[Sara Damiano]

If you remove both the coin battery and the mayfly loses power, even for an instant, the clock will reset to Jan 1, 2000 0:00:00.

The coin battery isn’t necessary if there’s another power supply, but it’s very convenient to power the clock with its own battery so that you don’t have to reset the clock every time you turn the Mayfly off.  The clock battery should last for a few years.  If you’re running modular sensors and have internet connection, the first thing it attempts to do on boot-up is set the clock and it will continue to attempt to connect to NIST and set the clock on every cycle until the clock passes a “sanity” check (ie, between 2019 and 2025).  If there’s no internet connection, though, it will spit out lots of warnings about the incorrect time but should proceed to sample on every 5 minute interval.  Once you download the SD card you’ll have to use your installation notes to estimate when you turned it on and adjust everything accordingly.

I don’t remember if there’s a “sanity” check on MMW or not – I thought not.  Look for data that’s labeled as 20 years old.  (Man that makes me feel old..)

[Sara Damiano]

As for T-Mobile’s 2G, the most recent I’ve found says no guarantee past the end of this year.  A while ago they were saying that they would maintain the same coverage area for 2G up until the sunset, but we keep having more sites without coverage.

[Sara Damiano]

I’m sorry!  The SIM800 definitely has quirks, but it’s better than this.  We have had better luck with the Mayfly and Digi LTE XBee3’s than you have had with the UBee, but I’ve spent a lot of time tweaking things to figure out what works.

It’s funny, we were on a phone call at one point with a group at Oregon State that was just beginning to look into adding cellular connectivity via a breakout of the SARA R410M. The guy working on it said something to the effect of “we haven’t had any problems with it so far” to which my response was “then you haven’t been working with it long enough.”

[Sara Damiano]

I’m sorry, but you keep saying things that are unclear and incomplete which makes it very frustrating for me in trying to help you. I need you to share more information.

Do you have or have you read the manual from Yosemitch for your sensor and do you understand how it works? I am not specifically familiar with the Y500-B; I assume it can be interacted with like a Y502.

Have you ever succeeded in communicating with this sensor – that is, using your computer, a hand-held Yosemitech transmitter, an AVR based Arduino, or any other device that is NOT your Node MCU board?

Do you know your sensor’s modbus address? That information is required.

Now describe completely your physical wiring and connections:

• Are you using breadboards or have you made a custom circuit of some kind? Post a picture.
• By what is the Yosemitch sensor powered and at what voltage?
• Exactly what RS485 to TTL adapter do you have connected between the A and B (green and white) of your Y500B and your NodeMCU (brand, chipset, etc)
  • What powers the RS485 adapter and at what voltage?
  • Does the adapter require the use of a pin to change the direction of communication or does it have automatic flow control?
  • Are there any LED’s on your adapter?
    • If so, do you see the power, Tx, and Rx LED’s light up appropriately?
• What level shifters are you using (brand, etc)?
  • Are your level shifters between the Tx and Rx of your adapter and the pins of your NodeMCU?
  • If not, where are they in the chain?
  • What voltages are you shifting to and from?
  • I have not succeeded in using external level shifters on a breadboard with an RS485 adapter so I am quite skeptical of a set-up that requires them.
• Are you sure you have Tx and Rx coming out of the adapter connected appropriately the pins you are assigning as Rx and Tx in SoftwareSerial?
  • Have you tried reversing the Tx and Rx?

In your code, what version of the Yosemitch library, of SensorModbusMaster, and of the Arduino core for ESP8266 do you have installed? Please list the versions and post your complete code.

[Sara Damiano]

Are you using Arduino core on your ESP8266 or are you using NodeMCU Lua? They are completely different firmwares; Arduino core uses cpp and has many libraries that parallel functionality to an AVR Arduino board like the Arduino Uno. NodeMCU uses Lua script.

I use softwareserial and ive heard that it work but dont really know.

There is a SoftwareSerial for the ESP’s Arduino core, but I have never attempted to use it. Both SensorModbusMaster and YosemitechModbus are completely independent of SoftwareSerial. They should work on an ESP8266 using Arduino core, but, again, I’ve never tried.

As i couldnt download his code i made it from scratch.

I have no clue what code you’re talking about.

Acording to how i connected it it seems like its connected to the nodemcu but actually i dont really know sadly

Well, does it communicate or not?

[Sara Damiano]

I am so very unimpressed with the SARA R410. It does not deserve its name.

[Sara Damiano]

Oh, no, the hold for the URC *is* working. It’s just not holding for long enough. It gives up after 75s and the code wasn’t smart enough to differentiate between a ‘0’ = nothing in the returned buffer and ‘0’ = the modem returned that it opened the socket with 0 errors. The CSQ responses show good signal you’re already registered on the network with EPS.. What is it *doing* that takes it over a minute to establish the socket! I don’t know if switching to the synchronous open will help or not. It’s still going to give up after 75s and it might completely lock the whole thing up – that’s why I switched to async in the first place. But it’s worth a shot, I guess. If you start seeing outgoing AT commands with no responses after the socket open, it’s locked up and you need to power cycle.

If that doesn’t take or the board is locking up, you can increase the default timeout past 75s and see if waiting up to two or three minutes does anything more than waste your time. You have to do that in the CLIENT_OVERLOADS section of TinyGSM common. (line ~220 and ~224) [The timeout set in TinyGSM common takes precedence in this case.)

[Sara Damiano]

Now it’s the asynchronous open that’s causing trouble. That *should* be blocking. The program should not continue until the URC arrives. I will need to test that more.

Anyway, another change in TinyGSM:

C++

// Use an asynchronous open to reduce the number of terminal freeze-ups // This is still blocking until the URC arrives // The SARA-R410M-02B with firmware revisions prior to L0.0.00.00.05.08 // has a nasty habit of locking up when opening a socket, especially if // the cellular service is poor. // NOT supported on SARA-R404M / SARA-R410M-01B // sendAT(GF("+USOCO="), *mux, ",\"", host, "\",", port, ",1"); <----------------------------- Comment out this section // waitResponse(timeout_ms, GF(GSM_NL "+UUSOCO: ")); // stream.readStringUntil(',').toInt(); // skip repeated mux // int connection_status = stream.readStringUntil('\n').toInt(); // return (0 == connection_status); // use synchronous open <----------------------------- Enable this section sendAT(GF("+USOCO="), *mux, ",\"", host, "\",", port, ",0"); int rsp = waitResponse(timeout_ms); return (1 == rsp);

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

// Use an asynchronous open to reduce the number of terminal freeze-ups     // This is still blocking until the URC arrives     // The SARA-R410M-02B with firmware revisions prior to L0.0.00.00.05.08     // has a nasty habit of locking up when opening a socket, especially if     // the cellular service is poor.     // NOT supported on SARA-R404M / SARA-R410M-01B     // sendAT(GF("+USOCO="), *mux, ",\"", host, "\",", port, ",1");  <-----------------------------  Comment out this section     // waitResponse(timeout_ms, GF(GSM_NL "+UUSOCO: "));     // stream.readStringUntil(',').toInt();  // skip repeated mux     // int connection_status = stream.readStringUntil('\n').toInt();     // return (0 == connection_status);       // use synchronous open  <-----------------------------  Enable this section     sendAT(GF("+USOCO="), *mux, ",\"", host, "\",", port, ",0");     int rsp = waitResponse(timeout_ms);     return (1 == rsp);

[Sara Damiano]

ModularSensors does NOT work using an ESP8266 of any flavor, including NodeMCU, as the main processor.

The Yosemitech library might; I’ve never tried.

[Sara Damiano]

Oh, and yes, the issue with NIST is really common. There have been a few GitHub issues about it. I’m trying to connect over TCP to the daytime server. That server is designed to respond to any incoming connection on port 37 with 4 bytes representing the current timestamp and immediately close the connection. A lot of the time the various modems see the connection as closed before they’ve had a chance to tell you that any data was received. So I wait 4 seconds (as required by NIST) and try again, up to 5 times.

It would be much more efficient (and accurate) to connect to a proper NTP (network time protocol) server and get the time that way. But NTP is run over UDP and I don’t know of any libraries that support both TCP and UDP connections on more than 1 single device type the way that TinyGSM does for TCP. With TinyGSM, it’s only a few lines of code to switch from a 2G to 3G to 4G to wifi connection. It’s on my to-do list to implement full UDP support in TinyGSM, but I have no timeframe for it happening.

[Author]

Posts