Status of NEXEDGE/iDAS/NXDN4800 decoding?

[inigo88]

Hey guys,

For those that don't know, NXDN officially became an "open standard" and was released on the NXDN Forum's website. You can download it here: https://www.nxdn-forum.com/download_file/

I haven't delved too deep into the reading yet but it's apparently based on 4-level FSK just like DMR. Virtually everything is documented in the standard, including the error correction algorithms and the types and dimensions of every packet. The NEXEDGE trunking control channel messages are even documented (the only difference between NEXEDGE and iDAS from what I can tell is the constant control channel vs burst data, but the packet format appears to be standardized).

I've played around with the Low Level Digital Audio API in C/C++, but digital signal processing algorithms are outside my capability so I haven't been able to write anything to hex dump the packets (I'm still trying to figure out what a Phase-Locked Loop is!), so I figured I'd ask the community here.

I'm just curious if everybody knows the standard is out, and if anybody has started trying to add NXDN4800 capability to DSD and/or write a DMRDecode like app to dump control channel data messages?

If someone would be willing to code or modify an existing 4-level FSK demodulator to fit the packet size spelled-out in the standard to dump raw hex/binary, I know myself and a handful of other users in this forum with an ocd-like eye for detail who would be happy to figure out what packet does what.

 

[racingfan360]

Thanks for the link.

>and if anybody has started trying to add NXDN4800 capability to DSD
So DSD does already decode NXDN9600 and NXDN4800 (I've tested it both with Kenwood NEXEDGE and Icom IDAS). Of course it still doesn't help with any form of NXDN Trunking...is that perhaps what you were specifically asking about?

Jim

 

[inigo88]

Yes my mistake, I was under the impression that NXDN trunking (NEXEDGE or iDAS) used 4800 and that's why it wasn't supported. Literally all the NXDN I've come across while scanning has been one of the two trunking variants, so I was curious what was holding back the DSD authors and porters now that the standard has been released. I'm afraid I don't know enough C to change the source code myself, but I'd be happy to help any way I can.

 

[Mike_G_D]

The way I understand it, DSD is only for voice decoding and was never intended to handle any type of trunking (the channel tracking voice following aspects associated with all trunking variations). It will decode (theoretically - I haven't been able to do this myself) the voice channels of conventional OR trunked NXDN (iDAS or NEXEDGE) just as it will the DMR MotoTrbo voice channels (which I have used it for successfully). In other words, the voice formats are independent of the trunking control channel formats - if I understand correctly, in both DMR (MotoTrbo) and NXDN the voice channel encoding is the same in both conventional and trunked modes (with the possible exception of some extra trunking control data being included in the voice channel data in trunked systems?).

In other words, you could still decode the voice channels of either variant of NXDN trunking or conventional repeater systems (although I am unsure about direct frequency simplex variations - I seem to recall DSD cannot decode simplex direct versions of MotoTrbo and have no idea about NXDN simplex) but you would need some other separate program like Unitrunker but designed to handle iDAS or NEXEDGE trunked protocols to use a separate receiver to track and control the voice channel receiver. So, what we need, is a Unitrunker variant (or addition to Unitrunker) program to do the trunk tracking for iDAS and NEXEDGE (which are two very different incompatible formats).

And, as you say, a form of DMRDecode for either trunked versions of NXDN would also be nice to have!

I believe the recently released standard of NXDN is strictly for the voice channel encoding and has nothing to do with any trunking control channel format but I have not studied it. As I understand it, the two forms of NXDN trunking are both proprietary and developed purely within their respective companies (ICOM and KENWOOD).

-Mike

 

[inigo88]

I believe the recently released standard of NXDN is strictly for the voice channel encoding and has nothing to do with any trunking control channel format but I have not studied it. As I understand it, the two forms of NXDN trunking are both proprietary and developed purely within their respective companies (ICOM and KENWOOD).

Mike, follow my link and go download the standard. Take a look at NXDN-TS-1-C version 1.3 "Trunking Procedures." It's a 132 page pdf describing in depth the format of all trunking related data packet types.

In other words, the voice formats are independent of the trunking control channel formats - if I understand correctly, in both DMR (MotoTrbo) and NXDN the voice channel encoding is the same in both conventional and trunked modes (with the possible exception of some extra trunking control data being included in the voice channel data in trunked systems?).

Not true, at least for DMR. For MotoTRBO systems, Motorola also has two proprietary trunking types (Capacity Plus and Connect Plus), but the way they made it work was simply by taking various types of data messages already outlined in the European ETSI DMR standard and making them do proprietary things. So on a connect plus control channel you'll have a bunch of DMR CSBK and SLCO type messages, and on a voice channel you'll have a bunch of DMR voice messages interleaved together (for TDMA timeslots) along with some extra CSBK and SLCO messages denoting the talkgroup and LCN, but everything on the system is straight out of the ETSI DMR standard. Motorola never re-engineered the digital data, they just chose what to make it do on their system (i.e. CSBKO=1 is a Connect Plus Neighbor message).

Considering there's an entire NXDN trunking procedures standard, I'd say it's very likely that Kenwood and Icom are using those data packets but assigning them in their own proprietary ways (like Motorola did with trbo).

Thanks for the link.

>and if anybody has started trying to add NXDN4800 capability to DSD
So DSD does already decode NXDN9600 and NXDN4800 (I've tested it both with Kenwood NEXEDGE and Icom IDAS). Of course it still doesn't help with any form of NXDN Trunking...is that perhaps what you were specifically asking about?

Jim, are you saying DSD in its current form already decodes NXDN voice on trunked NEXEDGE and iDAS systems? I was unable to get DSD to recognize or decode voice channels on an iDAS truinking system, and after reading some threads in this sub-forum I was under the impression that there's something slightly different about the way the NXDN trunked voice packets are structured that prevents DSD from decoding voice from them. Has that since been solved?

It will decode (theoretically - I haven't been able to do this myself) the voice channels of conventional OR trunked NXDN (iDAS or NEXEDGE) just as it will the DMR MotoTrbo voice channels (which I have used it for successfully).

See above, I was under the impression that NXDN trunked voice was still unable to be decoded, and had no luck when trying it myself.


FWIW, this is the thread that led me to believe NXDN trunking wasn't working with DSD: http://forums.radioreference.com/di...ware/223202-dsd-nexedge-help-suggestions.html

 

[Mike_G_D]

The actual voice data encoding is one thing; the extra data capacity for other uses including possible trunking data is another. You can define a LMR narrowband digital voice standard and, given today's environment, when you do so you would be well advised to give that standard some extra data (packets, frames, whatever) capacity for things like selective signalling, special private and group calling, and, of course, trunking control data. As you have outlined, for the ETSI DMR standard, extra data capacity was allowed and Motorola took advantage of that to create their proprietary trunking systems while still complying with the standard as far as the basics are concerned (such as basic voice encoding). DSD will still decode the voice of all current DMR variants (theoretically and ideally except for, maybe, the direct simplex format as I mentioned previously) because the voice data encoding is according to the standard but it will simply ignore the data pertaining to the trunking protocols and whatever else that is part of the extra data non-voice related (such as manufacturer specific proprietary functions). I expected the same to be true of the NXDN DSD capability.

There is no technical reason that a digital voice format cannot be made so as to be framed within a larger data grouping that includes extra data capacity for other uses and also so as to allow manufacturer discretion regarding what those uses may be as long as the actual voice data conforms to the standard. As I understood it this is what was done for the DMR standard. Based on what others in the know on these forums have said regarding NXDN this sounded like the case for that format as well. The iDAS and NEXEDGE trunking formats are proprietary and incompatible with each other - I forget which is which, but one is similar to LTR where there is no dedicated control channel while the other does have a dedicated control channel similar to what trunking formats such as common P25 and Motorola variants do. I will have to read the standard as you have suggested but it may be that instead of defining a complete trunking protocol it may only be defining the format for the data packets or frames that contain whatever trunking data a manufacturer deems necessary to put into them. In other words, something like "Here is where you put data concerning trunking operations - format it this way." What you put in there is up to you so long as it conforms to that data size and location. Anyway, I will have to read it myself but the thing to take away from what I am saying is that a transmitted digital stream may contain multiple types of data - there may be voice data mixed with lots of other stuff. That other stuff can include trunking information if used and applicable. But decoding programs can elect to ignore some or all of the "other stuff" and just focus on the voice data (and whatever relevant error correction and associated framing data pertains to the voice data) - that is pretty much what I thought DSD did.

-Mike

 

[inigo88]

iDAS is the LTR-like variant with the burst type data channel every 5-10 sec. NEXEDGE is the continuous control channel version. One reason that made me believe both versions were pulling from the same pool of data packets from the standard was because if you listen closely, the iDAS data bursts sound identical to the NEXEDGE control channel (just a short 1 second's worth).

The standard explains that there are both continuous and "composite" control channels, the latter being a mix of control data and voice. The RCCH (RF Control Channel) uses a frame type called FACCH (Fast Associated Control Channel) messages on composite control channels. I'd be willing to bet that iDAS is simply the "composite" case in the standard, while NEXEDGE is the continuous case.

 

[racingfan360]

>Jim, are you saying DSD in its current form already decodes NXDN voice on trunked NEXEDGE and iDAS systems?

So just to confirm, in my experience DSD does NOT decode any form of NXDN Trunking. I have personally tried it against several Kenwood Nexedge trunking systems - ones associated with a continuous control channel - and although the raw signal sounds like standard NXDN4800, DSD can't touch it at all. I also believe that based upon lots of posts that I've read that it isn't even possible to listen into a trunked NXDN system with a Nexedge radio unless you have access to the system key file. I haven't come across an IDAS trunking system yet.

I can confirm DSD works well against Conventional [Kenwood] NXDN9600 and Conventional NX4800 (both Kenwood and iDAS flavours). For the Kenwoods, I've tested it works ok both simplex and repeater, for IDAS only simplex has been tested (so no idea if DSD can decode a repeated iDAS signal but I fully expect it would be ok).

In my experience, of all the great things that DSD does, it performs worst of all on MotoTRBO simplex.

HTH,

Jim

 

[Mike_G_D]

iDAS is the LTR-like variant with the burst type data channel every 5-10 sec. NEXEDGE is the continuous control channel version. One reason that made me believe both versions were pulling from the same pool of data packets from the standard was because if you listen closely, the iDAS data bursts sound identical to the NEXEDGE control channel (just a short 1 second's worth).

The standard explains that there are both continuous and "composite" control channels, the latter being a mix of control data and voice. The RCCH (RF Control Channel) uses a frame type called FACCH (Fast Associated Control Channel) messages on composite control channels. I'd be willing to bet that iDAS is simply the "composite" case in the standard, while NEXEDGE is the continuous case.

That could be - two trunking protocols called out in the standard. Maybe since the two have been on the market and in the field for awhile it simply made sense to make them part of the public "standard".

In any case, I'm pretty sure that DSD was written for unencrypted voice channel decoding only and was never intended to handle any sort of trunking control data, "composite" or "continuous". As far as I know, the actual voice data portions of the total data stream as transmitted on a voice channel are the same in either trunking format as well as in conventional repeated systems. Non-repeated, direct, simplex mode, however, for some reason, has presented a problem at least in MotoTrbo formats, I seem to recall from way back when DSD was first being developed. If I am recalling this correctly, it may be due to the TDMA multiple access scheme being used in MotoTrbo and all DMR variants. In the current systems, going to simplex direct mode defeats the TDMA two channel slot operation and reverts to standard FDMA single channel across a full 12.5KHz bandwidth. I can understand this from having worked on TDMA systems in the past as you really need an accurate stable central timebase signal from the base/repeater/controller to allow the subscriber units to synch correctly and differentiate between channel time slots. When we take that away, which would happen in simplex off-network direct mode, you would no longer have that stable sync signal. The only way you could go back to multi-slot mode channel-wise would be to dedicate one of the subscriber units to take over as a master time base signal for all of the other units participating in the conversation so that everyone gets sync'ed correctly. Of course, this seems superfluous since most simplex operation probably only really needs to be performed between very limited numbers of users, as little as two, even, so the need to split extra voice channels in occasional simplex operation is of limited value anyway. In any case, MotoTrbo, currently, simply reverts to one voice slot per radio frequency as in any FDMA-only system when in direct off-network simplex mode. I imagine that this significantly affects how the voice timing slot data is parsed in the transmitted data stream such that, it makes receiving them via non-affiliated independently developed decoding programs such as DSD, potentially problematic.

Since NXDN is solely FDMA based the above may not be a problem - at least in the same sense. The problem I see with NXDN reception in either infrastructure on-network (conventional repeater or either trunked variation) or in simplex off-network mode is that the system uses very narrow 6.25KHz bandwidth channels for each radio channel. If the system's channels are separated by 25KHz or more then it may be sufficiently receivable by most consumer class receivers but when the system actually has voice and control channels separated by as little as 6.25KHz there will be problems as most consumer grade receivers lack such narrow IF selectivity and a sufficiently accurate and stable (not to mention low noise) local oscillator, and I'm not sure post processing software filters can adequately filter such signals when adjacent channels are simultaneously occupied. I didn't used to think such scenarios were likely until I read some posts on here some time ago wherein someone posted that he was trying to listen to such a system with tightly packed 6.25KHz channels being simultaneously used including full time control channel and adjacent 6.25KHz voice channel! I think it was in England, as I recall. I was surprised but I think someone else chimed in and claimed that, yes, indeed, the NXDN equipment is designed to operate within 6.25KHz channels in the presence of strong adjacent channel activity within the same on-site system! That leads me to believe that the subscriber and infrastructure radios have two big things that consumer grade equipment typically lack - very tight and selective IF filters and very stable and precise local oscillators. If this type of operation proves to be widespread (the use of multiple tightly packed 6.25KHz channels simultaneously on-site) then this will prove to be very problematic for reception using typical consumer grade scanning equipment and programs like DSD. Advanced forms of high end SDR equipment will likely be required. Of course, on systems that have spread out voice and control channels and/or in low RF density areas this won't be as much of a problem (theoretically).

-Mike

 

[inigo88]

So just to confirm, in my experience DSD does NOT decode any form of NXDN Trunking.

That's what I thought. Glad to see I'm not crazy.

Clearly there's something in an NXDN trunked frame that's different enough to cause DSD not to recognize it. This thread is an open invitation to RR's best and brightest in digital voice decoding (Ian Wraith, Unitrunker, Slicerwizard, Eric Cottrell, and the rest) to help figure out what that is, if any of you are interested in the challenge.

Now that the standard is freely available, I'll try to continue reading and see if I can spot any obvious differences, but I would love to get to the bottom of this.

the system uses very narrow 6.25KHz bandwidth channels for each radio channel. If the system's channels are separated by 25KHz or more then it may be sufficiently receivable by most consumer class receivers but when the system actually has voice and control channels separated by as little as 6.25KHz there will be problems as most consumer grade receivers lack such narrow IF selectivity and a sufficiently accurate and stable (not to mention low noise) local oscillator, and I'm not sure post processing software filters can adequately filter such signals when adjacent channels are simultaneously occupied.

Your point is a good one, but it relies on the assumption that the immediately adjacent channels +/- 6.25 KHz from the center frequency are occupied ALL the time. In most cases this won't be true, considering that in the U.S. NXDN trunking is mainly limited to private SMR systems with variable levels of traffic. Scanners as old as the GRE PSR-500 can tune in 6.25 KHz channel steps. If the system turns out to be packed as closely as you describe, the end user is always welcome to go purchase a $5000 AOR receiver if they wish to have flawless operation on one. But I don't think we should let one hypothetical system configuration prevent us from pursuing a universal solution to this issue.

 

[Mike_G_D]

Count me in as very interested in this too! I'm with inigo88 in wanting those software brains to look into this - I've found a couple of, I think, Nexedge trunking systems in my area and have had no luck with them but then, I don't know the associated voice channels so I can't say one way or the other if DSD could work on them. Based on what jhampton2000 said it doesn't look like I could in any case.

I would really like to see some form of Nexedge (and iDAS) trunking analysis tools similar to DMRdecode and/or Unitrunker. That would be a great first step - just analysis and info decoding no voice.

I imagine that the framing of the voice data on the trunked voice channels must be significantly different somehow from that of the conventional stuff based on what jhampton200o said. Oddly, I didn't get his post until quite late.

inigo88 - yes, I agree that it might not seem likely that two adjacent channels with co-located transmitters in a system would be simultaneously occupied but, at least according to one poster on here some time ago, such very busy systems do exist - at least somewhere in the world if not in the US. Also, I would be concerned about adjacent channel interference from outside sources as well as in-system sources; step size on scanners does not imply corresponding IF filter BW or oscillator accuracy - all separate design elements that are interrelated but with individual characteristics. Sorry, these are just concerns of mine pertaining to effective NXDN reception and demodulation - my RF background tends to make me a bit overattentive to such things, I know. I certainly didn't mean to imply that work on NXDN demodulation, trunked and conventional, is a hopeless cause unless top shelf super expensive gear is used, not by a long shot (geeez no! I'm dirt poor myself anyway and would love to keep experimenting with the junk I am using - old tapped pro2052!). I just can't help dotting "t"'s and crossing "i"'s as it were. What's fascinating to me is that the equipment is apparently actually designed to perform in such tightly packed dense RF environments with co-located adjacent channel signals at such narrow channel spacings - if the systems are really designed to handle such environments routinely then the system deployment folks will have no compunction about setting them up as such so we, as hobbyist listeners/analyzers, should be prepared to deal with and at least be aware of the possible consequences.

Anyway, I am very interested in how all of this develops!

-Mike

 

[SCPD]

Clearly there's something in an NXDN trunked frame that's different enough to cause DSD not to recognize it.

Just a guess. It's probably the sync bits. NXDN uses different synchronization bit patterns for mobile vs. base. I don't have the code in front of me (and too lazy to look).

 

[inigo88]

Just a guess. It's probably the sync bits. NXDN uses different synchronization bit patterns for mobile vs. base. I don't have the code in front of me (and too lazy to look).

I may not know how to write a Phase-Locked Loop algorithm in C yet, but I can certainly help in that regard. I'll dig around the PDFs of the standard and see if I can find anything on the sync bits.

 

[inigo88]

Take a look at NXDN-TS-1-A ver 1.3 "Common Air Interface."

First a couple quick NXDN defintions (will make the document way easier to read):

VCH - Voice Channel
RCCH - RF Control Channel (trunked)
RTCH - RF Traffic Channel (trunked)
RDCH - RF Direct Traffic Channel (conventional)
SU - Subscriber Unit
TC - Trunking Controller
FSW - Frame Sync Word
LICH - Link Information Channel

There are three layers of NXDN data, with layer 1 being the simplest (broad message categories) and layer 3 being the most complicated (specific packet message types).

Voice coding method is outlined on page 164 (PDF page 177). AMBE +2 using either EHR (3600 bps) or EFR (7200 bps). Example test bit patterns are provided in the document.

Frame Synchronization is on page 53 (PDF page 64), section 5.3:

Direct Mode Operation (DMO)(5.3.1.3):

Initial frame sync can be established by the SU if the Frame Sync Word (FSW) is received N5 times continuously. Can also be established if the FSW is detected along with the last 9 symbols of the pre-amble, then if it's received N6 times continuously.

Conventional System (Repeated)(5.3.1.2):

Same as above.

Trunking System (Capturing RCCH - the control channel)(5.3.1.1.1):

Initial frame sync is achieved when an FSW is received N1 times continuously. Something called superframe sync can then be established if the number of frames in the superframe is determined from decoding the BCCH (Broadcast control ch type layer 3 message carried on the RCCH frequency).

Trunking System (Capturing RTCH - the voice channel)(5.3.1.1.2):

Here's where it gets weird... Since the RTCH (voice channel) is only activated when an SU is sent there by the RCCH (control channel), the SU can establish initial sync after receiving an FSW N2 times continuously "under retaining the acquired frame synchronization timing on (the) RCCH."

Diagrams of this synchronized control ch vs. traffic ch frame timing are provided in Figure 5.5-1 (4800 bps) (PDF page 70) and Figure 5.5-2 (9600 bps) (PDF page 71).

Frame Format (4.4): (PDF page 37)

Each frame is 384 bits total.

An RCCH (control channel) outbound frame is 384 bits broken up as follows:

FSW (20) | LICH (16) | CAC: can be BCCH/CCCH/UPCH (300) | E (collision control) (24) | Post (24)

An RTCH (trunked voice traffic channel) is also 384 bits and is broken up depending on NXDN 4800 or NXDN 9600 (see PDF page 38):

FSW (20) | LICH (16) | SACCH (60) | then two frames of FACCH1 (144) interleaved with either four 72 bit VCH frames (NXDN 4800) or two 144 bit VCH frames (NXDN 9600)

An RDCH (Convenctional direct traffic channel) is apparently the same as the trunked traffic frame, only there is a Preamble field (of 24 bits or more).

Preamble is defined in 4.4.3, and is 24 bits long.

In terms of 4-level FSK symbols: (First 3) +3,+3,+3, (Last 9) -3,+3,-3,+3,+3,-3,-3,-3,+3.
This translates to HEX: 5775FD
There's also an arbitrarily longer preamble that can consist of +3,+3,-3,-3 symbols.

Frame Sync Word (FSW) is defined in 4.4.4 and is 20 bits long:

Symbols: -3,+1,-3,+3,-3,-3,+3,+3,-1,+3
HEX: CDF59

Post Field is defined in 4.4.5 and is 24 bits long:

Symbols: (First 3) +3,+3,+3, (Last 9) -3,+3,-3,+3,+3,-3,-3,-3,+3
The last 9 can be used in addition to the FSW to establish initial frame sync.

After section 4.4.5 it goes on to describe CRC and error correction methods for each frame.

The bit to symbol mapping for the Nyquist 4-level FSK is:

Bit Symbol
01 +3
00 +1
10 -1
11 -3

How's that Rick?
Do you guys think that the issue could be as simple as DSD looking for the 24 bit-Preamble field (5775FD) in trunked frames where none is present?

 

[brandon]

+1 on the Nexedge trunking decoding. Lots of systems here in SoCal just waiting to be analyzed

 

[SCPD]

I may not know how to write a Phase-Locked Loop algorithm in C yet

In DSD, there is a variable called "jitter". The code manipulating that variable is the PLL. The signed value represents time phase - early (negative), late (positive), or on time (zero).

 

[inigo88]

In DSD, there is a variable called "jitter". The code manipulating that variable is the PLL. The signed value represents time phase - early (negative), late (positive), or on time (zero).

This stuff is starting to make sense. Thank you!

+1 on the Nexedge trunking decoding. Lots of systems here in SoCal just waiting to be analyzed.

Agreed!

 

[nbarco]

It sounds like this is where all the gurus are...is it possible that any of you can add these algorithms and code to the PSR-800 firmware. And release a "jailbreak" type firmware that incorporated these standards. Once a scanner hits the market that can decode these standards then the increasing popularity of these standards will be undermined. And even though it would be illegal for a company to release encryption workarounds, it would not be illegal for decrypting programs to be made to confirm encryption's success. It is illegal to copy cd's and dvd's to sell but it is not illegal to bypass copyright measures to back-up our movies and music. Same loophole...

 

[klown]

Does anyone think that given the information the OP provided, there will be a break through by the dsd developers?

 

[inigo88]

...is it possible that any of you can add these algorithms and code to the PSR-800 firmware. And release a "jailbreak" type firmware that incorporated these standards.

Short answer: No. I'm not aware of anyone that does scanner firmware programming. Your best bet is to lobby GRE to do it, although last I checked it sounded like their company's future was uncertain.

Does anyone think that given the information the OP provided, there will be a break through by the dsd developers?

With DSD having been split a bunch of directions by a bunch of different independent developers, I'm hoping dsdauthor's return will re-combine a lot of those efforts into a new version. One of those will almost certainly be support for NXDN trunked, because I think the problem has been noticed by enough people.