IoT water tank telemetry project – part 4

After a long hiatus… the project activity resumes.

Boxing is underway, and the code has been revised to use a BME280 sensor replacing the DHT sensor. The BME280 is a better sensor (less jitter), and is also capable of barometric pressure if that is of interest.

Experience has been that 18650 cells do not last when exposed to extreme temperatures in solar powered modules like this, so a single cell pouch 2000mAh LiPo will be used (as in the battery trials).

The code has been refactored to make measurements before starting the WiFi as WiFi activity injects noise into the ESP8266 ADC.

The nodemcu core was updated as part of this process.

Interpolation

The system is easy to calibrate in terms of stored water volume for containers with vertical sides where the change in volume with level is uniform… but there are lots of applications where that is not true, natural dams for example.

Above is a plot of volume versus depth of water for a container like a spherical bowl. The interpolation line is a cubic spline interpolation based on the six input data points, it is of course a very good fit to those points but would appear to be a good estimator of the regions between.

The code now contains a facility to perform a cubic spline interpolation of a small number of data points over the expected range of depths.

Entry{0.000,0.000}
Entry{1.000,313.112}
Entry{2.100,1375.744}
Entry{3.000,2799.159}
Entry{4.000,4959.528}
Entry{5.000,7723.082}

Above, a set of six points (as in the chart) in the format required of the code in a file named dam.xy.

The code calculates and stores an intermediate data file <name>.cstable if it does not exist for more rapid calculation. If the .xy file is updated, the corresponding .cstable file needs to be deleted.

The init.lua file is augmented to call a transform function from the httpreq function which customises the HTTP request.

function transform()
  dofile("csinterp.lua")
  if level<0 then level=0 end
  volume=csinterpolate("dam",level)/1000
  volume=string.format(meas_fmt,volume)
  print("Volume: ",volume)
end

function httpreq() 
--  req=rest_url.."?api_key="..apikey.."&field1="..level.."&field2="..temperature.."&field3="..humidity
  transform()
  req=rest_url.."?api_key="..apikey.."&field1="..volume.."&field2="..temperature.."&field3="..humidity
  body=""
  print("req:"..req.."\nbody:"..body)
  return req,body
end

Above, the transform function fetches the function definitions for the cubic spline interpolation, and calculates an interpolated volume from the measured level (or depth) value.

Above is a trial run using a calibration generator for the level input, and its conversion to current volume of the storage.

Hardware

One of the possible paths this project might follow was to use LoraWan… but experience with LoraWan has not been positive, particularly issues with the Laird gateway.

Above is the enclosure, an electrical box with transparent lid. The PV array is mounted inside the lid, the cheap Chinese ones tend to degrade too quickly when exposed to the elements. There is room in the box for a 2000mAh 1S Lipo battery. The switching circuit for the 24V DC-DC converter is mostly on the Veroboard under the (red) DC-DC converter (powers the 4-20mA loop). The module at lower left is a 1S battery management / protection board.

The resistor diagonally across the Wemos module is the 4-20mA sense resistor wired from A0 to ground. Experience is that locating the resistor on-board reduces the errors due to variable contact resistance through the module header pins.

If temperature / humidity monitoring is desired, a BME280 module plugs into the header near the antenna, but it needs to be remote from the box which gets quite hot in the direct sun.

The implementation supports easy development and update, if the battery and solar cell are disconnected, plugging a computer into the USB port on the Wemos board allows update and normal operation / testing.

ESP32 WROOM32 – A possible fix for failure of auto-program facility

Espressif’s esptool has a facility to automatically put the ESP32 into bootloader mode using the DTR and RTS signals of the serial interface.

For whatever reason, it is very unreliable. There are many schematics of knockoffs of Espressif’s original DevKits.

Above is the schematic of one of the larger makers of ESP32 modules, AI-Thinker. The auto-program facility is implemented in the logic gate arrangement at right top of the left top block. Continue reading ESP32 WROOM32 – A possible fix for failure of auto-program facility

ISP adapter for Arduino Pro Mini / Pro Micro

I have started using Arduino Pro Micros recently, and sourced inexpensive clones from China.

Experience is that all manner of inexpensive small microcontroller modules from China are likely to have issues with the bootloader: it isn’t there, it is back level, not suited to the actual clock speed.

I have come to routinely install a current / known / working bootloader to avoid wasting time down the track.

The Pro Micro does not have an ISP header, and the QFN package does not suit a chip adapter, so the next option is an adapter that can connect to the board with no pins, male or female headers, top or bottom.

Above is an adapter built on a small piece of Veroboard. If you are ging to copy it, make it one row of holes higher. I did initially, and in a miscount of rows, I incorrectly removed the top row. The black mark identifies the pin 1 of the Pro Micro, and the adapter connects to the side with the /RST pin.

 

The headers on the adapter engage JP6, preserving the pin ordering, pin 1 to the black mark on the veroboard.

Continue reading ISP adapter for Arduino Pro Mini / Pro Micro

IoT – exploration of LoRa – part 3

This series documents a set of experiments to explore LoRa for a telemetry application. Note this is simple multipoint to point LoRa, it does not use LoRaWAN.

IoT – exploration of LoRa – part 1 outlined a simple direct RESTful submission to Thingspeak from the LoRa – Wifi gateway.

IoT – exploration of LoRa – part 2 outlined a simple RESTful submission to Node-Red from the LoRa – Wifi gateway.

This article describes a direct MQTT submission from the gateway. In this case the gateway converts the binary LoRa payload into more friendly MQTT key,value pairs.

The block diagram above shows the information flow between the main elements. Continue reading IoT – exploration of LoRa – part 3

IoT – exploration of LoRa – part 2

This series documents a set of experiments to explore LoRa for a telemetry application. Note this is simple multipoint to point LoRa, it does not use LoRaWAN.

IoT – exploration of LoRa – part 1 outlined a simple direct RESTful submission to Thingspeak from the LoRa – Wifi gateway.

This article introduces an intermediate flexible and extensible Node-Red flow.

The block diagram above shows the information flow between the main elements. Continue reading IoT – exploration of LoRa – part 2

Arduino SAMD21 bootloader protection II

At IoT – exploration of LoRaWAN – part 2 I reported some quality issues with two low cost SAMD21 Arduino Zero like boards, and at Arduino SAMD21 bootloader protection some related discussion.

In view of continuing experience of incorrectly programmed low cost SAMD21 boards, I have decided to re-flash them as a matter of course

Above is one of the culprit boards. Continue reading Arduino SAMD21 bootloader protection II

Arduino SAMD21 bootloader protection

At IoT – exploration of LoRaWAN – part 2 I reported some quality issues with two low cost SAMD21 Arduino Zero like boards.

In both cases, the bootloader did not work. I did not investigate further but did note that the NVM user row looked like it had been cleared, but just wrote a new bootloader and restored a default user row with protection for the 8192 length bootloader.

Above is one of the culprit boards. Continue reading Arduino SAMD21 bootloader protection