Most recent activity
-
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(); -
- 13 comments
- 4,878 views
-
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-communication-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); }
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?