Ask Hackaday: Whatever Happened To LED Light Sensors?

If you’re a long-time Hackaday reader like we are, you’ll certainly remember a rash of projects from around ten years ago that all (mis-)used an LED as a light sensor. The idea wasn’t new, but somehow it made the rounds and insinuated itself into our collective minds. Around the same time, a cryptographic cipher with an exceptionally small memory footprint was also showing up in hacker projects: TEA (Tiny Encryption Algorithm).

This old project by [Marcin Bojanczyk], [Chris Danis], and [Brian Rogan] combines both the LED-as-light-sensor meme and TEA to make a door-entry keyfob that works over visible light. And they do so using almost nothing — a few LEDs and just over 2Kb of code. It’s pretty sweet.

Which brings us to the question: where are they (LED-sensors and TEA) now?

ledtouch_photoLED-as-light-sensor was just cool. We certainly loved the idea back in 2006. But [Forrest Mims] had been using the phenomenon for decades back then. It certainly makes sense when you’re trying to squeeze as much as possible out of as little as possible, or when budget is a main concern and you just can’t afford an extra photodiode.

But our own experience with LEDs as light sensors is that the results are extremely variable across different LEDs. Code that works with water-clear red LEDs might not work with the ones that come in red-tinted plastic, for instance. Is that why they went extinct?
4746123271_7888160588Similarly, the TEA family of ciphers showed up in a bunch of projects around this time, from the badge for the HOPE conference in 2010 to a widely used RFM12B radio library. There are a couple of attacks on XXTEA, but they only affect reduced-round versions of the cipher, and rely on a tremendous amount of intercepted data — more than we’d see in a home-automation network over years.

Over the last five years or so, there’s been a lot more Internet of Things, which means using standard Internet-style encryption methods (AES and so on) that are widespread on non-memory-constrained computers. Is that what happened to XXTEA?

Anyway, we got tipped off to a project that combined a few of our favorite (old) ideas in one, so we thought that we’d share. Thanks [Blue Smoke] for the walk down memory lane. Any of you out there keeping the flame(s) alive? Have you used sensing LEDs or XXTEA? Are those projects still going, or do you have any future projects planned with these tricks still up your sleeve? Let us know in the comments below.

17 thoughts on “Ask Hackaday: Whatever Happened To LED Light Sensors?

  1. What is the point of an LED touchpad, now that you can have a cheaper PCB copper trace touchpad? Every MCU supplier now has either software or hardware touch sensing even in the low-cost devices.

  2. I did some research on the LED matrix as a sensor for classwork shortly after I first saw that video from that professor at NYU. Basically, it sucks.

    You can’t use it to measure reflectance if there’s basically any ambient light at all; the LEDs-as-photodiodes all couple problematically even if all the leads are floating. I was able to use it to take low-resolution pictures of shadows in sunlight, though.

    If you are in a dark room, so that you can measure reflectance, you need to emit too much light to really use it as a simultaneous display.

  3. An attack on TEA was what made the hack of the Xbox v1.1 possible. Microsoft used it as a hash function to validate part of the boot ROM- the MCPX chip held the first 512 bytes of the boot ROM’s address space, and served as a securely unalterable start for the Xbox’s boot process. The hackers were able to figure out how to flip a couple of cleverly-chosen bits in the rest of the boot ROM (in a separate flash chip) without changing the hash value, which allowed them to alter a jump instruction to skip over validating the rest of the ROM with a better, less space-constrained algorithm.

  4. Yep, did some fun work on LED sensors. They can kind of work as photodiodes, but only kind of, making them useless under ambient light. Also, they use a lot of power. Also, it’s a ton of work to get the displays to show graphics and detect touch at the same time. Also, the resolution isn’t very good in many applications. Also, I can get an LCD with a touchscreen for like, nothing these days.

    So yeah, they kind of…suck. But it was fun.

  5. I’m using 64 rounds of XTEA and then 16 rounds of AES-128 single block encryption of a 32 byte struct for nRF_Detekt. Oh got a 317 powersupply for you too Elliot (it’s a trivial addition these days), since you were crying about that last time of people just using power straight from Arduino board. Now I can’t easily mount the LCD on top of the proto board then.

  6. I have created an optimal Arduino library ( from XXTEA encryption using the more proven XXTEA-II program ( This library works for both ESP8266 Arduino and conventional Arduino Uno. Memory footprint is optimized to help use it for IoT applications. As mentioned, I will add a repeated cypher option for number of rounds into the API. This library is officially released so any one can easily integrate into their projects under CC-BY-SA.

  7. How about machine to machine communication using leds only?

    This device demonstrates entity to entity led emission and detection using leds only. The led on-time is randomly chosen using pll jitter, the direction the leds rotate is also selected randomly using pll jitter. The hysteresis of each device was tweaked so that its rarely (but still) possible all devices will turn off. Requiring external light stimulation. Red emission is the only wavelength activated on these rgb leds, the other colors for led detection are possible but require more work on the program to tweak the difference in photon gate falloff charge, for blue, i found that assembly level code is needed.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.