GPRSBee

Hi Cal,

I have been working on a tutorial, but it’s unfortunately nowhere near complete, and I will be away for the next week. I suggest using the Modular Sensors library on GitHub, where there’s an example called logging_to_EnviroDIY. This is formatted to log to data.envirodiy.org, where you can set up a hosting site for free.
https://github.com/EnviroDIY/ModularSensors/blob/master/examples/logging_to_EnviroDIY/logging_to_EnviroDIY.ino

The catch is that it has a lot of library dependencies, which could be difficult to set up depending on your Arduino background.

Because you are using Hologram, line 106 will be:

const char *apn = “apn.konekt.io”; // The APN for the gprs connection, unnecessary for WiFi

The Modular Sensor sketches have a built-in “sensor testing mode”, and when you are in logging mode, watching the serial monitor, the sketch will give you
the “response code” for your internet connection, which you can look up to see if you have success (201 is the winning response: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes).

I’m attaching the tutorial text that I have done so far. It’s really in first draft mode, but I hope it can help you.

Beth

The modular sensors library that Beth references depends on TinyGSM for the majority of the cellular connection process. You may want to look at the code and examples in that library for help communicating with the GPRSBee (which is a SIM800 chip).

Unfortunately, I think if you’re successfully querying for csq and only being a response of 0, that probably means you just don’t have any signal. Having amazing 3G or 4G doesn’t mean there’s any 2G at all. Beth has found some quirks to the sequence of connecting the GPRSBee to that could also cause it to falsely report 0 signal. From the ReadMe for modular sensors:

Note for GPRSBee modems: To start the modem you will need to power the logger board off, connect the battery to the logger board, and finally attach the modem to the logger board. Then you may power the board and run your sketch. We have found that attaching a GPRSBee modem to power in a different sequence results in the modem reporting zero signal strength. Note, the Mayfly connected to a computer via USB does not supply sufficient power to the GPRSBee. If the community finds this true for other modems, please let us know.

I can feel your pain, Cal. I am going to face the problem of data upload to the the cloud or whatever on some projects that I am contemplating. I have a Mayfly water sensor on my property and the 2G is working fine. Shannon has a small box that does a 2G site survey that we used before installation of SL149

I think the larger concern will be how to upgrade all the existing Mayfly’s using 2G when that service goes the way of the dot-matrix printer!

I got some input on this question from some colleagues and in summary 3G and 4G will be overkill in terms of data rate so it would be expensive. The other option might be ORBCOMM which is a low data rate store and forward system which might be more affordable.

There are 3G and 4G modules that work just fine with the Mayfly. Are you meaning you want instructions on how to do it, or you’re just looking for the hardware?

Hi @ckillen, The Bee socket on the Mayfly makes it easy for the Mayfly to hook up with any radio with that connection/communication protocol. The socket can be used for several types of radios, including the 2G one that you have, WIFI radios, and the new XBee3 by Digi, that supports LTE-M communication (https://www.digi.com/pdf/ds_xbee3-cellular-lte-m.pdf). @w3asa, have you looked into this LTE-M radio? I think it will work with my existing hologram.io SIM plans and data rates.

I think the XBee3 is the route to use if you are no longer covered by 2G. My understanding is that T-Mobile is keeping their 2G coverage until ~2020, but if you don’t have their coverage, it’s not going to expand to cover you in the next couple of years. Here’s a 2G coverage map: https://orion.freeus.com/coverage-map.aspx.

I’ll keep plugging away on the instructional for logging to data.envirodiy, but it will probably be after September 10… because I have two proposal deadlines before then!

Beth

P.S. @ckillen Are you using a sensor with the ADS1115 chip? This is an analog to digital converter that shows up in ~3 sensors in the logging to envirodiy sketch. If not, your error message sounds like you need to “turn it off” by commenting those sensors out. I use “Command-/” after text is selected on my Mac. I suspect PC has a similar keyboard shortcut.

Which ADS1115 library are you using? Make sure you’re using the soligen2010 fork at https://github.com/soligen2010/Adafruit_ADS1X15/ – Don’t use the Adafruit original.

What was the bug you found?

Hi Cal, there’s a thread on GitHub about getting this thing up and running. Looks like others are having trouble as well. Perhaps contributing your debugging will help things along.

https://github.com/EnviroDIY/ModularSensors/issues/162

Huh.. I don’t know why the XBee would entirely stop responding. Does it still respond on XCTU? Could you have accidentally put it to sleep?

So far I have not managed to get my LTE-M XBee to connect to the internet with Hologram’s sims. I get denied service every time; sometimes quickly, sometimes after hanging at “22” (searching) for a long time. I’m having the same issue whether it’s on a Mayfly, connected to a PC and talking to XCTU, or connected to a PC and using a terminal with the USB direct access pins at AT commands.

The same hologram sim works fine in a 3G XBee and my LTE-M XBee can connect to the network just fine when I put in my AT&T sim from my cell phone. But I cannot get the hologram sim to allow connection with my LTE XBee.

Cal,

I have the hardware:

Mayfly Datalogger v0.5b
Digi XBee3 Cellular Lte-M/NB-Iot – XB3-C-A2-UT-001
No antenna – 3 bars of AT&T on my iphone
Soldered SJ13 and cut trace BEE-Vcc to 3v3 – 4.19V between Bee pins 1 and 10
3.7v Lipo battery
Solar panel from mayfly startup kit
USB to Windows PC – XCTU installed but not implemented
Hologram SIM activated

Software is:

logging_to_EnviroDIY with lines 53 (loggername), 54 (file name), 58 (registration token) 59 (sampling feature), 67 (BEE_TYPE = “gprs”), 68 (APN = “hologram”), and 321 (onboard_battery multiplier * 4.7 *) customized

and I’m getting this message from the Arduino 1.8.8 Serial Monitor:

09:44:27.286 -> — Request —
09:44:27.286 -> https://data.envirodiy.org/api/data-stream/
09:44:27.333 -> TOKEN: d02f68c0-2ed7-44e4-b912-d27c5aec74b0
09:44:27.379 -> Content-Type: application/json
09:44:27.426 -> {“sampling_feature”: “85e1d0c8-40dd-49ad-9a3a-6619a5500a6f”, “timestamp”: “2019-01-25T10:44:27-05:00”, “fec11d32-0658-4ef0-8a27-bdffa2104e31”: 26.25, “a7329b1b-b002-4fa8-afba-ae83b82ab8e9”: 4.94}
09:45:08.974 ->
09:45:08.974 -> Request to data.envirodiy.org timed out, no response from server or insufficient signal to send message.

I’ve tried multiple iterations of connecting the battery to the board.
My hologram dashboard shows the device state is live but there is no usage.
My site on Monitor My Watershed shows ‘Sensors have no data’.

I have a 900Mhz radio network setup here in the Minneapolis MN and I know those radios (RF450) need individualized configurations and I haven’t done that type of thing to the XBee3 yet.

I would like to get this XBee3 connected and configured and get my data logging to the https://data.envirodiy.org/api/data-stream/ server.

How can I fix this?

mdean,

I want to try those things but don’t have enough experience yet to know exactly how. When you reference TinyGSM (increasing the timeout time) what exactly do you mean by TinyGSM? And defining the modem serial at 9600 is understandable except I don’t see where to do that (in my logging_to_EnviroDIY sketch or in a different sketch that sets up the modem)?

I feel like I’m close.
Thanks for your input.

Ugh. I’m sorry you’re having so much trouble understanding what’s going on in ModularSensors. It’s a very heavy-weight library.

While you’re deep debugging your modem connection, though, sticking to TinyGSM and a basic sketch, or even just XCTU, is probably the way to go.

I’ve spent a lot more time playing with the LTE-M XBee3 so I think I can help a bit better now.

I cannot get it to connect without the solder jumper – it just needs the extra uumph. And the antenna is also definitely not optional.

No matter what I do, it sometimes stops responding. I’m seeing this whether I have it powered off the mayfly or if I have it on a separate Skywire development board, so I don’t think’s a capacitance or brown-out problem. Putting it to sleep and waking it again seems to magically resolve it.

Setting the network technology (“N#) to 2 (LTE-M only) seems to speed the connection up dramatically for me. On waking from sleep it will connect in comfortably under a minute.

And, acting against the manual, I’ve found I can connect even faster and it flakes out less if I put the thing in bypass mode and tell TinyGSM it’s a u-blox (which it is). Go figure.

To put it into bypass mode you set AP5, WR (write changes) and then FR for a force reset. It doesn’t enter bypass until after that.

@srgdamiano, that is great news. Do your recent discoveries lead to a clear path for getting this to work with ModularSensors on the Mayfly?

I’ve made some tweaks to try to make the LTE XBee work better. Code wise, it should have already been working, though. The problem was more about slowness/inability to make a connection to the internet and periodic non-responsiveness. That problem is somewhat upstream of ModularSensors.

I noticed that Atlas Scientific sensors are not in the ModularSensors list. I have built two EC sensor stations that are currently deployed in Great Marsh primarily to monitor stormwater runoff from the Pa Tpk. Scott Ensign has suggested I write this project up in more detail. Sara, are you interested in adding these sensors to ModularSensors if so I can give the code and details for this project?

Currently these EC stations are storing the data on a sd card only. Access to these stations can be a bit challenging to say the least especially in this weather!

I recently purchased some XBee’s from Sparkfun and have been able to get them talking to each other using the serial passthrough example code loaded on a Mayfly. I have checked out the range of the XBee Pro (60 mW) and I think they have the range to talk to a central location using the XBee’s ‘out of the box’ configuration.

I am looking for any code examples for using XBee for end to end comm. Basically I want to send data to a central station station when ever the mayfly wakes up and takes
EC and temperature data.

On the hardware side has anyone had experience connecting an SMA conector to the XBee board with the attached whip antenna? The distances involved are about 1 KM LOS so will probably need some gain antennas since I am quite sure the little whip antennas wont quite cut it.

I attached a dropbox link to brief report on the deployment of the EC/temp stations

I’m having a similar problem with the LTE-M Xbee3 that folks in this forum have already described, but slightly different. I have the same hardware as Cal and Brian, but I have a Taoglas LTE-M/NB-IoT antenna. Using the menu_a_la_carte.ino from Modular Sensors, the modem will throw a lot of “NO RESPONSE” messages while trying to synchronize with NIST, and the cell signal strength and % will be displayed as -105 and 12 when written to the SD card. It is getting a good amount of signal when I connect the modem to XCTU with an XBEE explorer-type board, but it takes a few minutes to connect. I tried using some simple code with AT commands that was posted in the “Trouble Initializing XBEE LTE-M” forum to wake it up and reset defaults, but it only responds about half of the time to the “+++” commands and never responds to AT commands with StreamDebugger.

I switched from using the main branch of Modular Sensors to the develop branch, but I got the same kind of response. I then changed up some of the “timeout” values in “TinyGSMXbee.h” and got this response:

Sending data to data.envirodiy.org
08:54:25.650 -> POST /api/data-stream/ HTTP/1.1
08:54:25.650 -> Host: data.envirodiy.org
08:54:25.650 -> TOKEN: [my token]
08:54:25.650 -> Content-Length: 402
08:54:25.650 -> Content-Type: application/json
08:54:25.650 ->
08:54:25.650 -> {“sampling_feature”: [my sampling feature]}
08:54:25.650 ->
08:55:17.649 -> — Response Code —
08:55:17.649 -> 504

I could see that the modem was trying because the Hologram Dashboard showed activity, but my values for cell strength were all zero. I modified some code in EnviroDIYPublisher::sendData to try and increase the waiting time for a response from the data portal:

After this change, I got a similar response, but there are no “NO RESPONSE” codes, a “Bad timestamp, not setting clock.” message, and my data were sent to the portal once. Every time after that initial upload to the data portal, I will get a 504 response code. The cell strength and % were still reported as zero even when it uploaded to the data portal. Output showing initial successful upload:

Setting up sleep mode on the XBee.
08:46:28.963 -> [2797] ### Modem: Digi XBee3™ Cellular LTE-M
08:46:29.308 -> Attempting to synchronize RTC with NIST
08:46:29.308 -> This may take up to two minutes!
08:47:06.473 -> Bad timestamp, not setting clock.
08:48:01.713 -> ——————————————
08:48:18.506 -> Successfully connected to SD Card with card/slave select on pin 12
08:48:18.540 ->
08:48:18.540 -> \/—- Line Saved to SD Card —-\/
08:48:18.540 -> 2019-02-01 08:48:00,2,-9999,11025,4.761,30.25,0,0
08:48:18.574 ->
08:48:18.574 ->
08:48:26.027 ->
08:48:26.027 -> Sending data to data.envirodiy.org
08:48:42.099 -> POST /api/data-stream/ HTTP/1.1
08:48:42.099 -> Host: data.envirodiy.org
08:48:42.099 -> TOKEN: [My Token]
08:48:42.099 -> Content-Length: 402
08:48:42.099 -> Content-Type: application/json
08:48:42.099 ->
08:48:42.099 -> {“sampling_feature”:[My sampling features]}
08:48:42.099 ->
08:48:45.941 -> — Response Code —
08:48:45.941 -> 201

Does anyone have code that consistently works with the LTE-M Xbee3 or suggestions on how to proceed? I am hoping to have a total of 10 stations that each have an LTE cell modem so they will work for a long time, and I don’t want to invest in the LTE-M Xbee3s if they’re not dependable. Are there other LTE cell modems that are known to work easily with a Mayfly like the Digi 4G LTE Xbee or the Digi 4G LTE-Cat1 Xbee3?

@srgdamiano, thanks talking to me on the phone Wednesday afternoon, explaining to me all your recent advances and successes.

All, I just answered that question on GitHub here: https://github.com/EnviroDIY/ModularSensors/issues/162#issuecomment-459879699

Here it is, also pasted below.

From what I understand, to get the Digi XBee3 LTE-M module to work on the Mayfly with Modular Sensors, it is necessary to:

1. Use “Bypass” mode to directly interact with the UBLOX modem chip, bypassing Digi’s chip, rather than using the standard “Transparent” mode, which would cause full freezes (probably due to power instabilities because there isn’t a capacitor chain on the Digi LTE-M module or the Mayfly).
2. Turn off the NBIoT radio to speed up the connection, by setting the network technology (“N#) to 2 (LTE-M only).
3. Turn off Power Saving mode, because this mode interacts with the network regarding when it will wake again, and if that doesn’t match the logging interval that we give it, it becomes impossible to wake up the modem when we need it.

@SRGDamia1 has implemented these changes in the current develop branch:
https://github.com/EnviroDIY/ModularSensors/commits/develop

She’s had it working since her Jan. 29 commit, be9e2eb, but she’s been working on improvements since then.

This solution still isn’t perfectly stable, because of the following hardware issues (which could all be addressed by an Xbee adaptor shield that I would like to build):

• Neither the Digi XBee3 LTE-M module or the Mayfly have the recommenced capacitor chain on the Xbee power line. This is the likely culprit for brownouts.
• Benefit of optionally switching Xbee-Mayfly pin connections for the “status”, depending on radio module
• The Mayfly doesn’t have a means to separately reboot or power-down the Xbee module
• The Mayfly doesn’t set all the unused pins to Ground, which would be ideal for broader radio compatibility, with for example the Nimblelink Skywire.

The new SODAQ SARA UBEE R410M radio module, https://shop.sodaq.com/sodaq-sara-ubee-r410m.html, has the same UBlox SARA-R410M radio chip as the Digi XBee3 LTE-M module​, but it also has a built-in capacitor chain, which could substantially improve the stability when deployed with the Mayfly.

Sara, what did I miss?

I just want to be really clear that the very slow connection speed and non-response is A PROBLEM WITH THE XBEE ITSELF, NOT THE CODE.

The messages like “no response received” are merely letting you know that the Bee is not responding.

There is nothing I’ve done in the code recently that changed it from “not working” to “working” with the LTE-M XBee3. I’ve done a lot more testing and tweaks to make it work better, that’s all. The basic code has been working as long as the module has been available.

@srgdamiano, thanks for making it really clear that the issues folks have been facing are primarily on the side of Digi’s LTE-M XBee3 hardware/software, and the work you’ve done with the ModularSensors code are all work-arounds to deal with the instability of Digi’s LTE-M XBee3 hardware/software when running on the Mayfly hardware.

I had failed to clearly convey that message in my previous post. Sorry about that!

Hi everyone,

Very quick question. Something I didn’t see listed in the above replies has to do with antenna selection. Anthony or Sara, do you have a recommendation as to an antenna for one of the new Digi LTE-M Xbee3’s? We have had really good success with the 900mhz xbees and are now working on projects where there is cell service, so we’re exploring these new options.

Sincerely,

Dave

I haven’t done any comparisons, but I bought Taoglas Maximus FXBU66 antennas and they seem to work quite well: https://www.taoglas.com/product/maximus-fxub66-ultra-wide-band-flex-antenna-smam/

Dave,

I bought the PulseLarson W3554B0140 RF ANT 829MHZ/2.2GHZ PCB TRACE (https://www.digikey.com/products/en?keywords=553-2574-ND) and I’m pretty sure it works. It looks like the one that comes with the Development kit (https://www.digi.com/products/models/xk3-c-n1-ut-e).

There’s a known bug from Digi that any of the XBee3’s with revision “B” of the primary processor, where it will become unresponsive even with very short dips or irregularities in voltage: https://www.digi.com/resources/documentation/Digidocs/90002258/#Troubleshooting/ts_brownout.htm%3FTocPath%3DTroubleshooting%7C_____7

I don’t know about the capacitors though. A manually soldered capacitor chain might create more problems than it solves. https://nimbelink.com/Documentation/Skywire/1001619_Breadboard_WhitePaper.pdf

Sara, thanks for your link to the bug on the XBee3 LTE-M RF Module. That is helpful to know that some of the issues folks have experienced were due to a known hardware bug. Do you know if the hardware fixed modules are available to purchase yet?

Also, regarding your concern about adding a manually soldered capacitor chain, your link describes why it wouldn’t be a good idea using a breadboard, or probably even the SparkFun Breakout Board for XBee Module, because the power traces are undersized to transmit those short bursts of high-amp power. However, it seems that manually soldering capacitors into an appropriately-sized power line would likely work, right?

I bought some of the Xbee3 LTE-M modules a few weeks ago and they had hardware version D printed on them, so they appear to be the latest version. I also updated their firmware to a version that came out a few weeks ago which supposedly has some improvements too. Digi also states in the manual several time (including with big warning symbols) that Bypass mode has been deprecated and should not be used because it causes instability in the cellular connectivity. So I’m now switching ours over to transparent mode to see if they are more stable. Previously in Bypass mode, I had the same issue that Cal did where things would work fine for a few days, but then the module would stop responding and require me to reset it. I’m hoping that operation in transparent mode will be better.

Something else that I discovered lately is that because of the workaround we did with using the SJ13 option for powering the Bee socket pin 1 directly from LiPo is that the module is now constantly powered. This is great as long as the Mayfly is turned on and can put the LTE-M bee to sleep by asserting the bee’s sleep pin high. The Mayfly is able to keep that pin high even when the Mayfly is asleep (if you write your code correctly). However, when the Mayfly gets turned off at the main power switch, the Bee module is no longer kept in sleep mode by the Mayfly, so it wakes up and stays on permanently until someone turns the Mayfly back on. The LTE-M bee draws about 7ma when idle, so it’ll drain a battery after a short while if you don’t have a solar panel connected. So for now, I just remove the Bee module from the socket when I turn the Mayfly off. It’s possible that you could solder a pullup resistor to the bee sleep pin, but that gets messy and could cause other issues. So our next version of the Mayfly board will incorporate some new changes to how all the Bee socket stuff is handled to fix this problem and to add some other functionality.