nRF9160 device functionality after a week

RE: nRF9160 device functionality after a week

Simon — Fri, 10 Jul 2020 12:50:43 GMT

Nice that you finally found a solution 🙂

RE: nRF9160 device functionality after a week

anicare-tero — Fri, 10 Jul 2020 08:37:53 GMT

Hi Simon,

Thanks for the more detailed information! I created a bug report in https://github.com/zephyrproject-rtos/zephyr/issues so let's see if they are going to solve this.

EDIT: It seems to be already fixed in Zephyr but it's not pushed to NCS yet. If you want to check the ticket I created, here is the link: https://github.com/zephyrproject-rtos/zephyr/issues/26793

Best regards,
Tero

RE: nRF9160 device functionality after a week

Simon — Thu, 09 Jul 2020 14:04:18 GMT

Could you try to ask about this in https://github.com/zephyrproject-rtos/zephyr/issues or https://lists.zephyrproject.org/g/devel/topics to get in direct contact with the developers of these libraries and ask if there is a bug?

I tested k_delayed_work_submit_to_queue(&my_work_q, &my_device.work,

K_MINUTES(2160)) and tried to watch what happened in the underlying functions:

k_delayed_work_submit_to_queue() (ncs\v1.3.0\zephyr\kernel\work_q.c) →
- z_add_timeout() (ncs\v1.3.0\zephyr\kernel\timeout.c)

I added some logging in z_add_timeout(),

void z_add_timeout(struct _timeout *to, _timeout_func_t fn,
		   k_timeout_t timeout)
{
        .
        .
        .
		if (t == NULL) {
			sys_dlist_append(&timeout_list, &to->node);
		}
		printk("z_add_timeout-->timeout: %llu\n", next_timeout());
		if (to == first()) {
			z_clock_set_timeout(next_timeout(), false);
		}
	}
}

and got the following: "z_add_timeout-->timeout: 0", which is why it triggers immediately I think.

If you don't get any help from the above links, please tell me and I will try to get to the bottom of it.

Best regards,

Simon

RE: nRF9160 device functionality after a week

anicare-tero — Wed, 01 Jul 2020 12:01:45 GMT

Hi Simon,

No worries, it's not keeping me stuck. For now it's in "would be nice to have" state so it's not that urgent case.

BR, Tero

RE: nRF9160 device functionality after a week

Simon — Wed, 01 Jul 2020 11:22:11 GMT

My apologies for the delay, I've been quite busy lately. Hopefully, this issue isn't keeping you stuck. I will try to get to the bottom of this within this week.

Best regards,

Simon

RE: nRF9160 device functionality after a week

Simon — Tue, 23 Jun 2020 13:03:39 GMT

I looked some at this, but have not figured out the cause yet. I'll share my temporary findings.

I checked if K_MINUTES worked properly for different values and got these results (blue text-->K_MINUTES worked):

K_MINUTES(2880)
- This should be (2880 minutes)*(60 seconds/minute)*(1000ms/sec) = 172 800 000 ms
- This should be (172 800 000* 32768 + 999)/1000 = 5.662 × 10^9 ticks
- printk("2880 minutes to ticks to ms: %llu\n",__ticks_to_ms(K_MINUTES(2880).ticks)); gives: 2880 minutes to ticks to ms: 41728000 ms (~695 minutes)
- printk("2880 minutes in ticks: %llu\n",K_MINUTES(2880).ticks); gives: 2880 minutes in ticks: 1367343104 ticks
K_MINUTES(2160)
- This should be (2160 minutes)*(60 seconds/minute)*(1000ms/sec) = 129 600 000 ms
- This should be (129 600 000* 32768 + 999)/1000 = 4.2467 × 10^9 ticks
- printk("2160 minutes in ticks: %llu\n",K_MINUTES(2160).ticks) gives: 4 246 732 800
- printk("2160 minutes to ticks to ms: %llu\n",__ticks_to_ms(K_MINUTES(2160).ticks)) gives: 129 600 000
K_MINUTES(5040)
- This should be (5040 minutes)*(60 seconds/minute)*(1000ms/sec) = 302 400 000 ms ()
- This should be (302 400 000* 32768 + 999)/1000 = 9.909 × 10^9 ticks
- printk("5040 minutes in ticks: %llu\n",K_MINUTES(5040).ticks) gives: 5040 minutes in ticks: 1319108608
- printk("5040 minutes to ticks to ms: %llu\n",__ticks_to_ms(K_MINUTES(5040).ticks)) gives: 5040 minutes to ticks to ms: 40256000
K_MINUTES(4320)
- This should be (4320minutes)*(60 seconds/minute)*(1000ms/sec) = 2.592 × 10^8
- This should be (2.592 × 10^8* 32768 + 999)/1000 = 8.49347 × 10^9 ticks
- printk("4320 minutes in ticks: %llu\n",K_MINUTES(4320).ticks) gives: 4320 minutes in ticks: 4.1985x 10^9
- printk("4320 minutes to ticks to ms: %llu\n",__ticks_to_ms(K_MINUTES(4320).ticks)) gives: 4320 minutes to ticks to ms: 1.2813 x 10^8

I will continue investigating this when I get time

Best regards,

Simon

RE: nRF9160 device functionality after a week

Simon — Thu, 18 Jun 2020 13:32:05 GMT

That is strange.

I will be gone until Monday (22 June) but I will do some testing then and try to get to the bottom of it.

Best regards,

Simon

RE: nRF9160 device functionality after a week

anicare-tero — Tue, 16 Jun 2020 11:21:51 GMT

Hi Simon,

I test your the project you shared and I'm still having the same problem. It is working with some values but not all. See below:

	//k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_SECONDS(15));	//working
	//k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_HOURS(160));	//working
	//k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_MINUTES(5040));	//working
	//k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_MINUTES(4320));	//not working
	//k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_MINUTES(2880));	//working
	//k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_MINUTES(2160));	//not working
	//k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_MINUTES(1500));	//not working
	k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_MINUTES(1440));	//not working

RE: nRF9160 device functionality after a week

Simon — Tue, 16 Jun 2020 10:19:58 GMT

I am not able to reproduce the behavior you're talking about (immediately triggers) on commit 7dcdee6deb2e04d45f2080dd0b91b5723631a9a4. Can you test this solution:devzone.nordicsemi.com/.../work_5F00_submit_5F00_delay.zip

Best regards,

Simon

RE: nRF9160 device functionality after a week

anicare-tero — Fri, 12 Jun 2020 06:48:56 GMT

Hi Simon,

[quote userid="72692" url="~/f/nordic-q-a/60303/nrf9160-device-functionality-after-a-week/254027"]I will test it out myself and see if I get the same result.[/quote]

Have you got this working or are you having the same problem as I do?

RE: nRF9160 device functionality after a week

anicare-tero — Tue, 09 Jun 2020 11:54:47 GMT

I don't want to use v.1.3.0-rc1 or earlier versions because I'm waiting quite a lot of upcoming changes, for example A-GPS support for Asset Tracker. I have been on master branch almost all the time so I have implemented the latest updates. Now I'm on the commit 7dcdee6deb2e04d45f2080dd0b91b5723631a9a4.

RE: nRF9160 device functionality after a week

Simon — Tue, 09 Jun 2020 11:32:29 GMT

Did you check out NCS release candidate 1.3.0 before testing this? Many changes have happened to the underlying libraries that you should implement in order to make this work.

E.g. in ncs\zephyr\kernel\timeout.c-->z_add_timeout(), the argument s32_t ticks changed to k_timeout_t timeout: https://github.com/nrfconnect/sdk-zephyr/commit/7832738ae985a63febb8f82e7c4e34824f48486e#diff-fb2a509e3f45ffb30a72cf17792d75f6L30

Please checkout v1.3.0-rc1, or implement the changes into NCS v1.2.0.

Best regards,

Simon

I just saw that you've used the configuration CONFIG_TIMEOUT_64BIT without any build issues. Which signifies that you're on a newer tag than v1.2.0.

What commit/tag are you on? I will test it out myself and see if I get the same result.

RE: nRF9160 device functionality after a week

anicare-tero — Tue, 09 Jun 2020 10:51:38 GMT

Hi Simon,

I tested your suggestion to use 64 timeout ticks. I enabled CONFIG_TIMEOUT_64BIT in prj.conf and removed my split timer and directly calling this:

k_delayed_work_submit_to_queue(&application_work_q, &start_gps_work,
                                K_MINUTES(gps_start_delay_minutes));
// gps_start_delay_minutes for example 1521 minutes

and the device will start the GPS straight after no delay. I have no idea why it's not working.

- Tero

RE: nRF9160 device functionality after a week

anicare-tero — Thu, 04 Jun 2020 14:10:47 GMT

Thanks for telling me! I will test that as soon as possible.

- Tero

RE: nRF9160 device functionality after a week

Simon — Thu, 04 Jun 2020 14:04:24 GMT

Okay, I've figured out what's causing the issue

First k_delayed_work_submit_to_queue(&my_work_q, &my_device.work, K_HOURS(160)) is called
- Where K_HOURS(160) equals 576000000
Then k_delayed_work_submit_to_queue()-->k_ms_to_ticks_ceil32(576000000) is called
Then k_ms_to_ticks_ceil32()-->z_tmcvt(t, Z_HZ_ms, Z_HZ_ticks...) is called
- t equals 576000000
- Z_HZ_ms equals
- Z_HZ_ticks equals 32768
Eventually, this line is returned, which will convert the timeout to ticks. However, the number of ticks calculated will exceed what a u32_t type can store
- t * to_hz + off) / from_hz = (576 000 000 * 32768 + 999)/1000 = 18874368000 ticks
  - This is bigger than 2,147,483,647, which I mentioned earlier in my reply
- When converted to u32_t type, it will be equal to 1694498816 ticks (this is what I got when logging it)
- This will lead to a timeout of (1694498816 ticks)/(32768 ticks/sec) = 51,712‬ seconds = 14.36 hours

I just figured out that this seems to be fixed in the master branch, where the ticks are stored in k_timeout_t-->k_ticks_t, which can hold up to 64 bits instead of 32 bits.

Just make sure CONFIG_TIMEOUT_64BIT is enabled.

Best regards,

Simon

RE: nRF9160 device functionality after a week

Simon — Sat, 30 May 2020 02:16:59 GMT

I am sorry for the delay. But when the answer is verified, it is removed from my stack of cases, and that is the reason I haven't answered. I just happen to stumble upon this by accident.

However, I'll put in a feature request in Devzone that the case is reopened and visible for if the customer rejects it.

I will look into your issue on the next working day (which is Tuesday due to Norwegian holiday on Monday).

Best regards,

Simon

RE: nRF9160 device functionality after a week

anicare-tero — Wed, 27 May 2020 10:05:43 GMT

Any updates on this?

RE: nRF9160 device functionality after a week

anicare-tero — Tue, 12 May 2020 08:38:54 GMT

I did that almost the same way. I'm getting the current time from date_time_now() after date_time_update() and then calculating the time to the target time and using k_delayed_work_submit_to_queue() which is split to 12h periods as minutes, and when the remaining time is shorter than 12h I'm then using the remaining time in k_delayed_work_submit_to_queue().

EDIT: I once verified your answer as a solution but it closed this case so I rejected it. I would like to have an answer for the following and then I could close the case:
Any idea will that k_delayed_work_submit_to_queue() be fixed to support longer periods so we shouldn't use the split timer?

But thanks for the help to this point!

BR,
Tero

RE: nRF9160 device functionality after a week

Simon — Mon, 11 May 2020 14:48:22 GMT

I played around with the Date-Time Library. I did the following to make it work

Used an already working nrf9160 project that connects to the network (I used http_application_update)

In prj.conf I added these configs:

CONFIG_DATE_TIME=y
CONFIG_DATE_TIME_UPDATE_INTERVAL_SECONDS=10

At the top of main.c, I included the Date-Time header file:

#include <date_time.h>

In main(), after modem configuration and connection to the network, I added these lines:

s64_t date_time_stamp;
.
.
.
k_sleep(25000); //Wait some time to make sure the Date-Time update has happened
date_time_now(&date_time_stamp); 
printk("Date time: %016llX\n", date_time_stamp);

Then I got the following log:

E: getaddrinfo, error: -11
E: Not getting time from any NTP server
LTE Link Connected!
I: Time successfully obtained (Log added by me in date_time.c)
Date time: 00000172042bf014

The timestamp 0x172042bf014 equals 1,589,207,887,892 and gives the date: Mon 11 May 2020
16:38:07, which is correct

Best regards,

Simon

RE: nRF9160 device functionality after a week

anicare-tero — Tue, 05 May 2020 08:29:27 GMT

Not actually, not any progress on Date-Time stuff. For now I'm using half a week periods for starting GPS and the period is split into 12 hours.

RE: nRF9160 device functionality after a week

Simon — Tue, 05 May 2020 08:20:23 GMT

Any progress on this while I've been gone?

RE: nRF9160 device functionality after a week

Simon — Wed, 29 Apr 2020 02:22:12 GMT

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

Best regards,
Simon

RE: nRF9160 device functionality after a week

anicare-tero — Wed, 22 Apr 2020 12:24:37 GMT

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.

[quote userid="72692" url="~/f/nordic-q-a/60303/nrf9160-device-functionality-after-a-week/246022"]If you would rather like to use the Date-Time Library or k_delayed_work_submit_to_queue() I can look into it.[/quote]

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().

RE: nRF9160 device functionality after a week

Simon — Wed, 22 Apr 2020 12:10:11 GMT

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

RE: nRF9160 device functionality after a week

Simon — Wed, 22 Apr 2020 09:52:51 GMT

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

Best regards,

Simon