TRX-1: Hearing more talkgroups on a large system

[ebplayer]

I just got a TRX-1 and have been playing around with it. One of the first things I noticed after loading up my local trunked systems is that it seemed deaf to showing talkgroup action on a system with many talkgroups. I'm talking about the EBRCS system in the SF Bay Area which has about 480 talkgroup IDs.

I noticed that by making a scanlist with only particular talkgroups I wanted to monitor (150 out of 480) had the effect of hearing more traffic and talkgroups showing up with action that weren't showing up when trying to scan all 480 talkgroups.

Is this a bug? The scanner is scanning the same frequencies regardless, but there is something about the TRX-1 that seems to make it produce more action on talkgroups if the overall list of talkgroups is reduced via a scanlist. Anyone else observing this?

Thanks.

 

[k1xd]

I have a TRX-2 and I'm new to this model. I notice a similar issue with State of Maine P25 system with lots of talk groups. I have a PSR600 running side by side with the TRX-2, same antenna with a splitter. With a few talk groups programmed into the TRX-2, I receive all traffic. When I put in the compete list into the TRX-2 (over 100 talk groups) transmissions are missed as compared to the PSR600. I have two very strong control channels in my area and they are programmed into both scanners as the only cc's to use. I've set the data decode threshold on 50/80 so it shouldn't ignore either cc (both are 99 on the PSR600). The dwell is set on the default value of 0.8 seconds.

Not sure what the problem is. I'm still investigating. Could be a bug, could be corrupt data in the RR download, or it could be me?

 

[byndhlptom]

Large scan list

When you are scanning a trunked system.....

Every time the scanner decodes a talk group, it has to look at the enabled talk group list and compare to the decoded. If your list is long, it will take a finite time per compare to check the list.

As an example, lets say it takes 2 milliseconds to do a compare, 1 millisecond to check the list, and 5 milliseconds to decode a group number.

5 ms to decode
1 ms to fetch number from list
2 ms to compare, repeat x100 (groups in list=100), = 300 ms to check list.
Any matches, stop, goto voice channel, open squelch

in the mean time the system has assigned other groups to freg (you missed these while doing the compares).

Smaller list of groups, quicker back to the control channel to listen for other calls.


$.02

 

[kma371]

I just got a TRX-1 and have been playing around with it. One of the first things I noticed after loading up my local trunked systems is that it seemed deaf to showing talkgroup action on a system with many talkgroups. I'm talking about the EBRCS system in the SF Bay Area which has about 480 talkgroup IDs.

I noticed that by making a scanlist with only particular talkgroups I wanted to monitor (150 out of 480) had the effect of hearing more traffic and talkgroups showing up with action that weren't showing up when trying to scan all 480 talkgroups.

Is this a bug? The scanner is scanning the same frequencies regardless, but there is something about the TRX-1 that seems to make it produce more action on talkgroups if the overall list of talkgroups is reduced via a scanlist. Anyone else observing this?

Thanks.

That system is setup regionally. You can't hear all talk groups in all areas. For example if youre in Hayward, you won't be able to hear talkgroups in Concord. That's partially the reason why you don't hear as many talk groups as you would think.

If you are in the ALCO SW zone, you will only hear talkgroups in that zone and it's neighbor zone.

 

[k1xd]

to byndhlptom:


That's a possible explanation, but I would think 100 talk groups to compare, isn't many. Lot's of unknowns, but I wouldn't think we would be talking 2 milliseconds for each compare, but more like 2 milliseconds for the whole set of 100 talk groups and I would assume the buffer of data coming in continues to fill while talk group compares are happening, hence nothing would be missed unless we go to a voice channel.

Not that a bad programmer couldn't take 2 ms per compare, but 20 microseconds to fetch and compare two 16bit values seems reasonable even with a slow processor. (20us x 100 compares = 2 milliseconds)

to KMA371:

I'm missing traffic on talkgroups in my area, when more talkgroups are added to the list, regardless of whether the added talkgroups have traffic or not...

 

[byndhlptom]

Large group lists

Kx1d

I was just using 1-5 ms as an example. actual time will be different.

I agree it shouldn't take too long, but it does take some time. Since the uP in the scanner is only single tasking (I'm assuming), while it's comparing, it's not listening to the CC. What ever the time, a larger list takes time away from data decoding.....

Time to do things depends on uP, instruction set, clock frequency, code efficiency, etc.

Only the manufacturer knows.....

My experience is the smaller the group being scanned, the less I miss, thus the shelves full of scanners :<)

Also, while it's listening to a talk group (actually decoding voice traffic), it can't be listening to the CC.....

$.02

 

[k1xd]

to byndhlptom

Maybe...

But I would guess the data stream is buffered while compares and housekeeping task are performed. Almost certainly the I/O is handled by a DSP chip that would include QPSK decoding, buffering, vocoder for P25, etc... DSP chips have generous buffers!

The various vocoders that are licensed by the manufacturer are provided to run on DSP platforms.

Once the receiver goes to a voice channel though, all cc data stops as the system has only one receiver.

Dave
k1xd

 

[Ubbe]

It's a seperate DSP chip running it's own code independent of what the main CPU is doing. It's sending an interupt request to the CPU with it's result of the decoding process.

The CPU is running at least at 10MHz, 10 million clock cycles per second. Taking a TGs double word value from the DSP and compare to a table of TGs are very simple and do not require many clock cycles. You could probably compare at least 1 million values per second, one value each micro second.

/Ubbe

 

[ebplayer]

to byndhlptom:

I'm missing traffic on talkgroups in my area, when more talkgroups are added to the list, regardless of whether the added talkgroups have traffic or not...

Same here, I should've noted that originally. Since the EBRCS system is setup regionally that was one of the reasons I tried a separate scanlist with only the locals I was interested in.

 

[goodmore]

MY TRX Units definitely perform better with smaller lists. I have the one and two. If I program in the zip on both and listen they each take turns missing hits. That is on a scan list of 417. If I shorten it down to the dispatch channels and a few fire police say 50 channels the scanners seem to hit it all.

 

[sibbley]

Where do you have the squelch knob set? The squelch on the Whistler units is not the same as other scanners. You really need to set it between 1 and 3 o'clock. If the squelch is set in the white between 7 and 11 o'clock, the scan speed will be drastically reduced resulting in missed transmissions.

 

[ebplayer]

Where do you have the squelch knob set? The squelch on the Whistler units is not the same as other scanners. You really need to set it between 1 and 3 o'clock. If the squelch is set in the white between 7 and 11 o'clock, the scan speed will be drastically reduced resulting in missed transmissions.

I haven't had this experience, in fact if my squelch knob is turned past 12 most transmissions seem to struggle to break through. I've been leaving it on 11.

One thing I noticed in using an external antenna is that an FM BCB filter is a must. This was not the case with my older scanners such as Pro 92 and Icom R2.

 

[goodmore]

Just to clarify what I said earlier..... When my scan list is long I'm not missing hits because the scanner isn't getting through the list or the scanner stopped on another transmission. I actually hear two way conversations on one scanner that the other scanner missed all together. And the scanners will take turns doing it. Same scan lists. When the lists are shortened the scanners work great.

 

[DonS]

20 microseconds to fetch and compare two 16bit values seems reasonable even with a slow processor

Taking a TGs double word value from the DSP and compare to a table of TGs are very simple and do not require many clock cycles. You could probably compare at least 1 million values per second, one value each micro second.

Sure, if everything was in fast RAM. It's not. Everything is on the SD card. If it was all in RAM you'd run up against a hard limit of "how much you can scan".

Since all the important data is on the SD card, it takes far more than 20 microseconds (to say nothing of 1&#956;s) to determine if a given TGID is programmed, not locked out, in an enabled scan list, has a priority level higher/lower than any currently-active TGID, etc.

That said, the limiting factor is really "can we determine if a given TGID is 'interesting', including reading the necessary data from the SD card, faster than 'active TGID' messages can possibly be received from the trunked system?" Yes, we can. Even with a mix of P25, DMR, and NXDN, "scanning" over 4000 talkgroups, and on a heavily fragmented file system, I have never seen those queries take longer than 12ms - far shorter than the minimum interval between such trunked system updates.

If the OP is missing traffic, it's not because one system has lots of talkgroups enabled for scanning. Without further info, I'd suspect things like:
* multiple trunked systems enabled
* conventional channels enabled
* poor trunking data decode

 

[goodmore]

You nailed 2 out of the three. When I load it up with the zip code there are quite a few conventional channels enabled. And I am monitoring a trunked phase 1 system that quite frankly my 436 and 536 could not handle from location. The TRX scanners have a garbled transmission once in a great while.

 

[Ubbe]

The need for a super fast SD card in a whistler scanner seems to be a neccessity.

 

[wa8pyr]

I just got a TRX-1 and have been playing around with it. One of the first things I noticed after loading up my local trunked systems is that it seemed deaf to showing talkgroup action on a system with many talkgroups. I'm talking about the EBRCS system in the SF Bay Area which has about 480 talkgroup IDs.

I noticed that by making a scanlist with only particular talkgroups I wanted to monitor (150 out of 480) had the effect of hearing more traffic and talkgroups showing up with action that weren't showing up when trying to scan all 480 talkgroups.

Is this a bug? The scanner is scanning the same frequencies regardless, but there is something about the TRX-1 that seems to make it produce more action on talkgroups if the overall list of talkgroups is reduced via a scanlist. Anyone else observing this?

Not sure if the issue is the same or not, but in addition to the various notes from other individuals. . .

I've noticed on the WS1080 and the Pro668 (as well as others of their ilk) that the radio doesn't want to receive talkgroups unless they're added via library import rather than copy+paste, even though system frequencies, settings and talkgroups are identical.

For example, if I add System X manually by creating a system, entering site frequencies, then copying and pasting talkgroups so that my scan lists only contain what I want, the radio will rarely stop on anything.

However, if I use the Library Import feature, and manually delete the talkgroups I don't want in the scan list, the silly thing receives just fine (P25 simulcast issues aside).

This really is an inconvenience, since instead of adding only that which I want to hear, I have to manually surf through a much larger quantity of data, find what I want to delete, and delete it. If the stuff I'm not interested in is in big contiguous blocks of talkgroups it's not too bad, but if it's one here and one there scattered throughout the file, it takes a pretty long time.

Even so, I'd suggest trying a Library Import for the specific system you're trying to monitor and see if that makes a difference.

 

[k1xd]

If the OP is missing traffic, it's not because one system has lots of talkgroups enabled for scanning. Without further info, I'd suspect things like:
* multiple trunked systems enabled
* conventional channels enabled
* poor trunking data decode

I agree with what you're saying, except that:
*Only one system is enabled - with two sites - one cc each site
*conventional channels are disabled (not even loaded into scanner)
*Data decode is 99% as measured for these both cc on the PSR600

It's a very basic configuration. With lots of talk groups, things are missed. Things are missed while we're on the cc. I'm not sure it's repeatable. I've reloaded the SD card and then it seems to work.

My 'sense' is it's a software issue. I'll see if I can come up with a way that consistently produces the same results.

Is there a way to check decode % on the TRX-02... like the analyze mode on the PSR600?

I'm curious how you measured the 12 ms worst case time for SD card queries?

Dave
K1xd

 

[k1xd]

.
For example, if I add System X manually by creating a system, entering site frequencies, then copying and pasting talkgroups so that my scan lists only contain what I want, the radio will rarely stop on anything.

However, if I use the Library Import feature, and manually delete the talkgroups I don't want in the scan list, the silly thing receives just fine (P25 simulcast issues aside).

This sounds to me like something is 'flaky' in the software with talk groups... Similar to what I'm seeing rarely stops on anything or works OK. I've been running a few days with a small selection of talk groups and everything works OK. PSR600 and TRX-02 capture same traffic...

 

[DonS]

I'm curious how you measured the 12 ms worst case time for SD card queries?

I added some debugging code to measure the time required to determine "is this TGID interesting" (time between message received and result returned). Then I added code to send descriptive text out over USB (the "COM port"), along with all the other "CCDump" messages.

Scanning 2 DMR, 2 NXDN, and 1 P25 system over the last 3 hours, ~4200 talkgroups enabled over 6 scan lists, the maximum query time, so far, is 10ms. (It actually indicates 9ms, but it could be up to 10ms, due to aliasing with the interrupt-driven millisecond increment.)