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
El 11/06/16 a las 16:48, Jim Unroe via chirp_devel escribió:
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