Production Pyra photos/videos/thoughts thread


levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
13,001
Location
Somewhere off the coast of the EU
Thanks for your kind words, it was my first video at all, i think at the pyra, i will have to first make notes what i want to say, and i have to look first how the correct words are, so i ditnt have that much thinking breaks in it
These "ähm" s where just there because i needet to remember the Translation...
Theise ähm's sounded just like English erm's to my ear, with a slight german accent. Even people speaking English intersperse their speech with those as they try to come up with the right word, so I almost didn't notice them at all.

Some people record their audio after filming. Maybe you could record it with audio then ditch that audio, and do it again under more controlled settings, so you have the timings more or less right for what you want to say, but that is a chunk more work, and it wasn't at all for hard for me to follow what you said live, so I'd propose this video to be a success.

So we now have tereing to match up with the sirring sound. Do you get tereing when you do too much sirring?
 
Last edited:

matzesu

Forum Addict!
Staff member
Joined
Oct 24, 2008
Messages
10,148
Age
36
Location
Germany,, Saarland, at home
Well, im happy that it worked out whit the one take videos, i dont know how to mix sound whit the allready filmed video...

The noise may come from my small fridge i have near my desc for Schokolade or other things, and my Pandora make also some noise..
Next time, i will thoug about my speaking bevor, and try to speak more natural
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
13,001
Location
Somewhere off the coast of the EU
I'm not sure what the noise was; I thought it might be traffic noise since it was quite brief (maybe a couple of seconds) and it didn't really interrupt your speech. Fridges generally run for longer than that. Your pandora only creaks and clicks when you press it, and produces sweet sweet music when you played GBC, and I personally wouldnt classify any of that as simple 'noise'.

If your next video shows your fresh number 28 Pyra I doubt I'd even notice any background noise.
 

Confuzzled

Active Member
Joined
Oct 1, 2018
Messages
70
Not to co-opt anyone's symbols, but using a simple 'rainbow' pattern should suffice pretty well. Combining Indigo and Violet into purple as most human eyes have trouble distinguishing one from the other without the other as reference.
Red <= 5%
Orange > 5 and <= 15%
Yellow > 15% and <= 25%
Green > 25% and <= 75%
Blue > 75% and <= 99%
Purple > 99%

Whatever the color or pattern you decide on, though, can we tie the 'intensity' of the glow out to whatever the keyboard backlight is +1? I.e. the light always glows when plugged in, but when the thing is booted up can be dimmed in line with the keyboard back-light settings.
Not brilliant for people who are colour-blind. I would suggest using blinking, with different rhythms and/or mark-space ratios to indicate battery level.
Off - charger not plugged in, unpowered, or otherwise not working.
Mostly off with one short flash per second: Between zero and 25%
Mostly off with a double short flash per second: between 25% and 50%
Off for half a second, on for half a second: between 50% and 75%
Continuous flashing: between 75% and 100%
On continuously: Fully charged.

The above is only a suggestion, and not a hill upon which I wish to die. Percentages, mark-space ratios and rhythms just an example for discussion.
 

λ the β-Redex Reducer

β-Redex Reducing Member
Joined
Sep 13, 2016
Messages
741
Age
50
Location
Lambda Centre
Combine colours and blinking so that the led can indicate 2 different kinds of information. One should be battery level but the other could be for whether it's connected to power.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
13,001
Location
Somewhere off the coast of the EU
Not brilliant for people who are colour-blind. I would suggest using blinking, with different rhythms and/or mark-space ratios to indicate battery level.
Off - charger not plugged in, unpowered, or otherwise not working.
It's my understanding that to people who are red/green colourblind (the majority of colourblind people I believe) then green appears brighter than red. Blinking might be slightly easier to interpret still than an isolated LED of differing intensity, but as a non-colourblind person, I appreciate the simplicity of red/amber/green.
 

FBnil

There is 1 impostor among us.
Joined
Dec 14, 2012
Messages
3,454
Location
Yurp
using blinking, with different rhythms
how about waving (i.e. change the intensity a bit so we see a patterm but not on/off/on/off). And blinking only for when it's drained.

How do people feel about blinking the keyboard (or pyra symbol when closed) Just before automatically shutting down to protect the battery from drain.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
13,001
Location
Somewhere off the coast of the EU
Yes, the shutdown process should probably alert the user using as many low power abilites that the Pyra has, including LEDs. Be aware that if it flashes the Pyra symbol, I don't believe this is visible from outside. I assume that if you've set your Pyra aside, you still need to be aware that it's just shut down because it ran out of battery.
 

PowerGod

Hardcore Member
Joined
Jun 20, 2011
Messages
3,637
Could it be possible to light the pyra symbol only when the lid is closed ?
 

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
330
Location
Seattle
Everybody wants something different :) I’m working to make this customizable via the uEnv.txt file so you can configure the behavior however you want. To start it will be hardcoded to a particular management loop but I will working on making it configurable soon after.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
13,001
Location
Somewhere off the coast of the EU
Yes, looking at the schematics, the lid illumination LEDs come into the lid via an i2c line which gets decoded on the display board and used to illiminate the two RGB LEDs. The current configuration is to light them the same as the internal lights alongside the power button I think, but that seems to all be done in software, so can be changed.

Edit: And maybe it can all be done by editing a text file in the end :)
 

ToastBucket

Very Active Member
Joined
Oct 12, 2010
Messages
330
Location
Seattle
Yes, looking at the schematics, the lid illumination LEDs come into the lid via an i2c line which gets decoded on the display board and used to illiminate the two RGB LEDs. The current configuration is to light them the same as the internal lights alongside the power button I think, but that seems to all be done in software, so can be changed.

Edit: And maybe it can all be done by editing a text file in the end :)
Not quite. There’s two LED controllers, one for the power/status LEDs on the same board and one for the lid status LEDs. They are the same chip, but on different buses so are controlled separately. Right now the bootloader does nothing with the lid LEDs but this will change soon.

Also, it should be noted I identified a hardware bug a few days ago that prevents software control of the red line in the center LED. There is a status line that comes from the charger chip that indicates whether we are charging or there is some sort of fault. This is wired up to the red line of the center LED. It should be able to be disabled via a GPIO, but due to the hardware bug it cannot be. Therefore the center LED always has red illuminated while charging. I’m going to look for a way to disable the status line in the charger chip but I don’t think there is one, plus we don’t really want to do that. This line is useful for indicating charging when there is no SW running
 

Confuzzled

Active Member
Joined
Oct 1, 2018
Messages
70
Not quite. There’s two LED controllers, one for the power/status LEDs on the same board and one for the lid status LEDs. They are the same chip, but on different buses so are controlled separately. Right now the bootloader does nothing with the lid LEDs but this will change soon.

Also, it should be noted I identified a hardware bug a few days ago that prevents software control of the red line in the center LED. There is a status line that comes from the charger chip that indicates whether we are charging or there is some sort of fault. This is wired up to the red line of the center LED. It should be able to be disabled via a GPIO, but due to the hardware bug it cannot be. Therefore the center LED always has red illuminated while charging. I’m going to look for a way to disable the status line in the charger chip but I don’t think there is one, plus we don’t really want to do that. This line is useful for indicating charging when there is no SW running
Well done for finding the hardware bug!
It makes life complicated for ED. I guess he will need to collect together all the known bugs and work out whether it is a good use of time and resources to produce a revised hardware that resolves the known bugs. I do not envy him that decision.
 

Confuzzled

Active Member
Joined
Oct 1, 2018
Messages
70
Everybody wants something different :) I’m working to make this customizable via the uEnv.txt file so you can configure the behavior however you want. To start it will be hardcoded to a particular management loop but I will working on making it configurable soon after.
Ah well, I only made a suggestion. I can well understand that some would prefer a rainbow of colours, or even just red/orange/green. Technically, it would be possible to combine both approaches e.g. fast-flashing red, slow-blinking orange, steady green. Customisable sounds good. Frankly, just a single LED indicating the battery is connected to a powered charging source would be enough: the rest is just decoration.

(I once had a Dell laptop that had 5 LEDs on the battery. A press on a button lit up the LEDs as a crude bar-chart indicating the state of charge of the battery, which was useful when juggling multiple batteries - you didn't need to put the battery into a laptop and boot it up just to see how much charge was available. I am NOT suggesting this for the Pyra batteries.)
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
525
Location
Oberhaching
Also, it should be noted I identified a hardware bug a few days ago that prevents software control of the red line in the center LED. ... It should be able to be disabled via a GPIO, but due to the hardware bug it cannot be.
Well done for finding the hardware bug!
Well, it is not really a hardware bug but a limitation. It was not designed to work this way, so it doesn't work... IMHO it is only a weak limitation for full configurability. There is also a similar limitation for the left and right LEDs which are connected to the USB host overload detector. And, one LED in the display lid remains illuminated after a cold boot until the OMAP turns it actively off. So if the OMAP doesn't boot or gets stuck for any reason during boot you will still see that the Pyra is still powered on and draining the battery. Then you can press the power button for 10 seconds to force shutdown.
 

matzesu

Forum Addict!
Staff member
Joined
Oct 24, 2008
Messages
10,148
Age
36
Location
Germany,, Saarland, at home
This is actually a good solution, its a feature not a bug,
I noticed yesterday when i dit my small test video, that my Pandora was still on when i opend the lid part, it meantioned that it was not properly power off the last time.., so it runs the whole week or so..
I had my LEDs settup on the Pandora to not glow whyle the Pandora is in Low Power Mode..
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
525
Location
Oberhaching
Is FN mappable for scripts?
Depends on what kernel and user-space tools are doing with the key events.
Here is a description of how the keyboard is mapped to hardware: https://www.pyra-handheld.com/wiki/index.php?title=File:PyraKeymatAndButtonsFunctions.png
Post automatically merged:

cool!

So does that mean when you use i2cdetect the LED Controller shows up there?
Well, no. i2cdetect will report "UU" because there is a kernel driver which maps the LEDs to /sys/class/leds.
But yes, if you unload the drivers you can use i2cset to control the LEDs. i2cget will not report anything since the chips are write-only.
So it is better and easier to use the kernel driver...
 
Top