DSDPlus

[br0adband]

Is that a new laptop, like somewhat recent (maybe less than 3 years old)? If so your mic jack could also double as a proper line-in jack as well depending on the drivers/software for that specific sound chip. On my Dell Latitude E6400, the onboard audio chip is one that's technically not made by Intel but they bought the company that produced the chips (IDT) and in the software controls for mine if I plug something into that "mic" jack it will ask me if I plugged in a mic or is it a line-in signal - it can auto-switch as well if I disable the prompt to ask me which is which, something I find pretty cool actually.

I don't have anything that uses a line-level output presently, I'm hoping to track down an older more simple scanner like a BC-350 or whatever so I can finally get a proper discriminator tap going once again for whenever I have need of such a thing. It's nice to know that when I do this laptop of mine will automagically detect and handle the line-in signal without me having to muss or fuss about it.

I'd say check whether or not your laptop's audio circuit offers that capability as well - I know all the IDT ones do, some Realtek ones, the older Sigma ones did in some instances, and so on. Can't hurt, and it sure would be a lot cleaner than having to use the mic-level side of things and getting those audio levels just right.

Here's what mine looks like...

 

[Jay911]

TG 1231 x 16 = 19696 <-- what you're really looking for TG 19696 isn't listed in SNACC, but 19696 is the actual talkgroup that most scanners / listeners on here would make sense of.

Mike

Actually unless I am looking at the wrong thing, SNACC is a "real" P25 system (or at least P25-X2) and so the talkgroup ID displayed is the real ID.

The above calculation is only used on Motorola Type II systems. For some reason, scanners have always shown Type II talkgroup IDs as shown above (the actual TG multiplied by 16). The RRDB stores Type II talkgroups in this fashion as well.

 

[br0adband]

Actually unless I am looking at the wrong thing, SNACC is a "real" P25 system (or at least P25-X2) and so the talkgroup ID displayed is the real ID.

The above calculation is only used on Motorola Type II systems. For some reason, scanners have always shown Type II talkgroup IDs as shown above (the actual TG multiplied by 16). The RRDB stores Type II talkgroups in this fashion as well.

Well this S.N.A.C.C. system here is getting even more complex than it was in the past:

It started off as a Smartnet system originally (as I understand it), then went through all the possible revisions or upgrades of that to whatever it is now in terms of the technical classification, and they've added P25 Phase I and X2-TDMA support in the interim for testing while Phase II is finally standardized which upon that happening they'll start moving towards. The thing is that the P25 control channels are different (but still part of the whole system, apparently) and the P25 traffic that I've been able to snatch here and there seems to happen on just one or two frequencies specifically (I'm guessing because there's different control channel frequencies/repeaters for that traffic).

It's just one big huge mess in terms of staring at it (at least to me) but it all seems to be working just fine, unfortunately for me after all these years of putting off dealing with digital modes monitoring now that I'm actually into it there's almost nothing with respect for P25 for me to actually listen in on.

That will change, of course, since they are underway with the Phase II changeover whenever those standards finally get put in place.

I may be going from never having messed around with P25 at all to being able to listen in now only to find they're moving to P25 Phase II which I may not be able to monitor at all unless DSD or DSD+ gain that ability at some point, and I'm sure they will - again - once that Phase II standard is finally locked down.

So even though that 1231 is the proper P25 TGID, to be used with the current overall S.N.A.C.C. (which it seems to be since the frequencies I've been picking up the P25 traffic on - just two of them so far of the ones assigned for that traffic) I suppose it is being worked out to get the proper Type II TGID for interoperability.

Fun fun fun...

EDIT:
Looks like they now just refer to it as College of Southern Nevada or CSN and not the CCSN from years past, who knows. TGID 19632 is their Police Dispatch and obviously the TG that I've been noting the few transmissions with.

 

[RonnieUSA]

Is that a new laptop, like somewhat recent (maybe less than 3 years old)? If so your mic jack could also double as a proper line-in jack as well depending on the drivers/software for that specific sound chip. On my Dell Latitude E6400, the onboard audio chip is one that's technically not made by Intel but they bought the company that produced the chips (IDT) and in the software controls for mine if I plug something into that "mic" jack it will ask me if I plugged in a mic or is it a line-in signal - it can auto-switch as well if I disable the prompt to ask me which is which, something I find pretty cool actually.

I don't have anything that uses a line-level output presently, I'm hoping to track down an older more simple scanner like a BC-350 or whatever so I can finally get a proper discriminator tap going once again for whenever I have need of such a thing. It's nice to know that when I do this laptop of mine will automagically detect and handle the line-in signal without me having to muss or fuss about it.

I'd say check whether or not your laptop's audio circuit offers that capability as well - I know all the IDT ones do, some Realtek ones, the older Sigma ones did in some instances, and so on. Can't hurt, and it sure would be a lot cleaner than having to use the mic-level side of things and getting those audio levels just right.

Here's what mine looks like...

Just updated my sound drivers, and it sounds so much better.

 

[br0adband]

Just updated my sound drivers, and it sounds so much better.

But but but... you should still check to see if - and this is another if: if the sound card offers some kind of control panel for the chip - there's the option to alter the input from mic-level to line-level which would work better. It may have done that automagically for you (detecting it as a line-level input) and now that's how it's functioning, but it doesn't hurt to check/verify that and if for some reason it's capable of but not switching over to treating the jack as a line-level input, setting it that way manually could improve things even more.

 

[frazpo]

Just curious to ask if anyone can provide a link for the DSD+ software???

Tnx in advance

https://mega.co.nz/#!dxBEES5T!URN1d1aqbIX8wCqHCKpCuiI0J-VB7GaF9oP_42vUHaE

 

[Jay911]

Has anybody looked into why NXDN trunked isn't received by regular DSD? Is it just a missing sync pattern, or are there significant protocol changes?

Reference: http://forums.radioreference.com/digital-voice-formats/231192-nxdn-idas-frame-sync-data-needed.html

I found the NXDN syncs and posted them in that thread a few months ago, are you finding those sync patterns are not working, I didn't release a new windows DSD with the sync patterns you need to compile them in yourself in linux, if there is enough interest I could release another version with them in.

Are you guys talking about the actual control channel data, or voice calls on a NXDN system? Because I successfully decoded NXDN96 voice calls (on a couple of different trunked systems) today. I didn't get RAN or radio ID or anything else, but the voice was decoded quite clearly.

 

[RonnieUSA]

But but but... you should still check to see if - and this is another if: if the sound card offers some kind of control panel for the chip - there's the option to alter the input from mic-level to line-level which would work better. It may have done that automagically for you (detecting it as a line-level input) and now that's how it's functioning, but it doesn't hurt to check/verify that and if for some reason it's capable of but not switching over to treating the jack as a line-level input, setting it that way manually could improve things even more.

I looked, and don't see that in the settings, but it sure sounds a lot better after the driver update.
It had Microsoft drivers to start with, and when I installed the Realtek drivers it fixed the really bad decode, sounds just as good as my scanner for P25.
There are 2 local NXDN 4800 systems here, and a NXDN 9600 system in a different county, and the are also very clear.

 

[br0adband]

I looked, and don't see that in the settings, but it sure sounds a lot better after the driver update.
It had Microsoft drivers to start with, and when I installed the Realtek drivers it fixed the really bad decode, sounds just as good as my scanner for P25.
There are 2 local NXDN 4800 systems here, and a NXDN 9600 system in a different county, and the are also very clear.

Excellent, then it probably is now handling that as a proper line-in by switching to that aspect. You can look in Control Panel - Hardware and Sound - and you should find a Realtek HD Audio Manager or something in their that is Realtek audio related; that's where you'd check to know for certain as to how things are set up.

You should also be able to unplug the input and then plug it back in for a test - if it's working properly (and it seems like it is now) the audio manager may just appear (if it's not already showing up as an icon in your System Tray by the clock, that's the other way to access it) and you can go from there. The default Microsoft drivers are there strictly to provide you with audio and nothing else, no special aspects of the audio hardware, etc - the actual Realtek set includes the audio manager to make full use of the hardware's capabilities.

Or, since it's apparently working better, you could just leave it alone I suppose.

 

[RonnieUSA]

Excellent, then it probably is now handling that as a proper line-in by switching to that aspect. You can look in Control Panel - Hardware and Sound - and you should find a Realtek HD Audio Manager or something in their that is Realtek audio related; that's where you'd check to know for certain as to how things are set up.

You should also be able to unplug the input and then plug it back in for a test - if it's working properly (and it seems like it is now) the audio manager may just appear (if it's not already showing up as an icon in your System Tray by the clock, that's the other way to access it) and you can go from there. The default Microsoft drivers are there strictly to provide you with audio and nothing else, no special aspects of the audio hardware, etc - the actual Realtek set includes the audio manager to make full use of the hardware's capabilities.

Or, since it's apparently working better, you could just leave it alone I suppose.

You were right there was a Realtek Manger. But no advanced settings.

 

[br0adband]

Oh well, at least it's working better. I suspected it would have the ability to alter the function of the mic input jack from mic-in to line-in like mine does. I right-click directly on the mic input "icon" as shown in the picture above that I posted and I get that additional menu to set it as mic-in or line-in - might consider trying that yourself for yours, it could be something just a right-click away.

If not then, again, it's doing better now so that's a positive.

 

[airforceflyr]

Experts,

Is anyone using the ICOM R-8500 dis tap ? I am and not having good decode on P-25 or DMR. Choppy and unintelligible snippets using -fa , -f1 and -fr . Here is a raw audio file. Hope I did this correctly :

Zippyshare.com - 155.640 DMR.wav

Using a MacBook air with parallels. I tried previously using an older Sony Vaio laptop. Thinking it was to slow, I switched to the Mac and same result.

Anyone able to help troubleshoot ? Also have a screen grab attch'd. A msg the screen grab failed to see was also a msg at the conclusion of the transmission that reads "Synch: no Synch"


Thanks

 

[mtindor]

Anyone able to help troubleshoot ? Also have a screen grab attch'd. A msg the screen grab failed to see was also a msg at the conclusion of the transmission that reads "Synch: no Synch"


Thanks

Nothing to troubleshoot. Good signal, good decode. The problem is that it is encrypted. I can tell just by listening to the decoded output that it is encrypted.

Mike

 

[br0adband]

I'd agree. The native score is 58,688 there, and after a tuning pass it ended up with about 58,892 or so - barely anything that could be done, a decent solid decode save for the encryption making it all but useless.

 

[airforceflyr]

Thx for the listen fellas .. On DSD+, I thought I read encrypted comms are muted? In this instance, I'm hearing the unintelligible/encrypted comms on the PC speakers in real time . As mentioned in my OP, I'm having the same result - trouble with a known P-25 unencrypted system as well. I'll keep tweeking and throw the P25 audio over to you guys if unsuccessful

Sent from my DROIDX using Tapatalk 2

 

[br0adband]

DSD mutes the P25 encrypted audio unless you feed it the -pu switch on the command line to unmute it (never had much luck with that aspect, not that listening to encrypted comms makes much sense in the first place). DSD+ apparently doesn't mute much of anything which is actually pretty cool I suppose - don't have to record stuff then go back and feed it to a media player or audio editor to figure out what the hell it is/was.

Just one of those things I guess.

<I could be mistaken here but I have been able to hear encrypted P25 decoded in real-time myself with DSD+ - I thought it was just some quirk and I only did it one time because it's difficult to catch on the Nellis AFB P25 system here, but it came blaring out while monitoring...>

 

[mtindor]

Thx for the listen fellas .. On DSD+, I thought I read encrypted comms are muted? In this instance, I'm hearing the unintelligible/encrypted comms on the PC speakers in real time . As mentioned in my OP, I'm having the same result - trouble with a known P-25 unencrypted system as well. I'll keep tweeking and throw the P25 audio over to you guys if unsuccessful

Sent from my DROIDX using Tapatalk 2

P25 encrypted comms are muted. Most other DMR/NXDN encrypted comms are not muted, except for one or two varieties that somebody has mentioned earlier in this thread.

If you're having trouble with P25, please provide a raw audio wav for us to listen to.

Thanks

Mike

 

[Jay911]

Here are a couple of files from a NXDN96 trunk system near me.

Decoded audio
Raw input audio

That's my home machine. If you listen to the raw input it appears that my machine is having a hard time "keeping up". I notice this when I'm running SDR#; everything else on my system slows to a crawl. It's clearly sapping up CPU cycles. And this is a dual-core 3GHz x64 machine...

Looks like I may have to go with a tapped radio if I want to decode anything at home. (Or, move some of my other CPU-intensive applications to another machine.)

 

[mtindor]

Here are a couple of files from a NXDN96 trunk system near me.

Decoded audio
Raw input audio

That's my home machine. If you listen to the raw input it appears that my machine is having a hard time "keeping up". I notice this when I'm running SDR#; everything else on my system slows to a crawl. It's clearly sapping up CPU cycles. And this is a dual-core 3GHz x64 machine...

Looks like I may have to go with a tapped radio if I want to decode anything at home. (Or, move some of my other CPU-intensive applications to another machine.)

Jay,

That is encrypted voice. That's why it sounds like that. Within the past few days, somebody here on the forums had discussed the fact that most protocols do not automute, only P25 and one flavor of NXDN. Apparently this isn't the flavor of NXDN that automutes.

Your input signal is fine.

Mike

 

[Jay911]

Jay,

That is encrypted voice. That's why it sounds like that. Within the past few days, somebody here on the forums had discussed the fact that most protocols do not automute, only P25 and one flavor of NXDN. Apparently this isn't the flavor of NXDN that automutes.

Your input signal is fine.

Mike

Are you certain the input is fine? I had thought it was potentially encrypted (and I did read the earlier posts on that), but the input signal has minute gaps sprinkled throughout compared to a recording done on my laptop (which doesn't show the same CPU-hog slowdowns that my desktop does), which sounds "gapless".

(I recorded the signal while driving to work, using my laptop, but of course nobody was talking then!)