Hi! Using the bluetooth UART to send data like you're doing is usually pretty good as it can buffer up writes and send them at once, but as @fanoush says you need to be careful that you actually can send the data faster than you're sending it.
I'd suggest:
NRF.setConnectionInterval(7.5) as @fanoush says - this should be the default usually, but if you don't specify it and the device is idle for a while it'll fall into a low power state where it only sends every 200ms (until you start sending lots of data again).
Don't use console.log() but instead use Bluetooth.println(...) and send all data in one call. console.log worries about getting the formatting right for the REPL (for example displaying the > prompt on each new line) and by using Bluetooth.println you can skip that and save a few chars
As @fanoush says you could look at making sure you're sending the data in a slightly more compact way if it's possible
But the slowing down and disconnecting is a bit of a surprise - there is actually a possibility that you just have a flat battery? Going 'full tilt' reading the accelerometer and sending data can draw a lot more power than just being idle (~10mA vs 0.03mA). It'd last for ~20 hours on a fresh battery but even so if that battery is old it may well end up flattening, then rebooting after?
For advertising if you did go that way, you can specify NRF.setAdvertising({}, {interval:20}) which is the max of 20ms = 50 times a second, so it should still work for you without a connection (the default is 375ms) - so that could be an option too.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Hi! Using the bluetooth UART to send data like you're doing is usually pretty good as it can buffer up writes and send them at once, but as @fanoush says you need to be careful that you actually can send the data faster than you're sending it.
I'd suggest:
NRF.setConnectionInterval(7.5)
as @fanoush says - this should be the default usually, but if you don't specify it and the device is idle for a while it'll fall into a low power state where it only sends every 200ms (until you start sending lots of data again).console.log()
but instead useBluetooth.println(...)
and send all data in one call.console.log
worries about getting the formatting right for the REPL (for example displaying the>
prompt on each new line) and by usingBluetooth.println
you can skip that and save a few charsBut the slowing down and disconnecting is a bit of a surprise - there is actually a possibility that you just have a flat battery? Going 'full tilt' reading the accelerometer and sending data can draw a lot more power than just being idle (~10mA vs 0.03mA). It'd last for ~20 hours on a fresh battery but even so if that battery is old it may well end up flattening, then rebooting after?
For advertising if you did go that way, you can specify
NRF.setAdvertising({}, {interval:20})
which is the max of 20ms = 50 times a second, so it should still work for you without a connection (the default is 375ms) - so that could be an option too.