Would love to see this resolved.
Oddly, my new 2020 HP omen laptop does not seem to have this issue. Both of my desktops have USB wifi cards, and they do have this issue. It’s not a huge deal because you can close pitool… but i prefer to have it auto-start with windows. Having to close it just to use the internet is pretty annoying, but I’m used to it at this point!
Yepp, just not starting PiTool or closing it after reconfigurations was my solution also. Now that Pimax Experience is autostarted when the headset starts and afaik PE needs PiTool running in the background, it might become more interesting to get a proper solution here.
You should be able to check in Device Manager to see where your Mobo’s Wifi is connected; though usually they are an m2 laptop card. Plan on upgrading mine sometime in the future.
Likely an idea to build a list of Wifi mfgr and how it is. Connected ie m2, pci, usb that are having issues as it can be hard to identify cause if it is not common to all mfgrs and interfaces.
Nope, seems to be PCI-E, it is a Realtek 8822BE chip which is the onboard WIFI for the STRIX ROG B350-I Gaming motherboard.
Just retried it with the current PiTool, I even get the effect when no Pimax headset is connected.
Mine seems to be Intel
ROG Strix B450-I Gaming features Intel 802.11ac Wi-Fi with 2x2 MU-MIMO and wide 160MHz channels, for wireless speeds of up to 1.73Gbps — so you’ll get fast, smooth transfers, even when your rig is further away from the router.
Ok, might have changed between B350-I and B450-I then. Besides PiTool the wifi chip does what it should. Also had the same problems with this USB WIFI adapter that was based on Realtek RTL8812AU (don’t have it anymore):
Perhaps Realtek is a pattern here? If that is the case then it shouldn’t be difficult to reproduce, when getting a random wifi card then chances are high that it contains a Realtek chip 
Indeed Realtek is fairly common widespread used components. This type of info can make it easier for them to maybe implement a fix.
Best to use integrated ‘gaming motherboard’ network devices, or some server type Intel NIC, or maybe a PCIe WiFi device with excellent review statistics on Amazon. USB network interfaces in my experience have had some very subtle abnormal behaviors, that cause pernicious malfunctions further up the OSI model, affecting everyone with packets routed through such devices.
Another trick, the best of all, is to get one of these routers, and use it as a WiFi-to-Ethernet adapter. Downside is you may have to wade through a somewhat slow web interface to connect to different WiFi hotspots.
Myself, all versions of PiTool are not having such problems with my motherboard integrated PCIe WiFi and PCIe Ethernet.
I concur, with PimaxUSA on this… there is enough convergence of evidence to strongly suspect a USB problem.
I still feel as if this is a software issue considering it happens without the headset plugged in and powered.
Even if the result of this is ‘don’t use usb wifi’, there’s no reason pitool has any effect on USB in general without a device being communicated with
Software issue… or ‘firmware issue’… or ‘BIOS issue’… or even VHDL ‘hardware’ issue (which is more like a software issue).
I remember a long time ago the ‘Descent 3’ installer recommended some number of precautions to take when using USB audio devices. Nowadays those things aren’t so bad .
This is happening because consumer network devices in general are already often not mature, and now USB power management features and such are being added on top of that. The result is inevitably going to be some ‘software’ problems with weird things interacting with the drivers/firmware/BIOS. Then of course there is the fact that MSW is not a realtime operating system to begin with…
Only way to solve these sort of complexities is to use the simplest possible arrangement of well-established tech.
Network interfaces are so bad this sort of stuff happens even on Linux and BSD.
Next time you see Intel Gigabit Ethernet cards selling on Amazon or eBay for $100/port, or some old IBM SATA cards selling for $100/port, remember this topic. Folks like me are trading these 15+ year old ‘legendary’ devices around just to use their decent firmware/drivers in our servers.
FYI I have this same issue with my asus maximus X code motherboard, I posted about it late last year - I had to run ethernet through my house and have not turned the WiFi back on since. The exact same network activity pattern as above only when pitool runs
Well I would have to agree some are having a software issue. If no headset is plugged in/on and pitool running is causing network issues proven by killing pitool issue is resolved. Then something in pitool is interfering with some setups.
Network interfaces blur hardware and software issues badly. Network hardware is supposed to do TCP offloading and checksumming. Cheap (or rushed to market) network stuff wants the OS to do this. Usually, the hardware, or the OS doesn’t do something Internet Protocols fundamentally expect, even when that OS is Linux or BSD. Add to that multiple translations from CPU to PCIe to USB, and you have a recipe for disaster. This breaks protocols as basic as HTTP all the time.
Most users just don’t notice the occasional missed webpage reload.
Gaming/VR is realtime, which is not ‘most users’. Neither are server admins who hold onto PCI-X (yes, PCI-X) 15+ year old network cards because of this.
In this case, Pimax might be able to add a reasonable workaround for whatever is going on, or at least a warning message about USB WiFi.
When building VR workstations though, everyone needs to remember that we are building realtime systems here.
Would you feel comfortable designing a 3D printer to send STEP/DIR signals to the motors over a USB WiFi dongle with an unknown chipset, connected to a USB controller with an unknown chipset, shared with other unknown USB devices, with all of these things having unknown buffers and error rates at every layer, and protocols that just drop connections when some of these failures happen?
I don’t. But with a conservative approach and some testing, I am planning to directly control 3D printers by commodity PC hardware. When we build VR workstations, we must do the same.
The OP’s issue report should be a sobering reminder to us of the reality that we are putting humans in flight simulators connected to motion control hardware, all driven by many layers of fundamentally not-realtime systems.
So, please, buy decent hardware.
EDIT: Offtopic, I am seriously considering selling ready-to-go VR PCs with some very innovative features.
This is Pimsx interpretation of Wifi6.
Uh…if this is the barrier to entry to enjoy a Pimax then
I’M OUT a liitle extra FOV ain’t worth this.
Goes and buy literally any other headset. 
Except we have also a report thar it is not just usb wifi. See above.
So there are also cases with pciX wifi from gaming motherboards.
Yes, my motherboard is a high-end ASUS model from late 2017 at £350 RRP with 2x2 802.11ac Wi-Fi. I never had a single issue using the onbaord wifi for real-time applications such as p2p lag-free wireless display mirroring/miracast.
Then pitool came along and I had to buy 20m of ethernet, a network switch, then lift carpet & floorboards and drill several holes as a workaround…
(Oh this saga also involved buying & returning 2 separate sets of Netgear Orbi mesh routers that I initially blamed for the dropouts before later realising it was Pitool)
I was already surprised my buddies makerbot can accept step files over wifi. I’m plenty happy with my basic ol ender 3, but that’s a cool idea.
Also, what you said is true on windows not being an RTOS attempting real time applications. But the same can be said for any PC os, mac or linux (outside of RTlinux). Definitely makes embedded work harder (my only experience is with rtos). I’m sure NASA’s old vr setups ran on some rtos though
Obviously this is occuring at a far different frequency than the usb polling rate. I don’t think pitool should be interfacing with hardware without having a device plugged in. I’m no CS so I’ll botch this statement - but if APIs are used to interface directly with hardware, they should be paused until comms are established.
Nothing can be done now, but there are a lot of ‘usb’ issues with pimax, makes me wonder if usb 3.0 would’ve helped.
I wouldn’t care if my wifi was being interrupted while I play as I don’t play many multiplayer games. If I did, i would just wire in.
Interesting part is also that the problem only occurs with PiTool running, using Pimax headsets with the PiTool closed leads to no issues with WIFI. I would understand if the drivers or services would require some high prio threads in order to guarantee a steady framerate. But PiTool is just a configuration tool.
I am pretty convinced that the current behavior isn’t a necessity and could be solved better.
