Tracker sample questions

mwgustin

First off -thanks for the incredible work on this project. Very excited as I’m diving into it.

I was able to get the Tracker sample working with Golioth following the instructions and I get both the Boot and GPS state and GPS stream update after a reset (and GPS acquisition). However, it only sends the GPS once on the successful acquisition and then doesn’t send any additional payloads after that. Is that the intent of the demo or is it supposed to poll the GPS or send on motion/accelerometer data? Nothing I do seems to get it to send additional data.

If that is the intent of the demo, what is the best way to check the GPS for updates or enable the GPS to feed the event stream?

00:03:11.224,060] <dbg> nrf9160_gps.gps_thread: PVT: Position fix
[00:03:11.231,231] <inf> app_main: Evt: APP_EVENT_GPS_DATA
[00:03:11.237,731] <inf> app_main: Data size: 73
[00:03:11.243,743] <dbg> nrf9160_gps.print_satellite_stats: Tracking SV  8:     used,     healthy
[00:03:11.254,364] <dbg> nrf9160_gps.print_satellite_stats: Tracking SV 30:     used,     healthy
[00:03:11.264,282] <dbg> nrf9160_gps.print_satellite_stats: Tracking SV  7:     used,     healthy
[00:03:11.274,230] <dbg> nrf9160_gps.print_satellite_stats: Tracking SV 27:     used,     healthy
[00:03:11.284,332] <dbg> nrf9160_gps.print_satellite_stats: Tracking SV 14:     used,     healthy
[00:03:11.294,250] <dbg> nrf9160_gps.print_satellite_stats: Tracking: 5 Using: 5 Unhealthy: 0
[00:03:11.303,833] <dbg> nrf9160_gps.print_satellite_stats: Seconds since last fix 0
[00:03:11.312,591] <dbg> nrf9160_gps.print_satellite_stats: Seconds for this fix 128
[00:03:11.321,350] <dbg> nrf9160_gps.print_satellite_stats: 18:23:49.668 2022-03-04
[00:03:11.330,017] <dbg> nrf9160_gps.gps_thread: NMEA: Position fix
[00:03:21.278,656] <inf> app_main: Evt: APP_EVENT_ACTIVITY_TIMEOUT
[00:12:07.378,936] <wrn> golioth_system: Receive timeout
[00:12:07.394,622] <inf> golioth_system: Starting connect
[00:12:09.790,985] <inf> app_main: Evt: APP_EVENT_BACKEND_CONNECTED
[00:12:09.798,065] <inf> golioth_system: Client connected!
[00:23:09.804,718] <wrn> golioth_system: Receive timeout
[00:23:09.820,404] <inf> golioth_system: Starting connect
[00:23:12.298,400] <inf> app_main: Evt: APP_EVENT_BACKEND_CONNECTED
[00:23:12.305,511] <inf> golioth_system: Client connected!

jaredwolff

@mwgustin it should reattempt after a certain amount of time and/or motion should trigger another acquisition event. Give your board a jiggle it should trigger it.

Hope that helps!

mwgustin

jaredwolff Yeah that’s the problem, it doesn’t seem to reattempt… if you look at the logs you can see it over waited over 20 minutes for a new event (resulting in several golioth backend timeout and reconnect event).

Jiggling the board and even moving around with it across the house didn’t seem to make a difference either.

jaredwolff

I assume you’re using an nRF9160 Feather?

mwgustin

jaredwolff Yep - purchased just a week or so ago.

jaredwolff

Hmm I’ll have to get back to you. Not sure why it’s not working for you.

I assume you haven’t modified any of the jumpers on the underside of the board? Also make sure you don’t have anything connected to D3 since that is shared with the interrupt pin of the LIS2DH12TR

mwgustin

Only thing I’ve done to the board since taking it out of the packaging is attach the antennas and insert the SIM. Nothing attached to any pins, and no modifications of any jumpers.

For repro purposes, I created a brand new folder, and followed everything step by step from here (https://www.jaredwolff.com/nrf9160-feather-on-golioth/) and got exactly the same results… GPS publish on initial position fix, but nothing triggering at an interval, and nothing triggering by movement. All that happens is the golioth client expires after about 10 minutes and reconnects.

mwgustin

Doesn’t really help, but I also tried a fresh install of the extension/tooling and repo on a mac (previous builds were on a PC) and got the same result.

jaredwolff

Ok let me look into it. Must be a big somewhere.

jaredwolff

@mwgustin sorry for the delay on this!

Turns out, I changed the code so JMP3 was the interrupt pin. By default that guy is open on the bottom of the board. If you short it with a blob of solder, you should get wake up events which trigger GPS. In that sample, the only thing that starts GPS is motion but you can create your own timer and invoke the app_gps_start function or make your own customizations to app_gps.c as you see fit.

Hope that helps. Let me know if you have any other questions!

mwgustin

Thanks so much for the help! I’ve added the bridge on JMP3 and I’m making a little progress… I am able to get motion events shortly after start up while the GPS is looking for a fix, but not once it finds a GPS fix.

I added an app_motion_reset_trigger_time call to the APP_EVENT_ACTIVITY_TIMEOUT and that lets me get a motion event after the initial GPS fix, but when the APP_EVENT_MOTION_EVENT triggers, the app_gps_start call returns a -120 error (which I believe means it’s already started). I’m going to go down the path of setting up a polling timeout, but I’m gonna guess I get the same -120 response in that as well… do I need to call the app_gps_stop function somewhere? Or will that cause the GPS to need to fully reacquire a position?

jaredwolff

mwgustin hmmm. Maybe it wasn’t stopped which means it should acquire another fix based on the CONFIG_GPS_CONTROL_FIX_CHECK_INTERVAL interval. You can search for this in your build folder to see what it’s set to. I believe this value is in seconds.

You can also stop it and restart but it may request the AGPS data again.

mwgustin

Got the polling working! Thanks so much for the help. It was a few things…

the value was being set in the Pyrinas.conf file which I don’t believe is being used by default (since the default backend is golioth). Added it to the golioth.conf
the value’s default setting was 10 hours (36,000 seconds). Changed that to 30seconds
The gps_config in app_gps had the nav mode set to GPS_NAV_MODE_SINGLE_FIX which will search and then stop once it finds a fix. I updated it to GPS_NAV_MODE_PERIODIC so that it will respect the interval timing.

Those 3 changes got things working! Again - super appreciate all the help.

One last question for you - I noticed you rolled your own event manager for the main portion of the app utilizing the internal msgq rather than using the built-in zephyr event manager? Is there a particular reason for that?

jaredwolff

mwgustin Those 3 changes got things working! Again - super appreciate all the help.

Excellent!

One last question for you - I noticed you rolled your own event manager for the main portion of the app utilizing the internal msgq rather than using the built-in zephyr event manager? Is there a particular reason for that?

It just made sense at the time. I know Nordic built one but wasn’t aware of a Zephyr specific one. There’s so much in Zephyr that it’s hard to cover all the ground! If you don’t mind sharing where that implementation is that’d be cool to see and play with.