ValMetTelem
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