Improved Controller For E-Skateboards

December 28, 2018 by Lewin Day 12 Comments

[Timo] recently purchased himself a Acton Blink Qu4tro electric skateboard. Performance-wise, the board was great, but the controller left a lot to be desired. There were issues with pairing, battery displays, and just general rideability. Like any good hacker, he decided some reverse engineering was in order, and got to work.

Initial results were disheartening – the skateboard relies on various chips of Chinese origin for which documentation proved impossible to come by. However, as it turned out, the board and controller communicated using the common NRF24L01+ transceiver.

Initial work focused on understanding the pairing process and message protocol. With that done, [Timo] decided the best course of action was to redevelop a controller from scratch, using an Arduino Nano and NRF24L01+ to do the job. [Timo]’s Open esk8 controller improves driveability by removing delays in message transfer, as well as improving on the feel of the controller with a 3D printed chassis redesign.

[Timo] now has a much more usable skateboard, and has racked up over 200 miles in testing since the build. However, if you fancy converting your existing board to electric, check out this project.

Dainty Delta Is About As Small As A Robot Can Be

December 28, 2018 by Dan Maloney 8 Comments

There’s something mesmerizing about delta robots. Whether they are used at a stately pace for a 3D-printer or going so fast you can barely see them move in a pick and place machine, the way that three rotary actuators can work together to produce motion in three axes is always a treat to watch. Especially with a delta robot as small as this one.

[KarelK16] says this is one of those “just because I can” projects with no real application. And he appears to have been working on it for a while; the video below is from eight years ago. Regardless, the post is new, and it’s pretty interesting stuff. The tiny ball joints used in the arms are made from jewelry parts; small copper crank arms connect the three upper arms to micro-servos. The manipulator [KarelK16] attached is very clever, too – rather than load down the end of the arms with something heavy, a fourth servo opens an closes a flexible plastic grasper through a Bowden cable. It’s surprisingly nimble, and grasps small objects firmly.

There are certainly bigger deltas – much bigger – and more useful ones, too, but we really like this build. And who knows – perhaps model robotics will join model railroading as a hobby someday. If it does, [KarelK16]’s diminutive delta might be the shape of things to come.

Continue reading “Dainty Delta Is About As Small As A Robot Can Be” →

A Different Kind Of Hand Controlled Vehicle

December 28, 2018 by Lewin Day 5 Comments

It’s generally understood that most vehicles that humans interact with on a daily basis are used with some kind of hand controlled interface. However, this build from [Avisha Kumar] and [Leul Tesfaye] showcases a rather different take. A single motion input provides both steer and foward/reverse throttle control.

The hand controller lives on a protoboard for ease of testing.

The project consists of a small car, driven with electric motors at the rear, with a servo-controlled caster at the front for steering. Controlled is provided through PIC32 microcontroller receiving signals via Bluetooth. The car is commanded with a hand controller, quite literally — consisting of an accelerometer measuring pitch and roll position of the user’s hand. By tilting the hand left and right affects steering, while the hand is rotated fore and aft for throttle control. Video after the break.

The project was built for a course at Cornell University, and thus is particularly well documented. It provides a nice example of reading sensor inputs and transmitting/receiving data. The actually microcontroller used is less important than the basic demonstration of “Hello World” with robotics concepts. Keep this one in your back pocket for the next time you want to take a new chip for a spin!

The 7400 Quad 2-Input NAND Gate, A Neglected Survivor From A Pre-Microprocessor World

December 28, 2018 by Jenny List 63 Comments

There are a range of integrated circuits that most of us would regard as definitive examples of their type, devices which became the go-to for a particular function and which have entered our collective consciousness as electronics enthusiasts. They have been in production since the early days of consumer integrated circuits, remaining in use because of a comprehensive understanding of their characteristics among engineers, and the job they do well.

You can probably name the ones I’m going to rattle off here, the µA741 op-amp designed by David Fullagar for Fairchild in 1968, the NE555 timer from Hans Camenzind for Signetics in 1971, and a personal favourite, Bob Widlar’s µA723 linear regulator for Fairchild in 1967. There may be a few others that readers will name in the comments, but there’s one that until today it’s likely that few of you would have considered. Texas Instruments’ 5400 and 7400 TTL quad 2-input NAND gate has been in continuous production since 1964 and is the progenitor of what is probably the most numerous breed of integrated circuits, yet it doesn’t trip off the tongue when listing famous chips, and none of us can name its designer. So today we’re turning the spotlight on this neglected piece of silicon, and trying to bring it the adulation it deserves. Continue reading “The 7400 Quad 2-Input NAND Gate, A Neglected Survivor From A Pre-Microprocessor World” →

Rebuilding An Extremely Rare Twin Mustang Fighter

December 28, 2018 by Tom Nardi 64 Comments

Towards the end of the Second World War, as the United States considered their options for a possible invasion of Japan, there was demand for a new fighter that could escort long range bombers on missions which could see them travel more than 3,200 kilometers (2,000 miles) without refueling. In response, North American Aviation created the F-82, which essentially took two of their immensely successful P-51 fighters and combined them on the same wing. The resulting plane, of which only 272 were built, ultimately set the world record for longest nonstop flight of a propeller-driven fighter at 8,129 km (5,051 mi) and ended up being the last piston engine fighter ordered by the United States Air Force.

Today, only five of these “Twin Mustangs” are known to exist. One of those, a prototype XP-82 variant, is currently in the final stages of an epic decade-long rebuilding process directed by warbird restoration expert [Tom Reilly]. At the end of this painstaking restoration, which makes use of not only original hardware but many newly produced components built with modern technology such as CNC milling and 3D printing, the vintage fighter will become the only flyable F-82 in the world.

The project provides a fascinating look at what it takes to not only return a 70+ year old ultra-rare aircraft to fully functional status, but do it in a responsible and historically accurate way. With only four other intact F-82’s in the world, replacement parts are obviously an exceptional rarity. The original parts used to rebuild this particular aircraft were sourced from literally all over the planet, piece by piece, in a process that started before [Tom] even purchased the plane itself.

In a way, the search for parts was aided by the unusual nature of the F-82, which has the outward appearance of being two standard P-51 fighters, but in fact utilizes a vast number of modified components. [Tom] would keep an eye out for parts being sold on the open market which their owners mysteriously discovered wouldn’t fit on a standard P-51. In some cases these “defective” P-51 parts ended up being intended for the Twin Mustang project, and would get added to the collection of parts that would eventually go into the XP-82 restoration.

For the parts that [Tom] couldn’t find, modern manufacturing techniques were sometimes called in. The twin layout of the aircraft meant the team occasionally had one component but was missing its counterpart. In these cases, the original component could be carefully measured and then recreated with either a CNC mill or 3D printed to be used as a die for pressing the parts out of metal. In this way the team was able to reap the benefits of modern production methods while still maintaining historical accuracy; important on an aircraft where even the colors of the wires used in the original electrical system have been researched and faithfully recreated.

We’ve seen plenty of restorations here at Hackaday, but they tend to be of the vintage computer and occasionally Power Wheels variety. It’s interesting to see that the same sort of techniques we apply to our small scale projects are used by the pros to preserve pieces of history for future generations.

[Thanks to Daniel for the tip.]

DooM Retrospective: 25 Years Of Metal

December 28, 2018 by Drew Littrell 35 Comments

Metal is many things. A material hard and coarse in nature that by forging it in fire becomes sharp enough to cut through anything in its path. The music that bares its namesake is equally cutting and exudes an unyielding attitude that seeks to separate the posers from the true acolytes. Metal is the sentiment of not blindly following the rules, a path less taken to the darker side of the street. In videogame form, there is nothing more metal than Doom.

The creators of Doom, id Software, were always hellbent on changing the perception of PC gaming in the 1990s. Games of the time were rigid and slow in comparison to their console counterparts. The graphical fidelity was technically superior on PC, but no other developer could nail movement in a game like id. The team had made a name for themselves with their Commander Keen series (which came about after a failed Super Mario Bros. 3 PC demo) along with the genre defining Wolfenstein 3D, but nothing topped Doom. In an era that was already soaking with “tude”, Doom established an identity all its own. The moody lighting, the grotesque monster designs, the signature push forward combat, and all the MIDI guitars a Soundblaster could handle; Doom looked and felt a cut above everything else in 1993.

In December of that year, Senators Joe Lieberman and Herb Kohl held a hearing to publicly condemn the inclusion of violence in videogames sold in America. The bulk of the arguments sought to portray the videogame industry and its developers as deviants seeking to corrupt the nation’s youth. Id Software responded as if to raise the largest middle finger imaginable, by releasing Doom to the world the very next day. A quarter of a century later people are still talking about it.

Continue reading “DooM Retrospective: 25 Years Of Metal” →

Peering Into A Running Brain: SDRAM Refresh Analyzed From Userspace

December 28, 2018 by Ted Yapo 7 Comments

Over on the Cloudflare blog, [Marek] found himself wondering about computer memory, as we all sometimes do. Specifically, he pondered if he could detect the refresh of his SDRAM from within a running program. We’re probably not ruining the surprise by telling you that the answer is yes — with a little more than 100 lines of C and help from our old friend the Fast Fourier Transform (FFT), [Marek] was able to detect SDRAM refresh cycles every 7818.6 ns, lining right up with the expected result.

The “D” in SDRAM stands for dynamic, meaning that unless periodically refreshed by reading and writing, data in the memory will decay. In this kind of memory, each bit is stored as a charge on a tiny capacitor. Given enough time (which varies with ambient temperature), this charge can leak away to neighboring silicon, turning all the 1s to 0s, and destroying the data. To combat this process, the memory controller periodically issues a refresh command which reads the data before it decays, then writes the data back to fully charge the capacitors again. Done often enough, this will preserve the memory contents indefinitely. SDRAM is relatively inexpensive and available in large capacity compared to the alternatives, but the drawback is that the CPU can’t access the portion of memory being refreshed, so execution gets delayed a little whenever a memory access and refresh cycle collide.

Chasing the Correct Hiccup

[Marek] figured that he could detect this “hiccup,” as he calls it, by running some memory accesses and recording the current time in a tight loop. Of course, the cache on modern CPUs would mean that for a small amount of data, the SDRAM would never be accessed, so he flushes the cache each time. The source code, which is available on GitHub, outputs the time taken by each iteration of the inner loop. In his case, the loop typically takes around 140 ns.

Hurray! The first frequency spike is indeed what we were looking for, and indeed does correlate with the refresh times.

The other spikes at 256kHz, 384kHz, 512kHz and so on, are multiplies of our base frequency of 128kHz called harmonics. These are a side effect of performing FFT on something like a square wave and totally expected.

As [Marek] notes, the raw data doesn’t reveal too much. After all, there are a lot of things that can cause little delays in a modern multitasking operating system, resulting in very noisy data. Even thresholding and resampling the data doesn’t bring refresh hiccups to the fore. To detect the SDRAM refresh cycles, he turned to the FFT, an efficient algorithm for computing the discrete Fourier transform, which excels at revealing periodicity. A few lines of python produced the desired result: a plot of the frequency spectrum of the lengthened loop iterations. Zooming in, he found the first frequency spike at 127.9 kHz, corresponding to the SDRAMs refresh period of 7.81 us, along with a number of other spikes representing harmonics of this fundamental frequency. To facilitate others’ experiments, [Marek] has created a command line version of the tool you can run on your own machine.

If this technique seems familiar, it may be because it’s similar the the Rowhammer attack we covered back in 2015, which can actually change data in SDRAM on vulnerable machines by rapidly accessing adjacent rows. As [Marek] points out, the fact that you can make these kinds of measurements from a userspace program can have profound security implications, as we saw with the meltdown and spectre attacks. We have to wonder what other vulnerabilities are lying inside our machines waiting to be discovered.

Thanks to [anfractuosity] for the tip!