forum.pistar.uk

Hi all,

I just wanted to post here to share something quite strange I've encountered. And if this post may be helpful if anyone else is experiencing something similar or strange behaviour that they cannot get to the bottom of.

For ages I've had a strange problem with some of my Raspberry Pi MMDVM based hotspots, I have 5 hotspots and 2 out of those 5 often misbehave.
This week I'd had enough and decided to investigate, as I was using the hotspots a lot as I host a XLX server and I recently installed a pair of DvStick3003's and needed to give the transcoding a good workout with multiple different modes.

I re-imaged both hotspots and swapped out the PSU's but the issue remained.
What kept happening was on one hotspot that I was using for DMR I'd constantly get a "Not linked" then "Linking to" message after every other transmission, or I would lose access to the Pi-Star webpage momentarily and eventually it would come back or I would have to reboot the hotspot. On the other that I use for YSF I would get the same issue with the webpage and sometimes I'd get network packet loss.
After a bit of testing with swapping the Pi's out and swapping some MMDVM Hats over I opened a terminal and ran a continuous ping on every Hotspot here and noticed the following:

The first problematic hotspot is a Raspberry Pi Model 3A+, this has a MMDVM Dual HS Hat and is configured for DMR.
When I key up a DMR Radio I could see a lot of packet loss on each ping, then when the radio was receiving and the hotspot transmitting the same thing would happen again, on some occasions I would get a few "Request timed out", this absolutely coincided with the loss of the Pi-Star webpage and it dropping any links. As this is a duplex hotspot it is TX/RX'ing when I transmit in to it.

I then tried the second problematic hotspot which is again a Raspberry Pi Model 3A+ but has simplex MMDVM HS Hat, I connected to the YSF parrot and transmitted in to it, the ping was perfect with no loss. Then as soon at the parrot came back to me I started experiencing severe packet loss and a lot of "Request timed out"

I tried the same test on the other 3 hotspots, those are 2x Raspberry Pi Zero W's and 1x Raspberry Pi Zero 2 W.
No packet loss or any "Request timed out messages"

I swapped all the MMDVM hats around and the problem would stay with both of the Raspberry Pi Model 3A+ devices.
I did some more testing and discovered that the difference between all the hotspots was the fact that both of those 3A+ Pi's were connected over 5GHz. This problem was happening with every single MMDVM Hat I own (I have 3 different types) on any of the 3A+'s that was using the 5GHz WiFi band. Doing some further testing I noticed the issue was much worse on 434.000MHz than 438.800MHz.

Now what I don't know yet is, is this problem unique to the Raspberry Pi Model 3A+, I do have a Pi4 here that I will test them with this week, is it unique to specific WiFi channels. In this instance one of my 5GHz channels is Chan 52 5.256MHz which is very close to the 12th harmonic of 434MHz and my network also uses Channels 128 or 108, I have a mesh system in both the house and an outbuilding which is my workshop. On the particular day that I'm experiencing issues the hotspots just happened to be on Chan 52. Not every day do I experience these problems, I re-imaged both hotspots a few weeks ago and I did not encounter any problems for a while, which makes me think they were on a different 5GHz channel and the days where only the duplex hotspot is misbehaving the 5Ghz channel in use must be a harmonic of 438.800MHz.

I need to do some further testing to see if it is only the Pi Model 3A+ that is affected by this as the WiFi logic on those is directly next to the GPIO port and directly underneath the SMA connectors on a MMDVM Hat. I will also go through the frequencies on the MMDVM board and see what frequencies are harmonics of WiFi channels on the 5GHz band. Unfortunately none of my spectrum analyzers or communications test sets go up to the 5GHz range. I will do this test with a Pi4 however and report back.

I need to look in to a way of disabling 5GHz on my Hotspots, it may be possible to add a list of specific 2.4GHz channels/frequencies to the wpa supplicant file, but I don't know if that works on Pi-Star. It would be really useful if there was an option in Pi-Star to disable 5GHz WiFi.

I am unable to change WiFi channels or give an individual SSID to 2.4GHz and 5GHz WiFi bands on my MESH system.
I can put it in to 2.4GHz only mode, but that has a 10 minute timeout. So I need to find a way of disabling 5GHz on the hotspots themselves.

I would be really interested to hear if anyone else has encountered something similar.

I've had/have a similar problem but came to it via a different angle:

For a time, several of my hotspots would mysteriously drop their wifi connections but could not relate it to any specific activities or configurations on the hotspots themselves. But eventually, it became annoying and that's when I noticed they all were connecting on the 5G band. What was odd (for me, anyway) is that these hotspots were a mere 10 feet away from an extender. After playing with it for a while, I too came to the conclusion that 5g was not the way to go (particularly with Pi's) and thus restricted them to 2G. Easily done (for me) in that I had different SSID's for each band and could control access accordingly. (I should mention that I deployed 5G in stages, starting first with a secondary (wired) router before upgrading my main router later - but the problems with 5G and my hotspots continued even after switching router/location/distance. I found out later that 5g does not handle its "environment" quite that same as 2G - so, in my case, in spite of the short distance involved, they were communicating through several layers of plasterboard. 2G has better "penetration" it seems. So location, location, location).

But I still have the issue when out and about and connecting to other routers, potentially anyway, because those connections are transitory and too short lived to notice much in the way of disruptions. So I have considered using the wpa_supplicant file to restrict access, but haven't gotten around to following through with the thought, mainly because it seems like it may not work as advertised:

<https://raspberrypi.stackexchange.com/q ... 2462%20%7D>

Another option to consider: set up a secondary or alternate access point on your network with a different name and different parameters. Many routers support multiple AP definitions, so this could be an easy way out.

Hi KN2TOD,

That's interesting that you have had a similar problem albeit from a different cause.
Did you check the signal strength when you were connected to the 5GHz WiFi band?
I do wonder if the issue you were experiencing was actually related to the issue I discovered in my post, or at least partially.
If you get some spare time one day I'd be interested to know if you look at it again and run a continuous ping while connected to the 5GHz network and see if you get any packet loss when the hotspot itself starts transmitting.

I think for now I will have to just edit the WPA Supplicant file to restrict these 5GHz capable hotspots to the 2.4GHz channels/frequencies.
It would be really helpful if there was an option within Pi-Star to select WiFi bands as there are a few scenarios where 2.4GHz is preferred.

Unfortunately the Mesh system I have does not have the ability to create additional AP's or channel selection.
It does not even have a web based configuration page or any form of logging which is extremely annoying, you have to use an app on a smart phone/tablet to change any configuration.

My analysis was casual/circumstantial and did not involve special equipment or extensive testing via pings, etc.

Rather, my phone wifi analyzer app gave me this, taken within 2 feet of main router:
But going straight to the most effected component in the chain, I run this command chain to get meaningful results on specific hotspots:
yielding these results (for a select few of my hotspots):
In general, the results show fairly consistently that 5G has the poorer range (and hence the greater chance of transmission errors). The phone app also shows, in real time, that the 5G signal strengths vary a bit more, up or down than 2G, also leading to greater chances of dropped packets and/or connections. And, as I mentioned before, location/location/location: I can move a hotspot a foot or two in either direction and get significant differences in results/performance. Not unexpected, as I have a rather noisy "shack" to begin with.

(Also, to be fair, I should mention that I'm using some "ancient" NETGEAR equipment here that is several cycles behind the times, so ... YMMV.)

Perhaps you can "dumb" down your connections: get (or borrow) an extender of some sort and work with it to see if you restrict your HS's to 2G. Or see if you can get the "freqs=" line in the wpa_supp file working.

---

And ... thanks for posting your query. It's nice to know that one is not alone in suffering the slings-n-arrows of all this technical BS ... er ... wizardry!

I've managed to find a work-around for now, I can get it to stay on 2.4GHz by changing the ssid to bssid in wpa_supplicant.conf and then specifying the MAC Address of the 2.4GHz radio on my router. That will work fine here, but that is not an ideal work around for anyone using a 5GHz hotspot "portable" and connecting to other networks that have a shared SSID for 2.4GHz and 5GHz.

@KN2TOD

Those 5GHz levels on your router looks strong enough to not have any transmission errors, if you ever get some time spare and don't mind messing around it would be interesting to know if you do get the same issue as me with harmonics when the MMDVM board RF TX's

Unfortunately I'm reluctant to add more WiFi AP's here as the system I have here has worked absolutely flawlessly, it's been incredible in fact.
I get no issues with WiFI throughout the house, gardens and outbuildings and I would have to add more AP's for the hotspots in those locations, I get a throughput of well over 1Gbps over WiFi. Although it's limited in it's configuration it just works, I was adamant I wouldn't use it when I had a new line installed here, but I gave it a go and it's been refreshing to have a WiFi network that I don't need to mess around with after all these years.
This has been the only issue I've had to be fair and it's not really the router/mesh's fault.