Tuesday, June 25, 2019

Dead Solar Panel

A couple of days ago I discovered that the solar panel was not working. The day before that, the solar charging data had indicated that it was only charging the battery for a few hours near noon, and usually it charges the battery whenever the sun is out. Opening the waterproof case for the charge controller revealed that the Velcro backing on the controller had come loose and the controller was resting face down on the other equipment in the box. I don't think that anything had shorted out, and the controller still appeared to be working correctly, although there was no output from the panel. Solar panels are capable of operating with a short circuit between their outputs, it's actually a rating that they are specified for: "short-circuit current". So I'm not exactly sure what happened. I contacted the panel vendor to see about replacement, but have not heard back yet.

Up until now, I have been using my iPhone in AMOS as a hotspot, whenever cell connectivity was required. It never actually worked very well. Even though my phone was right inside AMOS, it would often drop the connection, requiring a reset of either the phone or AMOS to get re-established. So last week I bought the Huawei LTE E8372 Hotspot Turbo Stick: https://www.thesource.ca/en-ca/cell-phones/portable-internet/huawei-lte-e8372-hotspot-turbo-stick/p/108036412 I was able to use the same 100 MBytes data plan that I had for the Android phone. So far I have just done some limited testing with it, but it seems to work well. It's also pretty small and plugs into one of the available USB charging ports on the charge controller. I'll have to try it out in an actual field test soon.

The turbidity sensor enclosure is coming along, but so far isn't quite 100% waterproof. The weak point now is near the top, where the cable enters the housing. I hung an old lawnmower spark plug from the bottom of it to weigh it down and make it more vertical in the water, and by taking up some of the slack in the electrical cable I can keep the top end from getting immersed in the water. It's not ideal, but might work OK for now.

Software-wise, things are coming along also. I modified the startup code to make sure that a GPS fix is acquired prior to saving sensor data. Previously, AMOS would wake-up from sleep mode to collect data, but GPS data was not always available before the sensor data was collected. I also added code for better handling the low battery condition. Now if the battery voltage dips below 11.3 V an alarm can be sent via email and / or text, and AMOS goes into low power mode for an hour, in the hope that some exposure to sunlight will give it some more charge.






Tuesday, June 18, 2019

Sensor Deployment Arm

An armature for deploying sensor probes into the water was added to AMOS this week. It was basically the simplest design that I could think of; a lever arm connected to a servo motor that swings back and forth with the sensor probe cables attached to it. When swung toward the water, it pulls the probes into the water to deploy them. When swung back in the opposite direction, it pulls the probes back onto the stern deck.The probes are not overly heavy so I didn't bother with any strain relief for the electrical cables. My home-made turbidity probe is possibly a bit too buoyant, so I may need to add a bit of mass to it.

Here is a video of the armature in action in our pool today:


The first time I tried it out in the pool a couple of days ago, I noticed that the turbidity probe output changed drastically by almost 50% after a few minutes of being deployed in the water, and that the probe had settled lower down into the water. Unfortunately the enclosure had flooded with water. After taking it out, emptying out the water, and studying it for a bit, the most obvious source of water intrusion were a pair of fastenings on the underside of the shell. Here is a photo of one of the fastenings:


I built the turbidity shell last year, and I think I must have been planning on filling the holes with some molten 3D printer filament, but never got around to it. So last night I held the probe upside-down under my 3D printer nozzle, turned on the heat, and then manually fed the printer filament through the nozzle so that it dripped down into the hole, filling it up completely. I then smoothed it out later with a heat gun and my finger (hot ouch!).


The blue printer filament sort of looks like a wad of gum. I'm hoping it will be more water-tight than that though. Tomorrow I'll let it sit in the pool for a while to see what happens. If it doesn't work, I'll try 3D printing a new shell without through holes for the fastenings.

Tuesday, June 11, 2019

Showing AMOS Around Town

This past week was a busy one for AMOS. In preparation for the Fredericton e-Hack event on Monday, I spent some time looking up info on LoRaWAN wireless radio kits and map-based GIS (Geographic Information Systems). Here is a link to a map that I made from the Woolastook grid test: https://arcg.is/01C8Gu.

On Saturday, the sun was bright and shining, and I took AMOS back to the same parking lot near the walking bridge, this time just going directly downriver to collect some temperature samples around the mouth of the Nashwaak River. I was able to try out my new $20 anemometer, which told me that the wind was coming out of the north at ~ 15 km/hr on average, with occasional gusts close to 30 km/hr. The current also seemed pretty strong with a lot of waves. AMOS was still able to make forward progress (albeit slow) against the current and wind when it needed to. Unfortunately, the temperature probe did not work for this test, I think because I had melted part of the probe cable's insulation with a soldering iron the night before. It didn't look like the damage was too bad, but I'm guessing that water must have leaked in, because after AMOS got back home and dried out the probe worked fine. Anyway, I made a cool GIS graph with the temperature from inside the electronics enclosure instead:


On Sunday, I took AMOS to the Fredericton e-Hack event at Planet Hatch. Eleven-X and some other organizations were there as sponsors, and LoRaWAN radio kits were distributed to the participants. There were quite a few people there, and most of them went to the event as teams. Anyone at the event could pitch an idea to the assembly of people and then the top 6 ideas were chosen based on a voting system. I pitched the idea of AMOS, along with a simplified version of AMOS connected to a buoy or retrofitted to a boat. I think about 10 people in total pitched ideas, and AMOS barely made it in at 6th place. Then teams were formed for the 6 ideas, and we got to work trying to figure out the wireless kits and get some sort of rough prototype and presentation together. Here's a selfie of team AMOS:

 Unfortunately, nobody was able to get their LoRaWAN wireless kit working. That was the part that I was looking forward to hacking, so that was a bit of a disappointment. We spent the remainder of the time trying to throw together a PowerPoint for the final presentation. As my children will tell you, my PowerPoint skills are very poor, so the presentation didn't look as good as those of other teams, but I thought that the actual content was OK. We didn't place in the top 3, so no prizes were won. :-( However, we did get to meet Mike O'Brien, the mayor of Fredericton and spent a few minutes talking to him about AMOS. I also spoke briefly with a CBC reporter, but so far I haven't been able to find any footage of that.

Today I attended the Canadian Export Challenge at the convention center in Fredericton. There were probably a couple hundred people at this one, and I recognized a lot of the same people from the e-Hack event there. You could do a one minute pitch at this event, and the top 20 pitches were selected to go on to the second of three rounds. AMOS didn't get to the next round, but I did get some useful tips about shipping and exporting, such as: try to get the size of AMOS (and its packaging) down to less than 8 feet long, since that is the standard maximum length that most shippers will handle before things get much more difficult. It was also interesting to hear the stories and advice that the panelists had, and meet some of the other attendees.

Tomorrow I'm looking forward to a return to hardware development. I want to get a deployment arm mechanism in place at the back of the boat for deploying sensors into and out of the water.


Tuesday, June 4, 2019

Sensor Grid Trials

AMOS has been programmed to accept a pair of diagonally opposing GPS coordinates that define a rectangular area for collecting sensor data. It also requires the user to specify how many stops to make in the N-S direction over the grid, and how many stops to make in the E-W direction over the grid, and how many samples to collect at each stop. For example, the following script command:

grid_sample: 45.878336, -66.909070, 45.876592, -66.906151, 5, 5, 10

tells AMOS to make 25 stops (5 in the N-S direction by 5 in the E-W direction) down to the opposite corner at 45.876592, -66.906151. Here is what it looked like with the path to and from and all the sampling stops drawn on a Google Earth view:


The whole thing took a little over an hour to complete, and since the day was overcast and a bit rainy, the battery was nearly fully depleted. I had hoped that the water closer to the inlet of the small cove would be warmer and would make for a nice color map, but alas no. The water temperature was quite uniform throughout, either 14.06, 14.12, or 14.19 deg C everywhere. I don't have the turbidity or pH probes hooked up yet; I'm waiting until I finish building a mechanism for deploying them into the water so that they don't create excess drag when moving around. Here is a graphical representation of the temperatures collected, expressed as a bubble chart in Excel:



Today I tried to repeat the sensor grid test at a location more likely to show some sort of temperature gradient. The goal was to launch AMOS from a parking lot about 1 km north of where the Nashwaaksis River empties into the St. John River. I set up the GPS waypoints in a script file the night before with the intention that AMOS would first travel west about 100 m into the St. John River, then 1 km south where it would do two separate grid patterns around the end of the Nashwaaksis River. Both the wind and the current seemed really strong this morning, with the current running from north to south and the wind probably in excess of 30 km/hour (Andrew, I just bought an anemometer from Amazon so should have better data on that soon!) coming from the northwest. Poor AMOS didn't stand a chance. It struggled gamely for a little over an hour, before its battery quit and the wind quickly pushed it back to shore. I probably should have edited the script to just skip the first waypoint and proceed south instead but part of me kind of enjoyed standing there watching it struggle. At one point when the wind died down a bit it looked like it would almost make it, but in reality it was still pretty far off:




As this is a more populous spot than my usual Woolastook testing ground, there were a few curious onlookers that asked questions about it. Next time I'll have to bring my wallet with its home-made business cards 😃.

I really like the name AMOS, but I'm thinking of changing what the acronym stands for. Instead of "Autonomous Mini Ocean Surveyor", I'm thinking that "Acquatic Mini Observation System" might be more accurate, as it is not really an oceangoing vessel, unless perhaps you're talking about using it in the doldrums around the equator.

It turns out that I was not properly using the real-time clock that I had hooked up to AMOS a couple of months ago. It needed this line at the start of the /etc/rc.local file:

sudo hwclock -s

I had noticed that the ship log times were always wrong after a cold boot in the field without any available Internet, and that missing line was the reason why. AMOS might take a while to reach its destination against a stiff breeze, but at least it now knows exactly how late it is.