Clarification for NXDN decoding

[troymail]

From my personal experience monitoring various NXDN systems of different sizes and types, I think rather than

"...may not function correctly on all systems."

it should read:

"...may not perform optimally on all systems."

At some point, I may go into the wiki and document my recommendations on optimizing the configuration to achieve the best performance.

 

[ka3jjz]

From my personal experience monitoring various NXDN systems of different sizes and types, I think rather than

"...may not function correctly on all systems."

it should read:

"...may not perform optimally on all systems."

At some point, I may go into the wiki and document my recommendations on optimizing the configuration to achieve the best performance.

OK I'll make the change in the wiki presently. And please do develop something for optimizing the configuration - we have a gap in our FAQ that needs to be filled. Mike

 

[troymail]

Will do --

 

[garys]

Thanks. I didn't know that and don't know anyone who knows it. Other than you.

Yes, it actually is -- but you have to know to click on the site to see the channel numbers.

You can't see NXDN channel numbers from the System level:

https://www.radioreference.com/apps/db/?sid=8212

But you can see the channel numbers from the site level:

https://www.radioreference.com/apps/db/?siteId=24771

So, in my example above, if you click on the first one, and then select a site (such as Canton), you'll then see the channel numbers.

Mike

 

[mtindor]

Thanks. I didn't know that and don't know anyone who knows it. Other than you.

It does seem like that, doesn't it A few know, but it's not common knowledge. But people should just be more inquisitive -- If they were, they might click on a site once in a while and see that there is sometimes more useful information in there. Not only do you see channel number / LCN info, but you also see reported site neighbors (if somebody previously submitted those), etc.

I think it's only like that on NXDN trunked systems. Not sure why it's like that. Probably has something to do with NXDN channel numbers taking up more valuable screen real estate on the RRDB main system screen than do the LCNs for LTR and DMR (which only take up two spaces). Lindsay may have simply wanted to avoid any inheritent issue with alignment of data on the main screen that might occur if you throw more characters into the cells.

Mike

 

[racingfan360]

No scanners decrypt encrypted or scrambled transmissions. This would be illegal anywhere on Earth (regardless of any opinions to the contrary.)

If we were to use the terminology correctly, then

Dave, completely agree on your point re terminology. However the bit on scrambling isn't true for several countries outside North America. And as examples, the Yupiteru 3300 has a voice inversion descrambler and the AOR DV-1 descrambles NXDN.

 

[racingfan360]

OK I'll make the change in the wiki presently. And please do develop something for optimizing the configuration - we have a gap in our FAQ that needs to be filled. Mike

Mike, could I suggest you also add that only the Whistlers and DSD / DSD+ decode NXDN9600 and NXDN4800.....the AORs only cover NXDN4800. In believe the R8600 is similar but can't confirm.

Also, technically, NXDN trunked requires a network key and system key file to be added to a Kenwood or Icom transceiver to enable it to decode.....unlike a scanner, a conventionally programmed transceiver wont work at all.

 

[ka3jjz]

Right now, I'm pretty sure that the scanners can't distinguish between NEXEDGE or IDAS, so putting that distinction on them is a moot point. And speaking of those 2 types, I don't want to give any ideas to anyone as to how to program a Kenwood or Icom NXDN radio for reasons I think are obvious. The fact that there are such radios are briefly mentioned on the NEXEDGE and IDAS pages, and that's enough for now. There are other places to find out (legit and otherwise) about how such a radio is programmed; the wiki won't be one of them.

Keep in mind that the wiki is a member edited db; you can make those changes yourself. However I've added a couple of things in line with what you mentioned. 'nuff said

Mike

 

[DaveNF2G]

Dave, completely agree on your point re terminology. However the bit on scrambling isn't true for several countries outside North America. And as examples, the Yupiteru 3300 has a voice inversion descrambler and the AOR DV-1 descrambles NXDN.

Sorry, but prohibitions on unauthorized decryption are universal. Some of the countries where these "descramblers" are available don't even allow monitoring of most communications in the clear.

Also, I have found no reference in AOR's product materials to decryption relating to NXDN.

 

[racingfan360]

Respectfully Dave, I was not referring to the unauthorized decryption (ie use of a scanner), which I do not condone, but was merely pointing out that there are places 'on Earth' where scanners are available and it is perfectly legal to buy a scanner that can de-scramble communications. The Alinco DJ-X11E/T is a further example that de-scrambles voice inversion analogue communications, and the ADCR25 de-scrambled NXDN and BP DMR scrambling. I'm sure there are others.

Anyway, back to NXDN: the AR-DV1 de-scrambling function is described here https://forums.radioreference.com/aor-receivers/354555-nxdn-descrambling-ar-dv1.html

The table at the top of the AOR homepage AOR,LTD. Tokyo, Japan Home Page refers to the NXDN [de-]scrambling capabilities of the DV1 and DV10. Not available in the US version or on their website - obviously.

 

[wa8pyr]

Along comes Whistler, who just requires you to put ALL active frequencies associated with a given site into the site -- no need for RANs, color codes, LCNs or channel numbers.

I'm not entirely sure about this; when I programmed the local NXDN system in a TRX-1, it absolutely would not work correctly. It was missing transmissions all over the place even though all of the (100% confirmed) channels were entered; once I figured out the proper channel numbers and programmed them into the radio it scans the system just fine.

Wondering if there is some sort of hybrid thing going on, where it's scanning the voice channels and at least partly monitoring the control channel.

 

[mtindor]

I'm not entirely sure about this; when I programmed the local NXDN system in a TRX-1, it absolutely would not work correctly. It was missing transmissions all over the place even though all of the (100% confirmed) channels were entered; once I figured out the proper channel numbers and programmed them into the radio it scans the system just fine.

Wondering if there is some sort of hybrid thing going on, where it's scanning the voice channels and at least partly monitoring the control channel.

You programmed channel numbers into the TRX-1 for NXDN? How'd you do that? YOu can't do that via EZScan.

My TRX-1 is still on the blink, so I can't test to see if you can enter them manually from the keypad. No way to do it in EZScan though.

Mike

 

[DaveNF2G]

Anyway, back to NXDN: the AR-DV1 de-scrambling function is described here https://forums.radioreference.com/aor-receivers/354555-nxdn-descrambling-ar-dv1.html

The table at the top of the AOR homepage AOR,LTD. Tokyo, Japan Home Page refers to the NXDN [de-]scrambling capabilities of the DV1 and DV10. Not available in the US version or on their website - obviously.

"(For 15 bit digital scrambling mode NXDN signals. Does not support encrypted mode NXDN signals )"

"Please note that although the display shows "ENC.CODE", it actually means "descramble" code. No relation to encryption."

Somebody is having a hard time using the terminology correctly.

Scrambling IS encryption.

 

[ka3jjz]

OK this has gotten way off topic. Let's take the scrambling discussion elsewhere; the original topic was to update the description of how the TRXs handle NXDN for use in the wiki as part of the warning template..

Back on topic, folks...Mike

 

[werinshades]

Monitoring NXDN or MotoTRBO using a TRX-1 or 2 is not the optimal way. Their has been some discussion on this subject in other forums, but my experiences have been less than desirable. If Uniden offered NXDN as a "paid upgrade" for the royalty fees as they did with MotoTRBO and Pro Voice, they would do very well.

As it has been discussed here, TRX scanners do not utilize the control channel for these systems. It reminds me of the old days of Trunk Tracking and until I figured out you need that control channel, scanning these systems accurately was next to impossible. Diga-Talk runs a large NXDN system, and RAN-6 and RAN-24 is needed for the systems I want to monitor. Their were some reports on the forums prior to my purchase they resolved the NXDN control channel issue. That was false, but the NXDN bug bit me, and now I have a good idea what I'm listening to and I want it as good as other trunking systems. Also, some 3.125 khz frequencies are being thrown in the RAN's, so hopefully this will be addressed by Uniden or Whistler as these can't be programmed correctly at this time.

 

[daddyjohn]

When this discussion came up I decided to block the control channels for the nxdn system I monitor and I can confirm that it makes no difference on the trx-1 if you have the control channels enabled or disabled.

Sent from my SAMSUNG-SM-T337A using Tapatalk

 

[werinshades]

When this discussion came up I decided to block the control channels for the nxdn system I monitor and I can confirm that it makes no difference on the trx-1 if you have the control channels enabled or disabled.

Sent from my SAMSUNG-SM-T337A using Tapatalk

I did that too, until I realized that at times the control channel becomes a voice channel.

 

[daddyjohn]

I did that too, until I realized that at times the control channel becomes a voice channel.

Yes, that's a downside.

Sent from my SAMSUNG-SM-G890A using Tapatalk

 

[troymail]

I think alot of the problem with these systems is a lack of stadnards similar to P25. P25 is required to have certain consistency to be marketed at P25 compliant. Not so much for non P25 type systems.

The only NXDN system I've seen a problems with receiving since the NXDN release are NXDN-C systems with a large number of frequencies per site and some systems where the voice channel currently being used changes at a very rapid rate (i.e. as soon as the called releases the PTT the next voice call on that talkgroup instantly jumps to a different frequency). From my experience monitoring other system types (P25, Motorola, etc.), there tends to be a short hold/delay time where a response on a talkgroup will be able to reuse the same frequency. For some NXDN systems, particularly public safety it seems, the frequency is released immediately and the response nearly always comes on a different frequency. NXDN-D systems seems to use "home" frequencies and you're less likely to miss a response.

The other thing that adversely impacts monitoring a NXDN trunk system is when you try to monitor multiple sites of a multi-site system. This somewhat equates to monitoring a system/site that has a large number of frequencies in that the radio has to check every frequency on every pass. That is - if a user imports and loads, for example, all 5 or 6 sites of a multi-site system and each site has 4-6 frequencies, the radio is having to check 20-36 frequencies on each and every pass. You are guaranteed to miss responses this way - even worse if it is one of those public safety systems I mentioned above that rapidly changes the voice frequency between voice calls since many calls are very short.

So, you have to be smart about your programming for the best results.

 

[DaveNF2G]

I believe GE/Ericsson/whatever referred to that as "aggressive trunking" and Motorola called it "transmission trunking" if I have the attributions right.