Radioberry JUICE

A development journey …

Wishes for the radioberry to improve:

  • IQ bandwith increase
  • CPU utilization reduction
  • Supporting multiple platforms
  • Different computer boards
  • Easy setup

But keeping :

The radioberry with the high coupling to the RPI must be kept; i want to keep the charm of this radio setup.

Some time ago i tried to add an ethernet module; it worked but the RPI was still needed.

Radioberry using ethernet module

In the search for all these improvemets i made a proposal for an alternative setup.

The proposal:

I like to introduce a Radioberry FT2232H extension board; renamed into the radioberry juice board.

This radioberry can be plugged in to the board (like you connect a RPI).

This board contains the FTDI FT2232 chip and implements an USB interface.

The extensionboard communicates with any SBC/PC via USB, making it possible to connect better performing SBC or a PC.

To allow USB communications between a PC and the FPGA,
the extension board uses an FT2232H USB device to create a communications bridge between
the PC USB interface and the FPGA.

This communications bridge splits into two channels: a programming interface
channel and a parallel 245 FIFO communications interface channel.

The programming interface uses channel B of the FT2232H to configure
the FPGA using the Intell Cyclone Passive Serial interface.

The 245 communications interface uses channel A of the FT2232H to transfer data,
either synchronously or asynchronously, over the 245 FIFO interface to and from the FPGA.

The extensionboard utilises the functionality of the Multi-Protocol Synchronous Serial Engine (MPSSE)
architecture in channel B of the FT2232H chip to adapt to the Intell Cyclone Passive Serial interface.

MPSSE is an FTDI function that allows different synchronous protocols to be configured on any available data channel.
Once the FPGA has been configured, channel B of FT2232H can be reconfigured, using MPSSE, to operate as general purpose IO pins.

Initial idea of extension board… later called radioberry juice

The intention was to make an IQ server controlled by a SPI interface!

During development the IQ stream and SPI control as individual functions were working fine.
In the radio setting where both functions should work together i got a problem…..took me some time to figure this out!

Sometimes it is better to read the datasheet than just doing….

Quoted from the datasheet;

‘In this mode (FT245 Style Synchronous FIFO Interface) the ‘B’ channel is not available as all resources have been switched onto channel A.’

So no SPI / I2C; no control using the FT2232H chip.

So back to the drawing board….

Can we solve this? and make it even beter as the initial proposed solution?

One big drawback in the previous solution was that i had a shortage of pins… so the
data in the synchronous mode was based on 4 data lines…. already thinking of a hardware upgrade of the
radioberry…. but that is not longer required in the next iteration of the design.

The solution is simple… looking to the HL-2 there is also 1 data channel for getting the iq datat and
control data from and to the SDR program….

i will follow the same principal.

In the gateware i have only to reimplement the usopenhpsdr1.v and dsopenhpsdr1.v and making
a module for the physcial interface.

Making the phy interface in verilog… i had some problems to solve…

After sending 510 bytes i lost 2 bytes! Took me sometime to figure this out! Seems that the FTDI is using 2 bytes
for controlling the USB bulk stream (which is 512 bytes);

So i learned when checking for speed you also must look to data integrity…

The advantage is that the gateware is now implementing the protocol 1 packets… which can be easliy
placed, using one line c code in the ethernet package :

………….
read_stream(hpsdrdata); // fetching 1032 bytes of ethernet packet.
………….

in stead of building the p-1 packet in the c code.

example from the firmware using the radioberry driver running at a RPI:

void fillPacketToSend() {
	memset(hpsdrdata,0,1032);
	memcpy(hpsdrdata, header_hpsdrdata, 4);
	hpsdrdata[4] = ((last_sequence_number >> 24) & 0xFF);
	hpsdrdata[5] = ((last_sequence_number >> 16) & 0xFF);
	hpsdrdata[6] = ((last_sequence_number >> 8) & 0xFF);
	hpsdrdata[7] = (last_sequence_number & 0xFF);
	last_sequence_number++;
	memcpy(hpsdrdata + 8, sync_hpsdrdata, 8);
	memcpy(hpsdrdata + 520, sync_hpsdrdata, 8);

	if (lnrx != nrx) usleep(1000);

	lnrx = nrx;

	int factor = (lnrx - 1) * 6;
	for (int frame = 0; frame < 2; frame++) {
		int coarse_pointer = frame * 512; // 512 bytes total in each frame
		
		int nr_samples = (nrx == 1)? 63 : (nrx == 2)? 72: (nrx ==3)? 75: 76;
		read(fd_rb , rx_buffer , nr_samples);
		rb_sample = 0;
		for (int i=0; i< (504 / (8 + factor)); i++) {
			int index = 16 + coarse_pointer + (i * (8 + factor));
			//NR must be read from gateware.
			for (int r = 0; r < MIN(lnrx, NR); r++) {	
				memcpy(hpsdrdata + index + (r * 6), rx_buffer + rb_sample, 6);
				rb_sample+=6;						
			}
		}
		// inform the SDR about the radioberry control status.
		// https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol	
									
		if ( !i2c_measure_module_active & last_sequence_number % 500 == 0) read_temperature_raspberryPi();			

		if ( last_sequence_number % 2 == 0) {
			// if i2c_measure_module_active; the temperature of module is used, otherwise the RPI temp.	
			hpsdrdata[11 + coarse_pointer] = 0x08 | (rb_control & 0x07);
			if (i2c_measure_module_active) {
				hpsdrdata[12 + coarse_pointer] = ((pa_temp >> 8) & 0xFF); 
				hpsdrdata[13 + coarse_pointer] = (pa_temp & 0xFF); 
			} else {
				hpsdrdata[12 + coarse_pointer] = ((sys_temp >> 8) & 0xFF);
				hpsdrdata[13 + coarse_pointer] = (sys_temp & 0xFF);
			}
		} else {
			hpsdrdata[11 + coarse_pointer] = 0x10 | (rb_control & 0x07); 
			hpsdrdata[14 + coarse_pointer] = ((pa_current >> 8) & 0xFF); 
			hpsdrdata[15 + coarse_pointer] = (pa_current & 0xFF); 
		}
	}
}

Making the firmware very small around 300 lines of code.

Here we are getting all the ethernet behaviour for ‘free’ no difficult coding in the FPGA.

What is done:

  • inital version of firmware running at windows and linux.
  • initial version of gateware for 6 RX and 1 TX

Todo:

  • no i2c support yet…for the radioberry preamp board
  • no i2c support for radioberry extensions
    • when running on a SBC it could be possible to add i2c support to the firmware.
  • adding i2c support to the gateware
  • adding bandscope

What to expect about perfomance:

Based on a remark by Steve:

Bandwidth usage can be estimated.
Each IQ sample is 24 bits of I and 24 bits of Q data for 48 bits total.

If you realize 100Mbs, then you have 100e6/48 = 2.083 MHz total IQ bandwidth.
This is just over 5 384kHz receivers or 10 192kHz receivers.

I think you will run into RPi4 limitations processing and demodulating this much data before hitting bandwidth limitations

I have been testing the setup on a W10 latptop running 6 rx slices with a 384KHz sampling rate:

The juice board brings indeed some juice to the radioberry!

JUICE BOARD

The change of plans… makes it necessary to make a new juice board design.

Requirements for the board:

  • 12 V input iso 5 V making supply mistakes (CU2ED Jacinto)
  • adding a rpi pico or teensy uC ?
    • i2c / spi support?

O yes a last remark:

It is also well possible to program in python… there is a nice library available for the FTDI chips.

Radioberry working together with juice board
Juice board

No deadlines, all done in leisure time!

As always have fun.

73 Johan
PA3GSB

  • Proposal : https://groups.google.com/g/radioberry/c/yze9Gq0Jgf8

Radioberry TX amplifiers.

20W Amplifier

From Deepu, VU3TLD i received a bare PCB board, he designed a PCB based on the developement done by G6ALU.

20W PCB design by Deepu VU3TLD

It took some time to collect all the required components. I had a great time building this amplifier.
Winding the toroids and assembling the 1206 SMD components, these 1206 SMD are large…when you are used to 0603 sizes.

Also doing some mechanical work like tapping the holes for mounting the HF devices.

A big advantage of these devices used here are in a TO220 package which differ, from switching devices,
in that the tab is connected to the source electrode, so in this design are grounded by the PCB and heat sink.
No insulating washers are used when bolting the devicesdown to the heat sink and PCB.

After assembly i attached a 50 ohm resistor at the amp in connecor; setting the bias was going smooth.
But when removing the 50 ohm resistor the amplifier started to oscillate… but looking back in some direct mails
from Deepu i could have found the warning; i had to ground the HF-in and HF-out connector.

Assembled 20W Power Amplifier.

Detailed information can be found at:

https://github.com/pa3gsb/Radioberry-2.x-extensions/tree/master/Radioberry-PA-20W

10W HF linear

This kit was orderd from QRP – Labs

Nice to built a kit after long time…. the documentation provided is very good.

10W amplifier

The amplifier is working good.

https://www.qrp-labs.com/linear.html

Besides the amplifier i decided to buy and built the LPF from QRP – Labs.

LPF

https://www.qrp-labs.com/lpfkit.html

combining these filters with the Ultimate relay-switched LPF kit from QRP – Labs.

https://www.qrp-labs.com/ultimatelpf

For switching the relays iam using a PCA9555 board; an IO extender controlled via I2C.

This controller is supported by radioberry firmware.

5W Radioberry preamp board.

The preamp board can be clicked on top of the radioberry.

Radioberry preamp board

This results in a nice setup with a long time ago built 100W amplifier

https://github.com/pa3gsb/Radioberry-2.x/wiki/Radioberry-preamp

Iam using this setup with a amplifier i built some years ago, the amplifier does contain the LPF filters.

100W PA

Have fun

73 Johan

PA3GSB