Hi Jim,

My first approach to this will be reading the 1+4+64 bytes at once (as a 69 bytes string), but then this will has a timeout issue with the *correct* packets and the reading will be slow, sum to that the fact the the timeout has different behavior in linux/mac vs. windows. Also if the radio as a tight timeout you will get in trouble.

The more precise control of the download reading just a few bytes at a time has proven being not efficient, so call Huston about a problem...

I'm coding a dev btech driver for the waccom case that may work in this case too by using the concept of the buffer (Dan has insisted on this in the past).

I will read the radio as expected and put *everything that looks like valid* on a temp var, re-requesting the suspected-of-being-bad segments before adding it to the buffer, then I will process that var to detect the headers and data; of course this approach has it's own problems we have to test & evaluate.

I'm working on it since yesterday, you will receive some test code as soon as I can get it completed.

73

All,

I am trying to read a new radio. Here is the problem.

A request for data is made like this.

52 1D 80 40

Then usually 68 bytes (4 header bytes and 64 data bytes) are returned like this:

57 1D 80 40 + {64 data bytes}

But every once in a while the radio will return 69 bytes (the command
byte is sent twice increasing the header to 5 bytes) like this:

57 57 1D 80 40 + {64 data bytes}

Got any advice how I can deal with this extra byte being introduced
randomly. The OEM software apparently has no problem handling this.

Jim
_______________________________________________
chirp_devel mailing list
chirp_devel@intrepid.danplanet.com
http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers

-- 
73 Pavel CO7WT.