Most recent activity
-
- 38 comments
- 9,915 views
-
One more update. Looks like the changes I made to try to fix the power consumption issue were successful. I only just now had to change the battery for the first time since I made the changes 7 months ago.
So everything is going great. Just thought I'd let everyone know. Thanks for all the help!
-
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. :-)
-
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.
-
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?
-
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.
-
quick question, what would be the syntax to clear the security setting? Would it just be
NRF.setSecurity({});?
-
Oh, I just saw your reply.... yeah, that should be a workable solution. I'll check it out.
-
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.
I ran the setConnectionInterval call, but I think what really fixed things was removing the LED lightshows that I would launch on connects and disconnects, as well as removing this setInterval call that I had in my code:
which was there because sometimes the light shows would persist.