Ball Nut Modification Charts A Middle Course Between Building And Buying

A lot of the projects we feature here on Hackaday engender the classic “build versus buy” argument. We’ve always been puzzled by that; if anyone can appreciate the sheer joy of making something rather than buying it, it should be our readers. But there’s something to be said for buying the stuff you can buy and concentrating your effort on the bespoke aspects of the project. It’s perhaps not as exciting, but needs must, oftentimes.

Let’s not forget there’s a third way though, which [Andy] explores with this ball nut modification project. Keen-eyed readers will recall [Andy]’s recent scratch-built ball screw build, in service of some top-secret, hush-hush project related to world domination and total subjugation of humanity. His homebrew efforts in this regard were a great lesson in how to machine a complex mechanism to work in a constrained space. Still, it left folks wondering why he’d go to all the trouble when he could have just trimmed an off-the-shelf part down to size. So, he decided to give that a try.

Continue reading “Ball Nut Modification Charts A Middle Course Between Building And Buying”

[Kerry Wong] Talks (and Talks) About A 300 MHz Oscilloscope

There aren’t many people who could do an hour-long video reviewing an oscilloscope, but [Kerry Wong] is definitely one of them. This time, he’s looking at a UNI-T MSO2304X 300 MHz scope. The review might be a little long, but the scope — like many modern scopes — has a lot of features for measuring power, accommodating digital signals with an add-on pod, and protocol decoding.

The scope has a touchscreen and four normal inputs, plus two frequency generator outputs. You can also use a mouse or an external display. But, of course, what you really want to know is how the scope performs when reading signals.

Continue reading “[Kerry Wong] Talks (and Talks) About A 300 MHz Oscilloscope”

38C3: Lawsuits Are Temporary; Glory Is Forever

One of the blockbuster talks at last year’s Chaos Communications Congress covered how a group of hackers discovered code that allegedly bricked public trains in Poland when they went into service at a competitor’s workshop. This year, the same group is back with tales of success, lawsuits, and appearances in the Polish Parliament. You’re not going to believe this, but it’s hilarious.

The short version of the story is that [Mr. Tick], [q3k], and [Redford] became minor stars in Poland, have caused criminal investigations to begin against the train company, and even made the front page of the New York Times. Newag, the train manufacturer in question has opened several lawsuits against them. The lawsuit alleges the team is infringing on a Newag copyright — by publishing the code that locked the trains, no less! If that’s not enough, Newag goes on to claim that the white hat hackers are defaming the company.

What we found fantastically refreshing was how the three take all of this in stride, as the ridiculous but incredibly inconvenient consequences of daring to tell the truth. Along the way they’ve used their platform to speak out for open-sourcing publicly funded code, and the right to repair — not just for consumers but also for large rail companies. They are truly fighting the good fight here, and it’s inspirational to see that they’re doing so with humor and dignity.

If you missed their initial, more technical, talk last year, go check it out. And if you ever find yourself in their shoes, don’t be afraid to do the right thing. Just get a good lawyer.

Bokeh photo of red light particles in the dark

Beam Me Up: Simple Free-Space Optical Communication

Let’s think of the last time you sent data without wires. We’re not talking WiFi here, but plain optical signals. Free-space optical communication, or FSO, is an interesting and easy way to transmit signals through light beams. Forget expensive lasers or commercial-grade equipment; this video by [W1VLF] offers a simple and cheap entry point for anyone with a curiosity for DIY tech. Inspired by a video on weak signal sources for optical experiments, this project uses everyday components like a TV remote-control infrared LED and a photo diode. The goal is simply to establish optical communication across distances for under $10. Continue reading “Beam Me Up: Simple Free-Space Optical Communication”

38C3: Xobs On Hardware Debuggers

If you just want to use a debugger for your microcontroller project, you buy some hardware device, download the relevant driver software, and fire up GDB. But if you want to make a hardware debugger yourself, you need to understand the various target chips’ debugging protocols, and then you’re deep in the weeds. But never fear, Sean [Xobs] Cross has been working on a hardware debugger and is here to share his learnings about the ARM, RISC-V, and JTAG debugging protocols with us.

He starts off with a list of everything you need the debugger hardware to be able to do: peek and poke memory, read and write to the CPU registers, and control the CPU’s execution state. With that simple list of goals, he then goes through how to do it for each of the target chip families. We especially liked [Xobs]’s treatment of the JTAG state machine, which looks pretty complicated on paper, but in the end, you only need to get it in and out of the shift-dr and shift-ir states.

Continue reading “38C3: Xobs On Hardware Debuggers”

Wire Rope: Never Saddle A Dead Horse

If you’re into building large projects, you’ll eventually find yourself looking at wire rope. Multistrand steel wire used as antenna guy wires, bridge supports, and plenty of other uses.  The [HowNot2] team tested an old rule of thumb for wire rope. “Never saddle a dead horse”.

Click through the break for more:

Continue reading “Wire Rope: Never Saddle A Dead Horse”

A Die-Level Look At The Pentium FDIV Bug

The early 1990s were an interesting time in the PC world, mainly because PCs were entering the zeitgeist for the first time. This was fueled in part by companies like Intel and AMD going head-to-head in the marketplace with massive ad campaigns to build brand recognition; remember “Intel Inside”?

In 1993, Intel was making some headway in that regard. The splashy launch of their new Pentium chip in 1993 was a huge event. Unfortunately an esoteric bug in the floating-point division module came to the public’s attention. [Ken Shirriff]’s excellent account of that kerfuffle goes into great detail about the discovery of the bug. The issue was discovered by [Dr. Thomas R. Nicely] as he searched for prime numbers. It’s a bit of an understatement to say this bug created a mess for Intel. The really interesting stuff is how the so-called FDIV bug, named after the floating-point division instruction affected, was actually executed in silicon.

We won’t presume to explain it better than [Professor Ken] does, but the gist is that floating-point division in the Pentium relied on a lookup table implemented in a programmable logic array on the chip. The bug was caused by five missing table entries, and [Ken] was able to find the corresponding PLA defects on a decapped Pentium. What’s more, his analysis suggests that Intel’s characterization of the bug as a transcription error is a bit misleading; the pattern of the missing entries in the lookup table is more consistent with a mathematical error in the program that generated the table.

The Pentium bug was a big deal at the time, and in some ways a master class on how not to handle a complex technical problem. To be fair, this was the first time something like this had happened on a global scale, so Intel didn’t really have a playbook to go by. [Ken]’s account of the bug and the dustup surrounding it is first-rate, and if you ever wanted to really understand how floating-point math works in silicon, this is one article you won’t want to miss.