Just me so far, but I’ve been using it for a few weeks now.
Indeed. I’d still appreciate it if you could confirm the possibility that this is a hardware or a firmware problem, and forward it to whoever is responsible and can take a look. Here’s a possible explanation:
The logic in Blaming EmbeddedController/baseboard/fwk/battery.c at 72748b7d0aa4ac18204f00608ed61451b10314a3 · FrameworkComputer/EmbeddedController · GitHub (this code is custom to the Framework!) sets the charging mode to CHARGE_CONTROL_IDLE when the set charge threshold is reached. If the charge current happens to be high at this point, it’s suddenly reduced to 0, and this is precisely what causes disconnects in my experiments.
Note that CHARGE_CONTROL_IDLE is even set if the max threshold is 100% (i.e., the default), but still, it seems that only users with a threshold <100% seem to suffer from disconnects. I suspect that is because the other parts of the charging logic make sure that the charge current is low when close to 100%. And when a low current is suddenly set to 0, this does not result in a disconnect according to my experiments.
All of this is speculation until tested, but it seems plausible that this is the cause. A second reason to investigate this code further is that it may be the reason for the flipping between charging and discharging.