Difficulty getting wfview on RPI to connect with IC-705

Hi there,

So I have a headless RPI setup as a portable wifi hotspot for portable use in the field, and I have connected the IC-705 to the RPI and I have connected my phone to the RPI.

I can ping the IC-705 from the RPI directly and from the phone, but I don’t understand why I am getting such delayed pings----between 250 and 900ms from the phone and slightly better direct from the RPI. That dosent make sense to me with the phone and the 705 just inches from the PI and nothing else connected here in testing at home but it is an overall improvement from when the IC-705 batter saver was on which apparently was the cause of even worse results.
First question, is that normal with an IC-705? What is an expected response time to a ping to a 705?

I have wfview installed on the RPI, I have confirmed that I have the correct username and password in wfview, but I can’t connect to the RPI. The log would seem to indicate a problem with lost packets, but why?

Also, is it possible that this setup is not compatible with wfview? The ic-705 being in station mode, with the RPI as a hotspot AND the RPI being where wfview is operating from?

73 and thanks!
Tom

I apparently can’t upload a log file yet as a new user but here is a text excerpt:

2023-01-26 13:50:17.116 INF udp: Closing UDP stream : “10.0.0.143” : 50001
2023-01-26 14:04:29.993 INF udp: Starting udpHandler user: “N2YTF” rx latency: 312 tx latency: 314 rx sample rate: 16000 rx codec: 4 tx sample rate: 16000 tx codec: 4
2023-01-26 14:04:29.994 INF udp: UDP Stream bound to local port: 49852 remote port: 50001
2023-01-26 14:04:29.997 INF system: Received CommReady!!
2023-01-26 14:04:29.997 INF default: Setting rig state for wfmain
2023-01-26 14:04:29.998 INF default: Setting rig state
2023-01-26 14:04:31.124 INF udp: udpHandler : Received I am here from: QHostAddress(“::ffff:10.0.0.143”)
2023-01-26 14:04:31.124 INF udp: udpHandler : Received I am here
2023-01-26 14:04:31.160 INF udp: udpHandler : Received I am here from: QHostAddress(“::ffff:10.0.0.143”)
2023-01-26 14:04:31.161 INF udp: udpHandler : Received I am here
2023-01-26 14:04:31.434 INF udp: udpHandler : Received I am ready
2023-01-26 14:04:31.435 INF udp: udpHandler : Sending login packet
2023-01-26 14:04:31.613 INF udp: udpHandler : Received I am ready
2023-01-26 14:04:31.613 INF udp: udpHandler : Sending login packet
2023-01-26 14:04:31.947 INF udp: Got connection type: “FTTH”
2023-01-26 14:04:31.948 INF udp: udpHandler : Token response did not match, sent: 61411 got 64498
2023-01-26 14:04:31.948 INF udp: udpHandler : Detected connection speed FTTH
2023-01-26 14:04:31.978 INF udp: udpHandler : sending request for missing packet : “0x3”
2023-01-26 14:04:32.078 INF udp: udpHandler : sending request for missing packet : “0x3”
2023-01-26 14:04:32.178 INF udp: udpHandler : sending request for missing packet : “0x3”
2023-01-26 14:04:32.278 INF udp: udpHandler : sending request for missing packet : “0x3”
2023-01-26 14:04:32.378 INF udp: udpHandler : No response for missing packet “0x3” deleting
2023-01-26 14:04:33.078 INF udp: udpHandler : sending request for multiple missing packets : “06:00:06:00:07:00:07:00:08:00:08:00:09:00:09:00:0a:00:0a:00:0b:00:0b:00:0c:00:0c:00:0d:00:0d:00:0e:00:0e:00:0f:00:0f:00:10:00:10:00”
2023-01-26 14:04:33.178 INF udp: udpHandler : sending request for multiple missing packets : “06:00:06:00:07:00:07:00:08:00:08:00:09:00:09:00:0a:00:0a:00:0b:00:0b:00:0c:00:0c:00:0d:00:0d:00:0e:00:0e:00:0f:00:0f:00:10:00:10:00”
2023-01-26 14:04:33.278 INF udp: udpHandler : sending request for multiple missing packets : “06:00:06:00:07:00:07:00:08:00:08:00:09:00:09:00:0a:00:0a:00:0b:00:0b:00:0c:00:0c:00:0d:00:0d:00:0e:00:0e:00:0f:00:0f:00:10:00:10:00:12:00:12:00”
2023-01-26 14:04:33.379 INF udp: udpHandler : sending request for multiple missing packets : “06:00:06:00:07:00:07:00:08:00:08:00:09:00:09:00:0a:00:0a:00:0b:00:0b:00:0c:00:0c:00:0d:00:0d:00:0e:00:0e:00:0f:00:0f:00:10:00:10:00:12:00:12:00”
2023-01-26 14:04:33.478 INF udp: udpHandler : No response for missing packet “0x6” deleting
2023-01-26 14:04:33.478 INF udp: udpHandler : No response for missing packet “0x7” deleting
2023-01-26 14:04:33.479 INF udp: udpHandler : No response for missing packet “0x8” deleting
2023-01-26 14:04:33.479 INF udp: udpHandler : No response for missing packet “0x9” deleting
2023-01-26 14:04:33.479 INF udp: udpHandler : No response for missing packet “0xa” deleting
2023-01-26 14:04:33.479 INF udp: udpHandler : No response for missing packet “0xb” deleting
2023-01-26 14:04:33.479 INF udp: udpHandler : No response for missing packet “0xc” deleting
2023-01-26 14:04:33.485 INF udp: udpHandler : No response for missing packet “0xd” deleting
2023-01-26 14:04:33.485 INF udp: udpHandler : No response for missing packet “0xe” deleting
2023-01-26 14:04:33.485 INF udp: udpHandler : No response for missing packet “0xf” deleting
2023-01-26 14:04:33.486 INF udp: udpHandler : No response for missing packet “0x10” deleting
2023-01-26 14:04:33.486 INF udp: udpHandler : sending request for missing packet : “0x12”
2023-01-26 14:04:33.578 INF udp: udpHandler : sending request for missing packet : “0x12”
2023-01-26 14:04:33.678 INF udp: udpHandler : No response for missing packet “0x12” deleting
2023-01-26 14:04:34.279 INF udp: udpHandler : sending request for multiple missing packets : “15:00:15:00:16:00:16:00:17:00:17:00:18:00:18:00:19:00:19:00:1a:00:1a:00:1b:00:1b:00”
2023-01-26 14:04:34.378 INF udp: udpHandler : sending request for multiple missing packets : “15:00:15:00:16:00:16:00:17:00:17:00:18:00:18:00:19:00:19:00:1a:00:1a:00:1b:00:1b:00”
2023-01-26 14:04:34.478 INF udp: udpHandler : sending request for multiple missing packets : “15:00:15:00:16:00:16:00:17:00:17:00:18:00:18:00:19:00:19:00:1a:00:1a:00:1b:00:1b:00”
2023-01-26 14:04:34.578 INF udp: udpHandler : sending request for multiple missing packets : “15:00:15:00:16:00:16:00:17:00:17:00:18:00:18:00:19:00:19:00:1a:00:1a:00:1b:00:1b:00”
2023-01-26 14:04:34.679 INF udp: udpHandler : No response for missing packet “0x16” deleting
2023-01-26 14:04:34.680 INF udp: udpHandler : No response for missing packet “0x17” deleting
2023-01-26 14:04:34.680 INF udp: udpHandler : No response for missing packet “0x18” deleting
2023-01-26 14:04:34.681 INF udp: udpHandler : No response for missing packet “0x19” deleting
2023-01-26 14:04:34.681 INF udp: udpHandler : No response for missing packet “0x1a” deleting
2023-01-26 14:04:34.681 INF udp: udpHandler : No response for missing packet “0x1b” deleting
2023-01-26 14:04:35.579 INF udp: udpHandler : sending request for multiple missing packets : “20:00:20:00:21:00:21:00:22:00:22:00:23:00:23:00:24:00:24:00:25:00:25:00:26:00:26:00:27:00:27:00”
2023-01-26 14:04:35.679 INF udp: udpHandler : sending request for multiple missing packets : “20:00:20:00:21:00:21:00:22:00:22:00:23:00:23:00:24:00:24:00:25:00:25:00:26:00:26:00:27:00:27:00”
2023-01-26 14:04:35.779 INF udp: udpHandler : sending request for multiple missing packets : “20:00:20:00:21:00:21:00:22:00:22:00:23:00:23:00:24:00:24:00:25:00:25:00:26:00:26:00:27:00:27:00”
2023-01-26 14:04:35.879 INF udp: udpHandler : sending request for multiple missing packets : “20:00:20:00:21:00:21:00:22:00:22:00:23:00:23:00:24:00:24:00:25:00:25:00:26:00:26:00:27:00:27:00”
2023-01-26 14:04:35.978 INF udp: udpHandler : No response for missing packet “0x20” deleting
2023-01-26 14:04:35.978 INF udp: udpHandler : No response for missing packet “0x21” deleting
2023-01-26 14:04:35.978 INF udp: udpHandler : No response for missing packet “0x22” deleting
2023-01-26 14:04:35.979 INF udp: udpHandler : No response for missing packet “0x23” deleting
2023-01-26 14:04:35.979 INF udp: udpHandler : No response for missing packet “0x24” deleting
2023-01-26 14:04:35.979 INF udp: udpHandler : No response for missing packet “0x25” deleting
2023-01-26 14:04:35.979 INF udp: udpHandler : No response for missing packet “0x26” deleting
2023-01-26 14:04:35.979 INF udp: udpHandler : No response for missing packet “0x27” deleting

Tom, N2YTF

What model RPi are you using ?

Hi Tom,

With the Pi, you must make sure that periodic wifi scanning is disabled, this will cause you endless headaches with wifi and USB interruptions at random times.

The log does show a lot of network issues. The IC-705 is known for it’s weak wifi implementation unfortunately. It is very picky. It will not work with wifi mesh, for example, and may have trouble with some other topologies.

Do I understand correctly that your IC-705 is joining a network being hosted by the Pi? Can you try changing things around, and having the IC-705 and the Pi join a network hosted by the phone? Or clarify if I’ve got this wrong.

–E
de W6EL

Its an RPI 4, I believe the 8gb version with a high performance SD card.

It is in a wicked aluminum case and that does limit the Wifi a bit but I do get 60ms pings between the iphone and the rpi.

73,
Tom

How do I disable periodic wifi scanning on the RPI? Is the RPI doing the periodic scanning if it is running as a hotspot?

Yes the IC-705 is joining a “network” hosted by the RPI. My phone is also joining the RPI hosted network. For testing at home I have the RPI connected to my home network via ethernet (so that I can type in and alter things from a laptop) but even not connected to the ethernet there is no difference.

Switching around this setup may be a bit beyond me, but also the phone is sending GPS data/time date to the RPI which I have found is superior to the IC-705’s internal GPS and I want to keep that. Also having the RPI act as the hotspot allows the setup to be universal…for example if I take out another rig that isn’t a wifi enabled rig I can use the RPI hotspot and connect the phone to it to run headless in the field with the other rig connected by USB or USB soundcard. If the RPI is not the “hotspot” then I will lose the universal solution aspect of it because the phone will have nothing to connect to in the absence of the IC-705. The goal here is for the IC-705 setup to be fully wireless, with the RPI receiving time from the phone, and keying and sending audio to and from the IC-705 all wirelessly. I hope this will cut down noise on quiet summits and improve RF resistance when using odd and closely placed antennas but who knows.

What is a typical ping response time for an IC-705 with a near perfect wifi connection? is there a long delay dictated by a slow IC-705 processor or something?

Thank you guys again for your help,
Tom, N2YTF

OK so more experimentation.

I connected the RPI to the home network via ethernet, and connected the 705 over wifi to the home network.

Pings from the RPI to the 705 in this configuration run from about 26ms to about 350ms—certainly not as good as I would expect but a big improvement. When my phone is on the same home network the pings are just about as slow, and maybe a bit slower…so the 705 is slow in responding to pings.

I can get wfview to connect to the 705 when the 705 is connected to the home network via wifi and the rpi is connected to the home network via ethernet…

So I think the problem here is the wifi connection between the RPI and the 705, but I am at a loss on how to improve it. And the problem appears to be unique to the 705 mating with the rpi on wifi, it is not something that affects my iphone connected to the RPI via wifi as the phone has fast pings with the RPI when they are simply connected together on the RPI’s own wifi network.

Any suggestions?

73,
Tom

PROBLEM SOLVED! Yahoo!

OK so I suspected that the IC-705 might have a simple WiFi chip in it, and that something sophisticated about the WiFi negotiation from the RPI in access point mode might be tripping up the 705’s wifi chip-----and it turns out that is the problem. The RPI WiFi connection needs to be dummed down.

My /etc/hostapd/hostapd.conf file now looks like this:

#2.4GHz setup wifi 80211 b,g,n
interface=wlan0
driver=nl80211
ssid=RPiHotspot
#hw_mode=g
hw_mode=b

#channel=8
channel=3

#wmm_enabled=0
macaddr_acl=0
auth_algs=1

ignore_broadcast_ssid=0
wpa=2
wpa_passphrase=1234567890
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP TKIP
rsn_pairwise=CCMP

#80211n - Change GB to your WiFi country code
country_code=US
#ieee80211n=1
#ieee80211d=1
ieee80211n=0
ieee80211d=0

The commented out parts followed by the new settings are what I had to change to get the system running smoothly.

Typical ping time now between the RPI hotspot and the 705 is less than 100ms…a 90% improvement and good enough it would seem to get wfview running. I did change the channel number as well but I don’t think that was the deciding factor, I believe it was the explicit disablement of the protocols beyond 802.11b that fixed the problems.

73 & thanks,
Tom, N2YTF

2 Likes

Hi Tom,

This is super interesting. I wonder how many 705 users have encountered this (unknowingly) from their home wifi networks?

Yeah the chip in the 705 is not the greatest. And it handles the UDP data stream as well (at the socket level), so it will be hard to do much in the way of firmware updates to address it.

Perhaps you can start a company selling a wifi AP designed for the 705? :slight_smile:

—E
de W6EL

Thanks Elliot!

You know I did a little more experimentation and I found that once everything is running, wfview, WSJTX, and gpsd with time coming from my phone to the RPI over wifi, the ping latency from the RPI to the IC-705 drops to below 2ms from under 100ms with nothing running. Oddly, although the ping program on the RPI is reporting under 2ms for pings, wfview is reporting about 150ms but seems to operate fine. DT in WSJT is slightly more than I would expect though.

I think I the ping delay time acts like this, counterintuitively going down the busier things got, because there is still some power saving feature enabled on the RPI’s wifi—I will look around for that but seems like everything works now fine even with that odd behavior.

I do wonder why wfview and the ping program report different delay stats.

Also now I want to figure out how to get the gps info flowing from the phone into WSJT-x’s Autogrid feature…

73 and thanks again for wfview!
Tom