I’m setting up a remote ham radio station and plan to use a Raspberry Pi as a server for WFview, connected to an Icom 7300. It will be operated from another house that is connected to the QTH through an Wireguard VPN. I’d like to hear your recommendations regarding the best Raspberry Pi model for this setup.
My main questions are:
Is 4GB of RAM sufficient, or is it better to go with 8GB for smoother operation?
Would a Raspberry Pi 4 be enough, or is it worth investing in a Raspberry Pi 5 for better performance?
If you have experience running WFview on a Raspberry Pi, I’d appreciate your insights on performance, stability, and any potential bottlenecks to consider.
I have a remote system with an IC-7300. The server is an Inovato Quadra with 4 GB of ram. It’s running the full XFCE desktop environment with wfview 1.64 as a startup item. And it’s been working great for years at my father’s QTH.
So yes, I think 4 GiB is plenty of ram. And Pi4 or better is a good recommendation.
The pure server command-line version of wfview will use even fewer resources. Although it may take more work to configure it.
Been operating remote for years with both the Raspberry Pi 4 and 5. 4GB ought to work fine, but at only a $20 difference between 4GB and 8GB, I say go with 8GB. A Pi 4 will operate remotely just fine. The Pi 5 is much faster but that’s only important if you do a lot of compiling and building from source. The only drawback to the Pi 5 is that it runs hot, so get plenty of heatsinking and ventilation. I have overheated my Pi 5 building fldigi with the j4 option which uses all 4 cores for compiling. I resolved this by removing the lid on the case.
Another option is the OrangePi. I have just ordered a couple of the Orange Pi Compute Modules (CM4) with onboard eMMC (no SD card needed). You need a base-board, but there are some good deals on AliExpress (52 GBP for the 4GB CM4 with 32GB eMMC and baseboard)
when in ops, it is running WFView 2.03 with GUI, plus WSJT-X or FLDigi, plus a selfwritten script to control the antennas and do the logging into different logbooks, depending on the current user.
Thanks for the tip. I was actually considering the idea of using the same PSU that powers the IC7300. To do so, I bought this little DC to DC converter (input from 8 to 30) and output 5v at 3A, exactly what the raspberry needs. I hope I haven’t overlooked anything, but in my mind, it makes sense to take advantage of the stability and clean power supply provided by the Icom itself.
It does really make sense to a very good power supply. I have choosen setups, where I have different power supplies for the IC7300 and the Raspberry. The Raspberry is running 24x7 (because in the night, there are backups running and some data gathering for WSJT-X call information). The powersupply is attached to a remote controlled switch, so I can individually power the raspberry down/up, if something strange happens.
The power supply for the IC7300 ist attached to a remote controlled switch as well. If the usage is below a certain level for some time (~10w), than the powersupply is completely shut of, the antenna is disconnected from the radio.and shortened to ground.
If later wfview is started on the Raspberry, everything is connected again: power on the radio & connect the antenna.
First of all, thank you so much for the answers. As many of you im sure, I’m configuring this remote station because the noise level in my city apartment doesn’t allow me to operate properly. So the server station will be set up in my countryside house. Although my idea is build something to last stand alone, I visit the house every weekend, so minor adjustments or unexpected outage could be solved.
The server station is based on a IC-7300 with an EFHW antenna of 40m long). Some additional questions that come to my mind:
The server side of Wfview can run in the raspberry without desktop mode? Just saying, so I can save memory and processor resources for additional routines (wspr, etc…)
Is there any good guide to follow for server side installation process in the raspberry?
Any advice on how to “automate” the antenna connection and disconnection to prevent issues in case of electrical storms?
Finally, and this is a subject one: do you miss touching the knobs and so on? I know this is the price to pay for a remote station (as long as you don’t want to spend 6.000€ in Flexradio + Maestro).
I can almost guarantee you that $4 AliExpress DCDC converter will generate so much noise that several HF bands will be ruined simply because it is powered and near the HF radio (radiative emissions).
Use a linear 5V regulator or use a converter known to be quiet. (This is where the $20 saved by going with lower RAM can be used).
I am using a 12V vehicle USB charger designed to charge phones to run the R Pi(s) for my repeater. They aren’t branded and I have no idea where they came from, but I tested them and they were very quiet. YMMV.
I have never really tested working without a desktop. As I am using the remote station out of a camper van, I do not always have optimal mobile coverage. Therefore I have decided to put as much as possible on the raspberry local to the IC7300. So I basically need the bandwidth for the video, when doing WSJT-X and audio, when doing CW. WSJT-X locally on the raspberry is working flawless.
never tried
as mentioned, I have written a script which controls the IC7300 specific to my environment. But regarding the antennas, it basically switches relays to connect or disconnect, when the IC7300 qsys or if powered on/off.
no, do not miss the knobs, only for PBT. I visit one of the remote sites every couple of months and use the IC7300 as it is local.
Thomas
I run wfview and flrig chained behind it at the same time on a 3B+ running rasbian
controlling a 7300 . . .
However, the PRI runs headless. it only has power and USB attached and the UI
is exported across the rpi onboard wifi to the main computer.
This is the windowmaker button that starts the xfce4 panel to appear on main machine desktop
(“xfceP afu@PI”, SHEXEC, “ssh -a -n -q -l afu PI ‘(export DISPLAY=10.77.7.7:0 && /home/afu/rxfcep)’”)),
display ip is the eth address of the main machine.
/home/afu/rxfcep on rpi
#!/bin/bash
if ! ps axc | grep -q xp.afu.3bp ; then
dbus-launch /home/afu/xp.afu.3bp
–sm-client-disable --disable-wm-check \
1>/dev/null 2>/dev/null &
else
echo " xp.afu.3bp is already running"
echo
sleep 6
fi
sleep 3
That script runs the xfce4 panel applet to appear on main desktop, and wfview and flrig is started from there
The RPI itself does not run any GUI at all . . boots to an unused text prompt.
the 3b+ can run these GUI programs with plenty free ram left over because the GUI burden is carried by the big machine, that serves as the only desktop for house full of headless machines.
Yes wfserver is a separate binary that you can build with no UI, it needs to be configured manually (by editing the wfserver.conf file) and some information is available here Headless Server | wfview
If you do miss ‘knobs’ wfview supports a wide range of external controllers, from the Icom RC28 (which has a nice weighted VFO knob) to the very economical Mirabox M3 with multiple encoders and plenty of buttons, all of which can be assigned to almost any function. Using USB Controllers (RC-28, Shuttle, Stream Deck, sunSDR, etc) | wfview
That’s great Phil. Thank you so much for such an incredible job you’ve done here.
One last thing: in order to “connect” the two houses (countryside house where the antenna and Icom are set up and city apartment where I’ll be remotely operating) I’m planning to establish a VPN tunnel using Wireguard. I have read that UDP is important and take special care to MTU value so packets are not mangled. Any special advice to take into account?
From my testing, it really depends on the audio Codec being used. For wfview-wfview I would always recommend using Opus as it results in very minimal loss of quality but significantly smaller packets.
As an example, single channel LPCM16 will generate 2 UDP packets for every 20ms of audio, with the largest packet being 1380 bytes. I assume this number was chosen by Icom to ensure that the packet doesn’t get fragmented (which will break things fairly spectacularly).
I have found the packet overhead on some VPN systems can cause these packets to be fragmented however, but with the average Opus packet being < 300 bytes for the same 20ms duration of audio, this is never going to happen.
