Introducing ColorHug ALS

Ambient light sensors let us change the laptop panel brightness so that you can still see your screen when it’s sunny outside, but we can dim it when the ambient room light level is lower to save power.

colorhug-als1-large

I’ve spent a bit of time over the last few months designing a small OpenHardware USB device that acts as a ambient light sensor. It’s basically an uncalibrated ColorHug1 design with a less powerful processor, but speaking a subset of same protocol so all the firmware update and test tools just work out of the box.

colorhug-als2-large

The sensor itself is a very small (12x22mm) printed circuit board that inserts directly into a spare USB socket. It only sticks out about 9mm from the edge of the laptop as most of the PCB actually gets pushed into the USB slot.

colorhug-als-pcb-large

ColorHugALS can currently control the backlight when running the colorhug-backlight utility. The Up/Down header buttons do the same as the hardware BrightnessUp and BrightnessDown keys. You can still set the absolute backlight so you’re in control of the absolute level right now, the ALS modifying the level either side of what you just set in the coming minutes. The brightness is modified using a exponential moving average, which makes the brightness changes smooth and unnoticeable on hardware with enough brightness levels.

colorhug-backlight-large

We also use the brightness value at start to be what you consider “normal” so the algorithm tries to stay out of the way. When we’ve got some defaults that work well and has been tested the aim is to push this into gnome-control-center and gnome-settings-daemon for GNOME 3.18 so that no additional software is required.

I’ve got 42 devices in stock now. Buy one here!

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

10 thoughts on “Introducing ColorHug ALS”

  1. I’ve ordered one. I’ve been very happy with my ColorHug, and offered no feedback whatsoever because it just worked. Looking forward to maybe being a bit more helpful this time.

    Have you considered also performing colour temperature adjustments, like “redshift”? There are other issues to consider (a dark room during the day doesn’t necessarily mean you need a lower temperature), but it seems related enough that it would be nice to avoid running another screen adjustment tool.

  2. Great! Thanks for your work. I have an Dell XPS with integrated ambiance sensor. I’d love to see if this gets supported one day. Do you see any chance for this? Adding an other device would be a kind of redundancy.

    1. I’ve not got a Dell with an ALS sensor myself, but I’m hoping with more software using the sensors the kernel hackers will get to work and provide us some data :)

  3. Great job! My question is similar to @peter’s one. In my case I have a MacBook Pro with integrated ambiance sensor, but if I type a # lsusb this is not a USB device (I not very sure what kind of device is) because is not listed, just USB hubs, IR, Bluetooth o WiFi devices. I have been diving into the Color Hug Utilities code and I found that is only compatible USB devices hence, do you think that a dummy USB port or something similar could help to make it compatible? I know a pair projects[1][2] that solves (partially) the keyboard/screen brightness problem. But thees projects does not fit for me I want to see something integrated with Gnome or kernel that works in a generic way.

    Thanks!

    [1] https://github.com/poliva/lightum
    [2] https://github.com/Janhouse/lighter

    1. Well, the backlight utility is compatible with kernel class devices and USB devices, and soon it’ll be compatible with iio devices too. I’m not sure this helps you much until someone has reverse engineered the driver.

      1. Thanks for the response. Taking a look into the code of mentioned projects I realized that is pretty easy to get or set the brightness with this: cat ‘/sys/class/leds/smc::kbd_backlight/brightness’ and it returns a double value if I’m not wrong. So, why we need do reverse engineering? Maybe just with normalize/standardize the values could solve the problem? I’m not sure… but thanks again.

  4. How did you handle EMV tests? Was not having a fully closed enclosure an issue?

    1. The PIC I chose is quite resilient to ESD, and USB port controllers are (should be!) immune. From a business point of view, there was no way to get a custom ABS mold for this; initial estimates are in the thousands of dollars area which for a product line that’s going to struggle to break even isn’t something I could consider. I’d be interested if anyone does something using 3D printing, I’ve always wanted a machine but couldn’t justify the NRE. There’s also no CCC or CE testing done, again due to the cost of getting these done.

  5. I ordered one simply because I was so happy with the ColorHug. I am eager to see if it helps with the Asus’ moderate battery life. I was happy to see my order was dispatched the next day. Good luck with this and I look forward to more fine Hughski products :)

Comments are closed.