To DSD+ authors - a quirk

[M105]

I am monitoring both a P25 and a NXDN system. I have 2 control channel dongles and one voice channel dongle.

The control channel dongles are each running a copy of FMP24 and TCP linked to their matching copies of DSD+. One is on port 20003 and the other 20004. The NXDN control channel moves daily and that copy of FMP24 follows it as it should. The P25 channel never moves so all is well and all works except for a quirk.

The quirk: The P25 system is weaker at my location and sometimes loses sync on the control channel. When this happens for more than a few seconds it causes my NXDN CC dongle to tune to the secondary control channel in the P25 system! When that happens of course, the NXDN monitoring is stopped. Somehow when the P25 loses signal it causes the NXDN dongle (which is on another TCP port) to change frequencies. I am assuming it is doing this by writing a file which the NXDN copy of FMP24 is reading.

I can reproduce this bug. With the system running I can remove the antenna from the P25 CC dongle and this action will cause the NXDN CC copy of FMP24 to change frequencies. At which point I lose the NXDN CC.

Just wanted to let you know about this quirk. I have tried everything I can think of to prevent it but have not come up with a way. The copies of FMP24 and DSD+ have to have the -rc parameters and they have to be in the same directory as the VC copy in order for it to read the tuning files they both produce.

If indeed this is a file writing/reading issue then you might want to come up with a method to make the FMP24 CC copy only read the files from the DSD+ CC copy it is associated with when it comes to following the CC channel frequency or do the CC tuning only over the TCP link.

 

[natedawg1604]

I am monitoring both a P25 and a NXDN system. I have 2 control channel dongles and one voice channel dongle.

The control channel dongles are each running a copy of FMP24 and TCP linked to their matching copies of DSD+. One is on port 20003 and the other 20004. The NXDN control channel moves daily and that copy of FMP24 follows it as it should. The P25 channel never moves so all is well and all works except for a quirk.

The quirk: The P25 system is weaker at my location and sometimes loses sync on the control channel. When this happens for more than a few seconds it causes my NXDN CC dongle to tune to the secondary control channel in the P25 system! When that happens of course, the NXDN monitoring is stopped. Somehow when the P25 loses signal it causes the NXDN dongle (which is on another TCP port) to change frequencies. I am assuming it is doing this by writing a file which the NXDN copy of FMP24 is reading.

I can reproduce this bug. With the system running I can remove the antenna from the P25 CC dongle and this action will cause the NXDN CC copy of FMP24 to change frequencies. At which point I lose the NXDN CC.

Just wanted to let you know about this quirk. I have tried everything I can think of to prevent it but have not come up with a way. The copies of FMP24 and DSD+ have to have the -rc parameters and they have to be in the same directory as the VC copy in order for it to read the tuning files they both produce.

If indeed this is a file writing/reading issue then you might want to come up with a method to make the FMP24 CC copy only read the files from the DSD+ CC copy it is associated with when it comes to following the CC channel frequency or do the CC tuning only over the TCP link.

It might help if you post your .bat files or command line startup entries for each instance of FMP24 & DSD+.

 

[M105]

Okay here we go:
P25 FMP24 CC = FMP24 -i3 -o20004 -f771.01875 -b9.5 -P41 -_3 -wsl6.6 -g49.6 -rc
---
P25 DSD+ CC= DSDPlus -F3 -f1 -o2 -i20004 -rc -_10 -e -wsl400.2 -wss100.200 -wel0.1 -wcl160.700 -wes400.520 -OM NUL
---
NXDN FMP24 CC = FMP24 -i2 -f453.53750 -o20003 -b4 -P57.8 -_3 -wsl6.6 -g49.6 -rc
---
NXDN DSD+ CC = DSDPlus -F4 -fn -rc -o2 -i20003 -e -_10 -wsl400.2 -wss100.200 -wel0.1 -wcl240.116 -wes400.520 -OM NUL -dr3 -dh2 -ds70 -dd56 -dv20

 

[slicerwizard]

I don't think you can fix this.

Because you're using one voice dongle, the NXDN and P25 copies of CC DSD+ have to be running in the same folder (the folder where VC FMP24 looks for .traffic files), otherwise VC FMP24 won't see the .traffic files that the two CC copies of DSD+ create.

And that means that if either of those copies of DSD+ lose their control channel signal, they start creating .control files in that folder (I just got some of those by disconnecting the CC antenna - files like P25_BEE00.3C2-1.6_1-1364_770.531250.control are showing up)

Because you have -rc specified on your CC FMP24 command lines, both copies will respond to those .control files. So that's why your NXDN FMP24 jumps around when the P25 CC fades. I would also expect that when the NXDN CC rotates, P25 FMP24 also starts jumping, because it also has -rc on its command line.

You said that the P25 CC doesn't rotate, so you could remove -rc from the P25 copy of FMP24. Then that copy will ignore any .control files. That would keep P25 FMP24 on the control channel and P25 DSD+ would recover its control channel decoding as soon as the fading stopped, rather than when P25 FMP24 got back to the CC frequency.

So during the P25 CC fade, NXDN FMP24 would be tuning to P25 channels (and NXDN channels, because NXDN DSD+ would lose its control channel and also start creating .control files), but as soon as the P25 CC faded, NXDN FMP24 would get directed back to its proper CC frequency.


To stop the interfering actions, you need to run the NXDN and P25 copies of FMP24 and DSD+ in their own folders, but then they both can't steer voice traffic with a single copy of VC FMP24. If you could come up with a way to copy .traffic files from one folder to another, then you could run that way, i.e. run one of the CC FMP24/DSD+ combos in a different folder, and if any .traffic files are created there, copy them to the original folder (where the other CC FMP24/DSD+ and the VC FMP24/DSD+ are running). Something like CopyThem.bat:

:top
copy *.traffic otherFolder'sName
delayFor100ms
goto top

Don't know you'd implement the short delay though.


Or better yet, get the DSD+ folks to send CC steering information over the TCP link if CC FMP24 and CC DSD+ are using a TCP link...

 

[M105]

Thanks Slicer. I had already come to the same conclusions which is why I posted this to the DSD+ authors. They need to associate the CC DSD+ with the CC FMP24 that is feeding it in some unique way either with filename or over TCP.
---
The three dongle setup works fine otherwise. With only one VC I don't get double talk as the VC picks up on the first traffic file no matter which CC creates it. Sort of like a scanner.

 

[Forts]

That's a neat concept... I had never thought of monitoring control channels on 2 different systems and routing both to one VC dongle.

 

[KD8DVR]

That's a neat concept... I had never thought of monitoring control channels on 2 different systems and routing both to one VC dongle.

I do this all the time...using Unitrunker. Easy. Effective.

AntiSquid disclaimer: All information provided is personal opinion only and may or may not resemble actual fact.

 

[slicerwizard]

The three dongle setup works fine otherwise. With only one VC I don't get double talk as the VC picks up on the first traffic file no matter which CC creates it. Sort of like a scanner.

Yeah, I kind of see that here when monitoring a very busy NEXEDGE48 site - there can be a dozen or more .traffic files (because there are a dozen voice calls on the go), but FMP24 ends up on one of the calls and stays there until it ends, unless a higher priority call starts up or I fiddle with priorities.

I do this all the time...using Unitrunker. Easy. Effective.

Yeah, that'll work great on the NXDN system M105 is monitoring.

 

[natedawg1604]

I do this all the time...using Unitrunker. Easy. Effective.

AntiSquid disclaimer: All information provided is personal opinion only and may or may not resemble actual fact.

I didn't realize you could do this with Unitrunker, I just tried it and it worked great. Way cool.

 

[Jphila20]

DSDPlus and Nortons

When I downloand DSDPlus and then extract my Norton deletes files because of a risk. Just getting into SDR's. Have 2 up and running but want to recieve P25.

Any suggestions?

 

[slicerwizard]

Suggestions? Yes - stop using Norton. It's obviously junk.

26,000 downloads (that's the exact number the dsdplus.com site shows right now) of DSD+ 1.101 - if it really had a virus, our antivirus programs would be screaming at us, but they're not.

Why are you using Norton? Did it come installed on your computer? That's a scam...

 

[M105]

When I downloand DSDPlus and then extract my Norton deletes files because of a risk. Just getting into SDR's. Have 2 up and running but want to recieve P25.

Any suggestions?

I suggest you stop posting questions unrelated to topic being discussed under the thread you are currently viewing. If you want help, start a new topic. That said, I will reply this once.

I don't run Norton on any machine I am using for a SDR listening device. The antivirus programs steal CPU cycles and disk access time. I do run Norton on machines that I use to surf the Internet and have for over 20 years without ever catching a virus. Considering I sometimes go to some pretty scary places and have gotten hundreds of "saves" from Norton, I have stuck with it. When Norton removes a download simply click the more information link, restore the program, and tell Norton to remove it from scans. Takes all of 10 seconds. A lot of these SDR programs have no download history with Norton and have not been registered with the company so they generate a "reputation" warning. You can manually scan a file with Norton by right clicking it in Windows Explorer if you like. That will check for known virus patterns in the file but will not clear the "reputation" check. RTL-SDR is currently bleeding edge experimental software and if you want to play in the sandbox be aware that you are going to get some warnings from all the AV programs. If it scares you, dedicate a computer to it or at least read the freaking help file for your AV software. If you can't figure out how to bypass the checks in a consumer AV program, your adventure into command line based SDR software might be very tough!

 

[Jphila20]

Thanks for the feedback! Lost a bunch of stuff when I didn't have Norton before. Still new in this SDR stuff.

Thanks again!

 

[adcockfred]

Jphila20 quite being an adcockfred.
Slicer we are still having that p-25 c c loss too. with fmp-24. I tried putting in -A1on the fmp cc and when I launch I can not even get close to the correct freqs. Any thoughts on this ongoing problem? sysid 1A7 site 3-5