Syndicate content Hackaday
Fresh hacks every day
ถูกปรับปรุง 21 min 28 sec ก่อน

Hands On With The First Open Source Microcontroller

ศุกร์, 01/06/2017 - 01:00

2016 was a great year for Open Hardware. The Open Source Hardware Association released their certification program, and late in the year, a fe pleasew silicon wizards met in Mountain View to show off the latest happenings in the RISC-V instruction set architecture.

The RISC-V ISA is completely unlike any other computer architecture. Nearly every other chip you’ll find out there, from the 8051s in embedded controllers, 6502s found in millions of toys, to AVR, PIC, and whatever Intel is working on are closed-source designs. You cannot study these chips, you cannot manufacture these chips, and if you want to use one of these chips, your list of suppliers is dependent on who has a licensing agreement with who.

We’ve seen a lot of RISC-V stuff in recent months, from OnChip’s Open-V, and now the HiFive 1 from SiFive. The folks at SiFive offered to give me a look at the HiFive 1, so here it is, the first hands-on with the first Open Hardware microcontroller.

Before I dig into this, I must discuss the openness of the HiFive 1, and RISC-V in general. Free Software and Open Hardware is a religion, and it’s significantly more difficult to produce Open Hardware than Free Software. No matter how good or how Open the design is, the production of the first Open Source microcontroller will generate far too many comments from people who use the words ‘moral imperative’ while citing utilitarian examples of why Open and Libre is good. You should ignore these comments, but not just because these people have only read the back cover of the Cliff’s Notes for Philosophy For Dummies.

The Openness of the HiFive 1 and RISC-V

The biggest selling point for RISC-V chips is that there are no licensing fees, and this microcontroller is Open Source. This is huge — your AVRs, PICs, ARMs, and every other microcontroller on the planet is closed hardware. You can’t study the silicon. If we’re ever going to get a completely Open Source computer, it has to start somewhere, and here it is.

With that said, this is an Arduino-compatible board with an FTDI chip providing the USB to serial conversion. If we had a facepalm emoji, we’d use it here. An FTDI chip is not Open Source, and they have designed drivers to break chips that aren’t theirs. The design files for the HiFive 1 were made with Altium, a proprietary and non-Free software.

This was the best picture for this section of content.

Will Stallman ever say the HiFive 1 is Free as in speech? Absolutely not. Instead, the HiFive 1 is an incrementally more Free microcontroller compared to a PIC, ARM, or AVR. There will be people who will argue – over the Internet, using late-model Intel processors with Management Engines — this is insufficient to be called Free and Open Source. To them, I will simply link to the Nirvana fallacy and ask them to point me to a microcontroller that is more Free and Open Source. Let’s not cut down the idea of an Open Source microcontroller because it’s not perfect on the first release.

Hardware Teardown

So, what’s in the HiFive 1? The spec sheet is simple enough, the datasheet is complete enough,  although there are some caveats:

  • Microcontroller: SiFive Freedom E310 (FE310)
    • CPU: SiFive E31 CPU
    • Architecture: 32-bit RV32IMAC
    • Speed: 320+ MHz (the stock frequency seems to be about 256 MHz, this can be changed)
    • Performance: 1.61 DMIPs/MHz
    • Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad
    • Other Features: Hardware Multiply/Divide, Debug Module, Flexible Clock Generation with on-chip oscillators and PLLs
  • Operating Voltage: 3.3 V and 1.8 V
  • Input Voltage: 5 V USB or 7-12 VDC Jack
  • IO Voltages: Both 3.3 V or 5 V supported
  • Digital I/O Pins: 19
  • PWM Pins: 9
  • SPI Controllers/HW CS Pins: 1/3
  • External Interrupt Pins: 19
  • External Wakeup Pins: 1
  • Flash Memory: 128 Mbit Off-Chip (ISSI SPI Flash)
  • Host Interface (microUSB): Program, Debug, and Serial Communication

Basically, the HiFive 1 is the SiFive FE310 microcontroller packaged in an Arduino Uno form factor. The pin spacing is just as stupid as it’s always been, and there is support for a few Adafruit shields sitting around in the SDK.

There are no analog pins, but there are two more PWM pins compared to the standard Arduino chip. The Arduino Uno and Leonardo have 32 kilobytes of Flash, while the HiFive 1 has sixteen Megabytes of Flash on an external SOIC chip.

The HiFive 1 supports 3.3 and 5V I/O, thanks to three voltage level translators. The support for 5V logic is huge in my opinion — nearly every dev board manufacturer has already written off 5V I/O as a victim of technological progress. The HiFive doesn’t, even though the FE310 microcontroller is itself only 3.3V tolerant. It should be noted the addition of the voltage level translators add at least a dollar or two to the BOM, and double that to the final cost of the board. It’s a nice touch, but there’s room for cost cutting here.

Other than that, the only other chip of note on the board is the FTDI FT2232HL, a well-supported but most certainly not Free and Open Source USB to UART chip. This is a two-port chip that provides programming, serial, and debug connections simultaneously.

Getting Started With The HiFive 1

The folks at SiFive realize documentation and SDKs are necessary to turn a chip into a development board. To that end, they have a bare-metal SDK and support for the Arduino IDE. The board itself comes with a bootloader, and when you plug the HiFive 1 into a USB you get the equivalent of the Blink sketch from the Arduino. Yes, you too can have Open Source blinkies. What a magical time to be alive.

Right now there are two methods of programming the HiFive 1. The Freedom E SDK, and the Arduino IDE. The Arduino IDE appears to be dependent on the Freedom E SDK, so either way, you’ll have to get the SDK running.

Right now, the SDK only works under Linux (and OS X, and possibly Cygwin), but support for Windows is coming. For Linux users, the getting started guide is more than sufficient, although it will take quite a while (at least 30 minutes) to build all the tools.

Once the Freedom E SDK is installed, support for the Arduino IDE pretty much falls into place. You’ll have to futz around with the Boards Manager, but with a few clicks, you get something fantastic. You can blink an LED with Open Source Hardware.

 Actually Programming the Thing

Blinking an LED is proof enough this can be programmed, but what about the vast SDK we had to install before getting the Arduino IDE working? Here, too, it’s pretty easy to get the SDK up and running:

For this example, I simply changed the ‘hello world’ program shipped with the SDK to a ‘hello Hackaday’ program, compiled it, and ran it. Yes, someone as dumb as me can compile and upload a program to the HiFive 1.

This Stuff is Still New, Okay?

Before receiving the HiFive 1, I originally planned to benchmark this dev board against other small, common dev boards. The SDK comes with a Dhrystone program, making this the obvious choice. The results were not good, but this isn’t a reflection of the power of the FE310 microcontroller. Allow me to present the shocking infographic you should not pay attention to:

Ignore this infographic

This test used this Dhrystone Arduino sketch with the Arduino Micro, HiFive 1, and the Teensy 3.6. As you would expect the Arduino Micro performed poorly (but still ten times faster than a mainframe from 1988), and the Teensy 3.6 was extremely fast. According to this benchmark, the HiFive 1 did terribly at barely twice the computing power of the Arduino while running 16 times faster. If this benchmark was accurate, it would immediately spell the end of the RISC-V ISA.

The above benchmark is not accurate, and the poor Dhrystone performance was due to incorrect assumptions about the timer’s frequency. I plopped this problem up on the SiFive forums, and a patch was available in a few hours. What does the real benchmark say?

That’s a fast microcontroller. RISC architecture is gonna change everything.

love this test. Beginning this review, I originally planned to run a few benchmarks on an Arduino, a Teensy, and the HiFive 1, throw together a graph and spend a hundred or so words on the results.  I got so much more.

Right off the bat, we can see the HiFive 1 is fastReally, really fast. Right now, if you want to build a huge RGB LED display, you have one good option: the Teensy 3.6. If you need a microcontroller to pump a lot of data out, the Teensy has the power, the memory, and the libraries to do it easily. In this small but very demanding use case, the HiFive 1 might be better. The HiFive 1 has more Flash (although it’s an SPI Flash), it has DMA, and it has roughly twice the processing power as the Teensy 3.6. This could be very, very cool, and I can’t wait to see the real life examples of how much the HiFive 1 can push out of its pins.

There’s your hundred word review on the performance of the HiFive 1 based on synthetic benchmarks. However, getting this benchmark working revealed far more about the state of the HiFive’s software, and how much support SiFive is throwing at it.

Admittedly, I do have a very early version of this board, and the CrowdSupply campaign for the HiFive 1 was only funded last week. No one would expect one of the three demo apps shipped with a newly released board with a mature architecture to be completely broken (unless it’s an Allwinner chip, but whatever). Very few people would expect the devs to get a patch out in less than 24 hours in response to a random person on a support forum.

All of this circles back to a single observation on the HiFive 1: It’s new. The HiFive 1 and all RISC-V microcontrollers don’t have a vast market share, user base, or decades of work behind them. However, the SiFive team seems to be taking their work seriously. They’re fixing the problems they have, and they’re constantly pushing out new documentation. This is great, and a very good indication of how much support the RISC-V chips from SiFive will have.

Chips As A Service

I should note that the folks at SiFive aren’t in the business of building RISC-V Arduino boards. They’re in the business of making chips for people. This is custom silicon we’re talking about here.

The easiest parallel to draw is between SiFive and OSH Park. These companies don’t have their own manufacturing capability; the value is in connecting end users (engineers, startups) to manufacturers. OSH Park connects you to a board house that really knows purple, and SiFive connects you to a chip fab. In the case of the FE310, that’s TSMC.

For anyone who wants silicon you can study, this is great. No, it’s not as simple as sending a board off to a fab house, but it’s a start. The fact that SiFive chose to start with Open Hardware is great, and we can’t wait to see the other hardware made with their sweat and hydrofluoric acid.

Update: You can already get your hands on the RTL for the SiFive chips if you want to run the cores on your own FPGA.

It’s a Beginning

At the base level, the HiFive 1 is a powerful microcontroller with a lot of Flash, with support for hundreds of Arduino libraries. That’s great, and alone this might be worth the $60 price of admission.

However, the big story here is the Openness of the HiFive 1. Is it completely open? No. the HiFive 1 itself uses an FTDI chip, and I’ve heard rumor and hearsay the FE310 chip has proprietary bits that are ultimately inconsequential to the function of the chip. A strict interpretation of Open Hardware will not allow this board to be called Open Hardware. Those who advance this interpretation are dumb, and to counter this argument I will quote the man himself:

…We need to distinguish levels in the design of a digital product (and maybe some other kinds of products). The circuit that connects the chips is one level; each chip’s design is another level. In an FPGA, the interconnection of primitive cells is one level, while the primitive cells themselves are another level. In the ideal future we will want the design to be free at all levels. Under present circumstances, just making one level free is a significant advance.

– Richard M. Stallman, Free Hardware And Free Hardware Designs

A design that fails to be completely Open does not deserve to be grouped with designs that are explicitly closed.

Nevertheless, this is the best we have so far, and it is only the beginning. We’re going to have more microcontrollers that are more Open, but until then, the HiFive 1 is actually a pretty cool board.

Filed under: Featured, Microcontrollers, reviews, slider

Python Solution To A Snake Cube Puzzle

พฤ, 01/05/2017 - 23:30

Puzzles provide many hours of applied fun beyond any perfunctory tasks that occupy our days. When your son or daughter receives a snake cube puzzle as a Christmas gift — and it turns out to be deceptively complex — you can sit there for hours to try to figure out a solution, or use the power of Python to sort out the serpentine conundrum and use brute-force to solve it.

Finding himself in such a scenario, [Randy Nuss] walks us through his solution while giving insight into how he approaches writing code — learning other methods of problem solving can be a valuable experience in itself, and thematically fitting, considering this particular case! [Nuss] includes his final code near the end of his post, but his write up instead outlines it in enough detail that would guide others along the correct path. Once it ran successfully, he was cajoled into creating a visualization of the solution since the actual code completes in less than a second.

If a hack is a means to make a given task easier to accomplish, then some fancy coding to solve a puzzle — while perhaps defeating the purpose — is arguably still a hack that simply uses a different avenue. Sometimes, the puzzle winds up being the hack itself when you are gifting something special.

[Thanks for the tip, Josh!]

Filed under: toy hacks

Visualization of a Phased Array Antenna System

พฤ, 01/05/2017 - 22:01

Phased array antenna systems are at the cusp of ubiquity. We now see Multiple-Input Multiple-Output (MIMO) antenna systems on WiFi routers. Soon phased array weather radar systems will help to predict the weather and keep air travel safe, and phased array base stations will be the backbone of 5G which is the next generation of wireless data communication.  But what is a phased array antenna system?  How do they work?  With the help of 1024 LEDs we’ll show you.

It’s good to first review what phased array antenna technology has been used for in the past, where it is today, and where it is going, then we will show you how it all works.

The Military Industrial Complex: Pioneers in Phased Array Technology

Phased array technology was pioneered for military applications. The ever increasing speed of aircraft and ordnance after the second world war pushed the requirement for antenna sweep time from seconds to milliseconds.

The first full-scale phased array radar systems was the FPS-85, which is used for detecting and tracking space objects which by their very nature are fast moving.

Additional iconic examples of phased array radar technology include the SPY-1 phased array radar, PAV PAWS, and others.

The First Widespread Use of Phased Array Radar Technology for a Civilian Application:

To manage increases in air traffic and to consolidate numerous existing aging radar infrastructure, including most types of primary air traffic control radar and weather radar, the multi-function phased array radar (MPAR) system is under development and prototypes to be fielded soon. This will become one of the first (likely the very first) wide scale civilian deployment of phased array radar technology.

More Wireless Bandwidth for Your Mobile Devices

Key to the 5th generation of wireless systems (5G) is the use of phased array antenna technology, where individual wireless devices will be tracked by beams transmitted/received from the base station thereby enabling greater data bandwidths which are discretized into individual microwave beams.

Many WiFi routers now use Multiple Input Multiple Output (MIMO) antenna arrays for the purpose of reducing multi-path signal loss, which is quickly becoming more and more of a problem as data rates increase.

How Do Phased Array Antenna Systems Work?

How do you create a ‘beam of microwave energy’ and direct your receiver onto just the right point in space?

Synthesizing a focused beam of microwave radiation with an array of elements fed with the same microwave signal where each element is independently phase controlled.

An excellent tutorial is presented here, but the key take away is that if we feed an array of antenna elements with the same microwave signal then we can use these elements to direct (or steer as it is commonly referred to) a microwave beam anywhere in space.  This beam steering is achieved by the use of a phase shifter (or its equivalent) in series with each and every antenna element.

To make the above explanation more interesting and understandable, friends of mine at MIT Lincoln Laboratory created this direct visualization of how antenna arrays work (shown recently at the 2016 IEEE International Symposium on Phased Array Systems and Technology).  It is almost as if you were to put on a pair ‘microwave goggles’ and looked into the antenna array!

MIT Lincoln Laboratory Phased Array Demonstrator, on display at the 2016 IEEE Intl. Symposium on Phased Array Systems and Tech.

A plexiglass duplicate of an actual phased array antenna system built by MIT/LL is stuffed with NEO Pixel LEDs.  Each antenna element is illuminated by two NEO Pixels, where this is a dual-polarized phased array using one LED for vertical and another for horizontal polarization.

The color of each NEO Pixel is mapped to phase of what its respective antenna element should be to project a beam of microwave energy in any given direction and this beam pattern is plotted by the flat-screen monitor next to the array.

The brightness of each LED is proportional to transmit power out of its respective antenna element. The array supports amplitude tapering to synthesize low sidelobe beam patterns and numerous advanced array modes.

With this visualization system, you can manually move the antenna beam around with a joystick and view the lighted pattern and beam plots changing in real-time, providing an instant and intuitive understanding of phased array beam steering and beam patterns.  Absolutely amazing!


Phased array antenna systems will play a central role in our modern lives facilitating greater wireless bandwidths, making airline travel safer, and weather prediction more accurate.  Compelling visualizations like the array shown here will facilitate widespread understanding of electromagnetics and modern antenna techniques.

Filed under: Engineering, Hackaday Columns, hardware, radio hacks

Acoustic Levitation with a Twist

พฤ, 01/05/2017 - 19:00

Don’t blame us for the click-baity titles in the source articles about this handheld “acoustic tractor beam”. You can see why the popular press tarted this one up a bit, even at the risk of drawing the ire of Star Trek fans everywhere. Even the journal article describing this build slipped the “tractor beam” moniker into their title. No space vessel in distress will be towed by [Asier Marzo]’s tractor beam, unless the aliens are fruit flies piloting nearly weightless expanded polystyrene beads around the galaxy.

That doesn’t detract from the coolness of the build, revealed in the video below. There’s no tutorial per se, but an Instructables post is promised. Still, a reasonably skilled hacker will be able to replicate the results with ease straight from the video. Using mostly off the shelf hardware, [Marzo] creates a bowl-shaped phased array of ultrasonic transducers driven by an Arduino through a DC-DC converter and dual H-bridge driver board to boost the 40 kHz square waves from 5 Vpp to 70 Vpp. By controlling the phasing of the signals, the tractor beam can not only levitate small targets but also move them axially. It looks like a lot of fun.

Acoustic levitation is nothing new here – we’ve covered 3D acoustic airbending, as well as an acoustic flip-dot display. Being able to control the power of sound waves in a handheld unit is a step beyond, though.

Thanks to [Brian Andersen] and [Sak] for the nearly simultaneous tips.


Filed under: misc hacks

Pretty Fly for a DIY Guy

พฤ, 01/05/2017 - 16:00

Milling machines can be pretty intimidating beasts to work with, what with the power to cut metal and all. Mount a fly cutter in the mill and it seems like the risk factor goes up exponentially. The off-balance cutting edge whirling around seemingly out of control, the long cutting strokes, the huge chips and the smoke – it can be scary stuff. Don’t worry, though – you’ll feel more in control with a shop-built fly cutter rather than a commercial tool.

Proving once again that the main reason to have a home machine shop is to make tools for the home machine shop, [This Old Tony] takes us through all the details of the build in the three-part video journey after the break. It’s only three parts because his mill released the Magic Smoke during filming – turned out to be a bad contactor coil – and because his legion of adoring fans begged for more information after the build was finished. But they’re short videos, and well worth watching if you want to pick up some neat tips, like how to face large stock at an angle, and how to deal with recovering that angle after the spindle dies mid-cut. The addendum has a lot of great tips on calculating the proper speed for a fly cutter, too, and alternatives to the fly cutter for facing large surfaces, like using a boring head.

[ThisOldTony] does make things other than tooling in his shop, but you’ll have to go to his channel to find them, because we haven’t covered too many of those projects here. We did cover his impressive CNC machine build, though. All [Tony]’s stuff is worth watching – plenty to learn.

Filed under: tool hacks

Hacked Television Uses No Power In Standby Mode

พฤ, 01/05/2017 - 13:00

How much effort do you put into conserving energy throughout your daily routine? Diligence in keeping lights and appliances turned off are great steps, but those selfsame appliances likely still draw power when not in use. Seeing the potential to reduce energy wasted by TVs in standby mode, the [Electrical Energy Management Lab] team out of the University of Bristol have designed a television that uses no power in standby mode.

The feat is accomplished through the use of a chip designed to activate at currents as low as 20 picoamps.  It, and a series of five photodiodes, is mounted in a receiver which attaches to the TV. The receiver picks up the slight infrared pulse from the remote, inducing a slight current in the receiving photodiodes, providing enough power to the chip which in turn flips the switch to turn on the TV. A filter prevents ambient light from activating the receiver, and while the display appears to take a few seconds longer to turn on than an unmodified TV, that seems a fair trade off if you aren’t turning it on and off every few minutes.

While some might shy away from an external receiver, the small circuit could be handily integrated into future TVs. In an energy conscious world, modifications like these can quickly add up.

We featured a similar modification using a light-sensitive diode a few years ago that aimed to reduce the power consumption of a security system. Just be wary of burglars wielding flashlights.

[Thanks for the submission, Bernard!]

Filed under: hardware, home entertainment hacks

Browsing Forth

พฤ, 01/05/2017 - 10:00

Forth has a strong following among embedded developers. There are a couple of reasons for that. Almost any computer can run Forth, even very small CPUs that would be a poor candidate for running programs written in C, much less host a full-blown development environment. At its core, Forth is very simple. Parse a word, look the word up in a dictionary. The dictionary either points to some machine language code or some more Forth words. Arguments and other things are generally carried on a stack. A lot of higher-level Forth constructs can be expressed in Forth, so if your Forth system reaches a certain level of maturity, it can suddenly become very powerful if you have enough memory to absorb those definitions.

If you want to experiment with Forth, you probably want to start learning it on a PC. There are several you can install, including gForth (the GNU offering). But sometimes that’s a barrier to have to install some complex software just to kick the tires on a system.

We have all kinds of other applications running in browsers now, why not Forth? After all, the system is simple enough that writing Forth in Javascript should be easy as pie. [Brendanator] did just that and even enhanced Forth to allow interoperability with Javascript. The code is on GitHub, but the real interesting part is that you can open a Web browser and use Forth.

If you want to learn Forth, you could do worse than start here. You can also use the Web browser-based Forth to try things as you read. If you want to create you own Forth, though, you really ought to read JONESFORTH. Not only is it a Forth system in two files (an assembly language file and a Forth file), but it is one of the best examples of literate programming we’ve ever seen.

In addition to a lot of older computers and–of course–the PC, you can find Forth for many modern processors. For example, we’ve seen systems for the LPC ARM chips. There’s even a version for the ESP8266 and the Arduino (see the video about that Forth, below).

Filed under: Software Development, software hacks

Another Electric Longboard Goes the Distance

พฤ, 01/05/2017 - 07:00

Looks like electric longboards are becoming a thing, with increasingly complex electronics going into them to squeeze as much performance as possible out of them. When an electric longboard lasts for 35 miles, can longboard hypermiling be far behind?

If endurance longboarding sounds familiar, it’s because we just covered a 25-mile electric that outlasted its rider. To get the extra 10 miles, [Andrew] cheated a little, with a backpack full of extra batteries powering his modified Boosted Board, a commercially available electric longboard. But the backpack battery was only a prototype, and now [Andrew] is well on his way to moving those batteries to a custom underslung enclosure on his new “Voyager” board. Eschewing balancing and monitoring circuitry in favor of getting as many batteries on board as possible, [Andrew] managed sixty 18650s in a 10S6P configuration for 37 volts at 21 Ah. He didn’t scrimp on tools, though – a commercial terminal welder connects all the battery contacts. We really like the overall fit and finish and the attention to detail; an O-ring seal on the 3D-printed enclosure is a smart choice.

Voyager isn’t quite roadworthy yet, so we hope we’ll get an update and perhaps a video when [Andrew] goes for another record.

Filed under: transportation hacks

Hand Cranked Generator Charges Supercaps, Starts Car

พฤ, 01/05/2017 - 04:00

Pity the lowly lead-acid battery. A century of use as the go-to method for storing enough electrons to spin the starter motor of a car engine has endeared it to few.  Will newer technology supplant that heavy, toxic, and corrosive black box under your hood? If this supercapacitor boost box is any indication, then we’d say lead-acid’s days are numbered.

To be fair, we’ll bet that number is still pretty big. It takes a lot to displace a tried and true technology, especially for something as optimized as the lead-acid battery. But [lasersaber]’s build shows just how far capacitive storage has come from the days when supercaps were relegated to keeping your PC’s clock running. With six commercial 400F caps and a custom-built balance board, the bank takes a charge from a cheap 24V hand generator. The output is either to a heavy-duty lighter socket or some automotive-style lugs, and the whole thing is housed in a simple box partially constructed using energy stored in the bank. Can the supercaps start a car? Stay tuned after the break for the answer.

Although we’ve seen supercaps replace a motorcycle battery before, we’re a little disappointed that the caps used here only have a 1500-hour life – lead-acid wins that fight hands down. But this one gives us lots of ideas for future builds, and we’re heartened by the fact that the supercaps for this build ring up to less than $70.

Filed under: car hacks, misc hacks

Toshiro Kodera: Electromagnetic Gyrotropes

พฤ, 01/05/2017 - 02:32

We’ve learned a lot by watching the talks from the Hackaday Superconferences. Still, it’s a rare occurrence to learn something totally new. Microwave engineer, professor, and mad hacker [Toshiro Kodera] gave a talk on some current research that he’s doing: replacing natural magnetic gyrotropic material with engineered metamaterials in order to make two-way beam steering antennas and more.

If you already fully understood that last sentence, you may not learn as much from [Toshiro]’s talk as we did. If you’re at all interested in strange radio-frequency phenomena, neat material properties, or are just curious, don your physics wizard’s hat and watch his presentation. Just below the video, we’ll attempt to give you the Cliff’s Notes.

Freaking Magnets, How Do They Work?

In the end, what [Dr. Kodera] is after is something like a diode, but for microwaves: a material that will let waves pass in one direction but not in the other. Such materials already exist, and are in use in very specialized applications, but making the particular ferrite that’s needed is expensive, and damaging to the environment because they require Yttrium, which occurs alongside radioactive ores. And anyway, yttrium iron garnet is incompatible with silicon technologies, so it’ll never be integrated into ICs.

But what yttrium iron garnet does do is exhibit magnetic gyrotropy, and here’s our first physics lesson. Magnets work because of domains of electrons with similar spin. Like the windings in an inductor, the spinning charges make a magnetic field. If you hit certain magnetic materials with an external magnetic field, it effectively puts a torque on them.

If you think of the spinning electron like a gyroscope, and you remember something about vector cross products, you’ll recall that when you apply an external torque to a gyroscope, it starts to wobble or precess. The equivalent phenomenon in electrons is magnetic gyrotropy, and getting the spinning electrons precessing breaks a symmetry in the material’s magnetic properties. And this in turn is the key to making one-way wave propagation possible.

The other downside of using natural magnetic gyrotropy in a “wave diode” is that the frequency with which the electrons precess depends on the magnetic field strength applied. In particular, they precess at 28 GHz per Tesla of applied magnetic field. You can get a Tesla or so on the surface of a neodymium magnet, but if you want to generate it with an electromagnet, it becomes challenging — an MRI system runs at one to three Tesla, and the detectors in the Large Hadron Collider at CERN run only 8 T. In short, making natural magnetic gyrotropes useful in the microwave range requires big magnets.


[Dr. Kodera]’s approach is to build up small circuits out of non-exotic materials that, when viewed together as an aggregate, have the same material properties of magnetic gyrotropy. If the individual sub-circuits are small enough compared to the wavelength of interest, the metamaterial will behave like a homogeneous material as far as the designer is concerned, but can avoid using rare-earth elements or requiring hefty magnetic fields.

The basic unit of [Dr. Kodera]’s investigation is a ring with a gap in it. Like the split-ring in Hertz’s early electromagnetic experiments the ring will oscillate best at a particular resonant frequency. So far, so symmetric. But then a diode (or FET used as a diode) is placed in the gap of the ring, breaking the symmetry and allowing this basic element to be the building block for diode-like electromagnetic metamaterials.

In the talk, [Dr. Kodera] presents a circulator, an beam-steerable antenna, and a duplex antenna made using this technique. A circulator is a three-port device with the odd property that signals going in port 1 come out port 2 but not port 3, signals going into port 2 come out port 3 but not port 1, and signals going in port 3 come out port 1, but not 2.

His duplex antenna is basically a radiating extension of a circulator — by using this one-way property, he is able to transmit and receive on the same antenna at the same time without getting the signals mixed up. Crazy. There’s more detail about the applications and the physics in the talk.

Clark Kent? Or Superman?

Until this talk, we only knew [Toshiro Kodera] as [kodera2t], a prolific contributor to Hackaday.io and Tindie. We’ve covered a few of his projects before on the blog. We knew that he was interested in minimalist microcontroller projects, capable of amazing miniaturization, and a builder of quality homebrew PCBs. We were pretty certain that he wasn’t actually a guinea pig, but it’s nice to see this confirmed on stage.

We’re often as impressed by what members of the Hackaday community do when they’re not hacking as when they are. It’s no surprise that some of the really brilliant hacks come from folks who are brilliant for a living as well, but it’s nonetheless inspiring to see what a pool of talent we actually have here. Thanks, [Dr. Kodera] for giving us a peek into that other side of your life. But keep up the microcontroller hacks too!

Filed under: cons, wireless hacks

Rust Running on the Realtek RTL8710: ESP8266 Alternative?

พุธ, 01/04/2017 - 23:30

For simply getting your project connected to WiFi, a least among hacker circles, nothing beats the ESP8266. But it’s not the only player out there, and we love to see diversity in the parts and languages that we use. One of the big shortcomings of the ESP8266 is the slightly-oddball Xtensa CPU. It’s just not as widely supported by various toolchains as its ARM-based brethren.

And so, when [Zach] wanted to do some embedded work in Rust, the ESP8266 was out of the picture. He turned to the RTL8710, a very similar WiFi module made by Realtek. Documentation for the RTL8710 is, at the moment, crappy, much as the ESP8266 documentation was before the hacker community had at it. But in trade for this shortcoming, [Zach] got to use the LLVM compiler, which supports the ARM architecture, and that means he can code in Rust.

In the end, the setup that [Zach] describes is a mix of FreeRTOS and some of the mbed libraries, which should be more than enough to get you up and running fairly painlessly on the chip. We’ve actually ordered a couple of these modules ourselves, and were looking to get started in straight C, but having Rust examples working doesn’t hurt, and doesn’t look all that different.

Is anyone else using the RTL8710? An ARM-based, cheap WiFi chip should be interesting.

Filed under: Microcontrollers, wireless hacks

Maintenance, Emissions, and Privacy: The OBD Story

พุธ, 01/04/2017 - 22:01

The 90s were a pivotal time in world history, and 1996 was no different. You might have spent the year glued to the TV playing Super Mario 64, or perhaps you were busy campaigning for Bill Clinton or Bob Dole, or maybe you were so depressed that Princess Diana and Prince Charles divorced that you spent the whole year locked in your room, a prisoner of your own existential nihilism. Whatever you did, though, it’s likely that one major event passed you by without a thought: The standardization of on-board vehicle diagnostics (in the US), otherwise known as OBD-II.

In the 1970s, vehicles (in some western countries, at least) were subject to ever-increasing restrictions on emissions. Most companies began switching from carburetors to efficient fuel injection systems, but even that wouldn’t be enough for the new standards. Cars began to carry rudimentary computer systems to manage and control the influx of valves, meters, and sensors that became the new norm. And, as one would guess, every car company had their own standard for managing and monitoring these computer systems. Eventually they would settle on the OBD system that we have today.

Sea Change

First, though, we should go back in time to see what led to this sea change in the automotive industry. In the beginning, the only way to diagnose a problem with a car was to investigate unusual noises, poor performance issues, or other problems directly. This can be especially troublesome on electrical problems because of their invisible nature. It was only a matter of time before someone hacked together a way to make the troubleshooting process easier. That’s partially why the first mass-produced vehicle diagnostics systems had almost nothing to do with emissions and focused mostly on helping mechanics identify common problems.

The first of these systems came online in the late 60s on some Volkswagens. (Here’s on in evidence in the author’s Beetle.) The proprietary test port that was installed in these cars gave the mechanics easy access to the electrical system via a “small” computer that could test a number of different aspects of the car. From there they could tell if lights were burned out, some information on the ignition system, and (for fuel injected cars) some information on the fuel delivery system. Even though a 1970s Volkswagen is pretty late in the game as far as old Volkswagens go (the first model year was 1938) it was still early for the industry and gave VW mechanics a leg up on troubleshooting.

The next car company to take a stab at a vehicle diagnostics system was Nissan on their 280Z sports car. Unlike Volkswagen, this system was intended to help manage the increasing demands of the fuel injection system in the post-EPA world. Not to mention the fact that the 280Z was a pioneering performance car, and any gains that could be made by using a computer to fine-tune the engine were welcomed.

After the success of Volkswagen and Nissan, other car companies saw the perks of having a diagnostics system that was easy for mechanics to plug into to identify problems with vehicles. General Motors created their own proprietary system in the 80s that helped factory workers identify problems with cars as they rolled off the assembly line. Although it’s probably not a good sign for your manufacturing process that you need to specially design diagnostic tools for brand new cars (after all, when was the last time you saw a Cadillac Cimarron on the road?), the GM diagnostic system did find some utility with mechanics for a time.

Unification (Slide from this talk on OBD-II)

At this point there are many different car companies having equally different standards for interacting with the on-board diagnostic systems. This is where the US federal government stepped in with a mandate that all cars have a standard OBD system by a certain date. As a result, diagnostic systems really start to focus almost all of their attention to the emissions systems. The first standard was known as OBD-I and took effect gradually in the late 80s and early 90s. This system was primitive by comparison to its successor, OBD-II, which is the current standard for all cars sold in the United States since 1996. Most other first world countries adopted this (or similar) standards around this time as well.

The current OBD-II standard specifies the protocols used to monitor many of the sensors in the car and can alert the driver if any of them aren’t operating properly. Most cars built under this standard have an increased number of oxygen sensors, control over mass air flow sensors and the fuel injectors, and many other aspects of the car. All of this means that there are more efficient engines on the road that all communicate in a way that makes it easy to tell why the check engine light on your dashboard came on. It also makes it easy for a mechanic to test the emissions of the car if you live in a place the requires your vechile to pass an emissions test. All the mechanic has to do for an OBD-II compliant car is plug into the OBD port and view the output on another monitor, rather than fuss with attaching sensors to the exhaust and running the car through a battery of tests.

On the other hand, there’s a lot to be desired from a system that was designed years before anyone had heard of Super Smash Bros. There’s some talk about a new OBD-III standard that would allow cars to take advantage of the growing wireless network, essentially adding “all new cars” to the list of Internet of Things devices. It would then be possible for a car to report itself to regulatory agencies, and for the car to be shut down remotely if it violates any emissions laws. While this could be argued to be a win for the environment, there are certainly concerns about government overreach and Big Brother that will need to be addressed before anything substantial is brought to market. It would have probably made it harder for Volkswagen to have cheated their emissions test results, for example, but the benefits might not outweigh the unintended consequences of something like this. Whatever the new OBD standard will include, though, it will be a welcome improvement for the aging system we have in OBD-II.


Filed under: car hacks, Featured

The Cyborg Artist – Tattoo Machine Arm Prosthesis

พุธ, 01/04/2017 - 19:00

[JC Sheitan Tenet] lost his right arm when he was 10 years old. As most of us, he was right-handed, so the challenges he had to face by not having an arm become even harder.

Have you ever tried to perform mundane tasks with your non-dominant hand? If you’re right-handed, have you ever tried to feed yourself with your left? Or if you’re left-handed, how well can you write with your right? For some people, using both hands comes naturally, but if you’re anything like me, your non-dominant hand is just about useless.

The thing is, he wanted to be a tattoo artist. And he wasn’t giving up. Even facing the added difficulty of not finding a tattoo artist that wanted to take him as an apprentice, he did not gave up. So he became a tattoo artist, using only his left arm. That is, until some months ago, when he met [Jean-Louis Gonzal], a bio-mechanical artist with an engineer background, at a tattoo convention. After seeing [Gonzal] work, he just asked if it was possible to modify a prosthesis and attach a tattoo machine to it.

The Cyborg Artist is born. The tattoo machine in the prosthesis can move 360 degrees for a wide range of movements. [JC Sheitan Tenet] uses it to help with colours, shadows and abstract forms in general. It’s a bad-ass steam punk prosthesis and it’s not just for show, he actually works with it (although not exclusively) . This, it seems, is only the beginning, since the first version of prototype worked so well, the second version is already being planned by [JC] and [Gonzal]. We can’t wait to see what they’ll come up with, maybe a mix between current version and a tattoo robotic arm or a brain controlled needle?

Check it out in the video:

[Thanks dunryc]


Filed under: hardware, Medical hacks, tool hacks

From IKEA Lamp To Robot Arm

พุธ, 01/04/2017 - 16:00

We’re used to projects that take everyday household objects and modify or enhance them into new and exciting forms that their original designers never intended. A particular theme in this endeavour comes from the IKEA hacking community, who take the products of the Swedish furniture store and use them for the basis of their work.

A particularly inventive piece of IKEA hacking is a project from [anastas.car], a low-cost 3D-printed robot arm based on Ikea Tertial lamp. The lamp in question is a relatively inexpensive spring-balanced desk lamp that when looked at in another light has all the metalwork ready-cut for a 5 degrees of freedom robot arm when combined with 3D-printed servo holders for five servos at its joints. The resulting design has all files available on Thingiverse, and judging by the video we’ve posted below the break makes for a rather effective arm.

A quick search reveals IKEA hacks to be a regular feature here, we’ve brought you more than a few. Just a selection are an IKEA desk laser cutter from Craigslist finds, an IKEA table that has been used as the frame for a 3D printer, and a rather pretty IKEA lamp hack. The IKEA hacking community are a resourceful bunch, and we look forward to more of their creations.

Filed under: robots hacks

A Ten Turn Pot, For Not A Lot

พุธ, 01/04/2017 - 13:00

If you have a traditional regulated power supply that you want to make adjustable, you’ll have somewhere in the circuit a feedback line driven by a potential divider across the output. That divider will probably incorporate a variable resistor, which you’ll adjust to select your desired voltage.

The problem with using a standard pot to adjust something like a power supply is that a large voltage range is spread across a relatively small angle. The tiniest movement of the shaft results in too large a voltage change for real fine-tuning, so clearly a better means of adjustment is called for. And in many cases that need is satisfied with a ten-turn potentiometer, simply a pot with a 10 to 1 reduction drive built-in.

[Dardo] had just this problem, and since 10-turn pots are expensive to buy and expensive to ship to his part of the world he built his own instead of buying one.

His 10-turn pot is a fantastic piece of workbench improvisation to deliver the goods from what is at hand. A capstan and shaft from an old radio tuner drives a small rubber belt and pulley from a CD-ROM drive. This in turn has a gear which drives a much larger gear coupled to the shaft of a standard potentiometer. All the drive components are mounted on a frame made from an old aluminium heatsink.

To be strictly accurate it’s a 13-turn pot rather than a 10-turn one, but the principle is the same. And it’s an extremely effective component, especially for the price. We like it!

If you are inspired to put a 10-turn pot in your supply then this project provides a blueprint. It’s worth saying though you could take a look at an off-the-shelf component instead.

Filed under: parts

Laser-Cut Gingerbread Trailer Home

พุธ, 01/04/2017 - 10:00

Ah, the holiday gingerbread house. A traditional — if tedious — treat; tasking to create, delicious to dismantle, so why not try applying some maker skills to making the job of building it easier? [William Osman] decided to try two unorthodox approaches to the gingerbread construct; first, he opted to build a gingerbread mobile home. Secondly, he cut the pieces out with a laser cutter.

After the tumultuous task of baking the gingerbread sheets, [Osman] modeled the trailer in SolidWorks and set to work cutting it out on his home-built, 80W laser cutter. Twice. Be sure to double check the home position on any laser cutting you do, lest you ruin your materials. Also — though this might be especially difficult when modelling food in any CAD programs — be sure to account for the thickness of your materials, otherwise you’ll end up with a lot of trimming on your hands. At least gingerbread cuts easily.

Hot glue and royal frosting secured the pieces together — as well as some improvisation of the final details — making for a picture perfect holiday scene — from a certain point of view.

If you try laser cutting your food, keep it out of the refrigerator or you may find everything infused with a burnt flavour. Still, the potential for dazzling complexity in one’s gingerbread creations makes this an appealing option for anyone with the moxie to try it.

Filed under: Holiday Hacks, Uncategorized

Getting The Amiga 500 Online

พุธ, 01/04/2017 - 07:00

If you were lucky enough to have a Commodore Amiga or one of its competitor 16-bit home computers around the end of the 1980s, it’s probable that you were doing all the computing tasks that most other people discovered a few years later when they bought their first 486 or Pentium. So in the mid 1990s when all your friends were exclaiming at Paint Shop Pro or their Soundblaster cards you’d have had an air of smugness. Multitasking? Old hat! Digital audio? Been there! Graphics manipulation? Done that!

There was one task from that era you almost certainly wouldn’t have done on your Amiga though, and that was connect it to the Internet. The Internet was certainly a thing back in the late 1980s, but for mere mortals it was one of those unattainable marvels, like a supercomputer with a padded seat round it, or a Jaguar XJ220 supercar.

Later Amigas received Internet abilities, and Amiga enthusiasts will no doubt be on hand to extol their virtues. But the machine most people will think of as the archetype, the Amiga 500, lacks the power to run most of the software required to do it. If your 500 with its tasteful blue and orange desktop colour scheme is languishing though, never fear. [Shot97] has produced a guide to getting it online.

It’s important to understand that an Amiga 500 is never going to run a copy of Chrome or play a YouTube video. And he makes the point that any web browsers that might have surfaced for hardware of this class delivered a painful browsing experience. So instead he concentrates on getting the 500 online for something closer to the online scene of the day, connecting to BBSs. To that end he takes us through setting up a PC with  Hayes modem emulator, and connecting it to the Amiga via a null modem cable. On the Amiga is a copy of the A-Talk terminal emulator, and as far as the Amiga is concerned it is on a dial-up Internet connection.

The PC in this case looks pretty ancient, and we can’t help wondering whether a Raspberry Pi or even an ESP8266 module could be put in its place given the appropriate software. But he has undeniably got his A500 online, and shown a way that you can too if you still have one lurking in the cupboard. He has also produced a video which we’ve put below the break, but be warned, as it’s nearly an hour long.

If you are after a wallow in Amiga nostalgia, perhaps you’d like to read about a business using the ultimate high-end Amiga on the 1990s. And if you want to take it further but lack real hardware, have you ever tried AROS?

Via Hacker News.

Filed under: classic hacks

Retro-Style DIY Polygraph: Believe It Or Not

พุธ, 01/04/2017 - 04:00

A polygraph is commonly known as a lie detector but it’s really just a machine with a number of sensors that measure things like heart rate, breathing rate, galvanic skin response and blood pressure while you’re being asked questions. Sessions can be three hours long and the results are examined by a trained polygraph examiner who decides if a measured reaction is due to deception or something else entirely. Modern polygraphs feed data into a computer which analyses the data in real-time.

Cornell University students [Joyce Cao] and [Daria Efimov] decided to try their hand at a more old fashioned polygraph that measures heart and breathing rates and charts the resulting traces on a moving strip of paper as well as a color TFT display. They had planned on measuring perspiration too but didn’t have time. To measure heart rate, electrodes were attached to the test subject’s wrists. To measure breathing they connected a stretch sensor in the form of a conductive rubber cord around three inches long to a shoelace and wrapped this around the test subject’s abdomen.

While the output doesn’t go into a computer for mathematical analysis, it does go to a PIC32 for processing and for controlling the servos for drawing the traces on the paper as well as displaying on the TFT. The circuit between the breathing sensor and the PIC32 is fairly simple, but the output of the heart rate electrodes needed amplification. For that they came up with a circuit based off another project that had a differential amplifier and two op-amps for filtering.

Since parts of the circuit are attached to the body they made some effort to prevent any chance of electrocution. They used 12 volts, did not connect the test subject to power supply chassis ground, and tested the heart rate electrodes with a function generator first. They also included DC isolation circuitry in the form of some resistors and capacitors between the heart rate electrodes and the amplifier circuit. You can see these circuits, as well as a demonstration in the video below. The heart rate output looks a little erratic, no surprise given that the body produces a lot of noise, but the breathing trace looks very clear.

[Joyce] and [Daria] were mentored in this project by Cornell’s [Bruce Land] whose students have been so prolific over the years that he has his own tag here on Hackaday. Pulling out a random sample of their projects check out this real-time video anonymizer, these FPGAs that keep track of a ping-pong game, or you can become a student yourself and take one of his courses.

Filed under: Medical hacks

Derek Schulte: Path Planning for 3D Printers

พุธ, 01/04/2017 - 02:31

[Derek Schulte] designed and sells a consumer 3D printer, and that gives him a lot of insight into what makes them tick. His printer, the New Matter MOD-t, is different from the 3D printer that you’re using now in a few different ways. Most interestingly, it uses closed-loop feedback and DC motors instead of steppers, and it uses a fairly beefy 32-bit ARM processor instead of the glorified Arduino Uno that’s running many printers out there.

The first of these choices meant that [Derek] had to write his own motor control and path planning software, and the second means that he has the processing to back it up. In his talk, he goes into real detail about how they ended up with the path planning system they did, and exactly how it works. If you’ve ever thought hard about how a physical printhead, with momentum, makes the infinitely sharp corners that it’s being told to in the G-code, this talk is for you. (Spoiler: it doesn’t break the laws of physics, and navigating through the curve involves math.)

The Problem

Path planning goes on inside the 3D printer itself. It’s what the 3D printer’s firmware does with the received G-code that turns it into the physical motion of motors along the X, Y, and Z axes as well as the extruder. While G-code is universal, it’s also unrealistic: it specifies a series of points in 4D space (the extruder, remember?) and the speeds that are needed to get there. Path planning blends knowledge of the physical printer’s motion control abilities and tries to make the end result match the G-code as much as reasonably possible, without taking forever. Being the interface between idealized G-code and a real printer, the planning firmware needs to take the design of the printer itself, with all its physical limitations, into account.

You can make your own, one-off, 3D printer out of unobtainium, dragon scales, and the unbilled labor of a year’s worth of weekends. But if you want to make a product to sell to the general public at a reasonable price, it’s got to be built using commodity parts and work robustly. This is what drove [Derek] to use a DC motor with an encoder instead of the ubiquitous, heavy, and relatively expensive stepper motors that most other 3D printers use. Driving DC motors in open-loop feedback meant that none of the “standard” printer firmwares were going to work — he needed to roll his own. And that’s how we have this talk, about getting from A to C, around the corner in B, as quickly and accurately as possible.

Trapezoids, and the KISS Principle

There are a few ways to turn a piece of G-code that says “go north at 50 mm/sec and then go west at 50 mm/sec” into machine movement. One is to go north at full speed, slam to a stop, and then jerk off west at full speed. This is what the earliest versions of DIY 3D printer firmware did — and the result was noise, and vibration of the print head, and degradation in print quality. These were ugly times.

[Derek], and the path planner in grbl, chose the next most complicated solution — moving at constant acceleration for each segment of the path, resulting in trapezoidal velocity profiles. This turns out to work decently well in practice and be easy to compute. [Derek] added corner rounding to the routine: where the G-code said to make a sharp corner, the firmware would take a curved corner that’s close enough that it wouldn’t look bad, but also doesn’t require the nozzle to slow to a stop. Combining the two is basically the simplest solution that can work well.

Connecting a few segments together is the next step, but it lets the printer eventually come to a stop, whether at the end of the path or because a user pressed the pause button.

Closed-loop Control

Most stepper-driven 3D printers operate in open-loop control mode. The firmware tells the stepper motor driver to take ten steps forward and hopes for the best. When a printer loses steps, layers get de-aligned from each other, and if you’ve had this happen catastrophically in the middle of a print, you know why this can suck.

[Derek]’s printer runs in closed-loop mode, meaning that if the printhead is too far south of where it should be, the firmware can tell that this is the case and apply more power to a motor to get it back right. Again, [Derek] chose one of the simplest methods that could work: PID control with feedforward. Of course, this means calibrating the algorithm to the machine, but a well tuned PID algorithm is a joy to watch.

And the closed control loop provides additional benefits. Where stepper motors have to be way overspecified to avoid the dreaded missed steps, closed-loop DC motors can get by on lower torques. The coolest trick that [Derek] plays with the feedback, however, is in using the ability to detect motor stall to home the printer. There are no limit switches on the three physical axes. Instead, when the motor hits the end of its ability to move, the firmware detects the stall and uses this to zero the coordinate axes. This reduces parts and simplifies the device. We’re all for that.


[Derek] designed his motion planning routines on the same tools that we all use, and used basically the simplest possible algorithms that would work well, avoiding “academic” complications for their own sake. In the end, this allowed him to optimize for speed, look fifteen steps ahead, include some necessary special tweaks like logic for dealing with very short segments and get the product out the door for a reasonable price. Motion planning and control in a closed-loop system is never simple, but “apply the KISS principle as far as possible and then tweak for performance later” is something that all of us hackers could stand to get tattooed on some suitably long part of our bodies. Better still, let’s just thank [Derek] for the reminder and exemplification!

Filed under: 3d Printer hacks, cons, Hackaday Columns

Ditch OpenSCAD for C++

พุธ, 01/04/2017 - 01:01

There’s an old saying that a picture is worth a thousand words. If you’ve ever tried to build furniture or a toy with one of those instructions sheets that contains nothing but pictures, you might disagree. 3D design is much the same for a lot of people. You think you want to draw things graphically, but once you start doing complex things and making changes, parametric modeling is the way to go. Some CAD tools let you do both, but many 3D printer users wind up using OpenSCAD which is fully parametric.

If you’ve used OpenSCAD you know that it is like a simple programming language, but with some significant differences from what you normally use. It is a good bet that most Hackaday readers can program in at least one language. So why learn something new? A real programming language is likely to have features you won’t find readily in OpenSCAD that, in theory, ought to help with reuse and managing complex designs.

I considered OpenJSCAD. It is more or less OpenSCAD for JavaScript. However, JavaScript is a bit of a scripting language itself. Sure, it has objects and some other features, but I’m more comfortable with C++. I thought about using the OpenCSG library that OpenSCAD uses, but that exposes a lot of detail.

Instead, I turned to a project that uses C++ code to generate OpenSCAD output, OOML (the Object Oriented Mechanics Language)). OpenSCAD does the rendering, exporting, and other functions. Unfortunately, the project seems to have stalled a few years back and the primary web-based documentation for it seems to be absent. However, it is very usable and if you know how to find it, there is plenty of documentation available.

Why not OpenSCAD?

Obviously, there’s nothing in OOML that you can’t do in OpenSCAD. Which is like saying you can do everything C++ does in assembly language: it is true, but kind of misses the point. First, OOML defines many more basic objects (see below for a graphic taken from a white paper about OOML). If you want, for example, a RoundedTablet, you simply create one and the final output will have the necessary OpenSCAD.

Sure, you could define that stuff with a module. There’s also a library of parts including Arduino outlines, bearings, and other useful components. But the real value is that you can bring to bear all of the C++ features to developing new shapes.

Here’s a simple example. One of the parts available is the shape of a generic ultrasonic transducer module. The class provides a constructor that lets you set the different attributes like the size of the board, the size of the sensors, and more.

There is also a part that is a specific brand of ultrasonic sensor (one from Seeed Studios). Here’s how to create one of those in an OOML C++ program: SeeedUSSensor sensor;

That’s it. Here’s the definition of the SeeedUSSensor constructor:

SeeedUSSensor(bool fill_drills = true) : USSensor(43,20,15,2,40,17,1,16.1/2,20-16.1/2,fill_drills) { rebuild(); }

That’s out of context, but there’s nothing else significant in that object. All the rendering is in the USSensor base class. I could as easily make my own class for a Seeed sensor on a bracket, for example. I would just derive a new class and provide the additional rendering (or I could use any other C++ technique such as making my new object instantiate the sensor object).

Another feature that isn’t necessarily compelling is that I personally like the syntax. Here’s how you translate an object in OpenSCAD:

translate([10,10,0]) cube([5,5,10]);

Here’s the same code in OOML:

Component cube(Cube(5, 5, 10)); cube.translate(10,10,0);

If you want to take a union and a difference of some OOML objects:

result=cube1+cube2-boltholes; Documentation is Like Oxygen

At one time there was a Wiki with documentation about the project, but it has either moved or is gone. However, the project is set up to do Doxygen documentation. It isn’t complete, but it is over 2,000 HTML files (which is probably why it isn’t on GitHub). You can generate it easily, but to save you the trouble, I forked the project and added the documentation as a ZIP file you can download.

The other way to learn about OOML is to read the source code. In particular, the test subdirectory has everything from a simple cube, to some fairly complex shapes. If you dive into the src directory you can also find examples of interesting things like the ultrasonic sensor I showed you earlier.


Having the power of C++ at your design fingertips is nice. What isn’t nice is losing the immediate design cycle you get with OpenSCAD. Being able to just tweak a number, hit F5, and repeat is pretty addicting. Using things like the octothorpe (I have too many British friends to call it a pound sign) to visualize a cut is a big loss, too.

You can’t do much about the special characters unless you read through the OpenSCAD code and find the right spot to put it (which somewhat defeats the purpose of using OOML). However, you can help get a little more immediate feedback with some setup.

All you need to do is open up the generated OpenSCAD file one time. Then make sure that “automatically reload” is checked on the Design menu. Now when you rerun your executable program and write over the OpenSCAD, the program will detect that, ask you to confirm and reload the file. Not quite as handy, but not bad.

If you are just making a simple keychain, this is probably more overhead than you want. But if you are doing a complex design with a lot of pieces that you reuse, with small differences, it can be just the thing.

Something Simple

Here is a pretty simple OOML program. I factored out the drawing code from the part that writes the output.

#include <core/IndentWriter.h> #include <components/RoundedTablet.h> #include <components/Cylinder.h> #include <iostream> #include <fstream> void render(IndentWriter &writer) { Component obj(RoundedTablet(100,100,5,25,true,false,false,false)); Component cyl(Cylinder(25,10)); cyl.translate(22,22,-2); writer << obj-cyl; } int main(int argc, char **argv) { IndentWriter writer; render(writer); std::cout << writer; return 0; }

What that means is you can ignore the code in main and focus on the render function. I build a RoundedTablet with only one corner rounded (that’s not well documented, but you can figure it out from the parameter names). Then I cut a cylinder out of one corner. Granted, this wouldn’t be very hard to do in OpenSCAD and it doesn’t really show off the features you could use, but I wanted something simple to let you see how it works.

You can see the resultant OpenSCAD rendering at the start of this post. Once you have it at this point, you can do anything OpenSCAD can do.


Since OOML doesn’t do any of the actual graphics generation itself, it is easy to build. I built a copy under Cygwin, but it should be about the same on Linux. You do need cmake installed. Here are the basic steps:

cmake . make make install

I did have to play with the DLL locations a bit on Windows, but that’s nothing new. To compile my example, I issued the following command:

g++ -o had -L ../lib -I ../src had.cpp -lOOMLCore -lOOMLComponents -lOOMLParts && ./had >had.scad

Note the part after the && actually runs the resulting program and then you still have to open the had.scad file (although just once if you turn on auto reload).

Give OOML a try. It is open source, so if there’s anything missing, you could add it to your own fork of the code. While I’d start small, the real power is when you want to build complex objects or systems of objects using C++. I can imagine a base class for chess pieces, for example. Or pulling data from a database to drive object creation.

Filed under: 3d Printer hacks