The analog radio signal is sampled, converted into the digital domain, by a clock running at 76.8MHz. Every second, 76800000 times a new sample is delivered. The AD9866 delivers 12 bits per sample making ‭921.600.000‬ bit/s.

It is obvious that we are not getting this large data flow in the SBC (single board computer) using the radioberry.

So we need to reduce the data flow. The FPGA is responsible for the data flow reduction.

The radioberry is using the GPIO of the SBC to retrieve the reduced data flow, no other device is required.

Downsampling (another term for data flow reduction) by the gateware can go to : 48K, 96K, 192K or 384K samples per second for a receiver channel.

This radioberry variant implements max 4 RX channels, the data of these streams must be retrieved by the SBC.

The RX stream is read using 4 data and 1 clk GPIO pin. The data is retrieved via 'bit-banging' method. Iam using a so called DDR, double date rate, algoritm. Iam reading 4 bits by setting the clock high, when the clock is going low the next 4 bits are read. For TX the same is done.

An IQ sample contains 48 bits. So when running 48K sampling rate the flow of data from FPGA to the RPI is :

48000 * 48 bits = ‭2.304.000‬ bits per second per channel is 576.000‬ nibbles per second. The rx clock rate must be 288 KHz.

Running 4 receiver channels running at 48KHz the rx clock rate is 1152 KHz.

So when running 2 receivers it is possible to run 96KHz.

Pretty amazing that the raspberry pi is able of making this all possible, all handled by the CPU, not only reading GPIO data but also packeting the data into ethernet format and doing the DSP and showing spectrum.

Running 2 receivers at 192K is also possible when running the SDR program on a seperate computer. This type of configuration was never intended but nice to have!

This all can be further improved. How can this be done:

For TX the data rate is 48KHz; this can be handled by the SPI port; making an additonal 4 bits available; this will double the speed!

Iam not interested to do this, maybe there is a volunteer who likes to learn verilog an some c programming.

Happy with 4 RX channels for skimming use like SPARK SDR, with the possibility of virtual receivers.

You like to handle the total process as smooth as possible; hereby a little insight.

In the flow there are some sync points; the gateware is informing the raspberry pi that there are RX samples present. The firmware is polling if these samples are present using another GPIO pin. When the firmware is polling and there is no data available the process will sleep for a while before polling again.

here a fragement from the firmware code:

while ((((*rpi_read_io) >> 25) & 1) == 0) { usleep(rb_sleep); }//wait for enough samples

This is asking for an improvement, which is already on the wish list for a long time.

Can this be solved? Yes it can.

The firmware is running @linux distro, raspbian linux for the raspberry pi. Linux is running in so called kernel module processes and the apps are normally running in the so called userspace. Everyone programming for microcontrollers is aware of interrupts; linux does support this also.

In userspace it is as far as i know not possible to handle interrupts. Making a device driver for the radioberry which runs in the kernel makes it possible to react on the interrupts, like there are RX samples available.

Getting knowledge for making kernel modules, i advice to read ldd3.pdf (linux device drivers) a free e-book; really a 'must' read!!

As stated for the radioberry project, learning by doing is made an intial driver; still without the interrupt.

After having a first device driver available i started learning about the new way the linux system is configuring the drivers. They are using the so called device tree structure (dts). It describes the system configuration and the device driver is

I did add an initial dts for the radioberry; in folder /boot we can now add in the config.txt the following magical lines:

dtoverlay=radioberry

When booting the system the linux system does load the kernel module for the radioberry; during the load the gateware code is loaded into the FPGA.

Also did implement the IRQ handling.

again hereby a fragement from the firmware code (using the device driver) :

read(fd_rb , rx_buffer , nr_samples);

using blocking read; the waiting is now handled by the kernel; where it belongs!

For most users the question stands and what is now possible with the radioberry? how many receiver channels and sample rate can i use....

as always when running on a multi purpose system ....

all depends of course whith other tasks are you running at the rpi; as said the rx stream is coming with a CPU load!

https://groups.google.com/g/radioberry/c/_Ub2KMf0XCU gives some performance figures.