TRX-1 LCN order needed for DMR systems?
- Thread starter W4KRR
- Start date
- Status
That may because of increased hardware price and patents to read it. Your average P25 user doesn't want to pay another $50 who will never use it.
CanesFan95
Analog already is interoperable.
So does this basically mean that Unidens are the only true DMR trunking capable scanner?
Ubbe
Member
Uniden does DMR trunking, Whistler does not. AOR also have a DMR capable receiver but no trunking by itself.
/Ubbe
/Ubbe
Whistlers TRX do DMR trunking
My last side be side test of TRX 2 and 436
On cap plus, Con plus and signal channel DMR
Had the Whistler doing a better job tracking talkgroups on cap and con systems
On one channel DMR ham repeater, again slightly better on TRX
As others noted in this thread and as I observed
at times the Whistler was on an active TG while the
Uniden continued to scan on by
Ubbe
Member
TRX doesn't do DMR trunking per se. The manual also states this. TRX only scans all channels in the trunked system until it finds what it is searching for. Unidens BCDx36HP goes directly to the correct channelnumber/frequency it's decoding from the controlchannel, that's what defines trunk tracking.
/Ubbe
/Ubbe
Ubbe with all due respect your playing with semantics
The TRX tracks DMR Cap and Con trunk systems very well
How exactly it's done, who cares and techno garble is irrelevant
The TRX does do DMR trunk period and in my opinion and
experience better than the Uniden
A Whistler Rep stated what Ubbe said and told how it works. It does not use the CONTROL CHANNEL REST CHANNEL TO TRACK. It scans all channels programmed for the system looking for a talk group or other traffic.
Join Date: Jun 2003
Location: Franktown, CO
Posts: 3,995
Default
Quote:
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.
Join Date: Jun 2003
Location: Franktown, CO
Posts: 3,995
Default
Quote:
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.
woodpecker
Member
- Joined
- Aug 7, 2005
- Messages
- 693
Its not semantics, the Whistler DOES NOT trunk track DMR systems period!
It just scans the frequecnies you enter, you may find this picks up more traffic at times but its luck, it doesn't follow the rest channels on Cap+ and it doesn't decode the control channels on Con+, its an el cheapo botch compared to Unidens implementation which actually track the systems properly as per the Motorola specs.
troymail
Silent Key
....fails to track many times from my experience.... particularly CAP+
woodpecker
Member
- Joined
- Aug 7, 2005
- Messages
- 693
The Uniden will attempt to track properly as per the MotoTrbo specs, lazy Whistler didn't even bother to try, just tweaked the 5 year old PSR800 design slightly and added what ammounts to nothing more than conventional frequency DMR scanning.
They are so lazy they couldn't even update the documentation for these radios, the manual is full of errors and incorrect statements, they are complete joke of a company, they should have stuck to radar detectors.
OMG like I said in my experience and others the TRX does a better
Job monitoring Cap and Con systems than Uniden
We Don't care how it's done all we care it works
To techno garble is just that, I and 80 % of the don't care how its done
All we care it works and work well
The Uniden will attempt to track properly. But, my experience tells me that it only attempts to track properly. I have found more new Con+ TGID's on the TRX-1 than I have with the 436 or 536. That tells me that the Whistler is working better than the Uniden. The Uniden's still come up with bogus talk group ID's. The Whistler handled Simplex DMR out of the box, the Uniden just started working Simplex with last week's firmware update.
The Whistler will track Con+, CAP+, and DT3 without LCN. I'm following systems with the Whistler that I still haven't been able to find LCN's for on the Uniden. Yes, I know I can use DSD+ to find the LCN.
BTW, I own all 4 scanners. I owned the Uniden's since release. So, I am neither a Whistler or Uniden fanboy. Just a guy that uses all 4 radios daily.
The Whistler will track Con+, CAP+, and DT3 without LCN. I'm following systems with the Whistler that I still haven't been able to find LCN's for on the Uniden. Yes, I know I can use DSD+ to find the LCN.
BTW, I own all 4 scanners. I owned the Uniden's since release. So, I am neither a Whistler or Uniden fanboy. Just a guy that uses all 4 radios daily.
That's my experience also
WELL SAID. I agree completely.
woodpecker
Member
- Joined
- Aug 7, 2005
- Messages
- 693
Well keep your heads in the sand and carry on, the TRX scanners don't trunk track DMR, it seems there are lot of people who are easily fooled.
Then we'll just agree to disagree.
CanesFan95
Analog already is interoperable.
The whole point is... who cares! We get it, you don't like it. So go back to the Uniden forum and be happy there. I use my 1088 alongside a TRBO radio almost every day at work and it tracks the Cap+ system and conventional channels I'm interested in flawlessly. How it does it, I don't care. But it works. My only complaint is the lack of details when you are searching and land on a control channel (SYSID, Site # etc).
The same for me as sibbley said I own all 4 both 36x's and both trx-s I am a scanner fan and I use each scanner for their strong points.
- Status
