Search results for:

I'm not sure if this is expected/intentional or if I did something wrong, but the time that I've manually input resets whenever the watch is powercycled. Is there a way to get around this?

Sorry for the delay - yes, using 2v00, not cutting edge builds. Though, I tested them before and experienced the same issues. The button is used to trigger a recording (with the hotkey that's sent), so when testing the system we press it twice within 10 seconds to a minute. During actual recordings, we press it to twice: start and end within 5 minutes to an hour of recording.

The button (sometimes) just fails at some point and doesn't reconnect until the battery is removed and put back in. Other times, the battery is completely dead.

I left my puck at the office, which isn't open until January 2nd, but I'll be sure to test out the interval change when I'm back there.

Honestly, I've been having a lot of battery issues too recently. I've been having to change them out every few days. Just connected via BLE - getting worse battery life than with v199. Let me know if you'd like me to start my own topic for this.

E.on('init', function() {
  var debug_log = function debug_log(t) {
    console.log(t);
  };

  debug_log(NRF.getAddress());
  debug_log("Battery: " + E.getBattery() + " " + Puck.getBatteryPercentage());

  var kb = require("ble_hid_keyboard");
  NRF.setServices(undefined, { hid : kb.report });

  var sending = 0;

  var catchButton = function catchButton(e) {
    if(!sending) {
      var keyDown = e.state === true;
      var keyUp = e.state === false;
      var click = false;

      if(keyDown) {
        //digitalWrite(LED3,1);
      }

      if(keyUp) {
        triggerCommand();
      }
    }
  };

  var triggerCommand = function triggerCommand() {
    try {
      if(!sending) {
        sending = 1;
        //107 is f16
        NRF.sendHIDReport([0,0,107,0,0,0,0,0], function() {
          setTimeout(function() {
            NRF.sendHIDReport([0,0,0,0,0,0,0,0], function() {
              setTimeout(function() {
                debug_log("works");
                sending = 0;
              }, 250);
            });
          }, 100);
          //digitalWrite(LED3,0);
        });
      }
    } catch (e) {
      console.log("caught:" + JSON.stringify(e));
      //digitalWrite(LED3,0);
      digitalWrite(LED1,1);
      setTimeout(function() {
        digitalWrite(LED1,0);
        sending = 0;
      }, 100);
    }
  };


  setWatch(catchButton, BTN, {repeat:true, debounce:50, edge:'both' });
});
save();

Firmware is cutting edge from Sept 13 2018.

Basically, I am actually pressing the button a lot as an intensive test. So every press causes an output. I'll remove the console.logs to see if we get the same behavior.

We've had cases of spontaneous button bricking. Need to reset and re-upload code. Sometimes, after a period of inactivity the button stops responding to clicks despite being shown as connected as a keyboard.

In the cases where I've been able to get a log of what happens, it's the same set of errors as I've been getting here. This is what lead me to adding the delay between allowed clicks, make sure it's not sending multiple HID reports at once.

So, I've been doing more testing. I've upped the delay to in my setTimeout() to 500 - still getting errors.

Most of them are caught, so it doesn't brick the button:

caught:{"message":"Got BLE error code 12292","type":"Error","stack":" at line 38 col 8\n      });\n       ^\n"}

Per this error code, I've found this other post: https://devzone.nordicsemi.com/f/nordic-­q-a/6222/stability-in-the-uart-communica­tion-over-ble

Eventually, the button just gives up entirely, the exception can't be caught...

Uncaught Error: Got BLE error code 12292
 at line 37 col 10
        });
         ^
in function called from system
New interpreter error: FIFO_FULL
WARNING: jsble_exec_pending: Unknown enum type 46
WARNING: jsble_exec_pending: Unknown enum type 46
WARNING: jsble_exec_pending: Unknown enum type 46

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.

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);
}

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

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.

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?

Interestingly enough, I tested again just now and it's working! Weird.

I'm not sure if nwjs has actually fixed the issue on their end or not. Seeing a lot of different reports over the years for similar issues.

If it's a hassle to update, I would say don't worry about it. The flags are a perfectly fine solution for me.

I retested the two flags (--disable-gpu --force-cpu-draw) and they worked this time. Not sure what went wrong the first time. So, consider this resolved.

Though, maybe NW.js needs an update? https://github.com/nwjs/nw.js/issues/615­2

Right. I program, commit, push, deploy, etc on my computer at my desk.

Usually, I'll connect the puck to my workstation, upload new code, disconnect it from my workstation and reconnect it on our "production computer". My workstation is 100% functional and has no issues with the IDE.

The production computer is the one having issues - it's able to connect via BLE, the IDE just doesn't open completely. I need the production computer to be functional, so other non-technical users can simply open the IDE, to troubleshoot and redeploy the code as-needed.

The URL in the desktop IDE (which is what I use 99% of the time) points to: https://www.espruino.com/modules/

I'll re-check the manual code changes tomorrow, but they definitely worked when I tested them. I'm thinking the IDE does a level of caching?

Yes, I've tried an uninstall and reinstall. Trust me, I've tried all troubleshooting that I can think of - I'm a computer technician, so I've pretty much tried everything before asking for help.

The Web IDE "opens", but I can't use it, as non-Canary Chrome does not support Web BLE yet.

I'm not able to access anything. The entire screen is black, but I can see a blue outline near the top.
Last version I tried was: espruino_ide_win64_0v69.0.exe

Gordon updated the Bluetooth HID javascript file per the conversation earlier in this post.
https://www.espruino.com/modules/ble_hid­_keyboard.js

When uploading code to the Puck.js using the IDE, and trying to send a F13-F24 key, the expected key is not sent. The same behavior as before the modification. Nothing to do with the other post.

Hey - I saw this was updated on the site, but it's not working when uploading the code via the IDE. Is this file cached or something, so it's not being pulled fresh everytime?

Desktop IDE. Finally tried this, and it still didn't show up with anything.

Do you think it'd make sense to throw F13-F24 into the KEY array? Just so people know they have the option. I've found them to be a great alternative to using keys that may conflict with other applications. Most keyboards don't have F13+ keys anyways.

Looks like that works. Changed lines 41 and 44 to 0x73 and I was able to send F13 as a key.

Sorry for the double post but found someone encountering a similar issue with another kind of custom HID, the same fix may apply here. I'll see if I can test by making the change locally and importing that

https://www.microchip.com/forums/m/tm.as­px?m=917121&p=1

Hm. The PDF included in the HID library saya F13+ are included in the 0x07 page, which is the same page already included for basic keys. I'll see if I can find more info the HID report descriptor.

Has anyone gotten F13-F24 keys to be sent from a Puck? I've tried to send them as HID commands using their numerical ID but applications that can/should recognize them don't for some reason.

I can confirm the application can recognize F keys beyond 12 by using AutoHotKey to send the key.