Musicians have an array of electronic tools at their disposal to help make music these days. Some of these are instruments in and of themselves, and [Wai Lun] — inspired by the likes of Choke and Shawn Wasabi — built himself a midi fighter
Midi fighters are programmable instruments where each button can be either a note, sound byte, effect, or anything else which can be triggered by a button. [Lun]’s is controlled by an ATmega32u4 running Arduino libraries — flashed to be recognized as a Leonardo — and is compatible with a number of music production programs. He opted for anodized aluminum PCBs to eliminate flex when plugging away and give the device a more refined look. Check it out in action after the break!
As this clock’s creator admits, it took far more than five minutes to put together, but it does display the time in five minute increments.
After acquiring five 4-character, 16 segment display modules that were too good to pass up, they were promptly deposited in the parts pile until [JF] was cajoled into building something by a friend. Given that each display’s pins were in parallel, there was a lot of soldering to connect these displays to the clock’s ATMega328P brain. On the back of the clock’s perfboard skeleton, a DS1307 real-time clock and coin cell keep things ticking along smoothly. The case is laser cut out of acrylic with an added red filter to up the contrast of the display, presenting a crisp, crimson glow.
Troubleshooting — as well as procrastination — proved to be the major stumbling block here. Each of the displays required extensive troubleshooting because — like Christmas lights of yore — one bad connection would cause all the other displays to fail. Furthermore, there isn’t any easy way to change the time, so the clock needs to be reprogrammed once in a while
[Big Fish Motorsports] has a vehicle with an adjustable rear spoiler system that broke in the lead up to a big race. The original builder had since gone AWOL so the considerable talents of [Quinn Dunki] were brought to bear in getting it working again.
Cracking open the black control box of mystery revealed an Arduino, a ProtoShield and the first major road block: the Arduino remained stubbornly incommunicado despite several different methods of trying to read the source code. Turns out the Arduino’s ATMega324 was configured to be unreadable or simply fried, but an ATMega128 [Quinn] had proved to be a capable replacement. However, without knowing how the ten relays for this spoiler system were configured — and the race day deadline looming ever larger — [Quinn] opted to scrap the original and hack together something of her own design with what she had on hand.
[Blecky]’s entry to the Hackaday Prize is MappyDot, a tiny board less than a square inch in size that holds a VL53L0X time-of-flight distance sensor and can measure distances of up to 2 meters.
MappyDot is more than just a breakout board; the ATMega328PB microcontroller on each PCB provides filtering, an easy to use I2C interface, and automatically handles up to 112 boards connected in a bus. The idea is that one or a few MappyDots can be used by themselves, but managing a large number is just as easy. By dotting a device with multiple MappyDots pointing in different directions, a device could combine the readings to gain a LiDAR-like understanding of its physical environment. Its big numbers of MappyDots [Blecky] is going for, too: he just received a few panels of bare PCBs that he’ll soon be laboriously populating. The good news is, there aren’t that many components on each board.
It’s great to see open sourced projects and tools in which it is clear some thought has gone into making them flexible and easy to use. This means they are easier to incorporate into other work and helps make them a great contestant for the Hackaday Prize.
A self-balancing robot is a great way to get introduced to control theory and robotics in general. The ability for a robot to sense its position and its current set of circumstances and then to make a proportional response to accomplish its goal is key to all robotics. While hobby robots might use cheap servos or brushed motors, for any more advanced balancing robot you might want to reach for a brushless DC motor and a new fully open-source controller.
The main problem with brushless DC motors is that they don’t perform very well at low velocities. To combat this downside, there are a large number of specialized controllers on the market that can help mitigate their behavior. Until now, all of these controllers have been locked down and proprietary. SmoothControl is looking to create a fully open source design for these motors, and they look like they have a pretty good start. The controller is designed to run on the ubiquitous ATmega32U4 with an open source 3-phase driver board. They are currently using these boards with two specific motors but plan to also support more motors as the project grows.
We’ve seen projects before that detail why brushless motors are difficult to deal with, so an open source driver for brushless DC motors that does the work for us seems appealing. There are lots of applications for brushless DC motors outside of robots where a controller like this could be useful as well, such as driving an airplane’s propeller.
I am a crappy software coder when it comes down to it. I didn’t pay attention when everything went object oriented and my roots were always assembly language and Real Time Operating Systems (RTOS) anyways.
So it only natural that I would reach for a true In-Circuit-Emulator (ICE) to finish of my little OBDII bus to speed pulse generator widget. ICE is a hardware device used to debug embedded systems. It communicates with the microcontroller on your board, allowing you to view what is going on by pausing execution and inspecting or changing values in the hardware registers. If you want to be great at embedded development you need to be great at using in-circuit emulation.
Not only do I get to watch my mistakes in near real time, I get to make a video about it.
Getting Data Out of a Vehicle
I’ve been working on a small board which will plug into my car and give direct access to speed reported on the Controller Area Network (CAN bus).
To back up a bit, my last video post was about my inane desire to make a small assembly that could plug into the OBDII port on my truck and create a series of pulses representing the speed of the vehicle for my GPS to function much more accurately. While there was a wire buried deep in the multiple bundles of wires connected to the vehicle’s Engine Control Module, I have decided for numerous reasons to create my own signal source.
At the heart of my project is the need to convert the OBDII port and the underlying CAN protocol to a simple variable representing the speed, and to then covert that value to a pulse stream where the frequency varied based on speed. The OBDII/CAN Protocol is handled by the STN1110 chip and converted to ASCII, and I am using an ATmega328 like found on a multitude of Arduino’ish boards for the ASCII to pulse conversion. I’m using hardware interrupts to control the signal output for rock-solid, jitter-free timing.
Walk through the process of using an In-Circuit Emulator in the video below, and join me after the break for a few more details on the process.
Here’s a slick-looking VGA demo written in assembly by [Yianni Kostaris]; it’s VGA output from an otherwise stock ATmega2560 at 16MHz with no external chips involved. If you’re getting some Super Mario Kart vibes from how it looks, there’s a good reason for that. The demo implements a form of the Super Nintendo’s Mode 7 graphics, which allowed for a background to be efficiently texture-mapped, rotated, and scaled for a 3D effect. It was used in racing games (such as Super Mario Kart) but also in many others. A video of the demo is embedded below.
[Yianni] posted the original demo a year earlier, but just recently added detailed technical information on how it was all accomplished. The AVR outputs VGA signals directly, resulting in 100×120 resolution with 256 colors, zipping along at 60 fps. The AVR itself is not modified or overclocked in any way — it runs at an entirely normal 16MHz and spends 93% of its time handling interrupts. Despite sharing details for how this is done, [Yianni] hasn’t released any code, but told us this demo is an offshoot from another project that is still in progress. It’s worth staying tuned because it’s clear [Yianni] knows his stuff.
