transmitter frequency not so clear

[David140]

Hi all, thanks for the amazing work, I'm using this syncro architecture to sample difference sensors at the same time. I found some issues regarding syncro frequency. This plot shows the time between two consecutive syncro packets from transmitter. I take the data each 2ms (sampling at 500Hz) and the syncro frequency is the standard one (30hz). So, doing some maths, it makes sense for me having values of 16-17 units between each syncro packet. Indeed, each packet is sent every 1/30 = 33ms, I sample each 2ms, I'm expecting to have 16-17 samples between each syncro packet and the next one. But, as you see, I don't know why every 6 packets, there is a longer interval (66), that is the time used to send 4 packets (16.5*4 = 66). Do you have an explanation? I was expecting to have always 16-17 samples between each syncro packet. I want also to highlight that every time I have a 66-samples packet, the receiver misses that packet (I noticed this introducing a counter_packet variable inside the syncro packet). Thanks for the help, David

[David140]

Is this repo still maintained?

[kwakeham]

You're better off asking in nordic dev zone. A lot of your explanation isn't clear as to what you've setup here and why you're sampling instead of triggering interrupts on edges. It sounds like you're using a whole separate device that is sampling in and around 500hz that you're saying is 500hz -- but more than likely isn't or at least isn't locked to the same clock. Depending on how accurate each clock is the sampling and the reception will happen at different clocks and therefore every so often depending on how long the pulse is from the timing you'll miss one as they drift. If it's the same device you could be in race condition. It could also be regular interference or a ble transmission is happening at that time and it it skips it -- or as you're suggesting maybe there is a code bug. Almost all nordic support happens over at nordic dev zone and you'll find very little in the wild so best to move this there.

[kwakeham]

Also, most Nordic countries are on holiday this month

[nordic-auko]

Hi @David140, yes, the repo is still maintained. I've been on vacation for the past couple of weeks.

Which branch have you been using so far? I've been working on improvements to this code (https://github.com/nordic-auko/nRF5-ble-timesync-demo/tree/counter_revamp) that haven't made it into the master branch yet. The logic for when to transmit sync packets has been changed quite a bit here.

Generally, the transmitter will request timeslots to match the desired transmission rate. The softdevice will reject these requests if there is BLE activity of higher priority scheduled at the same time. Additionally, the master branch avoids transmitting sync packets if the 16 MHz timer is close to wraparound, in order to avoid corner cases on the receiver side. There is also some logic to offset the timeslots to avoid this corner case, but I don't think this was very successful.

The counter_revamp branch handles the wraparound corner cases properly, so there is no need to skip transmissions close to timer wraparound. There will still be some skipped transmissions when BLE is used at the same time, but you can disable BLE activity to get a baseline measurement.

[David140]

Hi @nordic-auko! Thanks for the reply. I started my development from master branch, but actually I added lots of features (including SAADC sampling e some other things) and it's quite hard for me to port all the work in the new branch you linked.

Generally, the transmitter will request timeslots to match the desired transmission rate. The softdevice will reject these requests if there is BLE activity of higher priority scheduled at the same time. Additionally, the master branch avoids transmitting sync packets if the 16 MHz timer is close to wraparound, in order to avoid corner cases on the receiver side. There is also some logic to offset the timeslots to avoid this corner case, but I don't think this was very successful.

I know these limitations, but I don't know if this is my case, I mean, I have a missed syncro pack exactly every 5 sent packets. This seems more like a sort of bug.

There will still be some skipped transmissions when BLE is used at the same time, but you can disable BLE activity to get a baseline measurement

Do you know if it is possible to disable BLE before syncro packet transmission also in the master branch? In this way, I could check if that could be my problem. Thanks!

[nordic-auko]

Hi @nordic-auko! Thanks for the reply. I started my development from master branch, but actually I added lots of features (including SAADC sampling e some other things) and it's quite hard for me to port all the work in the new branch you linked.

No worries! Have you made modifications to the time_sync.c and .h files? If not, there are only some minor API changes to accommodate.

Generally, the transmitter will request timeslots to match the desired transmission rate. The softdevice will reject these requests if there is BLE activity of higher priority scheduled at the same time. Additionally, the master branch avoids transmitting sync packets if the 16 MHz timer is close to wraparound, in order to avoid corner cases on the receiver side. There is also some logic to offset the timeslots to avoid this corner case, but I don't think this was very successful.

I know these limitations, but I don't know if this is my case, I mean, I have a missed syncro pack exactly every 5 sent packets. This seems more like a sort of bug.

During work on this other branch I did observe that there were quite a few missed sync packet transmissions in the master branch. However, I did not determine if this was a bug (flaw in the logic that offsets transmission to avoid wraparound) or normal clock drift that caused the wraparound logic to hit more often.

I'm at a home office at the moment, and won't be able to do any testing until the end of next week at the earliest.

It might not be too much work for you to try running an example from the other branch with only your instrumentation added to see if the behavior improves? I mean without adding the SAADC code etc.

There will still be some skipped transmissions when BLE is used at the same time, but you can disable BLE activity to get a baseline measurement

Do you know if it is possible to disable BLE before syncro packet transmission also in the master branch? In this way, I could check if that could be my problem.

If you comment out the advertising_start (if peripheral) and scan_start (if central) functions, there should be no BLE activity that would interfere. Also, if you are actively storing data to flash memory this could also introduce some timeslot contention.

[David140]

Have you made modifications to the time_sync.c and .h files? If not, there are only some minor API changes to accommodate.

Yes, I added something in time_sync.c/time_sync.h, especcially PPI feature for syncronized SAADC sampling.

It might not be too much work for you to try running an example from the other branch with only your instrumentation added to see if the behavior improves? I mean without adding the SAADC code etc.

I can try adding to your branch essential parts to log data and see the syncronization mechanics behaviour, it just needs some time, but sooner or later I can do this test.

If you comment out the advertising_start (if peripheral) and scan_start (if central) functions, there should be no BLE activity that would interfere. Also, if you are actively storing data to flash memory this could also introduce some timeslot contention.

I could comment out also the uart initialization, I think BLE won't start without uart_init. No storage in flash so far, just RAM and serial log to store the data on PC side.

[nordic-auko]

Closing after inactivity