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…
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?
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?
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…
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;\
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…
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:
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:192.168.100.22" : New Control connection created
2023-02-28 23:37:39.882 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Received 'Are you there'
2023-02-28 23:37:39.884 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Received 'Are you ready'
2023-02-28 23:37:39.889 INF udp.server: "::ffff:192.168.100.22" : Received 'login'
2023-02-28 23:37:39.889 INF udp.server: "::ffff:192.168.100.22" : User "sq6emm" login OK
2023-02-28 23:37:39.890 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Sending Login response: 1
2023-02-28 23:37:39.892 INF udp.server: "::ffff:192.168.100.22" : Received create token request
2023-02-28 23:37:39.893 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Sending Capabilities : 2 for ""
2023-02-28 23:37:39.893 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Client will have TX audio
2023-02-28 23:37:39.893 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Sending ConnectionInfo : 3
[...]
2023-02-28 23:38:40.019 INF udp.server: "::ffff:192.168.100.22" : Received token request
2023-02-28 23:38:40.020 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Sending Token response for type: 5
2023-02-28 23:38:40.023 INF udp.server: "::ffff:192.168.100.22" : Received request for radio connection
2023-02-28 23:38:40.023 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Sending Status
2023-02-28 23:38:40.024 INF udp.server: "::ffff:192.168.100.22" ( "Control" ): Sending ConnectionInfo : 607
2023-02-28 23:38:40.025 INF udp.server: "::ffff:192.168.100.22" : rxCodec: 64 txCodec: 0 rxSampleRate 48000 txSampleRate 48000 txBufferLen 150
[...]
And even after that, wfview-client is showing (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!
