Closed russel closed 7 years ago
Input files are only partially useful to test dabtools because some tuning loops actually reconfigure the RTLSDR reception frequency during reception. I've always had better reception performance with SDR-J than with dabtools. Short answer to your question: no, it is working. Could it do a better job? Yes.
@basicmaster @mpbraendli It is perhaps worth noting that SDR-J_DAB is no more, it has morphed into Qt-DAB. https://github.com/JvanKatwijk/qt-dab
Also that there appears to be a maintained version of librtlsdr at https://github.com/librtlsdr/librtlsdr
This pull request https://github.com/Opendigitalradio/dabtools/pull/9 has made things better but Qt-DAB still has the edge over dablin_gtk/dab2eti for receiving DAB radio on the same hardware. I believe currently, anyway. Would investigating the way Qt-DAB (and it's command line counterpart) do things help improve dab2eti?
Cool! I was able to compile qt-dab on my Arch Linux box after a longish quest to get the correct qwt version. Seems to work pretty well with my rtlsdr (TCXO and R820T2 tuner). Improving dabtools would be welcome of course.
Still something to be done for that issue? Can we close it?
I just compiled up SDR-J_DAB on Fedora Rawhide (can't on Debian :-( and with the two devices I have I get DAB radio. I had to use some seriously dark arts (i.e. try all options) to get a suitable gain value, but I did get actual sound – fairly continuous and more or less reasonable sound. Same hardware, same settings with dablin_gtk/dab2eti and the situation is usually silence if there is a signal lock, usually though a lock fail. Given both are using librtlsdr as the way of communicating with the hardware, one has to hypothesise that dab2eti is failing in it's role of generating a good ETI stream.
Are there any input file / output file pairs anywhere that could be used as a test to see if the code is doing anything useful?