标签: loggers

I just received the following query from a reader: Hi there Clive! I don't want to give a 'How to' at this stage, I would like to ask 'how to?' While officially retired, I cannot stay away from MCUs. The design and programming is simply too intriguing. I have this line of soil moisture data loggers. The 'how to' I have yet to find is the transport of the data from the loggers to the computer. Physical connection is not the best. Weather and geckos and spiders and such like really make plugs and sockets not the ideal. GSM is also out, no signal at most of the loggers. Permanent physical pairs are also out, the length is too high, and road crossings are a problem. Because the system is only efficient if there are a sufficient number of data loggers to cater for all the varying soil types and plants, the loggers get to be cost sensitive. Bluetooth modules are too expensive, else it would be a nice alternative. Then a cellphone can be used to transport the data. So "How to?" Perhaps your readers can contribute. Well, first of all I have to admit to being a little bit biased, because I know a local company in town – Synapse Wireless – who create small, affordable, low-power, wireless modules that would be ideal for this sort of thing. Since you are talking about having lots of sensors / data loggers, one thing you need is a mesh network. The idea here is that all of the wireless nodes link up to form a mesh. So if any nodes are located remotely from the main computer – that is, too far to communicate with the main computer – the other nodes will automatically route the messages. I tend to think of this a bit like runners in a relay race passing the baton from one to the other. Each wireless node includes a microcontroller running a piece of software called a wireless stack. One wireless stack that everyone has heard about (even if they don't know much about it) is called ZigBee. There are a couple of issues with ZigBee. First, the ZigBee stack is quite large – about 120KB, and that's without any user applications – which forces you to use a more expensive microcontroller. Second, creating application programs requires knowledge of the ZigBee stack, coding in C, compiling the application in conjunction with the stack, and physically loading the application-stack combo into the target wireless node. And if you think this is a pain, wait until you try debugging your application (grin). By comparison, the folks at Synapse have a stack called SNAP. Even though it's only 40KB in size, SNAP is a fully self-forming, self-healing mesh network. By "self-forming" I mean that when you turn a node on it effectively should "hello everyone" and automatically integrates itself into the network. By "self-healing" I mean that if any node or nodes fail, the others will automatically re-route messages around the failed node(s). But the really big advantage of the SNAP technology to my mind is the fact that you create your applications in the Python scripting language, which is really easy to learn. (I know of one small company that took delivery of a Synapse evaluation kit. One of the guys drove into town to pick up a book on Python programming. By the time he returned, the other guy was already modifying the demo applications and running them.) The folks from Synapse also have a software tool called Portal that is free and that runs on your PC. This is the tool you use to create and debug applications and to administer your network. When you power-up a new wireless node, its corresponding icon immediately appears in your Portal window. When you create a new application, you simply drag-and-drop it over the destination node or nodes. Your application is interpreted into byte code, which is wirelessly transmitted to the target nodes "over the air". This means that even after you've deployed all of the nodes, you can modify your application(s) at a later date without having to bring the nodes back to your "head office". Actually, I emailed David Ewing – the CTO at Synapse Wireless – copying him on this reader's query and asking what he would recommend in this case. David replied as follows: All of our modules are fabulous (grin), but for this application I would recommend something in our RF2xx or SM2xx line. Since cost is an issue, the SM200 may be the best bet. Yes, Portal can be used freely as a datalogger for an unlimited number of nodes. However, it would be really cool to use one of our E10 units as the datalogger. This could also sport a cell-modem to provide Internet access to a remote site. A SNAPconnect license is built into the cost of the E10, which is a reasonably priced rugged-embedded Linux box. As a bonus, one of the example programs bundled with SNAPconnect is a Pachube Updater program. With that in place – and almost no programming at all – you would have web-access to sensor readings from anywhere in the world, including the ability to "tweet" if the readings went outside your prescribed boundaries. The Pachube service provides archiving, tweeting, etc. for free at present. So there you have it. I shall be emailing the poster of the original question asking him to keep us informed as to which solution he eventually decides to adopt (ZigBee, SNAP, something else ... ) and how he gets on with it. Maybe he will even write a "How to" article on this topic (you can run, but you can't hide :-)