Ts101

[Ralim]

Tracking Adding support for TS101.
Using info from #1420

Todo:

• Tip control
• Power Muxing
• ADC config
• Tip res measurement
• Bitbang I2C for two buses
• Basic (cropped) OLED
• Accelerometer handling
• PD is broken (somewhere)
• Enable EPR

Out of scope:

• Handling of larger res screen fully

[Ralim]

Going to have to figure out why USB-PD isnt working another day, out of time for today.

[VioletEternity]

I can confirm much of the functionality works. Here are two USB PD captures of me plugging the iron into a 65 W UGREEN power supply and into a power bank:

ts101_pd_fault.zip

These are Sigrok format files, decodable with PulseView 0.5, and have been captured by a ChromiumOS Twinkie type device.

EDIT: The previous set of captures I posted was corrupted on my end due to instrument issues, I've reuploaded different ones.

[Ralim]

Thanks for the captures.
Confirms exactly what I'm seein here too locally, where the PD IC initalises and then sends a good CRC. But the code never reacts to the message that came in. I need to break mine open and capture the I2C bus during a negotiation I think at this point; which will require more time :/

Have done a bunch of ideas but nothing seems to change it so far.

[VioletEternity]

I built the latest version and gave it a quick test. It appears usable for soldering with a PD power source I have, however there are a few issues:

• The "1" display brightness results in nothing displayed at all.
• The accelerometer threshold is set much too high. Even at the "9" sensitivity I have to pick the iron up and shake it so that it wakes up.
• There is an annoying high-pitched sound emitted by the iron when it is e.g. on standby at 320 degC, at 1755 Hz. It is likely caused by the large MLCC being pulsed, which causes it to act like a piezoelectric buzzer. Do you get that? Do you think anything could be done about it at all?
• The display being cropped is not a significant issue, however the "overscan" area not being cleared after updates is. That seems like a relatively minimal fix that would not require a complete UI overhaul that is out of scope for this PR.

[Ralim]

I built the latest version and gave it a quick test. It appears usable for soldering with a PD power source I have, however there are a few issues:

Thanks for the test

* The "1" display brightness results in nothing displayed at all.

That is going to vary display-to-display, different OLED's start at different thresholds

* The accelerometer threshold is set much too high. Even at the "9" sensitivity I have to pick the iron up and shake it so that it wakes up.

I'll try and look into this.

* There is an annoying high-pitched sound emitted by the iron when it is e.g. on standby at 320 degC, at 1755 Hz. It is likely caused by the large MLCC being pulsed, which causes it to act like a piezoelectric buzzer. Do you get that? Do you think anything could be done about it at all?

Hmm, yep I can probably shift this around, I dont hear it here on my unit (checked with spectrogram app on phone).

* The display being cropped is not a significant issue, however the "overscan" area not being cleared after updates _is_. That seems like a relatively minimal fix that would not require a complete UI overhaul that is out of scope for this PR.

This is still entirely out of scope, as to clear the GRAM we need support for the larger buffers etc. And I would rather ship something than hold this for weeks/months until I have time to deal with OLED stuff.

[L1cardo]

I flashed the latest firmware, and DID hear the high-pitched sound when it reached the target temp. Except for the cropped display and the sound, nothing wrong happened on my side.

[sandmanRO]

Hello @L1cardo / hello @VioletEternity, regarding the noise, if I may suggest, could you please check using a phone/mobile app the actual frequency of the sound? It's kind of strange the sound occurs near temperature setpoint, when the power consumption is actually the smallest during heat session. In short, the power train (actual pulse that controls the power FET) is a 10kHz (or 5kHz?) signal, 50% duty cycle. Let's say it's 10kHz. This 10kHz square signal is gated / modulated by a gate pulse with variable duty-cycle (the width of the gate pulse is under the dynamic control of IronOS and this is the way the average output power is controlled). The frequency of this gate pulse is about 100Hz if I recall correctly. At setpoint, the width of the gate pulse has the smallest value (duty-cycle of only few percent) while at full power, the power gate duty-cycle goes up, near to "100%" (more like 95%). However, it never reaches 100% as we need a small window of time (few ms), when no power is injected into the tip, and during this window, the temperature (and other) measurements are performed.

Now, if the sound frequency is around 10kHz is one thing / if it's a clean 100Hz frequency is another thing / if it's a 10kHz sound modulated by a 100Hz envelope (probably a microphone + oscilloscope would be required to conclude this) would be yet, another thing. I am tempted to suspect that the last case is true. Most likely the sound is always there (10kHz) during heat session, but the human ear starts perceiving it only when the sound is significantly modulated. This would explain why it seems to appear near setpoint.

It also would be good to know if on TS101, Miniware preserved (or not) the AC coupling between the command signal and the gate pin of the power FET (as used with TS100). In the "Addendum: Outline of functional blocks" (see @VioletEternity post #1420 (comment)) I could not notice any capacitors in the gate / power area. It could be that they are placed elsewhere on the PCB or maybe on TS101 they went with a simple, direct DC coupling, in which case that 10kHz power train is no longer needed and the power could be controlled directly by the current gate / modulation pulse, in which case the high pitch sound would probably go away.

The alternative (and this would be easy to test) would be to increase the frequency of the power train from 10kHz to 20kHz (by lowering the timer 3 period), in which case most of the people (old guys like me for sure) would not hear a damn thing :-). I could not test it on TS101 as I don't have one, but on TS100 the 20kHz power train seems to work just fine.

[L1cardo]

[sandmanRO]

As for the suggested test change, this should be done in IronOS/source/Core/BSP/Miniware/Setup.cpp at line 270:
htim3.Init.Period = 100;
should be replaced with something like:
htim3.Init.Period = 50 - 1;
or even
htim3.Init.Period = 25 - 1;
I believe the prescaler should be set 8 - 1 as well (line 268). I might be wrong, but somehow, I recall that there was an explanation in STM32 documentation why 1 should be subtracted from the prescaler and period values, something related to the fact that indexing is zero based or something like that.

[sandmanRO]

Hello @L1cardo, you dropped that picture without a word. I initially thought it's timebased / oscilloscope like frame. Now, I'm thinking that most likely what you dropped is in fact a histogram (FFT). Is that what you posted?

[sandmanRO]

That's ok @L1cardo. It looks like a FFT histogram to me (on X axis we have the frequency and on Y axis the amplitude of the harmonic at a specific frequency). The issue is FFT analysis on "piezo" soundwaves generated by square electrical signals is tricky. As a square signal is basically a superposition of an infinity of harmonics of various amplitudes, you don't get clean results, and most often multiple harmonics out of which you don't know which one matches the excitation frequency. For such cases, it is preferable to just analyze the recorded sound (as a plain time-based sequence) and get the main frequency / see the signal modulation (if any) from there.

[sandmanRO]

Nevertheless @L1cardo, you could try the suggested changes in the firmware. If you still hear the high-pitch sound afterwards, it means you either have an exceptionally good sense of hearing or the sound could actually come from elsewhere (like the PD power supply used to power the iron). In that case, switching to a plain DC power supply (powering the TS101 via its DC barrel) would make any difference?

[Ralim]

@sandmanRO

The TS101 is direct tip drive, so there is no ac coupling capacitor anymore. Instead the 50% duty cycle is replaced by the pwm value instead. https://github.com/Ralim/IronOS/pull/1695/files#diff-1eddd86b1c0ecb235a3774a6edd96ebaf75b1d1ab570bdd58629aa93a092c387R138

Other Irons have not been audible at this frequency, but we can definitely shift it down. Going higher seems to run into issues with something not fully switching in very quick tests I did.

If someone wants to do testing, I would suggest adjusting the prescaler here: https://github.com/Ralim/IronOS/pull/1695/files#diff-089752d1b62731302cc1ebf92ed076fbeea024af8f5a8818c5b61de467c88f5aR310

[sandmanRO]

Hello @Ralim, that's good as it simplifies a bit the timers stuff. At a first glance, in the new, TS101 dedicated code (thank you for the links!) the htimTip timer, at a prescaler of 2690 (in fast PWM) would lead to a timer tick rate of about 2.97kHz (8MHz / (2690 + 1)). Then considering the constant period set for 255, this would lead to a htimTip cycle frequency of about 11Hz. There is no way this would lead to the reported high pitch noise (7-15kHz), disregarding the pulse width / duty-cycle, dynamically set at runtime.

[Ralim]

Realised I forgot to update the prescaler when I increased the period; can you try latest build artefacts 🙇🏼

[Ralim]

@sandmanRO
Glad links helped, its a total mess; dont expect anyone to want to read it all 🤣

For the TS101 I suspect its mostly happening as we scale back duty cycle on the tip control PWM, as the PWM gets shorter the harmonics will get worse too.

(as well as I forgot to update the prescaler when I bumped the max from 100 to 255 which I just pushed).
Ill try and test tomorrow if I can hear it and where its coming from on my unit.

[sandmanRO]

Oh man, there are so many changes since last time I was looking over the code. Brand new code all over the place. I'm petrified that you managed to write so much code in such a short time. I feel like I should apologize for the change suggestions I made, as they no longer have anything to do with the new code.

[L1cardo]

And one more thing, after I flashed IronOS, I can notice that the heating up speed is significantly slower than the stock firmware.

[Ralim]

Can I have some more details on what build this was, and what power supply was being used ?

[Hoholok21]

Hello! When compiling the firmware, such an error occurs, I have already tried a lot of things, could you help?

[L1cardo]

@Ralim I am using this commit 6a50743, and with a 65w pd power supply. On screen, iron shows 16-17, I guess that is voltage.

[L1cardo]

Seems like the voltage and the current are the same which means power is the same on the spect, but I can feel a significant slow heat up on IronOS.

[sandmanRO]

@L1cardo, if the current is the same in full power, there is little reason the tip would heat up slower. This is a physical fact. What it could be different is the way the PID drives the average power near the temperature setpoint. For that, to exclude the subjective sense of timing, why don't you do this: have the setpoint set at 300 Celsius. Then using a chronometer / stopwatch you measure how long it would take to heat up the tip from the room temperature to 270 degrees and 300 (setpoint) degrees respectively. You would have to repeat the experiment on both cases, when running IronOS and when running Miniware firmware.

[L1cardo]

Miniware firmware: 15.0s->270­°C，17.4s->300­°C
IronOS：18.0s->270­°C，22.0s->300­°C

[sandmanRO]

Ok, we are getting somewhere. Have you noticed at what temperature the IronOS starts to drop from full power to less than full power?

[sandmanRO]

I mean, from the data you have collected, from room to 270 the IronOS "falls behind" by about 3 seconds, then, on the last 30 degrees, the delay almost doubles, so this backs up that this is related to the way the PID drives the temperature to setpoint. You can lead the temperature aggressively, and most likely risk to overshot, or drive the temperature in a clean, asymptotic ramp to setpoint. It's a matter of choice.
By the way, you really have a good sense of timing if that, 3-5 seconds, delay feels significantly :-) Since I am not a native English speaker, I should probably stress that I'm saying this in a good way, just in case...

[Ralim]

Hello! When compiling the firmware, such an error occurs, I have already tried a lot of things, could you help?

This is because you did not git clone the repository down, it appears likely you have used the zip download feature of Github instead. This repository requires a git clone --recursive https://github.com/Ralim/IronOS.git

[Ralim]

@L1cardo

Yep that looks exactly like conservative tuning vs aggressive tuning.
At the moment on most of the Hakko tipped devices the tune is somewhat conservative because when its aggressive and then overshoots people raise tickets, email, tag and message me. (Keep in mine IronOS does not do filtering like Miniware to hide these).

I think honestly all Irons need abit of a "tune up" to to speak after I cleaned up tuning to handle S60's tiny ass tip.
So I wont block this merging for this.

Buttt hold me to improving the tune before release 👀

[L1cardo]

How about providing an option to switch between conservative tuning and aggressive tuning?
BTW, what is S60? A new iron?

[Ralim]

How about providing an option to switch between conservative tuning and aggressive tuning?

Certainly an option, best if you open a new issue to track it so it doesnt get lost 😓

BTW, what is S60? A new iron?

Yep it was merged in a little before TS101

[Jonny-T-cyber]

I follow the discussion