Hi Everyone,
We are currently stumped and are looking for guidance. A brief overview of what's needed from our client are as follows:
1) From the nRF mesh app, send a start command to all peripherals (can range from 2-10 devices) to turn on all their timer/counter that will be used for keeping track of the elapsed time.
2) The peripherals (nRF52832 DK) will then keep a timer/counter going until button1 on device1 is pushed. Device 1 now has a recorded value of the start time to its own end time. Calculations can be made to find out the elapsed time
3) These will keep going till nth-device is done. The devices will be holding this value until asked by the nRF mesh app or a client node and get the value.
I hope I wrote this in a way that visualizing this was easy.
The things we considered or attempted to implement:
1) we thought of implementing the time synchronization technique shown here: https://devzone.nordicsemi.com/guides/short-range-guides/b/bluetooth-low-energy/posts/wireless-timer-synchronization-among-nrf5-devices but it seems like implementing this onto the mesh would take a while and if at all possible. We saw issues such as having to modify the mesh stack which could potentially void the certification as seen in this devzone.nordicsemi.com/.../how-to-use-timeslots-and-radio-hal-to-send-time-sync-packets-in-mesh
2) we thought of using Zephyr-RTOS but they did not have any time synchronization example except for the gPTP. From our understanding, we would require an ethernet port but this would void the wireless requirement needed from our client.
3) We thought of implementing a GPS module because of its PPS but these devices will be indoors and sometimes out of sight from the satellites. We can't have an extension on the Antenna sitting beside a window as this is not at all feasible.
3) But then we realized we were going all wrong about this. We just needed a way to start their timer at the same time once all of the peripherals are ready. Unfortunately, we don't know where to start. We don't want to implement a constant delay where it turns ON after X-ms because this is a terrible idea. We think that the acknowledgement might play a role here but still unsure.
We understand that the crystal's PPM can cause a drift but the elapsed time wouldn't run for more than 10 minutes so an error of anything less than 5ms is ok.
The reason why we are using Bluetooth mesh is because of its theoretically unlimited distance and its ability to relay messages. We imagine that the devices will sometimes be placed in a straight line each one more than 8 feet apart from each other.
We will be more than happy to hear any insight or even a completely different approach to this problem.
