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