I have a custom load cell setup with HX717 ADC connected to STM32F072 MCU. The MCU is connected using the internal usb to Klipper host. The boards were fabricated without a crystal for the external clock. However this MCU synchronizes it’s clock via the USB signals. The Klipper MCU adj chart doesn’t seem real stable but I haven’t encountered any Klipper errors running 4 of these on same printer 24/7. The adjust values seem to drift a good bit but are pretty continuous with occasional 50-100 usec discontinuities. Looking for some feedback if these are good enough (at least for dedicated load cell) or what kind of issues to look out for. 3 of these are being used to monitor belt tension and the remaining one was being used as a probe.
I recommend deploying and utilizing a crystal on micro-controllers when using Klipper. The cost of the crystal is typically pretty small and it does measurably improve Klipper’s multi-mcu clock synchronization system.
Internally, Klipper implements homing and probing operations using the time synchronization system. That is, whenever the system observes an endstop or probe event, the ultimate position is obtained by correlating the time of the sensor observation to the timing of the stepper motor commands. If the stepper is on a different mcu from the endstop/probe and there is inaccuracies in the correlation between the mcu clocks, then that could result in increased positional inaccuracy.
Some mcus support USB clock synchronization that could potentially improve the accuracy of an mcu without a crystal. In my past tests this system wasn’t as accurate as an actual crystal. Worse, currently several mcus only use the “usb clock recovery” to improve the timing of the USB implementation and they do not improve the internal scheduling clock. The stm32f072 is an example of this - when compiling with an “internal clock” the main scheduling timer uses only the internal silicon based clock and it is not improved by the usb system.
Anyway, all that aside, your question was whether or not your implementation is “good enough”. Alas, I don’t have a good way of judging that. Your graphs seem noticeably worse than systems with crystals. However, I can’t say if that will result in a measurable change in print quality. The Klipper clock synchronization code is fairly tolerant, so it’s rare for it to cause “shutdown errors”. The biggest risk of “shutdown errors” is for mcus enclosed in a chamber that experience rapid heating/cooling - silicon clocks are known to vary based on temperature, and so rapid temperature changes is when the system is most fragile. As above though, accuracy may suffer even if there are no “shutdown errors” reported.
