-
-
Notifications
You must be signed in to change notification settings - Fork 22
dsd-neo audio #152
Hello Arancormonk, I don't know how good it is that I opened a new issue, but I haven't found the problem with SNR, in fact the problem is that there are still times when the first call comes in with a broken sound, the right ones less often, please when you can take a look at the code, otherwise for me it's super ok
All reactions
Replies: 22 comments 18 replies
Hello Arancormonk, I don't know how good it is that I opened a new issue, but I haven't found the problem with SNR, in fact the problem is that there are still times when the first call comes in with a broken sound, the right ones less often, please when you can take a look at the code, otherwise for me it's super ok
To debug this properly I need an IQ capture from a run where the first call has broken audio. Without the raw IQ, I can only guess whether this is RF/SNR, sync timing, demod state, or audio output.
Please run the same command/settings you normally use, but add IQ capture, for example:
dsd-neo <your usual options> --iq-capture broken-first-call.iq --iq-capture-max-mb 512 2> broken-first-call.log
Start the capture before traffic begins, let it catch the broken first call and ideally one normal call afterward, then stop dsd-neo cleanly. Please link zip/7z/rar/whatever:
- broken-first-call.iq
- broken-first-call.iq.json
- broken-first-call.log
- the exact command line/config used
All reactions
https://we.tl/t-2Hq4nyBUyucb2pHF
Hello Arancormonk, I made new recordings, I had no activity on certain channels so I did it with my own DMR station, without encryption, but it still does the same thing, from what I've noticed either at the beginning of a call, or when I come in with one call after the other. Thanks !!!
All reactions
Arancormonk, I have now tested with multiple audio inputs, TCP, Pulse Audio and it behaves the same.
All reactions
This comment has been hidden.
This comment has been hidden.
i think your rtl gain is too high, can you lower the gain and try again? my signal analysis of the IQ shows a ton of RF clipping
All reactions
hello arancormonk, I installed the latest version and I have these messages as if they were calls but they are not calls, do you have any idea?
IMG_20260612_153923
All reactions
Hello Arancormonk, yes I noticed that the problem was that I had the Motorola station too close to the RTL, but I did tests and the loss of audio voice is much rarer than before at the beginning of the call, but only with RTL input, with pulse audio or TCP is it ok, I noticed some decoding of TGT 0 and SRC 0 without there being any call?
All reactions
try the latest commit in main, purely guessing without having any captures to go on... #176
All reactions
All reactions
Hello Arancormonk, I made a new registration, I left the gain lower, the audio errors are somewhere in the middle
All reactions
-
👍 1
yea, still looks like an RF impairment issue... does this happen when using sdr# or sdr++ as the dsd-neo input? or does dsd-fme have this problem? signal analysis still looks like a pre-decoder issue...
All reactions
hello arancormonk, I don't know about dsd-fme because I don't have anywhere to run it, I don't have linux anymore, but with dsd-neo the problem is only with the RTL2832U input, when I use pulseaudio or tcp from sdrsharp as input I don't have any kind of error anymore
All reactions
ok, i converted your IQ capture to a wav file and now i see the terrible performance in rtl/iq mode... investigating now....
All reactions
give the latest main a try, i had to compromise on my fsk approach... but your IQ file decodes much better now... ~4000 audio errors to only like 300 now.
All reactions
Hello Arancormonk, I noticed that in the new code with the -fr function there is no longer MONO, when I activated this function instead of -fs, the audio errors were almost 0 for me, do you know what the MONO function is like now?
All reactions
oops, that got caught up in a repo wide cleanup i made. i added it back, latest main has it restored.
All reactions
Thank you very much!!!!!
All reactions
arancormonk, where could I set colors for the terminal? Calls should be green, ARS should be yellow, and LRRP should be cyan, before I was able to do it with this function : state->event_history_s[slot].Event_History_Items[0].color_pair = 3;
All reactions
sure, i can add something like that with the new call system. i've been trying to decouple as much of the backend stuff with the frontend so a native UI can go on-top of dsd-neo easily.
All reactions
can you switch to this PR branch and see if it does what you want? #257
feature/protocol-neutral-event-colors
make comments on the PR if you want something changed/adjusted
All reactions
Honestly, I have no complaints—the program is superb. However, these "RX OK" messages used to appear in the terminal; I believe they were related to the request-response process. Thank you very much
IMG_20260725_064939
All reactions
does this do what you want? #263
branch dmr/standardize-response-events
All reactions
Hi arancormonk, honestly, the program runs perfectly for me, but I’ve noticed that LRRP messages appear twice, and when a call comes in, they appear three times—is that normal? Otherwise, it’s great
All reactions
check if the latest main fixes the duplicated event history, if not, can you send a capture? same capture method as before in this thread.
All reactions
Hello arancormonk, the calls are still repeated, you can see the date and time of the call by the time, I have attached a photo.
IMG_20260728_131911
All reactions
try the latest commit to main... if it still doesn't work, i need an IQ capture to playback and determine what else is causing this:
dsd-neo <your usual options> --iq-capture dup-call-event.iq --iq-capture-max-mb 512 2> dup-call-event.log
i'll need the resulting .iq, .iq.json, and .log files please
All reactions
so... did the changes work or not?
All reactions
but, arancormonk, what is your opinion of SNR ????
VID_20260728_131943.mp4
All reactions
enum { SNR_METER_BARS = 8, SNR_METER_WIDTH = (SNR_METER_BARS * 2) - 1 };
#if defined(DSD_USE_PDCURSES) && defined(DSD_HAS_PDCURSES_WIDE_API)
static const wchar_t snr_block_glyphs[SNR_METER_BARS][2] = {
{(wchar_t)0x2581, 0}, {(wchar_t)0x2582, 0}, {(wchar_t)0x2583, 0}, {(wchar_t)0x2584, 0},
{(wchar_t)0x2585, 0}, {(wchar_t)0x2586, 0}, {(wchar_t)0x2587, 0}, {(wchar_t)0x2588, 0},
};
#else
static const char* const snr_block_glyphs[SNR_METER_BARS] = {"▁", "▂", "▃", "▄", "▅", "▆", "▇", "█"};
#endif
static int
snr_meter_bar_count(double snr_db)
{
if (!isfinite(snr_db) || snr_db <= -50.0)
return 0;
if (snr_db < 2.0) return 1;
if (snr_db < 3.0) return 2;
if (snr_db < 4.0) return 3;
if (snr_db < 5.0) return 4;
if (snr_db < 6.0) return 5;
if (snr_db < 7.0) return 6;
if (snr_db < 8.0) return 7;
return 8;
}
Here I made the change, in case anyone still wants to have 8 lines at SNR and have the SNR be more "active"
All reactions
-
😄 1
Hello Arancormonk, I saw a new decoding: dmr: detect and decode standalone Reverse Channel bursts, but wouldn't you like to make messages like; Cease Transmission Request; or whatever messages may be being decoded appear in the Ncurses Terminal? Thank you very much, and if you can with a yellow color. I love decoding messages in the terminal. Thanks Arancormonk
All reactions
does this branch do what you want? dmr/rc-command-events
All reactions
Superb, thank you very much Arancormonk
All reactions
cool, i'll merge it into main :-)
All reactions
Hello Arancormonk, thank you again, for me dsd-neo works very well, will you be able to add more realistic tones for DSD-NEO, for example what are the Motorola tones like? Or Dual Tone? I tried with GPT but I only got some terrible noises, anyway thank you again
All reactions
ill think about it. can't use motorola tones more than likely due to copyright
All reactions
Hello Arancormonk, I wanted to test other communication modes, namely NXDN, but it seems to me that there are problems with decoding?
All reactions
gonna need more detail, can you share your configuration/command line switches? i need to see the entire thing you're passing to dsd-neo.
then take a iq capture for investigation:
dsd-neo <options> --iq-capture nxdn_debug.iq --iq-capture-max-mb 512 2> nxdn_debug.log
then send me the all the files: iq, json, and log
All reactions
Hello Arancormonk, I think the NXDN decoding was actually my problem, I saw your new update and I said that I would connect with sdr++ to the spy server to find a tier 3 or con+ system and test it with dsd-neo, but I didn't succeed, but please explain to me if I find a Tier 3 or Con+ system, how can I call it DSD-Neo? I found a control channel but it didn't find the frequencies even with T active, or does the new update find the frequencies itself? Thanks
All reactions
dsd-neo (or any of the other popular decoder software for that matter) can't learn voice frequencies over the air for dmr tier 3 or con+ (same applies to nxdn with a very minor rare exception). unfortunately dmr is not designed like p25 in that area; all grants are LCN-based. you'll have to provide it a channel map CSV (example: https://github.com/arancormonk/dsd-neo/blob/main/examples/dmr_t3_chan.csv, https://github.com/arancormonk/dsd-neo/blob/main/docs/cli.md#trunking--scanning)
the terminal version of dsd-neo doesn't have the radioreference import feature i just added to android, but i can work on adding it.
also, SDR++ audio alone can't retune, enable SDR++'s rigctl server and run with -i tcp -U 4532, though a remote SpyServer will retune too slowly to follow calls reliably (too much latency).
All reactions
Hello arancormonk, I recently had the opportunity to listen to a digital communication, I think c4fm, or at least that's how it appeared to me in dsdplus, and when the audio call appeared, it had a very clear hearing compared to DMR. Do you think that in the future you will be able to work on the audio on DMR to be heard as clearly as possible or is it all about modulation? Or maybe it's these settings and I don't know, and please when you can add the tones as realistic as possible of a real station. Thank you.