This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.
Way to rub it in, guys. As it turns out, due to family and work obligations we won’t be able to see the next Great American Eclipse, at least not from anywhere near the path of totality, when it sweeps from Mexico into Canada on April 8. And that’s too bad, because compared to the eclipse back in 2017, “Eclipse 2: Solar Boogaloo” is occurring during a much more active phase in the solar cycle, with the potential for some pretty exciting viewing. The sun regularly belches out gigatons of plasma during coronal mass ejections (CMEs), most of which we can’t see with the naked eye because not only is staring at the sun not a great idea, but most of that activity occurs across the disk of the sun, obscuring the view in the background light. But during the eclipse, we — oops, you — might just get lucky enough to have a solar prominence erupt along the limb of the sun that will be visible during totality. The sun has been quite active lately, as reflected by the relatively high sunspot number, so even though it’s an outside chance, it’s certainly more likely than it was in 2017. Good luck out there. Continue reading “Hackaday Links: March 24, 2024”→
Given that [Les] spent all of around $100 on this widowmaker, we’re pretty sure he knew what he was getting himself into. But he likely wasn’t quite prepared for the scale of the sketchiness this thing would exhibit. The deficiencies are almost too many to number, starting with the enclosure, which is not only made completely of plastic but assembled from individual sheets of flat plastic stock that show signs of being glued together by hand. Even the cooling water tank inside the case is pieced together this way, which probably led to the leaks that corroded the PCBs. Another assembly gem is the pair of screws the big energy storage capacitor is jammed under, presumably to hold it in place — because nothing says quality like a BOM that can’t spring for a couple of cable ties. Click through the break to read more and see the video.
I’m pretty good with time zones. After all, I live in Germany, Hackaday’s server is in Los Angeles, and our writers are scattered all over the globe. I’m always translating one time into another, and practice makes (nearly) perfect. But still, it got me.
I was in the states visiting my parents, when Daylight Saving Time struck, but only in the USA. Now all my time conversions were off by an hour, and once I’d worked through the way the sun travels around the globe, I thought I had it made. And then my cell phone started reporting a time that was neither CEST nor EDT, but a third time zone that was an hour off. Apparently some cell towers don’t transmit time zone information, and my phone defaults to UTC. Who knew? For a short while, my phone lied to me, the microwave oven clock in the hotel lied to me, and I felt like I was going nuts.
But this all got me thinking about clocks and human time, and possibly the best advice I’ve ever heard for handling it in your own programs. Always keep time in something sensible like UNIX time – seconds elapsed since an epoch – because you don’t have to worry about anything more than adding one to a counter every second. When and if you need to convert to or from human times, you can write the function to do that simply enough, if you don’t already have a library function to do so.
Want to set an alarm for 2 hours from now? That’s easy, because you only need to add 7,200 seconds, and you don’t need to worry about 59 wrapping around to 0 or 23:59 to 0:00. Time math is easy in seconds. February 29th? That’s just another 86,400 seconds. It’s only us humans who make it complicated.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
No need to wonder what stories Hackaday Editors Elliot Williams and Al Williams were reading this week. They’ll tell you about them in this week’s podcast. The guys revisit the McDonald’s ice cream machine issue to start. This week, DIY voice assistants and home automation took center stage. But you’ll also hear about AI chat models implemented as a spreadsheet, an old-school RC controller, and more.
How many parts does it take to make a radio? Not a crystal radio, a software-defined one. Less than you might think. Of course, you’ll also need an antenna, and you can make one from lawn chair webbing.
In the can’t miss articles, you’ll hear about the problems with the x86 architecture and how they tried to find Martian radio broadcasts in the 1920s.
Miss any this week? Check out the links below if you want to follow along, and as always, leave your comments!
Here’s a fun thought experiment. UDP packets can be sent with an arbitrary source IP and port, so you can send a packet to one server, and could aim the response at another server. What happens if that response triggers another response? What if you could craft a packet that continues that cycle endlessly? That is essentially the idea behind Loop DoS (Denial of Service).
This unique avalanche of packets has been managed using specific implementations of several different network services, like TFTP, DNS, and NTP. There are several CVEs being used to track the issue, but CVE-2024-2169 is particularly odd, with the description that “Implementations of UDP application protocol are vulnerable to network loops.” This seems to be a blanket CVE for UDP, which is particularly inappropriate given that the first DoS of this sort was first reported in 2009 at the latest.
More details are available in a Google Doc. There some interesting tidbits there, like the existence of cross-protocol loops, and several legacy protocols that are vulnerable by design. The important thing to remember here is you have to have an accessible UDP port for this sort of attack to take place, so if you’re not using it, firewall it.
Flipper Flips Back
We’ve covered the saga of the Flipper Zero vs the Canadian government, in the context of car theft. The short version is that Canada has seen an uptick of car thefts from organized crime. Rather than meaningfully dealing with this problem, the Canadian government went looking for scapegoats, and found the Flipper Zero.
Well now, Flipper has responded, and put simply, the message is “stop the madness”. There has never been a confirmed case of using a flipper to steal a car, and it’s very unlikely it’s ever happened. On a modern car with proper rolling-code security, it’s not meaningfully possible to use the Flipper Zero for the theft. The two primary ways criminals actually steal cars are with dedicated keyfob repeaters and CAN bus hackers.
We are always fascinated when someone can take something and extend it in a clever way without changing the original thing. In the computer world, that’s old hat. New computers improve, but can usually run old software. In the real world, the addition of stereo to phonograph records and color to photography come to mind.
But there are few stories as strange or wide-ranging as the path to provide color TV. And it had to be done in a way that a color set could still get a black and white picture and black and white sets could still watch a color signal without color. You’d think there would be a “big bang” moment where color TV burst on the scene — no pun involving color burst intended. But there wasn’t. Instead, there was a long, twisted path with many competing interests and ideas to go from a world in black and white to one tinted with color phosphor.
Background
In 1928, Science and Invention magazine had plans for building a mechanical TV (although not color)
It is hard to imagine, but John Logie Baird transmitted color images as early as 1928 using a mechanical scanner. Bell Labs had a demonstration system, also mechanical, in 1929. Baird broadcast using his system in 1938. Even earlier, around 1900, there were attempts to create mechanical color image systems. Those systems were fickle or impractical, though.
Electronic scanning was the answer, but World War II froze most consumer electronics development. Baird showed an electronic color system in late 1944. However, it would be 1953 before NTSC (the National Television System Committee) adopted the standard color TV signal for the United States. It would be almost 20 years later before SECAM and PAL were standardized in other parts of the world.
Of course, these are all analog standards. The world’s gone digital now, but for nearly 50 years, analog color TV was the way people consumed TV in their homes. By 1941, NTSC produced a standard in the United States, but not for color TV. TV adoption didn’t really take off until after the war. But by 1950, the US had some 6 million TV sets.
This was both a plus — a large market — and a negative. No one wanted to obsolete those 6 million sets. Well, at least, the government regulators and consumers didn’t. But most color systems would be incompatible with those existing black and white sets. Continue reading “The Long Strange Trip To US Color TV”→
This week, Jonathan Bennett and Rob Campbell chat with Ben Meadors and Adam McQuilkin to talk about what’s new with Meshtastic! There’s a lot. To start with, your favorite podcast host has gotten roped into doing development for the project. There’s a new Rust client, there’s a way to run the firmware on Linux Native, and there’s a shiny new web-based flasher tool!
