Old version

[sevstels]

Dear author. I want to porting this code to the old version SDK for nRF51822. Can I ask you for an old version of this project?

[nordic-auko]

Hello, the original version of this code was indeed made for the nRF51 series. However, in its current iteration it's not possible to port directly to the nRF51 due to hardware differences (mainly lack of EGU peripheral).

I could not find the original nRF51 source code, but I see this is the last commit before the EGU was introduced into the codebase: https://github.com/nordic-auko/nRF5-ble-timesync-demo/tree/409015d1a6dc49af52801f54fba141be5b0a0ec5

[sevstels]

Thank you. I'll try to port it and run. :) Сurrent example for 52 cannot transfer anything to the slave at all. And it makes me very upset.

[sevstels]

What is the meaning of the instruction ? (void)NRF_TIMER0->EVENTS_COMPARE[0]; (void)NRF_TIMER0->EVENTS_COMPARE[1];

[nordic-auko]

What is the meaning of the instruction ? (void)NRF_TIMER0->EVENTS_COMPARE[0]; (void)NRF_TIMER0->EVENTS_COMPARE[1];

In NRF52, CPU domain is 64 MHz, and peripheral domain is 16 MHz. There is a write buffer from CPU to register domain. Reading a register in 16 MHz domain flushes the write buffer. This is useful in IRQs, to ensure that the appropriate EVENT register is actually set to 0 before the IRQ finishes. If this register is not set to 0, the IRQ will be triggered again immediately. In NRF51, CPU and Peripheral domains are both 16 MHz, and there is no such write buffer.

[sevstels]

Probably Nordic should introduce a sync(); instruction in the API, to make it clear and standard. How wisely it is done in AD BlackFin processors.

May I ask this question? If two devices are already connected. Does the slave switch automatically to the TimeSlot channel or does it need to be notified in advance?

[nordic-auko]

May I ask this question? If two devices are already connected. Does the slave switch automatically to the TimeSlot channel or does it need to be notified in advance?

There is no notion of "connection" in the timesync code. The transmitter/master always transmits sync packets at a fixed rate, and the receivers/slaves (it can be any number of receivers) listen for these packets. There is currently no intelligence to when the receivers are listening, they simply run the radio in receive mode as much as possible. If there is BLE activity at the same time, the timesync code will not be able to run the radio as much as it wants, but it will request as much radio time as possible

[sevstels]

Clear. I implemented everything differently. This works already over the established BLE connection and without using SHORTS. Phaze offset do not compensated to 0, for my case this is not important.

Video here: https://singapore-ru.com/files/ble-lock.mp4

[nordic-auko]

Closing after inactivity