hamlib-developer — hamlib developers forum

[Hamlib-developer] IC735 - first test run

[<dar...@bt...>]

Stephane,

Have done a quick test of the ic735. The list below shows the functions I
quickly had a go at, with the attached text file as the output. It looks
like it works as expected so well done doing this without the radio!

As I'm still a bit new with this, so the functions with "??" below I'm not
sure about (hence the debug file). Have a look and tell me what you think.
I'm going to be adding to this radio at some point, but will drop a note
when I get going. 

All the best,

73's,

Darren - G0WCW
-------------- List of Functions -------------- 

F: set_freq        (Frequency)		OK!
f: get_freq        (Frequency)		OK!
M: set_mode        (Mode,Passband)      	OK! - USB, LSB, AM, CW
m: get_mode        (Mode,Passband)		OK!
V: set_vfo         (VFO)        		??
v: get_vfo         (VFO)        		Not Implemented
T: set_ptt         (PTT)        		Not Implemented
t: get_ptt         (PTT)        		Not Implemented
R: set_rptr_shift  (Rptr shift)           Not Implemented
r: get_rptr_shift  (Rptr shift)           Not Implemented
O: set_rptr_offs   (Rptr offset)		Not Implemented
o: get_rptr_offs   (Rptr offset)		Not Implemented
C: set_ctcss_tone  (CTCSS tone)         	Not Implemented
c: get_ctcss_tone  (CTCSS tone)		Not Implemented
D: set_dcs_code    (DCS code)   		Not Implemented
d: get_dcs_code    (DCS code)			Not Implemented
I: set_split_freq  (Tx frequency)       	Not Implemented
i: get_split_freq  (Tx frequency)		Not Implemented
X: set_split_mode  (Mode,Passband)      	Not Implemented
x: get_split_mode  (Mode,Passband)		Not Implemented	
S: set_split       (Split mode)         	Not Implemented
s: get_split       (Split mode)		Not Implemented
N: set_ts          (Tuning step)        	Not Implemented
n: get_ts          (Tuning step)		Not Implemented
L: set_level       (Level,Value)        	Not Implemented
l: get_level       (Level,Value)		Not Implemented
U: set_func        (Func,Func status)   	??
u: get_func        (Func,Func status)	??
P: set_parm        (Level,Value)        	Not Implemented
p: get_parm        (Level,Value)		Not Implemented
E: set_mem         (Memory#)    		??
e: get_mem         (Memory#)			Not Implemented
G: vfo_op          (Mem/VFO op)         	Not Implemented
g: scan            (Scan fct,Channel)	Not Implemented
H: set_channel     ()   			Not Implemented
h: get_channel     (Channel)			OK!
A: set_trn         (Transceive)		Not Implemented         
a: get_trn         (Transceive)		Not Implemented
B: set_bank        (Bank)       		Not Implemented
_: get_info        (Info)			OK! (None)
2: power2mW        ()				Not Implemented

Re: [Hamlib-developer] Proposed patch for tranceive hanging

[Chuck H. <n2...@am...>]

I forgot to mention that with respect to the possibly major rewrite of the
backend to support multiple radios on the CI-V bus among other things:

1. I don't have two icom radios to test it with directly.
   (without going over to a friends, and then they may overlap in frequency
    which would cause problems for tranceive)
2. I'm not sure how separating out the ci-v bus would fit in hamlib.
   (New routine in src/register.c to register the ci-v bus?)
   (what to put in the various internal structures and such.)
3. I'm not sure how much time I'll have.

Because of this, I'm not sure when/if I would get to it.  However, if you do
want me to work on it, I'll try.

Or if I run into a need and/or problems with the current code.  :)

I will of course, help finish cleaning up the fixes to the current version I
started the other day.  And other things I run across.

[Hamlib-developer] RE: [Hamlib-cvs-digest] CVS: hamlib/src iofunc.c,1.1,1.2 iofunc.

[Chuck H. <n2...@am...>]

You might want to undo this particular part of the patch.  Assuming that rxmax
is the max size of the buffer, since your adding the '\000' character to the end
of the returned string, you only want to read up to rxmax-1 characters.

I had changed that in my routine because:
1. I dropped the trailing '\000'
2. read_icom_block was calling my routine with the expected frame length
   rather then the buffer size.  Otherwise I'd miss the last character.

Since you didn't do 1 and killed the need for 2, it probably should be rxmax-1.



On 10-Mar-02 Stephane Fillod wrote:
> *** iofunc.c  16 Jan 2002 22:56:34 -0000      1.1
> --- iofunc.c  10 Mar 2002 23:41:39 -0000      1.2
> ***************
> *** 292,296 ****
>     tv_timeout.tv_usec = (p->timeout%1000)*1000;
>   
> !   while (total_count < (rxmax-1)) {
>               tv = tv_timeout;        /* select may have updated it */
>   
> --- 291,295 ----
>     tv_timeout.tv_usec = (p->timeout%1000)*1000;
>   
> !   while (total_count < rxmax) {
>               tv = tv_timeout;        /* select may have updated it */
>   

Re: [Hamlib-developer] Proposed patch for tranceive hanging

[Chuck H. <n2...@am...>]

On 11-Mar-02 Stephane Fillod wrote:
> On Sun, Mar 10, 2002, Chuck Hemker wrote:
>>
> 
> RIG_EPROTO is the only one to fit. However, it's rather pointless to the
> user. When having a collision, we should retry rs->retry times, and fail
> with an error code. I was thinking of something like RIG_ERESTART, telling
> that there was a temporary protocol issue. Do you have a better name in
> mind?

I was thinking of something as simple as RIG_COLLISION, however, several times
in the past I may have errored on the side of too many error codes rather than
too few.  Or if your expecting that in most cases it will have retried and only
return it if the retries failed, maybe something like COMMBUSY or BUSBUSY (like
CIVBUSY but more generic)  Also most of the time in the past I've run across
"protocol errors", they have been caused by either software errors or version
mismatches rather than temporary overload or hardware issues.

> And yes, if you'd like to work on this, you're more than welcome!
> I don't have time to work on the backend, even though I have a clear idea
> of what needs to be done.

I'll come up with a patch which adds error checking to icom_transaction and
icom_decode along with comments of possible causes.  Then we can discuss
error codes for each of the cases.

>> 3. Just a note to anyone who does want to try to implement resend on
>>    error/collisions:
>> 
>>    It would be nice if there was a way to turn it off.
>> 
>>    A collision could easily be caused by someone turning the knob while the
>>    software is trying to do something to the radio.  In that case, my
>>    software would prefer to know that the knob was turned rather than the
>>    command was done correctly so it doesn't lose any knob turns.  I
>>    understand
>>    that many other pieces of software would prefer their commands to work
>>    and
>>    don't want to have to worry about handling the errors.
> 
> To my mind, if a collision occurs, there's no way to give priority to
> transceive event simply because TX and RX are tied together, meaning
> that data on the CI-V bus is jammed. The controller knows its command
> failed (readback mismatch), chances are big the transceive event is lost,
> i.e. the rig won't resend it. TBC.

1. In the pdf file (note 1) I have (sections 5-4 and 1-6) it says the radio
   when seeing a collision:
    a. waits till the bus is idle
    b. sends the jammer code (FC) 5 times
    c. waits till the bus is idle
    d. retransmits the frame
2. If you have a collision between a set frame and a tranceive frame, and you
   did automatic recovery, you could end up with a situation like this:
    a. call set
    b. set gets a collision
    c. tranceive frame received (if it does resend correctly)
    d. tranceive callback called
    e. set is retried and works
    f. set returns
   And if the software really wanted the tranceive event to take priority, it
   would have to realize this happened and set the radio to the value given by
   the tranceive event.  And if the transceive frame did get lost, there is no
   way the software could figure out what it did because the set was done
   afterwords.

   Where if the set is allowed to fail on a collision it would be:
    a. call set
    b. set gets a collision
    c. set returns collision error
    d. tranceive frame received (if it does resend correctly)
    e. tranceive callback called
   Then the software could either process the tranceive frame, or call get to
   figure out what state the radio is in.

   Now, I'm not saying that retrying shouldn't be supported because most
   software out there will probably just prefer the set to succeed.  But if your
   trying to handle turning the knob while trying to do sets based on the
   previous values of the same vfo it makes it more difficult.  I'm just saying
   it would be nice to make it optional.  
   (Always retry on get commands might be ok)
   (The other issue I could see is what if the software is supposed to be doing
    something else that is semi time critical and gets tied up in hamlib for
    several seconds retrying a command)

  Quick description of my software:
   Because satellites are moving so quickly, the frequency at the radio is
offset    from the frequency at the satellite by a the doppler shift (which
keeps    changing as the satellites possession changes).  Several of the
satellites    have transponders on them which repeat everything (ssb and cw) in
their    passband (~100 khz) on another band.  So, what I was trying to do was
   to allow the user to select the transponder, and then tune through the
   transponder using the knob on the radio and when they hear something that
   they want to listen to, they stop tuning and the software starts updating the
   receive frequency based on the doppler changes so it tracks the qso.  I've
   also used this to adjust the radio when listening to beacons and other 
   fixed (at the satellite) frequency things when either the frequency at the
   satellite is not quite the same as published, or the calculations are
   slightly off.
   And I will be adding support for setting the transmitter (either same radio,
   different vfo, or different radio) to the matching uplink frequency (possibly
   with minor tuning support for correcting errors)

   I got this idea from InstantTune, a dos tsr (with source available)
   that talks to InstantTrack (a dos tracking program w/o source):
    http://www.amsat.org/amsat/ftpsoft.html#pc-it 
     InstantTune

   After hearing talks he's given at some of the Amsat Symposiums, there are
   lots of limitations with radios while trying to do this, such as:
   a. can't change the transmit frequency while transmitting
   b. can't change the receive vfo while transmitting
   c. radio blanks receive audio while adjusting transmit frequency (because
      it has to select transmit vfo, set frequency, select receive vfo)
   If I run across any that could be fixed in hamlib, I'll let you know.

>>     Also, I have implemented a semi-atomic update that does a get, checks to
>>     see
>>     if the value is the same as the old value, and if it is, then it does a
>>     set
>>     followed by another get.  This helps catch any knob changes that it
>>     might
>>     miss due to delays and such)
> 
> Stupid idea: could we have a collision callback? This way the application
> can be notified when a transceive event may have been lost.

  Not sure how much it would help.  First, hopefully the radio will resend it.
  Second, recovery would be a mess (you would have to do a get_freq and
  get_mode on every radio/vfo on the bus) and/or try to figure out if you set
  something you shouldn't have.

  What my "atomic" update checks against:
  a. lost tranceive events
  b. tranceive events that got processed after the set was sent.
     (because right now my radio_server program (hamlib calling program) and my
      doppler control program are separate (and sometimes on different
      machines) talking over a tcp connection, sometimes tranceive events and
      set events pass each other in the network.
  c. On non tranceive radios: knob changes that happened after the last poll
     cycle.
  Now it could miss things that happened between the get and the set, which is
  why it isn't really atomic, but it's much closer than before.
  (It's irritating to get something tuned in just right just before the software
   decides to set the radio off frequency which was happening before)

>> 4. The old read_icom_frame didn't didn't worry about the max rxbuffer
>> length. 
>>    This is a good thing to check just in case the radio/ci-v bus decided to
>>    send lots of garbage.  Since this new version does check, I looked at a
>>    bunch of the callers.
>>    Most of them call it with a buffer of size of 16, however icom_decode
>>    calls
>>    it with a buffer size of 32.  This should probably either be passed as an
>>    argument to read_icom_frame, a #define'ed constant, or at least
>>    consistent. 
>>    For now, I set it to 16 in read_icom_frame.  This will cause problems if
>>    icom_decode_frame gets a frame between 17 and 32 characters (Not seen in
>>    my testing)
> 
> a #define'ed constant or an argument to read_icom_frame would be a must.
> Do you have a patch already?

No.  I didn't know what you wanted.  If you want me to, I'll come up with one.

> Now, talking about the ci-v bus, it's not that simple, I agree with you.
> Just imagine the following cases:
> * the controller remote controls the rig (basic we're doing already, but
>         in ideal case where the following don't happen too much)
> * transceive frames received now and then, while doing something else
> * one controller and several rigs on the same bus (same serial port)
> * multithreaded application (-> serialize Hamlib calls, message
>         interleaving and multiple "open" cmds would be a nightmare)
> * more than one controller on the bus (-> ignore the noise)

(I did some testing by accident the other day when I opened the same radio more
 than once.  There was a fight between icom_transaction and icom_decode because
 they were using different hold_decode's.  I believe multiple radios on the
 same ci-v bus MAY work now as long as tranceive is OFF in hamlib.  But it
 definitely will NOT work if tranceive is ON in hamlib.)

One way to handle most of this would be:
 Try to separate the rig from the ci-v bus.
 When you opened a rig, it would check to see if the ci-v bus was already opened
 (see if the serial port name is the same??) and if so, it would use that ci-v
 bus.  Otherwise it would open the new ci-v bus.

 hold_decode would be a property of the ci-v bus not the rig.

 icom_transaction would be similar to now.

 icom_decode would get a frame, and if it was a tranceive frame it would go
 through each rig that was on that ci-v bus and see if the ci-v address of the
 rig matched the rig and if so call the callback.
 Ignore everything else unless you wanted to add support for ci-v sniffer
 software.

The other option would be switch to a more network programming type structure:
A poll/get_next_event/callback type structure.  icom_decode would handle all
incoming (and possibly echo) frames, and transactions would be handled by
sending a frame, and either hamlib or the user would have to
poll/get_next_event/wait for a callback to get the response.  This would require
either a separate thread, api change, or some odd code.  And I don't see this
as needed unless someone is afraid that the transaction processing time (send,
radio processing, response) is going to be too long to be inside hamlib the
whole time and/or the radio processing time is long enough that you want to
allow someone to send a command to a different radio on the bus in the mean
time.  (any radios with ethernet ports yet?)

(Maybe I'll do some testing of this one of these days:
 a. slow laptop
 b. put radio on old serial terminal server port (not enough serial ports on
    laptop to talk to both tnc & radio)
 c. ci-v bus at 1200 bps.
and I'll see if it's slow enough to cause problems.  I'll have to get the
terminal server from a friend.)
 
(did just realize that we do need to be prepared for a tranceive frame while in
icom_transaction (with no collisions):
 a. send command
 b. receive tranceive frame from same or different radio
 c. receive response to command
)

Don't know what you want to do about multithreaded apps:
big hamlib lock?
ci-v bus lock?
use hold_decode as the ci-v bus lock?
tell people to only call hamlib from one thread?
create a separate hamlib thread to do the work?

> PS: BTW, you must know the excellent Ekki's site at the following URL:

Yes, and I mentioned the other day:

Note 1:
   Old Icom CI-V docs at: http://www.chasque.net/franky/ci5.pdf
 These:
  a. describe older radios like the R7000
  b. describe some things that Ekki's site doesn't, like collisions/jamming

Re: [Hamlib-developer] Proposed patch for tranceive hanging

[Stephane F. <f4...@fr...>]

On Sun, Mar 10, 2002, Chuck Hemker wrote:
> Short description:
> 
> Here's a patch to fix my tranceive problem a a bit more.  (More like a re-write
> of a small piece of the icom frame handling).  Feel free to use it, ignore it,
> use pieces of it, ask me to change and/or extend it, or whatever.

Short answer:

The icom frame handling has to be completly re-written.
And you're taking a good start.

> ---
> 
> Long description:
> 
> I went to try to fix my problems with tranceive hanging in icom_decode, and
> also saw the comment in read_icom_frame:
>          * However, an automate with a state model would be more efficient..

The automate would be a kind of lexer. Maybe a bit overkill at 1200bauds.

> In doing this I was almost ready to write a new routine, then I noticed
> read_string was close to what I wanted:
> 1. It didn't do any reads without a select (which solved my tranceive problem)
> 2. It could read until a given set of stop characters (as in: FI or COL)
> 3. It only printed out the complete frame with dump_hex rather than the start
>    followed by each additional character.

yep, this function written by Francois is really handy. It can even handle
some protocols that have optional acknowledge (Kenwood).

> However, it didn't support one thing I needed:
> 1. Support for 00 as a character in the block.
> 
> So I copied it and created a new routine "read_block_until" (feel free to
> change the name) for reading a block (that can include 00) up until a set of
> stop characters (which may or may not include 00).  Then I changed
> read_icom_block and read_icom_frame to call this new routine.
> (see docs at top of read_block_until for more information about it)

No need for code duplication. I've added the missing parameter to
read_string. And since this function didn't exist in Hamlib-1.1.2, we
don't break binary compability.
Your patch works fine on my Ic-706MkIIG.

> Since I didn't know what format you wanted it in, I attached a patch in 
> "diff -urN" format.

very good. unified patches are the easiest to read.

> ---
> 
> A few other things:
> 
> 1. read_icom_block and read_icom_frame are very similar now.  I didn't know
>    what you had planned for each of them.

the death to read_icom_block. It was a hack to read n bytes. Very
dangerous if you get some collision or transceive bytes in the way.

> 2. I didn't add any additional checking for collisions or timeouts after
>    receiving at least one character.  Timeouts before the first character are
>    handled as before.
> 
>    Example collision/timeout processing:
> 
>    rxlen = read_icom_block(
>    or 
>    rxlen = read_icom_frame(
> 
>    if(rxlen <= 0)
>    {
>         /* normal error handling including timeouts before the first character*/
>         /* should never be 0 */
>    } else {
>       select(rxbuffer[rxlen-1])
>       {
>          case FI:  /* Normal frame */
>          case COL: /* Collision */
>          default:  /* timeout after receiving at least one character */
>       }
> 
>    If you would like me to work on this, let me know.  Also, I didn't notice an
>    error message for a collision.  Didn't know if you wanted a new one, or fit
>    it in one of the others.

RIG_EPROTO is the only one to fit. However, it's rather pointless to the
user. When having a collision, we should retry rs->retry times, and fail
with an error code. I was thinking of something like RIG_ERESTART, telling
that there was a temporary protocol issue. Do you have a better name in
mind?

And yes, if you'd like to work on this, you're more than welcome!
I don't have time to work on the backend, even though I have a clear idea
of what needs to be done.

>    Now, this error comes from the fact that it's trying to look at parts of the
>    buffer that are not initialized.  With my current xterm buffer size, I
>    couldn't scroll back far enough to see which routine got the collision first.
> 
>    I'll come up with a better trace if need be.

transceive is largely untested. The more traces, the easier to fix.
A complete rewrite may help also.

> 3. Just a note to anyone who does want to try to implement resend on
>    error/collisions:
> 
>    It would be nice if there was a way to turn it off.
> 
>    A collision could easily be caused by someone turning the knob while the
>    software is trying to do something to the radio.  In that case, my
>    software would prefer to know that the knob was turned rather than the
>    command was done correctly so it doesn't lose any knob turns.  I understand
>    that many other pieces of software would prefer their commands to work and
>    don't want to have to worry about handling the errors.

To my mind, if a collision occurs, there's no way to give priority to
transceive event simply because TX and RX are tighed together, meaning
that data on the CI-V bus is jammed. The controller knows its command
failed (readback mismatch), chances are big the transceive event is lost,
i.e. the rig won't resend it. TBC.

>     Also, I have implemented a semi-atomic update that does a get, checks to see
>     if the value is the same as the old value, and if it is, then it does a set
>     followed by another get.  This helps catch any knob changes that it might
>     miss due to delays and such)

Stupid idea: could we have a collision callback? This way the application
can be notified when a transceive event may have been lost.

> 4. The old read_icom_frame didn't didn't worry about the max rxbuffer length. 
>    This is a good thing to check just in case the radio/ci-v bus decided to
>    send lots of garbage.  Since this new version does check, I looked at a
>    bunch of the callers.
>    Most of them call it with a buffer of size of 16, however icom_decode calls
>    it with a buffer size of 32.  This should probably either be passed as an
>    argument to read_icom_frame, a #define'ed constant, or at least consistent. 
>    For now, I set it to 16 in read_icom_frame.  This will cause problems if
>    icom_decode_frame gets a frame between 17 and 32 characters (Not seen in
>    my testing)

a #define'ed constant or an argument to read_icom_frame would be a must.
Do you have a patch already?

> 5. Because I needed a character array with FI and COL in it in two different
>    routines and couldn't figure out how to use a #define to create it, I
>    defined it as a "static const char" in "icom/frame.c" (not inside of
>    either of the routines, but not EXTERN either).
>    If you have any better ideas of what you want to do with it, go ahead and
>    change it or let me know.

That's fine. Anyhow it would end up as a static const char[].

> 6. In testtrn I added a printf of the idle loop counter so as to better show
>    that it's working.  Otherwise you can't tell if something is hung in
>    tranceive handing routines without waiting to see if the program exits
>    after 120 seconds.  Feel free to ignore/change this if you don't want it.

Acutally, the loop is a kludge. Or to put it better, the application has
to be well written, i.e. check for errno == ERESTART, which means
"Interrupted system call should be restarted".

Maybe testtrn should be merged in rigctl..

> 7. read_block_until uses read rather than fread.  I don't know if it was
>    changed to use fread in the past for a reason, but sharing the same
>    standard i/o file descriptor between "normal" and signal handler contexts
>    makes me nervous.  Someone else may have a better idea of what is allowed.
>    You also could add buffering directly to read_block_until, but to do that
>    you would need:
>    a. A place to store characters read, but beyond the end of the current frame.
>    b. You might want to think a bit more about how you want to share a ci-v bus
>       between multiple items.  With this, right now, non-tranceive stuff
>       probably works because it doesn't read anything it doesn't handle.
>       return i;

The fread was here just because I was doing a lot of 1-byte reads.
Wrong approach. IMO, read_string is the way to go.
Maybe the days of fread are counted. And that would be a good thing.
(Let me be the executioner :)
Buffered reads can save some syscalls, but is it worth it?

Now, talking about the ci-v bus, it's not that simple, I agree with you.
Just imagine the following cases:
* the controller remote controls the rig (basic we're doing already, but
	in ideal case where the following don't happen too much)
* transceive frames received now and then, while doing something else
* one controller and several rigs on the same bus (same serial port)
* multithreaded application (-> serialize Hamlib calls, message
	interleaving and multiple "open" cmds would be a nightmare)
* more than one controller on the bus (-> ignore the noise)



Stephane

PS: BTW, you must know the excellent Ekki's site at the following URL:
		http://www.plicht.de/ekki/civ/

Re: [Hamlib-developer] Fwd: Opto535 test results

[Stephane F. <f4...@fr...>]

On Thu, Mar 07, 2002, John R. Marshall wrote:
> Now a question about cell phone freqs.
> 
> The opto boards can pick up the cell phone freqs, and that is outlawed in the
> US. Of the windows programs I used one let you receive them and another would
> sent you a code to turn on the banned freqs (you had to show you were
> government or repair related to get the code If I remember). So anyway I know
> many of you are not located in the US so I was wondering if you had any ideas
> about handling it?

Simple, remove the cell phone holes in rx_range_list1 of the os535
capabilities. rx_range_list1 stands for ITU region 1.
This would give something like 25MHz..520MHz, 760MHz..1.3GHz
And then "rigctl -C itu_region=1" would select it.
Would it be okay?


Stephane

[Hamlib-developer] Proposed patch for tranceive hanging

[Chuck H. <n2...@am...>]

Short description:

Here's a patch to fix my tranceive problem a a bit more.  (More like a re-write
of a small piece of the icom frame handling).  Feel free to use it, ignore it,
use pieces of it, ask me to change and/or extend it, or whatever.

---

Long description:

I went to try to fix my problems with tranceive hanging in icom_decode, and
also saw the comment in read_icom_frame:
         * However, an automate with a state model would be more efficient..

In doing this I was almost ready to write a new routine, then I noticed
read_string was close to what I wanted:
1. It didn't do any reads without a select (which solved my tranceive problem)
2. It could read until a given set of stop characters (as in: FI or COL)
3. It only printed out the complete frame with dump_hex rather than the start
   followed by each additional character.
However, it didn't support one thing I needed:
1. Support for 00 as a character in the block.

So I copied it and created a new routine "read_block_until" (feel free to
change the name) for reading a block (that can include 00) up until a set of
stop characters (which may or may not include 00).  Then I changed
read_icom_block and read_icom_frame to call this new routine.
(see docs at top of read_block_until for more information about it)

I tested it, and it seems to work fine here with my R7000.

Feel free use it, parts of it, change it, or whatever.

Since I didn't know what format you wanted it in, I attached a patch in 
"diff -urN" format.
I also attached copies of the the new read_block_until and modified
read_icom_frame and read_icom_block to make them easier to read and/or do
something else with them.
(tried just sticking them in the message, but my email program decided to word
 wrap them, which would have made it difficult to do anything but read them)

If you want anything different, let me know.

---

A few other things:

1. read_icom_block and read_icom_frame are very similar now.  I didn't know
   what you had planned for each of them.

2. I didn't add any additional checking for collisions or timeouts after
   receiving at least one character.  Timeouts before the first character are
   handled as before.

   Example collision/timeout processing:

   rxlen = read_icom_block(
   or 
   rxlen = read_icom_frame(

   if(rxlen <= 0)
   {
        /* normal error handling including timeouts before the first character*/
        /* should never be 0 */
   } else {
      select(rxbuffer[rxlen-1])
      {
         case FI:  /* Normal frame */
         case COL: /* Collision */
         default:  /* timeout after receiving at least one character */
      }

   If you would like me to work on this, let me know.  Also, I didn't notice an
   error message for a collision.  Didn't know if you wanted a new one, or fit
   it in one of the others.

   Note: The docs I have say the radio sends the collision/jammer code 5 times,
   waits for no more incoming data and then resends the frame.  Just a word of
   warning for anyone trying to implement collision recovery.

   BTW With a bit a playing I did cause a collision.   In the trace, I saw
   multiple calls to icom_decode in a row:

icom_decode: tranceive cmd unsupported 0x05
sa_sigioaction: activity detected
icom: icom_decode called
RX 1 characters
0000     fc     .
icom_decode: CI-V 0x8 called for 0xe0!

   Now, this error comes from the fact that it's trying to look at parts of the
   buffer that are not initialized.  With my current xterm buffer size, I
   couldn't scroll back far enough to see which routine got the collision first.

   I'll come up with a better trace if need be.

3. Just a note to anyone who does want to try to implement resend on
   error/collisions:

   It would be nice if there was a way to turn it off.

   A collision could easily be caused by someone turning the knob while the
   software is trying to do something to the radio.  In that case, my
   software would prefer to know that the knob was turned rather than the
   command was done correctly so it doesn't lose any knob turns.  I understand
   that many other pieces of software would prefer their commands to work and
   don't want to have to worry about handling the errors.

   (Well, the error handling in my software is fairly simple right now.  :)
    It just does a get after every set, and uses the last successful get as the
    number to check the new calculated value against when deciding to an
    update. 
    Also, I have implemented a semi-atomic update that does a get, checks to see
    if the value is the same as the old value, and if it is, then it does a set
    followed by another get.  This helps catch any knob changes that it might
    miss due to delays and such)

4. The old read_icom_frame didn't didn't worry about the max rxbuffer length. 
   This is a good thing to check just in case the radio/ci-v bus decided to
   send lots of garbage.  Since this new version does check, I looked at a
   bunch of the callers.
   Most of them call it with a buffer of size of 16, however icom_decode calls
   it with a buffer size of 32.  This should probably either be passed as an
   argument to read_icom_frame, a #define'ed constant, or at least consistent. 
   For now, I set it to 16 in read_icom_frame.  This will cause problems if
   icom_decode_frame gets a frame between 17 and 32 characters (Not seen in
   my testing)

5. Because I needed a character array with FI and COL in it in two different
   routines and couldn't figure out how to use a #define to create it, I
   defined it as a "static const char" in "icom/frame.c" (not inside of
   either of the routines, but not EXTERN either).
   If you have any better ideas of what you want to do with it, go ahead and
   change it or let me know.

6. In testtrn I added a printf of the idle loop counter so as to better show
   that it's working.  Otherwise you can't tell if something is hung in
   tranceive handing routines without waiting to see if the program exits
   after 120 seconds.  Feel free to ignore/change this if you don't want it.

7. read_block_until uses read rather than fread.  I don't know if it was
   changed to use fread in the past for a reason, but sharing the same
   standard i/o file descriptor between "normal" and signal handler contexts
   makes me nervous.  Someone else may have a better idea of what is allowed.
   You also could add buffering directly to read_block_until, but to do that
   you would need:
   a. A place to store characters read, but beyond the end of the current frame.
   b. You might want to think a bit more about how you want to share a ci-v bus
      between multiple items.  With this, right now, non-tranceive stuff
      probably works because it doesn't read anything it doesn't handle.
      return i;

8. If you don't like memchr (I needed a routine to that treated 00 as a normal
   char), it could easily be replaced by a for loop.

[Hamlib-developer] Re: [Xlog-discussion] OT: Sked follow up

[Stephane F. <f4...@fr...>]

On Thu, Mar 07, 2002, Joop Stakenborg wrote:
> So here is the complete schedule for sunday March 10th:
> 20.00	14.073	psk31
> 20.30	10.033	psk31
> 21.00	14.083	mfsk

alright, that'll be a good opportunity for me to test new digital modes,
and esp. with the good looking gmfsk.

I've also cross-posted to the hamlib-developer mailing list. 
Who knows if propagation will be good..

73's
Stephane

Re: [Hamlib-developer] PCR1000 debugs

[Stephane F. <f4...@fr...>]

On Thu, Mar 07, 2002, dar...@bt... wrote:
> Log from the PCR1000 as requested. If you need specific commands executed, just let me know and I'll run them.

well, actually, there aren't much :)
Just get_info and get/set freq/mode. Still a good start.

> Have a look to see if anything obvious. If not, I'll need to start digging as well!

2 huge bugs!
It's so much easier when you can test..

> Rig command: _
> 
> TX 5 bytes
> 
> 0000	 47 32 3f 0d 00	G2?..
                     ^^
This should be 0x0a. First bug. fixed.

> RX 1 bytes
> 
> 0000	 0a	.
> 
> RX 1 bytes
> 
> 0000	 48	H
> 
> RX 1 bytes
> 
> 0000	 31	1
> 
> RX 1 bytes
> 
> 0000	 30	0
> 
> RX 1 bytes
> 
> 0000	 30	0
> 
> RX 1 bytes
> 
> 0000	 0d	.
> 
> RX 1 bytes
> 
> 0000	 0a	.

Obviously, the rig reply with "H100", i.e. "I'm in power off state".
This is the second problem. should be fixed and commited.

Thanks to Jim Tittsler, I better understand how it works. There's now a
pcr_open in pcr/pcr.c that talks at 9600 bauds to power on the rig, and
will change speed later on, when the code stabilizes a bit.

Darren, could you please run again the same tests with the newest cvs
code and send me the traces? Thanks.

Stephane

Re: [Hamlib-developer] Problems with Icom R7000 modes

[Stephane F. <f4...@fr...>]

On Wed, Mar 06, 2002, Chuck Hemker wrote:
> I did some checking of the setting and getting of modes on the Icom R7000 and
> I noticed a few problems.

[many problems described, so easier to fix, esp. with good suggestions ]

> Feel free to ask if you need traces and/or any other help in doing this.  I'll
> also be happy to come up with a patch if you want, but there are several ways
> to fix this and I'm not sure which one you want to use.

icom2rig_mode and rig2icom_mode have to be reworked.
And each model should have the ability to override the conversion
functions. This is to prevent the messy if (rig->caps->rig_model ==
RIG_MODEL_ICR7000) etc.

I'll try to do that before the end of the week-end.


Stephane

[Hamlib-developer] Fwd: Opto535 test results

[John R. M. <jo...@jr...>]

Looks like this never made it to the list?

----------  Forwarded Message  ----------

Subject: Opto535 test results
Date: Thu, 7 Mar 2002 04:31:19 -0500
From: "John R. Marshall" <hot...@so...>
To: HamLib <ham...@li...>

This is great!

For the first time since I kicked my Microsoft habit last summer, I had the
pleasure of watching my scanner display go blank as my computer took control
over the scanner! :-D

Under rigctl

F - works
f - works
M - works
m - works
_ works

A few little things I noticed.

in opto535.c line 119 - need to add the 50kHz tuning step

in optoscan.com line 128 the error string should be optoscan_get_info not
icom_get_info

Now a question about cell phone freqs.

The opto boards can pick up the cell phone freqs, and that is outlawed in the
US. Of the windows programs I used one let you receive them and another would
sent you a code to turn on the banned freqs (you had to show you were
government or repair related to get the code If I remember). So anyway I know
many of you are not located in the US so I was wondering if you had any ideas
about handling it?

--
John R. Marshall - Web Developer

JRM Studios - http://www.jrmstudios.com
The Hotrodding Network - http://www.hotrodding.net

-------------------------------------------------------

-- 
John R. Marshall - Web Developer

JRM Studios - http://www.jrmstudios.com
The Hotrodding Network - http://www.hotrodding.net

RE: [Hamlib-developer] Icom PCR1000 - trying to get going ...

[Stephane F. <f4...@fr...>]

Quoting dar...@bt...:
> Stephane: you mentioned there was an online resource for the PCR1000. Any
> chance of the URL? I might stand a chance of getting some of the other
> functions working once over this initial hurdle.

I have a printed copy from http://www.philtered.net/icomlib.phtml which appears 
to be down. It's in the google's cache, at
http://www.google.com/search?
q=cache:87BKRKCX1_QC:www.philtered.net/icomlib.phtml+qt+pcr1000+icomlib&hl=en

No idea if the PDF is there also. I can scan my printed copy and e-mail it to 
you if you can't find it on the web.

May be of some help also, http://www.qtpcr.org
The code is GPL'ed, and supposed working. Worth a read.

Cheers,
 Stephane F8CFE

[Hamlib-developer] PCR1000 debugs

[<dar...@bt...>]

Stephane,

Log from the PCR1000 as requested. If you need specific commands executed, just let me know and I'll run them.

Have a look to see if anything obvious. If not, I'll need to start digging as well!

Regards,

Darren - G0WCW

RE: [Hamlib-developer] Icom PCR1000 - trying to get going ...

[<dar...@bt...>]

Stephane,

It's been a while but am still expecting to test a few radios over the next
few months.

Thanks for the notes on the PCR1000 - it was getting late last night and I
thought I was going bonkers! I'll run a quick test today and post back here.

Stephane: you mentioned there was an online resource for the PCR1000. Any
chance of the URL? I might stand a chance of getting some of the other
functions working once over this initial hurdle.

Jim: Thanks for the note on the switch from 9600 to 38400 - I had a
suspicion of this but no docs to back it up!

Many thanks,

Darren - G0WCW

-----Original Message-----
From: Stephane Fillod [mailto:f4...@fr...]
Sent: 06 March 2002 23:00
To: dar...@bt...
Cc: Hamlib developers
Subject: Re: [Hamlib-developer] Icom PCR1000 - trying to get going ...



Hey Darren, good to see you again!

On Wed, Mar 06, 2002, dar...@bt... wrote:
> Am I doing something dumb? I've used the pre-packaged Win32 app from Icom
> which works fine. Using rigctl and testrig (radio 401) I seem to get no
joy.
> I have set the line speeds from 2400 to 38400, set to /dev/ttyS0, and from
7
> or 8 bits using cs7/8 etc, to be sure all is the same. Am using RH 7.0 and
> the latest cvs release (downloaded yesterday).

fine. Reading the pcr1k docs, it looks like the default line speed is 9600.
I guess you already gave a look at the README.betatester file.

Would it be possible to run "rigctl -m 401 -r /dev/ttyS0 -s 9600 -vvvvvv"
and report the traces on the list or to me?
The "-vvvvvv" is very important since it will show off the traces
of the serial communication, giving hints where it breaks.

Actually, I developped the backend from documentation found on the
Internet. And obviously, I never got a chance to test it. But now,
the time has come :)

> Before I start delving into the PCR code and adding the other functions, I
> was hoping to at least get a correct response back from the radio! Anyone
> spot my mistake? 

mistake is not necessarily yours. Let's see what we can do with the
traces.


73's
Stephane F8CFE

Re: [Hamlib-developer] Icom PCR1000 - trying to get going ...

[Jim T. <7J...@On...>]

On Thu, Mar 07, 2002 at 12:00:18AM +0100, Stephane Fillod wrote:
> fine. Reading the pcr1k docs, it looks like the default line speed is 9600.

Yes, the PCR-1000 initializes at 9600 baud.  (The first thing
the Windows application does is change to 38400.)

[Hamlib-developer] Problems with Icom R7000 modes

[Chuck H. <n2...@am...>]

I did some checking of the setting and getting of modes on the Icom R7000 and
I noticed a few problems.

---

With setting of modes:

In the r7000 part of rig2icom_mode:

if (rig->caps->rig_model == RIG_MODEL_ICR7000) {
                if (mode == RIG_MODE_USB || mode == RIG_MODE_LSB) {
                                icmode = S_AM;
                                icmode_ext = 0x00;
                } else if (mode == RIG_MODE_AM && icmode_ext == 0x00) {
                                icmode_ext = 0x01;      /* default to Wide */
                }
}

First, SSB mode is 05 00, or S_FM 00, not S_AM 00.

After changing all the S_AM's to S_FM's, I ran across one other problem:
icom_set_mode strips on the '00' of the '05 00'.  And just sends the 05 which
puts it in FM mode.

retval = icom_transaction (rig, C_SET_MODE, icmode & 0xff, icmode_ext,
                                icmode_ext[0]?1:0, ackbuf, &ack_len);

Don't know how you want to fix this.

---

With the getting of modes:

In icom_get_mode, if the radio only sent one mode char, not two, icom2rig_mode
gets called with an uninitialized modebuf[2].
1. This occasionally causes errors if the initialized width is an Unsupported
   Icom mode width.  I reproduced this by doing a bunch of things with rigctl,
   trying to get an AM mode, getting an error, restarting and having it work
   fine.  (I guess it happens to be 0 most of the time)
2. I didn't know how you wanted to handle the difference between:
   FM:  05
   SSB: 05 00

Either icom2rig_mode needs to be passed the length, or the second character
needs to be set to something.  And that something can't be 0 because of #2.

---

Feel free to ask if you need traces and/or any other help in doing this.  I'll
also be happy to come up with a patch if you want, but there are several ways
to fix this and I'm not sure which one you want to use.

Re: [Hamlib-developer] Icom PCR1000 - trying to get going ...

[Stephane F. <f4...@fr...>]

Hey Darren, good to see you again!

On Wed, Mar 06, 2002, dar...@bt... wrote:
> Am I doing something dumb? I've used the pre-packaged Win32 app from Icom
> which works fine. Using rigctl and testrig (radio 401) I seem to get no joy.
> I have set the line speeds from 2400 to 38400, set to /dev/ttyS0, and from 7
> or 8 bits using cs7/8 etc, to be sure all is the same. Am using RH 7.0 and
> the latest cvs release (downloaded yesterday).

fine. Reading the pcr1k docs, it looks like the default line speed is 9600.
I guess you already gave a look at the README.betatester file.

Would it be possible to run "rigctl -m 401 -r /dev/ttyS0 -s 9600 -vvvvvv"
and report the traces on the list or to me?
The "-vvvvvv" is very important since it will show off the traces
of the serial communication, giving hints where it breaks.

Actually, I developped the backend from documentation found on the
Internet. And obviously, I never got a chance to test it. But now,
the time has come :)

> Before I start delving into the PCR code and adding the other functions, I
> was hoping to at least get a correct response back from the radio! Anyone
> spot my mistake? 

mistake is not necessarily yours. Let's see what we can do with the
traces.


73's
Stephane F8CFE

[Hamlib-developer] Icom PCR1000 - trying to get going ...

[<dar...@bt...>]

Hi all,

In the haste to get one of these beasts working against hamlib I have gone
through trying to get the various test apps to talk to the PCR1000. Sadly to
no avail.

Am I doing something dumb? I've used the pre-packaged Win32 app from Icom
which works fine. Using rigctl and testrig (radio 401) I seem to get no joy.
I have set the line speeds from 2400 to 38400, set to /dev/ttyS0, and from 7
or 8 bits using cs7/8 etc, to be sure all is the same. Am using RH 7.0 and
the latest cvs release (downloaded yesterday).

Before I start delving into the PCR code and adding the other functions, I
was hoping to at least get a correct response back from the radio! Anyone
spot my mistake? 

Any thoughts appreciated.

Darren - G0WCW

[Hamlib-developer] Problems with tranceive mode

[Chuck H. <n2...@am...>]

In changing my software to be using transceive using sigio, I've run across a
bug that I've been able to duplicate using testtrn.  When/if hamlib gets a
tranceive frame it processes it correctly, but it ends up back in icom_decode
and gets struck in there and never returns back to the main program.

To duplicate using testtrn:

First, I changed testtrn's loop to print out something:

        for (i=0;i<12;i++)
          {
            printf("Loop pass %d\n",i);
            sleep(10);  /* or anything smarter */
          }

Then I ran it:

./testtrn 340
testrig:hello, I am your main() !
rig:rig_init called 
rig: loading backend icom
icom: _init called
rig_register (309)
rig_register (310)
rig_register (311)
rig_register (319)
rig_register (330)
rig_register (326)
rig_register (327)
rig_register (334)
rig_register (344)
rig_register (335)
rig_register (340)
rig_register (342)
rig_register (304)
rig_register (307)
rig_register (300)
rig:rig_open called 
Port /dev/ttyS0 opened ok
TX 12 bytes
0000     ff fe fe 08 e0 05 00 00 70 39 04 fd    ........p9..
RX 12 bytes
0000     ff fe fe 08 e0 05 00 00 70 39 04 fd    ........p9..
RX 6 bytes
0000     fe fe e0 08 fb fd      ......
Loop pass 0                               (didn't touch the radio for
Loop pass 1                                one pass and it works fine)
sa_sigioaction: activity detected         
icom: icom_decode called                  (bumped tuning knob one step) 
RX 6 bytes
0000     fe fe 00 08 00 00      ......
RX 1 bytes
0000     01     .
RX 1 bytes
0000     70     p
RX 1 bytes
0000     39     9
RX 1 bytes
0000     04     .
RX 1 bytes
0000     fd     .
Rig changed freq to 439700100Hz
sa_sigioaction: activity detected
icom: icom_decode called

(and it stays there no matter how long you wait.)

---

To trace it down futher, In fread_block, I changed the first fread to be:
(Added printf's, and change count to 1)

  printf("fread_block: before first fread\n");
        rd_count = fread(rxbuffer, 1, 1, p->stream);
  printf("fread_block: after first fread\n");

Repeating the last test I, in the last part I got this:

Rig changed freq to 439700100Hz
sa_sigioaction: activity detected
icom: icom_decode called
fread_block: before first fread

---

This is telling me that it's hanging in the first fread in fread_block.
This has me confused because:
1. Why are we getting a SIGIO after we have read the last frame.
2. Why are we getting a SIGIO if there are 0 charaters in the input buffer.
3. Why is fread_block not timing out.  It times out fine if you try to command
   a radio that is off for example.

I would have loved to send in a patch that fixes the problem, but it has me
confused.

---

The particular machine I'm debugging this on is a RedHat 7.1 with a
custom compiled kernel version 2.4.14.  Problem is also there with the redhat
supplied 2.4.2-2.

---

If nobody else has any ideas, I'll dig into in further.  I did notice the
comments in read_icom_frame:

        /*
         * buffered read are quite helpful here!
         * However, an automate with a state model would be more efficient..
         */

I was wondering if there was a problem doing non-buffered reads?  If there is
a problem with fread and timeouts and/or signals, would read be better?  Just
wondering if there was a previous problem?

Re: [Hamlib-developer] Optoscan 535

[Stephane F. <f4...@fr...>]

Hi John!

Thanks for stopping by. That's nice to see people interrested in Hamlib.

Quoting "John R. Marshall" <hot...@us...>:
> I wonder if anyone is interested in coding a backend for the Optoelectronics 
> Optoscan 535 (A computer interface for the Radio Shack pro2035 and pro2045 
> scanners) It uses a version of the ICOM CI-5 interface.

Shouldn't be a problem since it uses the ICOM CI-V protocol.

> So if someone makes the backend, I'll make a kick butt gui for it. :-) I

take five, you've got a deal!

> subscribed to the list and I have the optoscan535/pro2035 combo so I'll be 
> available for testing (I'm good at breaking code ;-0) and I might be able to 
> fix some bugs myself, who knows.

Code breaker. Good. We need it. That's half of the work. I've heard stories
at the NASA where testers able to find 1 or 2 bugs per month were considered as 
*very* good testers.
Hamlib has be to be robust. Imagine controlling AO-40 with Hamlib, nobody wants 
to loose it again.

> You can find the specs for the interface here:
> http://www.optoelectronics.com/tech/pdf/os535/os535_ci5_spec_v10.pdf
> 
> And let me know what info you need for the scanner (freq range etc..).

Should be okay. I'll add in some basic support, and then we can implement
Optoscan specific commands.

> And heres the specs for the optoscan456 interface for the pro2004-6 scanners 
> if your interested: 
http://www.optoelectronics.com/tech/pdf/os456/os456_ci5_spec.pdf

Are there many differences with the os535?

> Come to think of it the Elecraft K2 would be another rig I'd like to see
> included (the specs are on their site www.elecraft.com) I'm going to buy the 
> kit as soon as I get around to getting my ticket, and have the cash :-)

Is the K2 remote controllable? I got to check this out. 
As Frank used to say it, "If we can talk to it, we want to control it!!"


Cheers,
 Stephane F8CFE

[Hamlib-developer] Optoscan 535

[John R. M. <hot...@us...>]

Hi folks,

I wonder if anyone is interested in coding a backend for the Optoelectronics 
Optoscan 535 (A computer interface for the Radio Shack pro2035 and pro2045 
scanners) It uses a version of the ICOM CI-5 interface.

I was going to try to do it myself by hacking the ICOM source but to tell the 
truth after looking at the code for a few days I found out that it's all over 
my head. (I'm just starting with C/C++ stuff, my background is mostly in php 
and some perl) 

So if someone makes the backend, I'll make a kick butt gui for it. :-) I 
subscribed to the list and I have the optoscan535/pro2035 combo so I'll be 
available for testing (I'm good at breaking code ;-0) and I might be able to 
fix some bugs myself, who knows.

You can find the specs for the interface here:
http://www.optoelectronics.com/tech/pdf/os535/os535_ci5_spec_v10.pdf

And let me know what info you need for the scanner (freq range etc..).

And heres the specs for the optoscan456 interface for the pro2004-6 scanners 
if your interested:
http://www.optoelectronics.com/tech/pdf/os456/os456_ci5_spec.pdf


Come to think of it the Elecraft K2 would be another rig I'd like to see 
included (the specs are on their site www.elecraft.com) I'm going to buy the 
kit as soon as I get around to getting my ticket, and have the cash :-)

-- 
John R. Marshall - Web Developer

JRM Studios - http://www.jrmstudios.com
The Hotrodding Network - http://www.hotrodding.net

[Hamlib-developer] Re: [hamlib - Open Discussion] GUI clients and Java

[Margaret L. <ma...@vo...>]

On Tuesday 05 March 2002 17:31, Stephane Fillod wrote in "Re: [hamlib - 
Open Discussion] GUI clients and Java":

> In other words, a GUI with a Pure Java implementation of the various
> rig protocols. Usual pros and cons apply.

I've been programming for thirty years in various languages. I can read 
C/C++, but writing it makes my head hurt. :-)

> > I'm especially interested in satellite work personally, and may
> > eventually borrow some code from the somewhat dormant JStation
> > project, so I expect that would require a GPLish licence at that
> > point.
>
> Software tends to want freedom :) 

Indeed...this is the first prolonged period of unemployment in my 
career; I've been out of work since last May... .
 
 <plug> resume at http://voicenet.com/~maggie/msleresume.html </plug>
 
..so releasing my first open source project at this point leaves me 
feeling, in Tom Lerher's famous words "like a Christian Scientist with 
appendicitis". :-)    

> AFAIK, Francois has already a patch for a Java binding...

Knowing that keeps me from reinventing *that* wheel. :-) 

 73 de Maggie K3XS

-- 
-----/___.   _)   Margaret Stephanie Leber    / "The art of progress  /
----/(, /|  /| http://voicenet.com/~maggie   / consists of preserving/
---/   / | / |  _   _   _    `  _AOPA 925383/ order amid change and /
--/ ) /  |/  |_(_(_(_/_(_/__(__(/_  FN20hd / change amid order."   /
-/ (_/   '  K3XS  .-/ .-/    ARRL 39280   /___ --A.N.Whitehead ___/
/____ICQ 7161096_(_/_(_/__AMSAT 32844____/ <ma...@vo...>

[Hamlib-developer] Re: IC-718 support, was Re: Hamlib-cvs-digest digest, Vol 1 #283 - 1 msg

[Stephane F. <f4...@fr...>]

Hi Chuck!

On Mon, Mar 04, 2002, Chuck Gilkes wrote:
> Thanks for the info.....I've attached a tar ball which includes the
> ic718.c and a few diffs.  Please check 
> to ensure the diff are in the correct format.  I haven't done any
> serious C work in 3 or 4 years and I'm bit  rusty :-).  

Everything seems fine. Looks like you made your patch against 1.1.2.
Anyway, ic718 is checked in. Thanks to you.
Can you give it a try now, from a fresh cvs checkout?

BTW, did you have any reason to comment out the "frame[i++] = PAD;" in
icom/frame.c ? Did it confuse your ic718?

> I'll do what I can to help.  Do you and the rest of the crew ever
> schedule on 20 or 15 meters SSB? Or maybe mfsk? 

That'd be a good idea. I know some of us have problem with their mikes so
mfsk would be more appropriate. hi.  
Whatever, I would say it's better to agree on some frequency we can all
watch, and then listen for CQ CQ CQ HAMLIB...
Do you have any preference for a qrv?


73's
Stephane F8CFE

Re: [Hamlib-developer] Info for Kenwood ts-440 & tmd-700

[Stephane F. <f4...@fr...>]

Hi Brett!

On Mon, Mar 04, 2002, Brett Schwarz wrote:
> Hi
>  I have devolped code for controling many radios by my repeater controller.
> 
> Radios tested are:
> Alinco DX-77, Kenwood TS-440 ( and others ), Kenwood TMD-700(A/E), Tait
> T20xx radios in CTMM & ICOM CI-V, both 4 & 5 byte frequency data.

Do you still have access to all these radios? Because Hamlib has protocol
implemented for almost all these rigs, but still lacks testing.
Note: I've never heard of Tait T20xx radios. Are they transceivers?

> All the code is written in C for the 68HC11 single chip micro and also for
> the PIC16F84 & 805x chips.

Too bad the memory constraints are too restrictive to let Hamlib run on
these shrinked microcontrollers.

> Something I have worked on is a single chip "universal" interafce that has
> RS-232 to the PC with ASCII based commands translated to the appropriate
> radio.

What kind of functions does your universal interface support?
Is there any the Hamlib API does no cover?

(Idea poping into my mind)... Are you interrested in developping a Hamlib
backend for your single chip universal interface ?

> If any of this is usefull let me know.
> Live long and prosper.

"Que ta barbe pousse toujours plus longue".

Thanks for the proposed help.
Stephane F8CFE

[Hamlib-developer] Re: [hamlib - Open Discussion] GUI clients and Java

[Stephane F. <f4...@fr...>]

Hi Maggie!

On Tue, Mar 05, 2002, maggiel wrote:
> 
> Read and respond to this message at: 
> http://sourceforge.net/forum/message.php?msg_id=1502152
> By: maggiel
> 
> I've been lurking here a little while and thought I'd mention that I'm working
> on a personal project I  call JHamTune.
>
> It's approaching rig control from the opposite direction:  rather than building
> a C++ library first, I'm working on a pure Java approach...GUIs written to a
> Java API (interface JHTRadio), and then building Java drivers implementing JHTRadio
> for each supported radio. The design is still very preliminary, and I haven't
> yet decided yet exactly how this will eventually be released.

In other words, a GUI with a Pure Java implementation of the various
rig protocols. Usual pros and cons apply.

> I'm especially interested in satellite work personally, and may eventually borrow
> some code from the somewhat dormant JStation project, so I expect that would
> require a GPLish licence at that point.

Software tends to want freedom :)

> That said...it occurs to me that a Java class that implemented JHTRadio and
> could call hamlib through JNI might be a fun thing...and would give Hamlib 
> a somewhat useful GUI client.

Sure. And know that you're not the only one interested in satellite work.
Funny how ideas are not bound to geographic frontiers.
AFAIK, Francois has already a patch for a Java binding, waiting to be
included in 1.1.4  (dang, I should really release 1.1.3, and quickly!).

> So far I've only written an FT-847 driver; I'll probably tackle ICOM 746 next,
> after I have a manual control widget I'm happy with; so far only the band-sweeping
> and channel scanning GUIs are usable.

cool

> Anyway...I have a skeletal JavaDoc (and a screenshot from a recent build) up
> on a Geocities site:
> 
> http://geocities.com/maggieleber/JHamTune/doc

I'll give it a look tomorrow.

> I suppose this note really belongs on the developer list--I'm new to Sourceforge
> so bear with me.

Don't worry, I've Cc: your message to the hamlib-developer list. 
Feel welcome to subscribe it, and discuss about Hamlib and your software.

> 73 de Maggie K3XS <k3...@ar...> 
> http://voicenet.com/~maggie        


Cheers,
 Stephane F8CFE