Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of Home › Forums › Mayfly Data Logger › uBee R410 setup issues › Reply To: uBee R410 setup issues
It’s awesome that you’ve created your own publisher! I’m really excited you’ve been able to pick up and modify this library to be useful for something new!
Ok. I see what’s happening. The R410M takes a *really* long time to close sockets (like 2 minutes). To speed things up, I call the socket close “asynchronously” – that is, tell it to close and move on. But what I think is happening here is that I’m telling the socket to close before opening a new one, just to be safe. (AT+USOCL=0,1 is close sock 0 with async flag) So the ‘close’ command goes out and the u-blox either spits out a not allowed error if the socket in question wasn’t open or says ok and starts doing whatever it is that takes it ages to do it to close a socket. In your case, it must believe the socket is open (it said ok). Then without waiting for that socket to finish closing, we ask the ublox to open a new socket (AT+USOCR=6 – open socket, 6=TCP, don’t tell it the number), which it does. But, idiotically, it assigns us the new socket as socket 0 +USOCR: 0 which it is supposed to be in the process of closing. It even happily sets socket options (USOSO) and connects (USOCO), but, low and behold, somewhere in there the socket close command finally took effect and when you try to write to the socket.. you’re not allowed. Why the chip isn’t smart enough to assign a new socket number when we try to create the new socket after asynchronously closing the old one, I do not know. I also don’t understand why it didn’t return an error when asked to close the socket. Based on your log, it shouldn’t have been open in the first place. I don’t think I’ve ever seen it do that before.
Enough babble; how to fix it. Unfortunately, I think you’re going to have to do it within the TinyGSM library. In that library, open up the TinyGsmClientSaraR4.h file and scroll down to line 97ish. Un-comment the chunk for “synchronous close” and comment out the chunk for “faster asynchronous close”. It will slow you connecting down (by up to 2 minutes..) but hopefully it won’t reassign you a new socket overlapping a closing one.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
virtual void stop(uint32_t maxWaitMs) { TINY_GSM_CLIENT_DUMP_MODEM_BUFFER() // synchronous close <----------------------------------------------------------------- enable this chunk at->sendAT(GF("+USOCL="), mux); // NOTE: can take up to 120s to get a response at->waitResponse((maxWaitMs - (millis() - startMillis))); sock_connected = false; // // faster asynchronous close <------------------------------------------------------ and disable this chunk // // NOT supported on SARA-R404M / SARA-R410M-01B // at->sendAT(GF("+USOCL="), mux, GF(",1")); // // NOTE: can take up to 120s to get a response // at->waitResponse((maxWaitMs - (millis() - startMillis))); // sock_connected = false; } |
The double AT commands are because echo is being turned on by default every time the board powers up. I think the echo settings are *supposed* to be stored, but like the baud rate, are not. It isn’t a problem; the repeated commands get tossed. If you want to turn it off to save yourself some scrolling, you can find the modemWakeFxn in SodaqUbeeR410M and modify it to turn off the echo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
#if F_CPU == 8000000L if (_powerPin >= 0) { MS_DBG(F("Waiting for UART to become active and requesting a slower baud rate.")); delay(R410M_ATRESPONSE_TIME_MS + 250); // Must wait for UART port to become active _modemSerial->begin(115200); gsmModem.setBaud(9600); _modemSerial->end(); _modemSerial->begin(9600); gsmModem.sendAT(GF("E0")); // <--- Add this line to turn off the echo gsmModem.waitResponse(); // <--- listen for OK } #endif |
