Experimental upgrade Raspberry CM4 to a Radxa CM5

[ct1iqi]

For those that like to experiment with embedded software and Compute Modules I'd like to report some recent results with an upgrade inside the G2.
Replaced the Raspberry CM4 module by a Radxa CM5 in a G2 w.o. control front. The CM5 features a Rockchip rk3588s2 System-on-Chip in 8 nm technology. Details: https://radxa.com/products/cm/cm5
The CM5 that I bought has 8 GB RAM and 64 GB eMMC memory. Together with a development IO board for the CM5 and a heatsink the investment was about 120 €. (see photos). Reduced the heatsink size and glued it directly onto the SoC in view of the heatsink's four screw inserts not being compatible with the screws used in the G2.
The integrated eMMC storage makes the use of the SDcard obsolete. Mechanically the CM5 is compatible with the Raspberry CM4; it has three 100 pin connectors though; the third, along the short side, remains unused on the G2 Saturn board. A negative is that the CM5 does not provide WiFi; I don't use the G2's WiFi though and of course it can be added back via USB.
Time from power-on to internal Pihpsdr ready is now under 17 sec. Two receivers in parallel, each at 1.536 Msamples/s, load the 8 CPUs to about 20% of maximum.
To create the OS I have used the Armbian build system with a recent Linux 64 bit kernel 6.11.0-rc3. The xdma driver, needed on the Saturn board and not in standard Linux, is patched into the source before compilation. The optimum use of the Graphical Processing Unit inside the rk3588s2 'Mali G610' is still an area of experiment but these first results with the CM5 are encouraging. Further info on request.

cm5_set.jpg (220.93 KiB) Viewed 18366 times

cm5_in_G2.jpg (118.2 KiB) Viewed 18366 times

[Trucker]

I have wondered if there would be a way to upgrade to the CM5 if it ever becomes necessary. This sounds like the answer is yes if someone is willing and able to do the necessary work to make it happen. I wonder how much more difficult it would be with the radios with a front panel?
Thanks for sharing.
James
WD5GWY

[ct1iqi]

@WD5GWY
The front panel with LCD and knobs is just another control input, and video output, as seen from Pihpsdr running on the (Rpi) CM4 or (Radxa) CM5.
It is sufficient to compile Pihpsdr with the GPIO option active in its Makefile and it will 'see' the front panel.
The bulk of CPU work is related to the massive floating point number calculus done in the WDSP library, but ONLY when the embedded Pihpsdr is used.
To get audio, show a S-meter, show a spectrum etc. is all very calculus intensive. Each of the 8 CPUs in the rk3588s2 has its own floating point calculus unit in hardware, they all run a bit faster, so the rk3588 offers significant extra compute power. Using Pihpsdr embedded in the G2 is obviously the intention for a G2 with control front. My use case, a G2 with just the power switch at its front, is in that sense a bit unusual use case, but functionally equivalent to your version with controls. I just use the G2's HDMI output to feed a separate LCD screen, and its USB to control Pihpsdr from a DJ midi device with two tuning wheels, and from CAT. From a software point of view the two use cases are nearly identical: the G2 runs stand-alone. The G2s with the black face are delivered with the software set to start p2app as default, and not pihpsdr. I changed that so that pihpsdr starts i.s.o. p2app.
Upgrading the Compute Module is not that useful when the G2 is controlled via LAN from a program like Thetis on another computer, or, again, Pihpsdr but on another computer (it can do both). The p2app that is activated in case of LAN use merely forwards data between LAN/WiFi and xdma, reshuffling a bit the data to merge and separate signal data and control data, but without any signal processing being done. A CM4 easily handles that. A CM5 will then only bring a shorter switch-on waiting time.

[Trucker]

Thank you for the detailed information. I am still undecided about purchasing a G2 Saturn Ultra mostly for other reasons than the hardware itself. I have a 8000DLE that I enjoy quite a lot. But, new hardware always attracts my attention. From all the reading I have done I was not sure what kind of life expectancy the CM4 module may have. And since the CM5 is so new, I was not sure how difficult it would be to replace the CM4 with a CM5 should it become necessary.
With your comments, it seems it is certainly possible to do.
James
WD5GWY

[n1gp]

@ct1iqi

Tnx for the heads-up on the Raxda CM5. I had tried the BPI-CM4 (Banana-Pi)
and it works at about the same horse power as the rPI CM4, but only has
1 HDMI port. I think this Raxda only has 1 HDMI port as well, not that that is
even an issue.

I wonder why you had to chisel the heatsink down, "Reduced the heatsink size and glued it directly onto the SoC in view of the heatsink's four screw inserts not being compatible with the screws used in the G2".

How were the four screw inserts not compatible? Could you have used the screws that came with
the heatsink, seems like they line up with the holes?

Curious where you bought this from, arace.tech?

I'm torn waiting for the official rPI CM5 (maybe first half of 2025?).
I have an rPI5 and I can also get 2 piHPSDR 1536Ksps running on that over network
so it seems the official CM5 will be a substantial upgrade if it remains pin compatible.

Tnx again for letting us know.

-Rick / N1GP

NOTE TO OTHERS: This is not the official rPI-CM5

[w-u-2-o]

Well done! Outstanding! I was waiting for someone to do this. The CM4 is barely adequate, especially if running piHPSDR. If I had a G2 (which I don't) I would have done the same already.

This is probably worth a more detailed write-up so that others might do the same more easily.

[ct1iqi]

@N1GP
two reasons for cutting back and gluing the heat sink:
1. while the position of the heat sink screws is exactly right, the metric screw size is much smaller than that of the nylon screws that the Saturn board applies.
The tiny screws that come with the heat sink don't have the length to reach through the Saturn PCB. They allow fixing the heat sink against the CM5 but in that case nothing other than the two 100 pin miniature connectors keep the CM5 in place, a CM5 heavier than before due to its heat sink.
2. Radxa supplies the heat sink with a small rubbery heat conductive slab, to be put on the SoC, that will keep the heat sink 1-2 mm above the other components.
Prefer the heat resistance that a thin epoxy glue layer provides, plus not having to balance the 4 screws to not let the heat sink tilt, and to have the CM5 being secured in place and in the connectors by the nylon screws. Basically the way the original CM4 was mounted as well.

Indeed the CM5 has the HDMI-0 connected and HDMI-1 not. The rk3588s2 SoC has two digital video outputs and for each output it is either HDMI or DisplayPort.
On the CM5 output 0 connects for HDMI and output 1 for DP. CM5' DP connects to connector U443 on the Saturn board for connection to an internal screen. Have not yet verified the functionality of this DP since I don't have a separate screen with DP interface and my G2 has no screen, but is would appear to be standard functionality. DP is also on the Radxa IO development board.

Supplier was indeed arace.tech

[n1gp]

@ct1iqi

Tnx for the info.

I just ordered one with heatsink from arace.tech

Are you willing to share your Armbian image for it? I have the G2
with Front Panel + Display.

I notice Radxa's image is based on a 5.10.x kernel.

[laurencebarker]

Well done! Outstanding! I was waiting for someone to do this. The CM4 is barely adequate, especially if running piHPSDR. If I had a G2 (which I don't) I would have done the same already.

This is probably worth a more detailed write-up so that others might do the same more easily.

Barely adequate? For anyone using Thetis it provides full sample rate data transfer. Why is that barely adequate?

For those running piHPSDR, we can easily operate dual RF with sample rates at 384KHz. I think we have had dual RF at 768KHz and single RX at 1536KHz. Yes that could be improved on; but again I would question "barely adequate".

I'm all in favour of finding improved performance; but why the need to belittle the current solution?

[w-u-2-o]

My apologies, Laurence, but the CM4 is working hard, and the full capabilities of the RF subsystem cannot be fully realized as you describe. Indeed, some potential piHPSDR users might even describe that as "inadequate", particularly those used to Thetis on prior Apache hardware.

The good news is that the Radxa is a relatively inexpensive upgrade, and given the ubiquiti of the Pi compute module ecosystem, undoubtedly there will be other choices in the future a well.

[Trucker]

Laurance,
I must have missed something.
From the G2 Saturn manual:

piHPSDR will make the best use it can of the available processing on the Raspberry pi. 96KHz with one receiver or 48KHz with two receivers are the recommended sampling rates. If the rate is set too high gaps may appear in the audio stream.


I have figured that statement was accurate. Has something changed since the manual was posted that allows for more bandwidth for two panadapters running at the same time in PiHPSDR?
James
WD5GWY

[ct1iqi]

@N1GP
sure, I'll inform you where to download.

[laurencebarker]

My apologies, Laurence, but the CM4 is working hard, and the full capabilities of the RF subsystem cannot be fully realized as you describe. Indeed, some potential piHPSDR users might even describe that as "inadequate", particularly those used to Thetis on prior Apache hardware.

If you are using Thetis: Saturn with p2app achieves equivalent performance to previous generations of Apache hardware; and it uses about 10% processor loading. You have full access to the same sample rates across the 4 DDCs that previous hardware provides. Saturn does offer 10DDCs; it awaits DSP clients that can employ them. That's been that way for around 9 months.

And the manual is way out of date for performance with piHPSDR: I don't think Abhi has released the current update but 2 RX @768KHz can be achieved.

And we are working, slowly, on further upgrades.

[laurencebarker]

dual RX @768KHz screenshot attached.

dual rx.png (392.3 KiB) Viewed 18103 times

[Trucker]

Thanks Laurance for posting the photo. It looks like things are improving with PiHPSDR. What kind of difference it makes opening a second spectrum display? Do you have to decrease the bandwidth of the displays? Or can the CM4 handle the extra load without problems such as audio dropouts as mentioned in the manual? That would be a big improvement if it can sustain the data rate without problems.
James
WD5GWY

[dl4zbg]

Hello Laurence,

as far as I remember (from my discussion with Christoph), there is still no audio stream available (on the phones and speaker) for both receivers simultaneously. This is not very helpful while working split. Is this possible with CM4 or is a future CM5 needed to provide this functionality?

73

Volker

DL4ZBG

[laurencebarker]

That's not a CM4 vs CM5 issue: it would need to be coded. As far as I know, piHPSDR doesn't have that code yet. It might mean that the sample rate had to be reduced; I don't know by how far.

And don't get me wrong: more processing is always welcome.

[ct1iqi]

Screenshot via VNC of my G2 with Radxa CM5, running two receivers at 1.5 Msamples/s each, one tuned on 20 m. and the other on 15 m. band.

Screenshot_G2_w_Radxa_CM5_ws.png (1005.26 KiB) Viewed 17690 times

Total load average of all processes running, including the vnc server, is at around 2.5 out of 8 (source: 'htop'). I modified Pihpsdr to show a bit more info on the large external screen that is connected to the G2 via HDMI.

As far as audio from the second receiver is concerned it is my understanding that this audio is available in principle but is only used by Pihpsdr in diversity reception, where the two audio streams are subtracted. Where would you want to send the two sound channels? Left right separated, superimposed? It won't make any substantial difference on CPU load but is more a matter of making it controllable in an ergonomic and transparent way. Perhaps worth its own forum topic on how to structure this.

[dl4zbg]

Christoph wrote me, that both audio signals shall be available at an external audio device (RX0 and RX1). A bigger audio buffer should be needed for routing to headphones and speakers which might increase latency.

My suggestion for a simple solution without an internal mixer (like we have in Thetis) would be first RX to the left and second RX to the right side.

73

Volker
DL4ZBG

[w-u-2-o]

Screenshot via VNC of my G2 with Radxa CM5, running two receivers at 1.5 Msamples/s each, one tuned on 20 m. and the other on 15 m. band.

Very cool! Again, well done! Apache should consider offering this hardware upgrade in future G2 shipments.

As far as audio from the second receiver is concerned it is my understanding that this audio is available in principle but is only used by Pihpsdr in diversity reception, where the two audio streams are subtracted.

"Diversity", as defined in the openHPSDR world, is the summation of two baseband IF data streams in order to achieve two-element beamforming, whereby the summation is done with a controllable amplitude and phase offset against the reference signal. It is not merely the addition or subtraction of audio waveforms.

Where would you want to send the two sound channels? Left right separated, superimposed? It won't make any substantial difference on CPU load but is more a matter of making it controllable in an ergonomic and transparent way. Perhaps worth its own forum topic on how to structure this.

The answer to this question is to provide the well-proven means of allowing each channel to be independently adjustable in amplitude (volume) and spatial location (pan left/right).

There is no need to do this organically in piHPSDR except that it is more convenient for the operator that way. If both streams came out on different ALSA channels then they could be independently adjusted for volume & pan in the standard Linux ALSAMixer app, which is part of the OS. That might be a good first step prior to implementing an internal audio mixer in piHPSDR.

[ct1iqi]

@wu2o
quite right, subtraction in case of diversity reception is an over simplification; the I and Q are combined while allowing amplitude and phase adjustment. Further processing in WDSP is then done for the one resulting IQ pair. With two receivers active independently, both IQ pairs are processed by wdsp. The audio output of the second rx is available now, but is discarded; (see receiver.c, line 1497). The second spectral display can be shown though. Hence my conclusion that dual audio should not influence CPU load by much.

[JohnFT61]

I see a Raspberry Pi 5 CM has been manufactured. It is available at:https://www.raspberrypi.com/products/compute-module-5/?variant=cm5-104032

They seem to be out of stock now. I wonder if they would work in G2? Even has WiFi!


John
N2kbe

[ct1iqi]

@John, N2KBE
The System on Chip BCM2712 (Rpi CM5) has a lower specification than the RK3588S2 (Radxa CM5) due to latter being octo core and being manufactured in 8 nm technology, opposed to 4 core and 16 nm. The smaller design rule allows for better price/performance and for increased clock frequencies at equal dissipation.

[n1gp]

There's a nice overview of the rpiCM5 here: https://www.youtube.com/watch?v=X4blR5Ua3S0

Here's some highlights on performance and efficiency comparisons, note the Radxa kicking butt:

[JohnFT61]

Installed the Radxa CM5 into my G2 with the original display, with lots of help from CT1IQI. Also, we received help from Laurence and possibly others. A little more involved with the original display, but it works, and the software just needs fine tuning. Martin (CT1IQI) supplied the image file for the CM5. I decompressed it to a MicroSD card, and inserted it into the Saturn board, only for the initial installation. After that, turned the G2 off, and then removed the card. The OS is then on the eMMC memory on the CM5.

Besides the Radxa CM5, one also needs a RP2040-PiZero board, to convert the GPIO data to USB. Of course the board also has to be programmed, which I am told Laurence did the work with that. The 40-pin GPIO cable is removed from the Saturn board, and plugged into the RP2040-PiZero board. I bought a much shorter cable (8 inch), because the original cable is much longer than it needs to be. 4 wires on the P5 10-pin ribbon cable have to be removed (close to the rear panel connector on the Saturn board) and wired into a USB-C Data Connector, which is then connected to one port of the RP2040-PiZero board. Another regular USB charging cable is used to help supply current to the RP2040-PiZero and front panel. I just soldered two wires with the proper female pins on the end, and connected them to pins 2 (+5V) and 6 (gnd) at the 40-pin GPIO connector on the Saturn board. The other end going to the Red and Black wires from the USB-C charger cable.

I used tie wraps to hole the CM5 down, only because the nylon 2mm bolts/washers/nuts I ordered were not right. The washers were too thick, and wouldn't let the CM5 seat properly, and I wanted to get the G2 (with Radxa going)!

Attached are some pictures. NOTE: The picture of the RP2040-PIZero board does not show the second USB-C cable, because I didn't have it installed yet.


73
John
N2KBE

[laurencebarker]

The absolute newest p2app should also work with this, unless the USB serial device comes up at a different address from my radio (which is possible). Christoph is also supporting it in piHPSDR. We do need to do a little more work to finalise the naming of the USB serial devices.

With my RP2040-piZero I didn't get a high enough USB supply voltage for the VFO encoder (which is marginal on 5V). If it doesn't work, or becomes temperature dependent, it may need a 1 wire modification to feed switched +13.8V to the encoder.

[JohnFT61]

@laurencebarker
The absolute newest p2app should also work with this, unless the USB serial device comes up at a different address from my radio (which is possible). Christoph is also supporting it in piHPSDR. We do need to do a little more work to finalise the naming of the USB serial devices.

Thank you for the heads up with the P2_app, it now works on my G2 with the Radxa CM5!


73
John
N2KBE

[n1gp]

@JohnFT61

I don't know if Martin mentioned it, but this carrier makes a nice platform
for your old CM4:

https://www.amazon.com/dp/B0BX9NGNQN

-Rick / N1GP

[JohnFT61]

@N1GP

Thank you for the information. I see it has a GPIO interface on it. I looked at setting up the PC to program the RP2040-PIZero, and it was a nightmare! So many programs/utilities had to be downloaded to program it (not that I would know how to do it anyway). Just curious... I believe the RP2040-PiZero had to programmed in C to get maximum benefit from the GPIO. It is cheap enough!

The only thing I miss when using the Radxa CM5 is the desktop (GUI) for Linux. Now I have to use a second Linux PC with programs like Filezilla, and Putty. It was nice to do everything from the G2. My wireless keyboard with the G2 is lonely. I can still use the mouse.


73
John
N2KBE

[laurencebarker]

I don't imagine you **have** to use C for the RP2040-piZero, but that's the only language I've written code in for 30 years.

I didn't find installing the code for windows a problem; it sailed through in a few minutes. One operation to install the board type, then another (which I have forgotten the details of) to load a timer library. There shouldn't be any more.

That modules costs about $10: so not expensive.