Wireless eKo from Memsic - anybody?
john_s
Posts: 369
I use these and wonder if anybody implemented eKo nodes in the field and would like to exchange any related thoughts and apps.
www.memsic.com/products/wireless-sensor-networks/environmental-systems.html
Thanks,
John
www.memsic.com/products/wireless-sensor-networks/environmental-systems.html
Thanks,
John
Comments
This link shows info on IBM’s infrastructure platform for wireless sensor networks (WSN)
http://www.zurich.ibm.com/moterunner/
Although not directly related to Parallax product(s) it might be of some interest to others contemplating wireless.
I thought the eKo sensors were very interesting. I personally don't have need for remote sensors of this nature but I appreciate your sharing of the information.
Duane
I'm glad to carry this topic on if anybody's interested. It's a 2.4GHz ISM network and uses an interesting mesh topology that allows nodes to rearrange and hop in between to cover the distance using some algorithms to find its path of 'least resistance'. Mind you these are my guesses and opinions only as I'm just an end user of eko and going through pains of learning while implementing :-)
John
We've worked intensively on integrating the EN2120 series of long-range nodes eKo nodes into a Propeller-based platform for the past year or so. We started out by connecting the eKo base ("IRIS" base transceiver) riding on the Memsic mib510 interface board to a Basic Stamp. That configuration worked ok, but the mib510 board drew a lot of extra current, and was kind of bulky. Plus, we had to work with Memsic to get a special version of IRIS firmware that ran at a baud rate the BS2pe could handle. After doing that initial testing, we developed what we have now, which is a Prop-based platform that integrates the small IRIS transceiver module right onto our motherboard. We run the native IRIS firmware at 57,600 baud, and have a cog dedicated to listening for the Node packets that the IRIS passes in through its UART. We have about 10-20 installations with around 8 Nodes each. With the results of testing we conducted early on, I'm sure the Propeller could handle many more Nodes, which, in their standard operation, only report about once every 16 minutes. I'd be happy to share more of our development experiences with either of you or other who are interested.
-Gian
I'm very interested in your accomplishments especially as related to Parallax products.
My experience is with the mix of EN2100 and EN2120 only but without any custom designed circuitry, with up to 14 nodes in one installation where 1 node's as far as 2 miles away.
Any chances to view your installation on-line?
Thanks,
John
By viewing an installation online, do you mean a topographical view of a system layout? I may be able to show that, but I'll need to figure out a way to anonymize the location, due to customer privacy concerns. But, right off the bat, I can give you a generalized layout of most of our installations: we have the units in tree crop orchards, vineyards, and row crops. To be on the safe side, we've set 1 mile as our maximum line of site distance between nodes. In fact, so far most of our installations have each node within a mile of the base unit - more like hub & spoke than MESH (although the Nodes are likely "MESHing" anyway to gain the optimal path). We try to install the Nodes and the Base unit at least 6 feet above the top of the canopy, to decrease interference from canopy within the fresnel zone.
A big factor in integrating with the propeller is that you need documentation from Memsic/eKo that describes the packet structure of data coming into a Propeller pin from the eKo base transceiver. The eKo folks seem to be pretty open with their documentation. A lot is available on the Memsic website. For example: http://www.memsic.com/support/documentation/eko.html, and particularly http://www.memsic.com/eko-esb-integration.html. On first glance, I don't see the descriptive XML files for the eKo packets, but I would guess Memsic would send them your way if you contact them and let them know you're building an OEM application. Once you have those, it's an exercise in parsing out the bytes received at the Propeller into a structure you'd like to use for your application.
The eKo IRIS base transceiver does not implement its "Rx" line, as far as we could tell. So, that means all data from the IRIS to the Propeller is sent asynchronously from the IRIS. In other words, the Propeller has to sit there waiting for data from the IRIS. However, the Propeller is set up well for this task, as one can simply dedicate a cog, and sit in a WaitPNE statement until the IRIS reports.
As far as the hardware integration between the Prop and the eKo Base, there are two choices: connect the Propeller through level shifters to/from the Memsic mib510 interface board (full duplex RS232 driver (MAX3232, I believe) & DB9 connection on the mib510), or build a circuit board to carry the eKo IRIS Base module a la carte. With a Basic Stamp, we could just use a resistor to protect the Stamp input pin, and the 5V output was enough to drive the RS232 on the mib510 board. I'm not sure if that would work using the 3.3V Propeller pins.
Well, I'll leave it at that for now. Please let me know if you have other questions. Thanks!
-Gian
My initial intent was to get a better understanding of eKo Pro system, and perhaps to customize it with some off the shelve or custom built sensors other than the already provided by memsic. Also, I have some specific 2-way communication needs. For example I'd like to control a remote relay or generic 'contact closure' type output device (example: valve) based on the signal obtained from associated 'contact closure' type input device (example: rain bucket reed relay).
Imagine scenario where you have an area with water sprinklers installed and you want to stop watering when it rains. Your rain bucket keeps tipping on and off and some intelligent circuit like BS2 or Prop reads those signals ( see excellent Tracy Allen discussion on tipping bucket interface at http://emesystems.com/ and elsewhere in this forum) and decides to send STOP WATERING NOW command.
That's what I'm trying to understand and perhaps come up with a simple circuit design. So far the only contact I was able to establish was with Mark Holler, the owner of Camalie Networks http://camalienetworks.com.
Mark is very familiar with eKo and a great help, while being also a developer of PERL scripts and tons of codes which connect to an eKo Pro Gateway over the internet. He also placed his works for all of us as a free source under Open Source project idea. There is a place to put comments and share on the Source Forge forum where he's sharing his code http://sourceforge.net/projects/ekopromulti-sys/
In Acknowledgements there I read the following:
" Funding for this Open Source release was provided by the University of California - Berkeley researcher
Michael Hamilton stationed at the Blue Oak Ranch Reserve where a 38 node eKo Pro network provides a steady
stream of data. Please don't abuse this data stream or we will have to block its use.
The draw program was written and maintained by Christophe Kalt from 2003-2008, modified here by M. Holler "
So that's in short where I am at today. Although I'd prefer to work with BS2 family that I'm familiar with, I sense that the power of Prop is what's needed to make any wireless projects truly amazing - as long as it is solar powered and mesh type similar to eKO Pro kind of design. I figure that it might be you to come up with the right stuff...
My guess - next over the Internet accessible, low cost, easy to implement, solar powered, mesh architecture based wireless design for small sensors, network breakthrough design will come either from ANT and / or.... TI
Where can I find any technical details and start toying with mib510 or eKo IRIS base transceiver hardware?
I have few spare eko nodes to play with but with no schematic or signaling details they're of no use to me as I wouldn't even know where to start. And reverse engineering is the last thing I wanna try. I believe there must be quite a few people / user groups discussing mote applications, hardware designs and eko IRIS details and apps. Are you in touch with any of them? Perhaps you already went through all these hassles and can share some details on hardware and software site of such project with IRIS board.
As far as viewing your installation on-line - it can wait indefinitely till you decide and allow people to visit it.
We can also move our conversation to PM if you'd prefer.
Thanks,
John
p.s. I just read recent Camalie Networks News http://camalienetworks.com/news2.htm where you can get a visual sampling of their achievement while browsing through links to real field installations of eKo Pro. Also, it seems that Mike and Dr. Alan Broad had already successfully resolved the I/O issues that I mentioned earlier with the addition of CN101 interface module. Good job!
Camalie Networks is a great resource for all things eKo. I've been working with Alan Broad for well over a year now. He is a wealth of information. As I understand, he developed the lion's share of the eKo Node/base firmware when eKo was Crossbow, and then subsequent development and support once it became a Memsic product last year. Mark Holler I met for the first time earlier this year, and one minute talking with him is plenty to know he's been dealing with field implementation of the eKo systems for years. I daresay that the braintrust at Camalie networks is probably the best available about eKo products. The only issue is what information they are willing/allowed to release about the eKo products. I'm not really aware of user groups for eKo networks. There may be some, but we did not use them for our development. We really just got as much info as we could from Memsic (mainly from Alan and others who are no longer with the company) and got our hands dirty to reverse engineer what they couldn't provide (as far as I could tell that was always because they did not have the answer, vs not wanting to release the info).
As far as technical details about the mib510 /IRIS, this is a great jumping off document: http://www.memsic.com/phocadownload/support_eko/eKoEsbDevGuide.pdf. However, this does not give great detail about how to break apart data from the IRIS/mib510. This is something that Mark or Alan could probably help you with. We never got a schematic of the mib510 during our development. It was pretty much a black box that output the Node data via a RS232 connection. There is no flow control on the IRIS or mib510. Node messages are passed along through the UART immediately upon receipt. Furthermore, data from individual Nodes arrives asynchronously. This means that the microcontroller needs to be listening to that pin constantly so as not to miss a transmission. As I mentioned, when we used the BS2 for our initial development, we needed to have the eKo folks build us a special version of the IRIS firmware that transmitted at 9600 baud so the Stamp could keep up. Furthermore, if you want the Stamp to do anything with the incoming data, that takes some time, which is time it can't be listening for another incoming Node message. We needed to parse that data to prepare it for delivery to our server, which took a relatively long time, and could cause data loss in a large network. Furthermore, we were sampling environmental sensors every so often, which also took time away from listening for the eKo nodes. With the Propeller, none of that is a concern, as 1. the propeller is fast enough not to require a special firmware version (native baud is 57,600 bps) and 2. a cog can be set to solely listen for messages on a pin and then pass it to another cog for further processing. This is further enhanced by the speed of Propeller instruction execution vs the BS2. We've had much better results using the Prop vs. the BS2. However, if you can get the custom baud-rate firmware from Memsic/Camalie, using the BS2 is a good starting point, especially if you're already familiar with its ins & outs (one less variable to deal with during development!!).
I agree that Tracy Allen's discussions on the tipping bucket interfaces, along with a multitude of other subjects are terrific!
Anyway, I think to begin development, you'll certainly need to get a mib510 and IRIS. Once you purchase those, Memsic or Camalie may be more forthcoming with integration information. Do you have a eKo gateway used for provisioning the nodes? If not, you'll most likely need one of those as well. That gateway is used to set up the nodes with a "Group#", as well as a NodeID. The Nodes transmit data on a hardware-selected channel, with their assigned group# in the header of their data packet. The IRIS base listens only on a particular channel, and only accepts data from Nodes on the same Group#. There's a chance that the Nodes you had already been provisioned at some point. If they have, and they were provisioned on the default Group# & channel, then the mib510 should be able to see the Nodes reporting right out of the box. If that's the case, then come to think of it, you should be able to plug the mib510/IRIS into a PC serial connection, fire up a terminal emulator, and see the data coming out of from the Nodes. That would certainly be a good start. Another tidbit here - if you press the ON button on the bottom of the Node, the Node will send messages once every 30 seconds for the next hour. Thereafter it will send messages every ~16 minutes. Having to wait 30 seconds vs.16 minutes between Node transmissions makes development time much more productive!
-Gian
Great stuff, tons of information to chew on - thanks. I'm in touch with Mike and also sent a request to memsic (soooo sloooow) for a specific XML config file to test those 4-20mA and 1-5mA devices that I'm mainly dealing with this time. I plan to run a test bench with 'generic' sensors using mainly current loop interface. For that I need to become a kind of 'expert' in remote access while learning Linux to operate that Ubuntu box that memsic supplied as a gateway. It's nothing but a plug-and-play at all but at least I'm plowing through. Now, I'd probably reverse engineer some of that and hope to come back with a method to send 'Hello world' over that network :-)
Glad to hear you're all around in CA and kind of envy you having a chance to meet Alan, Tracy and Mike and all others fine folks while sharing your knowledge at will. Oh well, I hope to survive this coming winter and to install at least a single valve as per Mike's promise 'sometime' next spring :-)
I really enjoy this conversation and hope it also helps some others who read it here.
Thanks,
John
p.s. I'll sent you a PM with some details
I'd say to put a GPS inside and sync the nodes. At minimal cost but what an advantage. GPS = precision RTC + Lat/Long coordinates for each node, and plenty more.
The IRIS is basically an 802.15.4 radio wrapped in an ATMega1281 processor. Not many capabilities of the ATMega are exposed in the IRIS, but Alan is certainly the one who knows how to do so. Crossbow and Memsic have halfheartedly (if that much) supported the IRIS as an OEM embedded platform.
(We should fess up, Gian and I are related, son and dad. We have done a lot of stamping and propeteering together!)
Now - that is the news! Is your system available commercially?
You left me speechless - congratulations to both of you.
John
p.s. The other fellow that did some eko is Robert Davidson of www.ambientsensors.com fame, but I'm sure you knew it already :-)
Not bad at all...
"Puresense, established in 2006, produces software to manage and monitor irrigation systems, soil moisture and weather changes on the farm. The firm has more than 1,000 installations for 200-plus customers in California, the Pacific Northwest, Idaho, Arizona and Texas. "
Tracy said "The system Gian developed (and I had a hand in)". I would say "The system Tracy developed (and I had a hand in)"
Yes - PureSense is very proud to be a recipient of the game changer of the year award in ag. technological innovation. Water is such a valuable resource, and that's ever-more evident each year here in California. It's great to be part of an organization that is taking big strides to help optimize the use of what we have. But, Tracy's right - we don't sell hardware outside of our full service solution that includes installation, service, agronomic/tech support.
I agree that the Ubuntu netbook is a bit frustrating. But, once you get everything provisioned using that, with an mib510 I think you could circumvent that and go right into a PC terminal program via a serial port.