From: Chris B. <ry...@cr...> - 2010-03-27 13:14:31
|
To recap: I have an FT747GX with a known working 232-serial converter that works with the MixW program in windows. rigctl in debian sid linux talks to the rig as evidenced by a CAT icon flashing on its display, but no commands worked and attempts to retrieve the status timed out with 0 bytes received. After a bit of fiddling around to make absolutely sure that the pc was really sending the bits (and only the bits) the terminal driver was asked to send, I borrowed my daughter's storage scope and captured/compared the RS232 data as sent by MixW and rigctl. MixW polls at intervals, and the "return status" command 5-byte string 00 00 00 00 10 was being sent with *no* inter-byte gap. The 747 manual specifies an inter-byte delay of 50 - 200mS and hamlib defaults to 50mS. I used rigctl command line parameter -C write_delay=0 and now the 747 interprets command correctly (but see below). I can use F, M, T, etc ok. By adjusting the delay parameter, I can see the 747 is happy up to a delay of 18mS and fails with 19mS or greater. I had previously contacted the developers of MixWl who couldn't recall a particular problem with the 747 beyond "the timing is tricky"; I think it was a while ago. However, on rigctl start, and for any command that asks for data from the 747 I now get a timeout error after 344 bytes - just one short. The 747 is specified as returning 345 bytes for any sort of get status operation (it only has the one command for this). Here's a typical -vvvvv output (the eol ........... wrapped as I wrote this mail) TX 5 bytes 0000 00 00 00 00 10 ..... <-this is the get status command 0000 00 00 07 03 00 00 13 00 00 07 03 00 00 08 00 08 0010 00 07 00 00 00 10 00 00 08 10 00 10 00 00 00 10 0020 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 0030 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 0040 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 0050 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 0060 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 0070 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 0080 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 0090 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 00a0 00 10 00 10 00 00 00 10 00 10 00 10 00 00 00 10 00b0 00 10 00 10 00 00 00 10 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0150 00 00 00 00 00 00 00 00 ........ read_block: timedout after 344 chars I can confirm that the first byte is present - it contains state of panel indicators, eg if I press the Display lock button I see the LSB of the first byte change as follows 0000 01 00 07 03 00 00 13 00 00 07 03 00 00 08 00 08 Unfortunately, the last few bytes in the 345 block are undefined so I can't test them to see if something is missing at the end. Just in case, I have set the timeout (rigctl -C) for the whole operation to 5 seconds which makes no difference as expected (345 bytes hould take about 800mS; confirmed at a gross level with a scope on the serial data out from the 747) Any ideas for further investigation? 73 Chris g3wie |