What exactly happens when an HID report is sent? Is there some sort of handshake or request/response with the receiver to make sure the packet has been received? Or is it just fired out in the hope the paired device receives it? From your comment I seem to understand there is a difference between the callback being triggered and the report actually being sent out / received?
My understanding is there's a bluetooth 'notification' fired from the Bangle, and the PC is able to 'accept' that notification. It's entirely likely that Espruino marks the HID packet as sent when the notification is sent, and not when it is accepted.
experience this issue when I am at least 2 m from my PC
Ok, that would definitely back up the lost packet theory then.
Could you add a NRF.on('disconnect', function(reason) { Bangle.buzz() }); to your code? That way at least you'll know if the Bangle is disconnecting.
My concern is that if there really is a disconnect, there's nothing we can do. If a keydown event is sent and then the Bangle disconnects, even if we were able to detect that, it's not going to be able to send a key up event until it reconnects.
I am pretty sure that the problem lies in the Bluetooth reconnection procedure
I didn't mention before but there should be no reason to call NRF.wake() unless you've set up Bluetooth to be off - once the Bangle bluetooth is 'woken' it should stay awake even after a disconnect (until NRF.sleep() is called).
I guess it is possible that if the Bangle gets disconnected in the middle of sending a HID report, the state of the HID module ends up being invalid and then doesn't recover. But if that happened, even after forcing a reconnect you should no longer be able to send any HID reports - and it sounds like that doesn't happen.
the missing initial keypress could wait until a timeout
Yes - if we're in the situation where you call NRF.sendHIDReport and the callback never gets called, that's something we could definitely add.
However it doesn't sound like that happens? It seems like if anything the callback is being called too early?
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.
My understanding is there's a bluetooth 'notification' fired from the Bangle, and the PC is able to 'accept' that notification. It's entirely likely that Espruino marks the HID packet as sent when the notification is sent, and not when it is accepted.
Ok, that would definitely back up the lost packet theory then.
Could you add a
NRF.on('disconnect', function(reason) { Bangle.buzz() });
to your code? That way at least you'll know if the Bangle is disconnecting.My concern is that if there really is a disconnect, there's nothing we can do. If a keydown event is sent and then the Bangle disconnects, even if we were able to detect that, it's not going to be able to send a key up event until it reconnects.
I didn't mention before but there should be no reason to call
NRF.wake()
unless you've set up Bluetooth to be off - once the Bangle bluetooth is 'woken' it should stay awake even after a disconnect (untilNRF.sleep()
is called).I guess it is possible that if the Bangle gets disconnected in the middle of sending a HID report, the state of the HID module ends up being invalid and then doesn't recover. But if that happened, even after forcing a reconnect you should no longer be able to send any HID reports - and it sounds like that doesn't happen.
Yes - if we're in the situation where you call
NRF.sendHIDReport
and the callback never gets called, that's something we could definitely add.However it doesn't sound like that happens? It seems like if anything the callback is being called too early?