An electronic tachometer is a straightforward enough device, in which the light reflections from a white spot on a rotating object are detected and counted over time, measuring the revolutions per minute (RPM). It’s a technique that has its roots in analogue electronics where the resulting pulses would have fed a charge pump, and it’s a task well suited to a microcontroller that simply counts them. But do you need an all-singing, all-dancing chip to do the job? [Stefan Wagner] has done it with a humble ATtiny13.
His TinyTacho is a small PCB with an IR LED and photodiode on one end, a small OLED display on its front, and a coin cell holder on its rear. The electronics may be extremely simple, but there’s still quite some effort to get it within the ATtiny’s meagre resources. Counting the revolutions is easy enough, but the chip has no I2C interface of its own and some bitbanging code is required. You can find all the design files and software you need in a GitHub repository, and he’s put up a video of the device in action that you can see below the break.
Tachometers are a popular project hereabouts, and we’ve featured a lot of them over the years. Perhaps the best place to direct readers then is not to another project, but to how to use a tachometer.
First-timers playing with 8-bit micros such as the AVR and PIC will at some point in their lives, find themselves locked out of their MCUs. This is usually attributed to badly configured fuses that disable certain IO functions rending the device unprogrammable via conventional ICSP methods. [Uri Shaked] shares his story of how his ATtiny85 got locked and became the subject of a lengthy investigation into fuse bit configurations.
[Uri]’s journey started when he accidentally left some pins of the device connected to a second board while he was flashing the firmware. He quickly researched online for a solution for the problem and it turns out, there are a number of recipes to resolve the issue. As it turns out, his problem was not so straight-forward and warranted more digging. [Uri] ended setting up a High Voltage Programming serial programming setup and then probing the communications. He discovered that the chip refused to reset its fuses and would reject attempts to set fuses.
Further investigation of the fuse bits and reading them proved useful in understanding that the memory protection features were preventing alteration of the device. The quick-fix was to erase the ATtiny and things were back to normal thereafter. [Uri] details his pursuit of reading and comparing fuse bits from the impacted chip against a fresh device which is where he makes the discovery. The write-up is a case study in the investigation into the idiosyncrasies of device programming and will be a great resource for many and reduce hair loss for some.
When [Alain] wanted to use some of the new TinyAVR 0 chips — specifically, the Attiny406 — it seemed overkill to use the Windows IDE. There are plenty of sources of information on programming other AVR chips using simple command line tools, but not for these newer 0-series parts which use a new programming protocol known as UPDI. That led to a deep diving into how to program a TinyAVR 0 with a text editor, makefile, and USB-to-serial cable.
The Attiny406 has 4K of flash, 256 bytes of RAM and can run at 20 MHz with no external clock. You might think programming would be similar to a regular AVR part, but these tiny devices use UPDI (Unified Programming and Debug Interface) which uses 3 pins for programming. Older devices used different protocols.
It is very easy to create a UPDI programmer. A USB to logic-level serial cable and a 4.7K resistor is all it takes. There’s Python code that knows how to drive the protocol, too. You can also use the logic-level serial port on the Raspberry Pi with some device tree modifications explained in the code’s documentation.
[Alain] made a nice breakout board for the device. It fits a breadboard, allows for 5V or 3.3V operation, and has an LED and switch. Nothing fancy, but handy. Once you know how to ship a hex file to the chip, the rest is pretty standard. While the AVR version of gcc doesn’t cross-compile for the ATTiny out of the box, there is a device pack from Microchip that enables that feature.
The trend is to go to bigger processors, not smaller, but when you need to cram something in a small space, save a few pennies per unit, or draw very little power, these tiny processors can be just the ticket. The processors may be small, but if you work you can do some pretty big things with them.
If you own a laptop that’s got a few years on the clock, you’ve probably contemplated getting a replacement battery for it. Which means you also know how much legitimate OEM packs cost compared to the shady eBay clones. You can often get two or three of the knock-offs for the same price as a single real battery, but they never last as long as the originals. If they even work properly at all.
Which is why [Alexander Parent] decided to take the road less traveled and scratch built a custom battery for his ThinkPad T420. By reverse engineering how the battery pack communicated with the computer, he reasoned he would be able to come up with an open source firmware that worked at least as well as what the the third party ones are running. Which from the sounds of it, wasn’t a very high bar. From a more practical standpoint, it also meant he’d be able to create a higher capacity battery pack than what was commercially available should he chose to.
A logic analyzer wired in between one of the third party batteries and a spare T420 motherboard allowed [Alexander] to capture all the SMBus chatter between the two. From there he wrote some Arduino code that would mimic a battery as a proof of concept. He was slowed down a bit by an undocumented CRC check, but in the end he was able to come up with a fairly mature firmware that even allows you to provide a custom vendor name and model number for your pack.
The code was shifted over to an ATtiny85, with a voltage divider wired up to one of the pins so it can read the pack voltage. [Alexander] says his firmware still doesn’t do a great job of reporting the actual battery capacity remaining, but it’s close enough for his purposes. He came up with a simple PCB design to hold the MCU and support components, which eventually he plans on putting inside of a 3D printed case that actually plugs into the back of his T420.
This project is obviously still in a relatively early stage, but we’re very interested to see [Alexander] take it all the way. The ThinkPad has long been the hacker’s favorite laptop, and we can think of no machine more worthy of a fully open hardware and software battery pack.
To be clear, of course there’s a blade. They aren’t magic, obviously. The fan is just small, and hidden inside the base. Air is pulled from the sides and bottom, and into the ring mounted to the top of the unit. When the air eventually exits the thin slit in the ring, it “sticks” to the sides due to the Coandă effect and produces a low pressure zone in the center. That’s all a fancy way of saying that the air flow you get from one of these gadgets is several times greater than what the little dinky fan would be capable of under normal circumstances. That’s the theory, anyway.
We can’t promise that all the physics are working as they should in this 3D printed version, but in the video after the break it certainly appears to be moving a considerable amount of air. It’s also quite loud, but that’s to be expected given it’s using a brushless hobby motor. To get it spinning, [Elite Worm] is using a Digispark ATtiny85 connected to a standard RC electronic speed control (ESC). The MCU reads a potentiometer mounted to the side of the fan and converts that to a PWM signal required by the ESC.
Beyond the electronics, essentially every piece of this project has been printed on a standard desktop 3D printer. An impressive accomplishment, though we probably would have gone with a commercially available propeller for safety’s sake. On the other hand, the base of the fan should nicely contain the shrapnel created should it explode at several thousand RPM. Probably.
[Greg] loves hacking his bow ties. Back in high school, he added some bright RGB LEDs to the bow tie he wore to prom and even won the male best-dressed award. Recently he decided to try another bow tie hack, this time giving his tie some retro arcade game feels.
He decided to use an ATtiny85 and to experiment doing some more lower-level programming to refresh his skills. He wrote all his libraries from scratch which really helped him learn a lot about the ATtiny in the process. This also helped him make sure his code was as efficient as possible since he had quite a bit of memory constraints using the ATtiny85 (only 512 bytes of RAM).
He designed the body of the bow tie with wood. He fit all the electronics inside the body while allowing the ATtiny to protrude out of the body giving his bow tie some wanted hacker aesthetic. Of course, he needed to access the toggle switch to play the game, so he made a slot for that as well.
[Mitxela]’s repair of a Roland JV-1080 (a rack-mounted 90s-era synthesizer) sounds simple: replace a broken rotary encoder on the front panel. It turned out to be anything but simple, since the part in question is not today’s idea of a standard rotary encoder at all. The JV-1080 uses some kind of rotary pulse switch, which has three outputs (one for each direction, and one for pushing the knob in like a button.) Turn the knob in one direction, and one of the output wires is briefly shorted to ground with every detent. Turn it the other way, and the same happens on the other output wire. This is the part that needed a replacement.
The finished unit uses a modern rotary encoder and microcontroller in place of the original part, and implements a few tricks to power it.
Rather than track down a source for the broken part, [Mitxela] opted to replace it with a modern rotary encoder combined with an ATtiny85 microcontroller to make it act like something the JV-1080 understands and expects. There was an additional wrinkle, however. The original rotary pulse switch is an entirely passive device, and lives at the end of a four-conductor cable with no power provided on it. How could the ATtiny85 be powered without resorting to running a wire to a DC voltage supply somewhere? Success was had, but it did take some finessing.
For the power, it turns out that the signal wires are weakly pulled up to +5 V and [Mitxela] used that for a power supply to the microcontroller. Still, by itself that wasn’t enough, because the ATtiny85 can easily consume more current than the weak pullups can source. We really recommend reading all the details in [Mitxela]’s writeup, but the short version is that the ATtiny85 does two things.
First, it minimizes its power usage by spending most of its time in sleep mode (consuming barely any power at all) and uses an interrupt to wake up just long enough to handle knob activity. Second, the trickle of power from the weak pullups doesn’t feed the ATtiny directly. It charges a 100 uF capacitor through a diode, and that is what keeps the microcontroller from browning out during its brief spurts of activity. Even better, after browsing the datasheet for the ATtiny, [Mitxela] saw it was possible to use the built-in ESD protection diodes for this purpose instead of adding a separate component.
It’s a neat trick and makes for a very compact package. Visit the project’s GitHub repository to dive into the nitty gritty. In the end, a single assembly at the end of a 4-wire connector acts just like the original passive component, no extra wires or hardware modifications needed.
When opening older hardware it’s never quite certain what will be found on the inside. But at least [Mitxela]’s repair duties on this synth didn’t end up with him tripping out on LSD.
