Can Unitrunker be smarter about channel numbers in P25 imports from RR?

[AM909]

As I understand it, P25 sites each have a "band plan," which is used to set the relationship between channel number and frequency. If you listen to a new site OTA with Unitrunker, you'll quickly get the logical channel numbers (LCNs) for the control and voice channels for the site you are listening to, as well as its band plan, which will be used to convert the LCNs to frequencies. You may also get the LCNs of other sites on that system, but without their band plans, and therefore, without their frequencies,

If you then use the "download this system" (boat's wheel icon) to hopefully import the talk group and other sites for the system from RR, the following happens:

1. For the site you are listening to, additional entries are created in the channels tab for all the channels from RR, with sequential LCNs starting at 00-0001. Not only are these entries invalid because they have the wrong LCN for their frequencies, but they duplicate the entries with the correct channel numbers. Because there is already a band plan present for this site, the import should be smart and do nothing with entries for frequencies that match RR. It should add entries for any RR frequencies that are not yet in the channel list, and use the band plan to correctly calculate their LCNs.

2. It does the same thing for the additional sites on the system, creating all the channels with LCNs starting at 00-0001. Ideally, RR should have the band plan information -- it does in some cases, in a non-standard format. Most of the time, the other sites in a system share the same band plans, so I would like it if, when downloading these additional sites, if it sees just a single channel entry with an LCN but frequency = 0, and the prefix of the LCN matches the prefix of the LCN of the control channel of a site on the system that DOES have a band plan, copy the band plan from that site and use it to generate the correct frequencies for the existing control channel entry that had frequency = 0, as well as adding entries with correct LCNs for the additional channels from the RR db.

If it really can't determine the LCN for a channel, it should probably be set to some invalid value (??-????), instead of something that looks like it could be a real LCN.

Also, it would be nice to be able to select which types of data to import (perhaps with checkboxes in the login dialog that already pops up). With this current LCN issue, for example, I'd like to be able to just import talk groups. Control over which site (or all) to import would be good, too.

Thanks for any help or suggestions!

 

[SCPD]

Hello AM909;

What version are you running? What system did you download?

 

[AM909]

Hello AM909;

What version are you running? What system did you download?

Sorry.

v1.0.33.4.

System 91FE5-105 (RR sid 7955).

And thanks for an overall great piece of work!

 

[Jay911]

I've seen this before, Rick, if I understand AM's concern. UT downloads frequencies and seems to arbitrarily assign LCN 00-0001, 0002, 0003, 0004, etc., per each frequency downloaded. It doesn't seem to consider the band plan either as provided by the CC or stored in the site info in UT. I'm using 33.4 as well, and have seen this on 660C5-05B AFRRCS.

 

[teknishun]

So, that is why I see, when monitoring call history, the same frequencies with
2 or 3 different LCNs. The longer you monitor, the top half of the screen keeps
expanding with duplicate frequencies.

teknishun

 

[Jay911]

So, that is why I see, when monitoring call history, the same frequencies with
2 or 3 different LCNs. The longer you monitor, the top half of the screen keeps
expanding with duplicate frequencies.

teknishun

No, not at all... this situation revolves around downloading from the RRDB.

You might see one frequency with two different LCNs if you are monitoring a Phase 2 system. If you're seeing more than that, and "constantly" getting more channels/freqs showing up the longer you monitor, that sounds like a weak or dirty signal corrupting the inbound data. I have seen that problem on my own in two situations: One, where a signal is so weak that data might be corrupted (though the internal checksum of the signal should counteract this); or Two, the frequency being monitored has more than one signal within range. That last situation is something I've had experience with, with two sites on the fringe of my reception range both audible on the frequency. That provides a lot of cross-contamination of the data as you get some of the info from one site mixed with some of the info from another site.

 

[teknishun]

No, not at all... this situation revolves around downloading from the RRDB.

You might see one frequency with two different LCNs if you are monitoring a Phase 2 system. If you're seeing more than that, and "constantly" getting more channels/freqs showing up the longer you monitor, that sounds like a weak or dirty signal corrupting the inbound data. I have seen that problem on my own in two situations: One, where a signal is so weak that data might be corrupted (though the internal checksum of the signal should counteract this); or Two, the frequency being monitored has more than one signal within range. That last situation is something I've had experience with, with two sites on the fringe of my reception range both audible on the frequency. That provides a lot of cross-contamination of the data as you get some of the info from one site mixed with some of the info from another site.

OK. Thanks for the explanation. I have both those problems. A weak signal, fluctuating
from good to fair AND it is a simulcast system as well. Scanners monitoring P25 usually
do not do well with simulcast systems because of the multiple signals.

teknishun

 

[SCPD]

You might see one frequency with two different LCNs if you are monitoring a Phase 2 system.

Good point Jay.

If the frequency in question also serves as a control channel - or this is a mixed P1 / P2 system - you will see three rows for the same frequency. One for the FDMA channel, and one of each of the two TDMA slots.

I'm working on a new feature to combine the row for the first TDMA slot with the FDMA row.

 

[SCPD]

AM909 - thanks for reporting this. I'll add it to the bug sheet.

This is only a problem for P25 systems that are below 512 Mhz or non-Motorola systems in the 851 and incredibly rare 935 Mhz bands.