SDS100/SDS200: Missed call-backs

[Davey1]

On my SDS100 I have a few P25 trunked systems among my favorites lists. I usually scan two sites on one of those systems in addition to another favorites list that has a few DMR channels, non-trunked. On the trunked systems I have the delay on the talkgroups set to 2 seconds and the hold time on the systems set to 1 second. In spite of those settings I still miss some of the replies during a dispatch. From what I'm able to see on the screen it looks like the scanner is holding on the talkgroup but I hear no reply many times. What could I do to improve this behavior so that I don't miss anything? Should the hold time match the delay time? Or should they be different, and by how much?

I'm comparing results with a TRX-1, and Whistler 1065 and the SDS 100 side-by-side. Thanks.

 

[jasonhouk]

On P25 trunked systems (especially multi-site), the scanner sometimes appears to be "holding" on the active talkgroup but still misses the reply transmission after a dispatch. This is a common complaint.

Key Settings Explanation

• Talkgroup Delay (set to 2 seconds): This is the "hang time" the scanner stays on the talkgroup after a transmission ends, waiting for a reply.
• System Hold Time (set to 1 second): This controls how long the scanner stays on the entire system (checking sites/control channels) before moving to the next Favorites List or system.

The mismatch (2s delay vs 1s hold) often causes the scanner to resume scanning the next system/site too quickly, missing short replies on trunked P25 systems (which have very little built-in hang time on the voice channel).Recommended Fixes (Try in This Order)

1. Match or Increase Hold Time
   Set System Hold Time to 2–4 seconds (at least match or slightly exceed your talkgroup delay).
   Many users find 2–3 seconds works best for P25 trunked systems. A hold time of 0 uses the scanner’s minimum (~1–1.5s per site), which is often too aggressive when monitoring multiple sites.
2. Adjust Talkgroup Delay
   Try lowering talkgroup delay to 1–1.5 seconds (or even 0–900 ms on some tests) if replies are very quick. Higher delay helps with casual listening but can make the scanner "stick" and miss activity elsewhere.
3. Other Important Tweaks for SDS100
   • Reduce the number of active sites/Favorites Lists if possible — scanning two sites + DMR conventional slows resume time.
   • Ensure P25 Wait Time (under conventional/digital settings) is low (0–400 ms) to avoid clipping the start of transmissions, though this is more for conventional mixed-mode.
4. Advanced/Last Resort
   • Create a dedicated Favorites List with only the critical P25 systems (one max) and scan it separately or prioritized.
   • Compare exact audio start times side-by-side with the Whistler/TRX-1 to isolate if it's decode latency vs scanning resume.

Quick TestSet one critical P25 system to:

• System Hold Time: 3 seconds
• Talkgroup Delay: 2 seconds
• Scan only that list + minimal others

I'm fairly close to BG and frequent North Baltimore area, PM me with your contact information as I'm very familiar with the systems in that area and can share some programming with you.

 

[ofd8001]

You may also check to see if there are any Priority things going on. For example, a VHF frequency on priority or some type of weather alert priority. Your scanner may be jumping off the talkgroup to check for activity on these.

(Just touching all the possible bases.)

 

[Ubbe]

If you are comparing with Whistler scanners I will assume it is not a simulcast system where all transmission are sent out on all sites.
Then it will matter what site you are monitoring as it will need some mobile units to be affiliated to your site to make transmissions be active on it. Can you check that the Whistlers and Uniden scanner are actually on the same site?

I use something like a 5 sec TG delay time, or 7sec on a Whistler, as some users are slow to respond. Maybe your Whistler scanners are set to a longer delay time.

System hold time are only used if there are no active conversations and it waits on the system for that time for any activity to start. But if it detects a call then that timer will no longer be in use and it is the TG delay timer that instead are in effect for that system.

For important/priority systems I choose a 5 sec system hold time that makes it have a higher chance of hearing the start of a conversation but will slow down scanning of the whole scan list. If it is okay to more often find yourself that scanning stops in the middle of a conversation you can then set system hold to 0sec to speed up the scan process.

When having several scanners then have that SDS100 do only simulcast systems and remove other systems from it and put those in the Whistler scanners. If possible do not scan same systems in several different scanners and let them scan only a few systems each to improve scan rate.

If there's still issues with the SDS100 then set TG delay to 10 sec and monitor its signal strength when a conversation disappears but are still heard on the Whistler scanner. If the signal strength disappeared then the scanner are interfered by another strong signal and it's time to start trying out different filter settings for that site.

/Ubbe

 

[Davey1]

You may also check to see if there are any Priority things going on. For example, a VHF frequency on priority or some type of weather alert priority. Your scanner may be jumping off the talkgroup to check for activity on these.

(Just touching all the possible bases.)

There are no priority channels set, so I don't believe that would be the issue here. Thanks.

 

[jtwalker]

There are no priority channels set, so I don't believe that would be the issue here. Thanks.

Weather and Close-call count as priority modes also. Either of these set?

 

[Davey1]

If you are comparing with Whistler scanners I will assume it is not a simulcast system where all transmission are sent out on all sites.
Then it will matter what site you are monitoring as it will need some mobile units to be affiliated to your site to make transmissions be active on it. Can you check that the Whistlers and Uniden scanner are actually on the same site?

I use something like a 5 sec TG delay time, or 7sec on a Whistler, as some users are slow to respond. Maybe your Whistler scanners are set to a longer delay time.

System hold time are only used if there are no active conversations and it waits on the system for that time for any activity to start. But if it detects a call then that timer will no longer be in use and it is the TG delay timer that instead are in effect for that system.

For important/priority systems I choose a 5 sec system hold time that makes it have a higher chance of hearing the start of a conversation but will slow down scanning of the whole scan list. If it is okay to more often find yourself that scanning stops in the middle of a conversation you can then set system hold to 0sec to speed up the scan process.

When having several scanners then have that SDS100 do only simulcast systems and remove other systems from it and put those in the Whistler scanners. If possible do not scan same systems in several different scanners and let them scan only a few systems each to improve scan rate.

If there's still issues with the SDS100 then set TG delay to 10 sec and monitor its signal strength when a conversation disappears but are still heard on the Whistler scanner. If the signal strength disappeared then the scanner are interfered by another strong signal and it's time to start trying out different filter settings for that site.

/Ubbe

At this time I'll just talk about a few of you suggestions, and experiment with the others later. You are correct that these are not simulcast systems. They are both single sites on the Ohio MARCS system. The sites being monitored are the same on both the SDS100 and the Whistler scanners. Also the TG delay times in all scanners are set the same to 2 seconds each.

Thanks for the suggestions. I will try them and see what happens.

 

[Davey1]

Weather and Close-call count as priority modes also. Either of these set?

None are set up.

 

[Ubbe]

The sites being monitored are the same on both the SDS100 and the Whistler scanners.

That could be a problem. Set both scanners to only scan one and the same site. If you listen to one site that have only one mobile radio set to the TG you are monitoring and that mobile are then moving to another site, then your site suddenly goes silent on that TG. If your other scanner are instead monitoring another site with several mobiles set to that TG it will still transmit that TG until all mobile units have been switched off or gone to another site.

If a monitor a trunked systems closest site to me I hear TG's randomly. Sometimes they are heard and sometimes not. If I instead tune to a site much further away that have a much higher channel capacity and a bigger load of users I can hear pretty much all TG's in the system.

/Ubbe