ESP32 Time Clock runs slow under certain conditions with Bluetooth Classic HF client (IDFGH-11110) #12282
Open
3 tasks done
Assignees
Labels
Comments
github-actions
bot
changed the title
|
Hi @danjulio!
|
|
Thanks for looking at this @KonstantinKondrashov.
I realize this is not a very detailed description. Please let me know if I can provide more data. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Answers checklist.
IDF version.
v4.4.4-439-gc25d92074e
Operating System used.
macOS
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
Custom Hardware
Power Supply used.
USB
What is the expected behavior?
I expect the system time as reported by gettimeofday() to remain fairly accurate during continuous operation of the ESP32 in a communication device that uses the Bluetooth Classic Handsfree Client Protocol to connect to a cellphone.
What is the actual behavior?
Under poor Bluetooth conditions (the phone is at the very edge of Bluetooth range) then the time clock running on the ESP32 can lose many tens of seconds per hour of real time.
This does not occur when the Bluetooth connection is good (e.g. the phone is in the same room as the device) or not present (e.g. the phone is so remote that the ESP32 can never connect).
See "More Information" for additional details.
Steps to reproduce.
The program is designed to run continuously (the ESP32 is not put to sleep at any time). When not connected to a Bluetooth device it will attempt a connection every minute. The following assumes the device has been paired with a cellphone (iPhone 13 iOS 16.6.1).
The external hardware RTC chip has been verified to hold the correct time.
Debug Logs.
More Information.
The log file contains a section of an overnight run showing approximately 1 hour of elapsed time during which the ESP32 loses 54 seconds (it is 54 seconds slower than the hardware RTC). [NOTE I had to cut out some of the log file to post this]. Interestingly the log file millisecond time stamps do appear to be keeping accurate time. At time 25205186 mSec the code corrects the ESP32 time clock. For the next hour you can see it struggles to maintain a connection with the phone. About one hour later, at 28807306 mSec, it checks the ESP32 time clock against the RTC and finds it is 54 seconds slow.
My Bluetooth code is based on the Espressif Bluetooth Classic Handsfree client demo code and I retained the logging information for the various GAP (bt_gap) and HF (bt_hf) callbacks that you can see in the log file. My bluetooth handling code can be found here: BT Task.
Again, if the devices are physically close and the Bluetooth SLC remains valid or if the devices are too far apart (or the device pairing information is deleted) then the clock maintains accurate time. It seems only when the Bluetooth stack is struggling to maintain a connection does the clock slow down (it never runs fast).
The text was updated successfully, but these errors were encountered: