gnss_event_handler: NRF_MODEM_GNSS_EVT_PVT vs NRF_MODEM_GNSS_EVT_FIX

[bluebeam]

I have a question on the gnss event type NRF_MODEM_GNSS_EVT_FIX. It seems there's always the NRF_MODEM_GNSS_EVT_PVT event regardless it's a fix or not. The flag can tell us exactly what is. The confusion is once we have a fix, the event handler also gets triggered by an extra NRF_MODEM_GNSS_EVT_FIX event, which seems just a duplication of the same PVT event. Why is that? What's the purpose to have it? I have a separate thread receiving all the events. This does causes confusing because I'm seeing two identical PVT message for every fix. I'm running GPS continuous mode. This is on 9160DK, modem 1.4.1, NCS 1.7.

Second question, when I have a fix, the PVT data flag becomes 0x21. The 0x01 is the 'VALID' bit. But I can;t find any reference to the 0x20 bit. In nrf_modem_gnss.h, the highest bit documented is 0x10(NRF_MODEM_GNSS_PVT_FLAG_NOT_ENOUGH_WINDOW_TIME).

Thanks!

[Øyvind]

Hello, 

Yes, you are right. This can be somewhat confusing. Talking to the developer of the GNSS library, he answers the following:

It seems there's always the NRF_MODEM_GNSS_EVT_PVT event regardless it's a fix or not. The flag can tell us exactly what is.

EVT_FIX is intended only for use cases where you only want to get the PVT which has a valid fix. EVT_PVT is sent once a second and flags field can be used to check if it's a valid fix or not.

Normally you don't use both, both select which one suits the use case better. The EVT_FIX is not necessary. E.g. In the modem_shell sample:

case NRF_MODEM_GNSS_EVT_FIX:
		/* Data is not read for the fix notification because we use the PVT notification
		 * and the data is the same.
		 */
		if (operation_mode == GNSS_OP_MODE_PERIODIC_FIX) {
			k_work_cancel_delayable(&gnss_timeout_work);
			k_work_submit_to_queue(&gnss_work_q, &gnss_stop_work);
		}
		break;

In our gnss sample, the EVT_FIX is not used in the gnss_event_handler()

static void gnss_event_handler(int event)
{
	int retval;
	struct nrf_modem_gnss_nmea_data_frame *nmea_data;

	switch (event) {
	case NRF_MODEM_GNSS_EVT_PVT:
		retval = nrf_modem_gnss_read(&last_pvt, sizeof(last_pvt), NRF_MODEM_GNSS_DATA_PVT);
		if (retval == 0) {
			k_sem_give(&pvt_data_sem);
		}
		break;

	case NRF_MODEM_GNSS_EVT_NMEA:
		nmea_data = k_malloc(sizeof(struct nrf_modem_gnss_nmea_data_frame));
		if (nmea_data == NULL) {
			LOG_ERR("Failed to allocate memory for NMEA");
			break;
		}

		retval = nrf_modem_gnss_read(nmea_data,
					     sizeof(struct nrf_modem_gnss_nmea_data_frame),
					     NRF_MODEM_GNSS_DATA_NMEA);
		if (retval == 0) {
			retval = k_msgq_put(&nmea_queue, &nmea_data, K_NO_WAIT);
		}

		if (retval != 0) {
			k_free(nmea_data);
		}
		break;

	case NRF_MODEM_GNSS_EVT_AGPS_REQ:
#if !defined(CONFIG_GNSS_SAMPLE_ASSISTANCE_NONE)
		retval = nrf_modem_gnss_read(&last_agps,
					     sizeof(last_agps),
					     NRF_MODEM_GNSS_DATA_AGPS_REQ);
		if (retval == 0) {
			k_work_submit_to_queue(&agps_work_q, &agps_data_get_work);
		}
#endif /* !CONFIG_GNSS_SAMPLE_ASSISTANCE_NONE */
		break;

	default:
		break;
	}
}

 

Second question, when I have a fix, the PVT data flag becomes 0x21. The 0x01 is the 'VALID' bit. But I can;t find any reference to the 0x20 bit. In nrf_modem_gnss.h, the highest bit documented is 0x10(NRF_MODEM_GNSS_PVT_FLAG_NOT_ENOUGH_WINDOW_TIME).

 

Actually that has been missing from the header file. It was added in modem lib v1.4.0, i.e. it's now in NCS v1.8.0, although modem support for it has been added already earlier. Note that in the newest nRF Connect SDK, v1.8.0, this is fixed:

/** @brief The velocity estimate is valid. */

#define NRF_MODEM_GNSS_PVT_FLAG_VELOCITY_VALID         0x20