Working with Sleep in code?

Is there a way to trigger a Blink to go into Sleep mode? I’m working on an idea for a “game select” system and would like one of the final selections turn all the Blinks off. (This would be especially useful when about to put the Blinks away, so that we don’t have to use the “Wake your Blink” scissors workaround if a button accidentally gets held inside the case.)

Is there a way to prevent a Blink from going into Sleep mode? During some games of Fracture we have noticed some Blinks turning off, and this is clearly because we haven’t pushed the buttons for some time. It’s not a BIG deal but if there was some way in code to “if (this happens) then (refresh the interval before sleep)”, it would be nice.

Not yet… but soon!

  1. Do our best to ensure all contiguous Blinks fall asleep at the same time
  2. Hold for 6-9 seconds and release to send force sleep to neighboring Blinks or automatically send force sleep at 9+

Currently, the default sleep timeout is 10 minutes (which can feel long…) I have been thinking about making it shorter once we have item #1 implemented. Also the wake neighbors helps with this a lot, since waking Blinks is quite tedious at the moment.

The solution I am leaning towards on variable sleep times is that our default sleep time without any button presses will remain at 10 min, but perhaps a game can be designed to timeout earlier if you so choose to. Allowing it to be longer than 10 min feels problematic for all of the obvious battery life concerns. In a game like Fracture, a game can take place for 30 minutes or more… waking it 3 times with a single button press during that game play seems reasonable, especially if they all warn they are going to sleep and go to sleep together. Other games, such as Berry have a lot of button pressing, it feels reasonable that if Blinks timed out after 2-5 minutes of inactivity that it probably signals you are not actively playing and they can go to sleep.

All in all. These are great points, and you are absolutely right. Looking forward to having these features implemented as stated in the issues. And moreover, it will be fun to see your “game select” system. We try ours out with a quick mockup of the interaction first.

Good ideas, both 1 and 2 would help a lot.

Any thoughts on whether ANY neighbor signal activity should affect this timeout even without buttons, sort of the opposite of isValueReceivedOnFaceExpired. Such as when a piece notices it has ‘moved’ and has a different number of neighbors (in Fracture)? Does that make sense? I did notice in DevKitDemo there was occasional odd behavior in direct sunlight so that is worth keeping in mind to test.

Thanks! This quick mockup is good stuff, it has nearly all of what I had in mind and helps me understand quite a few things I was overlooking. I’m not the best coder but enjoy modifying existing works. I see I’m not the first who thought of the menu mode, I hope kenj1 shares!

1 Like

Yes, this was the source of internal debate for a while, and I feel like I have been convinced that offering a way to prevent sleep without button actions could be playing with fire for battery life. You are correct that sunlight and other stray IR does affect the dev kit Blinks (significantly) and the commercial Blinks should be greatly improved with their shielding.

That said, I do like the idea that the games only go to sleep after game inactivity, for n minutes, this way Fracture doesn’t fall asleep during game play. We’ll try it out, and if we feel we are in danger of some battery catastrophe, we’ll play it safe, otherwise, great suggestion! Keep ‘em comin’ :slight_smile:

Completely agree on needing a way to put the Blink to sleep via program. I also made this request awhile ago. I know they’re looking to implement it in their “menu” feature.

Is there a way to trigger a Blink to go into Sleep mode?

Here is an example of how to force a blink into hardware sleep…

Note that unless you are doing something very funky (like writing a game select system?), you probably want to leave this to the blinklib code to do for you automatically since there are some gotchas in there.

The example here works well, but I see some funkiness when I try to use it here

Seems to put them to sleep but then have some trouble waking…

Try this and LMK if you still see any problems!..


1 Like

That did it. I had a sneaking suspicion that would be the solution, but it kinda bothered me that the display needed to be cleared through the loop first. No serious bother, since this is a bit hacky anyway :slight_smile:

It is not about clearing the display - you can take that out, I only put that in for good from.

What I think was happening with the original code was that a button press would increment the mode to SLEEP mode, and then the test would see that and make it go to sleep, and then when it woke it was still in SLEEP mode - so unless you could hit the button again before the next pass of loop() , then the test code would see that you were still in SLEEP mode and go to sleep again over and over.

New code avoids this lock out by updating the mode right after waking so you are not in sleep mode anymore.

1 Like