Trouble locating information on new LTEBee

I’ve been trying to resolve an issue with a sensor library file that is currently causing an error when users compile any sketches using ModularSensors.  Sara and I worked on it this afternoon and will hopefully have it resolved soon.  In the meantime, I’m working on an instructional page for the sim7080 module as well as posting example sketches that use that module with our most common water sensors (Hydros 21 CTD sensor and OBS3+ turbidity sensor).  I hope to publish that page later tonight.

I added a sketch called “DRWI_sim7080LTE.ino” to our Github repository.  You can find it here https://github.com/EnviroDIY/ModularSensors/tree/master/examples/DRWI_sim7080LTE along with a brief summary.

We’re still working out the bugs in the libraries that were cause by an update to an external library that is included in our bundled files (the AOsong DHT library).  So anyone downloading the libraries right now might get some errors, especially if you’re using PlatformIO, but hopefully that will be resolved soon.

The only main difference between the sketch for the sim7080 and the sketch for the Digi LTE boards is that there are 2 sections in the code that configure the logger for using the cell module (lines 85-117 and 349-364 in the sim7080 sketch).  I also cleaned up the section with the UUIDs to make it match the MMW website.  This example sketch is also written for the new Mayfly v1.0, so there’s code on line 101 and line 325 for proper operation with the Mayfly v1.0 board.  The sim7080 LTE module has been successfully tested on the Mayfly v0.5b board, so putting “-1” in line 101 instead of “18” will let you use it on the older Mayfly board.  There are commented notes in the sketch on those lines.  More descriptive tutorials and manuals are currently being made and will be published as soon as we can finish them.

And as mentioned in the Github readme, here’s some info about antennas for the sim7080module:

The EnviroDIY LTE sim7080 module includes 2 antennas in the package. The small thin one is the cellular antenna, and should be connected to the socket labeled “CELL”. The thicker block is the GPS antenna, and should be connected to the “GPS” socket, but only if you intend to use the GPS functionality of the module. ModularSensors does not currently suport GPS functionality, but other libraries such as TinyGPS can work with the sim7080 module.

The included cell antenna works best in high-signal-strength areas. For most remote areas and logger deployments, we suggest a larger LTE antenna, like the W3907B0100 from PulseLarsen (Digikey 1837-1003-ND or Mouser 673-W3907B0100)

I’ve had 2 problems with the SIM7080G modem on the Mayfly 1.x board.  I wonder if anybody else has had the same problems or has any information that would help me.

My code is uses the TinyGsm library, and some parts of the ModularSensors code but is otherwise custom code. The code has been working in the field with Mayfly 0.5 and Digi LTEbee’s for years. I’m just starting to migrate the code to accept the Mayfly 1.1 and SIM7080 for new installations.

<u>Problem 1 – Posting too much data</u>: I found that doing an HTTP POST to my website fails when sending data greater than ~1400 bytes.  The post is not accepted by Apache on my website.  It works fine if sending less than 1400 bytes.  The same code running on my Mayfly 0.5 with Digi LTEBee sends 6000 bytes with no problem.  Can this be a timing thing? Is there some limit on the Sim7080?

<u>Problem2 – Modem Unresponsive</u>: After doing some tests, sending some AT commands, trying some new ideas online – the modem became unresponsive to any AT commands.  This wasn’t a sleep/wake problem as it would sleep and wake as normal using pin 23 pulse.  It took me a long time using parts of TinyGSM’s Factory Reset code and my test tool to get the modem to work again.  Has anybody else run into this problem or has an idea what I did wrong? I’m worried that the module might get into this mode when it’s in the field.

I think @srgdamiano should be able to help, since she has the best understanding of the libraries and commands used with the sim7080.

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.

We’ve never had any hardware failures of our sim7080 module in the field when using the sketch mentioned above.  With hundreds of them deployed in the past 18 months, the only problem we occasionally see (one or two stations a month) is where they stop responding to the Mayfly board and kind of “lock up” and need to be reset.  This is usually accomplished by just cycling the power switch on the Mayfly board and everything returns to normal, thanks to all the module initialization code Sara put in the libraries and the sketch that run at startup.  But sometimes just a power cycle isn’t sufficient and the LTEbee has to be unplugged from the Mayfly’s bee socket for just a second, and then plugged back in.

@ckillen sorry to hear about the problems  – I make the assumption that a sub-module can always lockup, and may need a hard reset/power cycle to bring it back. Internal modem software can only be as good as its tested, sub-modules  comms software is complicated and its very difficult to test for all cases.

The Maylfy1.1 now supports a power off capability as well as reset. I treat lab found conditions like you are talking about as a golden opportunity to build in simple reliability – repower, reset. Intermittent field problems are too hard to figure out.

I find it really doesn’t work to give field technicians (or even PhD hydrologist) a training in how to remove a 20pin modem and reinsert it in hot and sweaty field  conditions, and also how to have a u.fl antenna stay affixed. “You want what!”

It could also be that the modem power has been turned off, and the device is not working.

I have it such that the modem stream monitor can be enabled from the build command line (or platformio.ini).

I should note it probably is only able  to work with the modem UART stream Serial1 running at a slow 9600baud and the SerialTerminal running at faster 115Kbaud

I haven’t yet tried the SIM7080, still using the Digi LTE modem (I  fortunately got enough stock).

In the extreme, last year  I used the IP protocol monitor stream debugger WireShark to actually see what was going on the line, and to check for  the HTTP response. However this is a pretty difficult setup to get right.

Thanks all for your replies and help.  I didn’t know about the MTU and limiting my message buffer under 1500 will easily solve that problem.  I’ve put recovery code in my sketch to gracefully power down and reset the modem if it ever gets into a non-responsive state.  I’ll be installing several units (Mayfly 1.1 and Sim7080) this summer. Thanks again.

Hope it works  – be fascinating to get an overview of the project when you have time 🙂