WiFi Shield packet loss

[posipunk]

WIFI Direct connect from Windows 10 PC to Wifi Shield + Cyton + Daisy - all with latest firmware/software.
Sampling at 1000Hz 16 channels we will drop 50-60 contiguous packets rather often (~1 minute) with smaller drops more frequent.
Environment has a lot of 2.4GHz devices in range (though not adjacent to setup).
What we've tried so far:
Have tried TCP and UDPx3, have tried dropping the sample rate to 250Hz and dropping down to 8 channels. Performance was sometimes improved but not perfect.

We only need 8 channels and 250Hz but highly desirable to get 1000Hz and 16 channels.
We did get the SD card working so we can always pull off data later but we ideally can stream it live.

1, Is there a particular setup which will give us the highest probability of little to no dropped packets?
2. Is there a general performance tradeoff list we can use to tune? (i.e. 8 channels will always get you better performance than 16)

[produceconsumerobot]

Hi @posipunk ,
Sorry you're experiencing dropped packets!

In general, wireless communications can be challenging in 2019 where more and more devices are hopping onto the limited number of bands in the 2.4GHz spectrum. It can sometimes help to understand what your wireless spectrum looks like and there are a number of available tools to make that possible https://www.ittsystems.com/wifi-analyzers-for-windows/

We're constantly working to achieve the highest reliability of transmission. Be sure to check that you're using the latest version of the firmware https://github.com/OpenBCI/OpenBCI_WIFI/releases

If that doesn't solve your issues, there are a few things you can try to improve the data transmission.

• One option is switching between TCP and UDPx3 as you mentioned you've already tried. TCP is "guaranteed" packet transmission, but network hiccups can be problematic for the limited CPU resources on the wifi shield and potentially cause buffer over-run data loss. UDPx3 avoids these network hiccup issues by simply sending each data point multiple times and not waiting for transmission confirmation. While not "guaranteed" we've found that it can sometimes be more reliable than TCP (we actually learned about this approach from a group of smarty pants at NASA).
• Another option is to try different latency settings. Which setting works best on any one computer/wifi card will vary, but in general longer latency gives the wifi shield a little more room to handle network hiccups. However, if the latency gets too long, it's possible to over-run the ring buffer that's storing the EEG data before sending. Particularly at higher sampling rates, it's important that you don't make your latency too long. Pro tip: We offer 3 options for setting the latency, but you can actually try out any latency you want by manually sending rest messages to the wifi shield directly per the api at https://app.swaggerhub.com/apis/pushtheworld/openbci-wifi-server/2.0.0
• If those options don't solve your dropped packet issue, you might consider using a dedicated access point (AP) rather than the soft AP on the wifi shield. There can be bit of variability from computer to computer in the strength of the wifi antenna and host of other parameters. Using a dedicated router with burly antennas and dedicated networking can help improve packet transmission in these cases. Here is one such router option for $25 https://www.amazon.com/gp/product/B003Y5RYNY/ref=oh_aui_search_asin_title?ie=UTF8&psc=1

Thanks for submitting the issue. Sorry for the delay getting back to you and I hope this helps solve your problems!

[Joe-Westra]

I was also having a packet drop issue which I raised in the OpenBCI discussion forum, and was requested that I share the post here:

-I was initially using 1000hz and 16 channels with 10ms latency over both
TCP and UDP. As per your suggestion, changing to 5000hz while using
TCP reduced the packet drop issue to an occurrence ~once every 5
minutes. Using the UDP protocol at 10,000hz seems to be even more
reliable, however my sample size is small at this moment.

-After 10 minutes, there were no packet drop issues when using Bluetooth.

-When attempting to use the WifiShield and UDPX3 I receive an error message
stating that the WifiShield firmware is out of date, which prohibits UI
initialization and data streaming. WifiShield firmware is V 2.0.5 (which
is the most current version on https://github.com/OpenBCI/OpenBCI_WIFI/releases)

What firmware version is required for the WifiShield to use UDP x 3? FTR
I have tried downloading the pre-compiled version of the OpenBCI GUI (v
4.0.3) and Hub (V 2.0.4) but I receive the same error message when
attempting to use UDPx3.

[produceconsumerobot]

@Joe-Westra thanks for the description of your UDPx3 issue! We'll attempt to replicate on our end and get back to you. To help us run down the issue, would it be possible for you give us the details of your configuration: OS/version, hardware/versions, FW/versions and any other specifics about your system you think might be relevant?
Thanks! -Sean

[wjcroft]

Jason Paquette ('alwayswearshats' on the OpenBCI forum and @paquettejp on Github) , on this thread,

https://openbci.com/forum/index.php?p=/discussion/2108/measured-shield-regulated-3-3v-supply-has-6v-dip-at-1-second-intervals-with-resonant-ringing

Has found a way to eliminate packet loss, by adding a capacitor on the Wifi Shield. Previous to this, the high current demands (400 mA!) of the ESP8266, were causing droops in the regulated 3.3V DC power supplied to the ESP. With the cap, packet loss seems to be gone.

@Joe-Westra , have you tried running the GUI from Processing IDE? Your 2.0.5 shield firmware should be current.

https://docs.openbci.com/OpenBCI%20Software/01-OpenBCI_GUI#the-openbci-gui-running-the-openbci-gui-from-the-processing-ide

Regards,

William

[wjcroft]

Please see this related issue on the GUI repo:

OpenBCI/OpenBCI_GUI#231
"Strange cyclical noise spikes w/ WiFi Shield"

This was really a hardware issue, but it got logged on the GUI repo. My impression is that the issue should be flagged on both the Wifi and GUI repos, so that it is not forgotten. ALSO, the title of this issue thread should be edited from reading: "WIFI Direct dropped packets" to "WiFi Shield dropped packets". As the packet loss due to power supply issues is not limited to only Wifi Direct mode.

There are multiple repos for the Shield on Github, at least three that I can see. This is the only repo that is logging issues, so it makes sense that it continue to do so. The other repos have ZERO issues logged, even though they are more hardware related.

William