How to decode Lojack?

[ScannerSK]

i posted a new test build (20150225_2042_lj1200_test.zip)

Everything is working great Denny in the test version!

I do have a couple of requests for the final release. The first request is an update to the "Function: 1" verbiage which represents speed up requests. The following is an example of how SDRTrunk presently shows speed up requests:

20150225 201716, PASSED, FUNCTION: 1-REPLY CODE REPLY CODE [5E72N] ADDRESS [8A2E4B2] VRC [71] LRC [5E] CRC [FB6B]

Speed up requests are displayed as "Function: 1-Reply Code Reply Code". I would suggest a verbiage of "Function: 1-Speed Up Reply Code"?

The second request is to display the function code character (0-9, A-E) even if the function code is unknown. Currently, the function code character is not displayed for unknown function codes. The following is an example:

20150225 233344, PASSED, FUNCTION: UNKNOWN REPLY CODE [T38SK] ADDRESS [4991D0D] VRC [D8] LRC [26] CRC [B078]

By looking at the bits, I was able to determine the above is a Function: C frame.

Would it be possible for the specific function code of each unknown frame to be displayed? This will assist in the future with determining what each specific unknown function code is used for.

Thank you again!

Shawn

 

[ScannerSK]

xx maybe a pseudo-random number

I noticed this evening that the "pseudo-random" characters are apparently relayed by the non-called towers. I had not noticed this before until the reply code format was added to SDRTrunk.

Example:

FUNCTION: 1Y-SITE ID SITE [[u]6P[/u]YN2] ADDRESS [015FB53] VRC [77] LRC [1A] CRC [3BFB]	22:05:44	Command			015FB53			173.075000
FUNCTION: 1Y-SITE ID SITE [[u]6P[/u]YN3] ADDRESS [815FB53] VRC [66] LRC [AA] CRC [FD0D]	22:05:36	Command			815FB53			173.075000
FUNCTION: 1Y-SITE ID SITE [[u]6P[/u]YN4] ADDRESS [025FB53] VRC [17] LRC [8C] CRC [F9AC]	22:05:28	Command			025FB53			173.075000

In the above example, the three towers I receive at my location are N4, N3 and N2 every 64 seconds. The first two characters (underlined) are the pseudo-random characters. Notice how the pseudo-random characters (6P) are broadcast by each of the three towers. Possibly the called tower generates the pseudo-random characters which are relayed by the non-called towers.

Shawn

 

[ScannerSK]

164.175 MHz

Those in the vicinity of Canton, MA and Westborough, MA might want to monitor 164.175 MHz as LoJack conducts testing on this frequency. Apparently, other countries use 164.175 MHz for vehicle recovery systems; LoJack uses the 164.175 MHz frequency near the location of their headquarters to test equipment made for these out of country markets.

FCC LoJack use of 164.175 MHz

Shawn

 

[ecps92]

For the United Kingdom

Those in the vicinity of Canton, MA and Westborough, MA might want to monitor 164.175 MHz as LoJack conducts testing on this frequency. Apparently, other countries use 164.175 MHz for vehicle recovery systems; LoJack uses the 164.175 MHz frequency near the location of their headquarters to test equipment made for these out of country markets.

FCC LoJack use of 164.175 MHz

Shawn

 

[ScannerSK]

Vehicle Transponder Acknowledgement Message

I ran across the following which appears to indicate a LoJack vehicle transponder may transmit a 1.8 second duration transmission every five minutes when first activated:

"As of 2002... Optionally, they can now add a 1800 ms uplink cycle when activated - (either 'early warning' or reported stolen). They can transmit the 1800ms (1.8 seconds) signal every 5 minutes, with a maximum of six such messages in any 30-minute period. This 1800ms signal is long enough to ID the unit and to let the base know that it has, in fact, received the instruction to transmit its 'I'm stolen' signal to police units. Previously, once a vehicle was reported stolen, all the LoJack base stations would transmit a 300-watt 'turn yourself on' signal every 15 minutes for the first two hours, and then once an hour for 30 days, or until the vehicle was recovered, whichever occurred first. The 1800ms cycle for the mobiles lets the base stations know 'I heard you, I'm turned on, you can shut up now.'"
Freq Of Nature LoJack

Shawn

 

[ScannerSK]

Vehicle Transponder Acknowledgement Message (Part 2)

I ran across additional information regarding the "acknowledgement message". The "acknowledgement message" is NOT the same as the reply code/tracking pulses transmitted by stolen vehicles.

"In 2002, the Commission amended the Section 90.20(e)(6). The rule's duty cycle limitation of 200 milliseconds per 10 seconds was increased to 1800 milliseconds for every 300 seconds (with a maximum of six messages in any thirty-minute period). The longer duty cycle allows SVRS operations to incorporate an early warning feature that minimizes lag time, thus assisting in the recovery of a stolen vehicle." FCC Record, Volume 20, No. 14, Pages 11429 to 12324, June 28-July 15, 2005, Page: 11446 | UNT Digital Library

So, the "acknowledgement message" appears to be part of the early warning system which is an optional feature available with all newer LoJack installations.

One of the best documents on LoJack "acknowledgement messages" appears to be the following FCC docket:
Click to Read FCC Docket

In this FCC docket we read the following:

"This amendment will enable LoJack to introduce a mobile-to-base-station 'uplink' technology... LoJack would like to improve the stolen vehicle system operation by incorporating an early warning feature to minimize that lag time [between stolen time and activation time]...

"As discussed in greater detail below, the early warning feature involves mobile-to-base station 'uplink' transmissions. This technology was not available when LoJack's system first was introduced, and has been developed by LoJack as part of its ongoing efforts to expand and improve the recovery of stolen vehicles. The uplink signal would be used for two purposes.

"First, in the event of a theft, uplink transmissions would be used to alert a control center, and then the vehicle owner, in order to effect a prompt police theft report, thereby improving the probability of a quick recovery. Second, uplink transmissions would be used to acknowledge base station activation and deactivation messages, thereby obviating the need for repetitive transmissions by high-powered base stations, reducing the actual transmitting time on channel by as much as a factor of 100:1. Uplink transmissions would be used in only these two, limited circumstances associated with vehicle theft and recovery activities. They would not be used for other purposes and, in particular, would not be used for general vehicle tracking and monitoring operations. Uplink transmissions are fully compatible with the existing SVRN.

"Section 90.20(e)(6) of the Commission's rules already permits uplink transmissions within a stolen vehicle recovery network. The rule, however, limits such transmissions to a duty cycle of 200 milliseconds every ten seconds or, when a vehicle actively is being tracked, to 200 milliseconds every second. The uplink technology requires a duty cycle from LJUs of 1800 milliseconds every 300 seconds with a maximum of six messages in any 30 minute period. The uplink receivers will be located at the base station sites around the country....

"The uplink uses a narrowband transmission with a 63-bit spacing code modulation...

"The message length can be determined as follows: The transmissions use a reduced bit rate, two level FM modulation, with a bit rate of 17.92 ms/bit (3571.428 Hz clock divided by 64). The format is [short preamble] [flag] [frame] [short preamble] [flag] which totals to 100 bits. 100 bits x 17.92 ms = 1792 ms. The request was rounded off to 1800 ms/300 seconds for simplicity.

"In the proposed system, vehicles would be fitted with an 'Early Warning Detector,' or 'EWD.' If at any time an EWD unit that has been enabled and armed detects external movement of the vehicle or determines that the vehicle has been started without using the key, (i.e.; 'hot-wired'), it would send a brief alert signal to the LJU unit. The LJU unit then would transmit this alert to the nearest base station(s), which would receive, process, and forward the message (via the existing network) to a central, 24-hour-per-day control center operated by LoJack. Personnel working in the call center then would alert the owner that the vehicle has been stolen, making it possible for the owner immediately to notify the police of the theft.

"Once the theft is reported to the police, the existing LoJack activation and tracking process can be initiated. By speeding up the theft detection and reporting process, the uplink technology would improve the chances for successful vehicle recovery and improve tracking efficiency. The more quickly the theft is detected and reported, the more defined the area in which the vehicle is likely to be located. When LoJack introduced this technology in South Africa, the vehicle recovery rate went up 10%, from 82% to 92%.

"With LoJack's proposed change, the LJU would transmit a brief message acknowledging the receipt of a [activation/deactivation] message from the base station. Upon receiving an acknowledgement, each affected base station will cease transmitting any additional messages, thereby reducing dramatically the number of base station transmissions required for each theft/recovery activity....

"Transmissions from mobiles shall be limited to either 200 milliseconds every 15 seconds or 1800 milliseconds every 300 seconds, except that when a vehicle is being tracked actively, the transmissions occur 200 milliseconds every second for 30 minutes and then revert to 200 milliseconds every 15 seconds."
Click to Read FCC Docket

"The uplink modulation consists of a two-frequency FSK:
Binary '0' : 17.92 mSec low frequency
Binary '1' : 17.92 mSec high frequency"
http://servv89pn0aj.sn.sourcedns.com/~gbpprorg/zine2/html/2/lojack-1.html

So, the acknowledgement message is a separate and unique message from the reply code transmitted after being activated. The acknowledgement message is transmitted by LoJack equipped vehicles to LoJack towers to notify the owner of any vehicle movements when the owner is subscribed to receive early warning notifications. Also, the acknowledgement message is transmitted by LoJack equipped vehicles to acknowledge activation and deactivation messages broadcast by the towers intended for that specific vehicle (whether subscribed to the early warning system or not).

This explains why I have heard what appeared to be dead air transmitted for 1800 milliseconds on two separate occasions following two separate LoJack vehicle transponders being deactivated by the tower. Above, it states, "Uplink transmissions are fully compatible with the existing SVRN". For this reason, a person would assume the same CPFSK data format is being used, however this does not appear to be the case.

Notice it states, "The transmissions use a reduced bit rate, two level FM modulation, with a bit rate of 17.92 ms/bit...100 bits x 17.92 ms = 1792 ms." This appears to indicate the acknowledgement message is transmitted at a bit rate of about 55.8 bits per second rather than the usual 1200 bits per second used by LoJack.

So, what I thought were dead air transmissions following deactivations of stolen vehicle transponders may actually be acknowledgement messages!

I amplified the sound several thousand times over on the best example I have of an acknowledgement and have attached it to this thread for everyone to review. It does appear there is some type of data being transmitted at a rate of around 55.8 bits per second.

There is a possibility ultrasonic frequencies are being used in the modulation of the acknowledgement message which my recording equipment may not have captured. Otherwise, it appears the higher frequency (possibly the "1" bit) is around 500 Hz and the lower frequency (possibly the "0" bit) is around 300 Hz.

The attached sound file would appear to decode out to something as follows:

1111[u]1111010010111000[/u]1001000001101110001001010100010101100011010011100101010010000[u]1111010010111000[/u]

Shawn

 

[ScannerSK]

1111[u]1111010010111000[/u]1001000001101110001001010100010101100011010011100101010010000[u]1111010010111000[/u]

The acknowledgement message (for the above attached sound file) was transmitted when a stolen vehicle transponder was deactivated. The stolen vehicle transponder that was deactivated had an activation/deactivation address of FB6F4F1 (MSB) and a speed up address of B7B4800 (MSB) corresponding to a reply code format of UU910.

I fail to find any of the above addresses contained in the acknowledgement message. Possibly a different data format is used in the acknowledgement messages or another possibility is that a different address is used in the acknowledgement message than is used to activate/deactivate a stolen vehicle.

Possibly the short preamble is 11010010 and the flag is 111000? This would leave 63 bits for the frame.

I have one additional example of an acknowledgement message which sounds similar to the above attached file when amplified however the file is too noisy to make out the bit structure.

Shawn

 

[DSheirer]

Shawn,
Audacity works good for cleaning up the audio and includes some frequency spectrum and auto-correlation analysis tools.

You might try:

1) Low pass filter the audio with 3000 Hz and 48db
2) Select all of the waveform that looks like signal and then choose Analyze > spectrum.

See if there are any dominant frequencies and then use the low and high pass filters to isolate those frequencies.

You can always ctrl-z to undo any filtering and get back to the original waveform.

You can zoom in on the spectrum.

That recording has some some frequency spikes at 60 Hertz (AC-power line frequency) and 400 Hertz (aircraft power cart). I suppose other things can generate 400 Hertz signals too, but that's one I'm familiar with ... and I'm not suggesting this signal is coming from an aircraft

Denny

 

[ScannerSK]

Shawn,
Audacity works good for cleaning up the audio and includes some frequency spectrum and auto-correlation analysis tools.

You might try:

1) Low pass filter the audio with 3000 Hz and 48db
2) Select all of the waveform that looks like signal and then choose Analyze > spectrum.

See if there are any dominant frequencies and then use the low and high pass filters to isolate those frequencies.

You can always ctrl-z to undo any filtering and get back to the original waveform.

You can zoom in on the spectrum.

That recording has some some frequency spikes at 60 Hertz (AC-power line frequency) and 400 Hertz (aircraft power cart). I suppose other things can generate 400 Hertz signals too, but that's one I'm familiar with ... and I'm not suggesting this signal is coming from an aircraft

Denny

Hi Denny,

Currently, I use an old version of Cool Edit. It contains low and high pass filters, notch filters and noise reduction (based off a noise sample taken from the recording) and many other features.

After cleaning up the audio a little, the best I can make out of the second example of the acknowledgement message from an entirely different vehicle is as follows:

11111111111[u]1010010111000[/u]1100111001100000100101111010010101010001000111000010011101110010[u]1010010111000[/u]0000

This example begins with more 1's and ends with more 0's. I re-checked the 18th bit from the end and it definitely appears to be a "0" bit. So, this appears to rule out the short preamble as 11010010.

If the format is [short preamble] [flag] [frame] [short preamble] [flag] as noted in post #266 then I would assume the short preamble may be 010010 and the flag 111000. Possibly a better recording down the road will reveal some insights.

The only two examples I have of acknowledgement messages compared one on top of the other are as follows with the similarities underlined:

    [u]111111110100101110001[/u]001000[u]00110[/u]111000100101010[u]0010101[/u]100011010011100101010010000111[u]1010010111000[/u]
1111[u]111111110100101110001[/u]100111[u]00110[/u]000010010111101[u]0010101[/u]010001000111000010011101110010[u]1010010111000[/u]0000

I believe what you are referring to as 60 Hz spikes are actually the "1" bits appearing in the data which is being transmitted at a rate of 55.8 bits per second (which is very close to the 60 Hz per second rate the power grid runs on).

Shawn

 

[ScannerSK]

LoJack Data will include GPS Coordinates in the future?

Looking through this document https://apps.fcc.gov/edocs_public/attachmatch/FCC-08-186A1.pdf appears to indicate new LoJack technology will be capable of providing GPS coordinates of the vehicle to the base station/tower. When the LoJack frequency is used to relay GPS details (cell towers can also be used), it appears the data will be transmitted the same way acknowledgement messages are currently transmitted with the exception the length will increase from 1.8 seconds to 7.2 seconds in total length.

"To transmit GPS information to provide police with the exact longitude and latitude of a stolen vehicle, hijacked hazardous materials or other dangerous cargoes, however, the uplink message will require sending 124 bits. Therefore, LoJack requests a longer uplink transmission time, as it will need to send at least four successive uplink messages of 1.8 seconds duration to the base station, equivalent to a duty cycle of 7200 milliseconds every 300 seconds."

"LoJack states that GPS data transmission requires at least four successive uplink messages of 1.8 seconds duration to the base station, equivalent to a duty cycle of 7200 milliseconds every 300 seconds. LoJack states that without a lengthened uplink duty cycle, new VLUs would not be able to transmit GPS coordinates to uplink receivers."

The article does not state whether any of these proposed changes requested in 2008 have been adopted/approved.

Shawn

 

[DSheirer]

Looks like the requests were approved around 2009:

https://www.law.cornell.edu/cfr/text/47/90.20

See section (e)(6)

 

[ScannerSK]

Vehicle Transponder Acknowledgement Message (Part 3)

Skimming through the list of LoJack patents on their website, I ran across one patent 6522698 which details how the Acknowledgement Messages functions. The patent also includes five images which can be viewed.

The following are some notes from this patent:

"According to a first aspect of the present invention there is provided a method of transmitting and receiving data, the method comprising the steps of: transmitting a narrow band data signal at an unknown frequency within a known range of frequencies; receiving the data signal within the known range of frequencies; dividing at a receiver the range of frequencies into plural frequency bands each of width less than the uncertainty in the transmission frequency of the data signal; detecting the presence of said data signal in at least one of said frequency bands; and, demodulating the detected data signal....

"The frequency of the transmitted data signal may be varied between successive transmissions. This ensures that a good signal will be received even if there is line interference at a particular frequency as the subsequent transmission will be at a frequency which is unlikely to be affected by the same interference....

"The data signal is preferably transmitted as two sub-channels, the detection and demodulation steps being carried out on each sub-channel...

"For example, when a transceiver has been activated by a base station, the transceiver can send a data signal to the base station to acknowledge that it has been activated, thus providing assurance to the base station that the activation signal has been received and saving the base station from having to repeat the signal many times to ensure that it had been received as in the past. A de-activation signal may be sent to the transceiver which can also be acknowledged by the transceiver so that the base station can be confident that the de-activation signal has been received and thus preventing false or erroneous activations from being maintained. Data concerning the status of the transceiver (such as the status of the transceiver unit, its battery voltage, etc.) can be sent to the base station which can therefore continually monitor the status of the transceiver unit...

"In particular, in the specific example described, the techniques described in detail below enable a substantially conventional low power transceiver unit to be used to provide two-way communication on-board a vehicle, but with a range increased to be comparable to that of a base station. The range of the transceiver is increased by a reduction in bandwidth by effectively reducing the bandwidth at the receiver only, though the transceiver unit still transmits across the same band. The only modification required at the transmitter unit, therefore, is to reduce the speed of transmission because the system will behave as if, in effect, narrow band transmissions are being made. As will become clear, at the receiver, the channel received is divided into a number of narrow bands from each of which information can be detected and demodulated. The use of a narrow bandwidth at the receiver has the advantage of reducing the effect of noise because, by definition, white noise has a uniform energy per unit of bandwidth....

"The data to be transmitted by an individual transceiver unit is modulated onto the carrier signal by frequency shift keying (FSK) with a deviation of ±2.5 kHz and a bit transmission rate of 55.8 bits per second. The FSK modulation with this low data transmission rate produces a spectrum which has the appearance of two narrow band AM spectra, separated by 5 kHz, with one data band inverted with respect to the other because the data being transmitted can, to a large extent, be regarded as being transmitted only at either the higher or at the lower band produced by the FSK process. The upper band is defined to contain the inverted pattern.

"Preferably, the centre frequency for the transmission from the transceiver unit is varied slightly ('dithered') on successive message bursts so that if a message happens to be masked by line interference on one frequency of the transmitted data signal, it is likely to get through on the subsequently transmitted data signal. In this respect, the range of centre frequencies is limited to ±250 Hz....

"A demodulation process lasts for 63 bits of data....

"As can be seen, each data signal has a 4 bit dotting sequence of 0101, followed by an 8 bit flag sequence which is followed by a 4 bit null or space sequence of 0000. In this example, the 8 bit flag sequence is 10001101. In order to improve performance during detection, the detection algorithm looks for an extended 10 bit sequence commencing with the last 1 of the dotting sequence and ending with the first 0 of the null sequence. Thus, the detection algorithm is seeking the 10 bit extended sequence 1100011010....

"Multiple data packets can be sent by the transceiver on-board the vehicle in a single message. Each data packet is separated by a flag sequence from the next and previous data packet, there being flag sequences at the start and the finish of the message so that each data packet can be properly detected."

This patent makes for a very interesting read however I cannot say I understand it. How to properly decode the acknowledgement messages remain somewhat of a mystery. Possibly, the fact that acknowledge messages are broadcast in a type of narrow band manner explains why I had to amplify the signal thousands of times in order to even notice the bits being transmitted (on what at first appeared to be an un-modulated LoJack signal). I may or may not have properly decoded the two examples I have of acknowledgement messages which were received when two LoJack vehicle transponders were deactivated.

Shawn

 

[ScannerSK]

Yesterday, my scanner picked up an unusual data burst on the LoJack frequency. There are no signs of doppler shift in the brief signal so the source may have been stationary. The un-modulated leader preceding the data burst has a different peak amplitude than any of the three local towers which leads me to believe this was from a vehicle transponder. This data burst occurred in addition to the normal tower transmissions. The three normal tower transmissions occurred at 5:50.50, 5:50.58, 5:51.06 and again at 5:51.54, 5:52.02, 5:52.10. The unusual transmission was received at 5:51.36 (between two sets of normal tower transmissions).

The decode of the bits is as follows:

0101010100001111100000000001110111111011010111100011111010100000000011000101111000000000

In LSB format this translates to the following:

CRC - 7A30
HEX Address - 057C7AD / Reply Code Address - U9X7A
Function - F
LRC - B8
VRC - 01

This is the first example I have seen of a data burst containing 1111 as the actual transmitted bits. The unusual part is the CRC, LRC and VRC do not correspond to the address and function bits.

A stolen vehicle tracking pulse is transmitted with 1110 as the function bits and has a clear matching CRC, LRC and VRC. It also ends with around 100 extra "0" bits beyond the actual frame.

This unusual data burst recorded yesterday has the bits 1111 as the function bits and has no clear matching of the CRC, LRC and VRC. It ends with 8 extra "0" bits beyond the actual frame. The address translated into the reply code format reveals an "X" as the middle character which I believe may be reserved for special use in both tower and vehicle transmissions.

It is not a stolen vehicle tracking pulse however it most likely originated from a vehicle. I fail to understand why this was broadcast or what purpose it serves??

Shawn

 

[ScannerSK]

Additional Acknowledgement Message

A vehicle driving down the highway (clear doppler shift) transmitted an acknowledgement message this morning at 6:57 AM EST. It is the third (bottom) example below.

I am translating the spikes as "1" bits and the areas without spikes in the signal as "0" bits however am uncertain whether this is correct or not. I guess the important part is the realization that these are indeed acknowledgement messages. How to translate the acknowledgement messages properly into "1" and "0" bits remains a mystery however the following might be correct or at least a starting point for those who wish to pursue it.

    [u]111111110100101110001[/u]001000001101110001001010100010101100011010011100101010010000111[u]1010010111000[/u]
1111[u]111111110100101110001[/u]100111001100000100101111010010101010001000111000010011101110010[u]1010010111000[/u]0000
 111[u]111111110100101110001[/u]100000000011001000110110011011011000001100010011001001100000000[u]1010010111000[/u]

Shawn

 

[ScannerSK]

Mystery System - Vanished?

While in Denver Friday, I noticed the mystery LoJack system has vanished. It was not received even once. Possibly one of the other two locations of this mystery system are still active. If not, possibly LoJack updated the mystery system so it is no longer required to transmit unnecessarily four times per hour. Another possibility may be simply system problems at one specific site.

To date, the SDRTrunk program has assisted in the recovery of three stolen vehicles in the Denver area.

Shawn

 

[ScannerSK]

SDRTrunk LoJack Decoder

I posted a new test build (20150225_2042_LJ1200_test.zip) with the following changes:

1) Address, CRC, Function, LRC, and VRC are now displayed in Big-Endian (LSB first) format.
2) The reply code and address are now shown for all messages. The reply code is labeled as either reply code or site id, depending on the message type
3) Function 1 (former function 8 site id) is now correctly identified as site or transponder.

The function codes are now:

F1_SITE_ID( "1Y-SITE ID" ),
F1_TRANSPONDER_REPLY( "1-REPLY CODE" ),
F2_TEST( "2-TEST" ),
F3_DEACTIVATE( "3-DEACTIVATE" ),
F4_ACTIVATE( "4-ACTIVATE" ),
FF_TRACK_PULSE( "F-TRACK PULSE" ),
UNKNOWN( "UNKNOWN" );

I also updated the aliasing. Use the SiteID identifier to specify site IDs and reply codes. Use the ESN identifier to specify any address value. Be sure to use a full 5 characters/wildcards for site id/reply code and use a full 7 characters for addresses.

Denny

Denny,

I realized yesterday when I attempted to use the alias feature in SDRTrunk (to turn on sound notifications whenever speed-up {function: 1} frames are received) that it appears to not be working correctly. When an alias ID of "Site" is used it appears this selection is only currently working with site IDs and not with reply codes for some reason.

If you get a chance to look into this, the following additional updates to SDRTrunk would also be helpful (all of which should be rather quick):

1.) The ability to view the specific function code for each unknown frame. Currently, function codes 0, 5, 6, 7, 8, 9, A, B, C, D, and E all appear as "Function: Unknown" so there is no easy way to distinguish as to which specific unknown function code(s) are being received.

2.) A change in wording for speed-up frames. Currently, speed-up frames appear in SDRTrunk as "Function: 1-Reply Code Reply Code". An update in the wording to "Function: 1-Speed-Up Reply Code" may prevent confusion as to what the frame represents (a speed-up request).

Thank you again for the decoder. I keep it running non-stop!

Shawn

 

[ScannerSK]

SafetyNet Video

I came across the following SafetyNet video today which may be of interest to some. It shows a close up view of the unit used to locate missing persons.

https://www.youtube.com/watch?v=R5ZykfN8Cek

Shawn

 

[ScannerSK]

Inexpensive LoJack Receivers

I ran across the following LoJack units on e-Bay:
Lojack Ruggedized Locating Unit

The receiver portion of this specific model is always on which makes it a great candidate for use as a LoJack receiver. All one has to do is supply 12 VDC power and tap into the audio section of the circuit to decode the data. These are advertised as new, never used so there should be no worry of them ever transmitting.

Shawn

 

[ScannerSK]

I ran across the following LoJack units on e-Bay:
Lojack Ruggedized Locating Unit

The receiver portion of this specific model is always on which makes it a great candidate for use as a LoJack receiver. All one has to do is supply 12 VDC power and tap into the audio section of the circuit to decode the data. These are advertised as new, never used so there should be no worry of them ever transmitting.

Shawn

Correction to the above, the receiver portion of this particular model does appear to synchronize to the local LoJack signals after all which in turn shuts off the receiver portion of the unit when a signal is not present (to save on battery power). There is likely an easy way to override this and make the receiver stay on.

Shawn

 

[DSheirer]

I posted a new build (sdrtrunk_20150426_1958.zip) to the downloads folder with the following changes requested by Shawn:

1) Aliasing of Site IDs and Reply Codes - fixed
2) Reporting of unknown function codes to include function number/letter
3) Changed wording for speed-up messages

Denny