ValMetTelem

From NebarnixWiki
Revision as of 07:30, 31 March 2016 by NebarnixWikiSysop (talk | contribs) (New Page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Problem Statement

I found a steady stream of FSK activity on 452.625Mhz, 452.825Mhz, and 453.150Mhz. I looked this up and found it to be associated with the Phoenix area bus system. I wanted to know what exactly was being transmitted, maybe I can track the bus and never be late again?

Data Format

Using GNU-radio and baudline, I discovered that these FSK signals have a deviation of 4800Hz, and a bitrate of also 4800Hz. I constructed a demodulator and bitsync in GNUradio, and discovered the following packet structure. It is easy to see that this is some sort of manchester encoding as there is a transition during every 2 bis and there are no consecutive bits within the groups.

1 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 10 10 01 01 01 10 01 10 01 10 01 01 01 10 01 01 10 10 10 01 10 10 10 01 10 10 10 10 10 10 
(the rest) 101010101010010101011001101001010101100110100101010110011010010101011001101001010101100110100101010110011010010101011001101001010101100110100101010110011010010101011001101001010101100110100101010110011010010101011001101001010101100110100101010110011010010101011001101001010101100110100101010110011010010101011001101001010101100110100101010110011010010101011001101001010101100110100101010110011010011001101010010101011001011010010110011001100101101001011010010

Decoding this using standard manchester (1 => 10 and 0 => 01) yielded some really funny patterns that did not make sense to me. Who uses a preamble like this?! The following is my best attempt to break the code into 8 bit chunks at boundaries that appeared to make sense... But the pattern does not make sense. This stumped me for a while...

00110011 00110011 00110011 00110011 00110011 00110011 00110011 00110011  10101011  11111111 11111111  10000000 01111111 11011000 11100000 11101111 1001 0011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 00001011 10111010 11100111 10101011 00110011

It is clear there are far too many transitions still left in the data. You can just see it. Then suddenly it dawned on me. This is DIFFERENTIAL Manchester encoding! We can actually convert manchester decoded data to differential manchester data by looking at the bit vs the previous bit. Bit_previous == Bit_Current? Yes=1, No=0.

After we apply this differential transform, we arrive at data that makes much more sense.

10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101010 01111110 01101001 10011000 00000000 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 10001110 11110010 00110101 01111110 1010101
This is:
AA AA 7E 69 98 00 8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E8E F2 35 7E

Confirmation of data structure made by grabbing a second packet:

8 bytes of 0xAA, then a packet start flag of 0x