Is this a crazy idea or not?

[Sukarn]

Originally Posted by Yourcat

"I haven't jailbroken my kindle, but I assumed I could SSH into anytime after I "turned it on" " - I hope you learned that JB is required for SSH.

Context, my friend.

Why was the SSH thing brought up? Because it was used as an example for why this person thought that kncl's statement did not fully make sense to him/her.

If a kindle is sleeping between two page turns, then it should not be possible to ssh into the kindle when you are reading a book, unless you try to ssh at the same time as you turn a page or the clock changes the time.

If you can use ssh anytime while a book is open on the kindle, then it's not asleep, it is only idle.

Why do these things matter? To try to figure out whether his web app would *theoretically* use similar amount of battery to typical reading, or whether it would kill the battery by keeping the device awake when normal reading sends the device to sleep.

Sleep mode and idle mode have a difference in power consumption. kncl said this himself / herself, but I have not seen any good argument showing that the kindle does go to sleep between page turns instead of just sitting idle. What I did see was an explanation that turning the screen off does not ensure that the device has immediately gone to sleep.

Not that it matters to me whether anyone can provide insight into whether the device goes to sleep or stays idle while a book page is being displayed. I have no nothing to gain by acquiring such a knowledge.

[knc1]

Originally Posted by Sukarn

Context, my friend.
- - - - -
If a kindle is sleeping between two page turns, then it should not be possible to ssh into the kindle when you are reading a book, unless you try to ssh at the same time as you turn a page or the clock changes the time.
- - - - -

Now that might be a point of confusion -
If you ssh into the Kindle over the USB cable -
Then that means the USB cable is plugged in -
Which means the Kindle is running on external power -


If there is power on the USB cable jack, then the Kernel sets a "Wake Lock" flag and the Kindle never goes to sleep (although it can shift to another clock speed - depends on how you have its governor set). There is a KUAL app for that.

Even with the "Wake Lock" flag set - the Kindle can go into "Screensaver Mode" and display a screensaver.
But it remains running.

Now if you ssh into the Kindle over Wifi -
Then the Kindle must have been running at least the Wifi modem, which can be a much bigger battery hog than the rest of the Kindle.

And if you ssh into the Kindle over 3G . . . .
You had better plug it in to external power.

[xorlof]

Originally Posted by knc1

The screen saver is no indication that the device is asleep. "Idle" == No work to be done, as in "idle loop" (which in modern devices isn't a loop at all). "Sleep" == Read the ARM manual to see what that means - there are many individually controlled areas of the SoC chip.

Got it. Now we're heading back to my previous understanding of Kindle power states. I think I've read that a Kindle running on batteries generally goes to sleep a minute or two after the screen saver kicks in. But I haven't tested that.

Originally Posted by knc1

It is your project, who did you expect to do the work?

Me of course! But I figured getting some opinions from subject-matter experts BEFORE starting work was a wise thing to do. If you for some reason need info about hacking or programming an old REX 6000, I'm you're guy, and am happy to reciprocate, including battery questions!

Originally Posted by Cinisajoy

Ok here:
https://www.amazon.com/Malloom-Lipst...rds=Power+bank

Now you have power. Note: that is the cheapest.

Cheapest and also isn't a battery, only a battery case (you supply your own 18650 even though the listing tries to imply otherwise). ;-) But point made anyway! I have lots of portable power, but it is a lot of complication I'd like to avoid. Why? More equipment for one, but also I think a good number of devices will be unplugged by players and not replugged in and I don't want device batteries dying at inopportune times. (I'm hope to use these devices to streamline things during events for all involved. Extra complication of charging at night isn't an issue since it isn't happening during the event).

Originally Posted by Yourcat

@xor: I have no idea whether meta refresh works in the kindle browser. If it does (or js.setTimeout) you may need just a simple to keep the Kindle alive by resetting the sleep timer and you may run your test with wifi enabled for some hours ....

Yeah, hoping that simply hitting the "disable screen saver" option also disables sleep state. Will be testing that. Screen refreshing will be done via JS using data retrieved with an Ajax call, so I won't rely on meta refresh.

Originally Posted by Yourcat

"I haven't jailbroken my kindle, but I assumed I could SSH into anytime after I "turned it on" " - I hope you learned that JB is required for SSH.

Yep. And I did jailbreak the Kindle last night (first one ever! yay!). It was surprisingly easy, which is a testament to the work that other forum members have done to make it so!

Originally Posted by Sukarn

Why do these things matter? To try to figure out whether his web app would *theoretically* use similar amount of battery to typical reading, or whether it would kill the battery by keeping the device awake when normal reading sends the device to sleep.

Yep, on this and the rest of your post. Those are the sorts of things I was trying to asking about, not wanting anyone to test something for me, just get an idea of when my sort of app might be feasible.

I think this discussion, despite its enlightening meandering, has revealed that in my case it's not clear cut so testing is the only way to know.

Originally Posted by knc1

If there is power on the USB cable jack, then the Kernel sets a "Wake Lock" flag and the Kindle never goes to sleep (although it can shift to another clock speed - depends on how you have its governor set). There is a KUAL app for that.

Even with the "Wake Lock" flag set - the Kindle can go into "Screensaver Mode" and display a screensaver.
But it remains running.

Great info there. Thank you. And if power budget turns out to be marginal after my testing, you just gave me an idea that I might be able to save a bit by deliberately underclocking (assuming I figure out how that's done and performance is still acceptable).

Thanks all! Now I move on to battery testing. If someone has thoughts on questions 2 or 3 in the OP, I'm all ears!

[Yourcat]

@Sukarn tldr4me, so context was lost. No offence meant.

I'll nohup something to update the display every n seconds and will see when K stops/resumes updating.

In any case with little experience with Kindles the idea to use them is crazy. Just my 2 cent, once again no offence meant.

[knc1]

Just get the "CPU Report" KUAL extension I wrote -
It has menu entries for the governor settings.

[Sukarn]

Originally Posted by knc1

Now that might be a point of confusion -

Great explanation! Thank you.

Originally Posted by xorlof

I have lots of portable power, but it is a lot of complication I'd like to avoid.

Portable batteries might still be your best option.

Originally Posted by xorlof

Yep, on this and the rest of your post. Those are the sorts of things I was trying to asking about, not wanting anyone to test something for me, just get an idea of when my sort of app might be feasible.

I think this discussion, despite its enlightening meandering, has revealed that in my case it's not clear cut so testing is the only way to know.

The only I chimed in was because it seemed to me that people were misunderstanding you.

Originally Posted by xorlof

if power budget turns out to be marginal after my testing, you just gave me an idea that I might be able to save a bit by deliberately underclocking

I'm sure you and the other participants in this discussion are aware of this, but I'm mentioning it for other who might be reading and thinking of under clocking for battery life: it's not that simple. Under clocking can lead to worse battery life if the processor stays awake longer to finish a task, but could otherwise have gone to sleep.

Originally Posted by Yourcat

@Sukarn tldr4me, so context was lost. No offence meant.

That doesn't bother me at all. This is not my project, and anything that comes out of this discussion will probably never be used by me in any form.

[xorlof]

Originally Posted by Yourcat

I'll nohup something to update the display every n seconds and will see when K stops/resumes updating.

Yeah, lots of tests are possible. FWIW (nothing probably), I found this quote from a B&N rep in an old May 2011 article. It is unclear which model of Kindle is being referred to. Something around Kindle 2/3(Keyboard) presumably:

With up to two months on a single charge, the all-new Nook has the longest-battery life in the industry and superior battery performance to Kindle 3. In our side-by-side tests, under the exact same conditions, continuous use of the device resulted in more than two times Kindle's battery life. While reading at one page a minute, the all-new Nook battery lasts for 150 hours where the Kindle battery, using the same page-turn rate, lasts for only 56 hours (both with Wi-Fi off). We've also done a continuous page turn test and at one page turn per second, the all-new Nook offers more than 25,000 continuous page turns on a single charge.

It does point to the old Nooks as being a possible device to investigate if the Kindle battery doesn't pan out. Unfortunately, I loose a speaker in going to that device vs the KT1, but it's an option.

Originally Posted by Yourcat

In any case with little experience with Kindles the idea to use them is crazy. Just my 2 cent, once again no offence meant.

None taken. I have experience using them, but none developing for them, so yeah, there's a risk.

Originally Posted by knc1

Just get the "CPU Report" KUAL extension I wrote -
It has menu entries for the governor settings.

Found it. Awesome, thanks. Your warnings on that page about just how slow the powersave option sound like that it may end up a no-go for this application, but I'll try it out!

[Cinisajoy]

Originally Posted by xorlof

Got it. Now we're heading back to my previous understanding of Kindle power states. I think I've read that a Kindle running on batteries generally goes to sleep a minute or two after the screen saver kicks in. But I haven't tested that.


Me of course! But I figured getting some opinions from subject-matter experts BEFORE starting work was a wise thing to do. If you for some reason need info about hacking or programming an old REX 6000, I'm you're guy, and am happy to reciprocate, including battery questions!


Cheapest and also isn't a battery, only a battery case (you supply your own 18650 even though the listing tries to imply otherwise). ;-) But point made anyway! I have lots of portable power, but it is a lot of complication I'd like to avoid. Why? More equipment for one, but also I think a good number of devices will be unplugged by players and not replugged in and I don't want device batteries dying at inopportune times. (I'm hope to use these devices to streamline things during events for all involved. Extra complication of charging at night isn't an issue since it isn't happening during the event).


Yeah, hoping that simply hitting the "disable screen saver" option also disables sleep state. Will be testing that. Screen refreshing will be done via JS using data retrieved with an Ajax call, so I won't rely on meta refresh.


Yep. And I did jailbreak the Kindle last night (first one ever! yay!). It was surprisingly easy, which is a testament to the work that other forum members have done to make it so!


Yep, on this and the rest of your post. Those are the sorts of things I was trying to asking about, not wanting anyone to test something for me, just get an idea of when my sort of app might be feasible.

I think this discussion, despite its enlightening meandering, has revealed that in my case it's not clear cut so testing is the only way to know.


Great info there. Thank you. And if power budget turns out to be marginal after my testing, you just gave me an idea that I might be able to save a bit by deliberately underclocking (assuming I figure out how that's done and performance is still acceptable).

Thanks all! Now I move on to battery testing. If someone has thoughts on questions 2 or 3 in the OP, I'm all ears!

Can I assume the people playing this game are familiar with some powered device or other?

If so then most if not all should know how to use a power bank.

FWIW: I think you are making it more complicated than it is.
Make a website or App compatible with smart phones and tablets. Buy a few cheap tablets for those that don't have a smart device.
Either make your router public or give everyone the password and the Web site or app.
Have a few cheap power banks available.
Problem solved.

[Yourcat]

With one SoHo router you may get connection issues unless you connect only a few clients. SSL requires CPU and SoHo routers often don't have enough. Running a load test over LAN with an increasing number of clients fetching a dynamic page every 60s should reveal the router limits.

[Barty]

xorlof: I think you're going to have to bite the bullet and write a test app. Something that polls the server and downloads something, does some busy work to simulate processing, and displays something.

I suspect it will be unsatisfactory. Kindles get good battery from having a display that does not need refreshing and from sitting mostly idle. Amazon somewhere has published specs on battery life with and without Wi-Fi; that will give you an idea of what kind of hit the battery takes from just having Wi-Fi on. Another thing is the kindles you are thinking of using are old so you are starting with lowered battery life.

Any reason you want to avoid going the smart phone/tablet route? Do you have a no phone policy at the tournament? Your users look young and geeky, and it should be little problem to have them bring their own device. You can supply them with portable chargers and/or outlets as a courtesy. You just need to write the web app.

[Sukarn]

I'm not OP. I believe the main idea was that having a device that is always showing current or recent info without needing a button press would be a nice addition for them.

If OP wasn't looking for interactivity, and only wanted to display info, I would have suggested trying this and seeing how long the battery lasts https://www.mobileread.com/forums/sho...d.php?t=236104

[xorlof]

Lots to reply to. What a great "problem" to have!

Originally Posted by Cinisajoy

...most if not all should know how to use a power bank.

Yes, pretty much everyone probably knows how to use a powerbank. The goal of this to have a very polished, pro-level player (and tournament director) aid available. Plugging and unplugging power banks is hacky. I like hacks (this whole project would be a kind of hack), but I don't want to have to depend on that sort of hack if possible. The whole point of this exercise is to bring our "professionalism" in running the event to the next level.

If that response doesn't feel satisfactory, feel free to expand this spoiler for a rambiling explanation of an important (to us) detail. All but the people most dedicated to understanding our reasons are advised to skip the spoiler:

Spoiler:

I guess that one thing I haven't explained is that for this sort of event to feel like it's been run super smoothly (remember, that's one of the goals in adding these devices), there are a critical few minutes during the changeover from one round to next. Given these two things:
1) We want every round to launch on time at (for example) the top of the hour.
2) Every round has games that do not complete in the allotted time (and a winner is determined via some alternate rules).

When time is called, we already have the results for games that didn't go long. That's great. But at that point the players who were still playing have to do a pretty quick calculation to determine who wins their game, record those results, and relay them back to the tournament director's table. Until ALL results are in, the tournament director usually can't really do too much in starting to determine the next round's pairings.

However, we are a very friendly community, and after you finish a game, espeically one that was fought to the bitter end, what normally happens is that time is called, the players figure out who won and then start chatting about the game...perhaps how tense or close it was, or disappointments, or whatever. (And sometimes the players themselves try to sneak in some extra play). Getting the results to the tournament director (TD) quickly is far from their mind. Remember the TD *needs* those results before they can go to work. What usually happens is that the TD ends us going table-to-table on the games that went long (sometimes after figuring out where the players actually were playing) trying to collect results. For various reasons, this takes some time (several minutes) at events that are the size ours are. At that point, finally, the TD can determine next round pairings and only then can they be announced so the next round can start. (End of rounds are a busy time for the TD also because this is when players are most likely to have miscellaneous questions for the TD).

So what does this have to do with the Kindle? The speaker on the Kindle I'm proposing using can audibly prompt (or even nag) players to report their results when their game goes long. I think this will short-circuit the delay that exists in games getting called on time and players sending results back. Secondly, the results get transmitted electronically which can saves time physically moving them around (currently done with small slips of paper). All of this saves time and frees up the TD during this time to take care of other stuff, rather than trying to get results from players.

Results being electronically entered also means that after the last result is submitted the server can instantly calculate the next round pairings and immediately display them on every kindle (with a beep on all of them to signal to everyone to look at them). You pick up the nearest kindle (all of which at this moment are automatically displaying all of this round's pairings), note which map you have to go to for your next round, set the kindle down, walk to your spot and start playing. This saves time too. It gets the pairings out very quickly. Our current "state of the art" is to post a printout of all of the rounds' pairings that players crowd around until they can get close enough to see their name and map number.

All of these time savings (with getting results, calculating pairings, and distributing next round pairings to players) means that there is more time to actually play the games. Currently, if our 1:00pm round is finishing (next round is supposed to start at 2pm), and there are lots of games threatening to go long and the event is large, we may have to call time at 1:50. That gives the TD 10 minutes to 1) go around and hassle players for results, 2) determine next pairings and 3) distribute/post them. Sometimes that 10 minutes isn't enough and the schedule slips which exacerbates our time problems for the next round. If players get used to responding the kindle's prompting and immediately enter results, we might be able to call time at 1:58 or 1:59 for a 2:00 launch of next round. Combine that with all players being seated at the start of that 1:00 round by (say) 1:02 instead of 1:05 means that overall players have 56-57 minutes to play their games instead of 45, a difference of 11-12 minutes. About 25% more time to play! THAT'S HUGE and it means fewer games will get called on time and more reach a natural conclusion which makes everyone happier.

How does this tie in to your question? At the crucial switchover times between rounds, if the TD is busy dealing with technology (e.g., someone forgot to plug in a device to a battery bank so it's dead and you can't report results, what's that router password again?, etc.) it *kills* the schedule. Most of the time, minutes don't matter. At the beginning and end of rounds, it does, and this is precisely the time when people are mostly likely to have a kindle in their hands, needing it to work. If it doesn't and someone can't report results (i.e., a dead battery to directly address your question) that's a problem, and a problem at one table makes 60 other players wait. Don't get me wrong; our players are patient and understanding, but making them NOT have to wait is part of the job of a tournament director. We need something simple to use (from the players' perspective) and super-duper, no-questions-need-to-be-asked, no-problems-need-to-be-addressed reliable.

Trust me, that is important to us.

All of that said, previous posts about protecting the Kindle from damage and frequent references to power banks have made me think it wouldn't be too hacky to use a kindle protective rubbery case from ebay (~$3) and slide one of these thin usb battery banks ($2.50 from ebay) INSIDE the case, taped inside to the kindle, and have the battery bank ALWAYS plugged in. Here is a picture of the cheap battery:



It would make the rubbery case bulge a bit up top, but I think it would look OK since it would all be one sleek unit (no plugging and unplugging of the batter and it doubles the watt-hours available). I'm ordering a sample case and battery to test it, just in case it turns out my battery life test comes up short.

Regarding the later part of your post (why not just use tablets or smartphones and such), see my response later in this post.

Originally Posted by Yourcat

With one SoHo router you may get connection issues unless you connect only a few clients. SSL requires CPU and SoHo routers often don't have enough. Running a load test over LAN with an increasing number of clients fetching a dynamic page every 60s should reveal the router limits.

That's a good consideration. The router I'm using has a (IIRC) dual core ~1ghz arm processor. Reasonably beefy. TLS/SSL is not required for us. (If we wanted privacy, everyone would already have essentially a private channel talking to the private router if we had WPA turned on. Remember traffic does not leave the router to go to a seperate server). The server architecture envisioned is such that there is heavy caching of anything dynamic. Leaving the details out, it means the server is really only recalculating anything on average once every minute and a half or so, with a peak of probably 8 data submissions/recalcs in one minute (at end of round). Results are cached after each recalc. The only expensive operation is the player pairing calculation which only happens once an hour. I think I can safely say without testing (and understanding that I write lean code), that it will be able to handle it. What do you think?

Originally Posted by Barty

xorlof: I think you're going to have to bite the bullet and write a test app. Something that polls the server and downloads something, does some busy work to simulate processing, and displays something.

Yeah it looks like it. I've been playing around with the Kindle after I jailbroke it Thursday night which means I haven't done the test yet, but will do so in the next few days. Running the test itself takes a half a day (if all goes well and the battery holds out)!

Originally Posted by Barty

Any reason you want to avoid going the smart phone/tablet route? Do you have a no phone policy at the tournament? Your users look young and geeky, and it should be little problem to have them bring their own device. You can supply them with portable chargers and/or outlets as a courtesy. You just need to write the web app.

A fair enough question and one I've been dancing around until this post. There are lots of reasons, most of which I will try to restrain myself from going into too much detail with (as you can tell from my previous posts--I *love* detail!):

1) It would be very useful to have always-on display assigned to each map. It's always there. Always showing what's needed. It provides map and pairing-specific information INSTANTLY--no hunting for the right URL--just glance over at it. It can also function as an always visible game timer and player alert system, always controllable by the tournament director. A hodge podge of tablets turning on and off can't do any of this, nor can player provided smartphones. It's ubiquitous availability itself is a killer feature.

2) We do NOT have a "no phones policy." People do have and use their phones between games. I think most players would frown upon the use of phones during games (except for specific circumstances). We generally like to be quite interactive with the player in front of us. It's a great aspect of our culture. The tournament asking players to use their phones during games for official tournament purposes could start us on a slippery slope (including players using phones as aids to calculate tactical game information, which I suppose then could lead to a ban).

3) If you read the spoiler above, you'll see (in excruciating detail) that if this system works, the Kindles should provide us a lot of time savings per round, and you'll also read about the benefits of that. The time savings is actually is probably the #1 benefit to us.

4) We need whatever electronic system we use to be battery operated. The Kindles' (hopefully long) battery life gives it a huge advantage for us over tablets. Getting electricity from various venues (think at large gaming conventions) is expensive. We usually pay for one power drop to power a laptop at the tournament director's table (and it would also power the router/server located at that table in this proposed system), but the venues do not look kindly on stringing extension cables around to other tables. The reason for not using a bunch of battery banks is covered in the spoiler, but briefly, we need reliability. There are certain times we can't afford to encounter a dead battery even for a couple of minutes. (That's also why the idea mentioned above of essentially a permanently attached external USB battery *would* be acceptable.)

5) As mentioned quite a while back in the thread (easy to overlook), I can get these Kindles DIRT CHEAP. $10 each dirt cheap. With good battery life remaining. That saves a LOT of money, since we're talking about a lot of stations. Not sure if we could afford this otherwise (remember, just volunteers setting this stuff up for free).

6) While you didn't mention a "bring your own device"-only policy I want to address that here before someone does. Not all of our players have their own devices so we couldn't require that. The game is accessible to pretty young kids (8 year olds or even younger) and they sometimes enter the tournaments. Because there is a lot of strategy and tactics involved, young kids like that won't win, but they still have fun and most of the older players sporting enough to restrain themselves from absolutely trouncing them.

7) Any amount of bringing your own devices can mean more problems to troubleshoot. This isn't a big deal, but I mention it as a downside. Over time 99% of these wrinkles could get ironed out.

Originally Posted by Sukarn

I'm not OP. I believe the main idea was that having a device that is always showing current or recent info without needing a button press would be a nice addition for them.

Yes. I know I'm not the best communicator, and apologize for that. I think you understand me very well though so at least I can say I'm not a total failure at communicating my intentions!

For those keeping track, expect my battery testing results later this week. For funsies (not related to this project), I'm also building a lego minstorms ebook "reading" (actually just page turning) robot to test how long the batteries in these devices REALLY last when reading books (not using manufacturer numbers). Anybody know if someone else on the forum has already done this? I have my Kindle 3, a Kindle Touch, and a Nook Simple Touch that I will be testing. (The results of this testing will have its own thread). If there is enough interest I might try procuring some other (more recent) devices for testing purposes.

Thanks again for your help everyone. It's nice to see that some others find this to be a cool/fun/interesting/whatever idea. And I would have never hit on the "always attached" external battery INSIDE of a rubber case idea if not for this bouncing of ideas off each other. Whether I need that or not right now, it will come in handy as the kindle batteries start failing if easy, cheap replacements are no longer available!

[Dr. Drib]

Moderator Notice

Please take a few moments to read our Posting Guidelines, in particular the part about the maximum image size allowed (600x600 pixels). Images that violate those guidelines will be deleted.

It is every member's responsibility to read our Posting Guidelines and follow them.

Thanks.

[xorlof]

TESTING BEGINS!

For those following along, here's the status.

I've actually already done several short term tests and it's looking promising. I've just started the long-term test that will run until the battery is dead. Assuming I've done things correctly and the above test WAF app actually is running the Kindle at least as hard as the real thing will, I should have NOTHING to worry about. With a usable battery capacity of about 1350mah and an average draw of somewhere less than 50ma, we're talking about well over 24 hours of use (probably closer to 30 if I had to guess).

In the test I have several things happening every 10 seconds:
- about 15kb of network activity
- a full parse of the received data and dummy calculations done on that data.
- various calculations and branching in the code (in a way to help make sure branch predictions, assuming the ARM processor does them, are frequently missed).
- updating the clock at the top of the display.

And at every 10 minutes:
- lots more dummy cpu activity
- a dozen or so very expensive DOM operations
- full screen refresh
- reading of a bunch of internal variables from the system (various battery parameters, wifi signal strength, etc.)
- logging of status of those variables.
- other stuff I'm forgetting about without looking at the code.

All of this is done from a spot where the wifi is rather weak, just in case that consumes more battery on a Kindle (not sure if it adapts its Tx power in such situations).

I think this is a fair test of most everything other than my use of the speaker (which I just forgot to add until this very moment). Assuming this test works out, I'll add the speaker portion and retest.

While the test app isn't testing response to input, me having the app do operations in this simulation every 10 SECONDS all day, I think whatever battery life I come up with with be conservative. (Keep in mind, in the actually application, we're talking about our simple updates happening only once per minute). Wish me luck!

[Cinisajoy]

Please shrink your image.

Never mind. You are ok.

And good luck on your project.
You will please let us know the times.