Radioberry performance test

[j.g.ho...@rug.nl]

Hi all,

I did a lot of tests with my radioberry please read below.

Both programs pihpsdr and linhpsdr are performing very well but there are also some drawbacks when using four receivers.

My test was done with a two setups and well  with the complete raspberry Desktop install and one with bare minimum and only with Xserver and a Xterminal all software installed on the rpi4 with 4 Gb of ram.

 

It takes me some time to find out the problem when using a fresh pihpsdr-master, here it is important to know that we must comment out in the Makefile  GPIO_INCLUDE=GPIO GPI and in the RPI configuration  set interfaces   SPI, I2C to disabled.

For other resolutions then 800 x 600 you can change this in the main.c 

To use four receivers I installed linhpsdr on the raspberry, screen size 1024 x 600 pixels compiled for my tft touchscreen display for linhpsdr with four receivers it will not fit on this size of screen in this case I used a standard monitor.

Test 1 pihpsdr full desktop 1024x 600 :with two receivers,

Sample rate at  48000  2 receivers perfect

Sample rate at  96000  2 receivers perfect

Sample rate at  192000  2 receivers sometime random sequence errors or  when changing quickly the frequency and distortion in the audio

Test2 pihpsdr full desktop 1024x 600 :,

Sample rate at  48000  2 receivers perfect

Sample rate at  96000  2 receivers perfect

Sample rate at  192000  2 receivers sometime random sequence errors or  when changing quickly the frequency and distortion in the audio

Sample rate at  96000  3 receivers perfect

Sample rate at  96000  4 receivers random sequence errors and distortion in the audio

Sample rate at  192000 4 receivers  a lot of sequence errors (not really usable) and distortion in the audio

My conclusion is that the RPI4 has lack of CPU power for 4 receivers with sample rate at 192000.

Further I can say that my radioberry works awesome with two receivers and I am very happy with the tiny big radio.

Now the device driver is working perhaps it's time to use my ODROID-N2 Amlogic S922X SBC with 4GB RAM

https://mega.nz/file/T7pl1bqS#R-639xutMN404WBC384uEbFNMld9tFAeiyzgroq3L9M

Thank you Johan Maas for all the work you did for the radioberry and recently the device driver. 

Best regards,

 Johan Holstein

[Steve Haynal]

Hi Johan,

Have you tried Quisk or SparkSDR? I saw similar results to yours with linhpsdr and pihpsdr, but no audio drops or crackles with Quisk or SparkSDR even with 4 384kHz receivers. See:

https://groups.google.com/d/msg/hermes-lite/At-Olx59LBA/1e4tgxOQCAAJ

I am using a Hermes-Lite 2.0, so the up to 1 Gb/s ethernet interface is different. It would be interesting to understand if you do or do not run into radioberry interface bandwidth limits when running 4 receivers at 384kHz with Quisk or SparkSDR.

73,

Steve

kf7o

[pa3gsb]

Hi Steve and Johan,

Iam currently quite busy.....

but iam working on a small document about the dataflow used in the radioberry....

adding some tests using different software packages is quite a good idea.

73 Johan

PA3GSB

Op woensdag 8 april 2020 06:41:28 UTC+2 schreef Steve Haynal:

[pa3gsb]

Hi All,

Found some time to say something about performance and the radioberry; happy reading!

Radioberry performance

I like to describe the radioberry data flow/stream to gain knowledge about the internal working of the radioberry.

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 a wonderfull device to reduce the data flow.

The FPGA program, called gateware, is responsible for the data flow reduction. 

The gateware, actual a raw binary file (rbf) is the product of the RTL process,

executed by Intell's Quartus free tool. 

The gateware program must be loaded, after each power cycle into the FPGA.

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

Besides using the GPIO pins for the RX and TX data streams these pins are used to upload the gateware into the FPGA.

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. 

For all the receiver channels the same data rate (sample rate) is used, as a result of the openHPSDR Protocol-1 description.

Using the openHPSDR protocol-2 it is possible to use different sample rates per channel.

The radioberry is using the P-1; an hermeslite-2 gateware variant.

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

Getting to some detail of the internals of the radioberry.

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.

Is that all, no there is more:

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

(may be to detailed; but i found it important to describe it; and of course you are having a free will) 

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.

That is what i have done the last weeks, reading 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!

TODO measurements?

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!

In previous posts some indication is already given.

Hope this give some background!

73

Johan

PA3GSB

[Steve Haynal]

Hi Johan,

Thanks for the detailed explanation. My conclusion is that the max data transfer rate with your scheme is very dependent on the CPU load as the CPU is managing all transfers in real time, and not on any physical pin toggle rate limitation. Is that a correct conclusion?

One solution for this type of performance limit is to use dedicated hardware with DMA. For example, when using ethernet there will be dedicated hardware to handle ethernet packets in real time to reduce the CPU load. Here are a few ideas just for people to consider:

** The Raspberry Pi has a Secondary Memory Interface which is very similar to old ATA-IDE. See https://www.raspberrypi.org/forums/viewtopic.php?t=208074

** The Raspberry Pi has a MIPI interface to receive camera data. This can be repurposed for other high bandwidth data. I've been following this thread:

 https://twitter.com/claude1079?lang=en

He discusses using a different driver/library for generic data.

73,

Steve

kf7o

[pa3gsb]

Steve

Tnx for your reply.

This is exactly the develeopment line i have in mind. Doing things step by step, do and learn!

The following step is indeed looking into DMA. See what that is bringing.

But ulitmately i have in mind  using MIPI interface, tnx for the link, i did already created verson 3 of the radioberry..... using this MIPI interface. 

Hope this is a challeging idea!

73 Johan

PA3GSB

[pa3gsb]

Hi All,

Also showing here some figures running the radioberry firmware together with the latest kernel driver:

- linux raspbian  kernel version: 4.19.97-v7l+

Running pihpsdr with wdsp library:

1 rx 48K

2 rx 48K

2 rx 96K

1 rx 192K

Pretty good using the bit banging method.

I started the radioberry with a rpi-2; using the SPI bus for offloading some work of the CPU. The introduction of the RPI-4 is a real big improvement for the use with the radioberry.

I did also do an initial soapy implementation; only rx and 48K. So loading the kernel module; and start pihpsdr. 

Iam running pihpsdr from the forked repo of Christoph dl1ycf:

soapy discovery

soapy rx

1 rx 48K

In the early days of the radioberry i made a special radioberry protocol to achive this idea; running standalone! Now the soapy protocol is there to attach your SDR radio!

Hope this will give you some insight about the latest work!

73 Johan

PA3GSB