Need cheap wireless sensor help!
I’m doing a project that requires me to attach 24 different wireless accelerometers to 24 different people, get unique acceleration data from each, and I need to keep the cost of each wireless sensor to below $50 a pop. I have seen a bunch of good options such as the WiTilt at Sparkfun, but the cost is too high. I also looked into rigging an Arduino with a Bluetooth shield and accelerometer, but again, the cost is a little too high. The best option I have seen so far was buying a bunch of nike+ sensors, which are cheap, but they only give impact data, not acceleration or motion.
Does anyone know a good option for doing this?
For inexpensive distributed wireless sensor networks, it’s hard to do better than XBee in my experience. They are typically used for serial communication, paired with a microcontroller, but they also have built-in ADC if you use them in API mode.
Sounds good, but wouldn’t I need to attach it to a microcontroller in order to read and then transmit the accelerometer data? doing all that would drive the price up way above the $50 dollar ceiling. I looked into using the wiimote, but it is too big for the application we need.
any experience in rewiring a wiimote motion sensor?
As I mentioned previously, they also have an onboard ADC, so they can be used without a microcontroller, assuming you have a 3.3V sensor. You just have to do some configuration in API mode. It’s more complicated this way on the software side, but it’s cheaper.
@Andrew do you have any links that would further explain how to utilize the XBee sensors/transmitters? Am always looking for low-cost alternatives to the wireless controllers out there, which for now definitely cost too much. Also, assuming the API mode can be figured out relatively easily, how many ADC inputs does it have?
For the microcontroller part, if you want to utilize one, you could look into TI’s new baby:
Probably as cheap as something like that will get for the next decade… though I’m not sure how to interface it to the XBee, would that be simple or need some serious fiddling?
When I was puzzling through it, I relied heavily on Rob Faludi’s info here:
You will need to have one xbee radio connected to the computer via serial adapter and set up to transmit the values it receives from the other ones. The one word of caution here is that if you aren’t comfortable reading datasheets and parsing serial data, it might be a big pain to do this way. In the long run, if you are comfortable with microcontrollers, the most robust solution might be to write a simple ADC->UART firmware for one of the inexpensive Atmel chips like ATTiny26, which features an 11-channel ADC and doesn’t require much support circuitry besides power. Most modern microcontrollers include serial output pins, but programming them won’t be quite as simple as Arduino programming. Frankly, for all of this stuff, you pay for inexpensive solutions with your time and research, so it’s always important to factor that in as well.
Just an idea : Ask to your 24 people to bring their ipod touch/iphone, or to borrow it from a friend just for the performance (with the free Fantastick app installed on each one).
I think that getting their accelerometers data thru 24 differents udp ports should be possible. (I just tried with 3 ipod touch, it was working)
Otherwise, an ipod touch v1 with a broken glass should cost less than $50 in second hand, but may be hard to find.
@Alexandre I thought of this, but the problem is that in my case the iphones would be too cumbersome for what we need.
heh, have u find what you want :-? http://www.amazon.co.uk/Nyko-Wireless-Sensor-Bar-Wii/dp/B000LFJNG6 may be you should take a look here :D
Here’s some more possibilities
So I’ve been trying to build something similar to this, though price isn’t so big a deal.
The idea is to build two accel/gyro driven wrist bands that would get attached to the wrists of a painter.
The main requirements are:
I was originally thinking adapting a wiimote but they are kind of big/bulky. So I’ve been looking into piecing something together like this:
That would handle all the sensor requirements, but then I still have wireless, controller, and power to deal with.
I was originally thinking bluetooth as it’s easy enough to use, but this Xbee stuff seems cheap/easy, particularly if I can use that and no Arduino.
So if I understand correctly, for an Xbee setup, you need one to send the data, and one hooked up to the computer to receive the data? (or is it regular wireless signal that a macbook can pickup?).
In reading that the Xbee can do ADC on it’s own, and has 7 analog inputs. I take it that would be enough to read the 6 analog outputs of the accel/gyro linked above?
In short, if I’m understanding right I can use something like the sensorboard linked above (or any analog out IMU) and an Xbee antenna, with another Xbee connected to the computer and call it a day?
I’ve got on an external for making XBee easy to use in Max, it’s an mxj wrapper for Andrew Rapp’s Java XBee api. It’s nearly done now, you can see it working here http://registeringdomainnamesismorefunthandoingrealwork.com/blogs/?p=421
BTW I would recommend series 1 XBees over Series 2, apparently they have lower latency and support more XBee’s connected to a single coordinator. I have ten Series 2 ones all controlling Live through max4live and they seem OK.
Xbee series 1 meaning older ones?
I read on this blog that you need newer firmware to be able to do this stuff with the Xbee:
So in those boxes you just have an Xbee, and the circuitry needed to drive the LEDs/knob/switch with no Arduino/controller?
They have Arduinos, I’m not doing direct sampling of the encoder, the Arduino handles writing out the display data. Digi reccommend the Series 1 over the Series 2 for low latency applications where mesh networking isn’t necessary, tbh I’m not noticing much latency but I haven’t done proper tests. I think it’s jitter that’s supposed to be the real problem, when you use the full zigbee protocol as the Series 2 do then there’s no guarantee of when packets will arive. I have mine set up as a single coordinator and ten end devices (star configuration) and it seems fine, but I have no Series 1′s to compare with and I’m not shelling out the £120 it would cost me to test it!
As for firmware you just flash the latest version on to them using the XCTU program (windoze only).
Forgive my ignorance on this in general, but for an Xbee setup you need one in the device to broadcast, and one at the computer, to receive?
So you used a full fledged setup with arduino and all with the Xbee external just making it easier for Max to read the info?
Is it then possible to just have an Xbee, a sensor, and a battery, as a device?
In looking around some more I realized that it might be easiest to just gut a Wiimote Plus and break it down to its bare boards to use that way, as they are way cheap and there are externals setup for them already.
Has anyone gutted a wiimote plus and/or run it on thinner li-ion battery packs? I have a wiimote around that I wouldn’t mind destroying, but I would imagine the wiimote plus is different internally.
Loads of people gut wii motes for precisely that reason. However it is possible to have just XBee, accelerometer and battery and I’ve seen it working really well. My understanding is the wiimotes are blue tooth so you’ll be limited to four simultaneous (I think, you’ll need to check) XBee you can get more sensors in your network. It’s horses for courses.
That makes sense.
I only need two connections so wiimotes should work fine.
I found there’s a smaller wiimote called a minimote. So I ordered one and plan on gutted that down to its board and gutting a wii motion plus and wiring them up directly to make it as slim as possible. I’m planning on, wether wise or not, to try removing the top third of the wiimote board (with the Dpad and infrared) to slim it even more. That would probably get the whole thing down to near the size of an xbee(with breakout board) and sensor.
How friendly/unfriendly is dealing with xbee data in max (as compared to the aka.wiimote object)?
XBee data in max can be simple if you’re using AT mode, then they’re basically like wireless serial ports chucking out whatever they’re being sent at your sensor end. In API mode the packets are bigger and parsing potentially becomes an issue. Hopefully my external will make it easier.
I use at present the sensor of a nunchuk which I opened and cut the part of the card which is not of use to the acceleromêtre, to connect on the wiimote that I hide, it is small and discreet for cheap
I believed that nike air was sensitive only in shock, you can say to us about it more? How get back you the data?