[Sara Damiano]

As of a few years ago, the Skywire were _NOT_ compatible with the Mayfly. They use the XBee footprint, but they’ve re-arranged some of the pins so that it won’t work with the Mayfly – 0.5 or 1.x. At the time, each Skywire variant used slightly different pin-outs so you couldn’t even exchange between them directly.

I don’t know of any other cellular modems that are directly compatible.

If you’re willing to use jumper wires, you can pick any modem break-out you want.

[Sara Damiano]

Oh, your right, that’s from the break. I’m not sure about the power line.

[Sara Damiano]

100ms

[Sara Damiano]

@w3asa Did you look at this example: https://github.com/EnviroDIY/ModularSensors/tree/master/examples/DRWI_Mayfly1. I think it’s almost exactly what you want.

[Sara Damiano]

To close the jumper on the Mayfly, you need a soldering iron. If you don’t have access to one of those, you might need to go back to the trinket.

You could also order a replacement pendant logger from Onset: https://www.onsetcomp.com/products/data-loggers/ua-003-64

[Sara Damiano]

I don’t know if the Mayfly is powerful enough for any of the SSL libraries, but you shouldn’t need one. The SIM7080G itself can handle the layers of secure connection. The Mayfly should only need to tell it to use the secure connection. Look in the examples for secure connections in the TinyGSM library. Essentially all you need to do is call TinyGsmClientSecure client(modem) instead of TinyGsmClient client(modem).

I think for AWS, you may need to upload the SSL certificate to the SIM7080G before you can use it. I’ve never tried to do this, but there’s an example of doing it with the SIM800 in the TinyGSM library here: https://github.com/vshymanskyy/TinyGSM/blob/master/examples/more/SIM800_SslSetCert/SIM800_SslSetCert.ino

[Sara Damiano]

Unfortunately, there’s not a way currently to change the data level from provisional.

[Sara Damiano]

It’s been a long time since I played with the Atlas sensors, but from my notes, power cycling them can cause the whole logger to crash. If you want to power down Atlas sensors between readings, you need an I2C isolator.  See the warning here: https://envirodiy.github.io/ModularSensors/group__atlas__group.html.  The simple logging program should put the sensors to sleep and power them down between readings:  https://github.com/EnviroDIY/ModularSensors/blob/master/examples/simple_logging/ReadMe.md

[Sara Damiano]

The maximum transmission unit (MTU) for TCP is 1500 bytes. That’s why your transmissions over that size are failing. The commands TinyGSM uses for the SIM7080G are too low-level to break it up; you’ll need to do that yourself or submit a PR for TinyGSM. The XBee commands are higher level;  it does the break-up for you.

My first guess for the modem stopping responding would be that you changed the baud rate to something too fast for the Mayfly and the communication because too unstable, so it stopped responding. I can’t think of any other commands you might have read online that would result in something similar, but I’ve messed up more than one type of modem playing with the AT commands. Our field failure rate of the SIM7080G is lower than for the XBees. Shannon could give you a better guess of the number of field failures than I can.

[Sara Damiano]

The ModularSensors library is running the SDI-12 sensors in “concurrent” mode and the modbus communication only happens when initiated by the logger.  So the two sensors really should not be trying to talk to the logger at the same time.  ModularSensors first asks each sensor to start taking a reading, then goes back and asks each one for its results in the order that they’re expected to be ready.  You can try using the build flag -D MS_SDI12_NON_CONCURRENT in your PlatformIO.ini.  That will tell it to start a reading and then wait the full time for a reading to finish before the starting the next sensor. Note that the flag only affects SDI-12 sensors.

If the same code is working in some places but not in others, I would suspect the problem is electrical, not code.  That is, some combination of instantaneous voltage instabilities when both sensors are working is garbling the communication.  The SDI-12 library is “bit-banged” so it’s very weak to interference.  Shannon or Neil may have better ideas on ways you could try to electrically isolate the sensors from each other.

[Author]

Posts