Thread: Re: [Hamlib-developer] serial ports and hamlib
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Stephane F. <f8...@fr...> - 2003-02-11 08:10:49
|
Hi Orv,
On Mon, Feb 10, 2003, Orv Beach wrote:
> Can someone take a look at the code, and let me know if hamlib will
> handle /dev/usb/ttyUSBnn? If not, it really ought to be put on the
> to-do list. A ham can never have too many serial ports on his ham shack
> box ;-)
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.
Note: your email or...@or... does not seem to be in the list of
subscribers of this list, and I had to manually approve your post.
Cheers,
Stephane
|
|
From: Joop S. <pa...@de...> - 2003-02-11 15:37:35
|
Op di 11-02-2003, om 09:09 schreef Stephane Fillod:
> Hi Orv,
>
>
> On Mon, Feb 10, 2003, Orv Beach wrote:
> > Can someone take a look at the code, and let me know if hamlib will
> > handle /dev/usb/ttyUSBnn? If not, it really ought to be put on the
> > to-do list. A ham can never have too many serial ports on his ham shack
> > box ;-)
>
> 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?
>
> Note: your email or...@or... does not seem to be in the list of
> subscribers of this list, and I had to manually approve your post.
>
>
> Cheers,
> Stephane
>
>
Bye,
Joop
|
|
From: Stephane F. <f8...@fr...> - 2003-02-23 22:32:33
|
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
|
|
From: Joop S. <pa...@de...> - 2003-02-24 18:01:32
|
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
|
|
From: Stephane F. <f8...@fr...> - 2003-02-24 20:56:07
|
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
|
|
From: Alexandru C. <al...@ph...> - 2003-02-25 10:11:23
|
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 |
|
From: Wilbert K. <w....@ni...> - 2003-02-24 19:57:08
|
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 |
|
From: Joop S. <pa...@de...> - 2003-02-24 21:51:45
|
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 |
|
From: Wilbert K. <w....@ni...> - 2003-02-24 22:17:02
|
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 |
|
From: Stephane F. <f8...@fr...> - 2003-02-24 22:37:38
|
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 |
|
From: Stephane F. <f8...@fr...> - 2003-02-27 23:01:16
|
On Tue, Feb 25, 2003, Wilbert Knol wrote: > Yes, if you have time, I would appreciate a CVS snapshot . The office > fire-wall stops me from using CVS. I know what it is. There you are, http://hamlib.org/bleeding-edge/hamlib-1.1.4cvs-030227.tar.gz > > sure, very nice idea. Easier to say than to do. Maybe we should borrow > > some configure.ac magic from alsa or other project. > > I suspected it would not be too easy. But it is one of the features I really > like in ALSA. It certainly cuts down compilation time. yep, one day, when more important API design will be firmed up first. (contribution welcome anyway ;) 73 Stephane |
|
From: Stephane F. <f8...@fr...> - 2003-02-26 23:41:58
|
On Tue, Feb 25, 2003 at 11:13:53AM +0100, Alexandru Csete wrote: > 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. kind of poll in main loop? > 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. nope, the RPC backend won't be better either. The problem here is latency of synchronous protocols in general (command ... delay ... response). One solution is to make Hamlib asynchronous wrt to protocol handling, using either signal handler or poll in a main loop. This way you don't block waiting for the response. Event driven application is a nice concept, but not so easy to implement because the need of a state machine, and your main loop is nothing else but a degenerated "scheduler". The other solution, more common, is to make the application multi-threaded (or at least multi-programmed). This way, the GUI main loop is not blocked by the delayed reponse. However, the developer has to pay attention to proper locking within shared data structures... Now, I cannot see Hamlib to be asynchronous wrt transaction type commands in the forseable future... Comments? Cheers, Stephane |
|
From: Joop S. <pa...@de...> - 2003-02-27 16:19:55
|
Op do 27-02-2003, om 00:36 schreef Stephane Fillod: > The other solution, more common, is to make the application > multi-threaded (or at least multi-programmed). This way, the GUI main > loop is not blocked by the delayed reponse. However, the developer has to > pay attention to proper locking within shared data structures... > Without using multi-threading, you could fork a copy of the main program and have data transactions take place in the background. The main program listens on a pipe. Should not be too difficult.... > Now, I cannot see Hamlib to be asynchronous wrt transaction type > commands in the forseable future... > > Comments? > > > Cheers, > Stephane > > Regards, Joop |
Thanks for helping keep SourceForge clean.
X