3

I have a usb stick that communicates with a medical device. I am attempting to decode the communication. I have figured out the basic radio parameters (916.5MHz, ook, bit rate, preamble, sync words), but there is still some encoding I haven't figured out yet.

I can give the USB stick different destination device ids, and can see segments of the short (~12bytes) packet change. In fact, for each character of the 6-digit device id, I see 6 bits change in the packet, with a consistent mapping as follows:

"010101" => "0",
"110001" => "1",
"110010" => "2",
"100011" => "3",
"110100" => "4",
"100101" => "5",
"100110" => "6",
"010110" => "7",
"011010" => "8",
"011001" => "9"

So device id 123456 is encoded as "110001110010100011110100100101100110".

There are some other 6-bit sequences I see in the data as well, like:

001011 => ?
001101 => ?
101010 => ?
101100 => ?
011100 => ?

The second bit in each code seems to be a parity bit for the remaining 5 bits. The first bit seems special in some way as well, but I haven't figured it out. The four bits on the right are standard binary encoding for values 1-6. Those values also have the first bit set, which makes me think that when the first bit is not set, it turns on some alternate encoding for the right four bits.

Any ideas?

raaadio
  • 31
  • 2
  • 1
    Did you look at error correction codes such as Grey code ? It doesn't answer to your question about the meaning of extra signals but, it may explain how the code has been built (incrementally from a subset of elements). – perror Dec 23 '13 at 15:14
  • Similar to what @perror said, you may want to consider Hamming codes too. – Jason Geffner Dec 23 '13 at 16:37
  • Yes, I looked at error correction codes (though I hadn't seen Grey code before). I don't think it can be hamming code, since four bits of data would require more than 2 bits parity, if I understand hamming codes correctly (unlikely:). – raaadio Dec 23 '13 at 16:47
  • I didn't check exhaustively but it seems that every single element of your code is at a hamming distance of two (at least) from any other element. It might be a clue for discovering or invalidating new elements. It might be linked to the number of errors that is supported by your code. – perror Dec 23 '13 at 19:13

2 Answers2

1

This is not a complete answer yet, but perhaps it will be of assistance anyway. First, for every 6-bit code exactly 3 bits are set, strongly suggesting some kind of a 3-of-6 binary channel coding. I'm inferring the following rules:

  1. exactly 3 of the 6 bits must be set
  2. the last 3 bits must not all be the same value

Both of these would have valid reasons for channel coding because they'd assure that there are always at least two transitions (1-to-0 or 0-to-1) per symbol period, and therefore assist in synchronization and clock recovery. At first glance, it looked like Manchester encoding or Differential Manchester, but that does not seem to be the case, not least because it appears to be encoding at least 4 bits per 6-bit symbol.

If both those presumed rules are correct, there are 19 possible values (if only rule 1 is correct, there are 21 possible values). They're enumerated below in numerical order, followed by the symbol number, followed by the observed symbol meaning (I've assigned the observed but unknown symbols values of uA through uE; theoretically possible but unobserved symbols are marked as ?G through ?I):

000111 00 disallowed by rule 2
001011 01 uA
001101 02 uB
001110 03 ?G
010011 04 ?H
010101 05 "0"
010110 06 "7"
011001 07 "9"
011010 08 "8"
011100 09 uC
100011 10 "3"
100101 11 "5"
100110 12 "6"
101001 13 ?I
101010 14 uD
101100 16 uE
110001 17 "1"
110010 18 "2"
110100 19 "4"
111000 20 disallowed by rule 2

For the symbols"1" through "6" the low four bits are the encoded value 1-6 and the high two bits are the count of zeroes in the low four bits. It also works for ?I, uD, and uE if you give those the values of 9,10 and 12, respectively. However, that interpretation, does not work for the other values.

Edward
  • 2,521
  • 18
  • 25
1

I eventually figured this out. It's a hexadecimal based encoding. The remaining symbols I was stumped by were 'A' through 'F'. 

"010101" => "0",
"110001" => "1",
"110010" => "2",
"100011" => "3",
"110100" => "4",
"100101" => "5",
"100110" => "6",
"010110" => "7",
"011010" => "8",
"011001" => "9",
"101010" => "a",
"001011" => "b",
"101100" => "c",
"001101" => "d",
"001110" => "e",
"011100" => "f"
pschwamb
  • 111
  • 2