Good Progress on The Pyra Hard Design

It’s mostly all about the Pandora around here these days, but today let me give you some updates about her little sister the Pyra. There’s been some good progress recently on that front and we can foresee a late 2015 release window…

Evil Dragon (aka ED, leading the DragonBox Pyra development efforts) shared in a recent series of posts that several critical pieces of the Pyra hardware design are nearing completion.

First, he has received the prototype of the main PCB (driving the keyboard inputs, SD Cards access and battery connection among other purposes), that will need to be populated in order to be sent for testing.

The main prototype PCB, with the keyboard traces.

Next, the CPU board is still being worked on but it’s half way through and should be finished by end February. The OMAP5 SoCs needed for testing will be on their way as well by the same timeframe. As to why the OMAP was chosen, let me refer you to this prior article of mine. Note that the design of the Pyra is quite flexible since it works via modules (the CPU PCB can be changed later on to feature a different, newer ARM SoC or possibly an Intel x86 one).

The display has been apparently decided and it will be sourced from BOE (720p). The rotator chip from Solomon is available but cannot be tested right now because of an amusing set of circumstances:

Evil Dragon: The routing of the Video signal would go through the following:

OMAP5 SoC -> Rotator Chip -> Display

The signal is being sent via MIPI. MIPI is a digital standard that allows to send commands (like enable / disable rotation, change backlight, change powersaving settings, etc.) as well as a video signal.

The first thing to do to make a display work at all is to send an initialization command, so that it switches on, configures itself and accepts the MIPI Video signal. This is what I mentioned above and that is already working fine.

Then we got the rotator chip in between. We need to be able to send commands both to the rotator chip and to the display. To be able to do that, Solomon (the manufacturer of the chip) implemented an easy way to do that:there is a bypass mode to ensure all commands will be directly sent to the display. To to initialize our display, we need to switch the rotator chip to bypass mode, send the initialization sequence, disable bypass mode and enable the rotation. The bypass mode can be enabled or disabled with a command sequence. The sequence starts with 0xFF.

This would in theory work perfectly fine – but the initialization of the display ALSO starts with 0xFF!

Solomon had also thought of that. In order to send a MIPI command sequence that starts with 0xFF, you simply send 0xFF twice. So far no problem. However: MIPI command sequences have a maximum length of four bytes. And the initialization command sequence of our display uses the full four bytes.

Now THAT’S a problem: As we need to send 0xFF twice to tell the Solomon chip to pass through, we can only send a sequence of three bytes.

So… Murphys Law has fully struck us. We got the worst combination possible: if the initialization command sequence of the display wouldn’t start with 0xFF (or the Solomon chip would use a different byte for the bypass command), it would work without issues. And even then – if the sequence would only be 2 or 3 bytes long, it would STILL work. A start with 0xFF and 4 bytes long however is the ONLY combination that doesn’t work!

But don’t be afraid – there’s a solution for this.. it just means a bit of more work for us: We can flash the display driver IC so that it initializes the panel automatically as soon as it is connected.

So because of these setbacks, the rotator chip can only be tested after end of February (or let’s say March) and it looks like the display PCB will be the last PCB to be finalized.

The display PCB, unpopulated.

The LCD cable design for the display is pretty much over and samples will be available by the end of February. If you ever had any pink screen issue with the Pandora (where the LCD cable failed after too many clamshell openings) things should look brighter now. The new LCD cable has redundant traces and is much more simple than the Pandora’s, and only printed on a single face. Therefore it should have much lower failure rates.

The exterior case is still ongoing new iterations. The latest version features improved shoulder buttons design (a total of four, 2 on each side) as suggested by the community several months ago, but the case dimensions have become wider by 1.4 cm to ensure space for the screws to hold the screen, as recommended by the supplier.

The new shoulder buttons, seen from the inside.

This extended size is a problem. If you have ever used a Pandora, you would probably know the keypad is just the right size to be used with both thumbs, but if you extend it further it could make the center keys difficult to reach. ED is consulting the vendor to see if they can replace the screws with clips in order to gain space and keep the size close to the initial plan. New prototypes will probably be available by end February.

Keymats are on hold for now, as their final design will depend on the case final dimensions as well. Apparently getting new samples only take about 2 weeks so that should not become a limitating factor for the timeline. Don’t ask me about the final keyboard layout decision, as far as I know things are not set in stone yet.

As for the battery, it’s pretty much ready since the dimensions of the battery compartment are set. 20 samples of the new 6000 mAH battery are on their way and if they work as expected 3000 units will be produced.

ED has confirmed in a different post as well that the RAM size should be fixed to 2 Gb to start with. Some were worried we may end up with 1Gb with is barely enough for some applications, but 2 Gb is somewhat reassuring. There will be ways to increase the RAM size down the road as well as the SoC can support up to 8 Gb.

All in all, I think ED is doing a great job to ensure the Pyra’s design is more robust in every single way than the Pandora’s. It’s taking time, but things are shaping relatively well so far and he is carefully planning for all elements.

If you care about my predications, let’s say testing takes place in March, there will probably be a few fixes needed, so add another month to get the new prorotypes done, bringing us to mid-end April. If everything goes well from there ED will have to prepare for a manufacturing run, add another month to prepare and get all parts ready with GC, for a pilot run around June. Following that if everything went exactly as expected you could move to first batch production but it will easily take more time to get a large number of parts, so somewhere around August or September. That timeline could easily be delayed by several weeks if a second pilot run is needed to fix some issues. Overall, I am pretty confident we wil not see a Pyra for sale (not talking about prototypes, but actual batch units) until Q3 or maybe even Q4. At least end 2015 seems relatively likely at this stage, but we will know a lot more about that once the first tests are done in late February, early March.

Post navigation

What’s This ?

GiantPockets (Previously Known as Pandoralive.info) is a blog dedicated to the Pocket Linux Handheld computers (such as the Open Pandora and the upcoming DragonBox Pyra, but also non-gaming handhelds like the GPD Pocket). These handhelds can be used for gaming but for a bunch of serious uses as they can run full Linux distributions and are typically equipped with physical keyboards. You will find here news regarding their latest software offering, hardware updates, development stories and testimonies of users.