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
(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.
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!
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 boardJuice board
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.
