Dwell Clarification + All conv DMR in one site?

[AggieCon]

Howdy,

Two questions:

Has anyone determined the exact function of the new dwell limit on the trunked systems? Is it the total time it will spend monitoring an acquired control channel? Is it the total time it will spend on an entire system (assuming no voice traffic), even if no control channel is decoded? Is it the time it will spend on each frequency listed in the system/site? This might seem nuanced, but it matters. Additionally, what is the nature of the "auto" setting? It is very frustrating that there seems to be no official documentation about these changes, except for what the developer gets around to replying to in this forum.

Next, has anyone tried programing multiple conventional DMR frequencies in any of the following ways? I'm interested in cleaning up the programing footprint and perhaps speeding up scanning. Some folks appear to be having problems once they try to scan a couple dozen conventional DMRs all programmed as separate systems.

• 1 system with all (or a portion of related) DMR conventional channels. Put each frequency in as its own site.
• 1 system and 1 site with all (or a portion of related) DMR conventional channels. Put each frequency as a different LCN in the same site.

All of the relevant TGIDs and the wildcard would be entered on the talkgroup tab of the system. If they shared TGIDs, then you could use the voice channel to determine which frequency it is on. This method also reduces the number of wildcards needed.

The idea is that if there is no traffic on the frequency, the scanner will go through looking for a "control channel" and stop once it finds voice traffic. This is opposed to it hanging on a single system with no traffic because it is trying to wait for control channel decode until some "dwell" limit is hit. So, if this works, not only does it make the programing cleaner and easier, but, ideally, it would speed up scanning and allow people to more reliably scan a large number of conventional DMR frequencies.

What do you think?

 

[AggieCon]

Update: I started this thread from a webpage I opened this morning, so I missed the new DMR update thread posted shortly before. It makes my questions slightly less important but still interesting.

•Added Dwell Time column to the Trunked system list on the Trunked tab. This setting controls how long the scanner will remain on the selected trunking system before giving up and moving on to the next system or frequency.

So which is it, does Dwell move on to the next frequency, site, or system? Is it the total time spent on the frequency? If the DSP is able to decode, does it stay long, or does it leave once the dwell time is up? What is the nature of the "auto" dwell?

 

[DonS]

Dwell time:
It's the amount of time the scanner spends on a system per scan "cycle" (one scan cycle checks all trunked systems and all conventional channels), independent of the number of sites or frequencies programmed in a system. The defaults are (all times in milliseconds):
* P25: 800
* MOT: 1000
* LTR: 500
* EDACS: 800
* EDACS narrow: 1000
* DMR: 1000
(It's not really a "new" function. It's always been there. The only thing that's "new" is that the user can change each system's dwell time from the default.)

These times are not set in stone. There are cases where the effective dwell time might be longer or shorter than what's programmed. For example, in a P25 system where we haven't yet found a control channel, we'll increase the time to 2500ms per cycle until we find a CC.

DMR conventional:

•1 system with all (or a portion of related) DMR conventional channels. Put each frequency in as its own site.
•1 system and 1 site with all (or a portion of related) DMR conventional channels. Put each frequency as a different LCN in the same site.

These two methods are functionally equivalent, but there would be a very slight performance penalty to putting each frequency in its own SITE rather than just putting them all in one SITE.

Unless there are several talkgroup IDs associated with each frequency, it would be better to program them as conventional channels, rather than as a trunked system.

 

[AggieCon]

Unless there are several talkgroup IDs associated with each frequency, it would be better to program them as conventional channels, rather than as a trunked system.

Thank you VERY much for the information. When I started typing my first post, the conventional DMR programming option was not aware to me.

So, if a conventional DMR frequency has say 5 TGIDs and programming TGID 0 (essentially the conventional wildcard) is unacceptable to him because one of the TGIDs is annoying, I assume it is better (quicker) to still program it as a trunked "system" rather than as 4 separate DMR channels, all on the same frequency but with different TGIDs.

Which leads to dwell time: Is the dwell time different on various conventional frequency modes too? Or does it spend the same amount of time regardless of AM vs. FM vs. P25 Digital vs. DMR?

I am pleased that more of the scanner functions are becoming transparent and configurable to the user. Certainly, many of my problem list items are being crossed off. It's great that you and Whistler are putting the resources into further developing this product. Thanks!

 

[DonS]

So, if a conventional DMR frequency has say 5 TGIDs and programming TGID 0 (essentially the conventional wildcard) is unacceptable to him because one of the TGIDs is annoying, I assume it is better (quicker) to still program it as a trunked "system" rather than as 4 separate DMR channels, all on the same frequency but with different TGIDs.

Possibly, but not necessarily.

With only a few interesting TGIDs (like 4), it might be better to program them all as discrete conventional channels. This is because there is some time required to load and initialize a trunked system while scanning. It's much faster to load and initialize 4 conventional channels.

Now, if you had a large number of interesting TGIDs that might be present on a single DMR frequency (say, 10 or more), it would probably be more efficient to create a trunked system with that frequency and the interesting TGIDs.

Which method is "better" will depend on how many interesting (to the user) TGIDs are in use on the frequency and how many other objects (conventional channels, trunked systems) the user is also scanning.

Conventional channel: tune, look for DMR, look for "interesting" traffic (based on slot, color code, TGID)
Trunked system: tune, look for DMR, look for interesting traffic (based on color code and TGID), stay on system for dwell time.

Which leads to dwell time: Is the dwell time different on various conventional frequency modes too? Or does it spend the same amount of time regardless of AM vs. FM vs. P25 Digital vs. DMR?

Conventional channels have mode-specific timeouts separate from the trunked system "dwell time". For example, the timeout for conventional DMR is based on the DMR superframe time.

 

[BrianG61UK]

Dwell time:
It's the amount of time the scanner spends on a system per scan "cycle" (one scan cycle checks all trunked systems and all conventional channels), independent of the number of sites or frequencies programmed in a system.

WTF?

I just want it to scan all frequencies once each time round.
How could I have any idea what dwell time is appropriate -- I have no idea how long the scanner is taking to go through the stuff I have asked it to scan -- Whistler haven't provided any way for me to tell how fast it's scanning.

 

[AggieCon]

Program it as conventional. There's really no benefit to programming DMR as a system unless you have a ton of talkgroups or it is the only thing you will be scanning.

 

[BrianG61UK]

Program it as conventional. There's really no benefit to programming DMR as a system unless you have a ton of talkgroups or it is the only thing you will be scanning.

Another reason is that you can't get the scanner to show alpha names for talkgroups and radio ids when programmed as conventional (well not without slowing things down a lot anyway).

Sent from my SM-N9005 using Tapatalk

 

[Anderegg]

WTF?

I just want it to scan all frequencies once each time round.
How could I have any idea what dwell time is appropriate -- I have no idea how long the scanner is taking to go through the stuff I have asked it to scan -- Whistler haven't provided any way for me to tell how fast it's scanning.

Control channels spit out a stream of data, telling radios which frequency to find their talkgroup. They operate at 3600 or 9600 baud. If you have a 20 frequency trunked system, and it's 1AM and only one talkgroup is active, then that talkgroup channel assignment would be repeated over and over in the control channel stream, head to tail. If it's 1PM, and you've got 15 talkgroups active, and radios keying up requiring the CC to acknowledge them between spitting out channel grants, then the CC data telling your scanner that FD Dispatch t/g is on 854.1125 may come once every second and half to 2 seconds on a really busy active system. If your dwell time is 1 second, then the CC may have only spit out the grants for the first 12 active talkgroups, but not have gotten to your talkgroup yet before your dwell time expired and the scanner moved on. Make sense?

I would like clarification on dwell time for multi site systems. If I have 4 sites in one system, with a default 800ms dwell time, DonS's statement would indicate each sites CC is monitored for only 200ms for traffic, before the next sites CC is switched to for scanning. Also, when a transmission ends, does the dwell time expire and the scanner immediately moves onto the next system?

Paul