Ralim / IronOS

Open Source Soldering Iron firmware
https://ralim.github.io/IronOS/
GNU General Public License v3.0
7.24k stars 718 forks source link

TS80 + DN.OX Adapter 5v bug? #557

Closed lysdexic1 closed 2 years ago

lysdexic1 commented 4 years ago

Please edit this template and fill out all the information you can (where relevant). Failure to provide essential information can delay the response you receive.

Steps to reproduce:

  1. Update to v2.08
  2. Bring iron to temp using DN.OX adapter
  3. Unplug & repeat step 2. *4: I found that plugging the iron into a standard 5v2A supply and back into the DN.OX will also trigger this "5v only mode"

Video of problem if hard to reproduce

Maintain compatibility with the "supplied" adapter.

On the idle screen, you can hold the settings button and it will show you the firmware version.

2) AILAVI-180312 boost module: 5v/3A 9v/2A 12v/2A (24w max, QC2.0/3.0)

If submitting graphics to go on the iron, please use BMP or PNG files over JPG.

Ralim commented 4 years ago

Hmm, is this only occurring on the 2.08 update (i.e. doesn't occur on 2.07?) Very odd for this to happen.

Does this occur if you wait longer between re-plugs?

The TS80 attempts for QC3.0/2.0 at the start (i.e when you first plug it in), it does not continuously attempt to negotiate. If this fails then it stops asking for QC and thus you get the 5V mode of operation (as QC defaults to 5V for safety).

lysdexic1 commented 4 years ago

2.07 is where i joined the party, and everything worked fine with the adapter.

Iron has been off for 30 minutes, adapter 15-20. dont see it making a difference, but ill give it another 30 for both to see if anything changes.

Ralim commented 4 years ago

Ah, yeah no if its 30 minutes then it should be totally fine. I was thinking you were swapping much quicker than that.

rpoplawski0 commented 4 years ago

I'm experiencing similar problem.

My TS80 was happily running on 2.06. Upgraded to 2.08 today and it's stuck at 5V even in QC mode. ts80_1 ts80_2

The adapter was bundled with TS80 ts89_3

Reverting back to 2.06 fixes the problem.

EDIT: 2.07 is stuck at 5V as well.

lysdexic1 commented 4 years ago

Personal Experiences Update:

Through a combination of re-plugging all connectors I can eventually get 9V negotiation (but it will go back to 5v if power is removed). I am now using a QC trigger (https://www.aliexpress.com/i/32981745131.html) to negotiate the voltage when using my iron on AC. Although it works fine, it's not as elegant as going straight into the adapter.

coldfire0101 commented 4 years ago

any update to defaulting to 5v??. can you put option in menu to disable 5v??

Ralim commented 4 years ago

@coldfire0101 You cant disable 5V, as 5V is the "default" and the system has to negotiate away from it (to higher levels).

Is this issue still present on later releases @lysdexic1 ?

dmcinnes commented 3 years ago

I just updated to the latest firmware (v2.15) and can confirm I'm still having this problem with DN.OX QC adapter with model number DNQ18U-U.

Ralim commented 3 years ago

Could you have a look at testing the patches linked from this thread, specifically the ones coming from this PR. Highly likely its a similar issue for your chargers.

VaZso commented 3 years ago

I would like to also mention here: https://github.com/Ralim/IronOS/pull/994

That pull request was tested on Pinecil but it may also improve on TS80 if the root cause of QC3 problem was the same for some users...

dmcinnes commented 3 years ago

@Ralim I tried #989 and after the iron booted it started in 5v then switched to 9v. I turned on the "QC Neg" mode and that seems to do the trick! It's staying in 9v mode. With the setting off after the iron is idle for 20-30 seconds it flipped back to 5v and struggled to keep temperature. Thanks!

@VaZso it doesn't appear your branch has any artifacts associated with it, I guess because it's from a fork?

VaZso commented 3 years ago

@VaZso it doesn't appear your branch has any artifacts associated with it, I guess because it's from a fork?

@dmcinnes, I have forked IronOS main, then pushed modifications I did on the stack earlier and initiated a push request then. I have started experiencing with the firmware and only decided to contribute when I saw it is really working for me in a way I thought to be usable.

Ralim commented 3 years ago

Artefacts turn up once CI runs; which requires me to OK the first time for each account.

And the CI didn't finish due to issues in the compile. Once the build issues are fixed the artefacts will appear

VaZso commented 3 years ago

Right, CI didn't finish because there was a missing #ifdef POW_PD check around PD-related functions and it caused MHP30 to drop two warnings as it has no PD-related parts enabled/exists.

I have uploaded some modifications a few hours ago which should not have this problem now. Just found Re-request review button, I think I should have been used it.

Anyway, it seems I haven't understood what @dmcinnes wrote at first, maybe it was a bit too late in the evening... I knew there is an artifacts directory / generated, but didn't associate it to this question... :)

VaZso commented 3 years ago

@dmcinnes, sorry for this delay, @Ralim has just merged the code to main after having some cosmetic changes requested by CI. So you may test this option to see if it also helps on your charger like on some of my Baseus and Ugreen chargers.

Edit: As far as I see, it should support 12V over QC3 and not only 9V what you could achieve above. My power supplies worked for me when I set PD timeout on Pinecil up to 15 (around 1.5 seconds) while my PD chargers are still working well.

However, @Ralim wrote that the bootloader of TS80P has a 1-2 seconds additional delay, so you may have to use lower values I think, but I hope you can set appropriate delay if you have the very same problem what I had.

dmcinnes commented 3 years ago

@VaZso hmm I'm not seeing an additional option when I try that with my TS80, am I missing something?

Ralim commented 3 years ago

Hmm, for TS80 only you wont have any option as there is no PD to "get in the way" as the iron will go straight to QC mode.

Did you manage to test the alternative firmware with the different mode toggles ?

VaZso commented 3 years ago

Hmm... does TS80 have a similar delay in its bootloader what @Ralim wrote about TS80p? I suspect it has.

If the bootloader of TS80 takes 1-2 seconds to finish, then it may be the reason itself for an incompatibility with some chargers. As some of my power supplies fail to set the voltage if my Pinecil does send QC3 pulses after around 1.5 seconds (not including its own bootup time), the same thing will definitively happen if the boot time of TS80 is greater than this value.

My power supplies in question fall back to 5V if software sends these QC3 pulses after a certain period of time.

So if that is the case, IronOS can not really do anything to correct this behaviour with these chargers on QC3 mode. I think the same thing will apply for TS80p unless it has a different bootloader solution.

I think the cause of this delay is the USB DFU mode in bootloader which has certain timeout. A solution at this part would be a simple check of a pressed button of TS80 near the starting of loader and not starting DFU if it is not pressed, that way it would start earlier so IronOS may start working earlier as well.

I did not find if its bootloader is open or if there is an alternative bootloader for TS80, but doing an alternative one is not impossible on STM32F103, however, it can be a "sensitive part" in general. :)

Ralim commented 3 years ago

Hmm, off memory the TS80 has a faster bootloader but I think on later models they changed it so not sure if it changed.

Could be a requirement maybe to add QC 9 and 12V modes that disable the pulses to help with these?

None of the bootloaders are open source or available. There is a very minimal one over here with flash tool here though NOTE its only tested on ts100 so may not work. So only flash this if you have a backup first just in case. Also this bootloader only supporst USB-DFU protocol, no drag and drop.

VaZso commented 3 years ago

As of IronOS - when I was experimenting with Pinecil and disabled QC3 pulses, my chargers were left in 9V mode.

Looking into the code, there is a probe at the start for 9V, then it tries to handle the charger in QC3 mode where some of the chargers will fail if it does it too late for any reasons.

What is considerable if there should be an option for disabling QC3, that way it would remain at 9V but it should try higher voltages somewhere in QC2 mode which it currently does not try to do.

Not elaborating the above further, I have another idea as I like automatic solutions much better than an option which should be adjusted every time. :)

In SeekQC routine, it tries increasing voltage in QC3 mode. After osDelay(100), I may add a check if voltage has dropped, then move to QC2 mode and try to set higher voltages like 12V or 20V. I don't know what happen when the charger would put into unsupported mode like 12 or 20V mode, so if it would drop back or simply discards it - my problematic chargers seemed to discard 20V setting anyway as not supporting it.

Anyway, there is an ENABLE_QC2 defined in Pinecil but undefined in Miniware parts which part looks to be strange as it would try using QC2 solution unnecessarily to seek other voltages based on settings menu.

Maybe a check for the effect of QC3 pulses would be very welcome, then, if it had no effect or voltage dropped, it may try the voltage set in menu. ...then, if it did not take effect but it was initially set to 9V, it may try the next value based on settings (so QC_Seek20V, QC_Seek12V, QC_Seek9V) and if some of them took effect, it should keep that one.

I may try to experiment it on this or most likely next weekend if I have some time, but I think there is some room for QC improvement at that stage for better QC2 handling which may result in a higher voltage reached.

VaZso commented 3 years ago

I have tested the reaction of my power supply a bit using my Pinecil. I think @dmcinnes has a power supply which has a similar behaviour like what I have.

I have disabled PD timeout, so started in a situation where my power supply's output voltage goes to 9V then decreases to 5V.

I have found that also QC3 pulses and "QC_Seek12V()" or "QC_Seek20V()" pulses result in dropping the voltage back to 5V, except "QC_Seek9V".

So the best result achievable with that power supply when the PD timeout is high is 9V if QC3 pulses are disabled and the firmware does not try to set higher voltage than 9V.

This 9V is really low voltage for general soldering, however, it is still better than stuck on 5V.

So I think really better support for these QC chargers on TS80 needs an other bootloader which boots earlier than this kind of power supply times out, but an option which disables QC3 would add some minor usage for this kind of power supply.

If there is a way for the power supply to generate a reset condition, it would give some chance, but I haven't found it. Simply trying to start over QC handshake seems to has no further effect.

Edit: As I read above, the original voltage it could use was 9V, so that is definitively possible by adding an option which disables QC3 pulses and keep "QC Voltage" setting of that specific hardware set to a voltage not higher than 9V.

discip commented 2 years ago

@lysdexic1 Is this still a thing? Please close if not. 😊

thanks

dmcinnes commented 2 years ago

@discip at least for my case it turned out that my USB-C cable was loose. From what I gather, once the TS80 saw a drop in voltage it lost QC connection and never recovered. Once I squeezed the connector with some pliers for a more snug fit the problem went away. 😅 Maybe the cables that come with the "DN.OX QC" adaptor are prone to this?

discip commented 2 years ago

@Ralim Since @lysdexic1 does not respond and this issue seems to be solved, as reported by @dmcinnes, this issue can be closed. 😊

thanks