How to decode Lojack?

[DSheirer]

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

Shawn, you may be seeing overlapping messages. Notice how the bit revs and sync pattern appears toward the end of the message.

sdrtrunk uses a continuous sync pattern matcher and will start a message assembler each time it detects the sync pattern.. I do this so that if the first sync pattern detect is a false trigger, then I won't miss the second (real) sync detect. You then have to rely on the CRC to sort the good from the bad.

Denny

 

[ScannerSK]

Shawn, you may be seeing overlapping messages. Notice how the bit revs and sync pattern appears toward the end of the message.

Denny

Denny,

Oh wow, I did not realize that! This entirely solves the problem. I analyzed one burst bit by bit and see firsthand now what is happening. SDRTrunk has the capability of decoding the same exact bits into multiple messages simultaneously whenever it sees the sync pattern. That entirely makes sense.

One burst which contains a Function 0 message (line 3) decodes to the following:

1 - 01010101000011110110011011110011110011101110000000000000000000001101111100000010
2 - 01010101000011111000001000101010100001111101110111111010100000010011110000110111
3 - 01010101000011111011101111110101000000100111100001101110101010100001111100000100
4 - 01010101000011111000001001110101100011101010111111111010100000010010111000000001

The last 55 bits of line two (which just happen to contain the 0101010100001111 sync pattern) are the first 55 bits of line three. So, in essence line 3 should really not exist.

Going forward, I will ignore all Function 0 messages unless they state PASS or CORRECTED (which I have not seen to date).

Using the current build of SDRTrunk, I have noticed the following function codes:

1 = Tower related broadcasts
2 = Test messages (with three tones) (FAIL CRC)
3 = Guaranteed packets? (1st message in a data burst). One address 00003AB repeats every 16 minutes on the second.
4 = Command signals? Many repeat every hour minus 16 seconds (every 59 minutes and 44 seconds). Type of command (test, activate, deactivate, speed-up) determined by the VRC bits as outlined in patent 8618957?
C = Cancellation request?
F = YouTube example of the stolen vehicle data bursts

Shawn

 

[EricCottrell]

Hello,

From reading the patents it appears originally the base stations only communicated with the mobile units and only transmitted in their timeslot when sending messages to a mobile. Thus a base station did not always transmit in their timeslot.

It got more complicated when some base stations were connected directly to the operations center via landline and they became responsible for relaying information to the rest of the base stations via RF. There is a need to identify the station transmitting so the stations know what station it is hearing in the slot. There is likely some checking to make sure the base station is transmitting okay.

The timeslots were originally setup so a mobile unit did not have to listen continuously for a message, only for a short period every 64 seconds. 11 messages takes about 3/4 of a second to transmit, leaving about 7 seconds for mobile units to respond.

I am begining to think the data is transmitted MSB first instead of LSB first. Most of the transmitted data deals with the link between base stations. So I am refering to MSB first decoding in this message.

Info using MSB First Format.
I am seeing Function 2 messages that can be transmitted for days. Given the time scales mentioned in a patent involving saving battery power while the mobile is searching for a message, this makes sense. I assume the Function 2 message is the deactivate message. Some hours later this can turn into a Function C message, which I am assuming is a site to site message to dequeue the address listed.

The first message sent is also a Function C message. I think it is in a block of special addresses used to synchronize. The EE00000 address only occurs in the first message.
EE00000 First message in the timeslot
EE00100 Seems to occur as the ninth message in the timeslot
EE00300 Seems to occur as the third message in the timeslot
EE01800 Seems to occur as the fifth message in the timeslot
EE0C000 Seems to occur as the eighth message in the timeslot
EE30000 Seems to occur as the second or third message in the timeslot

Function 8 messages seem to be ID messages
xxCnnss Station ID
xxDnnss Station ID
xxEnnss Station ID
xxFnnss Station ID
where:
xx maybe a pseudo-random number to spread out the values of VRC and LRC?
nn is network and ss is site. Maybe ss = x0 are landline connected base stations?

73 01 NH
73 80 NH

79 01 MA
79 20 MA
79 21 MA
79 40 MA
79 41 MA
79 80 MA
79 C1 MA

7F 01 TX Collin Co
7F 21 TX Downtown Dallas

FA 40 CO
FA 81 CO

F0 C0 RI

73 Eric

 

[ScannerSK]

I am beginning to think the data is transmitted MSB first instead of LSB first. Most of the transmitted data deals with the link between base stations. So I am referring to MSB first decoding in this message...

73 Eric

Denny,

Would it be possible to make a version of SDRTrunk that processes MSB first? It would be greatly appreciated. I would love to see what Eric is referring to.

Shawn

 

[EricCottrell]

Hello,

Conversion Table (also reverse the order of digits)

LSB MSB
0   0
1   8
2   4
3   C
4   2
5   A
6   6
7   E
8   1
9   9
A   5
B   D
C   3
D   B
E   7
F   F

Conversions

LSB First  = MSB First
Function 4 = Function 2
Function 1 = Function 8
Function 3 = Function C
0000033    = EE00000
0080033    = EE00100
00C0033    = EE00300
0018033    = EE01800
0003033    = EE0C000
0000C33    = EE30000
ssnn3xx    = xxCnnss
ssnnBxx    = xxDnnss
ssnn7xx    = xxEnnss
ssnnFxx    = xxFnnss

73 Eric

 

[ScannerSK]

I see, so as an example my towers would be as follows:

1011 1001 1110 1111 1010 0100 0000
 D    9    7    F    5    2    0   = 025F79D (LSB)
 B    9    E    F    A    4    0   = B9EFA40 (MSB)

1000 1101 1101 1111 1010 1000 0001
 1    B    B    F    5    1    8   = 815FBB1 (LSB)
 8    D    D    F    A    8    1   = 8DDFA81 (MSB)

Just figuring things out manually for future reference.

LSB First  = MSB First
Function 4 = Function 2
Function 1 = Function 8
Function 3 = Function C
0000033    = EE00000
0080033    = EE00100
00C0033    = EE00300
0018033    = EE01800
0003033    = EE0C000
0000C33    = EE30000
ssnn3xx    = xxCnnss
ssnnBxx    = xxDnnss
ssnn7xx    = xxEnnss
ssnnFxx    = xxFnnss

73 Eric

In the above example would there be 7's in the left hand column instead of 3's? Just making sure I understand properly.

0000077 = EE00000
0080077 = EE00100
00C0077 = EE00300
0018077 = EE01800
0003077 = EE0C000
0000C77 = EE30000

73 Shawn

 

[DSheirer]

Denny,

Would it be possible to make a version of SDRTrunk that processes MSB first? It would be greatly appreciated. I would love to see what Eric is referring to.

Shawn

Yes, I can push an update a little later in the week ... my next couple evenings are booked.

 

[EricCottrell]

I see, so as an example my towers would be as follows:

1011 1001 1110 1111 1010 0100 0000
 D    9    7    F    5    2    0   = 025F79D (LSB)
 B    9    E    F    A    4    0   = B9EFA40 (MSB)

1000 1101 1101 1111 1010 1000 0001
 1    B    B    F    5    1    8   = 815FBB1 (LSB)
 8    D    D    F    A    8    1   = 8DDFA81 (MSB)

Just figuring things out manually for future reference.



In the above example would there be 7's in the left hand column instead of 3's? Just making sure I understand properly.

0000077 = EE00000
0080077 = EE00100
00C0077 = EE00300
0018077 = EE01800
0003077 = EE0C000
0000C77 = EE30000

73 Shawn

Hello,

Yes, 7.

73 Eric

 

[EricCottrell]

Hello,

One thing I forgot to mention is the Function bits are used in the VRC and LRC calculations. It did not seem logical until I read Patent 8618957 B2. The different VRC and LRC codes the receiver is looking for are for the unit address and function codes for the unit's functions, like activate.

I also noticed the ID messages occur seemingly random during the base station transmission. If data is indexed to the second to eleventh slot, as in the patent, then the ID is filler information when there is no message to send.

I started recieving Function 6 messages a couple of days ago. It started out at one base station being transmitted every 64 seconds for three rounds, then every 15 to 16 minutes. Other base stations joined in and transmitted the same message. The transmission have lasted for days, but the transmission rate has slowed to once per hour. I noticed the message always appeared as the second message, which makes sense if the message is indexed to a message slot.. Two other Function 6 messages started later in the day and all three are still being transmitted.

73 Eric

 

[ScannerSK]

I started recieving Function 6 messages a couple of days ago. It started out at one base station being transmitted every 64 seconds for three rounds, then every 15 to 16 minutes. Other base stations joined in and transmitted the same message. The transmission have lasted for days, but the transmission rate has slowed to once per hour. I noticed the message always appeared as the second message, which makes sense if the message is indexed to a message slot.. Two other Function 6 messages started later in the day and all three are still being transmitted.
73 Eric

Hi Eric,

Are you thinking Function 6 (MSB) may be for activation?

73 Shawn

 

[EricCottrell]

Hi Eric,

Are you thinking Function 6 (MSB) may be for activation?

73 Shawn

Hello,

It could be any command ( 6 is the same value for both MSB First and LSB First). I am continuing the logging to see if it stops and any other codes sent. The whole sequence of a base station sending a command and a mobile responding needs to be captured. It is like waiting for a fire to occur in your area so you can find fireground frequencies.

I get one or two messages after logging for over a day for some of the other function codes. I do not consider them valid, as messages with that frequency are likely multiple bit errors.

Here are the addresses I get for Function 6
MSB First LSB First
39EE230 0C4779C
19E38B0 0D1C798
24144B0 0D22824

Three is too small a sample size to figure much out.

73 Eric

 

[ScannerSK]

Eric,

I started a running spreadsheet on my end as well. I noticed one Function 2 address change over to a Function C prior to disappearing.

I have also started to store sound bites of the bursts (at least temporarily) using the following sound activated program: RecAll-PRO audio recording software for Windows

73 Shawn

 

[ScannerSK]

Regarding called (land line input) towers and non-called (RF input) towers there is an interesting note about the transitions which occur at midnight GPS time.

"In one specific implementation, at midnight GPS time (about sunset Eastern U.S. time) the state flag is changed for every entry in the BIN file. If the state=3 (Dial-up input), then keep the state the same. If the state=1 (1 RF input, do not transmit), then the entry is discarded. If the state=2 (2 RF inputs, transmit on schedule), then the state is changed to 1.
"The effect of these state changes is that garbage is discarded, and a fresh input from a dial-up source is required for the transmissions to continue after sunset, which is the next day GPS time. This rule limits the time that an RTU listens for the second RF input by discarding any single inputs at sunset. This rule also prevents garbage from transmitting when two identical garbage messages have been heard. It removes any old activation transmissions, in case a tower did not hear the de-activation signal. The sunset rule keeps the state of the RF repeated messages healthy." Patent 8787823

It appears primary towers that receive commands directly by land line continue to broadcast their commands until the set time expires (one month typical in the case of activation codes unless deactivated before the set time expires). Commands received by a secondary RF relay tower from only one other RF source are not rebroadcast and are deleted at midnight GPS time. Commands received by a secondary RF relay tower from two other RF sources are rebroadcast until midnight GPS time at which point the RF relay tower stops broadcasting the commands however the command is not deleted until an additional day has passed (to allow for the reception of another valid command and thereby resume broadcasts of the command).

73 Shawn

 

[ScannerSK]

Some hours later this can turn into a Function C message, which I am assuming is a site to site message to dequeue the address listed.

Hi Eric,

Regarding Function C messages, I just ran across the following:

"But, the de-queue message cannot be transmitted wirelessly from RTU 18 a [called tower] to RTUs 18 b or 18 c [non-called towers] and thus RTUs 18 b-18 c would continue to transmit the transponder activation message as shown in FIG. 7 causing needless airwave transmissions unless additional steps are taken.
"In the subject invention, the controllers of RTUs 18 b and 18 c (and all secondary RTUs) are programmed to transmit the transponder activation message only for a predetermined time period (such as five hours) unless an activation message is again received again by the RTU." Patent 7664462

It appears de-queue messages are only sent by land line to the called tower and are never broadcast over the air. This could have changed since the patent.

I wonder if Function 2 could be associated with rate commands and Function C could be the deactivate command (which is broadcast by both called and non called towers)?

I started recieving Function 6 messages a couple of days ago. It started out at one base station being transmitted every 64 seconds for three rounds, then every 15 to 16 minutes. Other base stations joined in and transmitted the same message. The transmission have lasted for days, but the transmission rate has slowed to once per hour. I noticed the message always appeared as the second message, which makes sense if the message is indexed to a message slot.. Two other Function 6 messages started later in the day and all three are still being transmitted.
73 Eric

Function 6 sure sounds like it could be used for activation commands from your description. Patents mention vehicle transponders being assigned to listen to a specific message frame and to ignore the remaining message frames. Also, patents mention non-called towers joining in broadcasting activation requests. Regarding timing, patents mention activation signals being sent once per hour for up to a month by a called tower as an example. For non-called towers the activation signals may only be broadcast for one day.

I'm not entirely certain however it appears the same address may be used in both the activation and deactivation commands.

73 Shawn

 

[ScannerSK]

I notice some Function 2 messages fall into the same message slot each time (ex: 2nd message slot) while other Function 2 addresses fall into random slots (ex: between the 3rd to 7th message slots). Whatever message slot(s) are being used by the address as a Function 2 continue to be used when the address turns into a Function C. Function 2 and Function C addresses mimic each other in their handling of message slots per address whether only one message slot is used or multiple message slots are used.

Shawn

 

[EricCottrell]

Hello,

I picked up 4 sets of Function 3 MSB (Function C LSB) messages. There were only three messages in a set out of a single base station. This might be the speed up command.

MSB     LSB
BA3D170 0E8BC5D 3 messages spaced one (64 Sec) or two slots (128 Sec)
0ED5C0A 503AB70 3 messages spaced one (64 Sec) or two slots (128 Sec)
108AF62 46F5108 3 messages spaced one (64 Sec) or two slots (128 Sec)
7709223 C4490EE 3 messages spaced 13 slots (13 Min 52 Sec)

73 Eric

 

[ScannerSK]

Hello,

In post #36 I also noticed an address alternating back and forth between Function 2 (LSB 4) and Function 3 (LSB C) for an extended period of time.

Function 3 as a speed-up command makes sense. However in light of post #36 I tend to lean toward Function 2 now being the activation command for a couple reasons. 1.) The sheer number of unique Function 2 addresses would appear to indicate the number of stolen vehicles which have yet to be recovered. Activation requests continue to be broadcast for at least one month (possibly longer) until the vehicle is recovered while deactivation requests are only broadcast for typically 24 hours. 2.) If Function 2 commands are intermixed with Function 3 commands as noticed on one occasion this would be contradictory if Function 2 was for deactivate (deactivate and speed-up commands being sent simultaneously). On the other hand Function 2 as an activation request makes sense as activation requests can continue to be sent from some non-called towers until a set amount of time has expired during which time speed-up commands could be broadcast at the same time.

Currently, I am thinking the following (all listed in MSB):

Function 2 - Activation requests
Function 3 - Speed-up requests
Function 4 - Test broadcasts
Function 6 - Specific "broadcast rate command code"? Slow down request if such exists?
Function 8 - Tower IDs
Function C - Deactivate
Function F - Stolen vehicle tracking pulses

The transponder when first activated sends a reply to the tower to confirm activation. I assume this reply from the transponder may have another unique Function code as well.

73 Shawn

 

[ScannerSK]

Examples of vehicle transponder units shown online have the following registration/unit label numbers:

01CA165
0482514
0BD2554
094BC05
01F4C44
0A286AB
0ADE589
01600D4
0E42E56
070FEF6
003F817
0D75968
038B981
073D775
020CC59

Notice they all begin with a 0 and are all seven characters in length consisting of 0-9 and A-E (similar to the addresses we are decoding with SDRTrunk). As these all begin with a 0 they would appear to be unrelated to the actual addresses transmitted by the towers to the vehicle transponders as they do not all begin with a 0.

Several documents online appear to indicate there may actually be three separate codes: an activation code, a deactivation code and a reply code. As examples search for "deactivation" in the following articles:
Example 1
Example 2

However, more likely than not, it is possible these "codes" are simply a reference to the 8-bits stored in VRC which are calculated based off the same address however differing function commands.

Shawn

 

[ScannerSK]

Unique function 4 addresses count

After logging for a day and a half (over 29,000 lines) I am showing 192 unique Function 4 addresses. The two towers I receive data from appear to cover part of southern Wyoming and most of the Northern half of the state of Colorado. This number seems fairly high to be the number of stolen vehicles with LoJack transponders which have not been recovered simply in this area alone.

I wonder if we were to compare lists of Function 4 addresses how many would match across the country?

Shawn

 

[ScannerSK]

Function 2 (MSB) - Fascinating facts

A little research into Function 2 reveals the following fascinating facts after four days of data:

A Function 2 (activation) address will cease to be transmitted either when a Function C (deactivation/recovery) is broadcast or after a certain length of time (possibly 30 days) at which point it just ceases to be broadcast any further.

When a Function 2 address appears for the first time it is transmitted very frequently (almost every minute), later in the day it slows down to half a dozen times per hour and days later it is a few times per hour, and just before a Function 2 ceases to be transmitted (possibly 30 days later) it is only being broadcast a few times every six hours.

Out of all the Function 2 (activation) addresses that were cleared by a Function C (deactivation/recovery) 13 occurred on the same day the address was first noticed, 3 occurred the following day and 2 were noted to clear after 2 or more days after the address was first broadcast.

Between the start of Dec. 11th to the end of Dec. 13th I saw an average of 4 new activations per day (44%) that were not cleared out within 2 days. I saw an average of 5 new activations per day (56%) that were cleared out within 2 days.

LoJack boasts of a 90% success rate in recovery (no time frame noted for this) with a typical recovery time of 2 hours (for those that are recovered).

My rough calculations based off only four days of data would appear to indicate that every 3 days there are approximately 10 vehicles stolen with LoJack installed (3.33 per day) that are not recovered within 4 days. As of this morning, I have 150 activation requests being broadcast daily that began on or before Dec. 10th which have yet to be recovered. 150 divided by 3.33 per day would come out very roughly to about a 45-day activation period. Patents state a month is typical for activation requests to be broadcast if a vehicle is not recovered.

73 Shawn