As promised last week, I'll make a detailed explanation how the sales price of a devices comes together.
But before that, let's start with the other things that happened.
1. MIPI steps...
Our journey through the wonderful world of MIPI continues (well, mostly Nikolaus' journey, as he is doing all the work here
)
The only thing I tried was finding a more in-depth datasheet of our LCD - and while doing that, we found out we received a slightly wrong datasheet from our distributor.
We had a more recent revision of the LCD than the datasheet was for, and while technically, it only has a bit higher brightness, it turned out that the initialization sequence had some different bits as well... oh well.
Well, getting the new datasheet was possible with just an eMail to our distributor, and then Nikolaus hacked in the new initialization sequence.
Of course, nothing will ever work out of the box - Nikolaus had a typo in the sequence as well, but after fixing that, the display at least did something!
It turns completely black!
While that doesn't sound so amazing, it actually is - it is another step of communication with the LCD.
Nikolaus has already continued to work on it, together with some support from TI and his oscilloscope. It seems the OMAP5 Display kernel driver also has a bug - it doesn't send a clock to the display (which is mandatory to send the actual video data...)
So the next step is clear: Find and fix the bug in the driver.
To be continued (hopefully next week...)
2. Keymat Meeting
While Nikolaus was hacking with MIPI, I had a meeting with a company from Munich about the keymat production.
Our keymat is a bit more complicated than the old one, as it needs to have semi-transparent key labels for the background light.
I also wish to improve the overall handling of the keymat (flat keys, slightly easier to push).
For that, we'll receive various samples in with different materials and thicknesses.
But until then, it's still a loooong way. First, the design has to be finished, then the mold has to be created, then it's time for samples.
That's still a few months away, but it seems we finally have a new company for the keymat as well!
3. Memory and Storage
If you followed the boards, you probably have seen the topic about memory and storage.
About memory: More than 2GB doesn't really make sense. You wouldn't gain much, but it would need more space, power and increase the costs.
I've run multiple things at once on my devboard (GIMP, LibreOffice, PSX Emulation, FireFox, etc.) and it never needed more than 600MB memory.
2GB should be enough for various multitasking threads for everyone.
About internal storage: This is another interesting task.
Basically, there are three possibilities:
If we use a Micro-SSD via SATA, we should be able to include an internal Micro-SD Card slot as well.
Using Micro-SD Card is a neat solution, as the user can replace it with a bigger card if he wants.
eMMC is the standard in most devices (and there probably is a reason for it).
How do all these compare in terms of speed, power consumption, reliability and availability (also in the future)?
That's something we need to find out.
Next week is the Embedded World in Nuremburg, and we'll be there and visit various manufacturers and distributors and try to find out the one that suits the Pyra best.
4. Battery Size
You know our main idea was to keep the Pandora battery, so you can use both in both systems.
The Pyra shouldn't need more power for the same tasks as the Pandora (in fact, it should use less), but you probably also want to do things that the Pandora was too slow for. Then power consumption can go up, so a slightly larger battery would help.
That's why we've been checking on this.
Basically, to get 6000mAh (which is 2000 more than the Pandora battery has), we'd need to increase the size of the battery a bit.
4mm in width and 1,2mm in thickness.
On the Pyra, this shouldn't be a big problem, and I think it can be done without increasing the size of the unit (needs a bit more puzzling).
Also, with a frame we could offer, the normal Pandora battery can also be used.
On the Pandora, the width SHOULD be possible (as the current battery compartment is bigger than it should be, the battery moves around so we even need to pad it), and the height would need a slightly changed battery cover, but I should be able to offer that as well.
To get enough width, you might need to file off a bit in the battery compartment, so with a bit of modifying the case, you would be able to use the bigger battery in the Pandora as well... this needs to be checked though, and I will do that with samples.
All in all, we're moving forward in different directions.
Still a long way to go, but we did expect that
But before that, let's start with the other things that happened.
1. MIPI steps...
Our journey through the wonderful world of MIPI continues (well, mostly Nikolaus' journey, as he is doing all the work here
)The only thing I tried was finding a more in-depth datasheet of our LCD - and while doing that, we found out we received a slightly wrong datasheet from our distributor.
We had a more recent revision of the LCD than the datasheet was for, and while technically, it only has a bit higher brightness, it turned out that the initialization sequence had some different bits as well... oh well.
Well, getting the new datasheet was possible with just an eMail to our distributor, and then Nikolaus hacked in the new initialization sequence.
Of course, nothing will ever work out of the box - Nikolaus had a typo in the sequence as well, but after fixing that, the display at least did something!
It turns completely black!
While that doesn't sound so amazing, it actually is - it is another step of communication with the LCD.
Nikolaus has already continued to work on it, together with some support from TI and his oscilloscope. It seems the OMAP5 Display kernel driver also has a bug - it doesn't send a clock to the display (which is mandatory to send the actual video data...)
So the next step is clear: Find and fix the bug in the driver.
To be continued (hopefully next week...)
2. Keymat Meeting
While Nikolaus was hacking with MIPI, I had a meeting with a company from Munich about the keymat production.
Our keymat is a bit more complicated than the old one, as it needs to have semi-transparent key labels for the background light.
I also wish to improve the overall handling of the keymat (flat keys, slightly easier to push).
For that, we'll receive various samples in with different materials and thicknesses.
But until then, it's still a loooong way. First, the design has to be finished, then the mold has to be created, then it's time for samples.
That's still a few months away, but it seems we finally have a new company for the keymat as well!
3. Memory and Storage
If you followed the boards, you probably have seen the topic about memory and storage.
About memory: More than 2GB doesn't really make sense. You wouldn't gain much, but it would need more space, power and increase the costs.
I've run multiple things at once on my devboard (GIMP, LibreOffice, PSX Emulation, FireFox, etc.) and it never needed more than 600MB memory.
2GB should be enough for various multitasking threads for everyone.
About internal storage: This is another interesting task.
Basically, there are three possibilities:
- eMMC (non-replaceable)
- Micro-SD Card (user-replaceable)
- Micro-SSD via SATA (non-replaceable)
If we use a Micro-SSD via SATA, we should be able to include an internal Micro-SD Card slot as well.
Using Micro-SD Card is a neat solution, as the user can replace it with a bigger card if he wants.
eMMC is the standard in most devices (and there probably is a reason for it).
How do all these compare in terms of speed, power consumption, reliability and availability (also in the future)?
That's something we need to find out.
Next week is the Embedded World in Nuremburg, and we'll be there and visit various manufacturers and distributors and try to find out the one that suits the Pyra best.
4. Battery Size
You know our main idea was to keep the Pandora battery, so you can use both in both systems.
The Pyra shouldn't need more power for the same tasks as the Pandora (in fact, it should use less), but you probably also want to do things that the Pandora was too slow for. Then power consumption can go up, so a slightly larger battery would help.
That's why we've been checking on this.
Basically, to get 6000mAh (which is 2000 more than the Pandora battery has), we'd need to increase the size of the battery a bit.
4mm in width and 1,2mm in thickness.
On the Pyra, this shouldn't be a big problem, and I think it can be done without increasing the size of the unit (needs a bit more puzzling).
Also, with a frame we could offer, the normal Pandora battery can also be used.
On the Pandora, the width SHOULD be possible (as the current battery compartment is bigger than it should be, the battery moves around so we even need to pad it), and the height would need a slightly changed battery cover, but I should be able to offer that as well.
To get enough width, you might need to file off a bit in the battery compartment, so with a bit of modifying the case, you would be able to use the bigger battery in the Pandora as well... this needs to be checked though, and I will do that with samples.
All in all, we're moving forward in different directions.
Still a long way to go, but we did expect that
Last edited by a moderator:
