@james_nz my process is to stage systems in an accessible context to check the reliability of the systems. This comes from the school of hard knocks working with embedded processors like the Mayfly.
IMHO while ModularSensors software has some fantastic classes to be able to access the instruments and also to push to cloud locations, Arduino Open Source is generally at the level of – Arduino teaching ~ this is how it can be done.
Its next to impossible to teach “reliability” – its usually learnt through being on the “bleeding edge”. The 2nd time around one tends to add more foundational capability to better cope with reliability testing.
You reference “dropping out” which can be a whole record or one instrument. A record lost is typically due to “internet failure”, but still stored on the uSD.
Individual readings, usually digital instrument, when the digital comms link to the digital instrument fails.
It seems, for the above referenced node, your RS485 instruments are responding OK, its the SDI-12 instruments that are having comms failures.
Its should be noted that the Mayfly’s xx could be said to support “Arduino SDI-12”, that is they show how it can be done, but there is a lot of technical debt. It isn’t per the SDI-12.org specification for signaling and protection.
I’ve been trying to prototype a solution to this for some time. Right now my RS485board includes SDI-12 protection and level shift. However I still need to work on the SDI-12 software for it to cope with the level shift. https://www.envirodiy.org/topic/sdi-12-level-shifting/
Currently when you access the Mayfly X with the USB cable (or even the FTDI cable), it causes the Mayfly to reset – a nice Arduino feature of always making sure the board can be programmed. However that reset isn’t good for reliability monitoring – that is plugging in and just monitoring how its been working – I’ve created a modified FTDI connector to allow that https://github.com/neilh10/ModularSensors/wiki/Test-Equipment-FTDI-cable