LTR Passport Decoder Project
- Thread starter KD4YGG
- Start date
- Status
Hello,
My travels ocassionally take me to CT and the last couple of times I was on the lookout for passport systems. The TRSDB mentions that Foxwoods in Eastern CT was a passport system. I was able to receive the system but it looked like a regular LTR system with some channels passport.
Marcus Communications is building out a statewide passport system in CT called VoiceLink. They also provided the system for Foxwoods.
Doing some further research I find that Voicelink and Foxwoods share some frequency allocations. During my last trip I get the impression that Foxwoods is regular LTR and the Passport I heard was really a nearby cell of Voicelink. One active passport frequency, 452.650, was heard during a drive from New London up to south of Worchester, Ma. I assume I received multiple sites.
So has anyone noticed any regular LTR traffic on a passport system?
73 Eric WB1HBU
My travels ocassionally take me to CT and the last couple of times I was on the lookout for passport systems. The TRSDB mentions that Foxwoods in Eastern CT was a passport system. I was able to receive the system but it looked like a regular LTR system with some channels passport.
Marcus Communications is building out a statewide passport system in CT called VoiceLink. They also provided the system for Foxwoods.
Doing some further research I find that Voicelink and Foxwoods share some frequency allocations. During my last trip I get the impression that Foxwoods is regular LTR and the Passport I heard was really a nearby cell of Voicelink. One active passport frequency, 452.650, was heard during a drive from New London up to south of Worchester, Ma. I assume I received multiple sites.
So has anyone noticed any regular LTR traffic on a passport system?
73 Eric WB1HBU
I was told that LTR and Passport can coexist but cannot share home channels. I occasionally monitor Marcus's Bolton site and there is a mix of both types of LTR there also.
I have never spent time monitoring Foxwoods, but it was described on several newsgroups as Passport. I would imagine that it could be a split system as easily as the others
chris gordon
granby ct
Hello,
That seems to fit because VoiceLink has two levels of service, a local one (regular LTR?) and a statewide roaming (Passport?). It also appears Marcus is using the license all frequencies for all sites method I have seen with other licenses. So looking at the FCC database it appears that Foxwoods and the various VoiceLink sites are active on the same frequencies.
There was not much traffic on the New London area site. There appeared to be only one talkgroup active on Friday. I need to see if I can get a fix on a good site in NE CT so the drive distance is reduced 8->.
Some things I noticed:
The Passport only channel seemed to send a burst about once per second. There is another frequency, 452.800, I received in the New London area that is about once every two seconds.
Transmission sequence
1c0680a8a8c4670 Passport <- Keyup Unit ID Talkgroup mapping?
0351e78cc00a420 Passport <- Group/Channel
0351e78cc00a420 Passport
...
0351e78cc00a420 Passport
1ffde78cc08d412 Passport <- Group Unkey
It also appears if another channel gets active that the information is sent every 9 frames
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e07f1b0a43c Passport <- Goto
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e07f1b0a43c Passport <- Goto
So far I figured out the xor mask for two bits (bit 0 is first non-sync bit).
Bit 12 xor 14
Bit 29 xor 3c
These do not seem to fit into the regular ltr check so far. The only other check is the 7th bit of the check (i.e. the extra bit) is a parity bit. If you count all the one bits in the 59 bits of the word it should come out to an even number. This should allow detection of single bit errors and all odd bit errors, 3 bits, 5 bits, etc. I do not know if Multinet also uses even parity.
73 Eric WB1HBU
That seems to fit because VoiceLink has two levels of service, a local one (regular LTR?) and a statewide roaming (Passport?). It also appears Marcus is using the license all frequencies for all sites method I have seen with other licenses. So looking at the FCC database it appears that Foxwoods and the various VoiceLink sites are active on the same frequencies.
There was not much traffic on the New London area site. There appeared to be only one talkgroup active on Friday. I need to see if I can get a fix on a good site in NE CT so the drive distance is reduced 8->.
Some things I noticed:
The Passport only channel seemed to send a burst about once per second. There is another frequency, 452.800, I received in the New London area that is about once every two seconds.
Transmission sequence
1c0680a8a8c4670 Passport <- Keyup Unit ID Talkgroup mapping?
0351e78cc00a420 Passport <- Group/Channel
0351e78cc00a420 Passport
...
0351e78cc00a420 Passport
1ffde78cc08d412 Passport <- Group Unkey
It also appears if another channel gets active that the information is sent every 9 frames
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e07f1b0a43c Passport <- Goto
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e78cc00a420 Passport
0351e07f1b0a43c Passport <- Goto
So far I figured out the xor mask for two bits (bit 0 is first non-sync bit).
Bit 12 xor 14
Bit 29 xor 3c
These do not seem to fit into the regular ltr check so far. The only other check is the 7th bit of the check (i.e. the extra bit) is a parity bit. If you count all the one bits in the 59 bits of the word it should come out to an even number. This should allow detection of single bit errors and all odd bit errors, 3 bits, 5 bits, etc. I do not know if Multinet also uses even parity.
73 Eric WB1HBU
The idle data that I get is almost identical.
I do get 300 bit increments (for lack of a better word) when I monitor the Marcus sites on idle.
1010110000011100000001011110000010101000101010001000111000000011111111111111101101011011011110110111001100110011010110101101011101110010001010001011110000111010010101101110000011000000010000110101010000101101001000000000011110101011110110100001001011011101110101101101101010110110111011101000000000000
I am trying to figure out what follows that common first line. At first I thought it was junk but it seems odd that it lasts 300 bits each time.
Also I got a SYNC of 000010000 followed by an identical line mixed in during one voice transmission:
101011000 00 00011000011 0101000 0000101010111000 0101 00010011111 000111111
000010000 00 00011000011 0101000 0000101010111000 0101 10001011001 01000000
101011000 00 00011000011 0101000 0000101010111000 0101 00010011111 000111111
000010000 00 00011000011 0101110 0000101010111000 0101 10001011001 01000000
3 repititions made me think it was not a decoding error.
All this info gathered by using the raw data mode and then breaking it up using MS Word.
chris gordon
granby ct
I do get 300 bit increments (for lack of a better word) when I monitor the Marcus sites on idle.
1010110000011100000001011110000010101000101010001000111000000011111111111111101101011011011110110111001100110011010110101101011101110010001010001011110000111010010101101110000011000000010000110101010000101101001000000000011110101011110110100001001011011101110101101101101010110110111011101000000000000
I am trying to figure out what follows that common first line. At first I thought it was junk but it seems odd that it lasts 300 bits each time.
Also I got a SYNC of 000010000 followed by an identical line mixed in during one voice transmission:
101011000 00 00011000011 0101000 0000101010111000 0101 00010011111 000111111
000010000 00 00011000011 0101000 0000101010111000 0101 10001011001 01000000
101011000 00 00011000011 0101000 0000101010111000 0101 00010011111 000111111
000010000 00 00011000011 0101110 0000101010111000 0101 10001011001 01000000
3 repititions made me think it was not a decoding error.
All this info gathered by using the raw data mode and then breaking it up using MS Word.
chris gordon
granby ct
Hello,
This past week I had a good field trip to CT and captured some more passport dumps.
I was also able to write a couple of programs that processes the data looking for check infomation. Using the programs I was able to figure out the check for 28 bits and I have possibles for 12 more. Unfortunely the bits are up in the frequency and talkgroup area that does not seem to change much. An I do not really see a pattern. It may take months to get all the bits.
If people could do some monitoring with LTRDump of a passport system for awhile I would appeciate it. I got most of NE Ct covered but Town of Bloomfield, SW CT, and systems outside of CT will be welcome.
One telltale sign of a Passport LTR is the repeater keying up about every 2 seconds when Idle.
73 Eric
This past week I had a good field trip to CT and captured some more passport dumps.
I was also able to write a couple of programs that processes the data looking for check infomation. Using the programs I was able to figure out the check for 28 bits and I have possibles for 12 more. Unfortunely the bits are up in the frequency and talkgroup area that does not seem to change much. An I do not really see a pattern. It may take months to get all the bits.
If people could do some monitoring with LTRDump of a passport system for awhile I would appeciate it. I got most of NE Ct covered but Town of Bloomfield, SW CT, and systems outside of CT will be welcome.
One telltale sign of a Passport LTR is the repeater keying up about every 2 seconds when Idle.
73 Eric
fmon
Silent Key Jan. 14, 2012
EricCottrell said:
Does this repeater keying up have any sound other than a squelch tail?
I have run LTRDump on Bloomfield's system for a while today but I am getting a huge number of "badcrc" lines. How long a run do you need? I have a couple of dumps from a fire call that have some good lines.
Hopefully tomorrow will be busier with the long weekend over. BPD is back to conventional so that makes it a bit harder to check it out.
chris
Hopefully tomorrow will be busier with the long weekend over. BPD is back to conventional so that makes it a bit harder to check it out.
chris
Hello,
Since this is a town system I would think there would be more activity tomorrow. Just run it for an hour or two during town business hours. Zip up the whole file and email it to me. I can process it and tell the bad lines.
73 Eric
Since this is a town system I would think there would be more activity tomorrow. Just run it for an hour or two during town business hours. Zip up the whole file and email it to me. I can process it and tell the bad lines.
73 Eric
Hello,
I was looking some more at the passport check and how it jumps around the BCH codes like regular LTR. In dumping a regular LTR system in Cranston I was getting Passport codes imbedded in the regular stream but I thought it may be a fluke until I saw this thread.
http://www.trunkedradio.net/groups/showthread.php?s=&threadid=1948
That got me to do some checking...
1c04a0 a8 a8c9f18 Passport
0 01110 00000 01001010 00001 0101000 1010 1000 1100 1001 1111 00011000
A Go to Home Group Free Check Passport Check
016c57985842146 Passport
0 00000 10110 11000101 01111 0011000 0101 1000 0100 0010 0001 01000110
016c5798580c022 Passport
0 00000 10110 11000101 01111 0011000 0101 1000 0000 1100 0000 00100010
016c5798580e40f Passport
0 00000 10110 11000101 01111 0011000 0101 1000 0000 1110 0100 00001111
...
1ffc57985885bd7 Passport
0 01111 11111 11000101 01111 0011000 0101 1000 1000 0101 1011 11010111
Interesting how these messages on a passport only system seem to use data that would be invalid to a regular LTR radio. Other LTR extensions use this method as well.
I did find a sequence match on the check codes! However the check does not come out correct on my captured data. I did find one of my calculated values differed from the regular LTR check value so I likely have some bad calculations.
From the description it appears in compatibility mode the first part of the frame has LTR information that a regular LTR can read (including a regular LTR check). The passport radio reads the whole frame. In passport only mode the first part of the frame is encoded so it is invalid for a regular LTR radio and contains passport information.
It appears frames starting with 1c0 are keyup and 1ff are end of transmission. It appears the data in the first part of a passport only frame does not follow the regular LTR definition much like other extended LTR coding.
Now to figure out why the check is not coming out right. A project for this week because it is bedtime.
73 Eric
I was looking some more at the passport check and how it jumps around the BCH codes like regular LTR. In dumping a regular LTR system in Cranston I was getting Passport codes imbedded in the regular stream but I thought it may be a fluke until I saw this thread.
http://www.trunkedradio.net/groups/showthread.php?s=&threadid=1948
That got me to do some checking...
1c04a0 a8 a8c9f18 Passport
0 01110 00000 01001010 00001 0101000 1010 1000 1100 1001 1111 00011000
A Go to Home Group Free Check Passport Check
016c57985842146 Passport
0 00000 10110 11000101 01111 0011000 0101 1000 0100 0010 0001 01000110
016c5798580c022 Passport
0 00000 10110 11000101 01111 0011000 0101 1000 0000 1100 0000 00100010
016c5798580e40f Passport
0 00000 10110 11000101 01111 0011000 0101 1000 0000 1110 0100 00001111
...
1ffc57985885bd7 Passport
0 01111 11111 11000101 01111 0011000 0101 1000 1000 0101 1011 11010111
Interesting how these messages on a passport only system seem to use data that would be invalid to a regular LTR radio. Other LTR extensions use this method as well.
I did find a sequence match on the check codes! However the check does not come out correct on my captured data. I did find one of my calculated values differed from the regular LTR check value so I likely have some bad calculations.
From the description it appears in compatibility mode the first part of the frame has LTR information that a regular LTR can read (including a regular LTR check). The passport radio reads the whole frame. In passport only mode the first part of the frame is encoded so it is invalid for a regular LTR radio and contains passport information.
It appears frames starting with 1c0 are keyup and 1ff are end of transmission. It appears the data in the first part of a passport only frame does not follow the regular LTR definition much like other extended LTR coding.
Now to figure out why the check is not coming out right. A project for this week because it is bedtime.
73 Eric
Hello,
Making some more progress. I was using a portable 7 element 70cm Ham beam on UHF and found I can pick up UHF LTR systems in Cranston, RI. With some fiddling I was able to get a Passport LTR site in RI weakly. So I put up a 6 element I had laying around on the roof and it was better but not great. I did a test run and was surprised I did get some good decodes. The main problem is lack of traffic.
I did another radio run in CT earlier this week. Instead of scanning the whole UHF band I put in suspected passport frequencies. It was sucessful and when combined with the RI data from a few weeks ago I think I have all but two bits figured out for the check. They are the area bit and the upper bit of the goto. There may still be some bad codes. During inital calculation I came up with the same check for two bits! I was able to do some crosschecking and eventually found a couple of bad check codes. A real intensive task but fortunely I wrote a couple of programs to help with the hunting. I need to get some more good data to see if the check is correct.
The 11 bits before the check appear to be the frequencies at the site. The step on the CT passport system appears to be 12.5 KHz with a base of 450 MHz. This data does not seem to indicate a free repeater.
From the little information I was able to gleem there can be 30 frequencies in the system and the radio does not have to have all the frequencies programmed in. I suspect that the site is transmitting site information during the 2 second data bursts. This system does not use the multinet system where the goto and free are frequency codes so there is a mapping that must be sent to say Repeater 1 is a certain frequency.
I suspect the "Talkgroup Mapping" is done by taking the lower 8 bits of the 16 bit group for the LTR compatible group and assigning a LTR compatible home channel. Since a 20 channel LTR system can only have a maximum of twenty users at a time then only 20 of the 256 groups with the same lower 8 bits could talk. So I think the field is split with the lower 8 bits in the regular LTR position and the upper 8 bits in the Passport section. Somewhere there are 16 bits for the unit ID.
I have added the check values to the LTRDump program and I am starting to add code to display the passport information like the other LTR systems. Still alot of work to do but I am getting results.
73 Eric
Making some more progress. I was using a portable 7 element 70cm Ham beam on UHF and found I can pick up UHF LTR systems in Cranston, RI. With some fiddling I was able to get a Passport LTR site in RI weakly. So I put up a 6 element I had laying around on the roof and it was better but not great. I did a test run and was surprised I did get some good decodes. The main problem is lack of traffic.
I did another radio run in CT earlier this week. Instead of scanning the whole UHF band I put in suspected passport frequencies. It was sucessful and when combined with the RI data from a few weeks ago I think I have all but two bits figured out for the check. They are the area bit and the upper bit of the goto. There may still be some bad codes. During inital calculation I came up with the same check for two bits! I was able to do some crosschecking and eventually found a couple of bad check codes. A real intensive task but fortunely I wrote a couple of programs to help with the hunting. I need to get some more good data to see if the check is correct.
The 11 bits before the check appear to be the frequencies at the site. The step on the CT passport system appears to be 12.5 KHz with a base of 450 MHz. This data does not seem to indicate a free repeater.
From the little information I was able to gleem there can be 30 frequencies in the system and the radio does not have to have all the frequencies programmed in. I suspect that the site is transmitting site information during the 2 second data bursts. This system does not use the multinet system where the goto and free are frequency codes so there is a mapping that must be sent to say Repeater 1 is a certain frequency.
I suspect the "Talkgroup Mapping" is done by taking the lower 8 bits of the 16 bit group for the LTR compatible group and assigning a LTR compatible home channel. Since a 20 channel LTR system can only have a maximum of twenty users at a time then only 20 of the 256 groups with the same lower 8 bits could talk. So I think the field is split with the lower 8 bits in the regular LTR position and the upper 8 bits in the Passport section. Somewhere there are 16 bits for the unit ID.
I have added the check values to the LTRDump program and I am starting to add code to display the passport information like the other LTR systems. Still alot of work to do but I am getting results.
73 Eric
Hello,
After looking at the log files some more I think I have the basic format to start using ltrtrunk to decode. Passport differs from Regular LTR and Multinet in that there are different types of frames with different information in some fields.
Basic Frame
9 bits - Sync (0x158)
2 bits - Unknown (seems to always be zero)
11 bits - Goto frequency
7 bits - Site ID?
16 bits - Group or MID
4 bits - Frame Type (0 = group, 1 = system info, 6 = MID [radio ID])
11 bits - Free Frequency or Neighbor Frequency
8 bit - Check
While listening to 461.9125 I picked up these frames
0ee45798584a75c 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1191 (464.887500)
0ee4503f634938e 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 02028 Type?: 06 Free: 1171 (464.637500)
0ee45798584a75c 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1191 (464.887500)
0ee457985806123 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 97 (451.212500)
0ee457985849343 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1171 (464.637500)
0ee45798584a75c 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1191 (464.887500)
0ee457985849343 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1171 (464.637500)
1ffc579858bb9e7 00 00 GoTo: 2047 (475.587500) Site?: 010 ID: 62219 Type?: 01 Free: 953 (461.912500)
Type 6 frames occur occasionally and seem to be Radio IDs.
The Type 1 frame above starting with 1f is unkey indication.
The other type 1 frame occurs in the idle burst and occasionally when there is traffic. I suspect it is giving neighbor information as the frequencies are not the same as the free frequencies when there is traffic. It appears the Goto, site, and ID fields are used for different purposes.
1c0630a8a8c57b2 00 00 GoTo: 1793 (472.412500) Site?: 070 ID: 005397 Type?: 01 Free: 1111 (463.887500)
1c0630a8a8c4693 00 00 GoTo: 1793 (472.412500) Site?: 070 ID: 005397 Type?: 01 Free: 1094 (463.675000)
1c0630a8a88e040 00 00 GoTo: 1793 (472.412500) Site?: 070 ID: 005397 Type?: 01 Free: 224 (452.800000)
If I look at the Bloomfield Passport the frames have a free frequency of zero so I suspect it means there are no neighbors.
1c000800a880084 00 00 GoTo: 1792 (472.400000) Site?: 001 ID: 000021 Type?: 01 Free: 0 (450.000000)
CW ID
0ee637fff84a700 00 00 GoTo: 953 (461.912500) Site?: 070 ID: 65535 Type?: 00 Free: 1191 (464.887500)
0ee637fff80617f 00 00 GoTo: 953 (461.912500) Site?: 070 ID: 65535 Type?: 00 Free: 97 (451.212500)
0ee637fff84931f 00 00 GoTo: 953 (461.912500) Site?: 070 ID: 65535 Type?: 00 Free: 1171 (464.637500)
Next week I will be going down to the Philly area for the Winter SWLFest. It appears there are several passport systems in PA and NJ that I may be able to receive.
73 Eric
After looking at the log files some more I think I have the basic format to start using ltrtrunk to decode. Passport differs from Regular LTR and Multinet in that there are different types of frames with different information in some fields.
Basic Frame
9 bits - Sync (0x158)
2 bits - Unknown (seems to always be zero)
11 bits - Goto frequency
7 bits - Site ID?
16 bits - Group or MID
4 bits - Frame Type (0 = group, 1 = system info, 6 = MID [radio ID])
11 bits - Free Frequency or Neighbor Frequency
8 bit - Check
While listening to 461.9125 I picked up these frames
0ee45798584a75c 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1191 (464.887500)
0ee4503f634938e 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 02028 Type?: 06 Free: 1171 (464.637500)
0ee45798584a75c 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1191 (464.887500)
0ee457985806123 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 97 (451.212500)
0ee457985849343 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1171 (464.637500)
0ee45798584a75c 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1191 (464.887500)
0ee457985849343 00 00 GoTo: 953 (461.912500) Site?: 010 ID: 62219 Type?: 00 Free: 1171 (464.637500)
1ffc579858bb9e7 00 00 GoTo: 2047 (475.587500) Site?: 010 ID: 62219 Type?: 01 Free: 953 (461.912500)
Type 6 frames occur occasionally and seem to be Radio IDs.
The Type 1 frame above starting with 1f is unkey indication.
The other type 1 frame occurs in the idle burst and occasionally when there is traffic. I suspect it is giving neighbor information as the frequencies are not the same as the free frequencies when there is traffic. It appears the Goto, site, and ID fields are used for different purposes.
1c0630a8a8c57b2 00 00 GoTo: 1793 (472.412500) Site?: 070 ID: 005397 Type?: 01 Free: 1111 (463.887500)
1c0630a8a8c4693 00 00 GoTo: 1793 (472.412500) Site?: 070 ID: 005397 Type?: 01 Free: 1094 (463.675000)
1c0630a8a88e040 00 00 GoTo: 1793 (472.412500) Site?: 070 ID: 005397 Type?: 01 Free: 224 (452.800000)
If I look at the Bloomfield Passport the frames have a free frequency of zero so I suspect it means there are no neighbors.
1c000800a880084 00 00 GoTo: 1792 (472.400000) Site?: 001 ID: 000021 Type?: 01 Free: 0 (450.000000)
CW ID
0ee637fff84a700 00 00 GoTo: 953 (461.912500) Site?: 070 ID: 65535 Type?: 00 Free: 1191 (464.887500)
0ee637fff80617f 00 00 GoTo: 953 (461.912500) Site?: 070 ID: 65535 Type?: 00 Free: 97 (451.212500)
0ee637fff84931f 00 00 GoTo: 953 (461.912500) Site?: 070 ID: 65535 Type?: 00 Free: 1171 (464.637500)
Next week I will be going down to the Philly area for the Winter SWLFest. It appears there are several passport systems in PA and NJ that I may be able to receive.
73 Eric
remedy44
Member
Here is one from a 217 Mhz Passport System in Chicago
lots of errors in this file do to not having the right data slicer
lots of errors in this file do to not having the right data slicer
Hello,
I want to add better Passport decoding before I release Beta 3. I have been "almost there" for weeks now.
It is interesting to compare my notes to posted information about passport. Although the descriptions
are general I was able to fit descriptions into the bits I have seen. It seems I was on the right track in decoding passport.
My take on how the 68 Bit data frame breaks down.
9 Bits Sync (158hex)
2 Bits DCC (Area)
11 Bits GoTo Frequency
7 Bits System ID (really a site ID)
16 Bits Group/Mobile ID
4 Bits Message Type
11 Bits Free/Neighbor Frequency
8 Bits Check
I notice that the bit sequence is similar to Regular LTR (Area first, Goto, Group, Free, finally Check).
DCC "Digital Color Code" are the bits I do not have the values to calculate the check. All the systems I have monitored so far have these bits set to zero. This is like the area bit. I was not sure why these bits were zero, now I do.
GoTo Frequency is the frequency in use for a call. Out of range values are used for other data. All ones (2047) is used for end of transmission similar to other LTR Systems. 1792 and 1793 (both decimal) frequency codes are used for "Idle Message". I suspect there is a difference in meaning between 1792 and 1793 codes. 1793 seems to be sent if the channel is not busy. 1792 are inserted in the data stream when the channel is active.
System ID is really a site ID. Bloomfield CT is a single site and has a System ID of one. VoiceLink in CT has site ids of 10, 20, 40, 50, 60, and 70. No doubt there is a 30 but I have not received it yet. For Idle Messages the System ID is the site System ID. Otherwise it appears to be the home System ID of the group/unit using the system. I am getting the impression that any passport trunker program needs to use the System ID with the Group/Mobile ID to get an unique group/unit identifier on a multiple site system.
Group/Mobile ID. With the Groups being in the upper part of the 16 bit range and the Mobile IDs being in the lower part of the 16 bit range I suspected they share the same ID space like another trunking system. Unit to Unit calls look like group calls but the ID is a low number mobile ID instead of a high number group ID. CW Id group is all ones (65535). For Idle Messages it appears the lower 8 bits represent the current site configuration and the upper 8 bits the neighbor site configuration. Possibly the lower 4 bits in the site configuration is the Frequency Band Code. Bloomfield has zero in the upper 8 bits and the lower 8 bits are split as 1 for the upper 4 bits and 5 for the lower 4 bits. Voice Link has the same pattern of 1 in the upper 4 bits and 5 in the lower 4 bits for both the upper and lower 8 bits. I need to get dumps of systems on the other frequency ranges to see if this is true.
Message Type. 0 = Group/Dest ID is in Group ID 1 = System messages (Idle, End of Transmission, etc) 6 = Calling Mobile ID is in Group ID. There are other codes but they are not known.
Free/Neighbor Frequency Free Frequency unless it is an Idle message then it is a Neighbor site frequency.
As you can see it is a more complex protocol than regular LTR because some fields have multiple uses depending on the message.
73 Eric
I want to add better Passport decoding before I release Beta 3. I have been "almost there" for weeks now.
It is interesting to compare my notes to posted information about passport. Although the descriptions
are general I was able to fit descriptions into the bits I have seen. It seems I was on the right track in decoding passport.
My take on how the 68 Bit data frame breaks down.
9 Bits Sync (158hex)
2 Bits DCC (Area)
11 Bits GoTo Frequency
7 Bits System ID (really a site ID)
16 Bits Group/Mobile ID
4 Bits Message Type
11 Bits Free/Neighbor Frequency
8 Bits Check
I notice that the bit sequence is similar to Regular LTR (Area first, Goto, Group, Free, finally Check).
DCC "Digital Color Code" are the bits I do not have the values to calculate the check. All the systems I have monitored so far have these bits set to zero. This is like the area bit. I was not sure why these bits were zero, now I do.
GoTo Frequency is the frequency in use for a call. Out of range values are used for other data. All ones (2047) is used for end of transmission similar to other LTR Systems. 1792 and 1793 (both decimal) frequency codes are used for "Idle Message". I suspect there is a difference in meaning between 1792 and 1793 codes. 1793 seems to be sent if the channel is not busy. 1792 are inserted in the data stream when the channel is active.
System ID is really a site ID. Bloomfield CT is a single site and has a System ID of one. VoiceLink in CT has site ids of 10, 20, 40, 50, 60, and 70. No doubt there is a 30 but I have not received it yet. For Idle Messages the System ID is the site System ID. Otherwise it appears to be the home System ID of the group/unit using the system. I am getting the impression that any passport trunker program needs to use the System ID with the Group/Mobile ID to get an unique group/unit identifier on a multiple site system.
Group/Mobile ID. With the Groups being in the upper part of the 16 bit range and the Mobile IDs being in the lower part of the 16 bit range I suspected they share the same ID space like another trunking system. Unit to Unit calls look like group calls but the ID is a low number mobile ID instead of a high number group ID. CW Id group is all ones (65535). For Idle Messages it appears the lower 8 bits represent the current site configuration and the upper 8 bits the neighbor site configuration. Possibly the lower 4 bits in the site configuration is the Frequency Band Code. Bloomfield has zero in the upper 8 bits and the lower 8 bits are split as 1 for the upper 4 bits and 5 for the lower 4 bits. Voice Link has the same pattern of 1 in the upper 4 bits and 5 in the lower 4 bits for both the upper and lower 8 bits. I need to get dumps of systems on the other frequency ranges to see if this is true.
Message Type. 0 = Group/Dest ID is in Group ID 1 = System messages (Idle, End of Transmission, etc) 6 = Calling Mobile ID is in Group ID. There are other codes but they are not known.
Free/Neighbor Frequency Free Frequency unless it is an Idle message then it is a Neighbor site frequency.
As you can see it is a more complex protocol than regular LTR because some fields have multiple uses depending on the message.
73 Eric
Hello,
I got feedback that a passport system using a dcc of 1 decodes so one guess on the check value is correct.
I had several days of "lift" recently and was able to monitor the passport system down in CT without leaving home! I uncovered a few things.
On site 70 the frequency 451.2125 appears to be the home channel for the groups local to the site. A different frequency, 451.8625, is in the neighbor list of adjacent sites. If a roaming radio is searching for another site it will use 451.8625 for site 70. 451.8625 does show various unknown data types for groups mostly from other sites. I spotted an interesting sequence. Passport will transmit data multiple times to increase the chance of decoding.
Type 1 messages with site-group of 40-2244
Type 1 messages with site-group of 40-62047
Type 11 messages with site-group of 40-2244
Type 1 messages with site-group of 40-2244
Type 3 messages with site-group of 40-2244 and a goto channel of 461.9125
Type 1 messages with site-group of 40-2244 and a goto channel of 461.9125
Group 40-62047 very briefly becomes active on 451.2125.
I get group 40-62047 activity for awhile on 461.9125 and then it goes away. It appears that unit 40-2244 registered or affiliated with site 70 for awhile and resulted in it's group being put on site 70.
It looks like a Type 1 message is an acknowledgement or system information. Type 11 message is register or affiliate and is used for both local groups and roaming groups. Type 3 message assigns a home channel to a roaming unit and it appears the same channel is used on a site for all roaming units.
Alot of messages on 451.8625 have 2042 (decimal) in the free field. I take it to mean that no other free channel is available because it is outside the valid frequency range. I also noticed that 451.8625 does not show up in the free field so it appears the "neighbor" frequency is dedicated.
I noticed alot a type 5 messages. I wonder if this is a page to a mobile.
So to get a complete picture of a site the "control channel" scanner has to monitor two or three frequencies. I can now see how a radio can use a adjacent site without having the frequencies programmed. The radio just decodes and stores data from the system.
73 Eric
I got feedback that a passport system using a dcc of 1 decodes so one guess on the check value is correct.
I had several days of "lift" recently and was able to monitor the passport system down in CT without leaving home! I uncovered a few things.
On site 70 the frequency 451.2125 appears to be the home channel for the groups local to the site. A different frequency, 451.8625, is in the neighbor list of adjacent sites. If a roaming radio is searching for another site it will use 451.8625 for site 70. 451.8625 does show various unknown data types for groups mostly from other sites. I spotted an interesting sequence. Passport will transmit data multiple times to increase the chance of decoding.
Type 1 messages with site-group of 40-2244
Type 1 messages with site-group of 40-62047
Type 11 messages with site-group of 40-2244
Type 1 messages with site-group of 40-2244
Type 3 messages with site-group of 40-2244 and a goto channel of 461.9125
Type 1 messages with site-group of 40-2244 and a goto channel of 461.9125
Group 40-62047 very briefly becomes active on 451.2125.
I get group 40-62047 activity for awhile on 461.9125 and then it goes away. It appears that unit 40-2244 registered or affiliated with site 70 for awhile and resulted in it's group being put on site 70.
It looks like a Type 1 message is an acknowledgement or system information. Type 11 message is register or affiliate and is used for both local groups and roaming groups. Type 3 message assigns a home channel to a roaming unit and it appears the same channel is used on a site for all roaming units.
Alot of messages on 451.8625 have 2042 (decimal) in the free field. I take it to mean that no other free channel is available because it is outside the valid frequency range. I also noticed that 451.8625 does not show up in the free field so it appears the "neighbor" frequency is dedicated.
I noticed alot a type 5 messages. I wonder if this is a page to a mobile.
So to get a complete picture of a site the "control channel" scanner has to monitor two or three frequencies. I can now see how a radio can use a adjacent site without having the frequencies programmed. The radio just decodes and stores data from the system.
73 Eric
Hello,
It has been a long time since I posted any additional information about Passport. This information comes from monitoring actual passport systems. All the easier stuff is figured out. As time goes on it will take logging systems that use seldom used features to progress.
I was overjoyed when a person out in CA found a Passport LTR site that uses a DCC of 3. Digital Color Code (DCC) is like the area bit in regular LTR. It is used when more than one nearby site shares a frequency. I have seen DCC values of 0 and 1. Because use of DCC values of 2 and 3 are rarer I had to guess at the check value based on the pattern I saw. It turns out I was off by one bit.
This is the Check value for each bit. The check is really 7 bits with the 8th bit as parity. Due to the magic of xor math you can xor the full 8 bits and get both the check and the parity.
6e DCC Bit 1
bf DCC Bit 0
d6 LCN Bit 10
e3 LCN Bit 9
f8 LCN Bit 8
7c LCN Bit 7
3e LCN Bit 6
97 LCN Bit 5
c2 LCN Bit 4
e9 LCN Bit 3
75 LCN Bit 2
3b LCN Bit 1
94 LCN Bit 0
4a Site Bit 6
ad Site Bit 5
57 Site Bit 4
a2 Site Bit 3
d9 Site Bit 2
6d Site Bit 1
37 Site Bit 0
92 Group Bit 15
c1 Group Bit 14
61 Group Bit 13
31 Group Bit 12
19 Group Bit 11
0d Group Bit 10
07 Group Bit 9
8a Group Bit 8
cd Group Bit 7
67 Group Bit 6
ba Group Bit 5
d5 Group Bit 4
6b Group Bit 3
bc Group Bit 2
5e Group Bit 1
a7 Group Bit 0
da Type Bit 3
e5 Type Bit 2
73 Type Bit 1
b0 Type Bit 0
58 Free Bit 10
2c Free Bit 9
16 Free Bit 8
83 Free Bit 7
c8 Free Bit 6
64 Free Bit 5
32 Free Bit 4
91 Free Bit 3
49 Free Bit 2
25 Free Bit 1
13 Free Bit 0
I had a nice trip down to the Washington DC area and monitored some Passport LTR systems. I was able to figure out some more stuff. This is my current understanding of how Passport works.
Three frequencies of interest are the registration channel, the remote home channel, and the home channel. They do not have to be unique frequencies.
When a passport radio powers up it finds the nearest site and registers. Some sites have one frequency dedicated for registration so that traffic on the home channel will not delay registration. As I mentioned earlier in the thread type 11 messages indicate a radio unit has registered with the site. This is followed by type 1 message to indicate an acknowledge that the radio has received it. These messages occur both on the home channel and the registration channel (if present). If a unit registers with a remote site a home channel will be assigned by using type 3 messages. This is again followed by type 1 messages.
It also appears that type 9 messages are data transmissions. The message types I have figured out are:
0000 (0) Group call
0001 (1) System messages (Unkey, Ack, Neighbor)
0010 (2) Console? Group Call
0011 (3) Remote Home Assign
0101 (5) Paging?
0110 (6) Mobile ID of unit transmitting
1001 (9) Data
1011 (11) Registration OK
Looking at the types it appears that bit 0 indicates if it is a system message or not.
All the bit 0 set (odd numbers) codes so far indicate a message from the system, It could be that types 0, 2, and 4 represent 3 levels of priority for calls.
As you can see there are missing codes that may never be determined. There should be a message type that disables or "stuns" a radio.
The Mobile IDs and Group IDs share the same 16 bit codespace like on a MPT-1327 system. Group IDs start at 65535 and go down. Mobile IDs start at zero and goes up. Group ID 65535 is reserved for the CW IDer. There could be other reserved groups. An ICall is the same as a Group Call with a Mobile ID instead of a Group ID.
Another area of interest is LCN decoding. The system has a frequency map that maps the LCNs to frequencies
Band
216 For LCN 1 through 320 Freq = LCN * 0.00625 + 216.0 if LCN is above 320 Freq = (LCN - 320) * 0.00625 + 220.0
400 Freq = LCN * 0.0125 + 400.0
450 Freq = LCN * 0.0125 + 450.0
Some LCN codes have special meaning. Zero in the free lcn means all frequencies are busy (like regular LTR). It seems LCN 2042 means no other frequencies are available. 2042 is used on the registration frequency in the free lcn when the channel is active since there is only one registration frequency. LCN 2047 is the unkey message. LCN 1792 and 1793 are used for neighbor messages. It appears that the top 256 LCN codes (1792 to 2047) are used for special purposes. As you can see I only figured out a few of the common ones.
Yet another area is the neighbor information. This is transmitted to provide radios with information on the site and neighboring sites. I am starting to see patterns here as well. The free lcn indicates the neighbor registration frequency with zero meaning none. The site is the site number. The 16 bit group number gives information about the site and the neighbor site. The lower 8 bits deals with the site and the upper 8 bits deals with the neighbor. On 216 MHz sites it seems the 16 bit group value is 7453 or 7581. If you look at it bitwise they are:
Neighbor This Site
00011101 00011101
00011101 10011101
The difference is with bit 7 and it is set on frequencies that are registration frequencies. So bit 7 indicates the registration frequency.
A passport system can have 127 sites. A maximum of 8 systems can be networked together. I suspect that bits 6 to 4 and 14 to 12 indicate the network id of the site and neighbor respectively. Most every system so far has a network id of one and it may take a massive 128+ site system somewhere to figure out if I am correct.
Bits 11 to 8 and 3 to 0 seem to be the same on systems on the same band. So far I monitored
Value Band
0101 (5) 450
1011 (11) 400
1101 (13) 216
The value of 5 matches the band code used for 450 to 470. The value of 11 does not match the band code of 2 used
for 400. It could be the bits tend to be set due to things normally configured when using the band, It would be nice to find a 800 MHz or 900 MHz passport system to see if the codes are 0 and 1.
73 Eric
It has been a long time since I posted any additional information about Passport. This information comes from monitoring actual passport systems. All the easier stuff is figured out. As time goes on it will take logging systems that use seldom used features to progress.
I was overjoyed when a person out in CA found a Passport LTR site that uses a DCC of 3. Digital Color Code (DCC) is like the area bit in regular LTR. It is used when more than one nearby site shares a frequency. I have seen DCC values of 0 and 1. Because use of DCC values of 2 and 3 are rarer I had to guess at the check value based on the pattern I saw. It turns out I was off by one bit.
This is the Check value for each bit. The check is really 7 bits with the 8th bit as parity. Due to the magic of xor math you can xor the full 8 bits and get both the check and the parity.
6e DCC Bit 1
bf DCC Bit 0
d6 LCN Bit 10
e3 LCN Bit 9
f8 LCN Bit 8
7c LCN Bit 7
3e LCN Bit 6
97 LCN Bit 5
c2 LCN Bit 4
e9 LCN Bit 3
75 LCN Bit 2
3b LCN Bit 1
94 LCN Bit 0
4a Site Bit 6
ad Site Bit 5
57 Site Bit 4
a2 Site Bit 3
d9 Site Bit 2
6d Site Bit 1
37 Site Bit 0
92 Group Bit 15
c1 Group Bit 14
61 Group Bit 13
31 Group Bit 12
19 Group Bit 11
0d Group Bit 10
07 Group Bit 9
8a Group Bit 8
cd Group Bit 7
67 Group Bit 6
ba Group Bit 5
d5 Group Bit 4
6b Group Bit 3
bc Group Bit 2
5e Group Bit 1
a7 Group Bit 0
da Type Bit 3
e5 Type Bit 2
73 Type Bit 1
b0 Type Bit 0
58 Free Bit 10
2c Free Bit 9
16 Free Bit 8
83 Free Bit 7
c8 Free Bit 6
64 Free Bit 5
32 Free Bit 4
91 Free Bit 3
49 Free Bit 2
25 Free Bit 1
13 Free Bit 0
I had a nice trip down to the Washington DC area and monitored some Passport LTR systems. I was able to figure out some more stuff. This is my current understanding of how Passport works.
Three frequencies of interest are the registration channel, the remote home channel, and the home channel. They do not have to be unique frequencies.
When a passport radio powers up it finds the nearest site and registers. Some sites have one frequency dedicated for registration so that traffic on the home channel will not delay registration. As I mentioned earlier in the thread type 11 messages indicate a radio unit has registered with the site. This is followed by type 1 message to indicate an acknowledge that the radio has received it. These messages occur both on the home channel and the registration channel (if present). If a unit registers with a remote site a home channel will be assigned by using type 3 messages. This is again followed by type 1 messages.
It also appears that type 9 messages are data transmissions. The message types I have figured out are:
0000 (0) Group call
0001 (1) System messages (Unkey, Ack, Neighbor)
0010 (2) Console? Group Call
0011 (3) Remote Home Assign
0101 (5) Paging?
0110 (6) Mobile ID of unit transmitting
1001 (9) Data
1011 (11) Registration OK
Looking at the types it appears that bit 0 indicates if it is a system message or not.
All the bit 0 set (odd numbers) codes so far indicate a message from the system, It could be that types 0, 2, and 4 represent 3 levels of priority for calls.
As you can see there are missing codes that may never be determined. There should be a message type that disables or "stuns" a radio.
The Mobile IDs and Group IDs share the same 16 bit codespace like on a MPT-1327 system. Group IDs start at 65535 and go down. Mobile IDs start at zero and goes up. Group ID 65535 is reserved for the CW IDer. There could be other reserved groups. An ICall is the same as a Group Call with a Mobile ID instead of a Group ID.
Another area of interest is LCN decoding. The system has a frequency map that maps the LCNs to frequencies
Band
216 For LCN 1 through 320 Freq = LCN * 0.00625 + 216.0 if LCN is above 320 Freq = (LCN - 320) * 0.00625 + 220.0
400 Freq = LCN * 0.0125 + 400.0
450 Freq = LCN * 0.0125 + 450.0
Some LCN codes have special meaning. Zero in the free lcn means all frequencies are busy (like regular LTR). It seems LCN 2042 means no other frequencies are available. 2042 is used on the registration frequency in the free lcn when the channel is active since there is only one registration frequency. LCN 2047 is the unkey message. LCN 1792 and 1793 are used for neighbor messages. It appears that the top 256 LCN codes (1792 to 2047) are used for special purposes. As you can see I only figured out a few of the common ones.
Yet another area is the neighbor information. This is transmitted to provide radios with information on the site and neighboring sites. I am starting to see patterns here as well. The free lcn indicates the neighbor registration frequency with zero meaning none. The site is the site number. The 16 bit group number gives information about the site and the neighbor site. The lower 8 bits deals with the site and the upper 8 bits deals with the neighbor. On 216 MHz sites it seems the 16 bit group value is 7453 or 7581. If you look at it bitwise they are:
Neighbor This Site
00011101 00011101
00011101 10011101
The difference is with bit 7 and it is set on frequencies that are registration frequencies. So bit 7 indicates the registration frequency.
A passport system can have 127 sites. A maximum of 8 systems can be networked together. I suspect that bits 6 to 4 and 14 to 12 indicate the network id of the site and neighbor respectively. Most every system so far has a network id of one and it may take a massive 128+ site system somewhere to figure out if I am correct.
Bits 11 to 8 and 3 to 0 seem to be the same on systems on the same band. So far I monitored
Value Band
0101 (5) 450
1011 (11) 400
1101 (13) 216
The value of 5 matches the band code used for 450 to 470. The value of 11 does not match the band code of 2 used
for 400. It could be the bits tend to be set due to things normally configured when using the band, It would be nice to find a 800 MHz or 900 MHz passport system to see if the codes are 0 and 1.
73 Eric
Would I get a different subaudible data dump on the input side of the repeater or is the subaudible data retransmitted over the repeater? Will your correction of the check bit help eliminate the jumping between different LTR types in LTRDump? Thanks for your work.
chris gordon
granby ct
chris gordon
granby ct
Hello,
The radio uses a different frame length on the input side. The controller generates all the data on the repeater output.
73 Eric
The radio uses a different frame length on the input side. The controller generates all the data on the repeater output.
73 Eric
PPfactoryGuy
Member
- Joined
- Nov 2, 2004
- Messages
- 1
- Reaction score
- 0
Passport Decoder
Hi Eric,
I see you are working hard at PassPort! Remember PassPort is always changing!!
One thing I wonder?? Everybody on this board calls PassPort by name while associating it with LTR. They say LTR Passport and/or Passport LTR, Why???? Just because the LTR and the Passport protocol are using the same subaubile region in the radio spectrum doesn't mean they are the same. Just because a group of people all ride the bus to work each day doesn't mean they all are doctors or maybe garbage men. LTR and the very different PassPort protocol may use the same data transport mechanism (sub-aubile data below 300Hz), but that doesn't mean they are the same in any way.
I C U
Hi Eric,
I see you are working hard at PassPort! Remember PassPort is always changing!!
One thing I wonder?? Everybody on this board calls PassPort by name while associating it with LTR. They say LTR Passport and/or Passport LTR, Why???? Just because the LTR and the Passport protocol are using the same subaubile region in the radio spectrum doesn't mean they are the same. Just because a group of people all ride the bus to work each day doesn't mean they all are doctors or maybe garbage men. LTR and the very different PassPort protocol may use the same data transport mechanism (sub-aubile data below 300Hz), but that doesn't mean they are the same in any way.
I C U
Hello,
Passport is grouped with LTR for the same reasons that Multi-Net is grouped with LTR. They use similar signal parameters (modulation, bit rate, sync word, 7 bit check,etc) but different data frame sizes. They use a parity bit like extended messages in Regular LTR. In both cases the designers started with Regular LTR and improved it by changing the data frames. Backwards compatibility was not a requirement. "Extended" LTR improves LTR by adding messages that are ignored by Regular LTR radios and thus maintains compatibility.
Features may be added to Passport but the basic protocol is not likely to change. Protocol designers tend to use reserved codes or combinations that are illegal in the existing protocol for new features. Unless the company markets the changes as a new system (Passport II) then it is just making more work and creating problems. There are just too many radios on the market. Also I doubt system operators would upgrade if the current system works and it means flashing thousands of radios.
For example, Motorola uses the same signal format from a Type 1 system to the OmniLink system. New Features and call types meant more messages in the later types of systems. Type 2 uses a different call message but it was not implemented by reusing the Type 1 call message. Trunker was modified to handle the new messages while still decoding older systems.
73 Eric
Passport is grouped with LTR for the same reasons that Multi-Net is grouped with LTR. They use similar signal parameters (modulation, bit rate, sync word, 7 bit check,etc) but different data frame sizes. They use a parity bit like extended messages in Regular LTR. In both cases the designers started with Regular LTR and improved it by changing the data frames. Backwards compatibility was not a requirement. "Extended" LTR improves LTR by adding messages that are ignored by Regular LTR radios and thus maintains compatibility.
Features may be added to Passport but the basic protocol is not likely to change. Protocol designers tend to use reserved codes or combinations that are illegal in the existing protocol for new features. Unless the company markets the changes as a new system (Passport II) then it is just making more work and creating problems. There are just too many radios on the market. Also I doubt system operators would upgrade if the current system works and it means flashing thousands of radios.
For example, Motorola uses the same signal format from a Type 1 system to the OmniLink system. New Features and call types meant more messages in the later types of systems. Type 2 uses a different call message but it was not implemented by reusing the Type 1 call message. Trunker was modified to handle the new messages while still decoding older systems.
73 Eric
- Status
Similar threads
