rpi-5 utilization running radioberry

[pa3gsb]

Hi All,

https://youtu.be/v34ROMQqOaA

Enjoy

73 Johan

PA3GSB

[Paulh002]

Looks great! 

Did you already publish the code?

I moved my software to wayland, and can support two screens on the pi 5.

73,

Paul

--
You received this message because you are subscribed to the Google Groups "Radioberry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radioberry+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/radioberry/6d6b8b1e-8fc7-4787-a33c-ba91ba8e09c6n%40googlegroups.com.

[pa3gsb]

Hi Paul and others,

The code is present in the repo so free to use.

I have attached a document radioberry@pi-5 .

In stead of building the software yourself i provide an image you can sell at https://pa3gsb.gumroad.com/l/radioberry

The image is for now only CL025 but i will do the same for the CL016..

Enjoy

Johan

PA3GSB

Op dinsdag 9 september 2025 om 20:36:54 UTC+2 schreef paul.hol...@gmail.com:

[Paulh002]

Thanks,

I tried to build the pio driver but had an issue 

KBUILD_EXTRA_SYMBOLS := /home/pi/git/rp1-driver/Module.symvers

This directory is not found.

To view this discussion visit https://groups.google.com/d/msgid/radioberry/de06fe61-4b6a-4c20-9b0a-74fabb98c83cn%40googlegroups.com.

[pa3gsb]

Paul you are exactly pointed to the issues why i decided to make an image.

As indicated in the attached document:

To build your own setup is pretty hard; the problem you are facing that i have described in the research paper;  i did a PR (Pull Request) to the linux kernel for a modification which is needed when using the rp1-pio driver as a basis for the radioberry driver.

Making a description is not that easy with a lot of individual issues and problems. When the development stabilize i will look into it again.

Iam willing to help everybody but i do not have the time and energy to pull that off.

Enjoy

73 Johan

PA3GSB

Op woensdag 10 september 2025 om 09:17:01 UTC+2 schreef paul.hol...@gmail.com:

[Paulh002]

Looks good 150% Load with wayland GUI (96  Khz samplerate), the old version was 250 % load

Thanks

Paul

On Wed, 10 Sept 2025 at 09:04, pa3gsb <pa3...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/radioberry/de06fe61-4b6a-4c20-9b0a-74fabb98c83cn%40googlegroups.com.

[pa3gsb]

Now also an image for Radioberry using a CL016 FPGA is available.

Op woensdag 10 september 2025 om 13:40:12 UTC+2 schreef paul.hol...@gmail.com:

[Yado-san]

Johan, thank you for your great development efforts.

I looked into the differences between the Raspberry Pi4 and 5.
- Radioberry2(10CL016-board) and SparkSDR(4RX-96k sampling)
- RPi4B(bookworm-64bit)  %CPU 58%
- RPi5 (bookworm-64bit)  %CPU  2%  FB! :)

< RPi5 / RB2(gw75.0_pio-mode) >

< RPi4 / RB2(gw73.3_gpio) >

Tnx!

Yado-san, jg1twp

2025年9月11日木曜日 2:48:05 UTC+9 pa3gsb:

[Rick Koch]

I am seeing similar results here on my RPi5. Tnx Johan!

I would like to test out how the 10rx-cic firmware works, would it be possible to update

the hermes-lite github repo with the 75.0 updates? Currently it is still at 73.3.

[rent...@comcast.net]

Hi Paul,

It has been some time since I played with my Radioberry boards.  I have two, one with CL025 and one with CL016 and a pair of Juice boards as well.  I have s few questions if you would indulge me:

1.  Is it (in your estimation) worth playing with the RPi4 or 5 with the Radioberry over the Juice/Radioberry combination?  I forget what I used on the PC with this combination, Thetis perhaps?

2.  What SDR SW is being displayed in your picture?  Doesn't look like PiHPSDR or DeskHPSDR unless a lot of work was done to customize the program display.  I like what I see in your picture a lot, which is why I am asking.  I looked at the Github pages for both and they look like (more or less) how PiHPSDR looked back when I was playing with it on a RPi 3B+ I think it was.  I am also confused by the two screens, one monitor and one RPi LCD display (I think).  What is driving each one?

I think I have another question as well, but it escapes me at the moment!

73,

Robert, WA2T

[Rick Koch]

I was wrong, the hermes-lite github repo does have the latest 75.0 pio updates.

I was able to build and run it on my rpi-5. I have the cl025 FPGA.

I see that the pio clock was updated from 66.67MHz to 100MHz so the throughput

should be:

Max IQ-sample rate:
100MHz / 75 ≈ 1333333 IQ -samples/sec

which should be able to handle 6×192000=1152000 IQ-samples/sec

again with 15% margin.

I am able to start 6 RX slices @ 192K in Spark SDR and see spectrum on all 6, but I cannot

control the frequency on any. If I limit the slices to 4 all works OK. The FPGA code has NR=6

and I updated rpi-5 firmware radioberry app for "#define NR 0x06"

I wonder if there is something hard coded for limiting the RX number to 4 somewhere else?

[Rick Koch]

It seems that sometimes the rpi-5 setup can't handle more than 4 RX streams,

but I found that if I unload the radioberry.ko module and reload it, then I can

get 6 working RX streams.

It's really not taxing the CPU very much as when running 6 RX @ 192K the radioberry

app is only taking 5% of the CPU.

Johan, is it possible to run the rp1 pio @ full speed (200MHz)?

[pa3gsb]

Rick,

Nice you are experimenting with the new pi-5 setup.

In the study document i mentioned:

I even did change the number of RX slices to 6 for the CL025 FPGA!
Making it possible to run for instance 6 channels @48K for doing wspr on 6 channels. By removing the
TX chain even more RX channels are achievable.(small change required in the firmware NR=4 to
NR=6; but better is to get this from the gateware)

This is still at the backlog. 

Some remarks:

- I think when you only want to listenen you are able to set the TX at 0 and is should be able to have 7 RX channels running (NR=7)

- i have set the PIO speed by experimenting... no possiblity to measure.... still thinking of using an other pi-5 and make a logic analyser using the 200Mhz clock must be possible to measure!

- Using the clock at maximum should be possible but than you need to add some additonal delays in the statemachine.. as said defined by experiment... 

Maybe you are able to measure?

In the driver:

config_args.config.clkdiv = 0x00020000;  => 00010000 for no division; so use 200Mhz
config_args.config.execctrl = 0x5901f680;
config_args.config.shiftctrl = 0x00000000;
config_args.config.pinctrl = 0x40091800;

const uint16_t rx_iq_sample_program_instructions[] = {
    0x80a0, //  0: pull   block
    0xa047, //  1: mov    y, osr
    0xa022, //  2: mov    x, y
            //     .wrap_target
    0x0013, //  3: jmp    19
    0xbb42, //  4: nop                    side 1 [3]
    0x5004, //  5: in     pins, 4         side 0
    0xbb42, //  6: nop                    side 1 [3]
    0x5004, //  7: in     pins, 4         side 0
    0xbb42, //  8: nop                    side 1 [3]
    0x5004, //  9: in     pins, 4         side 0
    0xbb42, // 10: nop                    side 1 [3]
    0x5004, // 11: in     pins, 4         side 0
    0xbb42, // 12: nop                    side 1 [3]
    0x5004, // 13: in     pins, 4         side 0
    0xbb42, // 14: nop                    side 1 [3]
    0x5004, // 15: in     pins, 4         side 0
    0x8020, // 16: push   block
    0x0044, // 17: jmp    x--, 4
    0xa022, // 18: mov    x, y
    0xba42, // 19: nop                    side 1 [2]
    0xb242, // 20: nop                    side 0 [2]
    0x00c4, // 21: jmp    pin, 4
            //     .wrap
};

this is the PIO:

.program rx_iq_sample
.side_set 1 opt       ; 1-bit side-set (clock), optional

; sideset_base = 6
; data ready pin = GPIO 25
; data pins = in_base = {18, 19, 20, 21}



pull block
mov y, osr
mov x, y

.wrap_target

jmp poll_ready

read_sample:

   ; read 6 × 4 bits = 24 bits ; I or Q sample
    nop side 1 [3]
    in pins, 4 side 0 [0]

    nop side 1 [3]
    in pins, 4 side 0 [0]

    nop side 1 [3]
    in pins, 4 side 0 [0]

    nop side 1 [3]
    in pins, 4 side 0 [0]

    nop side 1 [3]
    in pins, 4 side 0 [0]

    nop side 1 [3]
    in pins, 4 side 0 [0]

    push block

jmp x-- read_sample

mov x, y

poll_ready:
    nop side 1 [2]      
    nop side 0 [2]      

    jmp pin read_sample      

.wrap

Hope this gives some input for further experiments!

73 Johan

PA3GSB

Op zaterdag 20 september 2025 om 21:00:50 UTC+2 schreef mr.ri...@gmail.com:

[Rick Koch]

Tnx for the info Johan.

I was able to get the config_args.config.clkdiv  = 0x00010000;

working at 200Mhz

I have no logic analyzer, but your idea for using another rpi-5 sounds interesting!

As you indicated, it tooks some experimentation to find some delays that worked.

Here is what I came up with:

static const uint16_t rx_iq_sample_program_instructions[] = {

    0x80a0, //  0: pull   block
    0xa047, //  1: mov    y, osr
    0xa022, //  2: mov    x, y
            //     .wrap_target
    0x0013, //  3: jmp    19

    0xbf42, //  4: nop                    side 1 [7]

    0x5004, //  5: in     pins, 4         side 0

    0xbf42, //  6: nop                    side 1 [7]

    0x5004, //  7: in     pins, 4         side 0

    0xbf42, //  8: nop                    side 1 [7]

    0x5004, //  9: in     pins, 4         side 0

    0xbf42, // 10: nop                    side 1 [7]

    0x5004, // 11: in     pins, 4         side 0

    0xbf42, // 12: nop                    side 1 [7]

    0x5004, // 13: in     pins, 4         side 0

    0xbf42, // 14: nop                    side 1 [7]

    0x5004, // 15: in     pins, 4         side 0
    0x8020, // 16: push   block
    0x0044, // 17: jmp    x--, 4
    0xa022, // 18: mov    x, y

    0xbc42, // 19: nop                    side 1 [4]
    0xb442, // 20: nop                    side 0 [4]

    0x00c4, // 21: jmp    pin, 4
            //     .wrap
};

Initial testing indicates I can run 6 RX @ 384K which seems to coincide with

the available bandwidth 200MHz / 75 ≈ 2666666 IQ -samples/sec?

I'm not sure if it is still using 75 PIO cycles for reading IQ Sample?

[pa3gsb]

Rick

Your last remark is indeed true.

A nop statement with an additonal delay of 7 makes 8 cycles for the clock of 200MHz.

an in is 1 cycle.

after 6 in ; we have 24 bit of an I or Q sample.

which is push into the FIFO for another cycle. doing jmp also 1 cycle.

So your testing of a working 6RX slice receiver can't be true. 

Improvements :

= The in direcive must be using conscecutive pins ; so for 8 pins would be nice

= the push can be replaced by an auto push

= using DDR as done for the rpi-4

= continues reading iso of blocks of 80 samples...

So increasing the clock means also adding additonal delay cycles for getting a good timing....that is why i like a good logic analyser to what the max bandwitdth is for rpi + rb  ; i think a good

balanced pcb design can do much good.

So very much design considerations to get the max out of the system; but i do like to have io via pcie and offloading it from the CPU.

Also keep in mind DMA setup and hanling is also not free.

Maybe there are others who are having ideas to get the max throughput?

73 Johan

PA3GSB

 

 

Op maandag 22 september 2025 om 13:02:54 UTC+2 schreef mr.ri...@gmail.com:

[Mario Vano]

Thanks for all the new work, Johan!

I'm trying the preview image right now on one of my rigs and it works great - very low CPU usage. I can't wait for the patch to be rolled into the kernel so we can use a standard system. Are you testing with "trixie" yet?

So far I've only found one tiny complaint... It appears to me that the DMA or some other portion of the process is running at exactly 25 MHz. This seems to put an ENORMOUS signal with several sidebands into the Radioberry around the bus pins. It makes 12 Meters nearly unusable. I wonder if anyone else is seeng this, or it's unique to my layout?

If it's not just me, I wonder if there's any chance it might be moved somewhere else where it isn't in a Ham band. Even up a few hundred khz would be good... I realize the details of the transfer loop are not finalized yet.

I only reporting this because I think we're supposed to be testing this like a beta and looking for problems. I hope this is useful.

Mario, AE0GL

[pa3gsb]

Mario,

Tnx for your report. Iam still in house renovation project and not able to measure at this moment.  Iam also interested if others are also seeing this behaviour.

Iam a bit suprised by the statement exactly 25Mhz... we need to figure out where this signal  comes from.

a canidate is the pi-tx-clock (https://github.com/pa3gsb/Radioberry-2.x/wiki/Radioberry-In-Output)  but i do not understand the 25Mhz ...

the frequency of the pio is 200Mhz divided by 8 and than in the loop are 6 cycles which makes around 4 Mhz ; so no harmonic relation with 25NMhz.

The pi-rx-clock is as far away from the analog input side... but the pi-tx-clock from the pio is more close to the frontend of the radio.

I will look into it and i need some weeks to finish the house project.

The code in the image is the working code from the develop branch of the raspberry pi linux rep ; begin september i created the image.. so i think most of the trixie version based code is used already in the image. Use the commang uname -a and you will see that the image is pretty new.

Enjoy 

73 Johan

PA3GSB

Op maandag 13 oktober 2025 om 21:08:49 UTC+2 schreef mpv...@gmail.com:

[Mario Vano]

Hi Johan, I hadn't considered that it might be normal Pi 5 behavior, so I decided to run another test I installed the Pi5 Radioberry SDCard I had been using on this radio and tried the same thing. I found a very no of a 25mhz spur at all - the faint carrier visible is WWV on 25 Mhz..

I then reconfigured the radio with your new image and setup the piHPSDR to use the same 96khz sample rate as was working on the released version. I also confirmed that the piHPSDR resolution and basic HDMI resolution on the Pi was the same as on my original SDCard. The spurs in question were very strong and clearly visible.

Here are screen shots of the two. The one names spurs.png is from the experimental image.  The one marked nospurs.png is from my original Pi 5 version using the old non PIO driver.

nospurs.png

spurs.png

There are, of course other differences in the configuration and systems installed, but I think they're pretty close. RF gain variations didn't make much difference and both shots were taken this afternoon about 15 minutes apart on the same hardware.

Hope this is useful information...

[Mario Vano]

I just noticed that the new image picture was taken with the mode inadvertently set to SAM instead of USB. This apparently made no difference to the spectrum and waterfall displays in the screen captures except that the width of the visible bandwidth highlight is different. Switching back and forth made no difference...

M

[David Cooley]

200mhz divided by 8 is 25mhz

Get BlueMail for Mobile

To view this discussion visit https://groups.google.com/d/msgid/radioberry/9c202af2-0428-4367-a834-3b668865b0b7n%40googlegroups.com.

[pa3gsb]

Mario 

I only started the radio without measurement. Iam using an CL025 based RB-2 

Iam using a rpi-5 with a nvme drive.

You see in the picture no spurs at all.

Are you using a CL016 based RB-2?

73 Johan

Op woensdag 15 oktober 2025 om 02:00:26 UTC+2 schreef daco...@gmail.com:

[Mario Vano]

That's what I was afraid of...

All of mine are CL016. I suppose I could try swapping out the chip.

My boards are assembled with through pins on the GPIO so other things can be stacked with them. In particular, I have an LPF filter that stacks on top of the radioberry this way. It only uses the 3V, Gnd and I2C pins. All the rest are not connected to anything.

It's possible the extra pin lengths are to blame. I suppose the unused pins could be cut short if needed, without changing what I'm trying to do...

I'll run some more experiments. I have one board from China that has no through pins and I'll see what happens with it. It's an older version board, however.

I'll report back once I've tested all possible permutations. I'm not too excited about changing out the FPGA, but I'll probably get around to it, since I've been meaning to try one for a while...

thanks for your time Johan....

M

[Mario Vano]

OK, I found that at maximum gain on a configuration with only the Pi 5 and a properly working board from AliExpress (earlier rev)that the pio clock was still visible, but at a very low level - about 6 db above the noise, and none of the sidebands were visible. Since the PIO clock is NOT in the ham band, and the level is so low, I think this is a non problem for the Radioberry design...

I did find that it was getting into my LPF board via the extended GPIO pins. A simple shield between the GPIO pins brought them down to a manageable level. I'm sure that just cutting off the unused GPIO pins sticking up from the connector on my board (or a proper shield) will fix the problem on my configurations completely.

Sorry to cry "wolf"!

Please keep us posted on any word on the patch being accepted. The fix for the last major problem like this in the kernel (with the I2C IO drivers) took nearly a year to make it into the release. I hope we don't have to wait THAT long!

thanks again for all your work!

[El Calvo]

This is amazing. Great work on the driver.

Juan WP3DN

[pa3gsb]

Juan

 Your rpi-5 processor power is now there for you for doing other things than retrieving data from the radioberry card....

Tnx for sharing.

73 Johan

PA3GSB

Op maandag 27 oktober 2025 om 03:18:32 UTC+1 schreef 3vol...@gmail.com: