Bluetooth version supported in Espruino - 4.0, 4.2, 5.0?

Posting this here because I can't seem to find a reference to the supported Bluetooth version in the documentation. E.g. the nRF52832 can support Bluetooth 5.0, but which version does the Espruino Bluetooth stack support?

Specifically, it looks like my BLE sensor requests the MTU size at 40 bytes during connection setup (using the Bluetooth 4.2 packet extension?) and proceeds to send 37 bytes in each packet. When I try to read from the sensor with the MDBT42Q I only get 20 bytes per packet and the rest of the data appears to be missing.

Thanks,
-- Terrence

AFAIK, Espruino only supports 20 byte MTU right now. There is some discussion about increasing it.

Hi Terrence,

Espruino can run on a Bluetooth LE 5.0 stack but all the boards that I ship use the 4.2 stack because it's just better tested and more reliable with Espruino at the moment.

Unfortunately packet extension isn't supported at the moment however one Espruino user did post some modifications that would enable it - they were a bit too rough to include in Espruino and nobody else seemed to be needing it so I didn't bother, however since you seem to need it I'll take another look.

Ahh - you reworded this slightly :) So you believe that you need an increased MTU as opposed to Data Length extension?

Yes, sorry, I updated my question after posting ;-)

I think Bluetooth 4.2 is fine in general as it supports the vast majority of use cases.

Regarding the MTU: Is an increased MTU size possible without Data Length extension?

Also, what does the current Espruino stack do with an incoming gatt MTU request? Does it ignore the request or does it respond with an error? My gut feeling is the sensor should not use an MTU of 40 bytes unless the Central device has acknowledged it.

Thanks,
-- Terrence

Is an increased MTU size possible without Data Length extension?

Yes, it should be. However increasing MTU means the softdevice needs to allocate more RAM - realistically without some hackery that means everything needs recompiling and the RAM is gone regardless of whether you use the MTU or not.

Also, what does the current Espruino stack do with an incoming gatt MTU request?

There should be negotiation performed by the BLE stack and each device should be able to query the negotiated MTU I believe. Personally I'd say the device is probably ignoring that.

I spoke to the developers of the sensor device. They confirmed that the MTU size is hard-coded to 40 Bytes ;-( He will produce a test binary for me that uses the default MTU size.

Regarding the MTU: Is an increased MTU size possible without Data Length extension?

As you worded it I guess the answer is "no" but there is another BLE feature that allow sending bigger data i.e. write over 20 bytes to characteristics and receive it as single block. That feature is called "Write Long Characteristic" and "Read Long Characteristic". This works by splitting data to MTU sized chunks transparently on bluetooth stack level so both the calling code and receiving code gets it in one piece but still the MTU is 20 bytes and the data is splitted and reassembled for you.

It would be useful if you figured out which type of write your device is using. If it negotiates for larger MTU via DLE or uses long writes over default 20 byte MTU.

EDIT: posted before reading you next comment, in that case just forget it (if you trust what developers told you, they can be confused too and may in fact use long writes without knowing it)

Fanoush,

Thanks for this, I found a thread on the Nordic forums related to long characteristics (Read long characteristic as ble central). It seems like in my case though the developers first need to fix their hard-coded MTU size ... I can't imagine long reads work if the peers use mismatched MTU sizes. But I will ask them.

Best,
-- Terrence

Well with espruino long writes doesn't work too, it is just that these features are confusingly similar so that it is not clear which one is used.

Supporting long writes in espruino may be easier as the buffer may be allocated dynamically from variable space when asked for (explained here) while bigger MTU probably needs firmware with this enlarged buffer compiled in.

However unlike long/prepared/buffered writes, bigger MTU give real improvement in speed so is probably nicer thing to have.

Ok, there is an increased_mtu branch and I just brought it up to date with the recent fixes. Maybe you could try a build from http://www.espruino.com/binaries/travis/396d5b50fb378206a14de067222a88487ac063bc/ and see if you have any success with longer reads?

I tried it with my phone as a central with a long characteristic, but that didn't work - I don't know if that's because the phone isn't using long MTUs though!

Wow, your new builds are coming fast and furious ;-) Will try tomorrow. I am also expecting a new sensor tomorrow with a test build with default MTU of 23 bytes.

Best,
-- Terrence

Hi Gordon,

I tried to DFU http://www.espruino.com/binaries/travis/396d5b50fb378206a14de067222a88487ac063bc/espruino_2v04.105_mdbt42q.zip but nRF Connect shows "Starting DFU..." quickly followed by "Disconnecting...".

I am able to DFU the official 2v04 release so maybe the file you created is invalid?

Thanks,
-- Terrence

That's strange. I get that too, however I'm not sure what's causing it. The size looks fine, and in the log of nRF Connect it says the MDBT42Q reports 'operation failed'.

it is built in wrong way, it has type "bootloader"

$ nrfutil pkg display espruino_2v04.105_mdbt42q.zip

DFU Package: <espruino_2v04.105_mdbt42q.zip>:
|
|- Image count: 1
|
|- Image #0:
   |- Type: bootloader
   |- Image file: espruino_2v04.105_mdbt42q_app.bin
   |- Init packet file: espruino_2v04.105_mdbt42q_app.dat
      |
      |- op_code: INIT
      |- signature_type: ECDSA_P256_SHA256
      |- signature (little-endian): 71d5aef62a8a7833e13994a17ecb8397235fe0eebe0d74251f17ffb7d9db2bf053336828d7a814777e337e5246d34246badb7ff90e86793937af96ce3fd936a0
      |
      |- fw_version: 0x00000000 (0)
      |- hw_version 0x00000034 (52)
      |- sd_req: 0x8C
      |- type: BOOTLOADER
      |- sd_size: 0
      |- bl_size: 308148
      |- app_size: 0
      |
      |- hash_type: SHA256
      |- hash (little-endian): 0985a61291d7d45f0becc9b69a60b773bdd951466121225d9697606a97a217ce
      |
      |- boot_validation_type: ['VALIDATE_GENERATED_CRC']
      |- boot_validation_signature (little-endian): ['']
      |
      |- is_debug: False

here are some different fields from previous application packages

      |- fw_version: 0x000000FF (255)
      |- type: APPLICATION
      |- boot_validation_type: []

Thanks - just fixed it, it was a typo in the Makefile (ifndef vs ifdef) that was affecting everything.

This one should now work:

http://www.espruino.com/binaries/travis/7215b960a195ef38cd1f3f5777f5a30dcc406e03

Hi,

This firmware installed ok, but I cannot connect to MDBT42 via Web Bluetooth or nRF Connect. I can scan for the device, but when I try to connect to it the IDE just says "CONNECTING ..." for a long time and nRF Connect briefly says "Connecting..." but then goes back to DISCONNECTED.

I tried a hard reset, no change. When I re-flash the 2V04 release it works fine.