Walk into any home improvement store, and you’ll find dozens of smart accessories, home automation equipment, and WiFi-connected ephemera. The Belkin WeMo Insight is one of these devices, giving anyone with and a WiFi network the ability to switch lights and appliances on and off over a network. [John] picked up one of these WiFi plugs, but it didn’t work exactly as he would like. Instead of building a smart plug from scratch, [John] replaced the controller board for a WeMo Insight for his Hackaday Prize entry, making it far more useful and a replacement for devices like the Kill-a-Watt.
In its stock form, the WeMo can only be used though the smartphone app provided by Belkin or through a few third-party services like IFFT. All of these solutions have a limited API, and don’t provide advanced power metrics. To solve this problem, [John] replaced the smart controller board inside the Belkin WeMo with one of their own design.
By volume, most of the electronics inside the WeMo are a transformer, caps, and a relay; the smarts of this smart plug are just a daughterboard. By re-engineering this daughterboard with a new microcontroller, an ESP8266, and a microSD card connector, [John] can replicate the functionality of the WeMo while adding some new features. SD card datalogging for up to four years is now possible, a RTC now provides precise time stamps on all data collected, and a few simple calculations on the microcontroller enable power factor, line frequency, and total energy metering. With the ESP, all this data can be sent up to the cloud with a vastly improved API.
It’s a great project, and something that Belkin should seriously consider for their next revision of the WeMo. For anyone stuck with a stock WeMo, [John] has made all his design files and code available, allowing anyone to replicate this build
You can check out [John]’s Hackaday Prize entry video below.
The 2015 Hackaday Prize is sponsored by:
Filed under: The Hackaday Prize
Sometimes, a good hack is about using less rather than more. That’s the case with this neat tutorial from [Rahul.S] on driving a 7-segment LED display with an FT232. By using this cheap USB to serial controller, [Rahul.S] was able to drive the display directly without using a microcontroller, which keeps the component cost down.
He’s bit banging an octal buffer connected to the display. You may be surprised to find that the FT232 chips do have enough outputs to make this work. Rather than send serial data number to the display and have a controller convert this into a set of signals that make the number, this conversion is done by the PC, which then sends a signal that directly illuminates the appropriate parts of the LED. By using all of the available output lines of the FT232 (including ones like the RTS/CTS line that are usually used for signalling), [Rahul.S] was able to drive all seven of the elements and the decimal point.
Of course, cynics may argue that it would be simpler to use a cheap serial LCD display. That is true, but there is always something to be said for knowing how to do something yourself rather than letting others do it for you…
Filed under: hardware
We are suckers for a teardown video here at Hackaday: few things are more fascinating than watching an expensive piece of equipment get torn apart. [Jonas Pfeil] is going the other way, though: he has just published an interesting video of one of his Panono panoramic ball cameras being built.
The Panono is a rather cool take on the panoramic camera: it is a ball-shaped device fitted with 36 individual cameras. When you press the button and throw the camera in the air, it waits until the highest point and then takes pictures from all of the cameras. Sound familiar? We first coverd [Jonas’] work way back in 2011.
Photos are stitched together into a single panoramic image with an equivalent resolution of up to 106 megapixels. The final image is panoramic in both horizontal and vertical directions: you can scroll up, down, left, right or in and out of the image. Since images are all taken at the same time you don’t have continuity problems associated with moving a single camera sensor. There are a number of sample images on their site but keep reading for a look at some of the updated hardware since our last look at this fascinating camera.
Unsurprisingly, the device itself is pretty complex: I counted two rather crowded looking circuit boards and at least three smaller daughterboards that the cameras and USB port connect to, plus a whole rats nest of ribbon cables. This is the first commercial version (they are making and selling just a thousand of them, called the explorer edition), but it looks a little inefficient: I thought it might be possible to connect some of the cameras directly to the edge of the circuit board to lose a few of the cables. I asked [Jonas] about that, and he said:
The orientations of the camera modules are important and not two are the same. So at most we could mount three of 36 on the 3 mainboards in the center plane of the sphere. Orientation of the camera modules calls for their PCB to be tangential to the sphere surface. So basically you have to fold something. I’m sure there are other ways but this is the solution we came up with. We spent a good deal of time on that folding pattern and the shapes of the flexible boards Also for something made to hit the floor at this speed you have to decouple things mechanically or it will decouple itself on impact 😉
So, can anyone come up with a better idea for attaching the cameras to simplify this complex build?
Filed under: digital cameras hacks, teardown
We have some great apps for you today that are discounted for a short duration in the App Store, including Strategery, Where To Go? PRO and others. Some deals may expire quickly — even on the same day of this post. If there is a discounted app that you like, grab it while it is still on sale.
iPhone Hacks | #1 iPhone, iPad, iOS Blog
Getting into FPGA design isn’t a monolithic experience. You have to figure out a toolchain, learn how to think in hardware during the design, and translate that into working Verliog. The end goal is getting your work onto an actual piece of hardware, and that’s what this post is all about.
In the previous pair of installments in this series, you built a simple Verilog demonstration consisting of an adder and a few flip flop-based circuits. The simulations work, so now it is time to put the design into a real FPGA and see if it works in the real world. The FPGA board we’ll use is the Lattice iCEstick, an inexpensive () board that fits into a USB socket.
Like most vendors, Lattice lets you download free tools that will work with the iCEstick. I had planned to use them. I didn’t. If you don’t want to hear me rant about the tools, feel free to skip down to the next heading.
Hiccups with Lattice’s Toolchain
Still here? I’m not one of these guys that hates to sign up for accounts. So signing up for a Lattice account didn’t bother me the way it does some people. What did bother me is that I never got the e-mail confirmation and was unable to get to a screen to ask it to resend it. Strike one.
I had tried on the weekend and a few days later I got a note from Lattice saying they knew I’d tried to sign up and they had a problem so I’d have to sign up again. I did, and it worked like I expected. Not convenient, but I know everyone has problems from time to time. If only that were the end of the story.
I was impressed that Lattice does support Linux. I downloaded what appeared to be a tgz file. I say appeared because tar would not touch it. I examined the file and it looked like it was gzipped, so I managed to unzip it to a bare file with a tar extension. There was one problem: the file wasn’t a tar file, it was an executable. Strike two. I made it executable (yes, I’m daring) and I ran it. Sure enough, the Lattice installer came up.
Of course, the installer wants a license key, and that’s another trip to the Web site to share your network card’s MAC address with them. At least it did send me the key back fairly quickly. The install went without incident. Good sign, right?
I went to fire up the new software. It can’t find my network card. A little Internet searching revealed the software will only look for the eth0 card. I don’t have an eth0 card, but I do have an eth3 card. Not good enough. I really hated to redo my udev rules to force an eth0 into the system, so instead I created a fake network card, gave it a MAC and had to go get another license. Strike 3.
I decided to keep soldiering (as opposed to soldering) on. The tool itself wasn’t too bad, although it is really just a simple workflow wrapper around some other tools. I loaded their example Verilog and tried to download it. Oh. The software doesn’t download to the FPGA. That’s another piece of software you have to get from their web site. Does it support Linux? Yes, but it is packaged in an RPM file. Strike 4. Granted, I can manually unpack an RPM or use alien to get a deb file that might work. Of course, that’s assuming it was really an RPM file. Instead, I decided to stop and do what I should have done to start with: use the iCEStorm open source tools.
TL;DR: It was so hard to download, install, and license the tool under Linux that I gave up.
Programming an FPGA Step-by-Step
Whatever tools you use, the workflow for any FPGA is basically the same, although details of the specific tools may vary. Sometimes the names vary a bit, too. Although you write code in Verilog, the FPGA has different blocks (not all vendors call them blocks) that have certain functions and methods they can connect. Not all blocks have to be the same either. For example, some FPGAs have blocks that are essentially look up tables. Suppose you have a look up table with one bit of output and 16 rows. That table could generate any combinatorial logic with 4 inputs and one output. Other blocks on the same FPGA might be set up to be used as memory, DSP calculations, or even clock generation.
Some FPGAs use cells based on multiplexers instead of look up tables, and most combine some combinatorial logic with a configurable flip flop of some kind. The good news is that unless you are trying to squeeze every bit of performance out of an FPGA, you probably don’t care about any of this. You write Verilog and the tools create a bitstream that you download into the FPGA or a configuration device (more on that in a minute).
The general steps to any FPGA development (assuming you’ve already written the Verilog) are:
- Synthesize – convert Verilog into a simplified logic circuit
- Map – Identify parts of the synthesized design and map them to the blocks inside the FPGA
- Place – Allocate specific blocks inside the FPGA for the design
- Route – Make the connections between blocks required to form the circuits
- Configure – Send the bitstream to either the FPGA or a configuration device
The place and route step is usually done as one step, because it is like autorouting a PC board. The router may have to move things around to get an efficient routing. Advanced FPGA designers may give hints to the different tools, but for most simple projects, the tools do fine.
Constraints For Hardware Connected to Specific Pins (or: How does it know where the LED is?)
There is one other important point about placing. Did you wonder how the Verilog ports like LED1 would get mapped to the right pins on the FPGA? The place and route step can do that, but it requires you to constrain it. Depending on your tools, there may be many kinds of constraints possible, but the one we are interested in is a way to force the place and route step to put an I/O pin in a certain place. Without that constraint it will randomly assign the I/O, and that won’t work for a ready made PCB like the iCEStick.
For the tools we’ll use, you put your constraints in a PCF file. I made a PCF file that defines all the useful pins on the iCEstick (not many, as many of you noted in earlier comments) and it is available on Github. Until recently, the tools would throw an error if you had something in the PCF file that did not appear in your Verilog. I asked for a change, and got it, but I haven’t updated the PCF file yet. So for now, everything is commented out except the lines you use.
Here’s a few lines from the constraint file:
set_io LED3 97 # red set_io LED4 96 # red set_io LED5 95 # green
Every external pin (including the clock) you plan to use must be defined in the constraint file. Errors in the file can be bad too. Routing an output to a pin that is connected, for example, directly to ground could damage the FPGA, so be careful! The picture to the right shows the configuration with my PCF file (the center LED and the one closest to the FPGA chip just blink and are not marked in the picture). Keep in mind, though, you could reroute signals any way that suited you. That is, just because LED1 in the Verilog is mapped to D1 on the board, doesn’t mean you couldn’t change your mind and route it to one of the pins on the PMOD connector instead. The name wouldn’t change, just the pin number in the PCF file.
Configuring an FPGA
Different FPGAs use different technology bases and that may affect how you program them. But it all starts with a bitstream (just a fancy name for a binary configuration file). For example, some devices have what amounts to nonvolatile memory and you program the chip like you might program an Arduino. Usually, the devices are reprogrammable, but sometimes they aren’t. Besides being simpler, devices with their own memory usually start up faster.
However, many FPGAs use a RAM-like memory structure. That means on each power cycle, something has to load the bitstream into the FPGA. This takes a little time. During development it is common to just load the FPGA directly using, for example, JTAG. However, for deployment a microprocessor or a serial EEPROM may feed the device (the FPGA usually has a special provision for reading the EEPROM).
The FPGA on the iCEstick is a bit odd. It is RAM-based. That means its look up tables and interconnections are lost when you power down. The chip can read an SPI configuration EEPROM or it can be an SPI slave. However, the chip also has a Non Volatile Configuration Memory (NVCM) inside. This serves the same purpose as an external EEPROM but it is only programmable once. Unless you want to dedicate your iCEstick to a single well-tested program, you don’t want to use the NVCM.
The USB interface on the board allows you to program the configuration memory on the iCEstick, so, again, you don’t really care about these details unless you plan to try to build the device into something. But it is still good to understand the workflow: Verilog ? bitstream ? configuration EEPROM ? FPGA.
Since I was frustrated with the official tools, I downloaded the IceStorm tools and the related software. In particular, the tools you need are:
- Yosys – Synthesizes Verilog
- Arachne-pnr – Place and Route
- Icestorm – Several tools to actually work with bitstreams, including downloading to the board; also provides the database Arachne-pnr needs to understand the chip
You should follow the instructions on the IceStorm page to install things. I found some of the tools in my repositories, but they were not new enough, so save time and just do the steps to build the latest copies.
There are four command lines you’ll need to program your design into the iCEstick. I’m assuming you have the file demo.v and you’ve changed the simulation-only numbers back to the proper numbers (we talked about this last time). The arachne-pnr tool generates an ASCII bitstream so there’s an extra step to convert it to a binary bitstream. Here are the four steps:
yosys -p "synth_ice40 -blif demo.blif" demo.v
- Place and route:
arachne-pnr -d 1k -p icestick.pcf demo.blif -o demo.txt
- Convert to binary:
icepack demo.txt demo.bin
- Configure on-board EEPROM:
Simple, right? You do need the icestick.pcf constraint file. All of the files, including the constraint file, the demo.v file, and a script that automates these four steps are on Github. To use the script just enter:
This will do all the same steps using demo.v, demo.txt, and so on.
Try It Out
Once the board programs, it will immediately start operating. Remember, this isn’t a program. Once the circuitry is configured it will start doing what you meant it to do (if you are lucky, of course). In the picture below (and the video), you can see my board going through the paces. I have some buttons for the two adder inputs on one side and a reset button on the other. I also soldered some headers to the edge of the board.
If you are lazy, you can just use a switch or a jumper wire to connect the input pins to 3.3V or ground. It looks like the device pins will normally be low if you don’t connect anything to them (but I wouldn’t count on that in a real project). However, I did notice that without a resistor to pull them down (or a switch that positively connected to ground) there was a bit of delay as the pin’s voltage drooped. So in the picture, you’ll see I put the switches to +3.3V and some pull down resistors to ground. The value shouldn’t be critical and I just grabbed some 680 ohm resistors from a nearby breadboard, but that’s way overkill. A 10K would have been smarter and even higher would probably work.
If it works, congratulations! You’ve configured an FPGA using Verilog. There’s still a lot of details to learn, and certainly this is one of the simplest designs ever. However, sometimes just taking that first step into a new technology is the hardest and you’ve already got that behind you.
Although you can do just about anything with an FPGA, it isn’t always the best choice for a given project. Development tends to be harder than microcontroller development (duplicating this project on an Arduino would be trivial, for example). Also, most FPGAs are pretty power hungry (although the one we used is quite low power compared to some). Where FPGAs excel is when you need lots of parallel logic executing at once instead of the serial processing inherent in a CPU.
FPGAs get used a lot in digital signal processing and other number crunching (like Bitcoin mining) because being able to do many tasks all at once is attractive in those applications. Of course, it is possible to build an entire CPU out of an FPGA, and I personally enjoy exploring unusual CPU architectures with FPGAs.
Then again, just because you can make a radio with an IC doesn’t mean there isn’t some entertainment and educational value to building a radio with transistors, tubes, or even a galena crystal. So if you want to make your next robot use an FPGA instead of a CPU, don’t let me talk you out of it.
Filed under: Featured, FPGA
Nepal | 25 April 2015 | 11:56 NST
It was a typical day for the 27 million residents of Nepal – a small south Asian country nestled between China and India. Men and women went about their usual routine as they would any other day. Children ran about happily on school playgrounds while their parents earned a living in one of the country’s many industries. None of them could foresee the incredible destruction that would soon strike with no warning. The 7.8 magnitude earthquake shook the country at its core. 9,000 people died that day. How many didn’t have to?
History is riddled with earthquakes and their staggering death tolls. Because many are killed by collapsing infrastructure, even a 60 second warning could save many thousands of lives. Why can’t we do this? Or a better question – why aren’t we doing this? Meet [Micheal Doody], a Reproductive Endocrinologist with a doctorate in physical biochemistry. While he doesn’t exactly have the background needed to pioneer a novel approach to predict earthquakes, he’s off to a good start.
He uses piezoelectric pressure sensors at the heart of the device, but they’re far from the most interesting parts. Three steel balls, each weighing four pounds, are suspended from a central vertical post. Magnets are used to balance the balls 120 degrees apart from each other. They exert a lateral force on the piezo sensors, allowing for any movement of the vertical post to be detected. An Arduino and some amplifiers are used to look at the piezo sensors.
The system is not meant to measure actual vibration data. Instead it looks at the noise floor and uses statistical analysis to see any changes in the background noise. Network several of these sensors along a fault line, and you have yourself a low cost system that could see an earthquake coming, potentially saving thousands of lives.
[Michael] has a TON of data on his project page. Though he’s obviously very skilled, he is not an EE or software guy. He could use some help with the signal analysis and other parts. If you would like to lend a hand and help make this world a better place, please get in touch with him.
He makes a great point during his narration in this video: earthquakes disproportionately affect the poor because they live and work in lower-cost structures unlikely to be outfitted to withstand earthquakes. Shoring up infrastructure is a huge and costly undertaking. Discovering early warning systems like the one [Michael] is testing here will have an immediate and wide-ranging impact at a minimum cost.
Filed under: Hackaday Columns
As far back as we can remember, there have always been hacks, exploits, and just curiosity about undocumented CPU instructions. The Z80 had them. Even the HP41C calculator had some undocumented codes. The HCF (Halt and Catch Fire) instruction was apocryphal, but we always heard the old video controller chips could be coaxed into blowing up certain monitors. You don’t hear too much about things like that lately, perhaps because fewer people are working in assembly language.
[Sergi Àlvarez i Capilla] not only works in assembly language, he was writing an ARM assembler when he noticed something funny. Instructions are built in a regular pattern and some of the patterns were missing. What to do? [Sergi] lost no time trying them out.
His result? He found at least one instruction that causes a Raspberry Pi to lock up dead. All by itself, that’s not a big deal, but the instruction isn’t protected so any user program could potentially lock up a Pi. A reset will set things right, of course. No combustion occurs. The newer models, by the way, seem to be immune and [Sergi] tested some phones and other devices with ARM processors to no effect.
The practical implications? Probably not much? But if you were putting a Pi in a critical system, you might find this result interesting. Maybe the best defense against this kind of hack is only having one instruction to start with. The 6502, by the way, was well known for having a large number of useful undocumented op codes. There’s some talk about that in the video below (the undocumented part starts around 6:00).
Filed under: ARM, Raspberry Pi
A couple of old DVD ROM drives and a compact photo printer is fairly standard fare at the thrift store, but what do you do with them? Hack them up to make a CNC foam cutter of course!
[Jonah] started with a couple LITE-ON brand DVD RW drives, which use stepper motors instead of plain old DC motors. This is a huge score since steppers make accurate positioning possible. With the internal frames removed, threaded rod and nuts were used to hold the two units parallel to each other forming the Z axis.
The feed mechanism from a Canon compact photo printer was then bolted onto the bottom to form the Y axis. Add a bit of nichrome wire for the cutting element (this can be found in old hair dryers) onto where the laser assembly of the DVD rom once lived, and you have the mechanics done.
Control is handled by an Arduino and some easy-driver modules to interface with the steppers. G-Code is generated by CamBam, which handles various cad files, or has its own geometry editor.
This is a fantastic way to get your feet wet in several ways; Cracking things open to harvest parts, driving steppers with simple micocontrollers, modeling and generating g-code, etc. The one issue we see with this build is a chicken-or-egg problem since you need to have a cube of foam cut down to somewhat strict dimensions before it will fit in this cutter. But we suppose that is really just an iterative design problem.
Filed under: Arduino Hacks, cnc hacks, tool hacks
The original steganography technique dates back to 440 BC (according to Wikipedia) when a Greek wrote secret messages on a piece of wood, covered it in wax, and then wrote innocent text on the wax. The term, in general, means hiding a message in something that looks harmless. The LVDO project (and a recent Windows fork) says it is steganography, but we aren’t quite sure it meets the definition. What it does is converts data into a video that you can transfer like any other video. A receiver that knows what LVDO parameters you used to create the video can extract the data (although, apparently, the reproduction is not always completely error-free).
The reason we aren’t sure if this really counts as steganography is that–judging from the example YouTube video (which is not encoded)–the output video looks like snow. It uses a discrete cosine transform to produce patterns. If you are the secret police, you might not know what the message says, but you certainly know it must be something. We’d be more interested in something that encodes data in funny cat videos, for example.
The idea is not completely new. Backing up computers on VCR tape was very popular in Russia, although it never caught on in the US (despite a few products that did it, including one for the Amiga). In case you were wondering, yes, we’ve talked about hiding data using kittens before, too.
If you want to see what an encoded video looks like, here’s one. We didn’t decode it (we don’t have the keys) but if you do and you wind up being rickrolled, don’t blame us.
Filed under: security hacks, video hacks
Apple has stopped signing iOS 8.4 firmware file, less than two weeks after releasing iOS 8.4.1. This means that users won’t be able to downgrade from iOS 8.4.1 to iOS 8.4.
iPhone Hacks | #1 iPhone, iPad, iOS Blog