I’m filing this one under useful tricks. If you’ve got a password field the browser has saved and you can’t recall the text (and you’re too lazy to check the browser password save dialogue), fire up Firebug and press inspect. Target the password field and click. It will pull the HTML up into the screen. Click on type=”password” and change password to “text”. This should display the password in plaintext.
I’ve had the Solenoid project working for about a week and a half now, but the rain and lack of sunlight was getting in the way of making a video of everything in action. It worked out well because it gave me the chance to demonstrate the project to a number of visitors today, all at once. And, as the photo above demonstrates, the project passes the kid test.
The project is still in need of refinement, but I’m thinking that’s where things would get expensive. I’ve sourced out some new solenoids that could be used in a multimedia environment, I’m just unsure of the cost. The solenoids I have used are $7 washing machine parts. Specialty valves are bound to be more expensive. Some of the valves leak, and I’m pretty sure it’s not occurring in the sections I’ve sealed, the valves may be defective, or they may have a scratch in the plastic I created when I was reconfiguring the orientation of the connectors.
The brace you can see in the photo on the left was constructed to correctly position the hoses in sequence. the centre photo demonstrates the digital radio, Arduino, and transistor controller. The green wires leading out of frame are wired to the Solenoids. On the right, the solenoids are hooked up to the hoses. (All the photos have notes visible in Flickr)
In the above video, I’ve got the device filled with water, and directed through flexible hoses. Valves 2, 4, 6, 7, and 1 turn on. They then cycle off, leaving valve 1 open. The camera then pans up to the controller where it zooms in on the LEDs which I’m using as indicators of which valves are turned on. We then go through a test of all the valves on and off to demonstrate the flow when everything is open. A couple of the valves don’t work, and I’ve traced that back to a point on the controller circuit that I think has not been soldered correctly.
I think it would be important to note the projects out there that are doing the same thing. The Jeep waterfall was unveiled at a Detroit autoshow in 2000. This waterfall was published on the Make blog just the other day. MIT’s building made of water is scheduled to open at the 2008 Expo, they’ve hired Lumiartecnia to produce the valves. Also check out this water keyboard for its innovative use of sensing electric resistance when you touch the water to control the solenoids — in this case controlling air flow in a liquid. All these examples show that the envelope can be pushed that much further, and that there’s a large degree of possible variatons.
Still lots more ideas to play with, but many of these will be with the code. I’ve got some really interesting image processing ideas coming up.
My brother, Neil has been playing with an Arduino too. Here’s his latest script for controlling 3DS Max via Arduino:
This Solenoid controller has been filled with a ton of small successes. Today I’m chalking up one more success to the list. I’ve got the XBee portion of the controller working. I had been working on this for a long time now, and the more I work on it the more I see the potential in this platform.
XBee Solenoid Controller from Eightlines on Vimeo.
The issues I had getting the XBee to work appear to be common based on the message board threads I have seen:
If you can’t explain it simply, you don’t understand it.
— Albert Einstein
The big issue I was having with the Solenoids was too much pressure. So while on a trip to Sudbury my Stepfather and I redesigned it. Well, I just told him what I was thinking of doing, and he came up with a much simpler way of doing it.
It’s a good thing too, because I’ve easily broke the budget on this project! So this design uses a cap from a sewage pipe, and some garden hose adaptors. No soldering required. The pressure in the system is regulated by the height of the pipe and how much water is pumped in. When the solenoids are open and the water is draining a plunger falls, triggering an aquarium pump to refill the container. It stops when the plunger rises past a certain point.
Yes, this thing is now an electronically controlled toilet.
Off to buy some more parts, wire up the XBee controller, and waterproof the remote breadboard.
So the guys at the electronics stores are loving me lately. I’m pretty good at destroying things. While electronics is a reasonably affordable hobby, I’ve managed to turn it into something a little more extreme. So without further adieu, here’s my “listo destructo”:
One of the guys at work said I probably shouldn’t put a price list on this. I have to agree, it would hurt too much. Oh and this is by no means a complete list, I intend to update as I keep making stupid mistakes.
TED is always an excellent source of inspiration. Arthur Ganson has one of the more magical demonstrations I have ever seen. What a fabulous body of work!
Sometimes its worth venturing out to a disorganized surplus store to see what you can find. This is my latest little toy.
Its a fragment of a pixelboard. Alternate the currents from one pin to the other and you can make the yellow dots flip to black. The cool thing is even powerless it keeps its state. If you manually flip the pixel to the other side it returns based on the magnetic pull.
The guys at the store obtained it from a signage company that was dumping their old stock for TV screens. The destroyed all of the control boards because it was proprietary technology (just a couple relays I’m thinking). The larger versions of these pixelboards also come with LEDs to illuminate the structure.
In the photo above I’ve hooked the pixelboard up to an IR Rangefinder so it could light up based on distance of an object infront of the sensor.
One of the devices I’m most excited about lately is the MaxStream XBee. The problem with this seemingly innocuous little device is that it wouldn’t behave the way any other tutorial I found said it would. I’ve been working through three different sources of information on the XBee. The first was the source was the always helpful Arduino Forum. Then there’s the excellent article on the Arduino Playground by M. Yarza — though this would have been more helpful initially had I spotted the next page links at the bottom of each page. The third resource is this fantastic book put out by O’Reilly called Making Things Talk. (I’d hazard to think that most people getting involved with the Arduino and XBee will be coming into it from this book and Make magazine)
The first issue I had was working out how to configure the XBee module. The Arduino serial interface doesn’t appear to like to send characters as they’re typed, and requires a line break before it executes. This proves to be an issue with the Command Mode in the XBee. The workaround is to move into a terminal application that does support direct TTY. On a Windows machine PuTTY should do the trick, or Screen on the Mac OS. I’m using a Mac, but the PC should be a matter of pointing the terminal at the COM port associated with the USB-Serial adaptor that you’re using. On a Mac you’d point this at /dev/tty.usbserial[identifier].
The Arduino can act as a USB-Serial adapter if you like. Just remove the ATMega168 chip and communicate directly through the TX/RX ports.
To execute Screen type:
screen /dev/tty.usbserial-A4001uBD 9600
Replace the usbserial name with the one that is present on your system. The name should only appear when the USB device is plugged in, otherwise you won’t see anything. The connection speed of 9600 baud is the default connection speed of the XBee radio. If you’ve altered this, call your new baud rate here.
Once you’re in type in:
+++
This enters command mode. Here you can get or set the XBee parameters:
ATID returns 1111.
ATID1234 sets the ID for the XBee to 1234. It should return nothing.
ATID will now return 1234.
ATWR writes these values to the XBee.
ATCN exits command mode if it hasn’t automatically done so by timeout (~10s).
The configuration options go on from there, and they get increasingly complex.
Hopefully that helps others in a simillar situation I found myself in. Soon I’ll post a follow up detailing my setup.
Playing around with the Xbee has led to a number of really interesting thoughts and ideas. Part of me is thinking that some of these ideas are far more interesting than the Solenoid project I’m currently working on. I have to keep reminding myself that I should really finish one thing before starting the next.
I’m still wrapping my head around the Xbee and what it does, and I can tell you what it doesn’t. Its not a bluetooth adapter (you might be looking for a BlueSMiRF radio instead). It operates on the 802.15.4 Zigbee protocol. Essentially it sets up a mesh network.
The node points for the Xbee OEM modules are 30m in radio frequency (RF) or 100m line of sight. The Xbee Pro’s go to 100m RF, and 300m line of sight. Where it gets interesting is the Xbee Pro-XSC at a range of 24 km in RF.
The modules are capable of being configured as a peer to peer, one-to-many, or many-to-many. They can hibernate, just broadcast or receive, and more. The spec sheet is quite impressive. If you send a message from one node, it could repeat till it finds its destination in the network. Imagine this on a scale of ~20 km node points.
Lets say we build a telemetry device and outfit it on a vehicle. That device could consist of a couple sensors, say a Hall Effect sensor typical in bicycle computers and ABMs on cars, and a compass module (I’ll explain my reasoning behind this over a GPS later). Other possibilities could include a heart rate monitor, air quality sensors, battery power. I’d love to integrate my heart rate monitor into the mix. A USB stick could connect to the Arduino (I’m loving the new Nano form factor) and act as a data-logger. Finally a localized Xbee controller would sit dormant on the device. As the vehicle moves an onboard timer records the data to a timestamped string:
20080519 20:55:59,4.5204,30
These fields would translate back to “Date/Time, Radians, RPM”. Over specified intervals new data would be recorded and stored locally. When the device comes within range of a broadcast node it would awake out of hibernation and deliver the data into the mesh network. A receiver station collects the data from the mesh and sends a confirmation signal. The broadcaster deletes the store of data and starts over, sending the local Xbee into hibernation mode again.
The data is then processed by the receiving station, plotted onto a mapping API, cross-referenced against other broadcasting modules, etc.
I’m going to play devil’s advocate on myself here:
Why a compass module over a GPS? Would that not deliver more accurate data? From what I’ve read, a compass module should provide a far lower drain on the power supply. It would also operate in situations where no sky visibility is provided. The form factor is much smaller, and no antenna would be required. The disadvantage is you need to know the precise starting point (found via GPS no less), and mounting considerations would apply.
The interesting thing is that I have all of the components working in isolation. Its just the small matter of getting everything to play as a team. Then moving it out into the field for some real world tests. Right now these are just some thoughts, but I can’t explain how exciting this little device is.
