Golioth + Tracking Sample

cwb · 2023-11-17T04:07:10+00:00

hi Jared, I’ve hit this project (from the split discussion) again now that i’m back. I managed to update the modem firmware today and the tracker code runs,...

cwb

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.

AchimKraus

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.

omega2733

@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

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.

cwb

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

cwb

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.

omega2733

cwb

I’m in the US using hologram

omega2733

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.

omega2733

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.

cwb

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.

omega2733

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 ₂₀-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.

cwb

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.

AchimKraus

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.

« Previous Page