I'm looking into why the test message fails the CRC (possibly this is intentional to prevent rebroadcast by other towers) and why the stolen vehicle tracking pulses on the YouTube example require correction on the Function Code part of the data most of the time.
It appears the Function 4 test message was designed to intentionally fail the CRC. I assume this is to prevent test messages from being rebroadcast by other towers. The CRC for the test message begins with a couple "1" bits and then trails off into fourteen "0" bits. A correct CRC would appear to be F92D if I did the math correctly rather than C000. It appears this message is broadcast by the towers to troubleshoot tower related issues. Reception of a Function 4 test message (with the three tones) is therefore likely an indication of tower related problems.
As for the stolen vehicle tracking pulses on the YouTube example, I find it rather unusual that every decode has to be corrected and none pass automatically. It appears what is being corrected in most instances is the forth bit in the function code (from a 0 to a 1). The function code that is being transmitted by the stolen vehicle unit is 1110 however for the CRC to match it must be corrected to 1111. I looked at the waveform of a strong pulse and the Function Code decodes out to 1110 (the "0" bit clearly being 1.5 cycles at 1623 Hz). The frequency is a little on the low side (1623 Hz instead of 1800 Hz) however there is a clear transition from 1200 Hz to 1623 Hz and a transition from the one cycle "1" bit to the one-and-one-half cycle "0" bit. I'm not sure what to make of this currently however thought it was worthy of mention.
One additional note of interest with regards to the vehicle tracking pulses, a total of one hundred extra "0" bits are broadcast at the end of each tracking pulse. I assume this is to assist the tracking unit to more accurately determine the signal strength and direction to the stolen vehicle.
Shawn
Last edited: