LTR Passport Decoder Project

[KD4YGG]

Started thread to discuss LTR Passport decoding and corresponding development of LTrunk utility.

Chris
KD4YGG

[cg]

I was able to further break down the data on a Passport LTR system. I am not sure what terms Passport uses for each of these different groups of bits but you should get the idea of it.

sync - 9
area - 1
goto - 12
site - 7
GROUP ID - 16 (new)
unk? - 3
free - 12
checksum? - 8

I read that the radio affiliates and deaffiliates and can be ID'd on demand. Therefore I don't believe the radio ID is sent in every line.
I have collected some strange patterns over the last few days on several channels and with different systems. It will take a road trip to get nearer a site to try to determine if it is poor decoding % or other info in other lines.

chris g

[EricCottrell]

Hello,

I see references that the Goto and Free are 13 bit fields. They use a base/step with a possible fixed step of 6.25 KHz. With 8,192 steps you can cover 51.2 MHz of spectrum. With a base of 450 MHz you can almost cover up to the end of T band! I would suggest people capturing try to relate the numbers to real frequencies.

73 Eric

[KD4YGG]

Got this from an available pdf report dated April 19, 2002, from United Radio Communications to Tompkins County, New York Administration. In it, there are some details about LTR Passport spelled out in comparison to the APCO-16 standard for trunked radio systems.

These include:
- APCO 16 requires five (5) levels of user priority.
- LTR/Passport has three (3) levels of user priority.

Number of Site Restriction
While Passport features are added continuously, the present configuration will only support 30 channels on any one system. (The one non-government public safety Passport system I monitor in nearby Montgomery County, TN uses 30 channels - 10 channels at 3 sites).

So.... It looks like 2 more bits in that middle 26 bit datastream are PRIORITY.

73's
KD4YGG

PS - cg - might you be able to send a copy of your raw data dump text files to me? Address is KD4YGG at MSN dot COM.

[cg]

Originally Posted by EricCottrell

I see references that the Goto and Free are 13 bit fields. They use a base/step with a possible fixed step of 6.25 KHz. With 8,192 steps you can cover 51.2 MHz of spectrum. With a base of 450 MHz you can almost cover up to the end of T band! I would suggest people capturing try to relate the numbers to real frequencies.

73 Eric

I was able to do just that for several systems.

The valid freqs for the UHF systems I am monitoring use only 11 bits to report the freq so there is an extra one in 2 locations. AREA is probably invalid because in a network there may be more than 2 systems. So with that in mind here are the changes

*SYNC - 1-9
unk (maybe message type) 10-11
*CURRENT FREQ 12-22
unk (poss netwk or site info) 23-29
*GROUP ID 30-45
unk 46-49
*FREE RPTR 50-60
unk 61-68

*= sure of in many of the messages, not all may be the same.

Also, I am using a 780 near my computer, 10 miles from the xmit sites

chris g

[EricCottrell]

Originally Posted by cg

I was able to do just that for several systems.

The valid freqs for the UHF systems I am monitoring use only 11 bits to report the freq so there is an extra one in 2 locations.
chris g

If there is a frequency code in the 11 bits are the two preceding bits always zero?

If the system does not have frequencies that are more than about 12.8 MHz from the base frequency then you will not see those upper two bits set.

73 Eric

[KD4YGG]

The two bits between SYNC and ACTIVE might be the PRIORITY bits I mentioned in the above post - 3 priority levels would take 2 bits to code.

I've got service manuals for the ICOM handheld Passport radios coming within the week - might be able to shed some light on the protocol.

KD4YGG

[cg]

101011000 00 01100110001 0000001 1110011010001001 0000 00100100101 11111100
101011000 00 01100110001 0000001 1110011011001101 1000 00110011000 111110001
101011000 00 01100110001 0000001 1110011010001101 0000 00100100101 11111100
101011000 00 01100110001 0000001 1110011010001000 0000 00110011000 111110001
101011000 00 01100110001 0000001 1110011010001001 0000 00100100101 11111100
101011000 00 01100111101 0000001 1110011010001001 0000 00110011000 000000001
101011000 00 11101110011 0000001 1110011010001001 0000 00100100101 11111100
101011000 00 01100110001 0000001 1110011010001001 0000 00100010000 11110000
101011000 00 01110111001 1000001 1111001101000101 1000 00010010010 111111100
101011000 00 01100110001 0000001 0000001010001011 0110 00100010000 00000111
101001000 00 11110000000 0000001 1000000000001010 1000 10000000000 010000100
101011000 00 01100110001 0000001 1110011010001001 0000 00100100101 11111100
101001000 00 01100110001 1000001 1111001001000101 1000 00010001000 011110000
101011000 00 01100110001 0000001 1110011010001001 0000 00100100101 11111100
101011000 00 01100110001 1000001 1111011001001101 1000 00110011000 011110000
101011000 00 01100110001 0000001 1110011010001001 0000 00100100100 01111100
101011000 00 01100110001 0000001 1110011011001101 1000 00110011000 111110001
101011000 00 01100110001 0000001 1110011010001001 0000 00100100101 11111100
101011000 00 01100110001 0000001 1110011111001101 1000 00110011000 111110000
101011000 00 01100110001 0000001 1110011010001001 0000 00100100101 11111100
101011000 00 01100110001 0000001 1110011011001101 1000 00110011000 111110001
101011000 00 00100110001 0000001 1110011010001001 0000 00100100101 11111100
101011000 00 01100110001 0000001 1110011010001001 1000 00110011000 111110001
101011000 00 11100110001 0000001 0000001010001011 0110 00100100101 00001011
101011000 00 11100000000 0000001 0000000000010101 1001 10000000000 110001101
111011000 00 11101110011 0000001 1110011010001001 0000 00100010000 11110000


I hope this posts in a readable size.
This was a raw stream. I made the dumped file a wordpad file and used "find" to locate the start of each line. In this there are several errors.

On line 10 and again on 24 is the radio ID (651) in the 16 bit section. I can't get enough good lines in a row to see if there is a pattern but it may be 14 lines. Freqs are accurate. It is a 2 site system but I heard only using 1 as of now. Talkgroup seems to be in the range of what I was given but is not exact. (I believe this is a change rather than a decoding error)

If anyone cares, the system is the town of Bloomfield CT

chris g

[cg]

When I run:

ltrunk -p com1 -t cts -ow 68 -f dump ("dump" is my file name)

on a channel on idle, I get a great pattern. However, the longer I run the program, the further apart the patterns get. If I start again it is like it is reset.

I have attached a Word file where I have had the program highlight the legit frequencies for the system. scroll down to see the widening patterns.

This is as exact to 60 seconds of data as I can get. It generates appx 60 lines /second. (70+ pages, don't hit print)

[opus]

cg

I will have a look at your problem. I have not run it a long time myself so I may have a rollover bug or such somewhere.

Opus

[cg]

I didn't see the file get uploaded so I am trying again.

[KD4YGG]

From a very good source, to remain anonymous:

PassPort
Trident Micro Systems

PassPort is a wide area dispatch protocol that allows both group and individual calls across multiple sites.

Each radio has an ID (MIN) that identifies the radio in the system. A user may roam across multiple sites and communicate across the network to other units in the same talkgroup on other sites.

A switch is required at each repeater site so control is distributed. Sites are interconnected by T1.

A radio may have multiple talkgroups but will only carry a selected talkgroup and the primary talkgroup when roaming.

It will only scan the programmed talkgroups when on
the home site.

When sites are being added to the system there is not a
requirement to re-program radios. The radios learn the system over the air.

There are currently over 100 PassPort systems across the U.S. with most found at UHF but there are 900MHz and VHF systems in use.

[KD4YGG]

OPUS

I was wondering if we might be at a point where a initial beta version of LTRUNK.exe could be formulated for Passport???

Perhaps called PTRUNK.exe?

I believe we have enough data from several persons to at least begin showing some of the parts of the data word in decimal versus binary, plus display of the actual frequencies in the CURR and FREE fields. This would greatly assist with further decoding.

SYNC: Bits 1-9, display in HEX like regular LTRUNK.exe
PRIO: Bits 10-11, appear to be PRIORITY
CURR: Bits 12-22, displayed as 450 + value of CURR * .0125
SITE: Bits 23-29, appears to be SITE Number
GRUP: Bits 30-45
MESS: Bits 46-49, appears to be Message or Call Type
FREE: Bits 50-60, displayed as 450 + value of CURR * .0125
CHCK: Bits 61-68, appears to be CHECKSUM

I had a chance to gather over 500k of data on the Montgomery County, Tennessee, system. It appears that the DISPATCH side of a call shows up completely different than the unit responding back - GRPID are different, and the MESS types are different.

Not sure of the CHECKSUM, but I'm sure it is familiar to LTR or Multi-Net.

Thanks
KD4YGG

PS - Lyndsay, how about giving out the site's first ever OPUS Award for his work on this project? He's been a GREAT help!!! Maybe a bronze statue of OPUS's on-screen icon???

[KD4YGG]

I believe that in my previous post, MESS should be replaced with CALL.

Looking through some information I was able to locate, I see the following as the various CALL types. The names are arbitrarily assigned in case we might want to use them in future development once they are decoded.

INDV - Individual Call (Unit-Unit)
GCL1 - Group Call Type 1 (Single Site)
GCL2 - Group Call Type 2 (Multiple Sites)
BCST - Broadcast/Announcement
ORDN - Ordinary Call
PRTY - Priority Call
PHON - Phone Patch
DISP - Dispatcher Call
ALRT - Alert Call
INCL - Include Call (possible crosspatch between groups)

This would utilize 10 different combinations, requiring 4 bits of information.

In addition, it appears that one bit is reserved as an emergency alert/man-down button feature that will be released in the future.

So, here's a revised list of the 68 bit data word that appears to be correct:

SYNC - Bits 1 to 9
PRIORITY - Bits 10 to 11
ACTIVE - Bits 12 to 22
SITE - Bits 23 to 29
GROUP - Bits 30 to 45
CALL TYPE - Bits 46 to 49
FREE - Bits 50 to 60
EMERGENCY - Bit 61
CHECKSUM - Bit 62 to 68

[mr_hankey]

i agree with Chris.

it is largely because of Opus' ltrunk.exe that i've been decoding the hell out of the local LTR systems.

what i could use now is some help identifying the _type_ of LTR system i'm looking at when i park on a certain frequency - but it looks like there's enough information now that this could be decoded as well.

[opus]

cg

I have found a bug in ltrunk when using the -ow option. (See Multi-Net decoder thread for version 0.10). Let me know if you still have problems.

KD4YGG & mr_hankey

thanks for your kind words. It has got me going again. I was loosing interest since I have completed what I wanted from ltrunk. But I will keep going so you guys can get passport and multi-net stuff going. I was thinking of adding a feature whereby you could specify how to show the frame by a simple text spec. file. That way you can keep changing/adding to it as you work it all out so the output is up to date without me having to recode. Let me know if you think this is the best way to go forward.

Opus

[KD4YGG]

OPUS

Sounds like the text spec file would be a great idea

Kind of like passing the variables of TRACKSCANPARK, etc in TRUNKER.

Again, thank you for the GREAT EFFORT!!!!

Chris
KD4YGG

[mr_hankey]

i agree - sounds like a good option.

[cg]

I would agree to anything that will not make me look at more pages of 1's and 0's. I also echo the thanks from the others.


Opus, thanks for the u/d on the program, I am in the midst of another project but will check that out asap.

I saw on a radio companies site that Passport will allow up to 255 radios for each company. So the first half of that 16 bit GROUP id is available to be used for something else when the radio ID's are sent from the field.

When the mobile transmits they are obviously using the input to the repeater. Is the information the mobile passes simply repeated over the repeater or is the subaudible traffic independent of the user?

Just some random thoughts while I tap the keys on the laptop and wait for 21000 megs of data move onto my new hard drive...

chris g

[opus]

LTRunk 1.0 released. See seperate thread.