[chirp_devel] Need help reading a radio.

[Jim Unroe]

On Sat, Jun 11, 2016 at 4:48 PM, Jim Unroe <rock.unroe at 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