The indicator LEDs - what should they do?

[PowerGod]

Don't forget the color blind people !
I don't know which sequence/combination to avoid, maybe someone knows here ?

In my case it's Red/Green mainly, but depends on the actual tonality

 

[levi]

Regarding battery status, I'm mostly happy with it just telling me when I need to put it on charge. I do have to plug my TV-out-only pandora into my TV to check battery if I'm going away for a while, but I'm fine with that personally, and if I had a working LCD connector just opening the lid and saving whatever fullscreen game I was in to check would be even better.

 

[Neelix]

Regarding battery status, I'm mostly happy with it just telling me when I need to put it on charge. I do have to plug my TV-out-only pandora into my TV to check battery if I'm going away for a while, but I'm fine with that personally, and if I had a working LCD connector just opening the lid and saving whatever fullscreen game I was in to check would be even better.

Likewise, I see no need for battery level indication beyond the battery-low warning. A charging indicator would still be appreciated though.

-Neelix

 

[Grench]

Isn't the power button itself also an RGB led that can be used? If so, i would just indicate the battery state permanently on that.

This. I thought that the power button was an RGB independent of the keyboard backlights. Can someone confirm?

I had envisioned that all power states could be communicated through the power button RGB. Pulsing red for connected/charging for example. (The Tapwave Zodiac did something similar to this on it's power button.)

Also, the keyboard backlight itself, though not capable of color selection, could also be used in notifications. Incoming call could, in theory, make the keyboard backlight flash/strobe for example.

So - 6 theoretical communication channels via LEDs?
Now, also combine in the rumble motor - it is also a notification point. 7.
Chimes through speakers? 8.

Multiple colors * multiple RGB LEDs * rumbles * chirps&chimes = metric ton of possibilities.

Then there is the difference between what should be done with the lid open vs lid closed. With the lid open, I would want the option to turn off the lid LEDs - they're not facing me then. With the lid closed they should convey a whole litany of information - or not. User configurable options is going to be key to this - and the lid switch closed/open will be an important if/then factor.

Of course, someone will have to eventually create a 'disco effects' plugin for an audio player where different portions of the audio spectrum trigger different LEDs to glow in relative intensity to the power in that spectrum... Yeah, pointless, but Blinkinlights!

 

[ible]

Multiple colors * multiple RGB LEDs * rumbles * chirps&chimes = metric ton of possibilities.

i don't think i want to be caring around that much weight. but i guess a US ton isn't that much smaller. (a Brit ton is larger than both??)

 

[levi]

The rumble motor is only available when the unit is handheld, and the power button LED (thanks, I'd forgotten that one) is only usable when the lid is open, so I wouldn't want the battery low indicator to be on that button LED alone.

I'm not sure what you could really use that power button LED for, maybe the battery level indicator (just not the battery low one), but I think we should bear in mind that the Pyra will have 1080p out on its HDMI port, so using it plugged into a screen with a bluetooth controller or two could be quite a common usage. Maybe SD activity could also be on that button, but that doesn't feel like a good fit for the power button to me.
[doublepost=1474334184,1474330077][/doublepost]I've reworked the first post to eliminate some of my waffling, and to list the notifications that people have identified in this thread, in a sort of high/low/info level scheme.

 

[directive0]

I think its great that we try to determine the default settings for these lights as soon as possible, but there are so many possible lighting setups that could be interesting the reality is you will NEVER get consensus on this issue.

Therefore the only answer I can muster is that the lights need to be REALLY customizable. I know a lot of people here fancy the DIY solution, but a simple and accessible preference pane that lets you assign functions to each adressable light is really desirable. They need to be easy to disable too. Like a quick toggle to make all running lights turn off.

On the pandora there are setup wizards for a lot of functions which is great, also the quick toggles are very nice. Something like this for the lights would be great.

 

[Linux-SWAT]

IMHO first work on a wiki temp page listing all the events available (cpu, sd1, sd2, microsd, emmc, wifi, bluetooth etc.)
Then assign after that.
Maybe we should keep the order+color of the Pandora leds first.

 

[_jr_]

The rumble motor is only available when the unit is handheld, and the power button LED (thanks, I'd forgotten that one) is only usable when the lid is open, so I wouldn't want the battery low indicator to be on that button LED alone.

Yes, but gaming controls and keyboard are key features. Having some kind of low power indication visible on a closed unit is definitely nice, but having the primary indication on the inside seems reasonable to me.

 

[Grench]

IMHO first work on a wiki temp page listing all the events available (cpu, sd1, sd2, microsd, emmc, wifi, bluetooth etc.)
Then assign after that.
Maybe we should keep the order+color of the Pandora leds first.

However, on a device like this, hardware events are only the tip of the iceberg. If all of the 'clearest' to interpret signals get used up by hardware events, then the software events (incoming call, SMS, alarms/notifications, etc may wind up with harder to interpret signals.

Something else that could be interesting - unified signal LED brightness control. Our button in the atic of the keyboard controls lights.
Unmodified press = screen backlight increase
Shift + press = screen backlight decrese
Fn+press = keyboard backlight increase
Fn+shift+press = keyboard backlight decrease

It isn't much of a stretch to conceive:
Ctrl+press = Master LED brightness increase
Ctrl+shift+press = Master LED brigtness decrease
Alt+press = Master mixer volume increase
Alt+shift+press = Master mixer volume decrease
Super+press = Rumble motor intensity increase
Super+shift+press = Rumble motor intensity decrease

Of course those could/would be shortcuts not shown on the keymat - and there would still need to be a menu driven approach too.

All of that said, I don't think the default behavior is going to be something for the community at large to dictate. Rather it can be declared via proclimation by whoever makes the software package that controls the pacage(s) that do it. I don't expect this level of control at product release - just the ability to turn them on/off via command line for testing. From there it opens up for someone with the time and inclination to build what works for them and share it out at their leisure.

 

[levi]

IMHO first work on a wiki temp page listing all the events available (cpu, sd1, sd2, microsd, emmc, wifi, bluetooth etc.)
Then assign after that.

At the moment, I'm updating the first post of this thread to capture those events and categorise them. It's only my categorisation at the moment, but if anyone seriously disagrees, tell me. Anyone is free to port it to the wiki, but I'm not convinced the wiki is always the best way to capture disagreements, if one should arise.

 

[Linux-SWAT]

As you wish, at least it's archived.

 

[Grench]

Another thought... The two LEDs in the lid and the two+power inside don't need to be treated individually/exclusively. The duration, brigthness and combination of the LEDs are theoretically informative as well.

Theoretical example:
Left red fast pulse = left SD write
Right red fast pulse = right SD write
Both red slow pulse = low battery
Alternating left/right red flashing = ex girlfriend/boyfriend calling

There are so many possibilities. When combining color, intensity, duration and "light chording", the possibilities become pretty staggering.

Next up - someone will want the key/translation for the light codes printed on the lid.

 

[Linux-SWAT]

Here's what the letux/hns kernel handles on the EVM now :
$ cat /sys/class/leds/omap5\:blue\:usr1/trigger
none kbd-scrollock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock mmc0 timer oneshot [heartbeat] cpu0 cpu1 default-on transient mmc1 mmc2

 

[Haraldur]

I spent some time last night on an LED system design.

Firstly, some principles:

1. The power indicator should be on the power button LED.
2. The power button LED and one other on the front should be duplicated on the back. That means that there are 3 RGB LEDS available, with two duplicated.
3. Blue keeps people up at night and is relatively distracting, so red and, to a lesser extent, green should be favoured for "chronic" signals -- those likely to be active for long periods (and especially when the human sleeps -- this applies less to the non-duplicated LED).
4. Combination of red and green (yellow) is particularly difficult for colour-blind people to distinguish from either red or green (green, in my case).
5. There should be only one blinker per LED. More would likely be confusing, as it may be difficult to distinguish one from another.
6. LEDs conveying system information should be accessible only to root. This includes the power indicator.
7. At least one LED should be accessible to non-root users, and that should be duplicated on the back.
8. Phone-related information should, generally, be on a non-root LED as some Pyras will have no LTE-modem and because people may wish to change the phone software they use.
9. The back LEDs should be off when the lid is open, and the front LEDS off when the lid is closed.
10. Colours used must be as mutually different as possible (to aid the colour-blind, particularly).
11. From 10, there is a limit to the number of simultaneous indicators allowed, as otherwise there would be too many similar colours, confusing those with colour vision troubles (about 10% of males, 5% of general population, so more like 9% of the Pyra's likely owners).

The principles are most important, as they do not rely on minutiae of the hardware (particularly: is it possible to have a cell phone connection without GPS and vice versa? is it possible to have Bluetooth connection without WiFi and vice versa?). I am particularly interested in any disagreement with, or additions to, the principles.

My scheme (assuming that GNSS(GPS/GLONASS), GSM, WiFi and Bluetooth are all orthogonal/independent) includes the following:

1. power on/off/standby indicator
2. low power alert
3. GSM on/off indicator
4. WiFi on/off indicator
5. data access ((micro-)SD and NAND) indicator
6. low RAM/virtual-memory(RAM+SWAP) alert (I think all computers should have this, but the Pyra is relatively RAM-constrained, even at 4GiBs)
7. Bluetooth on/off
8. GNSS on/off
9. phone call alert (may also alert for SMS and email and for other alarms)
10. unread SMS indicator
11. unread email indicator (perhaps pointless, as it is likely to be always on, if most people are like me)

Data transfer indicators for GSM/WiFi/Bluetooth would need to be on the desktop -- the most important thing is the on/off indication, for energy conservation purposes and/or privacy.

Here are the notional LEDs, the main colours the user should see are red, green, blue and white:

Power button LED: accessible only by root, duplicated on the back, bright when on, dim when on standby and (obviously) off when off (I am not sure how to give an indication on the LED of charging when the OS is not running, but doing so would not necessarily mess up the rest of the scheme). Is used for system info that should be visible from a distance (and so is duplicated on the back).
Blinker: Blink slowly when 5% battery is reached, then faster when 2% battery is reached. Do not blink if the battery is charging (regardless of current fullness). Constant on indicates that the power situation is "OK".
Red: Both WiFi and GSM are off.
Green: GSM on (if used, is likely to be on all the time and also on when on standby, so should not be blue).
Blue: WiFi on (is there any point in having WiFi on while on standby? It would likely be a niche use, so it is fine for this to be blue).
White: GSM on and WiFi on (no need for purple-- it gives me problems anyway, as, for me, both green and blue overpower red).
Off: Power off.

Root LED: accessible only by root, NOT duplicated on the back. This one should spend a lot of time completely off.
Blinker: blink when there is data transfer to or from any of the SD cards, micro-SD card or NAND. If no other colour is in use, blink as a dim red.
Red: Bright red if free virtual memory (RAM+SWAP) is low (as opposed to the dim blinker default). A constant red is a giveaway that memory is low.
Green: Bluetooth on (presumed infrequent -- I have never really used Bluetooth).
Blue: GNSS/GPS/GLONASS on (OK to be blue as it is presumably only to be used outdoors).
Yellow: Low memory plus Bluetooth on (expected to be unusual, so the complex colour is OK).
Purple: Low memory plus GNSS on (expected to be unusual, so the complex colour is OK).
Cyan: Bluetooth on plus GNSS on (expected to be somewhat unusual, so the complex colour is OK).
White: Low memory plus Bluetooth on plus GNSS on (hardly ever, surely? so the complex colour is OK).
Off: All is good. Idle.

Application LED: accessible by any user or program, duplicated on the back. This is really a suggested default scheme, the real behaviour would be dictated by what ever programs the user runs, at any given moment.
Blinker: blink when any generic alert is received, like a wake-up alarm, a phone call alert (blink until call received or abandoned) and SMS alert etc..
Red: unread emails (most people have a backlog, but red is not very disturbing to sleep nor distracting).
Green: if phone call or other alarm and there is nothing unread, then blink green. Note that if receiving an SMS, the alert is always blue or white, while for an email it is red or white. Green is otherwise free for some other user application.
Blue: unread SMS or other phone message (image, video) (OK to be blue as these things are generally considered urgent and looked at immediately).
White: unread SMS + email (could be purple if green must be used for some independent function).
Off: You have cleared all your correspondence, well done! You have defeated the modern world!

Any thoughts on this scheme? Particularly, are there any aspects of the hardware that I have misunderstood so much as to demand a change to the scheme? What unmissable indicator do I miss?

 

[levi]

FWIW, I have a bluetooth joypad which has a single set of indicator LEDs (it's one of the 8bitdo ones ED's shop sells) and I can never remember what mode is what colour, or even what colour is 'on charge' and what is 'fully charged'. I don't use it all that regularly, so it may be better with the Pyra that I'm likely to be using far more regularly, but at the same time, if there's too much to remember I probably won't remember any of it.

I do quite like the idea of using the red, green and blue channels of a single LED as for example, power indicators for wi-fi, BT, GSM, with secondary colours created by more than one of them being on at the same time. I know that magenta is red and blue, so I just need to be able to remember what red and blue is in that instance.

Edit: And it may be the case that I still forget what the colours mean, but as long as LED on any colour means something's consuming battery power, for example, then I can always open the lid and look at the screen to figure out what it is, I guess.

 

[Grench]

One, two or both...

Lets first label the LEDs. These names should be replaced with whatever is officially in the system. Consider them naming placeholders for now.

top/lid LED 1 = T1
top/lid LED 2 = T2
keyboard left LED = KL
keyboard center/power LED = KC
keyboard right LED = KR

Obviously when the lid is open, the user is assumed to be able to see the KL, KC and KR LEDs. In that state power is displayed on the KC.

It makes sense for the T1 & KL to mirror functions and T2 and KR to mirror functions (at least by default). But what to do with KC? A possible 'simple' answer would be to have a virtual TB (Top Both) that performs the actions of KC on -both- of the lid lights simultaneously. The other momentary status flashes can override this - then default back to the 'power state' that would show on TB (both).

That would eliminate 'loosing' one of the top/lid LEDs to a relatively unexciting power status display.

 

[sulu]

Don't forget the color blind people !
I don't know which sequence/combination to avoid, maybe someone knows here ?

I'm by far not color blind, but I have somewhat impaired red/green vision. I prefer primary colors and clear contrasts when colors are meant to convey information.
From my POV, if you use HSV color space and assume maximum value, then signals with different meanings should be separated by at least 60 degree in hue or 0.5 in saturation. If you reduce value by factor X, then you should increase hue or saturation by the same factor.

 

[Kippykip]

I'd prefer a SD reading light and a battery light.
Wireless blinking isn't that important for me, but maybe there could be options I don't know...