nRF9160 device functionality after a week

[anicare-tero]

Hi,

I'm using latest master branch of nRF Connect SDK and pre-released modem FW 1.1.2 which is including ANT->AUX switching. I'm developing a firmware for a custom board that has nRF9160 SiP.

I would like to set the device to start GPS once a week. I have read the Date-Time Library and wondered if it's possible to use that library to set the device to start GPS at the specific time. Does anyone any suggestions how to do that?

But for now I have done it with k_delayed_work_submit_to_queue() and set the delay to one week. One week is 168 hours but that value is not working, I tested some different values and noticed that 163h is the maximum that is working in that function. If the value is 164 hours or more it seems to start the work immediately.

Why is that happening? Is there any other way to get 168 hours working than for example adding another delayed work with 8 hours to queue after 160 hours?

Here is some parts of the code:

static int gps_start_delay_hours = 160;		// one week - 8 hours

/* Stack definition for application workqueue */
K_THREAD_STACK_DEFINE(application_stack_area,
			CONFIG_APPLICATION_WORKQUEUE_STACK_SIZE);		// 2048
static struct k_work_q application_work_q;

static struct k_delayed_work start_gps_work;


/**@brief Callback for GPS events */
static void gps_handler(struct device *dev, struct gps_event *evt)
{
    ...
	case GPS_EVT_SEARCH_STOPPED:
		LOG_INF("GPS_EVT_SEARCH_STOPPED");
		gps_control_set_active(false);

		if (gps_failed_fix_attempts >= CONFIG_GPS_CONTROL_MAX_FAILED_FIX_ATTEMPTS) {
            k_delayed_work_submit_to_queue(&application_work_q,
                    &start_gps_work, K_HOURS(gps_start_delay_hours));
		}

		break;
    ...
}

/**@brief Start GPS. */
static void start_gps(struct k_work *work)
{
	gps_control(1);
}

void main(void)
{
    ...
	k_work_q_start(&application_work_q, application_stack_area,
			K_THREAD_STACK_SIZEOF(application_stack_area),
			CONFIG_APPLICATION_WORKQUEUE_PRIORITY);

    k_delayed_work_init(&start_gps_work, start_gps);
    ...
}

Regards,
Tero

[Simon]

Any progress on this while I've been gone?

[Simon]

I will be gone until monday (4th of may) and I'm not able to look at
your issue until then

Best regards,
Simon

[anicare-tero]

I will look into that Zephyr's timer. I earlier thought that splitting idea too and that might work.

I was just wondering why that k_delayed_work_submit_to_queue() is not working with larger hour values. That function also uses s32_t delay and I have my variable gps_start_delay_hours with int and s32_t but there is no difference. The K_HOURS() still seems to calculate the delay to milliseconds correctly when printed out but I have no idea why it's not working with submitting a work to a queue.

Simon said:

If you would rather like to use the Date-Time Library or k_delayed_work_submit_to_queue() I can look into it.

The final goal is to use Date-Time Library or similar which could "wake-up" the device at the specific time. But for now I want to make it at the easier way and use k_delayed_work_submit_to_queue().

[Simon]

Couldn't you use Zephyr's Timer? The function k_timer_start() accepts a timeout (in milliseconds) of type s32_t (signed int). The maximum value of s32_t before it wraps around, is 2,147,483,647 ms = 596 hours. When the timer expires you run k_work_submit().

If you encounter any problems, you can also split the timeout into several segments, e.g. 163h/10=16.3 hours, and increment a counter every timeout. When the counter reaches e.g. 10 you run k_work_submit().

I am not sure how precise this is, and if that is important to you, but can look into it if you would like to.

If you would rather like to use the Date-Time Library or k_delayed_work_submit_to_queue() I can look into it.

Best regards,

Simon

[Simon]

I am sorry for the delay, I will look at it today.

Best regards,

Simon