Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, an initiative of Stroud Water Research Center designed to help people advance knowledge and stewardship of fresh water.
New to EnviroDIY? Start here

uBee R410 setup issues

Home › Forums › Mayfly Data Logger › uBee R410 setup issues

Tagged: , , ,

Viewing 20 reply threads
  • Author
    Posts
    • 2020-01-07 at 3:40 PM #13538
      Dan
      Participant

        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:

        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…

        Any ideas?

      • 2020-01-07 at 4:50 PM #13541
        Sara Damiano
        Moderator

          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 the modemPowerUp() and another matching delay after the modem.wake(); in your setup function. Just see if that works.

        • 2020-01-07 at 5:25 PM #13542
          Sara Damiano
          Moderator

            I’ve attached some annotations showing what’s happening in your logs.

            Attachments:

            1. comment1.jpg

            2. comment2.jpg

          • 2020-01-07 at 6:55 PM #13545
            Dan
            Participant

              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?

              and the output

            • 2020-01-08 at 11:23 AM #13551
              Sara Damiano
              Moderator

                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
                Dan
                Participant

                  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:

                  I’ll try modemLast and see if I can get anywhere.

                • 2020-01-08 at 10:48 PM #13561
                  Sara Damiano
                  Moderator

                    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:

                    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 any USOWR commands that got ok back? Was there a +UUSOCL in there (that means that the socket was closed externally)? What was the result of the +USOCR command (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
                    Dan
                    Participant

                      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.

                      and then sending data:

                    • 2020-01-09 at 3:08 PM #13582
                      Sara Damiano
                      Moderator

                        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.

                        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:

                      • 2020-01-09 at 3:24 PM #13584
                        Sara Damiano
                        Moderator

                          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
                          Dan
                          Participant

                            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 allowed with USOCL. 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 the Connecting to NIST daytime Server message.

                          • 2020-01-10 at 5:28 PM #13594
                            Sara Damiano
                            Moderator

                              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:

                            • 2020-01-10 at 6:10 PM #13596
                              Sara Damiano
                              Moderator

                                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
                                Sara Damiano
                                Moderator

                                  I am so very unimpressed with the SARA R410. It does not deserve its name.

                                • 2020-01-14 at 2:10 PM #13612
                                  Dan
                                  Participant

                                    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
                                    Sara Damiano
                                    Moderator

                                      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
                                      Sara Damiano
                                      Moderator

                                        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
                                        Dan
                                        Participant

                                          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
                                          Sara Damiano
                                          Moderator

                                            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
                                            Sara Damiano
                                            Moderator

                                              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
                                              BrodVictor
                                              Participant

                                                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.

                                                pcb fabrication and assembly

                                            • Author
                                              Posts
                                            Viewing 20 reply threads
                                            • You must be logged in to reply to this topic.