From: Stephane F. <f8...@fr...> - 2009-12-21 19:27:54
|
Hi Jeff, Mon, Dec 14, 2009 at 01:50:55PM -0700, Jeff Steinkamp skribis: > I am having a bit of difficulty dealing with COM port timeouts. If for > some reason the radio is turned off or losses power while still > connected to hamlib, it appears that the library ( windows dll in this > case) is locking up. In my software I do detect the timeout ( -5) when I > request a frequency or mode read, and at that point I terminate the > polling process and send a rig_cleanup and rig_close command, but > something is still processing the the library and eats up 98% of the CPU. Is the problem specific to a rig model? Is the problem specific to Windows? I tried the FT-100 backend under Linux, without a real rig, but real serial port. The timeout is at 100 ms. No strange termination. But I remember seeing this problem, was it with a USB<->serial cable? Do you communicate with the radio using a USB<->serial cable? > I can demonstrate this with Rigctl by connecting to the radio, issue a > read frequency command, get a frequency in return, then power down the > radio, and issue another read frequency command. At this point rigctl > locks up and I get nothing in return to indicate a loss of serial > communications to the rig. > > So, my question is, how do we deal with this situation in hamlib?? To me, this sounds like a bug in Hamlib. It can be a bug in the OS, but in the latter case, Hamlib should work around it anyway. Can everybody check on their rigs the scenario described by Jeff, and tell us if you can reproduce it? Some potential suspects: * USB<->serial cable * the win32 termios emulation layer (lib/termios.c) * hardware serial handshake * ?? -- Stephane - F8CFE |