Embedded WiFi in X-Air/ M-Air tests

[WK154]

OK, so in order to have a reproducible test procedure I decided to start from the beginning. Only using my MR12 (the most sensitive) I restored FACTORY settings that's that 10 second paperclip routine. This was never done since I received my unit. As a point of interest, in it's history it received at least 2 firmware upgrades since without anything other than reboots. Want a laugh about the "Factory Reset" values, well it's a tribal secret, no documentation anywhere (a dirty word with the new tribal council elders. Hmm' wonder what their smoking  ). You can make a copy of the various menus but that would only be for your unit, nothing for a reference comparison. I started this test on 12/26/18 6:21PM with the PC V1.5 MR edit program. It still has firmware V1.17.NO connection failures after 91 hrs. So I added the iPad and the Android for more activity. It lasted for an additional 2.5 hrs. Fortunately I was there when it failed and the PC version of course needs intervention to continue but the iPad was flashing disconnect notices several times, but continued on, the Android never flinched. This AFAICT is due to the loss of Beacon messages and when to consider the connection broken. This varies with the control surfaces (PC, iPad, Android). The MR12 did not hang and the test continued. Quite a difference from previous results where the MR12 needed to be power cycled to recover. On 1/1/19 the iPad locked up and only a reboot recovered it, the same iPad that ran a browser for 6 days straight streaming audio and videos from U-Tube. You be the judge I call it a bug. The iPad lost connection briefly again 13 hrs later but continued. On 1/1/19 at 9:45PM I added the fourth control surface to the test, an Android Galaxy  View running Mixing Station. The PC disconnected again on 1/2/19 at 12.39AM but I reconnected it without issues. So far only the Androids have had no connection problems. I will terminate this test after 48hrs on Mixing Station use after 1/3/19 9:45PM. The conclusions are however already obvious:
The iPad App can crash iOS, not good and disconnects but recovers otherwise.
The PC app has disconnects as well and requires intervention to continue but doesn't crash W10.
The Androids so far are the winners with no disconnects. Kudos to Google and Dave Schumann.
With all that said I would not recommend using it for a gig even with Androids since the real problem lies outside of your control called phones. Most WiFi routers can only handle 50 clients (ie. Airport Express). 2.4GHz congestion is the real problem that at present can be avoided with the 5GHz band or wired.
Clearly when updating the firmware/software a FACTORY reset should be performed after the update and a reboot. I have not tested the effect of reloading saved shows/snapshots from prior versions. Clearly there are issues with the update process. This is a temporary workaround.
Additional info on test parameters are:
 A 30ft separation and two walls existed between the MR12 and control surfaces typically at -60 to -65 dBm, near the limit of the range. One e-835 on channel 1 picking up room noise and a signal generator on channel 2 for more activity. This test of course only applies to the hardware and software version used in the test YMMV. I will update the final results.

UPDATE:
The test continued with failures of iPad and PC several times more. The iPad required terminating the App and restarting it but no problem with the MR12 as prior to the Factory reset times. The PC just needed the reconnect intervention (click on messages) to continue. Androids just continued to work throughout this. After the 48hrs I set for Mixing Station I decided to add an additional control surface, a PC. Everything is still running just fine even with five control surfaces. Four is clearly not a hard limit just one defined by Microchip for their software.

Now for the conclusion. I would NOT recommend AP mode for anything other than practice when you can maybe afford a loss of control. It's clear to me that there are issues with the firmware and the issuance of Beacon messages (the heartbeat of WiFi) that causes the various Apps to stop communicating. I would use the wired connection for Firmware updates and gigs. Test finally terminated 1/4/19 10:00 AM with everything working.
Cheers

[WK154]

Next will be a long-term test of the wired connection that I've used all along. Hope it survives.
Cheers

[WK154]

Long term wired test started 1/8/19 10:00 PM. I am using the LAN mode with DHCP Server enabled. I have two PC's and one Android connected via a switch (Dlink). It's now been 25 hrs. and all is well.

Update: 1/10/19 10:36 now at 48+ hrs. and all is well. Displaying pink noise on channel two EQ with RTA which should generate a lot of communications traffic.

[WK154]

It's now 73 hrs. and all is well. I also added another PC to the mix now having four control surfaces. I'll let it go a little longer but it's pretty clear that none of the AP problems exist.

[WK154]

It's been 96 hrs and all four control surfaces are working. Clearly a change from AP mode. Terminated test at 1/12/19 11:32PM.
Conclusion: Wired LAN mode is solid as opposed to AP mode. Android's are even solid in AP mode. AP mode has RTOS delays far in excess of what is required by both iOS and W10 Beacon expectations causing a disconnect. iOS is approximately 2 sec. and W10 slightly more but Android is 6 sec. as per error message. The MR12 RTOS delays need to be looked at and fixed. There are many more modes to evaluate but I will leave that to someone else. It's also quite clear that a Factory reset is required after any Firmware or App update at the present time.
Cheers

P.S. Actually the test ran for another 2 days without a problem till I really shut it down for the wireless test. That's about 144 hrs.

[WK154]

I did need to test the most likely setup for wireless control. The location was the same 30ft. plus 2 walls giving about -60 to-65 dBm at the control surfaces at 5GHz channel 44. Channel 44 was also shared with my main WiFi router Nighthawk (Tri-band) that was only 2-5 ft. away from the control surfaces (-25 to -30 dBm). Yes it knows how to share on the same  frequency. I was using a EA 6350 Linksys (Cisco, now Belkin) AC1200 unit (at least a 4 year old unit) . The WLAN (Wireless Local Area Network) window poorly named by the Tribe and not to be confused with WAN (Wide Area Network on your router). The SSID is the one established by the EA 6350 (the Access Point) unfortunately and incorrectly changed by the App to, in my case, MR12-xx-xx-xx which is wrong! This certainly can add to the confusion for additional control surfaces trying to use this information. Fortunately the IETF sets the standards not the Tribe  . Since when does an App override typed in and applied data? Tribe needs to fix that ASAP. The test started at 1/16/19 at 9:00 PM. So far so good with 2PC's (W10), one iPad 3 and one Android running Mixing Station. There also has not been any noticeable loss of Beacon messages from the Linksys.

[WK154]

It's now been 48 hrs. and no disconnects have happened. Beacon messages (packets) issued on a consistent regular basis by the AP (Linksys) is the reason for this results. I believe that a loss of Beacon packets is the reason for iPad and even PC disconnects that are the cause with the internal AP. There are also reasons not controllable by the mixer or router that would cause this as well. The most obvious is a high activity on a specific wavelength which would delay the Beacon packets as can happen with a high concentration of cellphones looking for Internet connections. So for now the 5 GHz bands are still sparsely used. How long this will last is anyone's guess. At that point wire or another frequency band will be the reliable solution. IoT will certainly not help with this. It would also help if the disconnect decision of the iPad and PC would be closer to the criteria used by Androids.

P.S. For those of you new to this it was determined five years ago with the DL1608 and external WiFi routers.
http://cacophony.aspinock.com/index.php?topic=188.msg898#msg898

[WK154]

After 63 hrs. I'm pulling the plug on this test. With three PC's (one wired) two Androids and one iPad 3 all working just fine. So the conclusion for now is if you update or even just received your unit from the "Factory" do a FACTORY reset (paper clip) then reboot Buy yourself a current /AC router (5GHz) or go wired to do gigs. There are enough other things to deal with and learn.
Cheers

[WK154]

For those of you that are in the market for a WiFi router you may want to future-proof your purchase by considering a 802.11ax unit if your budget allows. It will no doubt take more time before Tablets catch up to this spec but it has been available since late 2017. I would expect the next batch of new gear to have this in 2019. Even some 802.11ac gear can benefit from the /ax version. For those of you not into Networks the /ax spec isn't about more speed it's about dealing with the very thing that we are talking about, traffic density.

[WK154]

Just received my new toy a WiFi sniffer (Openwrt based) that can monitor one channel at a time for Wireshark and I caught the MR12 in AP mode dropping Beacon frames on a fairly regular basis. This is with no control surfaces active, just my WiFi-Analyzer making occasional discovery requests. Next I'll stress it with 4 control surfaces and see what happens. This already is a clear indication that the MR12 AP can't handle a lot of network load.

[WK154]

OK at a control surface of four plus and other minimal local traffic I was getting a range of 6-10 Beacon frames per second. That is in the functional range (no disconnects). It is however quite a large range when the expected average is 9.8 based on the 100TU (102ms).  The 6 frames per second interval had quite a bit more traffic than most, so if additional traffic exists it can very well cause termination of the connection. That of course depends on the control surface logic and what criteria they use. Since failure intervals are quite long using my surroundings it is really best dealt with Firmware debug tools. That's a job for the Tribe (Jan Duwe & Co.) not me.

[WK154]

After all this time I finally had to power cycle the MR12. So there is more to this than what I found. I guess the Music Tribe has their work cut out for them. 1/31/19. I had a Android and a iPad running with the MR12. Neither could get a connection after they disconnected.   This was in AP mode. Power cycling a mixer is not acceptable during a gig.

[WK154]

Since I had the test setup for MF5.1 I thought it would be an opportunity to revisit this test. The only difference is the mixer this time it's the MR18 instead of the MR12. After 50+ hrs. the same conclusions still stand. The router was also different (Netgear R7900) along with the distance of only 15 ft. to the router. I had 13 instances of M-air running 3 more than the MF5.1 test. All the M-air apps for Windows were V1.5 with the V1.6 firmware. The control surfaces were:
Windows ---- 5 units with all but one running W10 and one W7. The W7 also had instances of M-Air and Bluestacks Android Mix Station running. A wired connection no failures. One other W10 was wired the rest on WiFi.
Android ------ 5 units and as before no disconnects using WiFi. None were wired.
iPad ---------- 2 units a iPad 3 and a iPad 2018. The Ipad would loose connection but recover without intervention.
Still the same conclusion as the Mackie MF 5.1 use wired as a minimum and in MF's case use a Windows tablet for the highest reliability of the lot For M-Air/X-Air that would be the Android version.