You'll hate this post. And you'll love this post.


i'm not sure we should allow software to know the color of the pyra... think of what evil uses this could be put to. a blue pyra only BSODs, a red pyra overheats, a transparent pyra gets all the optimizations, etc.
 
I suppose we could put a color code in /etc/pyra/case_color or something like that, which could give a hint to software that cares about it (but you can modify it if you want).
 
Glad to see that it progresses steadily and methodically. When every detail is just right then we hit mass production.
I't's interesting to hear about the mould process.
 
I can't wait for this forum to devolve into class wars and sectarian violence over which colour Pyra you have/want.

BETTER RED THAN DEAD

PURPLE RAIN, F****R!

MY CONSCIENCE IS CLEAR!
 
The samples I get will be dark transparent which helps finding out any issues, as you can see if some parts don't fit properly.
Look forward to seeing these, as I think this could be a very good color choice vs. clear transparent that may let too much light leak.
 
I suppose we could put a color code in /etc/pyra/case_color or something like that, which could give a hint to software that cares about it (but you can modify it if you want).
...sure, that's always possible. Then it has to be set again after reflashing/reinstallation.

That doesn't help this first-boot setup that would like to use the case color early, like so (Pyra render by fusion_power):
hellolo.png


A (semi-)persistent "case" integer or so (there may be complex designs) in hardware storage would be neat-o there. I have no idea whether the Pyra hardware is giving a non-dirty way to do this.
 
I don't really think there is any persistent memory to differentiate model differences (ex Wifi only, cell variety, etc...) let alone case color.
 
And wouldn't something like that just lead to more headaches? You'd need to make sure the boards you are assembling match the case colour? Or reflash them with whatever identification needed. So in a scenario where ED has a whack of boards sitting around set for Pink and he only has Red cases he'd need to reflash all of them instead of just assembling and shipping.

I can see that getting way out of hand.
 
I don't really think there is any persistent memory to differentiate model differences (ex Wifi only, cell variety, etc...) let alone case color.

Actually, there is. The display PCB, for example, has a model number included on the PCB which can be read out.
This is necessary for future upgrades, if we want one OS for all the units.
The system needs to know what display driver to initialize, for example, so it needs to know which display PCB there is.

However, that's being done during PCB production, and when the PCBs are being produced, nobody knows which color they get in.

What's possible would be to create three different testing and flashing cards that could be used during production.
But that would only work for the initial flash, not if a customer reflashes.

I doubt anyone would have a problem if the unit in the picture has a different color than his own one, though :)
 
At least ED learned a lot about case production, so thanks for sharing that experience on the boards.

When production is finished, will ED also get the molds (or will they keep it in case you need more produced)?

You might not have case colors influence the model, but a model could probably read its version and have your desktop auto-themed.
If the PCB wasn't finished you could have a contact-strip on the back where the case could have some pins to indicate what type it is (but that is a pretty expensive way to do this compared to do it manually).
 
[...] So in a scenario where ED has a whack of boards sitting around set for Pink and he only has Red cases he'd need to reflash all of them instead of just assembling and shipping.


I can see that getting way out of hand.
...except if end-of-line testing is being done (which I don't know, but as far as I know that's why there is an input tester on the Pandora), then that means that the devices have to be booted after assembly anyway (to test buttons, screen connection, etc.). You don't have to touch the OS block device to set a variable that's stored elsewhere in the hardware, you can handle it the same way that applying a serial number sticker can be used to signify an end-of-line quality check pass.

I don't really think there is any persistent memory to differentiate model differences (ex Wifi only, cell variety, etc...) let alone case color.
By design, such electronic components have to be (mostly) software-identifiable as what they are. That's not the case with case color...
 
Here's an informative video on plastic injection molding if you want to learn more (Expand Spoiler)
 
By design, such electronic components have to be (mostly) software-identifiable as what they are. That's not the case with case color...
Not really, there may be ways of identifying which model you have by seeing which cell module is present or not. But I doubt there will be anything like an eFUSE blow, or discrete PROM that will identify model type and what not.
 
I can see how a stored case color accessible from software can be handy sometimes, but I'd trust the average user to be able to select the right color in the first startup wizard for example.
That could also cater for custom color selection for modded cases or just random preference.
It may be cool to have it automated, but it's not worth the effort imo.

But in the end, in Nintendo games/manuals it's always the white version of the device shown, I haven't heard anyone being confused from that yet (reminds me of the lettered game button "issue").
 
To all the software/ case color ideas, I would say: That only would be worth bothering, if the software could CHANGE the case color :)

@directive0
As for the custom color runs: That will be difficult/ expensive. As far as I know, you have to run a minimum amount of parts to be cost efficient. To get the injection running, there is some waste involved (like mold not headed up, plastic not in perfect flow yet and such), while starting the process.
So there is a minimum amount of cases necessary per color. You are perhaps free to choose a minimum run and buy all the cases that will be produced in that run. But I guess that will be close to 5 digits in cost. Or there have to be enough people wanting the same color.

The other question is, if my assumption about the "change color in production run" (and get mixxed colored cases inbetween) will work... (I perhaps want one of the mixed color cases...)
 
@elvissteinjr , it's not about solving an issue, it's about improving the experience. User experience is one area where open handhelds are often lacking (significantly).
 
If there was a camera it would be easy to light up the case while closed, then capture colour that way.

Or setting the case_colour could be part of the testing-procedure.

Sleek to have lighting that matches the case. Fun to have that to use in games aswell.
 
Wouldn't you need lots of special rubber plugs for all the ports then?
I actually have a silicone set of these and have used them on my phone and laptop. They're cheap and pretty nice quality. Search for "laptop dust plugs".
 
If you really really care about having the pictures in the initial screens, make the first one a big freekin' color wheel and ask the user to touch the screen at the point that most closely resembles their case color. To me, including that step would be far more annoyance than it's worth. A generic color matching a/the color of a/the initial production units should be more than adequate.
 
When does the initial contents of the eMMC get flashed? Before or after assembly?

If the eMMC is flashed by booting from a specially prepared SD card (which does some automatic or semi-automatic hardware testing, I suppose, and then installs the OS), then it could be an option to prepare different first-flash SD cards for the different models (not just the different colors but also 3G module or not). I don't think the color thing is very important, but it could make sense to use a different flavor of the OS for models with and without 3G/GPS: e.g. I can imagine some drivers and packages would be useless without 3G/GPS, so it seems right to omit them on those models (so they have some more available eMMC space).
 
Back
Top