[chirp_devel] Need help reading a radio.

[Pavel Milanes (CO7WT)]

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 at intrepid.danplanet.com
> http://intrepid.danplanet.com/mailman/listinfo/chirp_devel
> Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
>

-- 
73 Pavel CO7WT.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://intrepid.danplanet.com/pipermail/chirp_devel/attachments/20160613/ab0e3688/attachment-0001.html