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
If you're a KSGR v3.x:
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"
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.
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.
people seems to translate open source as "it's free, and there's someone doing for me everything I ask".
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.
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.
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