Jump to content

Most Liked Content

#300770 Christmas, the past and the future (2013-12-24)

Posted by EvilDragon on 24 December 2013 - 05:11 AM

Well, it's christmas time and most of you here will probably spending some quiet days with their family.

I wish you all a very merry christmas - and as the end of the year is approaching, I'd like to look back into the past year and also a bit into the future.


1. Pandora - it was still a rollercoaster ride - with a happy ending


The first few months were awesome. Production was swiftly moving, everyone could get a Pandora from stock, I finally delivered the units to all my remaining preorder customers and even all 1GHz customers from Craig got their unit.


You think it's weird that Pandora production works flawlessly?

Sure, that's probably why we had issues with the LCDs for the next batch that was delivered in June.

440 LCDs, where half of them had dust below the touchscreen and a lot of those had calibration issues.

So 400 of those had to go back to be fixed... and that sure took a while, as the manufacturer needed to find out what went wrong.


So in August, we were running out of Pandoras because of that. We had a few older screens left, but you really couldn't call that "mass production" at all.

In September, we got 60 LCDs for testing - they were working fine on a quick test and all assembled into Pandoras and shipped...

Only to find out shortly after that those touchscreens autodestruct when you move the stylus at the edge of the screen.

Well, another two months until that issue is fixed...


And finally, in December, production has resumed and I've got 400 fully working screens!


So Pandoras are now back in stock, production is back to normal. Finally :)



2. Craig and his customers


That really was the saddest part of the whole Pandora story so far.

I can fully understand that Craig had a huge load of stress on his back, and it's sad to see where everything has gone.

But he really caused a mess, with the 1GHz preorders 2012 and also with the amount of remaining customers in 2013.


After I finally got the results of the survey Craig created for all remaining customers, it turned out that there are A LOT more customers left than there should. I still have no idea where that huge number comes from, but i don't even want to think about it.

It's more important to moved forward and help everyone here.


Wow, and it's really really awesome how helpful you all are!


While I can only offer Pandoras at production costs, you, the community, help out with donations as well.


So here is a little statistic:


  • Customers who used the upgrade possibility so far: 92
  • Number of Pandoras funded with the help of donations: 50 (36 have not used that voucher yet, they were probably waiting for the Pandoras to get back in stock)
  • Total numbers of remaining customers from Craig (according to the survey): 445


So we're getting somewhere - let's continue to help everyone. Thanks for all your donations :)



3. Awesome software releases


2013 was a REALLY good year softwarewise.

Not only have huge quantities of new software been released for the Pandora, there also were some high quality releases - from all points of views.


Little but useful programs like MasterControl or the recent SixPair-Controller daemon, unique and useful applications like Streak's WIP PIM Manager, awesome emulator releases and updates (who would've thought we could get a fullspeed AGA Amiga, most-of-the time fullspeed Nintendo DS, and a very playable PSP emulator?) and also a lot of games, from ports for classic games like the Jedi Knight saga, to ports of Indie games and also completely new releases.


There's so much to do on the Pandora it won't get boring... I can barely keep up with playing everything I'd like to!




4. A peek into the Future


The Pandora sure still has a lot of potential. I'm pretty sure we'll still see a lot of new releases and updates.


But still, most of you already know I am working on a successor. More details will be revealed overtime.

I cannot tell when it will be finished - based on the whole Pandora story, you know how long that could take...

But let's hope it will be smoother run :)


In case you're wondering how this will be financed:

Well, you know I got money from investors for the remaining Pandora orders, right? That money will be back when all remaining Pandoras have been sold - and will then be used for the development of the successor.


I can fully fund the full design and production for both the unit and the case up to the final prototyping.

Only the mass production itself will need a lot more money than I have - but there are various possibilities to get that as well.

Maybe Kickstarter, maybe Preorders with part-payment, maybe something completely different.


Well, we'll see, but I'm sure we'll find a way to produce it once the prototype is running... but this could still be far, far away in the future.




5. Some special thanks


Well, finally, I'd like to give some special thanks.

Of course, a huge thanks to all the community and developers, as you keep everything going!


Special thanks goes to notaz - he helps both with low-level stuff and the OS. And he'll also be helping with the Pyra :) Also to skeezix and DJWillis - they might not have much time recently, but they're available when I really need them. And c4a is simply awesome :D


More special thanks go to Fatih. Many might've forgotten about him already, some have never heard of him. He's also one of the guys behind the Pandora - and he's still helping out a lot (e.g., he's the one sourcing stuff like the AC Adaptors or LCDs, and he's also the one who dealt with the chinese manufacturer to fix our LCDs). Yep, he's still helping out, even though most of you don't know this.


Of course, MWeston is not to be forgotten. He's the one who designed the Pandora PCB, and he still helps out each time I have some technical or manufacturing questions. Thanks - and I hope you really have a real awesome christmas time with your family!


Not to forget: Linux-SWAT, fantomid and p'tiSeb for taking care of the Tolouse Game Show and of course Link and ekianjo for distributing Pandoras in US and Japan as well.


There are many many more which I didn't mention by name here... my investors, the moderators, all the devs.


Well - we sure don't have to space here to mention them all. But I'm really happy to have such an awesome community backing me, helping as good as they can.

With guys like you, I KNOW the Pyra will be awesome, and even though it might be a hard way once again, I'm totally sure it'll be worth it!


Thanks - and all of you, have a very merry christmas, and a happy new year!

#321168 Starcraft

Posted by notaz on 04 March 2014 - 08:31 PM

Awaken my child, and embrace the glory that is your birthright. Know that I am the Overmind; the eternal will of the Swarm, and that you have been created to serve me.

It's on the repo.
You'll need full installation of Brood War from PC with latest 1.16.1 patch applied. It also needs to have required files copied from CD (1.16.1 removed CD checks, but doesn't automatically install all required files):
- copy "INSTALL.EXE" from the StarCraft CD to your StarCraft folder and rename it to "StarCraft.mpq
- copy "INSTALL.EXE" from the StarCraft: Brood War CD to your StarCraft folder and rename it to "BroodWar.mpq"

You should try the game on PC without CD first, if that works, you're ready to copy the game's folder to pandora/appdata , the folder should be named "starcraft".

So a Starcraft port? Sort of..

The "no source, no port" rule is not completely true, you can get something similar (but not the same) as a port through static recompilation. Similar stuff was done several times by M-HT for some DOS games. The game was also converted for Android with somewhat similar approach.

So how does it work? The game was fully disassembled with IDA, then converted from x86 disassembly to C with my custom tools that I wrote as the project progressed, then compiled as a normal program and linked against ARM winelib (so the Win32 API is provided by ARM port of wine). Sounds easy? The hell not! I've started it sometime in autumn and was hoping to have something after a month or so, but it was far from working at the time of New Year. Then tried to target the Alive compo, but that slipped too. There were way too many problems and things that I did not expect.. Maybe I'll write about it someday. Would I do it with another game? Maybe not, let's just say "no source, no port" rule is always true and Windows games should be handled through emulation, static recompilation is possible but way too problematic in practice.

However in the end I think it works quite well, give it a try. It should be close to how "real" port would work, there is no emulation anywhere. There is a bit of overhead in 8bpp -> 16bpp conversion, but it's not too bad. The game likes to eat CPU even when it doesn't really need it, so it might make sense to underclock sometimes.

Known bugs in b6:



old bugs:
- custom scenarios are broken
- when playing as terran, attempting to land a building will crash the game
- first protoss mission (from expansion) crashes

Edit: wine is hacked a bit, I've pushed out the changes to github:

#290765 Some more of my ideas

Posted by EvilDragon on 19 November 2013 - 02:53 AM

Well, since you know I'm actively working on the successor yet, I think I can share some of my ideas.


Basically, it's to keep what's good and fix what can be fixed :)


What's good:


Size: Similar. If we have to increase it, it will not be much (maybe 1 - 2 mm to one side)

Clamshell design: Of course!

Full sized SD Card slots: I would like to keep these as well.

USB Ports: Sure thing!

Gaming Controls: Ummm... :)

Replaceable battery: Yep. I want to keep the exact same battery for various reasons.:

  • It will ensure that batteries for the Pandora will be available for a longer period of time.
  • We know it works properly (less risk)
  • Whoever owns the successor AND the Pandora can the batteries for both devices.
  • The battery compartment will be changed though, so that the battery will fit much better


What needs to be fixed:


Nubs: Completely new ones. We already have some samples that are working so much better (best nubs I've ever seen).

LCD-Cable: While the current ones are good, they still fail too often in my opinion. With MIPI displays, we don't need LCD Cables anymore.

Case: The case will be completely designed and produced by one company in Europe. This will ensure a higher quality.



What could be improved:


LCD: Better refresh rate, higher resolution (ideally 720p, but that's hard to get), size increased to 5"

Keyboard: Slightly improved layout, better feel, probably backlight

Wireless: Improved Wifi, but maybe also optional 3G/4G would be neat.

Speakers: We already have samples of much better speakers. :)

SoC: A more recent one, of course. And yes... we have the confirmation for one now, but I won't tell you :)



So, that's my basic idea - what do you think about that? :)

#324835 Silent progress

Posted by EvilDragon on 19 March 2014 - 11:49 PM

It's been quite a while since the last blog post, but of course that doesn't mean nothing has happened here.


A lot of what has happened for me was organizing (looking for companies that are able to produce the keymat, etc.) while Nikolaus was working on the base PCB most of the time.

Here's a quick summary of stuff that happened :)


1. Base PCB design


Nikolaus is now about 95% finished with the design of the base PCB.

All of the parts have already been placed and will be wired up.

If everything works out, then the base PCB does not need another revision - but you never know.

We'll know when it's finished and tested :)


As for the ports on the backside, it seems we can include the following ones:


  • 1x Micro USB 3.0 OTG
  • 1x USB-A 2.0 Host Port
  • 1x USB-A 2.0 Host + eSATA Comboport
  • 1x MicroHDMI Port
  • 1x Headset (an internal switch ensures you can both use Apple and normal headsets)
  • 1x Micro USB Debug and charging port

Plenty of ports. We cannot tell 100% that these will all be included though.

They fit on the PCB, but we need to wait for feedback from the case designers if that works out well.


In case you wonder what the Micro USB Debug port is:

It's basically the serial out port. You can connect it to a PC and it will register as USBtty device.

No more hardware needed - so if you want to do some low-level kernel development, it will certainly be useful.


The port can also be used to charge the unit. This makes it possible to use a USB3.0 device (i.e. harddisk) while the Pyra is connected to the charger.



2. The case


The case designers were mostly working on the keymat, where I should get a first design this week.

This is important, as the keymat is the only part of the case that cannot be produced by FormAction, so I need to get quotations from other companies, and find a suitable one.

And as you can imagine, the keymat needs a lot of testing, as it has the buttons and the DPad included - and those need to be perfect :)

Therefore, the faster we get it, the faster I can test and confirm it.


After they finished the keymat, they will work on the keyboard part of the case and make sure, the PCB fits without any issues. This is also the time to work on the hinge and finalize the keymat design and PCB design.


When that is done, the lid will be designed, and finally, the lower part wit the battery compartment.



3. The touchscreen


The technical design of the touchscreen has been finished and is approved by me, now the production will begin.

We should get samples soon (I don't have a date yet, probably in about 4 - 5 weeks).


I've ordered the highest resolution and sensivity, anti-glare. So we should hopefully get the best resistive touchscreen as possible.




4. New (or old?) help


Some more helpers joined our internal development mailing list.

Two TI employees who are helping us in their spare time (they know a lot more about the OMAP5 than we do, so this will certainly be helpful) and Michael Weston (yep, the one who designed the Pandora) :)

It's always good to have various experienced designers.

There are often multiple solutions for one problem, and different ideas often help to find the best solution.


And proof-reading a schematics before the PCB goes into production is really helpful as well.


I'm really happy and thankful for all the help :)

It helps us to improve the final product and move forward a bit faster.



That's all there is for today. See you soon :)

#318507 News from the embedded world

Posted by EvilDragon on 25 February 2014 - 07:52 PM

As mentioned a few days ago, Nikolaus and me have been visiting the embedded world exhibition in Nuremburg today.


We mainly focussed on different storage solutions (eMMC, nanoSSD, MicroSD Cards), but also discussed various other things and learned quite a few new things.

Here is a small blog post about the results :)



1. What storage is best?


We followed all your discussions, concerns and wished here at the boards and spoke to various manufacturers about pros and cons.


A nice solution would've been nanoSSD together with an internal MicroSD slot, both bootable.

nanoSSD is pretty fast - however, it's also very powerhungry.

While MicroSD Cards / eMMC usually use about 0,3W, the nanoSSD can use up to 0,9W

Therefore, it's not really an option.


Next was to compare the MicroSD with an eMMC.

Power consumption is similar, speed mostly depends on the eMMC/SD Card used, but the latency of a MicroSD Card will always a bit worse than for the eMMC.

The eMMC is directly connected to the MMC line of the SoC, whereas a MicroSD Card always needs to have a converter inbetween.

That converter adds a bit of latency - probably not much, but a bit.


However, I can understand that a MicroSD card is appealing, since you can change it and still use the unit easily in case the eMMC breaks sometime in the future.


Therefore, we thought of a solution here - and I think we found the perfect one.


As mentioned, we're planning to put the CPU together with the memory and storage on a pluggable daughterboard.

This saves money in production (since the mainboard will be two-layer and only the small CPU board needs to be more complex), and it adds the possibility to upgrade the Pyra in the future with whatever SoC / memory / storage will become available in the future.


Additionally, we will try to add the MicroSD/SIM-Card Combo-slot below the battery - and include a small chip that will be able to either connect the eMMC or the MicroSD Slot to the SoC.


If we use the OMAP5, you can then either use the eMMC together with both full sized SD Card slots or the MicroSD Slot with both full sized SD Card slots.

If a future SoC supports more MMC devices, you will be able to use all the devices at the same time.


This should be a solution perfect for everyone. You can either boot from eMMC, the internal MicroSD Card or the Full Sized SD Card slot (like on the Pandora).


And in case your eMMC breaks (never seen that on the Pandora, but you never know), then simply put a MicroSD Card in and switch to that slot.


I hope you're happy with that solution :)



2. UMTS and a hardware switch


Some of you here at the boards had a bit of a concern with the (optional) UMTS module:

A modified firmware or software could be created to misuse the UMTS module and send data somewhere without the user knowing it - so they asked for a hardware switch to completely turn off the module physically.


Well, we thought about that - but adding a switch would increase the costs quite a bit (mold would be more complicated, switch would be needed, etc).

However, we found another, pretty cheap but effective solution:

We plan to include a small power measurement chip into the hardware, that is hardwired to a small LED.

Whenever the UMTS module needs power (which it does when it will be activated), the LED will light up.

This hardwiring cannot be changed in software, so you will KNOW when your UMTS module will be active!



3. Intel and everything else


While you all know that we won't start with an x86 right away, it could be that we'll release a CPU module with one sometime in the future.

And as Intel had a booth there, we thought it doesn't hurt talking to them and get some more information.


Right now, the latest BayTrail does NOT have a development board available, as we already thought.

While it's possible to buy the latest BayTrail without any NDAs and in low numbers, Intel suggests to not buy it directly but get it on a module from one of their partners.

Getting the SoC directly to work is a bit more complicated than an ARM SoC, since it will also need a BIOS...


We checked some of their partners, but their modules usually are way too big for us (and not yet available with the most recent SoC anyways).


So right now, the x86 is too risky for us, but that doesn't mean we won't do an x86 module sometime in the future (though please don't bet on it!)


I also visited Qualcomm and got another contact for getting the Snapdragon. The 805 will be too power hungry for mobile devices though (it's mostly aimed at tablets), so it won't be usable for us.

But I'll keep you informed about any further updates.



That's it from the show - keep on discussing about things.

As you could see with the storage, we'll follow your ideas and try to find the best solution for everyone :)


#324969 Silent progress

Posted by EvilDragon on 20 March 2014 - 03:01 PM


this is amazing! progress seems to fly now. the only thing that worries me is the keyboard layout.

Don't worry I'm sure after 100 polls we will find a scheme that at least a small majority would like.



We'll use latin letters as action buttons, weird symbols on the DPad and greek letters on the keyboard.


Or we just leave it blank and include a waterproof pen for your own layout.

#302322 2014 - a Sneak Peek! (2014-01-02)

Posted by EvilDragon on 02 January 2014 - 11:35 AM

The new year has started - and I hope it did start well for you.


A fresh new year, new plans, new possibilities.

What will happen in Pandora and Pyra-Land?


I can at least give you some information.



1. FOSDEM 2014


Yes, we'll be at the FOSDEM again this year (taking place 1st and 2nd February in Brussels)

We'll have a table and I'll have a small talk in the gaming dev room - Saturday evening, 6 - 7pm.

Of course, we'll have some Pandoras there and I'll also talk about the Pandora in the devroom.

However, we might also have some information or even previews of the Pyra there.

Askarus will be there Saturday and Sunday the full days, while I will be there Saturday 2pm to 7pm and the full Sunday.


You're very welcome to visit us and get more information about the Pandora / Pyra.

I'm also open for any interviews, in case some of you are bloggers or even writing for magazines.




2. Alive and Kicking Coding Competition


Looking at the current list of entries, we'll see some awesome releases for the Pandora!

Thanks a lot to all devs participiating - it shows how lively the Pandora scene is.

A bright future :)




3. Pandoras and Craigs remaining customers


Hopefully, we'll be able to fulfill many more of Craigs remaining orders, but we have no idea how many that'll be.

We're trying to do our best, but Pandora stock is limited now due to some parts needed for Pandora production that have seen the end of life quite a while ago.

However, any customer who still remains after the last Pandora has been sold will be able to get the Pyra for production costs - whenever it might be ready.

I don't want to forget anyone, so I'm trying to offer whatever I can.




4. More partly defective Classic Pandoras


We still got over 100 defective boards from CC and will now focus on finding out if they are still usable in some way.

They will all be at the Pandora-Section at the DragonBox Shop, so be sure to check it out every once in a while to see if there's one that is of interest to you.

They're all units with brand new cases (most of them had some small scratches from the very beginning though) and PCBs which have one or more issues.



5. The DragonBox Pyra

With the Pandora reaching the end of production, when will the Pyra be available?

We have no idea. And looking back at the Pandora developments, I will NOT give any estimations.

But we'll work on it. And you will be able to follow us with videos and pictures I'll post.

We'll probably start with that after the FOSDEM.


Thanks to all of you - quite a few good ideas from the community will find their ways into the Pyra.

And with a capable production company from the very beginning as well as a case company in Europe, things are looking a lot better.


It'll most probably still be a while until it's finished. So in case you're thinking about getting a Pandora or wait for the successor, I'd get a Pandora now - as stock is limited.



So much for a peek into 2014. If you have any further questions, let me know :)

#317533 How to calculate a price for the Pyra

Posted by EvilDragon on 22 February 2014 - 10:24 AM

And here, as promised, is a blog post about how to calculate the sales price - probably also explaining why we can't give any fixed price yet :)
Be warned - it is quite a lenghty post!


I hope you enjoy reading it though, it's full of information you probably didn't think about :)


Basically, the price of a device being sold is being calculated using many different factors:

  • Development Costs (one-time costs)
  • Production Costs (costs per unit)
  • After-Sales Costs (Support, Repairs, etc.) (monthly varying costs)
  • Monthly company costs (fixed costs per month)
  • Marketing Costs (monthly varying costs)
  • Some money put aside for bad things that can happen (i.e. the touchscreen issue we had with the Pandora)
  • Profit and Distribution (varying costs)

Let's take a look at all of these, shall we?
1. Development Costs
The development costs are one-time costs.
It means: Once development is over, they won't change anymore, so they will be a fixed value in the final unit price.
Development costs include everything you need to do to create the unit up until the part the mass production is going to start:

  • Wages for the designers
  • Costs for prototype parts and production
  • Costs for samples, evaluation parts, etc.
  • Costs for doing different tests (CE certification, reliability testing of various parts)
  • Costs for parts needed for mass production (case molds, stencils for PCBs, machine programs, etc.)


Wages for the designers should be clear - someone needs to create the device and he / she needs something to live from as well ;)
Of course, using a company for the design (i.e. for the case design) will increase the costs, as the company needs to cover their costs and wants to make profit as well, but in exchange you have additional safety. In our case: The case design company is also the company producing the actual molds. The designer knows their machine quite well, and if something doesn't work, it's THEIR job to fix it.
This was different with the Pandora - the case had issues (as you know), and the company blamed the designer for that whereas the designer blamed the company. I am in no position to tell who was right (I'm no expert here), but this is something that needs to be prevented - as in the end, it cost more time and money.
Next are the costs for prototype parts and production.
You don't just create and design a product and then mass produce it.

There are many many tiny little steps until the final product is ready.

With such complex technology, it's nigh impossible to have a design fully working on bug free on first try.

The Pandora had 5 revisions before it went into mass production.


We already had 3 revisions for our dummy PCBs as well.

It is possible to save costs here, as we did it with the Pyra: 2-layer PCBs only partly populated are less expensive than creating a full working 8-layer PCB with the SoC, etc. each time.


Then we have the costs for samples, evaluation parts, etc.

As you probably know from all the discussions on these boards and due to my previous blog costs, there are multiple solutions for everything. Be it SoC, Storage, etc.

To find out the best possible solution, you can't just read the datasheets (though it's a good start). It's better to make your own testings.

If we want to find out which SoC is best, we'd need to buy devboards for all of those. These cost money.

Doing all the tests also needs time - and cost wages for the designer as well.


This was just an example for the SoC. There's a lot more - touchscreen, LCD Cable, etc.

These all need to be produced and extensively tested - and if they don't work as planned, you might need to find another company or solution and start from zero again.


These costs all add up - and need to be covered with the sales later.


For the Pyra, I expect development costs of about 50,000 EUR - but it's impossible to tell until everything is finished and working.

It might be less, it might be more. But I think we won't hit more than 50,000 EUR, I'm always pretty careful with that.



Next are the costs for doing different tests (CE certification, reliability testing of various parts)


To be able to even sell the units to the public, we need to be sure they follow all the given guidelines.

Which means: The prototype will need to pass tests like CE, FCC, etc.

These tests cost money as well - and if they fail, you need to change the prototype until it passes.

These are one-time-costs like the development costs.



Additionally, we need to expect to sacrifice things as well.

The OMAP5 devboard has a heatsink, and we also need to create one for the Pyra as well.

However, what happens if the OMAP5 doesn't have a heatsink? Does the SoC die when it gets to hot, or does it simply get very very hot and crash?

The only way to be sure is to try that - so it might be we have to sacrifice a devboard for that.


I expect about 10,000 EUR for the Pyra here - so certainly less than the development costs.


There is something else before the Pyra will finally be ready for mass production:

Costs for parts needed for mass production (case molds, stencils for PCBs, machine programs, etc.)


Once everything has been confirmed to be working, mass production needs to be prepared.

Molds will be created (or finalized), the mass production machine needs to be programmed, stencil layers need to be produced, etc.


My expected costs for the Pyra here would be 100,000 EUR.


These are all the fixed one-time costs you have before you can start mass production.


Now, the expected sales are VERY important for that.

Whether we sell 10, 1000, 10,000 or 100,000 units - these costs won't change.


If we sell 10, it would break down to 15,000 EUR per unit. With 1000, it would be 150 EUR per unit. 10,000 would go down to 15 EUR per unit, 100,000 would be 1.50 EUR per unit. And so on.


This is one of the reasons why low-quantity devices are always more expensive than devices that sell in millions.


It's also the reason why we can't try as many different approaches and solutions as a huge smartphone company.

With low production quantities like about 10,000, it makes a huge difference whether the production costs are 150,000 EUR or 500,000 EUR (from 15 EUR to 50 EUR per unit)

With quantities like you have for smartphones, it doesn't really change the price at all (from 0.15 EUR to 0.50 EUR per unit).



2. Production Costs (costs per unit)


Next up are the production costs.

Unlike the development costs, this is no fixed value, of course. Producing 100,000 units costs more than 10,000 units ;)


The production costs itself consists of different factors.


  • Parts
  • Production time
  • Assembly, testing and packaging
  • Failure Rate

Parts costs probably are pretty clear: All the parts that are needed to produce a unit are in there.

That's the case, the PCB, the SoC, the keymat, the LCD Cables, the Battery, the packaging, all those tiny little components that are on the PCB, etc.

For the Pandora, these costs are about 200 EUR each.

I expect slightly higher costs, as the SoC, memory and LCD will cost more. However, nubs are a lot cheaper (since we won't need two ATMELs for the firmware) and we also try to create a 2-layer base PCB and a small 8-layer CPU module PCB (which should also lower the costs).

So we should expect something like 250 EUR for the Pyra.


Production Time Costs is the time the machine (and the people doing the manual soldering for some comonents) needs to populate each PCB.

The machine at Global Components can populate 400 parts per minute - so the fewer parts we've got, the cheaper it will get.

With the Pyra, by making use of two PCBs (module and simple main PCB), where we place the complex parts (BGAs) on the way smaller CPU module, the overall production time costs should be a bit cheaper than for the Pandora.


The Pandora was 40 EUR per unit, so I expect the Pyra to be around 25 - 30 EUR.


Assembly, testing and packaging

Each unit needs to be fully assembled, tested and packaged up, so it's ready to be shipped to the customer.

With the Pandora, this is pretty complex. We're trying to improve that for the Pyra as well (mainly case design changes).

Also, as the Pyra has a faster SoC, the self-tests should run faster.


The Pandora cost for this was 10 EUR per unit, I expect 7 - 9 EUR for the Pyra. 


Failure Rate


If you calculated everything up to now, you should have about 300 EUR production costs per unit.

So 1000 Pyras would cost 300,000 EUR. However, there's always a failure rate.

Global Components guarantees a failure rate of less than 5%. Anything higher is covered by them.

The real failure rate usually is lower though (with the Pandora, about 2 - 3%).


These are PCBs that could not be made to work, so they can be thrown away.

So 50 out of 1000 Pyra PCBs could be broken from the very beginning.

The parts can't be reused (well, except for LCD, Case, etc. of course), and they also cost production time.

That's would be about 180 EUR per unit. With 50 units, it would add up to 9000 EUR.


So in reality, when calculating costs to produce 1000 Pyras, you need to calculate with 309,000 EUR (or 309 EUR per unit).



3. After-Sales Costs (Support, Repairs, etc.) (monthly varying costs)


So, unit shipped, customer happy, no more costs?

That would be great - but unfortunately, things can always break.

Warranty repairs cost time and money (wages, shipping and part costs).

Thanks to our experience with the Pandora (and to the fact that my shop is making additional money with other things), these won't be a huge issue for us.

But you need to expect them - so I'll calculate with 4 - 5 EUR per unit.

Of course - later in the production, the after-sales cost will go down, as the production process will constantly be improved.



4. Monthly company costs (fixed costs per month)


A company has monthly costs as well.

Wages, room rent, tax counsellor, etc.


For my shop, this is about 4000 EUR per month.

Luckily though, these costs are mostly covered by all the sales in my shop already, so it's not a huge concern for us.


But what if sales go down and I mostly only sell the Pyra anymore?

Now, as these are costs are monthly costs, they heavily depend on sales.


If I sell 100 units per month, I would need to add 40 EUR per unit just to keep the shop going.

If I sell 1000 units per month, it would only be 4 EUR.


The reality is probably somewhere inbetween.


There's another concern though:

The more units I sell, the more people and space I need to hire to be able to ship them and have enough space for the stock.

That's why I want to grow slowly - what would happen if I have 10,000 sales per month, and after 6 months it suddenly goes down a lot...?

I still had to pay the rent and wages - and then would probably run out of money at some time.


Right now, I'm calculating with about 10 EUR per unit.



5. Marketing Costs (monthly varying costs)


If sales go down, more marketing is needed.

Thankfully, this is not really an issue for us - most of the marketing happens due to retro-gaming magazines, reviews and the community itself.

So it's only about 300 EUR per month at a maximum - something we can easily cover :)



6. Some money put aside for bad things that can happen (i.e. the touchscreen issue we had with the Pandora)


Even though the production is running, something bad can always happen.

Like the recent issue with the touchscreen in a full LCD batch, which did cost us thousands of EUR just for shipping.


That's why you always need to put a bit aside - to be able to cover that.

For the Pandora, that was 10 EUR.


I don't expect that much for the Pyra though. I've taken care that all our companies are sitting in Europe, mostly in Germany.

So if the touchscreen issue would happen, I'd simply return it to our German distributor and let him deal with the rest.


So I'm planning with 4 EUR per Pyra.



7. Profit and distribution (varying costs)


Last is profit and distribution.

If you calculated everything together, we should have a rough price of 350 EUR per unit (expecting a total sale of 10,000 units)


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%.

Or, if it's a company that also sells games and apps, they often don't make profit on the hardware, as they plan to make profit with the games.

This is not the case for the Pyra though.


So that would increase the price to 402,50 EUR


Then there are also distributors (like ThinkGeek, Ithic.com, GetDigital.de, etc.)

They also want at least 15 - 20% profit (they've got huge shipping costs from Germany to US as well) - which leads to a price of about 500 EUR.

Of course, they won't be happy if I sell it for a lower price as they do - so I would need to calculate with that price as well.


In our scenario, we'd have a final price of about 499 EUR.


However, as we don't know the final development costs, production costs, etc. right now, this is just an estimation.

But thanks to my experience with the Pandora, we should roughly get that. It shouldn't be a lot higher though.


Wow... this was a long post.

I hope you enjoyed reading it and learned something new :)


Calculating costs certainly is no easy task.

There are a lot of different ways optimizing the production itself, to save costs. You just need to find the best way (which sounds simpler than it is).

Also, estimating sales is not easy. Having more sales will lower the production costs a bit, but if your price is low and the sales aren't too good, you make a loss as well.


But having done that for the Pandora (and my shop in general as well) surely will help us a lot.

#309847 Welcome new and old members!

Posted by EvilDragon on 01 February 2014 - 11:23 AM

Today will be a most interesting day!


I'm currently sitting in the train on my way to the FOSDEM, while Askarus, Fantomid and some other Pandora community members are already there and presenting the Pandora to everyone who is interested.


I've got a Pyra Dev-System in my bag which will be setup at about 2pm (in case the train isn't late) at the FOSDEM - that's when the real fun begins.


Everyone who is at the FOSDEM today and tomorrow is welcomed to try out a first version live and see what we can expect from the future.


This evening will also be the time to finally open the development blog of the Pyra, along with a small development website.

The same time I'll have my talk at the FOSDEM - which will reveal everything I have planned so far for the Pyra.


Let's hope we'll see a lot of old and new members here who will support us all the way to the finished product :D


I'll try to fully record the talk and put it online tonight or tomorrow - so if nothing goes wrong, you will also be able to get all the information you need.


See you later!


EDIT: Oh, and I almost forgot:

We've got Carry Cases, TV Out Cables, Pandoras, 1GHz Upgrade boards and other stuff ready to be sold for a discounted FOSDEM price :)

#322615 Prepare for the next level

Posted by EvilDragon on 10 March 2014 - 12:33 AM

The display is now working, so what's happening now?

Quite a few things at once!

Let's start with...

1. The PCB

Nikolaus will work on the next incarnation of the main PCB now.

Together with the case designers, he will juggle around the parts a bit and make sure they technically fit on the PCB whereas the case designers will make sure the case won't have any issues when the parts are where we place them.


The next main PCB will be as close to the final release as possible.

It will have the audio, battery and charger circuit included as well as all parts like a Wifi module, 3G module, all connectors, SIM and SD Card slot (and a lot more), and the connectors for a CPU PCB included as well.


Also, a CPU PCB dummy will be created, so we can do measurements (size) and other testings as well.

Most likely, the dummy PCB will be connected to the devboard, so that the main PCB can be tested properly.



2. The case


Besides checking that the case will fit around the PCB, the case designers will first concentrate on designing the keymat.


Why? Well, simple:

A good keymat needs to be tested very thoroughly.

Besides the keyboard, it's also the important part of how the DPad feels - and we want that to be perfect as well!


Once the keymat has been designed, the case designers will continue with the case while various prototypes with different material strength and thicknesses will be produced, so we can test them and decide which is the best one.

We will also be able to test the placement of the backlight LEDs with it.


One high-priority topic for the case designer will be the hinge.

They will first check if we can use the existing hinge part and improve it with a different case design (so that it works more like a laptop and stays open whereever you want it to).


But we'll also contact a company which is specialized on hinges for laptops and small mobiles - maybe they can provide us with a better one.

Thanks to MWeston (yep, you read right :)) for the link to that company.



3. Testing, testing, testing


I will mostly concentrate on testing our new display, will try if rotation of the full framebuffer works fine via hardware using the OMAP5 DSS commands.

I'll also try to test various resolutions (if possible), dpi settings, refresh time, etc.


Of course, I'll make some videos for you here :)



4. The OS


We'll also start working on setting up the basic OS as soon as possible.

DJWillis has already looked a bit into setting up a Debian build server.


Before customizing anything, we'll start with the basic stuff:

1. Set up a build server for Debian

2. Make sure it grabs and compiles packages from Debian automatically

3. Adapt the compiler settings (so the packages are optimized for the Pyra)


When that is working, we can start creating and adding our own packages - and this is where everyone (well, mostly developers ;)) can help us.

There's a lot of work to do - improve the PND system, create configuration dialogues for the Pyra-specific hardware, etc.


Of course, we'll put everything into a git :)



As usual, I'll keep you informed about anything that's going on :)

#321943 The long journey towards a working display

Posted by EvilDragon on 07 March 2014 - 03:09 AM

Well, as you know from yesterday's post, we got the display to work.

However, as promised, we want to be as open and in-depth as possible, so here's an explanation of what we did during the last weeks (well, mostly Nikolaus...)


You will also see some more pictures attached to the post.

Enjoy :)


The following text is directly from Nikolaus (gta04)

5 weeks of treasury hunt have finally lead to a successful "game over". The MIPI interface does no longer woe.

Firstly we did have some hardware bugs (e.g. swapped wires - due to a misprint in a data sheet).
After fixing this we quickly did have a first success: we were able to send some commands and read values back from the display.
But the display stayed dark when sending the initialization sequence.

For some lengthy time we did suspect the OMAP5 and/or Linux drivers and tried to understand/modify/fix/improve it.
But the display stayed dark.

And measuring experiments with an oscilloscope did not show obvious deviations from what we could expect. We were even tempted to rent a better oscilloscope or a commercial MIPI-DSI tester.

Well, it became obvious that our treasure map (data sheet) for the panel was an incomplete excerpt of the data sheet of the controller (it did not have the full command list of the panel). After knocking on many doors, I received a copy of the original treasure map on Tuesday morning :)

It did list all commands and gave a better understanding of everything. But some commands still did not work. I was not even able to read out the chip id code...

Then, I did measure directly on the panel to verify the voltages to exclude another hardware bug.
The result was interesting: the voltages were in coincidence with the default settings according to the data sheet.
But they were not matching the values that should have been set by sending the initialization sequence to the panel.
So it became clear that for some reason the panel did ignore some (not all) of the commands sent to the panel.

After browsing again and again I suddenly found a small footnote on page 244...

We simply have to send the manufacturer specific commands in a slightly different way (it is roughly comparable to use either TCP vs. UDP).

With this knowledge it was also possible to decrypt one table in the panel data sheet... But that is common for such games - afterwards you know which redundant deviations you have taken...

After fixing our kernel driver it worked almost immediately to read back the correct chip id code. Then, it was only a small final step to enable and see a test pattern.

And even the OMAP5 DSS subsystem was initialized correctly, so there was the Linux Tux and some xterm.

If I look at the photos I must say that I am really impressed. Seeing a full web page in a readable manner is amazing.

So let's take the next challenging treasure hunt :)


Attached Thumbnails

  • DSC01900.jpeg
  • DSC01899.jpeg
  • DSC01898.jpeg
  • DSC01897.jpeg
  • DSC01896.jpeg
  • DSC01895.jpeg

#295534 Openpandora Ltd (UK) Struck off email

Posted by EvilDragon on 05 December 2013 - 01:17 PM

I don't think anyone blames Craig for the bad things that happened because he didn't know better.

I'm pretty sure a lot of people would be a lot more supportive to him if he always told honestly what's happening and proved he is trying to support his customers as good as they supported him back when the preorders started.

Heck, I'm even sure in that case many of his customers would say "Too bad I lost that money - but before Craig gets anymore trouble, I'd rather forget about it".

The problem is that no one knows what happened with all that money, he has not been supportive to his customers at all and told lies over and over again.
THAT is why people are angry now.

He started an awesome thing - the Pandora. But sadly, on the way down with all the issues he had, he somehow lost the idea that it's a community device.
The whole community here is very supportive - you couldn't wish for more. Everyone understood the issues, tried to help us finish it and now even donates that the remaining customers get their unit.

If he hadn't lost the spirit, most of his customers wouldn't have lost the faith and would still be supporting him as good as they could.
But he decided to turn his back on the customers and not tell them what happened during the last three years... sad, but his decision.

#290763 OpenPandora is NOT dead!

Posted by EvilDragon on 19 November 2013 - 02:33 AM

Just thought I'd make a quick news post here in the official news section, as Craigs downfall of OpenPandora Ltd. is currently going through the news and to his remaining customers.

One important thing upfront:


OpenPandora Ltd. in UK is NOT OpenPandora GmbH in Germany


I am the owner of OpenPandora GmbH in Germany, and that company does not have ANY money issues or similar. All of my preorder customers have received their units quite a while ago and production is still running strong (though we're currently out of units until the next batch in December arrives).

And yes, a successor of the Pandora is being planned. And no, I cannot tell you when it will be ready (probably 2 months™ ;))



What does that mean for still waiting customer of OpenPandora Ltd.?


Not much. OP Ltd. has been unable to pay refunds for quite a while now.

The reason we created the survey was that OpenPandora GmbH and the community can help Craigs remaining preorders, regardless what happens with OpenPandora Ltd.

You will still be able to get the Pandora for a discounted price or with the help of the community donations.


BTW: My shop is now also accepting Bitcoins, and as they have risen significantly in value lately, it's a good way to get your upgrade in case you had bitcoins lying around for a while now.


As long as there are Pandoras available, everyone of Craigs remaining customer can get them for production cost or lower (with community donations).



Well... that does lead us to another question:

When will the Pandora REALLY be dead?


We've only got a limited amount of parts, and some are already end of life so we can't buy anymore.

The production of the final Pandora batch has been started. There will be 500 more 1GHz and 150 more Rebirth units.

Well... and that's that. There will be a few more classics, but after that, production will most probably stop (unless we get a huge demand so it makes sense to change the PCB design to replace a few end-of-life parts...)



When all Pandoras have been sold - what happens to the remaining preorders?


No worries, the money will STILL not be lost.

Hopefully, most of the remaining Pandoras will go to Craigs remaining customers, but you never know.

In case there still are some left, then I'll move that discount over to the successor... even though I cannot tell you when it will be released.

#288995 They're throwing in the towel.

Posted by EvilDragon on 13 November 2013 - 02:14 PM

I will NOT do any Kickstarter / preorder payments, etc. with a Pandora successor before I've got a complete working prototype (both PCB and case) in my hands and all orders setup, so that I simply need to tell "Go!" to make it happen. So much I can tell you.

#238874 Final preorders, action required

Posted by KickAss on 10 April 2013 - 04:43 PM

ive got to admit, i totally lost track of how the preorder madness went on as soon as i received my unit.

ive had it for a while now and just recently came back to this forum.


reminiscing when the first customers got their units, all the unforseen in between, the unbroken constant struggle to please each and every customer til this very day ...


this community right here so very special for exactly two reasons:

1. the people who still believe in it. you made all of this possible in the first place. some of you are still waiting for their units. keep your hopes up, you will receive and love them in the end. you guys are awesome!


2. the bunch of ppl who still keep struggling with production, sales, delivery, soft- and firmware updates etc. even tho at times the pandora was facing a rather grim future, you kept dealing with it and turned it all to the better. i can not imagine what a hell of a job that might be. you guys are awesome!


ive never seen anything like this anywhere else and i do believe its important to mention that.

thanks :)

#330742 Quick video of the case

Posted by EvilDragon on 17 April 2014 - 05:19 PM

Well, as the first 3D Print of the case has arrived, I made a quick video to show it to you guys :)

A few notes about that:
  • It's a VERY first version of the case, mainly for checking that it fits with the major components as well to be able to test the exact space available for the CPU PCB.
  • Missing features include the logo, the shoulderbuttons, the rounded edges, an improved hinge, proper speaker inclusion, etc.
It already shows how it will be assembled and some advantages we'll have here.
Enjoy :)

#310720 SoC: Back and forth!

Posted by EvilDragon on 03 February 2014 - 11:08 PM

Wow, FOSDEM really was impressive this time.
There were so many people interested in the Pandora and Pyra, it's amazing.
And even though the time for my talk was a bit too short, I think I made myself mostly clear about what I want.
Well, and if not, then you can always ask here at the boards - and the blog entries will probably clear up some more mysteries as well :)
Productive discussions about the OS have started on the boards as well and I will take care about new forum sections for that tomorrow.
Thanks a lot to anyone who wants to help out here :D
One question I've seen quite a few times was "Why use the OMAP5? It has a PowerVR chip, which doesn't have OpenSource drivers!"
As mentioned, you should take part of the Pyra development and production process - and of course, also of the things that already happened in the past.
Especially, since that basically answers the above question as well - so follow me on a journey...
From OMAP5 to everything else and back
Back in 2011/2012, when the OMAP5 had just been announced, we decided to use it for the successor. It was, once again, faster than anything else.
But it seemed like TI would never even release the OMAP5...
Early 2013, TI still couldn't give any clear dates - and now Samsung, NVidia, MediaTek, etc. were all catching up.
It was clear for me that I WILL work on a successor - and it was pretty clear that the most complicated things to source would be the SoC and the LCD.
So I started as early as I could and contacted various other companies.
Samsung was the first company I contacted, since the German Headquarters are in Munich, just 45 minutes away from me.
The german team did pay me a visit and they really liked the Pandora and the idea to use a Samsung SoC for the successor.
They did their best to convice the Korean HQ, but without success. Samsung did not want to sell us their SoC.
So I continued to search for companies.
I contacted the Freescale distriubtor, as their Cortex-A9 SoCs can be bought without any registration and in small quantities - but unfortunately, they decided to not produce a Cortex A15.
Next stop: MediaTek. Asian company, so probably easier to get than from the huge global players.
However, MediaTek only offer Android drivers, and they do not plan to support Linux - well, not for our small quantities anyways.
So they decided to not sell them to us as well.
I knew from some developers that Rokchips English design manuals were never really usable - so even if we could get the chip, we couldn't make the hardware design without a good manual.
I tried to call nvidia a few times, but the German Headquarters never really picked up the phone.
Thanks to some contacts I had, I finally got the right persons from nvidia worldwide headquarters on the phone - however, only to get another "no".
They explained to me that in order to be able to use the Tegra, I need to let the hardware be designed and produced by a contracted partner company from them.
That's certainly not what we want - and my guess is that no company would do such a complex design as we need for such a low quantity anyways.
Things didn't look good here. There were still a few more companies who licensed ARMs big.LITTLE architecture, so I contacted them one after another.
Most of them were in industrial / automotive business, and they planned to have their SoC ready in 2016... a bit too late for us.
Then TIs distributor contacted us - apparently, the OMAP5 was finished and will go into mass production in November 2013.
We can still get it if we want.
Well, we talked about the various options.
PowerVR doesn't have the sourcecode released - but then again, all other GPU drivers in SoCs are closed source as well.
I know a few will now shout "But for MALI there's an OpenSource driver available!" - well, yes and no.
Yes, there's a driver available - but it's for the old MALI GPU. Not a single Cortex-A15 SoC uses the old one.
And it's unknown when and whether there will be an OpenSource driver for the new Mali as well.
TI offers Linux drivers. for their SoC and for the PowerVR.
One thing that's good about the PowerVR is that the kernel part of the driver is not closed source - which means:
While you need a binary blob for the 3D driver, it can still be used on any compiled kernel or OS.
So when PowerVR stops development for the SGX driver, it doesn't mean we cannot update the kernel or OS.
We can. Only the 3D driver will not be updated anymore.
While a fully OpenSource driver would be nice, there just isn't one out there on an ARM SoC.
We can't fix bugs in the 3D driver, but we won't be stuck with an outdated kernel ever either.
You can see that on the current Pandora:
There's a small application available which lets you change the 3D driver version on-the-fly in the running OS.
Each version has different bugs, advantages and disadvantages - but they can be run, regardless of the kernel version.
We had a long journey, and I talked to various SoC manufacturers - and TI turned out to be the only feasable for us.
I'm pretty sure even though it has its flaws, it will be a neat chip for our next handheld.
The horsepower I've seen so far is impressive!
Oh, and about "Why not using an Intel?"
Well... to be honest: I rather be safe and sure than risky and sorry.
When we decided what SoC to use, no one knew if the mobile market will ever switch over to Intel.
There are many Android games out there that probably wouldn't work anymore - and we would also lose all the optimized ARM emulators out there like PPSSPP or PCSXReARMed.
Yeah, I know, it exists for x86 as well - but it's probably not as optimized and therefore drains more battery...
It was too risky for a small company like ourselves - so it's best to stick to ARM right now.
Well, that's it for todays post.
I'll probably post more stuff next weekend.
See you at the boards :)

#209723 Merry christmas and a happy new year (2012-12-25)

Posted by EvilDragon on 25 December 2012 - 11:05 AM

I won't write much here, as I said it all in a video :)



Feel free to ask more questions in case you have any.


And now... let's go into a Pandora-rich 2013 :)

#327246 The Pyrabook

Posted by EvilDragon on 01 April 2014 - 06:06 AM

Wow, that was fast - a few days ago I was talking about Facebook buying the Oculus, and now a few days later Facebook offers to buy OpenPandora GmbH and help out with the Pyra (of course, we're not as expensive as Oculus...).

Apparently, Mark heard from Palmer about the Pyra.
I've spoken with Mark and it totally makes sense to me.
When using the Oculus, you can't use your mobile phone to chat on the planned Facebook-VR - as you can't blindtype on a virtual keyboard.
The Pyra would be perfect for mobile Facebook-VR, as you can learn to type blind on its hardware keyboard.
Special markings you can feel with your fingers will make that more easy.

It's a perfect addition to the virtual Facebook world. It enables the user to type comments and timeline entries as he is used to it.
But it's also awesome for gaming: Imagine virtual Farmville when you can meet others and actually chat with them.
And it will enrich your virtual life as well!
Imagine taking your Avatar to a virtual barber shop to get a new hair cut.

If you're the barber, you can use the nubs and the controls to cut the hair while doing the usual smalltalk with the keyboard.

If you're the customer, you can use the nubs to move your hands and grab a coffee or read a magazine, while the keyboard can be used for smalltalk as well.

The possibilities would be endless - the Pyra would be a perfect companion to the Oculus and Facebook VR.
The fact that the Pyra actually opens like a BOOK is a neat addition as well.

Of course, it means the unit would be Facebook Blue and would probably be renamed to Facebook Pyra, but that's what you probably would've expected anyways.

The deal is not yet set, as I wanted to get opinions from the community first.
It would give us a lot of capital, so I could drink even more coffee than I alread do :D

Let me know your ideas :)

#321608 Let there be light!

Posted by EvilDragon on 06 March 2014 - 12:34 AM

This will just be a pretty quick blog post without much explanation or anything else (more will follow soon :))


Finally, we received the missing datasheet for the driver IC as well as some other needed documentation, and shortly after, Nikolaus managed to do the following:




Now, before you are getting excited:

This is NOT a picture from the Pyra devboard.

It is a built-in test pattern from the driver IC.


However, it means that the LCD is now properly initialized - now we're talking ;)


Shortly after however, Nikolaus managed to do this:




This doesn't look spectacular, I know. It looks like a white box on a black screen.

However, it isn't.


It's actually an X server with a white xterm window.

If you look careful, you can see a tiny symbol in the top-left corner of the LCD - that's the shell waiting for input.

It's very very small (well, FullHD on 5"...) and the camera is a bit overexposed.


But yes, that does mean: We've got the LCD running on the devboard.


Now you can get excited.


I don't have the hardware PCB at home right now to connect the display myself yet, so I can't do any more pictures.

However, as soon as I get an updated version from Nikolaus, I'll do pictures and videos.


Now it's fullspeed ahead mixing the components further together :)

Attached Thumbnails

  • DSC01894.jpeg
  • DSC01893.jpeg

  • Privacy Policy