This is a repost of my post to Cloudy Nights. I'm currently unable to open a bug report for the issues in this due to failure to upload logs.

Last night I had an especially hard night with the AAP 2.4GHz wifi connection with many lost connections, problems authenticating and poor wifi signal strength. Through the use of a couple of diagnostic tools I was able to isolate some of the problems and thought it useful to share my findings so others may benefit from what I found.

I use Ubiqiti Unifi wifi equipment in my house which provides useful information about each wifi client such as signal strength (RSSI) and which access point and channel the client connects to. I also used the wireless diagnostics, scan window built into macOS to observe what channel the AAP used for its broadcasted wifi SSID. I observed four distinct problems:

The OTA blocking the AAP wifi antenna causing a substantial reduction of signal strength of the AAP’s wifi SSID and the connectivity using ‘station mode’. By looking at the signal strength of the AAP’s wifi SSID signal using the macOS wifi scan I could see there was a large reduction of signal when the AAP’s antenna was blocked by the OTA. It went from an RSSI of -60 (good) to -80 (poor). After the meridian flip the AAP’s antenna was no longer blocked but I continued to have other wifi issues. BTW, if anyone has found a longer replacement antenna that works with the AAP, please post info on it.
In ‘station mode’ I observed the AAP fail to get an IP address from my dhcp server and then sit happily connected to my home’s wifi with an unusable IP address (the fallback IP address, 169.254.x.x, which doesn’t work). This likely happened when the antenna was blocked and my signal strength was poor. The fallback IP address was observed using Unifi’s console. This is something that ZWO could fix by retrying to obtain an IP address using dhcp and after a certain number of failures, disabling ‘station mode’ and disconnecting from the ‘station mode’s network. Just sitting connected with an unusable IP address misleads the user (me) into thinking the AAP should be reachable over the home network. By disconnecting I would be forced to use the AAP’s wifi SSID to reconnect and see in the wifi settings that it was no longer connected.
I observed the AAP selecting the worst channel possible for 'station mode'. This by far was the most frustrating problem of the set of problems I ran into last night and took quite a while to find a work-around. After I get my rig polar aligned using the AAP’s SSID, I would like to use ‘station mode’ to monitor the session from anywhere in my house. Provided that I haven’t hit problems 1 or 2 above and have a good signal this should be possible.

When a wifi device broadcasts an SSID for clients to connect to, it must do so on an individual channel. The channel is ether configured specifically or the device is left in auto mode to select a channel. Auto mode is usually completed by performing a scan of the environment to find which channel is the least congested and that channel is selected for use. The AAP doesn’t have a setting for the channel so it clearly is using auto mode. This is fine when not using ‘station mode’ and you are using the AAPs wifi to connect to it. However, when using ‘station mode’ the AAP does a scan of the nearby wifi networks and you select which one to connect to. In this case the AAP must switch to the channel of the SSID you select. It can’t broadcast its SSID on one channel and connect as a client to another SSID on a different channel. The device can only use one channel for 2.4GHz at a time.

My home network has three access points with each one configured to use a different 2.4GHz channel all on one SSID. This provides the AAP with a choice of which channel to connect to for ‘station mode’ and is the source of poor connectivity and authentication problems. There is a conflict of needs when a device is broadcasting an SSID for clients to connect to and also being a client of another wifi network (‘station mode’) at the same time. When broadcasting an SSID you generally want the least congested channel. When connecting as a client you want to connect to the strongest channel for the selected SSID. This is where the AAP fails to pick the right choice when in ‘station mode’. It is picking the channel based on the least congested channel and not the strongest signal. In my case channel 6 is the strongest channel (closest AP) for ‘station mode’ to choose, but the AAP routinely picked 11 or 1 to use for ‘station mode’ which provided especially poor signal strength for ‘station mode’ to use.

I would argue that this is a ZWO bug and it should switch strategies for selecting a channel when in ‘station mode’ to the strongest channel available that is being broadcasted by the selected home wifi network. There is a work-around for this problem that I used to force the AAP to use channel 6 but it may not be an option for many people who don’t use Ubiquiti for their wifi. I configured an additional 2.4Ghz only SSID that is broadcast only from the closest AP to the rig. This forces the AAP to switch to channel 6 to connect with ‘station mode’ and does not give it an option to use the poor signal channels.

I suspect the AAP wifi occasionally crashes. Prior to putting the work-around in place, I observed it switching channels spontaneously. I would see it on channel 11 or 1 and without making any config changes, disconnect and reconnect to another channel. It is either crashing or decides to disconnect from the poor 'station mode' connection and then pick the least congested channel again (good for its broadcasted SSID, bad for ‘station mode’ connectivity). Whatever the reason, when you combine problems 3 and 4 together it would frequently require that I walk outside next to the rig and connect to the ASIAIR_xxxx SSID to attempt to connect to the ‘station mode’ network again. Then since it keeps selecting the worst channels for ‘station mode’, frequently it would either not connect or get an authentication password problem using a saved known good password due to poor signal.