XBEE 3G initialization errors

[Mikelanner]

Hello, Im trying to use my XBEE 3g global with your library but im encountering a few issues.

TinyGSM version: 0.3.5 (latest) Hardware: Feather m0 connected to XBEE 3G global version using the hardware serial interface. Can confirm both units work as i can successfully perform http get/set using ubidots and XCTU as well as the Mouser example

Scenario

Trying to test the http client example provided. added the line #define TINY_GSM_MODEM_XBEE which was missing from the example The modem attempts to initialize and wait for the network but it fails

Initializing modem... Modem: Waiting for network...

AT command log

From the Arduino Serial monitor (now with Dump AT COMMANDS) + +++ +++Initializing modem... ++++++++++++Modem: Waiting for network...+++++++++++++++++++++++++++++++++++++ (and other ~100 +) Waiting for network...+++++++++++++++++++++++++++++++++++++ (and other ~100 +) +++Cac+++he-+++Con+++tro+++l: +++no-+++cac+++he +++Con+++nec+++tio+++n: +++clo+++se +++Con+++ten+++t-T+++ype+++: t+++ext+++/ht+++ml +++ <h+++tml+++><b+++ody+++><h+++1>4+++00 +++Bad+++ re+++que+++st<+++/h1+++> Y+++our+++ br+++ows+++er +++sen+++t a+++n i+++nva+++lid+++ re+++que+++st.+++ </+++bod+++y><+++/ht+++ml>+++

Using Termite, I've monitored the feather TX/DIN pin of the XBEE modem and the output is literally hundreds of +'s with no white space or new lines etc.

Has anyone had any success using this Library with the XBEE?

[SRGDamia1]

Yikes. I wrote the XBee block and have it working fine with the 3GBee.

It's sending all the plus signs because it's trying to get the board to enter "command mode". If you look closely at the timing, it should be holding (guard time) putting out three plus signs and then waiting for the "OK" that the board has gone into command mode.

Is it possible that your XBee board is sleeping? (SO set in XCTU) Have you possibly changed the guard time or command mode settings in XCTU?

Could you possibly post your XCTU settings (minus ip's, etc)? Can you confirm that you can get the board into command mode with the terminal in XCTU or termite?

Sorry! I'm have a few fixes that I've put in on my fork (https://github.com/EnviroDIY/TinyGSM) that I'm cleaning up for a PR, but I don't know if they'd make any difference in this.

[SRGDamia1]

Also, when you're hooking your Bee up, are you giving it enough power? Digi recommends that you give it access to at least 5W of power (1.5A at 3.3V). When I've connected mine on the "typical" boards that give only < 500 mA I can often get it to respond for a little bit, but then it "browns out" and stops responding when it tries to connect.

[SRGDamia1]

I have a Feather M0, so I thought I would give it a shot.. and it worked for me. I'm connecting the bee Tx and Rx to Serial1 (pins D0/D1) and have the Bee Vcc connected to Vbat with a LiPo battery attached. Don't try to use the 3.3V or Vbus pins on the Feather, they're only rated to 400mA and 500 mA, respectively.

[Mikelanner]

Hi Sara Lots to reply to, sorry not entirely in order either :) Hardware wise: The Feather is powered by USB while the Xbee is powered by a bench top supply @3.3V with a couple of 100uF caps. The serial connections are the same (D0/D1) and BAUD is 9600 (default for the xbee)

I can get the XBEE into command mode using termite. (Three +'s followed by a empty message both with no CR or L,F and then i receive the OK. All other AT commands thereafter with CR and LF). Can also do with with XCTU.

I trying removing the TINYGSM library and replacing it with yours, still have the same issue.

Im using the default settings for XCTU.

Hopefully I've removed all the important stuff!

[SRGDamia1]

I went back and tried re-ran exactly that example.. and got exactly the same results as you. I'd been running a different example.

It turned out there were all kinds of bugs. I'd assumed that everyone would always run the init()/begin() function first and had the guard times and module series set in that function. Since that example jumps right into restart() the guard time was un-set so it would never have gotten into command mode. There was also a botched goto statement in the restart that was causing it to endlessly loop. So it just spit out millions of plus signs.

I'm working now to fix everything up. I'll push it soon for you to try.

[SRGDamia1]

Okay, I've pushed to my fork and added to the PR here. Please let me know if this fixes it for you!

Thank you for helping to debug everything!

[Mikelanner]

Awesome stuff!

Already looking much better although there are some peculiarities around the HTTP/HTTPS get sample, particularly the ATLA command. It seems to 'hang' after the first +++ATLAvsh.pp.ua command before suddenly spitting out the next 6.

[SRGDamia1]

I'm glad it's working better!

The behavior around the "ATLA" (lookup address) command is actually a quirk (problem?) with the XBee's themselves. The XBee's will only open up a socket to a numeric IP address, so if you don't know the IP address you have to look it up. Hence, the ATLA command. But the XBee's IP-address-resolving skills seem to be less than stellar. It often takes it a while to resolve the address and sometimes doesn't at all (returns "ERROR"). For some reason, it always seems to take a long time and then fail once, and then fail fast several times before (usually) giving a response. I'm giving the module up to 45 seconds in waiting/retrying to get the IP address resolved so it can then open the socket. The long wait is why it seems to hang.

If you're setting up an XBee to regularly send out data to something that has a known/stable IP address, I'd definitely recommend just typing in the IP instead of using the name. Some IP's it just never seems to get. (It cannot seem to manage time.gov at all.)

Also, by default the guard time to get into command mode is 1 second. In the init() function I cut that down to 100ms so everything will run a bit faster. I left the settings change out of the restart so someone could factory reset and then restart. Unless you have a reason not to, I'd suggest starting with the init() function to get the speed boost. Someday it might be better to re-write to use API mode so there would be no waits on command mode and multiple sockets would be available, but the API frames are much more complicated and not something I want to mess with right now.

[Mikelanner]

Hi Sara Sorry i wasn't too clear in my last message. But first, a BIG thank you for all your awesome contributions to these repos! The code never seems to execute beyond this while loop (see the added prints). It seems my first screen shot was a red herring as i've never been able to achieve the same result. However, the get command is correct and setup till that point does seem to be correct! If i connect the xbee to xctu and go straight to console working mode, i can send a packet of the text highlight in the above image (with the required 0D 0As appended) i get this lovely result.

[Mikelanner]

Decided to monitor the output of the XBEE instead now (still using termite) and its almost identical to the XCTU output! While the Serial monitor output is still (you can see the added "here" print) My guess is that this is an issue with the Http library

[SRGDamia1]

I'm still stuck on this one. It should go through to completion. I just wanted to let you know that I haven't forgotten about it.

[SRGDamia1]

I've finally figured out why this is happening, but I haven't figured out a work-around yet.

The loop never finishes (gets to "there") because there's a buffer overflow. The XBee implementation is using the buffer from whatever stream you're inputting into it (probably 64 bytes from Serial or SoftwareSerial). All the parsing the HTTP library is doing as it reads in characters slows it down too much so it doesn't read characters as fast as they XBee spits them out (even at 9600 baud..). If it runs out of characters after a header has started, but before the next new line, the http.headerAvailable() function hangs. The powers that be didn't make that function smart enough to realize that if there's nothing left in the incoming buffer, the header won't ever finish. You would see the same thing on any of the other chips that don't have internal buffering (ESP, A6, M590) if the TinyGSM buffer overflows. The XBee just has a smaller buffer (ie, not the TinyGSM FIFO) and overflows silently.

[SRGDamia1]

I've played with forcing the XBee to use a secondary buffer to allow it more space, but it's just not as stable for me. I just don't see a way to make the HttpClient work with the XBee unless you slow your XBee down or modify your serial buffer to have more space.

Sorry!