Battery Life compromise.


For the second option, the unit would become substantially thicker and, and those who don't want two batteries would have to deal with having a partially hollow base. It's annoying to use a current Pandora with its battery missing, doesn't feel good holding it.
Why wouldn't they use the battery if it's there? I was thinking side to side.
 
What about an additional battery pack which can be clamped to the bottom of the Pyra and connects via USB slave/charging?

Could probably be made at any time after release, but by already having it in mind during case design it could possibly be made a bit easier.
 
^ It will look ugly.

Also, you could use external battery you buy for the pandora now
 
Last edited by a moderator:
If you don't care about the look, you can buy external battery pack and use it.  I use it for my Pandora now.
Well but that's less good ergonomically.
Edit: Also I was thinking about semi-integrated solutions. Being able to use generic external battery packs is just a given.
 
Last edited by a moderator:
Ergonomic is subjective. My coworker complains his chair is uncomfortable but I find it very comfortable.  Like the x86 vs ARM argument going on right now :p
 
Ergonomic is subjective. My coworker complains his chair is uncomfortable but I find it very comfortable.  Like the x86 vs ARM argument going on right now :p
Yeah, all I want is people to be objective and consider and reconsider everything, but that debate is pretty bad.
 
What about an additional battery pack which can be clamped to the bottom of the Pyra and connects via USB slave/charging?


Could probably be made at any time after release, but by already having it in mind during case design it could possibly be made a bit easier.
Yeah, for your x86 Pyra you would really need such an construct! ;)

...sorry, couldn't resist.  :rolleyes:
 
What about an additional battery pack which can be clamped to the bottom of the Pyra and connects via USB slave/charging?

Could probably be made at any time after release, but by already having it in mind during case design it could possibly be made a bit easier.
 Yeah, for your x86 Pyra you would really need such an construct! ;)

...sorry, couldn't resist.  :rolleyes:
That's what you don't seem to get. The argument is not mainly about power consumption. No matter whether we choose OMAP, Snapdragon or z37xx: Under full load, the battery will last 3 hours or so. Under less load, longer.
 
Why wouldn't they use the battery if it's there? I was thinking side to side.
How does that fit the description of two full-sized batteries? That's more like the first scenario.

No matter whether we choose OMAP, Snapdragon or z37xx: Under full load, the battery will last 3 hours or so. Under less load, longer.
But not all SoCs have the same perf/W, and not all SoCs have the same concept of how much and what kind of perf can be extracted under full load. For example, you'd be much more inclined to peg OMAP53xx's dual cores than you would the quad cores of other SoCs. I don't think it's correct to say they'd all end up at around the same 3 hours under full load, much less under a useful heavy load.
 
Last edited by a moderator:
Why wouldn't they use the battery if it's there? I was thinking side to side.
How does that fit the description of two full-sized batteries? That's more like the first scenario.

No matter whether we choose OMAP, Snapdragon or z37xx: Under full load, the battery will last 3 hours or so. Under less load, longer.
But not all SoCs have the same perf/W, and not all SoCs have the same concept of how much and what kind of perf can be extracted under full load. For example, you'd be much more inclined to peg OMAP53xx's dual cores than you would the quad cores of other SoCs. I don't think it's correct to say they'd all end up at around the same 3 hours under full load, much less under a useful heavy load.
I admit, it was grave oversimplification of something you sure as hell understand better than me. I'm comforted by the fact that I'm still not the most ignorant person around :-D (I think. Maybe I just don't know it. If I was stupid, I couldn't know. But those kind of fundamental doubts about the possibility of the perception of "reality" and ability to think logically and coherently don't tend to lead useful results, so I avoid them).
 
That's what you don't seem to get. The argument is not mainly about power consumption. No matter whether we choose OMAP, Snapdragon or z37xx: Under full load, the battery will last 3 hours or so. Under less load, longer.
Of course all of these chips will need more power under full load than the current Pandora SoC. They are multicore, some can go over 2GHz and have more powerful GPU units on board. So like ED already mentioned it is even more important to optimize the software in a way that the SoC is used in it's most efficient way and not just go the "brute force" method like simply overclock the CPU until it runs fast enough this way. I'm sure, modern SoC's need much less power when doing comparable tasks like the Pandora can do at the moment(surfing the web, music, movies, desktop stuff...), meaning with same clock speed etc. Things like the 2D acceleration of the OMAP5 sound very promising there. But most coders will pull out everyhting the CPU/GPU can offer or will go the lazy way, maybe only Software Acceleration, so I guess the battery will not last that long under load.This is the main problem with todays PC games, even big companies just tend to optimize their stuff not that well because the PC's have so much raw power compared to consoles. Not every game but some need to much CPU/GPU power for the stuff they offer. I don't like that trend, maybe it's because so many games are multiplatform today, who knows.
 
You know, I think can take a thicker bottom for a bigger battery by the same company.  I think there should be a choice for that.

If the whole bottom comes off, it could still look nice.
 
Last edited by a moderator:
These would be big prices to pay, when the alternative is to have an easy way to suspend the Pandora to storage (a certain button combination could work, also have it happen automatically on low battery) and having to wait a little bit to pull it and out of this mode, then swap the spare battery. It'd be nice if there were a way to charge the battery without the Pyra. I wonder if some people will use their old Pandoras for this. Too bad you aren't supposed to remove or insert the battery while it's on.
 
The problem with pure software solution like suspend to disk is that it doesn't work as expected sometimes especially with games that tend to use more resources than one (cpu+gpu), and we're not talking about some dsp, network and such here.

Could you elaborate on inability to remove and insert the battery while the unit is on? Do you think it's impossible or prohibitively expensive for pyra to have such ability?
 
The problem with pure software solution like suspend to disk is that it doesn't work as expected sometimes especially with games that tend to use more resources than one (cpu+gpu), and we're not talking about some dsp, network and such here.
Only if the drivers don't properly support it. It's not an intrinsic problem. We don't know yet what kind of software limitations there'll be, but there's no reason to assume them at this stage.

Could you elaborate on inability to remove and insert the battery while the unit is on? Do you think it's impossible or prohibitively expensive for pyra to have such ability?
Pandora's PMIC doesn't like it for whatever reason, Pandora owners are warned not to do it. I don't know if OMAP5's PMIC has issues like this. But I was referring to the Pandora specifically in that comment.
 
Pandora's PMIC doesn't like it for whatever reason, Pandora owners are warned not to do it. I don't know if OMAP5's PMIC has issues like this. But I was referring to the Pandora specifically in that comment.
 
neo900 guys claim to be able to implement battery hot swap and they use the same SoC as 1GHz pandora. I wonder if they somehow overcame this problem 
 
SoC isn't PMIC, the limitation is in the latter, although I don't know if TI had anything newer or even a revision that would still be applicable to DM3730.
 
SoC isn't PMIC, the limitation is in the latter, although I don't know if TI had anything newer or even a revision that would still be applicable to DM3730.
TI only lists one PMIC (http://www.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=689&uiTemplateId=NODE_STRY_PGE_T&DCMP=hpa_pmp_pmu&HQS=pmu#p1395=TI-DM3730/25'>tps65910) for dm3730 and omap3530.

So either it's another revision or there really is some workaround
 
Back
Top