LTR Passport Decoder Project

[slicerwizard]

Which program? (just wondering if you're in the right thread)

 

[slicerwizard]

16 - not defined

12, 14, and 16 are not defined in the Passport 2.8 manual, but there is a VHF band that it does not tell us which plan it is. It should be one of those three.

There is no band 16 - the bandplan fields only use four bits.

 

[kd5dga]

I am using LTR analyser 1.6.

 

[slicerwizard]

Which is better;
Use a trunk tracking scanner trunking a LTR system while running the program?
or
set a single LTR frequency and monitor with the program?
I am using a pro92 (version 3.28) discriminator tapped trunking a LTR system.

That would depend on what you were trying to accomplish. If your scanner is in LTR mode, you obviously already know the LCN's. If you want to see what traffic a channel carries, park on it. If you want to log all active groups, scan away (in search mode)

Personally, I program all system channels as a conventional system and let the scanner run through all of them. That finds all active group ID's.

BTW, we're in the wrong thread (should be here: http://www.radioreference.com/forums/showthread.php?t=90337 )

 

[inigo88]

Hello again guys! Thank you for the earlier clarification slicerwizard, I've read the IFR2975 manuals that were posted here and I think I have a much better understanding of the protocol, and how the official terminology coincides with the various incarnations of the Passport "Outgoing Signal Message" (aka OSW). I'm still very much interested in figuring out the functions of the unknown system type messages, and have many more questions...

For the record in this thread, I've been trying to map out each occurance of an OSW based on "call status" (message type), since they change. So far I've got the following:

Basic Structure of Passport OSW - 68 bits total, with the (0x158) sync bit omitted, ends up being 59 bits:

| DCC    | GOTO LCN  | ASID or HSID | TG ID / MIN ID | Call Status | FREE LCN  | CRC+Parity |
| 2 bits |  11 bits  |   7 bits     |     16 bits    |   4 bits    |  11 bits  |  8 bits    |

ASID = "Affiliated System ID"
HSID = "Home System ID"

Passport seems to define what would normally be called a site a "System", and what would normally be called a system a "Wide Area Network." Therefore, ASID = Current Site Number, and HSID = Home Site Number, and this field is variable based on the Message Type ("call status?").

The following 16 bit section is shared between talkgroup ID, Mobile Identification Number (MIN) and the System Parameters section of an Idle OSW, depending on the message type.

I believe "Call Status" is the same thing as the 4 bit message type.

Type 0 - Group Call:

| DCC   | GOTO LCN | HSID  | Talkgroup ID | Type = 0 | FREE LCN | CRC+Parity |
| 2 bit |  11 bit  | 7 bit |    16 bit    |  4 bit   |  11 bit  |  8 bit     |

Note that the site # is the HOME System ID - the home site # of that group (and in the case of the networked system I monitor - most likely where the call originally took place) - not the current site number that it was received on. As Eric said, if Free = 0, then all channels are busy (so there are no more FREE CHs left).

Group Call OSWs are immediately followed by a Mobile Identification Number (Radio ID) type 6 message, identifying the MIN and the HSID it is transmiting on.

| DCC   | GOTO LCN | HSID  |   MIN (RID)  | Type = 6 | FREE LCN | CRC+Parity |
| 2 bit |  11 bit  | 7 bit |    16 bit    |  4 bit   |  11 bit  |  8 bit     |

Type 1 - System Message - IDLE, ACK or UNKEY:

IDLE OSW - Neighbor Message:

| DCC   | Normal or   | ASID  | "System Parameters" | Type = 1       | Neighbor     | CRC+Parity |
| 2 bit | Forced Idle | 7 bit | Neighbor |  Current | System Message | Registering  |  8 bit     |
|       |   11 bit    |       |  8 bit   |   8 bit  |   4 bit        | LCN - 11 bit |            |

Normal/Forced Idle can be read in either Hex or Decimal:

Hex: | Dec: |
-------------
 701 | 1793 = "Normal Idle" (Channel Idle)
 700 | 1792 = "Forced Idle" (Channel Busy)

ASID = Current Site

"System Parameters" uses the 16 bit Talkgroup/Radio ID block to include the modulation and bandplan information for the neighbor site and current site. Additionally, System Parameters also specifies whether or not the current frequency is the Registering channel for the current site. It is broken into two 8 bit groups, which are most easily read in hexidecimal. The first (left) group is the neighbor information, and the second (right side) group is the current site information. Each 8 bit group makes a two digit hexidecimal number. The first digit is frequency modulation, and can be either 0 or 1. 0 = FM, while 1 = NFM. The second digit is the site's bandplan, and this took me some thought to realize, but because it's in Hex, the highest bandplan number for passport (Decimal 15 for 700 MHz) is also the highest single digit hex number (F). Finally, the 1st digit of the current site group (current site modulation) can also be used to indicate whether or not the current frequency is the registering channel for the current site. It does this by adding 8 to the modulation number.

Here is a system parameter example (in hex):

 Nbr | Current |
----------------
 1 5 | 1 5
 ^ ^   ^ ^
 | |   | |
 | |   | Current Bandplan
 | |   Current Modulation (+8 indicates Registering)
 | |
 | Neighbor Bandplan
 Neighbor Modulation

As an example, I've put together the following table of possible System Parameters values based on a 450 MHz system bandplan (the one I'm able to monitor):

Hexidecimal | Decimal | Description
--------------------------------------------------------------------
  1515      | 5397    | Neighbor NFM, 450 MHz. Current NFM, 450 MHz.
  1505      | 5381    | Neighbor NFM, 450 MHz. Current FM, 450 MHz.
  1595      | 5525    | Neighbor NFM, 450 MHz. Current NFM, Registering, 450 MHz.

(I haven't seen the following yet but they fit this configuration. Can anyone else confirm them?)

  1585      | 5509    | Neighbor NFM, 450 MHz. Current FM, Registering, 450 MHz.
  0505      | 1285    | Neighbor and Current FM and 450 MHz.
  0515      | 1301    | Neighbor FM, 450 MHz. Current NFM, 450 MHz.
----------------------------------------------------------------------

Thanks slicerwizard for explaining the hex conversion and how system parameters worked - as you can see the numbers are pretty confusing in decimal notation and I had no idea what their significance was.

ACK - Acknowledgement:

| DCC   | GOTO LCN | HSID  |   Radio ID (MIN)  | Type = 1 | FREE LCN | CRC+Parity |
| 2 bit |  11 bit  | 7 bit |    16 bit         |  4 bit   |  11 bit  |  8 bit     |

So far most of the ACKs I've seen are OSWs from the trunking system acknowledging radio affiliations on the registering channel, though I have seen some randomly with radio IDs on the local and remote home channels of various local sites. A question on this to follow...

UNKEY:

| DCC   | UNKEY MSG | HSID  |  TALKGROUP ID     | Type = 1 | CURRENT FREQ LCN  | CRC+Parity |
| 2 bit | LCN 2047  | 7 bit |    16 bit         |  4 bit   | IS FREE!          |  8 bit     |
|       |  11 bit   |       |                   |          |  11 bit           |            |

An unkey is a type 1 system message. The GOTO field changes to the special UNKEY command, LCN 2047 (decimal) or 7FF (hex), while the LCN of the current frequency is moved to the FREE LCN block, indicating that the channel has become available. The HSID and Talkgroup are included to instruct all other radios on that talkgroup to drop off the frequency.

I'll post more specific questions later, but I'm curious about some additional message types. There should be message types to STUN and KILL a radio, as well as one to request the Electronic Serial Number (ESN) from a radio to compare against its Mobile ID Number (MIN / Radio ID) - such as during registration. I'm curious if the initial Type 11 message during registration may be an ESN request sent by the system in an OSW in response to an ISW from the radio requesting to register (that isn't repeated as an OSW). I've also seen no evidence of any "DE-REGISTRATION" message type, though I fairly frequently see lots of ACK messages, sent seemingly at random over the remote and local home channels to various radio IDs. I'm curious if again, the ISW to de-register comes from the radio but is not repeated by the system, and instead the system simply acknowledges it. Finally... I keep changing my mind on whether I think a type 5 is a Page or not. Most recently I'm doubting it. My latest log has some type 5 messages that I listened to in real time. No reply from the radio ID it was sent to, just a long string of the same type 5 OSW repeated over and over for several seconds. Then I also noticed some shorter ones, this time with a brief Type 5 message to a radio ID (3 or so repeated OSWs) followed by a much longer string of ACKs to the same radio ID. At this point I have no idea what this means, but is probably not a page (no response or subsequent group call from any of the radio IDs), and if it was there doesn't appear to be any way to identify the party sending the page, just the Radio ID receiving it.

That's all for now... I'm sure I'll have more (and try to include some more examples). Any idea on the above?

Inigo

 

[slicerwizard]

Basic Structure of Passport OSW - 68 bits total, with the (0x158) sync bit omitted, ends up being 59 bits:

| DCC    | GOTO LCN  | ASID or HSID | TG ID / MIN ID | Call Status | FREE LCN  | CRC+Parity |
| 3 bits |  11 bits  |   7 bits     |     16 bits    |   4 bits    |  11 bits  |  8 bits    |

DCC is 2 bits.

Type 0 - Group Call:

| DCC   | GOTO LCN | HSID  | Talkgroup ID | Type = 0 | FREE LCN | CRC+Parity |
| 3 bit |  11 bit  | 7 bit |    16 bit    |  4 bit   |  11 bit  |  8 bit     |

Note that the site # is the HOME Site ID - the site # on which the call took place - not the current site number that it was received on.

The site number is the home site of the talkgroup and it is part of the full talkgroup ID. E.g. 34567 is not a talkgroup number, but 37-34567 could be.

There should be message types to STUN and KILL a radio,

Mesaage types 9 and 13 respectively.

as well as one to request the Electronic Serial Number (ESN) from a radio to compare against its Mobile ID Number (MIN / Radio ID) - such as during registration. I'm curious if the initial Type 11 message during registration may be an ESN request sent by the system in an OSW in response to an ISW from the radio requesting to register

As far as I can recall, it's all part of message 11.

I've also seen no evidence of any "DE-REGISTRATION" message type,

I don't think there s one.

I keep changing my mind on whether I think a type 5 is a Page or not. Most recently I'm doubting it. My latest log has some type 5 messages that I listened to in real time. No reply from the radio ID it was sent to, just a long string of the same type 5 OSW repeated over and over for several seconds. Then I also noticed some shorter ones, this time with a brief Type 5 message to a radio ID (3 or so repeated OSWs) followed by a much longer string of ACKs to the same radio ID. At this point I have no idea what this means, but is probably not a page (no response or subsequent group call from any of the radio IDs), and if it was there doesn't appear to be any way to identify the party sending the page, just the Radio ID receiving it.

Message 5 = mobile transpond; it is usually used by the site controller to confirm that a mobile is still monitoring a site and is typically sent after three hours of inactivity by a subscriber radio. It is equivalent to a SmartZone affiliation request.

 

[fwradio]

There is no band 16 - the bandplan fields only use four bits.

Oops. Brainfart.

 

[EricCottrell]

Message 5 = mobile transpond; it is usually used by the site controller to confirm that a mobile is still monitoring a site and is typically sent after three hours of inactivity by a subscriber radio. It is equivalent to a SmartZone affiliation request.

Hello,

I have also seen these messages as well so wondered if it was either paging or another unit trying to connect for a unit-to-unit call.

Any idea of what message types 2 and 4 are used for? Perhaps it is a priority indication or a source indication (console, inter-site, inter-network)?

I noticed that the even message types are for messages involved with active communication on the repeater (group call, radio id) while the odd message types are system commands and responses.

73 Eric

 

[inigo88]

DCC is 2 bits

Wow that's embarassing, I wrote that too late last night... of course it's 2 bits.

I also know that the talkgroup is preceeded by the HSID followed by a dash, I just didn't know what to call it officially... Group? The radio IDs follow the same format. I've edited my original post to fix the above.

Thank you for clearing up those message types, especially the Type 5! I've witnessed it performing exactly as you explained (though I've seen both Type 5 followed by Type 1 ACK, and just Type 5 with no answer).

I started suspecting that type 11 was the ESN request, because 50% of the time with registration I saw the following OSWs:

ACK -> Radio ID
ACK -> Talkgroup ID
(Type 11) ESN Request? -> Radio ID
ACK -> Radio ID
(Type 3) Home CH Assign -> Radio ID
ACK -> Radio ID

But the other 50% of the time, I simply saw this:

ACK -> Radio ID
ACK -> Talkgroup ID
(Type 3) Home CH Assign -> Radio ID
ACK -> Radio ID

I could very well be overcomplicating the system... but I was just curious about the existence of a DE-REGISTRATION message because it appears in the Key Terminology on Page 5 of this document. I was also curious because of the seemingly random ACKs to Radio IDs that go out over the home channel (by themselves - not in conjunction with type 5 or any other message type).

I too am curious about Types 2 and 4 (though I haven't seen them yet on this system on the west coast).

Finally, I witnessed a Unit-to-Unit call ONCE, but didn't have the program running in time to catch the format. Do you know the format and message type used by a Unit to Unit call?

 

[DaveNF2G]

Updating our tools?

I and other hobbyists who are working on deciphering local Passport systems as they pop up are using LTRDUMP and LTRTrunker. The latest version of LTRDUMP is from October, 2004. It seems to understand Passport, but if the original coders know more about the format now than they did 3 years ago, is there a possibility of having the software revised?

LTRTrunker never came out of beta, AFAIK. I'm using v3.84 beta ec4, which I believe is also vintage 2004. I am aware that Windows based programs are under development, but they lack the capabilities that the DOS programs already had. I'd like to see functioning tools kept up to date, too.

 

[kd5dga]

I know that LTR trunker needs a special low pass filter arrangement to work properly but is there a way to make a filter that will go inline with the discriminator out that can be easliy plugged into a standard 2 level slicer?

 

[slicerwizard]

Any idea of what message types 2 and 4 are used for? Perhaps it is a priority indication or a source indication (console, inter-site, inter-network)?

No, not yet. I haven't seen those OSW's around here.

I noticed that the even message types are for messages involved with active communication on the repeater (group call, radio id) while the odd message types are system commands and responses.

Yep, they seem to have some organization to them.

 

[slicerwizard]

I also know that the talkgroup is preceeded by the HSID followed by a dash, I just didn't know what to call it officially... Group? The radio IDs follow the same format. I've edited my original post to fix the above.

You had written: "Note that the site # is the HOME Site ID - the site # on which the call took place - not the current site number that it was received on."

Nothing in the OSW indicates which site originated the call.

Thank you for clearing up those message types, especially the Type 5! I've witnessed it performing exactly as you explained (though I've seen both Type 5 followed by Type 1 ACK,

The subscriber radio was still monitoring the system.

and just Type 5 with no answer).

The subscriber radio was not monitoring the system.

I started suspecting that type 11 was the ESN request, because 50% of the time with registration I saw the following OSWs:

ACK -> Radio ID
ACK -> Talkgroup ID
(Type 11) ESN Request? -> Radio ID
ACK -> Radio ID
(Type 3) Home CH Assign -> Radio ID
ACK -> Radio ID

But the other 50% of the time, I simply saw this:

ACK -> Radio ID
ACK -> Talkgroup ID
(Type 3) Home CH Assign -> Radio ID
ACK -> Radio ID

The radio ID may not have been flagged for ESN checking.

I could very well be overcomplicating the system... but I was just curious about the existence of a DE-REGISTRATION message because it appears in the Key Terminology on Page 5 of this document. I was also curious because of the seemingly random ACKs to Radio IDs that go out over the home channel (by themselves - not in conjunction with type 5 or any other message type).

Many radios don't deregister as they don't have soft power buttons. Any that do would do so by sending an appropriate ISW. All you'd see would be an ACK OSW, so there would be no deregistration OSW for you to track down.

Finally, I witnessed a Unit-to-Unit call ONCE, but didn't have the program running in time to catch the format. Do you know the format and message type used by a Unit to Unit call?

I've never seen one in these parts. We were counting on you...

 

[inigo88]

I've never seen one in these parts. We were counting on you...

D'oh!!! Luckily I do know they're possible on this system (albeit extremely rarely) - you just gave me the extra motivation to try and nab one. I'll try not to disappoint.

Inigo

 

[kd5dga]

I just found out that the radio makes the difference.
I was using a PRO92 to provide me with my output and I was getting alot of erroronious talk groups and the program did not run as smooth as I would expect. This morning I spent the time to look up the information and started to explore my PRO433. Now I have a discriminator output from the PRO 433. Now LTR analyser runs smoothly since I have a modern scanner providing the data, and I think that the data is correct by compairing the scanners display to the program.

 

[inigo88]

KD6DGA, as much as I'm enjoying LTRAnalyzer also, this is the wrong thread to discuss it in. This thread is about Passport, which LTRAnalyzer can't decode (yet - I look forward to when it can though!). See this post earlier on the page for the correct place to go:

http://www.radioreference.com/forums/showpost.php?p=695916&postcount=64

As for the I-Call hunt guys, I heard another one a couple days ago in the middle of the night, scrambled to get the computer on and set up in time and then they hung up within seconds of decoding the call... this is getting ridiculous!!! But I should have a result for you soon.

It's worth mentioning that the frequency only carried half the conversation (only one user not both), and the radio seemed to be hot miked because there was dead air between his side of the conversation. I tried to find the other guy on another frequency but couldn't in time. Damn... lol.

Inigo