This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Time_stamping_value?

Hi Nordic Devzone,

First i want to make sure that if the clock being used by softdevice is the LFCLK (32kHz) and its counter register is 24bits ? and which prescaler is being used? because I want to send the local time (clock value ) from one device to another using Bluetooth mesh connectivity, but when i'm reading the time of the receive message from the ( const access_message_rx_t * p_message) the value of timestamp is greater than 24 bits value actually its a 32bit value , so if the counter register in the LFCLK is 24 bits how would it be possible to count up to 32 bits value ? does it mean that the clock begin used for time stamping the receive messages is different than the clock used by softdevice ? And what is the best way to keep track of time while using the softdevice ?

Thank you in advance

Parents
  • Hi MMG,

    The timestamp you see in access_message_rx_t is the timestamp when the packet is received. It's a local timestamp counting from the start of current timeslot. Have a look at radio_handle_end_event() in scanner.c

    And note that we use TIMER0 to count time, and it's 32bit. Not the 24bit RTC.

    Currently we have no use of the timestamp in the receive package yet.

  • It's not entirely true that there is no use of softdevice when using Mesh. We still use timeslot mechanism by softdevice :)

    The way it works is that the mesh stack request timeslot from softdevice, softdevice will grant a timeslot to the application when it possible. Max timeslot length is 100ms and it can be extended until 128 seconds. In our case, softdevice won't do much stuff, so most of the time the mesh stack has all those 128 seconds, but it can't be guarantee. And timeslot will be closed and open again because of the limit.

    Everytime a new timeslot is granted, TIMER0 will be reset to 0.

    So you can't rely entirely on TIMER0 as it will be reset. You can use what we are doing now RTC+TIMER0.

    But I would suggest you just use a new timer , say TIMER1 to keep track of the timing. Then you don't have to worry about timeslot etc.

    But still even if you use a separate timer for time keeping, how do you sync time between nodes ? How do you calculate the drift and the initial offset ? Note that all devices don't start up at the same time. You need a timing master.

    You can have a look at this blog.

Reply
  • It's not entirely true that there is no use of softdevice when using Mesh. We still use timeslot mechanism by softdevice :)

    The way it works is that the mesh stack request timeslot from softdevice, softdevice will grant a timeslot to the application when it possible. Max timeslot length is 100ms and it can be extended until 128 seconds. In our case, softdevice won't do much stuff, so most of the time the mesh stack has all those 128 seconds, but it can't be guarantee. And timeslot will be closed and open again because of the limit.

    Everytime a new timeslot is granted, TIMER0 will be reset to 0.

    So you can't rely entirely on TIMER0 as it will be reset. You can use what we are doing now RTC+TIMER0.

    But I would suggest you just use a new timer , say TIMER1 to keep track of the timing. Then you don't have to worry about timeslot etc.

    But still even if you use a separate timer for time keeping, how do you sync time between nodes ? How do you calculate the drift and the initial offset ? Note that all devices don't start up at the same time. You need a timing master.

    You can have a look at this blog.

Children
No Data
Related