Beyond Essence of Irrigation - Part 2 - "LoRa flavor"

Beyond Essence of Thor - Part 2

Reliable, cheap, extensible, modular, distributed irrigation control. This builds on Part 1 adding LoRa Radio to the mix.

Before we start let me just straighten one thing out. This is using raw LoRa PHYS not LoRaWAN. So the program(s) are handling all the reporting and collision avoidance ish.

So, I was asked by neighbors and friends to implement a version that can also handle LoRa as the comms link between controllers so valves can be slaved at extended distances. In fact, one person actually turned up with a couple of boards from Lillygo (TTGO) to program so that sorta clinched it, the game was on.

So at this point in history the irrigation controller software is capable of email reporting and many other new things but it was only deployed on ESP8266. The ESP32 version existed but had not fired a shot in anger yet. This meant getting all the additions and fixes on the old system into the new one. No small task as it also involved changing a lot of the web stuff to make it run smoother and faster.

WiFi is a lot more "civilized" than LoRa which means link monitoring for the LoRa is a must and this system delivers. You will get an email if a node that was on-line goes offline. This is not quite as good as the I2C bus monitoring but it will do as a first cut.

Update to local I/O mapping

In spite of building a dozen or so irrigation controller prototypes I'm yet to build one that is deployed with purely Local(CPU) I/O driving the valves.

So, I've updated this code and added bullet guards on the toes. The web interface won't let you select local I/O actually used by the TTGO board hardware. So when you map a board to local I/O you should be right to go hard but not kill any hardware by an invalid selection. It even checks whats stored in memory just in case bytes get changed in an upgrade. The ESP32 gives more choices of pins but the LoRa radio and OLED quickly take their toll on the pin count.

The Uplink/Slaving of valves works via either LoRa or WiFi. So you can use a non LoRa board and it all works fine or you can use a long range option. The WiFi option has been in use for over a year now.

Using this method means local fertigation pumps or valves can be deployed at slave valve sites as the remote node has all the functionality of the master.

Power Management

How to reduce power utilization? Obvious, Put it all to sleep? Except it has a job to do. The memory is packet full of data to achieve this, so if you puts it to sleep you loose the memory.

So status. We have turned off the WiFi and like YAY 50%+ power saving, good start. Now CPU power usage is roughly proportional to clock speed and we are normally running at 240 MHz from a 26MHz clock, one suspects a phase locked loop is involved and these usually express multiple frequency "tappings". So what happens if you simply take the foot of the accelerator and let the CPU idle along? You get a really massive order of magnetite power drop. Now we in business! 50% saving with wifi off and an OOM for lower cpu frequency. What could go wrong ?

Crash Core 1, OK why ? Observations - Only happens when doing WiFi things. So the solution crude as it is, don't drop the CPU frequency unless wifi is off. This yielded a reliable system that was still operating between 10 and 20 ma at 80 MHz. You can go harder and drop to 26 Mhz or fingers crossed 13 Mhz. Obviously you need to do the reverse before the WiFi wakes up otherwise it ends badly. Speaking of user interface, there is a button and timer that allow the system to automatically switch off the WiFi after power up or to wake it up from it's peaceful slumber. The display can be linked to this and is an obvious reminder of the WiFi state but it gets confusing if display on and WiFi off. So the ubiquitous blue ESP led blinks at a different rate when WiFI goes to sleep so you can tell at glance whats going on regardless of the state of the display.

Even at slow clock speeds the irrigation software component still executes in an acceptable cycle time. So a leaf out of Neo's book, change the speed of time and solve the problem.

IT's BIG ! - No really, it's too big to fit in the only option of TTGO board.

TTGO didn't include any partition options with the board definitions as downloaded in the Arduino IDE. But as pointed out online by many people you can add your own which I have done. I simply copied ones for another esp32 based board and pasted them in for the TTGO board area renaming the bits so it all looked "about right".

ttgo-lora32-v1.menu.PartitionScheme.minimal=Minimal (1.3MB APP/700KB SPIFFS)
ttgo-lora32-v1.menu.PartitionScheme.minimal.build.partitions=minimal
ttgo-lora32-v1.menu.PartitionScheme.min_spiffs=Minimal SPIFFS (1.9MB APP with OTA/190KB SPIFFS)
ttgo-lora32-v1.menu.PartitionScheme.min_spiffs.build.partitions=min_spiffs
ttgo-lora32-v1.menu.PartitionScheme.min_spiffs.upload.maximum_size=1966080