The tail light is based around SMD LEDs, mounted in acrylic to diffuse the light. The construction is beautiful, using custom PCBs and carefully machined acrylic to match the lines of the bike.
As far as warning lights go, a brighter light will be more obvious in the day time, but could actually hinder visibility at night by blinding other road users. To this end, [Josh] built the tail light around an ATtiny 45, which could be programmed with various routines to optimise the light level depending on ambient conditions. Another feature is that the light’s brightness pulses at high frequency in an attempt to attract the eye. Many automakers have experimented with similar systems. The ATtiny controls the lights through a PCA9952 LED controller over I2C. This chip has plenty of channels for controlling a bunch of LEDs at once, making the job easy.
[ch00f] was searching for an idea to build for his father this Christmas, and cast his gaze across those novelty phone charging cables that have “flowing” LEDs along their length. Not one to stick to the small scale, he set out to create a flowing LED effect for a Tesla EV charger.
The basic components behind the build are a current transformer, a NeoPixel LED strip, and an ATtiny44 to run the show. But the quality of the build is where [ch00f]’s project really shines. The writeup is top notch — [ch00f] goes to great lengths showing every detail of the build. The project log covers the challenges of finding appropriate wiring & enclosures for the high power AC build, how to interface the current-sense transformer to the microcontroller, and shares [ch00f]’s techniques for testing the fit of components to ensure the best chance of getting the build right the first time. If you’ve ever gotten a breadboarded prototype humming along sweetly, only to suffer as you try to cram all the pieces into a tiny plastic box, you’ll definitely pick something up here.
[Tim]’s Dice10 is an exercise in minimalism. Building an electronic dice using an ATtiny10 with code that fits within 1kB is not too difficult. Charlieplexing the LED’s would have used three of the four available GPIO pins. [Tim] upped the game by using just two GPIO pins to drive the seven LED’s for the dice. A third GPIO is used as a touch button input. Besides the ATtiny and the LED’s, the only other component used is a capacitor across the supply inputs.
The LED’s are grouped in three pairs of two LED’s and a single centre LED. Usually, Charlieplexed LED’s are connected across pairs of GPIO pins. But his scheme includes connections to the 5V and GND terminals, besides the two GPIO pins. Building a truth table makes it easy to figure out what’s going on.
STATE PB2 PB0 LED's
1 Z Z --
2 L Z LED 1/2
3 H Z LED 3/4
4 Z L LED 5/6
5 Z H --
6 H L LED9
7 L H --
8 H H --
9 L L --
Only the logic states used are listed in the table. It’s possible to add two more LED’s between PB0 and GND and one more anti-parallel with LED9, making a total of 10 LED’s driven by two pins. That’s quite a hack. The important thing here is to have two LED’s in series in the arms that connect to either 5V or GND.
[Tim] has posted the code and hardware source files on his Github repo, and his blog post has some additional details on how he solved the problem.
If you’re looking for more inspirations on minimal dice designs, check this “PIC powered pair of electronic dice” which uses a PIC 12F629 with five outputs driving a pair of 7 pips to make a dual dice.
If you have a cool project in mind, there is still plenty of time to enter the 1 kB Challenge! Deadline is January 5, so check it out and fire up your assemblers!
DUO BINARY is a very, very small computer system in every possible sense. It runs on an ATtiny84, which has even got “tiny” in its name. The user interface is a single button for data entry and a single LED for feedback, making this binary keyboard look frivolously over-complicated. It uses a devilish chimera of Morse code and a truncated ASCII to enter data, and the LED blinks the same back at you.
[Newbrain] had a small problem. He’d turn off the TV, but would leave the sound system turned on. Admittedly, not a big problem, but an annoyance, none the less. He realized the TV had a USB port that went off when it did, so he decided to build something that would sense when the USB port died and fake a button press into the amplifier.
He posted a few ideas online and, honestly, the discussion was at least as interesting as the final project. The common thread was to use an optoisolator to sense the 5 V from the USB port. After that, everyone considered a variety of ICs and discretes and even did some Spice modeling.
In the end, though, [Newbrain] took the easy way out. An ATtiny 84 is probably overkill, but it easy enough to press into service. With only three other components, he built the whole thing into a narrow 24-pin socket and taped it to the back of the audio unit’s wired remote control.
[James Bellafaire] wanted a good looking old radio with a modern sound. Granted, you could hollow the case out and replace it with an iPod. Or you could convert the thing to an Internet radio. But where’s the fun in that?
[James] took a different approach. Part woodworking project, part Raspberry Pi project, and part microcontroller project, he wound up with a hard drive-based music player in a 1930’s case with knobs that control the playback.
You will probably be familiar with I²C, a serial bus typically used for not-very-fast communication with microcontroller peripherals. It’s likely though that unless you are an I²C wizard you won’t be intimately familiar with the intricacies of its operation, and each new device will bring a lengthy spell of studying data sheets and head-scratching.
If the previous paragraph describes you, read on. [Clint Stevenson] wrote a library for interfacing I²C EEPROMs to Arduino platforms, and when a user found a bug when using it on an ATtiny85, he wrote up his solution. The resulting piece is a clear explanation of how I²C EEPROMs talk to the bus, the various operations you can perform on them, and the overhead each places on the bus. He then goes on to explain EEPROM timing, and how since it takes the device a while to perform each task, the microcontroller must be sure it has completed before moving to the next one.
In the case of [Clint]’s library, the problem turned out to be a minor incompatibility with the Arduino Wire library over handling I²C start conditions. I²C has a clock and a data line, both of which are high when no tasks are being performed. A start condition indicates to the devices on the bus that something is about to happen, and is indicated by the data line going low while the clock line stays high for a while before the clock line starts up and the data line carries the I²C command. He’s posted samples of code on the page linked above, and you can find his library in his GitHub repository.