-
Annoyingly it looks like there's no way to get the MTU from Web Bluetooth at the moment
indeed, found this issue https://github.com/WebBluetoothCG/web-bluetooth/issues/383
at least they mention higher MTU is negotiated by ChromeAbout the only thing we could try is when connecting, send a packet that's too long and see if it gets a response
or subscribe to notification (e.g. even nordic uart tx) and trigger it to send bigger block and see how much data you get in one part. similar to that https://gist.github.com/freestyl3r/318cf4b00a9287f5f452cab9d8b32ccd#file-espruino-js-L18 test. Before increasing MTU they only received first 22 bytes of the packet.
EDIT:
or the espruino side could report negotiated MTU, could be some property of connection , described here https://devzone.nordicsemi.com/f/nordic-q-a/49931/nrf52832-get-current-connection-mtu-size
Could be used to at runtime to know how much can be send/how large value can be set on characteristics via NRF.updateServices
You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
fanoush
Thanks! Yeah, I think I'll leave the app_ram_base stuff for now.
Great news about the new NRF Connect taking advantage of the MTU. I had looked at a change but hadn't really bothered much with it as I didn't think it'd have much effect unless we'd got special bootloader tools.
Annoyingly it looks like there's no way to get the MTU from Web Bluetooth at the moment, so stuff like the IDE could have problems taking advantage of the increased size. About the only thing we could try is when connecting, send a packet that's too long and see if it gets a response - and if it does keep with the increased length.