An almost naked Pyra


holy cow, this looks great!!
i always thought i dislike transparent cases, but somehow it looks verry nice here with the rough finish and the precise fit of all the areas, this is serious art!
xtra good karma and mental strength to nikolaus fixing the cpu-crasher bug! you'll make it! maybe we need more fingers here? :)
 
I think I will be quite pleased with the texture of the case. That is pretty much what I wanted. Thanks for doing your own thing and not going with the ultraglossy look that is so popular right now. I think a slightly shiny dark red will look pretty good.

When will the color decision be made?
 
Interesting, the smaller case parts still take a while to be finished, even the company sayed they had all molds ready when ED visited them. Maybe they really meant only the rough, unfinished ones.
Well, at least there is a steady progress, which is already much better than everything Pandora-case releated. ;)

Analyzing the Pix I spot some strange thigns on the front gaps. The seam that should be flat and straight between the SD slots (where top and bottom part meet) seems to be rounded, shouldn't it be flat? And the surrounding "trench" looks very sharp, this should be actualy rounded (was a bad part of the Pandora case by the way).

DSC02884.JPG


So basicly, the roudned part should be flat and "sharp" and the surrounding sharp angle part should be rounded imho. ^^"

I think I will be quite pleased with the texture of the case. That is pretty much what I wanted. Thanks for doing your own thing and not going with the ultraglossy look that is so popular right now. I think a slightly shiny dark red will look pretty good.

+1 :)
That's the right "texture", which makes a huge difference imho.
 
After watching EEVBlog on and off for a few years I think the hanging issues may be a grounding issue? I'm not questioning the skills of Nikolaus and I'm just doing electronics as a hobby but it sounds exactly like it (hangs when power consumption goes up rapidly). Dave (the main host of EEVBlog on YouTube) made a video about powering a processor without using the power pins, it's quite entertaining to watch.

Anyway it's nice to see progress, the color of the Pyra in the render on the previous page looks amazing. I've been saving up for a Pyra for months now and hopefully I'll be able to order one soon :) .
 
Looking damn good ED, really good! At this stage, the fine details are for sure the most important, and will probably take the most time. I'm actually happy to wait the coming, weeks and months, as I'm sure mass production won't start unless every issue big and small has been addressed.

Chris
 
The system runs a bit unstable if it uses too much power. Running two cores at the same time will cause the system to freeze at some time, running only one core will run mostly stable (except for if you stress the CPU).

This is another one of those issues where the solution will probably be simple....

Very sadly I was expecting and fearing this.

I have been following mobile/cell phone industry for a very long time, and I have seen near nobody choosing Cortex-A15 because they were too much power hungry with lots of problems. I saw how most manufactures jumped over Cortex-A15, and who didn't had problems.

¿A simple solution? ¿Use only one core? ¿Lower frequency? Not nice.

It is sad to find this problems in this development stage, where other points are so advanced.

We end up with a 32 bit ARM with problems, while there are lots of 64 bit ARM without problems (only Snapdragon 820 had problems, and are they are thermal problems); and with closed driver for GPU, using a rotator chip (more power demand, lots of initially problems and forcing to use 720p display instead of 1080p as originally planned) instead of using SOC graphic hard to rotate screen as all modern hard/SO can do.

I understand Pyra problem: to find a manufacturer supplying so little quantity and some support; so little to choose.

I don't know if in the end it may be I should wait for upgraded Pyra with a better CPU board (64 bit ARM v8A and without power issues).

PD: Sorry for being this crude but I was fearing this problem and this add-up to the handicaps.
In other way I haven't lost all hope on Pyra.
 
I don't think disabling a core or running at lower clock speed is an acceptable solution for that problem. Let the engineer engineer before you blast out the end is near-propaganda :p
 
Very sadly I was expecting and fearing this.

I have been following mobile/cell phone industry for a very long time, and I have seen near nobody choosing Cortex-A15 because they were too much power hungry with lots of problems. I saw how most manufactures jumped over Cortex-A15, and who didn't had problems.

You are jumping to conclusions and this won't need to be a permanent solution, the devboard does not have these issues, infact the current draw in my experiments shows it's comparable to the OMAP 3 in the Pandora. It's most likely the charging circuit or something ED mentioned.
It is sad to find this problems in this development stage, where other points are so advanced.
Why is it sad, this IS the stage to find these things, only a handful of prototypes were made and it still may be a software tweak that is needed to fix it... there is nothing alarming to find issues at this stage.

We end up with a 32 bit ARM with problems, while there are lots of 64 bit ARM without problems (only Snapdragon 820 had problems, and are they are thermal problems); and with closed driver for GPU, using a rotator chip (more power demand, lots of initially problems and forcing to use 720p display instead of 1080p as originally planned) instead of using SOC graphic hard to rotate screen as all modern hard/SO can do.
From what I understand Native Linux support for 64-bit ARM is very early in maturity, it's actually good we have a 32bit SoC at the moment. The rotator chip is a future proofing as not every SoC handles rotation the same way, it's also an optional piece of hardware that can be disabled at anytime and perhaps may not be on future display boards. The current draw if I recall isn't that much either.

I don't know if in the end it may be I should wait for upgraded Pyra with a better CPU board (64 bit ARM v8A and without power issues).
Here is the Paradox, if the current gen Pyra doesn't sell then a future CPU board may never happen.
 
Last edited:
That's the right "texture", which makes a huge difference imho.
Absolutely. It looks and feels better (not sure if the better grip is more in my head or not, as it may be less surface area contact instead of more like it seems). Not sure why so many devices are now slick fingerprint magnets. It makes a huge difference to me as well, although one of the bigger reasons, the "gripiness", may be mostly an illusion.


I am also interested in future news of the next round of keymat changes to fix the issues ED mentioned. I thought flat (or concave) would be an improvement, however it makes sense the smartphone industry did things as they did (convex/domed).
 
Very sadly I was expecting and fearing this.
I have been following mobile/cell phone industry for a very long time, and I have seen near nobody choosing Cortex-A15 because they were too much power hungry with lots of problems. I saw how most manufactures jumped over Cortex-A15, and who didn't had problems.

Well, there were a few smartphones that used the Cortex-A15, and yes, they're power hungry.
Running the Pyra with full CPU power (means: stressing both CPU cores to the maximum) will eat up the battery in 2,5 - 3 hours.
That's nothing new. And then again, with a CPU heating to 120°C when using both cores fully for a longer period of time, you should not do that.

Most modern smartphones clock down when the CPU gets too hot, and I guess we will have to do the same as well.

However, that's a very unlikely scenario (unless you compile something, but then again, you should use an AC Adaptor for that), and my smartphone can also eat it's battery within an hour if I stress both cores to the maximum :)

What's more important is that the CPU itself uses LESS power for the SAME processing power than on the Pandora.
Which means: If you run stuff that works on the Pandora (which doesn't use the full CPU), the Pyra should have a WAY longer battery life.

Typical tasks like Webbrowsing, for example, increase the CPU load when rendering a page, but that's only a short peak, until it's loaded. So webbrowsing should be faster and use less power.

When using stuff like DreamCast or N64 emulation, which needs more CPU power than the Pandora can offer, the power usage will increase. To what amount cannot be said yet, but I doubt they will use both CPU cores fully (as N64 already runs pretty well on the Pandora).
3D Stuff doesn't use the A15 but mostly the GPU, so the power issue is not really a thing here.

The battery time will be something between 2,5 hours and probably 20 hours, depending on what you do.

However, that has NOTHING to do with the issue we have, so lets get back to the topic :)

¿A simple solution? ¿Use only one core? ¿Lower frequency? Not nice.

Nope, that's not a solution, and no one said that.
This is just part of the "tracing-the-issue-back"-part.
This shows that the SoC clearly doesn't get enough power. And as that issue doesn't happen on the EVM, but we are using a different system for providing the power (as the EVM doesn't need to handle battery charging), it's clear that this is most probably where to find the solution.

It could be hardware, it could be software.
It could be that the power circuit limits the power for some reason (i.e. it automatically limits to 500mA when you a USB power source, and that needs to be changed in the software configuration) and therefore, the SoC simply doesn't get enough power for higher speeds.
It could be that there are some power spikes when changing the CPU speed which just need a higher capacitor to smooth them.

There is a solution, that's for sure, but finding it can be fast or slow, you never now before.

It is sad to find this problems in this development stage, where other points are so advanced.

Umm - that's exactly where these problems occur :)
The prototypes are the first real produced systems based on a theoretical layout. They exist in order to find out if everything works right and then fix it :)

They couldn't have occured before, as the hardware didn't exist before.

We end up with a 32 bit ARM with problems, while there are lots of 64 bit ARM without problems (only Snapdragon 820 had problems, and are they are thermal problems); and with closed driver for GPU, using a rotator chip (more power demand, lots of initially problems and forcing to use 720p display instead of 1080p as originally planned) instead of using SOC graphic hard to rotate screen as all modern hard/SO can do.

TI still has the best support for their SoCs in Linux. Try to find other current SoC stuff in mainline kernel.
The SoC has nothing to do with switching to a 720p display, btw, the reason was that I tried a 1080p display and everything was too small to be used. While Linux desktops have a dpi setting, not all programs respect those, so e.g. GIMP is unusable until you manually change some configuration files with a text editor.

A 1080p display with that size would have had too many drawbacks and wouldn't really have given us any advantages.

I understand Pyra problem: to find a manufacturer supplying so little quantity and some support; so little to choose.

I'm pretty sure I could get a Rockchip or Allwinner somewhere, but they are pretty much fixed on Android whereas the TI SoCs even have mainline Linux kernel support.
We don't want to end up with outdated kernels at some time.

Also, I'm not sure how well they're SoC guides are written...

I don't know if in the end it may be I should wait for upgraded Pyra with a better CPU board (64 bit ARM v8A and without power issues).

Well, if everyone does this, there won't be a Pyra.
One reason the CPU is upgradable is that it's attractive for everyone, as the system doesn't need to be thrown away in a few years like smartphones are, but you can upgrade it for about 100 EUR with a brand new CPU.
And, honestly, what I've seen of the OMAP5 so far, we got plenty of processing power for a while :)

PD: Sorry for being this crude but I was fearing this problem and this add-up to the handicaps.
In other way I haven't lost all hope on Pyra.

Well, my guess is you didn't understand the post correctly.
This is not an issue with the SoC, it's an issue with the power circuit right now. Any Snapdragon, Rockchip, etc. would freeze as well in this case.

The parts we have CAN provide enough power according for the datasheets, but something limits it right now. And that's what we're trying to find :)
 
Looks very good. The transparent case is better than I expected (but I still favour opaque). How easy is it to use all the ports on the back at the same time? Is it a tight fit?

Perhaps, [broken_record]assuming we want to give a distinguishing feel to the keys F and J[/broken_record], F and J could be flat while the other keys are convex. That should be a relatively subtle feature for key navigation. How about that?
 
Very close to a full prototype. Then let the games begin.
It will be interesting to see what minor tweaks occur between now and the final Pyra model.
 
Between 2.5 and 20 hours and 40 to 120 degrees? Those are quite some margins ED... Obviously real life quotes won't be gotten until the current problem is solved. But hearing real life figures are really high up on the list of things I personally want to hear about before committing to a purchase.
 
Well, there were a few smartphones that used the Cortex-A15, and yes, they're power hungry.
Running the Pyra with full CPU power (means: stressing both CPU cores to the maximum) will eat up the battery in 2,5 - 3 hours.
That's nothing new. And then again, with a CPU heating to 120°C when using both cores fully for a longer period of time, you should not do that.

What does stressing both CPUs to the maximum mean? 1.7GHz with a power-virus like program running on both cores?

A 6Ah battery should deliver over 22Wh of power, so 2.5-3 hours would mean about 7.5 to 9W power consumption. The total CPU cluster contribution would probably be north of 6W in this scenario, possibly significantly more. For comparison, see Exynos 5430, a big.LITTLE 4xCortex-A15 + 4xCortex-A7 SoC used in a few Samsung phones:

http://www.anandtech.com/show/8718/the-samsung-galaxy-note-4-exynos-review/6

Dynamic power consumption running a stress test at 1.8GHz over two A15 cores uses about 2.36W.

It's not really that surprising, given that OMAP5 is on a worse process, probably without HKMG, and it uses an early revision Cortex-A15 without some later power optimizations that were made. Its physical implementation may be poorer. And it's forced to use less power efficient RAM. If it's really getting up to 120C there will be a bigger than expected increase in overall power consumption because leakage increases exponentially with temperature. That does mean that heavier duty cooling could help.

It's just sad that Pyra is stuck using OMAP5, an SoC that was made for phones but basically failed to make it into any mobile product - until now. And we can kind of see why. There may not be a lot of programs that want to use both cores at 1.7GHz with a full load, but DraStic with high resolution rendering is not that far away from needing that, so I'm saying this extends beyond compiling things. Now I think it's not going to be a realistic option for Pyra and that's really unfortunate.
 
Yea let us blame the SoC for a problem which isn't even really identified yet. Makes sense.
 
Except that it is, since every other option is not seriously feasible.

You're misunderstanding me. I'm saying that the high resolution rendering option now looks like it's not going to be realistic on Pyra.
 
Yea let us blame the SoC for a problem which isn't even really identified yet. Makes sense.
Let's try on a prototype first before making conclusion.

Who are you guys addressing this to?

If it's me (or SNESFAN), I'm not talking about the stability issues but ED's 2.5-3 hour usage at full load statement. IF that's true, and doesn't refer to something beyond the situation I gave (2GHz?) the implications are pretty bad. I'm hoping that it's an underestimation, if it's taken from the eval board it might represent something worse than Pyra because those do not tend to be very power optimized, but for now I can only really go with this comment at face value. It's good to have proper expectations going in here.

Having said all that, in my mind the 2.5 to 3 hours part, while a cause for concern, is all kind of moot if it heats up to 120C. Users could accept a much lower battery life but that temperature (SoC junction temperature?) is not safe for the electronics over long periods and is possibly not safe for the case or the user's skin. If it's not safe thermal throttling absolutely must be done, and I'd be really concerned if it were controlled at any level higher than SoC programming done early in the boot process, that is, anything that the user can change or break. Worst case scenario would be that the SoC has to completely shutdown if it can't throttle or throttling doesn't help fast enough. Even if the throttling is effective this is actually a really bad way to control thermal budgets and will result in worse typical performance than you'd get by not letting the SoC get too hot in the first place (something that the OS really needs to manage)
 
Last edited:
Back
Top