HID packet problems over BLE

[deinhofer]

Hi,
I occassionally have problems with the newmain-fixederrors-Deinhofer.js code regarding reliable HID packet transmission.
It should send mouse movement packets when tilting the puck and otherwise send clicks or key presses depending on the button press pattern.

// -------------------------
// BUTTON COMMAND STORAGE
// BM slots:
// 1=S, 2=SS, 3=L, 4=SL, 5=LS, 6=SSS, 7=LL
// -------------------------
const MAX_BM = 7;

var defaultStoreCommands = {
  "1": "AT CL",
  "2": "AT CD",
  "3": "AT CR",
  "4": "AT KP A",
  "5": "AT KP E",
  "6": "AT KP N",
  "7": "AT KP O"
};

Sometimes the mouse clicks or key presses are not detected on the computer (Win10). Other times when I press one of 4=SL, 5=LS, 6=SSS, 7=LL it should send a single key press respectively, but sometimes it happens that aeno (or similar) is sent repeatadly. Maybe in such a case a key release was lost?

I could add some retries if I get an exception while sending, but maybe it would also make sense to add some logic to the puck firmware to more reliably send the packets.

[gfwilliams]

As I understand it, if you try and send a packet when there are enough queued up already you'll get an exception and it won't send it - you could then just wait a bit and try again.

The problem is, if it auto-retries, what's to stop you trying to send updates faster than they can be sent over Bluetooth, and then they'll all queue up, updates will get more and more delayed, and what's supposed to happen when there's no more RAM to store them?

Best if you just handle the exception in code and re-send (or in the case where you're sending mouse movements you can merge two events together). You can also use NRF.setConnectionInterval(7.5) to force the Puck into high speed transmission mode (it does use more power when doing this all the time though), and then as it's 7.5ms interval, try not to send more than 100 updates second as well to give you a bit of leeway