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.
