[neilh20]

@zeke-holloman communications – peer2peer – is a deep subject.

Many years ago I wrote the code for a comms stack to use the 9bit UART to poll an array of processors. In the end it was 2people for 18months to get it working reliably.  So its not trivial, but i had a fantastic time with it.

https://forum.arduino.cc/t/uart-with-9-bits/612497/19

It may that you have a special case and only want to use 8bit communications,  it partly depends on what you want to communicate.

 

[neilh20]

Hey great. Many thanks

[neilh20]

@shicks just wondering if the RS485 schematic is likely to be published, and of course if the parts are likely to be available. Many thanks.

[neilh20]

Ok. Got it running with a student I’m working with (over zoom)

python -m serial.tools.list_ports -v

1	python -m serial.tools.list_ports -v

shows the ports and then substitute for “FTDI”

So in https://github.com/EnviroDIY/Sodaq_DS3231/blob/master/examples/PCsync/python3.9/PCsync3.py

about line 101 subsitute

“Silicon Labs”

(or maybe there is an OR function – but I don’t recognize the iterator )

 

[neilh20]

@mbarney just wondering did that work for you with the Mayfly1.0 .  Do you have any changes you made to the program. Many thanks

[neilh20]

edit to the above email:  Sorry I don’t have any experience with the 12V batteries, or 12V to 5V.

I would note that the Mayfly1.0 charger is different than 0.5b, and I’m seeing that it wants a slightly higher+5V than the Mayfly 0.5b for it to do a 0.5A charge of the LiIon battery. I am using USB charging monitor “USB Meter” to monitor the charge rate.

I definitely agree with @ckillen  that whatever methods’ are used, some monitoring is required to figure out where the power goes and is it working as expected

[neilh20]

I’m also deeply into power analysis as the way of keeping everything going. I was working with some engineering students and got them to do a spreadsheet, which I modified and added and can be used to build a budget for the power that you think you need, and what the power consumers might be.  I then look for the major user of the power, and let the project be driven by that. ie if its a sensor that needs 12V and consumes a lot of power then you need to have the large battery.

I also reduce the power by changing how often it turns on the cell modem. ie from 15minutes to 60minutes. The project with students we are only talking about turning it on every 24 hours. However this is a lot of software that I’ve added to my fork.

I also have a battery threshold that I stop any transmission, and then when there is enough solar power harvested start transmitting the stored readings and then the new readings. Its not trivial software to do this, but it has now been well tested.

Happy to share more about power savings if its of interest.

One idea that I’ve seen with the Mayfly 1.0 and the new power routing, is that there can be the  LiIon battery plugged in, with solar panel, and then a top up USB Battery pack plugged in.

However I do have to say that the Mayfly 0.5 and also 1.0 battery measurement is challenging, and I’ve tried to phrase it here. IHMO its a really basic issue, and has caused me no end of technical headaches. Mayfly 1.0A3 is more of problem than 0.5  https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/issues/32

Attachments:

1. Power-Consumption2-enviroDIY.xlsx

[neilh20]

@zeke-holloman  hey congrats,!!! Thanks for the posting and analysis, I could also build from that.

Wow… the power of open source that you can dive in and tweak it, so you can make it work. Go @zeke-holloman   !!!

Just an FYI, what I do to facilitate easy maintenance, and easy future merges, I rename my customizations to a “unique name space”  eg ThingSpeakPublisher3a.h/.cpp and then also the classes ThingSpeakPublisher3a.

Then if you come to do an update “git pull” and there are updates in the main line “master” ThinkSpeakPublisher.h/cpp you’ll have a smoother ride  with being able to track the updates,  and either adopt them or stay with your customizations.

[neilh20]

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

[neilh20]

@zeke-holloman I agree with @srgdamiano,  Mathworks have gone down the path of making it difficult to test a small number of devices against thingspeak, since it was added to ModularSensors publishers.

A bit of shame since I’ve had some simple devices working reliably against it since 2013.

Also unfortunately, “the real world” is that testing is against a matrix – release ModularSensors xx.xx against thingspeak – so I think you are on the leading edge for ModularSensors Publisher v mqtt3.thingspeak  🙂

Taking a scan of their  mqtt3,  it seems like they are suggesting you create new devices when moving to their mqtt3  – so at a GUESS, that suggests they have a whole new server architecture and subscription management. So be great if you share results – stuff that doesn’t work is as valuable as stuff that does work.

When looking at a new service, its also useful to consider what it takes to prove how well it works  and how far you want to go.

Typically new development goes in stages a) protoyping b) integration testing c) reliability/stability testing.

MMW has a lot of capability, and very mature,  but in the “reliability testing” of  Mayfly 0.5 and Digi LTE CAT-M1 modems, from a debug analysis, there is a possible timing  problem with the tinyGSM device driver  https://github.com/EnviroDIY/ModularSensors/issues/396 – which suggests that if the MMW servers response where a lot faster, faster than the current fastest 1.2seconds, it might break the current deployments with Digi LTE-CAT-M1 XB3-C-A2-UT-001.   Its what happens in testing sometimes.

I’ve had very good experience so far with “reliability/stability testing” of ModularSensors 0.32.2/(Mayfly 0.5+ Digi LTE-CAT-M1), but the server response through the cellphone network is pretty slow,  at its fastest 1.2seconds.

For mqtt3.thingspeak you are back to “a)prototyping”.

For  another wireless protocol LoRa/Thingsnetwork,  with max payload of 51bytes, which seems unlikely that it could work with MMW API, I’m checking out Arduino.cc mqtt/IoT or Adafruit mqtt as having plans  for smaller devices.  So I would describe I’m trying to figure how to prototype that interface.

I should note – https://github.com/EnviroDIY/ModularSensors/releases/tag/v0.32.2 doesn’t identify what features work with new Mayfly 1.0A3 boards. The modem SIM7080 , isn’t identified as being supported yet, or tested with ModularSensors – though as its open source we can all see what’s in the software. I guess, user test at their own risk.

I have only done minimal testing on Mayfly 1.0A3, as its typical for organizations to announce what they support and regression testing. My testing, is with a student capstone project as a standalone sensor so far, though they should get to cellular LTE integration soon.  On paper analysis I’ve identified a potential comms issues with Mayfly1.0A3  – see https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/issues

I’m making ModularSensors detect in runtime whether its Mayfly 0.5 or 1.0 – so the user/program doesn’t have to compile for one or the other.

[Author]

Posts