Pinecil V2 negotiates too high PD voltage overloading 60W chargers and cables

[21micha37]

Describe the bug
Pinecil V2 always negotiates 20V overloading 60W (20V 3A) charger

To Reproduce
Pinecil V2 with ~6.2ohm tip installed connected to any 20V 3A charger

Expected behavior
While using ~6.2ohm tip on 3A charger it should negotiate 15V (or 18V if PPS is available)

Details of your device:

• Device: Genuine Pinecil V2
• Release: multiple ones, from factory 2.20 to current 2.22
• Power adapters being used:
  Apple A1947 61W 20.3V3A/15V3A/9V3A/5.2V3A
  Anker A2613 60W 20V3A/15V3A/9V3A/5V2.4A
  Doogee TP651C-EU 65W 20V3.25A/15V3A/12V3A/9V3A/5V3A, PPS 3.3-21V3A/3.3-11V6A

Additional context
Depending on tip, cable, and charger combination sometimes it will work, otherwise pinecil restarts after turning the heating on
Tested on both 3A and 5A cables (pinecil also ignores 3A cable limit) - samsung 3A, pine64 3A, apple 5A, baseus 5A
Confirmed chargers and cables performance with fnirsi FNB58 and adjustable load.
Confirmed in debug mode that pinecil is correctly recognizing available PD modes and tip resistance
Most problems are on off-brand 5.9ohm tip that works only with 65W charger and long, high resistance cable (pulse draw with almost 3.5A of current), but genuine tips also cause 60W chargers and cables to work beyond their specification (up to 3.2A).

Possible solution
I suspect that software seeing 60W available counts on cable resistance and overcurrent tolerance of a charger, but some devices have power line compensation and rather sharp current limit. Manual PD voltage select in the settings would solve these problems.

[Ralim]

Hello,

This is actually something that was discussed and planned in the Pinecil chat.

When deciding on the voltage to use we include a small fudge factor on the resistance value to compensate for (cable resistance + MOSFET on resistance + PCB resistance + connector resistances).

Release 2.21 did actually take this fudge factor out as a test, and it didn't fix charger reset issues with the charger at the time that was being looked at. (A frame.work laptop charger).

There has been discussion for if we should expose an option to turn on and off the fudge factor and I'm not against adding this.
Adding a manual voltage selection is not planned, as I'm burned enough by QC with this that I don't want to take on liability of people who just set things to max and then try and chase me to be financially liable for their damage to their charger.

The original intention was when time permitted, to actually check the chargers specified current limit thresholds if those are available but this has not yet been implemented.

Noting that the tip specification for short tips is 6.2 ohms +- approx 0.2 ohms. Any tips that are cloning the Pine64 standard may have issues. I selected 6.2 out of the available options due to having tighter tolerances and also being easier to manufacture.

Also noting that cable current ratings are the problem of the charger to check as far as I recall from the specifications.

[21micha37]

Hi!
Thanks for fast reply.

I'm aware that running chargers at their limit could damage them, that's why i opened this thread :v
Most chargers that i have supports load line compensation, so cable resistance should give zero extra wiggle room. Resistances of mosfet and connectors are negligible. Even if charger gives 20V without any overshoot, and the tip is spot on 6.2ohm, it will still draw a tiny bit too much (20V/6.2ohm=3.25A), and looking at the worse case, but still in spec (20.5V/6ohm=3.4A). It should be quite easy to either add smart voltage selection that could only negotiate lower or the same voltage that soldering iron would on it's own or include voltage negotiation limit based on tip resistance and power limit set by a user.

Tell me if i'm wrong, but isn't ironOS already checking charger power/current capability? In PD debug there are pretty detailed info about supported modes, and they are correct. There must be something, because i've heard that soldering is also possible on 45W supply. But for some reason in my case iron is allowed to go over these limits. Cable and charger communicates properly - when using 60W cable the 65W charger reports 3A/60W max, while with 5A cable it will go up to 3.25A/65W. This current limit is also enforced by safety features of a charger properly, iron just don't care.

I'm aware that this is quite complicated, because most people probably use pinecil with stock tips, 65W charger, and 60W silicone cable, and if soldering iron would default to ohm-law and usb-spec correct mode it would lost almost half of it's power, that's why i suggest limiting negotiated PD voltage based on calculated max power draw and power limit in settings or separate setting "do not go over xV"

[Ralim]

Hello,

I've generally found the cable compensation to be sub-par on most chargers I've used when operating at 20V (appears more aimed at 5V) except on those with tethered cables. I think is is mostly to avoid risk of over voltage as they don't know the cable resistance ahead of time.
(Would love data on this if you have any).

Yes IronOS is decoding the full PD published specifications from the chargers, (which is used except for the ones that advertise 21V on PPS instead of 20V, as a lot of those can't actually do 21V).
You are correct on the slight over current of pushing around the 0.2A over assuming 0 intermediate losses (and ignoring chargers having to have +be tolerance).
Note here that there is no power limit IronOS can do in these situations that helps here, the only option is to drop voltage.

(The power limit is an average limit, enforced by limiting duty cycle. This doesn't stop a peak current. We also do actually do this, where the duty cycle for a 60W charger will actually be slightly capped to keep average below 60W. But doesn't help on the discussion of peak current).

As mentioned before we have a fudge factor, that is used to account for all the losses + the always existing off time. So that way our effective resistance is slightly higher. (Enforced off time is there as that is the time when we measure the tip temperature).

IronOS/source/Core/Drivers/USBPD.cpp

Line 138 in ad15a53

uint8_t tipResistance = getTipResistanceX10() + 5;

If you look in the rest of that function, we do actually follow the ohms law and check what our peak current is. And then check that against all of our voltage options.

So the only reasonable answer I would see here would be to offer the ability to disable the fudge factor to suit chargers that have a 0% over current tolerance ?

[21micha37]

I see couple possible solutions, option to disable fudge factor is definitely one of them. Manual lower voltage selection would also solve that problem. Btw, i know that right now power limit is basically PWM, but it could be improved so that if Pmax@lowervoltage>Plimit then choose lower voltage? I'm not a programmer so sorry if my ideas are unreasonable :)

If you are interested in some data about chargers behavior (same models as in original post), here it is:
-Apple 61W starts from 20.3V, and is able to sustain 3,35A draw on 3A limit. Anything over that trips OCP
-Doogee 65W can go up to 21V, tested on 20V, goes up to 3.7A on 3.25A limit, but on PPS 20V3A trips just over 3.15A
-Anker 60W reaches up to 3.3A on 3A limit
I can't tell if the power line compensation is working. Everything was tested using shitty, long, chinese cable, and voltage drop was very similar, around 450mV@3A. What's important, every charger had very sharp current limit. Unlike older/cheaper ones where first voltage is dropping with a curve, here right up to limit it was rock solid, and even slightly crossing that line caused voltage to go to zero.

[Nickduino]

So the only reasonable answer I would see here would be to offer the ability to disable the fudge factor to suit chargers that have a 0% over current tolerance ?

...or use a flag to know if the power was cut at the start of the heating? And at the next startup (which is necessarily while connected to the same power source since it trips and restarts immediately), you automatically revert to a lower voltage