Hi @btrue, this isn’t something I’ve looked into, so not sure about external ones.
Are you thinking this would get lowered from a boat at regular intervals (e.g. to measure temperatures throughout the water column, in multiple locations), or deployed to the lake bottom and collected later? Is the idea to get live data from the surface, or is it fine for the sensor to collect data that you then extract once the sensor is retrieved?
You should be able to do this with a 2" enclosure + Bar100 (or Bar30 if you’re able to dry it out fully at least once per day, and are ok with the lower accuracy). Control-wise you could use
a Raspberry Pi Zero
may be hard to get at the moment
but can use Python library and store lots of data on an SD card
could use MicroPython, with some slight tweaks to our existing libraries (I can help with that)
has some built in persistent storage
You’d also need a battery (or few, depending on what type and how long it needs to operate between charges), or you could supply power from the surface with a small solar panel on a buoy or something, for longer term deployment with a bit of extra cost.
It’s definitely a “permanently” submerged project, and only retrieving it a couple times per year to save the data. The big benefit for the one I bought so far is that it was $250 for the kit that included the USB cable and then $200 per sensor after that. The downside is that the battery is advertised to not be replaceable and the memory is volatile. I figured that it would be a easy starting place.
I basically need something that will turn on about every 12/24 hours, log the depth and temperature, and then turn off or go into a low power mode. For a possible advanced feature, it might also be cool to use the USB camera to also take a year-long time lapse.
My big problem is that I have zero programming experience, so it would be a long and tedious project for me to try to figure it out. I’m fine following along with someone’s very detailed directions since I know that there have been people making temperature loggers with a Rasberry Pi and Python as an intro to programming project. I will do some more research and see if I can find one.
Hmm - actual long term remote deployments are tricky, particularly with respect to power usage. If you’re not planning to have some kind of buoy-based tethered solar panel it’s likely only possible to do this with either a very large and expensive battery, or a microcontroller with a very low power sleep mode. For reference a Raspberry Pi Zero has idle draw of ~0.4 W, so even a battery like our white 230 Wh lithium ion one would only be able to power that for 575 hours (~24 days), and that’s assuming complete battery usage, and that the ‘active’ power usage is negligible.
That cost seems hard to beat, especially given we sell our Bar100 for more than the “per sensor” cost there, and that doesn’t include a battery or housing or control/measurement electronics.
I suppose that makes some sense, since an unopenable device can be completely potted, and much more tightly integrated than modular components that need to be accessible, and have to work well for a variety of use-cases.
A camera adds quite a bit of complexity and power usage, given a microcontroller is sufficient for doing the basic depth sensor interfacing and logging. That said, it’s possible to use a microcontroller to handle power/sleep control of a separate Raspberry Pi, which could then handle the sensor stuff, in which case it wouldn’t be that much extra effort to add the software side of things for taking photos. Beyond software though, I’m not sure how much light there would be, especially at the deeper points, and it’s very possible you’d need some form of active anti-fouling system to allow the camera to see for long periods.
As someone with both programming and electronics development experience, that side of things seems (to me) to be less likely to cause issues than power supply and budget. Our sensors already have libraries available, and the additional code (and potentially circuit design work and component sourcing) to set up “sleep for a long time, then turn on, then repeat” should be relatively simple (and is something I could help with if it was being developed openly, since it could serve as a useful example of a less common way to use some of our equipment).
If you were interested in multiple measurements within a single water body this would potentially be a good task for a solar-powered autonomous surface vessel with a powered winch that can lower and raise a set of sensors (e.g. pressure + temperature + camera) at several locations each day, and possibly upload the data each day / week to avoid needing to store large amounts of it.
That would significantly help with the costs, because one vessel could do the work of several deployed sensors, and would mean the data can be worked with at regular intervals, while also providing some indication on if something has gone wrong.
I suppose another alternative is to use a buoy with an altimeter for depth sensing, a separate temperature sensor, and a solar panel for powering, in which case the battery, enclosure, and power saving requirements are potentially less strict, given it only needs enough power to turn on once during each day. That may require a GPS module or automatic tensioning system to account for or avoid drift, would be measuring surface temperature (which may not be super useful, and can potentially be determined at low resolutions by satellites), and still very quickly approaches your $500 cost ceiling.
Buoys would definitely be out of the question for my application since they would probably get quickly stolen in these public lakes. I even refuse to use a dive flag buoy when SCUBA diving even though it’s required by law, because the only thing it does is attract boats.
I didn’t think about the Reefnet recorder being completely potted. I was hoping that ‘not replaceable’ meant that the battery was just soldered on. I’m planning on testing/deploying one this weekend so I can let you know how it goes.
Hum! I know those Hobo logger and they are the most affordable for sure. You need to buy the communication device but the free software is enough.
I already tried to build a cheaper sensor with no luck. In fact waterproofing the thing including batteries etc is hard.
Make sure you take into account the depth range of the sensor. The bigger the range, the lower the precision. If your lake move by only 2-3 meter then you rather install a 0-5m range sensor at 4.5m depth. The depth under the sensor is fix . Of course if you need tempature at the bottom then you need to install the depth sensor deeper / or install a separate temperaure sensor without depth measurement. Onset also sell cheap temp sensor like these: Temp logger
I built the frames for the recorders, but I couldn’t deploy them as intended since my ROV was having a hard time streaming the video. I’m really starting to get tired of having to abort dives all of the time due to the persistent unreliability of the BlueROV2.
Thanks for looking into this for me. I really appreaciate it. I switched to another twisted pair and got it mostly working at least. The Ping360 PingViewer was a little delayed, but other than that it seemed fine.
Yes, I have been having networking issues intermittently most of the time I have had the ROV since October 2020. It’s very frustrating since it works perfectly sometimes, but other times it won’t work at all.
Maybe it’s a loose connection somewhere or a issue with the slip ring in the spool? I think a lot of it is just low transfer speeds. I don’t know enough about networking cabling right now to an in-depth examination, but I haven’t noticed any obvious bad connections or signal dropouts when I move it around.
Is that asking about my laptop, or the ROV computer? I was using a MSI gaming laptop, but I upgraded a couple months ago to a System76 Gazalle with an i7-11800H, 32 GB of RAM, and a RTX 3060 GPU.
I have the 150M tether with the standard spool.
I assume it’s a Pi 3B since I haven’t upgraded yet, and I haven’t upgraded to BlueOS yet
I don’t have access to the ROV right now, but I think my usual transfer speeds are like 30 MB/s if I remember it correctly.
I just have the 2 Ping sonars
Some sloppy piloting on my part, but I was also having a hard time seeing the screen since I didn’t have my blanket with me:
No worries - if our equipment isn’t working properly then it’s important to us to try to rectify that
That’s definitely positive, although I’m curious why the original pair was having issues. Do you know if your tether jacket is cut somewhere, that may have corroded the wires?
Hmm, possibly, although I don’t think I’ve heard of any issues with the slip ring before, so that at least doesn’t seem common.
It can be useful when troubleshooting a network problem to replace different parts of the setup (e.g. you could try running an ethernet cable directly from the onboard Raspberry Pi up to your computer / the ethernet to USB converter in the FXTI), but given the problem is intermittent that can be hard to determine whether something has helped or if it’s just working at that point in time.
Numerical network tests can sometimes be useful for determining whether something has helped, but it can be tricky to know whether “it’s better like this” also means “there is an issue in one of the swapped out components”, or if it’s just that the Fathom-X + tether setup has inherent bandwidth limitations compared to a short direct ethernet cable. Changing pairs is a good test, because it keeps the rest of the setup the same and just checks whether the tether itself is causing issues.
Yeah, I don’t imagine that would have any issues, unless QGC is having compatibility issues with the decoder. One thing to try is if issues arise again you can go to QGC’s Application Settings page and try changing the video decoder selection, in case that helps, but given the nature of the issue I don’t expect it’ll make a huge difference.
Is that just a “haven’t got around to it yet”, or is there something in particular you’re waiting for before changing over (noting that BlueOS works well with Raspberry Pi 3B + Pixhawk - it doesn’t require a Raspberry Pi 4 or Navigator)?
That doesn’t seem too bad, especially if the ping, ping360, and video stream are running while you’re testing that (the network test can only measure remaining bandwidth, above what’s already being used). If you unplug the camera and both sonars and you’re still getting 30 mbps then that’s probably a concern.
Practice (and good conditions ) make perfect. Thanks for sharing the deployment video - I hope the sensors work well!