search

lwvmobile / dsd-fme

Digital Speech Decoder - Florida Man Edition
Other
162 stars 31 forks source link

RTL Input Method Has Multiple Issues -- Partially Busted #125

Closed lwvmobile closed 1 year ago

lwvmobile commented 1 year ago

Well, I never tend to use this input method, but its always worked 'fine' for me when the signal is good. I went back and reviewed a lot of the code for the implementation, and realized that its busted in multiple ways. This was probably one of the first things I ever worked on on this project, and it shows. The code is a mess. The issues I've found so far include:

  1. The Gain level is not being set properly. If you set the gain manually, it will tell you the gain is being set, and the value its being set to. Its lying. Its not setting those values. I have found that using the value of 0 for auto gain works correctly still, and to be honest, if you are going to use this method, you probably better use the automatic gain (which is against even my own normal sane recommendation) but since the manual gain is busted, its just arbitrarily assigning a value (seemingly a low value, or none at all) I'm not even sure what it 'defaults to' in the rtl, but willing to guess its very low.

  2. When squelch is enabled, everything hangs on a safe wait condition until enough samples arrive to allow it to push the samples to dsd-fme. This would be okay with single frequency, but completely breaks trunking. I've been investigating ways to work around this, but in the process discovered all the other problems mentioned here.

  3. There is a problem with the 'bandwidth' setting as well, its not initialized and a lot of settings are being based off of a non-initialized setting, so who knows what values are being set there.

  4. Lots of garbage code I wrote. I don't know a better way to put it. Code and variables doing nothing.

So, anyways, with all the broken implementation, I'm going to review this whole using the rtl input again, and figure out the best way to move forward with it. Either I can just copy and paste the original code szechyjs branch and start over, and put the things that work back in, and fix the few additions (tuning, bandwitdh) or I can get the up-to-date real rtl_sdr_fm.c file from the rtl-sdr project and try to work with that. Using the szechyjs code would be the easy option, the medium option would be to reimplement it with the up-to-date c file (not the cpp file, assuming they used CPP because...pthreads?). The hard option would be to write an external program that can do all of this and just pipe the audio from it.

TL;DR: RTL input is partially busted, don't use gain settings. Will attempt to fix, but no ETA on anything (if anything at all).

lwvmobile commented 1 year ago

Well, I went in and copied the original code from the 'rtl' branch of szechyjs, essentially cleaning up the mess I had in there, and put some things back in that was desirable to keep, and tweaked a few other things. Without going into a bunch of detail (it would take all day) It does appear to work a lot better now. A few major things worth mentioning.

  1. UDP Port is optional now, all tuning is handled without the UDP socket, but I left the code for the socket intact and it will only run if a UDP port is specified. This allows legacy software like EDACS-FM to tune with the UDP socket, or a user to write their own remote control to control it over the UDP port if they desire.

  2. NXDN Trunking and Scanning now works with the RTL input. Before, this wouldn't work because using squelch would cause the dongle thread to stop on a safe wait condition until enough samples arrived to push to DSD-FME. In turn, DSD-FME would cease all operation until it had samples to run. I had to think outside the box a little bit, and instead of applying the squelch to the device itself, now we use a 'squelch' value with an internal RMS (Root Means Square) measurement from rtl_fm to guage when signal is present, and if the RMS value is greater than the Squelch level, then we look for frame sync, if its less, then just skip the frame sync tests. Works very well, but is only applied to dPMR and NXDN. In other words, the squelch isn't applied to the device, its applied in the frame sync test.

  3. I made some tweaks to the sampling and application of low pass filtering(in rtl_fm). It was more of a test than anything, but I've found that using the RTL input now with P25 Phase 1 non-simulcast works very WELL a result (haven't been in range of a Phase 2 system to test). I honestly wasn't expecting that. It also cleans up EDACS/PV considerably (fewer random bit errors) and does pretty good with NXDN48 as well when paired with the GFSK demodulator. NXDN96 is a little bit more hit-or-miss, but may be more of an internal filtering than rtl filtering issue. DMR had always worked pretty well with the RTL input, and continues to do so. Short burst beacons in Cap+, XPT, and the beginning of DMR Simplex may still drop or have decode errors, which is to be expected given the current state of the demodulator, and is nothing new.

One thing of note, however, rtl_fm was ever meant to be anything but a simple analog FM demodulator for low powered systems, so it doesn't have the advanced DSP capabilities that SDR++ or similar has, and on weaker or marginal signal, rtl input may work very poorly in contrast to SDR++, which can do a fantastic job with 'meh' signal. In other words, RTL input works best on systems with good to great signal, marginal and weak signal it doesnt' work well with.

I have done about as much as I can to get this to work better, and it is an improvement. I will go ahead and close this issue now. This portion of zDEV is pretty much ready for the new 'main' branch that will come out in the weeks or so to come. Actually, the zDEV branch will be replacing the main and aero branch as the new main branch when I get around to testing everythign else and making sure the unified codeset works on the windows side.