Whitecaps

River rafting expeditions are by their very nature "off-the-grid", but due to the inherent risks involved, perhaps we could implement a minimally-invasive system that makes the experience safer for all participants, cheaper for the company running the gig (insurance), and adds some peace of mind to loved ones who aren't so outwardly bound.

Welcome to the world of Realtime IoT. AT&T has put together a neat little kit that allows an intrepid electronics explorer to prototype a device in a relatively short period of time. PubNub, a company dedicated to making things go back and forth really quickly also ties in here and helps us to achieve these goals.

So, what is this all about?

I have provided links for you to track down details on all components (software and hardware) for this project below. These include a number of comprehensive tutorials to get you up and running on this platform, so I am not going to repeat that information here. I will, however, touch on a number of "issues" that I personally experienced while developing this project, and hopefully help you avoid some of the pitfalls I struggled with.

ARM mbed provides us with an online IDE through which we can compile our code in the cloud and push down to our boards. There are a ton of open source libraries and projects that can be easily imported into your workspace with a single click.

Sounds great, right?

For the most part, it really is. I was a little hesitant about entrusting my dev environment to the cloud, as that is the very core of any IoT project. I started off looking at offline solutions (which there are several, both open and commercial that can be exported to) before curiosity got the best of me and I decided to check out the mbed Studio online.

For the first day, after @kayakpete showed me the ways of the dark side:

I was able to browse around the extensive code collection and import programs and libraries that I could immediately run on my board. Then something bad happened. All of a sudden, the server wouldn't compile my code. I could no longer get binaries. I couldn't work.

There exists functionality to export your code to work locally, but that sinking feeling you get when *nothing works* isn't great. It makes me nervous as a hobbyist, and would not want to be in a bind when commercial issues were at play.

Also, sadly, some of the documentation that accompanies the AT&T IoT Starter Kit are incorrect. This is especially troubling when it is directly dealing with board pinouts. For a quick example, please reference the printed quick-start quide and look at the lower header UART4. And by reference, I mean look at it, not use it. The documentation conflicts with the silkscreening on the board. This is bad.

This brings me to my next point on this project:

ATT-GATT

The #att slack group at hacksterlive.slack.com has been a great resource. I would like to personally give shout-outs to Pete Hoffswell, Drew Alden, Julio Rodriguez, and Elvis Wolcott for staying in touch over the past week and pursuing a great team environment that shares both research and results. I am sure I have left names off this list, and for that, I apologize. We not only shared information in chat, but set up a shared documentation resource and explored the mbed team facilities. Take care, folks, and I really enjoyed working with you!

What other platforms are we using?

Well, there is AT&T M2X. We are going to set up some streams of data running through this guy here in just a bit. It helps us manage all this sensor data we are throwing around, and it even has a dead-simple graphing interface that gives us immediate visuals of our output.

Have you heard of Node-RED? It provides a RAD toolset that lets you slap a very powerful graphical programmatic interface onto an end-to-end system. Note I didn't specify what type of system.

AT&T calls their flavor of Node-RED, "Flow", and I like to think of it as one of those balls of rubber-bands. I can pull off bands and make everything from slingshots to bridges, but it can also just be a simple rubber ball. Barrier to entry here is quite low. In fact, you can get all of the data flow elements for a wide range of projects knocked out in under an hour!

The methodology around Flow is very modular. We use "input nodes" to connect to "functions", "logic", and "output nodes". An interesting application of this technology is to allow tech-savvy end-users to customize your solution to more effectively function in a manner that may not be applicable to the majority of users of the full system. This empowers users to "make the software their own." No longer does every change request have to go through the development team. Users have a very powerful control system at their disposal.

I know some of you are probably thinking, "waitaminute... I don't want my users to be able to run around all over the system I so carefully engineered."

Good point, and teams of folks have thought this through. There are tiered access mechanisms available to allow you, the developer, to determine exactly how much latitude to give the end-user in terms of freedom to modify the solution.

We then feed our data into MapBox, a mapping platform that gives us a clean method of showing the status of all of our remote sensor boxes.

Wait, I thought you were going to tell me what this is all about

I did say that, didn't I?

Well, Whitecaps is basically a box. It is a box you can get wet. It is a box that floats. It is a box you can throw around. It is a box that can communicate the current state of a rafting expedition to a central command location, mobile devices, or first-responder authorities.

So, what data are we collecting? In addition to Temperature, Humidity, and Accelerometer/Magnetometer sensors already made available to us from the FXOS8700CQ, we add the following:

• GPS (# satellites, latitude, longitude, altitude, speed, course)

• UV

• Light

• Air Quality

• Water Detection

• Piezo Vibration

This combination of sensors not only provides us with realtime conditions, but maintains seasonal historical data, and allows us to set up "macros" for emergency response triggers. Our payload comes out looking something like this:

{ 
 "eon": { 
   "temp": 28.92, 
   "humidity": "35", 
   "heatIndex": 28.31, 
   "uv": "0.01", 
   "light": "0.58", 
   "air": "0.11", 
   "water": "0.88", 
   "accelX": "-0.172", 
   "accelY": "0.075", 
   "accelZ": "0.965", 
   "gps_satellites": "7", 
   "latitude": "XX.XXX", *
   "longitude": "-YY.YYY", *
   "altitude": "23.809999", 
   "speed": "0.000000", 
   "course": "4.361000" 
 } 
} 

* coords were removed to protect the innocent.

We wrapped this up in an "eon" tag to facilitate our charting/mapping that we will get to here in just a bit.

"If the boat is upside down, wet, and we hit something..."

This is where things get interesting. We can set up functions within Flow to trigger events such as sending an SMS, turning on an alert light at headquarters, or even contacting emergency personnel. Even cooler, these alerts can easily be customized by the companies to more closely fit their individual needs.

update: The more I am working with triggers, the more ideas keep popping up. I feel it is critical to try to keep this as unobtrusive a device as possible (but there are so many cool things to do here):

• When emergency triggered by sensors, go into SOS mode with flash beacon, radio emergency Flow, and shut down all sensors to help preserve battery life.

• Manually operated "abandon ship" switch.

• RFID keytags that guides would use to "sign on" to a raft for the outing. This can also tie into the full manifest via whatever existing backend is in place.

Maps

So, we want to display each raft that is currently out on the water on a map that can be accessed by both the central command and other employees via browser or mobile device. Using EON, the new mapping component from PubNub, this is easily achieved.

We can grab all of the data that we are capturing via the onboard sensors and display it on the map (as well as store it for analysis).

We need a place to put this up, so I decided to check out the new offering that Amazon announced; lightsail.

It only took about ten minutes to have a simple LAMP instance up and running (for 5USD/mo):

Custom Enclosure

A dry box was obviously needed to protect our hardware, but we also needed to expose our sensors to the "outside world".

Enter Sugru stage left.

If you haven't had a chance to play around with Sugru yet, you should really check it out. It is a hardening silicone putty that you will probably find a ton of uses for. I am using this to seal the holes going to the sensors that must live outside of the protective environment of the box. It is used in conjunction with heatshrink to provide a watertight seal around the electronics. Will this stand up to seasons of weather? I dunno. We shall see.

Links

AT&T IoT Starter Kit - Getting Started Guide