Headless wfserver vs IC-7610 with LAN + wfview


I’ve just started to make some tests…

My goal was to compare wfserver vs LAN interface of IC-7610.

So I compiled wfserver headless on my Raspberry Pi Model B Rev 2.
Compilation with “make -j1” took more than 2hours;)

Important information is that the connection is REMOTE.

Works without any issues with IC-7610 LAN when audio is set to 250ms latency LPCM 1ch 8bit both TX and RX and Sample rate 8000. rx latency shown by wfview is around 150 ms with rtt ~50ms.

So I run wfserver on RPI select Opus codec on my wfview thinking it should be waaay better but then…
Its waaay worse;)

RPI is not loaded by wfserver… link is the same and RPI is connected to the same switch that IC-7610 is…

Am I doing something really wrong?

Hi Dawid,

You are connecting to the IC-7610 via USB to the Pi, correct?

And you say the connection between another PC and the Pi is not too good, using opus?

de W6EL

Yes it’s way worse than direct to 7610. Plus initial start of that connection takes a lot more time. That RPI is not doing anything else… But maybe it’s just to slow?

Once it segfaulted but I am unable to reproduce.

I can tell you that at my dad’s QTH, he has an Inovato Quadra running wfview for his 7300 server, and it’s very smooth, no problems. CPU usage is about 1%. Compile time was 15 minutes. It’s no speed daemon but it seems to run pretty well, and he is using the GUI version mostly.

Do you see any log notices about missing packets?

Also, as odd as it sounds, can you try using 48k with Opus?

de W6EL


tried - logs attached.
Direct LAN works as usual, RPI connection did not even started the audio…

In both cases connection goes over wireguard VPN that starts on my notebook and ends on the mikrotik router in front of RPI and 7610.

test1-wfserver.log (116.9 KB)
test2-wfview-ic-lan.log (102.5 KB)
test1-wfview-rpi.log (21.0 KB)

Seems its other problem than one I reported originally…
As now it looks that wfserver cannot communicate with the radio, right?
Yesterday it was working but in terrible way…

Over LAN it works even today…

And if I turn off wfview and run my python code (I am reading frequency of radio and announcing it over UDP so that RF2K-S power amplifier knows what frequency I am on) all works…

To get more confidence in ports configuration:

pi@radio:~/.config/wfview $ ls -la /dev/ic7610a 
lrwxrwxrwx 1 root root 7 lut 25 00:50 /dev/ic7610a -> ttyUSB0
pi@radio:~/.config/wfview $ grep ic7610a /etc/udev/rules.d/99-hamlib.rules 
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="IC-7610 23001310 A" SYMLINK+="ic7610a"

And now the rest of the story.
I am unable to TURN ON the IC-7610 using wfserver…

So what I did is I connected over IC-7610 LAN, turned it on Exited wfview and run wfserver and wfview with connection over USB… then it is connected but audio is a problem;\

Please see more debug logs here.
test3-wfserver.log (56.4 KB)
test3-wfview-rpi.log (115.7 KB)

Configuration file of wfserver:




building wfserver does not automatically mean all is working though.

What’s your idea behind looking at the differences?

Wanted to see if Opus codec will give me some improvement in bandwidth etc.

Additionally I was thinking that this kind of setup may allow me to work on/test CW remote keying (not by sending letters, but dits and dahs - with USB keying or some GPIO?).

And additionally yet I was thinking that wfview could send UDP n1mm broadcasts Radio packets to my PA (which is also remote) instead of my Python code listening on CI-V…

So as you see - plenty of;)

Hi Dawid,

Any chance you can try the GUI wfview with the server enabled?

de W6EL

I will try but first will need to find recipe to cross compile from Ubuntu 64bit to arm RPI;)

Haha yeah I hear you. If you find a good one, do share. I’ve never got it working consistently.

I postponed cross compilation for now as it seems a little bit more time consuming;)


When I run wfserver (on the RADIO side) it consumes around 94% of CPU - audio is breaking and have a lot of messages like:

( "CIV" ): Missing SEQ has been received!  "0x2a9"
2023-02-26 16:38:32.910 udpServer : sending request for multiple missing packets :  "990299029a029a029b029b029c029c029d029d029e029e029f029f02a002a002a102a102a202a202a302a302a402a402a502a502a602a602a702a702a802a802a902a902aa02aa02ab02ab02ac02ac02ad02ad02ae02ae02af02af02"
2023-02-26 16:38:17.397 "::ffff:" ( "Audio" Large seq number gap detected, previous highest:  "0x171"  current:  "0x22c"

When I run wfview with server function (on the RADIO side with ssh -X) it consumes around 54% of CPU - audio is breaking.

Funny but then on the client side wfview likes to Core Dump.

On the client side wfview is not coredumping when I connect directly to LAN of ICOM…

Wondering maybe its as simple as my RPI does not have enough power?

As a reminder it is:

Raspberry Pi Model B Rev 2 512 MB RAM… one of the very first RPIs… :wink:

pretty sure it’s not enough no.

wfserver is definitely quite lightweight when compared to wfview, but it still needs significant resources. I have never tried it on anything less than a Pi3B, so I suspect an original Pi might not have sufficient power?

The BCM2835 is a single core CPU, so if you are seeing 94% CPU usage with audio breakup and packet loss, I suspect that the Pi just can’t keep up.

You can check which thread(s) are using the majority of CPU (I suspect the audioConverter() threads) using the command:

ps -T -p <pid of wfserver>

73 Phil M0VSE

Just ordered RockPI 4SE (due to RPI unavailability) and will get back after deployment;)

RockPI 4SE 4GB RAM, with Armbian on uSD card, no heatsink - its getting really HOT;)

wfserver build (make -j2) 3 minutes 30 seconds
wfview build (make -j2) 6 minutes 10 seconds

Ok I have some additional debug information…

I have connected my IC-705 to RockPI with wfserver then over LAN to my notebook with wfview…
And… I do not know if it is expected but “connection establishment” takes… 1 minute.

From client log:

2023-02-28 23:37:39.992 DBG udp: Single radio available, can I connect to it?
2023-02-28 23:38:40.117 DBG udp: udpHandler Sending Token request:  5

From server log:

2023-02-28 23:37:39.881 INF udp.server: "::ffff:" : New Control connection created
2023-02-28 23:37:39.882 INF udp.server: "::ffff:" ( "Control" ): Received 'Are you there'
2023-02-28 23:37:39.884 INF udp.server: "::ffff:" ( "Control" ): Received 'Are you ready'
2023-02-28 23:37:39.889 INF udp.server: "::ffff:" : Received 'login'
2023-02-28 23:37:39.889 INF udp.server: "::ffff:" : User  "sq6emm"  login OK
2023-02-28 23:37:39.890 INF udp.server: "::ffff:" ( "Control" ): Sending Login response:  1
2023-02-28 23:37:39.892 INF udp.server: "::ffff:" : Received create token request
2023-02-28 23:37:39.893 INF udp.server: "::ffff:" ( "Control" ): Sending Capabilities : 2 for ""
2023-02-28 23:37:39.893 INF udp.server: "::ffff:" ( "Control" ): Client will have TX audio
2023-02-28 23:37:39.893 INF udp.server: "::ffff:" ( "Control" ): Sending ConnectionInfo : 3
2023-02-28 23:38:40.019 INF udp.server: "::ffff:" : Received token request
2023-02-28 23:38:40.020 INF udp.server: "::ffff:" ( "Control" ): Sending Token response for type:  5
2023-02-28 23:38:40.023 INF udp.server: "::ffff:" : Received request for radio connection
2023-02-28 23:38:40.023 INF udp.server: "::ffff:" ( "Control" ): Sending Status
2023-02-28 23:38:40.024 INF udp.server: "::ffff:" ( "Control" ): Sending ConnectionInfo : 607
2023-02-28 23:38:40.025 INF udp.server: "::ffff:" : rxCodec: 64  txCodec: 0  rxSampleRate 48000  txSampleRate 48000  txBufferLen 150

And even after that, wfview-client is showing (no tx) ???:

While on server side, we can see:

2023-02-28 23:37:39.893 INF udp.server: "::ffff:" ( "Control" ): Client will have TX audio

The performance of server-side is no longer a problem, CPU load is less than 5% during complete period.

test-server-log.txt (248.0 KB)
test-client-log.txt (183.4 KB)

Okey. This situation:

1 minute delay on “Connect” and (no tx) happens only IF radio is turned OFF and wfserver is started.

If I will turn on the radio manually then run wfserver and then connect - all will work (no 1 minute delay and no “(no tx)”).

The radio MUST be on when wfserver is started as it needs to be able to query it for model information. If it isn’t on, the detection doesn’t happen (so wfserver doesn’t know that the radio has TX and various other settings)

I can’t really think of a way around this, short of forcing the radio to switch-on if no response and put it back in standby? By the time the client connects, it is already too late!

73 Phil M0VSE

So in short.
This is an expected behavior? and that 1 minute timer is also something by design?