Streaming BLE5 PHY data rates

[joshbrew]

Hey everyone,

I'm working on nRF52 firmware and it has 2M BLE PHY, I'm about to get about 250bytes at 30 updates/sec but it's not terribly stable, would like to do a lot more but that seems impossible right now. Is there a way to guarantee a stable stream at higher throughputs? I'm just subscribing for notifications in the usual way and logging a counter each time an update comes in.

[chengweih001]

Just want to clarify your question. In your case, are you experiencing instability when having the connection with the BLE device using WebBluetooth API? Or the unstable issue is also observed on other interface?

[joshbrew]

@chengweih001 Hey man, I am trying to get a 500sps x 8 channels x 3 bytes/channel stream working with the browser BLE API. I can do 250sps OK with few issues, 500sps seems to blow the browser buffering speed limits and stops running after a second or two on the browser, but this is just testing single threaded in an html file that's also running a plot.

So 500sps x 8 channels x 24 bytes = 96kBps,

And broken into packets of 9 samples * 8 channels or ~55 packets/second with our 250byte packet limit on our nRF board.

This seems to be too fast, nowhere near the actual limits of BLE PHY.

[chengweih001]

@moothyknight

Thank you for the information. Like what you suspected, there might be a browser buffering speed limit that disrupts the throughput, and we might need to dig further to identify the cause. However, it might also end up due to limitations and we couldn't fix it, or fix it on some OS but some won't be fixed.

Nevertheless, we intend to approach this by having a throughput benchmark test to consistently reproduce the scenario across different platforms, then we can dig further to identify the cause. Will keep you posted.

[joshbrew]

@chengweih001

Great! Let me know how I can help benchmark, I was the first person writing about this issue on the internet that I could find, and I have a setup to test my microcontroller throughputs easily just no way to debug this on a lower level that I know how to do. I am not worried about mobile performance as I will use native libraries for that due to the 20mtu packet size limit on android web BLE, just desktop is what I'm worried about. Thankfully I can get just enough juice to do my minimal sampling rate over BLE and split extra sensors into separate services. With Serial I have no issue streaming dozens of channels but it's a lot less overhead than BLE.

[joshbrew]

@chengweih001 while I'm here, what are the prospects of BLE in web workers? Would help prevent issues with overhead

[reillyeon]

Worker support is being tracked in #571. Most of the work for communicating with the Bluetooth stack actually happens outside the thread that JavaScript runs on so unless the JavaScript main thread is busy (for example, with rendering tasks) then moving code to a worker won't help much.

[joshbrew]

@reillyeon ah good to know! I've been pushing every limit I can think of with workers and device throughput rates etc. I'm excited how much work is going into optimization on browsers, really has me looking forward to application development. We are working on real time EEG and EMG analysis applications in-browser using threaded gpu workers and stuff to handle signal processing, just trying to make sure devices are stable over BLE 5 for our new boards which have insane throughput and range with little power usage.

[joshbrew]

Hey so what is the actual process for deciding what effort to put into these web API specifications? Is everything sort of silo'd off to whatever experts hired on get interested in? Just curious how decisions get made like how the android web BLE restricts byte rates on browser or in this issue how optimization is made for increasingly capable hardware?