Mike Riley is a Dr. Dobb's contributing editor. He can be contacted at firstname.lastname@example.org
Long-time Dr. Dobb's readers may recall my article series on embedded systems programming and reviews of products such as the open hardware Arduino and the first iterations of Bug Labs' BUG. These platforms provided optional hardware for connecting to a network, but were hardly designed for mission-critical 5-9 uptime. Rather, they satisfied their intended market of hobbyists and tinkerers. Alternatives for scalable devices and backend data collection and messaging systems were either non-existent or closed, proprietary and ridiculously expensive systems.
For serial entrepreneur Shane Dyer, this spelled "opportunity". This led Dyer, who had previously launch ventures such as Propellerhead Studios and ActivePhoto, to create Arrayent, a company centered around the idea of providing embedded systems developers with the hardware and infrastructure necessary to manage devices without the need to invest in a huge infrastructure to host the communications, data collection, security and provisioning required to scale a commercial embedded solution.
At its heart, Arrayent supplies organizations seeking all these things at a reasonable cost. The seed that germinates these potentially world-changing devices begins with Arrayent's Internet-Connect Development Kit.
The Arrayent DevKit contains hardware necessary to begin remotely activating and sensing its operating environment. The RF-enabled Arrayent Ethernet Gateway Board connects to a developer's live Internet connection and communicates with Arrayent's servers. Its on-board RF radio wirelessly talks to the second half of the developer kit, the Arrayent RF Module. The enhanced version of the board hosts several types of communication pathways such as a RS-232 serial port and two digital input/output lines and two analog input lines, as well as a basic temperature sensor whose readings can be collected at timed intervals. This sensor helps to both demonstrate how data can be captured and collected by Arrayent servers (and forwarded on to other servers via REST and other wire protocols) while simultaneously ensuring adequate operating temperatures for whatever other hardware will connect to the board.
Using the included 4.5V power supplies that separately power the Gateway Board and RF Module, the Gateway board will automatically negotiate a connection with the RF Module and indicate with on board LED's when a connection is made. Arrayent claims that reception between these two components can span a distance of up to 120 meters in open air environments. And while there are no signal strength indicators on either of the boards, these values can be monitored via the RFRSSI (receive strength indicator) attribute in the Arrayent Configurator. A good connection would be rated at roughly -30 to -40 DBM and can even be as low as -90 DBM and the boards can still communicate with each other.
Once the Ethernet board is plugged into a network cable with an Internet connection, communication with the RF Module and Arrayent's data collection and management servers is automatic. That's right -- no code required. Unlike other network embedded solutions I've worked with, Arrayent handled all the network and data transactions for me. This is great, since it leaves me able to work on what sensors I want to attach, what data I want to collect, and what actions I want to take with that data. Of course, I can also attach actuators to the boards, from servos and stepper motors as well as output devices like LCD screens and other RS-232 serial port-enabled systems (the SpeakJet chip for example). However, I found that the current Arrayent system is optimized for collecting data from various sensors such as the onboard temperature sensor, sending the data up to the Arrayent servers and having the system interact with those values either by storing and forwarding the data to non-Arrayent servers or placing alerts on the values being received should they exceed a defined threshold. These alerts currently include email messages and and Twitter tweets. Over time I can see these alerts expanding to everything from paging, phone calls with a mix of pre-recorded and text-to-speech generated audio to REST-based messages that cascade to other servers and processes.