Author: Mike Szczys

6403 Articles

Shah Selbe: Science In The World’s Wildest Places

January 22, 2018 by 2 Comments

When we think of building research hardware, lab coats and pristine workbenches come to mind. Shah Selbe used to do something kind of like that when he was engineering satellite propulsion systems. But after putting twelve of them into space, he ditched the office gig and took his gear to some of the wildest places on earth. He’s an explorer and fellow with the National Geographic Society, and at the Hackaday Superconference he shared his experiences building research hardware that gathers data in incredibly remote places.

Shah makes a really good point about two very different trends in our world over the past several decades. While we’ve had unparalleled technological growth, we’ve also seen horrifying wildlife trends to the point that some scientists believe we’re currently in a sixth mass extinction event. But to know that for sure, and look for ways to prevent and reverse it, we need reliable data. This is a fascinating problem because the world is huge, and we simply can’t monitor everything.

Continue reading “Shah Selbe: Science In The World’s Wildest Places” →

Hackaday Belgrade Call For Proposals Now Open!

January 22, 2018 by 6 Comments

Prepare yourself for the return of Hackaday Belgrade! Our premier European conference — Hackaday Belgrade — is on 26 May and we want to hear what you’ve been working on. The Call for Proposals is now open. We seek talks and workshops exploring the most interesting uses of technology and the culture that goes along with it. This includes design, prototyping, research, manufacturing, and the stories of people and progress that move hardware hacking forward.

We’ve booked Dom Omladine for the event because it was perfect for our previous Belgrade conference in 2016. The sold-out conference became a living organism of excitement when the Hackaday community from across Europe came together. A spectacular slate of speakers presented topics like designing computing clusters for use in University research programs, combining projection mapping with high powered lasers, building hardware for advertising campaigns, uncovering forgotten projector technology called Eidophor, fully embracing Open Hardware during product development, and so much more. All of this while hundreds in attendance joined forces for some of the best hardware badge hacking we’ve ever seen.

Hackaday Belgrade is the rare kind of opportunity that is worth reorganizing your life to attend. Want to guarantee yourself a ticket? They’re not available yet, but you can hack your way into the conference: submit a proposal! In addition to the adoration of the Hackaday community, accepted speakers will receive free admission. Everyone who submits a quality talk proposal will be given priority when tickets do go on sale. This event will sell out!

For updates, keep an eye on the conference page and pop into the chat on the project page by clicking “Join this project’s team”. Do you know someone who should be a speaker at this conference? Reach out to them personally, share this CFP on social media, or let us know in the comments below so we can make it happen.

Coin Cell Hacks That Won The Coin Cell Challenge

January 15, 2018 by 22 Comments

It’s amazing what creative projects show up if you give one simple constraint. In this case, we asked what cool things can be done if powered by one coin cell battery and we had about one hundred answers come back. Today we’re happy to announce the winners of the Coin Cell Challenge.

Continue reading “Coin Cell Hacks That Won The Coin Cell Challenge” →

Let’s Talk Intel, Meltdown, And Spectre

January 5, 2018 by 150 Comments

This week we’ve seen a tsunami of news stories about a vulnerability in Intel processors. We’re certain that by now you’ve heard of (and are maybe tired of hearing about) Meltdown and Spectre. However, as a Hackaday reader, you are likely the person who others turn to when they need to get the gist of news like this. Since this has bubbled up in watered-down versions to the highest levels of mass media, let’s take a look at what Meltdown and Spectre are, and also see what’s happening in the other two rings of this three-ring circus.

Meltdown and Spectre in a Nutshell

These two attacks are similar. Meltdown is specific to Intel processors and kernel fixes (basically workarounds implemented by operating systems) will result in a 5%-30% speed penalty depending on how the CPU is being used. Spectre is not limited to Intel, but also affects AMD and ARM processors and kernel fixes are not expected to come with a speed penalty.

Friend of Hackaday and security researcher extraordinaire Joe Fitz has written a superb layman’s explanation of these types of attacks. His use of the term “layman” may be a little more high level than normal — this is something you need to read.

The attack exploits something called branch prediction. To boost speed, these processors keep a cache of past branch behavior in memory and use that to predict future branching operations. Branch predictors load data into memory before checking to see if you have permissions to access that data. Obviously you don’t, so that memory will not be made available for you to read. The exploit uses a clever guessing game to look at other files also returned by the predictor to which you do have access. If you’re clever enough, you can reconstruct the restricted data by iterating on this trick many many times.

For the most comprehensive info, you can read the PDF whitepapers on Meltdown and Spectre.

Update: Check Alan Hightower’s explanation of the Meltdown exploit left as a comment below. Quite good for helping deliver better understanding of how this works.

Frustration from Kernel Developers

These vulnerabilities are in silicon — they can’t be easily fixed with a microcode update which is how CPU manufacturers usually workaround silicon errata (although this appears to be an architectural flaw and not errata per se). An Intel “fix” would amount to a product recall. They’ve already said they won’t be doing a recall, but how would that work anyway? What’s the lead time on spinning up the fabs to replace all the Intel chips in use — yikes!

So the fixes fall on the operating systems at the kernel level. Intel should be (and probably is behind the scenes) bowing down to the kernel developers who are saving their bacon. It is understandably frustrating to have to spend time and resources patching these vulnerabilities, which displaces planned feature updates and improvements. Linus Torvalds has been throwing shade at Intel — anecdotal evidence of this frustration:

“I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.”

That’s the tamest part of his message posted on the Linux Kernel Mailing List.

Stock Sales Kerfuffle is Just a Distraction

The first thing I did on hearing about these vulnerabilities on Tuesday was to check Intel’s stock price and I was surprised it hadn’t fallen much. In fact, peak to peak it’s only seen about an 8% drop this week and has recovered some from that low.

Of course, it came out that back in November Intel’s CEO Bryan Krzanich sold off his Intel stock to the tune of $24 Million, bringing him down to his contractual minimum of shares. He likely knew about Meltdown when arranging that sale. Resist the urge to flame on this decision. Whether it’s legal or not, hating on this guy is just a distraction.

What’s more interesting to me is this: Intel is too big to fail. What are we all going to do, stop using Intel and start using something else? You can’t just pull the chip and put a new one in, in the case of desktop computers you need a new motherboard plus all the supporting stuff like memory. For servers, laptops, and mobile devices you need to replace the entire piece of equipment. Intel has a huge market share, and silicon has a long production cycle. Branch prediction has been commonplace in consumer CPUs going back to 1995 when the Pentium Pro brought it to the x86 architecture. This is a piece of the foundation that will be yanked out and replaced with new designs that provide the same speed benefits without the same risks — but that will take time to make it into the real world.

CPUs are infrastructure and this is the loudest bell to date tolling to signal how important their design is to society. It’s time to take a hard look at what open silicon design would bring to the table. You can’t say this would have been prevented with Open design. You can say that the path to new processors without these issues would be a shorter one if there were more than two companies producing all of the world’s processors — both of which have been affected by these vulnerabilities.

Remember When Scratch-Built Robots Were Hard?

January 2, 2018 by 10 Comments

Even simple robots used to require quite a bit of effort to pull together. This example shows how far we’ve come with the tools and techniques that make things move and interact. It’s a 3D printed rover controlled by the touchscreen on your phone. This achieves the most basic building block of wheeled robotics, and the process is easy on you and your pocketbook.

We just can’t stop loving the projects [Greg Zumwalt], aka[gzumwalt], is turning out. We just saw his air-powered airplane engine and now this little rover perks our ears up. The design uses the familiar trick of two powered wheels with a ball bearing to avoid problems with differential turning. But the simplicity is all in the implementation.

This bot is 3D printed using eight very simple pieces: four gears, two axles, a cap and a single tray to mount everything. The cap captures the ball bearing which pokes out a hole in the bottom of the tray to form an omnidirectional wheel. Two 9G servos modified for continuous rotation. The mating teeth of the gears are found on the wheel sections which have grooves for neoprene O-rings to provide traction. The entire thing is driven by an ESP8266 in the form of an Adafruit Feather Huzzah. This is programmed using the Arduino IDE and your phone can connect directly or through a WiFi router.

We’re not crazy, right? Robots didn’t used to be this easy to pull together? This goes for the power of 3D printing versus traditional basement fabrication methods, but in the availability of powerful yet inexpensive embedded systems and the available tools and libraries to program them. Kudos to you [Greg] for showing us how great the currently available building blocks are in the hands of anyone who wants to channel their engineering creativity. He certainly has… this chassis ultimately powers Santa’s sleigh.

Need a bigger printing challenge? Here’s a 3D printed rover that goes all-in with the suspension system.

Continue reading “Remember When Scratch-Built Robots Were Hard?” →

Laptop With Raspberry Pi Inside Learns To Speak Battery

December 30, 2017 by 6 Comments

Early in November we took a look at a one of the best Raspberry Pi laptops we had ever seen, using the shell of a Sony VAIO. Laptops used to be hulking beasts, and that played into [Frank Adams’] hands as he got rid of the motherboard and had enough space to replace it with a Raspberry Pi and a few other support boards. This took advantage of the laptop’s screen, keyboard, LEDs, etc. But what’s a laptop without battery power? [Frank] hadn’t cracked that nut until now.

Inside of Sony VAIO laptop turned Raspberry Pi computer
VAIO battery and charging PCB seen to lower left

Adding battery power is trickier that it sounds, but [Frank] managed to get the Raspberry Pi to talk to the original Sony VAIO internal battery. His work on the project is shared, but this part of the story is best found starting on page 29 of his PDF project details.

Using the original battery is a good move since it’s designed to fit and has a charger ready to interface with the port on the laptop case. But these batteries have logic inside them, and there’s the rub. Communications use the 2-wire System Management Bus (SMBus) which is well documented. But the when trying to use the Pi’s I2C [Frank] couldn’t figure out to send a repeated start command.

He ended up writing his own C program that bit-bangs the communications he needed and now has the Pi speaking to the battery and listening to what it hears coming back. Reading through his description of this is fun since he includes his observations from a logic analyzer captures. He suspects an occasional bad read is due to Linux interrupting code execution. He watches for and catches these bad reads in software and can now reliably read all the battery vitals.

The hack leaves him with a system that functions in much the same way the original computer did: plug it in and it charges. He did add some hardware that lets him take a voltage reading from the battery using an ADC on the Teensy that was already present to control the keyboard and case LEDs. This adds a small constant draw on the battery, but for now he doesn’t leave the battery connected when the laptop is not in use.

If you’d like to read our original coverage of this laptop, here it is.

[Ken Shirriff] Becomes A Core Memory Repairman (Again)

December 29, 2017 by 5 Comments

Lately, [Ken Shirriff] has been on some of the most incredible hardware adventures. In his most recent undertaking we find [Ken] elbow-deep in the core memory of a 50-year-old machine, the IBM 1401. The computer wasn’t shut down before mains power was cut, and it has refused to boot ever since. The culprit is in the core memory support circuitry, and thanks to [Ken’s] wonderful storytelling we can travel along with him to repair an IBM 1401.

From a hardware standpoint core memory makes us giddy. It’s a grid of wires with ferrite toroids at every intersection. Bits can be set or cleared based on how electricity is applied to the intersecting wires. [Al Williams] walked through some of the core memory history last year and we enjoyed hearing [Pamela Liou] recount the story of how textile workers consulted on the fabrication of core memory for the Apollo missions during her OHWS Talk in October. But giddiness aside, core memory has pretty much gone the way of the dodo having been displaced by technologies that take up exponentially less space.

Bad inductor (green housing has been dissolved away)

We chuckle at [Ken’s] mention of the core memory capacity for the IBM 1401. It has 4000 characters of memory built-in (with another 12,000 in an expansion box) and he goes on to detail that these are 6-bit characters on a machine that operates in decimal and not binary (hence 4k instead of the base-2 friendly 4096).

You may remember his work a few years back to repair core memory on the same model. The Museum has two 1401’s, which turned out to be a huge help in trouble-shooting this. After tracing out the control lines, the repair team began swapping cards between the working and non-working machines. They were able to bring it back online — establishing one of the green inductors was bad — only to be struck with a second fault in the power supply.

Get this, [Ken] comments that “the whole computer is pre-silicon”. When working through the PSU, some suspect transistors were replaced with germanium power transistors. Those may have been a red-herring, as a penciled-in fuse on the original schematics turned out to be the linchpin of the PSU repair. Buried deep in the assembly, replacing the designed-to-fail part let the ancient beast awake once more.

Machines of this quality were heavily documented, and the schematics make this type of trouble-shooting a lot more manageable. But it’s still as much an art as it is skill. Make sure to give [Ken’s] article a read, and look around at the other repair jobs he’s documented — keeping these machines in service is becoming wizard-level work and we love being able to follow along.