... we're still alive!


True - but do you think there will be differences when using eMMC v5 on the OMAP5?
Any eMMC5 chip should be faster than what the OMAP5 can handle.

I'm not sure about that. The eMMC version says something about the interface speed, which is the theoretical max speed, but that doesn't mean that all read/write operations are actually at that speed. Maybe you will get that speed for a large sequential read, but most likely not for small random writes.

For things like boot time, random access speeds are important (reading config files and stuff all over the place), so I think we should get the fastest 16GB eMMC we can get. I wouldn't go smaller than 16GB, because then you can't just apt-get install whatever you want.

Also, I would gladly pay 20 EUR more to get a fast 32GB eMMC.
 
I'm not sure about that. The eMMC version says something about the interface speed, which is the theoretical max speed, but that doesn't mean that all read/write operations are actually at that speed. Maybe you will get that speed for a large sequential read, but most likely not for small random writes.

For things like boot time, random access speeds are important (reading config files and stuff all over the place), so I think we should get the fastest 16GB eMMC we can get. I wouldn't go smaller than 16GB, because then you can't just apt-get install whatever you want.

Also, I would gladly pay 20 EUR more to get a fast 32GB eMMC.

I had considered bringing this up, but there is already a lot of confusion rolling around.

Interface speed is not the same thing as actual speed. The eMMC 4.5 bus can, in theory, handle throughput up to 208MB/s. By contrast, the interface for the SD card slots can, in theory, handle throughput up to 104MB/s. That is -interface- speeds.

The actual speed of the device that is plugged or soldered onto that interface can vary greatly. The eMMC in consideration may be rated at 150MB/s when connected to a version 5.1 bus, but what does it do when connected to a 4.5 bus? The bus dictates the ceiling or maximum transfer rate. A given feature could communicate at a fraction of that but still use those bus protocols.

The only way to know for sure which eMMC is fastest is to populate a set of processor boards with them and test. However, that might not even be a thing worth pursuing. Doing a complete benchmark product shootout among multiple versions and sizes of current eMMC would require a pile of time and resources that this project doesn't have.

I would like the project to use the fastest available 8GB or larger eMMC that can fit the budget. That said, the process to figure out exactly which one that is would be cost prohibitive.

The v5.1 part is going to be the one currently available in quantity. Even if it only hit -half- of it's rated theoretical throughput it would still be very quick storage. Get some samples of this part in, create a few prototype sample boards, test it for functionality (including basic throughput speeds).

16GB is a good solid place to be. With the minimal up-spend for 32GB, that makes good sense. However, pick a part, draw the line, get some samples produced to validate and move through it.
 
You would get 64GB with 20€ alone, and that part is faster (40MB/s) on sequential reads, than the 32GB one.
That is just hynix. There are of course many other producers, but speed scales with size.
 
You would get 64GB with 20€ alone, and that part is faster (40MB/s) on sequential reads, than the 32GB one.
That is just hynix. There are of course many other producers, but speed scales with size.
That is wholesale PART cost nto including shipping, mount fees, failure cost, etc. By the time it is fully expensed, that part would have a real cost of @30EUR and a cost to purchasers, with related costs and markup of something in the range of 50 EUR per unit.
 
The actual speed of the device that is plugged or soldered onto that interface can vary greatly.
Also don't forget to mention the fact that most manufacturers (try to) apply those interfaces not because they need that kind of throughput but for marketing reasons.
 
simply because EDs profit margin is already small enough.

How do you know this?

It's from The price calculation thread.

Usually, to be able to work on future projects (successors, improvements, docking station, etc.) you need to make some profit as well.

Often this is up to 50% for some huge smartphone companies, but I'm calculating with about 15%.
And that was before all the small decisions of slightly more expensive parts were made, like the other wifi chip and more keyboard leds for example. Of course it could be that some parts became slightly cheaper since the thread was started, what hopefully balanced the calculation a bit.

But I think It could be problematic at some point. All those decisions are just a few Euros here and there, but these costs add up. And at some point you would need a final stroke to be made
 
The eMMC 'should' only contain the OS, right? All applications and such could be on the uSD or SD cards, like with the Pandora.
For the OS the 8GB/16GB should be doable. And you always need more space so the 16GB should be okay regarding price.
If more space is required you can use the uSD slot, 128GB is €42 and 64GB is €15, so I assume that would be enough space for people the require that much additional space.
 
The eMMC 'should' only contain the OS, right? All applications and such could be on the uSD or SD cards, like with the Pandora.
For the OS the 8GB/16GB should be doable. And you always need more space so the 16GB should be okay regarding price.
If more space is required you can use the uSD slot, 128GB is €42 and 64GB is €15, so I assume that would be enough space for people the require that much additional space.

Most applications would also go on the eMMC, if you just apt-get install stuff.
 
Well, I hope I didn't shock you too much on April 1st.
Don't worry though, the Pyra is alive and well :)

So it's time for some real news...

1. Updated keymat design

As I mentioned, the keymat is working fine, but the hard edges of the keys makes gliding over the keyboard with your thumbs a bit uncomfortable.
That's why they will be rounded a bit.

The design is now finished, it will go into production next week.

Here's an updated rendering from me showing how the keys will look now.

View attachment 28182 View attachment 28183


2. Calculating the price and some more hardware infos

We're almost finished calculating the price, so we're also almost ready for the preordering.

The good news: We can almost certainly keep the projected price of 500 EUR for the normal unit. We're still working on the price for the 4G unit, mostly because we need to discuss with the module manufacturer.
Usually, the minimum order quantity for one module is 1000. However, as we need both US and EU modules, we need to work out a deal with them... we don't have a use of 1000 each at the beginning.
I'm sure we can get lower quantities as well, but that will raise the price - so we can't determine the final price (yet).

Onto the hardware infos, or, to be exact, the eMMC:
4GB eMMC cost between 3 - 4 EUR, 8GB eMMC also cost between 3 - 4 EUR (so it's a no-brainer to NOT use 4GB).
The 16GB one is between 6 - 7 EUR.

I just checked my working PC: My ArchLinux needs 15GB. That's with ALL programs installed I can imagine, KDE5 (Plasma), FireFox, Chromium, Vivaldi, FreeCad, Inkscape, Gimp, Krita, Scribus, LibreOffice, Claws-Mail, and so on.

So honestly, for something like the Pyra, where the eMMC is mostly being used for the OS and the preferred storage are SD Cards, 8GB would be enough - but I think 16GB would be nice.
This should be more than enough for a normal OS with the most important programs installed.

After all, we're not using Windows, where the base OS without any applications needs a lot more already...

What do you think?


3. The Case

I've received the next case part, which is the back lid.
So now I've got an almost fully assembled Pyra with real case parts!
Not yet finished is the mold with small parts: DPad, Stylus, Nubs, Stylus Holder, Logo.

Everything else is finished and assembled, here is a quick picture I posted on Twitter two days ago:

View attachment 28184

One thing you will probably notice is that the LEDs are not properly aligned behind the logo.
Don't worry about that, the Display PCB will be vastly changed as well: Right now it weighs 20g (which is a lot).
The final version will have quite a few holes cut in, which will lower the weight quite a lot, and the LEDs position will also be fixed then.

I'll make more hires pictures of the assembled prototype within the next few days.


4. The OS / Drivers

Nikolaus had a crashed harddisk, so he couldn't do much last week, sadly, he needs to reinstall his computer.
I did work on the OS a bit more, the keyboard layout is now fully working.
BTW: Using the right nub click as left mouse button and the left nub click as right mouse buttons works nice and is pretty comfortable!

I am now looking for devs who can help us finishing everything right now.
The LCD / SSD driver combination exists as shell script only right now:
http://git.goldelico.com/?p=gta04-k...8;hb=4f931554c5e733ffe056566a5280bec11965b791

This script needs to be changed into a kernel module.
Anyone here who would like to do that?
Send me a PM!

And maybe you could help with that too, but this is very specific:
The OMAP5 is not using PRMC (which are power saving functions) as good as it could - so there's a lot of potential to save battery.
Is anyone here experienced with that or wants to take a look at that?
Send me a PM as well :)


5. Website

As mentioned, I plan to overhaul the landing page a lot. Christoph.krn has already contacted me with quite a nice list of hidden features, which is a great start.
I'm looking for a HTML coder who could code a small page based on our input (layout, text, pictures).
Nothing too fancy, just some standard HTML, but it should be responsive (which is what I can not do myself).

I've also updated the blender file (which was used to render the pictures above), which will be used for that landing page to create various nice pictures.

I'll clean it up a bit and will release it as well, so any 3D artists here can play around with it a bit.


We need to let new users know what the Pyra can do and what's special about it!
You can also help working on the Wiki: (https://www.pyra-handheld.com/wiki/index.php?title=Main_Page)

The login is the same as on the forums, so if you got an account, you can login and work on it right away!

That's it for today. More news soon, some pictures tomorrow.
For the price you gave, I assume it's without taxes?
 
It might actually be worse than that, since I think there's a 50AUD "Processing Charge" too! (See https://www.border.gov.au/ReportsandPublications/Documents/reviews-and-inquiries/fact-sheet-ipc.pdf )

So:
If the Pyra+Shipping costs 667EUR (999AUD), an Australian will pay 667EUR (999AUD).
If the Pyra+Shipping costs 668EUR (1000AUD), an Australian will pay 768EUR (1150AUD)!!!
(Obviously the EUR values will vary based on the days exchange rate)

If The 4G Pyra ends up around 600EUR or something, it gets a bit scary.
I don't know what the timeline is for production/delivery, but add to all this that come July 1 2017 there won't even be the $1000 threshold. All imports will be subject to the 10% GST.
 
Well ED has been quoting Hynix eMMC 5.1 chips. So in line with that I looked at the Hynix page and it seems to just quote one speed for their eMMC 5.1 chips - I don't think they differ with size (someone correct me if that's wrong)

Anyway, here is Hynix's website page on their eMMCs : http://www.hynix.com/eng/product/nandEMMC.jsp

For:
Sequential Read it quotes 271 MB/s
Sequential Write it quotes 138MB/s
Randowm Write it quotes 11.3 K IOPS
Random Read it quotes 11 K IOPS

As we are limited to eMMC 4.5 with the OMAP5 , this limits things to about 200MB/s . Worth checking to see what we actually get, but it does look very fast indeed.

https://www.jedec.org/news/pressreleases/jedec-announces-publication-e-mmc-standard-update-v45: "e•MMC v4.5 offers performance enhancement features, including an interface bandwidth increase from 104 Mbyte/sec to 200 MByte/sec"
 
Well ED has been quoting Hynix eMMC 5.1 chips. So in line with that I looked at the Hynix page and it seems to just quote one speed for their eMMC 5.1 chips - I don't think they differ with size (someone correct me if that's wrong)

Anyway, here is Hynix's website page on their eMMCs : http://www.hynix.com/eng/product/nandEMMC.jsp

For:
Sequential Read it quotes 271 MB/s
Sequential Write it quotes 138MB/s
Randowm Write it quotes 11.3 K IOPS
Random Read it quotes 11 K IOPS

As we are limited to eMMC 4.5 with the OMAP5 , this limits things to about 200MB/s . Worth checking to see what we actually get, but it does look very fast indeed.

https://www.jedec.org/news/pressreleases/jedec-announces-publication-e-mmc-standard-update-v45: "e•MMC v4.5 offers performance enhancement features, including an interface bandwidth increase from 104 Mbyte/sec to 200 MByte/sec"

Whether 200 or 200MB/s + is quite irrelevant. Real world numbers are nowhere near the limit. And its not sequential reads that matter most anyhow. So eMMC 4.5 is not a effective limit to the speed.
Speed scales with size and first party numbers should never be trusted.

Edit: Implementation plays a considerable role http://www.harddrivebenchmark.net/hdd.php?hdd=Hynix+HBG4e&id=6314
 
Last edited:
Speed scales with size and first party numbers should never be trusted.

You keep stating this, but nowhere in reality have I found it to be actually true. Also, you're ignoring the third leg of that table - costs.

Speed scales with parallel (RAID type) structures - which are not necessarily directly related to the capacity of the device.

For the longest time, the fastest SD cards were capped in the 16GB capacity range. Why? The controller required to handle those multiple memory chips to get the parallel, and thus faster, throughput combined with the physical footprint of the memory modules.

Advanced controllers and inclusion of controllers within the memory modules has meant that single silicone runs can generate a series of chips with varying capacities and speeds. Picture a microchip divided into 5 parts. Part 1 is the controller. Parts 2-5 are the memory. Yields are not perfect - often there will be a flaw in one section of a chip. By 'binning' they are able to still sell those 'flawed' parts at a lower spec. If the flaw is in the controller, then the chip may be usable as daughter-chip to another chip with a good controller. If the flaw is in one of the memory chunks, then that chunk may be disabled and that chip gets binned as 3/4 capacity and about 3/4 the speed as it has lost one of the parallel structures. So, yes, within a single line of chips with integrated controllers, you will find varying capacities that do follow speed. However, back to that binning thing, the chip manufacturers know that speed and capacity are both important and that drives their pricing schedule. 'Perfect' binned chips will demand a substantial premium.

There are three components to this puzzle. Speed, Capacity and low cost. Choose any TWO as the third factor will move exponentially in an unfavorable direction. For the Pyra, that low cost third leg is pretty important.

"But but it's only 20EUR more!"

20EUR in a single part cost with production failure rates, board population fees, markup to cover returns, advertising, profit winds up being a 50EUR single part by the time the device sells retail.

A 6EUR eMMC winds up being about 15EUR in the device or about 3% of the Pyra's retail price.
A 10EUR eMMC winds up being about 25EUR in the device or about 5% of the Pyra's retail price.
A 20EUR eMMC winds up being about 50EUR in the device or about 10% of the Pyra's retail price.

I suspect that ED budgeted something more on the 3-5% of final price range for the eMMC, not 10%.

"But but can't they make a special one just for me with individual purchased parts because I have deep pockets and am oh so special?"
ED mentioned that the part itself comes on spools of 1600 units. Up front costs for the 10EUR part are then 16000EUR. Up front costs for the 20EUR part are 32000EUR. If it is going to be a 'special run' then there are setup and testing fees associated with that change. Back in October ED raised 70K to do the prototype run, which is the closest thing to the 'special run' that you're asking for. I'm not sure how much of that 70K was spent in that one setup and testing run, but it was able to produce 10 units. Prototypes and 'special' units are insanely expensive to produce.

I understand that there are already issues of minimum order quantity causing consternation over the 3 versions that they're already committed to (Euro4g, US4g, none). I'm not sure how those modules are priced - they're large enough they're likely trays not spools - or how many are in a tray/spool, but those factors rapidly dictate how many discrete multiples of units must be sold of each type to make the thing work.

Lets not complicate things further. 16GB or 32GB - either is more than 'needed' and fine. Whichever fits the budget.
 
Back
Top