{ "version": "https://jsonfeed.org/version/1", "title": "PA3GSB", "description": "", "home_page_url": "https://pa3gsb.github.io", "feed_url": "https://pa3gsb.github.io/feed.json", "user_comment": "", "author": { "name": "pa3gsb" }, "items": [ { "id": "https://pa3gsb.github.io/publications/radioberry-eer-experiments/", "url": "https://pa3gsb.github.io/publications/radioberry-eer-experiments/", "title": "Radioberry EER Experiments", "summary": "Hereby some pictures showing the initial experiments. First QSO gives some positve feedback. Hope the pictures give some idea. 73 Johan PA3GSB", "content_html": "

Hereby some pictures showing the initial experiments.

\n

First QSO gives some positve feedback.

\n
\"\"
\n
\"\"\n
Actual setup for first exeriments.
\n
\n
\"\"\n
PWM / Envelope (using RPI GPIO for test)
\n
\n
\"\"\n
Drain and gate drive signal.
\n
\n
\"\"\n
Power SDR setup.
\n
\n
\"\"\n
Actual output using double tone.
\n
\n
\"\"\n
There is power...
\n
\n

Hope the pictures give some idea.

\n

 

\n

73 Johan

\n

PA3GSB

", "author": { "name": "pa3gsb" }, "tags": [ ], "date_published": "2022-06-18T11:57:17+02:00", "date_modified": "2026-10-24T16:49:33+02:00" }, { "id": "https://pa3gsb.github.io/publications/radioberry-juice-part-2/", "url": "https://pa3gsb.github.io/publications/radioberry-juice-part-2/", "title": "Radioberry Juice part 2", "summary": "Radioberry juice journey continues…. There was still a road ahead for the development of the juice board. 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…", "content_html": "

Radioberry juice journey continues….

\n

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

\n

I2C supported by radioberry gateware

\n

One of the things to discover was the i2c connection.

\n

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.

\n

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

\n

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

\n

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

\n

The HL-2 hardware uses 3 i2c busses:

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

All controlled by the gateware.

\n

Radioberry uses one i2c bus containinng the following devices:

\n
\n
\n
- Slow 4 channel ADC\n- Digital Pot\n\nboth i2c devices present at preamp board\n\n- N2ADR filter selection
\n
\n
\n

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.

\n

The gateware is modified to make this possible.

\n

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

\n

All described in the protocol:

\n

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

\n

for the HL-2.

\n

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

\n

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!

\n

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.

\n

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

\n

Bandscope

\n

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

\n

 

\n
\"\"
\n

Setup configuration

\n

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

\n
\"\"
\n

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

\n

The firmware provides in:

\n
\n
\n
- loading gateware into radioberry FPGA\n- openHPSDR protocol-1 (Discovery, IQ streaming and control)\n\nWhen the firmware is running on a RPI or other SBC the GPIO can be used.
\n
\n
\n

My Setup

\n

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

\n

Decided to go for a Refurbished mini pc

\n

ThinkCentre M900

\n

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

\n

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

\n

6* USB 3.0

\n

Audio in and out.

\n

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

\n

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.

\n

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

\n

 

\n

Have fun

\n

73 Johan

\n

PA3GSB

", "author": { "name": "pa3gsb" }, "tags": [ ], "date_published": "2021-07-22T18:41:28+02:00", "date_modified": "2026-10-24T16:48:36+02:00" }, { "id": "https://pa3gsb.github.io/publications/radioberry-juice/", "url": "https://pa3gsb.github.io/publications/radioberry-juice/", "title": "Radioberry JUICE", "summary": "A development journey … Wishes for the radioberry to improve: 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;…", "content_html": "

A development journey …

\n

Wishes for the radioberry to improve:

\n\n

But keeping :

\n

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

\n

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

\n
\"\"\n
Radioberry using ethernet module
\n
\n

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

\n

The proposal:

\n

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

\n

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

\n

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

\n

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

\n

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.

\n

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

\n

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

\n

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.

\n

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.

\n

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.

\n
\"\"\n
Initial idea of extension board... later called radioberry juice
\n
\n

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

\n

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!

\n

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

\n

Quoted from the datasheet;

\n

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

\n

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

\n

So back to the drawing board….

\n

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

\n

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.

\n

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….

\n

i will follow the same principal.

\n

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

\n

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

\n

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);

\n

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

\n

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 :

\n

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

\n

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

\n

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

\n
void fillPacketToSend() {\n\tmemset(hpsdrdata,0,1032);\n\tmemcpy(hpsdrdata, header_hpsdrdata, 4);\n\thpsdrdata[4] = ((last_sequence_number >> 24) & 0xFF);\n\thpsdrdata[5] = ((last_sequence_number >> 16) & 0xFF);\n\thpsdrdata[6] = ((last_sequence_number >> 8) & 0xFF);\n\thpsdrdata[7] = (last_sequence_number & 0xFF);\n\tlast_sequence_number++;\n\tmemcpy(hpsdrdata + 8, sync_hpsdrdata, 8);\n\tmemcpy(hpsdrdata + 520, sync_hpsdrdata, 8);\n\n\tif (lnrx != nrx) usleep(1000);\n\n\tlnrx = nrx;\n\n\tint factor = (lnrx - 1) * 6;\n\tfor (int frame = 0; frame < 2; frame++) {\n\t\tint coarse_pointer = frame * 512; // 512 bytes total in each frame\n\t\t\n\t\tint nr_samples = (nrx == 1)? 63 : (nrx == 2)? 72: (nrx ==3)? 75: 76;\n\t\tread(fd_rb , rx_buffer , nr_samples);\n\t\trb_sample = 0;\n\t\tfor (int i=0; i< (504 / (8 + factor)); i++) {\n\t\t\tint index = 16 + coarse_pointer + (i * (8 + factor));\n\t\t\t//NR must be read from gateware.\n\t\t\tfor (int r = 0; r < MIN(lnrx, NR); r++) {\t\n\t\t\t\tmemcpy(hpsdrdata + index + (r * 6), rx_buffer + rb_sample, 6);\n\t\t\t\trb_sample+=6;\t\t\t\t\t\t\n\t\t\t}\n\t\t}\n\t\t// inform the SDR about the radioberry control status.\n\t\t// https://github.com/softerhardware/Hermes-Lite2/wiki/Protocol\t\n\t\t\t\t\t\t\t\t\t\n\t\tif ( !i2c_measure_module_active & last_sequence_number % 500 == 0) read_temperature_raspberryPi();\t\t\t\n\n\t\tif ( last_sequence_number % 2 == 0) {\n\t\t\t// if i2c_measure_module_active; the temperature of module is used, otherwise the RPI temp.\t\n\t\t\thpsdrdata[11 + coarse_pointer] = 0x08 | (rb_control & 0x07);\n\t\t\tif (i2c_measure_module_active) {\n\t\t\t\thpsdrdata[12 + coarse_pointer] = ((pa_temp >> 8) & 0xFF); \n\t\t\t\thpsdrdata[13 + coarse_pointer] = (pa_temp & 0xFF); \n\t\t\t} else {\n\t\t\t\thpsdrdata[12 + coarse_pointer] = ((sys_temp >> 8) & 0xFF);\n\t\t\t\thpsdrdata[13 + coarse_pointer] = (sys_temp & 0xFF);\n\t\t\t}\n\t\t} else {\n\t\t\thpsdrdata[11 + coarse_pointer] = 0x10 | (rb_control & 0x07); \n\t\t\thpsdrdata[14 + coarse_pointer] = ((pa_current >> 8) & 0xFF); \n\t\t\thpsdrdata[15 + coarse_pointer] = (pa_current & 0xFF); \n\t\t}\n\t}\n}\n
\n

Making the firmware very small around 300 lines of code.

\n

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

\n

What is done:

\n\n

Todo:

\n\n

What to expect about perfomance:

\n

Based on a remark by Steve:

\n

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

\n

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.

\n

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

\n

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

\n
\"\"
\n

 

\n

The juice board brings indeed some juice to the radioberry!

\n

JUICE BOARD

\n

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

\n

Requirements for the board:

\n\n

O yes a last remark:

\n

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

\n
\"\"\n
Radioberry working together with juice board
\n
\n
\"\"\n
Juice board
\n
\n
\"\"
\n

No deadlines, all done in leisure time!

\n

As always have fun.

\n

73 Johan
PA3GSB

\n", "author": { "name": "pa3gsb" }, "tags": [ ], "date_published": "2021-05-31T16:27:21+02:00", "date_modified": "2026-10-24T16:48:54+02:00" }, { "id": "https://pa3gsb.github.io/publications/radioberry-tx-amplifiers/", "url": "https://pa3gsb.github.io/publications/radioberry-tx-amplifiers/", "title": "Radioberry TX amplifiers.", "summary": "20W Amplifier From Deepu, VU3TLD i received a bare PCB board, he designed a PCB based on the developement done by G6ALU. It took some time to collect all the required components. I had a great time building this amplifier. Winding the toroids and assembling…", "content_html": "

20W Amplifier

\n

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

\n
\"\"\n
20W PCB design by Deepu VU3TLD
\n
\n

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.

\n

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

\n

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.

\n

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.

\n
\"\"\n
Assembled 20W Power Amplifier.
\n
\n

Detailed information can be found at:

\n

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

\n

 

\n

10W HF linear

\n

This kit was orderd from QRP - Labs

\n

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

\n

 

\n
\"\"\n
10W amplifier
\n
\n

The amplifier is working good.

\n

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

\n

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

\n

 

\n

 

\n
\"\"\n
LPF
\n
\n

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

\n

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

\n

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

\n

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

\n

This controller is supported by radioberry firmware.

\n

 

\n

5W Radioberry preamp board.

\n

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

\n

 

\n
\"\"\n
Radioberry preamp board
\n
\n

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

\n

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

\n

 

\n

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

\n

 

\n
\"\"\n
100W PA
\n
\n

Have fun

\n

73 Johan

\n

PA3GSB

", "author": { "name": "pa3gsb" }, "tags": [ ], "date_published": "2021-03-23T17:07:22+01:00", "date_modified": "2026-10-24T16:49:15+02:00" } ] }