Syndicate content Hackaday
Fresh hacks every day
ถูกปรับปรุง 2 hours 31 min ก่อน

Sphero Wasn’t Actually Behind the BB-8

ศุกร์, 09/04/2015 - 22:31

Despite quite a few articles stating Sphero was behind the technology that made the real movie BB-8 droid, like this Tech Crunch article:

Sphero, makers of the eponymous spherical robots that you control with your smartphone — as well as the new BB-8 droid in Star Wars: The Force Awakens

and this excerpt from Fortune Magazine:

The same underlying technology (made by Sphero), which was licensed to create the version of BB-8 that graced the stage at the Star Wars Celebration…

Heck, even we drank the jungle juice with our original coverage! But now it seems the truth is finally coming out. As it turns out, it was actually built in Pinewood by the Creature Animatronics (CFX) team which includes [Matt Denton] — He’s the guy who built the Mantis Robot. A hacker / engineer — not a big toy company.

Two articles released this week on StarWars.com and EmpireOnline.com name various people from the CFX team at Pinewood as having built the movie puppets and the real BB-8. No mention of Sphero at all of course. They also state that they had to come up with the technology from scratch and that nothing like it already existed.

The analysis here is that basically Disney has a share holding in Sphero — they have now received $81 million of external investment off the back of it, so it’s ultimately all about the bottom line. The information about Sphero being behind the real BB-8, which neither Disney or Sphero had previously denied, was kicked off by the statement during the footage of the real BB-8 on stage that “it was all made possible by Bob Iger”. [Bob] is the CEO of Disney and brought Sphero into his accelerator program for start-ups. Obviously it’s taken until now for the CFX team to get any credit whatsoever for building BB-8.

The funny thing is, some of the news outlets have started to change the story concerning Sphero/BB-8, like this article about the new Sphero toy, covered by Gizmodo — conveniently edited over night (you’ll have to take our word for it), to no longer state that Sphero was behind the technology for the real BB-8:

It was rumored that Sphero, a company that’d been been making remote control robotic balls for years, was behind the real-life version of BB-8. It wasn’t, but that didn’t stop the toy world rumor-mill from also getting excited about Sphero possibly turning its existing robotic toy ball into a miniature version of BB-8. And good news for Star Wars fans—at least some of those rumors turned out to be true.

It’s unfortunate that big companies like this will take credit for something that they did not do, but we’re happy to see the truth coming out of the wood work.

And regardless of BB-8’s origins, which we’ve confirmed is definitely not Sphero tech, the new toy Sphero did release is pretty darn cool:

Filed under: news, robots hacks, toy hacks

Embed with Elliot: Practical State Machines

ศุกร์, 09/04/2015 - 21:01

Raindrops on roses, and whiskers on kittens. They’re ok, but state machines are absolutely on our short list of favorite things.

There are probably as many ways to implement a state machine as there are programmers. These range from the terribly complex, one-size-fits-all frameworks down to simply writing a single switch...case block. The frameworks end up being a little bit of a black box, especially if you’re just starting out, while the switch...case versions are very easy to grok, but they don’t really help you write clear, structured code.

In this extra-long edition of Embed with Elliot, we’ll try to bridge the middle ground, demonstrating a couple of state machines with an emphasis on practical coding. We’ll work through a couple of examples of the different ways that they can be implemented in code. Along the way, we’ll Goldilocks solution for a particular application I had, controlling a popcorn popper that had been hacked into a coffee roaster. Hope you enjoy.

What’s a State Machine?

State machines are basically a set of constraints that you set on the way you’d like to approach a problem. Specifically, you try to break your problem down to a bunch of states. In each state, the machine has a given output, which can either depend on a list of variable inputs to the state, or not. Each state also has a list of events which can trigger a transition to another state.

Mapping out your application in terms of what can happen in which state, and then when the machine transitions from one state to the next helps you clearly define your problem. When your code has a structure that makes it easy to plug these concepts in, everything is peachy.

For instance, when you fire up your coffee roaster, it may enter an initialization state, take some actions, and then go straight into a waiting-for-input state. In the waiting-for-input state, there may be two event-driven transitions possible: when one button is pressed it might go into a preheating state where it turns on the fan and heater, or when another button is pressed it might go into a configuration state where it lets you set the desired final roast temperature. The point of defining the states is that they limit when certain actions can happen — you don’t need to worry about setting the roast temperature in the preheating state, for instance.

Picking the right set of limitations to apply to your project’s code gives it structure, and once you get used to the state machine structure, you might find it useful for you. Of course, there are other, grander reasons to think about your problem in terms of a state machine.

One is that they are particularly easy to represent either graphically or in a table, which makes documentation (and later bug-hunting) a lot easier. The other is that, for applications like automatic code generation and automatic FPGA synthesis, there are sophisticated tools that transform your description of the state machine into a finished product without you getting your hands dirty with any of the actual coding.

Hackaday’s own Al Williams recently wrote an article covering state machines in these terms, and his article is a great complement to this one. If you’d like more state machine background, go give his excellent article a read. Here, we’re just interested in making your embedded coding life easier by presenting a few possible design patterns that have stood the test of time.

The Coffee Roaster Application

A concrete example is worth a thousand words, so let’s start off with a perfect state machine application: controlling a small home appliance. In this case, an air popcorn popper that was hacked into service as a small-batch coffee roaster.

The former popcorn popper had a fan that blew the popcorn around and a heater that heat up the air before it entered the popping tube. Both fan and heater were on the same circuit, with the voltage drop across the heater coil cleverly chosen so that the remaining voltage could run the fan motor more or less directly. It also had a thermal fuse to keep it from burning up, and an on-off switch. That’s all, and that’s all that’s necessary for the job.

To turn the popper into a coffee roaster, the fan and heater circuits were cut apart and made separately controllable. The fan got its own 16 V DC power supply, switched on an off with a power MOSFET. The heater runs through a solid-state relay to the mains power. Since the roaster was supposed to have temperature control, a thermocouple and amplifier (with SPI interface) were added. This is all tied together by a microcontroller that’s got four user pushbuttons plus reset, two LEDs, a TTL serial in/out, and a potentiometer connected to an ADC channel just for good measure.

Just writing this down gets us a lot of the way toward defining our state machine. For instance, we know what events are going to be driving most of our state transitions: four buttons and a temperature sensor. In practice, the machine also needs to know about elapsed times, so there’s a seconds counter running inside the microcontroller as well.

To come up with the relevant states, it doesn’t take much more than thinking about the desired roast profile. It turns out that roasting coffee is a lot like doing reflow soldering: you warm everything up, then ramp up the temperature at a controlled rate to a desired maximum, and then cool it back down again. From the roast profile, we get the states “preheat”, “soak”, “ramp”, and “cooldown” corresponding to the obvious phases of the process. Before the roast starts, the machine also goes through a “initialize” and “wait-for-input” states.

A further “emergency-shutdown” state was inspired by the real-life event where a wire came loose in the temperature probe and the roaster created charcoal instead of coffee. A nice thing about state-machine code is that you know exactly which sections of the code you have to modify when you’re adding a new state, and more importantly, which sections of code you don’t have to touch.

In each of the states the code controls the heater, the fan, and the LEDs, and potentially logs output over the serial port. These are our outputs. In the “preheat” state, for instance, the fan and heater are maxed out and the temperature rise is monitored to make sure that the thermocouple is working. If the panic button is pressed, the soak temperature is reached, or the thermocouple isn’t working, the machine moves on to another state.

With this background in mind, let’s look at two different code structures that can implement the same state machine.

Switch Statements

The simplest implementation of a state machine can be built with a chain of if...then...else statements. “If in state A, do something, else if in state B, do something else”, etc. The nesting and indentation get crazy after only a couple of states, and that’s what the switch...case statement is for. You’ll see a lot of state machines coded up like so:

int main(void) { enum states_e {INIT, WAIT_FOR_INPUT, PREHEAT, SOAK, ...}; enum states_e state = INIT; uint16_t temperature = 21; while (1){ switch(state){ case INIT: doInitStuff(); state = WAIT_FOR_INPUT; break; case WAIT_FOR_INPUT: if (buttonA_is_pressed()){ state = PREHEAT; } if (buttonD_is_pressed(){ state = SET_TEMPERATURE; } break; case PREHEAT: fanOn(); heaterOn(); if (temperature > SOAK_START){ state = SOAK; } if (test_thermo_not_working()){ state = EMERGENCY_SHUTDOWN; } break; etc. } temperature = measure_temperature(); } }

The code goes in an endless loop, testing which state it’s in and then running the corresponding code. The transitions between states are taken care of inside the handler functions, and are as simple as setting the state variable to the next state name. Instead of using numbers to enumerate the states, the code makes use of C’s enum statement which associates easy-to-read names with numbers behind the scenes. (Alternatively, this could be done with a bunch of #define statements, but the enum is sleeker and arguably less error-prone.)

The INIT state simply does its work and passes on to the next state. WAIT_FOR_INPUT doesn’t change the state variable unless a button is pressed, so the microcontroller spins around here waiting. The PREHEAT state actually starts the roaster going, and tests for the conditions that will bring it out of the preheating phase, namely the temperature getting hot enough or the temperature probe not being plugged in.

The EMERGENCY_SHUTDOWN state was added late in the firmware’s life, and it’s worth looking at where you need to touch the code to add or remove a state. Here it required a new enum entry, a new case statement in the switch to handle its behavior, and then transition code added into every other state that could possibly lead to a shutdown.

Finally, the temperature updating routine is called outside of the state machine. We’re not at all sure how this jibes with the state machine orthodoxy, but it’s a very handy place to have periodically polled actions take place, the results of which could possibly be relevant for the next pass through the state machine.

For small state machines, this style of writing a state machine is straightforward, decently extensible, and it’s pretty readable. But you can see how this could get out of hand pretty quickly as the number of states or the amount of code per state increases. It’s like a very long laundry list.

One possible solution to the sheer length of the switch...case statement is to break each state’s work off into a separate function, like so:

switch(global_state){ case INIT: handle_init_state(); break; case WAIT_FOR_INPUT: handle_wait_for_input_state(); break; etc. }

It’s shorter, for sure, and until you have a lot of states it’s not unmanageable. Notice that the state variable must now be made global (or otherwise accessible to each of the state handler functions) because the transitions occur inside each state handler function. If all the code does is implement the state machine, the state probably makes sense as a global variable anyway, so that’s no big deal. A little more disconcerting is that the temperature variable, and every other argument to a state handler, will need to be declared global as it stands now, but let’s just roll with it for a moment.

Wrapping up the switch...case version, you need to do three things when you add a new state:

  • add a new state name to the enum
  • write your new handler code in its case statement
  • write transitions for all of the states that can lead to the new state
Function Pointers Version

Let’s see what we can do to streamline and simplify the switch...case version of the state machine. Each state name matches with one and exactly one handler function, and the change in handler function is all that differs across states. In other words, the handler function really _is_ the state. The global_state variable that gives a name to each of the states, that we thought of as being the central mechanism, is actually superfluous. Whoah!

We could get rid of the switch...case statement and the global_state variable if only we could store the function that we’d like to call in a variable. Instead of creating this big lookup table from state name to handler function, we could just run the stored state handler directly. And that’s exactly what function pointers do in C.

Function Pointers Aside

Here’s a quick rundown on pointers in general, and function pointers in particular. (We’ll have to do a pointers edition of “Embed with Elliot” in the future, because they’re a source of exquisite bugs and much confusion among people who are new to C.) When you define a function, the compiler stashes that function’s code somewhere in memory, and then associates the name you’ve given to the function with that memory location. So when your code calls the function do_something(), the compiler looks up a memory address where the code by that name is located and then starts running it. So far, so good?

Pointers are variables that essentially contain memory locations, and function pointers are variables that contain the address of code in memory. Pointers do a little more than just store a memory location, though. In the case of function pointers, they also need to know the type of arguments that the function requires and the type of the return value because the compiler needs to be able to set up for the function call, and then clean up after it returns. So a function pointer contains the memory address of some code to run, and also must be prototyped the same way as the functions it can point to.

If we have a couple functions defined, and we want to use a function pointer as a variable that can run either of the two functions, we can do it like so:

int add_one(int); int add_two(int); int (*function_pointer)(int); int add_one(int x){ return x+1; } int add_two(int x){ return x+2; } int a = 0; function_pointer = add_one; a = function_pointer(7); // a = 8; function_pointer = add_two; a = function_pointer(7); // a = 9;

What’s going on here? First we declare the functions, and then declare a function pointer that is able to point to these kind of functions. Notice that the function pointer’s declaration mimics the prototypes of the functions that it is allowed to point to.

After defining two trivial functions and a variable to store the result in, we can finally point the function pointer at a function. (That was fun to type!) Behind the scenes, the statement function_pointer = add_one takes the location in memory at which the function add_one is stored, and saves it in the function pointer. At the same time, it checks that the arguments and return value of the add_one function match those of the function pointer, to keep us honest.

Now comes the cool part: we can call the function pointer variable just as if we were calling the function that it points to. Why is this cool? Because we’ve written the exact same code, a = function_pointer(7), and gotten different answers depending on which function is being pointed to. OK, cool, but maybe a little bit confusing because now to understand the code, you have to know which function is being pointed to. But that’s exactly the secret to streamlining and simplifying our state machine!

Function Pointer State Machine

Now, instead of storing the state’s name in a variable and then calling different functions based on the name, we can just store the functions themselves in the state variable. There’s no need for the case...switch statement anymore, the code simply runs whatever code is pointed to. Transitions to another state are achieved by simply changing the handler function that’s currently stored in the state pointer.

It’s time for an example:

void handle_state_INIT(void); void handle_state_WAIT_FOR_INPUT(void); void (*do_state)(void); uint16_t temperature = 21; void handle_state_INIT(void){ doInitStuff(); do_state = handle_state_WAIT_FOR_INPUT; } void handle_state_WAIT_FOR_INPUT(void){ if (buttonA_is_pressed()){ do_state = handle_state_PREHEAT; } if (buttonD_is_pressed(){ do_state = handle_state_SET_TEMPERATURE; } } (etc.) int main(void) { // Do not forget to initialize me!!! do_state = handle_state_INIT; while(1){ do_state(); temperature = measure_temperature(); } }

As you can see, all of the per-state code is handled in its own functions, just as in the streamlined switch...case version, but we’ve gotten rid of the cumbersome switch...case construct and the global_state variable, replacing it with a global function pointer, do_state.

Now, when you want to add another state, all you have to do is write the new handler code and then add the transitions from each other state handler that can lead to our new state. Not having to fool around with the state enum is one less thing to worry about.

And note that nothing in the main() body needs to change at all; it calls whatever function is pointed to by the global do_state function pointer, and that gets updated in the state handlers with the rest of the state code.

Style-wise, it’s nice to prototype the functions that get pointed to and the function pointer that will point to them all in the same place because that makes it easy to spot any inconsistencies, which the compiler will thankfully also warn you about.

You might want to split the state handlers off into a separate module, and that’s particularly easy given the above framework. The function and function pointer prototypes go off into the module header, and the functions into the code file just as you’d expect. All global variables required for the handlers will also have to be declared extern in the module header.


There are still some loose ends to tie up here, like dealing properly with the proliferation of global variables that have been used to pass arguments to the state handler functions. A great solution for that case is to pass structs to the handlers that contain all of the relevant arguments, but that’s a tale for another time.

In the mean time, you’re hopefully sold on the possibility of casting some of your microcontroller projects in terms of state machines. Learning state machines is a great excuse to build a simple robot or domestic appliance, for instance. Give it a try. To really grok state machines, it helps a lot to break down some complex behaviors into states, events, transitions, and outputs. Just thinking your project through this way is half the battle.

But then once you’ve sketched the machine out on paper, take the next step and code something up. Start out with some simple scaffolding, either the switch...case variety or the function pointer version, and expand out your own code on it. You’ll be surprised how quickly the code can flow once you’ve got the right structure, and state machines can provide the right structure for a reasonably broad variety of tasks. They really are one of our favorite things!

Filed under: Hackaday Columns, Microcontrollers

Experimental Theater Helps Field test Haptic Navigation Device

ศุกร์, 09/04/2015 - 18:01

The “absorbed device user” meme, like someone following Google Maps on a smart phone so closely that they walk out into traffic, is becoming all too common. Not only can an interface that requires face time be a hazard to your health in traffic, it’s also not particularly useful to the visually impaired. Haptic interfaces can help the sighted and the visually impaired alike, but a smart phone really only has one haptic trick – vibration. But a Yale engineer has developed a 3D printed shape-shifting navigation tool that could be a haptics game changer.

Dubbed the Animotus by inventor [Ad Spiers], the device is a hand-held cube split into two layers. The upper layer can swivel left or right and extend or retract, giving the user both tactile and visual clues as to which direction to walk and how far to the goal. For a field test of the device, [Ad] teamed up with a London theater group in an interactive production of the play “Flatland”, the bulk of which was staged in an old church in total darkness. As you can see in the night-vision video after the break, audience members wearing tracking devices were each given an Animotus to allow them to navigate through the interactive sets. The tracking data indicated users quickly adapted to navigation in the dark while using the Animotus, and some became so attached to their device that they were upset by the ending of the play, which involved its mock confiscation and destruction.

Performing art applications aside, there’s plenty of potential for haptics with more than one degree of freedom. Imagine a Bluetooth interface to the aforementioned Google Maps, or an electronic seeing-eye dog that guides a user around obstacles using an Animotus and a camera. There’s still plenty of utility in traditional haptics, though, as this Hackaday Prize semi-finalist shows.

Filed under: 3d Printer hacks, misc hacks

Tint your Epoxy Resin with Toner Powder

ศุกร์, 09/04/2015 - 15:01

Epoxy resin is useful stuff. Whether for gluing stuff together or potting components, epoxy is a cheap and versatile polymer that finds its way into many hackish projects. But let’s face it – the stock color of most commercially available epoxies lacks a certain pizzazz. Luckily, [Rupert Hirst] at Tallman Labs shows us that epoxy is easily tinted with toner powder from a laser printer or copier.

Looking for a way to make his epoxy blend into a glue-up, [Rupert] also demonstrates that colored epoxy makes a professional looking potting compound. There’s just something about the silky, liquid look of a blob of cured black epoxy. [Rupert] harvested his toner powder from a depleted printer cartridge; only a smidgen is needed, so you should be able to recover plenty before recycling the cartridge. We’ve got to admit that seeing toner handled without gloves gives us the willies, though. And don’t forget that you can find cyan, magenta and yellow cartridges too if basic black isn’t your thing.

Sometimes it’s better to leave your epoxy somewhat clear, like when you’re potting an LED matrix for a pendant. But this neat trick might just spiff up your next project a bit.

[Thanks, Jake]

Filed under: how-to, misc hacks

Hackaday Prize Semifinalist: A Mobile Node

ศุกร์, 09/04/2015 - 12:01

The future is the Internet of Things, or so we’re told, and with that comes the requirement for sensors attached to the Internet that also relay GPS and location data. [Camilo]’s MobileNodes do just that. He’s designed a single device that will listen to any sensor, upload that data to the Internet over GSM or GPRS, and push all that data to the cloud.

The MobileNode is a small circular (7cm) PCB with a standard ATMega32u4 microcontroller. Attached to this PCB are GSM/GPRS and GPS/GLONASS modules to receive GPS signals and relay all that data to the cloud. To this, just about any sensor can be added, including light sensors, PIR sensors, gas and temperature sensors, and just about anything else that can be measured electronically.

Of course the biggest problem with a bunch of sensors on an Internet of Things device is pulling the data from the Internet. For that, [Camilo] designed a web interface that shows sensor data directly on a Google Map. You can check out the project video below.

The 2015 Hackaday Prize is sponsored by:

Filed under: The Hackaday Prize, wireless hacks

Sending Serial Data from… Excel?

ศุกร์, 09/04/2015 - 09:01

When you think about serial communications, Microsoft Excel isn’t typically the first program that springs to mind. But this spreadsheet has a rather powerful scripting language hidden away inside it, which can, with a little coding, be used to send and receive data over your serial port. The scripting language is called Visual Basic for Applications (VBA), and it has been a part of Microsoft’s Office suite since 1993. Since then, it has evolved into a powerful (if sometimes frustrating) language that offers a subset of the features from Visual Basic.

It can be a useful tool. Imagine, for instance, that you are logging data from an instrument that has a serial port (or even an emulated one over USB). With a bit of VBA, you could create a spreadsheet that talks to the instrument directly, grabbing the data and processing it as required straight into the spreadsheet. It’s a handy trick that I have used myself several times, and [Maurizio] does a nice job of explaining how the code works, and how to integrate this code into Excel.

If you’re looking for other ways to leverage this Excel feature, consider watching movies at work or building a virtual machine inside of your sheets.

Filed under: software hacks

The Kraakdoos — Musical Abuser of an Ancient OpAmp

ศุกร์, 09/04/2015 - 06:01

A friend from the newly founded Yeovil Hackerspace introduced me to a device known as “The Kraakdoos” or cracklebox.

The cracklebox is an early electronic instrument produced by STEIM in the 1970s. The instrument consists of a single PCB with a number of copper pads exposed on one side. The player touches the pads and the instrument emits… sounds which can perhaps best be described as squeeze and squeals.

While the cracklebox was original sold as a complete instrument, the device has been reverse engineered, and the schematic documented. What lies inside is quite fascinating.

The heart of the cracklebox is an ancient opamp, the LM709. The LM709 is the predecessor to the famous LM741. Unlike the 741 was 709 had no internal frequency compensation. Frequency compensation is used to intentionally limit the bandwidth of an opamp. As input frequency increases, the phase shift of the opamp also increases. This can result in undesirable oscillation, as the feedback network forms an unintentional phase-shift oscillator.

Most modern opamps have internal frequency compensation, but the 709 doesn’t. Let’s see how this is used in the cracklebox:

Rather than using the frequency compensation pins as intended the cracklebox just routes them out to pads. In fact the cracklebox routes almost all the pins on the opamp out to pads, including the inverting and non-inverting inputs. A single 1MOhm feedback resistor is used in a non-inverting configuration. However reports suggest the instrument can work without a feedback resistor at all!

The exact operational details of the instrument are therefore a slight mystery. However what’s clear is that without any frequency compensation the opamp is likely operating as a phase-shift oscillator. The output of the opamp goes to a push-pull output stage. This configuration is often used for efficiency. However as the transistors do not operate below 0.7 volts there is also a dead band, this results in a distorted signal in the cracklebox and also filters out low level background signals.

While it’s interesting to investigate the cracklebox design, it’s creation likely involved a lot of circuit bending, playing with component values and layout until the circuit sounded “cool” rather than adhering to any design rules. As such the cracklebox is an interesting confluence of circuit design as engineering and art.

Filed under: classic hacks, musical hacks

Mini Fridge turned Gameboy Puts Hot Games on Ice

ศุกร์, 09/04/2015 - 03:01

The plain old white mini fridge, a staple of many dorm rooms could use a little decoration. The resemblance to a classic gameboy is not that hard to imagine with some novelty stickers, but [ModPurist] went the extra mile with his Cold Boy.

Making a mini fridge into a playable gameboy involves taking apart the door, once in a Raspberry Pi 2 is fitted in along with a second hand “square screen” LCD. The front of the door is cut for some custom wooden buttons, which are connected to tactile switches. Once everything is fit and finished the door is reassembled, so the fridge can resume its normal life keeping soda and hot dogs good and cold. [ModPurist] covered the progression of the hack in his work log.

While it’s a little low to the ground, it should be a hit at college parties where being on the floor is not unusual. Join us after  the break for a demonstration video and get your game on. It is, of course, missing one thing. There needs to be some type of latch inside to secure the beverages until the Konami code is entered.

Filed under: Beer Hacks, nintendo gameboy hacks, Raspberry Pi

How to Build Anything Using Delrin and a Laser Cutter

ศุกร์, 09/04/2015 - 00:01

Need a simple fab process to go from a humble vector graphic to a final part — in a matter of minutes? The CO2  laser cutter might be the right choice. As these tools open themselves up to widespread use through hackerspaces, I decided to give Delrin some well-deserved time under the spotlight.

The laser cutter yet-again proves itself a formidable tool with the construction of GameCube-Bot V2

This guide is a brief collection of tips and techniques that I’ve either learned from others or discovered on my own over the last couple years working with laser-cut Delrin (a.k.a Acetal) for functional prototypes. I hope this guide serves you well as we keep exploring the limits of the material.

As a disclaimer, keep in mind that in no way are these techniques unique or limited to Delrin. Many are not only years old but also common practice in either engineering design or the local machine shop. This article simply highlights the techniques shown here that perform both repeatably and predictably with Delrin and a couple hand-tools, and I hope to share them with a growing audience of laser cutter enthusiasts.

Why Delrin?

I won’t deny that I’ve seen posts about “laser-cutter techniques” before. Nevertheless, most of these past articles tend to focus on either acrylic or wood as the “material of choice,” and not all of those techniques are transferable across materials. Delrin, when compared to acrylic, is far more ductile, and, when compared to wood, is a far better approximation of a continuum. These two characteristics enable a number of additional design techniques that are either impractical or difficult to accomplish with materials like acrylic and wood.

Delrin Prototyping Techniques


The Press-Fit

When machining metal, a press-fit between two parts necessitates tolerances tighter than ±0.0005 in. (0.0127 mm) between the mating surfaces such that the two parts that are pressed together will deform slightly and cannot separate under normal operating conditions. Delrin, because of its flexibility, is much more willing to deform to accommodate press fits. This fact is a lifesaver for hobbyist laser cutters. What this means is that even if our laser cutter has slightly less precision, we can still achieve a press fit between two Delrin parts (or just one part made from Delrin) because of Delrin’s willingness to deform to the shape of another part. As a back-of-the-envelope rule, if your laser cutter can hit relative dimensions between features that are ±0.001 in. (0.0254 mm), just undersize the hole (or other press-fit geometry) slightly smaller than you would for a conventional press-fit, and the Delrin will still be able to expand and hold the part firmly.

In the image above, the linear rails are press-fit into the Delrin, which has graciously accommodated the two rails without cracking. Under normal operation, the rails will remain in place because of the compressive force of the Delrin pushing back against the rail from the outer walls of the hole. The Bearings are also press-fit.

In contrast, this technique cannot be applied to acrylic in any repeatable way. Acrylic is very brittle. Consequently, putting it under internal stresses, by trying to push a metal dowel pin (or other such parts) into a hole in acrylic will simply cause the part to split or shatter.


Delrin is easily machined–so easy that you don’t even need a proper machine to put countersinks into your part! Below, the countersunk screw holes for GameCube-Bot V2‘s motor plates were done by hand with a small countersink.


With any seasoned technique, the “gurus who came before us” have developed a tool for just the situation. In this case, the tool is a steady line of thread-forming screws, enabling us to screw directly into many materials without ever tapping. Conveniently enough, Delrin is so malleable that it doesn’t even need these screws! Simply size the hole to the appropriate tap size, and screw it in by hand.

As yet another disclaimer, this technique also does not apply to acrylic and wood. Acrylic is simply too brittle to be cut or deformed by screw threads, and plywood will not thread predictably since it is a composite of many layers of wood glued together.


Delrin’s ductility makes it a good candidate for snap fits involving tabs and slots. The big idea behind snap fits is that your assembly process will introduce a temporary stress on the tab such that it can pushed into the slot and then relieved once the tab is fully inserted. Acrylic might handle compressive loads just fine, but its tensile strength is very poor, making it an unreasonable choice for reliable snap-fit joints. Delrin, however, is much more accommodating for this technique.

Before you get too carried away designing arbitrary snap fits, keep in mind that there’s a plethora of research and equations that go into using this technique repeatedly in mass-produced consumer goods.

The Delrin-Rubber Sandwich

Delrin is notoriously slippery, so we should expect pieces to slide easily if they aren’t secured. If we’re looking to get a little more grip between our surfaces, I’ve had success with a thin sheet of Santoprene rubber (also laser cut) set between the Delrin and its mating surface. The resulting rubber sandwich has far more friction, especially with sufficient normal force applied via screws.


Dubbed, the “O-ring Sandwich,” you too can make your own wheels in a pinch! The idea behind this technique is to sandwich three Delrin plates together, the center of which is slightly smaller in diameter, such that the o-ring has a groove to rest in. Delrin has at least twice the impact strength over acrylic (~1.2 ft-lb/in vs 0.4 ft-lb/in), making it a far better materials choice for the ups-and-downs in the terrain that these (robot?) wheels will explore. Finally, the sandwich of three plates is thick enough to overcome any of the possible flimsy drawbacks from Delrin’s inherent ductility.

The image shown here has a custom aluminum hub made with a lathe, but you can also purchase hubs to do the same trick.


In “real life,” Delrin has a reputation for its wear-resistance, and we can find it sold as bushings and even gears. Why let the retailers have all the fun, though? With a sufficiently high-power (60W and up) laser cutter, you can lase your own gears too!

A fair forewarning: although the laser cutter can certainly cut 64-pitch teeth, odds are pretty low that the surface finish of the gear will be good enough to mesh with a properly fabricated gear of the same pitch. The taper (see the Drawbacks post that will be published after this one), coupled with the melty surface finish of the gear teeth will both negatively impact the quality of the gear–but perhaps these drawbacks aren’t deal-breakers in your application, and the melty teeth are simply “good enough?”

Spring Pins

Not all laser cutters are capable of consistently cutting the thicker (.1875 [in] or greater) sheets of Delrin. Furthermore, Delrin tends to warp after being extruded. Whether you’re trying to create a thicker plate or trying to straighten two warped plates by fixing them together, spring pins can assist in both endeavors. Spring pins are coiled rolls of steel that are press-fit into holes. Once installed, they hold their place by applying compression on the inside walls of the hole, making them really good for one-time installations and really difficult to remove if you messed up. To install them, I’d suggest an arbor press.


Remember I mentioned Delrin being slippery? Now it’s time to take advantage of this fun fact and put it to work. The idea behind this technique is to sandwich three-to-four discs of Delrin together onto a shoulder screw, where the size of the hole through each disc is large enough to allow the disc to run smoothly. Alternatively, you can also replace the inner discs with a bearing, provided that you choose an undersized shoulder screw.

Tune in Next Time

That’s all for this week! Check back in two weeks for PART II where I’ll explore the drawbacks involved with working with Delrin (hint: you can’t glue the stuff!) and how to work around them.

For the many techniques documented here, I’m greatly indebted to spending time with some excellent engineers over the last couple years. Thanks [Steph], [JB], and [Chris] for all of your pro tips that went into some of the ideas in this guide!

Lastly, for the full breakdown of Delrin’s material properties, take a look at DuPont’s Design Guide.

Filed under: Featured, how-to, misc hacks

Hackaday Prize Worldwide: Washington DC

พฤ, 09/03/2015 - 22:31

Join us for a Meetup on Saturday, September 12th near Washington DC. The Hackaday Crew is headed out to the DC area a week from Saturday and we want to hang out with you. We’ll be hosting a meetup at Nova Labs hackerspace in Reston, Virgina which is on the Northwest side of DC.

We’ll get things rolling at 6pm on Saturday, September 12. The event includes a few lightning talks, some food and drink, and a lot of socializing. This is free to all but you do need to RSVP to let us know you’re coming. We want you to bring a hack to show off. We love to see what people are working on no matter the level of complexity or stage of completion.

Breakout board laid out in KiCAD

This all started when [Anool Mahidharia] mentioned that he’d be at Nova Labs on September 11-13 to lead a KiCAD PCB design workshop. This 2.5 day boot-camp starts with installing the Open Source EDA software on your laptop and ends when you have a completed PCB design ready to be submitted to a board fab. There is a charge for the workshop and attendance is limited so if you’re interested in it you should sign up now. Our events page is a good collection of information on both events as well as directions to get to Nova Labs.

The workshop is being organized by our friend [Bob Coggeshall] who we first met (and interviewed about his work on the Linux ‘sudo’ command) back in 2014 at Bay Area Maker Faire. Since then, [Brian Benchoff] swung by and visited [Bob] to talk about his company Small Batch Assembly and to tour Nova Labs. He will be conducting his own surface mount soldering workshop, will speak about Design For Manufacturing, and will show his Pick and Place machine during the weekend.

It will be fun to visit with [Bob] and to meet everyone who can make it to the Saturday evening meetup. So far  [Mike Szczys], [Brian Benchoff], and [Sophi Kravitz] are all planning to be there. [Anool Mahidharia] will of course be there since he’s leading the workshop. The following weekend [Anool] and [Brian] will both be headed to Philadelphia for the 2015 Open Hardware Summit for which Hackaday is a proud sponsor. [Matt Berggren] and [Amber Cunningham] will both be at OSH as well, talking all things Tindie.

Filed under: Featured

Learn 3D Modeling in Your Browser

พฤ, 09/03/2015 - 21:01

If you have a 3D printer, it is a good bet you’ve at least seen or heard of Tinkercad. There’s pros and cons to doing your design in a Web browser, but Tinkercad is very easy to use and great for making simple objects. However, there are other 3D object designers you can use in your browser, too. Tinkercad is just the one that everyone seems to know about.

I won’t talk much about Tinkercad, but if you haven’t tried it, it is well worth a look. It has a simple system of drawing things and holes. When you merge holes with things you can make lots of shapes. The alignment tools are good, and since Autodesk acquired them (part of its 123d app suite), it isn’t likely they will go under any time soon (which, as you may remember, almost happened).

If you are designing some great new secret invention you may shy away from cloud-based design programs. But if you are printing out key chains with your coworker’s cat’s name on it, do you really care? Most of these cloud-based programs will work from any computer so you can quickly do a design in a coffee shop and then go home and print it.

Programs that generate 3D objects tend to fall into two categories: visual and parametric. Visual tools emphasize drawing shapes with a mouse while parametric tools tend to make you describe what you want numerically. This is one of those things where your intuition may lead you astray. It seems like visual drawing is the way to go, right? People are visual. But most people are also inexact. If you want to lay out, for example, a front panel for a piece of custom test equipment, it is hard to get everything lined up perfectly and spaced evenly.

Sure, tools like Tinkercad have alignment and spacing tools and that’s great. But for complex designs, making a change can cause a flurry of mouse activity. Professional CAD programs often combat this by allowing you to set constraints, but that’s generally not easy to learn and, as far as I can tell, is unheard of in a browser-based tool (except for Onshape, as you’ll see below).

The opposite of the pure visual approach is a program like OpenSCAD. You don’t draw anything. You describe your shapes using something that looks like a programming language and then you can see a visual representation of it that you can’t edit graphically. You might think OpenSCAD isn’t a browser-based program. You’d be right, but there are several versions of it on the web. One is the aptly-named openscad.net, and it is probably the closest to the desktop experience.

If you write OpenSCAD code correctly, it is nothing to make an adjustment here or there. Need another hole in that front panel? Add it and all the other holes move to adjust. However, not everyone writes flexible code. If you just hardcode all the numbers, the result is even worse than using visual tools.

Many visual tools (including Tinkercad) give you some way to do at least some parametric inputs (hint: use the ruler and click on a dimension) which may help if you need to make, for example, holes that are exactly the same size. But setting X and Y coordinates of a set of holes so they line up and space out is still something you have to do either by eyeing it, using a one-time alignment tool, or directly entering numbers.

I wanted to gather up some of the web-based 3D design tools I know about. The list is not exhaustive, and I’m sure the comments will point out some that I don’t know about.

OpenSCAD and Related

I already mentioned that a few sites provide OpenSCAD in your browser. If you are already using OpenSCAD, this is really handy when you aren’t at your own computer. If you are squarely in the visual camp, though, you won’t be impressed. The OpenSCAD language isn’t quite a full programming language (although the newest release is getting closer). If you are a more traditional programmer, there are options like OpenJSCad or CoffeeSCAD, both of which offer OpenSCAD-like capabilities aimed more at people who actually program.

If you ever have the urge to host your own private copy of OpenSCAD on a web server, have a look at cloudscad. It hasn’t been updated lately, though.

The Best of Both?

I have been very impressed with Shapesmith which is open source and runs well in the browser. What’s nice is that while it is visual, there is an inspector window that lets you do direct entry of parameters easily. If you don’t like creating accounts, you can try the site with no sign up at all, although you’ll lose your work later if you don’t create an account.
Like Tinkercad, Shapesmith lets you set a workplane. However, if it has tools to align or space objects, I couldn’t find them. The picture to the left shows an STL file imported into Shapesmith and tweaked.


I first learned about 3D Tin because it shows up in the Chrome store. It looks really nice and it is capable of drawing items for 3D printing or just doing general purpose 3D modelling. It has a bit of a quirky user interface that tries to bridge the visual and the parametric.
When you create a shape, you can enter sizes, for example, numerically. When resizing, you use a slider instead of grabbing object handles. It takes some getting used to, but it works. it does offer alignment and grouping tools, which are handy. The picture to the right shows a simple 3Dtin object.

The Full Monty: Onshape

While most of the tools in this roundup are simple to use, Onshape (currently in Beta) is a full-blown professional CAD package in your browser. If you need that kind of power, it is great. But if the term “padding a sketch” doesn’t mean much to you, prepare for a steep learning curve.

I mentioned earlier that professional CAD tools use constraints and parameters to get the same kind of effect you can get in a properly written OpenSCAD script. Onshape supports constraints and parameters. Watching their tutorial video might give you an idea of the learning curve you’d face to use this design technique. Of course, if you are accustomed to this type of modelling from other packages, you’ll find Onshape very impressive for a browser-based application.
Although you can use Onshape for 3D printing, it is fully capable. The free plan gives you a limited number of private drawings but a virtually unlimited amount of public ones. The picture to the left shows a complex part in Onshape.

Breaking the Desktop

Are any of these tools up to par with a desktop solution? Depends. Onshape is pretty powerful if you are willing to take the time to learn it. OpenSCAD in the browser is pretty much like OpenSCAD on your desktop.

Perhaps the other tools do lack a few features. However, for things you commonly 3D print, any of these tools will get the job done. I know there are others out there too. Feel free to call out your favorite (or, even, your least favorite) in the comments.

Would I use online CAD for a real project? Maybe. I use online mail applications now. I also occasionally use online office applications like word processing. I think it mainly comes down to how much I trust the back end. If I own the back end (a possibility with some of these tools) or a company I trust (perhaps foolishly) owns it, and there are reasonable privacy controls in place, why shouldn’t I use online tools? Besides, I don’t think there’s much chance of Mr. Buttons’ key chain falling into the wrong hands.

Filed under: 3d Printer hacks, Featured

Being Picked up by a Swarm of Drones May Become Reality

พฤ, 09/03/2015 - 20:07

In case you haven’t seen it yet, this video has been taking the internet by storm. The YouTube user [Gasturbine101] has successfully taken flight in his home made multi-rotor flying machine.

It’s a massive array of high powered brushless motors with props, fifty-four in fact, all counter-rotating. It has a weight of 148kg (we assume this includes the inventor), and produces a maximum lift of 164kg. Apparently it’ll even last for about 10 minutes. The props are grouped into six, using Hobbyking stabilizers to balance the flight.

He calls it the Swarm.

We’re starting to see more and more drones capable of carrying humans. Is this the future of transportation? From commercial companies promising flying cars in drone form, to even more unsafe examples of strapping far too many motors onto a single frame… it looks like the age of home-made flying machines is here.

[via Sploid]

Filed under: drone hacks, transportation hacks

Why IoT will Fail (and How to Save It)

พฤ, 09/03/2015 - 18:01

Buzzword technology has two possible fates: they fail and disappear or they succeed and disappear. Remember at one time “multimedia” and “networking” were buzzwords. They succeeded and now they’ve vanished into ubiquity. Of course, there are plenty of failed buzzwords (like telecosm) that you probably don’t even remember. They just vanished into obscurity.

Unless you’ve been living under the CNC mill in your local hackerspace, you’ve probably heard or read about the “Internet of Things” (IoT). Companies big and small have realized that getting in early on The Next Big Thing is good for share prices and, right now, IoT is where everyone is trying to make a play.

There’s two things I’d observe, though: First, IoT is far from new. Connecting embedded systems to the Internet is old hat (I even wrote a book called Embedded Internet Design way back in 2003). Second, the way it is going, IoT–in its current incarnation–is doomed.

To see why I would say that, let’s do a thought experiment. In the early days of the Internet, there was no big money involved in it. It was just a quirky government and academic project. But pretend the Internet was being invented in today’s business climate.

Now imagine the ads in your local newspaper: Subscribe to KoolDNS! More free addresses than any other provider. Surveys show that 85% of all sites are available when you use KoolDNS. Another ad would want you to buy a browser that allows you to read over half of the most popular Web sites.

What? Sure, your typical Hackaday reader can manage IP addresses directly and could probably cobble together a reader for some non-HTML format. But the broader public relies on DNS services and a standard HTML format. It is hard enough that a very small percentage of sites today rely on some specific browser feature.

Yet this is where we are heading with IoT. Everyone has an open or semi-open broker. Groups of companies are banding together to create standards that compete with the other guy’s standards. In other areas (for example, WiFi) vendors have submitted to IEEE standards. The IEEE is working on an IoT standard and it might be out by 2017. Meanwhile, it is a land grab to get something to market now, hoping it will take off and displace everyone else.

If you don’t think this kind of thing affects you, you might want to go watch a movie on your HD DVD or Betamax player. As a consumer, being on the wrong side of a standards war can get pretty expensive.

How to save it? I’m avoiding IoT infrastructure that isn’t open source. There no promise the eventual winning standards will be kind to open source, but at least you (or someone) can likely bring it up to snuff. Plus, if you decide to stick with it, at least you can support it yourself if that makes sense in your application.

The truth is, I don’t think IoT will win or lose. I think it has been around for years and will continue to thrive in places where it makes sense. For places it doesn’t make sense, the fad will eventually die down, the big companies will go milk the Next Big Thing (smell-o-vision, perhaps) and the rest of us will continue developing embedded systems that meet our needs.

In the video below, Jeremy Rifkin says the Internet of Things is going to launch a new economic revolution on par with the industrial revolution and that there will be 100 trillion Internet-connected sensors by 2030. However, I can’t help but think that his argument of zero marginal cost is going to apply more to the Star Trek-style replicator than to IoT.

[Artwork courtesy of dadallone]

Filed under: Hackaday Columns, rants, slider

Making a Door that Opens Both Ways

พฤ, 09/03/2015 - 15:01

How many times have you walked into the wrong side of the door? How many times have you been momentarily confused as to whether or not you push or pull that obscure door handle which isn’t so obvious in its intended use?

What if you never had to worry about doors again? What if we could have an omni-directional door? [TVMiller] couldn’t find any examples of this, so he decided to build his own prototype. He calls it the Any Way Door.

The Any Way Door is just a 1:12 scale version, but as you can see in the following video, it works pretty well — and if anything would make for a very cool door that interior designers / architectures would love.

The question is, can it be done at full size effectively?

[TVMiller] would love to find out, but does not have the time or resources to build a full scale model, so he’s invited the Hackaday audience to give it a shot. He’s posted the project on Hackaday.io and welcomes anyone to join and contribute.

What do you guys think? Is it possible? Is it viable? Or do we deserve it when we walk into poorly designed doors?

Filed under: home hacks

Hackaday Prize Semifinalist: Low Cost Radiography

พฤ, 09/03/2015 - 12:00

For the past year, [Adam] has been working full-time on developing a low-cost x-ray system for developing nations. He has more than 3,500 hours into the project. A few months ago, we announced the 2015 Hackaday Prize, with a theme of, ‘build something that matters.’ A low-cost x-ray would certainly matter to the two-thirds of the world’s population that does not have access to medical radiography, making this project a great entry for The Hackaday Prize.

[Adam]’s portable x-ray system consists of an x-ray tube encased in an epoxied, 3D printed enclosure filled with dialectric oil. This tube is tucked away inside a beautiful case with just a single 12VDC input and an easy to understand user manual. This is just very high voltages and x-rays, nothing [Adam] hasn’t handled (safely) before. The real trick is in the imaging, and for this, [Adam] is using a phosphor screen to turn that x-ray exposure into something visible, an off the shelf x-ray sensor, and a prism to adapt the sensor to the phosphor screen.

The results are incredible. After taking a few pictures of what he had on hand, [Adam] can see the bond wires inside the microprocessor of a calculator. That’s more than sufficient for medical imaging – the goal of the project – and cheap enough to send it to the far-flung reaches of the planet.

The 2015 Hackaday Prize is sponsored by:

Filed under: The Hackaday Prize

Hack an Editor: Fonts for Programming

พฤ, 09/03/2015 - 09:01

We’ve recently noticed two different fonts aimed at programmers, each with a different approach to editor customization. The first, Fira Code, transparently converts common programming digraphs into single characters. For example, <- becomes an arrow and != (or <>) becomes a proper not equal sign. The other font, Hack (can’t argue with the name), aims to make commonly confused characters distinct. For example, the zero glyph has a very distinct appearance from the letter O.

It is pretty easy to understand how Hack works, but Fira seems a mystery at first. Your C++ compiler expects <- not an arrow, right? Fonts support ligatures–sequences of two symbols that run together (like æ). Clever use of these ligatures means that the compiler still sees -> but the screen displays an arrow.

Once you install the font, you still need to tell your editor to use the font, but that’s a setting in just about every IDE (even if you have to edit a configuration file somewhere). We have mixed feelings about Fira Code. It has a high cool factor, but it also feels like you are hiding the actual code and that doesn’t seem like a good thing.

If you want to roll your own, there are plenty of ways to create fonts. Naturally, you can even do it with a Web application (see video below). Of course, if you do we want to hear about it.

Thanks [k5rud] for pointing out Hack.

Filed under: Software Development, software hacks

Retrotechtacular: Häfla Hammerforge Healed

พฤ, 09/03/2015 - 06:01

Visit any renaissance fair across the United States this fall and you’ll undoubtedly find a blacksmith. He’ll be sweating away in a tent, pounding on a piece of glowing steel set against an anvil. While the practice of the single blacksmith endures today, high-production ‘works of days past required increasing amounts of muscle. The more tireless the muscle, the better. The manual efforts of the blacksmith were replaced by huge hammers, and the blacksmith needed only to turn the piece between impressions and maintain a healthy respect for the awesome crushing power of the machine.

Last week, blacksmith enthusiasts completed restoration work on the Häfla hammer in Finspang, Sweden. The 333 year old hydraulic hammer hadn’t been used since 1924, when operations ceased at the Häfla Hammerforge. The ‘works was built in 1682 and used the German method of forging, which had been introduced to Sweden in the 1500s. Steel production was revolutionized in the 1800s by the Bessemer process, which resulted in a much stronger product.

[via reddit]

Retrotechtacular is a weekly column featuring hacks, technology, and kitsch from ages of yore. Help keep it fresh by sending in your ideas for future installments.

Filed under: Hackaday Columns, Retrotechtacular

3D Objects From a Laser Cutter

พฤ, 09/03/2015 - 03:00

Actors want to be singers and singers want to be actors. The hacker equivalent to this might be that 3D printers want to be laser cutters or CNC machines and laser cutters want to be 3D printers. When [Kurt] and [Lawrence] discovered their tech shop acquired a 120 Watt Epilog Fusion laser cutter, they started thinking if they could coax it into cutting out 3D shapes. That question led them to several experiments that were ultimately successful.

The idea was to cut away material, rotate the work piece, and cut some more in a similar way to how some laser cutters handle engraving cylindrical objects. Unlike 3D printing which is additive, this process is subtractive like a traditional machining process. The developers used wood as the base material. They wanted to use acrylic, but found that the cut away pieces tended to stick, so they continued using wood. However, the wood tends to char as it is cut.

In the end, they not only had to build special jigs and electronics, they also had to port some third party control software to solve some issues with the Epilog Fusion cutter’s built in software. The final refinement was to use the laser’s raster mode to draw surface detail on the part.

The results were better than you’d expect, and fairly distinctive looking. We’ve covered a similar process that made small chess pieces out of acrylic using two passes. This seems like a natural extension of the same idea. Of course, there are very complicated industrial machines that laser cut in three dimensions (see the video below), but they are not in the same category as the typical desktop cutter.

Filed under: cnc hacks, laser hacks, tool hacks

A Tale of Three Soldering Iron Controllers

พฤ, 09/03/2015 - 00:00

[ZL2PD] needed to replace an old Weller soldering station and decided not to go with one of the cheap soldering stations you can find all over the Internet. He has a long story about why he had to design his own controller, but you never have to explain that to us. He kept detailed notes of his journey and in the end, he built three different controllers before settling on one.

He started with a Hakko hand piece that uses a thermistor for temperature measurements. The first iteration of the controller had analog controls. He wasn’t happy with the number of parts in the design and the simple LED display. That led him to replace the controller with an ATTiny CPU and a use a serial LCD.

The third and final version still uses the CPU. [ZL2PD] realized the LCD display wasn’t very useful, so he went back to the LEDs and created a PCB. Finally satisfied, he created a 3D printed enclosure, an artistic dial scale, and scavenged a tool holder. The results look pretty good and there has to be something satisfying about soldering with a station you designed yourself.

Seems to us all he has left is to hack a fume hood. Or perhaps he’ll build a desoldering companion. If you want to duplicate his results, be aware that some irons use different types of temperature sensors. Or you might just want to blow $16 on a cheap station (see the video below) and work on other projects. We won’t tell.

Filed under: ATtiny Hacks, tool hacks

How CMOS Works: Some Final Words About CMOS

พุธ, 09/02/2015 - 22:30

Finishing up on the topic of CMOS bus logic I am going to show a couple of families with unique properties that may come in handy one day.

High Voltage Tolerant Family: AHC/AHCT Note the missing diode to VDD

First up is a CMOS logic family  AHC/AHCT that has one of the protection diodes on the input removed.  This allows a 5V input voltage to be applied to a device powered by 3.3V so that I don’t have to add a gate just for the translation.  Any time I can translate and do it without any additional gate delays I am a happy engineer.

Of course the example above works in a single direction and bidirectional does start to get more complicated. Using a bidirectional buffer such as a 74AHCT245 will work for TTL translation when going from 3.3V back to 5V providing there is a direction control signal present.

Dual Voltage Translating Transceiver

Another logic family by way of a true voltage translation is the dual supply translating transceiver, such as the 74LVC2T245.   This part can translate from any voltage between 1.2-5.5V to any other voltage in that same range making it useful for the voltages below 2V up to TTL, and other combinations.  This type device actually uses two power pins, one for each of the voltages being translated.

The 74LVC2T245 includes a “bus hold” function which can also be found in other logic families where they family name has an “H” in the name denoting the bus hold.

Bus Hold Function

The need for a bus hold function stems from the same concerns that makes us use lots of pull-up resistors; one for every single signal that has moments or possibilities of a high impedance tri-sate for any length of time, i.e. during a moment of tri-state where none  of the possible bus drivers are turned on.  This is a “floating” state where the voltage is free to wander around, unfortunately it can wander into the unspecified logic level state that is neither a logical high nor a low.  Bad things happen at this point, current consumption goes way up (remember from last post when we talk about both transistors turning on at once between VCC and ground?) and things can actually oscillate, in fact you may not even see the oscillations with an oscilloscope as the oscillation could be occurring on the insides of chips attached to the bus.

Source: [EE-Times]

Weak pullups, meaning pull up resistors, can be added to all of the signals so that any signals left floating will eventually be pulled to a high state.  There are several problems with pullups in general however; they add to the current consumption and the load on the bus and they can take a relatively long time to pull a voltage up into the “safe” high logic  zone.  By relatively long time I mean between 20-50ns  or longer as a passive resistor  suffers from an RC taper  due to the inevitable capacitance found on a bus.

Making the pullup stronger, i.e. a smaller value, can have the undesired effect of more drastically increasing power consumption and reducing noise margin by “lifting“ the low voltage signals and making the buffers work harder when driving a low.

IC Chips and Dies

Switching gears I am going to talk a bit about the physical layout of integrated circuits. Shown is an old wafer I have left around from my time at Commodore in the 1980s.  Looking under the microscope on my bench you can see the individual chip dies on the wafer.  In production these would, after the appropriate testing and QA steps, be scribed and cut so that the individual dies can be mounted in individual chip packages.

If we zoom in further we can see some of what’s on the chip. Note that we are looking through a semi-transparent layer of insulation called passivation.  At one time the chip designers could ask that a couple of wafers/dies skip the passivation step so that later  they could better see and probe the chips under the microscope, though the lifetime of the chips was measured in months when exposed to the air without the protective passivation coating.

FET Side View

Showing a side view of how a Field Effect Transistor (FET) is made, the process starts by laying down an insulating layer and then masking a layer of polysilicon, a fairly conductive material that is used for the gate contact. It’s important to note that the gate will remain insulated from everything below it though there can be contacts upward to route to metal conductors and eventually to the pad and pins of the IC.  The insulative layer can be seen under the gate in the drawing.

Once the gate is laid down the ends of what will be the transistor are then “implanted” by exposing the material to an ion implanter.  We were always breaking our implanter back in the Commodore days as we were running ion densities higher than the implanter was designed for.  This layer is called the diffusion layer harking back to a time when the layer was diffused via chemical doping.

The two diffusion zones now called the Source and Drain which are next to a polysilicon gate are what we need for the transistor to operate: apply the correct voltage to the gate and a conductive channel forms under the gate between the gate and source (shown in dotted lines above). Unlike a transistor which is bipolar, meaning it has a P and an N layer which are the makings of a diode (which conducts in only one direction), the FET supports current flow in either direction as the device is symmetrical, the drain and source are made of the same material with substrate between them.

[Source: Wikipedia]

Speaking of substrate or the base layer that everything is grown on, it is either a N type or a P type. Most often it is a P-substrate these days which allows the N-channel devices to be grown directly on it, like NMOS technology did, the predecessor to CMOS. Before we can fabricate a P-channel transistor we have to first create a miniature version of some N-substrate that completely encompasses the area where the P-channel device will be.  Looking at the diagram you will see the N-well which acts like an N-substrate.  When CMOS first came out I remember reading about the pros and cons of using “dual tub” or both a P-well and N-well vs. just using a P-substrate, but I believe “single tub” or single well has won out, though there may be more parasitic considerations without the isolative properties of putting everything into a well (takes more room also!)

Now for the P-channel device, the same steps are basically the same once the N-well is implemented.   When implanting, a different dopant is used to implant a P-diffusion drain and source than that used for N-diffusion.  Examples of dopants are Boron for P+ diffusion and Arsenic for N+ diffusion.

Top View

Looking down from the top things look like a bunch of overlapping polygons, mostly because they are in fact a bunch of overlapping polygons.  Most of the chip layout people I know have mentioned that they have dreamed about polygons in their sleep at some point.

If we look for the polysilicon and where it appears to overlap diffusion, though we know that it doesn’t really overlap as we saw in the side view, we can spot the transistors. The length of the channel underneath the polysilicon gate is where we get the “design rules” when talking about size, for example saying something is using 90nm rules means that the effective channel length between source and drain is 90 nanometers long.

In the video I trace out the layout of the simple CMOS inverter as compared to the schematic.

Open Source “Magic” VLSI Editor Open source Magic VLSI editor.

Lastly I wanted to show an open-source editing tool that allows us to play with some chip layout ourselves. The program is called Magic and its history and a download can be found here.

This is a great learning tool and design rule checks (DRC) built-in to the software can help someone first starting out in the craft to understand clearances and other rules regarding layout and production.  The software can be hard to use at first: one must left click on a grid then right-click on the opposite corner of the desired polygon and then select the layer by middle clicking on the layer on the toolbar.  Different rules can be loaded including scalable features and how a resistor or capacitor is made using various processes. Under the covers the DRC’s start kicking in and the various layers, masks and other photolithographic data can be extracted to start the process of going to chip fabrication.

But Why?

My style of engineering was always to look under the covers and I was fortunate to work at a couple of places where very smart people were there to explain to me what I was seeing or wanted to know.  Understanding how ESD protection is implemented for example, can help an engineer understand what and what not may be a good design in various unusual circumstances where the datasheet alone doesn’t tell you everything.

Filed under: Featured, hardware