Puck sending same key repeatedly?

Posted on
  • I'm having this odd issue with my pucks (tried 2) where, I guess, for some reason, the puck is repeatedly sending the same key over and over. I've had this issue on 2 separate pucks, and 2 separate PCs, 2 separate Bluetooth dongles.

    This has happened with both Cutting Edge and the last proper v199 release.

    Doesn't happen ALL the time, but often enough where it presents a problem.

    Any ideas?

  • I just tested with Espruino IDE, and eventually this comes up, which just KILLS the button:

    "Uncaught Error: BLE HID already sending" pointing at the end of a function. After that, the button stops responding to HID stuff.

  • more logs:

    press
    Uncaught Error: Got BLE error code 12292
     at line 36 col 8
          });
           ^
    in function called from system
    press
    press
    press
    press
    press
    press
    New interpreter error: FIFO_FULL
    WARNING: jsble_exec_pending: Unknown enum type 46
    WARNING: jsble_exec_pending: Unknown enum type 32
    
  • Either the button is stuck or something else creates jitters - changing signal - that the watch picks up fires the method. Since you tried it on multiple pucks, I do not think that it is cause by some hardware issue. What is the software setup that you nave? Could you please post (part of) your code
    (at least the part that covers the control/invocation path from catching the button press thru the invocation of the sending the press. Did you use a pinMode(,"xxxx") with xxx = "input_pulldown" or "input_pullp" to make the input not float around and catch electro smog?

  • Here's my current code. Previous versions did not have the "sending" check that this now does. I haven't experienced issues with this version of it.

    console.log(NRF.getAddress());
    console.log("Battery: " + E.getBattery() + " " + Puck.getBatteryPercentage());
    
    var debugText = false;
    
    var kb = require("ble_hid_keyboard");
    NRF.setServices(undefined, { hid : kb.report });
    
    var sending = 0;
    
    function catchButton(e) {
    
      var keyDown = e.state === true;
      var keyUp = e.state === false;
      var click = false;
    
      debug_log(keyDown?"key down" : (keyUp? "keyUp" : "broke"));
    
      if(keyUp) {
        triggerCommand();
      }
    }
    
    function triggerCommand() {
      try {
        if(!sending) {
          sending = 1;
          digitalWrite(LED3,1);
          NRF.sendHIDReport([0,0,99,0,0,0,0,0], function() {
            NRF.sendHIDReport([0,0,0,0,0,0,0,0], function() {
              setTimeout(function() {
                console.log("press");
                digitalWrite(LED3,0);
                sending = 0;
              }, 250);
            });
          });
        }
      } catch (e) {
        console.log("caught:" + JSON.stringify(e));
        digitalWrite(LED3,0);
        digitalWrite(LED1,1);
        setTimeout(function() {
          digitalWrite(LED1,0);
          sending = 0;
        }, 250);
      }
    }
    
    
    setWatch(catchButton, BTN, {repeat:true, debounce:50, edge:'both' });
    
    function debug_log(t) {
      if(debugText) console.log(t);
    }
    
  • Great - thanks for posting up! Do you think it's worth me updating the HID example to add that 'busy' check?

    I guess it's possible that two keys get sent at more or less the same time in such a way that it's then not possible to send the second NRF.sendHIDReport([0,0,0,0,0,0,0,0] which would have 'released' the key?

    Strange about the FIFO_FULL/etc though.

  • The FIFO_FULL thing might have just been my computer shitting itself. After that moment, I couldn't do anything with the Puck's HID stuff at all, even after re-uploading the firmware. A reboot of the PC fixed it.

    Great - thanks for posting up! Do you think it's worth me updating the HID example to add that 'busy' check?

    I guess it's possible that two keys get sent at more or less the same time in such a way that it's then not possible to send the second NRF.sendHIDReport([0,0,0,0,0,0,0,0] which would have 'released' the key?

    Yeah, that seems to be the case. The keys get sent too fast, which breaks the buffer or something. A simple check like that might be good in the example, yeah. It's odd that I didn't experience any issues until recently though.

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Puck sending same key repeatedly?

Posted by Avatar for tako @tako

Actions