nrf52 time synchron packet not arrived after BLE reconnect

hi,

I use softdevice s140 and nrf5_sdk_17.1. 

I import time sync demo from here (github.com/.../nRF5-ble-timesync-demo) to my project. 

My first usage version:

* nrf52 devices initalize and enable time sync library at startup

* a mobile phone connect to them and set one of them as timesync master

After that time synchronization works well. But if mobile phone reconnect randomly happen that time sync packets not arrived to slaves anymore (usually this happens sometimes everything remains ok). I cannot figure why this happen so I modify my usage:

* time sync library enable not start sd_radio_session

* when BLE connection established sd_radio_session is started and timeslot requested

* when BLE disconnects sd_radio_session is closed

After this modification time synchron packets arrived to slaves continuously if nrf52 device connects first to mobile phone which will be the time sync master. 

If time sync master reconnects none of slaves get more time sync packets. After that slave which is reconnect start to get time sync packets again. 

So my expericen with this second case that time sync packets arrived to slaves which are connected later than time sync master.

Any help would be appreciated.

  • Hi,

    I am not sure if I understood the issue correctly. So in the initial version, if the mobile phone disconnects and connects again, then the slave does not get the time sync packets. So after your change to call sd_radio_session only after a connection is established, you still see the issue or it got fixed?

    Can you show some logs or any code snippets that I can use to replicate this at my end?

  • There are 2 nrf52 device call master and slave. Master will send sny packets slave will listen to them. 

    During nrf52 startup ts_initalize and ts_enable is called, but ts_enable doesn't start radios session and request timeslot.

    When mobile app can send to devices a message for being a time sync master or slave. 

    Both starts radio session and request timeslot, and master call ts_tx_start() too.

    When works well:

    start mobile app which will connect to nrf52 devices

    switch on device which will be master (so this will connect first)

    switch on device which will be slave

    send message from mobile to devices for starting radio session and master sart to sends sync packet

    if change to switch on squence so slave will connect first it is not working slave doesn't get sync packets.

    in this case I don't get any NRF_RADIO_CALLBACK_SIGNAL_TYPE_RADIO in radio_callback on slave device.

    I log NRF_RADIO->STATE when I get NRF_RADIO_CALLBACK_SIGNAL_TYPE_EXTEND_SUCCEEDED in salve device and it is in RX state so it looks that it listen to packets.

    on master device I get NRF_RADIO_CALLBACK_SIGNAL_TYPE_RADIO and EVENTS_END so it looks that it sends sync packet well.

    if any of the nrf2 devices disconnect from mobile phone it starts to work (when 1 device connects to phone and other not it works).

    if slave disconnect from phone (here sync packet starts to arrived) then connect back it continues wokring.

    if master disconnect then connect agains it stop working. 

    now  I don't stop radio session when BLE_disconnect accours and start radio session when BLE_connect again. 

    But when I do this my expericen was the same (expect that one device disconnect it starts to work because in this case I stop it)

    Next week I want to write an example which I can share with you.

  • Hi,

    https://github.com/vregath/nrf_timeslot_test here is an example.

    there s readme which describes how can you reproduce the problem.

    thanks

  • Attila, 
    Sorry for the late response. We are ramping up after coming back from summer holidays. I will look at the details you gave and will reply to you today. 

    Thanks for your patience so far.

  • Attila, 

    The author of the project for this timesync demo, Audun,  accepted my request to comment on this thread directly. 

    So you will have your code looked by the expert. You will hear from Audun soon.

Related