We made great strides in 2016 with development of new calibration procedures and continued refinement of the housings & connectors for multi-sensor builds. At this point I’ve cobbled together more than 130 loggers for the Cave Pearl Project. While I still have a way to go before I reach Gladwell’s 10,000 hours, we haven’t spent $71 million, and I think I’m starting to get the hang of it. Of course, I felt that way last year too, so perhaps that’s just as good as it gets when you are figuring things out as you go along. It’s not unlike that moment when your boss calls you in for the annual performance review, and then starts the meeting by asking you to rewrite your job description, again, because less than half of the work you actually did last year was in the previous one.
Despite all that building, the number of loggers out on deployment leveled off around sixty five as newer units were often used to retire earlier generations out of the fleet. It’s worth noting that those old dogs are all still running, but field logistics have reached the point where we can’t expand the project unless everything on active duty has more than a year of operating life. Fortunately the latest Pearls are consistently delivering sleep currents around 0.1mA , so builds with more than AA cells are probably going to run for two years or more.
The temp. string loggers are currently the most complicated builds, but they have been delivering some very impressive data sets. Despite their flagship status, most are deployed in sites with a nasty mix of salt water and hydrogen sulfide that’s been destroying the marine grade stainless steel anchor weights. As they take a while to assemble, on-site service and redeployment will be the norm for those logger installations until we get more of them into circulation. Rapid turn-arounds like that were one of the original goals of the project, but that’s only possible in practice because none of our current sensors are affected the bio-fouling that accumulates over a deployment.
There are plenty of new sensor combinations on the todo list as we round out the hydrology tool kit with more cheap & cheerful ‘tattle-tale’ builds. The recent discovery that you can stretch the I2C bus out to 10’s of meters has opened up many new sensor possibilities. Long-cable MS5803 pressure sensors are now being put into service for borehole logging and if I can reduce the thermal equilibration time, that sensor also shows promise as part of a drop profiler. From very the beginning, we’ve had our sights set on a cheap reliable CTD with extended logging capability.
Our oldest monitoring stations are reaching the three year mark, which means we are starting to see repeating annual cycles in the data. As an example, here is the temperature and tilt record from one of the reef stations in Akumal Bay:
The occasional hurricane means there are some lovely ( …to a hydrologist 🙂 ) event records peppered throughout, but the real prize is the baseline data that you only get from multi-year deployments. From the builders perspective, those long records also give me a sense of the inter-unit consistency, which is looking good despite substantial changes to the loggers over time. As the project matures, more of my time is being dedicated to sensor calibration and normalization.
Though we rarely have enough visibility to capture it with our little point&shoot camera, the underwater procedures are getting smoother too:
At ~6000 unique IP’s a month, traffic continues to grow, though I will have to manage more than one post per month if the project is ever going to be a real contender for science geek fame. The UNO logger has now passed the RTC post in the daily rankings, which shows that the number of interested beginners is also increasing. The US dominates the overall traffic at (with about 50% of the total), and Germany leads the European traffic, often coming in second only to the US. If other DIY sites are seeing a similar trend, then I think it’s pretty obvious why Germany continues to be the economic powerhouse of Europe.
Many years ago I did a short stint as a high school science teacher and some of my good friends are still in the trenches. Conversations with them often highlight two things: How their job now depends on standardized test results (so they don’t have much room to change the curriculum), and that resource budgets are shrinking to zero. These are dedicated people who are more than willing to go the extra mile if they can get their hands on the right material. So I’ve been working to expand the online tutorials into a set that would help a teacher add Arduino based lessons to their curriculum, even if they have do it out of their own pocket:
- Build your own Arduino classroom
- Arduino UNO Logger for Beginners
- Using the UNO for Data Acquisition
- ProMini based Data Logger (update)
I’m sure that most people missed the significance of the DAQ post when it came out, but in terms of teaching it’s probably the most important one in the set. The IDE’s new plotting function makes it easy to do live demonstrations in front of a classroom simply by adding one print statement to the code: nothing I’ve tried before even comes close to this level of simplicity.
I use my ‘UNO-scope’ all the time now because I can do a quick screen capture or I can send a series of runs to a serial text monitor. In both cases, calculations can be done on the Arduino before the output is sent, converting the raw ADC readings into something more meaningful like current or power. Then I can go hunting for unexpected events by graphing it up in Excel. This approach has let me track down things like SDcard weirdness that are very hard to capture during normal logger operation because they only happen when you pass some threshold inside the flash controller:
I’ve overlaid the bold numbers, but that’s a screen capture of the IDE output. Modern scopes can do this kind of thing too, but you’ll be hard pressed to find one for the price of an Arduino clone on eBay. With a low value shunt resistor, you can push the ADC clock pre-scalars into the 20-40kHz range, which is more than adequate for the kind of diagnostic work I’m doing, and most stuff you’d be trying to demonstrate in a high school physics class.
I will add more tutorials to that set over time, and hopefully we’ll manage to publish a paper or two this year. The plan is to put them in open source journals so everyone in the world has access, and if we spin up all the collaborative projects we’ve been planning with other researchers, 2017 promises to be a very busy year.
2016 was also a banner year for the Maker movement in terms of media coverage. So I thought I would add selection of those articles here:
3D printers are finally reaching a price point where people can afford one to help them pursue other more interesting hobbies, and as key patents continue to expire, new/old high-end tools are entering the consumer market: Forget 3D-Printed Knick-Knacks. But it’s worth noting I haven’t used any of these tools on the project because I can still build more durable housings out of plumbing fittings from the local hardware store. Total part cost on those is ~$15, and I probably spend less time making them than I would repairing holes or fixing mesh errors on a constantly evolving 3D printed version. But I’m sure the strength and print quality tipping point will occur eventually… probably when DLP’s with stronger resins reach the kind of price point we are currently seeing for extrusion printers.
Sometimes those geeky editorials make me laugh, but even then they are still thought provoking. It’s also good to see more thoughtful criticism and self reflection going on as the movement matures it’s way through the Hype Cycle (beautifully illustrated by this 100+ year old debate about the Wright brother’s)
Unfortunately that also means the market has grown to the point that the big boys want a piece of the action. While this probably won’t be another “Embrace, Extend & Extinguish” situation, commercial players inevitably increase the pressure to commoditize the product into easier to use (& thus more sellable) packages. I can see good arguments to support this but I have some concern about developments (like the ESLOV) which eliminate the user’s exposure to actual code: turning great problem-based learning exercises into plug & play activities. Unless you let students see ‘under the hood’, they’ll walk away thinking technology is about connecting little black boxes for participation marks. By now it’s clear that we are heading toward a IoT powered world of self driving cars, Baxter bots, and staffless stores. So I can’t help thinking that unless our young people can handle Arduino level programming tasks, they won’t qualify for a job making toast.