### Backstory The [original](https://rem-blog.fly.dev/article/4) water tank monitoring and refill system has been working non stop for about 11 months at this point. The only issue that cropped up was that the LCD display would dim quite substantially when the relay is enabled to turn on the bore hole pump which made the screen basically unreadable while the tank was being filled. I guess this was due to the relay being powered by the Arduino directly instead of a via a separate power supply to keep the Arduino's supply clean, a problem I corrected in this second version. I could have simply improved the original design but I wanted to make the system wireless as originally planned with the first version, but I went with RS485 instead as the wireless transceivers I had back then did not perform well enough when line of site was not possible. This second version would be using LoRa for wireless communication, and be solar powered. ### Initial development I wanted to make the second version considerably more flexible than the first version by enabling one control unit to manage multiple sensor and relay units, and enable the customer to pair and link as many tanks and relays are they need. Rather than going with Arduinos again I opted for Raspberry Pi Picos. Normal Picos in the sensor and relay units and a Pico W in the control unit to enable Bluetooth and WiFi capabilities. Bluetooth to be used during setup by pairing one's mobile phone to the control unit and WiFi used to monitor the water levels and pump states from anywhere. I still wanted to use the Arduino framework though and thankfully [Arduino Pico](https://arduino-pico.readthedocs.io/en/latest/) exists. Unfortunately I found working with this core to be extremely clunky, the Picos constantly disconnected from my PC after flashing code to it and it was driving me insane. That and the Core's bluetooth stack being in Alpha led me to violently contemplate using the Pico's native C++ SDK, which I did. ### The Pico's C++ SDK and porting Arduino Code One drawback with using the Pico's native C/C++ SDK is that it has very few libraries written for it, which actually turned out to be quite the enjoyable problem as I leaned a lot by porting Sandeep Mistry's [LoRa library](https://github.com/sandeepmistry/arduino-LoRa) and Adafruit's [SH110X library](https://github.com/adafruit/Adafruit_SH110x) to it. The ported versions available [here](https://github.com/Reghardt/Pi-Pico-SDK-LoRa) and [here](https://github.com/Reghardt/Pi-Pico-SDK-Adafruit-SH110x). Overall I found the Pico's SDK to be very well though out and a joy to use. The only headache was getting the Pico up and running which eventually led me to the debugprobe approach, which can be seen [here](https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf) on page 20. That and getting the debugger working on Manjaro was something of a challenge, which I will write a blog post about in the future. ### JSON over LoRa and for persistent storage The use of JSON was spurred by the idea that a user can connect to the control unit over Bluetooth from a website running on their phone to simplify setting up sensor and relay units. This website did not materialise as of yet but it greatly influenced the system in other ways that turned out to beneficial. Since this hypothetical setup website would be written in JS, JSON would probably be used to send and receive data over Bluetooth, unless a custom transmission format was to be written, which usually is not wise. So if Bluetooth communication was to be using JSON, in what format will configuration data be stored on the Pico? Well, why transform JSON to and from some other format on the Pico? So it was decided to use JSON on the pico aswell. I wrote a separate blog article about persistent store on the pico [here](https://rem-blog.fly.dev/article/11). A similar argument could be made for data transmission over LoRa, why use some other format when JSON is already used on the Pico? So JSON throughout, and that is how JavaScript will take over the world. ### Nlohmann's JSON library The library I chose to enable using JSON on the Pico is [this](https://github.com/nlohmann/json) one by Nlohmann, a magnificent and astonishingly capable library that must have took many, many man hours to complete. One interesting capability of the library is the support of many binary JSON formats, the only one I was semi familiar with was BSON, developed and used by MongoDB. The benefit of using a binary format is that it reduces JSON's footprint, that could be during data storage or transmission. Now instead of sending a full, fat JSON object over LoRa I can first turn it into a binary format reducing it's size, transmit it and turn it back into regular JSON on the receiving end. The benefit is that if a packet has a smaller size it has less of a change to be corrupted during transmission. Testing this I did indeed observe some improvement and less dropped packets, although I don't have any numbers on this. ### Building the system Description

I started of by experimenting with the LoRa transceivers, the ones I am using are 868Mhz Hope RFM95W units. There are lots of settings that can be configured to get the best performance out of these units. Description

Here I am testing the SNR and RSSI values on the receiver's end. These values can be used to determine the strength and quality of a transmission. Description

Next up was testing the units on solar power. I am using the CN3791 MPPT Solar Charger with a 2000MAh battery. With the ultrasonic sensor taking a reading every second the unit easily made it though the night on battery power. Description

I used JLCPCB to print the circuit boards that I designed. All units share the same circuit board design no matter if it is a control, sensor or relay unit. Description

The Control unit has an additional PCB for the screen and buttons. The buttons don't look very professional though but that will be improved in the next version. Description

I decided to attend a farmers market in Hoedspruit to get some feedback on the system so for that I had to be able to demo the system. I built a model representing a water tank with acrylic bought from [Plastic World](https://plasticworld.co.za/). Description

Here I added some supports on the bottom to strengthen the tube. I used Methylene Chloride to glue the acrylic together and to form a watertight bond. Methylene Chloride is some really nasty stuff, the warnings on the bottle makes it hard not to be cautious while using it. Description

This was my stall at the farmer's market. I was a bit late so I didn't get a great spot. I bought a 12V water pump and powered everything with a 12V battery. Notice the ultrasonic sensor in the op of the pipe. I had some mysterious issues while at the market. The sensor was returning seemingly random readings. I later realised that this was due to small particles sticking to the inside of the acrylic tube at about the 3/4 mark, this was acrylic shavings from boring the water outlet/inlet at the bottom. I left the tube 3/4 full of water the previous night to test the water tightness... Description

My view from my stall. I very much enjoyed the experience and met some great people. There was a bunch of people that was interested in buying it when it is done. I did hear about some interesting potential use cases and additions I could make. Description

Me at the market with my creation. I didn't get much sleep the previous night. Description

Back home after the market I started replacing the old wired version with the new one to test it out over a longer period of time. Description

A good friend of mine printed the enclosure. The enclosure was designed in a hurry to be ready for the market, the final one will be much better. Description

A non blurry close up. The buttons correspond to the icons or text above them. The new version calculates the amount of water in litres available in the tank. There are some configurable options like sensor height, water depth, tank radius, fill when and stop at levels. Description

This is the sensor unit. The enclosure has 2 holes, one for the solar panel's wires and one for the ultrasonic sensor. I did not photograph the ultrasonic sensor's outlet as the waterproofing is way to sloppy. I will be improved. Description

Here the unit is placed on the top of the tank. The sensor's wire is a bit long in this incarnation. The wire can be seen again just to the side of the lid running into it, in which the sensor is mounted. ### Conclusion Building the system was immense fun and I leaned a ton. It is still quite a distance from being a viable commercial product but it will be edging closer over time. The biggest remaining work is getting WiFi and Bluetooth to work, and to get the control unit to talk to a mobile phone to allow easy setup and more advanced configurations. Apart from that some code needs refactoring and the containers of both the sensor and control unit needs redesigning. In this specific case the control unit acted as the relay unit as well due to controlling the bore hole pump, so enabling the control unit to control separate relay units are also on the drawing board. ### The code I haven't made the code public yet, I will see where the project goes, but I am more than willing to show it on request.

Reghardt's Blog

Wireless water tank monitoring and refill system - V2 + Attending a farmers market