0.33.0 release testing

I’ve merged it to my fork, so it’s the baseline, and I’ve been testing it over the weekend.
The configuration is Mayfly1.1, using the new onboard Sensirion SHT4x Humidity and Temperature sensors and an Insitu LT500/Modbus running at 19200baud.

Its an accelerated test setup with readings taken every two minutes, and then pushed to setup
https://monitormywatershed.org/sites/update/tu_rc_test08/sensors/
It’s been working well for a reported number of 1193 readings, or 12.4 days of equivalent time in 15minute readings
Though on the MMW visualization, which was been up for some time, the sparkline plots for the Sensiron SHT4 Humidity and Temperature are not being updated for Last Observation time, but all the other sparkline plots with valid data are reporting the “Last Observation” time.

Something to note, and it’s a bit challenging for me, is that I’m pretty much used up the program memory “Flash” space
My build for the 0.33.0 with LT5/Modbus
RAM: [===== ] 51.4% (used 8421 bytes from 16384 bytes)
Flash: [========= ] 91.0% (used 118354 bytes from 130048 bytes)

C++ language has come from programming large systems, where the growth in processor and disk space has expanded fast enough to cope with “C++ Bloat”.
Small systems though are resource constrained, and I’m hitting the limits of the code space for the mega1284, though interesting enough the ram is  growing slowly.

For a comparison I built the standard 0.33.0 releases with platformIO, which has all the advanced code optimization options turned on.
examples\DRWI_Mayfly1
RAM: [=== ] 30.1% (used 4935 bytes from 16384 bytes)
Flash: [====== ] 61.6% (used 80158 bytes from 130048 bytes)
However when building the standard examples\menu_a_la_carte it failed
Compiling .pio\build\mayfly\libf17\SdFat\ExFatLib\ExFatVolume.cpp.o
D:/usr/a/Documents/Arduino/enviroDIY/ModularSensors/examples/menu_a_la_carte/menu_a_la_carte.ino:48:10: fatal error: ModularSensors.h: No such file or directory

Looking at my previous builds, I have been adding features, and I haven’t yet decoded features to program space, but I’m pretty much hit the mega1284 processor limit by adding usability features.
The features I’ve enhanced are
– Increased the Modbus baud to 19200 – and actually saved space here by removing debugging text.
– customization of MMW UUIDs with a ms_cfg.ini file ~ this does take a lot text
– reliable delivery to MMW with standard protocol configuration in ms_cfg.ini
– selection of wireless radios and radio configuration from ms_cfg.ini
– enhanced sensor reporting to the log file – which has some virtual functions, and these may be pushing up the flash useage

For 0.33.0 I have a combined Acculevel/Modbus and LT500/SDI12 interface, with also a combined wireless of Digi LTE and WiFi – it selects which to use on startup, as well as detects if its Mayfly 0.5b or Mayfly1.1 series

**** Build with src\ms_cfg.h_LT5KA_wireless ****
RAM: [===== ] 53.7% (used 8796 bytes from 16384 bytes)
Flash: [==========] 96.8% (used 125852 bytes from 130048 bytes)

I’ve setup a system where I capture the build sizes, and this is the list of increases for my build with the most features
**** Build with src\ms_cfg.h_LT5KA_wireless ****
For 0.32.3 based
RAM: [===== ] 53.7% (used 8796 bytes from 16384 bytes)
Flash: [==========] 96.8% (used 125852 bytes from 130048 bytes)

For 0.30.0 (2021 Aug 31)
RAM: [====== ] 57.0% (used 9340 bytes from 16384 bytes)
Flash: [======== ] 82.7% (used 107502 bytes from 130048 bytes)

For 0.28.5 (2021 July 3)
RAM: [====== ] 57.5% (used 9426 bytes from 16384 bytes)
Flash: [======== ] 83.4% (used 108502 bytes from 130048 bytes)

For 0.28.3 (2021 April 8)
These builds are Insitu LT500/SDI-12 with LTE
**** Build with src\ms_cfg.h_LT5_lte ****
RAM: [====== ] 58.5% (used 9577 bytes from 16384 bytes)
Flash: [======== ] 81.6% (used 106180 bytes from 130048 bytes)

For 0_27_5 (2021 Feb 3)
**** Build with src\ms_cfg.h_LT5_lte ****
RAM: [===== ] 46.7% (used 7648 bytes from 16384 bytes)
Flash: [======== ] 77.4% (used 100604 bytes from 130048 bytes)

The advantage of having defined builds with a .hex output is reliability and ease of installation– its easier to test one configuration, and have confidence it can scale to a number of systems, and supply the systems to the field experts for installation. However, when the program space runs out, it becomes a lot more time consuming to manage the features. Oh Well.

I wonder if anybody else is running out of space.?