You really should learn to read Morse code. But if you can’t — or even if you can, and just want a break — you can always get a computer to do it. For example, [jmharvey1] has a decoder that runs on a cheap Bluepill dev board.

The device uses a touchscreen and a few common components. The whole thing cost about $16. You can see it at work along with a description of the project in the video below.

The code uses the Arduino-style setup for the Blue pill — something we’ve talked about before. As for the decoding method, the software employs the Goertzel algorithm which is akin to a single frequency Fourier transform. That is, while a full transform gives you information about the frequency component of a signal across a wide range, the Goertzel algorithm probes the signal for one or a small number of distinct frequencies.

The decoder table looks confusing at first until you realize that each “decode” value consists of a 1 as a start bit followed by a 1 for a dash and a zero for a dot. All bits to the left of the start bit don’t count. So an “E” codes as 02 hex — a start bit followed by a single zero or dot. A “C” is 1A hex (1 + -.-.). Once you find the matching code, you apply the same index to another table to look up the actual letter or string of letters.

If you buy a Bluepill to make one of these, you might as well get two and build something to send code, too.

There was a time when building realistic simulations of vehicles was the stuff of NASA and big corporations. Today, many people have sophisticated virtual cockpits or race cars that they use with high-resolution screens or even virtual reality gear. If you think about it, a virtual car isn’t that hard to pull off. All you really need is a steering wheel, a few pedals, and a gear shifter. Sure, you can build fans to simulate the wind and put haptics in your seat, but really the input devices alone get you most of the way there. [Oli] decided he wanted a quick and easy USB gear shifter so he took a trip to the hardware store, picked up an arcade joystick, and tied it all together with an Arduino Leonardo. The finished product that you can see in the video below cost about $30 and took less than six hours to build.

The Leonardo, of course, has the ability to act like a USB human interface device (HID) so it can emulate a mouse or a keyboard or a joystick. That comes in handy for this project, as you would expect. The computer simply has to read the four joystick buttons and then decide which gear matches which buttons. For example up and to the left is first gear, while 4th gear is only the down button depressed. A custom-cut wooden shifter plate gives you the typical H pattern you expect from a stick shift.

Of course, the joystick doesn’t have a long handle like a true stick shift, so [Oli] added some extensions. In addition, a real shifter doesn’t require you to hold it in position as a joystick would. To rectify this, the shifter plate has magnets that grab the stick and hold it. They aren’t strong enough that you can’t move the stick, but they are strong enough to keep it from moving on its own.

We noticed that the design doesn’t allow for a clutch, so it isn’t quite the same as driving a real stick. However, [Oli] mentions several upgrades he has in mind and a clutch is one of them. Some haptics would be a cool addition so could feel the gears grind if you didn’t do the shift correctly.

The last shifter we saw like this was 3D printed. It is getting harder to find a car in the US with a manual transmission, but [Kristina Panos] is definitely a fan.

Watching the advancement of technology is interesting enough by looking at improved specifications for various components as the years go by. But clock speeds, memory size, and power consumption are all fairly intangible compared to actual implementation of modern technology when compared to days of yore. For example, this $40 microcontroller can do what a video game console was able to do in the 80s for a tenth of the (inflation adjusted) price.

The NESDUE is an emulator for NES games which runs completely on an Arduino Due. The Arduino does have some limitations that have to be worked around to get the Nintendo to work, though. For one, it needs to be overclocked to be playable and it also needs a workaround to get past the memory limit of 96 kB of RAM. From there, a small screen is wired up along with a controller (from a Super Nintendo) and the gaming can begin.

This is an impressive feat for an Arduino platform to accomplish, especially with the amount of memory tweaking that has to happen. This might be the most advanced gaming system available that runs everything on an Arduino, right up there with the Arduinocade which can provide an arcade-like experience straight from the Arduino as well.

It is pretty well-known that I’m not a big fan of the Arduino infrastructure. Granted, these days you have more options with the pro IDE and Platform IO, for example. But the original IDE always gives me heartburn. I realized just how much heartburn the other day when I wanted to something very simple: increase the receive buffer on an ATmega32 serial port. The solution I arrived at might help you do some other things, so even if you don’t need that exact feature, you still might find it useful to see what I did.

Following this experience I am genuinely torn. On the one hand, I despise the lackluster editor for hiding too much detail from me and providing little in the way of useful tools. On the other hand, I was impressed with how extensible it was if you can dig out the details of how it works internally.

First, you might wonder why I use the IDE. The short answer is I don’t. But when you produce things for other people to use, you almost can’t ignore it. No matter how you craft your personal environment, the minute your code hits the Internet, someone will try to use it in the IDE. A while back I’d written about the $4 Z80 computer by [Just4Fun]. I rarely have time to build things I write about, but I really wanted to try this little computer. The parts sat partially assembled for a while and then a PCB came out for it. I got the PCB and — you guessed it — it sat some more, partially assembled. But I finally found time to finish it and had CP/M booted up.

The only problem was there were not many good options for transferring data back and forth to the PC. It looked like the best bet was to do Intel hex files and transfer them copy and paste across the terminal. I wanted better, and that sent me down a Saturday morning rabbit hole. What I ended up with is a way to make your own menus in the Arduino IDE to set compiler options based on the target hardware for the project. It’s a trick worth knowing as it will come in handy beyond this single problem.

The Issue: Arduino Serial Buffer Size Limit

I won’t bore you with the details about getting the board to work since you will only care if you have one. Details are available in a discussion on Hackaday.io, if you really want to follow it. But the upshot was that for XModem transfers, [Just4Fun] felt like the default Arduino serial buffer wasn’t big enough to be reliable. It did seem to work with the default 64-byte buffer, but XModem sends more data than that and it would be easy to imagine it getting overrun.

How hard can it be to update the buffer? In one way, it is trivial. In another way, it is very difficult because the tools want to help you so badly.

Tool Chain

The little computer project uses a real Z80 chip and uses an ATMega32A for almost all the support functions. It generates the clock, acts like a serial port, acts like a disk drive, and so on. However, the ATMega32 doesn’t directly have Arduino IDE support so you have to install a toolchain for it. The project called for MightyCore so that’s what I used.

The libraries for hardware serial were all set up using #define statements to allow you to adjust the buffer sizes. By default, if you haven’t set up anything, you get a default based on the amount of RAM your processor provides:

#if !defined(SERIAL_TX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_TX_BUFFER_SIZE 16
#else
#define SERIAL_TX_BUFFER_SIZE 64
#endif
#endif
#if !defined(SERIAL_RX_BUFFER_SIZE)
#if ((RAMEND - RAMSTART) < 1023)
#define SERIAL_RX_BUFFER_SIZE 16
#else
#define SERIAL_RX_BUFFER_SIZE 64
#endif
#endif

Making the Change

So this is easy, right? Just define those symbols before HardwareSerial.h loads. Uh oh. That file is loaded by Arduino.h. The IDE wants to add that to your program and it forces it to be first. There seems to be some IDE versions that check if you already included it so they don’t include it twice, but version 1.8.5 didn’t seem to do that. Maybe I can add some options in the preferences to pass to the compiler. Nope. Not via the IDE, anyway.

Not that I didn’t try a lot of things. It was tempting, of course, to simply change the core libraries. But that’s bad. You might want the defaults later. If you update the tool chain, you’ll lose your updates. I wanted to avoid that. Some people on the Internet suggested making a copy of the platform files and modifying those. Still not ideal.

Test Your Assumptions With Custom Error Reporting

I could tell things I tried were not working because I would put #if statements and #error statements temporarily in HardwareSerial.cpp. For example:

#if SERIAL_RX_BUFFER_SIZE==256
#error 256
#endif

Now if a compile causes an error 256, I know I was able to set the size. If not, then the system was resisting my changes.

Compromise: Adding Menu Options At the Board Level

I really wanted a way to make a change just in my project and set the serial buffer sizes. I failed at that. What I did do was make a modification to the boards.txt provided by Mighty Core. Yes, I will have to watch for upgrades overwriting my changes, but they are simple and it will be obvious that it is missing.

The reason it will be obvious is that I created a menu for the IDE that only appears when using ATMega32 for Mighty Core. This menu lets you select a few preset buffer sizes.

There were three parts to making this work:

1. You have to tell the IDE you have a menu item and what it looks like.
2. The new item needs to set some compiler options.
3. Because the existing system also sets some compiler options, you have to make sure not to clobber them.

The first part is easy. The boards.txt file was (for me) in ~/.arduino15/packages/MightyCore/hardware/avr/2.0.5/boards.txt. Near the top there’s a list of menu keys and I added mine to the end:

# Menu options
menu.clock=Clock
menu.BOD=BOD
menu.LTO=Compiler LTO
menu.variant=Variant
menu.pinout=Pinout
menu.bootloader=Bootloader
menu.SerialBuf=Serial Port Buffers (RX/TX)

Next, I moved down the file and added my menu before the existing LTO menu option for the ATMega32:

32.menu.SerialBuf.disabled=Default
32.menu.SerialBuf.disabled.compilerSB.c.extra_flags=
32.menu.SerialBuf.disabled.compilerSB.cpp.extra_flags=

32.menu.SerialBuf.SB64=64/64
32.menu.SerialBuf.SB64.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=64 -DSERIAL_TX_BUFFER_SIZE=64
32.menu.SerialBuf.SB64.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=64 -DSERIAL_TX_BUFFER_SIZE=64

32.menu.SerialBuf.SB128=128/128
32.menu.SerialBuf.SB128.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=128
32.menu.SerialBuf.SB128.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=128

32.menu.SerialBuf.SB12864=128/64
32.menu.SerialBuf.SB12864.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=64
32.menu.SerialBuf.SB12864.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=128 -DSERIAL_TX_BUFFER_SIZE=64

32.menu.SerialBuf.SB256=256/256
32.menu.SerialBuf.SB256.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=256
32.menu.SerialBuf.SB256.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=256

32.menu.SerialBuf.SB25664=256/64
32.menu.SerialBuf.SB25664.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=64
32.menu.SerialBuf.SB25664.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=64

32.menu.SerialBuf.SB25632=256/32
32.menu.SerialBuf.SB25632.compilerSB.c.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=32
32.menu.SerialBuf.SB25632.compilerSB.cpp.extra_flags=-DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=32

Menu Structure

You can see that the 32.menu object groups all the items together for this processor. The next part is our menu key (SerialBuf). After that is a unique key for each memory item. It is important that you don’t reuse these. So, for example, if you have two SB64 keys only one is going to work.

If you stop at that key and put an equal sign you can assign the menu item the text you want to display. For example “Default” or “64/64.” You can also extend the key with a property and that property will be set if the option is active.

So, for example, if you select 256/256 then the compilerSB.c.extra_flags property will get set. I made that name up, by the way, and you’ll see why in a minute.

Peaceful Coexistence

There is no property called compilerSB.c.extra_flags. The correct property is compiler.c.extra_flags. However, the Mighty Core LTO option uses the same key. That’s why it was important that the new menu appears first and also that it sets a fake property. Then the LTO code needs a slight modification:

# Compiler link time optimization
32.menu.LTO.Os=LTO disabled
32.menu.LTO.Os.compiler.c.extra_flags={compilerSB.c.extra_flags}
32.menu.LTO.Os.compiler.c.elf.extra_flags=
32.menu.LTO.Os.compiler.cpp.extra_flags={compilerSB.cpp.extra_flags}
32.menu.LTO.Os.ltoarcmd=avr-ar

32.menu.LTO.Os_flto=LTO enabled
32.menu.LTO.Os_flto.compiler.c.extra_flags={compilerSB.c.extra_flags} -Wextra -flto -g
32.menu.LTO.Os_flto.compiler.c.elf.extra_flags=-w -flto -g
32.menu.LTO.Os_flto.compiler.cpp.extra_flags={compilerSB.cpp.extra_flags} -Wextra -flto -g
32.menu.LTO.Os_flto.ltoarcmd=avr-gcc-ar

The big change is that each set of flags adds to whatever the new menu set in its custom property. This way, all the flags get put into the correct property, compiler.c.extra_flags.

I set up error traps to catch all the cases to make sure they were being set right. In addition, after removing those traps, I could see my memory usage go up accordingly.

Customize

Of course, you can modify the parameters if you want something different. You could also use this trick to set other parameters before the Arduino.h file takes over. There’s some documentation about how to set up the platform definitions, including boards.txt.

It would have probably been better for me to make a custom boards.txt file with the same information in it but then I’d need to take the rest of Mighty Core with me. Instead, I just keep a copy of the file called boards.txt.custom and if my menu disappears, I just have to compare that file with the boards.txt file to see what changed.

Of course, if you don’t have to support people using the IDE, maybe just give it up. The Pro IDE is better, even if it does have some shortcomings. Plus there’s always Platform.io.

There’s a reason why bowling lanes have bumpers and golf games have mulligans. Whether you’re learning a new game or sport, or have known for years how to play but still stink at it, everyone can use some help chasing that win. You’ve heard of the can’t-miss dart board and no-brick basketball goal. Well, here comes the robot-assisted game for the rest of us: cornhole.

The game itself deceptively simple-looking — just underhand throw a square wrist rest into a hole near the top of a slightly angled box. You even get a point for landing anywhere on the box! Three points if you make it in the cornhole. In practice, the game not that easy, though, especially if you’ve been drinking (and drinking is encouraged). But hey, it’s safer than horseshoes or lawn darts.

[Michael Rechtin] loves the game but isn’t all that great at it, so he built a robotic version that tracks the incoming bag and moves the hole to help catch it. A web cam mounted just behind the hole takes a ton of pictures and analyzes the frames for changes.

The web cam sends the bag positions it sees along with its predictions to an Arduino, which decides how it will move a pair of motors in response. Down in the cornhole there’s a pair of drawer sliders that act as the lid’s x/y gantry.

We love how low-tech this is compared to some of the other ways it could be done, even though it occasionally messes up. That’s okay — it makes the game more interesting that way. We think you should get 2 points if it lands halfway in the hole. Aim past the break to check out the build video.

Seems like there’s a robotic-assisted piece of sporting equipment for everything these days. If cornhole ain’t your thing, how’d you like to take a couple strokes off your golf game?

Thanks for the tip, [Itay]!

[Adam Welch] has built macro pads in the past out of pre-fab key matrices and handfuls of Cherry MX clones. But all the stickers and custom keycaps in the world wouldn’t make those macro pads as versatile as a stream deck — those visual shortcut panels with tiny touchscreens for each button that some streamers use to change A/V settings or switch between applications.

Let’s face it, stream decks are expensive. But 0.96″ OLED displays are not, and neither are SMD tactile buttons. Why not imitate a screen deck on the cheap by making it so the screens actuate buttons behind them? [Adam] based this baby on the clever design of [Kilian Gosewisch]’s FreeDeck, and they ended up working together to improve it with a dedicated PCB.

The brains of the operation is an Arduino Pro Micro, which addresses each screen individually via two 74HC4051 mux ICs. Thanks to an SD card module, there’s no need to flash the ‘duino every time you want to change a shortcut or its picture. Even if this deck doesn’t hold up forever, it won’t break the bank to build another one. Poke past the break for the build video, which has all the links you’d need to make your own, including a handy configurator.

There’s more than one way to do a visual macro pad. Here’s one that uses a single screen and splits it Brady Bunch style to match the matrix.

Thanks for the tip, [arturo182]!

Deep freezers are a great thing to have, especially when the world gets apocalyptic. Of course, freezers are only good when they’re operating properly. And since they’re usually chillin’ out of sight and full of precious goods, keeping an eye on them is important.

When [Adam] started looking at commercial freezer alarms, he found that most of them are a joke. A bunch are battery-powered, and many people complain that they’re too quiet to do any good. And you’d best hope that the freezer fails while you’re home and awake, because they just stop sounding the alarm after a certain amount of time, probably to save battery.

If you want something done right, you have to do it yourself. [Adam]’s homemade freezer failure alarm is a cheap and open solution that ticks all the boxen. It runs on mains power and uses a 100dB piezo buzzer for ear-splitting effectiveness to alert [Adam] whenever the freezer is at 32°F/0°C or above.

If the Arduino loses sight of the DHT22 temperature sensor inside the freezer, then the alarm sounds continuously. And if [Adam] is ever curious about the temperature in the freezer, it’s right there on the 7-segment. Pretty elegant if you ask us. We’ve got the demo video thawing after the break, but you might wanna turn your sound down a lot.

You could assume that the freezer is freezing as long as it has power. In that case, just use a 555.

If you want strangers to give you well wishes on your birthday out in the real world, you have call attention to the occasion by wearing a pointy hat or a button that says ‘today is my birthday, gimme presents’. But on your reddit cakeday, aka the day you joined, you’re automatically singled out with the addition of a slice of 8-bit cake next to your username. The great thing about your cakeday is that you’re almost guaranteed to get some karma for once, especially if you make something cakeday related like [ScottyD]’s cakeday countdown clock. But plenty of people forget what their cakeday is and miss out on the fun.

This countdown clock works like you might expect — every day that isn’t your cakeday, a message scrolls by with the number of days remaining until your next one. When the big day comes, the message becomes TODAY IS YOUR CAKE DAY. Both messages are bookended by cute little pixelated cake slices that we would apply liberally to the day-of message if we made one of these.

This simple but fun project shouldn’t put too big of a dent in your parts box, since it’s essentially an Arduino, a real-time clock module, and a 32×8 LED matrix to display the text. We love the uni-body design of the enclosure because it creates a shelf for the Arduino and gives easy access for gluing in the display from the rear. If for some reason you don’t reddit, then make one anyway and use it to count down to your IRL birthday or something. We’ve got the build video cut and plated for you to consume after the break.

We would understand if 2020 is supplying you with enough existential crises, but if not, consider building a clock that counts down the rest of your life expectancy.

Via r/duino

We’ve all been there. You’re manning the battle station, deep in the sim-racing or some other n00b-pwning zone and suddenly some loudmouth blows out your eardrums over Discord. It’s insulting to have to stop what you’re doing to find the right Windows volume slider. So why do that? Build [T3knomanzer]’s simple yet elegant multi-volume knob and stay zen in the zone.

It’s easy, just turn the knob to cycle through your programs until Discord comes up on the little screen, and then push down to change it into a volume knob. If you need to change another volume, just click it again. Since there’s no Alt+Tabbing out to the desktop, no checkered flags should ever slip through your fingers.

Inside the well-designed case you’ll find the usual suspects — Arduino Nano, rotary encoder, an OLED display, and an LED ring, each with their own place carved out.

This completely open-source knob looks great, and we love that it’s been made incredibly easy to replicate by standing up a site with foolproof, well-depicted, step-by-step instructions. Watch them take it for a spin after the break.

Want more than volume at your fingertips? Here’s a DIY USB knob that does shortcuts, too.

Whilst swapping out the stereo in his car for a more modern Android based solution, [Aaron] noticed that it only utilised a single CAN differential pair to communicate with the car as opposed to a whole bundle of wires employing analogue signalling. This is no surprise, as modern cars invariably use the CAN bus to establish communication between various peripherals and sensors.

In a series of videos, [Aaron] details how he used this opportunity to explore some of the nitty-gritty of CAN communication. In Part 1 he designs a cheap, custom CAN bus sniffer using an Arduino, a MCP2515 CAN controller and a CAN bus driver IC, demonstrating how this relatively simple hardware arrangement could be used along with open source software to decode some real CAN bus traffic. Part 2 of his series revolves around duping his Android stereo into various operational modes by sending the correct CAN packets.

These videos are a great way to learn some of the basic considerations associated with the various abstraction layers typically attributed to CAN. Once you’ve covered these, you can do some pretty interesting stuff, such as these dubious devices pulling a man-in-the-middle attack on your odometer! In the meantime, we would love to see a Part 3 on CAN hardware message filtering and masks [Aaron]!