DSD FME

[scanfan03]

I may just wait until my new antennas come in that will perform better on UHF. Right now I'm using the only SMA antenna I have which is for wifi stuck to the top of my window. That will probably make a huge difference.

I may try to pick up the p25 county system just to get the hang of the program which should do better since it's 7/8 with the antenna I have.

Once again thank you!

 

[lwvmobile]

I'm not quite sure what's going on, but I can see what is missing. You should have a frequency listing next to your control channel information when its available, and if it isn't available, then that means that it can't poll RIGCTL during the SRV_INFO packet to determine what the current control channel frequency is. Not sure if this is an issue with SDR# or that Gpredict plugin, but that's why its not tuning those calls, the return on the poll is negative, so Gpredict might not be working. When you stop and restart DSD-FME, does it show the gpredict disconnect and reconnect, or does the connection remain. Wondering if something else is connected instead, but I don't think that's the case for some reason. Could be some odd issue between SDR# and Gpredict still.

Just as a basis for comparison, any chance you could setup and run with SDR++ instead, should give me an idea whether or not the issue is with DSD-FME and not SDR#/Gpredict. Also, just as a side thing to try, try the latest AW build found here:

Release DSD-FME V2.1b-final (20230915) + AW (20240405) · lwvmobile/dsd-fme

This is the precompiled Windows version of the base release of v2.1b-final branch from 20230915, and the updated audio_work branch as of 20240405. Extract, and copy and paste the aw patched .exe fi...

github.com

Just download the patch zip, copy and paste it into the dsd-fme folder with the other exe files, and then reference the proper one you want to use in your bat file.


This is what you should be seeing, but aren't, so the return value from RIGCTL to poll for the frequency its currently parked on isn't valid.




Also, while there are tons of CRC errors, you should be at least getting that frequency from SDR#/Gpredict, but seeing the high noise floor, may want to see how it looks without the tuner and rtl agc turned on, or disable only one or the other.

 

[scanfan03]

I have played with the tuner agc and everything including bandwidth (down to 4KHz). I'll use sdr++ and see what happens. The connection for the plugins go down when I close dsd-fme and like I said it will hunt for the cc according to the channel table in the dsd-fme csv and you can watch sdr# tune to all of the frequencies so it has to be connected and working right. It seems like there's something keeping me from following the TGs in dsd-fme itself like lockout or something else.

So to recap my best bet is to try SDR++ first. Then go back to SDR# and then I'll try the aw version. If that doesn't work use SDR++ and the aw version.

 

[lwvmobile]

On the SDR++ route, you'll want to make sure your TCP and RIGCTL look like this, and you will probably need to add the rigctl server module first, its found under module manager. For the best result, I'd honestly just skip straight to AW for NXDN, but I suppose one step at a time to narrow it down.

 

[scanfan03]

With SDR++ I'm getting an error opening socket for something. I'm guessing it's for the rigctl server, but I will attach the log file to see if I'm even getting the right data in because there is data that looks like is being decoded.

 

[scanfan03]

Plus I don't know how busy the system is at the moment so who knows if there are any voice calls going on right now...

 

[scanfan03]

Also, here is a screenshot of my SDR++ settings.

 

[lwvmobile]

With SDR++ I'm getting an error opening socket for something.

Make sure the network sink and rigctl modules are started and in the listening status. If you still cannot connect, hit stop, and then change the 'localhost' value to your current IP address, and similarly, change the -i tcp line to -i tcp:192.168.7.8:7355 putting in that computers actual TCP/IP4 address assignment, and not my LAN ip. Others have reported that using localhost in windows does not resolve the IP address correctly for some reason when using SDR++.

If you can get connected after that, you should hopefully see a frequency listed out in DSD-FME with the control chanel information. You mentioned earlier you thought something was blocking DSD-FME from tuning when the call grants came in earlier, and I should clarify, if DSD-FME has not internalized the control channel frequency, it will not tune to a voice call because it does not know where to return to. If the system isn't busy, we still want that frequency there, pretty sure that is the root issue for not tuning calls to begin with.

---

Just got your update, change the network output to TCP and not UDP. and try the steps listed up top.

P.S., adjust the min and max sliders on the right, get that noise floor down, its purely aesthetic, I get that, but it does help to figure out signal from nothing when its not all glowing orange and red.

 

[scanfan03]

I think I have successfully broke it. I changed the command line to tcp instead of udp and it doesn't load at all. It just sits there on the screenshot below.

 

[lwvmobile]

Yeah, I'd say you got a little extra in there with some rogue copy and pasting, here I cleaned it up for you, try this instead.

dsd-fme-lz.exe -fi -i tcp:192.168.12.181:7355 -U 4532 -T -C examples\nxdn_chan_map.csv -N 2> nxdn.ans

Just of note, you don't need to use -Y (scannner) if you are trunking, they are different modes, but one should disable the other, and so on, so only -T was used (i think, don't have the code directly in front of me to confirm). Also, the -4 only works with a supplied key csv file, so only use that when supplying a key.csv file.

 

[scanfan03]

I went back to my original command line and the console still doesn't open... What in the world...

 

[scanfan03]

I used your command line with SDR++ and it seams to be working! Thank you! I'll see if I can break it some more later. HAHA!!

BTW I did lower the noise floor in my spectrum analyzer view.

 

[lwvmobile]

I used your command line with SDR++ and it seams to be working! Thank you! I'll see if I can break it some more later. HAHA!!

Okay, sounds good. So, just to clarify, its connecting now, and it is also successfully polling and retrieving the frequency, and perhaps tuning correctly (if any call grants received).

 

[scanfan03]

Yes it is. There is a scrambled talkgroup talking right now and it is tuning to it and I hear the garbled transmission. So, it seems to be receiving the control channel, polling and retrieving the voice frequency and tuning to the correct frequency, then going back to the control channel.

I really appreciate your help! I was pulling my hair out trying to figure out what in the world was going on!

 

[lwvmobile]

I really appreciate your help! I was pulling my hair out trying to figure out what in the world was going on!

Yeah, no problem, just wanted to make sure everything was good to go, I don't like leaving people hanging on something not working that should be working. Just as a side note, if you switch up to the aw build, probably just dsd-fme-aw-aero.exe for NXDN, the scrambler decryption has had some significant improvement when paired with trunk tuning and forced application of a key value, if you just happen to know what those are that is. But other than that, I would just recommend anybody just switch over to AW at this point, its got lots of other general improvements over 2.1b.

That does leave the question, though, I wonder if the Gpredict plugin is broken now for newer version of SDR#. While its tuning and setting frequencies, it doesn't seem to reply positively to the 'f' command for the current frequency tuned.

 

[scanfan03]

I've switched to the aw build and it works too.

I have no idea, let me know if I can do anything to help.

 

[Bote]

Others have reported that using localhost in windows does not resolve the IP address correctly for some reason when using SDR++.

Windows is probably resolving localhost to an ipv6 address which would bork an ipv4 connection attempt.

 

[UJMqwerty912]

How can we interpret this console output from DSD-FME? "SLOT 1 SB/RC (FEC ERR) E:_; I:_____ D:___;" Also, is there a resource for understanding and adjusting the console logging from DSD-FME that you would recommend?

 

[lwvmobile]

How can we interpret this console output from DSD-FME? "SLOT 1 SB/RC (FEC ERR) E:_; I:_____ D:___;" Also, is there a resource for understanding and adjusting the console logging from DSD-FME that you would recommend?

It just means that there was an FEC error, as in, it couldn't correct the single burst or reverse channel data using the BPTC method in the ETSI manual. The values of I and D and the Interleaved Values pulled directly from the sb/rc location OTA, and the D value is the hex value that was attempted to be recovered by the BPTC, but failure was indicated. They are really just debug values for me to look at.

If you see this message once or very seldomly, it most likely is just an error. if it occurs all the time, then its probably a CCR (Tytera, Retevis, etc) which may or may not be using their proprietary encryption, or using that SB field in a different unknown way.

 

[lwvmobile]

As far as payload logging, there is really only two options, or three if you count discarding everything, but you either just get the standard output, or the full payload dump with -Z option. I don't have verbosity levels, honestly, too far gone to go back and pick and choose what comes out on any given verbosity number, if applied.