SDK14, S132 v5.0.0, nRF52832: Unexpectedly high RTC drift?

RE: SDK14, S132 v5.0.0, nRF52832: Unexpectedly high RTC drift?

ketiljo — Fri, 11 May 2018 11:03:57 GMT

The width of the receive window is set by the clock tolerance. You can have a narrower window with a more accurate crystal. If you set the tolerance lower than the crystal have, you will miss the window more often and the packet loss will increase.

RE: SDK14, S132 v5.0.0, nRF52832: Unexpectedly high RTC drift?

Sydney — Wed, 09 May 2018 15:39:51 GMT

Good call. My best guess currently is that our original board designer copied the dev kit, which uses 12pF loading caps. But the dev kit uses a crystal with CL=9pF, which according to this equation would mean 14pF capacitors should've been used, which I guess is close enough.

But our designer must've changed the crystal without changing the loading caps accordingly. Our crystal has CL=12.5pF, which works out to 21pF loading caps. We'll get this fixed in future runs of the board, but in the meantime, we'll probably need to apply some sort of scale factor in firmware.

On a related note, any idea how this might be affecting BLE performance? As mentioned above, we've configured the softdevice with an LFCLK accuracy of 20ppm, but our effective accuracy is more like 100-120ppm.

RE: SDK14, S132 v5.0.0, nRF52832: Unexpectedly high RTC drift?

ketiljo — Wed, 09 May 2018 13:59:46 GMT

Sounds like the 32 kHz crystal isn't loaded correctly. Check the CL value in the crystal's datasheet. The pin capacitance of the nRF51 is 4 pF. This gives the value of the load caps to be (each):

Ccal p= CL *2 - 4 pF

If you're using the wrong value, you will pull the frequency of the crystal.