DSD FME

[URTK]

DSD-FME can work with Phase 1 trunking, but if it is not tuning appropriately, then we need to take a look in the log.ans file and see what all is going on. Are there a lot of decoding errors preventing things like the IDEN base frequencies from populating? Are they indeed call grants occurring but not being tuned? Are call grants attempted to be tuned but not landing on the correct frequency, or is that frequency poor signal? Lots of things could be happening. I see you are using the -mq switch, you might try without that and see if that improves things. You may also need to tweak the rtl setting a bit and see if that helps (things like PPM, etc.) Keep in mind though, if the system is simulcast (LSM, or CQPSK, or H8DPSK), then decoding may not be very good on that, and that's something that can't particularly be fixed in DSD-FME.

Thanks for your answer!
Indeed I used:

dsd-fme-aw-aero.exe -f1 -i rtl:1:***.***M:42:1:12:0:3 -T -N 2> log.ans
and everything worked perfectly. I also want to note that the CQPSK system is now in operation, the quality of decoding the voice channel is excellent. DSD FME sometimes (rarely) does not switch to the voice channel. I attribute this to the fact that the control channel in my location is not received ideally (150-200 RMS, when the voice channels on this site is 500 or more RMS). The PPM settings are installed, there are no complaints about them. The only thing is that the - "Call History" field remains empty after any successfully received encrypted voice message with key (AW 20240405).

I would especially like to express my gratitude for your efforts!
I remember I asked to add Volume when using RTL - this option turned out to be very useful, with its help I am already consistently receiving traffic from one of the CAP+ systems using RTL. It works very stably and efficiently today.
Thank you!

 

[dr_bot1]

Hello everyone!
I have a quick question regarding dsd-fme. First of all - what a great project! I really appreciate the work of the creators and community.
I have the following case here. I am listening to a NXDN48 trunk. I have a couple of people talking in the same TG, but they are using different scramble keys. I have the keys in the keys.csv files, but for some reason dsd-fme uses only the last key in the csv file. Is there any way to be able to switch between the keys based on other ID such as RID? Is there any way to check if the first key for the TG is wrong to switch to the next?
Thanks you!

 

[lwvmobile]

have a couple of people talking in the same TG, but they are using different scramble keys. I have the keys in the keys.csv files, but for some reason dsd-fme uses only the last key in the csv file. Is there any way to be able to switch between the keys based on other ID such as RID?

Are they using a unique key id? if so, then load by key id.

 

[dr_bot1]

Are they using a unique key id? if so, then load by key id.

Hello and thanks for the quick response.
No, the keyID is the same for all - 0x00, exactly like the TG. Only the aliases and RID-s are different. I understand that this is rather unusual setting, but do you think that it is somehow possible to switch the key based on other identifiers?

 

[lwvmobile]

And to be clear, is this on a trunked system? Or is this just scanning conventional frequencies with different RANs or something? If the TG is the same at zero, and the KeyID is the same, I don't understand how how individual units could be talking to one another with the correct key.

To be honest, yes, I could change couple lines, and have it either load by RID instead of by TG, or add an additional check for key by RID as a last resort, but doing that, due to the sheer possible number of RID values, may cause clashing key loads doing it in that manner. I'm not overly confident this sort of change in code would be beneficial to others without the risk of breaking things for others.

Do you use the windows precompiled version, or do you compile it yourself? If its the latter, I could easily point you to the lines to change or make a simple patch to apply, but windows precompiled would be reliant on me taking the time to fire up the VM, go through the cygwin rigamarole and spit out an .exe file for you to test.

 

[dr_bot1]

And to be clear, is this on a trunked system? Or is this just scanning conventional frequencies with different RANs or something? If the TG is the same at zero, and the KeyID is the same, I don't understand how how individual units could be talking to one another with the correct key.

To be honest, yes, I could change couple lines, and have it either load by RID instead of by TG, or add an additional check for key by RID as a last resort, but doing that, due to the sheer possible number of RID values, may cause clashing key loads doing it in that manner. I'm not overly confident this sort of change in code would be beneficial to others without the risk of breaking things for others.

Do you use the windows precompiled version, or do you compile it yourself? If its the latter, I could easily point you to the lines to change or make a simple patch to apply, but windows precompiled would be reliant on me taking the time to fire up the VM, go through the cygwin rigamarole and spit out an .exe file for you to test.

Hi, you are right! I talked to on of the guys (regular user, not the system admin) - it turns out that every group with the same scramble key uses separate channel. This makes the system not trunked, and each key is valid for a certain channel/frequency. Also the RID-s are just random numbers and the keys are not bind the them at all. Is there a way to automatically switch the key based on the frequency? I use windows, unfortunately. I don't have Linux box right now.

 

[lwvmobile]

Well, how are you using dsd-fme now? In other words, what command(s) are you using, and be specific about your setup. You can omit key values and exact frequencies, that's fine.

There is a way to load NXDN scrambler keys by frequency, but it requires using either the built in rtl input method, or using SDR++. dsd-fme-lz.exe (included in the dsd-fme-20240601-win32.zip release) can pretty much do what you are trying to get it to do. See the README Special Builds.txt for more information, but essentially, its this.

dsd-fme-lz.exe is a patched version where certain NXDN elements are explicitly forced to load and enforce keys based on frequency value read in by either the rtl tuned frequency, or via the RIGCTL reported frequency along with other NXDN specific tweaks to a very edge user case.

So, basically, make a csv file just like the usual ones for key loading, and set it up using the 9 digit frequency value in Hertz, and a key value in decimal. Keep in mind, this will only work with either rtl input, or with sdr++ using tcp input and rigctl.

 

[dr_bot1]

Well, how are you using dsd-fme now? In other words, what command(s) are you using, and be specific about your setup. You can omit key values and exact frequencies, that's fine.

There is a way to load NXDN scrambler keys by frequency, but it requires using either the built in rtl input method, or using SDR++. dsd-fme-lz.exe (included in the dsd-fme-20240601-win32.zip release) can pretty much do what you are trying to get it to do. See the README Special Builds.txt for more information, but essentially, its this.



So, basically, make a csv file just like the usual ones for key loading, and set it up using the 9 digit frequency value in Hertz, and a key value in decimal. Keep in mind, this will only work with either rtl input, or with sdr++ using tcp input and rigctl.

Hello again,
Thank you for the answer. That's great news! I am using SDR++ and tcp input and I will try your suggestion. I will let you know if it works

 

[lwvmobile]

Just remember, you have to also be using the RIGCTL module in SDR++ and connect to that as well so that DSD-FME will be able to poll SDR++ so it knows what frequency its currently tuned to.

 

[dr_bot1]

Just remember, you have to also be using the RIGCTL module in SDR++ and connect to that as well so that DSD-FME will be able to poll SDR++ so it knows what frequency its currently tuned to.

Hi, It works like a charm!
Thank you so much for your help and dedication to this awesome project!
I wish you best of luck and keep up the good work!

 

[Louie7]

so this is the silent frame?

It seems that it depends on the brands, some have 3 silence frames, others 18.