Avatar for FuzzyBumble

FuzzyBumble

Member since Jan 2019 • Last active Mar 2019
  • 1 conversations
  • 21 comments

Most recent activity

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    I work from home (and live in NYC where food delivery is ubiquitous), so I would say that I'm probably connected far more than I'm disconnected. I have on more than one occasion gone almost a week without leaving the apartment.

    I've run the SetConnectionInterval() call, so I'll see if that helps.

    BTW, while I connected via the IDE to do that, I did a call to Puck.getBatteryPercentage() to see where I was at after three days on the new battery, and it returned 100, so I'm not sure if that means my drain is really low or if the unrealistically high value means that the function is not returning the proper value. :-)

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    I just realized that I had an interval set to run every 15 minutes to shut off all the LEDs, just as a backstop because sometimes the lightshows would not stop.

    I wonder if that was doing it.

    Since I'm disabling the lightshows, I can disable that too; hopefully that will help.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    Update: So everything has been working pretty much perfectly now, but there's just one problem. I've gone through 2 batteries over the last almost 2 months.

    The first battery I just attributed to the heavy load from all the experimentation and testing and bugs leading to infinite connect/disconnect loops. :) But the second battery did not experience anything but normal (and what should be low-drain) use as the beacon that I built it to be.

    I'm attaching a file of all the code that has been running on the puck this whole time. Maybe someone can spot something I did wrong to put an undue draw on the power. I'm already going to comment out the lightshows that happen on connect and disconnect, so that should help (although I spend a lot of time at home, so those should not be firing that much anyway) and I'll add a counter to increment on each connect and disconnect, so the next time the battery dies I can get an idea of how much activity there has been.

    But if this keeps up and there's no obvious fix, maybe I should get the pixl instead for its ability to be plugged into a wall socket for power?

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    Ok, so I upgraded the firmware and applied the NRF.setSecurity() call and everything seems to be working just fine. It's still getting the random MAC, but with the PIN, I'm not bothering with the whitelist, so that's fine.

    The only thing I noticed is that the pin only comes into play when connecting with the phone. When I try to connect to the Puck via the IDE, it connects without asking for anything.

    It's not really a big deal, since I'm six floors up and I doubt my neighbors are really into hacking, but I was just curious if that was as designed and/or if there was a way to make the PIN always necessary.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    quick question, what would be the syntax to clear the security setting? Would it just be

    NRF.setSecurity({});
    

    ?

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    Oh, I just saw your reply.... yeah, that should be a workable solution. I'll check it out.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    I came up with an imperfect hacky workaround... I set up the whitelisting code to capture the MAC address of the most recently rejected connection attempt, and then I set a watch for a medium-length button press that whitelists that captured MAC. So whenever my phone ends up with a different MAC, and the connection is rejected, I can tell the puck to accept it and then try again.

    But obviously, if there's any way I can revert to how the puck was behaving a couple of days ago, that would be infinitely more preferable.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    So near as I can figure, this is what seems to be the case:

    Apparently, on android phones, there is a security feature where they randomize their MAC address each time the transmitter is restarted for BLE advertising.

    The phone's BT does have a fixed MAC address. And from the beginning, the Puck would see that fixed address in "addr" in "NRF.on('connect',function(addr){...})".­

    Ever since I made the "NRF.setServices(undefined, { hid : kb.report });" call, the "addr" variable in the NRF.on event has been resolving to the random MAC instead.

    Forgetting the device on my phone did not change anything, the Puck still showed up in the discovered devices with the HID icon instead of the BT icon next to it. But I was able to change the advertised name on the Puck to something new, and now it shows up with the new name and the default BT icon, so that much appears to be resolved, but the random MAC is still ending up in "addr".

    So the question is how to revert the NRF.on('connect') behavior back to how it was before, where the addr argument resolves to the real fixed address instead of the advertised random one.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for FuzzyBumble

    Hmm. So I added the NRF.setServices() call to my code and uploaded it with the IDE. The problem is that now, for some reason, when my phone connects, it's MAC address is being reported as something other than what it had been reporting before. And on top of that, it appears that the address changes each time I toggle BT off and on again on my phone.

    The problem with that being that my whitelist function is completely useless now.

    I tried performing a hard reset to undo the changes and start over, but it's still exhibiting the same behavior that started after the NRF.setServices() call.

    How can I undo what I just did?!?!

Actions