hamlib-developer — hamlib developers forum

[Hamlib-developer] Proper API implementation for Rotor-EZ

[Nate B. <n0...@ne...>]

When I implemented the rotorez backend I consolidated the rotor aiming
and rotating commands into rot_set_position.  I have a feeling this may 
be the wrong way to do it based on another reading of the API.

In my current implementation there is no use for the rot_move function.
As it is currently structured that when rot_set_position is called the
azimuth value is checked and then the command string is created and sent
to the rotor interface.  Next, the command to actually move the rotor to
the desired position is sent.

However, the Rotor-EZ and DCU-1 (Hy-Gain) interfaces do not support what
I gather to be the rot_move function's idea of direction (CW, CCW, Up or
Down) nor a rotational speed.  So, to use rot_move any passed values
would be ignored and a static command sent to the interface.

So, what is the intent of the API?  Is the application code expected to 
call rot_set_position and then rot_move for positioning to actually occur?
I see that fodtrack uses just rot_set_position while easycomm uses
rot_move.  So, whichever why I go will set a 2 to 1 preference.

I'd be happy to add comments to rotator.c to make this more clear.  :-)

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamamoto

Re: [Hamlib-developer] Bad luck with the new rpm

[<al...@ph...>]

I'll give it a try tomorrow (I use RedHat at work).

Alex, OZ9AEC

Quoting Joop Stakenborg <pa...@de...>:

> I am unable to build a new rpm. The chrooted environment which I have
> used previously, fails to build it due to some strange linking problem
> which I don't understand.
> 
> Sorry for the trouble. Maybe it is best if the current rpm is removed
> from the hamlib archive. I have to do some head-scratching and take
> some
> time to resolve this. Maybe some-one else wants to have a go at it?
> 
> The spec file which used to work is attached. This file only works with
> 1.1.3.
> 
> Regards,
> Joop
> 

[Hamlib-developer] Bad luck with the new rpm

[Joop S. <pa...@de...>]

I am unable to build a new rpm. The chrooted environment which I have
used previously, fails to build it due to some strange linking problem
which I don't understand.

Sorry for the trouble. Maybe it is best if the current rpm is removed
from the hamlib archive. I have to do some head-scratching and take some
time to resolve this. Maybe some-one else wants to have a go at it?

The spec file which used to work is attached. This file only works with
1.1.3.

Regards,
Joop

Re: [Hamlib-developer] serial ports and hamlib

[Alexandru C. <al...@ph...>]

On Mon, 2003-02-24 at 21:50, Stephane Fillod wrote:
> Now, let's do the math.
> The communication is set to 1200 bauds, which is 120 byte/s using 8N1.
> This allows 40 bytes per exange, since xlog/tlf poll ~3 times a sec.
> Note: the link is full duplex, but most of the time the protocol is
> half duplex.
> This is still okay, but now, what if the rig is a bit slow at answering?
> It may block the GUI and its event-handling loop.

Yes, exactly. I was thinking of solving this problem by having ONLY ONE
"main loop" interacting with Hamlib continuously, waiting politely for
slow connections and timeouts, and storing the read/set values in shared
memory which can be accessed by the rest of the application. This will
probably introduce some delay between the set and get values, but it's
still better than having a blocked GUI.

As long as we have a direct link between Hamlib and a GUI, there will
always be the possibility of this to-way struggle: An aggressive GUI
might easily overload Hamlib, which in turn will block the GUI. 
If we want to avoid such things in the long run, we should work toward
the client/server scheme, where we have a well designed server daemon
talking to Hamlib in one end, and accepting requests from clients
through pipes and/or sockets in the other end. The rpc.rigd may already
fulfill some of this.

Alex, OZ9AEC

Re: [Hamlib-developer] Rotator API

[Alexandru C. <al...@ph...>]

On Sun, 2003-02-23 at 20:36, Stephane Fillod wrote:
> On Mon, Feb 17, 2003, Alexandru Csete wrote:
> > I am currently adding rotator support to grig and I have a couple of
> > questions to the rotator API. First, the rot_reset function needs an
> > integer parameter besides the usual *rot structure. What is the purpose
> > of this integer? The API says it's "The reset operation to perform" but
> > what are the choices? Is there a "safe, universal value"?
> 
> So far, there's no such backend paying attention to this parameter. 
> However, in the future, some backend will.
> What about a safe ROT_RESET_ALL define ?

Yes, I think that's a good idea. It would also be consistent with the
rest of the API having #defs for discrete values (like mode, agc, vfo).
In the mean time I leave this feature out.

> > Second, the rot_move function needs to know the speed, which can be
> > between 1..100. Does the speed have a physical unit, or is the value
> > specific to the back end?
> 
> This speed arg is broken. Let's fix it. 
> First, it should not be specific to a backend, and next, it should have a
> physical unit. What about a float for radian per second?
> I don't have a computer-controlled rotator, so if anyone of you have
> a better unit, please stand up.

I think a float specifying degrees per second would be better because
(correct me if I'm wrong, please):

1) rads/sec would always be small number
2) it is easier / we are used to think in degrees rather than in rads?
3) we already use degrees in rot_set/get_position (API doc: "unless
specified otherwise")

> And of course, the rotator caps are missing minimum and maximum speed
> fields (which will depend on the unit).

That would be very nice too.

Alex, OZ9AEC

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.

Re: [Hamlib-developer] serial ports and hamlib

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

On Tue, Feb 25, 2003, Wilbert Knol wrote:
 
> OK..no problem doing that. Unfortunately, I am without hamlib at the moment.
> I have gone back to Mdk7.2/kernel 2.2.23, and hamlib won't build. I would 
> really appreciate any pointers. Here is the compiler output:
> 
> Making all in fodtrack
[...]
> fodtrack.c: In function `setDirection':
> fodtrack.c:59: `PPWDATA' undeclared (first use in this function)
[...]
> [root@zl2bsj hamlib-1.1.4cvs-030210]#
> 
> 
> Perhaps it is to do with the fact kernel 2.2.23 does not have ppdev?

absolutely! I saw your message on the sourceforge forum, and commited a
fix this week-end to address the problem. So it's in cvs. Let me know
if you prefer a snapshot to play with.

> I can't use rotator tracking and would be happy to disable it. In fact, is it 
> a good idea to give the ./configure script options like: --with-radio=ic725 
> etc etc, so as not to compile for gear one does not have?

sure, very nice idea. Easier to say than to do. Maybe we should borrow
some configure.ac magic from alsa or other project.
Anyway, it's in the todo list.

Cheers,
Stephane

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] serial ports and hamlib

[Wilbert K. <w....@ni...>]

On Tuesday 25 February 2003 10:50, Joop Stakenborg wrote:

> The recompile and see what it does. Maybe we are lucky.
>

OK..no problem doing that. Unfortunately, I am without hamlib at the mome=
nt.
I have gone back to Mdk7.2/kernel 2.2.23, and hamlib won't build. I would=
=20
really appreciate any pointers. Here is the compiler output:

Making all in fodtrack
make[1]: Entering directory `/usr/local/src/hamlib-1.1.4cvs-030210/fodtra=
ck'
source=3D'fodtrack.c' object=3D'fodtrack.lo' libtool=3Dyes \
depfile=3D'.deps/fodtrack.Plo' tmpdepfile=3D'.deps/fodtrack.TPlo' \
depmode=3Dgcc /bin/sh ../depcomp \
/bin/sh ../libtool --mode=3Dcompile gcc -DHAVE_CONFIG_H -I. -I. -I../incl=
ude=20
-I../include -I../src -I../lib    -g -O2 -Wall -c -o fodtrack.lo `test -f=
=20
'fodtrack.c' || echo './'`fodtrack.c
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../src -I../lib -=
g=20
-O2 -Wall -c fodtrack.c -Wp,-MD,.deps/fodtrack.TPlo  -fPIC -DPIC -o=20
=2Elibs/fodtrack.lo
fodtrack.c: In function `setDirection':
fodtrack.c:59: `PPWDATA' undeclared (first use in this function)
fodtrack.c:59: (Each undeclared identifier is reported only once
fodtrack.c:59: for each function it appears in.)
fodtrack.c:63: `PARPORT_CONTROL_AUTOFD' undeclared (first use in this=20
function)
fodtrack.c:66: `PPWCONTROL' undeclared (first use in this function)
fodtrack.c:70: `PARPORT_CONTROL_STROBE' undeclared (first use in this=20
function)
make[1]: *** [fodtrack.lo] Error 1
make[1]: Leaving directory `/usr/local/src/hamlib-1.1.4cvs-030210/fodtrac=
k'
make: *** [all-recursive] Error 1
[root@zl2bsj hamlib-1.1.4cvs-030210]#


Perhaps it is to do with the fact kernel 2.2.23 does not have ppdev?

I can't use rotator tracking and would be happy to disable it. In fact, i=
s it=20
a good idea to give the ./configure script options like: --with-radio=3Di=
c725=20
etc etc, so as not to compile for gear one does not have?

Wilbert, ZL2BSJ

Re: [Hamlib-developer] hamlib 1.1.3 rpm

[Joop S. <pa...@de...>]

Op ma 24-02-2003, om 22:49 schreef Bob Albrightson:
> Joop Stakenborg wrote:
> > 
> > Op zo 23-02-2003, om 13:21 schreef Bob Albrightson:
> > > Hello,
> > >
> > > I just pulled the hamlib 1.1.3 rpm and got the following error:
> > >
> > > [root@rake hamradio]# rpm -ihv hamlib-1.1.3-1.i386.rpm
> > > error: failed dependencies:
> > >       libhamlib-1.1.2.so   is needed by hamlib-1.1.3-1
> > >
> > > Looks like the dependency list is hosed.
> > >
> > 
> > Hi Bob,
> > 
> > I have cooked the rpm. Will have a look if I can fix it.
> > In the meantime, you can force-install it with 'rpm -i --nodeps'
> 
> I did that and there is another problem.  It appears that rigctl is
> trying to open libhamlib-1.1.2.so instead of libhamlib-1.1.3.so.  I
> haven't tried roctl yet...
> 

Darn, this needs to fixed for sure. Will have a go at it tomorrow.

> 73	de W1IF
> 
>  -bob
> 

Joop

Re: [Hamlib-developer] serial ports and hamlib

[Joop S. <pa...@de...>]

Op ma 24-02-2003, om 20:57 schreef Wilbert Knol:
> On Tuesday 25 February 2003 07:00, Joop Stakenborg wrote:
> 
> <snip>
> > If I remember correctly, someone on the xlog-discussion mailing list
> > reported blocking of the gui when using /dev/usb. This also happens when
> > using tlf. 
> 
> That was me. The interesting thing was that the hamlib rigctl program worked 
> perfectly through the USB port, but XLOG/TLF/GRIG didn't.
> 
> XLOG would grind to a halt, and, from memory, TLF would become errattic with 
> the QRG updates, complaining about time-outs. As a matter of interest: TLF 
> worked OK if I put a TNC on the USB port (for DX-Cluster spots), and have the 
> rig control on the serial port.
> 
> I had a look for time-out values using USBview, but couldn't see anything 
> obvious. If memory serves me, there were references to 50 ms
> 

Woops, I just noticed an inconsistency in the xlog source code. At
program startup, the polling frequency is set at 350 mS, but when hamlib
is activated through the preferences dialog, it is set to 200 mS, which
is too small.

Wilber, if you like we could do an experiment. In the xlog source code,
look for the ocurrence of:

hamlibtimer = gtk_timeout_add (350, (GtkFunction) get_riginfo, NULL);

in src/main.c and change the value of 350 to lets say 1000.

Also, in src/callbacks_preferencesdialog.c, look for:

gtk_timeout_add (200, (GtkFunction) get_riginfo, NULL);

There are 2 lines like this. Change 200 to 1000.

The recompile and see what it does. Maybe we are lucky.

> 
> Wilbert, ZL2BSJ
> 
> 

Regards,
Joop

Re: [Hamlib-developer] hamlib 1.1.3 rpm

[Bob A. <bo...@em...>]

Joop Stakenborg wrote:
> 
> Op zo 23-02-2003, om 13:21 schreef Bob Albrightson:
> > Hello,
> >
> > I just pulled the hamlib 1.1.3 rpm and got the following error:
> >
> > [root@rake hamradio]# rpm -ihv hamlib-1.1.3-1.i386.rpm
> > error: failed dependencies:
> >       libhamlib-1.1.2.so   is needed by hamlib-1.1.3-1
> >
> > Looks like the dependency list is hosed.
> >
> 
> Hi Bob,
> 
> I have cooked the rpm. Will have a look if I can fix it.
> In the meantime, you can force-install it with 'rpm -i --nodeps'

I did that and there is another problem.  It appears that rigctl is
trying to open libhamlib-1.1.2.so instead of libhamlib-1.1.3.so.  I
haven't tried roctl yet...

73	de W1IF

 -bob

Re: [Hamlib-developer] serial ports and hamlib

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

On Mon, Feb 24, 2003 at 07:00:29PM +0100, Joop Stakenborg wrote:
> If I remember correctly, someone on the xlog-discussion mailing list
> reported blocking of the gui when using /dev/usb. This also happens when
> using tlf. Both applications are using a polling frequency of around 350
> ms, which works okay with serial ports because the timeout is much lower
> (200 mS).

The 200mS is a _character_ timeout, ie. each byte has to be received
within 200mS of the previous one.

Now, let's do the math.
The communication is set to 1200 bauds, which is 120 byte/s using 8N1.
This allows 40 bytes per exange, since xlog/tlf poll ~3 times a sec.
Note: the link is full duplex, but most of the time the protocol is
half duplex.
This is still okay, but now, what if the rig is a bit slow at answering?
It may block the GUI and its event-handling loop.

That would be interessting to know at which speed the communication was
set. I don't see any reason why the USB serial driver would be slower.

I've made a silly program to measure rig_get_freq and rig_get_mode
in a loop:

    (fillods@charybde:tests)$ ./rig_bench 311
    Opened rig model 311, 'IC-706MkIIG'
    Backend version: 0.2, Status: Beta
    Serial speed: 19200 bauds
    Port /dev/ttyS0 opened ok
    Perform 100 loops...
    Elapsed: 5.120s, Avg: 19.532895 loops/s, 0.051196 s/loop
    port /dev/ttyS0 closed ok

> I guess I have to adjust the polling frequency when a usb device is
> used.

No, you shouldn't have to. However, that should be done with slow
serial rates.

Anyone here has an USB dongle to share his/her thoughts on the question?


Stephane

Re: [Hamlib-developer] serial ports and hamlib

[Wilbert K. <w....@ni...>]

On Tuesday 25 February 2003 07:00, Joop Stakenborg wrote:

<snip>
> If I remember correctly, someone on the xlog-discussion mailing list
> reported blocking of the gui when using /dev/usb. This also happens whe=
n
> using tlf.=20

That was me. The interesting thing was that the hamlib rigctl program wor=
ked=20
perfectly through the USB port, but XLOG/TLF/GRIG didn't.

XLOG would grind to a halt, and, from memory, TLF would become errattic w=
ith=20
the QRG updates, complaining about time-outs. As a matter of interest: TL=
F=20
worked OK if I put a TNC on the USB port (for DX-Cluster spots), and have=
 the=20
rig control on the serial port.

I had a look for time-out values using USBview, but couldn't see anything=
=20
obvious. If memory serves me, there were references to 50 ms

Anyway, it is quite possible that these problems are due to the hardware.=
 My=20
USB drivers stop talking to the USB hub built into my notebook, after a=20
random number of hours, and I have been unable to fix this.

I have gone back (from 2.4.20) to a 2.2.23 kernel, but the USB hassles=20
remain, which is a bummer, because my trusty notebook only has one serial=
=20
port.=20

For contesting, it's a toss-up between DX-Cluster and rig control support=
 :-(

I am toying with the idea of trying a PCMCIA RS232 card, if I can get my=20
hands on one.


Wilbert, ZL2BSJ

Re: [Hamlib-developer] hamlib 1.1.3 rpm

[Joop S. <pa...@de...>]

Op zo 23-02-2003, om 13:21 schreef Bob Albrightson:
> Hello,
> 
> I just pulled the hamlib 1.1.3 rpm and got the following error:
> 
> [root@rake hamradio]# rpm -ihv hamlib-1.1.3-1.i386.rpm 
> error: failed dependencies:
> 	libhamlib-1.1.2.so   is needed by hamlib-1.1.3-1
> 
> Looks like the dependency list is hosed.
> 

Hi Bob,

I have cooked the rpm. Will have a look if I can fix it.
In the meantime, you can force-install it with 'rpm -i --nodeps'

> 73	de W1IF
> 
>  -bob
> 
> 

Regards,
Joop PA4TU

Re: [Hamlib-developer] serial ports and hamlib

[Joop S. <pa...@de...>]

Op zo 23-02-2003, om 20:41 schreef Stephane Fillod:
> On Tue, Feb 11, 2003, Joop Stakenborg wrote:
> > > Hamlib should be okay, just pass the "-r /dev/usb/ttyUSBn" option to
> > > rigctl and friends, or rig_set_conf("rig_pathname", "/dev/usb/ttyUSBn")
> > > from your code.
> > 
> > What about the default timeout for the serial port?
> > Is it supported?
> 
> yes. I don't remember what was the acutal problem, but yes, there's a
> timeout field in the caps that can be set through rig_set_conf, or
> "-Ctimeout=500" using rigctl to set it to 500ms for example.
> 
> What was the problem again?
> 

If I remember correctly, someone on the xlog-discussion mailing list
reported blocking of the gui when using /dev/usb. This also happens when
using tlf. Both applications are using a polling frequency of around 350
ms, which works okay with serial ports because the timeout is much lower
(200 mS).

I guess I have to adjust the polling frequency when a usb device is
used.

> 
> Stephane
> 
> 

Thanks,
Joop

Re: [Hamlib-developer] IC-736 backend status and converter power

[Andrea B. <bo...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephane Fillod wrote:


> So far, I can only see RTS and DTR as a power source. Let me know if
> you see others.

This is an example: http://www.g3vgr.co.uk/civ.htm

I guess catering for RTS and DTR should cover most cases, but I remember 
seeing circuits (the one above is just an example) which used 3 
control-lines strung together as power source.


> Congrats for your upgrade! I haven't heard you on the French SSB
> contest "Coupe du REF" this week-end. Anyway, the propagation was not 
> at its best.

I have my doubts you'll hear me and my barefoot 736 connected to an 
11-year-old cb quarter wave ;-( Antenna upgrade is in my plans, but 
right now I'd just be happy to start operating in CW and I still have a 
few characters (punctuation and ligatures) to learn before that.

I'll get back here with the results of my tests once I get a free moment.

Thanks,
Andrea.

- -- 
Undergraduate student of Computer Science @ University of Bologna
Key fingerprint: 4037 9711 85C6 F9F9 A505  FA0A BB62 3A3C F7BA 9B13
ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+WhLzKhgqEyuO+p4RAtJ1AJ4wxHnJewGfR5ZoRc32rHHVcx/LRQCfRSPt
kLfPczDyLAlTTIlhAbaRJNg=
=Wnho
-----END PGP SIGNATURE-----

[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] Conflict with RIG_VFO_CURR and RIG_VFO_NONE

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

On Wed, Jan 08, 2003, Nate Bargmann wrote:
> As I'm working with the ft920 code to make it more robust, I am
> modifying rigctl to prompt for the VFO to read/set.  In so doing I am
> testing the return of parse_vfo for RIG_VFO_NONE.  Unfortunately, when I
> try to pass currVFO from rigctl, get_freq exits early as RIG_VFO_CURR
> and RIG_VFO_NONE are both defined in rig.h to 0!
> 
> How can this be rectified?  It seems that making RIG_VFO_CURR to be
> non-zero is the simplest answer.

okay, RIG_VFO_CURR has been allocated a non-zero value, it's in cvs.
Please let me know if it breaks anything for you. 
So far, with the new value, it's fine for me.

Cheers,
Stephane

Re: [Hamlib-developer] serial ports and hamlib

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

On Tue, Feb 11, 2003, Joop Stakenborg wrote:
> > Hamlib should be okay, just pass the "-r /dev/usb/ttyUSBn" option to
> > rigctl and friends, or rig_set_conf("rig_pathname", "/dev/usb/ttyUSBn")
> > from your code.
> 
> What about the default timeout for the serial port?
> Is it supported?

yes. I don't remember what was the acutal problem, but yes, there's a
timeout field in the caps that can be set through rig_set_conf, or
"-Ctimeout=500" using rigctl to set it to 500ms for example.

What was the problem again?


Stephane

Re: [Hamlib-developer] Rotator API

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

On Mon, Feb 17, 2003, Alexandru Csete wrote:
> I am currently adding rotator support to grig and I have a couple of
> questions to the rotator API. First, the rot_reset function needs an
> integer parameter besides the usual *rot structure. What is the purpose
> of this integer? The API says it's "The reset operation to perform" but
> what are the choices? Is there a "safe, universal value"?

So far, there's no such backend paying attention to this parameter. 
However, in the future, some backend will.
What about a safe ROT_RESET_ALL define ?

> Second, the rot_move function needs to know the speed, which can be
> between 1..100. Does the speed have a physical unit, or is the value
> specific to the back end?

This speed arg is broken. Let's fix it. 
First, it should not be specific to a backend, and next, it should have a
physical unit. What about a float for radian per second?
I don't have a computer-controlled rotator, so if anyone of you have
a better unit, please stand up.

And of course, the rotator caps are missing minimum and maximum speed
fields (which will depend on the unit).

Any idea?


Stephane

Re: [Hamlib-developer] IC-736 backend status and converter power

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

> >It isn't in Hamlib 1.1.3. However, I've just added it right now
> >in the cvs repository, so it will be part of future 1.1.4 if you
> >care to test it.
> Oh, good, I will! Thanks 8-)

It's in cvs, and there should be a http://hamlib.org/bleeding-edge/ snapshot
by tomorrow.

> BTW, RTS is not the only case: other converters use DTS or even a 
> combination of control lines as power source, so the option should be as 
> general as possible, both for the choice of the affected lines and for 
> the related radios (homemade converters for Yaesu use this trick, too).

So far, I can only see RTS and DTR as a power source. Let me know if
you see others. Here is how it works with rigctl for your IC-736:

	rigctl -vvvvvv -Crts_state=ON -m 320

There's also a config 'dtr_state' param. You can check them all with
the -L option. Let me know if this solves your powering problem.


> (*) considering that tomorrow is the first day I'm allowed to operate 
> with full privileges and the new callsign I guess pc-related activities 
> will have to share my brain-time somewhat ;-)

Congrats for your upgrade! I haven't heard you on the French SSB
contest "Coupe du REF" this week-end. Anyway, the propagation was not 
at its best.


73
Stephane

[Hamlib-developer] hamlib 1.1.3 rpm

[Bob A. <bo...@em...>]

Hello,

I just pulled the hamlib 1.1.3 rpm and got the following error:

[root@rake hamradio]# rpm -ihv hamlib-1.1.3-1.i386.rpm 
error: failed dependencies:
	libhamlib-1.1.2.so   is needed by hamlib-1.1.3-1

Looks like the dependency list is hosed.

73	de W1IF

 -bob

Re: [Hamlib-developer] IC-736 backend status and converter power

[Andrea B. <bo...@st...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephane Fillod wrote:


> It isn't in Hamlib 1.1.3. However, I've just added it right now
> in the cvs repository, so it will be part of future 1.1.4 if you
> care to test it.

Oh, good, I will! Thanks 8-)


> I'll try to come up with a patch, unless you want to provide yours.

By the time(*) I get up to speed on the architecture of the library and 
find a moment to write a decent patch, you'll have already coded it, so 
go ahead, I'll test the cvs and report back. If I get there first, I'll 
send it to you.

BTW, RTS is not the only case: other converters use DTS or even a 
combination of control lines as power source, so the option should be as 
general as possible, both for the choice of the affected lines and for 
the related radios (homemade converters for Yaesu use this trick, too).

73
Andrea.

(*) considering that tomorrow is the first day I'm allowed to operate 
with full privileges and the new callsign I guess pc-related activities 
will have to share my brain-time somewhat ;-)

- -- 
Undergraduate student of Computer Science @ University of Bologna
Key fingerprint: 4037 9711 85C6 F9F9 A505  FA0A BB62 3A3C F7BA 9B13
ICQ: 4905369 / JID: bo...@ja... / HAM: IZ4FHT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+VIo3KhgqEyuO+p4RAiNcAKDbk5znc22Efx5MCOuMN5zoOMYIIgCffxk7
ySaWYl3xPS5Avcpq3vP8QlU=
=4/37
-----END PGP SIGNATURE-----

Re: [Hamlib-developer] IC-736 backend status and converter power

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

On Tue, Feb 18, 2003, Andrea Borgia wrote:
> I'm trying to get rigctl to talk to my IC-736 but I can't get it to work
> so I wonder: is it really supported?

It isn't in Hamlib 1.1.3. However, I've just added it right now
in the cvs repository, so it will be part of future 1.1.4 if you
care to test it.

> ~From reading the sources of 1.1.3 I think it is, but I can't find out
> how to tell hamlib/rigctrl to toggle RTS always-on to supply power to my
> homemade converter, not even in the ml archives.

This is a good question, and interresting feature.
I guess if hardware handshake is not to be used, Hamlib should allow
RTS optional setting through some rig_set_conf parameter.
I'll try to come up with a patch, unless you want to provide yours.

73
Stephane