Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
We are working with a CYBT-423028-02 dual mode Bluetooth BR/EDR + BLE module. Because of a measurement timestamping requirement, I started to investigate use of the real-time clock (RTC) available in the CYW20719. Since the RTC would be reset by an external device each time it connects, high accuracy over the long term is not required. However, my results so far make the RTC unusable for our purposes.
I've included captured WICED_BT_TRACE messages generated by my program which is just the hello_client demo program with RTC functions added.
I added the following lines near the end of the hello_client_app_init() function:
When I call rtc_getRTCTime() immediately afterwards, it yields the expected time 06:00:00. After a RTOS delay of 60000 ms, a call to rtc_getRTCTime() yields a time of 06:01:04, an error of over +6%.
I also added a call to rtc_getRTCTime() in the 1-second app timer implemented in the hello_client demo program. After an actual elapsed time of 4m51s (as measured by my computer clock), the RTC shows an elapsed time of 5m12s, an error of over +7%. This seems quite high.
But, when a central device connects to the CYW20719, the RTC seems to increase its tick rate by a factor of 5.2 as shown by the RTC times in the trace messages. Worse yet, after the central device disconnects, the RTC appears to stop and continues to report the time at which the disconnection occurred.
Is an external crystal required for the RTC to work properly or am I missing something?
Here are my WICED_BT_TRACE messages. The timestamps in square brackets were generated by my COM port monitor program.
I assume that you meant to say that the internal LPO is inaccurate. I can accept that, even a 7% error would be understandable. However, if it is normal to have a 400% error while a connection is active and normal to have the RTC just stop running after a disconnect, it seems that the RTC should be documented as only usable with an external crystal rather than imply that the RTC is just less accurate when using an internal LPO.