There are piles of old 128MB and 256MB sticks of RAM sitting around in supply closets and in parts bins. For his Hackaday Prize project, [esot.eric] is turning these obsolete sticks of RAM into something useful – a big, fast logic analyzer. It’s cheap, and simple enough that it can be built on a breadboard.
If using old SDRAM in strange configurations seems familiar, you’re correct. This project is based on [esot.eric]’s earlier AVR logic analyzer project that used a slow AVR to measure 32 channels of logic at 30 megasamples per second. The only way this build was possible was by hacking an old stick of RAM to ‘free run’, automatically logging data to the RAM and reading it out with an AVR later.
This project expands on the earlier projects by using bigger sticks of RAM faster, with the ultimate goal being a 32-bit, 133MS/s logic analyzer that is more of a peripheral than a single, monolithic project. With a Raspberry Pi Zero, a stick of RAM, and a few miscellaneous logic chips, this project can become anything from a logic analyzer to a data logger to an oscilloscope. It’s weird, yes, but the parts to make this very handy tool can be found in any hackerspace or workshop, making it a great trick for the enterprising hardware hacker.The HackadayPrize2016 is Sponsored by:
Filed under: The Hackaday Prize
The modern motorcycle represents the pinnacle of over a century of refinement in design and manufacture of its every component. A modest outlay will secure you a machine capable of three figure speeds with impeccable handling, breathtaking acceleration and stopping power, that somehow seems also to possess bulletproof reliability that will take it to a hundred thousand miles of faithful transport.
At the dawn of the internal combustion engine age it was a different matter. Machines were little more than bicycles with rudimentary engines attached, brakes and tyres were barely capable of doing the job demanded of them, and the early motorcyclists were a hardy and daring breed.
You might think that this article would now head into retrotechtacular territory with a nostalgic look at an early motorcycle, but instead its subject has a much more recent origin. We happened upon [Buddfab]’s contemporary build of a 1905-era motorcycle, and we think it’s a bike you’d all like to see.
The bike itself is a faithful reproduction of a typical Edwardian machine. It has a modified bicycle frame with a belt drive and springer front forks. That’s all very impressive, but the engine is a masterpiece, crafting a more modern parts bin into something resembling a 1905 original. He’s taken the cylinder, piston, and half a cylinder head from an aircooled VW flat four and mated it with the crankshaft of a 125cc Honda, welding the two connecting rods together to join German and Japanese parts. With a custom-made crankcase, Lucas points, and the carburetor from a British Seagull outboard motor it both looks and sounds like an original, though we’d expect it to be significantly more reliable.
You can see videos of both bike and engine below the break, as he takes it for a spin through American suburbia. Sadly we’ll never see it passed to the definitive writer on early motorcycles for an expert view, but it would fool us completely.
And here is a video description of the engine.
We’ve covered quite a few motorcycle builds over the years here at Hackaday. If your tastes run to older machinery how about this 1921 Ner-a-Car rebuild, otherwise may we bring this gas-turbine monster to your attention?
Filed under: classic hacks, transportation hacks
Looking for a fun junk box hack? Have one of those old Nokia phones that (in contrast to your current smartphone) just won’t give up the ghost? Tinkernut has a nice hack for you: making a smart watch from an old cell phone. Specifically, this project details how to make a smart watch that displays time, date, incoming calls and texts from a Nokia 1100 cell phone display and a few other bits.
This 3-video series covers how to extract the display, connect it to an Arduino and conecting that to an Android phone over Bluetooth. We’ve seen a few similar smart(ish) watch builds, but this one covers the whole process well, including building the Android app in the MIT AppInventor. Sure, the final result is not as polished as an Apple Watch, but it’s a lot cheaper and easier to hack…
Filed under: wearable hacks
If you are running out of swear words to comment the magic smoke coming from your electronics, [Howard] has just the right weekend project for you: The reverse swear box. Most swear boxes would have you drop in a coin as penance for uttering your choice phrases. Instead, at the touch of a button, this obscure but classy device randomly suggests a four letter swear word and displays it on a 14-segment LED display for immediate or later use.
It’s built upon an ATmega168 and only requires a minimum of external components. The schematics and firmware for this project are freely available on the project page. There’s also an extremely profane header file, packed with 37 case-insensitive four-letter words you may not actually want to include in your toolkit. On the other hand, many of these words score intimidatingly well at Scrabble.
Filed under: misc hacks
Using Xcode to spoof GPS locations in Pokemon Go (like we saw this morning) isn’t that much of a hack, and frankly, it’s not even a legit GPS spoof. After all, it’s not like we’re using an SDR to spoof the physical GPS signal to cheat Pokemon Go.
To [Stefan Kiese], this isn’t much more than an exercise. He’s not even playing Pokemon Go. To squeeze a usable GPS signal out of his HackRF One, a $300 Software Defined Radio, [Stefan] uses an external precision clock. This makes up for the insufficient calibration of the HackRF’s internal clock, although he points out that this might also be fixed entirely in software.
Using SatGen and a conversion tool that comes with the software-defined GPS signal simulator gps-sdr-sim, [Stefan] turned a *.KML-exported GoogleEarth path into a *.CSV file that can be played back by the GPS simulator.
After firing up the GPS transmission, he found his avatar running happily through the Pokemon world. Someone still has to write the code that lets you navigate freely and actually catch ’em all, but it looks doable, and we are curious to see how and if it will affect the game. For the novice SDR cheater, [Stefan] has some extra advice: Disable A-GPS on your device and use a signal attenuator on the SDR (a shielded box should do).
A legit GPS spoof might still exceed the efforts and investments the average player might want to undertake. Meaning, that if done right, you might actually get away with it. If done wrong however, the legal consequences might be even more severe. But how many players will actually go so far to try this? And will Niantic be able to reliably detect SDR cheaters? What do you think? Let us know in the comment section!
Thanks to [sabas1080] for the tip!
Filed under: gps hacks, nintendo hacks
I should really like I2C more than I do. In principle, it’s a brilliant protocol, and in comparison to asynchronous serial and SPI, it’s very well defined and clearly standardized. On paper, up to 127 devices can be connected together using just two wires (and ground). There’s an allowance for multiple clock-masters on the same bus, and a way for slaves to signal that the master to wait. It sounds perfect.
In reality, the tradeoff for using only two wires is a significantly complicated signalling and addressing system that brings both pitfalls and opportunities for debugging. Although I2C does reduce the number of signal wires you need, it gets dangerous when you have more than a handful of devices on the same pair of wires, and you’re lucky when they all conform to the same standard. I’ve never seen twenty devices on a bus, much less 127.
But still, I2C has its place. I2C was designed to connect up a bunch of slower, cheaper devices without using a lot of copper real estate compared to its closest rival protocol: SPI. If you need to connect a few cheap temperature sensors to a microcontroller (and their bus addresses don’t clash) I2C is a great choice. So here’s a guide to making it work when it’s not working.Physical Layer Image from Sparkfun’s I2C Tutorial
Let’s start off by looking at the wires, because that’s where a surprising number of glitches and complications can creep in. Whereas SPI gets by with the minimal amount of protocol overhead but pays the price in a florescence of wires, I2C only requires you to lay down two tracks: one for the clock (SCK) and one for data (SDA). There is a price for this simplicity when interfacing systems that run at different voltages.
I2C devices can also be constructed with a single transistor per line, because the two lines are pulled up by an external resistor (or resistors). This sounds good, but can cause problems with high-speed signals and high-capacitance lines.
So let’s get down to details.Pullup Resistor vs. Parasitic Capacitance
The problem with relying on pullup resistors is “parasitic capacitance”. While we normally think of a capacitor as being made of two large conductive plates with a dialectric (or air) between them, the same charge-storage capacity exists between two parallel wires as well. And this means that there’s some small capacitance between the I2C signal lines and the PCB’s ground plane, or any other adjacent signals for that matter.
This parasitic capacitance means that the voltage level on the signal line (data or clock) can’t change instantaneously, but some finite current needs to be pumped into the wire to charge up this accidental capacitor. With SPI and asynchronous serial, this is not much of a concern because the high and low voltage levels are both driven by transistors on board the chips in question. Parasitic capacitance matters a lot in I2C because the devices pull down the signal lines, but they’re pulled back up by resistors (or a constant-current source in higher-performance designs).
This means that, while a high-to-low transition can be next to instantaneous, a low-to-high transition will always take some time as the line charges back up. This means that the signal lines can’t be too long, to keep parasitic capacitance at bay. 400 picofarads is the maximum, according to the standard. The optimal choice of pullup resistor varies with line capacitance, desired speed, and the strength of the transistors in the various devices, but 4.7 kOhms is normal.
Here’s some up-close shots of an I2C conversation. (We’ll discuss the protocol below.) Note that the downward transitions are nearly instantaneous, but it takes some time to rise back up to VCC. If these transitions needed to be faster, a smaller resistor could be used for the pullup, with increased power consumption in the bus being the negative side-effect.
See those tiny up and down spikes on the data line that occur in time with the clock (and vice-versa)? That’s the effect of another parasitic capacitance that couples the clock and data lines together. It’s not enough to change any of the digital values, and it decays back down pretty quickly, but in a more extreme form this could cause problems too.
Keeping the lines short and minimally coupled to each other and their surroundings is the cure. If you’re running other data lines over/under the I2C lines, arrange for them to cross seldom, and at 90-degree angles. A long wire with a weak resistive pullup is almost as good as an antenna.Bidirectional — Voltage Level Conversion
The data line (SDA) is necessarily bidirectional: both the master and the slave ICs have to read its voltage. But when you’ve got chips that work at different voltages, the line has to be pulled up to a high voltage on one side, and a lower voltage on the other.
Fortunately, there’s an application note for that (PDF). The standard solution is to use one MOSFET per line and abuse the intrinsic body diodes to pass signals through from the high side to the low side. It’s a nice hack, and you’ll enjoy reading it. You can buy these simple converters pre-made from most hobbyist-friendly shops, or directly from the Far East.The Protocol
So far, I2C sounds only a little bit tricky, but the truly tricky bits all take place at the protocol level. To start out, the data line is always set up when the clock line is low, and can be read out any time the clock line is high. (This definition eliminates the phase/polarity issue with SPI, and the voltage-inversion problems with async serial.) There are two exceptions to this rule: if the data line transitions high to low with the clock high, it’s a start signal, and if data transitions high during a high clock, it’s a stop. Every transaction starts with a start signal and ends with a stop. This, in principle, lets every device on the line know when a conversation is underway, and tells them not to begin a conversation of their own until they see a stop.Image: Marcin Floryan
Because all of the devices share the same two wires, they need addresses. Additionally, the slave devices need to know whether they’re supposed to send or receive data on the single wire. The first byte of any transaction, after the start signal, is a seven-bit address and a single direction bit that tells the slave whether it’s expected to read or write data. For instance, with an LM75 temperature sensor, you can read the two-byte temperature value by sending the device’s address ($48 in this example) combined with the last bit set to one — to read the data. The master then sends two bytes worth of clocks, during which it receives the data, and then sends the stop signal. Well, with one more complication.Transaction detail from Maxim’s LM75 datasheet
Every byte sent on the I2C line is acknowledged (positively or negatively) by the party (slave or master) that just received the last byte. It’s purpose is for the device to say “OK, I got that, go on”. So when the master is reading bytes from the slave, the master acknowledges each one before the next byte is sent. If the master is writing bytes to the slave, it’s the slave that has to acknowledge. A low voltage level, pulling the data line down, is the positive ACK signal, and it means that everything’s alright.
Things are more complicated with the negative-acknowledge (NACK) signal. Depending on context, it can mean “I’m not ready” or “that didn’t make sense” or even “I’m done receiving now”. Because of this multitude of possible meanings, one has to read the data sheet carefully to see when reading data from slaves because the master needs to know when to ACK and when to NACK.
For instance, with the LM75 temperature sensor in its easiest mode, the master sends the address and a read bit, and then reads two bytes back. Since the master sent the address, the slave acknowledges to say it’s ready. Then the slave sends a byte, which the master acknowledges with an ACK. Then the slave sends the second byte, to which the master responds with a NACK and a stop signal to say it’s done.Master: Start Signal Master: Address + Read Bit Slave: ACK Slave: First byte of data Master: ACK Slave: Second / last byte of data Master: NACK Master: Stop Signal
Wrapping up the protocol, there’s also multi-part communications. If the master needs to send a byte to the slave, and then read some bytes back, for example, it needs to first send the address with a write signal and then re-send the address with the read signal. To signal the change of mode, the master sends the so-called “repeated start” signal, which is just a regular start signal when there’s been no preceding stop. Again, here’s an example with the LM75, first telling the LM75 that is wishes to read the high temperature setting, and then reading the two bytes back.Master: Start Signal Master: Address + Write Bit Slave: ACK Master: Set the high-temperature register for reading Slave: ACK Master: (Re-) Start Signal Master: Address + Read Bit Slave: ACK Slave: First byte of data Master: ACK Slave: Second / last byte of data Master: NACK Master: Stop Signal
Note that in both of these examples, when the master is reading an arbitrary amount of data from the slave, the last byte is “acknowledged” with a NACK. This doesn’t mean that it missed a byte, but instead signals the slave that it won’t be requesting any more data. It’s an “all done!” signal. If you’re having trouble with the second transmission after power-on, have a look that you’re NACKing at the end, otherwise the slave can get confused.Debugging Help
This whole business with ACK and NACK can get tricky, and it’s definitely one source of bugs. On the other hand, the acknowledge bit provides a bit of information (tee-hee!) about how the communication is going.Bus Pinging
The first thing to do when debugging an I2C system at the protocol level is to make sure that the slave device is there and listening. Since the slave is supposed to respond with an ACK after hearing its address on the data line, this can be used to scope it out. This should be your first stop in debugging an I2C setup: if the slave doesn’t even acknowledge its address, you’ve probably got wiring troubles.
Because there are only 127 possible addresses on a regular I2C bus, this can be generalized to check all the devices on the bus. An I2C bus scan simply goes through each address, and prints out which addresses lead to an ACK. This is a great check to verify that each device’s address is what you think it should be. A bus scan and verification probably belongs in the power-on self-test of any serious I2C system. Modern I2C chips also have a chip ID field that can be read out. Use ’em if you got ’em.Check ACKs
I’ll be the first to admit, I usually throw away the ACK bits when all is working well. When an I2C setup is behaving, it just wastes CPU cycles to test it with every byte. When things aren’t working, on the other hand, the ACKs are a treasure. Tracing through a non-working multi-byte communication by reading the ACKs lets you know when things went south.
If you’re using an AVR chip, have a look at the datasheet for their “two-wire interface” (which is I2C, but doesn’t infringe on Philips/NXT’s trademark name). The hardware I2C module has a status code for almost every step along the way, including testing for expected ACKs and more. I’m sure other chips do something similar. If you’re having troubles, check status codes after each byte and compare it with the signal diagrams in the device’s datasheet. You’ll get it straightened out.Odds and Ends
I2C, as described so far, is pretty complicated, with a lot of hoops to jump through and opportunities for bugs to creep in. It gets worse.Address Collisions
While it sounds cool to have an address space that’s able to accommodate up to 127 devices, the reality is that any I2C bus will probably only have a handful connected up. There are two reasons for this. The first is that each device added to the bus brings along a little parasitic capacitance. The second is that device addresses aren’t fully flexible, and they can even conflict across different ICs.Three Address Pins: Maxim’s LM75 Datasheet
To take the LM75 example again, all of the chips have a hard-coded base address of hexadecimal 0x48 when they come from the factory. They also have three pins that, when grounded or pulled up to the supply voltage, let one specify up to eight possible addresses by adding the binary value of the three lines to 0x48. This means that you can only have eight LM75s on your bus at a time. Period. Not 127.
And you can’t use different chips if their addresses overlap, either. NXP’s PCF8563 RTC chip has a read and write address, both of which conflict with two of the eight addresses selectable for a 24C32 EEPROM, for instance. Many years ago, Adafruit started keeping track of these addresses and making a master list. Unfortunately, it looks like they gave up a long time ago as well. You’re on your own to read the datasheets and avoid address collisions.
A possible solution to the addressing problem is extended 10-bit addressing, which was adopted as a standard in 1992, but I still don’t see all that many devices using it. (Maybe it’s me.) The scheme uses a fixed 5-bit prefix (0b11110) followed by two address bits and the read/write bit in the first byte, and then a second byte with the remaining eight bits of the address. 1,024 addresses should be enough for the entire universe of I2C devices, right?Multi-mastering and Clock Stretching
This is where things get really hairy. Because of the pull-down, float-up behavior of the I2C signal lines, it’s electrically possible for two devices to send opposite signals at the same time. (The low wins.) This, in principle, can be used to extend functionality in two different directions. If a device expects to be sending a high signal on either SCK or SDA, but the line is being pulled low by another device, something is afoot.Clock-Stretching
If a slave is pulling the clock down, it’s called “clock-stretching” and is a signal to the master to pause until the slave is ready. In principle, the master shouldn’t send until it notices the slave has released the line, and it floats back up. Of course this relies on the master checking for a low signal when it thinks it’s letting the line float high. If you’re using a reputable microcontroller’s I2C hardware, you’re probably in good shape — it will check the clock line. If you’re using some back-alley bit-banging I2C routines that won’t pause when requested, you’re going to lose data.
A more subtle problem can occur when the line simply stalls due to clock stretching. In principle, any slave device can stretch the clock by pulling it low, and they can do so for an indefinite amount of time, and the master must respect this and not send new data until the slave releases the clock line. This can wreak havoc with data on the bus that needs to get out on a schedule, in the best of cases. In the worst case, the entire bus can be effectively DOS’ed simply by pulling the clock line low.
Devices like EEPROMS or flash memories are notorious clock stretchers. They often write data in pages, and writing the data takes a finite amount of time. So they’ll take in 64 bytes (for instance) as fast as you can transfer them, but then they’ll stall when they hit a page boundary and need to write out. Watch out for these chips! Other EEPROMS have double buffers that essentially sidestep this problem, reading into one while they write out the other.Multi-master Arbitration
The I2C standard allows for multiple clock-masters to take turns on the bus. Ideally, every potential master is keeping track of start and stop signals. When the line is free, it can start its transmission. But what happens when two masters decide to start at once?
They “arbitrate”. If a master tests the line when it’s supposed to be high, and finds it to be low, it’s a sign that the line isn’t free after all. All devices that currently aren’t pulling the line down should stop their transmission. The idea is that before the address is finished, all the conflicting masters should have backed down. Needless to say, mixing devices that are and aren’t multi-master capable is a recipe for disaster.Solutions
Call me a coward if you will, but my solution to multi-mastering and clock-stretching issues is to avoid them. And that means using multiple I2C bus networks. By far the simplest way to do so is to buy a microcontroller that has more than one hardware I2C controller built in.
Adding a second I2C bus can also help isolate a rogue clock-stretcher that blocks other, time-critical, transmissions. Reserve one bus for the low-latency transmissions, and segregate the clock-stretchers to their own bus. Or if you’re running a mix of chips — some that only run at 100 kHz while others run at 400 kHz or higher — running a fast bus and slow bus will allow you to get the maximum speed out without confusing the slow ones. More busses means more flexibility.
But if you really need to go overboard and control a bazillion I2C devices with the same address on a single bus, the solution is an I2C multiplexer. These are special chips let you run, say, 16 devices with the same address from a single I2C port by selecting among them using some more lines from the CPU. This is a special situation, for special snowflakes.Troubleshooting Checklist
So as you can see, there’s a lot going on with I2C, and a lot to go wrong. I2C debugging does not compare with raindrops on roses or whiskers on kittens.
- Go make yourself a calming tea or other beverage before you start.
- Double-check wiring. Are SCK and SDA mixed up? Are voltage levels right/same?
- Are you running the bus at the right speed for the slowest slave? And are the pullups strong enough? Verify the speed and waveform shapes with a scope.
- Can you get the initial ACK from your target device? Do a bus scan.
- Still failing? Pull all but your target device off the bus and get the initial ACK working. Add other devices back on one by one. This helps find bus-hogs.
- Once you get the initial ACK working, use these to step through the rest of the transaction, verifying one byte at a time.
- Are you setting the read/write mode correctly for each transaction?
- Are all parties ACKing and NACKing when they should? Sometimes you’ll see a glitch between the master releasing the line and the slave asserting a NACK. This is normal, and actually a sign that all’s well.
- If you switch read/write directions, are you sending a restart and the address again? Does the device support this?
- Double-check address clashes in the datasheets. Scan the bus and make sure that you see the right number of devices.
- Are you multi-mastering the bus? Can you avoid doing so easily?
- If you need to troubleshoot a truly tricky problem, put different-value resistors on the output of all chips on the bus. The low voltage values will be slightly different for each chip, allowing you to see on a scope which chip is talking at any given time, and diagnose when they’re talking over each other.
Good luck with I2C! And let us all know in the comments if you’ve got any other specific troubles or solutions. We got some great responses for the other two articles.
Filed under: Hackaday Columns, Microcontrollers, Skills
The 2016 Hackaday SuperConference is coming. Now is the time to submit your proposal for a talk or a workshop at the world’s greatest conference about hardware creation. The SuperCon is an unparalleled opportunity to present on a deeply technical level where you can be certain everyone in the audience is following. All of those details, the war stories of production, the out-of-stock problems and board respins, the moments when you’ve bent physics to your will, these stories will be met with awe and cheers as the audience of your peers takes the ride along with you.
SuperCon will take place in Pasadena, California on November 5th and 6th, 2016. It is a gathering of hackers, designers, and engineers passionate about learning, teaching, and celebrating what goes into making new and exciting creations. The atmosphere will be that of a hacker village, with several venues in close proximity playing host to talks, workshops, and other activities. This breaks out of the beige prison that usually accompanies hotel-based conferences and opens the weekend up for you to meet and interact with a cadre of interesting people. SuperCon is the place to share your hard-won knowledge and experience, and to add to your own arsenal of skills.
Accepted talks will be scheduled for 20-40 minutes, and workshops will be booked for 1-4 hours. In both cases, topics may include themes like techniques for rapid prototyping, new and interesting uses of technology, creativity in technical design, and stories of product development and manufacturing.
Last year’s SuperConference was incredibly successful. If you weren’t able to attend you can still work your way through all of the talks which were recorded and posted shortly after the event. That success is a credit to all of the talented presenters in the Hackaday community who put together their stories to share for the benefit of all. Thank you!
To all of you reading this now and wondering if you should propose a talk, you should! We thank you in advance for taking time out of your life to make this year’s SuperConference even more amazing by submitting your own proposal. It won’t happen without you because this is a conference of active involvement and not one of passive consumption. Be the hardware movement; this is your chance.
Filed under: Featured
There are a few 32-bit ARM-based 3D printer controller boards out there such as the Smoothieboard, the Azteeg X5 mini, [Traumflug]’s Gen5 electronics, whatever board is in the Monoprice MP Mini Select, and several others I will be criticized for not mentioning. All of these ARM boards provide smoother acceleration, better control, and ultimately better prints from whatever 3D printer they’re controlling. Now, out of the blue, there’s a new board. It’s an evaluation board from ST — much like those famous Discovery boards — that sells itself as a plug and play solution for 3D printers.
The heart of this board is an STM32F401 — not the king of the STM32 line or the fastest ARM microcontroller, but anything faster or more capable will add considerably more to the BOM for this board. This controller board features six of ST’s L6474 motor drivers with enough current for some beefy NEMA 23 stepper motors , a multi-zone heated bed, and connections for a WiFi module and external LCD and keypad. You can buy this board right now for $118. This board isn’t a game changer, but it is evidence the game has been changed.
As with all 3D printer controller boards, there are a few aspects that will leave users wanting more. This is a board meant for 12V heaters (except for the bed, which has a 24V, 20A output), and the stepper drivers can only go up to 16 microsteps. That said, there’s not much else to complain about. This offering comes with a 32-bit firmware called Marlin4ST. From a quick perusal, it looks like the familiar configuration.h is still there, and still does what it’s supposed to do.
This ST Discovery board is extremely capable, available now, and relatively cheap, but that’s not really the big story here. What this board represents is a reference design and working firmware for a 32-bit ARM-based printer controller. That’s the future, and with this board the future might come a little sooner.
Thanks [jagerboots] for sending this one in.
Filed under: 3d Printer hacks, Hackaday Columns, slider
Do you dream of opening a hackerspace, makerspace, or co-working space? Maybe it’s in the works and you’re already scoping out locations, intoxicated by visions of all the projects that will emerge from it. Here’s a sobering thought: makerspaces are a great big pile of risk. If the doors of your ‘space are already open, perhaps you’ve come to realize that the initial insurance policy you signed doesn’t really fit the needs of your particular creative paradise. Even if it does, the protection you need will change as you acquire new toys.
So why should you even get insurance? For one thing, your landlord will probably require it. If you own the building, you should insure it to protect yourself and anyone who uses the space. Do it for the same reason you’d insure a car, your house, or your collection of vintage pinball machines: to mitigate risk. It takes a lot of hard work to open a makerspace, perform the day-to-day operations, and keep it growing and getting better. Whenever the unthinkable happens, insurance will protect your investment as well as the people who make it a great place to be.
In researching this article, I contacted several well-established makerspaces in the United States as well as most of the major insurance providers to get both sides of the story. My intent was not to make a how-to guide, but to simply explore the topic and provide a view of the process and the struggle.Why is it Hard to Get Insured?
Getting a space insured is not an easy undertaking. While the task itself is hard for makerspaces, the concept of a community workshop is a difficult one for insurers to fathom. Most of their business clients fall into one category or another, so it’s easy to start with a boilerplate policy and go from there. But makerspaces and hackerspaces tend to touch many categories—machine shop, wood shop, electronics lab, and so on, and every category presents its own set of risks.
Another sticking point: most makerspaces are non-profit organizations. Some insurers I spoke with simply don’t cover any non-profits at all. Something else that makes risk assessment difficult–makerspaces are technically a private group, except for one night each week when many of them open their doors to the public.
To further complicate the picture, this is a group that has both shared and private resources and is trying to keep the private resources safe from theft and misuse. Most of this group’s valuable resources are tools, many of which are heavy or sharp or operate at high temperatures. It’s pretty much wall-to-wall risk. It will probably be a bit difficult, but it is by no means impossible to get insured in a way that meets the needs of your makerspace as well as those of your landlord.The Insurance You Need to Have
Every landlord is going to require some type of insurance coverage. This should be spelled out in your lease. If it isn’t, find out what your landlord requires and get it in writing from them. Keep in mind that governmental requirements differ by state and throughout the world. Every makerspace’s needs will be different. If a space has salaried employees, many states will require workers’ compensation coverage. This covers work-related injuries and is designed to prevent lawsuits against employers.
A landlord will typically require general liability coverage. This covers all kinds of bodily injury from slip and fall accidents to severed digits. It also covers personal injury claims like invasion of privacy, libel, and slander. The landlord may also require property coverage to protect against theft, loss, or damages. Property coverage doesn’t include automobiles, so keep your Power Wheels racer and your Mad Max car safe or else insure them separately.The Insurance You Want to Have
You might want to consider additional types of property coverage depending on your location. A makerspace in California would probably benefit from earthquake insurance, and one in Kansas should consider tornado and/or hail coverage. If you’re along the Gulf Coast or Eastern seaboard, look into hurricane coverage. All of these cost extra, though it could be worth it someday.
No matter where you are in the world, buying insurance against equipment breakdown is a great idea. But beware of the fine print, because there are two types of coverage—replacement cost and market value. Let’s say you get a great price on an old used Bridgeport mill and get it all set up. It runs like a champ for a year and half and then fails spectacularly. Did you get replacement cost coverage? Great! You’ll get a big enough check to cover the cost of a brand new Bridgeport. If you chose market value coverage, your check will only be as much as the actual cash value of that beat-up machine and you’ll be stuck in a loop of buying used mills. Of course, a replacement cost policy will carry a higher premium. But choosing to insure equipment at market value is actually a negotiating point in your favor because the company won’t have to pay as much out whenever you make a claim.The Agent and the Broker
So how do you find an insurer? The last time you bought car insurance, you probably chose the company based on past experience, word of mouth, or maybe even the company’s advertising spokesthing. You reached out to them and were assigned an agent in your area to work with. Here’s the problem with getting insurance this way: your agent isn’t really on your side. Sure, they might send you a postcard on your birthday, but their loyalty lies with the insurance company.
This is not the ideal method of shopping for makerspace insurance. What a makerspace is asking an insurance company to cover has far more serious implications compared to more common business models. For instance, your local grocery store has slip and fall insurance, but it’s a little different. If you wipe out on a melted Popsicle in front of the frozen pizzas, you’re not likely to cut your hand on a circular saw on the way down or land in a pile of sharp CNC waste.
What you want is someone who works for you. Someone who will take all the documentation you can provide about your makerspace and play the insurance game on your behalf. You want what is known as a broker. When I asked Bucketworks in Milwaukee about their experience obtaining insurance, they pointed me towards their broker, John Toepfer from The Anderson Insurance Group. John was an insurance carrier underwriter before becoming a broker, so he understands exactly what information insurers are looking for when assessing risk. In fact, he has a special application prepared for makerspaces that gets to the heart of potential hazards.Be Transparent, Because They Will See Through You
So let’s say you found a broker to spare yourself the headache of finding a company that will even think about insuring a makerspace. Like I said, each space is different and has a special set of needs that depend on many factors like location and building construction.
Finding a broker is just the beginning of the journey. There is no off-the-shelf insurance model for makerspaces. The policy you sign will be custom-made from all the available information about the building and the intended activities within. The more knowledge you can drop on your broker, the better.
What does this knowledge include? Usually, a copy of the lease. This will ensure that you, your landlord, and your insurer are all on the same page. The size of the building is a factor as is the size of your membership ranks. You would do well to describe the intended goings-on in great detail and make a comprehensive list of all tools and equipment. Copies of instruction and service manuals for all your dangerous machinery go a long way toward assessing risk accurately.
Transparency is a good policy in general. The company is going to send an inspector at some point, so there is no point in trying to deceive them. Established makerspaces know the value of transparency. For instance, Dallas Makerspace has a wiki page devoted entirely to the subject of insurance. There’s even a log of their experience obtaining insurance and a few examples of the kinds of questions that were asked of them.How to Make Insurance More Affordable
The fewer people with access to dangerous equipment, the more affordable the insurance premium. If your makerspace rules explicitly state that no one under 12 can use the soldering irons, you’re mitigating risk and will be rewarded for that when the insurance company is calculating your premiums. Installing an alarm system and/or surveillance cameras could also get you a discounted rate.
Once you have coverage, one fairly obvious way to make it more affordable is to pass the cost on to the members. Makerspaces charge an average of $50 per month for individuals. Is that the right amount for your membership fee? Whatever fee model you settle on, the cost of the insurance premiums should be a factor.Don’t Be a Stranger
Your membership dues will probably include a chunk of money for new equipment. Once the board is voting on what to buy, keep the insurance company in mind. Dallas Makerspace got an auto lift last year and promptly found out the hard way that it wasn’t covered in their existing policy. After the insurance company found out about it, the owners paid an inflated rate until they were able to revisit their policy.Don’t Reinvent the Wheel
Still don’t know where to begin? Go ahead and stand on the shoulders of giants. Established makerspaces have worked out a lot of the general kinks of getting insured, and there’s no shame in asking them for advice or for the name of their broker. Some makerspaces go so far as to offer serious consultation sessions in exchange for legal tender. Learn everything you can from them and pay it forward.
If you’re building the first makerspace in your area, it might be more difficult to get started. You can save a lot of time and frustration by going to some place like a local machine shop or other high-risk industrial operation to ask for the name of their broker or insurance company.
Makerspace insurance is hard, but there are ways to make it easier. Plan out the space in advance, collect documentation as you go, and find a broker to play the insurance game for you.
Filed under: Business, Featured, Original Art
Our conscience almost prevented us from posting this one. Almost.
What do people all around the world want most? Free WiFi. And what inevitable force do they want to avoid most, just after death and taxes? Rick Astley. As a getting-started project with the ESP8266, Hackaday.io user [jaime] built a “free WiFi portal” that takes advantage of people’s deepest desires. Instead of delivering sweet, high-bandwidth connectivity, once you click through the onerous terms and conditions, it delivers you a looped GIF with background music.
And all of this on $4 worth of hardware, with firmware assembled in the cloud and easily available to anyone. We live in a truly frivolous glorious age.
Digging through our archives, we found a number of Rickroll posts that we’d rather forget, but this steam-powered record player bears a second look.
Filed under: wireless hacks
Pokemon Go inherits a certain vulnerability to GPS location spoofing from it’s predecessor Ingress, but also the progress that has been made in spoof detection. Since taking advantage of a game’s underlying mechanisms is part of the winner’s game, why not hook up your smartphone to Xcode and see if you can beat Niantic this time? [Dave Conroy] shows you how to play back waypoints and activate your Pokemon Go warp drive.
The hack (therefore the Monospace) is based on the developers toolkits on Android and iOS, and also the easiest way to get banned from the game. On an Android smartphone, you need to get one of the many GPS spoofing apps from the Play store, repeatedly tap About phone to activate the developer settings and select that app as GPS spoofing source there. As [Max] points out in the comments, you may also need to install the mock mock locations Xposed module, which requires a rooted device. In iOS, you can (probably) also install a spoofing app through Cydia, although the easiest way without jailbreak is creating a new iOS app in Xcode (or any iOS application you have at hand) and build it to the phone. While in debugging mode, you can then load a *.GPX-file, which is simply a text file containing GPS waypoints in the XML-based GPS Exchange Format:<gpx> <name>My waypoints</name> <wpt lat="34.143895" lon="-118.151556"> <name>SupplyFrame, Inc.</name> </wpt> </gpx>
You can also create timed routes:<gpx> <name>My tracks</name> <trk> <name>Some track</name> <trkseg> <trkpt lat="34.143657" lon="-118.152368"><time>2016-07-18T00:00:00Z</time></trkpt> <trkpt lat="34.144502" lon="-118.152368"><time>2016-07-18T00:01:00Z</time></trkpt> <trkpt lat="34.144490" lon="-118.150470"><time>2016-07-18T00:02:00Z</time></trkpt> <trkpt lat="34.143654" lon="-118.150455"><time>2016-07-18T00:03:00Z</time></trkpt> </trkseg> </trk> </gpx>
The file is loaded via Product -> Debug -> Simulate Location -> Add GPX file to project, as shown in the video. This makes the waypoints or tracks available from the Simulate Location menu. From there, you then can then teleport your phone to the defined locations, or take it for a walk along the tracking points.
While the video is more a tutorial on how to get banned from the game than anything else, we’re not here to judge you if you try it. In the contrary, we’d actually love to see an implementation that catches ’em all without falling over the various strings Niantic has put in place, effectively turning GPS spoofing into a game of its own. Check out the video below to see [Dave Conroy’s] approach.
Oh, and did we mention this is probably get you banned? Can’t stress this one enough.
Filed under: nintendo hacks
Electromagnetism is the most difficult thing teach. Why is electromagnetism hard to teach? Well, when you’re asking a ‘why’ question (obligatory Richard Feynman video)…
[Adam Smallcomb] might not be able to explain electromagnetism with perfect clarity, but he does have an idea to give students a hands-on feel for electrons and magnets. He’s building an Electromagnetic Teaching Aid that turns 30 gauge wire, springs, Lego, and bits of metal into a toolset for understanding magnets, solenoids, current, and magnetic fields.
The devices explained via [Adam]’s toolkit include a DC motor, stepper motor, speaker, solenoid, relay, transformer, microphone, and generator. That’s not to say [Adam] is building all these devices – a DC motor is just a generator in reverse, a relay is a solenoid with more electrical connections, and everything in this toolkit is basically just wire and magnets.
So far, [Adam] has a bunch of interesting applications for magnets, wire, and Lego including a DIY stepper motor and a nifty little tool that measures magnetic flux with a Hall effect sensor. Will it teach schoolkids electromagnetism? Very few things could, but at least this little toolkit will allow students to intuit electromagnetism a little better.The HackadayPrize2016 is Sponsored by:
Filed under: The Hackaday Prize
3D printers are celebrated for their capacity to replace missing or broken parts. How about an entire T-62 tank?
Now hold on a second — this is only a model replica. It is, however another expression of the myriad uses for 3D printers. Designed in Maya and requiring almost three weeks to print all 62 parts from about 70 meters of PLA filament. The assembly is not terribly involved, made easier by printing a few large sections such as the crew section and hull while the parts don’t get much smaller than the turret hatches. Nonetheless, he final product is about as true to life as you can get when designing the parts from scratch.
The model for the tank is available for purchase here in STL format.
Model trains, ships, figures and so on have literally thousands of different offerings for the hobbyist, but for those with particular interests or taste, 3D printers — combined with some skill in a modeling program — will fill your niche. And, if you have some serious inspiration, how about a remote-controlled spider tank from Ghost in the Shell?
[via Yurii, of Gambody]
Filed under: 3d Printer hacks, toy hacks
One of [CNLohr]’s bigger claims to fame is his process for making glass PCBs. They’re pretty much identical to regular, fiberglass-based PCBs, but [CNLohr] is building circuits on microscope slides. We’ve seen him build a glass PCB LED clock and a Linux Minecraft Ethernet thing, but until now, [CNLohr]’s process of building these glass PCBs hasn’t been covered in the depth required to duplicate these projects.
This last weekend, [CNLohr] put together a series of videos on how he turns tiny pieces of glass into functional circuits.
At the highest level of understanding, [CNLohr]’s glass PCBs really aren’t any different from traditional homebrew PCBs made on copper clad board. There’s a substrate, and a film of copper that is etched away to produce traces and circuits. The devil is in the details, and there are a lot of details for this build. Let’s dig deeper.
To bond the copper to the glass slide, [CNLohr] first preps the materials by degreasing with acetone, and rubbing the copper with steel wool. The glue is Loctite 3301, a low-viscosity light-curing glue that can be squeegeed between the copper and glass, then exposed with a grow lamp.
That’s enough to get the copper on the glass, but several steps away from a circuit board. To etch the copper, [CNLohr] is using Riston film photoresist. This is applied by floating it onto the copper with a few drops of water and putting it through a laminator. The laser printer photomask is floated onto the Riston with some 3-in-one oil, the photoetch exposed, and then removed.
The next few steps – washing off the uncured photoetch, etching the copper, and washing off the cured photoetch – are the parts of this process that have given [CNLohr] the hardest time. He needs to use chemicals that don’t interact with the bond between the glass and copper. He’s found sodium carbonate works well for removing uncured photomask, ferric chloride for etching copper (although we’ve had good experience with cupric chloride and peroxide), and potassium hydroxide to remove the cured photomask. With the cured photomask removed, [CNLohr] has a perfect glass circuit board.
Of course, building a glass PCB is useless without soldering components to it. For that, [CNLohr] is using bismuth solder paste for low-temp hot plate soldering. If you’re only doing single-sided SMD work, this is a great way to produce beautiful circuit boards made of glass, but now we’re wondering if a small enough diamond drill bit would allow for double-sided construction.
Filed under: how-to
There are hundreds of ARM-based Linux development boards out there, with new ones appearing every week. The bulk of these ARM boards are mostly unsupported, and in the worst case they don’t work at all. There’s a reason the Raspberry Pi is the best-selling tiny ARM computer, and it isn’t because it’s the fastest or most capable. The Raspberry Pi got to where it is today because of a huge amount of work from devs around the globe.
Try as they might, the newcomer fabricators of these other ARM boards can’t easily glom onto the popularity of the Pi. Doing so would require a Broadcom chipset. Now that the Broadcom BCM2835-based ODROID-W has gone out of production because Broadcom refused to sell the chips, the Raspberry Pi ecosystem has been completely closed.
Things may be changing. ArduCAM has introduced a tiny Raspberry Pi compatible module based on Broadcom’s BCM2835 chipset, the same chip found in the original Raspberry Pis A, B, B+ and Zero. This module is tiny – just under an inch square – and compatible with all of the supported software that makes the Raspberry Pi so irresistible.
Although this Raspberry Pi-compatible board is not finalized, the specs are what you would expect from what is essentially a Raspberry Pi Zero cut down to a square inch board. The CPU is listed as, “Broadcom BCM2835 ARM11 Processor @ 700 MHz (or 1GHz?)” – yes, even the spec sheet doesn’t know how fast the CPU is running – and RAM is either 256 or 512MB of LPDDR2.
There isn’t space on the board for a 2×20 pin header, but a sufficient number of GPIOs are broken out to make this board useful. You will fin a micro-SD card slot, twin micro-USB ports, connectors for power and composite video, as well as the Pi Camera connector. This board is basically the same size as the Pi Camera board, making the idea of a very tiny Linux-backed imaging systems tantalizingly close to being a reality.
It must be noted that this board is not for sale yet, and if Broadcom takes offense to the project, it may never be. That’s exactly what happened with the ODROID-W, and if ArduCAM can’t secure a supply of chips from Broadcom, this project will never see the light of day.
Filed under: ARM, news, Raspberry Pi
Pokemon Go has done a great service to the world health. Or would’ve done, if we wouldn’t hack it all the time. The game suggests, you breed Pokemon eggs by walking them around, but [DannyMcMurray] has a better idea: Strapping your smartphone to the propeller of a fan and taking them for spin that way.
He shows how he built a Pokemon incubator using just a rubber band and a fan. This little trick saves you from physically leaving the house, but the process is still painstakingly slow: The time-lapse spin in the video results in about 0.01 km of progress, 0.5 % of the required 2 km. You need to spin your phone for over two hours until the little fellow hatches.
That said, we’re still left scratching our heads. Pokemon Go depends heavily on GPS. Why would the egg incubator not be constrained to this as well. If you have the answer, or have tried this and can confirm that it works, we want to hear from you in the comments below.
Need an assist for better PokeBall throws? Check out this papercraft guide rail that works every time.
Filed under: Cellphone Hacks, nintendo hacks
All these fifty years of conscious brooding have brought me no nearer to the answer to the question, ‘What are light quanta?’ Nowadays every Tom, Dick and Harry thinks he knows it, but he is mistaken.
Albert Einstein, 1954
As 1926 was coming to a close, the physics world lauded Erwin Schrodinger and his wave mechanics. Schrodinger’s purely mathematical tool was being used to probe the internal structure of the atom and to provide predictable experimental outcomes. However, some deep questions still remained – primarily with the idea of discontinuous movements of the electron within a hydrogen atom. Niels Bohr, champion of and chief spokesperson for quantum theory, had developed a model of the atom that explained spectral lines. This model required an electron to move to a higher energy level when absorbing a photon, and releasing a photon when it moved to a lower energy level. The point of contention is how the electron was moving. This quantum jumping, as Bohr called it was said to be instantaneous. And this did not sit well with classical minded physicists, including Schrodinger.Source: Eureka Physics
At this point in time, Erwin Schrodinger favored the idea of ‘wave packets’, and that matter was simply a concentration of these packets. This allowed for a clearer picture of wave/particle duality. Schrodinger understood that there were many holes in this idea, but he believed they would be worked out over time. In August of 1926, he would meet up with Bohr and a man by the name of Werner Heisenberg in a debate that would send the understanding of quantum theory in a new direction.
Schrodinger would have nothing to do with this “damned quantum jumping” as he would later recall. His classical wave theory had continuity and was easy to visualize. But Bohr and Heisenberg held steadfast in their philosophical view that it was not possible to visualize such quantum phenomenon. The debate raged on, and neither side was able to convince the other. However, all three were moved by the debate…most notably Werner Heisenberg. He had long given up on classical space-time visualizations within the atom and instead relied on theory and results of laboratory experiments. But Schrodinger had forced him to step back and try to visualize at least some atomic aspects. And this would lead him to one of quantum physics’ most important discoveries.Uncertainty
After the debate, Heisenberg began to ponder the path of an electron through a cloud chamber. This was an obvious way to visualize the position and momentum of an electron. Why could he not visualize such a path of the electron orbiting a hydrogen atom? After exchanging some correspondence with Wolfgang Pauli, he realized that he could reinterpret the square of the electron’s wave function. Instead of giving the probability of being in a specific state, this reinterpretation would give a probability of being in a particular location in the orbit of the atom. Doing so allowed Heisenberg to take Schrodinger’s wave mechanics and his insistence on being able to visualize the innards of atoms and apply his beloved matrix mechanics.
It was Pauli that would make the first connection between the position and momentum of the electron with wave mechanics. Viewing two electron waves on a collision path, one would find that each had a clear position (q) and momentum (p) while they are far apart. But as they come closer together, these values get ‘fuzzy’. He would write:
One may view the world with the p-eye and one may view it with the q-eye, but if one opens both eyes at the same time one becomes crazy.
Heisenberg took Pauli’s work and tried to describe the visible path of an electron in a cloud chamber. He would wrestle with this for a while before he began to ask himself some fundamental questions about what is meant by position. He realized that the position of the electron was only known because of the water droplets that condensed around its path. These droplets are much larger than the electron itself. While one might see the path readily by looking at the entire chamber, what happens when you zoom in? He realized that the position and momentum of the electron could not be known with infinite precision at the same time. Only an approximation could be measured. Heisenberg had discovered the uncertainty principle.A Fundamental Limit of Measurement
After doing some quick math, Heisenberg found that the product of the uncertainties of an electron’s position and momentum could not be smaller than Planck’s constant. There is a fundamental limit to how accurately you can know the electron’s position and momentum. He illustrated his new findings with a few thought experiments, including the following:Source: ChemWiki
Imagine we’re following the electron through our cloud chamber with a high powered microscope, and we wish to measure its position and velocity. The resolution of the microscope will increase with the frequency of radiation. So it would be most prudent to measure the position of the electron with a high frequency gamma ray. The problem is the gamma ray photon will affect the electron’s trajectory, which limits our ability to measure its velocity. The solution is to use lower energy radiation, so that the electron’s trajectory will not be affected by the photon. But lower energy means lower frequency. And because resolution is determined by the frequency, it limits our ability to measure its position. Which brings us back to where we started.
Heisenberg would go on to show that it is fundamentally impossible to observe (or visualize, for that matter) an electron in the orbit of an atom, and that he and Bohr were right all along. His uncertainty principle and its fundamental limitation on measurement would go on to shape quantum theory for the next several decades. It would later be applied to the concepts of energy and time, allowing “virtual” particles to blink in and out of existence, using uncertainty to escape conservation laws. This would become the basis of QED, or quantum electrodynamics.Author’s Opinion
I’ve read several books about Quantum Theory and even performed some basic experiments. While I will not pretend to understand even a fraction of the rigorous mathematics behind the theory, I can confidently state that anyone with an interest and desire to learn most of the basic aspects of the theory can do so.
One of my gripes with these books is that they tend to start off in Chapter 01 with explaining the concept of wave/particle duality, known as complementarity. This is utterly baffling to anyone new to the theory. How can something that looks like little baseballs be the same thing as what one sees when they toss a pebble into a pond? I would argue that they should first teach the uncertainty principle and focus on the idea of limitation of measurement. It’s not confusing, but fairly straight forward and anyone can grasp the idea without much effort. Once one understands that the location of a moving “tiny baseball” can only be known with a probability less than 100%, it becomes much easier to visualize wave/particle duality. The particle is there and real, just like a little baseball. But because of uncertainty in measurement, it is impossible to actually know it’s there1. We are forced to say that there is a probability it is here, and a probability it is over there. This probability is spread out in the form of a wave. This is why tiny particles display wave-like characteristics when you try to observe (or measure) them. You end up only seeing or measuring this wave of probability, because that’s all that you can see or measure.
So by understanding the above, looking at wave/particle duality is much easier, in my opinion. Understanding uncertainty in measurement is the key to all of the quantum weirdness.
1The question of if a quantum scale object can be considered actually ‘there’, even if it is impossible to know if it’s ‘there’ is a hotly debated subject that continues to this day. Albert Einstein refused to give up causality and held on to his belief that the universe is deterministic in nature (that means the object is really there even though we can’t measure it). While Niels Bohr and Werner Heisenberg pushed the idea that if you can’t measure and know that the object is there, to say that it is there is nonsensical. They believed that on the quantum scale, things like causality and determinism simply cannot exist. I will climb out on a yagi and say that modern quantum mechanics and experiments suggest that Einstein was wrong. It would appear that the quantum tree does not make a sound if no one is there to hear it.
The Quantum Story, by Jim Baggott. Chapters 9 &10 ISBN-978-0199566846
Filed under: Engineering, Hackaday Columns
We live in a time of unparalleled access to technology and this has the power to make life better for everyone. Today we are excited to announce twenty spectacular builds that use access to technology to move scientific exploration within the reach of all. These are the winners of the Citizen Scientist challenge of the 2016 Hackaday Prize. Themes tackled in this round include blood glucose monitoring, insole sensing for analyzing your footfalls, lab equipment like automated microscopy, sensors to measure the world around us, and more.
The winners for the Citizen Scientist portion of the Hackaday Prize are, in no particular order:
- Open Source Arduino Blood Glucose Meter Shield
- CODE RED
- Neuroscience of Grasshopper Jumps
- Flypi – Cheap Microscope/Experimental Setup
- Alli-GAIT-or Analysis
- Internet Of Things Microscope
- PULSE : Profiling Underwater Light SEnsor
- Affordable Reflectance Transformation Imaging Drone
- Universal Glucometer
- Robot Missions
- CierzScience Tunnel
- Open Indirect Ophthalmoscope
- BluBEAM – A Scanning Laser Microscope
- Automatic Digital Microscope
- Arduino, EEG, and Free Will
The Hackaday Prize is the greatest hardware competition on earth. We want to see the next great Open Hardware project benefit everyone. We’re working toward that by recognizing people who build, make, and design the coolest and most useful devices around.
These twenty projects just won $1000 and will now move on to the final phase of The Hackaday Prize, to be judged by our fourteen celebrity judges. Awesome! Now get to work: there’s a lot the hackers behind these projects need to do before the final judging in October where they’ll compete for the grand prize of $150,000 and four other top prizes.
If your project didn’t make the cut, there’s still an opportunity for you to build the next great piece of hardware for The Hackaday Prize. The Automation Challenge is currently under way. It encourages everyone to build devices that make your life easier.
Automate your life; build a device that makes your breakfast, a robot to mow your lawn, or software that does your taxes. Build a device that automatically tracks laundry detergent, automates washing the dishes, or a robot that obeys every command.
Like the Design Your Concept, Anything Goes, and Citizen Science rounds of The Hackaday Prize, the top twenty projects will each win $1000, and move on to the Hackaday Prize finals for a chance to win $150,000 and a residency at the Supplyframe DesignLab in Pasadena.
If you don’t have a project up on Hackaday.io, you can start one right now and submit it to The Hackaday Prize. If you’re already working on the next great piece of hardware design, add it to the Automation challenge using the dropdown menu on the sidebar of your project page.The HackadayPrize2016 is Sponsored by:
Filed under: Hackaday Columns, The Hackaday Prize
3D Printering: the final frontier. These are the voyages of another 3D printer hack. Its mission: to explore strange new ways of leveling a print bed.
So far, we’ve had servo probes, Allen key probes, Z-sled probes, inductive and capacitive contactless switches, just to name a few. All of them allow a 3D printer to probe its print bed, calculate a correction plane or mesh, and compensate for its own inherent, time variant, inaccuracies.Build plate with conductive pads by Zortrax
These sensors are typically mounted somewhere on the print head and introduce their own sensor offset, which has to be precisely calibrated for the whole thing to work. To eliminate these offsets – and a large part of costly EOL testing and calibration – the Polish 3D printer manufacturer Zortrax uses a smarter approach: Conductive pads on the build plate. During the leveling procedure, the printing nozzle makes contact with these pads, which practically turns the nozzle itself into the probe — offset-free. Makerbot patented a contact sensing solution based on force sensors located in the print head, although similar builds based on limit switches were known before. Other DIY builds use force sensitive resistors (FSR) underneath the build plate to achieve the same. All these techniques are based on the detection of a brief contact between the printing nozzle and the build plate, and are therefore offset-free.
Compelled by the idea of eliminating the last manual calibration step, I wanted to make Zortrax’s method of contact sensing compatible with non-conductive PEI, Garolite and glass build plates. I didn’t want to interfere with the Makerbot patent, and force sensitive resistors would not survive the temperatures of a heated bed. I figured that I could just strap a sufficiently heat resistant piezo sensor to the print bed to sense the little knock the nozzle would make when it collides with the print bed. However, not much sound energy is released when a nozzle runs into a build plate at blazing 1 mm/s. A first test revealed that the knocking sound was too weak to be reliably distinguished from other vibrations in the machine.Visaton EX 45s structure-borne sound exciter (image source)
To fix this, I acquired a 10 W structure-borne sound exciter and attached it to the extruder. The exciter allowed me to actively inject a white noise signal into the nozzle. If it was strong enough, this signal would travel through the entire printer and could be picked up by the piezo discs in the print bed, far above the printer’s own noise level. I assumed, that when the nozzle touches the print bed, the transfer function between the exciter and the piezo sensor must change rapidly due to the direct transfer of sound between the two. This change would then lead to a rapid change in the amplitude spectrum the piezo picks up. A little DSP could process the piezo signal, detect these rapid changes in the amplitude spectrum and give back a trigger signal to indicate the collision.
For the required realtime DSP, I hooked up the piezo discs to a plain Teensy Audio Shield equipped with a Teensy 3.1, which practically completed the hardware portion of this project in one step. Using Paul Stoffregen’s amazing DSP library, it took only a few lines of code to run a 256 point FFT on the input signal and a few more to generate a time-averaged amplitude spectrum. The little sketch compares this averaged “frequency fingerprint” of commonly present vibrations to the current spectrum, calculates an overall energy difference between the two, and if that difference exceeds a certain threshold, the Teensy pulls an output pin low, telling the 3D printer controller that the nozzle just touched the build plate. I later added an OLED display and rotary encoder, basically for plotting the signals and for being able to adjust the threshold.
This turned out to work quite well, while submersing the whole printer in a pleasant swoosh noise, but it added quite a bit of additional weight the extruder assembly. Also, these exciters aren’t particularly cheap, and an additional audio amp would be required, too. It wasn’t really it.
It took a while for me to figure out what I would do with the whole project. And then, just when I was about to send it into project-limbo, I had another idea: To save cost and weight, I could use the extruder’s stepper motor as the exciter, the stepper motor driver as the amplifier, and stick with the cheap piezo discs attached to the print bed as microphones. In theory, the 3D printer controller could both generate the noise signal and process the sound signal from the piezos, so the only additional component would be the preamp and the piezo discs.“Extruder, you’re a speaker now.” – “K, boss.”
Yet, it was still unclear if the stepper motor would adapt to become some sort of speaker, so that’s the first thing that needed testing. I hacked together a little noise injector board that would go between the 3D printer controller and the stepper driver. This little hack utilizes an Arduino Pro Mini clone to switch between two modes: A bypass-mode, where it just passes through the signals from the 3D printer controller, and a noise mode, where it streams a pseudo-random sequence of forward and backward micro steps to the motor driver. This, I hoped, would cause the stepper motor to oscillate and produce a noise signal. And well, it did. I turned it on and the extruder motor swooshed with a strong noise, very similar to the exciter I used before, although the extruder’s gears rattled quite a bit.Noise injector with Pololu DRV8825 driver (right), plain Pololu DRV8825 driver (left)
I tweaked the random sequence to make sure that the stepper motor would never perform an actual full step as a random accumulation of micro steps. Besides that, everything worked surprisingly well. The probing is accurate to a level where it becomes really hard to tell how accurate it actually is. If the nozzle touches down to a sheet of paper and stops once it senses the touch, the paper will slide easily and consistently between the nozzle and the build plate without being stuck. Since then I’ve been using this for several prints, and it works just like regular auto bed leveling probes, although with fewer advantages than expected: It eliminates the offset calibration, but also introduces a threshold value for the touch detection.
From an economical view, this is still a nightmare. On current Arduino-style 3D printer platforms, it takes an additional DSP, DAC, a preamp and the noise injection adaptor to implement this sort of sonic auto bed leveling. Even if the piezo discs are virtually free, everything adds up to about 5 times the cost of a decent capacitive distance switch.
It might make more sense in the not so distant future. We’re beginning to see a new generation of 3D printer controllers that feature a more powerful 32 bit MCU, ideally we want one that supports DSP instructions. Given the availability of cheap STM Nucleo boards with powerful, DSP-enabled ARM Cortex-M4 MCUs, my bet is that insanely powerful 3D printer controller electronics, capable of tricks like this one, are bound to happen rather soon. For now, enjoy the following video of an early test of the sonic auto bed leveling:
Filed under: 3d Printer hacks, Curated, Engineering, Featured, slider
$32 billion USD doesn’t buy as much as it used to. Unless you convert it into British Pounds, battered by the UK’s decision to leave the European Union, and make an offer for ARM Holdings. In that case, it will buy you our favorite fabless chip-design company.
The company putting up 32 Really Big Ones is Japan’s SoftBank, a diversified technology conglomerate. SoftBank is most visible as a mobile phone operator in Japan, but their business strategy lately has been latching on to emerging technology and making very good investments. (With the notable exception of purchasing the US’s Sprint Telecom, which they say is turning around.) Recently, they’ve focused on wireless and IoT. And now, they’re going to buy ARM.
We suspect that this won’t mean much for ARM in the long term. SoftBank isn’t a semiconductor firm, they just want a piece of the action. With the Japanese economy relatively stagnant, a strong Yen and a weak Pound, ARM became a bargain. (SoftBank said in a press release that the Brexit didn’t affect their decision, and that they would have bought ARM anyway. Still, you can’t blame them for waiting until after the vote, and the fallout, to make the purchase.) It certainly won’t hurt SoftBank’s robotics, IoT, or AI strategies to have a leading processor design firm in their stable, but we predict business as usual for those of us way downstream in the ARM ecosystem.
Thanks [Jaromir] for the tip!
Filed under: Microcontrollers, news