DSD FME

[EI9BAB]

Okay, I figured out something, its related to the auto gain. If you use the -g option and pick -1 it will disable auto gain, or you can use something like -g 1 or -g 2 then it'll play them again. I'll have to review the auto gain function again, seems like I did some things to it when working on the crackling/auto smoothing stuff a little while back.

This command worked for me, but you'll need to adjust it based on your own usage.
dsd-fme -g -1 -r mbefiles/*

That worked perfectly for me! Thanks a million for finding that workaround so quickly.

This might be a really stupid question but do the -K and -H options work with -r playbacks? The output audio sounds exactly the same to me, regardless of the key. I would expect it to alter with different keys.

Also when using the -H option, the **tera Key is shown but when using the -K option there is no mention of it during program exection. That is regardless of whether it is in live mode or playback mode with both Full and Lite versions. Again, maybe that is expected behaviour.

 

[lwvmobile]

This might be a really stupid question but do the -K and -H options work with -r playbacks? The output audio sounds exactly the same to me, regardless of the key. I would expect it to alter with different keys.

They do not work with .amb file playback. I could probably make -K work with .amb files, but not -H. Problem is, there is more to applying that than just raw .amb frames, there needs to be a count of frame number involved, or knowing when the next 'sync' occurs, and not to mention, the underlying svc and mfid bits to tell us what it was to begin with. Another reason why I prefer the symbol capture bin method to just the ambe/imbe frame files.

Also when using the -H option, the **tera Key is shown but when using the -K option there is no mention of it during program exection. That is regardless of whether it is in live mode or playback mode with both Full and Lite versions. Again, maybe that is expected behaviour.

Yeah, I have a bad habit of not printing all the input options a user uses, just depends. A lot of times, like with -H, the only reason it prints it on start up, is because I needed to verify the software was loading the long string and sorting it into the correct variables appropriately and that was the easiest way.

 

[lwvmobile]

That worked perfectly for me! Thanks a million for finding that workaround so quickly.

Just another thing that occurred to me, when I switched over to handling TDMA stereo voice on DMR (also goes for Phase 2), and LICH decoding on NXDN, there is currently no MBE file saving being done on those modes, since I couldn't reliably dump two sets of .amb files at the same time with the current code, and subsequently close them with proper names. I could feasibly work it back in on NXDN (open it when voice frame) the old source code always had it open those on 'voice sync' but with lich decoding, that really isn't super feasible, since you can have voice in half a facch in the other half, or no voice, etc. The older 'NXDN Voice Sync' in the source code was only one of multiple NXDN FSW + LICH patterns, so it didn't work on every possible voice pattern, particularly not on NXDN TB systems. All Full Rate systems (Phase1, ProVoice) and Half Rate D-STAR, dPMR "SHOULD" still work, but I haven't tested those to make sure.

 

[millam]

Question: is NDXN96 tracking supposed to work? I start SDR# listening to 154.37, start TCP and then enter this into
a CMD window.
'dsd-fme-lite -T -fn -i tcp:192.168.1.6:20022 -C etp.csv' tcp connects and I get rolling info but SDR#
doesn't change to the voice channel. I have etp.cvs file setup with this in it:
91,154370000
92,156195000
93,154445000
....
THIS ISN'T A PRIORTY, OK!

Mil

 

[millam]

Relates to entry #284. NDXN trunking. I started ndxn trunking using rtl, this is what I got.
Worked ok until dsd tried to change to a voice channel, then it stopped. See picture, again
this is not a priority, just passing time, but I enjoy trying to figure something out.

 

[lwvmobile]

Question: is NDXN96 tracking supposed to work?

Well, its supposed to, but I haven't been able to test it personally, at all. Gauging based off of your response and also mrscanner2008's struggles, its feasible to assume that something isn't quite correct. Does the Gpredict Plugin show it has an active connection? May need to check the port and match the port it shows vs what you have for it. Can you forward part of the console log to me for analysis?

If I had local NXDN Trunking systems, I could test things and make changes as required until I knew it was working well. For now, the code is pretty much untested except for you two, and the initial results isn't boding very well.

All that being said, if anybody with close proximity to an NXDN trunking system (Type-C...I think) can provide me remote access to a Linux Machine with an RTL dongle then I could work out some of the issues.

Relates to entry #284. NDXN trunking. I started ndxn trunking using rtl, this is what I got.

Well, going by that image, it does look like its tuning and whatnot, but the data before and after the tuning seems to have some issues decoding, or it landed on the wrong frequency somehow. If you use either SDR#, or the RTL input for NXDN, I very VERY highly suggest setting an appropriate squelch level to block out noise. Noise has a pretty good likelihood of triggering false positives currently and so on. What command did you run to start up the RTL dongle? Setting squelch on those can be a bit of a pain, more of a guessing game to figure out the threshold on your system and location to block noise but allow signal easily.

 

[millam]

1. Don't know what a "Gpredict Pluin" is. Oh yea, something about a satellite tracking program(?).
2. How do I start a "Console Log" and where is it?
3. TCP is connecting so I think that the ports are correct.
4. CMD input for rtl is: 'dsd-fme-lite -T -fn -i rtl:0:154.37M:23:67:8:0:20022 -C etp.csv'
5. Squelch? 2 P25 systems sitting on a dead spot work ok, ie coming back up after retuning to signal.
All nxdn systems will not come back up after off tuning and retuning to signal, if you follow.
All nxdn systems have junk data sitting on a dead carrier.
All P25 systems have no junk data sitting on a dead carrier.
6. Gonna play with a P25 system and see if it will trunk, can't remember what happened when I tried yesterday.
7. SDR# is connected to a AirSpy R2, haven't tried my Mini's yet. RTL connects to a cheap SDR.

Mil

 

[lwvmobile]

1. Don't know what a "Gpredict Pluin" is. Oh yea, something about a satellite tracking program(?).

That's probably what the plugin's author intended, but essentially, it uses the rigctl protocol, so in essence, its our tuning method in SDR# to command SDR# software to tune to another frequency. In the last windows rc2a release, I copy and pasted it into the zip file in a folder named SDR# plugins. Depending on your SDR# version, installation may vary, but pretty sure you just close the software first, then copy and paste it into the C:\SDRSharp\Plugins folder, or where ever the install is located, then enable it with the SDR# and hardware running, and it'll show a port number its listening on. You make sure to use -U portnum where portnum is the same as what that plugin shows its listening to.

2. How do I start a "Console Log" and where is it?

Basically, just run this on the end of your command to enable the ncurses terminal (with payload enabled) and reroute the console output to a log file
-Z -N 2> nxdn.ans
let it run for a little bit, then quit, and zip the log up and send it over here.

5. Squelch? 2 P25 systems sitting on a dead spot work ok, ie coming back up after retuning to signal.

NXDN is the only system type where I currently need to use squelch in DSD-FME to prevent a bunch of false positives on the signal. It has a very short sync pattern, and issues with the old school dsd demodulator make me have to permiss one dibit error due to the demodulator/buffer not being able to handle a 'zero' properly during no sync. That'll be fixed some time in the future...hopefully.

All nxdn systems have junk data sitting on a dead carrier.

Is the signal ALWAYS ALWAYS there, or just there for an extended period of time. That could be why there is no return to control channel action happening. I may need to adjust to return to the CC after a TX_REL or extended IDLE.

All P25 systems have no junk data sitting on a dead carrier.

That has always been my observation as well. RF Channel tears down when voice call or data call assignment completes. DMR mostly follows this same method on Con+ and TIII, although Con+ may have an extended idling period.

 

[millam]

Ref #288, I'll get the Gpredict plugin going I hope. Yes the NDXN Control Channel is always there 24/7. I'll work on the console log thing.
I can't get P25 to trunk so its probably something I am doing wrong, work on somebody else's problems ok, mine aren't important.
Just thought of something, SDR# never leaves the Control Channel so dsd-fme-lite commands never make it change (?).
Another thing, is Hex absolutely nessesary is the display, maybe dec?

Mil

 

[lwvmobile]

Just thought of something, SDR# never leaves the Control Channel so dsd-fme-lite commands never make it change (?).

That's because the gpredict (rigctl) plugin isn't running, judging from your other posts, so dsd-fme can't change the frequency in SDR#.

Another thing, is Hex absolutely nessesary is the display, maybe dec?

I have a lot of decimal and hexidecimal. From a programming perspective, its easier to work with a lot of things in hexidecimal form, so it tends to be put in the console and ncurses terminal often. Other times, in some PDUs, I don't know how to interpret the individual portions, so its just print a full hex value of that field. This is particularly noticeable in some NXDN PDUs. So, is the hex necessary? Nope. Is it my personal preference? Yes.

 

[millam]

Thanks. Its too complicated to work with now, I'll check back in later.

Mil

 

[mrscanner2008]

I tried the latest version on the NXDN48 trunking with either the command dsd-fme-lite.exe -fi -i tcp -U 4532 -C examples\nxdn_chan_map.csv -T -N 2> nxdn_ran_14.ans or this one dsd-fme-lite.exe -fi -U 4532 -C examples\nxdn_chan_map.csv -T -N 2> nxdn_ran_14.ans when I start everything it monitors the control channel and from the first conversation it switches (SDR#) to the voice frequency and we hear the conversation well but it does not return to the CC or do not follow the rest on the other voice frequencies.

 

[lwvmobile]

but it does not return to the CC or do not follow the rest on the other voice frequencies.

Okay, if its tuning to the right voice channel from the control channel, that's a good sign! Better than it was. If its not tuning back, try to enable squelch inside of SDR#, enough so that actual signal can break the squelch line, but noise can't get through. Wondering if random false syncs due to the shortened NXDN Frame Sync Word is causing it to linger indefinitely on the voice channel. So, try to use squelch, and let me know if that fixes it.

 

[Mudary]

To lwvmobile only, I have a linux running jammy, I have one nexedge96 system. If you want to remote in please PM me.

 

[sunwave]

Hi,

I want to try DSD-FME. It is hard for me to figure out. I want to monitor a P25 P2 TDMA system ( Oklahoma City Metro Public Safety Trunking System, Oklahoma City, Oklahoma (radioreference.com) ). Is it possible for single dongle trunk tracking? Will someone please show me step by step how to? I am running the windows FME-Lite latest.

 

[lwvmobile]

Is it possible for single dongle trunk tracking?

Yes, actually, that is the only trunking operation DSD-FME does. It does single dongle/VFO only, depending on if you use the rtl device directly, or use something like SDR++ or SDR# with RIGCTL. Which SDR device do you have?

Will someone please show me step by step how to? I am running the windows FME-Lite latest.

I really don't have a step-by-step guide at the moment, since it may vary slightly based on different variables, but if you want to try to trunk that system, you will need to use FME with these switches.

If using SDR++ with Network TCP Audio and RIGCTL or SDR# with TCP Plugin and Gpredict Plugin enabled (locally), making sure the VFO is set on the frequency of the current control channel, and no audio filtering or processing from sneaky SDR# plugins, etc.
dsd-fme-lite.exe -i tcp -U 4532 -T -mq

If using the RTL dongle directly (following the rtl:dev:freq:gain:ppm:bw:sq:udp convention) see the bat file for more info. Right click and click Edit or More Options/Edit to view them.
dsd-fme-lite.exe -i rtl:0:851.1M:22:0:12:0:6021 -T -mq

But essentially, since its QPSK (simulcast) you'll need to run with -mq to enable qpsk, assuming its a Phase 1 Control Channel. Also, because it is simulcast, the decoding experience can be affected, honestly not sure how well it will work in your situation, I haven't been able to thoroughly test in dense simulcast areas for performance.

Admittedly though, for now, DSD-FME isn't always a beginner friendly tool, really depends on what you are trying to do with it, and what your experience level is with SDR stuff and in a more general sense, computer usage experience with command line tools, etc.

You can see more information on here on the Example Usage page. It was written for the linux builds, but its essentially the same, just swap out dsd-fme for dsd-fme-lite.exe and it'll all still work the same (sans the audio input/output but default values will get you output the same)

 

[sunwave]

Yes, actually, that is the only trunking operation DSD-FME does. It does single dongle/VFO only, depending on if you use the rtl device directly, or use something like SDR++ or SDR# with RIGCTL. Which SDR device do you have?



I really don't have a step-by-step guide at the moment, since it may vary slightly based on different variables, but if you want to try to trunk that system, you will need to use FME with these switches.

If using SDR++ with Network TCP Audio and RIGCTL or SDR# with TCP Plugin and Gpredict Plugin enabled (locally), making sure the VFO is set on the frequency of the current control channel, and no audio filtering or processing from sneaky SDR# plugins, etc.
dsd-fme-lite.exe -i tcp -U 4532 -T -mq

If using the RTL dongle directly (following the rtl:dev:freq:gain:ppm:bw:sq:udp convention) see the bat file for more info. Right click and click Edit or More Options/Edit to view them.
dsd-fme-lite.exe -i rtl:0:851.1M:22:0:12:0:6021 -T -mq

But essentially, since its QPSK (simulcast) you'll need to run with -mq to enable qpsk, assuming its a Phase 1 Control Channel. Also, because it is simulcast, the decoding experience can be affected, honestly not sure how well it will work in your situation, I haven't been able to thoroughly test in dense simulcast areas for performance.

Admittedly though, for now, DSD-FME isn't always a beginner friendly tool, really depends on what you are trying to do with it, and what your experience level is with SDR stuff and in a more general sense, computer usage experience with command line tools, etc.

You can see more information on here on the Example Usage page. It was written for the linux builds, but its essentially the same, just swap out dsd-fme for dsd-fme-lite.exe and it'll all still work the same (sans the audio input/output but default values will get you output the same)

I have the Nooelec Nano3 RTL-SDR and all I want to do is simply start up a bat file and FME do the trunk tracking. I have SDR# v1906. I barely know anything about command lines.

I tried your provided command line. it didn't like rtl:0 I changed it to 1 then it fired up the rtl-sdr now it lost the control channel. I fired up DSD+ Fastlane to check which frequency it is which is 851.1875MHz. I edited M to 851.1875M. It is P25 P2 TDMA and the CC is P1. It is a simulcast system. I live 5 blocks from the Comm center for this system.

 

[lwvmobile]

Okay, well, try this command and see if it works any better for you. Let's try to increase the gain a bit, also, do you know what your PPM should be on that particular dongle, it may need to be adjusted a bit in order to get a good sync.

dsd-fme-lite.exe -i rtl:1:851.1875M:42:0:12:0:6021 -T -mq

If you need to make PPM adjustments, you can manipulate the value to the right of 42 for PPM, but it has to be a positive or negative integer (non decimal number) so values like, 1, -1, 2, -2, etc.

 

[sunwave]

Okay, well, try this command and see if it works any better for you. Let's try to increase the gain a bit, also, do you know what your PPM should be on that particular dongle, it may need to be adjusted a bit in order to get a good sync.

dsd-fme-lite.exe -i rtl:1:851.1875M:42:0:12:0:6021 -T -mq

If you need to make PPM adjustments, you can manipulate the value to the right of 42 for PPM, but it has to be a positive or negative integer (non decimal number) so values like, 1, -1, 2, -2, etc.

I tried the SDR++ route got it to hear the CC but It is not changing frequency. I made sure SDR++ is allowed in the firewall.

...and RIGCTL features disabled. huh?

 

[lwvmobile]

...and RIGCTL features disabled. huh?

Do you have RIGCTL enabled and listening in SDR++?