Just in case you wondered why you haven't heard many updates from
Nikolaus lately: He was busy. Busy creating the schematics... that's a
LOT of work.
But now he's almost finished with it! About 98% are done.
The only thing left is the power circuit for the OMAP5 (about 50
condensators) and some other small things.
So in theory, the Pyra is almost finished... the next step is layouting
the full schematics. This will be quite a bit of work - but after that,
we're ready for a real Pyra prototype PCB!
While working on the schematics, he was also working on the latest
kernel (3.18 RC1) and almost the full hardware of the OMAP5 EVM works
now as well.
Quite a bit of progress, I'd say :)
In the meantime, aTc, Vagrant and me have been working setting up the
package build system for the OS on my server. We now got a neat script
that grabs our own packages from the GIT, builds Debian packages from
it and sorts it into the repo.
The next step will be building our own rootfs with a preinstalled
package list on our server. aTc has already done that - but I need to
do that on my own server as well. Shouldn't be too hard now, though, as
he already figured everything out.
That will be quite a bit of progress as well - as then we can start to
shape the default PyraOS setup.
Now, I wish to say hello to all our newcomers who arrived here after my
talk at the Hackover2014 in Hannover on Saturday. It was fun, and I was
happy to see so many interested people there.
I hope you enjoy your stay here, join our community and have fun as
well :)
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17232-schematics-and-packages/
Follow me on twitter for short news inbetween:
https://twitter.com/EvilDragon1717
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
I just finished the first audio tests today, comparing the audio output
of a semi-professional USB Interface (FocusRite Scarlett), a Pandora
and the TWL6040 on the PandaBoard (which is the same we plan to use for
the Pyra).
The test I wanted to do today was testing the audio output of the DAC,
not the quality of the amplifier (which will be tested with a different
test).
I'vee created an Audio file (48kHz, Uncompressed, 32bit, Mono) has been
played back with a PC (FocusRite), a Pandora and a PandaBoard (also
uses the TWL6040).
Each device was then being recorded (with another FocusRite Scarlett)
and analyzed with Adobe Soundbooth (just a quick analysis).
The result was quite surprising:
I expected the TWL6040 to be the worst one, but actually, the TWL6040
DAC seems to be a bit better than Pandoras one - except when it comes
to noise: Then the Pandora wins of all devices.
I guess the bad audio quality with these days devices is the amplifier,
not the DAC. But that will be tested as well. Well, and it seems DACs
have become better within the last few years.
You can download the full report with graphics from here:
http://evildragon.openpandora.org/AudioTest.pdf
And here (http://evildragon.openpandora.org/AudioTest.zip) is a set
including the following: 1. Original WAV-File (that was played back)
2. Each recording from every device (compare the playback quality
yourself) 3. Three small WAVs where the audio device is switched while
audio is playing (see AudioTest-Report for more information).
Questions? Requests?
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17161-first-round-of-audio-tests-done/
Follow me on twitter for short news inbetween:
https://twitter.com/EvilDragon1717
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Well, this is not really a "progress" report, but I think it is a fine
example how useful a small computer like the Pandora or Pyra can be.
Nikolaus is too busy with finishing the hardware design, so he doesn't
have time to try to get the Solomon (SSD) Rotator chip to work. notaz
offered help out a bit when he finds the time - but doesn't have the
hardware.
So we created this little setup (you can view the picture at the
webboards post, see below)
In the back you can see the OMAP5 EVM, which
has the BOE LCD connected to the Display PCB (incl. the SSD Chip). You
can see the LCD in the middle of the picture.
In the front you can see a Pandora with a small webcam mounted.
The Pandora is connected via USB2Serial cable to the debug port of the
EVM. It's possible to hard-reset the EVM there as well as get the
direct serial output (which is useful for debugging).
The Webcam is setup to show the BOE display on the Pandora.
Both the EVM and the Pandora are connected to the internet as well.
notaz can login to either one via SSH and poke around.
Additionally, the Pandora acts as a VNC server, so he can also connect
to Pandoras desktop and see the webcam live video stream.
Here's a summary:
He can connect to both the EVM and Pandora, see the serial debug of the
EVM and reboot it and poke around with the display. With the webcam he
can see whether the display shows something on the screen or not.
Well, and all that with pretty low power usage :)
Once again, it shows how flexible something like the Pandora is - and
the Pyra will be even more flexible.
But please don't expect results within a few days. notaz doesn't have
much time, and we probably also need to send more questions to Solomon
to get it to work. Things like these won't happen over night, but
hopefully, we can show a working display with rotator soon!
I've attached the picture as MPO file as well - that's a 3D picture. If
you got a 3D-Viewer, you can see the setup in full 3D :)
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17143-an-interesting-setup-involving-a-…
Follow me on twitter for short but faster news:
https://twitter.com/EvilDragon1717
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Today is the start of multiple blog posts again - that worked fine last
time, so I'll continue doing this. Let's start with the Nubs today.
You probably read it via Twitter already:
The nubs we wanted to use for the Pyra have reached their EOL (End of
Life) - they will not be produced anymore. Orders until end of the year
will still be produced and fulfilled, but that's it.
Just as a quick reminder:
The nub we've chosen consists of two parts: The mechanical cage (which
is basically a magnet you move around with springs for autocentering)
and a hall sensor (on the other side of the PCB) which reads out the
movements and converts them to coordinates.
Not the full system will be EOL - only the mechanical part. The hall
sensor is still available. There will be a (smaller) replacement, but
that one will have 1mm less travel distance (so only 1mm instead of
2mm), which is probably too little for gaming.
So, what will happen now?
Will that cause a major issue?
Probably not.
Basically, our choices are...
1.:
Keep the hall sensor and try to create our own slider mechanism with
a magnet.
2.:
Order more than enough nubs needed until the end of the year
and find a company which can produce compatible replacement nubs (maybe
even the same one that produced the current ones for AMS)
3.: Switch to different nubs
4.:
Use the replacement ones with less travel distance
Well, what's our decision?
We didn't decide yet - but here are some thoughts I'm currently having:
Solution 1 would be nice to have - but it would need to be reliable,
not wear out easily. Sure, we only need to take care of the mechanical
part, no electronics involved, but I'm still not too fond of that.
Solution 2 is basically Solution 1 with a bit of safety. And instead of
designing our own one, it would be a clone of what we currently have.
Could be a solution, but I'm not sure... well, if we can get the
original manufacturer to produce the nubs for us on demand, then it
would work.
Solution 3 is currently my favorized solution.
We still got multiple nub samples for testing (the ones that Fatih
sourced for us last year). My favorite one is the one that the 3ds
uses. That's the one we're testing now. The travel distance is even a
bit more, but it doesn't have a stick click. We KNOW it's reliable and
well-tested though. It's approximately the same size, so no huge
redesign needed.
What I never liked with the 3ds nubs was the disc: My finger often
slips off. But the nub is WITHOUT the disc - so we'll still use our own
one :) Sounds like a pretty good solution.
Solution 4 doesn't really sound like a good idea to me.
Nothing is set in stone yet, but as you probably found out, I think
Solution 3 seems to be the best one for us. Well, unless we can get the
manufacturer of the current ones to produce them for us on demand - but
that needs to be checked.
In any case, it's important to test new ones to be ready to switch.
I'll let you know what'll happen.
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17133-its-the-end-of-the-nubs-as-we-kno…
Follow me on twitter for short but faster news:
https://twitter.com/EvilDragon1717
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Let's continue with our details about what's happening.
This time with...
1. Wifi, Audio and the SGX
--------------------------
We want as few binary blobs as possible, but there's probably no way to
get a Wifi chip without a firmware blob (the driver will be open
though!). While not yet fully decided, we'll most probably use the
WG7351 from Jorjin: http://www.jorjin.com.tw/#!wg7351-00/c1dnh
We've got a small concern as drivers are not being developped by TI
anymore for the WiLink6 chipsets but only for the WiLink8, but then
again, if the WiLink6 drivers work reliable and support all features
without issues, there won't be a need for more updates.
Right now, Jorjin suggests to use the WiLink6 modules as they work
without issues and there still seem to be some with WiLink8 modules. Of
course, if we get issues with the WG7351, we'll switch to a different
one.
If you know of any other small modules with good Linux drivers we can
get, feel free to suggest them here :)
This brings me to the next binary blobs: The SGX.
As you know, we can't choose our own GPU, we need to live with whatever
GPU we get with the SoC. The OMAP5 has Imaginations SGX, which is know
to only work with a binary blob (same on the Pandora).
While it's not great, it's still acceptable - but there's one issue:
There are two small binary blobs that make our life harder. One is a
library linked to MESA - so to use a more recent version of MESA (the
blob from TI supports the one from Ubuntu 12.04), we need to recompile
that small library. Similar with a second one: It's the one that offers
X.Org support. Unfortunately, TI has removed X.Org support in favour of
Wayland in their latest driver versions, so we need to be able to
change that one as well.
I'm already in contact with TI to find a solution and try to get these
little parts opened (at least for us). The other way would be to
recreate these libraries ourselves (which is possible, just takes a bit
of time). notaz suggests to recreate the libraries anyways, because it
would be hassle-free for us in the future.
Next, let's move to audio... audio? Binary blob?
Well... we feared that at first, but it looks like we don't need one.
I know I told you that we'll re-use Pandoras awesome audio setup -
however, it could be that it's not easily possible, as the OMAP5 has
different outputs than the OMAP3. Also, we need more audio outputs than
with the Pandora (3G/4G, etc.), which makes things even more complex.
TI offers the TWL6040, which is optimized for work with the OMAP5 and
offers all the features we need. According to specs, it should have the
same good quality as Pandoras Burr-Brown DAC, but I won't believe spec
sheets, I will test that! As you might know, my main job is doing
audio / video stuff in broadcast (TV) area. We've got plenty of
professional measurement devices, and I'll use them to test both
Pandoras and Pyras output and compare them. I surely don't want worse
audio.
A certain part (AESS Codec) needs a binary blob.
At first we thought we need that Codec for standard audio output - but
it turned out we don't. We can easily use an open codec, but with the
AESS Codec, we could use audio hardware effects (like an equalizer,
etc.)
I hope to do some audio testings soon and let you know (and listen to)
the results :)
2. The OS
---------
I didn't have much time to do anything there during the last two weeks,
but aTc has been slowly working on it, created a debian package of
fbturbo, and I hope I'll find the time to setup a repository and build
server next week (with help from aTc and other chaps).
I can't wait for the day when the server spits out a bootable image
that will run on our real first prototype :D
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17080-its-the-details-that-take-longest…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Let's continue with our details about what's happening.
This time with...
1. The LCD Cable and Display PCB
--------------------------------
Askarus and me have taken the time to design the layout (physical, not
electrical) of the LCD Cable, using paper and thin foil cuts to measure
that everything fits and can be assembled.
The flex cable will be a lot more simple than for the Pandora:
* No edges which rub against each other and could cut traces * Only
half of the traces needed, so traces on one side of the cable are
enough, no double-side (like on the Pandora) needed.
* The cable will be twice as wide in the area where it rolls and we're
keeping distance from the edge to prevent any damages there.
* The cable will only connect two PCBs, it won't have it's own PCB
included at the top.
We've not yet decided whether we make the lines redundant, so if one
breaks, there's still a second one, but we'll see how well that all
fits.
Nikolaus and me are also currently discussing about how the display PCB
will be layouted so that it is easy to assemble, needs as little space
as possible in the lid and works without any issues. There are multiple
solutions possible, and we need to find out the best one, so we'll do
some mechanical tests as well.
2. The LCD
----------
I received some BOE LCD samples which have the touchscreen applied.
Unfortunately, they're not properly assembled (there are air bubbles
between the touchscreen and LCD), but we'll get them replaced for free.
We can already use them for mechanical tests though.
I'm currently in favour of using the BOE display, as we got it to work
already and it had a fantastic picture. I'm also getting a demo board
of the Success display though, so I can test and see if it's worth
finishing our driver for it or not. And Sharp is interested in getting
their display into the Pyra - they even tried to code an OMAP5 display
driver for us, so we'll test their LCD as well. It's 5,2" instead of
5", so we need to check whether we can fit the LCD into the lid without
changing the size, but I think it might JUST work.
We haven't continued to work on the Rotator chip driver (not enough
manpower), as we know it's software and we know it works with the BOE
displays in other setups, so that has a bit lower priority.
That's it for today - more stuff will be posted tomorrow :)
That's it for today.
More stuff will follow tomorrow :)
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17066-its-the-details-that-take-longest…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Things seem to slow down (with less blog posts I do), and that's true
in a way, but untrue in another. Yes, progress has slowed down - which
is normal for a product. The first 90% of development are fastest, from
then on, it's only the details that remain... and those take longest.
We're now in that stage.
But while visible progress slows down, the actual background work is
more than before, and hasn't slowed down a bit.
It's quite a lot of things to tell you about, and surely a lot to
discuss about as well. So I'll do one post per day now for the next few
days with small snippets :)
Let's start with...
1. The Case
-----------
The case company is currently tweaking all the issues I found (stylus
didn't hold, speaker area needs to be finished, shoulder buttons need
improvement (and an alternate design should be created for testing),
battery compartment needs to be changed to fit the new battery, some
areas need to be modified so that the LCD cable can fit, etc.)
I've created quite a list (including pictures and explanations what
they need to be aware of when designing those areas)... and whew, that
really took quite a while. You need to think ahead of all issues that
could occur and explain upfront what needs to be done to prevent that.
I can't wait to receive the next case update - it should be pretty
close now to the final version!
2. The Keymat
-------------
The keymat sample we got was working fine (and felt fine), but the
material was not diffuse enough so you could see the LEDs clearly
below. I'm getting more keymat samples with more diffuse material soon.
No layout discussion from my side until everything is mechanically
ready :)
3. The Stylus
-------------
I've got an offer from Elton to create Pandora / Pyra-versions of the
XStylus - but I'm not sure yet whether we should use it or not. I
personally am fine with the stylus we got for the Pandora and have used
the XStylus for the Nintendo DS, but it's not more comfortable for me,
only a bit flakier.
The Pyra XStylus would use a new nylon material which doesn't break as
easy, so it should be better than the NDS XStylus.
What do you think? Would you prefer an XStylus as default stylus or a
solid one like in the Pandora?
That's it for today.
More stuff will follow tomorrow :)
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/17064-its-the-details-that-take-longest…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
The road from a first PCB version to a fully working prototype is a
long one.
Moving to Kernel 3.17
---------------------
Nikolaus is working at two things at the same time: Getting kernel 3.17
to work with all hardware AND testing the hardware itself.
There are two reasons to switch to 3.17:
1. It's the latest one (which we also want to use on the final unit)
2. He's also working with 3.17 on the GTA04, and quite a bit of
hardware is similar, so it saves some work.
Mostly, Kernel 3.17 is now working fine without major issues.
What's nice is that the CPU temperature is even lower than with the 3.8
kernel (about 10 degrees less on idle state).
The mainboard tests
-------------------
Now, onto testing the features of the mainboard.
First, let's start with what has already been tested and is working
fine:
* Keyboard-Backlight LEDs
* Shoulder Buttons
* Nub buttons
* Nubs (Position etc.)
* Keyboard
* Sensor: BMP180 (digital barometric pressure sensor)
* DC/DC-Converter for the USB-Hosts ports
Not yet tested:
* RGB-LEDs
* Stresstest VBUS
* Mikrofon-Detect-Switch
* CPU-Reset-Logic (LSH-BOTTOM + Poweron)
* Charger-Bypass
* FTDI232 (Linux console)
* Charger
* Vibration motor, Microfone, Speakers
* Modem-USB, Modem-Ignite, GPS
* INA231 (for checking modem status)
* Fuel Gauge(s)
* Other sensors
Can't be tested yet (as we need the CPU-Board or the next revision of
the motherboard:
* HDMI
* eSATA
* USB-OTG 2/3
* Audio
* WLAN/BT
* Display connected to the mainboard
Quite a lot of things to test, but we're moving forward.
Case design
-----------
FormAction (the case design company) is back from summer holidays, so
we resumed the work there as well. I'm working on giving detailed
explanations how the shoulder buttons should work internally and
externally, and we also want to try out Fusion_Powers design as well as
optimized the one I suggested.
The OS
------
Things are moving along, slow, but sure.
We've setup various gits (http://dev.pyra-handheld.com/) and will soon
populate them. The basic creation of a rootfs using debootstrap is
already working, now we need work out how to do automatic package
creation from sourcecodes and scripts and maybe move to multistrap (so
we can create the image directly on the server, not using the EVM).
Other stuff
-----------
Two batteries from two different companies have been sent to
FormAction. One is thicker, one is wider than Pandoras one, both have
6000mAh. They will let me know which one would fit better into our case.
We'll most probably use the BOE display, as the quality is great and we
already got it to work. We still want to test the success and maybe a
Sharp one.
Oh, and as someone requested it:
The Blog now has an RSS feed as well:
http://boards.openpandora.org/index.php?app=core&module=global§ion=rss&…
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/16973-the-long-road-to-a-final-unit/
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Finally, a new newspost!
I have to admit, it took a while since I posted some news - which was
simply because GamesCom preparation, the GamesCom itself and catching
up with my shop AFTER the GamesCom took quite some time.
Still, Pyra development has not halted, so here are some news.
But first of all, since I just mentioned GamesCom, I wish to send a
[b]big welcome to everyone who joined our boards or newsletter after
visiting us there.[/b] I hope you will have a lot of fun and excitement
together with us.
Okay, on to the news...
1. GamesCom
-----------
The GamesCom was a huge success.
There were TONS of interested people and they were all amazed by the
power the Pyra showed on our FullHD screen (well, we had multiple PSX
and MegaDrive emulators running and still a responsive desktop at
1920x1080... - all fullspeed).
What most of the visitors found especially great is the replaceable CPU
PCB. I was happy that most people love the idea having an upgradeable
system instead of producing more and more electronical waste. These
days companies tell you that you need at least one new smartphone each
year... great that's not the common opinion :)
We had a few special guests there - [i]LinuxSWAT[/i] was helping out
again, but we also had [i]ptitseb[/i] visiting during the weekend and
[i]notaz[/i] was even there the full time and was working there on the
devboard. They managed to get some games as well as Reicast and Mupen
running, but those still need more optimization.
All in all, GamesCom was great - and the retro area was fun.
2. The LCD
----------
We made various tests with the LCD from BOE, and we were really
satisfied so far. We tried Sonic 2 - famous on most mobile screens for
flickering palmtrees and black ghosting of the rings in the sky. Well,
we couldn't see any ghosting and even the flickering was only visible
if you knew what to look for.
We didn't have the rotator chip working with it yet and Nikolaus was on
holidays (as you might remember), but he's now looking into it. There
are multiple devices out there using the rotator chip with exactly this
one panel, so we know it'll work ;)
Additionally, we found the 720p resolution with 5" perfect for a Linux
standard desktop. While the default settings have small fonts and
icons, they're still perfectly readable (I like it small), with the
1080p LCD, it was just unusably small.
We still have the Success panel to test, but the BOE one is already
pretty good, and a LOT better than the Pandora LCD. As soon as we have
the rotator chip working, I'll make some nice videos for you.
I've already ordered a few samples together with touchscreens.
3. The software
---------------
notaz got the 3D driver to work together with fbturbo (which is a real
fast, NEON-accelerated framebuffer driver for X). The official TI
driver uses DRM - which is okay for normal desktop usage, but with
that, we can't use the framebuffer directly (which is where Pandoras
SDL version gets the speed increase from). So we definitely want to get
an X driver working that offers framebuffer usage - and that's why we
chose to use fbturbo.
As mentioned, the 3D driver is working already, but is still hardcoded
to ask for DRM. This is something we'll try to fix, otherwise, all 3D
games would need a patch. Another (small) downside is that the 3D
driver only works in fulsscreen mode.
No big thing, as even apps like Blender can also run in fullscreen mode
and games are usually played in fullscreen mode anyways. Still, we'll
try to fix that as well. If you really desperately need 3D with
windows, you could theoretically switch to TIs DRM driver, as it works
there.
We'll now concentrate on setting up standard Debian distribution with
our own patches for the Pyra.
4. Batteries
------------
I've received two different 6000mAh batteries from two different
manufacturers. One is thicker, one is wider. Both have been sent to the
case design team. They'll check which one can be easier implemented
into our current case design.
5. The Case
-----------
Not much has happened here, as the company in Greece is closed for
summer holidays. I took the time to write down a list with current
issues and a to-do-list which they'll work on when they're back in
September. It's not that much left to do, to be honest.
I'll continue tweaking the shoulder buttons and I'll also try
Fusion_Powers design.
6. The hardware
---------------
It's time for testing the main PCB thoroughly, we also still need to
add a Wifi chip. Then it's time for the CPU PCB.
I'll keep you updated with more news here.
That's it for todays post.
Now that I catched up with everything, I hope to have more regular
newsposts again.
Feel free to ask any questions here :)
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/16903-no-time-for-a-break-after-gamesco…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org
Well, there weren't posts for a while, since we've been busy preparing
flyers, etc. for the GamesCom.
And that took a lot of our time.
The shoulderbuttons
-------------------
In the meantime, a green case arrived - the latest revision with the
new shoulderbuttons. Do they work?
Well... yes, basically, they do.
However, there's one thing I can tell you after having assembled the
case: While we've got four shoulder buttons and all of them can be
pressed, it won't be comfortable to use the upper ones when gaming.
It's not possible with the extremely small and cramped space we got up
there.
The lower ones need a bit of tweaking but will work comfortably then,
but for the upper ones, you will have to bend your fingers a bit, which
is not nice to do for extended periods of time.
They will be fine for functions you don't need that often in games and
they will work fine as modifier keys when typing (as your thumbs are
lower when you're typing than when you're playing).
If you're coming to the GamesCom, you can test them yourself and let us
know if you got anymore good ideas, but we already discussed that with
multiple users here, and no one got an idea how to solve that in a
comfortable way.
The Heating
-----------
There's been a lot of discussion about heatsinks, special materials and
even tiny fans on the other thread, since it seem the OMAP5 will get a
lot hotter than the OMAP3.
Well, I finally found the time to properly measure it with a
professional IR thermometer (without heatsink).
The result:
The OMAP5 internal measurement seems to be off quite a bit.
When it shows 80°C, it's actually 55°C on the surface of the SoC itself.
With 112°C (the maximum I could reach with maximum stress on both CPUs
yet), it's 84°C.
The OMAP3 in the Pandora has a maximum of about 70°C, so it seems the
OMAP5 (under full load) is about 15°C higher. That's not that much. The
Pandora doesn't use any heatsink, so a few copper layers as heatsink
should be enough.
aTc also did some tests with his devboard.
The heatsink on the OMAP5 doesn't do much cooling actually - unless you
use a fan. So the only real way to lower the temperature a lot would be
using a fan.
We probably don't want that, so the best thing we can do is distribute
the heat inside of the case to prevent hot spots. Shouldn't be much of
an issue though.
The GamesCom
------------
We're leaving for GamesCom tomorrow morning and hope to meet some of
you there. We'll have a Pyra devboard there as well as the prototype
case and some nice PCBs to look at (and see how the CPU board will work
and look like).
We'll take pictures as well, and I'll try to write small reports for
you.
Discuss about that post on the webboards:
http://boards.openpandora.org/topic/16809-gamescom-shoulderbuttons-and-heat…
--
Greetings,
Michael Mrozek
-----------------------
OpenPandora GmbH
Geschäftsführer: Michael Mrozek
Schäffbräustr. 11
85049 Ingolstadt
Deutschland
Tel.: 0841 / 13 177 33
http://www.openpandora.de/
HRB 4879, Amtsgericht Ingolstadt
-----------------------
eMail: mrozek(a)openpandora.org