any possibility of DASH7 being integrated into arduino framework?
Which part of it?
Funny. The wireless sensor networking technology, not the plane.
Ahh i found it here:
http://www.dash7.org/index.php?option=com_content&view=article&id=9&Itemid=11
Looks very interesting.
Maybee there will bee a "base module" that could be hooked up to an Arduino ? would be neat.
EDIT:
Here it is compared to Zigbee, very interesting!
OK, I sat through the "DASH7 OpenTag Webinar" (http://www.dash7.org/index.php?option=com_content&view=article&id=127&Itemid=191)
I found it rather depressing. Here are some points:
- While the standard is apparently well aged for things like RFID, it appears to be pretty new as a general purpose wireless sensor technology. The Webinar talks about stuff to be released later in 2010; not ready now.
- The target of the OpenTag open source software is 32-bit ARM chips (M3, maybe M0. The current reference design is an STM32F Cortex M3) with DMA capability, and large-ish 16bit chips like some of the MSP430s. The author rates 8bit chips like 8051 and PIC as "unlikely." That's rather in contrast with the glowing marketing slides from dash7.org implying that DASH7 is significantly simpler than Zigbee (for instance, I think the Xbee modules use some sort of 8051 core cpu.) Of course, this is probably a rather bloated open source stack rather than a finely tuned minimal-size thing... I'd put the arduino-class AVRs somewhere between a PIC and MSP430 in overall capabilities, so putting a dash7 implementation inside an arduino is also somewhat unlikely.
- The marketing glossies talk about $10 modules, but you can't go out and get anything close to that yet. Nor is there anything close to the Xbee $25-$40 modules. The cheapest thing I could find was about a $70 module. The "reference" development kit is $2000. There's a much cheaper kit ($150: two transceivers) from TI based on the CC430 SoIC. This officially only supports 800/900MHz, but they're supposed to include schematics and instructions for conversion to the 433MHz used by Dash7. The 433MHz version of the TI sportswatch kit might be able to support this (the presentation seems to pre-date the watch.)
- they're talking about running IPv6 on top of DASH7 (or something like that.) OK. Add a bigger processor
(The current code is about 50KB on STM32 and 16KB on CC430. Not awful yet, but ... not something that fits in your arduino with plenty of room left over, either.) - It sounds like OpenTAG will like the XMega...
Sooo... IMO: Researchy. Not ready for the Arduino audience. Not even ready for the Arduino Developer Audience. Time will tell. Bluetooth and Zigbee are way ahead in terms of providing a drop-in wireless communications module.
Hi guys: some folks in the DASH7 community told me about this discussion. I am the lead developer for OpenTag. My email address is at the bottom of the message.
First, let me explain a few things about DASH7 and OpenTag.
Bluetooth and ZigBee are older that DASH7 and more mature, but they are also not open standards, nor are they open source. This may or may not be an issue for you.
DASH7 (ISO 18000-7) is not designed as a cables-replacement technology. In fact, it's a pretty lousy standard to use if your primary goal is to replace a traditional wire: this is because it does not focus on point-to-point "session-based" communications. The DASH7 MAC and data elements are architected in such a way as to make feasible ultra low power, ultra ad-hoc operation. So, it is quite good for sensing and awareness applications where things are moving around, or, from another perspective, where devices spend a lot of time sleeping and the session cannot be guaranteed.
This means that using a DASH7 module would not be as simple as hooking up a serial connector and sending addresses & data. If this is all you want to do, of course this is possible, and I could spin-out a module build for this limited function pretty easily. Or, I could tell you how to do it ... after all, OpenTag is open source, and we LOVE open source developers.
The other question here seems to be whether or not DASH7 can work with the Arduino. The answer is yes, and there are various ways to do it.
-
Use a module based on something like the CC430. I said earlier that it's not trivial to create a module for DASH7/OpenTag. The reason is not technical, but that it's hard to assess the market requirements in a way that would allow me to write a consistent OpenTag module interface that could be conformable to most of the them. If you have some requirements you would like to share, please send them. In some cases, it might be easy to get something working.
-
Port arduino (and OpenTag) to the XMEGA. OpenTag should have no problem running on the XMEGA, as XMEGA has a DMA and plenty of resources.
-
Port OpenTag to the Atmega. It is possible, but it won't be highly optimized. Someone thinks that because OpenTag cannot run on Atmega, it must be bloated. The opposite is true! OpenTag compiles into about 10-16K of program space on the MSP430 or Cortex M3, depending on options. OpenTag was architected to use a DMA because this reduces the number of interrupts and, thus, reduces the power requirement quite substantially. But you can still do it without a DMA. It's just not optimal. Certain radios also have hardware that can basically do the same job as a DMA. I do have one interested party that may well be going down the path of developing an AVR Atmega port that pairs with a TI CC1101 radio, so I'm looking into getting this to run OK without a DMA.
On supporting AVR:
OpenTag is not a huge project. The HW we support is based on a handful of things (in order):
- What products lead to the best price/performance?
- Which companies support ISO 18000-7 and the DASH7 Alliance?
- Which companies send us dev kits?
Atmel is not yet in this matrix. I have nothing against Atmel or the AVR, but there's only so much bandwidth I have (pun intended). Moreover, I find the MSP430F5 core to be lower power, higher performance, and about the same price as the AVR is. The CC430 is also hard to beat in price due to it integration. The Cortex M3 is a brute -- it can pretty easily do FFT, which is needed for many types of advanced sensors. These are the reasons why I haven't put AVR on the formal roadmap.
If someone else wants to write the AVR port, I will help, but I am too busy right now with the other ports to do the bulk of the job on an AVR port. Let me know if this is something that interests you. As I mentioned, I can hook you up with some guys who are already thinking about an Atmega+CC1101 port of OpenTag.
Lastly, TI is sending us some Chronos watches that we'll get set up with OpenTag. Shouldn't be an issue.
jpnorair_dash7_org (fill in the blanks)
I'm way behind on my networking efforts with arduinos. Xbees and ethernet interfaces sit in a box and lay there while "the real job" interferes. On top of that, radio has never been my strong suit. However...
Is there a "lay" description of DASH7 operation somewhere? Something RFC-like rather than CCITT-like? In particular, what sort of requirements are made on the radio? There are inexpensive 433MHz transceivers out there (Linx technology module: Electronic Components and Parts Search | DigiKey Electronics), but they provide modulation of a bitstream, so I don't know whether they're suitable for whatever DASH7 does with the radio.
The "ideal" DASH7 module for Arduino probably looks like an xbee, communicates with the Arduino app via a bytestream/print-like interface even if sending limited packets/transactions, and might well contain a CPU bigger than the arduino itself (I'm pretty sure that both the xbee and "ethernet" modules contain more computational power than the ATmega328.) Extremely low average power consumption is probably not a major goal the way it would be for a tire pressure sensor expected to run for years on a small coin cell, but lower than xbee (40mA/300mA) would be good.
This means that using a DASH7 module would not be as simple as hooking up a serial connector and sending addresses & data. If this is all you want to do, of course this is possible, and I could spin-out a module build for this limited function pretty easily. Or, I could tell you how to do it
A module or mode that you could tell "send this message to this (possibly broadcast or multicast address" when you get a chance, if possible, and let me know the results periodically" would be pretty useful for a lot of the things where Arduinos are currently using zigbee/xbees. I think. Especially if it was half the price due to lower computational requirements. (although as you point out, computational power itself is getting awfully cheap.)