Connecting XBee3 LTE to the internet

Tagged: monitor my watershed

This topic has 7 replies, 3 voices, and was last updated 2019-11-13 at 10:56 AM by Sara Damiano.

Viewing 7 reply threads

Author

Posts

2019-11-08 at 3:59 PM #13310
Matt Barney
Participant
I have a Mayfly 0.5b that I am trying to set up with a new XBee3, but have been unable to get an internet connection. The RSSI values are always zero. The serial monitor indicates “Could not connect to internet for clock sync”, I’ve not gotten any data to MMW, and Hologram says that there have been no network connections for the SIM.

I’m working from this sketch: https://github.com/EnviroDIY/ModularSensors/tree/master/examples/logging_to_MMW, and have modified it with my LoggerID, apn, UUIDs. I’m using PlatformIO with VSCode.
My modem is a Digi XBee3, LTE-M with ublox model SARA-R410M.
I have a Hologram SIM installed, which has been activated on my Hologram Dashboard.
I have a Pulse W3907 antenna connected to the Cell port.
I have set the RTC using PCsync.
I’m using the EnviroDIY LTE Bee Adapter, with a JST jumper to a LIPO port on the Mayfly, and am powering the Mayfly via USB.
I have enabled the debug build flags according to this post, and the terminal output is attached.

Grateful for any help!
Matt
Attachments:
1. XBee.txt
2019-11-08 at 5:14 PM #13312
Sara Damiano
Moderator
Hm. You have the LiPo plugged in in addition to the USB, right?

Are you sure you have service and the antenna is well connected? Don’t yank the antenna off unless you really have to; those u.Fl connectors are fragile and after 3 or 4 times of being disconnected and reconnected they stop working.

Have you ever gotten your XBee3 to connect? Sometimes it needs a long time on before it will make the first connection (think 20+ minutes). The sketch only waits two minutes on boot up and ~45 seconds every data point there-after. You can make it wait longer by changing the time in line 302 “if (modem.connectInternet(120000L)).” 120,000 ms = 2 minutes

Did you try changing from Transparent to Bypass mode? The instructions are in the thread you linked earlier. Sometimes that’s a magical fix for connection issues.

Can you connect the XBee3 directly to a computer and talk to it with XCTU? Do you have the latest firmware on the XBee3 and the SARA-R410M? If you’ve bought it within the last few months, it probably has at least the most crucial firmware updates, but the very latest is best, if possible.

Can you post a log from the same sketch, but change your settings in the terminal to use CR as the end-of-line. In transparent mode the XBee3 uses CR instead of the more typical CR+LF so you need to change the line endings to see all back and forth communication. In PlatformIO on Atom, you can select the line ending by expanding the extra options in the pop-up window when you open the serial port monitor. If you’re using PlatformIO on VSCode, you need to add these lines to your platformio.ini file in the env section:

INI

monitor_flags = --eol CR

1
2
3

monitor_flags =
--eol
CR

It’s funny.. @ensign and I were on a call the other day with someone who had just started working with a different SARA R410M board and was praising the chip’s reliability. My response was “if you haven’t seen any issues with it yet, it’s because you haven’t used it enough.”
2019-11-08 at 6:10 PM #13316
Matt Barney
Participant
Hi Sara,

Initially I was testing on USB power only, but will now keep the LiPo plugged in as well, though no success so far with that. (I’m guessing the LiPo is needed to provide adequate current for signal transmission?) I’m testing in my office in an urban area where we have good Verizon and AT&T signals. I did carefully press the antenna’s u.Fl connection together a couple of times just in case it wasn’t fully engaged.

I have never gotten the XBee3 to connect. I will try changing the timeout from 2 min to something longer and report back. Would this only be needed the first time you bring a new XBee3 online, and then could change it back to to minutes before deploying into the field?

I have tried Bypass mode previously, but changed back to Transparent after not having luck.

Yeah, I was wondering whether I needed to check firmware versions, and was just beginning to read about that in Digi’s docs. Do I need additional hardware to connect the XBee to the PC in order to use XCTU?

I’ll try modifying the line endings and post the logs.

Thanks!
2019-11-09 at 1:40 PM #13317
Matt Barney
Participant
I modified line endings and changed the wait time to 30 minutes: modem.connectInternet(1800000L). I then had to leave and left the Mayfly running overnight. Still no data at MMW, but I now see connections being logged on my Hologram dashboard, and a single message that shows data usage: https://drive.google.com/file/d/15FjVP3x_ySw_IEkIQVZ0OvbIB9x8UpQ1/view?usp=sharing . With the exception of that one, 1.88KB, all other data sessions show 0 bytes: https://drive.google.com/open?id=1YXvI1Kv9nn6ZgoKBINbav9SArQEFB-3b”

Also, here is my terminal log file (~2MB): https://drive.google.com/open?id=13_cvDM8-UMZ5dJueux9vZjbe9g5GmIcW
2019-11-10 at 3:53 PM #13319
neilh20
Participant
I had a similar problem – see my comment in https://www.envirodiy.org/topic/trouble-registering-with-lte-m-network-on-hologram/
The fix that seemed to work was if it didn’t connect after a 100 AI status polls it issues
gsmModem.sendAT(GF(“+CREG”));
Search for +CREG in
https://github.com/neilh10/ModularSensors/blob/rel1_dvlp1m/src/modems/DigiXBeeCellularTransparent.cpp

My Hologram with data connection every 4hrs looks like this – pink is no session , blue is with data
Attachments:
1. 191110HologramTimeLine.jpg

2019-11-11 at 5:49 PM #13322

Sara Damiano

Moderator

Oops. So, it never tried for longer than 15 minutes with that sketch because the watchdog doesn’t get “fed” while it’s waiting for the internet and it “bites” (ie, forces the board to reset) after 15 minutes. But 15 minutes is still a pretty long time to wait.

After the first connection in a new location, it should connect much faster in subsequent attempts. That is, if you can convince it to connect at all. From your log it doesn’t look like there’s anything wrong with the board programming; the XBee is just really, really convinced that it cannot connect to the network. Can you go back and try bypass mode again with both the USB *and* the LiPo plugged in and post that log? The trick that @neilh20 recommended is basically to send the XBee the command you would have used if you were in bypass mode but without actually entering bypass. Of course, based on all the manuals, that *shouldn’t* work, but if it’s stupid and it works…

To connect the XBee3 with XCTU you do need another adapter or development board. The XBee3 TH development board is probably the easiest way to connect them (https://www.digi.com/products/models/xbib-cu-th) because it uses USB-C to provide enough power and also separately breaks out the USB direct pins for easy plugging in straight to the SARA module. If you’re going to be using a bunch of XBee3’s, just spend the $70 and make your life a lot easier. If this is a one-off, I think there are ways to update “over the air” but it’s not as easy. To just check your firmware version you can run something like this on the Mayfly:

#include <StreamDebugger.h>

void setup() {
  // Set console baud rate
  Serial.begin(115200);
  delay(10);

  // Set XBee module baud rate
  Serial1.begin(9600);

  // Get into command mode
  delay(1500);
  Serial.println('+++');
  Serial1.print('+++');
  while (!Serial1.available()){}
  while (Serial1.available()) {
    Serial.print(Serial1.read());
  }
  Serial.println();

  // Sometimes it "forgets" to answer requests for versions, so we'll try 5 times
  for (uint8_t i = 0; i < 5; i++) {
    // Get the Digi firmware version
    Serial.println('ATVR');
    Serial1.println('ATVR');
    while (!Serial1.available()){}
    while (Serial1.available()) {
      Serial.print(Serial1.read());
    }
    Serial.println();

    // Get the u-blox firmware version
    Serial.println('ATMV');
    Serial1.println('ATMV');
    while (!Serial1.available()){}
    while (Serial1.available()) {
      Serial.print(Serial1.read());
    }
    Serial.println();
  }

}

void loop() {
}

#include <StreamDebugger.h>

void setup() {

// Set console baud rate

Serial.begin(115200);

delay(10);

// Set XBee module baud rate

Serial1.begin(9600);

// Get into command mode

delay(1500);

Serial.println('+++');

Serial1.print('+++');

while (!Serial1.available()){}

while (Serial1.available()) {

Serial.print(Serial1.read());

}

Serial.println();

// Sometimes it "forgets" to answer requests for versions, so we'll try 5 times

for (uint8_t i = 0; i < 5; i++) {

// Get the Digi firmware version

Serial.println('ATVR');

Serial1.println('ATVR');

while (!Serial1.available()){}

while (Serial1.available()) {

Serial.print(Serial1.read());

}

Serial.println();

// Get the u-blox firmware version

Serial.println('ATMV');

Serial1.println('ATMV');

while (!Serial1.available()){}

while (Serial1.available()) {

Serial.print(Serial1.read());

}

Serial.println();

}

void loop() {

}

2019-11-12 at 5:03 PM #13324
Matt Barney
Participant
Neil and Sara, thank you both! Last night, before seeing your posts, I began testing again while in a different location (happens to be much more remote). I switched to Bypass mode last night, and it appears to be working! Now back in my office in the city, it works as well. I’ll attach my logfile as an fyi.

The above sketch displays firmware version 11051. I should probably buy the XBee3 TH development board.
Attachments:
1. logFileNov11.txt
2019-11-13 at 10:56 AM #13329
Sara Damiano
Moderator
Yay! That’s more like it.

There are several posts and GitHub issues comparing the two but here’s a quick summary:

Bypass:
+ connects to the network faster
+ near 100% success in sending data if a network connection is made
– every transmission uses very slightly more data (in uncontrollable overhead – unsure why)
– Digi strongly discourages use of bypass
– rarely freezes logger to the point of a watch dog reset (cause unknown)

Transparent:
+ recommended by Digi
+ uses very slightly less data
– takes longer to connect
– occasional empty sessions where the internet connection is made but data isn’t successfully transferred (suspect a problem within the Digi firmware in packeting the data)

Author

Posts

Viewing 7 reply threads

You must be logged in to reply to this topic.

Attachments:

Attachments:

Attachments: