AchimKraus Hi there,

I’ve just had a look at the sparkfun_thing_plus_nrf9160_ns.conf file that i’m using and those lines are in there.

I’m trying to go through the code and understand where that loop is happening and if something is ending the loop. I noticed it sends the info I pasted in my post to Golioth when it first connects, but if I clear the Golioth lightdb, it will not populate again until I restart the device.

Cheers.

Chris.

      Let me guess: The loop waits until the device gets a position.
      “AGPS request” indicates, that the “fresh started modem” requires either that A-GPS data from a server or you need to operate the device in a classic GPS mode.
      Classic mode means: put the device in a place with free sight to the sky, hopefully it’s not that cloudy as today here in south Germany. After a couple of minutes (2-5) your GPS receiver should start to report positions.

      The background of that is simply: the GPS receiver needs some additional data, which are either requested from a server (A-GPS) or received “over the time” from the GPS satellites. The “free sky” is required, because on start the device need to scan in a “less sensitive broadband mode”. When the first “weak signals” are detected, the GPS receiver focus on that satellite using a “more sensitive narrowband mode”. That “additional data” is then send in small parts as additional to the position data. It requires then quite a lot of those “small parts” to have that required additional data completed.
      If the software isn’t aware of that, if may disable the GPS receiver just after a few seconds instead of waiting much longer.

      • cwb replied to this.

        AchimKraus
        Thanks for the detailed reply. I have left it sitting by the window for about 10-20minutes. It has previously received a good signal from here.
        Tomorrow, I will take it outside and let it sit with a better shot for a while. I’ll update on how it goes. Hopefully a sunny day in Aus tomorrow. 🙂

          Just to mention:
          In my experience, it’s always good to have more than just one type of devices.
          e.g. a Thingy:91 may serve as GPS test-device.

          I left it on with a clear view of the sky for about 4 hours yesterday but never moved from
          [00:00:14.379,943] <inf> app_gps: AGPS request!
          [00:00:14.380,065] <inf> app_event_manager: Evt: APP_EVENT_GPS_ACTIVE
          [00:00:26.471,496] <inf> modem: RRC mode: Idle

          I have ordered a sma-u.fl cable to I can test with a different GPS antenna I have here incase it is the gps antenna.

            Just to ensure, that the hardware and NCS is OK.
            I’ve right now tested to use a nRF9160 feather v5 and a Thingy:91 v1.6 with the mfw 1.3.5 and NCS 2.5.0.
            I put both outside, little cloudy. I got the fixes after 1-2 minutes.
            Which “tracker” code do you run? Could you provide a link?

              5 days later

              our postal service here really does suck and I’m still waiting on my parts to arrive to test a different antenna.

                6 days later

                New cable arrived allowing me to plug in a better GPS antenna and it now seems to eventually pick up a signal.
                Golioth is now populating gps data speratically.
                the device does seem to struggle to send the data though. most of the time i get this..

                inf> app_event_manager: Evt: APP_EVENT_GPS_DATA
                [00:03:14.783,386] <inf> app_codec: Size: 53
                [00:03:14.783,386] <inf> app_event_manager: Data size: 53
                [00:03:15.109,436] <inf> modem: RRC mode: Connected
                [00:03:17.127,532] <wrn> golioth: Resending request 0×2001ace8 (reply 0×2001ad20) (retries 2)
                [00:03:17.268,157] <wrn> golioth: Resending request 0×2001ae18 (reply 0×2001ae50) (retries 2)
                [00:03:21.799,499] <wrn> golioth: Resending request 0×2001ace8 (reply 0×2001ad20) (retries 1)
                [00:03:22.209,869] <wrn> golioth: Resending request 0×2001ae18 (reply 0×2001ae50) (retries 1)
                [00:03:31.152,313] <wrn> golioth: Resending request 0×2001ace8 (reply 0×2001ad20) (retries 0)
                [00:03:32.118,041] <wrn> golioth: Resending request 0×2001ae18 (reply 0×2001ae50) (retries 0)
                [00:03:43.578,491] <inf> modem: RRC mode: Idle
                [00:03:43.778,778] <inf> modem: Sleep enter
                [00:03:49.863,647] <wrn> golioth: Packet 0×2001ace8 (reply 0×2001ad20) was not replied to
                [00:03:49.863,677] <wrn> backend_golioth: Golioth async operation failed: -116
                [00:03:51.908,966] <wrn> golioth: Packet 0×2001ae18 (reply 0×2001ae50) was not replied to
                [00:03:51.908,996] <wrn> backend_golioth: Golioth async operation failed: -116

                  Which send interval are you using?
                  Did you enabled DTLS 1.2 Connection ID?

                  It depends a lot on you mobile network provider, how the ip-messages are forwarded to the public internet. It’s very common to use “NAT” and with that, that temporary assigned public ip-address may change more frequently in quiet phases than expected. Therefore enable DTLS 1.2 Connection ID to mitigate that.

                  Edited:
                  To enable DTLS 1.2 Connection ID, mfw 1.3.5 is required or a implementation in the application space.
                  I guess, you need to ask https://forum.golioth.io how to enable DTLS 1.2 Connection ID in their SDK.

                  • cwb replied to this.
                  • cwb likes this.

                    Thanks AchimKraus

                    Still learning how all of the parts of code interact, I have left all of the defaults for the tracker program. Can you point me to where i should look for the send interval?

                    I’ll look into DTLS 1.2 on the golioth forums. I have upgraded the firmware on the device to 1.3.5 already.

                        Can you point me to where i should look for the send interval?

                        I have no experience with that tracker. Something as a “send interval” is a very common approach, so I assume, it is also used there, but I don’t know that. I also don’t know, if that is really the cause of your issue, it’s just a guess based on common experience with longer quiet-phases and ip-address changes caused by NAT.

                          4 months later

                          @cwb have you found a fix for this? I’ve been looking for a solution for a bit on and off and haven’t been able to find anything that works thus far.

                          @jaredwolff any thoughts? I’m having an identical symptom on subsequent sends to golioth.

                          [00:08:10.462,310] <inf> modem: Sleep exit
                          [00:08:10.772,155] <inf> modem: RRC mode: Connected
                          [00:08:12.852,050] <wrn> golioth: Resending request 0x2001adc0 (reply 0x2001adf8) (retries 2)
                          [00:08:13.286,651] <wrn> golioth: Resending request 0x2001aef8 (reply 0x2001af30) (retries 2)
                          [00:08:17.608,825] <wrn> golioth: Resending request 0x2001adc0 (reply 0x2001adf8) (retries 1)
                          [00:08:18.987,457] <wrn> golioth: Resending request 0x2001aef8 (reply 0x2001af30) (retries 1)
                          [00:08:25.746,337] <inf> modem: RRC mode: Idle
                          [00:08:27.189,056] <wrn> golioth: Resending request 0x2001adc0 (reply 0x2001adf8) (retries 0)
                          [00:08:27.312,591] <inf> modem: RRC mode: Connected
                          [00:08:30.386,535] <wrn> golioth: Resending request 0x2001aef8 (reply 0x2001af30) (retries 0)
                          [00:08:37.103,637] <inf> modem: RRC mode: Idle
                          [00:08:43.128,417] <inf> modem: Sleep enter
                          [00:08:46.324,768] <wrn> golioth: Packet 0x2001adc0 (reply 0x2001adf8) was not replied to
                          [00:08:46.324,798] <wrn> backend_golioth: Golioth async operation failed: -116

                          • cwb replied to this.

                            omega2733 Sadly not. I tried with a couple of different sims but same problem. best I got was maybe 3 updates over a 1Hr drive.

                            I hope to dive back into this project soon but for now it is sitting next to my desk until i can think of something else to try.

                                6 days later

                                omega2733 out of curiosity, what region are you in and what carrier sim are you using?

                                    omega2733 and @jaredwolff

                                    I spent a coupled of days this week revisiting this project and I might have it working now.

                                    In case anyone else comes across this issue, some combination of this seems to be now working.

                                    I did some playing around with the prj.conf file and this morning I tested it and I have a GPS stamp in Golioth every 2 minutes for about 2 hours. I probably need to adjust some timers to get it to optimal performance/data usage but for the moment it is better than it sending a few stamps to lightDB stream then staying asleep.
                                    Changes are…
                                    added these lines:
                                    CONFIG_GNSS_SAMPLE_PERIODIC_INTERVAL=120
                                    CONFIG_GNSS_SAMPLE_PERIODIC_TIMEOUT=60

                                    Changed these values:
                                    CONFIG_GOLIOTH_SYSTEM_CLIENT_RX_TIMEOUT_SEC=300
                                    CONFIG_GOLIOTH_SYSTEM_CLIENT_PING_INTERVAL_SEC=60

                                    The GNSS periodic values seemed to trigger the gps update more reliably and the Golioth timeout and ping interval change has seemed to drastically reduce the failed response from golioth error.

                                        cwb

                                        What git branch are you on? I tried this on 2.4 with no avail, it actually ends up worse. I used to get a first send to lightDbState/Stream but now I get nothing except timestamp even with good GPS data.

                                        I looked at some of the client code and the client being used now is becoming deprecated. It looks like Golioth may have changed some of the API calls resulting in the async errors.

                                        Golioth has a new SDK out for Zephyr with a sample I’m going to attempt to use and if it works start with their sample client instead.

                                        Also as a heads up, defaults for GNSS_SAMPLE_PERIODIC_INTERVAL is set to 120 by default in kconfig (on 2.4 at least) with timeout at 120 as well, I’d be surprised if the only change to 60 made this difference. However it may have been the golioth timeouts that helped.

                                            Ok, strangely it seems to be very intermittent.

                                            I left these changes running, Golioth connections timed out twice (but received successful LightDbState data). Then after a 3rd connection, it worked flawlessly.

                                            I’m not sure why sometimes all the calls to golioth completely fails, then other times works as expected. Will keep trying to do some more debug with this client and the new golioth one as well.

                                              Terms and Conditions | Privacy Policy