Sensor Network: Difference between revisions
From HacDC Wiki
(Created page with 'The goal of this project is: ____________________ == Implementation == === Diagram === [ Device ]<--- ? Wire Language ? --->[ Driver ]<--- ? Message Format ? --->[ XMPP server ]…') |
|||
| Line 7: | Line 7: | ||
=== Wire Language === | === Wire Language === | ||
The wire language will be device-specific. Devices can speak any language they want as long as someone has written a "driver" to translate that language to/from the chosen format that will transmitted/received over XMPP. | The wire language will be device-specific. Devices can speak any language they want as long as someone has written a "driver" to translate that language to/from the chosen format that will transmitted/received over XMPP. | ||
JeeMesh protocol is being worked on to extend the [http://cafe.jeelabs.net/sw/library_-_rf12/ RF12] frame network to support datagrams up to 1022 bytes over a mesh of [http://cafe.jeelabs.net/lab/jn5/ JeeNodes]. The goal is to support up to 4 hop meshes of up to 26 nodes plus 4 servers/gateways each. | |||
=== Message Format === | === Message Format === | ||
Revision as of 00:55, 28 September 2010
The goal of this project is: ____________________
Implementation
Diagram
[ Device ]<--- ? Wire Language ? --->[ Driver ]<--- ? Message Format ? --->[ XMPP server ]<--- ? Message Format ? --->[ XMPP client ]
Wire Language
The wire language will be device-specific. Devices can speak any language they want as long as someone has written a "driver" to translate that language to/from the chosen format that will transmitted/received over XMPP.
JeeMesh protocol is being worked on to extend the RF12 frame network to support datagrams up to 1022 bytes over a mesh of JeeNodes. The goal is to support up to 4 hop meshes of up to 26 nodes plus 4 servers/gateways each.
Message Format
Since XMPP messages are already XML, I think it makes sense to use an XML vocabulary as the message format.
Possible candidates would be:
- EEML: Extended Environment Markup Language
- Very simple
- Widely deployed.
- Not a true standard
- No namespace
- SensorML: Open Geospatial Consortium's Sensor Markup Language
- More complex
- Possibly not an open standard
- Not as widely deployed.
Based on my quick research I'm not entirely pleased with either one. A third option to consider would be designing our own XML vocabulary.
The reason for having a standard message format is to encourage collaboration and interoperability between devices and client applications. Use of the message format would be opt-in.
Discuss your ideas!