Compiling for Mayfly v0.5 or v1.0

Hi Matt

The short answer :),  there is a difference in hardware ports, and that can impact the interface to the modem.  I expect to support the Mayfly 0.5b for the foreseeable future for devices in the field, and the Mayfly 1.0x features are in evolution. I appreciate the support and context of SWRC, hardware is available for purchase, software is gittable, ~ however there has been no description of regression testing or any visible plan for the Mayfly1.0 features. (The MMW has a visible plan https://github.com/ODM2/ODM2DataSharingPortal/milestones)

Sounds like you have put the software together and its worked. Probably its the default configuration of the ports. Whew!.

Looking at the schematics, the Mayfly1.0A3 v Mayfly0.5b ports are different when it comes to the modem. For Mayfly 1.0 I appreciate the better control of the modem subsystem – I so like to be able to ensure a known configuration of a complex module (the secret; periodic reset) – just to avoid long term reliability problems I’ve seen in other modules.

If there is a Mayfly 1.0 specific hardware integration issue, or usage of its new features,  its going to need a specific workaround, and only used if the Mayfly 1.0 is operating.

The long answer, is I’m working towards simplifying the complex configuration of the “logger platform”. The goal I have is that the “logger platform” should be configuration driven – that is configured by reading what revision the Mayfly board is at, and also in a uSD:ms_cfg.ini file for the network/UUIDs, and in the future configure for the modem, and configure for sensors.

I  have the infrastructure already built to program the onboard EEPROM for revision info, so relatively easy to read it out.

By far the biggest challenge to any software platform with 24/7 criteria is stability – embedded platform stability is even more challenging.  I put together this discussion – as much about having a whole system testable – ModularSensors/Mayfly +MMW – https://github.com/ODM2/ODM2DataSharingPortal/issues/524 which is also dependent on https://github.com/ODM2/ODM2DataSharingPortal/issues/485

Stability needs to be characterized and that is white box testing. Typically for a saleable product with software on hardware, its a core customer expectation (sales contract). Simplify all the complexity, to core stability confidence.

The target for engineering, can you change one item ~ software or hardware, and still have some confidence in the whole “logger platform” stability. The poster child for this is the Digi WiFi S6, which was working (in 2019 I think) – I put a system in the field with an external WiFi antenna + WiFi gateway and it worked (then the system got stolen). I used the WiFi module as a proving ground for stability of the general Mayfly when the LTE was still evolving and also for basic interfaces to the server. I designed the core ReliableDelivery algorithms over WiFi, as the data plans where pretty expensive at that point. Then something changed, probably the tinyGsm lib, and I wasn’t watching it as I had moved to using LTE and SDI-12, and getting them stable/working. The WiFi S6 was broken for probably 6months (and still is on main release). When I got the WiFI S6 back working middle of last year, it required a fork and rework of the tinyGsm drivers.  All of this is in my private fork, as to be honest stability characterization is hard/complicated. None of the known problems are reflected in the ModularSensors modems page. (https://envirodiy.github.io/ModularSensors/index.html#mainpage_modems) . What of course would be nice is what was the revision it was tested against – MS version, module hw/sw, and known problems in later releases.

Hardware also has stability characterization process – Mayfly SDI-12 implementation is a subset of https://sdi-12.org/specification  – Mayfly 1.0A3 was perhaps trying for +12V generation required by the specification. Mayfly1.0A3 still claims that it can do +12V generation (with no power spec), but my versions haven’t worked with real world requirement,  https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/issues/33

The history I’ve found, with other projects and also the Mayfly, you need to deal with the real world device foibles (and availability). Last time I looked at Xbee WiFi,  the Digi WiFi module was the only one with a u.fl connector for an external antenna – critical for better range. So i’ve stuck with keeping the Digi WiFI module.

Others may have something similar – but how about an objective to make it easy to change – switch one sensor LT500/SDI-12 to  CTD/SDI-12

My perspective for an embedded “logger platform”, is it has a defined configuration to work and be deployed – Mayfly0.5b+carrier board Digi LTE-CATM1 modem+ antenna  +4400mA battery + 3W solar panel + RS485board(for SDI12 +12V) +sensor LT500.

That configuration needs to work. If some of the components are switched out – eg to Mayfly 1.0 + Digi LTE-CATM1(less carrier board)  – I would also like it to work in the same way. However Mayfly 1.0 ports interface to the Dig LTE-CATM1 differently.

So hope you don’t mind the long answer, back to reading the hardware configuration,  so for software stability testing, when its loaded with a defined .hex, I’d like to be easily adjust for hardware features!! …. Mayfly 0.5b, Mayfly 1.0A3, … Mayfly 1.x