From: Stephane F. <f8...@fr...> - 2010-03-28 10:37:23
|
Nate Bargmann skribis: > BTW, Chris, Stephane just added two patches that affect the 747. Check > out SVN or grab the daily snapshot from: > > http://n0nb.users.sourceforge.net > > around 1030z tomorrow. You understand why I did that before going to bed yesterday ;-) > The difference between MixW and Hamlib may well be the difference in > why MixW works and Hamlib didn't. Of course we can't examine the MixW > code, but it's possible that it is not as strict looking for the byte > count on the wire as Hamlib. That's just conjecture on my part. I can't remember Chris whether you said what was the snooped block length when using MixW. On top of Mark's suggestions for unexpected protocol, it can also be due to a non-standard firmware. It can be the systematic pacing command right before the status report which confuses the rig. That's why I moved the pacing command into ft747_open() in my patch yesterday, which is then done once for all. In that patch, the write_delay has been changed from 50 ms to 5 ms. Is it the most appropriate value? As a bonus, there's also support for split operation in the svn commit. > The worst case is what do we do if we find that some rigs report 344 > bytes and others 345? This is what I did in ft747_get_update_data(): read_block() of 344 bytes with normal timeout, then read_block() of 1 additional byte with a 100 ms timeout and doesn't make whole transaction to fail if that byte is missing. Now, giving it more thought, I'm worried by the 790 ms latency. What about reading only the first 23 bytes (rest is memory content), hence shortening latency, but before sending the Update opcode, doing a serial flush? The serial flush should take care of dropping the unread mem status from a previous request. What do you think about it? 73 -- Stephane - F8CFE |