DSD Plus questions

Status
Not open for further replies.

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
2,924
Location
Coconut Creek, FL
I was using DSD 1.6 and it worked great on DMR and P-25, but wouldn't work at all on NXDN. Then I discovered DSD Plus, and it works great on NXDN. I didn't think it would be that much of an improvement, but luckily I was wrong! :D

Anyway, a couple of DSD+ questions:
With regard to DMR decoding, how can you tell what slot is in use? The second column just alternates between displaying "SLOT 1" and "SLOT 2".

And, can I assume that the column displaying "CC=6" refers to the color code?

With regard to NXDN decoding, after the display "NXDN48 TB VOICE" there is a column with things like "e:1", "e:31", "e:36r6r", and others. What do these indicate?

Thanks!
 

br0adband

Member
Joined
Apr 8, 2005
Messages
1,569
Location
Springfield MO
To tell which slot is in use, it's pretty obvious considering DSD+ allows for both channels of the audio transmission to be monitored so it becomes this simple: left audio output is Slot 1 aka Channel 1, right audio output is Slot 2 aka Channel 2 - of course this is dependent on you having your computer's audio system hooked up properly I suppose. :) You wouldn't believe how many times I've worked on people's machines over the years and they have left as right and right as left - no, I suppose for the majority it doesn't matter, but for some of us it does. Hell, it irks me and makes me laugh at the same time when I see people wearing headphones backwards; I may own the same particular pair and when I see someone else with the same, a lot of times they are wearing left as right and right as laugh and I gave up trying to tell people years ago...

Anyway, the "companion" app for DMR/MOTOTRBO monitoring is DMRDecode by IanWraith and it's highly recommended as you can "see" what's going on with those types of transmissions with respect to a lot more data as well as the typical color code info, group calling IDs, when data calls are happening (to whom and from whom, for example as data calls don't have any audible output), etc.

Also, the CC=6 does mean Color Code 6, yes.

With NXDN, I believe it's safe to say that nobody is 100% positive (except maybe the DSD+ author, of course) just what exactly the e:<whatever> actually does mean - and it's not just NXDN because it appears from time to time with DMR/MOTOTRBO transmissions as well. At first I was thinking it was an error reading but then I started thinking maybe it's just some unit identifier, but honestly I myself don't know and I'm not sure anyone else does either - again, save for the author of the program. On one system in particular I see it routinely (the same e:<whatever> code) when security personnel are transmitting so I get the impression it's more of some kind of unit identifier than anything else - for several minutes I've monitored calls going out and the e: code stays the same without variation so that kinda tells me it's not just some error in the bit or datastream happening, it's there on purpose for those particular units. At least that's my guess.

Hopefully if we ever do see a revision of DSD+ to add new features (and I say that 'cause I've been using it for weeks now and it still hasn't crashed or caused me any problems whatsoever) there may be some more extensive documentation about "every little thing" we see with respect to the individual modes and protocols when they're being decoded.

All in all DSD+ has really made a huge leap for digital mode/protocol decoding these days, it's a pretty damned awesome piece of code.

Now here's a question for you:

When you monitor something with NXDN traffic, are the broadcasts happening specifically on the frequency they're assigned by the FCC (assuming you've done a lookup of the frequency to find out what agency or business happens to be using it, that is ? I swear it seems like every single NXDN user here in my area is using some offset of their actual assigned frequencies and it's really starting to get on my nerves when it happens.

I made a post about it in the DSD+ thread a few weeks ago and nobody else responded so, I figure I'm all alone or whatever as NXDN doesn't seem to have that much usage overall compared to P25 (the overwhelming favorite) and then DMR (used around the world as well as with Ham operators) and of course MOTOTRBO (Motorola's own particular offshoot of DMR that's still pretty much compatible across the board).

I haven't found an NXDN system here in my area yet that is actually broadcasting on-frequency per FCC assignments; every one of them is shifted either + or - 3.125 MHz... very strange indeed. ;)
 
Last edited:

W4KRR

Member
Premium Subscriber
Joined
Apr 1, 2001
Messages
2,924
Location
Coconut Creek, FL
Thanks for the reply. I have only just started to fool around with this program; so far it's working pretty good. I use a scanner with a discriminator tap as the audio feed; I had tried using a USB dongle and SDR sharp as the feed, but for some reason I couldn't get it to decode anything, whereas the scanner works great.

As far as NXDN, yes, they appear to be using their assigned frequencies. The UHF T-band is heavily populated by NXDN here. A friend is in the two way radio business, and NXDN networked systems are expanding here in south Florida, it seems to be surpassing TRBO for use by businesses.
 

br0adband

Member
Joined
Apr 8, 2005
Messages
1,569
Location
Springfield MO
With SDR# the issue becomes getting the audio system working properly with respect to using DSD+ - that means when you intend to decode DMR/MOTOTRBO/NXDN/P25 traffic you have to stop SDR# and alter the output from the default of the computer's speakers to something else. Sometimes people can get away with using just the recording mixer in Windows; I myself never had much success with that route before but I haven't really delved into trying to do it that way at all in the first place.

I immediately set out to use VB-Audio Cable (which is donationware; it's not to be confused with Virtual Audio Cable which is a purely commercial piece of software and vastly more expensive but it can do a lot more as well) and never had issues with it from the moment I installed it for use with DSD+. In fact, DSD+ picked it up immediately the first time I ran it, detected it was the input (with speakers for output so I can here the decoded audio) and voila, been using it ever since without a single gripe or issue so far.

But, of course I don't have a tapped scanner presently either. ;) I'm using two RTL sticks, basically one at a time presently - there's on reason for me to use both at the moment, and when I do use both it's with Unitrunker and I'm having some issues with the audio quality there but that's already being discussed in another thread anyway (Unitrunker's latest preview builds can decode analog trunking systems all by itself, no need for SDR# or anything else if you're only using RTL sticks like I am).

I'm hoping to acquire another physical scanner here sometime soon, I search craigslist almost daily hoping to find something I can find here in my area that someone is offloading dirt cheap but so far it hasn't happened. I used Unitrunker (the old retro "DOS" version) many years ago and it worked great, still does for the most part but I don't have that tapped scanner any longer.

Oh well, what matters is DSD+ is working for you, right? :)

DMR/MOTOTRBO is very heavy here in the Las Vegas area now, and only two NXDN systems that I've found so far, might be three but I can't find anything on the third one I happened upon a few weeks back - think it might just have been an image broadcast I picked up from something I already know about.

I'm hoping if a revision of DSD+ comes along it might offer more info about NXDN instead of the very basic info we get (I use -v4 always when running DSD+ so I can see all the potential info it offers).
 

jhampton2000

Member
Joined
Dec 19, 2005
Messages
765
>When you monitor something with NXDN traffic, are the broadcasts happening specifically on the frequency they're assigned by the FCC (assuming you've done a lookup of the frequency to find out what agency or business happens to be using it, that is ? I swear it seems like every single NXDN user here in my area is using some offset of their actual assigned frequencies and it's really starting to get on my nerves when it happens.

br0adband....so I think I replied on that thread or at least one of the threads, when I raised the issue of NXDN offsets by 3.25khz: for me the reason why they do this is simple: there's not a lot of spectrum about, and Kenwood suppliers are competing against Motorola TRBO who will always say their solution is more efficient/cost effective cause they can squeeze two channels into one 12.5kHz assigned frequency using TDMA. For Kenwood to compete/make the most effective use of "their spectrum" using Nexedge they need to squeeze two 6.25kHz channels into one 12.5Khz allocation: they do this by offsetting by +/-3.25kHz from the published FCC (center) freq.

>e:<whatever>
So I don't know precisely what it means either but my experience says its error messages. If i decode a really really strong signal it shows practically no e: messages. The converse is true for weak signals. In addition, with a strong signal, if I offset the rx freq on my scanner by a little bit, I still get good decodes, but I get lots of e: messages. Flick moit back to the right rx freq and bingo no e: messages. Since I know the content of the transmission contains no more or more less RAN/GID/UID data than if it were set correctly on the rx freq, I can only conclude its signifying errors.

>I'm hoping if a revision of DSD+ comes along it might offer more info about NXDN
+1 I'm hoping for that too !

Jim
 

br0adband

Member
Joined
Apr 8, 2005
Messages
1,569
Location
Springfield MO
Well, here's the funny thing, as quoted from some Kenwood marketing material about NXDN:

"NXDN® equipment will program on any channel center or offset (2.5,
3.125, 5, 6.25, 7.5 kHz PLL channel steps) providing more potential to
find frequencies which is important where narrower channel migration
is being forced or there is a need to maximize use of geographical
licenses and use split-channels where permitted"
So go figure - it's not just 3.125 kHz offsets, it can be any of them as an offset. And as luck would have it, I found another system last night - Nevada Ready Mix - which is still listed in the RRDB as using a Motorola Smartnet Type II system and they've apparently moved on now to NXDN. Found it completely by acccident, in the 800 MHz range, wasn't even looking for it and kept seeing the waterfall and thinking "That's NXDN traffic... where did that come from?" :)

And they are using a negative 6.25 kHz offset - their control channel is licensed at 855.1125 and it's transmitting on 855.10625 so there goes the idea that all of the NXDN offset systems will/would use 3.125 kHz, that's just one of the potential options.

So now that I know this and found that snippet in the Kenwood brochure last night, I can go back and make more sense of the other 2-3 systems I've located here in my area. Kinda weird in some respects since most everyone else reporting their experience with NXDN traffic all say they're getting the traffic on the assigned licensed frequencies and yet none of the ones around here are "dead on" like one might expect.

NXDN is one damned strange beast, for sure...
 

EricCottrell

Member
Database Admin
Joined
Nov 8, 2002
Messages
2,293
Location
Boston, Ma
Well, here's the funny thing, as quoted from some Kenwood marketing material about NXDN:



So go figure - it's not just 3.125 kHz offsets, it can be any of them as an offset. And as luck would have it, I found another system last night - Nevada Ready Mix - which is still listed in the RRDB as using a Motorola Smartnet Type II system and they've apparently moved on now to NXDN. Found it completely by acccident, in the 800 MHz range, wasn't even looking for it and kept seeing the waterfall and thinking "That's NXDN traffic... where did that come from?" :)

And they are using a negative 6.25 kHz offset - their control channel is licensed at 855.1125 and it's transmitting on 855.10625 so there goes the idea that all of the NXDN offset systems will/would use 3.125 kHz, that's just one of the potential options.

So now that I know this and found that snippet in the Kenwood brochure last night, I can go back and make more sense of the other 2-3 systems I've located here in my area. Kinda weird in some respects since most everyone else reporting their experience with NXDN traffic all say they're getting the traffic on the assigned licensed frequencies and yet none of the ones around here are "dead on" like one might expect.

NXDN is one damned strange beast, for sure...
Hello,

The step used is usually a submultiple of the band's channel stepping. The 2.5, 5, 7.5 KHz steps cover the steppings used on VHF. The 3.125 and 6.25 KHz steps cover UHF and above.

This is also done on some of the auctioned frequencies regardless of mode. If the auction winner gets a 25 KHz wide chunk of spectrum, it can be used as two 12.5 KHz wide channels by offsetting -6.25 KHz and +6.25 KHz from center. If it is 6.25KHz wide Nxdn, then it could be 4 channels (-9.375 KHz, -3.125 KHz, +3.125 KHz, and +9.375 KHz offset from center).

This can also be done for a 12.5 KHz wide allocation. It is split into two 6.25 KHz wide NXDN channels by offsetting -3.125 KHz and +3.125 KHz from the center of the allocation.

73 Eric
 

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
933
Location
Vista, CA
To add to what has already been said about NXDN channel spacing - keep in mind that most consumer scanners have pretty wide IF bandwidths and may not have very tight tolerances for their local oscillators meaning that a difference of less than 10KHz or so can many times be largely unnoticeable. I know little about the dongles, however, except that they can be calibrated during use using the software to compensate and the software provides variable filter widths so they may be, once accurately calibrated, more accurate than using an old wide IF bandwidth consumer scanner with a sloppy LO. This may be why some folks don't see any offsets for a system but others might using more accurate and tighter IF based receivers.

Many many hobbyists just don't understand how their receivers work in this regard and just seem to assume that just because the receiver can be tuned to any frequency including the newer 2.5KHz and 6.125 KHz splits that that receiver is automatically dead on accurate and the filter is "automagically" set to narrow mode - it just ain't so; the display can say anything it wants but that doesn't mean the inside workings are really set right.

-Mike
 

Thunderknight

Member
Premium Subscriber
Joined
Jan 31, 2008
Messages
1,836
Location
Bletchley Park
Kinda weird in some respects since most everyone else reporting their experience with NXDN traffic all say they're getting the traffic on the assigned licensed frequencies and yet none of the ones around here are "dead on" like one might expect.
...
Maybe all your local systems were installed by the same dealer...
 
Status
Not open for further replies.
Top