Connection clock drift compensation not working correctly about sniffle HOT 14 CLOSED

Thanks for the feedback, there may indeed be a regression I introduced that I didn't notice in my testing. I'll take a look at your pcaps and console output.

If you have the chance, could you try version 1.2 to see whether or not it's affected? That might help me narrow down possible causes.

from sniffle.

Looking at the PCAPs you shared, I see what happened. The hop interval specified in the connect request was 100 ms, but the observed hop interval was 99.978 ms according to both Sniffle PCAPs. This means that the Sniffle clock and master device's clock are 220 ppm apart, which is worse than usual (an order or magnitude worse than the devices I do my testing with). I'm curious if the master device involved in the connection has a low quality crystal oscillator. What happened is that after packet 296 in the version 1.3 PCAP, due to clock drift, the M->S packet was getting transmitted before the sniffer tuned to the new channel. Thus, for packets 297 onwards in the version 1.3 PCAP, there was only one packet observed per connection event (S->M). A while later, further clock drift caused even the S->M packets to be missed, causing Sniffle to lose the connection.

Sniffle does have a clock drift detection and compensation mechanism, and evidently it was working correctly in version 1.1, but failed to compensate for drift in version 1.3. I'm not sure if the clock drift compensator is broken altogether, or if this 220 ppm drift was just outside the thresholds I may have changed between 1.1 and 1.3.

I didn't notice this issue in my testing because I've only been testing on devices with accurate clocks.

from sniffle.

Indeed, as part of changes in 1.3, I tightened what's effectively the range of adjustment for the drift compensator: a8db3b0#diff-2a1cb6a7735cd9d2387b35fbc74e87feR107

After accounting for other latencies in the system, your 220 ppm clock drift is just a little too much for the tightened limit.

Try changing AO_TARG back to 4000, recompile, and let me know if 1.3 works for you after this change. I plan to fix this a different way if this is indeed the issue, but I just want to confirm this first.

from sniffle.

I pushed a commit that I think should fix it: ad0dadb

It does clock drift compensation 4x more frequently with this, so I think it should now tolerate clock drift up to around 600 ppm, maybe a little more.

You can just try compiling the latest master, and not bother messing with AO_TARG if this change works.

from sniffle.

I tried the latest RadioTask.c. Sniffle captures packets for longer, but then still out of sync.
sniffle.zip

from sniffle.

Sniffle version 1.2 works well, like version 1.1.

from sniffle.

It seems AO_TARG = 4000 works well with RadioTask.c release version 1.3, but does not work with the latest master version.

from sniffle.

Thanks for the detailed testing, this helps. I have other reasons why I didn't want to raise AO_TARG back to 4000, but good to know that raising it works with the 1.3, and not with master. That gives me some insight. When I have time, I might build a crude master device with a software-hacked inaccurate clock to test the drift compensator and see why it's acting up.

from sniffle.

One more test you could try if you have time: take the current master branch, but change AO_TARG (https://github.com/nccgroup/Sniffle/blob/master/fw/RadioTask.c#L115) to 3000 instead of 2000, and change the length of the anchorOffset array (https://github.com/nccgroup/Sniffle/blob/master/fw/RadioTask.c#L86) to 8 from 4. Try following the connection for at least a minute to make sure the drift compensator is working correctly.

It might be that the drift compensator is working but now excessively sensitive to lost packets with the last change I made.

from sniffle.

I tried anchorOffset[8] and AO_TARG 3000 with the latest master version of RadioTask.c. It does not work.
test1.zip

from sniffle.

Another case that I came across a while ago and that I would like to report now is just the original simple_peripheral example from Texas Instruments, which is a part of ble_sdk_2_02_04_06 for cc2640. After connecting, the slave allows the master to change connInterval to 800 * 1.25 = 1000 ms = 1 s! After changing connInterval, both Sniffle 1.1 and Sniffle 1.3 quickly lose synchronization and freeze. Only a hardware reset (or USB jack reconnection) restores their normal state.
I tried other sniffers and I want to report that both ti2 and nrf3 lose synchronization too, only first ti with cc2540 works fine.
If you are interested in this, you can find additional information in the attached archive file. All sniffers worked simultaneously. Several attempts to connect and disconnect due to the fact that I did not synchronize ti sniffer to the slave's address.
test2.zip

from sniffle.

Thanks for reporting the second bug with long connection intervals. When I have time, I'll set up a master with an inaccurate clock to test and fix the first issue you described here, and then I can use the same master to test long connection intervals too.

from sniffle.

I was able to reproduce this issue by setting up a test master device with a deliberately inaccurate clock. Currently investigating the root cause.

from sniffle.

Fixed the issue with e0b00be. There was a logical error introduced in ad0dadb preventing the drift compensator from ever being invoked.

from sniffle.