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
Tagged: LTE, ModularSensors, R410M, ubee
- This topic has 20 replies, 3 voices, and was last updated 2021-04-23 at 4:46 AM by
BrodVictor.
-
AuthorPosts
-
-
2020-01-07 at 3:40 PM #13538
After I successfully got the uBee U201 to work for my application, Sodaq stopped producing that model and now only offers one based on the R410. So I’m working on getting the uBee R410 to work.
Scouring through this GitHub issue got me very close but can’t quite get it to work. I’m using hologram, ModularSensors 0.23.16 and a code based on menu_a_la_carte.ino. Sometimes the R410 will successfully register, but sometimes not. Here is an output upon powerup when it does NOT register:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175Powering unspecified modem with pin 23 <--SodaqUBeeR410MRunning wake function for unspecified modem <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 3201 ms <--SodaqUBeeR410MPulsed for 3201 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600Status pin 19 on unspecified modem is 0 indicating it is off! <--LoggerModemAttempting a hard reset on the modem! <--LoggerModemunspecified modem failed to wake! <--LoggerModemSetting up the modem ... <--LoggerModemWaking up the modem for setup ... <--LoggerModemRunning wake function for unspecified modem <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 64 ms <--SodaqUBeeR410MPulsed for 150 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600unspecified modem should be awake. <--LoggerModemRunning modem's begin function ... <--LoggerModemAT8��ATOKATE0ATE0OKAT+CMEE=0OKAT+CGMIu-bloxOKAT+GMMSARA-R410M-02BOKAT+CPIN?+CPIN: READYOKAT+CGMIu-bloxOKAT+GMMSARA-R410M-02BOKAT+URAT=7OK... Complete! It's a u-blox SARA-R410M-02B <--LoggerModemu-blox SARA-R410M-02B warms up in 250 ms, indicates status in 0 ms, is responsive to AT commands in less than 4500 ms, and takes up to 15000 ms to close connections and shut down. <--LoggerModemRunning given modem sleep function ... <--LoggerModemAsking u-blox R410M to power down <--SodaqUBeeR410MAT+CPWROFFOKAttempting to connect to the internet and synchronize RTC with NISTWaiting for u-blox SARA-R410M-02B to respond to AT commands... <--SodaqUBeeR410MATOK... AT OK after 35 milliseconds! <--SodaqUBeeR410MWaiting up to 120 seconds for cellular network registration... <--SodaqUBeeR410MAT+CEREG?+CEREG: 0,2OKAT+CEREG?␀AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?AT+CEREG?...GPRS connection failed. <--SodaqUBeeR410MCould not connect to internet for clock sync.And here’s an example when it DOES register, but cannot connect to NIST. When it does register, I see the activity on Hologram Dashboard.
Note that it hangs for about 6 minutes at the AT+CGATT=1 line and then fails to connect…
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485Powering unspecified modem with pin 23 <--SodaqUBeeR410MRunning wake function for unspecified modem <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 3201 ms <--SodaqUBeeR410MPulsed for 3201 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600Status pin 19 on unspecified modem is 0 indicating it is off! <--LoggerModemAttempting a hard reset on the modem! <--LoggerModemunspecified modem failed to wake! <--LoggerModemSetting up the modem ... <--LoggerModemWaking up the modem for setup ... <--LoggerModemRunning wake function for unspecified modem <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 64 ms <--SodaqUBeeR410MPulsed for 150 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600unspecified modem should be awake. <--LoggerModemRunning modem's begin function ... <--LoggerModemAT␐��ATATOKATE0ATE0OKAT+CMEE=0OKAT+CGMIu-bloxOKAT+GMMSARA-R410M-02BOKAT+CPIN?+CPIN: READYOKAT+CGMIu-bloxOKAT+GMMSARA-R410M-02BOKAT+URAT=7OK... Complete! It's a u-blox SARA-R410M-02B <--LoggerModemu-blox SARA-R410M-02B warms up in 250 ms, indicates status in 0 ms, is responsive to AT commands in less than 4500 ms, and takes up to 15000 ms to close connections and shut down. <--LoggerModemRunning given modem sleep function ... <--LoggerModemAsking u-blox R410M to power down <--SodaqUBeeR410MAT+CPWROFFOKAttempting to connect to the internet and synchronize RTC with NISTWaiting for u-blox SARA-R410M-02B to respond to AT commands... <--SodaqUBeeR410MATOK... AT OK after 32 milliseconds! <--SodaqUBeeR410MWaiting up to 120 seconds for cellular network registration... <--SodaqUBeeR410MAT+CEREG?+CEREG: 0,5OK... Registered after 98 milliseconds. Connecting to GPRS... <--SodaqUBeeR410MAT+CGATT=1␀... Connected after 360114 milliseconds. <--SodaqUBeeR410MAT+CGATT?No internet connection, cannot connect to NIST. <--SodaqUBeeR410MBad timestamp, not setting clock.Any ideas?
-
2020-01-07 at 4:50 PM #13541
Ugh. I should just get one of these R410 uBee’s just to help other people out.
It looks like it’s powering down when it’s supposed to be waking up and visa-versa.
I could babble at length about it, but my first suggestion to try and make it work it is to add a ~500ms delay [
delay(500);] after themodemPowerUp()and another matching delay after themodem.wake();in your setup function. Just see if that works. -
2020-01-07 at 5:25 PM #13542
I’ve attached some annotations showing what’s happening in your logs.
Attachments:
-
2020-01-07 at 6:55 PM #13545
Hi Sara,
Thanks for the reply and the helpful annotated logs. Unfortunately, that didn’t fix it, and it’s still doing the hard reset. Bummer! This issue seems reminiscent of the last post by acgold on that GH issue. This is what the relevant lines of my setup look like now, but still no dice. I also tried with a 1 second delay. Anything else?
1234567modem.modemPowerUp();Serial.println(F("Delaying 500 after powerup"));delay(500);modem.wake();Serial.println(F("Delaying 500 after wake"));delay(500);modem.setup();and the output
12345678910111213141516171819202122Powering unspecified modem with pin 23 <--SodaqUBeeR410MDelaying 500 after powerupRunning wake function for unspecified modem <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 3201 ms <--SodaqUBeeR410MPulsed for 3201 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600Status pin 19 on unspecified modem is 0 indicating it is off! <--LoggerModemAttempting a hard reset on the modem! <--LoggerModemunspecified modem failed to wake! <--LoggerModemDelaying 500 after wakeSetting up the modem ... <--LoggerModemWaking up the modem for setup ... <--LoggerModemRunning wake function for unspecified modem <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 80 ms <--SodaqUBeeR410MPulsed for 151 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600unspecified modem should be awake. <--LoggerModemRunning modem's begin function ... <--LoggerModem -
2020-01-08 at 11:23 AM #13551
Yes, it’s probably related to the same issues that @acgold had. These ublox modules just seem to be so much more finicky than the 2G SIM800’s were.
Could you try switching to the “ModemLast” branch? That’s where the most recent work is and I’d prefer to do more of the troubleshooting on that branch since it’s mostly modifications to the setup of the modem.
-
2020-01-08 at 7:19 PM #13560
Thank you Sara.
Inching closer. Prior to switching to the modemLast branch I tried something similar to what @acgold suggested. I added the following lines:
if (modemVccPin >= 0)
{
pinMode(modemSleepRqPin, OUTPUT);
digitalWrite(modemSleepRqPin, HIGH);
}to my file, just after
greenredflash();. This allowed the modem to wake up successfully and connect to the NIST timeserver on initial boot, which is certainly the farthest I’ve gotten with the R410. It does not successfully upload data after taking a reading, however, even though it goes through a lot of AT commands with “OK” responses, until it gets to:1234567891011121314151617181920212223AT+USOWR=0,167AT+USOWR=0,167+CME ERROR: Operation not allowedAT+USOWR=0,2AT+USOWR=0,2+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedI’ll try modemLast and see if I can get anywhere.
-
2020-01-08 at 10:48 PM #13561
Doh. Yes, I thought of that as I was driving home. Do add the lines setting the wake pin high.
Do you know what version of the firmware you’re running? To check, you can either hook it up to the u-blox m-center on your computer, run a pass through sketch and send it the commands AT+CGMR? and AT+GMR?, or tack these lines in after the modem setup:
C++12345modem.setup(); // add after this line in the setupmodem.gsmModem.sendAT(GF("+CGMR?")); // firmware version identificationmodem.gsmModem.waitResponse();modem.gsmModem.sendAT(GF("+GMR?")); // firmware version identificationmodem.gsmModem.waitResponse();The
AT+USOWR=0,##commands are attempting to write data over an TCP socket. Usually when I’ve seen the “operation not allowed” it’s either because either the socket was already closed somehow or it was never open in the first place. All those other commands that are failing are trying to check the socket status or get data from it. They’ll also spit out that “not allowed” error if the socket they’re asking about isn’t live. What happened in your log before that first failure? Were there anyUSOWRcommands that got ok back? Was there a+UUSOCLin there (that means that the socket was closed externally)? What was the result of the+USOCRcommand (opening the socket)?The reason I asked about the firmware is mostly curiosity. One of the “improvements” in the latest version was related to it locking up and I have noticed improvements with the newer firmware, but it should be able to get through with the older version
-
2020-01-09 at 1:03 PM #13576
Thanks Sara. Some more info for you. First, the CGMR and GMR commands both result in the response ERROR, as you can see in the output below.
Additionally, it sometimes seems to struggle getting a connection to NIST, also as in the example below. It took two tries before it finally connected, and this seems to be commonb. Note also the funkiness in the shutdown code.
No USOWRs with OK responses (only +CME ERROR: Operation not allowed), No UUSOCL anywhere, and the result of USOCR was variable. You can see the different USOCR responses in the NIST connection below.
Now, I am using a bit of a homebrew solution for sending data. I’m not using EnviroDIY publisher or any of the other built-in methods but instead am using the Hologram Cloudsocket API. I modified EnviroDIYPublisher.cpp and .h to create HologramPublisher.cpp, .h to send data to Hologram, which has been working quite well on the two other modems I have (Sodaq GPRSbee and uBee U201). It seems a bit weird that there are double AT commands echoed to the log when trying to send data.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213Powering unspecified modem with pin 23 <--SodaqUBeeR410MRunning wake function for unspecified modem <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 80 ms <--SodaqUBeeR410MPulsed for 150 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600unspecified modem should be awake. <--LoggerModemSetting up the modem ... <--LoggerModemModem was already awake and should be ready for setup. <--LoggerModemRunning modem's begin function ... <--LoggerModemAT8��ATOKATE0ATE0OKAT+CMEE=0OKAT+CGMIu-bloxOKAT+GMMSARA-R410M-02BOKAT+CPIN?+CPIN: READYOKAT+CGMIu-bloxOKAT+GMMSARA-R410M-02BOKAT+URAT=7OK... Complete! It's a u-blox SARA-R410M-02B <--LoggerModemu-blox SARA-R410M-02B warms up in 250 ms, indicates status in 0 ms, is responsive to AT commands in less than 4500 ms, and takes up to 15000 ms to close connections and shut down. <--LoggerModemLeaving modem on after setup ... <--LoggerModemAT+CGMR?ERRORAT+GMR?ERRORAttempting to connect to the internet and synchronize RTC with NISTWaiting for u-blox SARA-R410M-02B to respond to AT commands... <--SodaqUBeeR410MATOK... AT OK after 35 milliseconds! <--SodaqUBeeR410MWaiting up to 120 seconds for cellular network registration... <--SodaqUBeeR410MAT+CEREG?+CEREG: 0,2OKAT+CEREG?+CEREG: 0,2OKAT+CEREG?+CEREG: 0,5OK... Registered after 719 milliseconds. Connecting to GPRS... <--SodaqUBeeR410MAT+CGATT=1OKAT+CGDCONT=1,"IP","hologram"OKAT+CGACT=1,1OK... Connected after 885 milliseconds. <--SodaqUBeeR410MAT+CGATT?+CGATT: 1OKAT+CGPADDR+CGPADDR: 1,10.191.68.253OKConnecting to NIST daytime Server <--SodaqUBeeR410MAT+USOCL=0,1OKAT+USOCR=6+USOCR: 0OKAT+USOSO=0,6,1,1OKAT+USOCO=0,"time.nist.gov",37,1OKAT+USORD=0,0ERRORAT+USOCTL=0,10ERRORNIST Time server did not respond! <--SodaqUBeeR410MConnecting to NIST daytime Server <--SodaqUBeeR410MAT+USOCL=0,1ERRORAT+USOCR=6+USOCR: 1OKAT+USOSO=1,6,1,1OKAT+USOCO=1,"time.nist.gov",37,1OKAT+USORD=1,0+USORD: 1,4OKNIST responded after 73 ms <--SodaqUBeeR410MAT+USORD=1,4+USORD: 1,4,"���"OKAT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,9OKAT+USOCL=1,1OKResponse Byte 0 : � = 225 = 11100001 <--LoggerModemResponse Byte 1 : � = 193 = 11000001 <--LoggerModemResponse Byte 2 : � = 229 = 11100101 <--LoggerModemResponse Byte 3 : � = 128 = 10000000 <--LoggerModemSeconds from Jan 1, 1900 returned by NIST (UTC): 3787580800 = 11100001110000011110010110000000 <--LoggerModemUnix Timestamp returned by NIST (UTC): 1578592000 <--LoggerModemClock already within 5 seconds of time.Setting up sensors...Enabling interrupts for SDI12 on pin 7 <--SDI12SensorsAsking for sensor acknowlegement <--SDI12Sensors>>> 0! <--SDI12Sensors<<< ␀ <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12SensorsSetting up file on SD cardData will be saved as bel_2020-01-09.csvPutting modem to sleepAT+CGACT=0ERRORAT+CGATT=0OKDisconnected from cellular network after 428 milliseconds. <--SodaqUBeeR410MTurning u-blox SARA-R410M-02B off. <--LoggerModemRunning given sleep function for u-blox SARA-R410M-02B <--LoggerModemAsking u-blox R410M to power down <--SodaqUBeeR410MAT+CPWROFFOKTotal modem active time (s): 38.672 <--LoggerModemWaiting up to 15000 milliseconds for graceful shutdown as indicated by pin 19 going 0 ... <--LoggerModem... shutdown complete after 68 ms. <--LoggerModemTotal modem power-on time (s): 43.606 <--LoggerModemTurning off power to u-blox SARA-R410M-02B with pin 23 <--LoggerModemPutting processor to sleepand then sending data:
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490Powering u-blox SARA-R410M-02B with pin 23 <--SodaqUBeeR410MSkipping u-blox SARA-R410M-02B in sensor power up! <--LoggerModemRunning wake function for u-blox SARA-R410M-02B <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 80 ms <--SodaqUBeeR410MPulsed for 150 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600u-blox SARA-R410M-02B should be awake. <--LoggerModemAT#TH�Enabling interrupts for SDI12 on pin 7 <--SDI12SensorsAsking for sensor acknowlegement <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12SensorsAsking for sensor acknowlegement <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 is not currently measuring! <--SDI12SensorsATATOKIt's been 2454 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 2704 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemATATOKIt's been 2954 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 3205 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 3455 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemATATOKIt's been 3705 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 3955 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 4205 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 4455 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 4705 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemATATOKIt's been 4956 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 5206 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 5456 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 13,99OKAsking modem to give signal quality: <--LoggerModemGetting signal quality: <--SodaqUBeeR410MAT+CSQAT+CSQ+CSQ: 13,99OKRaw signal quality: 13 <--SodaqUBeeR410MRSSI Estimated from CSQ: -87 <--SodaqUBeeR410MSignal percent calcuated from CSQ: 42 <--SodaqUBeeR410MRSSI: -87 <--LoggerModemPercent signal strength: 42 <--LoggerModemGetting battery info, if possible: <--LoggerModemGetting modem battery data: <--SodaqUBeeR410MAT+CIND?AT+CIND?+CIND: 5,2,1,0,0,1,1,0,1,0,0,2OKModem battery charge state: 0.00 <--LoggerModemModem battery percentage: 100.00 <--LoggerModemModem battery voltage: 0.00 <--LoggerModemGetting chip temperature, if possible: <--LoggerModemGetting temperature: <--SodaqUBeeR410MAT+UTEMP=0AT+UTEMP=0ERRORTemperature: -9999.00 <--SodaqUBeeR410MModem temperature: -9999.00 <--LoggerModemPRIOR modem active time: 96.359 <--LoggerModemPRIOR modem powered time: 105.386 <--LoggerModemSkipping u-blox SARA-R410M-02B in sensor power down! <--LoggerModem\/---- Line Saved to SD Card ----\/2020-01-09 17:55:00,3,4.745,23.00,42,-9999,-9999.0,-9999.0,-9999.0,-9999.0,-9999.00Waiting for u-blox SARA-R410M-02B to respond to AT commands... <--SodaqUBeeR410MATATOK... AT OK after 39 milliseconds! <--SodaqUBeeR410MWaiting up to 50 seconds for cellular network registration... <--SodaqUBeeR410MAT+CEREG?AT+CEREG?+CEREG: 0,5OK... Registered after 131 milliseconds. Connecting to GPRS... <--SodaqUBeeR410MAT+CGATT=1AT+CGATT=1OKAT+CGDCONT=1,"IP","hologram"AT+CGDCONT=1,"IP","hologram"OKAT+CGACT=1,1AT+CGACT=1,1OK... Connected after 397 milliseconds. <--SodaqUBeeR410MSending data to [ 0 ] cloudsocket.hologram.ioRUNNING IN HOLOGRAM <--HologramPublisherOutgoing JSON size: 509 <--HologramPublisherConnecting client <--HologramPublisherAT+USOCL=0,1AT+USOCL=0,1OKAT+USOCR=6AT+USOCR=6+USOCR: 0OKAT+USOSO=0,6,1,1AT+USOSO=0,6,1,1OKAT+USOCO=0,"cloudsocket.hologram.io",9999,1AT+USOCO=0,"cloudsocket.hologram.io",9999,1OKClient connected after 77302 ms<--HologramPublisher{"k":"xxxxxxxx","d":"time,2020-01-09T17:55:00Z,sample,3,boardbatt,4.745,boardtemp,23.00,signalpct,42,Dm,-9999,Sm,-9999.0,Pa,-9999.0,Ta,-9999.0,Ua,-9999.0,Rc,-9999.00"}AT+USOWR=0,167AT+USOWR=0,167+CME ERROR: Operation not allowedAT+USOWR=0,2AT+USOWR=0,2+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowedStopping client <--HologramPublisherAT+USOCL=0,1AT+USOCL=0,1+CME ERROR: Operation not allowedClient stopped after 92 ms <--HologramPublisher-- Response Code --504AT+CGACT=0AT+CGACT=0ERRORAT+CGATT=0AT+CGATT=0OKDisconnected from cellular network after 499 milliseconds. <--SodaqUBeeR410MTurning u-blox SARA-R410M-02B off. <--LoggerModemRunning given sleep function for u-blox SARA-R410M-02B <--LoggerModemAsking u-blox R410M to power down <--SodaqUBeeR410MAT+CPWROFFAT+CPWROFFOKTotal modem active time (s): 95.746 <--LoggerModemWaiting up to 15000 milliseconds for graceful shutdown as indicated by pin 19 going 0 ... <--LoggerModem... shutdown complete after 1307 ms. <--LoggerModemTotal modem power-on time (s): 102.850 <--LoggerModemTurning off power to u-blox SARA-R410M-02B with pin 23 <--LoggerModem -
2020-01-09 at 3:08 PM #13582
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,1is 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: 0which 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.
C++12345678910111213141516virtual void stop(uint32_t maxWaitMs) {TINY_GSM_CLIENT_DUMP_MODEM_BUFFER()// synchronous close <----------------------------------------------------------------- enable this chunkat->sendAT(GF("+USOCL="), mux);// NOTE: can take up to 120s to get a responseat->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:
C++12345678910111213#if F_CPU == 8000000Lif (_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 echogsmModem.waitResponse(); // <--- listen for OK}#endif -
2020-01-09 at 3:24 PM #13584
Oh, and yes, the issue with NIST is really common. There have been a few GitHub issues about it. I’m trying to connect over TCP to the daytime server. That server is designed to respond to any incoming connection on port 37 with 4 bytes representing the current timestamp and immediately close the connection. A lot of the time the various modems see the connection as closed before they’ve had a chance to tell you that any data was received. So I wait 4 seconds (as required by NIST) and try again, up to 5 times.
It would be much more efficient (and accurate) to connect to a proper NTP (network time protocol) server and get the time that way. But NTP is run over UDP and I don’t know of any libraries that support both TCP and UDP connections on more than 1 single device type the way that TinyGSM does for TCP. With TinyGSM, it’s only a few lines of code to switch from a 2G to 3G to 4G to wifi connection. It’s on my to-do list to implement full UDP support in TinyGSM, but I have no timeframe for it happening.
-
2020-01-09 at 8:34 PM #13586
Sara, this is really amazing support. Thank you very much for your contributions to the community.
Unfortunately, problems persist. As far as I can tell, switching to synchronous close did not improve the situation. I’m attaching another log, this time with TINY_GSM_DEBUG enabled. We are still sometimes getting
+CME ERROR: Operation not allowedwithUSOCL. Hopefully the TINY_GSM_DEBUG messages will help with tracking down what’s going on… I don’t really follow all the internals of the AT commands but I do wonder why it’s closing immediately after theConnecting to NIST daytime Servermessage.123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888Connecting to NIST daytime Server <--SodaqUBeeR410M[208889] ***** Doing synchronous close on 1AT+USOCL=1+CME ERROR: Operation not allowedAT+USOCR=6+USOCR: 1OKAT+USOSO=1,6,1,1OKAT+USOCO=1,"time.nist.gov",37,1OK[224096] ### Unhandled: OKAT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[226238] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[226742] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[227244] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[227745] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[228247] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[228749] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[229251] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[229752] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[230254] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[230754] ### AVAILABLE: 0 on 1NIST Time server did not respond! <--SodaqUBeeR410M[231108] ***** Doing synchronous close on 1AT+USOCL=1OKConnecting to NIST daytime Server <--SodaqUBeeR410M[265910] ***** Doing synchronous close on 1AT+USOCL=1+CME ERROR: Operation not allowedAT+USOCR=6+USOCR: 1OKAT+USOSO=1,6,1,1OKAT+USOCO=1,"time.nist.gov",37,1OK[281118] ### Unhandled: OKAT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[283258] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,4OK[283760] ### AVAILABLE: 0 on 1AT+USORD=1,0+USORD: 1,4OK[284194] ### AVAILABLE: 4 on 1NIST responded after 1081 ms <--SodaqUBeeR410MAT+USORD=1,4+USORD: 1,4,"��Q�"OK[284278] ### READ: 4 from 1AT+USORD=1,0+USORD: 1,0OKAT+USOCTL=1,10+USOCTL: 1,10,9OK[284418] ### AVAILABLE: 0 on 1[284424] ***** Doing synchronous close on 1AT+USOCL=1OKResponse Byte 0 : � = 225 = 11100001 <--LoggerModemResponse Byte 1 : � = 194 = 11000010 <--LoggerModemResponse Byte 2 : Q = 81 = 1010001 <--LoggerModemResponse Byte 3 : � = 245 = 11110101 <--LoggerModemSeconds from Jan 1, 1900 returned by NIST (UTC): 3787608565 = 11100001110000100101000111110101 <--LoggerModemUnix Timestamp returned by NIST (UTC): 1578619765 <--LoggerModemClock already within 5 seconds of time.Setting up sensors...Enabling interrupts for SDI12 on pin 7 <--SDI12SensorsAsking for sensor acknowlegement <--SDI12Sensors>>> 0! <--SDI12Sensors<<< ␀ <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12SensorsSetting up file on SD cardData will be saved as bel_2020-01-10.csvPutting modem to sleepAT+CGACT=0ERRORAT+CGATT=0OKDisconnected from cellular network after 368 milliseconds. <--SodaqUBeeR410MTurning u-blox SARA-R410M-02B off. <--LoggerModemRunning given sleep function for u-blox SARA-R410M-02B <--LoggerModemAsking u-blox R410M to power down <--SodaqUBeeR410MAT+CPWROFFOKTotal modem active time (s): 281.107 <--LoggerModemWaiting up to 15000 milliseconds for graceful shutdown as indicated by pin 19 going 0 ... <--LoggerModem... shutdown complete after 66 ms. <--LoggerModemTotal modem power-on time (s): 286.040 <--LoggerModemTurning off power to u-blox SARA-R410M-02B with pin 23 <--LoggerModemPutting processor to sleep------------------------------------------Powering u-blox SARA-R410M-02B with pin 23 <--SodaqUBeeR410MSkipping u-blox SARA-R410M-02B in sensor power up! <--LoggerModemEnabling interrupts for SDI12 on pin 7 <--SDI12SensorsAsking for sensor acknowlegement <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12SensorsAsking for sensor acknowlegement <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12Sensors>>> 0! <--SDI12Sensors<<< <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 did not reply! <--SDI12SensorsVaisalaWXT520 at SDI12-0_Pin7 is not currently measuring! <--SDI12SensorsRunning wake function for u-blox SARA-R410M-02B <--LoggerModemSending a wake-up pulse on pin 20 for Sodaq UBee R410M <--SodaqUBeeR410MStatus pin came on after 82 ms <--SodaqUBeeR410MPulsed for 151 ms <--SodaqUBeeR410MWaiting for UART to become active and requesting a slower baud rate. <--SodaqUBeeR410MAT+IPR=9600u-blox SARA-R410M-02B should be awake. <--LoggerModemAT8��[294584] ### Unhandled: 8��ATATOKIt's been 309 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,2OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 559 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemATATOKIt's been 809 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 1059 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 1309 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemATATOKIt's been 1561 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 1812 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 2062 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 2312 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 2562 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 2812 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 3062 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 3312 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemATATOKIt's been 3563 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 3813 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 4063 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 4313 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 4563 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 4813 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 5063 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemATATOKIt's been 5314 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 99,99OKATATOKIt's been 5564 ms, and u-blox SARA-R410M-02B is now responding to AT commands! <--LoggerModemAT+CEREG?AT+CEREG?+CEREG: 0,5OKAT+CSQAT+CSQ+CSQ: 15,99OKAsking modem to give signal quality: <--LoggerModemGetting signal quality: <--SodaqUBeeR410MAT+CSQAT+CSQ+CSQ: 15,99OKRaw signal quality: 15 <--SodaqUBeeR410MRSSI Estimated from CSQ: -83 <--SodaqUBeeR410MSignal percent calcuated from CSQ: 48 <--SodaqUBeeR410MRSSI: -83 <--LoggerModemPercent signal strength: 48 <--LoggerModemGetting battery info, if possible: <--LoggerModemGetting modem battery data: <--SodaqUBeeR410MAT+CIND?AT+CIND?+CIND: 5,2,1,0,0,1,1,0,1,0,0,2OKModem battery charge state: 0.00 <--LoggerModemModem battery percentage: 100.00 <--LoggerModemModem battery voltage: 0.00 <--LoggerModemGetting chip temperature, if possible: <--LoggerModemGetting temperature: <--SodaqUBeeR410MAT+UTEMP=0AT+UTEMP=0ERRORTemperature: -9999.00 <--SodaqUBeeR410MModem temperature: -9999.00 <--LoggerModemPRIOR modem active time: 281.107 <--LoggerModemPRIOR modem powered time: 286.040 <--LoggerModemSkipping u-blox SARA-R410M-02B in sensor power down! <--LoggerModem\/---- Line Saved to SD Card ----\/2020-01-10 01:30:00,2,4.761,23.75,48,-9999,-9999.0,-9999.0,-9999.0,-9999.0,-9999.00Waiting for u-blox SARA-R410M-02B to respond to AT commands... <--SodaqUBeeR410MATATOK... AT OK after 39 milliseconds! <--SodaqUBeeR410MWaiting up to 50 seconds for cellular network registration... <--SodaqUBeeR410MAT+CEREG?AT+CEREG?+CEREG: 0,5OK... Registered after 133 milliseconds. Connecting to GPRS... <--SodaqUBeeR410MAT+CGATT=1AT+CGATT=1OKAT+CGDCONT=1,"IP","hologram"AT+CGDCONT=1,"IP","hologram"OKAT+CGACT=1,1AT+CGACT=1,1OK... Connected after 399 milliseconds. <--SodaqUBeeR410MSending data to [ 0 ] cloudsocket.hologram.ioRUNNING IN HOLOGRAM <--HologramPublisherOutgoing JSON size: 509 <--HologramPublisherConnecting client <--HologramPublisher[301012] ***** Doing synchronous close on 1AT+USOCL=1AT+USOCL=1+CME ERROR: Operation not allowedAT+USOCR=6AT+USOCR=6+USOCR: 0OKAT+USOSO=0,6,1,1AT+USOSO=0,6,1,1OKAT+USOCO=0,"cloudsocket.hologram.io",9999,1AT+USOCO=0,"cloudsocket.hologram.io",9999,1OK[376326] ### Unhandled: AT+USOCO=0,"cloudsocket.hologram.io",9999,1OK[378329] WARNING: Mux number changed from 1 to 0Client connected after 77319 ms<--HologramPublisher{"k":"xxxxxxxx","d":"time,2020-01-10T01:30:00Z,sample,2,boardbatt,4.761,boardtemp,23.75,signalpct,48,Dm,-9999,Sm,-9999.0,Pa,-9999.0,Ta,-9999.0,Ua,-9999.0,Rc,-9999.00"}AT+USOWR=0,167AT+USOWR=0,167+CME ERROR: Operation not allowedAT+USOWR=0,2AT+USOWR=0,2+CME ERROR: Operation not allowedAT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[378755] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[379262] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[379770] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[380276] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[380778] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[381288] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[381798] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[382308] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[382818] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[383324] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[383832] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[384339] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[384847] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[385355] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[385859] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[386369] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[386879] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[387389] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[387897] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[388403] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[388907] ### AVAILABLE: 0 on 0AT+USORD=0,0AT+USORD=0,0+CME ERROR: Operation not allowedAT+USOCTL=0,10AT+USOCTL=0,10+CME ERROR: Operation not allowed[389406] ### AVAILABLE: 0 on 0Stopping client <--HologramPublisher[389566] ***** Doing synchronous close on 0AT+USOCL=0AT+USOCL=0+CME ERROR: Operation not allowedClient stopped after 88 ms <--HologramPublisher-- Response Code --504AT+CGACT=0AT+CGACT=0ERRORAT+CGATT=0AT+CGATT=0OKDisconnected from cellular network after 479 milliseconds. <--SodaqUBeeR410MTurning u-blox SARA-R410M-02B off. <--LoggerModemRunning given sleep function for u-blox SARA-R410M-02B <--LoggerModemAsking u-blox R410M to power down <--SodaqUBeeR410MAT+CPWROFFAT+CPWROFFOKTotal modem active time (s): 95.838 <--LoggerModemWaiting up to 15000 milliseconds for graceful shutdown as indicated by pin 19 going 0 ... <--LoggerModem... shutdown complete after 1305 ms. <--LoggerModemTotal modem power-on time (s): 104.575 <--LoggerModemTurning off power to u-blox SARA-R410M-02B with pin 23 <--LoggerModem------------------------------------------ -
2020-01-10 at 5:28 PM #13594
Now it’s the asynchronous open that’s causing trouble. That *should* be blocking. The program should not continue until the URC arrives. I will need to test that more.
Anyway, another change in TinyGSM:
C++12345678910111213141516// Use an asynchronous open to reduce the number of terminal freeze-ups// This is still blocking until the URC arrives// The SARA-R410M-02B with firmware revisions prior to L0.0.00.00.05.08// has a nasty habit of locking up when opening a socket, especially if// the cellular service is poor.// NOT supported on SARA-R404M / SARA-R410M-01B// sendAT(GF("+USOCO="), *mux, ",\"", host, "\",", port, ",1"); <----------------------------- Comment out this section// waitResponse(timeout_ms, GF(GSM_NL "+UUSOCO: "));// stream.readStringUntil(',').toInt(); // skip repeated mux// int connection_status = stream.readStringUntil('\n').toInt();// return (0 == connection_status);// use synchronous open <----------------------------- Enable this sectionsendAT(GF("+USOCO="), *mux, ",\"", host, "\",", port, ",0");int rsp = waitResponse(timeout_ms);return (1 == rsp); -
2020-01-10 at 6:10 PM #13596
Oh, no, the hold for the URC *is* working. It’s just not holding for long enough. It gives up after 75s and the code wasn’t smart enough to differentiate between a ‘0’ = nothing in the returned buffer and ‘0’ = the modem returned that it opened the socket with 0 errors. The CSQ responses show good signal you’re already registered on the network with EPS.. What is it *doing* that takes it over a minute to establish the socket! I don’t know if switching to the synchronous open will help or not. It’s still going to give up after 75s and it might completely lock the whole thing up – that’s why I switched to async in the first place. But it’s worth a shot, I guess. If you start seeing outgoing AT commands with no responses after the socket open, it’s locked up and you need to power cycle.
If that doesn’t take or the board is locking up, you can increase the default timeout past 75s and see if waiting up to two or three minutes does anything more than waste your time. You have to do that in the CLIENT_OVERLOADS section of TinyGSM common. (line ~220 and ~224) [The timeout set in TinyGSM common takes precedence in this case.)
-
2020-01-10 at 6:11 PM #13597
I am so very unimpressed with the SARA R410. It does not deserve its name.
-
2020-01-14 at 2:10 PM #13612
Thank you Sara. Unfortunately those changes didn’t do the trick. I may have to fall back to using some GPRSbees for this project and hope that T-Mobile doesn’t shut down their 2G towers too soon 🙂
-
2020-01-14 at 4:07 PM #13614
I’m sorry! The SIM800 definitely has quirks, but it’s better than this. We have had better luck with the Mayfly and Digi LTE XBee3’s than you have had with the UBee, but I’ve spent a lot of time tweaking things to figure out what works.
It’s funny, we were on a phone call at one point with a group at Oregon State that was just beginning to look into adding cellular connectivity via a breakout of the SARA R410M. The guy working on it said something to the effect of “we haven’t had any problems with it so far” to which my response was “then you haven’t been working with it long enough.”
-
2020-01-14 at 4:13 PM #13615
As for T-Mobile’s 2G, the most recent I’ve found says no guarantee past the end of this year. A while ago they were saying that they would maintain the same coverage area for 2G up until the sunset, but we keep having more sites without coverage.
-
2020-01-14 at 5:20 PM #13621
Cool, thanks for that info. Yeah, I have found the GPRSbee to be pretty good; we have four of them that have been operating for over a year now and they all just keep trucking along.
It’s strange, I do also have an XBee3 (XB3M1, XB3-C-A2-UT-001 RevH) but have never been able to get it to power up or respond in any way on the Mayfly. I have SJ13 soldered to LiPo and am certain I have the pins right but can’t get it to wake up, using either the transparent or bypass constructors, or even just by setting the pins and trying to wake it up directly. I guess I could open a new thread for that one 🙂
-
2020-01-14 at 10:25 PM #13628
That does seem worthy of a new thread; those are the Bee’s we’re using so I’m more familiar with them. They’re easier for us to get (no international shipping), similar in price, have carrier certification, and have a secondary processor that takes care of the baud rate trouble.
I don’t think we’ve had any yet that were DOA, but we have managed to completely kill two or three of them without quite knowing how.
-
2020-01-21 at 1:39 PM #13702
I just pushed some improvements yesterday to the EnviroDIY fork of TinyGSM that should help with the uBee.
-
2021-04-23 at 4:46 AM #15414
Hi….so the gadget never gets a CSQ or CGATT?
It is safe to say that you are appropriately taking care of the ublox module? You’ll need to supply it with a battery or supercap as the hasty force draw is an excessive lot for the USB line to appropriately deal with, this causes a genuine voltage drop forestalling the ublox to work appropriately.
-
-
AuthorPosts
- You must be logged in to reply to this topic.
