Sense HAT RGB values limitation?

[philuk2000]

Hi,

I'm using the following code to iterate through the RGB values to light an LED. What I noticed is that unless any of the given R, G or B values reach 50 the LED does not light up, as soon as it hits 50 it turns on and when it falls below 50 it goes off again. This happens for any of the R, G or B lights on any LED in the array.

Code: Select all

from sense_hat import SenseHat
import time
sense = SenseHat()

sense.clear()

pixcol = 0

while True:
    while pixcol < 255:
        print('Count: ', pixcol)
        sense.set_pixel(0,1,0,pixcol,0)
        pixcol += 1
        time.sleep(.1)
        
    while pixcol > 0:
        print('Count: ', pixcol)
        sense.set_pixel(0,1,0,pixcol,0)
        pixcol -= 1
        time.sleep(.1)

I would have expected the LED to gradually get brighter from 0 to 49, the same way it does from 50 to 255.

Is this expected behaviour, a limitation or do I have a faulty Sense HAT?

[bensimmo]

I think the value is altering the current into the LED and at a point it will not light. I guess you are seeing it is 50 on yours.

I can check on mine but i though it was different to that.

But from the 4 I have, that is normal behaviour.

There is a lowlight and gamma function I've not used and it doesn't explain (to me anyway) what and why the low light mode actually does when it toggle etc...
https://pythonhosted.org/sense-hat/api/

The tech specs are hidden (as is usual for this things on here) in blog posts.
https://www.raspberrypi.org/blog/astro-pi-tech-specs/
If you understand it but it does not give a direct range they can be used w.r.t. values.
(There is nothing on the product page to note unfortunately, no specs or details http://www.raspberrypi.org/products/sense-hat/ )
More details function of the LEDs noted here https://www.raspberrypi.org/blog/buy-th ... -in-space/

[alphanumeric]

Low light, I believe, switches it to half of what ever brightness you have it at. It's either that or it sets it to 128. I have my sense hat joystick setup to go to low light when pressed down, and back to full when pressed up. Indoor outdoor, hi beams low beams, lol.

[Davespice]

Yeah the gamma functions were put in just before the Astro Pi mission started. ESA required us to give it a dimming function because the ISS is really dark and dingy and full brightness would dazzle the crew

[DaddyTheRunner]

Since I could only find limited documentation on the gamma functions mentioned by Davespice, I did a little experimentation with changing the gamma values. The gamma profile determines the "cutoff" value you observed (i.e 50 in your case). Increasing the lower values in the gamma list allows you to turn pixels on with smaller RGB values.

If you want to experiment with different gamma profiles, you can use the following code to fill the LED array with values from 0 to 64:

Code: Select all

from sense_hat import SenseHat
sense = SenseHat()
pixels = [3*[c] for c in range(64)]
sense.set_pixels(pixels)

With the default gamma profile, only the bottom two rows (i.e. largest RGB values) light up. A linear gamma profile will light up all but the top row (i.e. smallest RGB values). The following code demonstrates this:

Code: Select all

gammaProfile = [i for i in range(32)]
sense.gamma = gammaProfile

You can easily reset the gamma profile to the "factory default" using the following command:

Code: Select all

sense.gamma_reset()

The default gamma profile is:

Code: Select all

[0, 0, 1, 1, 1, 1, 1, 1, 2, 2, 3, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 17, 18, 20, 21, 23, 25, 27, 29, 31]

My question for the community is:

Why would you want to use a non-linear gamma profile over a linear profile?

[barny]

The RGB values displayed by the SH are in the range 0-255 so as you are only using 0-63 you aren't displaying the full brightness range in your code, so that is the reason so few LEDs light up with the default gamma.

This code below uses range 0-255 and toggles between (numerically) 'linear' gamma and the default (i.e. non-numerically-linear) gamma so it is easier to compare.

I'm no expert, but I believe the reason for non-numerically-linear default gamma is that the eye's sensitivity to light is not linear, and gamma is used to correct for this: the default gamma curve should make you (your eyes) perceive "linear" increases in the display brightness with "linear" increases in RGB value. The curve starts off slowly so it may appear that the display is underutilized at low brightness, but as the display only has 16-bit colour intensity resolution that's JTWIW. My perception is that with numerically linear gamma yes more LEDs are glowing but there are a lot of similar brightness LEDs at the bright end of the range, whereas with the default gamma this isn't so marked. Of course with either curve the change from off to 'dimmest' is the same.

Code: Select all

import time

from sense_hat import SenseHat

sense = SenseHat()
pixels = [3*[c] for c in range(0,256,4)]
sense.set_pixels(pixels)

while True:
    print "default gamma"
    time.sleep(2)
    print "linear gamma"
    gammaProfile = [i for i in range(32)]
    sense.gamma = gammaProfile
    time.sleep(2)
    sense.gamma_reset()

[barny]

I wonder it if might be possible to get better colour resolution by pulse-width modulating the LED drivers.

Just thinking about getting better than 16-bit colour rendition, let's guess the current scan rate is 80Hz, each column is active for 12.5ms, and the current drivers can modulate the LED brightness to 64 levels (according to the LED2472G datasheet) - probably with some mapping to get matching brightness levels from the RGB outputs (that will account for the sensehat's 5,6,5 bits of RGB resolution) by varying the current in the LED2472 driver.

However let's say that within the 12.5ms a column is active, the output was further updated on/off at four possible points that would give some more bits of brightness control - for the Green which has six bits resolution the first level that produces any ouput is 4, but I could get a level 1 by outputting 4 for a quarter of the active time, similarly 2 as a half of four, and 3 as a quarter of 12. I would get level 5 using a quarter of 20, 6 by a half of 12, couldn't do level 7, 9 by a quarter of 36, 10 by a half of 20, 11 by a quarter of 44, and so on. Gets harder for higher numbers, but this scheme does seem like it could give more control at low brightness. If instead of having four points we had eight, that would mean more levels were possible, for example 7 would be an eighth of 56.

Or instead of on-off, could modulate between two levels. So you could get level 7 (average) by displaying 8-8-8-4 - that would make it easier to work out the displayed values because with this approach the actual output levels are the mutliple of four below and above, in this example. I suppose this is just averaging at a higher scanning rate, no indication that the LED driver can't do it, AFAICT the update rate is determined by how fast the AVR can drive it.

Any AVR experts out there want to try updating the display code https://github.com/raspberrypi/rpi-sense? At the moment the routines output the 5- or 6-bit current value then wait for the scan time to finish. The scan rate would have to be quadrupled, or octupled, which should just be an update to the timer initialization, more complex is working out how each requested value maps to actual drive outputs, looks that that will need some extra data generating. An easy way of doing it for the two-level modulation, assuming the outputs are already straight 8-bit values per LED, would be to increment the value each time it is output. So 7 would become 8/9/10 on the following outputs, automatically outputting the correct average of 4/8/8/8. Makes sense to me, anyway.

[jdb]

Regarding driver PWM:

Yes, but: (tm)

Currently, LED duty cycles are programmed via the Atmel in a bit-bashed SPI protocol. The current drive is only settable per-bank (i.e. R / G / B) so it is set to a constant value (lowest in range, actually) and left as-is. The data register (output enable per-LED) is used via repeated writes to enact PWM.

The critical parameter is how often you can update the data register, which is a function of the clock speed of the Atmel. If you add an extra step to drive the reference current to a different value during the PWM cycle, you dramatically slow down the maximum column scan rate. We're at ~80hz for a 8MHz internal oscillator, slowing this down will produce noticeable flicker.

Plus there's gamma correction. Doubling the current of a low PWM value will not result in the same intensity change as a doubling of current at a high PWM value.