AbracaDABra - multiplatform SDR for RTL-SDR USB sticks

[andimik]

Already fixed. https://github.com/KejPi/AbracaDABra/issues/69

Please wait for newer version in case you cannot build yourself.

[KejPi]

Windows users can replace libdabsdr.dll in installation folder. Please go here: https://github.com/KejPi/AbracaDABra/bl ... dabsdr.dll and use Download button
I am sorry for the problems, I will release new version of app soon.

[KejPi]

AbracaDABra 2.1.1 has been released

Changes:

• bug-fixing release
  • DABSDR 2.1.1 fixing random crashes
  • localisation fixes

You can download binaries here: https://github.com/KejPi/AbracaDABra/re ... tag/v2.1.1

Arch Linux users can install AbracaDABra from AUR

If you have any problem please report here or enter new issue on GitHub

[oldenburger]

Hier gibt es eine neue Version der librtlsdr: https://github.com/old-dab/rtlsdr/releases
Weil HF-Hase festgestellt hat, dass die Spiegelfrequenz-Dämpfung der Tuner R820T und R828D bei Frequenzen unter 650 kHz schlecht ist, habe ich die Filter geändert. Die untere Filterflanke ist jetzt nicht mehr bei 490 kHz, sondern bei 620 kHz. Die untere Filterflanke ist dann nicht mehr ganz so steil. Aber was nützt das steilste Filter, wenn Spiegelfrequenzen auftreten?
Weil die technischen Daten bei der Bandbreite etwas streuen, kann man jetzt auch die Bandbreite von 1400 kHz bis 1900 kHz in kleinen Schritten von etwa 40 kHz einstellen.
Für die Tuner E4000 und FC0012/13, die keine für DAB passende Filter haben, wurde das FIR-Filter verbessert.
Auf den Bildern sieht man den leeren Kanal 8c, empfangen mit Tuner R820T. Im roten Kreis ist die Spiegelfrequenz vom Nachbarkanal 8d zu sehen vorher und nachher.
rtl2_tcp ist für qirx, rtl_tcp für alle anderen Programme.

Here is a new version of librtlsdr:https://github.com/old-dab/rtlsdr/releases
Because HF-Hase noticed that the image rejection of the tuners R820T and R828D is bad at frequencies below 650 kHz, I changed the filters. The lower filter edge is now no longer at 490 kHz, but at 620 kHz. The lower filter edge is then no longer quite as steep. But what use is the steepest filter when image frequencies occur?
Because the technical data for the bandwidth vary somewhat, you can now also set the bandwidth from 1400 kHz to 1900 kHz in small steps of around 40 kHz.
The FIR filter has been improved for the E4000 and FC0012/13 tuners, which do not have a filter suitable for DAB.
The pictures show the empty channel 8c, received with tuner R820T. The image frequency of the adjacent channel 8d can be seen in the red circle before and after.
rtl2_tcp is for qirx, rtl_tcp for all other programs.

[KejPi]

Thanks for very interesting information. However I have to admit that ABracaDABra builds do not use this version of RTL-SDR driver although I know it is far the best in terms of reception performance. The problem I can see currently is that at least on Windows there is a problem of stopping data acquisition thread that causes application to be annoyingly slow when tuning to new channel. Nevertheless I will check if I can include this driver to other builds, I really like the performance, specifically AGC control makes SW AGC implemented in AbracaDABra obsolete.

[oldenburger]

The data acquisition thread in RTL-SDR is not stopped when tuning to a new channel. Only the tuner changes its frequency.

I compared the times until the sound can be heard on the new channel after a change. With my version of the RTL-SDR it takes 4 to 8 seconds, with the original version 4 to 5 seconds. The difference might be because I set the "RAW_IO" parameter in the Winusb driver. This allows Winusb to overlap multiple USB transfers. Without this parameter only one transfer is active. Then there is data loss on slower PCs. The original version doesn't set the parameter because libusb doesn't support it yet. That's why I don't use libusb in Windows.

How are the times with you?

[KejPi]

I know that driver does not stop the thread while tuning, but I do. I have not found any better solution to avoid mixing of the data from old and new channel. There is an undefined latency between calling

Code: Alles auswählen

rtlsdr_set_center_freq

and getting IQ from new channel in thread callback. So what I actually do is following:

1. Stop data acquisition:

   Code: Alles auswählen

   rtlsdr_cancel_async

2. Wait for thread to exit - there is 2 sec timeout, with WinUSB implementation 2 sec is not enought and I have to wait 2 more seconds and occasionally even 2 more. So upto 6 seconds wait time. With libusb 2 seconds wait time is always sufficient.
3. Reset buffers

   Code: Alles auswählen

   rtlsdr_reset_buffer

4. Tune new channel

   Code: Alles auswählen

   rtlsdr_set_center_freq

5. Start data acquisition thread

I have removed WinUSB from your code and the problems with thread cancellation disappeared. I will probably use that RTLSDR implementation in next version of binary builds.

I am open for a discussion about better way of handling RTL-SDR driver during tuning but let's move to other channel not to bother people here with implementations details

[Drehrumbum]

Hi folks!

Maybe I'm wrong, but if you have switched to another channel, you are looking for the Nullsymbol at first. This takes a while and you can't do anything more until you've found it. If you want, you can overread some buffers from the device silently after switching, but IMHO there is no need for stopping the device.

With old-dab's rtlsdr.dll (QIRX) and calling rtlsdr_cancel_async(), the device fires up to RTLSDR_BUF_NUM (usually 16) additionally buffers before it finally stops and rtlsdr_read_async() returns. This must be handled well with multiple threads and takes time. So stopping the device should be avoided if possible.

For "normal use" the switching-speed is likely fast enough. Below you can see a screenshot of a IQ-Recording taken with my DAB-Scanner during debugging and while it switches channels every 102400 IQ-Samples. The "switching-noise" is short, so waiting a little longer might be useful. The fmlist-scanner (Raspi) waits 100ms, before it does its work.

[KejPi]

Well, it is true that first you need to look for null, but the problem is that I do not know when to start this process. Library is much faster to reach sync than the buffers latency, I can sync already on the first NULL. The other possibility would be to define some worst case of the latency - means when I call tune, next tbd. N buffers will be discarded. This is actually what I do for rtl_tcp so I can try to do the same with RTL-SDR device too.

EDIT: first trials seem to be positive. I will investigate further. If it works, AbracaDABra will be even better by using better RTL-SDR driver implementation

[oldenburger]

That's a good idea. With rtl_tcp it takes me a constant 4 seconds until something can be heard on the new channel. Another possibility would be fewer buffers. 15 is default. 5 might be enough in rtlsdrinput.cpp.

Code: Alles auswählen

rtlsdr_read_async(m_device, callback, (void*)this, 5, INPUT_CHUNK_IQ_SAMPLES*2*sizeof(uint8_t));

[KejPi]

I have left the number of buffers on its default value and it seems to work. I only have issue on Ubuntu running in VirtualBox with default RTL-SDR implementation (provided by Ubuntu 22.04) so I am curious if the new implementation will work with original RTL-SDR on slow computers.