Glo Glo Battery Problems

[Uschiekid]

Originally Posted by Mrs_Often

Weird. I don't wait as long as 30 seconds. I wait until the cover image is completely displayed and the screen has finished changing.

It was me with the wait 30 seconds idea....and it was more to someone who was having issues, that 30 seconds couldn't possibly be too short a waiting time before closing, so why not start there and see if the problem still exists....not that I thought 30 seconds was necessary.

[TechniSol]

I would guess that flicking into sleep mode and waiting for the final cover or image to be displayed would be long enough. Common sense would pretty much dictate that you'd power down everything else and then display the image last just prior to sleeping the microcontroller -unless something in the hardware design forces you to do otherwise. But then, common sense is not nearly as common as we'd like to think these days...


Samhy,

I think I understand the point you're making regarding multi-tasking/threading and multiple operations(and I'm not sure of just how much of that might be an issue), but any properly designed system like that has to be designed to terminate or put on hold those tasks if a sleep mode is entered, or through a semaphore or signaling device indicate that sleep mode must be postponed until the tasks or threads can complete.

Basically, the sleep mode code might signal that it wants to sleep the unit, and usually wait for an indication that it was okay to do so from the task scheduler after it had shutdown scheduling operations after ensuring that any time critical processes had been informed and shut down or completed, again with semaphores, messaging or at least flags of some sort.

I'm of the mind that a properly designed, programmed and engineered device does not indicate it is in a low power or sleep mode state if it is indeed drawing excessive current beyond the normal expectation for that mode. If it can't shut something down then it is either broken, poorly designed, or should not indicate it is in sleep mode -or possibly more than one of the former is correct. That is not to say that said behavior cannot be fixed or improved.

[samhy]

Regarding the battery drain, that's a big premise but can we see the permanent touch of the screen has being as demanding on the IR detectors as a page turn?
Not long ago, the battery life was expressed in pages (something like 8,000 for the Sony 650). In that case, 4 hours of uninterrupted touch could be seen as 14,400 page turns (1 per second). If that were true, the battery would be low very fast.



TechniSol, fair point and I see what you mean

IMO, what is really wrong is that even after having triggered the sleep mode something can interfere and prevent the device from being completely sleeping (a cover, a paper, my light...). It's just a matter of seconds, but enough to be a bother.

[Shai-Hulud]

Originally Posted by samhy

In that case, 4 hours of uninterrupted touch could be seen as 14,400 page turns (1 per second). If that were true, the battery would be low very fast

Polling IR beam interruption is only a small part of the energy equation. For a full page turn you'd also need to factor in the power needed to perform a screen refresh (where the screen is recomposed each turn and fully wiped every n turns), plus memory/disk access. Of course this part doesn't occur in sleep mode.

[TechniSol]

My contention is that under normal operation the neonode probably scans the matrix just fast enough to detect a break in order to use far less power. Once a break is detected the neonode probably shifts into high gear and scans faster to "follow" a gesture or swipe. I believe the current drain we're seeing is excessive because it is in a "tracking" mode that only occurs once a touch event has began, as such this would not be likely to occur in normal operation for such an extended period. Remember the neonode hardware is designed for multi-touch events, so it likely consumes more power and scans faster in order to be able to detect multi-point touches and track the gestures once a touch event has been sensed.

[Peakcrew]

I'm back - busy weekend!

Right, I can confirm the Mk1 Touch has the same problem. Three nights, three reductions of 50% +/- 5% with the beam-breaker on the screen just after manual sleep. The only thing I'm seeing that others haven't is a frozen screen when I wake it up, requiring a power off-on to gt screen response back.

I'm with TechniSol now I've seen it myself - the neonode is remaining/becoming very active when the screen is touched during the sleep operation. It seems to me that the shutdown order has the IR sensors/neonode shutting down after the signal has been sent to the screen, instead of the being one of the first elements, if not the first element, to shut down.

[TechniSol]

It's nice to hear confirmation, if unpleasant that there's a problem at all... I've been waaaaaay out on a limb here theory-wise without the data sheets. I've always maintained that if by any chance I'm correct more than most dealing with sparse data, it's because I've also been wrong more than most, just willing to take the risk.

The freezing up has me wondering if when you power back up it might have a queue full of data to transmit or some other communication/sync problem between the neonode and the processor since the processor was likely asleep and blissfully unaware of the neonode probably pushing out data the whole time it had beam(s) blocked, or maybe something else entirely if there is just an I2C interface or the like and it's just out of sync, or whatever.

Have you tried giving it a while once you pull it out of sleep mode? Or tried sleeping it again and waking after removing the interrupter to see what it does? I guess it doesn't really matter, I'm just curious. I'm going to have to try duplicating your results here and confirm them too. I have a later model Touch(internal SDHC card) and a Glo to play with, but have a couple other projects going here too.

I think the most important thing that's been accomplished, and I give the full credit to Mrs_Often, is that a way has been found to eliminate the discharge if it's just coming about as a result of something interrupting the IR prior to sleep mode getting the IR shut down. Hopefully, now that the issue is exposed Kobo will be able to put a bandaid on it. Unfortunately, it may not be the only power drain problem they need to fix according to others. At least it doesn't seem to be a huge across the board problem, based on how many are discussing it here. Then again, one wonders how many might not be bothered by it, or just so accepting of charging portable devices like phones so often they ignore it?

I wonder if they might just limit their problem by displaying a screen prior to the final sleep screen that warns customers to be sure the screen is untouched for a couple seconds? That is, if they are unable to shut the IR down sooner or ensure it shuts down no matter what. It seems to me there would be a way to confidently ensure the neonode shuts down no matter what unless someone screwed the pooch big time.

However, what they're going to do when shut down occurs due to a sleep cover is going to depend more on getting that IR shut down.

[Shai-Hulud]

Originally Posted by Peakcrew

Right, I can confirm the Mk1 Touch has the same problem. Three nights, three reductions of 50% +/- 5% with the beam-breaker on the screen just after manual sleep.

Interesting indeed. I'd already had mine replaced of course and I was loathe to press my father into giving up reading his for a week just so I could run some tests, so thanks. The intermittent issue I had with my Mk1 not entering power off was what opened this can of worms for me. It would neatly tie that observation into the (consistently) poor battery life when sleeping the Mk2. As I've previously said I always ensure I invoke sleep manually before closing the case. But when it was meant to slip into power off the case was already shut of course.

I hope you're making note of this dear Kobo representatives and that your own tests concur with our observations. Some official response or comment would be appreciated here to at least acknowledge that this is being looked into. I'm sure you'll agree that to have the device display "Sleep" if it's still polling the screen (and possibly other activity) is highly undesirable and needs to be fixed.


And while you're at it, why not regress the kernel version to 2.6.34 or at least some other version that doesn't have known power deficiencies (Phoronix).

Extract (my emphasis):
"With this expanded round of power testing, the Linux 2.6.37 to Linux 2.6.38 regression is still shown, but it also uncovered a very noticeable differentiation in power consumption between the Linux 2.6.34 and 2.6.35 kernels too. Under idle on this test system, it equates to a 20% difference in power consumption and then the 2.6.37/2.6.38 regression tacks on another 6% in this particular test profile."

A 20% power improvement for simply choosing the previous kernel version is a no-brainer surely?

[TechniSol]

A 20% power improvement for simply choosing the previous kernel version is a no-brainer surely?

It seems like a no-brainer, provided the older kernel supports the current code in all other respects and that 20% was not peculiar to the test bed cited somehow...

Frankly, the battery life is not bad at all when not encountering the issue(s) we've been discussing, but if an extra 20% was available and had no negative impact on other features and/or new code being written it'd seem tough to pass up. Of course, they may be trying to remain as up to date in all respects as possible to more easily add new code and stay current with the development community at large.

[Tintin]

I've been away and I have only skimmed through this thread. I have a burning question and if it has already been covered then I apologise!
Most people would concur that some covers can affect battery performance on the Glo/Touch. What about screen protectors though? Could they have a similar effect and have these tests been carried out on devices with screen protectors?
Erm, that's two questions!

[Shai-Hulud]

Originally Posted by TechniSol

Frankly, the battery life is not bad at all when not encountering the issue(s) we've been discussing, but if an extra 20% was available and had no negative impact on other features and/or new code being written it'd seem tough to pass up.

It's a marketable commodity. Existing battery life notwithstanding, in terms of efficiency it is highly desirable. Using the car analogy, a 20% improvement in fuel consumption is not to be sniffed at especially for no further outlay.

Originally Posted by TechniSol

Of course, they may be trying to remain as up to date in all respects as possible to more easily add new code and stay current with the development community at large.

2.6.35 was released August 2010, .34 was 3 months prior. If they were going for "remaining up to date" they'd be on the current stable 3.x revisions by now. No I think it more likely it's a known, stable quantity for them (despite inherent flaws) allowing them to concentrate on cluttering the UI with marketing and social media.

[Shai-Hulud]

Originally Posted by Tintin

What about screen protectors though? Could they have a similar effect and have these tests been carried out on devices with screen protectors?

A fair point. Do you happen to have a window free for testing in your reading schedule?

[TechniSol]

It'd take a very thick screen protector to be a problem, further, its presence would interfere with the normal operation of the device.

[Shai-Hulud]

Originally Posted by TechniSol

It'd take a very thick screen protector to be a problem

Well since we're guessing, my guess is if it's thin enough to squeeze under the IR beams without interrupting them then it shouldn't be an issue. And if it doesn't, it will.

Originally Posted by TechniSol

further, its presence would interfere with the normal operation of the device.

Please elaborate because other than the above case I can't think of any other reason why it would interfere with normal operation otherwise.

[TechniSol]

And today in Revisionist History 101...

"Reply Redux"

Most esteemed fellow poster, please accept my simplified and expanded clarification of a statement that I capriciously thought simple enough on it's own.

If a screen protector was thick enough to cause the high drain sleep issue being discussed, it would also likely prevent the normal operation of the device by not allowing proper touch input.

I wonder if a corner lifted up, if it might interfere as well? I guess it might depend on the position, angle and refractory index of the PET, or other plastic used.

I do so hope that was tame and boring enough to prevent the scalpel of the revisionists being employed to ensure that we all play nicely like good little children.