Why XBee?
I have completed a beta version of the processing code that does what the MAX/MSP program does. I just need to run it and see how well it works. If it works well I will post the code.
More of the question is why use the ZigBee protocol. The greatest advantage is that I do not have to connect and pair every device to the central hub. If I used Bluetooth the coding might be easier but I will have to pair seven devices and have seven sessions running simultaneously. This might add to some serious latency within the installation. With the Xbee I can target specific modems within the network as well as broadcast the information. To give the networking example of this, within a specific IP 124.124.1 (just made it up) I can target a specific node 124.124.1.124 or broadcast to that network only 124.124.1.255. This allows me to have data all be sent to one location. That location can understand which modem it can from and then send broadcast data or specifically target one modem. I have gotten them to broadcast data but and send to one receiver but I have yet to figure out how to have the central Xbee switch the targeted modem or how to have the other modems pick the correct information (instructions for them) out of a broadcast. I am trying to do away of the Arduino to save energy, save room, and remove latency. I might still be forced to use one because I only have six inputs and outputs. Three are being used by the accelerometer. One might be used by a Qprox sensor, if that is the case I am only left with two PWMs. If this is the case I would have to light the bottle with one LED. The LED would probably have to be a Luxeon, which are amazing but pull about an amp for power and can kill batteries quickly. The Arduino gives me more outputs (6 PWMs). Alternatively I can have the Arduino only receive the data and control the LEDs, sound, and vibration (and possible smoke). This should not cause noticeable latency but does not save on space and power.
I also ordered an I2C accelerometer. I am going to play with them since I2C products are much cheaper and in theory very fast. I also purchased a LiPo battery. This is a lithium polymer battery which is better than Lithium Ion (though it might be more toxic). The battery will be good for prototyping but does not have enough mA hours to run the LEDs for long (1 hour for one luxeon). I will order a VDPI1 from mouser to experiment with pull sound files off on to an Arduino. If this works I with have to use the Arduino but will try to have the XBee do the sensory work while the Arduino controls the bottle.
Tom Igoe has some nice code on page 273 on his "Making Things Talk Book". This explains how the Xbee sends data and how you can parse it. Included in the packet if data that the Xbee sends is the signal strength. I can use this to solve the issue of how close the user is to the alchemy table.
More of the question is why use the ZigBee protocol. The greatest advantage is that I do not have to connect and pair every device to the central hub. If I used Bluetooth the coding might be easier but I will have to pair seven devices and have seven sessions running simultaneously. This might add to some serious latency within the installation. With the Xbee I can target specific modems within the network as well as broadcast the information. To give the networking example of this, within a specific IP 124.124.1 (just made it up) I can target a specific node 124.124.1.124 or broadcast to that network only 124.124.1.255. This allows me to have data all be sent to one location. That location can understand which modem it can from and then send broadcast data or specifically target one modem. I have gotten them to broadcast data but and send to one receiver but I have yet to figure out how to have the central Xbee switch the targeted modem or how to have the other modems pick the correct information (instructions for them) out of a broadcast. I am trying to do away of the Arduino to save energy, save room, and remove latency. I might still be forced to use one because I only have six inputs and outputs. Three are being used by the accelerometer. One might be used by a Qprox sensor, if that is the case I am only left with two PWMs. If this is the case I would have to light the bottle with one LED. The LED would probably have to be a Luxeon, which are amazing but pull about an amp for power and can kill batteries quickly. The Arduino gives me more outputs (6 PWMs). Alternatively I can have the Arduino only receive the data and control the LEDs, sound, and vibration (and possible smoke). This should not cause noticeable latency but does not save on space and power.
I also ordered an I2C accelerometer. I am going to play with them since I2C products are much cheaper and in theory very fast. I also purchased a LiPo battery. This is a lithium polymer battery which is better than Lithium Ion (though it might be more toxic). The battery will be good for prototyping but does not have enough mA hours to run the LEDs for long (1 hour for one luxeon). I will order a VDPI1 from mouser to experiment with pull sound files off on to an Arduino. If this works I with have to use the Arduino but will try to have the XBee do the sensory work while the Arduino controls the bottle.
Tom Igoe has some nice code on page 273 on his "Making Things Talk Book". This explains how the Xbee sends data and how you can parse it. Included in the packet if data that the Xbee sends is the signal strength. I can use this to solve the issue of how close the user is to the alchemy table.
posted by Aaron M Cohen at 10:01 AM
0 Comments:
Post a Comment
<< Home