My point was meant to be that I still think those are not being properly parsed. Although the current parsing you are doing is certainly useful, there are things about it that do not make sense (but do not affect its usefulness). I think if properly parsed, they would make more sense on paper.
Assuming the newer versions of SDRTrunk still provide the reply code parsing for each line, you will notice that for the WNVD283 Aurora, IL tower mentioned that the last two characters of the reply code are 83 or 8-3 which matches your results. I've always just looked at the last two characters of the reply code provided automatically by SDRTrunk to differentiate between towers.
As 1.) tracking pulses, 2.) site IDs, 3.) tower commands and 4.) speed ups all have three of their address bits always set to 0, the assumption back in the day was that these specific commands were all using the exact same parsing. When it was verified the correct parsing had been determined for tracking pulses and then later for speed ups, it was logical to conclude site IDs were using the same parsing as they also had the same three bits always set to 0.
All other LoJack commands (tower test, deactivate, activate, quiet, alternate deactivate, etc.) utilize all 28-bits in their addresses (none of the bits are always set to 0) so these commands use a second different decoding scheme other than the one used for 25-bit tracking pulses and speed ups.
So, it is known there are at least two separate parsings of address bits being used by the LoJack system (one based around 25-bits and the other based around 28-bits).
It is certainly possible that the 25-bits in site ID addresses are being parsed yet a third way and not following the established parsing scheme being used to decode the 25-bits in tracking pulses and speed ups.
To keep things simple, SDRTrunk provided a verified reply code parsing for 25-bit addresses and a verified HEX parsing for 28-bit addresses. The 28-bit HEX parsing scheme used was deteremined based off actual screenshots of the working LoJack system provided in manuals to the FCC for functional equipment.
This is what I know. If anyone discovers something new regarding LoJack it would be interesting to look at it before it is turned off.
There is another part of the VHF LoJack system that nobody has ever decoded/parsed referred to as uplink transmissions (transmitted by vehicle transponders). These are transmitted at around 100 bits per second for a duration of 1.8 seconds. Most of these transmissions have to do with the early warning system and vehicle transponders acknowledging activations and deactivations with the LoJack towers. At this point, it's not worth the hassle of attempting to decode these however I thought it was worth a passing mention.
