puck.js not reliable

I use a puck.js for sending midi controller over bluetooth. It worked for while (on 2 different computers, Win and OSX) but after a while, the puck stops been reliable. It sends the midi data and then stops working. It doesn't respond anymore and I have to upload the code again to be able to use it. Any idea what the problem could be? Is it possible the puck is defective?

I upgraded the firmware to 2.04 with no success.

This is the code:

var midi = require("ble_midi");

midi.init();
setWatch(function(e){
  var isLong = (e.time-e.lastTime)>1;
  console.log(isLong);
  if (isLong) {
    midi.send(0, 101, 100);
setTimeout(function() {
midi.send(0, 101, 100);
digitalPulse(LED1,1,5);}, 100);
  } else {
    midi.send(0, 126, 100);
    digitalPulse(LED2,1,5);
  }
}, BTN, {repeat:true, debounce:50, edge:"falling"});

This might be a known issue with 2v0x versions (it'll be fixed for 2v05 and is fixed in cutting edge builds already) - if you write to the console while you're connected via Bluetooth but nothing is reading from the Bluetooth console then after a while the output buffer gets full and it stops responding (until it it cleared).

If you comment out the console.log it might start working again?

Ok but sometimes only after 10 messages it stops responding.

Did this or the SW update solve your problem?

I think the quality of the battery helped. But definitely loading the code onto the dead memory helped to avoid uploading the code every time.

This seems to be happening to us too. After some time of being connected one or more of the Pucks just stop responding. The Web BT interface doesn’t say anything about a lost connection which it does if the device is brought out of range.

We’re using Bluetooth.println to send data from the device to the computer for processing.

This seemed like the perfect solution for what we needed but unless we can get this fixed we may have to look for other solutions.

Please help me solve this.

Are you using firmware 2v07 on the Pucks? Have you tried it with a fresh battery?

And you're saying the Puck stops printing things, and doesn't even respond on the REPL? What happens if you disconnect and reconnect? And how long does it take on average?

Realistically to help I need to see some code - and then if I can reproduce here I can have a go at fixing it. But unfortunately I don't have much to go on right now.

A possible fallback is to use a hardware watchdog - use it in manual mode to be 100% sure and 'kick' it after printing data to Bluetooth: http://www.espruino.com/Reference#l_E_enableWatchdog

Once enabled, if E.kickWatchdog(); isn't called within a period you define the Puck will totally reboot. On your interface you'd just need to detect the lack of data and reconnect. It should be a last resort, but a watchdog does make your code pretty much bulletproof.

It's also worth noting that sometimes Web Bluetooth may not actually tell you a device has disconnected unless you try and send something from Web Bluetooth and it fails.

Hi Gordon,

Thanks for getting back to me.

So I've narrowed the problem to different behaviour between using the Web BT library on MacOS verses on iOS with the WebBLE app.

Turns out that this code works on MacOS but does nothing on iOS:

connection.device.ongattserverdisconnected = event => {
	console.log(`${connection.device.name} disconnected. Reconnecting...`)
	connection.reconnect(c => console.log('Reconnected'))
}

So now I've changed over to this instead which does work the same on both platforms:

connection.on('close', event => {
...

Reconnection works as expected on MacOS but never works on iOS. The error that is returned immediately upon calling connection.reconnect is this:

<BLE> ERROR: Premature cancellation.

This causes the close event to trigger again so the reconnect method is called a second time, for which the following error is returned:

<BLE> ERROR: No known device for device transaction Transaction(id: 287, key: device:connectGATT)

Do you have any idea how I can successfully reconnect the device from iOS?
Thanks

So you're using the Puck.js library on a website? And you're not using anything like Bluetooth MIDI or HID like the original poster was?

Do you have a stripped back example of the webpage you could post up that exhibits the problem?

It might be worth trying to react to the device not responding (rather than the close event) - so when that happens you could then attempt to trigger a close and a reconnect and see if that is any better.