DSD-neo

[Whiskey3JMC]

"On second thought let's not go to Camelot RR Forums, it's rather a silly place."​

 

[ArloG]

- RTL-SDR, RTL-TCP, SoapySDR, TCP/UDP PCM, WAV/file, and M17 UDP input/output paths.

I'll crown you King if you can find a way to use SoapySDR to use an Icom IC-R8600. The guys with I/Q drivers for other radios would probably give you a key to the city.
What University would a person have to enroll in to create a new driver that lets a radio work with these applications?

 

[nd5y]

I made a .ini file with chan_csv that points to the frequency list file.
If I start with -Y it finds the active CC but won't trunk track and sets [trunking] enabled = false in the .ini file.
-T -Y does the same thing.
-T trunk tracks but doesn't read the channel file. it only uses the specified rtl_freq.

Is there any way to make it scan for control channels and trunk track?

 

[arancormonk]

I made a .ini file with chan_csv that points to the frequency list file.
If I start with -Y it finds the active CC but won't trunk track and sets [trunking] enabled = false in the .ini file.
-T -Y does the same thing.
-T trunk tracks but doesn't read the channel file. it only uses the specified rtl_freq.

Is there any way to make it scan for control channels and trunk track?

I checked the code path here. -Y is conventional scan mode, not trunking scan mode. When -Y is parsed it enables scanner_mode and explicitly clears the trunking flags, so autosave later writes [trunking] enabled = false. -T -Y ends the same way because -Y wins when parsed last.

-T is the trunking mode. It can load chan_csv as the channel/frequency map, but it does not currently do a startup sweep through that CSV looking for an active control channel. Trunking expects the receiver to already be parked on a usable control channel via rtl_freq/rigctl, then it uses the map for grants and channel tuning.

So the current workflow is: use -Y or another tool to find the active CC, put that frequency in [input] rtl_freq, then run with -T or [trunking] enabled = true without -Y.

A combined “scan for CC, then switch into trunk tracking” mode is not currently exposed as a supported option. In ncurses, manual channel cycling with L may help step through the CSV, but automatic scan-then-trunk would need new behavior.

Realize this codebase was forked from DSD-FME, so a lot of legacy behavior and functionality is common. Use GitHub to submit a feature request if this is something you want: Issues · arancormonk/dsd-neo

 

[arancormonk]

I am running into an issue where it runs well for probably 20 to 30 minutes and then one of two things happen.
1. Signal box turns blue, still shows a very useable SNR but doesn't decode the P25P1 control channel.
2. Signal box stays green, but SNR meter shows N/A.

Restarting the RTL stream from the menu can sometimes get it going again for a few minutes.

If this is a bug and not a screw up on my part, I'll move it over to github. I am running windows, so I'll need to figure out how to dump logging.

My config, monitoring a simulcast cell on 853.725. I could dial the gain down to 40 with a still useable SNR.

version = 1

[input]
source = "rtl"
rtl_device = 0
rtl_freq = "853725000"
rtl_gain = 49
rtl_ppm = 1
rtl_bw_khz = 48
rtl_sql = -120
rtl_volume = 3
auto_ppm = true

[output]
backend = "pulse"
pulse_sink = "Headphones (Realtek USB2.0 Audi"
ncurses_ui = true

[mode]
decode = "p25p1"
demod = "qpsk"

[trunking]
enabled = true
group_csv = "c:\mpscs.csv"
allow_list = true
tune_group_calls = true
tune_private_calls = true
tune_data_calls = false
tune_enc_calls = false

[logging]

[alerts]
enabled = false
voice_start = true
voice_end = true
data = true

[recording]
per_call_wav = false
per_call_wav_dir = "C:\RadioApps\dsdneo\calls"
rdio_mode = "dirwatch"
rdio_system_id = 1942
rdio_api_url = "http://127.0.0.1:3000"
rdio_upload_timeout_ms = 5000
rdio_upload_retries = 1
rdio_api_delete_after_upload = false

[dsp]
iq_balance = false
iq_dc_block = false

I think mine (Linux AppImage) also seems to quit decoding after a while.

I don't know how the terminal text colors work in Win 10/11. I don't remember if you can even change that. With my terminal text color palate when I start the program the top line is white (uncolored) and the rest is all dark cyan. Parts of it will turn green. I don't know what green indicates. Sometimes the green part will rapidly alternate green/cyan with garbled audio or no CC decode.

What is GFSK? I have never heard or seen that before. Is that supposed to be GMSK (gaussian minimim shift keying)? I thought the only thing that uses GMSK is D-Star.

I get GFSK with auto demod on some DMR, NEXEDGE and some P25. I thought DMR, Both NXDN, and P25 except for QPSK simulcast were all 4 level FSK which to me is C4FM. If I use -mc or demod = "c4fm" in the ini file it doesn't seem to work sometimes.

i've added several defensive measures to resolve this issue, you can try it in: https://github.com/arancormonk/dsd-...ightly/dsd-neo-msvc-x86_64-native-nightly.zip

realize this is a nightly build (latest of main branch), so other things may break. also, this branch uses the latest version of the mbelib-neo api, so the audio quality should improve... may be subjective, though.

 

[dispatchgeek]

i've added several defensive measures to resolve this issue, you can try it in: https://github.com/arancormonk/dsd-...ightly/dsd-neo-msvc-x86_64-native-nightly.zip

realize this is a nightly build (latest of main branch), so other things may break. also, this branch uses the latest version of the mbelib-neo api, so the audio quality should improve... may be subjective, though.

Nightly build has been running most of the day on my PC without issue. I think you found the problem.