[chirp_devel] Need help reading a radio.
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
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
On Sat, Jun 11, 2016 at 4:48 PM, Jim Unroe rock.unroe@gmail.com wrote:
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
There is probably a more elegant approach, but here is what I did and it seems to work very well.
def _recv(radio, addr, length=BLOCK_SIZE): """Get data from the radio """ # read 4 bytes of header hdr = _rawrecv(radio, 4)
# the radio randomly sends out an extra command byte c, a, l = struct.unpack(">BHB", hdr) if hdr[0:2] == "WW" and a != addr: # extra command byte detected # throw away the 1st byte and add the next byte in the buffer hdr = hdr[1:] + _rawrecv(radio, 1) LOG.debug(util.hexprint(hdr))
# read 64 bytes (0x40) of data data = _rawrecv(radio, (BLOCK_SIZE))
# DEBUG LOG.info("Response:") LOG.debug(util.hexprint(hdr + data))
c, a, l = struct.unpack(">BHB", hdr) if a != addr or l != length or c != ord("W"): _exit_program_mode(radio) LOG.error("Invalid answer for block 0x%04x:" % addr) LOG.debug("CMD: %s ADDR: %04x SIZE: %02x" % (c, a, l)) raise errors.RadioError("Unknown response from the radio")
return data
What the above does is reads 4 bytes which should normally be the header bytes. These 4 bytes are then "unpacked" so I have the address.
Then I test for the double command byte. The MEM_SIZE is 0x8000 so just looking for "WW" (\x57\x57) is not good enough. If the addresses also don't match, then there is a very near 100% chance that what was read was caused by the extra command byte.
If the above check is "True" then we must have retrieved a double command byte and we are short 1 byte of the header. So then we throw away the first "W" and at the same time receive 1 more byte to complete the header.
If the above check is "False" then nothing special needs to be done.
From this point the remaining 64 data bytes are read and everything
continues normally.
Jim KC9HI
participants (2)
-
Jim Unroe -
Pavel Milanes (CO7WT)