TRX-1 LCN order needed for DMR systems?

[Ubbe]

Delay can/must be set per TG on digital channels.

There is information about active TG's once each 360mS on the voice channel.

The TRX hold/pause will hold on to the TG and scans the remaining channels on that site, including the control channel. The TG isn't displayed during that time.

Uniden BCD536HP goes back and monitor only the control channel on that site when holding on to a TG.

/Ubbe

 

[sibbley]

I'm saying that with a 2 second delay, it's most definitely not 2 seconds before the radio resumes scanning, probably 1 second or less. I have adjusted my delay times to 4 seconds, and it doesn't wait 4 seconds.

Mine works good on 2 second delay. I have not timed it, but it seems like 2 seconds. It definitely waits long enough to see if there will be more traffic.

 

[CanesFan95]

The TRX hold/pause will hold on to the TG and scans the remaining channels on that site, including the control channel. The TG isn't displayed during that time.

Uniden BCD536HP goes back and monitor only the control channel on that site when holding on to a TG.[/Ubbe

Is that for Connect Plus or Capacity Plus?

 

[W4KRR]

Every single frequency (trunked or conventional) in use will transmit at all times the TG, Radio ID, Color, Slot, etc. What more could the scanner need to find any of your set criteria to track something?

Nothing else. Some of the responses seemed to indicate that the TRX-1 scans DMR systems conventionally, simply looking for any conversation, and doesn't trunk track them, which is apparently incorrect.

 

[mtindor]

Every single frequency (trunked or conventional) in use will transmit at all times the TG, Radio ID, Color, Slot, etc. What more could the scanner need to find any of your set criteria to track something?

Again, I don't own one. I just asked the question. However, per CCS247's post earlier in the thread, it certainly does sound like they are not making any use of the control channel and thus are relying on all of the frequencies being programmed in.

And you're right that since all those things are transmitted on a voice call, you could just put all frequencies in with no other information and it would pick up transmissions.

However, imagine if you had a 16 frequency site. On a Uniden, it would monitor the CC for traffic and direct the scanner to the proper LCN when traffic is noted, whereas on the Whistler you would have to be scanning all 16 frequencies regularly to not miss a transmission [and would have a greater likelihood of interference if you are in a location where those frequencies are in use by other agencies/systems.

And let's say you were on a 16-frequency site and you held on TG 100. The scanner would presumably scan those 16 frequencies while you are holding on the talkgroup, and if there is DMR on any of those frequencies it has to pause long enough to determine if the talkgroup you are holding on is active. On a Uniden, it would simply park on the control channel (in the case of Con+ of course) and wait for the CC to note traffic on TG100, at which time the scanner would be directed to switch to the proper LCN of the TG 100 call. That really has to happen faster than scanning 16 frequencies with varying degrees of active DMR talkgroups trying to find TG 100 in use.

I'd be interested to play with a TRX, but I wouldn't buy one. Of course, I didn't have any plan to buy one anyway since i don't need another scanner.

Mike

 

[Ubbe]

TRX cannot do DMR trunktrack. Perhaps Uniden got the patent for trunktracking from the controlchannel.

A problem with TRX is (monitoring the IF out audio) that it only stays approximately 100mS on a DMR channel which result in one chance of three to catch the info at 360mS intervals from the channel. I have to set dwell time to a value that will scan each channel at least three times but I still loose 10% of conversations.

Uniden stays 400-500mS on a DMR channel and I haven't noticed it scanning past any conversation. It even decodes the transmissions that the MD380 DMR radio sometimes misses, due to BCD536HP's better sensitivity in the 400MHz band.

/Ubbe

 

[buddrousa]

One company may be paying for the tracking using the control channel and the other company may going about it without the control channel. Not that this is the answer it may be an option.

 

[CanesFan95]

This reminds me about the whole PRO-92 Radio Shack / GRE scanner debacle. If Whistlers don't actually use the control channel (or actively follow the rest channel), then that's not trunktracking the right way.

 

[W4KRR]

I have to set dwell time to a value that will scan each channel at least three times but I still loose 10% of conversations./Ubbe

What value did you set for the dwell time on DMR trunked systems?

 

[Ubbe]

Uniden uses the dwell time for each site. Set it to 5 seconds and it monitors a sites control channel for 5 seconds. Whistler uses dwell time for a whole system. Set it 5 seconds and it still monitors each active channel for 100mS but when it comes to the last channel it starts over again with the first active channel and loops thru all channels until the timer runs out.

Dwell time setting depends of how many active channels and sites there are in a system and how high procentage you aim at, but you can never really achive 100% with a TRX. It's like playing a slot machine, even if you spin the wheels ten times you're not guaranteed a payout but the chances increase with each spin.

/Ubbe

 

[mtindor]

Uniden uses the dwell time for each site. Set it to 5 seconds and it monitors a sites control channel for 5 seconds. Whistler uses dwell time for a whole system. Set it 5 seconds and it still monitors each active channel for 100mS but when it comes to the last channel it starts over again with the first active channel and loops thru all channels until the timer runs out.

Dwell time setting depends of how many active channels and sites there are in a system and how high procentage you aim at, but you can never really achive 100% with a TRX. It's like playing a slot machine, even if you spin the wheels ten times you're not guaranteed a payout but the chances increase with each spin.

/Ubbe

Thank you for the clarification!

Mike

 

[Ubbe]

Dwell time setting depends of how many active channels and sites there are in a system and how high procentage you aim at, but you can never really achive 100% with a TRX.

I correct myself. Theoretically you could get 100% by entering each voice channel 4 times in succession.

I 'll try that myself and get rid of the dwell time, that always dwell in a system even if no channels are active. Multiplying channel frequencies seems to be more efficient and a much quicker way to scan a DMR trunked system with a Whistler scanner.

/Ubbe

 

[DonS]

A problem with TRX is (monitoring the IF out audio) that it only stays approximately 100mS on a DMR channel which result in one chance of three to catch the info at 360mS intervals from the channel.

If the scanner determines that no voice is active on either slot, it doesn't have to stay on the channel for 360ms waiting for talkgroup information that will never come.

 

[Ubbe]

Quadruple DMR voice channels= 100% success.

If the scanner determines that no voice is active on either slot, it doesn't have to stay on the channel for 360ms waiting for talkgroup information that will never come.

Problem is that it only stays 100mS even on active channels, I have confirmed that by listening on the IF out audio, and that time is too short. Either the time is fixed or the code that should detect the databit for an active channel (none idle mode?) in the datastream are not working. What I could read out of the DMR specification the info of active talkgroup on a voice channel are only sent once each superframe, which is 360mS long. Whistler doesn't seem to care about info from the controlchannel, except from it's voice slot.

I entered the trunked DMR voice channels 4 times in each site and since then I haven't missed a single call
and scanning are also faster without the excessive dwell times.

/Ubbe

 

[W4KRR]

I entered the trunked DMR voice channels 4 times in each site and since then I haven't missed a single call
and scanning are also faster without the excessive dwell times.
/Ubbe

Interesting! I may try this. Must each duplicated frequency be in a block of four next to each other, or separated by the other frequencies, or does it matter?

 

[Ubbe]

They MUST be next to each other, otherwise the important info might be sent while on a non related channel and you will miss it.

/Ubbe

 

[Ubbe]

I see one problem with the Whistler way of not using control channel scanning and scan all voice channels. If you set dwell to 0.1S it will scan the first sites control channel for the voice slot and as the time for that is 0.1S it skips the rest of the channels in the system. (S in display just blinks and are not flashing for 1second with ten sites in the system)

If you count the control channels in the system and multiply it by 0.1S and use as a dwell time, it will not be long enough when voice channels starts to be active, as each active channel sending DMR signal eats up 100mS. The problem becomes hugh if using quadruple frequencies for each voice channel. You'll need a very long dwell time that will make scanning other channels/systems extreamly slow or using a shorter time will have the dwell time skip the last number of sites in a system.

There is no good substitution for a control channel scan method with a Whistler scanner as the firmware stands now. The firmware needs to check a new channel if it's sending idle and immediatly continue scan or else it must wait 400mS for the active TG info to appear to check if it's valid or skipped.

Whistler are learning by doing so hopefully they'll get the experiance needed to make this work without infringing any patents.

/Ubbe

 

[DonS]

it only stays 100mS even on active channels

It will stay "only" ~100ms on an active channel only if that channel isn't currently carrying voice. If a channel is carrying voice frames in either slot, it will stay longer, looking for "interesting" group or unit addresses via LC PDUs (I presume you're referring to Full Link Control PDUs since those come in at superframe intervals - 360ms).

If neither slot is carrying voice frames (which can certainly be determined in less than 100ms), there is no reason to wait around for 360ms just to see if an LC PDU is received indicating "interesting" voice traffic. If there is no voice traffic at all, there certainly isn't any "interesting" voice traffic.

Examples (DMR sync detect time after squelch will vary):

Case 1: DMR sync detected, no voice present (just data on both slots):
* T+0: RF squelch open, start looking for DMR sync
* T+30: detect DMR sync, start looking for voice frames
* T+110: no voice frames - timeout, move on to next channel

Case 2: DMR sync detected, voice present:
* T+0: RF squelch open, start looking for DMR sync
* T+30: detect DMR sync, start looking for voice frames on either slot
* T+60: voice frames detected, start looking for LC
* wait for LC messages indicating "interesting" group or unit IDs on any slot where voice is active.

Putting the same frequency in 4 times will only help if a) the system sends non-voice data (i.e. data on both slots) for a while before sending voice frames and b) you're scanning lots of channels that break squelch and invoke their own timeouts. If (a) is not true (the system sends voice immediately), then the scanner will detect voice and will wait for the slow LC messages. If (b) is not true, then the scanner will get back around to that channel in time to catch the start of the voice transmission.

Watching a CON+ system here, I'll see multiple instances of Case 1 on one frequency followed by Case 2 on another frequency. A typical sequence is:
F1, DMR sync, no voice
F2, no squelch
F3, no squelch
F1, DMR sync, no voice
F2, no squelch
F3. no squelch
... repeat ...
F3, no squelch
F1, DMR sync, no voice
F2, DMR sync, voice on slot 2

In the last 2 steps, the time between "giving up" on frequency 1 (F1) and detecting DMR voice on frequency 2 (F2) is 60ms. It then starts looking for interesting traffic on F2 - it gets an LC 241ms after detecting DMR voice on F2, decides it's "interesting" (I have a wildcard TGRP object programmed), and I start getting voice output.

If I'd put F1 in there 4 times, the scanner would have stayed on F1 for another ~300ms, looking for voice traffic that wasn't coming. It would have been more likely to miss [up to] 300ms of the voice traffic on F2.

Watching what the scanner is doing, it's not missing any traffic. If I enable another DMR "system" (really a few local DMR-MARC repeater frequencies programmed as another "trunked system"), I still don't miss any traffic.

 

[Ubbe]

It will stay "only" ~100ms on an active channel only if that channel isn't currently carrying voice.

Case 2: DMR sync detected, voice present:
* T+0: RF squelch open, start looking for DMR sync
* T+30: detect DMR sync, start looking for voice frames on either slot
* T+60: voice frames detected, start looking for LC
* wait for LC messages indicating "interesting" group or unit IDs on any slot where voice is active.

I agree. That is how it SHOULD work.

I can see the T symbol in the TRX-2 display and DSD+ decodes a syllable from IF out but scanner stops on the conversation at different scan cycles. Sometimes on first hit, sometimes on second and so on and even after 10 seconds which is fifth time the trunked system is scanned with my test setup using a TIII system. Using quadruple frequencies always makes it stop on first hit when the T appears.

The firmware code have probably not yet matured to a workable state. There where earlier a problem that it did not decode the second timeslot, and then it decoded both slots at the same time, and then it seems to be back to ignore slot2. I skipped a TG on slot1 while there was a conversation at slot 2, that where also heard in right speaker from DSD+, but at next scan of the frequency it monitored it for more than half a second and continued scan when I at the same time clearly heard a second conversation in the right speaker from DSD+ decoding from IF out.

I assume that Whistler must have a multiprotocol signal generator handling P25, DMR, NXDN and more, and test their firmware and the code is written to handle each protocol according to their specifications. So these anomalies must be software bugs. I can see how easily it could be to write the code to skip a frequency when detecting a skipped TG, instead of first checking slot 2 for a valid TG.

/Ubbe

 

[buddrousa]

Ubbe you know DonS is the firmware writer for the Whistler Scanners.