Try This For 3D Printing Without Support

Have a look at the object to the right. Using a conventional fused deposition printer, how would you print the object? There’s no flat surface to lay on the bed without generating a lot of overhangs. That usually requires support.

In theory, you might be able to print the bottom of the sphere down, but it is difficult to get that little spot to adhere to the bed. If you have at least two extruders and you are set up to print support material, that might even be the best option. However, printing support out of the same material you are printing with makes it hard to get a good clean print. There is another possibility. It does require some post-processing, but then again, not as much as hacking away a bunch of support material.

A Simple Idea

The idea is simple and — at first — it will sound like a lot of trouble. The basic idea is to cut the model in half at some point where both halves would be easy to print and then glue them together.  Stick around (no pun intended), though, because I’ll show you a way to make the alignment of the parts almost painless no matter how complex the object might be.

The practical problem with gluing together half models is getting the pieces in the exact position, but that turns out to be easy if you just make a few simple changes to your model. Another lesser problem is clamping a piece while gluing. You can use a vise, but some oddly-shaped parts are not conducive to traditional vise jaws.

In Practice

Starting with an OpenSCAD object, it is easy to cut the model in half. Actually, you could cut it anywhere. Then it is easy to rotate half of it so the cut line is at the bottom of each part. That doesn’t solve the alignment problem nor does it help you clamp when you glue.

The trick is to build a flange around each part. The flanges mate with a few screws after printing so alignment is perfect and bolts through the flange holes can keep the parts together and immobilized while your glue of choice sets. The kicker is that I even have an automated process to make the design side of this trick very easy.

Continue reading “Try This For 3D Printing Without Support”

Sonoff Factory Tour Is A Lesson On Life In Shenzhen

Judging by the popularity of “How It’s Made” and other shows of the genre, watching stuff being made is a real crowd pleaser. [Jonathan Oxer] from SuperHouse is not immune to the charms of a factory tour, so he went all the way to China to visit the factory where Sonoff IoT devices are made, and his video reveals a lot about the state of electronics manufacturing.

Test jig for six units at once

For those interested only in how Sonoff devices are manufactured, skip ahead to about the 7:30 mark. But fair warning — you’ll miss a fascinating discussion of how Shenzhen rose from a sleepy fishing village of 25,000 people to the booming electronics mecca of 25 million that it is today. With growth supercharged by its designation as a Special Economic Zone in the 1980s, Shenzhen is now home to thousands of electronics concerns, including ITEAD, the manufacturers of the Sonoff brand. [Jonathan]’s tour of Shenzhen includes a trip through the famed electronics markets where literally everything needed to build anything can be found.

At the ITEAD factory, [Jonathan] walks the Sonoff assembly line showing off an amazingly low-tech process. Aside from the army of pick and places robots and the reflow and wave soldering lines, Sonoff devices are basically handmade by a small army of workers. We lost count of the people working on final assembly, testing, and packaging, but suffice it to say that it’ll be a while before robots displace human workers in electronic assembly, at least in China.

We found [Jonathan]’s video fascinating and well worth watching. If you’re interested in Sonoff’s ESP8266 offerings, check out our coverage of reverse engineering them. Or, if Shenzhen is more your thing, [Akiba]’s whirlwind tour from the 2016 Superconference will get you started.

Continue reading “Sonoff Factory Tour Is A Lesson On Life In Shenzhen”

Amazon Echo Dot Upgraded To Retro Futuristic Look

It takes a surprising amount of planning and work if you want something to look old. [vemeT5ak] wanted the Echo Dot sitting on his desk to fit a different aesthetic motivated by a 1940s Canadian radio. Armed with Solidworks, a Tormach CNC, and some woodworking tools at Sector67 hackerspace, he built a retro-futuristic case for the Amazon Alexa-enabled gadget. Future and past meet thanks to the design and material appearance of the metal grille and base molding wrapping the wood radio case. The finishing touch is of course the ring of blue light which still shines through from the Echo itself.

A short USB extension cable connects the Echo Dot to the back of the enclosure, and the cavernous inside plus ample holes provide a nice rich sound.

It took about 15 hours of modeling, scaling, and tweaking in Solidworks with an interesting design specification in mind: single-bit operation. This single-bit is not in the electrical sense, but refers to the CNC milling operation. All pieces are cut with a 1/4″ end mill, without any tool changes. Metal pieces were milled from 6061 aluminum and the hickory case (with burgundy stain) was mostly cut on a table saw, but the holes were CNC machined.

What looks like an otherwise perfect build has a single flaw that eats up [vemeT5ak]’s soul; the Echo Dot has a draft angle that wasn’t considered during modeling, and the hole is ever so slightly too wide, meaning it didn’t press fit perfectly flush. Fortunately it’s not noticeable behind the metal grill, and unless you knew (please help keep his dirty little secret), you would think everything turned out perfectly.

It turns out building a case for the Echo Dot is challenging for a few reasons; the rubbery material on the bottom doesn’t allow anything to stick to it, and the sides are smooth and featureless with a taper that makes it difficult to lock it in. Many cases resort to clipping over the top to hold it in place. Others install it into a fish or a furby.

34C3: Ultimate Apollo Guidance Computer Talk

While it might not be as exciting as the Saturn V rocket itself, the Apollo Guidance Computer (AGC) was one of the most important developments of the entire Apollo program. While comically underwhelming compared to modern hardware, the AGC was nothing short of revolutionary when it was developed in the 1960’s. Before the AGC, the smallest computers were about the size of a refrigerator and consumed hundreds of watts; both big problems if you’re trying to pack them into a relatively tiny space capsule with limited resources. Not only did the AGC get humanity to the Moon and back, but it also redefined the state of the art for microcomputers, paving the way for the desktop systems of the 1970’s.

That said, the design and operation of the AGC is downright bizarre to modern eyes; it comes from a time of limitations we can hardly fathom. With this in mind, [Michael Steil] and [Christian Hessmann] put together “The Ultimate Apollo Guidance Computer Talk” for 34C3.

This hour-long presentation walks viewers through every aspect of not only the AGC itself, but how it interacted with the Saturn V rocket and the overall lunar mission. Even if you aren’t enough of a vintage computing aficionado to appreciate the complexities of core rope memory, the presentation gives a fascinating look at the gritty details of one of humanity’s greatest achievements.

Though very slick and easy to understand graphics, [Michael] and [Christian] break down the alien world of the AGC. Even if a lot of this part of the presentation goes over your head, just listen for the sounds of laughter or applause from the audience: that’s when you’re looking at something really off-the-wall.

Of particular note during this presentation is the explanation of how the astronauts actually interacted with the AGC. The AGC’s display and keyboard (referred to as DSKY) may seem rather obtuse even to those who used to hack on a VT100, but [Michael] and [Christian] explain how it’s not quite as complex as it seems. Comparing the input and output of the DSKY with what we would see on a more contemporary command line interface, the presentation makes the case that it’s actually a very straightforward way of talking to the computer.

There’s also a complete breakdown of the different phases of the Apollo mission from launch to landing, explaining what the AGC would be doing at any given time. The DSKY is overlaid on actual footage from the Apollo missions, giving a unique perspective as to what the astronauts would see on their computer during iconic moments such as stage separation or lunar touchdown.

If this presentation has you hungry for more Apollo-era computer technology, we’ve covered plenty of projects to keep you occupied. From building a replica DSKY to leisurely paging through the printed version of the AGC’s source code.

Learning ARM Assembly With VisUAL

Learning assembly is very important if you want to get a grasp of how a computer truly works under the hood. VisUAL is a very capable ARM emulator for those interested in learning the ARM assembly.

The GUI: A simply program to ADD two numbers

In addition to supporting a large subset of ARM instructions, the CPU is emulated via a series of elaborate and instructive animations that help visualise the flow of data to/from registers, any changes made to flags, and any branches taken. It also packs very useful animations to help grasp some of the more tricky instruction such as shifts and stack manipulations.

As it is was designed specifically to be used as teaching tool at Imperial College London, the GUI is very friendly, all the syntax errors are highlighted, and an example of the correct syntax is also shown.

Branch visualisation, credits: VisUAL homepage

You can also do the usual things you would expect from any emulator, such as single step through execution, set breakpoints, and view data in different bases. It even warns you of any possible infinite loops!

That being said, lugging such an extravagant GUI comes at a price; programs that consume a few hundred thousand cycles hog far too much RAM should be run in the supported headless mode.

 

34C3: Hacking Into A CPU’s Microcode

Inside every modern CPU since the Intel Pentium fdiv bug, assembly instructions aren’t a one-to-one mapping to what the CPU actually does. Inside the CPU, there is a decoder that turns assembly into even more primitive instructions that are fed into the CPU’s internal scheduler and pipeline. The code that drives the decoder is the CPU’s microcode, and it lives in ROM that’s normally inaccessible. But microcode patches have been deployed in the past to fix up CPU hardware bugs, so it’s certainly writeable. That’s practically an invitation, right? At least a group from the Ruhr University Bochum took it as such, and started hacking on the microcode in the AMD K8 and K10 processors.

The hurdles to playing around in the microcode are daunting. It turns assembly language into something, but the instruction set that the inner CPU, ALU, et al use was completely unknown. [Philip] walked us through their first line of attack, which was essentially guessing in the dark. First they mapped out where each x86 assembly codes went in microcode ROM. Using this information, and the ability to update the microcode, they could load and execute arbitrary microcode. They still didn’t know anything about the microcode, but they knew how to run it.

So they started uploading random microcode to see what it did. This random microcode crashed almost every time. The rest of the time, there was no difference between the input and output states. But then, after a week of running, a breakthrough: the microcode XOR’ed. From this, they found out the syntax of the command and began to discover more commands through trial and error. Quite late in the game, they went on to take the chip apart and read out the ROM contents with a microscope and OCR software, at least well enough to verify that some of the microcode operations were burned in ROM.

The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)

[Benjamin] then bravely stepped us through the browser-based attack live, first in a debugger where we could verify that their custom microcode was being triggered, and then outside of the debugger where suddenly xcalc popped up. What launched the program? Calculating a particular number on a website from inside an unmodified browser.

He also demonstrated the introduction of a simple mathematical error into the microcode that made an encryption routine fail when another particular multiplication was done. While this may not sound like much, if you paid attention in the talk on revealing keys based on a single infrequent bit error, you’d see that this is essentially a few million times more powerful because the error occurs every time.

The team isn’t done with their microcode explorations, and there’s still a lot more of the command set left to discover. So take this as a proof of concept that nearly completely undetectable trojans could exist in the microcode that runs between the compiled code and the CPU on your machine. But, more playfully, it’s also an invitation to start exploring yourself. It’s not every day that an entirely new frontier in computer hacking is bust open.

Ergonomic Keyboard Designed From The Ground Up

In 2011, [Fabio] had been working behind a keyboard for about a decade when he started noticing wrist pain. This is a common long-term injury for people at desk jobs, but rather than buy an ergonomic keyboard he decided that none of the commercial offerings had all of the features he needed. Instead, he set out on a five-year journey to build the perfect ergonomic keyboard.

Part of the problem with other solutions was that no keyboards could be left in Dvorak (a keyboard layout [Fabio] finds improves his typing speed) after rebooting the computer, and Arduino-based solutions would not make themselves available to the computer’s BIOS. Luckily he found the LUFA keyboard library, and then was able to salvage a PCB from another keyboard. From there, he programmed everything on a Teensy microcontroller, added an OLED screen, and soldered it all together (including a set of Cherry MX switches).

Of course, the build wasn’t truly complete until recently, when a custom two-part case was 3D printed. The build quality and attention to detail in this project is impressive, and if you want to roll out your own [Fabio] has made all of the CAD files and software available. Should you wish to incorporate some of his designs into other types of specialized keyboards, there are some ideas floating around that will surely improve your typing or workflow.