nordic-auko / nRF5-ble-timesync-demo

nRF52 clock synchronization demo code
55 stars 50 forks source link

Maybe bugged branch? #19

Closed David140 closed 2 years ago

David140 commented 2 years ago

Hi all! I'm full time working to update my code with the new branch (count_revamp). I download the branch, flashed my boards and press the button to start the syncronization. After some seconds, this is the situation: image

So I reset the boards and I repeat the procedure. After some seconds, this is the situation: image

Are you sure this is a completely tested branch? It seems to be veeeery bugged (at least respect to master branch).

Moreover, if you just download the branch and build it with SES, it fails. I needed to make these changes to build the project:

Is it supposed to be normal?

I think I will need a lot of support in the following weeks. Thanks for the help

crazyskady commented 2 years ago

Hi, David I happened to use this demo a few months ago. The demo works well, thanks to the authors for this excellent feature. Maybe some suggestions could help you to find the root cause.

  1. Ensure the sender and receiver using the same RF address and channel. (If you can sync at start, I guess this tip is okay in your environment)2. Ensure there's only one sender using the same RF address and channel over the air, if you have more than one sender, reminder to update the address & channel. (This could be possible, I meet similar issue in my environment.)3. Using same module (both 52832 or both 52840 is verified in my test) and same compile environment for download the application for both sender&receiver.

BR, skady

----- 原始邮件 ----- 发件人:David140 @.> 收件人:nordic-auko/nRF5-ble-timesync-demo @.> 抄送人:Subscribed @.***> 主题:[nordic-auko/nRF5-ble-timesync-demo] Maybe bugged branch? (Issue #19) 日期:2021年12月23日 06点33分

Hi all!

I'm full time working to update my code with the new branch (count_revamp).

I download the branch, flashed my boards and press the button to start the syncronization.

This is the situation after some seconds:

Is it a bug?

I think I will need a lot of support in the following weeks.

Thanks for the help

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

David140 commented 2 years ago

Hi crazy, thanks for the answer!

  1. Ensure the sender and receiver using the same RF address and channel.

I think this is ok, the two boards can sync at the beginning, just for like 30s.

  1. Ensure there's only one sender using the same RF address and channel over the air, if you have more than one sender, reminder to update the address & channel.

I'm using at the moment just one sender (that is the BLE central) and one receiver (that is the BLE peripheral).

  1. Using same module

I'm using a NRF52840DK as BLE central (and sync packets sender) and a Adafruit Feather NRF52840 as BLE peripheral (and sync packets receiver). The MCU is the same (NRF52840) so I don't think this could be a problem. Maybe I can try to use 2 NRF52840 dongles (to exploit 2 identical boards) but I would be surprised if something will change.

UPDATE Also with 2 nrfr52840 dongles the problem is always the same... So far I used the master branch and syncro went on all the night without problems. Now I need to start and stop the syncro every X seconds for my application and the master branch (after some switch-on / switch-off procedures) crashes. I thought to solve the problem updating to this new version, but it seems like here the syncro crashes after few seconds even without switch-on / switch-off procedures...

Moreover, if you just download the branch and build it with SES, it fails. I needed to make these changes to build the project:

  • SDK_CONFIG: #define PPI_ENABLED 1 (it was 0)
  • INSERTING: nrfx_ppi.c file inside the project

Is it supposed to be normal?

I think this is not how the branch is supposed to work, it seems weird that it comes not compiling... I downloaded counter_revamp branch, is it the right branch (the updated one)?

crazyskady commented 2 years ago

Hi, David

I guess different board have no impact if use same module, not sure. But I guess crystal oscillator configurations (PPM and so on) in sdk_config.h could have some impact, not sure, you can set them same in both. :)May be you can send email to author ask for help directly. I can't remember no more details due to I have left the company which use this module. :)

BR, skady

----- 原始邮件 ----- 发件人:David140 @.> 收件人:nordic-auko/nRF5-ble-timesync-demo @.> 抄送人:Crazy Skady @.>, Comment @.> 主题:Re: [nordic-auko/nRF5-ble-timesync-demo] Maybe bugged branch? (Issue #19) 日期:2021年12月24日 01点44分

Hi crazy, thanks for the answer!

Ensure the sender and receiver using the same RF address and channel.

I think this is ok, the two boards can sync at the beginning, just for like 30s.

Ensure there's only one sender using the same RF address and channel over the air, if you have more than one sender, reminder to update the address & channel.

I'm using at the moment just one sender (that is the BLE central) and one receiver (that is the BLE peripheral).

Using same module

I'm using a NRF52840DK as BLE central (and sync packets sender) and a Adafruit Feather NRF52840 as BLE peripheral (and sync packets receiver). The MCU is the same (NRF52840) so I don't think this could be a problem. Maybe I can try to use 2 NRF52840 dongles (to exploit 2 identical boards) but I would be surprised if something will change.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

You are receiving this because you commented.Message ID: @.***>

nordic-auko commented 2 years ago

Hi David,

I tested the revamp branch again and see indeed the same issues as you. Will need to spend more time on this to understand if the issue was always there, or if there was a local difference that did not make it into the commit.

Specifically it seems that the 2nd timer (in counter mode) is not handled properly, as the offset is always in time units of TIME_SYNC_TIMER_MAX_VAL / 16000000 seconds.

David140 commented 2 years ago

Hi Audon, thanks for your time. I will check daily this topic to see if there are any updates from you. Thanks again!

David140 commented 2 years ago

Hello @nordic-auko Any news about this branch? Thanks!

David140 commented 2 years ago

Hello. Another month without an answer. We are developing a new product and this branch is still bugged. Could we have the correct commit in few days please? Thanks.

cperezmicrofactorycoop commented 2 years ago

Hi, I'm also hoping a fix on this situation would occur as I'm getting similar issue.

David140 commented 2 years ago

Hi @cperezmicrofactorycoop Audun has just pushed an errata corrige commit on the counter_revamp branch. I will keep this issue open until I have done the necessary tests to assure proper functioning. Thanks again!

nordic-auko commented 2 years ago

Hi, sorry for the lack of response on this one. Please give the updated counter_revamp branch a try and see if it fixes the issue

nordic-auko commented 2 years ago

Closing after inactivity