How to access the TIMER3 in wireless timer sync?

[Michael01101]

Hello,

I found this great blog entry about synchronizing timers on different devices: https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/wireless-timer-synchronization-among-nrf5-devices

It works just fine on a nRF52840DK and a nRF52DK. Timers on multiple nRF5 devices are synced by one device (master) sending sync packets containing captured timer values to other devices (nodes). (TIMER3 is free running, TIMER2 counts TIMER3 overflows).

At the moment I am struggeling to access this synchronized TIMER3 on the two boards. I am familiar with setting up a TIMER without wireless timer sync. 

So here are my questions:

1. How can I define CC, Prescaler, Mode, Bitmode, the interrupt handler and so forth when using wireless timer sync?

2. Can anybody provide me some advice how to access this synchronized TIMER3 properly? 

Thank you very much in advance.

[Audun]

Hello,

can you share some more details regarding your use case? The following suggestions may be helpful for your case, otherwise we can see what options there are for you needs.

If you want to get a timestamp value, you can use the timestamp function (either 32 or 64-bit version): https://github.com/nordic-auko/nRF5-ble-timesync-demo/blob/master/nRF5_SDK_16.0.0_98a08e2/examples/common/time_sync.h#L203

If you want to trigger something at a given time, the ts_set_trigger function might be helpful. This lets you set up a PPI to be triggered at a given time in the future.

There are two TIMERs involved in this code, TIMER2 is used in timer mode, while TIMER3 is used in counter mode. By default, TIMER2 has a quite short CC/reset of 40000 (=40000/16 MHz = 2.5 ms wraparound). The counter is incremented for every wraparound (2.5 ms). This means that the timestamp function uses both of these TIMER values to calculate the current time with 16 MHz tick resolution.

Note that the ts_set_trigger function operates on the counter (TIMER3), which by default has a resolution of 2.5 ms. If you need finer resolution, you could reduce the TIME_SYNC_TIMER_MAX_VAL value.

Prescaler, bitmode, etc. is currently hardcoded. I would generally not recommend making changes to those.

Accessing the TIMERs directly is also not something I recommend, because it is quite tricky to handle the corner cases of TIMER wraparound and adjustment

[Michael01101]

Hello Audun,

First of all, thank you so much for your reply and your great blog entry about wireless timer sync. Of course, I will check your suggestions out.

Here is my use case:

I have two development kits. A nRF52840DK (central) and a nRF52DK (peripheral). I flashed the provided "wireless timer sync" code from github on them. It works just fine.

My goal is to have a similar counter on the central and the peripheral that increments every 1ms. The counter on central and peripheral should always contain the same value.

I already found this (https://devzone.nordicsemi.com/f/nordic-q-a/53521/two-timers-with-same-value). I am not sure, but I think there was someone trying to do the same.

What is the smartest way to achieve this goal?

I appreciate any suggestions.

Thank you very much in advance.

Michael

[Audun]

No problem!

I'll try to answer these questions:

1) I recommend using the latest version of the time_sync code. Among other improvements, the timestamp functions are updated to not have this parameter: https://github.com/nordic-auko/nRF5-ble-timesync-demo/blob/master/nRF5_SDK_16.0.0_98a08e2/examples/common/time_sync.h#L216 . If not, you can use the nrfx_ppi_channel_alloc() function to allocate an unused PPI channel, and use this channel when calling the old version of the timestamp function.

2) It would be easiest to use the 64-bit version of the timestamp function in this case, I think. This way you wont have to count overflows. Something along the lines of:

uint64_t timestamp_ticks;
uint32_t timestamp_ms;

timestamp_ticks = ts_timestamp_get_ticks_u64();
timestamp_ms = (uint32_t) ROUNDED_DIV(timestamp_ticks, 16000);

3) Use ts_tx_start(1) to set the lowest possible rate. As this API is in Hz, you cannot go below 1 Hz here

Regarding using the connection event to calculate a shared time, this does get more complicated with multiple connections. I was thinking maybe this function might be more useful than the radio notifications: 

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s140.api.v7.2.0/group___b_l_e___g_a_p___f_u_n_c_t_i_o_n_s.html?cp=4_7_4_1_2_1_3_10#ga6a2d8c4cd863ac538eb0a51d594e0dd6

You could have the softdevice trigger a timer capture for each link.

Either way, the time_sync code should work fine too. In this topology you can have any number of timing receivers (the receivers only listen, they never reply to the timing transmitter).

4) You can have any number of receivers with the time_sync code. The transmitter will transmit at the rate you start it with, and the receivers will listen for the sync packets from the transmitter. Note that in its current version the receivers will run the radio as much as possible in receive mode, which is not great for power consumption. An improved implementation would have the receivers only turn on the radio when it expects the transmitter to send a packet.

[Michael01101]

Hello Audun,

thank you for your great answer. Sorry for my late reply, I was out of office.

I continued my work on this and I figured something weird out.

I tried to add a continuous data transmission to the ble_app_uart example of the timesync-demo. To achieve this I implemented a timer which calls the ble_nus_data_send function every 40ms in its timer handler. So I added the following code to the ble_app_uart example: 

static const nrfx_timer_t   m_timer = NRFX_TIMER_INSTANCE(4);

static uint32_t counter = 0;
static uint8_t array[200];

void timer_handler(nrf_timer_event_t event_type, void* p_context)
{
    ret_code_t err_code;
    counter++;
    uint16_t length_array = 200;

    err_code = ble_nus_data_send(&m_nus, array, &length_array, m_conn_handle);
    if ((err_code != NRF_ERROR_INVALID_STATE) &&
        (err_code != NRF_ERROR_RESOURCES) &&
        (err_code != NRF_ERROR_NOT_FOUND))
    {
        APP_ERROR_CHECK(err_code);
    }
}

void event_timer_init(void)
{
    ret_code_t err_code;
    
    nrfx_timer_config_t timer_config = NRFX_TIMER_DEFAULT_CONFIG;
    timer_config.frequency = NRF_TIMER_FREQ_125kHz;
    err_code = nrfx_timer_init(&m_timer, &timer_config, timer_handler);
    APP_ERROR_CHECK(err_code);

    uint32_t ticks = nrfx_timer_ms_to_ticks(&m_timer,40);
    nrfx_timer_extended_compare(&m_timer, NRF_TIMER_CC_CHANNEL0, ticks, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK, true);
    nrfx_timer_enable(&m_timer);
}

void init_array (void)
{
    int i;
    for(i = 0; i < 200; i++)
    {
        array[i] = 33;
    }
}

int main(void)
{
    ...
    event_timer_init();
    init_array();
    ...
}

I use TIMER4. 

Here is my problem: The timer handler (and the ble_nus_data_send() function) gets called every ~12s instead of every 40ms.

If I add the code above into the normal ble_app_uart example without timer sync it works like it should.

Here are my questions:

1. Do you know what causes this weird behaviour?

2. Is TIMER4 available in general? (TIMER0 is Softdevice, TIMER2 and TIMER3 for timesync)

3. Can you please provide me some proper guidance how to fix this issue?

Thank you very much in advance.

#Update:

It looks like If I use TIMER1 it works like it should. Can you please still answer my questions. Thank you very much.

[Audun]

Hi Michael,

I looked at the code again, and noticed that different timers are used in the time_sync examples depending on SDK version. Could there be a conflict here with the version you are using?

SDK 14.2.0 version:

    ts_params.high_freq_timer[0] = NRF_TIMER3;
    ts_params.high_freq_timer[1] = NRF_TIMER2;

SDK 16.0.0 version:

    ts_init_t init_ts =
    {
        .high_freq_timer[0] = NRF_TIMER3,
        .high_freq_timer[1] = NRF_TIMER4,

[Michael01101]

Hi Audun, 

yes, there was an conflict. Now I use TIMER1 for my application and it works.

Thank you.

Kind regards,

Michael

[Michael01101]

Hello Audun,

I have another question regarding the wireless timer sync.

Do you have any experience how the wireless timer sync affects the throughput of the NUS in this ble_app_uart example?

Thank you very much in advance.

Best regards,

Michael

[Audun]

Hi Michael,

sadly I've not really tested NUS throughput together with time_sync. If there is a negative impact on throughput I imagine it would be slight.

The time_sync code requests timeslots at normal priority, which is below BLE activity: https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/priorities_and_events_intro.html#priorities_and_events__table_qgg_zc2_cs

Audun

[Michael01101]

Hello Audun,

thank you very much for your reply. 

I added the wireless timer sync successfully to my application and it works great. I already knew that the usage of the wirless timer sync would increase the current consumption. But I did not expect, that the power consumption increases so much.

The power consumption of the peripherals was ~1mA before. With wireless timer sync the power consumption of the peripherals (which receive the sync pakets) increases to ~48mA. This is too much for our application. I should achieve <5mA or at least <10mA. 

In a previous comment you already mentioned:

Audun said:

Note that in its current version the receivers will run the radio as much as possible in receive mode, which is not great for power consumption. An improved implementation would have the receivers only turn on the radio when it expects the transmitter to send a packet.

I need to lower the current consumption of the peripherals (receivers of the sync pakets). I am using the lowest sync interval of 1Hz (1sec). 

My questions:

1. Can you please provide me some guidance how to lower this current consumption?

2. Can you please give me some suggestions what changes do I have to make?

3. How can I implement that "the receivers only turn on the radio when it expects the transmitter to send a paket"?

Finally, it looks like that the success of our whole project depends on your help.

Any kind of help is always appreciated. Thank you very much in advance.

Best regards,

Michael

[Audun]

Hi Michael,

It is surprising that you see this high power consumption. I was expecting average current on the receiver to be in line with the RX scenario outlined here: https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/pmu.html?cp=4_2_0_16_0_0_0#unique_1047287462

(these numbers show current consumption for the entire chip for the given scenario)

If you are not using the DC/DC converter in your design, these numbers would be higher (in the ~13 mA range). Ref. electrical characteristics of the radio peripheral.

How are you measuring the current? And is there other circuitry in your design that could be contributing to the consumption you see?

Audun

[Michael01101]

Hello Audun,

thank you so much for your quick reply.

Audun said:

I was expecting average current on the receiver to be in line with the RX scenario outlined here

I know these current consumption scenarios and I also expected them. That is the reason why I am so curious.

I am using a DCDC-regulator and it is activated. 

Audun said:

How are you measuring the current?

I flashed my peripheral software on my target hardware: BMD-300 (contains nRF52832 chip)

I measure the current at the supply pins of this module. So there are no other components involved.

The software works like it should, but with too high current consumption.

If I comment out sync_timer_init() in the main function, the receiver should not run the radio all the time and the wireless timer sync is "deactivated". Is that correct? 

I commented sync_timer_init() out and the current consumption stays at ~40mA. So it looks like that the wireless timer sync is not responsible for the huge current draw. Can you confirm that?

Any kind of feedback is appreciated. Thank you very much.

Kind regards,

Michael

------------------------------------------------------------------------------------------------------------------

#Edit (one hour later):

Hello Audun, I programmed another BMD-300 to check if the actual BMD-300 is faulty:

Now I can achieve a current consumption of ~7mA @ 2.45 V. When I disable wireless timer sync by comment sync_timer_init() out, I have a consumption of ~1mA @ 2,45V. So it seems like the wireless timer sync cause an extra 6 mA. This sounds reasonable I guess?

We are still interested in lowering the total current consumption. We would appreciate very much if you could answer our previous questions:

Michael01101 said:

2. Can you please give me some suggestions what changes do I have to make?

3. How can I implement that "the receivers only turn on the radio when it expects the transmitter to send a paket"?

Thank you very much in advance.

Best regards,

Michael