Bluetooth Serial example un Puck

[espruino-discuss]

Posted at 2019-10-22 by voodooless

Hi there,

I'm looking for an example to use the Bluetooth serial port. I don't seem to get it working, probably because the console is still bound to it. I've tried looking for examples, but I can't find any. To be clear, I mean this one: https://www.espruino.com/Reference#l__global_Bluetooth
A println seems to output some data to the console, but the "data" event gets never posted..

[gfwilliams]

Posted at 2019-10-22 by @gfwilliams

Ahh - yes, you're right - that's just because the console is still using it.

You just need to move it out the way. Easiest is to use LoopbackA (which loops back output to LoopbackB).

Either:

• LoopbackA.setConsole() moves the console out the way until you next reconnect
• LoopbackA.setConsole(true) moves the console out the way permanently - so if you save to flash then you will no longer be able to program the Puck until you follow the steps for hard reset.

Just be sure to do that as either the last thing you upload, or on some other input. (eg buttonpress or delay) - because once the console has moved anything after will get ignored.

You can just do Bluetooth.setConsole() to move the console back, so you could have that happen on buttonpress (or sending some specific data) to allow the IDE to reconnect.

[espruino-discuss]

Posted at 2019-10-23 by voodooless

Thanks, that helps a lot! Another (set of) question(s): how is delivery of data guaranteed (if it is at all)? Is there any sort of flow control available that can he used for this? Maximum characters that can be send at once is 20 I think? Is there a way to increase the MTU at the moment?

[gfwilliams]

Posted at 2019-10-23 by @gfwilliams

how is delivery of data guaranteed (if it is at all)?

I believe some level of retransmit/error correction is done by the Bluetooth stack - it seems pretty reliable for code uploads anyway

Is there any sort of flow control available that can he used for this?

Not yet, so you'd have to implement your own. Espruino itself can implement software XON/XOFF flow control on Serial, but so far that hasn't been extended for use with Bluetooth.

Maximum characters that can be send at once is 20 I think?

Yes. If you're sending from Espruino then it will automatically 'chunk' everything for you. When you're sending to Espruino then yes, you have to split at 20 chars.

Is there a way to increase the MTU at the moment?

There's a branch of the code that implements this (https://github.com/espruino/Espruino/tree/increased_mtu) but it's not merged yet as it permanently uses a chunk of RAM and I need to decide if that's a good idea or maybe whether there's a trade-off (eg. 100 byte MTU rather than the full amount).

[espruino-discuss]

Posted at 2019-10-23 by voodooless

I believe some level of retransmit/error correction is done by the Bluetooth stack - it seems pretty reliable for code uploads anyway
Not yet, so you'd have to implement your own. Espruino itself can implement software XON/XOFF flow control on Serial, but so far that hasn't been extended for use with Bluetooth.

These things are a bit contradictory, aren't they? I was actually meaning flow control over the BLE uart connection. I'm pretty sure that if I'm sending data to fast It will choke at some point..

[gfwilliams]

Posted at 2019-10-24 by @gfwilliams

These things are a bit contradictory, aren't they?

Not really - Bluetooth data will get reliably to the Bluetooth stack, but if it's not handled by Espruino fast enough it'll get lost (however a FIFO_FULL error flag gets set in that case).

I was actually meaning flow control over the BLE uart connection. I'm pretty sure that if I'm sending data to fast It will choke at some point.

That's what I meant. There is no flow control on BLE UART yet, but conceivably it could be added to the firmware at some point.

Having said all that the datarate over BLE is pretty low with the standard MTU and there's a big input buffer, so it's entirely possible that you could write your code such that it can always handle data as fast as can come over BLE.

[espruino-discuss]

Posted at 2019-10-24 by voodooless

Not really - Bluetooth data will get reliably to the Bluetooth stack, but if it's not handled by Espruino fast enough it'll get lost (however a FIFO_FULL error flag gets set in that case).

Can one handle this error within the application code? I've tried overflowing by sending loads of data in a loop, but it seems be be fine. At least that is encouraging!

Having said all that the datarate over BLE is pretty low with the standard MTU and there's a big input buffer, so it's entirely possible that you could write your code such that it can always handle data as fast as can come over BLE.

Yes, it looks like it works for now. That's something we can work with at least.

[gfwilliams]

Posted at 2019-10-25 by @gfwilliams

Yes, you can detect the error at least - but obviously you can't stop it overflowing.

To test, you can do something like t=getTime()+10;while (getTime()<t); while uploading to RAM - so forcing the code (which executes on upload) to pause for 10 seconds - then you need to send lots (1k?) of data after that.

I actually hit this issue yesterday, so the absolute latest builds of Espruino (and 2v05+ when released) will now have XON/XOFF flow control built in.

[espruino-discuss]

Posted at 2019-10-29 by voodooless

That's very cool.

Some more questions: is there a way to actually detect that there is a BLE uart connection present at all? Are there any events for connect or disconnect?

Furthermore, it all seems to be based on string data? How does it work with binary data? can I safely convert the string data to binary and the other way around?

[espruino-discuss]

Posted at 2019-10-30 by AkosLukacs

There is an event for connect and disconnect that's fired when you connect / disconnect.

For binary, you can either convert binary to text, and send that. For example Bluetooth.write(uint16array.buffer) just sends the raw bytes from an uint16 array.
Or you can define you own characteristic, and that way it doesn't collide with normal Nordic UART operation.

I have a project using the Nordic Uart that transfers data (power measurements from INA226) from Espruino to a page with web bluetooth. Actual sending is this line Sends x + timestamp + voltage, current, power read from the INA + y in each line.
Parsing part is a bit contrived. Parses the bytes back to numbers.

I have a version that uses a custom characteristic, but that's not yet up on Github.

[gfwilliams]

Posted at 2019-11-01 by @gfwilliams

Some more questions: is there a way to actually detect that there is a BLE uart connection present at all?

As @AkosLukacs says you can detect connections, and NRF.getSecurity().connected allows you to query if you're connected - however you can't see if someone is connected but not looking at the UART.

Just a note that the Web Bluetooth Puck.js lib (http://www.puck-js.com/puck.js) now supports flow control.

HOWEVER while sending binary data over UART was fine, with XON/XOFF flow control (now the default in 2v05+ builds) you can't do that. You'd have to explicitly disable it using Bluetooth.setup(...) if you want binary.