Author: pa3gsb

Hereby some pictures showing the initial experiments.

First QSO gives some positve feedback.

Hope the pictures give some idea.

73 Johan

PA3GSB

Radioberry juice journey continues….

There was still a road ahead for the development of the juice board.

I2C supported by radioberry gateware

One of the things to discover was the i2c connection.

As reported in the previous post the juice board using the FT-245 protocol is
not able to use the i2c MPPSE mode of the FT2232 FTDI chip. To make use of bus for controlling the radioberry preamp the i2c logic must be build into the gateware.

During the development of the preamp i added an additional parallel i2c bus.
This i2c bus can now be used for the i2c controlled from the FPGA

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

(pin 15 and pin 16 of the radioberry io connector)

The HL-2 hardware uses 3 i2c busses:

- Slow 4 channel ADC
- Programmable clock generator (not used in radioberry)
- Digital Pot and  N2ADR filter selection

All controlled by the gateware.

Radioberry uses one i2c bus containinng the following devices:

- Slow 4 channel ADC
- Digital Pot

both i2c devices present at preamp board

- N2ADR filter selection

The slow ADC is used to measure the bias current, temperature of the PA finals, FWD and REV voltages.
Setting up the BIAS of the finals is done by the digital pot; the setup is kept in the EEPROM of the digital pot.

The gateware is modified to make this possible.

In the change also the RQST functionality; which Steve defined as an addtion to the original openHPSDR protocol-1, is implemented.

All described in the protocol:

https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol

for the HL-2.

The gatware must responds within a certain time… quisk and wireshark were very helpfull in testing.

It took some development effort (at least for me) to get it working properly, without quisk complaining; the quisk code was helping in the process to understand how it all should work!

The protection of the PA finals is also included in the gateware using the juice board. If the temperature is too high, following the same temperature as defined for the HL-2, the PA is shutdown.

Also implememted the PWM for a fan; but not yet assigned the pwm to a FPGA output pin!

Bandscope

Also the bandscope is working. Useable from Quisk and linHPSDR.

Setup configuration

The following overview shows what is possble with the juice board.

Nice to see that it is possible to use different machines and platforms.

The firmware provides in:

- loading gateware into radioberry FPGA
- openHPSDR protocol-1 (Discovery, IQ streaming and control)

When the firmware is running on a RPI or other SBC the GPIO can be used.

My Setup

I took some time searching for a computer for running the radioberry together with the juice board.

Decided to go for a Refurbished mini pc

ThinkCentre M900

Processor:Intel Core i5
Processor type:i5-6500T CPU @ 2.50GHz
Internal 8GB

Dimensions (W x D x H)
(inches) : 1.36″ x 7.20″ x 7.05″
(mm) : 34.5 x 182.9 x 179

6* USB 3.0

Audio in and out.

Making the computer dual boot; using W10 and Ubuntu linux.

Also a big advantage is to make use of a large computer screen; also a screen useable for normal computer work no need of additional (small) screens.

For controlling the radio i bought an MIDI controller a behringer cmd pl-1; active support to use with pihpsdr and other software!

Have fun

73 Johan

PA3GSB

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.

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.

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.

No deadlines, all done in leisure time!

As always have fun.

73 Johan
PA3GSB

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