Keep cool!


EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,986
Age
47
Location
Ingolstadt
Just some quick newspost, as it's late and I'm dead tired already...
But I hope you'll like it :)

Cooling, part 1

I'm still waiting for some small copper heatsinks that have been shipped to me.
These will be placed below the USB Port and the heat from the CPU will be moved there with a special heat-distribution material (self-adhesive tape).

However, I finally had the time to measure out and finish the first part of the cooling:
A 0.4mm thick aluminium plate which will go between the CPU-Board and the case and battery.

This will be self-adhesive as well and will be glued to the case backside, so you can open the unit and still access everything without any problem.

Here is a manually cut-out plate for you to look at:

IMG_20170724_001731.jpg

I will test how well the cooling works once I have part 2 finished as well.
In normal operation, the Pyra still is cooler than my GPD Win, so we should be fine.


The Sealing

The design for the sealing (which will be done with an adhesive tape) is now also finished.
Here is a quick hand-cut test pad:

IMG_20170724_004053.jpg

I haven't tested it yet, as the speakers aren't properly setup in our OS version right now (Pulseaudio configuration) - and therefore, playing sound right now drives the vibra motor :D
This is cool.... but not really useful ;)

I'll let you know once I can test it :D



The keymat

Everything is good here :)
DPad now also works fine.
There's a small tolerance issue where some of the produced DPads are too close to the PCB and aren't as nice to use.
That's already fixed (only 0.2mm needed to be cut from the mould) and we don't really need another sample here.

So: Keymat is now also ready for mass production!



The case

Will these be produced before August or not?
Well, I don't know myself yet.
They should be, the slot is planned, but I haven't heard exactly when (as I certainly need to inspect them before mass production!)

Of course, I'll keep you informed! Most important thing for me right now is getting final, properly looking cases with shoulder buttons, even if it's just a few samples.
Because if everything is fine, we can do the production run right after the holiday. We won't have the PCBs before that anyways!


Deadline for hardware bugs

Quite a few devs have units already, and except for the few bugs zmatt found months ago (and which have been fixed), nothing new has been found yet.
So it's time to move to the next step: Setting a deadline for finding remaining bugs - and if none are found, start the PCB production.

So far, the units themselves are working, so any remaining hidden bugs shouldn't be anything major. And at some time, we need to make a closure.
I'll set that for the start of the GamesCom middle of August.

This should also give Nikolaus enough time to thoroughly test the 4GB RAM.

So much for today. Quite a few things have now been finished and are final as well.
We're moving slowly, but still towards the mass production, so that you'll all receive units soon :)
 
Could someone wake me up whenever mass production starts? Thinking about going into hibernation too damn early, atm..
So good to hear things are moving forward, tho!! Please be soon, pretty please! <3

Edit: Getting the Pyra within at least a year would be way beyond what some have predicted.
Sure, could wait 2-4 years, even... And also, These news-posts with so much positive progress means a lot since it personally breaks a negative cycle of... meh after meh after meh, ect.

Happy dragon is happy~
 
Last edited:
It's very cool that things have reached the point where deadlines can be given, given how much of this project has felt more 'when it's ready' to me. And that it's far shorter than 2 months (tm) by any conventional definition is impressive.

In terms of 'the PCBs' are you lumping the main/periperal board and the CPU board, not forgetting the display board together there? Or have orders for the larger of the three been ordered already or anything?

Thanks for the updates!

Edited to add: Regarding that heatspreader, have you identified all of the hotspots yet? Is the 4G chip expected to kick out any heat, and maybe also the RAM now it's separate from the SoC? Also, if it's bound to the case, how will you get the heat from the hotspots to it? I also hope this won't affect the battery either in terms of stressing its heat shielding, or in terms of making it lose contact with the terminals - IIRC 0.4mm is much thicker than tinfoil for comparison.
 
Last edited:
OMG... I have cautious excitment

I thought we were going to have ANOTHER keypad test run..... Thank goodness that isn't the case!! FInally it looks like things are starting to get there. Seem like only main board, heating, and some case issues left.

Was the ram ever figured out?
 
Wow, best news post so far! Sounds like it's just that niggling 4G issue, software tweaks, and case production turnaround irks that are left.

I might not have been to happy about parts glued in place, but in this case, they are justified and an glad that they shouldn't affect disassembly/maintenance in any way.
 
...as the speakers aren't properly setup in our OS version right now (Pulseaudio configuration)
I still haven't figured out what pulseaudio is actually for yet! it doesn't do network sound properly or much else for that matter, still at least there are alternatives...

great that what looks like the final physical tweaks are on going, bit by bit its all getting there!
 
great news, happy to here. im thinking case's will be here in September im thinking.
 
I still haven't figured out what pulseaudio is actually for yet! it doesn't do network sound properly or much else for that matter, still at least there are alternatives...

I have come to the conclusion that the behind the scenes stuff in ALSA, PulseAudio, even Windows - that all works fine. What truly fails in all of them is the interfaces. They are all too simplified and 'output centric'. I would prefer to have one that is 'input centric'.

Each input should have it's own controls specific to all available outputs. This should include discrete handling of video.

Example:
Open Audacious(1). It appears in the mixer panel as an audio source. Set it to output audio via the HDMI port. Adjust balance, etc..
Open VLC. It appears in the mixer panel as an audio & video source. Set it to output video to the display and audio out the headphone jack.
Open Audacious(2). It appears as a second instance in the mixer panel as another audio source. Set it to output via the headphone jack AND the HDMI port. Mix audio streams with VLC - adjust volumes accordingly.

Above, each source is being pointed to an independent output - it should be able to them all simultaneously. Independent control over every input and every output in a clear and meaningful way with per-program settings so that playback profiles can be saved.

OK, so it's a dream.
 
I have come to the conclusion that the behind the scenes stuff in ALSA, PulseAudio, even Windows - that all works fine. What truly fails in all of them is the interfaces. They are all too simplified and 'output centric'. I would prefer to have one that is 'input centric'.

Each input should have it's own controls specific to all available outputs. This should include discrete handling of video.

Example:
Open Audacious(1). It appears in the mixer panel as an audio source. Set it to output audio via the HDMI port. Adjust balance, etc..
Open VLC. It appears in the mixer panel as an audio & video source. Set it to output video to the display and audio out the headphone jack.
Open Audacious(2). It appears as a second instance in the mixer panel as another audio source. Set it to output via the headphone jack AND the HDMI port. Mix audio streams with VLC - adjust volumes accordingly.

Above, each source is being pointed to an independent output - it should be able to them all simultaneously. Independent control over every input and every output in a clear and meaningful way with per-program settings so that playback profiles can be saved.

OK, so it's a dream.

That's how Jack works, sort of...
 
That's how Jack works, sort of...
And Pulseaudio, as that's what I'm doing with it on my PC: Redirect the audio signal of any program to any audio output.
Which is what we need for the Pyra, as we have multiple audio outputs (the Pandora only has one)

If JACK can do the same, I'm fine using that as well (never used JACK so far)

Sent from my XT1650-03 using Tapatalk
 
Which is what we need for the Pyra, as we have multiple audio outputs (the Pandora only has one)
ALSA can do the very same, the big difference is that PA can change it on the fly - once the program is already started and its audio interface initialized, ALSA's routing is pretty much set into stone.

If JACK can do the same, I'm fine using that as well (never used JACK so far)
The issue with JACK is that it is not and never was being developed as an universal framework that just runs in the background - it targets a specific usecase and sticks to it, it's professional software. The developers themselves recommend to not have it run all the time as its realtime requirements are pretty demanding.

And trying to get Bluetooth to work with it is likely to be the very same procedure than with ALSA, because it's really just a virtual switchboard. If it works at all, Bluetooth lacks the realtime properties that JACK expects from its hardware.
 
I haven't tested it yet, as the speakers aren't properly setup in our OS version right now (Pulseaudio configuration) - and therefore, playing sound right now drives the vibra motor :D

This begs the question... Can it carry a tune? ;-)

-Neelix

Edit: Cleared double-post - Binky
 
Last edited by a moderator:
During my adventures with Linux, I found PulseAudio problematic in one case: Configurability. Command-line tools don't list all options when they should, and sound output is usually set to wrong (at least in Dells). Nice configuration offered by pavucontrol is incomprehensible (I have to check "as spare" to use my output as primary in all applications - logic anyone?) and result is not saved. Configuration made by command-line tools likes to reset between reboots, so the only thing I found working is to mess with files in /etc.
On the other hand, PulseAudio allows to transform these universal sound i/o in a handy and quite documented way if only sound card is supported. And vibration motor may be driven with some modulation, so maybe it's a channel of the DAC?
 
Back
Top