Radioberry SDR radio meets RP2350.

[Radioberry]

Hi all,

I have been doing some early development work on a new RadioBerry-related hardware initiative.

It is still in a very early stage, so it is not ready to share in detail yet, but I would be interested in hearing your thoughts.

The idea is to create a new module around the RadioBerry Hub 2350, an RP2350-based Ethernet and control board for the RadioBerry ecosystem.

At this stage, I am mainly looking for feedback:

• Is this the kind of development you would like to see?
• What use cases or projects would you imagine for this board?
• Would you see it mainly as a Raspberry Pi replacement for RadioBerry SDR, as a standalone radio platform, or as a general control hub for radio applications?
• Are there specific features or expansion options you think would be useful?

Please let me know what you think. Your feedback would help shape the next steps of the project.

73,

Johan PA3GSB

[Ricardo Suarez]

Nice! 

Black box ahead!

Rick LU9DA

--
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/2caee922-5e27-4500-a7be-5802c4e883b8n%40googlegroups.com.

[Ed Marciniak]

An audio codec would be highly desirable. I think it would be highly desirable to have io expansion sufficient for a control panel.

Ideally, such a board would have a couple of encoder inputs and a header connector that could go to a pcb to provide a radio like front panel.

I have a Radioberry (CL025 variant)and juice pack

I have an earlier model BladeRF as well as a Carribou SDR

I have an ANAN-100D

I have a flex-1500 used exclusively for 10GHz portable station (I have no backup 10m radio for that portable station). It’s SDR or bust.

I seem to keep deferring buying a PlutoSDR of one or another model

I’ve been tinkering with SDRs since the days of the KB9YIG softrock RXTX 6.3 using an Si570 as the local oscillator. With some modifications, and a high end ADC I can hear a -131 to -135dbm tone swept through audio passband and ADC clipping starts around 1V or +6dbm at ~20 MHz.

What, precisely is needed in my humble opinion is an SDR that doesn’t suck.

While some of us may desire to experiment and roll our own without hope of saving money….if the obvious pieces cost more than a certain amount in total, it seriously discourages the desire to experiment.

One specific use case I have in mind should have they following features to make an effective microwave IF for portable operation:

Not cost more than IC-7300 or IC-705

A 10m/2m or both for RF input 

No more than +10dbm out if a pin is strapped (it is ok to be capable of more for linearity, but unacceptable to allow the risk of potentially blowing expensive mixers or modules that might be hard to replace after surplus dries up)

Onboard audio codec capable of driving headphones plus a line out jack, must also contain a mic preamp that will work with an electret and provide 5V phantom power to same as well as allow something like a Heil (dynamic) mic element. The onboard codec is desirable because it allows avoiding fractional sample rate conversion and works out cleanly for HPSDR type protocols

Buffered inputs for PTT,

A physical control panel providing, so a screen is optional rather than mandatory

A VFO knob, volume, AF gain control, squelch and preferable RF gain control knobs

Filter selection buttons

MOX button

Mode select for SSB/CW/FM either two buttons and LEDs or a switch with detents to be marked

Provisions for band switch up/down and LEDs to show band selected

Noise blanker buttons(2)

In general be amenable to interfacing with Thetis, PowerSDR mRX PS variants, speaking HPSDR protocol

Desirable: a 2^nd vfo knob

LCD/LED display of tuner frequency

Filter center frequency and bandwidth knobs

An optional 2m transverter

Desirable would be a board accepting a 10MHz input, or a pulse per second from a GNSs receiver putting out a 76.8 MHz to drive the radioberry and a quadrature pair of LO signals to drive an image reject mixer to convert a 144-148 MHz signal down to a suitable frequency for the radioberry.

Since portable operations frequently include a laptop for logging, and that laptop can usually support an SDR, a pi isn’t mandatory.

This distills down to a radioberry, expansion board, audio codec, and provisions for some sort of control panel. Together with a 5” display and a pi to drive it the whole stack shouldn’t cost more than maybe 750 USD shipped.

At this point a control panel that doesn’t require a pi+ 5” display and gets produced regularly enough that you can order one from somewhere like crowd supply is a headache.  I’d even settle for one that did require a pi plus display that was orderable than something someone did one or two group builds on.

An interesting question is whether a 5” display could be driven by a second RP2350 board with Ethernet for a spectrum/waterfall display. The SDR software could certainly have its spectrum output exported in Ethernet frames alleviating the processing.

What that  would simplify an Ethernet juicepack replacement using an RP2350 to for asks:

header for control panel interface

audio codec

Mic preamp with a jumper to add phantom power  to work with dynamic or electret mic(optionally line input)

Headphone and line outputs

Buffered PTT, key/iambic inputs

A Christmas wishlist item would be to have a 10MHz oscillator with a footprint amenable to a VCXO, an optional pulse per second input, and to generate 76.8 MHz, 25MHz Ethernet clock and a quadrature pair for a 2m transverter. Perhaps having dual footprint pads where optional parts can be populated at the expense of a square inch or two of PCB area is a way to make everyone happy.

73,

Ed Marciniak

NB0M

---

From: Radioberry <radio...@googlegroups.com>
Sent: Wednesday, 17 June 2026 12:10:16
To: Radioberry <radio...@googlegroups.com>
Subject: Radioberry SDR radio meets RP2350.

 

[Ed Marciniak]

A TX inhibit input that facilitates using a sequencer would be highly desirable as CW inputs frequently key PTT which complicates hardware enforcement of sequencing without it.

---

From: Radioberry <radio...@googlegroups.com>
Sent: Wednesday, June 17, 2026 12:10 PM

To: Radioberry <radio...@googlegroups.com>
Subject: Radioberry SDR radio meets RP2350.

 

Hi all,

[Paulh002]

Very nice, it would be nice that the board would also support SoapyRemote. There is no soapy driver for hpsdr protocol. 

Other option is to implement usb otg, like the Pluto. To connect to radioberry through usb. 

Op wo 17 jun. 2026 19:10 schreef Radioberry <radio...@googlegroups.com>:

[pa3gsb]

Hi all,

Thank you for the responses and ideas.

I would like to clarify what I am hoping to achieve. I am not planning to lead a formal development project, define a roadmap or assign tasks.

Instead, I would like to find two or three people who enjoy experimenting independently with hardware and software. The idea is to connect the Hub 2350 to a RadioBerry, explore what can be built with it, and share code, hardware designs, test results and discoveries with each other and the wider RadioBerry community.

The first prototype already connects to a RadioBerry and runs OpenHPSDR Protocol 1 in RX-only mode using the RP2350 PIO interface.

A possible direction is something similar in spirit to uSDR-pico:

https://github.com/ArjanteMarvelde/uSDR-pico

—but based on the RadioBerry SDR. This is only an example, not a fixed project specification. Everyone is free to explore their own ideas, whether in firmware, radio control, audio, displays, physical controls or other hardware.

I have two or three prototype Hub 2350 boards available for people who genuinely want to experiment with them. There is no predefined task list or obligation to deliver a finished product. I only ask that participants openly share what they make, learn or discover so others can build on it.

If this kind of open experimentation appeals to you, please contact me and briefly mention your experience and whether you already have a RadioBerry.

After sending this message, I will be off-grid for approximately two weeks. Please feel free to respond in the meantime; I will read and answer your messages when I return.

73,

Johan PA3GSB

Op woensdag 17 juni 2026 om 21:27:20 UTC+2 schreef paul.hol...@gmail.com:

[pa3gsb]

i forgot to attaced the schematic...

Op donderdag 18 juni 2026 om 08:26:44 UTC+2 schreef pa3gsb:

[Paulh002]

Take a look at this repo https://github.com/kelu124/pic0rick

The use a rp2040 with an 60 Mbsp ADC

To view this discussion visit https://groups.google.com/d/msgid/radioberry/a3aa944f-8dd8-4f08-9559-15f329be99dbn%40googlegroups.com.

[Frank Seidinger]

Dear Johan,

there are two main ways you can go with further development of the Radioberry Platform. I will make two main suggestions. One for the current Raspberry Pi based approach and one for your new intended Hub 2350. First to the Raspberry:

Feedback on Radioberry: Improving Accessibility and Software Stability through Modern Packaging

First of all, thank you for your incredible work on the Radioberry expansion card. It is a fantastic piece of hardware that brings powerful Software Defined Radio (SDR) capabilities to the Raspberry Pi ecosystem, and the community deeply appreciates the effort put into this project.

As the project grows, we want to ensure it becomes accessible to an even wider audience—from seasoned radio amateurs to beginners. Currently, the deployment workflow presents a few significant hurdles for everyday users. Below is some constructive feedback and a proposal for modernizing the software distribution method. Current Pain Points

1. The High Barrier of Manual Compilation

Currently, users must manually clone the repository, compile the drivers from source, and install them as kernel modules. While this is straightforward for experienced Linux users and developers, it is a major roadblock for beginners. Many users simply want a stable, "plug-and-play" experience and get discouraged by build errors or command-line complexities.

2. Fragility During System Updates (apt upgrade)

Because the kernel module is compiled statically against a specific kernel version, regular system updates via apt frequently break the driver. When the Raspberry Pi OS kernel updates, the Radioberry driver stops working until the user manually recompiles it against the new headers.

3. Major OS Upgrades (e.g., Bookworm to Trixie)

With major distribution shifts—such as the moving from Debian Bookworm to Debian Trixie—the underlying kernel architecture, compiler versions, and library dependencies change significantly. This almost guarantees a broken system for the user and leads to a high volume of repetitive support requests in the forums.

The Proposed Solution: PPAs and DKMS

To solve these issues and future-proof the Radioberry software ecosystem, we highly recommend shifting toward a modern package distribution model utilizing a PPA (Personal Package Archive) combined with DKMS (Dynamic Kernel Module Support).

[Upstream Update / Git Commit]
     │
     ▼
[CI/CD Build Pipeline]
     │
     ▼
[PPA / Package Repository] ─> (apt update) ─> [User's Raspberry Pi]
     │
     ▼
[DKMS Auto-Compiles Driver]

How this benefits the project:

• DKMS (Dynamic Kernel Module Support): By packaging the source code with DKMS, the system will automatically recompile the Radioberry kernel module in the background whenever a new kernel is installed via apt. The user never has to run make manually again.

• Pre-compiled Packages via PPA: Instead of a long list of build commands, installation becomes as simple as:

  sudo add-apt-repository ppa:radioberry/stable
  sudo apt update
  sudo apt install radioberry-driver radioberry-software

• Automated CI/CD Build Environment: To achieve this, a Continuous Integration and Continuous Deployment (CI/CD) pipeline (e.g., via GitHub Actions) can be implemented. Whenever you push a stable tag or a release to GitHub, the pipeline automatically builds the Debian packages (.deb) for the target architectures (armhf, arm64) and pushes them to the PPA.

Conclusion

Implementing a CI/CD pipeline with DKMS packaging requires some initial setup, but it will drastically reduce the maintenance overhead in the long run. It eliminates broken installations, reduces GitHub issues/support requests, and makes the Radioberry a truly accessible, stable, and beginner-friendly platform.

Thank you again for your dedication to this project. We would love to support or test any initiatives moving in this direction!

Best regards

[John Melton]

Hi Johan,

I would be interested in helping with this.

-- John G0ORX 

[Frank Seidinger]

Dear Johan,

now on the feedback to the RadioBerry Hub 2350 approach.

Feedback on the Radioberry Architecture Shift: Transitioning to a Dedicated Embedded Microcontroller Board

Thank you for opening up the floor for feedback regarding the future architecture of the Radioberry project. Shifting away from the Raspberry Pi Single Board Computer (SBC) toward a dedicated embedded microcontroller platform is a highly intriguing and strategic move.

Below is some structured feedback on the advantages of this approach, along with a few recommendations to ensure the new hardware platform is future-proof and meets the needs of the amateur radio community.

1. Key Advantages of the Microcontroller Approach1. Resolution of the OS and Driver Dilemma

By decoupling the Radioberry from the Raspberry Pi OS, you completely eliminate the ongoing challenges with manual driver compilation, apt upgrade breakages, and major Debian distribution shifts (like Bookworm to Trixie). A dedicated firmware environment guarantees that once the system is running, it remains completely stable for the user.

2. Cost Efficiency

The Raspberry Pi has become increasingly expensive and harder to justify solely as an interface layer. Utilizing a dedicated microcontroller board will significantly lower the total hardware cost, making the Radioberry an even more competitive and accessible DIY SDR platform.

3. Power Supply Integration (13.8V Standard)

A dedicated board allows for an integrated, robust power management circuit. We highly recommend designing the board to accept a standard 13.8V DC input, as this is the universal power standard in amateur radio shacks. This removes the need for awkward 5V USB-C adapters and aligns perfectly with existing station power supplies.

4. Smart HAT Extension Support (Preamp Board)

The native board should be designed to automatically detect the Radioberry Preamp board. Furthermore, it should handle the necessary voltage regulation to provide a clean, stable, and well-filtered power supply directly to the Preamp HAT without requiring external routing.

Critical Technical Recommendations

1. Ethernet Interface: Moving Beyond 100 Mbps to Gigabit Ethernet

You mentioned planning to use the OpenHPSDR Protocol 1 because the selected microcontroller features a native 100 Mbps TCP/IP stack.

While Protocol 1 is highly capable, 100 Mbps Ethernet is simply no longer contemporary. In modern network architectures, older 100 Mbps stacks can sometimes cause negotiation issues with smart switches, or bottlenecks in busy home networks. We strongly recommend aiming for a Gigabit Ethernet (10/100/1000 Mbps) interface with automated fallback. Even if the protocol data doesn't fully saturate the bandwidth, a Gigabit physical layer ensures flawless compatibility with modern network infrastructure and future-proofs the hardware.

2. Keep the Focus Strictly on a Pure SDR Backend (The HL2 Philosophy)

I strongly agree that the primary focus should remain strictly on providing a high-performance SDR Backend.

There is a tendency among some DIY-ers to turn the Radioberry into a standalone transceiver with integrated displays, front-panel controls, and a heavy UI. Trying to handle a leistungshungriges (power-hungry) frontend on an embedded microcontroller would waste precious processing resources and drastically increase software complexity.

Modern PC-based SDR software (and mobile apps) are already outstanding. By focusing purely on a solid network-attached backend, you save resources, keep the firmware maintainable, and follow the exact philosophy of the Hermes-Lite 2 (HL2), which has proven to be incredibly successful in the community.

Conclusion

Transitioning the Radioberry into a dedicated, network-accessible microcontroller platform is a fantastic evolution. It resolves the most painful software deployment issues while optimizing cost and hardware integration. If the network interface is kept modern (Gigabit) and the focus remains firmly on a pure backend, this new generation of Radioberry will undoubtedly be a massive success.

Thank you for your continuous innovation and for involving the community in these foundational decisions!

Best regards,

[Paulh002]

This is a good solution for the Pi4 and Pi5 old driver.

However the new driver for the Pi5 needs a kernel patch.

I have scripted everything, including the kernel patch, and most people are able to install without problems.

The only thing I notice is that almost nobody takes the time to read the wiki or installation instructions.

I would encourage anybody who has knowledge of DKMS to create a pull request with a first version, maybe AI will help.

My SDR software needs a lot of compilation and libraries, so keeping everything up to date is a challenge. 

I am very happy with users like Mike AL7AK and other users who have put so much effort in testing the software.

 

--

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/1be76c6c-e0d6-49d3-a8d6-b6e755d6d7c9n%40googlegroups.com.

[Praveen Nair]

Dear Johan,

My suggestion is.

1.Make a platform not OS dependent in this case ethernet is a best option.

2. Globally available components, elaborate - easy to use, easy to get anywhere.

Regards 

Praveen

Vu3prw

Thanks & Best Regards,

Praveen .R

Phone: 9496189229

To view this discussion visit https://groups.google.com/d/msgid/radioberry/CAGzkEXcJL8%3DP9C6OgdN%2BOZs0d1Q7wAizjt5_z4FtQpg%3DCtW80Q%40mail.gmail.com.

[Photon Multimedia]

I am not qualified to comment on the proposal but I would like to say that this project has been very valuable to me. I have learned a lot by being forced to learn about many of the issues brought up. My only comment on the proposal of not using a RPI is that I have found that this project has gone way beyond the original scope for me. SDRBerry for me is now a fully integrated HAM Station solution. Because the platform is the RPI5 I am able to add extra monitors that are thin and can be folded up. This is like having a big screen monitor that comes apart and folds.

Making an incredible portable station. With the SDRBerry supporting CAT commands and the use of HAMlib and Rigctld I have been able to connect GPredict to SDRBerry so it now controls the SDRBerry, tracks satellites and changes the freq on the SDRBerry, due to Doppler shift. With Hamlib Gredict can control my rotor and point my anttenna at the satellite.  I can do this remotely from another RPI4 connected via ethernet.  QLog connects to the SDRBerry grabbing band data for automatic logging. WSTJ-X and JS8Call get input, output and CAT control of SDRBerry. I can use QSL mapping software like GridTracker an PSKReporter. I can do all of this at the same time with Rigctld due to the power of the RPI5. The sky is the limit.

Because of the modular design I can use Radioberry for HF and a Pluto+ for VHF/UHF/Microwave and switch between the two with a click in the interface.

The whole system folds up in an old camera bag. 

Hence the RPI5 is a real value add for me. 

From my perspective as a true beginner with no RF experience is that the hardware can be the weak link. I am not capable of building my own hardware. The pre-amp board was not available for a couple of years until, thankfully, Aurasinc made them available. ( and takes them back until you get a good one :) ) and the filter board which is really required to properly complete the project is only, again thankfully, available from Makerfab, But to the beginner buying boards from China direct can be a adventure in itself. Now this is typical of open source hardware projects. Nothing really you can do unless you can convince Aurasinc to add the filter board to their stable. My only point is that the software no matter how it is done is available via the internet with some research but the hardware is harder to find and be sure it is the right stuff for Radioberry.  A person like me can waste a lot money buying parts that end up  not being right for the project. If you build a new platform who will produce the boards? Will they be readily available or a one time run of boards? This is not to say that there is anything wrong with experimenting with new solutions etc but that it may not be something that can become as popular as Radioberry has become.

Just my view from the "peanut gallery"

I also must add that I am incredibly grateful to Johan and Paul for their follow up support of their projects. It is quite understandable to put your work out to share with other people and then disappear because you have other work to do. But to share it and then support and improve it is commendable. I know how much work it is to develop a project and then document it. So we all owe you both, and all the other code producers in the open source community, a debt of gratitude.

Thanks again

[Frank Seidinger]

Hi everyone,

I would like to propose a general hardware design feature for future Radioberry boards or companion preamp/frontend boards: an integrated, automated Hardware Self-Test using a safe, internal loopback path.

Currently, verifying that the FPGA, RF-chip (AD9866), and the SPI communication are working flawlessly usually requires external test equipment or risking the hardware by transmitting. Especially when using a preamp board (delivering 3-5W of RF power), accidentally transmitting into an unmatched load or without an antenna connected can easily destroy the PA stage.

To make hardware verification 100% safe and simple, we could implement a dedicated, attenuated internal loopback path directly on the PCB:

1. PA Isolation: During the self-test mode, the main PA stage is completely disabled or powered down via a GPIO pin to prevent any high-power transmission.

2. RF Switches & Attenuator: The low-power TX output from the AD9866 is routed via an RF switch through a fixed attenuator (e.g., -50 dB) and then switched directly back into the RX input.

3. Software Evaluation: A simple software utility (e.g., a Python or C script) triggers a low-power carrier, captures the IQ data, and performs a quick FFT. If a precise peak at the target frequency is detected at the expected signal level (e.g., -40 dBm), the hardware is verified as fully operational.

This built-in loopback would allow users to instantly verify that the entire digital and RF chain (SPI, FPGA, AD9866, and RF switches) is functional with a single command, without any risk of frying the hardware.

What are your thoughts on integrating such a test path into the hardware layout? Has anyone experimented with a similar automated loopback design on custom Radioberry frontends yet?

Best regards,
Frank

[Paulh002]

The loopback option is more or less already available in the "Hat: design of Johan.

This is the alternative of the pre-amp board. I think it is used for pre-distortion. But with a software tweak you could use it for self check.

--
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/f4f3d1ed-e33a-4303-be52-261047c0c6ean%40googlegroups.com.

[Ricardo Suarez]

Hello.

Based on your schematics, I try to adapt my efforts using RP2040 as ADC talking to Thetis...

Rick LU9DA

To view this discussion visit https://groups.google.com/d/msgid/radioberry/a3aa944f-8dd8-4f08-9559-15f329be99dbn%40googlegroups.com.