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.

                            If I get a GPS fix, it seems to be fairly consistently sending to Golioth. Occasionally I get 1 or 2 retry errors for Golioth but it seems to then send.
                            It does currently seem to be a bit sporadic with acquiring a GPS fix. it for a fix and sent every 2 minutes for about an hour today. then the modem went into a cycle of ….
                            [00:04:05.515,380] <inf> modem: Sleep enter
                            [00:04:18.953,369] <inf> modem: Sleep exit
                            [00:04:19.272,369] <inf> modem: RRC mode: Connected
                            [00:04:31.569,854] <inf> modem: RRC mode: Idle
                            [00:05:20.406,036] <inf> modem: RRC mode: Connected
                            [00:05:32.785,522] <inf> modem: RRC mode: Idle
                            [00:05:39.372,222] <inf> modem: Sleep enter
                            [00:06:21.314,788] <inf> modem: Sleep exit

                            This then just repeats. This morning i also tested it on battery on the way to work and it didn’t pick up a fix for the first half hour of my drive. to be fair it is very cloudy and stormy today. but I thought the decent active GPS antenna I have would still pick up enough.

                              The NRF9160 is very picky when it comes to antenna’s as a heads up. I had tested 6 different antennas before I arrived on an optimal antenna out of the box that’s tuned well for the chipset.

                              If you’re having GPS fix issues, you’d probably want to use the GPS sample from NRF to test different antenna’s. In my case I’ve had GPS fixes the entire time still running into golioth issues with good GPS data. You may also be seeing issues due to your GPS periodic timeout being 60s, even with AGPS it takes 20-30s to get a good cold fix. Without SUPL/AGPS you’re looking at 50-60s as a good cold fix in a lot of conditions with up to 5 minutes being possible, especially moving in a vehicle (I specialize in vehicle tracking specifically with my product).

                              Also you’re seeing the modem come out of sleep often (every 50s or so) due to your golioth ping being 60s. The modem by default is requesting a 6s active time, which means after it sends a ping, it will wait 6s before going to RRC Idle (if granted the default PSM active time by the network, they can set this to whatever they want though). So if you send a ping -> wait 60s before another -> finish your connection/close the socket -> wait your active time to drop to RRC idle -> then 50s later you’re waking for your next ping event.

                              If you increase your golioth keep-alive ping you’ll see a lot less of the above with much better battery life, but it’s operating as expected from the RRC Idle/Connected states.

                                omega2733 Thanks for the info. I’ll play around with my timing a bit.

                                Good to know RE the GPS. I had to try a few before I could get any fixes when I started playing with this unit.

                                  omega2733 . So if you send a ping -> wait 60s before another -> finish your connection/close the socket -> wait your active time to drop to RRC idle -> then 50s later you’re waking for your next ping event.

                                  Not sure, if the 60s is intended or a work-around. In never close the socket unless I get deregistered from the mobile network, which is reported as errors. Using CoAP/DTLS 1.2 CID allows to be very flexible with the send interval. “close the socket” is something frequently used with TCP. With UDP (CoAP/DTLS 1.2 CID) just keep the socket.

                                    Terms and Conditions | Privacy Policy