One of the problems with the Internet of Things, or any embedded device, is how to get power. Batteries are better than ever and circuits are low power. But you still have to eventually replace or recharge a battery. Not everything can plug into a wall, and fuel cells need consumables.
University of Washington researchers are turning to a harvesting approach. Their open source WISP board has a sensor and a CPU that draws power from an RFID reader. To save power during communication, the device backscatters incoming radio waves, which means it doesn’t consume a lot of its own power during transmissions.
The big news is that TU Delft has contributed code to allow WISP to reprogram wirelessly. You can see a video about the innovation below. The source code is on GitHub. Previously, a WISP had to connect to a PC to receive a new software load.
The physical world is analog and if we want to interface with it using a digital device there are conversions that need to be made. To do this we use an Analog to Digital Converter (ADC) for translating real world analog quantities into digital values. But we can’t just dump any analog signal into the input of an ADC, we need this analog signal to be a measurable voltage that’s clean and conditioned. Meaning we’ve removed all the noise and converted the measured value into a usable voltage.
Things That Just Work.
This is not new information, least of all to Hackaday readers. The important bit is that we rely on these systems daily and they need to work as advertised. A simple example are the headlights in my car that I turned on the first night I got in it 5 years ago and haven’t turned off since. This is not a daytime running lights system, the controller turns the lights on when it’s dark and leaves them off during the day. This application falls into the category of things that go largely unnoticed because simply put: They. Work. Every. Time. It’s not a jaw dropping example but it’s a well implemented use of an analog to digital conversion that’s practical and reliable.
Scientific research, especially in the area of robotics, often leverages cutting-edge technology. Labs filled with the latest measurement and fabrication gear are unleashed on the really tough problems, like how to simulate the exquisite sensing abilities of human skin. One lab doing work in this area has taken a different approach, though, by building multi-functional sensors arrays from paper.
A group from the King Abdullah University of Science and Technology in Saudi Arabia, led by [Muhammad M. Hussain], has published a fascinating paper that’s a tour de force of getting a lot done with nothing. Common household items, like Post-It notes, kitchen sponges, tissue paper, and tin foil, are used to form the basis of what they call “paper skin”. Fabrication techniques – scissors and tape – are ridiculously simple and accessible to anyone who made it through kindergarten.
They do turn to a Circuit Scribe pen for some of their sensors, but even this nod to high technology is well within their stated goal of making it possible for anyone to fabricate sensors at home. The paper goes into great detail about how the sensors are made, how they interact, and how they are interfaced. It’s worth a read to see what you can accomplish with scraps.
An embedded MEMS sensor might be lots of fun to play with on your first foray into the embedded world–why not deploy a whole network of them? Alas, the problem with communicating with a series of identical sensors becomes increasingly complicated as we start needing to handle the details of signal integrity and the communication protocols to handle all that data. Fortunately, [Artem], [Hsin-Liu], and [Joseph] at MIT Media Labs have made sensor deployment as easy as unraveling a strip of tape from your toolkit. They’ve developed SensorTape, an unrollable, deployable network of interconnected IMU and proximity sensors packaged in a familiar form factor of a roll of masking tape.
Possibly the most interesting technical challenge in a string of connected sensor nodes is picking a protocol that will deliver appreciable data rates with low latency. For that task the folks at MIT Media labs picked a combination of I²C and peer-to-peer serial. I²C accomodates the majority of transmissions from master to tape-node slave, but addresses are assigned dynamically over serial via inter-microcontroller communication. The net effect is a fast transfer rate of 100 KHz via I²C with a protocol initialization sequence that accommodates chains of various lengths–up to 128 units long! The full details behind the protocol are in their paper [PDF].
With a system as reconfigurable as SensorTape, new possibilities unfold with a solid framework for deploying sensors and aggregating the data. Have a look at their video after the break to get a sense of some of the use-cases that they’ve uncovered. Beyond their discoveries, there are certainly plenty others. What happens when we spin them up in the dryer, lay them under our car or on the ceiling? These were questions we may never have dreamed up because the tools just didn’t exist! Our props are out to SensorTape for giving us a tool to explore a world of sensor arrays without having to trip over ourselves in the implementation details.
I keep up with the trends in 3D printing reasonably well. The other day my friend mentioned that filament thickness sensing had been added to the latest version of the Marlin firmware. I had no idea what it was, but it certainly sounded cool. I had to find out more.
In industrial settings, filament is made by pulling extruding molten plastic at a certain speed into a cooling bath. The nozzle for 2.85mm filament and 1.75 mm filament is actually the same size, but the filament is stretched more or less as it leaves the nozzle. By balancing these three variables the extrusion machine can produce any size filament desired. Like any mechanical system, it needs constant adjustment to maintain that balance. This is usually done by measuring the filament with a laser after it has cooled, and then feeding this information back into the system. The better filament manufacturers have multiple lasers and very fast feedback loops. Some of the best offer +-0.04mm or less variation in thickness between any two points on the filament. Some of the worst have larger errors such as +-.10mm. Because the plastic is fed into the extruder at a fixed linear speed, this makes a variation in the volume of the plastic coming out of the nozzle per second. With the best we see a 4.41% variation in the volume of plastic extruded. With the worst we start to see 10.51% or more.
A printer is dumb. It works under the assumption that it is getting absolutely perfect filament. So when it gets 10.51% more plastic, it simply pushes it out and continues with its life. However, if the filament is off enough, this can actually show up as a visible defect on the print. Or in worse cases, cause the print to fail by over or under extrusion of plastic.
So, what does a filament thickness sensor do to correct this issue? To start to understand, we need to look at how the filament is dealt with by the software. When the slicer is compiling the G-code for a 3D print, it calculates the volume of plastic it needs in order to deposit a bead of plastic of a certain width and of a certain height per mm of movement. That was a mouthful. For example, when a printer printing 0.2mm layers moves 1mm it wants to put down a volume that’s 1.0mm long x 0.4mm wide x 0.2mm high. The filament being pushed into the nozzle has a volume per mm determined by the diameter of the filament.
The volume out per mm of filament in.
The equation we are trying to balance.
Our goal is to integrate the thickness sensor into these functions to see what the thickness sensor is doing. This is a linear equation, so there’s nothing fancy here. Now, the layer height, layer width, and length of the move are determined by settings and model geometry respectively. These are fixed numbers so we don’t care about them. That leaves us the diameter of the filament and the length of filament extruded. As we mentioned before, typically the filament is assumed to be a fixed diameter. So all the software has to calculate is the length of filament that needs to be extruded per mm of combined movement in the x and y so that our volumes match.
But, we know that one of these variables is actually changing per millimeter as well. The filament diameter! So now we have a problem. If the filament diameter is changing all the time, our equation will never balance! In order to fix this we can add a multiplier to our equation. Since we have no control over the width of the filament we can’t modify that value. However, if we know the width of the filament, and we know the value its supposed to be, we can change the length of the filament extruded. This is because unlike the filament, we have control over the stepper motor that drives the extruder. This value is called the extrusion multiplier, and its determination is what the thickness sensor is all about.
So all the filament sensor does is measure the filament’s current diameter. It takes expected diameter and divides it by the value it just measured to get a simple percentage. It feeds that number back into our system as the extruder multiplier and slows or speeds up the stepper motor as needed. Pretty simple.
The ideal filament the printer thinks it is seeing.
The printer is unable to compensate for the variations.
By adjusting with the extrusion multiplier the printer is able to approximate perfect filament.
There are a few thickness sensors being toyed with right now. The first, as far as I can tell; let me know if I am wrong in the comments, was by [flipper] on thingiverse. He is in his third version now. The sensor works by casting a shadow of the filament as it passes by onto an optical sensor. The firmware then counts the pixels and works backwards to get the diameter. This value is sent to the Marlin firmware on the printer which does the rest. As is usual and wonderful in the open source community, it wasn’t long before others started working on the problem too. [inoranate] improved on the idea by casting more shadows on the sensor. The technique is still brand new, but it will be interesting to see what benefits it reaps.
Now comes the next question,”Is it worth upgrading my printer with a thickness sensor?” If you typically run poor filament, or if you extrude your own, yes. The current sensors can only measure +- .02mm. So for the best filament, you won’t really see a difference, but for worse stuff, you might. The latest firmware of the Lyman filament extruder, for making your own filament, also supports these sensors, letting you feed back into your production system like the industrial machines. All in all a very interesting development in the world of 3D printers.
RFID tags are really very primitive pieces of technology. Yes, they harvest energy from an RFID reader and are able to communicate a few bits of data, but for a long time these tags have been unable to provide useful data beyond a simple ID number. [CaptMcAllister] found a new RFID sensor platform from TI and managed to make a wireless pressure sensor that fits in the inner tube of his bike.
The sensor [Capt] is using comes from TI’s RF430 series that include a few neat sensors that don’t require batteries, but are still able to communicate sensor data to a cell phone or other RFID reader. With a pressure sensor, this tiny microcontroller can receive power from an RFID reader and send it back to a phone app, all without wires.
[CaptMcAllister] cut open an inner tube for his bike, epoxied his PCB to a patch, and sealed everything back up again. After a quick test for leaks, [Capt] found the data coming from the sensor was extraordinarily accurate, and should hold up well enough to be used in his bike.
The video below shows the mystery circuit (which is just the stock iCEstick board), which appears to react any time you flex the PC board. The Verilog implements a simple ring oscillator (basically an inverter with its output tied to its input).