Morse Code Clock For Training Hams

It might seem antiquated, but Morse code still has a number of advantages compared to other modes of communication, especially over radio waves. It’s low bandwidth compared to voice or even text, and can be discerned against background noise even at extremely low signal strengths. Not every regulatory agency requires amateur operators to learn Morse any more, but for those that do it can be a challenge, so [Cristiano Monteiro] built this clock to help get some practice.

The project is based around his favorite microcontroller, the PIC16F1827, and uses a DS1307 to keep track of time. A single RGB LED at the top of the project enclosure flashes the codes for hours in blue and minutes in red at the beginning of every minute, and in between flashes green for each second.

Another design goal of this build was to have it operate with as little power as possible, so with a TP4056 control board, single lithium 18650 battery, and some code optimization, [Cristiano] believes he can get around 60 days of operation between charges.

For a project to help an aspiring radio operator learn Morse, a simple build like this can go a long way. For anyone else looking to build something similar we’d note that the DS1307 has a tendency to drift fairly quickly, and something like a DS3231 or even this similar Morse code clock which uses NTP would go a long way to keeping more accurate time.

Continue reading “Morse Code Clock For Training Hams”

Dream Projects Face Reality

Do you ever get a project stuck in your mind? An idea so good you just keep thinking about it? Going over iterations and options and pros and cons in the back of your mind, or maybe on paper, but having not yet subjected it to the hard work of pulling it into reality? I’ve had one of those lurking around for the last couple weeks, and it’s time for me to get building.

And I’ve got to get started soon, because it’s rare that any project makes the leap from thought to reality unscathed, and when I hold on to the in-thought project too long, I become far too fond of some of the details and nuances that just might not make the cut, or might get in the way of getting a first pass finished. When I really like a (theoretical) solution to a (theoretical) problem, I’ll try to make it work a lot longer than I should, and I can tell I’m getting attached to this one now.

The only cure to this illness is to get prototyping. When the rubber hits the road, and the bolts are tightened, either the solution is a good one or it’s not, and no amount of dreaming is going to change that. Building is a great antidote to the siren song of a dream project. Although it feels now like I don’t want the fantasy to have to adapt to reality, as it inevitably will, I know that getting something working feels a lot better. And it frees me up to start dreaming on the next project… To the workshop!

The Devil Is In The Details

If you’ve taken a physics class, you’ve doubtless heard tales of mythical beasts like the massless string, the frictionless bearing, and the perfect sphere. And if you’re designing something new, it’s not always wrong to start by thinking in terms of these abstractions, just to get the basic framework laid and a first-order handle on the way things go. But once you start building, you’d better be ready to shed your illusions that a 6 mm peg will fit into a 6 mm hole.

Theory and practice are the same thing, in theory. But as soon as you step into practice, your “weekend build” can easily turn into a 500-hour project, full of hurdles, discoveries, experimentation, and eventual success. I’m not going to rehash [Scott Rumschlag]’s project here — you should really watch his detailed video — but suffice it to say that when building a sub-millimeter precision 3D measuring device, bearings do have friction and string does have non-zero mass, and it all matters.

When you start working on a project that “looked good on paper” or for whatever reason just doesn’t turn out as precisely as you’d wished, you could do worse than to follow [Scott’s] example: start off by quantifying your goals, and then identify where every error along the way accumulates to keep you from reaching them. Doing precise work isn’t easy, but it’s not impossible either if you know where all the errors are coming from. You at least have a chain of improvements that you can consider, and if you’ve set realistic goals, you also know when to stop, which is almost as important.

And if anyone out there has an infinite sheet of perfectly conductive material, I’m in the market.

Is It A Stupid Project If You Learn Something From The Process?

Fidget spinners — so hot right now!

[Ben Parnas], and co-conspirator in engineering inanity [Greg Daneault], brought to the recent Boston Stupid Hackathon in Cambridge, MA, their IoT-enabled Fidget Spinner…. spinner. A Spidget Finner. Yep, that’s correct: spin the smartphone, and the spinner follows suit. Stupid? Maybe, but for good reason.

Part satire on cloud tech, part learning experience, a curt eight hours of tinkering brought this grotesque, ESP32-based device to life. The ESP can the Arduino boot-loader, but you’ll want to use the ESP-IDF sdk, enabling broader use of the chip.

Creating an app that pulls data from the phone’s gyroscope, the duo set up the spinner-bot to access the WiFi and request packets of rotational data from the smartphone via a cloud-based server — the ‘spincloud.’ Both devices were enabled as clients to circumvent existing IoT services.

Continue reading “Is It A Stupid Project If You Learn Something From The Process?”