Pyra in the wild - the real life experience


Well, anything except 1.5GHz and 1.0GHz is outside of spec.

True, though 500MHz WAS inside the specs once :)

I think TI simply didn't test all of them properly and therefore, doesn't support them officially.
I'm sure some more power can be saved if we find the perfect voltage / MHz combinations that are possible.
[doublepost=1507165324,1507165260][/doublepost]
Just for curiosity, where the cracks have started?
Figuring out why they happened (fatigue/overstress/cyclic impacts from loose components) may give interesting insights to the final device development.

The plastic used is not the proper one (which will be a mixture of plastic and carbon).
This one is very soft, and even the hinge starts to wiggle after you open / close it a lot.

The case is still being sent to Greece so they can take another look at the areas and recheck the stability.
 
The plastic used is not the proper one (which will be a mixture of plastic and carbon).
This one is very soft, and even the hinge starts to wiggle after you open / close it a lot.
And this is the reason why I asked about it.
If we have weaker plastic, we have to investigate why cracks happened. Was it overstress or fatigue. If it happened because it was put in a pocket and squeezed, it's not a problem (typical overstress - usually durability improves with better plastic). But if it was a result of a cyclic fatigue, we have an excellent view what would happen to the original case, but after significantly larger number of load-unload cycles.
That's how tool wear is estimated in computer simulation - by simulation of tooling with softer material. I generally use mathematical models for it and scientists will tell you that messing with tooling material is not a good idea, but most people from industry like programming dies of butter to see where it will fail after e.g. 5000 cycles with one simulation run instead of 5000 (one simulation may compute even a week in a nice Xeon multiprocessor computer).
 
That's fair enough. I suspect the hinge waggle isn't representative though, as the hinge mechanism applies stresses designed for a more robust plastic. To model that you'd also need to adjust the hinge friction proportionally, I assume.
 
Are these the same hinges as the Pandora? I know ED tried to make it so we could have it hold in any position (when the correct plastic is used), although I think it might be nice to throw a DS hinge in if it will be used on a table/desk a lot (I don't care if it is a handheld with tiny keys and blah blah blah).
 
Time to finally answer ;)

@Askarus: how do others react to the apparatus? And compared to the Pandora? When you mean slow to compile, do you mean loading the libraries and starting or do you mean caching is not that good? Second time a linux program starts fast because it is cached in RAM.

There isn't much reaction. Computer Science students seem to be pretty good at ignoring extraordinary things and people ;)

I mean compile. I'm a beginner, so I do compile and run a lot and it's noticable slower on the Pyra.

I assume it's 2GB?I'm curious to see the battery life difference between 2 and 4.

It's 2 GB.
I don't think there will be so much difference. Turinig USB off however gives me two more hours.

Different theme I assume? The desktop environment doesn't have a direct influence to this. The underlying widget toolkit used by the program is still the same.

Yes, it's an integrated MATE theme. The one you saw as you used my Pyra.
Unfortunately I tried to install Plasma Desktop and it broke the theme engine and programs were not nice again.
I don't have much knowledge about theming and engines, so I can't give you a detailed answer.

BTW @everyone: I tried to install KDE 5 Plasma desktop and it did not install as it requires OpenGL2.

Yes, that rings more of a bell. I think he was doing a big compilation job at 1.whatever GHz to test out thermals.

Does the Pyra ramp down the CPU dynamically the same way the Pandora does? So if the CPU is idle it actually throttles the CPU down to a minimum frequency, so actually it's only ever at the currently selected max if you're 100%ing one core or the other. Or is that work still to be done? I guess that's kind of a fairly common linux feature - my CPU on this netbook is currently running at half speed, which tends to be about as far as x86 chips go down. My build server always starts at max GHz though, and only downclocks if thermally forced to, and after cooling down will rapidly bring the clock up if you do anything with it, which is a bit different to the way my Pandora behaves. Maybe it depends on whether the OS is running on battery or not.

It throttles down as sebt3 mentioned. You can add a CPU monitor to the panel and watch it. However that's unnecessary motion on the screen and uses CPU power. So I don't use it. But I tried and it worked.

Now you have gone and got me excited for the Pyra again.;)

Get one. There is a good chance you will get hyped again ;)

How would you compare the nubs of the Pyra to the Pandora's nubs? Do they have more travel? How are the clickable centers of them?

Well, the Pyra nubs simply work ;).
Travel? No Idea. Should be the same. But I'm not very sensitive here I think. At least they don't feel very uncomfortable or strange to me.
They feel like Nubs should feel. The plastic does not feel great so far, but it's still the prototype plastic.

To be honest I did not try the clicks so far...

Nubs can be used for scrolling but unfortunately it's only scroll/don't scroll at a fixed speed what makes it pretty much useless.

With all the set-backs and delays that we have been seeing, I needed this bit of positive news. Thanks @Askarus.

Me too :)

_________________________________________

And some news:

I finally asked the ExaGear support to resend me my license key as I lost it ...

Unfortunately it does not install.
The install script wants to install the "alsa-base" package but that's not in our Debian Stretch repo.
 
Unfortunately it does not install.
The install script wants to install the "alsa-base" package but that's not in our Debian Stretch repo.
That was the same even in Jessie, If I recall I got around it somehow. I'll play with it this weekend to try and remember what I did.
 
That was the same even in Jessie, If I recall I got around it somehow. I'll play with it this weekend to try and remember what I did.

I've contacted the Support already. At least they should know that it's not working.
If you find a solution I'm happy to try it.
 
The cursed tale of case production... I hope you can get it fixed with the new source!

As for brigdging the waiting on the Pyra I have a request (and I know that Evildragon is a very busy man) but I would really appreciate another small video with the prototype running some emulation or similar.

That would really make my day - even more than another news post !

Thanks for the update!!
 
Yeah, that would probably really help preorders. Trouble is, I think everyone who's got a prototype thus far (at least in August) is working on OS level stuff, apart probably from PtitSeb, who tends to work more on big C/C++ projects, like Codeblocks or the Mono engine. I think Notaz produced a lot of the early emulators (picodrive and playstation), but he's not got that much free time at the moment reportedly, and busy suggesting fixed for the 4GB issue currently I think. Askarus is down as desktop settings and scripts stuff apparently, which is worth getting right as well.

I think we'll have to wait until Ptitseb gets Codeblocks running on Pyra - I think Stella (2600 emu) running on the prototypes was Ptitseb's work we saw in that video from a past conference. Maybe Exophase is down as getting a prototype later.
 
Code::Blocks already works on the Pyra. I've compiled my games and software when playing around with the prototype at Gamescom.

I don't think there's a need for a mammoth DBP in the fashion of the Code::Blocks PND. The debian repo has most of the standard libs you need and you have a proper building environment + space to build from source yourself when needed.
 
Thought the whole point of using Debian is that most of this stuff will work out of the box?
It's for mostly for Games.
Also there are some things not in the ARM Debian repo.

That was the same even in Jessie, If I recall I got around it somehow. I'll play with it this weekend to try and remember what I did.
Did you play with it?
 
One of the things I think I'm going to appreciate as my Pandora enters EOL is that *everything* is on SD card. I'm planning to stick with that on Pyra as much as I can. Yes, the code::blocks DBP should be smaller than the Pandora one, and that can still be a distribution channel for things like gl4es I guess.
 
One of the things I think I'm going to appreciate as my Pandora enters EOL is that *everything* is on SD card. I'm planning to stick with that on Pyra as much as I can. Yes, the code::blocks DBP should be smaller than the Pandora one, and that can still be a distribution channel for things like gl4es I guess.

That makes sense for your data. Maybe also do a symlink for your config files to SD.
But I don't see any reason to have my standard programs not in the internal storage but on SD.
LibreOffice etc. shell start as fast as possible.
 
If we can access the internal uSD card at the same time as the eMMC, then I guess I could put my home directory on that, giving me the same result as having my appdata on external SD. For everything else you just need to backup the list of installed packages periodically I guess. So long as the pyra repo never goes down in the future, it should always be reproducible.
 
If we can access the internal uSD card at the same time as the eMMC, then I guess I could put my home directory on that, giving me the same result as having my appdata on external SD. For everything else you just need to backup the list of installed packages periodically I guess. So long as the pyra repo never goes down in the future, it should always be reproducible.

I wonder how much space it would require to save a local mirror of the pyra repo...
https://www.debian.org/mirror/size
"The CD archive varies greatly across mirrors — the Jigdo files are around 100-150 MB per architecture, while the full DVD/CD images are around 15 GB each, plus extra space for the update CD images, Bittorrent files, etc."

I think it is pretty conceivable to walk around with the entire mirror for multiple architectures being served up 'live' from a Pyra.

Heck, set up right, a person could conceivably connect the OTG port to a USB port on nearly -any- Linux compatible device and boot the 'other' device from the Pyra (as media source) and install Linux to it from a 'complete' set of Debian repositories.

They could also have a script to run on the Pyra to update those repositories periodically.

Eventually, if someone were so inclined, a program could be set up in a DBP that would do the above - complete with local repository maintenance and hosting the repositories as Live images to the USB OTG in device mode.

Hypothetically of course.
 
Back
Top