CFW for KSGER/Quicko STM32 Soldering Stations

[dark_hawk]

Calibration settings changed quite a bit from the older versions, you need to calibrate again, but calibration is not the point, You're testing for stability not accuracy, accuracy is easily done through new calibrations. Now test the 31-7 please.

[mastershake]

really my ONLY major issue at all was the issue i think you found with the tips not heating up enough. otherwise i really did not have an issue with the new or the old one besides that. honestly im not sure which i preff overall. i liked the settings i think best with the last few builds.

[Cuboy]

Cannot test 31-07 as it gives me errors on compilation, can someone please point me to it? Thanks.

[DavidAlfa]

  Why did I made a firmware list then?
Damn, do you see why i'm burning out?

[Cuboy]

Don't worry too much, I'll take a break, and then check what the hell is screwing up the regulation.
Meanwhile, test the available versions thoroughly, so I can know the code version causing the issues.

The problems started because I found a dead end. More filtering caused slow oscillation, less filtering caused more noise.
It was getting really hard to get any better. When some people were fine, others didn't. Always the same.
So again, I spent hours trying to figure out a better way, in the end it only added tons of new adjustments, leading to a much more complex tuning.
For a single line of code, maybe there have been 3 hours of testing to find out the best path.

What you should understand once for all is that these little spikes only happen at the sensor, mainly when the power is removed and it suddenly cools down to the real tip body temperature.
You shouldn't expect a perfect regulation, since there's a lot of power and usually a poor tip body-TC bond, so it'll always cause a very little oscillation when changing the setpoint. It's okay if it's just 1/2 second little spike and then gets stable.
This also happens with original fw, althought you don't see it, but if you see the pwm signal or hear carefully, it's a lot more caotic.
Mabe you buy JBC or any other professional brand and you think "it's just fine" because you set 350 and see 350.
Do you reallly thing that's the real thing? There are tiny differences all the time. I'll put both hands in fire if I'm wrong.
I'm seriously thinking in hiding the temp after the setpoint is reached, only showing it when it deviates more than 10-15ºC.
As they say, eyes that don't see, heart that doesn't feel.

What I can't do anymore is keep trying random settings and building everytime just to see if it gets any better.
It's not a matter of buying a ksger, because the same model works better for some people.
Being "lucky" I'll get a problematic model, but also it might work perfectly and do nothign with it.
Same with Quicko, I have 100% the same hardware as some users here, but they get a little oscillation while mine does perfect.
The owners of the "offended" stations need to do try the existing versions and find out the stable ones. Also try to tune the PID.
I know it's not easy, but it's much harder for me to tune a station that only exists in my mind.

2021-08-01 (Agressive PID?)
2021-08-01 (Reduce PID and filter values)
2021-08-2c  (Last build before switching to new PID)
2021-08-04a (Last build before adding new filter method)
2021-08-04b (New filter method)
2021-08-05
2021-08-06
2021-08-07
2021-08-10
2021-08-11

I dont see 31-07, am i crazy?

Will test 01-08

[dark_hawk]

If you're a KSGR v3.x:

[Cuboy]

If you're a KSGR v3.x:

Getting error:

c:\st\stm32cubeide_1.7.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_2.0.0.202105311346\tools\arm-none-eabi\bin\ld.exe: STM32SolderingStation.elf section `.text' will not fit in region `FLASH'
c:\st\stm32cubeide_1.7.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.win32_2.0.0.202105311346\tools\arm-none-eabi\bin\ld.exe: region `FLASH' overflowed by 27108 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [makefile:70: STM32SolderingStation.elf] Error 1

Yes, i'm using ksger 3.x thanks

[DavidAlfa]

For these things you could ask and I would help nicely.
It's not already written a zillion times or perfectly described in the documentation .

2021-07-31

To download any build, just check the git log.

You can see the dates and the commit messages.
You know these are "Updated builds"

[Cuboy]

For these things you could ask and I would help nicely.
It's not already written a zillion times or perfectly described in the documentation .

2021-07-31

To download any build, just check the git log.

You can see the dates and the commit messages.
You know these are "Updated builds"

This is 01-08 build

same cal values, testing 31-07

[Cuboy]

31-07.

[DavidAlfa]

Aaaand...

About the date: It was compiled 31-07.
But as it was already late, close to 00h, I decided to put tomorrow's date
Just keep scrolling in the git log.

[Cuboy]

Aaaand...

About the date: It was compiled 31-07.
But as it was already late, close to 00h, I decided to put tomorrow's date
Just keep scrolling in the git log.

Do you need more?

07-07

Here looks like it gets worse.


Tomorrow i'll try to play with the encoder, if you need more photos please ask.

[DavidAlfa]

Of course I need more.
That's just the temperature sitting there
You're only looking for 4°C stability, while forgetting the real thing.
But about power response, overshooting, reaction time... Maybe the "pretty" build puts 1/2 the power on a 10°C drop vs the "noisy".
And only one feedback. You should understand the situation, you're barely helping. All the people who complained should be testing. What if it's ok in your station but then fails on the rest?
That's what i'm tired of. Nope, not doing more "maybe" builds.
What about the rest? Should be stay with that just because looks nice? There might be better, there have been daily builds. What about builds 1st, 2nd, 3rd, 4th... aug?

[Cuboy]

Of course I need more.
That's just the temperature sitting there
You're only looking for 4°C stability, while forgetting the real thing.
But about power response, overshooting, reaction time... Maybe the "pretty" build puts 1/2 the power on a 10°C drop vs the "noisy".
And only one feedback. You should understand the situation, you're barely helping. All the people who complained should be testing. What if it's ok in your station but then fails on the rest?
That's what i'm tired of. Nope, not doing more "maybe" builds.

No worries, some people might test tomorrow or another day, just gather info for now. Don't make changes until more feedback is gathered.

For me, that's it for today, tomorrow as I said I will play with the encoder (fast-slow rotation) when I have some free time and test more builds.

Thank you for your patience, and have a good day-night everyone.

[DavidAlfa]

Sure! You're doing a nice job  .

[StephenR0]

I agree.  I encourage your work and will support whatever you need.   

[Tugo]

I intend to test this (maybe later today):
1.) Time to get from "zero" to 350 C (with FG-100 clone and not what soldering iron is showing - well maybe even how long will soldering iron take from "zero" to 350 C).
2.) Overshoot on the graph (if also on the tip, but at the end of the tip I never got any overshooting).
3.) I don't know how to check for power response (David, please advise).
4.) Reaction time... the same as for number 3, how? Both of them are pretty much subjective opinions unless done by camera and oscilloscope. Maybe I am wrong 

I will use the same period/delay/PID settings on all FW versions and I will do my period and delay (100/1) and also default ones (200/20).
So there are 11 FW versions to test.
David, do you think it could be less or do you really need all of them? Just asking!

[DavidAlfa]

By carefully touching the wet sponge, not suddenly dropping 50°C.
So if the setpoint is 360, do it in a way so it cools down to 358...355...353... You want to simulate a heavy load, like soldering a ground plane.
And maintaining it there for few seconds.

I can't/don't really know, my Quicko has always been ok.
It's the people here getting the nasty readings on their ksgers, and not everyone's Ksger...

[Andrew LB]

Well my ancient Hakko 936ESD (not a clone) that i've had for nearly 20 years has retired itself and it looks like ill be picking up one of these KSGR T12 soldering stations. Its good to see a few are still doing firmware work on these and DavidAlfa, thank you for all your hard work. Ill let you know how everything goes once i get the unit.

people seems to translate open source as "it's free, and there's someone doing for me everything I ask".

Ain't that the truth.

It reminds me of how things go when people find out you know how to weld, or work on cars, or fix computers, etc. *sigh*. which reminds me, im changing a friends alternator and belts tomorrow. 

[AndyC]

I've been "away from lab" so I've missed many builds. (Been running v1.1 on my daily driver). Going back and testing 210602 and 210707 I see horrible oscillations on my KSGER 2.1. Recently I have tested every build from 210804b -> 210811 on KSGER 2.1 (blue pcb) and KSGER 3.1 (black pcb). On the KSGER 2.1 things start to change on the 210807 build and onwards. Oscillations like in previous posts by others. However, I am able to tune the PID to get rid of the oscillations on all recent builds. Maybe the filtering tricks the PID?. I haven't  read up on the filtering, but will try, and also do some more testing.
On the KSGER 3.1 I have run the 210804b for a while, it works very well.
For some reason the new debug screen sometimes freezes the GUI when selected. This happens after tips have been edited.

[DavidAlfa]

Well my ancient Hakko 936ESD (not a clone) that i've had for nearly 20 years has retired itself and it looks like ill be picking up one of these KSGR T12 soldering stations. Its good to see a few are still doing firmware work on these and DavidAlfa, thank you for all your hard work. Ill let you know how everything goes once i get the unit.

people seems to translate open source as "it's free, and there's someone doing for me everything I ask".

Ain't that the truth.

It reminds me of how things go when people find out you know how to weld, or work on cars, or fix computers, etc. *sigh*. which reminds me, im changing a friends alternator and belts tomorrow. 

Really? I'm also mechanic, electrician, computer technician, even farmer

[Cuboy]

The only usability feature I'd like to see is when turning the encoder fast, I want it to make bigger steps for numerical values. Ie: if I turn the encoder at less than 5 clicks/sec then it increases by 1. If it's faster than that, then it increases by 10. IMO, it would help a lot when manually entering calibration values.

Added the fast-slow rotation feature, it was just some lines of code and some hours of understanding the code, as it's the same as the click and rotate feature, the only change is that we need a time differential and a number of rotations so it makes a big step.

You can modify the code, constant TIME_DIFF is used for sensitivity (the lower the ms, the faster you will need to rotate the encoder to make a big step).
constant NUM_ROT is for the number of rotations you need to make in the time differential (set as 45ms) to make a big step.

For me now it's on the sweet spot where you don't need to rotate very fast to make a big step.

I'll wait for David to review and merge.

Once is added, I'll wait for feedback. Both fast-slow encoder rotation and click-rotate are functional for big step increments of temperature (not yet for the settings menu). We can have both or just one, the community decides.

Thanks for your suggestion 

Edit: changed time diff value to 57.

Edit2: changed again to 80

[ygi]

The only usability feature I'd like to see is when turning the encoder fast, I want it to make bigger steps for numerical values. Ie: if I turn the encoder at less than 5 clicks/sec then it increases by 1. If it's faster than that, then it increases by 10. IMO, it would help a lot when manually entering calibration values.

Added the fast-slow rotation feature, it was just some lines of code and some hours of understanding the code, as it's the same as the click and rotate feature, the only change is that we need a time differential and a number of rotations so it makes a big step.

You can modify the code, constant TIME_DIFF is used for sensitivity (the lower the ms, the faster you will need to rotate the encoder to make a big step).
constant NUM_ROT is for the number of rotations you need to make in the time differential (set as 45ms) to make a big step.

For me now it's on the sweet spot where you don't need to rotate very fast to make a big step.

I'll wait for David to review and merge.

Once is added, I'll wait for feedback. Both fast-slow encoder rotation and click-rotate are functional for big step increments of temperature (not yet for the settings menu). We can have both or just one, the community decides.

Thanks for your suggestion 

Edit: changed time diff value to 57.

Edit2: changed again to 80

Thanks for your work. 
IMO it's more natural/intuitive that way instead of click+rotate but I honestly can live with both as long as the feature exists. As for testing, I don't have much time to flash and play around this week so I'm still happily running a build from early August with the "new" deleted PID (and I'm not looking forward to recalibrate yet again).

[Tugo]

I did some testing...
I was testing and comparing just 4 FWs:
31.7. -> 2021-07-31
1.8. (I named it 1.8.a) -> 2021-08-01a
4.8.a -> 2021-08-04a
4.8.b -> 2021-08-04b

Since the one from 31st of July had PID set to 110-80-20 and was working fine I used the same PID settings on all of the tested FW.
I tested speed of getting to 350 C (from "zero"), checking the time when giving me a beep (when station got to the set temperature) and when it reached 350 C measured with clone FG 100 and if there is any overshoot. Timings were tested at 200/20/1x and at 100/1/1x and I also tested both timings if they work at PWM multi of any higher than just 1x.
Checking for overshooting happened just on the graph (not at the end of the tip). Since that doesn't matter it is useless for my test but could be the issue if using a better quality tip so I will give the results with that too.

Between the best and the worst is not really that much difference. Any of the FW that I tested worked just fine (even the worst one!).
The worst of them was FW from 1.8.a. because on 200/20/1x was the slowest. On other FWs it needed 10 seconds to beep (receiving beep when soldering station got to 350 C) and 20 seconds to get 350 C at the end of the tip (on all of them except on FW 1.8.a it needed 12s/24s when using 200/20/1x timings).
The best was FW 4.8.a because it needed a little bit less time (9/19) at timings 100/1.
Overshoot at 100/1/1x was always below 5C, at 200/20/1x was below 7C. On FW 4.8.a was pretty much spot on at timing 200/20/1x!!!
FW 4.8.b was very close to 4.8.a with overshooting about 3C on the station.
I would say new PID is better than OLD but I should be doing some specific test to see how they perform when compared them. If I look just at first 2 FWs (old PIDs) and compare them to the other 2 (new PIDs) I can say that FWs from 4.8. are better so new PIDs are better on mine soldering station.

I almost forgot to tell that 200/20 is capable of doing PWM 2x multi while I cannot do it on 100/1 (it is oscillating). On PWM 1x it is always more stable (almost flat line) on 100/1 while this is true with 200/20 just on FW 4.8.a.

I couldn't do wet sponge because I didn't have time to think how to do the test. I tested with ear picks and watter but I watter evaporated very fast and didn't know how to test it on different FWs to be able to repeat the same condition.

I didn't get any spikes on the tested version (I also checked FW from 11th and 7th and I believe 2nd of August but not in this test). What worked stable on older versions did work on the newer. At least I didn't have any problems on any FW after 6th of July when I told you you fixed a problem that I have with jumping temperatures (not oscillating!).

David, do you need anything specific I could test?

[DavidAlfa]

Nice testing
Huh, why do I remember everyone complaining with the 110 pid settings?