Bradley Gawthrop: What You Need To Know About Wiring

January 12, 2018 by Brian Benchoff 53 Comments

Wiring — as in plugging wires together and crimping connectors, not the Arduino IDE thingy — is an incredibly deep subject. We all know the lineman’s splice is the best way to solder two wires together, and NASA’s guide to cables and connectors is required reading around these parts. However, there’s a lot that can be said about connectors and cabling, and one of the best people to explain it all is Bradley Gawthrop. He spent the last ten years building pipe organs, and with that comes tens of thousands of relays, solenoids, switches, and valves. All of these parts are connected by thousands of miles of wire, and are arguably as complex as an old-school telephone exchange. If there’s someone you need to talk to about connecting hundreds of thousands of parts together, Bradley is your guy.

Bradley starts his Hackaday Superconference talk with a discussion of the modern prototyping process. We’re pretty far away from dozens of chips sitting around a breadboard with data and address lines these days, and now any sort of prototype is basically a development board with a constellation of modules studded around the perimeter. The best solution for connectors is right angle headers, not only for the reason that the wires stay flat, but also because right angle connectors allow you to probe each and every wire coming out of a board.

Of course, when it comes to wiring, it’s helpful to talk about the wire itself. Instead of having an entire warehouse of wire in every color, gauge, and insulation material hanging above his workshop, Bradley only needs a few options. Right now, he’s only dealing with three gauges of wire — small, medium, and large, or 24, 18, and 12 AWG. That’s one wire for small signals, one wire for a bit of current, and one wire for supply amounts of current. Not only does this cut down on workshop inventory, it also means Bradley only needs three sizes of crimpers and connectors. When it comes to strand count, solid core wire is highly underrated. Not only is it easier to strip and crimp, it can also support its own weight. That’s important, because it means connectors don’t have to bear the weight of the entire cable run.

If you’re looking for the minimal required toolset for running cables and crimping connectors, Bradley has a great little shopping list on his website. The best strippers he’s ever found come from Wiha, but they’ve been EOL’d by the manufacturer. Knipex makes some good strippers, though. You don’t need to spend big money on ferrule crimpers, and some cheapies from BangGood are good enough. Bradley has standardized on Molex SL and Molex KK interconnects, and wire can be sourced easily if you have Amazon Prime.

While the subject matter for Bradley’s talk sounds easy to overlook, connecting parts together in an assembly is a critical skill in itself. We’re glad Bradley could share his experience with us at the Hackaday Superconference.

Dust Off Those AM Radios, There’s Something Good On!

January 12, 2018 by Gregory L. Charvat 53 Comments

If you are into vintage electronics or restoring antique radio equipment you may be very disappointed with the content offerings on AM broadcast radio these days. Fortunately there is a way to get around this: build your own short-range AM broadcast station and transmit curated content to your radios (and possibly your neighbors). There are several options for creating your own short-range AM broadcast station, and this gives you something fun to tune into with your vintage radio gear.

Continue reading “Dust Off Those AM Radios, There’s Something Good On!” →

Fail Of The Week: Engine Flips Out

January 11, 2018 by Adam Fabio 66 Comments

A few weeks ago an incredible video of an engine exploding started making the rounds on Facebook. This particular engine was thankfully in a dyno room, rather than sitting a couple of feet away from a driver on a track. We’ve all seen engine carnage videos before, but this one stands out. This diesel engine literally rips itself apart, with the top half of the engine flipping and landing on one side of the room while the bottom half sits still spinning on the dyno frame.

Building performance engines is part science, part engineering, and part hacking. While F1 racing teams have millions of dollars of test and measurement equipment at their disposal, smaller shops have to operate on a much lower budget. In this case, the company makes their modifications, then tests things out in the dyno room. Usually, the tests work out fine. Sometimes though, things end spectacularly, as you can see with this diesel engine.

The engine in question belongs to Firepunk diesel, a racing team. It started life as a 6.7 liter Cummins diesel: the same engine you can find in Dodge Ram pickup trucks. This little engine wasn’t content to chug around town, though. The Firepunk team builds performance engines — drag racing and tractor pulling performance in this case. Little more than the engine block itself was original on this engine. Let’s take a deeper look.

Continue reading “Fail Of The Week: Engine Flips Out” →

Spectre And Meltdown: Attackers Always Have The Advantage

January 10, 2018 by Roger Cheng 45 Comments

While the whole industry is scrambling on Spectre, Meltdown focused most of the spotlight on Intel and there is no shortage of outrage in Internet comments. Like many great discoveries, this one is obvious with the power of hindsight. So much so that the spectrum of reactions have spanned an extreme range. From “It’s so obvious, Intel engineers must be idiots” to “It’s so obvious, Intel engineers must have known! They kept it from us in a conspiracy with the NSA!”

We won’t try to sway those who choose to believe in a conspiracy that’s simultaneously secret and obvious to everyone. However, as evidence of non-obviousness, some very smart people got remarkably close to the Meltdown effect last summer, without getting it all the way. [Trammel Hudson] did some digging and found a paper from the early 1990s (PDF) that warns of the dangers of fetching info into the cache that might cross priviledge boundaries, but it wasn’t weaponized until recently. In short, these are old vulnerabilities, but exploiting them was hard enough that it took twenty years to do it.

Building a new CPU is the work of a large team over several years. But they weren’t all working on the same thing for all that time. Any single feature would have been the work of a small team of engineers over a period of months. During development they fixed many problems we’ll never see. But at the end of the day, they are only human. They can be 99.9% perfect and that won’t be good enough, because once hardware is released into the world: it is open season on that 0.1% the team missed.

The odds are stacked in the attacker’s favor. The team on defense has a handful of people working a few months to protect against all known and yet-to-be discovered attacks. It is a tough match against the attackers coming afterwards: there are a lot more of them, they’re continually refining the state of the art, they have twenty years to work on a problem if they need to, and they only need to find a single flaw to win. In that light, exploits like Spectre and Meltdown will probably always be with us.

Let’s look at some factors that paved the way to Intel’s current embarrassing situation.

Continue reading “Spectre And Meltdown: Attackers Always Have The Advantage” →

Friday Hack Chat: Assembling In Quantity With MacroFab

January 10, 2018 by Brian Benchoff 6 Comments

Building one of something is easy. You see it here every day, and yes, building a single robot, or a board to convert Segas to HDMI, or an Internet of Things thing is easy. Manufacturing is another story entirely. You’re going to have BOMs to work with, you’ll have suppliers, and you need to deal with assembly, programming, and packaging. Do you even know where you’re going to store all those boxes of parts? Manufacturing is a difficult task, but luckily there are assembly houses and contract manufacturers ready to ease the burden a little.

For this week’s Hack Chat, we’re going to be talking about Assembly as a Service through MacroFab. MacroFab is an online assembly house and contract manufacturer that makes creating hardware simple. If you thought sending a board file off to OSH Park and receiving a PCB in a week is amazing, you clearly haven’t experienced MacroFab. Here, you can upload your board and BOM, and with minimal effort, receive a completely populated product in a few weeks.

Our guest for this week’s Hack Chat will be [Parker Dillmann], MacroFab co-founder, with backgrounds in embedded design and DSP. He runs longhornengineer, a blog full of amazing projects that fit in well with the usual Hackaday fare. Shoutouts are especially deserved for the Game Boy VGA adapter.

During this week’s Hack chat, we’re going to be talking to [Parker] about manufacturing, the pitfalls, how you can better design for manufacturing (DFM), the machines used by MacroFab, pogo pin adapters, solder fountains, and all the cool stuff that turns one of a thing into thousands of a thing. If you’re wondering what MacroFab’s results look like, you’ve probably already held a few in your hands; the badge for this year’s Hackaday Superconference was manufactured by MacroFab, as were a lot of the independent badges at last year’s Def Con.

During this Hack Chat, we’ll be discussing:

What is the process for a first-time manufacturer?
Where can you find out how to design better for manufacturing?
What kinds of products are made at MacroFab?
What kinds of equipment is typically used for board assembly?

As always, we’re looking for questions from the community, you can add those as a comment on the Hack Chat event page.

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging. This Hack Chat is going down Friday, January 12th at noon, Pacific time. Time Zones got you down? Here’s a handy countdown timer!

Click that speech bubble to the left, and you’ll be taken directly to the Hack Chat group on Hackaday.io.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

The 348,296th Article About Cryptocurrency

January 9, 2018 by Lauren Faris 42 Comments

The public has latched onto the recent market events with an intense curiosity brought about by a greed for instant riches. In the last year alone, the value of Bitcoin has risen by 1,731%. We’re talking gold rush V2.0, baby. Money talks, and with a resounding $615 billion held up in cryptocurrencies, it is clear why this is assuredly not the first cryptocurrency article you have read — maybe even today. An unfortunate side effect of mass interest in a subject is the wildfire-like spread of misinformation. So, what exactly is a blockchain, and what can you still do now that everyone has finally jumped on the cryptocurrency bandwagon?

Continue reading “The 348,296th Article About Cryptocurrency” →

Entropy And The Arduino: When Clock Jitter Is Useful

January 8, 2018 by Jenny List 37 Comments

What do you do, when you need a random number in your programming? The chances are that you reach for your environment’s function to do the job, usually something like rand() or similar. This returns the required number, and you go happily on your way.

A shift register configured as a pseudo-random number generator. — A shift register configured as a pseudo-random
number generator. [by KCAuXy4p CC0 1.0]

Except of course the reality isn’t quite that simple, and as many of you will know it all comes down to the level of randomness that you require. The simplest way to generate a random number in software is through a pseudo-random number generator, or PRNG. If you prefer to think in hardware terms, the most elementary PRNG is a shift register with a feedback loop from two of its cells through an XOR gate. While it provides a steady stream of bits it suffers from the fatal flaw that the stream is an endlessly repeating sequence rather than truly random. A PRNG is random enough to provide a level of chance in a computer game, but that predictability would make it entirely unsuitable to be used in cryptographic security for a financial transaction.

There is a handy way to deal with the PRNG predictability problem, and it lies in ensuring that its random number generation starts at a random point. Imagine the shift register in the previous paragraph being initialised with a random number rather than a string of zeros. This random point is referred to as the seed, and if a PRNG algorithm can be started with a seed derived from a truly unpredictable source, then its output becomes no longer predictable.

Selecting Unpredictable Seeds

Computer systems that use a PRNG will therefore often have some form of seed() function alongside their rand() function. Sometimes this will take a number as an argument allowing the user to provide their own random number, at other times they will take a random number from some source of their own. The Sinclair 8-bit home computers for example took their seed from a count of the number of TV frames since switch-on.

The not-very-random result of a thousand analogRead() calls.

The Arduino Uno has a random() function that returns a random number from a PRNG, and as you might expect it also has a randomSeed() function to ensure that the PRNG is seeded with something that will underpin its randomness. All well and good, you might think, but sadly the Atmel processor on which it depends has no hardware entropy source from which to derive that seed. The user is left to search for a random number of their own, and sadly as we were alerted by a Twitter conversation between @scanlime and @cybergibbons, this is the point at which matters start to go awry. The documentation for randomSeed() suggests reading the random noise on an unused pin via analogRead(), and using that figure does not return anything like the required level of entropy. A very quick test using the Arduino Graph example yields a stream of readings from a pin, and aggregating several thousand of them into a spreadsheet shows an extremely narrow distribution. Clearly a better source is called for.

Noisy Hardware or a Jittery Clock

As a slightly old-school electronic engineer, my thoughts turn straight to a piece of hardware. Source a nice and noisy germanium diode, give it a couple of op-amps to amplify and filter the noise before feeding it to that Arduino pin. Maybe you were thinking about radioactive decay and Geiger counters at that point, or even bouncing balls. Unfortunately though, even if they scratch the urge to make an interesting piece of engineering, these pieces of hardware run the risk of becoming overcomplex and perhaps a bit messy.

The significantly more random result of a thousand Arduino Entropy Library calls.

The best of the suggestions in the Twitter thread brings us to the Arduino Entropy Library, which uses jitter in the microcontroller clock to generate truly random numbers that can be used as seeds. Lifting code from the library’s random number example gave us a continuous stream of numbers, and taking a thousand of them for the same spreadsheet treatment shows a much more even distribution. The library performs as it should, though it should be noted that it’s not a particularly fast way to generate a random number.

So should you ever need a truly random number in your Arduino sketch rather than one that appears random enough for some purposes, you now know that you can safely disregard the documentation for a random seed and use the entropy library instead. Of course this comes at the expense of adding an extra library to the overhead of your sketch, but if space is at a premium you still have the option of some form of hardware noise generator. Meanwhile perhaps it is time for the Arduino folks to re-appraise their documentation.

The subject of entropy and generating random numbers is one that has appeared on these pages many times. [Voja Antonic] made a in-depth study using uninitialized RAM as an entropy source for microcontrollers. If you have an insatiable appetite for understanding Linux entropy, we point you at [Elliot Williams]’ comprehensive examination of the subject.

[Arduino image: DustyDingo Public domain]