Sensor Area Networks (SANs)

[nedb]

(06-04-2013 21:16)davidmbrady Wrote:  Just a quick update on what I've recently discovered.

First, the Digi WR21 Cellular Router that I bought for $375 (plus $10.00 shipping) doesn't contain a ZigBee Internet Gateway as I initially had thought. This means another small box is required, the Digi ConnectPort X2 which costs $108.

On the plus side, EmbeddedWorks, the same folks who offer affordable byte size chunks of GSM and CDMA bandwidth carry a comparable router for less money and they offer group buys.

Another interesting tidbit is that the discovery of ZigBee Internet Gateway (XIG) devices requires client side connection initiation. This is because we're transmitting over the cellular network. To keep an XIG active and connected periodic keepalive messages need to be transmitted. If not then the device looks like it's disconnected from the network and the server can't find it. I think TCP keepalives are used and the total packet overhead for a keepalive exchange is 114 bytes.

Well if you do the math you can see that a keepalive sent every 5 minutes will consume almost 1 MB of bandwidth per month! Ouch! No big deal really. We have two choices, buy more bandwidth and/or decrease the keepalive frequency.

Putting one knee in front of the other...

If it was my business plan instead of Digi's, I'd be giving away Zigbee features in everything in the product line. An extra $100 box? Noooo. I'd dump Zigbee on the market below cost, drive the competition down, buy 'em out, and generally make way for the ubiquitous.

Hmm. Client initiation... So when a Zigbee comes on the network, it waits for a broadcast? Then gets discovered, then goes dark and gets scratched off the server list. Why not just wait for another broadcast from the client?

Must be a very orderly network.

Maybe Digi modems aren't the best way to go. Why not let the zigbees and the arduino do their transmit/aggregate thing, run some statistics on the data periodically to provide near-real-time status in a web page on a monitor. Use the gateway to upload a formatted email to the WaGu server's account, where scripts parse the email and add the data tp the database. It analyzes and calls you on the phone: "The last fuel stop slimed your filters. Vacuum levels will shut the engine down in 2.87654 x 10 23 femtoseconds." OK that was silly, but not bad considering I've forgotten what the modem connection was for.

For sure, not the end-all solution. If it isn't going to work, I can forego the explanation of why not.

I still think the all-in-one Digi modem is pretty swift. But I don't expect to be getting satellite, in fact my flatscreen is broken. I've turned it into a cabinet door. I like it now

[davidbrady]

I think it's due to the way cellular networks work. Communication on a cell phone is always client side initiated (initiated by the cell phone). You can't get a phone call until you turn your phone on and let it identify itself and it's geographic location. Cell phones don't have IP addresses. They adopt the IP address of the nearest cellular gateway (GPRS). With no IP address and the phone able to be anywhere geographically, the server can't initiate, or at least that's the way the protocols are written. (Scalability issues come to mind). So when a ZigBee comes online it sends a message to a server saying "here I am". Not a broadcast - the ZigBee Gateway get's programmed with a server's URL. Over WiFi no keepalives are needed.

The $100 ZigBee Gateway is a box that speaks ZigBee (RF) on one side and ethernet on the other. On the ethernet side it sends and receives HTTP/XML packets to allow configuration, monitoring, and control, and it generally does what it needs to do to stay visible on the network. It'll cost $50 for an rPi and $25 for an XBee Series 2 to duplicate the Gateway and then you need to add all the protocol development time. For an extra $25 you get all this plus more. It's not a Digi thing; it's a ZigBee standards thing.

From the ZigBee Alliance:
  Understanding ZigBee Gateways Sept 2010.pdf (Size: 939.35 KB / Downloads: 1716)

It's neat and light weight Ned. All WaGu needs to do is format an XML form and send it to the Gateway using HTTP! The Gateway will respond with either flipping switches or reporting back monitoring conditions (temps, pressures, voltages, etc). There are still questions to be answered though.

[nedb]

I approve of the idea of data wrapped in markup, like the html/xml San-a-grams this system would use, but I like it mostly because it represents a "form" that is human readable, and we could find existing server-side software to extract the data and put it in a 'base.

If the html/xml goes against the conservatively-sized data plan, it will hog the allowance in a hurry. I guess we'd prefer terse messages, probably just a formatted stream where position 1-3 is sensor #1 data value, position 4-6 is sensor #2 data value, etc...

You computer science guys will know how to take advantage of algorithms to compress the data and shrink it. Computer science gals will want to shrink it and pink it.

[nedb]

On the lighter side of Xbee, sensors, and remote control...

Here's a start-up using xbee and arduino in their product. They make it look easy

start-up using arduino+xbee

[davidbrady]

Folks,

I took an Arduino and wired up a temperature sensor to measure my pool water temperature. I plugged an XBee into an XBee shield that's plugged into the Arduino and I nestled the temperature sensor up against my PVC piping in my pool house. In my home I have a laptop that's running ZigBee Gateway software and I have an XBee hanging off a USB dongle. So I have a very simple network made of two Xbee's, a ZigBee Gateway, and an Arduino with a temperature sensor.

If you click here you can track my pool's water temperature!

[nedb]

I saw the temperature change!

I looked at the web page source--the tag <dcdFloatValue> contains the temperature. What is that from, a style sheet, or maybe the developer kit provides the definitions for sensor data in extended HTML?

Whatever, I think it is very cool. Probably just about right for diving in on a hot day

Nice work, David. Award yourself a Reputation point

[davidbrady]

Hey Ned,

Thanks!

I have my Arduino sending periodic temperature I/O data samples to the ZigBee Gateway once every 30s. The gateway opens a TCP connection to the Digi Device Cloud and sends an HTTP Post. The Digi Device Cloud stores the samples and allows WaGu to query for data using an HTTP Get. When WaGu issues the Get the Device Cloud responds with the below XML form. WaGu parses the results to pull out the temperature. As you can see there's a ton more info in the XML that I'll parse when I have the time. Right now my challenge is XBee signal strength. My pool house is quite far away from my laptop in my home. I'm using the XBee with the printed circuit board antenna. I need to order another XBee to act as a repeater in my mesh network. This way it'll relay messages from my Arduino to my laptop. I'm sampling swimming pool water temperature, but this could just as easily be the temperature inside your bus.

It's a great proof of concept Ned. My laptop gateway will be replaced with my Digi WR21 cellular router and connectPort X2. This will be the mobile XBee Internet Gateway which will be installed in my bus. Then it's a simple matter of moving over as many Arduino/XBee boards wired to sensors as I need to monitor Temperature, Voltages, Currents, Cameras, to my hearts content! And, this is scaleable. Anyone wishing to set this up will need to create a free account on Digi's Device Cloud. Data will be sent and stored there and on WaGu I can keep a secure MySQL record of participants account credentials and I can provide a webpage for them to see their gauges.

It is our first Sensor Area Network!

<result>
<resultTotalRows>1</resultTotalRows>
<requestedStartRow>0</requestedStartRow>
<resultSize>1</resultSize>
<requestedSize>1000</requestedSize>
<remainingSize>0</remainingSize>
<DiaChannelDataFull>
<id>
<devConnectwareId>00000000-00000000-001F16FF-FF2A2B07</devConnectwareId>
<ddInstanceName>XBee_40A03DF3</ddInstanceName>
<dcChannelName>temp</dcChannelName>
</id>
<cstId>4736</cstId>
<xpExtAddr>00:13:A2:00:40:A0:3D:2F</xpExtAddr>
<dcDataType>0</dcDataType>
<dcUnits>C</dcUnits>
<dcdUpdateTime>2013-06-08T14:02:11.000Z</dcdUpdateTime>
<dcdStringValue>72.08</dcdStringValue>
<dcdFloatValue>72.08</dcdFloatValue>
</DiaChannelDataFull>
</result>

[nedb]

(06-08-2013 11:16)davidmbrady Wrote:  <dcUnits>C</dcUnits>
<dcdUpdateTime>2013-06-08T14:02:11.000Z</dcdUpdateTime>
<dcdStringValue>72.08</dcdStringValue>
<dcdFloatValue>72.08</dcdFloatValue>

<dcUnits> is 'C'?

72.08'C

So your pool fed by hot springs?

[davidbrady]

That would be 'C' as in Comfort Units... LOL My pool is 72.08 Comforts!

BTW, the HTTP Post that my gateway sends is only 40 bytes. I'm realizing that it's better to send data periodically then to waste bandwidth on keepalives.

Also, we're not married to the Digi Device Cloud, any device cloud will do and there's several to choose from. I do like the idea of using a device cloud though. Remember this is a mobile SAN. The device cloud acts like a Domain Name Server for XBee internet gateways. As the bus travels across cell site boundaries IP addresses come and go, the device cloud hides the nastiness of all this. WaGu simply passes it login credentials and an XBee name and the device cloud resolves this to a physical location and IP address. The device cloud also provides a pretty slick HTTP/XML interface to do everything we need to monitor and control.

[nedb]

(06-08-2013 22:29)davidmbrady Wrote:  That would be 'C' as in Comfort Units... LOL My pool is 72.08 Comforts!

I thought Comfort Units were 'C'ookies :-)

Quote:BTW, the HTTP Post that my gateway sends is only 40 bytes. I'm realizing that it's better to send data periodically then to waste bandwidth on keepalives.

More sensors would increase it, but not much.

It would be fun to get some free data from the cellular network via the cloud. Do you think the cloud is storing location information, like the location of the cell tower you connected to when you upload? I don't see any reference to it in the XML output of 'get' you posted, but they might have it for you if you ask nice. If you got 'position' without transmitting it from the metered account, that'd be nice.

But you probably will have to integrate coach-based GPS into the data to get that info. I don't really know. Maybe cellular companies have developer kits with APIs for getting all kinds of info off the tower. Anyway, cell towers have GPS, but I think they only use it for the time tick.

Quote:Also, we're not married to the Digi Device Cloud, any device cloud will do and there's several to choose from. I do like the idea of using a device cloud though. Remember this is a mobile SAN. The device cloud acts like a Domain Name Server for XBee internet gateways. As the bus travels across cell site boundaries IP addresses come and go, the device cloud hides the nastiness of all this. WaGu simply passes it login credentials and an XBee name and the device cloud resolves this to a physical location and IP address. The device cloud also provides a pretty slick HTTP/XML interface to do everything we need to monitor and control.

Looked like a MAC address in the XML <xpExtAddr>. Or maybe it was the tower's IPv6 address? IPv6 just confuses me

I did create a free cloud acount good for up to 5 devices. Haven't signed up for any services or dev kits though. I didn't see anywhere to get the Gateway software for a laptop, looks like it might be part of a dev kit.

So far so good, it does look nice and light. I'm trying to gauge whether the value added by the cloud is worth the cost. An existing MiFi cellular data account would be addressable over the 'net, but I haven't looked very hard at the effort needed to do command and control. I did see an 'Internet accessible' thermostat at Lowes not too long ago. That might be a first step, but like the cloud of Digi's, it probably involves someone else's server in the middle.

Still, I'm getting a kick out of your pool monitor. Imagine monitoring your pool temperature from the banks of Puget Sound~it does suggest possibilities.

How about a pool cam?