puck on windows "paired" but not "connected" (or connected but not HID)

Hi,

I've been having some issues with my puck(s). Often, when I joined them to Bluetooth, they'll automatically go back to "Paired" rather than "Connected". Sometimes, when they connect, they don't appear as HID device either.

Any ideas?

Here's the snippet where I define the NRF services:

var services = {
  0x180a: {
    0x2a50: {
      value:     [
        0x01,           
        0x6d, 0x04,
        0x2b, 0xc5,
        0x00, 0x00
      ],
      readable:  true,
    }
  }
};

var kb = require("ble_hid_keyboard");
NRF.setServices(services, {
  advertise: [ 0x180a ],
  hid : kb.report
});

Thanks

In Windows you'd expect that the device goes back to 'Paired' from 'Connected' if Windows doesn't find a reason to maintain a connection - which would be the case if it didn't think your device was a HID device.

Just as a quick sanity check, what happens if you just do:

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

without any of the other services?

I might be that if windows sees the 180A device information service but it isn't in the format it expects, it just drops the connection...

Hm. That seems to be working consistently at that moment. I believe I switched to the format for defining services and whatnot because this method became flaky. I'll see what happens.

Thanks!

@Gordon Is there a way for the button to trigger a reconnect? To save battery, I want to turn bluetooth off until I click it a certain way to turn in back on. Figure this would introduce issues reconnecting.

You can't trigger a reconnect yourself, but you can do NRF.sleep() to stop advertising (which will make the PC think the device isn't around any more) and then NRF.wake() to wake it up again.

I should add that with firmwares after 1v99 (that's the cutting edge ones at the moment), having a connection doesn't take that much power at all since if nothing is happening it slows right down to almost the same speed as it would if it was normally advertising.

Gotcha. With future releases I should expect the battery life to be longer than around a month? That's the lifespan I'm seeing right now. Not doing much except BLE HID connection and waiting for button press.

Yes - the issue is that Bluetooth LE devices have to communicate every so often when connected. That used to be between 7.5ms and 20ms (usually 20ms) - which draws quite a lot of power if it's happening all the time.

The new versions of the firmware detect when they're connected but nothing is happening, and they ask the host computer to lower that polling rate to 200ms. As soon as there is sustained activity (>2 transmits or receives in a few seconds) it'll jump back to the 7.5ms rate, until it's idle again.

Hopefully it'll mean nearer 6 months battery life, maybe a bit more.

Hello community!

I actually have a very similar problem, but I'm not doing anything with BLE at all (i.e. not trying to save power or anything).
I just pair/connect my Puck to my Win 10 laptop as HID-keyboard and use it to automate a couple of things by pressing the button (just emit key presses).

Here's how I initialize the Puck (the code pretty much straight out of HID tutorial):

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

// Define button press handler
function btnPressed(e) {
      digitalPulse(LED1,1,50);
      // Send some key(s) here...
      kb.tap(kb.KEY.ENTER, 0, function() {});
}

function onInit() {
  // trigger btnPressed whenever the button is pressed
  setWatch(btnPressed, BTN, {edge:"rising",repeat:true,debounce:50})­;
}

The problem:
Because I often take my laptop and walk away from my desk where the Puck is, BLE connection breaks - this is expected. But when I come back to my desk, the connection never restores by itself. It shows as "paired" but not connected.
I have to open IDE and initiate a connection to the Puck, which works fine, but is a real pain in the bum because this happens a LOT.

Is this normal? My Bluetooth keyboard and headphones reconnect fine, and I would expect the Puck to do the same...

Is there anything I can do to fix this?

Thanks.

Hi - Are you on the latest (1v99) firmware?

Could you try unpairing in windows and then repairing?

When the Puck first pairs, it won't be a HID device, so windows won't think to automatically reconnect. But if Windows has paired to it when it's a HID device then windows should automatically try to reconnect as soon as it sees the device.

Hi Gordon,
Thanks for your reply.
Yes, I'm on the latest firmware 1.99. I also tried re-flashing which didn't help.
I'm aware of HID not being available immediately after I run the code. I am already re-paired and the Puck is definitely seen as HID keyboard, because it types and windows shows it as Bluetooth keyboard in the list of devices.
I also thought that Windows should reconnect it, but it doesn't. Very weird.
In case you want to know, the laptop is MS Surface Laptop with latest Win 10.

I am thinking I could try re- flashing with cutting edge version?..
Will let you know if it makes a difference.

That is odd - I'm pretty sure I've had people doing exactly that and it's been fine.

The other thing you could try is http://www.espruino.com/Puck.js#hard-res­et (do it after installing the espruino firmware version you want to use)

Windows always tries to create a secure connection to the Puck for Bluetooth HID, which means that encryption keys get stored on the Puck. I guess it's possible that something has gone wrong somehow and the Puck has the wrong keys stored - doing that hard reset should remove them and might help?

Hi Gordon,
Sorry it took me a while to try things and gather all the info to post here.
I've tried flashing 1v99 cutting edge and back to 1v99 stable countless times trying to figure out what's going on here.
And in the process, I think I found a problem with cutting edge firmware. I'll post it in a separate thread.
Back to the problem of puck not reconnecting.
Cutting edge firware didn't help no matter what I did. It is definitely running as a keyboard and is working fine until the connection breaks and then never reconnects again unless I initiate connection from IDE, or completely remove the device in Windows settings and re-add it again.

Then I found something even more interesting. I decided that I am going to always keep the puck next to my laptop and never separate them, and after a few hours I found that the Bluetooth was completely down on my Surface laptop. Inspecting Bluetooth in Windows Device Manager reviled that the driver crashed/stopped. Disabling and re-enabling the device didn't help. I had to either reboot the laptop or completely uninstall Bluetooth and run Bluetooth troubleshooter a few times to revive it.
After revival, Bluetooth works for a few more hours and the story repeats itself.
I've been doing since my last post trying to figure things out, but so far no clues that I can find anywhere, except that it only happens when the puck is connected. I don't even end up using it much, just a couple of time in the whole time and sometimes even not that, but the Bluetooth dies very reliably in just 3-4 hours each time every time.
Not sure what to make of this.
Anyone else experiencing this?

That's extremely odd - as far as Puck.js is concerned, especially when it's not sending anything it's basically completely inside Nordic's Bluetooth stack (which is supposedly certified). If the Bluetooth driver has crashed/stopped I'd be tempted to say it's an issue with the driver. I wonder if it happens with other Bluetooth LE HID devices.