LTR Passport Decoder Project

[KC5MAI]

We are one of the system operators in doubt. We are in the process of upgrading (flashing) over 4,000 radio's on our Passport, LTR, Conventional system so that the changes over the last 5 or more years can be taken advantage of. All radio's are now working, but we want them to work better with more options. This is a "Kick-Ass" protocol with many options and enhancements and it is backwards compatible and no more cloning of radios on our system, which was one of the main advanages along with networking dispatch.

 

[EricCottrell]

We are one of the system operators in doubt. We are in the process of upgrading (flashing) over 4,000 radio's on our Passport, LTR, Conventional system so that the changes over the last 5 or more years can be taken advantage of. All radio's are now working, but we want them to work better with more options. This is a "Kick-Ass" protocol with many options and enhancements and it is backwards compatible and no more cloning of radios on our system, which was one of the main advanages along with networking dispatch.

Hello,

I assume when the repeater sites and controllers got upgraded the radios still worked but could not use the new features until flashed.

I am looking at it from the radio over-the-air protocol end. The basic elements are set and can not be changed without breaking compatibility with existing radios. In this case the radio system is down until most radios are updated.

It is a very thought out protocol. The only problem I see is when a system is misconfigured. During the DNC the Fleet Center site had one frequency saying it was site 10 and the other frequencies saying it was site 100.

It is neat to find a new system when I travel and map out the system using the same information as a Passport radio. It sure beats having to figure out what repeater numbers and frequencies belong to the same Regular LTR system.

73 Eric

 

[KC5MAI]

Right, If the system is misconfigured then all bets are off. That is why you have competent techs or call for support alot. Hi Hi

Mike

 

[inigo88]

Hi guys,

I'm a college student without any background in electrical engineering, but because I found myself coming across a large amount of Passport frequencies here in the SF Bay area, I decided to take on the challenge of building a filtered data slicer based on Eric Cottrell's circuit - and thanks in large part to members of this forum I was successful. Using Eric's software LTRDump, I've slowly gathered and submitted a lot of information on northern California sites of the Fisher Wireless Teamtalk UHF Passport System, which spans the states of California, Nevada and Arizona and has several public safety users (AMR Ambulance in San Joaquin county CA and Lifenet EMS helicopters in Tucson AZ) amidst mostly commercial subscribers.

LTRDump is an awesome program, but because it was a proof of concept on Passport decoding it includes most of the common system messages but is by no means complete, because Passport itself hasn't been entirely figured out yet (at least by enthusiasts that want to listen in). For this reason I found this thread and tried to teach myself how to obtain the binary data from Passport's subaudible data in the LTRdump log file. I was eventually able to figure out how to take the raw hexadecimal data and convert it to binary using the windows calculator, add spaces to the 68 bit frame categorically where appropriate, and then use the windows calculator again to convert each binary number group to decimal - but this is obviously a complicated process (and my method is also probably highly inefficient) that is not very intuitive to someone just starting out. From there I just started attempting to decode different types of messages in various contexts, comparing them with the decoded text displayed in the LTRDump log file. To retain my sanity, I started a running text file where I broke down each manual decode I tried and attempted to rationalize what was actually going on, so I could refer back to what I learned later.

I've resurrected this three year old thread because Passport is still alive and well, but I haven't been able to find anything to indicate that there is any further understanding of the protocol then what has already been posted here, and LTRDump/Trunk remains the only option I can find to decode it. While it may seem redundant compared with the rest of the content in this thread, I wanted to post the txt file I made here as a sort of basic tutorial to help others like myself that are interested in getting into decoding the protocol but can't get over the initial hurdles.

I still have some basic questions I was hoping to get answered myself -

1.) I'm still not sure I completely understand which bits are responsible for a site's Network #, and I really don't understand which determine the band plan.

2.) While I understand a really basic idea of what the checksum does, and despite a lot of google searching on the subject, I still don't understand exactly how the parity bit or the checksum actually works (how one would use the table of checksum values Eric posted to check for errors) or how these relate to XOR math.

If anyone could clear these up for me I'd greatly appreciate it!

And finally, I hope that by attaching the following I can make some modest contribution to the Passport decoder project, and help others in my position get started.

Thanks everyone!

 

[inigo88]

Deleted

 

[slicerwizard]

1.) I'm still not sure I completely understand which bits are responsible for a site's Network #, and I really don't understand which determine the band plan.

The bandplan is encoded in the fourth OSW field (in the 5th through 8th bits)

OSW: 0 701 0F 1A1D 1 391 B1    N: 15->10/913 (420.4125) Puslinch
        ^   ^  ^      ^
        |   |  |      |
        |   |  |     neighbour site channel index = 0x391 (decimal 913)
        |   |  |
        |   | neighbour site bandplan = 0xA (decimal 10)
        |   |
        |  current site = 0x0F (decimal 15)
        |
       701 = true idle OSW



OSW: 0 700 0F 1515 1 333 7E    N: 15-> 5/819 (460.2375) Hamilton
        ^   ^  ^      ^
        |   |  |      |
        |   |  |     neighbour site channel index = 0x333 (decimal 819)
        |   |  |
        |   | neighbour site bandplan = 5
        |   |
        |  current site = 0x0F (decimal 15)
        |
       700 = forced idle OSW

2.) While I understand a really basic idea of what the checksum does, and despite a lot of google searching on the subject, I still don't understand exactly how the parity bit or the checksum actually works (how one would use the table of checksum values Eric posted to check for errors) or how these relate to XOR math.

Before sending a PassPort OSW, the PassPort controller sets its internal CRC value to zero.

For every '1' bit in the payload (the bits after the frame marker and before the CRC), the controller XORs its internal CRC value with the appropriate value from that lookup table.

After sending all of the payload bits, the controller sends the final value of its internal CRC value.


Therefore, if all of the payload bits were zero, the transmitted CRC would also be zero (since there were no '1' bits, the CRC would never change from its initial value)


If only the first payload bit (the high bit of the DCC) had a '1' value, the CRC value would be XORed with the first table entry only (so it would end up with that value, since 0 XOR n = n)


When you decode an OSW, you just start with a CRC value of zero and do the same sequence of XORs; your calculated CRC should match the CRC sent by the controller.

 

[inigo88]

Wow so I was skipping a step entirely by not converting back to Hex at the end?

For example:

Raw hex log...

7C05B8A8A8C5E66

Becomes Binary split into appropriate catagories...

11 11100000001 0110111 0001010100010101 0001 10001011110 01100110

Which looks like this in decimal...

3 1793 55 5397 1 1118 102

Then each catagory becomes its own Hex number again (my DCC is 3 instead of 0)

3 701 37 1515 1 45E 66
    ^  ^  ^   ^ ^
    |   | |   | |
    |   | |   | Neighbor registering LCN - 0x45E = dec 1118 = 463.975 MHz
    |   | |   Msg Type 1 - System Message
    |   | 5 = 450 MHz Bandplan!
    |   0x37 = Site # 55
    |
   701 = "True Idle OSW" (channel is Idle, not in use - neighbor frame)

That message becomes in LTRDump format:

Passport DCC:3 450MHz N:1 S:55 I Nbr -> 450MHz N:1 463.975

Looking at that 4 digit number the current bandplan was in, I'm starting to see a larger pattern and see where Eric got the bandplan and Network information...

Dec: Hex:

5397 = 1515
5381 = 1505
5525 = 1595

He said the first two digits were the Neighbor information, while the second two were for the current site, so I believe it breaks down like so:

15 15
^^ ^^
|| ||
|| |Current Site Bandplan = 5 (450Mhz)
|| Current Site Network = 1
|Neighbor Bandplan = 5 (450Mhz)
Neighbor Network = 1

I got 1595 (dec 5525) in this same field on a true idle OSW on the Registering Channel. If 15 belongs to the neighbor site, and 95 belongs to the current site, the extra 1 instead of 0 in binary could be explained in Hex by adding 8 to the network field for the current site. For instance:

5397: 00010101 00010101 <- Regular
5525: 00010101 10010101 <- Registering
               ^
               |
               Extra 1 for registering

Same as 1515 and 1595. 1595 -> 9-8 = 1 --> 1515.

This would also explain this interesting idle OSW, since this was the first time I had ever seen a Network # other than 1.

Passport DCC:3 450MHz N:0 S:60 I Nbr -> 450 MHz N:1 453.01250

3 701 3C 1505 1 F1 1A

1505 instead of 1515.

With 15 being Neighbor Network/Band followed by 05 being Current Site Network/Band.

However, for this idea to hold up I have another question for you slicerwizard...

The bandplan is encoded in the fourth OSW field (in the 5th through 8th bits)

OSW: 0 701 0F 1A1D 1 391 B1    N: 15->10/913 (420.4125) Puslinch
        ^   ^  ^      ^
        |   |  |      |
        |   |  |     neighbour site channel index = 0x391 (decimal 913)
        |   |  |
        |   | neighbour site bandplan = 0xA (decimal 10)
        |   |
        |  current site = 0x0F (decimal 15)
        |
       701 = true idle OSW

In this example your neighbor freq would be on Network: 1 and in bandplan 10 (Hex A), which is 420 MHz like you say. However, if I'm correct with the above, the current frequency you logged that on would have also been Network:1, but been on a bandplan 13 (Hex D). What was the frequency that was logged on? And does this kill my whole theory?

 

[inigo88]

I wanted to try and prove to myself the above method for determining the checksum value was true, so I painstakingly manually tried it on the calculator using Eric's bit table (difficult because I don't really understand XOR well enough yet). I accidentally used the ^ symbol for XOR in the calculation, which I believe is actually the AND symbol, but otherwise IT WORKED OUT!

3 701 37 1515 1 45E 66

11 11100000001 0110111 0001010100010101 0001 10001011110 CRC=(01100110)

Target CRC= 66 (Binary 01100110)

0^6E=6E^BF=D1 ^D6=7^E3=E4^F8=1C^94=88^AD=25^57=72^D9=AB^6D=C6^37=F1 ^31=C0^0D=CD^8A=47^D5=92^BC=2E^A7=89 ^B0=39 ^58=61^C8=A9^32=9B^91=A^49=43^25=66

IT WORKED!

 

[inigo88]

Slicerwizard, per one of Eric's earlier posts on page 2:

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.

Was that first OSW example on a 216MHz - 220 MHz frequency?

 

[slicerwizard]

Wow so I was skipping a step entirely by not converting back to Hex at the end?

Well, it's handy when looking at the 16 bit ID field in idle OSWs...

Looking at that 4 digit number the current bandplan was in, I'm starting to see a larger pattern and see where Eric got the bandplan and Network information...

Dec: Hex:

5397 = 1515
5381 = 1505
5525 = 1595

He said the first two digits were the Neighbor information, while the second two were for the current site, so I believe it breaks down like so:

15 15
^^ ^^
|| ||
|| |Current Site Bandplan = 5 (450Mhz)
|| Current Site Network = 1
|Neighbor Bandplan = 5 (450Mhz)
Neighbor Network = 1

I'm not familiar with any "Neighbour Network" bits; the fourth bit in the 16 bit field is the neighbour site's modulation mode (0=FM, 1=NFM) and the 12th bit is the current site's modulation mode (again, 0=FM, 1=NFM)

I got 1595 (dec 5525) in this same field on a true idle OSW on the Registering Channel. If 15 belongs to the neighbor site, and 95 belongs to the current site, the extra 1 instead of 0 in binary could be explained in Hex by adding 8 to the network field for the current site. For instance:

5397: 00010101 00010101 <- Regular
5525: 00010101 10010101 <- Registering
               ^
               |
               Extra 1 for registering

Same as 1515 and 1595. 1595 -> 9-8 = 1 --> 1515.

This would also explain this interesting idle OSW, since this was the first time I had ever seen a Network # other than 1.

Passport DCC:3 450MHz N:0 S:60 I Nbr -> 450 MHz N:1 453.01250

3 701 3C 1505 1 F1 1A

1505 instead of 1515.

With 15 being Neighbor Network/Band followed by 05 being Current Site Network/Band.

Are you seeing these values consistently? Or could they be bad decodes?

In this example your neighbor freq would be on Network: 1 and in bandplan 10 (Hex A), which is 420 MHz like you say. However, if I'm correct with the above, the current frequency you logged that on would have also been Network:1, but been on a bandplan 13 (Hex D). What was the frequency that was logged on? And does this kill my whole theory?

I should not have included that OSW; it was logged early in my PassPort investigations before I had any CRC checks in place (you have to log some data before you can reverse engineer the CRC table) and the OSW is invalid. If you hand-check the CRC, you'll see that.

 

[slicerwizard]

I accidentally used the ^ symbol for XOR in the calculation, which I believe is actually the AND symbol

'^' is the xor operator in C, so no worries.

IT WORKED!

Amazing!

 

[slicerwizard]

Was that first OSW example on a 216MHz - 220 MHz frequency?

As I said, just a bad decode.

OSW: 0 701 0F 1A1D 1 391 B1 N: 15->10/913 (420.4125) Puslinch

should be

OSW: 0 701 0F 1A15 1 391 B1 N: 15->10/913 (420.4125) Puslinch

 

[inigo88]

Hey Slicerwizard,

I'm still in the stage of trying to identify and rationalize how Eric decoded the data for use in his LTRDumper program 2+ years ago. In the LTRDump log and on the main screen, true and forced idle OSWs to use your terminology (what he was calling "neighbor frames" earlier in the thread) were displayed in the following format (with the raw hex omitted on screen):

7c05b8a8a8c5e66 Passport DCC:3 450MHz N:1 S:55 I Nbr -> 450 MHz N:1 463.97500

There's the raw hex data, followed by the fact that it's a Passport OSW, followed by the DCC, then the bandplan of the current site, the network number of the current site, the current site number, I for idle (there are also B for busy (forced idle OSW) and they can be preceded by R for traffic on a Registering channel), Nbr for Neighbor, and then the bandplan, network number and frequency (converted from LCN based on bandplan) of the registering channel of a neighboring site.

The above example decodes to:

3 1793 55 5397 1 1118 102 (decimal) and

3 701 37 1515 1 45E 66 (hex)

Compare that with this other log I got, which says the current site's network number is 0 instead of 1 like the rest I've come across so far:

7c05e0a8288f11a Passport DCC:3 450MHz N:0 S:60 I Nbr -> 450 MHz N:1 453.01250

This decodes to:

3 1793 60 5381 1 241 26 (decimal) and

3 701 3C 1505 1 F1 1A

The difference is 1515 vs. 1505. With the first two bits (although this may be confusing, because does binary read from right to left?) being for the neighbor site and the second two being for the current site. You can see in the first example the current site is N:1 and 450 MHz bandplan and the bits are 15 "15", while in the second example it is N:0 and 450 MHz bandplan and the bits are 15 "05".

However, my very premise for the whole network assertion to begin with may be flawed, because it's based on checking my manual decodes against those produced by Eric's software - so if he's wrong about them then I would be as well.

I was able to find the earlier post where this is referenced which isn't totally concrete:

10-24-2004, 07:08 PM - EricCottrell wrote:

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.

I didn't keep a record of which frequency that second decode I made was on, but I could try and find the frequency again for a similar example and see if that could lend any support to it being an FM vs NFM modulated freq (unless it was accidentally set that way at the repeater - since that was the first decode I had seen with that bit set to 0).

Since there appear to be differing ideas for their function, I think it really comes down to the question; How sure are you that those bits are used for current and neighbor site modulation?

The beauty of science is that it's based on falsifiability (i.e. the ability to be proven wrong), and this topic is at least related to science...

 

[wm8s]

I didn't see these posted anywhere; they shed a little light for the beginner...

http://www.p25.com/resources/manuals/2975passport.pdf

http://www.aeroflex.com/products/commtest/pmr/appnotes/passport.pdf

...R

 

[inigo88]

Thank you so much, they're definitely a much-needed crash course in Passport terminology. I was thinking the ASID would correspond to the Network #, but looking at the IFR 2975 setup screen it looks like just the Site ID, so I think this whole premise of an extra network number is incorrect, and those bits are indeed for current and neighbor ASID modulation.

 

[EricCottrell]

Hello,

Here are some decoding notes. My code is in C++ so I think in bits. My code splits up the frame into multiple variables to make it easier to decode.

XOR is neat. When you calculate the parity and check bits and XOR with the value in the frame then a zero value indicates a good result. The XOR values I use also have the parity included so I just XOR the whole 8 bit value.

Frame
2 bits DCC
11 bits Channel (LCN)
7 bits  SiteID
16 bits Group
4 bits  Type
11 bits Free
8 bits  Parity and 7 Checkbits

xor values to use if bit is set to one.
0x6e,   // DCC 1
0xbf,   // DCC 0
0xd6,   // Channel 10
0xe3,   // Channel  9
0xf8,   // Channel  8
0x7c,   // Channel  7
0x3e,   // Channel  6
0x97,   // Channel  5
0xc2,   // Channel  4
0xe9,   // Channel  3
0x75,   // Channel  2
0x3b,   // Channel  1
0x94,   // Channel  0
0x4a,   // Site ID  6 
0xad,   // Site ID  5 
0x57,   // Site ID  4 
0xa2,   // Site ID  3 
0xd9,   // Site ID  2 
0x6d,   // Site ID  1 
0x37,   // Site ID  0 
0x92,   // Group 15
0xc1,   // Group 14
0x61,   // Group 13
0x31,   // Group 12
0x19,   // Group 11
0x0d,   // Group 10
0x07,   // Group  9
0x8a,   // Group  8
0xcd,   // Group  7
0x67,   // Group  6
0xba,   // Group  5
0xd5,   // Group  4
0x6b,   // Group  3
0xbc,   // Group  2
0x5e,   // Group  1
0xa7,   // Group  0
0xda,   // Type  3
0xe5,   // Type  2 
0x73,   // Type  1 
0xb0,   // Type  0
0x58,   // Free 10
0x2c,   // Free  9
0x16,   // Free  8
0x83,   // Free  7
0xc8,   // Free  6
0x64,   // Free  5
0x32,   // Free  4
0x91,   // Free  3
0x49,   // Free  2
0x25,   // Free  1
0x13,   // Free  0

Decoding Notes

Groups and Radio IDs share the same code space.  Groups start from 65535 and work down.
Radio IDs start from 0 and work up.  Group 65535 is used for CW ID.

If Channel > 0 and Channel < 1792 then it represents a frequency otherwise command or special
	If Free equals 2042 then no free channel is available (Usually seen on busy registration channel)
	Else If Free equals 0 then all channels are busy
	Else decode Free the same as Channel to find the free channel
	If Type equals 0  (Group Call)
	Or Type equals 2  (Console Call? or maybe priority Level)
	Or Type equals 4
	Or Type equals 9  (Data?)
		then Active Call
	If Type equals 1 then Acknowledge
	If Type equals 3 then Home Channel Assignment (Seen on Registration Channels)
		Channel is the new home channel
	If Type equals 5 then Page?
	If Type equals 6 then Radio ID
		Site ID and Group represent the Radio ID of the unit transmitting
	If Type equals 11 then Register

Special Commands
If Channel equals 1792 and Type equals 1 then Neighbor information and Channel is Busy
If Channel equals 1793 and Type equals 1 then Neighbor information and Channel is Idle  (Idle Bust)
If Channel equals 2047 and Type equals 1 then Unkey Indication
	Free is the formerly active channel with Site ID and Group indicating the formerly active Site and Group.

Neighbor Information
	Group is split into 2 8 bit words.  Neighbor Info in upper 8 bits and Site Info in lower 8 bits.
		Site Info is used to decode the Channel and Free of other messages into real frequencies.
		Neighbor Info is used to decode the Free of this message into real frequencies.
		The most significant bit (Bit 7) of Site Info indicates Registration Frequency.
		The most significant bit (Bit 7) of Neighbor Info is unknown.
		Bits 6 to 4 (3 bits) are the network number (8 networks)
                Bits 3 to 0 (4 bits) are unknown. 
	Free is the Neighbor Site Registration Channel and uses Neighbor Info

73 Eric

 

[slicerwizard]

(although this may be confusing, because does binary read from right to left?)

Everyone has been using normal representations (high order values on the left, low to the right) in this thread, so 5381 decimal = 1505 hex, same as the Windows calculator, etc.

Since there appear to be differing ideas for their function, I think it really comes down to the question; How sure are you that those bits are used for current and neighbor site modulation?

Quite sure. When a PassPort channel is programmed, the mode (FM or NFM) for the channel and all of the neighbour list entries must be defined. This is because the information is contained in the idle OSW's. A PassPort site has no interest in the modes or bandplans used by neighbour sites; it only knows so that it can broadcast that information for the benefit of the subscriber radios. The radios will automatically adjust their TX/RX modes to match each site's mode.

 

[fwradio]

Seems there might be some unanswered questions as to which frequency range each channel plan indicates. Hope this helps:

0 - 800 MHz
1 - 900 Mhz
2 - 400-420 Mhz
3 - 420-440 Mhz
4 - 440-460 MHz
5 - 450-470 MHz
6 - 460-480 MHz
7 - 470-490 MHz
8 - 480-500 MHz
9 - 490-512 MHz
10 - 409-430 MHz
11 - 400-420 MHz NTIA (same DFA table as band 2, but uses 9 MHz split instead of 5 Mhz)
12 - not defined
13 - 200 MHz
14 - not defined
15 - 700 MHz
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.

 

[EricCottrell]

Seems there might be some unanswered questions as to which frequency range each channel plan indicates. Hope this helps:

0 - 800 MHz
1 - 900 Mhz
2 - 400-420 Mhz
3 - 420-440 Mhz
4 - 440-460 MHz
5 - 450-470 MHz
6 - 460-480 MHz
7 - 470-490 MHz
8 - 480-500 MHz
9 - 490-512 MHz
10 - 409-430 MHz
11 - 400-420 MHz NTIA (same DFA table as band 2, but uses 9 MHz split instead of 5 Mhz)
12 - not defined
13 - 200 MHz
14 - not defined
15 - 700 MHz
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.

Hello,

From the information I have a VHF system uses a different method to specify the DFA. Likely they use some additional messages to define a frequency map. The only VHF Passport system I am aware of is in Colorado. I would like to get some log files from the system so I can figure out the VHF protocol.

Here is the frequency table I use.

struct
{
    double base;
    double step;
    int    offset1;
    double base1;
    double step1;
    char *str;
} ppBandInfo[16] =
{
{851.0,0.0125,2048,0.0,0.0,"800MHz"},
{935.0,0.0125,2048,0.0,0.0,"900MHz"},
{  0.0,0.0125,2048,0.0,0.0,"B:02"},
{  0.0,0.0125,2048,0.0,0.0,"B:03"},
{  0.0,0.0125,2048,0.0,0.0,"B:04"},
{450.0,0.0125,2048,0.0,0.0,"450MHz"},
{460.0,0.0125,2048,0.0,0.0,"460MHz"},
{470.0,0.0125,2048,0.0,0.0,"470MHz"},
{480.0,0.0125,2048,0.0,0.0,"480MHz"},
{490.0,0.0125,2048,0.0,0.0,"490MHz"},
{  0.0,0.0125,2048,0.0,0.0,"B:10"},
{400.0,0.0125,2048,0.0,0.0,"400MHz"},
{  0.0,0.0125,2048,0.0,0.0,"B:12"},
{216.0,0.00625,320,220.0,0.00625,"216MHz"},
{  0.0,0.0125,2048,0.0,0.0,"B:14"},
{  0.0,0.0125,2048,0.0,0.0,"B:15"}
};

The 800 and 900 tables are guesses. The 216 MHz table is actually split to cover both 216 and 217 and 220 MHz with a 6.25 KHz step. The 218 - 220 Mhz range is mobile transmit plus a region not allocated to this service so it is skipped. I confirmed the 216 MHz map on several system on 217 and 220 MHz. Band 10 (409 MHz) is used up in Canada and likely has the Canadian offset (5.05 MHz?). I noticed I was lazy and have not updated the source code with the information but assume it is 409 MHz base with a 12.5 KHz step.

73 Eric

 

[kd5dga]

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.