How to decode Lojack?

[ScannerSK]

Hello,

I tested out the crc and found an error in the CRC value for Function value 2. It should be AEC8 hex...

73 Eric

Eric,

I think my eyes begin to glaze over when I think about CRC. I'm glad you have an understanding on this portion of the signal. By testing the CRC, were you able to come up with the same 8-bits contained in the CRC on your own by plugging the 32-bits contained in the FCN and Address fields into an equation of sorts? Just curious...

Shawn

 

[EricCottrell]

Eric,

I think my eyes begin to glaze over when I think about CRC. I'm glad you have an understanding on this portion of the signal. By testing the CRC, were you able to come up with the same 8-bits contained in the CRC on your own by plugging the 32-bits contained in the FCN and Address fields into an equation of sorts? Just curious...

Shawn

Hello,

CRC is not too difficult as it uses Exclusive-OR arithmetic. I have figured out other over-the-air formats. The main problem is getting enough samples that have single bit changes in the data to get the bit differences in the crc. Once enough changes are gathered, then the pattern can be determined, as the differences are only bit shifts and Exclusive-OR of the exponent value. I determined the CRC was backwards because the bit shifts were in the opposite direction.

I wrote a simple filter program that reads in the binary data file from SDRTrunk and outputs the timestamp and decoded data. It only outputs the address and function data if the crc matches. I let SDRTrunk run for about 24 hours and got a couple of C function codes, so the CRC table is correct. I can read the filter output into a spreadsheet program and sort the data. I had 60,533 good decodes out on the 67,427 frames received. I hear stations in all eight time slots, but only two are strong enough to be solidly decoded.

73 Eric

 

[ecps92]

Eric if it helps to aim at your nearest tower, here is a google earth of the Lo-Jack tower Locations

Hello,

CRC is not too difficult as it uses Exclusive-OR arithmetic. I have figured out other over-the-air formats. The main problem is getting enough samples that have single bit changes in the data to get the bit differences in the crc. Once enough changes are gathered, then the pattern can be determined, as the differences are only bit shifts and Exclusive-OR of the exponent value. I determined the CRC was backwards because the bit shifts were in the opposite direction.

I wrote a simple filter program that reads in the binary data file from SDRTrunk and outputs the timestamp and decoded data. It only outputs the address and function data if the crc matches. I let SDRTrunk run for about 24 hours and got a couple of C function codes, so the CRC table is correct. I can read the filter output into a spreadsheet program and sort the data. I had 60,533 good decodes out on the 67,427 frames received. I hear stations in all eight time slots, but only two are strong enough to be solidly decoded.

73 Eric

 

[ScannerSK]

Hello,

CRC is not too difficult as it uses Exclusive-OR arithmetic. I have figured out other over-the-air formats. The main problem is getting enough samples that have single bit changes in the data to get the bit differences in the crc. Once enough changes are gathered, then the pattern can be determined, as the differences are only bit shifts and Exclusive-OR of the exponent value. I determined the CRC was backwards because the bit shifts were in the opposite direction.

I wrote a simple filter program that reads in the binary data file from SDRTrunk and outputs the timestamp and decoded data. It only outputs the address and function data if the crc matches. I let SDRTrunk run for about 24 hours and got a couple of C function codes, so the CRC table is correct. I can read the filter output into a spreadsheet program and sort the data. I had 60,533 good decodes out on the 67,427 frames received. I hear stations in all eight time slots, but only two are strong enough to be solidly decoded.

73 Eric

Great work! If you could use a data sample from my location just let me know. I could record a number of hours and send it in spreadsheet format. I receive strong LoJack data bursts from two separate towers every 64 seconds.

73 Shawn

 

[ScannerSK]

Hello,

The A in the middle makes me think this is the address of the unit in Hex format. 28 bits is seven hex digits.

73 Eric

Eric,

I ran across some interesting documentation today which may support the idea of seven hex digits. This documentation is for CarSearch which appears to have been merged into LoJack. It's not entirely clear whether LoJack currently uses this same formatting or if this applied only to a now defunct CarSearch product.

Search for "seven-character" in this article

"If Activate is chosen, the user interface will accept a seven-character activation code and a five character reply code." "If Deactivate is chosen, the user interface will accept a seven-character deactivation code."

I wonder if each character of the reply code is based on 5-bits (allowing the characters 0-9 and A-Z excluding B, I, O, Z) while each character of the activate/deactivate code is based on 4-bits?

73 Shawn

 

[DSheirer]

I added Eric's CRC checks into sdrtrunk and will post a build later today. I'm still testing a patch for out of memory errors that other users are experiencing.

Eric: I had to invert your CRC polynomial and each of the bit checksums to work with the way that I apply the values against the message in sdrtrunk.

The check function will repair 1 and 2 bit errors in the message and show as CORRECTED.

I ran the latest recording ( the one with the tones ) against the decoder and this is the output:

 07:22:46.554 DEBUG d.lj1200.LJ1200Message - PASS:01010101000011111100011011011010110010110011000010000111110010100001000001111100
 07:22:46.695 DEBUG d.lj1200.LJ1200Message - PASS:01010101000011111100011011111110001001010111011101011100101111011010000111101100
 07:22:47.295 DEBUG d.lj1200.LJ1200Message - PASS:01010101000011111100011011011010110010110011000010000111110010100001000001111100
 07:22:47.297 DEBUG d.lj1200.LJ1200Message - CORR:01010101000011111101001011110010001010100001100001110101010001110100111010111100
 07:22:47.299 DEBUG d.lj1200.LJ1200Message - PASS:01010101000011111110010010111001100000110110110110111000111100001100100011010111
 07:22:48.546 DEBUG d.lj1200.LJ1200Message - PASS:01010101000011111011010011010101001011010001111111100011111111111000001101111000
 07:22:55.995 DEBUG d.lj1200.LJ1200Message - FAIL:01010101000011110100000001000000010000000100000011001000000000001100000000000000
 07:23:03.145 DEBUG d.lj1200.LJ1200Message - FAIL:01010101000011110100000001000000010000000100000011001000000000001100000000000000

What's interesting is that the data burst that precedes each of the three tones fails the CRC check. It's the same message repeated 3 times over (only two good decodes in my example above). I wonder if that is an actual transponder that's been activated. Those tones would provide a nice stable signal for Direction Of Arrival measurements in the receivers. But, if the CRC fails, maybe they're using a different polynomial for the transponder bursts.

Denny

 

[ScannerSK]

I added Eric's CRC checks into sdrtrunk and will post a build later today....

What's interesting is that the data burst that precedes each of the three tones fails the CRC check....

Maybe they're using a different polynomial for the transponder bursts.

Denny

I just downloaded the new version of sdrtrunk. It's wonderful!

While thumbing through the 200 to 300 pages of documentation on the CarSearch product (which mentions seven-character activate/deactivate codes) I also noticed numerous references to test tones being broadcast. I'm thinking the latest audio example mentioned with the sets of tones (from Jan. 2004) is from the old system referred to as CarSearch. This would explain why the CRC fails.

I just ran the YouTube example through the latest sdrtrunk build and it shows as CORRECTED on examples when the signal is strong so it appears broadcasts from the tower have the same structure/format as the stolen vehicle transponder units.

Shawn

 

[DSheirer]

New sdrtrunk build posted to the downloads page (sdrtrunk_20141205_1109.zip)

Denny

 

[ScannerSK]

CRC

After several hours, all the decodes which have occurred during actual data bursts show as CORRECTED or PASS with one exception. I have a function 0 message that shows as FAIL CRC which occurred in the middle of a strong data burst.

10:51:27 LJ-1200 FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1F04] 01010101000011111011101111110101000000100111100001101110101010100001111100000100

Just a heads up should we notice all function 0 messages show up as FAIL CRC.

All the other FAIL CRC messages have occurred outside of actual data bursts.

Shawn

 

[DSheirer]

After several hours, all the decodes which have occurred during actual data bursts show as CORRECTED or PASS with one exception. I have a function 0 message that shows as FAIL CRC which occurred in the middle of a strong data burst.

10:51:27 LJ-1200 FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1F04] 01010101000011111011101111110101000000100111100001101110101010100001111100000100

Just a heads up should we notice all function 0 messages show up as FAIL CRC.

Shawn

For now, I'm showing all detected messages in the messages tab, pass, fail, or corrected, so that none of them are thrown away for failing the CRC. Errant decodes (noise) may/will also show in the list.

 

[EricCottrell]

Hello,

I will do a run with the new version over the weekend and check it against my program.

Single bit errors are pretty safe to correct, but correcting double bit errors maybe pushing it a little too far.

73 Eric

 

[ScannerSK]

For now, I'm showing all detected messages in the messages tab, pass, fail, or corrected, so that none of them are thrown away for failing the CRC. Errant decodes (noise) may/will also show in the list.

That's a good idea. For now, I'm watching to see if the identical function 0 address appears again later in the day as a FAIL CRC.

For some odd reason there is a business using P25 handheld radios on 173.075 in my area so it could have been due to interference.

Shawn

 

[ScannerSK]

After several hours, all the decodes which have occurred during actual data bursts show as CORRECTED or PASS with one exception. I have a function 0 message that shows as FAIL CRC which occurred in the middle of a strong data burst.

10:51:27 LJ-1200 FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1F04] 01010101000011111011101111110101000000100111100001101110101010100001111100000100

Just a heads up should we notice all function 0 messages show up as FAIL CRC.

All the other FAIL CRC messages have occurred outside of actual data bursts.

Shawn

The same function 0 address was just rebroadcast again from the tower. Notice this time however that it has a different LRC and CRC than it did four hours ago.

14:56:47 LJ-1200 FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [EF] CRC [1F2D] 01010101000011111011101111110111000000100111100001101110101010100001111100101101

This was the third message in the data burst which consisted of nine messages.

I wonder why the tower would send a different LRC and CRC when the function code and address remain unchanged? I wonder whether LRC (computer control) is somehow incorporated into the CRC at least for function code 0 messages?

Notice the change in the bits between the first message and the second message. Four different bits changed from 0 to 1.

Shawn

 

[ScannerSK]

While thumbing through the 200 to 300 pages of documentation on the CarSearch product (which mentions seven-character activate/deactivate codes) I also noticed numerous references to test tones being broadcast. I'm thinking the latest audio example mentioned with the sets of tones (from Jan. 2004) is from the old system referred to as CarSearch. This would explain why the CRC fails.

Scratch the above statement! This LoJack system is full of surprises.

This morning I captured the same identical three data bursts followed by the same three steady tones as was recorded back in 2004. So, apparently I was incorrect and the signal with the three tones is part of the LoJack system after all.

Every bit of the three data bursts I received this morning matched exactly the recording made in Jan. 2004 by another member of the forum. I was considering the possibility of these being activation signals until I noticed the three bursts matched exactly the signal received in 2004 bit for bit (same VRC, LRC, FCN Code, Address and CRC).

The only guess I have currently on what this signal may be used for is for some type of synchronization by the LoJack towers.

The following is a brief timeline showing where the three data bursts with accompanying tones occurred in relation to the normal data bursts I receive from two towers.

7:05:11 AM Tower 1 - regular burst
7:05:19 AM Tower 2 - regular burst
7:05:42 AM Data burst with three tones
7:06:15 AM Tower 1 - regular burst
7:06:32 AM Tower 2 - regular burst
7:06:34 AM Data burst with three tones
7:07-7:09 AM = Only regular tower bursts
7:09:27 AM Tower 1 - regular burst
7:09:35 AM Tower 2 - regular burst
7:09:53 AM Data burst with three tones

The three tones are as follows: 1st = 1800 Hz for approx. 2.687 seconds, 2nd = 1200 Hz for approx. 2.015 seconds and 3rd = 900 Hz with a possible second tone at 1500 Hz for approx. 2.015 seconds. There is actually a 4th quick burst of 1200 Hz for approx. 0.032 seconds at the end.

The three data bursts with tones all had a very strong signal strength and certainly originated from a tower rather than from a vehicle.

Shawn

 

[EricCottrell]

Hello,

I notice transmissions take a short pause right around Midnight UTC. Sometimes the pause will last until 00:01:04 UTC.

The address field with a function code of 1 does not appear to be an address directed to a mobile unit. This was mentioned before in this thread.

The upper 16 bits are different for each transmitter I hear. There are 8 possible transmission slots and the bits are in the same slot for days. I can receive ten transmitters in Eastern MA, RI, and NH.

030F or 01CE depending on the beam position
829E
029E
049E or 80CE depending on the beam position
019E
809E
849E
839E

I assume xx9E is MA, xxCE is NH (beam is towards the north), and xx0F is RI (beam is towards the south).

The next 4 bits are either 3, 7, B, or F. The lower two bits of the nibble are always set.

I noticed I will eventually receive most of the possible values for the lower 8 bits if I log for a long while.

73 Eric

 

[ScannerSK]

I notice transmissions take a short pause right around Midnight UTC. Sometimes the pause will last until 00:01:04 UTC.

Good catch! I just looked at my data from today and see the same thing occurred here at 5:00 PM MST (UTC Midnight). The second tower transmitted at 4:59:28 and then there was a two minute gap until 5:01:28 when the first tower transmitted.

Possibly the towers synchronize to the atomic clock.

The upper 16 bits are different for each transmitter I hear.

Here in Colorado the upper 16 bits appear as either 025F or 815F for function 1 addresses.

73 Shawn

 

[PiccoIntegra]

I'm getting 80FE for Collin County TX, and I believe 84FE is for the Downtown Dallas site. Those are the only two I can receive.

 

[ScannerSK]

I completed analyzing all the data bursts from Friday evening through Saturday evening (21 hours worth). During this time I received the following function codes from actual data bursts: 0, 1, 2, 3, 4, C.

The only valid Function C address which appeared during this entire time period was for 6A03C28 which was transmitted by both towers at my location.

I also had one Function C which occurred in the middle of a data burst however showed as FAIL CRC.

FAIL CRC FUNCTION [C] ADDRESS [BB65C1D] VRC [30] LRC [E8] CRC [D914]
01010101000011110000110000010111001110111000001110100110110111011101100100010100

Function 2 was noted to occur during the three data bursts which were followed by the three steady tones. All of these bursts show as FAIL CRC.

FAIL CRC FUNCTION [2] ADDRESS [0013020] VRC [02] LRC [02] CRC [C000]
01010101000011110100000001000000010000000100000011001000000000001100000000000000
FAIL CRC FUNCTION [2] ADDRESS [0013020] VRC [02] LRC [02] CRC [C000]
01010101000011110100000001000000010000000100000011001000000000001100000000000000
FAIL CRC FUNCTION [2] ADDRESS [0013020] VRC [02] LRC [02] CRC [C000]
01010101000011110100000001000000010000000100000011001000000000001100000000000000

Every message which contained a Function Code of 0 during this time period always appeared as FAIL CRC. There were 22 examples during the course of about 21 hours or approx. one per hour. Each of the 22 examples below was taken from a different data burst (most occurring in the middle of the data burst). Notice all the similar addresses.

FAIL CRC FUNCTION [0] ADDRESS [55143AC] VRC [9B] LRC [AF] CRC [1E00]
01010101000011111101100111110101000000110101110000101000101010100001111000000000
FAIL CRC FUNCTION [0] ADDRESS [55143AC] VRC [9B] LRC [AF] CRC [1E0C]
01010101000011111101100111110101000000110101110000101000101010100001111000001100
FAIL CRC FUNCTION [0] ADDRESS [55143AC] VRC [9B] LRC [AF] CRC [1F4C]
01010101000011111101100111110101000000110101110000101000101010100001111101001100
FAIL CRC FUNCTION [0] ADDRESS [55143AC] VRC [9B] LRC [AF] CRC [1FC9]
01010101000011111101100111110101000000110101110000101000101010100001111111001001
FAIL CRC FUNCTION [0] ADDRESS [55143AC] VRC [9B] LRC [EF] CRC [1E48]
01010101000011111101100111110111000000110101110000101000101010100001111001001000
FAIL CRC FUNCTION [0] ADDRESS [551C3AC] VRC [9B] LRC [AF] CRC [1E01]
01010101000011111101100111110101000000110101110000111000101010100001111000000001
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1EA1]
01010101000011111011101111110101000000100111100001101110101010100001111010100001
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1ECC]
01010101000011111011101111110101000000100111100001101110101010100001111011001100
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1F41]
01010101000011111011101111110101000000100111100001101110101010100001111101000001
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1F81]
01010101000011111011101111110101000000100111100001101110101010100001111110000001
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [AF] CRC [1FC7]
01010101000011111011101111110101000000100111100001101110101010100001111111000111
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [EF] CRC [1F4C]
01010101000011111011101111110111000000100111100001101110101010100001111101001100
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [EF] CRC [1FC4]
01010101000011111011101111110111000000100111100001101110101010100001111111000100
FAIL CRC FUNCTION [0] ADDRESS [55761E4] VRC [DD] LRC [EF] CRC [1FC5]
01010101000011111011101111110111000000100111100001101110101010100001111111000101
FAIL CRC FUNCTION [0] ADDRESS [57761E4] VRC [DD] LRC [AF] CRC [1E0C]
01010101000011111011101111110101000000100111100001101110111010100001111000001100
FAIL CRC FUNCTION [0] ADDRESS [57761E4] VRC [DD] LRC [AF] CRC [1E89]
01010101000011111011101111110101000000100111100001101110111010100001111010001001
FAIL CRC FUNCTION [0] ADDRESS [5D761E4] VRC [DD] LRC [AF] CRC [1EC1]
01010101000011111011101111110101000000100111100001101110101110100001111011000001
FAIL CRC FUNCTION [0] ADDRESS [5D761E4] VRC [DD] LRC [AF] CRC [1F04]
01010101000011111011101111110101000000100111100001101110101110100001111100000100
FAIL CRC FUNCTION [0] ADDRESS [5D761E4] VRC [DD] LRC [AF] CRC [1FC5]
01010101000011111011101111110101000000100111100001101110101110100001111111000101
FAIL CRC FUNCTION [0] ADDRESS [75143AC] VRC [9B] LRC [AF] CRC [1E01]
01010101000011111101100111110101000000110101110000101000101011100001111000000001
FAIL CRC FUNCTION [0] ADDRESS [75761E4] VRC [DD] LRC [AF] CRC [1E84]
01010101000011111011101111110101000000100111100001101110101011100001111010000100
FAIL CRC FUNCTION [0] ADDRESS [75761E4] VRC [DD] LRC [EF] CRC [1E3C]
01010101000011111011101111110111000000100111100001101110101011100001111000111100

Is it the assumption at the present time that these are all double bit errors? Something is unusual about the Function 0 Codes... Why are all the addresses so similar? The VRC is very consistent per address however the CRC is not.

And finally, there were four Function 1 messages which occurred in the middle of four separate data bursts which also appeared as FAIL CRC (two of them decoded exactly identical from two separate data bursts).

FAIL CRC FUNCTION [1] ADDRESS [81BFFE4] VRC [24] LRC [4E] CRC [D1A5]
01010101000011110010010001110010100000100111111111111101100000011101000110100101
FAIL CRC FUNCTION [1] ADDRESS [81DFB34] VRC [05] LRC [32] CRC [2F73]
01010101000011111010000001001100100000101100110111111011100000010010111101110011
FAIL CRC FUNCTION [1] ADDRESS [81DFB34] VRC [05] LRC [32] CRC [2F73]
01010101000011111010000001001100100000101100110111111011100000010010111101110011
FAIL CRC FUNCTION [1] ADDRESS [81DFFC7] VRC [03] LRC [C9] CRC [BAF6]
01010101000011111100000010010011100011100011111111111011100000011011101011110110

Possibly this will be helpful somewhere down the road.

Shawn

 

[ScannerSK]

I'm getting 80FE for Collin County TX, and I believe 84FE is for the Downtown Dallas site. Those are the only two I can receive.

Eric has mostly 9E towers, you have FE and I have 5F. Possibly these relate to various sectors throughout the country. My understanding is an activation can be broadcast out of specific towers if the location of the vehicle is known or nationwide.

Shawn

 

[ScannerSK]

Eric has mostly 9E towers, you have FE and I have 5F. Possibly these relate to various sectors throughout the country. My understanding is an activation can be broadcast out of specific towers if the location of the vehicle is known or nationwide.

Shawn

Patent US 7664462 B2 appears to speak to this topic of the various towers being labeled by state and number and cells A-E. This may or may not apply to the current discussion however could be of interest.

"In the example of FIG. 4, one eastern U.S. network includes 21 RTU/tower combinations as shown each labeled by state, given a number, and associated geographically by cells A-E. Cell A thus includes two tower/RTU combinations located in New Hampshire (NH1 and NH2) and three tower/RTU combinations located in Massachusetts (MA1, MA2, and MA4). A particular tower/RTU combination may be a part of two or more cells as shown. The tower/RTU combinations with a “C” designation are the “called” towers (they receive a message from the center via a land line); the tower/RTU combinations without a “C” designation, in contrast, receive that same message wirelessly from other proximate tower/RTU combinations as discussed with reference to FIG. 3."

Shawn