hamlib-developer

[Hamlib-developer] AOR AR5000

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

I had a chance to play a little bit with an AOR AR5000 the other day.
I ran into a problem with hamlib in that the radio expects sent to it to be
terminated by a CR.  In aor.c, the commands being sent are terminated with a
EOM, which translates to "0xa" which translates to LF.

I'm not sure if anyone has tested this yet or if any of the AOR radios expect
commands to be terminated with a LF.  If there are, it's going to make the
patch a little more difficult.

I also ran across a bug where in aor_get_freq if the response from the radio
didn't have a "RF" in it (eg. because of a timeout) then it would try to do a
scanf with a null pointer and segfault.

I didn't have a lot of time while I was playing with the radio, so I didn't
have a chance to test most of the functions.  And I didn't have time to make
the changes look nice.  I attached an example of the quick changes I did, and
with them, get_freq and set_freq seemed to work fine.  If you want, I'll try to
come up with a cleaner patch.

By the way, I need to be able to set the radio's attenuator using hamlib and I
didn't see any support for the in aor.c.  Does that just require creating a
aor_set_level that does the work, and adding it to the cap structure in
AR5000.c?

---
Warning: this patch is pretty ugly, but it worked for me. :)

 #define CR '\r'
 #define EOM "\x0a"
+#define CR_STRING "\r"

.
.
.

 int aor_get_freq(RIG *rig, vfo_t vfo, freq_t *freq)
 {
                char *rfp;
                int freq_len, retval;
                unsigned char freqbuf[BUFSZ];
 
-               retval = aor_transaction (rig, "RX" EOM, 3, freqbuf, &freq_len);
+               retval = aor_transaction (rig, "RX" CR_STRING, 3, freqbuf,
&freq_len);
                if (retval != RIG_OK)
                        return retval;
 
                rfp = strstr(freqbuf, "RF");
+               if(!rfp)
+                 {
+                   printf("NO RF in returned string in aor_get_freq\n");
+                   printf("freqbuf = '%s'\n",freqbuf);
+                   return -RIG_EINVAL;
+                 }
                sscanf(rfp+2,"%lld", freq);
 
                return RIG_OK;
 }

Re: [Hamlib-developer] AOR AR5000

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

Hi Chuck, good to see you again!

On Mon, Feb 24, 2003, Chuck Hemker wrote:
> I had a chance to play a little bit with an AOR AR5000 the other day.
> I ran into a problem with hamlib in that the radio expects sent to it to be
> terminated by a CR.  In aor.c, the commands being sent are terminated with a
> EOM, which translates to "0xa" which translates to LF.
> 
> I'm not sure if anyone has tested this yet or if any of the AOR radios expect
> commands to be terminated with a LF.  If there are, it's going to make the
> patch a little more difficult.

I wrote initial support for the AOR backend, but it has never been
tested to a point where at least one command works :)
So the "\r" patch is applied.

> I also ran across a bug where in aor_get_freq if the response from the radio
> didn't have a "RF" in it (eg. because of a timeout) then it would try to do a
> scanf with a null pointer and segfault.

Ahah! still on the "Segfault-award" quest ;-)
patch applied.

> I didn't have a lot of time while I was playing with the radio, so I didn't
> have a chance to test most of the functions.  And I didn't have time to make
> the changes look nice.  I attached an example of the quick changes I did, and
> with them, get_freq and set_freq seemed to work fine.  If you want, I'll try to
> come up with a cleaner patch.

That's fine, it was short and obvious.

> By the way, I need to be able to set the radio's attenuator using hamlib and I
> didn't see any support for the in aor.c.  Does that just require creating a
> aor_set_level that does the work, and adding it to the cap structure in
> AR5000.c?

Absolutely. To give you a quick start, I've commited an initial
get_levl/set_level support. There's no guarantee it will work!

BTW, I've fixed the set_mode/get_mode. Passband width is missing though.


Thanks for the testing.

Cheers,
Stephane

Re: [Hamlib-developer] AOR AR5000

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

On 24-Feb-03 Stephane Fillod wrote:
> I wrote initial support for the AOR backend, but it has never been
> tested to a point where at least one command works :)
> So the "\r" patch is applied.

Looking at your patch, I noticed one thing that was different from mine:
The reason I didn't change EOM was I didn't change EOM in aor_transaction.
From the docs and the fact that it didn't stair step in kermit (sorry, I didn't
look that closely at the hamlib debug dump) I assume that the radio responds
with the result line followed by a CR LF.  I don't know what the effect would
be if it stops reading at the CR.  Would it help to have a radio->hamlib
returned EOM set to CR LF?

I'll be happy to test it the next time I get a chance, but it will probably be
a few weeks.  First, I have to fix the bugs in my code that I found, and then I
have to get up there, and get a chance to play with his radios.

> 
>> I also ran across a bug where in aor_get_freq if the response from the radio
>> didn't have a "RF" in it (eg. because of a timeout) then it would try to do
>> a
>> scanf with a null pointer and segfault.
> 
> Ahah! still on the "Segfault-award" quest ;-)
> patch applied.

I didn't mean to. :)
It was just one of those little tested code paths.  Since the radio didn't
understand the command, it was timing out.  So the buffer was empty.  By
definition empty buffers don't have an "RF" in them.  :)

> Absolutely. To give you a quick start, I've commited an initial
> get_levl/set_level support. There's no guarantee it will work!

Thanks.  Now I have to add support to my code for it.
I wouldn't have worried about it right now except that the radio locks the
keyboard (but not the tuning knob) when the computer is talking to it.  So you
can't just push the button.
And with a noisy down converter before the radio the attenuator helps.

Thanks for all your help with hamlib.  Otherwise I would have to write drivers
for all the radios I get a chance to play with.  Now all I have to worry about
is all the different quirks that the radios have. :)
Maybe when I get a chance I'll write up something about the things I've found.