-
Notifications
You must be signed in to change notification settings - Fork 1
1a Feature notes
-
Reliably Read sensors with a variety of industry interface protocols (RS485, I2C, Analog..) using local solar power (For SDI-12 I don't consider the base implementation very reliable).
-
Field deployable resources should be configurable where possible from data file, ms_cfg.ini.
-
Reliably deliver the readings to a cloud location over a variety of telemetry protocols.
3a. The telemetry should emulate a "walking boot net" - that is needs to be as reliable as "walking up" to a sensor with stored readings (eg Insitu LT500 stream gauge) and taking the readings off that device. -
Reliably Manage system resources gracefully. When there is a scarce resource, like solar (system power), manage the system reliably till when the resource is restored. Loss of solar is part of the environment, resources shall be prioritized to collect readings and deliver later if needed. For a loss of solar, such as an atmospheric storm this should be two weeks, and an objective is service loss of facility communications for two years.
-
The System needs to be testable and able to characterize essential subsystem. Any delivery of readings failure, needs to be discoverable, and identify it to the server people if needed. I have logs off all the communication attempts. And I have flushed out errors on the server, and still they haven't answered about other losses
Readings are stored in persistent storage -for the Mayfly 1.1this the uSD.
Configurable elements are store in a human readable form in a ms_cfg.ini file (Mayfly1.1 on the uSD)
LiIon rechargeable battery of vary sizes starting at 2Ahr.
Reliability enhancements.
Reliability is a challenge for embedded systems. Its not a system that has a human monitoring it and is rebooted everyday. Its a system that operates 24/7, and may occasionally if strange events, seamlessly reboot itself and continue operating.
Reliability comes from the way the subsystems are verified, and overall system - from sensor interface to cloud visualization - is soak tested.
Software reliability is the hardest metric to define, and usually comes from managing significant change a) check the change performs as expected b) appropriate system regression test to determine no loss of reliaility.
Hardware reliability comes from the right requirements and the way it is verified to those requirements.
As of this date (2023Q4), ModularSensors(master) and cloud server are not to my knowledge tested for reliability, or defined in a manner that is easy for a system integration test characterization.
The extra features defined in the following release are available when the core Modular Sensors team has cycles to accept them. I'm happy to do a PR if the core team has resources to discuss and define features.
See https://github.com/neilh10/ModularSensors/releases for details
2023 Mar 14 v0.34.1-abe Based on Envirodiy (master) 0.34.0
A release and series of bug fixes v0.34.1-abe
Retrieves LT500/RS485 and sends over Digi Modems to destination (tested with MonitorMyWatershed.org)
2022 Oct 26 v0.33.1-aac based on Envirodiy (master)0.33.0
Testing with Mayfly 1.1, RS485/KNH002rev7 to LT500 at default of 19200 E1
New hardware
(checks for ST3100 and uses it if present - not part of KNH002rev7)
2022 Feb 16 v0.32.2 [based on Envirodiy (master)0.32.2 I think)
Wireless configurable - Digi LTE and S6 modules
Tested Mayfly 1.0a3.
Added ms_cfg.ini: SEND_QUE_SZ_NUM - limit the que size on uSD
2021 Aug 31 v0.30.0
Digi WiFi S6 now working.
Fuel Gauge ST3100
2021 Jul 12 az0.28.5
Like linux, parsing uSD ms_cfg.ini0, ms_cfg.ini1 then ms_cfg.ini
eeprom cold init (.ini0), and then configuring eeprom (.ini1)
2020 Aug 12: v0.25.0? Three pre-defined releases https://github.com/neilh10/ms_releases
xxTu_EC.hex ~ A Stream Disconnect using Relative EC. Battery powered and serviced by bootnet access to microSD. Site config stored in EEPROM.
/---- Line Saved to TU_RC_test05a_2020-08-20.csv ----/
2020-08-19 18:54:00,1,4.139,4.0735,-38
xxTU_test.hex ~ A simple MMW reliable delivery test program using XBEE WiFI S6. Sensors SampleNumber_UUID, Batt_UUID, Volt0_UUID, DIGI_RSSI_UUID. It generates a log of all POSTs, whether passed or not, and shows retrys. Format ms_cfg.ini WiFi
xxTu_LT5.hex ~ A Stream depth monitor using redundant Insitu LT500 and Keller Acculevel sensors, reporting in over an XBEE LTE xb3m1. All config microSD:ms_cfg.ini
The sensors are; ITROLL_DEPTH_UUID, ITROLL_TEMP_UUID, KellerXxlevel_Height_UUID, KellerXxlevel_Temp_UUID, DIGI_RSSI_UUID, Batt_UUID, Volt0_UUID, SampleNumber_UUID
an example ms_cfg.ini:
[COMMON]
LOGGER_ID =MySiteID ;Used for LogFile MySiteID date.txt
LOGGING_INTERVAL_MINUTES=15
BATTERY_TYPE=0 ;0=none Future LiIon 4.2-3.3V LiSOCL2 3.6-3.3V , 3Leclanche 4.8-3.3V
TIME_ZONE=-8 ; -12 to +12
GEOGRAPHICAL_ID="MySiteRef 80 chars"
[NETWORK]
;apn OR WiFixx only one
;apn=VZWINTERNET
;apn=hologram
;WiFiId=Sid
;WiFiPwd=pwd or empty for none
COLLECT_READINGS=8 ; Number of readings to collect before send 0to30
SEND_OFFSET_MIN=7 ;minutes to wait after collection complete 0-30
TIMER_POST_TOUT_MS=9000; Gateway Timeout (ms)
[PROVIDER] ; Create at monitormywatershed.org/sites/xxxx
CLOUD_ID=data.enviroDIY.com ;only supports MMW
REGISTRATION_TOKEN= your_token_xxb0 ; registration token
SAMPLING_FEATURE= your_token_xxb1 ; Sampling feature
[UUIDs] ; Unique your_UUIDs below
ITROLL_DEPTH_UUID= 13770473-c058-4ef8-b0a9-2cfea0a710b0 ;Gage height ft LT500
ITROLL_TEMP_UUID= ea094242-29a9-45ac-8748-2a4987967214 ;Temperature LT500 Temp
KellerXxlevel_Height_UUID=e94cee5e-2717-4ef3-86b2-cf77e3f66c1a ;Gage height Keller_Acculevel_gageHeight
KellerXxlevel_Temp_UUID= 3206fb67-7690-40ac-978a-33fa2df88605 ;Temperature Keller_Acculevel_Temp
DIGI_RSSI_UUID= ac3c5798-2004-4fc3-9679-111977c6b0a8 ;Received signal strength indication (Digi_Cellular_RSSI)
Batt_UUID= 2ab799ea-0ff5-4798-b9a6-9549345f7310 ;Battery voltage EnviroDIY_Mayfly_Batt
SampleNumber_UUID= 199c4833-482b-43af-a0da-8db5fdc64871 ;Sequence number EnviroDIY_Mayfly_SampleNum
Volt0_UUID= 39aa2b45-29e1-4885-9fb9-b5fdb2955460 ;Percent full scale (Digi_Cellular_SignalPercent)
https://github.com/neilh10/ModularSensors/releases/tag/v0.25.0.release1_200812b
(branch rel1_dvlp1m) ModularSensors base 0.24.5: Individual Mayfly board configuration can be stored in EEPROM.
This allows for individual Mayfly's to be customized for a Geographical Location, and individually managed. The uSD can be retrieved from the Mayfly and the .csv are self identifying. Mayfly's can fail, lightening strikes or component failure, and when identified need to be tracked and removed from use.
The elements that can be stored are shown below with examples after the '=' and comments in ():
LOGGER_ID=TU_RC_LCC45_18 (20chars - first part of .csv file name, with date appended)
GEOGRAPHICAL_ID="LCC45_18 PitTag Monitor. Schneddy Rd bridge upstream 2nd bend" (60chars)
LOGGING_INTERVAL_MINUTES=2 (16bit integer)
TIME_ZONE=-8 (8bit integer)
BATTERY_TYPE=2 (8bit integer, manages different voltage thresholds for different battery types and capacities)
BOARD_NAME=Mayfly (20 chars)
BOARD_SN=AA0002 (20 chars)
BOARD_REV=0.5b (10chars)
The values are programmed into the EEPROM through fields in ms_cfg.ini, and a programming command in the sections [COMMON] or [BOOT] caused the values to be programmed into the EEPROM. On subsequent resets, the EEPROM is read first, and then if a ms_cfg.ini is present, those name=value pairs are read and replace any vale from the EEPROM.
This feature supports a Mayfly being deployed with no modems, and the only way of accessing the data is a field replacement of the micro SD card. The retrieved SD card will have all the nodes information coded onto the micro SD card, so it can be uniquely identified when the files are copied off the micro SD card.
ms_cfg.ini - resides on micro SD card, and read when ModularSensors starts. Defines specific node geographical customizations. For one build image (.hex) individual builds deployed to different geographical sites can be customized by the unique ms_cfg.ini file. Customizations include any passwords, and unique provider inormation.
ms_cfg.h - part of the ModularSensors build management in individual build directory. All constants are in one file for a specific build, enabling easy change to the build, or for testing multiple builds by changing one file.
A file on the microSD disk called "ms_cfg.ini" has configuration name=value pairs and is read after reset/boot.
This type of configuration file has a long history ~ INI files description
It uses sections for documenting, and in each section there is a name=value pair.
The name is descriptive and describes the purpose, while the value is for ModularSensors configuration.
After the value ';' then the rest of the line, to 80 chars, is treated as a comment.
The ms_cfg.ini contains node specific, or as deployed to a specific geographical location, geographically specific customized values.
Typically, for scaling a number of ModularSensor nodes, a unique file for each node is created, and is managed in a secure environment. These files should not, except as an example, be stored on the internet (in open github or any other open form).
The file's text fields are :
[COMMON]
LOGGER_ID =TU-ID-Test01a ;Site Reference and log file name
LOGGING_INTERVAL_MINUTES=5
TIME_ZONE=-8 ; -12 to +12
[NETWORK]
;apn=hologram
WiFiId=
WiFiPwd= ; or none if open network
[PROVIDER]
CLOUD_ID=data.enviroDIY.com
REGISTRATION_TOKEN=7ff7ae1b-9274-4376-afa8-get-from-MMW ; Device registration token
SAMPLING_FEATURE= 42c01940-952e-4a68-9d34-get-from-MMW ; Sampling feature UUID
[UUIDs]
Batt_UUID= 479f16f0-1e46-4d3e-8a80-286b7997608e ;Battery voltage (EnviroDIY_Mayfly_Batt)
SampleNumber_UUID=737aacd2-0259-4be1-9190-07308b9fdae4 ;Sequence number (EnviroDIY_Mayfly_SampleNum)
A Batter Management System that provides an API for Power Demand Managment
see https://github.com/neilh10/ModularSensors/wiki/Image-download-with-out-rebuilding
To ensure a clean reproducible build, the development environment needs a clean build. See https://github.com/neilh10/ModularSensors/wiki/Image-build-for-reproducible-output