TRX-1 Missing DMR Transmissions

[KC1UA]

Regarding the conventional DMR issues, here's a video of the problem. The best examples of the TRX-1 receiving slot 2 when both slots are showing active in DSD+ are briefly at the very start of the video and then mainly after the 1:30 mark. There are numerous examples of slot 2 being active in DSD+ and no decoding of the same signal with the TRX-1.

Hopefully the visual will help shed some further light.

https://www.youtube.com/watch?v=NyYxJvWO1KY

 

[EricCottrell]

Hello,

I suspect only a dozen or so beta testers as managing more can be a nightmare. It comes down to if anyone notices the problem. Scott's testing is helpful as it goes further than a generic "missing transmissions" complaint.

The WS-1080 will likely have the same problem as both use the same processor family and code base. The TRX-1 has a third more flash, which is the reason you need the TRX-1 for upcoming added NXDN stuff.

The DMR scheme reminds me of the Pro-92 scheme of doing Motorola analog trunking by reading the subaudible data on the voice channels. This has the possibility of working better for DMR as there is more complete data in the EMB portion of the DMR voice channel transmission. The downside is that it takes longer to receive the data.

73 Eric

 

[KC1UA]

That's funny you mention that, between this and Dave's mention of the "PRO-92 bug" it made me wonder along with that excerpt from the manual if that's what they were doing, didn't they call it "slow speed handshake" with the 92?

In any event, Whistler's rep Brian called me again late this afternoon and we had another chat based on the new information I provided. They are certainly in tune (pun intended) with these issues and I expect they're working on the issues. Hopefully they'll get them fixed soon. The audio coming from this scanner is superb.

Looking forward to hearing more input from other TRX-* users as well as those with "retrofitted" DMR capability.

 

[Comp-100]

Funny to see these old basic bugs in there especially the 0.0Hz one since they were apparantly tweaking all the delays and timeout so much, how they could have missed this basic bug is a mystery. Looks like customers are the real QA team.

If they are not using the control channel, i see the potential for many sutble problems with different systems, but more importantly a practical limit to how many channels they can really monitor at once. This seems serious.

The no slot-2 if no slot-1 also seems like a basic, but serious error that may be related to how they monitor a freq vs. channel (slot) Looks like their TDMA algorithm may have a speedup hack that's good for performance with slot-1, but fatally flawed. It could be that their 'squelch' algorithm is flawed and does not trip on frequencies if only slot-2 is active. All these could be related to trying to avoid the use of the control channel. Facinating stuff, and i will be very interested in how long it takes them to resolve the TDMA issue as a sort of measure of the viability of their basic approach.

 

[KC1UA]

It's important to note that the slot 2 issue only occurs on conventional DMR. It is not a problem on the Con+ systems I am monitoring.

An updated firmware when available will be great. A statement from Whistler sooner would be ideal. Stuff happens. At least in this day and age firmware can be flashed and problems fixed (and sometimes other things broken). I was a little surprised that they missed these problems as well but as Eric says maybe there were indeed a limited amount of beta testers.

I'll say it again, to the folks that created DSD+, hats off to you. Anyone wanting to do serious tests of DMR (and down the road NXDN) issues NEEDS to have this hardware software setup. Tim was actually the first one that did so, at the time that I was using the 436HP as a comparison tool. DSD+ is really what allowed for the results to be clear. So as not to go off on a tangent about DSD+ though, if you're not familiar and are interested just search this site for it and you'll find a ton of info.

Looking forward to hearing from the Whistler folks here, but I am encouraged that they have contacted me directly and they are most welcome to continue if it helps the cause.

 

[AA6IO]

Been listening to a lot of DMR with TRX-1 and 2 since yesterday. I don't have DSD Plus running at same time like Scott, but I do notice "no" slot 2 transmissions. On Unidens, see a fair amount (not lots) of slot 2 on systems like Long Beach Transit. TRX-1 and 2 not picking these up, or if they do, showing as slot 1.
Glad to hear Scott is in contact with Whistler and that Whistler is taking a pro-active stance. The audio sounds great, so once these issues get settled, should be pretty good DMR set-up. DMR, for me at least, is a whole different animal. I have lots to learn from some of you with more experience.

 

[AA6IO]

One other question? If the protocol is looking at each channel rather than a single control channel, isn't that really conventional rather than trunking? Trying to understand that concept.

Steve AA6IO

 

[EricCottrell]

Hello,

It is not an old bug, but rather a repeat of an implementation error, since Motorola decoding and DMR decoding are likely separate sections of code. Later scanners dropped this scheme in favor of decoding the Motorola control channel, so the code was likely eliminated.

P25, DMR, and other digital voice systems blur the division between conventional and trunking as you can have talkgroups on either system. The control channel is the scheme used to allocate and direct users of a talkgroup to the correct frequency (and slot if DMR). The scheme of just scanning the frequencies for activity will work on a scanner, since it is only receiving voice activity on the system.

The scanning scheme has some disadvantages. A scan rate of 70 cps means it takes about 14 mS for the scanner to tune and determine if there is a signal. Each DMR frame is about 30ms long. I assume the scanner would wait several frame times to determine frame sync, so that adds about 60mS. The EMB information is across 4 frames, which adds an additional 90mS. It might take 0.11 to 0.17 seconds for the scanner to tune to an active channel and determine if it is of interest.

That is not too bad, but it gets worse if you add talkgroup hold and talkgroup lockouts to the mix. As the system gets busier, the scanner has to spend 0.11 to 0.17 seconds on each active frequency and determine if it is a talkgroup of interest.

It might take about 0.4 seconds for the scanner to go through the 28 empty channels. A single pass of frequencies on a 4 frequency DMR system might take between about 0.5 to 1.1 seconds.

This assumes perfect conditions with a strong signal.

73 Eric

 

[AA6IO]

Thanks for that explanation Eric. Been ham/scanning a long time but continue to learn lots of new and interesting info from so many of you.

 

[DaveIN]

That's funny you mention that, between this and Dave's mention of the "PRO-92 bug" it made me wonder along with that excerpt from the manual if that's what they were doing, didn't they call it "slow speed handshake" with the 92?

In any event, Whistler's rep Brian called me again late this afternoon and we had another chat based on the new information I provided. They are certainly in tune (pun intended) with these issues and I expect they're working on the issues. Hopefully they'll get them fixed soon. The audio coming from this scanner is superb.

Looking forward to hearing more input from other TRX-* users as well as those with "retrofitted" DMR capability.

Well Scott, on my 10x8 I locked out all zero frequencies in my DMR scan lists and I still only hear occasional audio while the BCx36HP is capturing nearly everything. Using the same antenna and running a limit search on the 10x8, I hear a lot of intermod frequencies. If I attenuate globally I loose everything but the frequencies with full signal.

 

[KC1UA]

Well Scott, on my 10x8 I locked out all zero frequencies in my DMR scan lists and I still only hear occasional audio while the BCx36HP is capturing nearly everything. Using the same antenna and running a limit search on the 10x8, I hear a lot of intermod frequencies. If I attenuate globally I loose everything but the frequencies with full signal.

Interesting. It made a remarkable difference for me. We are talking about two different scanners though. Are you monitoring a Con+ or a Cap+ system? All I have here are Con+ so can't comment otherwise.

 

[mitreffahcs]

TRX-2 Slot 2 DMR

Just posted another and hopefully more helpful video illustrating the DMR issues with the TRX-2. There's not a ton of DMR in my area, so it's taken me a while to do more testing. I've tried to force my MD-380s into slot 2 for simplex, but it doesn't work.

https://www.youtube.com/watch?v=7Utx5OHmOew

At any rate...since someone brought up some valid points about scanning, in this test I've parked the TRX-2 on my local DMR-MARC repeater frequency and have an MD-380 tuned to the same repeater. The audio in the video is from the MD-380, there was never any audio from the TRX-2 despite the indicated full signal strength (poss need to use the atten?). This traffic is local traffic which occupies slot 2 of the repeater. I've never heard any slot 1 traffic on the repeater, so unfortunately I can't post a side-by-side.

My TRX-2 settings for the repeater are as follows, DG Mode: Dig (although I tried auto and there is no difference). Sq Mode: None, Sq Search unchecked, DMR checked, Color Any, Slot, Any, RadioID unchecked, TGID Any and the rest should be defaults.

Thoughts, comments? I'm open to testing new ideas, not really sure what else to try at this point. If anyone in the NC RDU-Triangle area wants to do some testing on the repeater, pm me, I'd be more than happy to help.

 

[KC1UA]

I believe I have a workaround for the conventional DMR Slot 2 issue.

I programmed my "test system" in as a trunked DMR system instead of conventional. One frequency, proper color code, and appropriate talkgroups.

I can confirm that in this manner Slot 2 is appearing and working fine, regardless of the status of Slot 1.

Jeff of Hamstation advises me that this was the way conventional DMR had to be programmed before the firmware upgrade, but I got my TRX-1 after the newest firmware so never tried this until now. It does appear to be a viable workaround until Whistler fixes the problem.

 

[WhistlerWendy]

Hi all -
I have been out since Thursday on some R&R and just catching back up with everyone. We have generated a update and it is in the final stages of testing and should be released tomorrow. I'll post a sticky when the update is available!

Thanks!
WW

 

[KC1UA]

Thanks Wendy, much appreciated. I'll look forward to giving it a try.

Hi all -
I have been out since Thursday on some R&R and just catching back up with everyone. We have generated a update and it is in the final stages of testing and should be released tomorrow. I'll post a sticky when the update is available!

Thanks!
WW

 

[jcardani]

Hi Wendy,

Great news! Any update whether the firmware will work on RAS enabled systems?

thanks!

Hi all -
I have been out since Thursday on some R&R and just catching back up with everyone. We have generated a update and it is in the final stages of testing and should be released tomorrow. I'll post a sticky when the update is available!

Thanks!
WW

 

[jje64]

Also, can Wendy or anyone with a radio comment on if the TRX models will track a pure ETSI Tier III system?

I am trying to decide from which vendor I should purchase. I have been partial to the Whistler products, but how the radio will deal with RAS and support of Tier III are a must for my needs.

Thank You
jje64

 

[buddrousa]

I was tracking a TAIT TIER 3 system Sunday in the car with my TRX-2 and my BCD436HP with no missed traffic as of now it has 3 repeaters 6 time slots per site and 3 of 5 sites turned on.

 

[mitreffahcs]

Scott, you're a genius! This works perfect on my local DMR repeater! I only have one repeater loaded, but will do more testing with several repeaters.

I believe I have a workaround for the conventional DMR Slot 2 issue.

I programmed my "test system" in as a trunked DMR system instead of conventional. One frequency, proper color code, and appropriate talkgroups.

I can confirm that in this manner Slot 2 is appearing and working fine, regardless of the status of Slot 1.

Jeff of Hamstation advises me that this was the way conventional DMR had to be programmed before the firmware upgrade, but I got my TRX-1 after the newest firmware so never tried this until now. It does appear to be a viable workaround until Whistler fixes the problem.

 

[trido]

do the update from today

i think slot 2 issue fixed.

Scott, you're a genius! This works perfect on my local DMR repeater! I only have one repeater loaded, but will do more testing with several repeaters.