I was 7 years old when my parents received drove home with 2 enormous boxes from a place called "Computerland".  They had gotten one of the original PC's, and I remember my excitement when they put in the floppy disk and powered it on.  It was loud, and after a bit of time while numbers incremented in the top right corner (counting memory) the floppy drive started making loud sounds, "Starting MS-DOS" appears.  My excitement waned when I realized it was not an Apple like a few of my friends had, and that there were no games for it as green monochrome text was all it was capable of.  

I am interested in making a monitor for my parents.  They are elderly and do not want to move out of their home, and are at the stage where if we don't hear from them after a while we get worried.  I am at the age (51) where my college friends are also going through similar issues.  Today's smart watches cover pretty much everything that I would want to know and more.. however there is no real way that my parents would wear them, nor would they be able to keep them charged, and they would likely take them off to sleep.  Smart Watches are amazing devices but require a level of maintenance that simply isn't possible.   I quickly found the DF Robot mmWave motion sensors.  

Problem: Solution: Ocean Science sensors should have enough memory to log an entire lifetime of data. They should know when they are being calibrated, and measure their offsets to have long and short term metrics for their performance. The sensor should know and keep track of what it is good at and what it is bad at to optimize its refurbishment and performance. Every sensor should have a default suite of additional sensors and telemetry built into itself: gps, power usage, motion, humidity, wifi, pressure (external and internal), temperature. These should be ‘always on’ even in low power mode while in transit. A sensor should know how many times it has been dropped or experience sudden movements while deployed. When a sensor’s wifi can see the internet it should upload all of its data to a custom server and be able to download the latest ‘usage database’ of all of the same model sensors. This ‘usage database’ is a compilation of all of the metrics for all the sensors of the same type. The importance of this is for that sensor to get a chance to compare its performance metrics with its entire family. If its pump is in the lower 20% of performance then we know it should be replaced. Once a sensor knows where it is in the world it can reference an internal (and external) database of what settings other sensors of the same model were set to. Discussions can be had and sensor settings can be agreed upon for each goal of the sensor and each geographical location, so it’s as simple as putting it in the water and the sensor will use it’s GPS and pressure sensor to determine the optimal settings (which can be over ridden for customized tests). A sensor should sit on a network and be able to communicate to all the other sensors on the same network. If it finds a similar sensor that is older then it can compare itself to that older sensor. If it finds a sensor with a better clock score then it can use that sensors clock. A network of sensors can corroborate its data with others. B There should be a “Ocean Science Sensor Operating System” that handles all of this for people building new sensors. It could run on the processor running the Bristlemouth stack. The open source Ardupilot software could be a good start for this. It has serial logging and storage, expansion over can (and thus bristlemouth), LUA scripting capabilities, location and motion based logging and being a ROS node. It has a protocol for communicating to higher level systems called “MAVLINK” but it could be adapted to the bristlemouth standard. Just like how they have customized versions for planes, rovers and boats we could make a customized version for sensors.