I know you've been waiting for news - and finally, you shall receive them!
GamesCom was a LOT more work than I thought - I didn't have a single free day for five weeks now, and still haven't been able to catch up with everything.
But - as usual: That doesn't mean there hasn't been any progress!
So here you go!
1. The cases
Ah well, the cases.
Work in Greece has just resumed (as mentioned, there were holidays in August) and I just had a phonecall with my contact today.
FormAction is currently in the process of updating the 3D data to represent the current mould.
Which means I can check everything upfront, without having to wait for samples.
Also, the special material for mobile devices is on the way and should arrive end of this week (let's hope they're right).
But you might remember that I considered a second company as another option, one with which I have already worked together and produced SNES, MegaDrive, NES and N64-shells:
Yes, we are keeping this open as an option. They've got a very interesting material as well: A mixture of plastic and carbon, which increases the durability of the plastic a lot (on their own tests, the normal plastic broke with 400kg force whereas the plastic/carbon-mix hold up to 1,5t!)
And someone from the community has contacted me: He's working for a plastic production company in Germany. I'll send them a Pyra case as well and will ask for a quotation.
So we have multiple options left.
Of course, I'll let you know which path we'll choose.
This mainly depends on the material arriving and the case quality of the next (and hopefully final) sample we'll receive from FormAction.
2. The cooling
While I was at the GamesCom, I found the time to modify ptitSeb's unit with the planned cooling (fully passive).
And I've got good news here: It actually worked out as I had planned!
With the cooling, the Pyra doesn't get warm at all with normal usage and stays a lot colder than the GPD Win even when running with full power for about 30 minutes at 1GHz.
It works as intended.
You can see that it works clearly in these heat-pictures we took of the unit at the GamesCom.
This was after it was compiling for about 20 minutes. The hottest area in the unit is the heatsink - with about 40°C.
The cooling consists of an off-the-shelf heatsink hidden below the USB port and some special 0.2mm thin heatpipe-material from 3M to transport the heat from the CPU to the heatsink.
The only thing we can improve here is to use two heatsinks (another one hidden below the second USB port) to keep it cool for an even longer period of time.
So all good?
Ah well - almost. But there's not much about that:
When running the unit at full load with 1.5GHz, it heats up A LOT more.
The CPU reaches over 90°C within a few seconds - and then immediately throttles.
As expected (like with any mobile processor out there): Fullspeed is not meant to be used for a longer period of time, just for a few seconds.
For normal usage, the device feels more fluid and snappier with 1.5GHz enabled, and won't heat up, as you usually only have short peaks of high CPU time.
The maximum speed you can run it with full CPU load for longer periods of time is therefore something between 1 and 1.5GHz.
Note: All the tests are for BOTH cores running with full CPU load, not just one.
And don't forget the A15 is two generations newer than the A8 being used in the Pandora, so you can't compare the raw GHz values.
The Pyra with 500MHz Single Core should be approximately as fast as a 1GHz Pandora. So with 1GHz Dual-Core, that's about four times the speed already.
So while it won't be as fast as current smartphones (surprise
), it will still be quite a huge upgrade compared to the Pandora.
And I'll work on a CPU Upgrade board as soon as we are finished here.
3. The keymat
'What? I thought it's finished!' - I hear some of you say.
Yes, indeed it is, and there is nothing to report here.
However, as we had many many users at the GamesCom try out the final keymat, I wanted to let you know that everyone liked how it feels.
Many praised the tactile feedback - especially when comparing them to the GPD Win (which we also had with us).
I was pretty happy about that - as you all know how many versions of the keymat we had
So yes, it seems I'm not the only one who likes the keymat
4. The sirring noise issue
And once again: Community to the rescue!
I'm not sure who suggested it, but the Q-Tip solution to find out the exact component seems to have worked for Nikolaus!
He has now identified the culprits: Three capacitors are the reason for the noise.
And he's already working on a way to fix that.
There are multiple ways: We could replace those with Tantalum capacitors - but we're not really fans of that (because of ethical reasons).
Another solution would be to use multiple smaller ones instead of one bigger one.
I'll let you know how we proceed here. The important thing was that we finally were able to find out the culprits.
The fix should only take a couple of days.
5. The 4GB RAM issue
Ah, well, yes... basically the only real remaining issue for the moment.
As soon as we fix this one, I guess we're ready for production!
So, what's the status?
Well, we're heavily working on that!
Tony got it to work stable on his unit by running it with 1.42V or higher or with 1.35V and improper timing settings.
Whether his patches work well with ther CPU boards is something we're testing right now.
Surely we won't use improper timing settings, as it would most likely NOT work with all CPU boards (chips aren't always the same).
Juliano also has done more simulations and the signal integrity is almost perfect. So that should be fine.
So with all the tests, the following scenarios are possible:
1. There's too much noise on the power traces or the power traces aren't wide enough which would cause a power loss.
2. The EMIF (Memory timing) settings aren't setup properly yet. We're still working on those (it's pretty complex!)
3. The memory chip itself is bad (which is unlikely, as it is being used in other devices as well).
What's our plan to figure that out?
We already ordered samples of a different RAM Chip (also 4GB in total size) by a different manufacturer.
We'll populate one PCB with those. If that chip works, we can pretty much rule out 1.
If the new RAM also doesn't work, the next step would be to populate some of the new optimized CPU boards with the 4GB RAM chips.
While the power supply for the RAM hasn't changed here, the noise of the OMAP5/PALMAS is reduced - and it could be that noise is too much for the RAM Chips right now.
So it might simply work with the optimized CPU boards.
We're also still working on the EMIF settings for the current RAM chip. There are not that many parameters left to try, but it could simply be ONE that causes the freezes.
Remember how long 1.5GHz didn't work? Now they work stable on the unoptimized boards as well - that also was just one parameter wrongly setup.
For mass production, I have already various solutions in mind...
1. If it turns out the CPU board layout needs to be fixed to get the 4GB running, we would have the problem that we already have 500 CPU boards lying at GC. Throwing them away would be a waste of 8000 EUR, so I would ask all everyone who preordered if he would be fine with a 2GB unit. If we get enough who would be fine with that, we could order the 2GB RAM chips and populate right away.
2. If the new RAM Chips work (but the old won't), we'd need to check the price difference and whether we could sell or give back the already delivered 4GB RAM chips. This could cause quite a loss (10k - 20k EUR), but thanks to my shop running well, we would be able to afford that (it would still hurt a lot).
It could also be a mixture of both.
But let's first try to get the RAM to work before we're doing more speculations!
After all, it runs stable on ONE existing CPU board, so whatever is keeping it to run stable on all of them can't be much.
Maybe it's really just the higher amount of noise coming from the older CPU Board revision...
We keep working on that - and you can be sure I'll shout it out loud once the RAM is working!
This is currently my main concern - as everything else is working already.
GamesCom was a LOT more work than I thought - I didn't have a single free day for five weeks now, and still haven't been able to catch up with everything.
But - as usual: That doesn't mean there hasn't been any progress!
So here you go!
1. The cases
Ah well, the cases.
Work in Greece has just resumed (as mentioned, there were holidays in August) and I just had a phonecall with my contact today.
FormAction is currently in the process of updating the 3D data to represent the current mould.
Which means I can check everything upfront, without having to wait for samples.
Also, the special material for mobile devices is on the way and should arrive end of this week (let's hope they're right).
But you might remember that I considered a second company as another option, one with which I have already worked together and produced SNES, MegaDrive, NES and N64-shells:
Yes, we are keeping this open as an option. They've got a very interesting material as well: A mixture of plastic and carbon, which increases the durability of the plastic a lot (on their own tests, the normal plastic broke with 400kg force whereas the plastic/carbon-mix hold up to 1,5t!)
And someone from the community has contacted me: He's working for a plastic production company in Germany. I'll send them a Pyra case as well and will ask for a quotation.
So we have multiple options left.
Of course, I'll let you know which path we'll choose.
This mainly depends on the material arriving and the case quality of the next (and hopefully final) sample we'll receive from FormAction.
2. The cooling
While I was at the GamesCom, I found the time to modify ptitSeb's unit with the planned cooling (fully passive).
And I've got good news here: It actually worked out as I had planned!
With the cooling, the Pyra doesn't get warm at all with normal usage and stays a lot colder than the GPD Win even when running with full power for about 30 minutes at 1GHz.
It works as intended.
You can see that it works clearly in these heat-pictures we took of the unit at the GamesCom.
This was after it was compiling for about 20 minutes. The hottest area in the unit is the heatsink - with about 40°C.
The cooling consists of an off-the-shelf heatsink hidden below the USB port and some special 0.2mm thin heatpipe-material from 3M to transport the heat from the CPU to the heatsink.
The only thing we can improve here is to use two heatsinks (another one hidden below the second USB port) to keep it cool for an even longer period of time.
So all good?
Ah well - almost. But there's not much about that:
When running the unit at full load with 1.5GHz, it heats up A LOT more.
The CPU reaches over 90°C within a few seconds - and then immediately throttles.
As expected (like with any mobile processor out there): Fullspeed is not meant to be used for a longer period of time, just for a few seconds.
For normal usage, the device feels more fluid and snappier with 1.5GHz enabled, and won't heat up, as you usually only have short peaks of high CPU time.
The maximum speed you can run it with full CPU load for longer periods of time is therefore something between 1 and 1.5GHz.
Note: All the tests are for BOTH cores running with full CPU load, not just one.
And don't forget the A15 is two generations newer than the A8 being used in the Pandora, so you can't compare the raw GHz values.
The Pyra with 500MHz Single Core should be approximately as fast as a 1GHz Pandora. So with 1GHz Dual-Core, that's about four times the speed already.
So while it won't be as fast as current smartphones (surprise
), it will still be quite a huge upgrade compared to the Pandora.And I'll work on a CPU Upgrade board as soon as we are finished here.
3. The keymat
'What? I thought it's finished!' - I hear some of you say.
Yes, indeed it is, and there is nothing to report here.
However, as we had many many users at the GamesCom try out the final keymat, I wanted to let you know that everyone liked how it feels.
Many praised the tactile feedback - especially when comparing them to the GPD Win (which we also had with us).
I was pretty happy about that - as you all know how many versions of the keymat we had
So yes, it seems I'm not the only one who likes the keymat
4. The sirring noise issue
And once again: Community to the rescue!
I'm not sure who suggested it, but the Q-Tip solution to find out the exact component seems to have worked for Nikolaus!
He has now identified the culprits: Three capacitors are the reason for the noise.
And he's already working on a way to fix that.
There are multiple ways: We could replace those with Tantalum capacitors - but we're not really fans of that (because of ethical reasons).
Another solution would be to use multiple smaller ones instead of one bigger one.
I'll let you know how we proceed here. The important thing was that we finally were able to find out the culprits.
The fix should only take a couple of days.
5. The 4GB RAM issue
Ah, well, yes... basically the only real remaining issue for the moment.
As soon as we fix this one, I guess we're ready for production!
So, what's the status?
Well, we're heavily working on that!
Tony got it to work stable on his unit by running it with 1.42V or higher or with 1.35V and improper timing settings.
Whether his patches work well with ther CPU boards is something we're testing right now.
Surely we won't use improper timing settings, as it would most likely NOT work with all CPU boards (chips aren't always the same).
Juliano also has done more simulations and the signal integrity is almost perfect. So that should be fine.
So with all the tests, the following scenarios are possible:
1. There's too much noise on the power traces or the power traces aren't wide enough which would cause a power loss.
2. The EMIF (Memory timing) settings aren't setup properly yet. We're still working on those (it's pretty complex!)
3. The memory chip itself is bad (which is unlikely, as it is being used in other devices as well).
What's our plan to figure that out?
We already ordered samples of a different RAM Chip (also 4GB in total size) by a different manufacturer.
We'll populate one PCB with those. If that chip works, we can pretty much rule out 1.
If the new RAM also doesn't work, the next step would be to populate some of the new optimized CPU boards with the 4GB RAM chips.
While the power supply for the RAM hasn't changed here, the noise of the OMAP5/PALMAS is reduced - and it could be that noise is too much for the RAM Chips right now.
So it might simply work with the optimized CPU boards.
We're also still working on the EMIF settings for the current RAM chip. There are not that many parameters left to try, but it could simply be ONE that causes the freezes.
Remember how long 1.5GHz didn't work? Now they work stable on the unoptimized boards as well - that also was just one parameter wrongly setup.
For mass production, I have already various solutions in mind...
1. If it turns out the CPU board layout needs to be fixed to get the 4GB running, we would have the problem that we already have 500 CPU boards lying at GC. Throwing them away would be a waste of 8000 EUR, so I would ask all everyone who preordered if he would be fine with a 2GB unit. If we get enough who would be fine with that, we could order the 2GB RAM chips and populate right away.
2. If the new RAM Chips work (but the old won't), we'd need to check the price difference and whether we could sell or give back the already delivered 4GB RAM chips. This could cause quite a loss (10k - 20k EUR), but thanks to my shop running well, we would be able to afford that (it would still hurt a lot).
It could also be a mixture of both.
But let's first try to get the RAM to work before we're doing more speculations!
After all, it runs stable on ONE existing CPU board, so whatever is keeping it to run stable on all of them can't be much.
Maybe it's really just the higher amount of noise coming from the older CPU Board revision...
We keep working on that - and you can be sure I'll shout it out loud once the RAM is working!
This is currently my main concern - as everything else is working already.
