SDS-100 Avoid P25 LINK while scanning?

[inigo88]

Hey guys,

I did a search but apologies if this has been discussed before.

I’m familiar with the call types the SDS-100 shows in the top right of the display, shown in this thread:

SDS100/SDS200: - Sds100 display field?

On the Trunked Detail display, in option 7, on all of the systems this field shows DATA when just scanning, and then flips to the system type (ex P25) alternating with LINK. Can anyone explain what LINK means? Thanks for the patience. Sent from my SM-G965U1 using Tapatalk

forums.radioreference.com

“LINK” data can show up either on P25 conventional repeaters or P25 trunking systems (when non-voice data is being carried on a voice frequency). I find this stuff interesting using monitoring software like Unitrunker or DSD+, but as a scanner feature it seems to just create a nuisance.

1. On P25 trunking, I can’t see the upside to stopping scan and dwelling on a “LINK” frequency for multiple seconds while P25 voice is being missed on other channels.

2. On P25 conventional it gets a little more complicated. There may be P25 conventional repeaters that carry very little voice traffic but frequent data, so stopping on the data packets in a custom search or direct entry helps identify the frequency. But then once you have these frequencies in your scan list hanging the scanner up for 10 seconds at a time waiting on “LINK” on a P25 repeater with no voice seems silly.

Is there a way to turn “LINK” data off to prevent the scanner from dwelling on a LINK transmission?

 

[werinshades]

Hey guys,

I did a search but apologies if this has been discussed before.

I’m familiar with the call types the SDS-100 shows in the top right of the display, shown in this thread:

SDS100/SDS200: - Sds100 display field?

On the Trunked Detail display, in option 7, on all of the systems this field shows DATA when just scanning, and then flips to the system type (ex P25) alternating with LINK. Can anyone explain what LINK means? Thanks for the patience. Sent from my SM-G965U1 using Tapatalk

forums.radioreference.com

“LINK” data can show up either on P25 conventional repeaters or P25 trunking systems (when non-voice data is being carried on a voice frequency). I find this stuff interesting using monitoring software like Unitrunker or DSD+, but as a scanner feature it seems to just create a nuisance.

1. On P25 trunking, I can’t see the upside to stopping scan and dwelling on a “LINK” frequency for multiple seconds while P25 voice is being missed on other channels.

2. On P25 conventional it gets a little more complicated. There may be P25 conventional repeaters that carry very little voice traffic but frequent data, so stopping on the data packets in a custom search or direct entry helps identify the frequency. But then once you have these frequencies in your scan list hanging the scanner up for 10 seconds at a time waiting on “LINK” on a P25 repeater with no voice seems silly.

Is there a way to turn “LINK” data off to prevent the scanner from dwelling on a LINK transmission?

What's your System Hold time set at? Is this a Motorola or Harris Trunking system?

 

[inigo88]

What's your System Hold time set at? Is this a Motorola or Harris Trunking system?

I’m referring to stopping on link data for both P25 conventional and P25 trunking systems. The trunking systems are generally Motorola (BEE00 WACNs).

Hold times for both the conventional and trunked systems are all set to 0 (sec).

It seems like a logical conclusion would be to be able to toggle stop scan on link on or off like a service type, but I’m pretty sure that doesn’t currently exist on the SDS-100/200.

 

[werinshades]

I’m referring to stopping on link data for both P25 conventional and P25 trunking systems. The trunking systems are generally Motorola (BEE00 WACNs).

Hold times for both the conventional and trunked systems are all set to 0 (sec).

It seems like a logical conclusion would be to be able to toggle stop scan on link on or off like a service type, but I’m pretty sure that doesn’t currently exist on the SDS-100/200.

To understand your feature request, you're asking that once a conversation ends and the scanner remains for your system hold time to 0, you'd like it to scan faster? You're Using Site NAC and all that too ?

 

[GTR8000]

The scanner should never leave the control channel of a P25 trunked system, certainly not to dwell on a data channel.

If I remember correctly, this is a bug that @KevinC discovered with the SDS series, where the scanner can get hung up on a channel transmitting data, falsely believing that it's a control channel. This seems to primarily affect ASTRO 25 systems, and I believe after Kevin made the discovery I looked into it further and determined that it had something to do with a specific bit of signaling that was happening on those data channel. The exact details escape me now, it's been a while, and all of the details of the discussion are probably buried in that "I'm here to help" thread that went nowhere fast from @JoeBearcat. We're quickly approaching the 2 year anniversary of that thread and so far not a single meaningful bit of firmware has come out for any Uniden scanner...just a lot of code to support "revised hardware" for new production batches (i.e. different chips due to the shortages), and a few extremely minor fixes that wouldn't affect the majority of users. 😒

Bottom line is that I wouldn't hold my breath waiting for a fix.

 

[inigo88]

To understand your feature request, you're asking that once a conversation ends and the scanner remains for your system hold time to 0, you'd like it to scan faster? You're Using Site NAC and all that too ?

There are certain cases where P25 trunking system and user radios will exchange data on a voice channel rather than via the control channel. I forget what the specific examples are but I believe they include OTAP/OTAR rekeying and potentially other reprogramming. This link has some examples:P25 Best Practice presented by Tait Communications

When monitoring a P25 control channel with unitrunker these “data on voice channel” activities usually appear as an individual call with one or multiple radio IDs with type “Dat” rather than voice.

This behavior will show up as a voice call on the SDS-100 and the scanner will stop scanning on the frequency and then get stuck displaying “LINK” for the duration of the data call. It’s a nuisance and there should be a capability to ignore it.

I also gave the example of P25 conventional repeaters broadcasting lengthy data packets without P25 voice which the SDS-100 also displays as “LINK” and hangs up the scanner for extended periods of time. This is caused by a totally separate reason then the trunked example above, but the result for the end user is the same scanner getting stuck on a link call. Here’s a thread about the P25 conventional issue - I’ve looked at it in DSD+ and confirmed it’s long strings of TDU packets as is stated in this thread:data belch

Using site NAC to filter it out is a good idea and I’ll give it a try - but that will only work if the P25 data packets aren’t broadcasting the NAC but the voice packets are. This might be the case sometimes but not others, but I’ll definitely give it a shot.

Bottom line is that I wouldn't hold my breath waiting for a fix

No worries, I figured Uniden wasn’t going to drop everything and push a firmware update. I was just hoping smarter people than me might have figured out a workaround.

 

[AA4BK]

@JoeBearcat if this isn't already on The List you might want to add it.

 

[KevinC]

@JoeBearcat if this isn't already on The List you might want to add it.

That list sure is getting long.

 

[GTR8000]

There are certain cases where P25 trunking system and user radios will exchange data on a voice channel rather than via the control channel. I forget what the specific examples are but I believe they include OTAP/OTAR rekeying and potentially other reprogramming. This link has some examples:P25 Best Practice presented by Tait Communications

When monitoring a P25 control channel with unitrunker these “data on voice channel” activities usually appear as an individual call with one or multiple radio IDs with type “Dat” rather than voice.

This behavior will show up as a voice call on the SDS-100 and the scanner will stop scanning on the frequency and then get stuck displaying “LINK” for the duration of the data call. It’s a nuisance and there should be a capability to ignore it.

I also gave the example of P25 conventional repeaters broadcasting lengthy data packets without P25 voice which the SDS-100 also displays as “LINK” and hangs up the scanner for extended periods of time. This is caused by a totally separate reason then the trunked example above, but the result for the end user is the same scanner getting stuck on a link call. Here’s a thread about the P25 conventional issue - I’ve looked at it in DSD+ and confirmed it’s long strings of TDU packets as is stated in this thread:data belch

Using site NAC to filter it out is a good idea and I’ll give it a try - but that will only work if the P25 data packets aren’t broadcasting the NAC but the voice packets are. This might be the case sometimes but not others, but I’ll definitely give it a shot.

Any P25 trunked channel that is not acting as the active control channel is known as a "traffic" channel; they can carry voice and/or data. Although it's possible to permanently assign channels to either voice or data, it's not done very often. With data capable systems that are using TDMA voice exclusively, you will notice in Unitrunker that you have the FDMA version of the channel for data, and the two TDMA slots for voice. Obviously the two cannot coexist on the same frequency simultaneously. For a standard run of the mill 700 MHz ASTRO 25 system, the FDMA channels (control and data) would be 01-xxx LCN, and the TDMA voice channels would be 03-xxxx LCN in that specific example.

It's actually not unusual for a data traffic channel to be "dead keyed" for a long period of time when the system is particularly busy, as it's more efficient for the system to keep the channel reserved for data so that subscribers can transmit and receive data packets in quick succession without the repeater's carrier dropping.

One other major use of P25 data is GPS/AVL. It's probably the most common usage, in fact.

The SDS series should never tune to a traffic channel carrying data, as it should completely ignore the data grant and only process voice grants. Maybe this is a slightly different issue than Kevin found, if the scanner is actually following data grants. Yikes.

As for the NAC, I believe the FDMA data channel will broadcast the site NAC whenever it's keyed, no different from the voice channels. If I'm wrong, someone will correct me I'm sure.

 

[radiodog2009]

The scanner should never leave the control channel of a P25 trunked system, certainly not to dwell on a data channel.

If I remember correctly, this is a bug that @KevinC discovered with the SDS series, where the scanner can get hung up on a channel transmitting data, falsely believing that it's a control channel. This seems to primarily affect ASTRO 25 systems, and I believe after Kevin made the discovery I looked into it further and determined that it had something to do with a specific bit of signaling that was happening on those data channel. The exact details escape me now, it's been a while, and all of the details of the discussion are probably buried in that "I'm here to help" thread that went nowhere fast from @JoeBearcat. We're quickly approaching the 2 year anniversary of that thread and so far not a single meaningful bit of firmware has come out for any Uniden scanner...just a lot of code to support "revised hardware" for new production batches (i.e. different chips due to the shortages), and a few extremely minor fixes that wouldn't affect the majority of users. 😒

Bottom line is that I wouldn't hold my breath waiting for a fix.

I would like to see a better mouse trap than the SDS100 to eliminate simulcast splatter. If the voices are not over-modulating the carrier, it sounds great. Anything beyond that and it is not understandable.

 

[dave3825]

That list sure is getting long.

The demand for a spectrum display must have out weighted fixes for any and all bugs that were reported in the last few years.

 

[Ubbe]

The demand for a spectrum display must have out weighted fixes for any and all bugs that were reported in the last few years.

That will always be the case. They look at their finances each quarter and discuss what they will gain if they put resources to fix firmware bugs for free. It will satisfy 10 users at an internet forum and the rest of users will not care or are not aware of that there is a problem. If they instead develop a new feature that retailers can advertise as a great new tool, or even use their pay-for-a-key system that already are in place in their scanners and at their web site and doesn't cost any extra to them and charge $9.95 for the waterfall, then that could boost sales. And also they will have to prioritize the firmware changes that makes it possible to use new hardware components to continue to make a profit from scanner sales.

/Ubbe