DSDPlus

[mtindor]

Jay,

Sounds fine to me. I'm no expert, but just listening to the input signal tells me that there is decent SNR. Might be fading from time to time [or more like it sounding as if the receiver is being desensed from time to time by another strong local signal], but the decode rate is good and the SNR remains more than needed for good decode even when I hear what sounds like desense. I see no problems.... other than it being encrypted.

If I do a "dsdplus -fN < your_raw_wavfile.wav" , everything looks and sounds good to me. On my Dell Laptop (3rd gen i7 quad core), it uses 3% CPu during decode. Of course, I'm not running a dongle+SDR# either, so I don't have that overhead. Attempts to increase decode with fine tuning do not accomplish much, most likely because the signal is already quite decent and there really isn't much to be improved upon.

Maybe somebody more knowledgeable will check in, but to me it's a simple case of encryption.

Mike

 

[radiodmr4tw]

Have anyone figured out how to transmit decoded voice to another computer - client (like winamp shoutcast)?

 

[Jay911]

Have anyone figured out how to transmit decoded voice to another computer - client (like winamp shoutcast)?

I haven't tried it, but I would think you should be able to do it with any streaming software. IIRC in one of these threads someone said they put up a feed on Broadcastify using DSD+ as a demonstration. You might use Virtual Audio Cable to transport the audio out from DSD+ into the audio in of your streaming software, so you don't get Windows dings and dongs and such in your transmission.

 

[frazpo]

Have anyone figured out how to transmit decoded voice to another computer - client (like winamp shoutcast)?

For what purpose? to mix? What OS? In a linux environment you could use darkice to feed it to a icecast server on the computer wou want the audio. Then it would accessible anywhere.

You mentioned another computer. Did you mean another client like Jay mentioned?

 

[radiodmr4tw]

Yes, to listening on android device or something like that... Windows 7..

 

[frazpo]

Yes, to listening on android device or something like that... Windows 7..

Yes. And Maybe Jay or someone can chime in. Windows used to have a media server but I haven't messed with it in a long time. It seemed to suck up CPU bigtime. I had setup a private feed using the setup I mentioned. The cool thing is you can load the address into 5.0 radio and use the app for your own feed. Basically you need an encoder and a server. I believe Scannercast gives you options on what server to send it to which could be your own.
Its basically this,,
Live Audio/Ubuntu Darkice - The RadioReference Wiki

 

[racingfan360]

>Here are a couple of files from a NXDN96 trunk system near me.
>Decoded audio
>Raw input audio

Jay911, I'm really not sure this is encryption..... on every other type of encrypted system I've heard (P25, NX96, NX48, DMR) the voice always comms through as 'bitty' ie just a randomized sequence of the voice which makes it sound unintelligible. For your sample there is clearly some voice to be heard, and I can pick out a female and at least one male: weird to say this but to me it sounds 'too good' to be encrypted. Try comparing with the samples I updated the other day......with these you can't tell if its male, female, a dog even !!!

I also get a really poor decode score with this......I haven't quite figured if this is a factor of how short the sample is or of its quality.

I also see it's decoding as an Icom IDAS trunk system (NXIDAS voice) - I've never come across one of those before. Anyone know what the MB in the NXIDAS MB VOICE stands for?

My honest guess is that the quality of the sample isn't quite 100% and it sounds bad as a result.......

Jim

 

[Jay911]

Yes. And Maybe Jay or someone can chime in.

Sorry, my only exposure to streaming is doing one feed for Broadcastify, and I do that with the custom ScannerCast software designed to work with RR.

My honest guess is that the quality of the sample isn't quite 100% and it sounds bad as a result.......

With all due respect to mtindor, that's my opinion too. Later raw recordings off my laptop (when, of course, nobody was talking) don't have the stuttering/gaps that the above raw does.

I think my home PC is struggling to run SDR# (and all the other stuff I run - a PlanePlotter operation and an APRS-IS instance being the ones I think draw the most CPU time). I have another option - I have a PSR-800 which I can hook into my antenna multicoupler at home, and feed into the line-in on the PC, bypassing SDR#. The signal off the multicoupler for the above NXDN96 system is awesome, very strong (nearby VHF pretty much pointed right at me). I can't use the PSR-800 on my laptop because the laptop has one of those stupid combo jacks for audio (4-element in/out) and I can't seem to get it to switch to "input" to receive the signal off the PSR-800 - it always wants to be "output", acting like a headphone jack.

 

[AZScanner]

Have anyone figured out how to transmit decoded voice to another computer - client (like winamp shoutcast)?

Yes, I have. My feed currently uses EdCast to pass the audio from DSD+ to RR. It could just as easily be pointed at a local server such as Icecast or Shoutcast and then streamed over my LAN at home. I also have my feed computer configured to allow me to listen to the audio as it is being streamed so I can make adjustments when needed.

The secret is a little program called Virtual Audio Cable or you can try the free alternative VBCable. These programs can act as both an audio input and audio output device, allowing DSD+ to see it as an output device and EdCast to see it as an input device. A google search for either one should get you started.

-AZ

 

[br0adband]

When I just listened to the raw sample Jay911 posted above my first impression - and I mean I loaded the raw sample in MPC-HC, not DSD+ or dsdtune - the fact that it's literally bursting data (data-silence-data-silence-data-silence over and over again like someone was hitting mute every fifth of a second on off on off, etc) gives me the impression that it's just a horrible signal to begin with. Now, I don't have a ton of experience with NXDN, nor 9600 NXDN for that matter (seems everything here in my area is 4800 so far), but the fact that when I did feed the raw sample to DSD+ it was loaded with nothing but errors almost start to finish would again imply it's a terrible signal to start with, that's just my opinion based on the sample itself.

Even so, with a solid signal here for NXDN it never does that on-off-on-off-on-off thing, it's a solid decent signal. If anything I'd say the result that I see of that audio waveform when I look at the sample in Sound Forge would be reminiscent of the FM multipath issue: in older times a few decades ago, in a moving vehicle when listening to an FM radio station, especially in a city environment with lots of buildings, you'd get that classic "on-off-on-off-on-off" type of reception that made you think someone was turning the transmitter on and off and on and off while trying to play music - it was happening because of Doppler shift and several other factors (multiple FM signals reaching the receiver at the same time from reflections, etc).

It's just not a clean signal to begin with so DSD+ is basically going to trip over itself trying to make something from it. All those e: references in DSD+ are errors, it doesn't mean encryption - that raw input sample is horrible to begin with. That's just my own opinion, however.

As for the CPU usage, I'm on a Core 2 Duo laptop at 2.53 GHz here (P8700) and I haven't had any issues using DSD or DSD+ in terms of decodes even with instances of DMR/MOTOTRBO being used with several filters derived from tuning a raw input sample which cause the CPU usage to get a bit higher in processing. I don't think the CPU is what caused that sample to end up that way: I think it's the fact that Jay911 clearly stated he recorded it while driving and it's just a case of potential multipath distortion wrecking the signal during reception.

YMMV...

 

[mtindor]

Good grief. I was listening to the wrong raw input. When I was listening by ear [and stating that i felt the signal was good], I wasn't listening to the NXDN96 wav that Jay sent me. Sorry about that fellows.

Sounds like NXDN96 CC data, but either the transmitter is on the fritz or [if when listening to th CC on a scanner it doesn't break up], then sounds like the computer that it was being fed into was having problems. [isn't that the computer Jay said was running at full CPU?]

I don't think the audio source (tap or whatever) is bad, and I don't think the signal from the site is bad [unless it sounds just like that when listening on a scanner]. I suspect something is happening after it's injected into the computer, due to the CPU maxxing out [assuming that was the instance where Jay was saying it was maxing out].

m

 

[Jay911]

That first one with the stuttering was not done while in motion. That was at a fixed location with the peak of the signal nearly touching the 0dB line in SDR#.

I haven't uploaded the one I recorded while driving; it's on my laptop which doesn't have a network connection while I'm at work. Suffice it to say it's a continuous data signal with only a little static/picketing from the motion, and no gaps multiple times a second.

There's just something about my PC that is making SDR# unable to run smoothly (while DSD+ is using its output), I think.

 

[mtindor]

That first one with the stuttering was not done while in motion. That was at a fixed location with the peak of the signal nearly touching the 0dB line in SDR#.

I haven't uploaded the one I recorded while driving; it's on my laptop which doesn't have a network connection while I'm at work. Suffice it to say it's a continuous data signal with only a little static/picketing from the motion, and no gaps multiple times a second.

There's just something about my PC that is making SDR# unable to run smoothly (while DSD+ is using its output), I think.

Jay,

If your raw audio signal (when listening to it via scanner) sounds anything like this, then the signal from the NXDN repeater is probably good. That's a NXDN96 trunked control channel.

Zippyshare.com - DSDPlus-Raw-Input_2014-01-03@122419.wav
- NXDN96 trunked control channel -- clip taken less than 30 minutes ago

Assuming your laptop records the source audio and it sounds similar to this, then the issue is the desktop at home.

Mike

 

[mtindor]

Jay,

If your raw audio signal (when listening to it via scanner) sounds anything like this, then the signal from the NXDN repeater is probably good. That's a NXDN96 trunked control channel.

Zippyshare.com - DSDPlus-Raw-Input_2014-01-03@122419.wav
- NXDN96 trunked control channel -- clip taken less than 30 minutes ago

Assuming your laptop records the source audio and it sounds similar to this, then the issue is the desktop at home.

Mike

Also, make sure you are on freq. Seems these NXDN96 trunked control channels are often not actually centered on normal boundaries. For instance, the sample above is on 454.03125 (not 454.025 or 454.0375). It's 6.25 kHz offset from the "assigned" frequency. This may be the case in your neck of the woods as well.

Mike

 

[mtindor]

That first one with the stuttering was not done while in motion. That was at a fixed location with the peak of the signal nearly touching the 0dB line in SDR#.

I haven't uploaded the one I recorded while driving; it's on my laptop which doesn't have a network connection while I'm at work. Suffice it to say it's a continuous data signal with only a little static/picketing from the motion, and no gaps multiple times a second.

There's just something about my PC that is making SDR# unable to run smoothly (while DSD+ is using its output), I think.

If you think this only happens when outputing a wav file, try using '-O NUL' top stop it from writing a wav file while its decoding. Of course, it shouldn't write anything unless there is decoded voice.

Mike

 

[Jay911]

If you think this only happens when outputing a wav file, try using '-O NUL' top stop it from writing a wav file while its decoding. Of course, it shouldn't write anything unless there is decoded voice.

Mike

I actually think the culprit is PlanePlotter, or more precisely, the program taking data from the other SDR stick and passing it to PP. I seem to recall RTL1090 (the program in question) having a high CPU usage rate in the past.

I'll try it after shutting the PP/RTL1090 off, tonight. I don't know why I run PP still, anyway - I never see any interesting aircraft in my neck of the woods.

 

[mtindor]

It's just not a clean signal to begin with so DSD+ is basically going to trip over itself trying to make something from it. All those e: references in DSD+ are errors, it doesn't mean encryption - that raw input sample is horrible to begin with. That's just my own opinion, however.

I still standby my claim that the signal itself is likely okay. It might be a little "low", but it decodes just fine. It's an NXDN CC and shows itself as such when passed through DSDPlus. The issue is the chopping / cutting out, and from what Jay says that is not what is happening on the actual raw audio signal [when listened to on a scanner]. I think that somewhere along the line during the process of it coming into the computer and being fed through DSD. If the computer is CPU / IO bound and causing SDR# and/or DSDPlus to falter, then that would make sense.

If I listen to that raw audio, aside from the constant chopping, it sounds just like my good NXDN96 trunked audio source.

Mike

 

[mtindor]

I actually think the culprit is PlanePlotter, or more precisely, the program taking data from the other SDR stick and passing it to PP. I seem to recall RTL1090 (the program in question) having a high CPU usage rate in the past.

I'll try it after shutting the PP/RTL1090 off, tonight. I don't know why I run PP still, anyway - I never see any interesting aircraft in my neck of the woods.

Ok, sounds good. Incidentally, I get a similar feeling about PP/RTL1090 in my neck of the woods. Of course, I've never used an actual antenna designed for that band. I have one of the DPD Productions 1090 ants, but I've always been too lazy to hook it up. my 2m/440 dual bander sucks at the job

Mike

 

[slicerwizard]

Sigh.

Raw audio has obvious holes. VAC/VBC is feeding DSD+ 96 kHz audio continuously. SDR# is not keeping up. Obviously, SDR# isn't getting enough CPU cycles.

Solution? Windows Task Manager. Raise SDR#'s dispatch priority. Done.

 

[AZScanner]

Sigh.

Raw audio has obvious holes. VAC/VBC is feeding DSD+ 96 kHz audio continuously. SDR# is not keeping up. Obviously, SDR# isn't getting enough CPU cycles.

Solution? Windows Task Manager. Raise SDR#'s dispatch priority. Done.

Doesn't SDR# already set it's own priority to realtime by default? I'm not sitting in front of it at the moment, but I'm pretty sure it does. I would check the audio latency within SDR# instead. If you set it too low, you can experience the same issue (cutouts, high CPU usage, etc). Try setting it a bit higher, maybe 125ms instead of 75 or 100. Also it's best to not have the computer doing much if anything else. Running another RTL program on top of SDR# certainly won't help things. My feed machine is an AMD quad core with 4GB of RAM and it's only used for the digital radio feed I host. I run it very lean - it only has the software installed that I need for the feed. The rest is pretty much a pristine, minimal Windows install.

Also, take the time to go out to the manufacturer's website for your motherboard, soundcard, etc and update the drivers. Much of the time the drivers running on any given machine are several months or even years out of date. Or, even worse, they are the generic Microsoft drivers. Using updated, hardware specific drivers will improve performance and let you squeeze a bit more CPU power out of your PC.

Good luck, let us know how you make out.
-AZ