EEVblog Electronics Community Forum
Products => Other Equipment & Products => Topic started by: ricktendo on March 14, 2018, 05:16:31 am
-
GitHub: https://github.com/deividAlfa/stm32_soldering_iron_controller (https://github.com/deividAlfa/stm32_soldering_iron_controller)
https://www.youtube.com/watch?v=j0HQq4aRiXw (https://www.youtube.com/watch?v=j0HQq4aRiXw)
https://www.youtube.com/watch?v=x9ohNL2J2lU (https://www.youtube.com/watch?v=x9ohNL2J2lU)
-
Update: I requested a CFW Flashing video, he delivered
https://www.youtube.com/watch?v=dzN0QhjiP0Y (https://www.youtube.com/watch?v=dzN0QhjiP0Y)
-
Hi Ricardo,
We can move the discussion regarding building from source here.
As I pointed on youtube the first step is to download System Workbench from http://www.openstm32.org/System%2BWorkbench%2Bfor%2BSTM32 (http://www.openstm32.org/System%2BWorkbench%2Bfor%2BSTM32). It is free but requires an account.
-
Thank you for the instructions, I can build debug but when I try to try to build release I get these 3 errors
12:29:51 **** Build of configuration Release for project iron ****
make all
Building file: ../startup/startup_stm32f103xb.s
Invoking: MCU GCC Assembler
C:\Users\Ricardo\workspace\stm32_soldering_iron_controller-master.zip_expanded\stm32_soldering_iron_controller-master\Release
arm-none-eabi-as -mcpu=cortex-m3 -mthumb -mfloat-abi=soft -o "startup/startup_stm32f103xb.o" "../startup/startup_stm32f103xb.s"
Finished building: ../startup/startup_stm32f103xb.s
Building file: ../Src/iron.c
Invoking: MCU GCC Compiler
C:\Users\Ricardo\workspace\stm32_soldering_iron_controller-master.zip_expanded\stm32_soldering_iron_controller-master\Release
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -mfloat-abi=soft '-D__weak=__attribute__((weak))' '-D__packed="__attribute__((__packed__))"' -DUSE_HAL_DRIVER -DSTM32F103xB -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Inc" -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Drivers/STM32F1xx_HAL_Driver/Inc" -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Drivers/STM32F1xx_HAL_Driver/Inc/Legacy" -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Drivers/CMSIS/Device/ST/STM32F1xx/Include" -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Drivers/CMSIS/Include" -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Drivers/graphics" -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Drivers/graphics" -I"C:/Users/Ricardo/workspace/stm32_soldering_iron_controller-master.zip_expanded/stm32_soldering_iron_controller-master/Drivers/graphics/gui" -Og -g3 -Wall -fmessage-length=0 -ffunction-sections -c -fmessage-length=0 -MMD -MP -MF"Src/iron.d" -MT"Src/iron.o" -o "Src/iron.o" "../Src/iron.c"
../Src/iron.c:11:25: fatal error: tempsensors.h: No such file or directory
#include "tempsensors.h"
^
compilation terminated.
Src/subdir.mk:36: recipe for target 'Src/iron.o' failed
make: *** [Src/iron.o] Error 1
12:29:56 Build Finished (took 5s.46ms)
Also when I build, how do I make sure its for hakko tips and not jbc?
-
Can you tell me what that bottom right temp is and what it's purpose is?
Thanks
Dave
-
Thank you for the instructions, I can build debug but when I try to try to build release I get these 3 errors
You can use the debug build, that is what I use, it is a bit larger but it behaves the same. If you do want to use the release build I have just pushed a fix for that issue, you can clone the repository and it should build without issues.
Also when I build, how do I make sure its for hakko tips and not jbc?
Just use #define JBC somewhere on the start of settings.c to build for JBC and remove that define to build for hakko.
-
Can you tell me what that bottom right temp is and what it's purpose is?
Thanks
Dave
It is supposed to be the ambient temperature in degrees Celsius, it is used for the cold junction compensation. Since I didn't see too much of a variation between sensors the calibration is hard coded, I can make it configurable if found necessary.
-
Thanks much, that's over my head.
Dave
-
You can use the debug build, that is what I use, it is a bit larger but it behaves the same. If you do want to use the release build I have just pushed a fix for that issue, you can clone the repository and it should build without issues.
You are correct, the ELF is different between the builds but the resulting BIN file is the exact same.
I did get these 3 warnings, hope they are not serious
Description Resource Path Location Type
suggest parentheses around arithmetic in operand of '|' [-Wparentheses] ugui.c /iron/Drivers/graphics line 5326 C/C++ Problem
suggest parentheses around arithmetic in operand of '|' [-Wparentheses] ugui.c /iron/Drivers/graphics line 5328 C/C++ Problem
suggest parentheses around arithmetic in operand of '|' [-Wparentheses] ugui.c /iron/Drivers/graphics line 5375 C/C++ Problem
suggest parentheses around arithmetic in operand of '|' [-Wparentheses] ugui.c /iron/Drivers/graphics line 5377 C/C++ Problem
unused variable 'tmp' [-Wunused-variable] ugui.c /iron/Drivers/graphics line 5810 C/C++ Problem
unused variable 'xs' [-Wunused-variable] ugui.c /iron/Drivers/graphics line 5808 C/C++ Problem
Thanks for everything
-
I did get these 3 warnings, hope they are not serious
Those are from the uGui library I'm using, I have checked and they are harmless.
-
Thanks much, that's over my head.
Dave
The cold junction compensation bit? That is not hard to understand at all.
The "temperature sensors" used on these soldering iron tips are thermocouples. A thermocouple reads a difference in temperatures not the absolute temperature, so in a iron tip it measures the difference between the tip temperature and the ambient temperature (not so simple but close enough). So in order for you to know the real iron tip temperature you need the thermocouple measure and another sensor reading which can provide the ambient temperature. Than you just compute the tip temperature real temperature.
Now you can ask what is the real value of having the ambient temperature being displayed, and you are right it isn't critical, I see it more like a sanity check, if it is on the ballpark of the ambient temperature it means the cold junction temperature sensing is at least reading something close to reality.
-
So should that thermistor in the handle actually be in the base away from the handle where the heat of holding it will change the value? Or should that be assumed to be the same temp each time you hold it since the human hand doesn't change in temp that much?
Thanks
Dave
-
So should that thermistor in the handle actually be in the base away from the handle where the heat of holding it will change the value? Or should that be assumed to be the same temp each time you hold it since the human hand doesn't change in temp that much?
Thanks
Dave
Ideally it should be as close to the termistor as possible, or to be more accurate to the cold junction, that is where the two dissimilar metals become copper. In reality is doesn't really matter much.
-
But if it is using the thermistor in part of the calibration and the thermistor is in the handle where the ambient temp it is measuring changes just by the action of holding it, doesn't that skew the calibration?
Dave
-
But if it is using the thermistor in part of the calibration and the thermistor is in the handle where the ambient temp it is measuring changes just by the action of holding it, doesn't that skew the calibration?
Dave
Calibration has nothing to do with this, so no it doesn't skew calibration.
Increasing the handle temperature by holding it is why the thermistor should be placed there, so it can measure that increase.
As I said above a thermocouple "reads" the difference in temperature between its hot and cold junctions, and the cold junction is on the handle so that is the temperature that you should read to make the proper compensation.
-
ok that makes sense now.
Thanks much
Dave
-
Hi PT_Dreamer,
thank you for sharing your firmware.
I've got a controller , flashed the firmware for JBC. Everything went fine except two minor issues:
1) The display content seems to be shifted a few columns to the left
2) Even with no iron connected the display shows about 167 degree and not an error....
Is there an explanation?
Thanky you very much....
-
Hi PT_Dreamer,
thank you for sharing your firmware.
I've got a controller , flashed the firmware for JBC. Everything went fine except two minor issues:
1) The display content seems to be shifted a few columns to the left
2) Even with no iron connected the display shows about 167 degree and not an error....
Is there an explanation?
Thanky you very much....
What size is your LCD?
You may also want to post your bug on the github issues page: https://github.com/PTDreamer/stm32_soldering_iron_controller/issues
-
It is this controller and looks like te same PT_Dreamer used (except the two colour display in his video) :
https://www.aliexpress.com/item/STM32-OLED-V3-5-OLED-T12-Soldering-Station-Temperature-Control-Board-1-3-Size-Screen-OLED/32822843496.html (https://www.aliexpress.com/item/STM32-OLED-V3-5-OLED-T12-Soldering-Station-Temperature-Control-Board-1-3-Size-Screen-OLED/32822843496.html)
has a 1.3 inch display....
-
It is this controller and looks like te same PT_Dreamer used (except the two colour display in his video) :
https://www.aliexpress.com/item/STM32-OLED-V3-5-OLED-T12-Soldering-Station-Temperature-Control-Board-1-3-Size-Screen-OLED/32822843496.html (https://www.aliexpress.com/item/STM32-OLED-V3-5-OLED-T12-Soldering-Station-Temperature-Control-Board-1-3-Size-Screen-OLED/32822843496.html)
has a 1.3 inch display....
Yea its the exact same board revision V1.5, only difference is the LCD size: 1.3'' vs 0.96''
-
Hi PT_Dreamer,
thank you for sharing your firmware.
I've got a controller , flashed the firmware for JBC. Everything went fine except two minor issues:
1) The display content seems to be shifted a few columns to the left
2) Even with no iron connected the display shows about 167 degree and not an error....
Is there an explanation?
Thanky you very much....
Hi sorry for the late reply, I'll have to look at the forum settings because it seems I'm not receiving new post alerts.
1- As already referred above your screen is different than the one I got. It is bigger and doesn't have the upper yellow line. If you want I can try to write some changes to fix the issue you are having. Unfortunately since I don't have a similar screen to play with it will probably require a few iterations before we get it.
2- Not having the iron connected means that noise is being fed to the input of the double stage amplifier which is then fed to the ADC. On the board I have this condition will made it appear as if a temperature above specs is present and trigger a "NO IRON" message. If your hardware is working properly it seems to be reading noise with an average level similar to a termoucouple inside the temperature spec of a normally running iron and as such impossible to detect as a non connected iron. I can think of a few ways to improve the behavior but all hacky and prone to fail on edge cases. Open to ideas though.
-
@giovannirat
You can try the attached firmware to see if it fixes the screen issue. It is compiled for JBC, no idea if it is what you need but should be ok just for testing the screen.
EDIT: Please let me think about it some more and I'll post a better firmware tomorrow night.
-
Hi PT_Dreamer,
thank you very much for your support....
I will try the attached firmware and give you feedback soon.
-
Hi PT_Dreamer,
one step forward... :D
The left side of the screen looks ok now, but on the right side is still a two column "interference"....
And the temperature looks a bit high without any iron (jumps between 100° an 960°), but that's obvoiusly the noisy input... ::)
Thanks a lot!
-
@giovannirat please try this new firmware, I tried fixing the screen issue in another way, after reading some docs it seems your screen uses a 132x64 controller while only having the normal 128 point horizontal resolution...which is weird....
I also tried lowering the "NO IRON" detection threshold.
@moderators if this kind of discussion/testing is outside the scope of this forum please let me know and I will move it to gitHub.
-
Hi PT_Dreamer,
now looks good! :-+ :clap: :clap:
It is still not showing the "NO IRON" message, but probably I have a board with a HW fault...
I found another minor issue: In the BOOST menue the values cannot be saved (SAVE button not accessible)
Thank you for your really fast support.
I'm still waiting for the ordered Hirose RPC1 connectors, then I will do further tests with my JBC handle...
-
This should fix the saving not possible on the boost menu, let me know if it doesn't.
Thank you for your really fast support.
No problem :)
-
Any chance on making the temperature font larger, there is allot of real estate being wasted
-
Any chance on making the temperature font larger, there is allot of real estate being wasted
Sure, if you guys test it. My two controllers are in use and encased, testing this now is a pain.
-
Any chance on making the temperature font larger, there is allot of real estate being wasted
Here you go, it is probably not centered though
-
Boost menue issue now solved. :-+
Temperature font now larger, but the last digit nearly not visible and not centered...
Thanks a lot!
-
Boost menue issue now solved. :-+
Temperature font now larger, but the last digit nearly not visible and not centered...
Thanks a lot!
How about this?
-
Any chance on making the temperature font larger, there is allot of real estate being wasted
Sure, if you guys test it. My two controllers are in use and encased, testing this now is a pain.
I am still waiting for mine to arrive, its with a friend in the U.S. waiting for him to ship it to Central America.
-
Boost menue issue now solved. :-+
Temperature font now larger, but the last digit nearly not visible and not centered...
Thanks a lot!
How about this?
Better, but still a part of the last digit missing.... ;)
-
Hi,
Here is one more for you to try, I also sent you a PM asking for your email so we can continue this testing that way since I don't think me posting firmware and getting your feedback is of interest to anyone else.
-
Hi PT_Dreamer,
do you have any feedback from giovannirat, where you were trying to fix OLED display content shifted to one side? I would like to build that project using the same controller with the same OLED display. I dont do programing so I need to stick to firmware which was already compiled for JBC. Thanks.
-
Hi,
Yes, we continued the conversation via PM. Everything is ok now.
New firmware versions are available on gitHub (link on my blog), there are versions for JBC and Hakko for both the small and the big screens.
-
Just out of curiosity, would this firmware be compatible with other stm32 controller board revisions?
-
Thank you for replaying. I found link to gitHub ,there is a file "iron_jbc.elf" I would be interested in. So this firmware (that particular file) can handle both the small and the big screens?
-
Thank you for replaying. I found link to gitHub ,there is a file "iron_jbc.elf" I would be interested in. So this firmware (that particular file) can handle both the small and the big screens?
No, please look at the last blog post, there is a total of 4 zip file, hakko, jbc, hakko +big screen, jbc+big screen
-
Just out of curiosity, would this firmware be compatible with other stm32 controller board revisions?
Hi, I'm sure you can answer that question right?
-
Yes, I found it ! Thanks a lot.
-
Just out of curiosity, would this firmware be compatible with other stm32 controller board revisions?
Hi, I'm sure you can answer that question right?
I suspect the answer is NO, I just want to confirm this.
-
Hello!
Thank you for sharing this CFW!
I have purchased a KSGER T12 OLED Station, but it has a STM32F102C8 instead of the F103.
Can your firmware run on F102C8 or I must replace the CPU?
Best regards,
Demian
-
ok guys,
I just tried both version of your firmware, for JBC and for Hakko. They seem to be the same regarding display symbols.
Even pre-defined tips are the same in both version. Is that ok?
OK, programming was my fault...
But I would like to ask to explain the display layout. So far I was using old school soldering irons, so this is pretty new for me. It may be helpful also for someone else. SoI have following questions:
Left upper corner symbols can be following: SET, STB, BOO "Set" is supposted to be temperature settings. That is clear.
What "STB" stand for? Is it Standby/Sleep setting? "BOO" symbol I guess is Boost mode. What for is boost feature? How do I use it?
Right upper corner - "%" symbol. What is the purpose of this symbol?
Left bottom corner - There are D24, BC2, DFLT, B symbols -- I guess they are preset settings for tips. D24, BC2 - are they ksger/Hakko T12-BC2 and T12-D24 tips? Why D24 and BC2 need to have extra settings? "B" symbol - not sure. With Hakko firmware I would like to use T12-JS02. Shall I use DFLT settings?
DFLT symbol- I guess it means "default". What tips are covered by DFLT settins?
Regards, Roman
-
You guys might have better luck with support if you use the github site for bug reports and feature requests
https://github.com/PTDreamer/stm32_soldering_iron_controller/issues
-
Hello!
Thank you for sharing this CFW!
I have purchased a KSGER T12 OLED Station, but it has a STM32F102C8 instead of the F103.
Can your firmware run on F102C8 or I must replace the CPU?
Best regards,
Demian
Hi,
Sorry for the late reply.
I'm not familiar with that cpu, but at a first glance even the max cpu frequency is lower so it would mess up things big time.
Although it is likely possible to run the firmware on that cpu you would have to make the changes yourself so it will probably be simpler just to swap the chip.
-
ok guys,
I just tried both version of your firmware, for JBC and for Hakko. They seem to be the same regarding display symbols.
Even pre-defined tips are the same in both version. Is that ok?
OK, programming was my fault...
But I would like to ask to explain the display layout. So far I was using old school soldering irons, so this is pretty new for me. It may be helpful also for someone else. SoI have following questions:
Left upper corner symbols can be following: SET, STB, BOO "Set" is supposted to be temperature settings. That is clear.
What "STB" stand for? Is it Standby/Sleep setting? "BOO" symbol I guess is Boost mode. What for is boost feature? How do I use it?
Right upper corner - "%" symbol. What is the purpose of this symbol?
Left bottom corner - There are D24, BC2, DFLT, B symbols -- I guess they are preset settings for tips. D24, BC2 - are they ksger/Hakko T12-BC2 and T12-D24 tips? Why D24 and BC2 need to have extra settings? "B" symbol - not sure. With Hakko firmware I would like to use T12-JS02. Shall I use DFLT settings?
DFLT symbol- I guess it means "default". What tips are covered by DFLT settins?
Regards, Roman
Hi,
You made a similar question on my blog so I answered there.
However since it seems to be a common question, regarding tip settings, the ones which have defaults on the firmware images aren't special in any way or form, they just happen to be the one I have.
The defaults should work with any tip but the performance will be poor. First the termocouple on the hacko tips varies a lot in terms of response from tip to tip (probably due to differences in terms of termocoupling), second depending on the termal mass of the tip the PID should be tune accordingly. Also PID tune depends on ones preference, you can favor response speed (for example when you put the tip to a big component) over decrease overshoot, or have no or little overshoot with a not so snappy response.
So if you want the best performance you should create a new tip (on the tips menu), run temperature calibration (requires an external temperature sensor), and tune the PID. If you just want to solder stuff just pick one of the defaults.
Cheers,
José
-
You guys might have better luck with support if you use the github site for bug reports and feature requests
https://github.com/PTDreamer/stm32_soldering_iron_controller/issues
Hi,
The thing is that with this forum if I miss an email for a thread reply the system doesn't send any subsequent emails for other replies.
-
I have finished the hardware for my makita battery powered JBC soldering station:
https://photos.google.com/share/AF1QipNUGWBi8TsTv3XJrhcUtLYmIUcQqSJdHKy6biLLu8C_IrXBQqWFeakXPjf2mygBng?key=U2VjWEVPLTZlNmxCVjBtRDdqZ21BQnF2dmNydW9B (https://photos.google.com/share/AF1QipNUGWBi8TsTv3XJrhcUtLYmIUcQqSJdHKy6biLLu8C_IrXBQqWFeakXPjf2mygBng?key=U2VjWEVPLTZlNmxCVjBtRDdqZ21BQnF2dmNydW9B)
The battery interface is a chinese clone of the Makita USB phone charger for about $10.
The USB charger still works (and is rather well made with two separate DC/DC converters).
I included a 10A automotive fuse, and a DC connector charging port for the battery.
Please note the difference between the 245 and 210 tip connections, as now documented on Jose's blog and github page:
https://www.ptdreamer.com/chinese-stm32-oled-soldering-controller-important-update/ (https://www.ptdreamer.com/chinese-stm32-oled-soldering-controller-important-update/)
https://github.com/PTDreamer/stm32_soldering_iron_controller/issues/4 (https://github.com/PTDreamer/stm32_soldering_iron_controller/issues/4)
If you don't watch this the PCB will smoke as soon as you try to put the iron in the stand for sleep.
The code changes for battery voltage display are also available on the github page.
Thanks again to Jose for his fine software, and the help in resolving the connection problems mentioned above.
Next: Makita battery powered work light with 120cmx22cm 70W LED cob, as seen on BigClive.
-
Can anyone help me with the temperature settings ?
i got my KSGER STM32 T12 yesterday and i can't figure out the temperature settings.. how do i change it..?
here are a few pics..
https://imgur.com/a/eLiyrx3
-
Hi, Please fix STANDBY mode. At the set time doesn't work. Firmware hakko. Thank.
-
if it is similar to this CRE-STM32
https://www.jotrin.com/product/parts/STM32F103C6T6_32_10 (https://www.jotrin.com/product/parts/STM32F103C6T6_32_10)
-
It would be nice to add protection from overheating of the cartridge. Today I burned :palm: the JS02 cartridge because of an improperly installed pid. Thank.
-
It would be nice to add protection from overheating of the cartridge. Today I burned :palm: the JS02 cartridge because of an improperly installed pid. Thank.
I'll try adding it soon.
-
Hi, Please fix STANDBY mode. At the set time doesn't work. Firmware hakko. Thank.
Do you mean you can't set the set time on the ui, or the problem is that the system doesn't go to standby after the set time?
-
Hi, Please fix STANDBY mode. At the set time doesn't work. Firmware hakko. Thank.
Do you mean you can't set the set time on the ui, or the problem is that the system doesn't go to standby after the set time?
System doesn't go to standby after the set time.
-
Hi, Please fix STANDBY mode. At the set time doesn't work. Firmware hakko. Thank.
Do you mean you can't set the set time on the ui, or the problem is that the system doesn't go to standby after the set time?
System doesn't go to standby after the set time.
I found some time to test this and found an issue in the code. Please try the new release and let me know if it fixes the issue.
-
standby mode now works :-+
-
standby mode now works :-+
Nice, thank you for the feedback!
-
Can somebody help me, I am getting the following error
10:03:32 : Can not connect to target!
Please select "Connect Under Reset" mode from Target->Settings menu and try again.
If you're trying to connect to a low frequency application , please select a lower SWD Frequency mode from Target->Settings menu.
Both "Normal" and "Connect Under Reset" fail to detect, "Hot Plug" does detect but I get an "Unexpected error" when opening Option Bytes.
10:51:41 : ST-LINK Firmware version : V2J31S7
10:51:41 : Connected via SWD.
10:51:41 : SWD Frequency = 4,0 MHz.
10:51:41 : Connection mode : HotPlug.
10:51:41 : Debug in Low Power mode enabled.
10:51:41 : Device ID:0x410
10:51:41 : Device flash Size : 64KBytes
10:51:41 : Device family :STM32F10xx Medium-density
10:51:51 : Unexpected error
10:51:57 : Disconnected from device.
10:51:57 : Connection to device is lost: check power supply and debug connection.
10:51:57 : If the target is in low power mode, please enable "Debug in Low Power mode" option from Target->settings menu.
-
try downgrade version
-
Are you powering the device externally?
-
I tried the previous suggestion and downgraded firmware and still no luck, I am not powering it externally it powers on itself with the current from the VCC pin.
Can somebody post the Linux command to flash with openocd, I would like to try the stlink with linux and I also have a Bus Blaster that may work as well.
-
You should provide external power in case USB is not providing enough current
-
You should provide external power in case USB is not providing enough current
If I do provide the current I assume I can skip the VCC connector?
-
On Linux I can not check. on Windows all is well.
19:34:36 : ST-LINK SN : 380069063141323955200543
19:34:36 : ST-LINK Firmware version : V2J24S4
19:34:36 : Connected via SWD.
19:34:36 : SWD Frequency = 4,0 MHz.
19:34:36 : Connection mode : Normal.
19:34:36 : Device ID:0x410
19:34:36 : Device flash Size : 128KBytes
19:34:36 : Device family :STM32F10xx Medium-density
19:35:07 : [iron1.2.bin] opened successfully.
19:35:07 : [iron1.2.bin] checksum : 0x004EA79B
19:35:26 : Memory programmed in 7s and 766ms.
19:35:26 : Verification...OK
19:35:26 : Programmed memory Checksum: 0x004EA79B
-
On Linux I can not check. on Windows all is well.
19:34:36 : ST-LINK SN : 380069063141323955200543
19:34:36 : ST-LINK Firmware version : V2J24S4
19:34:36 : Connected via SWD.
19:34:36 : SWD Frequency = 4,0 MHz.
19:34:36 : Connection mode : Normal.
19:34:36 : Device ID:0x410
19:34:36 : Device flash Size : 128KBytes
19:34:36 : Device family :STM32F10xx Medium-density
19:35:07 : [iron1.2.bin] opened successfully.
19:35:07 : [iron1.2.bin] checksum : 0x004EA79B
19:35:26 : Memory programmed in 7s and 766ms.
19:35:26 : Verification...OK
19:35:26 : Programmed memory Checksum: 0x004EA79B
Can you share that version of the stlink utility/software you used with me? (I found the V2J24S4 firmware)
Also can you post the commands used with Linux and openocd, I would like to try this.
-
I'm sorry, I only have a version for Windows. If this helps you, I'll give you my archive.
https://mega.nz/#!FNR1BYpJ!lhzPvsJsUFydcq3rCH5S0j9LvIRhSjXqrqwAWyVMbbM (https://mega.nz/#!FNR1BYpJ!lhzPvsJsUFydcq3rCH5S0j9LvIRhSjXqrqwAWyVMbbM)
-
SLP mode is not supported below 100C :(
https://mega.nz/#!FUIlhA6R!Y2RUSCpjiuwd23EOofrJQAYprZv5WEFDlEHnF0hFrx4 (https://mega.nz/#!FUIlhA6R!Y2RUSCpjiuwd23EOofrJQAYprZv5WEFDlEHnF0hFrx4)
-
SLP mode is not supported below 100C :(
https://mega.nz/#!FUIlhA6R!Y2RUSCpjiuwd23EOofrJQAYprZv5WEFDlEHnF0hFrx4 (https://mega.nz/#!FUIlhA6R!Y2RUSCpjiuwd23EOofrJQAYprZv5WEFDlEHnF0hFrx4)
It makes no sense having sleep set with such a low temperature due to the high thermal cycling that would result in. Furthermore neither the hardware or the code is capable of providing accurate temperature reading at that temperature.
-
Hi,
im planing to update my soldering stations.
I'm thinking about JBC stations but price is little bit to high for me and specially that i will need to buy two stations.
I'm considering STM32 station (with black aluminium handle)
https://www.aliexpress.com/item/KSGER-OLED-Soldering-Station-T12-ILS-Electronic-Iron-Tools-STM32-2-1S-Temperature-Controller-Handle-Stand/32825087311.html (https://www.aliexpress.com/item/KSGER-OLED-Soldering-Station-T12-ILS-Electronic-Iron-Tools-STM32-2-1S-Temperature-Controller-Handle-Stand/32825087311.html)
I've found that firmware update that give possibility of using JBC tips.
Main question is, is there advantage using that station with JBC tips ?
I'm asking cos i'm planing to use that handle:
https://www.aliexpress.com/item/ESD-DI3000-75W-soldering-handle-station-parts-T245-handpiece/32817321335.html?spm=2114.10010108.1000013.1.3dc83416jVEyW3&gps-id=pcDetailBottomMoreThisSeller&scm=1007.13339.90158.0&scm_id=1007.13339.90158.0&scm-url=1007.13339.90158.0&pvid=72e3f16a-3793-4c13-8e09-000b3cfcec84 (https://www.aliexpress.com/item/ESD-DI3000-75W-soldering-handle-station-parts-T245-handpiece/32817321335.html?spm=2114.10010108.1000013.1.3dc83416jVEyW3&gps-id=pcDetailBottomMoreThisSeller&scm=1007.13339.90158.0&scm_id=1007.13339.90158.0&scm-url=1007.13339.90158.0&pvid=72e3f16a-3793-4c13-8e09-000b3cfcec84)
with that tips:
https://www.aliexpress.com/store/product/10-pieces-lot-Sn-Pb-63-37-0-5mm-500g-roll-solder-wire/805067_32572251088.html?spm=2114.12010612.8148356.31.617e31b7I1zkbg (https://www.aliexpress.com/store/product/10-pieces-lot-Sn-Pb-63-37-0-5mm-500g-roll-solder-wire/805067_32572251088.html?spm=2114.12010612.8148356.31.617e31b7I1zkbg)
Asking cos i'm mainly soldering RG402 cables to 2oz pcb's and to connectors. I also work with aluminium pcb's.
Doing it with stations that uses 900 tips it's very slow and usually i must work with 450 degrees.
-
Looks like there is a another version with vacuum (solder suction) and JBC support. Scroll down to see the pcb with comments.
Uses a 6 instead of 5 pin connector.
Would be nice to have this in higher wattage version as JBC goes up to 140 watt?
https://www.aliexpress.com/item/KSGER-T12-K-B-C1-BC3-Electric-Soldering-Irons-V2-1S-STM32-OLED-Temperature-Controller-Thick/32888735872.html (https://www.aliexpress.com/item/KSGER-T12-K-B-C1-BC3-Electric-Soldering-Irons-V2-1S-STM32-OLED-Temperature-Controller-Thick/32888735872.html)
PCB picture:
(https://ae01.alicdn.com/kf/HTB1GcVthiMnBKNjSZFCq6x0KFXap.jpg)
-
When my iron goes into standby, instead of decreasing the temperature begins to rise and rise and rise. It does not stop, the iron gets bright red hot!!! and I have to shut it down before it melts :scared:
-
When my iron goes into standby, instead of decreasing the temperature begins to rise and rise and rise. It does not stop, the iron gets bright red hot!!! and I have to shut it down before it melts :scared:
delete cartridge configuration and calibrate
-
delete cartridge configuration and calibrate
Do you mean tip configuration?
Thanks
-
delete cartridge configuration and calibrate
Do you mean tip configuration?
Thanks
yes
-
Very cool project.
Do JBC handles plug and play with the existing connector on this board? Or it needs a different connector to be put in the unit as well?
-
RICKTENDO, a Great discussion here, thank you for this post! :-)
I briefly peeked at this post and did not find, or missed the discussion, of the type of wire used between the thermocouple and the junction at which the temperature is converted to true temperature. My limited knowledge of thermocouple interfacing seems to recall a specific reason for wiring to be of a certain type, dependent upon the alloy used at the hot junction, to maintain potential accuracy. If this is true the cable between the thermocouple and the sensing device very likely must be changed for reliable accuracy. It is doubtful the Chinese have taken this to the table after weighing the cost of cable redesign and manufacturing if it was considered at all.
The ultimate design would be to place the cold junction inside the handle of the iron removing the need for special cable construction. The closer the distance between the junctions accuracy is improved.
Please elucidate or point us to something missed? (Any person with knowledge in this area is encouraged to comment)
Note: This level of accuracy in temperature will be required in very few situations but it is reassuring to know it is on point when required. Too many tradeoffs quickly degrade any product on a logarithmic scale and that practice is too often the definition of made in China. In fairness, I ask what the driving force is behind these decisions? Could it be our constant desire of more for less?
-
Hey there. I am considering between either this project and another one. Or perhaps make both. However I do have a few questions. Maybe Some of you can chip in and answer these? Because the other project is all in Russian so it's harder for my to find similar answers over there! Many thanks.
1) What is the performance like, because it's difficult to see on the video. The original JCB stations go from cold to about 300C in only 3-4 seconds. However other solutions (like the unisolder) take considerably longer time than that.
2) Is the heating done high current DC pwm based. Or through an ac / zero crossing triac / half waves?
3) Does the heater have to be turned off, in order to measure the temperature from the thermocouple? How often is this done?
4) [edited] Is there no possible software fix, to make a safety mechanism to detect and prevent the tip from glowing red hot on sleep? Or is that something else? For example because of different wiring configuration between the T210 and T245 handles.
Ah... I see maybe that is already fixed now in the latest v1.1.3 release. "This release fixes an issue which resulted on the power to the iron being inadvertently be set to 100% with some calibration values." Good to know! :-+
5) If i get a revision 3.0 board, will the STM32 controller on it break / die quickly? Why would that happen?
Sorry if these questions seem a bit stupid or obvious. I really haven't had enough time to research all this in depth. Just trying to figure out which way to go first.
-
(https://ae01.alicdn.com/kf/HTB1GcVthiMnBKNjSZFCq6x0KFXap.jpg)
I have the KSGER soldering iron with the PCB that looks like this and I flashed it with the Oct 31, 2018 iron.bin from iron_hakko_big_screen.zip. However, now all the iron does is run the piezo beeper at insane volume and never starts up.
- Set readout protection disabled
- Program and verify said sectors were write protected
- Went into Option Bytes and turned off all sector write protection
- Program and verify completed
- BEEEEEEEEEEP (device just beeps). The beep isn't 100% continuous, it sort of ticks at a regular frequency, but mostly it just squeals loudly
- Performed chip erase and reset device. Sweet sweet silence
- Program and verify completed
- BEEEEEEEEEEP
Am I doing something wrong or is the hardware different and therefore now I've broken my soldering iron until I reverse engineer the schematic and hope it is close enough to run the custom firmware?
EDIT: Aww dangit. This is an STM32F102C8 so no wonder it doesn't work. Guess I just made myself a brick!
EDIT2: I pulled an STM32F103C8 off a blue pill and plopped it into the KSGER V2.1S PCB. It flashed ok with the iron.bin but I still get just the continuous beep, although it is a little quieter because I sorta melted the piezo while using the hot air gun. I also burst the battery from the heat, but removed it afterward. That's not needed to run though, right? Any step I've missed here?
-
What was wrong with the firmware that came with the station that made you want to upgrade? I'm just curious as I'm interested in buying one of these KSGER stations.
-
What was wrong with the firmware that came with the station that made you want to upgrade? I'm just curious as I'm interested in buying one of these KSGER stations.
Lets you run JBC irons/tips as well as T12/clones.
As for the previous poster, no you can't expect firmware for one board to work correctly on a different one, and yes you will need to do some work reverse engineering the PCB and modifying the code!
-
What was wrong with the firmware that came with the station that made you want to upgrade? I'm just curious as I'm interested in buying one of these KSGER stations.
The original firmware goes absolutely bonkers trying to control the temperature with the K shaped tip, even after calibration. The temperature tolerance for it is all over the place; setting it to 320C you'll see up to 360C and down below 300C. With all tips, it also doesn't seem to hold temperature very well. I set it to 300C with the BC2 tip and can hold it on a GND-plane-connected joint and it still says 300C and you can watch the power sort of creep up to as much as 20% but the solder still isn't melting. With I and J type fine points, soldering SMD is hit or miss as well with the temperature and how long I have to keep the tip on the part. I was hoping to get more accurate temperatures / less temperature drop / faster temperature recovery when soldering.
I also figured with the ubiquity of these designs and that the F101 and F103 processors have the same pinout, they would have the same things connected to the same pins and the only difference between then would be the firmware so the CFW might work. I looked at the code and it seems to halt and trigger the alarm if any of the HAL fails to initialize properly so I'm not even sure it is getting past init(), which should work given the MCU is the same as with the CFW. Not sure what crystal my board has though.
-
Hmm, that's discouraging. A soldering iron is one thing I don't want to troubleshoot and tinker with, just use it for it's intended purpose (I have too many other things like that already ;D). I've read and watched videos about fluctuating temps with the aftermarket T12 tips. I wonder if you just got a bad one and a genuine Hakko tip would have solved the issue?
-
Hey there. Somebody can comment on the heat up time (from cold) wth the T245 handle ?
-
My unit is also the STM32F101xxx series.
It will take me a bit to determine what is different.
-
My unit is also the STM32F101xxx series.
Wow that's nuts because the board layout is completely different than mine, despite mine also being "Ver 2.1S". Mine has the external pump switch header populated, and the battery is soldered along the bottom edge, with the piezeo closer to the other edge. I know there's also another, third, Ver 2.1S that has the header for the connector to the iron but also has the ability to solder the DIN / aviation plug directly to the board as well.
As far as how fast it heats a T245 I can't say, but the T12s take under 10 seconds to heat up so I can't imagine they'd be very different. It actually took longer for my unit to turn on once I flip the switch than it did to heat up. There's like an 8 second delay on startup between the power supply coming on (<2s) and the iron initializing with a black screen (~6s) or waiting in a bootloader or something.
-
EDIT2: I pulled an STM32F103C8 off a blue pill and plopped it into the KSGER V2.1S PCB. It flashed ok with the iron.bin but I still get just the continuous beep. Any step I've missed here?
Hmm. I am reading that specific variants seems to differ by the last letters denoting the various different sizes of the various different ram types...
https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565 (https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565)
His one was this:
(https://www.ptdreamer.com/wp-content/uploads/2018/02/SAM_2582-768x576.jpg)
STM32F103C8T6
Which is 64k flash and 20k ram
Where I *believe* that the T6 at the end merely means the 'normal' (not special) operating temperature of -40C to +85C... so 'yes', all C8 part are supposed to have the same amount of memory in them, which should mean they are compatible and flash each other.
So either you did not flash it properly somehow (which I myself don't know the proceedure yet, but it seems pretty darn complicated / jumping through hoops until the cows come home).
Or perhaps the new chip you replaced somehow sustained ESD damage at some point during it's handling. I have seen this myself on other 3.3v rated MCU chip (in the teensy). Where just through regular handling, and ESD discharge killed one of the GPIO pins on the MCU. Whilst the rest of the chip continues to function normally and without problem.
Hope that helps.
-
Heres a pic of my new v3.0 controller from KSGER. Which arrived today. The table @ https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565 (https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565) says it has enough flash space on it.... so it aught to be compatible i guess
(https://i.imgur.com/P4bXFij.jpg)
and typical (as per usual), we can see this board arrived with some flux residue left on it. No biggie really. Should come off
-
Heres a pic of my new v3.0 controller from KSGER. Which arrived today. The table @ https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565 (https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565) says it has enough flash space on it.... so it aught to be compatible i guess
(https://i.imgur.com/P4bXFij.jpg)
and typical (as per usual), we can see this board arrived with some flux residue left on it. No biggie really. Should come off
Your v3.0 controller looks identical to the one that is in my v2.0 KSGER (https://www.amazon.com/KSGER-Temperature-Controller-Electronic-Equipments/dp/B07L3HHZSX/ref=sxts_kp?pd_rd_i=B07L3HHZSX&pd_rd_r=55092277-45bb-499d-b6da-4341476cd777&pd_rd_w=rKOSh&pd_rd_wg=rja8g&pf_rd_p=9e1f8218-b1c6-41ee-b8db-ab27d6c0f6de&pf_rd_r=1B3DEPRCFV75PY4MH8V8&qid=1551906926&s=gateway) except the battery is soldered to the board rather than having a header. But same ST chip. Mine seems to work well so far with the KSGER firmware, just a weird issue with boost mode if I try to enable it too soon after coming out of standby. Mine has some flux around one of the SOT23-3 components like they had to do a little rework on it.
-
So either you did not flash it properly somehow (which I myself don't know the proceedure yet, but it seems pretty darn complicated / jumping through hoops until the cows come home).
Or perhaps the new chip you replaced somehow sustained ESD damage at some point during it's handling. I have seen this myself on other 3.3v rated MCU chip (in the teensy). Where just through regular handling, and ESD discharge killed one of the GPIO pins on the MCU. Whilst the rest of the chip continues to function normally and without problem.
It is very probable that I could have damaged the chip when desoldering it to move it over, but given that the STM32 ST-LINK utility flashes the chip and then can be verified as many times as I want, it is flashed fine unless there are other fuses or flags that need to be set in order for it to run properly.
It just plays the buzzer on startup though, which is a function of the source code which just turns on the buzzer if HAL init fails on startup. If any of HAL_ADCEx_Calibration_Start(&hadc2), HAL_ADCEx_Calibration_Start(&hadc1), or HAL_ADC_Start(&hadc2) fails it just turns the buzzer on. Looking deeper in the code it doesn't halt unless the last one fails. I probably should have just uploaded the code to the blue pill first to see if worked before the surgery.
The board you got there looks like the "2019 STM32 V2.1S" version and mine is the "2018 STM32 V2.1S", which is funny because the 2018 version listing on aliexpress shows the 2019 PCB and warns "STM32 V2.1S controller is changed to this model, before order please be careful". Hey here's an idea guys, why not change the version number when you made large changes?
I'd be interested in hearing if you have any luck with the custom firmware which could mean that all I need to do is just get a replacement 2019 control PCB.
-
Dear friends,
Is that possible to find the firmware for KSGER 2 in 1 soldering station? I broke the STM32 chip and I want to replace it.
Need the firmware to flash onto the STM32.
banggood.com/KSGER-STM32-OLED-T12-Temperature-2-in-1-Hot-Air-Dryer-Digital-Rework-Soldering-Station-Solder-Iron-p-1407450.html
-
I don't think U5 is up to the task for powering the controller. Mine continues to sporadically reset when trying to enable boost and then started resetting when entering sleep mode. I opened up the case to see what it would take to add chassis grounding and the crashing stopped. That got me thinking that maybe it was a overheating problem. Touching various parts while it was running revealed U5 was super hot. If I put my finger on it for more than a second, the station would reset.
The device is a 250mA 3.3V regulator in SOT89 footprint and heatsinking on the PCB is very poor. Looking that size up on Mouser/Digikey reveals there's not much available to support more current handling in that form factor and with 24V+ input voltage. I might try to just replace it if it's defective, but I have an idea of using a bigger/better regulator on a stand alone PCB and use flying leads to connect it.
-
while it was running revealed U5 was super hot. If I put my finger on it for more than a second, the station would reset. The device is a 250mA 3.3V regulator in SOT89 footprint and heatsinking on the PCB is very poor.
When i look at my earlier photo (above) of U5... it seems possible for me to cable tie a heatsink onto the back of the pcb there. And have it stabilized by the 2 other ICs beneath it. With the cable tie avoiding th mounting holes, and passing underneath the gap where the LCD screen is mounted on the other side of the PCB.
This would mean that the heatsink can fully cover the U5 package, however it would be positioned at the very corner of the heatsink. Due to it's awkward location right next to the LCD header along the top edge. Which sticks up a lot. WHich isn't most ideal. However if i trim down those LCD header pins, then the heatsink could be repositioned better. But still not ideal if it's overhanging a lot.
As somebody who only bought the controller PCB, and not the external casing / housing for it.... then there are more options for actually removing the LCD and the buzzer from the PCB. To put them on little extension wires / cables.
But first it would make more sense to veryify / make certain that adding such a size of heatsink actually can solve the issue at all. Before thinking about which of those options (if any) is most reasonable way of getting it mounted properly.
Not going to look at this for some weeks however. But in the meantime maybe you can experiment yourself with a thermal pad and a little heatsink. Mine over here is 20mm x 20mm square with 49 pins / extrusions (cross cut). And that is really the largest one I have that's going to fit without doing any of the other mentioned modifications.
-
That's disappointing news about the newer revision of the circuit board. Comparing your U5 to my U2, my U2 is much larger (SOT-223-3?) and also has a thermal pad in the copper with vias to the back side. Hope you're able to work it out and get a stable controller.
-
Yeah, this isn't what I really wanted to deal with. Looks like I can use spare holes in the board to get 24V and Gnd over to a little PCB I made that breaks out a larger, more capable Vreg.
But with the cover left off, this station actually does a great job. I have the K, ILS, BC2, D16, and DL32 tips. The D16 is my favorite, it's awesome for SMD. Works great for SOT23 type ICs and 0805 passives and still big enough for through-hole headers. I think the ILS is pretty worthless because the tip is so fine. The K is great for desoldering and removing solder bridges but needs flux to work well. The DL36 makes quick work of through hole and large copper pours. Not much time yet with the BC2, but looks like it'll work well to drag solder.
Like others have noted, the temps bounce around when the tips are new, but setting medium heat (250C) and letting them burn in for the first 5-10 minutes, they calm down and have been pretty accurate once calibrated. Being able to use a corner of my silicon mat to yank out one tip to swap in another is excellent. I really like the blue handle, it's comfortable to use and fits great in a Pace iron stand a buddy gave me. 8)
-
I've got the same "3.0" controller board, with the random reset issue out of the box.
I've tried burning the FW and ended up with a dead unit - it looks like it's freezing somewhere in a loop.
MCU is STM32F103C8U6
Info : device id = 0x20036410
I think it's time to start tracing the circuit. I'll have to buzz the traces out, there's some risk of breaking stuff if I try to separate the display board, etc.
I've quite different from the schematic at "https://www.ptdreamer.com/wp-content/uploads/2018/02/iron_schematic.png" - there is an extra 24C08 eeprom and a SOT23-5 marked "A36" - it might be an OPA336 amplifier.
It matches the connection and the output pin reacts to me touching the input connector.
(edit reason - added device ID)
-
@dreamcat4, do you have a photo of the backside of the controller PCB that faces the OLED display but taken down at an angle? I'd like to see how big the traces are coming off the empty header labeled "C D Gnd VCC" above the STM chip. If Gnd and VCC are reasonably substantial like the connections for Gnd and VCC are on the OLED header, then I'll use those to patch 3.3V back in from my little Vreg PCB.
-
I think i understand your question correctly. Unfortunately i did not think to take such a photo. However what i can describe is that both C and D traces are clearly only on the same back side as the STM32. Which I will call the "MCU side". C & D seem to be data lines connecting to pins on the MCU. SO those are already visible in my previous existing photo. So the only 2 that connect on the other side (the display side) are GND and Vcc.
However if you were to de-solder and remove the OLED display / mini board on the display side. Then you could get fine access to scrape & bodge a rather large solder blob for the GND VIA. To make GND perfectly fine. For the Vcc via, the trace connecting to it is the same width as another trace that can already be seen in my previous photo. Which is the short trace and fat directly above the middle of U5 regulator. So that is also reasonably 'a lot wider' than most of the other tiny signal traces. Hope that helps. :-//
-
Yep, that helps a lot, thank you. I'm no where near my station so I was curious how big those traces were and if they'd be fat enough to supply VCC and Gnd to the controller from the new regulator. That'll make it easy to connect everything up rather than tack on to the VCC and Gnd at the OLED connection.
-
Hey guys, can anyone help me to find compatible controller for ptdreamer's firmware?
I found this one, but I am not sure.
https://www.ebay.com/itm/110V-220V-OLED-Digital-Soldering-Iron-Station-T12-Handle-Finished-Controller/163243100220?_trkparms=aid%3D222007%26algo%3DSIM.MBE%26ao%3D1%26asc%3D20190212142712%26meid%3D0d8c747b314242d3826839693cdec1d0%26pid%3D100037%26rk%3D2%26rkt%3D12%26mehot%3Dpp%26sd%3D112639906210%26itm%3D163243100220&_trksid=p2047675.c100037.m2107 (https://www.ebay.com/itm/110V-220V-OLED-Digital-Soldering-Iron-Station-T12-Handle-Finished-Controller/163243100220?_trkparms=aid%3D222007%26algo%3DSIM.MBE%26ao%3D1%26asc%3D20190212142712%26meid%3D0d8c747b314242d3826839693cdec1d0%26pid%3D100037%26rk%3D2%26rkt%3D12%26mehot%3Dpp%26sd%3D112639906210%26itm%3D163243100220&_trksid=p2047675.c100037.m2107)
-
Very interesting, congratulations to ptdreamer and other users for do this firmware. Only a question, somebody have the pcb in some file to reproduce it o r knows if the PCB alone it's selled by anyone? I like the idea to use it with a battery or in a car but I prefer to populate the board with quality components. Thanks!
-
@Tarloth: i have a schematic for my unit, but it's not compatible with ptdreamer's firmware, I'm still working on a firmware for it but it's low priority now.
I recommend a TS100 - you can power it from the car battery or from a 4S - 5S RC lipo pack. You can find alternative firmware for it that will add some battery undervoltage protection, etc
-
My KSGER station with v2.01 firmware (http://My KSGER station with v2.01 firmware) has battery cutoff voltage in the menu options. That controller can be bought separately on Ebay and the like.
-
All the point is to use JBC soldering tips (thats have much better thermal response). That why I want to find compatible controller for ptdreamer's firmware. Help from anyone?
-
Hey guys, can anyone help me to find compatible controller for ptdreamer's firmware?
It is hard to say if any station is compatible with the firmware even if you can see a picture of the board inside. The one you linked doesn't even have that, or any identifying information about it, so I would be doubtful that it does. These devices aren't well documented, often undergo massive changes to the electronics inside while still being released under the same name and version number, and even the photos may not be of what you get. The only advice I can give you is to try to find a listing where the photo of the board in the listing exactly matches ptdreamer's and even then I'd say chances are it might not be compatible.
I sort of put off looking for a replacement controller board for my unit due to how problematic finding a compatible one would be and just went back to using my old soldering station.
-
My impression that if the controller is the same chip type... well then the only differences of the MCUs themselves on the different variants of these boards is just the amount of ram and flash on them. So long as there is enough of each to accomodate the firmware image (and booted / running). Then what else is there?
Well there is the pinouts, which pins are connected up to which parts of the circuits. For example if one board revision wires pins 16,17,18,19 (i am just making that up a fictional example), to the SPI display. Wheras it could be connected up to a different set of pins on a different version of the PCB. Well that sort of a thing should be fixable my modifying the open firmware on github.
Perhaps there is also a bootloader? Is that some separate chip that differs? But I am not sure that is the case here. Other than that? maybe some parts of the circuit measure different values. Or work slightly differently. Again, we should work to make these other revisions also compatible. Even if it means flashing a slightly different image. The rest of the firmware should be largely the same. Including all the features and algorithms etc.
So really over in the github network there, we should see evidence of this. And look in other forks of the code too by other users. Or outstanding PRs / issues.
Personally I have not looked yet or gotten around to any of this. My v3.0? 'v3.1'? Is still lying in a drawer somewhere.
Not that there is actually a version number printed on it!! :-DD
-
HI, I have a Hakko 888d and a 951 original stations with their original handles and original tips. A friend have the TS100 and comparing even to 888d feels like crap. TS100 have not a great heat capacity/control and very poor tip quality. I know that a lot of people love this portable solder but I didn't. Sorry, but I think that the problem it's essentially the poor thermal dissipation at handle and the very poor quality of the tips.
I think that the original handles and tips of JBC or Hakko would be work reasonably good with a DIY base, not like the original station but I presume close.
I can't connect my solder stations directly to a 24 volt DC because both circuits assume for the power section drive AC current. When I work in the field I connect they to a sinusoidal UPS but It's bulky and senseless to convert from 24 volts to 220 volt (in my case) to convert again to 24 volt.
I not know if exist any good brand solder station that can be connected directly to a DC source, but I did invest in the Hakko line and would be fantastic if I can use my tips and handles with a DC station. If somebody did an invest in JBC tips, for sure he prefers to use they and not something else.
I continuously read all the time people in this forum asking for a good quality chinese solder station, but when somebody found something that works, chinese maker change the design, the model or somebody copy the external design lowering the quality and the process to find some that works begins again.
Forums are full of T12/15 DIY solder stations but some work and some are worse than chinese copies or even over design the board and the DIY base cost more than the original JBC or Hakko (a crazy and silly design really). If some design can be tested here, would be nice to recommend to everyone that ask for a solder station. If this person need to reduce the final cost thay can buy a cloned handle with cloned tips and if they prefer something better can buy original handle and tips and, in the future, if he need something better, will buy the original base station only.
With a firmware that works OK for the stm32 line, anybody can adapt it for any other stm32 chip in the future with the same pinout only changing the constant definitions in the include section of the firmware. With a proven reasonably good PCB with his BOM somebody can have a DIY solder station that really works.
If somebody have the PCB design and BOM that works for this firmware (or knows that some project with an STM32 works), please post the link and may be can be a real and confident solution for other people. Thanks
-
One thing I would like to say about this custom firmware, is after flashing the latest by default calibration is off by 100 degrees, and calibration does not help much to close the difference.
I don't know if its the default PID settings and I would not know how to properly use this to better my calibration results
For those asking what board I purchased this unit but it appears to have ended
https://www.ebay.com/itm/110V-220V-OLED-Digital-Soldering-Iron-Station-Finished-Controller-For-T12-Handle-/112639906210?_trksid=p2047675.m43663.l10137&nordt=true&rt=nc&orig_cvip=true (https://www.ebay.com/itm/110V-220V-OLED-Digital-Soldering-Iron-Station-Finished-Controller-For-T12-Handle-/112639906210?_trksid=p2047675.m43663.l10137&nordt=true&rt=nc&orig_cvip=true)
-
For those asking what board I purchased this unit but it appears to have ended
Then it would really help to take a clear photo of the pcb (front and back). If it differs from the one PTDreamer has in any way. Since unfortunately seeing that auction picture is not enough to know which one they put inside the black box. (hence the term black box is very applicable here - you have to open it up to see !!). Anyhow many thanks for mentioning the 100c difference. That is also something important too.
-
Its the EXACT same PCB, but using Hakko T12 ptdreamer uses his with JBC
-
Hello
I'm new on this forum, and first of all, sorry for my English (if not exceed the threshold :"D)
So... I ordered one of these T12 copies, especially this DXCHMEI junk version...
The firmware is horrible, so dumb, not responsive, the knob every time over or undershoot the value, and forgot many steps if i linear turn a "bunch"...
My STM32 MCU is the F072CBT6
1.3 OLED
Single color, same as the guy before who got help, but i guess his firmware not gonna be okay for me...
So this is my real question; somebody could craft me somehow a firmware what is not make half a second delay for a simple temp adjust ?
Thank's in advance for every help !
-
Having just bought a KSGER V2.1S soldering station and finding out how good it is, I'm thinking of designing a PCB that ran PTdreamer's code; so what would be the ideal features? Let me try to start the list:
- Uses STM32F103 processor (please correct if wrong)
- Uses the same OLED display (or can we find a (cheap) bigger one, perhaps color?)
- Allows use of either the KSGER T12 tips or the JBC tips (can someone describe what this would mean, will they both plug into the same handle, what would be the connector arrangement?)
- Perhaps allow more power by increasing current handling ability and/or increasing supply voltage (please comment)
- Use a switch mode converter for the 3.3V supply so it doesn't get crazy hot
- Need to consider the form factor for the soldering station which would drive the outline of the PCB + where the controls, display, and connectors were; I think a unit that incorporates an iron-holder in some kind of angled station (like JBC) is better than flat on desk like KSGER but what if it were KSGER-style extruded aluminum case with the display end angled up away from the desk surface?
- Should the PSU be integrated or be a separate laptop-style brick?
- insert your own idea here
Right now, I'm in requirements gathering mode but I'm thinking that the design I end up with would be open source. The first PCBs would be bare boards and intrepid trailblazers could put their own components on in the beta phase. I could also design a case (or the angled end on a KSGER-style case) for 3D printing, I'm really an electronics designer but it would be dumb not to consider the end design aims.
What do you guys think?
-
- Uses STM32F103 processor (please correct if wrong)
Yep. Just be aware that there are different versions of this MCU, I have already explained in a previous post earlier in this thread which one(s).
- Uses the same OLED display (or can we find a (cheap) bigger one, perhaps color?)
It would make sense to initially design around the exact same display, or any other pin-compatible SPI display that is 100% compatible. Perhaps sacrifice an existing board for parts. (which, i am guessing, would require you to buy a 2nd v2.1 unit). But you know: there are always other ways!
Having an option for 2-3 more compatible displays in future would be great / even better. Getting a PCB design that can accommodate multiple types is a nice idea. But not everybody is inclined to go to such lengths. So it is also somewhat of a personal choice too. What is nice is when the person designing the PCB actually bothers to mention the reasoning / rational behind the choice. Because: it lets others know if the reason was region specific parts (they might live in another country, with different supply / prices / access to the part). It also lets others know: if there was some overriding cost based reason why other display(s) are not supported, and not for them to bother researching (because you did the hard work already and here was why). Or alternatively if someone wants to pick up and actually improve your design with an incremental update. Which you did not have the time / resources to do yourself. But is nevertheless welcome / useful / not harmful to the overall product goals (BOM cost, usability, quality, availability, complexity, etc).
- Allows use of either the KSGER T12 tips or the JBC tips (can someone describe what this would mean, will they both plug into the same handle, what would be the connector arrangement?)
Yeah the JBC 6 pin din connector is different, and made of plastic and it has been commented by someone else that it is not the best quality / best possible choice. An assessment which i also agree with. However to loose it means that the user would have to re-wire their JBC handle and solder on a different DIN connector. Which is not ideal assumption (IF that end user also intends to re-use same handle in future on real JBC hardware, or sell it on, etc). OTOH end user might actually want to rewire it with a different (better quality!) connector. Depending on their specific preference. So perhaps the best compromise is to just include suitable pads and holes on the PCB, where an end user can wire their own din plug(s). Whichever common type they need. 1 would be the 6-pin type for the JBC, the other one would be for an official hakko station handle.
Now here is another choice: you might choose to overlap them to occupy the same board space. But I would strongly recommend against that. And perhaps the different pinouts of each style would prohibit that anyhow. (if the pinouts don't match each other well enough to occupy the same space / area).
However a different thinking option might be with some small breakout board that is independently soldered to the main PCB via 0.1 inch headers etc. It is a design decision that also is dependant upon the level of complexity you want, those trade offs. And also the kinds of assembly, case assembly, and even the mechanical strength behind the DIN connector too. For example if the breakaout is situated on another layer directly above the place where you push through the 0.1 inch pins. That can be a simple way to add strength right behind the din plug might be getting some heavy abuse. Or it could be wrong overall choice, if the assembly is more challenging / annoying as a result!
There are best practices in these areas. And hopefully others here can comment better than myself. In the v3.1 pcb i have, there is option for 1 din type (which isnt JBC) AND also just adjacent some type of a breakout pads. Meant for soldering wires then onto the DIN, or off to an independant breakout board (to be screwed onto the front plate). Either way. So that is also another option too.
- Perhaps allow more power by increasing current handling ability and/or increasing supply voltage (please comment)
Not sure myself. Perhaps someone else can answer better. First things first: test the performance of this thing @ 24v. And see how many amps it will draw.
- Use a switch mode converter for the 3.3V supply so it doesn't get crazy hot
My solution was simply going to be glue a decent heatsink onto it. But a proper fix is more than welcome! Actually I have yet to test my approach yet. Have not got around to it. Busy with other things.
- Need to consider the form factor for the soldering station which would drive the outline of the PCB + where the controls, display, and connectors were;
Yeah the v3.1 board (i included photo earlier in this thread so hopefully you can see what I am referring to). Has side breakouts to cover both mounting types (on and off of the front facia). And IMHO that is a useful approach because some people wont have room to mount it all direct as a single piece OR would like to space out the fron panel controls a bit, leaving more gaps, have extra switches or for larger display they want to mount, etc.
IDK, perhaps your choices will be informed by other factors, so some decisions will be made for you due to the other constraints.
I think a unit that incorporates an iron-holder in some kind of angled station (like JBC) is better than flat on desk like KSGER but what if it were KSGER-style extruded aluminum case with the display end angled up away from the desk surface?
I think the main thing for the holder is to get the angle right. So that it is low enough to be ergonomic. If you look at an official JBC stand it is actually fullt adjustable to be as low as you want. Wheras some chinese clone JBC stands / equiplment on aliexpress are just - crap. They have the thing angled way too steep. Which is not comfortable from frequent usage and extended soldering sessions.
And boy are those JBC stands expensive. So yeah! Also just being really good (the stand) is difficult to make well. So you know... it's really something as a separate project (the holder for the handle) than the main controller unit. Would be best to split them up from each other I think. And tackle them one at a time.
AFAIK i am not aware of much considerations for the stand, that would affect the design of the main controller unit. Except for the detection of putting the handle in the cradle. Some switch or whatever they do. IDK how it works. But that seem the only thing to worry about (for ensuring that the main unit will properly support the feature on the cradle). And for it to work well! Not to be jank / or 'crap'/. For example if you were to have assumed and only support the reed switch method, or the mechanical switch method, or visa-versa.
- Should the PSU be integrated or be a separate laptop-style brick?
- insert your own idea here
Personally I am all for separate. And just a decent 24v DC input. That can be wired by decent terminal (not exclusively only by barrel jack). All the way. There are also those nice yellow DC high current plugs. Although again - not to have to assume that as a requirement. Just make it possible / though of.
24 DC input is more flexible. And lets users use for example their bench PSUs if they are in a pinch, or need to re-use the same PSU for multiple jobs. Which is what I am doing here.
That is not to say it's exclusive. Because you can just have a larger box version too, for those who do want an internal PSU. Since you already supported a beefy 2-wire termination aswell, right?
Right now, I'm in requirements gathering mode but I'm thinking that the design I end up with would be open source. The first PCBs would be bare boards and intrepid trailblazers could put their own components on in the beta phase.
Thank you +++1. You may have at least 1 beta test here in UK then.
I could also design a case (or the angled end on a KSGER-style case) for 3D printing, I'm really an electronics designer but it would be dumb not to consider the end design aims.
What do you guys think?
Its probably worth to research the best value 'standard' aluminium extruded box(es). And have those in mind when designing the PCB. For compatibiltiy reasons. To know that it is compatible with at least whichever 2-3 ones from aliexpress represent the best value / quality. For example like the ones being used by the existing KSGer / 'T12 OLED' stations. They are a kind of a standard size that can be bought for a few dollars on ali express. And OFC there might be even better ones. It's another side thing: more searching / research. No specific recommendations there from me though. IDK which ones, just vaguely remember seeing a few of them. Kind Regards.
-
Wow! That was a lot of feedback! Give me a while to digest that.
-
I finally decided to buy a replacement circuit board to swap out the one I flashed in error. I had been using my old soldering iron and had forgotten how stingy on power it is. You have to turn up the temp quite a bit on the old iron because the temperature sag is really bad-- even the display shows the temperature 5-10C below the setpoint and it is still only pulsing the power at a low duty cycle.
Of course, the version of the new circuit board I bought was the 2018 2.1S, which looks nothing like my 2.1S, nor the version posted on the previous page, and the listing even cautions in the text that it isn't the 2018 version. It has a switching regular to replace the SOT223 linear regulator so that's good, and it has a bunch of unpopulated footprints, IC3, IC4, D3, and I think D4. The CPU is the STM32F103C8 or CB (unclear) but strangely in a QFN package. I desoldered the 5-pin header from the old board and put it on the new one and oops the new board is much longer, integrating a 5-pin header and a 5-pin DIN kinda thing. I had to remove my old iron connector and instead solder directly to the new circuit board.
I'm on the fence as to if I want to try to flash this with the CFW, since I'm not 100% sure what MCUs are supported by that build and would hate to brick another board, even if it only was $22 shipped.
-
OK, I'm ready to start the PCB design by drawing up the schematic, if I start off with the one on PTdreamer's blog, here (https://www.ptdreamer.com/wp-content/uploads/2018/02/iron_schematic.png), is that a good start?
-
I put the 2.1S schematic and info in this thread: https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/ (https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/)
It would be good to keep the same form factor? So it can fit old enclosures. I can contribute to the PCB layout if I know ptdreamer is still supporting the project, that it is not orphaned.
The original STM32 T12 firmware written by ZhongGuoxin in 2014, but it kept getting copied so he added copy protection to it. The STM32 firmware binaries need to be activated to work the first time. It involves the taking your STM32 CPU ID1,ID2 and sending money or email for the two activation keys RG1, RG2. Another trick is to move a pin or two around on the MCU, so clone PCB X will not work with firmware load Y.
So there is a hassle to roll-back to the original firmware load, but it can be worked around.
-
Thanks, I'm not 100% clear on what you're telling me. I think it's the following, please comment:
1. PTdreamer's new firmware runs on the KSGER 2.1S hardware that you have reverse-engineered into the linked schematic
2. If I want to go back to the original firmware, it's a process that involves money and keys
3. You recommend keeping the same form factor - I get why you say that but I think that we should consider changing the form factor to a better one that had features not found on the KSGER version - e.g. larger display for old eyes, auto-sleep while in holder - otherwise we may as well just buy the $20 KSGER units. We can always branch the PTdreamer firmware to adapt to any new features.
I'm interested in anyone's thoughts on the above.
[EDIT] Floobydust, your link didn't work, the correct one is this (https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/msg2463234/#msg2463234) I think
-
The original STM32 T12 firmware written by ZhongGuoxin in 2014, but it kept getting copied so he added copy protection to it. The STM32 firmware binaries need to be activated to work the first time. It involves the taking your STM32 CPU ID1,ID2 and sending money or email for the two activation keys RG1, RG2. Another trick is to move a pin or two around on the MCU, so clone PCB X will not work with firmware load Y.
So there is a hassle to roll-back to the original firmware load, but it can be worked around.
Oh that's interesting. I was wondering where the firmware came from since it doesn't appear to be available anywhere to update or restore from.
I do like the current form factor since that style is so ubiquitous. I was originally going to put together a Unisolder (https://hackaday.com/2017/03/08/one-soldering-controller-to-rule-them-all/) before I bought the KSGER deal but the component count, high cost, and uncertainty that I'd be able to get it together made me shy away. It would be great to have a simpler alternative that would let me hack on the firmware too.
-
Unisolder, I think got too expensive and complicated?
I just don't think soldering irons need to be so hyper-complicated, given what they do. People think 1° accuracy will make them better solderers or something.
KSGER software V2.10 has 20 menus, it can be a selling feature but the software is a bit hilarious. It freaks out sometimes and the beeper sounds like stepping on a cat.
1. PTdreamer's new firmware runs on the KSGER 2.1S hardware that you have reverse-engineered into the linked schematic
2. If I want to go back to the original firmware, it's a process that involves money and keys
I have not tried PT Dreamer's firmware. (https://github.com/PTDreamer/stm32_soldering_iron_controller) The last blog update was June/Oct. 2018 and he seems to have reverse-engineered a V1.5 oddball controller board. You would have to change I/O mapping for V2.1S compatibility. PT Dreamer just needs a sample board.
He even sent his source-code to KSGER but that seemed to confuse them, lol.
3. You recommend keeping the same form factor - I get why you say that but I think that we should consider changing the form factor to a better one that had features not found on the KSGER version - e.g. larger display for old eyes, auto-sleep while in holder - otherwise we may as well just buy the $20 KSGER units. We can always branch the PTdreamer firmware to adapt to any new features.
The form factor - a hardware question...
Open-source soldering stations are mostly 936, T12, JBC compatible. Some use a ESP8266 (cheap processor) and SD card for big LCD display and cute graphics.
I like having something compact on my bench, but the KSGER T12 is silly in that the crappy stand is next to it. You're right, it should be on top.
-
Hi all, I recently bought a T12 station with this firmware in mind.
It's the Quicko T12, it shows HW version 3.4 and it's totally different.
Original FW is absolute crap, well, at least it works somehow, but it could be much better.
It uses STM32F072C8t6. Flash reading protected, of course!
Very close specs, 64 Flash, 16KB RAM (103 has 20)KB, 1 ADC instead 2 but enough channels...
The schematic is similar, it adds another sensor amp circuit, I guess for handle temperature sensor.
From what I see most is just swapping pins. Ex, SDA1 for SDA2, ADC inputs, few GPIOS.
Theorically, just need to relocate the pins in stm32cubemx, adjust ADC factors, touch some code, mainly swapping peripherals modules, timers, adc, PWM, as the pins in this board use other ones.
And compile! Hah! It's never that easy. I've tried and it messes up everything.
This is the same board:
https://www.aliexpress.com/item/32963498371.html (https://www.aliexpress.com/item/32963498371.html)
Edit: Corrected schematics.
(Click to open in a new window, high resolution)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1102496;image) (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1102496;image)
-
the pinout and schematic, everything is different.
I spent this afternoon reverse engineering it, let me know your thoughts!
Perhaps you can share the actual schematic file you are working on. Instead of just an image of it? This would then help to make a base for the other board variants.
-
the pinout and schematic, everything is different.
I spent this afternoon reverse engineering it, let me know your thoughts!
Perhaps you can share the actual schematic file you are working on. Instead of just an image of it? This would then help to make a base for the other board variants.
Of course, here it goes. Done in proteus 8.8 (Way faster and easier for me than in Orcad or Altium!)
-
@Gandalf_Sr
Hi, I think it's a great idea. I would certainly be interested.
As the controller that was originally used is not available anymore, there are only 2 options:
1. Modifiy PT Dreamer's code to work with the currently available controllers. This would be the simplest solution (at least for someone who knows programming) and provide for the possibility for additional features to be added.
2. re-design the pcb to work with the original firmware as you propose. An option would be to use a STM32F103 development board such as this: https://www.ebay.com/itm/STM32F103C8T6-Minimum-System-Development-Board-Module-Core-Learning-For-Arduino/113797404420?hash=item1a7eda9704:g:MkcAAOSw6CxdEMMg (https://www.ebay.com/itm/STM32F103C8T6-Minimum-System-Development-Board-Module-Core-Learning-For-Arduino/113797404420?hash=item1a7eda9704:g:MkcAAOSw6CxdEMMg)
They are cheap and it would considerably simplify the PCB design and assembly.
Also, I would opt for a header to connect the connector for the handle. This leaves it free to choose the type of connector you want.
I'm also in favor of keeping the existing form factor for the enclosure.
My main requirements are that I want to use a JBC T245 handle + tips; the handle is much smaller and I believe the tips are better and shorter. Furthermore, the tips can be easily removed/inserted without screwing.
Unfortunately, the chinese KSGER stations don't allow using JBC handle/tips.
I would be a candidate for beta testing either way.
-
I have this pcb version of ksger t12.
(https://ae01.alicdn.com/kf/HTB1r9gxXzDuK1RjSszdq6xGLpXan/KSGER-V2-01-STM32-OLED-T12-elektryczny-temperatura-lutownicy-regulator-stacji-lutowniczej-T12-K-T12-JL02.jpg_q50.jpg)
(https://ae01.alicdn.com/kf/HTB1vmgxXzDuK1RjSszdq6xGLpXax/KSGER-V2-01-STM32-OLED-T12-elektryczny-temperatura-lutownicy-regulator-stacji-lutowniczej-T12-K-T12-JL02.jpg_q50.jpg)
Does anyone have any firmware for it and can share it with me?
-
First of all, thank you PT Dreamer for custom firmware and Jomat for adapting it for v2.1S board. Great work.
I just bought 2.1S with 1.3 OLED and STM32F103C8 ... just try one on aliexpress and this come.
Even Im not developer, somehow I have managed to get the firmware compiled and flashed based on tutorial: https://www.ptdreamer.com/chinese-stm32-oled-soldering-controller-part2/ (https://www.ptdreamer.com/chinese-stm32-oled-soldering-controller-part2/)
Just few things that I have to manage to make it work. Can help someone. I dont understand GIT so just how I have done the changes:
- Jomat - your code is looking for i2s driver and Delay driver in /home/jomat/t12/hello/helloiron/Drivers/ instead of ../Drivers/ which fail on error during compilation
I have changed in file .cproject lines:
<listOptionValue builtIn="false" value="/home/jomat/t12/hello/helloiron/Drivers/software_I2C"/>
<listOptionValue builtIn="false" value="/home/jomat/t12/hello/helloiron/Drivers/1us_delay"/>
to
<listOptionValue builtIn="false" value="../Drivers/software_I2C"/>
<listOptionValue builtIn="false" value="../Drivers/1us_delay"/>
- My screen is 1.3 OLED, so I needed to change:
In file ssd1306.c change "//#define SH1106_FIX" to "#define SH1106_FIX"
- I have also added into code 2 latest PT Dreamer fixes, that are missing in Jomat code:
fix standby timing - https://github.com/PTDreamer/stm32_soldering_iron_controller/commit/c82850fb84bf1f76b8c03f231cffd560f6b82ccd (https://github.com/PTDreamer/stm32_soldering_iron_controller/commit/c82850fb84bf1f76b8c03f231cffd560f6b82ccd)
fix tip overheating - https://github.com/PTDreamer/stm32_soldering_iron_controller/commit/55332eaa6803638e1a5b382a8f639544c576266b (https://github.com/PTDreamer/stm32_soldering_iron_controller/commit/55332eaa6803638e1a5b382a8f639544c576266b)
Im also planning tio get rid of Debug screens, however its not big issue for me now.
For enyone interested also link to Jomat code (without changes mentioned above) https://github.com/jomat/stm32_soldering_iron_controller (https://github.com/jomat/stm32_soldering_iron_controller)
-
First of all, thank you PT Dreamer for custom firmware and Jomat for adapting it for v2.1S board. Great work.
Hey there I looked at the 'Insights' graph today...
https://github.com/PTDreamer/stm32_soldering_iron_controller/network
and it shows this other Github user LuckyThomas, who is many commits ahead of Jomat.
https://github.com/luckyTomas/stm32_soldering_iron_controller/tree/flawless_testing
Although it is not clear what exactly was added without manually walking through all of his commits log there. Since he did not update the README with any summary of whats those additional changes.
Furthermore:
There is another person found elsewhere who has been making some improvements towards supporting v3.0 or v3.1 pcb board. So I have asked them to kindly please come and share that with us. Since it is not on Github yet I also offered to put it up on Github, if they cannot themselves learn the git system etc.
Either way I am very happy to find these 2 new additional contributors and hopefully it will slowly improve the level of support for other board revisions. Perhaps the support is not fully complete but it is a great way to help others and fill in the gaps. So it is not so completely daunting the task.
We shall see / give some time. Personally I am still too busy to fire this thing up yet. Because I want to complete my fume extractor project first before going back to soldering tasks... however working on this is actually for me a priority task. Love to work with these JCB T245 tips. About time to give more attention to it.
:-/O
-
Oh snap this is awesome news that somebody has been working on this. I think I still have my
beeping device broken controller in a box somewhere so I'm going to have to check this out. My working device says:
HW Version [2.1S]
SW Version [2.10]
Is that what you had, alex79?
EDIT: luckyTomas's git includes the two fixes that alex79 posted, so that's a good sign.
-
Haha you know I never actually got around to turn mine on. It never occured to me to see if the version / revision was actually being reported and displayed in the menu... better do that myself.
:palm:
edit:
My unit is reporting reports v3.00 hardware, and v3.02 firmware versions.
-
I did find my old PCB and when I put 24V to it, it still goes BEEEEEEEEP so I'll try to flash it with the luckyTomas git source when I have a chance in the next few days. My current job has declared my project non-essential without pay and suddenly I'm overwhelmed with the number of hobby projects I'm picking back up, this included!
-
Hey what do you know, it beeps when it is supposed to now! I guess now I have to decide if I want to take apart my iron to put the old board with the new software on it.
[attach=1]
-
I soldered an old handle to my newly flashed controller and it worked like a charm. I'm trying to decide if I flash my stock KSGER with this code or if I do all the work of removing the old board and desoldering the connector and moving it over to this board. Probably not that because I damaged this OLED a bit when replacing the STM32 chip when trying to fix my beeping.
Im also planning tio get rid of Debug screens, however its not big issue for me now.
If you mean just get rid of booting into the debug screen, then just change iron/Drivers/graphics/gui/splash.c
static int splash_processInput(screen_t * scr, RE_Rotation_t input, RE_State_t *state) {
if(HAL_GetTick() - splash_time > SPLASH_TIMEOUT)
return screen_debug3;
return -1;
}
Change return screen_debug3 to return screen_main. If you want to remove them from the settings menu, just comment them out in settings_screen_setup() in settings_screen.c (same directory).
comboAddItem(widget, "DEBUG3", screen_debug3);
comboAddItem(widget, "DEBUG", screen_debug);
comboAddItem(widget, "DEBUG2", screen_debug2);
For those wondering how to get to the settings screen, it is hold down the encoder button and turn the knob left or right. You can switch from one settings screen to the next with the same interaction, once you've selected a setting from the list.
-
Long time lurker first time poster so Hello to everyone.
Slightly out of topic so probably not the best start but I just wanted to check something. Does anybody know if there are custom firmwares available for the attached board? It's written on the other side "T12 Controller Board V2.2" and the screen is "OLED V2.0 SH1106".
Many thanks!
-
Heres a pic of my new v3.0 controller from KSGER. Which arrived today. The table @ https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565 (https://www.st.com/en/microcontrollers-microprocessors/stm32f103.html?querycriteria=productId=LN1565) says it has enough flash space on it.... so it aught to be compatible i guess
(https://i.imgur.com/P4bXFij.jpg)
and typical (as per usual), we can see this board arrived with some flux residue left on it. No biggie really. Should come off
@dreamcat4 Am I viewing that PCB correctly and pins 3 and 4 share a common connection to ground?
-
@dreamcat4 Am I viewing that PCB correctly and pins 3 and 4 share a common connection to ground?
Just checked it with a multimeter... that is correct, yes.
-
That's a KSGER Ver 3.0 controller? It's a fail, or going to soon. Older version boards died due to the voltage regulator U5 overheating because it had bad a copper pour for no heatsinking, like what you have. It's just not enough to lower 24VDC to 3.3VDC and power the OLED. You'll see when you burn your finger on it.
-
Yeah there was also some Russian comment somewhere else online saying that these are in fact garbage. The other issue is that somebody tried adapting the custom firmware and could not get it to work properly. Its still sitting here on my desk, after all this time. The piece of garbage that it is.
:palm:
What we should be recommending for everybody is to only buy ones that are specifically sold as being v2.1s going forwards. This is the most recent known good model that is also supported in the firmware. Much fewer of these online listings actually specifically state or guarantee v2.1s board. So it is important to be sure before buying that you trust the seller, or it has existing reviews to confirm that etc.
The other implication is that it's usually best not to buy as some complete unit inside of a housing with the PSU etc. Since it's less clear what version is inside. Unless you already happen to know that the model you are buying contains a v2.1s (or similar) controller.
This isn't really so bad if you wanted it that way you can still buy the other parts separately as a complimentary kit. And need to open it up anyhow in order to upgrade the firmware, and solder in a different 6 pin DIN connector for JBC T245 handle etc.
:-+
-
Any STM32 soldering station controller boards using LDO with no copper pour for heatsinking- they just roast unless you add a metal tab for heatsink or lower Vin below 24V for the Vreg. Add a cap or diode across the heater to protect the mosfet, then they work OK.
-
@dreamcat4 Much thanks.
-
Good afternoon, I've been studying the thread and have been interested in exploring the KSGER CFW scene.
I ordered what was advertised as a 2.1S model as suggested in the forum and this arrived.
It does say 2.1S when I boot it and it does has the 103 version of the ship but it looks nothing like any of the others.
Do you think it's a fair assumption that this might be yet another one in the many millions of versions of this product? LOL
I'm going to just put it back together until I can find some type of shining light that this is safe to proceed on. I am hopeful this photo will help others in pursuing a proper board to proceed wth.
-
Well for the sake of science, I went ahead and flashed to see what happened... Sure enough the beep of doom.
Ended up flashing back 2.11 in the mean time. Might explore other firmwares until an update comes out for this HW revision.
Thanks!
-
Well for the sake of science, I went ahead and flashed to see what happened... Sure enough the beep of doom.
Ended up flashing back 2.11 in the mean time. Might explore other firmwares until an update comes out for this HW revision.
Hey there. I understand you have read up on the details of this already. However you did not mention here in your last message which specific version of the firmware you actually tried to flash. I only mention this in case you didn't notice that there are other forks on Github which claim better or improved support for the v2.1s... either way, please if you could just let us know which of those specific firmware your tied which was not working. Thank you.
:-+
-
Thank you for your response. In all honestly I didn't do due diligence. It was due to an error on my part. I ended up flashing PTDreamers version. When I read of the progresses people made to adapt to other boards, I thought they were all consolidated on to PTDreamers github. I will revisit the six pages and try all the different versions I can find.
If one thing positive came out of this, I learned how to go back to stock! :D now i'm not so afraid to jump off the cliff anymore. I will update once I've tested all the versions I can find.
-
Cool man.
thought they were all consolidated on to PTDreamers github. I will revisit the six pages and try all the different versions I can find.
OK so a more direct method to find all of the current activity on Github is to click on the 'Insights' tab. And then click on the 'Network' page. This gets you to the Network graph view. From which you can see everything. All of the known activity (unless a user has chosen to upload their changes back up as a separate repo, which cannot be tracked using this specific method).
Here we go:
https://github.com/PTDreamer/stm32_soldering_iron_controller/network
Then follow the commit lines to identify which other fork(s) contain useful activity that was not already merged back into the primary repo.
As you can see here LuckyThomas seems to have made an extensive number of commits.
You can then review those commits one by one. However since there are so many it is sometimes easier to just diff only what has changed in the README.md file.
To do that we have to generate a diff. So append `/compare` to the repo url (of this fork). To get here:
https://github.com/PTDreamer/stm32_soldering_iron_controller/compare
Then we can see amongst all the changed files
https://github.com/PTDreamer/stm32_soldering_iron_controller/compare/master...luckyTomas:master?short_path=04c6e90#diff-04c6e90faac2675aa89e2176d2eec7d8
those changes only in the README.md:
(https://i.imgur.com/DLvmBIC.png)
At this point I now see that Thomas has actually bothered to include schematics etc. for the v2.1s, in this same repo:
(https://github.com/luckyTomas/stm32_soldering_iron_controller/blob/master/schematic/Ver2.1S/t12-stm32-controller-back.jpg)
And indeed... not the same PCB! You are right.
:palm:
While similar in some places, yet also clearly its different in the middle area especially.
Dear me. They do want to make our lives harder for us, don't they? With all these different PCB revisions. And not being sure which one you will actually end up getting.
I suppose it makes sense now to try to check and trace where the pins on the right of the STM32 are connecting into that central little cluster. How this diverges from the Thomas v2.1s code fork.
Interestingly Thomas' PCB looks like it's also got a cluster of SMDs moved over (or relocated) from the back on to the front side of the PCB. As shown in his front photo. And some markings he seem to have annotated for some reason (sure why myself yet):
(https://github.com/luckyTomas/stm32_soldering_iron_controller/blob/master/schematic/Ver2.1S/t12-stm32-controller-front.png)
At this point (*so many having gotten the wrong PCB!!!) It would be useful for us to actually try harder to find out which specific online resellers exactly will source the correctly the right supported version of this 'v2.1s' board. The Thomas one.
From these pictures the main giveaway seems to be that it has the version number printer on the back side of the PCB. Wheras this other type has the 'v2.1s' only printed the front next to the Rotary encoder Dial, and nowhere on the back. Of course that itself could also be subject to change if somebody else comes along and tries to spin another so-called 'v2.1s' revision. So rather just use that as a first look way to filter out / narrow your search results. Then compare more fully the whole PCB in as much detail as is permitted by the seller images being provided by the listing.
Hope we can improve this situation over time. For example I think we can submit a PR to LuckyThomas' git repo. Just to add some extra lines in his README file to explain that there are multiple different PCB v2.1 revision floating about. Clearly his code was not tested on this other type.
BTW this is also my 2nd soldering controller and neither one of them are the right one.
:palm: :palm:
-
I envision a “cfw generator that will walk you through the process”....
Toss up a image of the STM32 with all the PIN numbers.
The have pop up boxes showing components on the board and asking you.
[example - shows picture of OLED screen]
‘Starting from pin one [left side] trace the connection back to STM32 and enter the PIN number here: ______”
[repeat for pins 2-xxxx]
[example - shows picture of buzzer]
Starting on pin 1 ......
[example - shows picture of. Xxxxxxx]
Rinse and repeat lol
After you fill out the questionnaire it will compile and generate hex :) wishful thinking!
-
I'm clicking away on those github links but never do I see a schematic?
If we can agree what the best schematic is, I am willing to redesign the PCB to iron out any issues like hot LDOs. I started this a while back but then got sidetracked by work but I am idle right now.
-
I'm clicking away on those github links but never do I see a schematic?
Here you go, up 1 level in the parent folder:
https://github.com/luckyTomas/stm32_soldering_iron_controller/tree/master/schematic/Ver2.1S
BTW i am also trying to email Thomas today just briefly for some few extra notes / infos. If he can help us find it online (from his order). And tell us if he developed and tested his version with either the JBC T245 handle or the Hakko T12 element.
-
Well I tried to compile the most recent commit from the flawless_testing branch here
https://github.com/luckyTomas/stm32_soldering_iron_controller/tree/flawless_testing
unfortunately I could not get it to work. These ST toolchain are so convoluted it's a total nightmare to use them. Installed the stm32cubemx on github.. which worked. However then you have to press this 'generate code' button, open it up in another tool (Workbench for STM32). Which is actually Escipse IDE. From that point it complain about some orphaned toolchain or something to that effect. In the project properties --> C++ build settings. It's all utter nonsense the amount of unnecessary complication added. BTW I have never successfully been able to use Eclipse IDE in my entire life.
So that is really a dead end after googling the error message. Could not find a direct solution. Instead a bunch of slightly different posts about similar error messages for other specific toolchain dependancies.
Tried, then after a few hours of total frustration just gave up pretty quickly.
:palm:
-
If one thing positive came out of this, I learned how to go back to stock! :D now i'm not so afraid to jump off the cliff anymore. I will update once I've tested all the versions I can find.
Oh hang on now. You have a way to get back to stock? I still haven't flashed my daily-use soldering iron because I am afraid of losing the original firmware when I turn off readout protection. Do you have a source for the stock firmware?
I will say that the stock firmware has a little better UI for me. When I need to switch to boost, just turn the knob to the right. Sleep, one turn to the left. Standby, two turns to the left. It is much easier than using the click scroll over, click scroll option, click, especially because clicking requires a change in hand position to prevent the iron from scooting away. I may take a swing at redoing the main screen UI to be similar. The temperature control of the custom firmware seems a little better in working on groundplanes, since the original firmware never seems to ramp up high enough.
These ST toolchain are so convoluted it's a total nightmare to use them.
I had a similar problem with building in that the project I loaded wouldn't build and I had to start editing all these settings and source files and adding files to the project and some were duplicates and I eventually had to blow away the copy of the project and start from scratch again. I'm sure the tools are very powerful but golly things are just all over the place. This is from someone who has been programming in C for 25 years. If I broke my project somehow I'm afraid I'd have to start from scratch again to repair it, although I am sure a lot of that comes from just not being very familiar with the IDE.
-
eventually had to blow away the copy of the project and start from scratch again
LMAO because the 'ST MX Cube' program decided to delete and blow away all of the source code for me. The whole lot. Then it didn't know what to do after that because couldn't find it anymore. It even deleted the hidden .git folder too.
:clap:
-
LMAO because the 'ST MX Cube' program decided to delete and blow away all of the source code for me. The whole lot.
haha that is crazy because the first time I tried to load the project it made a complete second copy but then the next time, I expected it to make a second copy but I was actually editing the originals in the git clone. I think one time I imported it into the workspace and the other time I was able to just load it. I really would like to learn more about STM32 development but there seems to be a pretty steep learning curve with the thousand different tools involved.
-
So, if the IDE setup for STM is so bad, what if we changed the processor to a Cypress PSoC 4000? The PSoC Creator IDE is great and I can get code running PDQ in that environment. Annoyingly, Cypress are now migrating to a new Eclipse-based IDE called ModusToolbox and I'm struggling to get anything other than the canned examples working but the PSoC4000 is all still done using PSoC Creator - everything is free BTW.
If the code already exists for the STM, is it written in C or C++?
Or shall I just stick with the original processor?
What other changes could we put in? The setup where the connector for the iron gets put in the front panel and then the PCB is soldering onto it is terrible IMHO, how the heck are you supposed to maintain it?
-
The setup where the connector for the iron gets put in the front panel and then the PCB is soldering onto it is terrible IMHO, how the heck are you supposed to maintain it?
Oh man I hate that as well. It isn't a problem to put it together but I've had to take 3 apart now and desoldering that chunky connector from the PCB is a real pain. Structurally it makes sense because everything is held together pretty well but using a header connected to the panel jack by itself is a lot more of a serviceable solution. My main iron has a header on those TSGEN pads and it makes it trivial to replace the board, but then the PCB just sort of floats inside, connected to the case only by the encoder... which is at a bit of an angle.
STM32 is a very popular platform for its low cost and high performance / available peripherals. I think the IDE is just confusing because we're unfamiliar with the toolset and there seems to be more tools than you can shake a stick at. I think ST is trying to address that with STM32CubeMXIDEetcetc by bringing everything into one frontend although it still is a little rough around the edges. The debugger interface with just a cheap ST-Link is also pretty good and makes it pretty accessible and it works a lot better than the AVR debugger interface (that white box thing I can't remember the name of that I rarely break out).
-
If I had a clear instructions how to just directly compile the src folder in linux from the cmdline using C compiler and flashing with OpenOCD instead.... then that is what I would do.
However there are no CMAKE or other traditional Makefile / build chain there to be found. Only whatever those ST Project files / Eclipse IDE.
However the stm32cubemx does have some useful feature in it. Just sadly still linked to that other workspace / eclipse IDE stuff. Which is rather a shame but heh it's likely somebody hanging out around the OpenOCD project has had same ideas to parse them and figure it all out.
The thing about the 'Workspace for STM32' skinned Eclipse IDE program is that its so-called 'latest version' is from ubuntu 14.04 days. All ancient, like the whole thing was left forgotten in a ditch for several years. Which is why it would be great to keep the newer CubeMX tool thingy but try do away with the other one.
Maybe not possible due to ST being total [redacted]. But one can dream eh?
:-//
-
So is the code in C or C++?
-
So is the code in C or C++?
Sorry for not answering earlier... it seems to be a fairly reasonable and straight C as you can see in the repo here on the flawless_testing branch.
https://github.com/luckyTomas/stm32_soldering_iron_controller/tree/flawless_testing/Src
:-+
My thoughts about it:
In regards to your recent suggestion to move the project onto a different platform:
* The main thing to realize is that there seems to be a heck of a lot of code in there for the control loop, dynamically adjusting temperature, calibration stuff etc.
* So therefore if you wanted to move it to a new platform the general expectation of what you would be doing would be 'much more of a porting effort'. To keep that stuff and translate it over. Now I don't know the specifics or how relyant this well developed code is on features that are specific to the STM32 family. So YMMV. I am just guessing that devil is in the details of it. I have not myself the knowledge of what they do down in there. At those level.
* Otherwise (if not possible to port because it's too specific to STM32 hardware features). Then having to throw all that stuff away and redo it. Which is to say I look online and keep stumbling over many other people (quite a few, it is no exaggeration) who have done just that. And ended up with independent firmware coding or re-implemented for that build again the control loops etc. BUT so many of them fail in the performance being so so and the heat up time (from cold) to working temperature being in the laggardly range of 9-12 sec. Wheras the true capability and performance of a JBC (T245) cartridge is in the order of approx. 3 seconds. And this is by far the exception than the rule.
In fact there are only about 3 projects I am aware of which *might* have the real world performance I am keen for. (i.e. a similar performance to a real JBC station). In regards to *this* project, it's been commented by somebody else that the PTDreamer firmware is better performing (or less slow / whatever) than the KSGER closed firmwares available from KSGER. However I am not sure of the performance myself.
One other project is a cheap Russian style job (or Romanian rather) uses an ardiuno for the micro and has a cheaper BOM and everything. That one has a video of decent heating performance. The DIY kit is simpler, and you are doing things in a very 'from scratch way'. Unfortunately the guy hasn't open sourced his firmware. And for a long time. Which I feel is a shame. And why I am so interested in this project instead for STM32. (and also to buy a premade controller than build from scratch has it's advantages, and being not-Romainian everything, searching for clues in the google translate etc).
The third and final project is some clever Turkish guy who is selling his units with international shipping. And also has a video demonstrating a great performance. 3 sec with a 10 amp draw @ 24v. His units are significantly more expensive though. More like $70 - $100 depending on specific options etc. But he did a nice professional looking job of it all.
So in summary:
* Do we need yet another different platform that somebody else likes just because it happens to be what they are familiar with?
Well arguably no, because the main benefit of this project is still an option to buy a premade controller and flash it with a .bin. Hehe we are having trouble in that area but maybe it's not enough to move platforms. Since we want to leverage the existing community efforts that have already been going on. For example if nobody else is familiar with that other new platform then er... perhaps it's not actually going to encourage the broader participation from others. And shut them out.
Maybe the performance side also comes under question. Because complications can occur for redoing those complicated stuff onto the other platform. Which is not exactly a known sure thing until it's actually done, and working on the hardware.
Also because we would have to spin out a different PCB and assemble it. Well heh I already have all the parts needed for the Romanian guy project here. Unfortunately his code is still closed source as it has remained so for some time. But it's also a freakkin arduino with literally the fewest possible moving parts. So much simpler than anything else out there. So that would kindda make more sense from the reason to 'avoid ST over complicated stuff and have things simpler, easier'.
You definately cannot port some complicated ST code over to arduino though. If the porting idea is such feasible one. IDK if it really is though... you will need look more carefully in the code. Browsing the commit history is useful to see what those 2 guys were changing there most recently in respect to the algorithms etc.
There you go. I would still expect it's probably path of 'least resistance' to try flashing this v2.1s or modify it should that be necessary for a difference in the layout. And you know... it's already the biggest community project of the 3 options. And the only one with an open source code. All big pluses.
Don't let my complains about ST toolchain stop us here because maybe it's a solvable problem somehow. We have not had enough time to figure it out yet.
We just don't need to take away from those main PROs to this project. Unless it becomes apparent that is in fact really necessary.
===
For other Guy:
(sorry I confuse the 2 of you here, which is which)
Redoing the PCB to make it better is surely a great value though. It may help to get around compatibility issues or issues of finding / buying the wrong PCB. Plus the reliability improvements to the PCB itself. Finally for people like myself, also to just transfer most of the components over from 'crap PCB' --> onto 'good PCB' is also less wasteful. For everybody who already has wrong version. This is also pretty useful!
-
I'll give a longer reply tomorrow but I wanted to say that I don't really want to be responsible for maintaining the software but I am happy to be in charge of the hardware. But, if no one wants to, or is able to maintain the software then the project might not be worth pursuing. I am able to port the software across if it's written in C and I am capable of maintaining it.
-
Oh hang on now. You have a way to get back to stock? I still haven't flashed my daily-use soldering iron because I am afraid of losing the original firmware when I turn off readout protection. Do you have a source for the stock firmware?
There is a way to get back to stock. You need to find the original firmware. Given that it's property of KSGER it's not something I can just post. I learned this when asking for guidance on a flir project. I was told "search" hahah so yah while I am new here I don't want to get on the wrong end of the eevblog hammer :D
Simply put there exists a multitude of original firmwares, about 27 if I counted correctly, Some labeled as KSGER, some T12, some labeled as hako and desolder and combo. Thanks to a screw up (or intentional?) on a subdirectory someone forgot to disable directory browsing. I was desperate to find "any" firmware I could once I got the beep of doom haha took me about an two hours of searching but eventually found one firmware made the beeping stop but had garbage on the display. I took the trailing file out of the download in hopes of finding a webpage that would explain what they were attempting to do and a directory listing just came up with a bunch of files.
I kept trying different ones until I got somewhere that looked like I was making progress. Eventually I was greeted with Chinese Writing asking for a code.
Which then began the next game of duck hunt. hahaha
You can find lots of information here.
https://medium.com/techmaker/reverse-engineering-stm32-firmware-578d53e79b3
https://weekly-geekly.github.io/articles/350602/index.html
The top link will help you learn how to get your hands dirty, the bottom one will show you that it's been done before. :)
I hope this help.
-
It's too bad they refused to go open-source but then they would have too many competitors.
My understanding is KSGER original firmware is copy-protected two ways.
If you re-flash, you need to run a keygen. I saw the guy disassembling the bootloader lol.
Also I notice they move I/O pin assignments around on pcb revs, and sometimes ground an I/O pin as an identifier the pcb is matching.
If you think about it, their firmware is their main IP and copying of these soldering stations is rampant.
The original firmware has an RTOS, I'm not sure which one but it explains the clunky UI.
-
Have figured out today how to compile from sources the latest version of the PTDreamer firmware. I was opening it into the wrong Program... 'ST workbench' is now replaced by STM32CubeIDE. They are both effectively the same thing (a skinned Eclipse IDE).
So what I am doing is trying to document (as best as I can), all of the steps required into the README.md file. Then upload that to Github. And submit the changes as a PR to LuckyTomas. Unfortunately I have not heard back from those 2 guys after emailing them yesterday. The last activity on the source code was back in February this year.
In the meantime here is the compiled .BIN and .ELF attached. Of course we didn't check it / try it yet. Or map the pins for the other version of the PCB. So YMMV.
Personally I would suggest to try to backup the OFW before flashing. But of course you guys are talking about copy protection, keygens, etc. Which all gets in the way of that process.
I have also included a warning message in the updates to the README file. Showing clearly (with photos) which one is which. Since they are both labelled as "v2.1S". I think that is going to be clear enough in future to anybody else downloading the source code. Being right there in the README.md. However it still does not find us where to buy the correct version online. Or if it's still even available.
:-//
Will report back after finishing these changes / raising a PR on github.
-
https://drive.google.com/open?id=1qLmAF7NNqVy2zQ2gsIhTnrgWpaj_WG1P (https://drive.google.com/open?id=1qLmAF7NNqVy2zQ2gsIhTnrgWpaj_WG1P)
https://drive.google.com/open?id=1O8wgvWNmMEFCBCkaGRfy-erHNlp1qiX6 (https://drive.google.com/open?id=1O8wgvWNmMEFCBCkaGRfy-erHNlp1qiX6)
-
Thanks for those schematics etc.
:-+
BTW I am debugging my SWD programmer now because i cannot seem to get SWD conenction to either of my boards (the 3.1 or the 'fake' 2.1S).
It is beginning to look as if the board is pulling the SWK_CLK (clock) whenthe programmer is attached. So if theres any other tricks, other than simply connecting to the 'C D V G' swd header then pls let me know. Thank you.
Simply cannot get any SWD connection working to these boards yet. My first time.
-
Tested and confirmed. It worked on my board. Thank you.
-
Tested and confirmed. It worked on my board. Thank you.
Can you be more specific please? About what you are referring to? BTW thanks for those files (not that i have had time to look at them yet).
:-+
-
I tested the file you posted it worked on the board I posted earlier that did not work. I’m sorry I never sent the files I was afraid of getting into trouble. Floobydust posted a few links which have a lot of the files I saw earlier. I just wanted to say thank you. It was your file that worked while all the other ones didn’t.
-
I tested the file you posted it worked on the board I posted earlier that did not work. I’m sorry I never sent the files I was afraid of getting into trouble. Floobydust posted a few links which have a lot of the files I saw earlier. I just wanted to say thank you. It was your file that worked while all the other ones didn’t.
This is very good news yes? Because I have not flashed yet. I am not sure which PCB excactly you are talking about here. I know its back in thread somewhere but have not had time to look can you please get link for us to see? Thank you so much.
[edit]
...Also if you tester with a T12 or T12 tip? Or a JBC tip? And what was the heat up time from cold iron to working temperature?
I ask because a lot of those recent activity on the source code seems to be around those control loop algorithm. Thank you again.
:-+
-
Here was my post regarding my board. https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3076054/#msg3076054 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3076054/#msg3076054)
I have only tested my stock ksger tip on it. I have a 10 pack of various t12 tips coming in Monday. Heat up times are quick. About 8-12 secs to hit target temps. I’ll make a video comparison between the two when I get my tips in on Monday for your observation. Would be great to see how it turns out! Getting new toys in the mail everyday. Your cfw adaptation is icing on the cake. Thank you greatly.
-
Here was my post regarding my board. https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3076054/#msg3076054 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3076054/#msg3076054)
Ah this is the version with aliexpress listing claiming 'v2.1S'.
https://www.aliexpress.com/item/32891292698.html (https://www.aliexpress.com/item/32891292698.html)
I have this same PCB here just cannot flash it yet due to some other technical problems. I would very much like to be 2nd person to do this. And to confirm your report. (Which is different PCB than what they had shown originally in github https://github.com/luckyTomas/stm32_soldering_iron_controller/blob/master/schematic/Ver2.1S/t12-stm32-controller-back.jpg (https://github.com/luckyTomas/stm32_soldering_iron_controller/blob/master/schematic/Ver2.1S/t12-stm32-controller-back.jpg))
If I can confirm that it works (indeed!) then i can add information about its compatibility to the github. Instead of saying to people to avoid it.
So for flashing: I might need some help. For example what programmer and software do you guys use?
For myself (so far)... I can see my programmer (TUMPA v2 over openocd) seems to send some pulse trains over its SWD 3 wire when not connected. But when I connect up to the 'CDG' pins on stm32 T12 controller PCB. I hold NRST low or connect it to the NRST on my programmers SWD header. The target PCB is powered independantly with 24v and I can see NRST affects the device. It freezes and unfreezes.
Unfortunatly the clock line on the SWD measure 0.95v on my basic multimeter and i cannot get a response from target in openocd output. So my SWD connection fails. This was about 4 hours of frustration yesterday night.
Perhaps I missed some step to cut trace or modify the PCB? Same seems to happen on my other v3.1 board.
:-//
About 8-12 secs to hit target temps.
Perhaps that is expected for a T12 tip? However that I feel is not the best. The gold standard is 3-5 seconds on a JBC tip. Which is to say something like 8-10 amp draw from the 24v supply. As per this other youtube video (other guys $100 product).
https://youtu.be/fvIjh8lIlpw?t=87 (https://youtu.be/fvIjh8lIlpw?t=87)
And this is really the thing we want to be aiming for. Or otherwise at least try to understand why its not possible. If there is some limitation. This also plays into the idea to make our own PCB version... we do not wish to handicap ourselves by copying an existing schematic if that design has a flaw that prevents a higher speed of performance (more current draw, more power to the tip).
About 8-12 secs to hit target temps. I’ll make a video comparison. Thank you greatly.
... hehe :)
if you are going to make video do you also have access to a power meter plug? To measure the watts. Then please plug that in to the socket / PSU. And put next to the iron. It will show us the watts power draw / consumption from the mains. As it is heating up. Thank you.
:-+
In meantime, i try to understand SWD and how to be flashing it. The has been support and help from OpenOCD (Paul Fertser) who I am very grateful for.
:palm:
-
Oh BTW another new project. It might be worth to start a new thread
https://www.youtube.com/watch?v=g8tazMAGKFA (https://www.youtube.com/watch?v=g8tazMAGKFA)
that one is arduino based (328P) MCU. The mosfets and transformer looks nice. And in the youtube comments is link to its github repo. For open source files HW and SW
https://github.com/Canonius/JBC_Soldering_Station (https://github.com/Canonius/JBC_Soldering_Station)
Its still new project. So i do not think they have compatibility yet for all the other JBC handles such as T470 etc. And heat up time is 6 second. Still it is the most promising other open source project. As the other simple Romanian arduino design (by 'xDadu') remains closed source AFAIK
OK I made a New thread about it here:
https://www.eevblog.com/forum/reviews/dual-jbc-t245-compatible-300w-soldering-station/new/#new (https://www.eevblog.com/forum/reviews/dual-jbc-t245-compatible-300w-soldering-station/new/#new)
To keep this thread free from those further discussion.
-
So, if the IDE setup for STM is so bad, what if we changed the processor to a Cypress PSoC 4000? The PSoC Creator IDE is great and I can get code running PDQ in that environment. Annoyingly, Cypress are now migrating to a new Eclipse-based IDE called ModusToolbox and I'm struggling to get anything other than the canned examples working but the PSoC4000 is all still done using PSoC Creator - everything is free BTW.
Hey again... here is the thing that I have been slowly realizing today. Whilst investigating other STM32 parts... their whole platform is not necessarily bad because of the software side. After getting to know the right development tools and support it is OK to use in 2020. And there is a wealth of support and knowledge out there. What I see now letting it down is the many different specific hardware versions and "variants of versions" out there. So (to cut a long story short) not only do ST silently for example remove a DAC, in the 'value version' that carries the same name. Or they rebrand a 103 as a 100.. there is also these 'GT32' clone chips now by LTSC which also themselves have subtle different hardware changes under the hood. And that creates a sort of hell of incompatibilities with so many SKUs, and if you order a specific chip, lets say a CBT8 variant from aliexpress. And its not actually quite the same. Then something is broken vs a differently sourced chip. That I think is the true hell of STM32 platform.
So yeah... I do see more value in switching to a different platform. Now that we have newer processors out there. Thing is though... Cypress PSoC 4000? Really? That seems to be based on cortex m0 and it's not one of the more mainstream micros that everybody knows about. And you say here they move to eclipse also. In fact the only feature that really seems in it's favor is that you personally are already familiar with that platform. Well there is nothing actually wrong with that if the intent is for some kind of a pet project.
However my previous criticism still stands that a platform for the broader community is going to be a platform that is better know and more familiar to the broader community. So if not STM32, then what else? Well it strikes me from that perspective. (to start from scratch) then something with the following characterics:
* Faster, to have a higher performance. Both for driving the screen and also reacting to the tip / driving the mosfet(s)
* Has very few different SKUs / variants. To avoid confusion around subtle hardware incompatibilities.
* Popular to the community
* Cheap - that anybody can afford to risk / break
* Easy to source worldwide
* Has good development tools, good
support (a mature platform, which is not buggy)
And really the only platform i can actually think of which satisfies all of those requirements well right now (2020) is ESP32. It also has 2 cores so potentially can drive the display off a different core than thesoldering tip. So as not to be any bottleneck or compromise one for the other. Also it's coremark score of about 400+, it has some precise timing capability. All are a good fit. It seems to tick all of the boxes above. Its cheap enough and mature enough to be a safe choice. And have such a large and enthusiastic community for getting (the most possible) other people to take an interest and want to contribute, help with the efforts.
IDK there must be some drawbacks come along with that too. I cannot think what they are. If somebody else has something negative about ESP32 platform specifics. Then it's nice to hear it. Otherwise it's going to be my new search term going forwards! Since there are many new JBC controller projects like this out there. They just keep showing up!
-
LOL, as you were coming around to moving away from the STM32, I was starting to accept that it's an OK processor. The PSoC4000 isn't a very good choice given it's an m0 but there are others, the PSoC5 is nice but it's stupidly expensive. The PSoC6 is dual core (M4 & M0+) and I do have some LQFP100 samples, there's also modules like the CYBLE416045-02 (https://www.cypress.com/documentation/datasheets/cyble-416045-02-ez-ble-creator-module) which is FCC certified with BT 5.0 that would allow remote control :D
If you're willing to work the firmware, I'll do a PCB design with whatever you want in it, I have most of the PCB components ready to do a design.
-
Interestingly I also asked today on other opensource project what they think about MCU choice, and if ESP32 is good (or not) since it is indeed popular atm amongst hobbyists. So here you can see linked that other discussion in case its helpful to you:
https://github.com/Jan--Henrik/Otter-Iron-PRO/issues/5
As for me I have simply ordered some RCT6 today on aliexpress. And paused working on it anymore until they arrive. Which should take anout 1 month to 6 weeks. Then can replace the original chip with a new blank one. To keep the original spare, because it has the original firmware on it. For backup purposes. Since it (turned out) it was not any one of the 'existing 27 known OFW firmwares'. Therefore cannot back it up any other way.
Then (eventually) can flash that same existing fork of the PT Dreamer firmware and confirm that the other guy said. Except also mod the pcb for the JBC T245 tip. It's no big deal really.
-
I noticed the JBC option on the T12 controller PC boards looks like they are doing it incorrectly -
You'd want to remove the 0R resistor to disconnect heater(+) from the (Hakko) thermocouple input, for the JBC thermocouple lead. Like in this schematic?
OLED-V3.0 has a R0 not populated, which is still wrong I think, wrong pcb traces. You have to disconnect the TC amp from the heater for JBC compatibility.
-
Do you have JBC T245 pinouts? I see mention of a Hirose RPC1-12P-6S female connector on the tool, but a Binder series 678 on the station side :-// so different pin# assignments as well. It's confusing.
After I will add that and uprev from 1 to 2 the T12 V2.1S schematic, with the correction on the 0R+jumper.
The original 2.1S design has some H/W errors and if those were fixed then it's a good schematic to build- if the world ever makes open-source F/W compatible with these T12 STM32 controllers.
I originally drew that schematic as I was repairing some, so not sure about putting it in a repo. I saw so many versions with mistakes galore, mostly from copycat builders.
-
Do you have JBC T245 pinouts? ..It's confusing.
Hey it turns out that after 'surfing everywhere else' there is in fact some guys here on our own eevblog forum. Who have made an excellent explanation about these JBC tips. If you jump to their thread. It has been pretty well documented over there (for the tip by itself).
:-DD
https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/ (https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/)
-
If a custom/PTDreamer compatible board idea is still proceeding, in Post #113 you asked for suggested features, one I have not seen that I would recommend is, for the FW have the option to select between the Hakko style and JBC style handles rather than having to re-flash, which is what I think the PTDreamer's FW requires if I have read through this thread correctly. Perhaps you still have to have a physical switch of some sort on the board, but at least not having to re-flash the firmware every time you want to use a different handle would be a step forward, IMHO. Just a recommendation/thought, I have not seen it discussed here and like I said, from my reading of the thread, if you want to change from one handle to another, you need to re-flash if you use PTDreamer's firmware or some version of.
-
Hello.
I have all the staff to do the flash but www.ptdreamer.com (http://www.ptdreamer.com) is not working.
Someone knows if the webpage changed?
Thank you!
-
I believe the original FW code was saved in a directory in the link belowfor backup purposes by a member here on EEVBlog, DreamCAT (though you may need to go up to a different directory level than this link puts you at):
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#v21s-original-version-green-pcb
Also look for "Lucky Thomas" on Github, going through the various threads here on EEVBlog, it seems LT has made the most recent code changes to PTDreamer's firmware, at least publicly, it's still possible others have made more recent changes that have not made them public. :-//
-
Here TotalNoob,
Yeah the guy emailed me yesterday. Which prompted me to finally merge all the LuckyTomas flawless_testing branch on to my master branch. Did that yesterday. Along with pushing up a few other minor updates.
Mostly because then people can find my fork, to make it easier to find the newer code. 2ndly for any future updates going forwards too. So they all gets merged together in the same branch. Since LuckyTomas himself is just not possible to contact him.
BTW sorry that cross link (to other repo) you mention here now: it was something forgot to do yesterday, have it pointing to dreamcat4/master branch now. It's same code + no worries
https://github.com/dreamcat4/t12-t245-controllers-docs/commit/c0f415004fb1522f9e149b46e2e3beae909cf9c6
Also backed up the original PTDreamer blog articles. Since his website went down recently. All saved / backed up. In my docs repo. The mirrored pages were saved with 'SingleFile' extension on Firefox.
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/research/ptdreamer
Hopefully any other specific information that people are looking for is not too hard to find. As there are quite a few different pages of stuff. It goes on and on. Lots of stuff gets dumped into the 'Research' folder if it does not have a clear and well defined category.
Please use the Docs to follow your research interests. Github issues is enabled on both the docs repo and the source code repo for the open firmware. For anybody wishing to ask questions, give feedback or have further suggestion or whatever else. You can instead contact me here on eevblog. Or by direct email. However you prefer. Here to help.
-
One other thing, check out the thread looking for the 3.1S software. If you have one of the "new" 3.1S's, beware. Others have said that KSGER is or may be encrypting/copy protecting their firmware and that you're better off flashing a new chip and desoldering the old, solder on the new, that way you have the original FW backed up on the original chip. Not sure if KSGER is encrypting/copy protecting the firmware of the "older" versions (i.e. 2.1S and 2.01(?)), that they are still selling, so this may not apply to those, but you may not want to take a chance.
-
Yeah I said that. They have all been protecting the program flash on the chip since the very beginning. It's an integral feature of these STM32 arm cortex mcus.
On the F103 series the copy protection mechanism cannot be fully broken. So there is no easy way to dump the firmware from the chip. Not without power glitching the MCU which is both difficult and requires special equipment and expertize, time patience.
On the earlier STM32 (before F103). The F100? I believe. That was an earlier revision. And it was possible to get around the copy protection. Before ST found out and partially fixed that feature on their later chips. However those older MCUs have not been used in these STM32 OLED devices for a long time. Not since the early days. Like v1 - something. Which nobody sells anymore.
It is therefore a lot easier to just physically remove the MCU. And keep it as the physical backup of the Original Firmware / Commercial Firmware. Since replacement chips are pretty cheap and easy to get hold of. Only a couple of dollars.
People have found the original firmware online for certain versions of hardware, around versions v1-v2. However after v2 KSGER made some licensing deal with the original Chinese author of the firmware (it was not made by KSGER originally, they simply aquired the right to use it later on). So the KSGER v3 firmware is a build which has been since modified in house by KSGER. Therefore there was no 3rd party channel to get hold of any such v3 firmware and nobody has a copy of it.
Of course if somebody is wholely obsessed. Then it's entirely possible to dump these images using the black art technique of power glitching the MCU. However I am doubtful it's really worth the effort compared to simply desoldering the MCU and then keeping that safe.
Since we can always instead try modifying / improving the open source firmware (by PTDreamer). In order to extend compatibility to more different PCB designs. And that is probably the better use of time. It provides a greater benefit to the community.
-
I was responding to Postman to warn him about trying to flash the existing chip. I knew you had a lot of knowledge about the copy protection, far more than I.
About the PTDreamer FW and variants, while I am not against modifying it to use with other designs, but wouldn't it make more sense to settle on a design that it works with? One I am thinking of is where you discuss the variants of the KSGER "2.1S's" in your Github repository there was a "2.1S" version that was built cheaper than the earlier "2.1S's" but with built-in compatibility for a JBC iron, that was shown to work with either the original or a variant of PTDreamer's FW. I would think it would make sense to base the PCB design on an adaption of that design, but use quality components, and then efforts could be concentrated on the firmware, working out the bugs, adding features, etc. But that's assuming the STM32 chip used in that variant is still readily available and will be for some time, if that's not the case, then I can completely understand why that approach may not be possible at this point.
-
Do you have JBC T245 pinouts? ..It's confusing.
Hey it turns out that after 'surfing everywhere else' there is in fact some guys here on our own eevblog forum. Who have made an excellent explanation about these JBC tips. If you jump to their thread. It has been pretty well documented over there (for the tip by itself).
:-DD
https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/ (https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/)
I just updated T12 V2.1S controller schematic Rev. 2 - added JBC pinout and fixed the JBC thermocouple breakout, my pcb has the mosfet trace on wrong side of R11, drove me nuts.
https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/msg2463234/#msg2463234 (https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/msg2463234/#msg2463234)
I was looking today and found a handful of different JBC wand schematics and even a thread arguing about it :palm:
Point is that board V2.1S is a good base if the H/W design bugs are fixed: Remove battery draining 10k and diodes, fix trace on JBC thermocouple option R11 or R0.
-
Thanks Flooby for updating the schematic. I have uploaded a copy of it to my 'docs' repo on github. So that it is organized and easier to find allong side all of the other research materials:
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#blue-pcb-ve21s-r2-ksger-version-lwfp-64 (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#blue-pcb-ve21s-r2-ksger-version-lwfp-64)
https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/ (https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/)
found a handful of different JBC wand schematics and even a thread arguing about it :palm:
Were you referring to those wand schematics which I already found? Or are there some other ones elsewhere, which I have missed? Please see here my research folder and let me know if you have any more to add:
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tips-and-handles/t245-c245 (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tips-and-handles/t245-c245)
Again it is for the same reason - so people have 1 central place they can find about the tips / handles. I gather it to there. There are seperate folders for T210 and the T245.
I am especially hoping for more research on the other JBC tips. For examlpe: T470, and also the "NASE Nano" (=C105 cartridge). And also the JBC Tweezers. And the Hakko Tweezers.
This is important research to gather for future. To see if it's possible to make a better controller. Thanks.
-
I posted this on another thread since I had indicated I would. I am also going to post these here so that this thread can consolidate the information in one place.
I just received my "V3.1S" Attached are photos of the controller. The first is intended to be a high res photo of the controller built up using 3 close-ups that are pieced together using Paint 3D. I did this with the idea that it would remain legible at higher magnification. It's not perfect, so you may see some inconsistencies between the "joints". I also took a single photo of the controller. I also took a closeup of the STM32 chip, but that may have to go in a separate post due to the size of the photos.
-
Just like I thought. Here's the third photo.
Edit to add: I just did a bit of testing, since I have not seen it mentioned anywhere else, but that's not to say that I might have missed it. Since I had the controller and front panel off, I ran 12V power to it from a power supply (wall wart charger for something) to see if the controller would power up. It did. From what I understand about the JBC soldering station, the C245 handle uses 24V for power and the C210 handle uses 12V for power (which is believed why when a C210 handle is used in a C245 compatible clone, you burn up the tip) and that the "6th pin" is how the unit is able to determine which handle is plugged in (i.e. if its populated its the C210, otherwise its the C245). If this is true, and the KSGER controller can be powered with 12V and still provide appropriate temperature control and sensing (I am not able to test that, the power supply I had was only rate at 1 amp), then it seems plausible that flashing with an offshoot of PTDreamer's FW specifically for the JBC handle, you may be able to use either handle if you have a way to switch between providing 24V or 12V to the controller. Just some food for thought.
-
just received my "V3.1S" Attached are photos of the controller...
:-DD
LMAO. If you follow this link, you will see that your PCB is missing a silk-screen to say: "OLED-V3.0". This is why the KSGER versions schemes are utter garbage.
https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/r3/back-low-res.jpg
They just make up whatever version numbers they feel like on a whim. There is no rhyme or reason to it.
BTW i have labelled this PCB as "v2.1 r3" for "revision 3" since it is remarkably similar to the v2.1 rev2. They seem to only have make some minor changes. See for yourself:
https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/r2/back-low-res_mods_for_JBC-T245.jpg
So in regards to compatibility they are not the same indeed, the circuit should be mapped out. But it's not earth shatteringly different either.
-
BTW thanks for the photos... will version them and include them in my git repository allongside the other ones.
Really dig what you are saying about compatibility. It's highly likely that doing some little mods onto these boards should help quite a lot. Perhaps also modifying the open firmware a bit too. To add some kind of extra tip detection feature(s).
All for extending the compatibility past the T245 to also the other jbc tips. (Not only the T210)... also the NASE ("nano"), the larger T470. And perhaps tweezers if its worth it or at all possible. Have been told that JBC tweezers are 'crap'. Because they don't come together tightly (the slop in the hinge). However they have 2 different types of tweezer. And I am not sure which one was being reffered to at the time. In addition Hakko also has their own (different) tweezer...
Really any of these additional cartridge types would be a great addition. And even better if we can have swappable. Too bad I don't have the time set aside for any of this. Instead have determined my role to be first "gather all technical research data and infos" together in one place. That is all going up on github. So that they can be more easily searched by anybody who is insterested. This includes the "gathering" of a 100 page forum thread. To be searchable on 1 page with ctrl+f. Those Russians always at it. Can't help themselves. And have accrued more knowledge than pretty much everybody else.
-
BTW thanks for the photos... will version them and include them in my git repository allongside the other ones.
Really dig what you are saying about compatibility. It's highly likely that doing some little mods onto these boards should help quite a lot. Perhaps also modifying the open firmware a bit too. To add some kind of extra tip detection feature(s).
All for extending the compatibility past the T245 to also the other jbc tips. (Not only the T210)... also the NASE ("nano"), the larger T470. And perhaps tweezers if its worth it or at all possible. Have been told that JBC tweezers are 'crap'. Because they don't come together tightly (the slop in the hinge). However they have 2 different types of tweezer. And I am not sure which one was being reffered to at the time. In addition Hakko also has their own (different) tweezer...
Really any of these additional cartridge types would be a great addition. And even better if we can have swappable. Too bad I don't have the time set aside for any of this. Instead have determined my role to be first "gather all technical research data and infos" together in one place. That is all going up on github. So that they can be more easily searched by anybody who is insterested. This includes the "gathering" of a 100 page forum thread. To be searchable on 1 page with ctrl+f. Those Russians always at it. Can't help themselves. And have accrued more knowledge than pretty much everybody else.
You are welcome for the photos, it was my dream to be immortalized for something in my life. :-DD Anyway, yes, that is what I was trying to do. I am not familiar with those Russian sites you are referring to, and I'd probably not understand what they said anyway, but I know that one thing that I have not seen referred to in any of the threads on the subject of these KSGER's is trying to run 12V through the control board. I thought of it after seeing someone mention in the comments of, I think it was, one of Equalizor's videos that the reason he burnt up a C210 tip in his Jabe UD1200 was because the C210 tips were 12V and not 24V like the C245's. I have no way of knowing, I don't own any JBC equipment, so I can only go by what others state.
I can appreciate that you don't have time to pursue this and I do appreciate your initiative to gather all the information. I'm not really an electronics person, I only need a soldering station for occasional use for repairing electrical connections on equipment, in this case that I used to justify finally getting a good (I hope anyway :-// :-DD) soldering station and retiring my fixed soldering iron is to replace the Klixon overload on my RAS I am restoring. It was mentions on your Github about JBC compatibility with both newer versions of the controller having "built-in" that capability (with modifications needed to use it) and mentioning that PTDreamer's FW allowed the use of JBC handles, that led me down the rabbit hole of finding out more and why a JBC handle is more desirable than the T12 handle. :D But I figured, I could try to contribute what little I can, being a non-electronics person. And while I do understand why you would like to extend the capabilities past just the C245 and C210 handles, that is where I must "tap out", at least as long as I have no real need to use anything like the C470 handle or tweezers, but I don't blame those who do use those for looking into whether they would work with these controllers.
-
just received my "V3.1S" Attached are photos of the controller...
:-DD
LMAO. If you follow this link, you will see that your PCB is missing a silk-screen to say: "OLED-V3.0". This is why the KSGER versions schemes are utter garbage.
https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/r3/back-low-res.jpg
They just make up whatever version numbers they feel like on a whim. There is no rhyme or reason to it.
BTW i have labelled this PCB as "v2.1 r3" for "revision 3" since it is remarkably similar to the v2.1 rev2. They seem to only have make some minor changes. See for yourself:
https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/r2/back-low-res_mods_for_JBC-T245.jpg
So in regards to compatibility they are not the same indeed, the circuit should be mapped out. But it's not earth shatteringly different either.
You're right! I never even noticed that it did not have the "OLED V3.0". :o |O :palm: As discussed earlier in this or another thread, with other changes to the PCB, was this another "penny saving" measure? :-DD
But I did see that you labeled it "V2.1 r3" and that you mentioned in that folder that it was referred to here as "V3.1S", which is how KSGER refers to it on their Aliexpress site. But, yes, that means nothing, really. If you look at the board photos on one of the newer "KSGER V3.1S" threads, did that person's controller have the "OLED V3.0"? I need to check right after I hit "Post". :-DD
Edit: Ok, I had forgotten the OP's screen name, but it was ACECool's thread and yes, his photos do show the "OLED V3.0" on his. However, he has a slightly different unit than I do, I have the thicker aluminum front plate, his appears to be the thin, black, (aluminum?) front plate. You wouldn't think that would make a difference, but perhaps the style I bought was more popular and sold out quicker and thus mine is from a second batch of "OLED V3.0"? Purely a guess. I bought mine from "KSGER Official Store" on Ali, I see there are three different "KSGER" stores, "KSGER Welding Tool Store" and "KSGER T12 Store" Each one is a little different and while there a lot of overlap in products there are some differences.
-
That is even more humorous. I never realized that were multiple 'official' KSGER stores. And 3 no less. It only ever gets weirder the closer you look. At some point certain things click, but not others.
I mentioned the similarity of your PCB to the v2.1s r2 because it suggests that your v3 might be doable for the PTDreamer open firmwar (the LuckyTomas fork for v2.1s, this is now set to my master branch). Since they are so similar.
I expect the reason for this further revision will become aparrent after mapping out the differences. Perhaps KSGER realized the v2.1s rev2 had both bad opamp and bad 3v3 vrm switching converter on it. And decided to improve that aspect? Well IDK myself. But its not too hard to just look up those 2 ics part numbers and check them online.
I certainly have to replace those parts on mine.
BTW i'm sure youve noticed in my other folder there are 2 over so called 'v3x' pcbs. Neither of which is anything like yours. So that is really a big reason also why yours has been labelled as 'v2.1s r3'... just to try to avoid confusing it with the other v3 ones.
BEARING IN MIND that in this screwy world its actually the v2.x series which are more revered / trusted models. Being older and closer to the original v2.1s is a more desirable thing. Crazy i know. Oh well.
In regards to the research I collect 'any useful infos' from 'all places'. So long as it does not directly infringe on the original product (eg the actual JBC stations and their reversed schematics etc. is omitted). I do that for mostly the reason that it's not necessary. Since there are other possible schemes to power an original JBC cartridge. Its only the investigation of the cartridge itself which is really required to know and develop a product for. Something which many others have already done at this point.
I am still collecting. Not everything is up online. But I just wanted to point out (in the meantime) that there are versions of the original closed firmware that already support powering JBC C245 tips. And so your station being newer perhaps might already support that. Without requiring you to flash the open firmware first. BTW you could actually make your own handle here is an example
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tips-and-handles/t245-c245/diy-handle (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tips-and-handles/t245-c245/diy-handle)
However that is not the one i was referring to earlier. I do not have a link. Maybe look in the comments section of the mysku.ru review pages instead. Not the review at the top... look in the comments thread underneath each review. Some words dont translate well from russian. So using ctrl+f for searching can be a bit difficult. e.g. 'tip' --> might appear as 'stringer'. And so on.
Otherwise I have not remembered where the original discussion about the better t12 handle was. However I have (for sure) found it now in my aliexpress bookmarks. It is the version in the listing below identified as 'handle 5'. From the product selector images.
https://www.aliexpress.com/item/33004762167.html (https://www.aliexpress.com/item/33004762167.html)
To be clear; it is the Silver (aluminium) handle. But also with the green foam soft grip over the fingertip area (aka looks like they tried to copy the jbc green soft grip). And to be clear; i myself have not aquired that accessory myself yet. It was just recommended by some other people I came across during my research. After some remarks like 'all the other handles are junk'. Or whatever they said about it. You get the picture.
Hope it helps. I know its probably not the cheapest T12 handle out there. But probably well worth the extra cost, given how important the feeling in the hand. And how much you expect to use it.
In regards to the 12v thing. I cannot remember right now but there are probably other better ways to limit power to a c210 cartridge. Rather than lower the psu voltage, just change the maximum pwm duty cycle when the t210 is detected. That should also work. Actually i believe the reason is probably more to do with the thermocouple being entirely different. Both the thermocouple wiring and the coeffecient for the formula. Better details about those tips in this thread:
https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/ (https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/)
-
https://www.aliexpress.com/item/33004762167.html (https://www.aliexpress.com/item/33004762167.html)
To be clear; it is the Silver (aluminium) handle. But also with the green foam soft grip over the fingertip area (aka looks like they tried to copy the jbc green soft grip). And to be clear; i myself have not aquired that accessory myself yet. It was just recommended by some other people I came across during my research. After some remarks like 'all the other handles are junk'. Or whatever they said about it. You get the picture.
Hope it helps. I know its probably not the cheapest T12 handle out there. But probably well worth the extra cost, given how important the feeling in the hand. And how much you expect to use it.
In regards to the 12v thing. I cannot remember right now but there are probably other better ways to limit power to a c210 cartridge. Rather than lower the psu voltage, just change the maximum pwm duty cycle when the t210 is detected. That should also work. Actually i believe the reason is probably more to do with the thermocouple being entirely different. Both the thermocouple wiring and the coeffecient for the formula. Better details about those tips in this thread:
https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/ (https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/)
@ a "better" T12 handle, got it! I don't care if is not the "cheapest" T12 handle, since I already purchased the "most expensive" and that one seems kinda janky. :-DD
About the 12V thing, what you are proposing is a bit beyond my capabilities. I was thinking more brute force like either having two power sources (least desirable) and switch between them when using the different handles or, I'm not sure if it can be used on the output of a PWM controller, but perhaps a 24V to 12V buck converter between the supply voltage from the controller to the handle. Again, not sure it would work, but it would need a way to switch to bypass the 24V direct from the controller and feed the 12V from the BC instead. Like I said, I'm not an electronics person, I'm a mechanical person.
-
........
-
The heater connector is important at the higher JBC currents (170W cold). The first pic socket looks good and the second pic with the two leafs is junk. It has cheapola plating and little contact area, they are a problem even for T12 handles where they are proven too cheap even at only 3A.
-
But I just wanted to point out (in the meantime) that there are versions of the original closed firmware that already support powering JBC C245 tips. And so your station being newer perhaps might already support that. Without requiring you to flash the open firmware first.
I just wanted to confirm that while playing around with it in my workshop tonight and going through the menu, the firmware does apparently support the C245 handle. I did not have my iPhone with me in my workshop, so I could not photo the menu, but under Tips, the very first one mentioned is "C245", with the ability to select it, and below that are not only obviously the T12 tips listed by what KSGER uses as their nomenclature when you go to order tips from them (i.e. "B1", "K", "D3.2", etc.) there are others listed by numbers that do not correspond to KSGER's nomenclature for the T12 tips, that I suspect are JBC numbers. If that is the case and those are JBC tip numbers, then that menu is one big cluttered mess! One area KSGER should clean up is adding submenus to the Tips menu. It'd be nice to have a menu selection for each handle and only those tips used by that handle listed, plus a menu selection for user defined tips.
Now the question is, are there any HW modifications needed to use a C245 handle and tips or can I just take a handle, either put a compatible end on it for the KSGER or makeup a patch cord and use it? I'm not necessarily expecting you, Dreamcat, to know, but if anyone else has tried this (Vulkan?), it'd be nice to hear. I prefer the patch cord, so if anyone knows the source of a male that plug works with the JBC receptacle on the handle cord, I might fab one up and get a Jabe handle and some tips.
Edit to add photos: (Note: not sure why the thumbnails are not lining up with the actual photo, if you click they come out right side up, at least they did for me).
-
I have gone through the Tip Selection menu and made up a PDF of all the pre-defined tips, 93 in all. In the PDF I just have "94+" to define the remaining spots as "User Defined" (if I remember, there are 6 user defined tips allowed under the menu). I have not gone through and verified which, if not all, predefined tips are T12 tips and which may be JBC or others. I suspect many of you would know offhand.
-
the firmware does apparently support the C245 handle
https://youtu.be/FTg5BybMmWs
-
With the C245 mode, what temperature sensor is being used for the CJC?
There are up to three - the (missing T12) wand thermistor, CPU temperature, or the thermistor on the controller PCB. The video shows 24C but wondering where it's getting it from.
I have seen JBC handle clones that are wired like a T12, to include a shake switch and CJC thermistor.
-
@floobydust - Vulkan's photos in his response (photo 2452) looks exactly like that.
@Vulkan - Do you have any links to sellers of that handle (i.e. the first one with the better connectors to the JBC tips), or, if the PCB was sold separately to be used in a donor handle, the PCB seller?
Thanks.
-
Do you have any links to sellers of that handle
907&JBC (https://item.taobao.com/item.htm?spm=a1z0d.6639537.1997196601.70.611374845ZHDoE&id=606729341548)
936&JBC (https://item.taobao.com/item.htm?spm=a1z0d.6639537.1997196601.35.611374845ZHDoE&id=594508144632)
Controller 2020 STC T12-951 JBC T245-T210.
T12-951 (https://item.taobao.com/item.htm?spm=a1z0d.7625083.1998302264.6.5c5f4e69rbxx90&id=619093191406)
-
I cannot match the controller pcb from these existing images. Perhaps a new and clear photos of the PCB, front and back. That should help to identify it. If you have the time.
-
Do you have any links to sellers of that handle
907&JBC (https://item.taobao.com/item.htm?spm=a1z0d.6639537.1997196601.70.611374845ZHDoE&id=606729341548)
936&JBC (https://item.taobao.com/item.htm?spm=a1z0d.6639537.1997196601.35.611374845ZHDoE&id=594508144632)
Controller 2020 STC T12-951 JBC T245-T210.
T12-951 (https://item.taobao.com/item.htm?spm=a1z0d.7625083.1998302264.6.5c5f4e69rbxx90&id=619093191406)
Great, thanks!
-
I cannot match the controller pcb from these existing images. Perhaps a new and clear photos of the PCB, front and back. That should help to identify it. If you have the time.
If you mean, the photos I posted, I think part of the problem is that they used black for the PCB color. It's hard to make out even looking at it in real life under the lighting in my office, which is quite well lit. I will do my best, but I can only guarantee that I will attempt to get better photos of the back. I'm sorry, but I am not good at de-soldering things and I need this station for my RAS restoration project, so I don't want to go experimenting before I can get that little bit of soldering done. If I can pull the PCB out without having to de-solder it (I saw one nut that is going to be a bear to try to get to without de-soldering the handle output, the potentiometer did not look too bad), I will take photos of what I can, but I realize there may be components and traces hidden under the display which would need to be de-soldered to see what's under it. I may try it later, once the RAS project is done.
-
No no sorry. The message was for vulkan. just didn't highlite him.
:palm:
-
I cannot match the controller pcb from these existing images.
T12-951 on the processor STC15F2K60S2, HW not compatible with STM32.
Perhaps a new and clear photos of the PCB, front and back.
Photo from seller version 2019, version 2020 added another MOSFET.
In the settings menu there is the possibility of accurate calibration of cartridge thermocouples.
Settings menu:
op amp gain: default 250, range 100-350, usually do not need to be changed.
offset voltage: default 0, range 0-400mV, usually do not need to change.
All users who buy a single PCB can request an open source firmware for the soldering station after assembly is complete, but do not allow personal distribution.
-
The MCU is not STM32, it has marking "STC" but the part number is too blurred to read. I wonder if it's STM32 clone (licensed compatible). Or if it's not STM32, then the firmware will be different.
I would suggest that if the debugging port is not SWD.... then it's not compatible.
-
it has marking "STC" but the part number is too blurred to read.
marking STC15F2K60S2
-
Intel 8051 clone
http://www.stcmicro.com/datasheet/STC15F2K32S2_Features.pdf (http://www.stcmicro.com/datasheet/STC15F2K32S2_Features.pdf)
-
I don't see firmware for my board. I know that is stm32 f072cbt6 from this link https://pl.aliexpress.com/item/32963498371.html Menu doesn't have tip selection and font i very small
-
It's the same as mine.
I already reversed it few pages back, it isn't so different, the problem is that the pinout is totally off...
https://www.eevblog.com/forum/index.php?topic=105869.msg2551614#msg2551614 (https://www.eevblog.com/forum/index.php?topic=105869.msg2551614#msg2551614)
Actually trying to figure out how to modify it in stmcube, it's driving me crazy!
Added pinout comparison:
https://docs.google.com/spreadsheets/d/1XHaR4yQGOzwOOm_SS0sypfmvLkAiSz8K8jxcwVk1R-8/edit?usp=sharing (https://docs.google.com/spreadsheets/d/1XHaR4yQGOzwOOm_SS0sypfmvLkAiSz8K8jxcwVk1R-8/edit?usp=sharing)
-
I posted this on another thread since I had indicated I would. I am also going to post these here so that this thread can consolidate the information in one place.
I just received my "V3.1S" Attached are photos of the controller. The first is intended to be a high res photo of the controller built up using 3 close-ups that are pieced together using Paint 3D. I did this with the idea that it would remain legible at higher magnification. It's not perfect, so you may see some inconsistencies between the "joints". I also took a single photo of the controller. I also took a closeup of the STM32 chip, but that may have to go in a separate post due to the size of the photos.
I got the same version right now.
Surprisingly i have the JBC options in menu, from JBC1 to JBC8.
HW 2.00, SW 2.12.
I have 2 questions:
1. as the processor is very hot, it helps if i put a heatsink on it? I can not hold my finger on it, i think it has about 50-60 Celsius.
2. I suppose if the JBC is present in tip menu, i can use those tips too. Where can i find the connection diagram for this?
-
Can someone please confirm, is it normal for this STM32 to work at 100 Celsius? Or it's defective?
100mA current consumption.
-
100mA at 3.3V is 0.33W, by no way it should get so hot.
Are you sure the heat is coming from it and no other part? Like a regulator.
Does it get hot without connecting the handle? Maybe it's the mosfet.
BTW @dreamcat4, I can only say, the STM32 ecosystem is a total mess.
I tried few years ago, I see it has become like arduino, new version to fix the older and cause more bugs, you can never make a damn thing easy.
I'm a microchip fan, although no so powerful as stm32, their documentation is way better. And the dev tools.
I've replaced the stm072 with a 103 from a bluepill. And trying to adapt your code.
Adjusted the ADC inputs, the EXTI GPIOS, all the inputs, outputs, the PWM channel and the spi interface.
Or everything is bugged or I don't know whats happenning. I started with a easy part, the screen.
Just use the spi2 module instead the spi1. The CS, RES, DC signals work. Transmiting a byte makes a signal on the spi output.
Sadly I lost the logic analyzer and I dont know what the hell is happening. The SPi configuration is the same for both channels, just replacing spi1 with spi2..., tried lower baudrates, no way.
In the end I throwed all the spi hardware to the trash and implemented a software bit bang spi. Bingo the screen works.
I've read that the spi module is kinda problematic in the stm32... Maybe the counterfeit stm32 is even worse!
The encoder is very erratic. The rotation works if I spin it quickly. The push button is like magic, sometimes it work, sometimes it doesn't, often works if I push and rotate. Very strange.
Some help would be great!
Edit:
The .ioc file seems to be totally off. The encoder push button is not configured in it, althought it appears in the code.
Check it up, download your git... PB5 shows empty. ADCs are strange too, signals are duplicated and set to both ADC?
Also, the interrupt-on-change shows in FALL mode, setting it to rising and falling fixed the encoder.
Another problem taken from the stmcubemx. In your code is set ok!
It's like if the ioc is not synced with the code. Like if it was from an older build.
Another headache is the user code, it's not set between the comments //User code begin //User code end, etc, so Cubemx erases everything after generating code.
It's far from being usable, dont know if it's a CUBEMX problem or what... tried with the fw 1.4.0 (it says it was the version used to make that project), also tried to migrate to the latest...
When I dropped that way and started fixing the code by hand it got better... hehe
-
Well, finally. Everything works.
I have only one problem. How to calibrate the NTC? It measures 56ºC in a pretty cold day.
Also, I don't know if it's a bug or what. Heating the NTC with my finger, if it goes past 65.5ºC it goes back to 0! Once it cools down a bit it returns to normal.
Did you code the uGUI yourself, by hand? Amazing work! My poker face when I tried to understand everything was epic :wtf:
-
Hey DvidAlfa, I am glad to hear your efforts. It is very encouraging.
I actually didn't touch the code myself, except to get it to compile cleanly. Other people were hacking on it in that branch for the v2.1 support. So what you see in their git history comment (since PTDreamer) is stuff like... maybe they didn't understand what was going on with the temperature readings and were trying to either fix or improve that. Unfortunately some subsequent versions of the KSGer v2.1 hardware actually had bad components on them around the 3.3v regulator that powers the ADC, and also the opamp that amplifies the thermocouple signal before it gets fed into the ADC pins of the STM32.
This is discussed elsewhere. But the question remains if those guys were genuinely trying to fix a real software bug. Or chasing their tails because they didn't realize the temperature errors / swings etc were all down to bad hardware. And were successively changing some parts of the code without any benefit for that reasons.
OK so all that aside, you can see I have given instruction for STM32CubeIDE in my docs. However I really do agree with you many of these difficulties with SMT32 platform in general, and also their dev tools (the code generator etc.). And also their libraries being difficult to use, etc. BUT you already know that!
What somebody else pointed me to (after I had wrote that guide) was that it's also entirely possible to do STM32 development on PlatformIO (in VSCode, using the PlatformIO plugin system). This environment is actually also quite complex itself. But one of several great feature it has is that it can automatically import and setup the required STM32 libs as dependancies. So we are not completely shackled to the STM32 manufacturer provided dev tools.
I just thought I should mention that.
And of course the chinese clone versions of the STM32F103 chip are in fact subtlety different. So you might have hit one of those very not so well known differences in the chip around the IO blocks. Not the same! It's terrible I know in fact was complaining myself about this matter elsewhere. It is really a minefield and pretty confusing situation without kind people such as yourself figuring this out (mostly the hard way) and then making clearer comments in the code and documentation for others to be aware.
I'm not going to be working on this code anytime soon myself. However I do really appreciate and want to support your efforts here on this branch however I can.
Thing is in the last couple of weeks a competing project has also now opened up his source code. But that is a completely different hardware. It has been my goal to eventually get them both going and compare the 2 options against each other. Very exciting! (aside from those terrible bugs i'm sure you will agree).
:-DD
Finally I do hope you fork the repo on github, and upload yourself your own changes into a new branch perhaps? It would be nice to share amongst others. To see what you have had to fix, and how.
You need to learn git? There are resources to help. It isn't that difficult. Personally I use SmartGit on linux. But if you are on windows (or mac) there are other options for a GUI Github client.
Have a nice day.
-
100mA at 3.3V is 0.33W, by no way it should get so hot.
Are you sure the heat is coming from it and no other part? Like a regulator.
Does it get hot without connecting the handle? Maybe it's the mosfet.
Absolutely sure. I touched the CPU with my finger but can't hold more than 2-3 seconds. After 5 minutes even the board is pretty hot and no other component.
100mA i measured on main power of 24V. So he's dissipating about 2,5W of heat.
-
Well, once you get the IDE running, it goes like butter.
The STM072 gave me errors when I tried to debug, in all IDEs! While the 103 worked fine
So it was a PITA to figure out what the problem was, every time.
Like we say in Spain, translated is like "hitting the blind", you feel but don't know why or where! :-DD
Like Windows in the old days, crashing very, very often, but without blue screen, just a red led of death lol.
Then I found that the SPI DMA copuldn't be active when enabling some parts of the initialization process.
Then, suddenly SW4STM32 crashed, lost all the build configurations, couldn't make, debug, program... :horse: :horse:
I said few not so pretty things, deleted SWSTM and installed again stmcubeide...
Guess what? It imported the bugged project perfectly! Just minor errors because I had to add few include paths. And even debugs!!
Now its working with DMA assisted display, which updates almost asynchronously, so now it really goes fast!
Now I put back the stm072 in its board (lucky survivor, I soldered/desoldered it at least 5 times, all pins are doing well still), and I'll go with the ADC now.
It reads ok, but the factors are totally off.
And!!! I fixed everything in the code to be CUBEMX friendly, so now you can touch any settings of a GPIO, ADC, Timer... And keep everything nice and happy!
That was a big part of the trouble too...
By the way, I found some source codes for the STC T12 irons, they are very much like baseline pics, 16fxx and so, few instructions and a delight to program without loosing 200 hairs per hour.
However I'm not aware how the ICSP programming goes.
-
Now I put back the stm072 in its board (lucky survivor, I soldered/desoldered it at least 5 times, all pins are doing well still), and I'll go with the ADC now.
It reads ok, but the factors are totally off.
For some models there is known hardware issue with certain components. It affects the temperature readings. I am not sure if its same problem for you here. BUT
We regularly talk about these 2 connected problem:
* The 3.3v regulator can be bad. And give bad unclean power to the op-amp. ---> The solution is to replace it with a better one.
* The op-amp can also be bad. ---> The solution is to replace it with a better one.
Because an inferior VRM will create noise on the line, is will throw off the sensitive reading from the thermocouple.
Because the op-amp itself can be inferior quality, and not good enough to amplify the delicate signal (microvolts). Before feeding in the result to the ADC.
In both cases it messes up the temperature reading. You want a smooth an continuous change in the temperature. Instead of the numbers jumping about everywhere.
We can give recommendations for replacement parts, for the KSGER T12 (v2.1) station. Just need to dig around to find them. As the are not in front of me right now.
Or perhaps that is not your problem? Then perhaps it is something else?
:-//
And!!! I fixed everything in the code to be CUBEMX friendly, so now you can touch any settings of a GPIO, ADC, Timer... And keep everything nice and happy!
That was a big part of the trouble too...
Good news. Please click the "Fork" button on github. Upload and share with the world. Thank you!
:-+
-
Nope, Vcc is fine. The adc reading are consistent. About 5bits of noise (4mV).
If you see my schematics, the VCC is well done in this board.
First is uses a buck converter to step down the voltage to 5V and supply the OLED screen.
Then a 3.3V LDO for just the stm32. The voltage is is stable at 3.299v.
It's the algorith used. Some constant is wrong.
The NTC function uses 16 bit value for reporting mCº, so going over 65.5ºC ( 65535mCº) saturates the variable and rolls over to 0.
The whole gui use also 16bit values. So not so easy to fix.
That will fixed be later, for now I want to adapt the conversion of adc, as the opamp circuit is different.
NTC final calc voltage using Vref has an error about 10mV. Which can be the voltmeter error easily.
The calculation algorithms don't use the vref input for anything! It uses a hardcoded voltage of 3300mV.
Simple as Vinput=(3300/4096)*Adc_reading.
The VCC may (And will) vary and affect those calcs. Vref is not used anywhere in the whole program.
I will share it of course, still have to polish it a bit more. Too much hardcoded values, hard to modify in an easy way.
-
Also, a bug in the cold-junction comp is using the station outdoors it can be below 0ºC (in Canada) and it bungles the sign change.
Temperature should be a signed variable to avoid wrap around.
-
There were bugs on dma transfers, the adc was filling only half of the buffer, and in FOR loops (specially on the cold function part).
Another strange bug causing Hard faults was that "sizeof" was returning 0 in part of the loop for calculation the average.
I guess it's a compiler bug, but I had to replace the sizeof with a define.
I replicated the cold function algorithm in excel and the results are totally different.
static const uint16_t NTC_R = 1013;
float adc_read = log(NTC_RES);
adc_read = 1000 / (0.001129148 + (0.000234125 * adc_read) + (0.0000000876741 * adc_read * adc_read * adc_read));
adc_read = adc_read - 273150; // Convert Kelvin to Celsius
The actual adc readings was about 2307 (1.85v).
The final result on the stm32 gives 80895.
As the result is truncated to 16bit, which results in 15359.
Units are mCº, so you might think it's ok because you see 15.3ºC on the screen. But it's not.
Finally I dropped the method using logarithms and float numbers. That thing was cursed.
It makes no sense, the cpu doesn'h have FPU, those calcs consume a lot of processing power.
Using a table based routine showed to be very accurate, the error is about 0.2ºC.
Now the temp works between 0 and 125ºC. Still finding how to show negative ones.
I think it's a uGUI fault, yet to find if it's wrong configured or a limitation.
I'm replacing a lot and making the code more versatile, there's too much stuff hardcoded, I just hate when I just change a timer or an output and also have to touch up 20 lines of code everywhere.
I haven't programmed like this for years, back then I was a nice amateur coder, but then you start working and not having time for anything...
But you never forget the IF...ELSE...WHILE... like listening to my my ex gf, how many times had I think "Where's the Control+C" :-DD
I'm still amazed how the gui works. The widget system built on top of uGUI is to joke!
-
I'm back with news. The STM is bad.
Measured 3,27V on pins 48 & 64, 1V on pin 13, 1,7Von pins 19 & 32.
Question is: if i replace it the STM32F101 with a new one, can i get it to work?
The board is HW 2.00, SW 2.12.
-
Do you have stlink for programming?
I have almost finished fixing the firmware, after that it should be very easy to port between stm32 variants.
The last changes were to stop ADC DMA being always in circular buffer.
The DMA routine was called every 300uS, which makes no sense, a waste of processing power just entering and exiting the callback.
ADC DMA changed from Dual simulntaeous conversion to single ADC mode.
There's no need of so much speed, and that way the compatibility is improved, as the STM32F0xx devices only have one ADC.
It may be even faster than before, as the sampling time was set to 239 cycles, while 13 cycles is almost the double needed to charge the internal hold capacitor through a 10K resistor.
So now the ADC is updated every time the PID is called (much often than the OLED update).
Actually the PID routine is called every 1mS and the OLED updated every 10mS (We got a 100Hz gaming screen lol).
The responsiveness of the GUI is perfect now.
Before it wass updated every 200mS and the encoder responsiveness was cluncky.
Added delay for the GUI readings update. By default update is done every 200mS, don't recommend going faster as you will only see numbers dancing.
PWM frequency updated from 2 to 24KHz to stop the annoying beeping, while adding 33% more PWM precision.
This still need testing, as the mosfet driving circuit may be too weak, resulting in the mosfet gate floating at a intermediate voltage and acting as a a resistor (lots of heat).
Anyway, the circuit is wrong anyway, because the mosfet gate absolute max voltage is 20V and this circuit is driving it at 24v!
I will add a mosfet driver to fix this. Most people should maintain the 2KHz frequency unless they know what they're doing.
Fixed the NO IRON crash. Added 1000mS delay to prevent bouncing back to temp screen.
Fixed NTC temperature readings. Will limit output between "-9.9" and "99.9" ºC.
I think I will reorder the main screen too. The release will be soon.
BTW, the "Btech" logo and all the files signed by "Jose". Who did this? Was this a leaked code from a company? Or a hobby project of is employeers?
-
Can someone please confirm, is it normal for this STM32 to work at 100 Celsius? Or it's defective?
100mA current consumption.
STM32F103 it never heats up, even when all its outputs are fully loaded. It is possible that the power supply voltage is too high or something else is heating up nearby. On older versions, linear voltage regulators were installed from 24V to 3.3 V, with a current of 0.1 A, this is 2W, which will heat a small board very much.
-
So glad to hear these improvements. It's a great work. Many improvements, I thank you.
:clap:
BTW, the "Btech" logo and all the files signed by "Jose". Who did this? Was this a leaked code from a company? Or a hobby project of is employeers?
Jose = PTDreamer, the guy who originally made on the v1.5 hardware board. And is still on github, just not active anymore on this project. There is also a blog etc, just search "PTDreamer".
BTW once you are fixing the PID algorithm, here is another guy on our forums. Who has donated C code, for an alternative control algorithm. He claims it is easier to use because less tuning (fewer variables). The performance should be similar as PID.
https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/msg3106950/#msg3106950 (https://www.eevblog.com/forum/projects/yet-another-controller-for-jbc-t210t245/msg3106950/#msg3106950)
Of course everybody else uses PID. And I don't know if you are interested in trying it. But it's just there for you in case you ever get frustrated with PID for whatever reason(s). If your code is working now... then it would be less reason to change it. Just more of a fun experiment / to see what happens.
However if you also read back ^^ this guy's thread also contains a lot of really good information about the C245 cartridge. How the soldering tip behaves etc. Which is also good reading.
In the meantime, please take your time with the code, there is no hurry. We are glad to wait.
:-+
-
Oh! I thought you were him. As you share the "dream" hehehe.
This is going out of control, I'm too perfectionist... haha
I'm revamping the interface too.. just a little. Like most electronics, the meters in the upper side and the control on the bottom.
A bit more tidier for my liking.
It was going too well. Worrying. While programming, suddely the IDE crashes, St-link crashes, and also does the T12 station.
Well, I thought it was gone... after 20 failures attempting to program it, I used ST-LINk utility and made a full erase....Pheww it worked.
I think the chip is bugged, being a fake no surprises... Or maybe they're not fake but they put there the defective ones?
About the PID, it's working pretty well here. I have to calibrate the temp, my probe died yesterday so it cant be done for now.
However the temperature remains very stable.
Few pictures:
-
Do you have stlink for programming?
I have almost finished fixing the firmware, after that it should be very easy to port between stm32 variants.
I just ordered one. And new processor too. Mine is STM32F101RBT6 with 64 pins. Board with 1.3" display.
Do you know (or have) a firmare that will work on my processor?
STM32F103 it never heats up, even when all its outputs are fully loaded. It is possible that the power supply voltage is too high or something else is heating up nearby. On older versions, linear voltage regulators were installed from 24V to 3.3 V, with a current of 0.1 A, this is 2W, which will heat a small board very much.
Mine is STM32F101RBT6, the 64pin version. I think in the past has some supply problems (feedback resistors where not good soldered) and now the processor is almost dead even if there are no other supply problems.
-
Well, at last I figured out how to use git. I've been always using the old school "modify, mess it up and then try to remember what did I change".
There wasn't git integration in microchip IDE until bthey migrated to MPLAB X in 2010. By then it was very buggy so I stick with the old IDE a lot of years.
Then I just got used and didn't try.
My god, this is incredibly useful. I already was able to fix some weird bugs that I caused, and I spent hours trying... with diff I fixed it in a sigh! Was a pretty stupid typo...
Now the progress will be much faster.
I just ordered one. And new processor too. Mine is STM32F101RBT6 with 64 pins. Board with 1.3" display.
Do you know (or have) a firmare that will work on my processor?
Currently not. Original firmware uses stm32f103 and my port uses stm32f072.
But mine it's not hard to port.
The main thing is to make the schematic and then adapt the firmware to it.
The I/O might be using different pinout, so may do the periphericals.
We have to check how the temperature signal is processed, etc.
If you make high definition and crisp photos, I'd try to help.
When I mead HD, I mean you should be able to read every component's value!
-
Thanks man, you're the greatest!
As far as i could find out, the board is KSGER v2.1s r3, acording to github: https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/r3
I uploaded the pictures here: https://drive.google.com/drive/folders/1HLGSN3M6CB--ZOcvBISrT-DVY-xlbpAI?usp=sharing
If you need more or different angle, just ask.
I have these schematics, but different processors.
-
I can try draw the schematic from your pictures of 2.1S r3, the board is very similar to 2.1S deluxe version with the desoldering option. Black solder mask is no fun.
-
Black solder mask is no fun.
I know... It's no rush. I will get the processor and the ST-Link hopefully in about 4-6 weeks.
I only ordered this black board for JBC tips compatibility.
-
Hi all, I recently bought a T12 station with this firmware in mind.
It's the Quicko T12, it shows HW version 3.4 and it's totally different.
Original FW is absolute crap, well, at least it works somehow, but it could be much better.
It uses STM32F072C8t6. Flash reading protected, of course!
Very close specs, 64 Flash, 16KB RAM (103 has 20)KB, 1 ADC instead 2 but enough channels...
The schematic is similar, it adds another sensor amp circuit, I guess for handle temperature sensor.
From what I see most is just swapping pins. Ex, SDA1 for SDA2, ADC inputs, few GPIOS.
Theorically, just need to relocate the pins in stm32cubemx, adjust ADC factors, touch some code, mainly swapping peripherals modules, timers, adc, PWM, as the pins in this board use other ones.
And compile! Hah! It's never that easy. I've tried and it messes up everything.
This is the same board:
https://www.aliexpress.com/item/32963498371.html (https://www.aliexpress.com/item/32963498371.html)
Edit: Corrected schematics.
(Click to open in a new window, high resolution)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1092388;image;image) (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1092388;image)
Well, I finally release the firmware and the code for the Quicko T12 soldering station.
I think it's mostly bug free, no crashes, stable readings, everything working nicely.
Lots of small improvements here and there. Nice BETA logo on boot up :-DD
Added a reset method, pushing the button before powering up.
It will warn you, so there will be no surprises. In case you mess up with the parameters and want to reload defaults...
Don't get fooled by the RAM usage, the compiler shows 35%, however the GUI mallocs a lot more, around 90-95%! This was a bigr problem in the F072, as it has 4KB less than the F103.
I ran intro serious trouble until I got the culprit of so many Hard Faults!
Also the flash is near it's limit at 95% usage.
The final PWM uses 50Hz, PID set to 100mS.
Works very well, makes no noises and the switching losses in the mosfet are minimal.
Anyway, you can tweak these settings in the setup.h file, along with other parameters like the Timer, SPI, PWM, ands ADC devices.
So for a different stm32, you only need to run cubeMX, copy everything, and change the names in setup.h
I must say, I'm tired, not of coding, but of fighting for nothing. Nothing works smooth for more than 2 days!
I miss the old and stable IDEs. When they switched to java-based eclipse, problems began. Not to mention it's a resource hog (2GB RAM usage for 5 text files opened?)
Have fun!
BTW, I recommend you the DL-32 tip. It's by far the most heat conductive tip I've tested. Will beat the crap out of any ground plane like butter!
-
Have fun!
BTW, I recommend you the DL-32 tip. It's by far the most heat conductive tip I've tested. Will beat the crap out of any ground plane like butter!
OK Thanks David. I have put your changes in a single git commit (dated Nov 03). And set that to a feature branch, made that the new default branch on my repo. The current state of the forks:
https://github.com/dreamcat4/stm32_soldering_iron_controller/network
It seems a couple of other people have also been active recently, at this same time. Nothing significant, except maybe 1 thing. Which was a bugfix for display (garbled lines) by LuckyTomas.
Other than that, I don't really see much point going back, if we have kept compatibility? We should go forwards!
I thank you so much for putting all that work into this open source project. And making a great effort to improve it.
:-+
-
The thing was that I didn't knew of your port until I was half doing mine lol.
Anyway I consider my code pretty clean, as for the DMA spi routines, never seen any display corruption, should be very east to implement.
I'll have a look at your repo too!
-
Whoops, you commited the whole project over the previous one! This is more like a branch, for the stm072, until we can make some changes to build it easily (ex. #define use_stm072, use_stm103... ).
My current firmware won't work as is with them!
I'm not too used to github, how to check out the previous version to compare?
Also, I'd like to comment most differences I can in the commit you pushed in, there're tons of changes ...
Edit:
Well, I tried to commit...No way. Errors everywhere, not permitted... seems to be the ssh keys, should open git console to generatethem , and... surprise command not found, doesn't work, blahblah I'm really fed up.
Here are some little changes with all the commit messages from the beginning that should explain everything.
I will try now to delete everything and clone your repo, I got a mess between my local git and... I admit that I'm lost hahah
-
It is committed as a feature branch ATM. It hasn't been merged onto master. I just changed my default branch.
Yeah to compare the code you can use the "compare branches" feature in github. Please try to find some free time to lean about using git, and github better.
Because splitting your work into multiple different commits makes it easier to follow changes. Too many changes in 1, it's hard to understand for others.
The commit msg is like a summary of an atomic change, so really the "branch compare" function is just reduced to a regular diff at this point. Since it's all in only 1 single massive commit.
:-//
The other way to communicate changes is to write a changelog, and put that into the README.md.
So instead of trying to go back and rewrite the git history. (when you cannot remember what you did anymore). It would be more helpful to just improve the current documentation in the README file. To update the details there and make it easier to understand the current status.
I was going to do this anyway. It's just better coming from you! As you are much more familiar with the code. Do you have a github account yourself? Can you re-redit the readme file to better reflect all these changes?
-
I have so, but I'm not familiar with git, appart of the classic "git clone" something, "make" and ta-daa!
See my previous edited post. All is there, all the changes I did, etc.
I cloned your repo , changed few things, when I came to commit & push, error! I just roll'ed my eyes, "I see we found each other again...".
No patience left!
Also, I've tried fixing the tab identation, no way, tried only spaces, 2 tabs, 4 tabs...the code appears broken in the browser, however it displays ok in Notepad++.
So it might be a Window issue
-
Hi again,
OK I have now had time to work on the README file. It now better reflects and represents the current project status more clearly. But I could use your help improving it further. There are a couple of sections in there named "Working" and "TODO". So if you feel like you can add more useful comments in there. And update that stuff. Please be my guest. Otherwise (as you said) we we can take your comments over the last week, in all these previous forum posts. Here on this thread. And summarize those back into the README.
Here you can see the current README.md in my fork:
https://github.com/dreamcat4/stm32_soldering_iron_controller
'git pull' it. To grab it then can just edit the readme. Your repo will be out of sync though... this is why you need to set aside some time to learn git. For merges, stashing, etc. As git typically won't let you sync changes with a dirty work area. What I do is either 'git stash'. Or otherwise just clone as a seperate (whole new folder). Then manually copy the working changed back into the repo folder. From the *old* repo folder.
* For doing some other changes in the repo, such as the Tab indent. Please make a seperate individual commit for that other type of action.
IMHO tabs and indentation can be annoying, sure! However some of our developer tools can at least be half-smart about the way they handle tabs and spaced. To be more intelligent especially when comparing files etc.
You can of course know what my own tools are:
* Linux
* Sublime Text 3 - no problem with tabs / spaces. Or newline CR LF!
* BTW - Please use unix newlines, not windows ones. Shouldn't be a problem.
* SmartGit - for git GUI
* Beyond Compare 4 - for diffs and folder compare
BTW if you want to try moving away from STM32CubeIDE. Then PlatformIO runs as a plugin inside of VSCode. So then I would suggest VSCode for your editor.
There is nothing wrong with using Notepad++ either. Or other different tools, which I didn't mention above. For example being on windows (rather than linux) you can use SmartGit for sure. But there are also a couple of other great options in windows for a git GUI.
Hope that helps. :-+
-
Otherwise (as you said) we we can take your comments over the last week, in all these previous forum posts. Here on this thread. And summarize those back into the README.
Did you check the changes.txt in prev post? That's what I tried to push in the git. Pulled the last version ("the david alfa improved" one), changes few things, then tried to commit as long the giant commit message... Error hahah.
Yep, I guess I have to learn how the system works. Must admit it's a bit overwhelming at first!
I would revert the last commit and put that one. I'ts basically the same with a little bug corrected, and everything explained.
-
Otherwise (as you said) we we can take your comments over the last week, in all these previous forum posts. Here on this thread. And summarize those back into the README.
Did you check the changes.txt in prev post? That's what I tried to push in the git.
Ah thanks! Sorry I did not see that before now. Sure I can add that for you no problem! Will have time to add that in... sometime during the next day or 2.
have to learn how the system works. Must admit it's a bit overwhelming at first!
OK let me try to help you better. To make learning git become easier:
It is a lot harder to do 2 different things at the same time. That is not going to help you learn git. When you have also some real changes to do, inside a large project. That is not going to work out so well.
So! My advice (and for windows platform).
* If you are on win10 then use WSL and install git inside WSL.
* Then do a basic tutorial for cmdline git. It must be of a good quality.
* Dummy tutorial project is a good and safe practise area. Without distraction from other real world project tasks.
* Make an example project, do not use a real project in this part.
* The 'getting started' tutorial is only for:
* Basic things, like: simple checkouts, how to make a commit. How to create a new branch etc.
This tutorial is best. Recommend:
https://git-scm.com/docs/gittutorial (https://git-scm.com/docs/gittutorial)
Once you have done the basic cmdline git operations:
Then look for 'git cheat sheet' online:
* All git commands listed on a single page, (html, image, or PDF file).
* google image search for: "git cheat sheet"
* It includes more advanced git commands. But only the ones which are really useful and needed.
Here are the 2 best 'git cheat sheets':
* https://www.jrebel.com/system/files/git-cheat-sheet.pdf (https://www.jrebel.com/system/files/git-cheat-sheet.pdf)
* https://www.git-tower.com/blog/git-cheat-sheet (https://www.git-tower.com/blog/git-cheat-sheet)
The 2nd one (by 'Git tower') requires newsletter signup. Then they will email you a link to download the cheat sheet. The download package includes a localized Spanish 'es' version. In your own language. Hope that helps.
OK. So you have played on the cmdline and learned as much as you can with dummy file. You have the git cheet sheet. What next? What to do after that?
...then you should install a GUI program for git. They are like an IDE. It makes the advanced operations much easier to do. For things like merging, rebasing, discarding changes or cherry picking, undoing mistakes in your git history, etc.
There is a lot of choices on windows. Here are my recommendations:
* SmartGit
* Github Desktop application
* TortoiseGit - with context menu desktop integration into Explorer.exe - very useful!
* Other desktop apps (sorry i forget now!). Some are better than others.
You should try as many as you think might be good ones. Choose the best one of which feel has best interface. That is easier for you to use.
Hope it helps :-+
-
Thanks! Will have a look.
English is not a problem, I prefer it in fact, as a technical problem/question will be much easier to find on internet.
Now I was trying to port the firm to the 103...guess what, sorted few things I missed, but the stm is crazy, sometiems can erase, others not, the debugger hangs everytime...
Will try to set up vscode!
-
Cool man :-+
-
Definitely my 103 is defective - Thrown into the bin.
Hope next ones come better!
-
Definitely my 103 is defective - Thrown into the bin.
Hope next ones come better!
* Can you please tell us where you got the defective one from? Where exactly?
* Please also tell us where the new ones are from.
Because I have been sourcing from aliexpress. Different sellers. Maybe we can compare / know better for next time. Thanks.
-
Hello to everybody, I don't have any knowledge on programming, compiling etc. But I have a JBC T245 HANDLE (with some Tips) and I'd like to buy one of these controllers on aliexpress (only the controller board to use with an external PSU), a few Spare STMs to solder and a ST-Link programmer to experiment and use it. Can you suggest me which one is best to buy and experiment with? Maybe using the new and adapted good work of DavidAlfa.
Thank You.
-
Definitely my 103 is defective - Thrown into the bin.
Hope next ones come better!
* Can you please tell us where you got the defective one from? Where exactly?
* Please also tell us where the new ones are from.
Because I have been sourcing from aliexpress. Different sellers. Maybe we can compare / know better for next time. Thanks.
It came from a blue pill I had bought time ago. It's not an original st,but a "CKS32F103". It worked well until..it no longer worked.
I will buy few more just to experiment, I'll post updates about how they go.
I want to buy the 103, someone said his T12 came with a 101 so I'll get the 101 as well... unless they allow me to remotely debug their board using teamviewer haha.
Did you already bought any good ones? If so, please share the seller, thanks!
Hello to everybody, I don't have any knowledge on programming, compiling etc. But I have a JBC T245 HANDLE (with some Tips) and I'd like to buy one of these controllers on aliexpress (only the controller board to use with an external PSU), a few Spare STMs to solder and a ST-Link programmer to experiment and use it. Can you suggest me which one is best to buy and experiment with? Maybe using the new and adapted good work of DavidAlfa.
Thank You.
The problem is that they change the design pretty often, usually to save few cents.
Mine is the "Quicko T12", but I've checked Aliexpress and I see they're different now, at least the GUI.
As long as it's stm32 based, it shouldn't be too hard to port...
My board is this one, pretty expensive nowadays:
https://es.aliexpress.com/item/32963498371.html
Maybe you could ask the seller to send actual photos of the pcb, then we could check out the compatibility.
I must say that, after having seen the other stm32 T12 boards, I'm happy with mine.
At least the power supply side is well made, the board doesn't heat up and the operation is very stable.
And it comes with circuitry to connect the handle temp sensor too...
I'm also thinking in adapting the JBC handle. But I don't think I will...
For me the T12 are doing fine, they are cheap, and I won't cry if I burn a tip...
Now with the firmware update the temperature stability works better.
Previously it would burn the board easily because at 400 it would oscillate a lot, between maybe 460 and 380.
In heavy copper traces or ground planes, it would either burn it down or make the tip stick to the trace and lift it off...
And, I have "overclocked" mine a little bit, since I bought it a year ago.
I modded the power supply from 24 to 30V... seems to be not much of a difference, but in terms of power it actually boosted from 72 to 112W.
Didn't burn any tip yet, except one... I was debugging and I stopped the core with pwm set at 100%.
Then I saw something glowing bright orange near the wall, like a candle :-DD
-
Added your changes.txt ---> as Changelog.md. Reformatted the text a little bit,
Did you already bought any good ones? If so, please share the seller, thanks!
Dammnit. I just realized that is what I also got for the 32 pins version. The reasons was because the 32 pin count version is more expensive than those Blue Pill boards.
So best thing is to buy from somewhere like Farnell CPC, or Digikey. I guess there are also some on Aliexpress. But it is not so clear if they are genuine ST version.
For the 64 pin version, (STM32F103RCT6) I purchased a couple of these. From an aliexpress seller. However I have not used them yet. So I don't know if they are any good. However if there is a problem found later on in the future. Then I will post a comment here to warn people.
https://www.aliexpress.com/item/4000122132651.html (https://www.aliexpress.com/item/4000122132651.html)
Perhaps when I have other things to buy from Farnell, enough to put together a larger order. Then I will order some from Farnell (the 32 pins, genuine). But it's not happening anytime soon right now.
-
For me, the only reason for buying genuine stm is if the clone doesn't work with the IDE. I want a smooth experience.
Otherwise, if I can save some cash, I'll go with clones
Currently I'm trying too move on from uGui to U8G2 library, as the second is specifically made for monochrome displays.
Plus it has a lot more of fonts.
Got it almost working now, while saving at least 10% flash space.
The gui shows distorted but it's close... needs some tweaking.
I definitely will changed the way update_display works, returning if the dma is active, without refreshing the display.
Who cares, the screen will update again in next cycle call, after few mS.
Just for benchmarking purposes, I made some performance tests counting cpu cycles used the SPI DMA mode...
It's great, almost no CPU time is used, only the interrupts and the few cmd bytes sent between rows.
Otherwise, with HW SPI and no DMA, it spends nearly 76K CPU cycles ( 1.6mS).
Overclocking a bit the SPI to 24Mbit (a bit over max specifications of 18Mbit but it works), efectively halves that time do 38K cycles.
Not to talk about software SPI, it takes 700K+ cycles...
-
I decided to go for a Bangood offer of a complete Ksger unit (fully assembled and with its handle), just because I think it's a good value to get it a try (32,5€ shipped). It should have (but who can tell?) A V2.1s r2 controller (based on your good work dreamcat4) and the JBC T245 (R7) option. I really hope that soon or later, thank to the work of all of you guys, I would be able to use it with my T245 handle and tips. I'll wait till I receive it and then, based on what I receive, buy a pair of spare STMs. I still hope for DavidAlfa to port his work to JBC T245. Maybe I can ship you a pair of weared C245 tips (I'll wait fir some trashed ones in next month) for you to experiment without burning good tips. It would be my help to the forum.
-
Well, this are my first steps on github... Tried to make the build process as easy as possible.
https://github.com/deividAlfa/stm32_soldering_iron_controller
Already compiled bins if anyone wants to try.
Keep in mind that only the stm32f072 is tested! Made for the Quicko T12
The stm32f103 is done "theorically". Made for the original 1.5 controller.
Dreamcat4, I checked your code, damn, lots of bugs I found were already corrected on yours... so much pain for nothing! :horse:
Anyway, as I said, I didn't knew the existence of your fork until it was done!
There's no sense in making separate projects, so now it would be nice that you tell me a bit how is yours doing.
I saw some exotic math functions (I guess for making the averages or what ?), "flawless adquisition" (what was the problem with adc?)
What is the status of the porting bertween the different board revisions (1.5, 2.1, 2.1s....so on)?
-
Yeah this all looks fine. I do really agree you should be the new lead developer / maintainer of the code. Network graph shows well the situation:
https://github.com/deividAlfa/stm32_soldering_iron_controller/network
Thanks for taking the time to learn the git, and also to make these instructions and guidance for others what to do / how to build. And for different hardware. It's really helpful and I cannot thank you enough.
Might send you a small PR (merge request) over on Github to fix the docs a little bit. But it's not anything important. Just small housekeeping.
Overall I am really looking forwards to following your new instructions and trying this out on my Ve2.1s ("r2") board I have here. And see how far I can get along with this one:
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#blue-pcb-ve21s-r2-ksger-version-lwfp-64
More generally, it would be nice to raise the awareness level for others. To get more people each with different boards. So we can have greater level of community participation and contributions for the many other versions of this hardware.
-
I would be happy to help!
I checked the 2.1 schematic and I must say it's pretty sad, we'll see how the ADC works with that 3.3V buck converter noise...and the op amp has no filters!
-
Not a problem! I have already got here the needed replacement 3.3v regulator, and the replacement op-amp. Which were ones recommended by the Russians. These should be ok once I install them. Going by those other people's past comments (in the radiokot forum).
-
oK. I saw the display uses i2c instead spi on these. Luckly my screen has a resistor to switch between modes.
I thought about it, to not overcomplicate the code, I will just make different branches for each controller.
That way the STMCUBE project can be used right away without needing any tweaking from the user side...
-
The problem with making seperate branches or codebases is then it creates a burden of extra work, keeping them all in sync with each other. Things become harder the more different hardware to support. And there are so many different boards.
What I was hoping is that we can have multiple project files, and then choose which one to compile for a specific build target.
It is a good idea to put different hardware features under configuration. This then also lets people to mod their devices and select (for example) and alternative display etc. by selecting a combination of options to compile in.
Of course the code generation aspect makes things more difficult. In the past I have used autotools. And other ones. But those are not necessarily best for this project IDK. Perhaps there are many possible build systems to choose from.
On a feature level. For example I2C vs SPI display. Then I would like to #ifdef stuff condifionally in the c code to compile in and out the specific features. Then have something in the build process to select which ones to compile.
What do you think about this?
-
But that way we'll have to put thousands of #ifdef.
Stm32 Cube Ide doesn't handle well switching between MCUs, that was my initial intention.
But the project creates a lot of problems,conflicts between HAL Drivers, startup code, linker script, and after changing all that, you find that the project mcu is hardcoded and can't be changed in it's properties.
The only way to not make it painful is to make it fully compatible with CubeMX code generation. It will make all the pin definitions, etc...
You can switch between .ioc files, yes, but again, only if the exact same mcu is used. And adding further confusion.
My thinking would be to share the common code , but let the specific part separated. We can share most of the code, but not the main, setup.h, IDE project and cubeMX files.
I don't know if that could be done and how.
Take a base for all, then each branch would add its own specific files, but taking any change from the base code.
-
Well being on linux, we have symlinks. So my own thoughts is to write a shell script that will let somebody 'create' a new folder. Containing just only those files you mentioned:
> the main, setup.h, IDE project and cubeMX files
By copying from a template or default folder. So then you end up with 1 folder per hardware configuration. With users having a way to just run a command to generate a new hardware configuration, into it's own folder.
Then (in linux, because we have 'symlinks')... we can have the same script also then symlink the common folder into that hardware configuration folder. So that it is a subfolder. To share all of the common code.
This might be a problem! because in windows you don't have symlinks. But instead have 'Shortcuts' .lnk. So then it would be more desirable to be having the possibility to reference the common code via a parent relative folder ..\Common\ (or whatever it is called).
And have relative paths.
Otherwise you are forced into using WSL, which inside WSL 'kindda' has symlinks. But also not really so great. It would be preferable not to have to impose the requirement of WSL onto windows users.
-
Or perhaps if we ever try PlatformIO, that itself will come with helps mechanism(s). Which are cross platform compatible. But right now it seels like we don't have the time to invest the efforts to try to switch over to that yet. And since we both can use CudeIDE well enough, it compiles things. It works.
:blah:
In terms of making separate per folder configurations.... Hopefully once I get the opportunity to work on this project next week, maybe the choices for how to do that... might become a little bit more obvious.
:-/O
But what I can say (for sure) is that maintaining multiple branches in version control across multiple users is a complete nightmare. I have done so before in past projects and it is utter dridgery. We should to our best to stick to 1 main development branch ('master'). This greatly simplifiers user contributions. We should switch back to 'master' already. I just didn't make / send you a PR yet. Next few days.
:scared:
In terms of #ifdef #elif preprocessor macros. Well again - I have used these too previously. Also in other (much larger) C projects than this one. They are by no means perfect. And like you say can make the code really untidy. However at the same time they are normally the right fit for a C project.
But I think it's helpful to talk more about how to use them properly. To address your concern that there would be '#ifdefs everywhere'. Because that certainly can happen too, without managing them properly.
Also the point of them is to be feature based. So taking the screen for example. There should only be 2 options. Either it is i2c, or its spi.
Basically there are 2 ideal instances where #ifdefs are not going to hurt your eyes... Either:
* It's a larger C file, and within it there is only a couple of places where you need some simple #ifdef #elif. OR that is some #define constant macro. That is a choice between preset values. Great. Then they are not going to be so frequent.
* If there are many extensive changes throughout the file. OK in this instance we don't want to #ifdef around specific lines of code. But instead of that pull in a completely different .c or .h file. So instead of putting them into the code, we reference the other file we are compiling in. For example via #include. And then have different 'variants' of the file. One for each #ifdef or build flag. So then we are either compiling 'timers_hw1.c' or 'timers_hw2.c'. And only the reference file needs to have a few lines in it to control which one was picked up. Be it for include, or compiling / linking.
By copying the entire file (timers.c --> timers_hw1.c). But then edit each file individually. And have to maintain multiple different files. For each independant feature we have under configuration. However in this way, we can develop all the code in the same VCS branch. And no need to keep many different git branches. Just because having many branches to maintain... that would be much less pleasant way. Trust me you don't want to merge stuff like that. It's terrible. (nightmares, I still remember).
:-DD
-
After an afternoon fighting to implement a DMA i2c rotuine (the damn CubeMX didn't enable the i2c interrupts by itself), then I found that... well, I'd like to know what these chinese programmers were thinking!
Having a 64 pin mcu, only ~20 used, why the hell they plugged the i2c devices to non i2c ports?
As if i2c wasn't slow enough! Use software i2c! Spend 80% cpu cycles sending a year 2000 phone resolution display!
I seriously think that these board don't deserve any development. Pure crap!
I could design a pcb, then anyone could order 5 from jlcpcb for $5!
Yes, in the end maybe the cost is a little higher having to buy all the componentes, but it would be a decent hardware to work with...
-
Custom board is certainly a very good idea. Actually others have already thought about that, over in the Russian forums. There was a guy on radiokot selling such pcbs for a while, to the other russians.
The main thing to realize is that the current solution is to buy the original v2.1 hardware, which is for sale on aliexpress. This was the version of the board which has been copied the most by people who make their own PCB.
Here it is:
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#v21s-original-version-green-pcb (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#v21s-original-version-green-pcb)
So another solution is to writing in bigger, bolder letters the correct hardware to buy. As above^^. Right at the very top of the README. So it's more obvious to see it. Instead of those warnings being so hidden away.
:palm:
As for my inferior garbage blue Ve2.1s board here, with the i2c display. i am not against cutting traces, scratching off copper. And putting little fly wires across to other pins. In order to re-wire the i2c display, if necessary.
Uhm I don't know if this could be compatible or not. But another component already on order (sorry I forgot to mention before). Was 1x SPI oled display for a completely different project.
https://www.aliexpress.com/item/32896971385.html (https://www.aliexpress.com/item/32896971385.html)
It is still in the mail, coming from china. If it's compatible then perhaps I could connect that one instead. To try it out first. Before cutting traces and ditching the i2c display completely.
Which solution is best? IDK. But those seem to be the current options for modding (on that specific one).
Anyhow yeah I agree it's frustrating and not very rewarding to give effort to supporting inferior boards. When you know full well it's not right. So maybe if we can come up with a reasonable hardware mod, and document for others how they can also do that for theirs. To rewire their boards. Because that's the situation for most people: they buy the garbage ones. Or don't know which board they are getting, because it's hidden in the enclosure etc.
:blah:
-
The OLED is not hard to fix, the I2C pins are free.
Being i2c we can share the same bus between the oled and the eeprom.
There's no need to cut the traces, just configuring them as input will be enough.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1145638)
-
The porting was pretty simple. About 10 minutes...
Here's the stmcube ide project, already compiled (.bin inside Release folder).
About Vstudio code, I tried setting up all the stuff, definitely not for me, a total mess, and repeat when you make a new project.
Plus I had to manually go to Tasks...Clean, Tasks...Build, Tasks...Run........... everytime!.
I'm pretty stuck to eclipse, although I like a lot more the way Microchip did it.
So, just solder these two wires (ignore the eeprom for now) and report! Nothing is adjusted in the ADC part, but the Vinput should work, and the NTC if it's the same type...
The thermocouple op-amp does roughly the same as in the quicko, except that in the Quicko it's divided in two stages.
But the final gain is similar, 234 on the Quicko, 250 on the KSGER... The temp will be a little lower on the KSGER.
Sadly the 103RC doesn't support I2C fast mode plus (1Mhz). We could manually try oveclocking it a bit, but first see that it works!
Although the ssh1106 datasheet tells that the max rate is 400Khz, it worked perfectly at 1Mhz on my stm32f072...We'll see.
-
Thank you.
Currently waiting on some better amtech flux in the mail. Because the pink chinese stuff has bad fumes. When my flux arrives... later this week.
Then the plan is to:
*replace adc
* replace 3.3v regulator
* replace mcu
* remove eeprom, its not currently being used, right?
Because the closed firmware uses the eeprom, i will probably try to back up whatever 'lock codes' or calibration settings are stored on it be the commercial firmware for back up purpose.
Ok. So the i2c bus display mod looks great. Because anybody can do that, it does not hurt anything.
So my main question is should I delay replacing the ADC and the 3.3v regulator to begin with? To know the behaviour with the stock component.
The other thing I could spend time (wasting time on), is setting up an arduino to talk to this thermocouple module. To take independent temperature measurement. To be able to cross check what the actual temperature is. However I dont know how well that is going to work. It is just a regular thermocouple. If it can adhere and stick to the blob of molten solder at the end of the tip. Or if you need some more special equipment IDK.
Thanks for checking out the vscode platformIO, and setting up the cubeIDE/MX project here for my board! This has saved my time, as otherwise would have taken longer to get to this point. Although that would have been fun too! However skipping that part lets me get on to the hardware mods.
Always getting interrupted, doing other things in-between which are not related. Hopefully by next week. Looking forwards to this!
Today was spent rewiring a T12 handle back together. Nearly broke it. What a mess. And the big knife tip was no good after all. It's too long for regular tasks. No contact area. Should have gotten something else instead. Like a bevel tip. Damn. Anyhow it is what I have to work with for the time being.
-
I don't think the main problem is the regulator itself.
Stepping down 24V to 3.3V with a linear regulator will build a lot of heat.
Only 50mA will cause more than 1W of heat, in than small board it will overheat easily and start throttling.
I have these and are great: Small, efficient and very convenient.
https://es.aliexpress.com/item/32768078949.html
I suggest to use a buck converter like these to step down the 24V to 5, then the LDO to give clean 3.3V.
There's a big design problem anyway... it's using the same supply for the analog and digital parts.
The analog supply should be, at least, filtered with small choke (inductor) and complemented with more capacitors
Replacing the ADC? I guess you were thinking on the ADC but actually wanted to say a different thing?
I wouldn't remove anything, this is just a test to see if it works. The eeprom will remain untouched, so no problem.
I'm actually fighting with a bug, the i2c will work on first boot, but no more after posterior reboots.
The OLED inits, but then the I2C hangs at the first DMA transfer. Dang...
-
Yeah sorry it was late in the day. I meant to say "Op-Amp" there. And not ADC.
:palm:
Understood. It seems I already have a different buck/boost converter my drawer. That also covers enough the right voltage ranges:
https://www.amazon.co.uk/dp/B011P8IW4Q (https://www.amazon.co.uk/dp/B011P8IW4Q)
As you say to reduce heat dissipation in the linear regulator (final step). It makes sense to add this. Thanks!
-
It depends. Measure the current, maybe it's low enough that it doesn't worth it.
-
OK Cool.
Unforunately just had an accident. While waiting for my Amtech flux to arrive.
:palm:
So far, had:
* Setup my MAX6675 thermocouple, and checked it's accuracy against ice water, boiling water, body temperature thermometer. Check.
* Checked the performances of my other irons:
ts-100, bc tip
====================================
350c = 240c
oled v3.1 'r1' cfw, knife K tip
====================================
350c = 250c
oled ve2.1s 'r2' blue,, knife K tip
====================================
350c = 250c
Those were the maximum steady state reading after some time 'settling'. 1-2 mins. So they all seem to have a 100c drop, between the internal temperature reading inside of the tip. Compared to what the k-type thermocouple was sensing across the molten blob of solder, and through it's protective metal tin can.
* It was not yet possible for me to measure or plot the power draw. But I do have 3 very large shunt resistors. 15A/75mV. That would have taken more time to setup.
* Started to make a chart, to measure the temperature fluctuations behaviour.
The next step was replace the op-amp. And also upgrading the step down voltage regulator that goes from 24v to 3.3v. To compare the smoothness / noise of the temperature fluctuations. Before and after. This way I can be confident to know it works. Not to have to guess what might cause any potential performance issue is in the software or hardware. Should that be the case.
Unfortunately as I finished my 1st chart, I put the handle into the holster. An had to bend down to unplug the PSU from the AC power socket on the floor. While my attention was diverted I missed what happened. But it seems to be that the MOSFET shorted out. And created a small fire on the back of the board.
Up until then I had been running the iron constantly at 350c for some minutes. To plot the chart. So I am unsure what the cause was. It could have been any one of these things:
* If I had run it too long. And the MOSFET got too hot over a long heating time.
* If something shorted internally inside of Handle. When I replaced the handle in the holster.
* If when i leaned down, it moved the PCB around on my desk, and shorted against either the thermocouple can (housing), or some little solder blobs. I don't know!
The mosfet was on fire for about 5-7 seconds. Images attached.
When my amtech flux comes, I shall remove the mosfet and nearby components. And see if the PCB is too damaged. Or can be repaired. Sorry to let you guys down and set things back. For testing the open firmware.
The other problem might be I don't have exactly the same mosfet to replace. But I do have a few other mosfets for other project(s). If they are compatible or not, IDK. Will have to check.
OR I could 'borrow' the mosfet from the other OLED v3.1 'r1' green PCB. https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r1/front-display-hw-sw-version.jpg (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r1/front-display-hw-sw-version.jpg) Which is currently seems working OK / fine. That other controller was the one needing the 48 pin package F103. Which as we discussed was to take off from the Chinese "blue pill" clone board. Which is not genuine ST F103, but a chinese clone MCU.
I was trying to avoid it for now. Because you said yours had died. And I just didn't want to damage mine either. Since I only have 2 of those "blue pill" boards. And they are cool to have around for general use.
After I get my amtech flux I will post more images. To better see the damage underneath. And check what mosfets I have. Without having to wait to order replacement parts, which would delay things.
-
OK so...
* The burned mosfet (on the Ve2.1s 'r2' blue PCB) = AO4409. Dead.
What I have:
* The mosfet on the v3.1 'r1' (green pcb, working) = TPC8107
* My 2 spare mosfet (meant for other project) = TSM4459
Maybe they are compaible ? IDK. Have not checked yet. Just making a note of it. Then again maybe the PCB is killed. So it cannot be repaired. Then there is no point speculating.
I can also look for other MOSFETs in my junk pile. Some recycled PCBs from other thrown out appliances. Those component should be in good condition and all working. To remove / scavenge from.
-
Custom board is certainly a very good idea. Actually others have already thought about that, over in the Russian forums. There was a guy on radiokot selling such pcbs for a while, to the other russians.
Russian guys from radiokot forum are just copying original schematic and making pcbs for their dimensions and needs. And usually people are making pcbs for combo option (iron + heatgun), because it is overpriced on aliexpress.
* The mosfet on the v3.1 'r1' (green pcb, working) = TPC8107
* My 2 spare mosfet (meant for other project) = TSM4459
Maybe they are compaible ?
Any p-channel mosfet with low Rds(on), voltage 30+V and drain current 10+A will be good, such as TPC8107 (like you have on green v3.1), IRF7240, IRF9328, AO4407, IRF9310. Btw, TSM4459 that you have will be very good option for replacing burned TPC8107. I think your board is fine, except for burning traces, maybe electrolytic cap is also dead due to overheating, and check transistor which controlling gate of mosfet, most likely he's also dead.
Sorry for language mistakes, english is not my native language :)
-
* The mosfet on the v3.1 'r1' (green pcb, working) = TPC8107
* My 2 spare mosfet (meant for other project) = TSM4459
Maybe they are compaible ?
Any p-channel mosfet with low Rds(on), voltage 30+V and drain current 10+A will be good, such as TPC8107 (like you have on green v3.1), IRF7240, IRF9328, AO4407, IRF9310. Btw, TSM4459 that you have will be very good option for replacing burned TPC8107. I think your board is fine, except for burning traces, maybe electrolytic cap is also dead due to overheating, and check transistor which controlling gate of mosfet, most likely he's also dead.
Sorry for language mistakes, english is not my native language :)
Thank you, my friend! Very grateful for this comment. BTW the quality of your english was also perfect, along with the advice too.
:-+
-
With what firmware did that happen? If the mosfet heatsup, its probably caused by bad switching.
Ex. high frequencies, lots of rising and falling time, specially with that switching circuitry, the gate transition is pretty slow.
That's why I went to 50Hz PWM. Also the power supply noise at 1KHz PWM was unbearable.
Yep, the chinese used the frequency that us humans hear the most!
The AO4409 has 7.5mOhm RDSon. That shouldn't be a problem.
At 5amps (Far over from this application, should be in the 3A range) on-state the losses would be ~0.2W.
With only 4.5V Vgate it's 12mOhm, so 0.3W. Nothing to worry about.
The AO transistor are pretty nice stuff. I've seen them everywhere, specially in laptop motherboards.
Yep, they fail from time to time, but usually on 10+ year old devices with a lot of running hours over them.
It also happens with IRF and similar makers.
So, don't replace the mosfet for now! First we should understand why it happened.
I also made a little mess with my second board.
I was probing the mosfet source, the probe slided and bang! Direct short between gnd and the mosfet output..
Don't tell anyone, they might think I'm a newbie at electronics :-DD
Althought there are gate resistors, mosfets usually short out all pins, so that means 24V everywhere, including the gate.
That's why it's important to isolate them somehow from the MCU.
Check that the Q2 didn't blow too, and that the STM32 pwm output still works.
-
I've been fighting hard with the stm32 library for a whole week.
My intention is to set the max pwm to around 98% and set a Timer trigger when the output goes low, that directly fires the ADC without software intervention.
I knew the HAL documentation was bad, but now I must say it's absolutely horrendous.
Hey, you have to use HAL_ADC_DMA_blahblah. OK. It works in single ADC mode. Every time the Timer PWM resets there's new ADC data.
Now, in ADC interleaved mode (For faster adquisition) it either works all the time or it works only once, and there's no way to start it again, neither by disabling all the DMA and ADC stuff and then re-enabling them.
How the fu** do I retrigger it?
Ah, you have STM examples. Done in 2012 with a outated library that it's nowhere close to the actual HAL. And set in DMA continuous requests mode that never stop.
Reference manual explains a sh**, "bit for DMA continuous mode request" 1=DMA Continuous mode enabled, 0=no continuous mode.
Oh, yes, that explains it much better. Thanks!
Fu* you ST!
I've tried to find STM32 technical books. Checked them all. All do the same, basic stuff.
"STM32 Arm Programming for Embedded Systems". Looks nice huh?
Open it and you'll see that half of the books explains how a transistor works. Lets's blink a led.OMG...
The title should be "STM32 introduction for dumbs". I intentionally bought it from amazon knowing I could return in within 14 days, returned it after 5 minutes!!
Yeah, I know how to convert a single ADC channel and poll for the conversion till it finish. Crap.
STM is BS. Very nice on paper... but on real world...!
I love so much how Microchip libraries are made. Just the way the SFRs declarations are done, and it's bit fields, 1000 times better!
I hope they move on and catch ST soon. They've done a nice step buy ATmel, but still the fastest MCU is 300Mhz while ST has 550MHz one, also have dual core versions!
Although the peripherals are getting better, they still added LCD hardware and DRAM controllers pretty recently, while ST had done that in 2010 or so.
Let's compare two situations. You want to enable ADC1.
In Microchip:
All the registers are declared in the libraries as in the datasheet. Every register, every bit. So you don't need pointers, structs and all that crap.
You have ADC1CON1 register. But also ADC1CON1bits bit field.
It's easy as
ADC1CON1bits.ADON=1;// Enable ADC1
ADC1CON1bits.ADON=0;// Disable ADC1
BUT in STM32 you dont have access to ADC registers directly. They use relative addressing. A mess as you will see.
Where's ADC1 declared? Inside stm32Fxxxx.h:
#define PERIPH_BB_BASE 0x42000000UL
#define APB2PERIPH_BASE (PERIPH_BASE + 0x00010000UL)
#define ADC1_BASE (APB2PERIPH_BASE + 0x2000UL)
All that is done in:
#define ADC1 ((ADC_TypeDef *) ADC1_BASE)
So ADC1 starts at 0x42012000. Nice. No problem for now.
I want to enable ADC1. From the Reference Manual, I should set ADON bit in CR2 register.
Where's ADC1 CR2 declared? Nowhere! There's a generic struct:
typedef struct
{
__IO uint32_t SR; /*!< ADC status register, Address offset: 0x00 */
__IO uint32_t CR1; /*!< ADC control register 1, Address offset: 0x04 */
__IO uint32_t CR2; /*!< ADC control register 2, Address offset: 0x08 */
__IO uint32_t SMPR1; /*!< ADC sample time register 1, Address offset: 0x0C */
__IO uint32_t SMPR2; /*!< ADC sample time register 2, Address offset: 0x10 */
__IO uint32_t JOFR1; /*!< ADC injected channel data offset register 1, Address offset: 0x14 */
__IO uint32_t JOFR2; /*!< ADC injected channel data offset register 2, Address offset: 0x18 */
__IO uint32_t JOFR3; /*!< ADC injected channel data offset register 3, Address offset: 0x1C */
__IO uint32_t JOFR4; /*!< ADC injected channel data offset register 4, Address offset: 0x20 */
__IO uint32_t HTR; /*!< ADC watchdog higher threshold register, Address offset: 0x24 */
__IO uint32_t LTR; /*!< ADC watchdog lower threshold register, Address offset: 0x28 */
__IO uint32_t SQR1; /*!< ADC regular sequence register 1, Address offset: 0x2C */
__IO uint32_t SQR2; /*!< ADC regular sequence register 2, Address offset: 0x30 */
__IO uint32_t SQR3; /*!< ADC regular sequence register 3, Address offset: 0x34 */
__IO uint32_t JSQR; /*!< ADC injected sequence register, Address offset: 0x38*/
__IO uint32_t JDR1; /*!< ADC injected data register 1, Address offset: 0x3C */
__IO uint32_t JDR2; /*!< ADC injected data register 2, Address offset: 0x40 */
__IO uint32_t JDR3; /*!< ADC injected data register 3, Address offset: 0x44 */
__IO uint32_t JDR4; /*!< ADC injected data register 4, Address offset: 0x48 */
__IO uint32_t DR; /*!< ADC regular data register, Address offset: 0x4C */
} ADC_TypeDef;
And where's ADON declared? Nowhere as itselft, but as a mask:
#define ADC_CR2_ADON_Pos (0U)
#define ADC_CR2_ADON_Msk (0x1UL << ADC_CR2_ADON_Pos) /*!< 0x00000001 */
#define ADC_CR2_ADON ADC_CR2_ADON_Msk /*!<A/D Converter ON / OFF */
So there's no direct definition for all the peripherals registers, neither its bit fields.
You must create a *ADC_TypeDef pointer and assign it to the ADC base address:
ADC_TypeDef Adc1 = ADC1;
And still, we don't have direct access to ADON bit.
We have to play with masking:
ADC1.CR2 |= ADC_CR2_ADON; //ENABLE ADC1:
ADC1.CR2 &= ~(ADC_CR2_ADON); //DISABLE ADC1:
In Microchip this would have been simple as:
ADC1CR2bits.ADON=1; // Enable ADC1
ADC1CR2bits.ADON=0; // Disable ADC1
All I see is that ST implementation is unnecessary overcomplicated. Why so much mess?
-
With what firmware did that happen?
It was the Chinese commercial firmware it came with.
The AO transistor are pretty nice stuff. I've seen them everywhere, specially in laptop motherboards.
Then I shall spend the time to see if I have anything suitable in my junk drawer... it's just slow to identify random mosfets on random boards. To check they are suitable.
So, don't replace the mosfet for now! First we should understand why it happened.
...
Althought there are gate resistors, mosfets usually short out all pins, so that means 24V everywhere, including the gate.
That's why it's important to isolate them somehow from the MCU.
Check that the Q2 didn't blow too, and that the STM32 pwm output still works.
Thank you. OK yes, I should try checking the MCU boots and was not destroyed. After cleaning it up and removing the existing blown mosfet. Then I can also investigate to see if the pins of the dead mosfet are shorted to each other.
If you don't hear from me it's just because I am still waiting for this amtech flux. They messed up the delivery, or I will need to re-order it all over again. Whichever the reason.
I knew the HAL documentation was bad, but now I must say it's absolutely horrendous.
Yeah I understand it's difficult to use ST libraries. They like to make life difficult. I suppose you cannot use the HAL ADC abstraction library, for example like this?
https://electronics.stackexchange.com/a/202952/206468
Perhaps because it requires an extra code generation step? Which then fixes to a specific hardware? Actually if you follow the link in that post, is included a tutorial about it. The complexities we must put up with. Yeah I agree simple things like this should not be even half so difficult. ST overcomplicate.
BTW For other smaller new projects (not this one), my wish is to try the Rust programming language instead. And just avoid this ST stuff completely. Of course learning Rust is it's own burden / overhead. But they provide their own system of interfaces / rust HALs. To provide that abstraction layer. And of course Rust is not limited to only ST hardware. It also includes HALs for the other manufacturers.
However it's not suitable for this existing project. And of course most other developers use C/C++ instead. Not many people use Rust yet. It is still developing. Better to try on smaller, more simple projects first.
-
Yes, I'm trying to use the HAL. But they should explain a lot of things.
In the end you mess your brain up searching on internet and you don't find much either.
For the simple it works.
It's when you want to start connecting stuff, that pain happens.
Thanks for the link, looks interesting. https://visualgdb.com/tutorials/arm/stm32/adc/
I hope they use ADC Interleaved in DMA mode, otherwise I already know how to use the other modes.
And...! I think I confused Visual Studio with Visual Studio Code.
The first seems what they're using in that link, it looks very tidy! Was that Visual Studio what you were saying?
The second is an Arduino-like mess, everything must be set in JSON files, I don't understand that logic...
You must first master at JSON coding, then study how VSCode uses it.. and then, maybe, you can start programming!
Furthermore, after that you see how STM HAL works ... That day you'll be a step of getting into the drugs!
(For arduino I use Eclipse-based Sloeber IDE, keep the original ArBuguino away from me!)
What ST really lacks is Technical notes. Yes, the datasheet describes everything, but doesn't it make easy to understand.
If you ever saw the Microhip ones, they have the full datasheet, but appart of that, a whole book for each peripheral!
I've spent days just trying to domimate the timers and the ADC modes.
But I'm doing everything in my STM32F429 discovery (I got it in the industrial revolution era, 2013 I think).
I remember when I bought it, I saw the libraries and... Spend a week on it! No way I'm trying to understand this anymore!
They used 4x more text just to init a GPIO, that was a inmense mess.
The technical documentation was, yes, way worse.
So I used it as a paperweight all this years!
I'd like to met with people who made Doom run on it... How did they learn?
Even knowing the Cortex architecture, the STM perpiherals are on its own, glued to the ARM core.
-
And...! I think I confused Visual Studio with Visual Studio Code.
The first seems what they're using in that link, it looks very tidy! Was that Visual Studio what you were saying?
Yeah... I was referring to installing VSCode, then ontop of that also installing the "PlatformIO" Plugin for VSCode. This then allows you to install the ST libraries, or alternatively install one of several other systems. And be able to create new projects (or open existing ones). All they do is add an extra file names "platformio.ini". Which then is a config file to tell platformio which build system you want to use for a specific project.
Actually it gets messy in there. Because there are multiple different ways to do the same thing. At least when it comes to configuring your project. Especially for setting up things like openocd, for intercative debugging.
It also gets complicated because while platformio is a plugin of VSCode, it also has it's own plugins system. So you can install plugins for platformio itself too.
So you can get lost in there. However it does look to be 'the future'. So that you can try out other environments. For example like myself, for creating a new embedded project in rust. And of course you are not limited to ST hardware targets. But can instead create projects for other hardware architectures too. IF it works....
... it does not always work. Or not without extra tweaking etc. And the right extra 'magic'. Certain things seem to be broken in PlatformIO. And may be fixed 'at some point' in the future. Or by other users finding out how to configure things.
So just be aware of that going in. It's not really 'finished' yet. More of a moving target. Some things already work. Other things do not currently work because they require more work and 'polish'.
I've spent days just trying to domimate the timers and the ADC modes.
...
The technical documentation was, yes, way worse.
My approach to dealing with "the ST problem". We all know what it is.... the over complicated mess. My approach is to use google as the first line of enquiry. And refine search terms. Until I get to finding the frustrated blog post of somebody else who already got really frustrated by the problem and decided to write an article about it. Then I work backwards into the technical docs from there. To fill in any remaining details that were referenced in the article but not fully covered by it.
This approach seems to be the more time efficient way. Because it's simply not feasible to budget enough time to read through the ST docs. They are far too big! And also because the 'matrix' way they multiply x*y their product stack. Leading to multiple different docs everything spread around to find in different places. Or with * side-notes because the "high pin count version only" etc. It quickly becomes too much to keep in your all head at once.
-
OK. I just read the whole thread. I ordered a 2.1S (whatever that really means). Recent discussion is about the difficulty dealing with all the different hardware revs, different processors, etc., and STM development complexity. I go back to this:
And really the only platform i can actually think of which satisfies all of those requirements well right now (2020) is ESP32. It also has 2 cores so potentially can drive the display off a different core than thesoldering tip.
Seems to me that using the basic physical platform, and making a new, replacement controller could focus development onto a unified architecture which is supported by an easier to use development platform (PlatformIO?, although I haven't had any real problems caused by Arduino IDE). If an ESP32-DEVKIT-C will fit (seems like it might - it's ~28 mm wide, the black case KSGER is about 38 mm on the outside, and it looks like there might be enough room to accommodate the board height), that seems a good fit - non-technical users could easily load firmware via USB with little difficulty.
ESP32 - dual core, 240 MHz, 520 K RAM, typically 4 M flash/code. STM32, 1/3 or less of all of that, and only a couple of dollars more for a devboard than a bare STM32 chip. The ADC sucks, so an external one would be needed, but the rest of the circuitry would be comparable. Could even use the WiFi for OTA upgrades or simple web based configuration, and make it the first(?) IOT soldering station.
The Unisolder is very capable, but overly complex.
I'm decent at hardware, a hack at programming (maybe ugly, but works). But I'd contribute however I can.
-
Yep, I've been having an eye at the ESP32 too for a long time. Plus its ridiculous low price!
Okay, I finally found the culprit.
In the datasheet:
In multi ADC mode, the start of conversion is triggered alternately or simultaneously by the
ADC1 master to the ADC2 and ADC3 slaves, depending on the mode selected by the
MULTI[4:0] bits in the ADC_CCR register.
Then at the Triple interleaved mode description:
If the conversion sequence is interrupted (for instance when DMA end of transfer occurs),
the multi-ADC sequencer must be reset by configuring it in independent mode first (bits
DUAL[4:0] = 00000) before reprogramming the interleaved mode.
DUAL[4:0]? Those bits don't exist! It's refering to the MULTI[4:0] on the ADC_COMMON register!!
Anyway it doesn't work that way. I also need to reset the DMA bits in that same ADC register and put them back.
For the last instance, I tried a small delay in the Main loop, between conversions, and guess? It became in the delay!
After some cursing:
void SysTick_Handler(void)
{
/* USER CODE BEGIN SysTick_IRQn 0 */
HAL_IncTick(); //<---------------------------This wasn't generated by CUBE IDE!!!
/* USER CODE END SysTick_IRQn 0 */
/* USER CODE BEGIN SysTick_IRQn 1 */
/* USER CODE END SysTick_IRQn 1 */
}
What the hell? Missing one of the most basic and important parts?
Why I have to feel frustrated 24/7 using this?
I'm pretty sure I will drop STM32 soon and get a 300MHz SAMC from microchip... Or learn ESP32!!
Tomorrow I'll have a look at the Visual Studio+VisualGDB combo. But the CUBEMX is the same so...
The worst is that I don't need to code anything.
Now it had become a personal issue, why doesn't it work? Wanted to clear up the matter so badly :-DD
-
And really the only platform i can actually think of which satisfies all of those requirements well right now (2020) is ESP32. It also has 2 cores so potentially can drive the display off a different core than thesoldering tip.
I wrote that comment a long time ago. Sorry for saying it... Because the comment is badly informed. I was since corrected on this point by somebody else who is more knowledgeable. The ESP32 is not actually going to make any improvement (at all). In fact ESP32 has it's own problems / issues. And could be worse. It is not so suitable for this application. Other MCUs are a better choice.
[EDIT] Specifically the ADC on the ESP32 is utter garbage. And when you switch on the built-in Wifi... well that will inject interference spikes all over the sensitive op-amp gain stage going into the ADC. So bye bye to accurate temperature measurements. You would then have to add an outboard adc module, and physically distance it away from the ESP32 and it's antenna. Doing all of that might perhaps be a fun experiment. But does not seem worthwhile. Compared to just ditching the wifi (because you don't really need it for this application). And instead just using a faster MCU from a different manufacturer. [EDIT2] not that we need a faster MCU it seems? all except for driving more advanced graphics to the LCD. Which (again, we don't really need for a soldering iron).
-
Sorry for saying it... Because the comment is badly informed. I was since corrected on this point by somebody else who is more knowledgeable.
Actually, it isn't, and you're arguing against yourself. WiFi obviously isn't needed, and I mentioned the need for an external ADC (<$3).
But my comment wasn't necessarily specific to the ESP, it's just something I'm more familiar with (ESP32-DevKitC). The point was broader - there's so much work being done simply to keep up with all these variants that is seems some common replacement controller would make sense.
I think the ability for anyone with a PC to easily flash the code without needing additional hardware is important. So, USB and a bootloader, basically. Devboards cost less than the sum of their parts for low quantities, and would make construction simpler (a whole lot of SMDs already soldered for you). I believe Blue/Black Pills also support a bootloader which allows flashing via USB. Looks like I can buy one of those for <$10 each on Amazon. But, I understand there are potential issues with getting a counterfeit, not-always-compatible STM32 on the generic boards. I haven't seen any similar issues with the ESP32 stuff, and you can get a genuine one from a distributor for $10.
-
Mikes those are totally some good points. And I agree with mainly the ease of development aspect you brought up. Wheras we mostly? Don't seem to need the extra performance or features offered by ESP32 platform. From the perspective of ease of development, I do not wish to discourage anybody from trying to develop on ESP32. So long as you understand the limitations. But also I think we don't understand each other in terms of the cost of those ESP32 modules. Because they used to be about $6 each? I think? This was significantly higher than the cost of other MCUs.
In terms of using an ST MCU with usb DFU for firmware update. Then the TS100 open source firmware has already achieved this on a fairly low end STM32 series part. So it would make sense to borrow code from that project, it already being open source itself. Rather than try to reinvent all thse aspect for STM32 platform by ourselves. And that is still a lower development cost (efforts) than doing somethine else as radical as, for example, switching over to ESP32.
Another point about the Blue pill.... it's not clear ATM why David's blue pill actually died. However those specific chinese clones on the blue pill are 'fairly close' to a real F103, aside from the different Product ID code. Anyway... to be sure of a genuine ST part here is a link to purchase a "black pill" on aliexpress. On those boards is a low pin count STM32F4 part.
https://www.aliexpress.com/item/4000679874594.html (https://www.aliexpress.com/item/4000679874594.html)
Please note that the above product ^^ seems to be priced somewhere 'in between' the cost of a blue pill chinese clone. And the cost of an ESP32. And it's performance is also somewhere in between.
I uhm... don't actually fundamentally object to other MCU platforms based on their merits. Because many different platforms would be more than capable of this task. Rather my objection is that by splitting our efforts... then collectively we achieve far less in terms of compatibility and features. Wheras if we just stick along with 1 main platform then it is far easier to keep a common codebase that remains compatible with the most number of different hardware configurations an features.
This same argument also goes for incorporating support for extra different tips beyond the T12. Including the various different JBC cartridges.
At this point I have seen multiple other 'worthwhile' GPL open sourced hardware + firmware projects for T12 and JBC 245 on github. Probably about half a dozen or so. However they all suffer from this problem of being completely isolated and fractured development, requiring a specific unique hardware design. And either having poor performance or 'whatever bugs and issues' that stop them from being a seriously usable and dependable product.
Adding another project to that growing list seems like a complete waste of time to me. This is why I generally tend respond overall negatively to the constant suggestions of switching to different MCU platforms. Without enough serious justification.
I think the short answer is that USB dfu on STM32 should be possible. However listening to DavidAlpha here, it would seem that there is not enough space on the cheaper versions of STM32 family. So perhaps if it is possible, then it should be considered for a compiled in/out option. So that the lower end parts can still share the same unified codebase. This is my opinion until somebody else independantly comes out with a kickass controller based around ESP32, all done for us complete with support for JBC tips, etc... which you never know! Might happen.
Until then my preferred (next best) alternative to this project happens to be an arduino based controller. Which was designed specifically for the JBC tips only. But that is not of concern here! Just some other pet project.
-
In fact I refuse to keep developing for 16/64 RAM/flash devices.
As I said before, the firmware is done in a way that you can't control the used RAM.
It's all ok until you add few more lines of code and suddenly the stm32 directly boots into the hardfault interrupt, with no way of debugging.
Delete the Splash logo frees up few bytes and it works again. Or deleting the new code and keeping the logo...
The compiler tells that the flash usage is 99% full but then the RAM is other thing, you might think you have free RAM, but malloc needs all the space you're allocating to be contiguous, then you no longer have that much usable RAM.
I don't like the malloc usage in mcus. It's ok in a system with lots if RAM, but not here.
Since using my 32f429, I only had one hardfault, which I quickly debugged and found to be a uninitialized pointer.
A breeze in comparison to the smaller one.
The fw should be re-done allocating everything at compile time.
Not sure if it worths the effort...
About the USB, stm32 already come with USB DFU so it should be easy as pulling boot1 high: ( Don't get confused, he's downloading an additional bootloader to the flash)
https://ardupilot.org/dev/docs/using-DFU-to-load-bootloader.html
-
Ah interesting...
Dropping the support of F100 and F072.... that seems OK to me. They are not really worth the time to support IMHO.
But for the mainstream ones... Looking up these various products, it would seem that the 48 pin MCU on the blue pill is too small then? Since it is 20k ram, 64k flash, then you are suggesting instead to transplant the F4 from a Black Pill? However is that the cheapest cost option? Perhaps there are some other F103 parts with more memory+flash.
Wheras on some of these other PCB, they have the pads for 64 pins LQFP package. For example on my Blue PCB. This is the cheaper RCT6 sku.
https://www.mouser.co.uk/ProductDetail/STMicroelectronics/STM32F103RCT6?qs=%252BB84zevwoRA6TYzZIgOIoA== (https://www.mouser.co.uk/ProductDetail/STMicroelectronics/STM32F103RCT6?qs=%252BB84zevwoRA6TYzZIgOIoA==)
.... which has 48k ram, and 256k flash size.
-
OK, so I am looking through SKUs in the STM32 MCU Finder. And it seems the STM32F103 that are packaged as 48 LQFP... those ones all max out at 20kb ram. This is only +4kb more than the amount of RAM you specified, so is that too small? This would then mean dropping support for all F103 mcus on the 48 pads boards.
Anyhow (just in case) the best 48 pin parts with only 20kb are:
F103 Series
* STM32F103CBTx = 20k/128k, package: LQFP-48 (preferred), bulk price:$2.23
* STMF103CBUx = 20k/128k, package: UQFPN-48 (not ideal), bulk price: $2.24
F3 series, the RAM increases to anywhere from 24k to 48k RAM. The max flash + max ram SKUs are:
* STM32F303CCTx = 48k/256k, package: LQFP-48 (preferred), bulk price:$2.56
* STM32F358CCTx = 48k/256k, package: LQFP-48 (preferred), bulk price:$2.89
F4 Series
* STM32F413CHUx = 320k/1536k, package: UFQFPN-48 (not ideal), bulk price:$4.94
* STM32F423CHUx = 320k/1536k, package: UFQFPN-48 (not ideal), bulk price:$5.26
So for the replacement 48 pin part... (as cannot solder anything else to those versions of the PCB)... maybe the F3 series is a better one to target, instead of the F4? Because the F4 series does not come in the LQFP package, which is easier to solder than the UFQFPN-48.
Looking on my Black pill it has the following MCU,
* STM32F411CEU6 = 128k/512k, package: UFQFPN48 (not ideal), bulk price: $2.80
Ah-ha! So we finally see the reason why black pill is on F4. The cost of that version of the MCU is the same price as an F3.
I don't know what else to say ATM, except that it seems a bit unfortunate that the F4 series does not come in LQFP package. I think people can still solder the UFQFPN package instead, it just requires hot air station. And is more difficult to do.
So mostly I suppose we shall see, DavidAlpha, how much ram is needed coming up. And will get a better understanding about that later on.
Until then, know that the thresholds for RAM compatibility are:
* 20kb for F103, package = LQFP-48
* 48kb for F3, package = LQFP-48
* 320kb for F4, package = UFQFPN-48
That ^^ applies only necessary to the 48 pin pcbs. Which is the 'worst case' situation. Because other PCBs have 64 pads. Those 64 pin count options can be found with extra memory.
-
Oh, I didn't mean to throw it all away and close the door! :-DD
Actually the firmware is prety well done and it shouldn't cause much pain to work on it, I'm totally open at porting it to new mcus.
What I meant was not not break my brain enhacing it much further... but I still have some ideas!
But when the flash 97% full, and you think on adding new stuff... ok let's do it...
An hour later you see it doesn't fit. Or it fits, but crashes without explanation.
It has happened to me to the extend of adding a single variable and causing a Hardfault!
And you couldn't debug it! The debugger directly started at hardfault... before using git this was a very painful process.
Then I really appreciated de diff view.
Suddenly, you delete an unused static variable "uint16_t temp", that you had left behind when debugging something, that was doing absolute nothing, being used nowhere...
And it was working again! I got so fed-up of that kind of unnecesary headaches, that I decided to stop for some time.
For now, I've been porting an old stm32f429 project, an oscilloscope from a german programmer, and adapting it to the new HAL libraries, as a self-training experience.
This project uses a lot of peripherals in advanced modes, so I'm learning a lot, specially timers, ADC and DMA. The datasheet is close to burning too :-DD
I think when I return to the T12 in few days or weeks, I'll have much clearer ideas!
I also looked for better, compatible stm32s last week. Don't need to swear that we both went to aliexpress like a bat out of hell!
Reached the black pill too... very nice mcu for the price. But the FPQ have two problems.
First, the QFP48 drops exactly in the inner part of the QFN48 footprint. Extremely close but the pins won't match.
The inner distance of the QFP is 7.3mm, while that same measure is the QFN's outer.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1114042;image)
If the footprint in the pcb is bigger, then maybe it can be done.
Another problem it's located in the supply pins.
There are minor diferences, the pin 22 is Vcap in the STM32 3xx and 4xx series, while in 1xx and 0xx series it's a GPIO.
Not a big deal unless that pin is already used.
Yes, people like us can cut, solder, burn, replace, scratch and break with no problem, but most people just wants to flash the stock board.
The stm32F3xx are a nice step forward in capabilities. In a board with an unused pin 22, just scratch, solder a cap and go...
The QFN is not that hard to solder by hand though. A nice tip and few lbs of flux will get it done!
The main issue is that you won't be able to solder the bottom ground pad.
Will work anyway, however the signal noise ratio will probably suffer.
About the mcu specs... I think the 20KB will be ok.
4KB extra ram is plenty of RAM for an already done firmware that doesn't need any more.
The problem was with my 072, the poor thing was having a hard time, like women in their 50's trying to get into the 20's wedding dress :-DD
(Also men do! Everybody's searching for something to get offended these days haha)
-
Wow - thanks for checking these details! Very thorough. Also very nice to hear about the 20kb ram limit not being an issue for the F103.
Yeah the PCB pads can be intentionally be sized halfway inbetween either type of package. And it will work fine for hot air. In fact the pads on my green pcb oled (v3.1) have the longer fingers for accomodating LQFP. Yet it came from KSGER with a QFN soldered onto it instead. Seems to be fine.
:-+
-
Finished the stm32f429 thing... I understood most of the libraries, but the DMA2D and LPDC...huh, they make manuals for people who already know how to use these things.
Now back with the T12. Had to find a way to reduce code usage...
When enabling a font and using just one character, the flash usage increased a lot.
So its seems the compiler can't optimize the font tables...
I adjusted the fonts so they only had ASCII chars between 32 and 127 (The basic ASCII set). And replaced the '~' data with the 'º' (The only extended ASCII code used in this project).
The flash usage went down by a 22%!... Much better.
This is what I planned to do. Reserve a fixed small PWM time from the PWM total period, limiting the max duty.
In the case of a 50Hz PWM, we take 1mS for measuring... that gives 95% Max PWM duty. Not a big loss.
At least we are doing that with absolute control. Is there any benefit on going to higher pwm frequencies for "slow"(From a micro-second perspective) heating a resistor? I don't think so?
With 64 conversions, it takes 64uS to teh ADC, so it would be nice to know the PWM output fall time and adjust the dead time.
I tried to paste here but the usual tab havoc happened :-DD
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1115674;image)
Time to dust off my old Philips PM3055 60MHz oscilloscope. To do it right, I also have to ensure that the cap in the amplifier doesn't discharge, that would void the iron detection.
Errr, the Vref and Vsupply channels are useless. So they'll be removed. Or maybe sampled later, outside the PWM off timelapse.
Sadly the tim17 timer is very basic, only provides generic interrupt. Would have been great if it had trigger output, so the second timer started automatically without the need of interrupts.
-
50Hz PWM is fine, I kinda don't like the 5% power loss though. You might not have to sample temperature so often?
Take a look at T12 Hakko Patent US6087631A (https://patents.google.com/patent/US6087631A/en) using 1/2 mains-cycle sample rate but longer PWM; includes the oddball thermocouple lookup table.
The thermocouple temperature measurement blanking-time is really important.
You need time for the mosfet to switch off and D-S capacitor to discharge. One guy said 500usec was plenty including the time at the end for doing a burst of say 10 fast ADC samples.
I thought some good work was done here: https://www.hackster.io/sfrwmaker/soldering-iron-controller-for-hakko-t12-tips-on-stm32-c50ccc (https://www.hackster.io/sfrwmaker/soldering-iron-controller-for-hakko-t12-tips-on-stm32-c50ccc)
Might be worth a read: http://dangerousprototypes.com/forum/index.php?topic=5264.0 (http://dangerousprototypes.com/forum/index.php?topic=5264.0)
-
That was just an example! :P
Actually it worked pretty well with 60uS dead time, although some spurious noise appeared from time to time (sudden 10ºC jumps).
I know that it works because when I plug a totally cold tip and set the power to 1%, it measures 60ºC which is the lowest it can measure, so there's no power there.
The ADC is always sampled in the moment that PWM output goes low, so the duty doesn't matter here.
At 80uS it appeared to stop doing it, I finally set it to 100 for better clearance.
The ADC takes 91uS to send 64 samples. Total time about 200uS = 1% of the PWM .
But because I'm also sampling the NTC. If I do it with 16 samples and only the iron tip, that would be 23uS. So 130uS loss at most. That is 0.65% loss.
With this method actually the power delivery is pretty awesome, it heats up to 350º in 6secs and stays +-3ºC.
Also you can hear the PWM being totally constant without strange noises. The good of doing synchronous measurement.
Next I'll trigger the ADC again while the PWM is operating to get the rest of the measures without disturbing it.
-
Some playing with EMA and DEMA filtering.
First I tried EMA, but it's slow and undershoots (causing the PID to overshoot), and causes oscillations.
If you adjust the pid, it will work on that range, but big changes in the temperature will cause oscillations again.
So, now I'll try the DEMA... its faster, but overshoots a little (opposite as EMA) looks nice on excel.
If anyone wants to play with it, I attach the excel sheet too. You can quickly modify the filter factor, ADC noise and ramp rate.
The noise is generated randomly around the configured value
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1116790)
-
Wondering if either of those methods... if would work better along side to work with the other algorithm, instead of PID. It is possible to replace PID. The thing guy on the other forum thread shared his C code. Sorry I cannot remember the name of it right now. It was linked previously.
-
Yep, that was my next task, I'll see how it performs.
-
Well, my last tip died.
This one didn't overheat, the temp started to jump back and forth making the system PID crazy, in last instance I notice it measured 400ºC though it barely could melt solder, and a moment later it stopped working.
I dismembered the dead tips :-DD and what a deception. The rigid wires that go between the heating element and the connector had wayyy high impedance, in most it had ~0.7ohm( I cut 6 and set them in series, it measured ~4ohm).
So from 72W, 60W are at the tip. and 12W at the wires! I guess (I hope!) this is not the case of genuine Hakko tips.
One of them looked better, with thicker wires, but no! It must be a different material, was 1.6ohm per wire! 3ohm in the wires!
I remember one of these bastards heated like hell, so much that the nylon in the connector had slighly melted. After a while of soldering you couldn't hold the handle anymore!
That must have been this tip. No wonder why, 27W in the wires, 45W in the tip...!
I might even lower the voltage to 18V or so. The PWM rarely went over 50% even when soldering big ground planes. The heat transfer is not that good.
How do the fake JBC tips do?
-
I think most of the software work is in the fault handling.
The cheapola T12 clone tips are notorious for having bad connections. Either the handle's plug or the crimp collars go bad, so you intermittently get an open thermocouple/heater.
Depending on the thermocouple op-amp circuit, this would be seen as flickering between full-scale say 500ºC and the actual tip temp. You code has to constantly check for open TC. They really need to add the standard 1MEG pull-up to the TC input.
Other op-amps will float to the lowest TC temp which might be why your PID went too hot?
If the tip temp keeps climbing when heat is off, the mosfet is shorted and hit the beeper.
You can also model the total heat input to the tip (simple integrator) as a sanity check on the temperature reading. Yes you don't know the actual heat load (wet sponge, soldering a piece of railroad) etc. but as an "observer" the code can keep an eye out for gross troubles.
Note I have also seen the CJC value get corrupted and go to a nutty value (or overflow a variable), which software can run with. Would you expect CJC of -100ºC ? Well, here in Canada I have soldered outdoors at -20ºC but I saw the KSGER S/W screw after up the sign change because likely an unsigned int. is used.
-
All those bugs were fixed since I started working on the firmware. There are no bugs on the temperature sensing or PWM generation, all the posibilities are taken in count.
If the handle circuit breaks, it will measure a very high temperature, so there's no danger.
In the instant of aN open circuit it measures 650ºC. The PID goes to 0, the gui disables user controls and shows NO IRON.
While no iron is detected the PWM is limited to 1%.
The old fw had a very weird NTC algorithm that absolutely didn't work.
I only burned a tip ever by a software error, and it was few days ago due the compiler not taking a define correctly.
Otherwise, all the other 3 burned tips were my fault by debugging and halting the core with PWM being at 100%.
I always disconnect the handle when halting the cpu, but you only need one mistake! :-DD
When this tip failed, the temperature rised instantly +50ºC when the power was on and the next cycle -50ºC. So it was something wrong in TC.
That tip had been done that randomly since last week. I knew it was the tip and not the software because all the rest worked well.
I've debugged the timings and it's like a swiss clock.
When the hardware sets the pwm low, triggers a delay timer, the timer triggers the ADC, the ADC interrupt resets the adc, calculates de PID and the cycle starts again.
So everything is isolated from the main loop, the PWM or the ADC won't miss anything because the gui is busy drawing, for example.
I've found this and it's very tempting! JBC handle + 2 tips for 30 bucks!
https://es.aliexpress.com/item/1005001530229488.html
Edit: I bit the bulled and bought the JBC ! Canceled the T12s
-
I can try draw the schematic from your pictures of 2.1S r3, the board is very similar to 2.1S deluxe version with the desoldering option. Black solder mask is no fun.
Today i received my STM32F101RBT6. Because of poor chinese packing, pin64 was too bent and when i tried to push back, it broke. From what i measured, pin 32, 48 and 64 are internally connected together (they are all VDD). So i suppose i can use it like that without any problems.
I was a bit predictive and orederd 2 chips, so anyway i have one chip with pin64 broken and one chip complete. Just in case...
-
Try, if it doesn't work , then you'll know it was important !
Now the problem is your fw, where do you get it? Do you have stlink programmer?
You can be a guinea pig that will propaby die or result seriously harmed/ disabled tester!
Once I got few more details we can try t if you like
-
I don't have the firmware yet and neither the STlink, but it should come in few days.
I just finished my schematic and passed over to floobydust. He will have a check and we'll see how to find a firmware.
-
Was it a Ksger v2.1s r3 in the end?
-
Yes, i believe so.
From pictures it's the same board. But mine was without onboard battery. Must be attached through the white connector.
-
I don't see the utility of a RTC on the soldering station.
For what? Having a clock? Replacing the battery every few months?
-
Hahahaha... exactly.
My Quicko statipn doesn't have clock. And i don't miss it.
-
In fact, the I see the PTDreamer stock firmware too complicated.
Too much actions and submenus required for simple things.
I'm trying to improve that.
For example, entering the screen Brightness menu shows only a big number, rotate to adjust, and exit at the first click.
without having to navigate up/down/ or having to go to exit/save. But its my personal liking.
The waiting for the C245 to arrive will be endless...
-
I decided to put a bit of humour when the thing crashes... 1KB less but worths it!
-
Hey guys, Sorry for being absent here. As per usual had some other interruptions after fixing my pcb.
dismembered the dead tips :-DD and what a deception. The rigid wires that go between the heating element and the connector had wayyy high impedance, in most it had ~0.7ohm( I cut 6 and set them in series, it measured ~4ohm).
So from 72W, 60W are at the tip. and 12W at the wires! I guess (I hope!) this is not the case of genuine Hakko tips.
Very interesting!
But can you also tell us which aliexpress store you bought these T12 tips from? Was it KSGER or the QUICKO store? It would be helpful to know the source.
Because I have this so-called "high quality" black tip K from the QUICKO store, and it cost $7. Instead of the normal $3.50, for the regular cheap T12 tips.
Measured it's total impedance from pins 2-3 between heater + and heater -. And the resistive impedance (at room temperature) measured about 9.0 ohms. After subtracting the 0.9 ohm impedance of my multimeter probe leads.
Not sure if that is good or bad. Have asked some people on Discord, will see if there is anybody who will reply. To compare others.
One of them looked better, with thicker wires, but no! It must be a different material, was 1.6ohm per wire! 3ohm in the wires!
I remember one of these bastards heated like hell, so much that the nylon in the connector had slighly melted. After a while of soldering you couldn't hold the handle anymore!
That must have been this tip. No wonder why, 27W in the wires, 45W in the tip...!
Good to know! :-+
-
How do the fake JBC tips do?
Not sure, but might be pretty good? For $15 I purchased a C245-029 tip (=JS02 bent tip, smallest) from "KNOKOO Store" on aliexpress, here is nearest current items, they only sell in bulk now:
https://www.aliexpress.com/item/457967413.html (https://www.aliexpress.com/item/457967413.html)
And it measures 3.6 ohm (lowest) across the heater (pins 2-3) on my multimeter. However my cheap multimeter is not very accurate! (subtract about -0.8? ohm in the leads?). So that is under 3 ohms.
I believe that looks like it's a good one, right?
The tip is marked "864858 JBC |<|" and look of a high quality. It would not be surprising... if they were made in the same factory as the real JBC tips. The KNOKOO seller also seems to be selling many other high quality soldering tools / related products for manufacturing.
I've found this and it's very tempting! JBC handle + 2 tips for 30 bucks!
https://es.aliexpress.com/item/1005001530229488.html (https://es.aliexpress.com/item/1005001530229488.html)
Edit: I bit the bulled and bought the JBC ! Canceled the T12s
Absolutely fantasstic. Great! Thanks for getting the JBC handle! I have to say that is an excellent price, even disregarding the free tips, a bonus!
My handle cost +$10 than that, and it didn't come with any tips. So it's a great value. I think we can take photos of both our tips (when yours arrive). And compare the laser markings and the tool markings. To see if there is any problem. Hopefully they both source from the same factory. Then it's super value indeed. At that price. Great! We shall see.
Maybe there is room for both T12 and JBC tips in the world? Since T12 tips are "usually cheaper" than the T245. However the performance is less than JBC. The quality is also a big question.
Do not see the point of buying genuine Hakko tips. Because the price is the same as genuine JBC tips, who are better? JBC. So rather it's about the relative quality and price of these "not genuine" chinese tips.
-
When this tip failed, the temperature rised instantly +50ºC when the power was on and the next cycle -50ºC. So it was something wrong in TC.
That tip had been done that randomly since last week. I knew it was the tip and not the software because all the rest worked well.
This is an interesting place to be. Because others (the Russians, in russian forums). Are blaming transient spikes on the power supply, not smoothed. The line noise on 3v3 which then makes it onto the op-amp high gain circuit (before reaching the ADC). Throwing off the temperature suddenly. Or they are blaming the op-amp itself being bad. As a chinese part which is either low quality or clone / fake. With some user reporting the problem goes away after changing the op-amp for different version (better alternative part).
IDK what is the truth, because I have not experienced this problem yet myself). Initially, it has been working OK for me, the temperature sensing. However on this Blue pcb at the moment I have 1.1MHz switching style 3v3 step down regulator ("should be good"). While the op-amp is not known. Unable to identify from markings. So-called "bad" 61LJV op-amp, which the Russian forums user explains here:
https://www.eevblog.com/forum/repair/brand-new-ksger-t12/msg3096285/#msg3096285 (https://www.eevblog.com/forum/repair/brand-new-ksger-t12/msg3096285/#msg3096285)
But what you are saying that for a while at the beginning everything was fine... then either something has slowly degraded. Or you have been running the tip for longer heating durations without break. And that caused the melting due to the high resistance in the leads.
Which is a different reason for the problem. IDK which is the reason. But it's really helpful to know why. Or perhaps more than 1 reason gives the same symptom....
Always watching to see if it happens to mine!
:-DMM
-
Found out why my mosfet blew up today!
Ironically :-+
as you were buying a T245 handle, I bought 2nd T12 handle for myself. This part was also recommended by Russians. But it should be better this time! ,hopefully.
https://www.aliexpress.com/item/4000311213864.html (https://www.aliexpress.com/item/4000311213864.html)
:-+
This is to replace my aluminium one, which was the problem.
Blown mosfet was in fact caused by dodgy handle shorting out. It's an aluminium handle see... and it's not insulated inside the 3 terminals.
The picture explains better. So what was happening? In brief: When strain or bend on the tip, it shorts the pin 3 heater + to the heater - & ground of the handle metal case.
(https://i.imgur.com/y458d8m.jpg)
This is such a poor handle, I do not recommend anybody else buy it. Multiple reasons:
* Pins not insulated to handle body. Could be fixed by wrapping electrical tape inside.
* Tip sticks out too far, so the tip to handle distance is too long
* There is no room inside the handle body, for the wiring to not get all squished and torn up / damaged and broken.
:palm:
Bad. Avoid!
-
From what i remember, mine have some plastic insulator over the connections. Something like in GX12/16 connectors, so no shorting problem.
I really like those aluminium handles.
-
I have been told that there are 2 different version, of this same aluminium handle. The "original version", and the "new version". The original version was better than the new version. At least in terms of the distance from the tip to the handle.
But they stopped making that now. It is no longer available. So I have got the new version here. This was discussed recently in the Russian forum (RadioKot). Except for my finding about how it was not properly insulated. Perhaps your example is, but not all from China are coming like that. So it could just as easily... be bad like mine. Who knows?
So the big problem is trusting it. But why cannot we just check it ourselves? To make sure? Because:
You cannot safely take apart this aluminium handle. Without damaging / destroying the fragile wiring in the process. Mine broke. Unless you use silicone grease lubricant on the strain relief. Because the wires are very thin, and there is no room inside.
Yet you need to dismantle the handle, in order to see / check if it was properly insulated. Or not safe, as mine was not. But in the process you damage the handle, and cannot safely fit it together, with a proper heatshrink on the wires. There is no room! Then you just get frustrated, and try to cram it all in there, (somehow). At which point the strain relief pops off the other end and will not fit back on anymore. Because it's being pushed out by the wires (no space). So you try to force the strain relief back on, really damaging the thin wires (yet again). That you cannot see / check they are ok anymore. Also they strain relief is damaged and will not fit anymore either.
:horse:
But that was my problem. Not to worry, maybe other people to not have such troubles. Because they use silicone grease on the strain relief. As recommended by Russian forums.
But why would you buy one in the first place, if you already knew this? In fact there was yet another drawback of it, I forgot to mention earlier:
* The metal conducts heat from the tip into your hand.
* This problem only occur (too hot to hold) after a longer duration of continuus usage.
* Problem is a lot worse when the tip itself generating a lot of wasted heat up at the wrong end, near the contacts, because that is within the handle. This happens if the tip is faulty, or is poor quality. Such as DavidAlpha measured earlier. High resistance!
By comparison:
The carbon fibre handle is better because it:
* Has a shorter distance from the handle to the tip. So it has better control like a pencil.
* Does not conduct the heat, but insulates / protects your hand from high temperature. No worries. It will never get hot.
* Does not short itself out randomly by accident.
* About the same price. Perhaps +$3 more.
So this was the recommendation given by RadioKot forum user. I come back to tell my experience after receiving my Carbon Fibre handle. And if any problem with it. Good or bad (either way).
:-+
-
About the tip oscillation, for sure, that was the only tip doing that. Even having extremely measuring delays didn't help.
Omfg chinese quality strikes again. From the total value of the, what's the cost of a plastic isolator...?
So the c245 is ~3-4ohm? I hope the Power supply handles that load.
Yes, there's no reason for ditching the T12s. The working method is the same, only the connections and the TC voltage are different.
I finally found the gremlin that crashed the mcu when flash usage was >9x%.
After a long afternoon seeing how the settings checksum was different on each booting, totally senseless, it suddenly came into my head!
I didn't took in count the system settings. It directly reads and writes to the last 1KB flash!
So the compiler is unaware, unless you touch the linker script.
Well, reduced the iron tips from 10 to 7 and that way it fits in 512bytes. As the flash page has to be erased whole, a single byte over the limit will need another 256bytes.
I think 7 tips are enought! Or are we T12 tip collectors?
I wanted the biggest font possible for the temperature screen, so to use the 22*36 font without eating the whole flash, I had to wildy strip and patch it to only use ~20 chars.
But that let me add more fonts, so now everything is nicely readable.
I think this is the limit for this fw in 16/64KB devices. Tried to add another menu to change the temperature units between Celsius, Kelvin, Farenheit... Errrrrr no way!
(Yes, I removed the trollface screen and neither, its the RAM). We'll see in the stm32F101/103.
I don't know why, but malloc did work last time I used it to find the biggest chuck of free ram.
Now it allocates everything, it will return a valid pointer allocating a bigger buffer than the RAM size itself!
That's a problem because now I can't measure the RAM usage by the screens. I keep adding stuff until it crashes....
I made a little video to show how It currently looks.
Keep in mind that I have no tips, so I'm faking the temperature, actually it's measuring 80°C with a pull-down resistor.
That's why the pwm doesn't fall when it enters sleep mode.
After flashing the settings are not yet initialized in flash, so it gives the error and resets everything.
That only happens the first time or if the memory gets corrupted.
https://www.youtube.com/watch?v=DD4ZN1ixw8A (https://www.youtube.com/watch?v=DD4ZN1ixw8A)
-
However, I already targeted this fw. Looks very nice and I suspect is way more memory-efficient.
https://www.youtube.com/watch?v=4YDcWfOQmz4 (https://www.youtube.com/watch?v=4YDcWfOQmz4)
-
So the c245 is ~3-4ohm? I hope the Power supply handles that load.
Its less than 3 ohm. So for 24v drive... P=V^2/R = 24^2/3. This would be 192 watts or 8 amps full load at 100% PWM. However I have seen a video of somebody getting 10 amps on a C245 cartridge.
This is why the JBC tip is faster than others to bring the tip up to temperature. The high current is only for a few seconds during this time. It should not going to stress the PSU for too long. Unless there is a bug in the firmware etc, or it remains full on 100% PWM by mistake.
Then, once at temperature. What happens then? The current is limited by the rate of heat transfer, for the rate of dumping new energy into a heat load. It is limited quite a lot by the thermodynamics, across the thermal junction. Somebody else said that this upper limit can be as low as 30 watts. However I'm not sure myself. Maybe it can be more than 30w continuus at the worst case. But surely it must also depends on the size of the tip area. Which is quite small surface over which to transfer the heat. And the relative temperature differential between the 2 metal parts.
SO getting back to the start: the maximum "burst" current is up to 10 amps, but only for 3 seconds. Therefore the minimum spec for the PSU should be... enough to provide that amount. For a short time. In order to get the maximum performance. Otherwise the heating up time, that performance will be limited by your PSU.
The cheapest Chinese PSU are not likely to perform up to their given spec. Unless it is of high quality, like Meanwell brand, etc.
So what I did was to buy a cheap 20 amps PSU here from China. To make sure and be "double rated". And not stress the PSU too hard. But also not pay very much. The PSU is big and heavy. If you want to pay more, then you might be able to get something higher quality, that is also more compact. And not need such a high over-rating as 2x.
Perhaps a really high current bench lab PSU. Like the Riden RD6018 for example. Although it has a high ripple current. And only 1 channel. But you can then also use it to power other high current loads too, for other tasks. And it will be a variable voltage, and with OCP over current protection. To help limit any possible damage.
Well, reduced the tips from 10 to 7 and that way it fits in 512bytes.
As I added the biggest font possible for the temperature screen, I had to wildy strip and patch it to only hace around 20 chars.
But that let me add more fonts, so now everything is nicely readable.
....
(Yes, I removed the trollface screen and neither )
To speaking for myself, I would like to see one day, each of these options configurable with C macros. Then having different build targets for each MCU. With enabling a recommended set of options. So that higher end MCUs with more memory can progressively have better font, more tips, etc. as the space allows. And not be penalized to the lowest supported hardware.
That is not urgent or anything. It can only come after supporting multiple build targets. And unifying the code base all together.
Great video BTW. The screens look pretty good. It's very impressive! You should be proud of your work here. It is also of a high quality, like the JBC tips.
:clap:
-
I checked some original JBC C245 tips of different type/code I have:
The HEATER Resistance ranges from 2,26Ω to 2,64Ω.
Thermocouple resistance ranges from 33mΩ to 38mΩ.
My only (by now) T12 tip:
HEATER Resistance of 8,62Ω.
I received my unit and it's not as expected, just another v2.1S hardware version!!!
The unit is a full one with Power Supply from KSGER, suffering from the well known two "BUGS":
- High Voltage trace under D2 Heatsink
- Missing Earth connection to the Case, Encoder and GX12 Connector.
Some Mica Insulator, a drill, and a little work will solve that without too much troubles.
Here is my v2.1S controller unit. (SW Version2.12)
[attachmini=1]
Here is its schematics. I put in the schematic my idea on how to use both T12 and JBC handles by using a GX12 PIN as a jumper to select T12 (jumper connected) or JBC (non connected) handle. Do you think it could work or maybe it will simply add noise and more troubles? I will try it when I get some GX12 connectors I ordered from aliexpress. I plan to cut out the GX12 connection board and wire a new connector so that I can freely remove the controller from the panel.
[attachmini=2]
-
I don't see the problem using the jumper. The root of the noise problem is usually in the supply to the ADC and the op-amp.
The TC has very low impedance, so the noise has not so easy way to come it.
However, once it passes through the amp... and it's badly done in these ksgers.
At least they should have added a small resistor in series with adc and the amp supply.
A 100 Ohm resistor with 10uF low esr ceramic cap after it would be already a big noise killer, the current is very low (1mA for the ADC) and won't cause more than few mV drop, but it's a very effective filtering option for low current devices.
The kser doesn't even have a cap on the amp feedback to prevent high frequency noise or oscillation.
And the effect gets worse with high gains.
I would solder a 10nF on top of R5. The bandwidth needed is really low, the temperature will not oscillate more than few Hz.
See this simulations. The input signal is 8mVpp, and the added noise is 2mV. A bit exaggerated but gives the idea.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1119686)
Being more optimistic, with only 100uV noise, multiply it with 250 gain and you got 25mV noise!
That translates to 12.5ºC noise in Hakko language! And gets much worse with JBC tips.
-
My only (by now) T12 tip:
HEATER Resistance of 8,62Ω.
Unless you actually tell us the name of the seller you purchased it from.... it does not help us find any better source better T12 tips. Or tell us if the clone tip is different from the hakko. Also including the tip type ot shape will help.
I received my unit and it's not as expected, just another v2.1S hardware version!!!
Looking at your PCB, it looks like the best v2.1 original version. I don't think you worry about the pcb. Thanks for including this. But again... which banggood seller was it?
-
And the seller... It was a year ago. I don't think that it'll any difference now.
They probably change their suppliers pretty often. So todays's tips might be totally different from what you buy in a week.
-
@DavidAlpha please also see this issue, for the JBC T245 handle. Another shorting problem. If this happens it can damage the cable, which is moulded into the plastic handle. Therefore the cable is not so easy to replace.
https://youtu.be/BxvPT4n7p4E?t=592
-
Here is the link where I bought my unit.
If you look at the reviews you can see that old lots were different. So you never know what you will get In future (or maybe just now). I ordered it from CN store (and was on sale, about 10€ less)
[41,45€ 19% OFF]V2.1S T12 Digital Temperature Controller Soldering Station Electric Soldering Iron Tips T12-K + 907 Handle Professional Tools from Tools on banggood
https://banggood.app.link/ELa95pSkObb
My only T12 tip came with the unit and is a K type one marked like this
T12-K 823151 31520
@DavidAlfa, I would add a 10nF cap parallel to R5 as you suggested.
I also ordered a Tip tester that I will get in a week or two, so that I can take some temperature measurements.
[12,42€ 27% OFF]DANIU FG-100 Soldering Iron Tip Thermometer Temperature Detector Tester 0-700℃ Professional Tools from Tools on banggood
https://banggood.app.link/7snIaDrmObb
I must say that, as far as I can see, T12 temperature seems quite stable. I think that K type tip I have was shipped with some lead free timon it. I checked and it melted at about 220°C set on the unit.
About T245 handle, the one a have was a wasted one... I disassembled it and the + heater contact was deep in the melted plastic! And that was an original handle. I don't know how that happened, but happened, once in a long time. By the way, JBC units should be in standby when you change the tip connecting the tip to the base extraction tool.
One last thing. JBC handles doesn't have the shake switch (and NTC), so you should take care of putting it in standby (or maybe sleeping mode) when needed (also when you change tips? )
-
It seems strange to me. I worked almost 7 years in a shop using a C245, repairing phones/computers, everything...
I had a round tip and a "knife" tip for serious pcbs. I only replaced a tip in those years.
I didn't need anything else, had a cheap hot air station also. The C245 worked so well...Used almost everyday without issues.
If you maintain the tip clean and don't abuse it (I rarely went over 380ºC) it wil last a lot.
When I replaced it, wasn't because it had stopped working, the tip had worn and looked like one of these... :-DD
(https://www.jbctools.com/cartridges/C245931%20(datasheet)_Completa.gif)
Maybe is the cheapo brand and its crappy internals. Being for hobby use, I think it'll be ok.
Today it was cloudy, cold as f** and of course, we are still quarantined. Like UK, 300 out of 365 days!
So played a bit making a Quicko pcb. The analog is powered from the TL431 and nicely filtered. Designed for 5mA, should be enough, but can take more if needed.
And using a high side mosfet driver (LTC4440) and a stm32F411.
I could panellize it and get 15 pcbs from jlcpcb for $6, but I don't think I'll do!
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1120102)
-
Hi. I am attaching pictures of my two controllers. Both are the same model 2.12s but have different STM32 chips, different op-amp, crystal seems to be different also.
Are those controllers already compatible with your firmware?
DavidAlfa: Can you please share pictures of hardware mods done to the 3.3V rail and op-amp you have replaced. Maybee also add links to aliexpress, where those components can be sourced. Maybe best on your git so it can be all found on one place.
TNX
-
2.nd controller
-
Huh? I didn't mod anything, worked pretty well as it is. Maybe you meant what dreamcat4 was doing, he's replacing the voltage regulator and the amplifier.
Well, and a blown mosfet haha...
I dodn't have these boards, so I can't try myself. If you have programmer we should get it working soon.
But I need someone for testing.
Most it's done, only the hardware layer needs to changed.
-
I do have stlink v2 programmer. Are there any quick manual hot to flash this controller and compile your firmware?
Also i can sacrifice the one with 61jlv U3 op-amp to flash it.
Is there an option to flash it back with original firmware and then activate it with codes, if your firmware will not work? I do not have any spare stm32 chips so will not desolder and solder it, will just overwrite them.
I saw on the Russian google drive some dumped hex files, are those original dumps from KSGER and how do I identify which are suitable for which?
P.S.:
May I ask why is the original firmware so bad and need alternative firmware? From your video I can see that there are some things missing that are present in the original one. Like stepping, startup behavior.
-
I have 2nd blue board f103 here. And it looks like the regulator is switching type, but at 1mhz. It is supposed to be ok according to other user reports. So the recommendation is to not replace it, instead of that DavidAlpha's capacitor noise smoothing. But check the circuit because these are a bit different from version to version.
The op-amp is unknown. There is no way to find and specs on it. So only replace if you have reason to believe it is bad. However you might instead have bad tip.
The crystal is not known.
For restoring, you are taking a risk. If you can manage to restore successfully. Then there will be a lock code after re-flashing. The key gen, and the eeprom will be cleared.
There is no DavidAlpha build yet for this version. It is yet to be generated. But he has put step by step instructions in the readme.
I still have to order soldering temp tester. The main reason I don't progress here is because I first want to document performance of the closed chinese firmware. As a baseline. This is not so much for the sake of knowing relative performance. But more to characterize the behaviours. To notice any bugs or weird behaviours if that occur in the open firmware. Since we are testing on a variety of different hardware boards. They are not all quite the same as each other.
For example if the board I have here has inferior component, such as crystal. And the closed firmware included some workarounds they fix in that. But DavidAlpha does not see that as a problem, because his circuit is different to mine.
I do not want to stop others from trying this software. It should be encouraged! For moving the open source development forwards. That is a good thing! Just be aware in case of unforseen issues.
:-+
-
May I ask why is the original firmware so bad and need alternative firmware?
Sure! Actually the original firmware is not so bad... For the most part it works quite well. However that does not mean we don't also need the option available for an open source firmware too.
It should be a free choice to users whether they want to play it safe and stick with the closed firmware. Or if they want to flash over it an open firmware. Just like the with TS100 iron. Same situation.
I do not discourage anybody from using the closed firmware. It is just a set of trade offs with different positive and negative for each one.
So if the closed firmware already works, why bother? Why make such efforts? Here is my attempt to list out, to explain the many motivations, for why to do this:
Reasons why we DONT want the closed firmware:
* The closed firmware is fixed. Due to the way it was developed, it does have the capability to be improved with new features.
* The closed firmware has lock code. Bad! We don't want that!
* The closed firmware cannot be dumped fully, so it cannot be reflashed if your build is not already one of the few versions available
* If the closed firmware boots into Chinese, and you don't know the chinese symbols... then it is also annoying to find the language menu. To change the language.
Reasons why we DO want an open firmware:
* By contrast, the open firmware can be recompiled for specific hardware, at will. So there is no worries that your specific board can be recovered back to an open firmware. Once that version of the hardware becomes tested and supported. Of course it isn't yet.
* We can change UI, menus, fonts, and use more memory. If the MCU has more memory.
* It gives the possibility to later on, maybe add support for other handles / tips. For example JBC T245. And other JBC tips.
* It gives a better trust in the equipment. If there is a problem, you can see where that is happening, in the source code.
* It permits open hardware also, to be supported with a common source code. Which then also means... the possibility for hardware improvements. Which would never be possible with a closed firmware.
For example:
* It gives a possibility for diagnostics / data monitoring features. Going through SWD, or through UART serial, back to the PC.
* It gives a possibility for USB DFU flashing. Like on the TS100.
* It gives a possibility for USB-PD over usb-c. With a separate outboard chip for handling the USB-C.
* It gives the possibility for other features, whatever you wish to add. Limited only by your knowledge, and imagination!
* The whole community can then benefit from all these improvements, for free.
Finally:
* With an open firmware, then we also do not need to buy as much the hardware from the KSGER or QUICKO manufacturers. Or other aliexpress / banggood sellers. For example if they do not make it a good enough product. Perhaps for cost reasons, or some stupid oversight, or lacking protections, which causes a fire etc.
From your video I can see that there are some things missing that are present in the original one. Like stepping, startup behavior.
Some features are disabled for memory, others are removed because they are not used often, and it helps to reduce the burden on the user to scroll past menus. Also: If a preferred option can be compiled in then it does not need a menu! You can just recompile it yourself, reflash. And you have your preferred option always-on.
-
Also i can sacrifice the one with 61jlv U3 op-amp to flash it.
Actually the op-amp on other board is another different, the SOT23-5 package with marking 621K1911. This smd package marking 621K1911 is also not identified either. So you have 2 unknown op-amp.
:palm:
So IDK maybe if you swap over just the op-amp. It they will both still work? Then your 2nd board with the F103 will be just like my one. And we can both use the same open firmware builds. Rather than have 2 different binaries for the F101 and F103.
The other thing however is that I must wait... another month from China. To get my RST FG-100 tester.
https://www.aliexpress.com/item/4000967030319.html (https://www.aliexpress.com/item/4000967030319.html)
Until then, I cannot take accurate temperature readings. Since my other temperature sensor reads consistently a -100C different than the iron. For all my irons, including TS100, etc. So my readings are not accurate enough to be useful. Maybe because it's not designed specifically for this task.
:-//
Well no matter the reason, new RST FG-100 tester should fix that, for $12. It will just take another month to come.
And the KSGER carbon fibre handle (from KSGER store). Should come at about the same time. Since I just only order them both right now. In the last 2 days.
https://www.aliexpress.com/item/4000311213864.html (https://www.aliexpress.com/item/4000311213864.html)
Is there an option to flash it back with original firmware and then activate it with codes, if your firmware will not work?
If you can reflash the right build, that is compatible, then yes maybe. However what if you cannot get the right hex? I searched already for this same Blue PCB. And did partial binary diff. None of the available .hex matches. And I have downloaded and checked all of the available closed firmware .hex / .bin available.
You will never know if it works until the point of flashing. So "maybe". Or maybe not! That is why to recommend buying a brand new STM32 mcu, that is pin compatible with the pads. You understand?
I have no reason to flash this for finding. Until maybe another 1-2 months. At earliest. Or perhaps never, because I actually have the spare MCU. Plus also I have v3.1 green pcb kept on closed firmware. So it would not be time efficient for this project, to waste the time check that. Since everybody else has many different boards. Only a few people actually have these same blue PCB.
I saw on the Russian google drive some dumped hex files, are those original dumps from KSGER and how do I identify which are suitable for which?
The process is to try to flash all of them. And if any will boot, then it will show the display. At that point, if successful. Then it will ask for code.
OR there is no compatible .hex available. Then you are forced onto open source firmware. With no way to restore back to original.
:-+
-
My firmware is prepared to be used with the hardware peripherals.
That is, I don't have i2c implemented using software. And those ksgers are using it that way.
It might be the reason why the stock firmware is so incredibly slow.
Mine did like 3fps amd moving through the menus was pain. Would move one step forward, then backwards.
And it used 1KHz PWM, so you heared a loud beeping all the time.
In my case the modded fw it's much better. But there might exist well done firmwares.
I've just committed the last changes as beta release. I hope not to be too arrogant :-DD. Pretty stable I must say.
Added some safety measures to make sure the PWM doesn't freeze in a high state when a system error occurs.
System settings checksum a boot and also while running (to save the settings), so I don't have to make a thousand functions for saving each bit.
And much more...A lot of effort in polishing small errors in the graphical system that caused weird representation.
But I'll be off for a time, because while handling te the handle wires, they slipped off and fell down exactly on the discovery board that I was using as stlink.
Yep, almost 30V to the poor thing. Luckly my computer didn't screw up too.
The MCU is cooked, it burns after few seconds, but somehow it's still is able to blink a led in it's agony
So time to get a stlink and another 103 for my discovery board.
-
Cool man! Not able to progress either, and for same reason: waiting for parts from China. All good.
:-+
Dropping metal conductors onto live board... is also something I can relate to. It's pretty easy to do! So no worries. Sometimes current limiting the bench PSU supply can help protect against shorts. But often that is not possible. Including when powering *not* from the bench supply. Which was how my mosfet caught fire.
BTW - just wanted to say that my repair friend has gotten back to me. And measured his Genuine Hakko tip. It is:
8.22 ohm
So that is the correct impedance. Between the 2 inner most pins heater + and heater -. To compare against chinese clone tips. I will forget this number! 8.22 ohm. Also my equipment is too cheap to measure these low resistances accurately enough!
:-+
-
Got 5 STM32F103CBT6 (128/20KB version) for 5euro. I hope they work.
https://a.aliexpress.com/_BOUYuD
Also a cheap stlink to play with. A quick Google trip revealed how to mod these to add more features.
https://pikabu.ru/story/delaem_stlink_v21_iz_kitayskogostlink_v2_6494848
-
Got 5 STM32F103CBT6 (128/20KB version) for 5euro. I hope they work.
https://a.aliexpress.com/_BOUYuD (https://a.aliexpress.com/_BOUYuD)
Here is good forum thread, many examples to help identify the genuine from the fake ones:
https://www.eevblog.com/forum/projects/do-you-have-an-stm32f103c (https://www.eevblog.com/forum/projects/do-you-have-an-stm32f103c)*t6-looking-for-your-help!/
Hope that helps! Well worth reading.
Another maybe useful? Suggestion is to look at the bulk pricing. For example here on mouser, you can see the prices:
https://eu.mouser.com/ProductDetail/?qs=WxFF5lh7QM3goh6GV5Ogig%3D%3D (https://eu.mouser.com/ProductDetail/?qs=WxFF5lh7QM3goh6GV5Ogig%3D%3D)
In ST MCU Finder tool, it shows $2.236 is the lowest cost they can be purchased from ST, the manufacturer. So unless it's overstock, obtained 'for free', or recovered from a defective failed board. Then the price should be more, to expect a profit by splitting / reselling in smaller quantities.
Perhaps another approach is to recover (by yourself) from other failed or broken device. Because these STM32 are used in so many product these days. All around us.
-
As long as it works... Haha.
In fact all the 100xx series seem to be the same all have 128kb and USB, supossely the 100,101 are cut-down versions (some might have defects, some not, it's a lottery), but chinese know that and program the 101 with 103fw, they usually work, with usb and everything !
That might explain why I could allocate up to 20KB ram before crashing my 072... It might have 20KB too!
This must be tried seriously. Modifying the linker script so the compiler uses all the thing and making a program to test the whole ram and flash.
Remember the the arduino T12 project I posted yesterday ?
The git page is great, has a ton of technical details. Like the op-amps, settle time...
https://github.com/wagiminator/ATmega-Soldering-Station/
I also found this. If you want to make your own Jlink (12MHz clock). And a lot of details on to change the firmware serial in case it gets blocked.Yep, I don't think it's too legal, don't use that professionally :-DD:
https://github.com/Kevincoooool/MCU_Link_Diy
About you guys just wanting to flash a new fw, and no interest in debugging or whatever, the DFU mode worked really well.
Just need a usb/serial converter, we almost all should have one already. Check ST AN2606 for UART connections.
Connect with BOOT0 set to 1. Open the Demonstrator gui, erase, flash...done!
I'll try to use my half-dead stm32F103 clone to flash st-link fw on it...
-
Well. I'm not todo proud of this, but without iron it's pretty remarkable.
The weird CKS chip worked well.
The stlink utility refused to recover it, downgraded to v4.3 and it worked.
Not only I have a stlink, but now it works in stlink+serial+mass storage modes!
Not too bad for an already (supposedly)dead blue pill.I suspect the stmCube does something weird in the startup code to make these to not work properly.
And yes, I edited the stmCube proyect xxxxxflash.Id file, and could use 128K on the 072! (verified some flash, not whole)
The ram definitely is limited to 16K. Reading further causes Hard fault.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1121566;image)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1121574)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1121570)
-
Hah! What a coincidence! Checking the flash I found an error, but not on the extra 64KB... on the "normal" flash!
That section was were the original fw keep erasing everytime, for every setting. I guess the flash weared out.
That was I feared and changed in my fw... too late! haha
In my case the bad address was 0x800FB84, it reads 0xFFFFFFFE after erasing.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1121704)
So I did this. Edited these parts of the linker script:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 16K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 64K
}
MEMORY
.rodata :
{
. = ALIGN(4);
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
. = ALIGN(4);
} >FLASH
Like this:
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 16K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 63K
FLASHBAD (rx) : ORIGIN = 0x800FC00, LENGTH = 1K
FLASH2 (rx) : ORIGIN = 0x8010000, LENGTH = 63K
SETTINGS (rx) : ORIGIN = 0x801FC00, LENGTH = 1K
}
MEMORY
.rodata :
{
. = ALIGN(4);
*(.rodata) /* .rodata sections (constants, strings, etc.) */
*(.rodata*) /* .rodata* sections (constants, strings, etc.) */
. = ALIGN(4);
} >FLASH2
By default it seems to use little or nothing of the .rodata, but if you add a new huge font, it will use it.
So it seems that .rodata will l get used only if the .text section is full? I don't really care...it works!
Declaring SETTINGS section will ensure that the program never gets written where the fw store the settings...
The result:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1121714)
-
Awesome! Cool man. Thanks for explaining this. So where was the linker script?
Do you think you can copy this post, into docs? For github. It's probably better as it's own separate markdown file. Otherwise it's harder to find in the forums here.
-
The problem I am having understanding... is because it is very difficult to find any information about NOR errors. Or "wearing of NOR flash". People say it should just always works. You can try to google. It is difficult to find such information.
:-//
There can be NOR defect at the factory. During manufacture. If this is true for your chip IDK. But if it was missed, by luck. That it did not trip over the bad address before now.
But usually when flashing, you also verify the flash is good afterwards, right? You re-read back all the bytes. And checksum compare. To the .bin. To make sure it flashed OK.
:-+
Only ever interacted with these MCU through "OpenOCD" program. Over SWD. I cannot remember now.
Could it be a bad flashing maybe? That is what these guys say.... Possible flashing problems for the NOR, on other STM32 series mcu:
https://community.st.com/s/question/0D50X0000AX8Hm3/stm32h7-internal-flash-error
The thread suggests if you have some bad stuck address, then "full erase" etc. To clear such issue. And get the cell straightened out.
:-//
It seems very strange problem. Since you have avoided it now... moving address. A great trick! Then maybe not worth trying to mess about more with full erasing etc. If this is your only one. While still waiting for the other ones, F103CBT6.
-
As I said previously, the programmer doesn't check the whole flash, only the used part.
If your code is 28KB, it will only check that.
It did never fail because I never went over ~94%.
It might be possible to change these settings somewhere.
The linker script is the STM32Fxxxxx_FLASH.ld that generates automatically when creating the project. You can open it at the root of the project, in the ide itself. Nothing special.
Now I bought an ultra cheap hot air soldering station.
https://a.aliexpress.com/_B0PhU5
My plan is to integrate the T12 inside too. No idea if there's room for that, but it's okay anyway if not.
-
As I said previously, the programmer doesn't check the whole flash, only the used part.
If your code is 28KB, it will only check that.
It did never fail because I never went over ~94%.
:palm:
Ah now I understand! Sorry for being slow... What you are saying seems to be that: after 80h there was a manufacturing defect in the NOR flash, so this part was binned as 64k part at the factory. So it always was a defective address.
So other people, who also want to unlock other chips using same method. They might have to define different usable regions, of different sizes. If their defect(s) are found at other locations. Which are not so close to the beginning of the next segment.
What would be even better, is a way to declare bad address locations for the compiler. To insert Jump instruction. To skip over only exactly the bad address segment. That is - if the segment is program code. Or some type of memory remapping for other segment types, like data.... But that would be more difficult. Perhaps not worth the trouble / efforts.
So long as these Chinese clone chip behave same for the IOs, ADC, etc. No worries.... the problem is when they do weird stuff. That deviates from the expected behavious, of the official ST parts.
Now I bought an ultra cheap hot air soldering station.
https://a.aliexpress.com/_B0PhU5
My plan is to integrate the T12 inside too. No idea if there's room for that, but it's okay anyway if not.
This station is from the 858d family. I have similar. It is never going to be a tool you will want to keep. Because the fan is in the handle. This means that the performance is limited.
So I would not recommend you try to integrate into that specific model of shot air station. Because you will most likely want to upgrade to a more powerful hot air station later on. Same situation here myself.
-
For the use I'll give to it, very ocasional, it'll be ok.
Yes all c8t6 are the same as the cbt6, all have 128K but upper 64kb are untested or have defect.
As I said, I don't know if the failure came from factory or was caused by the excessive flash wear by the firmware settings routine...
It works just selecting the CBT6 part instead the C8T6! The IDE nor the programmer complains.
No need to test anything, if your program uses a bad flash address it will fail verification.
I tried inserting a variable in the flash at that address, it didn't work when the program growed, the linker complained because the sections were overlapping.
So I had to make different sections.
Luckly assigning the .rodata section to the second flash space worked well.
This is just a dirty trick while I don't replace it. Or not...if it works, why spent money... Of course only for the DIY world.
-
I have ordered another one to see how it does.
The seller has said that it is stm32 based and it cost only 32€ incl delivery.
https://www.aliexpress.com/item/4000183089084.html (https://www.aliexpress.com/item/4000183089084.html)
-
Ask for internal photos. Their photos and the customer reviews show that it's using the STC chip, not the STM...
(https://ae01.alicdn.com/kf/Ufb0baa6d681e447086078003b9163728H.jpg)
Checkout this:
https://www.eevblog.com/forum/index.php?topic=160627.msg3352410#msg3352410 (https://www.eevblog.com/forum/index.php?topic=160627.msg3352410#msg3352410)
-
I have asked him:
05:20
On some reviews I cee that it is sct and not stm32 as stated in description. I can also see that some people did not get the tips included?
06:51
hi,friend.it is 5 Pin Stm32 station
we used sell STC,now all STM32
-
BTW - just wanted to say that my repair friend has gotten back to me. And measured his Genuine Hakko tip. It is:
8.22 ohm
So that is the correct impedance. Between the 2 inner most pins heater + and heater -. To compare against chinese clone tips. I will forget this number! 8.22 ohm.
I confirm the same resistance on T12 clone tips. I have a few and all have the same resistance ~ 8,22 ohm.
A friend got same board as mine, but is marked v3.1 and uses STM32F103. Mine is STM32F101.
Same HW 2.00, same SW 2.12. So i suppose the flash is the same.
Just 1 difference: board with F101 is much more brighter than this with F103.
The brightness is a firmware setting?
-
The brightness depends on both hardware and software.
At hardware level it has a resistor for the Iref.
And it can be adjusted by software, but based on the current set by the resistor.
Also the oleds have the burn-in issue, they will loose brightness over time. Specially the blue color.
Now make the equation: oled + blue + Aliexpress -> And you get the point!
Are you sure it's not adjusted in a lower setting?
The 101 is a cut down version, but nothing is really disabled, so all the extra stuff from the 103 could used at your own risk, it might fail, or not.
I'm almost 100% sure that they put the 103 firmware on it.
-
At hardware level it has a resistor for the Iref. - Can you tell me which resistor would that be? It can be found on mainboard or OLED board?
Also the oleds have the burn-in issue, they will loose brightness over time. Specially the blue color. - These OLEDs/controllers are both new, so could be only a hw/sw difference.
Are you sure it's not adjusted in a lower setting? - What do you mean? Is there a setting for the brightness?
I'm almost 100% sure that they put the 103 firmware on it. - So can i use any 103 firmware from Github or they are different, depending on board layout?
-
It can be found on mainboard or OLED board?
In the board. But I wouldn't touch that. You might reduce the life of the screen.
What do you mean? Is there a setting for the brightness?
I don't know, you must navigate in the menu and see if there's a brightness option somewehere.
So can i use any 103 firmware from Github or they are different, depending on board layout?
The board layout is absolutely important. The firmware must match all the inputs/outputs and it's connected devices.
What I meant is that the 101 can be flashed as a 103.
But the peripherals, memory... that the 103 has over the 101, will be a lottery.
They all use the same silicon, but on the lower versions (less memory, less peripherals) those parts are not tested, and might be defective.
It's just a matter of flashing it and if it works, you are good to go.
-
I've been fighting to fit all the gui. No way. The widgets system needs a total rewrite.
It's absolutely unnaceptable that the settings screen take 6.5KB RAM!
I already said it before, the way the gui was written looks more computer-oriented than for compact, low memory devices like a MCU.
-
In the board. But I wouldn't touch that. You might reduce the life of the screen.
I don't want to light the room, just to be a normal light as other OLED's. :P So which resistor would be? Taking as an example the floobydust schematic i attached.
I don't know, you must navigate in the menu and see if there's a brightness option somewehere.
No, there's no such a menu. It's a pretty spartan menu with only few options, as you know.
The board layout is absolutely important. The firmware must match all the inputs/outputs and it's connected devices.
What I meant is that the 101 can be flashed as a 103.
I thaught so... On absolutely the same board but with different processors, firmware would be the same. If even something minor is changed on board, the firmware will not fit. In my case, most probably they match.
But only testing will reveal if any of existing versions on Github will really match to this board.
-
This is the OLED schematic, might vary a little between makers, but the 30-pin OLED is the same, so you only have to follow the trace to the resistor from pin 26.
Compare the resistors, maybe they actually have different values.
My display have 820K. But according in the datasheet, the lowest recommended value is 760K (Max brightness)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1123226)
for example, this display uses 910K...
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1123242)
For more details, check the datasheet, page 26: https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf (https://cdn-shop.adafruit.com/datasheets/SSD1306.pdf)
-
Some updates about the firmware...
I read in a forum that malloc() might eat up to 40bytes for each call!
So That would explain a lot. If for every widget you sum 40 bytes... and only settings screen had 47 widgets!
Edit: Absolutely wrong. Malloc allocates multiple of 8bytes,+8bytes for itself.
Anyway, for a total of ~80 widgets, in the end it makes a difference.
So I had to change the behavior, now I declare the variable for each widget.
It's getting a bit painful to change all the program, again, a single mistake and you go back into the Hard Fault land.
But it seems the RAM is doing well! :-+
Edit: Added almost everything, fingers crossed!...
At least now I have full control of memory usage. Added around 20 widgets more and still some memory left!
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1123302)
-
for example, this display uses 910K...
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1123242)
I checked.
The brightest OLED uses 510k. Second OLED has also 510k. I switched between the OLEDs. That one board maintains the weak brightness with both displays. The FW are not exactly the same. When i switched the OLEDs, on board with F103 the whole image was moved to the left and a vertical line appeared on right of the screen.
So the firmware surely handles the brightness in different ways.
LE: maximum brightness i can get is at about 100k. Still less brighter as the old board, but acceptable.
-
Be careful if you flash that board, if the brightness is set at max by software, I don't know what could happen to the display.
A resistor almost 10 times smaller than normal ...That doesn't look right.
-
You can also order a new display on aliexpress. For like... $3 or something. To have a spare, in case you break it.
-
The board with that small OLED resistor (my friend's board) will remain as it is. It's fully functional with F103.
My board with cooked F101 has the OLED display with 510k resistor and will be reflashed as soon as i will have a proper firmware for it. Or do you think i have any chance to read the firmware from these boards?
I got the ST-link clone, installed the utility but i can't make it work or i got the wrong utility or defective St-link...
-
How are you connecting it and what's the error?
Remember that if only SWDIO and SWCLK are used, you must go into the programmer settings and change reset method from hardware reset to software reset.
-
Argg. So tired. There were a lot more bugs hidden.
But! I fitted a ton of new menus and features, and still have some memory left.
FarenWeird Farenheit users will be happy with this one!
Brief summary:
- Restored the tip storage to 10 tips.
- Fixed a trillion of newly discovered bugs. Very few bugs remaining.
- Stripped lots of unused code and functions from the uGUI libraries. Gained a few % free flash.
- Removed the weird "push and rotate" thing to change between screens, I never liked it. Now only the classic "push to do something" is used.
- Modded the widgets to accept a bmp as a button, added a settings "Gear" icon in the corner. It looks way nicer!
- To enter the debug menu: Long press anywhere in the settings screen. Long press in each Debug screen to change the screens and exit.
- Uses hardware to compute CRC32 checksum from the settings.
Options added to the menu:
- Screen: Oled Fix (to apply the oled fix on certain displays, where the image appears shifted)
- New PWM menu:
- Max Power (0-100%)
- PWM Period (1-65mS)
- Measuring delay(80-900uS)
- New DETECTION menu:
- ADC limit (0-4100) (Limit to detect no iron connected, 4100=Never detected (Max ADC=4095))
- Delay (After iron was detected again, delay before removing the 'No Iron detected' status. This is to prevent bouncing)
- New MISC menu:
- Save Delay: After last system change, minimum time to pass until the system stores to the flash
- GuiUpdate: Not related to the GUI speed, only to slow down the changes in values like temperature, voltage, to be human readable...
- Temp Unit: Changes the system temperature between Celsius and Farenheit.
- New TIP TYPE menu. Allows changing the system between JBC and T12 tips. Note that this will reset the tip and PID data!
- Serious warning displayed before allowing entering the screen. Using a JBC with T12 settings will totally destroy the tip, as the JBC TC output has much lower voltage.
The release will be soon!
-
How are you connecting it and what's the error?
Remember that if only SWDIO and SWCLK are used, you must go into the programmer settings and change reset method from hardware reset to software reset.
I tried also with Software system reset but no changes. I even updated the ST-Link to the latest firmware but that didn't helped either.
Here the pictures, i forgot to upload yesterday...
-
I had a strange problem with mine, when it used the stock FW.
There was no way to connect without manually holding the reset low. Probably debug disabled in software.
Try this take the tweezers and short the cap that goes to RST. Try to connect while shorting.
If it gives read error (read-out protected) then you must erase it.
While shorting the cap go into Option Bytes and set it to level 1, click "unselect all" in the Flash sector protection.
Remember that this will erase all the memory in the MCU.
For the RST pin, follow the stm pin 7. I think it goes to C3 but the black PCB doesn't help much...
I would start with the damaged board. Replace the roasted mcu, and try to connect.
-
If i connect the St-link together with my soldering board, the utility doesn't even see the st-link. Even the st-link blue LED stops. I think it's because of the cooked STM.
First print without soldering board connected.
Second print with the board connected.
Should i try to read the healthy board with F103? Is there any risk to erase the firmware when i read?
-
You didn't replace the bad stm yet?
There's no danger in reading. But it's very unlikely you can read it.
-
Actually wait! Don't write just yet. Because I forgot... there might be something useful to try.
You see the copy protection mechanism in STM32 products is what prevents you from reading the data. However the copy protection schemes only became "good enough" to hide "about 9%" of the data with these F103 series parts.
It might be possible then, if your F101 part is an older design. To in fact bypass the copy protection mechanism. However I just forgot and never bothered to look into that myself. Since I had F103 part.
Go check, do the research. And we might see if it's possible. What was the part number again, for the F101 version?
-
Hey, fun times....
It turned out that i was originally confusing your F101x with the earlier F0 series. For which there was previously a way to completely bypass the copy protection.
So that would have been something that would have worked on DavidAlpha's STM32F072 part. But not on your F101....
However in attempting to check up on this today, I have since discovered a recent new research paper. That seems to improve upon the existing method, for the F103 series.
If you start at this page:
https://blog.zapb.de/one-exploit-to-rule-them-all/
And then read carefully at the bottom, where it says:
11 August 2020
There has been new links added. To the most recent paper, and if you read that PDF file. It seems to be talking about new related vulnerabilities found. In order to get at the remaining coverage 1/9th. Which previously was not readable.
Sorry this is something that did not previously exist, at the time when I was trying to read these firmwares, earlier this year. But perhaps it's possible! now?
I am not sure how difficult this would be to do. With the new techniques. So YMMV.
:-+
-
Also: Those same guys also uploaded here for die image shots, to compare the "genuine" ST silicon, to the Chinese clones GD, CK etc.
https://github.com/JohannesObermaier/f103-analysis/tree/master/chip-images
Hehe :-DD
-
Very interesting, I'll have a look!
Being honest, I don't give a f...fudge for the original firmware. At least for what I got.
It's much better now, erased forever. That crap was worse than eating a bowl of Covid!
This was the original junk:
https://www.youtube.com/watch?v=uGYo4er5kts (https://www.youtube.com/watch?v=uGYo4er5kts)
Now have a look at the latest updates:
https://www.youtube.com/watch?v=XhJvmsmOdC0 (https://www.youtube.com/watch?v=XhJvmsmOdC0)
-
Being honest, I don't give a f...fudge for the original firmware.
I know. But the capability to go back / restore firmware helps others to try the open firmware. With fewer concerns. Which is a good thing generally for this project, to encourage others to switch.
Also it is useful to have the possibility to go back to check / compare. For example the performance. Or bugs. To check up such things, if ever needed.
There is also the possibility (in future) for other newer and higher quality commercial hardware. Which is also based on similar STM32 design. For example the newer WOKA stations. Are supposed to be pretty decent. So then it's more important to backup. Since with those version, the hardware design probably also changed a bit more.
Not that I really think I shall ever get a WOKA station now. But others might.
-
You didn't replace the bad stm yet?
There's no danger in reading. But it's very unlikely you can read it.
No, haven't replaced yet.
Surprise! The healthy board i could connect in a second! So that cooked STM will never be read.
And ofcourse, even on good STM, the firmware is not accesible. ;D
This was the original junk:
https://www.youtube.com/watch?v=uGYo4er5kts (https://www.youtube.com/watch?v=uGYo4er5kts)
So actually you didn't have the KSGER menu. Yours was a real junk.
This is the KSGER menu:
https://www.youtube.com/watch?v=y7FKnoNQeFo (https://www.youtube.com/watch?v=y7FKnoNQeFo)
PS: most of all i appreciate your brightness setting menu.
-
Agree. The menu on KSGER does look much better than on Quick.
Oh and btw today I have saw the review/pictures of the cheap stm32 soldering iron. It looks like it is stm32 board for real and not sct.
https://www.aliexpress.com/item/4000183089084.html (https://www.aliexpress.com/item/4000183089084.html)
-
I deciced to take a slightly different route for the screens.
Given that each screen can have its own draw function, I decided to use that.
I deleted all the static widget labels, now the labels are drawn in the screen draw function using PutString, after that the rest of the screen is drawed on top.
This saved a huge amount of ram, around 3KB. And adds the benefit that labels no longer use ram, we can add all we want.
I'n not happy yet. There's a need to differentiate static from dynamic widgets, and treat the first as constant (no ram usage.)
And I thing its a good moment for the community to start giving some ideas!
Yep the Ksger looks way nicer. But the Quicko has much better hardware! So what does that give us?
The stock uGUI fonts are rather boring, I'm looking to change them usign this:
https://github.com/AriZuu/ttf2ugui
-
I am not sure if it's easy to implement in the firmware, however I was hoping there is some way to sense automatically between T245 and T12.
This could be to prevent the need for the burn warning, at startup. And maybe also a way to modify the wiring to the handle, and have 2 connector jacks.
So that you can just plug in either handle, depending on the immediate task. Without needing to worry about keeps changing the setting. To avoid the danger.
However I didn't bring this up, because it seems more difficult problem. And maybe it's not so simple!
Also FYI the thermocouple resistance is also different between the C245 and the C210, enough to matter there too.
But there was another stupid feature, that you will also laugh at:
I wanted to know if we can use one of the spare GPIO pins (not used). To wire a 2nd button, or 3rd button. To make the menu navigation a bit faster / easier.
In simplest form, it's just the same button as on the rotary encoder. Because to push in the button of the rotary encoder, it's more difficult. It requires more pushing, and there is a hesitation for fear of turning the dial at the last moment.
But in addition. Having 2+ button then also enables the possibility to configure it as a dedicated "back" or "cancel" button. So that button 1 = "enter" or "ok" only. This also can make the menus faster / easier.
But we also have lots of other stuff that we want to do. Maybe those things are not matter so much. That's cool. Really I'm just happy we finally have a good open firmware! Really appreciate it!
-
Thank you DavidAlfa you are doing a great job.
As suggestions to the project, it would be interesting to support c210 tips from JBC, Another suggestion is to create a fork for people who have i2c oled screen.
Sorry my bad english.
-
The intention is to implement all hardware in the same base.
I already implemented hardware i2c in a test fork, when this fw is ready for release I only have to add that part.
Adding more buttons is the easiest part, but we must think how to do that.
I doubt most people will start soldering wires to the small TQFP package. It will be a minority.
Most will use the station as-is. So the addons should be implemented to be disabled by default.
Sensing the TC type by software? That's basically impossible without modifying the hardware.
You can't sense it by any means. And the voltage is neither a reliable way, as when cold they will measure similar.
Also you can't magically switch the circuitry. In any case, you can't swap T12 and JBC tips on the fly as the wiring is different.
So the menu is there, but only to be done once. You wire the station, select the Tip Type you are using, and that's all.
It can be done either switched manually in the software, or setting a jumper in hardware (useless, same thing as software)
An ok-ish way would be to use a different connector with more pins and use a dedicated pin to set the ID.
For example, assign a known resistor value for each handle type and sense the voltage with the adc.
But again that needs hardware modding. And for that we already nice hardware like the unisolder:
http://dangerousprototypes.com/forum/index.php?topic=7218.0 (http://dangerousprototypes.com/forum/index.php?topic=7218.0)
There's no sense on overcomplicating it. Same for the buttons.
What will be the 99.9% of user interactions? Click on the setpoint and adjust the temperature.
Nothing else! Does it worth it adding fancy buttons and so? The encoder works pretty nice, it almost never fails detection.
Keeping in mind that my encoder is defective, sometimes it stucks between two positions.
In that condition the firmware knows it's in the middle of a movement, so the encoder button won't work until the movement is finished.
There's nothing wrong with that, it should be like that. Encoders rotate either a step to the left or to the right, but not half-steps!
How do it the Ksgers? I know some have the ability to use the JBC tips. Appart of cutting the TC trace or removing the resistor?
They should have an option in the firmware. And the same problem will happen if you use JBC with T12 settings.
The real JBC stations have current sensing, so they know when the tip is not the correct one.
I received the C245 handle, not awful but not great. The tip wouldn't get in at first, it was hitting the second contact and damaging the isolating plastic.
The contacts were too closed, also the plastic support had a pronunciated step that caused again the tip to not enter nicely.
After smoothing the plastic and slightly opening the contacts, now it seems to be doing well.
The tips look utterly crap. They're badly pressed and there' plenty of space betwen the tip and the heater in some areas.
Not tried yet, we'll see how it performs.
The thin tip, is definitely useless as it is, too sharp. I'll make the tip rounder.
-
Well, I left you guys with a job. To propose nice fonts for the gui.
I already compiled and tried that program and it's very easy to implement new fonts!
-
An ok-ish way would be to use a different connector with more pins and use a dedicated pin to set the ID.
For example, assign a known resistor value for each handle type and sense the voltage with the adc.
But again that needs hardware modding.
I think this is my point:
We want to choose the most sensible hardware mod. From a variety of options. And then implement the software support for that decision, in a unified firmware.
Because if we don't come together and agree the best hardware choice. Then different guys will each solve the problems in different ways. And there is no standard, the firmware is modded many ways for each. And it's then really confusing for others who want to come and find out.
We also want to devlop our own board, incorporating 'levels of' advanced features. So that we can populate the same pcb design with progressively more chips, etc. to add thos features not everybody wants.
And we have the same problem ther. Lets not have multiple variants of the design that implement these same features in completely different ways...
So for this we need a good open discussions for the pro's and cons of each choice. For example one way might technically be better than the other way. But result in higher BOM cost, so can that be justified?
How do it the Ksgers? I know some have the ability to use the JBC tips. Appart of cutting the TC trace or removing the resistor?
Yes... that is how it is on these blue Ve2.1S r2 pcb. Like cosin and myself. These is a trace at R11 on the pcb. So if the R11 pads are bridge joined together (0 ohm) it is in T12 mode. But when you cut that trace it becomes mode for the jbc T245. This is shown on floobydust schematic.
I think I remember some guy who moved that switching off the main pcb. Into his own simple mod. Maybe with a mosfet circuit to sense, or connect them. And make the switching happen, for example when each handle was plugged in. So that he could switch between them based on that. And have a default handle when both were plugged at the same time. As a hardware mod. But it was pretty simple and basic mod.
However another good question to know is if the KSGER pcb wiring for T245 was entirely correct. Richard Sims has put some useful details about them here, both the t210 and the t245:
https://github.com/Jan--Henrik/Otter-Iron-PRO/issues/16
For example which pins to drive the heater, and sense the TC from. I forget right now. But its in the link above ^^. Also check against the T245 cross section photo:
https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/tips-and-handles/t245-c245/t245-tip-cross-section.jpg
I perhaps this means sense the TC between c+ and gnd ?
And heat only between c+ and c-, not GND.
Wheras the construction of the C210 is different, and there must me switching. This is what Richard Sims is saying.
The real JBC stations have current sensing, so they know when the tip is not the correct one.
Yes.... this is a good way to check the heater resistance. With a shunt resistor. And measure that power.
Since we know it will vary between the T12 (9 ohm) and the T245 (2.6 ohm). Then we can use that to stop burning the tip in software. But what we don't have yet is the consensus to standardize that hardware mod. So that it is the same for everybody. Then the software only needs to implement 1 version of that. To make sure for example, there is no confusion and only 1 valid shunt resistor size (as a default, at least). Then it is actually safe for everybody. And a safe product to use, not to destroy the tips.
FOR the C245 / C210 auto switching, the guy who made the C (not pid) algorithm used an H bridge. That is a more expensive part. But it then let him have all that switching happen automatically. The 6 pin din has some pin id shorted between 2 pins.
Instead of an H bridge, maybe it would be cheaper to use some conventional magnetic relays. Or to use some mosfets together as switches. IDK.
The thing is to understand the trade offs, for BOM cost. And usability, and safety. And choose the best solution. It needs more discussion to really get a design that is good for everybody. Because different people have different opinions, and wallets. So finding the best overall trade offs, to have the best unified design... is not always what individual people will recommend.
I received the C245 handle, not awful but not great. The tip wouldn't get in at first, it was hitting the second contact and damaging the isolating plastic.
The contacts were too closed, also the plastic support had a pronunciated step that caused again the tip to not enter nicely.
After smoothing the plastic and slightly opening the contacts, now it seems to be doing well.
I see now what you mean by the isolating plastic. Those black step between the pins. Mine are not uniform, not even all the way around. And also it makes a sharp ridge.
Perhaps you can measure (for js02 bent tip), the distance in mm, from the end of the tip to the round metal collar, when fully inserted? Mine seems to stop @ 41mm.
It would be nice to check with you, to be sure it's correctly engaged:
No audible click... but after a scraping, then a feeling of less resistance. Then a soft stopping in the hand. When it gets to the end. The voltlog video says it is bad to push too hard.
Checking the resistance between pins, it seems like a good electrical connection.
FWIW those lengthwise ridge crimp lines look normal, because they also exist on the official JBC tips. Out best guess is that the manufacturer should be same chinese oem /from same factory. Thinking more towards a QC issues.
-
I love modifying everything, I would fill the T12 box with more pcbs and wires and whatever haha!
But maybe I didn't explain corretcly (I' don't mean to appear rude or anything!)
The actual purpose of this project is to make a compatible firmware -with- existing soldering stations, just as they come from aliexpress, ande require the minimum modding from the user.
So anyone can buy a KSGER, or a Quicko, hook 4 wires and replace the firmware.
That doesn't mean we can fork it and unleash all the power, absolutely not!
In any case, once you make your own pcb, the costs will skyrocket, not only the pcb cost, but the components, usually you can't order just 1, but a multiple of 5, 10...
And delivery costs for each thing.
So I think we can't forget that the main target of this project are these $30 stations.
And if anyone wants to add 325 mosfets, of course we can work on it! :-DD
But I don't see merging that in the main branch. There would be a lot of important changes making it a totally different project.
The C245 slides like butter now. As I said the main problem was the second contact, the "fork" shape was too closed.
I should be like a "V" rather than "U". I don't see how you could push to hard to make a short.
The're endstops, you can't push any further. My guess is that the guy in the video bent a contact because this same reason, or who knows.
Maybe the soldered wires were not well isolated (does that seems familiar to you?)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1124972)
-
Well, I left you guys with a job. To propose nice fonts for the gui.
I already compiled and tried that program and it's very easy to implement new fonts!
Hi David, how are you connecting to the swclk pin to program the board, it doesn't seem to go anywhere on the quicko t12?
Cheers
-
Oh for sure it does!
RST not needed if set software reset method in the programmer options. If you can't connect, the debug interface might be disabled in software, then use RST.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1124980)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1124984)
-
Thanks for that, dead easy then, I'll have a go later see if I can connect to it.
-
I agree with DavidAlfa that you should keep it all as simple as possible, at least to start with. Maybe just some simple hw mod that are worth to make. JBC hardware jumper in ksger board just disconnect (if cut) + from JBC TC because in JBC T245 has it's own TC output. Anyway this jumper doesn't help in any way ksger hardware or software to detect if you are using T12 or T245 handle. It's just useful tu move this jumper to GX12 handle connector so to have it right wired based on the handle you are using.
I would find it useful to always power in the unit in sleeping mode, to avoid having it hot due to power/software failures. If it restart for any reason, it should keep cold. User just start it maybe rotating the encoder fast right (and put it in sleep or standby rotating fast left). Maybe powering on in sleeping mode make it possible detecting which handle or no handke at all is connected reading TC adc input? I don't know if some differences could be detected between T12 and T245 handles (leave T210 apart for now). Maybe SW could try to detect it and ask for confirmation for right detection at power on? Then the user can simply not confirm and select T12 option. Anyway it would be good to keep different T12 and T245 TIPS to fast select from T12 and T245 handles. I know that this is simple to say but hard work to do... Thank you DavidAlfa for the good work you have already done and what you are still doing. I still have not received GX12 connectors to try my T245 on my ksger unit (that has some JBC tips in its menu). As far as the JBC jumper way for ksger unit to use T245 handles, we have to live with the fact that common pole (for TC and HEATER) in theese units is GND (connected to the TIP). So, as long as it works (I'll try it ASAP), it would be no problem heating JBC TIP through the TC.
-
Well what about the NTC thermistor inside the T12 handle? Which is between pins 2 and 4 on the 5 pin aviation connector.
It's reading several kilo ohm, at room temperature. Between 8.5k and 9.5k. If we wire the T245 handle so that it is either an open or a short between those pins. To give a reading that is otherwise impossible.
Am I right to think there is no such NTC resistor inside the T245 handle? According to these information gathered:
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tips-and-handles/t245-c245 (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tips-and-handles/t245-c245)
Then If we can figure out these wiring scheme:
https://user-images.githubusercontent.com/749470/99142834-a33c4b00-260d-11eb-9dc2-b2753d5301a6.jpg (https://user-images.githubusercontent.com/749470/99142834-a33c4b00-260d-11eb-9dc2-b2753d5301a6.jpg)
Such that it does not conflict, to prevent detection (later on) of T210. Since they do a different type of short, between different pair of pins on the JBC HiRose connector. To maintain future compatibility.
So where does the NTC thermistor goes into the Micro? This is shown in floobydust schematic, as PA7 / Pin17, marked "NTC"
https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/msg2463234/#msg2463234 (https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/msg2463234/#msg2463234)
So that's an ADC input, which seems balanced (the 9k) with 2x 4k7 resistors. And then the NTC is like a bias? The NTC seems "NTC B=3950 10K@25 degrees Celsius".
Anyhow I am not sure the swing of "possible" adc values, given the bias. For when the NTC is working. Because it's resistance can vary a lot. However maybe if we were to short across the NTC, or have an open circuit. Or a closed circuit. It would seem possible to measure that as an invalid value in the code.
Unfortunately I am not 100% clear on the wiring, of the ground etc. Because these different diagrams are giving a conflicting information. Really annoying. Sorry. But pin 2 of the aviation connector seems to be going to the NTC, looking at my blue PCB here.
Heck if we just didn't connect it to anything at all, that could select T245. If only shorting it could then also detect T210. At the other end of the scale... however the way JBC wire it, they bridge a pin of the C210 only to the heater negative -, rather than to GND case. Which is a bit frustrating.
Also it is desirable to have a safe failure mode, of the T12 NTC (pin 2), in case the wire breaks inside the handle. This would then mean put the T245 as short, instead of open circuit. Because it would not be possible to distinguish between open circuit and a broken T12 handle wiring.
:-//
-
The main problem is... if a short to ground could instead also happen on a faulty handle. For the pin 2 NTC. If both short or open circuit can happen by such accident inside these chinese poor quality handles.
|O
-
Hmm, well it seems possible to detect both open and closed circuit on the NTC. Because I have just tested here on the original FW, and either way, the invalid ADC input value is noticed as out of range, and the "room temp" on the main screen then prints as text: "! 14°C"
Perhaps a sensible compromise would be to think in an extendable fashion. ATM we have 2 settings for the tip choice:
* T12
* T245
However there is no NTC present with T245 handle. So you don't need to display warning message at boot time. Unless you also detect the invalid NTC value too during boot time. Which would then suggest *maybe* the JBC tip. Or *maybe* bad wiring of the T12 handle. Then ask the user to positively manually select between T245 and JBC. So then display the warning message.
Otherwise it should be safe assume (most cases), if you get a valid NTC data it must be because a T12 handle is already connected to the station. Before the user powered on.
But in future, the planning of 1 additional option, is also possible. So then a 3rd option can later appears:
* T12
* T245
* JBC Auto
With "JBC Auto" being the auto sensing option. In this case, the user must manually choose to enable this option, by going into the menu settings after boot. However if somebody chooses this 3rd option, then they are no longer protected from faulty T12 handle wiring, giving a faulty NTC reading. This is then a good idea to display a 2nd warning screen, after the user selects "JBC Auto". To warn them of that.
An open circuit on NTC (--> 3v3 NTC adc max) should set station to --> T245 handle. However in 3rd planning stages. An additional mod board, hardware mod is installed. Which is to say for future expansion. Then a closed circuit on NTC (--> 0v NTC adc min). Would set the station to be T210.
I think that is the best way to map future expansion, to select multiple tips. Simply by physically plugging them in. The auto detect feature is useful when you frequently want to change handles.
For example, if you have cheap T12 tips for some shapes. Then more expensive JBC tips for other shape. Also the T245 has larger size, for large work. And T210 is smaller, better for fine micro soldering.
I think that is really the only way I can see ATM. To keep firmware compatibility, and make an extensible system. For both modding, and not modding, and new hardware.
Otherwise if you don't use the NTC value alone. Then it can be supplemented with additional extra GPIO digital IO pins. But that as you say original boards, which don't break out the pads for not-used pins. So then they are left to micro soldering some tiny fly wire (mod wire) and glueing it down with epoxy. Onto the legs of the MCU. Which is not always so easy, for the initial capabilities of beginner / novice user.
But anyhow, it's just something you can start doing right now! Check NTC value is valid at boot time. If it's valid it cannot be any JBC tips. ---> must be T12. --> No need to display the warning screen at boot up.
Similarly, after boot time: If T12 handle is the selected option. Then constantly be checking that the NTC is a valid value (not ADC max, or ADC min). If that ever happens, then stop all power to the heater. And display an error message.
-
I was planning to add a NTC in my T245 GX12 connector to use it as a cold point just as in T12 :) But I can do without it for the sake of autodetection :)
In ksger unit I can select in the menu what is the cold point I want to use, NTC (in T12 handle) or CPU (mandatory for JBC I think, maybe automatically selected for T245).
-
The NTC is for cold-junction compensation, but there are so many junctions - the socket, cable, GX connectors, PCB.
I wonder if it really helps with total accuracy. There is a temp sensor in the MCU, some boards have the NTC on the PCB, almost all (KSGER) builds are in the handle. The menus have an ability to dial in a temp and use that instead. I would limit CJC in firmware, your handle should not be beyond +50C or -30C. If outside that window just use 25C as a default. I don't know where JBC is doing CJC :-//
Could auto detect perhaps looking at the thermocouple A/D value when the heater is on? Because the JBC TC is separate it should not peg like a T12. But you'd likely end up looking at the cable resistance due to the high heater on currents. Hmm.
-
And add that lots of T12 handles don't have the NTC installed. Like mine...
We can't rely on that. A cut or short wire can have nasty consequences.
I agree with DavidAlfa that you should keep it all as simple as possible, at least to start with. Maybe just some simple hw mod that are worth to make. JBC hardware jumper in ksger board just disconnect (if cut) + from JBC TC because in JBC T245 has it's own TC output. Anyway this jumper doesn't help in any way ksger hardware or software to detect if you are using T12 or T245 handle. It's just useful tu move this jumper to GX12 handle connector so to have it right wired based on the handle you are using.
I would find it useful to always power in the unit in sleeping mode, to avoid having it hot due to power/software failures. If it restart for any reason, it should keep cold. User just start it maybe rotating the encoder fast right (and put it in sleep or standby rotating fast left). Maybe powering on in sleeping mode make it possible detecting which handle or no handke at all is connected reading TC adc input? I don't know if some differences could be detected between T12 and T245 handles (leave T210 apart for now). Maybe SW could try to detect it and ask for confirmation for right detection at power on? Then the user can simply not confirm and select T12 option. Anyway it would be good to keep different T12 and T245 TIPS to fast select from T12 and T245 handles. I know that this is simple to say but hard work to do... Thank you DavidAlfa for the good work you have already done and what you are still doing. I still have not received GX12 connectors to try my T245 on my ksger unit (that has some JBC tips in its menu). As far as the JBC jumper way for ksger unit to use T245 handles, we have to live with the fact that common pole (for TC and HEATER) in theese units is GND (connected to the TIP). So, as long as it works (I'll try it ASAP), it would be no problem heating JBC TIP through the TC.
Sure, that was in my mind, also disabling the buzzer (In fact, I removed it on mine the first day I got it. What an annoying thing :-DD)
Do people really switch between JBC and T12? Seems a bit strange to me. After using JBC tips..nothing beats it, at least not T12 tips.
I would understand the different JBC sizes, as you migh use a T210 for micro soldering, and the T245 for regular stuff.
-
I think i'm going crazy! :rant:
Replaced the STM32F101 with new one and still can't access or program. I get the same error.
The F103 i can access instantly.
-
Check the voltages in the Vcc pins, also in the reset pin!
-
Connected to St-link:
Vcc pins all equal ~ 3,31v.
RST pin ~ 3,29v.
Connected to 24v power supply:
Vcc pins all equal ~ 3,26v.
RST pin ~ 3,25v.
Same on functional board.
-
Could auto detect perhaps looking at the thermocouple A/D value when the heater is on? Because the JBC TC is separate it should not peg like a T12. But you'd likely end up looking at the cable resistance due to the high heater on currents. Hmm.
Hey! That is... a pretty good idea floobydust. Perhaps we could probe this with a 1% PWM on. For a very brief period? And then compare the averaged thermocouple adc value, over a brief time window. On, off.
TO see how much it jumps.
-
The latest JBC invention! Detachable tips!
The thin one works nice...
So the danger is not with C245 tips, but with 210s...
TC coefficient:
C245 ~40uV / °C
T12 ~21uV / °C
T210 ~10uV / °C
That explains why I had to set It crazy high to start melting the solder.
So we have a trouble here.
No T12 station will work correctly with the C245.
Op-amp gain is ~250.
Max ADC vin 3300mV.
3300/250=13.2mV Max amp input
13200/40=330°C Max temperature.
Can be fixed easily though.
-
The T12-clone controller boards are having many issues with the thermocouple amplifier. Mainly due to using too cheap op-amp, and the 3.3V buck-converter makes too much noise to expect a gain of 250 to be clean.
It's like they're shooting themselves in the foot by using the smallest capacitors, cheapest op-amp, no H/W filtering- yet expecting accuracy to a few degrees.
I saw recent T12 V4.4 controller boards are using a 24-8V buck, then a 3.3V LDO to power things. I'll have to check if the TC amp runs off 8V then you can accomodate the JBC TC and just need a second A/D channel with reduced scale.
-
Check the voltages in the Vcc pins, also in the reset pin!
Works on WinXP. But nothing happens when i open one of the .hex files available for these boards...
Am i missing something?
-
My idea was pretty simple. As the input has a 4k7 resistor, we could connect another resistor after it and switch to ground by software when c245 is selected.
No amp problems on mine, not perfect but the noise is totally acceptable (2-3 bits of noise)
Works on WinXP. But nothing happens when i open one of the .hex files available for these boards...
Am i missing something?
After opening the file you should see it in the Binary File tab.
-
After opening the file you should see it in the Binary File tab.
-
Solved it. The HEX file must be renamed. Long name file is not loaded.
Now i will see how it fits to my board...
-
I'll try to port the fw for your board soon...
There's something werid going on.
The measurement is very stable so I don't think it's wrongly wired. I re-checked it yesterday and it was fine.
The adc doesn' match any tip TC. The T12 was spot-on with 21uV/ºC.
My soldering alloy is Sn97Cu3, melts at 220-230ºC. The C245 starts slightly melting the solder at 1250 ADC.
That gives aprox 4.3mV at the amp input. So 4300uV/230= 18uV/ºC? Almost the half?
This was my approach to connect the c245. As the GX12 connector is soldered with the front fascia in between, I can't access the back of the board without removing it.
I wanted to avoid removing it, the board gets damaged easily.
This was the simplest approach
- Cut the heater to amp trace
- Connect the handle TC wire to the handle NTC pin
- Remove active components that belong to handle NTC circuit (fet and amp)
- Run a wire between the handle NTC input and the TC amp input
The only additional connected components are a 100K resistor and a 100nF cap, that should't make any difference.
(D1 acts like a 0.6V zener, it's reversed in the schematic)
Original
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1125598)
C245 mod (Heater input trace cutted)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1125602)
-
I'll try to port the fw for your board soon...
Great!!! 8)
Friend floobydust and i finished the schematic of my board, we will post it on Github or here.
-
That's something important to make the fw work... Post it when you can!
-
One problem solved.
Tested all fw available from russians and one perfectly matches my board (T12_HW20_Encryption_OLED13) and is very bright with unmodified display. Just needed to generate the RG1/RG2 keys and that's it.
But... now other problem apeared.
When i tested all those firmwares, i came across a version (T12_HW20S_Encryption-SSD1306) where the display was less bright.
Then came the idea: what would be if i rewrite the board with F103 with same fw that matches the first board? Just to have the screen more bright.
So... i put back the 510k Iref resistor and flashed the F103. Surprise: dead! And no other available fw matches this MCU.
I am thinking to replace the F103 with F101 and flash it with the working fw.
Sounds crazy?
Anyway, i will be more than happy to use your fw David, if you will port for this board.
PS: this fw works for black board with 101 MCU (but NOT with F103)
-
Intersting cosmin. But did you also take partial dumps and compare before flashing? I had put up some script for helping that on github.
If not, no worries. Just would be nice to see / compare the partial dumps. If you had taken them.
-
Sorry, i didn't... I had no idea it can be done. :(
But i couldn't read the old fw. It was protected.
So what do you advise me? Should i replace the MCU with F101 and will work exactly as the other one?
Does anyone have that 3.1s fw from this forum? It's no longer available, i want to test it on this MCU. https://www.radiokot.ru/forum/viewtopic.php?uid=124906&f=2&t=169984&start=0 (https://www.radiokot.ru/forum/viewtopic.php?uid=124906&f=2&t=169984&start=0)
Or if you have any fw to test, i would be happy to do it.
These from here are not working for this board: https://drive.google.com/drive/folders/1O8wgvWNmMEFCBCkaGRfy-erHNlp1qiX6 (https://drive.google.com/drive/folders/1O8wgvWNmMEFCBCkaGRfy-erHNlp1qiX6)
-
no problem, is ok :-+
-
Flash it right away with the 101 fw. It will probably work!
Definitely my C245s are weird.
They have the same output as a T12!
The solder melts exactly at 220°C.
The temp sensor didn't arrive yet.
Definitely the tips are total garage.
-
Flash it right away with the 101 fw. It will probably work!
No, it does not work. That was the first move.
Only a short quirtz from buzzer.
LE: Meanwhile i'm sort of beta tester for the v3.1S firmware and the board is alive again. ;D
Pretty nice menu, except the image is a few pixels right shifted.
I suppose we can't do anything about it, if we don't have the source code... or?
-
LE: Meanwhile i'm sort of beta tester for the v3.1S firmware and the board is alive again. ;D
Pretty nice menu, except the image is a few pixels right shifted.
I suppose we can't do anything about it, if we don't have the source code... or?
Is that firmware you are using this one?
One problem solved.
Tested all fw available from russians and one perfectly matches my board (T12_HW20_Encryption_OLED13) and is very bright with unmodified display. Just needed to generate the RG1/RG2 keys and that's it.
As I already know the cause of that screen issue (The PTDreamer firmware already had a patch for it) I disassembled the firmware you uploaded and quickly found the Oled initialization routines:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1126492)
Now, I'll try to find the Row addressing routine and patch it. I don't know if the firmware has a checksum or not, but we'll try anyway!
-
The v3.1S firmware matches to the black board v3.0 with F103 MCU. Pictures above are from this 3.1S fw. This one is shifted.
The firmware 2.0 attached above matches to the black board with F101MCU and is ok, no need to shift.
I found out what is with the shifted image. Firmware is made for SH1106 display driver (132x64 pixels) and the board uses a SSD1306 based display. So replacing the SSD1306 based display with a SH1106 based display will solve the issue.
This type of problem appears only on boards with different display, as the most of them uses the SH1106 driver.
If you can patch the fw i attached, i will change the displays between boards and i solved the problem.
David, you have a PM, maybe you could help me out with other issue.
-
The difference with the two is just a little offset, what you see in the display. Nothing less.
Try the attached BIN! I replaced the instruction that added +2 to the offset with a nop.
My Black pill just arrived. It looks great, matte black mask, and ENIG(Golf) finish.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1126600;image)
-
A bit off-topic, but how bad is an STC processor compared to an STM32? Looks like Aliexpress has a ready-made controller board that is 3-way compatible with T12, JBC245 and JBC210 handles, but it's STC based:
https://www.aliexpress.com/item/1005001694683205.html?spm=a2g0s.8937460.0.0.23292e0eGiFmm6 (https://www.aliexpress.com/item/1005001694683205.html?spm=a2g0s.8937460.0.0.23292e0eGiFmm6)
(I can't read Chinese, so most of the information in the photos on the page is unreadable to me.)
I also saw one that is similar to the KSGER T-12 units, but is built for use around a JBC245 handle and also uses the STC processor (though they do not have photos of the interior to see if they use the same controller as linked above).
https://www.aliexpress.com/item/1005001633176163.html?spm=a2g0s.8937460.0.0.56c72e0exOf1vr (https://www.aliexpress.com/item/1005001633176163.html?spm=a2g0s.8937460.0.0.56c72e0exOf1vr)
Compared to the Jabe's, the BEST's, the Toor's, etc. this appears to be the cheapest JBC245 compatible soldering station (I won't say "copy" since the Jabe and BEST units are copies with some slight changes).
-
A mcu itself is not "bad".
What makes them bad is the crappy firmware they have.
The stc might be actually better, who knows.
Other thing is the availability of documentation and development tools. I think there was an alternative firmware for these...but don't expect much interest from anyone.
-
Try the attached BIN! I replaced the instruction that added +2 to the offset with a nop.
Not working at all.
What could be causing this behavior? Opamp? It does like that with any firmware.
https://www.youtube.com/watch?v=o7OPp_O_DOY (https://www.youtube.com/watch?v=o7OPp_O_DOY)
https://www.youtube.com/watch?v=M1cnVedI0ac (https://www.youtube.com/watch?v=M1cnVedI0ac)
-
What does the patched fw do? nothing? Dead?
That behaviour is normal because you have nothing connected. The program is badly done and shopuld have a small delay to avoid that bouncing.
-
What does the patched fw do? nothing? Dead?
Absolutely nothing. Not even a buzzer chirp.
About the behavior... same fw on other board shows only ERROR message if no tip is connected. Just this board have this issue. Anyway, it's not very important. I'm happy it works.
-
It's just the thermocouple op-amp input floating and picking up hum and noise. There should be a 1MEG pullup to prevent this.
-
Finally got a repurposed blue pill to connect to the quicko t12, and flashed your firmware davidalfa, after spending hours and hours with a cheap chinese st-link/v2.
Real nice job you have done, so much smoother and easier to navigate than the ofw.
Does have a slight issue tho, not sure what is going on here?!
https://www.youtube.com/watch?v=51iwkKbZFA4 (https://www.youtube.com/watch?v=51iwkKbZFA4)
-
It's just the thermocouple op-amp input floating and picking up hum and noise. There should be a 1MEG pullup to prevent this.
Solved!
1Mohm resistor from op-amp pin3 to +3V and all ok.
-
Finally got a repurposed blue pill to connect to the quicko t12, and flashed your firmware davidalfa, after spending hours and hours with a cheap chinese st-link/v2.
Real nice job you have done, so much smoother and easier to navigate than the ofw.
Does have a slight issue tho, not sure what is going on here?!
Do you mean the oscillation? This is still very beta! Lots of adjustments still needed to be released. But that's exactly what we need, people trying and reporting.
Edit: I didn't saw that it almost went to zero. Start with the ADC delay, that it's no PID issue.
But the fact that it goes over 300ºC and still applies power, yes, it's the PID. It should stop more closely to the setpoint.
Try few things:
1:
Go into PWM menu and increase the ADC delay. It's set to 100uS by default, but I've found that it's not enough.
Last time I tested I got nice results at ~300uS. Set it to max (900uS). And if it stops doing that, try lower settings, 100uS at a time.
This is because the tips might cause some inductive spikes when switched off, and it will vary between tips.
If the ADC reads too soon, it will catch the spike and think the temp is either too high or too low.
See these wafeforms:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1128016)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1128020)
(Taken from https://github.com/wagiminator/ATmega-Soldering-Station (https://github.com/wagiminator/ATmega-Soldering-Station))
2:
Open /core/Inc/setup.h and edit the FILTER_N value.
Higher than 4 will cause a high of undershoot in the filter output, so when the filter output reaches the setpoint temp, the real temp already went way higher.
I have set it to 3, it's a nice balance betwen filtering and delay.
You can set it to 2 or 1, it will have less filtering, but smaller delay.
Or you can totally disable the filtering and use only the average of the last reading by commenting USE_FILTER.
If it still oscillates then it's a tip or PID problem.
3:
It still has PID values from the PTDdreamer fw. Try the different tips included.
Or try this:
PID menu:
Kp : 40
Ki : 1
Kd: 6
Might someone help with the PID tuning?
I usually set all to 0, rise the Kp until the temp is close, put 1-3 in Ki, and increase Kd until it stops oscillating. But it's totally empiric.
4:
Might be a bad thermal conductivity, so when the heater is stopped, there's already plenty of heat traveling till the tip sensor.
Try differents tips. From 6,I had 2 with issues.
Else they didnd't reach the temperature, or went crazy up and down like there was no tomorrow.
You'll have to play a lot with these options!
Post here your findings and I'll add the cal values to the fw. I no longer have T12 tips!
And, stay tuned, I have to push some important changes, as I had some lock outs and I hadn't planned any actions for them.
In my case I didn't had any problem, but in the worst case it might freeze with a high PWM setting and burn the tip.
So I've added the PWM emergency shutdown I already had in case of Hard Fault, on that part. Also added on-screen debugging showing the file and line where the problem came from.
(You must build in debug mode to show this information)
But it didn't fail again so I don't know yet what is it.
-
Yeah it doesn't seem like a pid tuning issue, the temperature seems to randomly jump +25°c and the output shuts off 0% and stays 0% until way under the setpoint, then the temperature jumps to 45°c briefly and it springs back to life.
Didn't get much of a chance to play with the settings last night, but I will have another go with it tonight and report back.
-
Last safety actions done, I hope you don't burn your tips!
Build bin added to the repo. Somehow I had added it to the ignored files.
Sorry for that!
What do you think of the font? I tried lots of them, it's hard to find one that reads nicely in a such low res display...
Edit: Yep, it was better before. Reverted the font.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1128094)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1128090)
-
I'll give the update a go later, tbh I quite liked the font as it was in my video, but anything is better than that horrible font the chinese seem to use for everything ;)
-
It's just the thermocouple op-amp input floating and picking up hum and noise. There should be a 1MEG pullup to prevent this.
Solved!
1Mohm resistor from op-amp pin3 to +3V and all ok.
It was not a good idea. I connected the tip and now have the following problems:
- tip is heating but temperature is not shown.
- at first time the ERROR message keept appearing on display even with tip connected. After few seconds, INVERT message appear and 3 beeps.
- LED from the back of the board not working
- now i see the tip is almost glowing, working continuosly.
Op-amp dead? :(
-
Hello dreamcat4, I've been trying to view this repository, https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled
but it seems corrupt. I can't see the diagrams. Please can you fix it, it's very helpful.
Thank you.
-
My friend, unfortunately after uploading many files, github (well, microsoft), decided that i had very quickly exceeded the highly insufficient git lfs bandwidth quota, on my free account.
It was not know that there was such restriction at the time of uploading the data. But it seems more people keeps coming to view it.
What you can do instead is simply download the whole repository. Then open the files locally on your computer. And that should work instead.
Ideally I would like to fix this problem, however the alternate service fast.io which was planning to move to... it's also taken itself private recently. And in a similar fashion. They change the terms.
Sorry for the inconvenience!
-
What you can do instead is simply download the whole repository. Then open the files locally on your computer. And that should work instead.
It does not work, I did it but "research" folder is only 8kb and pictures are a few bytes corrupted.
-
$ git clone https://github.com/dreamcat4/t12-t245-controllers-docs.git
Cloning into 't12-t245-controllers-docs'...
remote: Enumerating objects: 403, done.
remote: Counting objects: 100% (403/403), done.
remote: Compressing objects: 100% (297/297), done.
remote: Total 403 (delta 140), reused 337 (delta 77), pack-reused 0
Receiving objects: 100% (403/403), 6.72 MiB | 5.32 MiB/s, done.
Resolving deltas: 100% (140/140), done.
Downloading controllers/stm32-t12-oled/combo/Combo_HW101_ENC.hex.jpg (131 KB)
Error downloading object: controllers/stm32-t12-oled/combo/Combo_HW101_ENC.hex.jpg (1669d3b): Smudge error: Error downloading controllers/stm32-t12-oled/combo/Combo_HW101_ENC.hex.jpg (1669d3b3e05613720eef3388bd746ef9f82c98592306c7e624c5d14721d87739): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
Errors logged to /home/id/t12-t245-controllers-docs/.git/lfs/logs/20201210T223806.946697699.log
Use `git lfs logs last` to view the log.
error: external filter 'git-lfs filter-process' failed
fatal: controllers/stm32-t12-oled/combo/Combo_HW101_ENC.hex.jpg: smudge filter lfs failed
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
ok... this means that i shall need to disable / remove all of the references to git lfs in the repo. Then re-upload it.
The operation is too complicated to do tonight, it will have to wait until tomorrow. I'll let you know when it"s done. Or you can press the button to watch the repository to get an email alert.
-
It's just the thermocouple op-amp input floating and picking up hum and noise. There should be a 1MEG pullup to prevent this.
Solved!
1Mohm resistor from op-amp pin3 to +3V and all ok.
It was not a good idea. I connected the tip and now have the following problems:
- tip is heating but temperature is not shown.
- at first time the ERROR message keept appearing on display even with tip connected. After few seconds, INVERT message appear and 3 beeps.
- LED from the back of the board not working
- now i see the tip is almost glowing, working continuosly.
Op-amp dead? :(
If the LED does not come on, then the LED or op-amp input is shorted, or there is an open-circuit.
Check your soldering of the resistor - 1MEG cannot damage anything here. The LED must come on when the heater mosfet is on. If you ever short the heater to GND the mosfet can get damaged and short. More in this thread on a failed mosfet or op-amp (https://www.eevblog.com/forum/repair/brand-new-ksger-t12/) pg.2, some of the op-amps are low quality.
The thermocouple op-amp and mosfet are not protected against -ve voltage spikes in the KSGER designs. If you hot-swap handles or tips or hit it with ESD, or soldering to that pin ungrounded, it can damage the op-amp or mosfet. I add a fast-recovery diode across the heater (GX12 pin 5 to GND) to cover that.
I think the firmware should never put full heat on for over a minute say as that is an obvious fault condition.
-
Just to add... it help to power your controller (+24v rail) from a current limited bench psu. It is another helpful way to avoid fire
https://i.imgur.com/BKk93pH.jpg
:palm:
here also you can see in the picture how to implement floobydust diode mod for -Ve spike / esd protection. For the mosfet at least. Not sure what it should looks like for op amp.
https://i.imgur.com/RSIQcRB.jpg
-
A clamp diode across the heater protects the mosfet and TC op-amp from -ve voltage spikes. A 30V mosfet running off 25V... doesn't take much -ve to blow it.
But that extra diode doesn't give protection with JBC tips though, they have that separate TC input. So another diode is required unless the op-amp happens to have them built-in. No mention of that on the SGM8551 (http://cn.sg-micro.com/uploads/soft/20191011/1570775498.pdf) datasheet.
Can you explain your "r2" "r3" on the controller boards in your repo.
I did schematics for OLED-3.0 and OLED-3.1 to post in a new thread but you are calling one "2.1S r3" which seems confusing. I know there are many variants of these boards, a few different clones out there.
-
If the LED does not come on, then the LED or op-amp input is shorted, or there is an open-circuit.
Check your soldering of the resistor - 1MEG cannot damage anything here. The LED must come on when the heater mosfet is on. If you ever short the heater to GND the mosfet can get damaged and short.
Solved this time too. Chinese quality resistors...
When soldered the 1Meg resistor to R8, the R8 terminal peeled off. I only saw it only under microscope.
Replaced the R8, soldered a 10Meg pullup resistor and now everything's fine.
Be careful with these boards, if you need to resolder the resistors... they have very very thin terminals and they peel off immediately.
In the end i replaced several resistors because of their poor quality.
-
ok... this means that i shall need to disable / remove all of the references to git lfs in the repo. Then re-upload it.
The operation is too complicated to do tonight, it will have to wait until tomorrow. I'll let you know when it"s done. Or you can press the button to watch the repository to get an email alert.
Thank you.
-
ok... this means that i shall need to disable / remove all of the references to git lfs in the repo. Then re-upload it.
I'll let you know when it"s done.
Thank you.
OK done. It's currently at 366mb.
Can you explain your "r2" "r3" on the controller boards in your repo.
I did schematics for OLED-3.0 and OLED-3.1 to post in a new thread but you are calling one "2.1S r3" which seems confusing. I know there are many variants of these boards, a few different clones out there.
r = revision. Because there are so many revisions.
The one you are referring to was based upon the Ve2.1s r2 pcb design. But then the mid section has been redesigned. So purely in terms of what they were revising and taking from an existing design, it is in fact a further revision of that one. That is why it was labelled as 2.1s r3.
The problem is that there's 2 other completely different looking 'v3 x' designs.
So to at least keep that adjacency, and connection I can rename that one as "v3.0 r0"... How about that? It's really the best I can make of a bad situation here. Not my fault.
:-//
I'll make the change later today, and upload your new schematics to it's new folder in github. Is that OK ?
We still need the original schematic file, to edit and make better schematics of all the other derivations. This includes publishing schematics of all the possible mods on these boards. The need for it has only grown stronger over time. As predicted we are struggling in that area.
I think it would make things a lot easier then, for other people to trace their boards out and when they see they deviate from your schematic, to make corrections into the schematic. By editing it / tweaking it. So each revision can have it's own properly correct .sch file (or whichever reasonable format, kicad etc.).
My policy for managing this content, see "Disclaimers Section":
https://github.com/dreamcat4/t12-t245-controllers-docs#disclaimers
Bearing in mind these are clone stations, so I avoid publishing information there taken directly from original / official JBC stations. Only the chinese clone products. You have to draw a line somewhere.
-
So to at least keep that adjacency, and connection I can rename that one as "v3.0 r0"... How about that?
I say it's the best way, since both black versions support v3.0 firmware, but still they are different.
First revision (with STM32F101) supports both v2.0 and v3.0 firmware.
Second revision (with STM32F103) supports only v3.0 firmware. This version will shift image to the right if the display is the "small version" 128x64 pixels. If it's the normal display (132x64), all will be ok.
Here is the schematic for black boards "v3.0 r0" and "v3.0 r1" we drawed with floobydust. Only the MCU is different between them. Hope this helps you for the database. :)
-
Great.... if anybody else has a more 'sane' version naming scheme, then it's not a bad idea to field it now.
for example instead of using a sequential number, an alternative might be to use a character from the alphabet. So that they can then be rev'd ontop of that.
For example:
rev-a, rev-d, rev-g
Can then:
rev-d1
rev-d2
I didn't think of that before, because i had already used the letter 'r' to denote 'revision' instead of 'v' for 'version'.
If i can get some more feedback there, then it would make it more justifiable for me to change the current numbering scheme to something else like that. And also check to make sure that it can adequately cover for all the most commonly seen models.
-
The biggest part of the problem is the stores advertise: a soldering station version, a controller S/W version, a controller H/W version, and the PCB silkscreen version is usually different too.
I would not use the terms 'revision' or 'version' to tell different builds apart - there are a few different PCB versions and builds from different shops. They are compatible with each other to a large extent. That's the best part about Communism the "People's Soldering Iron" is a standard lol. I have the STM32 I/O assignments for at least five controller boards and they are almost identical.
i.e KSGER Store advertises "V2.01 2019" reporting "HW Version 2.0" but ships out OLED-3.0
"V3.1S 2020" (https://www.aliexpress.com/item/32790819535.html) reporting "HW Version 2.0" but is OLED-3.0 with no silkscreen name.
-
So I have had a good play with PID settings and have found it is fairly easy to tune them for any given setpoint, the problem is if you change the temperature even 30°C or so from the tuned setpoint it becomes completely unstable and requires retuning, which renders boost and sleep mode pretty much useless.
Now I know pretty much nothing about PID control, but it would seem we need some sort of setpoint compensation, or maybe I have missed something blindingly obvious?
-
In your prev. video, it looks like a software bug. Is that fixed?
As soon as the heater is off 0%, the displayed temperature makes big jumps. Setpoint is 300°C.
Heat is off and displayed temperature falling 303° (6%), 305° (1%), 325° (0%)... falling to 296° then heater on (100%) and display jumps down 46°, 48°, 87°, 313° (65%). The measured temperature should not have bad readings.
If those bad readings get into the PID, then the integrator term can wind up and cause overshoot afterwards.
When you edit PID settings, setpoint or gains I would reinit and clear the I term as well as the digital filters for all PID.
-
In your prev. video, it looks like a software bug. Is that fixed?
As soon as the heater is off 0%, the displayed temperature makes big jumps. Setpoint is 300°C.
Heat is off and displayed temperature falling 303° (6%), 305° (1%), 325° (0%)... falling to 296° then heater on (100%) and display jumps down 46°, 48°, 87°, 313° (65%). The measured temperature should not have bad readings.
If those bad readings get into the PID, then the integrator term can wind up and cause overshoot afterwards.
When you edit PID settings, setpoint or gains I would reinit and clear the I term as well as the digital filters for all PID.
Yes it does seem like a software bug, but it does seem to work ok if you get the gains right at a certain setpoint, but then if you change the setpoint it does the same sort of thing as in the video although not so bad.
In the video when the temperature is dropping from 325°C it the pid should start ramping up the output at 305°C but like you say nothing happens until 296°C which isn't right.
-
As I said before, ensure that the delay time is enough. And try other tips.
What are your pid settings?
Try increasing the PID time in setup.h.
Too quick might make this. Try 100mS.
Anyway I don't trust the PID algorithm used. I found so much bugs that it wouldn't suprise that it was wrong.
However my Jbc was perfect, +-3°C in all times.
Enter the debug menu and compare the adc1 with the adc1 raw readings.
Lastly, I can say a lot, but if you don't give feedback, it's useless...
The project is stopped, as I blew my mosfet last week(again) hooking the oscilloscope, the alligator clip loosened and fell over the connections.
Waiting for new AliExpress mosfets...
This beast heats crazy fast!
https://www.youtube.com/watch?v=20gnsCDd4iI (https://www.youtube.com/watch?v=20gnsCDd4iI)
-
Yeah thanks for that, I will try the pid delay and see what happens. I also tried setting the adc time to 900us, it made no difference. I will do some further investigation tonight, will also stick the scope on there(I'll make sure the clip stays on, oops;) to rule out a hardware issue, you are using the original MCP6002 op-amp I take it?
I can get the iron to stabilise at 300°C with the pids set at around 24 10 0 but as soon as you adjust the setpoint its starts doing silly things.
I also tried turning the filter off in setup.h, that didn't seem to make much difference either.
-
Yeah, I'm using all the original hardware.
I don't know right now how the PID time is set in the last update. As I usually play with it... So every update might be different, as this is still in development.
Does it still do the weird behavior of the temp going almost to zero?
I doubt it's a measure problem, the readings look to be clean, no spikes...
The PID decides to keep pushing...and somehow it causes a big hysteresis.
As I said, exactly that happened to me with two tips that had terrible heat transfer. The original fw lied a lot, you set 360 and could reach 380-390, then go down to 330, but always displaying 360!
And, the same: I could set the PID for one temp but changing it +-50°C made it crazy again, it got worse over few days, until it suddenly died. I didn't even use it for soldering!
-
Ok I see what is happening, the adc delay set to 900us does in fact help, the weird behaviour with the temp going to zero happens when it is set to 100us
1. This is a genuine Hakko T12 tip, you can see a slight fuzz @ 900us where the adc is sampled
2. This one is a chinese tip that came with the Quicko, settles much much faster
3. I'm guessing it is easier said than done to sample the adc just before the pwm pulse where the temperature value is more stable, rather than just after?
It still doesn't work very well with the Hakko tip even at 900us, but the chinese tips seem to work fine.
-
It's OK to lose a few msec while reading temperature. You have to wait because the heater is still hot and the sensor reading some of that heat, the mosfet to turn off etc. Or take the reading before switching the heater on.
For S/W development I use a thermocouple simulator. A known voltage source with divider resistors and potentiometer to dial in a desired uV and test software to see how it behaves at the limits and with changes etc.
Could modify it to tolerate 24V (heater) power and then it would bolt up to a T12 controller.
-
Yeah it seems it would be better to take the reading before the heater switches on.
I'm just wondering why the chinese tip work much better than the genuine hakko, incidentally the hakko tip also makes a noise maybe it is just defective?!
-
So my suspects were close! 300uS seems ok. But we'll have to try more tips to find a safe value. Maybe 500uS.
Your theory would work only in low pwm duties. How do we do that in a 9x% pwm?
If we do so, we will also need to measure the time since the pwm went down. Again, we will have wait.
But it'll be much more complicated. You can't delay the PWM output easily, pwm doesn't work like that.
Actually this is the method:
First, we set the maximum PWM value: 20.000uS period - ( ADC time(~30uS) + Delay time(~300uS) ) = 19.673uS
So at max PWM output we will always have the time for measuring.
This is how a PWM cycle works:
The PWM counter starts at 0, output goes high.
When the counter reaches the value in pwm value register, output goes low and the timer compare interruption triggers.
I use the interrupt to start a secondary counter that acts as delay. When the delay counter resets, automatically starts the ADC conversion.
The ADC conversion ends and generates an interrupt. The PWM is about to start, but we can measure the rest of the values. We start another conversion, just for the voltage and ambient temperature.
The counter continues (pwm off time) until reaching the PWM period register.
The counter resets and a new PWM cycle starts.
By now the ADC should have finished the secondary conversions. It disables, waiting for the next trigger from the delay counter.
This method has the advantage of being easily adjustable. We can modify the delay timer as we wish.
It works totally isolated from the main program, so it's much safer. A mistake causing a stuck loop won't leave the pwm calculation unattended, risking at burning your tip.
The max PWM will be 98.3%. It's ok! I can tell you that the stock fw, even the original PTdreamer one, heat slower because they take a lot of measurements and use higher pwm frequency.
Also, as we take measurements every 20mS, it should be pretty stable. What could be the max temperature variation in 20mS? Maybe 5ºC?
The only issue here is the delay. As you can see in the waveforms, it gets perfect after 300uS or even less depending on the tip.
Maybe we could add a second transistor and switch the heater to ground to quickly discharge the output. As long as we wait enough time to not shoot-through...
But again, why that much if we only need to wait!
The Hakko probably has higher inductance, mainly due the use of thicker heating elements and more turns?
-
The trouble is, it still doesn't work right at 900us with the hakko tip because even then the temperature reading jumps +20°C when the output goes to 0%
Maybe there is a hardware fix to remedy this, but I haven't thought of what it is yet, I did try a flywheel diode on the element but it made no noticeable difference
Edit: an easy way to get the hakko tip to work better would be to have a minimum pwm duty of 1%
-
Are you telling that this only happens with the Hakko?
Try to get some waveforms with the tip off, ex. set the temp to 400 and then suddenly set it to 200. To see what the TC output is.
Did you set the PID time higher yet?
-
Maybe adding 1MOhm pullup resistor that some ksger PCB have at the TC input would help in any way to stabilise TC reading faster?
-
I didn't notice before. It's the amp output, right?
Can you check at the heater pin? Or the mosfet source, whatever is easier.
-
Yes only the genuine hakko is a problem, the chinese tips work nice. With the hakko the slightest overshoot which puts the output at 0% sets it off in a vicious cycle because of the temperature drop when the pwm restarts. Haven't tried the pid delay yet, haven't had much time to play with it tonight
Yes I have been measuring the opamp output!
4. chinese tip @ opamp o/p for reference to previous ss
5. chinese tip @ opamp o/p, while switching from 0% pwm to pwm on, you can see there is a slight increase in temperature - reducing the risk of overshoot.
6. hakko tip @ opamp o/p, while switching from 0% pwm to pwm on, you can see there is a significant drop in temperature, which of course over ramps the pwm and causes overshoot and hence vicious cycle.
Can't remember which way around 7 and 8 are, but these are across the heater (still with flywheel diode btw), but you can just see a slight turn off negative voltage spike in one (the hakko I guess) I'll try without the diode tomorrow.
The hakko tip seems to have some sort of capacitive effect going on.
and yes tomorrow I will see what happens with a 1 meg pullup too.
note: 0v is at the bottom on the first 3, and in the centre on the last 2
-
Hmm definitely weird. Tomorrow will try setting the min pwm to 0.5% or so.
But I'd like to understand the cause.
-
Hmm definitely weird. Tomorrow will try setting the min pwm to 0.5% or so.
But I'd like to understand the cause.
Yes, me too, I am guessing the opamp doesn't much like negative voltage spike from the heater, further investigation required.
On a side note I think the opamp protection diode D1 in your schematic must be a 3v3 zener to protect the opamp input from the heater 24v
-
But there's no
Edit: ?? I don't what happenned to the message... neither where did that come from.
I think I left the phone unlocked lol.. luckly didn't type my credit number :-DD
-
In my schematic it's a simple 1n4148 diode.
The schematic is wrong, it's reversed.
So it limits the amp input to ~0.7V. All ok.
The ksger uses a LED to do the same thing.
-
In my schematic it's a simple 1n4148 diode.
The schematic is wrong, it's reversed.
So it limits the amp input to ~0.7V. All ok.
The ksger uses a LED to do the same thing.
Ok, so in this case there is nothing to protect the opamp input from the negative voltage spike, I'll have a look at that later.
-
Edit: Let me check the schematics...
Edit2: The're input clamp diodes. There's a 4K7 limiting resistor + filtering cap. Might be ok.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1133822)
-
6. hakko tip @ opamp o/p, while switching from 0% pwm to pwm on, you can see there is a significant drop in temperature, which of course over ramps the pwm and causes overshoot and hence vicious cycle.
Does that statement corrrespond to this pic? I see it needs almost 4mS to be accurate! Now please repeat in lower voltage scale to see the variation in uV :)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1133294;image)
If that is produced by the thermal impedance, we have a problem. We can't measure the temperature after each cycle on these, the wait is too long... 5mS is 25% of the pwm cycle!
I'll have to change back to tasked measurement, every x mS stop PWM, wait, measure, and resume PWM. I don't like that too much but if it works...
Or! We can apply a factor without waiting that much. Measure and removing a %. Although that may worsen the problem. I don't know.
Edit: I attach 0.1%, 0.5% , 1% and 2% min PWM bins. Please reset the settings holding the button before powering on (For now that settings are hardcoded and apply only on resetting). Please report results :)
And have a look at the temp! Anyway it's unlikely to burn the tip at 2%, I remember about 10% to hold the tip at 450ºC
-
Just for reference:
I just received a KSGER "2.1s" unit (https://www.aliexpress.com/item/4001174654612.html). It's what's called around here a "ve2.1s 'r2'" (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#blue-pcb-ve21s-r2-ksger-version-lwfp-64). Except, it has a STM32F103RBT6 (128K flash). I'm guessing they buy the cheapest which are available when they do a run. #dreamcat4, you may want to note that on your page.
Pulled #DavidAlfa code from here (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319820/#msg3319820). I think I've got it moved over to the B version (in addition to less flash, B doesn't have timers 6 & 8 ). Why does ST make this so hard??? Have an MCU on order to try (so I can unsolder the original as a backup), but it's not a B, I'll see how it works.
In any case, let me suggest that the STM32F103RBTx be used as the future target. AFAIK, that should be forward compatible with the C and higher versions. As David said:The actual purpose of this project is to make a compatible firmware -with- existing soldering stations, just as they come from aliexpress, ande require the minimum modding from the user.
Looking through github, I didn't see any obvious versions which support I2C displays, like the #DavidAlfa code mentioned above, including his git (https://github.com/deividAlfa/stm32_soldering_iron_controller). Is the intent to eventually allow that to be #define'd into the mainline code?
-
6. hakko tip @ opamp o/p, while switching from 0% pwm to pwm on, you can see there is a significant drop in temperature, which of course over ramps the pwm and causes overshoot and hence vicious cycle.
Does that statement corrrespond to this pic? I see it needs almost 4mS to be accurate! Now please repeat in lower voltage scale to see the variation in uV :)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1133294;image)
If that is produced by the thermal impedance, we have a problem. We can't measure the temperature after each cycle on these, the wait is too long... 5mS is 25% of the pwm cycle!
I'll have to change back to tasked measurement, every x mS stop PWM, wait, measure, and resume PWM. I don't like that too much but if it works...
Or! We can apply a factor without waiting that much. Measure and removing a %. Although that may worsen the problem. I don't know.
Edit: I attach 0.1%, 0.5% , 1% and 2% min PWM bins. Please reset the settings holding the button before powering on (For now that settings are hardcoded and apply only on resetting). Please report results :)
And have a look at the temp! Anyway it's unlikely to burn the tip at 2%, I remember about 10% to hold the tip at 450ºC
This one is a chinese tip waking from sleep 0%, and it works perfectly.
I think you are right the inbuilt opamp diodes are sufficient.
Thanks for the bins I tried the 0.1% one but unfortunately it doesn't help, it seems the temperature reading error is proportionate to the duty cycle, i.e. 1% pwm, error is negligible but 50% pwm introduces a big error, temperature reads lower than actual. This means when the pwm is ramping down as we approach set point we have already overshot and nobody knows lol!
I don't like to admit defeat but I'm running out of ideas
-
This one is a chinese tip waking from sleep 0%, and it works perfectly.
I think you are right the inbuilt opamp diodes are sufficient.
Thanks for the bins I tried the 0.1% one but unfortunately it doesn't help, it seems the temperature reading error is proportionate to the duty cycle, i.e. 1% pwm, error is negligible but 50% pwm introduces a big error, temperature reads lower than actual. This means when the pwm is ramping down as we approach set point we have already overshot and nobody knows lol!
I don't like to admit defeat but I'm running out of ideas
Just for testing... This fw allows much bigger delays. Max 5mS, and 5mS by default(Again, reset settings).
I didn't test it... be careful about the tip.
If that doesn't work... Man I'm out of ideas.
Given the low impedance of the TC + heater, how can it hold energy for so long?
Can you post the exact picture where the TC goes lower with the PWM? I can't see a big difference in the TC output in your pics.
Don't worry, it's my IQ not shining again :-DD.
The recovery time, sure, it was very noticeable
-
Just for reference:
I just received a KSGER "2.1s" unit (https://www.aliexpress.com/item/4001174654612.html). It's what's called around here a "ve2.1s 'r2'" (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled#blue-pcb-ve21s-r2-ksger-version-lwfp-64). Except, it has a STM32F103RBT6 (128K flash). I'm guessing they buy the cheapest which are available when they do a run. #dreamcat4, you may want to note that on your page.
Pulled #DavidAlfa code from here (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319820/#msg3319820). I think I've got it moved over to the B version (in addition to less flash, B doesn't have timers 6 & 8 ). Why does ST make this so hard??? Have an MCU on order to try (so I can unsolder the original as a backup), but it's not a B, I'll see how it works.
In any case, let me suggest that the STM32F103RBTx be used as the future target. AFAIK, that should be forward compatible with the C and higher versions. As David said:The actual purpose of this project is to make a compatible firmware -with- existing soldering stations, just as they come from aliexpress, ande require the minimum modding from the user.
Looking through github, I didn't see any obvious versions which support I2C displays, like the #DavidAlfa code mentioned above, including his git (https://github.com/deividAlfa/stm32_soldering_iron_controller). Is the intent to eventually allow that to be #define'd into the mainline code?
Oh, don't be shy. Select the B part even if you have a "8". 99.99% It will work.
The fw is still made for the 8 in mind.
The project properties will say it's a B, I noticed that when creating a new project, It always select the B part on the preprocessor define, no matter if you choose a 8 or a B.
It's the linker script what limits the flash.
Anyway, the code will work the same between R, C versions... the pin coun't doesn't matter, the core is the same.
Only few adjustments are required. Yes, we were figuring out the correct way to unify everything.
But Stm32 Cube Ide gave some trouble, so in the end I'll probably have a folder for each hw with the base project and few definitions, requiring the user to copy it to the project root. Not a big mess.
The i2c is barely tested yet, there's a secondary branch for it, pretty old, I just made the i2c work in DMA mode and left it there.
I will soon add the i2c support to the main branch.
But it's hardware i2c, these ksgers don't use it. A simple 2-wire mod will fix this, check this:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319738/#msg3319738 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319738/#msg3319738)
As if i2c wasn't already slow enough, so to make matters worse they used software IO! Those chinese must be high... or their water poisoned :-DD.
Sorry for the multiple posts!
-
Oh, don't be shy. Select the B part even if you have a "8". 99.99% It will work.
No, I have a "B", the archive is for a "C". "8" is nowhere to be found. :-DMM But, I'll be replacing the B (which will be the backup) with an E, because that's what I can get soon. I don't doubt it will be fine. The point is that future builds should be for the "least common denominator", to support less sophisticated users in the future.
it's hardware i2c, these ksgers don't use it. A simple 2-wire mod will fix this, check this:
I saw that, and that's the plan.
Edit: are all 103s the same die, and they just bin them when screening? There are so many, that doesn't provide much faith in their production processes.
-
Can you post the exact picture where the TC goes lower with the PWM? I can't see a big difference in the TC output in your pics.
Yeah I'll have a go at that tomorrow. It does seem strange how it performs so badly compared to the cheap chinese one, like I speculated before it could always be a faulty tip, but I don't fancy buying another :o and either way it seems predominantly a hardware issue.
-
No, I have a "B", the archive is for a "C". "8" is nowhere to be found. :-DMM But, I'll be replacing the B (which will be the backup) with an E, because that's what I can get soon. I don't doubt it will be fine. The point is that future builds should be for the "least common denominator", to support less sophisticated users in the future.
Edit: are all 103s the same die, and they just bin them when screening? There are so many, that doesn't provide much faith in their production processes.
It's already done for the c8!
It uses the linker script "STM32F072C8TX_FLASH.ld"
And yes they seem to be all the same die. If your C8 gets programmed as a CB without errors, your extra flash is ok!
Not sure if it's fault free in the complete voltage and temperature range, but at least for me it worked well both for a 072C8 and a 103C8.
-
Some screenshots of the error caused by the pwm, these are all waking from sleep at various temperatures, you can see the error ranges from 0 to -80mv from 0 to ~90% pwm.
The first 4 screenshots are the hakko which produces a negative error, the last one is the chinese tip which produces a similar error but it is positive.
If you think about it the negative error increases the overshoot tendency, whereas the positive error decreases it, and this is the problem.
I have a new theory, the difference between these tips is in one tip the heater is in the positive leg of the thermocouple and in the other tip it is in the negative leg of the thermocouple.
-
If that was true, the TC would push negative voltage, the amp would always see ~0°C.
-
If that was true, the TC would push negative voltage, the amp would always see ~0°C.
No it wouldn't, it would look like this.
-
Oh, you mean that! In that case there's no difference. They're in series in any case...
That negative spike is huge! Needs a diode or RC snubber ASAP.
I think the problem is the spike. The chinese tip stores less energy and doesn't discharge the amp cap completely.
But the hakko spike is so huge that it needs a lot of recovery time?
A snubber would be an option here.
Ex. 10nF in series with a 10ohm resistor. Totally empiric, bigger cap, lower the spike, higher the losses.
This in parallel with the tip. Will absorb the spikes but don't use power once the RC constant is over.
Very used in flyback circuits.
(https://incompliancemag.com/wp-content/uploads/2015/12/1601_PT_fig2.png)
-
Yeah after drawing it I couldn't see why it would make any difference either.
That is not the negative spike you can see in the last screenshots (0v is at the bottom), this is the amp output at 0v for around 100us.
I previously measured the negative spike (with 1n4007 flywheel diode across heater), the chinese tip was -1.6v and the hakko -3.2v, removing the diode made the hakko go upto around -4v, funny thing is these spikes only last less than 1us.
I think slowing the mosfet turn-off may help somewhat, I see the turn-off resistor R6 is 10k, perhaps I will try a 20k in its place
Screenshots taken from across heater, 0v at centre:
-
Hello all,
I'm sorry to interrupt just in your eager conversation.
I received my Quicko station, new hw-design (sais 108W, AC and has also a DC24V4A), HW:V3.1 SW:V7.1M, with a 6-pole connector for the soldering tip - grounding of the chassis is okay out of the stock ;)
However, I'm wondering if and how I coud try out your new firmware for this device (because I cannot set different settings for different tips)
The controling device has got a μC I cannot find any infos for:
STM32
F072TBT6 <- for me this really is a B not an 8
GQ28Z 129U
CHNGQ 024
Do you know what STM32 piece this is - maybe it's a fake?
And, if this chip is possibly able to load your firmwares.
Thanks in advance!
Cheers
shh
-
And for that the snubbers exist!
If you have the components, try 10ohm/470pF. And increase the capacitor value while taking screenshots.
Also, 1N4007 is not a fast diode.
Put a fast schottky rectifier and you'll see!
-
CB is the same as the C8 with a litle more flash.
It should work perfectly with the C8 fw.
However you'd better replace the mcu instead, to preserve the original fw.
-
My chip is a CBT6, I'm assuming TBT6 is a typo?
I'll have a look for a faster diode and try that, I'm not convinced the snubber is going to help much but I'll give it a go.
-
Well you were right, I found a sb560 schottky diode and that clamps the negative spike much better than the 1n4007, brings it down from -4v to around -1v
Unfortunately it doesn't help with the pwm temperature error, I think ideally this needs compensating for in the software on a per tip basis, although I quite like the idea of a jbc t245 handle
-
When the heater is on, the op-amp input is saturated and needs time to recover.
There are at least five different thermocouple op-amps out in the wild, and some are low power, slow parts. Their overload characteristics vary - some cheap op-amps phase-invert when overloaded, especially with any -ve input spikes.
Here are scope traces from my KSGER T12 H/W V2.1S with OPA336N (https://www.ti.com/lit/ds/symlink/opa336.pdf) op-amp "A36" and their D12 tip, idling at setpoint 300°C.
It shows the heater voltage along with TC op-amp output to give some clarity.
You can see the mosfet takes about 100 20usec to turn off.
The op-amp takes 250usec to desaturate.
The thermocouple-to-heater thermal time constant is about 1.7msec, so 5 tau to drop to 99.3% of settled value needs 8.5msec.
That gives us a blanking period of around 10msec required.
The PWM frequency is 5Hz (200msec). I think 50/60Hz worked for old triac controllers but we cannot use it due to the long (thermal) time constant of the TC. I don't see an advantage to usec timing, when the accuracy reading the TC is lost due to the high speed.
-
When the heater is on, the op-amp input is saturated and needs time to recover.
There are at least five different thermocouple op-amps out in the wild, and some are low power, slow parts. Their overload characteristics vary - some cheap op-amps phase-invert when overloaded, especially with any -ve input spikes.
Here are scope traces from my KSGER T12 H/W V2.1S with OPA336N (https://www.ti.com/lit/ds/symlink/opa336.pdf) op-amp "A36" and their D12 tip, idling at setpoint 300°C.
It shows the heater voltage along with TC op-amp output to give some clarity.
You can see the mosfet takes about 100usec to turn off.
The op-amp takes 250usec to desaturate.
The thermocouple-to-heater thermal time constant is about 1.7msec, so 5 tau to drop to 99.3% of settled value needs 8.5msec.
That gives us a blanking period of around 10msec required.
The PWM frequency is 5Hz (200msec). I think 50/60Hz worked for old triac controllers but we cannot use it due to the long (thermal) time constant of the TC. I don't see an advantage to usec timing, when the accuracy reading the TC is lost due to the high speed.
Interesting, so I assume this is custom firmware and you are measuring the TC 10ms after the heater switches off?
-
The only possible approach possible I see is to only take 10 measures/second, and wait 10mS for each.
We lose 100mS time, 10% power. We can barely filter with so few values, the filter must have a very low coefficient to avoid delay.
We can't take a lot more of measurements, we'll lose a lot of power.
We can't take less measurements, as the high power heat the tips very fast and risk overshooting.
-
The only possible approach possible I see is to only take 10 measures/second, and wait 10mS for each.
We lose 100mS time, 10% power. We can barely filter with so few values, the filter must have a very low coefficient to avoid delay.
We can't take a lot more of measurements, we'll lose a lot of power.
We can't take less measurements, as the high power heat the tips very fast and risk overshooting.
Can we not just allow the pwm to be set upto 200ms and the adc delay upto 10ms and leave it working how it does now so it still gives 95% power, or you are saying 5hz sampling is too slow?
-
Those scope measurements are from stock KSGER S/W 2.10
I would say the tips are hugely overpowered. Yes superfast warmup but 75W realistically doesn't make it to the work being soldered, the heat loss in a slim tip is more of a limiting factor, especially with the clones avoidance of using copper. So I'm saying the crappy soldering experience is due to that, not any controller lag. Old triac controllers are strictly proportional-only, all P and no I or D and they did OK.
Another way to look at it- tips can do a warmup from 25°C to 300°C in ~7 seconds, that's about 40°C/sec or 4°C/100msec rate of climb. Even at 90% PWM.
If you are 100msec late deciding to turn on heat, a 4°C sag in tip temp (in free air, a bit more if touching cold) - is quickly overcome in a fraction of a second.
I'm in favour of a 5Hz sample rate and 10msec blanking as a start until more data comes in. We don't know if it's OK for Hakko and JBC yet, and if some op-amps are reacting bad to the overload or -ve spikes.
Going to 10Hz I see no advantage to saving the 100msec there, the tip mass covers for fast drops and we have so much heat to spring back from a dip.
-
Ookey! The cold is coming, any excuse is ok for burning something and heating the house :-DD
This fw allows 10-650mS PWM periods and ADC Delay of 1-500mS (or Period-1 if <500).
By default Period=200mS, Delay=20mS.
Exotic filterings disabled, only average of last ADC buffer.
Remember to reset settings!!
-
Ookey! The cold is coming, any excuse is ok for burning something and heating the house :-DD
This fw allows 10-650mS PWM periods and ADC Delay of 1-500mS (or Period-1 if <500).
By default Period=200mS, Delay=20mS.
Exotic filterings disabled, only average of last ADC buffer.
Remember to reset settings!!
This seems to work pretty well, its the first time the hakko tip can stabilise at 330°C and at sleep 150°C with the same pids :-+
I did have to set the adc delay to 50ms tho as the hakko seems to have a pretty hefty recovery time when set to 330°C although interestingly it almost completely disappears when set to 370°C (screenshots)
Seem quite useable now, even with no exotic filtering, good work!
-
And if you add the snuffer it will filter the spike, it won't rise so fast, then the diode will have more time to react .
Just a thought: Try replacing the cap at the amp input with a 100pF one, and see how the signal is affected.
Anyway I don't see anything wrong.
For 1nF and 4.7K, the 5RC constant is 23.5uS
-
I still think the best place to measure the temperature is right before the heater turns on, then we can get close to 100% pwm and the error makes no difference(as we are not close to setpoint) and when we are at say 10-20% pwm close to the setpoint we get maximum adc delay for minimal error where it does make a difference.
Perhaps you could make a firmware that puts out 100% pwm continuously and I'll test it on the hakko, that will solve the hakko tip problem :-DD
-
Nope! If you set the pwm too high you will also have to wait!
-
Nope! If you set the pwm too high you will also have to wait!
I mean the hakko will glow red >:D
-
Well, in my experiments it was a bright orange, slightly illuminating the room, like a candle! A 15-second-life bulb, not very efficient...haha
-
:-DD
Something like this would work best I'm thinking, so fast enough at 10hz, can get 99% power and the important bit we get 80ms recovery time @ 20% pwm for accurate measurement close to setpoint.
-
@Bozog: Oops, you're right it's an F072CBT6 - sorry!
@DavidAlfa: Regarding preserving the original mcu (and its fw): Never did a that big desoldering before. This 48 pin μC looks really frightening... :scared: Any tips?
-
@Bozog: Oops, you're right it's an F072CBT6 - sorry!
@DavidAlfa: Regarding preserving the original mcu (and its fw): Never did a that big desoldering before. This 48 pin μC looks really frightening... :scared: Any tips?
Desoldering it is the easy part, with hot air or low melt solder, getting the new one on you'll need some good eyes, some decent flux and possibly some solder braid if you're doing it with an iron.
-
@Bozog: Oops, you're right it's an F072CBT6 - sorry!
@DavidAlfa: Regarding preserving the original mcu (and its fw): Never did a that big desoldering before. This 48 pin μC looks really frightening... :scared: Any tips?
This is a good example of how to do it.
Personally I avoid using the desoldering braid if possible, he used too little flux.
If the solder starts acting like a sticky mass, drop some flux, clean the tip and most of the solder will get suck by the tip.
Be bery careful, don't make more pressure than barely touching it! It's very easy to bend a pin or lift a pad.
Specially if using braid, don't use a large sections, only the tip, because the opposite side to the part you're heating will cool down and stick to whatever is touching.
Then, at the smallest movement you'll tear whatever it was sticking to.
https://www.youtube.com/watch?v=QiIy3Oe2UGI (https://www.youtube.com/watch?v=QiIy3Oe2UGI)
:-DD
Something like this would work best I'm thinking, so fast enough at 10hz, can get 99% power and the important bit we get 80ms recovery time @ 20% pwm for accurate measurement close to setpoint.
Not correct, 10Hz*10mS = 100mS off time, max power=90%. Not bad anyway, i'ts very rare to use more than 50%.
Maybe those giant flat tips for reworking BGAs will use all the power.
The frequency is not important if the temperature regulation works correctly. What I don't want is the temp dancing around like it did before.
Could you make a video to see how it performs? My mosfets are still in the way...
-
@Bozog: Oops, you're right it's an F072CBT6 - sorry!
@DavidAlfa: Regarding preserving the original mcu (and its fw): Never did a that big desoldering before. This 48 pin μC looks really frightening... :scared: Any tips?
This is a good example of how to do it.
Personally I avoid using the desoldering braid if possible, he used too little flux.
If the solder starts acting like a sticky mass, drop some flux, clean the tip and most of the solder will get suck by the tip.
Be bery careful, don't make more pressure than barely touching it! It's very easy to bend a pin or lift a pad.
Specially if using braid, don't use a large sections, only the tip, because the opposite side to the part you're heating will cool down and stick to whatever is touching.
Then, at the smallest movement you'll tear whatever it was sticking to.
https://www.youtube.com/watch?v=QiIy3Oe2UGI (https://www.youtube.com/watch?v=QiIy3Oe2UGI)
:-DD
Something like this would work best I'm thinking, so fast enough at 10hz, can get 99% power and the important bit we get 80ms recovery time @ 20% pwm for accurate measurement close to setpoint.
Not correct, 10Hz*10mS = 100mS off time, max power=90%. Not bad anyway, i'ts very rare to use more than 50%.
Maybe those giant flat tips for reworking BGAs will use all the power.
The frequency is not important if the temperature regulation works correctly. What I don't want is the temp dancing around like it did before.
Could you make a video to see how it performs? My mosfets are still in the way...
My example used a 1ms delay and 99ms pwm period, so exactly 99%
With a 1ms delay I get a big temp error at 100% pwm, probably 16-20°C but it doesn't affect stability so far from setpoint
If we can move where the adc is sampled we can then get 80ms delay at 20% pwm where we are close to the setpoint, then the error is negligible and it works well
I'll make some videos, 200ms period 50ms delay works well, but obviously only 80% power so not ideal. Could probably get away with 40ms delay.
If I bring the delay down to 10ms it doesn't work very well at lower temps <330°C, have to back off the pid gains and it still won't stabilise at sleep 150°C
Let me know your address and I'll send you the tip if you like, I've had enough of it anyway |O
edit: Yeah I don't like using the braid to remove bridges either, more flux and a clean iron is the way to go!
-
I don't get it. You must sample always in the same way. If you sample after 80mS you'll get for sure the real temp.
In your drawing, the last pwm wave with ~99%, will get a crazy higher/lower reading, this is exactly what happened with low delays.
What I don't understand yet is why you need such high delay.
Try a small snubber!
And I don't think sending the tip to Spain does worth it , I'll probably burn the tip, but not by accident :-DD
-
I don't get it. You must sample always in the same way. If you sample after 80mS you'll get for sure the real temp.
In your drawing, the last pwm wave with ~99%, will get a crazy higher/lower reading, this is exactly what happened with low delays.
What I don't understand yet is why you need such high delay.
Try a small snubber!
And I don't think sending the tip to Spain does worth it , I'll probably burn the tip, but not by accident :-DD
~99%, will get a crazy higher/lower reading - yes it does around 16-20°C but we are heating iron, far from setpoint, maximum power is more important than accuracy.
Hakko tip measurement accuracy is terrible <~40ms (as can been seen from waveform a few posts back) and the error is negative which destabilises pid, because as we are approaching the setpoint, the pwm ramps down, the error gets less, and the measured temperature gets greater - hard to explain lol
Have tried snubber and diode, the do clamp the negative spike but don't help the op-amp recovery time.
-
200/50ms pid 28 8 0 - works fine, max power 80%
https://www.youtube.com/watch?v=IDvdGg_H5x0 (https://www.youtube.com/watch?v=IDvdGg_H5x0)
200/10ms pid 28 8 0 - unstable at both 150°C and 320°C, max power 95%
https://www.youtube.com/watch?v=iIxTKa_oumg (https://www.youtube.com/watch?v=iIxTKa_oumg)
200/10ms pid 18 7 0 - unstable at 150°C, stable at 320°C, max power 95%
https://www.youtube.com/watch?v=uSDMhM8Etic (https://www.youtube.com/watch?v=uSDMhM8Etic)
-
And I don't think sending the tip to Spain does worth it , I'll probably burn the tip, but not by accident :-DD
Would be a lot cheaper than the tip to send, it won't heat your room very much tho, you cold? :-DD
-
And I don't think sending the tip to Spain does worth it , I'll probably burn the tip, but not by accident :-DD
Would be a lot cheaper than the tip to send, it won't heat your room very much tho, you cold? :-DD
Your issue may be hardware related and not software. There's another thread that even the OEM firmware is having issues with authentic Hakko tips. Perhaps another unforeseen circumstance where they used a lesser expensive component that works fine with clone tips but does not work when authentic tips are used. :-//
-
And I don't think sending the tip to Spain does worth it , I'll probably burn the tip, but not by accident :-DD
Would be a lot cheaper than the tip to send, it won't heat your room very much tho, you cold? :-DD
Your issue may be hardware related and not software. There's another thread that even the OEM firmware is having issues with authentic Hakko tips. Perhaps another unforeseen circumstance where they used a lesser expensive component that works fine with clone tips but does not work when authentic tips are used. :-//
Yes quite possibly, but there does not seem to be any quick fix for the hardware. I'm confident it can be made to work almost perfectly in the software(see above), without making any sacrifice - I'm going to need a stm32 crash course tho!
-
LE: Meanwhile i'm sort of beta tester for the v3.1S firmware and the board is alive again.
Greetings to all here ( & Merry X’mas), from a New member here from India, Trivandrum.
Special Thanks & appreciation to “DavidAlfa”, “dreamcat4”, “floobydust”, “Bozog”, cosmin1 & other active members here, for their great contributions so far on this fantastic OpenSource project. I am a Hardware & Software Engineer & Hobbyist from India, & planning to acquire a T12 Quecco/KSGER unit from AliExpress and participate in your wonderful venture, shortly.
@cosmin1,
I have some questions to you, w.r.to your above post #403, (Dec-08), to start with.
1. The “V3.1S” firmware [“3.1Snew1.hex”, 157.48 KiB], you were testing, Is it the one received from member “nkls” of the Russian Radiokot forum, which claims to have fixed the T12-BCM2 Tip Calibration Bug?
2. Does after flashing this “3.1Snew1.hex” firmware, the unit needs the “RG1” & “RG2” keys to be entered, for it to start working?
3. I have some confusion as to the exact T12-KSGER unit you have, & used for the above 3.1S test?
Can you confirm whether this is as below:-
a) “3.1S” hardware black-controller PCB.
b) ARM-uC: STM32F 101RBT6.
c) SysInfo Menu: [HWver 2.00, SWver 2.12].
d) Categorized as “2.1S r3” by dreamcat4 (github doc)
e) OLED: 1.3” 6-pin 128 x 64, SSH-1106, I2C-i/f ?
f) Board Schematic as per “KSGER STM32 OLED-3_0 schematic rev1_cosmin_floobydust.pdf”,
you posted in post-#430 here, dated Dec-12, 2020.
4. Finally, Why do you call it ver-3.1S, even though SysInfo-Menu says Hw-Ver 2.00?
Is it because of any PCB silkscreen markings? But I did not see any such markings in your posted photos earlier?
Rgds Bhishmar
-
There are a ton of problematic factors.
The analog frontend isn't what you would call great.
First, directly interfacing the TC without cold junction compensation (and I doubt that just adding the temp. from the sensing NTC is ok).
For measuring such low voltages they should have used symmetric power for the amps to void the offsets. Although it manages it pretty well I must say.
Check the great, non-existent filtering for the inductive spikes for the heater.
The transistor driver is not good for fast switching...
And the ksgers are even worse with a switching supply driving the amp, that gets max 20mV input.
My thinking was to put the schottky diode diretcly in the handle, so the spikes are cut down much faster.
Nice review, maybe I should starting selling these? :-DD
You need a more Kd. No Kd would cause weird response in my tests. Around 40-5-30 Kp, Ki,Kd but would vary a lot between tips
-
There are a ton of problematic factors.
The analog frontend isn't what you would call great.
First, directly interfacing the TC without cold junction compensation (and I doubt that just adding the temp. from the sensing NTC is ok).
For measuring such low voltages they should have used symmetric power for the amps to void the offsets. Although it manages it pretty well I must say.
Check the great, non-existent filtering for the inductive spikes for the heater.
The transistor driver is not good for fast switching...
And the ksgers are even worse with a switching supply driving the amp, that gets max 20mV input.
My thinking was to put the schottky diode diretcly in the handle, so the spikes are cut down much faster.
Nice review, maybe I should starting selling these? :-DD
You need a more Kd. No Kd would cause weird response in my tests. Around 40-5-30 Kp, Ki,Kd but would vary a lot between tips
I'm not much interested in modifying the hardware too much, I believe that although not perfect, it can be made to perform pretty well with the right software with both clone and genuine tips.
So that is what I am going to do. I have plenty of experience with C, arduino, pic etc but I am a complete stm32 noob so any advice welcome - to be honest I can't even see how much of your software works at the moment!
I'm thinking all it needs basically is a 100ms timer interrupt that will first sample the adc and then start the 99ms pwm cycle - of course nothing is ever easy...
-
After going through the various thoughts & suggestions here by the various esteemed members, I have the following observations & suggestions.
1) To avoid TC-opamp output +ve saturation (when the heater is ON) & the resulting high recovery time, possibly a negative feedback Zener can be connected between, the out (pin-4) & the inv-i/p (pin-4), of the opamp. Direction: Zener-Kathode at the opamp output. The Vz of this Zener should be < 3.3V & > 2.25V (corresponding to highest sensed 450°C). I feel a 3.3V zener itself may be adequate here, since it starts its cut-in (knee) before 3.3V, and provides necessary negative feedback. But it should be tested to ensure that it does not conduct before 2.25V (2.7V is ok), to prevent messing with higher temperature sensing. May be a 2.7V Zener is ideal, if this above condition is ensured. This gives more flexibility (& freedom) in the timing selection of ADC-read by David.
2) I feel, a clamping schottky-diode should still be connected at the opamp +in (pin-4) to gnd, to limit its Vin to +0.2V to 0.3V, even with the above zener present, to reduce +ve saturation stress on the input of opamp. (Position-D4 of flooby-cosmin sch-pdf Rev-1). If the above Zener is not there, this schottky-diode (as against any other diode) will reduce the saturation stress, even though not preventing it.
3) Another surge or transient suppression diode, should be connected at the heater +ve output (MOSFET-drain) to Gnd, to protect/prevent the MOSFET stress, as suggested by many others here. But this diode should be there, NOT only to protect the MOSFET, but also to reduce the –ve side saturation of the opamp. The opamp will still saturate, since even 0.2v-0.3V of the schottky is enough to saturate the opamp-input. But it should be a schottky-diode (not fast recovery diode), to reduce the limiting voltage to 0.2V-0.3V, rather than 0.7V. We should not simply depend on the internal limiting Zener of the TCP8107 PMOS Transistor, for this.
4) The position of this schottky should be at the controller board somewhere near MOSFET drain. (Position: RS1A of floobydust schematic Rev-2). It should NOT be at the soldering-handle across the heater, since the transient/surge causing inductance is NOT only due to the heater coil, but also due to the ~1meter long handle/wand-cable.
5) The input clamping diodes (both polarity) inside the opamp-die (pointed out by David), may provide some protection to the opamp device (not prevent saturation stress ). But these diodes may be overwhelmed if the input spikes are too high, even with the input resistor 4K7 Ω (R8/ R12D), if the spurious capacitance across these smd resistors pump more current during sharp rising transients.
-
What I would do is to add a signal mosfet at the input of the amp, shorting the input to ground until the input is ready.
The amp saturates with ~13mV input (250 gain).
Zeners and such won't help else than for protection.
-
What I would do is to add a signal mosfet at the input of the amp, shorting the input to ground until the input is ready.
The amp saturates with ~13mV input (250 gain).
Zeners and such won't help else than for protection.
Typically, No amount of signal tampering/shorting at the input of an OpAmp can prevent its saturation, especially at such high gains, unless otherwise you resort to specific negative feedback.
But I have to respectfully disagree to the point that the Zener can only provide protection. Allow me to explain.
My suggestion (in above post #498) of a 2.7V Zener was not for device protection. Instead it is for clamping the output of the opamp below (<=) 2.7V, and thereby prevent its output stage getting saturated, & creating all the extra recovery time delay issues. This is achieved thru opamp negative feedback, by connecting this Zener btw its output-pin and its inverting-input pin, as shown in the figure attached below (Option-1, Zener-FB). This is achieved with no sideeffect on the normal TC-amplifier (gain=250) action.
(http://[attachimg=1])
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1139254;image)
Infact, I think your signal MOSFET solution also will be more effective, if it is connected as negative feedback to opamp (fig Option-2), rather than simply shorting the input to Gnd. It has the added benefit of giving this limiting at both polarities (+ & -). But you have to select an NMOS with <= 2.5V Vgs Threshold, when operating from +3.3V, since its source also will be raised up.
The option-1 negative feedback Zener will clamp (limit) the opamp output, for +ve going input only. When the input signal goes negative (transient -ve spike) at the MOSFET power-off instant, the opamp ouput stage may still be saturated in the –ve direction. But since the opamp is powered with single supply, output is limited to zero. The negative-feedback from reverse diode action of the zener-diode will not come into effect till Vin goes below -0.7V. But still the opamp output stage will be saturated, creating recovery time delay I think.
But in both the above cases it has to be positively ensured that the presence of the device (Zener or Mosfet channel) across the opamp will be a complete insulator when Vin < 13mV (from TC), and so does not mess up the 250 gain of the opamp, in its normal TC-amplifier operation.
-
@cosmin1,
I have some questions to you, w.r.to your above post #403, (Dec-08), to start with.
1. The “V3.1S” firmware [“3.1Snew1.hex”, 157.48 KiB], you were testing, Is it the one received from member “nkls” of the Russian Radiokot forum, which claims to have fixed the T12-BCM2 Tip Calibration Bug?
2. Does after flashing this “3.1Snew1.hex” firmware, the unit needs the “RG1” & “RG2” keys to be entered, for it to start working?
3. I have some confusion as to the exact T12-KSGER unit you have, & used for the above 3.1S test?
Can you confirm whether this is as below:-
a) “3.1S” hardware black-controller PCB.
b) ARM-uC: STM32F 101RBT6.
c) SysInfo Menu: [HWver 2.00, SWver 2.12].
d) Categorized as “2.1S r3” by dreamcat4 (github doc)
e) OLED: 1.3” 6-pin 128 x 64, SSH-1106, I2C-i/f ?
f) Board Schematic as per “KSGER STM32 OLED-3_0 schematic rev1_cosmin_floobydust.pdf”,
you posted in post-#430 here, dated Dec-12, 2020.
4. Finally, Why do you call it ver-3.1S, even though SysInfo-Menu says Hw-Ver 2.00?
Is it because of any PCB silkscreen markings? But I did not see any such markings in your posted photos earlier?
1. Yes, it's from Nikolai. He said all bugs are fixed in this firmware.
2. From what i remember, v.3 doesn't need activation.
3.
a, b) 3.1S marked black PCB with STM32F 103RBT6 and 2.1s r3 PCB without markings using STM32F 101RBT6 MCU, same schematic.
Difference is, STM32F 101RBT6 supports both v3.1S and v2.0 firmware. STM32F 103RBT6 only supports firmware v3.1S. However, some russians reports they are still using v2.0 firmware on this v3.1s board. Mine doesn't work.
c) Yes, before flashing, i had HWver 2.00, SWver 2.12. But the the available v2.0 or 2.1 firmwares does not work on the controller with STM32F 103RBT6.
d) Exactly. Difference from the marked v3.1S is as i said, the 101RBT6 MCU.
e) I have OLED: 1.3” 6-pin 128 x 64, SSD1306 and a 1.3” 6-pin 132 x 64 SH1106. 3.1S marked board uses the 1.3” 6-pin 128 x 64, SSD1306 and the image is shifted to the right. I ordered a 132 x 64 SH1106 display to replace it.
f) that schematic is the same for both black boards.
4. I call it v3.1 because it's marked like that. Don't know what v2.0 firmware did he used before, because now it only supports v3.1S firmware.
(https://b9.eu.icdn.ru/c/cosmin34/2/69165052zMc.jpg?20201227133947)
Same as v2.1s r3. Just the battery connector position is moved:
(https://b9.eu.icdn.ru/c/cosmin34/4/imgsrc.ru_69315694tNr.jpg)
-
Now I understood your idea!
That's a very nice workaround indeed!
Bozog, can you test if and check if it improves the delay problem?
-
Well I could, but is the opamp recovery time really a problem, from what I see it is fast <300us?
With the hakko tip the opamp output is 0v (for 200us) very soon after the heater switches off, and this I think is due to the heater coil negative voltage spike induced thermocouple error.
I need to put the oscilloscope on the heater output again with the 200ms firmware.
-
Now I understood your idea!
That's a very nice workaround indeed!
There is always a saying in electronics. A para or a page of write-up can never defeat a simple circuit diagram. :)
‘Bozog’, if u are planning to test this, make sure the schottky-diode (D4) clamp at the + (non-inv) input is also there. (Fig-1a)
Why?
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1139862;image)
When this opamp works in Closed Loop-Negative-feedback mode (its normal mode), its output Vo = (Vi + Vz) = ClampVoltage [0.3V] + ZenerVoltage [2.7V] = 3.0V (when Heater is ON)
[Vi is the opAmp input (inv) pin voltage.]
So for this Diode-clamp (D4) if you use any other diode, (i.e. a 1N4148 [0.7v] or LED [1.8v]), the above sum will exceed +3.3V, which defeats the purpose, of keeping the opamp within negative-feedback linear region.
I will try to test a discrete 2.7V Zener in stand alone mode, to see how its Cut-in knee voltage behave. The intention is to find out how much earlier it will start conducting before reaching 2.7V. If the 2.7V Zener starts its knee before 2.25V, then the TC-amp gain will reduce from 250, for higher temperature sensing near 450°C.
But we have good margin 2.7V- 2.25V = 0.45V, So I don’t expect any problem. Just for confidence.
2.25v is the opamp output corresponding to 450°C.
For this parameter/phenomenon (0.45v margin), the additional schottky voltage +0.3V does not influence, since when voltage ‘Vin’ raises, so also Zener-Anode voltage at inv-inp pin-4, due to standard Opamp-virtual-Gnd phenomena.
-
It stranges me too that the big delay is caused by the amp... but who knows!
-
But is the opamp recovery time really a problem, from what I see it is fast <300us?
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1140316;image)
From the expanded view of your graph above, the settling time from Heater-Off is nearly 500 to 600 µs. But if you consider 90% of the final settled value, then this time is ~400 µs. But this figure is prone to widely vary from unit to unit, depending on the following phenomena.
- The quality of the opamap device.
- The amount of overstress, the opamps input & output stages are subjected to, based on the presence or absence of voltage-clamping/limiting devices. This includes phase-inversion by some really bad opamps, as pointed out by floobydust.
- Speed of turn-ON & turn-OFF of the power MOSFET depending on its gate driver circuit.
Regarding ‘3’, in the standard KSGER circuit this gate driver is a simple transistor (or mosfet) pulled up to +24V thru “1K+2K” resistors combination. This circuit can only provide a 24mA drive to the power MOSFET “gate capacitance” & “gate charge”, which is inadequate & is causing its longer turnoff time. That aspect at least is not attributable to the opamp recovery time, as seen from the graphs provided by floobydust in his post #472 (Dec-21). Even the delays shown by him is not the full picture. To get that, the controller-heater-on/off command output signal (port-out) vs “heater” vs “opamp-out” is required.
A more professional MOSFET gate driver is a two-transistor push-pull drive, with 100Ω series resistor, similar to what “Russel McMohan” suggested in this article below:-
https://electronics.stackexchange.com/questions/31594/mosfet-when-can-we-not-assume-that-the-gate-current-is-0 (https://electronics.stackexchange.com/questions/31594/mosfet-when-can-we-not-assume-that-the-gate-current-is-0)
(See attached circuit.)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1140312;image)
Beware, I am NOT advocating here, the above circuit changes to everybody’s KSGER hardware for David’s custom firmware. It may be too complicated to do as a patchwork in the current KSGER controller board. (Unless otherwise a separate 2”x 2” PCB circuit is designed tobe housed inside the current unit. But as I understand, that is not the primary goal of the current proponents of this forum-post, and the project coordinated by dreamcat. ).
But the above Gate-driver design change is an apt candidate, if anybody is planning for developing an entirely new custom-board, along with David’s custom-firmware for T12, as is indicated by some discussions here earlier. (I think by Gandalf_Sr/floobydust/dreamcat…).
May be the 3.3V discrete regulator with heatsink, and the LC-filtered 3.3V to the opamp & ADC sections of STM-micro, as suggested by David, can be candidates considered into such a PCB.
But changing the gate drive this way has advantages & disadvantages, to be considered by such ventures.
Positives: MOSFET will Turn-Off fast (say ~10us), from the instant of Heater-Off command by controller firmware. So the opamp input as well as output will settle earlier, to handle TC-voltage (21uV/°C).
Negatives: The noise spikes/transients created by the much faster & steeper MOSFET turnoff signals will we bigger & worse, if not snubbed or clamped properly at the mosfet & opamp.
-
I thought that Dreamcat's project was twofold, 1 - document the changes to the KSGER hardware and CFW compatibility with the HW changes and 2 - to also develop an open source HW that is compatible with the CFW but is generally based on the KSGER HW, and overcomes the documented shortcomings of the KSGER HW and allows compatibility with T12, C245 and, at some point C210 handles/tips. In other words, the idea was to have a "next gen Unisolder" that was simplified to focus on compatibility between the three handles/tips I mentioned. Generally, I believed that another factor for point #2 was to retrofit a KSGER station with the open source HW, although there was a short discussion of getting away from the form factor that KSGER (and the copies like Quicko) use for their stations. This was why I pointed out in an earlier post that a company appears to have done something similar, although it was based on an STC mcu instead of the STM32. The controller promises to be compatible with T12, C245 and C210 (with a 12V, 6A power supply, vs 24V power supply needed for the T12 and C245), but the seller has not answered my question whether the controller comes with firmware that allows you to select which handle you are using or if you need to specify it when you order it so that it comes with the correct firmware.
(Note to Dreamcat, if I am wrong on any of what I believed you were doing, please feel free to correct.)
-
But is the opamp recovery time really a problem, from what I see it is fast <300us?
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1140316;image)
From the expanded view of your graph above, the settling time from Heater-Off is nearly 500 to 600 µs. But if you consider 90% of the final settled value, then this time is ~400 µs. But this figure is prone to widely vary from unit to unit, depending on the following phenomena.
- The quality of the opamap device.
- The amount of overstress, the opamps input & output stages are subjected to, based on the presence or absence of voltage-clamping/limiting devices. This includes phase-inversion by some really bad opamps, as pointed out by floobydust.
- Speed of turn-ON & turn-OFF of the power MOSFET depending on its gate driver circuit.
Regarding ‘3’, in the standard KSGER circuit this gate driver is a simple transistor (or mosfet) pulled up to +24V thru “1K+2K” resistors combination. This circuit can only provide a 24mA drive to the power MOSFET “gate capacitance” & “gate charge”, which is inadequate & is causing its longer turnoff time. That aspect at least is not attributable to the opamp recovery time, as seen from the graphs provided by floobydust in his post #472 (Dec-21). Even the delays shown by him is not the full picture. To get that, the controller-heater-on/off command output signal (port-out) vs “heater” vs “opamp-out” is required.
A more professional MOSFET gate driver is a two-transistor push-pull drive, with 100Ω series resistor, similar to what “Russel McMohan” suggested in this article below:-
https://electronics.stackexchange.com/questions/31594/mosfet-when-can-we-not-assume-that-the-gate-current-is-0 (https://electronics.stackexchange.com/questions/31594/mosfet-when-can-we-not-assume-that-the-gate-current-is-0)
(See attached circuit.)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1140312;image)
Beware, I am NOT advocating here, the above circuit changes to everybody’s KSGER hardware for David’s custom firmware. It may be too complicated to do as a patchwork in the current KSGER controller board. (Unless otherwise a separate 2”x 2” PCB circuit is designed tobe housed inside the current unit. But as I understand, that is not the primary goal of the current proponents of this forum-post, and the project coordinated by dreamcat. ).
But the above Gate-driver design change is an apt candidate, if anybody is planning for developing an entirely new custom-board, along with David’s custom-firmware for T12, as is indicated by some discussions here earlier. (I think by Gandalf_Sr/floobydust/dreamcat…).
May be the 3.3V discrete regulator with heatsink, and the LC-filtered 3.3V to the opamp & ADC sections of STM-micro, as suggested by David, can be candidates considered into such a PCB.
But changing the gate drive this way has advantages & disadvantages, to be considered by such ventures.
Positives: MOSFET will Turn-Off fast (say ~10us), from the instant of Heater-Off command by controller firmware. So the opamp input as well as output will settle earlier, to handle TC-voltage (21uV/°C).
Negatives: The noise spikes/transients created by the much faster & steeper MOSFET turnoff signals will we bigger & worse, if not snubbed or clamped properly at the mosfet & opamp.
I don't believe the recovery we are seeing here is the opamp recovering from saturation, moreso it is the thermocouple recovering from the back emf from the heater coil, I will try to capture this on the 'scope. Therefore if anything we need a slower turn off to dampen the transient.
-
Ok here is a couple of screenshots from across the heater, so opamp input, not too great because the scope didn't like the vertical turned up any higher with 25v peak.
1. I think we can see the opamp input is below 0v for around 200us, which would explain the output being at 0v for 200us
2. Here it doesn't look like the input settles for around 10ms
-
I thought that Dreamcat's project was twofold, 1 - document the changes to the KSGER hardware and CFW compatibility with the HW changes and 2 - to also develop an open source HW that is compatible with the CFW but is generally based on the KSGER HW, and overcomes the documented shortcomings of the KSGER HW and allows compatibility with T12, C245 and, at some point C210 handles/tips. In other words, the idea was to have a "next gen Unisolder" that was simplified to focus on compatibility between the three handles/tips I mentioned. Generally, I believed that another factor for point #2 was to retrofit a KSGER station with the open source HW, although there was a short discussion of getting away from the form factor that KSGER (and the copies like Quicko) use for their stations. This was why I pointed out in an earlier post that a company appears to have done something similar, although it was based on an STC mcu instead of the STM32. The controller promises to be compatible with T12, C245 and C210 (with a 12V, 6A power supply, vs 24V power supply needed for the T12 and C245), but the seller has not answered my question whether the controller comes with firmware that allows you to select which handle you are using or if you need to specify it when you order it so that it comes with the correct firmware.
(Note to Dreamcat, if I am wrong on any of what I believed you were doing, please feel free to correct.)
About the new STC board on Aliexpress that should be compatible with T12,T245 and T210 here is what I understood about it, but I could be wrong:
1- you have to choose the first one (2€ more expensive) to have the universal one, the only one that specify T245 and T210 compatibility (I think that the only difference is the software where you can select 245 in some menu)
2- the type of handle you are using is also detected by the ID input pin that is nothing different from the NTC input of Ksger boards. They explain in some photos how to connect different handles stating that wrong writing can burn your tip.
T12 handle / 10K NTC between ID and OUT-
T245 handle / ID shorted to OUT-
T210 handke / ID open
Something similar was proposed some posts ago in this thread.
3- T245 handle requires 24V 8A PSU, otherwise they say the unit will blink on and off by obvious power supply problems damaging the board (maybe in CWF we should avoid this by checking at power on the maximum PWM the unit would provide by probing +24V/11 input so that in won't go too low? At the cost of longer time to get to SET temperature of course).
T210 handle requires 12V 6A PSU
4- New input added to this unit is HR (not in GX12 connector but a pad on the PCB). This input is a pull upped and protected input that should be externally connected to the handle stand so that it would go to OUT- when you put your handle in the stand. This is the way JBC handle goes in standby. Anyway some menu would allow you to still use vibration or mercury switch for T245 and T210 standby or HR for T12 standby.
It seems to me that this new PCB has nothing that can't be done on Ksger unit by software and small PCB mods.
-
Don't bother with power supplies. I tested the T245 tip with KSGER controller on both 24V 4,5A and 6A power supplies. Both working fine.
Just on 4,5A board i replaced the 400V 2x22uF capacitors with 2x47uF for better stability. Maybe it works fine with standard capacitors too, didn't test it.
-
I don't believe the recovery we are seeing here is the opamp recovering from saturation, more so it is the thermocouple recovering from the back emf from the heater coil,….
it is the thermocouple recovering from the "back emf" from the heater coil !!?
The real physical phenomenon involved in the generation of emf (voltage) at a ThermoCouple Junction, is the “SeeBeck effect”.
But in your comment, what does “recovering from back-emf means”? Are you referring to the opposite (corollary) effect of “SeeBeck effect”, termed “Peltier effect”? “Peltier effect” states that when a current is forced thru a Thermocouple junction, heat-energy is transferred from the “Hot-Junction” towards the “Cold Junction”. Mind you, this is not by joules heat transfer.
If by “back-emf” you are referring to the above “Peltier effect”, you may well be correct, since the heat energy transfer from hot to cold junction by the Peltier effect, in effect reduces the thermal gradient, by raising the cold-junction temperature.
If indeed this is true and others here also agree to this, then it is all the more required that David or anybody’s firmware sampling the Thermocouple emf has to do it as late as possible, meaning just before putting ON heater. Or at least well late in the cycle, when the thermal-imbalance of this “effect” dies down, significantly. In effect you are giving a delay for the normal conductive heat transfer to predominate over the Peltier result.
The ”Peltier effect” is well documented and it is within the trio of “ThermoElectric effect” (Seebeck, Peltier, & Johnson effects). May be other’s here can comment whether this Peltier effect is relevant, when T12 heater coil is heated, and this is indeed what is happening.
https://en.wikipedia.org/wiki/Thermoelectric_effect#Peltier_effect (https://en.wikipedia.org/wiki/Thermoelectric_effect#Peltier_effect)
https://en.wikipedia.org/wiki/Thermoelectric_effect#Seebeck_effect (https://en.wikipedia.org/wiki/Thermoelectric_effect#Seebeck_effect)
Location of EMF generated in a ThermoCouple
One associated fact: It is a common misconception that the location of the EMF (voltage) generated by a Thermocouple is only at the Hot-Junction. But in reality, it is not so. As per the SeeBeck effect, this emf generation is spread out all over the entire length, of the two conductors (with dissimilar materials), from Hot-Junction to Cold-Junction. That is, the entire portion of these two conductors which experiences different temperatures (or a thermal gradient) contribute towards generating this ThermoCouple voltage. (Ref: fig-1: Std ThermoCouple Circuit)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1141012;image)
Many members here (including me) had this misconception earlier, since I had no well defined notion about ThermoCouple Seebeck effect, until I refreshed the material and researched the topic in detail. But this misconception, screws up your rationale & logic, when thinking about the physical phenomena happening within the Tip.
In the above fig-1 (Std-Thermocouple), both the Red & Yellow conductors from Hot-Junction (@Tsense °C) to the Cold-Junction (@Tref °C), contribute towards these EMF generation. Finally the differential voltage is fed to the sense-amplifier at the instrumentation block (typically opamp). In fact if there is a further temperature difference between the Cold-Junction (@ Tref °C), & the Instrumentation-amp (@Tmeter °C), (meaning Tref ≠ Tmeter) in the above figure, then both the (+ve & -ve) Copper wires connecting them will also generate an EMF, as well. But since both these wires are of same material “Copper” (NOT dissimilar materials), the emf’s generated in both the +ve & -ve wires will of the same amplitude and, so will cancel out.
In the special case of T12 (& similar) cartridges, one of this conductor (+ve) is the one joining to the Heater-Coil in series. The other conductor (with dissimilar material) is the –ve conductor, the end of which goes directly to the hot-junction located at the tip of the cartridge. For T12 the cold-junction is, the dual ”terminal-contacts” at the rear-end of the cartridge, where they meet the copper conductors from the handle-wiring.
I hope this discussion above puts to rest categorically, the confusion and questions about where the “Cold Junction” is located in the T12 unit (Handle or MCU etc). Refer to fig-2a & 2b below for clarity on the above discussion with regard to T12 & similar cartridges. Fig-2a & 2b attached below.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1141016;image)
ThermoCouple Type of T12: K, N, C ?
There was a question about what is the Thermocouple type (“K”, “N”, or “C”), the T12 cartridge has? But the measured 21µV/°C is not matching neither of these std-types. The reason is that this is not a standard thermocouple. From fig-2a,b it is clear that, the conductor from the Cold-Junction (+ve terminal) to the Hot-Junction, is itself made up of two type of materials. Probably the conductor starting from +ve terminal is “chromel”, which joins to the heater coil, which is made of probably Nichrome. The conductor from the Cold-Junction (–ve terminal) to the Hot-junction may be made of “alumel”. So its thermal-EMF characteristics may be different. This para (about materials) is fully speculation from my part, and not based on any hard facts, but it gives an answer for the possible mismatch from the known Std-Thermocouple types, in terms of EMF/°C characteristics.
I don't believe the recovery we are seeing here is the opamp recovering from saturation, more so it is the thermocouple recovering from the back emf from the heater coil,….
Now coming back to “Bozog’s” comment, the extended time (~400µs) for which a reduced voltage is seen at the opamp output may be the combined effect, of both opamp recovery & the above cooling by Peltier effect. We cannot separate out the effects in the visualized waveform.
Finally one more point, to see the full effects of the mosfet turn-off delay, opamp recovery delay etc, & characterize it more clearly, we may need all three following graphs in the same time-line. (1. Mosfet Turn-off command by controller (port output). 2. Heater Voltage & Opamp-in, 3. Opamp-out ). If not possible two each in two separate graphs.
-
Wow, that is an extensive reply!
I'm thinking just some residual negative voltage in the heater coil offsetting the thermocouple output.
To be honest, I think you're looking far too hard at the hardware side of this - it is not some precision differential instrumentation amplifier, it is 1 up from the cheapest of the cheap Chinese hardware with a few software tricks to make it look like it is working properly.
In my opinion, the hardware is what it is, if it needs a capacitor here or a diode there then fine, but anything more than that needs accounting for in the software.
For example the unisolder, which has much more comprehensive hardware and a proper differential amp, still uses wave shaping to filter out the inductive peaks from series sensor signal.
-
Wow, that is an extensive reply!
Well the first section was only really in reply to your comment.
The next two sections (about ThermoCouple EMF location, & Type of T12 ThermoCouple) were some general information about Thermocouples specific about T12, where I had seen some discussions here in these forums, but no definite answers. I was only trying to clear the air about some intriguing questions.
Regarding looking hard on the hardware or the system as a whole, hey that is what probably the Hakko Japanese have done during their original design. But it is proprietary info.
Chinese have simply copied like they always do.
But the difference here is that they built a simple copyable or customizable & cheaper STM based hardware, on a platform of the copied T12 Tips, which has the potential to perform excellent, which is why it caught on.
But generally the more info we have, on the system, the more it makes the customized software & hardware better. I mean ironing out the residual faults or deficiencies, by whomsoever have the time, patience & necessary skills. I am only trying my own two bits, to help the community here, in the hope that someday a better CFW & better hardware emerge.
-
I agree and I was not having a dig, and like I say sure if we can add a zener to improve performance then fine, but then we are talking additional FETs controlled by the microcontroller which is likely beyond the scope of many hobbyists who want better performance from a custom firmware.
Anyways some more screenies for you, first 3 are opamp output vs stm32 command, second 3 are opamp input vs stm32 command.
These are taken directly from PB7 so of course account for the switching time of FET driving transistor Q1 too.
-
It isn't a switching speed issue. Or It doesn't look like.
30uS turn-off time is not the fastest but is ok for this application.
bhishmar, by back emf, we refer to the inductive spike when the power is suddenly cut off.
The heater and the wires have some inductance, I guess specially the heater since it's it's basically a wire rolled up.
See the waveforms. In a pure resistive load, the voltage would drop cleanly.
But here ir drops below 0... And It takes a while to recover.
Bozog, is that the chinese tip? Seems much faster....
-
This is the hakko tip, you can see in the first shot there is some error even upto around 100ms although it is negligible after 40ish
-
Some more screenies for you,
first 3 are opamp output vs stm32 command,
second 3 are opamp input vs stm32 command.
Excellent Graphs, Bozog. :-+
Timing figures on these graphs summarized into a Table below.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1141872;image)
Can u give some details on your Unit & Controller Board (used for above graphs for record.)
1. Front-Panel Label, Name, or Purchase Website claimed name
2. Controller Board silk screen Ver, & PCB Color.
3. Board Classification by dreamcat (github doc)
4. Sysinfo Menu [HwVer, SwVer] of original firmware.
5. STM Micro Number: “STM32F072C8T6” ? same as DavidAlfa?
6. Firmware Version used for above Test Graphs ?
These are taken directly from PB7 so of course account for the switching time of FET driving transistor Q1 too.
I have a feeling that, the extra timing of 6.9 µs from Port Command to Heater voltage Low going transition, is more due to the PowerMosfet gate charge removal delay. Anyway the figures being much less than the final settling delay, it does not matter much.
Can somebody else verify the timing figures, I intepreted from graphs to above Table?
Especially the 7.2ms & 91 ms figures! They seem to be too high!!
-
Can somebody else verify the timing figures, I intepreted from graphs to above Table?
Especially the 7.2ms & 91 ms figures! They seem to be too high!!
There is some mystery with these high timing figures, for the heater-voltage and opamp-ouputs to settle to saner figures.
I am also not sure whether these high values can be attributed to opamp recovery times.
Typically any opamp if saturated, takes some time to recover. But once the input conditions contributing to the overstress and saturation is removed, it has to come out of it, within some reasonable time (I think typically 10’s of µs, to may be 100’s of µs), depending upon the quality of the opamp. After all, if input stress is removed, it is the time constants within the chip/die with built-in caps, which cannot exceed few 10’s or 100’s of pfs. I cannot imagine these running to several 10’s of milliseconds, as is seen here.
Well I don’t know even the no-name opamps the Chinese put in there will do these trickery! Who knows? |O
-
Today i erased the flash by mistake on my quicko :palm: :-DD , so if you want i am ready to test some code. for the record i own another quicko , the pcb is exactly the same but the mcu, in the working one there is an stm32f072(as davidAlpha build) and the one that i erased is a cheap chinese clone of an stm32f103(also i cant find stm32f072 at a reasonable price). So there are two versions of the quicko t12 stm32 ,both of them report/ed HW:v3.1 and SW:7.1M, also have tried building the 103 version with the 072 .ioc , as the micro is the 103 but pcb layout is as on the quicko 072 but no luck, what should i do? thanks
-
Do you have some pictures with your erased board?
-
1. Front-Panel Label, Name, or Purchase Website claimed name
2. Controller Board silk screen Ver, & PCB Color.
3. Board Classification by dreamcat (github doc)
4. Sysinfo Menu [HwVer, SwVer] of original firmware.
5. STM Micro Number: “STM32F072C8T6” ? same as DavidAlfa?
6. Firmware Version used for above Test Graphs ?
1. Quicko T12
2. Board "OLED-HT-V3.4" colour green
3. Not sure this board is there?
4. No longer have OFW
5. STM32F072CBT6
6. https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3380238/#msg3380238 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3380238/#msg3380238) - running a 200/40ms cycle
-
yes here you go (https://i.imgur.com/nSbWhon.jpeg)
-
@Bozog: A few qns?
6. https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3380238/#msg3380238 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3380238/#msg3380238) - running a 200/40ms cycle
In the above referred post, you reported that (with PWM-peroid= 200ms, ADC delay= 40ms), the Hakko Tips are performing well (i.e. maintaining a stable closed loop temperature), both at 330°C & 150°C set temperatures.
I am assuming the following facts also. Please confirm or contradict. Due to brevity of your earlier posts I was not able to follow certain things, or I was a little slow.
- Hakko Tips were working well with period=200ms, & delay = 40 ms now.
- Upto what reduced delay value was the performance reasonable for Hakko-Tips?
- Your T12-clone Tips, how do they perform, comparatively, w.r.to above questions (adc-delays)?
- Both your Hakko & Clone Tips were performing bad (NOT maintaining temperature) with the original Quicko firmware (OFW)?
Finally it was reported by many in these forums & also the sellers (Quicko & Ksger), that the Chinese T12 controller Units cannot maintain stabilized temperature with brand new tips. The Temperature readings will fluctuate wildly & dance around a lot, when brand new Tips are used in such Units. This problem will go away automatically after a burn-in period, when the Tip is allowed to dwell at a temperature of ≈ 300°C continuously for 5-10 minutes.
This phenomenon was reported my many, mainly for T12-clone Tips. Not clear about Hakko Tips, with Chinese Controller. Hakko Tips with Hakko-controller, nonbody has reported any issues such.
The reason quoted by some experts (including Johnny B Good) is as follows:-
( I have modified and expanded on his words here)
There will be some residual moisture is trapped in the ceramic (mineral insulation) filling of these T12 cartridge tips around the thermocouple sensor, and heater coil, in all brand new Tips. When you pass a DC electrical current thru the cartridge Tip terminals, the potential difference across the heater coil, or any segment of the wires, embedded in these ceramic filling, will cause electrochemical & galvanic reactions since the trapped moisture acts as an electrolyte, and the embedded wires acts as electrodes. This process will create some galvanic potential across these segment of wires which may be very weak, say few microvolts.
But the emf generated at the thermocouple is also a weak signal, a few microvolts. So the galvanic potential created by above electrochemical process will totally mess up the sensor readings, which affects the thermal control, manifesting as dancing & bouncing temperature figures for first 5-10 minutes. Once the generated heat, evaporates and clears the moisture completely, this problem vanishes.
https://www.eevblog.com/forum/reviews/ksger-t12-tip-selection/msg3346456/#msg3346456 (https://www.eevblog.com/forum/reviews/ksger-t12-tip-selection/msg3346456/#msg3346456)
5. My Question to you:
5a. Did you experience such a phenomenon with your T12-clone tips, in the original Quicko firmware?
5b. Did you experience such a phenomenon with your Hakko tips, in the Quicko-T12 Unit with the original Quicko firmware?
5c. Or even after 10-15 minutes of initial heating @ >= 300°C, the Quicko Unit was not able to stably maintain set temperature, with both Clone & Hakko T12 Tips?
Incidentally to complete the earlier discussion, “Johny B Good” postulates a related aspect of the earlier issue in his post, which I also agree completely.
The best way to burn-in the T12-Tips is to power them externally (Stand-alone) with an AC voltage of ≈ 8V from a stepdown transformer. 8V is selected for approx. 10% of power (8v/24v)^2 = 0.11. Better to monitor the Tip temperature with a FG-100 sensor, and adjust AC voltage initially, so that you won’t exceed 300°C, in this open loop powering mode. Typically 7V to 10V ac, may be required to achieve 300°C Tip temperature in this open-loop mode.
Why AC? Initial DC powering has a potential to create galvanic corrosion at the sensor junction (hot-junction) as well as the junction where the +ve terminal meets the heater coil, till the moisture is driven away. This is good bad for the long life of the cartridges ( AC- burn-in improves service life).
-
1. Yes
2. That is it 200 + 40ms
3. The clone tips have an error of similar magnitude, but it is positive (over read) - the hakko error is negative (under read) for example:
Hakko tip sleeping at 150° with 0% pwm, the instant you wake the iron pwm is 100% temperature drops to 130°C - doesn't really effect operation, just doesn't look right.
Clone tip sleeping at 150° with 0% pwm, the instant you wake the iron pwm is 100% temperature jumps to 170°C.
The problem comes close to set point, the hakko tip is actually hotter than the stm knows - so it is easy to overshoot.
Of course the clone tip the opposite, close to set point, iron is colder then we think - less chance of overshoot - we can run more pid gain - possibly it even works better than no error!
4. Can't really remember, I don't have it anymore. But the clone tip worked fine and the hakko tip worked ok but maybe did seem a bit funny.
5. This does not happen with the quicko firmware, I believe this is nothing to do with burn in - it is ksgers pid autotuning.
-
The quicko firmware I had was pretty old. It did not even seem to have proportional pwm control - it seem to either be fixed at for example 1% or 99% and the proportion was achieved by missing cycles, kinda like ac burst fired control.
-
Today i erased the flash by mistake on my quicko :palm: :-DD , so if you want i am ready to test some code. for the record i own another quicko , the pcb is exactly the same but the mcu, in the working one there is an stm32f072(as davidAlpha build) and the one that i erased is a cheap chinese clone of an stm32f103(also i cant find stm32f072 at a reasonable price). So there are two versions of the quicko t12 stm32 ,both of them report/ed HW:v3.1 and SW:7.1M, also have tried building the 103 version with the 072 .ioc , as the micro is the 103 but pcb layout is as on the quicko 072 but no luck, what should i do? thanks
Let me guess Jesus, Did you thought that by removing the read protection bits you could read it? :-DD
Yeah the ide doesn't allow quick mcu change. You have to make a new project selecting the new mcu, assign all the pins, the options, then copy all the source over it, being careful with common files like main and so, that should be done by hand copying the code.
Let me have a look at it.
But I warn you, I don't know if it will work on clones (cks32 is a clone), it's been reported to have problems with spi.
-
i was looking at the programs associated with jlink on terminal and jlinkstm32 does that :-DD, now i know that for sure hahah (dont play with terminals kids!!!), for the moment im trying to find legit stm32f072, but looks like its almost impossible do to covid , so i guess in the mean time ill try to port it and give feedback, the ide is kind like eclipse but at the same time isnt, also i dont know which files are propietary for the mcu model (stm32f072 only, like drivers i guess )and which arent.
-
All changes should be only needed in setup.h, main.c.
Of course it's not as simple as "I want this on the 103". But is much,much easier than changing the whole project.
In this case, the pwm output is timer4. In the 072, this pin is the TIM17 output. For the delay timer, I used TIM3.
So after configuring the timers correctly, I only had to change setup .h and set TIM3, TIM4, PWM_CH2 and set the "normal" CHx channel #define (this pin is CHxN output in the 072 ).
Change the adc device to hadc1... the spi is the same, hspi2...
The ADC has some differences in the rank channel configuration, so in this case I had to change some specific code in the adc functions.
I ordered few 103s almost a month ago, to play with them and start porting the fw to the ksgers. But still in transit... so stopped for now.
When they arrive,I will be able to make a proper code to automatically set the adc depending if using the 103 or 072.
This is a quick test. I can't test anything myself. I doubt the ADC works in the first try! But I hope that at least, the screen and the control work.
Don't connect the soldering tip at first! And if you do, connect it for just few seconds and check if it's heating.
The PID is called at the end of the ADC conversion, so in the case of the ADC not working, the PWM should stay at the initial off state.
But don't trust anyone here. Test code can do anything! Turn off your wifi and hide your credit card too! :-DD
-
Hi guys,
first of all let me wish you a happy new year. It is a very nice project which you've setup here. Thanks a lot for all the efforts you've spent so far!
I'm following the development with great interest and I'm reading the updates regularly. Now I would like to order a soldering station from Aliexpress as well but I'm a bit lost on all the available models and which one is supported or not. There are different MCUs available which differ in available memory...etc.
Which one would you recommend to order (also in terms of future development)?
Could it make sense to design a copy of the Chinese boards with some improved circuity for better performance or new features?
Cheers
Tommi
-
Working:
-Screen (Shows only "the soldering station")
-Piezo (beeps while tip is not conected)
Partially:
-Rotary encoder(pressing button while booting registers reset)
-Reset Menu (Screen glitches when "release button now" is shown )
Not working:
-Heat(tip does not heat up)
-Menu(not shown)
-
What's happenning? Freezes in the boot screen?
It's pretty much impossible to guess what's happening without being able to debug it.
Might be some code not correctly initializing a peripheral, or who knows...
Edit: I made a small mistake in the linker script that might cause memory overlap, so when the settings were stored, it actually could be erasing part of the program.
That migh explain the weird behavior. I replaced the file with the new one, try again...
-
Hi guys,
first of all let me wish you a happy new year. It is a very nice project which you've setup here. Thanks a lot for all the efforts you've spent so far!
I'm following the development with great interest and I'm reading the updates regularly. Now I would like to order a soldering station from Aliexpress as well but I'm a bit lost on all the available models and which one is supported or not. There are different MCUs available which differ in available memory...etc.
Which one would you recommend to order (also in terms of future development)?
Could it make sense to design a copy of the Chinese boards with some improved circuity for better performance or new features?
Cheers
Tommi
It's hard to tell. The ksgers are done in a very odd way, screen and memory are not connected to the spi peripherals and all the communication must be done in software, so forget the speed for automated transfers using dma.
Quicko is what I have, and can talk about. Stock firmware is absolute crap, however the hardware is pretty decent and everything is correctly connected.
About the mcu power... there are few differences between the different stm32, however any is capable enough. Also easily replaceable if needed. Anyway, they change them on the fly to what they get cheaper. Today's and next week's models might have different stm32...
Designing a custom hw would be nice, however there're already very nice projects, for example the Unisolder...
-
trying to see if pc gets stuck at a certain address but halt isnt halting the cpu(edit: didnt saw the update , uploading it to mcu)
Ok get the same behaviour, boots , shows "The soldering station" on screen all the time , if no tip is found beeps each second until its connectd.
if turned on while pressing encoder , shows "hold button to restore defaults" if keep holding, shows "release button now" but only updates the pixels used by the second message so the screen is a bit messy and then goes back to show "The soldering station". if tip is removed starts beeping again so it seems code is running.
Seems to halt always at PC = 08002830 , CycleCnt is the only one that changes.
PC = 08002830, CycleCnt = 06901737
R0 = 20001208, R1 = 20000E9E, R2 = 00000000, R3 = 08002831
R4 = 20001208, R5 = 200012B4, R6 = 00000003, R7 = 00000004
R8 = 0000027F, R9 = 00000000, R10= 00000000, R11= 00000000
R12= 20004E7B
SP(R13)= 20004F70, MSP= 20004F70, PSP= 00000000, R14(LR) = 080078D5
XPSR = 41000000: APSR = nZcvq, EPSR = 01000000, IPSR = 000 (NoException)
CFBP = 00000000, CONTROL = 00, FAULTMASK = 00, BASEPRI = 00, PRIMASK = 00
FPU regs: FPU not enabled / not implemented on connected CPU.
-
Hmm... until I receive the 103s I'm out. Hopefully they will arrive soon.
-
its ok , no worries youve tryed and thats more than i can ask, ill wait until Correos delivers :=\
-
I can do barely nothing without debugging the hardware. The problem can be caused by a lot of sources.
Specially in the first build for a different hw.
Btw if someone has some graphics design skills, a new logo would be great...
-
I forgot I had a Bluepill lying around. Replaced the 072 with the 103 from the bluepill.
There was a nice bug! Somewhere in the widget processing functions, it could happen a situation where a null pointer was used.
Interestingly, when using the null (0) address as the widget typedef, the result was a call to the NMI handler.
In the 072 the NMI handler is non-blocking, just enters and exits, so I never noticed the problem, but in the 103 it's implemented using a a while(1) loop, so it gets trapped there forever.
Everything seems to be working. PWM, adc, encoder, screen...
There's still something weird going on, I can use compiler optimization for all except one specific functions, doing so causes a hard fault.
Will have a look tomorrow...
Again, I replaced the file in the previous post, try and report.
-
I forgot I had a Bluepill lying around. Replaced the 072 with the 103 from the bluepill.
There was a nice bug! Somewhere in the widget processing functions, it could happen a situation where a null pointer was used.
Interestingly, when using the null (0) address as the widget typedef, the result was a call to the NMI handler.
In the 072 the NMI handler is non-blocking, just enters and exits, so I never noticed the problem, but in the 103 it's implemented using a a while(1) loop, so it gets trapped there forever.
Everything seems to be working. PWM, adc, encoder, screen...
There's still something weird going on, I can use compiler optimization for all except one specific functions, doing so causes a hard fault.
Will have a look tomorrow...
Again, I replaced the file in the previous post, try and report.
David I just tested your latest bin on github, it works :-+
Temp. readout is still a bit jumpy at 400°C but pretty stable at 340°C
Works fine tho, been using it to do some actual soldering today :clap:
https://www.youtube.com/watch?v=JQViRxNNJgs (https://www.youtube.com/watch?v=JQViRxNNJgs)
https://www.youtube.com/watch?v=WcYgdDkSC6g (https://www.youtube.com/watch?v=WcYgdDkSC6g)
-
Nice! Well I wouldn't call jumpy +-3°C! Most stations just filter it and ignore small changes, so they will always show 360 as long the real temp is, for example, in a 15°C margin from the nominal temp.
I prefer to see the real temp!
The new mosfets arrived yesterday. Yay! I can play again!
My T245 shows amazing stability with 3mS delay. Below that it gets random +20ºC jumps.
I repeat again: Some tip profiles are waaay wrong.
Specially the DFLT. 3Kp 25Ki 0Kd! That makes the tip go crazy. When I set 45/5/20 the story changes a lot.(Edit: Much better with 35/10/15)
I'm currently redoing the method for targeting different boards.
Also merging I2C support.
I think is way easier now. Will update soon!
Edit:
This is the simplest approach I foun
We can't just use defines for everything, as the non-code related stuff can't be changed easily. And I hate when I see a new project and have to mess with the code to make it work!
It's not nice that you have to spend an hour to build something! So I decided to make it the simplest possible way. Copy,paste, few clicks and make.
The project config files are diferent for each MCU, otherwise you will have to mess with all the include paths, linker script and preprocessor defines. :blah:
As those files aren't code related, they will rarely need to be updated, so no worries about the manteinance.
In short, these are the files that each hardware template needs:
- CubeMX .ioc file: Hardware initialization. For configuring peripherals, GPIO, etc.
- .cproject, .project: Project configuration files.
- board.h: Specific board hardware configuration (this is the important file).
- stm32fxxx_it.c. IRQ interrupts routines, this file is generic, but is different for each family, and can't be mixed without causing errors. So we have 2 versions of the file, for F0(stm32f0xx_it.c) and F1(stm32f1xx_it.c) families.
- startup_stm32xxxxxxx.s. This is the startup file very specific for each MCU. Automatically generated when creating the project but won't be regenerated if deleted. So we must save it. Can't be mixed with others.
So, for same MCU and different board, only CubeMX (.ioc) and board.h files need to be changed.
And for new, different MCU, a new empty project has to be done setting the mcu parameters.
Then, copy the startup file, .cproject and .project files. And the board profile would be pertty much done.
So, now it's the time to try these KSGERS! We have a pretty stable fw with most issues solved! Any volunteers?
-
https://www.youtube.com/watch?v=8oeGVSSxudk (https://www.youtube.com/watch?v=8oeGVSSxudk)
-
I did not saw the update, after some testing, some of the tips where at 300C when set to 200C , calibration sort of works still a bit of overshoot +20C(on external temp meter) o so, also takes a lot of time to go down in temp , up speed is very good.With my ILS tip gets sometimes a bit confused and temp on lcd suddenly jumps to 300 then goes to 180 when set to 200, with other tips works ok (all 5 of them are clones, not real hakko, the good ones are expected to arrive soon, will report then). The beeping all time while no tip is detected is a bit much in my opinion. very good job :clap:
edit: also when standby mode ,eventhough tip is off, says 64C dont know if its a limitation in the tip, mb we could change it to a big STB or something.
-
Hmm if I tell you the truth, I've never touched the buzzer. I removed it from mine the first day I got it.
Don't use the default DFLT profile. Try B .
The DFLT is a total mess, makes any tip go crazy. I don't really understand why it's there.
Also the chinese tips are known to have such issues, they usually settle after some "burning" time.
Yes, the sensor can't go lower than ~70°C. The thermocouple type is not usable below 100°C or so.
The temp can't go down by itself if the tip is hot and the heat has no go away. That is thermal mass "inertia".
Instead buying genuine hakko, I'd but the Jbc handle ($18 in AliExpress) and a genuine tip ($30, expensive as f** but worths it)
-
about jbc handle will do , i supose i will have to change the handle connector where may i find the schematics? , with b profile its dead on , 270 on set temp, and 270 on thermometer.
-
I'd but the Jbc handle ($18 in AliExpress)
That includes shipping? Where did you see it at this price?
They are all above 26$. Not to mention the C210 handle, with price starting from 35$.
-
16 euro / $19 with free shipping.
https://a.aliexpress.com/_BOuVGY
Don't buy the tips! They're trash!
Also you might need to fix the contacts, if they come too straight the cartridge doesn't insert smoothly.
So, I need a volunteer with a ksger board to start porting it! I need to know the exact pcb model.
The rest of ksgers are similar and shouldn't cause much hassle.
-
I tried on both these boards with f103 MCU. No graphics, no sound.
v3.1:
(https://b9.eu.icdn.ru/c/cosmin34/2/69165052zMc.jpg?20210104162238)
Ve2.1S r2:
(https://b9.eu.icdn.ru/c/cosmin34/0/69206010UvW.jpg?20210104162410)
-
No, the fw is not ready. I asked to know who could try the tests builds.
I have yet to adapt everything.
-
I have the latest Russian Ksger (I bought it on November 11, 2020).
But I only used the firmware: 3.1Snew1.hex
I can check your firmware if you send a .hex file
-
Wait, soon I will start posting test builds. I'm working with software I2C routines so the Ksger boards work without modifying anything. ;)
-
I have tested leaving it unattended for some period of time, and it hasn't burned my shed down yet 👍
-
Im no designer but i have made my own splash mb its of your taste , probably not :-DD
const uint8_t splashBMP[] = {
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x7f, 0x3f, 0x3f, 0x1f, 0x8f, 0x8f, 0x87, 0x07,
0x07, 0x03, 0xff, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x03, 0x07, 0x07, 0x07, 0x0f, 0x0f,
0x1f, 0x3f, 0x3f, 0x7f, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xbf, 0xbf, 0xbb, 0xab, 0xab, 0xab, 0x01, 0x70, 0x51, 0x50, 0x51, 0xd0, 0x01,
0x10, 0x11, 0xf0, 0x11, 0x10, 0x01, 0xf0, 0x31, 0x40, 0x31, 0xf0, 0x01, 0xab, 0xab, 0xbb, 0xbb,
0xff, 0xff, 0xff, 0x7f, 0x1f, 0x07, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x03, 0x83, 0xc1,
0xe1, 0xe1, 0xf1, 0xf1, 0xf1, 0xf1, 0xf1, 0xf1, 0xf1, 0xf1, 0xe3, 0xe6, 0xcc, 0x88, 0x08, 0x08,
0x08, 0x88, 0x88, 0x88, 0x08, 0x09, 0x0f, 0x1f, 0x7f, 0xff, 0xff, 0xff, 0xf3, 0xf3, 0x03, 0x03,
0xf3, 0xf3, 0xff, 0xff, 0x03, 0x03, 0x9f, 0x9f, 0x03, 0x03, 0xff, 0xff, 0x03, 0x03, 0x93, 0x93,
0x93, 0xf3, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xfb, 0xfb, 0xfb, 0xfb, 0xeb, 0xeb, 0xaa, 0xaa, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x88,
0xa8, 0xa8, 0x51, 0x00, 0xc8, 0xa8, 0x91, 0x00, 0x00, 0x00, 0x01, 0x00, 0xaa, 0xab, 0xaf, 0xaf,
0xff, 0xff, 0x07, 0x02, 0x02, 0x02, 0x02, 0x02, 0xfe, 0x00, 0x00, 0x00, 0xf8, 0xfe, 0xff, 0xff,
0xff, 0xff, 0xff, 0xdf, 0x0f, 0x07, 0x07, 0x0f, 0xdf, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfe, 0xf8,
0x00, 0x03, 0xff, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, 0xff, 0xff, 0x1f, 0x1f, 0x9c, 0x9c,
0x9f, 0x9f, 0xff, 0xff, 0x1c, 0x1c, 0x9f, 0x9f, 0x1c, 0x1c, 0xff, 0xff, 0x1c, 0x1c, 0xfc, 0xfc,
0xfc, 0xfc, 0xff, 0xff, 0x1f, 0x1f, 0x1f, 0xdf, 0xdf, 0x1f, 0xff, 0xff, 0x1f, 0x1f, 0x9f, 0x9f,
0x9f, 0x9f, 0xff, 0xff, 0x1f, 0x1f, 0x9f, 0x9f, 0x9f, 0x1f, 0xff, 0xff, 0x9f, 0x9f, 0x1f, 0x1f,
0x9f, 0x9f, 0xff, 0xff, 0x1f, 0x1e, 0x3e, 0x7e, 0x1e, 0x1c, 0xf0, 0xfc, 0x18, 0x1c, 0x90, 0x9c,
0x98, 0x9c, 0xf0, 0xfc, 0xe0, 0xfc, 0x80, 0xfc, 0xe0, 0xfc, 0xf8, 0xfc, 0xfe, 0xfe, 0xfe, 0xff,
0xff, 0xff, 0xff, 0xf0, 0x80, 0x00, 0x00, 0x70, 0x7f, 0x70, 0x00, 0x00, 0x00, 0x03, 0x0f, 0x9f,
0xff, 0xff, 0xff, 0xff, 0xff, 0x03, 0x03, 0xff, 0xff, 0xff, 0xff, 0xff, 0x9f, 0x1f, 0x13, 0x10,
0x10, 0x10, 0x1f, 0x00, 0x00, 0x07, 0x07, 0x87, 0xf2, 0xff, 0xff, 0xff, 0xe4, 0xe4, 0xe4, 0xe4,
0xe0, 0xe0, 0xff, 0xff, 0xe0, 0xe0, 0xe7, 0xe7, 0xe0, 0xe0, 0xff, 0xff, 0xe0, 0xe0, 0xe7, 0xe7,
0xe7, 0xe7, 0xff, 0xff, 0xe0, 0xe0, 0xe0, 0xef, 0xef, 0xe0, 0xff, 0xff, 0xe0, 0xe0, 0xe4, 0xe4,
0xe4, 0xe7, 0xff, 0xff, 0xe0, 0xe0, 0xfe, 0xf8, 0xe2, 0xe6, 0xff, 0xff, 0xe7, 0xe7, 0xe0, 0xe0,
0xe7, 0xe7, 0xff, 0xff, 0xe0, 0xe0, 0xfe, 0xfc, 0xe0, 0xe0, 0xff, 0xff, 0xe0, 0xe0, 0xe7, 0xe4,
0xe0, 0xe0, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfc, 0xf8, 0xf0, 0xe0, 0xc0, 0xc0, 0xf0, 0xf8, 0xfe, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfe, 0xf8, 0xf0,
0xc0, 0xc0, 0xe0, 0xf0, 0xf8, 0xfc, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x20, 0x20, 0x24, 0x24,
0x04, 0x04, 0xff, 0xff, 0xfc, 0xfc, 0x00, 0x00, 0xfc, 0xfc, 0xff, 0xff, 0x00, 0x00, 0xe4, 0xe4,
0x00, 0x00, 0xff, 0xff, 0xfc, 0xfc, 0x00, 0x00, 0xfc, 0xfc, 0xff, 0xff, 0x3c, 0x3c, 0x00, 0x00,
0x3c, 0x3c, 0xff, 0xff, 0x00, 0x00, 0x3c, 0x3c, 0x00, 0x00, 0xff, 0xff, 0x00, 0x00, 0xf9, 0xf3,
0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfe, 0x52, 0x6d, 0xdf, 0xab, 0x7f, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xe0, 0xc0, 0x8f, 0x1f, 0x3f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0xff,
0x3f, 0x3f, 0x3f, 0x3f, 0xff, 0x3f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f,
0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f,
0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0x1f, 0xff, 0x1f, 0x1f, 0x0f, 0xff, 0x7f, 0x7f,
0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x7f, 0x79, 0x76, 0x55, 0x7e, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xff,
0xfc, 0xfc, 0xfc, 0xfc, 0xff, 0xfc, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8,
0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8,
0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xf8, 0xff, 0xf8, 0xf8, 0xf0, 0xff, 0xfe, 0xfe,
0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xfe, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff
};
-
I have the latest Russian Ksger (I bought it on November 11, 2020).
But I only used the firmware: 3.1Snew1.hex
On that board you could also use 2.0 firmware.
-
Jesusvallejo, yes, I'm aware of that bug. There's a function that can't be optimized, causes hard fault but only on the 103!
For now it's "fixed" by disabling optimizations in that specific function. I'm focused on finishing the code and start the first builds for the ksgers.
The problem on that function is probably a small bug that causes memory ilegal memory access by addressing a wrong pointer or any uncontrolled condition. That will be fixed soon.
The new code is almost ready, all the code for i2c and spi is ready, it currently supports all 4 modes (software spi, software i2c, hw dma spi and hw dma i2c), and is plain easy to change the modes.
-
I have tested leaving it unattended for some period of time, and it hasn't burned my shed down yet 👍
I'm so sorry. I promise I'll fix that on next build. It's not fair that people have cold homes when I could be helping...
Im no designer but i have made my own splash mb its of your taste , probably not :-DD
Post a pic! Nah, don't do it, I like surprises!
Edit: Wtf. I noticed that all the schematics use 48-pin. Where are the other schematics?
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled
Call me blind, or crazy, but I've checked 20 pages on the forum thread, all the github folders, and I couldn't find the KSGER 64-pin schematics!
We need a bit of order here. Move all the valuable info to the 1st post. Schematics, links...
-
At least mine is 64... ;D
-
Don't worry! Updating the Github. It now has that schematic, still adding the photos.
-
Los reyes majos have left this for you xd
(https://i.imgur.com/F4yZ3Ww.jpg)
-
Hahah, its nice! I like it :-DD
Oookay all the bugs (hopefully) solved. It builds right away on both stm32f072 and stm32f103.
Added bins in each board folder.
And soldered back the buzzer. Omg, that was incredibly annoying.
Changed all the buzzer timings. Now they're much more subtle.
The short beep is now a 10mS "tick".
The long beep is now a 50mS beep. They hear completely different although the timings are very short.
The alarm makes a "tick" every 2 seconds.
Only a system failure, like a hard fault or other internal error will make a long, annoying, 2 second beep.
Now let's go with the ksger.
Jesus, Please try the bins and also building your own!
Remember that you can't mix the files. If you add the files for ex. 072, you can't then paste the 103 over it, it will make conflict.
If you want to retarget the project, you have to delete:
- /Core/Inc/*stm32*
- /Core/Src/*stm32*
- /Core/Startup
And then copy the board profile files overwriting any files.
Different stm32xx HAL drivers can co-exist without problem as they don't overlap.
@Dreamcat4, for changes like this, how can I set the git to allow 3rd party contributions?
Also, I'd apreciate some help in the documentation side, as I already saw you are good at it.
I'd like to have all the files like boards, schmetatics, well organized.
-
Compiled by me version works flawless, the provided Quicko_STM32F103C8.bin does not work , screen turns on but only random pixels. diff shows the one compiled by me its bigger and has nothing to do except for 2 lines which are zeros , mb it got corrupted in upload (edit: have tryed with different downloads already)
-
Compiled by me version works flawless, the provided Quicko_STM32F103C8.bin does not work , screen turns on but only random pixels. diff shows the one compiled by me its bigger and has nothing to do except for 2 lines which are zeros , mb it got corrupted in upload (edit: have tryed with different downloads already)
Did you use the latest code? Updated few hours ago.
Well, the important is that it builds correctly. I'll upload the BIN again.
v3.1:
(https://b9.eu.icdn.ru/c/cosmin34/2/69165052zMc.jpg?20210104162238)
Am I correct thinking the OLED uses 3-Wire SPI? SCK, SDA, DC, RESET and CS not present? (internally always low).
Because I2C mode can also use DC (LSB Address) and RESET.
Ve2.1S r2:
(https://b9.eu.icdn.ru/c/cosmin34/0/69206010UvW.jpg?20210104162410)
This is clearly using I2C.
-
v3.1:
(https://b9.eu.icdn.ru/c/cosmin34/2/69165052zMc.jpg?20210104162238)
Am I correct thinking the OLED uses 3-Wire SPI? SCK, SDA, DC, RESET and CS not present? (internally always low).
Because I2C mode can also use DC (LSB Address) and RESET.
Yes.
(https://b9.icdn.ru/c/cosmin34/4/69398994HmW.jpg)
Ve2.1S r2:
(https://b9.eu.icdn.ru/c/cosmin34/0/69206010UvW.jpg?20210104162410)
This is clearly using I2C.
Yes.
(https://b9.icdn.ru/c/cosmin34/1/69399011bCt.jpg)
-
Did you use the latest code? Updated few hours ago.
Well, the important is that it builds correctly. I'll upload the BIN again.
I flashed the one on /Boards/stmxxxx/Quicoxxxx.bin and i did the clone not long ago(1h or so).tryed cloning and downloading zip , same result , diff says its the same bin, no change from .zip and git clone.
-
I flashed the one on /Boards/stmxxxx/Quicoxxxx.bin and i did the clone not long ago(1h or so).tryed cloning and downloading zip , same result , diff says its the same bin, no change from .zip and git clone.
Ooops yes, my local linker script was messed up. Yesterday I touched some options and I had totally forgotten.
Github had the scripts untouched, that explains why it worked well for you.
I added the last code changes. Built and flashed ok in STM32F103 and 32F072. I flashed the bins directly. Try it if you can!
Cosmin1, the first build for ksger 3.1 STM32F103RB is available! I'm assuming it uses 3-Wire SPI. Fortunately that board is well routed and can use the hw SPI.
Go to github, boards, and download the bin file.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv2.1s%20r3%5D%20%5Bv3.1%5D/STM32F103RB
-
OK have finished uploading cosmin1's missing photos to the git now. Alongside the schematic.Again there is no editable .sch, because well: nobody listens to me. But this is supposed to be an open source project. So letting others edit your .sch is actually something that matters. To get people to map their circuits and share that.
Heres what you posted for my cosmin1, sorry it's rather late. Images file size had to be reduced from 45mb. Because: git.
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0
@Dreamcat4, for changes like this, how can I set the git to allow 3rd party contributions?
Have left an extensive guidelines about that aspect, in a comment on your PR #1.
In short: The right way takes a certain amount time, work, effort to setup. You create a new organization on github. Then you add collaborators to it. And give them with whatever permissions you wish. To work together with you on the shared organisation repo...
Very important bit: This then has the added benefit meaning your own repo can have unstable code in it. Then when you are ready push / publish to the org repo.
However others can still see what you are doing, for the unstable work.
Discussion of that here:
https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/1#issuecomment-735274759
Also, I'd apreciate some help in the documentation side, as I already saw you are good at it.
I'd like to have all the files like boards, schemtatics, well organized.
OK so the big thing to realize here is that:
For the way that git works, we absolutely cannot put all that stuff into the same git repo as the code. Because the size of all the PDF files and images. And other documentation assets. Its hundreds of megabytes.
Git is accumulative, so nothing gets deleted in there. Already tried some work arounds to avoid that (git LFS, etc). Unfortunately it just doesn't work on github. Not without paying money for storage etc. And this is an open source project. So that is not possible like that.
Anyhow, so this is why the seperate docs repo exists to begin with. I'm very happy to move that repo into a new github organisation, should you decide to create one. For where to put your source code as 'published' and 'stable'. Then multiple people can work on it easily. And improve / upload. Add further assets. Re-organize it. And the docs is just another repo allongside the source code repo.
In fact can have multiple docs repos. If the existing docs repo is too big. For something not the whole kitchen sink. Then just create a brand new docs repo. That is more slim. And easier to follow. While my docs repo is more like a collection of reference materials. To keep them safe.
I'm not going to be responsible for that myself. For time reasons. I have other priorities. Instead everybody should contribute to documenting stuff. It's a community effort. I do my part, so others should too. Which also includes everybody these forums, very helpful!
Just be sure not to stuff the docs in the code repo. It will hurt the repo size too much. To mix them together.
BTW sorry I have not received any new notifications of activity here. But it turns out the forum stops notifying me of stuff, unless I come back to visit the forum again.
So the main thing I missed was you renamed your branch to 'master'. Great. OK so now that you have one clear branch. Then I have now updated the landing page on the docs repo. To point to your master branch. Hopefully it helps for others to find.
Actually theres pages in that docs repo it needs updating. Like where i put: stuff not tested, etc. Well it's getting tested right now! Just even doing that i don't have the time for. But at least the README.md (landing page) is updated.
https://github.com/dreamcat4/t12-t245-controllers-docs
And also the README page for the controllers themselves
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled
And that's all the time I have for this project today! (And tomorrow, next week). Until I can try cracking the read protection again. To try to dump the OFW again. With those new set of security hacks.
-
No worries! If it wasn't for the lockdown and being on sick leave, I woulnd't have 1/3 of the time, and by no means I could have started the project.
More than a year has passed now, the surgery was a total disaster, the plan was toput the problem to an end with a second surgery after 3 months, but thanks to the covid-19, it was postponed until the situation gets better, they don't want to take the risk.
So, what can I do, else that losing my precious time with crappy chinese stations? :-DD
Of course I agree, you can't say that it's done by the community if only one person built it all. I can understand that programming is not for everyone.
I took me weeks to fully undertand everything. I had never programmed with stm32 so you can imagine the initial beating. Also my C skills were pretty rusted.
So now I can modify the code in a breeze, and if there's a bug, I usually catch it quickly. It's ok. But I'd like this to be more open in general.
I guess once it works in ksgers it will catch more interest.
-
Heres what you posted for my cosmin1, sorry it's rather late. Images file size had to be reduced from 45mb. Because: git.
Excellent job!
Maybe we should put this version too.
It's 95% same as v3.0 r0 (schematic too), but with STM32F103 MCU and only working with fw 3.1S.
I have more pictures if you need to upload them on git.
(https://b9.eu.icdn.ru/c/cosmin34/2/69165052zMc.jpg?20210105203903)
Cosmin1, the first build for ksger 3.1 STM32F103RB is available! I'm assuming it uses 3-Wire SPI. Fortunately that board is well routed and can use the hw SPI.
Go to github, boards, and download the bin file.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv2.1s%20r3%5D%20%5Bv3.1%5D/STM32F103RB
Doesn't work.
Bad news is, now it doesn't work neither with old firmware... :(
-
I have more pictures if you need to upload them on git.
One is enough! Uploaded it. But that's all from me (for the time being). Please think to discuss about creating an 'Organization' account on Github. Thanks & Good day.
-
How it is possible that a firmware destroyed the MCU?
I tested all available fw but the controller does not start anymore. :palm:
-
Impossible! Open ST-Link utility, force reset low by shorting it to ground and click erase, release after a second.
Might take few tries. Or use nRST.
And, I discovered that the 101 is rated for 36MHz max.
Might be silicon that can't achieve 48/72MHz, so they sell them that way.
That's probably why the 101 fw works on 103 but not always the other way around.
-
Heres what you posted for my cosmin1, sorry it's rather late. Images file size had to be reduced from 45mb. Because: git.
Excellent job!
Maybe we should put this version too.
It's 95% same as v3.0 r0 (schematic too), but with STM32F103 MCU and only working with fw 3.1S.
I have more pictures if you need to upload them on git.
(https://b9.eu.icdn.ru/c/cosmin34/2/69165052zMc.jpg?20210105203903)
Cosmin1, the first build for ksger 3.1 STM32F103RB is available! I'm assuming it uses 3-Wire SPI. Fortunately that board is well routed and can use the hw SPI.
Go to github, boards, and download the bin file.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv2.1s%20r3%5D%20%5Bv3.1%5D/STM32F103RB
Doesn't work.
Bad news is, now it doesn't work neither with old firmware... :(
both compiled and uploded are correct and working nicely :-+
-
Impossible! Open ST-Link utility, force reset low by shorting it to ground and click erase, release after a second.
Might take few tries. Or use nRST.
Ok. Solved. Now it's working again after erasing.
Do you have an updated fw, so i could try out again on this F103 board?
This is the test board:
(https://b9.eu.icdn.ru/c/cosmin34/0/69206010UvW.jpg?20210104162410)
-
The fw was for the 3.0! This one:
(https://b9.eu.icdn.ru/c/cosmin34/2/69165052zMc.jpg?20210105203903)
And this schematic (But using a STM32F103RB instead of a 101)
At least mine is 64... ;D
Yes, I messed up the names at first (put 2.1 and 3.0 in the same folder).
Try the fw in the black pcb! All your board uses stm32F103?
Because I'm already getting mad of so many ksger versions, then the same versions with different mcus :scared:
(https://b9.eu.icdn.ru/c/cosmin34/0/69206010UvW.jpg?20210104162410)
Where's the schematic for this one?
This is not correct, uses a 48-pin STM32.
It might be similar to the "3.1 r0", but the display is I2C instead SPI, it can't magically work without knowing the exact mcu pins where the display is connected
Nevermind, there's no schematic for that one. I remembered I had done this, so there's no problem
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1145638)
-
I tried on 3.0 with F103 black pcb too. Does not start.
I have also a black pcb with F101.
The floobydust schematic for blue pcb Ve2.12s does not apply to my Ve2.12s. My pcb is with 64 pin, schematic is for 48 pin.
I will try to draw the schematic for this one too.
Until then... waiting the right fw for black pcb. If it works on F101 black pcb, it will surely work on F103 black too (same pinout). But the reverse, not.
-
There were some 103C8 / 103RB mixed labels inside the project file. Not sure if that was the problem.
Re-checked everything. Added KSGER v2.1s.
Added 101RB to all KSGER builds (Apart of 103RB).
Have a look. Ensure your board and MCU are correct.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER
-
There is a strangeness with PB2 connected to GND on many versions of boards, that could be for the suicide feature...
I was putting together this I/O port assignment for the common boards. Almost the same for them.
Some boards use SPI, others I2C for the OLED. One board has the encoder pins reversed.
That pic looks wrong, OLED SDA going to pin 33 and MCU 15? OLED SCL going to pin 34 and MCU 14?
-
Have a look. Ensure your board and MCU are correct.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER
Tested black pcb v3.0 with f103 and blue pcb v2.1s with f103 and right fw. None work.
OLED SDA going to pin 33 and MCU 15? OLED SCL going to pin 34 and MCU 14?
OLED SDA going to pin 33 and OLED SCL going to pin 34 on MCU.
-
No, that picture is a modification to connect the i2c lines to the i2c peripheral: That is not what I'm using on the builds.
Cosmin, I'm not a fortune teller... There are so many things that could be failing, without debugging is almost impossible to figure out.
If the schtematics are correct it should work... The only thing that occurs to me is if you are willing to let me debug it remotely, ex. using Teamviewer
-
It's fine with me. Can we do it now?
-
OK, I sent you a PM
-
so today i was testing a bit , and when load is big, a 100% is provided to the tip without limit and the tip got glowing red xd , tip is still working, i think the tip is now well "burned in". :-DD
So to explain little furder , temp was set to 315 , big metal sheet, contact with leaded tin, power sets to 100% and temp on oled starts increasing , even if tip is not in contact(so no load) it keeps power at a 100% to the point it got glowing red. lowering temp sets power to 0%. So i think maybe we could add a limit, that can be bypassed or something so people dont kill their tips.
-
big metal sheet, contact with leaded tin, power sets to 100% and temp on oled starts increasing , even if tip is not in contact(so no load) it keeps power at a 100% to the point it got glowing red. lowering temp sets power to 0%. So i think maybe we could add a limit, that can be bypassed or something so people dont kill their tips.
Hey there. I am just wondering if the big metal sheet was grounded, or connected to a path to ground? Because I have observed this phenomenon with my own thermocouple thermometer. The temperature does not rise hardly anything. And it messes up the whole thermocouple measurement. When the other thing you are touching with the thermocoouple is grounded. Or otherwise connected. Even if it is switched off at the time.
However it does not explain why the power kept going afterwards. Unless it got confused / stuck somewhow. And then continued to behave that way.
-
big metal sheet, contact with leaded tin, power sets to 100% and temp on oled starts increasing , even if tip is not in contact(so no load) it keeps power at a 100% to the point it got glowing red. lowering temp sets power to 0%. So i think maybe we could add a limit, that can be bypassed or something so people dont kill their tips.
Hey there. I am just wondering if the big metal sheet was grounded, or connected to a path to ground? Because I have observed this phenomenon with my own thermocouple thermometer. The temperature does not rise hardly anything. And it messes up the whole thermocouple measurement. When the other thing you are touching with the thermocoouple is grounded. Or otherwise connected. Even if it is switched off at the time.
However it does not explain why the power kept going afterwards. Unless it got confused / stuck somewhow. And then continued to behave that way.
No it was not connected to anything , i think i could replicate it with a big coin, i will try tomorrow and report back. edit: i have tryed again and achived the same glowing red tip.
even if the tip is no longer touching anything it keeps power at 100% achiving 450 - 500c (as per shown on oled)eventhough set to 315.
video: https://drive.google.com/file/d/1e66EGaBqzI_wBcZZfJvbUrg9o48N7iSw/view?usp=sharing
now station keeps going up no matter what , ive tryed other tips im going to try to reflash it.
BIG BUG!!!! with the lastest version in davidalfa repo when temp is set to 315 or above temp will go up without limit (will go glowing red). i have tryed 5 different tips, firmware compiled by myself , by david and happens all times if temp is set to 315 or above , the only way to solve it is to set temp below 315 as bug survived a reflash.
info about tested equipment:
bug: 315c and above power gets stuck at 100%
model: quicko t12 stm32
mcu: cks32f103c8(stm32f103c8 chinese knockoff)
firmware: quicko stm32f103c8
fork: deividAlfa/stm32_soldering_iron_controller
commit: a108de3
iron profile: B
handle: t12-9501(blue standard one)
tips: ils,jl02,k0 ,bc1,bl
-
In slow motion, you see the setpoint=325°C
Tip Temp:
running at 359°C PWM 100% :o
climbs to 381°C PWM drops to 0%
drops to 371°C PWM 100%
climbs to 454°C PWM drops to 0%
drops to 428°C PWM 100%
climbs to 450°C PWM drops to 0%
drops to 426°C PWM 100%
climbs to 452°C PWM drops to 0%
It's 22°C jumps up and down.
If your measured tip temp is way above the setpoint, heat on and/or the P and D-term is positive, this is a fault condition, there should be no demand for heat - assuming the setpoint was not dialed down while the tip was hot, or going to sleep etc.
I would have a separate safety task that just looks if things makes sense or not. It can catch malfunctions. The PID algo seems to not be working.
-
When something like that happens, enter the first debug screen(long press on settings screen) and see what the pid is doing..
The error is the difference between the setpoint and the actual reading.
Once the temp goes over the setpoint, the error goes negative and the pid shuts down.
I have not noticed anything strange, I've been using it yesterday for hours at 380°C.
Hopefully we'll find the problem soon.
Also, if you're flashing it often with different versions, remember to force a factory reset..
-
yes i know in the video its set to 325 , the problems of live tv xd. Any how temp keeps scalating until you kill power, i mean if you are well above target why would you keep going 100% and only happens when im above 315c. will report back with a foto/video in debug mode. edit : as soon as i enter debug mode it goes back to the set temp. so i was wondering why it was red while set to 400c , it should not so i measured it and was at 600c xd , calibrated tip and testing does not seem to happen any more.
-
Hmm. After calibrating, what are the Cal values in the second debug screen? (Again, long press, but in the first debug screen)
If you make a factory reset, does it happen again?
-
I would have a separate safety task that just looks if things makes sense or not. It can catch malfunctions. The PID algo seems to not be working.
That is easy to say.. Add more functions, more checks ... but it's not that easy.
Maybe the internal PID is getting a wrong temp, or the PWM value is getting corrupted, or I wrong typed a variable name.
This is developing. Everything is often being modified and you can't check absolutely everything.
Specially now adding support for new boards, there were some big changes.
Yes, there are safety checks, but assuming the programs works.
If you copy a random value somewhere, that is a bug, and totally unpredictable.
For protection there's already the no iron detection and it works very well. Lower the limit to something you would consider a limit.
Set you iron to the max temp you wil use it, go to debug screen and take note of the ADC value. If it's ex. 3800, set the ADC limit a little higher, ex. 3900 o 4000.
So if the temp rises too much it will trigger the detection and force PWM to 0.1%. There's no way the PID works if the detectign is triggered, the PWM is always 0.1%.
What I don't understand is why it doesn't trigger the no iron detection.
Have you disabled it by setting it to 4100? That is ouside the ADC range and will never be detected. Max is 4095.
At first I deleted the problematic DFLT profile, but then I decided to reset everything to approximate values, with the idea in mind to calibrate your own.
All the calibration were wrong, some people even reported -100ºC. So there's no sense of storing these calibrated values.
This were the default profiles:
All by default (including DFLT):
calADC_At_200 = 1300;
calADC_At_300 = 2000;
calADC_At_400 = 3000;
"B "
calADC_At_200 = 1221;
calADC_At_300 = 1904;
calADC_At_400 = 2586;
"BC2"
calADC_At_200 = 1463;
calADC_At_300 = 2313;
calADC_At_400 = 3162;
"D24"
calADC_At_200 = 900;
calADC_At_300 = 1932;
calADC_At_400 = 3598;
Now all by default:
calADC_At_200 = 1300;
calADC_At_300 = 2200;
calADC_At_400 = 3000;
Maybe I set some value wrong.
After successful calibration, let me know the cal values to note as reference!
My tip does:
CAL200:1468
CAL300:2373
CAL400:3379
Setpoint to 480:4000
So the detection is really close to limit on mine, but setting it to 4080 works.
Below that it triggers due the slight overshoot (reaches 4050 during 1/2 second when heating from cold).
As I say, I don't have T12 anymore, so I can't test it myself.
Also I won't spend money on something I don't need!
Maybe I should lower it even more, ex. 2500 at 400ºC
-
Hmm. After calibrating, what are the Cal values in the second debug screen? (Again, long press, but in the first debug screen)
If you make a factory reset, does it happen again?
Calibrated
Setp c200 c300 c400
____|_____|_____|______
0 | 836 | 1327 | 1777
reset
Setp c200 c300 c400
____|_____|_____|______
0 | 1300 | 2200 | 3000
After reset seems to work fine , no more scalating. Also i wont be using t12 soon, jbc handle is on its way , could you please point out how should i solder the connector (pins on handle and pins on quicko)?
-
1770 for 400ºC?? That doesn't look fine! The TC is doing 14uV / ºC
T12 tips do around 21uV, so @400ºC it should be doing 2600ADC or so.
Unless your board has different amp gain... mine has 250. Ksgers usually 230.
So what to do.. I can't magically set calibration values for everyone! Buying a temp sensor will be mandatory.
Fortunately they're cheap.
Anyway I added another protection, a 5-level runaway detection.
It only works if the PWM is active, as logically the tip can't be heated if there's no output applied.
If the tip heats with no PWM, then your mosfet has blown and there's nothing we can do.
This is also needed to avoid false triggering when the iron enters sleep mode, or it goes from boost mode back to normal, as in that moment the requested temp changes to much lower than measured.
Difference 0-25ºC : runaway level 0, not triggered
Difference 26-50C : runaway level 1, 20 second timer
Difference 51-75ºC : runaway level 2, 10 second timer
Difference 76-100ºC : runaway level 3, 3 second timer
Difference >100ºC : runaway level 4, 1 second timer
The values are beta, I will probably lower them further.
So if the overrun condition doesn't dissappear in the specified time, the overrun protection triggers and halts everything.
Assuming there isn't an error somewhere that sets the PWM to 100% instead disabling it :-DD
Now I did something because everything works but the tip is not heating. Even the PWM shows 100%.
Or my mosfet died just now!
(Edit: dead cartridge)
-
changes by +20 depending on the tip, but i have tryed it with two different multimeters, with two different thermocuples i think its called in english and both say the same temp, how could i tell how much adc is doing, anyway it could be said in the readme that is highly recommended to calibrate if not mandatory.
-
It was one of my tips that died. My mistake, I forgot to turn off the station yesterday, it worked at 390ºC for > 18h. And had disabled sleep...
Also I think it suffered heatstroke, the debuger stopped while I thought I had disabled the breakpoints... I was checking the menu and suddenly it freezed.
After 3 seconds I resetted it and the temp was ouside the measurement range. Oops. But I think it didn't got red hot.
And no, there's nothing you can do to void this in debug mode. If you stop the processor, you stop the processor in the middle of whatever it was doing.
I've found that the runaway detection is a bit problematic when removing the tip.
Depending on what the amp does when the tip is not connected, there are situations that make the amp to read noise, but giving values below the no iron detection.
So the PID goes crazy oscillating between 0-100% on each cycle, and triggers the runaway. Adding the 1M resistor will probaby fix this, setting the amp input to a stable state.
For the rest of people, the worst that can happen will be the runaway error shown in screen and the station rebooting after 5 seconds.
I think there's nothing else I can do with this limited hardware. And I prefer safe than sorry. A few runaway errors from time to time are better than burned tips.
In my case, it only does that when the tip is half-way conected.
If it's totally in or out, it works well.
Code updated!
-
Once your safety-check routine activates, I would also sound the beeper (as an alarm) so if I'm away from my bench, I know there is a danger- shorted mosfet etc.
Intermittent open thermocouple/heater is really a common problem with these T12 clone stations. Bad connections in the socket or cartridge. The hardware must default to something obvious, usually max. temperature and I add the 1MEG pullup. But we don't know if all the different op-amps behave the same (rail-rail) and can drive the A/D to 3.3V
I love Weller's approach to auto-shutoff and think it should be considered. Had a guy at work use a soldering station on the weekend and he forgot and left it running :rant: Monday I looked and the tip was oxidized dead.
Weller's algorithm is based on sensing soldering-station demand.
If tip-temp never drops 3°C or more (wand sitting there in the stand, doing nothing), shut off the iron after X minutes.
Every time tip-temp drops 3°C or more, the shutoff timer gets reset because that is a tip getting cleaned or wiped, or being used to solder.
I never use stand-by mode because it only takes seconds to warm up from cold. I think it's silly and prefer the iron to just shutoff if not being used.
-
Well, that is something to have a look into.
3 °C is definitely not possible as the temp regulation doesn't have that much precision.
And if the pid is well done the temp shouldn't drop much.
In fact it barely does, unless soldering something big.
Soldering small parts doesn't lower the temp enough, you won't notice the station is off before 10 seconds or so.
If you see the power output, it's always using around 10% to hold the setpoint temperature.
And now, with the lower sampling rate of just 5Hz, the pid is more harsh, it will detect that the temp lowered n°C in 200mS and try to recover fast.
That doesn't cause any real trouble, but you can't rely on the pid ouput to recognize a small load. It will go between 0 and ~20% all the time.
If you get a big tip and solder a ground plane, then yes, the power reaches 50-60%.
But the idea is nice. I will try doing a mean of the last 100-200 pid outputs and see if the values are usable.
As I said, what worries me most is detecting the small loads. There's nothing more annoying that the station shutting off by itself while working.
Also, doesn't weller use induction heating?
It will have a lot of sensing circuitry.
We have almost nothing, just the pwm output and tc sensor.
The problem is just that I've fitted the Jbc handle and haven't wired a mercury switch or the signal to the handle stand.
So it never gets any sort of wake signal.
About the problematic cartridges, what can I do? Doing something in the fw will give a lot of headaches.
If you detect the temp going crazy up and down, halt the station? So now every time you change the tip it will also halt?
Also, that will make the bad tips impossible to fix by heating, as they usually fix themselves after some burn-in time.
-
About the problematic cartridges, what can I do? Doing something in the fw will give a lot of headaches.
If you detect the temp going crazy up and down, halt the station? So now every time you change the tip it will also halt?
Also, that will make the bad tips impossible to fix by heating, as they usually fix themselves after some burn-in time.
Well if you can differentiate the situation for when the handle is not firmly contacting the tip. The metal rings....
Then you might occasionally flash up from time to time a simple message to the user like: "Check connection?"
To make them think to investigate more closely the handle. That it is keeping a solid connection. I think that could be very helpful.
However if you cannot distinguish the bad connection is inside and within the tip itself. Or the handle instead. Then it is really up to the user to check and dismiss the handle as the reason. But instead try with a different tip. And then notice it happening on tip A but not on tip B.
You see, i have kindda lost my trust in T12 tips and handles. After receiving the carbon fibre handle. Which is supposed to be the best T12 handle available right now. Yet despite being well made, and being electrically safe. Yet it still is not good enough? Because the hold on the tip is very loose. It spins and rotates freely in the handle. And the connection feels very loose. There is no click, or resistance when inserting the tip. It does not connect positively.
And yes... on the default chinese firmware the power flicks on - off - on - off. And it cannot stay on. So the overall heating is weak.
It's enough for me to say: well this handle requires modification. It needs to make a better connection electrically. With more force. More positively.
But for the firmware to notice this condition, (a regular disconnections of the TC). And to tell me with a warning message on the sccreen... well that would really be quite helpful. To be more sure, that I am not just imagining a problem. That it's real. And not due to something else. Or for other reasons.
-
regarding the handle on stand detection, on quicko station the rx pin on the swd header is connected to reset_state pa15 pin, having the tip conected to mains earth as it is on the t12 handle and connecting the stand to the rx pin, would make pretty straight forward to implement a similar solution as jbc(not implying that is easy , but very possible). also the sby detection works well with my iron , it turns off, and if no one touches the handle it stays off(forever), so i feel like its pretty redundant to have other ways that may take a lot of time to dev for very little results.
Also after trying last version pwm seems more linear and stable, dont know if you actually chaged anything regarding that but just saying good job!!
im at an early stage but sort of works, set up pin as pull up , check in iron if pin == 0 standby mode, the next thing is to think if we want to standby as lon as is in contact with the stand or go to sby when briefly detects when leaving iron on stand.
example: https://drive.google.com/file/d/1eJWj2_00FMrCstD7iu6MOW7HMfQUTmVm/view?usp=sharing
Only on quicko , dont know if it could work on other boards, this is just a concept dont take it as "good" coding xd
.ioc
pa15 -> left click -> GPIO_input
pa15 -> right click -> Enter user label -> STAND_DETECT
main.c line 551
/*Configure GPIO pin : STAND_DETECT */
GPIO_InitStruct.Pin = STAND_DETECT_Pin;
GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
GPIO_InitStruct.Pull = GPIO_PULLUP;
HAL_GPIO_Init(STAND_DETECT_GPIO_Port, &GPIO_InitStruct);
iron.c line 210
// Check if tip is in the stand
if(HAL_GPIO_ReadPin(STAND_DETECT_GPIO_Port, STAND_DETECT_Pin)==0 ){
if(Iron.CurrentMode != mode_standby){
setCurrentMode(mode_standby);
}
}
else{
setCurrentMode(mode_normal);
}
-
Yes, the stand detection is the easiest to do!
No worries, just check if it's 1 or 0, and go to standby or wake up.
It's faily easy, also if you set the GPIO with the weak pullup, you won't require any additional resistor.
But for safety, better to add a series resistor like 10K and a few nF cap to filter possible voltage spikes.
I would like the rest was so simple! :-DD
I wpudl like to add a tons of new menus for all that. But the menu system it's done in a way that makes it messy.
You can have scrolling titles, but no options. So you must do a new screen for the options, and only the few that fit in the display.
The menu requires a whole recoding to allow that. Then the options will be much nicer, and easier to add.
That's why the buzzer is set in code but not in the menu. I don't want do add a thousand screens!
My idea is to add just a few menus, then each with all the options in scrolling.
And, nope, I don't remember changing anything in the PWM or PID.
I added the runaway detection, improved some internal functions and I reduced the default calibration values to much lower.
-
After close inspection of the settings screen code i thin the problem is that the "options" are declared as widgets instead of comboadditem as in the menu, probably because its the only way to add an option box or what ever , documentation about microgui is not very extense, im trying to find if there is a way.I think what you meant was that having a menu for each option in each menu is a bit too much and you are right. :blah: :blah: if you have any id4ea how to refactor it im available to help :-+
-
OK... have now updated my research docs, for those sections which talk about how to backup the original firmware. Since August 2020, there is now a much easier power glitching attack, to unlock the protected flash memory.
It only requires an STM32F3 development board. And not a lot of skill or anything particularly challenging. If anybody is interested, you can read more about it here:
https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tools/software/STM32CubeIDE#option-2-power-glitching-timing-attack (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/tools/software/STM32CubeIDE#option-2-power-glitching-timing-attack)
Not sure where those boards are available from. Probably: Farnell, Digikey, and similar. But I would expect them to be fairly cheap and inexpensive?
[EDIT] yeah... search for "STM32F303VC" dev boards or "STM32F3DISCOVERY". They are pretty affordable. Under $20 on mouser or digikey:
https://www.mouser.co.uk/ProductDetail/STMicroelectronics/STM32F3DISCOVERY/?qs=%2Fha2pyFaduhRYzl9i01%252Bk0RzdRIzmgXiQMqh5UXh85Q1TO9QNL%2F%252BiQ%3D%3D (https://www.mouser.co.uk/ProductDetail/STMicroelectronics/STM32F3DISCOVERY/?qs=%2Fha2pyFaduhRYzl9i01%252Bk0RzdRIzmgXiQMqh5UXh85Q1TO9QNL%2F%252BiQ%3D%3D)
https://www.digikey.co.uk/product-detail/en/stmicroelectronics/STM32F3DISCOVERY/497-13192-ND/3522185 (https://www.digikey.co.uk/product-detail/en/stmicroelectronics/STM32F3DISCOVERY/497-13192-ND/3522185)
Seems to be more expensive from other places. Farnell / CPC is more like $23.
https://uk.farnell.com/stmicroelectronics/stm32f3discovery/evaluation-f3-cortex-m4-discovery/dp/2215108?ost=stm32f3discovery (https://uk.farnell.com/stmicroelectronics/stm32f3discovery/evaluation-f3-cortex-m4-discovery/dp/2215108?ost=stm32f3discovery)
-
After close inspection of the settings screen code i thin the problem is that the "options" are declared as widgets instead of comboadditem as in the menu, probably because its the only way to add an option box or what ever , documentation about microgui is not very extense, im trying to find if there is a way.I think what you meant was that having a menu for each option in each menu is a bit too much and you are right. :blah: :blah: if you have any id4ea how to refactor it im available to help :-+
The widgets and combobox are nothing from uGUI. That was done from scratch by PTDreamer.
uGUI only places lines, squares, and text.
There's absolute no documentation, I had to figure all myself!
Combo items only allows labels, not widgets.
The widgets are dynamic objects, the position can be relocated dynamically, also disable or enable them.
But there's no actual method to add them to a scrolling list.
I'm working on modifying the ComboBox widget, to allow two modes:
- Screen: The classic, text label, clicking enters a new screen.
- Option: Label, and a widget pointer. The widget will be drawn next to to the label.
Instead selecting the label, it selects the widgets. And clicking edits the widget.
Is no way so easy but I hope to get something.
It only requires an STM32F3 development board.
Interesting finding! If that lets the user backup their original fw for testing 3rd party ones, great!
Is the STM32F303 needed? Specifically? Can't be done with other stm32?
-
Well, I got it!
The whole menu is renewed.
Now the menus can be extended easily, and the initialization is way easier.
And as the combo box was modified intentionally this way, regular labels and editable entries can be used together, the first are used to enter a new screen, the second are attached to a widget and automatically takes care of everything, even placing it in the same height as the label it was attached to.
And I replaced the ugly square boxes with rounded ones, they look so much nicer.
Added few more options that I had in mind but couldn't due the menu system limitations.
And there's still plenty of ram free!
Video:
https://www.youtube.com/watch?v=l7mDah2jRSI (https://www.youtube.com/watch?v=l7mDah2jRSI)
Yes, I'm again without iron tips...
-
so cool , cant wait to upgrade
Problem in line 590 main.c ironwake() takes a bool as argument but none is provided on that line. just set it as 1 , working as expected.Also there is no longer wave widget when motion is detected on handle.
-
I don't know, probably you catched some transition code. There were a lot of changes, so I had to update the repository few times in between. I've compiled the boards a moment ago and all did perfect.
Git code updated, also the test binaries.
Had to set the NTC temp table as board specific adjustment. KSGERs use 4K7 pullup, while Quickos uses 10K, so the NTC reading on the KSGERs was totally off.
Changed the ADC trigering by Timer TRGO signal to manually start it from Timer interrupt.
This allows the use of any timer, as I discovered that not all TRGO signals can be used to trigger the ADC. This was a problem on KSGERs.
Hopefully should work on KSGERs now.
As the system configuration now has more settings, I changed settings versions to v11 to force resetting to defaults after firmware upgrade.
Jesus, try it out!
Cosmin you too, and report if the ambient temperature is correct now.
I've just removed JBC option and added C245 and C210 . C245 uses the same values as C210, it's not calibrated.
It's safe, as the C245 outputs much high voltage that the C210, so the real temp will be much lower.
Unless you give me away C245 and C210 tips, I won't buy them to calibrate anything, try yourself and report calibration values! :-DD
This last change is not yet in the compiled bins (I need some time for myself! ;))
-
will report back , also dont know if its against the rules of forum but if you post paypal i will send you a couple of beers , fantas or coffees. :-+
ok its working fine, the new gui is far better, also what does it mean Enc. Wake?
-
Encoder wake. So the iron also wakes up on encoder activity.
(Edit: Changed to "Button Wake" as it fits perfectly)
Ah, also the Iron mode times (Boost, sleep, standby) were changed to minutes.
No sense adjusting seconds in that.
At last, I found the weird bug that made some widgets to change its value a somewhat randomly when moving the encoder fast.
This happened where bigs steps were used, like PID and ADC limit widgets.
Now there's only a small bug left on the dot insert that makes numbers >99x9 shown a as 1000.x. Not a problem else than weird displaying.
-
Really nice work DavidAlfa, I like new menu and I'm really looking forward to trying you last CFW as soon as I get my spare STMs. Really many Thanks to everyone helping here!
-
Still have to do something with the widgets.
Although now I use less than ever, still each one takes 120bytes of ram for... a button? A 3 character value?
There're currently 66 widgets so... I have to find a way to enhace that.
-
Sounds like things have been progressing very well on the CFW front. One question, do you still lose the settings from one handle if you were to switch to another (say from T12 to using a C245) or can you now keep the settings from the previous handle from being overwritten when changing to another?
-
I've been working on that for a while already.
Hopefully, soon.
Edit: Almost working. That was a big pain to do... had to rework a lot of code!
Each iron type profile uses its own times and temperatures(standby, sleep, normal, boost), adc, pwm, etc settings.
Because , for example, T12 seems to need much higher recover time than C245. So it's better to isolate these settings.
To allow easy recover from messing something up, I also implemented new reset settings: only system settings, only current tip data(T12, C245, C210), all tip data(everything), or total reset.
-
What version of T12 hardware one should buy to be able to upload this custom firmware into STM32 controller and what external hardware will be necessary for this?
Also, I personally like the idea of having STC controller and 7-segment screen module with an "advanced" firmware. I'm pretty sure it can handle a minimal set of advanced features like: sleep time, sleep temp, power off time, encoder temperature step, individual calibration of 3-5 tips (who uses more?). Another nice thing that it can be programmed using a simple USB adapter.
Is there any detailed information about existing STC firmwares: firmware backup that can be used to restore controller after playing with it, etc.?
-
for the time being , quicko t12 stm32(so my first buy came with a stm32f072 about 3 months ago , and the second one with a cks32f103 about a month or so ago,both versions supported, as the pcb is exactly the same but the mcu), ksger v2.1s(64 pin both stm32f101 and stm32f103 ), v3.1 (64pin both stm32f101 and stm32f103), i would ask for a foto of the pcb or something before buying and check with the photos in documentation as if you buy something already working you dont have to rely on someone like david to port it as looks like they change hardware pretty easily and it takes time to adjust it.Also you will need an st-link or similar to flash it.
Regarding 7 segment , its possible yes , is someone in here willing to do it , dont think so as the developement requires having the device(maybe if you buy it for the dev, dont know).
And the usb adapter, no(depends , F103 does not have a built-in USB bootloader. Bootloader in F105, 107 has the USB option. for example ), i suppose you can update stm32 via usb but the mcu pins are pretty small and unused pins do not have a header, not accounting on someone having to research how to do it on multiple devices, no where to place the connector etc. a lot of work when swd is simple and dirt cheap.
on another topic:
the power glitching attack: so after having a look at it the main problem is the STM32F3 has 32 bit word(works with thumb 32),stm32f103 does too !!, it is implemented in assembly , and while pretty basic having it to work with different mcu is a bit too much as the register address for gpio and different states change from mcu to mcu. i bought a blue pill to see if i can port it as i don have any board to do so. so my idea is the attacker would need a blue pill, an swd(st-link v2 for example), and a usb2serial converter,probably a lot of people in here have both 3 or at least 2 so should be pretty cost effective. i found the STM32F3 for 16 euros on farnell so, in case you dont have a stlink and a serial2usb mb its a neater solution to have it on one board, anyway ill try to port it to the blue pill, ive managed to get working the leds using qemu emulator, but cant emulate buttons so im stuck until i receive the board.
-
What version of T12 hardware one should buy to be able to upload this custom firmware into STM32 controller and what external hardware will be necessary for this?
Also, I personally like the idea of having STC controller and 7-segment screen module with an "advanced" firmware. I'm pretty sure it can handle a minimal set of advanced features like: sleep time, sleep temp, power off time, encoder temperature step, individual calibration of 3-5 tips (who uses more?). Another nice thing that it can be programmed using a simple USB adapter.
Is there any detailed information about existing STC firmwares: firmware backup that can be used to restore controller after playing with it, etc.?
Of course, alternative firmwares are great!
I'm already crazy busy with the STM32 project, taking the 99.999% of its development.
Not being a professional coder (Although I must admit, my skills improved a lot with this project), developing it lot takes of tries, failures and debugging hours.
I won't take the huge task of porting to a new device that:
(A) - I don't known, mostly only chinese use them, so why taking the huge task of learning it?
(B) - I don't have, I don't need.. and I don't want even free. It's just a calculator that heats up!
(C) - Has documentation in chinese! Most development is also in chinese. Get prepared to find specifications, examples and forum support.
(D) - Already works pretty well, what can else can you expect from a 7-seg display? I don't expect any fancy features on such device.
-
(...) F103 does not have a built-in USB bootloader. Bootloader in F105, 107 has the USB option. for example ), i suppose you can update stm32 via usb but the mcu pins are pretty small
Anyway, the built-in uart bootloader works great, almost the same as by usb, you only need a cheap usb-serial ttl converter and the flash loader demonstrator.
Oh my, I started to see Hard faults everywhere... I even think I dreamed with a few! :-DD.
On first try I didn't think it enough, had to revert everything and start again using a different approach. Buuut it's done!
New profile system, now easily expandable, so in the future I can add support for new profiles in a breeze.
Included by default T12, C210 and C245. None gets deleted unless the user erases it.
Also, each stored data uses its own checksum, so in case of error only that slot is erased. Like this:
[SYSTEM SETTINGS][CHECKSUM]
[PROFILE1][CHECKSUM]
[PROFILE2][CHECKSUM]
[PROFILE3][CHECKSUM]
"Iron Type" menu and warnings are gone! Don't blame me if you mess up setting the wrong profile for the tip, be careful!
(I'm still thinking on detection method that doesn't need hardware modding)
The profiles can be changed on the fly from the Settings/SYSTEM entry. (Profile setting)
A new check after the boot splash is added, to detect first booting after a clean flash, that will prompt the user to select the correct profile.
Pretty similar to the old iron tip screen.
I discovered that CubeMX was allocating a lot of heap. Reduced it to almost 0. It freed up additional 1.5KB RAM. As I don't use dynamic allocation, it's ok.
(that was one of the big issues in the original fw, uncontrollled ram usage, hard faults everywhere...)
New settings use 2KB flash. Only the active profile is loaded to ram to save resources.
64KB devices are starting to struggle at 92% but still holding well!
The binaries are updated. As always, force reset at boot.
Also, as the state is stored, when you returned to a menu it would always be in "exit" or "back" modes(last state before exiting the menu), something I always found to be very annoying.
I made some changes in the screen system so there's always a "lastscreen" variable, very useful for taking certain actions depending on the screen you came from.
I use that to reset each menu to initial positions unless coming from a submenu.
-
nice i will try it , the power attack should be ready i cant try it until my blue pill arrives but it should be working, ive checked every single address and seem ok , its pretty much the same code but the address for the gpio moved from gpiod to gpiob and gpioe to gpioc https://github.com/jesusvallejo/BluePillPowerAttack
-
I won't take the huge task of porting to a new device that:
(A) - I don't known, mostly only chinese use them, so why taking the huge task of learning it?
(B) - I don't have, I don't need.. and I don't want even free. It's just a calculator that heats up!
(C) - Has documentation in chinese! Most development is also in chinese. Get prepared to find specifications, examples and forum support.
Is this about STC controller? Do I understand correctly that the main advantage of STM32 over STC is not calculation power, but 1) better development environment and 2) much better documentation? If so, then yes, STC becomes a bad choice for custom firmware.
What would make this project really useful is coupling it with a reference schematics, so people can assemble own board without a need to fight with Chinese sellers for a correct PCB version. Something like this: https://www.electronoobs.com/eng_arduino_tut49.php (https://www.electronoobs.com/eng_arduino_tut49.php)
-
after trying i get error while writing to flash! no matter if flash the provided or compiled. Also cant force reset at boot.
-
Hmm weird... I'll have a look. If I can't find anything will you let me debug yours with TeamViewer?
-
ive got it set up on linux, if we can do it there or you give me time to install whats required on windows yes, also older commits still work
ive tryed flashing it on windows and let me select the tip but still same error after that, also i have every thing ready on windows so if you need to connect just let me know
mb has something to do with
implicit declaration of function 'memcpy' [-Wimplicit-function-declaration] settings.c /STM32SolderingStation/Core/Src line 46 C/C++ Problem
-
I've been working on modifying the widgets system to free even more ram while allowing dynamic data length.
Now all uses pointers instead a fixed data array for every widget.
When I finish that, l'll look at the rest of the builds. The problem will probably be a minor bug, like a typo or something like that, or wrong linker settings.
Should be easy to find, as it doesn't fail on mine, smeels like a profile-specific setting.
Edit: Done. Almost 3KB RAM gained! 16KB devices still have ~3.8KB left. The widgets still use a lot of memory, but it's something.
Edit2: Had a quick look and the problem was pretty obvious.
Flash page size differ between the different stm32 models. Some use 1KB(F103xB/8, F101xB/8), others 2KB(072xB).
Added a check to erase the correct ammount of flash pages. Easy fix.
My checking routines did the correct job ensuring the stored data was correct , stopping the black hole happening! :phew:
Code and builds updated! Let me know how the new edit mode looks, I think the readibility is far better than with the "inverted" look.
-
I've been working on modifying the widgets system to free even more ram while allowing dynamic data length.
Now all uses pointers instead a fixed data array for every widget.
When I finish that, l'll look at the rest of the builds. The problem will probably be a minor bug, like a typo or something like that, or wrong linker settings.
Should be easy to find, as it doesn't fail on mine, smeels like a profile-specific setting.
Edit: Done. Almost 3KB RAM gained! 16KB devices still have ~3.8KB left. The widgets still use a lot of memory, but it's something.
Edit2: Had a quick look and the problem was pretty obvious.
Flash page size differ between the different stm32 models. Some use 1KB(F103xC, F101), others 2KB.
Added a check to erase the correct ammount of flash pages. Easy fix.
My checking routines did the correct job ensuring the stored data was correct , stopping the black hole happening! :phew:
Code and builds updated! Let me know how the new edit mode looks, I think the readibility is far better than with the "inverted" look.
edit: gui is now working but th te tip does not get hot, adc 34 p = 31 i =6 d = 0 err =708 out =0,also pcb temp says 30c and it isnt . Also gui is far more readable now, good job.
-
Did you made a full reset?
I have the 072 quicko station, and an additional quicko board that got as warranty replacement back then, I put 103 in that one.
They differ 2ºC in the ambient temperature right now. The board inside the enclosure is hotter from being in a closed space and also the power supply heat...
I can't try the pwm (dead tips,again)
Edit: Humm, yes something happened. It's not loading something. Power always shows 0%
Once you select each profile, and go back to the settings menu, it works again. And will work unless you reset everything.
Another bug! You know, for each feature you ad 2 new bugs haha.
Edit Fixed: The programmer The ape changed a profile variable after computing the checksum, when the checksum should be the last operation.
Also ensured to align the data to 32-bit , as the CRC uses that word size.
Thas wasn't the problem, however that is undefined behaviour and could catch some random data at the end if not computing an exact multiple of 32 bit data.
Builds updated
-
Did you made a full reset?
I have the 072 quicko station, and an additional quicko board that got as warranty replacement back then, I put 103 in that one.
They differ 2ºC in the ambient temperature right now. The board inside the enclosure is hotter from being in a closed space and also the power supply heat...
I can't try the pwm (dead tips,again)
Edit: Humm, yes something happened. It's not loading something. Power always shows 0%
Once you select each profile, and go back to the settings menu, it works again. And will work unless you reset everything.
Another bug! You know, for each feature you ad 2 new bugs haha.
Edit Fixed: The programmer changed a profile variable after computing the checksum, when the checksum should be the last operation.
Also ensured to align the data to 32-bit , as the CRC uses that word size.
Thas wasn't the problem, however that is undefined behaviour and could catch some random data at the end if not computing an exact multiple of 32 bit data.
Builds updated
yes full reset was made, in my case pwm shows 100% no heating, with older firmwares works, so its not a dead tip or or component.
-
Yes I know, it was a security feature not being disabled after the boot screen. All that is fixed. Or should be.
Unless something messed up with the pwm pun configuration
-
Yes I know, it was a security feature not being disabled after the boot screen. All that is fixed. Or should be.
Unless something messed up with the pwm pun configuration
the problem is still present after commit 8454c9bd799b8f0f97ee32109033cef313092633
works in "added more options"(10/1/2020), does not after it.
-
Had a second, Yep, the iron init has a new function to init the timer's timebase detecting the processor speed, to ease the porting between the different stm32, as some has max 36MHz, others 48, 72...
I forgot to put a line at the end that sets the PWM value that is used to calculate the PID output, so the PWM setting was always 0.
This only happens at boot, you'll notice taht if you go to advanced and change the pwm duty or delay, it works, because in that function it's ok.
Fixed and updated.
Edit: Didn't update, I noticed that disabling the Timer master output does nothing? The pwm stays on!
This is critical for safety control, so I won't update util fixed
Edit2: Ok, That only works in advanced PWM timers that have dead time generation. Not for normal ones.
-
This only happens at boot, you'll notice taht if you go to advanced and change the pwm duty or delay, it works, because in that function it's ok.
Fixed and updated.
Edit: Didn't update, I noticed that disabling the Timer master output does nothing? The pwm stays on!
This is critical for safety control, so I won't update util fixed
Edit2: Ok, That only works in advanced PWM timers that have dead time generation. Not for normal ones.
yes when changing pwm solves it , when the update is avaible ill report back.
edit: i have seen the update, working perfect.when in debug menu " Error In: graphics/gui/widgets.c" line:274
-
I know, that's why I didn't update here. Shortly after the update I noticed that, but it was late and I was tired, so I left it for other day.
I had done few widgets modification, added more data fields, (all signed/unsigned int 8/16/32) and put a check to ensure the last char is always 0 (string null termination), as otherwise it could get out of control.
This check wasn't done before, so you'd never know if a widget was incorrectly configured.
So after the update, one widget had an incorrect reserved char size, and the check detected it.
It didn't cause problems either because the assigned array was bigger, but it could crash the system in other conditions, so I decided to generate and error there.
The issue now happens with the calibration. I'm faking it as I don't have tips, and it reboots at the end.
In any case it should take care of the correct conditions, and reject data if not correct.
There might be something not being checking causing an undefined behavior, or other problem that I haven't identified yet.
Edit: I had a last try. I think the issue was the calibration process. It always returned 1 (correct).
There was no implementation for returning 0 anywhere. So it worked if the conditions where correct, but if they was not the case, again undefined behavior.
I added a check at the end of the calibration that ensures that the adc and temp values are 200<300<400 and return error if not. Hopefully should fix it.
At least, now the calibration shows failed for me, what it should have done before because the ADC only collects garbage when the iron is not present.
Code updated but builds removed for now. It should be pretty safe anyway, the pwm stops, the watchdog triggers...
I don't have iron tips and I've spent too much timer lately into this... I left the testing to you, try the calibration, and see if it fails anytime.
The only way the stm32 hard reets without warning is if the watchdog triggers. And this only happens when the ADC/PWM stalls.
I was busy with some test at the hospital, I'm a bit saturated and will take a small break.
Yesterday I added another option for setting the steps in the setpoint adjustment.
Also redesigned the PWM updating method, as changing it directly would cause some issues with the iron process being updated within the ADC interrupt.
Now it's the iron process who updates the pwm if it was changed. Also few other modifications in the pwm period/pwm delay widgets to ensure they never overlap.
BTW, you had asked me how to connect the JBC handle...nothing special needed.
In the C245 you have 2 options: Wire it exactly as the T12, with the sensor in series with the heater (no modifications needed), or independently (Then you will need to modify the board).
The C210 connection uses series conenction internally so it's the only way.
Check the Dreamcat4 documentation repo, has a lot of info.
-
thanks a lot, ill do some testing and report back as usual, i hope your test was ok. :-+
-
Fixed few widgets. More than fixed, reverted some test changes I inadvertendly commited...
And I think it's done.
The tests, well, that's just their routine before the next surgery, it should be ok.The surgery worries me more...
Before the first surgery, I was very active, doing a lot of trips, training... they advised to do the surgery because it the could become cancer in my 40's, so better to to it now I was in good shape.
It was a hard recovery, as the surgery was extensive, but after 15 days I was already walking and went to home.
Only 10 days after, all got so wrong that had another 3 surgeries, each screwed me up worse, and the last one was done to half-revert what they had done, had to stay 2 months in the UCI(ICU in english), new problems were appearing every day, and after that and one additional month to hardly be capable of standing up by myself for brief moments, and another month to be able to walk without fainting after 1 or 2 minutes...
And this surgery is to repeat that again, so I think I'm not being over dramatic?. But I'm optimistic anyways, as always. Maybe too much, close to idiotness maybe? :-DD.
-
keep it up :bullshit: , youll beat it soon :box:, and be back to your normal life. with covid everyone has lost the last year so youll catch your normal life right where you left it :phew:
-
Yeah, I hope so. Enough off topic haha.
Try the damn thing :-DD
-
ok i have tryed everything i could think of and seems to be working spot on :-+
-
Great! Any new options you might consider adding?
I feel the menu is a bit randomly organized, but there are lots of options and it's no so easy.
I might do a separate "Profile options". Anyway, now it's a breeze to rearrange the menu, as the widgets aren't attached to the screen itself but to the combo widget.
Updated builds. Any ksger user wants to try? I think now it's easier than ever to adapt.
The 3.1s 64-pin is known to work. I don't have extensive test report yet, but the PWM, display, buzzer and encoder is working.
Yet I have to know if the 2.1s 64-pin version with i2c works.
Dreamcat4, wasn't your blue board that version?
Now the main task would be to collect calibration results from different boards and set them as base into the firmware.
So anyone could use the firmware without huge temperature differences if not calibrated.
And to start adding the rest of KSGER boards, 48-pin versions.
-
maybe an option to have stand detection , that lets you select off,slp or stb. Also i know is more aesthetic to have te menu in current order but pid for example seems pretty advanced in compare to system settings, calibration or iron, so mb changing the order or not idk :-DD . also whats the real use for the edit tip menu, because if im correct the tip profile follows an algorithm based on the calibration c200 c300 and c400 and its different between tips, so i dont know why it lets you add new tips or else.
-
The edit tips menu is not only the name... each tip have its own pid data, max power... ;)
The specific tip pid settings are loaded when you change it, and pid control uses that data.
Then each specific profile (T12, C245, C210), has its own pwm settings, adc delay and few others.
Yes, I think the PID can be now moved elsewhere, as by long-pressing over the tip selection widget, it enters the PID menu.
Before, you would go to it very often to adjust the settings.
-
Added 2 new options:
- Encoder rotation inversion
- Wake input mode (Shake, Stand)
- Shake mode: Any change triggers wake up
- Stand mode: Input=0: Set Standby mode, Input=1: Set normal mode.
Stand mode enabled will disable "wake on button activity" mode.
-
Added 2 new options:
- Encoder rotation inversion
- Wake input mode (Shake, Stand)
- Shake mode: Any change triggers wake up
- Stand mode: Input=0: Set Standby mode, Input=1: Set normal mode.
Stand mode enabled will disable "wake on button activity" mode.
cant build it
Description Resource Path Location Type
'hiwdg' undeclared (first use in this function) board.h /STM32SolderingStation/Core/Inc line 74 C/C++ Problem
-
Added 2 new options:
- Encoder rotation inversion
- Wake input mode (Shake, Stand)
- Shake mode: Any change triggers wake up
- Stand mode: Input=0: Set Standby mode, Input=1: Set normal mode.
Stand mode enabled will disable "wake on button activity" mode.
cant build it
Description Resource Path Location Type
'hiwdg' undeclared (first use in this function) board.h /STM32SolderingStation/Core/Inc line 74 C/C++ Problem
I see. Accidentally deleted lines 47 and 48 from main.h when cleaning it:
https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/4cf254cf907bdde44662d51738522e1ff0ab7bb8#diff-4b24e111cbd493caaec9ed931db8ef718fe3ad9ffd30e549011705431eccf5fbR45
Restoring those should make it work again. Will fix that later in the day. Sorry! :palm:
-
Added 2 new options:
- Encoder rotation inversion
- Wake input mode (Shake, Stand)
- Shake mode: Any change triggers wake up
- Stand mode: Input=0: Set Standby mode, Input=1: Set normal mode.
Stand mode enabled will disable "wake on button activity" mode.
cant build it
Description Resource Path Location Type
'hiwdg' undeclared (first use in this function) board.h /STM32SolderingStation/Core/Inc line 74 C/C++ Problem
I see. Accidentally deleted lines 47 and 48 from main.h when cleaning it:
https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/4cf254cf907bdde44662d51738522e1ff0ab7bb8#diff-4b24e111cbd493caaec9ed931db8ef718fe3ad9ffd30e549011705431eccf5fbR45
Restoring those should make it work again. Will fix that later in the day. Sorry! :palm:
correct, flashed already will test later. ok how does the stand detection mode works? i cant see pa15 mapped to detect the tip touching the stand.
-
No, you use the existing pin that would go to the handle sensor.
It works exactly as I already wrote in the previous post.
Connect the tip to the ground and the stand to the pin.
Or whatever that makes the signal go to ground when the handle is in the stand.
-
im plain dumb :scared: , i cant see how that works , the stand is connected to nothing so how do you know is touching it :=\
edit: a ok so you are using the remaining pin in the connector for that instead of pin pa15 right?
ok so handle switch changed by cable to the stand but eventhough connection is good , the detection gets crazy when its on the stand.
-
I'm not using any remaining pin.
The pin that normally goes to the handle "wake" switch is disconnected and then wired to the stand.
And the part of the handle that touches the stand is connected to ground.
Is the handle connected to solid ground?
By default it isn't, there's only a 100K resistor to gnd for esd protection.
Otherwise it will pick noise and go crazy...
-
Is the handle connected to solid ground?
By default it isn't, there's only a 100K resistor to gnd for esd protection.
Otherwise it will pick noise and go crazy...
3 ohm from tip to chassis so dont know why it happens it should work.
-
I repeat that the Quicko gnd is not chassis.
The chassis goes to main's earth.
And it's connected to the internal gnd through a 100K resistor you will find next to the soldered connector in 45° angle, next to the mosfet.
You can put a solder bridge over that resistor
-
I repeat that the Quicko gnd is not chassis.
The chassis goes to main's earth.
And it's connected to the internal gnd through a 100K resistor you will find next to the soldered connector in 45° angle.
so i replace it with a 0 ohm and good to go right?
-
Correct! :-+
New update in the graphics drawing system, it's been in my head for a while now.
The original firmware redraws the whole screen everytime, no matter if there are changes or not. That causes the oled drawing process to consume almost all the cpu power.
I modified the code to add content checking, also in strings widgets (doing a quick checksum from the string data and comparing values), so unless force_refresh variable is set, the widgets won't be drawed if there are no changes.
This checking is done for each widget, and updated independently from the others.
Initial tests show almost 20x less cpu usage (the main loop went from 108Hz to 1800-2000Hz in the heaviest screen, STM32@48MHz, SPI DMA).
So there's a lot of power left for other applications that could be embedded in the fw.
Software-updated displays will benefit a lot from this with increased refresh rate.
I think it's time to announce the end of the project.
The main target was for myself, to replace the terrible Quicko firmware and to learn about stm32 hardware and programming.
Because I'm not egocentric, since the beggining I decided to develop it to be multi-target friendly.
But there's almost zero interest, so I will not bother further. Once finished for the 64 pin KSGER 3.1 and 2.1s, that will the end.
I might still do small updates from time to time correcting small bugs or adding new features I might need, but I won't be working actively on it anymore!
-
the detection gets crazy when its on the stand.
Regardless of your wrong gnd connection, I added a 500mS debouncing time for changing the mode.
So as long as the mode isn't stable for more than 500mS, it won't be applied. This will ensure stand clean and stable operation.
-
Hi,
how can I connect a 245 Tip to Quicko?
There is no jumper, so have I to cut traces?
-
Beware that the stock fw can't handle C245 cartridges.
You will probably burn the cartridge as it's set for T12 only and doesn't allow calibration.
A big problem with the Quicko is that the connector is soldered and to have access to the back of the pcb you must unsolder it.
That is calling for trouble, the board will get damaged for sure.
I found a simple way to connect the C245 without much hassle. This is how I did and it worked very well.
Only a trace must be cutted and a wire soldered.
It uses the pin normally used for the handle NTC, not used with JBC, neither in this firmware.
The existing circuitry shouldn't be a problem.
I found best performance PWM settings with 50mS Period and 5mS Delay. Less delay will catch random noise from conmutation and affect the temperature reading.
Keep in mind that calibration is a must! Select the C245 profile, and use a temperature sensor for calibration, be careful to not do anything wrong that could end burning the tip!
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1155124)
-
Is it possible to use the handle sensor amp instead of the tip sensor amp for 245?
The schematic seems the same.
So we dont have to cut anything.
-
That amplifier provides a gain of ~50, far away from the 233 from the tip amplifier.
The adc resolution would be very low and catch a lot of noise, as with that low gain, it almost equals to 1bit/°C.
You would need to modify the gain by replacing amp resistors.
Why so much drama for cutting a trace than can be joined again very easily?
You can still use T12 this way, only needing to join the heater and the Jbc pins in the GX12 connector
-
edit: i have seen the update, working perfect.when in debug menu " Error In: graphics/gui/widgets.c" line:274
Hey, I'm migrating the graphic system from uGUI to u8g2. The latter is in active development and has much more options, fonts...
But the picture format is different (XBM). Can you upload the boot picture so I can convert it?
-
(http://)
edit: i have seen the update, working perfect.when in debug menu " Error In: graphics/gui/widgets.c" line:274
Hey, I'm migrating the graphic system from uGUI to u8g2. The latter is in active development and has much more options, fonts...
But the picture format is different (XBM). Can you upload the boot picture so I can convert it?
here it is :-+, remove .c from the logo.kra.c to have the krita file in case you want to edit anything.
Also o another topic, the stm32m3discovery arrived and attemted the attack but i was not succesfull, i removed the stm32f07 from one of my quicko and replaced it with an stm32f103 , flashed last version and lock the flash with level 1, removed for the moment the cap on boot0 and the resistor on the reset, traced the tx and rx to one pin of the encoder and the other to a resistor that leads to the handle sensor, sonnected everything, followd instructions, but the serial terminal never appears, in the img he has the mcu alone , so i have bought a dip48 to pins(pins are very fragile to try soldering enamel wires) to try it again, mb i have more luck then , its aliexpress so it will take prob a whole month.
-
New u8g2 library fully implement in the firmware, replacing uGUI.
A brief review of the new gui :-+
https://www.youtube.com/watch?v=Ft9yvSj_qFU (https://www.youtube.com/watch?v=Ft9yvSj_qFU)
-
Actual stage is getting stable, and further customization easier every day due more widget changes.
Currently accepting any gui / widgets / fonts suggestions!
Fresh ideas and/or collaboration would be sweet.
Bought new C245 tips, and a pair of cheap T12 for testing.
There's a new C245 seller in Aliexpress, wasn't there last week, they're cheap and they look really nice. Bought the 3.
(https://ae01.alicdn.com/kf/H1e0c8ef1ab8c4f6cb2f6b62d266ac1b7G/Serie-de-puntas-de-hierro-de-soldadura-OEM-C245-estaci-n-de-soldadura-Universal-JBC-CD.jpg)
https://es.aliexpress.com/item/1005001953693376.html
I'm thinking on removing boost and standby modes, leaving only Sleep (power disabled) and Normal modes.
Never saw much sense to so many modes, specially keeping the iron partially turned on when it heats in 6 seconds from cold.
I might add additional options to disable that within the firmware.
Currently thinking on totally disabling the screen while in sleep mode and display a fancy sleep animation.
I'm pretty sure there's no other firmware with such level of customizable options... Actually so many that making a proper documentation is now a must!
The EMA/DEMA filtering looks good, I'm sure the problems were caused the low ADC delay used back then, so I added them back (already seen in the video).
-
Nice C245 tips, thanks so much for sharing the link. Overall i am really impressed with your GUI is amazing. Really well done.
In terms of my own usage, I often find that nearly always I want to set ont of 2 temperatures:
* 350c for delicate control traces etc.
* 450c when the solder joint is connected to ground plane. Or +Vcc. Or for large connectors etc.
So if you take away boost mode, then can we have a way to select between presets instead? It is kindda the same thing, just not called 'boost'. I guess the real question is how many presets a user needs to access and save? 1, 2, 3. It is an open question. IDK.
The thing about 'boost' is i forget what it means! And I forget how to activate it. It would be easier (for me) to understand to just cycle between preset labels on the screen: T1, T2, T3. And draw a 1px box around the currently selected one. In fact I just do not tend to trust automatic sleep myself. And would prefer to manually switch the iron on and off by clicking a button. This is what I already do ATM. However the power switch is on my Lab PSU.... so then every time I turn the iron back on. I have to wait for the firmware to reboot. And go past the splash screen etc. Which is not so fast.
Rather it would be better to keep the controller booted, and just on/off the tip by using your firmware! Hope that makes sense. If you understand what I mean.
Was also wondering about the C210 handle. Because somebody said on discord they find it is smaller enough (than T245) to feel better at micro soldering. For a finer control under the microscope. However IDK if really worth it myself.
https://www.aliexpress.com/item/4001098984098.html (https://www.aliexpress.com/item/4001098984098.html)
It is mostly just smaller distance between the fingers and the tip end. Of the handle Which T210 gives you.
-
the sleeping station :=\ would be hilarious for the sleeping screen :-DD . Also when we us mortals will be able to compile and flash, i cant wait.
-
The boost is enabled by long pressing over the setpoint widget, and stays active for the specified run time.
I never used such, if I need more power, just turn it higher.
It was just my personal liking. Do you guys think it's really useful? I will left it there then.
Jesus, still tons of bugs, why would I upload problematic and dirty code...
Do you like crashing every 2 minutes and funny widget bugs? :-DD
The GUI isn't done either. Trying a lot of different fonts, screen organizations...
Today I found a nice font that fits great and has perfect readability for the iron temp.
The main problem with pretty fonts is that they usually look terrible on aliased, low-res displays.
-
Sorry to interrupt you guys.
I have a problem again with my Ksger board.
After a bad connection to JBC tip, i blewed the 4409 power transistor. I replaced it, now it's working again but the actual tempersture is smaller with 100-130 Celsius degree than the requested temp.
I replaced the opamp too but nothing changed.
What could be the problem???
-
In a different scenario, i myself observed a similar result when grounding a thermocouple by accident. It interfered with the measurement and the reading became something like -100c lower than it was previously.
As for where in your damaged circuit that is happening... I really don't know! Maybe at least try a different tip. Hope it helps.
-
Are you sure it's correctly wired? Was it really measuring correctly before blowing up?
-
I am using the T12 handle with different T12 tips, all measure the same on that board. On the other board the measuring is right.
The wiring is correct, it was never been changed.
I got no idea what is happening... new MOSFET, new op amp... and still having this problem.
-
So one board reads the wrong temps? Check the CJC reading from NTC, it can also make tip temperature seem wrong. To trouble shoot, sometimes I inject 10mV and see what reading I get at the handle.
The soldering station connectors and wire are not good for more than a few amps which is a problem at JBC levels. Direct soldering to the board is better. The handle wiring/cable is also thin copper and has two grounds - a power ground for the heater and signal ground for the TC, NTC and switches.
With the AO4409 (http://aosmd.com/pdfs/datasheet/AO4409.pdf) I would add a fast recovery back-emf diode in parallel with the heater to protect the mosfet and TC op-amp. Check the two gate-drive resistors (1k, 2k) are not flipped. With 25VDC power, should give 10-15V drive. Max is 20V. The other mosfet seen TPC8107 has a gate zener for protection. But I think you might have -ve spike, wimp mosfet, or power supply is sagging too much- if it drops a lot with heat on, it starves the mosfet of gate drive and it will burn up.
-
First time i tried with TPC8107. And had this temp reading problem. I assumed it was not ok to use that Mosfet, so i ordered the propper one, AO4409. But problem was not the Mosfet type.
I think the board should work without modifications, if in the beginning was ok.
If i calibrate the tip to read the propper temp, i have another weird behavior:
https://youtu.be/DRw-xHCXBk8
-
I've always liked minimalist designs, keeping functionality, of course
I will definitely remove boost and sleep modes.
The boost mode itself is kinda useless.
If you really need the boost to solder big stuff, it will disable anyway after the timeout, and it will annoying having to set it again.
You can increase the time, but again you'll have to manually disable it when finished.
I hate overcomplicated stuff.
More power? Rotate clockwise.
Less power? Rotate anticlockwise.
To enter settings, long press.
To change tip, rotate while pressed.
I have not assigned a simple click action yet.
And as I said before, no sense keeping the iron hot when it heats so fast.
So it will be running or in standby.
https://www.youtube.com/watch?v=8jYHOFXxlhw (https://www.youtube.com/watch?v=8jYHOFXxlhw)
-
First time i tried with TPC8107. And had this temp reading problem. I assumed it was not ok to use that Mosfet, so i ordered the propper one, AO4409. But problem was not the Mosfet type.
I think the board should work without modifications, if in the beginning was ok.
If i calibrate the tip to read the propper temp, i have another weird behavior:
https://youtu.be/DRw-xHCXBk8
In the video, looks like S/W issue at 0% PWM and it's always under the 300C setpoint. It's supposed to turn on the heat for more than a blink.
For wrong tip temp:
Check 3.3V rail is accurate, TC op-amp is not the 621K that seems to give poor results.
Cold Junction Temperature is correct, the handle NTC could be wired wrong, or just switchover to fixed value like 25C.
Firmware shouldn't read the NTC when the heater is on due to the voltage drop in the cable upsetting that analog.
Circuit gain is 250 (249k/1k), never seen 233 where is that from?
-
Quicko has 2-stage amp circuit, 16 and ~14.5 gain each.
So the total gain is around 232.
It's getting close to release a beta for testing! The SPI HAL crashes often and I have no clue why, I didn't change the hardware functions.
It just comes to a point where after a dma transfer, the HAL SPI gets stuck in busy state. All the bits checks are done, it's not the hardware being busy.
My guess is that it could be a bug in newer library versions.
I removed the debug screens from normal builds (can be enabled by setting a preprocessor define) as they took almost 1/3 of ram usage.
Now is a little over 9KB, allowing it to run on more basic devices.
The widget part seems to be ready, making everything self-aware of content changing was a little mess, there was always some situation where a widget wasn't refreshed, took old values or wasn't even drawn.
It's great to see the display completely idle while nothing is changed.
U8g2 has it's weird bugs too, certain drawing functions corrupt the whole display if certain parameters are exceed, they don't check them.
Now I'm thinking on doing a temperature graph or something like that.
-
Circuit gain is 250 (249k/1k), never seen 233 where is that from?
What do you mean by 233? It's 249k/1k.
3.3V rail is stable.
I will do more tests, even playing a bit with the op-amp gain.
Wiring is correct. Same handle works ok on other controller.
-
Oh c'mon, why's this thread so dead?
Nobody coming with ideas or anything!
It's very easy to sit down and wait for things to come... :-\
Anyways, I'm decided to beat the crap out of these crippled firmwares :-DD
I have not set the labels font yet and they look ugly.
https://www.youtube.com/watch?v=xIL7ontLoGM (https://www.youtube.com/watch?v=xIL7ontLoGM)
I also found the way to add handle type detection without modifying the hardware, by changing the wake/stand pin to analog.
This will also completely fix the iron detection.
No need of adding the op-amp resistor!
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1159418)
By changing the resistor value (potentiometer in the picture) we change the divider voltages.
We have only 2 possible voltages (switch on/off), they will tell us the handle status but also what handle type is connected (T12, C210, C245...).
If no handle is connected, the open circuit will cause the reading to be very high, that will be no iron detection.
The way C210 and C245 are wired require different handles, so it's ok.
-
I also found the way to add handle type detection without modifying the hardware, by changing the wake/stand pin to analog.
This will also completely fix the iron detection.
No need of adding the op-amp resistor!
By changing the resistor value (potentiometer in the picture) we change the divider voltages.
We have only 2 possible voltages (switch on/off), they will tell us the handle status but also what handle type is connected (T12, C210, C245...).
If no handle is connected, the open circuit will cause the reading to be very high, that will be no iron detection.
The way C210 and C245 are wired require different handles, so it's ok.
Hey I really find this awesome idea. Thank you so much. We really needed to come up with a good solution for this.
2021 will be the year of KiCad. Because that software is getting some major improvements.... do you think we can publish these mods as schematics in KiCad? Because that would help for gathering them all together, and editing them in github. It would be really nice I think, to make them available for everybody in a way that is easy to edit.
I have not had time to really understand what you are doing here to get this to work. But I really like it! And will definitely want to try it out 'at some point'. Just I have these other unrelated stuff going on.
Also for this project is nice to hear from Jesus... about whether we still can use a regular MCU like the blue pill to read the protected flash. Or if we must order the special discovery board for that.
Anyhow I really appreciate what you guys are all doing here! Even without enough time personally to participate.
-
I still can't experiment, still waiting for Aliexpress delivering my GX12 connectors and spare STMs. By the way, Is there a good reason to prefer a STM32F301C8 over a STM32F072C8 when it comes to change the original STM32F072C8 in my board with the new spare one? I'm also considering overwriting the original quicko firmware because, as far as I can see, the great and hard work on this CWF by DavidAlfa is going to provide us a way better firmware and soldering station! I'm also starting to think that one day or another we will see Quicko soldering stations sold with this CWF installed :)
-
for the moment the read attack is on standby, the attack does not what its meant to do with the original hardware stm32f3discovery neither with the blue pill port as its the direct "translation" from one bord to another, ive opened an isue on the h3 git but seems op is not willing to help, there is another issue opened a long time ago with no answerd, so when im done with exams ill go deeper into it. There are two problems, the attack consists in loading into ram a binary that enables uart, but in order to be able to read flash, protection needs to be disabled, hence the power attack, that should leave untouched the ram loaded code and give us access to flash, but the uart shell code does not open the uart and continues with the flsh bin execution(first problem),also i have tryed to flash shell bin into flash to see if it works but does not, has no uart output(problem 2). ive tryed also with the provided bins and self compiled , neither work and its strange as the self compiled is much faster , eventhough are supposed to be the same.
-
I was wondering how are you powering the target mcu? Have you desoldered it, or lifted all the Vcc legs? And do you have a scope to check the power glitch is successful at pulling down the Vcc rail?
-
For sure, if it gets good enough, they will at least take part of the code, probably disabling the advanced settings.
Their developing is absolute crap, but, why even bother when it's already done and free?
They are like hienas, opportunists, makes me want to close-source it and request activations for a beer. F** them.
There's no really a big difference between these, else than higher speed and more memory.
Both are more than capable for the current fw, now more than ever, as it basically idles almost all the time, unless you board is crap and can't use hardware dma.
But why bother so much when you can buy few chips for little? The firmware itself is rubbish, specially the Quicko one.
Unless you do it for the challenge, which I totally understand, I've trashed countless hours on such things :-DD
If you want to power glitch it remember to remove or reduce the board capacitors, or they will filter the glitch out!
Dreamcat, that isn't a schematic itself. Just 4 resistors! haha.
But I agree to use a more standard schematic software.
The circuit is pretty simple, instead using the handle switch to short the sense pin to ground, it does it through a resistor, making a voltage divider with a known voltage.
If you put a parallel resistor, you will have always a voltage divider, but with a parallel resistor to it when the switch closes.
Again, the voltages are known, so you can perfectly know what handle type is plugged in, and the switch status.
-
yeah for the wiring between the board and the various different connectors. A schematic then gives the way to do the wiring. Regardless if the mod is on board or off board. Does not matter. Also kicad can work with 3d models. Which might be helpful. As are other possible mods.
For the copy protection: The main benefit (to this project) is for those in the ex soviet states, on other forum such as Radiokot. We want to encourage them to participate in this project. But they are all prefering the chinese firmware over there. So (for them) being able to backup before flashing is really important. And we will do better to include that other group of people, they have very good knowledge and expertise. Much help is from Russians.
But even without, its still very useful for many other devices. Since STM32 is widely used in industry. And appears in many products. Therefore the ability to read and backup original firmware from other types of devices. That is a very useful capability. As a part of right to repair.
-
I was wondering how are you powering the target mcu? Have you desoldered it, or lifted all the Vcc legs? And do you have a scope to check the power glitch is successful at pulling down the Vcc rail?
im using a broken board with everything removed but the mcu, dont have a scope , but with the multi i can see the voltage droping a bit, so i think its doing it. the thing is , how is the mcu supposed to stop executing flash and start executing ram, i mean , loading it to ram does not tell the mcu to execute it or does it? there is little explanation on how the attack works ,and all i know is from the code , wich as stated before behaves strangelly as th provided bin is slower than the compiled version, the rooshel bin seems odly small and so on. also everything is wired correctly i have made some tests , uart works , boot and reset work etc.
-
you also read the PDF paper too, yes? It explains in there the basic idea behind the attack. Hopefully to make it easier to understand what the code is doing. (edit) but also you will want to refer to the ST reference documents and specifications. It is difficult not to have a scope... to check the pull down time is long enough. Unfortunately i don't have a scope either here. Maybe a logic analyzer could see it (the glitch), if it is fast enough. Not sure.
-
you also read the PDF paper too, yes? It explains in there the basic idea behind the attack. Hopefully to make it easier to understand what the code is doing. (edit) but also you will want to refer to the ST reference documents and specifications. It is difficult not to have a scope... to check the pull down time is long enough. Unfortunately i don't have a scope either here. Maybe a logic analyzer could see it (the glitch), if it is fast enough. Not sure.
after rereading the paper, the way it tells the stm to boot from ram is via pulling up boot 0 AND BOOT1 , it does not metion it on the README but st is very clear about boot0 and boot1(pb2) having to be up in order to boot to ram, paper says:". Next,
we configure SRAM-booting via the BOOT pins.", anyway it still does not work
here is the attack in real time: https://www.youtube.com/watch?v=20GghGAopXw (https://www.youtube.com/watch?v=20GghGAopXw) , min 16 , the bin he uses is 1832 bytes != 268 bytes of the bin they provided. i have seen he has updated the bins but still cant make it work, perhaps the mcu im trying it on is fake?
Success!!! after trying with another mcu i could do it, so first of all to see wich type of attack to perform is to check wether its legit or fake.if fake like cks , there are other easyer attacks.
-
I released the code! The spi still crashes without logic reason from time to time but for the rest is pretty good. As a preview it's ok!
Updated binaries for Quicko STM32F072/STM32F103 and KSGER 2.1s STM32F103RB ("Blue" 64-pin version)
They can be downloaded on their respective folders.
I think the compiler went crazy, at certain moment it got stuck inside a loop from the oled initialization that I haven't modified for ages.
Doing"while(value==0);" and value was 0! No sense. Added a nop instruction inside the while loop and started working again.
That stupid problems make me mad!
After finding a stable ADC delay, try EMA filtering with a coefficient of 1 or 2! Higher might delay the signal too much (limited to 4 anyways)
-
This is excellent news, from both of you!
Success!!! after trying with another mcu i could do it, so first of all to see wich type of attack to perform is to check wether its legit or fake.if fake like cks , there are other easyer attacks.
Jesus - have you tried identifying the mcu by connecting over swd with openocd? I believe there is another thread here on eevblog somewhere. Which explains how to read certain bytes. If i can find that thread then i shall come back and post the link.
-
could not find the original thread. But here us another different thread
https://www.eevblog.com/forum/microcontrollers/cheap-bluepill-very-likely-it-has-fake-stm32-right/125/ (https://www.eevblog.com/forum/microcontrollers/cheap-bluepill-very-likely-it-has-fake-stm32-right/125/)
it is necessary to load into memory a program over debug swd connection. For example after connecting via openocd. Then get the mcu to run the test program on itself. without having to write anything to the flash. If that makes sense.
-
This won't last long. Once the companies see their code compromised, they will use lvl2 protection, which permanently disables the debugging and can't be reversed by erasing :-DD
-
level two is also compromised, its more dificult but it is anyway. clone chips are far easyer as with some commands and swd you can dump the flash. mb they just stick to other stm32 versions as for the time being there is no info about other chips such as 072,101,etc 103 is older than 072 so mb some of this attack vectors are solved,
if not it would a matter of (mb also changing some directions) compiling for m0 instead of m3. atually not possible to reuse the attack, m3 uses fpb wich can patch code and use breakpoints , and m0 uses bpu , wich is only breakpoint (stated on reference manual). the attack needs the software patching in order to work.
-
Then they will end with the old school e-fuses ;D. Once burned it's over!
In fact I've seen cases where they physically damaged the programming pin by overloading it, causing the esd diode to short out.
-
Then they will end with the old school e-fuses ;D. Once burned it's over!
In fact I've seen cases where they physically damaged the programming pin by overloading it, causing the esd diode to short out.
yeah for sure, on the other thread there is a comment that makes it pretty obvious, the only way they can keep their products ownership is via firmware as the pcb once its sent to the pcb maker it is of "chinesse public domain" meaning anyone can buy the desing from the pcb maker :-DD , so i guess they will do as you say. But as long as they use the stm32, and your firmware is avaible, we are safe. :-+ Also stm32f0 is also compromised but is a bit slow and the firmware for the attack board is for stm32f052 https://www.aisec.fraunhofer.de/en/FirmwareProtection.html (https://www.aisec.fraunhofer.de/en/FirmwareProtection.html) , i have also seen another using bus pirate https://gist.github.com/egirault/7b3fe7041e1bf5e2258ed5df7083f14d (https://gist.github.com/egirault/7b3fe7041e1bf5e2258ed5df7083f14d) .
-
There are also anticopy chips, they are like spi memories, however inside there's a 128bit key and a encryption engine.
-
There are also anticopy chips, they are like spi memories, however inside there's a 128bit key and a encryption engine.
so i have tryed the last commit and i love the new gui. also ist working in both f103 and f072.
-
They should! I had tested both thoroughly :-+
-
They should! I had tested both thoroughly :-+
i could reproduce twice an error: "ERROR IN: ../Drivers/graph LINE: 241" , use iron , let it sleep for a long time(30 mins or so) , and it freaks out.
Also no iron detection in 072 is more stable than 103.
-
I know, it's the bug I said. It happens randomly in the dma callback.
Iron detection is the same, for all, only the ADC pin is different...
I tested putting a 10 Mohm resistor between the amp input and vcc and it was more than enough to force high level when floating.
The issue is in the SPI HAL handle State. File "stm32f0xx_hal_spi.c" line 3050.line
After the DMA is completed, it clearly sets it to "HAL_SPI_STATE_READY".
Then it calls the callback, where I change the oled row and send the next data chunk if not done yet.
And it fails is in the oledrow change. It suddenly returns "BUSY".
I added a check before the return of the offending funtion to catch the error. And it never triggers the breakpoint!
It's completely ridiculous!
stm32f0xx_hal_spi.c, HAL_SPI_Transmit, line976.
error:
if(errorcode != HAL_OK){
asm("nop"); //<-- Breakpoint here, never triggers
}
hspi->State = HAL_SPI_STATE_READY;
/* Process Unlocked */
__HAL_UNLOCK(hspi);
return errorcode; //<-- So this should return HAL_OK!
}
However in ssd1306.c, write_cmd, line 244, it receives HAL_BUSY!
uint8_t err=HAL_SPI_Transmit(oled.device, &cmd, 1, 10);
if(err!=HAL_OK){
Error_Handler(); //<-- But it breaks here! err==2(HAL_BUSY)
}
It's driving me crazy! If I omit the error and continue, it wil fail anyways in thenext SPI call.
-
I know, it's the bug I said. It happens randomly in the dma callback.
Iron detection is the same, for all, only the ADC pin is different...
I tested putting a 10 Mohm resistor between the amp input and vcc and it was more than enough to force high level when floating.
The issue is in the SPI HAL handle State. File "stm32f0xx_hal_spi.c" line 3050.line
After the DMA is completed, it clearly sets it to "HAL_SPI_STATE_READY".
Then it calls the callback, where I change the oled row and send the next data chunk if not done yet.
And it fails is in the oledrow change. It suddenly returns "BUSY".
I added a check before the return of the offending funtion to catch the error. And it never triggers the breakpoint!
It's completely ridiculous!
stm32f0xx_hal_spi.c, HAL_SPI_Transmit, line976.
error:
if(errorcode != HAL_OK){
asm("nop"); //<-- Breakpoint here, never triggers
}
hspi->State = HAL_SPI_STATE_READY;
/* Process Unlocked */
__HAL_UNLOCK(hspi);
return errorcode; //<-- So this should return HAL_OK!
}
However in ssd1306.c, write_cmd, line 244, it receives HAL_BUSY!
uint8_t err=HAL_SPI_Transmit(oled.device, &cmd, 1, 10);
if(err!=HAL_OK){
Error_Handler(); //<-- But it breaks here! err==2(HAL_BUSY)
}
It's driving me crazy! If I omit the error and continue, it wil fail anyways in thenext SPI call.
what about waiting for the transmit to end as suggested in here: https://electronics.stackexchange.com/a/274685
I can see one problem for sure which is HAL related. The HAL_SPI_Transmit is not a ready to use function. It is a blocking SPI send function only without the blocking part.
So I do not know if there anything else wrong, but you certainly should wait after the SPI transmit as follows:
HAL_SPI_Transmit(&hspi1, &xy, 1, 1);
while(HAL_SPI_GetState(&hspi1) != HAL_SPI_STATE_READY);
You should wait for the end of the transmission, before moving on.
-
Yeah I also added these checks everywhere, and as I said, the breakpoint never stops there.
It's in ready state before calling spi transmit.
It's in ready state when the spi transmit checks it.
And it's ready when it returns.
But then, at some point the return value randomly changes, by magic.
I will compare the oled routines against the older code, there's something weird going on.
The strange is that it fails very randomly.
Sometimes it works 20min, others just a few.
Or there's memory corruption by some wrong pointer or whatever, or I don't understand why.
It also happens with the graphics disabled, only updating the screen.
Edit:
I updated all the other boards. Ksger with software i2c should be ok, as they don't use the spi dma.
I don't know if the bug happens with the hardware i2c too.
I also added active power limitation. Before, it was a fixed value (0-100%) applied to the PWM duty.
Now it's limited in watts.
The iron routine takes the last power supply reading, the heater impedance (new option added in the menu) and the power limit setting, and adjust the max pwm duty.
This value is then applied to the PID calculation.
So, if you set 30W, the power will be always 30W, independently of the power supply voltage, as long as it's enough to apply that power into the load.
This wil be very useful, specially for low power tips. Each profile has its own power limit. By default: C245=150W, C210 and T12=80W
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1162714)
Edit 2:
Also made some changes in the graph so it will display temperatures between 200 and 500°C for better accuracy.
Showing lower temps is pretty useless. Also some other changes for increased stability/smoothness while not making it too laggy.
Now it's 7°C/pixel which should give enough precision to see oscillations.
About the iron detection: It's a shame, but hardware modding will be necessary in most cases.
The wake pin is usually not connected to an ADC pin |O
Edit 3:
Also, I don't know if it was a lucky shot or what, it's been running well for the whole night without crashing.
Latest build video:
https://www.youtube.com/watch?v=XDQdpYJrET0 (https://www.youtube.com/watch?v=XDQdpYJrET0)
-
i have 2 of the 3.1s units. both have boards inside that say oled v3.0 but they both have stm32f102 chips. is this compatible with those or only 101 and 103? hoping so! thanks
-
Yes, I didn't made for the 102 before as nobody asked.
Also, some 102 versions have 10KB RAM which was too low for older fw versions.
I can make a build for you to test if you want,but I don't have these boards to test, so please take in count that although it should work, and I will try to help with any issues that could appear, I won't take any responsibility, it's all at your own risk ;)
I need a picture of the actual board. Is it 48 or 64-pin? There is a crazy ammount of ksger boards out there.
Is it like this one but with a 102?
(https://www.eevblog.com/forum/reviews/ksger-t12-stm32-v3-1s-soldering-station/?action=dlattach;attach=909440;image)
-
yes that is exactly what it looks like pcb wise the actual part number on the chip is stm32f02r8t6 it is 64pin. i can take some pics today but its identical to that style. sucks i was hoping they were 103's. how much difference if any will it make in performance of the unit with these 102's seems they cheaped out on them i have not seen them mentioned to many places so im bummed i got them even though my orders for them were far apart time wise. is it worth getting 103's and changing them out at all if so which version would you recc. new to stm32 but im trying to learn as much as i can. not new to this type of work though. thanks again
-
Not really a difference in performance.
A little slower than the 103, but will work perfectly fine, 36 or 48MHz are a lot more than needed.
I will make a build in a while. Check later!
Edit: Done! try it out.
-
awesome thank you! will give it a go when i get done with work later tonight. will let you know, if i want to order some spare stm's in case which would you suggest i order?
appreciate it!!
-
About the iron detection: It's a shame, but hardware modding will be necessary in most cases.
Yes... it seems like that was always going to be the case. Due to certain difficulties. Hope that you do not feel too bad about that. What is important is that we can give a very clear instructions, examples. For how to correctly do the necessary hardware modifications. That is not going to be confusing anybody.
Latest build video:
Overall really impressive video. Amazed that you can do the graphing feature at all, on these low powered devices. And also the realtime bar meter along the bottom. It looks so responsive the updating rate. Really excellent!
A suggestion for the Main menu, because it has a really big text, which fills up the whole screen... You do not have to do that. Because displaying only 1 menu item at once, it makes it impossible to see how far to turn the dial for multiple steps at once. Seeking 1 step at a time is slower.
Instead f that... if you just use the exact same 4 line display as already in the submenus. Then it is possible to see where you are scrolling to. As then the screen can display the -1 before entry, and the +1 after entry. With the selected entry in the middle. This would be easier see more of the menu.
That was my only UI suggestion for this, as the default hardware configuration, I think? Cannot remember now.
My other suggestion requires hardware mod. To add 2nd, 3rd push button(s). Either for dedicated: up/down/ok/back navigation. Or for: iron on/off. Or to select a saved preset temperature with 1 click. Reason: because not everybody loves rotary encoders. If i can just press 1 button, by feel alone, and without having to check the display. Then can keep eyes looking through the microscope. That is faster.
Another one of my annoyances with rotary encoder: When you press in the dial to click. Sometimes it also rotates by accident. And selects the wrong item. Perhaps if we can duplicate the push button with re-wiring?To have a separate physical button just doing the same thing? IDK.
-
I would take the 103 which is the most common, but it's not extrictely needed
-
I would take the 103 which is the most common, but it's not extrictely needed
just be sure to buy it from a reputable source as the risk to get a clone is pretty high(rs-components,farnell,arrow,digi,etc), the problem is there is not stock anywhere , or wasnt a month ago or so.
-
The graphics are nothing trivial.
The power graph, is basically done by drawing few lines every 20mS to make it smooth.
And the temp graph draws 100 vertical lines every 100mS (10pixel/second).
This mcu can take a lot more! It's only a 128x64 monochrome screen. Also the DMA helps a lot.
The settings screen was removed to free some memory to fit within 10KB RAM.
As in the end I also changed a lot more things, I could free up even more memory.
I agree that the settings screen could be changed.
It might be still possible to restore the old menu. But I wanted something more direct.
The text is big because it's the same font as the iron error or sleep. To save space.
The settings options isn't a menu any longer, now it's a widget itself, so multiple options can't be seen at the same time.
There are only 7 options, you will get used to them in no time.
At first you'll want to touch a lot of options. You will see it's dead easy. Just get used to it.
Once it's working, the only options you'll ever use will be rise and lower the temperature, little else.
Set the temp step to 10ºC and in 2 turns you will have the whole range.
Sorry, but, if you don't like encoders, I guess you shouldn't buy a soldering station with encoder from the start :-DD
I know the encoder can be a little picky some times. Maybe I'll find the way to make it work better, but I blame the encoder more than the software.
I have 2 quicko boards, one works very nicely. The other has a defective encoder that fails like f**, working with it makes you want to smash it to pieces!
I totally understand your point of view. And all that can be done of course.
But I repeat my thinking: Only 1% of the people will actuall mess with soldering in these boards.
The whole wiget system is designed to work with the input of an encoder.
I would have to re-design everything, again! As I said, I'm not to up to the labour. I will have to spend a lot of time in something I don't need.
Adding physical buttons to my station, mix it together in the code so they don't cause problems.
Of course they will do, new bugs will appear, again a lot of time debugging.
Then doing it for every board out there, blindly because I don't have any of them. More and more testing.
And the stupid tips getting cherry red and burning everytime a new bug appears or whatever happens.
I'm not being rude or anything like that. I know it might sound like so, but I'm just being clear. Everyone wants their own custom version.
Ones don't like the menu, others dont like the font, others say its too big, others want lot of fancy stuff.
Well, I repeat, I wanted my firmware too, and I had to do it by my own.
I can bend my arm slightly, accept suggestions, but I'm not a programmer working for free, neither I feel pleasure from spending hours frustated, hunting bugs :-DD.
They might think doing this is like glueing easy parts together and it's not.
I'm doing all this alone and I'm pretty tired. The project is very far away from what it was at the start.
If anyone doesn't like it, use the crappy stock skger fw. Or the original PTDreamer version.
Hell, it's a cheap controller, not an advanced JBC station ::)
I will repeat again, this is not a new hardware project. It's a firmware for existing hardware.
Anyone can take the code and adapt it to whatever they want.
You can replicate the hardware easily with a blue pill board and few components.
There are dozen projects out there, some pretty nice, with buttons and a lot of stuff.
-
The settings options isn't a menu any longer, now it's a widget itself, so multiple options can't be seen at the same time.
OK understood. Did not realize this earlier. But looking in your code now... I can see how the menu is being constructed, with successive calls to add_widget(). So it would be a lot more work to change that menu. More than what I was imagining in my head. So sorry sometimes I forget how we do things in embedded C projects. Where many things end up being hard coded.
Sorry, but, if you don't like encoders, I guess you shouldn't buy a soldering station with encoder from the start :-DD
a defective encoder that fails like f**, working with it makes you want to smash it to pieces!
I love encoders! Just not for everything all of the time. But I take your 2nd point is so true, the pain is really felt most of all when the encoder is bad. When they work well it is not such a big frustration..
I would have to re-design everything, again! As I said, I'm not to up to the labour. I will have to spend a lot of time in something I don't need.
That is fine, it is not my intention to create a lot of extra work for you. I think the answer here is to understand how the theoretical idea of clicking a button is more complicated in reality. Than what it might seem. Which I did not consider. Things like:
* If the button is software debounced (by the MCU)
* If the GPIO is hardware interrupt, then it's going to interfere with other tasks
* If the GPIO is being polled instead. Which also requires the opportunity to poll, on a timer. And can miss the signal or otherwise interfere with other tasks.
Sorry for not realizing these details, and not thinking it through. Doing buttons would make extra problems as above. In one way or another. But especially when you are in a phase of maturing the software. I'm sorry to have brought it up again. You just keep asking for suggestions! And the rest is so good that I really cannot think of anything else.
Really I don't mind you rejecting these feature ideas, when it is clear that it would be difficult. It's my mistake for not bothering to check the code. And should think things through a bit more carefully what the complications might be.
And the stupid tips getting cherry red and burning everytime a new bug appears or whatever happens.
Yes this is very annoying. Doesn't stm32 platform have a watchdog timer for that? To catch when the mcu freezes. Or perhaps the feature does not exist on some chips. Or it cannot catch this situation?
For example: ...we cannot do something like this?
https://medium.com/@kunalsalvi63/stm32-window-watchdog-94bc0406ea51
I will repeat again, this is not a new hardware project. It's a firmware for existing hardware.
Thank you! Yes I was confusing exactly on this point. Which you made before, but I forgot. What has helped me in particular today was reviewing some bits of your latest code just now. To understand better the way it is written. In those specific areas.... and I did not have to look too hard! Because your C is pretty darn good. Very well written I have to say. It is pleasing to read the code.
But also the method that C requires of writing programs. Which does demand a certain way. It then makes more difficult to make certain kinds of changes on top. This is something familiar to C. And to get into the rhythm of it again. For a productive progress in a session, but without breaking things. I should leave you to it! (as much as possible)
Sorry also for distracting from your other discussions here. For the other boards oled v3.1 etc. That is a more important matter. Lets be clear! Back to that.
-
The fact that you can see how the code works is the main thing, now it's a child's game!
That is not a issue, and as I said I'm open to change the menu. But I neither liked the old menu so I have to think something.
My idea was to adding a centered combo widget in the center of the screen. I don't know it the rest of the widgets will like to share their screen with it, but I will try.
Nah, no sorry! I'm not angry or anything, not even close! I just was showing the point! :-+
It's completely normal to ask new features, however I'm actually completely frustrated with the stm32 ecosystem.
Very bad HAL documentation, weird bugs, etc etc... I'd love to add a lot of things, and the huge code changes where aiming to reach a stable and solid fw to work on.
Now, after all that work, a silly HAL bug appears and crashes the system without explanation. I've been trying at it for at least 10 days with no avail.
How do you debug a bug that appears every 2 minutes or 12 hours?
And it's invisible, passes all the checks detect with no problems. I would set fire to everything right now. :palm:
I will take a break for a few days. Then I will be probably fine, with renewed energy to put into this.
-
Ah so if i understand correctly: it is not MCU freeze then? But instead output stuck on?
In regards to HAL bugs and other issue surrounding HAL / IO systems: I was discussing elsewhere this matter a few days ago and the main finding was that f4 series (and newer) has different HAL that is much better than the older HAL previously for f103 and earlier...
However as we discussed though the F4 package (removed from a black pill) is generally 48 pin. Not 64 pin. So then that option is not so cheap / easy to replace on those 64 pin pcb versions.
But also perhaps another issue around bad HAL. Which is on counterfeit chips not being genuine and manufactured by ST. So the trick (in other thread, we linked before) to better identify the MCU by reading hidden bytes. It might actually make sense to check for this. To make sure the cpu id is genuine and not fake. Bearing in mind that these devices are made in China, and sold on aliexpress.
Yes it is a good idea to take a break. But also the purpose of taking the break is to have fresh ideas when you come back to it. And think differently about the problem. So that a different approach can reveal a different path of actions to take.
What i am saying here is that sometime I take a break for this same reason. But then never think to get the new idea. And therefore don't come back / don't enjoy to return to the problem. Because the situation is left in the same way and nothing has changed. So then I have no new ideas to bring back to the problem! And nothing gets solved. This is particularly true for these more difficult type problem, that is on a critical path. Because the fatigue is being caused not by the workload. But instead by the problem itself. It is being so difficult, which draining of motivation, enthusiasm.
We kind of have to fool ourselves. And just pretend 'well this is not so hard!' In order to forget that sticking point. And push the paper about a bit.
I saw this same exact thing happen to somebody else to, in another project. He kept getting kernel panics (in the linux kernel), the low level networking stack. So what happened? Well he wrote up all of the problem, and described fully everything into an issue. In the project issue tracker. Eventually, a few weeks / months later somebody else came along. And was able to make sense of it. And then the other guy could help, picked it up and was solving a lot of the bugs. And improve the code. That was a critical intermittent bug. It would crash the whole computer.
So I am not suggesting that can be the same solution here. But whatever you do, try to think differently about the problem. To find out about this elusive HAL bug. It seems rather mysterious. Search for links to resources. And searching online for similar bugs. For same mcu, same IO block, etc.).
I also want to ask a question about it: can we sort-of reboot the device. Well not reboot, but instead just re init() the IO block every N hours? For example when it is in idle state. This sounds stupid i guess. But then again if it is a real hardware bug. Then that is often the type of a workaround that makes sense. It depends what is triggering the bug. And the way that you are interacting with the HAL. I guess you just simply don't know.
In some cases it might make sense do realtime trace debugging. To try to catch somehow a unique signature, or 'clues' for what is happening. Either over the SWD bus, or the other debugging bus. I forget now what it is called. But there is some alternative ultra fast 2 wire bus specially for trace debug on stm32. Then again, you could spend all that effort and time setting up a hardware debugging trace back to your PC. And then if it is a low level hardware bug it just not show up anyhow in the trace!
:horse:
So please, don't listen to me for anything solid. They are just a few different ideas to kick around. Personally I would be trying google, different sets of keywords. Searching around for others with this same HAL bug. Looking for clues.
-
Hi just in case gives you any hint, the last git update reports the error in line 554.
-
Hi just in case gives you any hint, the last git update reports the error in line 554.
I know, I moved the set oled row to the interrupt itself, as I was doing before.
Its seems to crash less often, at least for me. It's the same crash, but in different place.
Ah so if i understand correctly: it is not MCU freeze then? But instead output stuck on?
In regards to HAL bugs and other issue surrounding HAL / IO systems: I was discussing elsewhere this matter a few days ago and the main finding was that f4 series (and newer) has different HAL that is much better than the older HAL previously for f103 and earlier...
However as we discussed though the F4 package (removed from a black pill) is generally 48 pin. Not 64 pin. So then that option is not so cheap / easy to replace on those 64 pin pcb versions.
But also perhaps another issue around bad HAL. Which is on counterfeit chips not being genuine and manufactured by ST. So the trick (in other thread, we linked before) to better identify the MCU by reading hidden bytes. It might actually make sense to check for this. To make sure the cpu id is genuine and not fake. Bearing in mind that these devices are made in China, and sold on aliexpress.
Yes it is a good idea to take a break. But also the purpose of taking the break is to have fresh ideas when you come back to it. And think differently about the problem. So that a different approach can reveal a different path of actions to take.
What i am saying here is that sometime I take a break for this same reason. But then never think to get the new idea. And therefore don't come back / don't enjoy to return to the problem. Because the situation is left in the same way and nothing has changed. So then I have no new ideas to bring back to the problem! And nothing gets solved. This is particularly true for these more difficult type problem, that is on a critical path. Because the fatigue is being caused not by the workload. But instead by the problem itself. It is being so difficult, which draining of motivation, enthusiasm.
We kind of have to fool ourselves. And just pretend 'well this is not so hard!' In order to forget that sticking point. And push the paper about a bit.
I saw this same exact thing happen to somebody else to, in another project. He kept getting kernel panics (in the linux kernel), the low level networking stack. So what happened? Well he wrote up all of the problem, and described fully everything into an issue. In the project issue tracker. Eventually, a few weeks / months later somebody else came along. And was able to make sense of it. And then the other guy could help, picked it up and was solving a lot of the bugs. And improve the code. That was a critical intermittent bug. It would crash the whole computer.
So I am not suggesting that can be the same solution here. But whatever you do, try to think differently about the problem. To find out about this elusive HAL bug. It seems rather mysterious. Search for links to resources. And searching online for similar bugs. For same mcu, same IO block, etc.).
I also want to ask a question about it: can we sort-of reboot the device. Well not reboot, but instead just re init() the IO block every N hours? For example when it is in idle state. This sounds stupid i guess. But then again if it is a real hardware bug. Then that is often the type of a workaround that makes sense. It depends what is triggering the bug. And the way that you are interacting with the HAL. I guess you just simply don't know.
In some cases it might make sense do realtime trace debugging. To try to catch somehow a unique signature, or 'clues' for what is happening. Either over the SWD bus, or the other debugging bus. I forget now what it is called. But there is some alternative ultra fast 2 wire bus specially for trace debug on stm32. Then again, you could spend all that effort and time setting up a hardware debugging trace back to your PC. And then if it is a low level hardware bug it just not show up anyhow in the trace!
:horse:
So please, don't listen to me for anything solid. They are just a few different ideas to kick around. Personally I would be trying google, different sets of keywords. Searching around for others with this same HAL bug. Looking for clues.
Yes, that was my idea. reset the spi and dma and maybe live with it. I'm too perfeccionist and I kept fighting to do in a clean way.
And the fact that didn't happen before is what crisps me more.
No, burning tips is entirely my fault. The normal users have nice protection methods.
When you are debugging for example a strange pid behavior, you need to have the real thing connected. And your stop the core iat certain point to check the variables.
The 99.99% of the times I do it right and remove the handle. The 0.01% that I get distracted looking at the code, and the tip PWM was set to a high value. After 5-6 seconds, say bye to the tip :palm:
Might I ask how to do a compare view of a file in 2 different versions, in github?
I've seen that only when that specific file was changed.
Ex. r2636 that file added a line. But since then, 300 commits were done.
So I have to search what was the last commit for that specific file. A total PITA.
Since the oled system and widgets routines are isolated, I can mix old and new the code pretty easily.
-
Might I ask how to do a compare view of a file in 2 different versions, in github?
sure no problem! It is very easy.
Actually there are 2-3 different mechanisms which you might find useful.
1) The Github Blame button. This appears when viewing a single file. And all you have to do is click it. Then it shows a special 'git blame' view mode. For every single line in the margin it gives the git comit (hash id). And the commit message. Which is a clickable link. So for from there, any line in a file you can jump to the original commit where it was entered.
If there are multiple changes (lines over written). Then the current git blame view will only take you to the last git commit when those lines were updated. But from there is also a special little icon to look back further through the entire history. (for that 1 line of code).
Another way is to click the 'parent' button to go back in the view, to the previously commit (-1). Which is then going to reveal whatever the previous code had already been replaced.
This is assuming that you keep a good git history. And a continuation. Git is usually smart enough to understand simple file moves, or file renames. So long as those operations does not skip over multiple commits.
Help for Github blame:
https://docs.github.com/en/github/managing-files-in-a-repository/tracking-changes-in-a-file
But that is not what you asked for. You asked for:
2) Github Compare feature
This is a hidden url, which you can access by typing:
https://github.com/username/repo/compare
For example:
https://github.com/deividAlfa/stm32_soldering_iron_controller/compare
Which lets you compare git branches. BUT that does not show how to compare individual commits. However branches and commits are all just different kinds of git Refs in git. So you use git-ish syntax in the url to specify a commit range. Which can be tags, branches or commits. Whatever.
For example to compare between several commits 'a725d88a' and 'ddcdacecd' you would type the URL:
https://github.com/deividAlfa/stm32_soldering_iron_controller/compare/a725d88a..ddcdacecd
Help for Github compare tool:
https://stackoverflow.com/questions/49837769/how-to-compare-two-different-commits-on-the-same-branch-in-github
And you are done! Well... not quite because you can also:
3) Click the "Create Pull Request" button. To use Github to generate a new open PR. This then also makes it possible to easily generate a .diff or .patch file between 2 arbitrary commits. The resulting text file then makes it very easy to re apply those selected changes from that diff into your working code. As it then becomes just a regular patch file
You take the URL of the pull request, for example:
https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/2
then just add ".patch" or ".diff" to the end of the URL:
https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/2.patch
https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/2.diff
In github... this can only be done for a pull request. Or for a single commit. Unfortunately it cannot be done from the /compare view.
But you can just go ahead and click the "Make PR" button. Then delete the PR when you are done with generating the patch file.
Reference: https://stackoverflow.com/questions/6188591/download-github-pull-request-as-unified-diff
You will find github is a very powerful tool, for searching back in the history. If you also want to do things locally, you can do all the same operations on your local computer too. With other software tools, such as smartgit or the git command line. I also find that Beyond Compare is great tool. For comparing 2 folders outside of git. When they are not properly versioned.
Hope it helps! Good day.
-
ill mess with min again tonight after flashing it appeared to have nothing at all loaded. ive flashed stm's before i just ran out of time last night, one question is the 101 in these cases not as good as the 102 stm chips? i found someone local with a handful of new 101's i know they run at a bit slower speed then the 102 generally though i have to check to see which 101's they are
-
101s will work correctly too.
The main problem is that I can't test these boards. It's done looking at the specs. Any little thing wrong can make it fail.
I will look again at the schematics and see what could be wrong.
-
he has 101 and 102 chips which is why i was asking he said i can take which ever of them i need for nothing but asked which ones i want they are both rb or r8 revision so i assume the 102 with everything else being the same for the slightly faster clock at 48mhz. i saw the 102 offered usb where the 101 doesnt but i dont see that being needed here
im going to reflash it later and see it could be on my end i was in a hurry last night as we had a family member pass and i had to leave in a hurry.
-
Yeah you could replace them, specially to not lose the original firmware.
As I said, the 3.1 board is currently untested.
It worked some time ago, but since then I hadn't more opportunities to try it.
I depend on other people to debug these.
For the ksgers, cosmin1 let's me connect remotely and use his computer to debug the boards.
That's how I got the 2.1s to work. He also have the 3.1 but we don't coincide very often.
Now for the 3.1 could be anything, and without debugging it's very hard to find.
If you have st-link and a moment I could try to setup the code and debug remotely using TeamViewer.
I have no dark intentions, but I don't have any other alternative to fix these.
Edit: Well, I tried to use the same display abort routine I use to update the screen when a "panic" error happens.
And it seems to be working. I don't like it to be happening in first place, but at least now it can continue working after the error.
Code updated!
About the performance questions being asked recently: I tested different speeds, and this is what I found.
At 8MHz it crashed, I guess because it was too slow to finish some interrupt before the next call (overrun).
10MHz and upper worked perfectly fine (With SPI DMA). The menu navigation was a little slow but still pretty good.
The main screen, graphs, temp drawing were doing perfectly. So I wouldn't worry.
Software-updated display will be noticeable slower, but anyways I think they will work well with +36MHz devices.
The graphics system won't affect the pwm and such, as these are interrupt driven.
The display might get updated quicker or slower, but the PWM/ADC/PID will be always working normally in the background.
And this is with compiler optimization set for size (Os). With optimization set to "more" (O3) it gains a 25-30% performance at cost of higher flash usage.
128KB devices can use this option without problem. 64KB ones...definitely not.
Dreamcat... I've been checking it. Sorry, all I can say is I hate it, so damn complex, I don't understand why.
Maybe linux lovers like to be typing into a black console for every little thing. I find it anoying!
We are in 2021! Make a simple gui for the everyday use, and the leave the console for what it really is for, fixing something when you screwed it up badly!
They should make the advanced part for anyone who wants to use it, but also a more simple package for normal people.
Like the old SVN. I see I'm not alone :-DD:
https://ohshitgit.com/
-
terminal like interface is good when you know what you are doing, i can definetly increases productivity, but on the other hand you end up erasing your fake stm32 in a blink xxdd, i dont like the button in the encoder because they are shit , period, but the encoder makes it straight forward and its already there.i can live with some ghost clicks.
which connector would you guys use(mount on the case) to connect the stand? mb wifi coax, i cant think of a sturdier small connector.
-
Yeah for the ghosting I think it could be fixed somehow by software.
Anyways, I thought the encoder had filtering capacitors. It doesn't. That will cause a hell of switching noise.
The encoder is read at systick frequency, 1KHz. Before it was interrupt-driven and would catch all that noise..
I don't know you, but only problem are the fake clicks. You push it once and it does like 2 consecutive clicks.
Then I also have the screwed encoder that doesn switch correctly between rotation positions and causes weird issues, like nothing at all working until you move the encoder to a stable position.
I will try adding an internal reset function. If the encoder doesn't move for 100mS, reset the position if it was in the middle.
Also don't send buttons clicks if the last one was less than 100mS ago?
The fix seems to be working. All night on, no errors.
I found is that it seems to happen more often if you trigger the handle sensor a lot.
Touching it floating, causing it to catch the 50Hz mains noise, caused the failure a lot quicker, within 30 seconds usually.
The STM32 IDE kept going slower and slower, and the system stuttering like hell althought no visible CPU, SSD or memory use was going on.
I guess one of the thousands weird things I installed didn't go well. I ended reinstalling the whole system, it's like night and day!
It seems to be a computer now, instead of a gameboy!
-
yes sometimes the push is not registered and others a double push :-DD but most of the time is ok , rotation always works fine. ill pull and compile new one later and report back. :-+
-
Okay, now I'm officially out for a while. Managed to break an OLED corner while replacing the encoder! :palm:.
It still can be seen partially... looks interlaced, half of the horizontal lines are dead.
Added the delay. Seems to work better. No more double clicks here.
-
ill mess with min again tonight after flashing it appeared to have nothing at all loaded. ive flashed stm's before i just ran out of time last night, one question is the 101 in these cases not as good as the 102 stm chips? i found someone local with a handful of new 101's i know they run at a bit slower speed then the 102 generally though i have to check to see which 101's they are
Well, maybe the display info is wrong.
These oleds usually have either 4 or 7 pins (I2C or SPI). That KSGER has a weird 6-pin display with no CS line.
It's very strange that a SPI device has no CS line. I found these displays being described both as i2c and spi in different sites, which seems contradictory.
I smell i2c here... So I made test builds with both modes. Test them, luckly it will work.
Edit: For cosmin seems to be working? (V3.1 with 103RB) Try these files and report.
There are 3 builds: Hardware spi, software spi and software i2c. At least one should work!
-
Correct me if I'm wrong, but I believe that the OLED display itself, is supposed to be capable of both ways either SPI or I2C. However the newer ksger models use it in I2C mode. Instead of SPI mode.
So the lack of a CS pint should not matter... but even if you wanted to use the 6 pin display in SPI (for a mod, or in a different product). The spi protocols only uses CS when there are multiple devices sharing the same SPI bus.
So you can use SPI without the CS pin... however you then cannot daisy chain extra devices. So my guess: maybe the display does this to force the user to avoid a situation where it shares devices on the same bus. To make sure the data bus is kept free for updating the display only. Without loss of performance or being interrupted. IDK.
Wait what am I saying? You do always have minimum 2 devices on SPI bus. The other one is the STM32 mcu. However because it is a display, it only needs to receive the display data? Then it does not need to transmit back to the MCU and send the other way. Except for something like an ID string, to identify the device. However the MCU does not need such reply, if the firmware is coded to already know which model the display is.
-
Yes, the controller is capable of all these modes.
But not at the same time, neither can be freely chosen at any time, it's configured by setting a pin to 0 or 1, usually with a resistor within the board.
I2C bus has addressing so it doesn't need chip selection.
Spi doesn't, so it usually has cs, otherwise you will have to dedicate a interface to only that device, which is a total waste of resources.
In I2C mode, the DC pin is used as LSB bit for addressing, so you can use 2 displays together in the same bus.
The oled pins were correctly configured in the firmware and as I don't have the hardware, I have no clue what's there.
If it didn't work in spi then it must be i2c. If neither, well, I can't help further. Needs debugging.
Edit:
I restored the old settings menu. RAM still has 800 bytes left (9.2KB used).
The encoder still had some false triggering, I added another debouncing timer.
-
ive been trying this morning yesterday's version and the screen bug its still there, dont know if it should be solved or not. :-+
-
Are you sure you got the update? Both 072 and 103 have been working correctly for more than a day here.
If it puts the same line number error, it's definitely not updated.
I found the transfer completed callback might be called without having actually having finished it.
Why the hell do you call it "transfer completed callback" then?
I'm polling it before sending the row command, I'll leave it running and see if it crashes.
This HAL library is total mess.
If you poll for a dma transfer, and it finished before doing the polling, instead returning ok, it returns error.
It also returns error for true errors, so they couldn't have done it worse.
Wtf ST. Do you use monkeys for programming the HAL?
Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.
-
This HAL library is total mess.
Hey, just found this 40 pages of errata pdf. It should describe in here all of the known hardware bugs. Might be worth the time reading
:-//
https://www.st.com/resource/en/errata_sheet/cd00190234-stm32f101x8-b-stm32f102x8-b-and-stm32f103x8-b-medium-density-device-limitations-stmicroelectronics.pdf (https://www.st.com/resource/en/errata_sheet/cd00190234-stm32f101x8-b-stm32f102x8-b-and-stm32f103x8-b-medium-density-device-limitations-stmicroelectronics.pdf)
[edit] be aware: "medium-density" = 64 pin version.
So there must be other errata documents for the 48 pin count ones, f072, etc
-
Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.
Is this with i2c bus? Could it be same problem as this other guy found?
https://www.programmersought.com/article/71326761904/ (https://www.programmersought.com/article/71326761904/)
-
Are you sure you got the update? Both 072 and 103 have been working correctly for more than a day here.
If it puts the same line number error, it's definitely not updated.
I found the transfer completed callback might be called without having actually having finished it.
Why the hell do you call it "transfer completed callback" then?
I'm polling it before sending the row command, I'll leave it running and see if it crashes.
This HAL library is total mess.
If you poll for a dma transfer, and it finished before doing the polling, instead returning ok, it returns error.
It also returns error for true errors, so they couldn't have done it worse.
Wtf ST. Do you use monkeys for programming the HAL?
Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.
im pretty sure, but ive flashed todays last commit and no problems so far in last 2 hours,alot of hours later still going strong
-
Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.
Is this with i2c bus? Could it be same problem as this other guy found?
https://www.programmersought.com/article/71326761904/ (https://www.programmersought.com/article/71326761904/)
It was with spi but I think it's dma related, not spi .
Anyways if checking by that it works, it's done.
Edit: Only checking the DMA didn't fix it. Got few crashes.
Reverted the fix to the previous one.
-
Hello. I flashed my board with version [v3.1] / [64pin] / STM32F103RB. Got artifacts on display, vertical bar on the left. Probably need a different display driver. Can you edit the firmware?
-
Go to settings, system and adjust offset to 0.
Some display have different offsets, by default I set it to 2 because that is what my display use.
-
Definitely, sometimes it catches the dma not having finished yet.
So I guess the problem was that. But totally confuses me why it gets into the interrupt before it really finished the transfer in first place.
Is this with i2c bus? Could it be same problem as this other guy found?
https://www.programmersought.com/article/71326761904/ (https://www.programmersought.com/article/71326761904/)
It was with spi but I think it's dma related, not spi .
Anyways if checking by that it works, it's done.
Edit: Only checking the DMA didn't fix it. Got few crashes.
Reverted the fix to the previous one.
If it is SPI then maybe it's on page 28 of the errata then? (image 1) Or it could be a conflict, when multiple IO devices are used together, in a specific combination (image 2)
-
I don't see relation...
SPI is not used with CRC enabled. That is usually used for SD cards (Frames are ended with CRC checksum).
Neither do I2C and SPI coexist. One of them is totally disabled.
I don't know if it happens in I2C mode. I only had that problem in my boards (And Jesus's), using SPI.
Definitely there are no more crashes, running for 3 days now without any issues. So I wouldn't bother.
-
Hi, a weak ago the firmware work well with me but days ago i saw you update the code so i flash my board with \KSGER\[v3.1]\[64pin]\STM32F101RB and nothing boot up i think u just change the pin the oled is PB 13, 15 OLED_SDA, OLED_SCL (schematic) to SPI2_MOSI, SPI2_SCK. Maybe this cause my board don't work? Sorry i don't have knowledge about stm32.
-
Let me check it.
These names don't matter if using spi/i2c in hardware mode. Only used in software mode.
-
Hi, will STM32F101RB firmware work for STM32F101RC ?
-
Hi, will STM32F101RB firmware work for STM32F101RC ?
is it the same board, if so yes if not no
Also oled does not work on last version in github quicko f072 with provided bin neither with compiled,still have to test f103.
-
I have to discard possible display compatibility issues from the latest changes. Also I had placed some preprocessor #ifs incorrectly.
Jesus, please try these. My 072 board is currently removed and the display desoldered, so I can't test it. My 103 works nice.
-
Hi, will STM32F101RB firmware work for STM32F101RC ?
Yes, using the same family but bigger memory variant should work just fine.
-
I have to discard possible display compatibility issues from the latest changes. Also I had placed some preprocessor #ifs incorrectly.
Jesus, please try these. My 072 board is currently removed and the display desoldered, so I can't test it. My 103 works nice.
none of them work xd , the provided bin in this commit does:
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/353a33fa8c2028d5d089bec4cbf956efd5a71cf0 but seems its even older,as its 6 days old
f103 works perfectly as you said. Also the encoder is super good(va fino fino).
-
What the... :scared:
For the Ksgers: From now only the STM32F101 will be built. It will also work in 102 and 103 (but all running at 36MHz).
I can't lose so much time updating everything everytime while there's no real difference in performance :P
I uploaded new builds. Didn't see any problem really. Litte comestic bugs in the error screen, nothing else.
Stm072 works fine for me! (Yes, broken screen) Flashed exactly the same binary from github.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1167006)
Edit: Nice that it goes "fino, fino" :-DD
-
now works with the last pull
i have tryed also in windows and cant get it to work |O , ont know what could be happening :-//
There might be a bug regarding the stand(just fyi i replaced the resistor so the tip is grounded), the stand is correctly detected but if i boot with the tip touching the stand sleep mpde is not triggered until i get the iron and place it again in the stand.Also tip type selection is missing ajajajaj
also it is not a problem for me if you dont provide bins for the quicko if it saves you time, or if you want to stick to f103 or f072 as i have spare of both and can solder either.
-
@DAvidAlfa, thank you very much for all the work you are doing. It is much better than the original code.
The edit tips menu is not only the name... each tip have its own pid data, max power... ;)
The specific tip pid settings are loaded when you change it, and pid control uses that data.
Then each specific profile (T12, C245, C210), has its own pwm settings, adc delay and few others.
I suggest that when creating a new tip, tip info (calibration, PID, power, etc.) should be copied from the first tip (e.g. "DFLT"). That lets you make settings once for DFLT, then just make small changes when adding new tips.
Now the main task would be to collect calibration results from different boards and set them as base into the firmware.
So anyone could use the firmware without huge temperature differences if not calibrated.
I just loaded the latest .bin (r2135e11) on my KSGER OLED-3.0 (103RC). When calibrating (T12 tips), these were the readings I got 130@200, 219@300, 288@400.
One problem - when set to use Fahrenheit, the calibration doesn't work correctly. It will show "CAL STEP: 200", then "WAIT... " with the temperature in F (but shown as C!). i.e. if I set the temp to 390F, then go into calibration, it will show "WAIT... 390C", and waits until the tip drops to 200F (displays 200C). But the tip is actually cold then. It is probably easier to just try it yourself than to understand my explanation.
-
my stlink may have an issue i tested it on something else and i had a simiar issue to the ksger f102 so i ordered in a few new ones should be here early next week sorry for the delay
-
Calibration -must- be done in Celsius, the fw works in that unit internally. Farenheit support is done by converting that.
I see that I forget to force the system to use Celsius when entering calibration screen, and restoring it back when exiting.
That happens when F is not your everyday unit. Farenheit mode is no extensively tested.
Fixing that soon. About the tips, not a bad idea. I will have a look at that.
Your build is already old! Try the latest (r52bc1a1) and confirm that it's working ;)
-
What are the exact issues? Most have easy solution.
The usual issue is when you flash a corrupted fw or one that doesn't have SWD enabled.
After that, stlink won't be able to flash it again without connecting NRST.
You can still fix it easily by shorting the reset cap with the tweezers, then clicking Erase command, and releasing the tweezers 1 second later.
The timing need some practice. Or just solder a wire to NRST.
-
also it is not a problem for me if you dont provide bins for the quicko if it saves you time, or if you want to stick to f103 or f072 as i have spare of both and can solder either.
Oh the quickos are just 2 versions with very different processors.
The problem comes with the ksgers. For only 2 boards, already 5 builds.
Mostly the same (101,102,103) but it's a tedious process to repeat the same thing everytime.
And since the 101 works in 102/103, why bother so much ;D
-
just blank screen. i have flashed stm32 before so i dont think im doing it wrong. it looked like it finished and everything went fine but no power after just appears to be dead. this stlinkv2 i opened and the soldering is total crap and it has a cks chip on board it was given to me so who knows. i went ahead and ordered a pair this seller swears these should work fine they have great reviews. for the few bucks no sense in beating around id rather start with a new one.
i was going to go ahead and solder on a new chip to this board. ill try the erase first when the new stlink's arrive before doing that, i do have a few spare stm's here now though if need be. looks like tues according to the tracking number.
-
Your build is already old! Try the latest (r52bc1a1) and confirm that it's working ;)
Oops, that doesn't work. It just flashes the splash screen (constant reboots?)
Using the file here: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv3.1%5D/%5B64pin%5D/STM32SolderingStation.bin
Memory programmed in 4s and 680ms.
Verification...OK
Programmed memory Checksum: 0x004D2FBE
Went back to r2674313 (which I had a copy of), back to normal.
-
Yeah my stlink came like that. Bent pins, floating on top of the solder. But I gave it some love with flux and it's working nicely.
If it verifies correctly, then it should be working. Otherwise it should give some error.
-
Your build is already old! Try the latest (r52bc1a1) and confirm that it's working ;)
Oops, that doesn't work. It just flashes the splash screen (constant reboots?)
Using the file here: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv3.1%5D/%5B64pin%5D/STM32SolderingStation.bin
Went back to r2674313 (which I had a copy of), back to normal.
Actually the default calibration values are set very low intentionally to avoid burning the tips.
I don't have those boards, I can't test them, so, as I always say, I prefer to be safe than sorry.
The measured temp is not what I need for the calibration, I need the ADC reading.
I modified the calibration screen to show these values after a successful calibration.
With those I can set a default calibration for each board.
About the bootloop, I already knew it existed. It didn't happen often, and when it did so, it was always after a flashing procedure, so I blamed the flashing...
But I found the issue. It happens when the system settings changes (when new settings are added), or the checksum fails.
The system settings were loaded, checked, resetted and saved before loading the profile data. But all must be saved together.
So the system profile was empty in that moment. Storing the settings would also store that empty profile, computing a correct checksum.
After that, it would bypass all checks, causing a bootloop. The main issue was loading the PWM with 0 data.
That breaks the pwm, the system watchdog stops updating and resets the system. Good boy doing its work ;D
All that should be fine now. Calibration screen is fixed. And new tip data copies the data from the first tip.
Will upload the code and the new builds in a moment.
-
I'm almost done fixing the calibration and copying the tip data for new tips.
Also, the measured temp is not usefull here. I need the ADC reading for puttong that into the database, so i can set the most accurate calibration by default.
I modified the calibration screen to show these values after a successful calibration.
Resetting to default fixed the reboots. Thanks.
I can provide the cal data, I'm assuming it will be shown in a future version, r52bc1a1 doesn't show it. In a previous post you mentioned deliberately making the default low, I agree. I don't know how much variability there is with these, but ~20C low seems reasonable. I'm seeing 100C low now.
Another suggestion: when doing a calibration, start with the defaults. Right now, it seems to start with the existing calibration. I recalibrated a tip, and ran into an issue where it couldn't reach what it thought was 400C, so ended up with a "red" tip. I had to delete the tip and recreate it.
Also, some tips will heat up, show "NO IRON", recover a few seconds later and repeat for a while until settling down. I seem to be able to fix that by setting "Iron/No iron" to 4100 (from default 4000). Perhaps it should be allowed to be set even higher?
Finally, and this is NOT important, just cosmetic. Menus say "BACK" except SYSTEM, which says "RETURN". You can save a couple of bytes and make it consistent.
-
Correct, I forgot about that issue, it happened to Jesus.
As you can't reset that, after some wrong calibrations you end with too high values that migh be impossible to reach. I will set always a default value.
About the no iron error: It's a tip fault, very common. Something's wrong inside the TC sensor.
Some people say it's moisture, while others think it's a poor internal connection.
I had issue that with most T12 tips. Leave it running at 400ºC... it usually settles after a while.
The ADC can measure between 0 and 4095, being 4095 is the max supply voltage (3.3V).
Anything over that will totally disable iron detection. That's why the 4100 is there.
If the ADC reads so high, it's because the circuit is open or not working correctly.
I decided to delete the T12 tips. Leave only one with the default profile.
These calibrations are not valid, as each board has different variations.
-
Ah, I didn't know what the "No iron" value directly represented. Odd that it will still detect NO IRON when set to 4100 - although it takes a few seconds (can EMA/DEMA overshoot?). I'll try setting it a bit lower.
Thank you again for all your work. It is appreciated, and you're doing good work. I've done projects for myself, just for the satisfaction and learning, but without much interest from others. I understand how and why you'd want to simply stop when it's working for you. I hope you stick with it for a bit more, you've added a lot of value and improvements to what we started with.
BTW, the board I have is marked OLED-3.0. I think it's electrically identical to a 3.1 board (I have one of those, too), but they moved the pads for the on-board battery and the off-board battery connector.
One other thing I've noticed - the button doesn't always work in the menus. When that happens, it simply stops working (I can press multiple times, hold it, etc., nothing) until I scroll up/down, then it works.
-
If you set it to 4100 and no iron is still there, check the ambient temperature.
KSGERs usualy have the ambient sensor in the the handle.
If unconnected, the ambient temperature reading will be below -60ºC. That also triggers the detection.
With the default 200mS PWM, the tip only gets updated 5 times per second. Setting a high EMA/DEMA factor will make the filtering response very slow.
Leave it in AVG by default. Set the temperature and play with settings until there are no spikes or anything weird.
Then you might try the other filters.
EMA causes delay at the filter output, and will cause PID overshoot.
If done correctly this can be beneficial, to compensate the tip thermal mass (Heat doesn't travel instantly from the heater to the tip),making it to heat faster without real overshoot.
However, when the tip gets cold, it also causes delay so the PID will not react so fast.
DEMA also has delay, but will react faster to the changes.
It will stop the PID faster when it reaches the temp, but also when the tip loses heat.
Check this picture (Blue line: original signal, orange line: regular EMA, red line: DEMA.):
(https://www.norwegiancreations.com/wp-content/uploads/2016/08/dema3-1140x641.png)
As you see, this can affect the PID a lot. Must be carefully tested, it can cause serious oscillations.
I wouldn't use it with a factor higher than 2 by default.
Also, did you play with the ADC delay? Setting it too low will cause a lot of trouble, false readings and such.
If you lower too much, the ADC will be reading the voltage spikes after turning off the heater.
By default is set to 200mS PWM, 20mS delay, it was the most stable, safe and efficient.
Builds updated!
No more random bootloops when the settings version changes.
Calibration should be doing well now. Also the ADC values are shown when successful.
Added more checks to ensure the calibration values never get higher than the ADC range, otherwise set the calibration failed.
Hopefully this was the last issue with red hot tips. The only red hot things I like are the chili peppers ;)
-
That must be it - I was testing further by unplugging the handle, and with "NO IRON", the ambient went well below 0. Although, it will bounce between <0 and 99.9C for a few seconds. Not an issue, just an observation.
-
OK, latest .bin (r61b02cd):
Calibration...
Deg C
200/134
300/188
400/273
ADC:
200/1641
300/2499
400/3626
But, now getting "EXCEEDED 500C! ERROR!!" when setting to 700F. I can avoid that by starting low, and increasing the temp slowly (10F steps, waiting for it to "catch up" each time). Guessing something is watching unfiltered temps, and picking up spikes, plus a C-F conversion? Doesn't happen when set to use C and setting to 370C (~= 700F).
-
Ouch. Yes, that check is always compared with 500.
I forgot to check if the system uses F haha...
-
Wow, I wasn't expecting an answer so soon. Do you sleep? It's in the middle of the night in Spain. If I were a better programmer (and understood Github better), I'd contribute that way. Perhaps I can contribute by documenting the settings better, to help others?
-
Yes but it's Saturday, and I have no other plans else than sleeping and eating during the whole weekend :-DD (Covid quarantine)
Fixed that, try it out :-+
Did you say that it also happens also in ºC mode?
The runaway check has different timeouts. If the PWM is actively applying power to the iron while the temp is over 500ºC, it will shutdown in one second.
There are also other runaways levels, with different timeouts (+25ºC for over 20 seconds, +50 10 seconds ,+75 3 seconds, +100 1 second).
This ensures that the PID or anything else doesn't go crazy setting the PWM out of control.
I neither understand github. I only know how to commit and little more! The day that something goes wrong I will have to call few guys here...
Yeah, I know the documentation is... well, there isn't. Since the firmware started to grow and more options added, now it really needs proper instructions.
-
ill go over the stlink tomm and touch up all the pins and things and try again. either way i have two more coming that are supposed to be better quality we shall see
-
(Covid quarantine)
Did you say that it also happens also in ºC mode?
Works in F now, good job. (I should use C, but 50 years of habit ;) )
It did not happen in C mode. I will test it more tomorrow, but right now it works OK.
Thank you.
-
ill go over the stlink tomm and touch up all the pins and things and try again. either way i have two more coming that are supposed to be better quality we shall see
I guess you are using st-link utility? Does it recognize the STM32?
Does it show the memory contents? If so, I doubt it's a stlink fault.
First, try to do a full erase, and then check for blank content. I had a stm32 with defective flash and that way is how I noticed the problem.
If that works, open the bin file and flash it. If there're no errors, the issue might be other.
Is it the KSGER 3.0?
Works in F now, good job. (I should use C, but 50 years of habit ;) )
It did not happen in C mode. I will test it more tomorrow, but right now it works OK.
Thank you.
Nice! Are the calibration results consistent every time?
Those values seems pretty high, since the KSGER have lower amp gain than Quicko... I don't remember having such high values.
Keep an eye at it, maybe the sensor is "unripe" and reports different values, it might drift with the use.
It would be interesting to check the sensor output variation after some burning time.
I remember Jesus having calibration of 1700 @ 400ºC. My last calibration was 3100.
I'm currently without iron tips, I hope they arrive in 1-2 weeks, for now I can't test anything.
-
Thank you for your updating, i really appreciate your work with this firmware.
But on new update I found a problem about the screen on SW: r7b29f04, HW: KSGER30F101.
When turn on with "No Iron" the screen just display for 5 seconds and turn off (just screen off) then i plugged the iron in, the board know and heat it but the screen still off. This prolem is same to sleep mode, shake to wake but screen no wake up.
There is the video demonstration: https://youtu.be/9cyWZL-GL-4
-
Seems to be a problem with the brightness control and that specific display.
These oleds mix ssd1306, sh1106 and other compatible controllers, but can have little differences when doing specific adjustments.
Anyone else having this issue?
Yes, after 5 seconds in sleep or no iron mode, the screen dims to protect the oled, as staying with static picture for long times can cause burn-in, but shouldn't turn off completely.
After returning to normal mode or on button activity it goes to full brightness again.
First, update to the latest version on GitHub(current version r61b02cd) and report if the issue is still there.
The number doesn't represent a higher or lower version. It's the code revision used to built it. Changes completely every time.
-
Thank you for your updating, i really appreciate your work with this firmware.
But on new update I found a problem about the screen on SW: r7b29f04, HW: KSGER30F101.
When turn on with "No Iron" the screen just display for 5 seconds and turn off (just screen off) then i plugged the iron in, the board know and heat it but the screen still off. This prolem is same to sleep mode, shake to wake but screen no wake up.
There is the video demonstration: https://youtu.be/9cyWZL-GL-4
I recommend you erase the mcu and flash it again after that.
-
Thanks to the screen, everything worked out, I set the offset to 0. Now there is a new problem, when setting 480 degrees, the controller heats up the tip much higher, I saw the temperature more than 700 degrees. Then it shows "no iron", and returns to 480 degrees
-
Did you properly calibrated it?
These cheap tips usually fail when new, causing reading spikes, but the real temperature is not that, it's impossible to reach 700°C in 1 second unless connecting the tip to 240V :-DD
Also, if the tip was really so hot, it wouldn't cool down that fast.
See previous posts talking about that issue. It happens with all controllers, all firmwares.
Set it to ~400 for a while. It will evently stop doing that.
Ohh, we need a FAQ urgently...
For now, always reset all settings when changing the firmware, there many changes lately
Also, ensure to use the latest firmware and reset the settings before reporting issues.
-
I did not calibrate the tip. I haven't gotten to the thermocouple yet. I have been using this soldering iron tip for a year and a half, it is not new. I did a full reset. Problem still exists. I downloaded the firmware two days ago. The temperature is real because the tip turns black quickly, the tin layer burns out. It does not gain 700 degrees in a second, but in 10-15 seconds, and then also slowly cools down.
-
Yeah, but this is in active development. Changes are made almost everyday. Only yesterday there were 4 builds...
By default the real temperature will(or should) be much lower.
Until I get more calibration feedback from users.
Try other tips. I had both issues with new tips and old tips that started to fail after some use. T12 market is wild.
It's weird that it heats so much.Test the latest fw and report.
-
It used to work well with older firmawre (before you adding ksger stm32f102). This is lastest version.
I recommend you erase the mcu and flash it again after that.
I have erased the mcu and flash it again with lastest version, reset all setting, the problem still there.
-
Try something. Enter the settings and adjust the brightness.
Does it dim until the minimum brightness or does it suddenly turn off at some point?
If not, then it's a recently added command for more brightness what's causing the issue.
Try the attached FW. I removed that specific command.
It must be something with that display. Other v3.0 KSGERs don't have the issue.
-
Try to change brightness til minimum and it still off.
Try the attached FW. I removed that specific command.
Sorry i'm new at this, how to flash with .bin file? just adding to folder or adding and removing the old file
It must be something with that display. Other v3.0 KSGERs don't have the issue.
It's weird, it worked well with the your old version.
-
I think you didn't understand. I mean that while in the settings and adjusting the brightness, does the screen dim until the minimum brightness? From 255 to 5 it's always on but less bright?
How did you do with the previous fw? Did you build yourself?
Download the st-link utility, erase the mcu, open the bin file and program it.
-
I think you didn't understand. I mean that while in the settings and adjusting the brightness, does the screen dim until the minimum brightness? From 255 to 5 it's always on but less bright?
I take your point. From 255 to 5 it's always on but less bright, doesn't dim at minimum brightness.
How did you do with the previous fw? Did you build yourself?
Download the st-link utility, erase the mcu, open the bin file and program it.
Thank you! Yes i built fw myself. Didn't know what to do with .bin file now i get it. Problem is solved.
-
just flashed the newest firmware, the problem remains. the ksger firmware tip is working fine. https://www.youtube.com/watch?v=jciOhP4WuSA (https://www.youtube.com/watch?v=jciOhP4WuSA)
-
Nice! Are the calibration results consistent every time?
Those values seems pretty high, since the KSGER have lower amp gain than Quicko... I don't remember having such high values.
Keep an eye at it, maybe the sensor is "unripe" and reports different values, it might drift with the use.
It would be interesting to check the sensor output variation after some burning time.
I remember Jesus having calibration of 1700 @ 400ºC. My last calibration was 3100.
I'm currently without iron tips, I hope they arrive in 1-2 weeks, for now I can't test anything.
OK, using current code (r7b29f04), I did full reset, then calibrated 3 different tips:
200/1461
300/2176
400/3013
200/1388
300/2046
400/2626
200/1390
300/2043
400/2640
-
Nice! Are the calibration results consistent every time?
Those values seems pretty high, since the KSGER have lower amp gain than Quicko... I don't remember having such high values.
Keep an eye at it, maybe the sensor is "unripe" and reports different values, it might drift with the use.
It would be interesting to check the sensor output variation after some burning time.
I remember Jesus having calibration of 1700 @ 400ºC. My last calibration was 3100.
I'm currently without iron tips, I hope they arrive in 1-2 weeks, for now I can't test anything.
OK, using current code (r7b29f04), I did full reset, then calibrated 3 different tips:
200/1461
300/2176
400/3013
200/1388
300/2046
400/2626
200/1390
300/2043
400/2640
Thanks. 200-300ºC seem close, however at 400 it's very different.
I guess what the temp is when using the 3000 calibration with the other tips.
If doesn't make a huge difference (420-430) then I might take the middle, 2800, as the default 400ºC calibration.
Thank you! Yes i built fw myself. Didn't know what to do with .bin file now i get it. Problem is solved.
So the screen dims normally now? I'll remove that command then.
-
just flashed the newest firmware, the problem remains. the ksger firmware tip is working fine. https://www.youtube.com/watch?v=jciOhP4WuSA (https://www.youtube.com/watch?v=jciOhP4WuSA)
Huh.. no idea, I can't try myself until I receive the new tips.
Did you modify any system option, like filtering modes? Leave everything default for now.
Set the PID Ki/ Kd to 0 and check if the problem still happens.
-
Cant select B profile, there is no menu for it and dflt is unusable, is there any way to change it as i cant find it anywhere in menu. Also cant open debug menu.
-
The default tips are gone, as they were all the same with different names.
Now, to select the tips press and rotate
I already told that, debug menu was removed to save ram.
You can add it again by uncommenting a define in screen.h
Why is the DFLT unusable? All the tips are the same...
-
very low stability(set to 300 and keeps rising until no iron and down) but as you said B and dflt are the same i have no clue, the tips are well used and should be pretty stable, will keep an eye on it and report back.
-
Thanks. 200-300ºC seem close, however at 400 it's very different.
I guess what the temp is when using the 3000 calibration with the other tips.
If doesn't make a huge difference (420-430) then I might take the middle, 2800, as the default 400ºC calibration.
It is all based on using one of those cheap Chinese clones of a HAKKO FG-100, but I think it's reasonably accurate. I suggest staying on the low end. Better colder than hotter as a default.
I replaced the (unknown) op-amp with a good one (OPA317), then re-calibrated one tip. The result wasn't much different.
One new suggestion - a long press takes you into Settings. Make is so a long press from anywhere in Settings takes you back to the main screen. That would eliminate the need to scroll/back out through menu levels.
-
very low stability(set to 300 and keeps rising until no iron and down) but as you said B and dflt are the same i have no clue, the tips are well used and should be pretty stable, will keep an eye on it and report back.
I'm assuming you have the cheap Chinese tips. Do you have more than one? I've got one which is really unstable, like you describe. Most are OK, but some are better than others. Once I decide on my favorite tip (BC1 is the front runner right now for SMD work), I may buy a genuine HAKKO one, just to see how it behaves.
I think your issue is more the tip, and not @DavidAlfa code. For me, the original KSGER code was much worse (more tips had problems).
-
First, I don't understand why you have these tips.
Last code changed the data layout, so the tip data should be resetted.
And the new defaults don't include any of these tips.
Reset, and if it still does that, start with the pid. Ki kd to 0 and start from there. Search how to tune pid... But the values are the same.
About the menu, yes, I had done that. But caused some bugs, then removed the settings screen, then reverted that...
I will restore that too, but when it works correctly
-
About the menu, yes, I had done that. But caused some bugs, then removed the settings screen, then reverted that...
I will restore that too, but when it works correctly
It was just a suggestion. If it's not simple, don't waste your time. It would be better, but it's not important. Even better would be a timeout - no change in 15 (?) seconds, go back to main screen. But both would probably use similar logic, so if it's hard don't do it. I've been doing a lot of things in the menus because I've been testing things, but when just soldering the menu wouldn't be used as much.
I replaced the encoder with a Bourns one (PEC11R-4115K-S0018 - requires "Encoder REVERSE", thanks for adding that). Since then, I have not had the problem with button presses not working.
-
That also was made back then.
It's not hard, I just got overloaded with so many issues lately... What is hard is to guess all the issues without my iron working, I burned my tips down and recently accidentally cracked the oled :palm: :-BROKE.
Yep the issue with these cheap encoders is that they doesn't always make complete steps.
Sometimes it stays in the middle. So the encoder routine is waiting for it to complete the step.
I can't fix that. It needs to know the position before a click to detect the correct action. It can detect simple clicks but also "rotate while click".
-
You can add a timeout for the encoder routine so it if gets 1/2 a movement ignore it and return. The next movement may be unknown too and may have to throw it out as well.
-
Then it will be annoying too.
I will make some tests.
-
Set the coefficients KI and KD to zero. The problem is gone. But now the station is not gaining 480 degrees, it stops at 474.
-
Now you need to play with the PID. Increase Kp until it gets closer to the setpoint, then try low values on Ki (1-5) and Kd.
Sorry, PID is a complex thing, I can't teach you how to tune PID, search yourself!
When I get my tips I will try to tune these better.
From what I remember, it would vary a lot between tips, even same tips from different sellers.
These are the PIDs from the old firmware. They didn't work too well with my tips.
"B"
Kp = 40
Ki = 31
Kd = 7
"BC2"
Kp = 30
Ki = 25
Kd = 0
"D24"
Kp = 200
Ki = 25
Kd = 0
Updated the builds. Added return to main screen on long click or being idle for >15seconds.
Try to fix the cheap encoders. If it detects the encoder stopped in the middle position for more than 500mS, it will treat the clicks as normal clicks instead drag clicks.
It might need additional timing tweaking, and could cause more problems that it fixes.
If it's the case, I will revert the changes and forget about it. Use a quality encoder then.
-
got new st link's in today and am going to try to reflash. im also curious due to my color vision would anyone know of a white oled i can solder in place of the blue one from ksger that will be fully compatible? i ordered a few to try but they are taking FOREVER to get here from china right now. is there a specific one anyone has tried yet?
edit this time it flashed fine with the new stlink. must have been something odd there. went through no issues. love the new gui imo
-
Nice!
If the pinout is the same, it should work.
I'm also waiting for them to come, bought a blue and also a white one, but they're 7-pin modules, I think KSGER 3.0 uses 6-pin.
I think @Cosmin1 already did this...
-
edit i realized the spot in the corner i was seeing is because when set to F the graph is maxed out and its the triangle next the graph level in that top corner. erased and did a new flash and this time it did overshoot but was much faster to come down and i did not get the no iron message. it did go up to over 600 but came back down fairly quickly. i do still get a lot of jumping up and down though temps wise. when set to say 350c it bounces between around 300 and up to around 380 fairly quickly. i did use the build on the github this time from today instead of the last version posted here in the thread
is the a way to put the handle into sleep though without waiting?
-
i think i found the almost identical display i ordered a few and will report back the pin layout is exactly the same as the 3.0/3.1 ksger and in white
is this the official github page for your builds? i just want to be sure im testing the proper builds? https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv3.0%5D/%5B64pin%5D
thank you again for all the help.
-
https://github.com/deividAlfa/stm32_soldering_iron_controller
-
edit i realized the spot in the corner i was seeing is because when set to F the graph is maxed out and its the triangle next the graph level in that top corner. erased and did a new flash and this time it did overshoot but was much faster to come down and i did not get the no iron message. it did go up to over 600 but came back down fairly quickly. i do still get a lot of jumping up and down though temps wise. when set to say 350c it bounces between around 300 and up to around 380 fairly quickly. i did use the build on the github this time from today instead of the last version posted here in the thread
is the a way to put the handle into sleep though without waiting?
Is the temperature behaviour different? I didn't change anything in that part.
This is just a warning, I'm not blaming anyone!
Don't ever open an issue if PWM/DELAY/Filtering settings are not set as defaults.
This is an advanced FW, allowing a lot of tweaking, and it will cause a lot of trouble if not configured correctly.
Please don't touch them and complain later! These settings usually need probing with oscilloscope to ensure the ADC is reading a clean signal.
Entering sleep: Not manually with the encoder. You can set the wake input to "stand" mode in the settings.
You will have to connect the wake input (which normally goes to the handle "shake" sensor) to the stand, disconnecting it from the handle sensor.
And connect the tip to Gnd. When the tip touches the stand it will enter sleep instantly. And wake up automatically when removed.
You can also put a reed relay in the stand, that shorts the signal to gnd when activated, and a magnet somewhere in the handle to trigger it.
The weird corner: Ouch. The graph also expected Celsius only. Fixed and updated. Try it.
-
i was using an older firmware you posted here in the thread that was causing the overshoot to 700 then no iron. the later one from the github does not cause that. but as an example with a "k" tip the china ksger branded one seems to bounce between 580 and 656 (highest i saw) F when set to 600f with the genuine hakko k tip its a bit better where it is less of a range of jumping around but still does it. this is even after calibration.
the spot in the corner is def gone now and the graph for F seems to be working fine now. ill try the stand setting and see how i like that one. i was thinking like with the ksger you could turn the knob quick right i think it is to go to stby. i did use that often as i would be doing other things as i was working and instead of waiting just put it in stby. my stands are black so i would have to scrape some paint prob for the stand setting to work properly i think. i may leave it the way it is then and just set it for shorter time. if i could get the temp to stabilize better on the display this would be super useable and i would prob flash the other 2 i have also. i much prefer this to the ksger firmware personally. ill try a better calibration of the tip later today and see if that helps.
is there a place to get the original ksger firmware im curious to see what all the pid values are for all the various tips? (i have large variety of types)
-
Entering sleep: Not manually with the encoder. You can set the wake input to "stand" mode in the settings.
How about "push and turn right" for tips, "push and turn left" for sleep (and wake, even if "button wake" is off)? Also, when "button wake" is off, you can't "push and turn" to change tips. It would be nice if you could. If sleeping with a cold tip, and you want to change tips, right now you have to wake first, which means the tip you want to replace gets hot.
-
^^^ that is what i was hoping for. i dont know how much work it would be to do that or if it can be done though. push turn right for tips and the push left similar to the stock firmware either way would be awesome (imo). has anyone figured out a good way to get the temp numbers to sit more still and not jump around as much? i assume the ksger firmware gives a more general idea of temps?
-
dont know ksger but on my quicko the set temp coul be 280, current temp 280 , and the tip be 280+-20c , already has been discussed better to know the real temp jumping around than showing a fake stable one.
-
Just replace the tip cold. It will detect no iron and wake when the new tip is plugged in.
Yes, that button behavior can be done.
Tune the pid for stability. I had very stable temps. +-3°C usually.
-
Just replace the tip cold. It will detect no iron and wake when the new tip is plugged in.
The concept was to change the type before waking, so the new tip comes up with all the right settings. But I suppose the tips are close enough that it doesn't matter much.
-
using the d24 pid you showed above temps are within 10-20deg f. where can we find the stock pid settings for the various tips? i have another unit on ksger 3.1 is that firmware able to be dumped to a file to read them?
-
using the d24 pid you showed above temps are within 10-20deg f. where can we find the stock pid settings for the various tips? i have another unit on ksger 3.1 is that firmware able to be dumped to a file to read them?
There is only one default tip now, and David has said that all the default tips in earlier versions had the same settings.
-
edit: i now have the no iron overshoot again. was working fine today and i just did a calibration on a ku tip and it now climbs to around 550-600c then says no tip. did not see this earlier when i was using it. did nothing except do new calibration. and i tried to erase the chip and reflash with most current firmware just in case and reset with the same issue now. this is on a 102
-
so in this firmware changing the "tip" from the menu does not change the pid for that tip?
No one said that. Create a new tip. Switch to that tip. Set the PID and other settings to whatever works for you. There was no point in starting with multiple tips before, when they were all the same unless/until you changed them. BTW, when creating a new tip, it initially copies settings from the first tip.
-
Try to fix the cheap encoders. If it detects the encoder stopped in the middle position for more than 500mS, it will treat the clicks as normal clicks instead drag clicks.
It might need additional timing tweaking, and could cause more problems that it fixes.
Something is wrong with the encoder changes you made, with the normal/reverse setting. I have a Bourns encoder, needs "reverse". When it powers up, it works backwards as if it's set to normal. If I go into Settings/System, it's still set to reverse there. If I change it - reverse to normal to reverse - then it's fine until the next power cycle. If I set it to "normal", it always works backwards. So, it's acting like it's always set to "normal" at powerup.
-
so in this firmware changing the "tip" from the menu does not change the pid for that tip?
No one said that. Create a new tip. Switch to that tip. Set the PID and other settings to whatever works for you. There was no point in starting with multiple tips before, when they were all the same unless/until you changed them. BTW, when creating a new tip, it initially copies settings from the first tip.
gotcha i just wanted to be sure i was not misunderstanding was all. as edited above im getting the no iron overshoot again for some reason. with most current firmware to when this is posted. as said above did an erase reflash, reset same issue. tested 4 different tips now and 2 handles. 2 different stations (i went ahead and flashed another one both are acting the same way, for testing since i had three here for different work areas)
-
i am not sure if its been posted here or not but i did find a v3.1s im testing now. i flashed this to a ksger 102 stm32 v3.0 board and its working exactly as the ksger version is but says wlida when it boots. just in case anyone needs it to revert to stock and then back again while testing. this was said to "which corrected the error with the calibration of VSM2" over at radiokot i attached it here in case anyone might need to use it. everything seems to work as the ksger version did.
-
You have the old, old pid settings few post up, might work well, or might not.
There are no "standard PID". Even not PID at all. There are a lot of driving algorithms.
I already said too many times recently. Search how to tune pid and play with it.
Sorry, I'm getting a little tired, some people need everything chewed up...
There's a fw for the 3.0, I don't know if it's the wilda or the ksger.
-
You have the old, old pid settings few post up.
There are no "standard PID". Even it might not use PID at all.
I already said too many times recently. Play with it.
I'm getting a little tired, some people needs everything chewed up. Try yourself...
i of course have been all day testing it and trying to get it as close as i can. do you know why its doing the overshoot no iron thing as some others mentioned? i have it testing within 3-4deg now. if i could get that no iron thing fixed this would be great to use!! and i do not mean to ask stupid questions i appreciate your work on this very much and now that i understand i do not need to ask the pid question again. ill do some calibrations for you with ksger and genuine hakko tips tonight and post results.
-
Hey mikes, thanks for the commits. I made few comments explaining some features.
Be careful with that, I may have uncomitted changes at any moment.
I don't know what happens when I commit changes and later you make a pull request using older code. Doesn't sound good.
mastershake, what are your actual PID values? I had some 2 (supposely defective) tips that were completely undrivable.
All I can say is, again, remove Ki and Kd and increase only Kp until it reaches close to the setpoint.
Then give it a little of Ki. 1...2... very small steps.
It's a complex thing.
https://newton.ex.ac.uk/teaching/CDHW/Feedback/Setup-PID.html (https://newton.ex.ac.uk/teaching/CDHW/Feedback/Setup-PID.html)
https://www.eurotherm.com/temperature-control/pid-control-made-easy/ (https://www.eurotherm.com/temperature-control/pid-control-made-easy/)
Check this picture, it will make easier to understand what each PID paraneter does
(https://www.eurotherm.com/wp-content/uploads/2018/12/PID-Control-fig4.jpg)
All are important, but Kd in special can make the system go absolutely crazy, as it responds to small changes.
Try 90-2-0 for example. If I remember correctly that value worked pretty well.
It's been months without the T12 tips. C245 cartridges worked soo much better.
-
i of course have been all day testing it and trying to get it as close as i can. do you know why its doing the overshoot no iron thing as some others mentioned? i have it testing within 3-4deg now. if i could get that no iron thing fixed this would be great to use!! and i do not mean to ask stupid questions i appreciate your work on this very much and now that i understand i do not need to ask the pid question again. ill do some calibrations for you with ksger and genuine hakko tips tonight and post results.
Again I don't pretend so be rude by any means. It's just that I can't magically fix every single tip/board, specially not having it.
I didn't invent PID, neither made the PID implementation in this firmware. I tested with a lot trial&error, following internet tips.
Is the tip new? Does that happen with all tips? Try to measure the real temperature.
>600ºC will quickly destroy the tip, also the tip will start glowing red around that temp.
700ºC+ will be clearly red.
And always remember that 700ºC can't cool down to 400ºC in matter of seconds. So it must be some reading issue.
Some ksgers have terrible power supply noise causing a lot of problems. They have a 3.3V switching supply, stepping-down from 24V.
And all the analog and digital circuitry is powered with that, without any kind of filtering else than few ceramic capacitors... Not the best way to interface 20mV signals!
Do you have oscilloscope? Watching the waveform would be a great way of debugging the problem.
If you want to be 100% sure the ADC isn't reading inductive spikes from the heater, increase the ADC delay to something crazy, ex. 100mS.
Yep, 50% of the power will be lost. But it's just for testing.
Follow these guides!
-
yes i can put in on the scope tomm when im in the office ill bring it with me and have a look. i think i found what "seems" to be a happy area where its not overshooting and temps are almost spot on. this is 150-30-0 or slight variations of that seems good also, the stock firmware was 0100-0030-0100 but that made it way worse. with that it was a mess. but using the 150-30-0 after a calibration im literally around 3deg over at 300c, spot on at 350, 4 deg under at 375 and 2 deg over at 400c (ksger tip). and stable it seems. ill continue to test it as a main station and see how it does. i also have c245 and c210 tips i can test also. ill power it off the bench psu and see if that helps also.
whats odd is i even erased and reflashed then did a reset-all. did not touch the pid at all left it as was and it was reading crazy high like 650-700 no iron then i adjusted the pid and got the same high readings and no iron. then i put it aside to get some stuff done and came back a couple hours later and did another reset -all (did not reflash) did not touch the pid settings and tip it was not overshooting anymore, its just weird was all thats why i was like hmmmm temps were off but it was not going nuts.
i saw a station on you tube (homeade one) where he had it graph out the pid is that possible with these chips or would they need to be more powerful?
-
got new st link's in today and am going to try to reflash. im also curious due to my color vision would anyone know of a white oled i can solder in place of the blue one from ksger that will be fully compatible? i ordered a few to try but they are taking FOREVER to get here from china right now. is there a specific one anyone has tried yet?
edit this time it flashed fine with the new stlink. must have been something odd there. went through no issues. love the new gui imo
I already did that. It's a nice improvement. But it's not easy. If you have v3.0 black board, you have 6 pin screen board so you need to unsolder only the screen with the flex foil, then resolder to your screen board because it's different in dimenssions.
If you have 4 pin blue board, you also need to do the same operations because the chinese screen boards you will find, are bigger than the controller screen board.
(https://b9.icdn.ru/c/cosmin34/6/69703666mVw.jpg)
(https://b9.icdn.ru/c/cosmin34/1/69703721mQy.jpg)
-
i actually found today a screen that has the exact same 6 pin out as the 3.0 and its very very close dimension wise. im thinking if i slightly bend the header pins i might be able to get it into position without de soldering the screen itself. i ordered a pair of them once i get them and try it ill report back if it worked or not
-
Do you have a link?
I ordered few white screens too but only one is pure white. The rest is some greenish dirty white. Didn't liked.
-
ill ask the seller on aliexpress if they will put them up. i messaged a number of sellers. i gave them the specs and size (approx) and they had me send payment for a dollar amount. they sent me the specs so im just going off that. thats why i said ill see how they are when they arrive. and yeah i know what you mean about the dingy look. they told me these are bright white same pin out and not perfect size wise but not tooo far off. we shall see.
-
yes i can put in on the scope tomm when im in the office ill bring it with me and have a look. i think i found what "seems" to be a happy area where its not overshooting and temps are almost spot on. this is 150-30-0 or slight variations of that seems good also, the stock firmware was 0100-0030-0100 but that made it way worse. with that it was a mess. but using the 150-30-0 after a calibration im literally around 3deg over at 300c, spot on at 350, 4 deg under at 375 and 2 deg over at 400c (ksger tip). and stable it seems. ill continue to test it as a main station and see how it does. i also have c245 and c210 tips i can test also. ill power it off the bench psu and see if that helps also.
whats odd is i even erased and reflashed then did a reset-all. did not touch the pid at all left it as was and it was reading crazy high like 650-700 no iron then i adjusted the pid and got the same high readings and no iron. then i put it aside to get some stuff done and came back a couple hours later and did another reset -all (did not reflash) did not touch the pid settings and tip it was not overshooting anymore, its just weird was all thats why i was like hmmmm temps were off but it was not going nuts.
i saw a station on you tube (homeade one) where he had it graph out the pid is that possible with these chips or would they need to be more powerful?
Now you got it more or less stable, try EMA filtering. First try a factor of 1, if it does better try 2. I wouldn't go further, but you can try.
About these pid stock values, where did you took them from?
You didn't say if the tips were new. The way it fixed itself by leaving it running suggest that it could be the case?
-
Try to fix the cheap encoders. If it detects the encoder stopped in the middle position for more than 500mS, it will treat the clicks as normal clicks instead drag clicks.
It might need additional timing tweaking, and could cause more problems that it fixes.
Something is wrong with the encoder changes you made, with the normal/reverse setting. I have a Bourns encoder, needs "reverse". When it powers up, it works backwards as if it's set to normal. If I go into Settings/System, it's still set to reverse there. If I change it - reverse to normal to reverse - then it's fine until the next power cycle. If I set it to "normal", it always works backwards. So, it's acting like it's always set to "normal" at powerup.
I will check that. Edit: fixed, builds updated
-
they sent me the specs so im just going off that. thats why i said ill see how they are when they arrive.
Right... i don't trust chinese measurements, they would tell you anything just to make some money. But maybe you're lucky.
About the different color on white displays available... i only saw that after buying 2-3 displays from different sellers. They all swear they sell the brightest version, but the reality is different.
-
yes i can put in on the scope tomm when im in the office ill bring it with me and have a look. i think i found what "seems" to be a happy area where its not overshooting and temps are almost spot on. this is 150-30-0 or slight variations of that seems good also, the stock firmware was 0100-0030-0100 but that made it way worse. with that it was a mess. but using the 150-30-0 after a calibration im literally around 3deg over at 300c, spot on at 350, 4 deg under at 375 and 2 deg over at 400c (ksger tip). and stable it seems. ill continue to test it as a main station and see how it does. i also have c245 and c210 tips i can test also. ill power it off the bench psu and see if that helps also.
whats odd is i even erased and reflashed then did a reset-all. did not touch the pid at all left it as was and it was reading crazy high like 650-700 no iron then i adjusted the pid and got the same high readings and no iron. then i put it aside to get some stuff done and came back a couple hours later and did another reset -all (did not reflash) did not touch the pid settings and tip it was not overshooting anymore, its just weird was all thats why i was like hmmmm temps were off but it was not going nuts.
i saw a station on you tube (homeade one) where he had it graph out the pid is that possible with these chips or would they need to be more powerful?
Now you got it more or less stable, try EMA filtering. First try a factor of 1, if it does better try 2. I wouldn't go further, but you can try.
About these pid stock values, where did you took them from?
You didn't say if the tips were new. The way it fixed itself by leaving it running suggest that it could be the case?
the tips were not new one was VERY used prob towards end of life the other still fairly used it did the no iron issue also with a genuine hakko tip also bought here from reputable store in the usa. i took those from the stock firmware v3.1s on another unit. i can take a pic and show you if you would like. also they are the same in the wlida 3.1s firmware
-
Seems weird. But as I'm out until I receive the tips, try the "PID test" build.
It disables and resets the PID when temp is higher than setpoint.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv3.0%5D/%5B64pin%5D
However a proper PID should not need this...
-
i just double checked both the ksger and the wlida 3.1s pid are p-0100 i-0030 d-0100 as default setting
-
Do the ksger actually allow PID tuning? Didn't knew that.
I think they actually set a very high PID but also disable it when reaching the temp to prevent overshoot.
Try the test build
-
thanks, will test it at the office today and ill have my scope and stuff available to take some readings first. yes the v3.1s lets you adjust pid settings. 2.1 prob does also but i will check tomm i have a 2.1 controller board (original green style) i ordered and have not used yet but im thinking it does.
-
Do the ksger actually allow PID tuning? Didn't knew that.
I think they actually set a very high PID but also disable it when reaching the temp to prevent overshoot.
Yes, it allows.
(https://b9.icdn.ru/c/cosmin34/2/69166312KwQ.jpg)
-
The weird corner: Ouch. The graph also expected Celsius only. Fixed and updated. Try it.
The graph is a nice touch, but not very useful, since it shows the full range, and normally only changes by a pixel or two (unless you change the set temperature).
Let me suggest that it should be centered on the set temperature, and show +- 10 or 20 degrees away from that. That would provide a better visual indication of actual vs. desired temperature during use, and also make it useful for PID tuning.
-
I made that just because it was cool and easy. It displays 200-500°C, so 300°C range.That gives 7°C /pixel.
I think I won't bother with that, at least for now... +-10°C definitely not... that would be noisy.Maybe +-20
-
Not trying to make more work for you (well, I guess I am :D ). Just thinking about how to make it better (it's great compared to the original). It's only a suggestion, the decision is your's - especially since there doesn't seem to be anyone else contributing code. Even if it was "cool and easy", thanks for adding it, because it's more than what we had before.
-
i saw this project where he has a graph for the pid setting on his custom station. https://www.youtube.com/watch?v=P9hfRYrdItY&feature=emb_title (https://www.youtube.com/watch?v=P9hfRYrdItY&feature=emb_title) i played around with pid today and found a few kind of sweet spots. i got super busy at the shop today though so i didnt have as much time as i wanted to mess around with it to much. i do have it really pretty stable with the regular firmware. tomm ill try the one you did specific for ksger with the pid adjustments i would have today as i said i just ran out of time i do apologize. i will mess with that tomm and report back
-
i saw this project where he has a graph for the pid setting on his custom station.
Can you provide a link to the code? Hardware? Is it open source?
A link to a video sucks. Just saying.
-
this is his custom built station i think with a hot air attached as well as the iron. based on a blue pill board. here is a link to the info https://www.hackster.io/sfrwmaker/stm32-based-soldering-and-rework-station-e3955b (https://www.hackster.io/sfrwmaker/stm32-based-soldering-and-rework-station-e3955b) and the code is here: https://github.com/sfrwmaker/F1-T12-858D#readme (https://github.com/sfrwmaker/F1-T12-858D#readme)
-
Remember that RAM usage is around 9.2KB actually.
Each plot will eat 128bytes (128pixel).
It'll come the moment when a decision will have to be done. Forget 10KB stm32s or limit features.
Replacing the stm with a 103 (20KB) is easy but not for everyone.
Nobody tried the pid test build?
-
ill be testing it today. i should be at the office soon.
-
so i tried the ksger pid firmware. temps were way lower then set temp was out of the start. i did make sure to erase then also reset to be sure. so i tried calibrating the tip and i could calibrate at 200 but it would never get to 300 even if it went above 300 for a second or two on the display it would not give me the option to calibrate there or then of course 400. if i used the pid settings from the normal firmware then it worked fine calibration wise but after calibration (tested three times with fake and genuine k tips) temps are fine at 200-300 but as the temp setting goes up the actual measured temps are much higher with the same pid settings as your normal firmware. at 400 i was seeing around 424 with the hakko themocoupler. and one other slight thing when set to 300 and up the screen would read below 300 or 350 etc. so if i set it to 350 it would hover around 345-348 but was measuring 356-358 same before calibration except the measured temps were much lower then it was set for. it seems i had better temps and control with the normal firmware from you vs this one.
-
I was thinking about the tip changing method. What are your thoughts about this.
Change EDIT TIPS menu entry to TIPS
Single click will select the tip and return
Long click will edit the tip.
"Add new" will be still there.
-
I was thinking about the tip changing method. What are your thoughts about this.
Change EDIT TIPS menu entry to TIPS
Single click will select the tip and return
Long click will edit the tip.
"Add new" will be still there.
Sounds good to me - don't change tips often, and the "push and turn" method doesn't save that much time vs. a TIPS menu. It takes longer to physically change the tip. Move the new TIP menu to the top.
But, if you're going to do that, let me suggest also moving the PID coefficients, Heater R., Power, and "No iron" to the TIPS configuration, since they are stored with individual tips. I don't think PID TIME is, though - should it be? If that's added to tips, the PID menu could then go away.
-
Yeah but as PID is often modified, it's much more convenient in the main menu.
And PID mixed with the tips would be weird...
-
as debug is no longer by default available, could there be an option in calibration to enter directly the values?
-
Did you see what I answered few posts back about enabling the debug menu?
-
as debug is no longer by default available, could there be an option in calibration to enter directly the values?
If you don't have a tip thermometer, how would you know the ADC values to enter? And if you do have one, just go through the proper calibration. And if you calibrated before, but don't have a thermometer to do it again - you should have recorded the actual temperature at each step, then simply entered that again for a new calibration (which would only be needed after the controller configuration was cleared).
Or, just fork the code, then modify and compile it yourself - make it whatever you want it to be.
-
Im not asking for someone to implement it, i know i can code and compile my self thanks.As there is plenty people tweaking pid etc, it would be usefull after a hard reset to be able to just enter the values(or a reset in pid menu), not every body has the knowledge or the means to compile, i do, and always try both provided and self compiled binaries. i was just proposing, mb david finds it not worthy or even silly, he'll say why he thinks so and thats all, no need to tell me i can code it my self. :-+
-
But he is right, the calibration will be pretty much the same entering the last temps :-+
The tip and the board will be the same.
Anyways, a full calibration takes 20 seconds!
Also, the reset in pid menu, why? Change the 3 values and done haha.
-
yeah , im not saying he isnt right, or that mi idea is good :-DD, i just did not like the 2 cnts
-
I wouldn't take it personal :D
I know it might seem a bit harsh, but it's the reality when people wants to change everything to their liking.
I took PTDreamer's base and continue it, because it had a lot of potential, but for my liking it lacked a lot of things, had bugs and I wanted better hw support.
What would you think if I started to harass him? Hey I want your firmware to work with my station. I don't like this. That is weird. And so on. He'd probably ignore me or answer some well deserved ugly words. Things don't work like that, specially when most people asking don't contribute in any way (not specifically against anyone).
Better that you never know what passed through my mind (again, not against anyone in special) when I had a bad day and the silly requests started :-DD
I understand everyone want to give ideas, but in most cases they should have been analyzed better in first place.
Is it really needed?
Is there actual alternative to fix it/do the same?
Does it worth the effort vs functionality?
"It would be nice..." is not a good reason.
Otherwise, it also would be nice that you guys buy me one of these expensive JBC stations. And introduce to me some hot single ladies. And a nice car.
Moreover, I can give up on the car and the JBC :-DD.
For now the development is stopped until I receive the tips/displays and check the PID stuff. I might fix any bug that might appear, but nothing more.
But I already said back then, it's pretty much done and over. Currently I have no more plans for it. Just achieving it to work nicely and without bugs.
-
The oleds arrived. The white was OK, the blue had a worse traveling experience :palm:.
I opened a claim, the packaging was very poor, they were dancing inside the envelope with nothing protecting them.
It's a miracle that both weren't crushed.
This is the white result:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1175310)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1175318)
The white temperature is warmer than the camera sees.
Also it's a little dimmer than the blue, but definitely better for my eyes, more comfortable to look at.
The first picture is much closer to the real brightness and temperature.
-
Hi, I have a KSGER Ve2.1S OLED1.3 board, an STM32F102C8T6 controller (48 pinout), I can use this firmware, or I need to change to an STM32F103CBT6 controller, I looked at the datasheet for stm32F102 / 32F103, the pinout is the same, the board revision is Ve2.1S How does it affect or can only the controller be changed? I use T12 (KSGER) for soldering, but the quality is bad, I bought the Original Hakko T12-B I think the Firmware will work with it Good), Photo of the board (https://i.ibb.co/T0CrMKN/111.jpg) (https://ibb.co/T0CrMKN) Full review of the Ve2.1S controller here https://mysku.ru/blog/aliexpress/64124.html (https://mysku.ru/blog/aliexpress/64124.html)
-
That board is not supported actually...
Since I don't know if you can restore the original firmware, it's better to replace the stm32 instead.
I'm only doing f101 builds, since they will also work on 102 and 103.
Not difficult, it only needs profiling the board for the correct pinout.
But I'm no longer working on it.
I can try to help, but I won't spend a lot of time debugging problems.
-
I have two such boards, assembled in the case and a spare, I have already updated the firmware 2.10> 2.12, on the second board my native 2.10, the firmware is on the network, I can solder well)), but I do not understand programming ((, I will buy STM32F103C8T6 for replacement, I wonder what will come of it)
-
I only told you to replace it because I didn't want you to lose the original fw, so in the case the CFW was not good for you, you could revert it.
But if the original fw is available, you don't need replacing!
Edit: There's no need of new profile.
Although the pin count is different (48 vs 64 pin), the pin names are identical, it will work in the exact same way.
So you can flash the 64-pin 101 2.1 version.
-
The T12 tips arrived.
I only calibrated and made a quick pid adjustment.
When calibrating, remember to wait until the tip temperature is stable.
Although the TC reads 200°C, the tip heat is being transferred, in my case it kept rising for about 10 seconds untils stopped at about 230°C. And that is the value.
The tip needed about 10 minutes to stop doing weird things.
There were noises, like moisture escaping the heat, now it's pretty fine.
I use EMA 2 and pid 140-0-0. In AVG it clearly takes some spikes, EMA completely filters them.
The real temp doesn't overshoot, like the reading does, as I said the tip still needs several seconds to fully transfer the heat.
The fact that the temp never reaches the setpoint is mainly because the PID nature works that way, it needs an small error to keep going. I will probably do like normal stations, fake the temperature if it's in +-10°C range.
I don't see any of that weird issues going to 700°C like crazy.
If it's a KSGER issue, sorry, I don't have the hardware. Someone will need to attach an oscilloscope and see what's going on.
https://www.youtube.com/watch?v=vHxMhkdgixU (https://www.youtube.com/watch?v=vHxMhkdgixU)
-
@DavidAlfa - Just out of curiosity, is that a real Hakko tip or clone in your last video?
-
Hey, that was fast! ;D
Of course they're not. I will use the JBC ones.
I just bought a pair of cheap T12s for testing (BC3 and D24).
If you read some pages back you will see some real hakko tests, they didn't do better in the readings, although the heat transfer probably will be much higher.
Edit: With the stock pid values it worked perfect, much better.
I did so much testing back then... I don't understand why it fails for so many users.
Temp regulation is great. You can perfectly see tip transferring the heat.
Once the TC reaches the setpoint, then the power slowly goes down, as the tip stops absorbing heat.
https://www.youtube.com/watch?v=4nC3NzZb2YA (https://www.youtube.com/watch?v=4nC3NzZb2YA)
-
Both tips calibrated very close, but after the 10 minute burning time.
At first, the difference was huge, 3600 ADC at 400°C!
If you calibrate that way, once the tip settles, the real temp will be much higher!
Jesus are you still alive? How were your last calibrations?
Ksgers will be about 10% higher due the higher op-amp gain.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1181970)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1181974)
-
Okay, definitely the tips needs some hours to stabilize. Within 2h the temp had slowly drifted 30ºC, the calibration at 400ºC was now 2400.
I noticed that temps >400ºC were way off the setpoint (setpoint=480, measured=440), there's no calibration for that, it guesses the value based on the 300-400 calibration.
200ºC won't melt ROHS solder alloys (who solders at 200ºC anyway?), also a little error at lower temps don't represent a risk at damaging the tip or the electronics, which definitely can happen at >400ºC.
So I decided to change calibration values to 250, 350 and 450ºC.
The regulation is now better in the whole range, the biggest error I found was 4ºC
Remember to leave the station working for at least 20 minutes to heat the internals and calibrate in the best accuracy conditions.
I will leave the tip running overnight. It must settle at some point! And that will be the final calibration.
-
wow mine never could get that stable and would bounce all over the place. ill re flash again tonight and test it out again. i know this tip is fine i was using i tested it with the stock firmware on both the fluke and the hakko thermocouplers. you say stock pid do you mean the ones you have as default or the ones you listed here in the thread as the stock values? thanks!
-
By stock I mean defaults. I'm also using default PWM settings.
Try EMA filtering and factor of 2, and tell me...
I didn't make new builds yet, although the code is uploaded.
I don't know if the hakkos do better, but this tips take about 10 seconds to actually get to the setpoint temp, after the TC has reached it.
Crappy heat transfer, but ok for small jobs.
Don't try with a ground plane or everyone will laugh 😂
I think I found even better pid... 25-42-15
-
yes, still reading you , been doing some exams. i will update with the lastest and report back.
-
200ºC won't melt ROHS solder alloys (who solders at 200ºC anyway?),
Maybe to weld plastics? Burn wood? :-// :-DD
I don't think it matters, 200, 250, whatever, as long as the spread is even, the calibration should be spot on regardless of the starting and ending points. :-+
About the cheap T12 tips, perhaps the ones that came with my KSGER are pretty decent because I don't believe the break-in period was as long as 10 minutes. 5 minutes, tops, I'd say and they have been spot-on and don't drift up or down much, but that's with the stock FW which may not be as responsive (i.e. update as frequently) as your new FW. Of course, I can only confirm within the limits of my FG100 clone.
-
It's very random. The BC3 is perfectly stable even only using AVG filtering.
But the D24 reads slots of spikes, can't be fixed even increasing the delay to 50mS.
You can hear the coil when the pwm turns off, like "tac-tac-tac-tac...". Luckly the EMA 2 is able to fix it.
I will try to see what's going on with the oscilloscope.
-
t12 ,c200,c300,c400,m200,m300,m400
Conical big ,1397,2091,2966,190c,306c,408c
Conical small ,1577,2210,3150,200c,301c,404c
knife ,1538,2184,2841,200c,302c,400c
curved conical,1591,2232,3457,197c,292c,not stable
Not stable means tip most probably needs to be burned in a bit more, the knife one wich i use the most is super stable.
-
My unstable tip has at least 12h burn time, and didn't get better.
-
I've set the EMA filtering by default. I think I've tested it enough, and gives a lot more of stability.
Ignore the display overshoot, it doesn't appear at the iron tip, in fact it needs 5-10 additional seconds to reach the temperature due the thermal impedance.
Changed the encoder behavior:
- Click and increase to change tip.
- Click and decrease to enter sleep.
- Click to wake (If enabled).
Changed build optimization to "O2" for faster code execution.
Updated builds.
I could replicate the KSGER issues (temp jumping around) by removing the input filtering capacitor at the amp input. But EMA filters it nicely.
Edit: deleted the mod pictures. No real improvement.
-
i got the new oled white panels and they are very close size wise and exactly the same pin out (for ksger 3.0 / 3.1 6 pin) ill solder on in this weekend and report back but these can def work size wise.
is there a specific way the quickko is done vs the ksger then filtering wise? id love to stop it from jumping all over like that if i can.
-
I found this thread a while back and got all excited. I got some KSGER boards, some dev boards, installed the CubeIDE...and then realized I have no clue about any of this. Any good resources for STM32/C noobs?
Eventually I was able to flash a prebuilt .bin to a blue pill and then moved the F103C8T6 to the KSGER board. I haven't seen this board anywhere else, but gave it a chance and the firmware (SW: r.c727393, HW:KSGER21F101) worked.
The temps were way off at first, but dead on after a calibration.
The only thing that didn't work was 'shake-wake'.
Some ADC numbers from a well used T12-K:
250C: 1826
350C: 2573
450C: 3320
I also have another T12 station from JCD, which at first looked like a KSGER variant, but the board is quite different. It does have an STM32F103, so I might tinker with that one too. The temps on the JCD station are quite stable as-is though. All these board designs seem very unfinished. Is it time to make our own?
Anyways, fantastic job with the firmware! I have more boards on the way (KSGER and Quicko), so more testing ahead.
-
Start with the basics, YouTube tutorials.
Read the datasheet and reference manual.
Read the HAL manual.
Open HAL code examples and try to understand how it works, try to implement in your own project.
Start with simple things, once at a time, until you have enough knowledge to start mixing things together.
There're some basic stm32 books in Internet.
Else than that, stm32 literature is poor.
C language is another different thing.
You must first learn its sintax, operators, variables, methods, structures...
It's a hard learning curve if you never used them.
Needs a lot of practice. Hours, everyday, for weeks, months... You never stop learning.
C can be very simple but also overwhelming.
There's a video in the github readme showing how to build the project from zero in 2 minutes.
I learned microchip PIC16/18/24 assembly and C programming by myself around 13 years ago.
Arduino didn't exist yet. And there where no libraries either, so it was hard, but you knew how every single bit worked, touching everything at low level.
And I did always keep in touch with that from time to time.
Still, it took me easily 2 months to get fluent with stm32 world and get the project running.
Mostly caused by the original fw issues, HAL bugs and lack of documentation. A lot of the time not knowing if it was my fault, neither what was causing the issues.
Learning a new architecture is no easy. And not to talk about the stupid HAL documentation...
About the shake issue. Doesn't a small wave icon appear at the bottom left when you shake the handle?
The stm32 version is very random, they mix 101,102,103... using what's cheaper at the moment.
As stated in the readme, the 101 build works with all of these.
I neither know that board, but at least it's green and the traces can be seen easily.
At first it seems the same pinout is being used, but didn't check everything. The board labeling is very nicely done.
-
the white oled screens worked perfectly! they do fit fine with the oem faceplate just a bit lower then the ksger ones but what i did is gently bend the header pins down a bit then straight out to raise the panel just a bit and its a perfect fit will take some more pics once i put it all back together.
-
I try to flash the "STM32F102" file STM32SolderingStation.bin from the "BOARDS" folder and get this Screen, native firmware 2.11-2.12 is working / stitched, am I doing something wrong? (https://i.ibb.co/M62x5rH/123.jpg) (https://ibb.co/M62x5rH) (https://i.ibb.co/Js5bjYs/test.jpg) (https://ibb.co/Js5bjYs) (https://i.ibb.co/R0b5cwC/test1.jpg) (https://ibb.co/R0b5cwC)
-
The write protection warning might be the cause.
You have to go to option bytes and set all protection to disabled.
Something like this:
(https://blog.avislab.com/uploads/2016/11/ST-LINKUtility_OB_02.png)
What board is it? Ksger 2.1s?
-
What board is it? Ksger 2.1s?
Thanks, it helped))), Ksger Ve2.1S board
-
What board is it? Ksger 2.1s?
Thanks, it helped))), Ksger Ve2.1S board
It's working now, then?
Does the "shake" sensor work when moving the handle? (Icon appears in the bottom screen)
-
There's a video in the github readme showing how to build the project from zero in 2 minutes.
Thanks, I tried it on Ubuntu first and just got lots of errors. Turns out I had forgotten about '.cproject' files being hidden. :palm:
I've made some builds since.
About the shake issue. Doesn't a small wave icon appear at the bottom left when you shake the handle?
No, no icon at first. It turned out this board had no pull-up resistor for the handle switch. I set PA6 to 'pull up' but still nothing. Then I read about .ioc files in your readme. NVIC was not enabled in the .ioc I had. (Which was downloaded from github earlier this week). With these two changes the shake-wake works perfect.
-
As I said, I don't have these board so I can't test them thoroughly.
I see you are a fast learner, good job finding that!
I checked the KSGER 2.1 ioc files.
EXTI was enabled, however the interrupt didn't. Was that what you meant?
Fixed and updated the builds
Are you sure it doesn't have pullup? Seems strange to me, check this pic from other 2.1:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1188898)
-
What board is it? Ksger 2.1s?
Thanks, it helped))), Ksger Ve2.1S board
It's working now, then?
Does the "shake" sensor work when moving the handle? (Icon appears in the bottom screen)
on the firmware dated March 6, the "Wave" did not appear, I have now flashed the version dated March 8, everything worked when you move the handle, an icon appears in the lower left corner)
-
Yes, AndyC found the problem and I quickly updated the fw :-+
Thanks for reporting that the issue is now corrected!
-
As I said, I don't have these board so I can't test them thoroughly.
I see you are a fast learner, good job finding that!
I checked the KSGER 2.1 ioc files.
EXTI was enabled, however the interrupt didn't. Was that what you meant?
Fixed and updated the builds
Beginner's luck :)
Checked the new .ioc, and yes, that was what I meant.
Are you sure it doesn't have pullup? Seems strange to me, check this pic from other 2.1:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1188898)
Yes, traced and measured the board. There's no 'R12C' equivalent on my board. Like I said, I've not seen this board documented elsewhere.
The latest build works fine on the board though, with the small pull up modification.
I thought I would enable the debug screen and see what fun could be seen there, but it needs...debugging :) (Mismatch between cal temps)
Is there anything useful for me in the debug screen or should I forget about it?
-
Well, we should enable the pullup by default then :D
Oh, were you talking about the the JCD version?
Yes, it's a bit stupid to put resistors when you can use the internal pullups/puldowns and save some cents.
Debug screen is actually divided in 2,
The first shows internal pid values, ADC reading, pwm output.
And the second just lets you set the setpoint, but instead based on temperature, it's the desired ADC value. That's how it works internally.
Not really useful for most people and uses plenty of space, it will not fit in 10KB RAM devices.
If you want to enable it just go to screen.h, and uncomment the line that has something like:
"//#define ENABLE_DEBUGMENU"
I don't remember the exact name but it's seen clearly.
-
If you want to enable it just go to screen.h, and uncomment the line that has something like:
"//define ENABLE_DEBUGMENU"
Yes, I did exactly so, but when building I get errors. It wants the old 'calADC_At_200' etc.
Just thought I would check it out, but I'll leave it as it is for now.
-
Yep I might have forget that in the last changes.
Just replace with +50 values (Cal at 250, 350, 450)
Will look at that later.
Edit: Fixed the debug screen (Tested, uses +1.5KB RAM)
-
Well, we should enable the pullup by default then :D
Oh, were you talking about the the JCD version?
Yes, it's a bit stupid to put resistors when you can use the internal pullups/puldowns and save some cents.
I was referring to the KSGER 2.1s having no pullup resistor. I got it from here: https://www.banggood.com/V2_1S-T12-Digital-Temperature-Controller-Soldering-Station-Electric-Soldering-Iron-Tips-T12-K-907-Handle-p-1338117.html (https://www.banggood.com/V2_1S-T12-Digital-Temperature-Controller-Soldering-Station-Electric-Soldering-Iron-Tips-T12-K-907-Handle-p-1338117.html)
Debug screen is actually divided in 2,
The first shows internal pid values, ADC reading, pwm output.
And the second just lets you set the setpoint, but instead based on temperature, it's the desired ADC value. That's how it works internally.
Not really useful for most people and uses plenty of space, it will not fit in 10KB RAM devices.
If you want to enable it just go to screen.h, and uncomment the line that has something like:
"//#define ENABLE_DEBUGMENU"
I don't remember the exact name but it's seen clearly.
I tried a build with the debug screen, but it looked like the attached photo.
The good news was that we can add the JCD station to the compatibility list.
Worked straight away with a '2.1,STM32F101R8' build.
Had to adjust the settings quite a bit though. ADC delay 20->30. Still not 100% with the PID settings, but usable.
-
That's true, I didn't remember that.
As you see, I just quickly fixed the errors, but didn't flash it.
I abandoned the debug screen when switched to u8g2 library, as there was nothing relevant there and it was taking a lot of work.
I will check that on the weekend.
Remember that new iron tips are usually unstable when new and will jump like crazy. Let it run for 30 minutes or so.
It's strange that it requires that much time, usually 5mS is enough.
The genuine hakko tips had a lot of delay, that's why the final value was increased to 20mS.
Are you using EMA filtering and factor 2?
And I repeat that the little overshoot doesn't appear at the tip.
-
Hello everyone, i want to buy stm32 soldering station and install CFW in it :) I have some questions. As far as i checked Chinese sellers there are 4 pin, 5 pin and 6 pins versions. Which one do you suggest? What are the pros and cons of them? I am also interested in with using C245 tips as a future option.
Thanks!
-
What you need is a supported board, check the GitHub readme.
As far as I know all the supported boards use 5 pin connectors. Most will work with JBC tips.
C210 will work without board modifications (TC is also in series with the heater, as T12s).
C245 needs with minor mods, as the TC has it's own pin.
-
I will follow the compatibility part on github. I was wondering for 6 pin model after i saw this video on youtube. https://youtu.be/XDQdpYJrET0
Thanks!
-
I will follow the compatibility part on github. I was wondering for 6 pin model after i saw this video on youtube. https://youtu.be/XDQdpYJrET0 (https://youtu.be/XDQdpYJrET0)
Thanks!
Ouch sorry, that was a slip. Yes, Quicko has 6 pin, while KSGER 5.
That's my station indeed ;D
All are similar in the real world.
But I prefer Quicko due better power supply design, ok-ish quality analog parts (amplifier, analog frontend). Overall, better design.
Also the display is SPI and it's connected to the dedicated hardware pins in the STM32, making it much, much faster, while barely needing CPU power.
KSGER v3.1 also has SPI display connected to the hardware pins.
KSGER v2.1 uses I2C (much slower), and not connected to dedicated hardware (even more slower and taking a lot of CPU power).
Ksgers in general tried to save as much as possible in parts, some people have stability issues with theirs.
But also there a lot of KSGER users happy.
If the price is close, I'd go for the Quicko. But let others share their experience.
I tried a build with the debug screen, but it looked like the attached photo.
The debug screens are fixed! The space is really tight there.
I found something in the internal PID settings: "PID.minI = -50;"
I think, since the heater can't cool down actively, there's no sense in setting a negative factor.
I set that value to 0 and now it reacts much faster when the temperature falls down.
Both tips (BC3,D24) are doing great with these PID values: 52-25-14 (I set this by default now).
The PID values are stored in the profile data upon initialization, so flashing the firmware won't change them if the profile already exists.
In that case, the profile must be resetted form the settings menu.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1191472)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1191476)
-
I will go for spi :) I found another T12 soldering iron which has F103CBT6 mcu, It looks very interesting seems 2.1s style and i2c.
I texted Quiko store for MCU model, they said they are using F101C8T6, on customer reviews there are photos with F103CBT6 :-// Seems it is related to luck.
F101C8T6 covers the requirements of 10KB RAM and 64KB flash with 36 Mhz. Do you think its good to go?
-
Don't worry about the MCU. In the worst case, you can get a 103 for little and replace it.
That board doesn't look too nice, more like done on the cheap.
Yes, pretty similar to the KSGER v2.1. I like it has the bridge for the JBC.
I do that bridge at the handle connector, so I can just swap the handle on the fly.
I don't have a build for the Quicko with F101, but won't be a problem, it just needs a new profile.
Ask for board pictures to ensure they didn't change everything.
-
Hi guys,
after about 3 month I received my station: It is a T12-955 from Queckoo which I bought in the Quicko store. Is there an easy possibility for the firmware upgrade? I can reverse-engineer the pin-out if needed.
CPU is a STM32 F103CBT6 48 Pin. Edit: Just seen that it has 128kB of flash.
Attached 2 pictures and here the Ali link: https://de.aliexpress.com/item/1005001608493682.html?spm=a2g0s.9042311.0.0.63264c4dtXm7T0
Cheers
Tommi
-
Edit: It's similar to the KSGER v2.1 but seems to have some differences?
The display, encoder, PWM seem to be the same as the KSGER v2.1, but there are pins with unclear connections.
I didn't find anything about the CEIAH IC.
Seems to be an independent voltage regulator for the analog? Or at least it sems to power only the op-amp and the stm32 VDDA.
I don't see the NTC anywhere, it's probaby in the handle like the KSGER. Or it might use the internal stm32 sensor.
I see the earth (PE, R25) is joined to the internal ground with a solder bridge. At least in mine, this causes a big reading offset > 70ºC.
I left the original 100K resistor there.
As a reference, check the v2.1 64 pin schematic.
https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf)
Don't compare the pin numbers, but the pin names.
Ex. PA2 is pin 12 in 48-pin package or pin 16 in 64-pin. If the same signal go to to PA2 in both, the firmware would work right away.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1192964)
-
The debug screens are fixed! The space is really tight there.
Cool!
Meanwhile, I've been testing the JCD station and it behaves odd with the standard settings:
[attachimg=1]
And yes, that temperature reaches the tip.
Also, I get this when shaking the handle:
[attachimg=2]
This made me look into the TC wiring and opamp. It's different from KSGER stations. Tried to draw something in EasyEDA and came up with this:
[attachimg=3]
[attachimg=4]
Is this a feature or a bug? Time for some hardware mods?
-
I was talking about a single overshoot.
But yours oscillate a lot!
If it was a small 1 second overshoot it wouldn't actually appear there.
Did you try with the last PID settings I wrote in the last posts?
When it oscillates like that, decrease "I" factor in steps of 10.
I guess that doesn't happen in the Ksger?
Let me check it more thorougly, but the amp schematic seems the same.
The second picture is not bad, that variation is just 1-3 °C.
But the first one is way too much.
Are you using the last fw? And resetted the tip profile?
-
I was talking about a single overshoot.
But yours oscillate a lot!
Yes, indeed!
If it was a small 1 second overshoot it wouldn't actually appear there.
Did you try with the last PID settings I wrote in the last posts?
Yes, it oscillates even more with the new settings. Erased the flash and used the latest version.
I guess that doesn't happen in the Ksger?
No, the KSGER works fine.
Let me check it more thorougly, but the amp schematic seems the same.
The notable difference is that the JCD version has a capacitor on the opamp output and the led cathode is connected to the inverting input(?)
The second picture is not bad, that variation is just 1-3 °C.
This is with ADCdelay set to 33mS and the PID 'calmed down' a bit.
I'm going to test it with some hardware mods and see what happens.
-
As I said I had no time yet for fully checking it....
Yes, I didn't notice that! The cap is ok, but the led is not.
That circuit will let the 24V reach the amp inputs.
It's not good to let the clamp diodes work during normal operation, they're there for protection, but the extra voltage before the diodes start conducting can affect a lot.
I've seen that in other MCUs ADCs, the diode protected the input, but the extra 0.6V caused weird measurements.
Since the max input voltage is 13mV before saturating the amp output (gain 250), I clamped to the lowest voltage possible.
Quicko has a 1N4148 diode, which will clamp to 0.6V, I replaced it with a ultra low voltage schottky diode, which clamps at 0.15V
Didn't see a noticeable difference, but I think it might help to recover from saturation faster.
In your case, I would put a 1N4148 at the non inverting input, straight to gnd.
Anyways that circuit is interesting, I will simulate it.
Lower the PID I to 0. It shouldn't spike now. Then increase it slowly. Maybe 5 each time, cooling the tip every time before checking the result.
If you use water, don't fully submerge it, only the part where the solder sticks.
I already lost some tips because water got inside and messed up, causing the measurements to go crazy, didn't fix itself by letting it hot for a long time, I guess it caused internal corrosion and that affected the TC output.
I use some cleaning alcohol when I want to do this.
If you have oscilloscope, measure the ADC input, you could discover something.
-
Beware that the stock fw can't handle C245 cartridges.
You will probably burn the cartridge as it's set for T12 only and doesn't allow calibration.
A big problem with the Quicko is that the connector is soldered and to have access to the back of the pcb you must unsolder it.
That is calling for trouble, the board will get damaged for sure.
I found a simple way to connect the C245 without much hassle. This is how I did and it worked very well.
Only a trace must be cutted and a wire soldered.
It uses the pin normally used for the handle NTC, not used with JBC, neither in this firmware.
The existing circuitry shouldn't be a problem.
I found best performance PWM settings with 50mS Period and 5mS Delay. Less delay will catch random noise from conmutation and affect the temperature reading.
Keep in mind that calibration is a must! Select the C245 profile, and use a temperature sensor for calibration, be careful to not do anything wrong that could end burning the tip!
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1155124)
Hello!
Thank you all for those work and sharing it.
I have the same board showed avobe. I’ve flashed the cfw from @DavidAlfa with no problems, but I think I’m doing something wrong with the connections.
The trace from the mosfet is cutted and the join C7-C19 is done, but when I connect the C245 cartridge, I get a short circuit (the current is limited to 1A in the PSU to prevent smoke), and the tip doesn’t heat up.
I think I’m not understanding what you want to say with VIA HERE! DON’T CUT! What’s the meaning of that?
Than you very much!
-
Do you see the small hole? That is a via.
It connects to the bottom trace, and goes to the amplifier.
If you cut it, it will stop working.
What do you expect with 1A.? A C245 will draw 9Amps at 24V!
Are you using C245? Not C210?
-
Hello.
Thank you for teaching what is a via to an ignorant.
I didn’t expect so much performance with only 1A, but the tip should heats up even slowly, shouldn’t?
I’ve tried with a genuine C245 and a clone, with the same results.
Best regards.
-
No worries! No one is born already educated :-+
These cartridges have a resistance of ~2.6ohms. At 1amp limit it will draw 2.6W at most.
Being lucky, it'll get barely warm to the touch. But the mosfet wont't work at 2.6V, and I also doubt the stm32 does.
The circuit likely will be resetting in a closed loop, turning on the mosfet, drawing too much current, current limiting trigerring, voltage goes down, circuit resets again...
If the screen isn't working, the heater won't either.
Set the voltage to 8V, 3amp limit.
That's still pretty safe, but enough to make everything work, and the power will be 24W, heating the tip for sure.
-
Ok, I will try with 8v 3A and bring the feedback.
Thank you.
-
As you supposed, the cartridge heats up with the configuration you suggested 8)
Nevertheless, I have had to do the test without handle (just with cocodrile wires) cause I must have something wrong in my handle (T245 clone), because when I connect it with the cartridge inserted, I have total short and the screen of the controller goes off.
So, some post ago I saw how you dismantle your T245 handle, how do you do? I'm doing some force between the green and black part, but I can't pull apart.
Thank you very much!
-
Check the wiring in the connector, maybe that's the issue. Either wrong wired or touching something.
Without cartridge inserted there shouldn't be a short anywhere.
The C245 handle only uses 3 wires: Gnd, Heater and sensing (TC).
Ensure that heater and TC connections aren't reversed.
Once inserted, Heater-Gnd is 2.6ohms, TC-Gnd ~0.5ohms, Heater-TC ~3ohms.
About dismantling the handle, if it's the cheap aliexpress clone, just pull hard the green part out.
It just has a drop of glue holding it, no fancy locking mechanisms.
-
Hello.
I don’t know why, but I have been trying the system (whitout handle), and the mosfet achieve so high temperatures that has desoldered itself.
I’m suspecting from the psu, seems to do weird things while the cartidge is connected.
I’ll come back with the results.
Thank you.
-
Use 24V, or at least 12, without current limit.
8v was only to test for shorts, the mosfet will not work correctly and heat up.
-
What's up guys? Are you using the latest fw? ( 11-3-2021, "SW: git c612c32" )
I think I damaged something when replacing the OLED. However I didn't use the station for few weeks, until now.
Yesterday I noticed that it was having a really hard time melting the solder.
When I resetted the calibrations, they were are almost 100ºC less (for 250, 350, 450 I measured 160, 265, 390).
I doubt it's a software issue because I don't remember changing anything, but who knows.
I just wanted to know if it's doing well for you? Because maybe I could have screwed it again without noticing :-DD
Removing the GX12 connector it's really hard, too tight (They should have done it with higher clearance), so it requires a lot of heat and the cheap ass PCB will just fall apart.
-
What's up guys? Are you using the latest fw? ( 11-3-2021, "SW: git c612c32" )
Yes, on 3 different stations. JCD, KSGER 2.1 & 3.1.
I had time to scope the JCD during the week, and I found the cause of the oscillations (the opamp). With ADCDelay=35 it runs fine.
The KSGER 2.1 works fine with the latest build.
The KSGER 3.1 (with the black 3.0 board) needed some tweaking. Had to slow down the PID quite a bit (P25 I10 D0). Handle shake-wake is misbehaving, but this was a custom build, so I'll have to look into it again.
The temperature readings are quite low when doing calibrations, see attached photo for KSGER ADC numbers.
BTW, that's Swedish you see on the KSGER screen :)
-
Nice! Are you using EMA filtering? That should do the trick.
You are lucky that I added automatic widget sizing to the contents! (Unless it hits OLED boundary limits).
You had to try that when every little thing caused a hard fault crash... "English is ok" :-DD
With that words (I would too if using it in Spanish), better to start thinking on a 10" screen!
-
Tested a few builds on the KSGER 3.0 today, and it works fine with the precompiled .bin and also the F101 & F103(!) build. No need for PID adjustments. Using EMA, factor 2. :-+
I must have messed up the clock settings on the previous build which made it rather nervous.
The one issue remains: shake wake. I see constant 'wave' flashing when the input is pulled high. Switching noise?
10" screen, yeah! Soon we'll have usb and wifi and watch TV on our soldering stations, only using the iron to heat our coffee :)
(I have been eyeing the T12X stations with the 128*128 screens though)
A question about the PWM and ADC functions. The documentation states:
|<----------------- PWM TIME -------------------->|
|_____________________________[ADC READ]|<-DELAY->| NEXT CYCLE
|<- POWER ->|_____________________________________|
Is this correct?
When troubleshooting the JCD, it led me to believe it was more like this:
|<----------------- PWM TIME -------------------->|
|___________|<-ADC_DELAY->|<-ADC READ->___________| NEXT CYCLE
|<- POWER ->|_____________________________________|
-
Yes, it's wrong, I will tell Mike to fix that (Edit: fixed), he very kindly made the user's guide :-+
The firmware works like in your correction.
|<----------------- PWM TIME -------------------->|
|___________|<-ADC_DELAY->|<-ADC READ->___________| NEXT CYCLE
|<- POWER ->|_____________________________________|
The one issue remains: shake wake. I see constant 'wave' flashing when the input is pulled high. Switching noise?
How are you pulling the input?
Some KSGER users had a similar issue in the stock fw, the station would wake up randomly, it got better with bigger capacitors.
If you connect the wake/shake input either to GND or 3.3V, it should only blink briefly.
If I touch the input, the icon it will stay on all time, due the 50/60HZ mains noise I'm injecting with my body capacitance.
So, it's detecting like the handle was moving at 100/120Hz (it detects rising and falling edges).
The shake icon has a 50mS timer before going off (I don't remember the exact value right now).
What happens is that it gets enabled again before turning off. Not a bug, just noise.
-
How are you pulling the input?
Some KSGER users had a similar issue in the stock fw, the station would wake up randomly, it got better with bigger capacitors.
If you connect the wake/shake input either to GND or 3.3V, it should only blink briefly.
The input is pulled high by the onboard resistor and pulled low by the handle tilt switch like normal.
I changed the 3.3V output capacitor to a bigger one, but no improvement. Then I just inverted the switch in the handle :)
Which capacitors 'need' upgrading on the 3.0 board?
-
I have no idea, I don't have that board...I read that in a KSGER v2.1 thread.
How are you testing it when you say you are "pulling high"?
My handle had the switch reversed, it didn't detect anything while soldering, only when putting it upside down.
-
How are you testing it when you say you are "pulling high"?
My handle had the switch reversed, it didn't detect anything while soldering, only when putting it upside down.
Maybe I'm using the wrong words, not a native speaker...
When the handle was in the stand, the tilt switch was open -> shake input is at 3.3V + lots of noise
When holding the handle with the tip pointed up, the tilt switch was closed -> shake input is ~0.3V + very little noise
So, open switch gave flickering shake indicator and the station never went to sleep. Inverting the tilt switch fixed this.
-
Neither am I!
I was not sure if you were pulling high the handle itself or the pin by connecting it to vcc.
But even when leaving the handle in the stand caused the noise? With no movement?
Can you confirm the actual resistor value? I think it was 4k7, more than enough...
And there was another 4k7 resistor in series to the stm32 pin (as a protection method).
Shouldn't cause any trouble.
Given you already know how to build the de, open CubeMX (.ioc file) and enable pullup resistor for wake input. And check if it gets better.
-
My JBChinese tips are about to come after 2 long months... I hope I don't get the same crap like the last time! :palm:
I used the station a bit these days, and noticed that the detection was a mess, it jumped like crazy.
So nobody realised that iron detection was broken since long time ago?
I don't know why, but I was disabling the PWM completely when not detecting the cartridge. Fixed by leaving the PWM slighly on.
I remember doing exactly this few months ago to fix the detection! I might have had another brain stroke... :-DD
I mostly spent the day in testing and debugging to enhace the filtering delay/response.
The iron detection works spot-on now (at least for me), no resistor needed in the amp input, even with very low detection delays (tried 100mS and perfect).
This is the last changelog:
Disable error detection during the first second, to let the readings get stable.
This is safe, as during this time only the boot screen is shown.
The PWM is almost disabled (10uS pulses to enable iron detection).
Disable PWM if supply voltage is lower than 12V to avoid the possibility of the mosfet going into ohmic region and overheating.
Enabled Shake input pullup also in KSGER v3.0 profile.
Setpoint widget inverted for better reading. Increased delay to 1 second before returning.
Enable Tip selection in sleep / No iron screens.
Changed Tip selection widget to smaller letters, also added title "Tip selection".
Deleted DEMA filtering since it was pretty much useless in this application.
Enhaced EMA filtering response by comparing to last average.
Typical reading noise is around 10-40, so that's what we want to filter.
Reset filter if delta>200, add half the difference if > 100.
This allows a much faster response, yet the filtering still works perfectly fine.
Fix iron detection by always leaving PWM to min value (10uS pulses).
(Critical failures will always disable PWM completely).
Clear the plot data when entering sleep/error screens, so it appears clean when it returns to run mode.
Don't collect plot data if not in run mode.
Added more errors messages.
If only iron detection is triggered, the classic "NO IRON" is shown.
If more (not critical) errors are active, a code-based error message is shown.
- No iron (No cartridge inserted)
- NTC reading too high, > 70ºC (Shorted, open-circuit or serious overheating)
- NTC reading too low, < -60ºC (Shorted or open-circuit)
- Supply voltage too low (Less than 12V).
- Internal failure. It means the PWM has been disabled for safety reasons.
Actually the only reason why it could happen is if the profile is undefined after passing the ID + checksum checks, very unlikely unless there's some kind of memory corruption.
(Maybe I'll move this one to critical errors, not a good thing if it happens).
Error code is a 8 bit bitfield (Displayed in HEX):
x x x x x x x x
7 6 5 4 3 2 1 0
- Bit 7: Global flag (Any error is active)
- Bit 6: Unused
- Bit 5: Unused
- Bit 4: Internal failure
- Bit 3: Supply voltage low
- Bit 2: NTC reading low
- Bit 1: NTC reading high
- Bit 0: No iron detected
Multiple errors can be shown, however only 3 will fit in the screen.
The displayed error code can be used for determining the cause.
For example, a KSGER with no handle connected will trigger No iron+ NTC low, showing "ERROR 85, No iron detected, NTC read low".
Facing an extreme case: Internal failure + voltage low + NTC low + No iron.
All these errors won't fit in the screen, but the code will be 9D.
And, of course, I updated the binaries.
Since everything seems OK, I made the first release!
Say Hello to v1.0 :-+
-
I used the station a bit these days, and noticed that the detection was a mess, it jumped like crazy.
So nobody realised that iron detection was broken since long time ago?
Aha! I thought that my KSGER 3.1 was misbehaving in more than one way. I'll have to reflash it and test.
Did not see any issues on the 2.1 version though.
This is the last changelog:
Wow, great work!
I really like the inverted setpoint display.
My OCD will miss the F103 builds since I have only those MCU's, and I really need the extra MHz so I can solder faster :-DD
This FW and the Bourns rotary encoder is the upgrade of the year!
Edit: The KSGER 3.1 is running better than ever on the new FW.
-
Haha... since I optimized the code to not waste all the cpu power to redraw the screen contents every time, the speed is pretty fast even at 16MHz!
The slowest by far will be the v2.1, as the display must be updated by software. And i2c is slowwwww, even being overclocked.
Before, it was a big mess to make 3 builds (F101,F102,F103) for every KSGER board! Since it works the same... it saved a ton of time!
If it could be automated with a make script, then it would be much easier. Since I don't have that knowledge, I'm tied to do it manually...
Did you modify the code to set a so low setpoint, right? Because it's 180ºC minimum by default.
Under ~100ºC the TC reading is pretty much dead. If it reads something, can't be trusted. See this:
https://hackaday.io/project/94905-hakko-revenge/log/144548-hakko-t12-thermocouple-is-not-type-k
The setpoint should be centered, but that widget is stretched so much to fit 5 characters and fill the entire screen, that it's actually a little outside the display.
If the code detects that, it disables the alignment calculation, and draws at x=0.
Since the widget is designed to have always 5 digits (xxxºC), that would never be an issue.
But you had to touch, didn't you? :-DD
Did the shake input get better?
Check that the errors are correctly detected when removing the handle connector (KSGER should complain about NTC low and iron detection).
-
Did you modify the code to set a so low setpoint, right? Because it's 180ºC minimum by default.
Yes, of course I had to touch it :)
The original 3.1 FW has that setting, and while I don't trust it, I find it useful when testing handle assemblies. I can get a reading and insert and remove the tips without burning my hands :)
Did the shake input get better?
Check that the errors are correctly shown when you remove the handle connector.
The shake input problems were bad cap and soldering.
The error display seems to work as it should on my KSGER's and on the JCD.
-
I see. I do it with some pliers, haha. If I have to wait until the tip cools down... would need to shave/eat/sleep few times!
Anyways, the PID doesn't work below 100ºC. It just sets PWM off.
You can modify iron.c line 151 from 99 to 100, and set min temp to 100 in the widget.
That way the setpoint widget still shows nice, and setting it to 100ºC disables the PWM.
You replaced some caps? Can you show which ones?
It would help others with your same problem.
Aaaand a litle bug, I forget to ensure that PWM was never 0 after PID calculation, that would cause detection issues if the tip was removed when the PID was off.
Fixed and updated everything.
-
You replaced some caps? Can you show which ones?
It would help others with your same problem.
I replaced C9 on the black 3.0 board and redid some solder joints with leaded solder. Overall poor solder joints on this board.
-
they are sending out a new psu with the ksger now. v 2.05 one major thing is the one trace doesnt run under the heatsink anymore otherwise its pretty close to the same thing. the one heatsink in the one that just got here is a mess though im going to remove it and straighten it out and re mount it. the thing was supppper warped and leaning way off to one side. i was gently able to straighten it upright wise but the thing is mangled warped wise. also they did not use any thermal paste or material at all on either one in this version. i thought i mentioned the sleep issue a while back. i did have that but i dont remember which build it was now. i may have forgot to mention it i cant remember.
-
As you see the sleep issue is not fw fault (Also happens in original fw), it occurs in few boards, but due a hw proble.
Btw I'd like to add support for the older ksger v2.0 board, what the original PTDreamer fw used.
However nobody asked ever, strange.
-
Finally, the C245 tips arrived.
Edit: Same crap with fancy steel cover.
The tips loosen when hot, they are badly pressed.
I'm done with cheap JBC copies.
They're pretty good, but all of then are too small for soldering heavy stuff, only suitable for smd parts.
The overall finish is very good.
Couldn't calibrate them, I lost the DMM temp sensor weeks ago :palm:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1205822)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1205826)
-
My chinese 245 behaves well. But the 210 tip is some crappy material. Oxidizes quickly.
-
Define "well".
Have you used genuine JBC before to compare experiences?
I worked with one for 6 years, used almost every day. I changed one tip only once, because it was worn out.
And I can say the heat transfer was amazing even with the small tip.
This is absolute crap... Will buy some genuines. I have a friend where I bought all the parts for the repairs, he still makes me the discount...
I can get them for 22 euro. With 2 tips I'm more than OK. A "knife" tip for the heavy stuff and a 1mm round type for the rest.
Anyways I'm barely using it lately, so I'll leave it for the future.
Talking about soldering. Someone send me a private message in other forum asking for help.
Dammit, he used a gas soldering iron for the fine electronics, I felt in my soul all the pain the board had suffer, all the lifted/burned pads .... :-DD
Told him to inmediately stop using that thing coming from the hell and get at least a cheap temp controlled iron.
He's doing the soldering training with the $$$ board, skipping the practice with some cheap damaged one :palm:
-
Someone send me a private message in other forum asking for help.
Dammit, he used a gas soldering iron for the fine electronics, I felt in my soul all the pain the board had suffer, all the lifted/burned pads .... :-DD
;D
I used these tips several times and they did the job. I have no genuine JBC tips to compare. Can only tell is ok considering my experience with other types of tips.
It's very possible to find big quality differences between different sellers.
-
yeah the copies are super hit an miss. i have a few okay ones and mostly horrible ones. i only bother with genuine tips now. it sucks they are much more pricey but compared to the clones worth the cost difference imo unlike the t12 ones where the copies are usually pretty decent
-
So, @DavidAlfa, after having used v1.0 for a while on different stations, here are some thoughts/questions:
- When the buzzer is set to ON, there are two beeps per edge detection of WAKE input. Is there a way to disable this? (Sounds like a radiation meter!)
- The new error handling is great!
- For a newly flashed KSGER, I sometimes get failed calibration (the temps are way off). How is successful / failed calibration determined?
- The original Quicko firmware is indeed terrible! I managed to save another station from the closed-source-crap. I saw it had support for 1321/1322 heaters, but who will use those when there's a T12 option?
- The standard calibration values for the Quicko almost made my tips glow, I saw 580°C at the 450°C calibration point. See attached photo.
- The temperature was not very stable on the Quicko, increasing EMA filter factor 2 -> 3 helped a bit though.
- Found an SSD1309 2.42" display for the KSGER 3.1, worked fine with offset = 0.
-
there are two beeps per edge detection of WAKE input.
Currently I have no buzzer. Are you sure it's that? It will beep when waking but also when reaching the temp.
So if you go to sleep and wake up quickly, both things will happen very closely in time.
How is successful / failed calibration determined?
Basically, it checks that T450>T350>T250. And than none of the new calibrated values exceed the ADC range.
So for example if your T450 was ADC 3900 and you measured 300ºC.
The calibration (Not exactly done this way) would be something like: 3900/300*450 = 5850.
The max ADC value is 4095, so the calibration will fail.
Otherwise it could store a number higher than the ADC, that would push all the power into it, while never reaching the setpoint, making a T12 candle.
This was another security check added some weeks ago.
Also, if you are getting unstable readings, the calibration will likely fail.
(the temps are way off)
That's the problem with so many tips and boards.
First, I set it a lot lower to avoid exactly that, then people complained that it was too cold on default calibration.
Then I put it normal, now they are getting candles :-DD
As you see, almost nobody post their calibration results.
That way I can't make a proper table for each board and set a default calibration.
increasing EMA filter factor 2 -> 3 helped a bit though.
If it's unstable, increase the delay, not the EMA factor. The ema is designed to filter small spikes.
Also a bad power supply/noise will cause a lot of trouble.
Are the tips new? You know they do that for maybe 10 minutes, right?
Don't calibrate a new tip before lthe burn-in time!
The original Quicko firmware is indeed terrible!
Terrrible is not enough. There are no words in the human language to describe it.
The standard calibration values for the Quicko almost made my tips glow,
The Quicko board has adjustable gain, there's a pontentiometer in the board behind the display that can change the gain between 160 and 300.
You can guess what happens if the gain is too low.
Either set the gain higher or change the default T12 values than can be found in Core/Inc/settings.h
Lower the values by a 30% or so, and try again. :palm:
Found an SSD1309 2.42"
Yeah they're basically the same thing with bigger pixels.
Not willing to pay 15$ for them just to see the temp :-DD
-
there are two beeps per edge detection of WAKE input.
Currently I have no buzzer. Are you sure it's that? It will beep when waking but also when reaching the temp.
So if you go to sleep and wake up quickly, both things will happen very closely in time.
Well, it behaves like this:
https://youtu.be/Vbdyr-n5YeY (https://youtu.be/Vbdyr-n5YeY)
I did not see this behavior in earlier builds.
-
So, @DavidAlfa, after having used v1.0 for a while on different stations, here are some thoughts/questions:
- When the buzzer is set to ON, there are two beeps per edge detection of WAKE input. Is there a way to disable this? (Sounds like a radiation meter!)
- The new error handling is great!
- For a newly flashed KSGER, I sometimes get failed calibration (the temps are way off). How is successful / failed calibration determined?
- The original Quicko firmware is indeed terrible! I managed to save another station from the closed-source-crap. I saw it had support for 1321/1322 heaters, but who will use those when there's a T12 option?
- The standard calibration values for the Quicko almost made my tips glow, I saw 580°C at the 450°C calibration point. See attached photo.
- The temperature was not very stable on the Quicko, increasing EMA filter factor 2 -> 3 helped a bit though.
- Found an SSD1309 2.42" display for the KSGER 3.1, worked fine with offset = 0.
wow sweet can you tell me where to get that display? id love to get a few of them for mounting these into a combo type unit?
-
there are two beeps per edge detection of WAKE input.
Currently I have no buzzer. Are you sure it's that? It will beep when waking but also when reaching the temp.
So if you go to sleep and wake up quickly, both things will happen very closely in time.
Well, it behaves like this:
https://youtu.be/Vbdyr-n5YeY (https://youtu.be/Vbdyr-n5YeY)
I did not see this behavior in earlier builds.
is this just with the quicko branded one? i dont have this issue with the ksger boards?
-
the newest posted ksger firmware (3.0 oled board on this one) id like to say is working amazing. temps are rock solid after calibration. i mean within 2-3 deg stable. very nice. thank you! this is with the china t12 tips also the real hakko ones are even more stable. i was able to get one to within 1 deg almost everywhere 2 max
-
Huh..it shouldn't even beep for that. Only if it wakes, nothing else.
I'll check the code, I made some changes, probably screwed something up.
I simplified some wake functions, maybe I forgot checking the buzzer part.
Since my buzzer became half buzzer 2 months ago, I couldn't test it.
Edit: Fixed. Will update in a moment. It seems I deleted too much last time:
void setCurrentMode(uint8_t mode){
Iron.CurrentMode = mode;
buzzer_short_beep();
void setCurrentMode(uint8_t mode){
if(Iron.CurrentMode != mode){
buzzer_short_beep(); // Beep only when the system mode changes, you bastard!
}
Iron.CurrentMode = mode;
About the buzzer: Quicko drives the buzzer with a transistor (Like it should be), but KSGER does it with 3 parallel stm32 pins (cheap-ass method top save 0.01$).
I guess that maybe, the pulse is too short for KSGERs.
Nice to know that mastershake! That's the way it should be.
For me at least, after calibration it's accurate within +- 3ºC in the whole range. And regulation is pretty much nailed.
Guys, I'm thinking on changing to a new thread. Since I didn't made this one, it's impossible keep this tidy.
I would like to use the first post as an quick FAQ for the troubles / fixes / questions that usually appear, also maybe announces/updates.
For example, I need calibration values ASAP.
Since long time ago, I've been thinking to make board-specific default calibrations.
So ex. KSGER 3.0, v2.1, Quicko, get a defaulkt calibration close as possible to real.
But I can't do it myself. Also after so much touching my Quicko it reads a lot different.
-
wow sweet can you tell me where to get that display? id love to get a few of them for mounting these into a combo type unit?
Search Aliexpress, Banggood, Amazon etc for 'SSD1309 2.42" OLED'
is this just with the quicko branded one? i dont have this issue with the ksger boards?
I see it on the KSGER 2.1 too.
the newest posted ksger firmware (3.0 oled board on this one) id like to say is working amazing. temps are rock solid after calibration. i mean within 2-3 deg stable. very nice. thank you! this is with the china t12 tips also the real hakko ones are even more stable. i was able to get one to within 1 deg almost everywhere 2 max
Agreed, great upgrade for the 3.0 board!
-
Updated binaries! (Also the release v1.0 files)
-
Updated binaries! (Also the release v1.0 files)
Wow, fast work! It did get better, only one beep per input now :) (Tested the .bin straight from github on my KSGER 2.1)
-
so with the default handle the ksger does the same thing with the buzzer. i was using one i made without the shake sensor inside of it. this is the regular blue 9501 version if you shake it it beeps and if you have it a certain way it will beep continuously.
edit same here only one beep per input on 3.0 or as you tilt it each way now.
-
wow sweet can you tell me where to get that display? id love to get a few of them for mounting these into a combo type unit?
Search Aliexpress, Banggood, Amazon etc for 'SSD1309 2.42" OLED'
is this just with the quicko branded one? i dont have this issue with the ksger boards?
I see it on the KSGER 2.1 too.
the newest posted ksger firmware (3.0 oled board on this one) id like to say is working amazing. temps are rock solid after calibration. i mean within 2-3 deg stable. very nice. thank you! this is with the china t12 tips also the real hakko ones are even more stable. i was able to get one to within 1 deg almost everywhere 2 max
Agreed, great upgrade for the 3.0 board!
almost everyone i can find has the pins down the left side ill look again. there wouldnt be enough clearance that way how i want to mount them where yours has them on the top. ill take another look maybe i missed it. was the one you have solder and go or did you have to modify it at all? i have a source for the 1.3" that are VERY close fitment wise to the stock ones just a hair lower and are exact pin out. thanks
-
Updated binaries! (Also the release v1.0 files)
Wow, fast work! It did get better, only one beep per input now :) (Tested the .bin straight from github on my KSGER 2.1)
Wait, does it still beep when you shake the handle? It should -only- do it when entering or exiting sleep mode.
Or when you change the temp and it reaches the setpoint.
-
Updated binaries! (Also the release v1.0 files)
Wow, fast work! It did get better, only one beep per input now :) (Tested the .bin straight from github on my KSGER 2.1)
Wait, does it still beep when you shake the handle? It should -only- do it when entering or exiting sleep mode.
Or when you change the temp and it reaches the setpoint.
with the ksger yes. its a quick beep as you shake or tilt the handle.
-
With the very latest firmware I just updated a moment ago?
-
yes. correct. i can reflash it if you want but before if i held it right it was a steady constant beep or if i shook it it would beep every time you move it. but now it only beeps when you move / shake it. i dont get the steady constant beep.
to be sure i erased / reflashed / reset still short beeps as you move the handle
-
Is the wake mode set in SHAKE, right?
... I'm debugging it, everything seems correct.
Every change in the handle triggers the mode change, but the buzzer is only called when the system was not in the same mode (waking up / going to sleep).
I've been shaking the handle for a while, the neighbours don't seem to like it. :-DD
Maybe I deleted the new bins and uploaded the old ones??? (Another brain stroke)
Just in case I made a new build for the ksger 3.0. Try it.
Don't bother resetting the fw, it's code related, there's nothing in the settings that could cause that issue.
-
yup its set to shake. ill try the new one now i just got back give me a bit ill flash it over in a min.
nope same behavior now with the file you just added see here:
https://streamable.com/76avlq
-
If you disable the buzzer it stops doing it?
Just to be sure it's the buzzer call.
-
almost everyone i can find has the pins down the left side ill look again. there wouldnt be enough clearance that way how i want to mount them where yours has them on the top. ill take another look maybe i missed it. was the one you have solder and go or did you have to modify it at all? i have a source for the 1.3" that are VERY close fitment wise to the stock ones just a hair lower and are exact pin out. thanks
This looks similar to the one I got: https://www.aliexpress.com/item/4001250463926.html (https://www.aliexpress.com/item/4001250463926.html)
I just soldered the header pins and connected it :)
-
If you disable the buzzer it stops doing it?
Just to be sure it's the buzzer call.
Yes, all quiet with the buzzer disabled.
Guys, I'm thinking on changing to a new thread. Since I didn't made this one, it's impossible keep this tidy.
I would like to use the first post as an quick FAQ for the troubles / fixes / questions that usually appear, also maybe announces/updates.
Good idea! Maybe the mods can move the last part of this thread into the new one to keep everything in one place.
-
AndyC, also happens with the Quicko?
-
AndyC, also happens with the Quicko?
Yes, also quiet when buzzer disabled.
EDIT:
Another clue: when the tip temp is more than 5C from setpoint, there are no 'shake beeps'. So if I heat up the tip and then lower the setpoint, it doesn't beep while the tip is cooling down.
-
Yes, after a nice sleeping I catched it instantly.
These tiredness consequences always fascinated me, something being in your face so clearly, and you didn't see them!
*Takes a nap* It shows like a neon sign! :-DD
The problem was again, the setmode function.
I was resetting the temp reached flag every time.
As it was already at the setpoint temp, it caused an instant beep.
Yesterday I didn't got the problem because I was setting the power extremely low, to avoid overheating the tip while debugging, so it was cold all the time.
Fixed, uploading updated builds.
Edit: updated.
I also lowered the low voltage limit a bit, to 11V. So 12V can be used correctly (11.9 would trigger the error).
At 12V the mosfet became very slightly warm (with 24V it was colder) meaning it was not doing it's best, having higher switching loses. But nothing to worry about.
But below 11V, it's asking for trouble, so I won't set that parameter as an adjustable option.
Now I have to think something about calibration.
For example, only on first boot, require a manual adjustment for 250, 350, 450ºC, these values will be stored and used for the auto calibration.
To avoid ex. ADC 2500 makes 300ºC in one board but 530ºC in another.
I'd prefer to avoid that, the only way is that you guys start posting calibration values.
I need to ensure there are not a lot of difference between same boards or tips.
I'll start the new thread later. There's a lot to do.
-
wow sweet can you tell me where to get that display? id love to get a few of them for mounting these into a combo type unit?
Search Aliexpress, Banggood, Amazon etc for 'SSD1309 2.42" OLED'
There're also some new 1.54" oled. Same thing, just 2x more expensive. They are available in white, blue and yellow.
The good thing is that they have connector, and all circuitry is in the upper side, so the pcb can be trimmed if it doesn't fit inside the T12 box.
(https://i0.wp.com/ae01.alicdn.com/kf/H4e9113f305054fa1ab425ccd716db211R/1-54-inch-PM-5PIN-7PIN-White-Blue-Yellow-OLED-Module-IIC-I2C-Interface-128x64-Display.jpg)
-
Some small fixes regarding the recent error reporting changes.
In some situations the screen would not get updated until resumign normal operation (Ex. If removing the iron while in sleep mode, it would stall the sleep text).
Also triggering wake (Moving the handle or on button activity) would overwrite the buzzer alarm status, thus disabling it.
-
the buzzer seems good now. from quick testing. do you need simple calibration measurements or do you need separate ones from different tip styles? the basic tip i have been using to test this (t12) is the simple k tip. i have others though as well as genuine ones.
edit:
sleep seems to be working fine also no lock ups and comes right out of sleep with a shake or tilt of the handle with a single beep now.
-
almost everyone i can find has the pins down the left side ill look again. there wouldnt be enough clearance that way how i want to mount them where yours has them on the top. ill take another look maybe i missed it. was the one you have solder and go or did you have to modify it at all? i have a source for the 1.3" that are VERY close fitment wise to the stock ones just a hair lower and are exact pin out. thanks
This looks similar to the one I got: https://www.aliexpress.com/item/4001250463926.html (https://www.aliexpress.com/item/4001250463926.html)
I just soldered the header pins and connected it :)
was the one you got a 5 pin or a 7 pin version? the one you linked to is 7 pin.
-
I've been working on a calibration method that keeps the tips safe once for all.
The idea was to allow a reasonable offset between the measured and the target temp.
I changed the calibration menu and the profile data. Now each profile stores a default calibration value.
It's like the tip calibration values, but this are the values used by calibration process itself.
You can have a difference of maybe 10 ... 20 ºC between tips, that's ok. But not >50ºC... or shouldn't!
If the calibration wizard detects more than 50ºC difference in any of the measurements, it will abort and show a message telling to do the manual adjustment.
Ex, in 250ºC step, you set 300ºC, it will fail. Guess what could happen if you keep going and try the 450ºC step. It could heat up to 500...600...
The adjustment is really simple. You have the 3 steps (250C,350C,450C) and the ADC setpoint.
This doesn't adjust the temperature, you set the ADC value you want.
For each step, adjust slowly until you get it close to the target temp.
Some tips need 10 seconds or even more to transfer the heat and get stable.
Doesn't need to be perfect, just close.
These values are stored and applied on future calibrations for that profile.
C210, C245,T12, all have different values.
https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10
The final calibration was spot on. I'll probably have to improve few things, but it's working.
Also put a lot of checks to ensure you can't put random values on it!
Give it a try and report results! :-+
do you need simple calibration measurements or do you need separate ones from different tip styles?
The more measures I have, the better!
-
was the one you got a 5 pin or a 7 pin version? the one you linked to is 7 pin.
7 pin
The adjustment is really simple. You have the 3 steps (250C,350C,450C) and the ADC setpoint.
This doesn't adjust the temperature, you set the ADC value you want.
For each step, adjust slowly until you get it close to the target temp.
Interesting, this is sort of how I used the debug screen. I'll test the v1.10 and report back.
-
I forgot to check for system errors in the calibration process :-/O
So you could ex. calibrate with no iron, or bad NTC...
Now any detected error won't let you start the calibration.
Also abort it if already in the process.
Anyways I see that calibration doesn't work very well below 350°C, once you go below internal 250°C (internal = setpoint-ambient temp).
Something related to ambient temp compensation.
I think it's fixed (in my test code, not released yet).
But I'm having an issue with temperature stability.
With the same ADC levels, I can get up to 20°C difference.
I suspect the problem comes from the handle temperature itself, as that's where the NTC should be to read the temperature of the cold junction.
Since it's on the board itself, that could be the cause.
I don't know if it's the handle (there was a bit of corrosion), the tips, the temperature probe or something wrong with my amplifier.
Edit: Definitely, heating or cooling the handle connector makes a difference. That's a limitation of not having the NTC in the handle.
Edit2: The probe was about to break or already broken. Moved it slighly and the two wires came apart.
I'd say it's Ok. Give it a try (Uploading)
-
After a LOT of testing, yes, definitely the issue is caused by the handle heating up.
I blowed hot and cold air over the T12 connector, it would drift the temperature up to 30ºC!
Fixed an -oops- that would overwrite the tip calibration with the test calibration.
Also added soft screen diming when going into sleep or waking up partially (Just rotating the encoder).
Updated operating manual to show latest changes.
All seems correct, everything updated.
-
Especially DavidAlfa who contributed to this firmware (and also PTDREAMER who started this), DREAMCAT4 for making beautiful all round information (mainly on github and also who managed to gathered all the infos :-) ) and also others who helped (with circuits, pictures, new ideas,...) THANK YOU VERY MUCH for all the hard work!
After reading this topic for the past month or so and I decided to order a fresh STM32 T12 v2.1s controller, a couple of STM32F103's and a ST-Link V2.
At the end of 2015 I bought BAKON 950D and had it a few years (it is still working) after that I bought a STM32 v2.1s controller (I believe from the end of 2018 2017) and made my self a "KSGER" version (case and controller is from KSGER, power supply is a 24V 4-6A version which was better than what KSGER was selling and cheaper and proper wiring which KSGER and others didn't do that time - I don't know if this even changed).
Also I own A LOOOOOOOT of different T12 soldering tips which I bought over the last 6 years or so. I would say I own about 20 different tips but normally I use just 3-5 of them regularly (normally D series) and about 5-7 just from time to time (DL52, ILS, BC...).
This message is just to let David know that there are some of us who don't have an option yet to help you by sending you a lot of different values of the tips so that you can make things even better.
I hope to get everything soon so that I can test and let you know my findings, so please don't leave us ;-)
After I get all the parts to program a new STM32 I will let you know and you will tell me if you will need any particular tip.
THANK YOU AGAIN!
Best regards to all.
-
Thanks! :D
Yeah, some calibration results would start to get the project in a more user friendly state, hopefully not requiring calibration by default.
I don't have such of a problem, usually I don't get my tips red hot because the calibration is wrong.
I'm fine with the firmware. Most of the development was just to make it nicer for the people.
Most pople tried, touched a lot of things, didn't read the thread, complained and ran away.
Maybe they expect everything to work like a professional controller that has been tested ina lot of conditions and having more resources.
In my case, all KSGER support was done almost blindly. And I only have few tips and my Quicko.
Thankfully there are few guys still testing it, I must thanks to them! :-+
By the way, I've been checking the PID. I don't have a lot of experience with those algortithms, but I've been suspecting it was wrong since a long time ago.
I've been testing Phil's implementation, and what a difference. I'm finding the apropiate values, but it's a lot smoother and stable.
Github (https://github.com/pms67/PID)
Youtube (https://www.youtube.com/watch?v=t5phi3nT8OU)
-
David,
I watched the video you linked it and I also watched the video from the same guy about PIDs and I saw you implemented it in your new version.
Also I installed STM32CUBEIDE to start learning a little bit and I checked your code in PID.
Here are a few questions or thoughts that I came by while watching your code because I don't understand some parts (at the moment I was just trying to understand PIDs):
1.) You defined 'lastTime' in 'calculatePID' but never changed it (I believe I am missing something). You did use it when calculating timeStep but it was never changed (or maybe it is changed somewhere else?).
2.) You never used pid.lastTime. Do you need pid.lastTime somewhere else? Maybe you don't need this at all.
3.) This is a sum of number 1 and 2: In case I understand it correctly I would change it from this (your first 3 line of code in calculatedPID):
static uint32_t lastTime=0;
float timeStep = ((float)HAL_GetTick()-lastTime)/1000;
pid.lastTime = HAL_GetTick();
To this (in case you need pid.lastTime):
uint32_t newTime= HAL_GetTick();
float timeStep = ((float)newtime-pid.lastTime)/1000;
pid.lastTime = newTime;
Or to this (in case you don't need pid.lastTime):
static uint32_t lastTime=0;
uint32_t newTime= HAL_GetTick();
float timeStep = ((float)HAL_GetTick()-lastTime)/1000;
lastTime = newTime;
Maybe number 1 and number 2 are just something you forgot to upload and you already changed on your computer.
As I already wrote, I hope you will tell me what am I missing just to know a little bit better.
Keep up the good work!
-
Haha wait, did you saw the commit notes? "Alpha"!
Yes, that was a typo because the old pid code used single variables, while the new Code has a nice struct.
All that is fixed now.
I dropped it for the old one, it was too sensitive.
The main issue was the I term having a really high number.
I don't know why it had a such high value, I think a dividider was lost in the code.
I've been working hard on it yesterday, changed a lot of things in the widgets to save a lot of RAM and keep compatibility with 10KB devices.
The widgets halved the memory usage! 1.7KB RAM free now.
I also found few bugs and fixed them, currently testing, seems to be ok so I'll update the code soon.
Then your may ask :-DD
-
Haha wait, did you saw the commit notes? "Alpha"!
Hmmmmmm........... no. |O
I did now :-+
I dropped it for the old one, it was too sensitive.
I've been working hard on it yesterday, changed a lot of things in the widgets to save a lot of RAM and keep compatibility with 10KB devices.
The widgets halved the memory usage! 1.7KB RAM free now.
I also found few bugs and fixed them, currently testing, seems to be ok so I'll update the code soon.
I hope to get everything from China soon so that I can test everything, but I don't expect it before May.
Then your may ask :-DD
Is it then now? :P
What was wrong with the PID code from Phil that was problematic? Was something wrong with I (regarding dt maybe)?
-
Code and builds updated!
Now there's plenty of memory left, I added new adustable options:
- PID MaxI (Max integrator value).
- PID MinI (Min integrator value).
These clamps the limits for the integrator. Too much will cause over and undershoot. Too low and it won't compensate enough.
I've spend a whole day trying to reach these values.
The big problem is thay you might get good values for 400ºC, but then get oscillation at 260.
Or get good regulation at 260, but doesn't reach 400ºC. It's a lot of work. I hope they work ok in most cases!
At least for me, with the worst tip I have, it works really really nice.
- IRON Max temp
- IRON Min temp
These just set the max/min values for the main screen setpoint.
Also fixed the setpoint widget to be always centered when it has only 2 digits.
Now there's still 1.5KB RAM and 4KB Flash free. Feel free to suggest new options!
Always remember the main target of the project: stock controllers. No crazy addons.
These cheap pcbs are a pain in the ass to modify and will get damage without any effort.
-
Is it then now? :P
What was wrong with the PID code from Phil that was problematic? Was something wrong with I (regarding dt maybe)?
Now, yes :D.
I tried for a while, but all I got was oscillation or too low gain.
The code is still there, you only have to comment the "OLD" section and enable the "NEW" one. The comments state these sections clearly.
-
This is how it does now.
It's a little less responsive, but because some tips have low thermal conductivity, the heater would heat or cool too fast and make the PID to oscillate.
It gets fast close to the setpoint, but last few degrees are reached more smoothly.
This is a pretty bad tip that would jump back and forth.
The heat transfer is so bad that it reads 300°C under water!
https://m.youtube.com/watch?v=Tv6WBr00hVU
-
It looks great in video.
I didn't have time to check the code yet, but I intend to do so.
Also thank you for an explanation.
I was thinking about over and undershoot:
Information on the screen is information from the sensor inside the tip and not the temperature that needs to come to the outside of tip.
In case you have (and I believe you do have) temperature meter you can check how will temperature be on the outside of tip compared to sensor inside the tip.
And you can do 2 tests: with the current code and with code from Phil.
This is something I wish to know and will do myself when I get all of my things (if you will not have time) but would answer those questions above.
Did you ever test it like that yourself so that you would have any knowledge about it?
EDIT: I forgot to ask you about the voltage inside your soldering station. Is it really set to 25.2V? Is that correct? I have mine set to 24V but since iron tips have more than 8 ohms the tips don't put 72W as they should. That is why 25V would be even better. I read some place that somebody even had more voltage on the tips so that the tips would put about 100W on the start. I don't know if this would even kill T12 tips sooner, but I don't have any tip that would die. I had bad contacts and I had to repair 1 tip, but it is working now. Funny thing is that it is a genuine Hakko tip.
-
I did put 30v on these tips, making around 110w, they will overheat the internal wires and melt the nylon connector.
The tips can't transfer so much power and will oscillate a lot.
Yes, some power supplies are 25V due the internal resistor feedback slighly different.
The tip needs about 10 seconds to reach the internal temperature.
It really depends a lot on the tip.
Some transfer the heat much better than others, so you never know.
So better to keep it like this and not play with overshooting.
Of course, you can do that: just increase the PID Imax.
As I said, the Phil's code was too sensitive, I couldn't adjust it to get stable. Maybe I'll give another try in the future.
-
ive been away (had to go in for a surgery) ill get on testing more when i get home. only one place in florida that do the surgery i needed and i had to stay for the whole week min. i think i have a variety of some 30+ different model t12 and 4 or 5 styles of 245 tips some t12 genuine some aftermarket but the ones i have been buying so far are working great. i finally can see enough today to use the laptop so im checking on some things ive missed the past week or so.
-
I hope everything went smoothly! :-+
Where did you buy the tips?
-
Hello everyone.
First of all, thanks for awesome work!
second one - about PID and adc work - on my chinese tips everytnig work fine, but on genuine tips when temp drops enough to start heating, it starts heating with temp spike drops ~ 20c below actual. i guess i should somehow set proper PWM and adc delay timer to withstand this.
also - could it be possible to add standy+sleep mode ? im bad at programming, so i cant do it manually. also i like how sleep mode is not disturbed by hadle shaking on stock stm32.
and finally - what about bypassing pid at all? many cheap stations dont use pid and work stable, pid as it is is a must for powerful jbc tips with delayed temp control, cuz u have to drop power before reaching work temps to avoid overshoot.
https://youtu.be/39_Vgb5UuUI
-
Did you change any settings? Is the tip new?
What firmware? What board?
I hope you read the thread before asking!
Sleep was removed long time ago, why such thing when it heats in 6 seconds? Sleep is just "off".
Not planning to remove PID by any means.
It's the opposite: JBC tips have much better heat transfer, the temperature will not jump so much when removing or adding power.
T12 will jump a lot. The cheap controllers simply fake the reading.
You set 350, they show 350, but the tip might be going up and down between 370 and 330.
A way to bypass PID is to set I and D terms to 0, and high P .
It will jump more than a pan making popcorn.
The temp drop is a known problem with genuine Hakkos.
It's been discussed, and that's why the default delay is 20mS.
You can try increasing it.
Also some ksgers are known to have very noisy power supplies, causing a lot of issues.
-
any setting. vid is captured on stock pid on 3 days ago build(currently too lazy to go to shop to buy pins for swd)
board is some of the newest 2.1 ksger with dc-dc and ldo. replaced it to work with 30v supply. stock OA was 8551, now AD8605, draws same thing, but at least now i believe in its numbers.
about heat transfer - im using W tips, they have more copper, and also thinned plating, so end of tip works very fast.
p>9000 i0 d0 is still pid. i understand what u mean - when heater reaches set temp, tip end needs to be heated a bit more, so pid is adding some power after reaching set temp to maintain heat transfer to tip end. setting only P pid will hold temp a bit below set temp, but without overshooting.
heating up is 6 secs is cool, but heating from 20 to 350 instead of 250 to 350 i guess should shorten tip life. also 250-350 jump needs only 2 sec wich negates any difference in jbc-t12
p.s. rechecked adc delay - it all works good if set to 50+1% of pwm cycle., so i just shorted pwm cycles to acceptable ticking tip noises. no overshooting now. i guess its connected with heat capacity, not heat transfer - my genuine tips are thin , while fake are heavy.
-
I didn't understand anything :D
Explain using the terms that are on the firmware.
There isn't pwm % anywhere.
I repeat asking the firmware version? It's clearly in the settings, sw version.
The last version is not in releases, but in the Boards folder.
Last one seems to be the most stable.
When you flash a different version, ensure to make a full reset to reset all stored data.
The best would be some pictures showing your settings.
So you are worrried about tip life, but running them at 145% the rated power...?
I tried that, the tips quickly loose their abilility to transfer the heat, after some weeks the temperature started to jump and the tip died.
-
>>Explain using the terms that are on the firmware.
>>There isn't pwm % anywhere.
As i guess heating cycle is pwm-temp reading-pwm-pid
and pwm timer in menu sets lentgh of all cycle
adc delay means only time break in pwm cycle and in menu u shift from cycle begining so pid get info after some more heating is done, but calculates power shift based on temp read in middle of cycle.
example:
pwm cycle set to 50ms (100%)
adc delay set to 15ms (30% of pwm setting)
14 ms heating - temp measure break- 35 ms heating, pid calculation for next cycle
settings, idle, boiling tea:
(https://i.imgur.com/4KFenvq.jpg)(https://i.imgur.com/RZSFq3a.jpg)(https://i.imgur.com/qCPw10n.jpg)
example 2:
pwm cycle set to 50 ms (100%)
adc delay set to 26ms (52%)
25ms heating - temp measure break - 24 ms heating , pid calculation for next cycle
settings, idle, boiling tea:
(https://i.imgur.com/vqM4NCN.jpg)(https://i.imgur.com/dJFciBH.jpg)(https://i.imgur.com/TsAA1pA.jpg)
So i dont get spikes now, pid dumps most power when needed, and doesnt overheat.
>>I repeat asking the firmware version? It's clearly in the settings, sw version.
1.10
>>When you flash a different version, ensure to make a full reset to reset all stored data.
i have no eeprom installed and flash erased before flashing
>>So you are worrried about tip life, but running them at 145% the rated power...?
it`s 9 ohm nichrome heater, it last forever on 4 amps. im using vapes where 0,5mm 1 ohm nichrome heaters suffer 30 amps for years.
>>I tried that, the tips quickly loose their abilility to transfer the heat, after some weeks the temperature started to jump and the tip died.
thats caused by microarcs on loose tip clamps because 30v is enough to arc through air. u must spotweld or at least solder tip end clamps. no problems on genuine tips - they are spotwelded, chinese are only clamped.
(https://i.imgur.com/8tR1DOX.jpg)
-
Sorry, I can't help if you touch settings that have been adjusted for a reason after a lot of testing.
Leave 200mS pwm, try 50mS delay.
Otherwise, if you touch everything, don't complain.
Please read my answers throughly.
I repeat, 1.10 is old and superseed by the current version inside the Boards folder.
Also read the readme and the operation manual.
-
Little update:
Added shake wake option. This sets if the shake input will exit sleeping state.
During run mode, shake input will always reset the run timer and prevent it from entering sleep mode.
Little fix in the main screen, where the station would wake after exiting tip selection widget or returning from the menu.
Now it only will wake up if a click is done in the "SLEEP" screen.
I will delete the releases, since it's giving more trouble than benefit.
Back to git version only.
-
Added shake wake option. This sets if the shake input will exit sleeping state.
Huge thanks!
-
Binaries updated! As always, inside BOARDS folder.
Huge thanks!
No problem! I consider every reasonable request! :-+
How are these readings going?
-
Thank you very much for this great Firmware David!
Is it possible to have the actual Tip Temperature insteat of the Word "Sleep" when the Station is in Sleep mode?
Or the Tip Temp else where on the Screen in Sleep mode?
-
To know if it's still hot? Weren't german strong people? Just touch it with your hands and check! ;D
Maybe I can put it in between the voltage and ambient temperature. I'll make few tests.
It bounces for a reason, to not cause the oled burning. As I later added brightness dimming, that 's no longer an issue.
But I don't want to remove the bouncing thing, I like it! :P
-
Weren't german strong people?
absolutely ;D
Maybe I can put it in between the voltage and ambient temperature. I'll make few tests.
good Idea :)
But I don't want to remove the bouncing thing, I like it! :P
Why not let the actual Temp bounce...
-
How are these readings going?
full stock settings show this. on genuine wd16 tip.
(https://i.imgur.com/fvccfQ3.jpg)
maybe ill change transistors later - noticed that another station dont tick on pwm break event. but im pretty satisfied now - tips now work fast enough to delay transition to jbc tips.
Why not let the actual Temp bounce...
there is only one true choice -(DVD) logo bounce!
-
Just as test, try really huge Delay time. 50... 100mS. Leave PWM to 200mS.
These spikes shouldn't exist. Maybe the transistor is getting a huge negative spike, making it to conduct slightly?
If you have oscilloscope,check the 3.3V rails for noise. Also the signal in the heater.
Think that only 13mV will completely saturate the amp send 3.3V to the ADC.
The TC outputs about 21uV/ºC. 200uV noise will be 10ºC noise!. 1mV will be 50ºC noise!
Some people put a schottky diode between GND and the heater to kill the negative spikes.
Ksger uses a led to clamp the voltage! I don't like that. I doubt a led response is close as a fast signal diode.
I also thought in the classic DVD screen saver a thousand times! :-DD
-
good Idea :)
However, it's not there for a reason. Usually the lowest reading will be 70-90ºC. With the tip completely cold.
There's nothing that can be done. Below 100ºC, the thermocouple output is almost null.
All you have then is the amp offset and noise being amplified.
And will differ between boards...
Maybe I can make make something like a warning, "HOT", if the reading is above 120ºC.
-
Yep, i dont have oscil but i guess there is something wrong in stock transistors causing spikes.
power rail is solid , i placed dual ldo to negate noise.
tested on looong adc delay. result is a bit sloppier power up ramp compared to fast pwm cycle, and idle power % is higher, can go up to maximum power output even for small tips. but also is see advantages - fast max power output, and temp tip looks much more real - it can drop 100c down while in tea. no overshooting and fast switching to idle.
test run:
settings
(https://i.imgur.com/0KkrJ8a.jpg)
idle run (power % is a bit higher than usual)
(https://i.imgur.com/n5C3IgO.jpg)
tea boiling - easy go to max power even for small tips
(https://i.imgur.com/DeYTTwG.jpg)
going back to idle - nice curve
(https://i.imgur.com/FSeE3KN.jpg)
-
Maybe I can make make something like a warning, "HOT", if the reading is above 120ºC.
This would be great and absolutly enough :D
Thank you!
-
You have to adjust the delay until the spikes start again. Find the limit.
It's "real" because it's putting a lot less power on it and can pull heat out as it gets generated. Simple as that.
For 200mS PWM, every 10mS delay you rest 5% of power. 100mS delay will use only 50% of the power. So about 55W.
That's what I said about using it with 30V. The tip will get hot inside no matter what you do, it can't get rid of so much heat.
24-25V... doesn't make a difference. 72...78W. But 110...
The heater has thermal mass. Doesn't need high frequency PWM. The stock FW used 1KHZ PWM.
Why? 5Hz is perfectly fine.
The tip temp is read after every PWM cycle, so the delay also applies.
if you set 50mS PWM, you'll be subtracting the delay to each 50mS cycle.
So don't touch that because is just useless. Only increase de delay in 10mS steps until you find it does ok.
Then you could make some fine tuning, but always leave 1-2mS extra.
-
What about this? Moreover, slightly bigger icons. It's a solder station, it's expected to be hot at any time ::)
I also added a new option to disable automatic dimming. If you want to burn your oleds its not my problem!
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1213573)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1213575)
-
so you say that delay is after pwm cycle, adding idling time, resulting in huge power loss? i thought it was inside pwm duty cycle for better power control.
heater shouldnt overheat with proper pid settings, because termocouple is part of heater itself. even 110watts are not enough to overheat in 0,2 secs.
heater has thermal mass, sure, but thing about pid and so on is about algoritmically detect how much heat is drained from tip end and add power to avoid drops. thermodynamics says that thermal power is affected by temp delta. so its important to detect temp drops as fast as possible and build proper temp/power curve. t12 are definetly not best soldering tips, but are enough powerful and responsive. principles apllied on t12 tips are also apllied on better solder tips like c245. c245 just have better heater-copper alignment, more copper and dumb thin coating.
for example i use W series tips, which have additional 1mm copper around heater. it makes tip end much more responsive. also most of my tips have manually thinned coating - genuine are coated with 0,2mm iron, so i shred off 0,1mm from each. fake ones are usually coated with 0,4-2mm iron, so cant transfer heat at all when you try to solder big copper something.
and yes, i wanna tune my solder station to a metcal level where u just solder everything with one universal tip. its not impossible.
If you want to burn your oleds its not my problem!
its already burnt on mine in like a week cuz 255 brightness by default was too much, and i had no normal sleep - mercury switch is located at the highest end of solder iron so any wire touch actually wake it up.
p.s. retested. fake tips show great temp readouts with any delay, even with 1ms (pwm set to 200). genuine oscilate like crazy.
-
I ensure you that the heater reading will be lot if you psh too much power. I ran it at 30V for a year, burned like 10 tips, tried a lot of things.
Finally I started working in the firmware project. You won't believe the hours in testing I've done on it.
Say whatever you want, the heater is not perctecly bonded with the tip, neither is the thermocopuple.
If you push all the power with the tip under water, you'll see bubles coming. You turn off the power and still will be bubbling about 1/2-1second.
That is the residual power. If you still think you can put 110W on it under weater and read less than 100ºC...Whatever, but dont' ask me when things don't go well! :-DD
Big tips do better, yes. K, KF, BC3 tips have thicker tips, but still read >150ºC usually in those conditions. Get a thin tip like ISL and you'll read >200ºC.
To the date, I only had one tip that had a nice thermal bond. I mean it woudl drop to 120ºC. Maybe original Hakko does better.
Of course, it's done inside the PWM cycle. But the delay time is included in the PWM cycle itself.
So the max duty will be (PWM time - Delay time). You can't measure while the power is on.
You must turn off and wait for the switching noises to dissapear(That's the delay time).
I suspect hakko uses a heater coil with thicker nicrom wire, more turns, thus more inductance and bigger inductive spike.
-
Yes, it's done inside the PWM cycle. But the delay time is included in the PWM cycle itself.
So the max duty will be PWM time - Delay time.
Now it explains almost everything. oscilations are real, and genuine tips show real heater temp. fake ones have improper heater-couple thermal connection and thus dont oscilate, they show temp not of heater itself but of casing. also i never checked tip wire clamps in genuine tips - caps there are very hard to dismantle.
-
Search the thread , there are waveform pictures of original Hakko vs chinesium.
T12 made a negative reading of almost 20mS before recovering.
-
Search the thread , there are waveform pictures of original Hakko vs chinesium.
T12 made a negative reading of almost 20mS before recovering.
oh thanks. i backtracked only 10 pages but ppl actually noticed weird oscilations 20 pages back. on different boards, so OP or diode/mosfet gating isnt root of a problem. i have some guesstimate about genuine tips, need some testing
-
If you read carefully, you'll see that a lot of people just touch every setting without knowing how it works.
Also as this is development, sometimes something sneaks in and causes new issues.
But as I say, if you put a lot power, you'll get oscillation more easily, you will need to reduce PID factors, because 10% of 70w is not the same as 10% of 110W.
You should know these things before starting modding. Lower P term to maybe 30, or 20. There's always a value.
Anyways, understand that I can't solve everyone's problem, this is a free fw, not a JBC customer service :-DD
-
trying to get back to work. i have another eye surgery now they need to do so i apologize if someone messages or tags me and i dont respond. but i did flash the newest ksger 3.0 tonight just to mess with it some. one thing is you can set it to shake to wake or stand to wake then there is a shake wake on or off? i would think if you set it to shake to wake then why would someone turn that off? so it never goes to sleep? just something curious. im not allowed to do any soldering for a couple weeks sadly they dont want the fumes to get in the eye.
a few asked me what they had to do and how i was doing (which is very kind thank you) they had to do radiation to my left eye with a plaque they sewed in / onto the sclera to kill a tumor. now there are some other surgeries to follow.
-
I will disable the shake wake entry in stand mode as it doesn't matter.
As I said, this only is to disable shake when already in sleep mode.
So you must manually use the encoder to wake up.
It doesn't affect in run mode, the shake input will keep resetting the sleep timeout, preventing it from sleeping.
About your surgery, man that sucks. I hope the treatement works and the tumor goes away.
Stay strong! :-+
-
changed led to low capacity(10 pf) shottky. delay now stops oscilating on 15 ms instead of 80ms.
nvm. rebuilt all the scheme from the scratch. put wrong amp dividers, got red hot 900C iron :-DD changed to nomial, recalibrated, no osciltaions on default settings. nothing more can be done without oscil, but i guess something wrong is with mosfets. why cant it just work
-
That's what you get from these chinesium things.
I put a very low voltage schottky (around 0.15V drop), didn't notice any better than the 1n4148 that was before. But the 1n4148 is very fast, with 4nS switching time. A led it's not.
Are you expecting zero delay? 15mS is pretty nice.
You can guess what the original firmware reads.
Maybe they pause for 100mS, but it's a really crappy solution.
Remember you are amplifying a very small signal where 100uV is 5°C.
You can't expect to suddenly turn it off and voilà! You have the heater and wires capacitance, inductance, also the power supply will for sure make a small spike due the sudden load release.
All that contribute to noise, and frankly speaking, it fascinates me that these boards get stable readings at some point with such careless design.
Just leave defaults, or don't complain!
You are not going to get anything better than that easily.
-
That's what you get from these chinesium things.
problem is about fake tips work with no troubles at all and genuine show strange behaviour. that just make me upset. by now i guess quicko boards with dual amp was good idea cuz it has filters. but my ksger board(3.3) is also same one newest quicko.
noticed that with iron disconnected i still see pulsations each pwm cycle and that ticking noise by end of pwm cycle. so ill grab some oscil and take at look at mosfets.
p.s. i think by this time i could already have built fully functional jbc board with their normal thermocouple control or even wire resistance controlled something no-need-for-pid-im-40khz-500w-glow-tip-in-2-sec
-
I think you need to stop for a moment, you're hearing bells from nowhere.
So you see pulses in the mosfet with no iron and guess it's a transistor problem.
Now the mosfets turn on themselves with fast pulses? :-DD
Have you seen the gate signal? Or the output from the stm32?
Pwm never turns off completely unless a critical error happens.
It stays at the minimum possible value, 1, equal to 10uS pulses for every PWM cycle.
That's totally intended. That's how the detection is achieved.
The small pulse charges the amp capacitor.
If there's no load, it will hold the charge when the ADC reads, making a very high reading and triggering the iron detection.
If there's load, it will read normal values again.
You can do whatever, but don't offtopic in this thread if you start doing something like that! Start a new one :-+
This is only for the firmware and their supported boards.
And 40KHz... For heating a resistor...? At that frequency you can make an induction heater :palm:
-
Hi to everybody,
At last I received my spare STMd and found some time work on it.
I'm experimenting on the same Quicko PCB as DavidAlfa.
1 - Changed original STM with Chinese STM32F103CBT6
2 - Flashed FW 7c4d613 for F103
3 - Removed C7, R11 and R15 from PCB. R23 is not there where you put it in the schematic, so removing C7, R12 and R15 completely isolate HANDLE_TEMP (PIN 4 of Iron connector) from the rest of the circuit.
4 - cut the correct track near U7, above the PCB VIA, as in your MOD, because I'm planning to use C245 Tips.
5 - Wired C19 to C7/R15
Now HANDLE_TEMP (pin 4) has become TIP_SENSOR_INPUT, isolated from HEATER
6 - Soldered a single pin of a 2.54mm pitch strip into pin 5 (HANDLE_SWITCH) of the PCB Iron connector where I can in future connect a "C245 Stand".
7 - Wired pins HEATER (pin 1) and TIP_SENSOR_INPUT/HANDLE_TEMP (pin 4) inside T12 IRON Connector, so that it can work just like a normal T12 Iron bypassing C245 MODs above.
Now my observations, some of them obvious and some a little less:
1 - With no Iron connected, whether T12 or C245, NO_IRON detection obviously doesn't work because there's no more pcb connection between HEATER and TIP_SENSOR_INPUT
2 - It still doesn't work with a C245 IRON connected because it doesn't have that wire in the connector with no tip inserted
3 - It works fine with modified T12 Iron but only obviously able to detect missing TIP and no missing IRON.
4 - I tryed some calibration with two different T12 TIPS and while there's no issues in the procedure itself I find some with the Thermometer sensors that are way too fragile and brake easily (non fiscally but in wrong measurements, especially abusing 450°C measurements!). You can find yourself making a calibration and not understanding why 5 minutes before you had got good measures and 5 minutes later much lower measurements.
So my suggestion is to reduce at minimum contact with sensors, just to take your actual temperature, then put your Iron in the stand while adjusting the calibration data in the station. I'll Come to a suggestion later for you DavidAlfa (just a try, I know you have already done way much to the project with your loooong work on it).
Here my calibration for T12
BL TIP
1439
1951
2723
K TIP
1447
1968
2490
5 - I then tryed with C245 IRON...
My 72W power supply in the station can't stand their current requirements and the station keep restarting. This is with Power on option set to RUN, otherwise I found no way to start the station in SLEEP mode and then exit from SLEEP with some sort o Encoder button pushing or rotating. Maybe I'm missing something here? Is there a way to manually exit from SLEEP the same as entering it whit press and CCW rotate the encoder? Pressing and rotating CW is for selecting TIPS, I see.
6 - I made a try with my PC power supply, 19V and 4,74A. That made it (but then I think I need a new PSU for my station anyway), I could make some C245 test.
6 - Tried to calibrate two identical ORIGINAL C245 TIP and, apart from Thermometer sensor as above, I could do it. Maybe in some way it was even easier.
TIP C245-944, Flat tip
1624
2199
2727
This values worked fine with the second identical C245 tip (good)
That is it for now. But as far as Tips calibration and Tips data saved I have some point to ask you and maybe to implement? (If possible, if you are like willing to do it and you think it usefull. And with many thanks).
Let's say add add some tips in the menu,
For T12 I add a K and a BL
For C245 I add -944 and maybe -xxx
Once you finish a calibration for each tip you get the calibration values
1111
2222
3333
You can see them just after the calibration.
Then why shouldn't I see these same data and shouldn't I be able to lightly modify them in the CALIBRATION, ADJUST menu for each Tip? I have a certain tip selected with it's own three calibration data, I think it would be much useful to be able to see and edit them every time I need it. Maybe to check them at the end if calibration if I have not taken note of them, or to fine adjust them from time to time without going through oll calibration process and so saving THERMOMETER sensors.
In CALIBRATION, ADJUST menu of each different TIP I always read the same generic T12 and C245 data, not much help.
Sorry for being so long and take my notes just as what they are, notes!
Once again, Thank You very much for you work. Thanks to everybody.
Here is my PCB after all MODs
-
I Will add a 1Meg pullup resistor to TIP_SENSOR_AMP input (now pin 4 of Iron connector, ex HANDLE_TEMP) to solve every NO_IRON Issues for both T12 and C245. I forgot that some Ksger unit has it (910K for the one I own).
Then I should retry calibrations and see how it will affect its values.
-
Hey!
Of course, if you isolate that pin you lose detection :D.
What I do is to join the pins inside the GX12 connector.
For the T12 I join heater+TC, and for the JBC I put a resistor.
That way you can change them on the fly.
But 1M is too high.
Since the minimum output is 10uS, you need to set a resistor that can charge the capacitor (was it 1nF?) in that time, otherwise it will start bouncing.
I don't remember right now what I had put there... I think it was around 100K?
About the features, I've thinking on such menu for a long time, but as the current firmware is using almost all the flash in 64KB devices, It'll be no easy.
I might end making a v2 firmware for 128KB devices only.
For manually waking up the station from sleep state, just enable button wake in the options. Then make a click to exit sleep.
(Entering menu or selecting tips won't do it).
Yes, the cheap K sensors are very brittle. When doing calibration don't cover the whole thing with solder.
That can short the wires and cause weird readings.
I usually fix the sensor in place with tape and put the handle on the table, touching the sensor.
Then add a little blob of solder and make the whole calibration without moving anything.
And yeah, asking 220w to a 72w supply usually won't work!
Try reducing the max power on the menu, first to something low like 20w, then slowly search the limit.
That will make shorter pulses and might avoid the power supply overcurrent detection (although it may, or not, go ka-boom! :-DD)
My Quicko has a 120w supply, the voltage ripples a lot with such loads, but everything works (goes down to 19V or so).
The stm32 supply stays clean so nothing resets.
I'm currently at the hospital for a surgery, so there won't be firmware updates for at least 2...3...4 weeks. It all depends on how it goes, wish me luck! ;)
-
hope it all goes great! i just finally can come back and you are heading in. we will see you soon enough im sure, good luck!
-
David, good luck with a surgery! :-+
-
Thanks! It's been a long-awaited surgery, I hopefully will get my normal life back :-+.
Anyways, I can use my phone, so remember I'll keep watching! :popcorn:
-
Good luck DavidAlfa, see you soon here at work! :)
-
About the features, I've thinking on such menu for a long time, but as the current firmware is using almost all the flash in 64KB devices, It'll be no easy.
I might end making a v2 firmware for 128KB devices only.
My Quicko has a 120w supply, the voltage ripples a lot with such loads, but everything works (goes down to 19V or so).
I'm currently at the hospital for a surgery, so there won't be firmware updates for at least 2...3...4 weeks. It all depends on how it goes, wish me luck! ;)
afaik all stms have 128kb, but not tested so u can push 128kb firmware with no guarantee of stable work.
quicko power supply have very low input capacity (40uf or 80). changed it to 150 and it works much better.
good luck! and take care of health, u know i cant just write new firmware for your body :-BROKE
p.s. noticed firmware is designed for warm countries only. switched my station on today morning and it beeped till temp rised to 20c
-
Most* do have 128, but i've seen a few with only 64.
No idea if they were genuine or counterfeit.
What temperature?
It shouldn't complain unless the ambient reading is less than -60°C. Was it the "NTC low" error?
-
Some interesting update from my soldering station.
I added 1Meg pullup resistor between TC input and 3,3V rail. Now everything is working fine as far as NO_IRON detection is concerned. With no IRON connected to the station this 1Meg resistor take 3,3V to the OP-Amp input saturatung it and letting the firmware detecting NO IRON is plugged.
This same 1Meg resistor seems to not affect in any way the station when you plug an Iron, whether T12 or C245. With T12 jumpered as expected from TC to HEATER you still has NO_IRON when no TIP is inserted, while inserting a tip just start the PWM as it is supposed to do. Same with C245, NO_IRON with no TIP and normal working inserting one (without any resistor in C245 GX connector).
Calibrated temperatures don't seem to be affected by this 1Meg resistor but still I have to take some precise and objective measurements.
Let's now talk about C245 and my 72W power supply. Actually my PSU is not a Quicko but a Ksger and has two 1000uF capacitors on its output. Lowering the station power doesn't help much in my case and at the end I let it set at 80W both for T12 and C245. But I found a way to be able to use my PSU with C245, even if temperature rising is obviously not as short as 3 or 5 second of a JBC station. Experimenting a bit, this is what I noticed. Setting the station to a high temperature, like 450°C and Power-on setting on RUN is the worst situation. When you power on the station it keeps restating, no way until you power it off, unplug the tip (or the cable) and power it on again.
Setting the station to a low temperature before powering it on can make C245 work. Not much current request right from the start let it power on as it should. Then you can rise the temperature up to 450°C with no problem. Just be aware (and I don't mind at all) that from cold to 450°C takes about 25 seconds.
NOW the real news about this issue. If you set the station to always start on sleep mode, even with 450°C previously set, when you push the encoder to exit from sleep everything works FINE, NO STATION RESTARTS, even starting from a cold C245 TIP (same 25 seconds to get to 450°C).
Conclusion is that maybe many issues of such kind could be solved even with the station set on Power-on RUN mode by letting it go through a little "sleep time" before starting PWM output.
Just one last note, if I manually set the station on sleep, when I insert a TIP it automatically exits from standby. I don't know if I like it. I think manual sleep should override every other automatic run mode. Manual sleep only exit by manual Run. At least for C245 handles that doesn't have a shake switch to care about. Two way of changing tips.
1 - Manual sleep, change tip, manual Run
2 - Station running, extract tip, insert new one and automatic run.
Always long posts from me, sorry :)
Attached my new 1Meg Mod (in R11 place with a white wire to 3,3V).
-
Yes that also works. I think I tried with 10M and it worked well, too.
-
huge thanks for 1m res mod. made same way today and now happy with jbc tips :-+
-
ill have to try this for the 245 tips. does this work for the ksger 3.0+ boards as well i see it on the older boards here. thanks
-
There is a problem, before this was not. The station works well, but there is a ticking sound and a green LED is blinking on the control board.
KSGER T12 STM32 V3.1S
-
It's normal, that's the active iron detection.
It was wrong before and wouldn't work perfectly.
The noise you hear is a very short pulse checking the presence of the load.
I might add an option in the future to disable active iron detection for boards that have a pullup resistor in the amplifier.
-
Well, I got better and I was sent back to home for a few days.
The surgery was postponed until Friday, so I had a some time to spend into the project.
Changelog:
- New icons. Increased size slightly as there was plenty of room. The shake icon is now drawn in the top center.
- Increased screen dimming timeout to 15 seconds. 5s was a too fast and usually annoying.
- "HOT!" warning in sleep mode if the tip reading is >120ºC.
- Ignore No Iron error when the station was already in sleep mode, so the tips can be changed without waking up (If Shake wake option is enabled, it will wake up anyway).
- Added Active detection option, so PWM can be shut down completely when in sleep mode. Iron detection will only work if the op-amp has the ~1M pullup resistor!
- Removed PID menu, added Tip full settings menu (PID values and specific calibration values). It can be accessed by long-clicking when in Tip selection or in Edit tips menu.
- I don't remember if I already mentioned this. When editing a widget, small step is normal rotation, big step rotation-while-click.
- Updated Quicko schematic, minor corrections.
As always, builds updated in their respective folders.
There are two minor aesthetic bugs that I noticed too late, when I already had updated the builds.
- The shake icon might overlap momentary if it was active and the system goes into sleep mode.
- Ignoring the iron detection error while in sleep now causes the "HOT" warning to appear when removing the tip.
Also I forgot to hide "Shake wake" option when set in Stand mode. It had no effect in that mode.
They will be fixed in the future.
Remember that Calibration Menu values are not the same as the ones in Tip Settings menu:
- Tip Settings calibration values are the tip-specific, already temperature-compensated values, generated by the calibration process, and used when reading the tip in normal operation. Normally, you can safely set or restore this value from a previous calibration.
- Calibration Menu Adjustment values are the default value used when calibrating. Has nothing to do with the stored individual tip calibration, their purpose is to be somewhat fail-safe. So if the specific stored values are wrong, you won't burn the tip.
-
- Added Active detection option, so PWM can be shut down completely when in sleep mode. Iron detection will only work if the op-amp has the ~1M pullup resistor!
- added Tip full settings menu (PID values and specific calibration values). It can be accessed by long-clicking when in Tip selection or in Edit tips menu.
wow, amazing! no ticking while in sleep :=\
and individual tip adjustment is great also. cuz we already have "profile" from menu with global adc calibration, and now its finally usefull to have minor tip calibration.
works like a charm on jbc c245 with pwm cycle 22/2 delay. it is BIG FAST. 1ms delay is a bit noisy. i guess more speed could only be achieved if going AC with dual drivered fets, but not necessary - speed of copper heat conduction is already achieved. only thing i should worry now with jbc tips is getting rid of ac voltage on tip.
p.s. maybe small fix - set default screen brightness like 127 instead of full to avoid burning by default.
-
One thing is adding new options or features, other is personal likes.
You only have to do it once, takes 10 seconds, so just set the brightness yourself. Not all OLEDs have the same brightness.
For example, my last OLED is pretty dim even at max. You must think globally, not for you.
Individual calibration has been always there. The only difference is before it was an internal-only ajustment not accessable by the user.
It's is not meant for manual calibration, only to restore a known value from previous calibration. Otherwise you might get a red hot surprise...
"Profile" is just what it means, a different "slot" in memory with its own iron and tip settings.
I don't get what you mean with global calibration, there's no such thing. The only "global" thing is the default value at calibration time.
The calibration result is always stored per tip.
The noise is related to the power supply, and it will get worse with higher loads.
If you're overloading the power supply with 3x the rated power... guessed it?
The capacitors / tranformer will make this noise as there's a sudden and quick discharge.
If I set it to less 50mS, it also becomes a lot more noisy. That's exactly why 5Hz is used by default.
That's the best noise / performance spot. 5Hz is fast enough for the PID to react, while the noise is barely there.
Again, 22/2 are your settings, so you're at your own if any issues happen. The noise will be more audible as you rise the PWM frequency.
You should have heard the factory Quicko Fw running at 1KHz... even the tip was buzzing :-DD
-
And the noise is related to your power supply, also you're overloading the power supply with 3x the rated power.
"Profile" is just what it means, a different "slot" in memory with its own iron and tip settings.
I don't get what you mean with global calibration, there's no such thing. The only "global" thing is the default value at calibration time. But the calibration is always stored per tip.
i use meanwell 150w psu. it doesnt overload even on cold start. but have big bunch of X Y caps.
by "profile" i mean selection in settings menu, where 3 profiles are - t12, 210 and 245. they store all settings like wake/shake/etc AND adc values too. this makes it more viable then individual tip selection. i would eventually prefer tip selector as plain temp compensation value (like +10c/-15c etc).
p.s. ive seen 1 solder station which had possibilty of using different type of solder irons and it had built-in resistor in handle connector to detect type of iron connected and preload profiles. is it possible to make something like this on actual stm boards with usage of shake switch wire or its stm32 pin is digital only?
p.p.s. even in last month your firmware got very much updates and now looks far superior to and competitors customs and factory ones, by now im really happy and greatly appreciate your work.
-
I already mentioned that long time ago. But the wake pin is digital only.
ºC adjustment will never be done. Because we have different hardware. Some boards will have higher amp gains that others.
Even same boards will have slight differences. So you never know what ADC change corresponds to 1ºC.
I repeat you should't adjust it that way, use calibration for that, it's more precise.
I get 4ºC max error between 180-450ºC.
Also I will change the Tip name editing from the Tip setting itself.
As you seen in the top of the menu.
-
oh i get it.
i ask about this things because eventually in genuine products u dont have any "individual" calibration at all. all the thingys are tied deep in firmware so operator/user shouldnt ever think about this because manufacturer already did all the "calibration" work. this is the way high-end products should be done. and that chinese bells and whistles are not.
-
Want a professional-like high end calibration, testing and research?
Remember the resources I work with. I don't have a 100m2 workshop full of equipment.
I'm not going to spend any money to make people over internet happy. I already spent a lot of time on this. I'm a human after all, and I have a life.
And the hardware capabilities of a cheap T12 is not even remotely close to a professional station. So don't make such ridiculous comparisons. There are a lot of limitations.
Little more work, fixed these small cosmetic bugs.
- Now the tip name is edited from the tip setting edit menu itself (First menu item, clicking over the tip name).
- The Edit Tips menu no longer uses long-press feature, just simple click to enter the settings for the selected tip.
- The main menu tip selection keeps the long press to edit.
- Added tip name checking to avoid adding a tip with a name that already exists.
- After returning from the menu, always go back to temperature display (instead returning to the tip selection again).
- Hide shake wake option in stand mode.
- Lowered the default T12 450ºC calibration value, as it was too high for some boards.
Binaries updated. I think I'm almost done with it.
-
More work in the encoder button debounce. It still did some unwanted actions from time to time.
I used a different approach now, I think it's completely fixed now. Some optimizations here and there.
Edit: I checked all the other ksgers boards. It seems that all v3.x / v2.x are compatible with the existing v3.1 and v2.1 profiles.
Only the original v1.5 was different and needed a new profile, so I made a new profile for it.
Now I would say that all controllers are supported. I don't have the hardware, so status is yet unconfirmed.
Any feedback will be welcomed!
Update the documentation to reflect the latest features.
-
Thank you once again DavidAlfa, grat work!
Really thank you for spending your time in this project. I haven't tried last update but I hope to do it next weekend. I think this station with your firmware will be my definitive solder station.
And again, Good Luck for next Friday!
-
So, I'd like to get a T12 soldering station that runs this firmware.
For background, I've been soldering for many years. I built my first kit in high school, a Heathkit vacuum tube voltmeter. :) But, I'm really a software guy to be honest. I've had a Weller WES50 for many years, but I'm sure these new devices can be much better. I've been looking at the Quickos. It looks like the one to get is this one because it calls out the STM32 specifically.
https://www.aliexpress.com/item/32994824865.html (https://www.aliexpress.com/item/32994824865.html)
But, they seem to be using a compatible CKS microcontroller because they can't get real STM32s. Is the compatible one ok or should I wait for a real STM32? Or should I consider something else? I really want to be compatible with DavidAlfa's firmware. Thanks.
-
Cks should be compatible, however I don't have any for testing.
In the worst case you'll have to replace it when the production resumes.
-
What's up guys? Last update for at least some weeks.
I received the black aluminium handle. Very nice and comfortable! Nice buy for 10eur. The mercury switch works a lot better.
Then I modded my Quicko to put the NTC inside the handle. After that, I noticed a lot of noise in the ambient temperature reading, +-5ºC jumps.
When I checked the signal with the oscilloscope, I saw that the was a 200mV drop in the gnd wires.
So I simplified the ADC, now everything is sampled at once after the ADC delay (When PWM is off). NTC reading is perfect now.
I should have done that long time ago, since that was designed when the delays where a lot lower.
After all the research the delay was increased to 20mS, so +100uS for the ADC conversion is perfectly fine.
The latest optimizations did so great! There's still ram for at least 9 more options while keeping compatibility with 10KB RAM devices.
So think something to spend that free memory! :-+
I feel sad for a russian user who wanted to contribute by adding standby mode.
He made a pull request when I already had most of the code working, with only a few bugs left before releasing!
- Added adjustable Low Voltage Protection. Allows 9.0-24.0V limit. I don't recommend going below 12V, specially if running a JBC tip, you mosfet might heat up more than the tip itself!
- Standby mode is back!. Added standby timeout and temperature options.
- Enhanced stand mode. New option for selecting idle mode. So the handle goes into sleep or idle state when going into the stand.
The timeout is still applied, so if the handle is left for a long time, the system will go into idle and sleep mode anyways.
- The encoder works as usual. Click and rotate anti-clockwise to enter idle modes. First time will enter standby, second time will go into sleep mode. Also in stand mode.
- Boot mode option is only displayed and used in shake modes. For stand mode, the first WAKE reading at boot time will be used to determine the starting mode.
However, my new tips are doing terrible. ANything over 390ºC will cause them to go crazy. I had to increase delay to 50mS!
-
Don't update yet, something's wrong with the ADC!
Edit2: almost OK. While changing the PWM still can cause a crash. Not a serious problem, it won't burn your tip, and it doesn't happen when running.
I'll check that when I get back. I have 2 hours left!
There was a long-time bug I noticed just now because adding another check.
Saving settings to the flash takes a while, so the interrupts would overlap some times. Moved that part outside of the interrupt.
Also the ADC was being stopped incorrectly. If DMA had finished, HAL would wait for a long time, just waiting for it to finish? Why?
Gave some extra timing room for the ADC to ensure PWM never turns on while converting.
With these changes, now the reading are a LOT smoother. At least in my case.
The delay does a lot better now. These nasty spikes don't appear so often. Now I can run 5 mS perfectly fine with my T12.
However, remember that a too small delay might cause a reading offset because the signal didn't settle completely.
You can try to calibrate anyways, then ensure that the real temp doesn't drift too much in the whole range.
EMA is still required, the raw readings have ~5-20ºC noise.
Now the PID seems to be smoother too. More aggressive settings can be set without causing trouble.
These are my last values. Seem to work great with big and little tips.
Kp: 80
Ki: 45
Kd: 30
Imax: 0.60
Imin: 0.00
-
Huge thanks again! You do update so fast i cant even flash them same often.
so ny question is - i start freshly flashed, select profile, then go to manual calibration, set adc points with 100s step. then i go to tip calibration and set them with 1 step. is this correct way?
-
No! :-DD
Go to calibration adjustment and make a rough aproximation for 250, 350 and 450°C steps.
This is only needed on the first time after flashing or resetting the tip profile.
Save and start calibration normally.
The calibration values in tips are just for viewing or restoring from and old calibration.
The calibration process adjust these automatically.
Read the operation manual!
-
why no?
in main calbration menu i cant set adc values in steps less then 50 (not 100, rechecked) , but in new "tip calibration" i can adjust in steps of 1.
-
Do whatever you want then |O
You asked something, I answered.
-
The calibration values in tips are just for viewing or restoring from and old calibration.
so they dont change anything ? why then this submenu is added? :-//
-
I've said that a dozen times!
-
https://www.youtube.com/watch?v=l7mDah2jRSI (https://www.youtube.com/watch?v=l7mDah2jRSI)
video does not work. Can anyone post video about this firmware?
-
Surgery done! All went fine (for now). :-+
Now I'll staye here for maybe 2 weeks to ensure everything goes ok.
Not a problem, there are a lot of pretty and young nurses :-DD
-
https://www.youtube.com/watch?v=l7mDah2jRSI (https://www.youtube.com/watch?v=l7mDah2jRSI)
video does not work. Can anyone post video about this firmware?
I deleted the video because it was old and very different, but I didn't made a new one because things were changing too fast!
Hopefully someone can make a video :D
-
I would like to see what this firmware has to offer, how does UI it look like. How does it compare to https://github.com/wagiminator/ATmega-Soldering-Station
-
Just flash it and try yourself.
The ksger firmwares are everywhere.
No, I don't use fancy graphics.
-
Just flash it and try yourself.
The ksger firmwares are everywhere.
No, I don't use fancy graphics.
Are there at least screenshots of what it looks like?
-
Search back in the posts, there are some videos and pictures. Won't be exactly the same, but it's close.
This project will be unatteneded for several weeks for the said surgery and recovery.
-
I would like to see what this firmware has to offer, how does UI it look like. How does it compare to https://github.com/wagiminator/ATmega-Soldering-Station
it has full support of jbc handles(pace ads200 handles should work too),sleep switches by handle/stand, speedy and accurate temp control with no overshoots and tweaks for better work, power limits for use with low output PSUs, profiles for quick system/handles change, work with lessest components(no eeprom, 1 channel OA), and flashes on factory built boards available everywhere. it also has 3+1 fancy icons for aestetics.
-
Go to calibration adjustment and make a rough aproximation for 250, 350 and 450°C steps.
This is only needed on the first time after flashing or resetting the tip profile.
Save and start calibration normally.
The calibration values in tips are just for viewing or restoring from and old calibration.
The calibration process adjust these automatically.
I've said that a dozen times!
Acually you didnt explain all the process exatly. calibration process is made really good but your explanation is contrintuitive. i asked about restoring values after flashing w/o using thermometer every build release.
So to restore backup using only paper with 3 digits u have to do this
1)in profile calbration menu set appoximate values in steps of 50. this values dont copy on tip calibration.
2)to copy values press start calibration, just set temp to 250/350/450. no need to use thermometer.
3)go to tip menu, and adjust adc values in steps of 1 to finalize backup restore.
i guess if someone really use "tip menu" he should select another tip and only redo steps 2 and 3. cuz "calibration" do copypaste. Pretty smartass bypass of tip burning and avoids using electric drill to rotate encoder thousand times. :-DD
p.s. when system reaches standy temp buzzer beeps. so there is room for coding, but dont actually bother.
-
Hi guys! Just to let you know I'm not dead yet :-DD
First week recovery was really hard, also had some complications, but now it's getting better everyday.
If everything keeps going well, with some luck I'll be sent back to home in a week or even less.
There are another 2-3 months until full recovery (a year for any high intensity physical activities like training, lifting heavy weights... Running is ok) but I probably be back to the T12 battle in the next 2 weeks.
Cheers!
-
Glad to hear that Davidalfa, wish you will recover soon!
-
wishing you a speedy recovery!!!
-
OK so i've looked through all the pages (OK didn't read every line) but complete noob here.
If i want to flash one of my two Ksger 3.1 stations how and where do i hook up onto the board?
These are the two boards i have,
(https://i.imgur.com/bXFnAoQ.jpg) and
(https://i.imgur.com/jXn9ulm.jpg)
I've been having issues getting the tips to calibrate and stay that way :) so thought wouldn't hurt to try flashing some custom firmware.
-
See on the upper left corner, where C5 is?
C(Clock, SWCLK) D(Data, SWDIO) GND VCC
That's it :-+ .
If It refuses to connect, short the reset pin to GND, click erase and release.
Will take some tries...
Check the stm32 pinout, and where does nRST pin go to, I'm pretty sure it's connected to C3 or C4.
Shorting the capacitor with tweezers should work.
-
Thanks, thought it was them but just checking.
Now to wait for my extra cables to arrive to solder on and give it a try. :box:
-
I'm back to home! Hopefully will fix the ADC issues soon.
I get a random jump every 10-30 seconds, I guess something causes a delay making the ADC to measure when the PWM already went high.
I'm playing with the interrupt priorities, as they weren't optimal (OLED DMA takingover ADC DMA, for example).
Else than that, it's pretty much done.
-
It seems the issue was caused by a combination of too tight ADC timing and the SPI/I2C hardware IRQ having higher priority than the ADC and timers.
I hope it's done now. Updated the builds.
Some waveforms, as now I have new DSO! ;D.
First pic:
Input of the ADC pin.
CH2 is a debug pulse, set high when ADC starts, set it low when ADC ends.
Second pic:
Zoom in. ADC conversion takes around 160uS. There's ~140uS clearance between ADC conversion end and PWM start.
Previously it was 10...20uS, but there was some jitter. I suspect it was caused by the display IRQ.
So if the jitter was too high, it caused the ADC to read when PWM was already high.
I couldn't catch this issue, as it happened once every 5...20 seconds. Hard to catch, but I smelled it!
Third pic:
You can see the ADC sampling noise (18 readings). That's why you need a nice ground and low impedance path to the ADC!
Try these pid settings:
Kp: 120
Ki: 50
Kd: 20
Imax: 0.5
Imin: 0
Seems to improve response! For me, it's very stable and responsive now.
-
I'm experiencing some unexpected behaviour during initial calibration adjustment (before starting calibration) - the tip temperature (the real one, not the station measurement) goes insanely high (>500C).
It does not seem to be related to preset ADC values, as after starting calibration real temp is ~50% of temperature set by station.
And a small feature request: how about implementing screen flip option?
-
Did read the manual? There's an adjustment to avoid that.
As there are different stations, there are also different readings.
After first flash, you shouldn't adjust the temperature high, because it needs calibration.
And before entering calibration, you should go into calibration adjustment.
Why? Imagine that the default calibration step for 350°C sets your tip at 480°C. What will happen in the 450°C step? It will burn the tip for sure.
It's impossible for me to know what your station will read.
And nobody is helping by giving any feedback with calibration results, so it's the best I can do.
People simply install the firmware and go away, or complain here about something that is been said a lot of times.
I can't make it better that way...
So enter calibration->adjustment, and there adjust the values for the 250°C, 350°C and 450°C steps.
These values are applied in real time as you adjust them, so be careful. Move them slowly and carefully monitor the tip temperature. Once you get +-10°C, it'll be enough.
Doesn't need to be very precise, the calibration itself will do the fine job.
Once you adjusted them, save, and run calibration (Start).
Adjust the mesures temperature when asked, but wait until the tip temperature stops moving, it can take 10-20 seconds.
About the screen flip. It wouldn't be hard. Is you screen flipped? It would be the first case I'm aware of.
-
Did read the manual? There's an adjustment to avoid that. (...)
Yeah, I know. What I was trying to say is that heating goes crazy when i go to Calibration/Adjustment menu.
Outside of that everything works as expected with preset (low) ADC values - real tip temp is about half of what is set.
//EDIT
I have repeated test more carefully and narrowed it down to: Temperature rises uncontrollably when I'm turning the encoder in Adjustment menu. The longer turns - the more it rises.
Encoder handling messes with PID control?
//Edit #2
this is signal captured at mosfet gate during normal operation
[attach=1]
and during encoder rotation in calibration adjustment menu (without saving anything)
[attach=2]
Is you screen flipped?
No... But it will be, when i mount controller with encoder on the left;)
-
What's your controller?
What are you doing exactly in the adjustment menu?
If the temperature rises too much, then lower the values quickly, and start rising slowly.
For example, if cal250, with default value of 1400, already sets your tip way hotter than 250°C, what you should do is quickly set the value much lower, ex. 500, and wait for tip to cool down. Then slowly rise the value again.
When you go into 350 and 450 steps, do the same quickly.
If you tell me the calibration results I could set them as default for that controller, avoiding the issue.
The encoder changes the value, does the value change itself like crazy?
-
What's your controller?
ksger 2.1S, ksger 3.1.
What are you doing exactly in the adjustment menu?
adjusting value, constant ,fast rotations. for oscilloscope test it was half turn left, half turn right repeadedly.
For example, if cal250, with default value of 1400, already sets your tip way hotter than 250°C (...)
It is not the problem of default values being too high. In fact, they are too low, just as intended.
Default 1000ADC @250C gets tip temperature to ~130C, at 2000 for 450C, tip goes up to 240C, so there's no issue here.
The encoder changes the value, does the value change itself like crazy?
no, proper increments/decrements by 50.
If you tell me the calibration results I could set them as default for that controller, avoiding the issue.
2086, 2976, 3867 (ksger 2.1S, green PCB)
But I wouldn't trust it too much. I own 3 different KSGER controllers and none of them matches schematics found on the web, including opamp feedback resistor values.
-
Where's the problem then? If the calibration is too low, then adjust it.
I don't understand what's going wrong. How is the temperature going over 500ºC?
Some board pictures might help.
To flip the screen you'll need to recompile.
It's not hard, there are instructions and video, it only takes 5 minutes.
To flip the screen go to Drivers/graphics/ssd1306.c
Change these lines
write_cmd(0xA0|0x01); // Set Segment Re-Map
write_cmd(0xC0|0x08); // Set COM Output Scan Direction
to
write_cmd(0xA0|0x00); // Set Segment Re-Map
write_cmd(0xC0|0x00); // Set COM Output Scan Direction
Compile and done.
-
I don't understand what's going wrong.
Uhh... so, let's say I'm starting adjustment for 250C from default 1000. Real tip temp is ~130C. Everything ok so far.
I know that the value I need is 2086, so I'm turning encoder up to 2050. That's a lot of turning and during that, measured tip temp goes unexpectedly high, 400-500C.
Can't get that any clealer. But if nobody else experiencing this issue just forget it. I don't recalibrate too often.
-
Remember to push and turn for big steps.
Do it slowly. Every step should increase the temperature slightly.
Try to find the point where it starts going crazy.
-
Hello David. im here to ask, could i swap from i2c bus screen to spi one on fw for 2.x boards? or should i use 3.x instead?
-
2.x screens have only 4 pins, can't be used in spi mode.
-
2.x screens have only 4 pins, can't be used in spi mode.
your answer is not for my question. ok, ill simplify it.
do fw 2.x have spi screeen support?
-
All fw are the same thing. Each board have their own adjustments in board.h
The screen interface is set at compile time, so setting i2c, spi etc will disable the unused code.
You need to compile your own. The whole process is highly documented and explained.
-
thanks! so if i want to make some minor board adjustments i have to recompile fw to fit it.
-
Exactly. Learn and do whatever you want.
By no way I'm starting to make customized firmwares for everyome, I have life :-DD
-
I thought I'd mention my experience so far. I wanted to order a soldering station to run DavidAlfa's firmware specifically. So I ordered this:
https://www.aliexpress.com/item/32994824865.html (https://www.aliexpress.com/item/32994824865.html)
even though it says they're using a compatible CKS microcontroller for the time being since they can't get the STM32. I finally got it and tried out the original firmware. It didn't seem too bad, but the fonts are pretty ugly. :) So then I thought I'd try to back up the original firmware using the exploit documented here.
https://github.com/JohannesObermaier/f103-analysis/tree/master/d1-a/arm-cks32f (https://github.com/JohannesObermaier/f103-analysis/tree/master/d1-a/arm-cks32f)
After wrestling with OpenOCD some, I managed to make it work. I haven't tested it, but I did run it through "strings" and found some of the messages the firmware uses. I don't really expect to go back to that firmware anyway. So then I flashed DavidAlfa's firmware and ran into an odd problem with the flash being locked. Again after some wrestling with OpenOCD, I got it unlocked and flashed it without problems. I don't have much experience with it yet, but I've gone through the menus pretty well and run one of the tips some. These tips seem to need some break in before they are very stable. I'm going to do that before I try to calibrate them. At this point, I don't see a problem with the CKS microcontroller. Anyway, that's where things stand at the moment.
-
I accidentally burned my last working tip while making the Tip calibration values menu (To restore old calibrations), so I bought a 4 tip pack.
The tips are a lottery. I got issues with my last order.
They are a little unstable over 400ºC, anything over that and they'll start jumping +-10C.
It stays under control, it's justa little annoying. Neither a a big issue as I usually stay below that temps.
However one of them is specially bad, it keeps jumping between 400 and 700ºC no matter what.
I doubt it's a firmware thing, my last tips where perfectly stable at 480ºC. And I don't see anyone complaining ?
But yes, they usually need some burning time, normally no more than 15-20 minutes, but it depends.
I've had tips that never worked correctly, and others that were perfect out of the box.
Sometimes you can hear crackling noises as the moisture comes out, and the temps jumping like crazy, and after a while the temps get better.
I usually leave it around 300ºC for a while.
About the CKS: I think some stm32 clones had different flash layouts, so for running code there was no problem, but when writing to the flash within the firmware you could run into problems.
Thanfully that CKS seems ok!
-
@DavidAlfa, I've been burning in my tips at 300ºC as you suggested. But when I tried to calibrate, it was pretty clear that any temp over about 350ºC would cause the temp to run away and error out with a no tip message. Then it would recover and do it again. After looking over some of the previous thread posts, I increased the ADC Delay from 20 ms to 40 ms. That seemed to settle things down quite a bit and I was able to get a calibration. So it seems that my power supply is more noisy than usual, I guess. Do you have any advice about improving this? Is this something that might improve over time? Thanks.
-
That's a shame. I really like the actual firmware status, everything seems to work so smooth!
Can you attach some pictures of the board? From the listing pictures, it seems to be exactly the same as my Quicko board.
This is a dumb question, as nothing would work if you flashed the wrong FW. Are running the Quicko F103 FW?
Are you talking about real, measured 350ºC? Or the 350ºC calibration step?
Try something: Skip calibration. Attach the temp probe to the tip and slowly start rising the setpoint value, ex rise 20ºC, wait 10 seconds, and so on.
When the errors appear, note down the setpoint value and the real measured temp.
If the board is the same, then maybe the issue comes from the power supply.
My station came with the 108W version:
(https://ae01.alicdn.com/kf/H39bdd53000ff4d47ac6b09dc3c90d36co/QUICKO-fuente-de-alimentaci-n-T12-24V-108W-4-5a-para-Estaci-n-de-soldadura-LED.jpg_Q90.jpg_.webp)
https://www.aliexpress.com/item/32834572016.html (https://www.aliexpress.com/item/32834572016.html)
-
Yes, I'm running the Quicko F103 version of the firmware. And I get errors just running with too high a temperature or during calibration.
So, I did as you suggested. I reset everything to default values and started at 300ºC measuring as I went. Here is the result The first number is the set point, the second is what I measured.
300 343
320 372
330 390
340 409
350 420
360 433
370 413 (I changed sensors after this. I didn't trust it.)
390 448
420 464
I'm not finding these fg-100 clone sensors to last very long. And I'm not sure how much I trust them. While I was doing this, anything over 400ºC didn't hold the displayed temperature very well. I jumped the set point up to 450ºC in steps. As the set point increased, the fluctuations got wilder until it went up to 999ºC then said there was no iron. I need to order some more sensors to see if I can get something that I have more faith in.
I've attached pictures of my board and power supply. The power supply doesn't look like the same thing although I believe it was billed as 108W and is the same as the pictures of what I ordered. Anyway, that's my experience. Does any of this make sense?
-
Since it has a pot to adjust the gain, your board seems came with lower gain, resulting in higher real temps than requested.
I think I'm goign to set the default calibration values much lower by default, to avoid more issues like these.
It's better to get 100ºC at Cal250 step, than 300.
Please try the attached FW. After flashing, make a full reset by pressing the button before turning on the station.
Then go into Calibration / Adjust and set a rough aproximation there.
Save and run Calibration / Start.
And yes, the AliExpress temp probes are absolutely crap.
The one that came with my Uni-T DMM did really well.
I lost it, the others have given a lot of headaches.
Touch, you get 400°C. Remove and touch again, you get 370.
Clean everything , new solder, touch again, 385.
To make it worse, my probes came with the last 5mm twisted.
That's ok when you put the whole thing inside a hot oven, but when you measure a small spot, it will short out the voltage and read something on the middle. I got 150°C less!
After de-twisting it got better. But it's extremely sensitive to contamination.
Ex. The tiniest burned flux will stick to it causing lower readings. I have to scrape the small metal ball, ensure it's clean and shiny, place it under the cold tip ensuring that it makes enough force, heat the tip until it melts solder and play a bit with the position. After that I can crank the temps up.
But if the probe comes out at 450°C, putting it back will read 20-40°C less, requiring another exhaustive cleaning. Crap.
I think the probe wires are too thick, stealing heat from the tip of the probe, so any dirt will cause some isolation and wrong readings.
-
Anyways, after tearing your hair and clothes apart, the calibration is pretty good.
I've done it better, but getting these probes to work these showed to be a serious challenge.
-
Wow. That worked much better. I was able to get a quite accurate calibration, at least I think I did. I did it twice. The first time, I had to manually bump up 450°C three jumps to get it in the 50°C range. But after that, it worked just fine. So now I'm curious, could I have effectively done the same thing by manually adjusting all three settings lower? Or did you do something in the firmware that can't be adjusted?
-
Didn't you adjust these settings before? That's why they are there!
In fact, checking your results: "350 420", that one should fail because it exceeds 50ºC over the setpoint.
And the error message should clearly tell you to go to calibration/adjust and adjust the values.
In that menu, if the default values for 250/350/450 steps were 1400/1900/2200, and you were getting higher temps, what you should have done was to lower them.
I've worked a lot on this project, the only big issue that remains is the default calibrations values. Some boards get -100ºC, while others +70ºC
That is because for now the calibration values are generic. I could change the code so each board has its own values, it only takes 2 minutes.
But it seems nobody cares, I've already asked few times to the users to report calibration results, because I really need to make a database for it.
That way people could get nice, closer temps out of the box without needing the annoying calibration process.
But it'll stay generic until then.
-
You're right. I did have to adjust those settings to get the calibration that I got done before. I just didn't realize that I could have adjusted all of them much lower and gotten past it. Thanks for all your help.
-
I modified the readme, adding a FAQ section. Because some were really too frequently asked questions :-DD
-
Hi David,
I believe I have all the parts needed to modify and upgrade the controller.
I bought Ksger v2.1s and I already changed uC. Ksger version is that one with normal 3.3V regulator not a switch version.
Which modifications do you suggest?
Adding diode from MOS to ground?
Adding 1M ohm resistor from input opamp to Vcc as pullup?
Anything else?
I hope to assemble everything together and to start testing ASAP but lets take it slow so that I don't do anything stupid ::)
Any kind of advise is highly appreciated ;)
Again thank you for your effort in this project!
-
Adding diode from MOS to ground?
that could overload linear reg and gate transistor. i guess fet driver could be installed izi
-
How? We're talking about putting a diode in the source to kill negative spikes when the fet goes off.
-
How? We're talking about putting a diode in the source to kill negative spikes when the fet goes off.
diode on source is already onboard. but diodes are used to shut gate.
-
The diode in reverse polarity to the source and 1M resistor between the transistor src and drain (to ease iron detection) are the only mods I'd recommend.
Some boards already have them, others don't.
I don't have all the schematics in my head :D
-
Thank you all of you for any kind of reply. I like to "fight" with different opinions because sometime we can all have something out of it :-+
To make it all clear: I have Ksger v2.1s and based on the dreamcat4 and his EXCELENT github it is revision 1: https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled/v2.0-and-v2.1-original/r1 (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled/v2.0-and-v2.1-original/r1)
From looking schematic in that folder and my PCB (which is the same as on the pictures on that link) I can say a couple of elements are different (I only found R5 to be 249k and not 207k, R3 is 2k and not 20k, transistor driving MOS is not bipolar and is actually also MOS, R13 (10M) is missing on the board and voltage regulator is different) but schematic looks pretty much the same.
Looking into the schematic here: https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf) I think I need to change position of C8 (GND side to source of MOS - as on floobydust PDF) and add a RS1A. In case that is not ok, please let me know ;)
The only thing I don't know exactly where to put is 1M ohm resistor.
There are a couple of options:
- in parallel to C8 (between S and D)
- pin 3 of op-amp and 3.3V
- on the R12D before going into op-amp and 24V
Last 2 options... I don't know which is better but they are for future use in case I decide to buy and also use JBC tips. I know I will have to cut the trace like on the floobydust PDF but that is a minor thing.
David, which of the 3 options should be the best based on your knowledge and testing?
Again, thank you all!
-
In my case I can't do that because it's in the back of the PCB, I'd have to unsolder the GX12 connector and OLED.
So I did between the mosfet D-S pins, it works just as well.
Just put a 1M...10M resistor on R10 and you're done!
-
I desoldered OLED, connector where you connect GX12 and I took battery out because of plastic since I desoldered STM32 off with hot air.
If I understand it correctly: for T12 it is ok to solder 1M between S and D. When you have JBC you don't have a trace between MOS and opamp. And STM32 is reading output from opamp. Am I wrong?
So I will solder it to R12 and 24v (drain of MOS) which will be the same as on your case because I will use just T12 at the moment.
Thank you. I will keep you informed when I will put everything together and test it. After that is T12 test with a lot of tips. That will be for my friend to have a large base ;)
-
Why? You have the exact place in the board to solder R10. It goes directly to the amp, so it's the best.
Edit: I forgot, I no longer have the D-S resistor. I had changed it to 3.3V and direct input to the amp! Found alternative places in the pcb.
I didn't want to unsolder anything, because after lots of testings developing the firmware, I've done it few times already and the pads are way delicate now, some falling apart.
-
R10 is 4x 4k7 and is under oled when it is on. I don't know what did you mean by R10.
I thought you made a mistake and thought R12 which is R12d in floobdust pdf and is going into opamp.
So 3.3V and plus input of opamp it is :-+
After that oled, gx12, power cables, power supply, fw upgrade and first testing... wish me luck. Good luck to me :o
But first thing first... breakfast :-DD
-
Oops yes, I mixed R13 and 10M making R10 ;D
-
Oops yes, I mixed R13 and 10M making R10 ;D
"ksger pcb design" way :-+
-
That's a serious statement, mind your words!
You can't start calling everyone "ksger designer" ! :horse: :-DD
-
Dear Ksger designer :-DD,
Help needed...
I always have NO IRON displayed (if I change no iron from 4090 to 4100 I get 999C instead of NO IRON).
SW: 2021-06-02 (latest compiled)
HW: Ksger v2.x
Temperature sensor is working, shake sensor is working.
When there is no IRON inserted I see that LED is blinking brighter then after I insert the tip.
Before I remove 1 M or C8 or diode from S to GND... do you have any suggestion what should I do? HEEEEEEEEEEEEEELP ::)
EDIT: I removed 1M resistor and looks like it works. I will update you later...
-
Ensure that R13 was 1M. It's easy to make mistakes while reading smd codes.
1M should do nothing unless the tip is removed. Post some pictures!
Something you did created a strong path into the amplifier.
Did you put the diode in reverse polarity, right? Anode to GND!
-
R13 is 1M. How I know? I also measured it before soldering it on ;-) Actually it is 1.034M if I remember it ;)
As I already typed before: after removing 1M it started working.
Diode in reverse... well, of course ;-)
Attached picture is from before it started working. If I don't have 1M resistor soldering iron detect NO IRON perfectly. I don't see any problems.
But final solution is puting 1M resistor between 24V and R12d (4k7 resistor before going to opamp - pin 3) - on the attached picture marking with yellow.
I left everything on default except ADC values for 250, 350 and 450 C and I found a small "problem". Temperature is not very steady. It goes up and down around the set temperature but power is also not steady it also goes up and down. See the attached 2nd picture. I have to find our PID settings you left for us in one of the later posts and test again.
Anything else I should do?
EDIT: different tips and different PIDs don't change that power/temperature is gioing always up and down. I would guess that this should be almost flat power when you are near set temperature. Maybe I am wrong?
-
Don't connect it directly to the input, should be before the 4k7 resistor.
Check my Quicko schematics, R999 is the detection fix.
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/Quicko/Schematic
Let's say the 4k7 resistor is connected to GND.
You put the 1M resistor connected to 3.3V, making a voltage divider.
What voltage you get at the amp input?
The calcs give aprox 14.4mV.
14.4x250 gain= 3.6V, so you completely saturate the amp.
Even with 10M, you will offset the temperature by about 70°C (Remember it's just ~21°uV /°C).
Before the 4.7K resistor the load will be 8ohms when connected, adding only 21uV offset.
For 24V, use 10M instead, as 1M makes an offset of 191uV, about 9°C.
You have some oscillation, not huge, seems to be 4-5°C.
First read the GitHub documentation, then tell your situation.
There are some causes that can make that.
-
DavidAlfa has asked for calibration reports. Here is my attempt at a calibration report template with the values for my first calibration report. I've put it in a code block for text alignment purposes. Basically, the template maps to the calibration steps as I now understand them. It starts with adjusting the ADC values in real time measuring the temperature and getting it as close to the step value as possible. Then the calibration is performed. And last, the resulting ADC values are read from the Edit Tips menu. DavidAlfa, does this capture the information that you need for a calibration report? Do you want to make any changes in the format?
Model: Quicko STM32/CKS T12
Tip: T12-BC2
Calibration > Adjust >
Cal. Step 250°C
ADC Value 1100
Temperature 253°C
Cal. Step 350°C
ADC Value 1600
Temperature 354°C
Cal. Step 450°C
ADC Value 2100
Temperature 456°C
Calibration > Start
Edit Tips > (T12)
Cal250 1087
Cal350 1587
Cal450 2079
-
Yes, exactly. The more reports like this, the better.
If I see that same boards calibrate closely, within ~5% margin, then I could put them by default, so calibration would no longer be a must.
Getting 350 or 370°C... It's not a dramatic difference, the tip won't get cherry red.
The problem comes when it's 50...100°C difference.
Either not heating enough or burning everything.
Thanks! :-+
-
Wonderful. I was hoping that I got it right. The key for me was your new FAQ section where you mentioned that the ADC adjust happened in real time. That had not even occurred to me. :) Thanks.
Let the calibration reports begin!
-
You know, when you made everything, you assume a lot of things. I realised the firmware had become kinda complex.
Reading all the documentation, things I thought were there, were not. So I tried to add more details.
Anything not clear there, please comment. Anyone must be able to use it based on the documentation, without needing to ask.
-
Since I don't have a problem without a 1M resistor I removed it completely.
I always get NO IRON when I don't have any tip inserted even with that 1M resistor so this is fine for now.
I read your manual and you should put your information that you put here regarding uV/C and mV near opamp in your manual. It is a good point when something is not ok.
After that I went into settings and changed a lot of different parameters one by one checked how it reacted.
Yesterday I found out that my problem is related to lower temperatures and not to highest.
Then I bumped to ADC delay and PWM time. Lowering PWM time is basically how soldering iron reacts to temperature change but is limited with power sending into a tip. ADC delay is basically the same but lowering will give you more time to power inserting into tip but... here is where I found solution for my problem... On lower temperatures I had to set ADC delay to 50 ms otherwise I don't have stable output. Maybe around 45 ms is also ok, but I will play with that later. At the moment I have all settings set to default and ADC delay to 50 ms.
Here is calibration report for Ksger v2.1s with K tip - fake one (this is the tip I don't use at all and I wasn't afraid even if it got damaged ;) ):
Adjust:
1200 - 245 C
1900 - 345 C
3200 - 450 C
Cal 250 - 1459
Cal 350 - 2215
Cal 450 - 3213
I must also point that I am using a laptop power brick 20V/4.5A (actually 20.6 V) and it is not going to be my main power supply (I am waiting for power connector to put everything together).
Is it going to change any settings? We shall see :)
Also I must tell you I really like how fast it is turning on and response when changing anything :-+
I will keep you posted when I'll have some other testing done!
-
Huh, again the ksger gremlins :palm:.
For a moment disable I term, by setting Imax to 0.
Lower Kp to 45 and Kd to 10.
That should make it pretty lazy, but it serve to ensure it's not the Delay. Leave the PWM to 200mS, it's more than enough.
And check what happens with the Delay.
If you have oscilloscope, checking the voltages would be good too.
Not wanting to cause too much envy, but I've been using it for 2 days almost non -stop. It works really nice!
-
DavidAlfa, Thank you for supporting this project.
I'm here with a Quicko, exactly the same as StephenR0 shows us in the Reply #1065.
I'm not able to find a STM32F103 to buy (shortage due to COVID), so I use a CH32F103C8T6. I decided to switch the uCs because I couldn't figure out how to unlock the CK32F that comes with the Station.
The instructions you provided on GitHub and here make it easy, even for me that had never played with ST uC before).
During my tests I see some unexpected resets... even an error message was showed (I cant remember now)... I will investigate it.
Regarding the calibration processes the last set of messages here make it very clear, see below my calibration. A Fluke 289 + Fluke Type K and a FG-100 clone was used to measure the tip temperature.
Model: Quicko STM32/CH32 T12
Tip: T12-D24
Calibration > Adjust >
Cal. Step 250°C
ADC Value 1350
Temperature 254,5°C
Cal. Step 350°C
ADC Value 1750
Temperature 351,2°C
Cal. Step 450°C
ADC Value 2200
Temperature 447,1°C
Calibration > Start
Edit Tips > (T12)
Cal250 1450
Cal350 1955
Cal450 2350
-
Very nice and clear report.
Great that you easily understood everything by reading the available docs :-+
There's a noticeable difference from the Stephen results.
I guess it's the potentiometer coming in slightly different positions.
Note down any error you get! Maybe it's a CKS incompatibility? I don't know, never tested the fw in clones.
Is it working well now?
-
David, about Gremlins... did anyone else had similar problem like me?
I attached a couple of pictures. They are in pair and you can see what is going on at MOS source (yellow) and at opamp out (blue).
One pair is with your suggestions (Kp 45, Kd 10, Imax 0, PWM at 200 ms, delay at 20 ms) and the other... I forgot what exactly it was set to. I believe I set delay to 50 ms but I had Kp set to 80, Ki to 45, Imax to 0.60... I really cannot remember what exactly it was because I was trying a lot of things.
One more thing: after checking schematic from Quicko I noticed Quicko have a lot of small capacitors round the opamp. That could also eliminate some spikes that are seen on the output of opamp.
Also Ksger have a LED from (+)opamp to gnd and Quicko has normal diode + capacitor.
I need to find a lot of small capacitors and put them round the opamp.
What do you think?
-
It seems to be a lot of noise there. I guess CH1 probe was set at 10x, while CH2 was 1x.
Put the CH2 V/div (Out) much lower to better see the noise, set the trigger to CH1 fallig edge.
Then change CH2 to the amp VCC.
The out signal is about 5mv/ °C, there shouldn't be more noise than few °C, which gets filtered in the software.
I will explain a bit how the filtering works:
The ADC bit precision (LSB) is ~0.8mV.
It makes 18 samples, discards the highest and the lowest values, and makes the average of the remaining 16.
Then the EMA filtering is done. It uses an acumulator, applying a % of the old value and a % of the new value.
This works very well at filtering noise, but can add a lot of delay if the signal changes quickly.
To overcome that, I limited the filter range for ADC differences of to 200 between new and old values.
Between 200 and 300, 1 to 100% of the new signal is applied, so over 300 the filter is completely resetted using the last value.
200ADC is 161mV, ~32°C, that's the max noise the filter will filter. If you get huge spikes, then the filter will be resetted.
I usually get 5-8°C noise. Check my last pictures (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3581194/#msg3581194)
Your's seem pretty bad. I smell poor VCC filtering.
-
Thank you for your explanation and all suggestions. I read it and I will read it later today again when I will do the testing (after I get home).
Both channels are set to 10x, but I forgot to put probe for CH2 to 10x |O That is why you see higher voltage per division on channel 2. I know... just call me stupid :palm:
I don't know if I will have enough time before Friday but I will do a couple more tests and mods that I thought of. But I will set everything to default and do all the tests you suggested and also my own on default settings just to see differences between them.
I will keep in touch and THANK YOU! :-+
-
Then set the probe to 1x to better avoid the noise. There isn't high frequency there, so no worries!
-
Ok David,
Regarding the unexpected resets, after inspection of the board, measuring some voltage, etc I can’t find any hardware problem.
So far, the reset happens every time that I change the temp set. When the desired temp is achieved a reset happen.
I will continue to investigate, maybe measure the more relevant signals trying to capture the moment of the reset.
In parallel I’m trying also to flash the CK32.
I recorded a video: https://youtu.be/Ur_4IdlN1fE
Btw, The error message, that I mentioned in my first message, didn’t occurred again.
-
To me, it seems to happen when writing the settings to the flash.
When you stop changing things, including the setpoint, there's a timeout (Save Delay, default 5 seconds) before updating the stored settings.
It might take more time in this mcu, or maybe the writing algorithm is different and gets stuck somewhere, so the watchdog timeouts and resets the system.
The flash is one of the biggest differences in these clones.
Try going to settings, system and set save delay to 0 to disable it, then check if it still resets when changing anything.
Lucky you, I also got some CH32F103 blue pill boards, so I'll try to find the issue. Clearly a compatibility thing.
It's made by the same company that made the CH341.
The bad: Only chinese datasheet!
The strange thing is that the settings are actually being saved.
Hopefully it'll be fixed by adding more time or resetting the watchdog more often while programming.
Otherwise better that you know chinese, because I don't! :D
-
Chinese?! I should learn it :scared:
I believe you got it.
I changed the “System” > “Save Time” to the extreme settings (1s and 60s)
I conclude that there is a correlation. It’s more clear when I set it to 60s. The reset still happen, but after about 60s (temp already stable)
Btw, I’m very happy to know that it is the same manufacturer of CH341 :rant: :phew:
-
I'd set it to 0 for now to avoid any resets, not saving the setpoint isn't a big issue.
But remember that it won't save anything!
-
I did some testing yesterday and I didn't have time to upload anything so here are my pictures...
Everything was set at default for ADC and PID, probes are set to 1x (also in oscilloscope) and I did some test with different power supplies.
First 2 pictures are from the same power supply as I did all of my testing by now. It is a 20V 4.5A power supply for a laptop (I forgot which brand it is).
Then I tested with 3 other power supplies and each had different "problem".
In the last picture is a graph from a power supply that I will use with this controller but is "naked" :-DD
This is the power supply: https://www.aliexpress.com/item/32850805623.html?spm=2114.13010708.0.0.3a994c4dq6R8js (https://www.aliexpress.com/item/32850805623.html?spm=2114.13010708.0.0.3a994c4dq6R8js)
It is 24V 4-6A and is ok to use it up to 5.5A, after that protection kicks in.
Back to topic...
Yellow line is 3.3V from regulator but I measure it directly on pin 5 of op-amp.
Blue line is output from op-amp.
I have to tell you again that I modified this controller from the original with 1 added diode (correctly ;)) and 1 moved capacitor C8 (maybe 100nF?) to S and D on MOS.
Later today I intend to remove C8 and the diode to see what is going on but before that I will add some extra capacitors parallel to LED (between +op-amp and GND) and one in parallel to that 249k resistor (100pF as on your schematic) to see if anything changes.
Anything else I could do, David?
-
@RobHonn try the attached fw. It just clears the watchdog like crazy while writing to the flash.
Tugo, watch the 3.3V in AC coupling and much lower Vdiv, We need to see if there's correlation between supply and ADC noise.
Also measure 24V in CH1 (in AC mode) and amp output in CH2. If both have the same spikes, you know it's due bad filtering (Or C8, keep reading to know why)
Did you try the firmware before modding anything? Because not doing so is like searching in the dark.
You don't know where the problem comes from. You must ensure that your mods aren't the culprit.
I didn't notice the C8 thing before. I don't understand why put C8 between S and D. Originally it's between 24V and gnd, to filter trasients.
When the Fet turns on it will short out C8. Even 100nF can provide serious current spikes. Not nice!
A snubber is done with cap+resistor in series to dampen the spikes. And it requieres a lot of testing. But the inductive load here is very low.
But after switching off, the C8 will transfer all the high frequency noise from the power supply into the circuit. When the ADC is reading!
Set it as it was before. In any case, try putting a big capacitor in the 24V connector.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1228131)
-
"nonononono" :-DD Good one ;)
Why I did it? I did it to be like here in this schematic: https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf)
I will put C8 to where it was from the start and leave diode from S to gnd and first check if anything good comes out of this.
Then I will do everything you said that I should do, ok? :-+
-
Hmm. Maybe C8 there is smaller there. No value provided. Maybe 1nF, 100pF, but 100nF is too much
But doing so is not a good practice.
A proper snubber is done like this:
(https://i.stack.imgur.com/FUUR0m.png)
That one is for nasty inductive spikes, ex. flyback topologies in SMPS converters.
When the Fet turns on, the resistor limits the current, so the capacitor is discharged in a controlled manner.
When it turns off, if there's a negative spike, the diode will bypass the resistor, storing the energy on the capacitor, dampening the spike.
For not so harsh conditions, a properly tuned RC snubber tuned works perfectly.
And it's better than a diode because there's no response time.
Made some quick simulations, check the pictures.
The T12 heater model is roughly simulated as a resistor+inductance+capacitance. The values are empiric.
Tuning in this application is pretty easy.
At only 5Hz you don't have worries about resonances and those problems that do appear in the KHz/MHz range.
-
David, thank you for the quick new .bin file. :-+
My understanding is that the changes you did were effective for the reset issue.
I did set the “save time” to 1s, the reset didn’t occurred.
There is another unexpected behavior as you can see in this video: https://youtu.be/UPKiAZg0bRw
In 2:30 it happens, the uC understands a lower input voltage and the temps (tip and room) became messed.
Note that I saw this happen when I tried the .bin you post in message #1066.
That time I did some troubleshooting. The power supply (24v and 3.3v) did not change.
The tip temperature are not real. The PWM signal is lowered really.
I can’t figure out a reason, it’s intermittent and random, apparently.
So I returned to the version on GitHub. I forgot to mention this experience in my first message.
-
The only difference is the extra care resetting the watchdog while saving.
That's a really weird issue. All the values get shifted but remain stable. Never seen that before.
Keep using the test version, set Save Delay to 0 to see if the problem disappears.
Otherwise the readings are really nice and clean, no noise whatsoever.
Testing the CH32F103. Programming using the stlink takes 20x longer than with a genuine one!
However with their usb bootloader and WCHISPTool it only takes 1 second!
After modifying any option, keep moving the encoder until the saving timeout expires and the new settings are stored.
The screen freeezes for ~2 seconds. That was definitely the reset issue. The watchdog is set for 1 second if I remember correctly.
I'm trying with 2.5 seconds. But I can't set it much higher, otherwise the tip might burn dowm in case of a software stall/bug
I edited my last post, check "Quicko_CH32F103_Increased_watchdog.zip". Increased to 2.5 seconds, the CH32 doesn't reboot here
-
something really wrong with power. as is can see while temp is maintaned and digits remain stable, power line(at bottom) do waves.
can u plz make high res photos of board ?
p.s. some really quick thoughts - rotate psu power AC plug 180, detach ground wire from iron handpiece(in case u dont have real ground line in your AC socket at home)
-
something really wrong with power. as is can see while temp is maintaned and digits remain stable, power line(at bottom) do waves.
can u plz make high res photos of board ?
p.s. some really quick thoughts - rotate psu power AC plug 180, detach ground wire from iron handpiece(in case u dont have real ground line in your AC socket at home)
Those small spikes in the blue wave are caused by the ADC sampling circuit...
-
One thing that I thought I'd mention. I believe that I have a cks32f103c8t6 on my board. It's really hard to make it out, but that seems consistent with what I can read. Also, I had to account for the fact that it returns 0x2ba01477 instead of 0x1ba01477 in OpenOCD. After that it worked just fine. I've had no trouble programming it in the open source version of stlink, which has provisions for the CKS processor.
-
I've tried CKS before, no issues else than STM32 IDE complaining about non original part.
However the CH32F are a little diffferent, requiring some adjustments.
And better to not talk about searching timing and AC characteristics in the chinese datasheet...
-
Those small spikes in the blue wave are caused by the ADC sampling circuit...
and cooling speed slopes are also caused by this?
And better to not talk about searching timing and AC characteristics in the chinese datasheet...
only senior ksger designers can do this
-
@DavidAlfa,
I flashed the new firmware (increased_watchdog).
Note that the “System” > “Save Time” cannot be 0. Only values between 1 and 60 seconds are allowed. I'm maintaining it as 1sec.
The behavior remains the same.
Additional Information: eventually, I left the station turned on, with the problem (display shows unrealistic input voltage and tip temperature).
After some minutes, the message "Error 82 NTC read high!" so I realized that the temperature room (display top right) is ramping up, that stop when 99.9C is achieved.
During this tests, no resets, no freezing.
David, If you want to continue to investigate this case, you can count on me, otherwise, I will try to get a CKS.
@wickated, thank you for your thoughts.
I changed the power supply a more reliable one (Agilent E3632A), the issue remains.
see attached some photos.
-
I see, at some point I set the min value to 1. Easy fix.
Will make some test builds that show more data in the screen, hopefully we'll get the problem source.
Do you have scope to debug some signals?
If by some reason the ADC is slower than the real STM32, maybe after a while the timing shifts and the ADC reads when the PWM already went high.
I added Quicko detection fix to github:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1228526)
-
I removed C8 from S-D MOS and put it where it was.
I also removed diode from S to GND so all of the attached pictures are now from the board that is not modified. Well... if not described differently below ;)
Pictures explained:
1.) Default board: 3.3V (yellow) and op-amp output (blue).
2.) The same as on the picture 1, just a zoom to ADC (reading) part.
3., 4. and 5.) All pictures was shoot when 100 % power was used and I can see no clear difference if unmodified board was used (3) or with a 1000uF capacitor added at the input of regulator (4) or with 1000uF at the input of regulator and 470uF at the output of regulator (5). I didn't put 1000uF capacitor directly to the 24 V power supply, it is a diode between 3.3 V regulator and 24 V. I just thought of this now :( Maybe I should put another (at least) 1000u straight to 24 V line...
6.) AC coupling with full power load: 24 V (yellow) and 3.3 V (blue).
7.) The same as picture 6 just with DC coupling.
I believe that it got a little better than before but not that much.
Again I must point that I have more problems on lower temperatures (270 C) then on higher (360 C).
Does that make any sense? Maybe because of higher voltage to noise ratio?! David?
Thing I should do and didn't have time:
- different power supply
- checking noise, op-amp output and other locations on my daily using Ksger soldering station (I bought just controller and case from Ksger and I used different PSU then what you normally get with Ksger) that is working as it should just to see if there is the same noise
David, thank you for your information, simulation and everything else! :-+
-
About putting 1000uF everywhere, check this:
https://www.youtube.com/watch?v=qosClvn9GqU (https://www.youtube.com/watch?v=qosClvn9GqU)
1000uF at the 24V input is ok, you have wires and nasty load spikes.
But 1000uF at the output of a small 3.3V regulator... no! :-DD
What would I do? Instead adding such crazy big caps, add a series diode with the LDO instead. So the "low" spikes from the 24V supply can't pull current back from the LDO regulator capacitor.
Am I explaining well? Since it's a switching regulator... The best would be to convert to a higher voltage and then clean the signal with a LDO, like Quicko does.
-
Yes, I have a scope. I will install R999 and wait the new build. Thank you
-
I had 1000uF at the input of regulator and not at the output.
If you ment to add diode between 24V and input regulator it is already there.
Today I checked about schematic and it is thr same as here https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r2/STM32_T12_oled_v2.0.pdf (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r2/STM32_T12_oled_v2.0.pdf)
Elements are diffrently tagged but are the same elements.
Check about D2. Did you mean like that?
Which switching regulator? 24 V or 3.3 V?
-
Oh, nice. Didn't notice the diode . I don't spend my time at "KSGER engineering Inc". Throw it to the bin and get a Quicko! :-DD
The 24V supply is not so important. What you need is a really clean 3.3V signal. And it's very ugly!
Oh wait, your's doesn't have switching regulator, but the spx2954am3-3.3 LDO, and a 10uF tantalum cap.
Why so much noise then? Disconnect the heater and check the difference.
-
Dear Ksger designer,
You are not fooling me :-DD
Regarding throwing and buying Quicko... that was one thing I also thoght of but then I remembered why I wanted to do this FW mod and modifications to this pcb in the first place and I will stick with this till the end :scared:
I will have to be more like engineer and stop taking shortcuts. I am short in time but I will do more work and less asking here ;)
I intend to eliminate things step by step... I will also tell you what 3.3 V looks like without a tip... maybe today if I will have time.
Thank you for now mr. Ksger senior engineer. :box:
-
Hmmm.. I found something weird in the PWM. I hope it's not the shitty Hantek fooling me!
The pwm has some issues. From time to time, the PWM period changes.
But at 200mS time it's really hard to detect. Not to talk with the analog scope I had.
I started to rise the PWM frequency, at around 40mS I caught some pulses happening too close, between 20mS or a little less.
It's like if the whole PWM cycle is being resetted, starting again. The ADC and everything is triggered again too.
The real stm32 handles this like a champ. I can compute this, no problem sir!
But the CH32 got some serious fecal incontinence issues! Something gets delayed, and when the ADC starts, it takes the punch from the active PWM.
Shouldn't be a big issue. Seems a little bug flags/timing-related, coming from the ADC changes I made some weeks ago.
But I like things working like swiss clocks, so I definitely look at this.
Next time I get called ksger-whatever, better to start seeking for some chinese programmers, I'll quit! :D
-
:-DD :-DD :-DD
About Ksger... I tested a lot of things today, changing power supplies, comparing your FW with original Ksger. Something is not ok, but lets start with what you wanted me to test... 3.3V and op-amp out when I don't have a tip. It is in the attached file.
What is bothering me are those 2 dropouts on the 2nd picture. I checked output from op-amp and graph on the soldering iron. Voltage on the osciloscope is slowly droping. It is not a fast drop as you can see on the soldering iron. It doesn't make sense. Something is not as it should be. I will check the code about ADC tomorrow. Well I hope I will have time.
Another thing is adc delay .. on Ksger it is below 5 ms and everything is very fast. I will attached pictures tomorrow. I should also record a video for you to see how fast is a response from temp to temp.
Tomorrow pictures and description, other things later.
Thank you mr. KS.... I mean David 8)
-
You might ask yourself if you understand what you're seeing in the graph. That drop is just 5-10ºC.
Whatever the cause is, you'll hardly see that in the scope, it might be a drop of 40-60mV.
Ksger seems to be running at 500-600Hz. I'm -not- goign to do that.
Anyways, you might remember that it fakes the temperature!
-
On the soldering station is T [t]. T is temprature, t is time.
On the osciloscope I am watching output of op-amp and how it is dropping when temperature is dropping on the soldering station. Pretty much at he same pace and everything looks ok. Problem I see is at the end of dropping temperature because voltage starts dropping slowly at "the end" (just before it is starting to rise - when soldering station is starting to heat) but temperature on the graph is dropping faster (where I pointed in my previous post on the picture).
As I understood you voltage in correlation to temperature is linear (some mV/C), is that correct? I don't understand how tip caould be drastically dropped in temperature as it is shown on that graph. Please explain so that I will not walk in the dark ;)
Ksger has the same period (200 ms) as you have. Nothing is different with period, they just don't have so big a delay at the end of the period (low or no ADC delay). My problem is why I could have problems with your FW and not with Ksger (on physically different but "the same" board - both are from Ksger and v2.1s). Answer could be if I would desolder "your uC" and put back an original one. If everything will be the same on both boards then there is for sure something wrong in the FW and not on the board. Maybe it would be even better that I would know if there is any problem on this board. I hope not, but... :-//
-
I can run 1mS delay with most tips... But others cause trouble.
KSGER 200mS? Where?
Your picture shows 8ms/div and there are at least 5 pwm cycles per division...
I repeat: ksger doesn't display the real temperature.
There are fluctuations, but they don't show them.
However, I don't use to have those problems.
I'm looking at it, but I have a life! :-+
-
I didn't upload any Ksger pictures yet... well, I did now. ;)
You are correct about wrong temperatures, but it is way faster when I tried to take pictures on the oscilloscope. It is really good. Overall I like your menu and handling way better but I believe there are some issues I will try to do some work to help. First I will put Ksger to original state with original FW and compare it to mx main soldering station so that I am sure it is not pcb problem in any way. Then I will go back to the state I am now.
Attached files are all from Ksger FW and you see all measurments on the scope, power at maximum with very low measurment time, also a stable pwm when I set temp to 240C. There is also some not very stable 3.3V.
And you can see 200ms period with below 5ms adc.
If you need from me anything else that you want to see just let me know.
-
They are using too low delay.
The sinal is still rising, but they measure anyways.
-
About Ksger FW:
When checking temperature with temperature tester I see practically no overshoot.
Also when checking op-amp output I see that You don't have to worry about wrong reading because after temperature is getting closer and closer to set temperature PWM is narrower and you have more "ADC delay "(you actually do not, but time from switching MOS off to reading ADC becomes further away).
About "David's FW" ;):
I will try to get to the bottom of it by reading, testing, understanding FW, but I will need a lot of time because I don't have it that much. But I really will try to do that because I would like to have FW with beautiful interface from you and with stability "from Ksger".
First thing I will do is to change to new PID (already inside your FW) and then I will check everything about ADC (thing I think where the problem is).
After that... we shall see :D
-
Hello David,
I'm playing with the station this Saturday.
Things are complicated here when the STlink is not official and the target chip is a bad clone (CH32).
Even more complicated because, as I mentioned, I have zero experience with ST microcontrollers. .. So, most of challenge is to understand how ST IDE and Programmer works.
I manage to get the station working, so far, smoothly. I copied the project from GitHub and changed just the watchdog time, to 2.5 seconds, as you proposed a few messages ago.
I believe adjustments made after the last release (GitHub) and before the .bin of message#1066, doesn't work well to CH32 and causes that behavior (showing low input voltage, unrealistic tip temperature and room temp ramping up).
I'll attach the file I'm using. I change SW to 2021-06-19
-
Did I already said that the versions I made for you were the same as Githubs's, only changing the watchdog time?
Anyways, I changed the saving function, now only disables irqs for each flash write instead for all.
This should fix the huge delay in the CH32F when saving (everything freezed for 2 seconds), including the watchdog problem.
I also made some changes in the ADC:
- Temporal workaround, checking the PWM pin state before and after the conversion, discarding the adc measures if it finds it to be active.
- Skipping and resetting the adc machine state if not found in the state it should. Seems to be some ocassional overlapping causing this.
While not perfect, this should avoid getting weird measures. I'm debugging it so no new builds yet.
I'm still finding out where the problems comes from, I think some calculations take too long sometimes.
But should be easy to catch, as I made the code very traceable and simple. It's just I didn't had the time for it yet.
-
Did I already said that the versions I made for you were the same as Githubs's, only changing the watchdog time?
I didn't know.
But I understood that you are working in more structural improvements.
My apologies if my last message sounded hostile. That wasn't my intention. I just have to thank you for the attention.
-
Hi all.
After getting into this thread some weeks ago, I got a Quicko T12 from Aliexpress: https://es.aliexpress.com/item/32994824865.html
It comes with a CKS32F103CBT6 MCU
I got also a couple STM32F103CBT6 spares (suposedly originals) ::), a Blue Pill and an STLink V2... I was thinking about having this CFW from the beginning.
I just tried it, seems to work well. Better than mi Yihua 853D anyway.
Now I disemboweled it and started to learn in detail about flashing it. I hope it's going to be my introduction to STM32 stuff. I'm going to try and get a backup of the OFW first. I 'm with the Obermaier paper and additionals right now.
Hopefully could you guys give any hints about this board's hardware and some link to basic acces to STM32? That connector marked GND-SWDIO-TX-RX-3.3V at the bottom of the board confuses me... Is that a boullabaisse? I was hoping to find something marked similarly to my STLink V2
I took some pictures of the front board.
Many thanks to DavidAlfa and those that contributed in any way to develop this CFW. You all do a great and useful work.
Edit: typo
-
Please read the GitHub readme to answer most of your questions :-+
https://github.com/deividAlfa/stm32_soldering_iron_controller#frequently-asked-questions
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/Quicko/Schematic
-
I know I've said it few times, but hopefully the ADC is fixed now. I fixed few potential bug sources! :-+.
I've been debugging it for a while, no issues in any conditions.
Also, increased the Delay precision, now it goes down to 0.1mS. At your own risk! Mine does well down to 0.3-0.4mS.
Below that, the noise made PID to go crazy, as it reads low/high all the time, setting PWM at max/min... in the end the tip will overheat so be careful.
Don't go below 1mS if possible!
Check the updated builds! Also, better to make a hard reset, as I changed some settings.
Save your calibration values to easily restore them!
CH32F devices keep doing the weird behavior. I'm unable to debug them to find the issue, so it's a dead end. Get other clones or real ones!
Not only that, after few flash writes that crap completely stopped working!
-
Thanks David,
CH32F devices aren't supported yet. I'm unable to debug them to find the issue. Get other clones or real ones!
I really agree with you! |O
-
Yeah, I didn't expect such issues. Most clones work pretty well. CKS did just great!
-
looks like that clones didnt even suggest to have flash memory as writeable more than once. maybe usage of eeeprom should help, but since original stm or good clones acts well w/o eeeprom, its not a solution.
-
The problem doesn't come from the Flash.
-
Well, I finally caught and fixed some strange bugs I had noticed some time ago.
- After first boot the PID goes nuts - PWM settings not being reloaded after initializing the profile, staying with failsafe values.
- After editing the tip name, it usually returned to main screen no matter what - Idle timer not being updated in that screen.
- 36MHz devices still had some issues.... I have fully tested and adjusted the timing. Only 50uS caused a lot of trouble!
Filtering low ADC sampling rates is hard, you have to choose between adding delay or having more noise.
So, after -lots- of testing, I completely changed the PWM timings and filtering:
- 50Hz PWM
- 100uS delay
- The increased noise is not a problem, thanks to the higher sample rate, now EMA factor 4-5 can be used without delay issues, filtering much better.
- Tweaked the filtering override parameters (To avoid delaying the signal when the temp is changing very fast).
I found a sweet spot where the noise is nicely filtered, but any big change resets the filtering and lets the PID react quickly.
Of course, if your board is reading giant spikes it will cause all kind of troubles. Can't make much about that!
Set the temp graph update rate to follow the PWM frequency for the smoothest experience possible.
50FPS+ are completely possible at least on boards that use hw dma display. Software i2c boards... I don't think so! ::)
Also made some improvements in the power graph (more reactive, less delay)
The filtering method widget was deleted, instead, to disable EMA just set factor 0.
My 3 tips are almost dying. Some had a lot of use, others became glowing candles while debugging (Consider donating some tips for the project? Beer is also ok :D), surviving that was a miracle!
And after all, they're are doing really well with the new settings. So give it a try!
New video coming!
-
this sounds like a bomb, looks like now it works like original jbc station.
-
Uuh, wait until my next update. |O
After a while using it I got some strange measuring errors, but only when using low calibration values.
I hope I catch this stupid bug soon!
Edit: It seems one of my tips is dying, causing a lot of mess!
The others tips work ok, but let me ensure...
-
looks like now it works like original jbc station.
cross yourself.. :-DD
-
I guess this is what happens when the water comes inside the tip and screws up everything!
Probably it caused some corrosion and it's now acting as another TC (Different conductive material)
I wetted it few times to test PID response....
I already had this issues in the past, but I said, for just 3 times won't break it, right? Yes it will!.
So don't put your tip under water and come here telling my FW does weird things (wickated? ahem...! :-DD)
-
So don't put your tip under water and come here telling my FW does weird things (wickated? ahem...! :-DD)
only genuine t12(all of them) acted weird, without any water help. since i jumped to c245 tips everything work as i expect thankfully for your programming skills.
-
Okay, no more issues. Found some new bugs in the menu while making the video(Due recent changes), fixed them and updated everything!
BTW: The aluminium handle is utter crap!! Don't buy it! Even the cheap blue one is better.
Very nice-looking, but after 10 minutes of soldering it will heat up to >40ºC!
Soldering and cooking your fingers at the same time!
Uhh, YouTube copyright detector is really picky, caught my headphones music!
Had to insert a Creative Commons audio track :D
Full calibration steps so you stop doing it wrong! ;)
https://www.youtube.com/watch?v=j0HQq4aRiXw (https://www.youtube.com/watch?v=j0HQq4aRiXw)
-
That's a good video.
So, when I flashed the latest version, I took the opportunity to test the backup of the original Quicko software that I made from the instructions here.
https://github.com/JohannesObermaier/f103-analysis/tree/master/d1-a/arm-cks32f
It appeared to work just fine, but I didn't actually try to use it other than go through the menus some. Now this method depends on having a CKS processor. But it does seem to allow backing up the original firmware. Just be aware that you have to edit the addresses in the program to copy the right parts. The original Quicko firmware is bigger than 64K.
-
you never asked but i did it :-DD :-DD :-DD
except this works fine, but with high default kI oscilates power(but temp doesnt oscilate) at full load with 4 filter and doesnt with 2
edit - error appears at full stock settings too
-
I made these for T12.
So you'll have to tweak it for other tips (Not going to buy them).
Filtering affects a lot the PID response. Since it's a C245, the PID gain can be a lot lower. Ex. Set Kp 60, Ki 30.
T12s need more punch to compensate changes, JBC doesn't.
Never seen that error, and it's almost impossible to happen, but will try to find out.
Also debugging is very difficult since I don't have them :palm:
Explain a bit better when and how it happens
-
Say I wanted to make my own front-end for one of these, so I just needed the power / switching / iron interface side, is there something I could buy?
Or would I be better off just making something from scratch?
-
I made these for T12.
Never seen that error, and it's almost impossible to happen, but will try to find out.
Also debugging is very difficult since I don't have them :palm:
Explain a bit better when and how it happens
got it.
ill test tomorrow, cuz i have some solder tasks today
-
That's a good video.
So, when I flashed the latest version, I took the opportunity to test the backup of the original Quicko software that I made from the instructions here.
https://github.com/JohannesObermaier/f103-analysis/tree/master/d1-a/arm-cks32f
It appeared to work just fine, but I didn't actually try to use it other than go through the menus some. Now this method depends on having a CKS processor. But it does seem to allow backing up the original firmware. Just be aware that you have to edit the addresses in the program to copy the right parts. The original Quicko firmware is bigger than 64K.
Nice! Could you attach the original fw? This will avoid some headaches to Quicko users :-+
-
I would think it's copyrighted. I don't really want to get into any trouble. And the backing up process isn't really that difficult.
-
David,
Great work, but I still have a lot of problems.
Because of your new version I found a couple of things I hope will know where they are because I still didn't have enough time to understand a lot of things.
When I left everything by default I get a major problem in lower temperatures and I have pretty much no problems above 400C so it is a step into a right direction.
What I found out: it is noticeable on very low temperatures but you can also see the same problem on higher, but not as much so I will explain how is on a temperature of 180C (if you want it is the same on 270C which I use the most). When you start soldering iron temperature is going to 180C. When soldeing station is going to get to that 180C it stop heating (power is set to 0) but temperature is shown as about 230 C. it is then cooling down so that it gets to 180C. When it gets to below 180C it shows about 130C and start heating (power to 100).
The same thing is when I set 270C but variable temperature is around 20-30C (between 240 to 300).
I was searching in your code to see where that could happen but I am not there yet and I hope you will know what I am talking about and know where to look for the problem.
Above 400C it works as it should. Stable temperature, pretty stable output power (PWM) and I REALLLLLLYYYYY like it! You are on the right path to the goal! :-+
I tested even on 450C and it is rock stable.
If you know where could be a problem you can also let me know where to look at so that I wouldn't search in the wrong places that could also helped me.
What I also was thinking is if there could be a problem in IOC file since you are working on higher frequency and if that could be a problem? I have F103CB so I could set frequency to 72MHz but I don't know what will change if I change that and I didn't change anything. I also thought of using Quicko settings and set correct pins + output for buzzer and NTC but I don't know if there is anything else I should do. Maybe I should use Quicko IOC and CORE for Ksger and just correct pins (that it would be for Ksger). Would that work or am I missing anything?
I really really really like what I saw on 400C ;) :-+ :-+ :-+
-
Did you calibrate correctly? By default the values are veeery low, the PID is too agressive for managing very low temps and very low power. ( Mine barely hits 260 at 450°C setpoint).
Also the T12 can't measure below 90-100°C so if your calibration is wrong weird things will happen.
I have seen that behaviour on said conditions, and it's normal because it's not set up correctly.
Anyways, when it starts oscillating, lower the PID.
I can't magically make it working for a controller I don't have!
Was this problem on the latest firmware?
Otherwise, don't ask for issues happening in older builds!
My controller works perfectly fine, I've used it for the whole morning (5+ hours non-stop) with perfect results.
At this stage, with such weird issues happening only on (v2.1 ?) boards, I can barely do anything, because it needs deep debugging on affected hardware.
Consider crowdfunding to buy a ksger 2.1 controller so I can properly develop for it.
Otherwise, to me it's blindly guessing what it could be.
I will check the ioc files to ensure the peripherals, interrupts, etc, are set correctly.
Tugo, is your's a v2.1? No problem trying 72MHz -once-.
But I can't manually maintain and build 3 Ksger boards and 3 mcu versions each, every time!
I ran my quicko at only 8MHz, and it did perfectly fine! Only had increase the ADC time to 1000uS instead 350 due the much slower clock.
I guess the display DMA helps a lot. But the display works completely smooth, even the temp graph, everything! Only the scrolling was a little less responsive.
-
I didn't calibrate it, I just put older 3 values and checked it with temperature tester (FG 100 or something like that) so it is not a problem with calibration.
I used latest version (DL-ed today).
Oscillating ok... but why do I have a 20 -40C drop on temperature as I described? I don't think they are from PID, calibrate, I believe they are from SW interpretation (reading + correcting).
I understand everything else you said. Remember what you said about Ksger when I told you they are reading inside 5 ms and now you are reading inside 0.1ms ;)
I see a lot of things about what is wrong I just hope you will read where it could be. That is something I hope I will prove to you that you will hear me :'(
Just point me to a function where it might happen... it is happening when detecting temperature over set temperature (when heating) and detecting lower temperature when cooling down.
-
There's no function that detects higher/lower temp. After each PWM cycle, the adc reads, and the new values are passed to the PID.
The PID receives new reading, setpoint and gives back the new PWM value. Internally it holds some data based on last values.
PID can cause that and much more with wrong settings, did you figure out how it works? What do proportional, integrator and derivative mean?
Nothing changed on the SW in the dectection/processing. But PID values changed, ADC samples much faster now.
As you said, the delay time changed in last release. If you suspect of too low delay, then why you don't go ahead and try changing the delay yourself?
Is the menu there just for showing? Are you expecting me to try it on a hardware I don't have?
I thought it was a nice idea to port the firmware for other boards, but it has become a nightmare.
When you come here and check for new updates, behind that there are a lot of hours debugging, testing, changing, reverting, searching the source of the problems.
It's already time consuming when I can debug the hardware, but for something that you can't touch, can't see, it's like find a needle in a haystack unless the problem is very clear.
Most developers will directly refuse to develop for something they can't touch of that. And this time-consuming way needs to stop.
Sadly, support for any hardware else than Quicko will be discontinued soon. I will try to find the issues, but I won't promise anything.
I'm gonna set something clear:
- No more stupid suggestion and "maybes" if you don't know how it works.
- When I say no more stupid advices, I mean no more "But JBC does this", "But KSGER blah". Stop losing my time ok?
- There are nice guys that really help and properly report issues. You rock.
- There are others that only cause annoyance with "I want", "It would be better", "Why don't we?". Go to the candy store. This doesn't apply for all suggestions, some have been really good.
Want faster sampling? Because JBC does? Unless you start programming, debugging, measuring waves with the scope and working on the real thing yourself to help in this project, save your ideas.
Timing needs to go back to 10ms+. This is why we choose 20mS delay months ago
- When you measure too quickly, the TC is always hotter than the tip body.
- This is not a problem if there's always some power. Until you reach the setpoint.
- When the power is gone, the TC will cool down to the real tip temperature.
- That takes -You guessed?- around 5-10mS, and if you don't respect the timing, the next adc reading reports 10...20ºC less and the PID goes crazy high.
- The next power stroke reads the extra heat on the TC, not the real temp. PID goes kicks back reducing power. And everything happens again.
- JBC and others use ac, so it's a sine wave, when it reaches zero the power has been decreased being slowly for the last 5mS, so there's no sudden power removal like with PWM. Thats helps a lot.
- And that's why PWM drive requires more time.
- Some tips do much better than others. Some will do great with 200uS delay with some, while others need 20mS (Specially genuine Hakko tips)
- If you want it better, faster -That's why you have a customizable menu-. Tweak yourself, but if it goes wrong don't come complaining. If it works for you, nice, but I'm not going to put risky settings for everyone.
-
Tired... :=\
Code updated, new builds... default settings now 100mS / 10mS.
This is why T12s can't use low delays (JBC can do much better).
While the first 2mS seem stable and flat, if you zoom out you'll see that it slowly goes down and really settles after 10mS. That small drift becomes 14ºC after measuring.
With 20mS or faster PWM you'll hardly notice this.
So no more discussion about timings! Could it be better? Maybe, it highly depends on the tip. But this will be the safe, default value. I might revert to 20mS if any issues appear.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1230744)
-
So, I just flashed your latest version. When I powered it up, I reset everything as you've suggested before. But I am seeing something that I haven't seen before. Every now and then I get a very quick message that says Error 88 Voltage Low. The readout in the upper left shows 24.5V. But this message is very quick and hard to read. For that split second, the voltage might be something else. It's really hard to say. Do you think this is the firmware or have I developed another problem? Thanks.
BTW, there's no emergency here. Please, take your time and get some rest if you need to. :)
-
Yesterday I saw that very same error few times, no idea why or where it came from, back then I thought it was something related to the setup: Lots of wires attached, scope probes, programmer, maybe some noise coming into the ADC... didn't happen again since.
Now, if you're having it too..clearly there's something. I suspect the calibration values have something to do here, maybe when they are too close... or too low...or not calibrated...
Try few things:
- I guess it happened right after a fresh setup. Does it still happens if you turn it off and on? I spent a lot of time fighting strange bugs happening only after first boot, fixed by magic after rebooting.
- Does still happen if you go to tip settings and you just click save, without modifying anything?
- If the errors still happen, rise the default calibration values, to ex. 1200, 1500, 1800. Does the error go away?
- If you go into calibration, Adjust... do you get the abort message while adjusting the values?
I'm trying to isolate it, but it's very sneaky! :-/O
-
Yes, this happened the first time after flashing, after a full reset. I will go through the steps that you mentioned and let you know what I find. Thanks.
----------
So, I turned it on again and never saw the message again. Of course, I have no idea why that would be, but you might. :) I watched it for several minutes to see if it would come back, but it didn't. Interesting.
-
Definitely, seems first-boot related.
Everytime I made a factory reset it happened, but gone after rebooting, without modifying anything. Well, it's a nice thing!
That means it's only something not being properly loaded after the first reset, when the profile is initialized and loaded on top of the failsafe values.
Will catch it for sure! :popcorn:
-
I think I spotted a sneaky setting causing trouble in the pwm settings.
I've resetted it at least 20 times... No errors.
In the end I reverted to 200mS PWM.
New builds uploaded.
Killed 3 of my 4 tips... the only tip left is the one that got damaged in the water, so I can't accurately check the PID settings.
ksger 2.1 can be modded easily to use hardware i2c dma: https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319738/#msg3319738 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319738/#msg3319738)
After that, only few changes need to be done in the firmware. The eeprom can be ignored. The fix pins are the same in 64 and 48 pin devices.
I anyone is willing to try, let me know.
-
ksger 2.1 can be modded easily to use hardware i2c dma: https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319738/#msg3319738 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3319738/#msg3319738)
After that, only few changes need to be done in the firmware. The eeprom can be ignored. The fix pins are the same in 64 and 48 pin devices.
I anyone is willing to try, let me know.
since no eeprom is onboard its just trace display on i2c bus used by eeeprom?
-
David, what is green line on the oscilloscope?
-
Test Signal, ADC sampling
-
I thought so...
I am trying to understand your code but I don't have a lot of time (I have it partially and it is giving me hard time to undertand quicker).
So you are always reading ADC after (PWM is done + ADC delay is done), yes? And not for example 350 us before you start PWM again (at the end of each cycle)?
-
So, to close the loop on this, I haven't seen any more of those messages with the latest version of the firmware. I think it's good, but I'll certainly mention it if I see anything like that again. Thanks.
-
another bug found - since i purchased some chinese 245 tips for test, i found they use t12 type TC, so i have to recalibrate tips.
1) main profile is 245, added new tip
2) selected tip
3) since difference in adc output is huge - like 1000+, i made preadjust
4) adjust start
5) new adc values written to all tips instead of one selected :-+
swapped screen to eeprom bus but since im dumb and never gonna compile working binaries im asking for help
also got 110 line error again. on default settings. just running temp up and down soldering.
edit - while just watching waiting noticed that on stand iron waked up accidentally. took more time watching and got ntc error. so took a further look and found damaged trace on board. seems fixed by now. :palm:
edit 2 - no its not, but i got idea - its somehow connected with ntc.
-
I cannot debug ksger boards, so it's a dead end.
If you're modifying PWM timings, you already know my answer.
Not really NTC related, but ADC wrong values. Maybe something is too slow on these boards, I don't know.
Will check the calibration bug
-
I cannot debug ksger boards, so it's a dead end.
If you're modifying PWM timings, you already know my answer.
Not really NTC related, but ADC wrong values. Maybe something is too slow on these boards, I don't know.
Will check the calibration bug
previous builds(may) work good. tested on full stock pwm, overshoots more than 100c.
-
I think I was already clear enough - I won't do any more work on these boards.
If default PID doesn't work, well, bad luck, tweak yourself. I won't make 50 tries until you get a good one. You can do the same.
-
I think I was already clear enough - I won't do any more work on these boards.
If default PID doesn't work, well, bad luck, tweak yourself. I won't make 50 tries until you get a good one. You can do the same.
well i dont even understand what u r talking about.
lateset firmware shuts down with at least 2 errors - in adc read and ntc read.
i dont know why are you talking about tweaking pid.
-
Don't you understand that a problem that only happens in a board that I can't test myself is a nightmare to deal with?
I repeat, I'm done wasting my time that way.
-
All I can say is go here and try each fw version, going back in timeline until you find one that works.
Avoid Jun 24-25 builds as they were bugged, pwm was not being shut down when going to sleep, burning the tip.
If you think that's a tedious work, then think how it's for me, coding, debugging and building each one of these builds.
https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/master/BOARDS/KSGER/%5Bv2.x%5D/STM32SolderingStation.bin (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/master/BOARDS/KSGER/%5Bv2.x%5D/STM32SolderingStation.bin)
I'm out again, the last working tip burned my handle socket down.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1231131)
-
cmn chiil down. i only wanna say that fw hooked some bugs from some time. i flashed back may fw and its rock solid, except unworking tip menu adc settings.
i spent some time to reduce noise and now have no spikes at fast pwm. as i said before, with jbc tips fast pwm is a must cuz it can easily overshoot 150c or even more. and jbc tips are trend nowadays. chinese have shitty TC but heat up well.
i just said there ARE bugs, if u cant fix them by any reason, its ok, there is no way to do anything without bugs. i dunno how github work, so link for older builds is MUCH enough.
p.s. i see there is code, ill try to read it later :-/O
-
Don't get me wrong, I'm just tired.
Fixing bugs when you can't debug is just exhausting.
More than once I've spent an entire day trying to find a Ksger problem that doesn't happen with Quicko.
What I mean, simple and clear: I won't lose my time that way anymore.
If you want proper support, then each Ksger owner puts $1, I buy the said board and then we might start talking about bug fixing.
Otherwise, why would I spend my own money?
Development is almost over, everything works pretty nicely.
Yes, Ksger 2.1 seems to have some timing issues, but that is the hardest part to fix, no way when you can't see what it's doing.
-
Hey, even I would give a dollar to contribute. And I'm a Quicko owner. :)
-
It took another 4 hours, but I think I found the issue. I smell it appeared after the recent update of STM32 F1 library (v1.8.4).
I set my quicko as slowest as possible (8MHz), and software-mode display to slow it down even more (And it still did pretty nice! The graphics optimization gave its results :box:)
And the errors started to appear! Suddenly, the adc was triggering twice. But the program workflow was fine, nothing was calling the adc start again... was doing that by itself.
I suspected it was coming from the adc stopping. Something going wrong causing to self-trigger again. That could only be the DMA?
Long, long time ago I had a issue when stopping the ADC, the library waited for the dma to finish, but it had already finished, so it would stall for long times, causing a lot of trouble.
I had to made my own detection method, and it worked fine all this time. I decided to remove the fix that previously worked, and directly call the adc dma stop.
Now it no longer did what happened months ago. A clean, proper stop, no stalling, and no more double adc triggering.
Why didn't happen with Quicko? Who knows. I really hope it wasn't a lucky shot and the error is still around, just hiding from me.
Try the atttached file
But what I said about ksger hardware remains unchanged.
Debugging/fixing things in hardware I don't have takes 10x more time. I can't/won't do that anymore.
**** you ST and your libraries!
-
Hey, even I would give a dollar to contribute. And I'm a Quicko owner. :)
+1
Also a Quicko owner.
I think people that get us out of vendor's claws hast to be supported. The amount of effort is not trivial and we all take profit of it. I find much more value in my solder station if I can fiddle with it's firmware. Please put a donation link and I will happily contribute.
And take it easy, man. Nobody here expects you to work non-stop for free nor wants you burn out.
No te encabrones, hazte el escandinavo.
Best wishes
-
And if Ksger owners don't want to contribute, we can always get him some tips. :)
-
Thanks guys! I really appreciate it. I lost count of the tips I've killed for the benefit of the development. Easily 12...15... :-DD
It's not like I'm wanting money for it, but it would be nice to have some support for the project, buying new tips when they burn down, or properly supporting problematic boards. I added a link in my signature!
About the burn out, it's not the developing itself. I love new challenges, I like to support this project!
What I don't like is to waste my time. If there's an issue in Quicko boards, I set up the debugger and I ususally find the problem quickly. But with others, it means hours of trial and error.
Talking about errors, they seem to be gone, so... new builds!
Can't test PID settings until I buy new tips (The handle half-melted too ... |O) so meanwhile I reverted to older ones.
I made some work in the graphics driver, to allow simultaneous software and hardware i2c coexistence, and detect if the display is connected to the hardware, or use software mode instead.
It'll be specially good for the ksger 2.1, which has the display connected to normal pins, requiring software mode.
This will allow modifying them by connecting the display to the correct pins, and yet maintain compatibility with non-modded boards, without requiring any firmware modification.
This is still WIP, so not enabled by default. When/if the detection works correctly, it will be added to future builds.
Added this picture to github for modding instructions.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1231285)
-
Thanks David,
CH32F devices aren't supported yet. I'm unable to debug them to find the issue. Get other clones or real ones!
I really agree with you! |O
Hey, I suspect the CH32 reacted a little different to the ADC bug.
Give it another try! :-+
-
I made some work in the graphics driver, to allow simultaneous software and hardware i2c coexistence
This is still WIP, so not enabled by default. When/if the detection works correctly, it will be added to future builds.
i am awaiting for tests. as i read in code 2.1 boards are only ones using software i2c screen
**** you ST and your libraries!
well at least there ARE some IDE now, i took a look like 10 years ago and it was like programming a mainframe with perfocards.
-
First, why don't yiu try if the error still happens un these? Otherwise the display is useless! :-+
-
First, why don't yiu try if the error still happens un these? Otherwise the display is useless! :-+
as far as i guess display and adc shares processor time at most, so mod for dma i2c should offload plenty of cpu time. and my board is already wired for this.
as for latest fixed fw , station is currently busy working for food. i ll test fix a bit later.
-
That would be a terrible programming, maybe someone who just started learning would do that, after the first LED blinky program.
The display has absolutely zero priority in the system.
All the important functions are called using interrupts, and as the name suggests, that makes the CPU to stop whatever it was doing, run the priority task, and resume the previous one. That includes ADC, pwm, iron, PID, error/runaway detection...
That's why everything works perfectly even at only 8MHz and software display mode.
The display driver might be drawing a line, or refreshing the oled memory... it'll get interrupted 1000 times if necessary to do the important stuff.
When the system works correctly, only then new features might be added.
Otherwise, working on already broken code is like storing air your pockets, plainly stupid.
Anyways, the max attainable i2c speed depends a lot on the pullup resistors. The displays come with 10K, which limits the slew rate.
The firmware is already overclocking the i2c bus by default, with a peak speed of ~900KHz.
With 470R resistors I've been able to brutally rape the i2C standard, only 50nS between data and clock, and 150nS clock high time, achieving 2.2MHz.
Stock: 48fps
Pullups + lowering delays: 141fps
Pullups + 64MHz: 211fps (Modifying code to maintain the same clock delay)
But of course this can't be done by default, it would break the compatibility with most v2.1 boards.
-
David I did quite a lot of testing with new FW, old FW, different tips,...
At the end I found out that different tips mean different story...
I have:
- new tips
- old tips
- Hakko tips
- other tips (Quicko, Ksger, noname)
For the purpose of testing I used 1 noname "K tip" which is pretty new tip but with a burn in of at least a couple of hours but I didn't use it for work (just for this testing) and 1 pretty much the same "K tip" but should be a genuine Hakko (it has a logo on it) which also wasn't used for my work but was also stable in my Ksger soldering station.
Today after testing a lot of different new and old FWs I decided to try a tip that I used from time to time and it is a DL52 (from Ksger). Well... it works... I could set it to pretty much anything. Delay to 0.1ms, period from 50-200ms... temperature down to 180 C... you name it and it worked.
I also tested a Hakko JL02 which also worked ok as DL52. Then I tried different Hakko tips which I use the most and none of them worked (D12, DL32) - I had the same problem as with first 2.
After that I tried 2 noname new tips (KU and D12) which had a lot of trouble even starting to work. New tips are pain in the a** to test because they need a brake in (well, we all know that).
I will be on vacation for the next 10 days or so but I will try to check everything if I can find something... anything... that could give me any kind of clue where to start searching for the trouble.
David, please don't get angry if I will ask you some questions in the next weeks because I would like to help and I need to understand a lot of things before I can give you something back. For the record, I am not dumb, I just don't have experience like you and somebody else but I am willing to try because I would like this to work as it should.
One thing I believe in is that if there are tips that work and some that not work no matter what and if Ksger has a code that works with both of them... I KNOW it could be done even in this FW! :-+
David, thank you! :-+
-
No problem, but you always forget one detail:
I show the real measured temperature.
Factory firmwares don't, unless the difference is huge.
So the tip might be oscillating 20°C up and down, and you simply won't notice.
So when you see a small 5°C drop and blame my FW, remember that. I could do the same, easy... But this is an advanced firmware, where you can tweak every little parameter.
To get all tips working, you must use the worst conditions.
Otherwise the behaviour will be random, some will do nice, others won't.
I don't want to explain again the delay thing, anyone tweaking the pwm settings will be at it's own!
The tip names are for your own reference, so you know what you're loading.
There isn't any kind of internal database, that would be impossible given the infinite providers of these tips.
For now, just try the latest firmware and confirm the ADC issues are gone :-+
The rest is just PWM timing and PID adjusting.
PID will change a lot with the power, being applied, settings working at 24V will be probabbly a lot slower at 12V, because the power going into the tip is 1/4.But also the sampling interval affects a lot.
-
Thank you for the pointers. :-+ :-+ :-+
I will first try to understand where things are and how are they put together.
After that I will try to do small changes and try to make my worst tip work :-+
In the mean time I will ask you some questions just to be sure I am not way off when I will find something. I still don't understand how a good tip can work at 180 C without a problem but a bad tip is almost working (at start it is heating at 100% and when it is getting to the set temperature it is losing power and even y graph on soldering station is showing temperature slowly getting to the set temperature but when temperature is just above the set temperature the temprature is shot to 220 C without putting any new power to the tip - pretty much the same when cooling down from 220 to 180 and when hitting just below 180 it shows about 140 C... not really make any sense and is pi...ing me off - I really think this is a software bug - David, did you have this problem any time or is this just me? Any other user also?).
Measured tempratures: from what I tested with your FW and Ksger I don't really see any different ways of showing temperature compared to a measured one. I don't know how is this on Quicko or on v3.x in Ksger since I have only v2.1. I will not work with oscilloscope in the next 2 weeks or so. Vacation is vacation and I will try to understand things first and maybe do some software changes to see what happens (I will have a controller, 20 V brick power supply with 1 tip and a FG-100 with me :-DD Well enough to learn and try to understand).
-
David, I forgot 2 more things:
- after I get home from vacation I can make a video to show you a comparison of your FW with Ksger in regarding of temperature with a good tip
- I have an original Hakko D16 tip that it got the same burn as yours. What I did was grind all of those black thing off and then I crimped it back together (not soldering just hold it firmly together). It still works and I use it a lot! Don't just throw it away.
-
tested new fw
tip menu works as intended both ways - manually setting adc or throyugh calibration menu
pwm/pid works very good and fast, but somehow it looks a bit wobbly like if adc readout shifts -+ random time. but anyway no critical bugs.
p.s. Chinese tip burnt in 1 "nominal" heatup at 250watt . no way to spend 10$ instead of 30$ for genuine one (in my country they cost 60€) :-DD :-DD :-DD
at least it have some copper
-
I still don't understand how a good tip can work at 180 C without a problem but a bad tip is almost working (at start it is heating at 100% and when it is getting to the set temperature it is losing power and even y graph on soldering station is showing temperature slowly getting to the set temperature but when temperature is just above the set temperature the temprature is shot to 220 C without putting any new power to the tip - pretty much the same when cooling down from 220 to 180 and when hitting just below 180 it shows about 140 C... not really make any sense and is pi...ing me off - I really think this is a software bug - David, did you have this problem any time or is this just me? Any other user also?).
Beacause of the thermal transfer. Because of this:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3594821/#msg3594821 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3594821/#msg3594821)
You'll be very lucky if a tip has close to perfect heat transfer.
Doesn't matter the tip size or profile, the problem comes from inside, the heating element can't transfer the heat so fast.
You'll see how most of the problem is gone when powering from 12V. As you put a lot less power on it, it can effectively transfer that heat in time.
The only fix is to add delay. If you want to keep using 100uS delay, then please don't ask anymore about this issue.
-
well at least with proper tip internal configuration heat transfer is stable, so u can also refer to unsetled temp. but it need deep understanding of processes inside tip and stability of controller.
-
I call it "Don't complain, it's a $3 soldering tip, don't expect NASA engineering in it".
Genuine JBC work much better, but you must think if it's worth the money for a hobbist, ocassional use.
One cheap JBC tip costs the same as the whole T12 station.
wickated, don't buy chinese JBC copies, I already bought 5 or 6... They do much worse than T12s and cost 2-3x more.
-
wickated, don't buy chinese JBC copies, I already bought 5 or 6... They do much worse than T12s and cost 2-3x more.
sure i just bought it for tests, noticed improper TC voltage curve, and tested curved point tip, found it very useful but not suitable for my work
Genuine JBC work much better, but you must think if it's worth the money for a hobbist, ocassional use.
One cheap JBC tip costs the same as the whole T12 station.
yes but jbc tips work like if they are pure copper, no other plated tips can compete with pure copper.(except metcal, but they have another limits)
i stand with the price of tips but genuine stations like this combo are too much for a real hobby.
-
The pure copper thing is just **** ::), liquid tin slowly dissolves copper, after a week the tip will be gone.
So the tip needs to be iron-coated to prevent that (And the iron coating, chrome-coated where you don't want tin to stick)
(https://qph.fs.quoracdn.net/main-qimg-e6385bdca8b987a6654ee27f114512ae)
The problem is not really the coating, but the contact between the tip and the heater.
Copies are badly pressed, you can see the air gap, so the heat tranfer is terrible.
Some years ago, I had a tip that became damaged after falling to the floor.
The tip end flattened, but I decided to "fix" it with a file.
After a while the tip end became this:
(https://external-preview.redd.it/6xEwgc7Hyhrl5N1jaqVH-yy_s3L-Tu35bHVcZNM1HiY.jpg?auto=webp&s=9983a0e6d7a564dca3d331f79595286f25053499)
Because I was using "pure copper" :-DD
-
I installed the latest firmware and started revisiting calibration. I did get some thermocouples that I have more faith in. Here's the calibration report. I've changed the format slightly to reflect all of the numbers used in the calibration.
Model: Quicko STM32/CKS T12
Tip: T12-BC2
Calibration > Adjust >
ADC Value Temperature
Cal. Step 250°C 1050 256°C
Cal. Step 350°C 1500 353°C
Cal. Step 450°C 1900 445°C
Calibration > Start
Temperature ADC Value
Cal250 224°C 1160
Cal350 324°C 1602
Cal450 419°C 2012
I started to calibrate a D24 tip, but I couldn't get the 450°C adjustment done without it going out on an error. I'm burning it in some more assuming that's the problem. Or should I be adjusting something else?
Edit: Here's a little more detail about what happens. I'm in the adjust portion of calibration. I get through the 250°C and 350°C steps. While on the 450°C step, the temperature is about 430°C. Before I can adjust the ADC value, the temperature starts climbing. At about 500°C, it throws an error and quits the adjustment. I've burned this tip in for at least an hour at 300°C. Do you have a suggestion about how to go forward? I can certainly burn it in some more.
-
So the BC2 calibrated correctly, but not the D24? Select the BC2 profile, plug the D24 and carefully start rising the setpoint.
I guess weird things will start to happen around 400ºC. Latest fw version? Stock PWM settings?
When that happens I set an extreme delay, maybe 100mS, if the temperature stops jumping, then I decrease the delay in 10mS steps.
If the issue persists, then either the tip is defective or need a crazy amount of burn-in.
I've had some tips that didn't like going over ~420ºC. My last ones (Now RIP) for example.
In gave up and used them normally at 370-390, testing the 450ºC setting from time to time but no way.
Maybe 2 weeks later, I rememberedthis issue, and they were working much better!
It's hard to tell why it happens. It woul be nice if you can hook a scope to the handle and see the difference in the waveforms, because clearly there's something going on.
Do you have older tips that were working correctly, to compare with the new tips?
-
Actually, I don't expect to use this tip at anything close to 450ºC. I'd be fine with only going to say 400ºC. I'm sorry, I'm not as electronics knowledgeable as you are. I have an old analog scope, but I don't really know how to use it. :) And all of my tips are from my original purchase of the Quicko. You've given me some ideas. And I'm sure you're right that time will affect this. I'll keep working with my other tips. I bought five with the Quiko. :)
Edit: Yes, it's the latest firmware version and stock PWM settings. If you'd like to test some changes, just let me know. Thanks.
-
So the D24 did fine before?
The important thing is to figure out if it's only that tip, or there's something going on.
-
These are all new tips. I'm only now trying to calibrate them. I will be on the look out for any other issues.
-
Hi David,
Hey, I suspect the CH32 reacted a little different to the ADC bug.
Give it another try!
I gave up of the CH32F. Returned it back to the seller.
I installed the CKS in the board and managed to mass erase it.
Just installed the last firmware. Tomorrow I play with the calibration.
Anyways, thank you for the remembrance.
-
Updating
Model: Quicko STM32/CKS T12
Tip: T12-D24
Calibration > Adjust >
ADC Value Temperature
Cal. Step 250°C 1400 261°C
Cal. Step 350°C 1800 349°C
Cal. Step 450°C 2200 444°C
Calibration > Start
Temperature ADC Value
Cal250 232°C 1495
Cal350 321°C 1939
Cal450 414°C 2354
now I'm using a FG-100 clone.
-
Model: ksger STM32 2.1s/3.3 ad8605 x250
Tip: jbc c245-944
Calibration > Adjust >
ADC Value Temperature
Cal. Step 250°C 1950 ~240
Cal. Step 350°C 2650 ~340
Cal. Step 450°C 3450 ~450
Calibration > Start
Temperature ADC Value
Cal250 240°C 1960
Cal350 340°C 2660
Cal450 450°C 3450
Model: ksger STM32 2.1s/3.3 ad8605 x250
Tip: china sheet jbc
Calibration > Adjust >
ADC Value Temperature
Cal. Step 250°C 1400 ~250
Cal. Step 350°C 2050 ~350
Cal. Step 450°C 2650 ~450
-
Hmmm.... ??? I don't trust your calibration wickated.
Tip calibration results are always a tad higher than Cal adjustment values, because they're temperature compensated.
But yours are almost the same, like if you did something yourself.
Or are you soldering at 0°C ambient?
-
I wondered about that. I was confused that the measurements that I had just made were now lower during the calibration step. You have now made that clear. The problem is that we are always questioning our measurement hardware. I'm beginning to have some confidence in my current thermocouples, but I still question everything.
Edit: Maybe this is an item for the FAQ.
-
It's already there, sort of.
Cal adjustment is just a coarse calibration.
It didn't exist before, made just to avoid burning tips between different boards with huge measuring differences.
Why question everything? For you is just a number.
What you should take care of is the real temperature and avoiding burning/making holes in your boards :-DD
-
Hmmm.... ??? I don't trust your calibration wickated.
Tip calibration results are always a tad higher than Cal adjustment values, because they're temperature compensated.
But yours are almost the same, like if you did something yourself.
Or are you soldering at 0°C ambient?
ahh that explains everything. for example i set adj1000 for 250c, start cal, on 250 step i see 230, set 230c reading and after that see ~1000adc in tip menu. i thought that its temp compensation not used while setting adc but didnt mention should it be so or is a bug.
anyway instead of calibrating mulitple tips to tip end temp i prefer to set heater outer shell temp(place where TC is), so i use only 1 setup for all tips and its guaranteed that temp wont exceed onscreen value. tip end temp delta is written on small sheet of paper in ma brains.
-
When you set Cal_Adjust manually, it just sets the desired adc value as the setpoint, it isn't not ambient temperature-compensated.
That's why after that you get -20ºC or so. It doesnt matter, doesn't need to be spot-on, only needs to avoid burning your tip during calibration.
When you set ex. 235ºC as result, all the work is done by the calibration process, extrapolating the correct ADC value given the current ambient temp.
That's the last time I explain this.
And that's why I certainly know your calibration results were not done by the automatic wizzard, making it useless.
CAL_250 adjustment=1950, CAL_250 result=1960? No way!
Why you must thing everything is a bug? Talking like if you knew how the firmweare works? That really bugs me!
The calibration gives different values, what's the problem? If it calibrates accurately, that's the only thing you should take care of.
If you don't have enough knowledge, don't pretend me to explain you every single detail of the firmware. I'm a developer, not a teacher! :-DD.
-
So, I've been burning in my tips a lot more. I just set the standby to an hour and let them run at 300ºC and walk away. After an hour I come back and see how they run at 450ºC. I've got five tips and in every case burn in seems to settle things down. But sometimes it takes two or three hours of burn in to do it. Not a problem, of course. Here's the D24 calibration report. I'll post the others as I get them.
Model: Quicko STM32/CKS T12
Tip: T12-D24
Calibration > Adjust >
ADC Value Temperature
Cal. Step 250°C 1050 251°C
Cal. Step 350°C 1500 354°C
Cal. Step 450°C 2000 445°C
Calibration > Start
Temperature ADC Value
Cal250 220°C 1190
Cal350 320°C 1645
Cal450 423°C 2109
-
Why you must thing everything is a bug? Talking like if you knew how the firmweare works? That really bugs me!
The calibration gives different values, what's the problem? If it calibrates accurately, that's the only thing you should take care of.
If you don't have enough knowledge, don't pretend me to explain you every single detail of the firmware. I'm a developer, not a teacher! :-DD.
what u see wrong ? i can set cal_adjust in steps of 50/100 only. i have values written down on a paper. why should i use thermometer every single time i wanna reroll fw ? and u can see very clearly symbol "~" near preadjusted temp.
since i have paper with digits written and fast encoder rotation added to adc setup if i use 1 tip preset after flash i just directly go to tip menu and set 3 values directly. if i wanna use multiple tips i go and set nearest preadj, which are only 10 steps tight. why i should even bother measuring real temp while preadjust? i made if multiple times before and nothing in controller opamp part had changed. resulting error is within 50c, not 150c+. jbc tips are pretty dense, on my favourite 741 tip end is only ~5c lower then core
-
It seems you still don't understand that pre adjust is done only once, when the settings have been erased?
Then you only run the normal calibration.
I usually don't bother much and use the same profile for all, the temp between tips doesn't change more than 5°C.
Of course you can go and restore the values, that's why the tip cal section was made.
-
that pre adjust is done only once, when the settings have been erased?
Then you only run the normal calibration.
i literally wrote it
-
Well, I didn't understood that:
if i wanna use multiple tips i go and set nearest preadj, which are only 10 steps tight. why i should even bother measuring real temp while preadjust?
If you already know your typical adjust values, ok. If not, of course you should measure when adjusting.
Did you ever thought that you might be confusing others? There's a lot more people reading the thread, and they don't know how it works first-hand like I do.
Test the attached firmwares. There are 3 tests.
As their names suggest, the tests are SW only mode, HW only mode, and detection mode.
The tests show a bouncing ball and the FPS (The screen effective update rate)
HW I2C speed is set low for now., so don't expect more speed than SW mode.
In any case, it will show if it's working in HW or SW mode.
Althought it will never reach the crazy speeds of SPI 8):
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1232283)
-
Did you ever thought that you might be confusing others? There's a lot more people reading the thread, and they don't know how it works first-hand like I do.
i have analog devices 8605 opamp, which is not pretty default on those boards, its output is not default, so numbers i have shouldnt confuse anyone who have same modification.
57fps in sw_detect mode
58fps in sw mode
doesnt start in hw mode with mod from prev page
-
Post picture of your mod.
I limited the drawing rate, but not the OLED update rate.
Drawing eats much less cpu power now, so the fps will be limited by the i2c speed.
Also changed few other things, download and try again.
In detect mode, the speed will be the same as in a forced SW/HW builds. It only probes the screen at initialization, and sets a flag.
That flags is read by the graphics driver before sending data to the screen, using sw or hw method.
The purpose of SW and HW builds is just to ensure the detection works correctly.
And it seems to, as forced HW doesn't work either.
Overclocking the spi bus (16->32MHz) :-DD
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1232292)
-
lifted standard pins also
in newer build auto also 58 fps sw now
-
Remove these resistors for now.
Why lifted the pins? :palm:
-
Remove these resistors for now.
Why lifted the pins? :palm:
what resistors?
for test
-
What is those soldered pins that can be seen in the uper part of the image?
-
What is those soldered pins that can be seen in the uper part of the image?
sda scl display wires
-
Ok, it looked like something else connected :-DD.
I wonder if 48/64 pin devices, although GPIO compatible (Ex. PB8 is the same in both), are different at mapping the peripherals.
Edit: It works correctly
I'm checking it.
-
dont worry if it wont work. even if im jealous u have rtx3090 fps in your solder station :-DD :-DD
-
I don't know why it doesn't work for you... Here its doing perfect.
Check my Ksger v2.1... :popcorn:
The left pins are are sw i2c, wired to the hw pins.
The detection works perfectly. Setting the hw i2c too fast will also fail and set sw mode.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1232324)
The stock 10K resistors make an RC filter and limit a lot the i2c frequency. They're meant for the standard 400KHz, and it works perfecty in that conditions.
Stretching the timing to the limits, it could handle 900KHz in hw mode.
Curiously, that's a litle less that what I do in sw mode, because I don't care about the acks/nacks, I just send the data hoping it reaches its destination.
Since there haven't been any issues with sw i2c, why add more complexity?
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1232328)
-
You're having so much fun. I'm jealous. :)
-
Well, I ditched the i2c hw. In this case, it's worse because you are tied to the hw timing you can't tweak anything else than purely clock speed.
In fact, I was able to vastly improve the algorithm by optimizing the code and squeezing the clock.
The clock period is the important thing here. You can't make a too short pulse or the receiver won't notice it.
But between pulses, you have to process the data, determine if the next bit is 1 or 0 and toggle de data line.
There is were I made the black magic. The time between pulses have gone to minimum.
Sometimes only 100nS between clocks, using the (now it's an advantage) delay of the slow i2c slew rate, instead doing it on sw, giving a performance boost.
I'm afraid of being sued by Philips for giving absolutely zero *** at their specification. Even the scope is no longer able to decode anything :-DD.
But if the display does, who cares! The result is that it now achieves 90fps. At 36MHz, and not optimized for speed!
Test it and report.
Edit: Updated with O2 optimizations.
New build for Ksger 2.1 available on github
-
90 fps too
I don't know why it doesn't work for you... Here its doing perfect.
Check my Ksger v2.1... :popcorn:
possibly its caused by other resisitor nominals on spi wired display module. mine has 5k pullup resistors.
-
Doesn't make a difference. I tried with 10K and 220R, and worked.
But by no way the hw i2c could reach that speed at 36MHz core. The best I got was 67fps.
The module itself crashes if you go too fast.
Setting the CPU core to 80MHz (little overclock) I could set the i2c to 3MHz (Theorically, real was about 2.7MHz). And about 400fps.
But 90 is a lot more than you need. Will work perfectly.
This is still strange. What's there? That's what I asked yesterday.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1232399)
-
This is still strange. What's there? That's what I asked yesterday.
display module wires. just a bit damaged cuz i used hot air instead of spare iron
-
Hi guys!
I don't know if it will make any changes but I tested 3 versions: SW, Auto and the latest one.
In SW and Auto I got 58 FPS and in the latest I got 93 FPS.
I still study the whole SW but it is getting slow since this is the first time with STM uC and I have limited time.
David, I didn't find a lot but I believe I found a variable that will not change anything if removed (settings.c -> checkSettings -> variable checksumtime is there that doesn't do anything). David, am I wrong and I don't understand how things are done? I know I don't know A LOT!!! But I really hope I am not wrong at least here. As I stated already it shouldn't change anything. This is just to see if I at least understand some things or that I really am |O
-
Must be a joke... :palm:
It's not that you don't known how things are done.
Because I couldn't have explained it better 2 or 3 post above, where you downloaded the file.
You simply come and say whatever without reading anything.
About the code, must be another joke.
When you want to know what a variable does, use the search function and find it yourself.
Of course it does something!
-
David, I did try to find it but my screen is so small I didn't notice it at the end of if sentence :-DD |O |O |O
And I didn't do a search, you are correct!
I should get into shadow sun is making it even worst! :-//
I am sorry, David. And thank you for clearing things out.
-
Ohhh I'm not angry, I just encourage you to use your eyes!
Because if you search that variable you'll find:
if (......) || (CurrentTime-checksumtime<999)
return;
If you don't understand what that code does, what you need is to learn C!
I noticed something: my project began as a fork, and github search doesn't index forks with less stars than the original project.
So my repo code search didn't work. I made a new repo importing the existing one, but completely dettached from the original.
So now code search works. Ex:
https://github.com/deividAlfa/stm32_soldering_iron_controller/search?q=checksumsettings
Now you don't have excuses! :-+
-
:palm:
I told you I have a small screen and that I DIDN'T use search BEFORE. I did use it AFTER you told me to use it and I found the missing and used variable.
Also I told you I didn't find it at the end of the IF sentence so you should know C language is not something I saw here first. Even tho I used decades ago I didn't forget it completely. David, you should also start reading our comments before judging me or anybody else.
Everybody makes mistakes. Even you, my friend. Please just help us to understand things better not just judging us and see that we are not your enemies.
Even you wasn't born with all the knowladge. :-+
If you want from us not to comment anything about your code just let us know that and me for one will be dead silent.
-
Oh and don't take it badly, I know I'm a bit rude sometimes, but there aren't bad intentions!
It bugs me a bit is when people enters the forum to ask something that has been said 3 posts earlier, so yeah, I say "Hell, use your eyes or the damn search button!!"
More or less like this :-DD
(https://memegenerator.net/img/instances/75215655.jpg)
-
:-DD
David, my question wasn't like that but I will take your critic :-+
Now that I understand you and that you know you are like that makes things a little bit (just a little bit :box:) better to understand.
-
The Samuel L. Jackson face was for the question "I tested the files, first I got 58fps, then 90, did you made something to the oled.
While 3 post earlier, where you downloaded the file: "(Lots of detail) Hey guys I made a lot of optimizations to the i2c code, now the screen runs at 90fps!"
This firmware is pretty complex. Although I did my best by adding comments and keeping the code tidy, there's still a lot of code.
It took me weeks to fully understand the code. I had never programmed arm/stm32, neither used eclipse, and my C skills were more than rusted.
So it was a long way until I got there. I had to figure all by myself!
I can make a quick summary, but I can't keep answering such simple and basic questions like "does checksumtime do anything?", when the answer is in a 3-second-away search.
What I said, either download CubeIde and properly review the code (You can search in all project files with control+H), or use github search.
Actually the code is huge, but the program workflow is pretty simple.
(main.c, Init)
After CubeMX setup, it initializes the rest of the system, like:
-Loading the system settings.
-Enabling the ADC.
-Runing ironInit (This is the most important part).
(iron.c, ironInit)
- Sets up some variables.
- Runs initTimers.
That's the most crucial part, everything works based on the timers.
The system watchdog is not being refreshed, so if the timers don't run, the system will reset.
Once the timers started, the interrupts will run the rest of the program, resfreshing the WD.
(main.c, main)
The main function only runs non critical stuff:
- oled_handle: reads the processed input, updates the widgets, draws them and updates the screen.
- checkSettings: Tracks changes in system options and updates the stored data.
(main.c, program_handler)
Called from SysTick_Handler at 1KHz rate.
- Reads the encoder pins.
- Reads the wake input.
- Handles buzzer state.
And here it comes the important part, the interrupts!
(main.c, HAL_TIM_PWM_PulseFinishedCallback)-
- Called when the PWM wave goes low.
- Checks that the adc status is correct, and enables the delay timer.
(main.c, HAL_TIM_PeriodElapsedCallback)
- Called when the delay timer expired. Now it's time to sample the adc!
- Runs ADC_Start_DMA.
(adc_global.c, ADC_Start_DMA)
- Starts the ADC in DMA mode
(adc_global.c, HAL_ADC_ConvCpltCallback)
- Called when the ADC conversion is done (All data, not single conversion).
- Refreshes the watchdog timer.
- Runs handle_ADC_Data (Processes and filters the adquired data).
- Runs handleIron (Checks for error conditions, timeouts, pwm setting updates, runs calculatePID to get the new PWM value).
- Runs runAwayCheck (If pwm is active, checks that the temperature is not going out of control).
If something wrong happens with the timers, or the program stalls somewhere, the watchdog won't be resfreshed anymore, and 500mS later the system will be resetted.
And that's pretty much it. The timing is adjusted so the PWM never starts again before the HAL_ADC_ConvCpltCallback ends.
On next PWM cycle everything happens again.
The time between the ADC conversion start and HAL_ADC_ConvCpltCallback finish is around 300uS.
The code is ajusted for 350uS to have a safety gap. Actually this timing is for 36MHz devices (KSGER v2/v3), for Quicko F103 and others running at 64MHz it's ~200uS, but I use the same timing for all because it hardly makes a difference while adds complexity.
For the rest, you'll have to look at it and learn, don't ever expect to understand in 2 nights a firmware that wasn't made by you!
-
So you don't need calibration reports anymore? I had noticed a certain similarity with mine. Maybe you still need reports from different hardware versions?
Edit: I see your request is back in your sig. :)
-
Oops! I deleted that accidentally when adding the github link!
Of course I need, the firmware won't get any better unless people really start reporting them.
What I really need is 20 reports for same model, but different stations, to ensure there's coherency between them.
-
display module wires. just a bit damaged cuz i used hot air instead of spare iron
What controller is that? I wonder if these pins are actually connected to something, routed below the stm32, it could explain why it doesn't work.
Anyways, who cares, in this case SW mode is faster!
-
First of all thank you for your quick explanation where things are. :-+ :-+ :-+
I didn't use GitHub to understand/search things (I use CubeIDE and when I learn your code and found something I wanted to test I change it, compiled it and saw if it works like I thought it would) and I study your code for quite some time now. I just didn't have a lot of time as I already explained. After this message I will get back to the message you explained things because I need to got through it very carefully to see what I managed to understand myself and what I didn't.
I cannot give you any good soldering tip results at the moment because a lot of tips simply just don't work with your FW (even in the newest) but I will need to get home and put everything on the oscilloscope to give you more infos why. All I have here with me is a K tip that works with Ksger (just so that you will know it is not defective) and I cannot get it to work even at 200ms (delay at 50ms) at 240-270 C. I believe it works at above 400 C (even at 0.1 ms delay if I remember it correctly) but not below. That is why I wanted to change your code a little to test one thing but I didn't find where/how to change it yet.
Thank you David!
-
What controller is that? I wonder if these pins are actually connected to something, routed below the stm32, it could explain why it doesn't work.
Anyways, who cares, in this case SW mode is faster!
stock display, i just detached it and encoder too for some fancy look. only have some resistors and caps on module itself.
-
I was playing with the chinese jbc tip that still lives. Yep, the power is so huge that the pid needs to be lowered a lot.
The software is doing everythign correctly, it's just the PID parameters.
This is where maybe some people don't the see difference between "custom firmware" and "Professional firmware that was lab tested with 100 tips in all conditions".
After 5 minutes playing with the PID I got this. not perfect but gives you a example:
Chinese JBC clone PID
Kp: 18.00
Ki: 5.00
Kd: 2.00
Imax: 0.10
Imin: 0.00
Debugging with SW: (CubeIDe SWO viewer sucks! It's buggy, slow and sometimes reads weird data!)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1232501)
If that works, it will be the default JBC PID.
I also updated the runaway detection to detect these cases where the tip (wrong timing, bad PID, new tip, etc) causes hard PID oscillation, going on-off-on-off all the time.
That could bypass the runaway detection. Now it stores the last 4 power values and makes the average.
Seems stable, not causing issues when removing the tip or plugging it in. But I touch the adc pin on purpose to inject 50Hz ac mains noise, the pid freaks out and yes, the runaway stops it.
So great, it never hurts some extra safety :-+
-
i approve. since i have
p40
i10
d2
im0,2about runaway - since tip end is not true ground, if u touch tip to smth grounded or common neutral, TC readout also drops and tip start to glow. hope this tweak should help for this rare situations. original jbc stations have ground leak detection.
-
T12 are connected to internal gnd throught a 100K resistor (At least in Quicko).
JBCs are directly connected to gnd.
Never seen that issue.
Kp40? Seems crazy. Doesn't overshoot like crazy?
Also, why you first complain about JBC overshooting more than 100ºC, but then adjust the PID and say nothing?
These are the things that help.
Thanks everyone for the donations!
New tips coming! :-+
I'm testign again Phil's PID algortihm. Seems to work correctly now, so I enabled it.
-
been away for a bit had another surgery. cant see to well out of the eye still sadly. its pretty bad unfortunately. tumor is def dead though.
i flashed the newest ksger 3.x build to a v3.0 oled board and i keep getting hard fault system halted press btn message and then if i do a full reset in the menu it gets stuck at the error 8d screen if no iron is plugged in. i have to power cycle to get back to the menu. any thoughts. tried 2 different ksger 3 board same result. i did try to fully erase the chip and reflash a few times.
hard fault happens every time after i pick the tip type (t12, c210 etc) after program or in the setup screen. and when trying to go to settings randomly. after changing settings it get stuck on the error 8d screen randomly edit: hard fault also happens randomly when changing the settings then selecting back.
-
Damm, so sad, I hope you get better!
It's always better to lose some sight than cancer, isn't? :-+
Ok let me try something. Maybe it's my fault.
What chip is in your Ksger? A 101, 102?
-
yeah but it also sucks to not be able to see. its tough man. i think id give up any other one of my senses before my vision.
let me try to read it with the eye now its super hard i may have to put it under the scope give me a min.
edit the one im testing on is a 102. but i have ksger 3.x boards with all three 101,102 and 103 chips
-
Try again. Should be fixed now. Messed up the devices some hours ago .
Of course is tough....Losing anything... Althought I agree, vision is one of the worst to lose.
Don't get stuck in yourself, I'm pretty sure you'll find lots of support in your relatives and close friends!
I wish you get better! :-+
-
same issue with this new one actually did it 3 times after selecting t12. reflashed twice to be sure.
-
The error 8D means:
- No iron detected
- Ambient temperature too low (-<60°C)
- Power supply voltage too low. (<11V)
You can remove the tip, no problem, but removing the handle will cause that error because it has the NTC sensor.
Also,.new errors can be added if there's an active error, but they won't be cleared until all conditions disappear.
Connect everything like it should be!
I'm trying to figure out the Hard fault error, doesn't happen here, so I suspect is a rare condition.
-
okay so changing the tip style from t12 to c210 or any which way causes the hard error as does sometimes changing the settings then clicking back it will hard lock
then sometimes if i start it up with out a handle i get the 8a error and its frozen there i cant hold down the button to get to settings or anything. i have to power cycle it to clear the message.
-
Really strange. Could you test if the builds from 21-june and before work correctly?
https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/master/BOARDS/KSGER/%5Bv3.x%5D/STM32SolderingStation.bin
Anyone tested Quicko and Ksger v2.1 versions?
-
I tracked the issue. The temporal buffer used to store the flash before writing seems to be changing other memory zones.
Yet I have to find it if it a stm32F101 issue, because with the 103 it doesn't happen.
I'm tired, more in a while.
-
i do not have that issue with the older june builds i wanted to update you.
-
Kp40? Seems crazy. Doesn't overshoot like crazy?
Also, why you first complain about JBC overshooting more than 100ºC, but then adjust the PID and say nothing?
These are the things that help.
cuz if i lower P too much station gets lazy and always work on temp below set. so i just speed up pwm, at 20hz it only overshoots 10c from cold start. and 5c after rising tip from joint. at 50hz no overshoot at all. low D adds power ramping slope. low I negates oscilations.
i was pretty happy with older builds PID, which were 45 30 5 or smth, in newer builds you added much more agressive PID for t12, so i had to tune it.
p.s. some thing were made in fw internals, cuz i n old builds on small tips power could even not rise to 100% before reaching set temp, in newest power reaches 100% for half of heating from cold start.
-
That's why Ki is for! To compensate the error when kp is not enough.
Older builds used less powerful pid. But these should work, at least with T12. Jbc has already been lowered in the fw.
-
I just upgraded FW with latest BIN for Ksger v2.x.
A lot of times I get "HARD FAULT SYSTEM HALTED Use btn to reset".
Sometimes I cannot get to EDIT TIPS. Sometimes I cannot SAVE inside EDIT TIPS.
When I did a full reset I couldn't get to menu at all (long press). Power off/on helped.
Sometimes save did work and sometimes didn't.
Save could also reset the device.
Previous version from 2.7.2021 was ok.
When I try to build BIN I cannot because I get 3 errors.
I did the same as with previous versions and everything was ok there.
Attached are the screenshot with 3 errors in case it will help you.
Maybe it has something to do with IOC file?
If I can help in any way, please let me know.
-
I'm working on it. Something's wrong with the compiler. It's not checking for ram overflow.
I can allocate 1000x more memory than available and the compiler is happy doing so.
So yeah, that will only end in hardfault. Don't use newer builds for now!
The error will appear any time the system saves the settings.
The temporal flash buffer overwrites half of the memory being used by other parts of the firmware |O
103 devices have 2x ram, so no issues. Damn stm32 ide!
-
Ouch. When it's the ape's fault, it's the ape's fault.
Today I learned someting new about C programming!
Ahh the stack size... :-DD
-
:-+
As long as you have found it, it is ok ;)
I mean... as long as it is not my fault I am happy :-DD
-
I'm sure you have part of it :-DD
See what I mean about debugging? That was really hard to catch because I only have 103.
It was using more memory than what I saw, but no problem when I had 2x more ram than 101.
As I've been explained, stack grows downwards, and in the end it will corrupt the data section.
Well, this bug might have been present for some weeks now.
It would explain the no-sense behaviour of the ksgers.
So I'll have to remove some options. Too much ram used!
-
Thank you :-DD
-
i have 128/20 stm so i definetly wouldnt notice overflow, sorry.
i had stm board with 3digit screen, it had 32kb flash, what about porting? >:D
-
Damn, that wasn't easy. The memory is really tight. After a lot of hours losing hair, it's done.
Mainly the tip settings and calibration start menus. Now the edit tip name / cal measure input screens are gone, and done there.
So I could delete all these stupid buttons using a lot of space
Check the builds. :-+ (wickated, for your 32Kb stm32, it would be other finger! :-DD)
-
Damn, that wasn't easy. The memory is really tight. After a lot of hours losing hair, it's done.
Mainly the tip settings and calibration start menus. Now the edit tip name / cal measure input screens are gone, and done there.
So I could delete all these stupid buttons using a lot of space
Check the builds. :-+ (wickated, for your 32Kb stm32, it would be other finger! :-DD)
this did fix the errors both of them. i may swap the stm once im allowed to again right now no soldering allowed which sucks so i can only do quick tests. they dont want the fumes at all in the eye
-
Made few small cosmestic fixes and new builds. Nothing important.
The main screen would flash briefly whenreturning from the menu if there was an error present.
The state was being resetted, so the first drawn frame was tip temperature, overwritten by the error at the next frame.
Also removed the error code, as back then I thought there were going to be more errors.
But there're only 4, so they (barely) fit. It counts the active errors and vertically centers them for better reading.
Mastershake, good to know, thanks for testing it so quickly.
Be well and take care! :-+
Edit: And last update, I added a tip copy button. You can take any tip you want and copy it with a new name.
Buttons take very little space, so it's fine. The problem comes with the editables!
This is not yet in the builds. I'm exhausted!
-
I tested latest version and for me it feels the same as in the version from 2nd of July or any before. It works but I still have the same unstable temperatures in under 400 C. If I set to 200 ms/ 50 ms it is almost stable, but still not as I would expect it or how a "good" tip (the one that works at 20ms/0.1ms at any given temperature).
I guess I am still searching for one thing that I hope to find in your code ;) ... that is temperature related something (bug, something wrong,... pretty much anything that it will work with any tip not just the ones that are ok with it).
Oh I almost forgot: one thing that I see it is gone or at least I didn't see it is a bug in graph where from time to time I got a blank graph and after I pressed or rotated the button I got it refreshed. This I haven't seen in the latest version so :-+
I don't know if I ever told but I have F103CBT6.
-
Stop blaming my code, you forget the PID.
You assume the code is wrong, while the problem is for sure in the external signal, noise, or whatever.
How many times I have to say that ksger and such firmwares lie about the real temperature? That these oscillations exist?
Isn't strange that ex. ex new tips, you set 350ºC it suddenly shows "Error", without any change in temperature? All fake.
That has nothing to do with the recent isssues. These came because I added a new widget (PID tau) and it seems it was too much for 10KB devices.
I repeat that, except the different pinouts and display interfaces, all the boards run exactly the same code.
With the last ADC fix (after the library update) all I can say is that it works flawlessly.
The blank graph is not a bug. The graph shows aproximately +-20C from the setpoint. More precision in the center than in the rest. Logarithmic-like.
So if your tip is at 300ºC and you set 350, it will appear empty. And if you set 200ºC it will appear full until the temperature drops.
Although anything could happen in last versions, memory corruption is no joke.
-
Check the builds. :-+ (wickated, for your 32Kb stm32, it would be other finger! :-DD)
i guess this one
(https://i.imgur.com/2z3MBz7.png)
tested.
like new pid, just good and not spiky
you never asked but i found bug
stand mode - if it go sleep, it sleep forever
p.s. also its not really a fw bug, if buzzer beeps, some lil spike appear. i suggest not to bother with buzzer and just turned it off.
-
David, I don't blame your code! I never blame you anything. All of the time I always try to explain anybody what doesn't make a sense and I always tell why.
I HOPE there is something wrong inside the code because a lot of things doesn't make any sense.
Later I will explain what is buging me and I hope David you will see that that doesn't make a sense and I really hope you will take a little time and read it very carefully.
Now I will try to explain what I see and what looks like you are wrong (what you tell is not the same as what I see and measure):
I don't care who make soldering station and who make FW so I am not blaming anybody for this.
You told us that Ksger and other company are lying about real temperature... if I can measure temperature and are pretty stable (way below 5 C) without any bouncing whatsoever I believe I can say it is not like you said. I am sorry, maybe you had problems with your soldering iron but I didn't (don't) have.
When temperatures are rising (lets say from 0) they are higher than what they are on the end of the soldering tip, but that is normal. When they settle down they are pretty much dead spot on (+- 1-2 C).
What I see that opamp and element around it are a little bit different. Ksger v2.1 doesn't have any capacitors. That can be the thing that is different and when I get home I will add some little capacitors and test if that makes any difference.
The blank graph was an error/bug: it didn't show anything. That was not because of different read/set temperature. I know how your graph work/shows (I didn't know exact plus minus temperature). As I told you in the latest version I didn't see any problems about graph.
Now regarding temprature thing I don't get... David, please read carefully because if there is anything to do you will be way faster to know where it could be. I understand about temperature delay from heater to sensor where you read the actual temperature. When you heat things up it jumps after the temperature rise and I will not talk about this because you can say the same thing as you already told me BUT!!! I will talk about when temperature is falling... when temperature is for example 20 C over the set temperature heating is completely stopped. That is why temperature is dropping for example about 10 seconds or so linearly. When temperature drops about 1-2 C below set temperature and heating is starting at the same time the temperature is dropped about extra 20 or 30 C. That is not linearly it is dropped in the next 1 or 2 "ticks" (if I set perios to 20ms and delay to 0.1ms you can see the same thing). This is not delay after heating or not heating. I hope you understand what I am trying to explain because it doesn't make a sense. You cannot remove 20-30 C in 20 ms when you had like 1 or 2 C drop per second when you didn't have any heat on. This is main problem that I am trying to find. Please help me explain how that can happen so that I will understand. PLEASE HELP ME UNDERSTAND!
-
Buzzer is already disabled by default!
Yep, I moved Stand code after the error/sleep detection, so It would be ignored. Fixed and updated builds.
Tugo, the -+20°C jumps is either that tip, very slow reaction PID or something wrong with that board.
What I say about temperature is true.
Are you really measuring +-20°C changes?
I doubt it. Although it goes up and down, the temperature will be pretty stable due the thermal mass of the tip.
And that's what happens with all these firmwares, although they don't show you.
The only difference is that real measured temperature is shown here.
I dont know what capacitor are you taking about, but you can try removing it.
As you see other quicko/Ksger work correctly (ignoring the recent memory problem), only the PID needing some tweaking.
In any case it's a rare condition happening in that board,
or with that tip, which I can't magically see or debug.
You need a scope to see the waveforms.
Or at least debug it with swv, making a real time plot of the sensor data (like that picture I posted yesterday)
Right now the only thing I can think of is disabling the filter resetting, so it filters everything, no matter the difference.
But it'll add delay, causing over/undershoot for most tips.
Test this. Although I doubt it does better.
-
in quicko schematics there is snubber on opamp input. work very well since its 2stage amp.
doesnt needed on ksger board since there is emea sw filter already. also it will add some delay and other unneeded things like rising signal zero level.
tested. got some error code but fw restarted and didnt see it again. other things look ok
-
You're very wrong. Software can't do everything, specially when you have low sampling rates.
If you have only 5 samples per second, you can easily have quick changes from the tip heating.
You can't just filter everything, or the tip response wil be delayed, causing problems.
So the EMA filter is only applied for small differences, these you have during normal operation, maybe +-7ºC.
But not when you have +-20ºC jumps! An external analog filter small filter is always nice. The delay is negligible.
Taking in count that max voltage we need there is 20mV, 5RC would be:
1nF+4K7 is 23.5uS.
10nF+4K7 is 235uS.
None adds what you would call delay, but filter nasty spikes. Also clamping the signal with a led is absolute crap.
Furtermore, the leds will produce some voltage when exposed to light.
Put a proper fast switching diode like the 1n4148.
-
First of all thank you about everything you wrote.
I understand what you said and that is why I don't understand how this is happening.
I don't measure temperature plus minus 20, uC or how you call it real measured temperature shows that on the screen. That is why I believe there is something wrong. And since I have tips that work at 20/0.1 or tips that don't work at all, not even at 200/50, and this doesn't metter if they are Hakko or cheap tips. They work or they don't. Nothing in between.
At graph or at display I can see at lower temperature (180 to 230) plus minus 40C or at above 400C dead spot on. Higher the temperature lower plus minus C.
Fake FG 100 is giving temperatures that are way more stable but still they about plus minus 5 C or so. At stable output they are both stable. Even with this bad tip on the Ksger at any temperature set. When they sattle down they are all stable at plus minus 1 C or no more than 2.
At the moment I am packed, we are moving tomorrow morning but I will test new bin asap and let you know how it goes. I am open to any suggestions or tests. ;)
Capacitors... quicko has capacitor in parallel to diode before opamp. It also has a couple of small capacitors in parallel to feedback resistors or something like that. I am speaking from what I remember at schematic of your soldering station. Correct me if I am wrong. Ksger dont have any capacitors around opamp beside at power supply.
-
I have no idea why happens. And I can't do anything at it without watching the signals.
The timing is always the same, the temperature doesn't change anything.
So that's something caused by the tip itself. Maybe ksger knows some tricks to deal with them :-//
-
what about your strange tip - u should check clamps under tip end white cap, looks like they have sheetty connection
-
Lot of things can be done with those sheets:
(https://i.ytimg.com/vi/KUuTvERSpWA/maxresdefault.jpg)
I'm experimenting with independent pwm/read timers.
So the pwm could run at any frequency, the reading timer disables the pwm pin and triggers the adc.
I came to the conclusion that that maybe 50mS pulse stores too much heat in crappy tips.
By increasing the pwm frequency the average power delivery is smoother, so it might work better.
For now everything is crazy, althought the adc is reading spot-on when it should.
The runaway detection function deserves a promotion and a salary rise!
-
no error messages with the newest firmware either. i can not test actual soldering yet though.
-
Wickated: thank you, I will check the tip later when I will also do the from David.
I hope to get better info after I get home and put everything on the scope.
Thank you guys!
Edit: David, are Hakko tips still worst choice as cheap ones or should they be the same?
-
I don't know, never used them.
For the average hobbist the cheaps are more than enough.
Things would be different with an everyday professional use.
-
David, I thought about working with your FW. If they should perform the same and without problems?
-
I meant cheap vs genuine tips. For serious work, JBC is the way to go. Or any other good one.
In fact this FW could work with almost any cartridge (Quick, Pace), only needing initial calibration.
It depends on your work needs. If you use very simple soldering jobs, some wire here and there, anything would do ok.
But for precision jobs, no way. Ex. I repaired a lot of phones, specially usb connectors.
With the cheap solder station you sentenced the phone to death. For sure.
But with JBC was extremely easy. I very rarely went over 360ºC, even when working with ground planes.
-
Do you mean you used JBC and your FW and this HW or other JBC soldering iron?
-
No, were their tools, proper equipment, a real jbc station. 6-7 years ago.
-
On KSGER HW2.0 dont work.
Installing firmware and black display. Dont work.
With firmware 3.x launches but It does not work properly.
But if it is fine-tuned, it even works on version 3.0.
STM32F102C8
I still don't understand why the HW2.0 board version is in the 3.x folder?
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv3.x%5D/Schematic (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv3.x%5D/Schematic)
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv3.x%5D/Schematic/STM32_T12_oled_v3.0.jpg (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv3.x%5D/Schematic/STM32_T12_oled_v3.0.jpg)
I have just such a board.
bought here :
https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.6.2.6ec133edUymGDu&orderId=88969206563645&productId=32836043839 (https://www.aliexpress.com/snapshot/0.html?spm=a2g0s.9042647.6.2.6ec133edUymGDu&orderId=88969206563645&productId=32836043839)
-
It's there because, at least at sight, it has the same conections as the 3.1.
Schematics:
v3.1 (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/KSGER%20STM32%20OLED-3_0%20schematic%20rev1_cosmin_floobydust.pdf)
v2.0 (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r2/STM32_T12_oled_v2.0.pdf)
As I replied in YouTube, recently there was a bug that broke all these boards. Did you try the latest files?
When you say it doesn't work properly, please explain better. I can't do anything otherwise
So first, flash the latest 3.x version. If it still doesn't work, explain what's wrong! :-+
Ksgers needs some tuning with the PID because I don't have any myself.
The PID values are set from my Quicko tests and other people's feedback!
It needs temperature calibration by default, because I barely have any feedback from users, so I had to put safe values which are far behind the real to avoid people burning their tips.
If you don't have thermometer, try setting this values in the first system tip.
After that, new tips will use that data by default.
Cal 250 - 1459
Cal 350 - 2215
Cal 450 - 3213
But if you have it, then run a proper calibration like shown in the vídeo.
-
let me see if i can get you one @davidalfa i may be able to send you one of the v3.x boards. let me talk to someone and see i know someone who sells them. i have a few of the 2.1 boards here on hand not sure if that will help with the v3.x ones though
yes i can send you a ksger board. shoot me a pm with your info and ill get it out this week. lmk which one you prefer ill have him send that one.
-
Thanks for your offering, but I don't think it's necessary.
C'mon, I only need few calibration reports from Ksger users.
3-4 calibrations from different users would be enough.
It's pretty damn easy, only takes 3 minutes, if people don't want to spend a minute helping with that, well, Ksger support will stay as it is :-//
Do you see my signature? It's been like that for weeks. Only 3-4 users submitted calibration results, mostly for Quicko.
Don't spend a single buck at that! Just relax and recover! :-+
-
Well, not really. Just a while back you were complaining that you didn't have any Ksger hardware. Now someone is willing to give you anything you want and you say no? I'm sure calibration reports would be good. But having the hardware is good, too. Take the offer.
-
sucks i just cant solder right now. maybe i can run some quick calibrations. ive been on a soldering hold for a while now. the eye is super sensitive at the moment and they told me no solder smoke in it at all. let me see if i can have my wife hold the iron for me while i run the station. ill see when she gets home from work tomm. any specific tips you would like i have basically every single one for t12 and a number of jbc ones.
well lmk if you change your mind. all id pay for is shipping.
-
sucks i just cant solder right now. maybe i can run some quick calibrations. ive been on a soldering hold for a while now. the eye is super sensitive at the moment and they told me no solder smoke in it at all. let me see if i can have my wife hold the iron for me while i run the station. ill see when she gets home from work tomm. any specific tips you would like i have basically every single one for t12 and a number of jbc ones.
plz no. no need to hurry.
-
DavidAlfa
My station on firmware for 3.x boards seems to work, but due to very low calibration values for temperatures 250, 350 and 340, the station could not be calibrated.
I had to first put the values close to the real ones, and only after that I was able to pass the calibration without error. Perhaps this is due to the fact that the cartridges are not original.
There is also an error if the PWM and Delay values are set too close, provided that the cartridge is installed.
Without a cartridge installed, these values can be set as close to each other as possible.
-
Please read the GitHub readme. It's there for something!
If you had used cal Adjust menu (like it's explained there, and shown in the video where you asked for help!) you wouldn't have any problems calibrating.
Setting different settings that default is not covered.
It highly depends on the hardware, tips, power supply...you're at your own! Set the delay a little higher for now.
The pwm method is being changed for a different one, soon there will be a new release.
-
Well, not really. Just a while back you were complaining that you didn't have any Ksger hardware. Now someone is willing to give you anything you want and you say no? I'm sure calibration reports would be good. But having the hardware is good, too. Take the offer.
+1
David, of course it's only you who can decide what you are going to do. But I really think you got into the rabbit hole when you added "official" support for Ksger. Now you are going to have lots of questions about Ksger boards anyway. Having that hardware will probably save you a lot of guessing and time.
Actually I think it would be very convenient for you to have at least one of each different "supported" models. Maybe your home isn't big enough to have one of each different Ksger models :scared: then perhaps you should drop support for some (all?) of them.
As a Quicko owner, I will be happy even if the subject of the thread changes to "CFW for Quicko Digital Soldering Station with T12/JBC handle/tips". But, again, it's up to you to decide.
-
quite a few who are using this firmware have ksger boards. i know a few myself who follow your updates on git and they run it and update as you do. it would be a shame to cut ksger i know all my boards are ksger and i cant toss those to buy quicko boards. one reason why im happy to send one to you.
-
DAVID, PLEASE ACCEPT THE OFFER :clap: :-+
-
Yes, I complained, because there were very strange things going on. Probably the memory error that I discovered later.
Anyways, some ksgers works pretty well, while other don't. Some tips do great, others are impossible to drive.
Is it supposed that getting single ksger station is going to fix that? It won't solve the calibration problem.
Most ksgers use the same amp circuit, but have you seen how much do they differ? Maybe one gives 3200, other 3800.
I just asked calibrations to try to fix that. As you said, people download and use it, but what about helping a bit, with 3 simple numbers?
There's people who like to get everything already done. If they're so lazy, expecting things to fix by themselves, don't expect me buying 20 ksgers.
Not to talk about apparently blind people doesn't read any instructions, touchs everything, then comes here complaining.
All these things are makeing me to change my mind, and unless something starts changing, this project is not going to last much longer, not at least as it is now.
Maybe becoming a silent github page, where I commit whatever when I want.
Anyways.
Here're the new builds. It uses a different approach: The PWM is running free, controlling nothing.
Then there's the ADC timer. It controls how many times per second the tip is read, and the delay before doing so.
It forces the pwm pin low before starting the delay, and restores it after finishing.
That way no timing issues can happen. The ADC conversion time no longer needs to be controlled or adjusted.
To adjust the pwm frequency, a multiplier is used. You can set the PWM from 1x to 20x the ADC timer.
The basic idea behind that is to deliver the power in the tip more smoothly. I don't know if it will work better or not as I no longer have any tip to test (Last chinese JBC died peacefully while standing at 360ºC).
Keep in mind that faster doesn't mean better!
RAM usage 99.7% on some boards!
-
IT WORKS!!!!
YOUR NEW BUILD IS AT LEAST WAAAAAAAAAY BETTER!!!
I have to test a lot of the things but after just changing set points (250,350,450) it looks like working!
All I did was set points and went to 180C... it overshoot but when it came back down to 180... IT STAY THERE!!!!!
Every time you set it to a higher temperature it overshoot when it get to the set temperature but when it comes down to the set temperature it stay there.
From my point of view, IT WORKS!!! I only have 1 tip here with me so I cannot say about other tips, but the one I always tested and I couldn't get it to work... IT WORKS!!!!! I told you, you can do it a lot faster then me :-+ And I told you since it works with Ksger it can work. Just believe me next time when I say it is something wrong somewhere! :-+
Maybe I will need to do some more test if everyting is really working but I will stop writting and do some tests.
GREAT JOB DAVID!!!! :-+ :-+ :-+ :-+
-
This is sick! Sick in a good way!!!! :-+
I forgot if ADC time was 50ms as default but I set it to 100ms because at dhe default it wasn't 100% stable and at 100/1 it looks way more stable and as David said faster doesn't mean better. Also Ksger has 200ms/4.7ms and was ok by me, I just liked Davids FW way more and it would also be fine at the same timings if it wasn't as great as it is now. So I have 100ms/1ms/1x PWM (higher multiplier doesn't mean better and I would have to put more ADC delay so I rather put Kp to 100 to be a lot faster and also stable :-DD and by stable I mean stable with this "bad" tip I have problems with) and (as I already wrote) I set Kp to 100, I left other things to default values (Cal250, Cal350 and Cal450 are those I changed as stated in my first message).
Default values (50ms/1ms) was ok at lowest temperature but at the higher temperatures it was a little bit up and down. Not much but it was not flat as it is now. That is why I changed to 100ms/1ms. I believe it is also stable with 100/0.5 or even lower... BUT!!! completely stable at 100/1 is PERFECT FOR ME. Even if I will have to go even higher I am more than happy :-+ :-+ :-+
Again, David, thank you and expect a lot of my tip tests (I hope to have some time over the weekend when we are going home). I will also test new tips that have never been put in the soldering station so I will be thrilled to test them :-+
In case you need any test with just this tip that I have with me, please let me know.
Happy happy happy HAAAAPPPPYYYY!!!! :-DD
EDIT: I forgot to tell that I have a power supply with just about 20.5V so I will still have to test everything at about 24V. This power supply is a brick (compact one) and that is why I took it with me.
-
Overshoot is usually a PID thing. When you have issues, set Ki and KD to 0.
The overshoot should be close to none, but you'll see that the temp is always lower than the setpoint...
Now increase Ki in 5 each time until th temp is the same as the setpoint. Remember Imax, needs to be 0.2-0.4, otherwise Mi won't be able to build enough error to compensate.
If you have too much Imax, the error will sum up and when the tip reaches temperature, it will still put power at it, causing overshoot.
If you have some oscillation, ex. 5/°C up and down all the time, increase KD in very small steps, 1 or 0.5.
It should stabilize at some point. But if you put too much Kd, it will over react and make it worse!
When the timing is wrong, ex. too small delay, you'll get noise or huge temperature changes.
Ouch I see that I forgot some test values! It's defaulting to 50/1 instead 200/20.
I'd try the 10x multiplier. Shouldn't cause any trouble. It's the main update for the firmware!
Try these tips and report calibration results!
-
i did send them a message and ask again for calibrations for you. i get it trust me. ive done stuff like this before and i know what you mean where people want their hand held the whole time and want something finished. i hate to see people who really want to help (like i said im willing unfortunately its not easy for me right now my wife said she will help and get me temp measurements today this way i dont have to be anywhere near the smoke. do you have a few tips you want measurements from?)
i hope you dont discontinue the ksger myself they are all i have here and i much prefer your firmware over the stock one. i appreciate your time which is why i made the offer. i have both 2.1 and 3.1 boards available so if you change your mind just let me know. ill try the the new one here in a bit and have her get me some readings. let me know which tip you want them from like i said. ill show here how to hold it on the thermocouple and let her do it from there.
-
No worries. But as I said I can't trust just one source.
Otherwise people might start burning their tips.
If you try, doesn't matter the tip model, just try 2-3 different ones, note down the results, and then calibrate other Ksger with these same tips.
If the results are close, it'll be ok for me.
-
i have 6 of the 3.1s stations / boards here (to disassemble for different projects so let me have her check them all give me till tomm and ill have her do all 6. hopefully that will give you a good set to use. give me a day or so. i wasnt going to flash them all yet but i have the stock firmware and can go back if need be (wanted to keep a couple stock just in case something wasnt working with this firmware at the time) if she does well ill have her do the 2.1 boards also i have a few of those also.
what would you say are the three most popular tips in your opinion? and do you want china t12 tips and genuine or just genuine? and jbc also?
-
You're going to have some work! Just try different shapes. Not ones that are very close. Ex. Kf, dl32, ils... You get the point.
The more the better! Remember that genuine hakkos seemed to need more delay, around 20mS. Jbc is usually ok with 1mS.
Runaway detection is doing a great job, so I'd say you're tips are pretty safe.
-
I set 200ms/20ms with 10x multiplier (do you think this should be something else?).
Ki=0, Kd=0, Imax=0.2
Then I had to lower the Kp to 45 to not have any overshoot (50 was to much).
Ki at 5 gives me a little overshoot (about 3-4 C).
Lowering Imax to 0.1 overshoot to about 2C.
All this was at temperatures 210-270C.
When I get ti higher C (280 and up) I don't even get to set temperature :-DD
OK, here we go again... temepratures 270 and above... 270 is the temperature where I usually solder.
Kp=65
When set to 270 I get overshoot at about 3C.
When set to 300 I get overshoot at about 1C.
When set to 330 I get no overshoot.
So I set Kp to 70 and tried again to see what will happen.
Funny thing was I didn't get any overshoot :-DD But I set from 180 to 270 and it is an overshoot if Iget to 240 and then get to 270 where it gets an overshoot.
Now I cannot get anywhere with Ki set to 5 (Imax at 0.2 or 0.3). If I put anything higher than 5 I get an overshoot...
You know what... I set everything to default (75/40/10/0.40) and left 200ms/20ms/10x and I get about 8 C of overshoot (at 270, when set to higher temperature it is even lower overshoot) and about 10 seconds or so of long bouncing up and down. I am ok with everything of this! I could also set Kp to 100 and is having a litle bigger overshoot but it is getting faster the to set point.
Kp=100, Ki=40 and I tried with setting Kd to higher values and at 20 was quite faster debounce to a set value.
At the end I tried something from the start...
I left 200ms/20ms/10x as it was.
I changed just the PID settings and I got to almost the same as you set it, but I lowered Imax to 0.3 (I think this made a little more overshoot if set to 0.4) and I put Kd to 20 and this made bouncing less. When I had Imax at 0.2 I couldn't get to 450C or it got there after a longer period of time.
So my final test was at 75/45/20/0.30 and it looked very good. I just hope it will not be any different at 24V power supply. Or could it be?!
David, does this make any sense to you or should I start everything over again?
I am loosing my mind after all of this tests so please don't be angry ;)
-
That overshoot doesn't really appear at the tip so I'd leave it like that.
There are bad iron tips that overshoot badly, I think the sensor or the heater is not making proper contact with the body, so the main solution is to limit the power in the settings or use very relaxed pid settings..
Let me insist on the custom firmware part. This fw shows everything real-time. Else than a slight filtering, what you see is real.
You'll also see how different tips, even being the same model, have differences in handling the power.
Don't expect to get a superb, perfect adjustment with every tip. You could, but it would take a lot of time while barely making any difference in the real world.
Those +8ºC for 2-3 seconds only happen internally. The tip will be colder, requiring several seconds to fully heat up.
That's why you still see some power being applied, decreasing slowly, although the temps are steady. The body is absorbing that heat.
Also, any change in your system will heavily affect the PID. Going from 20V to 24V for example, will output 50->72W. That's almost 50% more power.
If the PID was adjusted to handle 50W in a relaxed way, it might work. But if it was tweaked for best response, now it will overshoot for sure.
You migh ask, how do factory fw work with all conditions? Well, as long as you keep the temperature under control, you simply don't care about oscillations.
The reading could be going 10ºC up and down all the time, but the tip temperature will filter that, staying at an average temp. So no problem!
You should attach the scope to the PWM ouout using a factory fw and see yourself.
So don't take it so serious. If you see some oscillation, try to tweak it, but it woin't do any harm, unless your settings are very wrong!
And in that case, the runaway detection will get triggerred so it's always safe.
You can try it at any time, just set Imax to 1.00 and Ki to 80.00, heat up a cold tip, the overshoot will be massive and trip the protection.
I'm thinking some options to enhance the overshooting problem.
Maybe disabling I factor while the temperature is below 50ºC from the setpoint, using only proportional, so the I factor doesn't build up.
These things require a lot of testing!
-
Thank you for your explaination and everything else.
Now I believe have 2 different options to test when I have 24 V and other tips to test:
1.) 100ms/1ms/1x with PID=100/40/10/0.40 ... this was my first test with new FW and has internal overshoot but I didn't test on the tip itself
2.) 200ms/20ms/10x with PID=75/45/20/0.30 ... this was my yesterdays final test
I will go from here and see how each tip is doing with this settings so that I know if I will have 200/20/10x or 100/1/1x
When I get more test I will publish it here so that others can see if they can be in any help to them.
Of course I will have to do a lot of different CAL informations "for you" David (you know that it is for all of us ;) ).
Again... THANK YOU! :-+
-
tested new fw. now my iron make some funny bzzzzz instead of ticking with mosquito powered FW:-DD
PID settings a bit low - tip is a underloaded, added some kI.
new type pwm feels good and reliable. i guess if mosfet would be gated with driver, it could be even better.
-
Yeah, some controllers will make more noise. Just lower the pwm frequency like before.
It's just that I forget to restore the test values I was trying and made the builds, the next ones will go back to 200/20.
Nah, the mosfet is doing well. For such low frequency it's not necessary.
I tested the JBC (10amps load) up to 10KHz, the rising/falling edges are ok up to 1KHz or so.
Have you ever wondered how a soldering station developer edition looks like?
-
most of noise i get from PSU, so i guess its time for purchasing big bulk transformer.
Have you ever wondered how a soldering station developer edition looks like?
its a bit cold outside. time to wear hat
-
Hahaha. It's much easier and handy to have the signals there. I got tired of blowing up parts every time the probe slipped and shorted something!
Fixed some bugs and reverted to normal timings.
Due all pwm changes, there was a bug where the max PWM output was being passed to the PID, instead the computed value from the power limiter.
So if you limited the power, the pwm would not follow the limit, tripping a security check and crashing the station.
Yeeeeah, there're a lot of checks. All these error messages are trigered on purpose when an undefined behaviour is detected.
Of course, new builds!
-
im showing her how to test temps now she will start later tonight and do one station at a time ill keep a chart. will let you know soon
-
New tips arrived. They're pretty rebel, but they seem to work better with higher pwm frequencies.
The adc timing is spot-on, no doubt. It's really the tip fault, doesn't return to "0" fast. Sometimes it goes down slowly, and that's what makes PID to freak out.
Also some tips heat from cold to 400 in 3 seconds, which is not notmal. It's like if the heater was isolated from the tip.
The best to drive new tips is not use Kd/Ki at all. The temp will be always a little lower but it'll work without these crazy oscillations.
I need to do more testing!
-
what kind of tips did you get? t12 or jbc? just curious
-
T12 of course, the chinese jbc adventure is over!
-
yeah the china jbc tips are all terrible imo. i have one that is okay at best but most of them are ehh. the china t12 tips are not perfect but imo better built then the knock off jbc ones a couple of the china jbc's had the tips fall off in like 10 min of use lol.
-
Hmm I think I can get over the tip unstability problems. Just increasing a bit the filter threshold.
Anyone has bouncy tips to make some tests? It's doing pretty good here.
-
china jbc tips are basically t12 ones with fat heads clamped over :-DD
-
yup that they are. i was like wtf when i got them i got a refund and never bothered again after that batch. ive yet to see a "good" one thats not original imo
-
New tips arrived. They're pretty rebel, but they seem to work better with higher pwm frequencies.
Can I ask if these are Quiko tips? That's what I have and I would like to know how to compare them. Maybe some more specifics would be helpful.
-
No, I bought these:
https://a.aliexpress.com/_uwap9r
-
tuned to this settings. for me works good enough
-
I use default 20mS with 20xpwm, seems to help with the jumpy tips. They will bounce 2 -3 times but then get stable.
I don't think I could do anythign about that. Tested a lot of things during the morning.
Filtering these huge spikes will also filter quick temperature changes, adding a lot of delay between the real and the filtered temperature, causing continuous oscillations.
Now is when I think on hiding these oscillations like rest of firmwares do. It's just impossible, at least for me.
-
since its not possible to get really quick response on t12 tips, maybe it would be good to tweak filtering to the max even if it will add like 2 seconds delay ? on jbc i only would like to see 1c estimation, so temp wouldnt jump like 299-300 all time and thats all any1 would need.
-
Please don't suggest such things like if I didn't try everything already, the current is the most stable. What you say performs really bad.
-
even estimation ? i mean cpu counts everythiing as usual but on display applies average func
-
Hi all,
This is quite a discussion.
Certainly if one hopes for a definite conclusion that moves the soldering station into a reliable competitor situation w.r.t. JBC, Unisolder, Hakko.
The basic set-up is already competitive, certainly for a multi holder solution.
I am not a development specialist. However, needing over 1300 posts seems a bit overdone.
Regards, Frans
-
Now that I am back home I did quite a lot of tests but without oscilloscope.
First of all I checked again Ksger and his overshoot. I didn't test with all tips so there might be differences but I found out it overshoot by about 10C. It is a little bit slow on the tip (on display is fast) regarding the temperature (when starting or when turning it up).
David, what I like on the Ksger and I would like to make a suggestion is:
- changing (setting) a temperature even when you don't have a tip inserted (if possible)
- changing (selecting) a different tip when you don't have a tip inserted (if possible)
Now to my tips that I have been testing (all on 24,7 V and FW from 7th of July)...
K (China) - 1566/2287/3230
K (Hakko) - I don't know what happened but I forgot what was the case with it |O
DL32 (Hakko) - 2178/2950/4095 - I set those valus manually because I couldn't get it by calibration and also 400 C was the highest stable.
D12 (Hakko) - 1530/2290/3650 - I set those valus manually because I couldn't get it by calibration and also 380 C was the highest stable.
BL (China) - 1900/2580/3400 -I set those valus manually because I couldn't get it by calibration and also 390 C was the highest stable.
All of the tips have been used before in my Ksger soldering station and was having pretty much the same problem just on the higher temperaures (420 or higher).
What I get are "spikes" when PID ar trying to go the set values so I will have to work around on getting better PID settings.
Manual values was set so that I set temperature to 250C and then I changed values to get to the correct temperature. Then I repeated all the same for 350C. Since I couldn't set to 450C I set it to highest possible and changed values for 450C so that set value was correct. I believe I set everything as it shoould be done but a little deviation is possible.
David, what do you think if we would use lower temperatures? For example 200C, 300C and 400C? This is just a question I don't make you do anything.
I will do some more tips but I don't have a lot more. I also have about 10+ more but are new and they need to be "break in".
-
did u tested on default 200/20 settings ?
-
I forgot to put that info.
It was on 200/20/10x just as you told me I should do it.
I even tested some other settongs but I forgot how they were. I will try to get the worst tip and try to change all of the settings to something that it will work and see if that will improve others tips too. I don't know when I will have time but I will try to do it as soon as I can.
If you have any othet suggestion please let me know ;)
Thank you, David.
-
David, you will hate me :-DD
I had time just to test 1 tip and I used my worst tip. That is original Hakko D12.
Then I set it to 100ms/1ms/1x which was my first sweet settings.
After that I set PID as you described how to set it and I figure out that at the higher temperatures Kd is giving me hard times so I set it to 0 for now.
Kp is 45, Ki is 10 and Imax is 0.20.
My cal values were 1585/2350/3700.
I was also able to do an automatic calibration so :-+
It gave a little to high values but not so much.
I also found out that after some time when NTC is going higher and higher... from 25 to over 30 I had temperatures also a bit higher... or lower... I forgot |O
Do we really need that temperature to compensate the temperature in tip?
Today I probably will not have time but I will test the same PIDs with 200/20/10x if it will work at 450C.
-
D12... I hope my last post about this tip I will try next tips now that I know how to do the test.
D12 Hakko tip:
100ms/1ms/2x pwm
PIDs are 45/15/2/0.20
Cal250/350/450
1600/2335/3500
Higher multiplier makes things go up and down a lot and I see that everything else is going great with other settings. David, please give a suggestion how to do any step better like you did for PID if you have ;)
And another thing for you David: is it possible to ask for another question when you click on Delete inside a tip? I hate when I was |O and deleted all my tests in the middle and had to start over.
-
Well I'm trying to calibrate after installing July, 7th update. A guy would think that, after releasing it on that date, this should have San Fermín blessing 8)
I got half a dozen Quicko-branded tips: three "standard" ones...
D16: https://www.aliexpress.com/item/32834486432.html (https://www.aliexpress.com/item/32834486432.html)
B2: https://www.aliexpress.com/item/32835767458.html (https://www.aliexpress.com/item/32835767458.html)
K -This came with the station: https://www.aliexpress.com/item/32994824865.html (https://www.aliexpress.com/item/32994824865.html)
And three "High grade" ones :-DD BC2, ILS, KU : https://www.aliexpress.com/item/32834661555.html (https://www.aliexpress.com/item/32834661555.html)
I don't think there's much difference between the "standard" and "high grade" tips, aside the black coat the "high grade" ones have. Probably they aren't worth the extra expense. Yet they are cheap, so I decided to give them a try.
All of them have been on the "warm up" phase for at least 15 minutes at 350ºC
First stage: done with default values. Temperatures measured with FG100 clone.
| Tip | Grade | 250 | 350 | 450 |
| BC2 | High | 258 | 275 | 291 |
| ILS | High | 244 | 257 | 273 |
| KU | High | 298 | 314 | 327 |
| B2 | Standard | 254 | 276 | 294 |
| K | Standard | 258 | 272 | 293 |
| D16 | Standard | 265 | 284 | 303 |
I did my best to get good readings. I did put a somewhat big solder blob on the tip, then measured twice, letting the FG100 fall under 50ºC between measurements. After the six measurements, I wicked the solder on FG100's thermocouple and cleaned the tip. So, no oxidized solder working as thermal barrier. Then did the same with the next tip. Got quite good repeatability, always with less than 2-3ºC differences. I think measurements are as good as I'm able to do.
Since FG100 readings are way under the set point at 350 and more at 450, I guessed next step was go to calibration->adjust. Maybe I'm getting it wrong? Anyway, I'm unable to do that adjustement. BC2 tip gets very close to 250ºC with 1050 ADC value; to get it to 350ºC ADC value has to go up to 1600; to get it to 450ºC it should go over ADC 2000 but here I'm getting errors... So I stopped the process here. What am I getting wrong?
I guess San Fermín is quite busy caring for the runners every morning at 08:00, then he has to get drunk as everybody else in Iruña these days. Maybe should I try again after "Pobre de mí" has been sung? >:D
One last question: Is calibration a whole-system thing? I mean, is it possible to have a calibration for each different tip, or the station should be calibrated so all tips are approximatively OK?
-
Is calibration a whole-system thing? I mean, is it possible to have a calibration for each different tip, or the station should be calibrated so all tips are approximatively OK?
both ways are possble. u can manually add different tips. preadjustment is made for purpose of avoiding tip burning. u can manually add new tip from tip menu if u have another. if u use different types of handle (for example t12 with shake switch and pace/jbc/anything another with stand switch) u can switch whole system setting profile from settings menu. there are 3 there - t12, 245, 210.
-
Tugo, you can select a different tip at any time.
No, I don't plan adding anything else. Almost no memory left. It was a challenge to fit the firmware into 10KB devices.
And no, I'm not breaking my head because the iron drifts a few degrees. I can't control it better in the way it's built.
Start repeating this: $30 Hardware limitations.
Tatel, calibration is per-tip, although new tips copy their initial values from the first tip, or from the selected tip if you use copy function.
But if you run a calibration, it will for the selected tip only. I suggest to calibrate the initial one before adding more tips, so you have a good base to start with. The difference between tips is usually pretty small and doesn't worth the effort.
-
you can select a different tip at any time.
(...)
It was a challenge to fit the firmware into 10KB devices.
And no, I'm not breaking my head because the iron drifts a few degrees. I can't control it better in the way it's built.
Start repeating this: $30 Hardware limitations.
Tatel, calibration is per-tip, although new tips copy their initial values from the first tip, or from the selected tip if you use copy function.
But if you run a calibration, it will for the selected tip only. I suggest to calibrate the initial one before adding more tips, so you have a good base to start with. The difference between tips is usually pretty small and doesn't worth the effort.
I think I'm missing something. Can I calibrate just a tip differently, then set the station to use that calibration? How can tip type settings be put at work? I mean how to choose which T12 tip i'm going to use. I'm unable to guess it. I know how to change profile. But that's not what I'm looking for.
Of course, I understand hardware limitations
-
It's in the manual.
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md
Main screen
Tip selection
Click and rotate clockwise to show the tip selection. Then, long-pressing will enter the selected tip settings.
It will return to normal mode after 5 seconds of inactivity.
There's a lot of subtleties. :)
-
Here I go...
$30 Hardware limitations.
$30 Hardware limitations.
$30 Hardware limitations.
$30 Hardware limitations.
$30 Hardware limitations.
$30 Hardware limitations.
$30 Hardware limitations.
...
$30 Hardware limitations.
$30 Hardware limitations.
$30 Hardware limitations.
David, I think I got it :-+
Maybe...
Kinda...
I hope :-//
---------------------------------
From my point of view I think first thing to set the controller is to know your board. Each board (each version, release,... or manufacturer and even each element on the board is not exactly "the same") is different in a way that for example David can run things on 10x with 200ms/20ms and is stable, but mine is not. I don't know if wickated has the same board as mine or somebody else but he had very tight settings and was better for his board. Mine don't work so good like that.
That is why I believe we should use the worst tip and first try setting up Period, Delay and Multiplier (maybe even set Ki and Kd to 0 so that you don't have problems like I had, I even set Kp to 45) that it would work stable on lowest temperature and also on the highest. When you will have it stable then you tweak PIDs like David explained how to set Kp, Ki and Kd.
Cal250 and Cal350 values are set points for calculate values for temperatures below 350 C and Cal350 and Cal450 for temperatures over 350 C. So you can set these values manually like I did or use calibration process which is great if you have stable temperatures. Even on not stable temperatures you can first use calibration process and then tweak it manually if needed. David did a GREAT JOB! Again, thank you David! :-+
Tatel: I had exactly the same problems as you and had to figure out how my board could be used with higher set temperatures. First of all not all tips are the same. Find the worst one you can find and try experimenting with settings that will be used in all of the tips (PWM period, PWM delay and PWM multiplier). Try basically everything as I explained above and before doing anything, read a link that StephenR0 gave you to have a basic knowledge what you should and could do.
-
I don't know if wickated has the same board as mine or somebody else
noone here. i changed:
1) op amp to genuine and reliable AD8605
2) gate disharge resistors to 1k
3) opamp input snabber
4) Ldo
5) PSU to stable and reliable 200w by meanwell
Yes, David is absolutely right. 30$ hardware works only by miracle. and some very fancy-pricy genuine 400$ stations doesnt even allow to change temp without master operator key. because hobby level is nothing compared to business solutions.
-
Oops, I knew I was missing something. I forgot the push-and-rotate thing since last week :palm:
I see half my tips are in 2ºC range, and all of them are in 54ºC range, using default values. So I bet this $30 hardware will serve me well. And I don't think it's working only by miracle, but by good work.
Now I'll have to see why I'm getting that error while calibrating, but it will have to wait some more days. I have very little spare time right now.
Thank you all :-+
-
The calibration error is probably because the temperature is very unstable. New tips do that a lot. So when the temperature rises, the spikes trigger no iron detection.
And It will stop calibration,of course.
Doesn't work my miracle, there's lor of work behind. But you lack a lot of accuracy. You must understand how thermocouples work. The NTC compensation is just a cheap way, does something but far from perfect.
Probably there're proper algorithms, I don't know.
I'm just tired of the damn T12 tips. How to drive them correctly to work with all? I don't know.
I've explored other projects, including the Unisolder, it has a lot of nice calculations that I don't understand but I didn't find anything that avoids that problem.
Maybe the best option is to just use proportional gain and live with 3-5°C less.
-
Well, I see my MAX 6675 can have about 7ºC error over what the K thermocouple gives, that will probably have her own error... So I'm not expecting anything better than 10ºC error here. I'm happy with that. I will be happy even if there is a 20ºC difference. I can see that San Fermín release is successful in getting the tips pretty darn good stable. Quite a lot more that the previous release. I bet it will let me do what I need and that it will be able to get my way forward with what you have given to us so far.
I was getting about 100ºC differences between the point set on my Yihua station and the tip readings from the FG100. So this is much, much better, and you can be proud of your work. It's really useful. Please don't let my cluelessness lower your morale. I'll have plenty of caffeine next time ;)
-
I consider the accuracy to be pretty good. Yes, I get some drift when the handle heats up and NTC reading changes, but maybe 5-7°C at worst.
Are you soldering or growing bacteria in Petri dishes?
It seems better to show nothing to the user. Comments like "I set 360 but I only get 358". Oh dear.
Now I completely understand why they just put the setpoint. Lots of problems solved!
For the picky people let me tell that you'll be the only suffering because it's 3°C off :-DD.
The only thing that bugs me is the unstable T12 readings.
I wish I could wipe them off.
From my point of view, that would finish the firmware.
-
The only thing that bugs me is the unstable T12 readings.
I wish I could wipe them off.
From my point of view, that would finish the firmware.
you know, i finished it via dumping all t12 tips i had. :-DD
parallel TC connection instead of series one solves some problems.
main joke is not about just showing set temp close to real tip temp, but in excluding over/undershoots. which results in solid solder joints.
and then u can finally start working on own ac solder station with zero crossing detection, universal pinout, multichanell , big rainbow screen and coffee machine. 8)
like this
-
thats pretty sweet but i doubt many will be able to afford or want to spend that kind of money. i get it id love a station like that but most people 30$ is a great price point and for most people they work plenty good enough. just imo though maybe
-
The only thing that bugs me is the unstable T12 readings.
I wish I could wipe them off.
From my point of view, that would finish the firmware.
you know, i finished it via dumping all t12 tips i had. :-DD
parallel TC connection instead of series one solves some problems.
main joke is not about just showing set temp close to real tip temp, but in excluding over/undershoots. which results in solid solder joints.
and then u can finally start working on own ac solder station with zero crossing detection, universal pinout, multichanell , big rainbow screen and coffee machine. 8)
like this
Can you spend some words on the technical specs, like a functional block and the expected results?
The pictures are very clear, so I understand what you try to achieve, no mistake here.
The control station is compact and very useful as depicted.
Thanks in advance,
Frans
-
changed stand switch from 2 wire switch to 1 wire through 1k res, noticed that station goes standby but dont sleep. with 0,1k res works mostly ok , with 0k res also dont sleep. ( stand switch line looks this : (3.3v > 4,7kR)+(stm pin > 4,7kR) > |/ tip gnd < 2,5R heater < 1MR < 3.3v )
-
Sorry, but make a damn proper schematic or drawing :-DD
The handle mode will ignore any changes in the wake input unless it's steady for at least 500mS.
Where's your electronics knowledge? Have you seen the voltage drop in the gnd wires when drawing 10 amps?
Probably you're injecting a lot of switching noise, and the wake pin is receiving constant changes.
Try using a diode like this [3.3v][4K7][--|>|--][Handle gnd].
But it' probably won't work either.
-
diode didnt work. 100R did.
i really dont bother, just chatting. 2 wire mechanical stand switch is also good if spend some time on 3d printing proper holder
proper drawing ? yeha im boss of paint.exe
-
Just use a reed relay! :-+
-
Just use a reed relay! :-+
NOOOO. i spent 100$ on jbc handle not to install reed relays in it. but ill try smth better - optical sensor switch.
-
Maybe I could check the wake input when the PWM is low, after the ADC conversion, to get a clean reading.
Try this:
-
Maybe I could check the wake input when the PWM is low, after the ADC conversion, to get a clean reading.
Try this:
i dont get what you actually changed but now it works solid as rock even on 10ms/0,1/10x. no spikes at all. i also left almost default pid this time :-DMM
p.s. in older fw, if i touch tip end on stations self ground wire, temp reading got mad due to ground drain, now not. maybe i missed new runaway detection in latest fw.
p.p.s. made some test vid like SteveyG did
https://www.youtube.com/watch?v=ZqhqccbS70U (https://www.youtube.com/watch?v=ZqhqccbS70U)
https://www.youtube.com/watch?v=-TQwp-GLd1w (https://www.youtube.com/watch?v=-TQwp-GLd1w)
-
You need more Imax!
-
You need more Imax!
thanks, now all stable! up to ~100w output on 10mm shovel tip and overshoots only 5-10c
40/40/2/0.4
i have a question, maybe its stupid a bit but what about AC driving, but using current schematics with 1 p fet pwm ? i can just go buy 2*12/24v donut transformer anywhere but no 9/18v ones
-
David, I finally managed to do a lot of test with different tips.
All was done manually so that I could get the same temperatures after a while going up or down and at the end of the tip.
Tip type (C/H... China/Hakko) Cal250 / Cal350 / Cal 450
D12 (H) 1570 / 2285 / 3500
K (C) 1600 / 2400 / 3500
K (H) 1645 / 2455 / 3880
BL (C) 1900 / 2625 / 3750
DL32 (H) 2200 / 3050 / 4095 *
D24 (H) 1850 / 2575 / 3450
ILS (H) 1660 / 2475 / 4095 *
J02 (C) 1840 / 2555 / 3380
BCF2 (H) 1870 / 2650 / 4095 *
BCM2 (C) 1640 / 2500 / 4095 *
JL02 (H) 1890 / 2760 / 4095 *
DL52 (C) 1760 / 2400 / 3220
Those with a * are not able to get 450 C but I was able to set to about 400 or 410. At those set temperatures are really lower tip values.
Those with * I don't use very much (except DL32 which should be stable at higher values but I cannot set higher Cal450 to be able to use it - I should lower a gain in opamp but my test will then be of no good for you). Any suggestion?
EDIT: FW version 7.7.2021
-
Sure, anything can be made... You will have to learn programming :-DD
-
BCF2 (H) 1870 / 2650 / 4095 *
BCM2 (C) 1640 / 2500 / 4095 *
JL02 (H) 1890 / 2760 / 4095 *
you should check opamp gain. it should have 250x multiplyer . 4000+ adc is too much
-
I doubt is the amp. It won't vary the gain between tips.
Likely these tips have little use and need more burning.
I might revert to the old 200/300/400 calibration.
But some solder alloys won't melt at 200°C...
So maybe just use different calibration values like 250,325, 400.
I could add more calibration steps but I don't think it worths it. More hassle when calibrating... The actual accuracy is pretty good in all range.
-
I doubt is the amp. It won't vary the gain between tips.
i mean gain set by voltage divider. 4000 for t12 is way too much, even on mine ad8605 opamp 450c t12 was near 2500 adc value. also this explains why he get "no iron" and so on cuz opamp output exceeds adc ipnut voltage.
250-350-400 woulld be ok since noone really uses 450 but 350 ftw
and what about ac sine power supply instead of dc voltage? with high pwm frequency will it work?
-
I understand you guys but I cannot do anything about it.
Well, I could, but then I cannot do anymore tests for David or he will have to do some calculations :-DD
DL32 is one of my oldest tip and you can be assured it is burned enough ;)
For the past 2-3 years I usually work with 270 and I almost never go over 330, but there are times I also need 380 (which is veeeeeeeery rare).
Before that I used higher temperatures and this tip was also used at higher temperatures and quite a lot so it is well burned.
I will check both resistors to calculate exact gain. Maybe that 1k resistor is lower than what it should be since it has more impact in gain.
Other than that it doesn't matter if I set it to 4095 and use just temperatures to about 380-400 since I will not go over for example "4080".
David, leave FW as it is, it is perfectly fine. If I will decide to do anything about it I will change it for me :-+
-
The fact you're soldering fine at only 270°C suggests a wrong temp measurement... It's too low!
-
The fact you're soldering fine at only 270°C suggests a wrong temp measurement... It's too low!
maybe he`s soldering wires with leaded solder? like in good old times :-/O
p.s. bought donut transformer and bridge, ll try pulse 24v (fully rectified ll be 30v, thats too much), hope 1khz pwm would be enough.
-
Not a good idea unless the voltage drops a lot or your plan is to ruin the expensive tips.
30V would out more than 300W over them.
The best would be unfiltered rectified, and synced 100Hz pwm ending at zero crossing.
The stm32 would need additional circuitry and code modifications. That's close to how jbc does it (they use ac+triac).
I also use leaded. But by no way it flows like it does at 330.
With original jbc I mostly soldered at 320.
-
Temperatures are just fine ;)
I measured it with fake FG 100 and with a Uni-t DMM with temp probe. Temp was off by a degree or spot on, but if you measure it on different tip spots you get very different temps.
I always calibrate station to set the temperature at the spot of the tip where I use the tip on the pcb. That is usually at the "far end" of the tip where it is all narrow and small. If I would have calibrate it on any other spot it would be even lower. Maybe I am doing it wrong (please tell me why), but that is how I calibrate it.
And yes, I use leaded solder, I don't use or even have any lead free solder. If I would have one that would have been another story.
David, why is 270 C too low for leaded solder?
When I see that there is lot of ground or higher mass to solder I also put +50C to use there (or even higher).
-
30V would out more than 300W over them.
jbc uses 24v ac transformers. so they have 30v too. i meant usage of only bridge w/o caps, so it rectified unfiltered i guess and 100hz. high frequency pwm should be ok, but as i see, stock circutry is unable to work stable over 1khz.
my plan is too get rid of awful acustic noise i get from pulse PSU and get 12+24v for later c210 hadle+tips expansion.
p.s. i calculated a bit, read some info about mosfet drivers and other stuff and decided to wait and build DC supply but with donut transformer, so i returned mine to shop and ll order 2*9v 10a from manufacturer. 2 month or so waiting time. :horse:
-
Resistors measured on the pcb are 0.999k and 247.3k.
I guess about 250 gain is just fine.
-
Resistors measured on the pcb are 0.999k and 247.3k.
I guess about 250 gain is just fine.
and input ones? should it be 1k-5k
try change 247k to 200k.
-
wickated: what?
Those 2 values are 2 resistors that define gain.
you should check opamp gain. it should have 250x multiplyer . 4000+ adc is too much
It is about 250x.
I agree with you that 4000+ is too much.
I also told in my message which was in general for David: "I should lower a gain in opamp but my test will then be of no good for you."
So I only have 2 options: to leave it as it is and I will use it as it is or I will change the gain and I cannot help David with my other tips. Hmmm... I just thought of something: Maybe I can put a switch on the side to lower the gain for some of the tips and use it just when needed :-DD :-+ This could be for example to put a 1 M resistor in parallel with a switch ;)
-
be careful with some of these boards the ones that showed up today both had pieces of solder bridging legs on the stm32 chips and some stray solder pieces all over the board. one had 6 bridges on the stm32 chip i had to pick off. they were not directly soldered together but there were pieces of extra solder bridging them they came right off with a small plastic pick. not that all will be this way but this one was its also a better stm32 then most of the others have had on the with the stm32f103rbt6 my wife should be done with all the tips i gave her in the next day or two again sorry for the delay. the eye went downhill some more and i had to go back in again friday and today
-
mastershake I am keeping my fingers crossed that everything will be better from now on about your eyes.
Just take your time and don't hurry. You have only 1 pair of eyes.
Good luck!
-
Forget about testing, recover the best you can! :-+
-
Hi guys,
I flashed the latest (Jul 7) .bin to my Quicko T12 station with a STM32F072C8 MCU. Everythings seemed to be fine, beside ...the iron won't heat up. The bar graph is at full scale deflection but there are no PWM pulses at the iron connector. Older builds worked like a charm.
What I've done so far:
- read the last pages of this thread
- played around with the menu options
- checked older builds, (Jul 4, ok; Jul 6, not ok, no heat up)
- compiled the project on my own (also not ok)./li]
Hmm, did i miss something or is there something wrong with the latest builds? What should i do next?
-
a few of you messaged asking which display i used to change it over to white here is the link. these work nearly perfect. they are just a tiny bit taller but if you carefully bend the header pins before soldering them in you can raise it up a teeny bit and then it will still fit in the aluminum case where the window is. for the ksger 3.1 they are plug and play just solder and go. hope this helps someone out.
https://www.aliexpress.com/item/32903968632.html?spm=a2g0s.9042311.0.0.73824c4dN3l7ws (https://www.aliexpress.com/item/32903968632.html?spm=a2g0s.9042311.0.0.73824c4dN3l7ws)
-
Hmm, did i miss something or is there something wrong with the latest builds? What should i do next?
Very bad, you should have read the 56 pages in this thread!! (Just joking) :-DD
Let me check it. Since I upgraded my Quicko to a 103, I no longer can test that build.
Thanks for reporting the issue :-+
Edit: I missed that Quicko uses alternative PWM pin config, so after the adc conversion, enabling the pwm pin wasn't loading the alt pin cfg. Fixed.
Also commited the stand mode detection test. Wake is read after adc conversion to have a clean reading, avoiding switching noises.
For normal "shake" mode, the pin is read normally at 1KHz sample rate.
Try the latest Quicko F072 build!
-
Try the latest Quicko F072 build!
Hi David,
wow, what an incredible fast response time :-+ I did a quick check of your latest build. And yeees, it heats up! More testings tomorrow.
Thank you very much, Sir!
-
Great! :-+
-
bought one more controller same type i had (2.1s v3.3.). have stm32 onboard. so i ll have to install mods on it and wait for 210 handle. i also have some time to select big 2" screen
-
I just opened up my new 2.1s ksger and there appears to b e a 78l08(U6) voltage regulator feeding the ams1117 3.3v regulator.
[attach=1]
Doesn't this mean that the 78l08 would need to be dissipating 1.6w if it was stepping down the voltage from 24v? The ams1117 would be dissipating less than 0.5w so it would be fine but the 78l08 must be well over 100c, even 125c. The most I ever got out of a dpak voltage regulator was 1.9w before thermally throttling(heaps of copper wire to heatsink the heat away too).
-
I just found out about the new firmware by David today on YouTube, did not know that it had forked and improved so much :o
Anyways I updated the initial post with a link to devidAlfa's GitHub and posted a couple related videos
https://www.youtube.com/watch?v=x9ohNL2J2lU (https://www.youtube.com/watch?v=x9ohNL2J2lU)
If you guys would like me edit my initial post with more quick links to relevant fw/iron mods in the initial post, PM me these links and I will add them
-
Cool review, but I feel he could have tweaked it further!
At least my last D52 is pretty strong, I could solder 4mm2 wires into a battery pack without issues. I also threw away the rohs solder and got good old 60/40.
That solder melted at 235ºC, making the work much harder, not really a problem when assemblying, but when repairing, specially when trying to remove a multi-pin package.
-
I just opened up my new 2.1s ksger and there appears to b e a 78l08(U6) voltage regulator feeding the ams1117 3.3v regulator.
(Attachment Link)
Doesn't this mean that the 78l08 would need to be dissipating 1.6w if it was stepping down the voltage from 24v? The ams1117 would be dissipating less than 0.5w so it would be fine but the 78l08 must be well over 100c, even 125c. The most I ever got out of a dpak voltage regulator was 1.9w before thermally throttling(heaps of copper wire to heatsink the heat away too).
That package is sot223, I doubt it can even handle 0.5W without thermal vias and huge copper pads.
Were did you get the power from? Did you measure the current? Between the stm32 and the oled, it maybe draws 10mA, 15 at most. I didn't measure it, barely looked at the datasheets ac and dc characteristics.
I don't think it gets over 0.3W in any conditions. Have you tried it?
-
Cool review, but I feel he could have tweaked it further!
At least my last D52 is pretty strong, I could solder 4mm2 wires into a battery pack without issues. I also threw away the rohs solder and got good old 60/40.
That solder melted at 235ºC, making the work much harder, not really a problem when assemblying, but when repairing, specially when trying to remove a multi-pin package.
FYI the test board he is soldering to is 4 solid copper layers, all pads are on a single plain (like a ground plain) and all 4 layers are stitched together! >:D
-
Yes it's an unrealistically difficult board to solder with, but that's the point. Any normal PCB will work just fine.
Increasing the temperature would likely work, but the point is that's a good indication the soldering iron or tip is of poor design. It's also not recommended as some devices are particularly sensitive to thermal shock.
-
Sure! With the jbc C245 station I rarely went over 350 in any conditions, usually 320, while with T12, 360ºC is the start :-DD
Anyways, the heat shouldn't be a problem, if the solder barely melts, how is it going to heat the part so much?
Well, yes, if you have to put the tip in the pad for 30 seconds until it melts, that's not good.
I usually put a very small blob of solder and wait 2-3 seconds until it starts flowing and filling the hole / pad, then I add a second one, it will flow like butter in a frying pan.
But always making the main heat transfer spot in the the pad, not in the pin. On through-hole you'll definitely need to touch the pin, but again, I don't do it from the beginning, but when the solder has already filled the hole slighly.
This is all talking about these solid pads. 99% of solder operations are done a single touch.
Good news: It seems I found a way to remove these nasty spikes with new tips while yet providing fast response.
I mean, completely new tips will still have some weird behaviour, but not that extreme.
All by adding a simple "spike counter" and playing with the filtering factors. Only applying the heavy filtering is applied while in normal behaviour, and reducing it when the change is big, with 2 additional thresholds.
So in total there're 4 filtering levels:
- Diff lower than "Smooth start", considered normal noise. The filtering factor adjusted in system settings is applied (Heaviest filtering).
- Diff between "Smooth start" and "Smooth end" trigger excessive delay detection (tip heating or cooling too fast), so the factor is lowered to 2 to reduce the response time.
- Diff between "Smooth end" and "Reset_max": This is considered a spike, so it's counted and ignored for a maximum of 4 consecutive times, using normal filtering. I the counter hits the limit, reduce filtering to a factor of 1 for max. filtering response, but still provide some filtering.
- Diff higher than "Reset_max": Very huge change. This is usually when a tip is removed and /or put back. Completely reset the filter using factor 0, will override the filter data with the last reading.
This also seems to allow bigger filtering values. I've tried factor 4, seems to help a lot with these spikes, and didn't get any overshoot. So it's the default now.
I opened 2 new tips, and I was able "burn" them into working state in less than a minute.
Set 300ºC. It will oscillate a bit, maybe 280-320. It will progressively dampen, and after 10 seconds or so it will get stable. Sometimes you will get temp runaway error, just click the button and let it start again.
Repeat the procedure rising temps to ex. 370 and 450ºC and let it sit at least 15 seconds each time to ensure it's stable.
The tips are still very new and will do some little jumps when approaching the setpoint, but stay spot-on after that.
After few more changes I've gotten it to the point where I can put all the power onto the tip with only 6ºC difference (400ºC setpoint, 100% at 394ºC touching the wet sponge).
That was with my last tip, which I opened 15 minutes ago! It should behave like a wild beast, but seems to be under control.
Ksger v3 ram is 100.00% used! Adding anything else will require either sacrificing somewthing or huge changes in the code!
Updated builds! :-+
-
I just opened up my new 2.1s ksger and there appears to b e a 78l08(U6) voltage regulator feeding the ams1117 3.3v regulator.
(Attachment Link)
Doesn't this mean that the 78l08 would need to be dissipating 1.6w if it was stepping down the voltage from 24v? The ams1117 would be dissipating less than 0.5w so it would be fine but the 78l08 must be well over 100c, even 125c. The most I ever got out of a dpak voltage regulator was 1.9w before thermally throttling(heaps of copper wire to heatsink the heat away too).
That package is sot223, I doubt it can even handle 0.5W without thermal vias and huge copper pads.
Were did you get the power from? Did you measure the current? Between the stm32 and the oled, it maybe draws 10mA, 15 at most. I didn't measure it, barely looked at the datasheets ac and dc characteristics.
I don't think it gets over 0.3W in any conditions. Have you tried it?
No I didn't measure the current I thought I saw from a couple of posts that it needs 100ma, that's what I was basing my numbers on. If it's only 10-15ma then I'm sure it's fine then.
Btw the 78l08 looks like a sot89 device and the 1117 3.3v is sot 223 and sot 223 can handle 0.5w pretty easy even free standing(they're 110c/w), the cpu temp sensor on my station reads the correct room temperature when I first turn it on then over the next 10-15min it's temp rises about 17c then it's steady from then on.
-
100mA is crazy for a stm32! Yeah, you're probably right about the power, anyways, I wouldn't be happy with a regulator working at 110ºC!
Little update and new builds.
I went a little too far with the settings, in some cases filtering x4 delayed the changes too much, causing oscillation. Lowered to x3.
Also some cosmetic issues fixed caused by the recent font changes (When I added the special symbols). I hadn't noticed them until now.
The converter code reports lower font height than it should, messing up some buttons. Manually patched the heights, problem gone.
Also changed the default PID settings (again). I swear these work great with my 10 tips of all sizes. The temp rises like a rocket and stops like if it had hit a concrete wall.
As always, remember these values are meant for the stock PWM speed. If you increase the frequency, it'll probably mess up the PID response too!
-
Hi,
I have a KSGR v3.1s bought directly from China. The board is a little different from the picture on github. It has an STM32F101 instead of the STM32F103 like in the picture.
Do you use the v3.x on github or any other firmware?
Also, was anyone successful in getting a copy of the original firmware from the v3.1 board before flashing and would like to share it? I don't have access to an STM32 development to do the timing attack.
Thanks.
-
Github readme:
KSGER v3.1 [STABLE]: Profile compatible with all STM32F101/2/3xx. Use 101C8 profile.
Boards/KSGER/v3.x/compatibility.txt:
Only the STM32F101 build is provided.
It will work perfectly with 102 and 103 devices
I know some people here has the firmware because they switched the firmware to try the differences. I don't have them!
It would be a nice thing to add into the project.
-
Thanks for the reply.
After flashing I get this written on the screen:
[attach=1]
-
Ksger v3 ram is 100.00% used! Adding anything else will require either sacrificing somewthing or huge changes in the code!
Should we advise to get a STM32F103 MCU or the respective CKS clone?
https://aliexpress.com/item/32994824865.html
(Disclosure: not affiliated)
-
Ksger v3 ram is 100.00% used! Adding anything else will require either sacrificing somewthing or huge changes in the code!
Should we advise to get a STM32F103 MCU or the respective CKS clone?
https://aliexpress.com/item/32994824865.html
(Disclosure: not affiliated)
The CKS is supposed to be functionally equivalent, but who knows. If you can managed to get hold of a genuine STM32 chip, I'd be tempted to drop it in as a replacement.
-
Thanks for the reply.
After flashing I get this written on the screen:
(Attachment Link)
Oops, that line is a malloc, it wanted another 4 bytes and obviously it failed.
I think there's still some margin for the stack, so I reduced it in 32 bytes.
Try this, if it works I'll upload it to github. Edit: I'm pretty confident. Uploaded anyway!
Should we advise to get a STM32F103 MCU or the respective CKS clone?
You have a quicko F103, so what are you worrying about?
I don't think it's necessary. It's tight, but for now it'll work. I'm not planning to add lots of new features, for now all my effort is going into making it work smooth as possible.
I spent the whole morning in changing the code, trying to dinamically load each screen, so only the displayed screen uses ram resources. But for now it's just a test, still having a lot of issues.
But it could reduce ram usage in 25% easily.
I have no idea about the CKS. It'll probably work ok, but who knows. I had a cks blue pill, no issues else than ST debugger complaining about not genuine part. Worked nicely with openOCD.
It's doing something inside the stereo of my car :D
-
Thanks, now it works fine.
There is a small bug with the adjust menu in calibration. When I change the value of adc from 1100 to 1150 the save option appears, if I changed it more the save option disappears!
Although I'm still messing around with the firmware but the temperature reading seems to be way off. I think this is by design since you don't want to burn out tips. But for the 250 C for example the actual tip temp. is around 150, that's a lot I think, adc needs to be increased to 1400-1500 for the tip to reach around 240 C.
I'll continue calibrating and report back the calibration results for all the tips I have after you fix that save option disappearing issue.
Thanks again for the hard work. I really love the feel and look of the new firmware.
-
Not a bug, that's intentional.
If there're no changes, or the changes don't follow Cal250 < Cal350 < Cal450, the save button is disabled.
Adjust the values ensuring there's no overlap, and it'll let you save.
Yes the tip is lowered on purpose. I don't have enough calibration reports from users, so for now it will be like this.
1400 ADC for 250ºC is pretty normal, even a little low. My Quicko does about 1450-1850-2450. But it's a different hardware, also I lowered the amp gain to use C245, they give 2x the output of T12 at the same temps.
-
You have a quicko F103, so what are you worrying about?
I don't think it's necessary. It's tight, but for now it'll work. I'm not planning to add lots of new features, for now all my effort is going into making it work smooth as possible.
I spent the whole morning in changing the code, trying to dinamically load each screen, so only the displayed screen uses ram resources. But for now it's just a test, still having a lot of issues.
But it could reduce ram usage in 25% easily.
I have no idea about the CKS. It'll probably work ok, but who knows. I had a cks blue pill, no issues else than ST debugger complaining about not genuine part. Worked nicely with openOCD.
I'm worrying about people asking "which KSGER/Quicko should I buy?" There is a thread like that in this very same section of the forum. To find that the new soldering station purchased has a limited MCU where the RAM usage is one 100% would be appalling, at least to me, should I know after the purchase that there are other stations, perhaps even cheaper, that will have RAM usage about a 50%.
Now you say RAM usage could be reduced in 25%: good. Nobody's in inminent danger to run out of RAM. That was unclear to me until you said RAM usage can be easily reduced from where it's currently. But even so, I would have been disappointed, should I have bought a F101 station. I'm sure that extra RAM will come handy sooner or later.
I'm happy to own a clone CKS F103 MCU; I bought the station on the Quicko store following your advice, and paid just 29.34 EUR, with PSU said to be able to give 108W. It also has a 24V 4A rated DC input, 9501 handle, 6-pin GX connector and is ESD safe. No primary protective earth, however . Now there are other station models, not so cheap, that seem to have F101 MCUs, without PSU, some 80 watts, "bad" handle, 4-pin connector and no earth connection at all. So I'm not worrying about my station, but do care about the advice I could give to a prospective buyer. The sheer amount of models available makes it confusing. I think being able to say somewhat like "these three models are the worthiest to be considered" would be A Good Thing (TM)
I have some STM32 spares: at least one of them passes all tests so it's probably original. Others not checked yet, but I hope they are original too. However, so far I don't think it would be worth to substitute one of them for the CKS clone now in the station. IIRC, other people in this thread have CKS-based stations too, and I don't see any bad reports coming. Also I can't find bad reports about them on the Net, but I can find bad reports for other clones. So, it wouldn't surprise me if the current Chipaggedon will make clear that CKS clones are a worthy, cheap alternative to STM original ones. Perhaps a guy is asking himself right now if he should care about seller's warning that for the time being, they have resourced to CKS clones. Maybe he could find it handy to see some reports from CKS users.
Last, people looking at these stations do care about the money, or they would be considering original Hakko stations at least. When they ask, they hope to get advice to buy the best bang for the buck. Now, do we have a clear picture about what model is that best bang for the buck? Or, would we be giving contradictory information based just on our personal, limited experience? I for one know I have been unable to answer that "which model to buy" question.
-
one of mine has the cks chip on it and all seems to work the same as the real stm32
-
I see your point. I think Quicko offers better hw for the money, although their fw is terrible.
KSGERs are more expensive, while they reduced costs everywhere they could.
Anyone could put a 103 there and compile their own by just changing the linker script to the 103.
Or by modifying the 101c8 script, replacing 10kb with 20.
So what's going on? I put a lot of hope in the new release, where most tip issues seem to be gone, and nobody is testing? :-DD
-
I see your point. I think Quicko offers better hw for the money, although their fw is terrible.
KSGERs are more expensive, while they reduced costs everywhere they could.
Understood. I'm happy this coincides with the advice I gave.
Anyone could put a 103 there and compile their own by just changing the linker script to the 103.
Or by modifying the 101c8 script, replacing 10kb with 20.
Good. However I wouldn't buy a F101 based station having cheaper stations with F103 available. Not worth the hassle, I think. But there could be other reasons, unknown to me, that would make F101 advisable?
So what's going on? I put a lot of hope in the new release, where most tip issues seem to be gone, and nobody is testing? :-DD
I have been playing with calibration: I quite fast ran out of FG-100 thermocouples... clones, should I say? I found it somewhat difficult to get repeated results, and I'm not trusting those readings so much. Also they doesn't seem to last much more than a couple dozen readings; I wonder if just a naked multimeter thermocouple would do it better... or perhaps something like a PT100 RTD, interfaced to an arduino and a 7-segment display? I think it couldn't be worse that my FG100 clone. But, anyway, new FG100 thermocouples are on the way. We'll see if they are any better.
https://www.digikey.com/en/products/detail/innovative-sensor-technology-usa-division/P0K1-520-6W-B-010/13686726 (https://www.digikey.com/en/products/detail/innovative-sensor-technology-usa-division/P0K1-520-6W-B-010/13686726)
-
ksger randomly uses 101,102 or 103 its a luck of the draw basically with those. i own 5 and only 2 have 103's i actually mostly saw 102 chips (i ordered these in for the kids learning to solder) and only one of them had a 101 on it.
so my wife turned on the 3.1s after using the newest firmware today (i needed her to touch something up for me and it was a really easy thing i knew she could handle) and after calibration set to even 350 with the k t12 tip it barely melted the solder at all. we tried re calibrating it still acted like it was way to cold. grabbed another non flashed stock 3.1s station and heated right up with the same tip no issues at all instantly melted the solder. any thoughts on why?
-
I have been playing with calibration: I quite fast ran out of FG-100 thermocouples... clones, should I say? I found it somewhat difficult to get repeated results, and I'm not trusting those readings so much. Also they doesn't seem to last much more than a couple dozen readings; I wonder if just a naked multimeter thermocouple would do it better... or perhaps something like a PT100 RTD, interfaced to an arduino and a 7-segment display? I think it couldn't be worse that my FG100 clone. But, anyway, new FG100 thermocouples are on the way. We'll see if they are any better.
I had the same experience. I didn't even get ten readings that I trusted from the ones that came with my FG-100 clone. So, I ordered these.
https://www.ebay.com/itm/261905476277 (https://www.ebay.com/itm/261905476277)
These seem much more reliable. I'm still on my first one and it seems just fine.
-
I'm testing the latest firmware for my Quicko with a CKS processor. Everything seem to work just fine. Calibration seemed to be the same as before. There is some hunting up and down, maybe about three degrees once things stabilize. I don't think that's a problem, though. So, given the new knobs in the menu, what should I tweak if I want to? I'm not completely clear what affects what yet.
-
But there could be other reasons, unknown to me, that would make F101 advisable?
F101/102 are just cut-down versions of the 103. Other than cheaper, nothing else.
and after calibration set to even 350 with the k t12 tip it barely melted the solder at all.
Strange. Maybe a bad calibration? Did you compare the results against older calibrations?
I'm testing the latest firmware for my Quicko with a CKS processor. Everything seem to work just fine. Calibration seemed to be the same as before. There is some hunting up and down, maybe about three degrees once things stabilize. I don't think that's a problem, though. So, given the new knobs in the menu, what should I tweak if I want to? I'm not completely clear what affects what yet.
Do you mean oscillating up and down few degrees? Did it automatically reset the settings after flashing? Otherwise its better to manually reset them, as there're new pid values.
First play with the filter factor. Try 2 and 4.
Then try increasing and decreasing Kd by 10. If it doesn't get any better, try reducing Kp to 70 or so. If it still does it, reduce Ki to 60.
Maybe you have one of these tips where the sensor is poorly attached to the body.
But if the problem is just few degress, don't worry too much. Do you have other tips to compare?
-
I had the same experience. I didn't even get ten readings that I trusted from the ones that came with my FG-100 clone. So, I ordered these.
https://www.ebay.com/itm/261905476277 (https://www.ebay.com/itm/261905476277)
These seem much more reliable. I'm still on my first one and it seems just fine.
Good to know. I got these:
https://aliexpress.com/item/32803533834.html (https://aliexpress.com/item/32803533834.html)
Now I think they look as clones again... weĺl see how they work
-
Do you mean oscillating up and down few degrees? Did it automatically reset the settings after flashing? Otherwise its better to manually reset them, as there're new pid values.
First play with the filter factor. Try 2 and 4.
Then try increasing and decreasing Kd by 10. If it doesn't get any better, try reducing Kp to 70 or so. If it still does it, reduce Ki to 60.
Maybe you have one of these tips where the sensor is poorly attached to the body.
But if the problem is just few degress, don't worry too much. Do you have other tips to compare?
Yes, I mean oscillating up and down few degrees.
Yes, I manually reset to defaults by holding the button during startup. That's a habit now. :)
I did try those two filter values. 4 seemed to lengthen the cycles, but not change degrees up and down.
I'll try the steps that you suggested. I have five different tips that I can compare with. I haven't tested more than one yet, though. I'll work on it. Thanks.
-
My calibration data:
Board: KSGR 3.1 with the STM32F101 and the 28-07-2021 version of the firmware. Temperature Measured with a Hakko 191 iron thermometer clone with a new sensor.
All tips are KSGR branded, some are with a black tip which is more expensive and supposed to be of a better quality, which certainly are not.
B : 1677, 2338, 3199
D12:1622, 2260, 2938
D52: 1615, 2251, 2947
J02: 1636, 2305, 3087
J02 Black head: 1655, 2334, 3234
K: 1640, 2297, 3094
I have a problem with 2 of the black heads tips, D16 and D24. When connected the overshoot quite a bit. Set for 300 for example, the board gives it power when under 300, it immediately shoots to 500-600 degrees on screen (nothing like that on the thermometer), then start going down slowly until when under 300 degrees and have a slight power then it overshoots again.
On the original firmware those tips used to fluctuate wildly around the set temperature.
I know these tips are of lower quality or the thermocoupler is not bonded correctly, I want to try to make them usable though. I think I need to the change the Kp,Ki,KD, Imax and Imin for those 2 tips, how do I go about doing that?
A few suggestions for the firmware:
1-Adding the option to round robin, when at the start of a menu, if you rotate the knob counterclockwise it would go to the last item on the page, useful when you enter a wrong menu or just want to get to the end of the menu without scrolling all the way down.
2-Show the name of the current tip profile on the main screen, useful to make sure you have the correct tip selected especially with those big difference in calibration values.
3-Show the name of the current tip profile on the calibration screen, there is enough room I think.
4-When adding a new tip, and opening the edit tip menu it shows the ADC values of that tip which are the default 1100, 1200, 1300, but when opening the adjust menu when calibrating that tip, it shows the values you added for the first tip you adjusted. 1450, 2200, 3100 for example, is that a bug or is it intentional? And if it was intentional, why not add a new menu with those values since they seem to be universal for all tips and specific to the board and not for each individual tip.
Thanks again for the hard work. The firmware completely changed the station for the better.
-
Another board picture. It is from Handskit.
-
Thanks for the calbrations.
Yes, new tips copy calibrations from the 1st tip, to provide a close match to start with.
As you see, your tips have some differences. So I left the door open to that posibility.
I made the round robin a while ago, but it was too easy to go back to the other side, which I found really annoying.
The graohics are not designed to work as a continuous roll, instead it goes back to the upper side and first item.
Everything can be done, but this is just something I do in my free time. In fact it takes too much free time.
The tip name is something easy. Will look at it.
No problem in the calibration screen, but there isn't enough space in the main screen for it.
Maybe removing the icons...
I won't reduce the heater font size, that's the main thing I wanted in this fw. I hated these small letters.
I've been working hard to implement the dynamic screen loading. It's working almost perfect now. Yet to ensure there're no bugs as I had to move and split a lot of code.
The required ram is greatly reduced. Some screen will use little as 224bytes, while the largest (SYSTEM menu) uses aroudn 1832.
But together they would sum up ~6KB. So now it uses just 30% of that :-+. So no worries.
-
Thanks for the calbrations.
Yes, new tips copy calibrations from the 1st tip, to provide a close match to start with.
As you see, your tips have some differences. So I left the door open to that posibility.
I made the round robin a while ago, but it was too easy to go back to the other side, which I found really annoying.
The graohics are not designed to work as a continuous roll, instead it goes back to the upper side and first item.
Everything can be done, but this is just something I do in my free time. In fact it takes too much free time.
The tip name is something easy. Will look at it.
No problem in the calibration screen, but there isn't enough space in the main screen for it.
Maybe removing the icons...
I won't reduce the heater font size, that's the main thing I wanted in this fw. I hated these small letters.
I've been working hard to implement the dynamic screen loading. It's working almost perfect now. Yet to ensure there're no bugs as I had to move and split a lot of code.
The required ram is greatly reduced. Some screen will use little as 224bytes, while the largest (SYSTEM menu) uses aroudn 1832.
But together they would sum up ~6KB. So now it uses just 30% of that :-+. So no worries.
Seems like a lot of work, wish you the best of luck.
For the tip name, I think you can free up some space if you decrease the size of the temperature unit, Making it as big as the actual temperature value is not very informative imho. If you decreased it's size by half you can put the tip name above it, directly under the ambient temp. sensor data. Just an idea.
I have a problem with 2 of the black heads tips, D16 and D24. When connected the overshoot quite a bit. Set for 300 for example, the board gives it power when under 300, it immediately shoots to 500-600 degrees on screen (nothing like that on the thermometer), then start going down slowly until when under 300 degrees and have a slight power then it overshoots again.
On the original firmware those tips used to fluctuate wildly around the set temperature.
I know these tips are of lower quality or the thermocoupler is not bonded correctly, I want to try to make them usable though. I think I need to the change the Kp,Ki,KD, Imax and Imin for those 2 tips, how do I go about doing that?
Would love some feedback about this problem please, which values do I change first and by how much to try to make these tips work.
-
imo those black tipped ones were terrible i ended up tossing a few of them the regular ksger ones without the black tip worked far better imo. neither one is still a genuine hakko though.
im going to reflash this board and see if that fixes this heating issue i did a full reset and new calibration same tip as i said is fine with the stock firmware on a second unit but it refuses to fully heat up on this one for some reason. ill try that in a bit and let you know.
-
Strange, because everything is mostly the same.
The sensor spikes are filtered for a limited number of times, it shouldn't affect the overall temperature.
Don't tell me about how bad it melts, check the real temperature! If you correctly calibrated 250,350 and 450 steps, then the setpoint should be almost spot on.
-
I have a problem with 2 of the black heads tips, D16 and D24. When connected the overshoot quite a bit. Set for 300 for example, the board gives it power when under 300, it immediately shoots to 500-600 degrees on screen (nothing like that on the thermometer), then start going down slowly until when under 300 degrees and have a slight power then it overshoots again.
On the original firmware those tips used to fluctuate wildly around the set temperature.
I know these tips are of lower quality or the thermocoupler is not bonded correctly, I want to try to make them usable though. I think I need to the change the Kp,Ki,KD, Imax and Imin for those 2 tips, how do I go about doing that?
I had to use really low numbers to stop this oscillation. It goes unstable with only Kp=40, Ki=0, Kd=0, so I settled on for now Kp=20, Ki=15, Kd=5
-
But doing so won't put all the power into the tip... These oscillations are mostly due the filter response and the tip itself. Just a bad combination.
As long it just 3-5º oscillation, it's better than lowering the tip power. Like the penny soldering test, if you set 350 and the tip was reading 340, that clearly means there weren't 80w anywhere at the tip. If you don't see the lower powerr graph rising to at least 80% with a 10ºC drop, it's no good!
Also play with the Delay. Sometimes reducing it gets better! My current tips seem to be happy with 1mS.
I also get oscillations when I rise the PWM frequency. That's why I keep 200mS ADC time and 1x pwm.
When you have these problems, it's always better to make a video. Otherwise I can only guess what's going on.
I'm testing a different layout. Slight smaller font (But not half, I want to read it perfectly 1meter away), and changing the power bar to a vertical one.
-
It's not just 3-5 degrees, it's jumping all over the place. Please see the photos and video.
I think I won't play with configuration universal to the board and all the other tips since I have other tips that are working fine with the default setting, changing values like filter or the delay will have an effect on those tips that are already working great and regulating correctly.
My problem is those 2 tips. They worked with the KSGR firmware, although the temperature readings was fluctuating wildly.
Video: https://www.dropbox.com/s/2lglwrc362dcmoi/Pxl%2020210729%20145112698~2-1.m4v?dl=0 (https://www.dropbox.com/s/2lglwrc362dcmoi/Pxl%2020210729%20145112698~2-1.m4v?dl=0)
-
I had to use really low numbers to stop this oscillation. It goes unstable with only Kp=40, Ki=0, Kd=0, so I settled on for now Kp=20, Ki=15, Kd=5
Thanks for the reply, and for letting us know about this great project.
I just tried those PID values: Kp=20, Ki=15, Kd=5 and Kp=40, Ki=15, Kd=5
There does not seem to be much different between the two, and they are both acceptable for these bad tips I think.
-
Are you sure the tip is correctly calibrated with these values you showed? ~1600-2300-3000?
Remember that new tips always have these problems, they need some time. Some are just unusable.
Set a high sleep time and let it cook at 300°C for a while.
If in a few minutes it's doing the same, then start working on the settings. Try KD (derivative) values between 5 and 50. Too little and won't compensate enough, too high and will over react doing it worse.
But 40/0/0 will give awful pid response.
The pictures.you showed show an oscillation of +-15°C not terrible, but could get better.Try lower filter factor...
-
Another board picture. It is from Handskit.
Try the Ksger v2 fw. Never seen that board before, but there are several clones copying the Ksger schematic.
-
Are you sure the tío is correctly calibrated with these values you showed? ~1600-2300-3000?
Remember that new tip always have these problems.
Set a high sleep time and let it cook at 300°C for a while.
If in a few minutes it's doing the same, then start working on the settings. Try KD (derivative) values between 5 and 50. Too little and won't compensate enough, too high and will over react doing it worse.
But 40/0/0 will give awful pid response.
Those tips are not new, been using them for a while, I don't think they need any beak-in time.
After playing for a while with the D24 tip I managed to get it as close as possible with as high values for the PID as possible.
Kp=35, Ki=15, Kd=25
First picture is without load, second one is when I put the tip on a big thermal mass, it dips a little bit, then stabilizes, and overshoots a bit after releasing the load.
Other good tips does not behave like that, it's a straight line even under the load of a thermal mass.
The other D16 tip needs different numbers though, it still oscillates at these PID values. Great thing is that PID is defined for each tip and not for the whole board.
And please don't change the load meter to vertical :)
-
But doing so won't put all the power into the tip... These oscillations are mostly due the filter response and the tip itself. Just a bad combination.
As long it just 3-5º oscillation, it's better than lowering the tip power. Like the penny soldering test, if you set 350 and the tip was reading 340, that clearly means there weren't 80w anywhere at the tip. If you don't see the lower powerr graph rising to at least 80% with a 10ºC drop, it's no good!
It's not 5°C it's 50°C but not critically damped, so it gets worse then locks out on overtemperature
-
dark_hawk:
What are your settings for ADC time (or period), ADC delay, PWM multiplier and Filter (those 4 settings are in Iron menu)? Those settings are the first thing I had o set to "good" values so that I could even start anything else. Values that David told you are on my hardware (which is different then David's) the way to go.
100ms, 1ms (which could also be 0.5ms but for safety I set it to 1ms), 1x (but could also be 2x and not anything higher on my hardware) and I set filter to 2 (different values wasn't as good for me).
David: I am glad you finally came to my settings ;) I don't know if you remember but 1ms was way better than 20ms and 1x was stable and 10x wasn't (2x was almost ok or pretty much PID dependant). My period is 100ms (50ms was a little to fast and 200ms was slower and I wanted faster soldering iron). One more question: do you have enough soldering tips from my hardware or would there be in any help if I would give you even some other tips? I don't know if I have any used ones so I would have to burn it a new ones. I am still at 7th of July and I didn't use it at all because I didn't have time so I didn't update it to new version. Thank you for all the work that you do!!! :-+
-
first of all set adc delay to normal values like 10-20 ms
-
If anyone is interesting there is a cheap option to get this soldering iron. It is STM32 based. It is 31€ including delivery and VAT. I see there are 1o available.
https://www.banggood.com/groupshopping-item-1911768_1764061.html?rmmds=category&cur_warehouse=CZ (https://www.banggood.com/groupshopping-item-1911768_1764061.html?rmmds=category&cur_warehouse=CZ)
A few notes:
Under about it says
HW Version: 2.1S
SW Version: 2.11
I have tried to switch handle from KSGER to this one and is says error the same in reverse. So wiring must be little different in the handle, but i think this will not make any difference.
-
dark_hawk:
What are your settings for ADC time (or period), ADC delay, PWM multiplier and Filter (those 4 settings are in Iron menu)? Those settings are the first thing I had o set to "good" values so that I could even start anything else. Values that David told you are on my hardware (which is different then David's) the way to go.
100ms, 1ms (which could also be 0.5ms but for safety I set it to 1ms), 1x (but could also be 2x and not anything higher on my hardware) and I set filter to 2 (different values wasn't as good for me).
I didn't change any settings in the iron menu since I have 6 other tips that are working fine and regulating correctly with the default value, my problem is with 2 specific tips that I know have a physical problem but I want to run them anyway. So changing these values in the iron menu will mess up the 6 good tips for the sake of 2 duds.
-
A question:
Form the theory of operation part of the operation guide:
"The voltage is basically proportional to the difference between tip temperature and room temperature. The controller uses PWM (Pulse Width Modulation) to control the tip temperature."
So the controller measures the room temperature through the temperature sensor in the handle? If that is correct, then if the handle gets hot, the temperature sensor in the handle also gets hot. For me when calibrating the reading of the sensor is around 35 degrees, but with extended periods of soldering that reading jumps to around 45. So that means that actual tip temperature will be 10 degrees above the calibrated temperature. I tried adding those Fiberglass Braided tubes around the sensor but it does not seem to help.
My question: wouldn't it be better to move that NTC from the handle to socket?
-
A question:
Form the theory of operation part of the operation guide:
"The voltage is basically proportional to the difference between tip temperature and room temperature. The controller uses PWM (Pulse Width Modulation) to control the tip temperature."
So the controller measures the room temperature through the temperature sensor in the handle? If that is correct, then if the handle gets hot, the temperature sensor in the handle also gets hot. For me when calibrating the reading of the sensor is around 35 degrees, but with extended periods of soldering that reading jumps to around 45. So that means that actual tip temperature will be 10 degrees above the calibrated temperature. I tried adding those Fiberglass Braided tubes around the sensor but it does not seem to help.
My question: wouldn't it be better to move that NTC from the handle to socket?
Yes the handle sensor heats up a little when you're using it, while using the cpu temp sensor is more stable after it's been turned on(though from when you first turn it on the cpu temp sensor is 17-18c lower than where it is after 10-15min, after 10-15min though the cpu temp sensor is more stable - on mine anyway).
-
dark_hawk:
What are your settings for ADC time (or period), ADC delay, PWM multiplier and Filter (those 4 settings are in Iron menu)? Those settings are the first thing I had o set to "good" values so that I could even start anything else. Values that David told you are on my hardware (which is different then David's) the way to go.
100ms, 1ms (which could also be 0.5ms but for safety I set it to 1ms), 1x (but could also be 2x and not anything higher on my hardware) and I set filter to 2 (different values wasn't as good for me).
I didn't change any settings in the iron menu since I have 6 other tips that are working fine and regulating correctly with the default value, my problem is with 2 specific tips that I know have a physical problem but I want to run them anyway. So changing these values in the iron menu will mess up the 6 good tips for the sake of 2 duds.
After your worst tip is going to work, your normal tips will also work.
When I had problems I used the worst tip that I could and set everything that it started to work. Other tips were not a problem. David put a nice tutorial how to find a good PID setting for each tip and that was my main problem.
I had problems with oscilation on default settings. Those are Davids settings in which I never believed in but I always believed in Davids firmware. That is why I always insisted it had something that it didnt work on my hardware from the start. When he changed FW I told him he is on right path and that he did a perfect job. I also told him my HW doesnt work well with default settings. I could use delay as low as 0.5ms and period to about 50ms but for stability I set to 100 ms and 1 ms.
Another thing... set Kp to about 40 and Ki and Kd to 0. Then change period and delay to lower values. Use the worst tip you have and see how it behaves on 350C. When it should work, test it on 250 and 450 if it is ok. After that check if your other tips are working as they should. Oh, i have filter set to 2 and I dont know if it is set to highet values in newer version of FW but I also had some problems with it. I just forgot what was wrong with it. 2 is perfect for me.
-
I flashed the 2.x firmware 7-28 build on my ksger hw v2.1s and the rotary switch is reversed when set to the default "normal," I had to switch it to "reverse" to have it back to normal.
I also have a hw v1.5 and issue is NOT present on this one, rotary works normal.
-
After your worst tip is going to work, your normal tips will also work.
When I had problems I used the worst tip that I could and set everything that it started to work. Other tips were not a problem. David put a nice tutorial how to find a good PID setting for each tip and that was my main problem.
I had problems with oscilation on default settings. Those are Davids settings in which I never believed in but I always believed in Davids firmware. That is why I always insisted it had something that it didnt work on my hardware from the start. When he changed FW I told him he is on right path and that he did a perfect job. I also told him my HW doesnt work well with default settings. I could use delay as low as 0.5ms and period to about 50ms but for stability I set to 100 ms and 1 ms.
Another thing... set Kp to about 40 and Ki and Kd to 0. Then change period and delay to lower values. Use the worst tip you have and see how it behaves on 350C. When it should work, test it on 250 and 450 if it is ok. After that check if your other tips are working as they should. Oh, i have filter set to 2 and I dont know if it is set to highet values in newer version of FW but I also had some problems with it. I just forgot what was wrong with it. 2 is perfect for me.
Thanks for the detailed reply.
I actually managed to get those 2 bad tips to stop oscillating with just tweaking the PID values and are working relatively fine now.
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3617005/#msg3617005 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3617005/#msg3617005)
The first one values were 35/15/25 and the second one were 30/15/25.
Yes the handle sensor heats up a little when you're using it, while using the cpu temp sensor is more stable after it's been turned on(though from when you first turn it on the cpu temp sensor is 17-18c lower than where it is after 10-15min, after 10-15min though the cpu temp sensor is more stable - on mine anyway).
I'm not aware of an option in the firmware to switch the temperature sensor from the handle's NTC to the controller's sensor.
I just moved the NTC from the handle to the socket that plugs into the unit, the ambient is now stable within 2-3 degrees compared to the 15-17 degrees when the ntc was in the handle.
But now I need to recalibrate all the tips again since the readings now are actually a bit higher since the NTC is reading lower.
I'm just waiting for David's reply to see if there is something in the code that compensates for the handle getting hot with use.
-
That usually happens with new tips. If the tip has already some use, the only explanation is to be defective.
Probably it can't handle the power. I mean, it can't tranfer the heat properly.
What happens when lowering the power to 20W or so?
-
I flashed the 2.x firmware 7-28 build on my ksger hw v2.1s and the rotary switch is reversed when set to the default "normal," I had to switch it to "reverse" to have it back to normal.
I also have a hw v1.5 and issue is NOT present on this one, rotary works normal.
That's the first report I have from the ksger v1.5. It was completely untested.
What probably happens is that actually the reversed one is the v1.5!
Normal encoder behavior is to move down (and increase values) when rotating clockwise.
So what station is doing it wrong?
I'm almost done with the new version. All bugs are gone, now I'm fully testing it and thinking the interface layout.
The ram looks really good now.
5.35Kb are fixed (HAL, oled buffer, other variables).
Without dynamic allocation, it used 10KB (99.99%). Now in the worst condition (SYSTEM screen, which is huge) it uses 7.1KB.
The screen/widgets memory usage was reduced down from 4.7 to 1.7KB, which is a 64% reduction!
-
I flashed the 2.x firmware 7-28 build on my ksger hw v2.1s and the rotary switch is reversed when set to the default "normal," I had to switch it to "reverse" to have it back to normal.
I also have a hw v1.5 and issue is NOT present on this one, rotary works normal.
That's the first report I have from the ksger v1.5. It was completely untested.
What probably happens is that actually the reversed one is the v1.5!
Normal encoder behavior is to move down (and increase values) when rotating clockwise.
So what station is doing it wrong?
David, I also have Ksger 2.1s and had to reverse it to work normally. This is present (at least for me) form the start but I thought others have the same version and not have this problem |O
-
And you say that now? How am I going to guess that? :-DD
Fixing it in a breeze.
-
mine was reversed too, but i never bothered cuz just swapped encoder wiring since its not mounted onboard
-
1.5 encoder works perfectly, its 2.x that has the bug:
Clockwise it moves up
Counterclockwise moves down
-
You're terrible beta testers! :horse:
Always complaining about little things or personal likes while missing the important! Learn from ricktendo >:D
Fixed, new builds will be ok from now.
Ricktendo, please test the v1.5 throughly. The software is the same thing for all, don't try to find bugs there.
Just test the hardware functions: buzzer, oled, pwm, encoder, tip/ambient/supply readings...
-
You're terrible beta testers!
why? its always a lottery of what type encoder will chinese place onboard. they can even place 20 tick instead of 24 tick one.
-
Hi David, you think you can make the default offset on v1.5 to zero instead of two?
I do not think 1.5 has the same offset problem as the other boards (I could be wrong,) hopefully somebody else with a 1.5 can confirm this.
Note: I have a 1.5 with a yellow/blue color lcd, this is a smaller size screen than the 2.1s similar to (if not exactly) this one https://deathmarch.net/archives/1414
Edit: I will test the 1.5 more thoroughly when I fix my fake Hakko FG-100, buzzer, ambient and supply readings all seem fine.
-
they can even place 20 tick instead of 24 tick one.
The encoder resolution is something irrelevant. But the direction will be the same!
Hi David, you think you can make the default offset on v1.5 to zero instead of two?
Of course, that can be done for each specific profile. But nobody's telling these things! :-//
Added a new define in all board.h files to make it profile-specific. Took me 30 seconds!
What are the offsets you're getting in the different models?
-
David:
What do you think about moving the NTC from the handle since it gets hot to the socket? Will it affect operation?
-
No! That's how it's supposed to be. You're not measuring the ambient temperature, but the thermocouple cold junction temperature.
A thermocouple generates voltage based on the temperature gradient between the hot side and the cold side.
It has 2 different metals. Those metals go all the way from the sensing tip until the end of the probe.
The temperature gradient ends where it reaches the connector (When the material changes).
Actually, it makes a second TC in series, luckly copper and solder generate little to nothing.
It gets really really complex when you dive into it!
Optimally that junction should be at 0ºC for best performance, no compensation would be required.
Since it's impossible to achieve that in a lot of applications, you must compensate somehow... And that's why the NTC is there!
The TC will either output nothing or negative values if the hot side is colder than the cold side.
In this case, we can only read positive values. So if the junction is at 40ºC, any measurement will be over that temperature.
Of course, it will drif a bit. There are a lot of complex mathematics behind a compensation algorithm, which I'm not doing.
As I said before, this is a soldering station, not a a bio genetics laboratory. 5ºC off are completely acceptable.
Read a bit about thermocouple cold Junction compensation! :popcorn:
Otherwise, why the *** would the station care about the ambient temperature? Just a fancy reading? :palm:
I modded my Quicko and moved the sensor to the handle to make exactly that!
I'm going to start saying a famous quote in the developing community, "use it or change it".
That means exactly that, when something doesn't cover your needs or likes, fork it and make your own!
Don't like the font? Don't like the interface? Can't live with a 3ºC error? Change it! Or contribute to the project! :-+
-
You're terrible beta testers! :horse:
Always complaining about little things or personal likes while missing the important! Learn from ricktendo >:D
Fixed, new builds will be ok from now.
From my end: I AM A TERRIBLE BETA TESTER! :-+
Now go live with it and make your god damn good firmware and stop :horse: us :-DD
When I made my first post you guys really had a debate for couple of months and nobody said anything so every time I just got into a settings and change that. Even when I did some tests and compile it I change that in the code so that wasn't a big deal and I really thought only my board is like that :-DD
Well... I think I will have to review it from the start to see if I missed anything else :o
EDIT: Regarding NTC: I set temperature to about 350 C and wait some time so that NTC is getting a little bit higher and then I do my tests with ADC at 250, 350 and 450. So when I will start using the tip the temperature will be a little bit less than what is should but will get to the desired after a while.
-
I'm running 20mS again.
I don't get nasty oscillations at all, but the power bar is going up and down by 20% all the time, which means the tip is not getting enough clearance to give a clean reading.
There are somw people here thinking the best is to have ultra fast pwm, ultra fast delay, ultra fast everything... when you must simply use what is correct.
I set up the D52 @ 400ºC, NTC @ 26ºC. The attached probe read 402ºC.
After 5 minutes, the NTC had heated to 38ºC. The probe read 401ºC.
So I don't see any issues at all.
-
to set things clear. ntc could be placed anywhere if tip and handle could withstand temp. its only a must if your handle get hot to 60c , what chinese certainly do :-DD in my casei use very high quality china copper wires, that get hotter than anything else and obviously placed ntc nearby, which results in pretty good readings.
There are somw people here thinking the best is to have ultra fast pwm, ultra fast delay, ultra fast everything... when you must simply use what is correct.
its pretty obvious that jbc tips require much faster everything. and im pretty happy with current 100hz adc readout.
-
I'm just waiting for David's reply to see if there is something in the code that compensates for the handle getting hot with use.
Thanks for the reply.
I was not trying obviously to do something new or asking for work or code to be written, I'm trying to learn, hence my question about if there was compensation for the change in the NTC temperature and if it affects the readings of the tip not that I wanted it implemented.
I just did the same test you did with a D52 tip @ 400 C, and the difference between an NTC reading of 33 to 45 was about 4-5 degrees which is negligible imo, we are not working in aerospace applications after all.
Don't like the font? Don't like the interface? Can't live with a 3ºC error? Change it! Or contribute to the project! :-+
I actually like the font and the interface a lot. I wish my scope of knowledge covered programing for the STM32 but it doesn't so all I can do for the project is report any bugs I find and suggest ideas for you to consider.
-
What is the difference between "Reset Profile" and "Reset Profiles"?
Reset profiles does not seem to do anything when you click reset.
Also when you click "Reset Profile" I get the error message in the photo. And after I click the knob it resets the board and the first boot menu shows.
-
Added a new define in all board.h files to make it profile-specific. Took me 30 seconds!
What are the offsets you're getting in the different models?
2.1s offset is perfect at the default two
1.5 offset is perfect at zero
-
If anyone is interesting there is a cheap option to get this soldering iron. It is STM32 based. It is 31€ including delivery and VAT. I see there are 1o available.
You can buy a stm32 Quicko for 32€, fully made!
https://www.aliexpress.com/item/32931458502.html (https://www.aliexpress.com/item/32931458502.html)
My question: wouldn't it be better to move that NTC from the handle to socket?
Well, I didn't wrote that, it's not 100% accurate. "Room temperature" refers to the cold side. As I alreay said, the thermocouple will start generating voltage when it's hotter than the cold side.
So, you need to know the temperature is in the cold side! Stop making your own thoughts. It's placed where it should be.
If you move it away to a colder side, then for sure you will get a more noticeable drift.
What is the difference between "Reset Profile" and "Reset Profiles"?
Reset profiles does not seem to do anything when you click reset.
Also when you click "Reset Profile" I get the error message in the photo. And after I click the knob it resets the board and the first boot menu shows.
Have you seen the message after entering each option? "Reset current profile" vs "Reset all profiles" ?
Or did it error appear instantly after clicking on reset profile?
The profiles are the T12, C210, C245 slots.
You might want to reset only the T12 because you messed up something, but preserve the others.
Or wipe all profiles but keep your system settings.
Or wipe only your system settings but keep the profiles.
Or wipe everything.
I'm still working on fixing few things, also had to find a way to backup the menu position, because it's very annoying that its resets to the first entry when returning to the previous menu.
Because now the screens are destroyed on exit, also does the menu position. It was easy, but there are always subtle things causing a lot of trouble, and it takes a lot of time to spot them!
Will check the reset menu later. I know it worked before, because I tested it, but I also made some changes, so who knows.
Edit: Fixed. There's a check that decides if the system must be resetted or not after saving the settings to the flash. I misstyped the name, forgot the "s" from "profiles", so that specific reset option was broken.
I'm doing a better calibration menu, as now there's memory for that, with the 3 calibration options.
Also, turning the heater on only when the value is being edited.
-
so an update about that one tip. its odd. this one "k" tip i was talking about refuses to work with the custom firmware properly. its something with the tip and the firmware. it heats up in the stock firmware and a different k tip will calibrate and heat up just fine with the custom firmware. so its this one tip. i tried re calibration a number of times just like any other tip but something is causing it to not heat up. so its not the firmware as i said another k tip brand new just opened heats up after calibration just fine. but the question why the this tip specifically acts this way is weird. i am testing it with a thermo and it does get up to temp properly (or close enough) with the stock firmware but even after calibration is nearly 100 deg off in the custom firmware (which is of course why it was not melting solder). ill have her try another k tip later i have that is used to check that one also.
-
New builds availale.
Fixed all known bugs and few more, everything seems to be working.
Since there's plenty of ram available I added a PID debug menu that plots P, I and D.
The main screen is half-done, lacks the icons and I left the vertical bar, I know its ugly, it'll be changed later, but I'm really tired.
This is just a test build, what matters is to be error-free. There're a lot of internal changes!
There's a small one in calibration adjust (Already fixed), it won't heat up the first time you click the the widget, you need to change the value first!.
-
Yesterday, I had an error message about "Delta too high" during calibration with V1.5. This one: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/calibration_screen.c#L372
The 4 lines message doesn't fit on the small 0.97" screen. Text overlaps with the box where you must enter measured temp so that part needs a cosmetic fix. Also I'm not really sure what I did wrong to get that error but since it wouldn't accept the measured temperature I entered and there's no "cancel" option I couldn't get out of that screen. I ended up turning off the unit.
Anyway, great work. So far, I like it a lot :-+
-
First play with the filter factor. Try 2 and 4.
Then try increasing and decreasing Kd by 10. If it doesn't get any better, try reducing Kp to 70 or so. If it still does it, reduce Ki to 60.
So, I've been testing my tips further. Four of my tips seem to act pretty much the same. The temperature oscillates up and down, about three degrees up and three degrees down from the set temperature. I tried changing the filter factor to 2 and 4. 4 seems to lengthen the period of the oscillations, but not change the magnitude. I tried increasing and decreasing Kd by 10. That didn't seem to affect it. Then I tried reducing Kp to 70. That didn't help either, so I set it back. Next I tried reducing Ki to 60. Again, no improvement.
Now one of my tips is much worse. It's an ILS tip that has several hours of burn in. That tip oscillates about 11 degrees up and 7 or so down from the set temperature. I've been through all the steps that I mentioned before and the only thing that improves things is setting the filter factor to 4. This seems to lengthen the period of the oscillations, but more importantly, the magnitude goes down some, something like 7 degrees up and 5 degrees down from the set temperature.
As I recall from using these tips with previous versions of the firmware, I didn't have these oscillations, even with the ILS tip. Of course, it's always jumped around a little. These larger oscillations only started happening with the recent changes.
So that's my experience so far. For reference, I'm still on the 7-28 firmware.
-
Yesterday, I had an error message about "Delta too high" during calibration with V1.5. This one: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/calibration_screen.c#L372
The 4 lines message doesn't fit on the small 0.97" screen. Text overlaps with the box where you must enter measured temp so that part needs a cosmetic fix. Also I'm not really sure what I did wrong to get that error but since it wouldn't accept the measured temperature I entered and there's no "cancel" option I couldn't get out of that screen. I ended up turning off the unit.
Anyway, great work. So far, I like it a lot :-+
Edit: I tested it, same thing. That screen also had a lot of changes recently. Another bug! (Now fixed). Not related to the screen size, just the code!
Stephen, I'm starting to suspect from the new PID algortithm. I might revert it to the old one.
-
whats really odd is that one k tip is working okay now with this newest version? after calibration its only about 3-5deg off or so. that tip was still in the handle in that station and i usually will flash your newest builds so i did and thought why not at least try to calibrate it quick and its good now.
-
Hah! Must be gremlins, didn't touch anything related to that!
Finished the main screen, fixed the calibration screen and reverted the PID to the old one.
Sorry for so many builds, I thought I was going to stop until tomorrow... but It seems I didn't! :D
Everything updated!
Now I'm struggling with the flash! Some devices have only 360 bytes left...
Some tips seems to work nice with filter 3 and Kd 45...
-
Sometimes I get this error message when no tip is inserted, get them more when the handle is disconnected. Don't know what triggers it.
Also, did you change something in the PID algortithm? Reason for asking is that calibration data seems to have changed a bit for the same tips.
-
PID has nothing to do with calibration! The calibration results will be slightly different everytime. Maybe +-10...20. That's normal.
Edit: You're right, I also got noticeable differences. Hmmm, let me check the new alibration screen... However, the adjustment is spot-on!
(Edit2: It might be that I changed the temperature probe to a new one!)
About the runaway error: It can happen sometimes. When the tip is removed, the temp reading rises a lot. That's how the iron detection works.
However if the reading rises too slowly, it can trip the runaway detection before it reaches the no iron threshold.
I relaxed a bit the runaway timings. Hope its better now.
Will make new builds later.
Anyone can report the oled offset for ksger v3?
I also need more calibration results, specially for ksger v1.5!
From now, Ksger v2/v3 will use default calibrations of 1600-2300-3000
-
I also need more calibration results, specially for ksger v1.5!
Those are cal values for some of my tips, I still have to calibrate a few others (BCM2, C1, ILS, JL02). If that's important, note that my station isn't ksger branded.
Type, cal250, cal350, cal450
BC2 1193 2039 2884
KR 1059 1559 2594
J02 983 1535 2555
KU 1277 2124 2970
-
Are you using v1.5 firmware? It'd be nice if you could attach some pictures of the board :-+
New builds! No need to reset if coming from recent builds, just little bugs or nehancements, not settings-related.
-
PID has nothing to do with calibration! The calibration results will be slightly different everytime. Maybe +-10...20. That's normal.
Edit: You're right, I also got noticeable differences. Hmmm, let me check the new alibration screen... However, the adjustment is spot-on!
(Edit2: It might be that I changed the temperature probe to a new one!)
About the runaway error: It can happen sometimes. When the tip is removed, the temp reading rises a lot. That's how the iron detection works.
However if the reading rises too slowly, it can trip the runaway detection before it reaches the no iron threshold.
I relaxed a bit the runaway timings. Hope its better now.
Will make new builds later.
Anyone can report the oled offset for ksger v3?
I also need more calibration results, specially for ksger v1.5!
From now, Ksger v2/v3 will use default calibrations of 1600-2300-3000
v3 offset is 2.
I think v3 calibrations for 450 C is a little high at 3000. With the new version most tips calibrate at around 2800-2900
-
From now, Ksger v2/v3 will use default calibrations of 1600-2300-3000
plz no. 1400 2000 2600
-
Are you using v1.5 firmware? It'd be nice if you could attach some pictures of the board :-+
Yes, I am using v1.5 firmware. As for the pictures, it looks exactly like the board from ksger (at least the pics you have in your github). Same layout, same components but the brand is DXC and it came with a non ksger firmware. So maybe they stole the design or they bought the board from the same supplier as ksger.
-
I've been testing the latest firmware. Four of my tips seem to behave in a similar manner. The temperature still jumps around some, something like 2 degrees above and below the set temperature. And again the ILS tip was a little wild, something like 9 degrees above and 6 below the set temperature. But it doesn't have that regular oscillation like it did before. So, I made an entry in the edit tips menu for the ILS and started experimenting. First, I increased Kd by 10. That did seem to make the jumps smaller, but I changed it back and went on. Then I reducied Kp to 70. That didn't change anything, so I changed it back. Then I reduced Ki to 60. That seemed to quiet things down some. So I increased Kd by 10 again. Then the ILS started acting like my other tips, 2 degrees above and below the set temperature. Interesting.
BTW, I really like the currently selected tip display. That's really nice. I'd like to understand the PID debug display when you're ready to explain it. :)
-
plz no. 1400 2000 2600
You have modified yours. Am I supposed to make the firmware for you own needs?
Also these are defaults for T12 only.
BTW, I really like the currently selected tip display. That's really nice. I'd like to understand the PID debug display when you're ready to explain it. :)
PID debug menu plots are:
Proportional--->
Integral--->
Derivative--->
I'm finding the setpoint to be almost perfect between 250 and 450ºC.
However, going under 250 clearly loses a lot of accuracy, because it interpolates the difference between 250 and 350.
Not really a problem because nobody's soldering at 180ºC... I've trying to fix that but seems pretty much impossible.
-
PID debug menu plots are:
Proportional--->
Integral--->
Derivative--->
When I looked at it, Proportional and Derivative were straight lines. Only Integral seemed to change. I'm guessing that's normal.
-
PID changes depending on the tip readings, so won't change much unless there's load on the tip.
Clean the tip in the wet sponge you will see how it reacts.
-
plz no. 1400 2000 2600
You have modified yours. Am I supposed to make the firmware for you own needs?
Also these are defaults for T12 only.
those are for factory device
-
my station isn't ksger branded.
Same here ygi my v1.5 station also does not say ksger instead it says yuanhe, but as you can see from my pictures my board is EXACTLY the same as PT Dreamer's (the board that started this all)
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3617550/#msg3617550 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3617550/#msg3617550)
-
Ok! :-+ I was wondering if it was different (Ex. like JCD T12 and Ksger 2.1, different boards but same circuit), to add it to the board pictures.
I flashed older fw versions (Holy *** the interface was terrible :-DD), the tips perform, at best, the same, when not going absolutely crazy!
-
Got the new thermocouples. They are exactly the same that StephenR0 posted. At the very least, they react much faster than the ones that came with the FG100 clone.
Testing last build. BC2 tip. Default iron and PID values (active detection off). At first got big oscillations, about more than the height of graphic display. FG100 didn't detected any oscillation, however. I guess thermocouple thermal mass in some way attenuates these oscillations? After calibrating, always with default PID values, oscillations are mostly gone, -5 +10, and the readings on the FG100 show a difference to the set temperature of 20º at most. Callibration values 1421, 2082,2395
When going from lower to higher, oscillations are bigger at first, then for a few seconds after setting a higher temperature it stabilizes. Under 400º set point, they are about -5 +10º, as said before, and they doesn't seem to get any flatter with time. But at 400º, they become almost flat quite fast.
When going from higher to lower temperatures, I'm getting a nice ramp until the new, lower set point is reached, then I'm seeing the flatests graphics ever. Oscillations about -1, 0º.
FG100 readings are spot on set points 300,350,400º. At most a 2º difference. At 450º the FG100 reading is 430. At 250º, reading is 235. Quite repeatable. So I guess my calibration could get better, but this is enough for me.
I think that going as high as 450º is excesive. No matter how much I clean the tip, tin oxidizes almost instantly and the readings obtained are less trusty, IMHO. Sometimes I can hear dilatation clics coming from the tip. Also, Quicko doesn't recommend going over 380º. I'm using Qicko tips exclusively, this BC2 is one of the "high grade" :-DD type, with the black coating, and is the most burned in one. I would suggest that the higher calibration point would be nicer at 400º
Very nice to have the selected tip visible in the screen. BTW, how many ºC are represented by each step in the graphic? Just curious...
All in all, I would say this is a big improvement. First times, I was getting resets while trying to calibrate at 450º. No more. Now it's easier to callibrate and temperatures are much more stable.
On the flop side, I noticed some weird behaviour while editing tips. Usually I create a DFLT tip with the same values as the firmware-included BC3, then I delete BC3. This time, it was not possible, after creating a new DFLT tip, when deleting BC3, it was DFLT which got deleted. After some times, I created a BC2 tip, calibrated it, then noticed that it was still with default values when going to see calibration values. Then somehow I deleted BC3. Then BC2 got calibration values again? I'm not really sure what happened. However, I'm not drunk yet, I can swear it.
David, thank you very much. This is getting better and better.
-
The internal TC is not properly bonded to the body and fluctuates a lot, but the tip body had the thermal mass. The probe is doing nothing to filter the changes.
I'm sure the stock fw also oscillate, because you can hear how it changes...more..less...on..off.. all the time. I guess it's just normal with these tips.
Edit: Definitely, I missed a line of code where it reads the previous screen widgets to find out the selected tip.
However now the inactive screens are destroyed, so it was reading garbage.
Fixed!
-
Forgive me if this has been asked and answered, I looked in the Operations Instructions and FAQ but did not find the anser
Is there a Boost mode setting/feature, if not is it possible to add this to the feature requests?
-
The main thing I wanted in the fw was to keep it minimalistic, away from a lot of adjustable widgets in the main screen and having to navigate beween them, selecting, deselecting... that's a mess.
That's why it's done that way. Every encoder action has its own function.
So,there are no free actions for the encoder in the main screen. All of them (click, long click, rotate, click and rotate) are used.
Anyways, why? When you can simply turn the encoder. It'll be worse to have to go somewhere to select it or doing some long-clicking thing.
Call me old grump, but I always saw the boost as a stupid thing. Depending on the board you'll need different boost temperature and time.
Having to adjust any, will be more annoying than just cranking up the temps.
Otherwise, something will need to go. Like the temperature plot graph.
BTW, how many ºC are represented by each step in the graphic? Just curious...
It draws +-20ºC from the set point reference. So if you set 300ºC, the drawable range is 380-320ºC.
The plot height is 40 pixels , so it's 1px/ºC
-
The main thing I wanted in the fw is to keep it minimalistic, keeping the main screen away from alot adjustable widgets, having to navigate beween them, selecting, deselecting... that's a mess.
That's why it's done that way. Every encoder action has its own function.
So,there are no free actions for the encoder in the main screen. All of them (click, long click, rotate, click and rotate) are used.
Anyways, why? When you can simply turn the encoder. It'll be worse to have to go somewhere to select it or doing some long-clicking thing.
Understood
But for whatever reason it were to be implemented it could be a increase in degree setting (example 50) from the current temperature setting (example 350, boost would increase to 400)
I think double click would be a good boost shortcut and maybe single click to exit (or use the dial in any direction to go back to set temperature and maybe adjust up/down in the direction the dial has turned)
-
Hmm you gave me an idea. Maybe selecting the setpoint, and quickly doing a long-press...
The main thing is to not cause trouble with other settings. There are a lot of checks everywhere.
-
Isn't long press already used to get to settings from the main screen?
I think double click from the main screen is a good option, because click right is already taken by tip selection, click left for standby/sleep
-
Edit: I made it even easier.
When you adjust the setpoint, there's 1 second timeout before returning back to normal screen.
If you click within that time, boost mode will be enabled.
Instead of a fixed temp, I made the boost mode as an offset which is added to the actual setpoint. Here we start again, people will want one or another.
I think this way is better. If you are soldering a sensitive board, you'll want a lower temperature, and boost relative to that setpoint.
Then you take a 4mm board with thick traces, you aren't going to enable boost time after time, instead, you'll set the temp for the average needs of that board.
If you find something hard to solder, it'll be better to boost the actual temp.
Otherwise youll have to go to settings and change it every time.
Options added to IRON settings.
Click while the setpoint view is enabled to trigger boost mode.
Click at any time in main screen view to exit sleep, standby, and boost modes.
View modes (Numeric or graph) can't be switched unless it's running in normal mode (The first click will exit the mode).
The flash is struggling really hard. Althought I removed and simplified some code, I saw 232 bytes remaning in one of the builds! That's only ~115 instructions!
Since the reserved flash for the settings can't be less than 2KB (Page size), and less than half of it was used, I increased the tip capacity to 20.
Does anyone know how to create Makefiles, so I can run an automated build for all targets?
The biggest issue is to run cubemx code generation automatically.
Building by hand is a tiresome job!
BTW, I was planning to literally lie dead in the sofa and relax for a while. You had to mention the boost thing, didn't you? :-DD
Try this pid: 60-60-10, Imax 0.50, filter 2.
Builds updated!
-
BTW, I was planning to literally lie dead in the sofa and relax for a while. You had to mention the boost thing, didn't you? :-DD
I know that I speak for everyone when I say, please take care of yourself. We love the work that you do, but you have to keep yourself in a condition to do it. Please, be selfish about this! :)
-
Today I have first time flashed the iron. Have used Ksger 2.x bin file. At quick look I have find one thing that is not working.
- It does not lower the temperature when it goes into the STBY mode.
Also some things that I liked in original firmware:
- When in SLEEP mode it would be nice to still see/display the temperature beside HOT!.
- I kinda liked the quick rotation of the encoder left to manually put it into the stby/sleep mode.
- Quick rotate it right to put it into boost mode.
- Press and rotate to select the tip.
- Also I liked the way the shake/button press was handled. When in STBY mode the shake can waken the iron but when in SLEEP mode the shake will not waken it but only button press. This way it will avoid accidently waken it when working on the bench and tilt it and burn something.
- For screensaver I am not sure but any info should not be static on oled display to prevent burn in. I know it will sound funny but original one has a moving Sleeping and displaying temperature at the same time.
The board I have flashed it was with original firmware HW: 2.1S; SW: 2.11
TNX
-
It seems you need some reading! Most of those features already exist.
You're right about the standby temps, a new bug that appeared after adding boost.
Fixed, I'll wait a bit before making another builds just un case more issues are found.
Screen saver is not needed since it lowers the display brightness to the minimum.
-
if i need "boost mode" i can just adjust pid so it will overshoot under heaby load :popcorn:
-
Please avoid the silly comments.... :palm:
-
I have 6 hours old build.
-
Please avoid the silly comments.... :palm:
genuine jbc stations literally do this.
-
Yes, but in a controlled manner, not with a such weird hack :-DD.
I removed the sleep screen. Now everything is normal, but the screen is dimmed as before.
-
Yes, but in a controlled manner, not with a such weird hack :-DD.
I removed the sleep screen.
if it work why not. there are tons of hacks everywhere
no dvd ? NOOOOOOO
-
New builds. Hopefully all issues are sorted now.
I'm updating the documentation to follow the current fw.
-
Hello,
First, many thanks to DavidAlfa, dreamcat4, floobydust and all other contributors to the custom firmware. Truly excellent work! I have a controller with a T12 iron happily running with your firmware since a few weeks.
I have a few questions about connecting JBC C245 cartridges to a v2.1S original version (green PCB) controller board. The C245 can be connected in two ways. Either 1) like the T12, with the sensor in series with the heater or 2) JBC 245-style with the heater and sensor separate, requiring some small hardware modifications.
- What are the pro's and con's of the two different connection methods?
- If connecting a C245 like a T12, should the T12 or C245 iron profile be used?
Thanks in advance!
-
I am trying to flash another KSGER 2.1 and it says that Can not connect to the target. Is it possible that the flash is defekt on this board? I have checked and there is connection with clock and data to the STM32 pins from the flashing port.
-
JBC 245-style with the heater and sensor separate, requiring some small hardware modifications.
this. even though tc in genuine jbc tips can withstand this power temp accuracy will suffer with oscilations and other awkward reading like with t12
-
Yes, but in a controlled manner, not with a such weird hack :-DD.
i suggest then much simpler and reliable turboboost implementation. in tip menu u select power % which add temp +offset. so it will automatically boost when heating big things.
-
I am trying to flash another KSGER 2.1 and it says that Can not connect to the target. Is it possible that the flash is defekt on this board? I have checked and there is connection with clock and data to the STM32 pins from the flashing port.
Because in stock fw trhe debugging pins are disabled. Connect nRST to the programmer.
Another way is to manually short the reset pin to gnd with the tweezers, click on erase, and release after 1/2 second. Though you'll need some tries.
-
TNX. I have inspected under the microscope and there was a cold joint out of factory. Now it works.
-
There's still something in the "Edit tips" menu. Created new DFLT and BC2 tips. Then got into BC3 to delete it. Result: last created tip (BC2) gets deleted instead.
-
Not happening here.
After factory reset, I created "2","3","4","5"... Deleting BC3(1st tip), deleted exactly that one.
Deleting any other tip also worked as it should.
Please describe the exact procedure to reproduce the issue.
Ensure you're using the latest, made few hours ago.
Since I've been doing multiple builds daily, it's a little confusing.
-
Not happening here.
After factory reset, I created "2","3","4","5"... Deleting BC3(1st tip), deleted exactly that one.
Deleting any other tip also worked as it should.
Please describe the exact procedure to reproduce the issue.
Ensure you're using the latest, made few hours ago.
Since I've been doing multiple builds daily, it's a little confusing.
Hello David,
Today I stumbled with the project, I have to say you are doing a great job.
I was wondering what is happening with the PID algorithm, are you having problems with it? I see that you pushed an old version, what's happening with the new version?
Thank you.
-
I think it was too sensitive, harder to adjust.
I also reverted to less agressive settings.
Now the defaults are 60-60-10-0.50
-
Thank you David for the new Boost Mode feature, I think you did a great job implementing this!
I would like to report a possible bug, I tested the latest firmware on ksger v1.5 (not tested yet on 2.x) and I cannot seem to switch temperature display from numeric to graph
Can anybody else reproduce this?
-
I have tested the newest firmware and STBY now works.
- I think that contrast in settings has no effect.
- And also about shake to wake. Maybe I am doing it wrong but what I would like to achieve is:
1. when it goes into the STBY mode that it is possible to wake it with shake (This works)
2. but when it goes into the Sleep mode it can only be waken with button press but not with Shake. (This does not because already a shake wakes him.)
-
You can enable or disable button and shake wake independently.
You might not notice an instant change in brightness, you have 255 steps! Set contrast to minimum, the screen should dim a lot.
In sleep/standby/boost modes and button wake enabled, the first click will set the normal mode instead changing the temperature display mode.
Will check these issues later. For now, test it thoroughly and ensure it's not your fault :D
-
Not happening here.
After factory reset, I created "2","3","4","5"... Deleting BC3(1st tip), deleted exactly that one.
Deleting any other tip also worked as it should.
Please describe the exact procedure to reproduce the issue.
Ensure you're using the latest, made few hours ago.
Since I've been doing multiple builds daily, it's a little confusing.
Update after writing this message: I can't see that boost feature. Clicking github link in your signature, I see last commit 7716267 6 hours ago. Then, in BOARDS/Quicko/STM32F103C8, I see a09f40c 8 hours ago, which is the one I'm using. So I does look like I'm not getting the last update. FWIW, I'm including the report for a09f40c.
(somewhere in the past)
Well, the exact procedure is almost as I said... using last commit a09f40c. It's true that after calibrating, I have been able to delete BC3 as expected. But, to be sure, I flashed it again. What I see now is, after creating a new tip, going to BC3 I got into the last tip created -still uncalibrated. So, created DFLT, just named, saved, selected BC3 (still in Edit Tips menu), clic... and got into DFLT settings. Cancel. Created BC2, just named, saved, select BC3, clic... got into BC2. Create D16, just name it, save, select BC3, gets you into D16.
Selecting any created tip in the Edit tip menu, gets me into the last created tip settings. BC3, DFLT, BC2... no matter, selecting any of these I got now into D16 settings.
After that, selected BC3, clic, got into D16 settings, delete. D16 gets deleted. Now selected BC3 again. Clic. This time I got into default settings with a blank name. Cancel. Same with DFLT and BC2, I get into default settings with blank name.
After that, in main screen, clic+rotate right, selected DFLT tip. Then, in Edit tips menu, again I always get into default setting with blank name, no matter which one i select.
So, again in main screen, click+rotate right, select BC2 tip. Calibration->Adjust. Save.. Edit tips. Still default settings with blank name.
Calibration -> Start. Back. Exit. Edit tips. Same again. Any tip I enter into, has default settings and a blank name. Included the calibrated one. But, If I get into any of these and delete it, is that tip the one that gets deleted.
Well, last time somehow I was able to get it working. Not this time.
-
Will check that later
-
I would like to report a possible bug, I tested the latest firmware on ksger v1.5 (not tested yet on 2.x) and I cannot seem to switch temperature display from numeric to graph
Can anybody else reproduce this?
Yes, I can verify that I can't seem to switch temperature display mode either. Also, the new PID values don't seem to be an improvement, especially for my one wild tip. But I expect that I can adjust the PID similar to what I had before.
-
That pid is for the average tip, not your wild ones :D.
It reduces aggressiveness, so it should help a bit with most tips.
Maybe you're running old PID settings? Current defaults are 60-60-10-0.50, and filter 2.
-
I got a ksger t12 v2.1 with a stm32f103rbt6. Im waiting for a stlink v2 clone to test the firmware.
-
I can confirm the temperature display mode bug. Fixed.
Couldn't reproduce other issues. Maybe some builds were not updated correctly as tatel's comment suggests.
New builds available, try them.
It's sleep time for me, more tomorrow!
Cuboy, that mcu will work fine with the current ksger v2 build.
Does anyone have original backups of ksger v1.5/v2/v3 or quicko F072?
-
I can confirm the temperature display mode bug. Fixed.
Couldn't reproduce other issues. Maybe some builds were not updated correctly as tatel's comment suggests.
New builds available, try them.
It's sleep time for me, more tomorrow!
Cuboy, that mcu will work fine with the current ksger v2 build.
Does anyone have original backups of ksger v1.5/v2/v3 or quicko F072?
Any problems i will report back.
Anyway today i was searching throught the code and saw that you reverted the pid algorithm to an old one, why is that? Doesn't the "new" algorithm work properly?
I'm willing to spend time debugging and working on it.
-
Downloaded commit f3b505b. Now I see boost settings. Weird behaviour in Edit Tips menu is gone. I created new tips, then deleted BC3, no problem 8). Thank you, man
-
Anybody else with a 1.5 board have a similar issue as me, a stuck pixel/row on the LCD
It could be a faulty LCD screen, it could have always been like this and I am just noticing.
Edit: Also would it be possible to enable Shake wake from Standby but not Sleeping?
I like to start my iron sleeping, but any light movement it wakes, I would like to maintain the ability to have it wake from standby but if its sleeping I would like to have to press button.
-
That pid is for the average tip, not your wild ones :D.
It reduces aggressiveness, so it should help a bit with most tips.
Maybe you're running old PID settings? Current defaults are 60-60-10-0.50, and filter 2.
I'm running the new settings. I did a full reset after flashing. FYI.
-
I can confirm the temperature display mode bug. Fixed.
Couldn't reproduce other issues. Maybe some builds were not updated correctly as tatel's comment suggests.
New builds available, try them.
It's sleep time for me, more tomorrow!
Cuboy, that mcu will work fine with the current ksger v2 build.
Does anyone have original backups of ksger v1.5/v2/v3 or quicko F072?
Any problems i will report back.
Anyway today i was searching throught the code and saw that you reverted the pid algorithm to an old one, why is that? Doesn't the "new" algorithm work properly?
I'm willing to spend time debugging and working on it.
Hi. I have tested backups and flashing KSGER v2.1S and the one from HANDSKIT. The HANDSKIT does not asks for codes after flashing back to original but KSGER does.
Here is the keygen for codes that i have tested with 2.1S
http://t12.omegahg.com/keygen.htm (http://t12.omegahg.com/keygen.htm)
The files I have used are:
- T12_HW21S_Encryption-SH1106 _SW211.hex (version HW-2.1S; SW-2.11; SH1106)
- T12_HW21S_Encryption-SH1106_SW212.hex (version HW-2.1S; SW-2.12; SH1106)
- T12_v.2.1S_OLED1.3_enc_mod_SW211.hex (version HW-2.1S; SW-2.11; SH1106; encoder moves in opposite direction)
- T12_HW21S_Encryption-SSD1306_SW211.hex (version HW-2.1S; SW-2.11; SSD1306)
Oled Info:
SSD1306 - 0.96 inch
SH1106 - 1.3 inch
I have also attached short info how to flash the firmware.
Since google drive for firmwares is dead, I have uploaded also original copy of all the files there. From the name you should be able to identify the version.
-
I just flashed the 209KB T12_HW21S_Encryption-SH1106_SW212.hex file successfully, if you convert this to bin its 74.1KB.
So I guess the 64KB limit is nothing to worry about, maybe these boards can handle larger files :-//
Edit: This is not the first time I flashed a file larger than 64KB on a STM32 that said it was 64KB in size, when I converted my blue pill stm32 board to a blackmagic debugger it was two files with combined size over 100KB
-
all stm32f10x are 128kb based
-
Will add separate options for wake sources:
- Button Sleep wake
- Button Standby wake
- Shake Sleep wake
- Shake Standby wake
It's the only way to work in all combinations.
-
Anybody else with a 1.5 board have a similar issue as me, a stuck pixel/row on the LCD
It could be a faulty LCD screen, it could have always been like this and I am just noticing.
I'll be sure to get back to you in the unlikely event the same issue appears on my v1.5 next time I update (tonight or tomorrow). It looks like hardware failure though.
Edit: Updated to latest build, it's not on the software side; your screen is faulty/failing.
-
Anybody else with a 1.5 board have a similar issue as me, a stuck pixel/row on the LCD
It could be a faulty LCD screen, it could have always been like this and I am just noticing.
I'll be sure to get back to you in the unlikely event the same issue appears on my v1.5 next time I update (tonight or tomorrow). It looks like hardware failure though.
Also your offset is wrong
Added the extra wake options and made new builds.
It's a bit experimental: I unlocked 128KB for all devices.
Some clones truly have 64KB, as well as older 10x.
-
Not sure unlocking the full 128KB is a good idea. I mean, they may have 128KB physically but they also may be binned at the factory so that rejects with damaged flash end up in lower tiers with the damaged part disabled.
Just my 2 cents, I have no proof of that in one way or the other.
-
We will see. KSGER already does this from factory and nobody is having issues.
This allows the firmware to keep growing, also enabling O2 optimization, which is way faster than optimization for size.
I can always revert it if causing trouble :-+.
The programmer checks the written flash, and the firmware checksums the settings before and after writing.
Any flash issue will be detected instantly, so no worries.
Updates:
- Standby timer can be set to 0, effectively disabling it. In that case the station will switch from run to sleep state, skipping standby mode.
- Sleep timer cannot be disabled, or it would run forever.
- Any input (Shake or encoder) will "wake" the screen up when dimmed, even being disabled.
- When the screen is dimmed, the first encoder action will only wake the screen, blocking any action. The next one will do what it's supposed to do.
- Lastly, I realised there was a safety flaw. It's not good that the screen dims if the tip is hot. So the screen dimming will only happen when the tip is <100ºC
-
oh yeah, greetings in 128kb club buddy :popcorn:
also they still are limited in ram amount.
p.s. plz note last standing 64kb rom in builds section, so it can be reversed for those who had failed.
-
No worries, if it fails, I'll set 64KB again. I won't be messing around with 2 different firmware versions for 64 and 128KB mcus. Too much work.
Neither I'm going to abandon 64KB devices.
The ram is ok, I can make really huge screens even in 10KB devices. For example, I could make system settings at least 2x larger.
Found litle bugs, fixed, enhanced some features.
From now same-day builds will add a letter at the end to differentiate them.
Also I will add it to the commit message.
Ex. I've just updated them, current version "2021-08-02a".
I think I've finished for today. Test it thoroughly!
Specially, the tip editing menu, to find out if Tatel's issue was an older build or there's still something wrong.
Oh, I almost forgot. There's a hidden feature somewhere, that does something, in some mode, and can be enabled somehow (doing something in some way) ... maybe you'll need to read some code in some file to find it out :D.
-
Hi all!
Did somebody had issues with ambient temperature?
My HW KSGER v3.x fully identical with this one:
https://raw.githubusercontent.com/deividAlfa/stm32_soldering_iron_controller/master/BOARDS/KSGER/%5Bv3%5D/Schematic/STM32_T12_oled_v3.0.jpg
and MCU STM32F102C8T6. I flashed binary 2021/08/01
Real room temperature is 26~27C, but measurment temp is minus 15~14C.
Diference between seting temp and temp which measured with FS100 clone approx. 50 C
I can't found solution in this forum. Sorry for my english :-\
-
Post pictures of the screen! :-+
I didn't understand too well. Is the reading 13ºC higher, or 13ºC lower that room temperature?
The normal behaviour is to be hotter than room temperature (Usually 35-40ºC)
-
I didn't understand too well. Is the reading 13ºC higher, or 13ºC lower that room temperature?
Not lower, really displayed MINUS -15~14ºC
[attach=1]
-
Then the handle NTC resistor is different. The current NTC look-up table is for 10K NTC.
But I know there are stations using 100K NTC.
However it's really weird that nobody reported this issue before.
I will add a new option to select the NTC type! :-+
-
I will add a new option to select the NTC type!
Thank you David! I will check it with another handle tomorrow.
-
Looks like the setting to disable button standby doesn't work.
I have the following settings:
- btn slp ON
- btn stby OFF
but when pressing encoder+left it will still cycle through standby then sleep.
V1.5 on today's build.
On a more general note, I believe the previous PID values or maybe the algorithm were better (I used a 3 days old build before). I just can't calibrate some tips properly, the result is always off by +30~+50°C even though calibration values come out very similar when I retry. Admittedly, I only tried with 2 tips and the second one isn't that bad (within 10~15°).
-
Then the handle NTC resistor is different. The current NTC look-up table is for 10K NTC.
But I know there are stations using 100K NTC.
I can't wait tomorrow and checked it. You are absolutelly right!
One handle (yellow-blu) have right amb.temp, another ("Quecoo") have wrong.
And yellow-blu NTC=7.5K. "Quicoo" have 77K
-
Looks like the setting to disable button standby doesn't work.
I have the following settings:
- btn slp ON
- btn stby OFF
but when pressing encoder+left it will still cycle through standby then sleep.
V1.5 on today's build.
On a more general note, I believe the previous PID values or maybe the algorithm were better (I used a 3 days old build before). I just can't calibrate some tips properly, the result is always off by +30~+50°C even though calibration values come out very similar when I retry. Admittedly, I only tried with 2 tips and the second one isn't that bad (within 10~15°).
Button sleep / standby options disable button wake, doesn't affect manual mode. That's how its supposed to be and won't be changed.
-
Then the handle NTC resistor is different. The current NTC look-up table is for 10K NTC.
But I know there are stations using 100K NTC.
I can't wait tomorrow and checked it. You are absolutelly right!
One handle (yellow-blu) have right amb.temp, another ("Quecoo") have wrong.
And yellow-blu NTC=7.5K. "Quicoo" have 77K
yup the handle i have from quicko is the same one you have and its the same way. i just never bothered to change it yet. but the same exact handle in the ksger bramd (with the ksger logo) works like normal for me with the ksger stations.
-
I switched again to the new pid algorithm again. No changes, same thing.
After tweaking the filter values, it seems to be a lot better. It takes a lot of trial and error.
Filtering too much causes these slow oscillations, but insufficient filtering is much worse, because the nasty spikes will pass to the pid.
I switched the NTC algorithm to the float based. Takes lot of processing power, but it's perfectly capable, accuracy will be much better.
Added the a new submenu inside SYSTEM. Allows to fully configure the NTC.
- Pull-up/down resistor
- Pull resistor value
- NTC resistor value
- NTC Beta value
New builds coming!
-
Looks like the setting to disable button standby doesn't work.
I have the following settings:
- btn slp ON
- btn stby OFF
but when pressing encoder+left it will still cycle through standby then sleep.
V1.5 on today's build.
On a more general note, I believe the previous PID values or maybe the algorithm were better (I used a 3 days old build before). I just can't calibrate some tips properly, the result is always off by +30~+50°C even though calibration values come out very similar when I retry. Admittedly, I only tried with 2 tips and the second one isn't that bad (within 10~15°).
Button sleep / standby options disable button wake, doesn't affect manual mode. That's how its supposed to be and won't be changed.
Oh, that's a "press to wake from sleep/standby" option then. I thought it was the "press to sleep/standby" option. My bad, thanks for clarifying.
-
That's when you don't want the encoder to exit sleep or standby modes. Simple as that.
Same with the Shake input. If you disable both, the station will never wake up! Well, unless you trigger boost mode...
The main screen code is very sensitive, a little change here can affect something elsewhere...
All the recent changes introduced a lot of little bugs that took while to catch and fix. None were worse than simple cosmetic issues.
Builds updated.
No problem, but please, I wrote the manual for something, so :D:
(https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQsbLPURRMbC3KO5sG3f7N9SljYzFhF-3wrxA&usqp=CAU)
-
If you disable both the station will never wake up!
One way to avoid people making this n00b setting mistake, instead of:
Btn Slp = ON/OFF
Btn Stby = ON/OFF
Shake Slp = ON/OFF
Shake Stby = ON/OFFConsolidate the menus into two like so
Btn Wake = BOTH/SLP/STBY
Shake Wake = BOTH/SLP/STBYThis reduces the menu by 2 items and it will prevent a scenario that would disable wake all together
P.S. you could also maybe use "ALL" or "FULL" instead of "BOTH" (to distinguish between just one option or both options)
Edit: if you did want keep the ability of disabling wake you could add "NONE" to Wake Mode = STAND/SHAKE/NONE and/or to the above menus NONE/BOTH/SLP/STBY
Edit2: Default would be BOTH of course, if you wanted to disable Shake Wake from Sleep you change Shake Wake = STBY and it will only shake wake when in Standby and not Sleeping
-
Yeah these things can be easily polished out.
-
sorry station is currently at 24/7 load so i cant test new builds :'(
-
Is it possible to implement on the first screen an option to select eather voltage input (left up) or the set temp info.
-
What? Why adjust the voltage?
-
No no :) Instead of displaying voltage it would show SET Temperature.
Because you do not know to which temperature will the iron rise since you can not see set temperature only if you rotate the knob.
-
I don't think it's necessary?
The station stays very close to the setpoint, so it's very obvious.
Edit ok. Did something.
In run mode, the setpoint is displayed in the place where for other modes, the labels "sleep", "standby", "boost" are shown.
Moved the shake activity icon to the botom and resized the power bar.
Also updated the wake options for shake and button inputs: Off, Sleep only, Standby only, All.
Modified the system settings structure, because due the structure padding, sometimes it didn't detect changes when adding/removing variables, bypassing the checksum detection and causing weird settings to be applied.
New builds.
The tip regulation is working really fine for me, the only change I made was the calibration.
https://www.youtube.com/watch?v=1m3bHZnKgvg (https://www.youtube.com/watch?v=1m3bHZnKgvg)
Not yet in the latest builds, also added a smooth brightness ramp at boot.
I'm one of these persons who care about the small things :D
So nobody found the hidden easter egg yet?
-
Your temperatures seem very well behaved. I flashed 2021-08-03b and I'm having a very different experience. Of course, after flashing I did a full reset. I've attached some pictures of the temperature graph of each of my tips. They are in order BC2, D24, Ku, C4, and my one wild tip ILS. I did notice that after changing tips the temperature graph would start going really fast. I could clear that condition by going into the menu and exiting. After that the graph was the normal speed. I haven't tried to modify the PID values from the reset. Do these pictures suggest how I can get to your very well behaved temperatures?
-
Try the 03c I'll upload in a while.
No idea about your issue. I suspect something related to noise but I can only guess.
Will think about it.
-
Very nice with set temp. TNX. I am sure I will find some additional things ;)
-
This is the 1% of the code that takes 90% of the time!
The internals are mostly rock solid, most issues are in the interface, due the complex user interaction.
Updates:
- Tip selection screen deleted. The label in the corner is highlighted when selecting tips.
- Only remove the tip temperature widget when an error is active. Setpoint and tip selection can be used normally.
- Remove internal lower temperature limitation, now it can work down to ambient temperature (For standby adjustment)
- Graph bug is fixed (it was just the plot drawing timer being erased by the the error screen).
- Only trigger boost mode if it's clicked within the 1st second, ignore afterwards.
- In graph display mode, to allow watching the system response when changing the setpoint, the temperature widget is updated in the background.
There's a drawback: Boost can only be triggered in numeric display mode.
- And lots of debugging to fix small details and undefined behaviors that could cause display corruption in very specific events.
New builds uploaded
-
Do these pictures suggest how I can get to your very well behaved temperatures?
Ignoring the spikes, what are the real temps in the tip?
Must he a hardware-related issue. I have 10 tips of all shapes, and they all work perfect with the same pid.
-
Ignoring the spikes, what are the real temps in the tip?
Must he a hardware-related issue. I have 10 tips of all shapes, and they all work perfect with the same pid.
I haven't tried the new firmware yet, but I worked with the currently installed version some. It seems to maintain about a four degree range. That's for the two tips that I tried. I'll give the new version a try.
Edit: I tried the new firmware. It seems to act in a similar manner. The actual temperature fluctuates in what seems to be a four degree range. I'll keep working with it.
-
Your temperatures seem very well behaved. I flashed 2021-08-03b and I'm having a very different experience. Of course, after flashing I did a full reset. I've attached some pictures of the temperature graph of each of my tips. They are in order BC2, D24, Ku, C4, and my one wild tip ILS. I did notice that after changing tips the temperature graph would start going really fast. I could clear that condition by going into the menu and exiting. After that the graph was the normal speed. I haven't tried to modify the PID values from the reset. Do these pictures suggest how I can get to your very well behaved temperatures?
thats just grass grown in your display. time to trim it! :-DD
obviously time to change opamp
-
I found what it seems the bug reported by mastershake. Setting 400ºC the tip barely melted the solder.
Happened only when deleting the tip currently being used by the system.
The current tip was correctly changed, but the pointer used by the system was not being updated. So it was probably reading garbage.
Maybe that's what related to what tatel mentioned.
However this bug would not cause any issue with other tip being deleted. Editing or copying was unaffected.
Only affected the PID/adc/temperature conversion, as they read using that pointer.
Restarting the system would load the new tip and solve the issue.
Made new builds to solve this, I really couldn't live knowing that :D.
(2021-08-04)
-
thats just grass grown in your display. time to trim it! :-DD
obviously time to change opamp
Maybe, I'm not opposed to it. I'd like to play around further first, though.
-
I found what it seems the bug reported by mastershake. Setting 400ºC the tip barely melted the solder.
Happened only when deleting the tip currently being used by the system.
The current tip was correctly changed, but the pointer used by the system was not being updated. So it was probably reading garbage.
Maybe that's what related to what tatel mentioned.
However this bug would not cause any issue with other tip being deleted. Editing or copying was unaffected.
Only affected the PID/adc/temperature conversion, as they read using that pointer.
Restarting the system would load the new tip and solve the issue.
Made new builds to solve this, I really couldn't live knowing that :D.
(2021-08-04)
same was when switching global profile (t12-210-245) in settings. i thought it was very obvious to restart system
-
I know, that was a different bug, the profile is not applied instantly but when exiting the screen, and since I reworked the code recently, that part was lost and the profile was never changed.
It's already fixed in the current build.
Anyways, you should have reported the problem when you detected it, not now!
Let's see if we get more feedback from Ksger users. I need to know if it's only Stephen or there's a problem with these stations.
Stephen, for now try like lowering the tip power to 50w and disabling active detection.
Actually the only bug I'm aware of is the setpoint being locked/unlocked if you long click it. It's almost a feature :D
-
Hi David!
Could you please explain what this parameters mean? (except NTC resistor value)
Allows to fully configure the NTC.
- Pull-up/down resistor
- Pull resistor value
- NTC resistor value
- NTC Beta value
I was checked new build in deep night. With standart handle all working fine, but with Quicoo handle I've got a another problem: station can't hold setting temp (see/attachment pict.) Don't look at ambient temp, I was make photo after full reset. When I was set NTC res. value at 77K amb.temp looked like thru 26...27°C (real temp~29°C) and iron temp was unstable to.
And coomon question: How original FW determine which NTC in handle? I haven't any inconvenience with handles change
-
Put 100K in the menu, not 77. I didn't knew that original fw automatically switched between them.
Will look if I can make the same.
Anyways, that oscillation is related to the pid or adc filtering. Tuning the system is a hard part when I can't do it myself.
I know ksger v2.1 is has stability issues even with original fw. I need more feedback from users to find a pattern.
-
awesome you found that yes thats pretty much what i had happening. i will flash the new build and have her test it again for me tomm. i would try it tonight but today was a rough day with the eye they took out the cataract in the previous surgery and removed the patch today and lets say its def not nearly what i had hoped it would be. apparently the macula took some damage from the detachment and the radiation and there is no left or upper periphery left at all just grey there. only central and thats not really great either. everything is wavy and warped and its a very limited range of vision from say 15" to maybe 10ft MAX thats pushing it, after that its blur. they claim its better then they hoped for given how large the tumor was but it still sucks. granted the tumor is def dead for sure they say. not sure how this will hinder my work i do and things like smd stuff now. ill have to try to get used to a camera on a bigger screen then using the scope all the time maybe, def not going to be able to do as much field work though. just not what they told me going in of course they promised the world and def were not able to deliver. next they move the muscles to try to fix the double vision they caused when they did the radiation :palm:
sorry rant over back to the topic at hand now had to vent somewhere before it ate me up.
-
I know how it feels when you get hit by something like that. It takes a loooot of time to accept the situation and get used to it.
Keep it up! We're tough animals :-+
I'm making an extra-advanced filtering menu to allow adjusting every internal filter parameter.
I'll put a description in the operation guide but don't expect me spend the day explaining it! :-DD
So don't flash the latest yet. Skip to the new I'm going to upload in a while.
Also added NTC auto detection option. This is highly experimental, so it's disabled by default for good reasons.
First, it's impossible to guess the NTC value if you don't know its temperature neither it's value, it's a dead loop.
So you must choose two different NTC values, and the system will probe them.
The lower value will tested first. If the temperature result is negative, it will assume the NTC is wrong, and switch to the higher value.
- The default values are 10K and 100K.
- Each resistor have its own beta value.
- If your handle is below 0ºC it will use the higher value, causing a big negative offset (The temperature will be lower than the setpoint).
- With default 10/100K values, the detection will fail at ~60ºC, because the 100K NTC resistance at that temperature would be the same than the 10K NTC at 0ºC.
In that case the higher value will be used, giving a huge positive offset (The temperature will be higher than the setpoint)
- The NTC is only probed after removing and putting back the handle (or any other error is detected). It's not checked while running, as it's impossible to replace the NTC without removing the handle and triggering an error.
The option is there, for 99% of the time it will work nicely. Just remember the limitations, nothing can be done for that.
It's mainly made only for 10K and 100K values. I don't recommend using this method, it's better have all handles with the same NTC type!
New builds updated. I know there's a copy&paste a bug in the NTC Auto detect options where the beta values are shown as KOhms. Will work anyway.
It's fixed in the code, but I can' loose my time that way, building for every single change!
-
I will explain how the advanced filtering menu works.
First, the new measurement is compared with filtered average and the difference extracted ([Delta]).
There are 4 filter modes:
- [Delta] < [Threshold start]: Normal filter coefficient is used (That one set in Iron settings screen). Usually the highest coefficient of all, to filter out the low amplitude noise.
- [Threshold start] < [Delta] < [Threshold end]: Threshold filter coefficient is used, usually lower, to provide faster response for the PID.
- [Threshold end] < [Delta] < [Reset limit]: Count the spikes. If within limits, use spike filter coefficient to avoid sending noise to the PID. Over that, use reset filter coefficient.
- [Delta] > [Reset limit]: Reset filter factor is used. Usually very low or none to reset the filter or provide very fast response (Used to detect the iron tip fast).
This parameters affect a lot the filter response. Too low thresholds will reduce filtering (crazy spikes everywhere), and too high will reduce response (Slow oscillation), also wrong reset and spike settings will cause all kind of issues.
If no filter is used in the iron settings, the menu will be disabled and simple average used (very noisy).
And yes, I had to figure all that by myself. There'are a LOT of testing hours behind 4 numbers. Think twice when you suggest random things like if it was my first day at work :D
-
why not use cpu temp as option? its enough for operation in range. stock ksger have this option for "empty" handles. quicko based on stc chips do this either.
-
So, I've been testing 2021-08-04, which I flashed yesterday. I'll try 2021-08-04b shortly. Those wild swings that I had before seem be much less now. For my four similar tips the temperature seems to vary about 4 or 5 above and below the set temperature. The measured temperature varies in a 4 degree range. My one wild tip varies about 8 or 9 above and below the set temperature. But the measured temperature still varies in about a 4 or 5 degree range. I tried setting the tip power to 50w and disabling active detection. That didn't seem to change anything.
-
why not use cpu temp as option? its enough for operation in range. stock ksger have this option for "empty" handles. quicko based on stc chips do this either.
Is it a good idea to suppose that the NTC temp is the CPU temp (As it is fairly accurate)? If so, you might be able to get a ntc resistance value (Which from what I see, is just a bunch of equations).
Also, I'm backseat engineering here.
-
Is it a good idea to suppose that the NTC temp is the CPU temp (As it is fairly accurate)?
ppl overrate ntc accuracy. its just needed to know enviroment temp to bind tc voltage to real life C/F numbers. no real trouble with -+10c bias
-
David, I updated FW to 2021-08.04b and just inserted my old PIDs and all Cal values. I have Ksger v2.1s (written on PCB) but I believe my real PCB version ahould be v2.0.
Everything is the same as before (I think my last version was 7.7.) and is working great!
I set pretty much everything as before (100ms/1ms/1x - or even 2x / filter set to 2) other things are default one.
I saw a couple of your new things (boost, set temp, PID debug,...) and I like them a lot.
I didn't have time to check any new tests but I did a quick test by adding new tips, set it to first one and then delete first selected tip from the tip menu. I didn't have any problems. Everything worked. I believe this is something you needed to be tested? Or did I read and forget what you really wanted to be tested on the Ksger boards?
EDIT: Did you wanted to know if Ksger board has oscillation? No, it is dependant of period, delay, PWM multiplier and PID settings on mine if I remember correctly.
EDIT 2: And I forgot to tell you that I really like that I can change tip type and temperature even without inserted tip ;) :-+
Boost is working :-+
EDIT 3: I also forgot about encoding. Thank you, it works :-+
-
A couple thing I noticed with my v1.5:
The "GUI time" setting seams to be broken in the latest version.
The value decreases by turning counter-clockwise as expected, but turning right does nothing. Other settings in the same menu work as expected.
---------------
I'm unsure if it's by design or a bug but the option to "reset all settings" does not apply to settings in the Iron menu. I does apply to the system menu.
-
Model: KSGER STM32 HW: v3.x
Tip: T12-BC3
Handle Quecoo T12-M8 with 100K NTC (NTC Detect OFF in NTC menu and Resistance set to 100K)
My Calibration settings
Cal250 1708
Cal350 2316
Cal450 3341
build: 2021-08--04b
Differences between set.temp and measurement ~5ºC lower
-
Feature request:
I don't know if this has been requested or if its possible to add a feature like the 3.1s KSGER firmware, where when you turn the knob slow it will adjust temperature in by one degree increment and fast at ten degree (or custom) increments?
https://youtu.be/w0nZCK7B-0U?t=1371
Also when in sub-menu, could you make long press go back one instead of exit. If you do want to totally exit (instead of letting go, then long pressing again,) maybe just keep pressed (really long press) and then it will exit?
Just some personal requests, please do not make these a priority vs other stuff you have on the table!
-
1°C steps?
I could also add 0.1°C steps, so you can safely grow bacteria in your laboratory.
/Ironic off
C'mon, really? :-DD
Also it would mess up the boost mode badly.
Keep it simple! Nobody needs 1°C precision.
How in the Earth would you need specifically 237°C?
Furthermore, the station itself is unable to provide such accuracy. There's a small error in the whole working range.
You might set 250 and get 252. Set 350 and get 349. Set 400 and get 401.
So just why?
The "GUI time" setting seams to be broken in the latest version.
I'm unsure if it's by design or a bug but the option to "reset all settings" does not apply to settings in the Iron menu. I does apply to the system menu.
Maybe it's a little confusing.
Settings=System settings, but not iron Settings.
Iron Settings belongs to the tip profile.
[profile] [profiles] [all] will reset the profile (tips and iron).
[Profile]=current selected profile, [profiles]=all profiles.
[settings] [all] will reset system settings.
Definitely the Gui time option was bugged. Fixed.
Handle Quecoo T12-M8 with 100K NTC (NTC Detect OFF in NTC menu and Resistance set to 100K)
Does the autodetect work when switching between the 10K/100K handles?
-
One think that i have noticed is that when I flash original firmware from KSGER the display is brighter than on this one. Also contrast seems to not do anything after like 150. It does not dim proportional.
-
illiac4:
Try push and rotate to change (it will change by +-10) and see if it is really like that because on mine it is working ok. I also have Ksger.
-
That's a display controller thing, you have 0-255 adjustment and the display controller does whatever with it.
Will make 20 step again.
Also these displays lose some brightness when you turn on a lot of pixels.
-
Where can I find hot tweezers compatible with KSGER 3.1S plug, which is gx16-8 male?
-
I saw someone made them. https://www.youtube.com/watch?v=p_sx5a6ueeg (https://www.youtube.com/watch?v=p_sx5a6ueeg)
-
to make twezeers u actually only need to select 1 pair by resistance.
-
Took the debug menu back to life and completely reworked it.
Can be enabled in System options. New option will appear in main settings menu.
Click to switch between debug and debug pid screens, long click to exit.
Theres's a setpoint adjustment, so you can see everything in real time as you change the temps.
I forgot to add auto reset this time, the settings structure changed, it might detect wrong checksum, but if it doesn't, reset it to factory.
-
I got some new thermocouples and had some spare time, so here we go:
KSGER 2.1 Green board:
DL32: 1733/2466/3323
D4: 1753/2531/3396
D24: 1797/2567/3546~
K: 1705/2367/3065
KSGER 2.1 Blue board:
DL32: 1667/2382/3155
D4: 1693/2423/3241
D24: 1714/2454/3270
K: 1597/2241/2895
KSGER 3.1 Black "OLED 3.1" board:
DL32: 1975/2668/3428
D4: 1985/2683/3442
D24: 1977/2690/3467
K: 1908/2548/3189
KSGER 3.1 Black unmarked board:
D24: 1727/2426/3181
I made the huge leap from "v1.10-fix" to "210804b". Many great improvements! The grinning screensaver was...yeah :)
-
You found it! :clap:
-
This is with the latest firmware 2021-08-05. After a full reset, I performed a quick calibration.
Model: Quicko STM32/CKS T12
Tip: T12-BC2
Calibration > Settings >
ADC Value
Cal. Step 250°C 1050
Cal. Step 350°C 1500
Cal. Step 450°C 1900
Calibration > Start
Temperature ADC Value
Cal250 252°C 1193
Cal350 353°C 1640
Cal450 443°C 2077
Then I tested how controlled the tips were. I noticed that at 180°C, the temperature was very well controlled and the temperature graph was quite smooth. Then as I increased the set point at about 250°C, some variation started to come in. At 320°C where I do most of my testing, the variation seemed to be where it was going to be.
Here's my BC2 tip, which seems to be my most stable.
(http://[attach=1])
Here's my D24.
(http://[attach=2])
Here's my KU.
(http://[attach=3])
Here's my C4.
(http://[attach=4])
And finally here's my ILS, my most wild tip.
(http://[attach=5])
Then I started changing some of the PID values. I discovered that I could decrease the amplitude of the variations by setting Kd to 50. Here's the result.
(http://[attach=6])
The actual temperature variation seems to be within a four degree range. It may not be as perfect as David's, but I'm sure it's quite usable.
Edit: I tried to get the images in line in the post, but apparently I didn't get the trick to that. They are in the correct order, though.
-
welp, ill definitely place swd port on back of my next stations case. :-DD
found some bugs.
1) tip detection delay - can be only swithced with press+rotate until 900ms and lowered as usual after. also can finally get 1000ms detection now
2) buttons wake settings affect stand mode too - before i can preselect temp whil handle in stand, now it will awake iron from standby state if set in shake wake settings. and to sleep back i have to lift-land iron.
otherwise looks cool. also got new china jbc compatible stand, now stand mode works as intended :popcorn:
-
welp, ill definitely place swd port on back of my next stations case. :-DD
found some bugs.
1) tip detection delay - can be only swithced with press+rotate until 900ms and lowered as usual after. also can finally get 1000ms detection now
2) buttons wake settings affect stand mode too - before i can preselect temp whil handle in stand, now it will awake iron from standby state if set in shake wake settings. and to sleep back i have to lift-land iron.
otherwise looks cool. also got new china jbc compatible stand, now stand mode works as intended :popcorn:
How does the C245 handle and tips compare to the T12 using the KSGR station and David's firmware?
-
@wickated
Do you have a link to the stand?
-
How does the C245 handle and tips compare to the T12 using the KSGR station and David's firmware?
overwhelming
-
@wickated
Do you have a link to the stand?
https://www.aliexpress.com/item/4000270557037.html (https://www.aliexpress.com/item/4000270557037.html)
dont forget that it require rewiring to work with genuine jbc handles.
-
Yes, I rised the detection limit to 1000mS.
Before, the label was too big and would overlap.
Confirmed these bugs, will be fixed :-+
Stephen, your plots look really noisy, also the waveforms are quite strange.
Usually you'll get a sine-like waveform when filtering is too heavy.
But you get a double oscillation in the highs and in the lows.
Really strange.
Anyways, I'll repeat what happens when you blindly use it: It might be doing worse in the original fw and you won't notice!
Time me to plug the scope and see what the hell is going on.
Any other Ksger v2.1 users getting these weird oscillations no matter what?
1 minute of silence for my deceased D52 tip.
I got a hard fault while making the debug menu, the debugger will stop without you noticing and... :'(
Btw, data trace is the most useful feature ever. Had something writing out of bounds, affecting some widget data. Ran the data trace setting the affected variable, and Bang! Variable changed at line 552.
Unitialized data writing to random address!
Really, are these extremely slim tps like the ILS useful gor anything? Maybe for soldering a 0402 pad..
-
Any other Ksger v2.1 users getting these weird oscillations no matter what?
usually cuz of faulty fake opamp
Really, are these extremely slim tps like the ILS useful gor anything? Maybe for soldering a 0402 pad..
nope. absolutely useless.
-
Maybe for soldering a lifted bga pad. I've had to do that few times when worked on that. Scratch the 1st pcb layer until you get to the via and solder an extremely fine wire.
That's the only application coming to my mind. Definitely you're not going anywhere with a D32 tip :-DD.
Fixed these little bugs and made new builds.
The widget issues are caused by some small changes I made recently.
For instance, I save the iron delay as time/100. ex. 1=100mS. Same with other settings that go in 100mS steps.
It saves some space, but I forgot to adjust the widget :D.
Also added a check to the setpoint widget, so it only triggers boost mode when the station is in run mode. So if you're in sleep or standby, clicking won't do anything.
This is the polishing state already!
-
@wickated
Do you have a link to the stand?
https://www.aliexpress.com/item/4000270557037.html (https://www.aliexpress.com/item/4000270557037.html)
dont forget that it require rewiring to work with genuine jbc handles.
How big a PSU board do need to drive those tips?
I think the one in the KSGR stations is 24v5A. So an upgraded PSU will be needed for those tips I think.
-
Please, can you add Tetris next? :-DD
-
Snake better? :-/O
-
Please, can you add Tetris next? :-DD
Snake better? :-/O
On which drugs are you two? :-//
/joke off ;)
I have no oscillations but I still don't know if I have Ksger v2.0 or v2.1. It say v2.1s but I have linear voltage regulator on the board and not a switch one.
Bought it here: https://www.aliexpress.com/item/32844179319.html (https://www.aliexpress.com/item/32844179319.html)
It is normal version.
-
Bought it here: https://www.aliexpress.com/item/32844179319.html (https://www.aliexpress.com/item/32844179319.html)
It is normal version.
and you should have bought GX version like i did :-DD
-
2.0/2.1 whatever. There only 3 real versions.
If the fw works nicely with 2.0 but
reads noise with a 2.1, it's either a design problem or a defective controller.
-
Wickated: I already owned the same version for a couple of years and didn't have any problems so I bought the same. I would buy the same if I had to ;)
David: what if some pcbs don't like the same settings like other pcbs? Keep in mind about your 200/20 and my 100/1. Wickated is using T245 so he is out :-DD
-
achao, everything you need to know is here: https://github.com/deividAlfa/stm32_soldering_iron_controller (https://github.com/deividAlfa/stm32_soldering_iron_controller)
-
I don't know... I'm really tired about that, even I could say I don't care anymore.
The fw is there, it's time for some Ksger owner to play with it, check the signals, voltage ripple, noise sources, try replacing the op amp...
-
Wickated: I already owned the same version for a couple of years and didn't have any problems so I bought the same.
gx is at least equipped with 8551 opamp instead of noname fake sheet.
-
The fw is there, it's time for some Ksger owner to play with it, check the signals, voltage ripple, noise sources, try replacing the op amp...
sorry i dont have affordale quality oscil yet, but u see, i dont see trouble in reverse rotating encoder, i can just swap wires without complains. i dont complain for strange t12 spikes anymore, cuz i can just swap to 245 and be happy with amazing firmware and u see, i dont have any strange behaviour with 245 tips which can be seen with just bare eyes and ears (my psu make enough acoustic noise). u did enough work when tried to enable dma for i2c display module but it was found that factory screen module use different display controllers that dont support any changes (i guess yours had ssd1306 or smth), but u gave a try. thats pretty enough.
im using ksger board cuz i dont like pcb design of qicko one and also that they dont sell controllers alone, only full kits
p.s. have to upgrade to newer build once again, got some bugs with sleep stand state. i know u dont have stand, so i dont complain there are less options for stand users than shaker users
p.p.s rechecked, all seems ok (got bug that rising handle went from slp to stby only and not work mode), now fixed and i can set temp while handle in stand. also thanks for up to 2s tip detection time, i have now +1second to swap tip with bare hands :-+
p.p.s. to everyone - all that ali stuff is just diy, piece of pcb that require lot of work to make it work good. chinese fw just draw digits like if its all ok, but u have to change schematics and components to make it working for real. so for now i only have display, quartz, stm and some passive smd left from factory state, but thats still ksger 2.1.
-
Please, just tell what's currently wrong, listing old bugs is simply confusing.
I think you didn't understood correctly.
There're a lot of Ksger models, very similar ones.
If model A works, but model B, using the same op-amp circuitry and same fw settings, reads noise, it's something wrong with the circuit itself, and I can't do anything about it.
In that cases the owner will need to find the source of the problem. Or live with it, because It will usually work just fine.
It's not that I'm not willing to help. But I can't do anything.
The firmware is doing correctly. All the timings are spot on.
Then the problem must be from the outside. Power supply, op amp, tip, handle connection... Even a badly soldered capacitor on board, which has already happened.
I'm adding a fine filter tuning. Instead using rough 0...8 factors, now it can be tuned from 0 to 99%.
Calling the filter coefficient "k": New average = (k*previous average) + ((100-k)*new reading).
This means: As hig the value, the less impact the new reading has on the average. 100% can't be set, the average would never update - Yep, red glowing things would happen.
-
Wickated: I already owned the same version for a couple of years and didn't have any problems so I bought the same.
gx is at least equipped with 8551 opamp instead of noname fake sheet.
Don't be negative about this.
Normal version also has 8551 on it. At least I have it.
On my old (the same on the outside but with STM32F101 and S06AC opamp) it is an opamp that I can tell you it has the same noise as 8551 (I tested both). I could be wrong but if you try to order 8551 you usually get S06IA or S06AC.
When I thought my opamp was wrong I replaced it with S06IA and it is working without any problems (no oscillations).
David: I would suggest using PID as about 45-0-0 so that it is stable enough and see how period, delay, filter, (pwm multiplier)... maybe something else but it was just those 3 (4) things really had an impact on all tips. You know that I had a huge problem before you completely rewritten some things and from that time I never complained. I believe before that time I was pretty much the only one with complains. After that I just tried to help you back with testing and how I did my testing so that others could see what should be done to see how things could be better. But others used default values and whoever have problems didn't change that. Stop repairing what should be ok and try to chill for a bit with some other stuff. After you will have your head away from the project you could also think and see something better. Have a :popcorn:
And again THANK YOU VERY MUCH FOR A GREAT FW!!! :-+
-
45-0-0 is pure crap. The temperature will alway be lower than the setpoint, also the responsiveness will be close to nothing.
Updated code with new filter settings. From now the builds will be less frequent, so I recommend to install stm32 Cube ide and set up the project, it only takes 3 minutes, you have the video showing how to do it.
-
Some people are having problems with oscillation.
PIDs can have its own problems with some tips on default values.
That is why I suggested 45-0-0 to see how things are going and to see how iron settings are contributing to oscillations.
Trying different settings in iron along with different PID settings could be the solution. I know I had some problems at first and I had to lower PID values so that I had a stable response with different iron settings (in IRON menu). I used my worst tip that I had and tried so many times to see how it reacts to different settings. When I found it I tried PID settings as YOU suggested. You gave me a great advise regarding PID settings but that was possible after I set everything under IRON menu.
I tried many times to explain and you never liked it. I don't know if you even try to understand what I wrote so many times or you just know a lot better about this (I don't have any knowledge I just know I what I see) and I just had luck with my testing. It is your firmware and you are the boss (I understand that and I am fine with it) but please don't tell us to do some work and to share what we do if you don't like it then. All I explained here is how I did my settings when I had problems.
-
Please, just tell what's currently wrong, listing old bugs is simply confusing.
thats cuz i listed 1 bug before and that bug was not viable, but then i got another one and had to check if they have common source. newest build has fixes, i can even select temp while handle in stand. this makes me happy :-+
-
But you're runnign at 1mS, which is proved to not be correct :-//
With your suggested settings, I only get 100% power if the temp is under 60ºC below the setpoint. The it drops to 50% 30ºC below, and only 25% 15ºC away.
So where's your power? Are you fine with that?
Let me explain what's happening: It's like if you put a giant delay before your magical 1mS number. The PWM has been already stopped for a long time befor the delay has even started. And that's why it works.
Some you guys hype about the lowest delay, fastest pwm, while that's not the important. The only thing that matters is doing it right!
Sorry if that's not what you want to hear, but definitely 45-0-0 isn't a solution, just a cheap workaround. It's like if put a brick under the gas pedal in your car because it shakes when you push it too far.
There's something else that needs to be adjusted, probably timing.
I switched the filter calculation to floats to best accuracy.
Also, I took an old idea that was abandoned back then.
Resetting the Integrator acumulator when the difference is huge, so it doesn't overshoot like crazy.
But this time I used a different approach: Check for proportional output, if it's already saturating the pid output, clear the integrator.
When the temperature gets closer to the setpoint and the proportional starts going down, then the integral part starts working.
I've been tweaking the filter and pid settings for hours now. The new settings are amazingly accurate. For sure ksger will have trouble... :-DD
New builds available, hopefully they'll work ok.
-
So, I flashed the new version on my Quicko. Not too much seems to have changed. I like the new filter percentage. I played around with that from up to 90% and down to 20%. In the end, I went back to 65%. Then I set Kd to 50. Again, it seemed to cycle about four degrees, but the measured temperature seemed quite stable only varying about two maybe up to three degrees.
I did look into what it would take to change the opamp. It looks like the one that I'd need to change is U4, which must be on the other side of the board under the screen. U3 is called out in the schematic and is on the board where it's easy to get at. But it says it's not connected to the handle. Very inconvenient. :) I think I'll run it this way for now.
-
I doubt it's the amp.
As far as I know only Ksger mounts crappy amps!
I wouldn't bother more for just 3°C oscillation.
When it's a slow oscillation, try lowering the filter %, might help.
But it's easier to make It much worse!
-
But you're runnign at 1mS, which is proved to not be correct :-//
I believe you but I still don't know why.
With your suggested settings, I only get 100% power if the temp is under 60ºC below the setpoint. The it drops to 50% 30ºC below, and only 25% 15ºC away.
So where's your power? Are you fine with that?
Actually, yes, I am fine with it and that is why I always wanted to have a smaller delay. Exactly for that reason. With 200/20 you get slow start where you need a full power. After you don't need full power it pretty much doesn't matter if you have 200/1 or 200/50.
Let me explain what's happening: It's like if you put a giant delay before your magical 1mS number. The PWM has been already stopped for a long time befor the delay has even started. And that's why it works.
This is what I always wanted to explain you in the first place but you never wanted to hear me. As I already told you I believe you could be correct but I really cannot see that. In case you have any kind of link or anything else so that I could understand why I am wrong (or you are correct) please give it to me because I would really like to know where my thinking is way off.
Sorry if that's not what you want to hear, but definitely 45-0-0 isn't a solution, just a cheap workaround. It's like if put a brick under the gas pedal in your car because it shakes when you push it too far.
There's something else that needs to be adjusted, probably timing.
It is not a cheap workaround. It is something I explained why is this needed if my thinking is not wrong. Larger timing (20 or 20+) are not good on my PCB version.
I've been tweaking the filter and pid settings for hours now. The new settings are amazingly accurate. For sure ksger will have trouble... :-DD
Hoping for the best :box:
And thank you for a new build! :-+
-
200/20 slow Start? Are you kidding me?
Your way takes 30 seconds to fully heat :-DD
-
I don't understand it how. Can you please explain how is that possible?
-
I don't understand it how. Can you please explain how is that possible?
u have to get some I and D to deliver full power to tip. and its more viable than fast pwn and so on
-
How what? 200/20 "only" puts 90% of the power, so it will heat really slowly, right?
While killing the PID, using only a poor proportional value and causing the power to drop to 50..25...10% much sooner than it would do with a proper pid, will heat faster? :-//
-
AHA!!!! So I will have to do a lot more test about this.
So my test when comparing different timings with the same PID is really not a test. Crap.
Can you give me a starting point by telling me which PID coefficients are "fast" and which are "slow" if I would use 200/20?
Filter will be set to 4. PWM multi is oscillating if I set it more than 2x on 200/20.
Just to give you my settings on the tip I tested and it is not oscillating: 100/1/1x/ filter 4, PIDs are 100/30/10/0.4
THANK YOU GUYS!
-
I don't understand it how. Can you please explain how is that possible?
u have to get some I and D to deliver full power to tip. and its more viable than fast pwn and so on
I wasn't talking about 45-0-0. I was talking how to set IRON settings in menu and find stable settings before setting PID settings for each tip. All of the tips have the same IRON settings and each tip has their own PID settings. So first you need to find stable period, delay,... settings before sou can set PID. That is all I wanted to point out.
-
What about the current defaults?
Leave the delay untouched for tweaking, it won't harm.
Once you found good settings you might try lowering it.
Make a video of the oscillations and I might be able to recognize the pattern.
-
So I should leave everything under IRON settings at default and set Cal values and then try different PID settings?
I have version 2021.08.04b. Do I need new version?
I will be on vacation until Friday so that I will not be able to do any test from tomorrow.
-
You always need a new version if it exists :D
Start with defaults, just calibrate
-
so bug revisited me
sometimes when handle went to sleep rising from stand goes only to stanby. need to restart system.
-
Hi,
I've been trying the new versions, and I have some issues with some tips that used to work flawlessly on the older version.
This D12 tip used to have smooth lines, stable power meter, and no fluctuation at all.
Now it looks like this with no load (With the power meter going back and forth like it's possessed):
[attach=1]
And like this with load:
[attach=2]
I tried playing with filter percentage and PID values but don't seem to find the sweet spot to make it act like before.
How do I processed?
-
Try increasing the spikes limit to 3 or 4?
Old settings (not that different, but you see it doesn't need much to go completely mad :D)
Pid: 60-60-20-0.50
Filter:
Normal/spikes: 75
Partial: 50
Reset: 0
Spike limit: 2
Threshold: 300-500
Reset limit: 700
First, only change the filter settings and test the results.
-
Try increasing the spikes limit to 3 or 4?
Old settings (not that different, but you see it doesn't need much to go completely mad :D)
Pid: 60-60-20-0.50
Filter:
Normal/spikes: 75
Partial: 50
Reset: 0
Spike limit: 2
Threshold: 300-500
Reset limit: 700
First, only change the filter settings and test the results.
I don't mean settings, I mean older versions of the firmware.
I'm still getting those spikes that gets way worse with the sponge test/load test. And overshoots a lot when heating up or recovering from load.
I changed filter settings, and PID settings, going over and under your suggested values.
Here is a few screen shots from the 31/07 version, that one had very smooth response when heating/load.
-
That version was slightly different. Try this:
Threshold 50-150
Normal filtering 50
Partial filtering 25
Reset limit 0
Reset filter 0
-
I don't understand where to put these numbers.
The ADV Filter menu:
Threshold
End
Filter
Spike Limit
Filter
Reset Limit (Does not go to zero)
Filter
And there is the filter value in the Iron menu.
-
normal filtering is the option in iron menu (not adv. menu)
threshold 50
end 150
spike limit 0
Yeah sorry set reset limit to 700.
I'll have a look at that when I have free time.
-
Hi,
I've been trying the new versions, and I have some issues with some tips that used to work flawlessly on the older version.
This D12 tip used to have smooth lines, stable power meter, and no fluctuation at all.
Now it looks like this with no load (With the power meter going back and forth like it's possessed):
(Attachment Link)
And like this with load:
(Attachment Link)
I tried playing with filter percentage and PID values but don't seem to find the sweet spot to make it act like before.
How do I processed?
When I see those spikes and the power bar pumping like crazy, I know I need a lower Kd value. My D24 wants to have Kd=3. D52 has Kd=15. I keep lowering Kd until those spikes disappear and power bar behaves easy.
Generally speaking, I find that Kd=20 a little bit excesive. With default values, I'm getting resets while calibrating at 450º. Lowering Kd solves it.
-
normal filtering is the option in iron menu (not adv. menu)
threshold 50
end 150
spike limit 0
Yeah sorry set reset limit to 700.
I'll have a look at that when I have free time.
Changing those values does not help. Still very spiky and overshoots when heating up and recovering.
Strange thing is that tip used to behave very nicely using old firmwares. May I ask what is the difference between those two versions of the firmware.
When I see those spikes and the power bar pumping like crazy, I know I need a lower Kd value. My D24 wants to have Kd=3. D52 has Kd=15. I keep lowering Kd until those spikes disappear and power bar behaves easy.
Generally speaking, I find that Kd=20 a little bit excesive. With default values, I'm getting resets while calibrating at 450º. Lowering Kd solves it.
Thanks for the reply. I tried lowering the Kd as low as 2, and that does not help much. Problem is Kd that low will make recovering from a load overshoot a lot and takes a lot of time to regulate back to set temperature.
Edit: after a few resets, lowering the Kd to 4 seems to remove those spikes.But is it not a bit excessive to have to lower Kd so low for the tip to behave correctly?
-
I've tried to flash my ksger t12 without success, i erased and tried to flash and i always get an error saying that i need to upgrade the firmware, when i upgrade i get an error saying "Upgrade error, please try again".
So my ksger isn't working for now....
Edit: I managed to upgrade the firmware, a new error im getting is
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 97]
Error: failed to erase memory
Error: failed to erase memory
Any help would be greatly appreciated.
Edit2: I managed to install the new firmware, but the oled screen doesn't light up
-
I can confirm the temperature display mode bug. Fixed.
Couldn't reproduce other issues. Maybe some builds were not updated correctly as tatel's comment suggests.
New builds available, try them.
It's sleep time for me, more tomorrow!
Cuboy, that mcu will work fine with the current ksger v2 build.
Does anyone have original backups of ksger v1.5/v2/v3 or quicko F072?
Any problems i will report back.
Anyway today i was searching throught the code and saw that you reverted the pid algorithm to an old one, why is that? Doesn't the "new" algorithm work properly?
I'm willing to spend time debugging and working on it.
Hi. I have tested backups and flashing KSGER v2.1S and the one from HANDSKIT. The HANDSKIT does not asks for codes after flashing back to original but KSGER does.
Here is the keygen for codes that i have tested with 2.1S
http://t12.omegahg.com/keygen.htm (http://t12.omegahg.com/keygen.htm)
The files I have used are:
- T12_HW21S_Encryption-SH1106 _SW211.hex (version HW-2.1S; SW-2.11; SH1106)
- T12_HW21S_Encryption-SH1106_SW212.hex (version HW-2.1S; SW-2.12; SH1106)
- T12_v.2.1S_OLED1.3_enc_mod_SW211.hex (version HW-2.1S; SW-2.11; SH1106; encoder moves in opposite direction)
- T12_HW21S_Encryption-SSD1306_SW211.hex (version HW-2.1S; SW-2.11; SSD1306)
Oled Info:
SSD1306 - 0.96 inch
SH1106 - 1.3 inch
I have also attached short info how to flash the firmware.
Since google drive for firmwares is dead, I have uploaded also original copy of all the files there. From the name you should be able to identify the version.
I'm trying to reset my ksger to the old firmware, i have found those firmwares dont work for my station, i have HW: 2.0 SW: 2.09 do you know where i can find the firmware?
-
https://drive.google.com/drive/folders/114IoglODyu8bP7dqmw3WWMFV5O7RB9o4
-
https://drive.google.com/drive/folders/114IoglODyu8bP7dqmw3WWMFV5O7RB9o4
I have downloaded the one for the 1.3 oled and it doesn't work, it makes a strange beep upon start and thats it.
Maybe i have fucked something up |O
-
https://drive.google.com/drive/folders/114IoglODyu8bP7dqmw3WWMFV5O7RB9o4
Thank you for the firmwares, i have flashed it successfully to my old version.
I have a screen asking me for codes, i have id1:9E14 and id2: 685E
Ok found the keys, successfully reseted it to the original firmware.
-
Well, removed all the advanced filtering thing as it seemd to only cause trouble.
Now the only options are filter % and reset limit.
Reset limit is to override the filter if the difference is too big. And that's all.
This way it will cause a little overshoot when reaching the setpoint (actually not doing real overshoot at all) but will be a lot more stable.
Try the new builds and report.
-
Well, removed all the advanced filtering thing as it seemd to only cause trouble.
Now the only options are filter % and reset limit.
Reset limit is to override the filter if the difference is too big. And that's all.
This way it will cause a little overshoot when reaching the setpoint (actually not doing real overshoot at all) but will be a lot more stable.
Try the new builds and report.
David, i tried to install the firmware without any success, as noted i have HW: 2.0 SW: 2.09 1,3 oled KSGER
-
Weren't you already using this firmware?
Maybe your stm32 is actually 64KB only?
Post pictures of the errors and your board.
-
Weren't you already using this firmware?
Maybe your stm32 is actually 64KB only?
Post pictures of the errors and your board.
Forget the upgrade messages, those were stlink related. I have no board errors, its just that when i install the firmware the screen is dead.
My stm32 is 128KB, i have the black board -- im not sure about this, i need to confirm
STM32CubeProgrammer says i have the 128kb version (can this be trusted?) searching for the datasheet there are 2 versions available (64kb and 128kb)
(https://i.imgur.com/Z7TWwcb.png)
(https://ae01.alicdn.com/kf/Uc9e0f12d1f5e477ea99a7c85e60fd1b05.jpg)
the stm32 model is stm32101 rbt6 (Excuse the confusion, i thought by the review i had the one i said, but its this one)
And no, i wasn't using the firmware.
Will try to flash again
-
You should flash ksger v3 fw. Ksger versions are confusing, because the mix hw/sw v2/v3 versions.
If you read the readme... It clearly states to not flash based on the version reported by the original firmware, instead, compare your actual board with the pictures.
First of all, make a complete flash erase to ensure it lets you to do so.
-
You should flash ksger v3 fw. Ksger versions are confusing, because the mix hw/sw v2/v3 versions.
If you read the readme... It clearly states to not flash based on the version reported by the original firmware, instead, compare your actual board with the pictures.
First of all, make a complete flash erase to ensure it lets you to do so.
Will try this now, thanks
-
You should flash ksger v3 fw. Ksger versions are confusing, because the mix hw/sw v2/v3 versions.
If you read the readme... It clearly states to not flash based on the version reported by the original firmware, instead, compare your actual board with the pictures.
First of all, make a complete flash erase to ensure it lets you to do so.
Will try this now, thanks
Flashed, now its working as it should. How dumb am i:palm:
Now putting it at 450 celsius i get 250 celsius
-
"calibration". You keep ignoring the readme. Read it!
-
"calibration". You keep ignoring the readme. Read it!
Before i sent the post i calibrated, getting a calibration error. Im trying new tips.
I have read the readme and operation, as someone once said, read first, then post.
-
Then you should have seen something like "do not calibrate new tips until they become stable" :-DD
-
Then you should have seen something like "do not calibrate new tips until they become stable" :-DD
I had read that, yep. :-DD
Thank you, will let the tips bake for a little, then try to calibrate them.
-
I have flashed the last commit (10-08-2021) and it's working flawlessly. Tested 2 tips, t12-ku and bc3, calibration works great and no crazy spikes.
Thanks for all the help, I thought I broke the soldering station but i was flashing the wrong firmware.
Will keep testing tips and creating profiles, but for now its working great.
-
I know I'm nitpicking on cosmetic details but the time unit "mS" should be all lowercase "ms" (uppercase "S" is a unit of conductance).
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/iron_screen.c
lines 411, 425 and 465
Feel free to keep it however you want after the // >:D
-
There's a 4th "mS" :-+
-
Loaded 2021-08-10. Now there are clearly less spikes at 450º; just some at first seconds after setting the temperature, then it gets stable with default PID values. So it's better now than yesterday.
But I still feel this behaves like a horse after feeding on psylocybes. I agree with other posts: FW about 07-31, 08-02 was "better". IIRC, then "PID tau" was missing, before coming back? What I remember is it was quite easy to get almost flat graphics, about 1-2ºC max oscillations, and nice ramps when lowering temps.
Please see attached picture. Left-most ellipse marks a peak on a from-350-to 300º descent ramp. Power bar didn't showed any activity, so temp should be getting lower without any disturbances, as before. Yet it's usual to see those peaks since some days ago. Remaining ellipses mark two instantaneous temperature changes, about 3º. I'm not -at all- sure about these. Perhaps it's a spike from NTC or so. But I don't think tip temperature can drop instantaneously. And I'm sure this behaviour wasn't present about a week -or two- ago.
So, while this FW is getting better and better, I think there is some regression in this aspect. Maybe there is some overreaction?
-
Those spikes are less than 5°C.
That's simply and plainly how the TC sensor reads.
Yes they can do very weird things.
There's nothing else now than plain average and %.
No "overreaction", "ntc spikes", "black magic".
Reduce KD if so, or increase filtering.
-
BTW, could somebody explain how do I restore an image saved with openocd's "dump_image filename.bin 0x08000000 0x20000"
I'm trying with "load_image", "program" and "flash write_image" but I'm just getting errors. Second time this happens to me... so calibrations losed (again)?
David, I don't know about black magic, but my NTC didn't read like that a week ago
-
What's wrong with the NTC? 32.9°C?
I won't spend any more time guessing values for 2°C oscillation that leads to nothing.
I willl try for the last time the old pid algorithm, but I'm leaving the project soon.
-
are you considering it finished? or is anyone taking it over from you? i have not been able to test the last few builds so im just wondering.
either way thank you for the work and time spent on this!
-
Thank you for your work David and everyone who contributed into this, i know it isn't easy.
-
What's wrong with the NTC? 32.9°C?
I won't spend any more time guessing values for 2°C oscillation that leads to nothing.
I willl try for the last time the old pid algorithm, but I'm leaving the project soon.
Sorry if that made you feel frustrated. This is just feedback. As I see it, this new, more agressive PID, makes the system less stable, without giving any advantage that I could see, bugfixes aside. Old PID worked OK for me. Tips got hot more than fast enough. Small initial overshoot. Rapid stabilization. Passed the wet sponge test with flying colors. Easy fine tuning. I couldn't ask for more than that.
So, can last version be used without any problems? Yes, sure as hell it's good enough. But last week updates just gave between 3x and 8x the oscillation to me, without any visible advantage in any other aspect. Again, bugfixes aside. Again, sorry the bad news. Probably others could see it other way, and it will be helpful to hear about their experience.
Should you go back to old PID again, I'll stick to it like Tarzan to Chee... uh, Jane.
-
It's very sad that you're leaving the project, you breathed new life for those units.
Cosmetically, the firmware now for me is in a perfect spot, a little more tweaking in the PID section of things and you can leave it in a great spot if you decide you had enough and want to leave the project.
The 10-08 is better than the last one for sure, still spikey, but you have to lower Kd to 10 instead of 3-4 to get rid of the spikes.
I have to agree with the other posters here, the old PID algorithm was more stable and gave smoother curves and less black magic. With minimal editing of PID you can make a really bad tip to behave.
Edit: There is a small bug with the standby feature. It takes 1.5 minutes over the specified value. I tried it with 1,2,5 minutes. And it always adds 1-1.5 minutes over.
-
The menus, settings and everything are there for something. Not just to be fancy.
I have to loose an afternoon trying 100s of pid settings, then making new builds just for you to try. All I can do is guessing, I don't all have the tips and controllers in the world.
Let me explain what should be happening and it's not: You, the community, should be trying, finding and discussing settings for your hardware.
A blinded monkey can build the firmware. There's a video for that, it takes 3 minutes.
If you suspect of the pid, guess what? There're only 3 lines in pid.c that says "old" and "new". Disable the new pid, try the old one and show your findings.
But is easier to just wait, isn't? I'm tired, people seems to translate open source as "it's free, and there's someone doing for me everything I ask".
I completely deleted the new pid code. I hope it does better, because it's not going to come back, ever.
At first, it didn't any better, in fact it was way worse, I had to adjust the PID settings to avoid wild spikes.
dark_hawk, I don't know what are you talking about. It takes exactly the set timeout. Remember encoder activity also wakes the station (and/or resets the timeout) if enabled.
-
The menus, settings and everything are there for something. Not just to be fancy.
I have to loose an afternoon trying 100s of pid settings, then making new builds just for you to try. All I can do is guessing, I don't all have the tips and controllers in the world.
Let me explain what should be happening and it's not: You, the community, should be trying, finding and discussing settings for your hardware.
A blinded monkey can build the firmware. There's a video for that, it takes 3 minutes.
If you suspect of the pid, guess what? There're only 3 lines in pid.c that says "old" and "new". Disable the new pid, try the old one and show your findings.
But is easier to just wait, isn't?
I completely deleted the new pid code. I hope it does better, because it's not going to come back, ever.
At first, it didn't any better, in fact it was way worse, I had to adjust the PID settings to avoid wild spikes.
dark_hawk, I don't know what are you talking about. It takes exactly the set timeout. Remember encoder actitivity also wakes the station, if enabled.
For me it works properly, some tips depending on the profile go crazy and the board asks for a reset, that is because they are new and unstable.
Did testing with 5 tips already, after some baking and then some calibration they work properly.
The new PID looks fine, I'm using the 10-08-2021 build. As I see, the old PID is a more "simplistic" version of the new PID, which I guess you will get less accuracy. I Will test that later.
You're working with hardware that has a lot of different versions, which is pretty difficult in the sense that everyone has its own errors. For me the defaults work properly using the new PID;
systemSettings.Profile.tip- .PID.Kp = 7000; // val = /1.000.000
systemSettings.Profile.tip- .PID.Ki = 6500; // val = /1.000.000
systemSettings.Profile.tip- .PID.Kd = 2000; // val = /1.000.000
systemSettings.Profile.tip- .PID.maxI = 75; // val = /100
Haven't got any errors apart from new tips being unstable (which is normal for new tips). When asking for power(lets say 450c), there is an oscillation of +-2 degrees, which I don't care about.
-
The 2021-08-11 has the previous pid algorithm, also similar pid settings to older versions.
-
its almost fun to look at diffrent user complaints compared to my own rumbles about small spikes on genuine hakko tips. :horse:
still ticketing small bug with stand sleep to permanent stanby on lift.
everything else is good for me, maybe old pid didnt overshoot on liftoff? i dont even remember :-//
-
well i know i appreciate all the time and work you put in for sure. i feel really bad i wasnt able to test as much as i wanted to due to the eye. but know i do appreciate it very much.
-
I hate to say it but It's still spikey, you still need to lower the Kd under 10 to get rid of the spikes, so I don't think the new PID is the culprit here, more with the filter and reset limit.
Reason for reporting is that tip and the others are your run of the mill Chinese tips, nothing special and no problems, so if I'm having the issues I'm sure a lot do too.
I don't expect you to fix it, but I thought I just report it. I still appreciate your effort and your time, but not all of us monkeys can edit and compile code, some of us - including myself - are hobbyist with limited knowledge in these areas.
For me the solution is easy, go back to the last known working - for me - iteration of the firmware.
-
I hate to say it but It's still spikey, you still need to lower the Kd under 10 to get rid of the spikes, so I don't think the new PID is the culprit here, more with the filter and reset limit.
Reason for reporting is that tip and the others are your run of the mill Chinese tips, nothing special and no problems, so if I'm having the issues I'm sure a lot do too.
I don't expect you to fix it, but I thought I just report it. I still appreciate your effort and your time, but not all of us monkeys can edit and compile code, some of us - including myself - are hobbyist with limited knowledge in these areas.
For me the solution is easy, go back to the last known working - for me - iteration of the firmware.
Yep, you are right. New PID wasn't the culprit. I have to say that last firmware, after just calibrating with default PID values, never gives me more than a 5ºC oscillation. Good!
Now let me explain what I was speaking about. Here's how my KU tip behaves, after just calibrating with default PID values, on FW 2021-08-2a
-
Sorry, tried to put pictures aside and it seems it's no good... so here there are...
-
It takes just one attachment?
-
Yep
-
so which one specifically are you speaking of firmware wise? there was a bunch he released in the past couple weeks. which version was the better for you guys? i was trying to test for a while till they got on me for not getting smoke in the eye. i saved both the new one with the old pid and the last one before that i believe which had the new pid. id love to mess with the firmware but at the moment seeing clearly to read is my issue. its tough still.
-
This is 2021-08-02a... I don't know abouth others but I'm sure they are there. Please stay health. Best wishes.
-
Sorry I couldn't resist... this is how things looke like in 2021-08-10 :wtf:
-
just increase delay 200/20 like it was for t12 :blah:
-
Not having that issue wickated, in stand mode the station goes into run state on lift, in any low power mode.
-
I didn't find anything about the CEIAH IC.
Seems to be an independent voltage regulator for the analog? Or at least it sems to power only the op-amp and the stm32 VDDA.
It's definitely an EEPROM in sot23-5 package (U2 chip)
(https://obrazki.elektroda.pl/4_1274112100.jpg)
-
Let me explain what should be happening and it's not: You, the community, should be trying, finding and discussing settings for your hardware.
A blinded monkey can build the firmware. There's a video for that, it takes 3 minutes.
If you suspect of the pid, guess what? There're only 3 lines in pid.c that says "old" and "new". Disable the new pid, try the old one and show your findings.
But is easier to just wait, isn't? I'm tired, people seems to translate open source as "it's free, and there's someone doing for me everything I ask".
I completely deleted the new pid code. I hope it does better, because it's not going to come back, ever.
At first, it didn't any better, in fact it was way worse, I had to adjust the PID settings to avoid wild spikes.
dark_hawk, I don't know what are you talking about. It takes exactly the set timeout. Remember encoder activity also wakes the station (and/or resets the timeout) if enabled.
What should be happenning and isn't is that it would be better to have a serious developer who listens what the testers have to say. Instead you closed your ears and throwed yet another temper tantrum.
Now we all know that a week ago we already got the 30-bucks-almost-JBC-station. Now we all know that you, the developer, not just didn't even noticed it, but you were complaining we users do nothing while managing our reports with pure comptent. Refusing to think that non-programmers could notice a 5x greater oscillation and know what's better. Saying that it was cheap chinese hardware's fault. Well, it's now clear that it was instead a turd in your code, it isn't?
I'm not here to feed your ego. Please spare the teenager drama and explain where the turd is and how it got sneaked into your code.
Alternatively, put your cojones were your mouth is and go away as you said here many many times. I already got even more than I (and you) were hoping for and I just cloned your repository. Not that I'm wishing to build it. But I can work with 2010-08-02a until I eventuallly have the time and the need for it to do better. That would be bad, but after your answer to wickated, I'm thinking it couldn't be worse that having to support our dear big great toddler.
I don't really think wickated was speaking literally, do you?. Rajoy style won't work.
And please apologize to dark_hawk as a real man would do. I think you owe some apologizing to -at the very least- him.
-
Sorry, but if you read carefully, it wasn't against dark_hawk, it was more like a global relief.
In fact you have a been a lot worse with your dramatic 2°C spikes.
Go and install your Quicko/Ksger fw that hides the real temperature, if that makes you happier... Even jbc does that.
Serious developer? Maybe that means: huh I have 2 degree oscillation, please spend a whole day trying something for me! Or is it someone that keeps programming night and day to keep everyone happy?
It has worked great for me since months ago, I was fine stopping there, but check my ego: I carried on, and at least 90% of my time has been for the community!
Almost every requested feature has been added to the firmware, some requiring days of work to fully develop and bugfix. Specially f** bugfix.
So clearly you don't know me at all.
Instead blaming my ego, join the project and start developing...you'll see that pid, tips, pwm and filters are anything but easy to tune.
Maybe it works for you, but then wait, because ot will cause havoc on other stations!
I didn't knew I wasn't allowed to complain! I have a life!
One thing is to support the project and a very different one is people wanting everything done.
The next firmware will remove all options, as it seems some people only know to flash and run, instead using the damn options to tune things up :-DD
Otherwise, don't get into the custom firmware thing if you want someone doing all the work.
-
Let me explain what should be happening and it's not: You, the community, should be trying, finding and discussing settings for your hardware.
A blinded monkey can build the firmware. There's a video for that, it takes 3 minutes.
If you suspect of the pid, guess what? There're only 3 lines in pid.c that says "old" and "new". Disable the new pid, try the old one and show your findings.
But is easier to just wait, isn't? I'm tired, people seems to translate open source as "it's free, and there's someone doing for me everything I ask".
I completely deleted the new pid code. I hope it does better, because it's not going to come back, ever.
At first, it didn't any better, in fact it was way worse, I had to adjust the PID settings to avoid wild spikes.
dark_hawk, I don't know what are you talking about. It takes exactly the set timeout. Remember encoder activity also wakes the station (and/or resets the timeout) if enabled.
What should be happenning and isn't is that it would be better to have a serious developer who listens what the testers have to say. Instead you closed your ears and throwed yet another temper tantrum.
Now we all know that a week ago we already got the 30-bucks-almost-JBC-station. Now we all know that you, the developer, not just didn't even noticed it, but you were complaining we users do nothing while managing our reports with pure comptent. Refusing to think that non-programmers could notice a 5x greater oscillation and know what's better. Saying that it was cheap chinese hardware's fault. Well, it's now clear that it was instead a turd in your code, it isn't?
I'm not here to feed your ego. Please spare the teenager drama and explain where the turd is and how it got sneaked into your code.
Alternatively, put your cojones were your mouth is and go away as you said here many many times. I already got even more than I (and you) were hoping for and I just cloned your repository. Not that I'm wishing to build it. But I can work with 2010-08-02a until I eventuallly have the time and the need for it to do better. That would be bad, but after your answer to wickated, I'm thinking it couldn't be worse that having to support our dear big great toddler.
I don't really think wickated was speaking literally, do you?. Rajoy style won't work.
And please apologize to dark_hawk as a real man would do. I think you owe some apologizing to -at the very least- him.
So much drama when just trying to develop firmware, goddammit.
Please just let the drama behind and let's try to work through it. We are here to try to help develop firmware, testing...
Errors can happen, we're all humans.
Adding drama to the equation will not help more, so it's better to leave it out of the equation.
-
Sorry, but if you read carefully, it wasn't against dark_hawk, it was more like a global relief.
In fact you have a been a lot worse with your dramatic 2°C spikes.
Go and install your Quicko/Ksger fw that hides the real temperature, if that makes you happier... Even jbc does that.
Serious developer? Maybe that means: huh I have 2 degree oscillation, please spend a whole day trying something for me! Or is it someone that keeps programming night and day to keep everyone happy?
It has worked great for me since months ago, I was fine stopping there, but check my ego: I carried on, and at least 90% of my time has been for the community!
Almost every requested feature has been added to the firmware, some requiring days of work to fully develop and bugfix. Specially f** bugfix.
So clearly you don't know me at all.
Instead blaming my ego, join the project and start developing...you'll see that pid, tips, pwm and filters are anything but easy to tune.
Maybe it works for you, but then wait, because ot will cause havoc on other stations!
I didn't knew I wasn't allowed to complain! I have a life!
One thing is to support the project and a very different one is people wanting everything done.
The next firmware will remove all options, as it seems some people only know to flash and run, instead using the damn options to tune things up :-DD
Otherwise, don't get into the custom firmware thing if you want someone doing all the work.
Will say the same as last reply David, we're being drama queens and we have a spanish flag on our profile. Leave the drama behind, it will hurt more than it will help!
On a serious note here, how do you compile-build for different versions of the firmware once you add a piece of code?
-
dafuq did i read.
David isnt a developer, he is a contributor. he doesnt sell his firmware, his fw is hobby fork of ptdreamers old one. fw is open source, go to rep, copy it and give it to stm developers who definetely wiil make it work with some china shit flawlessly.
since this noone have a permission to rant on David`s errors or end of development or so on. just use what u have, u can even easily rollback on older fw for stability instead of whining. actually David spend like 2 weeks in a row rewriting code for free before burnout.
p.s. also u all can buy high quality components for hw upgrades or even genuine tips. using faulty fake opamp and shiity solder joints and wires and blaiming fw not supporting this crap is just plain stupid.
i have everything working great, but i did tons of work to make my hw work flawlessly, why cant all of you?
-
I don't like drama. I joined this project to contribute positively where I can. I haven't changed my mind. That is what I will continue to do. That's my vote.
-
i wish i would have kept some of the builds along the way. i would have no idea how far to go back now. some of them worked darn near perfectly and i only updated to get the newer features he was adding even some of the very early builds were great and pretty stable. i may have to grab all the old ones and keep them for testing now.
again i want to say thank you and i would love for you (if its possible) for you to release whatever you feel was the version YOU feel was the best one as kind of the final one. features aside i just want stability myself.
i wish i could take it over i have the time but im so new to stm32 and without being able to read very well im not sure that would be easy to do.
no one should be yelling at him or jumping on him there were hours spent on this and i doubt there were many donations. i was and still willing to send parts to him im not sure others were. just know some of us VERY much appreciate your time you spent on this for us and are sad to see you go and it end this way if it will. maybe offer it to those who want updates for donations or a one time donation something like a patreon or something like that i would be up for that and im sure others would also. at least to get some compensation for all your time.
-
On a serious note here, how do you compile-build for different versions of the firmware once you add a piece of code?
I'm not quite sure what your question is. If you have watched the video on github ( https://github.com/deividAlfa/stm32_soldering_iron_controller#building ), then you know how to build the firmware from source. The process doesn't change after you've modified the code: save your modified files, press the "hammer" button, done. Now, if you want to know where to change the version string to keep track of your various builds, it's in Core/Inc/settings.h at line 37
-
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 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/121375fc1dbd8f0c5800a8e9d2fb5a4b286fcff5) (Agressive PID?)
2021-08-01 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/a09f40c511964767819770d808fe82a9d3a407e9) (Reduce PID and filter values)
2021-08-2c (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/96f40ef43ea0b23e9c83fdb3638fa87a90b37e40) (Last build before switching to new PID)
2021-08-04a (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/1fe5860aa2ad832a0b72192378c2ed60146a2198) (Last build before adding new filter method)
2021-08-04b (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/d1c1aa6b58f4566e70feb4a3a4a9ac01b143491e) (New filter method)
2021-08-05 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f1a4cc7f849ca86a26d58739639831f1a1e05fc0)
2021-08-06 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/44894d8a440a201cdf6ca0631806be97473698d1)
2021-08-07 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/30e00692dae2469dcbe576dbf09e22edeee68554)
2021-08-10 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f7db75fab41260d25ed44d445df1db876fd4663d)
2021-08-11 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/1ae831a30f4eaae2b4f478df59647b0cee525e45)
-
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 check the code affecting that.
What I can't do anymore is keep trying random settings and building everytime.
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 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/121375fc1dbd8f0c5800a8e9d2fb5a4b286fcff5) (Agressive PID?)
2021-08-01 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/a09f40c511964767819770d808fe82a9d3a407e9) (Reduce PID and filter values)
2021-08-2c (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/96f40ef43ea0b23e9c83fdb3638fa87a90b37e40) (Last build before switching to new PID)
2021-08-04a (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/1fe5860aa2ad832a0b72192378c2ed60146a2198) (Last build before adding new filter method)
2021-08-04b (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/d1c1aa6b58f4566e70feb4a3a4a9ac01b143491e) (New filter method)
2021-08-05 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f1a4cc7f849ca86a26d58739639831f1a1e05fc0)
2021-08-06 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/44894d8a440a201cdf6ca0631806be97473698d1)
2021-08-07 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/30e00692dae2469dcbe576dbf09e22edeee68554)
2021-08-10 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f7db75fab41260d25ed44d445df1db876fd4663d)
2021-08-11 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/1ae831a30f4eaae2b4f478df59647b0cee525e45)
I dont know if i'm lucky or not (regularly i have more bad luck than good one) but in this case for me the fw works flawlessly as i said on a previous post. My ksger has the built in converter so i dont need a power brick.
I dont get any crazy oscilations, no crazy behavior, for me its on point. Lets wait for more ksger users feedback.
-
With the current version? The "spiky" edition? :-DD
Somewhere in the future, showing a "KSGER" logo to electronics engineers will make them run like scalded cats.
Run for your lives! Ksger is back! :scared:
With the current one I get a little of overshooting in my Quicko. +7ºC for 1 second and it settles down.
Of course, the tip doesn't even notice. Not only that, it's still colder.
I used it a lot during this week, I really noticed the 5ºC drift when soldering (ironic mode on).
I'm tired dude, people thinks they can get a JBC for $30, and while it's great performance per buck, they gave to undertand the limitations.
No current sensing, no proper tip detection, crappy board layout susceptible to noise, cheap sensor amplifier, cheap thermocouple compensation...
When you all see a 5ºC error, think it's 100uV. 0.0001V error at the input of the amplifier. Damn it, it's already great for what it is!
On a serious note here, how do you compile-build for different versions of the firmware once you add a piece of code?
I think it's pretty well explained here:
https://github.com/deividAlfa/stm32_soldering_iron_controller#building
Any change in code will be compiled everytime you run it.
-
With the current version? The "spiky" edition? :-DD
Somewhere in the future, showing a "KSGER" logo to electronics engineers will make them run like scalded cats.
Run for your lives! Ksger is back! :scared:
With the current one I get a little of overshooting in my Quicko. +7ºC for 1 second and it settles down.
Of course, the tip doesn't even notice. Not only that, it's still colder.
I used it a lot during this week, I really noticed the 5ºC drift when soldering (ironic mode on).
I'm tired dude, people thinks they can get a JBC for $30, and while it's great performance per buck , you don't have 1/3rd of the circuitry.
No current sensing, no proper tip detection, crappy board layout susceptible to noise, cheap sensor amplifier, no proper thermocouple compensation...
Not the current version, the last version before this one.
We might not have a JBC, but it works great for 1/3 of the price. Also i have seen wickated using the c245 which is great. We might not have a jbc, but we have something built by the community and cheaper than a JBC.
Of course you will get lots of headaches dealing with that, lots of different feedback from different users with different problems. To deal with that I would suggest using GitHub issues (at least, you won't deal with drama, which sometimes by itself consumes lots of brainpower which could be used to deal with actual problems).
Edit: also yes, i saw the video,for some reason i thought i needed to do another thing when changing the code, thanks.
-
Glad we are back to some rational talking instead of name calling and temper tantrums.
David, please understand, no one here is complaining about 5 degrees oscillations.
If someone new got his unit today and flashed it he will be happy with the performance. Thing is for others who have tested older versions, things at some point started to get worse. For example, for me with 31/7, things where great, no spikes, no oscillations, no overshoots, fast recovery from load, and stable ramp up curves. I even have 3 bad tips that can be tuned with minimal PID adjustments.
Jump forward a few versions, and we got spikes, and not just 5 degrees, more like 30 when recovering and when ramping up (onscreen), and yes, there are actual overshoots on the thermometer not just the screen (not the 30 on screen). A power meter that goes back and forth like it's on meth, and to reign everything you need to lower Kd to insanely low numbers to get it to start behaving. Note that's it's the same hardware, nothing changed expect for the firmware.
If you decide that you have spent enough time with the project and is happy with the performance of your unit, do move on to other projects with the best of luck and wishes. But if want to keep working on the firmware, please be more patient and respectable to your testers, at the end of the day no one here - including myself - expect you to fine tune his individual unit, but when more than one person with different hardware start reporting the same issues, you might want to start taking their feedback more seriously.
-
I know JBC works great. It's not a miracle, JBC tips are much easier to control than these crappy T12s.
You only need a capable power supply, the rest is plain easy.
I remember that part. I was getting complains due little oscillations in some devices. And see, it would have been better to not have touched it.
But this is the everyday trial and error.
I don't thing github ticket system would do better. After all, the message depends on who writes it. So it would be the same there and in the forum.
Anyone could flood github with silly feature requests, too.
People should be more self-capable, I can't fix every station out there.
You should always have taken note of the good one, and know the filter/pid/pwm values you were using.
If the next build, or the next 20 are wrong, the menu is there, the first step is to compare the settings and restore them if different.
Then, instead writing a hell of comments, report a concise report. Some people did great, it helps a lot.
- The problem
- Works restoring older settings? What happens when retoring them?
- Last version that did ok. Flash that version, test it and make sure it's true. A "maybe" will waste a lot of my time.
- Keep it clean.
I will wait for more feedback. Ensure to report the last version that worked ok. Always fully reset the station and try.
No need to calibrate everytime, just restore the tip calibration values.
Don't report bugs from older builds.
-
Ksger user (David knows that :-DD):
I don't see any oscillation and I never saw it. But I must tell you that I didn't check all of my tips, I am using the one that I had the most problems with.
From 6th (or 5th) of July when you made a build that put everthing upside down (at least for me) I didn't have any problems.
But I followed your advise about PID settings. I didn't follow your advise about IRON settings (period, delay) and I still don't see anything better with those settings BUT!!!! I have to do a complete testing from the start which I didn't and I just used my old settings with your/mine period and delay to compare them.
I tested with 11th of Aug build, 4b from August (didn't test others in between) and i case you need me to test them about oscillation, please let me know.
Using my bad chinese K tip, FW from 2021-08-11, PID settings 100-30-10 with Imax 0.4 I don't see anything different in compared to older builds.
I also set PID to 100-60-20 and was ok.
On lower temperatures (for example 270) and coming from room temperature I see some overshoot (sometimes to 10, sometimes to 20, but only for a second or 2) on the soldering station. Tip is actually way lower and needs quite some seconds to get to desired temperature. On the graph I can see that power and temperature are stable even before the end of the tip is getting to desired value (on all temperatures 270-450C).
On 200/20 (period/delay) I see a little bit more power jumping (not really on the end of the tip!). On the 100/1 I see a little bit less or pretty much no jumping at all (again no differences at the end of the tip).
Measuring time to get to 350 C from "zero" it makes no difference on the same PID setting (compared 200/20 and 100/1 - period/delay).
I didn't test it long enough but I never got any problems.
To sum it up: I don't see any differences in old or new FW versions about stability or oscillations. My KSGER have no problems after 6th of July :-+.
David, if you have some specific test that I can do please let me know.
-
David, I was sure you wouldn't go away, even after being directly challenged to put your own words into practice. So could you please spare those pathetic shows? All you need is to say "I need a break"
If you want people collaborating, you must put your contempt two meters under ground and keep it there, even if you feel the comment/suggestion/report implies criticism of your work. Remember, those collaborators are doing it for free, too. I see it's a lot easier to ask for a new feature than to warn about some regression. That's your ego at work
So you have been warned by two different persons that the system is, from some days ago, quite a lot less stable than it was a week ago, and all you did was to show contempt. Then you were provided with the pictures to demonstrate it and a FW version that does it right. Then you choosed to ignore the report, answering wickated comment instead. That's your ego at work, again. Time for banderillas de fuego.
Now you are instructing people what to do to report a bug in your code, like if that info was never been provided to you in this case. All wrapped in a whole mountain of chinese cheap hardware mumbo-jumbo. But at least you are now doing the right thing: to revert git commits until the turd surfaces out.
Cuboy is right, we are all humans and errors can happen. What matters is what we do to amend those mistakes. I don't see any amend in your last posts. Contempt clearly is there again, now that your ego got somewhat massaged. You really need it, it isn't? Qué pobre hombre.
So I can only assume this project is flawed. And, if your statements aren't pure bullshit, it looks like I probably got lucky and to get a better working firmware on my station is impossible, since you say I got what I got because of some very unlikely astral conjuction of Saturn with Uranus, firmware and chinese hardware. Not that I think you're getting it right, but... in that case... then why should I waste my time collaborating with a toddler who mainly shows contempt to any criticism?
Anyway 2021-08-02a does all I need it to do, and I think it will do in the foreseable future too. No juju in electronics, wizard.
My collaboration -and this argument- ends here. But I'm not leaving. I will keep one eye here, and will happily download any new version, should it be better than 2021-08-02a. I'll probably be cloning your repository, too, just in case you throw another temper tantrum and delete some code (again). Then I would put it again on GitHub for the people to download/fork ;)
Good luck guys
-
Wanna keep it just in case I delete my own code? Here it goes the drama again.
I never felt that pid working right, so why to keep it?
The current pid has been used 99% of the time, I'm just removing problem sources and simplifying things out, I was tired of going back and forth.
Do whatever you want, this is open source.
For sure you know how git works, drama(2), anyone can recover that code at any moment by checking the git log, which I usually document very well. :-+
-
Drama is when you throw a tantrum, and anounce you deleted some code forever. Now this is stupidity. I already got it cloned and I can do it again no matter the reason why. Argument ended on my previous post. All people here has seen what happened. So you can keep masturbating as long as you need it. Not my problem any more.
Now I'm going to socialize a little bit. I have a life!
-
We need changes, this can't be ongoing.
If you keep this out of context, we won't advance anymore. This thread should be about technical discussions, testing, and feedback. Personal comments and opinions about each other are out of context. And those shouldn't be tolerated.
I don't really care about social life, personal events, or whatever, I'm here to try and contribute to a project I find interesting, that's it.
Then again, please, keep out all these personal comments because this wasn't what this thread was intended for.
Any help with stations, suggestions, any feedback, or technical discussion will be accepted, but not that bullshit we are dealing with right now.
-
One minor feature re-request, long press in menu goes back vs exit.
-
One minor feature re-request, long press in menu goes back vs exit.
Hello, I haven't understood it correctly, so when long-press in the menu it shuts down the station? instead of going to the temperature display
Seems like a good idea
-
Cuboy, he means going back to the previous menu/screen, instead exiting the menu.
It's impossible to make it for everyone's liking, so I hope you understand why I won't do that.
You can go back easily, it's always the last option, so simply scroll down.
Needing to go back 3 times to exit the menu is a lot more annoying, so it's way better like it is now.
-
I don't mean to pile on here, but I do like it as it is. I'm pretty used to the current behavior. :)
-
i agree i honestly prefer it the way it is im fine with using the exit option.
-
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.
-
That already exist, read the manual.
-
That already exist, read the manual.
I was scrolling through the code and saw commit 3f0f705 had a data->big_step on system_screen.c
Thanks.
-
Read the *** operation guide :-DD.
I really hate those silly questions everytime because lazy people don't want to read!
Rotate while pressed to use big step.
-
Read the *** operation guide :palm:
I see it :-DD.
While editing the widget, normal rotation will make fine adjustement. Click and rotate will do coarse adjustment.
Also, for temperature it doesn't work
Isn't there a way to detect if the know is rotating faster or slower? like counting the number of rotations made in a second?
I saw the error, will make edit and make a pr just so i feel i contributed :-DD
-
Everything could be done.
It actually counts the steps, but the system is so fast that you'll hardly make steps faster, so it'll mostly read every step as it happens.
You should know that click and rotate is used for other functions in the main screen, that's just extra hassle for nothing.
Nope, not going to break my head with that :D
I'm still waiting! Remember is up to you, the firmware will remain as it is until I get proper feedback of what versions worked better.
Some people doing drama, deciding to go away, should realize they're hurting themselves, I don't need help for fixing my own for my own station, and I don't care about bugs for features I don't use (That's why these bugs happen), it's them who aren't going to get any fixes :D
-
Read the *** operation guide :-DD.
I really hate those silly questions everytime because lazy people don't want to read!
Rotate while pressed to use big step.
My bad, I skipped that line it while reading through it for the 3rd or 4th time but I'm glad the feature was already there so thanks for that.
Gotta say though, if I could blow as much hot air as you do on a regular basis, I wouldn't need a soldering station.
-
I edited the message because I thought it would look like me being angry. Not that, I'm just a little tough, specially when I have to lose my time: once to write the readme, manual, FAQ... And then each time someone doesn't give a *** about them and keeps asking because it's easier :-DD.
Sometimes I just repeat the same thing for 471849th time, while others I use the RTFM (read the fu*** manual) quote, it has existed since the beginning of the times, it seems the problem is nothing new :D
Yep, sometimes I don't need to power on the soldering station. Some hard words and it'll heat up by itself ;)
-
I edited the message because I thought it would look like me being angry. Not that, I'm just a little tough, specially when I have to lose my time: once to write the readme, manual, FAQ... And then each time someone doesn't give a *** about them and keeps asking because it's easier :-DD.
Sometimes I just repeat the same thing for 471849th time, while others I use the RTFM (read the fu*** manual) quote, it has existed since the beginning of the times, it seems the problem is nothing new :D
Yep, sometimes I don't need to power on the soldering station. Some hard words and it'll heat up by itself ;)
I have a question, im trying to add big steps for temperature screen, so when click+rotation is done, it makes a big step. This time not for widgets but for temperature.
Where do you deal with that?
-
Check process input function in main screen.c
/drivers/gui/screens
Always check ***screen**_setup function, each screen has it's own, where all the handlers are declared.
Not easy because there's a lot of hacking to make the different main screen functions, it uses a custom process input function, overriding the default one.
Otherwise it would be extremely easy.
You won't be able to set sleep/standby modes neither select tips unless you code your own method.
But is not up to me, spend some days studying the firmware and figuring things out.
Let me be clear about this, I can help a bit, but I won't be teaching how to handle every single bit of the code.
Being open source means "as it is", not free unlimited hours of support.
-
Not easy because there's a lot of hacking to make the different functions work, it's not the widget doing the work.
You won't be able to set sleep/standby modes neither select tips.
Check process input function in main screen.c
Drivers/Gui/screens
But let me be clear, I can help, but I won't be teaching how to handle every single bit of the code.
Being open source means "as it is", not free unlimited hours of support.
I know, I will try to do it and see if I'm able to do it.
I need to understand pieces of code still, but thank you anyway.
-
Damn, I always hit post instead preview and then someone quotes me before I finish the message :-DD
-
Here's is your bug report from 6 days ago:
The one before 11-8:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3623522/#msg3623522 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3623522/#msg3623522)
The 31-07:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3623645/#msg3623645 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3623645/#msg3623645)
-
Damn, I always hit post instead preview and then someone quotes me before I finish the message :-DD
I've been looking at the code for a little.
Is Widget_SetPoint the widget where the temperature is drawn?
Thanks.
-
Some people doing drama, deciding to go away, should realize they're hurting themselves, I don't need help for fixing my own for my own station, and I don't care about bugs for features I don't use (That's why these bugs happen), it's them who aren't going to get any fixes :D
Still cheating yourself... please note that just two persons noticed the regression, and only one bothered to reinstall an old FW version and posted the pictures that show you were wrong. If not for that, you'd be still chasing your own tail. So maybe you should think again who is hurting not just himself... this is the main reason that convinced me I'd be better doing it my own way.
It's easier to deal with C pointers than to deal with a guy unable to acknowledge he could be wrong.
-
Damn, I always hit post instead preview and then someone quotes me before I finish the message :-DD
I've been looking at the code for a little.
Is Widget_SetPoint the widget where the temperature is drawn?
Thanks.
Yes
-
Read the *** operation guide :-DD.
I really hate those silly questions everytime because lazy people don't want to read!
Rotate while pressed to use big step.
My bad, I skipped that line it while reading through it for the 3rd or 4th time but I'm glad the feature was already there so thanks for that.
Gotta say though, if I could blow as much hot air as you do on a regular basis, I wouldn't need a soldering station.
Your suggestion was added for the temperature increments, i'm waiting for David to review it.
-
located "stand only" bug
happens when i change tip with jbc stand so both stand and no iron are triggered. i know, there is no additional pin for tip change shutdown.
-
Nice work Cuboy. I already answered your pull request so you fix a little thing.
Wickated, and what happens next? Goes into standby instead of run mode?
-
Wickated, and what happens next? Goes into standby instead of run mode?
yep, cycles through instasleep(on stand)-stanby instead of stanby-run. encoder dont pull out of this state.
-
Encoder doesn't wake the station in stand mode, it wouldn't make sense.
But should be able to force standby/sleep modes. Neither does when the bug happens?
Btw, cheap clone jbc handles are just crap. They can't stand that power.
Check ou how the contacts have become purple/blue... They made that shitty cut downs, causing hot spots.
-
Nice work Cuboy. I already answered your pull request so you fix a little thing.
Wickated, and what happens next? Goes into standby instead of run mode?
Added the little fixes, i was wondering why the signs weren't showing correctly at the end, that's why...
-
I didn't test the code, just saw it, like in The Matrix... and told you the issue :-DD
I thought it would be better that you learned a bit how it goes, and finished your own work :-+
The current code is a lot cleaner and much more intuitive than before!
I think anyone with some C knowledge should be able to easily mod it.
Remember that screens are dinamically created and destroyed. You won't see the real ram usage at compile time.
So when adding a new screen or adding widgets, you should debug the memory allocation.
You have a define in main.h to enable that. After that, add the variable max_allocated to the variables watch window or live variables.
It holds the max ever allocated value since system boot. Run through all screens, menus, and then check the value.
You can also check the current allocated memory by reading mi.uordblks.
They get updated afer every malloc/calloc/free call.
The system reserves 4KB for the heap. The current heaviest screen is system, with 1.83KB usage.
-
I didn't test the code, just saw it, like in The Matrix... and told you the issue :-DD
I thought it would be better that you learned a bit how it goes, and finished your own work :-+
The current code is a lot cleaner and much more intuitive than before!
I think anyone with some C knowledge should be able to easily mod it.
Remember that screens are dinamically created and destroyed. You won't see the real ram usage at compile time.
So when adding a new screen or adding widgets, you should debug the memory allocation.
You have a define in main.h to enable that. After that, add the variable max_allocated to the variables watch window or live variables.
It holds the max ever allocated value since system boot. Run through all screens, menus, and then check the value.
You can also check the current allocated memory by reading mi.uordblks.
They get updated afer every malloc/calloc/free call.
The system reserves 4KB for the heap. The current heaviest screen is system, with 1.83KB usage.
That's a nice hack right there, thank you! :-+
-
Encoder doesn't wake the station in stand mode, it wouldn't make sense.
But should be able to force standby/sleep modes. Neither does when the bug happens?
enocder also shifts to stanby-sleep only
-
What do you expect shifting to? You should already know he encoder ledt-rotation it's for entering low power modes.
You can't enable any higher power mode with the encoder while in stand mode, in any case you need to remove the stand.
If the sleep/standby timer expired while the handle was put, you need to put the handle in for a moment to reset the state.
You are not supossed to use low timeouts for stand mode, that's more like a safety timeout, as you normally put the handle in and out all the time.
If by any reasons the handle is forgotten or doesn't make contact with the stand, the timeout will be still counting, entering sleep/standby.
Stand mode works perfectly here. I can remove and put the tip a thousand times.
Of course, it goes into sleep when there's no tip, showing NO IRON error.
Do you want to exit sleep mode when you dont have tip? Does that make any sense tyo you?
It returns to normal mode when the tip it's plugged back.
Please take seriously what I said, make proper reports. Not just "hmm it does something strange".
Test it, what, when and how it happens and then report. Otherwise I'm gonna start blowing hot air again ;).
-
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.
Do you like the feature? Any feedback?
As per testing the new version (which none of the core code has changed) I see that testing temperature plot, with BC3 it's a little spiky (that is in 450ºC), less stable, even at 320º or 180º you can appreciate some oscillations. For me, the "new PID" algorithm was on point, what is the feedback of other users regarding the new PID algorithm? I have seen some comments here that it was less accurate and had more spikes but for me it's inverted.
Logically, it would make sense that new PID is better than the old PID, because it has more accuracy. More variables are taken into count, which makes much more sense. But I could also be wrong, I don't really know.
Take this as an opinion, i don't care about accuracy as long as it works, we're talking about constant 4-degree oscillations at max power (450 ºC).
-
Stop blaming the pid, there were a lot more changes in filtering, also in the PID values. You can have 100 pid algorithms, all will do terrible with the wrong settings.
I won't move a finger until you all test the other versions and propery report which one worked so amazingly well.
-
Stop blaming the pid, there were a lot more changes in filtering, also in the PID values. You can have 100 pid algorithms, all will do terrible with the wrong settings.
I won't move a finger until you all test the other versions and propery report which one worked so amazingly well.
Okay okay testing testing.
-
Tested version 10-08-2021
Cal settings are the same in both actual version and 10-08-2021.
250: 1110
350: 1799
450: 3500
The image is from 10-08-2021 version
Honestly, i tought it was better, but it seems worse.
-
Tested version 10-08-2021
Cal settings are the same in both actual version and 10-08-2021.
250: 1110
350: 1799
450: 3500
The image is from 10-08-2021 version
Honestly, i tought it was better, but it seems worse.
Test the 31-07 or the 2-8 Please
-
Tested version 10-08-2021
Cal settings are the same in both actual version and 10-08-2021.
250: 1110
350: 1799
450: 3500
The image is from 10-08-2021 version
Honestly, i tought it was better, but it seems worse.
Test the 31-07 or the 2-8 Please
Will test right now
Edit: 2021-08-2c (Last build before switching to new PID) testing
Same cal settings, real temp is 230 while as the other it was around 450.
-
Cal settings have nothing to do with the pid. As I said, don't calibrate every version, it's he same thing, just restore the values from a previous calibration.
-
Tested version 10-08-2021
Cal settings are the same in both actual version and 10-08-2021.
250: 1110
350: 1799
450: 3500
The image is from 10-08-2021 version
Honestly, i tought it was better, but it seems worse.
That's exactly what pissed me off.
People saying "old was better".
David rolls back. Huh not better.
David restores again.
Hmm old definitely better.
David rolls back again.
No ,not good.
David throws the soldering station 100m alway, crunches the computer table, eyes injected in blood...
Damn it, test the damn versions and stop losing my time! :-DD
Try the oldest first. But again, if I only get feeback from 2 people, restore the code, and then I get feeback from 10 guys saying it's worse... :palm:
I'm taking the break now. Will come back in a few days... And see what's going on :D.
-
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.
-
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.
-
Cannot test 31-07 as it gives me errors on compilation, can someone please point me to it? Thanks.
-
:palm: Why did I made a firmware list then?
Damn, do you see why i'm burning out? :-DD
-
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 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/121375fc1dbd8f0c5800a8e9d2fb5a4b286fcff5) (Agressive PID?)
2021-08-01 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/a09f40c511964767819770d808fe82a9d3a407e9) (Reduce PID and filter values)
2021-08-2c (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/96f40ef43ea0b23e9c83fdb3638fa87a90b37e40) (Last build before switching to new PID)
2021-08-04a (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/1fe5860aa2ad832a0b72192378c2ed60146a2198) (Last build before adding new filter method)
2021-08-04b (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/d1c1aa6b58f4566e70feb4a3a4a9ac01b143491e) (New filter method)
2021-08-05 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f1a4cc7f849ca86a26d58739639831f1a1e05fc0)
2021-08-06 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/44894d8a440a201cdf6ca0631806be97473698d1)
2021-08-07 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/30e00692dae2469dcbe576dbf09e22edeee68554)
2021-08-10 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f7db75fab41260d25ed44d445df1db876fd4663d)
2021-08-11 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/1ae831a30f4eaae2b4f478df59647b0cee525e45)
I dont see 31-07, am i crazy?
Will test 01-08
-
If you're a KSGR v3.x:
-
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
-
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 :D.
2021-07-31 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/22d5382a1b0ea991fcbb7e221a6f947274fbaeae)
To download any build, just check the git log (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/master).
You can see the dates and the commit messages.
You know these are "Updated builds" ;)
-
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 :D.
2021-07-31 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/22d5382a1b0ea991fcbb7e221a6f947274fbaeae)
To download any build, just check the git log (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/master).
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
-
31-07.
-
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.
-
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.
-
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?
-
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.
-
Sure! You're doing a nice job :-+.
-
I agree. I encourage your work and will support whatever you need. :-+
-
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!
-
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...
-
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. :palm:
-
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.
-
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. :palm:
Really? I'm also mechanic, electrician, computer technician, even farmer :-DD
-
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
-
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).
-
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?
-
Nice testing :-+
Huh, why do I remember everyone complaining with the 110 pid settings? ;)
-
The problem here is that screen processing is very fast, so you won't acumulate 2 steps, it'll process them almost in real time.
Instead of hacking around, apply the time diff method to the encoder functions, increasing the steps by 2 instead 1, that will trigger the big step in the widgets processing .
Well, before modding widgets.c, I changed it few weeks ago. I'll revert some code to make it work, let me check that tomorrow.
-
The problem here is that screen processing is very fast, so you won't acumulate 2 steps, it'll process them almost in real time.
Instead of hacking around, apply the time diff method to the encoder functions, increasing the steps by 2 instead 1, that will trigger the big step in the widgets processing .
Well, before modding widgets.c, I changed it few weeks ago. I'll revert some code to make it work, let me check that tomorrow.
It's more like 1 fast- 2 slow- 1 fast kind of thing. If you want them to accumulate over a period of time, it's just increasing the time differential so when a fast increment is detected, the next ones are also read as fast increments, so it will be more like fast-fast-fast-some time-slow.
Will wait for tomorrow and see what is reverted.
It's a little bit hacky in the sense that I'm taking the existing code (rotate increment with a click) and using it in my case. I'm not doing much.
I see what you're saying, you want incremental changes to be "constant", so when a big increment is made, all the next increments are big increments until timeout. Will play with it a little more and see if I'm able to make it.
Thanks.
-
What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.
I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope :-DD
Keep it up :-+
-
What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.
I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope :-DD
Keep it up :-+
I got it there, or almost there, I just need to tweak some things and it will be it.
Surely the video of the example helped a lot.
Thank you, at least i understood i was doing it the wrong way.
-
What I mean is very simple.
The encoder function scans the encoder pins at 1KHz.
I only need to save the last step time, and check how many time has passed when the next one happens.
Ex. Less than 50mS from last one will trigger big step (by increasing step counter >1).
Otherwise, increase only 1.
Widget process input uses (used) normal step value if step counter is 1, or big step if greater.
I know there are a lot of things easy to do, but as I said, I lost interest.
Will fix these last things and little else.
At least these are my current thoughts, who knows in the future.
You are free to fork it and keep working on it, I will happily help you to get started, because you know your things, this is not like explaining to a concrete wall, which is the most common thing, "I don't have a clue about programming, electronics, or anything, but please explain everything".
(Hot air enabled) Nope :-DD
Keep it up :-+
I think now it's on point, much better than before.
It behaves just like in the video.
https://youtu.be/w0nZCK7B-0U?t=1382
-
Nice testing :-+
Huh, why do I remember everyone complaining with the 1q0 pid settings? ;)
Thank you. I finally did something good :-+
What did you mean by "1q0 pid settings"? What is that?
-
110* :D
Before It was 40..60 kp or something like that.
People complained about stability issues after that.
-
110* :D
Before It was 40..60 kp or something like that.
People complained about stability issues after that.
Aha, ok :-+
But it wasn't me complaining. I have different PID settings for different tips. In case I will have time I will check the one with the lowest Kp that wasn't working above 50... or even 45. It is a tip problem. At least on mine!
I followed your advise on how to set PID settings and it worked great so I didn't even try default settings just the ones I tested that worked for me.
That is even why I suggested PID settings to start with are 45-0-0 and do that for every tip you have.
-
Added big step support at the encoder / widget core level (Like it was ages before).
I had to remove that and use the click and rotate thing because I had found some kind limitations back then. I don't remember why. Or maybe a very silly mistake :D.
This firmware has had a lot of back and forths due that. First hittting a wall, remove/disable the feature to keep it working, and then restore the feature when the workaround was found.
Cuboy, your way depends on how quick/often the screen is processed, so it might behave differently in 36MHz and 64MHz speeds, also it will only work in the main screen.
Now everything in the system works that way. I must confess I never liked the click and rotate thing...
I committed directly through the web while I figure out how to make git working again.
Simple user/password was deprecated and git token is not working for me, neither ssh keys.
Check out the commits:
widgets.c (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f5e8a0af8a3a66edce86955783509fd87e743a28)
rotary_encoder.c (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/e60e63fef5fbb2959fcb40199f13ebda9e38f610)
-
Added big step support at the encoder / widget core level (Like it was ages before).
I had to remove that and use the click and rotate thing because I had found some kind limitations back then. I don't remember why. Or maybe a very silly mistake :D.
This firmware has had a lot of back and forths due that. First hittting a wall, remove/disable the feature to keep it working, and then restore the feature when the workaround was found.
Cuboy, your way depends on how quick/often the screen is processed, so it might behave differently in 36MHz and 64MHz speeds, also it will only work in the main screen.
Now everything in the system works that way. I must confess I never liked the click and rotate thing...
I committed directly through the web while I figure out how to make git working again.
Simple user/password was deprecated and git token is not working for me, neither ssh keys.
Check out the commits:
widgets.c (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/f5e8a0af8a3a66edce86955783509fd87e743a28)
rotary_encoder.c (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/e60e63fef5fbb2959fcb40199f13ebda9e38f610)
That is something I didn't understand yesterday, but now it makes sense, the higher the frequency of the screen is processed, the faster you will need to rotate to make a big step (Is that right?). And yes, it would only work for the main screen.
In the code, there's something i dont understand which is abs(state->Diff) > 1, what is exactly that?
The code in rotate_encoder.c is almost the same logic as I used (You're using the last step, which is pretty much what I was trying to do).
Trying this new build works the same as it did before which is nice. And now we have fast encoder rotation for everything.
As you see, in the click and rotate thing i just made few lines of code, not much. It was just the hours going around the code trying to understand what was happening.
Thanks.
-
Re_Get function computes how many steps have passed since the last call and writes it to Diff var.
That way you won't lose steps if the processing is slow.
Diff can be positive or negative, depending on the direction.
I need to know the step number, regardless of the direction, that's why abs (absolute) is used.
Check rotate_encoder.h for RE_State_t structure description.
Yes, there aren't many other ways.. store the time and compare it, nasa science :D
You don't exactly know how often the screen update is called, the screen drawing will take more or less time depending on the widgets, causing a lot of jittering.
You needed 80mS because the whole screen is dma-erased and redrawed when the main screen is changed, it's faster than clearing and redrawing each widget, and needs to be done because some widgets slightly overlap, so updating only one would partially erase other nearby widgets.
But if I changed or removed a widget, that time would change, also if the CPU was faster or lower.
Working at the encoder level, you know it's called every 1mS, no matter what.
-
Re_Get function computes how many steps have passed since the last call and writes it to Diff var.
That way you won't lose steps if the processing is slow.
Diff can be positive or negative, depending on the direction.
I need to know the step number, regardless of the direction, that's why abs (absolute) is used.
Check rotate_encoder.h for RE_State_t structure description.
Yes, there aren't many other ways.. store the time and compare it, nasa science :D
You don't exactly know how often the screen update is called, the screen drawing will take more or less time depending on the widgets, causing a lot of jittering.
You needed 80mS because the whole screen is dma-erased and redrawed when the main screen is changed, it's faster than clearing and redrawing each widget, and needs to be done because some widgets slightly overlap, so updating only one would partially erase other nearby widgets.
But if I changed or removed a widget, that time would change, also if the CPU was faster or lower.
Working at the encoder level, you know it's called every 1mS, no matter what.
Well, we managed to get it working so great job :-+
Now I need to find something else to put my head into, do you see anything that needs changes or could be better implemented? Btw closed the pr request.
As per temperatures, have you thought of anything? Do you have enough feedback to make changes or still?
-
I don't feel it's been tested enough...
Though you and Tugo did a great job, I need the same thing from more users.
By the other hand, others say they've been always happy with the settings.
See the problem here? This is plain stadistics, and I have very little feedback to get something clear :-//
Otherwise the mindfucking will continue. Have you seen how many builds and commits are out there just for testing?
If I keep that route something's gonna explode in my head :-DD.
-
I don't feel it's tested enough yet...
Though you and Tugo did a great job, I need the same thing from more users.
By the other hand, others say they've been always happy with the settings.
See the problem here? This is plain stadistics, and I have very little feedback to get something clear :-//
Otherwise the mindfucking will continue :-DD.
Let's wait then.
If anyone wants to see some feature or has any suggestion please ask for it, I will be glad to try and implement it.
I'm really happy we got fast-slow rotation, seems like a great feature (even though David didn't like it at first, he wanted clicky rotation :-DD)
-
It wasn't that I didn't wanted it. I was just burned out, not willing to spend a single minute on that ::)
-
What are you 2 doing with slow/fast rotate?! :-//
I guess I will have to DL, compile and see for myself :-+
David, yesterday I forgot to write down something it was in my head (I know that also happens :-DD): is it possible that somebody could be having problem with spikes because of a switch power supply on the PCB and/or something that has to do with a power supply on the board? I have Ksger but I don't have problems and my PCB has linear power supply. Could that be a case here?
-
Anything can happen, but how am I going to know?
To develop a firmwar both developer and testers need a decent level of knowledge.
If certain people are geting noise, while others doesn't, the next step is looking at the signals to find out what's going on.
Ex. comparing waveforms from ksgers stations behaving different. I can't do that for you guys.
Sure, I can try different filtering methods, but it's purely based on trial and error, very slow and time-consuming.
-
i guess 08-11 is with so-called old pid ?
so i set to
default filter 75%
10/0.1/x2
120/100/2/0.5/-1
no overshoot on liftoff, fast recovery, fast startup. almost double of the speed when tinning coin (near 7seconds, metcall level of power delivery!) :clap:
bug with stand mode is so hard to catch, just added rc. i guess there is some timer related thing that overlaps 500ms timer of stand pin reading, cuz it should wait for 500ms pin state, but sometimes it beeps very very fast twice or more and bug occurs. there is even no jbc users here so i wont ever bother :horse:
maybe i tweaked pid a bit wrong but it works ok and reliable. much better than old defaults of 20/5/2 or smth
p.s. no noise with up to 10% filter
p.p.s my big donut transformer is on delivery now, so ill build very new station soon with cool big gx20 plugs for reliable connection. ksger based board for sure >:D
-
I tried the new pid again. Definitely not putting it back, adjusting it is **** difficult, extremely sensitive to tip changes, the old is much easier to tune.
The spikes and such are usually filter-related, but also high KD will cause them.
This time I tried a different adaptative threshold filtering, which helps with the noise but also with fast temperature trasients.
I'm actually pretty happy with it, heating up from cold to 360 hits 363-364 and goes down to 360 peacefully.
Of course, here the people will report wild stations attacking the user and running around the room!
I'm still unable to use Github... Will make test builds and upload them here.
-
I tried the new pid again. Definitely not putting it back, adjusting it is **** difficult, extremely sensitive to tip changes, the old is much easier to tune.
The spikes and such are usually filter-related, but also high KD will cause them.
This time I tried a different adaptative threshold filtering, which helps with the noise but also with fast temperature trasients.
I'm actually pretty happy with it, heating up from cold to 360 hits 363-364 and goes down to 360 peacefully.
Of course, here the people will report wild stations attacking the user and running around the room!
I'm still unable to use Github... Will make test builds and upload them here.
Use github desktop, more easy, just clone and ready to play with it.
-
Use github desktop, more easy, just clone and ready to play with it.
I know, but I used the integrated eGit module until now ad I liked it a lot more. Cloning doesn't require user login, the problem comes when commiting.
I think I finally found decent pid/filter values, most people might not realize how hard it is, this time it took 4 hours between setting the pid, new filters and debugging/finding good values!
Edit:
After the 5th... 6th time... I lost the count... finally the damn thing started working with my git user token!
I was about to... :horse:
I added +0.5ºC to the user setpoint to make the display more stable. Ex. 350ºC->Set adc for 350.5ºC
The display will show 350 between 350.0 and 350.9, reducing a lot the dancing between 349 and 350ºC.
New builds available!
(Flies away :D)
-
Nice! Tested on the KSGER 3.1. PID and filtering works with standard settings.
Found something though, after exiting the debug screen, the setpoint remains the debug screens setpoint.
The graph does not follow the setpoint either, see pictures.
Also I got an error: "settings.c line 125"
More testing tomorrow, good night.
-
Yep, my fault. It exited to settings screen before, now goes to main, and there was a check I forgot to update.
That error means there was no free memory left to allocate a buffer to save the settings.
The checking issue also caused a memory leak, not freeing up the pid plot buffer on exit, so if you entered 3-5 times to the debug screen, it probably ran out of memory, causing the error.
For 32F103, I need to enter debug screen ~35 times for that error to happen, I would never have that issue unless I had a very long day debugging! :)
Don't use the debug screen for now, it's already fixed (or I think so) but I'll wait for more feedback before making new builds.
You can't imagine how useful the error reporting feature has become :D
-
Yep, my fault. It exited to settings screen before, now goes to main, and there was a check I forgot to update.
That error means there was no free memory left to allocate a buffer to save the settings.
The checking issue also caused a memory leak, not freeing up the pid plot buffer on exit, so if you entered 3-5 times to the debug screen, it probably ran out of memory, causing the error.
For 32F103, I need to enter debug screen ~35 times for that error to happen, I would never have that issue unless I had a very long day debugging! :)
Don't use the debug screen for now, it's already fixed (or I think so) but I'll wait for more feedback before making new builds.
You can't imagine how useful the error reporting feature has become :D
Can you post a photo of your debug temperature screen? Just to see how stable is for you. I'm testing it.
Can you change fast increments to 10º and slow ones to 1º by default? I think that's better than 20º and 10º.
-
Sure, that's a simple thing.
Asking that, let me guess... are you getting spikes reaching nuclear fission temperatures?
About my debug temperature screen:
360ºC, SET=1790
AVG oscillates between 1787-1793, staying at 1790-1791 most of the time.
RAW (unfiltered) continually moves between 1782 and 1797.
PID plots are completely flat once the temp is reached.
-
Mine is pretty much flat. Sure, that's a simple thing.
Asking that, let me guess... spikes reaching nuclear fission temperatures?
Some spikes. will upload mine once I get my phone working.
Less spiky than the lastest version, so there's that.
Any suggestion to make it flat like yours?
-
https://m.youtube.com/watch?v=IXJkJWSnIBo
Make a video, it's hard to guess what's going on.
Remember my tips are already 1 month old, they get better with the use.
What I'm interested now in is comparing another Quicko.
Because that's what annoyes me the most, same hardware, different results.
-
https://m.youtube.com/watch?v=IXJkJWSnIBo
Make a video, it's hard to guess what's going on.
Remember my tips are already 1 month old, they get better with the use.
What I'm interested now in is comparing another Quicko.
Because that's what annoyes me the most, same hardware, different results.
https://streamable.com/upu6s2
Here's the video. Mine is ksger using 3.x
-
Looks like a noise issue, but it isn't that bad, that's just 3ºC or so. Worry when you have 50ºC spikes :D
Could be the voltage regulator, crappy amplifier, who knows.
If your board has the switching 3.3V regulator, I guess it's the best you can get without modding the board.
This is when I say the same thing again: With ksger fw you couldn't see that.
Soldering will work exactly the same with that little noise - it's just that you can see it -
Adding heavier filtering will affect the response and probably make it worse.
If you want to try:
Iron/Filter settings
Filtering: 90%.
Mid limit: 150
Count: 5
Filter: 90%
But as I say, this might drive the PID crazy.
Isn't this a hacking forum? Why I'm not seeing anyone trying adding more caps, showing scope waveforms...? :P
These ksger don't put a cap in the VDDA pin, neither close to teh amp pins, which is absolute cost-saving crap.
Start by adding 1-10uF ceramic caps there, with 100nF in parallel to improve high frequency response.
Then replace the led with a 1n4148 in direct polarization to gnd, to clamp the voltage to ~0.7V.
That diode is very fast (<4nS) and should help with the spikes.
I would start trying this, hopefully will kill those nasty spikes:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1247691)
-
So, I flashed today's version on my Quicko. I did tweak the calibration slightly, but it's pretty close out of the box. I'm using the default PID settings. I did play with them some to try to get it more stable, but in the end went back to the defaults. The displayed temperature fluctuates about 7 or 8 degrees above and below the setpoint. I'm using 360ºC because that's what everyone seems to be using. The measured temperature fluctuates in about a 4 to 5 degree range. This is my BC2 tip, which is my most stable. Thoughts?
-
Make a video if possible!
That's a slow delay, seems caused by a combination of tip + filtering delay
Try reducing "Filtering" in iron settings, maybe to 60%. For me, the noise is marginally higher.
I get some little 1-2ºC spikes below 35-40%.
Test more tips to make sure you didn't take the crappy one :D
Kd might be doing it worse due the noise, try reducing Kd to 1 or 2 (You too, Cuboy).
Also try different PWM settings, ex. 5ms delay, 50ms pwm.
This is just impossible to get perfect for everyone, each passing day I'm more sure about freezing the temperature screen!
-
I tested all of my tips. This is with filtering set to 50% and Kd set to 1. Here are my tips in order, BC2, D24, Ku, C4, and ILS. I can try to do a video, but I'm not sure what you want to see. The history of the fluctuation is pretty well described by the graphs. Do you want to see the actual temperatures as they change?
-
This is just impossible to get perfect for everyone, each passing day I'm more sure about freezing the temperature screen!
I'm not complaining. I'm sure a fluctuation of 4 or 5 degrees is quite usable.
Edit: I did try 5ms delay, 50ms pwm (ADC time?). That didn't change the size of the fluctuations, but things seemed to go faster on the graph screen.
-
Yes, it goes faster because it's made like that, updating at the same rate as the pwm/adc for better detail.
Those spikes are really weird. Can you take some pictures of the internals?
Try increasing "mid counter" to 4-5, and "Mid limit" to 150-200.
The "mid" name comes from previous testing, at first I added more stages (low, mid and high thresholds depending on the noise amplitude), but in the end it didn't provide any improvement, so I removed the high one.
The low noise (Normally used) is just "Filtering". "Mid filter" is used when the new reading difference is greater than "Mid limit". If the threshold counter keeps rising, and exceeds "Mid counter" , then the filtering will be reduced by -5% everytime as long as it keeps exceeding the limit.
You can also set Mid limit to something very high so it's never used, ex. 500, and see what happens.
Thats all I can explain for now! I have yet to put proper names there. Or might change everything tomorrow, that's why I didn't bother too much.
Enable debug menu in SYSTEM, it will appear in the main system menu. Enter it and set 360ºC.
Check out AVG (filtered) and RAW (unfiltered), what are the variations?
The ADC setpoint is SET(Converted to adc value), PID tries to reach this value all the time, in perfect conditions AVG and SET would match.
I'm starting to run out of ideas. I can't go further without someone debugging these noisy stations...
-
Looks like a noise issue, but it isn't that bad, that's just 3ºC or so. Worry when you have 50ºC spikes :D
Could be the voltage regulator, crappy amplifier, who knows.
If your board has the switching 3.3V regulator, I guess it's the best you can get without modding the board.
This is when I say the same thing again: With ksger fw you couldn't see that.
Soldering will work exactly the same with that little noise - it's just that you can see it -
Adding heavier filtering will affect the response and probably make it worse.
If you want to try:
Iron/Filter settings
Filtering: 90%.
Mid limit: 150
Count: 5
Filter: 90%
But as I say, this might drive the PID crazy.
Isn't this a hacking forum? Why I'm not seeing anyone trying adding more caps, showing scope waveforms...? :P
These ksger don't put a cap in the VDDA pin, neither close to teh amp pins, which is absolute cost-saving crap.
Start by adding 1-10uF ceramic caps there, with 100nF in parallel to improve high frequency response.
Then replace the led with a 1n4148 in direct polarization to gnd, to clamp the voltage to ~0.7V.
That diode is very fast (<4nS) and should help with the spikes.
I would start trying this, hopefully will kill those nasty spikes:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1247691)
If only I had an oscilloscope... Just for the sake of comparing, I would start playing and adding extra circuitry and seeing how it behaves. This would also be a great learning experience.
For now, I have to stick to what I have and follow what you're saying.
-
Does anyone know a socket model number for the STM32 F103 RCT6 - 64 pin, 4x 16 at about 0.25mm spacing...
I've been wanting to do this project for a bit but have a few others going on... so I am thinking of purchasing a few of these chips so that I can desolder the one on my replacement KSGER station, solder the socket on and cut a hole in the top, or side, of the case so it sticks out so that I can swap chips whenever...
Edit: I have board marked OLED-V3.0, in software it reports 3.0 / 3.1 or something along those lines.
I did get pretty lucky with my replacement KSGER - the stm32 chip I have actually has more memory than the original. I do want to see if I can find a way to read the data off the chip, though so I can restore it... but until then I think a socket would be the best bet so I can continue to use it....
If I can't find a inexpensive socket ( some I've seen are around $100 which is crazy ) I could just do a breakout board and then solder the chip to another and just plug the pcb into the breakout and do it that way... It would mean a much larger area for all the pins unless I can see if there is an old cpu socket and cpu I can rip apart and use... that would actually look kind of nifty... But I'd rather have something smaller.
Edit2:
From the previous message by Cuboy quoting a message from DavidAlfa - If you need to know capacitor values, etc... let me know... especially if you have the same board as me... I have a DER DE-5000... I'd probably have to remove the battery - honestly I'd actually be ok with added a header for it... But, it may work without having to undo that... Let me know what readings and what frequency and the position...
Edit 3:
Question: Does anyone know the OLED Model number off my particular KSGER unit? ie: is it color, or just single color? If it is color, I wonder why the colors aren't being used. It would make it much more readable.
-
Cheap socket for tqfp64? It's cheaper to buy another Ksger!
-
i have a couple of the oled's desoldered i replaced with white panels on the ksger 3.x boards. there is no part number on the screen but i can take some pics or show you which i used to replace them.
these are the white screens i used to replaced the blue ones they are pin for pin and just a teeny big bigger. this may give you the info you need also
https://www.aliexpress.com/item/32903968632.html?spm=a2g0s.9042311.0.0.27424c4daX5ARu (https://www.aliexpress.com/item/32903968632.html?spm=a2g0s.9042311.0.0.27424c4daX5ARu)
-
LQFP-64 Socket is it... There are some for $23 I've found, but that doesn't include the PCB / Mating surface so I'd either have to solder all the wires individually, which would be meh but not the end of the world... there may also be one for $15 on ali...
I could also use a perfboard if the pins on the bottom are spaced ok and find a breakout board and make an adapter... it probably would be cheaper just to buy the kit or just the front part as it would likely be around the same cost... The only benefit of this idea would be the ability to quickly swap in and out chips without having to move any of my setup around, etc...
-
:-\ Another minor feature request, add option to use eeprom for storage of settings/misc.
-
https://streamable.com/upu6s2
Here's the video. Mine is ksger using 3.x
:palm: absolutely stable.
-
:-\ Another minor feature request, add option to use eeprom for storage of settings/misc.
Not this one, when the whole firmware is already based on the flash, and some boards have it, others doesn't... Why make it more complicated?
Also, these eeproms are 8Kbit, current settings doesn't fit there.
Just why ask for a feature that is not needed neither affecting in any way the station behavior?
:palm: absolutely stable.
Was that an irony? It's almost perfect!
-
Was that an irony? It's almost perfect!
absolutely no irony. best u can get with pwm psu and pwm instead of ldo
-
Can you change fast increments to 10º and slow ones to 1º by default? I think that's better than 20º and 10º.
After a day of 1/10 steps, all can I say is that's incredibly annoying.
I'll put 5/20, which lets you use reasonable steps yet moving fast when needed.
I've been suspecting this since the beginning. The tips go worse as they age.
I've tested builds back to February. The all do really bad with my current tips.
They just grow grass like StephenR0's.
These tips are just crap, from the start to the end.
So definitely, will have to just ignore that in the display. I don't see other way.
These tips simply change too much between suppliers and during their lifetime.
-
Another full day fighting this |O
New filtering, I think now it's easier to understand, also works pretty well.
Diff means: difference between average and new reading
*FILTER SETTINGS*
- Filter: Coefficient of the filter
- Threshold: Define normal noise level. Diff lower than this will be filter normally. If greater, will increase "threshold counter"
- Count limit: If the threshold counter is below this, normal filter will be used. If exceeded, will start reducing the filter coefficient by "Step down", until reaching "Min"
- Step down: Filter reduction step applied each time
- Min: Minimum filter coefficient, don't go below this.
- Reset limit: If diff greater than this, filter is resetted (ex. Tip removed)
Now let me explain a practical example:
If the normal tip noise in around 20, you set a bigger threshold to have more clearance, ex. 50. Also, if the tip changes too fast, you might increase it a little more.
Now, the new reading reports +100, could be just noise ,or the temp changing fast. The threshold is triggered and the counter increased.
While the counter is below the limit, it will be filter normally, and barely affect the average. You'll need to adjust this depending on how noisy your signal is.
If the next readings is under the threshold, the counter is cleared, but if not, it keeps increasing.
When that counter exceeds the limit, each time the filter coefficient will be lowered, until reaching the min. set value.
Ex. when heating a cold tip, it'll usually be faster than the filter, so if we have a coefficient=90, step down = -5 , min=50, the filter will do 90%,85,80,75,70,65,60,55,50,50,50... and when the readings get normal again, return to 90%.
Anytime a reading is under the threshold, the filter will be restored and the counter resetted.
The higher the threshold and the count limit, the slowest the filter will react. So this always require a lot of testing.
It's easy to have a clean signal by skyrocketing the filter values, but you'll get a slow oscillation caused by the filter response. Though still better than having it jumping around like crazy.
The noise levels can be seen in the DEBUG menu. Set a normal temp (Ex. 350) and check the values in the field RAW. Your noise is highest-lowest. Add some clearance and start testing.
There's nothing the sw can do to improve the RAW readings, that's how the ADC is reading the signal, it purely depends on the external circuitry.
Edit:
The problem is definitely due the tip sensor. It's impossible that they heat up +100ºC in just 1 second, but the sensor does read that.
Tips having little use work better.
So the PID needs to be very responsive, requiring ver narrow adjustments. Its very easy to over or under compensate, both causing spikes and oscillations.
The fact that the PID is able to control it with only 5Hz sampling rate is already amazing.
Opened a new tip, it jumped for 5-10 seconds and after that it worked great. Don't know if I was just lucky or if it's the current filtering doing great.
Current filtering is set at 95%. Seems to greatly cut down the noise, and the adaptative filtering does the rest.
New builds available!
-
Feedback here:
I can say it has improved drastically from the last video, with much fewer spikes, it's almost perfect.I get some small 1 pixel spikes here and there, maybe 2 or 3 horizontally and that's it :o
-
Great! I was about to make my station land somewhere in between Germany and Russia!
What about the response?
1 pixel is just 1ºC, can't even be called noise.
-
What response are you referring to?
Everything is by default. I made a reset.
-
I mean what happens when plugging a cold tip, or touching the wet sponge.
How does it react? The PID is also different.
-
I mean what happens when plugging a cold tip, or touching the wet sponge.
How does it react? The PID is also different.
It reacts perfectly, temp down while on wet sponge, power to the tip goes up, then stabilizes to its set temp. maybe a little overshoot because of extra power (of 1ºC)
Now I don't get any temperature oscillations, the temperature plot is as flat as it can be.
-
My newest tip, opened today only for testing, barely overshoots. However it seems the sensor bond loosens with the time.
The firmware version from the video shown in Github, which looks perfect, now overshoots and oscillates a lot using the same tips I used to make it, it's just that the tips have worked for few weeks-months and no longer behave the same.
My older tips are now very nervous and overshoot by just looking at them.
I don't really care, it's just for 1 second and then the thing completely flattens out .
Also, it seems moisture affects the tips, after being unused for few days, or just few hours but having cleaned it in the wet sponge, at first they will oscillate a lot.
After few seconds they suddenly stop and start working perfectly, like if there was a switch somewhere.
After cooling the tip and plugging it back it still behaves correctly. But tomorrow might happen again.
Things to take in count when blaming the fw ;)
-
So, with today's firmware, after a full reset, I get a steady oscillation about 5 above and 5 below the set point. But if I set the filter down to 80%, things settle down quite a bit. It jumps around, but in a much smaller range, not the steady oscillation as before. I tried 70% and 60%, but there was no improvement. The measured temperature stayed in about a 3 to 4 degree range. Then I tried my wild tip and things were more, well, wild. :) So, I tried what has settled it before. I set Kd to 50 (what I believe to be a very large number). This tightened up the cycles quite a bit. The pattern of these cycles is that double top and double bottom that we've seen before with my hardware. But the range was about 4 degrees, even for my wild tip. Now, the measured temperature cycles at most 2 sometimes 3 degrees. These settings seemed to work for all of my tips. I would say this is quite usable.
Can you help me understand the effect of this rather radical value of Kd? I'm not really sure what I'm adjusting. And since adjusting the new filter seems to have an effect, do you have any other filter parameter suggestions that I could try?
-
If previous reading and current one changes a lot, Kd acts like a brake or gas pedal on fast changes, like a damper.
But too much will cause it to react at every little noise.
Instead reducing the filter, try reducing the threshold a bit, so the filter self-regulates.
You can also increase the step to 5% for faster response.
Wickated, today I saw the bug you said, I didn't was in stand mode, so it must be a global issue.
When plugging the tip, it went from sleep to standby, could be waken using the button but it kept happening every time I removed the tip.
However after connecting the debugger I wasn't able reproduce the issue again.
I don't see anything strange, but these small little bugs are usually hard to catch at eyesight.
Try to find out what's triggering it. Could be happening after running for a long time, or after entering certain menu...
-
So, I put the filter back up to 95% and started to experiment with threshold and step. If I understand the setting it's "step down" and you must have meant -5%. I reduced threshold to 30, then 20 and still had some cycles. Then I read your explanation of the filter parameters again. If I understand correctly, we should first see what our noise range is and set threshold larger than that. So, I went into the debug screen and observed raw to cycle in a range of 50, although the extremes weren't that common. So, I set threshold to 50. I'm going to experiment more, but this doesn't look too bad. But I still have Kd set to 50. I'm going to have to play with that.
-
Yes, not an easy thing when you're having noise.
50 is a lot of noise, however the oscillation shouldn't be considered as noise, it's another thing.
Noise is... 1890...1882....1895, random, fast changes between readings.
Try to find a temperature where it doesn't oscillate and measure the noise there.
The current filtering is by far the easiest to adjust from all, yet more useful and capable.
If you don't understand something just ask.
I don't have degree in technical english grammar and vocabulary, so it would't be anything new if I wrote something wrong ::)
-
Does anyone know a socket model number for the STM32 F103 RCT6 - 64 pin, 4x 16 at about 0.25mm spacing...
I've been wanting to do this project for a bit but have a few others going on... so I am thinking of purchasing a few of these chips so that I can desolder the one on my replacement KSGER station, solder the socket on and cut a hole in the top, or side, of the case so it sticks out so that I can swap chips whenever...
Edit: I have board marked OLED-V3.0, in software it reports 3.0 / 3.1 or something along those lines.
I did get pretty lucky with my replacement KSGER - the stm32 chip I have actually has more memory than the original. I do want to see if I can find a way to read the data off the chip, though so I can restore it... but until then I think a socket would be the best bet so I can continue to use it....
If I can't find a inexpensive socket ( some I've seen are around $100 which is crazy ) I could just do a breakout board and then solder the chip to another and just plug the pcb into the breakout and do it that way... It would mean a much larger area for all the pins unless I can see if there is an old cpu socket and cpu I can rip apart and use... that would actually look kind of nifty... But I'd rather have something smaller.
Edit2:
From the previous message by Cuboy quoting a message from DavidAlfa - If you need to know capacitor values, etc... let me know... especially if you have the same board as me... I have a DER DE-5000... I'd probably have to remove the battery - honestly I'd actually be ok with added a header for it... But, it may work without having to undo that... Let me know what readings and what frequency and the position...
Edit 3:
Question: Does anyone know the OLED Model number off my particular KSGER unit? ie: is it color, or just single color? If it is color, I wonder why the colors aren't being used. It would make it much more readable.
We've got pretty much the same version, mine includes the power circuit with it. Do you have schematics for it?
Now the temp graph is stable and i have zero oscillations, which is pretty awesome. If you have the same version as me test it.
-
For the schematics, check out Dreamcat4's repo. I think this one (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0) is your model (Black pcb?)
-
I am having two issues connecting/configuring a KSGER 'v2.1S' Original Version (Green PCB) controller for a JBC T245 handle.
1. The controller is saying "NTC reading high" or "NTC reading low" depending on if the "wake" signal is floated or grounded. The controller stays in "sleep" in both cases. The "wake" input pin is connected pin 17 on the microcontroller, just like in the schematic "iron.pdf". Could the pin setup of the MCU be swapped somehow?
2. The level on the non-inverting input to the temperature sensor OP is around 0.2 V during the measurement pulse, which means the output of the OP saturates. Using an oscilloscope, I cannot see much change in the OP input level when heating the tip with a hot air gun. Note that R5 in the schematic is 247 kOhm on my board, just like on Tugo's.
I have cut the trace between the heater and R12, installed R13 (not originally on my board) and replaced the LED D1 with a Schottky diode. The C245 TC is connected between R13 and R12. The firmware is 2021-08-19 from /BOARDS/KSGER/[v2]/STM32SolderingStation.bin.
A similar board without modification runs fine with T12 tips and firmware from 2021-07-07.
Any suggestions what is wrong?
Thanks in advance!
-
In Ksger v2.x firmware:
Pin 16 Wake
Pin 17 NTC
Pin 12 Tip temperature
That schematic (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.0-and-v2.1-original/r1/iron.pdf) might incorrect, all the rest is the same as others Ksger V2.x.
It's a bit strange that they only changed that, requiring firmware modification.
Check the 2.1S schematic (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf), the stm32 pinout is the same, only these labels are swapped.
Try reversing them. Also post pictures to see what's going on.
You won't see much at the input, the T12 sensor will output 8mV at 400°C.
Check the output, it should output ~600mV per 100°C.
The T12 output doesn't work well below 90-100°C.
-
Great! I was about to make my station land somewhere in between Germany and Russia!
u mean Poland ? ;D
ill probably spend all day tomorrow building new station with this cool looking 4kg tiny cake
-how many board modification u do?
-yes
(probably it would be faster to just make plain pcb from the scratch)
-
Acosmetic one. Not important so you can ignore it, if you find it stupid.
Under system/contracts maybe a better option would be to add just a scale from 1-10 instead of showing 255,230,205,......
-
Hello DavidAlfa,
Thanks for the quick reply.
The iron.pdf schematic matches my board with respect to WAKE (pin 17) , TEMPAMB (pin 16) and TEMPIRON (pin 12). I will try reversing WAKE and TEMPAMB tonight and post pictures.
Roughly what signal level should I expect on the OP input during sleep and operation with a C245 tip? With the current input level to the OP, the TEMPIRON (tip temp) saturates at 3.3 V during the short pulses in sleep. I may have messed up something when modifying the board or connecting the C245...
-
Hello DavidAlfa,
Thanks for the quick reply.
The iron.pdf schematic matches my board with respect to WAKE (pin 17) , TEMPAMB (pin 16) and TEMPIRON (pin 12). I will try reversing WAKE and TEMPAMB tonight and post pictures.
Roughly what signal level should I expect on the OP input during sleep and operation with a C245 tip? With the current input level to the OP, the TEMPIRON (tip temp) saturates at 3.3 V during the short pulses in sleep. I may have messed up something when modifying the board or connecting the C245...
board require modification to support 245. u have to cut 24v line and add 1Mom from 3.3v line to opamp input
on tip-handle connector - outer casing (green) - ground, center rim(blue)- power, end pin(red)-tc
-
Don't connect anything before checking what you did.
I believe the problem is your wiring.
You wrote: The T245 TC is connected between R13 and R12.
TC should go between GROUND (which is also ground for the heater) and on the cut trace line going to R12.
How many pins do you have going into the soldering handle? 5? And you don't have 2x ground going into handle, correct? In the original handle you have G and E going to handle and both are ground. One of them (E?) will be needed for temperature reading (TC).
Please make a schematic and/or take pictures and I know it is going to work.
You can also make an old handle with T12 that way it will work with the same board ;)
Maybe that should also be good to do before T245.
EDIT: I just saw what could be wrong... I hope I am correct! If you check schematic here: https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/KSGER%20STM32%20Ver2_1S%20schematic%20rev%202_floobydust.pdf) I don't think everything is clear or I am thinking it wrong. You have JBC 6 pin on the bottom right. That is not what you should look when connecting to the 4+2 pin header for JBC! It is not pin to pin! T12+ must be connected to HTR+, G is connected to COM and JBC is connected to TC+. Shake and NTC must be connected as in the T12 schematic (E as earth should be connected to ground - G because E and G are the same spot on the PCB!). Please check this first and report back. Also wickated told you to use 1M for R13. I don't know if it is ok to use 10M (in the schematic you gave it is used 10M), but David should answer you this. He is the master ;)
-
Under system/contracts maybe a better option would be to add just a scale from 1-10 instead of showing 255,230,205,......
Will look at that.
It's normal that it saturates during the pulses, the ADC is read when the output is low.
10M should work ok, it goes straight to the amp input.
No master in anything!
-
David, come on ;)
You know you are. Just say it :-DD
David, again, thank you for everything you did to this FW (how great it become)! I really mean it. I know a lot of other guys also contribute it but I don't think today a lot of different PCB versions would have this FW if you hadn't come and start doing it. :-+ :-+ :-+
-
Done the brightness stepping. Yeah also I never liked 0-255. I'm not that grumpy, but I have to put some limits from time to time or people will rush with silly/useless/undoable suggestions :D
Wickated, it's been a long way. I feel sorry for the Polish people, probably triggering their ww2 air raid sirens every 2 days "KSGER coming!! Everybody get into the bunker!!".
So sad that only AndyC checked the code and found it :(.
After long-clicking "Auto dim" setting while in edit mode, check what happens when entering sleep mode.
-
---
Could the pin setup of the MCU be swapped somehow?
---
I have had to swap NTC/WAKE pins on two of the green 2.1 boards. The KSGER documentation is incorrect, they just fixed the wiring in the supplied T12 handles.
Isn't this a hacking forum? Why I'm not seeing anyone trying adding more caps, showing scope waveforms...? :P
Right, found an old screen capture from when I was troubleshooting the JCD station:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1248592)
Watching it live one could clearly see that the first ~30ms after PWM off, the opamp output was not stable.
Did mod it a bit, but now it sits in the 'project box'.
Regarding modding, I had an SSD1309 display on one controller, but it stopped working somewhere between v1.10 and recent versions. I couldn't find the cause, any ideas?
These ksger don't put a cap in the VDDA pin, neither close to teh amp pins, which is absolute cost-saving crap.
Start by adding 1-10uF ceramic caps there, with 100nF in parallel to improve high frequency response.
Then replace the led with a 1n4148 in direct polarization to gnd, to clamp the voltage to ~0.7V.
That diode is very fast (<4nS) and should help with the spikes.
I would start trying this, hopefully will kill those nasty spikes:
Looks like something I should try.
My 'Mini' KSGER 3.1 'flat-lines' on the 210819 version. :-+
-
Is that ssd1309 i2c or spi?
The current i2c code is extremely hacked for best performance.
I thought it was going to fail in a lot of stations, but a few months have passed since then and to my suprise nobody has complained.
You should have reported the issue when you found it. Now.. who knows which was the last working version!
Although there are people actually using 2.42" Oled without issues.
-
Is that sss1309 i2c or spi?
The current i2c code is extremely hacked for best performance.
I thought it was going to fail in a lot if stations but seems it's stable, nobody complained.
You should have reported the issue when you found it. Now.. who knows what was the last working version!
Although there are people using 2.42" Oled without issues.
It's SPI, I haven't used that controller for a long time, so I just found out. I'll test some builds in between to see when/what changed.
-
You could start by simply opening the .ioc file and increasing the spi prescaler to something much higher, to discard a frequency problem.
-
You could start by simply opening the .ioc file and increasing the spi prescaler to something much higher, to discard a frequency problem.
Ah! That was an easy fix! SPI Prescaler 2->4 fixed it.
BTW, saw a toroidal transformer above. How well do these controllers do with a linear power supply? Better or worse than the stock KSGER SMPS?
-
Will be mostly the same, with lower high frequency noise, but doesn't justify the high cost.
If the board still has the 3.3v buck converter, it won't improve anything.
Adding proper VDD filtering will do just as fine, see mine :-+
Are you connecting the display through wires? High frequency will mess things up.
If so, shield the signals, ex. use twisted pairs for clock and data (each pair is Signal+gnd), it will help a bit.
Also, play with pin slew rate, too fast might cause resonances, ringing...
Check the spi configuration, gpio, where it says "output speed" (low/medium/high...)
Try lowering that. It's like adding a series resistor, lowering the driving strenght.
-
Will be mostly the same, just less high frequency noise, but doesn't justify the high cost.
Adding proper VDD filtering will do just as fine, see mine :-+
Sometimes the cost can be quite low :) But some caps will be the next thing to try.
Are you connecting the display through wires? High frequency will mess things up.
Yes, since the pinout didn't match, about 100mm wire as it is now.
-
David - my mistake regarding the temperature measurement OP. It is working fine and the output responds to heating the tip with the air gun. For some reason I was thinking the measurement was made during the pulses, even though I know that is not the case...
I have swapped the pins for NTC and WAKE, now the NTC is on pin 17 and WAKE on pin 16. The controller stays in sleep independent of the status of WAKE, but I guess that is since the NTC reading is seen an error?
When connecting a C245, what to do with the NTC input? Now it is left not connected, so depending on if pull-up or pull-down is selected, the controller will say NTC reading high or low. Can the NTC measurement be disabled in the software or shall I use two resistors to put the input it at a fixed level?
I will try to make a schematic and take some pictures, but I am not sure I can tonight and tomorrow I leave town for two weeks, so please be patient.
-
BTW, saw a toroidal transformer above. How well do these controllers do with a linear power supply? Better or worse than the stock KSGER SMPS?
im just tired of acoustic nise my spsu make, even though its decent quality (meanwell). also i have 2 separate voltage lines for 2 controllers, and i wont be limited in power. even if will cost me a tip i just wanna run it at full ~300 watt startup, just for fun.
When connecting a C245, what to do with the NTC input?
just add ntc on board
-
As wickated says. NTC must be somewhere, either in the board or in the NTC.
Any error sets the station in sleep mode, so it's normal
-
Thanks wickated and David. An NTC is on the to-do list for when I get back.
-
I have yet to try using the internal CPU temperature when that happens.
I think I caught the standby bug!
I was lucky, started debugging and happened instantly!
handle_iron loads current_time at the beginning, then calls Iron error check and next checks the mode timeout.
Iron error check sets run mode when the errors are gone.
Set mode updates mode_time when the mode is changed, reading the latest value from the timer.
In only takes few us, but sometimes that was enough for the timer to increase a step.
In that moment current_time was lower than mode_time.
Doing current_time-mode_time caused underflow, rolling the the variable to a very high number, instantly triggering the standby timeout.
I'm working to implement internal temperature, detecting the correct mode when a handle is connected.
-
Added internal temperature reading.
The system will revert to it if the NTC detection fails.
Also added NTC disable option to always use internal reading.
Quicko STM32F072 is beta! I can't test it, the calibrations values, pointers and calculations are completely different.
To test it, just disable NTC in options and check what temperature shows up.
Note: When the NTC is enabled, the system will always try the NTC when the handle is removed, so the NTC error will still appear everytime you remove the iron.
That way you can mix different handles, with and without NTC.
-
i still demand "stabilizer" feature. switchable since ur fw is for customization . u tune ur iron and tick option in iron menu so ~5c oscilations will be negated on display. like everyone else do. u know ull get much less rants about 1 pixel spikes if it would be implemented.
-
Who would this be for? I think the people here would have their eyes open. I'd never turn it on.
-
so transformer based station IS silent. im happy with this. also i still have tasks to do - add filters, cooling, and so on. station works stable, with small ripples on latest fw i shouldnt bother of.
-
has anyone ever seen it start rebooting when you turn the rotary encoder? I just flashed mine with the precompiled KSGER V3 bin. it works but at some positions, the rotary encoder seems to reboot it. Edit I could be mistaken on what's causing the reboot but that's the only thing I am noticing. the MOSFET (TPC8107) that drives iron is getting warm but not super hot.
Edit again. lol. Ok, so I hooked up the O-scope to 3v3 it is at 3.2volt rms. when I turn the rotary encoder it drops to 3.14v while rotating and when it power cycles its drops to 1.28v. I didn't have issues with this on the original firmware so I don't think the LDO went bad.
-
The firmware can't do anything to cause that. You have only a mosfet and a load, how is It going to lower the 3.3v voltage?
When you rotate the encoder (changing the setpoint) the PID reacts quickly and causes a sudden load.
Likely you have a weak power supply or some problem with the filtering/ldo. The 3.3v should be always stable. So probably the 24v are going nuts, affecting everything.
The mosfet shouldn't get hot, even with JBC tips it was barely warm.
If you have a scope, check what going on in the voltages.
-
The 24V line is 24.80V RMS really clean/stable (400/600 mv VPP). I also Just tested powering with my bench power supply and still same issue. So 24v rail was ruled out.
I had not changed any settings. I did think it was maybe some noise from the PSU causing issues so I did throw a random 47UF 50V cap on the 24v line at the control board side earlier. Maybe the LDO did fail? I was reading that my board has a pretty crappy thermal load for the LDO. Attach is a photo. I did replace the original STM32F103 since it was read-protected. I have triple-checked for bridges. I was sure if maybe I got a weird board that's not fully supported. ( the about page on the KSGER firmware said I had HW version 2.0 but the photos matched HW 3.0 and your HW 2.0 firmware did not work with it. I just think it's strange to think the LDO might have just failed at the same time as testing different firmware and that it couldn't be anything else like a pin that's different on this board causing a heavy load. Yes, there is still a small amount of no-clean flux on the board.
Edit: don't take me saying your firmware as if I am upset or blaming. I am really just trying to figure out why it's an issue one way but not the other? I wish I knew a source for my original bin for it so I wouldn't have to swap the mcu again to verify that maybe the LDO did just fail. Oh and the first impression this firmware is awesome! it boots way faster than the original firmware did.
-
I don't really took it like that, just said how is it going to load up the 3.3V line until it drops? Makes no sense.
So either the ldo is working at the very limit of its specs or got damaged.
Thanks, I hope you enjoy it! It could boot much faster, the boot screen is shown for 1 second just to look cool.
Try lifting the ldo output and connecting and amp meter, shouldn't be more than few mA.
Anyways, it would heat up badly if the current was too high, it's directly regulating from 24V, dissipating 0.42W/mA.
5mA(1W) would be already too much, I doubt that small package can get rid of the heat without thermal pads and thick traces.
Typed some funny thing at the calculator!
-
So I figured out more or less what the issue is. So yes it's too much load on the LDO on my unit. (Maybe it's failing). I thought rotary encoder because when it's that's when the load got to the point of reset. It's actually the screen. I turned down the contrast and no more issues. when you rotate the encoder it lights up more of the OLED and guess that load is enough to force a reset.
-
Anyways, it would heat up badly if the current was too high, it's directly regulating from 24V, dissipating 0.42W/mA.
David, I believe it is just 21mW/mA.
About 24V "in" and about 3V "out" (for easy calculation).
Difference on the LDO is 21V.
Power consumption = 21V * "X" mA
So for every 1 mA it is 21 mW of power consumption therefore 21mW/mA.
But it is very small power supply and shouldn't be putting a lot of output current as you already explained.
-
Yep, I typed something wrong :D
-
B2 --- 80 20 0,50 1 0 - 1145 1637 2187
-
Also B2
-
BC2----100 20 0,50 1 0 ----1130 1631 2299
-
Also BC2
-
D16 --- 100 20 3 1 0 ---1147 1658 2209
-
Also D16
-
D24 ---100 40 2,50 1 0 ---1126 1638 2138
-
D52 --- 100 20 3 1 0 ---1105 1590 2215
-
K ---100 20 2,50 1 0 --- 1268 1827 2442
-
Also K
-
KU, this was the best one, but now there are some funny moments ---60 20 5 1 0 ---1067 1665 2375
-
KU wants is best at ADC Period 200 ms; but other tips want it to be at 25 ms. So I'm setting 50/1 as a compromise. BTW, I lowered delay to 0,1 ms without noticing nothing weird in some three or four tips. Last pictures for KU at 100 and 25 ms ADC period. You have seen it at 200 ms on a previous post a couple of weeks ago, and it was on 50 ms on the previous post
-
That's a hell of a noisy signal, that's what makes those teeths.
You might want to increase the filter threshold level a little and/or setting the count limit to 1 or 2, hopefully will filter these small spikes out.
I'm pretty sure they're caused by the poor analog design.
VCC noise, cheap amp, crappy input clamping/filtering...
Here we go again with the "invisible" Ksger firmware benefits :-DD.
Overall, it's pretty ok, think that you might put a lot of effort on cleaning the signal, but at the end, the tip performance might be almost the same.
I hope you read some of the recent details, some tips behave wildly during the first seconds, until they suddenly stabilize, like new tips do.
I blame the moisture, because it no longer does it until the tip is left unused for hours or days.
And for the love of god, use jpg instead png, will save a lot of space and you'll be able to put a lot more pictures before reaching the 5MB limit per post.
PNG is ok for "clean" images like schematics or datasheets with few colours, because it compresses really well avoiding compression artifacts, but for real photos it's not :D
Inserting attached images doesn't work directly, I don't know why.
A "hack" is to upload the pictures, then edit the message, copy the attachtments links and insert them as imagen.
Not the image link, but the attachtment, the link you get from the image name at it's bottom.
-
tatel, what version are you using?
Seems like an older version since the set temperature is not present!
Also what's with the number format?
100 20 2,50 1 0
P I D, ? ? ?
-
Nice catch! Also the plot has 1 pixel offset at the bottom, which I fixed a while ago.
Not really an offset, but the 1st pixel was not correctly drawn, now there's a line at the bottom when empty.
P, I, D Imax, Imin and... tau? (No longer present)
-
There are just 5 numbers. So no tau ;)
But should be an old version, yes.
-
I see 6... Or did I drank too much? (again)
-
groovy :-+
still got some work to do. 78xx stabilizers are just too hot. and maybe ill replace bridge rectifier with mosfet one.
-
tatel, what version are you using?
Seems like an older version since the set temperature is not present!
Also what's with the number format?
100 20 2,50 1 0
P I D, ? ? ?
Yeah, it's FW 2021-08-02a.
Format: Kp Ki Kd Imax Imin --- ADC values
Station is a Quicko. Tips are the cheapest Quicko, too.
I don't know what Imin is for, I see it takes negative values only. Did nothing with it.
Imax: going to 1 from 0,5 helps with the sponge test. Also it puts some 3-4ºC more on my tips. I would say temperature drop at Imax=1 is half the drop than at 0,5. Sponge is gravity dripping wet. By putting the tip in just one place in the sponge, temperature never drops more than some 10º. If I do it wander along the sponge, then in some 10-15s temperature drops 20º or more. A guy can see the power bar going to 100% first, then the big temperature drop happens.
With the fat tips I can set Imax 1,5 without noticing any weird behaviour. D52 with Imax=1,5 seems to be a monster, see video below: coin test, 100 mm Sn60Pb38Cu2 solder, 357ºC, Imax=1,5. Yet I'm sticking to Imax=1, just in case any tip would go red hot. It seems to be good enough for usual cases.
Kp: 60 seems to be a good initial value here. Fat tips usually allow to go further, I did tried 150 in some cases without noticing any problems. Again, I'm sticking to a more conservative Kp=120 max
Ki: it's effects are the more obscure to me, but generally speaking, I didn't noticed any oscillation increase with it in the 20-40 range. Most of my tips seem to like it at 20; but some wants it at 40
Kd: wildest setting, going further than 10 gets me increased oscillation with any tip. Most of the tips want it lower than 5, some really want it at 0,5.
Well, that's all I have to report. I could try some newer version in the future, should there be good reports about it. So far, I'm pretty happy with it. Difference with set point never goes further than 3ºC after stabilization. That's pretty darn good for me. Time to do what I bought this station for.
Thank you all.
https://youtu.be/odDk0jAr4G8
-
Just make a backup of your current flash using stlink, try the new version, if you can't get it working simply put it back.
The new filtering is much better.
Hah, the D52, the only T12 tip actually capable of pushing a decent amount of power! Mine burned down while debugging :palm:
Imax greater than 1 is pretty much useless, that's the Integral acumulator, the PID can't go over 1 actually (0-1 = 0-100%), but so much will cause a lot of overshooting with most tips, likely triggering the Runaway detection in some cases.
-
Hah, the D52, the only T12 tip actually capable of pushing a decent amount of power! Mine burned down while debugging :palm:
wd52 :-/O
just take a look how oscilates untuned unisolder
https://youtu.be/xGWQ4OvsW0Q
-
Fixed a little bug in tip name editing caused by the big steps, there shouldn't be a big step there, it would escape the boundary detection and select random characters.
Also, implemented returning to previous screen using click and decrease. Long click still returns to main screen.
You have something to do: Find a fancy black and white icon for the screensaver. Size must be around 32x32-48x48 px!
-
You have something to do: Find a fancy black and white icon for the screensaver. Size must be around 32x32-48x48 px!
(https://play-lh.googleusercontent.com/kN3Hrnzx2W1Fln0kkmYymfycyU3R4FCjt-3e9hGINPkblk00pEwJFbxOCJ8wW8rA6sg)
-
;)
#define 69a07976a3a3416cb1a1d3ecd311ef6eD78dlskMeAYvbSr3_width 48
#define 69a07976a3a3416cb1a1d3ecd311ef6eD78dlskMeAYvbSr3_height 26
static char 69a07976a3a3416cb1a1d3ecd311ef6eD78dlskMeAYvbSr3_bits[] = {
0xF8, 0xFF, 0x1F, 0xE0, 0xFF, 0x1F, 0xFC, 0xFF, 0x3F, 0xF0, 0xFF, 0x3F,
0xFC, 0xFF, 0x3F, 0xF0, 0xFF, 0x7F, 0xFC, 0xFF, 0x3F, 0xF8, 0xFF, 0xFF,
0x00, 0xFE, 0x3F, 0xFC, 0x00, 0xFF, 0x7C, 0xF0, 0x7F, 0x7C, 0x1F, 0xFC,
0x7E, 0xF0, 0x7F, 0x7E, 0x1F, 0xFC, 0x7E, 0xF0, 0x7F, 0xBF, 0x1F, 0xFC,
0x7E, 0xF0, 0x7B, 0x9F, 0x1F, 0xFC, 0x7E, 0xF8, 0xF9, 0x8F, 0x1F, 0x7E,
0x3E, 0xFE, 0xF9, 0x8F, 0x8F, 0x7F, 0xFE, 0xFF, 0xF0, 0xC7, 0xFF, 0x3F,
0xFF, 0x7F, 0xF0, 0xC3, 0xFF, 0x1F, 0xFF, 0x1F, 0xF0, 0xC1, 0xFF, 0x07,
0xFF, 0x07, 0xF0, 0xC1, 0xFF, 0x01, 0x00, 0x00, 0xE0, 0x00, 0x00, 0x00,
0x00, 0x00, 0x60, 0x00, 0x00, 0x00, 0x00, 0xFE, 0xFF, 0xFF, 0x7F, 0x00,
0xF0, 0xFF, 0xFF, 0xFF, 0xFF, 0x0F, 0xFC, 0xFF, 0xFF, 0xFF, 0xFF, 0x3F,
0xFF, 0xFF, 0x07, 0xE0, 0xFF, 0xFF, 0xFF, 0xFF, 0x03, 0xC0, 0xFF, 0xFF,
0xFF, 0xFF, 0x0F, 0xF0, 0xFF, 0xFF, 0xFC, 0xFF, 0xFF, 0xFF, 0xFF, 0x3F,
0xE0, 0xFF, 0xFF, 0xFF, 0xFF, 0x07, 0x00, 0xF8, 0xFF, 0xFF, 0x1F, 0x00,
};
-
This again? :-DD
-
any of these work?
[attach=1][attach=2][attach=3][attach=4]
-
Anything too "fancy" or detailed will be horrible once scaled down.
Something like that:
-
Find a fancy black and white icon for the screensaver. Size must be around 32x32-48x48 px!
Maybe something like a life "saver" would work
https://www.google.com/search?q=life+saver+icon&tbm=isch (https://www.google.com/search?q=life+saver+icon&tbm=isch)
Edit: Maybe an LCD screen with a Life Saver inside would convey it better.
-
Oh and the first impression this firmware is awesome! it boots way faster than the original firmware did.
Got ya! ;)
https://www.youtube.com/watch?v=IhNqDsbcy2Y (https://www.youtube.com/watch?v=IhNqDsbcy2Y)
-
Nice! I should figure out how to do youtube videos.
-
Updated the documentation to show the current features :-+
-
Greatly reduced PID spikes happening when changing the setpoint by temporary using only proportional for few cycles (disabling integral and derivative).
I've been testing different pictures for the screensaver. Yep, mastershake's pictures don't look good downscaled, they're too detailed.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1253407)(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1253410)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1253389)(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1253392)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1253398)(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1253401)
And the obvious one :-DD
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1253416)
I'm looking here, great source for icons:
www.shareicon.net (http://www.shareicon.net)
Maybe I'll skip this feature, as it's actually pretty useless.
The oled burns out in a different way than old CRTs, the organic light emitting compound degrades with the use, so the screensaver would only degrade it even more, but in a more widespread way, so the burned pixels won't be so noticeable.
Dimming will protect the oled much better.
Maybe disabling the whole screen and drawing only a dimmed static image?
-
I like something with zzzz (like the one from mastershake called download.png - it is a face with zzzz) or just simple word sleep would be just fine.
When you cannot solder anymore you know what is going on :-DD
-
It already shows sleep/standby/boost modes, it's hard to not see it :P.
-
all screen black exept "slp" in its normal place. would definitely save most of oled amd pure spartan style :-+
mine is already burned even on lowest dim setting. only way to prolongate oled - buy module with green color. green oled live 10-100x times longer then blue
-
I recall you were wanting the most extreme brightness, so I suspect you already had burned it even before the dimming feature was added :-DD
The problem is not sleeping with 5% brightness, but the running hours, which use the screen at maximum brightness.
-
I recall you were wanting the most extreme brightness, so I suspect you already had burned it even before the dimming feature was added :-DD
The problem is not sleeping with 5% brightness, but the running hours, which use the screen at maximum brightness.
when i installed fw it already had brightness setting
-
i wasnt sure how they would look just some ideas i found. i agree even something like a simple box that says sleep or has zzzz would be fine if you decide to do it
-
The sleep screensaver in original firmware was in my opinion not bad.
-
Yep, I'd rather have just the current t° floating (or the words "Sleep mode" when iron's below readable temperature) around instead. Maybe it could be pulsating between black screen and minimum brightness for extra efficiency?
As it's shown above, I don't see much benefit to an icon floating on top of the main screen (the same pixels are still constantly lit).
-
Meh, I don't think it's necessary, at 5% brightness it's almost off.
It would be annoying to have something blinking all the time.
As I said before, the big problem actually comes from the normal use, when the station is constantly working.
So, I will skip this.
-
black screen or almost black should be best. icons on top and power bar would burn anyway but they are static, so u wont notice anything. but temp digits change so u can notice burnout. thus in sleep mode "set temp" part of screen should be blank. iron cools to ~50c and digits dissapear.
-
Dude, that's 5% brightness, you'll need years to burn it, don't make me repeat it again.
1h of soldering with the screen at normal brightness is probably worse that 1 day at 5%.
Ksger fw moves things around, but it's still causing pixel wear because it's at full brightness all the time.
My approach is to set brightness to min. , increasing overall lifespan.
-
How about bounced dimmed SLEEP word on the screen? Just the word SLEEP, nothing else on the screen.
You made a test FW with bounced ball. The same, just with a word. Dimmed of course.
-
Bounced temp is better. If it bounces it is already in sleep. So why telling something twice?
-
Bounced temp is better. If it bounces it is already in sleep. So why telling something twice?
:-+
-
Hello,
Sorry, maybe wrong thread but i have a problem with my newly arrived soldering station.
My board is this one:
[attach=1]
The temperature readings are way off on it. In stand by, with ambient temperature around 29 degree the display reads 67-70 degree.
On higher temperatures difference can get up to 100 degree less than the set temperature.
I thought maybe something wrong with original firmware and upgraded to David's latest one (SW: 2021-08-21), still same results.
With your firmware I was able to somewhat compensate with calibration, but i believe it is not a good solution as i am getting over 3300 at 450 degree set point measuring temperature around 400 degree.
Below are values i ended up with:
250 degree -> 1950
350 degree -> 2850
450 degree -> 3300
With higher values than 3300 i get error, as expected.
Does anyone had such problem? is there anything i can do to fix this problem?
Additionally someone in China mixed the wires inside the tip, green and white ones were swapped for some reason, because of that NTC was not working.
[attach=2]
-
The tip sensor doesn't work below ~100ºC, so a completely cold tip will usually read 60-80ºC.
If the ambient temperature reading (Top right corner) is correct, it should be ok.
If the 70ºC issue you said is the ambient temperature readiong, probably you have a 100K NTC instead the usual 10K.
Manually measure the handle NTC pins with a multimeter (Between Ground and NTC) , if you have more than 30-50K, you have a 100K NTC for sure.
Go to IRON -> NTC Menu, set NTC Res to 100.0K and check the result.
Your calibration values look pretty normal.
Please explain better what temperatures are wrong and what are the exact errors you're getting.
In the end, not doing the screensaver. I think people will prefer looking at the station status instead the bouncing SLEEP thing. It'll be ok!
I could modify the charge pump voltage to lower the brightness even more, but that caused issues with some screens in the past, so I'll avoid messing with that.
New builds available!
-
Thanks for looking Dave.
The tip sensor doesn't work below ~100ºC, so a completely cold tip will usually read 60-80ºC.
Well, I have an older station which is HW: 2.1S, SW 2.10 and there, with original firmware the tip temperature gets down to ambient, that's why i assumed that 70 degree is wrong.
If the ambient temperature reading (Top right corner) is correct, it should be ok.
It is, the NTC is working as expected after i switched the wires to correspond the schematics.
Your calibration values look pretty normal.
Please explain better what temperatures are wrong and what are the exact errors you're getting.
I get error "ERROR DETECTED! Aborting..." on values higher than 3300. I assumed that this value is in mVolts so as 3.3V is the maximum opamp can do when powered from 3.3V, it is defined in software to throw an error if values exceed 3.3V. Please correct me if i am wrong in my assumptions.
At schematics i found here and in other threads i can see that for 450degree it should read around 2.25V, which is clearly way off in my case.
[attach=1]
Hope this clarifies my concerns.
In the end, not doing the screensaver. I think people will prefer looking at the station status instead the bouncing SLEEP thing. It'll be ok!
As i own fairly old unit (i have it for 2 years now i think and the station was on almost all that time) my display is completely destroyed now, even with screensaver turned on. In my opinion setting the display as dark as possible during sleep is a good option to have to prolong the life of the display.
-
I bet you're having huge spikes in the readings, usually caused when the iron tip is too new (Read the documentation in Github).
Manually set these calibration values (1950, 2850, 3300) in the tip settings menu (Edit Tips... Select the tip, Cal250/350/450) and save.
It's not the same, but close enough for testing. Then see what happens as you rise the temperature.
If at some point it starts going crazy up and down, might be the iron tip. Try another one, older if possible.
When that happens, set a temperature where it's stable, then increase in 50ºC steps, wait until it become stable and another 10-15s, rise again...
At some point it should be able to reach 450ºC.
AnNyways, that board has a very poor power filtering. Only one capacitor at the ouput of the regulator. And that's all! Nothing for the stm32.
Flash the latest version, I introduced a workaround to avoid the PID spikes happening when changing the setpoint. It might help in these cases.
In your case, better to make a factory reset after updating.
The firmware dims the screen down to the minimum, that's why I don't think the screen saver is necessary.
What's wrong with T12 stations? Is it the semiconductor crysis?
They're asking $40 for only the board, and $80 for a KSGER.
Bought mine for $40, whole!
-
What's wrong with T12 stations? Is it the semiconductor crysis?
They're asking $40 for only the board, and $80 for a KSGER.
Bought mine for $40, whole!
You got ripped off! I paid 27$ with 3 tips >:D
All jokes aside, things from China started to get noticeably more expensive ~2 years before the whole covid collapse. Now with price gouging and new EU customs taxes on top of it, I don't even look at chinese sites anymore. The fun of ordering random crap for 2$ delivered is gone.
-
Well it depends where you look at. KSGER prices were always fluctuating. There is also a problem with chip stm32 shortage.
But you can still get good deals.
I have ordered this one and is including shipping, taxes and overall price is 32€
https://www.banggood.com/groupshopping-item-1911768_1764061.html?rmmds=category&cur_warehouse=CZ (https://www.banggood.com/groupshopping-item-1911768_1764061.html?rmmds=category&cur_warehouse=CZ)
-
I don't know what are your taxes, here it's 21%.
So it's not that much, there're tons of stuff still being cheap.
-
thats just ksger overhyped with cheapwilladforfood bloggers ads
-
What's wrong with T12 stations? Is it the semiconductor crysis?
They're asking $40 for only the board, and $80 for a KSGER.
Bought mine for $40, whole!
You got ripped off! I paid 27$ with 3 tips >:D
All jokes aside, things from China started to get noticeably more expensive ~2 years before the whole covid collapse. Now with price gouging and new EU customs taxes on top of it, I don't even look at chinese sites anymore. The fun of ordering random crap for 2$ delivered is gone.
I feel you :(
-
thats just ksger overhyped with cheapwilladforfood bloggers ads
I don't think that's completely fair. I've done 2 videos on them and was never paid a dime for it (by ksger or quicko). My friend (Jeffescortlx) has done a few videos on them too. his most recent one was sponsored though. they sent him the 2 in one hot/ soldering iron units. They screwed up and sent the wrong hot air handle for it so his video was pretty negative on that. They clearly sent one with a 240v heating element.
they have gone up in price a good bit on the Asian retail sites. Really they just went up to match the amazon price of them. They have been about $80 on amazon for at least 3 years.
I think that is still a fair value at that price but pricing isn't really where I am saying that isn't fair. Most blogs, YouTubers, and such suggesting it are suggesting it as an entry-level soldering station. what would you prefer them to recommend? ts-80? To me, for your entry-level station, it is between the Chinese t12 or ts80/ts100. I think t12 wins it on that solely because it is made to use t12 tips so if the user outgrows the usefulness of a Chinese t12 station they can move up a used Hakko FM203 or something of that nature and still keep all the old tips. Yes I know you can use Hakko t12 tips in ts80/ts100 but the tip to grip to tip is awful if you do that. I personally would not recommend sleeved soldering irons anymore cartridge style irons are much better IMO. so that takes out 90% of the entry-level units like 888D, all the entry level wellers, and such.
That being said I really think people should just go to the used market and start out with a real Hakko, Metcal, or JBC. I got my JBC CD-1D with 20 tips(no joke) and a t210 handle used for $200 locally and you can normally pick up used Hakko FM 202 all day long for less than $200. The used market is really hard to convince noobies to look at though.
-
they sent him the 2 in one hot/ soldering iron units.
that. and after vid is made they resell it on local ebay analog. this type of ad cost 0 (zero) to manufacturer.
-
that. and after vid is made they resell it on local ebay analog. this type of ad cost 0 (zero) to manufacturer.
Oh yeah I know how it works I have a youtube channel as well. He actually kept the unit it's his daily use right now. He just replaced the heating element in the hot air wand.
I'm saying it's not popular because of shills like you think. It's popular because it's a good entry-level unit. People are willing to promote for free because they believe it's a good unit for someone getting started. Your average hobbyist isn't outgrowing the capabilities of either the ts100s or Chinese t12 units for the most part. If you have a better entry level unit in mind let me know. Id love to review it lol!
BTW so you know how these Chinese vendors work. They normally won't actually send you the unit directly. They send you an Amazon gift card or Paypal you the money to order off amazon so that way they get a sold item on amazon, they normally expect a review on amazon also.
-
I also think Ksger is overrated, hyped on the prices and they have done everything possible to save few pennies at cost of quality
Quicko has better power supply (took c245 without problem), way better vdd converter, much better board layout and filtering, quality amps (or cloned MCP6002), which results in better stability and little noise, also they don't put cheaper 32F101/102 versions (actually the 32F072 is better than these, more RAM, more speed), and you could buy the station alone (no handle or tips) for $27-30.
Now they seem to have supply problems, warning their buyers they had to put a CKS32, which is a very legit move instead lying, you can still get a complete kit (blue handle) for 38€ / $45, or the station alone for 29€ /$34.
-
I also think Ksger is overrrated, they hyped on the prices and they have done everything posdible to save few pennies at cost of quality
I was lumping the KSGER and the Quicko together. as Chinese T12s. I thought you were making a broad statement that they are all getting overpriced now... $60 on amazon for the quicko with no PSU at all (ASIN : B07T57CK29). I just use Amazon for the standard on these things because people who are going to promote the thing tend to do it if they can get links for $$. Banggood literally stole $80 in affiliate money from me so they are dead to me!
You are not wrong about hype, in general, I was just misunderstanding where the conversation was going. I thought this was T12 stations are losing there value but IMO you are hard-pressed to find a better entry-level station other than any of the OLED T12s. Under $100. Edit: so yes, My fault I misunderstood what the conversation was about cost.
-
No worries. Yep, still much cheaper than a $300 soldering station.
I've been thinking on adding languages for a long time.
While english is ok for most people, I know it's very different for russians and other slavic countries.
However, you can see yourselves the available space, everything is really tight.
I know nothing about these languages and their symbols, except that "Bomb" (бомба) is very similar to spanish "Bomba" :-DD
I would need to find a proper russian font that fits and looks good in the screen, which is not easy.
It's ok to add other languages too, there's plenty of space.
So, if you want translations, help a bit by seeking the menu labels/buttons/messages and finding something that would fit in there!
I think the fw is actually pretty finished, but I might give it a last push for a proper ending.
-
BTW so you know how these Chinese vendors work. They normally won't actually send you the unit directly. They send you an Amazon gift card or Paypal you the money to order off amazon so that way they get a sold item on amazon, they normally expect a review on amazon also.
my country is nearby china so ppl just write on ali/tao directly with starting words "send me free item_name"
So, if you want translations, help a bit by seeking the menu labels/buttons/messages and finding something that would fit in there!
i can make direct dictionary style translation, how can i make proper font? cuz we actually have weird symbols like Ф Э Ы Я Ю Щ :-DD
im still too dumb to load even load a project in ide, not even compile it
so i renamed menuitmes with stlink direct fw editing :palm:
I think the fw is actually pretty finished, but I might give it a last push for a proper ending.
stand bug still there since 8-04 ?
-
It's ok to add other languages too, there's plenty of space.
Even if you did not have enough space, you could do what they do with IronOS and generate separate language bins.
What I think would be great is if they did a similar thing with this firmware as it did with IronOS (Ralim firmware,) it would be nice if a member of the forum developed a new open source controller board to better replace the KSGER chinese soldering stations (like the $25 Pinecil did to the $50 TS100)
https://www.youtube.com/watch?v=eme_AUayLp8 (https://www.youtube.com/watch?v=eme_AUayLp8)
Maybe something cool looking like this!
https://www.youtube.com/watch?v=F_1m6pLDWBk (https://www.youtube.com/watch?v=F_1m6pLDWBk)
-
The stand bug was fixed some buils ago.
Manually building 10 bins for each model, 50 builds everytime? No way!
Just make the translations, and I'll do the rest.
Changing the font is a child's game. The problem is finding one that isn't too big, too small, too wide and doesn't look terrible when downscaled.
-
Changing the font is a child's game. The problem is finding one that isn't too big, too small, too wide and doesn't look terrible when downscaled.
is it coded same as on symbol displays ?
-
The font could be seen as pack of icons.
Each ASCII code number retrieves a different glyph and that's what it draws.
Don't worry about that, just help with the translation :-+
-
looks cool
i just have to translate stringnmae in \gui\menu.c etc and zip them or add commentary lines or how?
-
But is that ok? Without russian symbols?
Modify the files from drivers/graphics/gui/screens/, once done Zip everything and send it to me.
-
But is that ok? Without russian symbols?
Modify the files from drivers/graphics/gui/screens/, once done Zip everything and send it to me.
just a quick try. symbols are needed. im limited in screen width only ? (words in russian are much longer)
and big signs like NO IRON on main screen are text too ?
p.s. possibly confirm stand bug fixed. got some HUGE overshoot, tweaked PID a bit. imax 0,85 is overkill for jbc, it blasts 50c over settemp on liftoff. i got imax 0,4 for stable little_underload, 0,5 overshoot little
-
I think it was fixed. It's you who must test it and confirm it's no longer happening :-DD
I found a font that might do nice. As I said, you know the available space. If it won't fit, then it's better to leave it as it is...
For testing, type the settings screen options in russian (IRON, SYSTEM, DEBUG, EDIT TIPS, CALIBRATION, EXIT).
-
For testing, type the settings screen options in russian (IRON, SYSTEM, DEBUG, EDIT TIPS, CALIBRATION, EXIT).
(ОБЩИЕ,СТАНЦИЯ,ОТЛАДКА,БАЗА ЖАЛ,КАЛИБРОВКА,ВЫХОД)
found some code example for arduino for u8g2 with good font, dunno if utf8 enable is also needed here
https://github.com/olikraus/u8g2/blob/master/tools/font/build/single_font_files/u8g2_font_unifont_t_cyrillic.c
-
Yes utf8 needs to be enabled (Already done on my tests)
-
Yes utf8 needs to be enabled (Already done on my tests)
very nice u have my cat, now feed him :-DD
i counted 15 symbols in line with selector, 16 without, small symbols looks weirdm so CAPS FTW
-
The characters are not fixed width, so will vary.
This font seems ok for both. There are only few cyrillic fonts!
-
very good. so im running in translation 8)
sent in pm. tried to fit everywhere
-
The fw layout is not designed to be randomly changed, everything is carefully placed, so using a different font causes slight cosmetic bugs.
There are very few fonts supporting cyrillic, so there isn't much I can do.
Still lots of text overlapping, need fixing by changing the labels to something shorter, or reducing the russian font size further.
I still need the translation for calibration screen error:
.CAL_Error = "ERROR DETECTED!",
.CAL_Aborting = "Aborting...",
Check the attached file :-+
-
nvm. errors were caused by overrun protection |O
test fw dont work with tip/handle disconnected
everything else work good. need some fixes to avoid overlaps and better word meaning for SAVE OK buttons etc, some more CAPS for clear view and "strings" translation
-
I translated v1.0 to Swedish earlier this year, so I made an attempt again with the new version. Seems to work well so far. Some tweaks had to be made of course, like adding 'ÅÄÖ' etc.
I added/replaced some caps on a 3.x board which had been acting weird previously. (Random wakeups)
The mod (like suggested earlier in the thread) got rid of some noise on the 3.3V, but the PSU noise still gets through. See attached photos.
Made a mini setup with a KSGER 2.1 + 3.1 controllers. Added audio jacks since I expect MP3 support soon :)
Easy to work with and portable.
And as you can see, the KSGER 3.1 is completely flatlining :)
-
Made a mini setup with a KSGER 2.1 + 3.1 controllers. Added audio jacks since I expect MP3 support soon :)
so u can flash only when powered wth psu? seems ok cuz i dont have any suitable ports in local shops for backplating.
-
nvm. errors were caused by overrun protection |O
test fw dont work with tip/handle disconnected
What errors are you talking about?
Is that a proper error reporting?
"Don't work"? No problem, I'll fix the "no work" problem :palm:
Currently the big NO IRON text won't be displayed because there's no russian symbols, but all others, yes.
Else than that, it should be working normally.
Some tweaks had to be made of course, like adding 'ÅÄÖ' etc.
Made a mini setup with a KSGER 2.1 + 3.1 controllers. Added audio jacks since I expect MP3 support soon :)
Jokes aside, there a lot of blind people using the firmware, or at least they don't know how to read the instructions, asking the same things again and again, so the MP3 could be for voice guidance :-DD.
If you modified the existing bdf fonts to add these characters, then why don't commit the changes?
For a few characters it's ok, but as it needs to be done by hand, it's extremely time consuming if you have to add a lot.
But that's what needs to be done here.
Currently I'm using a different font for russian, it would be much better to modify the current fonts instead.
But ain't just normal letters with accent marks...
Wickated, seems you'll have some work to do.
Time to start compiling and trying the translations,. it's very easy, It just takes a lot of trial to fit everything nicely ;).
Will post some guidelines later.
-
nvm. errors were caused by overrun protection |O
test fw dont work with tip/handle disconnected
What errors are you talking about?
Is that a proper error reporting?
"Don't work"? No problem, I'll fix the "no work" problem :palm:
Currently the big NO IRON text won't be displayed because there's no russian symbols, but all others, yes.
Else than that, it should be working normally.
Time to start compiling and trying the translations,. it's very easy, It just takes a lot of trial to fit everything nicely ;).
Will post some guidelines later.
sorry for that, ill make vid for that.
https://youtu.be/tVBiQWcIcTo
i think i can make project in ide with current guides. but abcolutely no clue how to conpile .elf in .bin
-
Made a mini setup with a KSGER 2.1 + 3.1 controllers. Added audio jacks since I expect MP3 support soon :)
so u can flash only when powered wth psu? seems ok cuz i dont have any suitable ports in local shops for backplating.
Yes, but it was what I had. It works ok though. Open to suggestions for proper SWD ports.
If you modified the existing bdf fonts to add these characters, then why don't commit the changes?
I don't even know what that means :) But of course I could share the modified files. I'll just zip'em if that's ok.
-
I realized something I'm kinda concerned about, so to speak. Since the controller remembers the last set t° after powering up, that means it stores it to flash every time it's changed, right? So wouldn't it be better if current set t° were simply stored in RAM and the default startup t° would be a user defined setting?
Admittedly, I have no idea how NAND durability is on those MCU but my guess is probably not that great. The thing is, I checked availability and price of STM32 yesterday and... it's scary. Now I look at my 1.5$ Chinese fake stlink from years ago like it's precious cause it has a "rare" 20K/128K F103 inside :palm:
-
settnigs are written to flash once per 5sec. in original fw with eeprom they are saved every encoder tick. if u really worrie about lifecycles u can just set longer timeout for write operations
-
I've just tried the new version and things seem to be settling down for good.
I have a few good tips and 2 bad ones, the good tips seem to work fine using the default PID values with no change to system settings.
Good tip:
(https://i.imgur.com/754Hx22.jpg)
Recovering from a load:
(https://i.imgur.com/rsAD6ad.jpg)
Recovering from a bigger load:
(https://i.imgur.com/tobf2m9.jpg)
Now for the bad tips, which used to flucuate like crazy in the original firmware:
Using the default PID values:
(https://i.imgur.com/ze00WVP.jpg)
Reducing the KP, Ki and Kd:
(https://i.imgur.com/MuebnHU.jpg)
PID= 30 20 10 (If I remember correctly) Starting up:
(https://i.imgur.com/XPqeR1m.jpg)
Stabilizing:
(https://i.imgur.com/wur9PIk.jpg)
Problem is recovering from a load takes a lot of time and cycles:
(https://i.imgur.com/ogeaKOZ.jpg)
So I decreased Kp and Ki further, increased Kd a little, here is a recovering from load PID (22, 10, 15):
(https://i.imgur.com/3Xfx0AS.jpg)
I'm very satisfied with the current results, but if there is room for improvement specifically in the load handling part of things please point me in that direction.
Thanks david.
-
Reducing the KP, Ki and Kd
PID= 30 20 10 (If I remember correctly)
so u changed pid to some crazy values from default 18 5 2 and now solved the problem reverting them almost to default ? :clap:
-
Yes, but it was what I had. It works ok though. Open to suggestions for proper SWD ports.
They sell the exact same female plug with 4 poles (https://www.aliexpress.com/item/4000300792563.html). A jack should be fine as long as VCC is on the last pole of the male connector (ie: the last to make contact and first to get out when inserted/disconnected).
settnigs are written to flash once per 5sec. in original fw with eeprom they are saved every encoder tick. if u really worrie about lifecycles u can just set longer timeout for write operations
There's a lot I don't understand/remember when I read code as I haven't programmed a single line since college but I'll take your word for it.
@DavidAlfa My station freezes when trying to enter the debug menu. That is when I go to the settings menu, place the selector on DEBUG, then press the encoder, it just stops there. It doesn't enter DEBUG nor responds to encoder anymore (tried all combinations of long/short press and left/right). I can only switch the station off.
Hardware is KSGER v1.5 running a build I compiled from latest source (as of today).
-
Reducing the KP, Ki and Kd
PID= 30 20 10 (If I remember correctly)
so u changed pid to some crazy values from default 18 5 2 and now solved the problem reverting them almost to default ? :clap:
I don't understand!
Default values are 75 48 12!
-
Reducing the KP, Ki and Kd
PID= 30 20 10 (If I remember correctly)
so u changed pid to some crazy values from default 18 5 2 and now solved the problem reverting them almost to default ? :clap:
I don't understand!
Default values are 75 48 12!
i clearly see defaults of 18 5 2
din or svideo jacks should be ok
https://aliexpress.ru/item/1005001769865560.html
-
Those are defaults for C245 tips.
Values for T12 are different and are indeed 75 48 12.
-
I realized something I'm kinda concerned about, so to speak. Since the controller remembers the last set t° after powering up, that means it stores it to flash every time it's changed, right? So wouldn't it be better if current set t° were simply stored in RAM and the default startup t° would be a user defined setting?
Admittedly, I have no idea how NAND durability is on those MCU but my guess is probably not that great. The thing is, I checked availability and price of STM32 yesterday and... it's scary. Now I look at my 1.5$ Chinese fake stlink from years ago like it's precious cause it has a "rare" 20K/128K F103 inside :palm:
The settings are checked every second, if something changed then a 5s timeout is started.
If nothing else is changed in that time, the flash is updated.
But if you keep changing things, the timeout will be resetted and nothing written until you stop changing things.
No idea about the debug freezing.
Anyone else having that issue? Works perfect for me.
Does that v1.5 have a 32f103?
-
also i showed in vid that fast rotate is slow in adc tuning, on first implementations it was fast.
-
https://www.youtube.com/watch?v=tVBiQWcIcTo (https://www.youtube.com/watch?v=tVBiQWcIcTo)
i think i can make project in ide with current guides. but abcolutely no clue how to conpile .elf in .bin
The encoder direction seems broken?
I see, it's strange. Does the freeze happen when changing IRON settings? Only SYSTEM options? Or only debug setting? Is it really completely freezed? Try long clicking or wait 15 for the timeout.
Remove the tip just in case!.
You only have to click the compile button, when it's done click the run button to program it.
Everything is explained in the video, also in the readme.
I adjusted the step sizes some builds ago, because it was too fast, ex. some options jumped +5, but 50 in big step, the slighest fast rotation would go too far, being extremely annoying.
-
The encoder direction seems broken?
I see, it's strange. Does the freeze happen when changing IRON settings? Only SYSTEM options? Or only debug setting? Is it really completely freezed? Try long clicking or wait 15 for the timeout.
Remove the tip just in case!.
i just reversed encoder pins before it was reversed in fw
frezees when returning to main menu. other freeze variants also shown in vid. only frezees in translated
-
Only when clicking exit?
What happens when long-clicking or waiting so it returns by itself?
-
Only when clicking exit?
What happens when long-clicking or waiting so it returns by itself?
same. it also beeps long if beep enabled. after power cycling ir freezes from start with 999c and beeeep
-
When reporting issues, please be clear!
Does the buzzer issue only happen when changing languages? Does ok if you don't change it?
Is that issue caused by enabling the buzzer? Or happens after setting russian language?
Try long-click in the settings menu, so its skips settings menu, directly returning to main screen.
I can't make it fail, even when forcing 10KB RAM to simulate a 101.
Updated the code in github with all the changes.
I don't even know what that means :) But of course I could share the modified files. I'll just zip'em if that's ok.
What did you modify then? Only trhe strings? The letters you said already existed in the fonts?
-
happens after setting russian language?
this. so i guess its somehow linked with iron detection due to lack of NO IRON
-
If a font doesn't have the character, it will be skipped, won't cause any issue.
Ex. Current russian font doesn't have "Ω" or "°" symbol.
The meny entries simply don't draw these characters.
Same with ambient temperature widget.
-
I realized something I'm kinda concerned about, so to speak. Since the controller remembers the last set t° after powering up, that means it stores it to flash every time it's changed, right? So wouldn't it be better if current set t° were simply stored in RAM and the default startup t° would be a user defined setting?
Admittedly, I have no idea how NAND durability is on those MCU but my guess is probably not that great. The thing is, I checked availability and price of STM32 yesterday and... it's scary. Now I look at my 1.5$ Chinese fake stlink from years ago like it's precious cause it has a "rare" 20K/128K F103 inside :palm:
The settings are checked every second, if something changed then a 5s timeout is started.
If nothing else is changed in that time, the flash is updated.
But if you keep changing things, the timeout will be resetted and nothing written until you stop changing things.
No idea about the debug freezing.
Anyone else having that issue? Works perfect for me.
Does that v1.5 have a 32f103?
OK I get the idea for the settings, I just don't see much value to saving current temperature. I mean, I have a go-to t° that varies if I use leaded/non leaded solder then maybe I change it temporarily because the component is fragile or that corner of PCB is sucking heat. But I want the startup temp to be what works for most cases, not the temp I set for yesterday's plastic connector that would start melting at 250C. Well, that's my opinion and you may or may not share it.
Now, regarding the debug thing, yes v1.5 has F103C8T6. If there's nothing specific to v1.5 that could cause this, it may be the result of board damage on my station. I pinched 2 wires while reassembling the handle the other day and insulation failed. 24V went to the 3.3V wake sensor line. That made the station bootloop, burned a hole in a SMA diode, charred its positive pad and melted the track. I fixed all that and got everything seemingly working again but who knows. :-//
-
Checking the schematics:
https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v1.5-ptdreamer-orig/iron.pdf
Holy crap, who designed the v1.5? That's not how it's supposed to be!
2K2 resistors (R9, R10) provide little isolation against 24V short. The 24V would see them in parallel, connected to 3,3V (stm32 clamping diode)
So 1.1K to the 3.3V line, injecting ~20mA, which is a lot of current for the stm32 and the oled, probably rising the voltage in the 3.3V rail to dangerous levels.
Replace them with 10K, or even 47K!
Also, the diode should be after the resistor, at the side of the stm32 pin, so the resistor limits the current in case of a short, and nothing gets damaged.
Ricktendo also has a v1.5, maybe he can try...
I also thought about that time ago, seems reasonable.
Setting the initial temp, setting the temperature each time you turn on the station it's not a huge pain.
In any case, for 100K flash erase/write lifespan, if you change it 50 times a day it would take 5.5 years.
But yes, not an important option to justify the additional flash wear, also being the most changing option.
Edit: Done. Setpoint is no longer saved. Add new option in iron settings, "User temperature", which is applied at boot.
-
and one more. strings like SHAKE STAND can be translated also or not possible?
-
Yes, everything can be translated. I've just added that:
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/gui_strings.c
Done updating the code.
You can now clone the repository and start compiling and testing the translations.
It's dead easy, just follow the video. Then modify the translations until you get a nice result.
I was checking the Cyrillic unicode block. Damn, 256 characters, it will take a lifetime to modify the existing fonts |O
https://en.wikipedia.org/wiki/Cyrillic_(Unicode_block) (https://en.wikipedia.org/wiki/Cyrillic_(Unicode_block))
-
only 32+32 are used actually U+041x to U+044x. other are for weird slavic languages
cool, ill try to make a build today
-
So only these?
U+040x Ѐ Ё Ђ Ѓ Є Ѕ І Ї Ј Љ Њ Ћ Ќ Ѝ Ў Џ
U+041x А Б В Г Д Е Ж З И Й К Л М Н О П
U+042x Р С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю Я
U+043x а б в г д е ж з и й к л м н о п
U+044x р с т у ф х ц ч ш щ ъ ы ь э ю я
Funny to see russians thinking "weird" about other languages.
Next step: German, requiring 24" screens for they endless words :-DD
-
So only these?
U+041x А Б В Г Д Е Ж З И Й К Л М Н О П
U+042x Р С Т У Ф Х Ц Ч Ш Щ Ъ Ы Ь Э Ю Я
U+043x а б в г д е ж з и й к л м н о п
U+044x р с т у ф х ц ч ш щ ъ ы ь э ю я
Funny to see russians thinking "weird" about other languages.
Next step: German, requiring 24" screens for they endless words :-DD
fixed. only this
best is german with russian accent. actually ppl run with fear thinking ur a casting black magick spell when u just say "daisy"
-
The Unicode thing adds a lot of mess. The bdf editors I found aren't compatible with these encondings. So not breaking my head here, it's a dead end.
I disabled the big "NO IRON" message when russian is selected, showing the small error reporting instead.
This is a only a workaround, I'm not trying to master russian language. Just enough for making it work and people understand it.
I'm sure the're tons of good programmers in Russia ;)
-
i have BIG progress in IDE. i can even import project now :-DD
so i guess now everyone cam make translation and add more languages with ease since gui_string accepts copypaste well ?
-
If it fits in the flash, you can add 185 new languages if you want.
The file is self-explanatory. This all you need to add new languages.
// language indexes and LANGUAGE_COUNT defined in settings.h
const strings_t strings[LANGUAGE_COUNT] = {
[lang_english] = {
...
},
},
[lang_russian] = {
...
},
};
char * Langs[LANGUAGE_COUNT] = {
[lang_english] = "EN",
[lang_russian] = "RU",
};
#define LANGUAGE_COUNT 2
enum{
...
...
lang_english = 0,
lang_russian = 1,
};
Ex. Adding Spanish:
// language indexes and LANGUAGE_COUNT defined in settings.h
const strings_t strings[LANGUAGE_COUNT] = {
[lang_english] = {
...
},
[lang_russian] = {
...
},
[lang_spanish] = {
// Copy & paste structure from other language, modify the strings
},
};
char * Langs[LANGUAGE_COUNT] = {
[lang_english] = "EN",
[lang_russian] = "RU",
[lang_spanish] = "ES",
};
#define LANGUAGE_COUNT 3
enum{
...
...
lang_english = 0,
lang_russian = 1,
lang_spanish = 2,
};
-
wow i made it! im almost a certified senior
developerdesigner now :box:
-
Nice! I'm sure it wasn't that hard ;)
Wtf is this, you wrote "Error 404" :-DD
.ERROR_UNKNOWN = "ОШИБКА 404"
Before start working on it, be sure to download the latest code. I've been changing some things.
I don't think I'll change any more code related to the translations.
You don't need to delete the project and start again, just overwrite the project files.
-
i just didnt found any word short enough :-DD
anyway its not final
no freeze now
-
You were right, the new Calibration big step value was too small. Increased it to 20, now it's much better.
-
You were right, the new Calibration big step value was too small. Increased it to 20, now it's much better.
Good. actually 2 clean setups before = 1 new encoder |O
No freeze now, everything works good. Translation is ok, small "no iron" is not as cool as big NO IRON but is shown (maybe place picture like in bootscreen?), some text is used across different menu sections, so had to improve readability, no error404 now :-DD
so i finalized translation in gui_strings. only untranslated are time units like "ms" "min". how can i commit it?
-
As it's only a file and few lines, just send it to me or post here in .zip.
-
here
-
Nice! Added, made new builds.
Now you have more work: Readme and operation manual! :-DD
Google always has a hard time at translating latin and slavic languages, you get all kind of no sense stuff.
(I'm watching your movements at radiokot)
(https://c.tenor.com/0Gw2YAHJCJsAAAAC/in-laws-im-watching-you.gif)
-
Now you have more work: Readme and operation manual! :-DD
ill make it on friday night :beer:
-
i never ever used boost, but ppl found it is calculated not from settemp, but from starttemp
-
i never ever used boost, but ppl found it is calculated not from settemp, but from starttemp
That seems to be the case, yes. (I haven't used boost a lot either)
Got one of those ~€30 Handskit stations today. Well, the last part of the name literally means 'crap' in Swedish :)
Speaking of Swedish, I've forked the project and done some work on fonts and translation. Maybe, maybe, a pull request will show up one of these days :)
-
Nice catch, I neither use boost, you know for me it's just a dumb thing :)
I forgot to update it when modifying the setpoint code to make it volatile (Not saved on every change).
Fixed.
I also modified the readme, adding how to update preserving the settings (https://github.com/deividAlfa/stm32_soldering_iron_controller#flashing-the-firmware), as it seems most people were wiping everything on every update, which is not always needed!
Edit2: I noticed the station was waking up when changing the tip profile in the main screen. I don't like neither I see any logic on that, so I disabled it.
Also disabled showing the setpoint when cancelling boost mode (Just like when waking up the station from low power modes).
Updated builds.
-
I also modified the readme, adding how to update preserving the settings (https://github.com/deividAlfa/stm32_soldering_iron_controller#flashing-the-firmware), as it seems most people were wiping everything on every update, which is not always needed!
I tried that before but settings ended up being wiped anyway. If I remember correctly there's some check in the firmware that triggers a full reset if settings version doesn't match firmware version or something like that.
-
These programming steps will preserve your settings, but if the settings structure changed, or anything causes a CRC checksum mismatch, the firmware will erase them at boot time.
For example, the translations added a new variable (Language), so a previous version will be wipe, but usually they'll stay the same for a long time.
-
Speaking of Swedish, I've forked the project and done some work on fonts and translation. Maybe, maybe, a pull request will show up one of these days :)
Nice work! Programming seems hard as breathing for you ;).
I answered in the pull request. The code had already diverged and git was complaining.
So I manually patched the code with your changes.
Now, the only remaining thing is adding the extra Swedish characters to the default font building scripts:
- u8g2/tools/font/bdconv/make_font_menu.bat
- u8g2/tools/font/bdconv/make_font_no_iron_big.bat
- u8g2/tools/font/bdconv/make_font_small.bat
The characters (Unicode encoding) are defined with the -m option, ex. -m "32,33,45,46,48-57,65-90,176".
You can use decimal numbers(32,33...) or hex ($20,$21...)
-
Speaking of Swedish, I've forked the project and done some work on fonts and translation. Maybe, maybe, a pull request will show up one of these days :)
Nice work! Programming seems hard as breathing for you ;).
I answered in the pull request. The code had already diverged and git was complaining.
So I manually patched the code with your changes.
Now, the only remaining thing is adding the extra Swedish characters to the default font building scripts:
- u8g2/tools/font/bdconv/make_font_menu.bat
- u8g2/tools/font/bdconv/make_font_no_iron_big.bat
- u8g2/tools/font/bdconv/make_font_small.bat
The characters (Unicode encoding) are defined with the -m option, ex. -m "32,33,45,46,48-57,65-90,176".
You can use decimal numbers(32,33...) or hex ($20,$21...)
Thanks, still a beginner though. New to C and new to Git.
I thought the building scripts were included in the PR, but maybe I made a mistake.
They are here: https://github.com/AndyC52/stm32_soldering_iron_controller/tree/swedish-testing/Drivers/graphics/u8g2/tools/font/bdfconv (https://github.com/AndyC52/stm32_soldering_iron_controller/tree/swedish-testing/Drivers/graphics/u8g2/tools/font/bdfconv)
-
My mistake, you did it right, I missed it.
It was at the bottom of your commit (https://github.com/deividAlfa/stm32_soldering_iron_controller/pull/4/commits/22248be6a7094202b53be058b23a9699e80ad5d1) |O
-
By any chance, does the firmware display Vref when controller isn't powered by the main power supply? I kinda wonder why it displays ~2.1V when powered by stlink even though it should be ~3.3V. Then again, my board's been fried once, so weird behavior could definitely happen.
-
Because you're missing something... You aren't measuring the stm32 VDD, but the power supply output.
If the power supply is off and you power the stm32 with the stlink, it'll read a random value depending on the current that leaks from VDD to other unpowered parts on the board.
Where are your electronics skills? :D
Vref is never used anywhere, not even sampled by the ADC.
-
"Electronics skills"? I've never studied electronics, I'm just a hobbyist with tons of things I don't understand or don't even know exist.
-
I was teasing you! :-DD (In a friendly way)
Good news, I was able to insert cyrillic symbols in the existing fonts, russian looks much better now.
Also the big "NO IRON" label is working now. Loooots of work!
Uploaded new builds.
-
Hi, I finally been able to run calibration and thought it might be helpful if I share it with you.
HW: KSGER v3.1 T12 D24 heater. firmware from 01.09.2021
-
Nice! Every report is helpful! :-+
If you have free time, make some tip performance tests to compare their quality.
I enter the debug screen and set 350°C, then take something hard to solder, like a copper heatsink, heavy plane PCB, and try to solder over it, carefully watching the PWR reading. Water is not a valid test!
Most of my tips didn't go over 25%, the temperature was +-1°C around the setpoint.
Only a small one, D12, reached 34%, even better than the D32 being much larger.
The extra power was very noticeable, although pretty poor anyways.
-
see u talking about debug menu
what units are shown for pwm?
for power ? (i guess power has %)
-
Check your eyes! (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md#debug-if-enabled) (Hot air is coming ::))
The PWM timer uses 5us clock (each step is 5us). For example, for the default 200ms, the timer period would be 40.000 (40.000*5=200.000us=200ms)
PWM is the value compared against the timer counter that generates the duty cycle. So for 50% power, the PWM value would be 40.000/2.
The timer counts always up to 40.000, the pwm output is enabled as long as the counter is below the compare value.
So in this case (For 50% at 200ms), the pwm would be enabled until the counter reaches 20.000. In that moment the pwm is set low, and the timer keeps counting up until 40.000.
Then, it resets and a new cycle starts.
As you rise the PWM frequency this value will be lower, ex. 10ms would be 2.000, 50% would be 1.000.
You can esily see how the pwm loses precision as the frequency increases, although you have a broad adjustment range in any case, from 0.05% at 10ms, to 0,0025% at 200ms.
-
Nice! Every report is helpful! :-+
If you have free time, make some tip performance tests to compare their quality.
I enter the debug screen and set 350°C, then take something hard to solder, like a copper heatsink, heavy plane PCB, and try to solder over it, carefully watching the PWR reading. Water is not a valid test!
Most of my tips didn't go over 25%, the temperature was +-1°C around the setpoint.
Only a small one, D12, reached 34%, even better than the D32 being much larger.
The extra power was very noticeable, although pretty poor anyways.
D24 went up to around 34-36% with set temp +=1°C, ILS went up to 24%.
-
And these are the real numbers!
So they can take 80W while heating up, but they can't transfer so much power!
The record is 28W for now :palm:
Testing a big tip like D52 will be interesting, also genuine Hakko vs "original" Ksger!
-
And these are the real numbers!
So they can take 80W while heating up, but they can't transfer so much power!
The record is 28W for now :palm:
Testing a big tip like D52 will be interesting, also genuine Hakko vs "original" Ksger!
I didn't mention it but I had max power set to 120W as it's what was stated in specs for the station.
I changed it back to 80W and tested again with D24 tip, and the PWR goes up to around 50-51%.
-
Weird. The code only uses the limit when the max possible power is higher than you limit.
If you some math you'll see that 24²/8=72W, so you could set 80W or 500W, it wouldn't make a difference, the power limit would never be applied.
You can see this in the debug screen.
Enter the debug screen, set ex. 350ºC and plug a cold tip while watching the PWM value, it will max out when heating a cold tip, also PWR should be 100(%).
Try this with 80w and 120W, the values should be the same.
But if you set 60W, you'll notice that PWM is now lower.
My power supply outputs 25V, so the power is a little higher, 78W, I can see the limit working when setting 75W.
Are you letting the tip to fully heat up before doing the tests?
When the tip has just heated up, the tip body will still absorb heat for a while.
You can see this: The temperature will reach the setpoint, but the power will be still 15-20%, and slowly decreasing.
When the power stays at 5-10% and is no longer decreasing, that's when you should do it.
-
Sorry, my bad, I didn't change the tip in the firmware back to D24. You are totally right heating cold -> 350 PWR 100 and PWM 40000 in both cases :)
-
Haha no worries.
But anyways, you should know that the power is calculated using the actual limit as base.
Let me explain:
If you set 500W, that's not the real limit, the firmware knows you're asking for more than the system can output.
Ex. for 24V, 8Ω, max 75W, if you set 500W, the limit will be still 75W.
However is you set 40W, the limits will apply.
So if you see 100% power, that's 100% of the actual limit, 75W, 40W, whatever.
You could set 5W, the power would be 100% all the time, yet the tip will take forever to heat, perhabs achieving 300ºC after 10 minutes.
-
Check your eyes! (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md#debug-if-enabled) (Hot air is coming ::))
The PWM timer uses 5us clock (each step is 5us). For example, for the default 200ms, the timer period would be 40.000 (40.000*5=200.000us=200ms)
PWM is the value compared against the timer counter that generates the duty cycle. So for 50% power, the PWM value would be 40.000/2.
The timer counts always up to 40.000, the pwm output is enabled as long as the counter is below the compare value.
So in this case (For 50% at 200ms), the pwm would be enabled until the counter reaches 20.000. In that moment the pwm is set low, and the timer keeps counting up until 40.000.
Then, it resets and a new cycle starts.
As you rise the PWM frequency this value will be lower, ex. 10ms would be 2.000, 50% would be 1.000.
You can esily see how the pwm loses precision as the frequency increases, although you have a broad adjustment range in any case, from 0.05% at 10ms, to 0,0025% at 200ms.
ah that somehow explains why at 500+hz pwm is uncontrollable. its all about amount of digits available. lowfreq pwm bothered me cuz i know that proper mosfet can run up to 10khz without gate shutdown driver. anyway i was bothering only cuz mosfet prefer short pulses of load.
for my setup 10/0,1 x2 i got ~960-980 pwm numbers at 100% power
for wd52 as i remember i got up to 60w real heat drain
jbc 3mm high heat chisel can throw up to 80 watt in copper plate
jbc 10 mm shovel can drain up to 100 watt pure power in copper plate
-
Not only that, as the frequency increases, also does the noise, the filtering becomes less powerful because you're feeding the data much faster.
-
(Hot air is coming ::))
Really??? Tell us more! This would be great ;D
-
Noo :-DD this was a joke someone told me here after I answered something "a bit" harsh (something like "You have the hot air without soldering station").
There's no way I can do that without heavily modifying the hardware, which is not the target of this project :)
-
I started to modify the calibration to compensate the amplifier offset.
That should fix the temperature offset displayed in a cold tip and the setpoint accuracy below 250ºC
-
that was tlaked about. on ad8605 i have zero offset with calibrated 250/250 jbc tip
but i think that this i due to usage of shitty t12 tips that have huge difference in TC temp and tip end temp. ~40c offset. so i think that if ppl calibrate not the actuall tip end but heater outer case temp readings would be better.
-
Nope, you plug a completely cold tip and that's all, no measurement needed, it'll be the same as ambient temperature.
You know a TC can't generate any voltage if cold and hot sides are at the same temperature.
So the ADC value will be be offset from the amplifier (ex.360)
Knowing that, you map the ADC values, ex. 360 will be used as the min. ADC value for calculation, being the ambient temperature. Not 0 as before.
It's done, working nice, needs more testing.
This gave a lot more work than I initially thought, as everything depends on everything.
Also I discovered few bugs here and there, mainly affecting performance and conditions I wasn't using before, few tweaks everywhere...
-
You know a TC can't generate any voltage if cold and hot sides are at the same temperature.
Hi, it's not true,TC is always generating voltage, depending on temperature voltage will increase or decrease...
In turn Peltier elements behave like you described :-)
-
|O Peltiers behave exactly like I said, they are thermocouple devices
They generate voltage when there's a temperature gradient between the cold and hot sides.
Not just because they are hot ot cold. If both sides are at the same temperature, they don't generate anything.
I'm no longer wasting my time arguing these matters. :palm:
-
there are some not bugs but ux features not impleneted like default temp step is 5c , if i change it (ex 10) in system it wont affect iron min/max/user temp steps, they will step in 5c. i know it require lot of linking so its not smth to bother.
cold tip offset detect would be awesome. this should fix low temp accuracy. also i suggest bigger time for stand check. cuz even with small RC it can run-stand when i accidentally catch cord.
and i still demand adjustable on/off feature for DISPLAY temp negation. if u select graph widget it shows everything, but normal temp display could be "sticked" cuz 1-0-9c jumps are a bit annoying. and yes this should be selectable so u should turn it on only when everything is tuned.
-
I'm no longer wasting my time arguing these matters. :palm:
i think u definitely MUST not talk in such a rude way to yet another nobel prize winner who finally invented perpetuum mobile generating voltage out of pure nothing just by reading wikipedia :horse:
-
Not a bug, I'm completely aware of that behaviour, and it's how it's supposed to be.
500ms is plenty of time to debounce the stand, if it changes easily, then it's your handle not making proper contact with the stand...
You don't need any RC, the system ignores the input until it becomes stable for at least 500ms.
You could keep quickly inserting and removing the handle for hours, it would keep the current state.
I don't think I was rude, just what it is, people come from blinking 4 leds and think they're mastered electronics.
I just can't stand getting dumb advices, feels like telling a mechanic if he did check under the hood :palm:
You say completely turning off the screen when sleeping? Not hard to do.
I've been fighting the calibration algorithm, finally understood it (was the last part I never took much time to analyze) and spent the whole afternoon trying to find the best calibration method.
I always have small changes and little 4-5°C offsets, the lower temps keep losing accuracy even with the cold calibration.
I have yet to find out if this is caused by the NTC itself (you cannot perfectly compensate it in the way it's built), or what.
-
i think u definitely MUST not talk in such a rude way to yet another nobel prize winner who finally invented perpetuum mobile generating voltage out of pure nothing just by reading wikipedia
I am glad for you that you have born already knowing everything, and do not need Wikipedia. I belong to others, who learn from mistakes.
-
I don't think I was rude, just what it is, people come from blinking 4 leds and think they're mastered electronics.
I just can't stand getting dumb advices, feels like telling a mechanic if he did check under the hood :palm:
Lots of people can't stand of different things, go drink some sedative to handle things. If you wrote two lines of code it does not allow you to treat and judge people or be prepared to be judged.
If i don't know something it does not allow you to speak with me like this, i can tell 1000 things that you don't know, but i do not treat you like you do.
-
I just said I'm gonna stop arguing when I see that kind of stuff, I see this too often, everywhere.
I understand your point ,sorry! But it was nothing personal against you dude! :-+
Otherwise ... let's say I'd like to have the same filters I use in the firmware :-DD
Added the option for shutting down the screen while sleeping! It's done automatically after dimming, can be enabled in the menu.
New build is close, maybe tomorrow, I'm still with the calibration.
It's pretty ok, I just can't find why it always has a small drift after calibrating. Maybe I'm losing accuracy somewhere.
I already changed everything to use 0.1°C precision, which helped a bit, but still having 3-5°C off.
-
You say completely turning off the screen when sleeping? Not hard to do.
i ment actually thing that screen temp doesnt change unless it bounce out of ex.3c bracket, so digits dont jump(like in genuine jbc screen doesnt change temp shown until it jumps/drops 5c) (but everything else is calculated inside as usual). i know i can switch screen to 1fps mode, but it looks weird a bit. and also know that u added 0,5c for better rounding. that might just help ppl be confident everything is fine.
also switchable screen off is cool too. i have things attached to station power supply so i definetely know its plugged in.
what about ntc - when i changed it to freshly bought 1% precision with known datasheet i think i have much better ambient reading.
-
I'm not that much ***hole. Check this out! (Warning, terrible music! :D)
https://www.youtube.com/watch?v=0eOvVCGLF9g (https://www.youtube.com/watch?v=0eOvVCGLF9g)
-
So I added that too. But I don't think I'll add an option for it.
If the temperature is within +-5ºC from target, it'll show the setpoint value.
The plot graph will behave as usual, showing the real temperature history.
I'm thinking in also adding dimming while in run mode, as the 90% of the time you'll be soldering, not watching the screen.
Edit: Added the option. In any case the screen will only turn off if in sleep mode and iron temp <100°C.
-
huge thanks, ill take a look as soon as possible, cuz currently i have 24/7 workload again for next week. :horse:
also i wanna say thanks again for great job for writing and adjusting all that filter/pid/everythingelse stuff, cuz i just built new station from scratch with unfiltered PSU, just wrote adc numbers and it work like a charm. and oversshots from cold start at 150w to 350c only for less than 10c. while i remeber SteveG vid about pace ads200 that overshooted like 50c at same condition lol.
-
Remember that the overshoot is not real, happens only at sensor level, so nothing to worry about.
-
.SYSTEM_OledOff = "Oled power"
.SYSTEM_OledPwrOff = "Pwr off",
.SYSTEM_Run_Dimming = "Runmode dim"
stands for ?
-
Turning oled off in sleep / dimming the brightness while running.
It's not finished yet, 1st is duplicated, forgot to delete it.
-
Swedish translation of the operation manual underway...this is taking some time.
Meanwhile, I tried the newest changes. Compiler complains about "CalNTC" not being declared etc. More work to be done I guess?
The ADC values for cold tip on my KSGER 2.x and 3.x are 0 and 2, so I don't know where 350 is coming from.
-
I haven't submitted all the code yet, tempsensors and calibration screen are pending, will be updated when ready.
The cold tip reading is provisional and needs feedback.
You can't properly see that value in the existing builds, the debug screen won't go down to 0°C (now it does), so a completely cold tip will get some power (50°C)
You can't trust an instant reading as there's a lot of filtering, so the proper way is set 0°C, insert a cold tip and wait few seconds for the average.
-
.SYSTEM_OledOff = "Oled power"
.SYSTEM_Run_Dimming = "Runmode dim"
stands for ?
if OFF stands for working display, ON stands for display off
SYSTEM_OledOff = "Откл.Экран"
if ON stands for working display, OFF stands for display off
SYSTEM_OledOff = "Пост.Экран"
.SYSTEM_Run_Dimming = "ЗатемнЭкр"
-
if ON stands for working display, OFF stands for display off
SYSTEM_OledOff = "Пост.Экран"
Not entirely clear
Since it will be in the screen control menu, it seems to me to use "Пост. вкл"
-
Stop sneaking into the code you *** impatients! :-DD
I'm changing things back and forth all the time, searching the best layout. Those labels no longer exist!
I'll tell you when it's ready :-+
Edit: Done with the screen dimming. Check these strings:
SYSTEM_Oled_Dim = "Dimming", -> Uses dimMode options
SYSTEM_Oled_Dim_SleepPower = " Slp pwr", -> Screen power in sleep mode, uses existing Off/On options
dimMode = { "OFF", "SLP", "ALL" }, -> Dim mode: Off, only in sleep mode, always (I already translated this, ensure it's ok)
Also:
CAL_InsertColdTip = "Insert cold tip"
But I'm not sure if I'm keeping that option.
Using the cold value seems to break low temperature calibration in the opposite way, hotter than the setpoint, more testing needed |O
-
SYSTEM_Oled_Dim = "Dimming", -> Uses dimMode options
SYSTEM_Oled_Dim_SleepPower = " Slp pwr", -> Screen power in sleep mode, uses existing Off/On options
dimMode = { "OFF", "SLP", "ALL" }, -> Dim mode: Off, only in sleep mode, always (I already translated this, ensure it's ok)
i guess "Slp pwr" should be better named "scrnsaver" or smth with On means screen off in SLP state
-
I've been working with the calibration until now.
Definitely, the main error source is the compensation.
This controllers can't have a lot of accuracy due the design, in fact it seems that using the internal temperature is a little better than the NTC in the handle, which also have noticeable tolerances.
After hundreds of tests, I think I've made a decision.
I will use only 2 point calibration: 250 and 400°C, which are the range of temperatures a soldering iron usually works at.
Below 250°C, I don't care to much.
I removed the cold calibration in the end, it breaks more than it fixes.
The sensor response isn't exactly linear, it's slightly curved, but the calculation is linear, so at the middle it has a little error. The curve changes slightly between tips, too.
I don't think it makes any sense making a complex and painful calibration for what it is.
You'll set 350, and if it's actually 355 or 345, it won't make any difference.
There's a limit beyond the practicity and I think this was it.
Next builds will tell if this is a good idea or not!
-
I could help with Spanish translations, but Spanish is a second language to me and I would not know the technical definition to some stuff.
-
2-point calibration makes the calibration much easier and faster... I like it.
Calibration test :
Target Measured
175 165
200 194
225 223
250 251
275 277
300 303
325 328
350 353
375 378
400 402
425 426
450 449
475 472
Below 200ºC the curve changes a lot, as expected.
As the handle heats up or cools down, the temperature drifts 3-5ºC, regardless of the NTC compensation.
I think 3-4ºC error in the whole usable range (250-450ºC) is more than ok, I doubt professional soldering stations have so much accuracy either.
ricktendo, I could do it easily, I've already tried, but spanish words are too long.
I experimented with sliding text, but I wasn't convinced about the result.
-
SYSTEM_Oled_Dim = "Dimming", -> Uses dimMode options
SYSTEM_Oled_Dim_SleepPower = " Slp pwr", -> Screen power in sleep mode, uses existing Off/On options
dimMode = { "OFF", "SLP", "ALL" }, -> Dim mode: Off, only in sleep mode, always (I already translated this, ensure it's ok)
i guess "Slp pwr" should be better named "scrnsaver" or smth with On means screen off in SLP state
I changed it to " In sleep". So it appears like this:
Dimmer [OFF, SLP, ALL]
Delay [10s]
In Sleep [OFF, ON]
-
Definitely, the calibration gremlins are my station's fault.
The calculation is correct, but little NTC changes affect a lot.
Not only that, when the cartridge contacts heat up and the NTC didn't notice yet, it will also change a lot.
So, yeah, end of this calibration drama. These things are what they are, can't do magic.
I reworked few very delicate smd connectors few hours ago, set at 340ºC, but guess what, it worked great at 343ºC! :D
-
too many calibration points :blah:
350c is only one anyone will need. :-/O
p.s. next step - zero calibration step calibration :popcorn:
"press "hot" when hot"
jokes away - actually all this martyr moves show that u dont really need ultraprecise ntc directly in handle like some ppl do think.
-
I'm broken! Too much calibration stuff/adding/removing/fixing code :scared: :-BROKE.
Finally I found the way to make everything work together.
In the end I returned the zero offfset calibration option.
It's applied to the global profile, not tip-specific, as the error is mostly caused by the amplifier.
How to calibrate:
Now the calibration menu removes the power from the tip, and suppress any errors to let you remove/insert the tip.
The error detection is still active while calibrating (START) and adjusting the SETTINGS.
- If you already ran the initial zero/cal values adjustments, do the same as always: -> CALIBRATION / START.
Now there're only 2 steps: 250°C and 400ºC. Simple and easy.
-If the controller has never been calibrated before: ->CALIBRATION / SETTINGS
Insert a completely cold tip before entering SETTINGS!
The options are:
- Zero set: This widget behaves differently than others, when clicking it will switch between modes:
- Zero set: This is the current system zero calibration value. Click to start sampling the ADC.
- Sampling: Shows the ADC value in real time. When the tip is completely cold, the reading will be stable at a low value, click to capture.
- Captured: Show the captured ADC value. This value is now being used for Cal250 and Cal400 calibration steps.
- Click again to discard the capured value and revert to system stored value.
- Cal 250: Adjust until you get 250ºC. It will be affected by zero set value.
- Cal 400: Adjust until you get 400ºC. It will be affected by cal 250 value.
So, to run the initial calibration, follow in this this order: Zero set(Sampling,Captured) -> Cal250 -> Cal400 -> Save.
The current zero calibration method seems to bring more benefits than issues.
The calibration below <~200ºC will be a little higher, ex. 180°C->187ºC, but allows to track the tip down to ambient temperatures.
Now it's so sensitive that it will detect if you touch a cold tip with your hands.
Please, don't bother me with the translations and such stuff, this is still testing stage.
I'll make test builds in a while and post them here, I prefer to leave the current Git builds as they are.
Edit: Uploaded. This build will wipe your settings!
I also changed the default NTC beta to 3450, was what I was using some months ago.
Now, as always, I need reports with:
- Cold tip readings to find out the default values (Can also be seen in debug menu, set 0°C, check "AVG")
- Calibration accuracy at 200, 300, 400 and 450 (Or more steps if you wish).
-
I hope one day David will say that my ksger isnt pure shit and i never ranted w/o reason
-
KS :wtf: GER?
The day I saw a LED as a clamping device for the amplifier, or only one capacitor for the whole stm32+buck regulator, they lost my respect! ::)
-
I like the new calibration so far. Both the procedure and the results. Made some quick testing this morning, here are the results:
KSGER Calibration values and comparative measurements 210908
Temperatures measured with "KDRST 191"-thermometer
KSGER 2.1 Calibration:
TIP COLD 250C 400C
-------------------------
K 0 1530 2524
D08 0 1428 2808
KSGER 2.1 D08:
SET MEAS AVG
-------------------
200 190 980
300 299 1615
350 352 2067
400 400 2520
450 433 2975
-------------------
KSGER 2.1 K:
SET MEAS AVG
-------------------
200 190 1030
300 293 1647
350 347 1974
400 400 2302
450 449 2628
-------------------
KSGER 3.1 Calibration:
TIP COLD 250C 400C
-------------------------
K 2 1600 2553
D08: 2 1549 2870
KSGER 3.1 D08:
SET MEAS AVG
-------------------
200 218 1070
300 308 1737
400 403 2608
450 437 3043
-------------------
KSGER 3.1 K:
SET MEAS AVG
-------------------
200 194 1085
300 296 1725
350 345 2040
400 394 2354
450 440 2670
-------------------
Looking at these numbers I'm not sure I got the "Zero" right when I calibrated...
-
And what was the zero offset value?
The zero calibration is only used for temps below 250°C.
Well, not exactly, the calculation removes the ambient temperature first.
So if you set 250°C and the NTC reads 40°C, your setpoint is actually 210°C.
Between 250 and 400, the zero offset is irrelevant.
-
And what was the zero offset value?
0 and 2. Don't know if I captured that correctly. Does the firmware use 0 as default now? If so, the above table should be OK.
-
0 and 2? 0 or 2? Can't be both. Yes, default is 0.
So that amp is able to go to absolute zero? Thats good!
You must leave it in "captured", then do the other calibrations.
If you set it back to zero set, you're resetting the captured data.
My Quicko reads 360 with a cold tip...
You posted 2 temperature tables. What's each?
Edit: I see you edited them.
Definitely, each tip has a different temperature curve.
Was the older calibration procedure more accurate?
This is all about the sensor non-linearity.
If it changes so much between tips, the only way would be to add a lot of calibration points.
-
0 and 2? 0 or 2? Can't be both.
So that amp is able to go to absolute zero? Thats good!
Yes, default is 0.
Yes 0 AND 2, but not in the same controller :) It was 0 for the 2.1 controller and 2 for the 3.1 controller.
-
Now we talk, you confused me :D.
The temperature curve is similar to this plot:
(https://i.stack.imgur.com/z2S92.png)
If you take 2 points and make a linear interpolation, you get exactly what's happenning.
You get hotter temperatures when you go under the lower calibration point, also as you approach the mid point, and colder when you surpass the upper point.
I could add a coeficient, but frankly, having such differences between tips and controllers, it seems mission impossible to me.
I think the point on all this is just to have close-enough temperatures, so when you set 320, you get something close, but not 300 or 350.
The cold calibration is a different thing, my Quicko reads 60-80°C with a zero set of 0, so it took a long time to cool down below 100°C, causing the screen to stay on all that time.
I don't mind taking 3 point calibration back, but I first want the the real differences against 2 point calibration.
-
So my unit is indeed messed up...
Cold -- > 389
Cal 250 --> 2220
Cal 400 --> 3360
Idle temperature now seems OK, 30 on tip, 30.6 on NTC and 27 on fluke.
New dimming with option to completely turn the display off is awesome!
-
I installed the test firmware. Then I went into the calibration settings menu and inserted a cold tip. The captured ADC sampling was 51. Then I set Cal 250 to 1200 and Cal 400 to 1900. This turned out to be pretty close. When I went to calibrate, Cal 250 was 1207 and Cal 400 was 1898. Everything seemed to measure pretty close to that. This was all with default values for everything. I still have to tweak things to find the smoothest configuration, so there is some cycling of the temperature that does show up when measuring. I would say about 3 degrees above and below that set point. This was with my D24 tip.
-
screen full off in slp and runmode is awesome feature :-+
wrote adc avg (350+450)/2 numba and got just as close to 400 as i wnted. cool. now only two numbas to rape encoder. :-DD
p.s. nice new "no iron" in russian 8)
got adc offset 10. stand loop adds 30. also as i remember ad8605 is not zerodrift, just very precise and very fast. i guess i should find ad8628 which has almost zero offset.
jbc tips are so precise i can get 1 adc sample unit change with just a breath near the tip.
now i can grow some bacterias in petri with my ksger controller thanks David!
for jbc ad8605 ksger 2.1
was
250 1910
350 2660
450 3460
now
offset 10
250 1900
400 3050
-
Your amp drift is ok, 20adc is just 3°C or so.
The problem is like mine, 360.
I also have a lower amp gain, for 450°C it needs ~2300, so the offset has a deeper impact.
I recall screwing something up few months ago after soldering something related to the JBC, the drift became larger, reverting the mods didn't fix it, and it became part of the family.
I don't want to modify my board,, has suffered all kind of torture during the development, there're damaged pads everywhere, specially in the screen and T12 connections, which need to be desoldered to access the back of the PCB(Where the amp is located).
I asked Quicko for the board only, they wanted 20$, which is a bit wtf when I can buy the whole kit for $34...
You didn't report any calibration results! :-/O
-
You didn't report any calibration results! :-/O
sorry im just abusing manual cal set :-DMM
and had only quick test without actuall calibration cycle.
test was ok - 250c was ~250c, 400c was ~400c
-
I asked Quicko for the board only, they wanted 20$, which is a bit wtf when I can buy the whole kit for $34...
David maybe you or another member could design and make your own PCB better than KSGER & Quicko, selecting and using only the best parts!
-
there is already project for combo station with hot air gun channel,, but i obviously think its fw is much less comfortable
-
I already designed a similar controller (https://www.eevblog.com/forum/microcontrollers/fan-controller-with-pwm-using-stm32-chip/msg3594990/#msg3594990) months ago because I was bored.
(https://www.eevblog.com/forum/microcontrollers/fan-controller-with-pwm-using-stm32-chip/?action=dlattach;attach=1230791)
It's untested, unfinished (NTC on-board), not in my current plans doing anything else with it. The Proteus files are there.
There're good enough controllers. With little modifications (Op-amp, some capacitors, LDO) some ksgers will perform great.
-
I already designed a similar controller (https://www.eevblog.com/forum/microcontrollers/fan-controller-with-pwm-using-stm32-chip/msg3594990/#msg3594990) months ago because I was bored.
(https://www.eevblog.com/forum/microcontrollers/fan-controller-with-pwm-using-stm32-chip/?action=dlattach;attach=1230791)
It's untested, unfinished (NTC on-board), not in my current plans doing anything else with it. The Proteus files are there.
There're good enough controllers. With little modifications (Op-amp, some capacitors, LDO) some ksgers will perform great.
I hope somebody takes it or is inspired by it and does a GoFundMe
-
With little modifications (Op-amp, some capacitors, LDO) some ksgers will perform great.
LITTLE
from this way its just like if i bought only stm32 and pcb.
but if make new controller ill say it would be better to make full new project with bigger resolution display(for better graphics) and dual channel (for tweezers support or 2 handles)
-
I need these translations to make the next builds:
.SYSTEM_Oled_Dim = "Dimmer"
.SYSTEM_Oled_Dim_inSleep = " In sleep"
Max. 10 char:
.CAL_ZeroSet = "Zero set"
.CAL_Sampling = "Sampling"
.CAL_Captured = "Captured"
-
.SYSTEM_Oled_Dim = "Dimmer"
.SYSTEM_Oled_Dim_inSleep = " In sleep"
.CAL_ZeroSet = "Zero set"
.CAL_Sampling = "Sampling"
.CAL_Captured = "Captured"
.SYSTEM_Oled_Dim = "Затемнение"
.SYSTEM_Oled_Dim_inSleep = " Реж.Экрана"
for current off=screen off, on=screen on and dims
.CAL_ZeroSet = "ХолСмещОУ"
.CAL_Sampling = "Замер.."
.CAL_Captured = "Записано"
also there is mistake in big "NO IRON" in russian translation, 1 char missing :'( should be "ОТКЛЮЧЕН"
sry for didnt notice it before, my eyes lie to me sometimes.
-
I need these translations to make the next builds:
Swedish:
.SYSTEM_Oled_Dim_inSleep = " I sovläge",
.CAL_ZeroSet = "Nolläge %4u",
.CAL_Sampling = "Mäter %4u",
.CAL_Captured = "Uppmätt %4u",
-
David maybe you or another member could design and make your own PCB better than KSGER & Quicko, selecting and using only the best parts!
nema 17 stepper motor (http://"https://www.czcymotor.com/product/42-nema-17-stepper-motor/"), nema 17 driver (http://"https://www.czcymotor.com/product/nema-17-stepper-motor-driver/"), nema 23 stepper motor (http://"https://www.czcymotor.com/product/57-nema-23-stepper-motor/"), buy stepper motor (http://"https://www.czcymotor.com/pro_cat/stepper-motor/"), small stepper motor (http://"https://www.czcymotor.com/pro_cat/stepper-motor/"), closed loop stepper (http://"https://www.czcymotor.com/pro_cat/closed-loop-stepper-motor/"), 3 Phase Stepper Motor (http://"https://www.czcymotor.com/pro_cat/3-phase-stepper-motor/"), 2 phase stepping motor (http://"https://www.czcymotor.com/pro_cat/2-phase-stepper-motor/").
-
Maybe, maybe... Maybe someone could send me $1.000.000 :)
It's fine for me, I already said that a thousand times, I'm not doing that, so stop insisting, it's really bad for my patience :D
Wickated, I see, the symbol "Т" was missing from the font script. I'll fix it before the new release. It's a bit messy to do!
Isn't this wrong? Mixing upper and lower case options?
.WakeModes = { "откл", "СОН", "ВЫКЛ", "все" },
^^ ^^
I made more changes to the oled dimmer:
[SLP] option has changed to [ON]. So you have [OFF] [ON] [ALL].
ON mode will be applied in low power modes (sleep and standby), no matter the temperature, as the screen is perfectly readable.
The safety is still there, it will only turn off the screen only in sleep mode, when the tip temperature is below 100ºC.
[ALL] is same as before, enabling the dimmer while running (But never turning off).
Feel free to show your suggestions before I make the new builds.
-
but screen off in run mode is still there ?
-
Re-read the post :D.
-
Isn't this wrong? Mixing upper and lower case options?
.WakeModes = { "откл", "СОН", "ВЫКЛ", "все" },
no it isnt. cuz actually those are two "off" words(but with different additional meanings. off stands for "disable" and OFF also means "shut down") and it looks like "off" and.. "off", so it had to be differed in that way - "off" for a feature and "OFF" as a mode state
-
So"откл" is different from "ОТКЛ", or "все" from "ВСЕ"?
-
So"откл" is different from "ОТКЛ", or "все" from "ВСЕ"?
yep - small should be off and on for feature and big for iron states. "все" is ok for "all possible variants" , "ВСЕ" is not used afair, but if is it would mean all 3 iron states slp,sby,run only.
nvm, ive seen u minimized possible text usage and same words linked across all menus, so ill recheck after new features added to build.
p.s. also i had to mix abbreviations in a weird way and delete spaces or points just to make a clear and readable view.
-
Yeah, I took existing parts for the dim modes (OFF, ON, ALL).
Wouldn't be strange if I did it wrong, so please check them:
.dimMode = { "откл", "ВКЛ", "все" },
.dimMode = { "AV", "PÅ", "ALLA" },
-
Yeah, I took existing parts for the dim modes (OFF, ON, ALL).
Wouldn't be strange if I did it wrong, so please check them:
.dimMode = { "откл", "ВКЛ", "все" },
.dimMode = { "AV", "PÅ", "ALLA" },
jajaja
so here fun part begins. "ВКЛ" stands for ON, so it logically fully duplicates "all" and is unclear.
so i actually prefer SLP instead of ON (SBY if more accurate, i guess screen actually start dimming on SBY state, am i right?)
-
I'll use "СОН" then. Or which of the 1000 russian versions :D?
-
I'll use "СОН" then. Or which of the 1000 russian versions of it :D?
yeah it should be ok :-+
p.s. chinese room in action
-
p.s. chinese room in action
(https://i2.wp.com/truthsnitch.com/wp-content/uploads/2017/02/meme-kermit-drinking-tea-but-thats-none-of-business.png?ssl=1)
New builds available (21-09-10). Updated operation manual.
-
loaded new build, got some strange results. offset is BELOW zero
-
I see nothing wrong. What does that picture explain?
-
i got offset that is like -10 cuz i have to wait some time to actuaaly get some adc output when touch cold tip.
also i need proper instruction. when should i insert cold tip for preclibration? on calibration submenu?
also finally got solid temp on screen. thanks for debouncer.
-
Again, explained in the manual! In the main calibration menu.
Otherwise it'll trigger the error detection.
It's impossible to get a negative ADC reading? Show pictures or video.
The firmware calibration code didn't change from the test build.
I only added the translations and modified the oled power modes.
-
nvm, fw is ok, i just meant that on my board smth is draining voltage. lowering opamp input on like 10 adc samples.
didnt tested well, menus, dimmng etc, on quick look everything is ok and great.
-
Still don't understand completely. Just make a video!
-
this
on other station it starts rising next second i touch tip with my thumb (i ddnt touch tip with my index finger so it lowered back to 0 after minutes)
https://youtu.be/t_6SdOsqokk
p.s. its said that entering calibration menu supress power to the tip, so i can change tip and keep it cold. but stand switch actually triggers it again.
-
I would like to make a German translation.
Which File do I need to translate?
-
this
on other station it starts rising next second i touch tip with my thumb (i ddnt touch tip with my index finger so it lowered back to 0 after minutes)
https://youtu.be/t_6SdOsqokk (https://youtu.be/t_6SdOsqokk)
p.s. its said that entering calibration menu supress power to the tip, so i can change tip and keep it cold. but stand switch actually triggers it again.
Still don't.see the problem? Some stations will be more sensitive than others.
Will look at the stand mode, I always forget it exists...
I would like to make a German translation.
Which File do I need to translate?
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3654799/#msg3654799 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3654799/#msg3654799)
But the fonts don't have special german symbols.
Remember that space is very constrained.
Once you made the translation, post it here or add a pull request in github, I'll take care of the fonts.
-
sry, tested on old station, it also has some time(~3s) to actually start rising adc output when touched with finger, so i guess its just very low thermal conductivity of skin. other numers seems very same, exept 0 offset on one and 10 on other, thats still withtin opamp datasheet anyway.
p.s. also afair in very old builds when i turned active detection off, i could unplug tip, insert new one and manually started station with encoder cuz screen showed no iron until i trigger it manually. now it looks like there is passive detection and as soon as tc readings go again, station starts. this works as intended ?
-
Sorry, when you complain about the tip heating slow by the finger I just want to *** everything.
First you said it had a negative offset, got me checking the code and testing, you never showed any proof when asked... Dude!
I seriously encourage you to stop that type of complains, it's becoming really annoying.
Unless you want it for that, it's a soldering station, not an anal temperature sensor ???
Fixed the stand mode, ignore changes when calibrating.
Also little changes in the calibration mode code to keep the station in run mode no matter what.
The active detection is just the 5us pulse before the ADC delay, to slightly charge up the capacitor at the input of the amplifier, so if there's no tip, it'll keep the charge when the adc reads and trigger the detection error.
If you disable it, it's supposed that you put the 1M resistor. Otherwise it'll got crazy, like most stations, error..800ºC...20ºC...error...
I don't remember old builds.
The tip connection fails sometimes, and it goes to "no iron" mode.
It would be annoying if after that the station went into sleep mode, needing to push the button.
So yes, it sets run mode when the error is cleared out.
-
sry for that. :'( i thought i was clear enough that it was behaviour of my hardware only, and i had only little time to recheck everything and really didnt expect opamp sticking to 0 output(cuz by datasheet it should have little offset, noise from psu and so on)
i currently have too little time to do any long tests, just quick button smashing.
-
When you warm a tip with your fingers, you have to heat up the whole tip body before the sensor starts reading.
The temperatre difference between your fingers and the tip will be only 10-15ºC, and your fingers are not copper rods, the skin cools down almost instantly, so the heat transfer is very slow.
Thats why you feel the cold! This is not like touching the temperature probe, which is a 0.5mm ball weighting 0.3grams.
So, let's keep this in topic: Soldering, cherry red iron tips, burned pcb pads/traces, exploding mosfets, and such.
I modified the error delay widget, now it has 0.1s steps and allows up to 60s.
So if you wish, you can change the tip at Flash speed yet have time for preparing a tea:
https://www.youtube.com/watch?v=NkqPUdgD37c (https://www.youtube.com/watch?v=NkqPUdgD37c)
-
The active detection is just the 5us pulse before the ADC delay, to slightly charge up the capacitor at the input of the amplifier, so if there's no tip, it'll keep the charge when the adc reads and trigger the detection error.
If you disable it, it's supposed that you put the 1M resistor. Otherwise it'll got crazy, like most stations, error..800ºC...20ºC...error...
I don't remember old builds.
The tip connection fails sometimes, and it goes to "no iron" mode.
It would be annoying if after that the station went into sleep mode, needing to push the button.
So yes, it sets run mode when the error is cleared out.
ah, very nice hardware hack :-+
things clear. i aksed just only because of jbc tip extraction algorithm - genuine have two stand switches, one is normal stand and other is for tip change, is almost same but shuts down power until u manually restart runmode. thought that was accidentally intended. no need to change behaviour, 2s iron check give actually give enough time to push new tip.
-
But here we have only one switch for all. So what :-//? I have no way to detect if it was a tip change or a momentary connection error.
We can't have everything. If I lock the station after the error, people will start complaining, if I don't, they will also complain :-DD
I could add an option, ex. "After error" [Resume] [Sleep] [Run] or something like that.
-
no need to worry, i didnt complain, just always forgot to ask about behaviour change.
-
No worries, you know what are the kind of requests that annoy me (Issue #1223: Tip heats up slowly using the fingers :D)
This one is an useful feature :-+.
Added "Err. mode" [SLP] [RUN [LAST]
(Error resume mode)
I noticed the error delay was not profile-specific, but system-wide.
You might need more delay for changing T12 tips than with a JBC, or the other way, so I moved it to the profile data.
Also, that delay ws not really related to not related to "NO IRON", but to any error, so I changed the label to "Error delay".
New translations needed:
.IRON_Error_Timeout = "Err delay",
.IRON_Error_Mode = "Err mode",
.errMode = { "SLP", "RUN", "LAST" },
Or maybe use a different label for."Err. Mode"?
"After Err"?
-
i would suggest as "tip change" - "off" - "run"
since it would actually be mostly used as workaround for tip changing and "slp" wouldnt suit for both t12 and 245
when "dim all" and "screen off" enabled, it shuts when temp lowers, but dont ignite again when iron starts by switch. so i suggest "screen off" work w/o temp check cuz if iron restart user could think "screen off only when temp low so i should lick tip now nothing to worry about" :-DD
also this makes dim "all" option useless. since screnn would only go off after full cycle slp-cooldown-run
-
Arghh, stupid miniature screens.
I got tired, I'm redesigning combo widgets to slide text, for now only for the label, not the options.
That way you could write:
"Excuse me Sir, what would you like to do after an error condition is no longer present?" [SLP] [RUN] [LAST] :D
-
Starting to work...
https://www.youtube.com/watch?v=tXuzEojKBCk (https://www.youtube.com/watch?v=tXuzEojKBCk)
-
Hey. I saw this post and maybe to someone like David it would also make sense and maybe will find something usefull.
https://github.com/Ralim/IronOS/issues/1038
-
Yep, I've been watching that project since long time ago.
Not interested, it's a very different project targetted for a very specific hardware, while this one needs a lot of options to maintain compatibility.
My intention is just to tweak the graphical interface to make it easier to translate.
If you have ideas for a menu layout, just let me know.
-
The way the new graphics look on the TS100 look amazing, they are pixel perfect.
Using images instead of text on the small TS100 LCD makes more sense, it also minimizes the need to translate.
-
Translations required anyway and they don't have 1/4 of the options. When you have only 10 options, it's easy...
But this fw needs a real menu.
https://www.youtube.com/watch?v=vEZ1wHPPvHw&t=391s (https://www.youtube.com/watch?v=vEZ1wHPPvHw&t=391s)
-
Using long strings is actually worse because you don't have a clue what's about until it starts sliding...
Ex.
OLED | NOT VISIBLE
Standby Temperature
Standby Timeout
Stby temp
Stby time
Is seen as:
Standby T
Standby T
Stby temp
Stby time
It's easy to shorten words in english, but in other languages it's not.
Not sure about this... It's giving lots of new headaches.
The text is clipped to the field size, so it will look a bit weird.
I've trying different layouts using paint and a 128x64 bitmap... The hard part is to keep everything readable while properly highlighted when selected or editing.
I don't like any of them, I'm this close to ditch the translations...
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1268734)
Any ideas for the layout?
-
looks really cool in 1500 fps ;) but not necessary cuz short names look more clear when u get used to.
when "dim all" and "screen off" enabled, it shuts when temp lowers, but dont ignite again when iron starts by switch. so i suggest "screen off" work w/o temp check in "dim all" cuz if iron restart user could think "screen off only when temp low so i should lick tip right now nothing to worry about" :-DD
also this makes dim "all" option useless. since screen would only go off at run mode after full cycle slp-cooldown-run
-
I know, that's why I prefer english for all, short and meaningful. But you're missing the point of this, it's all about the trasnlations.
If you're lucky, you'll be able to find some words in your language that fits the available space. But if not, you're screwed.
So I was trying to find a workaround for that.
What you say about the oled makes no sense.
- Dimmer [OFF (Never dim)] [SLP(Dim in low power modes)] [ALL(Dim in all modes)]
- In sleep: What to do after the screen was dimmed in sleep mode and temperature is under 100ºC. Leave on or turn off.
It's never turned off in any other modes, and never turns off unless the tip is below 100ºC.
Any encoder movement, wake input in shake mode, station mode change, errors change, will wake up the screen.
It's impossible that the tip heats up while the screen is off, and it's impossible that the screen stays off if something happened.
BTW the sliding text is updated every 20mS (50 times per second), it should be the same for all controllers.
In the end I added the code but kept everything as it was, the sliding text is disabled by default and can be enabled in widgets.h using "COMBO_SLIDE_TEXT" switch.
Also added drawing detection, to update the screen buffer only when needed.
It won't increase the screen performance, the iron functions are interrupt-driven, and all the remain power was used to draw the screen.
Now it just won't be updated if not needing so, freeing processing power for other future tasks, but peak framerates are still the same, limited by the bus speed.
So, in a static screen the stm32 is doing almost nothing, only updating the adc/pid/iron states.
-
Wickated, I see your point now.
I've already explained a few times how the oled dimming should work. That was a bug, not the way it was supposed to be.
I missunderstood you. We aren't masters at English language, so that things will happen from time to time :D.
Ex. I said: "It turns off after sleep".
You answered:"I suggest you turn it off after sleep" instead "You said it turns off but it's not doing so"
In that moment my thoughts were "wtf, did he even read what I wrote? It's doing so (Or should)" *Lots of confusion* :wtf:
I changed the oled dimmer. Now it behaves in a different way, doesn't care about the stand or shake modes, uses only the iron states.
- If dimmer is only enabled for sleep mode, run modes will keep the oled at full brightness all the time.
- If dimmer is enabled for all modes, the screen will only wake up if it was off and the station is not in sleep mode (It woke up).
But if screen was only dimmed (oled power in sleep is enabled), it will stay dim, because that's what "Dim always" should do.
- In any case, the encoder activity will wake up the screen.
I also added wake filtering (For shake input mode).
If enabled, wake changes faster than 100ms or slower than 500ms will be ignored, so the station won't wake up by a small noise or vibration.
Made changes to the labels. If you're fine with them, time for translations!
.IRON_Boost_Add = " Increase",
.IRON_Error_Timeout = "Err time",
.IRON_Error_Resume_Mode = " Resume",
.SYSTEM_Oled_Dim_inSleep = " In sleep", (Maybe "Отдыхает" ?)
.SYSTEM_Shake_Filtering = " Filter",
.SYSTEM_Stand_Mode = " In stand",
The layout looks like;
Boost [10...120s]
Increase [10...200ºC]
Dimmer [OFF] [SLP] [ALL]
Delay [5...250s]
In sleep [OFF] [ON]
Err time [0.1...25.0s]
Resume [SLP] [RUN] [LAST]
Wake mode [SHAKE][STAND]
In stand [SLP] [STBY]
Filter [OFF] [ON]
I know the timeouts are a bit weird, but they are supposed to be fast, ex. 10-30s for the oled timeout (To prevent burning), and 0,5-2s time for clearing errors (When removing/inserting tips, handles...), not meant for high values, although it allows to do so.
-
- In sleep: What to do after the screen was dimmed in sleep mode and temperature is under 100ºC. Leave on or turn off.
It's never turned off in any other modes, and never turns off unless the tip is below 100ºC.
-
It seems someone didn't read the last message :D
Regarding the mesage from the Radiokot user, saying that the temperature actually goes down when manually heating the tip.
Seems caused by the mains ac noise.
The reason it goes up and down is because you're injecting 50Hz noise to the ADC, sampling at 5Hz, but they aren't perfectly synced, so the mains wave will drift over time.
So in the end you'll have a sinewave!
My house earth isn't great, touching the iron tip while having the feet away from the floor doesn't cause the issue.
I'm waiting for the translations, new builds will go when they're ready :-+
-
I'm waiting for the translations, new builds will go when they're ready :-+
Swedish:
.IRON_Error_Timeout = "Feltid",
.IRON_Error_Resume_Mode = " Återst.",
.SYSTEM_Shake_Filtering = " Filter",
.errMode = { "SOV", "KÖR", "FRG" },
I had a quick look at the scrolling text, could be quite useful for the translations...
-
Thanks!
Yeah... As I already spent the time on it, I left the code somewhere, could be useful in the future.
The current method has no limits, you can have a very short label and a huge option, the other way around, or overlap.
But sliding text has boundaries, dividing the screen in 2 parts...It's complicated.
There other possible layouts, like expanding the option, but I prefer to see every option with its value.
Testing the sliding text is as simple as enabling the option and using longer strings than the available drawing space.
Wickated, c'mon! Just 4 words! I could use Google but I'm scared, I might end writing some bad things about someone's mother, you never know with these translations :)
What about translating "boost" as "турбо", and " Increase " as "Добавить"?
Would it make more sense?
-
Wickated, c'mon! Just 4 words! I could use Google but I'm scared, I might end writing some bad things about someone's mother, you never know with these translations :)
What about translating "boost" as "турбо", and " Increase " as "Добавить"?
Would it make more sense?
sry i was very tired and forgot to post message.
boost is just new layout of boost?
.IRON_Boost_Add = " Догрев"
.IRON_Error_Timeout = "Вр.Ошибки"
.IRON_Error_Resume_Mode = " Возврат К"
.SYSTEM_Oled_Dim_inSleep = " РежЭкрана"
.SYSTEM_Shake_Filtering = " Фильтр"
.SYSTEM_Stand_Mode = " Подставка"
.errMode = { "ВЫКЛ", "ПУСК", "ПРЕД" }
i also forgot to explain photo. screen shuts down when tip cools down, but after wake triggers it doesnt light up. as i remember at first implementations it was supposed to be ultimate antiburn feature and screen goes off instead of dimming every time. later hot protection was added and screen turns off only after tip cools down. but dont turn on.
p.s. if text lables are short enough (11chars), they wont scroll?
so i mean we can enable scroll but leave short names as is?
-
I've said already 2 times it was a bug, not how it was supossed to be.
Affected only stand modes because it was using shake input as source. All that is already fixed.
Text scrolling is a test feature, disabled by default in the code.
With it, the actual text size is even smaller, around 8 chars, because you have to split the screen in 2, one for the value and other for the label scrolling.
New builds! All should be fine now.
The settings structure is different, so everything will be wiped... note down your calibrations!
The fw has changed a lot since the last video... Will have to make a new one.
My camera hates oled screens, specially the refresh rate!
-
Nobody complaining? Everything working correctly? Really?? :D
-
You miss the complains already? I just bit the bullet and updated from a 2 weeks old build, thus had to spend two hours recalibrating all my tips (my thermometer's so fiddly it takes 10min for each tip).
All I can say for now is that default settings for calibration target points are too high for my unit. Both 250° and 400°C are off by a large margin (80~100°C too high). I lowered them to 1100 and 2000 so it lands within the 50°C delta.
Hardware is Ksger 1.5 with T12 tips. For reference, my values are:
Zero 41
BC2 1092 2338
BCM2 1097 2022
C1 1209 1645
D52 (forgot it, I'll do it later)
ILS 1157 2517
JL02 1184 2350
JS02 1107 1906
KR 1041 1833
KU 1092 2135
-
Well, that's easy to fix. I can't find these values by myself :-+
You have a lot of variation between tips, specially with the C1.
That's crazy, are they new?
-
I don't use C1 often but it's not new, it's got at least 4-5 hours of burn in. My tips are of 3 or 4 different chinese "brands".
-
That makes sense.
I usually get all from the same seller, the calibrations are so close that I rarely calibrate more than one tip, doesn't worth the hassle for 1-5ºC error!
Being your tips so different, backup the flash before flashing the firmware, so you can quickly restore it if the new version fails for any reason, keeping all your settings.
-
flashed 9-13. on first boot after changing languange once screen clears and new strings doesnt load
-
Whoops, I introduced a bug due the new drawing detection mechanism.
I also spotted a little bug in the screen power, it wouldn't turn off if there was an active error, staying dim.
Fixed, updated the builds (Same settings structure, nothing will be erased).
-
so for late testing, i still dont have external port for swd on backplate.
about newest post on radiokot. so u say precal. values 250 and 400 are linked to each other i.e. 400 is an offset over 250? i thought that both 250 and 400 are set independently above 0. and only rule is "250 < 400"
-
Nope, no offsets.
In older releases you had to roughly adjust the ADC value, but when I studied the calibration code, I made it right.
You should have noticed that now the default calibration adjustment is a lot more accurate when calibrating tips, that's because of that.
The system uses linear interpolation, but applying temperature correction.
So when you adjust CAL 250 or CAL 400 values, that's not the value applied in the ADC, but the calibrated value for 0ºC ambient temperature.
So for example, if you have these values:
- Zero offset: 300
- Cal 250: 1400
- Cal 400: 2300
- NTC reading: 38ºC
And you ask the system for 400ºC, it won't use the 2300, what's really happening at low level is this:
- You want 400ºC at the tip.
- But remember, thermocouples works on a temperature gradient.
- As the ambient temperature is 38ºC, you really want to read 400-38=362ºC.
- You have 1400 for 250ºC (at 0°C), 2300 for 400°C(at 0°C), but you need the ADC value for 362°C.
- The system checks what range to use: 0-250 or 250-400, Which are Cal_zero-Cal_250 and Cal_250-Cal_400.
- In this case, 362ºC is between 250 and 400. The calculation would be: (362-250)*(2300-1400)/(400-250)+1400 = 2072.
- This is the real value for the ADC when you're calibrating for 400ºC and your NTC reads 38ºC.
- And this value is changing all the time based on the NTC readings.
So, as you see, if you change CAL_250, it will affect the 400ºC calibration.
When cal 250 hits the limit (Can't be set higher than cal 400 value), you need to increase 400ºC, always watching to not overheat things, repeat cal 250 calibration, then run the 400 calibration to use the updated Cal 250 value.
This is likely to happen only with JBC tips because I set really low values, don't want to take any risks, they're not $3 tips, but $40.
You'll certainly prefer spending some extra time at calibrating than burning your expensive tip.
-
Thanks for total explanation!
this also persuades me to actually run calibration eventually, not only writing numbers from paper every fw update. even if it still work enough accurate to never bother about.
-
These values are temperature-compensated, so it's completely valid to manually restore them.
The differences you may get between calibrations are usually caused by the NTC or the handle connections, causing small errors.
Normally these errors are very small, you might get 2400, 2420, 2385... That's not an issue.
I do that too, I got my calibration values of 1377 and 2216, and I restore them after each build in the tip settings menu.
The only calibration I need to do is the zero cal value the first time after resetting the settings
-
i also have stupid question - do i still need quartz generator onboard ? :-DD
-
No :-//
After a lot of research,I found the type D thermocouple to look very similar, my measurements also showed that slight curve.
Type C is almost the same, but it's more straight.
(https://upload.wikimedia.org/wikipedia/commons/c/c3/High_temperature_thermocouples_reference_functions.svg)
-
You could put a clock somewhere at the bottom of the system screen just to give it a use. :horse:
-
Nope, I've been clear about that.
Found this great PDF with all polynomials(mv to C, C to mv)
https://tempsens.com/pub/media/pdf/Product_Guide.pdf
Will have a look. Luckly I'll be able to use a single vale calibration.
-
You could put a clock somewhere at the bottom of the system screen just to give it a use. :horse:
i cant make any explanation for a 150+watt clock
is that type of tc for t12 or jbc? since i guess not both at the time
-
These values are temperature-compensated, so it's completely valid to manually restore them.
The differences you may get between calibrations are usually caused by the NTC or the handle connections, causing small errors.
Normally these errors are very small, you might get 2400, 2420, 2385... That's not an issue.
I do that too, I got my calibration values of 1377 and 2216, and I restore them after each build in the tip settings menu.
The only calibration I need to do is the zero cal value the first time after resetting the settings
I didn't have time to do any tests at all but I read this forum ;)
When I will have more time I will tell you my new values.
So if I understand you correctly... if real temperature is "23 C" and NTC is showing that at the start before soldering iron wasn't used at all, does that mean I will have a "15 C" (for this case) lower value than wanted if NTC is getting higher values over time since handle is getting warmer (lets say to "38 C") but ambient room temperature will still be the same "23 C"? If that is correct, wouldn't be better to have NTC somewhere where there is more like real ambient room temperature and would not change over time if outside temperature wouldn't change?
-
Nope, you need to measure the temperature in the cold side of the probe, which are the T12 contacts.
If the contacts are at 40ºC, the sensor will output the equivalent voltage for 360ºC when the tip is actually at 400ºC.
That's how it works, and why you need the NTC there.
If you want to use the internal temperature, simply disable the NTC in the menu.
-
if more accurate - ntc should be place in place where copper wires still have low thermal resistance.
-
Meh, it's enclosed inside the handle, surrounded by 4-5 wires that will move the heat from the connector.
I think the temperature inside will be pretty much uniform.
-
Ok, got it.
Great explanation, thank you! :-+
-
Did some work, this looks extremely close to what I got manually measuring the temps:
https://docs.google.com/spreadsheets/d/1-gHFioHSMEHnq2Rf6m0XHOzFCaLRm-75jOYCPRLmUlw/edit?usp=sharing
As you see, using polynomials you only need one-step calibration to calculate the ADC gain, after that it'll perfectly track the temperature along the curve.
Also, it's clear why the linear interpolation is only ok for 150ºC range max.
More tests coming. Yet to find what's the TC type in JBC tips, I'd need an accurate plot graph to compare...
I dont know what I'll do. I might restore 3-point calibration, go for the polynomials, or leave as it is.
After all, going below 250ºC in a soldering station is pretty useless, and an error of 3-4ºC in the whole range is perfectly acceptable.
On top of that, given the extremely dispair calibration results of different tips, leads me to think the quality control of these tips are just inexistent, so every TC will be different, and the coefficients will no longer be valid.
It's just that I discovered Type C (TUNGSTEN 5% RHENIUM 26%) and type D (TUNGSTEN 3% RHENIUM 25%) thermocouples, which aren't commonly used, and I decided to play a little.
-
you said "adc value per 1C step" ? could i help?
-
*per 0.05ºC step* :-DD
Are you crazy? It's enough with 25ºC steps. But these steps must be measured using a thermometer. You might need ex. 252ºC setpoint for true 250ºC.
But don't break your head, it's very unlikely that I implement this.
The most important part is to measure the voltage at the input of the amp at least once to check the actual gain and scale the ADC readings.
But won't be easy. You can't correctly measure 8mV when there're 24V spikes everywhere, and the tip will cool down quickly if you remove the power.
-
i remembered one cool thing ivee seen in one station
could it be possible to make diy attachment for selfcalibrating ? or shop-shelf TC K type also have huge parameter spread?
once i used broken t12 tip to clabirate one station with another but i definitely had tip calibrated before breaking:-DD
-
Usually, calibrating a tip takes less than 1 minute!
You don't have a secondary channel to read, so that would be a deep hardware mod.
You would need to calibrate the thermometer anyways.
And remember this FW targets existing stations, at most with little mods like adding a pull up resistor to improve tip detection.
-
Usually, calibrating a tip takes less than 1 minute!
im too lazy to pick termocouple for multimeter from shelf
everything is better when there is no need to lift ass :-DD
-
see gui_strings.c with first Version of German Translation attached
-
Thanks for the effort, but... Half of the strings are just too long, they don't fit even using the whole screen space :palm:.
That's why I didn't translate to spanish. Tried the scrolling text, made it worse... Not easy with such limited screen.
I suggest you to compile the fw when working on the translation, it's really easy, and you'll be able to see how it fits.
-
IMO it's awkward to use tools or many electronic devices with a localized interface, it hurts my soul when I'm forced to. Sure, you can translate the words but the technical significance behind them is lost most of the time and you end up with nonsensical phrasing. And that's when you have plenty of screen real estate.
-
i dont think that most of languages dont have proper words for technical terminology. :-//
even simple "sby" translated makes station looking more solid
-
I do prefer english, too. Makes it much easier.
The idea for the russian was because it's a completely different language, but most european countries will do fine with basic english terms.
So yeah, if someone breaks his head and finds really short words in their language that fit the menu, I'll add the translation, but that will never be a project objetive.
I just made the support for it and left the door opened.
-
...next try with German Language ;)
Now it looks good...
But Ä Ö Ü are missing ;)
-
I added üäÄöÖÜ chars.
Yep, as I said before, the fonts only included the basic Latin charset + very specific localized chars and symbols.
The most stripped font is the big NO IRON font, it only has the very specific chars required, because it's huge, so I added the required ones too.
I made a quick lookover:
- The big error "KEIN KOLBEN." doesn't fit in the screen (EIN KOLBE).
- Iron screen "Kein Kolben" slighly overlaps with the ADC value.
- "Aktiv Erkenn." and "NTC Anschalt." overlaps with "AUS"
- "LÖTSPITZEN EDIT." Fits without the '.' , still uses the whole screen.
- Boot screen "SPEICHERN" is too large. Consider using something like "OK".
- Reset screen "SYSTEM EINSTELLUNGEN", is tooooo too large :-DD
I can't spend too much time in this.
I updated the project.
Now you only need to download the latest code, and spend some time on changing the strings and compiling until it fits.
-
Hello,
first of all, I would like to say a big thank you for developing such an awesome T12 CFW. I really appreciate this work! :)
Following author's advice, I bought a QUICKO station with a CKS chip. Flashing the firmware went just flawlessly and the soldering station works pretty well after calibrating my tips. However, I would like to ask a simple question about proper earthing this device: should I be worried about the lack of a GX connector's grounding? My multimeter doesn't show any continuity between PE pin and outer case of the socket or GX plug (metal screws, nut etc.). Obviously, the handle's tip and encoder's case itself are grounded. I know that it can be quite simply fixed, but is it necessary?
Thank you in advance for any help :-+
-
It's not directly grounded, but through a resistor, 100K if I remember correctly... Just to avoid static charges from building up.
Edit: sorry I understood it wrong. The 100K resistor is used between power supply and mains earth.
The connector is connected to the housing in mine, must be the paint isolating it.
I don't see how is it going to be a issue. I don't recommend disassembling it, it'll need the gx12 desoldered, the jelly-made board won't survive the beating.
If it worries you, you can simply take the earth from the handle connector, using the pin that goes to the tip shell, and connect it to the connector outer shell.
-
I spent one or two days to find the original KSGER FW, just in case I need a chance to go back.
Now I can confirm that, for my KSGER device , the backup original ksger 3.1 fw can be flashed and it works again.
(my ksger: screen sysinfo HW 3.10 SW Ver3.1s , PCB black , silkscreen OLEDV3.0, Stm32F103RB 64pin , the tiny battery connector below the STM32 chip),
Using the FW from some page in this thread, file name --- 3.1Snew1.hex , it works, it can be loaded to the system, it didn't ask for some register code, and it has the same spell error and bugs or signature behaviour(option 5 code end (should be cold end) , Standby -- doesn't allow user to set zero and save (after system reboot it's default to 10min), sysinfo says the same version 3.10 and 3.1s, the only difference is the sys start info says WILDA , not Ksger.
(firmware attached --- 3.1Snew1.hex.zip )
For the flasher, a cheap and popular 2$ stlinkv2 clone works well.
So, hopefully more people with my device model or similar model can relax and encouraged to try the customized open source FW and knowing that they can always go back should they choose to, without worrying anything about losing the current solder station or desoldering a 64PIN chip to backup or getting a new same chip to replace or buying a new stm32 discovery dev board to do time glitch attack, or porting the original attacker program from asm to C and from a weird discovery STM32F303VCT6 (not so cheap, out of stock , and paying high shipping cost ) to a popular blue pill (stm32103C8T6), while the original attacker program is using PD port while the bluepill doesn't even have that port (PA PB PC only )....good to know that all those problems are gone now. :-+
When flashing/erasing, need to solder a 4 pins header connector to the ksger pcb, CDGV, but the TH holes are a little too tiny, so just use a filler to work on the new pin header to make them a little smaller, then they can fit in. No need to remove the PCB from the front panel (mine is CNC Ksger panel, looks good, but not easy to remove the pcb )
Another note, when booting the Orig Ksger fw with stlink, need a twezzers to short the capacitor C4 below the stm, which is the reset pin - and Gnd, then it can be connected using STM32CUBEProg program.
then destroy the read open option byte and at the same time erase the KSGER protected fw.
And, thanks all contributors !
-
Can you post the exact file you used? So I can add it to the project.
Are V2./v2.1 files available too?
-
Can you post the exact file you used? So I can add it to the project.
Are V2./v2.1 files available too?
yes, 3.1s ksger fw attached to my original post , (just to keep the info whole ).
I do have a bunch of 2.1 firmware but I didn't test them....they should work...I guess.
attached everything here:
KSGER_Original_Firmware_2_and_3.zip
and another file drive-download-20210802T050454Z-001.zip.
(too large to combine exceed forum limit)
for Ksger 2, people say it need register code to activate the system, so the register code link is also included in the notes.txt file ( not written by me, but by some other fellow contributor).
, and here: http://t12.omegahg.com/keygen.htm (http://t12.omegahg.com/keygen.htm)
thanks for everything !
-
Great! Can you Ksger guys test these versions? So I can create an accurate restoring guide in the project, people will appreciate not needing to replace the stm32 for testing custom firmwares.
What are the spell bugs? Unless they use some kind of checksum protection, ut should be easily patched.
-
Great! Can you Ksger guys test these versions? So I can create an accurate restoring guide in the project, people will appreciate not needing to replace the stm32 for testing custom firmwares.
What are the spell bugs? Unless they use some kind of checksum protection, ut should be easily patched.
I tested upgrading my boards from firmware v2.11s to v2.12s (worked fine,) you only have to use the keygen once (maybe they store the key in the SPI flash)
Couple misspellings in the 2.1x firmware:
- The abbreviation they used for Tuesday (Thes instead of Tues)
- The DateTime sub menu title (Data & Time)
There may be other misspellings, so if you or somebody could post instructions how to fix these typos would be nice!
Edit: I would probably shorten Tues and Thur to match: Mon, Wed, Fri, Sat, Sun
-
There are more files there than words in the german translation :-DD
What exact file did you use?
-
There are more files there than words in the german translation :-DD
What exact file did you use?
I used T12_HW21S_Encryption-SH1106.hex from this folder
https://drive.google.com/drive/folders/1Yp-jdfl9CQ28IoZ9sAB_wfVKQHx2rJlv
Edit: Direct Link
https://drive.google.com/file/d/1B3VXI1EOx0QLJluB5b7UdXvYLR9J_kso/view?usp=sharing
-
Can you post the exact file you used? So I can add it to the project.
Are V2./v2.1 files available too?
3.1 firmware has been in this thread for a long time i posted it a good while back in this thread. the only difference are the branding when it boots and there are a couple other minor changes that were made to the 3.1snew firmware. it flashes just like any other firmware just do a full reset afterwards but its been available for a long time. im surprised you missed it back then. https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3456602/#msg3456602 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3456602/#msg3456602)
i also posted it in the other ksger thread all the way back in feb. https://www.eevblog.com/forum/reviews/ksger-t12-stm32-v3-1s-soldering-station/msg3480024/#msg3480024 (https://www.eevblog.com/forum/reviews/ksger-t12-stm32-v3-1s-soldering-station/msg3480024/#msg3480024)
-
I tried converting the hex to bin, hex edited the strings, but for some reason the iron will not boot after flashing the modded bin. Restored original hex/bin and it boots fine again (settings also preserved after erasing)
-
It reminds me when I patched the OLED code to adjust the offset, the controller was completely dead after changing only 1 byte.
Does the converted bin work without modification? Then it definitely has tamper protection.
-
Yes if I flash the bin I converted using objcopy it works normally, what is strange is that the Russians have a reverse encoder firmware mod and it appears they did it by just by modding a few bytes
https://drive.google.com/drive/folders/1Clt8zoYeoTd0hvxemXFKrErCIIeV06nu
Edit: Looks like they patched some bytes on the end of the file, could it be checksum?
-
Yeah, probably a checksum. I'm not interested in reversing the ksger firmware.
Added the firmwares and mirrored the keygen inside repo, so if the keygen site dissapears, there will be a backup.
-
Hello,
I'm following this thred for a couple of weeks, interesting project. Thank you for CFW. Here is my little help with original firmware of QUECOO T12-955 (KSGER v2.1S). I tried to back up original FW and i did it. Also try to flash with CFW from BOARDS_KSGER_[v2] and it's work very well. Flashing again with my back up file, OK too. I've read and programmed STM32 with TNM5000 programmer, so this is back up file. Here is pic of board and backup FW.
-
this board is 100% same across quecoo and ksger. almost. this one dont have quartz but do have quartz cap load :-DD
aaah forgot to say David im using only hq quecoo hw 8)
-
Maybe they're the same company now, or there's a 3rd one providing these boards. Who knows.
Yep, the smd are usually placed at once in a pick and place machine, but probably the rest of parts are soldered by hand.
Seems they became smart enough to realize placing a clock that uses 1/2 of the screen was not a good idea.
Thus, they removed that step from manual production step.
It's likely thet these parts will be removed eventually from the smd process too.
-
the ksger boards are sold under a few brands now ive seen they are identical literally in every way. could be one company dropping different brands on them now
-
Hello,
I'm following this thred for a couple of weeks, interesting project. Thank you for CFW. Here is my little help with original firmware of QUECOO T12-955 (KSGER v2.1S). I tried to back up original FW and i did it. Also try to flash with CFW from BOARDS_KSGER_[v2] and it's work very well. Flashing again with my back up file, OK too. I've read and programmed STM32 with TNM5000 programmer, so this is back up file. Here is pic of board and backup FW.
Dear groff , do you mind share how did you backup the ksger fw ? Is it encryped/read protected ?
Did you have to desolder it from the Ksger pcb and solder it to your own breakout pcb ?
And did you use the bluepill to run time attack app?
Thanks!
-
Hi David, I have spent my whole Friday and Saturday to tried /add/mod/add the ksger pcb and the open source on my KSGER OLED 3.0 black pcb, it works well, I don't think I need to go back to ksger.
But there is one thing, seems the project currently only supports F101 ( BOARDS\KSGER\[v3]\STM32F101 ), I know it's compatible with F103, but currently there is no direct/native support for F103 (no BOARDS\KSGER\[v3]\STM32F103 ), so I made a F103 variant for it, all pins are identical to the F101 (BOARDS\KSGER\[v3]\STM32F101) setting,
loaded the F103 bin to my board, tested, it works well on my F103RB mcu, buzzer, oled, encoder, temperature sensing etc.
Even though it's working fine but this stm32 ide and the 64pin mcu and it's clock is quite new to me so could you please take a look see if there is some error need to be fixed, especially the clock frequency part ?
thanks.
-
Hello, I already answered in the pull request.
Sad that you spent so much time on that.
Actually it's much easier: Edit the .ioc and the project files, replace all 101CBTx entries with 103RBTx, copy and edit the linker script, changing the line that sets the RAM size, update the project linker settings to use that file, and done!
It's a good idea to ask before doing such things, didn't you wonder why there wasn't a RB profile? :D
There's no 64 pin build anymore, because there's no need to do so, I unified v2 and v3 builds using 101CB because everything is compatible. Less mess with files.
I will never have a build for each stm32 type (101c,102c,103c,101r,102r,103r...) and every controller type (v1.5, v2,v3).
Multiply that, and make these builds by hand every time. That's a lot of work, and why? The result will be the same. The project needs to be compatible with all, so it's designed to use 10KB max.
The extra RAM will do nothing, there isn't any benefit.
48 and 64pin boards use the same pins, so it's just a waste of time.
Flash the current v3.x build in your RB, and you'll see...
-
Check out this cool settings menu! (also check out the funny No Iron screen)
https://www.youtube.com/watch?v=DIIqDWEzMVU (https://www.youtube.com/watch?v=DIIqDWEzMVU)
-
When are you starting to work on it? :popcorn:
-
I think the graphic "no iron" screen would be an improvement but I'm definitely not a fan of the settings menu. The guy in the video seems to only have 3-4 options in his menu so it works for him but I don't see how cycling through 60 icons to find the desired option would be a good thing.
-
Maybe I wasn't clear enough of the current state of the project.
Only
Bugfixing
And little
things
No major
reworks
taking
my time
my life
and my tips
If you want something like that
time to fork and make your own
(https://starecat.com/content/wp-content/uploads/error-in-the-code-me-slaps-comment-mark-programming.jpg)
-
i dunno why anyone should want something more of this project. fw is already on its top state. i even think some features are overkill. all u already have 4 cool icons, why more? :blah:
i personally dislike project with hot air plugin, cuz hot air turbine handle sucks hard compared to 857dw.
i`d prefer project with multichannel, huge pixel density screen and other sort of jbc compatibilty. but it should be completely new project requiring build from scratch for pcb and everything else, this is 1) not fun , 2) compared in price with professional stations
-
Check out this cool settings menu! (also check out the funny No Iron screen)
https://www.youtube.com/watch?v=DIIqDWEzMVU (https://www.youtube.com/watch?v=DIIqDWEzMVU)
i could swear ive seen that version somewhere before. i wish i could remember if it was handskit or who it was. he may have modified it but im positive i saw another brand with that setting menu and sleep icon. hmmmm now its going to drive me crazy trying to remember
-
Hello,
I'm following this thred for a couple of weeks, interesting project. Thank you for CFW. Here is my little help with original firmware of QUECOO T12-955 (KSGER v2.1S). I tried to back up original FW and i did it. Also try to flash with CFW from BOARDS_KSGER_[v2] and it's work very well. Flashing again with my back up file, OK too. I've read and programmed STM32 with TNM5000 programmer, so this is back up file. Here is pic of board and backup FW.
Dear groff , do you mind share how did you backup the ksger fw ? Is it encryped/read protected ?
Did you have to desolder it from the Ksger pcb and solder it to your own breakout pcb ?
And did you use the bluepill to run time attack app?
Thanks!
It's a long story :phew:. Just kidding, it wasn't read protect. Maybe producer forgot to enable "read protection" |O. Readed with SWD connection without desoldering. That's all. :popcorn:
Not encrypted. On this board no need for activation code.
-
Hello, I already answered in the pull request.
Sad that you spent so much time on that.
Actually it's much easier: Edit the .ioc and the project files, replace all 101CBTx entries with 103RBTx, copy and edit the linker script, changing the line that sets the RAM size, update the project linker settings to use that file, and done!
It's a good idea to ask before doing such things, didn't you wonder why there wasn't a RB profile? :D
There's no 64 pin build anymore, because there's no need to do so, I unified v2 and v3 builds using 101CB because everything is compatible. Less mess with files.
I will never have a build for each stm32 type (101c,102c,103c,101r,102r,103r...) and every controller type (v1.5, v2,v3).
Multiply that, and make these builds by hand every time. That's a lot of work, and why? The result will be the same. The project needs to be compatible with all, so it's designed to use 10KB max.
The extra RAM will do nothing, there isn't any benefit.
48 and 64pin boards use the same pins, so it's just a waste of time.
Flash the current v3.x build in your RB, and you'll see...
Yes I flashed the F101 build from BOARDS/KSGER/[v3]/STM32F101 at the very beginning, it works very well already.
But then I noticed F103 and F101 are quite different, other than pins and ram, the speed is 72MH vs 36Mhz, so I think maybe a F103 build can utilize the full computing power of the F103 ?
Regardless, it's still a good learning experience for the stm32 and ide, I'll just keep the F103 build for my ksger F103.
and for those wants to try the F103 FW: attached
My original plan was to test your fw for reed/magnet switch, so when user put the handle on handle rest, it enters standby mode immediately (magnet triggers the reed switch) , so it doesn't burn the iron for air, the Ksger 3.0 fw doesn't support this setting well...but it seems the custom firmware already supports this feature well enough, nothing is needed to add.
Thanks.
-
afair fw is built for lowest resources possible, so u cant get any additional performance boost from x2 cpu clock. or just small fps boost on spi screen.
stand switch support was always in fw, even in stock. not hard to diy.
-
I would do that if there was an automatic building method, but by hand, no way, keep it simple.
Except Ksger v2 (limited by the screen interface), all others are very fast. Simply there's no need for more speed. It's like cruising in the highway, you don't need 400hp for that.
There's a lot of unused power already.
I thought to manually adjust the speed by detecting the CPU, but there's no option for that, the mcu id shows the revision (A,B, C...), family (32F10xx) and flash density (Low, high, XL..), but as far as I know, there's no way to detect if it's a 101,102 or 103.
-
German translation will be disabled in the next build if it doesn't get fixed in time.
I don't like adding half-made features, please finish it... ;)
-
hello i just noticed recently that displaytemp is now locked once it reaches settemp instead of 5c threshold. so u thought this behaviour is much better than before? (again, i just ask, no offence) maybe this could be switchable in menu?
-
David, I've installed your latest software release. On github it is written 21-09-29, and in SYSTEM I read 21-09-23. Where is the typo? ::)
-
Yesterday I made and tested a semi-automated build script , that was all. No changes.
Wickated, 17 days ago I increased the threshold to +-10°C for the noisier controllers.
But what you say is a bug. I never said I was going to lock the temps, only add a threshold, if not doing so, should have been reported.
I didn't notice because I don't use to put my tips in the water ;D (BTW, that's a quick way to damage the tips).
A missplaced ")" .. Fixed, new builds uploaded.
Maybe I'll add a "Denoise" option to adjust that.
-
sry i couldnt notice since jbc casually dont drop temp out of bounds.
-
I'm not sure it has actual repercussion on the generated builds (since they appear to work anyway) but there's an error in the linker files. For 101CBTx and 103CBTx you set:
/* Memories definition */
MEMORY
{
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 10K
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 126K
SETTINGS (rx) : ORIGIN = 0x8001F800, LENGTH = 2K
SETTINGS is out of bound, it should be 0x801F800. The IDE build analyzer indicates that it consequently slapped the settings partition at the end of the officially available 64K (0x800F800) which is definitely NOT good if that's true.
EDIT: compiled binaries have the same CRC regardless of this parameter so... I guess it's not important as long as it passed compilation, maybe? :-//
-
Nice catch, you're right, but it won't cause any issues, that linker section is unused.
The address is hardcoded in settings.h at the last 2KB of flash.
The important part is the regular flash section, reduced in 2kb, so the code never overlaps the settings.
I'll correct it anyways.
-
German translation will be disabled in the next build if it doesn't get fixed in time.
I don't like adding half-made features, please finish it... ;)
Sorry, less Time at the moment ;)
I finish it right now... give me some minutes
EDIT:
tried my best with the long german words...
NO IRON needs to be NO IRON because no german words fits...
-
NO IRON needs to be NO IRON because no german words fits...
u have no short words for "disconnect", "offline" "off", halt" ? i had same problem but just changed to similar meaning with another words.
maybe "abstellen" ?
-
no, not really...
Any other Germans here with an Idea?
-
Or "No Tool" like JBC
-
NO TOOL is in German "KEIN WERKZEUG" ;)
-
why not make the BIG "NO IRON" smaller?
-
size for "no iron" is adjustable afair :-//
in russian font is smaller
-
Or just slap an icon showing a barred iron instead of that text. ^-^
That would solve the need for extra font that is only used there (AFAIK) and also the need for that string in every translations with the added bonus of looking better. Correct me if I'm wrong but the coding part should be trivial as long as we can dig out a nice icon.
-
Ex.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1286677)
-
Hello, In my opinion flashing cross on top of the iron will be more informative than the question mark aside.
-
How about "X" over the iron you draw?
-
This is the final result (the shift is caused by the gif image alignment).
(https://i.postimg.cc/MZC1q3Sn/20211001-110418-1.gif)
-
Nice! :-+ The image speaks more than 1000 words...
-
Also consider the case when the iron wire is removed from the jack, there should be NTC and iron error simultaneously, what will be shown then?
-
As always. The big NO IRON error has always been completely isolated from the small error.
I properly finished the settings section in the linker scripts, and stored the settings there instead hardcoding it:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1286743)
I added a new option, de-noiser threshold in system/temperature settings.
Used the existing "Threshold" string. Set to 0 to disable, all the noise will be shown in the screen widget.
This is only applied to the widget, it's completely unrelated to the ADC signal processing and filtering.
A value of 5 means to ignore ±5C differences from the setpoint.
New builds available! Your settings will be wiped!
-
flashed, new option works ok
new icon in french translation:
-
This is the final result (the shift is caused by the gif image alignment).
(https://i.postimg.cc/MZC1q3Sn/20211001-110418-1.gif)
Perfect! Thank you!
My other german translations from last Post seems not to be in the last build
-
:) :-+
-
My other german translations from last Post seems not to be in the last build
Oops sorry, I forgot! Updated. What about :
ERROR_BTN_RESET = "Use btn to reset"
Can't you put something german in there. ex, "Press button"? Doesn't need to be so detailed.
Wickated, be careful, French people can throw hot butter at you if you offend them :-DD
Meanwhile, working on the russian version:
(https://i.postimg.cc/D0JxzJDT/ezgif-5-0dae92b895e0.gif)
-
shure:
.ERROR_BTN_RESET = "Drücken für Reset",
-
Meanwhile, working on the russian version:
(https://i.postimg.cc/D0JxzJDT/ezgif-5-0dae92b895e0.gif)
-
So Russian vodka will clean up corrosion and baguette is best for soldering with hot butter? I knew I was doing it wrong :palm:
-
who needs rosin when u can use butter instead :-/O
-
One for me, one for the board... put some onions when the iron is not being used... :-DD
-
Something is wrong with the new Build on KSGER V2
-
same
-
what version is yours? my v3.1 is fine with the new build no issues. i did erase the chip first i dont know if that had anything to do with it though
-
Don't panic, already spotted it, only affected v2.
I made some optimizations recently, put one line in the wrong place.
It's hard to fully test these things when you can't try it yourself...
Edit: Updated builds
-
it works :-+
-
How do I identify if a Quicko is STM32F072 or STM32F103
-
You open it up and check the marking on the chip. You're going to have to open it to flash anyway.
-
If it's a 072, try to dump the original firmware!
-
just a casual joke about temp debouncer
-
I have a KSger 2.1 - had to solder in an STM32F103. After flashing with the latest version pulled straight from github (BOARDS\KSGER\[v2]\STM32F101\STM32SolderingStation.bin) - my screen is upside-down. Anything I can change in code to rotate it 180 degrees?(board in attachment)
-
Why did you had to change the stm32? It's compatible with all 10x models.
Is it upside down or mirrored? Ex. If you rotate it, it's readable?
-
The original F101 couldn't be read back, and flashing failed. Yes, I rotated it on its head. Readable that way ;D
-
It failed because you have to connect the reset pin when the debug interface is disabled :D.
Will look at that tomorrow.
-
It failed because you have to connect the reset pin when the debug interface is disabled :D.
Will look at that tomorrow.
Gracias! Ah well, it got a free upgrade ;D
-
cancel the upside down. Did a full reset and it's fine now. Strange, it was a new STM32
edit: the only thing I needed to do, to get stable behaviour on ksger2.1, was turn down filter to 40%
-
Strange, can you try flashing it more times to check it doesn't happen again?
I was about to upload a test binary.
-
Aha, after calibration / tip setup, and powering it off and on again, the display is rotated again ;D
-
What the... Do you see any image corruption?
Switch the power on/off few times, is the orientation always the same?
-
If i do a "reset profile" then it restarts correctly. powering off and on again causes the image to be flipped. No corruption.
-
Everytime you power it on it appears flipped?
If there's no corruption or strange pixels flying around, i2c bus problems can be dicarded.
It might be power-related (power supply rising too slowly) or a timing thing (display needing more time for self-resetting?).
What happens if you only reset the profile? That will preserve settings, I bet it will also work.
Can you attach some pictures of the front?
I'll make a test file with increased boot delay.
-
If I reset the profile, so the device restarts without power-off/power-on, yes, that works. I'll make a capture a bit later in the evening, not at my desk now.
-
I suspect the system is booting too fast, and the power is still unstable when initializing the oled.
Check the attached file, contains modified boot delay versions with 100ms(Default), 500ms and 1000ms.
Also slightly increased the reset pulse. I guess it'll work now, probably the 500ms version is enough.
-
That seems to have done it (using the 500ms one). For reference, the 2.1 version that I have, is using a linear LDO + tant cap. Maybe power rises indeed a bit slower than with a switcher.
-
That's what I guessed.
I already updated the code, next releases should work fine.
-
Works great. Mine is powered with a floating SMPS, and the ksger 2.1 board technically couples tip earth to the negative supply. So I put the shaker on the NTC ground as well, but oriented so while soldering it doesn't trigger. I now have a nice separate, earthed tip, instead of floating, possibly damaging components. Only gives a small *blip* when the NTC is read at the same time (technically, it would be possible to sample these out in code I guess :-/O, so shaker sampling does not occur when NTC is read).
-
I didn't understand it all.
The shaker must use the same ground as the controller, not the earth.
How are you going to damage anything by joining ground and earth?
And what's that blip you're talking about?
The Shake input is read at Systick rate (1KHZ), not with the ADC.
There's an exception, in stand mode it's read after every ADC conversion.
But ADC and Shake input are completely separate parts.
-
I didn't understand it all.
The shaker must use the same ground as the controller, not the earth.
How are you going to damage anything by joining ground and earth?
And what's that blip you're talking about?
The Shake input is read at Systick rate (1KHZ), not with the ADC.
There's an exception, in stand mode it's read after every ADC conversion.
But ADC and Shake input are completely separate parts.
So For the following - My switching power supply, supplying energy to the station, is a two-prong type. So with reference to actual earth, there's a 27V offset. This means, the tip; was also having a 27V offset in regards to earth. So I lifted the wire below; and coupled it via a resistor to real earth.
[modification.jpg]
But the original handle pinout, had the following:
[original.jpg]
The shaker ground, was also connected to the tip ground (and that in turn to the negative voltage rail). So I had to move the shaker ground, to the same NTC ground. But when actually shaking, you see some noise in the graph.
-
That handle wiring was either wrong or designed for a circuit that has earth and gnd connected together.
Of course you saw noise, it was connecting the earth through the stm32 and few resistors, bad idea if the smps is isolated.
How are you going to get 27V offset if you join negative and Earth? Once they're joined, both will become the smps ground reference.
New builds (21-10-06), oled should be working perfectly now.
-
offset from gnd ?
maybe there is just ac constant cuz in most SPSUs u have Y caps (afaik) that connect secondary gnd with ac gnd. i actually dunno real schematics, so can say wrong
-
That handle wiring was either wrong or designed for a circuit that has earth and gnd connected together.
Indeed, that's why I put the shaker on the negative wire instead of green "earth", and lifted tip ground, with a separate cable + resistor to a real earth. (see handle wiring in attachment)
Of course you saw noise, it was connecting the earth through the stm32 and few resistors, bad idea if the smps is isolated.
Well no, technically speaking, the negative of the smps is also the gnd of the stm32. Real Earth is completely separate now and only used for the tip. But when shaking, I do get some noise now in the ADC measurement.
-
First, stop the abstract descriptions and post pictures.
Clearly something affecting the analog circuitry.
Try putting a 1n4148 diode in series, so the shake sensor can only pull to ground.
That's a very bad circuit design anyways, no protection at all.
Try something:
Heat the tip to 400C, then set 180C setpoint.
As the tip is hotter than the setpoint, the pwm will be off.
Do the spikes still appear when shaking the handle?
It's really strange.
Again, if your mains earth is good (a lot of older houses have poor earth connection), there shouldn't be any offset.
-
Firmware 21-10-06. When turned on, it shows the real temperature of the NTC and the soldering iron, for example 22 degrees, then gradually increases to 30 degrees within a minute. I take out the tip, insert it again and now it shows the real temperature again. :o This happens at two stations, one works with T12, the other with C245.
-
It's probably as good as it gets at such low temperature. I mean, the expected working range is 200-400°C , it's not a weather station.
-
I am not interested in the value of the ambient temperature. The strange thing is that change happens for no reason. In addition, this was not observed in previous firmware.
-
Enter the debug menu, insert the cold tip, wait some seconds and note down the AVG value.
Keep watching the value as it heats up.
Debug screen has 5 minutes timeout, so there's plenty of time.
Mine does perfectly, no issues at all. There were no changes on the measuring code.
Also, the tip detection sends small power pulses, it might increase the temperature some degrees, but not that much.
Could be a lot of things,ex. the internal amplifier causing a small drift with the temperature.
What happens when you remove the tip and plug it back?
Have you changed any filtering/pwm setting from default?
Ensure your description is accurate. Ex. 1 minute is not 10 seconds, It can mean a completely different thing.
Or just make some videos.
My station shows 23-24°C with 24.5°C ambient, all the time.
Ensure your calibrated zero cal value.
Anyways, not something I'd spend my time on.
My personal life has changed lately, and the project will receive much less time.
-
David, thanks for the answer. I shot several videos.
I looked at the AVG value, but I don't know what to do with it later.
Active det. is disabled, so there is no heating.
After removing and installing the tip, the temperature decreases by about 10 degrees.
I did not change the filter settings and power.
I completely erased the microcontroller and re-flashed it to exclude incorrect settings, but it did not help.
Returned to firmware 21-09-29, temperature is stable, removal and installation of the tip is not affected.
Video here:
https://drive.google.com/file/d/1-s2-wLOUAZt87tjqJ7ia5Y9WDzRMO9iA/view?usp=sharing
-
I can't access the file. Check the permissions, ensure it's public.
-
Sorry, fixed.
https://drive.google.com/file/d/1-s2-wLOUAZt87tjqJ7ia5Y9WDzRMO9iA/view?usp=sharing
-
It's not the tip what rises, it's the ambient temperature sensor.
It goes from 25ºC to 36ºC, seems it's disabling the external NTC for some reason, using the stm32 temperature instead.
When the handle or tip is removed, the internal sensor is never used, unless the NTC is disabled in the menu.
That can be quickly checked out, remove the handle connector, the ambient should show -99.9ºC.
If it doesn't, the NTC is disabled. In that case the value should never change, regardless if the handle is connected or not.
Check your wiring. I can get similar results when I connect the handle only partially from one side, changes between 13 and 25ºC.
In your case, it seems like it isn't making a good ground connection, and travels back through the shake circuitry.
I checked the code and didn't find anything. Last weeks were minor updates, mainly to the user interface, translations, nothing to the sensors.
If you keep thinking it's a firmware thing, go to Github history (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/master) and start trying builds, from newer to older.
Ensure it's not the wiring, test it thoroughly!
Is anyone else able to replicate that issue?
-
I mentioned above that this temperature change is observed in the same way at two different stations. The first one, which can be seen in the video, has a controller according to the KSGER HW2.1s scheme and works with the T12. The T12 handle is connected to the station.
The second one is assembled according to the same scheme and works in the C245 profile with a copy JBC handle.
I flashed both stations to the software on 21-09-29, now no temperature jumps occur.
-
Is anyone else able to replicate that issue?
definitely not possible.
-
Check your wiring. I can get similar results when I connect the handle only partially from one side, changes between 13 and 25ºC.
Thanks. I will check. I just double-checked the C245 station, it looks like it’s okay and the temperature doesn’t jump.
Tomorrow I will check the wiring of the T12 handle, maybe something is wrong there.
-
Keep trying newer versions, if you find exactly the one that causes the problem it will be much easier.ç
I have re-checked every change. Again, nothing related to the sensors.
21-09-29 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/77ad4653cb3c7c325072bec0fa68155032b9cb97)
21-10-01 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/35ba4855cc6b74e3dd33a03feb1d834ad9822b4b)
21-10-02 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/b4fe43394543411ce6baaf724589e4743f4020a6)
21-10-02a (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/1684a54c4adeb9b64361d6df2dfb3c840ae62411)
21-10-06 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/2a40e21695718aa8829cbd72eec4b5c59b02d0bd)
definitely not possible.
So a black capacitor can't be a capacitor anymore? I smell racism here :D.
What did you do this time? Or you soldered a coil by mistake?
-
nope, thats just big black NTC i bought in store cuz black ones work better than chinese ones (no racism)
-
For what it's worth, temperature doesn't drift on my v1.5 using latest build (21-10-6) and it is also fairly accurate (error margin is less than 2°C with cold tip).
-
To avoid possible mistakes, I took another controller, assembled according to the same KSGER HW2.1s circuit and a different handle. First, I flashed the controller with software 21-10-01, I did not find any temperature jumps. Then I flashed the controller with firmware 21-10-06, the result is in the video. Profile T12. The jump in temperature is 7 degrees. Earlier firmwares do not give temperature jumps.
https://drive.google.com/file/d/1-soPKq4LCOnD7XktsQflZ7TuJuaTACkj/view?usp=sharing (https://drive.google.com/file/d/1-soPKq4LCOnD7XktsQflZ7TuJuaTACkj/view?usp=sharing)
-
What about 2 and 2a versions?
-
There are no temperature jumps in version 2a.
https://drive.google.com/file/d/1-ypNQdyTXiE548xtIEPZ4reHsNMRwKxB/view?usp=sharing (https://drive.google.com/file/d/1-ypNQdyTXiE548xtIEPZ4reHsNMRwKxB/view?usp=sharing)
-
im very pretty sure there is some error in pullup config, in ntc parameteres (beta), in ldo load sag, inproper wiring.
-
Maybe so. But logic suggests otherwise. I use the same connection for different firmwares. If the connection is incorrect, then the temperature jumps should not depend on the firmware. In fact, I see that there are jumps in firmware 21-10-06, but there are none in firmware 21-10-02a. How can this be explained? To avoid errors, I used different controllers and handles. I did not find any jumps in the C245 profile. Of course there are miracles, but I think that this is not the case.
-
Keep using 2a to make sure it doesn't happen.
The changes between 10-02a and 10-06 are minimal, just few tweaks related to the Oled and the main screen drawing.
The most important changes happened between 29 and 01 builds.
Sometimes there're sneaky errors that simply don't happen always. Just opening the station to update the firmware might be enough to open/close a defective connection.
Open the handle and check the wiring.
What happens when you remove the handle connector? The ambient shows -99.9, right?
What happens when you plug the handle again, but without any tip inserted?
You have to find the exact source of the problem.
Is It a Ksger v2? I will make a test fw showing some info in the screen to help troubleshooting the issue.
-
Open the handle and check the wiring.
I used multiple handles and the result is the same.
The same result is obtained with another user. https://radiokot.ru/forum/viewtopic.php?p=4102678&sid=c9cabbbf3bfd8abd65726caeb66a5b00#p4102678 (https://radiokot.ru/forum/viewtopic.php?p=4102678&sid=c9cabbbf3bfd8abd65726caeb66a5b00#p4102678)
What happens when you remove the handle connector? The ambient shows -99.9, right?
Yes exactly.
What happens when you plug the handle again, but without any tip inserted?
See photo below.
Yes it is KSGER HW2.1s
David, I'm removing my question, I think I need to wait for messages from other users.
-
Try the new build (21-10-09).
Recently, I increased the initial system booting delay to ensure a stable voltage, as there was someone having issues with oled screen corruption.
There was a little hidden bug in the screen initialization, not updating another screen timer. Nothing happened until now because the old timings were close enough.
The boot screen forces a reset of the measures to show clean values in the main screen.
Now, due the increased boot delay, the bug appeared, so in certain conditions it could force the update without actual update from the ADC.
As it forces error reset to clear any bad readings caused by initial power-on noise, the combination of both seems what could be triggering the NTC error.
The code was updated, shouldn't happen anymore.
I couldn't replicate the issue in my station in any way, that's strange.
-
David, thanks. Now everything is fine, no temperature jumps occur. :-+
-
Thank you for testing, too :-+
I realised something was wrong in my station because the tip initially read -40ºC, then slowly recovered after few seconds.
My amplifier has a minor issue where it causes a small drift, so with a cold tip the ADC usually reads 360.
A negative value means the ADC value was less than that, probably 0, in other words, wasn't being updated before exiting the boot screen.
Since the only recent change was the boot delay, I followed that path... These sneaky bugs in the code take a lot of time! |O
-
I found a bug and I don't know if I just didn't read something so I apologise if I didn't read something.
My hardware is Ksger v2.1 with latest version sw 21-10-09.
When showing graph and changing temperature it shows temperate on the middle of the screen but it will never disapear from the screen. Even after clicking on the main button. Only long press to get into menu and back will remove it.
Is that bug only on my HW?
-
The same thing on my HW2.1 with 01-10-2021 sw.
One proposal from me. Very often I forget to select tip after changing. I think it will be useful to see "select tip" togather with icon "no tip" on display and select it by simple rotating knob.
-
Sorry, I can't test everything everytime.
Nothing serious, caused a while ago when I fixed a small bug that was continuously triggering screen refresh.
Fixed, uploading new builds.
gorff, if I do that, changing the temperature from the error screen won't be possible.
You can change the tip at any time.
-
David, it is not a problem that you make mistakes. We all do. That makes you human ;)
I didn't check yet and should be tested later today.
EDIT: I just tested and the bug (or the feature :-DD) is gone. Now it works as it should. Thank you!
-
David, is there a way to sort tips by the name? When I want to pick an inserted tip I need to scroll round to see where it is. Question is in a form if it is possible to please put it on ToDo list ;)
-
Don't know if this has been asked before, but would it be possible to add a pre-compiled list of tips that can enable/disable similar to the original fw?
-
David, is there a way to sort tips by the name? When I want to pick an inserted tip I need to scroll round to see where it is. Question is in a form if it is possible to please put it on ToDo list ;)
Hmmm. I already had an efficient bubble sort algorithm I made for other project, so it was easy.
Tips will be automatically sorted on any addition/deletion/modification, keeping track of the current tip being used.
I also added a new feature: Now you can also select the working tip from the tip list screen by long-clicking over it.
This make it easier when you have a lot of tips in the system.
Updated builds
Don't know if this has been asked before, but would it be possible to add a pre-compiled list of tips that can enable/disable similar to the original fw?
I don't see much sense on that, and complicates things. There're 40+ T12 types. It's okay as it is.
(https://images-na.ssl-images-amazon.com/images/I/51THBEof8RL.__AC_SY300_QL70_ML2_.jpg)
The purpose of having only one tip by default is to calibrate it, then the new tips will copy that calibration and be more or less close.
I'd add more tips, but it's stupid for a simple reason: You'll have a lot of completely uncalibrated tips, every single one requiring manual calibration.
It's much easier to simply add or copy an exiting calibrated tip and write 4 letters.
Currently, enabling/disabling the tips cannot be easily done. ToDo, maybe in the future.
-
THANK YOU David!
I will test it later today and get back to you.
Regarding adding all the tips... I agree with you and I believe that your way is better because you can save the tip under the name you prefer or even have "top 5" tips you wish to have on the top (by adding '_' before the name) or even have multiple "same" tips with adding numbers or any other character by knowing which is which.
All I needed was sorting ;)
-
ksger "tip list" is just a marketing feature to force you buying more tips :clap:
and not to program manual tip adding and keyboard entry.
-
Caught a small bug in the system menu, returning from NTC or Reset menu would restore a wrong position.
Fixed, I very rarely use these menus...
-
never mentioned it cuz it was released with menu flush ram saving feature.
i have some question . are 2.x and 3.x pin compatible ? could it be possible adding spi screen module wiring only data pins for creen
-
Nope, v3 is v2 and v3 is v3. The schematics are very different.
And what gives? The display is already very fast. You won't get anything by doing so.
I'd understand it if it was slow as with the factory firmware, giving only 10-15fps being optimistic.
But it's capable of 90fps with i2c screens, so what's the problem?
Thanks for reporting the bug... :palm:
-
I like sorting very much :-+
All I did was a quick test and I can set "BC3" to " XXX" just to have it on the top as default.
I also test long push in the edit menu to set that tip and it works which is very good feature! :-+
Other tests will be done later or in the next few days and in case I get something weird I will tell you (well, I will let you know when I will stop doing all the test but I have a couple other things to work in our home).
This is something that could be changed but it could also be as it is. Under "Iron" changing "No iron" values are changed by 10 and not by 1. If I set it by mistake to 4096 I cannot get to 4090 directly. I have to go down to 300 and them go up to 4090. This was the same in the previous version but I forgot to write down.
-
Not important, anything over 3800-3900 is already a lot.
-
with i2c screens, so what's the problem?
Thanks for reporting the bug... :palm:
user tryed another screen module with ss1306 and if shows mess if wired to i2c. afair i2c screen bus is overcloked a lot here, so i guess plain spi should act wo any bugs.
i thought that if u didnt code menu ppostion return directly so its much complicated todo and shouldnt be bothered :-//
-
You shouldn't use wires for high frequency signals.
-
I got a new Quicko today with a CHK (CKS?) 103 controller
Please see the video:
https://streamable.com/3lo584
Something is strange. Only the STM32 is connected.
-
If it's a ch32f (not related to the cks) then yes, somebody already had issues with it.
Edit : Also, actually the CH32F103C8 has only 64KB flash, so it's not compatible.
-
Edit : Also, actually the CH32F103C8 has only 64KB flash, so it's not compatible.
but there are very old builds that fit in 64kb space ?
-
Yes, but the ch32f had such issues anyways, and the datasheet is chinese only.
Clearly something is wrong with the ADC and/or the DMA, but go figure.
-
He's better off swapping this counterfeit crap for a real STM32. They now sell for 20x what they're worth but all things considered it's a lot less hassle for "only" ~10$.
-
It's the CH32F which makes the trouble. The CKS works perfectly...
David, thanks. Now everything is fine, no temperature jumps occur. :-+
I saw your post at Radiokot about the new display. Try this, I relaxed a bit the I2C timings.
There're 2 files: One is the normal firmware, the other makes a FPS test to show the current screen throughput.
Another option would be to set lower I2C pullup resistors, like 2k2, to make the signal stronger.
Also, if you soldered wires to the display, the signal will have more issues, like crosstalk:
https://axotron.se/blog/crosstalk-problems-when-running-i2c-signals-in-a-cable/ (https://axotron.se/blog/crosstalk-problems-when-running-i2c-signals-in-a-cable/)
Twisting a gnd wire with each SDA/SCL signal, or even simple interleaving (signal-gnd-signal-gnd...) will help:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1296463)
But keep the wires shortest as possible.
Edit: File removed, please refer to this post (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3747094/#msg3747094)
-
David, thanks! Didn't expect you to answer this. I used the firmware from the KSGER_V2_I2C_Timing_Test archive. The image has improved slightly. Then I installed pull-up resistors for SDA and SCK, with a nominal value of 2k2. In the display itself, 4k7 resistors were already installed, I did not remove them.
The image is now stable, but sometimes there are slight glitches. This can be seen in the video when the soldering iron cools down in sleep mode. For example, at a temperature of 179 and 100 degrees.
Video:
https://drive.google.com/file/d/10-XvzIZxIF8Xr-7NKQLV1ecxPNybR5xY/view?usp=sharing (https://drive.google.com/file/d/10-XvzIZxIF8Xr-7NKQLV1ecxPNybR5xY/view?usp=sharing)
-
is this screen so slow or just set to 0,1 fps?
-
Leave the standard resistors for now, I want to make it work without modifications.
Can you post pictures of the connections?
Wickated, really? You should already know this.
Standard PWM/ADC is 5Hz, the display values won't update faster than the ADC.
-
Remove the 2k2 resistors (4k7 resistors will remain) and shoot a video of the display?
The display is connected without long wires.
-
The firmware KSGER_V2_I2C_Timing, the 2k2 resistors are removed, the 4k7 resistors remain.
Video:
https://drive.google.com/file/d/101dvsNCqSw53iQEUXo2pdfUXcV34vfnE/view?usp=sharing (https://drive.google.com/file/d/101dvsNCqSw53iQEUXo2pdfUXcV34vfnE/view?usp=sharing)
or
https://disk.yandex.ru/i/x4AzTPtzD_qymA (https://disk.yandex.ru/i/x4AzTPtzD_qymA)
-
Lets go. Made some additional tweaks and delay adjustments.
There're only a few versions to try :D.
KSGER_V2_I2C_Test_H10_L01_140fps.bin
KSGER_V2_I2C_Test_H10_L04_128fps.bin
KSGER_V2_I2C_Test_H10_L08_92fps.bin
KSGER_V2_I2C_Test_H14_L01_102fps.bin
KSGER_V2_I2C_Test_H14_L04_92fps.bin
KSGER_V2_I2C_Test_H14_L08_83fps.bin
KSGER_V2_I2C_Test_H18_L01_91fps.bin
KSGER_V2_I2C_Test_H18_L04_83fps.bin
KSGER_V2_I2C_Test_H18_L08_76fps.bin
KSGER_V2_I2C_Test_H22_L01_82fps.bin
KSGER_V2_I2C_Test_H22_L04_76fps.bin
KSGER_V2_I2C_Test_H22_L08_70fps.bin
KSGER_V2_I2C_Test_H22_L12_65fps.bin
The versions are called H--_L--, where H is the signal rise delay (the slowest part on the I2C bus because the resistor limits the slew rate), and L is the fall delay (Much faster because it's actively pulled down).
Start whith the higher: H22_L12. If that doesn't work, don't bother trying the rest.
If it works, try H22_L08. If it keeps working, then try in this order: H18_L08, H14_L08, H10_L08 (keeping the highest L).
Stop when it starts failing or there're no more files, note down the lowest "H" that works.
Now, strat trying the lower L versions, keeping the H version that worked.
Ex. If the lowest working H was L14, now try H18_L04 and H18_L01.
The lowest, the faster the display can be updated.
This not about refreshing the screen at 2000fps, but to refresh the screen when required using the lowest cpu time.
This firmwares only run the screen test, which updates the screen as fast as possible, so the errors will be detected easily.
I know wickated is going to try the 140fps version right away.. ;)
Edit: File removed, please refer to this post (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3747094/#msg3747094)
-
Display does not work even with software H22_L12. :(
-
Take a picture from the rear of the oled module and the current connection in main board.
Could be any little thing...
More tests:
KSGER_V2_I2C_Test_H30_L08_61fps.bin
KSGER_V2_I2C_Test_H30_L16_48fps.bin
KSGER_V2_I2C_Test_H40_L08_52fps.bin
KSGER_V2_I2C_Test_H40_L16_42fps.bin
KSGER_V2_I2C_Test_H50_L08_44fps.bin
KSGER_V2_I2C_Test_H50_L16_38fps.bin
It's like this one?
(https://ae01.alicdn.com/kf/HTB1CQrOXizxK1RkSnaVq6xn9VXan/TZT-White-2-42-2-42-inch-LCD-Screen-128x64-OLED-Display-Module-IIC-I2C-SPI.jpg)
-
Attaching photo. The display is switched to the I2C mode:
- 0 Ohm resistor moved from position R8 to R11 (connects pull-up resistor R7 to SDA)
- installed resistors 4k7 in positions R9, R10, R12
- removed linear stabilizer Q1 3.3 Volts, replaced by a jumper
- installed tantalum capacitor 4.7 uF in position C7
-
What about the DC pin? Should be connected to gnd, not floating.
That display has very weird gnd traces. The gnd plane is connected only in the pads where the oled is hold, then everything else is routed to gnd using thin traces.
-
I tried all the firmware, the display does not work normally. But even the firmware from the github works with 2k2 resistors. DC is connected to the ground.
-
Do you have oscilloscope? Watching the signals would be nice.
Try also 1K or 470ohm resistors, it won't cause any harm.
Check this:
https://www.youtube.com/watch?v=uPWzL_MZ4q4 (https://www.youtube.com/watch?v=uPWzL_MZ4q4)
-
I didn't say they are connected to the VCC, they are actually connected to ground.
-
David, I watched the video, you gave the link to it. I noticed that all resistors that are installed in positions R9-R12 have a nominal value of 0 Ohm, and not 4k7, as I installed according to other information on the Internet. Comparing the two wiring diagrams of this display for SPI and I2C, I noticed that there are no R9-R11 resistors in the diagrams. But on the connector 24 for the I2C version there are jumpers on pins 5-6 and 14-15. This means that it is correct to use 0 ohm resistors and not 4k7. I replaced the 4k7 resistors with 0 ohms. The image became more stable (firmware 21-10-12a with github), but I still had to install 2k2 resistors for SDA and SCK. Now I do not see the image slowing down. If this happens, I will change the SDA and SCK resistors to a value of 1k. Thanks for the help!
-
Give another try to the tests to find if I can optimize the timings further.
So no image corruption with 2k2?
-
Hi together,
I'm looking for some "cartridge based" soldering solution for quite some time already. Just had too much soldering jobs lately where my old Weller was not up to the task with big ground planes and non existent thermal relief.
After some searching I found these cheap STM32 based stations. Seemed to be a good choice for the price and should perform better, right?
To benchmark I used a big copper plated PCB like in one of the EEVBlog videos where Dave did the same test. My Weller on 300 °C can't really solder on this. I can just pile up some solder. But neither can the T12 clone... The display keeps telling me that I am still at 300 °C but I can barely get solder to melt.
So what could I do next? Does the custom firmware improve the regulator to a way that it performs better in challenging situations? Do the T12 clone tips suck and I should get legit Hakko ones? Or is it better to try a JBC handle on the STM32 station with the CFW?
-
Soldering ground planes at only 300°C...? It's very low for most soldering stations.
Maybe a genuine C245 tip could do that.
Improve what? If the tip has bad thermals, there's no way to know what the real temperature is, the internal sensor reads 300°C.
These jobs require 400°C when using T12 tips. Most tips can't transfer enough heat, so you need to compensate by increasing the delta (difference between hot and cold).
The board won't see 400°C...
Also, It heavily depends on the tip model. Don't expect Soldering ground planes with a small or thin tip.
Edit: and if it's lead-free...much worse, as the melting point is around 235°C instead 180.
-
With 2k2 resistors in SDA and SCK, the following firmware works fine:
KSGER_V2_I2C_Test_H10_L08_92fps
KSGER_V2_I2C_Test_H10_L04_128fps
KSGER_V2_I2C_Test_H14_L08_83fps
KSGER_V2_I2C_Test_H14_L04_92fps
KSGER_V2_I2C_Test_H18_L08_76fps
KSGER_V2_I2C_Test_H18_L04_83fps
KSGER_V2_I2C_Test_H22_L12_65fps
KSGER_V2_I2C_Test_H22_L08_70fps
KSGER_V2_I2C_Test_H22_L04_76fps
KSGER_V2_I2C_Test_H30_L08_61fps
KSGER_V2_I2C_Test_H30_L16_48fps
KSGER_V2_I2C_Test_H40_L08_52fps
KSGER_V2_I2C_Test_H40_L16_42fps
KSGER_V2_I2C_Test_H50_L08_44fps
KSGER_V2_I2C_Test_H50_L16_38fps
firmware does not work (image is distorted):
KSGER_V2_I2C_Test_H22_L01_82fps
KSGER_V2_I2C_Test_H18_L01_91fps
KSGER_V2_I2C_Test_H14_L01_102fps
KSGER_V2_I2C_Test_H10_L01_140fps
-
Ok, one last try, slightly increasing H time to have some margin.
This might become the new timings, so other ksger v2 users, please try it...
For me it works with the standard 10K resistors, no modifications.
Edit: File removed, please refer to this post (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3747094/#msg3747094)
-
Soldering ground planes at only 300°C...? It's very low for most soldering stations.
That's the video I was talking about: https://www.youtube.com/watch?v=scvS2yeUH00 (https://www.youtube.com/watch?v=scvS2yeUH00) And Dave actually used even less temperature in his test.
Maybe a genuine C245 tip could do that.
Maybe. Currently I don't really know where to invest my money in. Completely give up with T12 tips? Get more of them? Probably genuine ones? So far I have the two tips that came with the station (T12-K, T12-BC2) and one T12-D08 I ordered from a different supplier. All "non-genuine" tips. And in my test the T12-D08, that just arrived, already performs somewhat better than the T12-BC2 I did the initial test with.
So far I used a Weller WS 81 station including several tips. And at least from my experience the idea of having a really short tip just sitting flat to the heating element with a pretty tiny contact surface seems to be not the best idea. In almost all other similar heat transfer jobs, you would put some thermal grease to such a joint but I think this will get very messy if it is used in this situation.
Improve what? If the tip has bad thermals, there's no way to know what the real temperature is, the internal sensor reads 300°C.
So far I have not changed my "china station" at all. It runs stock firmware. And it makes me a bit suspicious that it always shows 300°C no matter how big the "heatsink" is. So either the tips are that bad or the firmware "hides something". I expected at least a small dip in temperature and probably a small overshoot once the tip is removed from the heat sinking surface. Will replacing the stock firmware actually bring in a better temperature regulator or can I expect the same performance as with the stock firmware?
These jobs require 400°C when using T12 tips. Most tips can't transfer enough heat, so you need to compensate by increasing the delta (difference between hot and cold).
That's exactly what I really want to get rid of. Unfortunately the last board that was really difficult is properly mounted in a case, now, so I can't take a picture, but there I always had to vary the temperature. Somewhere above 400°C for the ground connecting pads and then back to 300°C to do the pads with proper thermal relief. And no, I did not always remember this process and once you touch a "non heat sinking" pad for a second too long you already damaged the board |O
Also, It heavily depends on the tip model. Don't expect Soldering ground planes with a small or thin tip.
So we are back to the question about where to spend my money at. Get some wider T12 tips?
Edit: and if it's lead-free...much worse, as the melting point is around 235°C instead 180.
I use lead free solder with a pretty big amount of silver to get the melting point down.
-
Ok, one last try, slightly increasing H time to have some margin.
This might become the new timings, so other ksger v2 users, please try it...
For me it works with the standard 10K resistors, no modifications.
Yes it works. I tried to remove the 2k2 resistors and leave 4k7 - my display does not work. :( I returned 2k2 back.
-
If you want Soldering Iron comparisons use this channel: https://www.youtube.com/c/Sdgelectronics (https://www.youtube.com/c/Sdgelectronics)
Edit: here is the playlist
https://www.youtube.com/watch?v=AMvZfOWkApw&list=PLZzwMlLVLdOBBz8pwjt9CJhEJFYVfHSH2
-
I don't know how the factory fw works, but mine can put almost 100% power if the temperature doesn't match the setpoint even by 1°C, the pid integral will keep rising and rising, but only if the tip is able to transfer the heat.
Yes, stock fw hides the real temperature because it probably bounces more than a kid in a fun fair.
I've recently added a small filter (5°C) to remove these annoying constant little changes, but the real temp will be shown when the threshold is surpassed.
Give it a try, you have original backups to revert.
All I can say is T12 are a very random thing, some perform a lot better than others, even smallers doing better than bigger ones.
The main issue comes in the TC bonding with the tip.
If poorly bonded, it'll read the heater temperature, instead the tip body, I've had tips reading 300°C under water, while others did much better.
Also they calibration can vary a lot, more than 50°C.
New tips are often a bit unstable, after a while they start working nicely, and few months later they start losing thermal performance.
I'd get a beefier 150-200w 24V power supply and mod the station to use JBC.
Also, I've heard JBC overshoots on purpose when detecting load, so when you think you're soldering at 300°C, it's actually rising the temps to compensate, but I can't verify that.
My fw doesn't do that because I can't trust these T12 tips, they all behave different, so better stay in the safe side.
You have the boost option which increases the temperature for a specified time and returns to normal, so you'll hardly damage anything by forgetting.
Anyways, the temperature control is pretty good, I've used it a lot at 380-400 and even 450°C when using small tips to solder grounded pins, and very rarely damaged anything, only when applying excessive force and other screw-ups caused by me.
If you want Soldering Iron comparisons use this channel: https://www.youtube.com/c/Sdgelectronics (https://www.youtube.com/c/Sdgelectronics)
Edit: here is the playlist
https://www.youtube.com/watch?v=AMvZfOWkApw&list=PLZzwMlLVLdOBBz8pwjt9CJhEJFYVfHSH2
He should re-test the performance with the newer pid and filtering algorithms, I thing it'll do better now.
-
Yes it works. I tried to remove the 2k2 resistors and leave 4k7 - my display does not work. :( I returned 2k2 back.
Nice!
I'm sorry but... I found that slightly changing certain parts of the code boosted performance up to 20-25%.
Ex. software SPI went from 600 to 920fps. I2C needs to got slower, but the data processing before toggling the pin is now faster.
So, I need another few test to recalibrate the timings again... This is the last one, I promise! :D
The H value now is (~)equivalent to older H+3. Ex. older H10 is now H7.
The L is the same.
Check it thoroughly. Sometimes there're little blips, random pixels... it doesn't always fail completely.
Edit: Deleted file (now useless)
-
With 2k2 resistors in SDA and SCK, the following firmware works fine:
KSGER_V2_I2C_Test_H10_L04_129FPS
KSGER_V2_I2C_Test_H09_L04_137FPS
KSGER_V2_I2C_Test_H08_L04_142FPS
KSGER_V2_I2C_Test_H07_L04_148FPS
KSGER_V2_I2C_Test_H06_L04_153FPS
KSGER_V2_I2C_Test_H05_L04_165FPS
firmware does not work (image is distorted):
KSGER_V2_I2C_Test_H10_L03_135FPS
KSGER_V2_I2C_Test_H10_L02_141FPS
KSGER_V2_I2C_Test_H09_L03_141FPS
KSGER_V2_I2C_Test_H09_L02_147FPS
KSGER_V2_I2C_Test_H08_L03_147FPS
KSGER_V2_I2C_Test_H08_L02_155FPS
KSGER_V2_I2C_Test_H07_L03_155FPS
KSGER_V2_I2C_Test_H07_L02_163FPS
KSGER_V2_I2C_Test_H06_L03_163FPS
KSGER_V2_I2C_Test_H06_L02_171FPS
KSGER_V2_I2C_Test_H05_L03_171FPS
KSGER_V2_I2C_Test_H05_L02_179FPS
KSGER_V2_I2C_Test_H05_L01_188FPS
KSGER_V2_I2C_Test_H05_L00_200FPS
-
Thanks. I'll take the next slowest one, also increase slightly to L05.
Can anyone test KSGER_V2_I2C_Test_H06_L04_153FPS in a Ksger v2?
-
Can anyone test KSGER_V2_I2C_Test_H06_L04_153FPS in a Ksger v2?
Looks good.
-
Thanks. I'll take the next slowest one, also increase slightly to L05.
Can anyone test KSGER_V2_I2C_Test_H06_L04_153FPS in a Ksger v2?
https://disk.yandex.ru/i/iZlp37DM_bdo-g (https://disk.yandex.ru/i/iZlp37DM_bdo-g)
-
New builds using H06 L05.
Enjoy your new staggering 153 fps of power :D
I got tired of manually updating the build version everytime.
Following builds will use the automated __TIME__ C preprocessor macro, which generates something like "Oct 14 2021"
-
I know wickated is going to try the 140fps version right away.. ;)
Edit: File removed
nooooo, where is mine 9000 fps supermegaturbohighoctane edition
tested final build. i2c screen works ok with 20cm nontwisted wires
-
Current build is even faster :D
That's crazy, is It working with default 10K pullup resistors?
-
Current build is even faster :D
That's crazy, is It working with default 10K pullup resistors?
yep, all default with wires right over transformer.
latest builds looks like having even less jitter. compared to very old build where screen temp had permalock. looks like it was also linked with power limiter and it didnt worked either. now power limiter works ok.
cant be ever sure before since had huge voltage sags on my unregulated PSU, now no sags and power bar moves smooth
p.s. turkish translation :-+
-
It came a year later, but I finally figured out how to trigger CubeMX code generation from the command line.
Now the build script is completely unattended.
-
Give it a try, you have original backups to revert.
Finally managed to do it. I forgot that st-flash can't directly flash to locked controllers for some reason. Had to use openocd for unlocking, first. Then flashed with st-flash.
All I can say is T12 are a very random thing, some perform a lot better than others, even smallers doing better than bigger ones.
The main issue comes in the TC bonding with the tip.
If poorly bonded, it'll read the heater temperature, instead the tip body, I've had tips reading 300°C under water, while others did much better.
Also they calibration can vary a lot, more than 50°C.
The T12-D08 seems to be a bit dodgy. With original firmware it showed "Error" every time I started the station with this tip until it finally settled to some usable temperature.
With the custom firmware the 250°C setpoint was way off while calibrating. Measured was around 300°C which was not accepted while calibrating, so I had to manually adjust it a bit, first. For some reason the 400°C setpoint was way better and needed almost no adjustment...
If I set the station to 300°C and try to solder to a ground plane, then the tip cools down to a point where it is impossible to melt solder while the station still says 300°C without any major changes when touching or removing the tip from the ground plane.
When putting just the tip under water, then the station can heat to around 290°C. So somewhere around 190°C get lost.
I've ordered one original tip, now, just to see how they perform. What I've seen, so far, is not the performance I'm aiming for.
-
only d52 or c4 are suitable for big solder pads. d08 is for througholes only. i used dl32 and wd52 and c4, other tips (even genuine K) arent suitable for heavy soldering.
-
The default calibration is generic, close enough to be usable, but it will be wrong for almost every station.
It's just impossible, each one is different. For the stlink, all it takes is connecting the nRST pin.
You can -absolutely- forget about soldering anything heavy at 300ºC with most T12 tips, and D08 is a toy for small pins.
Made few updates:
- Made NTC settings profile-specific, so now each profile can have it's own NTC settings. Moved NTC menu to iron screen.
So now T12 can have NTC enabled, and C245/C210 have it disabled to use stm32 internal sensor.
- The NTC detection was not working as I thought. Fixed.
Edit: Since now NTC is profile-specific, it makes more sense to show NTC error if NTC is enabled and not detected, and use internal sensor only if disabled.
Otherwise you won't notice there's a problem with the NTC.
So, for profiles/handles without NTC, disable NTC to use internal sensor.
- Improved the error screen. Only show other errors when iron is detected, otherwise, only show the iron detection graphic.
After all, other errors are irrelevant without iron.
- Improved the main screen drawing.
Sometimes, an error could suddenly appear while drawing it, so it was too late to notice.
The system could get wrong readings and display them until the next frame was drawn, causing a brief flash.
Now, after drawing to the screen buffer, it will check for errors, and skip screen update if detected. So no more flashes.
- Fixed a small bug in the main screen when DEBUG is enabled, returning to the wrong position.
- I had messed up something (again) in Farenheit temps.
-
Does anyone know a good source for the T12 handle where the tip sits deeper in the housing to have better control when soldering smaller stuff?
I'm searching for this one: https://www.banggood.com/-p-1305799.html (https://www.banggood.com/-p-1305799.html)
But this offer does not include NTC and tilt switch.
I want to get it delivered to Germany. And I can't order from Aliexpress as they for some reason disabled my account and now want a phone number (which I won't give them).
-
you can just type "ksger" in search window and select any handle u prefer :-//
-
I'm looking for some handle that does not get excessively hot even with the "reduced tip length". So probably not the aluminium one because aluminium conducts heat very good (bad isolation for my fingers).
I've searched with all kinds of search terms on Banggood but could not find something that fits this. But there are many offers on Aliexpress... I have a friend who regularly orders stuff from Aliexpress. I guess I'll just tell him what I need and ask him to place the order.
-
12euro + shipping just for the plastic parts? You're better off buying the fully assembled one here https://www.banggood.com/-p-1613852.html (https://www.banggood.com/-p-1613852.html)
Meh, I remember those were sold for like 7$ on AE a couple years back...
-
i use the black aluminum one but i put the foam sleeves from the jbc 245 on them the green ones stays cool enough for me imo i just prefer the feel of that one to the plastic one
-
I have the alu handle, don't recommend, it'll cook your fingers.
The cheap blue handle does ok, only 5 euro /$6 (Without cable). That's damn expensive in the link your provided!
https://es.aliexpress.com/item/32871508100.html
-
i have handle that has both alu and plastic versions absolutely identical.
alu is warm but stiil workable
plastick one actually melted :-DD
-
Most of the firmware development was done with the plastic one...never had any isssue. And it had a LOT of use.
Until I bought the aluminium handle because I thought it was better :palm:
I don't change it because I'm lazy, until something breaks or explodes...
-
i have used the aluminum for hours imo it gets a bit hot but nothing crazy. once i added that jbc sleeve thing on there its perfect imo
-
Had some time to cleanup the code, there was quite a lot of old/useless/redundant bits remaining.
I caught few bugs related to changing temperature unit, thus strange values could appear in some temperature fields.
I was using absolute temperature conversion instead relative temperature (You don't add/remove 32 when converting relative temperature between C and F).
Also, I'm testing something, but I might revert it.
I disabled endless rolling, like numeric input widgets do, for multioption widgets (those which fields are labels, not numeric, like "SLP","STBY","RUN").
So once you reached the end, it stops there instead goign to the start. Gives a little better control when adjusting them.
Enhanced the tip name editing, now you can also move the char position using the push and rotate method.
So if you missed a letter, you can click and rotate to the left to edit it, instead requiring a lot of clicks to exit editing mode and editing again.
Or move 3 positions forward to edit the last character.
Finally, I applied the boost mode behavior from the setpoint widget to the plot graph screen.
A single rotation step will do nothing at first, but it will actually set a timer for enabling boost mode.
Clicking within a second will trigger boost mode.
After the first rotation step, subsequent steps will start to modify the setpoint (like it did before), disabling the boost flag,
requiring to stop adjusting the setpoint for 1 second to rearm boost again.
It's not very useful, but now you can see the boost response in real time, in the plot graph.
-
I used firmware 21-10-14 and then 19 Oct 2021. Display 2.42" glitches occur from time to time, for example, the image becomes mirrored vertically. I went back to the test firmware 21-10-12a KSGER_V2_I2C_Timing.bin that David made for me.
The display works more stable with this firmware, I will test it further.
-
Maybe I tightened too much the timings. I'm already going way over the 400KHz theorical speed, so it could be the controller itself.
Try this. It's the normal fw, keep using it for a few days and ensre there're no artifacts. If all goes ok, I'll update the timings.
The priority is making it work will any display, the functionality is over the performance.
-
I installed 1k resistors for SDA and SCK, and also increased the nominal capacities for STM32 power supply to 1 μF. Looked at what the oscilloscope shows (Oscillograms correspond to firmware Oct 19, 2021.) ... if I knew what should be .. ::)
Installed your latest firmware on Oct 20, 2021.
And even repainted the case (it was glossy, it became matte). ;)
So far, everything is fine. I'll see what happens next.
-
I need both at the same time, and the lower plot (That's SCL, serial clock) zoomed in to clearly see the transitions.
Did try the firmware I posted?
-
The signal is non-periodic, I cannot synchronize. Maybe I can later.
Yes, I installed your firmware Oct 20, 2021, while it works well, frames are not distorted, there is no mirror effect. I will test further.
-
Just do a single shot until you find one that looks nice
-
My green 2.42 OLED firmware * KSGER_V2_I2C_timings ++.
-
Such an image error. It is stable, disappears only after turning the power off and on.
-
wouldnt it be much easier to rewire to spi and make special LTS build for ksger2_spi ? i remember there was a try with rewiring to test i2c hardware mode.
-
Nope, no custom support from my side. The're instructions to do so.
I'm not going to spend my time with custom builds for a number of reasons.
One of them is most people will think "this is just like wiring leds". Flying wires with 18MHz signals is asking for problems.
Then I'll have to spend my time here, again explaining concepts like signal crosstalk, capacitive coupling, inductive spikes, ringing, impedance, slew rates, signal shielding.
I like supporting this firmware, but not waking up everyday and having to give support like if I was selling it.
This case is just i2c compatibility. This is a display that uses the same interface and command set, so it should work.
If it fails, it's my fault for exceeding i2c specifications.
I think the layout in these displays is not good for high frequencies, they have long traces, going to multiple places, instead of going from A to B and putting the resistors somewhere in the middle.
So the frequency must go down.
Next try.:
-
OK, thanks!
-
Over the weekend I solder this PCB board, a slightly modified OP AD8551 and a bluepill stm32 board.
-
Nice job! Try the same fw I made for Polf :-+
-
I will use that FW for my PCB, even on a bad test board it works well (a little text shifted to the right). Consumption 2.42 OLED green about 150mA.
-
The text shift is a different thing. Seems you didn't read the project readme - You have an option to adjust that, try it.
-
After using the station a bit I have to say that it is working really well. And yes, the original tips are better. The one tip, I got so far, worked perfectly right from the start. No ugly temperature readings. The tip was heated at least once when manufacturing (minor blue coloring of the tip portion where the heater is). Hakko clearly has something that is usually missing for cheap china clone stuff: Quality control. I think at least for me this is worth the extra money.
But I'm still planning to get another handle. Don't like the thing that came with the station. I would really like to run an original Hakko iron on this station but hell are they overpriced!
What I don't like at all is the shake sensor. While doing a longer solder job I had to really shake the handpiece several times to make the station wake up. I've now disabled the filter for the sensor in the settings and I hope it is more sensitive now.
I'm unsure if I really like this whole shake sensor idea. Hakko has a switch on the iron stand. The station enters "sleep mode" immediately once the iron is placed in the stand. Has someone here ever replicated this? At least the settings allow to change the wakeup method to "stand". Where would I have to wire this in? Do you use a different digital input? Where can I find this on the board?
-
The filter is for extremely sensitive sensors, where the smallest vibration in the table would wake up the station.
It's time filtered, shaking it like crazy won't work, you have to shake the handle in a way that the sensor changes happen between 400ms or so, ex like when you clean the tip.
You'll find the correct timing easily, it only needs some practice, or you can simply disable it..
Sure, you can use it in stand mode, it's nicely explained in the project Readme, it's the same input but wired differently.
Nice to know the original tips performance... but for what they cost, I'd get C245.
-
I, for one, replaced the stock ball based sensor with a much more sensitive mercury switch. Because of the angle, it never triggers in the stand but does easily while working. TBH I also thought my sensor was busted after the filter was implemented and I didn't know about it. For me, the filter makes it extremely awkward, like I have to actively shake or tilt the handle in weird positions during work so it won't go to sleep. But I guess you can't accommodate everyone with every sensor type and every use case so I'm happy to leave it disabled.
-
looks like u just placed shakyshaky upside down.
shake sensor input should be never triggered while handle in hands. so u have sleep timer counting 5 mins or so. if u need longer work u just point tip in the ceiling and back.
stand input is very easy to do
-
Next try.: KSGER_V2_I2C_timings_2.zip
I have been testing for 2 days. Everything is fine, it works very well. There are no questions.
-
OK. Next builds will have the shake filter disabled by default and the new i2c timings.
-
FW KSGER V2 I2C timings 2 works equally well for me.
-
looks like u just placed shakyshaky upside down.
shake sensor input should be never triggered while handle in hands. so u have sleep timer counting 5 mins or so. if u need longer work u just point tip in the ceiling and back.
stand input is very easy to do
That's exactly why I replaced the SW200D with mercury. Mine works basically like stand mode, I set a 1min timer and never think about it.
-
I prefer the mercury switch because it's quiet... Just solder it pointing down when in stand, or in the direction of the tip.
-
I've been playing with the pid/filter values. They're made for the default PWM/ADC frequency (200ms).
Everything affect everything, tunning the system takes a hell of an effort, but eventually it can behave great.
I get almost square response, with only 3-5ºC over shoot for 1/2-1 second, works with almost all tips.
I must mention that's with used tips which aren't so noisy. Probably will go crazy with new tips (Tip: Set Imax very low or close to 0 for new tips).
This is shows how filtering, pid and tips are extremely linked together.
Settings that worked with new tips became unstable as they aged up.
I don't know how this settings behave with new tips.
FILTER MENU:
- Filter: 75%
- Threshold: 40
- Count limit: 0
- Step down: -3%
- Min: 40%
- Reset limit: 600
PID:
- Kp: 55.00
- Ki: 110.00
- Kd: 8.00
- Imax: 0.75
- Imin: 0.00
https://m.youtube.com/watch?v=h1DmABDAlR0
-
What I don't like at all is the shake sensor. While doing a longer solder job I had to really shake the handpiece several times to make the station wake up. I've now disabled the filter for the sensor in the settings and I hope it is more sensitive now.
The motion sensor should be closed when the soldering iron handle is turned down. In some soldering iron handles, the opposite happens.
Perhaps the reason is this.
-
What I don't like at all is the shake sensor. While doing a longer solder job I had to really shake the handpiece several times to make the station wake up. I've now disabled the filter for the sensor in the settings and I hope it is more sensitive now.
I checked too.
Profile T12, firmware Oct 19 2021. In the menu System the Filter is ON. Awakening from the motion sensor occurs only by shaking it several times with a soldering iron. With Filter OFF, the wake-up occurs immediately after changing the position of the soldering iron.
The motion sensor is closed if the handle is turned down.
-
I'll give this a try for some time with the filter disabled, but I've now also ordered the handle with the shorter "hand to tip distance" and the corresponding iron stand. I guess there are several ways to mod this stand to have a switch added which is triggered with the iron weight.
After all I think that adding a switch is more work (as this is not the stock configuration and the sensor is already built into most handles) but it is still the better way to do it. In this case I actually don't need any timeout at all. If the iron is in its stand the station can go to "sleep" immediately. Probably (if possible) I'll enable the filter in this case to filter out contact bounce from the stand switch.
-
Pretty sure stand mode tracks whether the sensor/switch is in on or off state whereas shake mode resets timer every time there's a change in state (going from on to off or off to on). Replacing the tilt switch - that's quite honestly unfit for the job - with an actual vibration switch might be a good solution too. Though, picking one with the "perfect" sensitivity may be a challenge.
-
Correct. As the name suggest, Shake mode reacts to any change.
-
After all I think that adding a switch is more work
if u bought stand of this type all "work" is wrapping 1 wire to stand
-
if u bought stand of this type all "work" is wrapping 1 wire to stand
I assume you also have to ground the handle, and the wire to the stand would be the switch wire?
P.S. anybody actually test these power supplies to verify if the indeed rated for 24V 5A?
https://www.aliexpress.com/item/32854397476.html (https://www.aliexpress.com/item/32854397476.html)
-
Why test them? For T12, 4 Amperes is enough, so this power supply will do. But for JBC C245 even 6 Amperes is not enough.
-
ive used this one when i needed to replace the ksger one that blew up before has been working without issues https://www.aliexpress.com/item/33037808888.html?spm=a2g0o.cart.0.0.70fa3c00VjJiPp&mp=1 (https://www.aliexpress.com/item/33037808888.html?spm=a2g0o.cart.0.0.70fa3c00VjJiPp&mp=1)
https://www.aliexpress.com/item/32998949310.html?spm=a2g0o.detail.1000014.4.f5993261hcALF1&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.33416.213724.0&scm_id=1007.33416.213724.0&scm-url=1007.33416.213724.0&pvid=a4eea926-c658-4972-87ac-986a6c2ac388&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.33416.213724.0,pvid:a4eea926-c658-4972-87ac-986a6c2ac388,tpp_buckets:668%232846%238114%231999&&pdp_ext_f=%7B (https://www.aliexpress.com/item/32998949310.html?spm=a2g0o.detail.1000014.4.f5993261hcALF1&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.33416.213724.0&scm_id=1007.33416.213724.0&scm-url=1007.33416.213724.0&pvid=a4eea926-c658-4972-87ac-986a6c2ac388&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.33416.213724.0,pvid:a4eea926-c658-4972-87ac-986a6c2ac388,tpp_buckets:668%232846%238114%231999&&pdp_ext_f=%7B)"sceneId":"23416","sku_id":"66978618242"%7D
-
Hi David, is there any particular reason why the encoder is set to REV by default?
-
It shouldn't... Does it use that value after resetting defaults?
-
It shouldn't... Does it use that value after resetting defaults?
Yes, on clean install after total chip erase and also after reset all. It occurs in both KSGER 1.5 and 2.x builds.
-
I renamed the typedef labels, as "mode_Zero" and "mode_One" made little sense, to "Mode_Reverse", "Mod_Forward".
Obviously, did it wrong, renaming mode One(Forward) to reverse ::)
I have very little time for testing! I'm a mess :P
-
Just out of curiosity: How big would a power supply have to be to drive a JBC C245?
And how would it be wired into the T12 controller? I think I've read somewhere that it can't just be connected to the T12 connector but needs a modification to separate the thermocouple sensing, right? Can the existing FET handle the increased current or would I have to replace it? How do you handle the missing NTC? Or does the C245 handle actually have a NTC inside it?
-
Just out of curiosity: How big would a power supply have to be to drive a JBC C245?
And how would it be wired into the T12 controller? I think I've read somewhere that it can't just be connected to the T12 connector but needs a modification to separate the thermocouple sensing, right? Can the existing FET handle the increased current or would I have to replace it? How do you handle the missing NTC? Or does the C245 handle actually have a NTC inside it?
I first connected the 6 Ampere power supply unit (tested, it actually gives out 6 Amperes), but this is not enough, the power supply protection is triggered. Then I plugged in the 12.5 Amp power supply, it works well.
The T12 thermocouple is connected in series with the heater, the C245 has a separate thermocouple lead, therefore, for example, the KSGER controller v. 2.1s has a jumper that needs to be switched to use the JBC tips. As in other controllers, I don't know.
In the KSGER controller in v. 2.1s installed MOSFET TPC8107 with a maximum drain current of 13 Amperes. The C245 heater has a resistance > 2 Ohms, so the current through it cannot exceed 12 amperes. Therefore, there is no need to replace MOSFET. I use homemade controllers similar to KSGER v. 2.1s, but MOSFET installed IRF9310, which has a maximum drain current of 20 Amps.
-
Quicko (not quecoo) handles it fine.
The 108W (Actually 120W design) power supply drops to ~20V, but else than that, it doesn't overheat or shutdown, seems to limit the current to ~7.5A.
The AOD403 mosfet handles >55A (70A at 25°C), 200A pulsed.
It needs a small modification which can be seen in the schematics folder on github.
-
...found some Original Backups even Ksger 3.1
Not tested by me!
-
I can't imagine someone ever wanting to downgrade back to ksger's firmware though. ;D
-
Suddenly most of my tips are behaving very erratically. All expect one! Some of them used to work fine without adjusting anything. And some are not barley used although not new.
I think something is wrong with my board. Where should I start looking?
I have a ksger v3.1. I was using an older version of the firmware, and just updated to the new version but it's the same behavior. The board powers the tip for a second, it overshoots 100 degrees and slowly comes down to continue the cycle.
Edit: The one tip that worked, looks like after a few minutes of operation the behavior is exactly like the other tips.
(https://i.imgur.com/kTClJSV.jpg)
Looks very similar to this board from David's github:
(https://raw.githubusercontent.com/deividAlfa/stm32_soldering_iron_controller/master/BOARDS/KSGER/%5Bv3%5D/Schematic/Board.jpg)
-
I can't imagine someone ever wanting to downgrade back to ksger's firmware though. ;D
only needed when u use 2.1s with solder pump attachment board. but actually who uses desolder guns? cost like a truck, work only a bit better then copper braid wire.
-
Don't forget the handle, the contacts can wear out or corrode.
I guess you already tried Factory reset?
...found some Original Backups even Ksger 3.1
Not tested by me!
Are they different from the ones in github?
-
Yes. And I also tried an unused new handle. Same problem.
-
and what about opamp?
-
If you mean the 8551 SOT23-5, I didn't check it, don't know how, and don't have a replacement for it.
-
u dont have 8551, u have shitty 621 one. first to change.
-
u dont have 8551, u have shitty 621 one. first to change.
From the message it is 8551 (top picture). 621 (bottom picture) is from the picture dark_hawk said it is from David's github.
-
dark_hawk: how about a good picture from the other side of the board? Maybe something near the pinout for upgrade? Did you use some kind of conductive paste?
Another option: downgrade to original FW just to see if it has anything to do with SW or HW.
-
I don't think it's the software if it has worked well until now.
He updated the fw after the problem appeared, trying to solve it.
Maybe some ceramic capacitor has failed.
There have been few cases of badly soldered caps, or broken.
Recently one failed on my Quicko, the one that filters the handle Shake sensor, it developed 6K internal resistance.
I'd rework the solder joints, and add/replace the LDO/stm32 caps.
If you have oscilloscope, check the op-amp output and the power rails...
-
...found some Original Backups even Ksger 3.1
Not tested by me!
Are they different from the ones in github?
I dont see any for Ksger 3.1 on github
-
It seems it has been resolved by a complete erase from the STM32 utility. It now works fine. I don't know the reason why a complete erase from the utility would differ from a new flash which does an erase or an All Reset.
A question: When setting the zero value in calibration, when I start the board the first time, the temperature in the debug menu is around 30, 6 degrees above the ambient with an adc around 30. If I left the debug menu running (set at zero) it slowly rises in a few minutes to reach around a 100 degrees!
Which value should I be using for zero in calibration ?
-
...found some Original Backups even Ksger 3.1
Not tested by me!
Are they different from the ones in github?
I dont see any for Ksger 3.1 on github
i posted the hex file a while back and someone else posted the backup later on so they have both been posted in this thread already.
-
It seems it has been resolved by a complete erase from the STM32 utility. It now works fine. I don't know the reason why a complete erase from the utility would differ from a new flash which does an erase or an All Reset.
A question: When setting the zero value in calibration, when I start the board the first time, the temperature in the debug menu is around 30, 6 degrees above the ambient with an adc around 30. If I left the debug menu running (set at zero) it slowly rises in a few minutes to reach around a 100 degrees!
Which value should I be using for zero in calibration ?
I, for one, power up the station without tip then go straight into calibration menu. There, the MOSFET is turned off and I can insert a cold tip, then enter calibration settings where I capture the ADC value for zero. That value should not change more than a couple points when you try multiple times.
If your ADC drifts that much with the MOSFET turned off, there's definitely a hardware issue, most likely the opamp. I'm assuming the reading is the problem but if the MOSFET turns on when it should be off, then it's what drives the MOSFET that's faulty.
-
Yep, that's how it's done.
You might get small variations depending on the tip and the station temperature , but usually no more than 2-3°C.
About the strange 100°C drift happening in the debug menu: Is the tip actually getting any warm?
-
That erase thing wasn't it, It worked for a while and then started acting up again. It was a dodgy solder joint on the board. Not the one in the picture but another one I didn't see, but I resoldered all the joints again and it seems to be working now.
[attach=1]
The zero value seems to drift from 33 when just starting the board to 42 in 40 minutes, and seems stable at 42 for the last 10 minutes at an adc of 135.
Should I change it? And if so, what are the compatible part numbers, I can search the scarp boards I have I may find one.
-
Uhh... ???
What is 32...44? °C?
135 ADC value when reading 44...°C?
Typically you calibrate when the system has fully heated up and got stable.
Some drift is normal as the handle/board heat up, it's working with very small signals and there's no compensation of any kind, few tens of microvolts are enough to change the readings slightly.
Given the way they're made, that's more a design issue than a hardware failure.
If not done yet, I'd redo the soldering joints of every single smd resistor, capacitor...
-
Uhh... ???
What is 32...44? °C?
135 ADC value when reading 44...°C?
Typically you calibrate when the system has fully heated up and got stable.
Some drift is normal as the handle/board heat up, it's working with very small signals and there's no compensation of any kind, few tens of microvolts are enough to change the readings slightly.
Given the way they're made, that's more a design issue than a hardware failure.
If not done yet, I'd redo the soldering joints of every single smd resistor, capacitor...
Yes, 32 to 42 degrees °C. 135 is the ADC value at 42 °C.
Is there a way to enter the zero value manually instead of capturing it? I'd have to power the board for half an hour and wait for it stabilize.
I re soldered the ics and few of the smd resistors/capacitos. I will take it apart again and do the everything.
-
Is there a way to enter the zero value manually instead of capturing it? I'd have to power the board for half an hour and wait for it stabilize.
just work with station keeping spare cold tip nearby. switch and recapture
-
Minor cosmetic feature request:
Add JBC iron picture for no tip error screen, station shows JBC iron picture when station is set to JBC type handle and/or T12 tip when set to T12 handle.
-
Without having had a chance to read much of this 95 page long thread yet (I have looked at this github page https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled)) which aliexpress irons are suggested buys at this point, or could someone direct me to a page of this thread where that was discussed? I was looking at this KSGER V2.1S https://www.aliexpress.com/item/33006521566.html (https://www.aliexpress.com/item/33006521566.html) as the PCB on shown on aliexpress looks like the recommended one "Original version of the v2.1S hardware. This is the preferred hardware for v2.1s ..." from the github page.
Thanks
-
58eur/$67 for a DIY kit, ,comign with the crappiest plastic handle? To me, it seems very expensive, and a try of charging twice trying to get extra profit of the silicon crysis.
There isn't a design that's notoriously better than others., everything is just the same, don't get fooled by a fancy alluminium bezel.
The major changes come in the 3.3V regulation. Some KSGERs (2.0, 2.1, 2.1s.. uhh... I don't know which ones right now) use a cheap design where they convert 24V to 3.3V with a linear regulator, causing a lot of heat.
For some boards it's too much, the LDO overheats and causes weird behavior like random resetting. But the analog front end is, as far as I know, the same thing in all with minor changes.
Maybe some KSGER fanboys can advice you better, I just see a ton of money for a crappy design ::)
I'd get a KSGER 3.1, Quicko T12, Quecoo T12-955, whatever is cheaper.
Search "aliexpress" in this topic, you'll quickly find some links.
https://www.aliexpress.com/item/4000183089084.html (https://www.aliexpress.com/item/4000183089084.html)
https://www.aliexpress.com/item/32947718640.html (https://www.aliexpress.com/item/32947718640.html)
https://www.aliexpress.com/item/32954334507.html (https://www.aliexpress.com/item/32954334507.html)
-
If you want portability and inexpensive (if you already have the QC3/PD/DC power supply) you can also go with a PINECIL
https://pine64.com/product/pinecil-smart-mini-portable-soldering-iron/ (https://pine64.com/product/pinecil-smart-mini-portable-soldering-iron/)
Here is a smaller/cheaper KSGER 3.1 that requires external laptop DC power adapter (however it does not come with a nice handle, I would buy separately)
https://www.aliexpress.com/item/4000055007842.html (https://www.aliexpress.com/item/4000055007842.html)
-
I own 2 of the v2.1s and they work fine. Main problem is that I cannot compare it to other versions.
David has Quicko so I believe the best support will be for Quicko :-DD
When I measured with thermocam I believe I got something over 50 C on the LDO but it wasn't in the case. It was a little bit worm to touch but nothing big.
On my first v2.1s I used for quite some years I didn't have any kind of problems. Nowdays I mainly use another one that has David's FW and has a lot of probl... I am just kidding, everything works. Even David's FW :-DD
-
all of mine i use are 3.1 versions. they work fine with the newer firmware versions now. i do have some 2.1 controllers but i dont use them as much honestly
-
Anyone tried this handle? : https://www.aliexpress.com/item/4000130747937.html (https://www.aliexpress.com/item/4000130747937.html)
On paper it checks all the right boxes. I mean, it's made of aluminium, has a usable shape, short tip to grip distance, a large silicon sleeve and is suspiciously cheap (compared to all the "nice" T12 handles). So, is it as good as advertised or yet another piece of garbage that burn user's hand or doesn't fit the tip properly?
-
Anyone tried this handle? : https://www.aliexpress.com/item/4000130747937.html (https://www.aliexpress.com/item/4000130747937.html)
On paper it checks all the right boxes. I mean, it's made of aluminium, has a usable shape, short tip to grip distance, a large silicon sleeve and is suspiciously cheap (compared to all the "nice" T12 handles). So, is it as good as advertised or yet another piece of garbage that burn user's hand or doesn't fit the tip properly?
its actually a default fx9501 handle
-
i have one of those handles note it did not work properly with the ksger stations i had to modify the wiring to get it to heat. so it depends what seller you get it from and how its wired ive seen a few different ones.
-
I just say because I've received few reports of the controller going nuts randomly, magically fixed after lowering the screen brightness.
So it must be the LDO, might be overheating, defective, a broken solder joint... there's no way I could know unless the owner works on it, which almost never happens.
An it's not a personal war against ksger devices. It against their inflated prices. They charge almost twice in some cases!
-
I just say because I've received few reports of the controller going nuts randomly, magically fixed after lowering the screen brightness.
So it must be the LDO, might be overheating, defective, a broken solder joint... there's no way I could know unless the owner works on it, which almost never happens.
It didn't happen to mine yet but I hope to remember that if it happen. Thanks.
-
I would like to try to run a real Hakko handle on this station. But I don't want to modify the handle in any way so it can still be used on its original station.
The NTC seems to have a different value but is connected the same way as on chinese handles. So no problem there as the value can be configured in your firmware.
BUT: The original handle has a small capacitor of 100 nF in parallel to the tip contacts. You can see it here: https://uploads.tapatalk-cdn.com/20170812/a70044c1d56aa37c3955395497c75ae1.jpg
I wonder if this causes any trouble with your firmware as the chinese handles don't have this capacitor. Is it possible to run the handle with this capacitor at all?
-
I tried once with an almost identical capacitor, when I was fighting with the sensor noise.
Well, it exploded :-DD, maybe wasn't rated for 25V, I don't know!.
Are you sure the capacitor is connected between the heater pins?
100nF isn't a huge capacitance, but can cause nastly current spikes when driving it with PWM.
I don't know how original Hakkos work, but maybe they use 24Vac, in that case the capacitor wouln't cause any trouble.
-
Speaking of handles, is there a way to use/connect the NTC in a 5 pins handle with a 4 pins station? As I understand it, that's what the 5th pin is for so it's not possible without it but I may be wrong.
-
I guess one big difference could be the frequency which is used to drive the heater. If Hakko more or less measures around two times per second to then decide for how long of the next cycle they enable the heater (effectively 2 Hz PWM), then the capacitor does not change too much. But if you really use the PWM of the controller set to, for example, 1kHz PWM frequency, then the capacitor has a big impact. But as, I guess, noone in this thread actually owns a legit Hakko station for these tips, noone can tell how they drive the heater.
Probably best I keep with the chinese handle. But I really would like to get the original Hakko stand with the switch. I tried to hack my own but unfurtunately had a minor accident because of using improper tools. So I lost interest in creating my own one.
Any chance that someone here can tell me if this handle: https://www.banggood.com/KSGER-FX9501-Soldering-Handle-DIY-Set-Electric-Soldering-Iron-5-Core-Silicone-Wire-p-1305799.html?cur_warehouse=CN&rmmds=search (https://www.banggood.com/KSGER-FX9501-Soldering-Handle-DIY-Set-Electric-Soldering-Iron-5-Core-Silicone-Wire-p-1305799.html?cur_warehouse=CN&rmmds=search) (chinese handle with the short "finger to tip" distance) fits nicely into this holder: https://hakkousa.com/fh200-01-fm-2027-fm-2030-iron-holder-w-599b-tip-cleaner.html (https://hakkousa.com/fh200-01-fm-2027-fm-2030-iron-holder-w-599b-tip-cleaner.html)
-
Hi there,
This is probably a very simple issue but after going through a few dozen pages I couldn't find a similar issue.
I have a KSGER 2.1S model which looks like an exact copy of one of the boards from a photo in the Github repository. (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv2%5D/Schematic/Board.jpg) I program the firmware file labelled "KSGER v2.x, JCD T12, QUECOO T12-955" but find that the station doesn't power up.
I've been able to reprogram it with a copy of the original firmware from the repo (thanks for providing this) and it works perfectly once again, I'm sure there's a simple change that needs to be made for my particular board but I'm just not sure what it could be.
-
Any chance that someone here can tell me if this handle: https://www.banggood.com/KSGER-FX9501-Soldering-Handle-DIY-Set-Electric-Soldering-Iron-5-Core-Silicone-Wire-p-1305799.html?cur_warehouse=CN&rmmds=search (https://www.banggood.com/KSGER-FX9501-Soldering-Handle-DIY-Set-Electric-Soldering-Iron-5-Core-Silicone-Wire-p-1305799.html?cur_warehouse=CN&rmmds=search) (chinese handle with the short "finger to tip" distance) fits nicely into this holder: https://hakkousa.com/fh200-01-fm-2027-fm-2030-iron-holder-w-599b-tip-cleaner.html (https://hakkousa.com/fh200-01-fm-2027-fm-2030-iron-holder-w-599b-tip-cleaner.html)
I do not have a genuine hakko stand like you, but I do have a chinese clone of the stand and that exact iron handle. I am happy to report they do fit together perfectly
-
Speaking of handles, is there a way to use/connect the NTC in a 5 pins handle with a 4 pins station? As I understand it, that's what the 5th pin is for so it's not possible without it but I may be wrong.
I don't how 4 pin handle is connected but in 5 pin handle you have 2 pins connected to ground (on the PCB).
Check here: https://www.aliexpress.com/item/32933941125.html?spm=a2g0o.productlist.0.0.25824e14MR1zrh&algo_pvid=d3e4c3f8-d6a4-42a3-ab41-69b8991642be&algo_exp_id=d3e4c3f8-d6a4-42a3-ab41-69b8991642be-59&pdp_ext_f=%7B%22sku_id%22%3A%2212000022941698495%22%7D (https://www.aliexpress.com/item/32933941125.html?spm=a2g0o.productlist.0.0.25824e14MR1zrh&algo_pvid=d3e4c3f8-d6a4-42a3-ab41-69b8991642be&algo_exp_id=d3e4c3f8-d6a4-42a3-ab41-69b8991642be-59&pdp_ext_f=%7B%22sku_id%22%3A%2212000022941698495%22%7D)
G and E (green and black line) are connected together on the PCB board (check bottom of the PCB where you can see G and E markings near the white connector).
I hope that helps you.
-
I guess one big difference could be the frequency
A discharged capacitor is seen by the output as temporary short circuit until it charges up. For maybe 10us, there'll be a short but tough current spike, easily exceeding 50-80Amps depending on the wire properties and how fast the mosfet is turned on.
As the frequency rises, so does the number of times it happens per second, beating the crap out of the transistor. Any square pulse of any frequency will cause this problem.
With AC, usually you send half waves, so the voltage will start at 0V and rise evently, the power is delivered in a much smoother way, there's no such sudden capacitor charge.
This fw uses 5Hz by default, if the pid and filtering are properly adjusted it works very well.
I have a KSGER 2.1S model which looks like an exact copy of one of the boards from a photo in the Github repository. (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/%5Bv2%5D/Schematic/Board.jpg) I program the firmware file labelled "KSGER v2.x, JCD T12, QUECOO T12-955" but find that the station doesn't power up.
Strange, that's the correct firmware for that board. Anyone having else this issue?
Can you post the log from the programming tool? Try making a full wipe.
The guide to preserve the settings, where you skip erasing the last 2 sectors, is only for settings made by this firmware, so you can update to newer versions keeping everything.
But not for the original firmware, that one stores them in the eeprom, this custom fw doesn't make use of it, so they'll be preserved always.
Speaking of handles, is there a way to use/connect the NTC in a 5 pins handle with a 4 pins station? As I understand it, that's what the 5th pin is for so it's not possible without it but I may be wrong.
In a 5 pin handle, the wiring is typically like this:
- Power
- NTC
- Shake
- Ground from power supply (Common for ntc, power, shake)
- Chassis earth (isolated from power supply ground)
I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply + chassis earth
Quicko (Not Queeco) uses a 6-pin plug, it's similar to the 5-pin, but with 2 ground wires, no NTC (in-board) and has a second sensor input for a different heater type, I guess for hakko 936 heaters, which use a PTC sensor.
Adapting the wiring isn't complicated, but you must check the connections in your board.
-
I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply
+ chassis earth
this
-
Strange, that's the correct firmware for that board. Anyone having else this issue?
Can you post the log from the programming tool? Try making a full wipe.
The guide to preserve the settings, where you skip erasing the last 2 sectors, is only for settings made by this firmware, so you can update to newer versions keeping everything.
But not for the original firmware, that one stores them in the eeprom, this custom fw doesn't make use of it, so they'll be preserved always.
I've attached a log from another attempt about an hour ago, I've been performing a full wipe with each attempt and it seems to all go through just fine. It programs and verifies just fine both with this and the OFW I'm using.
Here's a copy of the log. (https://files.catbox.moe/6acccn.txt)
-
Is anyone running the latest fw in a Ksger v2.1 board?
-
Is anyone running the latest fw in a Ksger v2.1 board?
Hello David, tested on this 2.1 board revision (https://raw.githubusercontent.com/deividAlfa/stm32_soldering_iron_controller/master/BOARDS/KSGER/%5Bv2%5D/Schematic/KSGER%20_v2.1_board.jpg) and I can confirm NO issues with the latest firmware.
-
I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply
+ chassis earth
this
Yep, I just finished rewiring the handle and that's what I have (that's why I asked in the first place). Anyway, the Handskit 5 pins handle turned out to be a 4 wires cable with a 5 pins connector so there isn't even a NTC inside to worry about. :-//
Thanks for your input guys.
-
Thanks, Rick :-+
TeamTeacup, can you make pictures of your board, specially showing the stm32 in it?
-
Here's both a full shot of the board, and a closeup of the STM32. I did my best with contrast to make it as easy to read as possible.
-
Hmm everything looks correct.
Have you tried downloading the file again just in case?
-
I downloaded the same file and they both have the same SHA-1 checksum to them, I'm not sure if it'll be the same for anyone else but the files I'm receiving are at least consistent.
I'm using the ST-LINK Utility, though its with a reprogrammed STM32 development board that behaves like an ST-LINK. That's about the only rogue element I can think of, but given it could program the original firmware just fine I'm not so sure.
-
I don't think so... Try this file (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1303238).
It's a display test I made a while ago when adjusting i2c timings.
No pwm, ADC, flash settings..everything is disabled and unused except the display.
Another way to check what's going on is to install stm32 cube ide, import the project and start a debugging session, if anything crashes (hard fault, whatever) you'll be able to see it.
I think it's possible to use a st-link remotely, ex. connect to your stlink from here, but I've never tried.
I wonder why it's not working, if you want to try just send me a pm :-+
-
I also use the old stlink utility to flash mine, only difference from yours is I updated the STLinkUSBDriver.dll (v6.0.0.0) file and flashed the latest firmware V2.J39.S7 on my stilink
https://www.st.com/en/development-tools/stsw-link007.html (https://www.st.com/en/development-tools/stsw-link007.html)
-
I guess a 4-pin connector joins earth and gnd, like this:
- Power
- NTC
- Shake
- Ground from power supply
+ chassis earth
this
Yep, I just finished rewiring the handle and that's what I have (that's why I asked in the first place). Anyway, the Handskit 5 pins handle turned out to be a 4 wires cable with a 5 pins connector so there isn't even a NTC inside to worry about. :-//
Thanks for your input guys.
Did you rewire it? Andy why have you rewire it? I know that it is not compatible with Ksger handle wiring.
-
I don't think so... Try this file (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1303238).
It's a display test I made a while ago when adjusting i2c timings.
No pwm, ADC, flash settings..everything is disabled and unused except the display.
Another way to check what's going on is to install stm32 cube ide, import the project and start a debugging session, if anything crashes (hard fault, whatever) you'll be able to see it.
I think it's possible to use a st-link remotely, ex. connect to your stlink from here, but I've never tried.
I wonder why it's not working, if you want to try just send me a pm :-+
The I2C timings firmware file seems to have the same outcome for me, nothing appears on the display. Perhaps the particular I2C OLED module thats in this station needs compensating for. ???
-
To accomodate every single display out there, I made the timings a lot slower than they used to be, so I doubt it's the problem here.
More like the stm32 is failing to run?
I mader a simple diagnostic fw, should output a number of beeps on every initialization step (from 1 to 9).
After the 9th beep, the screen should turn on. If it makes any beep, at least we know the stm32 is working.
-
Aha, I guess that means the STM32 isn't initializing then. It doesn't beep at all.
As for debugging it in STM32CubeIDE I'm not sure I'm doing it correctly, but I have the project files opened and all set up for debugging. And it seems to halt at line 89 of main.c:
int main(void)
{
/* USER CODE BEGIN 1 */
/* USER CODE END 1 */
/* MCU Configuration--------------------------------------------------------*/
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
-> HAL_Init();
/* USER CODE BEGIN Init */
/* USER CODE END Init */
/* Configure the system clock */
SystemClock_Config();
/* USER CODE BEGIN SysInit */
-
There's something wrong there. HAL_Init should be line 167. So there's a lot of code missing.
Are you following the project generation steps?
- Run the script _KSGER_v2.bat, in the root of the folder.
- Open stm32 cube ide, import an existing projectn and select only the file that appears in the root of the folder, unselect those inside the BOARDS folder!
- Double click STM32SolderingStation.ioc to open cubeMX tool, and click on the code generation button, it's the orange gear, close to the build button (hammer icon).
- Now the code will be complete. You should see this sections in /Src/main.c:
/* Private variables ---------------------------------------------------------*/
ADC_HandleTypeDef hadc1;
DMA_HandleTypeDef hdma_adc1;
CRC_HandleTypeDef hcrc;
IWDG_HandleTypeDef hiwdg;
TIM_HandleTypeDef htim3;
TIM_HandleTypeDef htim4;
DMA_HandleTypeDef hdma_memtomem_dma1_channel2;
/* USER CODE BEGIN PV */
/* Private function prototypes -----------------------------------------------*/
void SystemClock_Config(void);
static void MX_GPIO_Init(void);
static void MX_DMA_Init(void);
static void MX_ADC1_Init(void);
static void MX_IWDG_Init(void);
static void MX_TIM3_Init(void);
static void MX_CRC_Init(void);
static void MX_TIM4_Init(void);
HAL_Init();
...
SystemClock_Config();
...
MX_GPIO_Init();
MX_DMA_Init();
MX_ADC1_Init();
MX_IWDG_Init();
MX_TIM3_Init();
MX_CRC_Init();
MX_TIM4_Init();
Make sure you're running a debug build. In the hammer icon, click the downward symbol, select Debug, and it will compile for debugging.
Go to the HAL_Init() line and make double click in the line number to set a breakpoint there.
Then start a debuggging sesion by clicking over the downward symbol in the debug button (green bug), select"Debug configurations", select "STM32SolderingStation Debug".
In Startup section, check that "Set breakpoint at main" is disabled, and finally click on Debug.
It will program the stm32 and start the execution until reaching the breakpoint we set earlier on HAL_Init.
Now check the small arrows im the debug area: "Step into", "Step out" and "Step return".
- "Step into" dives into the code on the function, ex. in will enter HAL_Init() and step through its code.
- "Step out" will skip the details and execute the function "silently".
- "Step return" will execute everything and stop at the end of the current function.
Given it seems to stall in that HAL_Init, use "step into". Once inside it, use "step out" to execute each function without entering them.
At some point you will see that it keeps running indefinitely, that's because the function didn't return (it's stuck somewhere) so hit the suspend button, and you will instantly see where the program is at.
Now make "step into" and see what's the code causing the endless loop.
-
If I'm not mistaken, it seems to be stuck on line 493 as part of Error_Handler but that might just be the expected response from the STM32. The debug panel to the left shows it occurred during SystemClock_Config() so that may be the point at which is actually had a problem and it just jumped here as a response.
Apologies for any difficulties I'm giving anyone with this, debugging and using any IDE is new to me for the most part.
-
Please attach the file main.c
Doesn't make any sense, error handler isn't empty on my code... I think you made something wrong.
Watch the video on GitHub that shows how to correctly import and build the project.
In any case, hal_rcc_init is failing, so run step into, and check what's causing that.
If you have a moment, I can have a quick check using TeamViewer, just send me a pm.
-
Here you go!
-
It's empty! :-DD
Check the video:
https://www.youtube.com/watch?v=8oeGVSSxudk (https://www.youtube.com/watch?v=8oeGVSSxudk)
-
Uh oh, my noobie side is showing! I'm completely confused with this and I'm not sure I'll make any headway with it. Might as well just stick with the original firmware for the time being.
-
You're close! Just follow these 5 steps ;)
-
It proceeds to tell me that the build failed with several dozen errors :wtf: Also has the pinout changed since the video was made or could this be another issue?
-
The video shows the build process for my Quicko, of course the pinout it's different now you're building for Ksger.
That one is correct for Ksger v2.
With CubeMX opened (like your picture) click on the code generation button:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1337378)
That will add everything needed, including the libraries, that's why you're getting the error.
-
One thing I remember from the first time I set up cubeIDE that is not in the video: the root folder name where you extract the files must be "STM32SolderingStation" otherwise build will fail. I can see on your screenshot yours is auto named by your unzip program "stm32_soldering_iron_controller-master". Rename it and try again.
-
Thankyou to you both, I've been able to build from the source just fine. Though when I go to run/debug it I find it halts on the following line:
FillBuffer() at ssd1306.c:520 0x8014a44
while(oled.status!=oled_idle); // Don't write to buffer while screen buffer is being transfered
Looking through the debug panel, it seems as if Oled_error_init() is being called, which then tries to fill the screen buffer but ends up stuck waiting for it to stop being transferred across. I have absolutely zero knowledge of C or working with STM32s however.
-
You're doing very good! :-+
Ksger v2 doesn't use hardware for the display, it's done by software, so oled.status should always be idle...hmmm
Anyways, the error appears in a very early stage, in SystemClock_Config.
Step into that function, anything that returns Hal_error, hal_timeout... Anything not being hal_ok.
By the way, in the left planes you have "Expressions".
Write there "oled.status" to view its value in realtime.
-
I'm not sure what I should be looking for, but the value of RCC_OscInitStruct is 0x20002720 at the point it checks to see if its a null pointer (line 248 as part of SystemClock_Config).
-
The pointer is valid, the struct data is shown in the Variables window.
Is it failing at the null check?
Otherwise step the function until something returns HAL_ERROR.
I see you're running v1.8.0, I'm still using v1.7.0.
Let me update and check few things... That part is 100% ST code, not made by me, and it's not strange that new versions come with bugs.
Edit: v1.8.0 working correctly here. Run "Step into" in HAL_RCC_OSccconfig and check what line is failing.
-
It halts at 'if (RCC_OscInitStruct == NULL)' while the value for it is 0x200027c0 .
-
Doesn't make any sense at all :o
-
It doesn't make sense to me either, I'd suspect an issue with the STM32 itself but the OFW functions perfectly.
-
Maybe a defective stm32 or whatever. This fw uses a lot more of resources from the stm32... weird.
A simple test... what happens?
HAL_StatusTypeDef HAL_RCC_OscConfig(RCC_OscInitTypeDef *RCC_OscInitStruct)
{
uint32_t tickstart;
uint32_t pll_config;
uint32_t *p = NULL;
if (p==NULL){
asm("nop"); // Expected
}
p= (uint32_t*)RCC_OscInitStruct; // Copy the pointer
asm("nop"); // p should have nowthe same value as RCC_OscInitStruct
if (p==(uint32_t*)RCC_OscInitStruct && p!=NULL){
asm("nop"); // Now it should should land here
}
else if(p==NULL){
asm("nop"); // Empty?
}
else{
asm("nop"); // Not the same value as RCC_OscInitStruct?
}
Also check this. In main.c
void malloc_fragmentation_fix(void){
uint32_t *ptr = NULL;
uint32_t try=17408;
while(!ptr && try){
ptr = _malloc(try);
try-=16;
}
_free(ptr); // Set a breakpoint here. What's the value of "try"? Just put the mouse over it, the value should pup-up.
// The value should be 0x10A0 / 4256 (bytes)
-
Switching out the HAL_RCC_OscConfig code for the one you provided doesn't seem to have made a difference, the system still does nothing. p is nulled and the value from RCC_OscInitStruct is copied over like it should be but it still halts on 'if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)' in main.c
I made sure to check malloc_fragmentation_fix as well and sure enough the value for try was 4256.
-
I'll make a specific build for the 103R8, but as far as I know everything is the same for 48 and 64 pin versions expect more pins exposed.
What I don't understand is why an initialized pointer fails at the null check, it's simply ridiculous.
p was assigned with the same value, 0x200027c0, right?
-
is this only on v2.1? i have a v3.1 with the 103r8 chip on one of them and it loads up fine
-
I have absolutely no idea, to this date nobody has complained about this.
I've checked the memory mapping, peripherals, startup script, linker script... everything seems identical between 103R and 103C models.
I attached a project made for the 103RB. It runs perfecty in the 103C8... give it a try, although I'm pretty sure it'll fail in the same way.
-
I'll make a specific build for the 103R8, but as far as I know everything is the same for 48 and 64 pin versions expect more pins exposed.
What I don't understand is why an initialized pointer fails at the null check, it's simply ridiculous.
p was assigned with the same value, 0x200027c0, right?
Yup, it was 0x200027c0
-
Sorry, I forgot to attach the file!
https://anonfiles.com/F3V0X7Y8u3/103R8_zip
Delete the project, then click import...existing project/Select archive file and select this file.
-
This one isn't proving any better. It halts at the 'bl main' instruction in the startup_stm.s file and goes to HardFault_Handler. Could this just be a bad STM32?
-
This is a new project, made from scratch. It's a very basic blinky, only toggles the buzzer pins.
Everything else is untouched. If this doesn't work, I don't know what will.
The only options left would be the stm32 being defective or a crappy counterfeit?
I'll keep trying for a while, but it's a very slow process, needing local testing, uploading the tests, waiting for feedback, etc, I could run 1000 tests in 15 minutes, so consider letting me to debug it remotely if it keeps failing.
Otherwise, I can't spend much more time with this...
-
Is this the right way to do wiring for stand standby detection? I see on the picture at the same time GND to Earth is this ok?
If stand is selected shouldn't be the shake sensor disabled?
-
I you want stand mode, then you must disconnect it from the shake sensor in the handle, cutting the wire in the connector or removing the sensor.
Wire the shake signal from the board to somewhere, ex. like you're doing, ta a rear conector.
That signal is left floating then the handle is out, and pulled to ground when the handle is in.
Earth and ground are not the same. If your station has them connected together, then you can use it for pulling down the shake sensor input, but if not, you have to use the power supply ground.
-
A stupid question.... Would it be possible to ignore the sensor when in stand mode in software?
-
As far as the controller is concerned, both the sensor and the stand send the same signal. Both are pulling the same wake pin to ground, the only difference is what the software does with it (ie. the mode you set in settings). I can't see how you could discriminate reliably without a separate pin for both devices.
-
So since neither Ksger nor Quicko i think has an option to use sleep in stand. Would it be possible to assign additional pin if there is any spare on stm32 and do a hardware mode. So that if stand will be enabled pin 13 (i think) will be disabled and some other pin would be enabled.
-
It certainly is possible but that means running a bodge wire straight from the MCU pin and also adding some input protection resistors and diodes so you don't fry your MCU. Any sane person would just disconnect the shake sensor and be done with it (unless you're designing your own board).
-
I plan on getting a t12 clone off aliexpress/banggood for some messing around and some keyboards, the plan atm is to get one of the t12, an 858d heat gun station, and an engineer ss02 for desoldering since the default plastic tip ones are really bad. Is there any better I can do than any of these for around the same price? And would you recommend a desoldering gun station thing, or would I be better off getting everything separate?
Which t12 clone would you recommend getting in terms of hardware and software compatibility? I plan on getting one running the stm32 rather than the stc or some other chip because I heard there's not as much or any software compatibility. I understood that quicko has better hardware than ksger as well as better support software side, is that the case? and am I less likely to need to reconfigure the temperatures for the tips? and is there any good way to do this on the cheap if I plan on getting genuine hakko tips or the default quicko tips?
And which version should I go for? there are many on the quicko aliexpress store, as well as some quecoo ones, what are the differences between the "brands" and the versions?
Thanks in advance!
edit: formatting
-
You can find the answer to your question here
58eur/$67 for a DIY kit, ,comign with the crappiest plastic handle? To me, it seems very expensive, and a try of charging twice trying to get extra profit of the silicon crysis.
There isn't a design that's notoriously better than others., everything is just the same, don't get fooled by a fancy alluminium bezel.
The major changes come in the 3.3V regulation. Some KSGERs (2.0, 2.1, 2.1s.. uhh... I don't know which ones right now) use a cheap design where they convert 24V to 3.3V with a linear regulator, causing a lot of heat.
For some boards it's too much, the LDO overheats and causes weird behavior like random resetting. But the analog front end is, as far as I know, the same thing in all with minor changes.
Maybe some KSGER fanboys can advice you better, I just see a ton of money for a crappy design ::)
I'd get a KSGER 3.1, Quicko T12, Quecoo T12-955, whatever is cheaper.
Search "aliexpress" in this topic, you'll quickly find some links.
https://www.aliexpress.com/item/4000183089084.html (https://www.aliexpress.com/item/4000183089084.html)
https://www.aliexpress.com/item/32947718640.html (https://www.aliexpress.com/item/32947718640.html)
https://www.aliexpress.com/item/32954334507.html (https://www.aliexpress.com/item/32954334507.html)
-
hello, can anyone adjust the boost settings? When I turn the key on the home screen, it doesn't work like it used to?
-
Please BOOST setting
-
Then explain how it's failing for you...
-
hello, can anyone adjust the boost settings? When I turn the key on the home screen, it doesn't work like it used to?
Maybe start by reading the manual here: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md
-
I know that, although much better than before, it still has some issues with cheap encoders, as they bounce so much that can cause instant returning to normal mode.
Adding delays is even more annoying because it blocks the whole input, it's very noticeable and frustrating.
Something I'd like to try fixing, but these things are the fine tweaking stuff that require a lot of time to tune and fix.
If a serious bug appears I might try my best, but I can no longer spend so much in these little details, at least for a while.
After very long two years, my efforts are going into physical rehabilitation and fixing/doing things I couldn't for all this time.
Everything's going great so far, I'm starting to feel again like a strong 34yr old guy instead a WW1 living fossil.
While I read everything and take in consideration every suggestion, understand that I have very clear priorities here! :-+
-
The software is nice, but there are a few missing, for example, the boost does not work. I do +50 manually, but it doesn't return to stable operation. The warm-up time of the handle has been extended compared to the previous software. I am waiting for a new arrangement, please. If you turn the button on the main screen, the degree does not change, if you turn the button to the right as before, if the boost works, when you turn it to the left, if there is standby and sleep, that is, it will be very good if it is like the original software. can you also add the bin file of the original software? I can't revert to original software?
-
The software is nice, but there are a few missing, for example, the boost does not work. I do +50 manually, but it doesn't return to stable operation. The warm-up time of the handle has been extended compared to the previous software. I am waiting for a new arrangement, please. If you turn the button on the main screen, the degree does not change, if you turn the button to the right as before, if the boost works, when you turn it to the left, if there is standby and sleep, that is, it will be very good if it is like the original software. can you also add the bin file of the original software? I can't revert to original software?
You need to read the operation instructions |O
Boost mode shortcut has changed: turn encoder (this enters temperature set) and press the encoder button before 1 second is up (to return to normal mode turn encoder or press button)
For Sleep and Standby press encoder button while you rotate left (once/twice)
The original bin files are on the github repo under Original_FW
Edit: Version 3.x ksger board firmware is not on github, maybe David can add it.
-
here is the 3.1 firmware if you want to revert back flash the same as the custom firmware. i like to erase the chip first if i have to revert back
-
Added, thanks.
Meanwhile I had some free time to make a little update.
Setting the station in sleep/standby/boost modes became a little annoying, often the station instantly returned to run mode after releasing the encoder.
This was not due any bug, the contacts in these cheap encoders fail, probably caused by tired springs, oxidation or contamination, then any slight movement causes noise in the connections, leading to unwanted rotation detection.
I fixed it few times with contact cleaner spray, but it always came back after a while.
So I made a very simple yet effective workaround: Block only the rotation input for 250ms after setting these modes.
Seems to greatly reduce the issue.
-
Cutesy little thing
https://www.youtube.com/watch?v=OAOVEsLiSBM (https://www.youtube.com/watch?v=OAOVEsLiSBM)
-
hello, I was very excited when I read your reply. I have a new ksger device. It's 3.1, thanks, there is no problem with it, but I want to use your software and unfortunately, boost still does not work in the same situation. What I want is that when you turn the pot to the right as in the original software, the boost will be +50 and at the end of the set time, it will return to normal operation and wait in the 1st turn of the pot to the left, and go to sleep in the 2nd turn. I'm sure you will, thanks.
-
that is the same handle as the one in the aixun t12 version
-
I'm sure you will, thanks.
This fw has more features, making everything easily accesible using only a rotary encoder is not easy.
Sorry if this sounds rude: I'm sure you will read the operation manual and learn how to use it.
I don't make custom firmwares for the liking of everyone out there, it would be a lot of work and impossible to maintain.
Cutesy little thing
Erm... 65 euro for that, must be a joke... :-DD
-
I know it has more features so I want to use this fw but I need to use boost and I can't use it please help with this.
-
I'm sure you will, thanks.
This fw has more features, making everything easily accesible using only a rotary encoder is not easy.
Sorry if this sounds rude: I'm sure you will read the operation manual and learn how to use it.
I don't make custom firmwares for the liking of everyone out there, it would be a lot of work and impossible to maintain.
Cutesy little thing
Erm... 65 euro for that, must be a joke... :-DD
this custom firmware for t12 is great but whole of chinese T12 equipment manufacture is unfortunatelly crap :(
main problem with these DIY T12 stations is simply they are manufactured not by companies but by chinese amateurs on CNC thats why 99,9999% of these soldering stations have funny potentiometer (rotary encoder) instead of three simply buttons to set temperature !!! it seems they have big problem to drill 3 smallest holes for buttons to make these stations managment much more better just take a look on aliexpress most or (whole) of oldest design 936 soldering stations to use with older tips technology have buttons to setup temperature like they should because they manufactured by chinese companies !
3 signifficant issues with these t12 diy stations:
1 - rotary encoder potentiometer instead of buttons
2 - hard to operate on this potentiometer unless you put something under this soldering station
3 - tft display panel should be placed diagonally centered to operator face > another big or even biggest problem for these chinese amateurs to release it via CNC ...
ive replaced my ksegr t12 to BAKON BK969D soldering station especially to meet my missed requirements (point 1 , 2 , 3) and even if i cannot change the tip model via menu in this station is much more better to operate
we are live in 2021 year is funny to manufcture/buy soldering stations with potentiometers - dont you think so ? :)
another excellent chinese product manufactured on amateur CNC:
https://www.aliexpress.com/item/1005002765445341.html?spm=a2g0o.productlist.0.0.58b76554AgKyoh&algo_pvid=30f6fb72-45e5-4397-ba2b-27ccd23045c0&algo_exp_id=30f6fb72-45e5-4397-ba2b-27ccd23045c0-9&pdp_ext_f=%7B%22sku_id%22%3A%2212000022079117374%22%7D (https://www.aliexpress.com/item/1005002765445341.html?spm=a2g0o.productlist.0.0.58b76554AgKyoh&algo_pvid=30f6fb72-45e5-4397-ba2b-27ccd23045c0&algo_exp_id=30f6fb72-45e5-4397-ba2b-27ccd23045c0-9&pdp_ext_f=%7B%22sku_id%22%3A%2212000022079117374%22%7D)
AIXUN T3A T3B T3D wonderfull display panel and firmware managment can operate also with JBC tips with one issue (have crap potentiometer for setting tip temperature) :( - have you found another AIXUN product with buttons to set tip temperature ?! - no you wont find it never ....
regards
-
I know it has more features so I want to use this fw but I need to use boost and I can't use it please help with this.
Please, read the manual... also Ricktendo has described how to use boost mode... Couldn't be more simple ;)
lfldp, the encoder input is pretty handy. The problem comes when a good quality encoder costs 1/3 of the station. So they use cheap quality.
-
When you press the pot and turn it to the left, it is good to wait at the 1st and sleep at the 2nd, but when you press the pot and turn it to the right for boost, it comes to the end part of the screen, namely bc3, and the boost set is not +50. Please, a final setting.
-
You need to read the operation instructions |O
Boost mode shortcut has changed: turn encoder (this enters temperature set) and press the encoder button before 1 second is up (to return to normal mode turn encoder or press button)
For Sleep and Standby press encoder button while you rotate left (once/twice)
The original bin files are on the github repo under Original_FW
Sleep and Standby OK but boost not working.
BC3 just choosing
-
You're doing it wrong. Don't rotate clockwise while pushing.
Rotate in any direction so the setpoint screen appears, then simply click.
-
counterclockwise, standby and sleep works fine. But when you turn it clockwise, the BC3 icon appears on the screen only and the boost does not work. Please one last adjustment.
-
When you press it and turn it clockwise, the boost will increase to +50 and it will return to normal operation to -50 at the end of the set time, please, a final touch. Also, although I choose sleep at the beginning in the settings, there is no sleep at the beginning, it starts to work normally.
-
Do not push while rotating. Nowhere is said that to set boost mode.
Rotate normally to make the setpoint screen appear, then click.
Rotate anticlockwise while pressed: Set sleep and standby modes.
Rotate clockwise while pressed: Enable tip selection.
Rotate ONLY, no press: Shows setpoint screen. Click before 1 second to trigger boost mode. If clicked later, it will be ignored.
For the sleep issue, go to Iron screen, below "Err Time" you'll see "Resume". Set it to "LAST".
I have to fix the issue but that's the workaround for now.
-
Unfortunately, boost doesn't work. When you don't click, the setting goes up. If possible, reverse the boost setting with the tip scimi so that the tip does not select but the boost works.
-
For the sleep issue, go to Iron screen, below "Err Time" you'll see "Resume". Set it to "LAST".
thanks sleep solved please get boost.
-
Sorry, I don't know what you're doing. If settings are showing, you're clicking for a long time.
Mobile users: Warning, link to 2MB gif!
It's really this simple (https://s10.gifyu.com/images/f3a9a8ce-872e-46a3-be96-7bd9b8d6f2cd.gif)
When booting, there's always some error detected before the voltages and sensor readings are initialized.
Thanks for reporting the booting issue, I never had it, as I always had the resume mode in "Last".
I quickly figured out that it was the Resume option overriding the Boot mode.
Fixed the issue by adding a boot flag, set when exiting the boot screen.
If any error is cleared before the boot flag is set, force the configured boot mode. Otherwise, set the Resume mode.
I also increased the shake filter timing window: Accept changes happening between 100-500ms, instead 200-400ms
Still, it's good to ignore very slow or very fast changes, usually it's just vibration or noise.
Hotfix builds released. It's so much easier now I automated it... :)
It there's something confusing in the operation manual, let me know.
I want to avoid the same questions being asked everytime.
-
David, the new firmware is working great! Thanks!
-
main problem with these DIY T12 stations is simply they are manufactured not by companies but by chinese amateurs on CNC thats why 99,9999% of these soldering stations have funny potentiometer (rotary encoder) instead of three simply buttons to set temperature !!! it seems they have big problem to drill 3 smallest holes for buttons to make these stations managment much more better just take a look on aliexpress most or (whole) of oldest design 936 soldering stations to use with older tips technology have buttons to setup temperature like they should because they manufactured by chinese companies !
1) u always have throughholes for three buttons on pcb. since u need them, just buy pcb only and add buttons instead
2) encoder is not pot
3) angle of screen does nothing with job. its not a clock
-
When you press it and turn it clockwise, the boost will increase to +50 and it will return to normal operation to -50 at the end of the set time, please, a final touch. Also, although I choose sleep at the beginning in the settings, there is no sleep at the beginning, it starts to work normally.
how the holy f// did u manage to install custon firmware? :palm:
-
it was very nice with the new software, thanks it was boost :)
-
I've added a socket to my station which allows to plug in an external stand switch.
I want to directly connect an original Hakko stand to this so I followed their pinout. I guess if copying a feature from the original Hakko station it may be a good idea to follow their pinout so original Hakko equipment can be connected. I even took some photos to document how a socket can be added in a way that the shake switch reconnects if no plug is inserted.
But now there is another problem where I want to ask first before doing any mods to anything.
For some time I was wondering why my switch does not work at all or only very unreliable. Until I realized that, if the switch is open, the pin, it is connected to, only rises to about 1.6 V and not all the way up to 3.3 V. So I finally took apart the Hakko stand and I found that they have an 4.7k resistor in parallel to the switch. So basically this switch toggles between 0 Ohms and 4.7k Ohms in this setup. My guess is that Hakko does this to detect if a stand is connected at all.
0 Ohms: Stand connected, Iron in place
4.7k Ohms: Stand connected, Iron not in holder
open connection: No Stand switch connected
I guess that the processor pin which is used for the shake switch is not an analog input port and so it is not possible to detect voltages below the "logical high" level? Would it be safe to add a bit of additional pull up to raise the voltage up to a region where the station properly detects it? If possible I would really prefer to make my new "switch socket" compliant in a way that original Hakko stuff works on without modifying it.
EDIT: Actually I have found an hacky solution. If I add a diode in series to my socket, then this adds half a diode drop (around 0.6 V) to my 1.6 V which results in around 1.9V and this is slightly above the lower "minimum" that is described in the STM32 datasheet for "logical high". Seems to work but I still think, if possible with not too much effort, reading the pin in "analog mode" would actually be nicer.
-
Nope, I already thought that ages ago... The shake input doesn't have analog connection in most boards.
Remove the 4k7 resistor, easy.
-
Erm... 65 euro for that, must be a joke... :-DD
Agreed, but its kinda interesting to see the new irons and the different menu item names and layout. Here is a video with teardown at 12:45 (it appears to use Atmel micro)
https://www.youtube.com/watch?v=LgurDQmcjeA (https://www.youtube.com/watch?v=LgurDQmcjeA)
-
well they also copied the malectrics welder and are charging like 250$ for it
-
main problem with these DIY T12 stations is simply they are manufactured not by companies but by chinese amateurs on CNC thats why 99,9999% of these soldering stations have funny potentiometer (rotary encoder) instead of three simply buttons to set temperature !!! it seems they have big problem to drill 3 smallest holes for buttons to make these stations managment much more better just take a look on aliexpress most or (whole) of oldest design 936 soldering stations to use with older tips technology have buttons to setup temperature like they should because they manufactured by chinese companies !
1) u always have throughholes for three buttons on pcb. since u need them, just buy pcb only and add buttons instead
2) encoder is not pot
3) angle of screen does nothing with job. its not a clock
ok but point 1 need to modiffy panel case too :(
-
I decided to keep the diode in. Seems to be pretty stable this way without modifying anything at the stand at all. And worst case the voltage level is still too low and the iron does not properly leave standby mode. Not that big of a deal. I can still fix this problem if I really have issues in future.
Maybe I now have found the first small issue. I have a "Standby time" set in the "IRON" menu. I also would like to keep this in case I unplug the holder and want to use the small station "on the go" with a holder without switch. In this case I only want to change one setting (stand to vibration switch). The way it is programmed currently, a configured "Standby time" combined with "stand switch mode" causes the iron to go into standby while working with it if it is not placed regularly to the stand. In my opinion in "Stand mode" the "Standby time" setting should be ignored. Only the "Sleep time" should be still active but the iron should only go to sleep if it is kept into its stand for the full "sleep time" value.
-
The timeouts are always active, even in stand mode.
However they won't be refreshed without the shake sensor.
-
I decided to keep the diode in. Seems to be pretty stable this way without modifying anything at the stand at all. And worst case the voltage level is still too low and the iron does not properly leave standby mode. Not that big of a deal. I can still fix this problem if I really have issues in future.
Maybe I now have found the first small issue. I have a "Standby time" set in the "IRON" menu. I also would like to keep this in case I unplug the holder and want to use the small station "on the go" with a holder without switch. In this case I only want to change one setting (stand to vibration switch). The way it is programmed currently, a configured "Standby time" combined with "stand switch mode" causes the iron to go into standby while working with it if it is not placed regularly to the stand. In my opinion in "Stand mode" the "Standby time" setting should be ignored. Only the "Sleep time" should be still active but the iron should only go to sleep if it is kept into its stand for the full "sleep time" value.
fire safety reasons. just set to 10 mins.
-
The timeouts are always active, even in stand mode.
However they won't be refreshed without the shake sensor.
And as the pin is shared between either shake sensor or stand switch there can't be a shake sensor once the stand switch is connected.
If there is no way to add a new GPIO just for the stand switch (I guess it would be possible to repurpose one of the programming pins for example) and you don't want to disable the timeouts, then maybe just allow to configure which kind of "sensor" is connected. And if this is set to "stand" then 0 minutes for "standby time" means "go to standby immediately if iron placed to stand" and "sleep time" on 5 minutes means "go to sleep if the iron was in stand for 5 minutes".
Just thinking. Stuff that only works properly with shake switch is pretty useless to keep running once the firmware was told that there is no shake switch connected.
-
What are you talking about? You can adjust all that :-//
0 standby time will skip that mode and check sleep timeout instead.
You can adjust the desired the mode when the handle is put in the stand.
The timeouts are there and will always be, otherwise the station would run forever if the handle is not correctly placed or the stand sensor fails, adjust them as required.
-
The problem for my usecase is that my plan was to use the station "on the go" sometimes. That's why I designed it the way that unplugging my stand switch reconnects the vibration sensor so the station works in the "original configuration". I have the station without power supply (as I don't trust the Chinese power supplys and prefer to place the bulky power supply below my workbench). So on the go it would be possible to run the station from a power bank.
It would be not a big issue to change one setting in the menu (even though I would prefer if the station would detect if the plug is pulled and automatically switches mode. There is actually a switch contact left that could be used for that. But actually that would need another GPIO to connect this to :-X). But the way it is currently designed I would have to change two settings. One setting in "SYSTEM" to reenable the shake sensor and one setting in "IRON" to reenable the standby time. And the same in reverse as soon as I place the station back to my workbench.
Maybe I'm the only one who uses the stand switch feature at all, so the target group is too small, but I would really love to have some simple way to switch from "workshop mode" (stand switch, no standby time) to "on the go mode" (shake sensor, standby time set). Maybe configuration profiles that can be easily switched or something like this.
-
u can cut wire to shake sensor and place switch on station case and add jack for stand switch/ i still see absolutely no problem anywhere. :-// im using stand and feel nothing wrong with standby timer.
-
thanks for the response, sorry for missing it, I just found this, which seems to have the stm32 chip, and seems to be cheaper than the ones you linked, is it good? or should I get a different one? it's a quecoo from the quicko store
https://www.aliexpress.com/item/4000045522658.html? (https://www.aliexpress.com/item/4000045522658.html?)
-
Why are you disabling the standby time in stand mode?
In stand, the timeouts are secondary, basically used as a protection method, the running state will be set instantly when you insert or remove the handle from the stand.
When you unplug the stand, you said the wiring is connected back to the shake sensor.
The timeout will be refreshed with the handle movement, so what's the problem?
From what you're saying, I think you only need to switch between stand and shake modes.
In any case, I can't make a custom firmwares for everyone, I would be making mods for all people on the forum...
The problem isn't just making the mod, I would also need to make them on each new update!
Adding a new "mode" which reads an external gpio... I'll need checking the schematics of all controllers, finding available gpios that are easy to reach, modifying the profiles and testing, explaining 1000 times what they're doing wrong in the mod...
Huh, not currently on my plans.
-
i did this for someone and as david said just added a switch was the easiest way to fix it and it works great. he runs that station off a battery board i made for it. works great
-
thanks for the response, sorry for missing it, I just found this, which seems to have the stm32 chip, and seems to be cheaper than the ones you linked, is it good? or should I get a different one? it's a quecoo from the quicko store
https://www.aliexpress.com/item/4000045522658.html? (https://www.aliexpress.com/item/4000045522658.html?)
You should email the seller ask him for pictures of the controller board.
David suggested the 955 this is a 956, you need to be careful because not all the models use STM32, for example the 952 uses STC chip instead
https://es.aliexpress.com/item/32986107656.html (https://es.aliexpress.com/item/32986107656.html)
(https://ae01.alicdn.com/kf/HTB1h29Xo.l7MKJjSZFDq6yOEpXau.jpg?size=471003&height=588&width=900&hash=8deecc89805f615a9e3719b0baf56231)
-
Woo Hoo! This thread turned 100! Pages, that is.
To bring this back on topic, I am still running OEM firmware in my KSGER 3.1, it works pretty well for me. I may upgrade to the CFW if the quality of the JBC clone tips get better.
-
I don't promise anything, but I've looking at the schematics. There're some options:
- STM32 pins: PB2+PB10 are free in all boards. But require to solder over these small 0.65mm pins, not for everyone.
- RTC pins: PC14+PC15. All have them, except Ksger v1.5. Wires can be soldered to the caps or crystal pads, they don't need removal.
- EEPROM pins: v1.5 and Quicko: None, v2:PA0+PA1 v3:PA3+PA4. Doesn't need removal, it's extremely hard to randomly match the clock/address sequence.
- Ksger v1.5 has PB12 (BOOT1) routed to a resistor/solder jumper, can be removed without issues.
- Quicko has PA15 routed to the programming header, labeled "RX".
Enabling the internal pull-up resistors, it barely requires any external parts. You could just wire the pin to the sensor, but it's a quick way to destroy the board if something goes wrong.
To prevent for current flowing into the pin, ex. a broken wire touching 24V, use a 1N4148 diode, will withstand 200V and the voltage drop won't be a problem. Then just pull the signal to ground.
For now, let's assume there's only one input.
This is not done by magic, so carefully think what functionalities might worth adding and how to implement them.
Maybe:
WAKE MODE: [STAND] [SHAKE] [SET BY SPECIAL PIN STATE?]
-
100 pages on this thread! :wtf:
I still read from time to time :-+
-
hello, the device heats up a little fast, is this possible?
-
The heating speed heavily depends on the tip construction.
Tips that have the temperature well bonded to the tip body will heat up slower, but it's not such, it's the real heating speed from the tip body mass.
Others have the sensor less tightely fitted, the sensor will take the heat from the heater and appear to warm up much faster, but the tip body heating will actually be slower because the power will be reduced sooner.
I cannot do anything about this, it's the quality you get from these cheap tips.
Yep, 100 pages. Probably 40% was answering the same silly questions over and over. Time for a clean-up or a new thread.
-
Have you tried the new update? Wouldn't it be better if you share the innovations with a picture or a video?
-
https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/340ebe2ecf4be78dac306c2d5386f159457cde92#diff-ac50f85b045548466b87272c25f2c87b22fe90f0776248caf4c27221c2383248 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/340ebe2ecf4be78dac306c2d5386f159457cde92#diff-ac50f85b045548466b87272c25f2c87b22fe90f0776248caf4c27221c2383248)
"Update builds (Dec 12 2012)
Fix little bug not restoring user temperature when exiting the calibration screen.
This only happened when the timeout expired and triggered the exit."
-
Do you want me to make a video of every single little option in the firmware? Sorry, I don't have time for that.
There's a pretty extensive operation manual there, I people is lazy and don't want to read, it's not my fault.
The firmware is prety stable, last updates were only bug fixes and little improvements, just read the changelog.
-
In fact, I want an update if it won't be too hard, as in the original software, when ksger turns clockwise, when boost turns counterclockwise, standby and sleep :) it is difficult to press the button each time, the device slides when pressing the button, it has to be done with 2 hands. ksger software is easy to use and beautiful in your software. I was always in the middle.
-
Jut hold the station with the hand and use your thumb, it's pretty easy to do, no need to use 2 hands.
In the original firmware you have to click everytime to change the temperature, that's very annoying, I find a lot more handy the current behavior.
-
I used Ksger FW for years and I know what sevgiduvari_7 is writing about.
Now I wouldn't change it back to Ksger :-DD
Boost is useless in Davids FW. Why? Just turn the knob. In Ksger I used boost all the time because of dificult temperature set (press before turn). That is why I love new way. I am not getting back :-DD
Thank you David ;)
-
I use the temperature at 360 and I set the boost +50, when I need it, I only do +50. My job is solved with 410. Please put such an option if you want, press the button to boost. If you want ksger, download your software that is like the original. I want to use your software like ksger, please. I'm sure there will be many like me.
-
When the time expires in boost, it falls back to the automatic operating degree. Like boost, it may be in a system that falls back to the degree of operating at the end of the time, such as boost, not necessarily boost. For example, I'm using it in 360, I upgraded it to 450, can it drop back to 360 after 5 minutes?
-
Jut hold the station with the hand and use your thumb, it's pretty easy to do, no need to use 2 hands.
In the original firmware you have to click everytime to change the temperature, that's very annoying, I find a lot more handy the current behavior.
I agree with you, you're right, but it's really hard, first translate, then press, time passes. imagine what i said. Those who want to have 2 options in this way can use it as I said. can't it?
Friends who understand me, please give your opinion and support.
-
When the time expires in boost, it falls back to the automatic operating degree. Like boost, it may be in a system that falls back to the degree of operating at the end of the time, such as boost, not necessarily boost. For example, I'm using it in 360, I upgraded it to 450, can it drop back to 360 after 5 minutes?
You are one F'ing piece of work! |O
-
When the time expires in boost, it falls back to the automatic operating degree. Like boost, it may be in a system that falls back to the degree of operating at the end of the time, such as boost, not necessarily boost. For example, I'm using it in 360, I upgraded it to 450, can it drop back to 360 after 5 minutes?
You are one F'ing piece of work! |O
I did not understand what you said ?
Are we going to cook pasta with a soldering machine?
We are going to solder with a soldering machine, we do not need a constantly moving device in this, do we?
-
I used Ksger FW for years and I know what sevgiduvari_7 is writing about.
Now I wouldn't change it back to Ksger :-DD
Boost is useless in Davids FW. Why? Just turn the knob. In Ksger I used boost all the time because of dificult temperature set (press before turn). That is why I love new way. I am not getting back :-DD
Thank you David ;)
I've used ksger fw for years too, just saw david's fw, I liked it very much, thank you, he applied and updated the things I wanted. why not the 2nd fw, like ksger but david's fw. I want it, I'm sure there are friends who want it too, please david.
-
There is no need to redo anything in BOOST, everything works great and is very convenient.
I will not go back to Chinese firmware. Thanks for the firmware David :-+
-
There is no need to redo anything in BOOST, everything works great and is very convenient.
I will not go back to Chinese firmware. Thanks for the firmware David :-+
I don't want to go back to china software either, but it's hard to press with one hand, please a solution. 2nd option.
-
There is no need to redo anything in BOOST, everything works great and is very convenient.
I will not go back to Chinese firmware. Thanks for the firmware David :-+
I don't want to go back to china software either, but it's hard to press with one hand, please a solution. 2nd option.
You are wrong, the controls are very convenient! I don’t understand why to remake SW for one person?
-
There is no need to redo anything in BOOST, everything works great and is very convenient.
I will not go back to Chinese firmware. Thanks for the firmware David :-+
I don't want to go back to china software either, but it's hard to press with one hand, please a solution. 2nd option.
You are wrong, the controls are very convenient! I don’t understand why to remake SW for one person?
yes, the controls are very good, I just want to switch to the boost menu more easily. this is all i want
-
No way, it's fine as it is now. You're not discussing improvement or useful feature, you just want the firmware tailored to what you're used to. That's not how it works with open source software.
Feel free to fork the code and make you own custom version or go back to stock if you want a firmware that works like ksger's.
-
there is no need for boost mode, just use normal tips
-
No way, it's fine as it is now. You're not discussing improvement or useful feature, you just want the firmware tailored to what you're used to. That's not how it works with open source software.
Feel free to fork the code and make you own custom version or go back to stock if you want a firmware that works like ksger's.
Are you writing the software? :blah:
-
there is no need for boost mode, just use normal tips
Are you writing the software? :blah:
-
brother david, if you say yes, I want to change the boost mode to the right just like in ksger. to the left in sleep and waiting. If you say it will not disappear, thank you. :-+
Please do not offer different answers for those who cannot do business. :-+
-
I use the temperature at 360 and I set the boost +50, when I need it, I only do +50. My job is solved with 410.
Please do not offer different answers for those who cannot do business.
very serious bus_in_ess :-/O
-
I use the temperature at 360 and I set the boost +50, when I need it, I only do +50. My job is solved with 410.
Please do not offer different answers for those who cannot do business.
very serious bus_in_ess :-/O
what is your purpose? :-//
I don't want to press the button when the temperature is + 50, I want it to be + 50 when I turn it to the right, that's the point, don't you understand?
-
I was about to...
(https://64.media.tumblr.com/tumblr_m8kpk42WmG1rwl09fo1_500.gifv)
But I'll keep myself civilized for a little more.
Boost mode is something made for ocassional use, not to be used every minute.
For example, when you're soldering small parts and suddently you have to solder a big part, you trigger boost and you get ex. 1 minute running at +50ºC to solder that specific part, then it'll return back to normal temperature.
You can configure the boost increase and time to whatever you want. (Read the operation manual)
If you want it crazy hot, just set +300ºC boost, it willll always apply the max temp limit set in the options, to prevent burning things.
It's not normal to use 5+ minute boost, if you use it for so long, then learn to properly adjust the temperature to the working requirement.
Simply rotate the encoder to quickly adjust the required temperature.
Are you conscious that the encoder is already used in every possible way?
- Switching temperature view (Numeric / graph).
- Adjusting the temperature.
- Entering low power modes.
- Changing tip profiles.
- Entering the settings menu.
People think developers do things magically, however don't use the term "just" or "simply" here, changing only one action will require to change all others, that's not quick neither easy as changing 2 lines of code.
I've worked very hard to get it working in armony, so nothing crashes or breaks another function, tweaking the timings, etc...
So sorry, I won't do that, get used to it.
Original firmware handling is simply terrible, you have to move between options in the screen, click a dozen times for doing simple things... in this firmware, most of them can be done with a simple gesture.
Let me remember you that the source code is available for everyone for modifying.
Or you can mail KSGER asking them to make a firmware that's not crap.
-
I was kinda expecting you to blow your top and start spitting fire a lot sooner. Color me impressed by your newfound self-control :-DD
-
I was kinda expecting you to blow your top and start spitting fire a lot sooner. Color me impressed by your newfound self-control :-DD
I'm actually a very patient person, really!
Oh sorry, translation lost all meaning, let me explain it better:
We have great drug here, come visit Spain! But they don't mention that in the tourism adverts!
Just joking :-DD. You handle it different when you're no longer fu** up 24h a day!
-
I was kinda expecting you to blow your top and start spitting fire a lot sooner. Color me impressed by your newfound self-control :-DD
almost a month wuthout bugreports worked like a vacation for David
-
I don't want to press the button when the temperature is + 50, I want it to be + 50 when I turn it to the right, that's the point, don't you understand?
go set temp step 50c then , why do u find problems out of thin air? :-DD
-
I don't want to press the button when the temperature is + 50, I want it to be + 50 when I turn it to the right, that's the point, don't you understand?
go set temp step 50c then , why do u find problems out of thin air? :-DD
That could actually be very good workaround for sevgiduvari_7. So sevgiduvari_7 what do you think? 250-300-350-400?! Or even 260-310-360-410? I am NOT joking! Wickated just found a solution for you. And you don't even have to worry about time run out which I know I had to double check every time when I used Ksger. In the middle of soldering with booster it dropped back to normal temperature and I couldn't solder any more. That is why I love David's FW. Just turn and go to desired temperature and be there for time you need and get back down when not needed. Turning the knob is really responsive and it works.
I am not even on the latest FW (I believe I have the one before 9th of December) because I have to check how to backup every tip to put it back :)
sevgiduvari_7: I had the same problem as you when I saw David's FW. When I saw how turning to a desired temperature and getting to that temperature is so fast... man, I stopped using the booster and I don't needed it any more.
-
I don't want to press the button when the temperature is + 50, I want it to be + 50 when I turn it to the right, that's the point, don't you understand?
go set temp step 50c then , why do u find problems out of thin air? :-DD
Yes, I was not thinking rationally. :-DD
thanks
let's say I changed my name to +50 as you said. I use 360, I turned it to the right, it turned out to be 410, I will have to turn it to the left to fall again, and when I forget, it will just get hot for no reason. this is what i want to tell. that is, if there is a time setting for the boost other than the boost, the problem will be solved satin. :-+
-
Tugo, check the readme, it's really simple to update preserving the settings
-
Tugo, check the readme, it's really simple to update preserving the settings
I know that it is because I saw some photos or even a video about it (I forgot what it was but I am sure I watch it in the past).
I just never done that and have to read it first and do it :)
-
David, I support your concept of soldering station control. I like her much more than KSGER. It is clear that different people may have different opinions and desires, but following this is a road to a dead end.
-
Thanks, Polf :-+
People must understand this is a different firmware, just because Ksger does something, doesn't mean it's right.
The most important things in a soldering station are the temperature reading and adjustment, everything else is just secondary.
Having worked with electronics for a lot of time, I designed the controls based on the everyday working needs, keeping it simple.
That's why there's no stupid clock using half of the screen, and the primary function of the encoder is to adjust the temperature.
:blah:
-
just because Ksger does something
This SW is not owned by KSGER.
The author of this product is ZhongGuoxin
KSGER is just a salesperson. ;D
-
Well, it's not a generic firmware, it clearly shows KSGER, so it's been designed and/or customized for them.
You get what you pay for, ZhongGuoxin can make a good firmware, or a "just good enough" firmware.
In any case, as a seller/maker, you set your product requirements, you're 100% responsible of what you're selling.
So you can't blame xxyy developer, right?
-
david software is very nice yes I congratulate you but wouldn't it be nice to offer different options upon request? whoever wants to use it as I want, whoever wants it's current state. What is the need for discussion? We have this satin software, why not have different options?
There will be critics so that change can happen. There will be those who like it, there will be those who don't. It's normal for everyone to have different opinions. but some people can't accept it, here is the problem.
-
david software is very nice yes I congratulate you but wouldn't it be nice to offer different options upon request? whoever wants to use it as I want, whoever wants it's current state. What is the need for discussion? We have this satin software, why not have different options?
There will be critics so that change can happen. There will be those who like it, there will be those who don't. It's normal for everyone to have different opinions. but some people can't accept it, here is the problem.
You are correct. And that is exactly why David put it on Github and you can change it if you want. He did a lot of GOOD suggestions but he is not your maid so he don't have to do whatever YOU want. I am sorry but I had to write it.
-
david software is very nice yes I congratulate you but wouldn't it be nice to offer different options upon request? whoever wants to use it as I want, whoever wants it's current state. What is the need for discussion? We have this satin software, why not have different options?
There will be critics so that change can happen. There will be those who like it, there will be those who don't. It's normal for everyone to have different opinions. but some people can't accept it, here is the problem.
You are correct. And that is exactly why David put it on Github and you can change it if you want. He did a lot of GOOD suggestions but he is not your maid so he don't have to do whatever YOU want. I am sorry but I had to write it.
That's what I wanted to tell you why while David has a mind to give his own answers, why do some give answers on his behalf? let david say he can't do it or not, but please don't say it. What you're doing is restricting people. Of course, if David thinks that other people can control my mind, I won't say anything anymore. :clap: :clap: :clap:
-
That's what I wanted to tell you why while David has a mind to give his own answers, why do some give answers on his behalf? let david say he can't do it or not, but please don't say it. What you're doing is restricting people. Of course, if David thinks that other people can control my mind, I won't say anything anymore. :clap: :clap: :clap:
WTF?
Please send $1000 and I'll see what I can do.
Please don't say no. Please, I want $1000 so much. It would be great if you sent me $1000 right now.
I hope you say yes. Thanks for your understanding.
-
David, u r are so coldhearted... he s from turkey, its like a whole 1year salary up there. why cant you work for free :-DD
-
Yay, entertainment is back! :popcorn:
I don't know, maybe that's a language barrier/automated translation thing but the level of entitlement seems off the charts with this guy.
A: "It doesn't work properly!"
B: "Read the manual"
A: "I don't like it like that, change it, thanks"
B: "No"
A: "You're my bro', do that for me!"
[...]
A: "Why don't you answer me, I want it now because I'm special!"
B: "Too much work and no one else wants that"
A: "Then make it an option!"
GTFO
-
Because you know, I'm just lazy.
There's a giant button in the screen, Make it a option, whatever option, it just reads your mind, without any effort, 100% automated :palm:
-
I don't know, maybe that's a language barrier/automated translation thing but the level of entitlement seems off the charts with this guy.
nope, thats actually how turkish are begging, its like national ability.
-
David, u r are so coldhearted... he s from turkey, its like a whole 1year salary up there. why cant you work for free :-DD
I totally agree. Our ancestors said that even a broken clock is right twice a day.
1000 $ = 15000 tl
For 15000 TL, they eat here in a casino for 1 night with Russian friends.
Then they take you to the hotel.
I won't tell you what's next..
I don't know, could I explain? :-DD :-DD :-DD
-
I don't know, maybe that's a language barrier/automated translation thing but the level of entitlement seems off the charts with this guy.
nope, thats actually how turkish are begging, its like national ability.
I think you have a tail pain from the Turks? :-//
tell me right?
-
friends.
nope. turks are not friends. we dont make friendship with mammals :-DD
-
Jokes are great, but please keep the xenophobia and the offtopic away... :-+
-
Hello David,
I recently purchased a KSGER OLED-v3.0 (printed on the board) and I would like to report the correct offset for me is 0 (zero,) can anybody else with a similar board confirm this, if so please set the default offset to zero.
-
Jokes are great, but please keep the xenophobia and the offtopic away... :-+
I wasn't kidding, David.
Russians are famous in Turkey.
They take a lot to the hotel.
That's why they come on vacation.
Turkish things are sweet. :-DD :-DD :-DD
-
friends.
nope. turks are not friends. we dont make friendship with mammals :-DD
what you suck is not breast!!!
you understand right? :-DD :-DD :-DD
-
The key for me was your new FAQ section where you mentioned that the ADC adjust happened in real time.
I've recently waded in and am attempting to decide which flavor of hardware to purchase. FAQ link in DavidAlfa's sig leads to discussion of Hantek hackery.
Is there a T12/STM32 FAQ someplace?
TIA...
-
The key for me was your new FAQ section where you mentioned that the ADC adjust happened in real time.
I've recently waded in and am attempting to decide which flavor of hardware to purchase. FAQ link in DavidAlfa's sig leads to discussion of Hantek hackery.
Is there a T12/STM32 FAQ someplace?
TIA...
Read this https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3802196/#msg3802196 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3802196/#msg3802196)
-
Thank you. I still have couple of basic questions for which my searches here have yet to yield answers:
- Most of these stations are rated at 24V/3A. I notice others rated 24V/5A. Always nice to have some additional SOA, but are there relevant hardware differences besides the output stage upgrade?
- T12 cartridges seem to top out at 72W -- are there other cartridges that utilize some or all of the additional capacity?
- What about 5-pin versus 4-pin plugs? Quicko seems to offer both, but KSGER uses 5-pin from what I can see.
-
As you say, T12 cartridges are limited to 72W so only stations that can fit a different handle and cartridge type (typically C245) benefit from the extra power. Though, do keep in mind Chinese specs are often way more flattering on paper than in reality so having 5A could help hitting the needed 3A.
The main difference between 4 and 5 pins is the possibility to have a NTC for cold junction compensation inside the handle. That is - supposedly - for better t° accuracy whereas 4 pins stations rely on the t° read from on-board sensor. With properly calibrated tips, a 4 pins station's still within 5°C (real vs set temperature). My guess is they added NTC so they could get away with cheaper components with every newer revision. All in all, both 4 and 5 pins work well enough in regard to temperature tracking.
-
FAQ = Github documentation.
I'm pretty happy with my Quicko 108W power supply. Definitely better than 75W ones.
Slightly struggled when I powered C245 tips with it, but did withstand the beating (200+W).
-
Thanks. Firmware fun comes next, once I get an order placed :)
We have a surplus of 24V 3A supplies here, and I'm leaning towards a Quicko 945 (https://www.aliexpress.com/item/1005002305722978.html) at this point.
What happens if we feed these things with 27 VDC? 3.3V buck converter would be the gating question. Do also risk of overstressing the heating element, or will the PID take care of that?
-
27V might be pushing it for long term use. Small step down converters are dirt cheap and may even fit inside the case. Like this one: https://www.aliexpress.com/item/32711173698.html (https://www.aliexpress.com/item/32711173698.html)
-
27V? I ran it at 30V some years ago., no problem for the board itself, but these cheap tips are already overpowered
Yeah, the tip will warmup faster, but only internally, the thermal performance won't get any better, and the heater lifetime will be shortened.
-
Anybody with KSGER v3.x board also have this same issue?
While I have no tip inserted and the iron is pointing down (shake sensor open) it shows normal no tip error, but if I tilt iron up (shake sensor closed) along with the no tip error gif it displays these random temps (click HD on GIF player for better view)
https://gfycat.com/personalenergeticdipper
Issue seems to be related to the ball/mercury switch, when circuit is closed (iron pointing up with no tip) is the only time the screen does that.
P.S. If somebody can tell me what Offset you use on your 3.x station to get the OLED straight, mine is 0 offset.
-
Anybody with KSGER v3.x board also have this same issue?
While I have no tip inserted and the iron is pointing down (shake sensor open) it shows normal no tip error, but if I tilt iron up (shake sensor closed) along with the no tip error gif it displays these random temps (click HD on GIF player for better view)
https://gfycat.com/personalenergeticdipper
Issue seems to be related to the ball/mercury switch, when circuit is closed (iron pointing up with no tip) is the only time the screen does that.
P.S. If somebody can tell me what Offset you use on your 3.x station to get the OLED straight, mine is 0 offset.
u just raise signal lvl so system counts it as temp. when shaky is closed current flows from cpu not only to ground directly but also to op input. u should recalibrate zero offset with shaky closed.
-
u just raise signal lvl so system counts it as temp. when shaky is closed current flows from cpu not only to ground directly but also to op input. u should recalibrate zero offset with shaky closed.
Maybe I should not have included the zero offset question, I was referring to display offset (which by default is set to 2 but for me the best offset is 0)
Can you tell me what zero offset you are referring to and what setting do I use to change signal level?
-
He meant the calibration thing where you capture the ADC value with a cold tip. According to his idea, shake sensor would allow current to pass through opamp when closed. That noise would then be mistaken as temperature reading. My v1.5 doesn't do that but it's a different design from your v3.
-
this here. presence io has 4,7k res, opa input also has 4,7k, so if shaky is only voltage on tip it would affect temp reading.
-
How? The 4.7K resistor is pulled to ground, has nothing to do with the temperature circuitry.
Recently someone told me the tip temperature drifted 1°C when moving the handle.
I can't figure out why it does that, maybe a poor board design, ADCs are very sensitive.
Never had that issue with my Quicko, it's really weird.
-
Recently someone told me the tip temperature drifted 1°C when moving the handle.
noticed similar, declared its just air cooling. on jbc tips outer casing is very sensitive to airflow, and can sense even finger touch on cold tip.
-
How? The 4.7K resistor is pulled to ground, has nothing to do with the temperature circuitry.
sure, i just forgot circuitry
painted some wiring.
forgot to dwaw switch on S pin
-
Did you know ther're plenty of colors to choose? ;)
What's that blue resistor? It's between the same wire, wont do anything.
The shake/NTC go to GND. There's no way they can inject current into the amplifier.
-
Did you know ther're plenty of colors to choose? ;)
What's that blue resistor? It's between the same wire, wont do anything.
The shake/NTC go to GND. There's no way they can inject current into the amplifier.
no i dont. im colorblind :-DD
res is heater in t12
tc also goes to ground, so applying some voltage on tc "ground" end would also result in voltage on opa input.
-
Unless you have a terrible wires for ground, it should have very low-impedance.
But not completely impossible:
3.3V throught4.7K draws 702microamps, if the ground wire+connector adds 30mOhms, it would drop 22uV, just enough for 1ºC offset.
Your station reads 12 when the switch is closed.
ADC 12 = 9.67mV, amplified x250, so input is 38uV.
I remember the chinese JBC handle having pretty thin wires.
My quicko has 2 wires and 2 pins in the GX-12 connector for gnd 8)
Try replacing the 4.7K pullup with 47-100K and see what happens.
But that doesn't explain the strange behavior in Rick's station. It reads low.
-
I remember the chinese JBC handle having pretty thin wires.
u kidding me//
nvm i found the case, i actually added RC for stand cuz got bad contact bounce. that was adding those microvoltage to opa input.
-
He meant the calibration thing where you capture the ADC value with a cold tip. According to his idea, shake sensor would allow current to pass through opamp when closed. That noise would then be mistaken as temperature reading. My v1.5 doesn't do that but it's a different design from your v3.
I also have a 1.5 and I can confirm it is not affected. I have a 2.1s that is affected but not as severe, you have to shake the handle really hard (which is why I did not catch this before.) Now that I purchased a 3.0 its more noticeable.
I made a video of the 3 boards, 1.5 (bottom,) 3.0 (middle,) and 2.1 (top.) You can see from the video the 3.0 all I need to do is tilt the handle up, the 2.1 I have to shake it really hard
https://gfycat.com/orangesilveriberiannase
-
poor pwm/ldo i guess. i would also check/swap handles
-
I remember the factory fw also went a bit crazy when the tip was removed, switching between temperature screen and ERROR?
I guess it needs the 1M pullup resistor between 3.3V and T+?
The circuit is almost identical in all boards, so it's strange.
-
I remember the factory fw also went a bit crazy when the tip was removed, switching between temperature screen and ERROR?
I guess it needs the 1M pullup resistor between 3.3V and T+?
The circuit is almost identical in all boards, so it's strange.
I have tested all 3 of these handles and issue exists with all 3
David you think we can use IDE to debug the issue?
-
Without the tip, the amplifier input is floating, reading noise.
There isn't much I can do fix that, it's a bad design.
Try increasing IRON/Err time to 1.0s to increase the error timeout and prevent the issue.
Otherwise, try the resistor pullup mod, I did it to my Quicko and made the detection perfect.
-
Without the tip, the amplifier input is floating, reading noise.
There isn't much I can do fix that, it's a bad design.
Try increasing IRON/Err time to 1.0s to increase the error timeout and prevent the issue.
Otherwise, try the resistor pullup mod, I did it to my Quicko and made the detection perfect.
Increasing to 1.0 did the trick, can you share a picture of your modded board and point out where/how to mod my 3.1 board?
-
whoops, i forgot about 1m pullup since i always thought its like a default option
-
I didn't see any board with the pullup resistor from factory.
It's really simple: 3.3V -> 1M -> T12+ pin
Also can be done with a 10M resistor between the mosfet drain-source pins.
-
i cant add pics in pm so
-
No, don't connect resistor directly to the amplifier input! Must be connected before the 4k7 resistor...which goes directly to the T12+ pin.
I'd to the 10M resistor between the mosfet, much easier.
Even easier, just between 24V and T12+.
-
Will it matter if I use carbon film resistor vs metal film?
Thanks
-
thats just resistor, sure no difference. smt or tht
-
how does this one seem?
it's a 955 with an stm32 microtontroller, and the store wants another 3 bucks or so for the power plug, also comes with the metal handle which I've heard from some people is relatively nice
https://www.aliexpress.com/item/1005001608493682.html?spm=a2g0o.store_pc_allProduct.8148356.1.73da3f26PsDQcX (https://www.aliexpress.com/item/1005001608493682.html?spm=a2g0o.store_pc_allProduct.8148356.1.73da3f26PsDQcX)
-
do anyone knows soldering station to manage T12 + T210 110 115 tips all in one with enough power 130W ? except these audio amplifiers https://www.aliexpress.com/item/1005003653221929.html?spm=a2g0o.productlist.0.0.4d386b5fvtxXWU&algo_pvid=1ab03050-75a0-4205-85c8-0265b1cf16e0&algo_exp_id=1ab03050-75a0-4205-85c8-0265b1cf16e0-12&pdp_ext_f=%7B%22sku_id%22%3A%2212000026662183563%22%7D&pdp_pi=-1%3B494.68%3B-1%3BPLN+16.27%400.230000%3BPLN%3Bsearch-mainSearch (https://www.aliexpress.com/item/1005003653221929.html?spm=a2g0o.productlist.0.0.4d386b5fvtxXWU&algo_pvid=1ab03050-75a0-4205-85c8-0265b1cf16e0&algo_exp_id=1ab03050-75a0-4205-85c8-0265b1cf16e0-12&pdp_ext_f=%7B%22sku_id%22%3A%2212000026662183563%22%7D&pdp_pi=-1%3B494.68%3B-1%3BPLN+16.27%400.230000%3BPLN%3Bsearch-mainSearch)
https://www.aliexpress.com/item/1005003471618661.html?spm=a2g0o.productlist.0.0.138072bb0peaCX&algo_pvid=a394391f-cc93-4089-8718-d9066082186d&algo_exp_id=a394391f-cc93-4089-8718-d9066082186d-46&pdp_ext_f=%7B%22sku_id%22%3A%2212000025939465360%22%7D&pdp_pi=-1%3B377.95%3B-1%3B-1%400.230000%3BPLN%3Bsearch-mainSearch (https://www.aliexpress.com/item/1005003471618661.html?spm=a2g0o.productlist.0.0.138072bb0peaCX&algo_pvid=a394391f-cc93-4089-8718-d9066082186d&algo_exp_id=a394391f-cc93-4089-8718-d9066082186d-46&pdp_ext_f=%7B%22sku_id%22%3A%2212000025939465360%22%7D&pdp_pi=-1%3B377.95%3B-1%3B-1%400.230000%3BPLN%3Bsearch-mainSearch)
:):):)
-
Any body has seen this one ?
https://nl.aliexpress.com/item/1005002965912186.html?spm=a2g0o.productlist.0.0.14434502ShEDhW&algo_pvid=9135628f-0c67-4c29-aa8d-5e1df964d92d&algo_exp_id=9135628f-0c67-4c29-aa8d-5e1df964d92d-50&pdp_ext_f=%7B%22sku_id%22%3A%2212000025085328578%22%7D&pdp_pi=-1%3B56.37%3B-1%3B-1%40salePrice%3BEUR%3Bsearch-mainSearch
Is also a T12 soldering station.
-
Looks pretty bad to me. First and foremost, it's not compatible with David's firmware. Then there's the rest: handle is just a piece of hard plastic with a long tip to grip distance and a 6 pins connector to make it annoying to replace. Interface looks terrible (from seller's video), screen's big but is a segments display, station and stand are made of plastic, it's rated for 65W so it probably can't even max out T12 tips and it's not even cheap. Why would anyone pick this Bakon instead of any other T12 station?
-
Looks pretty bad to me. First and foremost, it's not compatible with David's firmware. Then there's the rest: handle is just a piece of hard plastic with a long tip to grip distance and a 6 pins connector to make it annoying to replace. Interface looks terrible (from seller's video), screen's big but is a segments display, station and stand are made of plastic, it's rated for 65W so it probably can't even max out T12 tips and it's not even cheap. Why would anyone pick this Bakon instead of any other T12 station?
i already buyed this soldering station few weeks ago and...
good things:
- large display
- x3 buttons this is what i like instead of rotary encoder
- this station detecting T12 tips quite faster than ksegr t12 (i mean when you swap soldering tip)
- it is small
bad things:
-no standby , this station have output drilled for standby? but it is not connected
-buzzer is not soldered to PCB
i did make test by my wattmeter and on ksegr it noticed 80W while on BAKON BK969D just 60W :( so this is big difference
-
Hello all and Happy New Year!
I had Ksger HW 2.0, SW 2.09, STM32 102C
Flash original firmware on 2.12 from https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/Original_FW/KSGER/Firmware%202.12%20(14.05.2017) (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/Original_FW/KSGER/Firmware%202.12%20(14.05.2017))
and Info it became: HW 2.0, SW 2.12
Everything worked.
KGSER oled screen connection: 6 pin (SPI) = v3.x
(http://[attach=2])
I wanted to flash your new V3. firmware: https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv3%5D/STM32F101 (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv3%5D/STM32F101)
and got on the screen:
(http://[attach=1])
FLASH ERROR
SYSTEM HALTED
Use btn to reset
i tried V2 version: https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv2%5D (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/KSGER/%5Bv2%5D)
and got a black screen.
I wanted to flash back the original (2.12 - 2.11) - and got a black screens.
Please help me start the station.
-
Hi!
I figured it out myself.
We helped me solve the flash firmware mode: Automatic mode, see pic.
-
Happy New Year everyone! :-+
How did you flash it on first time to make that error happen?
The error means the flash erase or write veritification mismatched the expected values.
Maybe there was some flash protection bit in the option bytes?
Oh and never skip verification... it's a bad idea!
-
I flashed it according to the instructions (from YouTube in russian) for updating the standard firmware and installed 2.12 successfully instead of 2.09
then activated new 2.12 firmware.
And then I found out about your firmware :)
And I really wanted to try :)
And by standard instructions got a brick :)
-
Maybe you followed "update" instructions, those that erase the stm32 partially.
That's when you're already on this fw, to update to a newer version without losing your settings.
But when coming from factory firmware, it must be fully erased.
I will clarify that section further.
-
(http://[attachimg=2])
-
Hi,
Can anyone provide instructions on how to convert KSGER 2.1 station to support T245 handle?
I have attached a photo of my board.
Thank you.
-
cut r11 trace
-
cut r11 trace
Ok. Is this correct? Where should I connect TC+, to NTC?
-
watch the trace nearby r11 and ull see special pin dedicated to jbc tc+ (lowest in 6 rake)
-
T12 has heater and thermocouple in serial.
That trace that you need to cut is to split power (+24V) and input of U3 amplifier (this is to know what is the temperature on the thermocouple).
I hope I explained it clearly. If not, just ask.
So you need to connect TC+ to JBC (also where is says: "this trace wrong on some boards"). So your thermocouple will go to R12D (pin 5).
Everything understandable?
EDIT: I guess I was a little bit too slow :-DD
-
This is the C245 connection (https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/msg3871406/#msg3871406)
-
Everything understandable?
Understood.
I guess I have to also replace original 75W power supply with something bigger, like this one:
https://allegro.pl/oferta/zasilacz-impulsowy-24v-240w-10a-cnc-led-reprap-11019179682 (https://allegro.pl/oferta/zasilacz-impulsowy-24v-240w-10a-cnc-led-reprap-11019179682)
-
I guess I have to also replace original 75W power supply with something bigger, like this one:
https://allegro.pl/oferta/zasilacz-impulsowy-24v-240w-10a-cnc-led-reprap-11019179682 (https://allegro.pl/oferta/zasilacz-impulsowy-24v-240w-10a-cnc-led-reprap-11019179682)
I don't think you need it. At least you don't need it from the start. You can use your current PSU. You just have to go into settings and limit power.
David, am I wrong about this?
-
Meh, the cheap 75W rarely handles that, usually it resets or greatly reduces the voltage.
Try it, if it goes bad then get a better PSU.
-
There's a new model, the T12-959, with 2.6" LCD.
It seems to use stm32 but I didn't find any board pictures.
https://a.aliexpress.com/_msv7R9K
(https://ae01.alicdn.com/kf/Udfb8f5fe5b014d33bbaed64c8cc85ecc6.jpg)
-
one of the ones i received that looks like that one has an stc not stm on the board
-
It's actually written on the product page:
- Using STC15W408A5 microcontroller,
- Use sGM855xN high precision op amp,
-
Ouch, how did I miss that in the description?
These say stm32, but they also say it's OLED. I doubt any is actually true.
https://es.aliexpress.com/item/1005003502334733.html (https://es.aliexpress.com/item/1005003502334733.html)
https://es.aliexpress.com/item/1005003713432532.html (https://es.aliexpress.com/item/1005003713432532.html)
https://es.aliexpress.com/item/1005003526410748.html (https://es.aliexpress.com/item/1005003526410748.html)
STC (Now?) has english datasheet and website:
https://www.stcmicro.com/stc/stc15w408as.html (https://www.stcmicro.com/stc/stc15w408as.html)
Seems a basic 8051-based MCU, only 8K flash and 512B RAM.
But has enhanced execution times, much faster than traditional 8051.
Up to 35MHz, that gives more than enough processing power, but the memory is definitely very limited.
-
Yeah, it seems very unlikely that someone would make a clone on a completely different microcontroller and bother recreating the same firmware. Most certainly they are all using STC.
Now, that chip may be enough for its purpose but that's a definite rock bottom downgrade for anyone wanting to hack it.
-
Hmm and the Quicko T12-958 seems to be a KSGERv3-compatible.
-
If anyone needs T12 tips, here is the pack of it for less than 20€
https://www.banggood.com/groupshopping-item-2293069_1191594.html?cur_warehouse=CN (https://www.banggood.com/groupshopping-item-2293069_1191594.html?cur_warehouse=CN)
-
vulkan over at dangerous prototypes put the unisolder into the ksger style case as a lite version now looks like https://www.youtube.com/watch?v=P7042EOqoQs (https://www.youtube.com/watch?v=P7042EOqoQs)
-
Hi,
Can anyone provide instructions on how to convert KSGER 3.1s station to support T245 (C245) JBC handle?
I have attached a photo of my board.
HELP :)
-
cut at x mark. solder at bolb mark
-
Then follow this connection.
Edit: Also added pcb picture just to annoy Wickated :D
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1392896)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1392878)
-
just to annoy Wickated :D
:-+
noone complaining bout FW ? im still on like september build and feels ok.
-
There aren't big changes, just minor gui bugfixes you'll rarely encounter.
The settings structure isn't changed, you could update right away keeping everything.
Just in case, make a backup of the flash...
-
ma soft suck...
standby time (manual option) minimal is 1 minute....
-
How I can change soft?
my processor is MindMotion MM32SPIN27PF not stm32...
-
Stlink cant read processor…
I connect 3.3v gnd swdio swclk and cant read
-
Yeah well, it's not a ST part so of course STlink won't work with it.
It's yet another obscure STM32 copy that may or may not work with David's firmware. Basically, you're on your own, it's not supported (that is, no one tested it and knows if it could work). Most of those copies have some difference, bugs or missing features that make them weird to work with.
-
Warning: it's a MM32SPIN27PF. That's a Cortex M0, so it won't be compatible with this CFW.
There isn't a single ksger with a M0 mcu, all use STM32 F1 series (cortex M3).
Porting it would be lot of work for just a single board.
I recommend replacing it with a stm32F103C8 or CB, ex. from here:
https://www.aliexpress.com/item/1005001953737425.html (https://www.aliexpress.com/item/1005001953737425.html)
Might be a clone, but most work ok. Only CH32F have issues in this FW (ADC reading random values).
The connection problem is a common issue, happens with most controllers because SWD interface is disabled in software, so ST-Link won't be able to access the stm32 unless it's in reset state.
Try connecting RST pin to ST-Link. That's stm32 pin 7 (48 pin package).
It'll be connected to a capacitor, solder a wire there.
Do you want to lower the standby time even more?
1 minute is already very low, it'll enter standby after only 1 minute of inactivity.
Read the operation manual, everything is explained there. If you still have doubts, ask :-+.
-
Yes. I must change processor.
1 min is too much :) jbl soldering station goes into standby mode right away :)
-
Nicee xdd
I connect reset to stlink and nothing … again same problem
-
T12 boards use a shake sensor, the firmware has no way to know if the handle is in the stand, only checks the sensor for movement.
JBC uses stand detection, not a timeout. The stand itself is a signal, when the handle is placed this signal is tied to ground, making the detection possible.
You can do the same with this firmware, read the manual, that's also explained there.
Ouch, you ripped it off? Fix it, or the mcu might randomly reset, RST needs to be connected to a capacitor.
Chinese-only datasheets:
https://www.mindmotion.com.cn/en/products/mm32mcu/mm32spin/mm32spin_specific_mcu/mm32spin2x/ (https://www.mindmotion.com.cn/en/products/mm32mcu/mm32spin/mm32spin_specific_mcu/mm32spin2x/)
Edit: Direct links (Skip registration)
Datasheet (https://www.mindmotion.com.cn/download/products/DS_MM32SPIN2x_SC.pdf)
User Manual (https://www.mindmotion.com.cn/download/products/UM_MM32SPIN2x_p_SC.pdf)
It seems only J-Link is able to flash it, they provide custom flash scripts for it.
You can convert the St-Link into J-link OB:
https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/ (https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/)
But anyways, the CFW won't work on it.
-
I'll fix it. can i solder the stm32 processor? if so what? if i can then i can use stlink?
falling asleep and waking up works but it goes to sleep only after a minute and wakes up immediately when it loses contact with the mass
-
Of course, if you use a stm32 then stlink will work.
Are you talking about the CFW? How is it failing if you couldn't even program it?
If it's about the original fw, this is not the correct thread!
CFW in stand mode willgo into sleep steane instantly when touching the stand, and resume when lifted.
If by any means the handle is not touching the stand, the timeout will still happen, preventing it from runing indefinitely.
-
this is what i am talking about CFW. on the original program it works but it turns on only after a minute ...
when I take the tip off the stand it heats up immediately
-
I'm having a hard time understanding the issue. What's wrogn in teh CFW then?
That the sleep timeout can't be set under 1 minute? Wire and use Stand mode (instead Shake mode) for instant sleeping and waking up.
Or that it heats up inmediately on movement? That's how it's supposed to be?
If it's reacting to the slightest vibration and you want to avoid that, try the Shake filtering option, should reduce the sensibility a lot.
-
wants the soldering iron to go to sleep as soon as it is put on the stand
-
That's what it does when configured in stand mode. Of course, you have to modify your stand with a switch/grounding ring and connect it to the board. You might also want to remove the shaker in the handle. As long as you do the necessary hardware mods, the CFW will do what you want.
-
wants the soldering iron to go to sleep as soon as it is put on the stand
if you want then go and buy normal solder station with normal cpu and normal fw. why the f u even complain here. this thread is for quicko\ksger stm32 stations ONLY. u dont have any
-
Maybe he wants to know if it's possible before buying parts/board he needs. Not sure if he's a "plz bro" or just can't communicate well in English.
-
What I don't understand is how he knows what the cfw does if he wasn't able to program the mm32.
-
I have a strong feeling a lot of stuff got lost in translation. I mean, it's either that or we landed in crazytown. ^-^
-
$wickated: I do not have a feeling he is complaining. Also he has bought Ksger 3.1 but obviously because of the chip shortage he has got some stm32 clone in it. I do not feel that you should attack him. And to be honest the documentation for modding the station to be able to work as 'pun in sleep when put into stand' is not covered very well.
-
Yep, it's we probably didn't understand each other properly due the translation or any other missunderstanding.
Don't make this thread a bad place for newbies :-+
-
he got poland country marker, so he has to know engrish well. also there are no problem with slavic-engrish translations in google. its not arabic.
i only studied engrish via pc games and can properly read and possibly even write :-DD . so i believe its just lazyness.
-
I also know english pretty well, anyone has english at school, yet I know very little people able to understand and write this conversation ;)
-
Keep calm :)
see how sleep works in the video :)
I would like it to work for me too ! ;)
https://youtu.be/Yw_xHbouqxk
-
That's "Wake mode: Stand".
As explained in the manual:
SYSTEM MENU (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md#system) : Wake mode
In the video you posted, wake pin is wired to the stand (Internally disconnected from the T12 plug, or the shake sensor removed).
The JBC has a metal ring connected to ground, so when it touches the stand, the signal is tied to ground.
You can do the same with a T12 handle.
If it's the plastic handle then you'll need to use a switch.
Check Wickated's stand for reference:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1396547)
-
I have fabric soft…
I know that on your soft everything work well :)
Tomorrow I change my shit clone stm to stm32f101cbt6 and I will upload your soft :)
-
Please start writing in full sentences and without ugly abbreviations 🤨
-
Please start writing in full sentences and without ugly abbreviations 🤨
r u k7
-
Hey guys, I've been researching about these t12 stations. The fact that I'm from Serbia kind of limits my options a little bit. I've narrowed it down to these 2 options but would appreciate some help in deciding the one to buy. BTW this is my first soldering station, so sorry in advance if I don't know something :).
1. https://www.banggood.com/Quicko-T12-942-MINI-OLED-Digital-Soldering-Station-T12-907-Handle-with-T12-K-Iron-Tips-Welding-Tool-p-1326151.html?cur_warehouse=CN&rmmds=search (https://www.banggood.com/Quicko-T12-942-MINI-OLED-Digital-Soldering-Station-T12-907-Handle-with-T12-K-Iron-Tips-Welding-Tool-p-1326151.html?cur_warehouse=CN&rmmds=search)
2. https://www.banggood.com/T12-Soldering-Station-Infrared-Soldering-Station-Portable-BGA-Rework-Station-Welding-Tools-200-450-with-T12-K-T12-BL-Soldering-Tips-p-1764997.html?cur_warehouse=CN&rmmds=search (https://www.banggood.com/T12-Soldering-Station-Infrared-Soldering-Station-Portable-BGA-Rework-Station-Welding-Tools-200-450-with-T12-K-T12-BL-Soldering-Tips-p-1764997.html?cur_warehouse=CN&rmmds=search)
The benefits of the quicko are the better display which I really like, and that it's without PSU (I can get a used laptop one here for under 5$) which is a lot safer
The benefits of the Handskit are the vastly better pen, the other included tip (which I've heard is a lot useful), and the stand.
The main thing I want to know, since I've never soldered before is if the Quicko pen is really that bad? Thanks in advance!
-
Both stations are STC based, meaning they aren't compatible with David's firmware.
Quicko's handle isn't that bad, it's serviceable. It's less practical because the locking screw makes it harder to swap tips and it's also less accurate for fine work because the distance from the tip to your fingers is significantly longer. If you've got shaky hands like me when doing very precise work, Handskit handle is a huge help. But sometimes, having a longer tip helps accessing a component between taller components (like heatsink or something). Handskit handle gets uncomfortably hot when in use for over 30min. It's not "burning hot" but still, more heat shielding would be needed.
Finally, when it comes to internal vs external power supply, your tip will most likely not be grounded with an external supply. Sometimes, Chinese manufacturers fail at grounding tip even with internal supply but it's usually easy to fix.
-
These T12 mini have stm32:
www.aliexpress.com/item/1005002306563910.html (http://www.aliexpress.com/item/1005002306563910.html)
www.aliexpress.com/item/4000567017884.html (http://www.aliexpress.com/item/4000567017884.html)
-
I know they aren't, but I was planning on maybe getting an stm controller and replacing the stc one. Also, I think this is the most active t12 forum so it was a good bet someone was going to answer :).
About the quicko tip, I was wondering if I could just stick some silicone tape (like the one you use for bike handlebars) around the metal so I could hold it closer to the tip. I do have shaky hands...
-
They don't ship to Serbia :(
-
You can't replace a stc with a stm32, physically they are completely different.
I checked shipping to serbia, why is so extremely expensive? It's more expensive than the station itself!
This small T12 has very cheap shipping to Serbia, yet there's not CFW for it, might be enough for your needs if searching for something economic, also uses 5.5mm barrel connector suitable for your laptop charger:
https://www.aliexpress.com/item/1005003209383311.html (https://www.aliexpress.com/item/1005003209383311.html)
-
I saw this comment and thought that you can.
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3970565/?topicseen#msg3970565 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3970565/?topicseen#msg3970565)
Never mind, not a big deal. It's the same handle though. Probably going to end up getting the 7 segment display one. Thanks!
-
Yes, you can replace a stm32 clone with a real one, as it's meant to be a direct replacement.
But this can't be done with stc, the package and pinout is completely different.
-
Okay, I get it now. Thanks.
-
Can this firmware work in ksger c210 ?
I'm looking for resource of that controller and nothing found for the board sch and pict.
Did you guess that a same board as t12 ?
-
Probably very much the same but no idea unless someone posts pictures of the board.
-
You can't replace a stc with a stm32, physically they are completely different.
I checked shipping to serbia, why is so extremely expensive? It's more expensive than the station itself!
This small T12 has very cheap shipping to Serbia, yet there's not CFW for it, might be enough for your needs if searching for something economic, also uses 5.5mm barrel connector suitable for your laptop charger:
https://www.aliexpress.com/item/1005003209383311.html (https://www.aliexpress.com/item/1005003209383311.html)
Better to get a Pinecil, it only costs $26 and it does support CFW
https://pine64.com/product/pinecil-smart-mini-portable-soldering-iron/ (https://pine64.com/product/pinecil-smart-mini-portable-soldering-iron/)
-
can i use c210 catridge with this firmware right now if i use original t12 v3.0 board ?
-
C210 connection is the same as the T12, so it should work without modifications (But will require calbration)
-
yes i already read at github, i mean on firmware side can it detect the c210 ?
and also the power supply input it'll just work at 24v or i have to change with 12v ?
-
Most stations use specific resistor values in the handle to detect that, but there's no way the firmware can detect the cartridge type with the limited Ksger hardware unless modifications are made, something that would require fine soldering to the stm32 pins, so the idea was discarted long time ago.
So cartridge type must be manually selected in IRON menu.
-
ok i understand right now, but i must down the supply input to 12v or the firmware can do that automatically?
https://imgur.com/gallery/6mrrU2Y
i found the pict of ksger c210 controller, but it seems a new board they call wlida that use MM32.
and someone has been modded for t245 at 5th image.
-
The firmware can limit the power that goes into the cartridge, ex. 50W max, based on the reading of the power supply voltage and the heater impedance (It's user-adjustable)
Basically it limits the pwm active time, so if 100% pwm would make 100w, to set a 50W limit it will limit the duty to 50%.
The power supply voltage and the power limit is refreshed on every pwm cycle, so the accuracy is pretty good.
However it can't regulate the voltage in any way, there's nothing to do so in the board, it might be a better firmware but can't make miracles :D
The mosfet will switch much better at 24V than 12V, in fact at 12V it might overheat when using high current loads like a JBC tip.
-
Hey guys, I'm not sure if this is the correct place to ask but I received my KSGER 2.1S iron today and I was wondering what modifications I need to make it safe?
The PCB is black and labeled "V2.05". The control board is blue with an STM32 but no version:
(https://i.imgur.com/SiJlEnZm.jpg)
(https://i.imgur.com/sXil63Um.jpg)
More pictures: https://imgur.com/a/F3JDS1J
The one thing that concerns me is that I'm not seeing continuity between the solder tip and the earth ground plug?
Thanks for any help!
-
https://www.youtube.com/watch?v=QESGY5LzPPw (https://www.youtube.com/watch?v=QESGY5LzPPw)
https://www.youtube.com/watch?v=9BnxiF-gQwQ (https://www.youtube.com/watch?v=9BnxiF-gQwQ)
-
Thanks, but those are for an older version of the PCB.
Anyways, I've found a few other guides to ground the case and tip.
However, I can't seem to slide the sleeve over the tip onto the handle. Has anybody else had this problem? I suppose I could just grind the sleeve a bit but I'm not sure?
-
It should slide effortlessly as in gravity alone should do it. At the tightest point, my sleeve has an inner diameter of 5.9mm.
-
Thanks for the reply ... Mine measures 5.5mm so either they sent the wrong sleeve (with the correct handle?!) or it's a manufacturing error.
I've contacted the seller but there should be harm in filing/grinding a bit of the sleeve to make it wider, right?
-
Yeah, as long as it's the only defect, filing that to correct specs will do.
Here are some more measurements to make sure you received the right part:
inner tube diameter: 7mm
inner tube diameter at the top end: 5.9mm
tube length excluding locking nut: 20mm
tube length with locking nut: 25mm
-
@DavidAlfa i have few questions
i have in plan to buy this station https://www.aliexpress.com/item/1005003713432532.html?spm=a2g0o.productlist.0.0.2b4a538bkQ5GYr&algo_pvid=8d5d11eb-da7b-4f09-ae4b-c0cbda821623&algo_exp_id=8d5d11eb-da7b-4f09-ae4b-c0cbda821623-18&pdp_ext_f=%7B%22sku_id%22%3A%2212000026905474132%22%7D&pdp_pi=-1%3B243.53%3B-1%3B-1%40salePrice%3BPLN%3Bsearch-mainSearch (https://www.aliexpress.com/item/1005003713432532.html?spm=a2g0o.productlist.0.0.2b4a538bkQ5GYr&algo_pvid=8d5d11eb-da7b-4f09-ae4b-c0cbda821623&algo_exp_id=8d5d11eb-da7b-4f09-ae4b-c0cbda821623-18&pdp_ext_f=%7B%22sku_id%22%3A%2212000026905474132%22%7D&pdp_pi=-1%3B243.53%3B-1%3B-1%40salePrice%3BPLN%3Bsearch-mainSearch)
this version is with larger oled display and stm32 later i wants assembly it make photos etc but before i buy it wanna ask something , how much power i need to fully drive T12 tips - 72W or 75W ?! because ksegr t12 claim about its power transformer deliver 120W 24V/5A while QUEEKO T12-959 claim about its station have power 108W 24V/4,5A - is this big difference in tip heating speed ? 72W is enough or 75W ? i ask because in latest station model which i buyed BAKON 969D 60W or 55W this is maximum power heating of this station and is reall crap i must wait much more to heat tip and it lost temperature faster in sharp tips
regards
-
72W is the theoretical max those T12 tips can draw. Though to use that much power, you'll need one of the biggest tips 'cause you need actual contact surface to transfer heat to the board. You'll be lucky if you manage to draw 50W with the usual D24, BC2, or other small conical tips.
On the other hand, you wouldn't really want to run a Chinese PSU at 100% load anyway as the usually specify their peak power instead of continuous running power. So you don't really need 72W most of the time and when you do, it's better to have some extra power to avoid voltage sag. Pick a 96 or 108W for best results, anything beyond that is marketing BS.
-
Hi, I might know a lot of things but I'm not the king of wisdom, I only have a Quicko T12 108W :-DD
For sure lots of people here have tried others and might help much better than me.
If the cost difference is minimal, I'd get the most powerful, enabling the posibility of using JBC tips in the future.
I know Ksger 72/75W power supplies are very tight and will barely handle anything over that, also few security concerns regarding the design.
All I can say is that my 108W supply handled C245 pretty nicely, limiting the voltage to around 20V (Still putting ~150W onto the load), doing the job instead restarting, turning off or exploding :D
The actual power on a T12 will be the same no matter the power supply, you have 24V and a 8ohm load, max power will be 72W no matter what.
-
Warning: it's a MM32SPIN27PF. That's a Cortex M0, so it won't be compatible with this CFW.
There isn't a single ksger with a M0 mcu, all use STM32 F1 series (cortex M3).
Porting it would be lot of work for just a single board.
I recommend replacing it with a stm32F103C8 or CB, ex. from here:
https://www.aliexpress.com/item/1005001953737425.html (https://www.aliexpress.com/item/1005001953737425.html)
Might be a clone, but most work ok. Only CH32F have issues in this FW (ADC reading random values).
hello
I was thinking of buying a ksger v3.1s and putting the custom firmware on it.
as already mentioned, since a few months they produce the control board with a "mm32" chip.
are the pcb and the components on it the same as the version with stm32?
or would i risk soldering an stm32 and then having a pcb not compatible with the controller?
thanks
-
I'm almost sure the board is the same. Probably they simply recompiled the existing firmware for it.
I could try compiling the FW for STM32F072 (Like some Quicko boards), which is a Cortex-M0 cpu like that MM32.
However, ST-LINK won't work with it. Not all hope is lost, quoting the datasheet:
"The Boot loader is stored in the system memory and can be reprogrammed to the flash memory through UART1."
So there's a UART bootloader like in STM32, which might be (or not) compatible with the STM32 bootloader format. There's only way to know: Testing it!
To set it in bootloader mode you need to set BOOT0 to high level (3.3V).
However, there's another problem: Boot0 is directly routed to ground in these boards, the only way to set it high is to *very carefully* apply heat, lift it and solder it to VDD.
Then, it's pretty straighforward, tahe the USB serial converter, connect Rx, Tx and Gnd, open STM32CubeProgrammer (Or FLASHER-STM32) and connect to the serial port using 115.200 baudrate.
But in any case, it might not work at all in the end, and if you didn't manage to backup the original firmware, you'll have to replace the controller.
So, first of all, try reading the original firmware using the uart bootloader.
-
Hi!
So I am in the unfortunate situation, that my device will have the MM32 chip in it. Now fortunately I can get either a STM32F101CBT6 or a STM32F103C8T6. I would lean to take the letter, but I am unsure if it is fine regarding the storage size.
-
Although the C8 is sold as 64KB, it actually has the same 128KB as the CB, so any is fine.
But beware, clones don't follow this rule.
If you're planning to replace it, why don't you try the bootloader mode first and see if It can be read or programmed?
Who knows, it might work.
-
Thanks for the fast reply, I will give it a shot! Regarding whether it is a clone or not, I would be ordering from a reliable seller in Germany, it will definitely be a real STM32 :).
-
@DavidAlfa i have few questions
i have in plan to buy this station https://www.aliexpress.com/item/1005003713432532.html?spm=a2g0o.productlist.0.0.2b4a538bkQ5GYr&algo_pvid=8d5d11eb-da7b-4f09-ae4b-c0cbda821623&algo_exp_id=8d5d11eb-da7b-4f09-ae4b-c0cbda821623-18&pdp_ext_f=%7B%22sku_id%22%3A%2212000026905474132%22%7D&pdp_pi=-1%3B243.53%3B-1%3B-1%40salePrice%3BPLN%3Bsearch-mainSearch (https://www.aliexpress.com/item/1005003713432532.html?spm=a2g0o.productlist.0.0.2b4a538bkQ5GYr&algo_pvid=8d5d11eb-da7b-4f09-ae4b-c0cbda821623&algo_exp_id=8d5d11eb-da7b-4f09-ae4b-c0cbda821623-18&pdp_ext_f=%7B%22sku_id%22%3A%2212000026905474132%22%7D&pdp_pi=-1%3B243.53%3B-1%3B-1%40salePrice%3BPLN%3Bsearch-mainSearch)
this version is with larger oled display and stm32 later i wants assembly it make photos etc but before i buy it wanna ask something , how much power i need to fully drive T12 tips - 72W or 75W ?! because ksegr t12 claim about its power transformer deliver 120W 24V/5A while QUEEKO T12-959 claim about its station have power 108W 24V/4,5A - is this big difference in tip heating speed ? 72W is enough or 75W ? i ask because in latest station model which i buyed BAKON 969D 60W or 55W this is maximum power heating of this station and is reall crap i must wait much more to heat tip and it lost temperature faster in sharp tips
regards
someone i know just got one of these thinking it was going to be stm but he says it is stc. i have not seen pics yet but i dont know why he would tell me that if it wasnt. just like i have a handskit unit that was sold to me as stm32 but when i got it and complained it was actually stc they changed the description and basically told me they were sorry and thank you for my order. didnt care at all. i tried disputing it but since they changed the listing to stc aliexpress decided in their favor.
-
Always take videos and/or pictures before claiming, just in case.
Doesn't AliExpress save a cached version of the listing, linked to the date when the item was purchased, like in eBay?
I very rarely have claims rejected in Ali.
Ex. My $22 858D was DOA (Dead on arrival), the seller wanted me to return it (More costly than the whole thing), so I argued that I shouldn't pay anything as it wasn't my fault.
Claimed, properly showed the problem to AliExpress, ignored the annoying seller pms, and won.
After some investigation, it was only a bad solder joint :-DD
Another example:
Bought a USB 2.0 hub, but it worked at 1MB/s at best.
Opened it, took pictures, downloaded the datasheet (USB. 1.1 hub wtf) and opened a claim sending all my proofs, showing the board pictures, IC marking, and the datasheet description. Zero issues, next day refund.
Bought a usb 2.0 pin-compatible controller ($1.5) and got a 7-port USB 2.0 hub for... $1.5 :D
-
yup this was my first one they ever rejected i make sure to take screen shots and all that now just in case. every other time i ever had an issue aliexpress has been really good to me. needless to say the couple handskit units i have ordered so far have both been crap honestly
-
Mastershake, how many stations do you have already?
Last time it was something like 5 ksgers.
Then you also got the T3A, now trying to build the Unisolder... You're not needing heaters in winter hehe :-+
-
haha to many. i just havent found THE station yet. for me its kind of a hobby. i also have a few guys working for me doing repairs at the office along with me so some of them we buy for the shop to have around as backups or for the guys to use and see of they like them better then what they are currently using. the unisolders will prob be mine to keep at home though. im kind of ocd so i tend to mess with things more often then not lol to see if there is better.
-
Hello David,
thank you for continuing the development of the open source firmware. I bought a Quecoo T12-955 and was able to flash the KSGER_v2 firmware variant without any problems. The main PCB is marked Ver3.3 and uses some different parts than in the KSGER schematic by floobydust. For example, the main P-channel MOSFET is a RU30L30.
The MCU seems to be an original SM32F103CBT6, where the readout protection was not enabled, so I was able to read the factory firmware V2.10 without any hacks. Please PM me if you need the file.
By the way, my STM32CubeIDE wanted to update to version 1.9.0. After updating, I was not able to compile the firmware any more, loads of multiple definition of ... gcc errors. Since the update provides gcc version 10.3.1, adding -fcommon to the GCC options did the trick.
-
It'll problably be the same as the existing T21-955 backup (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/Original_FW/Quecoo), but please compare them, it might be newer version or who knows.
No idea about CubeIDE, I still had 1.8.0 and it never complained since 1.4.0 or even older.
I'm updating the IDE... Already shaking, I have a bad feeling about this :D
Edit: Indeed, installation f*** everything up.
Will check that later, not having the mood to fight it today.. :palm:
-
Oh, the joy of updating otherwise working software...
My update from 1.8.0 to 1.9.0 went smoothly, but then gcc threw errors when compiling/linking, since -fno-common is the default in newer versions of gcc.
I compared my T12-955 firmware dump to the one already in the github repository. They are completely equal.
-
Okay, I just wiped ST folder and reinstalled cleanly and worked. Fixed the compilation errors.
Few very silly mistakes (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/c39de3382e9b7cf0f279ddf99bbd2dbf7adc9979), don't know why GCC didn't complain before!
-
Great that you found the errors so fast. Now it compiles for me also without any problems.
-
I don't remember having to do any specific config for previous versions but it seems like v1.9.0 doesn't generate bin file by default. Granted we can just feed the raw elf file to the programmer I think it might be good to document that in the readme.
That can be found in project Properties > C++ build > Settings > MCU post build outputs > "Convert to binary filie (-O binary)"
-
Hello, thinking of getting a quecoo t12-959, any compatible cfw for it?
-
Hello, thinking of getting a quecoo t12-959, any compatible cfw for it?
No. It's not STM32 and the display's also unsupported.
-
I don't remember having to do any specific config for previous versions but it seems like v1.9.0 doesn't generate bin file by default. Granted we can just feed the raw elf file to the programmer I think it might be good to document that in the readme.
That can be found in project Properties > C++ build > Settings > MCU post build outputs > "Convert to binary filie (-O binary)"
Migrated profiles to CubeMX 6.5.0 and enabled Hex/Bin generation by default (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/0896c5ea3acc9f9c0b83fa162dce5a5deaaab6e1)
Hmm... I never understood those strange updates ST always do.
Seriously, updading the IDE always gives the same feeling as plugging some scrapyard finding, completely untested, straight to a 400V 1MW transformer, without any breaker or protection in between :D
Compiled and tested, everything seems working.
I'm just ensuring the newer IDE/Compiler versions work, didn't made new builds because there're no code changes.
-
Compiled and tested, everything seems working.
Almost... ;)
The Debug configuration generates bin and hex files by default now, the Release config still does not.
-
Ahh will re-check
Edit: Some profiles had Debug config selected as default. So they were mixed. Enabled bin/hex generation for all configs and all profiles.
-
Hello David,
thank you for continuing the development of the open source firmware. I bought a Quecoo T12-955 and was able to flash the KSGER_v2 firmware variant without any problems. The main PCB is marked Ver3.3 and uses some different parts than in the KSGER schematic by floobydust. For example, the main P-channel MOSFET is a RU30L30.
thats a good one h2.1 board. only disadvantage is i2c screen. even 8551 OPA is good enough. also David suggests to change LED to fast(low capacity) diode.
and i still dunno if quartz is needed to run CFW :-//
edit - oh i see - quicko has no quartz, but has quartz load caps instead. ksger has quartz but with no load caps. looks like budget was limited to only one to choose :-DD
-
Crystal is only used in the original firmware for the real time clock, unused in cfw.
-
David, is it possible to remake your firmware for TFT SPI display 1,8"?
https://aliexpress.ru/item/1005003797803015.html
Now my SPI OLED display works with your firmware. But he's small.
-
I already thought this many times.
Last year, I bought a 1.14" 135x240 ST77889 display for testing.
I modified, improved and released (https://github.com/deividAlfa/ST7789-STM32-uGUI/) a driver/graphic library for it making use of stm32 DMA, achieving prettty nice speeds.
Anyways, there're several reasons I decided to not do it:
- It's a lot of work, specially if I have to add every display/driver anyone requests. Also, I would have to buy the display for the development.
- The graphics driver would need to be done completely, there's no RAM for buffering, all operations need to be done at pixel level over the lcd interface.
- Even if using DMA, driving a colour LCD over SPI is usually pretty slow, specially ksgers using stm32F101 (36MHz). Only DMA transfers (image/block filling) achieves acceptable speeds, fonts are way slower, specially big fonts.
(Have you seen those arduinos refreshing the display at 2FPS? No thanks!)
- Wasn't happy with the performance/image quality, redrawing usually causes tearing effect or glitches due the interface slowness.
Most of these displays can't be read over 3-wire SPI, so forget transparency. Also most don't have Tearing Effect output to minimize the tearing.
- It would be a lot of work just for a minority of users.
-
It's a pity. But I understand you.
It's just that with age my eyesight worsened and I wanted a bigger display. And I already have such a TFT display.
I'll have to order a larger OLED. Under the current conditions, it will not be cheap.
-
I also understand you! But it's a lot of work!
Regarding the screen size, I find these 2.4" OLED screens price close to insulting.
About 3 weeks ago I ordered this 128x64 2.4" monochrome LCD for testing (I'm still waiting for it):
https://a.aliexpress.com/_uAbRI3
Making it work will be much easier because it shares the same rows/columns pixel structure and resolution, so it should only take few changes to the display commands.
LCDs have worse contrast and brightness than Oleds, but they don't have burn-in issues and are a lot cheaper.
I have yet to see the image quality, if it looks terrible, then why bother?
Also the brightness can't be controller unless more circuitry is added. Not really a big issue as it won't wear out like Oled do.
-
About 3 weeks ago I ordered this 128x64 2.4" monochrome LCD for testing (I'm still waiting for it):
https://a.aliexpress.com/_uAbRI3
Which of the three colors?
Blue, cyan or black?
Blue is very fond of the Chinese themselves - they put them everywhere. Perhaps this is due to their perception of color.
But I really don't like blue.
Will the characters on black be visible well?
Show me the result, please.
-
I ordered the black model, but the colour doesn't matter, they will work in the same way :)
-
The well-known Chinese device. LCD 128x64 SPI
Will his indicator work?
Now from China it is very long to wait for a parcel. And there are many such testers. And they lie idle :)
-
You can't simply plug any screen and expect it to work, every screen is different, might have a different controller...
The display you showed seems to be this one (https://datasheetspdf.com/pdf-file/1412268/ETC/12864B-2A/1)
Looks like it uses the same command set as the ST7565R (https://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf), which the controller of the display I'm waiting for.
So once I test it, if it works for me, should work for you, too.
-
I'll wait for the results of your experiments.
I have an experimental "rabbit" (display) - I can try it. :)
-
I just noticed that Banggood has the "10pcs T12 Soldering Iron Tips Set" on FlashDeal for 18.99 USD and thought this might be interesting for some of you guys:
https://www.banggood.com/custlink/KKDdUK0zom (https://www.banggood.com/custlink/KKDdUK0zom)
I will order one set even I still don't have a T12 station yet (but will order one too).
-
I have an old controller from KSGER V2.0.
[attach=1]
I uploaded the firmware from David - it works. Even replaced STM 101 with 103 (was in stock).
But I don’t understand where he takes the input voltage data from?
I reviewed the entire board - there is no resistive divider from +24 to the STM port (unlike later versions).
Therefore, the display shows the wrong voltage: 19 - 20 volts, regardless of the real input voltage (changed from 15 to 24 volts).
Add missing details? On the 19th pin, if I'm not mistaken?
When calibrating, in order to reach 400C, I had to "wind up" almost to the maximum (40000) the coefficient
The operational amplifier is SGM8551, the resistors in the strapping correspond to the ratings. And this is the situation with T12, and with JBC (Chinese).
-
Edit: It seems it's a unknown version? A lot of connections seem different.
Pin 19 (PB1) seems to go to the temperature sensing instead the voltage monitoring, also the buzzer and eeprom seems different?
Clearly this board need a new profile. Not compatible with any other existing ksger profiles.
I can barely appreciate anything in that picture, please update with better resolution, both sides.
And you have to trace the connections, I need the schematic to adapt the firmware.
-
I will make an external resistor divider. Which PIN of the controller should the signal be sent to?
Here is the schematic from this version of the controller. The port assignment is different from later versions. For example, the PWM port on the key transistor is PA6, and in version 2.1 it is PB0.
But it works with your firmware. :)
But it is possible that the problems with the calibration are connected precisely with the other purpose of the controller pin.
In my version 19 pin is the PWM control, while in others it is the voltage control input.
Surprisingly, temperature control works in this configuration as well.
-
Oh wait, the v2.0 naming confused me, it's basically a v3.0 hardware and should use that firmware.
It's all right. Your version is here (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r2/STM32_T12_oled_v2.0.pdf).
As you see, v3.0 (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/KSGER%20STM32%20OLED-3_0%20schematic%20rev1_cosmin_floobydust.pdf) is almost the same.
The only difference I can really see is the missing voltage monitoring. I hadn't notice before.
Well, whatever not being there, you can use that schematic as reference. Supply monitoring goes to PB0 (stm32 pin 18).
Replace R5 (249K) with 120K or 150K and try calibrating.
-
OK. Thanks. I'll try and post the result here.
Today is Friday - if I do not have time, then on Monday.
P.S. I added two resistors with a 104 capacitor.
Connected to 18 pin stm - everything worked fine.
Now correctly displays the input voltage.
I'll deal with the amplification factor later.
-
I also came to the conclusion that OLED displays are not the best option, there is burnout and the size is small. I hope that David will offer an option with a SPI display, which he ordered on Ali, he also ordered the same ;)
-
Nice work yelkvi :-+
Polf, I bought the inverted model, white pixels over black background, imitating the OLED style.
Didn't arrive yet... Something weird happenned with that order, usually it takes 10-15 days, it's been 40...
Check the feedback here, there're lots of pictures.
Some look great, others are dim or bleached, it's impossible to really know.
https://www.aliexpress.com/item/1005001621784395.html (https://www.aliexpress.com/item/1005001621784395.html)
-
I ordered in the same store and also black and white, we'll see what comes. The mail service is called 4PX Express, but I don't think it will be fast.
-
Viewing angles are probably not great judging from users' pictures. It may or may not be a problem depending on where you position your station.
-
It's a LCD, they'll always have that issue.
However, I don't see the sense of spending $20 on a 2.4" oled screen, on top of that having to handle it like Extremis Expensivium Delicatum stuff.
Does the LCD look worse? Sure. But doesn't burn out and costs a quarter.
It's .just a test :)
-
LCD displays come with different angles of the best view.
Perpendicular, top, bottom. I have one multimeter better visible from below, and the other vice versa.
Like this Chinese, David will see only when he receives the package. And we will wait :)
-
You can't simply plug any screen and expect it to work, every screen is different, might have a different controller...
The display you showed seems to be this one (https://datasheetspdf.com/pdf-file/1412268/ETC/12864B-2A/1)
Looks like it uses the same command set as the ST7565R (https://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf), which the controller of the display I'm waiting for.
So once I test it, if it works for me, should work for you, too.
I have a 14 PIN display.
Here's one: https://aliexpress.ru/item/1005002863542148.html (https://aliexpress.ru/item/1005002863542148.html)
P.S. Today I continued to modernize the Chinese board on the advice of David.
I put a DC / DC converter from 24 V to 5 V so that the 3.3 V stabilizer is less heated.
Also, a 10 Mom resistor is added under the board at the thermocouple input.
-
I would love to see something become of this, you guys should consider teaming up and making a better controller board and sell these!
-
A good option for firmware from David. Powerful power supply. Easy to convert to C245. The price is good. I ordered myself.
https://aliexpress.ru/item/4000183089084.html
The same power supply is used in the Aixun T3A. I checked - I connected the controller with David's firmware to this power supply. Works well with C245. Does not turn off when heated.
-
Hi,
It is possible that fw will work with QUECOO T12-959?
-
It's not possible. T12-959 uses a completely different microcontroller and doesn't have nearly enough RAM on top of it.
-
Will update the readme in a while.
T12-958 has been tested working (after replacing the mm32 with a stm32), and the t12-959 needs to be added to the non-compatible list.
-
I use two types of soldering iron handles - T12 and C245. The T12 has a vibration sensor. And so I chose Shake from the menu. In C245 I use Stand mode. For some reason, when switching profiles T21 <> C245, these settings do not switch (they remain the same). I have to manually edit every time I change the handle.
But the NTC setting switches when changing the profile (there is no NTC in the C245, but there is in the T12).
Is it a firmware feature?
-
Options inside IRON menu are profile-specific, SYSTEM's are global.
I modified these options to be profile-specific and moved to IRON menu.
New builds available, test them.
Note down your calibrations before updating, the settings structure has changed, so everything will be deleted!
BTW, these settings are still running great with the same tips, untouched for months, I barely have any overshooting, while still getting decent heating speed.
Test them, and if it improves the response for most users, I'll set them as default.
It's annoying because Aliexpress tips performance degrade a lot within few months, new tips might be able to run much stronger PID settings than old tips.
Kp 44.50
Ki 120.00
Kd 10.00
Imax 0.75
Imin 0.00
Filter 75%
Threshold 50
Count limit 0
Step down -3%
Min 50%
Reset limit 600
50%
600
-
Thanks. I'll try tomorrow. The soldering iron is at work, and I'm already at home. :)
-
Installed on my v1.5 with the proposed filter settings. I can't say I did much testing but at the very least it works, it melts solder and nothing's on fire... Standby and wake from shake both appear to be working as intended.
I don't notice much difference in terms of heating speed from the new filter settings, granted I didn't time it. Overshoot seems to be non existent, though it was already fine with the old settings.
-
There are no big changes, just wake mode / shake filter / stand mode are profile-specific now, nothing else.
I didn't have a lot of time to debug but everything seemed to be working correctly.
The default pid/filtering were ok when my tips were newer, but as they aged and the thermal transfer worsened, they started to overshoot more and more until I adjusted them again, and stayed perfect since then.
The filtering had to be strong due some very noisy ksgers, the threshold was later added for that, extreme filtering is not the best option as it causes poor response.
-
March 30 version - everything is fine. Now it is convenient to change T12<>C245 profiles.
I changed the settings, as David advised above - it soldered well. I can not compare with the previous settings, since I have been using this firmware recently. The experience is small in comparison.
-
I have some free STM32F303CBT6 chips.
Will they work in this soldering station instead of stm32f103?
-
I don't think so, STM32F1/F2/F3/F4... are different in architecture, it would require modifying the firmware.
In any case, it would be a waste, these mcus are a lot more powerful and even the slower 36MHz ksger are already fast enough.
-
Thanks for the answer. It's just that there are unused chips - I wanted to put them to good use somewhere. :)
-
do i need to check new fw build or localization is ok?
-
do i need to check new fw build or localization is ok?
Nothing has changed in localization. David moved one menu item from global to iron:
"There are no big changes, just wake mode / shake filter / stand mode are profile-specific now, nothing else."
Now when changing the profile ( T12-C245-C210 ) the wake-up method is also switched
-
do i need to check new fw build or localization is ok?
Nothing has changed in localization. David moved one menu item from global to iron:
"There are no big changes, just wake mode / shake filter / stand mode are profile-specific now, nothing else."
Now when changing the profile ( T12-C245-C210 ) the wake-up method is also switched
spasibo
also i still dont get why it should be changed since u can easily modify t12 to use stand switch. :-/O
-
Ksger v3/v3.1 users, what's you screen offset? Unmodified stations (Original screens) only!
Ricktendo, check this... it seems there might be that subtle difference between v3 and v3.1?
Hello. I flashed my board with version [v3.1] / [64pin] / STM32F103RB. Got artifacts on display, vertical bar on the left.
Go to settings, system and adjust offset to 0.
v3 offset is 2.
I recently purchased a KSGER OLED-v3.0 (printed on the board) and I would like to report the correct offset for me is 0 (zero,) can anybody else with a similar board confirm this, if so please set the default offset to zero.
also i still dont get why it should be changed since u can easily modify t12 to use stand switch. :-/O
Well, the fact that we aren't using that option, doesn't mean it isn't useful for someone else.
It's ok! :-+
-
I finally got my t12-955!
I was able to flash the custom firmware but couldn't figure out how to change the tip.
It's stuck on B3 (if I remember correctly)....
I clicked and rotated clockwise but the other tips don't come up. Is there a tips presets?
Thanks!
-
If I added 20 tips, all would be uncalibrated, so instead, only one tip is provided.
New tips copy the calibration values from the first tip in the system.
Calibrate that BC3 (you can rename it), after that newly added tips will be pretty close to the target temperatures, not requiring calibration in most cases.
Creating a new tip takes 15 seconds, enter EDIT TIPS/ADD NEW...
Once added you will be able to switch them.
There're no presets because almost nobody reported calibration results when I asked.
And I'm not going to buy every Ksger controller, dozens of tips and spend hours calibrating for the sake of lazy people... :D
-
If I added 20 tips, all would be uncalibrated, so instead, only one tip is provided.
New tips copy the calibration values from the first tip the system.
Calibrate that BC3 (you can rename it), after that newly added tips will be pretty close to the target temperatures, not requiring calibration in most cases.
ah ok! now it's clear to me.
So I can copy the same values of the BC3 and calibrate the D24 with those values?
Since this is my first soldering station with T12 tips, I thought each tip had different physical parameters from each other type.
-
You don't need to manually copy the values, you can either copy the tip (In the tip settings menu) or just create a new one, the values will be copied automatically from the first one.
But here's the thing, you might buy few D24s, each one from a different seller, and get huge variations in the performance/calibration between them.
So there's no sense on doing any presets, because even the tips have huge differences.
-
So there's no sense on doing any presets, because even the tips have huge differences.
ok, now i understand, it makes sense
There're no presets because almost nobody reported calibration results when I asked.
So far I've only calibrated my D24 which is my absolute favorite tip!
If it makes sense I can share my values with you... but from the quote above I understand it doesn't make much sense :)
-
I would need quite a lot of feedback to make a decent preset. If 20 ksger v3 give 3500-3700, that's close enough to say 3600 is safe to use.
But last time I tried, got 3-4 reports, very different from each other, so I just set a pretty low value to make it safer ::)
-
First time I tried to calibrate a tip running stock firmware, I ended up with a bright red glowing stick. Scary stuff.
You just can't make universal presets, there's too much variation between board and tip brands. Not to mention Chinese brands can't even make two identical tips that behave the same way.
-
The new firmware version is very good. However, the PID for the JBC tips had to be changed because the stability of the temperature stabilization was greatly degraded.
Temperature fluctuations are very large.
To make them smaller, I had to set the parameters:
Kp=30
Ki=15
Kd=45
-
The new firmware has no changes in anything related to performance or calibration!
Restoring your older calibration should perform exactly the same.
Have you tried the settings I posted few messages earlier?
-
Yes, I tried your settings (PID + Filter), although I wasn't sure if they were for JBC C245. With these settings, the temperature of the soldering iron does not stabilize and swings like a pendulum. Previously, you also gave similar settings, but they gave the same result. I have iron according to the KSGER 2.1S scheme.
-
C245 has much faster response, those are for T12!
I don't have C245...
-
Yellow SSD1309 problem when sleep enters.
-
Looks like the minimum brightness is on the limit for the pixel activation threshold for that screen.
Decrease the brightness option, does it also happen at any lower level?
What T12 board is it?
@Polf did it happen anytime in your yellow OLED?
-
I also have a Green SSD1309 running on that same board with no problems. Program version v2. Contrast at level 4-5 loses pixels.
-
Is it actually dim at 4-5 level, or still pretty bright with these weird patches?
Edit: Increased precharge/discharge clocks and Vcom Deselect voltage.
Does it make any difference?
-
Now contrast 10 works well. Contrast 3 is equal to sleep mode.
-
Now contrast 10 works well. Contrast 3 is equal to sleep mode.
any link for stand ? nice box design.
-
I bought a stand here.
https://www.aliexpress.com/item/1005003246855374.html?spm=a2g0o.detail.1000060.3.3daa3522RbUdXv&gps-id=pcDetailBottomMoreThisSeller&scm=1007.13339.274681.0&scm_id=1007.13339.274681.0&scm-url=1007.13339.274681.0&pvid=629faa35-176c-46a5-92d9-52e950a7a75e&_t=gps-id:pcDetailBottomMoreThisSeller,scm-url:1007.13339.274681.0,pvid:629faa35-176c-46a5-92d9-52e950a7a75e,tpp_buckets:668%232846%238109%231935&pdp_ext_f=%257B%2522sku_id%2522%253A%252212000024842420455%2522%252C%2522sceneId%2522%253A%25223339%2522%257D&pdp_pi=-1%253B184.41%253B-1%253B-1%2540salePrice%253BHRK%253Brecommend-recommend (https://www.aliexpress.com/item/1005003246855374.html?spm=a2g0o.detail.1000060.3.3daa3522RbUdXv&gps-id=pcDetailBottomMoreThisSeller&scm=1007.13339.274681.0&scm_id=1007.13339.274681.0&scm-url=1007.13339.274681.0&pvid=629faa35-176c-46a5-92d9-52e950a7a75e&_t=gps-id:pcDetailBottomMoreThisSeller,scm-url:1007.13339.274681.0,pvid:629faa35-176c-46a5-92d9-52e950a7a75e,tpp_buckets:668%232846%238109%231935&pdp_ext_f=%257B%2522sku_id%2522%253A%252212000024842420455%2522%252C%2522sceneId%2522%253A%25223339%2522%257D&pdp_pi=-1%253B184.41%253B-1%253B-1%2540salePrice%253BHRK%253Brecommend-recommend)
-
So it works well at all brightness levels including sleep?
Added to the repo (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/e46192e001df9f1e1fbba21ec0d47c37b218c8c3), new builds.
Anyone having display issues with the new settings, please report!
-
any link for stand ? nice box design.
Very high price. I have such a stand. AIXUN T3A was equipped with such a stand.
The body is painted plastic. I don't like the mesh. I like a wet sponge. If you have locksmith skills, then you can do this yourself. Or even better. Perhaps not so pretty. But the main thing is that it works.
Aixun T3B has a good idea - they connected the stand with the soldering station with a wire. And the soldering iron handle itself is connected to the stand. It is very convenient if, for example, like mine, the soldering station is fixed above the desktop on a shelf. And on the table is a stand for a pen.
-
Question: What is the function of the LED at the input of the 8851 op-amp?
What voltage drop should be on it?
I have seen boards with blue LED (2.6V) and red (1.8V) LEDs.
-
Cheap way of clampling the voltage going into the amplifier input, you don't want 24V there, it works at 3.3V!
Plus it lights up when tip power is active.
-
Thanks. I assumed so. That is, the type of LED is not important.
P.S. I received a parcel with a HandsKit soldering station (I posted the link above). I uploaded firmware V2.x - everything works fine. :)
-
Very high price. I have such a stand. AIXUN T3A was equipped with such a stand.
The body is painted plastic. I don't like the mesh. I like a wet sponge. If you have locksmith skills, then you can do this yourself. Or even better. Perhaps not so pretty. But the main thing is that it works.
Aixun T3B has a good idea - they connected the stand with the soldering station with a wire. And the soldering iron handle itself is connected to the stand. It is very convenient if, for example, like mine, the soldering station is fixed above the desktop on a shelf. And on the table is a stand for a pen.
all of them exept genuine one are lightweight. but it can be fixed with some rocks put inside. jbc stand has an unique ability to lock in place all types of handles - 210,245, even 115 should fit. i definitely dont have equipment and skills to mill this metal things. outsourcing would cost same or more.
-
Ksger v3/v3.1 users, what's you screen offset? Unmodified stations (Original screens) only!
C'mon! Everyone wants support here, but when I ask something, nobody cares!
Sorry to insist, but:
Ksger v3/v3.1 users, what's you screen offset? Unmodified stations (Original screens) only!
-
If this board can be considered V3, then with a screen of 0.96" offset = 0, and with 1.3" = 2
-
Ksger v3/v3.1 users, what's you screen offset? Unmodified stations (Original screens) only!
Additional to the Quecoo T12-955, I also own a completely unmodified KSGER V3.1 station.
The correct screen offset for this station is 0.
Regarding the calibration data for my KSGER V3.1, it really depends on the tip.
I tried two "identical" BC3 tips from different vendors on AliExpress. Both are new, they just went through a 30 minute burn-in cycle.
BC3 Tip 1: Cal 250°C 1073, Cal 400°C 2273
BC3 Tip 2: Cal 250°C 1309, Cal 400°C 2604
-
ill also check i missed the post where you asked hang on a min ill go grab one and check sorry for late reply i checked three of them all are set to 0 and are perfect.
-
This is why a color LCD won't happen anytime.
It's a simple test imitating the firmware appearance, even with optimized routines, clearing the LCD and redrawing everything takes 100ms, running at 72MHz.
That's about 10frames per second in a 160x128 screen, will be slower at higher resolutions.
Also the screen image quality is terrible!
The ST7789 screen looks much better, but it's 1.14".
-
Yes. It doesn't look good. That's why the Chinese in Aixun T3 used a more powerful GD32F305RET6 processor.
And the picture is much better. And the animation speed is great.
P.S. Has the LCD indicator arrived yet?
-
Well, are we talking about 16 or 24bit colors? If so, wouldn't it be good enough for a soldering station to reduce that to 4bit color palette? My guess is the slow refresh rate has to do with lack of bandwidth. Granted I have no idea how realistic that is, if even feasible. Anyway, that just a thought, I'm perfectly happy with B&W display.
-
You can't go 4bit, these display allow 12-bit as lowest, that would be even slower as you have a weird pixel arragement (a pixel is 1.5bytes) needing a lot of cpu power and limiting a lot the dma capabilities.
Anyways, the problem is the spi bus itself, a parallel LCD would do the same transfer at least 16x faster, if not even more when using the memory controller peripheral (no spi clock limitations).
Thus, it's impossible to wipe the screen and redraw it fast enough, it will always cause a small flickering.
Don't expect this ever on cfw, I was only being curious, drawing some stuff!
Some numbers so you can see clearly the limitations:
Oled 128x64:
- Frame buffer size 1024bytes
- Can be stored in the ram, and quickly transferred in a single shot.
- Theorical speed with 18MHz SPI: 2197fps
LCD 160x128:
- Frame buffer size 40960bytes
- Needs a lot of RAM, most mcus won't be able to store it, requiring modifying the LCD memory, slow and causes artifacts.
- Theorical speed with 18MHz SPI: 55fps
Of course, theorical speed is nowhere from real. You must process the fonts, address the pixels... there's a lot of overhead.
Clearing the LCD is also a frame, so, you can transfer in the best case 27 "real" fps, the screen will show the black frame due the slowness and look terrible.
That's why I laught at these Arduino projects where you see the screen drawing taking 3 seconds! It's so crappy :-DD
There're some tricks, but doesn't worth the time with spi and crappy LCDs.
Yelkvi, didn't arrive yet. No news since 26-february.
-
do stm support any other bus for screens?
i have a big station with this size of screen and it works wo any lag. actually didnt disassemble it, it should work on generic arm M series cpu
-
Of course they do.
STM32 F3/F4 series have F(S)MC, Flexible (Static) Memory Controller, can be used to interface memories, but also any other device using the 8080/6800 bus standard like a majority of those small parallel LCDs (D0-D15,WR,RD,RS...), example (http://aliexpress.com/item/32863719845.html), FMC+DMA would be crazy fast.
However, it takes a ton of pins and routing, no less than 20, that's why these SPI things exist, it's cheap and simple.
Probably, even driving the parallel screen by manually toggling pins will be faster, since a single write pulse transfers one pixel, while in SPI it takes 16 spi clocks, which run at 1/2 or 1/4th the core speed, so it's 32-64 cpu clocks per pixel.
I further optimized some DMA routines, got the 103 to write the same screen in 51ms(transparent font) and 34ms(normal font). That's wiping+filling, with a peak of 110fps.
The 32F411 running at 144MHz can do it in 21ms(transparent) and 14ms(normal), with a peak frame rate of 220fps.
Yet, you can be as fast as you want, there's no way to read scanline or provide Vsync in these cheap displays, so part of the black (screen wipe) is shown, and then the new content, causing the flicker.
The only difference is the 411 has 128K SRAM and could store the framebufer (40KB), reducing the display tearing...
That way tearing is a lot better:YouTube (https://youtu.be/NNAJT7QAf0M)
But 160x128 is crap and bigger screens (ex. 320x240) won't fit unless completely changing the hardware, not the target of this fw.
Enough testing! This screen is awful, don't buy it :)
-
SSD1309 Yellow goes out after a long test (solder and all vibration sensor and stand functions).
When you restart SSD1309 works (sometimes it takes 2-5 times to work).
-
Hardware KSGER v.2.1s display OLED 2.42" spi/i2c SSD1309 with the latest firmware of David works fine, no artifacts and problems. :-+
-
I also have a green SSD1309 that works without a problem. Probably a yellow SSD1309 some bad display series.
-
Why is yellow so good? I like white more - it has more contrast.
-
Artifacts problems yellow SSD1309.
-
Are you using wires to connect the display?
-
I don't use wires. I use a 7 pin gold plated connector.
-
If it's a custom board, I've seen several ones at 4pda/radiokot that are made way worse than ksgers.
7-pin connector? Those are SPI, sid you configure the display as I2C? As you said it uses v2 firmware.
Some pictures would be better!
It's strange because I relaxed a lot the I2C timings for these 2.42" displays, actually it runs nearly at half the speed of older versions.
-
I'm using v2 firmware. The green SSD1309 works without problems, and the yellow one shuts down sometimes and can't be started.
-
This issue happens almost only in custom controllers.
Don't you have any pictures of the board and the assembly?
Some displays use 4K7 I2C pullups, others use 10K... will heavily affect the signal integrity at high speeds.
Check the value of those resistors, try 2K2 or 1K.
-
I don't have a picture of a soldered PCB. Both the yellow and green SSD1309 only work with 2.2k. I use an insulated 3W DC / DC converter TRA3-2411 and two voltage regulators AMS1117-3.3V.
One ams1117-3.3 specifically for the SSD1309 power supply. Is it possible that the AMS1117 -3.3 v controller is causing some problems due to excessive current.
-
when looking into the unisolder i was suggested against using yellow ones. well i said i dont know why. so i ended up ordering some anyway (along with white and green, i had blue ones already) but surprise none of the yellow ones worked properly where they white and green ones worked first time. not saying all yellow will have an issue but i know for me in the identical setup pin for pin same brand / seller of the display one worked and the other had weird random issues.
-
If you go DIY, you should also know how to troubleshoot yourself.
Ensure the power is stable under all conditions, check i2c waveforms...
What I won't do is spending my time on guessing what it could be, without knowing for sure the hardware is doing good.
Only when that it's 100% proven OK, I will start to look at my side.
Don't you have schematics for it?
-
Hello everyone, I used STM2F103C8T6 and CKS32F103CBT6 to try v2.1s firmware on the small blue board, and found that STM32 works normally, but CKS32 can't display anything.
Both STM32 and CKS32 burn procedures are normal. I don't know why this happens. I'm not sure if I bought fake CKS32.
Here's a buy link from CKS32.
https://m.tb.cn/h.fJUacUw?sm=a096b7?tk=4LN42i7RNKq (https://m.tb.cn/h.fJUacUw?sm=a096b7?tk=4LN42i7RNKq)
-
The original firmware has a lot of piracy countermeasures, so it probably detects something different.
Those CKS32 solders look suspicious. And this is not KSGER support section!
-
Hi all i am new Thank you david and all for all of your work now running cfw ;D . would any one know if support for the 128x64 2.4 lcd will happen "i asked 5 programmers if they could help with the LCD12864 most run off lol thanks all
-
Several users reported that it's already working on the software side. It's just a matter of picking the right screen and pray they don't send you junk.
That should be the one: https://www.aliexpress.com/item/32950307344.html (https://www.aliexpress.com/item/32950307344.html)
-
It's not LCD, it's OLED
-
i will get one on order thank you. i order the lcd davie ordered https://a.aliexpress.com/_uAbRI3
thank you for your help
-
Didn't arrive yet :palm:...I don't know if the ship/plane was shot down or what!
The implementation looks very easy, if anyone has everything ready for testing, just let me know, I might do dome testing builds.
That means "actively testing", not passing-by every 3 days, it would take forever!
The connection is the same as the 6/7-pin spi OLED (VDD, GND,RST,CS,DC,SCK, SDO).
Given it's a SPI module, only Ksger v1.5, v3 and Quicko can use them.
I don't know if they can be modified for i2c.
-
i ordered from the same shop as you and got here in 2 weeks so seller seems legit. i can test if you Ever need i have 6 pin spi v3 and lcd. i tagged the lcd on to pcb then looked at the code which not my strong point |O thank you for your work
and i don't give up i will |O until it works lol
just in case you do a test is this right thanks
-
First test. Place the extinguisher nearby ;)
Edit: Failed, deleted.
-
how the hell did you do that so fast gutted i can not test this second :( getting very late in the uk and don't want to make a mistake. First thing in the morning will post pictures thank you
and i get free magic smoke jk
update no smoke. just some random line's/grid Patten for 2 seconds then blank. i will test the screen on a Arduino before chasing a rabbit down a hole lol
-
I already had checked the datasheet before buying (Isn't that a logical step?).
The display memory array is exactly the same (8 rows, 128 columns), so the framebuffer/pixel mapping/drawing will work as-is.
For now I disabled the brightness/power/offset commands, that's secondary, the rest is just adjusting the initialization and addressing commands.
So in this case, yes, really that easy, that's why I wanteds to try, these small oleds are not so cheap anymore, and the biger ones cost too much, if these 2.42" LCDs work, it'll be a great alternative.
It's just that not being able to do it by myself makes testing slow and annoying.
Anyways, the LCD can't compete against the OLED in image contrast.
I expect, at best, something like this:
(https://jeelabs.org/2010/11/dsc_2278.jpg)
This just looks too good! (I guess you might get that when placed in the perfect viewing angle)
(https://jeelabs.org/wp-content/uploads/2011/05/dsc_2507.jpg)
-
looks good to me yes. i don't get the price of the big oled.i will check what i have done if not i will send you my lcd
update no smoke. just a blank screen but when power cycling the lcd with stm32 powered then get some random line's/grid Patten for 1 seconds . i will test the screen on a Arduino before chasing a rabbit down a hole lol
update at some point in testing i killed my lm317 new one on order and have to wait nearly a week to turn up
last update tagged a wire on and used bench power supply 3.3v. screen blank i must of messed up will check over pinouts
just found this on the net "works through settings for U8G2_ST7565_ZOLEN_128X64_F_4W_SW_SPI u8g2 but you need to set the contrast u8g2.setContrast (80);""
could this be the problem or missing cs pin but my 7 pin spi screen works without this pin.
ok just checked data sheet i will try tagging a wire on to PA 0-WK UP pin 10 or not that's my wake sense pin :-\ :-//
-
If cs is not used, connect to gnd!
-
thanks just tried pull down still blank.if you pm me your addy i will post it tomorrow. something i have missed .
i have just ordered another LCD st7565 just incase its a dead lcd
-
Are you following this connections? Also: Don't use long wires! Keep them as short as possible, or it'll have noise issues.
I doubt it's dead,unless you connected power backwards!
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1465765)
-
it looks the same. this is what i have thanks
short mmmmm is 120mm short nope and just run out of solder |O
at lest we know what was going on i think David is right noise looks like shit on the scope
-
I also ordered two of these displays for myself (from another seller). But long delivery. Promise in a month (or later).
-
shame no one has this screen so we could do some more testing aswell
shops are shut now will grab some solder tomorrow and use small jumpers and see what we get :)
ok just found a scrap of solder now jumpers are 20mm long but still no joy.
off for a nap then i will get the scope back out :-//
-
I have another display:
-
Don't blame the display yet, a single command can screw everything up, so initializing these things usually require several tries.
Found the cmds in u8g2 to be completely different...
Also lowered the SPI speeds to 140KHz, should work much easier with longer wires, the display will be pretty slow, but this is testing stage!
Edit: v0.2 removed.
-
now flashing
-
just flashed 0.2 still blank and jumpers are 20 mm now thank you for all of your time
update dc=high ,rst=high ,sda and scl are wave forms will have more of a look when i have had a nap
-
Make connectivity tests with the DMM, testing point-to-point connectivity and isolation between lines.
If good, I don't think it's really the connection, also the pin code had no change, just the commands init commands.
Addressing is the same, I missread the datasheet, was using the wrong cmd!
-
now flashing
lcd blank must be a problem my end.
i am shore i just see a flicker or i am going mad. and the bad thing is i only see its one time 3 lines
-
it looks the same. this is what i have thanks
In that picture the power is connected backwards. VDD to GND :palm:! Should go to 3.3V!
Maybe you had a little stroke while drawing? I hope so, otherwise the module might have gone kaput :D
Also the LED is reversed, A(Anode) should take the positive, and K(Cathode) should go to the negative.
At least, you won't kill the backlight. If you don't see any light coming out, reverse -only- the led connection.
I think it was related to how the commands were sent.This controller might be a little more picky, not sure.
More testing!
-
think it mite of been a mini stroke what the hell was i thinking. |O |O |O
i love the art work :-DD
-
Dave you done it there is a faint image on v0.3 :phew:
just looks like contrast is very low or very high and the text/image was flipped left to right ;D
top to bottom is good
:-+
i think i need sleep
-
Did you miss v0.4.1 I posted earlier?
Added a higher contrast build, too.
-
yep i missed it just flashed .4.1 and contrast 80 and don't seem to get any screen
just flashed .3 back and image but fliped
i can try agen with .4.1 in the morning but didnt have any image and flashed .3 faint fliped image
-
I think I finally caught the issue, turn on/off commands were wrong, so that's why you probably had that blink.
Also added additional power-on steps, I think this time will work! (Still might look reversed or flipped).
-
lets get flash :box:
just very quickly span through new .5 still blank but could be something my end will keep checking
.3 test https://youtu.be/s9Zx6hZTxqU
-
Keep comparing it with 0.3 before breaking your head.
I cleaned and reworked the display code, it was prety messy and redudant, now is a lot easier to modify, so you might want to try different initializations sequences.
- Setup the IDE (Easy step, just download and install)
- Download the code in .zip rom github, unpack somewhere
- Run _KSGER_v3.bat to load the profile.
- Open the IDE, import the project at the root of the folder (ignore those inside "board" folder)
- Go to Drivers/graphics/lcd.h
Adjust the first lines as this:
/* Display selection */
#define ST7565
//#define SSD1306
Above those lines you can find the command codes.
- The initialization sequences are at start of Drivers/graphics/lcd.c
// CMD_SIZE, DELAY_MS, CMD_DATA
const uint8_t disp_init[] = { // Initialization for ST7565R
1, 0, c_disp_off,
1, 0, c_bias_7,
1, 0, c_adc_norm,
1, 0, c_com_norm,
1, 0, c_start_line,
1, 50, c_pwr_ctrl | c_pwr_boost,
1, 50, c_pwr_ctrl | c_pwr_boost | c_pwr_vreg,
1, 50, c_pwr_ctrl | c_pwr_boost | c_pwr_follow,
2, 50, c_boost_ratio, c_boost_234,
1, 50, c_res_ratio | 0x07,
2, 0, c_set_volume, 0x16,
1, 0, c_disp_off,
1, 0, c_all_on
};
Follow the project Readme in Github for more details.
-
I have the same board as in the picture. Trying to connect on st-link. Already tried with and without rst, with external power and check st-link on different stm without any problem. I just cant connect to this board
-
@AUTOMOTIVE SOLUTIONS, damn a little more bug. Forgot a small detail about..enabling the final power ::)
That's the slowness caused by not being able to debug the code in real time, waiting for your feedback :-DD
islonina, try the manual method, shorting nRST usign tweezers.
Some ST-Link clones have a bug in the PCB design where that signal is connected wrong.
-
Now i can connect but after chip erase i got error about not accessible elf
-
@DavidAlfa thank you so much and sorry for the slow testing. i have ordered 2 more lcd's one will be here in 3 days would you like a free screen?
i have tested all. 0.3 is the only one so far with a output. have you seen the vid i posted will look so good. thank you so much what you do for the eevblog i take my hat off.
-
Ksger_v3_ST7565R_LCD_v0.6d.bin is the best image starts nice but all 0.6 fade away after 3 seconds ish.
i will install ide and keep on trying
-
Now i can connect but after chip erase i got error about not accessible elf
Please follow the Instructions (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md).
Ksger_v3_ST7565R_LCD_v0.6d.bin is the best image starts nice but all 0.6 fade away after 3 seconds ish.
Well, that's something! Please attach some videos/pictures!
-
Now i can connect but after chip erase i got error about not accessible elf
Please follow the Instructions (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md).
I done this on 2 diffrent board already but never got elf error. I already disabled read protection, now i have empty stm32 with only FFF read on all blocks. On github wiki there is no information about this problem
-
https://youtube.com/shorts/gFzCz5WCVdE?feature=share
sorry just lost power
its looking good
-
What's that elf about? Are you using the .bin file, right?
-
Yes Im using bin file according to my board like on the SS. For what i remember elf file its needed when using extrernal memory but on this firmware there is no external memory that weard. On 2 diffrent board i never get this error.
-
Shouldn't be detected as a STM32F07x, but as STM32F10xx.
Are you sure it's a CKS130F103 like the picture you posted? Might it be one of those weird MM32SPIN27PF?
-
https://youtube.com/shorts/gFzCz5WCVdE?feature=share
I found another possible issue... working on it.
-
nice one i will be on it tonight but can do lots of flashing in-between
-
Its smt32 not magickmedia or other clone. Now i replace for whole new cpu and still have this problem with elf
-
@islonina where did you get your stm32 from think stm link utility is saying you have the wrong chip
my one saying this
Device ID:0x410
Device flash Size : 64KBytes
Device family :STM32F10xx Medium-densi
-
Farnell or mouser or other store not ali or alibaba
-
my chip was from china stm32f103
-
are you using a st-link because changing fw on the st-link use to be a problem sorry just brain storming
probably not think it use to say invalid chip id
tested on stm32f103
https://www.ebay.co.uk/itm/203914595377?hash=item2f7a41cc31:g:wC4AAOSwjthiWZP7 (https://www.ebay.co.uk/itm/203914595377?hash=item2f7a41cc31:g:wC4AAOSwjthiWZP7)
-
This board works fine for over a year-last board with OFW. Now its time to change that. So i was trying to flash like every other board i have. Ind in the middle of flashing after erasing i got elf error. Now after a day of troubleshooting i just replace for the new stm32 and flash firmware again and all works fine now.
-
nice one glad you got it sorted
-
@DavidAlfa i have to pop to work soon. i will be back at 10:30 uk then its ide time :box: |O
-
Original firmware seems to use only Cortex-M0 instructions, it's the only logical explanation of why it works with these MM32SPIN.
I guess yours was a relabeled stm32!
Edit:
I spent hours fighting weird graphical artifacts, at the end it was caused by the newer u8g2 version I updated yesterday, I was just moving air! :palm:
New test!
-
i am on it just having a little problem
update just black screen on all firmware's .all i done is go to work and come back now no output now this must be problem my end
update update its like it was neva working and i have changed nothing apart from making some esd when i was out
i am starting to think the lcd has sh*t it's self i can't rule it out. new screen here 22/4
i know it don't sound right i have checked all connections with dmm and there all good.it was not even moved all i done is shut laptop down then come back flashed the two .7's nothing so went back to .6 and then 3 and nothing.not even geting lines on the screen when powering down like before
-
Wait, in last fw it was just black instead white, like when it didn't work at all?
Might be too high contrast.
-
but versions .3 or .6 have stopped working as well .just like its not even got power to cog just backlight. i am really starting to think esd i know unlikely
i will just quickly check on scope
vcc cleen
we have a clock and data |O
i am running out of ideas any one lol feeling a bit special needs
-
More tomorrow! Kinda late here.
Ensure the stm32 is working... Sometimes weird things happen, make a full erase, try again with 0.3...
Check voltage at both sides of R4, on any doubts replace with a solder jumper.
Also, you can connect A/K directly to power, there's already a resistor for the led, R7 in the corner.
It seems J1 joins K to gnd (One wire less to worry about).
Resolder C1-C9 to remove any posibility of a dry joint.
Finally, be extremely careful with the bottom corners, the glass there is very thin, will break with just a mean look!
-
lol r4 missed that one .i am with you must be stm being a ass ok sorry to slow progress. i will test with oled
just erased and .3 still nothing .
yep will check all caps and like the jumper i will get on that and spinning up a pcb layout for a adaptor
r4 good
-
Photos for Rixi.
I couldn't figure out how to attach photos in private messages. So I'll put it here.
-
New test. This one is a bit different, refer to the text file!
-
mite have a bad stm32 no flashing led
just check boot0 good blanked chip and read blank flashed v3 and read all ok installed original oled nothing. dmm all good not scoped yet but realy looking like we have a dead stm32 and no spares :(
-
The led will only flash with the 24V supply on, as it's fed from there! Just remember *don't* connect the handle.
-
i will try but not looking good just updated post ^ :(
its not having any of it 24v psu no led
-
i will try but not looking good just updated post ^ :(
its not having any if it 24v psu no led
update r3 was open on the voltage regulator. voltage selection resistor must of been intermittent because every time i checked voltage rule one was at 3.3v now 7.4v :wtf:
just out of interest put 200 ohm in and we have 3.3v.will look tomorrow but think that's the end of the stm ect
-
Ouch... that sucks! Still you were lucky to not get full 24V!
What board is it? Do you have pictures?
I know simulation doesn't reflect real life, but that's all I have, here it works...
Proteus has SED1565 displays, that controller seems to be identical to the ST7565.
-
i have found a black pill here STM32F411 could i continue testing ?
-
I tried stm32F303 - didn't work. David said that it's a completely different chip.
-
thank you will have to wait for new stm32f103 just really slowing things down
-
And I'm waiting for the displays. They are still in China. (by track number)
There are controllers for experiments. 2 pieces. No displays :(
-
that's not good i just payed £16 for the lcd in the uk one form china £4. need to get a new stm32 fast lets see how much this will be lol
what version pcb did you get
should get it by 26 Apr. :(
-
OMG how is that? £16 for that cheap LCD?
Why not get a 2.4" OLED then, it costs the same!
There's no hurry -at least for me- , so do whatever you consider right. China option might be ok!
Nope, I don't think I'm spending more time with different mcus, just wait until your stm32 or my display arrives :-+
-
:-// i know i did think getting oled but would like to finish what we started and don't like to be beating. stm32 on order just £10 Bargain here 26th :-DD
i don't blame you not doing anymore mcu support lol
i am going to start on a pcb with supports for this lcd but before i start reinventing the wheel do you know of any open source pcb layout or should i just start from scratch thanks
-
Hello everyone, I made a board of V3.1s, but after I finished welding and burned the firmware, it was stuck in the boot logo.
Does anyone know the reason?Schematic diagrams and HEX files follow.thank you
-
has anyone got the lcd screens working yet? i was debating on ordering a few
-
I don't have screen, people with screen have smokey stm32s... :-DD
Goes stand-by until the situation changes!
I turns out color and monchrome lcds have a subtle but critical difference when sending commands.
ST7565/SSD1306, etc, need the command arguments to be sent with DC=0, like any other command.
But color LCDs (ST7789, ST7735...) require the cmd with DC=0, then the arguments with DC=1.
Probably I've have mixed both at some point, not really sure.
Improved the code, should be working now unless some command is wrong, and if it doesn't, must be really close.
So I leave there a Ksger v3 ST7565 test build (https://github.com/deividAlfa/stm32_soldering_iron_controller/raw/master/BOARDS/KSGER/%5Bv3%5D/STM32F101/STM32SolderingStation_ST7565_test.bin) for anyone. If tested, please give feedback!
Contrast should be adjustable in the same menu entry.
Dimming options are removed, as the contrast will turn the display darker or lighter, not brighter or dimmer.
-
ill have to order in a few to try out. ill see how fast i can get a few here. is there one color you recc over the others normally?
-
Check yourself, but personally, the one with white pixels over black background seems the best, gives that oled high-contrast look.
Haven't seen any myself, so the image quality could be crap and the pictures fake or too optimistic.
-
stm32 david :clap: :phew:
0.7.1 working stable clean flipped image
0.7.0 working stable clean flipped image "best looking"
0.8 tries to initiate get a line for 1 second then blank
will post pics very soon
and i mean a clean image looks so good
-
Very positive news! Fine! :-+
-
stm32 david :clap: :phew:
Nice! Also test:
Improved the code, should be working now unless some command is wrong, and if it doesn't, must be really close.
So I leave there a Ksger v3 ST7565 test build (https://github.com/deividAlfa/stm32_soldering_iron_controller/raw/master/BOARDS/KSGER/%5Bv3%5D/STM32F101/STM32SolderingStation_ST7565_test.bin) for anyone. If tested, please give feedback!
Contrast should be adjustable in the same menu entry.
Dimming options are removed, as the contrast will turn the display darker or lighter, not brighter or dimmer.
-
test build we have no output
david i still have this screen here for you. i can not use 2 screens
got work will be back in 2 hours
-
Have anyone seen this Station disasasebled it looks like 2 Boards in one Housing
https://de.aliexpress.com/item/1005004176816101.html?spm=a2g0o.detail.1000060.1.164026a3LhAGVO&gps-id=pcDetailBottomMoreThisSeller&scm=1007.13339.274681.0&scm_id=1007.13339.274681.0&scm-url=1007.13339.274681.0&pvid=4f4ba5e7-387a-4636-b225-5e54216f67b9&_t=gps-id%3ApcDetailBottomMoreThisSeller%2Cscm-url%3A1007.13339.274681.0%2Cpvid%3A4f4ba5e7-387a-4636-b225-5e54216f67b9%2Ctpp_buckets%3A668%232846%238107%231934&pdp_ext_f=%7B%22sku_id%22%3A%2212000028292146020%22%2C%22sceneId%22%3A%223339%22%7D&pdp_npi=1%40dis%7CEUR%7C%7C48.94%7C%7C%7C%7C%7C%400b0a23aa16510037217614323e1aba%7C12000028292146020%7Crec&gatewayAdapt=glo2deu
-
test build we have no output
What about this ones?
Now I'm, saving the lcd file too, I can't remember everything I did for every test!
-
0.1 upside down contrast bad /have to look at a extrema angle
0.2 upside down contrast bad /have to look at a extrema angle
-
0.1 upside down contrast bad /have to look at a extrema angle
0.2 upside down contrast bad /have to look at a extrema angle
0.3 was first time readable but a bit faint
0.7 best image bright
-
Yeah, now go into system settings and adjust contrast
But do they look the same?
Also: always make a full chip erase when testing different versions. The default settings might stay otherwise.
-
Translation request
To address any display orientation issues, specially with these DIY designs, I added new display options and moved them to a new screen for better organization:
The new entries needing translation are "DISPLAY", "X flip", "Y flip", "Ratio".
"Ratio" means "Voltage regulator ratio".
SYSTEM |-> etc
|-> RESET MENU
|-> DISPLAY |-> Contrast
|-> Offset
|-> X flip
|-> Y flip
|-> Ratio (Enabled only when using ST7565 display)
|-> Dimmer
|-> Delay
|-> In sleep
Attached v0.03, this version can tweak all display settings from the menu.
If it shows anything, even weak or washed out, that's ok, go into MENU/SYSTEM/DISPLAY and try different settings.
- Adjust contrast. You might also need to adjust Ratio, not sure if they're correlated.
- Adjust X and Y flip until the image orientation is correct.
- Adjust Offset until the image is centered.
I also made additional profiles for Ksger v1.5 & v3 and Quicko, for SSD1396 and ST7565 displays.
When it's finally working, report your settings and they'll be ready!
-
we have a faint image on 18 and 500.i will fit the encoder now
now in a dark room trying
i do have eye stain but
contrast 40
-
we have a faint image on 18 and 500.i will fit the encoder now
now in a dark room trying
just resting eyes a second eye strain really so faint
update got it
contrast 40
offset 0
x flip on
y flip off
ratio 5
contrast 38 best
after 1 min screen go's black but if you change contrast by 1 starts working
powering off and on will not bring it back you have to change contrast by 1 and back working
powering off and on with display working go's back black change by 1 and back working
contrast 25
offset 0
x flip on
y flip off
ratio 6
could this be a problem my end should i test on the other screen?
-
We're getting there :)
After 1 min? hmm strange. Let me check if I didn't disable all power-saving functions used for oled screen.
I updated the build script. Couldn't be easier now! Just install CubeIDE, download the code in ZIP from Github, extract it anywhere and run "Building_script.bat"
-
thank you that's a nice layout. you are starting to make it to easy.
on the old v.03.bin lcd screen go's corrupted in about the same time then black
is this problem my end ?
i will install ide tonight and have a play=press any button stab any key it's all a lottery
jk
-
Unless you modify the code, compiling yourself won't change anything, as you'll get the same result.
I the code that makes the soft-start code was still enabled.
But all it makes is a contrast increasing ramp from 0 to the defined value for about 1 second, then nothing else touched the contrast or the power except the display controls.
I disabled that part. Yet, it's strange that it dies after a minute, these things either work, or not. That's weird!
Keep testing the settings!
Pushed the latest code to github.
-
dam was hoping was like Arduino ide |O
-
Do you think this firmware can coded in 4 arduino lines?
magic.create(soldering firmware)
display.begin()
menu.show()
do.workmagic():-DD
-
ammmmmm no lol
screen starts well just flipped stm32 logo then shows ion for 1 second then screen corrupted for 1 second then black
and sorry for delay lifted a track :-DD
i am starting to feel sorry for a pcb its been throw so much just need to hang on in there just a bit longer :-DD
-
You must fix everything in the way you can handle it without wires breaking every 5 minutes, ex. mounting everything and only handling the programmer USB connection.
Otherwise it's adding more possible sources of trouble!
I've had such display issues when I reverse engineered the board, removing almost everything.
Any damaged track will make the display randomly go nuts!
-
One question.
Why are buying so many people the KSGER version of the T12 soldering station and not the Quicko Version, which has a much better build quality?
Even the Youtube videos are mostly about the KSGER version.
-
track is fixed and i glued in to the bench lol it was like i was one step ahead :box:
Ksger_v3_ST7565R_test_v0.03_18MHz
contrast 10
offset 0
x flip on
y flip off
ratio 7
stays working with this settings until you restart then have to go to contrast and adjust and its back
ok as i was typing it went black
last update the original 0.3 stays on screen stays good mmmmm
ok went out come back and black screen
-
Keep testing the 1mhz version?
-
SYSTEM |-> etc
|-> RESET MENU
|-> DISPLAY |-> Offset
|-> X flip
|-> Y flip
|-> Ratio (Enabled only when using ST7565 display)
|-> Dimmer
|-> Delay
|-> In sleep
SYSTEM |-> etc
|-> RESET MENU
|-> ЭКРАН |-> Сдвиг
|-> X Зерк.
|-> Y Зерк.
|-> Усиление
|-> Затемнение
|-> Задержка
|-> Реж.Экрана
anyway i still see no photos of progress with those displays here. is it worth ?
-
One question.
Why are buying so many people the KSGER version of the T12 soldering station and not the Quicko Version, which has a much better build quality?
Even the Youtube videos are mostly about the KSGER version.
there is board design that is same for both ksger and quicko. v2.1S with cutoff sides. anyway it uses i2c screen, it has some limits. i would suggest buying ane version with spi display
-
do you mean KSGER_v3_ST7565_CurrentRevision_1MHz\STM32SolderingStation.bin this boots then icon then screen corrupted then black in about 3 seconds.
keeps working longer in first setup menu but end's up crashing
if you think its my end then can test the other lcd screen if you like. i can pop the stm32 off and put in on a blue pill pcb and just have a screen and encoder connected ?
-
Aren't the LCD settings being saved after a power cycle?
I mean, if you set contrast 40, isn't being stored on reboot
Yes, you can use a bluepill, follow the Ksger schematic to connect the LCD.
They're exactly the same, just the spi works at a slower speed. It's very strange that the slower performs worse!
Wickated, of course, I already wanted to make a display menu since long time ago, also screen mirroring feature has been asked several times. So that's it.
The display is the less important part of the station.
I2c..spi...meh, not critical, take the one with best power regulation, less signal noise, best stability.
What I really want are accurate temperature readings, not 5000fps LCD :)
So yeah I'd go with the older quickos.
Newer 956 and 958 seems good too, or at least nobody complained
-
on Ksger_v3_ST7565R_test_v0.03_18MHz it keeps settings but have to adjust by 1 then it working reboot back not working adjust by 1 then working
its like it initializing the lcd when changing contrast if you get me even though is a faint screen to start with
i have to pop to work soon when i am back i will redo all connections
i am back will give it a go
update i had to try. swap lcd just because what it been through ie 8v. same just jumps in to life if you change contrast just 1 up then 1 down and staying working on and off same back to having to change by 1 back working and contrast setting are saving.
tell me to piss off but is there any test scripts like you get in arduino or a sketch from a stm32 project with the same screen ? just before lifting stm
-
Hi!
DavidAlfa thanks for this alternative fw for the stations!
I have started modifying the code a bit. Okay, maybe a lot. And I also started re-structuring the project and how the build is done.
I think some of the features I have added could be merged back to your repository after I update all the targets and finish a few more todos (like translations).
In the master branch of my fork (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/master (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/master)) I have added/fixed:
- Select the last added/copied tip automatically.
- Re-layout the settings storage, so the areas can be updated independently (changingthe layout of one area does not affect the others). This will also make automatical layout upgrades possible in the future.
- Apply temp restrictions on the current set temp if the user changes it in the settings (min max temp)
- Make the "iron.c/h" follow the c stucture object pattern. This resulted in a slightly smaller flash footprint. I have done this while I was understanding how it worked. It was in a middle state where some variables were accessed via getters and setters while some were accessed directly. Now its all getters and setters. This way its possible to intercept (debug/reject/overwrite) any call.
- Removed a few unused code parts, files.
- Separated the main.c/h into the generated parts + hooks and the user written one. This way its much easier to update those files.
- Moved some duplicated code to separate functions.
- Moved some code parts to different places because it was not related to the main purpose of the file.
- Added support for the backup memory: if a battery is present then the last selected profile and tip is stored there instead of writing the flash on every change. And also added the ability to save the last used temperature there. If no battery is present (compiler switch) then it behaves much like it did previously, except its possible to make it only affect the current power cycle -> on the next boot it defaults back to the stored one. The behavior is user selectable in the menu.
- Added an addons screen where people can add other functions.
- Addon for controlling a fume extractor.
- Addon which reminds (beeps at) the user to turn off the station if left in standby mode longer than the set amount of time.
Then I noticed that to port these changes to all the targets a lot of eclipse (stm32cube ide is eclipse based) projects need to be edited manually. And I'm a software engineer and spend a lot of time using (and developing plugins for) eclipse. So I restructured the whole project. Its not 100% done yet, as it is missing the automatic generation of the code from the ioc files (I have not looked into it at all how those are generated, currently it uses the stock method), but once those are generated there is no need for any silly batch file or similar. In eclipse you can just click build all then it builds the project for all targets. No need to copy paste stuff, there are no generated conflicting common files, etc. Each resulting artifact encodes the target name too, no more confusing "STM32SolderingStation.bin" / etc. As I said its not 100% done, as I have not yet added the pre-build step to generate the sources from the IOC files. I only spent today evening on this restructuring.
This can be found on the updateProjectStructure branch of my fork: https://github.com/KocsisV/stm32_soldering_iron_controller/tree/updateProjectStructure (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/updateProjectStructure) . I also removed the LFS because that is not fully supported on github if you don't have a subscription. It was only storing a 32kb pdf anyways.
To try this out: create a new eclipse workspace (file, switch workspace), then go to "window", "show view", "c/c++ projects" (maybe its in the "Other..." menu if you have never used this view). Then in the "c/c++ projects" window (it looks exactly the same as the "Project explorer") right click, "Import...", "General", "Existing Projects into Workspace", select the git repository as the "root directory", down in the options section tick (enable) the "Search for nested projects" and import all of them. You will see one project for each target (these are only used as a workaround due to the inability for the stm32cube plugin to use custom outputs for code generation). As you normally do generate code from the IOC files. Now right click on the STM32SolderingStation project and you can switch between the targets in the "Build configuration" menu. Or on the drop down triangle besides the build icon (hammer) in the upper toolbar (but you have to have the project active, aka click on it or any file within it in the c/c++ projects window, else it shows build targets for the other active project). If you build multiple targets and don't delete the other resulting artifacts for other targets (it will show up as a folder in the project), then the build analizer (which shows the ram/flash usage) won't work. But besides this everything else is fully functional. Keep in mind when you edit the build targets select the appropriate target or if it applies to all select "all configurations". There is no need to edit all the targets for eg adding a new source folder/include folder.
What's on my todo list (this is not an ordered list, and its not guaranteed that I will do any/all of these :) ) :
- Separate the settings screen source files to multiple ones, as it contains 3 (or more?) screens
- Add the source generation from the IOC files.
- Move the common files from the hardware targets (linker + startup script) into a separate "target MCU" folder, and make eclipse handle the rest based on the target CPU define.
- Move / generate the resources (languages, images).
- Make a better menu layout :) This "settings" and "iron" is confusing a bit. I rather have a "global preferences", "profile preferences", "profile hardware config" layout or similar.
- Add option for multiple temperature sensors: there is one built in into the MCU, add one for the cold junction and plus the one currently onboard the pcb.
- Add an option to backup/export the settings, maybe a small tool which parses back the binary file then exports it as an XML or something. And the other way around so human readable -> binary.
- Add bootloader support on F103 (via the USB port)
- Add option to rename profiles.
- Move all default settings to a separate file (the constants), because now they are all over the place.
- Instead of using the git repository to store the release binaries, use the releases option in github. Using git to store the binaries just makes the git history huge (which it is now already).
- Add a method for a better "iron in the stand detection" feature, using an IR led + photodiode, so it will work with any shape stand + handpiece.
- Add some kind of auto PID tuning.
- Fix the readme to use relative links, and update it for the newer project structure.
I only started working on this for the fume extractor thing, but I got a bit carried away.
-
sorry KocsisV nice work.
david this screen when you set the contrast it stays good (more than 5 min's its still working)until restart
15 min still working do i leave it running and see if it blacks out ? or pull stm32 off and pop it on the blue pill?
I am watching a flashing logo (X) for about 25 min now i think lcd not going blank/black
30 min's still working. i would say screen dose not cut out anymore was it a damaged cog on the old lcd mmmmmmmm :) :phew: 1 problem down next
and tested KSGER_v3_ST7565_CurrentRevision_1MHz =42,0,on,off and fully working even after restart. :-+ you have cracked it.will post pics tomorrow need sleep
looks really good in person
-
KcsisV, that's a lot of work, great to see someone contributing. I have a lot to review!
Just some thoughts:
- Before doing so much work at your own, it might be a good idea to talk, it's not the first time I'm developing something, not published yet into git, and someone makes a PR for the same stuff!
Also, there's some code you might think it's dirty or redundant, and while it might be true in some cases, others are actually small patches to address very specific issues that took a lot of effort to catch.
I've tried to comment the code in the best way, otherwise I would forget myself how it worked! But not everything is properly described, so be careful when optimizing.
- Not sure about the separate main. The current main had very few lines of code, and didn't cause any issues. You still need a custom main to call the second one. To me, that's just overcomplicate things.
- I don't think IRON and SYSTEM are confusing, it's been clearly stated that IRON stores settings that are unique and private for each profile, while SYSTEM stores global settings applied at all times.
- The temperature was saved long time ago, later removed to reduce flash wear, actually you'll use the same temps for 99% of the time, ex. 350ºC. That was a real Flash punisher :D
- I don't understand what you did here (https://github.com/KocsisV/stm32_soldering_iron_controller/commit/4a45a9e2a36769340e5d7f97fc93dd3216c2f3f9)?
The used tip is currently saved in the profile itself. Each profile has it's own currentTIP. Then the current selected profile is saved in systemSettings.
But now you're saving it globally to systemsettings.currentTIP, so if last T12 tip was "2" and you load C210, it will also load "2" ?.
Anyways the profile type is a rarely changed setting, not nearly as often as the temperature does, so I don't think the "save last tip" option is necessary?
But if saving to the external eeprom, then save currentTips for all profiles, not just current one.
- I *want* to preserve CubeMX code generation instead manually copying the HAL. Why? Because it's exactly that, a HAL, constantly being enhanced and fixed.
Thus, that way I can always generate the latest fresh HAL. When a new one appears, all I need is to press "Migrate". If I hardcode it, updating the HAL will need to be done manually. More work!
- I'm not a big fan of hardware mods because interfacing new functions will usually require soldering to the small stm32 pins, which is not a thing for the 90% of the users.
Sure, you can add anything, but please also add detailed instructions / explanations in the docs, I don't want to start answering questions every 5 minutes :D
- Yes, some screens are embeded in other files, because they're very small and sub-screens of the main one, also because it recycles several common variables.
Otherwise, most screens use separate files.
- It's all nice to improve, it also keep in mind that I'm not going to debug your work, so take all the time you need to ensure everything works correctly.
- Yes, I know I should make releases, however, the few times I did, there were few firmware bugs, causing even further confusion between users on which to use, needing to explain everythig.
So I just removed them, adding the latest binary instead. Doesn't work? Just use the latest version. I don't want to keep track of every single release!
- Picture generation etc? I have no idea. Given there're just a few images, I simply converted them manually. Converting them to XBM and copying the contents is nothing complicated.
Of course if I had hundreds of pictures, it would be a heavy task.
- The best storing solution would be a FRAM (https://www.aliexpress.com/item/1005003084184197.html), no wear issues!
- I though many times on adding usb OTG to export/restore the settings, wouldn't be hard. Again, it requires hw modifying, but also more RAM usage, which would be impossible for STM32F101 devices, they have only ~250 bytes left.
- Ensure to check latest code, there were several changes lately... there's a new batch building script, much easier to handle.
Yes, it might still not that good as fully integrated project, but works, let's you build any or all profiles with a single keypress, not requiring to setup the ide, it finds and invoques everything by itself, making it *much* easier for people not used with this things.
I just hate when someone publishes a project that requires a lot of intermediate steps, setting up the toolchain, dependencies, importing... 95% of the time there'll be issues before you can build anything! So I don't want that pain for anyone if it's not specifically required.
Whenever I want to build new firmware, I simply open _Building_script-> Build all. Three minutes later, I open git and upload the new binaries that were automatically placed in their folders. That's all the work it takes, and I don't want it to be more complicated!
looks really good in person
Is everything working with that screen? Is contrast, etc, being saved and restored correctly on boot?
Never corrupting/glitching? Sure, if 9V went into it, cannot trust it anymore!
Keep trying that one and ensure nothing breaks down.
Are these your definitive settings? 42,0,on,off ...
You forgot thet resistor ratio! What are the effect of adjusting it?
-
contrast work boot working and can not get it to crash/glitch
last settings 34,0,on.off,5
ratio 6 over contrast white screen
ratio 4 nearly blank screen
i really stating to think it just working will keep pressing buttons but looking good still
(when i get time try the old screen) but 90% faulty
thank you david for all your hard work.
one question if you don't mind what schematic/pinouts should i base my pcb on staying with stm32f103 thanks andy
-
When changing resistor ratio causing it going blank, does it come back to life when restoring the value without requiring rebooting?
Well, that was a sneaky one, most ST7565 code used 6 or 7 ratio, it was just in latter tests where I changed it to 5 by default.
Does the contrast work as expected, increasing/decreasing the contrast in fine steps?
You can use any STM32F101/102/103, take the cheapest one, 36 or 72MHz isn't really critical here.
You could build a Ksger v3.1, but with decent routing, two-stage voltage regulation (24v->5V buck converter, 5V->3.3V LDO), proper ground planes, adding decoupling capacitors to every VDD pin, also filtering analog supplies (VDDA+op-amp) with a small chokes+more capacitors.
-
screen comes back as you adjust so no black outs anymore or needing reboot i have not managed to find 1 bug.
contrast is a nice smooth control like my tv
thank you was just going to spin some pcb's up. i like the idea buck and ldo it is a lot of stress for a ldo.
let the games begin.
thank you for all you do for eev its very appreciated
-
How interesting are you. :)
And I'm still waiting for a parcel with displays. :(
And today I made brackets for my soldering station so that it can be fixed above the desktop on a shelf. It won't take up space on the table.
-
thank you interesting most people say :-BROKE
david is the man i just brake stuff lol
that looks good in a case like the idea less bench space. i have a case on its way ie getting made and starting on pcb's
just a piss take not finished
update: really can not find any bugs
-
there's some code you might think it's dirty or redundant
Don't worry, this isn't the first thing I work on. I can differentiate between a workaround/corner case handling and actual duplicated/unnecessary code. :)
I've tried to comment the code
Yea, about that... I don't want to offend you but this code seems exactly like its coming from a one man army. Not much comment, lot of cross referencing, tightly coupled parts, not much logical separation inside the components either, and generally a "patchwork" code. Don't take this as a negative comment because well, you are working on this alone. And that results in this kind of code 99% of the time. Because you know your own work, you fail to see what's wrong with it from a different prespective. I have done this too, not once, not twice.
I don't really plan to organize/separate things much because I don't want to spend a lot of time on this project alone, but I will do a small amount of it. Eg doxygen comment the parts I touch, refactor the names of the functions to reflect where it comes from, separate constants, etc.
To me, that's just overcomplicate things.
It makes it cleaner overall. Common part are in a common file, target specific/generated ones are in another. The best would be to not even have a main.c/h with mixed manual and generated code. I have not deep dived into how the CubeMX templates work, but this hardcoded project structure is not great. Not the structure itself, but the "hardcoded" part.
For both adding the addons and the backup ram init I had to touch the main.c/h, and after code generation it would have been a mess in the git history if I commit the generated parts.
IRON and SYSTEM are confusing
It is in a way that its just a list of all settings, no logical separation between hardware configuration and user preferences. Eg adc/pwm timings, ntc settings, etc are in the same menu as max temperature. The first is a hardware config which ideally should be left at default (if one does not want to debug why it's not doing what it's expected), while the user is free to change the second. If you put these in the same menu then one can assume that its there to mess with it just like a max temperature setting.
don't understand what you did here?
The current tip/profile(/temp) setting stored in the flash become the default tip. It is applied on boot as the current tip (just like how it was done previously). If there is a battery present and the "remember last tip" option is enabled (and the backup mem actually contains the data), then it (the current tip variable) is overwritten by the backup memory on startup.
In the periodic background flash saving task:
- if the remember tip is ON and there is no backup battery -> default tip updated -> works just like before my modification
- if the remember tip is ON and there is a battery present -> last tip is stored in the backup memory -> no flash wear
- if the remember tip is OFF then the default tip setting is not updated
It's true the tip/profile is not changed often, but I see no downside to having an option to disable some behavior.
If you look a few commits further, you will see that I made it (tip selection) profile specific.
The profile/tip saving was just a side effect of the backup ram thing, why not reduce the flash wear if there is a way to do it without removing any previous features? And the current code is not using a "flash friendly" filesystem (eg some kind of copy on write fs), and who knows how durable the clone STMs will be in the future. I worked with 5k euro MCUs which had a guaranteed 100 erase cycles for their program memory. Yes, 100. There is a reason why a few hardware revisions include an eeprom. If they can spend 0,0001$ less by omitting the eeprom they would do it in a heartbeat to gain extra profit.
That was a real Flash punisher
With a proper c.o.w. filesystem it would not be. If the block size/dataset layout is properly setup then only the changed seciton is written every time (in case the temp this could would mean only a few bytes), no need to erase until the given page is full. But introducing a c.o.w. filesystem is in itself about that much code as the whole project is currently.
instead manually copying the HAL.
Good thing then that I'm not doing any manual copying :) The projects reference to each other. When you switch targets then that changes which project supplies a specific set of files. Updating the HAL/CubeMX code generation happens exactly the same as before. Only difference is that now you don't have to copy paste the project (or any) files at all, nor close/reopen anything. All contained within one single project and its subprojects.
I could even get rid of the separate main.h/.c via a pre-build step too and have one common just as before (which then gets copied to the target mcu's project in a pre-build step automatically, then CubeMX generating the code into it).
I would really like to get rid of these bat files. They don't really work on linux :)
hardware mods
This is why these addons are disabled by default. They won't show up in the menu, won't get compiled into the binary. I updated the operating instructions already :)
In theory the switch off reminder could be always enabled, as that does not require any hw mod.
because they're very small and sub-screens of the main one
See my previous comment about the one man army and code structuring/documentation :)
Either have all in one file, or have all separate. Don't mix and match.
I'm not going to debug your work
Hopefully you won't need to :)
I don't want to keep track of every single release!
That's not the point. If in the future a dataset migration is implemented (so the user don't have to re-calibrate 60 tips each time the layout changes), then versioned releases is a must. Then you can say "ok, version X supports automatic migration from Y and Z, upgrading from other versions wipes all data!".
This does not excludes having development builds. I already wrote a small tool for myself to migrate between the flash layouts, because I did not want to re-calibrate or re-enter 15 tips.
Picture generation etc?
The focus is not only picture generation, but "generation". Eg.: I rather write the translations in a domain specific language, than having to edit the source code and know exactly which define to update when a new one is added, etc. Let eclipse generate the source files and the required configuration from it.
usb OTG to export/restore
USB would be complicated in my opinion. I was thinking about dumping it out via UART or the SWD debugger console, as either one or both are already wired out on the PCB. Then a script to convert them to layout X. But this not only needs this feature to work, but a properly described dataset layout, not just a struct in the c code.
STM32F101 devices, they have only ~250 bytes left
That's plenty for this feature. :)
Btw, what consumes this much heap? I have not looked into how the GUI works, but all I saw was the 20 byte windows and similar smaller objects in the BSS area, then 5k heap. I planned to print out what's the max heap usage, but for some reason debugging does not work properly... I even have a genuine J-Link Plus with all the required licenses but somewhere something is misconfigured. The controller does not stop at the breakpoints, but the J-Link dumps the RAM when one is hit so I can see the details, just not step in the code. It is literally the first time I used the j-link plus since I got it like 2 years ago.
Does splitting the menus to smaller sub-menus bring down the heap usage?
-
Well, I'm not a software engineer. Learned C, stm32 and all that by myself.
There must be some differences when comparing amateur vs everyday professional work!
And if course, this is not paid up software, but done in my free time to the extend I consider enough.
The screens need a lot of heap. Each widget is about 60-96bytes, although I made a lot of work to reduce the footprint.
So when you load a big screen, keep suming widgets, easily 3K.
+ When saving the Flash, it needs to store the 2K block before erasing and rewriting.
That's why automatic saving is disabled when certain screens are active.
+ Current profile settings
+ system settings
+ Screen buffer
+ ADC measure data
Everything sums ups really quickly!
You can always check the build report, showing where the ram usage goes.
Check the defines in main.h for debugging the heap usage! You can run the code, adding the heap usage variables to the watch window, checking the usage on any screen, also the absolute max heap usage. It's hard to keep track of everything, normally heap is handled by a OS and not heavily constrained like in a small embedded mcu.
But without the heap, all those screens would be impossible.
And the widget system is really useful and dynamic, provides a lot more flexibility, I don't feel like removing it.
You've seen yourself how easy is to setup a new screen!
For sure it could be optimized more, but I'm done, you can't imagine how much time I spent on it.
Actually splitting the screens in smaller sub-screens would be beneficial.
I had nightmwares when implementing the dynamic screen loading. It turns out syscalls.c was missing, no error generated at all, and there was no control on heap usage, I could allocate 3GB no problem! So heap and stack would collide and cause all kind of strange issues.
Why does X change to -2848583 when I write to Y? Oh man, I spent a lot of time until I found the root of the problem :-DD
Like I say all contribution is welcome, all I demand is to be responsible of your own work :)
-
it needs to store the 2K block before erasing and rewriting
I was considering a solution for that. Could be reduced to 0 bytes on the heap (still needs a few bytes on stack, but not much more), but it needs +1k of flash allocated as a rotating data storage and a lot of effort to code it :) . Since the heap is allocated anyway it does not matter.
check the build report
I know about that, not checked it in details yet. BSS usage seems reasonable, stack is stack, then there is the 5k of heap which the static analyzer can't say anything about. i saw the debug defines too, but as I said something is misconfigured and I have not yet spent the time to debug why debugging isn't working. It does not stop at the breakpoint, but it sometimes grabs a few tens of bytes from the top of the stack when it's reached but that's about it.
how easy is to setup a new screen
I like the widget system, its great. If someone only needs what's already implemented and is ok with the default behavior then its super fast to use and intuitive. At first I was expecting something hard to use, requiring me to manually call rendering for text, scheduling ui handling calls and similar but its not the case.
heap and stack would collide
One solution for avoiding this is to define the stack so it grows toward an address range which causes an exception. Same goes to the heap. Eg one at the beginning of the RAM address range and one at the end, other sections in the middle. So it will raise an invalid memory address exception (if this MCU has it, and can enter the exception handler without stack) rather than silently corrupting the other. Easier to place a breakpoint to the exception handler, than to track down what wrote where. And to monitor both, at boot both need to be filled with a known pattern and in an interrupt check where the pattern ends / was overwritten. From that the runtime the max stack and heap use can be monitored. Not just the allocated/reported one, but the unintended writing too. If one counter says that the max was X but the pattern only starts at X + 2 then something wrote a byte in unallocated space. This is a common strategy in safety critical systems. Even when an MPU/MMU is present.
-
Why not store the temperature or other dynamic settings that may cause ware on the flash separately in the eeprom :-//
-
Not all boards have an eeprom, nor all have a battery for the rtc (backup ram).
-
KocsisV, I debugged a moment while having breakfast. Heap debugging still works great!
- The "fixed" ram is ~4KB. Screens, buffers, different settings/structures...
- Then, the reserved heap is actually a lot larger than required, it peaked at about 2.1KB.
The options were very constrained at the beginning of development, as the original screen management wasn't dynamic.
I had to sacrifice lots of features until I later made the dynamic loading, while 10KB devices were still having issues with random stuff changing by divine intervention :-DD.
I repeat, the heap issue I mentioned was caused by "syscalls.c" and "sysmem.c" files missing.
Lost a lot of hair until I analyzed the disassembly code and I noticed _sbrk() was returning always a valid pointer, and quickly figured out the issue.
After more optimizations (Which were a lot!) widget space was reduced, then saving was allowed only in boot, main, settings, calibration and reset_confirmation screens, which use at most 356 bytes, keeping the stack under 2KB, almost halving the previous usage.
But to be safe, I allocated all the free ram to it, it doesn't hurt, that ram would be left unused anyways.
In any case, the system allocates all ram at boot to prevent heap fragmentation.
The widgets design is also dynamic, glueing different elements using pointers.
- Screen (52 bytes). The only not dynamically-allocated part of the gui system.
- Points to the next screen, first widget, current widget, customized handling functions...
-Main "widget_t" (28bytes)
- "Content" linked to the widget type. Ex. in the system menu, it's linked to a comboBox_widget_t.
- "next_widget" points for the next widget, only used in non-combo screens, ex. boot screen, reset confirmation...
- comboBox_widget_t (28bytes)
- "first" linked to the first "comboBox_item_t"
- Then each "comboBox_item_t" contains "next" item and so on.
- comboBox_item_t (20bytes)
- Linked to "action_screen", "action" or "editable_widget_t".
- action_screen and action don't use additional space, they hold just integers or a pointer to a function.
- editable_widget_t is linked to an additional widget, so it's also allocated when creating that combo type.
- editable_widget_t (64bytes)
- Content can be can be:
- Editable: "field_int32"(editable integer) or "field_string"(editable string)
- Multioption: Editable integer but the integer is used as index to an array of strings, ex. value 0,1 -> char *opts[]={"OFF","ON"}
As you see, the ram usage is pretty modular, keeping it optimized for each widget configuration, but grows quickly!
Also, each allocation (malloc) adds 8 bytes to handle internal stuff.
SYSTEM menu has only "screen" combo options, doesn't attach editable widgets:
- Main screen widget: 28+8=36
- Combo widget: 28+8=36
- 6x non-editable items= 6*(20+8) = 168
- TOTAL: 240bytes
Now let's go with a larger screen. "SYSTEM"
- Main screen widget: 28+8=36
- Combo widget: 28+8=36
- 15x editable items: 15*((20+8)+(64+8))=1500
- 5x non-editable items= 5*(20+8) = 140
- TOTAL: 1712bytes
IRON is 2KB, and most remaining screens use ~1KB or less.
Nevermind: STM32F101/2/3 don't have USB OTG, so it's a dead end!
-
Bought another screen, found this seller, a lot cheaper:
https://a.aliexpress.com/_u7160L
-
I don't like that this seller has few orders sold.
I prefer to choose such sellers who have a lot of sales. Let it be more expensive.
I bought here: https://aliexpress.ru/item/1005001621784395.html
While I'm waiting. Promised to deliver in the second half of May. :(
-
My test with ST7565R.
-
Thanks for testing! What binary are you using?
I've just uploaded to git freshly compiled ones using latest code.
Have you tried to tweak Contrast/Voltage ratio settings in the menu?
That's the real picture quality or just the camera making it look worse? (Mine does that a lot!)
-
KSGER v3 ST7565 CurrentRevision 1MHz.
-
Latest update is not working. Black screen.
-
Might be the wires messing the high frequency signals.
What about this 1MHz version?
Anyways, I've spent too much time with this already, no more guesssing until I test it myself!
-
This version works well.
-
really now testing
just downloaded and working are you using the script ?
sorry wrong screen but new ST7565R still working lol
but do need to flip now but that's no problem
-
Last two updates for SSD1309.
-
was you taking about ST7565R or ssd1309 not working
-
ST7565R runs on version - v3_st7565_current_1MHz.
SSD1309 not working properly v2.0 Apr 30 2022.
-
ST7565R and working on new STM32SolderingStation using the new script ?
have you tried this version?
-
That version works.
-
ST7565R and working on new STM32SolderingStation using the new script ?
have you tried this version?
What's this? The latest build from git?
bozo,
Try these files, I wonder if the sh1106 charge pump command is causing conflict with the ssd1309.
Also, testing the ST7565 in a breadboard is anything but reliable, should be soldered with wires short as possible.
-
Test with SSD1309.
-
Ah! Great. Do the first two look the same or there's ani difference in brightness?
Please check the different st7565 frequencies too.
-
Identical first two. I'm also testing ST7565. Everything works ok.
-
Even the 18MHz version?? That's confusing, in your tests that was the only difference between getting it working or not.
Anyways, I lowered the SPI frequency to 3...4.5MHz in all controllers.
It's still fast enough and should work more easily with custom boards, wire connections...
AUTOMOTIVE SOLUTIONS, yeah I had enabled Y-flip(Copy&paste mistake), you clearly stated only X-flip was required, fixed.
Latest builds should have fixed everything entirely.
"Should", as I cannot test SSD1309 neither ST7565.
-
Version v3_1565_18MHz also works.
-
All updates for SSD1309 (V2.0) and ST7565 (V3.0) work.
-
DavidAlfa hi sorry i hadn't tested new build |O
i really like the new layout of build script.
let me know if you need me to test any versions (still glued to the bench)
bozo just idea could you put both screen's connectors so layout will let you use any screen? SSD1309/ ST7565
-
IRON is 2KB, and most remaining screens use ~1KB or less.
That is great, so there is plenty of room left, even on 10k targets!
Nevermind: STM32F101/2/3 don't have USB OTG, so it's a dead end!
One can implement one in software ;) . I'm leaning towards the printout method via the virtual serial port over SWD. Or just reading out the flash completely and parsing it back via a tool (this is what I did previously). And thanks ST for implementing the standard CRC32 with the Ethernet polinom with a non standard implementation!... Took me 2+hour too figure out what magic combination of byte ordering, data inversion works. At least on the newer controllers the reversing and negating can be controlled, but not on the F1xx.
-
KocsisV thanks you for helping on the eev
sorry to be a Pain but do you think its posable for me to add second input like stand sleep mode but in ide to sleep and switch mosfet off until it reads there is a valid tip temp input so i can just swap tips without switching off the unit (similar tips) thanks andy
-
KocsisV thanks you for helping on the eev
sorry to be a Pain but do you think its posable for me to add second input like stand sleep mode but in ide to sleep and switch mosfet off until it reads there is a valid tip temp input so i can just swap tips without switching off the unit (similar tips) thanks andy
you can hotswap tips
-
One can implement one in software ;) .
Do you have a lot of free time, don't you? :D
AUTOMOTIVE, if the station does weird things when removing the tip, just solder a 1M resistor between 3.3V and T12+ (Or 10M between the mosfet power pins), it will keep the amplifier input at high level removing any bouncing, and it won't affect the measurement on normal operation.
-
thanks David was trying not to bother you .i was thinking trying to adding tip changing input like jbc. but if i can just change tips with out frying anything then not needed?
thanks wickated i didn't know ok to hot swap
(working on pcb layout)
-
Remember the power is the upper T12 pin, thus the last to make contact when inserting it.
Only a faulty connection could cause issues, ex. a bent contact or broken wire shorting the power, in that case it will blow the mosfet with or without detection pin, so no difference.
-
thanks David was trying not to bother you .i was thinking trying to adding tip changing input like jbc. but if i can just change tips with out frying anything then not needed?
thanks wickated i didn't know ok to hot swap
(working on pcb layout)
if you want jbc experinec while tip swap u can select "run after error" mode to "off". so after tip change u have to manually start.
-
Or just increase the error timeout.
-
thanks all two ways to skin a cat :-//
-
Test with SSD1309 SPI KSGER V3.0 works well.
-
what was the problem?
-
Why does the latest STM32CubeIde ships with an 8 year old version of make... it does not support grouped targets. For that a more recent version is required (4.3 released in 2020 january).
I'm trying to get rid of the need to manually generate code from the .ioc files and also have only one main.c/.h (not one per board).
-
Which hardware revision should be preferred for building a T12 STM32 station with custom firmware and maybe display upgrade in mind?
As far as I found a spi interface is needed.
It is hard to find a seller making right descriptions, even the STM32 clones are only mentioned sometimes. And if you can trust the pictures... :-//
At the moment there are versions named 2.1, 2.1s, 3.1s . I also found a version called 2.01 that seems to have the spi, but also the not(?) cfw compatible mm32.
https://www.aliexpress.com/item/4000104741034.html (https://www.aliexpress.com/item/4000104741034.html)
-
It's hard to guess. Neither I have too clear the KSGER versions.
But basically: 4 pin OLED=i2c, 6-7pin=SPI.
Most OLEDs (SH1106, SSD1306, SSD1309) can be configured to work in i2c by changing some resistors.
It's only the cheaper alternative ST7565 LCD which can only work in SPI mode.
Cheapest STM32 station I've found so far.
i2c display, fancy aluminium plate, nice handle, but linear regulator (might run hot), although I don't think it'll overload:
(https://ae01.alicdn.com/kf/U4f28c45c58894c8daa2db856bf9d23ecj.jpg)
https://www.aliexpress.com/item/4000183089084.html (https://www.aliexpress.com/item/4000183089084.html)
More updated hw, no overheating issues, etc (i2c display)
I'd get this one. i2c isn't really a problem, unless you specifically want to connect a ST7565 display.
(https://ae01.alicdn.com/kf/U9776ece8be944790b4fb4adcc4eea0d4V.jpg)
https://www.aliexpress.com/item/1005003108002691.html (https://www.aliexpress.com/item/1005003108002691.html)
Older Quicko design, terrible fw but decent hw (SPI display):
(https://ae01.alicdn.com/kf/U2dc3e419a3d744e5aefcc7b85d4ac67en.jpg)
https://www.aliexpress.com/item/4000611002273.html (https://www.aliexpress.com/item/4000611002273.html)
Then you enter overpriced KSGER territory, prices double very fast and doesn't really provide any hw enhancements!
In any case, ask the seller first to confirm it ships with stm32 and not some random clone!
-
Though if you're going to install one of those "big" 2.42" screens, it won't fit inside the original enclosure. It might be a better deal to just buy board and PSU separately and then find or make a custom case.
I spent some time looking for a bigger screen that would fit the original case but for anything bigger than 1.3", the frame and/or driver board are too tall. Meh, 1.3" is good enough anyway.
-
@DavidAlfa
Wow, thank you very much! That helps a lot.
The second one mentions a CKS controller chip
Due to the impact of covid-19, the STM32 chip is out of stock, and the STM32 chip is temporarily replaced with a CKS microcontroller. The recovery time is temporarily uncertain.
Whatever "recovery time" should mean?
@ygi
Yes, I already thought about this. I could build a soldering station (or maybe two) around one bigger PSU I already have.
Main problem is, most combinations of board+handle+tips bought separately are more expensive than a complete station. Even if I throw away the original PSU and case. :(
You think the option for a bigger display isn't worth the expense and extra costs?
Edit: I thought, it would be nice to have a slightly bigger display, maybe LCD, that has no OLED disadvantages and lasts as long as the rest of my soldering career...
-
To me it's not worth it because I don't enjoy building the case and I'm not confident I can make it look as nice as I'd want, I also like the stock form factor and looks and my eyes are still good enough to read what's on the small screen.
That being said I can't speak for you. I don't know about your needs, what you deem important from the usability standpoint or how much work you're willing to put into this project. What I can tell is my station is now 5 years old and its tiny (0.96") OLED screen still works fine and bright. I do have a 1.3" on order just because it's a cheap and easy improvement.
-
So the recent planetary conjuction did the magic and I finally received the screen.
Worked right away with the current settings.
It's pretty decent, definitely a lot bigger than the 1.3" OLED.
The only real drawback is the extremely slow switching time, it seems the pixel response time is like 300ms, so fast moving images look weird.
The angles aren't terrible either, you have about 45° where the image looks nice, then it starts to wash out.
The background haze can be greatly enhanced with a dark filter (Check picture with the original dark filter on top).
With daylight the contrast is a lot better, it's in the night/afternoon where you notice the black pixels let some light pass through.
The backlight consumes 50-60mA at 3.3V.
Finally, a video in daylight:
https://www.youtube.com/watch?v=BEFAhWpfIJI (https://www.youtube.com/watch?v=BEFAhWpfIJI)
-
im still waiting for mine to arrive i ordered all three colors to see which i like the best then i may order a few more. using the green oled ones now.
-
Great news! :-+
I just have to wait for my displays to arrive.
I analyzed the circuit with I2C displays. It is easy to modify it for the SPI indicator.
The backlight consumes 50-60mA at 3.3V.
Turning off the display now makes no sense - the current consumption is scanty, the display itself does not degrade (unlike OLED)
You can also make a clock (as in the original firmware) in standby mode
-
You can't power these down, I mean, you can send the poweroff command, but the backlight will stay lit unless you make some modifications, so the dimming options are removed for this display.
The current consumption is only important for ksgers with linear regulator (Reducing 24V to 3.3V), the display alone would cause a thermal load of 1.2W, which is a lot for a small regulator.
You could connect the leds to 24V with a 2W 330ohm resistor...
-
Do the oled and lcd variants require different IO configuration files?
-
The only difference between them is in board.h, having either "#define ST7565" or "#define SSD1306".
I thought the hardware profile would need to be adjusted, perhabs slower SPI clocks, but not required in the end.
I know I could do it better, but it's easier to just copy the entire folder, as I said, I already spent too much time in this project, it works, it's documented, has a idiot-proof building script... what else? :D
-
I asked because this exact reason :) I'm still trying to get rid of the need for multiple projects, copy pasting, manual code generation etc etc.
You just open the project, hit build and if the main.c/h template or the .ioc was updated (or no code generation was run previously) it automatically generates the code. Also everything is in a single project you just have to select the target from the drop down menu.
What does not work (and this is the 3rd method I'm trying...) is that it fails to trigger the code generation if you select "Build All" which should build all available target configurations. I think this is an eclipse bug, would not be the first I run into... (and after 1+hour of searching this seems to be a 15+ year old bug...) The code gen is another build config in another subproject, because this ST codegen only opens the IOC if its in its own project.
Hitting build for each target individually works, if you update any relevant file it automatically re-generates the code from the IOC, if no relevant files changed it skips this step, and the rest is build incrementally. Somehow the single build triggers the build of the referenced (dependency) project, but "build all" does not.
Build all works if the target hw projects are already built, this is only an issue if you start with a new repo or you canged the IOC/template files and try to build all configurations.
In case I manage to get "build all" to work, there will be no need for different hw config if the IOC file/target controller is the same. So there could be multiple configuration for the same board type.
-
That would be great! I was curious how to use a simple switch, or exporting a variable (ex. BOARD=KSGER_V3_SSD1306 make).
But makefile is automatically generated by the project.
Who knows, now it's stable, some day I might try cleaning everything up and porting everything to libopencm3.
-
You can add custom pre and post build steps within the generated makefile (before generation), and also add custom make targets via the "makefile.init" in the project root, then add these targets to the build/clean steps. The issue with these for code gen, is the makefile is generated before the code gen is executed and if the generated files (by the code gen) is not present then the sources list won't contain them -> make will not compile them. If you run the build a second time (after refreshing the project) it works. This was the first thing I tried.
Then I tried to add a custom builder to the main project. This runs before the makefile is generated, but this only runs once for the "build all", not each time for each configuration. No idea why it's not executed for every configuration (it can have configuration dependent variables, that indicates that it is needed to be run for every configuration, but it does not...).
Now with the current setup I have the builder is in the separate hw config project (where the IOC is), the main project references (depends on) the hw target projects. So when the given target needs to be build and the hw project is not yet build it is triggered. Only magic here is that the main project is what contains the main.c/h templates is linked via a build in variable to the hw project, so if you change the template in the main project then a build for the hw project is also scheduled.
Yes it is stable but its inconvenient and prone to mistakes. If you have to add any compiler setting, src folder, include folder, exclude files from the build, etc then you have to modify this in every project manually.
With the setup I'm trying to do, you can do this modifications while the "all configurations" is selected, and only need to do it once.
-
After an another hour, I can think of a possible solution but it's not without a compromise:
The main project will have the code generation, but if the templates (main.c / main.h / mcu_it.c) changes or this is the first build then the code generation will be run for all hw targets (not the same as configurations like the LCD!). It's still incremental, because if you only modify one IOC then only the code for that hw will be re-generated. The main.c -> user_main.c, main.h -> user_main.h separation comes in handy in this case, because the main.c/main.h/mcu_it.c is even more rarely modified since all it does is call the respective handler in the user_main. And also if you add a new hw target, then the pre-build makefile needs to be modified to include that too.
Is this acceptable?
-
I don't really understand why are you saying main.c is rarely modified, CubeMX will modify almost everything, adding all the initialization code, handlers, interrupts, headers... they're different for each controller!
What I don't want is a complex building system which is harder to fix/maintain than just few files Boards folder.
I guess the way to go would be to run away from cubeIDE/cubeMX, and hardcode everything using regular Eclipse+makefile+libopencm3.
-
I don't really understand why are you saying main.c is rarely modified, CubeMX will modify almost everything, adding all the initialization code, handlers, interrupts, headers... they're different for each controller!
Because I moved those to a template folder and in the pre-build code generation step a makefile is executed which has a target (currently a dummy file, read the relevant comment in the makefile) that copies this template main.c/h/stm32_xxx_it.c file, runs the codegen. So the files in the template folder are never modified by the codegen. If you change the templates it is automatically discovered by eclipse (no special config needed, since the template is within the main project), which triggers the pre-build code-gen step, make discovers that the prerequisites of the code-gen target is changed, copies the template to the target hw specific project/folder and runs the codegen on that.
And because eclipse can change based on the currently active configuration which include and source folder to use each hw target can have its own separate folder. This folder is where the pre-build step places the generated files.
What I don't want is a complex building system which is harder to fix/maintain than just few files Boards folder.
Its not at all complex, all of this is contained in a single makefile https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile (https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile), plus the project settings to run this makefile before the build.
And if the pre-build step don't even need to take into account the currently active target configuration, then the project settings becomes really simple: just trigger the pre-build step before build and build the hw config for all targets.
regular Eclipse+makefile+libopencm3
Eclipse does not work well (actually not at all) with normal makefiles. Its internal builder/indexer can't use them. If you go this way then eclipse basically becomes a fancy text editor and nothing more. And I would suggest cmake in this case, because with a simple makefile it's still difficult to depend on code generated by a previous step/target especially if you don't know beforehand what files are going to be generated (what drivers get copied, etc).
VisualStudio and IntelliJ IDEA can work with make/cmake based projects, but then you run into the issue of actually setting up the target platform SDK, as opposite to STM32CubeIDE where everything comes in one single package (compiler, support packages, IDE, ...).
So I would keep the STM32CubeIDE + its automatic makefile generation and solve this pre-build code generation step.
-
Anyone know if I can use this soldering station for TX2 hakko tip?
-
Anyone know if I can use this soldering station for TX2 hakko tip?
T12 stations aren't designed to power 260W tips. Also, I bet those tips don't even run on 24V as that would require handpiece cable to be very thick. So, no way.
-
That's just like a C245, the TX2 runs at 29V, but will work at 24V, just at lower power, I guess the heater is 2.5-3ohms.
Of course, you'll need the FX2 handle and a decent power supply, but otherwise I don't see why it wouldn't work.
Also check the mosfet, some controllers have weak ones, while others have pretty powerful parts.
I have no idea about the thermocouple voltage and polarity, could be the same as T12, or completely different.
-
That's just like a C245, the TX2 runs at 29V, but will work at 24V, just at lower power, I guess the heater is 2.5-3ohms.
Of course, you'll need the FX2 handle and a decent power supply, but otherwise I don't see why it wouldn't work.
Also check the mosfet, some controllers have weak ones, while others have pretty powerful parts.
I have no idea about the thermocouple voltage and polarity, could be the same as T12, or completely different.
Thanks so much for clarifying me. Yes, I tried to measure the heater, it’s around 2.5-3ohm. Both AC and DC can heat it up, no polarity need to care. So I can change the information from the station or before uploading the CFW?
Since we have a lot 2nd TX2 tips laying around, and when I tried without controlling the temperature, it’s really comfortable to solder the big joints. Hope it will work.
Really appreciate it!
-
Is the connection just 2 pins like this picture?
(http://www.hakko.com/english/products/hakko_fu500_fu600/imgs/fu600_02.jpg)
So it might be like a T12 after all, with ground and earth connected together.
Try to take measurements of the thermocouple voltage, connectting a DMM in the lowest millivolt range and heating the tip with a lighter or something any other heat source.
In the worst case I expect the output to be higher than T12, requiring to adjust the amplifier gain, only if it goes negative (I don't think so) it'll be hard to adapt.
For 10A, I'd reinforce the connections with thick solid copper wire, from pin to pin, like in the picture.
Oh, and these tips are called T33... Interesting, $50+ for each tip though!
-
Is the connection just 2 pins like this picture?
(http://www.hakko.com/english/products/hakko_fu500_fu600/imgs/fu600_02.jpg)
So it might be like a T12 after all, with ground and earth connected together.
Try to take measurements of the thermocouple voltage, connectting a DMM in the lowest millivolt range and heating the tip with a lighter or something any other heat source.
In the worst case I expect the output to be higher than T12, requiring to adjust the amplifier gain, only if it goes negative (I don't think so) it'll be hard to adapt.
For 10A, I'd reinforce the connections with thick solid copper wire, from pin to pin, like in the picture.
Oh, and these tips are called T33... Interesting, $50+ for each tip though!
Yes, exactly. It has 2 contact points, as in pictures. I will send you the results later. There is one version from China which is confirmed to work well with this tip. But it was run out of stock, it called T12 V4 full color.
Here, the price for tx2 is nearly 1 US dollars. Super reasonable price but still good
-
Here is my measurements, with negative probe on the contact inside the tip, positive probe on the “small metal ring”
Heat with lighter, voltage stable goes up
Heat with the other soldering iron (I don’t have digital display ones), voltage up to 0.25 mV
Hope this will help
-
David, the display GMG12864-06D has LED backlight pins A and K. You have not thought about the possibility of adjusting the brightness of the backlight through the controller menu? For example, using one of the free ports STM32 and MOSFET?
-
Loosk good. Try adjusting the calibration values manually, and see what vakues you need for 250 and 400ºC.
400ºC shouldn't go past ~3500, the ADC limit is 4095 but you must leave some room for going to 450ºC, also for ambient temperature compensation.
$1 for a TX2? Do you know any online store to buy these cheap ones?
Polf, that display doesn't have much brightness, I added it just because it's much cheaper than 2.4" oleds, but I don't think many people will use it!
It's important for the oled to avoid burning after many hours, but LCD won't.
Not in my current plans, perhabs in the future...
-
$1 for a TX2? Do you know any online store to buy these cheap ones?
since that guy is from vietnam, i guess those cheap tips are used ones from PSU/amplifier factories. u can buy comissioned tips in almost any country in amount of "bucket of nails"
-
$1 for a TX2? Do you know any online store to buy these cheap ones?
Please pm me your address, then I will send you one tip as a gift. However, you have to pay shipping fee, which might over $50+ or never reach you :D
since that guy is from vietnam, i guess those cheap tips are used ones from PSU/amplifier factories. u can buy comissioned tips in almost any country in amount of "bucket of nails"
Yept, I’m from Vietnam, and we call where the heaven for DIY is located. Those stuff — I think it’s waste from Samsung’s factory or LG or other.
Again, many thanks for helping me. I’m now enough confidence to get the stm 32 station
-
$50 for shipping? Do you hire someone to personally carry the tip, walking from Vietnam? :-DD
-
$50 for shipping? Do you hire someone to personally carry the tip, walking from Vietnam? :-DD
Just kidding. To be honest, I really don’t know about the shipping fee.
-
I know! :-+
But I'm interested in getting that kind of stuff, that's perfect for DIY, cheap, you won't suffer if it breaks or burns...and actually way better than chinese clones, as they're used genuine parts.
Don't you know any place to buy them from outside?
I don't wanna go there because I like oriental foods too much, I would have to pay twice when returning (XXXL seat)
u can buy comissioned tips in almost any country in amount of "bucket of nails"
Just, where? :D
-
$50 for shipping? Do you hire someone to personally carry the tip, walking from Vietnam? :-DD
Just kidding. To be honest, I really don’t know about the shipping fee.
Sorry to get off topic, but do you have any $2 13"x40" (330 mm x 1000 mm) metal lathes, by any chance in Vietnam? I'd gladly pay $50 shipping for one. :-DD
-
Sorry to get off topic, but do you have any $2 13"x40" (330 mm x 1000 mm) metal lathes, by any chance in Vietnam? I'd gladly pay $50 shipping for one. :-DD
Metal lathes, we do have a lot but the price is $2 for 1kg. All of these come from Japan. I recommend you just go to VN and I will guide you find anything you want
-
I managed to come up with a solution for the code generation!
Only the main project needs to be imported (STM32SolderingIron), the rest is only needed if you want to change the IOC files conveniently within the IDE. (The inconvenient method is opening/editing the IOC files with the CubeMX tool directly.)
To select a specific target: right click on the project, build configurations, set active, select the target. Other option is to simply click the down arrow on the build icon (below the menu bar by default) and select the target there (this will also trigger a build). The first build will take a long time as it's generating all the code for all targets. Subsequent builds will re-generate the code from the IOC files if needed, there is no need to manually generate the code (and the code generated that way will be ignored). Only the changed targets will be re-generated if the prerequisites change (templates of main.c, main.h, interrupt file or the IOC file). To build all targets: "Project" menu then click "Build All" or right click on the project, build configurations, build all. "Build selected..." (multi selector) also works. To force a re-generation clean the project (right click on the project then clean, or from the project menu then clean).
And now its also possible to differentiate between target hardware and target configuration. So if the IOC files/generated code don't need to change between configurations, its possible to re-use these because it's possible to specify pre-processor defines based on the selected configuration eg.: lcd type.
Link to the branch in my repo: https://github.com/KocsisV/stm32_soldering_iron_controller/tree/updateProjectStructure (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/updateProjectStructure). This is not the master branch (yet)! You have to check out updateProjectStructure after cloning. This is also behind the main repo by a few commits.
-
I know! :-+
But I'm interested in getting that kind of stuff, that's perfect for DIY, cheap, you won't suffer if it breaks or burns...and actually way better than chinese clones, as they're used genuine parts.
Don't you know any place to buy them from outside?
I don't wanna go there because I like oriental foods too much, I would have to pay twice when returning (XXXL seat)
Here is link for tx2 tip that I found, price is 60.000 vnd (~$2.5 US dollars) without shipping fee. I bought from the other guys without online store :D
https://shopee.vn/product/169047023/7595160828?smtt=0.236339943-1652481120.9
Here is for the handle with price of 200.000 vnd ~$ 9 US dollars from the other store— I bought this handle. The store also has option handle with tx2 tip, price is 250.000 vnd ~ 12$
https://shopee.vn/product/34194508/10251373537?smtt=0.236339943-1652481679.9
Just download Shopee app from your cell phone and register one account and good to go. Because I saw alot of store from China, Indonesia so might be ship to Spain.
Just ask me if you have any concerns.
Many thanks
-
I've tested it, seems to work, but definitely running CubeMX 5 times is a bit annoying, nothing can be done to execute that only for the specified target?
Btw how to add target variables?
I tried using symbols as variables, but it didn't work, ex. -DDISPLAY=ST6565, but -DST7565 did.
-
Sorry, I can't to anything about having to run it 5 times. But on the upside, it only executes it if its changed, and only for the changed target. So if you only modify the IOC files for target X then only that will be re-generated.
I tried to separate the code gen per target, it works if you only build one target at a time. If you build all then the pre-build "builder" only gets executed one time or not at all (depending which project is it in). Its a known eclipse CDT (the c/c++ dev plugin) bug, and was reported 15 years ago. Welcome to eclipse...
To add target specific symbols (see the attached image):
- right click on the STM32SolderingStation project or in the menu bar Project -> Properties
- on the left of the properties window select "C/C++ General"
- then select "Paths and Symbols"
- select your target configuration from the drop down menu
- select the Symbols tab
- select "GNU C" for the language
- click add on the right side
No need for any -D or similar, the compiler specific "how to" is handled by eclipse.
You either have to do this for each target or tick "Add to all configurations".
Note: I will merge your changes to my repo then I will add the configurations to the new LCD type.
Note2: You can also add the project name as a symbol via a variable (to all configurations): set the value to ${ConfigName} and decide in the code how to handle different configurations.
-
I just got this board, it looks like v3 but I’m not sure. Could you please tell me if I can use your cfw?
The mcu is mm32spin. So weird
Many thanks
-
It seems a v3. Anyways, you must replace it with a compatible mcu, MM32 isn't!
-
It seems a v3. Anyways, you must replace it with a compatible mcu, MM32 isn't!
I got a v3.0 and the MCU does not have any identifying text, this has been rubbed off or it has a thin piece of plastic stuck on top. Fortunately it seems compatible with STM32 chips as it flashes and is running the fw just fine.
-
Out of the 5 supported, which boards have an onboard or external battery (attached from the factory)?
-
There are a lot of boards, versions, revisions, variations... check Dreamcat's controllers link in the Readme.
Luckly the layout is the same for a lot of them, there're just 4 bases: Quicko, Ksger 1.5, Ksger V2, Ksger v3.
Also, Quicko 072 and 103 are exactly the same, just uses different mcu, stm32f072 or stm32f103.
Are you planning to make a clock or something like that?
-
No, just enable the backup memory for the boards which has a battery backup.
-
there are at least 4 versions of the "oled v3.0" and of the v3.1 boards i know of there may be more. one has the battery soldered directly to the board. one had the spot for the battery to be soldered but no battery. the other has a socket for the battery the last has 2 point and leads soldered to it with a wire to plug into the battery. i have all of them. they appear to be the same boards minus the battery setup on them.
-
So there is no certainty that a battery is present. Then I keep the option disabled for all hw targets.
-
So there is no certainty that a battery is present. Then I keep the option disabled for all hw targets.
correct. even if two people order v3.0 / v3.1 they may both get different ones one with a battery and one without.
-
In the menu add an "enable/disable" option.
Let the user decide.
-
I see that a minor feature, while adding complexity and source of trouble.
Once you've setup everything, the settings will rarely change, unless you change tips every 10 seconds, so flash wear is pretty low.
Also, since the current flash usage is ~90KB, it shouldn't be hard to reserve more space for the settings and use use multiple partitions to reduce wear, ex. 6-8KB, for 3-4 partitions .
When the settings are modified, the a byte in the current partition is written to "0" indicating this block is used, so the settings must be searched in the next block, and when the last block is written, the cycle starts again.
KocsisV, I've tried EmBitz IDE, looks really fast, although as always, once you're used to certain environment, the transition is not easy, also CubeMX is pretty hacky to implement.
I also tried PlatformIO months ago, I hated the JSON stuff, setting everything up was a PITA, nowadays it seems you must master 20 different things before you can actually start developing, is that hard to provide a simple IDE setup?
I learned programming with the old MPLAB IDE, everything was very much the same as CubeIDE, integrated, straighforward, select your device-> Start developing.
Once I see all that lengthy stuff, I just close everything and run away :-DD
-
Finally received today a parcel with displays.
Connected - everything works fine.
Thanks David for the firmware!
-
Looks nice :-+. I actually like more the non-inverted display!
-
I bought two different displays to compare. The price is not very high.
I haven't decided which one I like better yet.
-
Backup RAM enabling/disabling could be done at runtime, it would not be that hard as the actual saving/loading is separated from the rest. The "areas" where it stores the selected profile/tip/temp is handled the same whenever its enabled or not. Only the save/load differs a tiny bit. I thought about auto detecting whenever a battery is present or not by measuring the battery voltage, but this could fail if they connected the VBAT to VCC.
Now this function can be enabled by adding (un-commenting) the "#define HAS_BATTERY" in the board.h file.
I often change tips, plus I found it cumbersome to go to the menu to change the default temperature. It would have been better if each tip could have a separate default temp but 20 bytes does not fit it all.
Cycling: what you described is the copy on write file system. I have mentioned this a few times already that it would be one the best solution to reduce flash wear, but to implement it in a non hacky way requires a lot of effort. Sure, it can be implemented with partitions as you said, but once you start to implement and realize that you are writing/erasing a whole page for a few changed bytes you quickly realize that simple partitions is not the way to go.
Btw there is ~40k of empty flash on 128k devices if you compile with size optimization enabled. (Sidenote: I did an experiment with compressed bitmaps (simple RLE) and that would yield another ~2k -> not worth it.)
IDEs: stick with this STM32CubeIDE eclipse. It comes pre-packaged with all things needed. If you plant to switch away then make it non IDE specific eg.: cmake. Then you edit the code in whatever IDE you desire, and others can pick other ones without any issues. But then it will not be as simple as just installing this IDE and having all things at hand immediately.
Btw I regularly use VSCode (what PlatformIO is based on) and its not bad. One of the better IDEs out there.
MPLAB (not MPLAB-X) is not much better than a text editor. I used it a lot for pic10,12,16 a long time ago.
MPLAB-X could have been better, but they picked the worst base they could have picked: NetBeans. Early versions of it were barely usable, but its not much better now either. I remember I got fed up with it and used eclipse CDT for actually editing the code, then switched to MPLAB-X to build&debug. And their decision to extend the C language with non standard stuff is also completely idiotic.
I created a pull request for my code changes (not the project restructuring, that will come later).
-
Hello,
I tried to use tx2 tip with the original firmware, the temp was up about 3s (100oC) and error occurred (one buzzer beep and scr displayed INVETER). So I think the only way to use my tip is going with CFW.
I also tried to put 600R 2w between 3.3v ldo and vcc, however the mcu is quite noisy, not stable (Vin reading ok but jump up and down)
Now, I’m waiting for the stm32 mcu. Hope it will be ok because my soldering skill is super low, and the mcu has 48 pins.
-
What do you expect connecting a 300W heater to a power supply designed for 72W?
-
What do you expect connecting a 300W heater to a power supply designed for 72W?
Haha, I thought it will be slower with the bigger one. Same as charging a lead axis battery with very small current :D
-
No. The power supply switches to protection mode under heavy load. Then it starts up again. You need a powerful power supply. Try connecting a small 24 volt bulb to this power supply in parallel with the controller - you will see for yourself how it blinks when the power supply is turned off in protection.
-
I need help again,
I soldered the STM32f103; however, when I tried to flash it said "File size is bigger than the flash memory size." I saw my flash memory size is only 64kb
So what can I do now?
-
Seems like a counterfeit, only clones have really 64KB for 64KB parts, stm32f103 C8(64KB) are actually CB(128KB) but 2nd 64KB memory block untested ot not guaranteed.
-
My project is KSGERv3.s with SSD1309 and ST7565.
-
Seems like a counterfeit, only clones have really 64KB for 64KB parts, stm32f103 C8(64KB) are actually CB(128KB) but 2nd 64KB memory block untested ot not guaranteed.
So can I remove some parts of your code to fit 64kb flash? Or I have to buy the real ic?
-
Just removing something easy like translations or unwanted profiles won't be enough. I mean, you can do it but It'd be a lot of rework with a lot of potential breakage to downsize the code that much. Alternatively I think builds went over 64KB in August last year so you could try running an older one from July 2021.
For what it's worth I recently bought a few blue pill boards from this seller and those came with genuine STM32F103C8T6 (QFP48) => https://www.aliexpress.com/item/1005003169244854.html (https://www.aliexpress.com/item/1005003169244854.html)
If you can't find the original part separately you have that option. Definitely better than butchering the code.
-
Nope not easily, neither supported, even when compiling for size instead performance, it still uses 79KB.
Just find a STM32F101/2/3CB, not C8, so even if being a clone, it'll have 128KB.
KocsisV, I don't forget, I just need to find some time to review all the changes!
I was thinking, are project build variables passed to the Makefile?
Could this:
all : ./boards/KSGER_V1_5/src/generated \
./boards/KSGER_V2/src/generated \
./boards/KSGER_V3/src/generated \
./boards/Quicko_STM32F103/src/generated \
./boards/Quicko_STM32F072/src/generated ;
Be replaced to something like this? (pseudo code):
all :
if(BOARD==KSGER_V1_5)
./boards/KSGER_V1_5/src/generated ;
elif(BOARD==KSGER_V2)
./boards/KSGER_V2/src/generated ;
elif(BOARD==KSGER_V3)
./boards/KSGER_V3/src/generated ;
elif(BOARD==Quicko_STM32F103)
./boards/Quicko_STM32F103/src/generated ;
elif(BOARD==Quicko_STM32F072)
./boards/Quicko_STM32F072/src/generated ;
fi
Declaring "BOARD" var in the build profile. A little hacky but would work.
Sorry, I have very little knowledge about Makefiles!
-
Really sorry, this is my stupid error. I did a right click to download the.bin file. And I end up with a bin file that is 1Mb size. Therefore I can’t flash into the new mcu. Now, it works like a charm!
Work well with tx2 tip but idk why it only draw 3A which is not powerful enough and it takes quite long time to heat up
Thank you so much for taking your valuable time to clarify me!
-
Have you set the correct values in iron menu? Power should be set to 260W and heater impedance to ~2.2 Ohm.
-
I just need to find some time to review all the changes!
I know, I'm not rushing you :)
That PR does not contain the project restructuring, that will be part of another PR later.
I was thinking, are project build variables passed to the Makefile?
It does not work. As I said in the earlier posts, I tried quite a few methods, here is why they don't work:
Method A: If there is one subproject per hardware target, it only triggers the build of the "codegen" builder if you build one target. If you try to build all configurations with the "build all" then it fails to trigger the subproject build completely. This is a known 15 year old eclipse CDT bug.
Method B: If you put the codegen step into the main project as a "pre build step" (This is different from a builder!) then eclipse will generate its own makefiles before this step runs thus the generated files won't be compiled. This partially works, but you need to compile the project twice, and refresh the project between them. And this does not work at all with "build all" because that executes a clean after build.
Method C: If you put the codegen step into a builder (like it's currently is) then it will be only triggered once, regardless if you asked it to only compile a specific configuration or compile all. And the eclipse internal variable which holds the "active configuration" does not tell you if its running for only that config or all the configurations. Even if it were executed for each target separately when "build all" the active configuration does not change because that contains the name of the config selected on the UI, not what its currently building.
To translate this to the "board variable":
Method A: works for single targets, but due to the bug build all configs does not.
Method B: does not matter, does not work.
Method C: no such variable available in eclipse in the builder stage.
Sorry, I have very little knowledge about Makefiles!
Your approach is with the "if"s is completely wrong :) You try to treat "make" as an imperative language, but it is a declarative one! It does not define steps to run, it defines rules how to obtain artifacts.
all : boardX ;This means to get the target "all" first target "boardX" need to be present (prerequisite), then do nothing.
If you wan't to introduce a variable for example, there is absolutely no need to "if" anything. Simply
all : $(BOARD);will work (well, actually it won't and this is not a good approach, will explain later). As this says resolve the BOARD variable and that becomes a target which is needed for all. And its possible to use wildchars, variables, etc in the target's name. So this is why that in my current setup you don't see specific targets for each board:
https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile#L24 (https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile#L24)
This matches any target that matches this given pattern. The last "touch generated" part is only there to make an actual file exactly at the target's name. This will be used by make to determine if the rule for this target need to be executed or not. If the file is there AND its timestamp is newer than all of its prerequisite, then the rule is already satisfied. This is why the code-gen becomes incremental. It only runs it if the file named "generated" is not present or if you change the templates or the IOC file.
And to why "$(BOARD)" won't work as a prerequisite: it will not check if "BOARD" exists or not if the target (all) is already up to date. So even if you ask it to build a different board if any files in its prerequisites is older than the one you already built then it will simply skip the rule.
This is why I have one rule that matches all boards (./boards/%/src/generated). If I ask make to build target "./boards/XYZ/src/generated" it will execute the rule if the file at "./boards/XYZ/src/generated" is not present or if one of it's prerequisites is newer than it.
So by listing all boards as prerequisite in the "all" target all it says that to get the "all" target it needs those ./boards/.../src/generated files before it can be satisfied.
I recommend you to read this tutorial: https://makefiletutorial.com/ (https://makefiletutorial.com/). It explains the basics pretty good. Only thing I used what's not in there is the "second expansion" trick to resolve env vars with env vars.
But again, no such "BOARD" variable can be obtained in "method C", and "method A" is not executed when building all targets. So neither works. And since this whole code-gen only needs to be executed once it's not that annoying. It takes less than 2 minutes on my machine for all 5 to be done. And again don't confuse the board target to the configuration! One board target can be used by multiple configs. If you check my latest commit of the updateProjectStructure, I already added the configs for the LCD variants. 18 configs get's built if you pick build all, but "only" 5 codegen is executed (one for each hardware variant).
-
Have you set the correct values in iron menu? Power should be set to 260W and heater impedance to ~2.2 Ohm.
I changed to 300W and 3.0R, as my calculating it should be 10A. Anyway, just a little bit waiting time, it’s okay to me.
So when I change tip to T12, do I need to set back to 8R /80W?
-
The power setting is really a limit for when you're using a power supply that's too weak for the tip. If yours can do 300W, you can leave it at that. Now for the heater setting, I'm not quite sure how it interacts with power delivery control. I would change it back unless David says it's fine like that.
PID settings for T12 are most likely not adequate for TX2. You can get really slow response time if it's not configured properly. Also, check if the MOSFET is overheating. I know others said it's fine according to datasheet but that's only if the part is genuine.
-
The heater resistance is used for the power limit function, nothing else, it simply uses Ohms law:
Power supply2/resistance = Max Power.
If this value exceeds power limit value, it adjusts the relative 100% PWM duty value.
Ex. If 24V puts 200W into the tip but you set 100W limit, the "virtual" 100% PWM output value would be actually the 50%, and that's what is used for PID calculation.
At maximum output, each PWM cycle would average the power limit: 50% at 200w, 50% off, average=100W.
Since PWM cycles is 200ms, there's no time for the heater to overheat and burn.
If course if you use a very low power heater, it would blow up like a fuse, even limiting the power, like driving 1W with 200W pulses.
But not likely to happen with any soldering heater.
-
The heater resistance is used for the power limit function, nothing else, it simply uses Ohms law:
Power supply2/resistance = Max Power.
If this value exceeds power limit value, it adjusts the relative 100% PWM duty value.
Ex. If 24V puts 200W into the tip but you set 100W limit, the "virtual" 100% PWM output value would be actually the 50%, and that's what is used for PID calculation.
At maximum output, each PWM cycle would average the power limit: 50% at 200w, 50% off, average=100W.
Since PWM cycles is 200ms, there's no time for the heater to overheat and burn.
If course if you use a very low power heater, it would blow up like a fuse, even limiting the power, like driving 1W with 200W pulses.
But not likely to happen with any soldering heater.
Thank you so much. I got the idea. Could you please explain a little bit about Imax (now it’s 0.7) what if I increase it to 1 2....?
Moreover, please add these explaining to your github. I think it will be really useful for someone noob like me
The power setting is really a limit for when you're using a power supply that's too weak for the tip. If yours can do 300W, you can leave it at that. Now for the heater setting, I'm not quite sure how it interacts with power delivery control. I would change it back unless David says it's fine like that.
PID settings for T12 are most likely not adequate for TX2. You can get really slow response time if it's not configured properly. Also, check if the MOSFET is overheating. I know others said it's fine according to datasheet but that's only if the part is genuine.
As DavidAlfa explained, I got the main idea. I do have 24V/14A psu and a laptop ac adaptor (19V 7A). Which one should I use? Since now I’m using DC power supply for testing current and so on
-
Explain what in GitHub? It does what it's supposed to do, limit the power, everything it's pretty well explained in the Operation manual.
Same for Imax, it's a PID adjustment, means Integral Max Accumulator, the limit it will grow, and the grow speed depends on Ki, all this is also explained.
I can briefly explain what each option does, but not down to ground level, I'm not a teacher!
Both power supplies are ok, 19V will give 120W and 24V 192W, with a 3 ohm load.
-
Explain what in GitHub? It does what it's supposed to do, limit the power, everything it's pretty well explained in the Operation manual.
Same for Imax, it's a PID adjustment, means Integral Max Accumulator, the limit it will grow, and the grow speed depends on Ki, all this is also explained.
I can briefly explain what each option does, but not down to ground level, I'm not a teacher!
Both power supplies are ok, 19V will give 120W and 24V 192W, with a 3 ohm load.
Thanks again! This is really good fw for the one not really good from China :D
Actually I’m not an electrical engineering, but I learned my first lesson from our school when my professor said “what ever you do, just do things that anyone could understand what you are doing no matter who are they, professor, amateur or stupid ones”
-
Actually I’m not an electrical engineering, but I learned my first lesson from our school when my professor said “what ever you do, just do things that anyone could understand what you are doing no matter who are they, professor, amateur or stupid ones”
Are you saying that the developer of a nuclear power plant should make sure that any peasant understands?
It is important for a peasant to have electricity in the house. And if he is interested in how a nuclear power plant works, let him go to study as a nuclear physicist. :)
I don't know how to program STM controllers. But I don't need it. I'm just using what David developed. I like.
-
@David Since nobody reported it, there's a misnamed variable here: https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/f142199fe73a4bf0c6f1dec9bf7ffa89af2fc334/Core/Src/main.c#L224
PWM_DETECT_TIME should be TIP_DETECT_TIME
-
You're right, I changed that recently... But I swear it compiled ok? Otherwise I completely missed out!
-
I wouldn't catch that if it weren't for the compiler crying about it, that's for sure. Your dev computer might be out of sync with github.
-
Received LCD GMG12864-06D v.2.2, black and white, inverse. I waited for the parcel for 60 days.
The backlight current is limited using a resistor, it is 11 mA. The update rate is noticeably lower than that of the OLED, there is a delay. How it works can be seen in this video.
https://disk.yandex.ru/i/hf1bfeK2GO3KMA (https://disk.yandex.ru/i/hf1bfeK2GO3KMA)
The controller is homemade based on the scheme of the KSGER v.3. The microcontroller is STM32F101CBT6. Firmware from David STM32F101_ST7565 May 8 2022.
-
I'll add a photo.
-
What is the preferred method to build the firmware atm?
I installed CubeIDE and followed the video instructions on github, but IDE 1.9.0 looks different and doesn't seem to load files as expected/explained.
After that I tried to use the Building_script.bat (java had to be installed first) but got an
Running CubeMX...
CubeMX error! :-//
-
TIP_DETECT_TIME
Probably you left it out from the commit or something.
I noticed this too, I thought that it was because of the failure of git to correctly resolve conflicts in the merge of 40+ commits. It is already fixed in the PR.
Btw feel free to leave comments in the PR itself, even better if make the comments on the specific changed lines itself.
I installed CubeIDE and followed the video instructions on github, but IDE 1.9.0 looks different and doesn't seem to load files as expected/explained.
I also use 1.9.0, followed the guide and it worked.
-
Yep, I left out that commit! Fixed. I had removed the main project to try KocsisV's and forgot about it...
soldermarc, it should build now. Thanks ygi for reporting!
KocsisV, reviewing some commits it seems we did the some work twice, like the screen pixel for bicolor OLEDs and cleaning of some old, unused parts(iron debug ,etc), flash erase IWDG (I detected it because it was resetting in a debug build)...
Are you sure about making the display variables as a packed bitfield?
I mean, it's ok, but saves only 3 bytes, makes access by the cpu harder, and you might want to change it in the future to whatever?
Otherwise, there're a lot more of variables that could be modified to bitfields to save space.
-
So I've managed to get a CFW on my pcb. :)
But I'm unsure if it is the right one... :-// Flashed the STM32F101_SSD1306 because of the 4pin OLED connector.
Display was flipped initially, but set to the right orientation in menu. The tip is not recognized. I wonder if I have a different pinout on the 5pin iron connector or the wrong board/fw combination.
I searched for all pictures of KSGER and Quicko revisions I could find. But there was no exact match - very confusing. The station was sold as Handskit STM32 v2.1S.
https://de.aliexpress.com/item/4000183089084.html
Btw. the component under the power cable is a big 78M05.
Edit:
what does the
JBC H/T+=OFF
T12 H/T+=ON
mean?
-
I had removed the main project
Why don't you check out multiple instances of the same repository? Git is a distributed version control system, you can even push&pull changes between your local repositories, have branches/commits only locally in your repository, etc.
Because STM32CubeIDE is eclipse based, you can have multiple workspaces and switch between them. So in one you can have one set of projects (and even IDE settings), and a different set (and IDE settings) at the same time. (File -> Switch Workspace)
we did the some work twice
Could be the case. But all of these conflicts are resolved. Don't check it commit by commit, use the review options in github.
makes access by the cpu harder
If I recall correctly, it does not. CortexM3 has instructions for direct bit manipulation/testing.
Btw, for these flags the bool_t type should be used as that gives a hint to the compiler that it can optimize a bit. (Eg with the abstraction of the iron_t structure with the additional getter/setter functions the code size actually decreased instead of increasing.)
But for this particular case, I think that was a mistake that I left that in (I tried to arrange the layout in a way to not have to reset every setting, thus the need to shift things around a bit). That could be reverted.
A lot of space could be saved, but since that area is not even close to being full it does not matter much from the space saving perspective.
Please make these comments in github! It will be hard to track them here. Assign yourself as a reviewer to the pull request, then click on the "files changed" tab, hover over any line where you want to add a comment, a small blue + icon will appear at the line number, click that, add your comment (and click "start review" in the first one). Once you are done with a bunch of these (you can also mark files as "viewed"), on the upper right corner click review change it to "request changes" (if needed) and submit.
-
Edit:
what does the
JBC H/T+=OFF
T12 H/T+=ON
mean?
For T12, these contacts must be closed (this is done at the factory).
If you want to use 245, then these contacts must be disconnected.
How to connect 245 can be viewed on the Internet.
If you use 245, then solder the missing LED, as in the picture.
-
That makes sense, probably the reason it's not being detected.
The LED function is to clamp the voltage when the output is enabled.
Not required for C245, as 24V never reaches the amplifier input (the sensor is isolated from power), it's in T12 where it happens.
I'd put a simple 1n4148 there, limiting the signal to 0.6V is already a lot more than the sensor will output, 13mV-40mV depending on the tip type.
-
Of course I missed that when desoldering the iron front connector (for adding the programming header to the pcb). |O
With the H and T+ pins closed everything works great now! I also added the diode, but so far only the T12 handle is in use.
Btw: great firmware with tons of options and super fast display and menu response. 8)
I think I have to spend more time and money for calibration now...
-
Get a cheap DMM with temp. probe, you don't need anything fancy. +-10°C won't change anything!
-
The purpose of having only one tip by default is to calibrate it, then the new tips will copy that calibration and be more or less close.
I'd add more tips, but it's stupid for a simple reason: You'll have a lot of completely uncalibrated tips, every single one requiring manual calibration.
It's much easier to simply add or copy an exiting calibrated tip and write 4 letters.
Currently, enabling/disabling the tips cannot be easily done. ToDo, maybe in the future.
Does this mean it is okay to run all T12 tips with just one profile? I still don't understand why it is only possible to make 20 profiles? I thought all tips needed a different PID config! Can anyone explain this?
-
Do you really have more than 20 different tips? If so, that's current limitation.
This firmware supports 3 profiles with 20 tips each, so that's 60 tips.
Starting a profile from an already calibrated tip usually works pretty well, most tips perform nicely with the same PID settings.
For the picky people wanting it absolutely perfect, not even professional stations do this, they just hide the overshooting and oscillation, and it's fine!
-
I do have more than 20 different T12 tips, yes. Regularly I might only use 5 though.
Currently I am running the original firmware on my v3.1s ksger. I don't know yet if it has the overheating issue concerning the display.
I will take some photos of the PCB later to post it here.
To me all these PID profiles and configs are a complete alien concept. I have no idea what any of it means.
As a novice I am too concerned about frying a tip by using the wrong PID configs on a different tip.
-
I'd appreciate you read the firmware readme and operation manual before asking, most of these questions are described there.
Normally the user only needs to calibrate the tip temperature, not other advanced settings.
Burning a tip? That will hardly happen, more than 2 seconds >100°C from setpoint or >500°C absolute will trigger the safety mechanism and lock the station with a warning.
Of course, if your tip is badly calibrated and it reads 200°C while it's actually at 400°C, it will be unable to work correctly.
The typical consequences of wrong PID settings will be some oscillation, or tripping the safety lock in extreme cases, but current settings works pretty well for most controllers and tips.
Calibrate one tip, then test the temperature accuracy at 300°C with other tips, usually you'll get small (5-10°C) differences, not to worry about, otherwise better make a new profile and calibrate that one.
I have a generic profile (T12) for most, then specific ones for those being too different (JL02, whatever)
Keep in mind there're dozens of controller versions and variations, also, depending on the brand, the tips change a lot, so it's impossible for me to perfectly tweak every posibility/combination.
I'm not working as a development engineer at Hakko/KSGER with access to lots of tools, controllers and tips, neither I make any income from it to justify spending all my free time in it (I worked on it for months during the lockdown), except very few small beer/coffee donations I get from time to time :D
Edit:
About the regulator overloading, you don't need to worry about.
If it happens, it'll just reset randomly, damaging the hardware shouldn't be a concern, proceed with any workaround to fix it.
-
Don't get me wrong. I am not asking you for features or to change anything! You are a legend in this community and you made an excellent firmware! :-+ Reading all your interesting posts and being able to follow you on your journey is a privilege in itself!
I was under the impression the PID values were some magical numbers which could destroy the tips or the soldering station if they were wrong.
My philosophy, especially when it comes to firmware on embedded devices, is don't fix it if it isn't broken. Your firmware however might be an exception to this rule and it is tempting to install nonetheless!
I just took some pictures and I was pleasantly surprised to find the updated PSU version in my unit even though I ordered at the beginning of 2021. The production run of this unit was from January of 2021.
The PCB is the black 3.0 OLED. Does this PCB suffer from the overheating voltage regulator? Do all SPI OLED models suffer from this issue? Would you personally consider this to be a "good" PCB?
Is there anything else interesting about this particular unit?
Thanks again David for all your contributions!!!
Edit: Interestingly system info claims the hardware to be version 3.1 but the PCB clearly says 3.0.
-
Ah, I think nobody got it wrong here! Just exposed why it isn't perfect :-+
That board should work fine, maybe a bit noisy because it's running a switching converter for 3.3V, while the best would be converting 24->5V and then use a low noise LDO for 3.3V.
You might get some noisy readings due that, but overall it should perform nicely.
AFAIK, there's a backup for your controller here (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/Original_FW/KSGER) (3.1Snew1.hex), so you should be safe.
Me, a legend? C'mon, this is just a firmware for cheap soldering controllers, not a NASA Rover on Mars :-DD.
Perhabs it reduces the cancer risk of being exposed to some terrible chinese firmware.
-
Hahaha you never know.
Today you have conquered the soldering station firmware - and tomorrow Mars!
I will try out your firmware. There was another project where they were using a raspberry pi 0 to program the stm32. I am not planning to get an st-link any time soon so I think I will attempt to flash it with a raspberry pi.
-
If your soldering skills are good, you can lift BOOT0 pin (It's connected to gnd by default), and connect it to gnd again, but through a 10K resistor.
Then solder a small wire from the pin to a switch/jumper, and the switch to VDD.
Now you if you turn on the stm32 while pushing that switch, it'll boot in bootloader mode and you could program it with a simple USB-serial converter as explained here (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4020196/#msg4020196).
-
Has no one here tried to connect a raspberry pi to the SWD/JTAG interface instead?
I found three references of this capability using the openocd software
http://zansprojects.blogspot.com/2019/01/stm32-remote-debugging-with-raspberry.html?m=1 (http://zansprojects.blogspot.com/2019/01/stm32-remote-debugging-with-raspberry.html?m=1)
https://stm32duinoforum.com/forum/viewtopic_f_37_t_940.html (https://stm32duinoforum.com/forum/viewtopic_f_37_t_940.html)
Someone on the raspberry pi forum tried it and has had some partial success. He wasn't able to flash anything but he could read and erase the chip: https://forums.raspberrypi.com/viewtopic.php?t=316090 (https://forums.raspberrypi.com/viewtopic.php?t=316090)
Instead of soldering to the uart I would rather get the St link instead ;).
The ksger is my primary soldering station. My only other soldering iron is some cheap weller without temperature controls and a big non removable tip. It is good enough to solder the header pins onto the SWD interface and that's about it.
-
I do have more than 20 different T12 tips, yes. Regularly I might only use 5 though.
Currently I am running the original firmware on my v3.1s ksger. I don't know yet if it has the overheating issue concerning the display.
I will take some photos of the PCB later to post it here.
To me all these PID profiles and configs are a complete alien concept. I have no idea what any of it means.
As a novice I am too concerned about frying a tip by using the wrong PID configs on a different tip.
Even though I follow this thread, I am still using the OEM firmware on my KSGER "v3.1" I bought about 2 years ago. The fact that mine is 2 yo may be a factor because I think the OEM firmware works OK, it does not have the best UI, but I have not run into any issues, I have read about people who have bought theirs after mine and they seem to have issues with the firmware on their soldering stations (leads me to believe that either the boards were cheapened even after mine or the firmware was changed after whatever version came with mine or I just got lucky). That said, I can't say that this works across the board, I only have 4 tips, but when I tested it and switched tips to see what the temperature difference was between different tips using the same profile, it was really minimal (maybe 10 degrees). I have one of those FG100 clones and the temperature it read agreed with what was onscreen, switched to the correct tip profile and the temperature corrected so that it was right on the money. My guess is that with the OEM firmware you will be safe if you have the wrong profile active for the tip you are using, at least as long as the tip is similar in size to the last one you used (i.e. you may run into overheating issues if you use a larger T12 tip then switch to a small one with little mass).
I believe Dave's firmware has some safeties built-in so that the "runaway tip heating" does not happen under his firmware (correct me if I am wrong, Dave).
-
As I already said, yes it does, but it can only detect when it's firmware's fault, i.e wrong PID settings or some bug causing a temperature runaway (Outputting power when temp>setpoint).
Faults like shorted mosfet cannot be detected, the signal is the same as when the tip is removed, reads very high, there's no way of detecting if there's current flowing.
Must say I've never burned a tip since it was implemented, so it's doing the job nicely.
With the variations between brands and batches, it's simply impossible.
Buy a BC3, calibrate it. Buy another BC3 3 months later, it won't perfectly match the temperature.
Will be 5, 10°C off, but not perfect.
That's why it's hard to believe it perfectly matched the temperature by just swapping the tip profile, unless you previously calibrated it beforehand for that exact tip.
-
That's why it's hard to believe it perfectly matched the temperature by just swapping the tip profile, unless you previously calibrated it beforehand for that exact tip.
If this was directed at me, then I don't know. I never re-calibrated the unit for the tips, I only changed the active tips to get the correct temperature. I only have the 4 tips that came with the station I purchased, so perhaps, since the tips and the station were all from KSGER's "official" store on Aliexpress (funny since they had three apparently different "official" stores at the time, have not looked lately), they have/had tighter control over the tips so that the calibration lines up with what is in their stations and tips from another supplier would not be as close? :-// Perhaps they pre-calibrated the stations based on the batch of tips produced/being sent out at the time (and if I were to buy a new tip, today, of the exact same as one I already have, and tried it with the original calibration, the calibration would be off)? Perhaps they pre-calibrated the units with the tips they sent, although this would not line up with my experience using the tips the first time, since my tips had the typical non-reading for about 15 minutes (or whatever the time was) until the tip had "burned in" and the station was able to detect the tip and temperature.
-
There were some posts that did a teardown of some of the t12 imitation tips. Different manufacturers use different amounts of copper inside the tip. Some use more, while others use less. The hypothesis of ksger calibrating the soldering station to their particular tips is very plausible.
-
I do have more than 20 different T12 tips, yes. Regularly I might only use 5 though.
It is possible to change the number of profiles to 1 then increase the number of tips to 60 if that works for you: edit the settings.h and change ProfileSize to 1 and TipSize to 60 and recompile. The total number of tips should not be over 60 because there is simply not enough area reserved to storing it.
I have not tested this, it might not work properly, but only one way to find out :)
Temp cal is pretty important in my opinion, I have a few tips where 400C is 1950 adc count, while others need 2200. This would be around ~50 C difference if I use the tip with the more sensitive thermocouple with the wrong calibration.
-
I think it should work...
-
Unless this limit has to do with the 10KB RAM devices, might as well increase the size of settings partition to 3 or 4KB in addition to TipSize instead of reducing ProfileSize. I mean, what are the chances the firmware is going to need all that free space for future development?
-
There's one problem, though.
The flash must be temporary stored in the RAM, prior erasing and writing the new settings, so although the flash has enough space, I'm not sure about the RAM.
Increasing to 60 tips per profile boost the memory requirement from 1.62KB to 4KB. Each tip is about 60 bytes (Not exact).
Edit: Nope, 60 or even 50 is too much 10KB ram devices, but 40 does fit. The STM323F103 could store something like 150..200...
Is that enough? How many *** T12 tips exist? :-DD
Commited this and made new builds, report any issues...
The code could be modified to split profile settings and tips in different sections.
Then, always load the tips directly from the flash, instead storing them in ram.
Temporary read the tip when entering tip settings screen, modify it, and save it when exiting.
F072 has 2KB sectors, while F10x has 1K sectors, another enhancements would be to perform the operation sector by sector.
All this this needs time, work, testing... I have other priorities right now!
-
Hi!
https://ibb.co/ySCPrSV
https://ibb.co/n7Km9W1
I didn't find any pictures of my board in the github repo.
It's a KSGER HW v2.1S (fw:2.10)
I guess it's the same pinout for the ST-LINK in the upper left corner as the rest of them?
And is that a STM32F103 C8T6 or CBT6? (I guess it's 8?)
Edit: Also I just noticed that the pin holes for the STM32 is too narrow for the 4 stlink wires to reside next to eachother:-/
-
Check compatibility section:
4-pin display = v2.x, use that.
It's a C8, but doesn't really matter.
Check programming section.
From left to right:
VCC, SWDCLK, SWDIO, GND.
-
Hi,
Struggling with a jbc clone handle on Ksger board V2.
The c245 handle verified working on a Aixiun T3A soldering station.
Ksger board display says 320c but is only around 200c
If I heat the c245 tip the opamp output ranges 0-800mv for 30c-400c.
Using the latest firmware and board verified working with t12 tips.
Have tried two boards, same result.
Am I missing something here? should I reread the documentation?
I have linked in a video.
Any help most appreciated.
https://youtube.com/shorts/ZkH15hy_oqY
Thanks
-
Hi,
Struggling with a jbc clone handle on Ksger board V2.
The c245 handle verified working on a Aixiun T3A soldering station.
Ksger board display says 320c but is only around 200c
If I heat the c245 tip the opamp output ranges 0-800mv for 30c-400c.
Using the latest firmware and board verified working with t12 tips.
Have tried two boards, same result.
Am I missing something here? should I reread the documentation?
I have linked in a video.
Any help most appreciated.
https://youtube.com/shorts/ZkH15hy_oqY
Thanks
A few things after watching the video:
1) Power supply voltage's sagging significantly under load. IDK if it's just a quick and dirty test setup or not but if you want a realistic idea of performance you need PSU, cables and connections that can handle the current drawn.
2) Let me be Captain Obvious there but is your tip even calibrated?
3) If after fixing point 1, you still get those massive overshoot and oscillations then PID settings should be adjusted.
-
Ok thanks.
I get similar results on a 24v 10amp supply.
I assumed it would work with the default settings.
I'll calibrate the tip and check the pid numbers.
Cheers
-
KocsisV, I've been trying (again) passing variables to the Makefile.
It should be possible to declare them in the Environment (Under Properties... C/C++ Build).
Ex. Declare "BOARD_TYPE", with content "KSGER_V1_5", etc, for each build profile.
Then in the Makefile:
clean :
ifeq ($(BOARD_TYPE), KSGER_V1_5)
clean_KSGER_V1_5
else ifeq ($(BOARD_TYPE), KSGER_V2)
clean_KSGER_V2
else ifeq ($(BOARD_TYPE), KSGER_V3)
clean_KSGER_V3
else ifeq ($(BOARD_TYPE), Quicko_STM32F103)
clean_Quicko_STM32F103
else ifeq ($(BOARD_TYPE), Quicko_STM32F072)
clean_Quicko_STM32F072
else
@echo "clean: BOARD_TYPE not defined"
endif
all :
ifeq ($(BOARD_TYPE), KSGER_V1_5)
./boards/KSGER_V1_5/src/generated
else ifeq ($(BOARD_TYPE), KSGER_V2)
./boards/KSGER_V2/src/generated
else ifeq ($(BOARD_TYPE), KSGER_V3)
./boards/KSGER_V3/src/generated
else ifeq ($(BOARD_TYPE), Quicko_STM32F103)
./boards/Quicko_STM32F103/src/generated
else ifeq ($(BOARD_TYPE), Quicko_STM32F072)
./boards/Quicko_STM32F072/src/generated
else
@echo "all: BOARD_TYPE not defined"
endif
It should fix the unecessary code generation, but so far, everything I tried has failed, it's not getting the variable.
I'm always getting "BOARD_TYPE not defined".
I've seen a lot of examples in Eclipse, so I guess it's not a Makefile version problem?
Any ideas? I feel like we're getting close to make it work!
Ah, I forgot: Please use spaces instead tabs. Eclipse settings, Editor... I'm pretty sure you know all that! :)
I had very nasty viewing issues with some browsers or editors, they used different spacing and the code looked like crap.
Just to keep the formatting nice. I use 2 spaces for everything, viewing was perfect in any plattform! :-+
-
Hi,
Struggling with a jbc clone handle on Ksger board V2.
The c245 handle verified working on a Aixiun T3A soldering station.
Ksger board display says 320c but is only around 200c
If I heat the c245 tip the opamp output ranges 0-800mv for 30c-400c.
Using the latest firmware and board verified working with t12 tips.
Have tried two boards, same result.
Am I missing something here? should I reread the documentation?
I have linked in a video.
Any help most appreciated.
https://youtube.com/shorts/ZkH15hy_oqY
Thanks
A few things after watching the video:
1) Power supply voltage's sagging significantly under load. IDK if it's just a quick and dirty test setup or not but if you want a realistic idea of performance you need PSU, cables and connections that can handle the current drawn.
2) Let me be Captain Obvious there but is your tip even calibrated?
3) If after fixing point 1, you still get those massive overshoot and oscillations then PID settings should be adjusted.
Also:
4) You made the alteration to the KSGER Board? I believe there is a trace that needs to be cut and perhaps a resistor removed?
-
Hi,
Struggling with a jbc clone handle on Ksger board V2.
The c245 handle verified working on a Aixiun T3A soldering station.
Ksger board display says 320c but is only around 200c
If I heat the c245 tip the opamp output ranges 0-800mv for 30c-400c.
Using the latest firmware and board verified working with t12 tips.
Have tried two boards, same result.
Am I missing something here? should I reread the documentation?
I have linked in a video.
Any help most appreciated.
https://youtube.com/shorts/ZkH15hy_oqY
Thanks
1. Calibrate not only the T12 stingers, but also the C245 - each profile separately. I have very different values on T12 and C245.
2. In the photo, your power supply is only 17 volts - first make a power supply.
P.S. Try it with a power supply from Aixun. I did that. I also have an Aixun T3A - with its power supply, such a controller with firmware from David works well.
-
There must be a big problem with human eyesight, I don't know how to make it more clear that it ALWAYS needs calibration, default is lower for safety, mainly because in 2 years only 5-6 people have reported calibrations, that's nowhere close enough.
Isn't going to magically improve with the actual fly-by technique:
- "I have a problem, urgent help"
- "Bye until my next problem"
This lazy behavior repeating over and over is really tiresome, PMs and messages whose matters are properly explained in the Readme will be ignored from now!
-
KocsisV, I've been trying (again) passing variables to the Makefile.
It should be possible to declare them in the Environment (Under Properties... C/C++ Build).
It is possible to pass env variables, that's not the issue at all. (See the examples later.)
The issue is still the when it gets executed and the what the eclipse internal builder state is. I explained in this post why its not working: https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4189318/#msg4189318 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4189318/#msg4189318)
To provide examples:
https://github.com/KocsisV/stm32_soldering_iron_controller/tree/d8783b6743ef06fe6ce97db9e0d481d5a00da460 (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/d8783b6743ef06fe6ce97db9e0d481d5a00da460)
In this the code gen is called for each configuration separately -> it only runs for that specific hardware. It runs in the pre-build stage. The internal eclipse builder already generated the makefiles at this stage, it looked through the project and picked out the specified source files and include directories. Since the generated files were not yet present (assuming a clean build), the makefile what eclipse generated will not contain the generated files, and it is not possible to add them anymore. The targets are already "created".
To see where this is called: right click on the main project, properties, C/C++ Build, Settings, Build Steps tab, pre-build steps. This pre-build step is invoked by the already generated makefile.
It is also possible to extend the generated makefile by a "makefile.init" file in the project root but that basically achieves the same thing.
https://github.com/KocsisV/stm32_soldering_iron_controller/tree/49ad550da55d91a381d962cc7e79dcc9e60b1c65 (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/49ad550da55d91a381d962cc7e79dcc9e60b1c65)
In this the code gen runs before eclipse creates its makefiles -> the generated files will be included in the build. The issue with this is that this builder only runs once, regardless if you ask it to build one configuration or all. And from the variables eclipse provides its not possible to determine if its trying to build a single configuration or all of them. So it works if you only build one configuration at a time, but not for build all.
To see where this is done: right click on the main project, properties, Builders, there I added a new builder named GenerateSources, click on that and on the right click edit. Here it can be specified when to run this builder, what to invoke, etc etc. On the tool arguments section you can see how I pass the "active configuration" into make.
https://github.com/KocsisV/stm32_soldering_iron_controller/tree/02f01120f2284c266f30d4d062747c54ba6679ff (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/02f01120f2284c266f30d4d062747c54ba6679ff)
This one is almost the same as the previous, difference is that instead of the main project containing the builder which runs before eclipse's internal builder's makefile generation, each target hardware project has its own builder. The issue similar to the previous, building one configuration works, building all does not. But it fails because of an entirety different reason: CDT bug not triggering the dependency's build.
To see where this is done: same as before, when you import the main project click "search for nested projects", then you will see a project for each hw target. Right click props... on the hw projects.
The main project depends on these hw projects, to see: open the properties of the main project, C/C++ General, Paths and Symbols, References tab. There you will see that each configuration refers to the required hardware project's other config.
clean :
ifeq ($(BOARD_TYPE), KSGER_V1_5)
As I said, don't use IFs :) Forget that "IF" exists. Forget any and every conditional operator, loop, etc. Make is a declarative language, you don't define "code to run" you define targets and relationships between them. Construct the commands for a specific rule to depend on the target being built. See the current makefile
for codegen for example: https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile (https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile). There is no "IF" in lines 24-29, yet it runs all the codegen. If in the future another hw target is added, these lines don't need to be changed at all, only the "all" target need to be modified with to add a new dependency, that the "all" target needs that new ./boards/XXXX/src/generated file. The rule between lines 24-29 will match this new name too.
So simply
clean : $(BOARD_TYPE)then another target with the name KSGER_V1_5 in this case does the same as your if-elif chain. And the if-elif chain will not work in most cases anyways, due to make assumes its a single target, it does not know it depends on env vars (and it builds multiple targets) if you don't include it in the target name or dependencies. You can even get rid of the concrete target name completely by constructing the rule in a way that the name is used to select the target in all cases. Eg
clean_% :
... instructions to clean on on $* ($* will equal %) ...
(Btw don't do this "clean : $(BOARD_TYPE)" thing, because this has the same issue as having a single target conditionally building something, use "clean_$(BOARD_TYPE) : " instead.)
Please use spaces instead tabs.
Ups. I already have eclipse configured to use spaces instead of tabs (and display tabs as 2 spaces wide). Is there any in the PR you just merged, or is this only an issue in the makefiles?
-
Working ok now.
Set PW multiplier to 20.
Thanks
-
Set PW multiplier to 20.
That's one of the reasons PWM multiplier exists.
Very long pulses exceeding rated power will quickly trip the power supply protection, but with the multiplier it divides the main PWM cycle into several small ones, it's less rude to the supply and might hold the power.
You'll hear the buzzing sound due the increased frequency, but that's the only way not requiring to buy a new power supply.
(Btw don't do this "clean : $(BOARD_TYPE)" thing, because this has the same issue as having a single target conditionally building something, use "clean_$(BOARD_TYPE) : " instead.)
(...)
Is there any in the PR you just merged, or is this only an issue in the makefiles?
I sad it for a reason, I remember opening something, finding it full of tabs... don't remember now, perhabs the Makefile?
Look at my older code... beginning of 2021 or so, when I realized the browser didn't like the tabs! Spent a lot of time fixing the formatting.
So I told you just in case, before you write anything huge :)
Edit: It seems my STM32 IDE uses tabs in the Makefile, but not in c/h files. Probably the formatting has rules applying only to certain files.
I found Eclipse Configurations to be extremely delicate. Selecting all profiles at once, then adding some variable or command caused all sort of issues.
At some point the Quicko F072 was taking the STM32_F1xx library, although the includes were right.
Cleared the include paths, completely empty, and it kept taking the paths, somehow it was taking the includes from other config.
The project became unusable, not even clearing the configurations and making new ones. Had to restore it several times!
When I modified profile-by-profile, things started to work.
I noticed the external builder only sees global variables... I thought this simple solution, seems working nicely here.
- Declare "BoardName" var in Environment (KSGER_V2, etc)
- Pre-build step (Use a temporal file to store the board name):
sh -c "echo ${BoardName} >../mcu/current"
- Modify the Makefile (Get the board from the file):
BOARD := $(shell sh -c "cat ./mcu/current")
clean :clean_$(BOARD);
all : ./boards/$(BOARD)/src/generated;
It's a lot faster now!
I made a PR in your github so you can test it.
-
Thanks, have sent a beer for you.
-
perhabs the Makefile?
That is definitely full of tabs :)
Spent a lot of time fixing the formatting.
You know that there are automatic tools for this right ;) ?
I have not yet checked, but I plan to configure and activate either the build in formatter in eclipse, or the clang formatter if this eclipse build supports that. Then you don't need to care about formatting at all. You can just spit out code without any formatting, not even new lines, once you save the file it will automatically format it. Also this will make formatting consistent in all files and for all committers.
Eclipse Configurations to be extremely delicate
Sure, its easy to break them, they are misleading a lot of the times and totally does not do what you expect them to. At least in case of the build pipeline its quickly reveals itself :)
external builder
The (external) builders only run once! Even if you ask it to build all configurations, it will be only executed one time and the active configuration set to the one you currently selected in the GUI. I have no idea how the built in builder receives the state that it shall build the makefiles then run them for all targets if it does it with simple builtin vars. Probably since its a plugin it can access variables not normally visible.
The env vars what you can define under the c/c++ build / environment settings is for the CDT Builder, this is why the "external program" does not see it. The "c/c++ build" only appears if you have the CDT Builder configured and enabled. That whole menu is supplied by it, the settings under that only affect it, nothing else.
You can supply arguments to custom builders under the arguments textbox. Click on the variables button, it will show you what can be passed to it. Eg the active configuration's name.
You can instead of passing the board as an env var, you can simply instead of asking make to build the "all" target, you can just as well ask it to build the "./boards/XXX/src/generated" target where you substitute XXX within eclipse with the active config. (Instead of calling "make all" you can just as well call "make ./boards/KSGER_V1_5/src/generated".)
But this will still only trigger once. And keep in mind, if you don't clean up the leftovers from the previous build before the next, then the CDT builder will include those and you will think that its working, but if you manually delete these files, refresh the project and try again it will fail.
I think you are currently trying to re-create this https://github.com/KocsisV/stm32_soldering_iron_controller/tree/49ad550da55d91a381d962cc7e79dcc9e60b1c65 (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/49ad550da55d91a381d962cc7e79dcc9e60b1c65).
I passed the active config via arguments to make (see attached image). But as I said the builder is only triggered once, so "build all" will not work. And in all its wisdom, eclipse calls the "clean" builder after a "build all" for some reason...
-
Damn, I see. So, we must choose between being able to build all, or doing one at a time manually?Just ignore my PR then!
Thanks, islcom! :-+
-
I made a PR in your github so you can test it.
While I made my previous comment you seem to made the PRs!
I tested it and it does not work sadly. The temporary file you create is created after the external build tool is executed. So when the GenerateSources builder runs the file is not there. As I said previously it is important when the builder runs and what state the build pipeline is.
This also results in a complete obliteration of all files within a repository during clean. I will fix this issue, this is the second time it happens... :palm: Since the "./boards/$*/src/Core/Inc" does not exist the "cd" command fails, and "find . -not -name 'GENERATED_FILES_DO_NOT_MODIFY' -delete" deletes all files in the repository...
To test it on your machine:
- in your git client click "view ignored files" and delete them all, or clone the repository into a new place so no /mcu/current file exists, nor any previously generated files
- switch off the "Clean" external builder :)
- try build all (don't try to bulid anything else beforehand)
-
Damn, I see. So, we must choose between being able to build all, or doing one at a time manually?Just ignore my PR then!
Thanks, islcom! :-+
Yes, sadly this is the case. On the upside it is incremental, so if you are working on a single target/config it will not re-run codegen if you don't touch the template files or the IOC files. If you touch the IOC files it will only re-gen that single one. If you touch the main.c/h templates or the interrupt handler templates then it will re-run codegen for all hw targets.
Edit:
What I forgot is you don't need to create PRs, I have my repository set up in a way that it fetches the changes from your repo too. Just tell me which branch to check out. (see pic)
-
It's clear here who knows the stuff! Nope, ignore the PR, it's fine!
-
I tried to change the tabs to spaces in the makefile, and now I remember why its full of tabs: it needs a tab before every command of a rule, spaces does not work.
(It's not often that I work with makefiles, I usually use cmake and that does not care.)
-
Just the makefile isn't a problem!
Was more if you started to code something large and the editor was using tabs.
I know that from Python too... Got all kind of errors due using spaces instead tabs. Hate so much such silly sintax requirements!
-
Can't find any tabs (that I added) in any of the source files. Doing a project wide search the only ones I found are either from auto generated files, part of an external lib, and a few in the widgets.h, display.h files.
Python accepts spaces :) Actually it is preferred to use spaces there too. Only rule is that instead of using explicit scope markers ({} in c) it uses the indentation instead.
-
https://www.youtube.com/watch?v=SsoOG6ZeyUI (https://www.youtube.com/watch?v=SsoOG6ZeyUI)
-
That's very serious stuff, joking about it might get you and/or your family injured or killed, don't mess with programmers :-DD
-
I have a K-type bit, but I can't calibrate it because it tells me the delta is too high.
I should proceed manually but I don't quite understand how to do it. Could you please help me?
thanks
-
Basically the difference between displayed temps and measured temps is more than 50°C therefor calibration can't succeed. You should change the values for cal250 and cal400 (both or either one depending on your situation) in the calibration > settings menu to something more realistic for your stations. Different stations use different opamps and tip brands are all over the place so a bit a DIY is expected there.
For example, if you can't do the 250°C step because it's too hot (say you measure 420°C), you should lower the current cal250 value by 400 (if it was 1500, set it to 1100). If it's too cold, increase it by ~200 and try again. Just don't be to heavy handed when you increase the value as you don't want a red glowing tip.
-
trisonic, isn't it correctly explained in the instructions? If there's any doubt just let me know.
CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now.
START
Requires a tip thermometer (e.g. Hakko FG-100 or similar). Calibrates the current tip at temperatures of 250 and 400°C.
Wait for tip temperature to settle (When the thermomether reading stops moving), it can take up to 20 seconds in some cases.
Then enter temperature as measured by the thermometer for each step.
If the entered temperature is more than 50ºC away from the target, the process will be aborted and you will have to adjust it manually.
This values have nothing to do with the Tip Settings calibration values! These are for the tip, while this ones are only used for the calibration process.
You can cancel the process at any time by clicking the STOP button.
SETTINGS
Here you can manually adjust the default calibration values, normally this needs to be done only once.
Cal 250 depends on Zero set, and Cal 400 depends on Cal 250, so if you're changing this, you must follow the correct order:
Zero set (Sampling->Captured) -> Cal 250 -> Cal 400 -> Save
If by any means the 250°C calibration needs to go higher than 400°C value, increase 400°C value carefully and repeat 250°C calibration.
For best accuracy, always calibrate 250°C if CAL_Zero value was changed, and always calibrate 400°C if 250°C value was changed.
Zero set
Calibrates the zero offset of the amplifier. You must have inserted a completely cold tip, or the calibration result will be wrong.
This widgets has 3 states than change when clicking on it:
Zero set: Shows the current value in the system (No changes).
Sampling: Shows the ADC value in real time.
Captured: Shows the captured value and applies it.
To calibrate the zero offset, you must set this mode before moving to the next step.
Zero set value is applied system-wide, not per-tip calibrated.
If you already know your tip calibration values, you can adjust only this parameter and save, then restore the tip calibration values.
Cal 250ºC
Cal 400ºC
Adjusts the value for 250/400°C. When editing this widget, the power is enabled and the value applied in real time.
Move in small steps until the thermometer matches the target temperature
SAVE
Return to calibration menu saving changes.
CANCEL
Return to calibration menu discarding changes.
BACK
Return to system menu.
-
trisonic, isn't it correctly explained in the instructions? If there's any doubt just let me know.
Hi
The calibration process is clear to me.
But when the warning and the request to change the "delta" manually appeared on my display, I thought there was some parameter somewhere that was just called "delta"!
By the way, I found the "zero set" to be a bit tricky.
How do I put a cold tip (at room temperature) during this process?
Without a tip the station goes into error and won't let me access this menu.
Thank you
-
Read the first line.
Power is removed when entering the calibration menu.
In calibration settings, power is only enabled when editing cal 250 and 400.
Delta means "difference".
So delta between expected 250 and read 320 is 70.
Might edit the name... If it fits..
-
Read the first line.
Power is removed when entering the calibration menu.
In calibration settings, power is only enabled when editing cal 250 and 400.
Delta means "difference".
So delta between expected 250 and read 320 is 70.
Might edit the name... If it fits..
The word "delta" could be substituted in the error message but it could be a minor fix. In general by reasoning a little bit it is understood.
However, I would like to suggest this in the calibration procedure:
In my opinion, to start a proper calibration procedure, you should start it without the tip inserted: this is because as soon as you turn the station on, it immediately heats the tip (rightly so) and you should wait for it to cool down.
So I would put the tip in from the bench only after starting the zero procedure from the menu (so you can be sure to take a tip at room temperature).
The problem is that: turned on the station without the tip inserted, when I go to the "settings" menu (from the "calibration" menu) I get this error (it doesn't always appear): "ERROR DETECTED Aborting..." and I can't zero.
What do you think?
Thanks
-
What is not clear about that yet?
CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now.
BEFORE entering any sub-menu (START, SETTINGS).
You can start your station without tip, enter CALIBRATION, then insert and calibrate each one.
You cannot enter START or SETTINGS without tip, doesn't make any sense, and will cause huge readings due the input floating, about 600-700ºC, that's how it detects the tip.
MAIN SETTINGS->CALIBRATION (Insert tip now)-> START/SETTINGS
Simple as that.
-
What is not clear about that yet?
CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now.
if this sentence would be followed by this explanation, everything would be a little bit easier.
BEFORE entering any sub-menu (START, SETTINGS).
You can start your station without tip, enter CALIBRATION, then insert and calibrate each one.
You cannot enter START or SETTINGS without tip, doesn't make any sense, and will cause huge readings due the input floating, about 600-700ºC, that's how it detects the tip.
MAIN SETTINGS->CALIBRATION (Insert tip now)-> START/SETTINGS
Simple as that.
-
CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now (Before entering any sub-menu).
You can start your station without tip to prevent it from heating up, then enter CALIBRATION, insert the tip and calibrate it.
Using a cold tip is only critical for the amplifier offset calibration (SETTINGS). If normal calibration works (START), or zero set is already adjusted, it's not required.
START and SETTINGS menus will show warning message if the tip was removed or not detected and then return to main calibration menu.
Clearer now?
-
CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now (Before entering any sub-menu).
You can start your station without tip to prevent it from heating up, then enter CALIBRATION, insert the tip and calibrate it.
Using a cold tip is only critical for the amplifier offset calibration (SETTINGS). If normal calibration works (START), or zero set is already adjusted, it's not required.
START and SETTINGS menus will show warning message if the tip was removed or not detected and then return to main calibration menu.
Clearer now?
Definitely!
I would add this state diagram that sums it all up:
(Station power on without inserted tip) -> MAIN SETTINGS -> CALIBRATION (insert tip to be calibrated at room temperature) -> START/SETTINGS -> start calibration operations:
1) zero calibration
2 & 3) 250° and 400° calibration
End
-
Hi!
No matter what I do, It won't connect.
20:23:50 : ST-LINK SN : 09130308C215303030303032
20:23:50 : ST-LINK FW : V2J39S7
20:23:50 : Board : --
20:23:50 : Voltage : 3.13V
20:23:50 : Error: No STM32 target found!
I get this all the time. I have checked all the pins and they are correct.
I've tried to connect the RST pin connected to the stlink and I've tried without, but then shorting the cap that goes to that pin. (as the instructions say) And both of the above to no avail.
The above error message comes immediately when I press the connect button.
As mentioned I have checked every pin with a multimeter so I know the pins are correct and not shorted anywhere.
I've also tried suplying the voltage from both the stlink or from the ksger powersupply.
Any ideas would be welcome.
KSGER v2.1S
-
Is it a real stm32? Show pictures of your board and your connection.
-
Is it a real stm32? Show pictures of your board and your connection.
I checked my soldered connector one more time and found a cold joint. That was it. I have now flashed your CFW without the rst connection :-+
Thanx for all your work bringing a much improved fw for all our solder stations :clap:
-
David, you deleted the old binary files from the github, but the new ones did not appear there. :-[
-
David, you deleted the old binary files from the github, but the new ones did not appear there. :-[
They are no longer thrown into the source code, they are now properly uploaded in the releases section instead: https://github.com/deividAlfa/stm32_soldering_iron_controller/releases
-
finally got cheap oscil imitation
it says this
-
David, you deleted the old binary files from the github, but the new ones did not appear there. :-[
It's described in the readme, go to Releases :-+
Now it's pretty stable, it makes sense, and I can easily add a changelog.
Previously there were too frequent updates, I didn't want to make 500 releases :D
-
Am I too late for this super cool topic? I can't find any store selling any STM32 version. They changed to CKS or MM chip. |O |O |O
-
Is there actually any source where it is still possible to get a controller which works on the KSGER board? I've ordered a second station about a week ago which will, for sure, come with this "MM32" controller. And to be honest I did not expect it to be THAT difficult to get a replacement controller for it. I still have a ST Nucleo board which seems to have a compatible controller on it. Maybe I'll just "borrow" this one and replace it as soon as chips are in stock again...
Can someone tell me how heat sensitive the OLED screens are? Should I desolder it before attempting to desolder the MM32 with hot air?
-
Not that sensitive as long as you don't blast the screen in the face. If unsure, you can reflow the MCU's pins with leaded solder to lower the melting point and deflect heat away from the screen with aluminium foil. These boards are thin and light on copper, they don't take much heat before solder starts flowing.
-
CKS32 are fine, the incompatibles are MM32 and CH32.
Just wrap the screen with something to ensure it doesn't get an accidental hot blast, other than that, replacing the mcu is easy, specially the 48pin packages.
-
The KSGER 3.1 seems to have an 64 pin MCU. Did actually someone test if the MM32 does work somehow? I'll get this station in a few weeks, can absolutely not find any source for a compatible 64 pin MCU and so would have this thing for testing purposes. I guess we will have to deal with this clone MCU for quite a while (and maybe even if the STM gets available again as probably MM32 is much cheaper). So it may be worth a try to find a solution to use this MCU.
I had a look at the Nucleo board that I hoped can act as a donor here. But at first I did not look closely at the MCU. It unfortunately is not F103 but a STM32L053R8T6. That's not compatible, right?
Would it actually be possible to bodge wire any other STM32F103 in there? I have a few STM32F103CBT6. That's a 48 pin MCU, so won't fit directly. But if there are not too many connections this should be possible to patch in. Is there a pin list somewhere so I can check how to move the needed pins? No, I don't have the ST IDE and I can't install it.
-
I asked on https://quicko.aliexpress.com/store/2954088 (https://quicko.aliexpress.com/store/2954088),
they said:
- only T12-955 V2.x model has STM32 IC
- T12-958 V3.x model uses MM32, even they still write stm32 on title >:(
- other models use STC
Do you find any store selling STM32 or CKS32 V3.x? I can replace the IC if it has CKS.
If it is hard to find V3.x model using STM32/CKS, I think I have to go with T12-955 V2.x. Any other advice? Thanks.
-
I bought this soldering station. It used STM32F103:
https://aliexpress.ru/item/1005003763630515.html
What processor now - I do not know. You have to ask about it.
-
If it is hard to find V3.x model using STM32/CKS, I think I have to go with T12-955 V2.x. Any other advice? Thanks.
Same for me. And I actually got fooled by the description on Aliexpress where they still say it is "STM32". Still have to wait what I'll get but I'm almost 100% sure it will be MM32.
I had a closer look at the schematics and as the instructions on DavidAlfa's GitHub say that it doesn't really matter which F103 is used as long it has enough flash I think I'll be able to mod my 48pin chip in there. I'll at least try that as, to be honest, I really enjoy doing such fine soldering stuff ;D
It seems to be totally possible to get STM32F103C8T6 based development boards. When searching, I even had the choice if I want to have the original STM IC or the CKS clone chip. As the CKS chip is also OK, I think this is a possible supply of chips to mod stations coming with unsupported chips. That's a bit more expensive than just getting the chip but in combination still way cheaper than any Hakko station.
And if we now (probably) have to do modding anyway in future, then I'm wondering if it would be possible to get one of the cheap STC based stations, throw out the chip, add ribbon cable in its position and wire the other end of the ribbon to a bluepill dev board. Maybe I should try to find the cheapest possible STC based T12 station to trace out the schematics to see if it is "close enough" that it works as "external circuit" around a STM32 dev board with DavidAlfa's firmware. I don't really need a third station but probably that could be fun to try ;)
-
looks like 2 buck per 1 cks chip. maybe i even buy one for test purposes.
-
If it is hard to find V3.x model using STM32/CKS, I think I have to go with T12-955 V2.x. Any other advice? Thanks.
...
I had a closer look at the schematics and as the instructions on DavidAlfa's GitHub say that it doesn't really matter which F103 is used as long it has enough flash I think I'll be able to mod my 48pin chip in there. I'll at least try that as, to be honest, I really enjoy doing such fine soldering stuff ;D
...
And if we now (probably) have to do modding anyway in future, then I'm wondering if it would be possible to get one of the cheap STC based stations, throw out the chip, add ribbon cable in its position and wire the other end of the ribbon to a bluepill dev board. Maybe I should try to find the cheapest possible STC based T12 station to trace out the schematics to see if it is "close enough" that it works as "external circuit" around a STM32 dev board with DavidAlfa's firmware. I don't really need a third station but probably that could be fun to try ;)
Warning: it's a MM32SPIN27PF. That's a Cortex M0, so it won't be compatible with this CFW.
There isn't a single ksger with a M0 mcu, all use STM32 F1 series (cortex M3).
Porting it would be lot of work for just a single board.
I recommend replacing it with a stm32F103C8 or CB, ex. from here:
https://www.aliexpress.com/item/1005001953737425.html (https://www.aliexpress.com/item/1005001953737425.html)
Might be a clone, but most work ok. Only CH32F have issues in this FW (ADC reading random values).
Does DavidAlfa means that we can get directly replace a MM32 with STM32F1?
I have here an image of MM32 of KSGER V3.1. At first, I have to compare the pinout on PCB with KSGER/Quickco PCB.
-
This board actually does not look like a KSGER 3.1. Now I'm curious what I'll receive. I hoped for a board with 64 pin IC, just like the V3.1 I'm used to. Advantage of your board: The available STM32 ICs can be just "swapped in". Disadvantage: This does not match any photo of known boards that I've found so far.
That's what my KSGER 3.1 looks like: https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/f103-back-hi-res.jpg
If they designed a completely new board, then it may be tricky to find out which station this actually matches now. Can you create a photo of the full board and post it here?
Edit: https://github.com/deividAlfa/stm32_soldering_iron_controller says that you can find out what type of board you have by looking at the display connection. Yours is 6 pin, so probably a "v3.x". And I also found your board. The seller seems to call it "V2.01": https://de.aliexpress.com/item/4000104741034.html
-
The latest QUICKO firmware is a huge improvement on my DXCHMEI T12-A, even the OLED display looks better/more vibrant.
These tip settings make it run perfect
Kp: 120
Ki: 50
Kd: 20
Imax: 0.5
Imin: 0
I installed a JST header so it can be flashed without opening it
-
Does DavidAlfa means that we can get directly replace a MM32 with STM32F1?
Yes, the board layout didn't change, you can perfectly replace the mm32 with a STM32F103.
Other F1 series, not sure, I made the firmware specifically for the 103.
-
I have recently purchased a KSGER 3.1 ver of the soldering station and am curious about this custom firmware project. I read through the read-me files on the GitHub link and cannot see what improvements have been made using the custom firmware as opposed to the mfg original version. I apologize if I have overlooked the obvious. Would someone please enlighten me?
Thanks - Jim
-
I have recently purchased a KSGER 3.1 ver of the soldering station and am curious about this custom firmware project. I read through the read-me files on the GitHub link and cannot see what improvements have been made using the custom firmware as opposed to the mfg original version. I apologize if I have overlooked the obvious. Would someone please enlighten me?
Thanks - Jim
This video is rather old, there have been many improvements since then, but it will give you and idea of the features:
https://www.youtube.com/watch?v=x9ohNL2J2lU (https://www.youtube.com/watch?v=x9ohNL2J2lU)
-
Hot glue inside of it might not be the best idea :)
I wired mine out to a DB9 alongside of a few gpios + power.
Btw, because you have a battery installed you can enable the "HAS_BATTERY" option in the config.h to have the option to remember the last used tip temperature.
-
This board actually does not look like a KSGER 3.1. Now I'm curious what I'll receive. I hoped for a board with 64 pin IC, just like the V3.1 I'm used to. Advantage of your board: The available STM32 ICs can be just "swapped in". Disadvantage: This does not match any photo of known boards that I've found so far.
That's what my KSGER 3.1 looks like: https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/f103-back-hi-res.jpg
If they designed a completely new board, then it may be tricky to find out which station this actually matches now. Can you create a photo of the full board and post it here?
Edit: https://github.com/deividAlfa/stm32_soldering_iron_controller says that you can find out what type of board you have by looking at the display connection. Yours is 6 pin, so probably a "v3.x". And I also found your board. The seller seems to call it "V2.01": https://de.aliexpress.com/item/4000104741034.html
It prints T12-V20 in the front. But it has 6 pin for OLED SPI. Anyway, I will give it a try.
Does DavidAlfa means that we can get directly replace a MM32 with STM32F1?
Yes, the board layout didn't change, you can perfectly replace the mm32 with a STM32F103.
Other F1 series, not sure, I made the firmware specifically for the 103.
Thanks for confirming.
looks like 2 buck per 1 cks chip. maybe i even buy one for test purposes.
I will try to swap the IC with a CKS (I do not have an STM32F1 T.T). Hope it can survice after the surgery.
-
Hi!
After flashing the latest (v1.01) BIN to a Quicko T12 with STM32F072 I get a "HARD FAULT SYSTEM HALTET Use btn to reset" error message on the display of the soldering station. Pressing the button results in the same error message. I've also tried v1.0, but there seems to be no difference.
Any ideas?
For the moment I'm back to a version from Oct 28. 2021, which works fine for me.
-
Does this one have the same issue as well? Can't test the F072 anymore.
-
Btw, because you have a battery installed you can enable the "HAS_BATTERY" option in the config.h to have the option to remember the last used tip temperature.
What are the chances of adding HAS_BATTERY toggle in Iron settings?
-
Does this one have the same issue as well?
Well, not the same... but a blank screen and no visible function.
-
I've tested some older builds. The latest .bin which works on my Quicko STM32F072 ist the one from Jun 2 2022.
-
I've received my station some days ago and to my surprise it has a STM32 inside.
There is no guarantee, but I've ordered this one: https://de.aliexpress.com/item/4000055007842.html in the variant without any handle (I don't like that "screw on" handle and ordered another handle separately). Mine came with a "real" STM32 MCU.
-
Is it working for everyone with F103 mcus? Ksger, Quicko, etc?
Edit: Mein bad! It seems I miss clicked the wrong folder und uploaded den Quicko F103 build.
Please re-download (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1534381) the zip file and try again!
-
It works ok.
-
Works great for my Ksger 1.5 with F103.
BTW, assuming HAS_BATTERY is set, is the selected tip also saved in backup registers or still written in flash? I remember KocsisV mentioning he could do that when you were discussing flash wear and now I'm wondering if the idea's been scrapped or implemented (or just on the todo list).
-
is the selected tip also saved in backup registers
Yes, the selected tip, last temperature and profile is saved to the backup registers. You have to enable the "remember x" options in the System settings (by default its disabled): https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/Readme_files/Operation.md#system (https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/Readme_files/Operation.md#system), scroll down to the "Remember last profile/tip/temp" description.
-
Nice, thanks :-+
-
Edit: Mein bad! It seems I miss clicked the wrong folder und uploaded den Quicko F103 build.
Please re-download (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1534381) the zip file and try again!
Ok, now there's the "HARD FAULT SYSTEM HALTET..." message again.
-
Can you set up the development environment and debug the code by placing a breakpoint to the fault handler and providing a stack trace?
-
Pretty sure it's related to the tip number and settings partition increase, will make some tests later...
Edit: Try this
-
Sorry, but i get the error message again.
-
Can you set up the development environment and debug the code by placing a breakpoint to the fault handler and providing a stack trace?
Ok, i've setup the build environment and i'm be able to compile the code without errors[1]. For debuging, compiler optimization needs be turned on, but ist too late now... I'll take a look at it tomorrow.
[1] in "addon_switch_off_reminder_settings_screen.c" "#include "addon_SWITCH_OFF_REMINDER_settings_screen.h"" should be "#include "addon_switch_off_reminder_settings_screen.h"" otherwise the compiler didn't find that header file on my linux machine...
-
I've received my station some days ago and to my surprise it has a STM32 inside.
There is no guarantee, but I've ordered this one: https://de.aliexpress.com/item/4000055007842.html in the variant without any handle (I don't like that "screw on" handle and ordered another handle separately). Mine came with a "real" STM32 MCU.
That's surprising with a "real" STM32 !? a CKS under STM32 label?
-
I've received my station some days ago and to my surprise it has a STM32 inside.
There is no guarantee, but I've ordered this one: https://de.aliexpress.com/item/4000055007842.html in the variant without any handle (I don't like that "screw on" handle and ordered another handle separately). Mine came with a "real" STM32 MCU.
That's surprising with a "real" STM32 !? a CKS under STM32 label?
just a very old batch from dusty warehouse.
-
deividAlfa Delete old binaries ?
-
Why do you need them?
You still have the history:
ksger v1.5 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/9f4b7f9565344e30a6ce1394d28350f82089488b/BOARDS/KSGER/%5Bv1.5%5D/STM32F103_SSD1306/STM32SolderingStation.bin)
ksger v2 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/9f4b7f9565344e30a6ce1394d28350f82089488b/BOARDS/KSGER/%5Bv2%5D/STM32F101_SSD1306/STM32SolderingStation.bin)
ksger v3 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/9f4b7f9565344e30a6ce1394d28350f82089488b/BOARDS/KSGER/%5Bv3%5D/STM32F101_SSD1306/STM32SolderingStation.bin)
quicko f072 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/9f4b7f9565344e30a6ce1394d28350f82089488b/BOARDS/Quicko/STM32F072_SSD1306/STM32SolderingStation.bin)
quicko f103 (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/9f4b7f9565344e30a6ce1394d28350f82089488b/BOARDS/Quicko/STM32F103_SSD1306/STM32SolderingStation.bin)
-
Ups, I missed your post sorry.
Could be done, I added it to the todo list. Its not that "nice" if its an user selectable option during runtime, as it requires hardware initialization plus different behavior during startup. Plus if someone sets it to on but do not have a battery installed it will complain on every startup.
-
Is this F072 build still failing?
-
Well, as nobody is trying, I just added a link to the Jun 02 build, mentioning the issue in the Quicko F072 section of the Readme, use that for now.
-
I had some time to check out some of the newer builds, the "Switch off reminder" was a nice addition.
I updated the Swedish translation and checked so everything looked good on screen.
During this I think I found a bug: under Calibration/Settings, I can't set the Zero if the language is set to Swedish or Russian.
When pressing the button the text just flashes briefly and the "zero" is not measured or updated.
This appear to have changed somewhere between the April 5 and April 30 builds. (April 5 build = OK, April 30 = NOT)
-
Thanks for reporting. The projects is almost stalled since I'm getting little to none feedback.
Testing every combination myself would take a lot of time, not realistic...
If anyone with a STM32F072 allows me to remotely debug the code, trying to find the current issue with it, would be nice!
AndyC, not a bug, it's intentional to make these people life's harder, that's my xenophobia kicking in :D.
Confirmed here, so strange the language affects the program behaviour, shouldn't at all, it's just an array of text strings :wtf:.
Will check it!
Edit:I think I got it. It worked removing optimizations, so it had to be some undefined behavior.
The reserved char array for the zero string was 16 bytes long because I thought is as normal ASCII, forgetting special chars use 2 bytes (unicode/UTF-8), so it was overflowing and writing over other variables.
Edit2: v1.02 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.02) Released. Should be working now.
-
Perhabs someone can help here.
I want to debug the stack when a hardfault happens, so I can show the program counter in the display.
That way I could check the map file disassembly and see where it's crashing, greatly easing the debugging process, like currently happenning with Quicko STM32F072.
I can also read SCB->BFAR, thus easily checking if an invalid address was accessed.
This seems interesting:
https://community.st.com/s/question/0D50X0000BxwhEhSQI/my-stm32h743vi-application-runs-to-a-debug-instruction-in-the-startup-code
However the startup file is not happy with PROC and EXPORT lines. Perhabs a Keil-specific syntax?
HardFault_Handler\
PROC
EXPORT HardFault_Handler
; Determine correct stack
TST lr, #4
ITE EQ
MRSEQ R0, MSP ; Read MSP (Main)
MRSNE R0, PSP ; Read PSP (Process)
MOV R1, R4
MOV R2, R5
MOV R3, R6
EXTERN hard_fault_handler_c
B hard_fault_handler_c
ENDP ; sourcer32@gmail.com
The rest is plain easy, the custom HardFault handler is called and then you get the values.
-
Hi All, I'm new and just ran across this while looking for a new station. Is there an FAQ to help noobies like me decide what station to get, meaning... what works best with the custom firmware, and what the custom FW adds / fixes / tweaks .. and anything it doesnt have vs the stock FW?
For instance, I'm thinking I should choose between the Ksger v3.1s and the Quicko T12-958 as they 'seem' equal, but I cant really tell for sure. I found the attached chart for Quekoo station features posted on the web... would be cool to have a chart for the custom FW showing supported stations, and features / exceptions / etc.
-
Not really... latest versions are identical in any maker, basically KSGER v2-based. If you wish, post here your buying options and we'll check out.
I'd get whatever is cheaper, usually KSGERs are very overpriced while providing nothing better than any other Quicko/Quecoo/Handskit/etc, ex. this Handskit:
https://www.aliexpress.com/item/4000183089084.html (https://www.aliexpress.com/item/4000183089084.html)
You have user feedback running this FW sucessfully.
-
curious the difference between unit models which are 2.1 vs 3.1? Is 3.1 better in some way?
... looks like 5.1 is ARM chip, not STM.
The below Hanskit looks very inexpensive, does it have the STM chip we need?
https://de.aliexpress.com/item/3256803059979222.html?spm=a2g0o.productlist.0.0.5411943aSX5L18&algo_pvid=06a82cc7-ce7e-4feb-ab81-97457a03c570&algo_exp_id=06a82cc7-ce7e-4feb-ab81-97457a03c570-17&pdp_ext_f=%7B%22sku_id%22%3A%2212000027999230424%22%7D&pdp_npi=2%40dis%21USD%21%2119.93%21%21%21%21%21%402101d8b516589555676914081e4c27%2112000027999230424%21sea
-
Cheaper, but without power supply.
And nope, it doesn't use stm32, but STC, won't work.
The main differences between v2 and v3 is the screen type, spi vs i2c, and few circuitry differences, sometimes better and others worse, can't tell, there're a lot of variants.
There's no such ARM chips. ARM sells the cpu design, doesn't make chips.
Chips containing ARM technology usually also have ARM labeled, stm32 do.
-
Quecoo T12-959 with the 2.6" screen says ARM chip, seems confusing... https://de.aliexpress.com/item/3256803527117780.html?spm=a2g0o.productlist.0.0.5411943aSX5L18&algo_pvid=06a82cc7-ce7e-4feb-ab81-97457a03c570&algo_exp_id=06a82cc7-ce7e-4feb-ab81-97457a03c570-6&pdp_ext_f=%7B%22sku_id%22%3A%2212000026905474133%22%7D&pdp_npi=2%40dis%21USD%21%2157.21%21%21%21%21%21%402101d8b516589555676914081e4c27%2112000026905474133%21sea
I prefer a smaller unit requiring a separate power adapter -- easier to store, less potential issues (wall warts last a long time, and very easy to replace if they die) ... but looks like there are fewer options for that with the STM32.
-
That station won't work with this fw, read the firmware compatibility in GitHub!
Arm chip = Anything having arm CPU, but don't them trust too much, sometimes they don't even know what they're selling, anyways there're tons of microcontrollers containing arm CPU, stm32 is just one of them, just "ARM" doesn't mean it's compatible!
Always check the user feedback, often you'll find internal pictures:
(https://ae01.alicdn.com/kf/U18456f585b764f228ed7fbd6335c7824x.jpg)
The xm1008k6t6 seems to be a clone of stm32f030k6t6 (Not supported)
This is the cheapest stm32 mini I found:
https://a.aliexpress.com/_uZPMpb
But it's only 7eur less than the Handskit, I wouldn't buy that.
Also the cheap one you listed has 0.96" screen while the others use 1.3".
Before asking again, ensure to check compatibility in the firmware firmware GitHub page.
-
Perhabs someone can help here.
I want to debug the stack when a hardfault happens, so I can show the program counter in the display.
That way I could check the map file disassembly and see where it's crashing, greatly easing the debugging process, like currently happenning with Quicko STM32F072.
I can also read SCB->BFAR, thus easily checking if an invalid address was accessed.
This seems interesting:
https://community.st.com/s/question/0D50X0000BxwhEhSQI/my-stm32h743vi-application-runs-to-a-debug-instruction-in-the-startup-code (https://community.st.com/s/question/0D50X0000BxwhEhSQI/my-stm32h743vi-application-runs-to-a-debug-instruction-in-the-startup-code)
However the startup file is not happy with PROC and EXPORT lines. Perhabs a Keil-specific syntax?
HardFault_Handler\
PROC
EXPORT HardFault_Handler
; Determine correct stack
TST lr, #4
ITE EQ
MRSEQ R0, MSP ; Read MSP (Main)
MRSNE R0, PSP ; Read PSP (Process)
MOV R1, R4
MOV R2, R5
MOV R3, R6
EXTERN hard_fault_handler_c
B hard_fault_handler_c
ENDP ; sourcer32@gmail.com
The rest is plain easy, the custom HardFault handler is called and then you get the values.
Hi,
You can define a naked function HardFault_Handler in main.c to capture the stack pointer and then jump to a custom handler which does some extra things.
Refer to https://www.codeinsideout.com/blog/stm32/fault-handler/#fault-handler (https://www.codeinsideout.com/blog/stm32/fault-handler/#fault-handler)
-
Thanks for reporting. The projects is almost stalled since I'm getting little to none feedback.
sry. im still on october build. maybe its time for updating fw
-
vqtrong, I modified the startup file to call a custom hardfault vector, backup the registers, then call the main hardfault function.
Seems to be working nicely, I tried to access an illegal address, the PC showed the correct program position, while r3 showed the memory address I tried to access.
Won't be a miracle, but will give some hints.
Quicko F072 owners, try this one, when the hardfault happens take a picture of the display.
The PC address should tell where the error happenend in the code, can be easily check in the listing file, also attached.
-
vqtrong, I modified the startup file to call a custom hardfault vector, backup the registers, then call the main hardfault function.
Seems to be working nicely, I tried to access an illegal address, the PC showed the correct program position, while r3 showed the memory address I tried to access.
Won't be a miracle, but will give some hints.
Quicko F072 owners, try this one, when the hardfault happens take a picture of the display.
The PC address should tell where the error happenend in the code, can be easily check in the listing file, also attached.
You're super fast. I think the list files should be included beside the release bin files, because the mapping can be different in each release.
-
I know, they will be included!
But for now I didn't made any new release, only the attached Quicko STM32F072 which is the only one having issues.
-
Are there people who had bought the sequre MSS 12 t12 soldering station. ? Its with oled and had even a usb-c pd connector.
-
Edit: Atmel MCU, small display. Not supported.
https://www.youtube.com/watch?v=LgurDQmcjeA (https://www.youtube.com/watch?v=LgurDQmcjeA)
-
been away for a while sadly health news is not been good. its a long story. they basically told me i have stage 4 melanoma as it has now spread to the bone. they will be starting treatment in the next couple weeks
which is the most current firmware for this station? the ksger v3 (the github folders are a bit different then last time i checked them) im trying to keep my mind off things and messing with just all random things now since i have time to get some things built because im not going into the office at this time or a lot during treatment most likely. appreciate it.
-
been away for a while sadly health news is not been good. its a long story. they basically told me i have stage 4 melanoma as it has now spread to the bone. they will be starting treatment in the next couple weeks
which is the most current firmware for this station? the ksger v3 (the github folders are a bit different then last time i checked them) im trying to keep my mind off things and messing with just all random things now since i have time to get some things built because im not going into the office at this time or a lot during treatment most likely. appreciate it.
Sorry to hear about your health.
You can find the latest compiled firmware on the releases page: https://github.com/deividAlfa/stm32_soldering_iron_controller/releases
If you have a v3 with the original screen, you will want to choose the oled version.
-
Very sorry Mastershake, I really hope the treatment works, will be a long road but try to fight it all you can!
Yeah now it's in Releases.
All the best!
-
I just noticed that the "10pcs T12 Soldering Iron Tips Set" on FlashDeal at Banggood for only 19.99 USD and thought this might be interesting for some of you guys:
https://www.banggood.com/custlink/3Dmpvt5A5R (https://www.banggood.com/custlink/3Dmpvt5A5R)
Ordered mine already 8)
-
When getting a power brick for the "mini" stations, how high would you go in the power rating? I only want to drive T12 tips. What's the official power rating of the T12 tips? 70 watts at 24 V? Is a power supply which can output 3.14 A sufficient or should I better get a 4 A supply?
-
T12 are rated at 72W.
But there are 2 things:
- you will have maximum power only at start
- the biggest tips are really close to that rating
If power supply will do that 72 W rated power you will be just fine with 72 W of power.
Even if it will not be able to do 72 W you can set maximum power to lower inside the settings with Davids FW and you will also be just fine.
As explained before smaller tips are not able to to achieve maximum power rating even from the start, when used they are not even closer (unless you will use the tips to heat water ;-))
So my advise is: use quality 72W power brick or at least a little bit more (96 W?!) for a no name. If you have any 24V low power (at least 24W so 1A) somewhere, set maximum power inside settings to lower and see how it goes ;-)
-
Thanks. The 100 W was only barely more expensive. The only downside is that it is slightly bigger. What I'm searching is a power supply where I can add my own cables. I want to route the earth connector to the secondary side to be able to ground the station this way. This is not easily possible with premade power bricks as they are usually welded shut.
I went for this one now: https://www.amazon.de/dp/B08NQ4CR96/ (https://www.amazon.de/dp/B08NQ4CR96/) This is not "the cheapest thing" but "Poppstar" is actually only an importer. You can find these power supplies under different brands. I'll post an update how it went with routing the ground wire to the secondary side. I hope that I can just feed it through between the board and the bottom of the case.
-
Hello to everyone,
is it possible to use any soldering tweezer (e.g. JBC AT420 or Hakko FM2023) with this CFW and maybe any HW mod? Did anyone tested it before?
PS: The link to this thread on github is wrong.
-
Oops, yes the final "/" was missing in the link.
Not compatible with tweezers, would require a second analog/pwm front-end, not a simple mod.
-
Thanks for your reply.
What about making a simple bridge between the two heating elements? It won't be possible to controll the temperature in every single tip, but will it be work?
Is there enough power to drive two soldering tips?
Edit:
I checked some circuit of STM32 soldering stations.
For a second channel you need an OP Amp and a mosfet including driver, nothing more. Nothing which you can't bring on a small additional PCB. This PCB can be conencted to the orginial one and wired to the µC. Also the Hirose connector for JBC can be placed on this PCB.
But will/can you add a second heater controll in your SW (I'm very bad in SW). If you say can will do it, we can manage it together. :-) In my opinion it is some copy paste and one additional menu for a tweezer. And there are some free pins on STM32 which can be used.
-
Yeah, technically feasible using another PWM and ADC input, running two PID controllers... but not straightforward, and I'm not working on it anymore, just small bugfixes, no more development..
There's not simple method running in parallel etc, read more here:
https://www.eevblog.com/forum/testgear/using-quicko-t12-952-soldering-station-with-2-tips-(as-soldering-tweezers)/msg4061356/#msg4061356 (https://www.eevblog.com/forum/testgear/using-quicko-t12-952-soldering-station-with-2-tips-(as-soldering-tweezers)/msg4061356/#msg4061356)
-
As the stations are cheap, the "way to go" would be to just have more than one. I have one that will always stay at my workbench which is also integrated into the workspace ESD ground and connected to a switch in the iron stand. I'm currently preparing a second station which will be stored in a small toolbox together with some stuff I need for soldering. So if I have to solder something that I can't bring to my workbench, then I can just grab that toolbox and have everything, that I need, right away.
And if I need two irons occasionally, then I can just set up my mobile station on my workbench.
The main issue for using the stations for tweezers is, in my opinion, that noone seems to make the "mechanical part". Meaning tweezers which hold two (identical) T12 tips. If that would be available, I would just create an adapter which splits the two heating elements off to two separate plugs for usage on two separate stations.
-
if u need tweezers, basically just add second controller and some awkward wiring. as David said, parallel connection wont work since most of smd elements are connected one end to ground plane and small tweezer needles just go burn in a second. more possible way is use unparallel high-matched pair and always touch controlled needle not on ground end.
-
The mechanical part is not the problem.
You can use original Hakko Tweezer (which works also with T12 tips) or original JBC Tweezer.
Now I bought Quicko STM32 station and checked the circuit, which is at github. There is already a second circuit for temperature measurement. I can be modified with only some components to be the same as the one for T12.
So no software changes have to made.
Then you have only to connect a MOSFET (including a driver) to any PWM Output and everything is done. (See "PWM on circuit)
Thats like a kind of bug fix ;) Using same function as before and making a new menu for a tweezer.
@DavidAlfa may you will make this bug fix? ;) I'll also donte a crate of beer.
-
Nope, the second analog input of the Quicko is for a different tip model, you still have only one power control stage, and more obvious, the software is designd to control only one tip.
First fix the PCB, when you have everything properly done I'll try to look at it, but not before !
-
What do I need to run a station with T12 and C210 tips? I have been looking into buying the Quicko T12 but I'm confused as to what else I would need to do to use C210 tips with these stations.
Thanks for any help!
-
Nothing, C210 connection scheme is the same, with heater+probe in series.
-
Here is also a nice diy T12 soldering station.
But then with atmel processor.
https://oshwlab.com/wagiminator/z-solderingstation-smd-v2
-
Nope, the second analog input of the Quicko is for a different tip model, you still have only one power control stage, and more obvious, the software is designd to control only one tip.
First fix the PCB, when you have everything properly done I'll try to look at it, but not before !
I'm working on it.
Step 0.5 is done. Build an flash adapter and flash your CFW to my soldering station. It was no problem, because of your very good documentation :-+
Step 1. comparing the circuit of 1322 and T12 temperature circuit and identify modification is almost finished. It seems to be a very easy mod to change 1322 circuit to t12 in existing layout.
But one question. Poti RJ1 and RJ3 is for? For temperature adjustment?
Regards
Chris
-
Gain calibration, I guess the original fw would use it to adjust the temperature.
Not required with this fw, but allows to easily extended the range if you're hitting the ADC limit and need more, like usually happens with C245, which output higher voltage per °C.
-
Ok, so it is no problem to get an fix value if a C245 is installed and to change the resistor. Thank can be fixed later.
I'll make the other parts before.
-
Nothing, C210 connection scheme is the same, with heater+probe in series.
For Power Supply, does it have to use 12 volts when using the c210 tip?
-
No, but set correct values in tip resistance and power limit to avoid overpowering the tip
-
No, but set correct values in tip resistance and power limit to avoid overpowering the tip
Is it also possible to use the c115 tip?
I'm interested in using the c115 tip, because it's smaller than the c210
-
Probably, but I've not tested it, neither anyone has provided any feedback, you must figure out how to connect it.
Read:
https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/ (https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/)
Apparently this is the wiring:
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1600888)
Th probe polarity is reversed, thus not straighforward fit.
-
Th probe polarity is reversed, thus not straighforward fit.
adding support for negative curve ?
-
No way, you can't measure negative voltage with the existing circuitry.
-
No way, you can't measure negative voltage with the existing circuitry.
i thought you meant negative thermocouple curve. i see no problems in connection with +V on tip.
-
No, the polarity is reversed, that's not negative curve, but negative voltage.
-
ah, i didnt even take a look at my station for an year, so i had to google c245 wiring again, now i understand whats wrong with c115 wiring.
-
Hi!
I'm deciding between a few T12 stations (Quecoo 955 or 958, KSGER V2.1 or the new STC V2.3, Yihua 948DB+ II and Sequre MSS12 Pro).
I'm mostly looking for a realiable station that will work even 5 or 10 years into the future with occasional use. For now I'm not looking to do any SMD work with it; just stuff like soldering a guitar switch, soldering two cable ends together and soldering a connector onto a cable. Probably won't need it more often than once a month on average. SMD does seem very interesting though so I might get into that a little bit somewhere in the future (probably at least a few years from now).
Would you say the Quecoo and KSGER stations are reliable enough to have a high chance of it lasting many years with occasional use? I've read and seen videos about many issues with it; though most are a few years old.
What issues still exists with these stations?
I'd prefer not having to ground it; the only KSGER / Quecoo station that seems to have both the tip and case grounded is the new KSGER STC V2.3. The PSU also seems way cleaner than previous revisions, for example the heatsink seems to not go over the power input trace anymore.
The most worrisome of all the issues I've found of KSGER and Quecoo T12 stations, is the tip glowing red hot causing the MOSFET to break. I don't have any experience replacing MOSFETs or anything alike, neither do I have the time to learn and do so at the moment, nor do I have the equipment to.
Also all the handles don't really seem realiable. Only the 907 seems somewhat realiable but that one's very chunky compared to the other offerings.
The KSGER V2.3 doesn't support this CFW as it has a STC chip and new, way bigger, display.
The KSGER V2.1 and Quecoo 955 should have the STM32 (have yet to confirm with Quecoo on their current offer on the 955, the 958 currently comes with the MM32).
Does this firmware add anything over the stock firmware in terms of durability?
What soldering station would you recommend to me and why? The KSGER V2.3, the KSGER V2.1, the Quecoo 955, the Quecoo 958, or another one?
Links to the stations I mentioned:
KSGER V2.3: https://a.aliexpress.com/_EHuRJy3
KSGER V2.1: https://a.aliexpress.com/_EGDIARd
Quecoo 958: https://a.aliexpress.com/_EHFcNaP
Quecoo 955: https://a.aliexpress.com/_EGGK8VZ
Yihua 948DB+ II: https://a.aliexpress.com/_EIQnoZD
Sequre MSS12 Pro: https://a.aliexpress.com/_EyOeYon
-
Durability?
The transistor usually fails due of some external issue, i.e. with the wiring/tip.
I've seen tips internally shorted because the internals rotated and twisted, also once the internal connection broke/burned up and touched the external tip casing.
There's nothing to do about that, if a short happens the transistor will blow up.
There's a small difference, some controllers have a better MOSFET in TO-252 package, will tolerate better heat and current peaks than SOIC-8 packages, but definitely not direct shorts.
I've blown it 3-4 times, most were caused by me (broken wiring, multimeter tip slipped while measuring...), only once a tip shorted out. I was lucky with the other short, could hear it sparkling inside the tip but nothing broke.
The psu is fine after 4 years, the rotating encoder is another common failure point, some are crap and fail quickly, mine has some bad days (Moisture, I guess) but overall it does fine.
There's no huge difference, don't get fooled by ksger or other overpriced brands, $40 stations are basically the same as $80 ones, perhabs with a fancier aluminium plate or a different handle.
And don't get the black aluminium handle, it gets *** hot after some use, soldering with a 50°C handle is uncomfortable at least!
-
Ok, thanks! That's my main worry: the cheap handles shorting causing the transistor to blow, or just something random shorting out.
Seems to be a regular occurrence with these stations.
I'm definitely avoiding the metal handles yeah. Besides heating up it would also kinda seem like a safety hazard to me to use those, especially with these stations.
Mainly looking at the 907 and 9051. The 907 is very chunky though and also seems to short out for many people, and the 9051 tends to melt and break.
The Yihua is a different station all together. The handle seems more robust. It's thinner and at least 2-3cm shorter from tip to fingers as on the 907, but the tip protrudes out more as on the 9051 and others, making it more likely that it'll handle the heat. Also the brand's products are certified by 3C, CE, UL, SGS, and ROHS. That's why I'm kinda leaning towards that one.
It has way less features though. For example it doesn't have per-tip calibration. But then again, how important is this?
The Sequre is a different station too. Not much to find about it though (only video is from 8 days ago, by learnelectronics; there's a few vids on the mini model) . The brand seems pretty new too; but they are certified by CE, FC, and ROHS, and from what I can find, they seem to make some decent stuff. Here the tip protrudes out about the same as with the Yihua, so shouldn't have any issues with heat at least (made from aluminium though so that's one small downside). The tip doesn't slide in as with the KSGER type stations, but clicks in. It's also a little more feature-rich than the Yihua. No per-tip calibration though but should have auto-calibration (which I don't know how, and how well, it would work though).
All the T12 type stations are about the same price. The only obviously cheaper ones are from Handskit (https://a.aliexpress.com/_EjwauOT), but the KSGERs and Quecoos seem better to me, and the price doesn't differ a lot either.
I don't know if the Handskit handles are any better when it comes to shorting out and heat-management?
The Oss T12-X also has a different handle (which again, I don't know if it has the same issues with shorting out and heat): https://a.aliexpress.com/_EHctfqR
The current prices (all including 3 tips; I'll probably order with just one though and buy real tips instead, but just to make the comparison easier):
KSGER V2.3: €67,7
KSGER V2.1: €65
Quecoo 958: €72
Quecoo 955: €62
Yihua 948DB+ II: €62 (also includes a stand that would cost me €10)
Sequre MSS12 Pro: €83 (with just one tip)
Handskit T12: €53,6 (including €10 stand)
Oss T12-X: €69,30 (including €10 stand)
-
Can i use CFW on this board, after replacing the chips with STM32?
-
Yes.
To date, all boards containing MM32 are exactly the same thing as normal ksgers v2/v3, CFW fully working after swapping to stm32.
-
I'm finding that the KSGER 2.0 builds of this firmware don't boot on my unit, while the 2.1S original firmware packages work just fine. Is there a particular step that I'm forgetting to take?
-
Probably using the wrong firmware.
As described in the readme, the easiest way to know is by checking the screen.
If it has 4pins, use v2 firmware, otherwise use v3.
-
The screen is definitely the 4-pin variety (1.3"), and the board is identical to one shown in the V2 schematics folder. :-//
-
Strange... Could you post some pictures of the board?
Also from the programmer log
I guess you're using the file from release v1.02 ?
-
I am using the 1.02 build, yes. CubeMX seemed to get stuck when I attempted to run building_script.bat and compiling it in the IDE itself didn't seem to work right (programming to the STM32 over the ST-Link finished in 1.1XX seconds!).
Here's a couple macro shots of the board:
-
Where's the stlink programmer message output?
-
Hi all,
Recently I bought a Quecoo T12-945 mini soldering station (I decided to go for the brand instead of the KSGER one, in general people seemed to be more positive about the Quecoo / Quicko ones.
I choose for the mini variant on purpose, it's very compact and can be used with a battery pack, which elimates leakage. From what I have read at several sources, an adapter can cause slight AC leakage which isn´t desirable for the most sensitive components.
Anyway, I wanted to get a station with STM32 chipset since that one is firmware upgradeable. However I can find very little information about my particular station. There's plenty to find about the KSGER stations though.
I took a look at deividAlfa's GitHub repository, https://github.com/deividAlfa/stm32_soldering_iron_controller, which has plenty of schematics of KSGER stations to determine if a particular station is suitable for the custom firmware. When checking at Quicko. there's no images of PCB's which makes it easier to see whether a station is suitable for a firmware upgrade or not. There's only some references to different kind of STM32 chips, but that's about it.
Is there anyone here who could give me some pointers about how to proceed? I am supposed to disassemble the station and check which STM32 chip my station exactly has? Before getting a station with STM32 chipset I assumed all were firmware upgradeable, hopefully I'm not wrong ;).
Cheers
-
Newer quicko/quecoos are basically ksger v2... Look in that folder.
If the display has 4 pins, go straight with ksger v2 fw, post a picture of your board just in case.
-
Hello David,
Thanks for your reply. Because I have been in a hurry, I just took photo of the STM32 chip, but I assume you need more information?
Anyway, I will post the picture here and when I am back home later, I will make some photo of the PCB or anything else that's necessary.
(https://i.imgur.com/EinMBbz.png)
Cheers
-
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1192964)
thats the board. just use ksger v2 fw.
-
Really glad to hear that its firmware can be upgraded.
Thanks a lot to you and a David for your fast responses!
-
I have been reading a bit about the procedure of upgrading to the custom firmware, which involves a bit more steps than I would have been expected at first.
Anyway, I was wondering if is there's any requirements when it comes to the STM32 ST-Link (V2) to do the actual firmware flashing. At Amazon a pretty affordable one is available:
https://www.amazon.com/Aideepen-ST-Link-Programming-Emulator-Downloader/dp/B01J7N3RE6/ref=sr_1_3?keywords=ICQUANZX+ST-Link+V2&qid=1666207844&qu=eyJxc2MiOiIxLjgwIiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sr=8-3 (https://www.amazon.com/Aideepen-ST-Link-Programming-Emulator-Downloader/dp/B01J7N3RE6/ref=sr_1_3?keywords=ICQUANZX+ST-Link+V2&qid=1666207844&qu=eyJxc2MiOiIxLjgwIiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sr=8-3)
Are they good enough to do the job?
If I understood correctly, you first flash the custom firmware, and then you start the calibration process. Could you recommend me any (cheap) high temperature meter for the calibration? Amazon would be desirable because of their fast shipping in general.
Since the custom firmware uses more power, it possibility causes the regulator to overload and will shut down. This applies to any SMT32 based soldering station or it's just a few that suffers from this issue?
-
The regulator issue applies only to very specific older ksgers, it failed commonly even with original firmware too, was very much at the limit!
Yeah, any cheap stlink should work...
-
You could buy a dedicated iron calibration device but most of us simply use a multimeter with thermocouple attachment (they usually go up to 500°C). There are also fake Hakko FG-100 available for cheap (~25euro). A genuine one will cost you around 250euro.
-
Thanks for that suggestion, I do have a thermocouple attachment for one of my multimeters. Actually haven´t used it yet myself, you're supposed to add a bit of soldering wire to the tip and then contact the end of the attachment, or you're supposed to contact the attachment with the bare end of the soldering tip without soldering wire?
-
You don't need a crazy accuracy for soldering, +-10°C won't make a great difference, except for fools :)
-
Hi,
Thank you for sharing this open source FW, in particular to the developers, but also to all the contributors.
Excellent documentation!
I have this V3 board: https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/f101-back-hi-res-12.jpg (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/f101-back-hi-res-12.jpg)
I flashed it with latest David build (KSGER_v3_OLED.bin V1.02) and after calibration is working very well with T12 tips.
I also like a lot all the customization options and the menu organization.
Next I would like to try C245 tips/handle, I've read here the connections and trace I need to cut (for another PCB): https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/msg3871406/#msg3871406 (https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/msg3871406/#msg3871406)
Are the T245 connections in the above link ?
One question I have is what pin from my GX12-5 PCB connector should I use to pass the (yellow) TC+ wire?
I was thinking to isolate/separate GX12-5 PIN 4 from the PCB and use that for C245 TC+.
Then I would need to shunt pin 5 and 4 of T12/c210 handles to undo the PCB trace I cut.
I'm not sure if I got this right? So would need some help before I butcher the PCB.
I'm thinking to desolder the GX12, enlarge the PIN 4 PCB hole, so it doesn't touch the GX12.
Is there a better connection option?
-
Thanks for that suggestion, I do have a thermocouple attachment for one of my multimeters. Actually haven´t used it yet myself, you're supposed to add a bit of soldering wire to the tip and then contact the end of the attachment, or you're supposed to contact the attachment with the bare end of the soldering tip without soldering wire?
Always add solder for reliable reading. It's too finicky to do it dry because you then have to contact the perfect spot at the perfect angle and hold it there several seconds.
-
Can i use hakko 907 handle with this firmware?
the handle has a1321 heater
https://hakkousa.com/amfile/file/download/file/2470/product/6798/
-
Not directly, but possible modifying the circuitry.
Instead of a 1-15mV thermocouple, that handle uses a PTC resistor of 40-60ohms.
You would need to add a pullup resistor to create a resistor divider, then modify the amplifier to reduce the gain by a lot, so the end signal tops up at 3-3.1V when 450°C are reached.
The curve of that sensor is unknown to me.
You'll have to figure out by yourself!
-
@DavidAlfa
Sorry to bother you David.
Thank you for all the development work and documentation.
Excellent firmware, much better than the sellers options and it's open source!
It's also an opportunity to learn a bit how this works, had no idea and liked a lot to read the documentation.
I wanted to also use a T245 handle.
I was thinking to isolate/separate GX12-5 PIN 4 from the PCB and use that for C245 TC+.
Can you tell if that is the correct way to proceed?
I'm just an hobbyist and need some guidance.
-
Hi,
The message you linked shows the correct jbc connection.
Yes, you could use one of the gnd wires (3/4) for that.
But you'll have a hard time desoldering that connector!
The easiest way would be to cut the pin, so it doesn't reach the board, then solder a wire to it.
Once you do that mod, you'll have to fix the T12 handle, joining both gnd wires together into the same pin, also T12+ with the pin you'll be using as tip temperature sensing (3).
Another approach, tidier and easier, would be this:
Since the T245 handle has no NTC, you'll have to disable it in the settings, so it uses the internal temperature sensor.
Now you can repurpose the NTC pin with few little modifications:
- Remove R10 so the CPU becomes isolated from the NTC pin.
- Cut the trace on R0 to isolate the amplifier from the tip power pin.
- Join the NTC and temp. sense pads.
- Now use the pin 2 for the tip temperature sensing, all should work fine.
The T12 handle would need to be fixed, disconnecting the NTC and joining T12+ with the pin 2.
Disabling the NTC doesn't make a lot of difference, perhabs some °C, but nothing crazy.
Check out your board schematics (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/KSGER%20STM32%20OLED-3_0%20schematic%20rev1_cosmin_floobydust.pdf).
-
Thank you for the detailed reply.
I now have all the information to do the changes during the weekend.
Still deciding if I'm losing NTC (much easier and clean solution) or use one of the GND pins (if possible without desoldering the socket).
-EDIT-
Without any HW change, I switched the T12 NTC on/off in FW settings.
With NTC ON and after T12 cold tip calibration, I saw around 1ºC (max 2C) deviation from FG-100 clone in 245,255,320,370C.
With NTC OFF and after T12 cold tip calibration (I calibrated the cold tip with CPU at 40C) and I saw around 6ºC deviation, after fooling around with temp. to 400C, suddenly the difference was 12C to the FG-100 clone. Same T12 tip, it's old and well cooked.
These results are based only on a few tries, so no for sure conclusion can be taken with so few tries.
I was now looking for a way to use one GND pin without desoldering the GX12-5 connector and keep the NTC if possible. If to much trouble I would go for the other option, removing NTC and use that pin.
Because PCB is soft, I decided to try to grind around PIN4 to separate it from the PCB GND connections in both PCB sides.
I used a battery power, hand size much smaller dremel like pen (15cm length) and what looks like a carving bit that I have never used before.
It worked much better than I expected, in a few minutes (3 or 5, I didn't clock), also pausing to examine progress and brush dust, the thing carved a perfect pit around the pin and also ate a bit of the pin top. (I don't have any hollow drill bits or milling cutter bit to try.)
-
Yes, you could use one of the gnd wires (3/4) for that.
After I cut around pin 4 isolating it from PCB, I realize maybe pin 3 was a better option. 8)
Pin 3 is closer to PCB JBC pin to make a connection and I would have kept T12+ and GND pins closer (easy to remember). Anyway any of the options work.
Now I'm facing an issue, with correct connections, C245 temperature read by the controller is wrong and much higher (double or more) than the FG-100 real tip temperature.
It only displays the correct TC+ = ambient temp. while sleeping and cold.
Will do some more tests in next days.
I read the problem is the PCB opamp or DC converter noise.
It makes sense and it's clear the opamp isn't passing the correct temp to the cpu.
I have 3 ksger controllers, all exactly the same PCB version I posted above.
I bough them with coupons a few years ago (when it was cheap) for 9 - 10 eur each.
To dismiss that unit had a problem, because I had repaired it in the past, I used a 2nd controller (not repaired). Now I only cut R0 and solder the correct T245 wires to the PCB and still have the same temperature issue.
Not in any hurry to solve this, so I ordered some ALI opamps, probably more of the same.
I'll search the thread about this T245 issue and make more tests in next days (when I have a bit more time).
-
looks like u dont need easy ways to do something ;D
-
I get it, the easy and clean solution, is indeed the logical solution, so it's the best solution and I agree with this. ;)
Still there's a bit of logic in my (drilling) "madness", I have 3 ksger controllers and 3 T12 handles and wanted to keep NTC.
(I bought these cheap in 2019/2020. I use 2x T12 D08, with both hands like tweezers when I do SMD and one controller broke so I got a spare.)
In a fast test, I saw 6C to 12C difference with NTC off in FW and want to test more.
Hopefully in the end I can also arrive at the conclusion that NTC is not important.
Still without NTC, every time we power on, the cpu is at ambient ~24C, then after 20mins or so, it'll be ~40C, those 16C startup difference don't affect tip temp? We either calibrate at 28C or at 40C, so I decided to calibrate at 40C.
I need to take some time to search the thread about my T245 temp. issue, but if you have any (easy) solution , I promise I won't drill another hole to implement it. ;D
-
Yes, you might lose 10ºC in teh worst case, is that so critical? Nope.
Did you calibrate the system? Otherwise you're losing your time, of course the readings will be wrong!
-
I mean, after soldering for 15-20min, you can clearly feel a handpiece warming up. At this point, how is NTC inside the handle any better at reading ambient t° than the one on the controller board? This never made sens to me. :-//
-
Yes, you might lose 10ºC in the worst case, is that so critical? Nope.
No not critical, it was what I observed in T12 test.
I wanted to experience it to learn.
Will it help having a NTC soldered to the pcb, inside the box, measuring ambient temp, compared to using cpu temp?
Did you calibrate the system? Otherwise you're losing your time, of course the readings will be wrong!
Regarding T245, I power on, T245 profile, NTC OFF, wakeup stand, startup sleep.
Station sleeping displays ~37C in tip, 36.7C in CPU and 25.3C in FG100. Ambient temp. in FG100 is 24.5C.
I started the T245 cold tip calibration, I noticed when the station is trying to stabilize 250, shoots at 800, 900C, but at same time tip is bellow 100C.
It stabilizes at 250 but FG100 measures 112C in tip.
I though something was wrong or I did something wrong and didn't proceed doing a manual calibration.
This in both stations, one I only cut R0, I soldered a short wire to PCB jbc pin (lower 6th pin in a row), then to T245 blue handle wire on the other side (with a crocodile).
T245 brown wire to pin 5 and green wire to pin 3 (using front GX12-5 socket).
-EDIT-
Proceeding with manual calibration:
cal 250 defaults to 900 and measures 110C in FG100.
Increasing the value to max 990 measures 120C in FG100.
I aborted the manual calibration and defaulted to 900.
I also ordered another tip.
Without calibration, waking up from sleep and going to the graph, it displays a lot of huge camel bumps, will take a photo, looks like noise? tip is touching nothing.
Going to the the home screen it displays a steady 320C, with a few occasional jumps to 315,326C, but tip is at 128C in FG100
-
Don't get fooled, we don't care about the ambient temperature, it's the cold side of the tip what we need.
Why?
Because that's where the Seebeck effect ends, at the connection of the T12 tip.
The probe voltage is generated based on the temperature gradient between the hottest part (Tip) and the coldest (Tip connector).
If you have 400 and 50°C, the probe generates voltage for 350°C.
If you have 400 and 10, it "reads" 390°C.
But the tip temperature is actually the same, it's the cold side what changes.
So that's why the NTC is ideally placed at the handle.
As the handle warms up, the tip sensor voltage drops, as the gradient is lower.
Reading the NTC compensates this, not greatly accurate, but does something.
Using the internal sensor might accidentally compensate enough as the board warms up, but that's pure luck, it might under or overcompensate.
Both handle and board will warm up, so using the internal temperature will be better than nothing.
-
Well I now know I'm thinking about it the wrong way. Thanks David :-+
-
Dcore, just follow the User Manual, there's nothing else!
You're skipping calibration because, well, it reads lower?
What's calibration is for, then? Why would cal250 and cal400 values exist? ;)
Increase until reading 250 and 400°C respectively, you have room up to 4000.
As stated in the instructions, default calibration is usually pretty low to prevent tip overheating, there're a lot of controllers out there and some of them read a lot different than others, I don't want anyone getting the $30 JBC tip red hot, ruining it.
Also genuine JBC tips read about twice than cloned tips, which are basically expensive T12 tips.
You're using a chinesium JBC clone, right?
Of course it oscillates a bit, it's trying to control too small temperature changes, thinking it's 10°C when the variation is 5°C really, way too sensitive.
Will get better when properly calibrated.
-
I now see that I was being overcautious.
(Yes, I use china clone tips.)
I did the manual calibration, since auto was not possible.
I had to do manual calibration twice, since the first time, the max allowed value for cal250 was limited to 990.
In the second manual calibration, it allows cal250 values beyond 990, probably because I had set cal400 to 4000 before.
After the manual calibration was correct, I did auto calibration and it worked, values were only off by 4C.
Back to home screen, the temp is spot on 320C, 370 is +2 hurray!!!! :clap:
I notice that cold tip, shows 39C, probably the CPU temp when I did zero set.
It's working very well now!!! :-+
Thank you so much for all your help and information! :clap: :clap: :clap:
-
Yeah, repeat the zero set when really cold, like after 30 minutes off.
Take out the tip without your fingers (Or you will transfer some heat to it), turn on the station, go to calibration menu, insert the tip, enter calibration adjustment and capture the new Zero Set value.
Once done right, it usually stays pretty close, few degrees off depending on the board temperature (This slightly affects the amplifiers drift).
However remember this is not a thermometer and shouldn't be expected to work like one.
Few degrees off here and there are completely expected, specially at the center between 250 and 400, as the sensor output is not 100% linear but I do use a linear interpolation.
The error will be about 5°C in the worst case, for me it's just fine, not enough to bother with complex maths.
Most commercial products won't display anything below 100°C or more, also they filter all these small oscillations and you won't know they exist (But they do).
Enjoy!
-
Which T12 (according to the technical base) is best to buy so that there are no problems with custom firmware? On 4pda I was advised a green diy kit ksger 2.1s, but it is quite expensive.
https://aliexpress.com/item/32933941125.html (https://aliexpress.com/item/32933941125.html)
-
https://aliexpress.ru/item/4000183089084.html
-
Which T12 (according to the technical base) is best to buy so that there are no problems with custom firmware?
https://aliexpress.ru/item/32788912011.html
this one
-
I'd like to fix the Quicko STM32F072 build, but I lost the chip long time ago.
Does anyone have that controller and some spare time to let me remotely debug it?
-
Firmware for soldering stations with MM32SPIN27: https://github.com/koendv/t12-958 (https://github.com/koendv/t12-958)
This is Arduino, and easily adapted to your needs.
Basically I ported the relevant parts of Arduino to MM32SPIN27 https://github.com/koendv/MM32SPIN27-Arduino (https://github.com/koendv/MM32SPIN27-Arduino).
In case you are using MindMotion MM32 Cortex M0 processors in another project: In MM32SPIN27-Arduino/mm32/mm32-libgcc you'll find libgcc, patched to use the hardware division present in MM32 Cortex M0 processors.
-
Nice work! :-+
-
Well, it seems they started to use relabeled chips.
Spent few hours remotely fighting with Cube IDE, discovered that anything never than JDK15 will break it in very strange ways...
Finally, CPU ID 0x13030410, definitely not a genuine STM32F103, Google says it's a GD32F.
So GD32F also has the same ADC issue as the CH32F.
-
hello, there is a newer KSERG T12 being sold on aliexpress that uses "STC Controller V2.3". one of the new "features" is that the chassis is now properly grounded and also the display appears to have a color interface. however, i suppose this means that the likehood of it using David's firmware is very low? AFAIK this is the first of the T12 clones to be properly grounded from the factory?
https://www.aliexpress.us/item/3256804499899529.html (https://www.aliexpress.us/item/3256804499899529.html)
-
Well, it seems they started to using relabeled chips.
Spent few hours remotely fighting with Cube IDE, discovered that anything never than JDK15 will break it in very strange ways...
Finally, CPU ID 0x13030410, definitely not a genuine STM32F103, Google says it's a GD32F.
So GD32F also has the same ADC issue as the CH32F.
Did it look like this? I got this one couple weeks ago.
KSGER T12 OLED Soldering Station T12 Iron Tips STM32 DIY Assembled Kits ABS Plastic FX9501 Handle Electric Tools Welding Heating
https://www.aliexpress.com/item/4000008060128.html?spm=a2g0o.order_list.0.0.635e1802h1LEh9 (https://www.aliexpress.com/item/4000008060128.html?spm=a2g0o.order_list.0.0.635e1802h1LEh9)
[attach=1]
-
STCs are not compatible. It's not a clone, but a completely different architecture.
Yeah it looked pretty similar.
After rubbing with some alcohol the label went away, original stm32 are labed with laser.
-
I thought every chinese faker got a laser engraving machine nowadays.
-
Probably got fake laser machines too :-DD
-
Haha, that would explain it >:D
-
just one other quick question that many of the experts in this thread can probably answer: what is primary difference between the 4 pin and 5 pin handles in the T12 clones? i've read that 5 wire irons have an additional temperature sensor in the handle to allow for proper cold junction compensation. is that an important feature that was absent from the 4 pin versions? if so, are all 4 pin handles in some sense defective? thanks for help understanding.
-
Nothing really, all you need is 4:
- Gnd
- T12+
- Shake
- NTC
5-wire handles use two wires for gnd.
-
I made a KSGER v2 test build, enforcing Cortex-m0 instructions for MM32, but I have no way of trying.
File attached, let me know the results if you tested it.
-
Hello DavidAlfa. I am studying your sources with interest. I am not a programmer, and therefore I program a little. I saw a lot of new things in the source code for myself.
To facilitate the study, could you explain the principle of forming menu screens with widgets and displaying them on the screen?
-
Sorry, I can't really explain everything, that's a pretty long thing to do, specially if you don't know programming!
Start at gui.c, follow the program flow...
Most stuff happens at widgets.h/c, screen.h/c and the individual screens at "screens/**screen.c".
Mostly you can reuse existing blocks, function names are easy to understand and self-explanatory.
It's like asking a mechanic to explain how to rebuild an engine when your daily business is office work.
I'm not saying it's easy for me either, first time I got into it, it took me weeks to understand everything, few years had pased since last time I programmed.
-
David, I'm trying to build the current master the usual* way but I'm hitting a brick wall for some reason. After opening the .ioc file, whenever I run the "Device configuration tool code generation", it just deletes all files leaving only an empty Drivers/CMSIS subfolder within the root directory. I also tried the old method of saving .ioc file with the same result.
I'm trying to figure out whether it's related to the recent changes ( https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/e3c76e33704b86c69e8d5ccc87f81b639c81c648 ), new CubeMX version somehow changing something (updated from 1.9.0 to 1.10.1) or something else entirely. Also CubeMX doesn't log anything, it all happens in the background. Any thought?
Building for Ksger v1.5 board with standard SD1306 OLED.
*by that I mean your old manual way that worked for me a hundred times before.
-
Understood. Thanks. Well, I'm not that inexperienced in programming...
It's just that there are quite a lot of different structures piled up there to immediately understand the entire hierarchy.
For example, that a screen is created, elements widgets are added to it, and so on.
Well, I'll figure it out slowly.
Is this a self-written gui or is there something similar with usage examples?
-
It seems there was information about problems when migrating from old CubeMX.
I now used CubeIDE 1.10.1 and CubeMX 6.6.1 without problems
But at startup CubeMX, I did not do the migration, but left the old version (press continue)
-
I can't seem to find how a tip change is covered. Any problems with "hot swapping" C245/C210 carts? I have original JBC AD-SF stand with separate holder-post and change-post wire outputs. Sleep/Standby works fine when triggered from holder-post with "Stand mode", now I'm wondering if there is something similar to detect tool change when change-post is touched?
-
Try using the Build script to generate the code or compile, works straight away.
There's no reason to do it manually, importing the projects, etc...
Also check your java version, open a CMD window and type "java -version", should be 12...15, newer like 17 and 19 won't work, the IDE will drop hundreds of errors.
Running CubeMX within the IDE seems to break it, haven't looked much, but apparently it's not liking the different profiles, and in some cases overriding the linker script completely.
I just noticed this in the diff. Hmm suspicious.
- ProjectManager.TargetToolchain=STM32CubeIDE
+ ProjectManager.TargetToolchain=EWARM V8.32
I upgraded the ioc files using the script, not inside the IDE, that could be the culprit.
Will make some testing tomorrow.
Spenoza, sorry no docs, it's custom, tried to keep it tidy and well commented but that's all.
It also took me a while to figure out when forking PTdreamer's code.
-
Thanks for looking into it David. BTW, if the problem's on my side and don't affect other people, don't waste your time on it I'm sure you've got more interesting things to do. ;)
Regarding the script, considering I run powershell as default command interpreter, the fact that cubeMX is in "program files" (which the script most likely can't access cause it's a system folder) and that I also replace a couple files manually anyway, it just didn't make sens for me. For the sake of testing, I did try the script in cmd, ran it as admin and even set the correct path in the script but it won't launch cubeMX and stops there. No big deal anyway.
JRE version is 1.8.0. Unless the CubeMX updater installed that version, it should be the same one that worked fine until now.
I tried changing the suspicious line in the ioc file, still no joy.
-
So for some reason calling CubeMX externally isn't behaving in the same way as before.
If you chose "only copy files" it would as expected, it was the generation causing the issue.
After generation using the script, these lines are changing:
ProjectManager.TargetToolchain=STM32CubeIDE
ProjectManager.UnderRoot=trueTo:
ProjectManager.TargetToolchain=EWARM V8.32
ProjectManager.UnderRoot=false
Building within the script will work perfectly, the issue will happen in CubeIDE.
After that, opening the ioc in CubeIDE and regenerating the code will completely mess the project up (Creating like 10 Release/Debug configurations, wtf) and placing the generated files under "Application" folder.
Trying to revert the mess regenerating with a good ioc wouldn't fix it, it was too late!
The big issue happened when I upgraded the ioc files to the new MX version, then committed broken files.
Everything fixed, check the commit details (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/0c9e902db02d4fc9ddcf92008adf2821e321637d).
-
Yep, you nailed it! I can also confirm that JRE 1.8 works without any error or warning.
Now just tick the checkbox to generates the .bin formatted file and it'll be perfect (yeah, I know, lazy users always complaining about something...) ^-^
Cheers man.
-
I had to reset the project several times until I found the issue, checked the hex & bin boxes every single time, well, except in the last one :palm:
In fact now you said it, I noticed the bin files were missing after an automated build, but it took me a while to put everything together and later forgot about Ii.
Edit: Fixed.
-
Hi,
I recently bought a Queeco T12-959, just checked inside and found an XM1008K6T6 instead of an STC, still not supported due to flash memory constraints.
Any ideas to replace that with a regular STM32F103C8T6? May be worth to design a new PCB? What are the benefits of the custom firmware?
-
Handskit tweezers
https://de.aliexpress.com/item/1005004933557376.html
-
Hi,
I recently bought a Queeco T12-959, just checked inside and found an XM1008K6T6 instead of an STC, still not supported due to flash memory constraints.
Any ideas to replace that with a regular STM32F103C8T6? May be worth to design a new PCB? What are the benefits of the custom firmware?
Maybe it's using external flash IC since 32k is quite small.
Regarding DavidAlfa's firmware: is it possible to configure it to turn heat off with a press of a button or some other action (other than timeout)?
-
Any ideas to replace that with a regular STM32F103C8T6?
No. STC boards are completely different.
Hi,
I recently bought a Queeco T12-959, just checked inside and found an XM1008K6T6 instead of an STC, still not supported due to flash memory constraints.
Any ideas to replace that with a regular STM32F103C8T6? May be worth to design a new PCB? What are the benefits of the custom firmware?
Regarding DavidAlfa's firmware: is it possible to configure it to turn heat off with a press of a button or some other action (other than timeout)?
Don't be lazy and read the MANUAL (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md#main-screen).
-
Hi everybody. I bought the Quecoo T12-958 soldering station on Aliexpress. Processor is MM32SPIN27. It arrived with tip J02 activated. I don't have tip J02 I tried to disable it but I can't. Has anyone had this problem ?
-
Thank you for great firmware. Have you considered XORing temperature digits with temperature graph? I'm curious if there are perhaps technical limitations for not doing so.
Btw, I have T-12 955 model (latest fw) and selection of Boost/Sleep/Standby does not work reliably (or how I imagine it should):
Boost cannot be selected by click-turn, only by click within one second of temp selection.
Sometimes I can get to Sleep, sometimes selection stops at Standby, continuing rotation does nothing.
If it stops at Standby, sometimes I can press-turn again to get to Sleep, sometimes that does not work.
-
If you're talking about the CFW, making those questions it seems your didn't read the manual?
Controls have nothing to do with Ksger.
Boost can be only selected that way, rotate (temp shows up) and click.
Low power modes are entered by making click-and-rotate-counterwise.
Please read the manual, I could understand those questions if it was written in Chinese, but it's English, so what's the excuse?
Read the Operation manual, then make questions if you don't find it there.
Yes I tried xor'ing it long time ago, it was weird (Check attached picture).
It's a 128x64 oled, don't ask for miracles!
-
This is what manual says:
Sleep/Standby modes
You can manually enter lower power modes by clicking and rotating counter-clockwise.
The sequence would be [run/boost mode]->[standby mode]->[sleep mode].
The way I understood the above:
1st detent: boost mode
2nd detent: standby
3rd detent: sleep
Based on your reply, sounds as first state is the starting point not a function accessed by click-rotate. The issue reaching standby or sleep reliably is how I described in my previous post (tl;dr standby is not selected on 1st detent and sleep on the 2nd).
-
Then there an error in the manual. I believe David changed the behavior at some point to accommodate for more actions and features. That line in the manual must be a relic of the past. :)
The way it currently works is:
- click and rotate 1 or 2 ticks counter-clockwise for standby then sleep.
- rotate 1 tick in any direction to highlight t° and then click while still highlighted for boost.
- click and rotate clockwise to highlight tip selector and select by turning the encoder clockwise/counterclockwise.
* While tip selector is highlighted, long press for more than 2sec to edit selected tip.
- long press for more than 2 sec to enter config menu.
-
I agree, it's not entirely clear...
How about this? Will update the Readme soon.
For some actions you might be instructed to issue a Drag rotation.
This means clicking the button (Helding down) and rotating at the same time.
The time between pressing and rotating must be short, i.e. don't keep the button down for two seconds before rotating, doesn't need to be blazing fast either, just done in a natural way.
After a drag-rotation was detected, release the button and use the encoder normally (Don't keep pressing to move, etc).
**Sleep/Standby modes**
You can manually enter lower power modes by making a counter-clockwise drag-rotation.
**Tip selection**
Issue a clockwise drag-rotation to show the tip selection. The tip name label will be highlighted.
-
Huh, I accidentally overwrote the whole repository because my local version was older!
After some hard sweating moments, everything was recovered back to its original state.
Updated the Operation manual showing these changes.
-
I agree, it's not entirely clear...
How about this? Will update the Readme soon.
For some actions you might be instructed to issue a Drag rotation.
This means clicking the button (Helding down) and rotating at the same time.
The time between pressing and rotating must be short, i.e. don't keep the button down for two seconds before rotating, doesn't need to be blazing fast either, just done in a natural way.
After a drag-rotation was detected, release the button and use the encoder normally (Don't keep pressing to move, etc).
**Sleep/Standby modes**
You can manually enter lower power modes by making a counter-clockwise drag-rotation.
**Tip selection**
Issue a clockwise drag-rotation to show the tip selection. The tip name label will be highlighted.
Looks fine to me. Maybe a native English speaker could suggest a more natural or preexisting wording for "drag-rotation"?
-
Forgot my A+++ Oxford degree, what really matters is the mechanics being easy to understand ;)
-
@KocsisV You owe me a truck full of beer for this (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/ba1bfc721db64f202e266350fa3486b5228c1b62/Core/Src/settings.c#L323)! (A little ranting) :horse:
This is why I'm reluctant to accept huge commits from 3rd parties...
The theory says it should be error-free, but there'll always be some bugs, people will fly away leaving your project broken, and you'll be the only one fixing it, which will be 5x harder because you didn't made the changes.
Spot the error:
// Ensure flash was erased
for (uint32_t i = 0u; i < (numPages * FLASH_PAGE_SIZE / sizeof(int32_t)); i++) {
if( *((uint32_t*)(pageAddress + i)) != 0xFFFFFFFF){
Flash_error();
}
}
// Ensure flash was erased
for (uint32_t i = 0u; i < (numPages * FLASH_PAGE_SIZE / sizeof(int32_t)); i++) {
if( *((uint32_t*)pageAddress + i) != 0xFFFFFFFF){
Flash_error();
}
}
The difference is subtle, almost evil!
((uint32_t*)(pageAddress + i))Casts a uint32_t pointer to (pageAddress+i). When i=1...3, it will cause misaligned access.
((uint32_t*)pageAddress + i)Casts a uint32_t pointer to pageAddress, then increase increase the pointer by "i" times 32-bit, so each "i" increases the pointer by 4bytes.
The reason it didn't crash in Cortex-M3 (STM32F10x) is because it seems to support unaligned access, but Cortex-M0 clearly doesn't!
Neither was the code checking what it was suppossed to, it worked by pure luck :-DD.
New builds available, Quicko F072 is working again.
Re-checked the projects, some were wrong (CubeIDE mixed some flags) or lacked binary outputs, fixed everything.
-
Hi. One question regarding Display brightness.
I have tested Handskit soldering station and the display brightness is much less bright then on Ksger. In fact it does not show any increasement in brightness after number 6.
It is a 4 pin display SSD1306 and have flashed v2 version on it. Is there anything it can be done to increase the brightness or is this just as the display is?
TNX
-
I think it's due the specific SSH106 display initialization it uses. I might make a special build for it, but first I need you feedback.
Is your display the 0.96" version or the 1.3?
Try this HW2.0 / HW2.0S / HW2.1S (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/Original_FW/KSGER/Firmware%202.12%20(14.05.2017)) firmwares, which work/doesn't, which are brighter/dimmer?
Took a moment to reverse-engineer the original 1.3" v2.1S firmware in Ghidra and extract the display initialization, clearly it's executing the SH1106 charge pump command.
I recall this broke compatibility with some displays, I think it was the SSD1309? So the command was removed.
void SSD1306_init(void){
SSD1306_start_write();
i2c_Send_Byte(0); // Write Cmd
i2c_Send_Byte(0xae); // Display off
i2c_Send_Byte(0); // c_col_H
i2c_Send_Byte(0x10); // c_col_H
i2c_Send_Byte(0x40); // c_start_line
i2c_Send_Byte(0xb0); // c_page
i2c_Send_Byte(0x81); // c_contrast
i2c_Send_Byte(0xff); // max contrast value
i2c_Send_Byte(0xa1); // c_remap_on
i2c_Send_Byte(0xa6); // c_inv_off
i2c_Send_Byte(0xa8); // c_mux_ratio
i2c_Send_Byte(0x3f); // mux ratio = 0x3F
i2c_Send_Byte(0xad); // c_pump_1106_set
i2c_Send_Byte(0x8b); // Enable pump
i2c_Send_Byte(0x33); // c_pump_1106_adj, 9V
i2c_Send_Byte(0xc8); // c_com_rev
i2c_Send_Byte(0xd3); // c_offset
i2c_Send_Byte(0); // offset =0
i2c_Send_Byte(0xd5); // c_clock_set
i2c_Send_Byte(0x80); // clock = 0x80
i2c_Send_Byte(0xd9); // c_precharge
i2c_Send_Byte(0x1f); // precharge = 0x1f
i2c_Send_Byte(0xda); // c_com_cfg
i2c_Send_Byte(0x12); // com_cfg = 0x12
i2c_Send_Byte(0xdb); // c_vcomh_lvl
i2c_Send_Byte(0x40); // level = 1 * Vref
i2c_Send_Byte(0xaf); // display on
i2c_stop();
SSD1306_fill_screen(0);
SSD1306_set_cursor_position(0,0);
}
-
Hi. So i did some testing and it looks like that with the original display named "Handskit_2.11.bin" display is bright. Then I have also tried "[HW2.1S]_[1.3OLED].hex" and the display was also bright.
After that I have flashed "[HW2.1S]_[0.96OLED].hex" and the display is not bright. It has the same brightness as your firmware.
In the picture below you can be see the brightness difference, but it is harder to see on the picture as it is in the real life.
Note: in your firmware display brightness on the picture is set to 10 - Max.
-
Thanks, now I have something to analyze and compare.
Edit: Try the attached file.
It turns out the previously tested SH1106 command was wrong, however I have no idea whether it will break compatibility with other displays.
I made two versions: One SH1106-only, and another executing both SSD1306 and SH1106.
Anyone else running Ksger v2, it would be great if you can try these too, specially if you have replaced the display.
-
It is still not as bright the KSGER one but better. But funny is that obviously Handskit is using different parts display because one is brighter then other with the same firmware. I would say that on one Handskit the brightens is the same when one is in wake status and other in sleep.
Do not spend too much time since I doubt that it is worth troubleshooting.
Will test new file. The report above is for the first one you have attached.
Hmm. Unfortunately I do not see any difference. I think it are the displays that are not the same quality. Handskit also uses display that has not the same pin order as KSGER and other displays that are available in aliexpress.
TNX
-
Yes, displays vary a lot.
Last ones I got from AliExpress were much dimmer.
There's another thing, these oled displays lose brightness as you turn more pixels on.
This FW turns almost the entire display on when adjusting temperature, also font is much larger.
Compare brightness at the menu, the difference should be less noticeable.
-
Final test. This version uses exactly the same commands as the original.
If brightness isn't restored, then it's simply a display limitation caused by larger lit areas.
For example, the display also dims noticeable when the temperature plot goes full white!
-
Hi. Have flashed many times and tested and I have a feeling that those last two are a little brighter than the official v1.04 is.
I think it is not placebo but those two in the latest attached zip file I do not see the difference between KSGERv2_SH1106_init.bin and KSGERv2_SH1106_same_order.bin but as I have said I think they are a little brighter than the latest official.
-
But did they made a difference between previous tests build?
-
Hmmm I am not sure. The difference is really small. I would saj last two in the zip are the brightest but only marginal.
-
You'll notice the display flickers a lot more in the original firmware than in this one, that0s because the display refresh rate is slower, while thisone runs it as fast as possible for better view.
The benefits overcome the minimal brightness drop.
So the difference is just the SH1106 charge pump command. I still need people trying it out to ensure it doesn't break compatibility.
-
Not sure it helps but I replaced the original SSD1306 0.9" with SH1106 1.3" on my ksger v1.5 and didn't notice any loss in brightness. I can also visually confirm brightness increasing when going > 6 in settings menu. It gets less obvious above 7 but it still gets brighter with each step up to 10. To me, it looks like the software works as intended but hardware quality may vary by batch or manufacturer.
-
Okay, this would be the final version (This time for real).
I realized there's a command that can't be set as ksger does: VCOMH_Deselect_Level.
The parameter value goes up to 0x40 in SH1106, but only to 0x3C in SSD1306/SSD1309.
So it must stay at a value compatible with all.
Is the brightness reduced compared to last test version? If so, it needs to live like that...
And really, I need people with SSD1309/SSD1306 displays to testing it before I publish it!
-
I would say that the previous one were brighter. This FINAL is the same as v1.04.
-
SSD1309 brightness from 6 to 10 has no change.
-
The brightness also depends on a external resistor, so it might reach the limit sooner.
Perhabs I'll add additional display settings to adjust Vcom voltage and few others parameters.
As I said, I can't set that setting like the original ksger fw because some displays are not compatible.
-
So, after few hours, I finally added a new screen for advanced display settings.
Had to figure out a proper way of editing the settings, 0-255 is definitely not the way for editing registers!
So I implemented a new hexadecimal editing widget.
I also discovered my display was SH1106-based (Not SSD1306).
The SSD1306 command "Turn charge pump off" would have no effect, but the SH1106 command did.
So now there's a new "ADVANCED" option in the display menu. Sorry, no translation for that!
Each setting has a different function for its higher and lower 4 bits (Each hex digit controls a different setting).
Please don't start making random changes and asking me to explain everything.
Instead, read the SH1106 / SSD1306 / SSD1309 datasheets.
CLK : Set Display Clock Divide Ratio/Oscillator Frequency.
PRE: Set Pre-charge Period.
VCOM: Set VCOMH Deselect Level.
I played for a while, I could definitely notice a brightness increase with this settings:
CLK : 0xF0 (Minimal diference, mainly affects the refresh rate and the flickering).
PRE: 0x0F
VCOM: 0xFF
KSGER original:
CLK : 0x80
PRE: 0x1F
VCOM: 0x40
Download: Release v1.05 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.05)
-
Thanks David, BTW there is no KSGER_v3_SSD1306.zip
-
Huh? Did I miss a file when uploading? (Yes)
Uploaded!
-
This was really the best option to implement. I like realtime change of settings. I can clearly see how refresh rate impacts the brightness. TNX
I know I am picky but would it be possible to add "default" under three settings.
-
Any ideas to replace that with a regular STM32F103C8T6?
No. STC boards are completely different.
This is not STC, it's an XM1008K6T6, clone of STM32F030K6T6.
Maybe it's using external flash IC since 32k is quite small.
Bob Sava was suggesting it may be using an external flash, but I couldn't find any. Also the RAM is just 4KB.
Seems like there's no way to connect external ram to the STM32F0 mcu family.
I was thinking about ditching the original MCU and rewiring everything to a pico sized STM32F1 dev board, might it work despite being a lot eccentric?
-
would it be possible to add "default" under three settings.
Sure, didn't think about that.
Will update the release in a moment, let me take a morning coffee (It's holiday).
I was thinking about ditching the original MCU and rewiring everything to a pico sized STM32F1 dev board, might it work despite being a lot eccentric?
You could, following any of the ksger v2 schematics, take a bluepill board and wire everything in the same way.
-
Well, I frenzied a lil'bit and made a light interface redesign.
- Now only the editing field is highlighted.
- Sharper widget frame (Not round anymore).
- Added the advanced display reset option.
- Updated the Operation manual to match current features. Huh, it's getting huge! Sometimes I forget it has soo many options!
Lots of changes in the drawing code (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/4416823e810e6e9b060d3ce15de1b8dea573d0d7), I didn't notice any bugs, please report if you find anything strange.
Download Release v1.06 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.06).
-
Finally, I implemented a rudimentary smart load detection, called it "SmartActive".
Every 200ms it stores the temperature error in a circular buffer, keeping the track of the last 3 seconds, then sums it up and compares the restult with the threshold set in Iron settings.
In ideal conditions, the error average will be ~0, but when there's a small load, the error tends to be positive, still very small (It's compensated by the PID), but detectable after all.
A value of 4-5 seems to work nicely, but every station will perform differently.
Likely, it won't work properly with new tips (Very noisy), but otherwise it's doing great with my "tamed" ones, can even detect the heat loss caused by the air when moving the handle around.
Noisy stations/tips: Try tweaking the sensitivity, if still not working, just don't use it!
It's not a different wake source, but an a extra layer working on top of the timers and wake sources.
After setting up a mode, the functionality will be delayed for 10 seconds to give the tip some time to heat up.
When the smart detection is triggered, the shake icon blinks to provide some feeback.
Obviously, it only works in active modes (Boost or Run), smartActiv will keep the current mode active as long as it detects load.
Button and stand modes will keep working in the same ways as before.
Release v1.07 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.07).
-
Hmm, compiler spits out an error in settings.c line 279 when building for ksger v1.5. I stumbled upon it cause I uncommented #define HAS_BATTERY in board.h (that still built error free for 1.06 just a few days ago). I feel like I've seen this error being fixed before. Could it be when you deleted and restored the repository?
../Core/Src/settings.c: In function 'checkSettings':
../Core/Src/settings.c:279:7: warning: implicit declaration of function 'isIronInCalibrationMode'; did you mean 'getIronCalibrationMode'? [-Wimplicit-function-declaration]
279 | if(!isIronInCalibrationMode() && scr_index != screen_debug) // don't persist the temperature while calibration is in progress or in the debug screen
| ^~~~~~~~~~~~~~~~~~~~~~~
| getIronCalibrationMode
arm-none-eabi-gcc -o "STM32SolderingStation.elf" @"objects.list" -mcpu=cortex-m3 -T"../_STM32F103CBTX_FLASH.ld" --specs=nosys.specs -Wl,-Map="STM32SolderingStation.map" -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
c:\program files\stmicroelectronics\stm32cube\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.100.202210260954\tools\arm-none-eabi\bin\ld.exe: ./Core/Src/settings.o: in function `checkSettings':
settings.c:(.text.checkSettings+0x10a): undefined reference to `isIronInCalibrationMode'
collect2.exe: error: ld returned 1 exit status
make: *** [makefile:76: STM32SolderingStation.elf] Error 1
"make -j16 all" terminated with exit code 2. Build might be incomplete.
-
Probably some file was not updated in the commit, will check later.
Edit:
Ahh it was these options never use... Fixed!
-
Thanks for the quick fix.
The battery option/backup register thing's actually a nice reliability feature, plus I have to find use for my stockpiled CR2032 cells. Bought too many at once, and now they are discharging in a drawer :palm:
-
Hey David, I found a bug.
It's on a build from 3 days ago (the 18th) though but it may still be relevant.
. Same thing with latest version.
The wake from shake option where you select whether a shake should wake from ALL, STBY, SLP or OFF doesn't work properly.
When STBY is selected, it will also wake from SLP (so it works like ALL).
When SLP is selected, it doesn't work at all (works like OFF).
OFF is still OFF.
ALL is still ALL.
Edit: In addition, it seems the new smartactive feature generates spurious wake events. I read the manual and saw you're using the shake icon to give visual feedback but I don't think it's intended to reset the sleep timer itself. Anyway, I had to go up to 23 to get rid of ghost wake events. Is it still worth leaving it on or should I turn it off?
Cheers mate.
-
Greetings, long time lurker, first time writer. I'm grateful for this fine piece of firmware!
I'm trying to tweak images. The splash screen for example. What is the workflow changing an image? Here's what I do:
- open Drivers/graphics/gui/screens/boot_screen.c
- copy only the encoded data
- paste it into https://javl.github.io/image2cpp
- press "Read as horizontal" button
As a result I get the attached image. I think is distorted in some way and moreover the "Generate code" button is not responding. What am I missing? I've searched here and read the manual.
-
Not explained because it's u8g2 library, that topic would be described at the u8g2 manual (https://github.com/olikraus/u8g2/wiki/u8g2reference#drawxbm).
XBM is another image format, use an online converter such as:https://www.online-utility.org/image/convert/to/XBM (https://www.online-utility.org/image/convert/to/XBM)
Edit: Updated the xbm structure, should be more straightforward now: Commit (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/boot_screen.c)
Open the XBM as text, copy/paste the content, adjust the width/height.
xbm_t splashXBM = {
.width=128,
.height=64,
.xbm = (const uint8_t[]){
>> XBM CONTENTS <<
},
};
ygi, as said, smartActive is pretty simple and depends entirely on sensing the temperature drop, I don't think there's another way, we have crappy sensing interface, no current detection...
As always: No miracles can be done with such basic hardware.
It already reads the filtered values, but if you're adjusting it so low that it detects every time you're soldering something, you'll get also false detections.
You only need one correct detection before the sleep timeout to keep running.
How do you keep it running but not by resetting the timeout?
Will have a look at the wake issue.
Edit: Fixed, commit (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/07a1560cf88fc16bac02373189b9f30a9a63294c), Download v1.07.3 Release (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.07.3).
-
Oh, got it, I totally misunderstood what smartactive's about.
Somehow I thought it's a new way to improve t° compensation while the tip's loaded so in that context it didn't make any sense to mess with wake events. |O
On top of that the mercury switch I put in my iron's already a lot more sensitive than the ball based one and works almost flawlessly while soldering. Sorry for the nonsensical question and thanks for fixing bugs at this time of the year.
Merry Christmas!
-
Yeah, but it's interesting if you don't use the shake sensor at all, wake with thebutton and it'll keep going as long as you use it ... in theory... ::)
Yeah, Merry Christmas and all that! :D
-
Hey David, I wonder is it possible to use another MCU in the same source code? For example STM32F4 instead of STM32F1? If yes, how to do? Sorry I'm a newbie.
-
Everything is possible, but work would need to be done, it's using HAL, migration should be a lot easier.
But you'll have to figure out yourself! Why not get a simple STM32F101/2/3?
-
Because STM32F401CCU6 - Stm32F411Cu6 in my place is very cheap, the price is just a little more than stm32F101/2/3. and I found the specs of stm32f4 to be completely superior to that of stm32f1. If you have a little guidance from you, that would be really great. and I also have a black palette like yours mentioned two years ago
-
Why does it need more power?
It runs fine even on the slowest 36MHz 32F101.
Actually it can run easily 10-15x faster, if not more, it just doesn't make sense for this application.
Would you see anything if the screen changes 100 times per second?
You can actually do so by reducing the GUI time and increasing the sampling frequency in the menu settings.
That message with the 32F411 BlackPill was just for showing, I never developed this firmware for it.
The idea was to buy your ksger/quecoo station and out a new firmware in it in a simple way, in fact a lot of effort was put to make it fit in the smaller 10KB RAM devices.
So anything better, faster, larger will simply waste resources.
I value my time, why would I spend hours in something that will make no difference or benefit in the end?
This is OpenSource firmware, not free personal programmer ;).
Better get the 32F103CB and use it as-is.
-
Yes. exactly as you said. thank you very much!!
-
You have the SWD header, just use your eyes, follow the programming guide:
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md
-
Hi Guys. I found that great thread from DavidAlfa signature. I have old T12 soldering iron with 7 segment LED controller diy module. I think it is time to upgrade. My main soldering station is mine Ersa I-con 1 but the T12 chinese tips are much cheaper and that custom firmware is great. What models of soldering stations are you recommend for it. Quicko or KSGER? I saw that Quicko soldering stations are cheaper but i diidn't know how it is quality compared to KSGER. Also Quicko stations are so many different models. I can't understood main difference between them. I see most of them have different T12 handles but I want to buy best one for that cutsom firmware.
-
Have a look to the github pages for compatibility, most statiosn are described there.
The only requirement for the CFW is it must have a STM32, some have STC which is a totally different CPU.
Otherwise, most them are 99% the same!
KSGER is usually overpriced, so I'd go with the cheapest Quecoo/Quicko/Handskit, also they are usually more stable in their analog readings.
Better ask the seller if they're making them with genuine STM32.
Lately, lots of them are coming with clones which won't work properly with some advanced features of the CFW.
-
Happy new year 2023 David.
Thanks for the info. I maybe will try to buy some of that Quicko soldering stations. If they used clones I will make try to replace STM32 mcu with genuine one. I also examined Quicko schematics. I figured out that cheap chinese stations used not very good OPAmps with large input offset for amplifying signal from thermocouple. KGSER ver 2 have better opamp with low input voltage offset. Is that a problem for calibration and accuracy of measurement of temperature.
Years ago one Bulgarian guy "sparkybg" made similar to your project for universal soldering station controller "Unisolder" which used very complicated circuit: https://github.com/sparkybg/UniSolder-5.2
-
Offset can be calibrated in the CFW, it's called "Zero cal".
-
Happy New Year!
-
Hallo, i have a KSGER 3.1 with a MM32. I replaced it with a ST32F103 (CKS32F103C8T6) from a blue pill.
It boots up but the display jumps between NTC to high, voltage to low and Temperature. Is the IC incompatible?
-
If you posted that screenshot, you already read the clone detection intructions (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#clone-detection) and know the ID doesn't match!
Superfake STM32!
-
Yes i read the manual, I had hoped that the cks32 would work as described :-[
It is hard to become a genuine chip direkt in Germany.
-
Where do you see it's a CKS32? To me it's a badly relabeled attempt to pretend it's a genuine part.
256K flash? Could be, 0x414 stands for stm32F10x high density device, which is extremely rare in a BluePill.
Probably not even a CKS32!
I recently bought few stm32 (Not 103) from aliexpress, they were genuine and working nicely.
I would try there. If the ID is not original, claim your money back and try again.
Remember you can get any 101 / 102 / 103!
-
I get it here : https://www.ebay.de/itm/253369088499 (https://www.ebay.de/itm/253369088499)
Next try is reichelt.de, a good electronic shop.
-
Got mine (F103C8T6) from this AE seller https://www.aliexpress.com/item/1005003169244854.html (https://www.aliexpress.com/item/1005003169244854.html) a few months back. It's got genuine chip ID. Though that's only if you can wait several weeks (plus Chinese new year holiday should soon add to the delay).
-
I wish I could find the major difference causing the ADC to fail in clones, so I could try some workaround.
From all I bought, I never got clones ::), except only once, back in 2020, used that one for something inside the car.
It would be great if anyone removed their clone and could send it to me using the cheapest ship method (Letter, etc).
-
I can send you my clone, PN me the address.
-
PM sent :-+
-
Hello guys, maybe it's a bit wrong thread, but I am looking for CFW compatible T12 soldering station + hot air gun and need your advice what to purchase. I know that 858D is most recommended hot air gun, but would like to have a compact one, so after searching through aliexpress for few days got these options:
Handskit:
Hot air - https://www.aliexpress.com/item/1005002965789645.html (https://www.aliexpress.com/item/1005002965789645.html) - (pros: cheapest one, separate gun stand; cons: not sure about overall quality, has calibration issues, requires replacement of some resistors and adding case grounding)
T12 - https://www.aliexpress.com/item/1005003155390894.html (https://www.aliexpress.com/item/1005003155390894.html) - (pros: cheapest one, has stand and ok handle I guess; cons: also not sure about overall quality, and about MCU used in latest versions (vendor could cheap out and use STC boards, those are used in their same stations but with external PSU), OLED with not standard pinout and low brightness)
* I don't mind some HW rework if overall their HW design in terms of schematic and elements placement is ok.
Quecoo:
Hot air - https://www.aliexpress.com/item/1005004884759470.html (https://www.aliexpress.com/item/1005004884759470.html) - (could not find any reviews)
T12-955 - https://www.aliexpress.com/item/1005001608493682.html (https://www.aliexpress.com/item/1005001608493682.html) - (pros: price is good, especially with 5 tips (not sure about their quality), CFW compatible; cons: slow I2C display)
T12-958 - https://www.aliexpress.com/item/1005002724765690.html (https://www.aliexpress.com/item/1005002724765690.html) - (pros: SPI display and some HW updates as told by vendor (?), CFW compatible; cons: price)
T12-958 V3.1S - https://www.aliexpress.com/item/1005003302164155.html (https://www.aliexpress.com/item/1005003302164155.html) - (what is the difference vs T12-958?)
* both have sturdy aluminium handle, but I'm not sure about how fast it will get uncomfortably warm during long soldering sessions.
** also are these T12 both have best HW implementation in terms of grounding or only 958?
KSGER:
Hot air - https://www.aliexpress.com/item/32844169715.html (https://www.aliexpress.com/item/32844169715.html) - (pros: non hazardous connection of heat gun, saw review on youtube, looks like it's all good, but it wasn't indeep review, so don't know does it need any HW changes or not; cons: price)
V2.1S - https://www.aliexpress.com/item/32871815985.html (https://www.aliexpress.com/item/32871815985.html) - (pros: same as Quecco's; cons: price)
V3.1S - https://www.aliexpress.com/item/4000453770565.html (https://www.aliexpress.com/item/4000453770565.html) (pros: same as Quecco's; cons: even higher price, especially with decent handle)
Some paired devices:
858DS - https://www.aliexpress.com/item/1005003801198284.html (https://www.aliexpress.com/item/1005003801198284.html) - (don't know what's inside, there are any reviews)
KSGER 1 - https://www.aliexpress.com/item/33040946949.html (https://www.aliexpress.com/item/33040946949.html)
KSGER 2 - https://www.aliexpress.com/item/32843211322.html (https://www.aliexpress.com/item/32843211322.html)
* as I understand none of these are supporting CFW?
Also was looking at OSS T12-X, T12-959, KSGER V2.3 - they are good overall, but have dimm display or bad color scheme (red-white or red-blue, like wtf) and I need CFW for ability to store calibration of different tips and none of these have this option.
P.S. What do you think about this handle https://www.aliexpress.com/item/1005004143441464.html? (https://www.aliexpress.com/item/1005004143441464.html?) I like it's design and flexible strain relief part, but looks like overall it's like 9501 and other plastic handles, those may become soft close to the tip during long time soldering at high temp or does it have better plastic, maybe someone using it?
P.S.S. I've seen Handskit T12 with silver front panel, not sure what is the difference between them, but possibly there is STC controller in the one with black panel, can anyone confirm?
-
After a very long day fighting the clone sent by CRS84 (Thanks! :-+) I think I found the way to make clones work!
Got some hints in the Air32F103 docs:
https://wiki.luatos.com/chips/air32f103/switchFromSxx.html#adc
I tested literally hundreds of combinations!
I hope all these clones use the same ADC base, otherwise fixing the firmware for all of them will be impossible!
I managed to get it in a simple menu entry, "Clone fix", in SYSTEM menu.
By default it works in "Genuine" mode, so it will still jump around with clones.
Enable the fix in the menu, it will reboot automatically afterwards and hopefully start working nicely.
I need testers! Anyone with a fake STM32 in their KSGER / etc?
New release available! (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.08)
-
I just received my first KSGER, and it has an MM32 inside. |O
BTW, it is the plastic case version (not aluminium) and it has all "ChongX" capacitors inside.
SMD work is very risky with my limited skills. So, is desoldering and replacing it with an STM32 my only option, or could the custom firmware support MM32 in the future?
-
Not in my current plans, neither I have any MM32 myself, but it's pretty different, not just a clone, also it can't be programmed with a Stlink.
You have this alternative firmware for MM32:
https://github.com/koendv/t12-958
-
BTW, I just discovered this project :
https://github.com/wagiminator/ATtiny13-TinySolder
It's a minimalistic hardware+firmware for T12 irons: only 200 lines of code, including temp control, sleep and wake ! :o
-
Good day,
a friend of mine gifted me a new Quicko soldering station.
(https://i.ibb.co/j3XKvSz/photo-5927191698004360087-y.jpg) (https://ibb.co/j3XKvSz)
I'd like your project and i want try to install the cfw, but unluckily i did not understand what version of cfw to install. It seems that is installed a CKS32.
(https://i.ibb.co/8927Hcn/photo-5927254271382895653-y.jpg) (https://ibb.co/8927Hcn)
The board seems really like the one in deividAlfa repository:
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/Quicko/Schematic/SWD%20connection.jpg (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/Quicko/Schematic/SWD%20connection.jpg)
Considering number of pin of oled it seems "first gen Quicko, easy to differentiate.!"
I also looked in dreamcat4 repository, but i did not found any hint.
I connected it to the pc:
(https://i.ibb.co/XxFym5J/Cattura.jpg) (https://ibb.co/XxFym5J)
1) What version will fit?
Quicko_STM32F072_SSD1306.zip
Quicko_STM32F072_ST7565.zip
Quicko_STM32F103_SSD1306.zip
Quicko_STM32F103_ST7565.zip
Thanks and Regards
-
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/Quicko/STM32F103
-
https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/Quicko/STM32F103
Done with Quicko_STM32F103_SSD1306 , not fully tested but seems passed.
-
If it works, it's the correct one, simple as that :-+
-
David, in the doc you mentionned possible issues with KSGER's voltage regulator and suggested to "replace the LDO with a better one".
Any specific tech parameter to look for when selecting a better one for that job?
-
Your options are also described there.
Note that only few older boards are affected, newer ones rarely use that design.
-
At my KSGER station I had an empty place for an additional linear regulator and an additional connector from it at the PS board. I soldered 7805 regulator there and added a wire to the mainboard (replace the stock with a three pin). All the adc readings are OK now. If you wish - I can make a photo of this mod.
-
Hi guys today decided to upgrade software to DavidAlfa, tried to fit connector from STlink board but it did not fit into Quecoo board, any tip how to solder/connect it?
-
This connector's obviously the wrong size. Either use one that fits the hole spacing for your board or you can solder wires between the holes and connector legs and protect it with heat shrink wrap.
-
Hey David,
just one question about PWR_ADC. Why do you measure the supply voltage? Just for showing it on the screen or do you need it for controlling e.g. pwm?
I plan to use your FW for controlling JBC high power iron. (48V instead of 24V). It should be possible with a few small HW changes.
Thanks & regards
Chris
-
Hi guys today decided to upgrade software to DavidAlfa, tried to fit connector from STlink board but it did not fit into Quecoo board, any tip how to solder/connect it?
ive in some cases pulled out the pins and just soldered them making sure they are straight up into each hole and add a small piece of heat shrink towards the board side then you can plug the separate wires onto each pin.
-
i double checked and all of mine are using real stm chips. if anyone has a knock off they want to send im happy to solder one in place of an stm and give it a shot. just lmk
-
Hey David,
just one question about PWR_ADC. Why do you measure the supply voltage? Just for showing it on the screen or do you need it for controlling e.g. pwm?
I plan to use your FW for controlling JBC high power iron. (48V instead of 24V). It should be possible with a few small HW changes.
Thanks & regards
Chris
For power limiting too.
For example, you can power a tip designed for 12V with 24V. The pwm will be limited to 25% so the effective power never exceeds its rated power
-
Good to know, so using a 24V iron with 48V supply voltage should be also possible.
I'll order some parts, also an tweezer and share my project details. 8)
-
Hello, David.
While I was researching the market for T12 stations, I noticed that the HANDSKIT ones offer an alligator clip to be placed on the metal stand that puts the iron into sleep mode as soon as the tip makes contact with the holder. I guess that's done internally using one of the STM32 GPIO pins?
Does your firmware support that feature? It would be great for Handskit owners.
-
JBC style handles like this C210 do not come with an internal vibration sensor. Instead, the stand itself is grounded and touching it will pull down the wake signal pin (same one that's used by the shake sensor but used differently). David's firmware supports that (check "wake mode" in operation manual (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md)). I have no idea whether that specific station is supported or even comes with STM32 (or compatible) MCU though.
-
In the case it actually uses a stm32, I'm pretty sure it'll be a "standarized" board, probably following the ksger V2 design.
-
On a side note, as I was browsing around, I noticed that the same company also sells a similar-looking unit but with a heatgun. And guess what? It´s an STM32 too! :clap:
David, hot air stations need a better firmware as well ! You could start a new project!
These units are cheap. Think about it.
-
I won't anytime soon neither in my planning at all, I have a life!
-
I'm sure I can find enough junk with trash tier firmwares on aliexpress to keep you busy for your next 10000 lives >:D
-
I haven't powered the computer for at least 15 days now..., too busy ;)
-
On a side note, as I was browsing around, I noticed that the same company also sells a similar-looking unit but with a heatgun. And guess what? It´s an STM32 too! :clap:
David, hot air stations need a better firmware as well ! You could start a new project!
These units are cheap. Think about it.
To bad its FAKE STM32 ;)
-
David, I have a problem with the LCD display. When turned on, the display works normally. And when the soldering iron handle is on the stand and the soldering station is in Stand By mode, then artevacs appear on the screen, as in the photo. It may even be a completely black screen.
The only way out of this mode is to restart the soldering station.
Latest firmware: January 2023. Firmware from May 2022 - also.
-
David, First I would like to thank you for this great firmware, Since I don't have a single soldering station I made the board myself from the KSGER t12 V3 schematic, I made 2 boards, 1 board as normal soldering stations normal and modular. All connection to OLED screen works perfectly, but connect to ST7565 2.4' LCD just black screen, pins connected correctly, I tried to connect with KIT board stm32fc8t6 Blue Pill and it works fine often. Is it due to noise? I used an extension cord about 20 to 30cm long.
-
Sorry if this has been answered before, but I can't find any details about it in the github repo docs - how does the wiring work for 210 and 245 handles?
I see way back in the thread there are some pictures of traces needing to be cut to support non T12 handles, is this still required? I read somewhere that the T12 has a 10k NTC between P- (pin 4) and ID (pin 2), T245 shorts P- and ID, and T210 is open circuit between P- and ID, is this the most recent way of supporting multiple handles? Do people also add their own motion/mercury switch (part number?) to pin 1 on the GX12-5 when using non T12 tips to allow standby functionality?
Ideally, I'd like to be able to swap between a T210 and T245 handle - is this possible?
-
All your wishes are possible.
Unfortunately, I do not speak English well to describe in detail all the nuances.
The photo shows one of the circuit options with two different connectors (so as not to confuse). It is possible to do it differently - with one connector.
The main difference between T12 and T245 is that the T245 has a separate conductor from the thermocouple, while the T12 has a common one.
-
Thanks, so there are no mods to the PCB? All the feedback gains are ok with the different tip impedances?
The JBC210 tips look more like the T12 pinout from here https://www.eevblog.com/forum/reviews/modify-aixun-t3b-to-work-with-t245-c245-and-t12-cartridges/ (https://www.eevblog.com/forum/reviews/modify-aixun-t3b-to-work-with-t245-c245-and-t12-cartridges/) so it looks like the same wiring diagram can be used for the T12 and T210?
Did you have to source the NTC and motion/mercury switches for the non-T12 handles? It looks like most of the non-12 handles are used with a stand so don't have the motion switch built in. I'm a little confused about the NTC, I see some circuits have it in others don't, I assume the ones that don't have it are using the MCU temp or a NTC in the chassis as the cold junction compensation of the thermocouple?
-
C210 and T12 are very much the same thing, heater+thermocouple in series, just different signal output.
C245 however has independent TC and heater pins, so yeah, you must modify the PCB, cutting the trace going to the amplifier, normally connected to T12+.
Then, T12/C210 handlers must bridge heater and TC pins in the connector, while C245 doesn't.
-
David, a big request to make in the firmware in the 'Standby time' section between positions 0 and 1 minute: 10 seconds and 0.5 minutes.
I'll explain why: I use the T245 with a stand. If you use the 'Stand mode' mode, then when you place the handle on the stand, the 'Standby' mode turns on immediately and the tip cools down. When soldering with short breaks and often placing the soldering iron handle on the stand, I would like to have a slight delay in turning on the 'Standby' mode.
So I use the 'SHAKE' mode, but with a stand. In this mode, you can select a delay. But 1 minute is a lot.
For AiXun T3A, this delay can be set in seconds.
P.S. Today I also tried different modes. In the "Shake" mode, it is also inconvenient to work with the stand. The optimal solution is in the "Stand" mode to make an adjustable transition delay in "Stby".
-
I don't have a station to test on but it looks like you should be able to edit the `[ Stby Time Widget ]` and the `getStandbyTime/setStandbyTime functions` in Drivers/graphics/gui/screens/iron_screen.c
Instead of 60000 ms increments try 10000 and you'll get 10 second increments with each step of the rotary switch.
-
Hello, David.
The release zip files in https://github.com/deividAlfa/stm32_soldering_iron_controller/releases (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases) are RAR compressed, but they are wrongly renamed as ZIP. This could make some people fail to uncompress them after downloading. |O
Just my 2 cents....
Also, the mirror link to PTDreamer's original blog seems dead?
-
I have literally zero time. I'll check these questions in the weekend.
A new delay for stand mode could easily implemented here (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Src/iron.c#L142) plus adding a new menu item.
-
The AiXun T3A soldering station is made as in the photo.
I meant the second point - the timer when placing the soldering iron handle on the stand
-
Sorry for the delay, life is not giving enough free time lately!
- Added Stand delay (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/feea073e0562dbf38229d8cb0148124f1e6db5cf), shown under IRON menu when set to stand mode.
- Apparently, rar.exe can only create RAR files. Use 7-ZIP instead, plus it's free. Fixed the Release script (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/a740573c52815122fca807e8951ddf9713363b10).
- New release v1.09 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.09). Settings version changed, so they will be erased on first boot. Backup your tips settings!
-
Does the soldering stations and hot air rework stations use the same firmware?
I'm considering buying a hot air station (specifically this one (https://www.aliexpress.com/item/1005002966228147.html?spm=a2g0o.detail.1000014.1.60d72b62QJ413j&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.40050.281175.0&scm_id=1007.40050.281175.0&scm-url=1007.40050.281175.0&pvid=4a362f6e-eac4-4249-aec4-e742c060f17d&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.40050.281175.0,pvid:4a362f6e-eac4-4249-aec4-e742c060f17d,tpp_buckets:668%232846%238110%231995&isseo=y&pdp_ext_f=%7B%22sku_id%22%3A%2212000032212692693%22%2C%22sceneId%22%3A%2230050%22%7D&pdp_npi=3%40dis%21SEK%21684.71%21547.74%21%21%21%21%21%402103239e16778364301017563e25de%2112000032212692693%21rec%21SE%21125083867)), but want a way to disable the clock and the "usage timer" as I have no use for those showing.
-
Hello everyone! Does the display need SSD1306? Will it work with the SH1106 driver?
-
Does the soldering stations and hot air rework stations use the same firmware?
No.
I'm considering buying a hot air station (specifically this one (https://www.aliexpress.com/item/1005002966228147.html?spm=a2g0o.detail.1000014.1.60d72b62QJ413j&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.40050.281175.0&scm_id=1007.40050.281175.0&scm-url=1007.40050.281175.0&pvid=4a362f6e-eac4-4249-aec4-e742c060f17d&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.40050.281175.0,pvid:4a362f6e-eac4-4249-aec4-e742c060f17d,tpp_buckets:668%232846%238110%231995&isseo=y&pdp_ext_f=%7B%22sku_id%22%3A%2212000032212692693%22%2C%22sceneId%22%3A%2230050%22%7D&pdp_npi=3%40dis%21SEK%21684.71%21547.74%21%21%21%21%21%402103239e16778364301017563e25de%2112000032212692693%21rec%21SE%21125083867)), but want a way to disable the clock and the "usage timer" as I have no use for those showing.
The Handskit stations I've seen have absolutely no QC. Bad solder joints, misaligned components etc. I have the equivalent KSGER hot air station which is OK, or maybe just less crappy.
BTW, I'm working on a Swedish manual for this firmware, might be available soon.
-
David, a big request to make in the firmware in the 'Standby time' section between positions 0 and 1 minute: 10 seconds and 0.5 minutes.
I'll explain why: I use the T245 with a stand. If you use the 'Stand mode' mode, then when you place the handle on the stand, the 'Standby' mode turns on immediately and the tip cools down. When soldering with short breaks and often placing the soldering iron handle on the stand, I would like to have a slight delay in turning on the 'Standby' mode.
So I use the 'SHAKE' mode, but with a stand. In this mode, you can select a delay. But 1 minute is a lot.
For AiXun T3A, this delay can be set in seconds.
P.S. Today I also tried different modes. In the "Shake" mode, it is also inconvenient to work with the stand. The optimal solution is in the "Stand" mode to make an adjustable transition delay in "Stby".
Hello @yelkvi.
I have a soldering iron c245 with jack like the picture attached. It can be used for ksger v2.1s circuit or not. Can you guide me how to wire with gx12-5 jack.
Thank you very much.
-
Hello @yelkvi.
I have a soldering iron c245 with jack like the picture attached. It can be used for ksger v2.1s circuit or not. Can you guide me how to wire with gx12-5 jack.
Thank you very much.
1. ksger 2.1s controller can be used for T245. But it will take a little tweaking.
2. The power supply will need to be changed. Because T12 needs 24 volts 3 amps, and T245 needs a power supply twice as powerful: 24 volts 6 amps.
In addition, you will have to replace the connector on the soldering iron handle (you can buy it on Aliexpress).
Are you ready to make these changes?
-
1. ksger 2.1s controller can be used for T245. But it will take a little tweaking.
2. The power supply will need to be changed. Because T12 needs 24 volts 3 amps, and T245 needs a power supply twice as powerful: 24 volts 6 amps.
In addition, you will have to replace the connector on the soldering iron handle (you can buy it on Aliexpress).
Are you ready to make these changes?
Thanks for the feedback, here is my circuit board (picture attached).
1. What do I have to fix this circuit? and how it is.
2. I already have a 24v 8.3A industrial adapter.
3. Can you send me the link to the connector you said on Aliexpress.
4. And when there is a connector, can you guide me to connect the wires.
Best regards.
-
On this page, at the top, I showed part of the connection diagram for T12 and T245.
The difference is that the T12 thermocouple is connected together with the heater and is connected with two wires, while the T245 thermocouple is connected with a separate wire.
Therefore, in the controller, it is necessary to break the connection with the '+' to the input of the operational amplifier and connect it with a separate wire.
Take a good photo of your controller board from both sides.
I can’t give a link to Aliexpress - I have my own store in Russia - this link will not work for you. Therefore, look in the store (pictured), GX12 5pin
-
No.
:-+
The Handskit stations I've seen have absolutely no QC. Bad solder joints, misaligned components etc. I have the equivalent KSGER hot air station which is OK, or maybe just less crappy.
Good to know, thanks! I guess that explains why it's so much cheaper...
Not to mention the fact that the name is... questionable... here in Sweden.
I might still give it a go, though, as money is tight and I consider myself competent enough to fix the factory sloppy job.
BTW, I'm working on a Swedish manual for this firmware, might be available soon.
:-+
-
Yes, SH1106 works fine with the SSD1306 build.
-
...
I would like to send you back a picture of the back of my circuit. The previous circuit is tightly soldered so I can't open it.
Thus, with 3 ropes green, red, and blue. How do I connect the pins of gx12-5.
Thx.
-
According to your photo of the soldering iron handle:
green is '-'
Blue - '+'
red - thermocouple output.
Cut the J1 on the board (photo)
You also need to decide how the soldering station will go into standby mode.
Your T245 doesn't have a vibration sensor like the T12.
Either insert the vibration sensor into the handle (you will also have to change the wire of the handle - there are few wires in yours), or (as David showed here before) make the sensor in the stand. Which will close the 'S' contact of the controller to '-'.
Also in this pen there is no NTC temperature sensor. But this issue is easily solved in the controller settings (disable NTC).
-
Thank you. and in case I have 5 wire type and have thermistor, vibration sensor switch, please help me how to connect.
1. Connect the resistor, vibration sensor, red, white, green, blue wires to the c245 controller circuit (picture below).
2. How to connect the wires to the gx12-5 jack.
Thank you again
-
Do it in this way:
-
Do it in this way:
Thank you very, very much.
-
David, thank you very much for the latest firmware.
Everything works very well!
-
David, I noticed this nuance:
If you put the soldering iron handle on the stand, the delay timer will turn on (for example, 10 seconds). But if the handle is removed from the stand before 10 seconds, the timer is not reset. And after 10 seconds, the soldering station goes into standby mode.
When you have free time, please fix it.
-
Fixed (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.09.1) :)
-
Thank you. I'll check tomorrow and post the result.
-
Now everything works correctly. Thank you very much!
-
I have a problem. My board is the queco green one from github. Moded for c245 handle (not cuting via) and added one wire from c19 to c7. Handle with gx-12 6pin and mesuring plug with SK tip i got: Heater-Gnd is 3ohms, TC-Gnd ~0.7ohms, Heater-TC ~3ohms. So eather i have broken tip and short in the tip or i dont know. When i remove tip there is no short. Set voltage to 24V and chage in system to c245. When i try to calibrate the station reset itself. What im missing? The firmware v1.09.1 for 1306 oled(one without specifiing oled version like in the older relese)
-
C245 have ~2.6ohms, you can't drive them with most 72W PSUs, they will just overload.
You should measure something like this:
- Heater-GND : ~2.6 Ohms
- TC-GND: ~0.7 Ohms
- Heater-TC: Sum of both (~3.2Ohms)
Try setting the power limit to 80W and increasing the PWM multiplier to 10x, so it runs at 50Hz instead 5Hz, the PSU will forgive shorter pulses easier than heavy, long ones.
If still resetting, try setting ADC time to 100 or 50 mS, with the PWM multiplier still set to 10x, so it runs at 100/200Hz.
-
THX. That give me heating and all now no restart. Only calibration is an error at this power. at 250 during calibration i get max 165.3. So only solution is to replace PSU, thats sad, The psu i use 108W 24V 4.5A
-
TC response is not linear so the error will be huge if trying to calibrate with >50°C Target vs Real difference.
In that case,.the calibration fails and tells you to follow the manual procedure under Calibration/Adjust.
If getting the generic "Error, aborting!" message, the system is unstable, too noisy, triggering tip detection error.
Read the manual at Github! :)
-
I know it give me an error. on t12 setup i have planty of tips calibrated. Thx for all the help will order better PSU. Thx again for help and firmware.
-
Try enabling the debug menu and watching the TIP values at ex. 300°C.
If it jumping like crazy (The RAW reading will, it's unfiltered), then it's probably the PSU.
My Quicko did pretty well with JBC, has the 108W PSU.
Can't help much more, consider making a video of the debug screen.
-
David, what are the optimal PID settings for 245?
You posted here earlier for T12. And these settings are very different from those in the firmware.
-
Ok after using manual calibration on 250 and 400 and setting: 250 value 1390 and 400 value 2320 and then auto calibartion for every tip all works fine. Tem is ok no jumping or anything weard. PWM multiplayer is still at 10 and power at 110W. No problem now. I try secound PSU from diffrient unit i have same behaviour. Temp is check with fg-100 so i guess im in clear. On diffrent question. On standby/sleep i hear light buzzing sound after heting started the buzzing deaspierd. No problem just curious. Debug screen 300 on fg100
https://youtube.com/shorts/n1aSUF5qnvU
-
Yes, that's the tip detection routine, before reading the TC it outputs a very short pulse.
Normally it's barely noticeable, but reducing ADC time will make it noisier.
If you added a 1M resistor between Heater and 3.3V (Or 10M across the MOSFET drain and source) then you can disable the "Active detection", noise will go away.
Also, now it's working you can try lowering the ADC time back to 200ms, then lowering the PWM multiplier, adjust so it doesn't reboot when fully loading the tip, this will reduce the noise.
I can't tell the optimal PID settings, it's depends heavily on the filtering, the ADC frequency, the calibration... It would be easy if we had only one controller type, but there'ro dozens of variations.
-
Ok so i will live active detection alone that useful safty feature. I lowered to 200ms and 2multiplayer. And i use t12 and c245 just changing system setting. Thx a lot again. Now i need to tweak PID slightly because it overshoot from 360 to 372. I can work with that after years od PID tuning drones. The only thing on c245 dosnt work perfect is reading room temp at idle. I zero in calibration on cold tip. The most important thing i can use jbc tips and t12 so i dont need 4th soldering station.
-
Don't worry about it, that overshoot doesn't really reach the tip, also most stations do this, they just hide it.
10°C is negligible anyways, 360 vs 370 °C don't make a difference at all.
Trying to get it like a 0.01% lab equipment is simply a waste of time.
If you're using chinese C245 tips, just don't, stay with T12, they're absolute crap, performing worse than T12.
Only genuine ones worth it.
-
I have jbc one and jabe. Both perform the same for my short test for now. Time will tell
-
David, I have a problem with the LCD display. When turned on, the display works normally. And when the soldering iron handle is on the stand and the soldering station is in Stand By mode, then artevacs appear on the screen, as in the photo. It may even be a completely black screen.
The only way out of this mode is to restart the soldering station.
Latest firmware: January 2023. Firmware from May 2022 - also.
Sorry, didn't read this before.
Hard to tell, those artifacts are usually caused by data transmission issues, like too long tracks, badly routed (Picking nearby interferences), bad connections, poor VDD filtering...
It's a common thing in DIY stuff.
You could try opening the .ioc file for your board and change the SPI prescaler to a higher value, so the SPI frequency is lower, compiling afterwards.
-
David, thanks for the answer. I once again disassembled and reassembled the soldering station. Flashed the latest firmware. And now the indicator is working fine. What was the cause of the artifacts - I do not know. The conductors that connect the display to the controller board are very short ~ 1 centimeter.
-
You could shield clock and data, twisting each wire with another one, grounded at both sides.
-
If the problem repeats, I'll try to make shielding.
-
Pardon me if I should have found this in my searching and reading, but is there a go-to open source hardware design that runs this firmware?
It feels ripe for an option of "Go to JLCPCB, upload these files, and they'll build and assemble one for you, then just get X enclosure, install PCB front and back panel, plug in Y power supply, and you're done and have a known good design". (Obviously it's only this easy because of all the work already done reverse engineering and developing all the firmware though.)
*Starts rocking back and forth mumbling* Must not start a new project...must not start a new project...must not start a new project... :scared:
-
Nope, there's no such open hardware project for this firmware. I'm pretty sure you could find gerber files for ksger/quicko controller boards but calling them open source would be a stretch.
-
The original thought was to document the various KSGER and Quicko boards with the hope that someone created a better, open source version that worked with an improved, open source FW (which there was a promising avenue at the time this thread was started but it worked on limited HW, this was before Dave stepped up and developed his FW). Since Dave's firmware works with various brands with slightly differing HW, there appears to be less of an appetite to develop the HW end. I agree that with a mature firmware, this is ripe for someone to develop an open source HW solution that is better than what KSGER and Quicko and others sell.
This is well beyond my capabilities, so I am not in any way shape or form volunteering, but I would encourage anyone with this talent and inclination to give it a try and I'll cheer that person on. I am a bit surprised because the Unisolder project appears to be very popular, this seems like it might be simpler, albeit with fewer choices in handle (predominantly T12 and various JBC handles, while Unisolder's claim to fame is the ability to adjust it to almost any commercially available soldering handle).
-
Pardon me if I should have found this in my searching and reading, but is there a go-to open source hardware design that runs this firmware?
It feels ripe for an option of "Go to JLCPCB, upload these files, and they'll build and assemble one for you, then just get X enclosure, install PCB front and back panel, plug in Y power supply, and you're done and have a known good design". (Obviously it's only this easy because of all the work already done reverse engineering and developing all the firmware though.)
*Starts rocking back and forth mumbling* Must not start a new project...must not start a new project...must not start a new project... :scared:
I asked the same question, David has a board designed already:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3677089/#msg3677089 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3677089/#msg3677089)
https://www.eevblog.com/forum/microcontrollers/fan-controller-with-pwm-using-stm32-chip/msg3594990/#msg3594990 (https://www.eevblog.com/forum/microcontrollers/fan-controller-with-pwm-using-stm32-chip/msg3594990/#msg3594990)
-
That board is basically a Quicko, sort-of-enhanced layout, done on a rainy day, untested, also probably unfinished.
-
It's all in David's instructions.
Read carefully.
Display 4 PIN means V2.
V3 for 6PIN display.
-
the new ksger vs oled firmware if i go into calibration then to settings i get "error detected aborting!" any idea why possibly?
-
Could you explain better how to reproduce the issue?
AFAIK, nothing has changed in calibration for a long, long time.
BTW, how's your eyesight going? :)
-
i go to the calibration menu select settings and see that message. not really sure how else to explain it??
-
With tip inserted? There must be a tip present both for calibration and settings (Because you calibrate the amp offset there).
-
yes correct. let me try a reflash just for the heck of it ill erase and re flash sometimes ive seen some odd things and a reflash worked. ill let you know when i get home.
-
...is there a go-to open source hardware design that runs this firmware?...
times ago I'm found this project https://www.hackster.io/sfrwmaker/stm32-based-soldering-and-rework-station-e3955b (https://www.hackster.io/sfrwmaker/stm32-based-soldering-and-rework-station-e3955b)
open source pproject T12 iron and hot gun based on bluepeel, But it has own open sofrware
-
Does anybody have a wiring diagram for a JBC C210 handle? Been struggling to correctly wire it to a GX12-5 connector and can't get it to work (NTC low/high errors).. My station is a KSGER T12 V2.1
-
(NTC low/high errors)..
The C210 handle does not have an NTC resistor like the T12.
Therefore, you need to either mount it, or disable NTC in the settings
-
Did it work with the T12? Otherwise it might have a stm32 clone.
-
What would be the correct way to calibrate BCF1 tip with FG-100 device? It has really small contact area of it's tinned surface, should I place it straight on the sensor or with it's side area (even if it is chrome plated) like any other small tips with bigger tinned surface (I and J series)? Because difference may be around 15-20 degrees at 300-350 range depending on the placement. Currently my calibration looks like this (all tips are burned in, using good blob of solder on the probe, adding a bit of rosin flux to refresh it when solder becomes mat, keeping tip on the sensor around 5-7 seconds and moving around to find hottest spot, letting sensor to cool down between measurements):
BCF1 - 250: 1875, 400: 3300
BCF2 - 250: 1800, 400: 3075
BCF3 - 250: 1675, 400: 2750
J02 - 250: 1800, 400: 3175
D52 - 250: 1700, 400: 2750
Is it ok that BCF1, BCF2, J02 are measured 380 C when set at 400 C (BCF3 - 385 C, D52 - 400 C), but all of them are very precise at 250, 300 and 350 points (I was measuring at them during manual calibration)? I am mostly interested in 300-350 C range precision.
-
I think you already answered yourself:
keeping tip on the sensor around 5-7 seconds and moving around to find hottest spot
-
(NTC low/high errors)..
The C210 handle does not have an NTC resistor like the T12.
Therefore, you need to either mount it, or disable NTC in the settings
Would you be willing to provide a wiring diagram? Thanks
-
Your question has been discussed many times in this thread. Read the last three pages. There are diagrams and answers to questions. If you don't understand something, then ask.
I did not install an NTC resistor on my soldering station v2.1S (C245), but simply turned off its polling in the setup menu. I did not notice any inconvenience in soldering.
Please note that you have a C210 cartridge. It has a supply voltage of 12 volts. Therefore, it is advisable to replace the power supply in your soldering station. For T12, the operating voltage is 24 volts.
In addition, the pinout of your cartridge can be viewed, for example here:
http://adgd.ru/2021/01/04/jbc-soldering-cartridges-pinouts/ (http://adgd.ru/2021/01/04/jbc-soldering-cartridges-pinouts/)
Or Google - "JBC C210 pinout"
-
Thanks, disabling NTC in the menu did the trick and the iron works now. Obviously needs proper calibration, but at least by setting the temperature to 180C , adjusting the calibration values until leaded solder just starts to melt got me in the right ballpark for now.
I guess the question now is - is there any advantage in using an NTC versus not using one?
-
Realistically speaking, it's a soldering iron not a thermometer. If you want to install a NTC go ahead, there's no drawback but it's not going to change anything if your station is 5°C more or less accurate.
As a matter of fact, genuine Hakko doesn't have a NTC in the handpiece, nor does JBC.
-
My aluminium handpiece heats up to 40 C at room temperature 25 C, so it will result in 15 C difference without NTC in it.
-
Do you know precisely what the optimal temperature is for every board and component you work on? Do you work on any component that's so sensitive you can only go 10°C above solder melting point otherwise you might damage it? Or maybe you work on an assembly line and must precisely repeat and validate the same solder joints at a specific t° for compliance?
If not, my point still stands but feel free to do it anyway for your peace of mind.
-
Why not just get the Hakko FX888D-23BY for $113.00 bucks on Amazon right now, or the 888 for $115?
-
I can think of several reasons:
- it doesn't cost 115$ outside of the US (~220euro here in the EU).
- it's an outdated heating technology that's worse than cartridges in every possible way.
- it looks like a toddler's toy.
- it takes more bench space.
- anyone with a budget in the range of 100~200$ is better off buying a C245 clone or a T12 clone under 100$.
All in all, I spent ~75€ on my T12 station and accessories. For that money I got the station, 2 handpieces (upgraded to an aluminium one), 11x T12 cartridges and an extra screen (replaced original 0.96" OLED with a 1.3"). Cherry on top, it runs David's firmware with UI and ergonomics that make sense because he put in most of the features we could think of collectively.
-
I can think of several reasons:
- it doesn't cost 115$ outside of the US (~220euro here in the EU).
- it's an outdated heating technology that's worse than cartridges in every possible way.
- it looks like a toddler's toy.
- it takes more bench space.
- anyone with a budget in the range of 100~200$ is better off buying a C245 clone or a T12 clone under 100$.
All in all, I spent ~75€ on my T12 station and accessories. For that money I got the station, 2 handpieces (upgraded to an aluminium one), 11x T12 cartridges and an extra screen (replaced original 0.96" OLED with a 1.3"). Cherry on top, it runs David's firmware with UI and ergonomics that make sense because he put in most of the features we could think of collectively.
You know, I completely missed that it wasn't T12! Good points. That, and the price in EU is crazy. Seems like the EU doesn't want Hakko selling in EU.
-
In the US, you have hakkoUSA as a branch office of the brand itself. They most likely set their own pricing for the US market. Hakko doesn't bother in the EU so it's down to random independent "partners" importing the goods and asking the price they want.
Anyway, the one you want is FX951 and its price stings even more.
-
Tell me who has a T245C handle from AIXUN, is this part made of aluminum or stainless steel?
-
hello i have this version of ksger https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/r2/back-low-res_mods_for_JBC-T245.jpg (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v2.1s-and-Ve2.1S/r2/back-low-res_mods_for_JBC-T245.jpg)
i have 3 wire from my handle how i can make working the jbc245 , i have this screen and i cut r11 make a bridge
when i try to turn it for geting heat it s reseting
i m making something wrong ?
-
Read page 134. C245 consumes a lot more power than T12.
-
it s getting so much hot , tc is not working , need to take off ntc sensor ? an pmw is ok to x1 ? i have 24 v psu !
-
Are you 100% sure the GX pin you isolated by cutting the pcb is really isolated?
If It goes out of control, check the MOSFET, it will get damaged easily and get shorted if you made any mistake in the wiring, thus powering the tip all the time.
Enable debug menu, enter it and set it to 0°C the tip shouldn't get warm at all.
Then you might try some low value, like 50°C.
It all might be caused by the calibration not done.
-
i make this on the picture
-
it seem to working now at 50 degre i can melt solder , tip at 0 its not working , 50 yes
what is the other step to make it working ?
at 55 i get 400 degre , something is not good but its not got more far stabilized to 400
if i try to get calibrated tip go red to much worm
-
Tell me who has a T245C handle from AIXUN, is this part made of aluminum or stainless steel?
It's stainless steel.
-
Something seems wrong with your wiring or innthe board modification, getting 400°C when setting 50°C is just too much.
-
i get it good now , i make a mistake from handle connection invert some wire
i get cal 250 to 2500 , cal 400 to 3880 , it is good ? i dont undestand how manage zero set , i put 45 W power , heater 3ohm , adc time 150 ms , pwm mult 10x , no ntc menu .
thank you to make a this firmware its realy good , i will buy another ksger solder
-
Consider contributing to this thread by nicely describing how you finally did it, so it helps other people with your same board :-+.
That's a much normal value, yes
C245s are rated for something between 80 and 130w, you can raise the power limit quite a bit, 45W is very low and won't get the full potential from these tips.
Zero cal is to remove the amplifier error.
I might rename it somewhere on the future, I chose a simple short name for it, ”Amplifier-induced offset calibration” doesn't fit ;).
As stated in the manual, enter calibration menu, insert a completely cold tip (At least 15 minutes OFF), click Adjust, click Zero cal, it will show ”Sampling”.
You will see some value there, if low (0-50) then can be omitted, but some stations (like mine) have it way higher (350), introducing a considerable error.
Click again and it will freeze the reading, now showing "Captured".
Click 'Save" to store the offset value.
Then it's better to run calibration process again for best accuracy.
-
Other things i have 2 wire to go inside the case for standing the handler , how i can to connect it ?
how i can select tip ? for exemple i have 3 tip i add the 3 with cal 250 and400 ? have a automatic selection ? https://www.youtube.com/watch?v=W-fDF4i718M (https://www.youtube.com/watch?v=W-fDF4i718M)
-
Have you read the manual at all?
-
yes i just find it for selection tips long push on the tip selection , by the way ,about the 2 wires from this stand , i think one is for standing sleep other i don t have idea .
-
Then you also read you must disconnect the shake wire, then route it to the stand, in a way the signal is pulled to ground when placing the handle.
A simple switch will do it. Search "stand" in this thread, it's been discussed infinite times.
-
Hello! I have a ksger v3.1s soldering iron, I changed the chip to 32stm and flashed a new firmware, connected the c245 handle, and burned the 4409 (BA2K05) chip the first time I turned it on. Tell me what is my reason? I probably mixed up the red and blue wire of the soldering iron?
-
Check the resistance:
5-4 must be ~3ohms.
2-4 should be ~0.5ohms.
Of course if you put them wrong, the transistor will overload and burn.
This was your modification, right?
-
David, thanks for the help, I mixed up the red and blue cable. Yes, I modified the board, cut the track in one place and put a jumper. I saw the version of this board discussed earlier.
-
I Have this board. KSGER. it had the MM chip on it, I have changed it out for a 128K STM32.
I have loaded the V3 KSGER binary, but all I get is a blank screen.
Does anybody have the correct binary for this board please.
Thanks.
-
V3 should be the correct version for it, make sure there're no shorts, solder can easily make hidden bridges under the chip.
Did you extract KSGER_v3_OLED.zip and then flashed the .bin, right?
Not the first time I get asked... For this very same mistake... :-DD
-
Thanks for your reply David, Yes, I flashed that bin file, and I can confirm there are no shorts between the pins.
If I power on the unit while keeping the encoder pressed, I get a full screen of snow. It goes off when I release the encoder.
Power draw is 34ma.
-
Snow/artifacting is usually a bad connection, make continuity tests between the oled and the stm32 pins.
That board uses the problematic linear regulator that tends to fail, check the voltage, If you have a scope it would be even better.
Try feeding it with the stink, connecting only 3.3v and gnd (Do not use the station psu).
Also try flashing the original firmware, available at Github.
-
Hello David.....
Thank you so much for your efforts on this awesome cfw.
-
My english is not so good sorry for that
I was trying differnet things on my board....just for curosity.
When i read the original firmware i saved it and uploaded yours firmware. It worked then i uploaded original that worked without any key.
Then i replaced the mcu (STM32F103CBT6) with another.. and uploaded your fw that worked ....after that original firmware also worked ...but when i removed the eeprom then original firmware asked for key....your worked without any problem...
How original fw works...i mean without eeprom what happens that it needed a key .....i have read the forum many posts of yours .. but one thing i want to ask is when i flashed the mcu so many times it did not asked for any key...
Can u please clear my mind....
Btw i am using your firmware ...i dont need original.....just learning
-
You don't need to remove the eeprom, the CFW won't modify it in any way!
The original firmare requests a key based on the stm32 unique ID and stores it in the eeprom.
Because you changed the stm32, the ID is different now, so will be the key, the existing one in the eeprom doesn't match anymore.
Use the keygen, it's available at Github (https://github.com/deividAlfa/stm32_soldering_iron_controller#backing-up-the-original-firmware).
-
Thank u so much...
Actually i dont need that what is saved in that chip...i am enjoying your fw.
Great work :-/O
I was learning and trying to draw schematic. Then just to see what will happen i done all this :-DD
-
Enjoy! :-+
-
Hi David ;D
FYI I Soldered the APM32F103CBT6 mcu And loaded with CFW and also Original FW. and that also worked. :-+
APM32 was pulled out from ST-Link v2 Clone.
-
Do the analog readings work correctly in the APM using the CFW?
Most clones seem to work just right, but the readings are garbage, values jumping everywhere, causing error messages.
-
I will check tomorrow and post the results
-
Hi all! I ask for help ... I'm not strong in programming ... Can anyone post the KSGER2.0 V2 Oled firmware with the Switch off reminder addon enabled.
Sincerely!
-
Sure!
https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.09.2
-
Thank you very much! Thanks to your firmware, I learned what JBC soldering is!
-
Hello David , greetings from Bulgaria. I would like to suggest, in future versions it should be possible to manually select the type of soldering tip from the list after removing from the handle and inserting the soldering tip.
-
Looks like a good idea at first glance. Tip list could come up just before a "no tip" error longer than 3sec (small delay to prevent annoyance in case of loose contact) is cleared. Let's see what the boss thinks ;)
-
Seems a reasonable idea!
Definitely, it should come out only after 3-5 seconds without tip to avoid false triggering, otherwise it would end annoying me and creating a new window, action which I doubt the station could survive.
Perhabs extending the tip selection time? (Only when triggered by tip removal).
-
Here's how I see it:
Let's say you remove a hot tip to change it. You would first put the hot tip away before you grab the new one and insert it. It's only at that point the tip selection menu would open while the "no tip" error would still disable the heating element until the menu closed. Worst case scenario, you have the cold handpiece in one hand while the other hand's free to interact with the station.
10sec should be plenty to either select the new tip or do nothing and safely put the cold handpiece back in the holder. In case no encoder input is detected during those 10sec, the station should exit tip menu and resume operation with previously configured tip.
-
I know I'm getting annoying with my wishes…
Is it possible for the soldering tip names to be 4 characters long but show with a station profile prefix eg. T12-1402 or C245-I, C245-939, C245-029.
The reason is that I bought a handle for T12 (the new version) from AIFEN (SUGON), which is similar to the shape and size of the handle for c245, and I work with two stations, one with T12, the other with C245.
Аnd the stations are the same.
-
So much for no new features :D
-
I know I'm getting annoying with my wishes…
Is it possible for the soldering tip names to be 4 characters long but show with a station profile prefix eg. T12-1402 or C245-I, C245-939, C245-029.
The reason is that I bought a handle for T12 (the new version) from AIFEN (SUGON), which is similar to the shape and size of the handle for c245, and I work with two stations, one with T12, the other with C245.
Аnd the stations are the same.
You already have 4 characters for tip names.
There's limited amount of screen space (resolution is only 128x64) and 10K of RAM on low end chips. You can't exactly go ham with fancy UI design and extra info when resources are scarce.
For example "T12-1402" is 8 characters => smaller font required => adding a new font => extra RAM and flash space needed and worse readability for 0.96" screens. Not great tradeoff for a feature that's not really helpful.
-
It is not necessary to reduce the font and use a new font, the power bar can be displayed in percentages or the bar can be reduced in length. The tip name can be stored as 4 characters but displayed as (station profile - tip name ) on the main screen and on the tip list. But if there really is no resource, it's not a problem.
-
I got no time for this, but you can try by modifying TIP_LEN (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Inc/settings.h#L20) and _BLANK_TIP.
_BLANK_TIP is made by TIP_LEN spaces.i don't think there'll be any issues else than GUI glitches (The shake icono will probably overlap).
Compiling is pretty straighforward following the guide and using the automated script.
Everything can be done, but don't expect me doing work for your personal liking!
-
I got no time for this, but you can try by modifying TipCharSize (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Inc/settings.h#L20) and _BLANK_TIP.
TipCharSize is always 1 more than real (For string termination), while _BLANK_TIP is made by (TipCharSize - 1) spaces.i don't think there'll be any issues else than GUI glitches (The shake icono will probably overlap).
If the compilation fails due not enough memory, reduce NUM_TIPS, 40 is already a lot.
Compiling is pretty straighforward following the guide and using the automated script.
Everything can be done, but don't expect me doing work for your personal liking!
Thanks for the guide, I'll try.
Is there a global variable for the station profile name?
It's just my wish that the firmware becomes even better and more functional.
I didn't want to impose myself on anyone and tell who should do what.
I'm sorry.
-
You don't have to be sorry! I completely understand that people wants changes!
From experience, small, apparently simple things tend to be not so simple, introducing new bugs or issues that will need more time, so I'm a bit reluctant on making changes once everything works as it should ;)
I have little free time, so I don't really want to use it in a cheap station firmware !
-
Damn! Completely skipped doing home stuff today, instead... ::)
-
Welp, so much for being too busy ^-^
-
v1.10 release removed!
For some reason, it caused Hardfault when saving tips, don't know why, this is the real life programming where sometimes simple changes aren't so straighforward!
New release: v.1.10.1 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.1)
Last commit changes (https://github.com/deividAlfa/stm32_soldering_iron_controller/commits/master).
Limiting the tip length to 9 chars seems to fix it, so that will be it for now!
Added small tweaks to the selection timeout.
-
@DavidAlfa i just flashed 1.10.1 and now i see: (same result on three v3 keger oled models now all are original stm chips none are knockoffs all worked with 1.09 versions prior)
line 374
settings.c
any ideas i triple checked i downloaded the newest one v3 ksger oled model has worked perfect till now with the 1.09.1 im glad i tested on mine first a client sent me his unit with a blown cap i swapped them out and installed 1.09.1 was fine (he saw this thread and asked me if i could do it and im NOT charging him for it just so you know. he is learning still and didnt want to ruin it. but yeah it was working GREAT but then he messaged me and said there is a new update can you do that before sending it out lol i told him you will have to learn to flash it yourself i soldered in the header for him so it cant be much easier lol.
-
No idea, perhabs 10KB devices don't have enough ram, will check later.
Edit: Crashing here (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Src/settings.c#L374), definitely running out of memory.
-
i have i think 7 3.0 boards and they all have different stm chips id have to check them all again.
anyway to fix it or will the previous build be the final one for 3.0?
-
Nothing is final, but I have to work 8h a day and a life, for now revert to previous release, will be fixed when possible.
-
I can confirm it works on V1.5 with the higher end chip.
Can't say I'm thrilled by the extra clicks and scrolling required to save all my tips or the now wasted/empty screen space because of the extended name field, though. I'm curious what you and others think about it.
-
You don't need to click 10 times, remember you can move from side to side using the "drag-clicking" method, much faster.
-
is there an easy way to say remove some of the extra languages to make some extra room or anything simple i can remove (i have not done code in a LONG time so it def will take me some time to figure it out again) honestly i only personally need english but not sure how much space that would free up
-
is there an easy way to say remove some of the extra languages to make some extra room or anything simple i can remove (i have not done code in a LONG time so it def will take me some time to figure it out again) honestly i only personally need english but not sure how much space that would free up
English only preferred. Who wants another language when compiling to specify it. However, many of the translations have incomprehensible abbreviations or anglicisms.
The tip name can be stored as 4 or 3 characters but displayed as (station profile - tip name) on the main screen and in the tip list and only the last 4 or 3 characters edited. But if there really is no resource, this is not a problem.
-
You don't need to click 10 times, remember you can move from side to side using the "drag-clicking" method, much faster.
I forgot about that, thanks. Still, I'm well aware you can't please everyone when it comes to UI design so I'll revert the change for my own build.
is there an easy way to say remove some of the extra languages to make some extra room or anything simple i can remove (i have not done code in a LONG time so it def will take me some time to figure it out again) honestly i only personally need english but not sure how much space that would free up
Languages enumeration is in Core/Inc/settings.h . You need to set LANGUANGE_COUNT to 1, and then look for lang_english and remove the extra languages lines.
And the translated strings are in Drivers/graphics/gui/screens/gui_strings.c . There you can go ham and delete the blocs you don't need.
That's pretty easy if you have the environment all set to compile your own binaries. If not, tell me what build(s) you need.
-
Reducing tip count to 35 (Who has 35+ tips anyways?) and shortening the tip name to 8 chars seems to make just enough room for 10KB devices.
Release v1.10.2 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.2).
The languages use only flash, there's still plenty of it, removing them will make zero difference to this problem, which is the RAM.
The issue comes when saving data into the flash (Profiles, settings...), everything must be stored into ram prior writing, as the entire flash sector needs to be erased first.
That means storing ALL the profiles (T12, C210, C245), not just the one being modified, so it temporally uses a lot of RAM.
A possible solution would be to store each profile on a different sector, using additional 8KB of flash, which is not really a lot, reducing the backup buffer by 2KB, saving only one profile at any given time.
But this again, needs time, testing.... no ETA!
-
8 symbols are enough, t12 soldering tips no more than 4 symbols, c245 and c210 no more than 3 symbols.
Let's not be maximalists, David is right, no one works with 35 soldering tips.
-
Yeah, more than enough, still allowing the full name, "T12-JL02", "C245-963", etc.
-
I never got a chance to "impose" upon my OLED version with better firmware but I'm interested.
One of the problems with the factory FW is that it does not see the shaker switch to wake up.
I've even done a bridge short between the input and black minus and still no deal, so I will try some new FW.
So the 2 questions are, the color codes and PCB markings for the newer white handles which are a vast improvement over the black/blue crappy socket types.
https://www.amazon.com/dp/B07HQ69VND (https://www.amazon.com/dp/B07HQ69VND)
I can't seem to find anything that agrees between any of these white handles as to what goes where.
I have it as Red +, BLK -, GRN as GND, WHT as Thermocouple, BLU as Shaker SW.
Pictorially it's all over the map.
Look at this nonsense:
https://www.aliexpress.us/item/2251832554212325.html (https://www.aliexpress.us/item/2251832554212325.html)
Scroll down to English Manual
I also bought a simple LED version for a friend of mine who does simple.
https://www.amazon.com/dp/B07KNT9DXL
Of course there are no instructions...
The 3 pin power plug is red, yellow and black. Just apply 12v-24v? so what is yellow for?
I have posted here because Google and the supplier are useless.
Sorry it this is in the wrong place, if not here can someone point me to the right place?
-
So the 2 questions are, the color codes and PCB markings for the newer white handles which are a vast improvement over the black/blue crappy socket types.
https://www.amazon.com/dp/B07HQ69VND (https://www.amazon.com/dp/B07HQ69VND)
I can't seem to find anything that agrees between any of these white handles as to what goes where.
I have it as Red +, BLK -, GRN as GND, WHT as Thermocouple, BLU as Shaker SW.
I've seen many handles where the blue and white wires are swapped. The important thing is of course that the pinout is right.
On most KSGER boards the pinout is: 1-Switch, 2-NTC, 3-GND, 4-(-), 5-(+)
Post a photo of your board and handle, maybe we'll be able to help.
I also bought a simple LED version for a friend of mine who does simple.[/size]
https://www.amazon.com/dp/B07KNT9DXL
Of course there are no instructions...
The 3 pin power plug is red, yellow and black. Just apply 12v-24v? so what is yellow for?
I have posted here because Google and the supplier are useless.
Sorry it this is in the wrong place, if not here can someone point me to the right place?
On the ones I've seen, the yellow seemed to be GND.
-
As far as the white and blue, it can be what ever way they want it to be.
The Chinglish manual found in various Aliexpress pages is useless. They should stop trying to speak English and just draw pictures. It really is better.
I've learned much more from the photos, but never from the text within them.
On this one the Yellow is 12V+-24V+
Before taking the 5 pound sledge hammer to it, I will explain why I would want to do such a thing.
Many photos all of which do not agree with each other, forced me to take a DMM to do some ohming \$\Omega\$ out of the traces.
I did find between my unbiased results and the photos, where I needed to hook the 3 power wires to. +12V. Red and Yellow to +12V. Black to -. I used 12V on both to play it safe.
The display lit up and showed 500 as seen in all the photos.
I know the new handpiece-wand works from my testing it in my OLED station.
None of the menu settings work or change the LED with the handpiece.
An Amazon call resulted in a refund + the original amount and pity money all in excess of the purchase.
I can keep the original (free handpiece)! kit and the bad board. No torturous replacement board to deal with.
Free money, free iron, let the hammering begin! ;D (no tension headaches that way)
Buy the STM-OLED one (KSGER, Quicko (Quecco)) for just a bit more in price.
Plenty of support here and elsewhere.
The original OLED one was very easy to build into an old flat faced, old Weller station with the original built in 18V torroidal transformer.
A new face made out of Formica, Dremeled and drilled, did the job.
Adding a 5A bridge and a 1000µF cap was easy, it came from the junk box.
That's what I made for my friends LED board version. FAIL.
Thanks anyway for trying. NEVER buy the LED version, it's just a dumb display.
Quote from: AndyC on 2023-04-29, 03:55:44 (https://www.eevblog.com/forum/index.php?topic=105869.msg4838225#msg4838225)>
-
Hello guys,
since a few months I own a HANDSKIT T12 soldering station.
With the help of @yelkvi I already prepared it a bit to use it with C245 cartiges. I (re-)wired the T12 handle and C245 handle and do have some nice (genuine) C245 cartiges on my desk.
The only thing missing is David's awesome CFW. But I'm struggeling to identify my board type and which firmware version to use for it.
Attached (sorry, I was to stupid to include them into the text) are pictures of the station, it's board, it's STM32 and another STM32 of an Arduino that I could use, if that would be beneficial (I have a hot air gun and could swap the STM32s).
Thanks for your advice which firmware to use!
-
Here's what David's instructions say:
"4 pin (I2C) = Generic v2 (KSGER/Quecoo/Handskit/etc.)"
So your firmware: KSGER_v2_OLED.zip
-
Don't put the stm32 from that Blue Pill, it looks fake from miles away!
You have the original firmware to restore, so no problem.
-
Thank you both for your quick replies!
This morning I flashed the KSGER_v2_OLED.bin. As the ST-Link Utility was missing the mfc140.dll (according to google this requires the installation of Visual Studio 2015 , which I wanted to avoid) I used the STM32CubeProgrammer. I'm not very familiar with this and not set/changed any settings, but I think the flashing was successfull. At least at next startup the CFW showed up :D
One question regarding this: Should I have full-erased the chip before flashing the CFW? So far I did _not_ because I wasn't sure if it might "break" something (erase the boot loader etc. etc. -- again: I'm not very familiar with this...).
The station boots with the CFW and seams to work as desired using the T12 handle (tested it just for a few moments).
However, re-starting the station, switching the profile to C245 and connecting a C245 handle incl. genuine cartige leads to this sequence (see pictures attached):
1: 24°C
2: -99°C [showing only for a fraction of a second]
3: Cartige Error
...and the cartige is not heating up at all.
Any suggestions what might cause this error?
-
Show us the handle wiring and the board modification.
-
davidalfa beat me to it lol i was just about to post you have to do the mod to the board for 245. a couple pages back there is some more info where someone else posted pics.
-
On the board I opened a bridge that was existing between PINs 1 and 2 (marked as H and T+) of the connector (Attachment 1).
For the T12 handle I added the bridge (PINs 1 to 2) inside the handle's 5-Pin GX12 Connector.
On the PSU I added a 1 Ohm resistor (Attachment 2).
C245 handle wiring/connector:
I just realized I can't take a picture of the wiring of the 5-Pin Connector (GX12) because I made a nice isolation (red shrink tube) as it has a metal housing (Attachment 3).
I can't open my handle anyways, so I figured out the handle wiring by measuring it. My handle came with a 3-wire cable so PINs 4 and 5 of the connector are not used. Here is what I re-measured on the connector with an inserted (used) C245 cartige a moment ago:
Pin 1 to 2: 2.9 Ohm
Pin 2 to 3: 1.0 Ohm
Pin 1 to 3: 2.9 Ohm
With no cartige inserted I have no connection/resistance between any connector pins.
-
Ensure the handle wiring is correct:
Read page 134. C245 consumes a lot more power than T12.
-
I did already read through many pages of this thread before and did again yesterday night (including page 134). It looks like I have a lack of understanding to find the problem with my wiring (or whatever might be wrong). What makes me curious is that I don't measure the resistance values you mentioned:
You should measure something like this:
- Heater-GND : ~2.6 Ohms
- TC-GND: ~0.7 Ohms
- Heater-TC: Sum of both (~3.2Ohms)
BTW: I noticed a typo in my last post (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4851914/#msg4851914): I actually measured 2.9Ohms for 1to2 and 1to3 (not 3.9Ohms which I wrote earlier and now corrected it to 2.9):
Here is what I re-measured on the connector with an inserted (used) C245 cartige a moment ago:
Pin 1 to 2: 2.9 Ohm
Pin 2 to 3: 1.0 Ohm
Pin 1 to 3: 2.9 Ohm
With no cartige inserted I have no connection/resistance between any connector pins.
I would like to check the wiring and contacts of my C245 handle, but can't open it. Is there a trick or best practice to open the handles? I have this one (https://s.click.aliexpress.com/e/_DCQJvu5) (which BTW has a good quality feeling), and already tried to open it by twisting it between the green grip and the black back-side, but it seams to be glued together strongly and I'm affraid of breaking it.
I also want to understand and double-check the pin-out of my board. @celica uses PINs 3+4+5 (photo in this post (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4794548/#msg4794548)), but for my understanding with my board (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/3425/) PINs 1+2+3 need to be used (Which I already do for the T12 plus 4+5 for the shake sensor and it works). Can anyone check/confirm the PINs?
-
Pins 1-2 put the Heater and the thermocouple in series, you should measure the sum of 1-3 and 2-3.
Green (H), red(T+) and Black (G):
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1730297)
-
Тhis is my connector arrangement and my modification of the Handskit to work with the C245 handle and stand. and like you, I have moved the bridge for T12 handle in the connector.I'm using CSK32 with clonefix off from this dealer Wan Xing Da Chip franchise Store and no problems.
-
Pins 1-2 put the Heater and the thermocouple in series, you should measure the sum of 1-3 and 2-3.
Green (H), red(T+) and Black (G):
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1730297)
David, the HANDSKIT uses a different arrangement of the GX15-5 connector. See my last picture.
H is the thermocouple, T+ is Plus on the soldering tip, SW is the vibration sensor, GND is the signal ground, PE is the protective ground. With the Handskit, the NTC is soldered to the board.
And about the HANDSKIT, changing the soldering tip after insert tip with version 1.10.2 does not work, while it works on the KSGER. For information, the HANDSKIT soldering tweezers work on the KSGER after replacing the cable with a five-core one and placing the NTC in their handle and wiring the rod according to their scheme.
Settings for HANDSKIT soldering tweezers:
Power:150W
Heater:4 Om
PWM:10X
Heaters and Thermocouples on HANDSKIT soldering tweezers is connected in paralel.
The HANDSKIT uses a 150 Watt power supply and is the same as AIXUN uses in the T3A.
G12-5 pinout for HANDSKIT whith JBC C245 Handle:
This colors is standart for JBC Handles.
1=RED=Theromocouple
2=BLUE=Heater +
3 bridge 4 = GREEN = Signal Ground + Protective Ground
-
First of all, many thanks to the author for the excellent work.
Please comment on my idea (maybe it's stupid, maybe it has already been implemented)
We have a "heating element with a sensor", after "thermal resistance" to "end of the soldering iron head".(regulator try keep temperature of the sensor an not "end of the soldering iron head")
The "heat flow" creates a proportional "thermal gradient" and temperature of the "end of the soldering iron head" is less than the temperature of the measuring point.
But "thermal gradient" is proportional to the "Heat Flow" and proportional to the current through the "Heater" .
We can add an additional "DeltaTemperatura" request to PID-regulator (proportional to Current/heat_flow/cooling_to_PCB )
It will partially compensate for the cooling of the soldering iron head (because the regulator tries to keep the temperature of the sensor and not "end of the soldering iron head").
-
Looks like you're using the wrong tip for the job?
Good tips like JBC have the sensors properly placed, so the performance is great, you can't expect the same from a cheap T12.
Also the thinner ones won't solder anything larger than a 0805 pad even at 400°C.
Trying to compensate for this will likely kill the tips, heavily overloading the heater.
Every tip, seller, fabrication date, aging process, everything will affect the tip performance, this sounds like an absolute nightmare to implement.
Ideas are easy to say, but nowhere close when taking them to practice ;)
If you know how to do it, welcome! :D
-
@DavidAlfa and @ststefanov13 Thanks for your replies regarding the pinout/wiring! I really appreciate it!
I will be out of home for the next days so unfortunately I will not be able to review my wiring accordingly. I will definitely post here once I make any progress!
Cheers
Rixi
-
Touch the tip body with the multimeter, find the wire measuring 0 ohms (Complete short), that one will be the gnd (G), then measure the other ones against that wire.
The one measuring ~3ohms is T+, the other (0.5-1 Ohm) is the sensor (H).
There's nothing else about it!
-
That's how I did it. My GND is PIN 3.
My measurements 1to3 and 2to3 seam to be okay. The only strange thing is that I measure about 2.9Ohms from 1 to 2. That should be around 2.9 + 1.0 = 3.9 Ohms if I'm not wrong?
Here is what I re-measured on the connector with an inserted (used) C245 cartige a moment ago:
Pin 1 to 2: 2.9 Ohm
Pin 2 to 3: 1.0 Ohm
Pin 1 to 3: 2.9 Ohm
With no cartige inserted I have no connection/resistance between any connector pins.
I measured it multiple times, but will re-measure once I'm back home.
EDIT: I just realized that I probably wired the thermocouple and heater the wrong way around. According to this...
David, the HANDSKIT uses a different arrangement of the GX15-5 connector. See my last picture.
H is the thermocouple, T+ is Plus on the soldering tip, SW is the vibration sensor, GND is the signal ground, PE is the protective ground. With the Handskit, the NTC is soldered to the board.
...I should measure the 1Ohm from PIN 1 (marked H on the board) to 3 (marked with ground symbol on the board).
And 3 Ohm from PIN 2 (marked T+ on the board) to 3.
Another question: Do I need to add a diode here? (Attachment 1)
-
The max. expected voltage coming from the sensor is under 50mv, but 24V will get there when powering the heater.
Not absolutely required, the amplifier esd diode will clamp the voltage, but this could cause weird behaviour, better to solder a led or a 1n4148 there to clamp the voltage at lower level than VCC.
-
That's how I did it. My GND is PIN 3.
My measurements 1to3 and 2to3 seam to be okay. The only strange thing is that I measure about 2.9Ohms from 1 to 2. That should be around 2.9 + 1.0 = 3.9 Ohms if I'm not wrong?
Here is what I re-measured on the connector with an inserted (used) C245 cartige a moment ago:
Pin 1 to 2: 2.9 Ohm
Pin 2 to 3: 1.0 Ohm
Pin 1 to 3: 2.9 Ohm
With no cartige inserted I have no connection/resistance between any connector pins.
I measured it multiple times, but will re-measure once I'm back home.
EDIT: I just realized that I probably wired the thermocouple and heater the wrong way around. According to this...
David, the HANDSKIT uses a different arrangement of the GX15-5 connector. See my last picture.
H is the thermocouple, T+ is Plus on the soldering tip, SW is the vibration sensor, GND is the signal ground, PE is the protective ground. With the Handskit, the NTC is soldered to the board.
...I should measure the 1Ohm from PIN 1 (marked H on the board) to 3 (marked with ground symbol on the board).
And 3 Ohm from PIN 2 (marked T+ on the board) to 3.
Another question: Do I need to add a diode here? (Attachment 1)
These measurements are taken at the handle connector disconnected from the post tip station.
pin 1 to 4 (Signal Ground) ???? Ohm
pin 2 to 4 ( Signal Ground ) ???? Ohm
Signal Ground (pin 4 ) is not connected with Protective Ground (pin 3) on the board.
1=RED=Theromocouple
2=BLUE=Heater +
3 bridge 4 = GREEN = Protective Ground
4 bridge 3 = GREEN = Signal Ground
!!!! Signal Ground is not connected with Protective Ground on the board. !!!!
5 =Vibration Switch to back panel for stand
The diode is not necessary for C245 in this place, but it does not prevent having it.
-
To David
on HANDSKIT station, soldering tip change in version 1.10.2 doesn't work while working on KSGER ?
I have three HANDSKIT stations, the first with T12, the second with HANDSKIT soldering tweezers and the third with C245.
on those with T12 and C245, changing the soldering tip does not work.
I also have two KSGER v3 stations, the first one with T12 (there, changing the soldering tip works). This makes me think that I should do a test with c245 at KSGER station. :)
Second is with HANDSKIT soldering tweezers.
What could be the problem with changing the soldering tip on the HANDSKIT stations.
-
That's how I did it. My GND is PIN 3.
My measurements 1to3 and 2to3 seam to be okay. The only strange thing is that I measure about 2.9Ohms from 1 to 2. That should be around 2.9 + 1.0 = 3.9 Ohms if I'm not wrong?
Here is what I re-measured on the connector with an inserted (used) C245 cartige a moment ago:
Pin 1 to 2: 2.9 Ohm
Pin 2 to 3: 1.0 Ohm
Pin 1 to 3: 2.9 Ohm
With no cartige inserted I have no connection/resistance between any connector pins.
I measured it multiple times, but will re-measure once I'm back home.
EDIT: I just realized that I probably wired the thermocouple and heater the wrong way around. According to this...
David, the HANDSKIT uses a different arrangement of the GX15-5 connector. See my last picture.
H is the thermocouple, T+ is Plus on the soldering tip, SW is the vibration sensor, GND is the signal ground, PE is the protective ground. With the Handskit, the NTC is soldered to the board.
...I should measure the 1Ohm from PIN 1 (marked H on the board) to 3 (marked with ground symbol on the board).
And 3 Ohm from PIN 2 (marked T+ on the board) to 3.
Another question: Do I need to add a diode here? (Attachment 1)
What is the function of the 10 ohm resistor in the picture on power supply ?
Isn't that 10 ohms you're measuring?
!!!! Signal Ground is not connected with Protective Ground on the board. !!!!
pin 1=RED=Theromocouple
pin 2=BLUE=Heater +
pin 3 bridge 4 = GREEN = Protective Ground
pin 4 bridge 3 = GREEN = Signal Ground
These measurements are taken at the handle connector with a post tip without the handle plugged into the station.
pin 1 to 4 ( Signal Ground ) ???? Ohm
pin 2 to 4 ( Signal Ground ) ???? Ohm
The field effect transistor that controls the heater is connected to + 24 volts and signal ground and not to the protective ground and its control from stm32 is relative to signal ground. !!!!!!
-
What is the function of the 10 ohm resistor in the picture on power supply ?
This is a revision of my power supply. When using 245 (when the soldering iron tip is cold), the power supply went into protection cyclically.
If you use T12, then this is not observed.
Changed the parameters of the current sensor. On the factory circuit, two 0.43 Ohm resistors are in parallel.
I added another 1.0 ohm resistor. And the power supply stopped going into protection.
Perhaps other instances of Handskit power supplies will not have such a feature.
-
That's a hack to let the PSU output more power, but it will instantly blow up if the transformer core reaches saturation.
All PSUs can handle more than their nominal power but they must leave some room for safety margin.
If It works, great, but if it goes boom you know why :D
-
This is not necessary, the HANDSKIT power supply unit is 150 watts, the same AIXUN is used in T3A. just in David's firmware menu for the C245 profile :
1. power 150
2. pwm 10x
3. ADC time 50 or 100ms
-
What is the function of the 10 ohm resistor in the picture on power supply ?
This is a revision of my power supply. When using 245 (when the soldering iron tip is cold), the power supply went into protection cyclically.
If you use T12, then this is not observed.
Changed the parameters of the current sensor. On the factory circuit, two 0.43 Ohm resistors are in parallel.
I added another 1.0 ohm resistor. And the power supply stopped going into protection.
Perhaps other instances of Handskit power supplies will not have such a feature.
Am I to understand that you have a HANDSKIT station at your place? Does the tip change feature work in version 1.10.2?
-
I have an old version of the firmware. I haven't programmed a new one. No free time. And there is no need for new firmware.
-
Does the tip change feature work in version 1.10.2?
What is the “tip change feature” exactly?
-
For convenience, it enables the tip selection for 5 seconds after changing a tip, so you can chose the new one by rotating the knob, or simply wait the timeout for it to go away.
Don't go Superman, it will ignore it if the tip is inserted again in less than 3 seconds, assuming it was a a connection failure instead.
Yeah, I have to update the Operation manual, too busy...
-
I'm back home and making progress with the C245:
EDIT: I just realized that I probably wired the thermocouple and heater the wrong way around. According to this...
David, the HANDSKIT uses a different arrangement of the GX15-5 connector. See my last picture.
H is the thermocouple, T+ is Plus on the soldering tip, SW is the vibration sensor, GND is the signal ground, PE is the protective ground. With the Handskit, the NTC is soldered to the board.
...I should measure the 1Ohm from PIN 1 (marked H on the board) to 3 (marked with ground symbol on the board).
And 3 Ohm from PIN 2 (marked T+ on the board) to 3.
I re-measured (with a better, more precise multimeter) and confirmed I had the thermocouple and heater the wrong way around. So I swapped them. Attachments 1+2 show how is how it's now wired up.
!!!! Signal Ground is not connected with Protective Ground on the board. !!!!
pin 1=RED=Theromocouple
pin 2=BLUE=Heater +
pin 3 bridge 4 = GREEN = Protective Ground
pin 4 bridge 3 = GREEN = Signal Ground
I bridged PINs 3 and 4 inside the connector (Attachment 3)
Another question: Do I need to add a diode here? (Attachment 1)
[...] better to solder a led or a 1n4148 there to clamp the voltage at lower level than VCC.
Added a diode (Attachment 4)
The good news: The station is now now showing the tip/cartige error any more :) And it's heating the tip :)
...but the temperature reading (or somethig else) is still not sufficient:
When switching on the station or putting in a new tip it's heating up strongly for 1-2sec and then reads temperatures up to 800-900 °C. The tip is then hot and you don't want to touch it, but not hot enough to melt solder. After reading the 900°C it stops heating and the temperature slowly drops to the set temperature which it then tries to hold. Still hot, but not melding solder. Various new and used tips all show a similar behaviour.
I do have a (fake) Hakko 191 Tip Thermometer, but can't read the temperatures acurately, because the tip is not melting solder.
However, I tried to run a calibration. It did not worked instantly for the 400°C calibration step: It showed "Wait..." forever and did seam to stabilize the read temperature enough. At some point the calibration seamed to work and showed "Successfull" (or something similar). But the behaviour did not really change (still heating up to ~900°C, tip get's hot but not melding solder).
The T12 handle and profile still work.
Any ideas why the C245 temperature reading/heating is so much off? Or what heating settings are not set the right way?
-
Genuine C245 have higher probe output than T12, almost double, so it might be saturating the amplifier output.
Enter calibration settings, click cal250 and keep increasing until it melts solder.
If the limit is reached ( cal400 value) and still not melting, increase cal400 by 500 and try again.
If you get to ~4000 value and still not heating enough, then it's the amplifier saturating.
There's a 249K resistor in the amplifier circuit, solder another one in parallel of 220K-150K to reduce gain and try again.
Be careful, now the output will double, set cal250/cal400 to original values before modifying.
-
Perfect! Will try it tonight.
-
I finally calibrated one C245-906 tip:
Cal 250°C: 2065
Cal 400°C: 3339
Thank you so much, David!
Is there a process to calibrate/optimize the PID values?
-
Was it the gain resistor?
Please document a bit the steps you took to make it work, so everyone with the same board can have a look at it.
The default values are pretty conservative, trying to avoid issues with the 4 million controllers out there.
You can try:
- Increase Pid Ki until having too much overshooting/oscillations.
- Reduce tip filtering to 30-50%.
- C245 sensor output is much cleaner than T12, try lowering ADC delay to 1ms and ADC time to 50ms, it might work nicely.
Do only one step at a time, it's easy to mess things up!
-
Please document a bit the steps you took to make it work, so everyone with the same board can have a look at it.
Sure! The correct wiring and connector PIN-out is described in Post #3466 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4860803/#msg4860803).
Was it the gain resistor?
No, I didn't have to put a new resistor.
Beside the correct wiring, the main part was temperature calibration. I first read your manual about this ;) and like you explained here (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4860842/#msg4860842) I needed to go into the Calibration-Settings and increasy the values for Cal 250°C and Cal 400°C manually. I did this step by step and ended up with Cal 250°C = 1950 and Cal 400°C = 2950. With these values (already with some lower values) my iron melted solder, so I was able to use my fake Hakko 191 Thermometer to measure the actual tip temperature.
I then started the automated/guided Calibration and finally was able to calibrate the tip precisely (Result: Cal 250°C: 2065 + Cal 400°C: 3339 ).
- Increase Pid Ki until having too much overshooting/oscillations.
- Reduce tip filtering to 30-50%.
- C245 sensor output is much cleaner than T12, try lowering ADC delay to 1ms and ADC time to 50ms, it might work nicely.
Finally, I did not change the PID Ki setting yet, but I did change the tip filtering to 40%, ADC delay to 1ms and ADC times to 50ms.
This made the temperature curve much smoother! :-+
I still need to learn and understand what all these seetings do and maybe play around with them a bit.
-
I apologize for my English, I have to write through a translator.
There was one idea that could compensate for the poor quality of T12 (clones), and unleash the full potential of C245 / C210.
Auto-boost, what I mean is -
1.The power (% of load) threshold is set (for example, 15% for C245, 50% for C210)
2. When this threshold is reached, the temperature rises by 10 degrees immediately.
3.If the load is not reduced, +10 degrees are added every 1 seconds
4. With adjustable upper limit, such as +30 degrees.
5. As soon as the load disappears, the temperature setpoint returns to normal.
-
For convenience, it enables the tip selection for 5 seconds after changing a tip, so you can chose the new one by rotating the knob, or simply wait the timeout for it to go away.
Don't go Superman, it will ignore it if the tip is inserted again in less than 3 seconds, assuming it was a a connection failure instead.
Yeah, I have to update the Operation manual, too busy...
Really nice function, but any chance to add that 5 seconds delay as a setting in future updates to make it longer? Sometimes I find it too short, when I start selecting changed tip it already timed out and changes temperature instead...
-
Easy, change checkScreenTimer(5000) in this line to the time you want, it's in milliseconds:
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/main_screen.c#L558
Compile following the instructions (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Build.md) from github, basically it's this: Install CubeIDE, Download the project in .zip, modify that line, run the build script, done!
Shouldn't take more than 10 minutes.
-
Thanks, gonna make it this way.
-
Hello. board KSGER v2.Firmware penultimate. Tell me why the current temperature is not saved? Saving a profile in the menu is enabled. There is a battery. The battery voltage is 3 volts. The tip type is saved but the temperature is not...
-
Not enabled by default, but there's flag to enable that.
Follow the firmware building instructions (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Build.md), uncomment this line (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/v2/STM32F101/Core/Inc/board.h/#L115) (Remove the "//") before running the building script, after compiling the new firmware will be available in BOARDS/KSGER(...) folder.
-
My question is, David, is it possible to disabled temprorary standard function of the tilt switch input and make an addon (for example, through an addon more similar to fume_extractor ) and repurpose it for a desoldering module to control a valve or pump as it is in the original Chinese firmware (eg when N tips are used) ?
Look at the picture....
-
Everything is possible, but not me doing it, I'm just too busy!
-
Good day to all. Got the station. The screen used 2.42 inches. April firmware .... I hear a small squeak from the display. Probably the throttle on the display board beeps. You can somehow remove the squeak. My screen settings. Thanks to all!
-
Hard to tell. Try adjusting the advanced display settings!
-
Is it possible to damage the display by changing the settings?
-
No, you could get a corrupted image, but the controller will still work, so just keep rotating until it looks nice/better or rotate backwards.
Nothing is saved unless you manually click on SAVE, in the worst case just turn the station off / on and keep trying different settings.
-
I expressed myself incorrectly. Can I reduce the life of the display with my settings? Are your default settings the optimal settings for the SD1309?
-
The only thing that can reduce display life is high brightness for long time, these displays will usually die after 2 years if working 24/7.
Nothing to worry about, just use it normally :-+
Optimal settings are relative, there are many displays!
I used something that seem to work with everything.
But you might find it looks brighter changing them.
-
I have the latest version of the source code on my end
Based on MM32SPIN27PF microcontroller
If the moderator is interested, I can provide it to you
-
What source code? From the original firmware?
-
Yes, that's the tip detection routine, before reading the TC it outputs a very short pulse.
Normally it's barely noticeable, but reducing ADC time will make it noisier.
If you added a 1M resistor between Heater and 3.3V (Or 10M across the MOSFET drain and source) then you can disable the "Active detection", noise will go away.
I only use C245. What is the principle of the active detection function if you solder a 10MΩ resistor between the drain and source of the transistor? In 245, there is a separate wire from the thermocouple..... Or does it only work for T12 tips, where the thermocouple is in series with the heater?
Sometimes a fictitious temperature jumps on the display when the sting is pulled out - I want to get rid of this defect .... Do I need to pull up the input of the operational amplifier by 3 volts through a 1MΩ resistor? ..
-
It prevents the amplifier input from floating and jumping around showing random temperatures when the tip is removed.
-
The new version of 3.1S is based on the original firmware of MM32SPIN27PF
I am a manufacturer of KSGER in China
We are currently designing a new version of the T12 handle
-
Interesting, could you upload it?
-
Give me your email and I will send it to you separately. Uploading here is not very convenient
-
Just use www.anonfiles.com (http://www.anonfiles.com) and send me a private message with the link :-+
-
New handle looks nice, but the tip to grip could be a bit shorter.
-
I have the stainless steel handle and the gripe I have with it is that there is no positive stop that you can feel the tip has seated and I have pushed the strain relief out of the back because I pushed the tip in too far. I recommend having a positive stop, even if there is no "feel" for seating the tip, to at least stop from pushing the tip in further.
Other than that request, I do like the look of the new handle. :-+
-
There is a limit at the rear end of the handle
Fix the position of the heating core
The position indicated by the arrow in the picture
Now there are already sales in KSGER's flagship store
Nylon material
Considering designing all metal or semi metal materials
If it is made of all metal materials, poor insulation can cause burns to the hands
However, metal materials can achieve contact dormancy
-
Because I am in China and some websites are not open enough, it is better to give me an email address
You still need to pay for opening this link now :(
-
Pm sent :-+
-
It has been sent, please check it
This is my store link on Taobao
https://item.taobao.com/item.htm?spm=a1z10.1-c-s.w4023-10625948436.8.1348758c3PjYp0&id=569286783873
-
I sent a link to a cloud disk for you to try
-
You asked me for the e-mail, just use it ;)
-
It has been sent with another email address, please check
-
Got it, thanks!
Will have a look at it, but just for curiosity, I don't have time for anything! :)
-
Good day to all. Got the station. The screen used 2.42 inches. April firmware .... I hear a small squeak from the display. Probably the throttle on the display board beeps. You can somehow remove the squeak. My screen settings. Thanks to all!
Everything was decided. I forgot about the resistance on the board of 10 ohms to power the display ... The voltage dropped and the inductance on the display began to squeak :). Now, instead of resistance, I put smd inductance - everything is fine! - The squeak is gone, the brightness is excellent!
Can I somehow change the picture on the screen of the T12 sting to C245? I use only C245 - I want it to be right :)
-
I never saw that resistor, is it a custom board?
Just power it with 3.3V directly (The inductor is fine).
-
Boards are sold by a person in Ukraine. I bought a bare board from him ... I soldered the details myself ... I soldered the inductance just so as not to put a jumper ;)...
-
More photos....
-
You can make your own picture using Paint in B&W mode, save it to png or bmp and convert to xbm (https://www.online-utility.org/image/convert/to/XBM).
Edit the xbm file as text, paste the array content here (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/main_screen.c#L107), modify size if different but I recommend using the same size (105x7).
Compilation.is easy following the instructions from github.
-
I will draw ;)
-
Good afternoon David. Tell me what I'm doing wrong .... I tried both version 1.5.1 and the latest 1.12.1. Knocks out an error .... What version of Cube should be installed?
Thank you!
-
Did you follow the instructions?
You only need the IDE, not CubeMX.
Latests version should work right.
Did you read this?
Note: CubeIDE (Current version: 1.11.1) needs Java JDK, but won't work with versions newer than JDK15 (Available here) (https://www.techspot.com/downloads/5552-java-15-jdk.html).
Also, if you made modifications to the code you might have broken something.
First try with a clean source code!
-
I read the instruction. I'll try again tomorrow on another computer...
-
No idea!
You can try by modifying this line (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Building_script.bat#L148) to:
start /w /min "CubeIDE" %IDE% -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -import %cd% -build STM32SolderingStation/%DISP:"=%_Release
That way it should show what's going on.
Or you can do it by importing the project into CubeIDE and clicking the Build button, it's also explained in github.
-
Hi!
It worked on another computer :)! Many thanks for the help :-+ !
-
David, big request. When you have free time, please add to release 1.09.2 the function of automatic selection of tips when replacing ... In 1.10.2 I don't like that the "Power" scale is reduced :(
-
What exactly?
The power bar will stay like that, required to allow longer tip mames.
-
I don't need long titles. I like it better when this strip is long :). So I'm sitting on 1.09.2 ...
And the sting selection function seems convenient. Therefore, if it can be implemented in 1.09.2, it would be great!
-
Sorry, but I can't make a custom firmware for everyone's personal preference, you'll have to stay with 1.09.2...
I think supporting larger tip names is a more useful feature than a slighly bigger power bar... :-+
-
Everything is ok, thanks!
-
Nevermind, I barely touched the station all these months so I didn't notice.
But after watching your picture I realized something... there was too much empty space between the tip label and the bar.
Then I remembered! I had tried even larger text, 13 or 10 chars, so I had to reduce the power bar (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/9c67a48611c73f95d3cc0bb24f22bc71d5e5c675).
The system became unstable and crashed, so in the end I set it to 8 chars... but I forgot to expand the power bar again to use the free space!
So I expanded it again, now it's 52px, still slighly smaller than before (60px), but barely noticeable while keeping the longer tip names.
-
It's a good news. So I'll be switching to 1.10.2!
-
v1.10.3 released (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.3).
I also added your JBC picture! :-+
-
:-+
-
Everything went great! Now I can choose tips when changing ....
-
Nice! :-+
I forgot to commit a small change I made long time ago and never got into the repo, so I deleted 1.10.3 and made 1.10.4 instead.
My encoder sometimes causes unexpected rotation when releasing the button, this became a PITA when trying to set the station to sleep as it would wake it again unless released very fast.
There's a blocking timer to avoid exactly this, only actuates when manually setting the station to sleep/standby modes, but 250ms was too small, increasing it to 500ms seems to be the sweet spot, now it works much better.
I'm sure there's a lot of people with the same problem, though nobody complained?
-
This is good news. I made a new picture of the sting :) ... If possible, replace it in your firmware.
I have a compilation error again |O. Replaced the line. Showed this...
-
Hmm that tells nothing... Try compiling inside CubeIDE.
First run the script, chose only run CubeMX, then import the project in CubeIDE.
Follow the instructions, it's easy!
-
It turned out to compile inside CubeIDE as you said! Thank you!
On the latest firmware, I get a periodic constant squeak of the boozer :-// ... I compiled it myself, I attach the firmware and video ... :-//
https://youtube.com/shorts/uOQ1uSvacn0?feature=share
-
Hi everyone, it’s me again. It’s really good with both TX2 and T12 tips. Now I want to try the 245-122 JBC tip and I run into new trouble.
1. It’s completely turned red if I used pin 4 pin5
2. It showed temperature from 600 down to 350 but the tip didn’t get hot
For my board, I’m using Ksger v3,
pin 1 is sw
Pin 2 marked as J
Pin 3 is PE (might be protective earth)
Pin 4 T- but also connected to ground from power supply and entire board
Pin 5 T+
For the jbc 245-122:
pinC is the protective ground
Pin B is heater +
Pin A is gnd
—————-
With T12 I use only pin 1 pin 4 and pin5
With jbc
The turned red time: I use same as T12 tip
PinA with pin4
PinB with pin5
The no working time: I use the way that Davidalfa show before
-
People! Test the latest firmware 1.10.4. No one has the effect of a continuous squeak of the speaker?
-
I can not turn off the BOOST mode. Video attached... https://youtu.be/wH81Yv0Am4o
-
People! Test the latest firmware 1.10.4. No one has the effect of a continuous squeak of the speaker?
If you turn on the controller with no soldering iron, or tip connected, then the buzzer will beep constantly until one is inserted.
-
People! Test the latest firmware 1.10.4. No one has the effect of a continuous squeak of the speaker?
Did it happen before? No changes were made to anything related to the speaker.
But I never use it, in fact I have no speaker, I removed it since day 2 or 3 I got the station, it was too annoying!
This happened way before developing this FW, about 1 year earlier.
The boost seems to be working fine here?
-
For the jbc 245-122:
pinC is the protective ground
Pin B is heater +
Pin A is gnd
Wrong!
pinC is the protective ground + gnd
Pin B is heater +
Pin A is TC (Temperature sensor).
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1730297)
-
@ricktendo we need to make a proper index in the 1st post, it's always the same questions and issues... ;)
-
I didn’t notice any problems with the speaker on old firmware .... Another problem with BOOST was added
-
People! Test the latest firmware 1.10.4. No one has the effect of a continuous squeak of the speaker?
If you turn on the controller with no soldering iron, or tip connected, then the buzzer will beep constantly until one is inserted.
No, I don't squeak without a soldering iron, is this a problem?
-
Hard to tell - Make a video!
-
Hard to tell - Make a video!
https://youtube.com/shorts/-uQApmdndRo?feature=share
-
I think I found the Boost issue... not an issue. Are you using SMART, right?
You should read the manual. It might not work well in all stations. Some are very noisy, causing this.
In your video it can bee seen it's triggering with no load.
Increase the load level until it only triggers when soldering something.
It needs to be as little sensitive as possible to avoid false triggering, as long as it once every minute or so it'll be fine!
https://youtube.com/shorts/-uQApmdndRo?feature=share
Thsi is not whoeign any issue? Where's that speaker buzzing yout told ealier?
-
I think I found the Boost issue, are you using SMART, right?
Yes.
-
I think I found the Boost issue, are you using SMART, right?
Yes,
Devid, if you make a new release, please add an updated picture of JBC... Photos are attached....
-
Added :-+
Increase SMART to 15 or 20... then try!
I don't use it anyways, I'm fine with the shake sensor.
What about the Speaker issue?
-
Added :-+
Increase SMART to 15 or 20... then try!
I don't use it anyways, I'm fine with the shake sensor.
What about the Speaker issue?
I have a smart at 30. I'll try to turn it off altogether .... The speaker behaved like in this video- https://youtube.com/shorts/uOQ1uSvacn0?feature=share
When the sting is pulled out, it does not squeak.
-
Does it also happen when changing the temperature in normal mode? Or only when boosting?
-
It was 2 times during overclocking and 1 time with manual calibration of 400 degrees. Now it seems to be working fine :-// ... I can't catch it :-// ...
There is no shake sensor. In the menu, work from the stand.Disconnected smart- now the boost is normally turned off :-+.
-
I think it might be a bug caused by setting run mode and quickly set boost mode, without letting it reach the run temperature first.
This might be a condition I'm not managing properly somewhere, I didn't find exactly what or where, but I can't spend an entire afternoon in my only free day debugging this freaking firmware!
The alarm won't be triggered by only removing the tip (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Src/iron.c#L681), it requires more critical errors.
Having the speaker beeping everytime you remove the tip would be pretty annoying!
I made some changes in the code, hopefully it will be solved.
Try v1.10.5 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.5) (Uploading in a few minutes), I can't spend more time in this.
-
Thanks a lot for your work...
-
On v.1.10.5 sounds work great! There are no failures! When "SMART" is on - BOOST does not turn off, I turned it off in the menu - without "SMART" everything is fine.
P. S. David, everything is great - you have done a lot for this board :-+! Don't waste your time off. Need rest ;)! Thank you!
-
Wrong!
pinC is the protective ground + gnd
Pin B is heater +
Pin A is TC (Temperature sensor).
That means my board doesn’t support for jbc tips? Because pin4 is tired with gnd? Or what could I do to use jbc tips with my board?
Really appreciate your time to make this wonderful CFW. It makes the station go to another level
-
Usually you need to make a small modification in the board
Search C245 in this thread, you will find out.
Check out this picture (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/f103-back-hi-res.jpg). Your board seems very similar.
You have to cut the trace R0, then find where the bottom pad is connected in the vertical connector.
That's where you need to solder the C245 "A" connection (The pin the end of the cartridge).
Similar to the one shown here:
https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/msg3871406/#msg3871406 (https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/msg3871406/#msg3871406)
-
Thanks so much, I did it, now it works quite well with both jbc and t12. The tip temperature is really fast and steady. But with jbc245 it seems to be corrosive a lot
-
What do you mean by "corrosive"?
-
Hi.. i flashed the wrong firmware [HW2.1S]_[0.96OLED].hex, i flashing for new stm32 with blue phil board, i plan to install a new chip for my t12, but I don't think it will damage my new chip , currently the chip just wasn't detected with stlink in SWD mode, but the chip can still be read with uart, how do you restore it so that it can read SWD stlink again? i did the steps according to the instructions https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md
-
Did you also try this (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#stm32-not-recognized-error)?
After detection, remove Level 1 protection and erase the chip as shown here (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#coming-from-original-firmware).
-
What do you mean by "corrosive"?
Oops, sorry my mistake. It should be oxidization, I have to sand the tip to use
-
Did you also try this (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#stm32-not-recognized-error)?
After detection, remove Level 1 protection and erase the chip as shown here (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#coming-from-original-firmware).
Hi, thank you, I missed wire up the RST PIN, I did the only jumper PIN7 to GND like capacitor jumper before, but I didn't do the PIN7 cable installation for the RST PIN on STLINK. thanks my STM32 is working again.
-
after compiling the firmware, the log shows a warning:
../Drivers/generalIO/adc_global.c:245:81: warning: expression does not compute the number of elements in this array; element type is 'adc_measures_t', not 'uint16_t' {aka 'short unsigned int'} [-Wsizeof-array-div]
245 | if(HAL_ADC_Start_DMA(adc_device, (uint32_t*)ADC_measures, sizeof(ADC_measures)/ sizeof(uint16_t) )!=HAL_OK){ // Start ADC conversion now
|
21:27:18 Build Finished. 0 errors, 1 warnings. (took 11s.811ms)
please help me what is the problem..
notes: firmware bin working despite getting a warning (1)
-
Have you modified anything? I have never seen that error.
A clean build on CubeIDE 1.12.1 shows "Build Finished. 0 errors, 0 warnings".
Anyways, it's perfectly fine.
typedef struct {
#ifdef ADC_1st
uint16_t ADC_1st;
#endif
#ifdef ADC_2nd
uint16_t ADC_2nd;
#endif
#ifdef ADC_3rd
uint16_t ADC_3rd;
#endif
#ifdef ADC_4th
uint16_t ADC_4th;
#endif
} adc_measures_t;
extern volatile adc_measures_t adc_measures[ADC_BFSIZ];
That code doesn't want to get the number of measures_tin adc_measures, but the total count of uint16_t it contains.
-
Have you modified anything? I have never seen that error.
I haven't changed any of the original code, I just learned to compile the cube ide, keeping the original chip, then I bought a new chip to program. there is currently no change in the code, I use the bat building script by selecting [3] ksger v2
the file compiles without error, there is only 1 warning like the log that I informed you before, I uploaded the bin file to stm32 and it turns on (I haven't attached it to the soldering board yet) this is still done with the bluepill board and by installing i2c oled 0.96
idecube version 1.13.0
then the second problem, I want to change i2c oled to pin i2c hardware mod.jpg (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/v2/Schematic/i2c%20hardware%20mod.jpg) then I enable I2C_TRY_HW on board.h, but I found a lot of errors, I'm very new to microcontrollers, which other parts to change I don't know.
change:
//#define DISPLAY_SPI // SPI display
#define DISPLAY_I2C // I2C display
#define I2C_TRY_HW // Try I2C HW first, use I2C SW if not detected
#define DISPLAY_ADDRESS (0x3c<<1) // Only used for I2C
//#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is used
#define FILL_DMA hdma_memtomem_dma1_channel2 // DMA mem2mem for filling
//#define USE_RST // Reset pin is used
//#define USE_DC // DC pin is used
//#define USE_CS // CS pin is used
#define DISPLAY_OFFSET 0 // Display offset
logs error:
make -j4 all
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.d" -MT"Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.o"
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.d" -MT"Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.o"
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/addons_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/addons_screen.d" -MT"Drivers/graphics/gui/screens/addons_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/addons_screen.o"
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/boot_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/boot_screen.d" -MT"Drivers/graphics/gui/screens/boot_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/boot_screen.o"
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addons_screen.h:11,
from ../Drivers/graphics/gui/screens/addons_screen.c:8:
../Drivers/graphics/display.h:265:2: error: #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
265 | #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
| ^~~~~
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.h:11,
from ../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.c:7:
../Drivers/graphics/display.h:265:2: error: #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
265 | #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
| ^~~~~
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/boot_screen.h:10,
from ../Drivers/graphics/gui/screens/boot_screen.c:8:
../Drivers/graphics/display.h:265:2: error: #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
265 | #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
| ^~~~~
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.h:11,
from ../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.c:8:
../Drivers/graphics/display.h:265:2: error: #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
265 | #error "I2C_TRY_HW defined, but DISPLAY_DEVICE is missing!"
| ^~~~~
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/addons_screen.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.o] Error 1
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/boot_screen.o] Error 1
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.o] Error 1
"make -j4 all" terminated with exit code 2. Build might be incomplete.
21:49:53 Build Failed. 9 errors, 0 warnings. (took 2s.584ms)
-
I guess CubeIDE 1.13.0 uses a newer GCC compiler. It'll be fine, I guess.
Use code tags for your logs!
[c0de]
Paste your code between these tags (write "code" instead "c0de")
[/c0de]
Paste your code between these tags (write "code" instead "c0de")
Better skip the i2c mod, it doesn't worth it, anyways if you insist, by default your Core/Inc/board.h will look like this:
#define HWSTRING "HW: KSGER v2.x"
/********************************
* Display Settings *
********************************/
//#define DISPLAY_SPI // SPI display
#define DISPLAY_I2C // I2C display
//#define I2C_TRY_HW // Try I2C HW first, use I2C SW if not detected
#define DISPLAY_ADDRESS (0x3c<<1) // Only used for I2C
//#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is used
#define FILL_DMA hdma_memtomem_dma1_channel2 // DMA mem2mem for filling
//#define USE_RST // Reset pin is used
//#define USE_DC // DC pin is used
//#define USE_CS // CS pin is used
#define DISPLAY_OFFSET 2 // Display offset
If you enable i2c in CubeIDE, then you must specify the interface used. It will be hi2c1, hi2c2...
You'll find it at the beginning of Core/Src/main.c it after CubeMX generates the code.
So if your i2c interface was i2c2, the handler will be hi2c2. You only need to specify the handler, changing this line:
//#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is
To this:
#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is
-
I guess CubeIDE 1.13.0 uses a newer GCC compiler. It'll be fine, I guess.
Use code tags for your logs!
[c0de]
Paste your code between these tags (write "code" instead "c0de")
[/c0de]
Paste your code between these tags (write "code" instead "c0de")
Better skip the i2c mod, it doesn't worth it, anyways if you insist, by default your Core/Inc/board.h will look like this:
#define HWSTRING "HW: KSGER v2.x"
/********************************
* Display Settings *
********************************/
//#define DISPLAY_SPI // SPI display
#define DISPLAY_I2C // I2C display
//#define I2C_TRY_HW // Try I2C HW first, use I2C SW if not detected
#define DISPLAY_ADDRESS (0x3c<<1) // Only used for I2C
//#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is used
#define FILL_DMA hdma_memtomem_dma1_channel2 // DMA mem2mem for filling
//#define USE_RST // Reset pin is used
//#define USE_DC // DC pin is used
//#define USE_CS // CS pin is used
#define DISPLAY_OFFSET 2 // Display offset
If you enable i2c in CubeIDE, then you must specify the interface used. It will be hi2c1, hi2c2...
You'll find it at the beginning of Core/Src/main.c it after CubeMX generates the code.
So if your i2c interface was i2c2, the handler will be hi2c2. You only need to specify the handler, changing this line:
//#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is
To this:
#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is
yes, this is original code before i change #define I2C_TRY_HW without //
original configuration gets warning 1 during firmware build. but its not a problem, i have tested the bin file its working though getting the warning (1) the image i have added in post #3558
if you have detailed information step by step or video showing how to change i2c mod i will try, but if you think this is not useful i will ignore it, i have read i2c hardware mod.txt (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/v2/Schematic/i2c%20hardware%20mod.txt) Software i2c makes a lot of hacks to squeeze the best performance, and it's about 50% faster. that's why i want to try
after change
#define HWSTRING "HW: KSGER v2.x"
/********************************
* Display Settings *
********************************/
//#define DISPLAY_SPI // SPI display
#define DISPLAY_I2C // I2C display
#define I2C_TRY_HW // Try I2C HW first, use I2C SW if not detected
#define DISPLAY_ADDRESS (0x3c<<1) // Only used for I2C
#define DISPLAY_DEVICE hi2c2 // SPI / I2C handler if used. Enables HW mode, otherwise SW mode is used
#define FILL_DMA hdma_memtomem_dma1_channel2 // DMA mem2mem for filling
//#define USE_RST // Reset pin is used
//#define USE_DC // DC pin is used
//#define USE_CS // CS pin is used
#define DISPLAY_OFFSET 0 // Display offset
i have new log:
make -j4 all
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.d" -MT"Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.o"
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.d" -MT"Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.o"
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/addons_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/addons_screen.d" -MT"Drivers/graphics/gui/screens/addons_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/addons_screen.o"
arm-none-eabi-gcc "../Drivers/graphics/gui/screens/boot_screen.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Drivers/graphics/gui/screens/boot_screen.d" -MT"Drivers/graphics/gui/screens/boot_screen.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Drivers/graphics/gui/screens/boot_screen.o"
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.h:11,
from ../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.c:8:
../Drivers/graphics/display.h:144:9: error: unknown type name 'I2C_HandleTypeDef'
144 | I2C_HandleTypeDef *device;
| ^~~~~~~~~~~~~~~~~
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addons_screen.h:11,
from ../Drivers/graphics/gui/screens/addons_screen.c:8:
../Drivers/graphics/display.h:144:9: error: unknown type name 'I2C_HandleTypeDef'
144 | I2C_HandleTypeDef *device;
| ^~~~~~~~~~~~~~~~~
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.h:11,
from ../Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.c:8:
../Drivers/graphics/display.h:207:15: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
207 | void lcd_init(I2C_HandleTypeDef *device,DMA_HandleTypeDef *dma);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addons_screen.h:11,
from ../Drivers/graphics/gui/screens/addons_screen.c:8:
../Drivers/graphics/display.h:207:15: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
207 | void lcd_init(I2C_HandleTypeDef *device,DMA_HandleTypeDef *dma);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
../Drivers/graphics/display.h:209:32: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
209 | void HAL_I2C_MemTxCpltCallback(I2C_HandleTypeDef *device);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
../Drivers/graphics/display.h:209:32: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
209 | void HAL_I2C_MemTxCpltCallback(I2C_HandleTypeDef *device);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.h:11,
from ../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.c:7:
../Drivers/graphics/display.h:144:9: error: unknown type name 'I2C_HandleTypeDef'
144 | I2C_HandleTypeDef *device;
| ^~~~~~~~~~~~~~~~~
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.h:11,
from ../Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.c:7:
../Drivers/graphics/display.h:207:15: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
207 | void lcd_init(I2C_HandleTypeDef *device,DMA_HandleTypeDef *dma);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
../Drivers/graphics/display.h:209:32: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
209 | void HAL_I2C_MemTxCpltCallback(I2C_HandleTypeDef *device);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/addon_fume_extractor_settings_screen.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/addons_screen.o] Error 1
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/boot_screen.h:10,
from ../Drivers/graphics/gui/screens/boot_screen.c:8:
../Drivers/graphics/display.h:144:9: error: unknown type name 'I2C_HandleTypeDef'
144 | I2C_HandleTypeDef *device;
| ^~~~~~~~~~~~~~~~~
In file included from ../Drivers/graphics/gui/screen.h:15,
from ../Drivers/graphics/gui/screens/boot_screen.h:10,
from ../Drivers/graphics/gui/screens/boot_screen.c:8:
../Drivers/graphics/display.h:207:15: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
207 | void lcd_init(I2C_HandleTypeDef *device,DMA_HandleTypeDef *dma);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
../Drivers/graphics/display.h:209:32: error: unknown type name 'I2C_HandleTypeDef'; did you mean 'CRC_HandleTypeDef'?
209 | void HAL_I2C_MemTxCpltCallback(I2C_HandleTypeDef *device);
| ^~~~~~~~~~~~~~~~~
| CRC_HandleTypeDef
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/addon_switch_off_reminder_settings_screen.o] Error 1
make: *** [Drivers/graphics/gui/screens/subdir.mk:64: Drivers/graphics/gui/screens/boot_screen.o] Error 1
"make -j4 all" terminated with exit code 2. Build might be incomplete.
21:51:44 Build Failed. 17 errors, 0 warnings. (took 2s.251ms)
-
i have read i2c hardware mod.txt Software i2c makes a lot of hacks to squeeze the best performance, and it's about 50% faster. that's why i want to try
Software i2c is what's currently being used. Going to HW i2c won't make any better, it's a slow inteface anyways.
Nah I won't spend my Sunday in this, sorry! Just use it as-is :-DD.
The station won't work faster or anything. It can actually get a lot faster, it's the PWM what limits how often the readings are made.
If you set SYSTEM->GUI time to minimum, then IRON->ADC Time to 50ms and Delay to 5ms, you'll get 20 readings per second instead 5.
Performance will vary, usually new tips go crazy, but after days of use they will behave much better.
-
i have installed the mcu to the board, i just realized my mcu chip is a clone, the problem is it shows NTC low/high and temperature keeps changing. i have read:
If you're getting "NTC high/low" error even when disabling the NTC in settings, then your STM32 is fake.
Check Clones in Compatibility section and Clone fix option in System menu.
after i Clone Fix (ON) the NTC problem no longer appears, and i don't see a change in temperature, but the problem is when i plug in the TIP, the iron TIP is smolder and very hot, on the top right OLED screen it shows the number -99.9C this appears when i installed or without TIP -99.9C always appear.
-
Can't really tell, the clone fix is experimental, just a "try your luck and win" thing :-).
I won't spend any more time trying to make clones work, I highly encourage to replace it with a genuine one.
You might have the NTC connection wrong, or did you even connected it?
If not having NTC, then go to IRON->NTC MENU->NTC enable = OFF, then it will use the STM32 internal sensor.
-
Hi, I've replaced the chip STM32 with original, now problem temperature it's working fine, but I have something to ask, I'm Building the firmware (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Build.md) without error and without warning i add new source (Fix for CubeIDE 1.13.0 warning) (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/generalIO/adc_global.c) the problem is when I change menu SYSTEM->Boot->Change Sleep to Run, after I come back to main screen, I get error as shown pictures, and changing boot "sleep" to "run" doesn't work, it doesn't seem to saved to eeprom the changes.
edit:
maybe i make changes to the encoder too fast and returned to the main screen too soon, i tried to change by turning the encoder slow and pressing "Back" then after 2-3 seconds i select the encoder for click "EXIT" and i didn't find any HARD FAULT, i will continue to try this firmware and report if it encounters an error
-
You can go as fast as you want, it should never do that.
What stm32 did you put in?
Try to replicate the issue, it's been ages since last hard fault.
There's no reason to build yourself, releases are always updated, so try them.
I wonder if it's caused when saving settings to the flash, which is done instantly when exiting IRON menu if anything was changed.
-
i am using STM32F103C8T6 i got original stock and i can Debug on Cube IDE without getting error ST-LINK: Could not verify ST device!
there is new information, I tried the firmware that you have compiled here (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/download/v1.10.5/KSGER_v2_OLED.zip), and it runs as fast as anything without error, I have not found what the problem is, there is a difference in the my build the firmware, I believe I did the steps correctly, and without changing any source code that is in your source code, if you have a lot of time maybe you can try to delete the old project in CUBE IDE and try new a import the source code, I have also added the paths [Properties] -> [C/C++ Build] -> [Settings] -> [Tool Settings] -> [MCU GCC Compiler] -> [Include paths] according to your instructions, but the problem is always there, and if I do a slow encoder change, I don't get a HARD FAULT error on the screen, it only appears if I do it fast.
-
You don't have to do anything like that? Just use the build script!
Or run the script to set the correct files, then import the project into the IDE.
But nothing else is required, like creating a new project etc...
Where did you saw that? Read again the instructions...
-
You don't have to do anything like that? Just use the build script!
Or run the script to set the correct files, then import the project into the IDE.
But nothing else is required, like creating a new project etc...
Where did you saw that? Read again the instructions...
Sorry I didn't say create a new project, but did a new import, sorry my English is bad to understand, it's true I imported according to what was information in Build.md (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Build.md)
-
Ok then! :D
It's hard to know, keep using it, changing settings etc, trying to trigger the issue.
You might try going into system-> reset menu-> reset all, perhabs it's only happening on first boot.
Of course, I always use the latest, this week I soldered a lot of things with no issue at all.
-
Ok then! :D
It's hard to know, keep using it, changing settings etc, trying to trigger the issue.
You might try going into system-> reset menu-> reset all, perhabs it's only happening on first boot.
Of course, I always use the latest, this week I soldered a lot of things with no issue at all.
reset all doesn't fix the problem, not only menu Boot = RUN/STBY/SLP, also menu ADDONS/EXTRAS if I turn Reminder ON, Btn Wake also if change ALL to SLP, then I quickly go back to the main screen, then HARD FAULT appears.
But there is something unique on the Edit Tips menu, I change the name of the tip and then save, and exit quickly to the main screen, I do not see errors there, it seems that the behavior of errors if something has changed without selecting save, then out quickly to the main screen, this behavior cannot store changes quickly, it takes 2-3 seconds to change changes to back to the main appearance then all will be fine, I think this is the problem of storing changes that are made without selecting Save, maybe..
-
Can you make a picture of it?
I can only think on a relabeled clone, or a bug related to CubeIDE 1.13.0.
The last release was compiled with 1.12.1, so if still crashing it wont be a IDE problem.
-
Can you make a picture of it?
I can only think on a relabeled clone, or a bug related to CubeIDE 1.13.0.
The last release was compiled with 1.12.1, so if still crashing it wont be a IDE problem.
You can see the difference between the chips I use, I have 2 clones with the code 991KA 93 SYM and the original code GQ23F 1293 CHN.
and you can also try the bin file from BUILD FIRMWARE which I did, I didn't change any source code, so I make sure that the code is still original.
-
My station is a Quicko, so I can't test other builds properly.
Try the release build and report the result.
It's strange to have only one user having this issue, for now I highly suspect a problem with that stm32
Is anyone running the latest ksger v2 firmware?
-
My station is a Quicko, so I can't test other builds properly.
Try the release build and report the result.
It's strange to have only one user having this issue, for now I highly suspect a problem with that stm32
Is anyone running the latest ksger v2 firmware?
I don't understand what you mean do you want a all file in "SSD1306_Release" folder? if this is true I will upload it
i tested with 2 original chips with different code, i have 1 more original stm32 chip with different code batch, and result is same. do you want me to make firmware for your quicko? maybe you can try it in your quicko with built firmware from my laptop, so you can find the difference.
yes, I am using your latest code source on github. stm32_soldering_iron_controller-1.10.5.
with and without "Fix for CubeIDE 1.13.0 warning" both are the same. i have tested it.
-
Is anyone running the latest ksger v2 firmware?
I am using the latest ksger v2 firmware. Everything is fine. Works without glitches
-
anwfeb, I'm telling you to use the existing precompiled binary in the Releases section, here!
https://github.com/deividAlfa/stm32_soldering_iron_controller/releases
No compiling the latest source!
-
anwfeb, I'm telling you to use the existing precompiled binary in the Releases section, here!
https://github.com/deividAlfa/stm32_soldering_iron_controller/releases
No compiling the latest source!
that is working fine. your binary file is working, I have plans to add ID language, so I need to build the firmware independently.
I am using the latest ksger v2 firmware. Everything is fine. Works without glitches
please try my firmware on post #3574
and try menu -> SYSTEM -> boot, change SLP to RUN, and select. after it you you scroll to Btn wake, and don't change anything, don't touch encoder, and look at the screen, it will exit to the main menu by itself, and find an error.
-
Try CubeIDE 1.12.1. I have not yet tested 1.13.0.
-
Try CubeIDE 1.12.1. I have not yet tested 1.13.0.
on CubeIDE 1.12.1 i get warning
arm-none-eabi-gcc "../Core/Src/user_main.c" -mcpu=cortex-m3 -std=gnu11 -DUSE_HAL_DRIVER -DSTM32F101xB -DSSD1306 -c -I../Core/Inc -I../Drivers/addons -I../Drivers/CMSIS/Device/ST/STM32F1xx/Include -I../Drivers/CMSIS/Include -I../Drivers/generalIO -I../Drivers/graphics -I../Drivers/graphics/gui -I../Drivers/graphics/gui/screens -I../Drivers/graphics/u8g2 -I../Drivers/STM32F1xx_HAL_Driver/Inc -I../Drivers/STM32F1xx_HAL_Driver/Inc/Legacy -Os -ffunction-sections -fdata-sections -Wall -Wno-builtin-macro-redefined -fstack-usage -fcyclomatic-complexity -MMD -MP -MF"Core/Src/user_main.d" -MT"Core/Src/user_main.o" --specs=nano.specs -mfloat-abi=soft -mthumb -o "Core/Src/user_main.o"
../Core/Src/user_main.c: In function 'HardFault_Handler_cp':
../Core/Src/user_main.c:235:3: warning: implicit declaration of function 'HardFault_Handler'; did you mean 'HardFault_Handler_cp'? [-Wimplicit-function-declaration]
235 | HardFault_Handler();
| ^~~~~~~~~~~~~~~~~
| HardFault_Handler_cp
arm-none-eabi-gcc -o "STM32SolderingStation.elf" @"objects.list" -mcpu=cortex-m3 -T"../_STM32F101CBTX_FLASH.ld" --specs=nosys.specs -Wl,-Map="STM32SolderingStation.map" -Wl,--gc-sections -static --specs=nano.specs -mfloat-abi=soft -mthumb -Wl,--start-group -lc -lm -Wl,--end-group
Finished building target: STM32SolderingStation.elf
arm-none-eabi-size STM32SolderingStation.elf
arm-none-eabi-objdump -h -S STM32SolderingStation.elf > "STM32SolderingStation.list"
arm-none-eabi-objcopy -O ihex STM32SolderingStation.elf "STM32SolderingStation.hex"
text data bss dec hex filename
88212 304 12332 100848 189f0 STM32SolderingStation.elf
Finished building: default.size.stdout
arm-none-eabi-objcopy -O binary STM32SolderingStation.elf "STM32SolderingStation.bin"
Finished building: STM32SolderingStation.hex
Finished building: STM32SolderingStation.bin
Finished building: STM32SolderingStation.list
12:30:52 Build Finished. 0 errors, 1 warnings. (took 16s.558ms)
edit:
after several times of testing making the firmware, I found a problem when CUBE MX asked to migrate the project to a newer version version 6.9.0, when I clicked migrate it became a problem even though I was using CUBE IDE 1.12.1 finally I was able to make firmware with CUBE IDE 1.12.1 without Migrate Cube MX, I ignored the Migrate request and clicked continue. now the firmware is working fine.
if draw conclusions then the problem is in CUBEIDE v1.13.0. source code does not match the new version of CUBE IDE.
-
Stay with CubeIDE 1.12.1!
So I tried building in CubeIDE 1.13.0 again, CubeMX has changed, the build script no longer works.
Also it asks to login for downloading the firmware package... what the hell ST?
I will not spend time in this now, perhabs in a few days or weeks. Just use 1.12.1.
All I can do for now is adding a warning in the building instructions (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Build.md#%EF%B8%8F-use-cubeide-1121-%EF%B8%8F-newer-versions-currently-1130-are-causing-lots-of-issuesneither-the-firmware-or-the-build-script-work-properlyuntil-the-issues-are-addressed-up-keep-using-1121).
anfweb, just use the precompiled binary.
There's no reason to build yourself unless modifying the source code.
I simply don't want to waste my time explaining everyone how to use the IDE so they can compile the SAME thing already available in the Releases requiring no work!
-
So I compiled for my Quicko, nothing failed.
When I used the linker script for the stm32F101x (10KB RAM), then it got the Hard Fault.
I inmediately suspected of the RAM. Indeed, it uses 300 more bytes in 1.13.0.
10KB devices are really tight!
I could simply reduce the reserved heap or stack and hope for the best, but I won't risk getting an explosion of users having all kind of errors.
A possible approach will be to use a different flash sector for each profile, removing the necesity of backing up the flash before erasing, will easily free 2KB.
Until I have enough time to find a workaround, it'll be CubeIDE 1.12.1 !
Attaching the Build analyzer output. I inverted the colour, the black theme is terrible (White text over bright green :palm:).
-
A possible approach will be to use a different flash sector for each profile, removing the necesity of backing up the flash before erasing, will easily free 2KB.
I believe you have many ways to give more ram space. while waiting, I will continue to test the firmware with cubeide 1.12.1
and please add one more profile for C115, it looks like the Chinese clone has added TIP C115 in one device.
-
My station is a Quicko, so I can't test other builds properly.
Try the release build and report the result.
It's strange to have only one user having this issue, for now I highly suspect a problem with that stm32
Is anyone running the latest ksger v2 firmware?
I am using the latest ksger v2 and v3 firmware. Everything is fine. Works without glitches.
Stations Ksger V2.1s , Ksger Ve2.1s , Ksger V3 and Handskit . Everything is fine.
-
Anfweb, you don't need a new profile for that as long as you calibrate the tip.
The C115 cartridge isn't easy to interface, if I remember correctly the thermocouple is connected backwards, giving negative voltage output.
That won't work with existing stations out of the box.
-
Anfweb, you don't need a new profile for that as lo g as you calibrate the tip.
The C115 cartridge isn't easy to interface, if I remember correctly the thermocouple is connected backwards, giving negative voltage output.
That won't work with existing stations out of the box.
i saw in this link, TIP C210 C245 C115 PINOUT (https://user-images.githubusercontent.com/749470/99142834-a33c4b00-260d-11eb-9dc2-b2753d5301a6.jpg) it has the same pins as C210, but i haven't tested it yet, i want to buy a TIP and Handle for C115 so i can try it.
actually the ksger V2.1S variant has the original chip code STM32F103CBU6 and that's 20KB RAM, there's still plenty of space available if the board variant has STM32F103 like Quicko and Ksger v1.5
-
Use the search engine, C115/nt115 has been discussed several times:
Apparently, this is the real pinout.
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4435738/#msg4435738 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4435738/#msg4435738)
Someone tried and never answered back.
https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/ (https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/)
The flash is not a problem, only the ram.
As I said, currently I won't spend any time in this project else than small bug fixes, I can't spend entire afternoons in this.
If you buy the C115 tip don't expect me to sit in my desk for two days debugging problems, sorry!.
-
Use the search engine, C115/nt115 has been discussed several times:
Apparently, this is the real pinout.
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4435738/#msg4435738 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4435738/#msg4435738)
Someone tried and never answered back.
https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/ (https://www.eevblog.com/forum/reviews/nt115-jbc-handle-for-ksger-t12-with-cfw-by-davidalfa/)
The flash is not a problem, only the ram.
As I said, currently I won't spend any time in this project else than small bug fixes, I can't spend entire afternoons in this.
If you buy the C115 tip don't expect me to sit in my desk for two days debugging problems, sorry!.
The flash is not a problem, only the ram.yes, STM32F103C8/CB has 20KB of RAM
there is someone who has tested and i saved the video. I want to buy a TIP because I want to test, regardless of firmware source code available or not, because some configuration is already prepared in your firmware such as input resistance "Heater" for example 5 Ohm and I can try with a lower power supply of 9-12V. So don't worry, if you haven't had the time, I'm not going to rush you to make the firmware right away, I want to test with all the existing source code with whatever electronics skills I have.
Video: TIP Solder C115 (https://youtube.com/shorts/J633EkDWZTI)
-
:-DD He's just applying raw power to the tip, there's no temperature control.
The problem comes wth the sensing voltage, whcih is I'm not mistaken, it's negative, that won't work with the current T12 stations without hardware modifications.
-
:-DD He's just applying raw power to the tip, there's no temperature control.
The problem comes wth the sensing voltage, whcih is I'm not mistaken, it's negative, that won't work with the current T12 stations without hardware modifications.
do you mean modify the hardware by cutting the R11 line? i will test the thermocouple with the COM pin and (-) or with (+) before i will remove the mosfet, it works only to read the temperature on the unheated TIP, it only reads through the OP AMPS, if that works, then i will start by installing the mosfet with low voltage, because C115 does not support 24V. I will try it.
this is just a test, how can the OP AMPS read the thermocouple, reverse the thermocouple PIN by testing all the PINs on the TIP to find the appropriate PINOUT location, so the mosfet is then installed, and put with low voltage.
succeed or fail, there's no harm in trying
-
No!
I repeat for 10th time, the C115 sensor output gives negative voltage, contrary to the positive voltage outputted by T12, T210, T245, T470.
You can't magically measure negative voltage without heavy hardware modification, not just cutting a trace.
This could be wrong, as I haven't tested myself.
You don't need t remove the mosfet, simply enable and enter the Debug screen, settign the setpoint to 0ºC.
Or disabling the button and shake inputs from waking up the station in the settings, thus once you set the station int sleep nothing will turn the output on.
There're really small C210 tips, you can use these with zero modifications, connection is the same as T12.
-
hi DavidAlfa,
i have tried to change .ioc cubeMX STM32F101 to STM32F103 for Ksger V2, all went well. however I encountered a problem when I changed the clock to 64MHz. but it works fine at 40-48MHz.
I have read:
#if !defined DISPLAY_DEVICE || (defined DISPLAY_DEVICE && defined I2C_TRY_HW)
// This delay is calibrated for 36MHz (Ksger v2 software i2c). If increasing the cpu frequency, also increase the nop count
__attribute__ ((noinline)) void bit_delay(void){ // Intended no inline to add further delay
asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop");
}
but i don't understand how to increase the nop. when I add more nop code it still doesn't work on my i2c display, even though I try to add a pullup resistor.
My goal of adding the STM32F103 device is so that I have 20KB of RAM working, because I'm using a 103 and the original chip embedded in my ksger board is also a 103.
-
Simply duplicate the line containing the NOPs.
Then open the project properties, go to build settings, linker settings and change the linker script name from the 101 to 103.
That will be all.
-
linker settings have been changed previously,
i did this and it didn't work:
#if !defined DISPLAY_DEVICE || (defined DISPLAY_DEVICE && defined I2C_TRY_HW)
// This delay is calibrated for 36MHz (Ksger v2 software i2c). If increasing the cpu frequency, also increase the nop count
__attribute__ ((noinline)) void bit_delay(void){ // Intended no inline to add further delay
asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop");
}
and try this code not working:
#if !defined DISPLAY_DEVICE || (defined DISPLAY_DEVICE && defined I2C_TRY_HW)
// This delay is calibrated for 36MHz (Ksger v2 software i2c). If increasing the cpu frequency, also increase the nop count
__attribute__ ((noinline)) void bit_delay(void){ // Intended no inline to add further delay
asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop");
asm("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop");
}
-
Then add a 3rd or 4th copy.
But increasing the RAM or the cpu speed won't change anything in the firmware, it's a waste of time.
-
Then add a 3rd or 4th copy.
didn't work until the 5th copy
yes, I just want to try. if that's possible using 64MHz, if not doable I'd stick with 36MHz it works fine.
-
Let me be clear about this, open source means you can use and modify the code as you wish, but that doesn't include free support.
Please understand that I'm not gonna sit an entire afternoon with the debugger, the scope and the code, to find out why it's not working, just because you updated the mcu to a 103 and want 64MHz for no reason beyond your personal whim.
What you're doing will mean absolutely nothing, 36MHz can already do many times faster than you could see, it's the tip response time and pwm noise what keep the limits at 5-20Hz.
All I see is a lost cause.
-
Sorry actually i'm not asking for free support for my own sake, i'm just trying anything to change my board ksger with your firmware, starting from HARD FAULT when i use cube ide 1.13.0, and here i found the answer that the cube ide 1.13.0 version takes too much a lot of RAM, actually this is not that important, but because i saw that my ksger was STM32F103 and had 20KB of RAM, then i tried to change the ioc cube mx to 103, for clock problems there was actually no problem using 36MHz, but because i saw that the F103 was capable of up to 64MHz then i just wanted to try. If can't then i'm not asking you to debugger all day. i will use the firmware as it is without changes.
Thank you, so far i have been able to use your firmware and it has been great.
-
currently i am testing T210, i have changed 6PIN to 5PIN and all is working fine when using the power supply 24V.
but after i read in this forum, many say that T210 is 12V, then i tried with 12V power supply, the result is temperature reading is unstable.
my question is, do you recommend 24V for T210? and will the cartridge last long with a 24V power supply? which do you think is better between 12V and 24V.
-
24v is ok, just set the correct resistance and power limit in the iron settings, so the average power is never exceeded.
I think C210 was 75W or so.
-
24v is ok, just set the correct resistance and power limit in the iron settings, so the average power is never exceeded.
I think C210 was 75W or so.
I don't have a precise ohm meter, but I have 2 different ohm meter and they show ±2.0Ω without cable. (OSS brand cartridge)
for watts, how do i calculate it? while some sources say 12V or 24V.
i have another question, when i change TIP T12 to T210 the firmware can't auto read cartridge type, i have to change it in SYSTEM menu, is there something wrong in my settings?
-
for watts, how do i calculate it? while some sources say 12V or 24V
JBC C245 - 24V 130W, JBC C210 - 24V 40W, JBC C115 - 9V 14W.
-
JBC C245 - 24V 130W, JBC C210 - 24V 40W, JBC C115 - 9V 14W.
nice information,
have you tested the T115 with this project?
-
R is usually 2.6 ohm, just set 80-90W power limit, the firmware will do the rest.
-
I did the calibration, and the measurement calibration results are
C210_Cal250 484
C210_Cal400 1194
after the saved calibration I tested again, and the result is when the
setpoint 200 measurement result 228 => looks high
setpoint 250 measurement result 251 => it's ok
setpoint 300 measurement result 278 => this is lower
setpoint 350 measurement result 336 => this is lower
setpoint 400 measurement result 399 => this looks good
-
Yeah I know it gets a bit off in the middle and the extremes, this is because it's using linear interpolation but the sensor response is slighly curved, now I see it's more pronounced in the jbc than in T12s, which had 5-10°C error typical.
Before the calibration was 3-point, but I was really tired of so many calibration steps for each tip and decided to simply it.
Ideally you would only need one step calibration and just apply a polinomial, but I really got tired of working so much in this fw.
So it's "my free working period has expired, take it as-is, enhance it, or don't use it" :).
But you won't be soldering anything at 200°C and 15°C lower isn't a big deal anyways.
And I prefer the error to be lower than higher!
-
yes, more step calibration, it will be better, even up to 5 steps will get better result too. I don't want you to waste your time if it's not important because I'm just relaying what I'm testing, not that I'm asking you to debug for updates.
-
I can't find "remember last temp" option in SYSTEM menu. I have a battery connected (KSGER v3), all the functions are working well (I'm using T12 tips), but I can't find this option anywhere. What am I doing wrong?
-
Must be manually compiled enabling the option.
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/v2/STM32F101/Core/Inc/board.h#L115
It's pretty simple, just un-comment the line (Remove the //) and run a compilation using the building script.
I'm not a fan of that, I would have done a menu option for it, but I didn't made that specific part and have other important stuff to attend.
-
Got it. Thank you!
Finally I successfully enabled this feature. Also I changed boot screen to the custom one (KSGER logo).
Thank you one more time!
-
David, I have a problem with the readings from the NTC, the station is KSGER 2.1s, when the NTC is turned on with autodetect 10k/100k and pullup 4.7k, everything is ok and shows 25-26 degrees, but when the NTC is turned off, the temperature shows -9 -1 degrees. Isn't it more reasonable to display and use the MCU STM32 temperature with the NTC off.
in my opinion there should be three possibilities ON , OFF and MCU STM32 . This will leave an opportunity to recognize the type of soldering tip (station profile) (T12, C245 and C210) as an example AIXUN T3A there with a different resistor connected to the GND the station profile is determined, for this purpose the NTC input of MCU STM32.
There the selection can be AUTO and MANUAL (T12, C245 and C210).
I haven't tried on my other HANDSKIT and KSGER 3.x stations to see if it has this problem. The version I use is 1.10.5.
This would also solve potential problems with HANDSKIT Stations where the NTC is on the board and not in the soldering iron.
-
Setting NTC off or failure in Auto Mode will use the internal temperature sensor.
I checked the manual and that part is wrong, stating it uses fixed values, that was ages ago.
I never had any issue with this, so it's likely to be a clone or fake stm32.
I used the internal temperature for months when my NTC broke, also lots of people have used it for JBC as the handles don't have NTC sensor.
What stm32 is it? Try making detailed pictures of it.
-
Genuine stm32 20036410 (Digikey) visually it does not look like a clone or a rebranded mcu. , my other stations ksger 3.x and Handskit are with CKS32 original. Pullup resistor is 4.7k 1% . Тhe station was with clone but i changed it.
Currently in the room 24-25 degrees, the station with NTC off shows 8 degrees at the tip and 5.5 degrees in SLEEP , when the NTC is turned on with autodetect 10k/100k and pullup 4.7k, everything is ok and shows 25-26 degrees. NTC has changed 10k 1% and again the same result.
-
The don't look genuine, the label seems printed, not laser engraved..
Maybe the stm32 is defective somehow.
What happens in the other stations?
Ksger stations can have all kind of issues, it could be power-related.
You could try flashing the original firmware and check if it measures correctly when disconnecting the NTC.
About the detection and such, this project is not in active development anymore, so there are no ETAs, no plans, if something is done if will be when I feel motivated enough and having free time, which I'm having none.
Also, what temperature is showing wrong? The ambient temperature or the tip? I understand that both are off.
Can anyone with ksger v2 test this by disabling the NTC?
-
David, I have a problem with the readings from the NTC, the station is KSGER 2.1s, when the NTC is turned on with autodetect 10k/100k and pullup 4.7k, everything is ok and shows 25-26 degrees, but when the NTC is turned off, the temperature shows -9 -1 degrees. Isn't it more reasonable to display and use the MCU STM32 temperature with the NTC off.
in my opinion there should be three possibilities ON , OFF and MCU STM32 . This will leave an opportunity to recognize the type of soldering tip (station profile) (T12, C245 and C210) as an example AIXUN T3A there with a different resistor connected to the GND the station profile is determined, for this purpose the NTC input of MCU STM32.
There the selection can be AUTO and MANUAL (T12, C245 and C210).
I haven't tried on my other HANDSKIT and KSGER 3.x stations to see if it has this problem. The version I use is 1.10.5.
This would also solve potential problems with HANDSKIT Stations where the NTC is on the board and not in the soldering iron.
if you are using internal NTC STM32 (or NTC OFF) and the reading is not accurate, there may be a problem with the clone chip, I have a clone chip and get the wrong value. now i am using original stm32 chip and everything is fine.
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4967692/#msg4967692 (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4967692/#msg4967692)
Can anyone with ksger v2 test this by disabling the NTC?
I just tested the NTC OFF, it looks like the system is reading the NTC from the MCU, before I turned on the iron it showed 26C, after turning on the iron for about 30s it quickly rose to 43C I don't understand whether the STM32 MCU gets hot fast? but this is not a problem, all show the correct numbers, even if they are not accurate, maybe around 1-3C difference with a IR gun thermometer.
-
It's not the stm32 what gets hot, but the psu, voltage regulator, mosfet.. heat eventually spreads across the pcb, this is completely normal and positive, because the handle will also warm up, so it reduces the temperature drift.
If the board was at 20°C while the handle did 40°C, the effective tip temperature would be 20°C lower.
-
The don't look genuine, the label seems printed, not laser engraved..
Maybe the stm32 is defective somehow.
What happens in the other stations?
Ksger stations can have all kind of issues, it could be power-related.
You could try flashing the original firmware and check if it measures correctly when disconnecting the NTC.
About the detection and such, this project is not in active development anymore, so there are no ETAs, no plans, if something is done if will be when I feel motivated enough and having free time, which I'm having none.
Also, what temperature is showing wrong? The ambient temperature or the tip? I understand that both are off.
Can anyone with ksger v2 test this by disabling the NTC?
Now I looked again under the stereo microscope and the marking is laser engraving.
the chips are not polished and remarked.
CPU ID (DBGMCU_ID) = 20036410 are taken from Digikey
I will try to flash 2.11 or 2.12 of the original firmware.
-
Also, what temperature is showing wrong? The ambient temperature or the tip? I understand that both are off.
Can anyone with ksger v2 test this by disabling the NTC?
Both.
With NTC on, ambient temperature and the tip are normal values.
NTC is not disconnected in the soldering iron.
When the soldering iron is disconnected from the station, when starting it shows -9 degrees and slowly rises up.
-
Well, I don't know how the temperature sensor is accurate, but I recall it wasn't very precise.
30°C however is a lot.
Mine is also a 103, recycled from an old blue pill, it has always worked fine.
Try flashing the other stations too, you have the original fw for all of them.
Will try the temp sensor with the ksger v2 build when I arrive home from work.
-
I don't have KSger v2 so I can only run the software blindly, but I can debug it, accessing the internal variables.
As you see, 29.9°C. Something seems wrong in that controller, better attach a picture of the board.
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1847764)
Perhabs it's the terrible 24-to-3.3V LDO design that dumps lots of heat, it often becomes unstable.
Is it stable, or moves around randomly?
It shouldn't move more than 0.2ºC or so between measurement, if it goes like -1, 0, -9, 1 then there's a physical problem.
-
A simplest way I found to avoid 3,3V regulator overheating is to put a 78m05 voltage at PSU board in ksger devices. An empty place for it exists at the board. Also a third pin hole exists under 24v connector. All you need is:
- solder 78m05 at appropriate place
- replace a 2-pin 24v connectors with a 3-pin
- add a third wire to female connector (you can use the same 24v wires, just replace a plastic part of connector)
- remove a diode at the main board (from +24v to 3,3v regulator
- solder third wire to 3,3v input (where diodes cathode was)
- also would be great to clue a small heatsink to 78m05
I made these changes and now it works flawlessly. No overheating, restarting or any other issues.
-
The don't look genuine, the label seems printed, not laser engraved..
Maybe the stm32 is defective somehow.
What happens in the other stations?
Ksger stations can have all kind of issues, it could be power-related.
You could try flashing the original firmware and check if it measures correctly when disconnecting the NTC.
About the detection and such, this project is not in active development anymore, so there are no ETAs, no plans, if something is done if will be when I feel motivated enough and having free time, which I'm having none.
Also, what temperature is showing wrong? The ambient temperature or the tip? I understand that both are off.
Can anyone with ksger v2 test this by disabling the NTC?
First boot after flash with disconneted solder iron (handle) -99.9 C ????????? , NTC setting is default : (NTC on pulup 4.7k autotetect off NTC 10k ) ?????
-
The NTC is enabled but it's not connected (It's in the handle itself), what do you expect?
There's no magic glass ball peripheral in stm32 :D
-
My question is this. Is the hakko t9 tip for the hakko fm2023. The same as the t12. Meaning could you use one t9 tip on these hakko clones. I could get my tweezers to work on two units one unit for each side of the tweezers. But my concern would be would the t9 tip work the same as the t12. Is there any difference between the tips other then size and dimensions. I don't mind running two stations for each tip. As long as it's compatible.
-
I did the calibration, and the measurement calibration results are (...)
I did this on mine (T12 tips)
Setpoint / measured
200 212
250 250
300 299
350 356
400 398
450 444
As you see, adding more calibration steps would be pretty much useless.
Can anyone using JBC tips perform this test?
And if you used AliExpress JBC knockoffs before, kindly explain to anwfeb how terrible they are compared to genuine tips!
-
I did the calibration, and the measurement calibration results are (...)
I did this on mine (T12 tips)
Setpoint / measured
200 212
250 250
300 299
350 356
400 398
450 444
As you see, adding more calibration steps would be pretty much useless.
Can anyone using JBC tips perform this test?
And if you used AliExpress JBC knockoffs before, kindly explain to anwfeb how terrible they are compared to genuine tips!
those are some new type of calibration? (im still on 21y build)
knockoffs jbc get +100-150 C on same adc settings as genuine
-
No... Same as always.
-
Hi, I just received the KSGER T12 3.1s.
The chip is not STM32 but MM32SPIN, how bad is this?
Also I noticed the tip isn’t grounded, I think there might be a connection missing from PE on the power supply to PE on the control board?
-
Search "MM32" in this thread! ;)
Yeah you can just connect PE with a wire.
-
Did that, all it tells me is that people swap their MM32s for STM32s. My question is what are the downsides of the MM32.
Also the second question is about the not connected PE
-
And why do people swap them? Because they are completely incompatible!
There're no "downsides", it just won't work with this CFW.
-
asupsp700 how to convert this 2.42 inch oled display from spi to i2c to work stably?
-
Thank you David for sharing your fabulous work. As you can see, I had an original Ksger v3 that I successfully updated to v1.10.5.
Everything worked the first time without problem.
https://imgur.com/a/j9JdnwS (https://imgur.com/a/j9JdnwS)
I wanted to experiment with original JBC C210 nibs. Do you recommend me to buy this handle?
Have you done any testing with JBC tips? Thanks and greetings from Spain!
https://vi.aliexpress.com/item/1005005719333730.html?spm=a2g0o.store_pc_groupList.8148356.1.9b433fbbCoduam&pdp_npi=3%40dis%21EUR%21%E2%82%AC%2023%2C99%21%E2%82%AC%2016%2C55%21%21%21%21%21%40211b88f016954258235514784e6c9d%2112000034109131586%21sh%21ES%21109409036
-
Hi, can't say, every seller at Aliexpress is a bit like a lottery ticket, quality can vary a lot between them.
What I can truly say is to not buy clone tips, they're crap, even worse than $3 T12 tips, only use genuine JBC ones.
-
Hi, can't say, every seller at Aliexpress is a bit like a lottery ticket, quality can vary a lot between them.
What I can truly say is to not buy clone tips, they're crap, even worse than $3 T12 tips, only use genuine JBC ones.
Thank you for your prompt response, I wasn't planning to spend the money on Chinese tips, only the original ones. The link I have given you is the handle with the ksger connector. This seems like a good option to you, right? Will I have to make any internal modifications or is the pinout correct? Have you personally been able to test c210 tips with this firmware?
-
I use T12, tried C245 knockoff for a brief period of time (Terrible ***) , never tried C210 myself.
I'm pretty sure others here use 210 and worked just fine after calibration.
C210 doesn't need any hardware mods like C245, it's very much like the T12, heater+thermocouple in series, just different calibration.
I guess the handle should right away, ksgers have no "optional" pins for secondary functions, nor different pinout versions.
Personally I'd go with the C245 instead.
The C245 has either small tips for precision jobs, and larger tips for heavy stuff, but the C210 have way less power, so not suitable for heavy soldering work.
Also the C245 tips are ususally cheaper, you can get them for 25-30€, while the C210 tend to be more expensive, around 40€.
It's been a long time sicnce I last checked their prices, might have changed.
-
Hello.
Admiration for your contribution, David! :-+
I am considering of getting the Quicko T12-955 soldering station and mod it with your firmware to use C245 handle and tips.
Do you think that unit is suitable for this purpose?
They state the the power supply is 120W, which is not enough for full utilization of the C245 tips, but still decent enough for the purpose I will be using the soldering station for.
It can also be powered with external 24V power supply which can unlock the full potential.
I am mostly concerned if the MOSFETS and the PCB traces can handle the higher current.
How much power do you think this board can handle stock and will changing the MOSFETS to beefier ones be enough?
Best regards.
p.s.
sorry if that was already asked.. i searched through the thread, but it's way too long to read all the pages
here are two pictures of the unit taken from the listing
-
To: knoway
Need to change MCU to original !!!!!! STM32F103C8T6 , STM32F103CBT6 or CKS32F103C8T6 , CKS32F103CBT6 . The thickness of the tracks and MOSFETS is not a problem for the JBC c245, but to fit a larger 1.7 or 2.42 inch display, the 3.3v needs to be modified in particular (SPX2954AM3-3.3). Аnd add 10 M ( 2M2 ) resistor to input of operating amplifier . This power power supply is 80w.
-
My question is this. Is the hakko t9 tip for the hakko fm2023. The same as the t12. Meaning could you use one t9 tip on these hakko clones. I could get my tweezers to work on two units one unit for each side of the tweezers. But my concern would be would the t9 tip work the same as the t12. Is there any difference between the tips other then size and dimensions. I don't mind running two stations for each tip. As long as it's compatible.
То:Wsander12
Connect the two soldering tips properly in parallel and you should have no problem. Tried by myself with Handkit soldering tweezers. but the power x2.
-
So are they straight lying for advertising the power supply as 120W?
The MCU is already STM32 and as far as I can see, the PCB is this one(KSGER v2):
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/v2/Schematic/STM32_T12_oled_v2.0.jpg
Do I need to change the display for bigger one?
-
So are they straight lying for advertising the power supply as 120W?
The MCU is already STM32 and as far as I can see, the PCB is this one(KSGER v2):
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/BOARDS/KSGER/v2/Schematic/STM32_T12_oled_v2.0.jpg
Do I need to change the display for bigger one?
99% FAKE stm32.
The STM32 has a precise laser-etched label visible well with a microscope.
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#clone-detection
SWD PINOUТ:
-
Sorry for the long answer! Here are the photos. I hope you can figure them out. If anything is not clear, write to dmitriy.kompaniets@gmail.com
-
To remove image artifacts, I added ferrite rings to the wires... And installed 2 kOhm resistors on the sda and scl display lines...
-
To remove image artifacts, I added ferrite rings to the wires... And installed 2 kOhm resistors on the sda and scl display lines...
Have resistor from +3.3v for reset capacitor ?
-
What are you talking about?
Graphical artifacts a are normally caused by DIY PCB designs or using long wires.
Lower i2c pullups will often help, but ferrite beads not much.
Neither it needs nRST pullup, this is internally supplied by the stm32, it would reset itself if it was too weak.
The only cause for a station to reset it's a bad LDO design (Getting too hot and triggering thermal protection) or the PSU getting overloaded because of using a different tip than T12 (Like JBC).
-
Yes, I have. Circled in red...
-
Neither it needs nRST pullup, this is internally supplied by the stm32, it would reset itself if it was too weak.
I wrote for the reset circuit for the screen!
I added ferrite rings because I had them :)
-
Ah, you're talking about the SPI->I2C conversion? In that case yeah!
-
Neither it needs nRST pullup, this is internally supplied by the stm32, it would reset itself if it was too weak.
I wrote for the reset circuit for the screen!
I added ferrite rings because I had them :)
Capacitor for forming reset of lcd 1 microfarad or more ?
-
I set it to 1uF
-
The LCD resets automatically at power-up, only ensure it doesn't randomly reset during operation by some noise.
So you can just use a 100K pullup, there's no need of old-school reset circuit.
Anyways the datasheet is your friend, check it out, most devices have internal pullups/pulldowns to reduce external parts.
-
Dear David. I have two boards (2.1s and 3.1). Both have the same firmware. What diagram should I use to connect the c210 tip? As far as I understand, this is a diagram for connecting c245.
-
Hi, try this. C210 have the heater and thermocouple in series just like the T12.
Like always, be prepared to disconnect the station, if the circuit is wrong the temperature might go out of control.
-
Огромное спасибо за ответ
-
Just tried to flash the CFW. Bought my KSGER T12 in the official store, version 3.1S. After flashing the "KSGER_v3_OLED.bin" the station doesn't boot up anymore. The splash screen keeps flashing. After flashing the "3.1Snew1.hex" provided on the Github, it would start again (with a different splash screen because of the firmware).
Mainboard revision is "3.0" and the STM32F101 shows the code "20036410", so it should be genuine.
Any ideas?
-
Maybe it has the problematic voltage regulator issue, so it can't cope with the extra power.
Try powering it when completely cold, see if it holds a bit longer.
-
I read about this problem on your Github page. But I did not think this could be my issue, because the soldering station does not boot at all. No matter if I supply the PCB via the ST-Link or via the power supply. There are no hot components on the PCBs either. I've got the black "OLED-V3.0" PCB if that's what matters.
-
But does the screen show something?
I understand it's bootlooping at the splash screen, if so, then you're using the correct firmware, a wrong one won't show anything at all.
-
Yup, it shows the splash screen only for a second. When I hold down the button, I can do a factory reset. That's all.
So I should swap the LDO you say? The one on the front PCB? Any recommendations on which one to use?
-
First of all, post a picture of the board to make sure it's one these.
The affected boards run the 3.3V linear regulator right off the 24V, it's just too much power for them.
Try powering it from the ST-Link VDD (Make sure it's 3.3V!), don't plug the AC, should turn on fine, ignore any error messages as the PSU will be off.
-
Here's a picture of my PCB.
It's exactly the same behavior when powering directly over the pin header. While powering over the PSU, I measure stable 3,32V while booting.
[attach=1]
-
Try older releases. Though nobody complained, but who knows.
-
Already tried that, same problem. Didn't flash every single release though. Just some random older ones.
-
same as what I use, the same thing happens in ksger v3.0 if you use firmware v3.1s
-
The 3.1S Firmware from the Github seems to work fine for me. I didn't make a backup of the originale firmware unfortunately.
-
Hmm no idea, my only guess is the ADC not working, triggering the IWDG. Try this.
-
Thanks dude, now your firmware works just fine! So what's the matter (explained for dummies)? Faulty hardware?
-
But is everything working normally? Readings, heating...?
The iwdg is a watchdog, if the program freezes somewhere it will reboot the system.
This is crucial here, the tip temperature might go out of control otherwise.
So for some reason the iwdg isn't resetting in your stm32. Never seen this before.
-
Alright, I used my soldering iron for the whole afternoon. Everything seems to work perfectly. Theres just on thing I noticed: The default temperature is at 320°C. When I adjust the temperature to 330°C, the value isn't saved. Whenever the station goes into standby or whenever I turn it off completely, the temperature is at 320°C again. Is that just a CFW thing?
However, what can I do to use the official firmware build? Do I need to swap the STM32?
-
To avoid excesive internal flash wear, saving everytime the temp was changed, that feature was removed, but you can set the default user temp in Iron settings.
No idea why does that stm32 fail that way, it seems to be defective somehow, so yeah I guess a new stm32 should do it.
-
Alright, thanks for your help! I keep it as it is for now and order a new STM32 at the next opportunity. I keep you updated!
-
Is it possible to have an alligator clip or a plug coming out of the back of one these units (Quicko/KSGER) and have it connected to the stand so that the controller can turn it on or off depending on if the handle is connected to the stand?
I remember reading something a few days ago, but it was late at night, and I'm having trouble remembering what to search for?
I'll be reading all of this thread at some point when I find the time, but just wondering if someone can point me in the direction of a post, or some keywords to search for.
If the above is possible, is it possible with stock firmware, or does it need to be custom firmware?
-
Needs to be taken from the handle shake signal (Disconnect from handle).
The handle must ground that signal when inserted, or press a switch doing it.
Shake option in Iron settings must be set to stand mode.
-
Thanks for your reply. If I am understanding you right, on the handle.. the shake on/off is controlled via SW-200D to pin 1 (in floobydust's schematic). Is it required to modify the handle and remove SW-200D or will it be ignored when in "Stand Mode"?
Is it as simple as grounding the chassis and then connecting the solder stand to the grounded chassis? Or does pin 1 need to be involved?
For example, even without a solder stand, if the menu is set to "Stand Mode" would touching the tip against the grounded chassis exterior put it into standby mode? I mean the "E" part of the tip, not the actual solder tip.
-
Your question makes no sense, if you are told to disconnect the shake wire from the handle and wire it externally, then no, it won't be magically ignored if you don't disconnect it and it won't magically work.
Tip earth and gnd are usually joined, but must be checked, won't work otherwise.
Also read WAKE MODE here:
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md
Wake mode
How to detect activity. SHAKE or STAND.
SHAKE uses a motion sensor present in T12 handles, shake or hold the handle tip up to wake.
STAND uses the same input, but disconnected from the handle. Must be shorted to gnd when the handle is in the stand.
(Stand mode operation operation: Shorted to gnd = sleep/standby, open = run ).
-
I don't have any STM32 stations yet, just trying to plan it out in terms of which handle and stand to buy. There are so many choices, it's all a bit of a headache. I'm also coming off an 8 year break in terms of electronics. My background is terms of soldering is mainly in guitar valve amplifiers. Around 8 years ago, I learned to do some fun stuff but yeah, my electronics/circuit brain is a bit rusty, I need to learn the fundamentals all over again.
There seems to be a good payoff in the long run for these units, if you can do the right mods and use them the right way. And they are cheap, so it's easy to experiment with things. The thing that worries me about the higher end Chinese units like AIXUN T3A is that they are still prone to component failures, no internal fuses, cold solder joints etc. And the front access to the controller board is bad. Where as with Quicko or KSGER.. you can easily access the controller board or replace it, if needed. The CFW seems to open up a lot of options and expand the value of these units, and that is appreciated. The UI also looks really good and 148 pages of development means that it is well tested.
Sorry, I hadn't read the GitHub Manual, I'll make sure to do that now. I've mainly just been trying to spec out the parts so far. I did find some good info earlier in this thread about Stand Mode with others trying to do a similar thing. There might be more but two good discussions I found were here (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3852983/#msg3852983) and here (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg3970742/#msg3970742). Those discussions helped a lot to understand more of what is required and there was also some useful pictures.
Even finding a stand has been hard, for example Wickated made a switch to use a plastic handle with his stand. But it's been hard in the last few days to find a heavy/non slip stand that makes good connection with smaller T12 handle.. and also is conductive and allows for an output or jack plug. I like the look of the Eruntop T12-ST91 for example, but there are two versions.. the earlier version fits T12 handle perfectly, the new version doesn't. (attached pic) :palm: Even without using Stand Mode, there is a thread here that says all T12 stands are bad. (https://www.eevblog.com/forum/reviews/t12-iron-holder/msg3824357/#msg3824357) With the right combination of some modding or patience, I believe something can work well. I have been trying to learn everything in the last 7 days, sorry if some of my questions are silly. I need to learn more, but I think after a few days of having the unit infront of me, it will become more simple.
Is there any difference if using Mini version vs PSU version? I believe the grounding can be different between the two units. But for Stand Mode, it probably doesn't make a difference? Disconnect the connection of Pin 1 in the handle, and run a wire from controller board Pin 1 to the rear of the case (female connector).. connect this wire to the stand, and make sure that it makes connection when the handle is resting in the hand.
-
Forgetting about Stand Mode.. I've been trying to work out the best configuration in terms of mini vs full size. Or green PCB vs blue PCB.
Is there any unit or controller board that is preferred over another? In terms of the step-down converter on the controller board or other issues. Or a safe way to know you are getting a real chip vs a fake chip? I'm considering buying a KSGER V2.1S controller board and handle but using it with a DIY chassis. With a DC 5.5x2.5mm, so that the same PSU adapter could be used for both this unit and also for Pinecil or TS100.
The AliExpress link for the controllers is here (https://vi.aliexpress.com/item/32844179319.html).. in the feedback, the pics appear to be real STM32 chips but I'm not sure how to tell the difference.
Is one better than the other in terms of reliability or suitability for CFW or are they both good (or bad)?
I have so many questions stands, handles, display sizes with different brand chassis but don't want to overload the thread. I would also like to remove the potentiometer and replace it with a higher quality one.
-
None of these, they're the worst ones, with the linear regulator running off 24V, often overheating or failing.
This one is better made.
The green has a buck regulator, the blue con is not shown.
Ask for pictures before buying!
https://www.aliexpress.com/item/1005005590057638.html (https://www.aliexpress.com/item/1005005590057638.html)
But I would avoid the DIY part and buy the full thing dor just $15 more.
Personal advice for the handle: The cheap, blue plastic one.
The others are just stupid, containing aluminium, a great heat conductor, so the entire handle will be burning hot after 10 minutes.
Mini vs full is the same thing, the only difference is the PSU.
-
:-/Oдорогой Дэвид. А ты не думал над прошивкой комбо поколдовать?
-
:-/Oдорогой Дэвид. А ты не думал над прошивкой комбо поколдовать?
А ты не думал переводчиком воспользоваться?
-
Hello,
The search engine doesn't give me the answer, maybe I'm using the wrong words.
I have a V3.1 R0 board, I saw that in R1 and R2 the 24V to 3.3V converter was changed to a linear stabilizer, is it worth converting your board to a linear stabilizer?
I still have the original firmware but it seems that the tip warm-up and temperature stabilization is unstable, could this be the reason?
I ordered new STM32 and when they arrive, I will upload the firmware from the forum, but I am still wondering about the voltage conversion.
-
None of these, they're the worst ones, with the linear regulator running off 24V, often overheating or failing.
This one is better made.
The green has a buck regulator, the blue con is not shown.
Ask for pictures before buying!
https://www.aliexpress.com/item/1005005590057638.html (https://www.aliexpress.com/item/1005005590057638.html)
But I would avoid the DIY part and buy the full thing dor just $15 more.
Personal advice for the handle: The cheap, blue plastic one.
The others are just stupid, containing aluminium, a great heat conductor, so the entire handle will be burning hot after 10 minutes.
Mini vs full is the same thing, the only difference is the PSU.
Thanks, that helps a lot.
-
Hello,
I still have the original firmware but it seems that the tip warm-up and temperature stabilization is unstable, could this be the reason?
Post a picture/link of your board before asking. This one? (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/f101-back-hi-res-12.jpg)
It's a good board, has a switching regulator convertign 24V to 5V, then a linear regulator lowering 5V to 3.3V.
This power scheme rarely caused any issue, if any.
It could just the usual behavior of new tips:
https://github.com/deividAlfa/stm32_soldering_iron_controller#temperature-unstability
You don't need to replace the stm32, we have all the original firmwares:
https://github.com/deividAlfa/stm32_soldering_iron_controller#backing-up-the-original-firmware
-
Post a picture/link of your board before asking. This one? (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/f101-back-hi-res-12.jpg)
It's a good board, has a switching regulator convertign 24V to 5V, then a linear regulator lowering 5V to 3.3V.
This power scheme rarely caused any issue, if any.
Yes, it's the same board, except I have STM32F103.
Are you sure you're thinking about a good board? Shematic (https://github.com/dreamcat4/t12-t245-controllers-docs/blob/master/controllers/stm32-t12-oled/v3.0-and-v3.1/r0/KSGER%20STM32%20OLED-3_0%20schematic%20rev1_cosmin_floobydust.pdf) shows that 24V goes to the JW5026 pulse converter and 3.3V comes out of it.
I know the problem of unstable temperature in new tips, but my tip is already heated. Maybe it's the poor quality of the tip.
I used to have an earlier version of the station and it seems to me that the temperature was more stable and warmed up faster.
You don't need to replace the stm32, we have all the original firmwares:
https://github.com/deividAlfa/stm32_soldering_iron_controller#backing-up-the-original-firmware
Ok, thank you for information :)
-
I can't really tell. I don't have a board collection, only my old Quicko.
Yeah it would be better to take 5V off the converter and use a 3.3V LDO.
-
Ok, thanks for the tips, I will do it and change the firmware, I hope I will see an improvement.
Regards :)
-
Here is a simple example of installed dc/DC module directly to a PS board of my Ksger. The PS board already has a third pin under a 24v connector and all wirings are already there. You just need to install a dc/dc and replace a 2-pin connector with a 3-pin one.
-
Here is a simple example of installed dc/DC module directly to a PS board of my Ksger. The PS board already has a third pin under a 24v connector and all wirings are already there. You just need to install a dc/dc and replace a 2-pin connector with a 3-pin one.
Wow, really elegant solution there. I'm not sure how the circuit works though, maybe I'm misunderstanding it.
In the last few days, I've been reading around, checking datasheets and trying to understand how all of this works and what the problem is. Coming from the PSU, 24VDC is fed to the controller board, where it separates in two directions. One to feed the TPC8107 MOSFET and the soldering iron itself (24V is desired) and the second is to feed the STM32 chip at 3.3V. The caps and resistors before the regulator are to reduce ripple and noise. The regulator steps down the voltage from 24VDC to 3.3VDC. On some boards linear regulators are used (bad) and sometimes buck converters are used (good), because they use a switching method and are more efficient and generate less heat.
The custom firmware draws more current from the regulator because it uses a larger font. It makes the regulator get hotter than usual, so the regulator chip shuts down due to overheating. One solution is to switch to a buck converter, and the other is to add a resistor or heatsink. Or just turn the brightness down on the display. The hard thing with this is every board seems to use a different regulator and every board/schematic is different.
In the solution above, is the 3rd pin the 3.3VDC? So you have 24VDC, 3.3VDC and negative/ground? And then bypassing the regulator/resistors/capacitors on the controller board, and feeding the STM32 directly with 3.3V? Or am I completely misunderstanding this? Would your solution work with all KSGER boards, or only with your controller board? Every board I see looks different.
-
I haven't messaged the AliExpress seller about the controller board yet, I'll do that in the near future. But I've had bad luck in the last week or two, when it comes to communicating with sellers and getting back good answers to questions. I think the language barrier is the biggest thing. And without pics, it's hard to know what you are getting. Or you could order the same thing twice and get two different things.
I've been looking at the idea of modding one of the other two boards (green or blue), because these are the boards that KSGER official store sells and I'm hoping they would still be available later in the future. Between the two, I've been favouring the green board, despite how crude the design is, there are some advantages.
With the GX12 connectors, I've had a hard time finding a high quality version. They all seem to be cheap Chinese ones. And they can't be desoldered without damaging the connector. So it seems easier to chassis mount the connector and have a bunch of spare connectors in a draw somewhere. Also, the KSGER design puts the connector lower than the center line and this makes it incompatible with other front panels. Chassis mounting the connector would mean that it is floating and could be used with other front panels. There is an option to cut the blue PCB and do the same thing. On the blue board, the thermal resistance varies between 46C and 90C depending on the board it's mounted to. The blue PCB is a more dense board and the pins of the regulator are reversed. The pin orientation makes it hard to plan a mod in advance because some of the components are on the other side of the board, where the display is. It's hard to know if there would be access or not.
The green board is crude and basic, but it makes it easier to mod. At first, I looked at replacing the regulator but didn't have any luck finding anything better than what is in there. On the datasheet the thermal resistance is 62C. Other alternatives, were cheaper but the thermal resistance was only 50C. So it seems better to keep the SPX2954A in there.
I've explored the idea of using a 2W Metal Oxide resistor to lower the input voltage. I did some simple diagrams at first, but realized the scale was way off. These boards and all of the components are really small. I looked at some datasheets and tried to get a better idea of the scale, and tried to draw it closer to real scale. I attached a diagram with two options, with resistor before or after the cap. The resistor could be soldered to the input pin of the SPX2954A, or from the empty pad/trace from C2. I generally like to favour strong mechanical connections, but also.. I'm worried that soldering directly to the regulator could damage it. So maybe laying the lead wire flat and soldering to the pad would be less risk.
The diagram positioning isn't literal, it's more to make it easier to read with the labels. For example, the positioning of the cap or resistor could be re-orientated to make it fit better. The components could float in the air 1cm away from the PCB, or be quite close, depending on internal space available. I found some super small heatsinks locally.. 4.5x6mm and a 6.5x6.5mm. The SPX2954A is 6.5mm wide. It could be an option to further reduce temperatures if the resistor alone isn't enough. I don't even know how much heat such a small piece of metal would dissipate, but the heatsink could be attached with a mixture of CPU thermal compound and thermal glue. I've done this before and it works ok.
The mod would have to be right first time because apparently these PCB's are so cheap, they can't handle being desoldered and resoldered much. The thermal glue would also be permanent, but those boards are pretty cheap, so it's easy to have a spare lying around.
I can't find the capacitance value of C2. Would it be better measure it and then order the same value, or is there a value that could be suggested that would work well with this 2W 120R resistor? Would 3W 150R or 200R be better?
My main question is if I am understanding the problem properly, and secondly would this solution work if these components can fit? And is it better to have the cap after the resistor? It usually looks that way in schematics. What uF range would be good for the cap?
-
In the solution above, is the 3rd pin the 3.3VDC? So you have 24VDC, 3.3VDC and negative/ground? And then bypassing the regulator/resistors/capacitors on the controller board, and feeding the STM32 directly with 3.3V? Or am I completely misunderstanding this? Would your solution work with all KSGER boards, or only with your controller board? Every board I see looks different.
The third pin is 5VDC from dc/dc converter board. I have a 24VDC, GND and 5VDC at this connector.
5VDC then fed directly to a linear 3.3V regulator input. In this case it dissipates much less power into heat, and works OK.
It is easy to calculate:
If you fed 24V directly to a regulator, and stm32 consumes 300mA for example, then we have a voltage difference 24-3,3=20,7v.
20,7v × 0,3A = 6,21 watts of a energy must be dissipated. If you fed only 5 volts, then regulator dissipates only 0,51 watt.
This solution would work everywhere. The only thing that not every board have a comfortable spot to solder a dc/dc subboard to it like in my case. But you can solder it where you want, it will work.
-
In the solution above, is the 3rd pin the 3.3VDC? So you have 24VDC, 3.3VDC and negative/ground? And then bypassing the regulator/resistors/capacitors on the controller board, and feeding the STM32 directly with 3.3V? Or am I completely misunderstanding this? Would your solution work with all KSGER boards, or only with your controller board? Every board I see looks different.
The third pin is 5VDC from dc/dc converter board. I have a 24VDC, GND and 5VDC at this connector.
5VDC then fed directly to a linear 3.3V regulator input. In this case it dissipates much less power into heat, and works OK.
It is easy to calculate:
If you fed 24V directly to a regulator, and stm32 consumes 300mA for example, then we have a voltage difference 24-3,3=20,7v.
20,7v × 0,3A = 6,21 watts of a energy must be dissipated. If you fed only 5 volts, then regulator dissipates only 0,51 watt.
This solution would work everywhere. The only thing that not every board have a comfortable spot to solder a dc/dc subboard to it like in my case. But you can solder it where you want, it will work.
Oh right. That makes a lot of sense. Dropping from 5V down to 3.3V must be very on the regulator. Having reread the Github Manual, it also mentions this but at the time of posting, I'd forgotten. I actually have all that info saved to a text file in case the Github ever disappears. It probably won't, but sometimes stuff online does that.
Your math is very helpful and easy to understand. And using 300ma seems like a good general figure. Does anyone know what the actual current draw is in total? I haven't had any luck finding specific numbers, but the datasheet for STM32F101C8T6 says 150ma max total draw. The display is also drawing some current as well though. Googling small OLED displays, it seems to be around 20-50ma depending on the screen size etc. So 200ma but with CFW and large font, maybe it's more.
-
I can measure a consumption a bit later today. I'll give you know.
-
I've been exploring the idea of using Meanwell power supply instead of KSGER, QUICKO or any of the others out there. Reading around, I see random component failures on all of them. Even Auxun T3A. A PSU with a better design, more reliable etc. There's many different options in terms of sizes or options.. I should probably make a separate thread in terms of the DIY side of things.
But in terms of the regulator.. I realized that there is a 12V 0.5A fan output for all three sizes that I am looking at. It says in the datasheet that it is for fan only, but the nature of these solder stations is that they don't stress the PSU very much. It's brief spikes of high load, rather than constant high load. For medical power supplies I can understand the warning, but for a hobby soldering station it should probably be fine to use the fan output for a 3.3V STM32/Display?
If using that 12V 0.5A output into the input of the regulator.. it seems like it could solve this problem without any need for PCB mods. A resistor could also be put in series and covered in a few layers of heatshrink to drop it down to 10V or 8V for example. The electronics math isn't my strongpoint, I usually just try a few different values to see what works and feel if the resistor is getting hot or not.
Using SynthKeyWizard's math above.. 12V down to 3.3V would be 8.7V X 0.3A = 2.61W. The right value of resistor in series could drop it to 8V. 4.7V X 0.3A = 1.41W.
Another advantage of this method would be running the 2 pin fan cable to a switch on the front panel that could connect to the controller board and turn the display on or off. For example.. with a 24V output at the rear of the case, the enclosure could be used as a standalone power supply for Pinecil or TS100 or TS101. The display could be turned off when using the Pinecil, and turned on when controlling the KSGER controller board. And the GX12 connector could be mounted on the rear of the enclosure similar to the Aixun T3B.
-
I can measure a consumption a bit later today. I'll give you know.
Thanks, that'd be interesting information to know.
-
The KSGER blue board (v2.1s) has two linear regulators in series. An L78L08 converts 24V to 8V. An AMS1117 converts 8V to 3.3V. In addition there's a 6.8 ohm resistor in series too.
I have not seen anyone mention fatal problems with that other than the regulators do get a bit hot.
See the thread about it here:
https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/ (https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/)
That's the board I have from a full unit with the power supply. I do not use CFW so I can't attest to its performance. I don't have a thermometer to do calibration. I flashed the CFW once before just to see. And then flashed back to the stock firmware.
-
A 3W 220 Ohm resistor should work pretty well up to 90mA, which I doubt it consumes, more likely around 50mA.
I (mA) LDO ONLY PWR RES (W) PWR LDO (W)
10 0,21 0,02 0,19
20 0,41 0,09 0,33
30 0,62 0,20 0,42
40 0,83 0,35 0,48
50 1,04 0,55 0,49
60 1,24 0,79 0,45
70 1,45 1,08 0,37
80 1,66 1,41 0,25
90 1,86 1,78 0,08
For 50mA, you might increase it a bit more to 330 Ohms, the LDO will only have to get rid of 0.2W.
An excessively high resistor will cause power strain issues (If the current raises too much).
If you have strange behaviour, resetting... lower the resistor in small steps until it works fine.
Like 330->300->270->240->220 Ohms.
The other cheap way is to screw a isolated 7805 (TO220F package) to the aluminum housing, the heat will go into the casing, and the onboard LDO only has to work dropping 5V to 3.3V.
-
I can measure a consumption a bit later today. I'll give you know.
Thanks, that'd be interesting information to know.
Here is my Ksger consumption measured with Owon B41t+.
-
The KSGER blue board (v2.1s) has two linear regulators in series. An L78L08 converts 24V to 8V. An AMS1117 converts 8V to 3.3V. In addition there's a 6.8 ohm resistor in series too.
I have not seen anyone mention fatal problems with that other than the regulators do get a bit hot.
See the thread about it here:
https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/ (https://www.eevblog.com/forum/reviews/t12-stm32-v2-1s-soldering-station-controller-schematic-etc/)
That's the board I have from a full unit with the power supply. I do not use CFW so I can't attest to its performance. I don't have a thermometer to do calibration. I flashed the CFW once before just to see. And then flashed back to the stock firmware.
Learning this stuff in the last week is all a bit of a blur, but I remember seeing a pic of a blown resistor on the power board due to failed MOSFET. It was a black PCB, the green PCB ones seem ok if you modify the heatsink and add a ground wire. The main filter cap can be dodgy though and it's hard to find quality replacements in that size. Also, there's a Aixun T3A video on youtube with a failed diode (it was intermittent and resoldering it helped, but then it failed weeks later). There's been a few more I've seen mentioned in text but hard to remember off the top of my head. Generally, the failure rate isn't that high, but for example quality stuff can last 10+ years. And it seems hard to expect the same from these cheaper units. It's hard to know for sure because most are only a few years old.
Thanks for that info it helps think about some extra possibilities. I've messaged the seller from AliExpress that David mentioned, hopefully I get a reply with some pics. There is a sale on AliExpress at the moment, it'd be nice to order some of this stuff before the sale ends.
I've been reading through some of the thread and all of the talk about regulators makes a lot of sense. Trying to keep heat on the controller board as low as possible, lower noise, better performance, reliability etc.
-
A 5W 220 Ohm resistor should work pretty well up to 90mA, which I doubt it consumes, more likely around 50mA.
I (mA) LDO ONLY PWR RES (W) PWR LDO (W)
10 0,21 0,02 0,19
20 0,41 0,09 0,33
30 0,62 0,20 0,42
40 0,83 0,35 0,48
50 1,04 0,55 0,49
60 1,24 0,79 0,45
70 1,45 1,08 0,37
80 1,66 1,41 0,25
90 1,86 1,78 0,08
I've tried to consider all options available and it's really good to have this information like this.
I saw some buck converters you mentioned earlier in the thread - https://www.aliexpress.com/item/32768078949.html (https://www.aliexpress.com/item/32768078949.html)
Do you still recommend these, or are there better options now? I could see two potential uses for these. One for stepping down from 24V to 5V for the LDO. But also.. if using an external 24V output for a Pinecil or TS101, to adjust the voltage from 24V to 20V for example. The variable resistor faces upwards which would allow for easy adjustment. Would it be fine for these applications? It's so small!
I haven't read the whole thread yet because it's very long. The journey of this firmware has been a long road of 5+ years! Maybe I should read the latest pages first and work backwards.
Another confusing thing.. many pages back (somewhere in 2023 though) someone posted a pic of the green PCB for 2.1S, the one that I also posted. A user said the STM32 chip was probably fake. But the two boards are sold on KSGER's official store on AliExpress. It was probably easier to buy a genuine controller board a few years ago and now it's hard to know.
-
Yeah these regulators are great, but not good for this application, meant for 24V max, you're pushing them to the limit.
Try finding similar ones rated for 30V or so.
Edit: The Mini560 Pro will do fine, capable of 32V (Take the 5V version).
Must be the "Pro" version, the "normal" one only handles 20V max!
https://www.aliexpress.com/item/1005005986412127.html (https://www.aliexpress.com/item/1005005986412127.html)
(https://ae01.alicdn.com/kf/S79233c862c5b4755b547471dba1ecafea.jpg)
Mosfet failure is 99.99% caused by damaged wiring or iron tips, I don't solder that much, yet already 3 tips have shorted.
While you're happily soldering, suddenly a loud ticking sound starts coming from the iron station.
Quickly turn it off, remove the tip, measure it... 0.3Ohms.
After tearing it down, saw the isolated wire had dettached and shorted to the tip case.
-
I can measure a consumption a bit later today. I'll give you know.
Thanks, that'd be interesting information to know.
Here is my Ksger consumption measured with Owon B41t+.
Really interesting information, thanks.
Is there any AliExpress link to the buck converter you used? The way you mounted it was very interesting, in terms of vertically taking up such small amount of space.
-
Yeah these regulators are great, but not good for this application, meant for 24V max, you're pushing them to the limit.
Try finding similar ones rated for 30V or so.
https://www.youtube.com/watch?v=4iAgaBzpOCE&t=486s (https://www.youtube.com/watch?v=4iAgaBzpOCE&t=486s)
Here is a video where the MP2315 module is tested.
At documented 24 V, the module withstood 33 V, went into protection (turned off) at 40 V, and failed (burned) at 45 V.
-
40V? Well, that was just pushing the luck, not to be taken seriously. Just like running 200mph with shredded tyres. Still nice to know :).
The official datasheet (https://www.monolithicpower.com/en/documentview/productdocument/index/version/2/document_type/Datasheet/lang/en/sku/MP2315/document_id/513/) states 24V, 28V absolute maximum, so it might me ok-ish with 24.5-25V.
But definitely not more! :-DD
-
Thanks guys, the controller issue seems mostly solved (in theory).
The controller board side of things seems more manageable now. For example, regardless of which controller board is used.. there seems to be a way to make any of any of them work. And to improvise depending on what each board requires. I hope to get a real STM32 chip and not a fake chip.
In terms of the firmware I've been watching some videos people posted, and wanted to clarify some things. The compatible tips are - Hakko T12, JBC C245, and JBC C210 or is there others?
When the board powers up for the first time, it requires the selection of a profile. Once the profile is chosen, you can dial in and change the settings, create a profile for each tip etc. When the board is switched off and on, the previous profile is remembered. But does it auto detect if you switch from T12 to C245 for example? And if switching to C245, are there a separate set of tip profiles only for C245 tips?
I noticed there are power limits. What are the recommend amps/wattage values for each handle type (for PSU specs).
At 24V:
Hakko T12 - 8 ohm - 72W (but can be 78W if you run 25V for example)
JBC C245 - 2.5 ohm - 230W (160W JBC default firmware restriction?)
JBC C210 - 2 ohm - 288W (160W JBC default firmware restriction?)
I've seen some C245 stations go as high as 200W, while others use lower values. Is C210 supposed to run at 12V? I read something about adjusting PWM to 25% to run it at 24V, does this work ok? I basically just want to know if it's ok to run all 3 of these at 24V and what the power limit range is. And is it in increments of 10, or adjustable by 1? 50W, 60W, 70W etc. And the range of adjustment, for example 40W-160W or 200W?
-
Forget all that, you only set the power the tip is rated for, and the heater resistance.
This is not for the PSU, but to protect the tip, if you could run 200W into a T12 it would burn in seconds.
The FW does this automatically based on the PSU voltage reading, so it doesn't mater if you're feeeding 18, 24 or 30V, the applied power will be the same.
I doubt C210 can hadle 160W continuously (More like 70-80W) without burning or greatly reducing the heater lifespan, though JBC "kicks" it with high power for short time to compensate temperature drop and/or heat up faster.
But this behaviour will be probably be limited and controlled in the firmware to prevent overloading it.
C245 is a lot more powerful and shoudl take 160W without a blink, still no way it can take 280W continuously.
Using 12V might cause the mosfet to conduct poorly, overheat and burn.
Following this request (https://github.com/deividAlfa/stm32_soldering_iron_controller/issues/68), I made some changes to the button handling.
- Release v1.10.6 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.6)
Feedback will be appreciated, but don't enter frenzy request mode, I really can't spend much time there.
-
Forget all that, you only set the power the tip is rated for, and the heater resistance.
This is not for the PSU, but to protect the tip, if you could run 200W into a T12 it would burn in seconds.
The FW does this automatically based on the PSU voltage reading, so it doesn't mater if you're feeeding 18, 24 or 30V, the applied power will be the same.
I doubt C210 can hadle 160W continuously (More like 70-80W) without burning or greatly reducing the heater lifespan, though JBC "kicks" it with high power for short time to compensate temperature drop and/or heat up faster.
But this behaviour will be probably be limited and controlled in the firmware to prevent overloading it.
C245 is a lot more powerful and shoudl take 160W without a blink, still no way it can take 280W continuously.
Using 12V might cause the mosfet to conduct poorly, overheat and burn.
Following this request (https://github.com/deividAlfa/stm32_soldering_iron_controller/issues/68), I made some changes to the button handling.
- Release v1.10.6 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.6)
Feedback will be appreciated, but don't enter frenzy request mode, I really can't spend much time there.
I approve and love the ease of the new feature; however, maybe you should rename "Btn wake" setting to some abbreviated form of "Rotary/Encoder wake"
-
C'mon, Btn ~= The user-activated thingy!
Now, which would be the easiest, most straightforward / self-explaining for most users? ;)
- BTN wake.
- ENC wake.
- ROT wake.
Absolute correctness it's not always the best!
I don't have a 4K display to show "Rotation-triggered wake source activation".
Still wrong, someone will think it has to rotate the station itself, or the table, or rotate the tip 180°.
Or better π/2, just in case someone tries heating the station to 180°C to wake it up... :-DD
Jokes apart, as per the manual that everyone should read:
Button Wake
Selects what modes can be waken with encoder activity.
[None] [Standby only] [Sleep only] [All]
This option is disabled when Wake mode is set to Stand.
-
Forget all that, you only set the power the tip is rated for, and the heater resistance.
This is not for the PSU, but to protect the tip, if you could run 200W into a T12 it would burn in seconds.
The FW does this automatically based on the PSU voltage reading, so it doesn't mater if you're feeeding 18, 24 or 30V, the applied power will be the same.
I doubt C210 can hadle 160W continuously (More like 70-80W) without burning or greatly reducing the heater lifespan, though JBC "kicks" it with high power for short time to compensate temperature drop and/or heat up faster.
But this behaviour will be probably be limited and controlled in the firmware to prevent overloading it.
C245 is a lot more powerful and shoudl take 160W without a blink, still no way it can take 280W continuously.
Using 12V might cause the mosfet to conduct poorly, overheat and burn.
Following this request (https://github.com/deividAlfa/stm32_soldering_iron_controller/issues/68), I made some changes to the button handling.
- Release v1.10.6 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.6)
Feedback will be appreciated, but don't enter frenzy request mode, I really can't spend much time there.
Oh, so input voltage into the controller doesn't matter and the current is adjusted automatically. That's good to know.
I understand that I may have been over complicating things, but it's mainly because I'm trying to decide chassis size, and PSU specs. A part of me thinks that it might be better to start a DIY thread, but also a lot of this does relate to the firmware. In terms of what the options can be.
I'm exploring the possibility of using two irons at once from the same chassis. Keep in mind, similar to yourself, I don't solder that often but for specs, it might be nice to have for those rare times where I want two different tips for example. And having one enclosure and mains cable instead of two makes it easier. For example a heavy tip with higher power to solder a larger electrolytic cap, and a smaller iron with a smaller tip for fine PCB work.
Option A, a larger chassis than the standard size.. enough headroom in the PSU that it never reaches the limit (200W). Restricting power levels in the firmware doesn't matter much in this case.
Option B, the standard size chassis (maybe 160mm long instead of 130mm).. but with only 140W power capability. This should be enough power for C245 to work ok. Using C245 with a Pinecil/TS101 would not be an option. But T12 and C210 could work quite well in combination with external 24V port. The PSU has 3 X 24V outputs. For example, one for controller board, one for buck converter and one for rear output. But if the two combined are nearing the wattage of 140W, could I power limit T12 to 60W for example, or C210 to 40W if a situation required it? The way the irons draw current for a few seconds after wakeup, this is probably a non issue but I like to always have a little bit of extra headroom for long term reliability.
C245 140W
T12 80W
C210 60W
Those are the wattages I would like to use, but with the ability to set the T12 to 60W or 40W. And the C210 to 40W. Just wondering if this is possible. For example.. using T12 at 80W. Plug a second iron in the back for 5 mins.. set the T12 to 40W. Use the second iron for a few mins and then unplug it. Set the T12 back to 80W. I'm not really looking to request a bunch of firmware features, I understand that this is frustrating to have too many requests, but more to understand what it is already capable of. Also, sometimes simplicity is better than having a menu with 100 options. But this new feature does seem useful.
A vote here for ENC Wake, but it's a preference thing and all 3 are ok. There is only one button, so BTN Wake works. If I were in your position, I'd name it one thing and see how many people care. If it's the majority change it, if it's just one or two people.. leave it as is.
-
It's so sad that after 2 years only one person found the small easter egg!
* sigh *
Hint: Double click SYSTEM / HW. Then enter sleep mode.
-
Hello DavidAlfa - thanks for great firmware! Need some help for improving station - I installed firmware (controller KSGER v3.0s, I will also flash a second one with v2.0s hardware in the near future) - via UART, everything is fine - except for "self-resets" at the slighty filling of the screen (for example when adjusting temperature), lowering the brightness did not help much. The power supply produces about 25.6V, the stock LDO at 3.3V was installed "SE8533" - which heated up like a beast.
As a result, I found a 100 ohm - 5 W resistor - I soldered it between the diode output and Vin of the LDO. The unit is also heating up - but resets when adjusting the temperature are generally completely gone, BUT with some glitchy T12 tips (with some voltage surges/drops in the power supply) - the station still resets when attempting to fully heat up (or a minute after successful warm-up).
Is it worth the trouble of installing a DC>DC module 30V>3.3V\5V? (here I also don’t understand why some people use 5V? Will this speed up the burnout of the OLED) - and will there be any advantages and improvements in performance? And will it help with the operation of “buggy tips” (I soldered the pins under the hood, it didn’t help - BUT these tips work perfectly on a simple T12 soldering station without full thermal control), also - i have also 100nF capacitor with FX9501 handle clone kit - is it necessary to install this cap on the NTC resistor or another line?
-
Is power limit adjustable on the firmware, I haven't seen a video showing that. If it is, I just want to know the range of adjustment.
I'm going to create a DIY thread, so that I don't derail this firmware thread with parts that don't relate to it directly.
Is it worth the trouble of installing a DC>DC module 30V>3.3V\5V? (here I also don’t understand why some people use 5V? Will this speed up the burnout of the OLED) - and will there be any advantages and improvements in performance?
Hopefully someone more informed can address this, but I believe it's all about making the regulator on the controller board behave correctly. It's designed to step the voltage down and dissipates the excessive heat in doing so. If feeding the LDO 2V for example, I don't believe it would function correctly, although some designs might. There are other factors as well, like noise. For example.. you could get a buck converter that outputs 3.3V and feed that straight into the STM32 and but this isn't optimal and would most likely be very noisey. The PCB is designed with this in mind. The LDO needs to be as close to the STM32 as possible, and the other resistors and capacitors are in the circuit also filter noise, based on the datasheet requirements of that specific regulator.
So it seems the best situation.. use the buck converter elsewhere, and then feed it into the LDO on the controller board. A value 4V could probably be used but isn't a common number, 5V is common and easy to find and the heat generated is very small. 6V, 7V, 8V they all work but generate unnecessary heat. I could be wrong but I think the main goal is to feed the STM32 with a line of DC that has as low ripple and noise as possible. For overall good stability and performance of the controller chip and display.
-
No, you feed the 3.3v regulator with 5V instead from 24V, everything is still powered with 3.3V.
-
Hello
I have a Lafayette SDD-9 (ZD-931A), which is working properly but which I no longer use (it is slow to heat up).
I would like to upgrade to use it again and would like to replace it with one of these T12 boards.
Since it has a wide transparent window, I would like to use the whole thing.
What is the version on the market with the largest possible screen?
Thanks!
-
Largest is 1.3" but you can replace the screen with a 2.4" ssd1309 oled.
-
After doing more reading, I've realised that T245 is not interchangeable, and that auto detect is not possible with the firmware. Choosing profile is required when switching handles but that is no problem. For CFW, C210 + T12 can be interchangable or T245 by itself. T245 requires a mod on the PCB. I've found some screenshots of what the PCB mod is but I'm not still not sure 100% what the mod is doing. Or how to wire the T245 handle vs T12 and T210, but that is not important for now. I'm mainly focused on T12 and T210. I might do a T245 station later.
I ordered some Sugon handles for T12, T210 and T245, but they haven't arrived yet. The main reason I chose Sugon is because the front part of the T12 handle fits into the Aixun T3A stand properly is the same size as T245. They come with a 6 pin connector but after rewiring they will be compatible with Aixun T3A station. But mainly, I want them to work with KSGER CFW but I realised that there are some other differences.
For example JBC style handles like Aixun and Sugon use 3 core soldering cable. There is no NTC wired in the handle and no shake switch. No shake switch is fine because I want to use Stand Mode.
Is NTC required to be wired into the handle for the CFW to work properly? I saw that in the firmware, there is NTC MENU section but I am not sure what the settings mean. Can I make adjustments in the firmware so that T12 and T210 works with no NTC in the handle? I assume that it can work this way but I haven't yet found the information about this. I'm not even sure why there is NTC in the handle, because the tip is supposed to have one already inside of it?
If I need to, I can order some NTC MF58 3950F 1% and some 4 or 5 core wire. But is it required for these Sugon handles to function properly with CFW?
-
Please first read the user manual at GitHub, ask later!
The mod is required because C245 has independent TC sensor, while in T12 and C210 it's in series with the heater.
After the mod, you'll use a new pin for TC, so it won't work with T12 / C210 anymore, that pin must be joined to T+ in the connector of C210 and T12 handles to make them work.
-
Thanks for your reply. I don't fully understand how these soldering irons work, so I need to learn the basics of what that means, in terms of why one unit wires it one way and why the other handle wires things a different way. The positives and negatives of each approach and how it changes things.
I thought I had read the manual when I read this. (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/README.md) But a few days ago I was downloading ST-LINK and trying to understand the firmware, and then found this (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md) and felt stupid, and realised I haven't seen it. Is this what I need to read? I might have already read it when I found it, but I was tired and might have forgot something.
I've been trying to juggle too many different things lately. But there is also no rush because it will take two weeks for ordered things to arrive. I've downloaded and installed all of the software for ST-LINK, but I'm new to all of this stuff and there is only so much time in the day. I was drawing some handle/PCB wiring diagrams but then I realized I don't know if I need NTC or not. Or if 3 core cable is enough to work with KSGER firmware.
I will have a nights sleep and read the manual again with a fresh mind.
-
Yes, the operation manual..there you will see what NTC settings do.
But yeah it'll work without a NTC, but might have some temperature drift as the handle heats up.
-
None of these, they're the worst ones, with the linear regulator running off 24V, often overheating or failing.
This one is better made.
The green has a buck regulator, the blue con is not shown.
Ask for pictures before buying!
https://www.aliexpress.com/item/1005005590057638.html (https://www.aliexpress.com/item/1005005590057638.html)
But I would avoid the DIY part and buy the full thing dor just $15 more.
Personal advice for the handle: The cheap, blue plastic one.
The others are just stupid, containing aluminium, a great heat conductor, so the entire handle will be burning hot after 10 minutes.
Mini vs full is the same thing, the only difference is the PSU.
Hello ,
do you have a link for a compatible station?
Thank you in advance.
-
Then follow this connection.
Edit: Also added pcb picture just to annoy Wickated :D
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1392896)
(https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/?action=dlattach;attach=1392878)
hi i have the same station which is mm32, is this the only modification so that i can use c245hanle and tips?.
-
Yes
-
Hello
do you think this stations are compatible with cfw?
I think 1 and 3 are.
Do you have something else to suggest?
1https://www.aliexpress.com/item/1005005222965956.html (https://www.aliexpress.com/item/1005005222965956.html)
2https://www.aliexpress.com/item/1005003246293974.html (https://www.aliexpress.com/item/1005003246293974.html)
3https://vi.aliexpress.com/item/32803295956.html (https://vi.aliexpress.com/item/32803295956.html)
4https://vi.aliexpress.com/item/1005001608493682.html (https://vi.aliexpress.com/item/1005001608493682.html)
-
Yes
hi david, thanks for the reply, so with stock firmware, the c245 tips will work? and the handle is the same on the socket?
-
Hello! I assembled a custom soldering station - the ksger 2.1s circuit was taken as a basis, but the project was assembled based on the bluepill stm32f103c8t6 board - a printed circuit board was developed for this project, DavidAlfa firmware for ksger 2.1s oled was installed. Everything worked right away. I decided to assemble a similar soldering station, but the Quicko STM32F103 scheme will be taken as the basis and I encountered such a problem - the image on the display is shifted up, the VTM88870B display controller ST7565, in the arduino the display works correctly, I chose the U8G2_ST7565_LM6059_F_4W_SW_F_P _Spi u8g2 (u8g2_r0, /* clock = */ 13, /* data=*/ 11, /* cs=*/ 10, /* dc=*/ 9, /* reset=*/ 8); .Can anyone help me solve this problem?
-
You'll have to find out why. Probably different LCD init sequence or pixel addressing/offset.
This would need tweaking in these files:
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/display.c
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/display.h
Probably in the ST7565 disp_init[] array.
-
Thanks for the advice, I just recently started learning stm32cube ide, my little knowledge was enough to understand what to look for in this direction, but in arduino ide this was solved much easier for me by simply declaring a variable, but here everything is more complicated for me. Anyway, I'll try. By the way, the latest firmware release works better than the previous one, my station began to almost instantly come out of sleep mode and the off state when the handle was lifted, and there are many other positive things.
-
Hello, which solution is better for fix power issues? I have ordered DC>DC buck modules Mini560-Pro 3.3V \ 5V (5A max load)...
1) Use 5V DC-DC module, 24V to DC-DC input and 5V to 3.3V LDO Input
2) Use 3.3V DC-DC module, 24V to DC-DC input and 3.3V to LDO Out
3.0s board - still self-resetting some times (SE8533 LDO with 100ohm 5V resistor on input), 2.1s board work well - but 1117 LDO clone are very heat....
-
I use a combination of DC DC mini-170 3A (in addition to adjustment, you can also rigidly fix the voltage using jumpers and it is suitable for the input voltage) and ams1117 3.3v everything works great, the only thing is not to spare capacitors for the ams body kit
-
Thanks for the advice, I just recently started learning stm32cube ide, my little knowledge was enough to understand what to look for in this direction, but in arduino ide this was solved much easier for me by simply declaring a variable, but here everything is more complicated for me. Anyway, I'll try. By the way, the latest firmware release works better than the previous one, my station began to almost instantly come out of sleep mode and the off state when the handle was lifted, and there are many other positive things.
I'll try to figure it out based on the u8g2 settings you posted (Just arrived home after a very loooong working week).
Edit: I think it will be display.c, line 26 (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Drivers/graphics/display.c#L26).
Replacing:
1, c_start_line,
With:
1, c_start_line | 31,
Try different numbers between 1 and 63. I might add a new option in the display settings for this.
Attaching sample firmwares with modified LCD starting line, testing offsets 30, 31 and 32.
This causes the same image effect on my "normal" LCD, so hopefully will fix your's.
You can easily patch any official firmware release without compiling it.
Open the .bin file in HxD and search for this hex pattern:
01 AE 01 40 01 A0 01 C8 01 A6 01 A2 01 2F 02 F8 00 01 25 02 81 22 01 A5
Once found, replace the 4th byte (0x40) with the desired offset, possible values are 0x40 (0 offset) to 0x7F (63 offset).
0x40 is 64 in decimal, so it's any number between 64 and 127, use any decimal to hex converter online / Windows calculator (Set to programmer mode).
But it looks to be very close to 30-32 offset, so 64 + 30/31/32 = 94/95/96, 5E/5F/60 in hex.
Hello, which solution is better for fix power issues? I have ordered DC>DC buck modules Mini560-Pro 3.3V \ 5V (5A max load)...
A typical regulator needs "output voltage" + 1.5V, so 3.3+1.5=4.8V
Always feed it slighly higher voltage than required to provide better noise supression, 5-7V will be a good place.
-
It worked! I installed all the firmware for Quicko stm32f103 sequentially - the image was normally stabilized when setting offset 32, it would be very nice to be able to make such adjustments in the firmware itself. I also checked these parameters by installing them in the stm32cube ide environment, according to your recommendations, everything works!!! Thank you very much for your help and your work!
-
Added new option for display Y offset. (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/d2874febc1cfb64b5c452ff2f69108d3055ef879)
New relese: v1.10.7 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.7).
Cheers! :-+
-
hi david, which custome firmware is available to this version of ksger t12 station?
-
None. And won't happen.
Read the manual / readme at GitHub.
Only oled stations with stm32!
-
Yes, the operation manual..there you will see what NTC settings do.
But yeah it'll work without a NTC, but might have some temperature drift as the handle heats up.
I think I'll order some NTC just to be on the safe side. Is it advisable to add NTC to C210 or C245 handle? Will it help with temperature stability with those too? The Sugon handles have 6 pin cable, so I need to rewire any handle that I use. If I already need to rewire the handle, adding NTC doesn't seem to be much extra work.
I understand how to wire the T12 handle, there are diagrams everywhere. I understand the C210 handle can be wired the same way as the T12. For the C245, I haven't found any good resources. Is there a link or guide somewhere? I will keep searching around.
-
thank you for the clarifications. one more thing, is this device used to flash the custome firmware for the iron? im so sorry for being noob.
-
The cheap ST LINK V2 clones on eBay or AliExpress is all you need.
-
No real need of NTC for safety reasons, it might drift 10-15°C without it, no worries.
-
I've read through the manual a few times in the last few days and feel like I understand the basics of the operation of the soldering station pretty well. My main problem is understanding the electronics fundamentals and the technical stuff. It's like I'm in the first few weeks of electrical college course. I've done stuff like this before but it was 8 years ago. Learning it again is fun, but it's also complicated. Maybe I don't need to know these technical things right now, if I can add a buck converter to the LDO input, and find wiring diagrams for the handles. In terms of fine tuning PID settings, this seems super technical and complicated. In the beginning, I think I can be happy with a basic functional station with no major bugs.
Either way, I will be trying to read this entire thread at some point. There is a lot of good information, and maybe that will help in understanding certain things better.
I've been playing around with a modified Splash images, I modified the original from Jesus Vallejo's image. I've attached a sample image at 200% to make it easier to see (256X128 instead of 128X64). The basic idea is to have something based on the handle that the station uses. And to try and make sure it's centered on the display but people's display can be different. It's easy to adjust the PNG or PSD file to move 1 pixel left or right if it's not centered. There is T2XX and C2XX versions for personal preference. This is all personal preference, but that's the advantage of custom firmware.
I'm not even sure I will use them but if Jesus Vallejo doesn't mind, I could share them here in a zip file, if anyone else wants to try them or modify them.
-
I updated all my soldering stations and the board of the future project for an LCD display - I had no doubt that everything would work perfectly.On LCD display by default, y offset was set to 56, set it to 32 with the encoder and the image on the display became normal,I didn’t have to adjust anything on the OLED displays. I would like to ask - are lcd displays supported only on the st7565? After all, the library supports many more displays, I’m just going to buy more displays for st7567 and uc1601 (they are on the list, at least for Arduino), I’ll try to experiment with them. And one more question - the list of supported firmware languages is final, I would just like to see the Ukrainian language too?
-
I designed the firmware for (And only for) existing stations (KSGER, Quicko, Handskit), which will be the majority of users, thus the gui fits *specifically* 128x64 displays, others will look weird.
Some people had a hard time reading those small displays, and 2.4" OLED were pretty expensive, so I decided to add support for those LCDs, which can found everywhere for cheap.
Only OLEDs (SH1106/SSD1306/SSD1309, etc) and ST7565 LCDs (And compatibles, like your LM6059) are and will be supported.
I won't be adding support for other displays, as I said this targets specific hardware, so just buy the correct display from the beginning.
Of course, it would be possible to make it work with other displays, but I can't be making a custom FW for everyone going different, so you'll have to do it yourself.
BTW I forgot to change settings version, so the firmware is taking the existing data, which will be wrong, that's why it was set 56 by default, that variable was used for something else.
Fixed in v1.10.8 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.10.8).
-
I'll still try to experiment in this direction.
-
Hi guys,
With your help I updated my HANDSKIT T12 station to David's CFW and modded it to work with a C245 some months ago. Love it!
Yesterday I found this extremly cheap C210 handle and "had to" order it including another, spare C245 handle. Ordering both, combined shipping applied (cheaper shipping costs). The price was just too good. Now I thought this is maybe also interesting for some of you guys:
[attachimg=1]
You can find it here on AliExpress (https://s.click.aliexpress.com/e/_DCdLuc9).
Has anyone of you ever opened this kind of handle or even inserted a shake sensor into it?
Best,
Rixi
-
David, what we have been talking about in the last few weeks is slowly starting to make more sense now. I connected a 3.3V buck converter last night and did some experiments but also have 5V and other versions to play around with if required. The 3.3V worked fine, but the soldering station was idling and wasn't under load. I have the Blue PCB and can share voltages that I measured at a later point.. if it helps anyone.
I received a full KSGER unit on the weekend, and opened it up last night for the first time. I didn't buy any KSGER handles, I will only be using modified handles.. so it'll be a while until I wire up a handle and can test actual soldering.. but understanding how the unit functions is becoming easier and easier now that it is in front of me. I can't patch firmware until the ST LINK arrives, which is maybe another week or two. But I understand the purpose of NTC in the handle and cold temp vs thermocouple temp a little bit more now.
I have attached a wiring diagram that I created a few days ago. If there is any criticisms or improvements, anyone feel free to share your thoughts. It's easy to edit and can be helpful in the future for noobs (like me). There's two versions, a simplified version, and an extra info version.
It is intended to be printed out on A4 paper in landscape mode. But can also be used in any image viewer on the PC obviously.
-
You can find it here on AliExpress (https://s.click.aliexpress.com/e/_DCdLuc9).
Has anyone of you ever opened this kind of handle or even inserted a shake sensor into it?
Are these Sugon handles? Or a clone? They look the same. I have T12, C245 and C210 versions of these handles and will be wiring them up in the next few weeks. I won't be using shake sensor though, only Stand Mode for sleep via banana jack on back of chassis. But for your question, it seems easy to simply wire pin 1 the same way as original KSGER handle. It depends if it's a 3 core wire or a 5 core wire (probably 3 core). I bought 5 core wire for this reason (flexibility of options).
The wiring diagram I attached above is based on using those style of handles. They are basically green/foam versions of the blue Aixun handles. It doesn't say, but it seems like there is 6 pin (black connector) and 5 pin (silver connector) versions. There is such little information it seems to hard to say, but the handles look exactly the same as Sugon handles. The interior of the handle likely looks something like this (attached).
-
You can find it here on AliExpress (https://s.click.aliexpress.com/e/_DCdLuc9).
Has anyone of you ever opened this kind of handle or even inserted a shake sensor into it?
Are these Sugon handles? Or a clone?
[...]
The interior of the handle likely looks something like this (attached).
I don't know the Sugon handles. A year ago I ordered a handle that looks the same (like the linked one) and had the same black connector. I then soldered my own connector to it, so I can use it with my HANDSKIT T12 station (very similar to KSGER, Quicko... stations) and it works great.
I already tried to open this handle, but I couldn't find out how. And was affraid of breaking it. That's why I asked if anyone already opened it. My goal is to upgrade it with a shake sensor.
Instead of the shake sensor I would also be happy with a proper stand to use the "stand mode". The only nice stand I found is this (https://s.click.aliexpress.com/e/_DmQP0pX) grey one from Aixun, but it's so expensive. Any recommendation for a cheaper, but nice stand?
-
I always hated the profiles being erased when the settings version changed, and I'm sure you also did.
Some parts of the firmware were still made for the old settings storage (Circa mid-2022), but since then, system settings and profiles were moved into different sections, so there was no reason to keep erasing everything when one part failed or changed.
From now, when the system settings version changes (New option added/changed to system settings, but still same tips/profile structure), the profiles will be kept :).
New release: v1.11.0 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v.1.11.0).
-
David, that’s awesome. You are awesome!
-
You can find it here on AliExpress (https://s.click.aliexpress.com/e/_DCdLuc9).
Has anyone of you ever opened this kind of handle or even inserted a shake sensor into it?
Are these Sugon handles? Or a clone?
[...]
The interior of the handle likely looks something like this (attached).
I don't know the Sugon handles. A year ago I ordered a handle that looks the same (like the linked one) and had the same black connector. I then soldered my own connector to it, so I can use it with my HANDSKIT T12 station (very similar to KSGER, Quicko... stations) and it works great.
I already tried to open this handle, but I couldn't find out how. And was affraid of breaking it. That's why I asked if anyone already opened it. My goal is to upgrade it with a shake sensor.
Instead of the shake sensor I would also be happy with a proper stand to use the "stand mode". The only nice stand I found is this (https://s.click.aliexpress.com/e/_DmQP0pX) grey one from Aixun, but it's so expensive. Any recommendation for a cheaper, but nice stand?
I believe it requires breaking it, but it's only breaking the glue bond. If I find a link to the video or pictures, I can post it. And then once the wiring is finalized, it can be glued again. But it's not something you want to be modifying constantly. There is also a chance that the handle will be damaged, all of this stuff is experimental. But others have successfully pulled it apart and put it back together.
If you go back a few pages, I had a lot of problems with finding stands. For now, I'm using the cheaper Aixun T3A black one. It will function ok. There's room in the future for other options, but for now I'm just focused on verifying that everything functions ok electrically.
-
You can find it here on AliExpress (https://s.click.aliexpress.com/e/_DCdLuc9).
Has anyone of you ever opened this kind of handle or even inserted a shake sensor into it?
Are these Sugon handles? Or a clone?
[...]
The interior of the handle likely looks something like this (attached).
I don't know the Sugon handles. A year ago I ordered a handle that looks the same (like the linked one) and had the same black connector. I then soldered my own connector to it, so I can use it with my HANDSKIT T12 station (very similar to KSGER, Quicko... stations) and it works great.
I already tried to open this handle, but I couldn't find out how. And was affraid of breaking it. That's why I asked if anyone already opened it. My goal is to upgrade it with a shake sensor.
Instead of the shake sensor I would also be happy with a proper stand to use the "stand mode". The only nice stand I found is this (https://s.click.aliexpress.com/e/_DmQP0pX) grey one from Aixun, but it's so expensive. Any recommendation for a cheaper, but nice stand?
I believe it requires breaking it, but it's only breaking the glue bond. If I find a link to the video or pictures, I can post it. And then once the wiring is finalized, it can be glued again. But it's not something you want to be modifying constantly. There is also a chance that the handle will be damaged, all of this stuff is experimental. But others have successfully pulled it apart and put it back together.
If you go back a few pages, I had a lot of problems with finding stands. For now, I'm using the cheaper Aixun T3A black one. It will function ok. There's room in the future for other options, but for now I'm just focused on verifying that everything functions ok electrically.
If you find a video or picture how to open the C245 handles, this would be great ! I searched for it some time ago but didn't find anything.
-
I did see a video somewhere, but it's often late at night when tired and of the memories blur together. There are a lot of us in this situation and the information is hard to find. I'm quite busy currently but I'll see if I can find it again in the next few days.
-
I finally made a board identification page (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/boards.md), also identified the ones with poor LDO design (Overheating, board resetting).
Feel free to contribute if there're missing boards/info!
-
If I‘m not wrong this board design is not covered.
It‘s from my HandsKit Station, bough April 2022 on AliExpress, but it’s not available any more.
Successfully flashed with KSGER_v2_OLED.bin
[attachimg=1]
-
Added, thanks.
Seems like another one with bad regulator design (5V taken from 24V). Does the regulator cope with all the heat?
At least it has a large 78M05, should be hable to handle a lot more heat than those small SOT-89 regulators.
-
Is this the regulator?
[attach=1]
When I find the time I'll try to figure out how hot it gets.
-
Yes
-
I will try to add some information and voltages from blue PCB version later today. I couldn't find any seller on AliExpress, selling anything other than green or blue PCB for V2.1S. Even other listings.. even if it's a good pic of a good controller board, it's likely fake because they say in communication that it will be a blue or a green PCB (random). It's pretty hard to find to find the specific one you want. It seems like it was easier a few years ago. I bought a full KSGER station which came with the blue PCB. And I have a separate blue PCB (hopefully) just in case I brick the firmware or some other accident happens. I already shorted one of the LDO's when probing because the pins are too damn small. Or I suck. :palm: The board still works, and I was going to use a buck converter anyway, so it's not a big thing. But shows how easy it is for things to go wrong.
If you find a video or picture how to open the C245 handles, this would be great ! I searched for it some time ago but didn't find anything.
I found the video.
https://www.youtube.com/watch?v=Ekg2QZa0ghE (https://www.youtube.com/watch?v=Ekg2QZa0ghE)
It's not Sugon or Aixun, it's a T245 from a BST station but these are all JBC handle clones and I expect them all to be similar internally since they are variations that are cloning the same thing. I attached a screencap of the glue I was talking about. I don't know if this helps, the handles you linked could be completely different.. but it gives an idea of what to expect. It's possible the plastic could crack, but in the video it didn't.
-
Before probing the output of U2 was 8.04V, after probing it a few times.. it now outputs 2.32V and the display won't turn on. Looking at the PCB, I'm not sure what I did because it doesn't seem possible to touch the outside pins together with a probe pin. Maybe a cold solder joint or maybe U2 didn't like the physical stress of being touched while turned on? :-// I was going to cut the trace and bypass U2 anyway, so it's not a big problem.
When connecting 2XAA batteries to the middle pin of U2, or using 3.3V Mini 560PRO Buck converter, the display turns on and board functions normally. I don't have a handle wired yet, but in terms of navigating menus, the board will works fine. After 5-10 mins.. the average temp across the whole board is 32C, including U2 and U6 but that's while idling. I'm sure it's much hotter under load.
I attached a pic of the blue PCB with some voltages, and a C245 PCB mod. With this board configuration, is it easy to solder the JBC wire to pin 4, or is further modification necessary around the amplifier chip?
-
Where did those 8V came from?
About the JBC mod, did you isolate that pin on the connector? Otherwise it'll be GND.
-
hello david, my board uses fw from version v1.10.8v to v1.11.1 and has the error as shown in the picture, but from version v1.10.6 and earlier it works perfectly fine. Don't know what the problem is?
-
Edit: Working here? I build a special v1.11.1 version that enforced 10KB RAM so my F103 behaves like the F101.
I tested:
v1.10.6 ->v1.11.1 : OK
v1.10.8 ->v1.11.1 : OK
As expected (Being different setting versions) it erased the settings, but had no issues of any kind.
Try writing the FW again, or a button factory reset (Though this would never be required).
-
With the blue version I bought, from version v1.10.8 to v1.11.1 there was a Hard fault error, but for the black version I made it myself following your diagram, all versions worked. both run stm32f103cbt6, both versions have quite similar diagrams, only the voltage regulator circuit level 3v3 for the mcu is different.. maybe I will use the black version.😆. Thanks David
-
Doesn't make sense, same MCUs, same FW, there's nothing different.
-
I'm searching for a "naked" T12 controler board capable of running the CFW and a C245 handle.
Any recommendations?
While browsing AliExpress I found this (https://s.click.aliexpress.com/e/_DD139RJ) boards. They are not my choice, because they are based on STC MCUs and AFAIK it's not possible to run the CFW on it. BUT in the product description I found this diagram, showing the wiring of the different handles. Not sure if this has been posted here already, but I thought it could be useful for many people here:
[attach=1]
-
Where did those 8V came from?
About the JBC mod, did you isolate that pin on the connector? Otherwise it'll be GND.
I haven't been able to figure it out where the voltage into U6 is coming from. It's 4V in and 8V out, I don't know how this is possible. It's so hard to probe these boards, they are so small! I can try probing around again and trying to understand the circuit more. I was expecting to see 24V on one side, and 8V on the other with ground in the middle. All I know for 100% sure is.. U6 outputs 8.04V into U2. And U2 outputs 3.23V. The 560 PRO mini buck converter outputs 3.28V. I took a few extra readings for D2 and R14 and updated the pic, but it's possible that something has failed and that the voltages are wrong. But when I took the initial readings, everything seemed to be working ok.
For JBC Mod, I haven't isolated any pins yet, currently I'm just trying to do the diagrams (to plan things out). Isolating pin 4 should be easy because I probably won't use the right side of the PCB.. I will be using a panel mounted GX12 connector, probably at the rear. With a 2.54mm JST XH connector soldered to the PCB and connecting to the GX12 connector.
Also.. I received the ST LINK in the mail and was able to successfully patch the firmware. Instead of using buck converter, I now use ST LINK's 3.3V supply to power the board when playing around with the firmware or the menus. It has worked 100% reliable doing this so far. As long as the connectors don't fall off of the pins.
The only hard part about the firmware was that the ST LINK pin holes have 2mm spacing on this blue board, and the ST LINK cable connectors have wider spacing (they fit ok for the display pins). I cut open a JST XH connector and took the pins out and soldered them to the PCB. The way I made it work.. was that I only used the two inner pins and tried to jam the connectors in there tight. And I used VDD 3.3V and Ground from the display pins. Doing this.. the 2.0mm spacing wasn't an issue. I've attached an updated pic of PCB with the pin outs for the ST LINK if anyone else wants to flash firmware on this board. It is confirmed official STM32 chip. :-+
-
I have to say.. this custom firmware is fantastic! It was easy to flash, the batch file works well for making changes to it.. everything was fast and easy! And even though I don't have any handles wired yet.. while it's idling.. the menus and everything is working very well. The font looks good. I've already made some changes to settings.c, so that it remembers my preferred settings so that I don't have to change them every time I flash. And some small GUI changes customized for this specific display. I'm using 250ms update delay and the display seems fine.
The firmware is great! You've done a really great job David.. it's easy to understand why this thread has 150+ pages. I also made a batch file, so if there is any firmware version upgrades, it can patch the tip profiles and settings preferences. Power limit numbers, brightness settings, sleep mode settings etc. The profiles and tip selection seem to work really well for switching between handles and tips. This is only while idling with 0V on the 24V rail, but so far it's working well. The UI looks good and the menus are easy to use.
-
That board is not in the list, can you reupload that image, but clean?
Enjoy the FW! :-+
I haven't been able to figure it out where the voltage into U6 is coming from.
It's R14. 6R8? Drops some of the voltage so the LDO work is a bit easier.
Be very careful when probing these!
Specially around U2, a small mistake and you'll send 8V to the stm32 instead 3.3, boom!
-
For long time I hated the profile switching method, requiring several steps (MENU / SYSTEM / PROFILE).
So I added quick profile selection (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/6df05df32ea4dd9608adf34c998883c593c94c3d) to the main screen.
- Perform clockwise drag-rotation to enter tip selection mode.
- Repeat drag-rotation (Any direction) to enter profile selection mode (T12, C210, C245).
New release: v.1.11.2 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.2).
-
A few new parts arrived via mail and it has helped a lot. I received a microscope camera from AliExpress, from here.. https://www.aliexpress.com/item/1005005446066467.html (https://www.aliexpress.com/item/1005005446066467.html) with 1-130X Lens.
So I was able to take a new pic of the PCB for better detail. The camera is only 1080p via USB connection, but it works in MPC-BE (my preferred Windows video player) and via keyboard shortcuts it can be rotated, zoomed, panned etc. I've never used one of these before but I am very happy because I think the picture is good for the price. Assuming you have good lighting (I use a combo of cheap AliExpress lamps). And you also need to focus the lens for the sweet spot. I am hoping that it makes the small components easier to work on. I don't recommend getting it now, but during the sales. The kind of sales where it's $6 off for every $30 spent. You can split the order into 2 orders for example (for stand and lighting) and save $60 or more in total if you buy from the right stores. It arrived in 14 days.
Also, a spare Blue PCB board arrived and the 8V mystery is solved. The new board has 23.5V for the input pin of U6, so in the first board one of the components must have been faulty. The first board never tested at the right voltages even at the beginning. And after some probing, the voltages became even stranger. Other voltages on that board test differently as well.. for example.. it has 1.4V for JCB Mod/T12+ pin during idle. The new board has only a few hundred mV when idling. I'm not sure which one is correct, but I assume it is the new board. It's possible I did damage when probing, I am not 100% sure. I only probed the 2 regulators and the JBC pin. But everything else is working ok I think.
I have attached a new PCB pic, hopefully everything is correct now. There is a blank PCB version, and a Mod Info version.. hopefully these can help others. I was using a tshirt to update firmware instead of a silicone mat, apologies for any lint or fluff on the PCB.
I cut the trace for the output pin of U6 and the PCB quality doesn't feel cheap, it feels pretty good. It wasn't easy to cut the trace, it took a bit of work. I have read on other forums that this Blue PCB board gets very hot even with 8V into U2. So the 560 Pro buck converter seems like a good option. I will experiment with 5V or 3.3V and see which works better. And make sure not to blow up STM32, that would not be good.
-
Here is a blank PCB version..
I look forward to trying the new profile selection..
-
Thank you very much you for you firmware, I've used it in my custom controller and it works great. I've added temperature saving to the flash with method similiar to the eeprom emulation.
static uint16_t readTempInit();
static uint16_t readTemp();
static void writeTemp(uint16_t tempRam);https://github.com/elektryk2/stm32_soldering_iron_controller/blob/master/Core/Src/settings.c
There's some mess with commits in my fork because I've started with code from the beginning of the year and then incorporated my changes to more recent code...
And something about supply, initially I've had L7805CV with heatsink and then 3.3V LDO, now 7805 is replaced with DD4012SA 5V DC/DC converter and its pretty cool.
-
Here is a blank PCB version..
PNG is nice for drawings because it compresses the data a lot without quality loss, but for pictures they get huge, please use jpg for such large pictures.
I've added temperature saving to the flash with method similiar to the eeprom emulation.
It's not that I forgot temperature saving, it was there but I removed it to reduce flash wear, only has around 10K erase/write cycles!
Otherwise each temperature change would erase and save new settings.
You can easily change temperature 10 times a day, plus swap some tips, change other settings... Easily reaching this limit in 2 years or less.
So, I just set the default temp value to the usual 350-370ºC.
Yeah an external FRAM could be installed etc... I keep saying this firmware targets original controllers, requiring minimum modifications.
NOT the 0.001% custom-made stuff, those will also have to perform custom firmware changes, don't ask me to do so :).
Most, if not all boards, have a battery connector for the RTC.
Connect the battery, enable #define HAS_BATTERY in board.h, now it'll save the temp to the RTC SRAM.
Simple as that!
Edit: For some reason this was mentioned nowhere.
Edited the README (https://github.com/deividAlfa/stm32_soldering_iron_controller#temperature-setpoint-saving), adding it.
-
I've seen that option with battery but my mod fills whole page with 2 byte temperature and issues erase only after all cells are not blank.
So if I'm not wrong it should extend declared flash lifecycle by 512x.
-
I didn't check the code yet but maybe it was the approach I thought on several times, using an entire sector for temperature variables, initially filled with "FF", writing "0" to used positions, and storing the temperature to the next position, the code seeks through them and uses the first one available.
When the entire sector is used, the settings are erased and starts over.
I simply hadn't time nor motivation for it.
Some controllers generate a hard fault if the sector is not erased prior writing, had lots of testing pending.
Edit: Yeah I see your mod does this.
I'll have a look, needs a bit more polishing, adding new section to the linker scripts to avoid code overwriting that area, but proves it to be working :).
-
My approach does almost the same but without overwriting with zeros. If next value is 0xFFFF, then the previous should be desired value saved last time.
-
Yeah I noticed that :).
Made some additional checks, simplified other parts, made sure it didn't break the battery mod, use a declared array in its own linker section instead hardcoding it, it's implemented now (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/5e7aa600700033699ea3c1f2ee4c4c71560220f2).
I didn't add any setting to enable or disable this function, it's enabled by default unless using the battery mod.
We can't use 1KB page size from the STM32F10x, as STM32F072 has 2KB pages and it would break compatibility.
Thus, 2KB space is reserved for this in the linker scripts (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/50a9a5f1603408af3ac28e71c7204f28ea98621c).
This allows +1K saves without erasing. Still plenty of flash available, around 25KB for STM32F10x, 15KB for STM32F072.
New release:v1.11.3 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.3).
Thanks for your contribution! ;)
-
I'm glad I could contribute something helpful.
I've got only 103CB, so some hard coding was used and yeah it was a bit easier to simply #define that offset.
-
The problem with hardcoding is that you aren't reserving that space.
So, the code might get into that area, then get erased by the temperature save function.
Long time ago I also used this method for the settings, the program became larger and larger until eventually I started getting hardfault errors for no apparent reason... but it was exactly this! :)
And few more updates:
- Remove Profile selection from System menu, now it's done from main screen.
- Remove Remember Temperature / Profile / TIP from System menu, now they're always remembered.
- Convert battery mod to a System menu option. If your board has battery installed, enable this to reduce flash wear.
New release:v1.11.4 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.4).
The current Youtube video is very outdated...
I don't have a fancy wooden table, nice lights or a decent phone, but I remember some people here posting some really good videos.
If you feel like having 15 minutes to make it, showing the functions, calibration, tip/profile selection, it would be very helpful! :)
-
Guys, I can’t keep up with you in flashing my station ;D. Update every day ;)
-
The current Youtube video is very outdated...
I don't have a fancy wooden table, nice lights or a decent phone, but I remember some people here posting some really good videos.
If you feel like having 15 minutes to make it, showing the functions, calibration, tip/profile selection, it would be very helpful! :)
You could ask this guy (https://www.youtube.com/@sdgelectronics) to make an update video. Love his channel and it has a very good outreach I guess.
Or David L. Jones running EEVBlog & Channel? That would "somehow" make sense, too ;-)
-
I'm searching for a "naked" T12 controler board capable of running the CFW and a C245 handle.
Any recommendations?
Any experience with this (https://s.click.aliexpress.com/e/_DmCvqSZ) or this (https://s.click.aliexpress.com/e/_DE55HMp) controller board? Do they work?
Which one (not limited to the two linked) would you recommend?
-
No experience myself but it's the same thing after all, just another Ksger V2.
The only issue can be a weak regulator design.
-
I'm searching for a "naked" T12 controler board capable of running the CFW and a C245 handle.
Any recommendations?
Any experience with this (https://s.click.aliexpress.com/e/_DmCvqSZ) or this (https://s.click.aliexpress.com/e/_DE55HMp) controller board? Do they work?
Which one (not limited to the two linked) would you recommend?
https://vi.aliexpress.com/item/1005002382830287.html?spm=a2g0o.order_list.order_list_main.419.4e541802bKgvf0&gatewayAdapt=glo2vnm
This seller is selling a finished controller to work with JBC and is with original STM32, he is selling PCB to the controller. It serves desoldering module and works with a valve or a vacuum pump.
The controller is of very good quality, the flux everywhere is perfectly washed. The EC11 encoder is perfect.
-
David, I would like to know, I will ask a possibly idiotic question, is it possible to run an LSD display on the ksger v2.0 firmware by editing the board.h file. It’s just that my custom board has the ability to connect such a display, is it currently using a 1.3 OLED display with the latest version of your firmware - 1.11.4?
-
If the LCD supported I2C... But the ST7565 and compatibles were only SPI, thus not by default, would need hardware (Wire
the SPI connection) and firmware (Enable SPI peripheral/pins in the .ioc, board.h) modifications.
Run the build script, load Ksger V3, then open the .ioc file in CubeIDE, see how the SPI peripheral is configured, LCD cs, dc, rst pins...
Also read Creating .IOC file (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Creating_ioc.md).
Anyways those LCDs look terrible, slow response, poor contrast...
Edit: Post the lcd pinout and I'll show you, it's very easy!
-
These are the displays I have in stock - they are the same as in the video published on your channel with the only difference - you had a display with white letters on a black background, and I have a standard display of characters for a graphic display. By the way, I Now I’m using the latest version of your firmware - the stability of the firmware has increased very much (I sometimes got a hard vault message on the screen, which was cured by rebooting the station (this is not critical), what’s more critical is that I couldn’t add all my T12 cartridges into memory, which I use and, accordingly, their calibration data. At first I sinned on my board - I have it completely custom based on bluepill and assembled using the ksger 2.1s topology, but after updating to the latest version 1.11.4 everything returned to normal. A pleasant bonus was the presence of a battery mod exactly in the station settings.
-
Except the previous post where someone was having a hard fault in a v2 controller, while working in another, using the same firmware (Very strange) this FW has been perfectly stable for quite a long time, easily 2 years.
Hard fault should never happen, when it ever did I fixed it quickly! Any bugged release was deleted, so there's no " v1.11.2 was buggy, don't use".
What I need it's not the lcd pinout, but the stm32 connection to it.
You said the custom board has connections for the LCD, that's what you should show, specially the schematic for it.
-
I meant that when I saw your post with firmware 1.11.2, you recommended enabling battery mod by editing the board.h file (I should have uncommented the battery enable line in my opinion) and in this file I saw that the connection lines for the spi interface were commented out and I asked this question about the possibility of connecting in version Xger 2.1. Now I see that this is impossible, but on Xger 3 and quicko lcd firmware I successfully installed various displays on 7565 and 7567, by the way the display on the uc1601 controller worked, unfortunately photo I didn’t do it, I connected the display as an experiment, the main displays in the tests were 7565 and 7567. And regarding the error that pops up, it was not a matter of your firmware, but a small flaw in the printed circuit board, which I corrected. I would like to thank you for the enormous amount of work you put into creating the firmware. I’ll make a donation at the first opportunity, right now there isn’t one - the front line is 50 km from my house and my payments from PayPal and other payment systems are still blocked, I hope that soon everything will end. Thank you again!
-
No worries, just enjoy it! :)
Anyways, it would very easy to add the SPI LCD if you connect it to a SPI port.
You need any SPIx SCK/MOSI.
Then use any free pin for CS, DC and RST.
(https://i.pinimg.com/originals/83/34/de/8334de3f3836cacc6020d8824d4e5fc7.png)
-
Inspired with some posts about the LCD I've tried it myself.
Here's DOGM128 with ST7565R controller.
-
- Remove Profile selection from System menu, now it's done from main screen.
- Remove Remember Temperature / Profile / TIP from System menu, now they're always remembered.
- Convert battery mod to a System menu option. If your board has battery installed, enable this to reduce flash wear.
New release:v1.11.4 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.4).
- Fix bug introduced in v1.11.4 blocking low temperature requests made by calibration and debug screens (Oops, no time for testing everything :P).
New release:v1.11.5 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.5).
-
David, I had a problem with the firmware - the firmware was 1.11.4, I decided to flash it to 1.11.5 and an error occurred during startup (I am attaching a photo), it helped me a lot that I had a second station with your firmware - I took a dump from it, I flashed the second one, reset it to factory settings and configured it. In principle, I didn’t notice any special problems in 1.11.4, but with the new firmware version such a problem arose.
-
Working perfectly for me (Quicko F103), which controller is it? KSGER v2?
What FW version did the second controller run?
Why copying the other controller dump instead erasing and flashing a clean firmware?
Or just use the button factory reset method?
v1.11.5b (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.5b), I'm now including the listing file (It's just a text file) so you can see the problematic code when a hardfault happens, search the PC address there (Bottom left value in the screen).
Comment any issues in v1.11.5b discussion board (https://github.com/deividAlfa/stm32_soldering_iron_controller/discussions/78).
-
I have a homemade soldering station board, assembled according to the ksger v2 scheme, but I use a bluepill stm32f103c8t6 board and until the last moment all the firmware was installed and worked perfectly, my second station is the same, but works in c245 mode - they are completely identical, except for working in different modes. I think it’s most likely the board, although before that everything worked fine
-
It doesn't make any sense. Proibably some issue in the HW.
-
I think so too, so I’ll stay on 1.11.4 for now, especially since it worked great for me and did not cause any complications. I use two stations operating in two different modes t12 and c245, they work great on your firmware and neither I don’t want to change any other one. I’ll wait for new versions of your firmware!
-
I can't fix anything if I don't know what's wrong.
New firmware versions won't get magically fixed unless people test it and report the issues.
So try 1.11.5b, post a picture if still getting errors, also try button factory reset and/or fully erase the stm32 with ST-Link.
Also, make sure there are no protected flash pages.
-
Okay, but I'll try your advice only tomorrow, although I previously installed the firmware with default settings. Regarding your firmware, it is the best available and from the release of a new version I do not expect a magical cure for all diseases, I understand perfectly well that it is very difficult to improve an already perfectly working product, unless you add bluetooth, wifi and the possibility of satellite communication with Alpha- Centauri. Please excuse me if the joke may seem rude to you!
-
David, version 1.11.5b is working!
-
Nice! Did you do anything special? The changes I made were minimal (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/58c176a4c88ab91341ec0e5bf3c5e6a6d4efe281) and I don't think they made any difference about the hardfault.
Did you check if you have a genuine STM32 after all?
Custom boards might be flawed, causing all kind of weird issues. Ensure 3.3V (VDD) is stable and have at least 10uF at the regulator output (This will depend on the regulator, check the datasheet) + several 100nF cap at every VDD/VDDA pin. .
A good design must have some extra filtering for VDDA, the current is very low so it can be easily done with VDD->10-22 Ohms->10uF cap->VDDA, or a 1K @100MHZ ferrite bead instead of the resistor.
(https://xilinx.file.force.com/servlet/servlet.ImageServer?id=0152E000003pEYdQAM&oid=00D2E000000nHq7)
(https://i.stack.imgur.com/WztJI.png)
-
The voltage is 3.3 volts stable, I’ll look into everything about the board, although before this everything worked stably.
-
Well, it took quite a lot of time (It's always the small things causing havoc :)), but finally the the new flash storing method used in the temperature was extended to also the tips and profile.
It will wipe the flash page every 512 temperature and/or every 128 tip/profile changes, greatly reducing the stress on the flash.
I tested it pretty extensively, I hope it's not bugged!
Release v1.11.6.
Edit:
Ouch! I'm forgetting how everything works...
- Small fixes here and there...
- The new way of storing settings caused the initial setup screen to never be shown. Fixed.
- Add Cold Boost function. Option added in SYSTEM options.
A primitive booster, enabled when entering Run mode, if the tip is 100ºC colder than target, it will automatically boost +50ºC for 12 seconds.
It seems to work pretty well, the real tip temperature doesn't get that high, but heats up noticeably faster.
This is intended for cheap T12 tips, genuine ones will heat up much faster and don't need this
Release v1.11.7 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.7).
-
Thanks for another release, will try it soon.
BTW, is it intentional that in stand mode System->Boot option disappears?
I've just commented out line 29 in https://github.com/elektryk2/stm32_soldering_iron_controller/blob/master/Drivers/graphics/gui/screens/system_screen.c and it seems to work but please note that I'm not using the newest version. In the new version it works the same.
And also what should be the behavior when the handle is out of the stand during booting and Boot->STBY is set?
-
Of course it is.
Why would you want a boot mode when using stand mode?
It's the stand what sets run mode, remove the handle and it activates, put it in and goes to sleep.
Maybe it could be allowed to boot in standby so it warms up but I don't think it's worth it.
The station boots in sleep or run depending on the stand status, enabling boot mode widget won't make any change, as this option is ignored elsewhere.
Check this (https://github.com/elektryk2/stm32_soldering_iron_controller/blob/master/Core/Src/iron.c#L104#L114).
-
It turns out that for some reason this setCurrentMode() call overwrited the previous one that you had highlited https://github.com/elektryk2/stm32_soldering_iron_controller/blob/master/Core/Src/iron.c#L707
After some investigation I've seen that before first call of checkIronError() last_NTC_C value was -999 because readColdJunctionSensorTemp_x10() was called to late and that tripped Err.Flags.
I've solved it crude way by adding firstRun flag https://github.com/elektryk2/stm32_soldering_iron_controller/blob/master/Core/Src/iron.c#L665
If I don't miss something, it should explain why this hidden option took an effect in my case, after adding mentioned flag it should be useless IMHO.
-
That behavior is completely intentional, triggering an error at the start, so CheckIronError loads the boot profile later on when everything settled down.
Any error is supposed to clear up during the initial splash screen (1 second), thus the original code assumed this.
But it will set Error Resume mode if cleared later.
Anyways, let's assume it took only slightly longer than the boot screen, this should fix it (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Src/iron.c#L675-L730).
Extended the time to 3 seconds since boot start, if the error doesn't clear in time then the resume mode will be used.
I hope this is not caused by your own changes, breaking my head for no reason... :P
-
I hope this is not caused by your own changes, breaking my head for no reason... :P
I really hope not to waste your time.
Just compiled latest release (only board dependent files were mine for different pinout and ADC channels) and it still goes there.
My "testing scenario" is:
-set boot mode to sleep
-set wake mode to stand
-set stand mode to stby
-set resume to last (this is the default option)
-do off/on
And the result is:
-station in sleep mode
I would be very grateful if someone could repeat this and share the result.
BTW Is my mentioned approach really bad? Because it seems to work for me.
https://github.com/elektryk2/stm32_soldering_iron_controller/blob/master/Core/Src/iron.c#L665
-
Switched from V1.11.5 to V1.11.8. Got this... While I rolled back to V1.11.5.....
-
I have 2 ksger stations from several years ago and I want to try the custom firmware, which is the best chip to buy? I have the 48-pin stm32f103cbue installed in one, and in the other I have a 64-pin stm32f103rbt6. A friend has another one with a 64-pin chip but this one comes with the stm32f103r8t6, which chip should I choose for the tests? Are the differences between them not important? or does the firmware differentiate between them and adjust automatically?
-
I have 2 ksger stations from several years ago and I want to try the custom firmware, which is the best chip to buy? I have the 48-pin stm32f103cbue installed in one, and in the other I have a 64-pin stm32f103rbt6. A friend has another one with a 64-pin chip but this one comes with the stm32f103r8t6, which chip should I choose for the tests? Are the differences between them not important? or does the firmware differentiate between them and adjust automatically?
STM32F103C8T6 , STM32F103CBT6 or CKS32F103C8T6 , CKS32F103CBT6
-
Read the Readme!
It's perfectly explained, any will work, 48 or 64 pin, C8,CB,R8, RB...
-
Hi david. This is my hardfault in FW v1.11.8. PC code: 08003468. It's a commercial version so you can ignore hardware errors because I did it myself. there is an LCD version I made myself that also has the above error. And let me ask, in the schematic folder there are many different schematics, which schematic is most suitable for the KSGER_v3_OLED and Quicko_STM32F103_OLED FW versions. thanks
-
People always forget to provide proper details:
- FW version 1.11.18, but which type? V2? V3? Quicko Fxx?
- How to replicate the problem? (What to do to cause this)
Which schematic is most suitable for the KSGER_v3_OLED and Quicko_STM32F103_OLED FW versions.
All V3 are very similar. You will have to check them out in DreamCat repo (https://github.com/dreamcat4/t12-t245-controllers-docs/tree/master/controllers/stm32-t12-oled).
Quicko F103 / F072 is *only* for Quicko F103/F072, is a unique controller sold few years ago, available here (https://github.com/deividAlfa/stm32_soldering_iron_controller/tree/master/BOARDS/Quicko/Schematic).
-
I flashed my station with KSGER_v2_OLED_1.11.8 firmware downloaded from here https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.8
The error appears immediately when the station is turned on...
-
Sorry david. which is version v1.11.8 KSGER_v3_OLED
-
Aha. Well, I found out that I'm bad at maths. 128 - 4 - 6 =124 :). Just joking, but this was a real bug.
Fixed the linker scripts, but I don't think this was the issue, as the firmare didn't reach that area.
I made a TON of changes between yesterday and today, seeking simplicity and tidiness.
Edit: This (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/fc2892aa209ada63bc28e54c138f83c4ab0a110f) was probably the cause (Accessing undefined address).
Please try v1.11.10 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.11.10).
There were so many changes recently that I got a bit overloaded, thus the bugs, but it's getting it back under control now.
If any left, should be pretty quick and easy to fix them.
-
I literally spent an entire day rebuilding the firmware with massive changes (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/235ece68e32ce1296ddc734a6ac608bcac252679).
There's much more control the settings handling, and the ram usage was greatly reduced, opening a lot of options for the future.
v1.12.0 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.12.0) is out, check the release notes.
-
I flashed from 1.11.5 to 1.11.10 after completely erasing the chip. Simply programming without erasing gave an error when turning on the station.
The profile does not save on 1.11.10. Every time you turn it on, the T12 profile is loaded....
-
I literally spent an entire day rebuilding the firmware with massive changes (https://github.com/deividAlfa/stm32_soldering_iron_controller/commit/235ece68e32ce1296ddc734a6ac608bcac252679).
There's much more control the settings handling, and the ram usage was greatly reduced, opening a lot of options for the future.
v1.12.0 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.12.0) is out, check the release notes.
Now I'll flash 1.12.0 :). And I will test it!
-
I updated it to 1.12.0. My profile is not saved when the station is turned off... Attached video.
https://youtu.be/G2tdXowkQ5o
Added:
The editor of stings only works with the first one in the list.... I choose to edit 4 in the list and the first one is edited... :-//
But I think all this will be resolved :). I would like to wish everyone a Happy New Year 2024! :)
-
I have the same problem, I had to roll back to the previous version
-
Thanks for testing, I found the issue, I'm working on it.
This issue is not critical, so instead rolling back, please try other features and report if you find any other issues.
Don't worry, settings won't be erased in the next version, this is just a initialization issue, so you can set up the tips and settings like normal.
(At least the Hardfault is gone!)
-
Everything should be fixed by now :): v1.12.1 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.12.1).
Uhh... I need to sleep, I literally spent the entire night hunting the issues :-DD
(And they want me taking beers in 4 hours LOL)
This firmware got pretty complex, about 14K lines of code!
Lots of things are placed in a critical order, and everything depends on everything, it's like playing Jenga.
So it's not easy to optimize or make heavy changes... Well, it's done now!
-
David, there is a problem when editing already created tips of stings. Even if I want to edit 3 on the list, I still end up on the first one.
Version 1.12.1Beta
-
Everything should be fixed by now :): v1.12.1 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.12.1).
Uhh... I need to sleep, I literally spent the entire night hunting the issues :-DD
(And they want me taking beers in 4 hours LOL)
This firmware got pretty complex, about 14K lines of code!
Lots of things are placed in a critical order, and everything depends on everything, it's like playing Jenga.
So it's not easy to optimize or make heavy changes... Well, it's done now!
After power up KSGER 2 firmware 1.12.1:
-
Try to completely erase the chip before flashing it. You’ll just lose all your profile settings!
-
Triple full flash erase and program and verify same result.
Roll back to 1.10.8 everything is fine.
Proposal to David to form three branches of the firmware: long-term, stable and beta or current.
-
Triple full flash erase and program and verify same result.
Then only David will help! I sewed KSGER_v2_OLED_V1.12.1Beta it up fine.
-
Nah don't insist on erasing! No matter how the flash is, it should never fail.
At least that error type is a much easier to trace.
I only have a quicko F103, nothing else, so make me a favour and report properly!
"Show this" is not a description, you're not helping me at all unless you say how to replicate the problem.
Does that error come instantly after flashing? Or after the setup screen?
Make sure you have no protected flash sectors, this is explained in the Github Readme / Programming.
EDIT:
OK! After trying myself several times, it seems to happen after initial system screen (But it shows up), crashing on next reboot?
I spotted the issue, damn, should be the last one!
-
Nah don't insist on erasing! No matter how the flash is, it should never fail.
At least that error type is a much easier to trace.
I only have a quicko F103, nothing else, so make me a favour and report properly!
"Show this" is not a description, you're not helping me at all unless you say how to replicate the problem.
Does that error come instantly after flashing? Or after the setup screen?
Make sure you have no protected flash sectors, this is explained in the Github Readme / Programming.
After first power up after flash , before setup screen , no protected flash sectors.
Roll back to 1.10.8 everything is fine.
-
I don't know why my station behaves so well, makes my life extremely hard |O.
Please try v1.12.2 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.12.2).
-
I installed all versions and had no problems. C245,T15,T12 KSGER_v3_OLED.
-
There's something quite interesting. when I flash KSGER_v3_oled v1.12.1 the hardfault error still appears, and that error appears after the setup screen. when I flash v.1.12.0 and v1.12.2(erase chip) it works normally. but when I flashed v1.12.1 again (without erasing the chip), the hardfault error no longer appeared. Once again, I flashed v.1.12.1 (erasing the chip), but the hardfault error appeared again :D. With the LCD version in KSGER_v3_LCD v1.12.1, I got the same error as the post above, "Line 964 settings.c", and when I restored it to default, it worked normally again. While using the KSGER_v3_LCD version, a hardfault error suddenly appeared. I don't remember which version. I'm just reporting the errors I encountered in both the oled and lcd versions, I hope David doesn't feel upset about it.
-
I installed all versions and had no problems. C245,T15,T12 KSGER_v3_OLED.
Which schematic did you use in the schematic folder? Can you upload them here?
-
I don't get upset by the error reports, it's very useful! :-+
What it does are the reports like "Not working"!
I need to know which controller, which fw version and how to recreate the problem.
Anyways, thanks to the display.c error I was able to trace the issue, I think it should work now in 1.12.2.
-
My schematic for the t12 chontroller.
-
My schematic for the t12 chontroller.
Thank you. Looking at the diagram, I see that there is a 3.3v power supply circuit for the separate MCU and 3.3v for the separate screen. There are additional inductors and filter capacitors to ensure a clean 3.3v voltage for the MCU to operate most stably, very different from the version I am using which has a voltage regulator circuit from 24v to 3.3v for all (mcu, oled, lcd, opamp...). I think it's not really stable yet.
-
Lots of things are placed in a critical order, and everything depends on everything, it's like playing Jenga.
Yeah, I've got a very funny time while merging and modding.
My previous FW for T12 fitted ATmega8 but it wasn't even half as functional.
-
Stop talking, try 1.12.2 and tell me! :-DD
-
With 1.11.7 my board booted ok but with actual release MCU (103CB without battery) is resetting somewhere near showed breakpoints.
After full chip erase it can boot to the first boot screen, I can then click save and after another power cycle only black screen is presented.
EDIT:
Forget debug4.jpg screenshot, debug5.jpg shows actual reason of rebooting.
-
Hmm, strange, would you allow me to debug it remotely?
It's really pissing me off, how in earth is it working for some and not for others?
The flash is the same!
Unless... Some are having different flash sector size... And thus erasing too much?
Otherwise it makes no sense.
Please make sure it's a genuine stm32
I swear I can't make it fail on mine :palm:
Also why Eclipse?
CubeIDE shows a lot more info when debugging, like the last function calls leading to the current position, so you know who called savesettings, why was reboot bit set, and so on.
The reboot bit is set when some data check at boot is bad, performing a scan and setting the defaults in the bad area.
For some reason your's is stuck in a loop, finding bad data everytime it boots.
Must be something really little and stupid!
Also, have you tried button factory reset? (This should never be required, but just as a test)
-
Must be something really little and stupid!
Now it boots ok, just see:
settings.c line 562
#ifdef ENABLE_ADDONS
//reset |= loadAddonSettings(); //SUCCESS = 1 so it rebooted then
if(loadAddonSettings()!=SUCCESS)
reset|=reset_Addons;
#endif
Another thing, when I edited one of the 3 tips the values changed in each of them, also the save button is present only in the last one added, even though it is not the last one alphabetically.
-
- Please report the result of the test below, also specify whether your controller is working with the new firmware.
- If not working, please specify if you're using any clone (Even CKS).
- If not working and apparently not a clone, please run clone detection (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#clone-detection).
Please don't fill the forum with pictures, just do like:
CPUID: 411FC231 -> Some clones are copying this too! 412xxxxx would be a fake (Different ARM core revision)
SIZE: 128 KB -> If this shows 65535, it's 100% fake!
PAGE: 1024 Bytes
Clone test: 20036410 -> Some clones are copying this ID too!
Yesterday I spent a lot of time creating/changing/copying/deleting tips, switching profiles, everything worked flawlessly here.
What you're doing will cause unexpected behavior, letting the system run with bad settings, then anything can happen then.
This all started after the new temperature storage area was added.
I suspect there's some issue in the flash erasing, perhabs some STM32 are not 64/128K, but 256K or larger, so the sector size will be 2K instead 1k.
This code assumes all STM32s have 64/128KB (1KB sectors), so in larger devices it will erase twice the memory, destroying other areas and possibly causing the system bootloop you got while debugging.
(Bad data->Load defaults->Reboot, Bad data->Load defaults->Reboot...).
This would never be a problem before because the whole settings block was written in a single step.
But now we have sepparated writing areas, so one might be erasing the other!
I made a very simple test to show the reported flash size from the FLASH register.
Whatever the version you're running, this test won't touch the stored settings, so just flash it, show the result, flash the working version back and keep working (Keeping your settings) :-+
-
What you're doing will cause unexpected behavior, letting the system run with bad settings, then anything can happen then.
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Core/Src/settings.c#L562-L581
Well, so even if loadAddonSettings() return SUCCESS (value 1) it should do saveSettings(perform_scanFix, do_reboot)?
-
Answering yoru PM - How to debug non-genuine devices in cubeIDE:
- You must set the debugger settings to ST-Link (OpenOCD), or J-LINK with you have it.
It will never work with ST-LINK GDB server as it performs its own checks.
- In older versions (I think <1.12) you could modify OpenOCD cfg files (https://www.eevblog.com/forum/microcontrollers/stm32f103t8u6-not-recognized-by-cubeide-as-genuine/msg4140457/#msg4140457) to bypass the genuine check.
- Recent CubeIDE versions added internal checks... but I was able bypass it (https://www.eevblog.com/forum/microcontrollers/$0-25-hk32f030m-(cortex-m0-32mhz-16kb-2kb)/msg4622494/#msg4622494) anyways (https://i.somethingawful.com/forumsystem/emoticons/emot-pervert.gif).
- You don't need to get your hand dirty, I have already made patches for 1.12.1 and 1.13.0 here (https://drive.google.com/drive/u/1/folders/1dZiZ2QO3rrZFRXDRg_KmQT4Wj1I72i2I).
-
Well, so even if loadAddonSettings() return SUCCESS (value 1) it should do saveSettings(perform_scanFix, do_reboot)?
SUCCESS=0
typedef enum
{
SUCCESS = 0U,
ERROR = !SUCCESS
} ErrorStatus;
What the init does (Simplified) is basically this. Load everything, store any reset flags and reset if necessary.
if( bad system settings )
reset |= reset_Settings;
reset |= loadAddonSettings(); // This return SUCCESS if ok, or reset_Profile
reset |= loadAddonSettings(); // This return SUCCESS if ok, or reset_Addons
if(reset)
saveSettings(perform_scanFix, do_reboot); //Fix whatever is bad there, loading defaults in the bad area
What I think it's the problem is flashTempSettingsInit(), which will delete its own area, just before the settings block.
If what I said in the upper post is true, it will erase also the settings, r maybe the settings also the temp. block, in a vicious circle.
Sorry, I'm not trying to be a jerk or anything, but I don't want to do twice the job, Developing the firmware + Explaining someone how everything works!
Specially when you're not properly checking things (Where did you get SUCCESS==1?)
Are you letting me debug it out or not? Would make things so much easier for me.
Otherwise I'm running out of patience, I won't keep debugging blindly, with no real hardware in my hands - It's tiresome, slow and time-consuming!
-
Thanks for your workaround.
What a joke, the open declaration option brought me here.
CMSIS/device/stm32f1xx.h in AC6
typedef enum
{
ERROR = 0,
SUCCESS = !ERROR
} ErrorStatus;
BTW If you look at my added if(loadAddonSettings()!=SUCCESS) statement you should notice that in case of error the reset will occur which was desirable.
EDIT:
The same in cube
typedef enum
{
SUCCESS = 0U,
ERROR = !SUCCESS
} ErrorStatus;
-
...
ERROR = 0,
...
SUCCESS = 0U,
...
The same in cube
Nope, they're completely opposed? How is ERROR=0 in AC6 when it's the same ST libaries?
Try this:
Set battery enabled by default:
const settings_t defaultSystemSettings = {
...
.hasBattery = false,
...
}
Empty this functions as follows:
void flashTempSettingsInit(void){
}
void flashTempWrite(void){
}
void flashProfileWrite(void){
}
void flashTipWrite(void){
}
void flashTempSettingsErase(void){
}
If you don't have a battery, this will cause a Low Battery message on every boot, also forget your last Profile / Temperature / Tip.
But everything else should work fine.
This will completely avoid touching the "Remember Last" flash block, and confirm or discard the said flash problem.
Completely erase the flash using the button factory reset or with the programmer to make hasBattery = true.
-
David, version 1.12.2 Oled 2. Launches and works without failures.
There are two points:
1. Please watch the video https://youtu.be/W2NE7IHkq3Y - in the tip editor I can only select the active tip for editing.
2. Please correct the information about the firmware version.
-
Nope, they're completely opposed? How is ERROR=0 in AC6 when it's the same ST libaries?
Yeah these enums are opposite, they've made a real joke on me.
-
In the tip editor I can only select the active tip for editing.
Please correct the information about the firmware version.
Bad version number - Yeah happens when making 25 builds in a day!
Tip editing - Ah, indeed! Happens if doing it from the tip list menu - FIXED (http://a8d1d0fc790cd297bdf0609c195169a8158d3c49).
Use this for now until next build is out (This is what I was using all the time):
1 - Highlight the tip in the main screen.
2 - Long-click to enter tip editor.
Also, based on your video, remember you can return to the main screen any time by long-clicking (While not editing any field).
In the tip editor this will discard any changes, but you can do it inmediately after clicking on SAVE/CANCEL/BACK, removing the need of navigating to BACK / EXIT in each screen.
In fact I was thinking in completely removing that screen, adding a NEW option below COPY.
- COPY->copies the current name to the new tip.
- NEW->clears the name.
-
In the tip editor I can only select the active tip for editing.
Please correct the information about the firmware version.
Bad bersion number - Yeah happens when makign 25 builds in a day!
:-+
Here's my test... (Attachment Link)
-
I think the people having those issues have a 64-pin STM32, but not R8 or RB... maybe RC, RD, RE? (Or relabeled by some chinese factory)
This will cause all these issues!
So, as I'm pretty sure the problem is coming from the flash page size being different, I made some changes to automatically detect and handle this, also few other fixes and enhancements.
Please try v1.12.3 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.12.3).
And if something is not working, remember I'm not a fortune teller, so please explain properly the issue and how to cause it.
-
Thanks David, версия 1.12.3 Oled2. Everything works for me! I'll test it.
-
So only one person ran the flash test and tested the new FW version, reporting the results... :-//
-
Everything as functionalities works.
Two cosmetic bugs remain. The motion sensor icon slightly pushes the tip name when the last letter is in bulk, for example O, R or P (TIP name DESOLDER) . The SW and HW version information is not aligned equally.
David, now can the number of soldering tips be raised to 50 without becoming a problem?
-
Do you really have 50 tips? They won't fit right now, but I have some ideas for the future.
(Not the current priority)
What I really need to know if it works now on controllers that failed before.
Hmm I tested what you say when designing it, filling the tip name with ”F" looked fine, maybe those letters are a bit larger.
-
For me, the problem with the Line 964 settings.c error disappeared even with version 1.12.2, the MCU with the error was STM32F103CBT6 [CPU ID (DBGMCU_ID) = 20036410], there are no problems with Handskit with MCU CKS32F103CBT6.
-
Of course, I have fewer stings in use - 11, I immediately add them to the list of station stings (in the photo there are those in the holder and two on the stations). Now I’m using firmware version 1.12.3 - everything works fine, there is no hard vault screen, which popped up for me on the 11th series of firmware (in some versions 1.11.*), purely subjectively, the response of the station when exiting sleep mode improved very much, calibration data is entered on all the tips that I use (in some versions 1.11.* the hard vault screen and the station popped up reset to factory settings (for me this was not particularly critical, so I did not inform you). There is not enough backup of the station settings, but I understand perfectly well that this is probably impossible to implement. I continue testing the firmware, if problems arise, I will inform you.
-
I saw a difference in the EDIT TIPS menu, then i selected TIPS T12-BC3, i saw that the value in Cal 250 was not the same as the value in CALIBRATION => SETTINGS.
for example, i calibrate manually, via the CALIBRATION menu => SETTINGS, then i change the value in Cal250 -> 1800, then save it. the result of this calibration change should be = the Cal250 value in TIPS, then what is the purpose of doing calibration and saving the calibration results if in the end EDIT TIPS menu displays the default numbers "1900" instead of the values resulting from the calibration that has been saved?
-
No. The value in settings is for the automated calibration procedure, so it doesn't drift too much.
Read the manual! (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md#calibration)
Also, you're all ignoring me completely, I've said several times that the priority now is to know if the problems with certain controllers (flash error, hard fault, black screen) is gone, also that I needed reports of the flash size check program posted few messages back...
So far it's been like talking to rocks, if it keeps like this I will drop the development, enjoy the same zero effort back... :-//.
-
No. The value in settings is for the automated calibration procedure, so it doesn't drift too much.
Read the manual! (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md#calibration)
Also, you're all ignoring me completely, I've said several times that the priority now is to know if the problems with certain controllers (flash error, hard fault, black screen) is gone, also that I needed reports of the flash size check program posted few messages back...
So far it's been like talking to rocks, if it keeps like this I will drop the development, enjoy the same zero effort back... :-//.
People! Let's be more active! :scared: David is doing a great job! And absolutely free! IT'S NOT DIFFICULT to download and test the firmware for a few hours....
-
People! Let's be more active! :scared: David is doing a great job! And absolutely free! IT'S NOT DIFFICULT to download and test the firmware for a few hours....
yes I'm testing it, I just opened github today there's a big update, I'm going to test some functions so I can report if I encounter errors.
-
It's simple!
1 - Fix these problems making some controllers useless.
2 - Once working, focus on the little things and features.
-
I have tested v1.11.2 and v1.12.3 + the test BIN on two different controllers:
KSGER v2:
Size: 128
Page: 1
STM32F103CBT6, came with the board, unsure about if it's genuine or not.
v1.12.3 seems to work on this controller.
KSGER v3:
Size: 65535
Page: 2
Clone test: 20036410
STM32F103RBT6, came with the board, unsure about if it's genuine or not.
v1.12.3 gives "Flash error"
v1.11.2 seems to work on this controller.
EDIT:
Found another KSGER v3 board:
Size: 64
Page: 1
Clone test: 20036410
STM32F103R8T6, IIRC, this one is from Digikey.
v1.12.3 seems to work on this controller.
-
Thanks AndyC, that's exactly what I wanted.
That flash size report is definitely weird, I'll need some additional testing in that controller.
-
BOARD: KSGER GX V2.1S
MCU: STM32F103C8T6
Size: 64
Page: 1
BOARD: Quicko F103 (DXCHEMI T12)
MCU: CKS32F103CBT6
Size: 128
Page: 1
No Hard Fault with 18b4558 git version. (Customed Build)
-
What I really need is the flash test result for those controllers that failed completely before, or failing now in 1.12.3 like AndryC's.
If working in any version, like mine (Genuine stm32), that's the expected, no need to report anything.
Definitely there's some flash memory issue going on.
-
OK, so next try will be to assume all controllers have 1KB sectors *unless* they report 256K - 1M flash size (Assume it's genuine, follow datasheet values).
Anyone having a hard fault / black screen / checksum error bootloop in older releases, please try this new version and report if working now.
AndyC your clone/fake should be working now?
Release v1.12.4-beta (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.12.4-beta).
Once working, I'll proceed with further enhancements.
My next target is to isolate each profile tips in its own 2KB block, this will raise each profile tip limit to ~80 (Probably going to limit this to something lower like 50?), while reducing the storing function heap usage by 50%, as it'll only need to backup the block being modified.
The tip block will be isolated from the profile and system settings, so if these change and the system is restored to defaults, the tips should always remain, the tip structure has not changed for 2 years at least.
Also a write-protect bit to prevent tips from being wiped when performing a factory reset, or even setting the Options bits to protect the flash areas in hardware, not even the programmer should be able to erase these areas accidentally.
(But still could if going to Option bits and manually resetting the protected pages)
But this won't make any sense unless the flash issue is completely fixed.
-
AndyC your clone/fake should be working now?
Yes, at least the basic stuff worked in the short time I had for testing the previously non-working KSGER v3.
Saving settings, adding/editing tips, calibration etc seemed to work without getting "flash error".
Will do some more testing later.
Many thanks!
-
Is this the regulator?
(Attachment Link)
When I find the time I'll try to figure out how hot it gets.
In my personal opinion, replace that LM7805 / 78M05 as soon as possible . It does get hot, i mean pretty damnn hot.
I got burned one of the chinese / custom board ( 2in screen using nuvoton NUC029LAN) with the cheap 78M05 . And now the MCU is dead, i resolder the MCU and replace the 78M05, no more shorted. But i dont have the firmware or the chip. I am still tickering myseft should i order the chip, it's not that expensive 50 cents each.
Also the voltage LDO for droping to 3.3V, it's just a complete mess / dissaster
Basically, the desgin just drop 24V -> to 5V , and then from 5V -> to 3.3V
-
v1.13.0-beta (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.0-beta)
-
v1.13.0-beta (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.0-beta)
Everything as functionalities works.
-
Hi David! Once again the hardfault error appears, PC Code:08004D9C in version KSGER_v3_OLED v1.13.0-beta. It appears after the new setup screen. then I turned the power off and turned it back on and a message appeared "BAD CHECKSUM! RESTORING THE TIPS"
-
99.99% it's caused because it's not a genuine stm32, so until I find a way to detect them, and someone with a problematic controller helps by trying my tests, they will remain bugged.
You didn't run the flash test I posted earlier when I asked to, nor anything else, so what did you expect?
I'll come back in a week and see if it magically fixed itself?
Buy a genuine stm32 and replace it.
-
So sorry! Because I haven't been on the forum for a long time, I don't know your request, so I'll just report the error I encountered.
Check genuine chip here? https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#clone-detection
- KSGER oled v3:
Size: 128
STM32F103CBT6,
came with the board
Clone test: 20036410
v1.12.1: "hardfault" error
v1.12.2: works fine
v1.12.3: works fine
v1.12.4: works fine
v1.13.0: "hardfault" error
-
Thanks. Understand this is not my job, nor I have 50 controllers to try. If you come 2 weeks after, I will have forgotten most, so I have to start again.
I tried the KSGER V3 build in my stm32cb103 and works just fine, so I keep suspecting there's something wrong with that stm32.
New build: v1.13.1-beta (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.1-beta).
Now a hard fault will show additional info about the last saving states, which might shed some light about the issue.
Post a picture of the hard fault screen, not only the PC address.
No solution will ever happen unless people is willing to help!.
-
#1 - KSGER v3 OLED:
STM32F103RCT6, came with the board.
Size: 65535
Page: 2
v1.13.0-beta runs ok.
-----
#2 - KSGER v3 OLED:
STM32F102R8T6, came with the board.
Size: 65535
Page: 2
v1.13.0-beta runs ok.
-----
#3 - KSGER v3 OLED:
STM32F103RET6, repaired/replaced.
Size: 512
Page: 2
v1.13.0-beta runs ok.
-----
----------
The only things I noticed using C245:
- version number displays 1.12.0
- with Temp:320C, boost_increase :30C, cold_boost:on
a) when boosting from temperature adjusting screen, boost goes to 350C.
b) when boosting from COLD sleep, boost goes to 370C and should it be 350C.
-
Hmm clearly clone/fake stm32s. At least they work!
No way it showed 1.12.0? I downloaded the release binaries and they have "1.13.0" string inside...?
Fixed the cold boost! (Will be fixed in v1.13.1-beta, reuploading the release).
-
You are right about the version number, somehow I had flashed and tested v1.12.2 (Beta), sorry about that.
I'll test the new v1.13.1-beta now.
-
Updated the flash test (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg5253981/#msg5253981) to follow the actual detection method of the firmware.
BTW I checked the traffic statisics, less than 5% of Github visitors check the Operation manual... ::)
-
Sorry David! I just got home from work and read your article carefully. Flash test results FLASH_TEST_KSGER_v3_OLED.zip:
STM32F103CBT6,
came with the board
CPUID: 411FC231
SIZE: 128 KB
PAGE : 1024 Bytes
Clone test: 20036410
v1.12.1: "hardfault" error
v1.12.2: works fine
v1.12.3: works fine
v1.12.4: works fine
v1.13.0: "hardfault" error
and hardfault screen KSGER_v3_OLED v1.13.1-beta:
-
KSGER_v2_OLED
stm32f103cbu6
came with the board
CPUID: 411FC231
SIZE: 65535 KB
PAGE : 1024 Bytes
Clone test: 20036410
v1.13.1: works fine
-
David, firmware KSGER.OLED2 V1.13.1 beta. The profile of the stings and the set temperature are not saved when turned off....
https://youtu.be/6U2d_EGw3Tk
-
Battery enabled?
If not, are you waiting at least 3 seconds after changing? Otherwise it won't be saved.
-
Battery ON.Everything was saved on the previous firmware 1.12.3...
-
Ok. Try battery off, just to test if it works.
-
Ok. Try battery off, just to test if it works.
David, I disabled the battery in the menu - "BATTERY OFF" - the settings are saved.
The voltage on the battery is 3.2 - It is new :-//....
On 1.12.3 - Settings were saved when the battery was on :-//.
-
No worries, such bugs can easily happen after reworking the settings again.
If it was the battery, you would get a warning message at boot (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/c0741e2cf1fa73482a16568ab41e67ee937502d5/Core/Src/settings.c#L698-L701).
I have to work, sleep, eat,... trying the entire firmware for every release is just impossible :).
Fixed in v1.13.2-beta (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.2-beta).
-
Geehy APM32F103RBT6 clone, debugging doesn't work
CPUID: 412fc231
SIZE: 128 KB
PAGE : 1024 Bytes
Clone test: 20036410
1.13.2 beta
The selection of tips after switching off occurs correctly
-
Of course David, I understand. You are a living person and this job is not your income! You make cool firmware! Thanks for corrections. :-+
I updated it to 1.13.2. Everything is fine! Settings are now saved when the battery is on! :-+
-
David, I had a small problem - when installing firmware 1.13.2 on one station the firmware installed normally, but on the second the hard vault screen popped up. Previously, I had 1.13.0 on both. The one that works in t12 mode, the firmware installed normally, but the one that works in c245 mode, the firmware caused an error, I had to roll back to 1.13.0. Both stations, although custom, are assembled from the same parts, the only difference is in the operating mode. Although I am still inclined to believe that the problem is in the hardware, although strangely, on the second station the new version was installed and works without problems.
-
Do you know all the information shown in the hard fault screen is for something, not just made to look fancy? It's the only hint I have to track a fault.
How many times do I need to repeat it...? :P
Anyone having an error screen, post:
- Firmware version and type (Ksger V2, etc).
- The error message, or a screen picture if it's hard fault.
- The result of flash test (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg5253981/#msg5253981) attached in few post back in Page 154.
It's strange because the differences between the different 1.13.x versions are minimal.
Can't tell until I see the hard fault screen.
-
#1 - KSGER v3 OLED:
STM32F103RCT6, came with the board.
CPUID: 411FC231
Size: 65535
Page: 1024
v1.13.2-beta works well, tested with C245.
I noticed that ST-LINK/Cube shows 2K page and 512K flash for this unit.
[attach=2] [attach=1]
: Device ID:0x414
: Device family :STM32F10xx High-density
-----
#2 - KSGER v3 OLED:
STM32F102R8T6, came with the board.
CPUID: 411FC231
Size: 65535
Page: 1024
v1.13.2-beta works well, tested with C245.
ST-LINK/Cube shows 1K page and 128K flash for this unit.
: Device ID:0x410
: Device family :STM32F10xx Medium-density
-----
#3 - KSGER v3 OLED:
STM32F103RET6, repaired/replaced.
CPUID: 411FC231
Size: 512
Page: 2048
v1.13.2-beta works well, tested with C245.
ST-LINK/Cube shows 2K page and 512K flash for this unit.
: Device ID:0x414
: Device flash Size : 512KBytes
: Device family :STM32F10xx High-density
-----
Cold boost is ok.
Thank you!
-
MCUs reporting 65535 are 100% fakes.
If the flash was really 2K the firmware would not work, causing hardfault or settings error bottloop.
-
Hi daivd.
STM32F103CBT6
CPUID: 411FC231
SIZE: 128 KB
PAGE : 1024 Bytes
Clone test: 20036410
Green board Version KSGER_v3_OLED v1.13.2 has a hardfault error.
Black board Version KSGER_v3_OLED v1.13.2 works stably.
Both MCUs have the same parameters for flash test and clone test.
But the engraved shape on the MCU seems a bit different.
Looks like this error is related to the MCU, right David?
-
Yes, it seems a problem with the way that stm32 clone works, it's crashing when resetting the tips to default.
We could try forcing the page size to 2KB and see what happens.
Read the failing stm32 and post the .bin file, it's strange that it's crashing at FLASH_WaitForLastOperation.
I wonder if that clone has a much larger page size and it's erasing part of the firmware.
-
Dear David, I am using your v1.13.3 firmware for the KSGER V.2 and V.3 controllers. There were no errors after applying the firmware. I have a question, maybe I should have asked it earlier. As before, there is a Def temp item in Iron menu. If you turn on the controller for the first time after flashing, the soldering iron heats up to this temperature. If you change the temperature later, it will be saved for the next turn on. Perhaps this menu item is no longer needed?
-
Yes, I also thought the other day, will eventually be deleted :-+
-
Hello and best regards from germany. I want to buy me a new t12 soldering station. I am searching since 2 days. I have now some questions. As i understand github, it not possible to flash this station
https://de.aliexpress.com/item/1005003713432532.html?spm=a2g0o.store_pc_allItems_or_groupList.0.0.5dc76006i9TsPH&pdp_npi=4%40dis%21EUR%21%E2%82%AC%2080%2C67%21%E2%82%AC%2056%2C47%21%21%2185.87%2160.11%21%40211b801a17056089182407380e3c06%2112000026905474129%21sh%21DE%212186267501%21&gatewayAdapt=glo2deu
I also found this one. This is a set with tweezers. Ist this also for custom firmware? Can i also use with this solderin handles from ksger or quicko?
https://de.aliexpress.com/item/1005006371386045.html?spm=a2g0o.detail.0.0.7b4cSrGmSrGmCk&algo_pvid=3df2dfc1-844e-4f48-ba88-9e4c55948f75&algo_exp_id=3df2dfc1-844e-4f48-ba88-9e4c55948f75-3&pdp_npi=4%40dis%21EUR%21183.30%2164.15%21%21%21195.10%21%21%40211b617a17056099307331138e51f4%2112000036932452392%21sea%21DE%212186267501%21&curPageLogUid=bZonqKEDf78U
BR Sebastian
-
No, uses different screen and mcu.
-
Also not the sescond one with the tweezers?
-
Sorry, missed that one. I have no idea what's inside that station.
You might ask the seller for internal pictures?
-
By coincidence I was reading another thread on the EEVblog forum yesterday and searched on AliExpress for those tweezers. I am not sure if all that is stated in this listing is true, but a seller of an identically looking soldering station (also with Handskit branding) describes the model as version 2.1 and mentions the chip as an stm32 in the specification table:
https://www.aliexpress.com/item/1005005027433673.html (https://www.aliexpress.com/item/1005005027433673.html)
So, there is a chance that it could be true and DavidAlfas excellent firmware might work.
-
I Ordered the set. I think in two weeks, we know more
-
I Ordered the set. I think in two weeks, we know more
Need to change MCU , Handskit use clone MCU. STM32F103C8T6 , STM32F103CBT6 or CKS32F103C8T6 , CKS32F103CBT6 . I have Handskit tweezers .
-
Hello, David! I changed the display on my custom station, installed an OLED display with a diagonal of 1.54 inches, i2c interface, ch1116 controller, white - I confirm that it worked immediately, I only had to adjust the screen position along the x axis in the station menu!
-
Hi David, I can also confirm that this Makita battery powered QUICKO T12-G station
https://www.aliexpress.com/item/1005005809199459.html (https://www.aliexpress.com/item/1005005809199459.html)
works perfectly with your firmware. Not problems whatsoever, original STM32.
Thank you again for your implementation.
-
If you find any board not in the board list (http://It's the controller board what matters, not the housing or brand!), please attach a picture!
-
How can I change the mcu und what I need to buy?
-
Hello, I have 3 ksger v2.1s stations and, I did tests for detect couterfakes ics on 2 of those stations on the "original" ic that came on the factory pcb, when doing the test to find out if it was fake it gave me the result 20036410, so I bought 3 ic from an Aliexpress seller and 2 from another AliExpress seller, because I imagined that some of the ones that would arrive would be fake, but oh surprise I soldered them all to the boards and I tested them and it showed the value 2003610, i do the test on 6 stm32 chips so i dont know if they are all fake, they are all original, or the counterfeiters have a way of writing this value in the IC, by the way I have already been testing the software in one of the soldering irons and I really liked it, thank you very much for your work.
-
Hello, I have 3 ksger v2.1s stations and, I did tests for detect couterfakes ics on 2 of those stations on the "original" ic that came on the factory pcb, when doing the test to find out if it was fake it gave me the result 20036410, so I bought 3 ic from an Aliexpress seller and 2 from another AliExpress seller, because I imagined that some of the ones that would arrive would be fake, but oh surprise I soldered them all to the boards and I tested them and it showed the value 2003610, i do the test on 6 stm32 chips so i dont know if they are all fake, they are all original, or the counterfeiters have a way of writing this value in the IC, by the way I have already been testing the software in one of the soldering irons and I really liked it, thank you very much for your work.
Hello! As David said, even if you pass the clone test and flash test, your MCU could still be fake. Like my MCU passed all the tests but the error still appeared. hardfault in some software versions. I replaced another MCU and it works in all software versions. Daivd said he still hasn't figured out how to test the clone chip.
-
On some clones, they only difference I cold find was the flash size register returning 65535 instead 64/128/etc.
Run the Flash test (https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg5253981/#msg5253981) !
-
Dear David, In firmware 1.13.4 for KSGER V.3 the instability of the buzzer appeared. When the set temperature is reached, the signal sounds constantly or does not sound at all. This happens if the temperature does not change after switching on. If you change the temperature after switching on, the buzzer will work correctly. But the next time you turn it on, there will be a continuous signal again. In the firmware for the KSGER V.2, the buzzer works correctly.
-
Dear David, In firmware 1.13.4 for KSGER V.3 the instability of the buzzer appeared. When the set temperature is reached, the signal sounds constantly or does not sound at all. This happens if the temperature does not change after switching on. If you change the temperature after switching on, the buzzer will work correctly. But the next time you turn it on, there will be a continuous signal again. In the firmware for the KSGER V.2, the buzzer works correctly.
I have same problem.
-
The buzzer? And it's not happening in previous versions?
The handling code is exactly the same for all, only the stm32 pins change. ???
-
1.13.4 KSGER V.3 I have no problem with the buzzer.
-
How about v1.13.5 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.5)?
-
How about v1.13.5 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.5)?
David, everything is fine now!
-
Hello David! I updated to firmware version 1.13.5 and it started up normally for the first time since version 1.13.0. Now I’m using it on a station operating in the c245 mode. I had a question - I had the following situation: I flashed a station with a pretty low battery , set the settings I needed (c245, etc.) and then turned off the station. When I needed it for work, I first saw the settings recovery screen, and then I saw that the station switched to T12 mode. After completely resetting the station, setting the settings I needed settings, but at the same time disabling battery mode in the settings, everything works fine. For me this is not critical, but I would like to know what this is connected with, I would like to use this function of your firmware. Once again, this is not critical, but still I would like it to be possible to save the parameters of your stings both with and without a battery. Thank you for your work!
-
Then simply disable the battery! The last settings will be stored elsewhere.
Did you read the Readme and the operation manual? This is explained extensively.
-
Please don’t worry, I removed the battery both physically and virtually and I always read the documentation. This doesn’t bother me at all, because in principle everything works, and this is a working situation. If a comparison is appropriate in this situation - any medicine has side effects effects, some have more, others have less. The firmware works and that’s the main thing.
-
Everything is fine now in KSGER v.3 and v.2. and Handskit (KSGER v.2).
Thank you for your work!
-
oleg401169, I don't think we're understanding each other.
If you have battery, enable the option, if you don't, disable it.
This only chooses where the last temperature/tip/profile is saved, there's no real difference.
But if you enable the option and there's no battery (Or it's discharged) the value will always be forgotten and the low battery error shown at boot.
-
I had a dead battery, I disabled the option itself in the settings for now, they just run out pretty quickly for me, I need to think about what’s wrong.
-
Some boards put a 10K resistor between Vbat pin and gnd, it's useless and only drains the battery.
-
Ok, I'll look at the diagram of my station, thanks for the advice!
-
Is it possible to add the Spanish language? I can do the translation
-
I'm spanish myself!
There's no spanish translation because most labels/options are simply too long.
Try yourself, you'll see the end result is awful.
-
hello, i have quicko t12 942, its stm32, i dont know if ita fake or not, i linked a yt video , credit to the owner, its exactly the same as mine
https://youtu.be/xzv6Tvg-ZqY
-
Hello. Today i got my Handskit with twezeers.
https://de.aliexpress.com/item/1005006371386045.html?spm=a2g0o.detail.0.0.7b4cSrGmSrGmCk&algo_pvid=3df2dfc1-844e-4f48-ba88-9e4c55948f75&algo_exp_id=3df2dfc1-844e-4f48-ba88-9e4c55948f75-3&pdp_npi=4%40dis%21EUR%21183.30%2164.15%21%21%21195.10%21%21%40211b617a17056099307331138e51f4%2112000036932452392%21sea%21DE%212186267501%21&curPageLogUid=bZonqKEDf78U
But the normal soldering is not included.
So as i can see, i can use the firmware or not? I am not sure.
BR
-
hello, i have quicko t12 942, its stm32, i dont know if ita fake or not, i linked a yt video , credit to the owner, its exactly the same as mine
https://youtu.be/xzv6Tvg-ZqY
That station uses STC not stm32?
So as i can see, i can use the firmware or not? I am not sure.
No idea, those pictures don't help all, PSU is irrelevant.
Compare with other schematics (https://github.com/deividAlfa/stm32_soldering_iron_controller?tab=readme-ov-file#compatibility).
-
it uses stm32f030k6t6
-
Hello. Today i got my Handskit with twezeers.
https://de.aliexpress.com/item/1005006371386045.html?spm=a2g0o.detail.0.0.7b4cSrGmSrGmCk&algo_pvid=3df2dfc1-844e-4f48-ba88-9e4c55948f75&algo_exp_id=3df2dfc1-844e-4f48-ba88-9e4c55948f75-3&pdp_npi=4%40dis%21EUR%21183.30%2164.15%21%21%21195.10%21%21%40211b617a17056099307331138e51f4%2112000036932452392%21sea%21DE%212186267501%21&curPageLogUid=bZonqKEDf78U
But the normal soldering is not included.
So as i can see, i can use the firmware or not? I am not sure.
BR
See pages 138,139 and next.
-
That T12-942 is lot supported and will never be, too small stm32.
-
so no support for this version of stm32?
https://www.st.com/en/microcontrollers-microprocessors/stm32f030k6.html (https://www.st.com/en/microcontrollers-microprocessors/stm32f030k6.html)
-
I said no, it's too small!
-
Hello. Can somebody tell me, where i need to connect the ST-link? BR
-
GitHub Readme, programming. Please read a bit before asking the same questions!
-
do you think we ask for more here if github guide answer allbour questions? terrible
-
Correct I read everything. But I am not sure because of so many boards where I need to connect. BR
-
Your PCB has nice silkscreen, just look at the connector with CLK, DIO, GND.
-
do you think we ask for more here if github guide answer allbour questions? terrible
Don't you know how to trace connections with a multimeter?
(https://raw.githubusercontent.com/deividAlfa/stm32_soldering_iron_controller/master/Readme_files/stlink_connection.jpg)
-
Hi David, in case it helps you, apparently I have another damn clone and I've had this station for years and it's not "recent"
-
As long as it works... :-+
-
Hello. I flashed my handskid station. I only have the problem with the NTC and I don’t know what else I can du. On the other soldering station with original firmware, the soldering iron works. Inside ist the board V2.7. Maybe know somebody the problem. Also when I switch off the NTC, its still the same alarm. Br
-
Probably fake stm32. Try clone fix option in system menu.
That option was bugged and wouldn't be applied unless other system option was also changed, so for example also change Debug option at the same time.
-
Hello David. When both is off, he shows me 24,9V an the problem with NTC Problem. When i switch them on, there in not anymore the problem with the NTC but he shows me, that the voltage is to low. Something arround 15 V.
-
If you disable NTC It will buse the internal sensor. Is this still fails, it's a fake stm32.
-
when i switch the ntc off, the he shows me "voltage low" and "ntc to high". I this case i can only flash the original firmware back and use it normal?
-
You can flash backup anytime.
If you feel up to it, you can also replace the MCU with a correct one.
-
no. i dont kow how to change it. Then i can only send back |O But for me, i dont looks like a fake :-X
-
It can be difficult without hot air station.
But for me, i dont looks like a fake :-X
They can write anything, but it doesn't mean that it is genuine.
-
no. i dont kow how to change it. Then i can only send back |O But for me, i dont looks like a fake :-X
A rosette alloy or thin enamel lead can be used, threaded behind the legs of the stm32.
Need to change MCU , Handskit use clone (fake) MCU. Use authentic STM32F103C8T6 , STM32F103CBT6 or CKS32F103C8T6 , CKS32F103CBT6 . Authentic chips have perfect laser engraving . I have Handskit tweezers and know this from personal experience. Even from your bad photo, it can be seen that the chip was sanded and re-marked not with a laser but with a milling cutter.
Please Reread : Clone detection https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md#clone-detection
-
I read it. i was sure, that its ok :-DD because there was not FFFFFFFF.
-
Are you sure you're clicking on SAVE after disabling the NTC?
Long-click or BACK will ignore any changes.
Some T12 stations come with 100K NTC instead 10K, try it!
-
I read it. i was sure, that its ok :-DD because there was not FFFFFFFF.
Your MCU is fake, I ordered some stm32f103cbt6 to replace cks32f103cbt6 on my old board a week ago.
-
Your MCU is fake, I ordered some stm32f103cbt6 to replace cks32f103cbt6 on my old board a week ago.
But didn't the CKS work? At least, they did before. Maybe no longer after changing the flash partition scheme?
-
I just want to replace cks with genuine one. :-+
And I also learned how to desolder MCU without hot air gun.
-
Your MCU is fake, I ordered some stm32f103cbt6 to replace cks32f103cbt6 on my old board a week ago.
But didn't the CKS work? At least, they did before. Maybe no longer after changing the flash partition scheme?
Work. I have Handskit tweezers with CKS32F103CBT6.
-
I did not read all the pages of this thread. But I do believe that I have done my due diligence in trying to answer this question for myself.
I have a KSGER T12 that has been running the excellent stm32_soldering_iron_controller firmware for some years now. I just received 2 new KSGER T12 stations and went out of my way to get the same V3.1 HW so they would be the same as my existing station. I got 2 more for one to mount to my other workbench, and one to run off a Dewalt battery adapter. Of course researching first would have let me know I was in for trouble.
The picture is of my previous black PCB, and then one with with the MM32 chip. So do I understand properly that replacing the MM32 with the STM32F103C8T6 will fix the compatibility issues?
My other option is to have these boards made and replace all 3 with the same hardware https://www.pcbway.com/project/shareproject/Stm32_Soldering_station_1_3_inch_OLED_display_T12.html?upId=0&sid=h5LFuKB3gd7kC%2f1DI6qKBaWVxIMIB5mgBvK0NdM4VI0%3d (https://www.pcbway.com/project/shareproject/Stm32_Soldering_station_1_3_inch_OLED_display_T12.html?upId=0&sid=h5LFuKB3gd7kC%2f1DI6qKBaWVxIMIB5mgBvK0NdM4VI0%3d)
Or ebay
https://www.ebay.com/itm/364491453379?hash=item54dd6233c3:g:OooAAOSwrORlC~G9&amdata=enc%3AAQAIAAAA4IkQ%2BXf8Fr1M5NCN2g5R%2FRo7luX5NJBZgtDWsUz58V8LxhecvPyFlxA6Ga5vzpOTtzACv0qbN5oz9r1ZaGJq2TnTF8n95Uj8o1vZBsPs5cG4jzVwfoEHJ%2BlKJbErmj49OTLvT1dbrUtIx4301N4HvY%2FZmSxs7%2B%2B5O4x71a%2FH5hg1%2Fgnmpco278bg4OIw%2Bznod%2BgBI3Cv1N95DdkHNJDGwQnelRoq7AXqE0O0%2BYLuvM7BlJ5sas%2BnR0uG9jhLOxu4Z8ilLzPDgPghPdWda4eS%2F6EtUwe8K%2BrjkNr3x34fuwFO%7Ctkp%3ABFBMuMvd4a1j (https://www.ebay.com/itm/364491453379?hash=item54dd6233c3:g:OooAAOSwrORlC~G9&amdata=enc%3AAQAIAAAA4IkQ%2BXf8Fr1M5NCN2g5R%2FRo7luX5NJBZgtDWsUz58V8LxhecvPyFlxA6Ga5vzpOTtzACv0qbN5oz9r1ZaGJq2TnTF8n95Uj8o1vZBsPs5cG4jzVwfoEHJ%2BlKJbErmj49OTLvT1dbrUtIx4301N4HvY%2FZmSxs7%2B%2B5O4x71a%2FH5hg1%2Fgnmpco278bg4OIw%2Bznod%2BgBI3Cv1N95DdkHNJDGwQnelRoq7AXqE0O0%2BYLuvM7BlJ5sas%2BnR0uG9jhLOxu4Z8ilLzPDgPghPdWda4eS%2F6EtUwe8K%2BrjkNr3x34fuwFO%7Ctkp%3ABFBMuMvd4a1j)
https://www.ebay.com/itm/404688596635?hash=item5e3951ee9b:g:XQcAAOSwBQ5lgE3E&amdata=enc%3AAQAIAAAA8NfuK1%2BDLF9WTYuVX%2FBxI0BhboXB9WU1r0%2BxM9l7m%2BTRpC%2BO3zmNFztrjap%2FiK5i4xEy1dPJ1sz3N7I9EpAmz1SfDyrGom4ov3%2BIMF3QarctriCE%2Bkfr4dOYE4dFfIA3L9WiROwhw%2FEooijoL2zSLnfK1vhCf6r1PBiownLAokjupKv34WrwUzRRrBxXi%2BzJ2jghsSQNHAwnertBWKuaqc2gcnwnsK53d7VEgarERGEDeOIiNBRaz7mk5Y0udlTnTzcQcWmSF%2BMcak8Ps2SY%2FLdTtW2Dm%2FWjDOLK0uMhHuNBs%2BHoblOBTr93cKTfi5l7Gg%3D%3D%7Ctkp%3ABk9SR77L3eGtYw (https://www.ebay.com/itm/404688596635?hash=item5e3951ee9b:g:XQcAAOSwBQ5lgE3E&amdata=enc%3AAQAIAAAA8NfuK1%2BDLF9WTYuVX%2FBxI0BhboXB9WU1r0%2BxM9l7m%2BTRpC%2BO3zmNFztrjap%2FiK5i4xEy1dPJ1sz3N7I9EpAmz1SfDyrGom4ov3%2BIMF3QarctriCE%2Bkfr4dOYE4dFfIA3L9WiROwhw%2FEooijoL2zSLnfK1vhCf6r1PBiownLAokjupKv34WrwUzRRrBxXi%2BzJ2jghsSQNHAwnertBWKuaqc2gcnwnsK53d7VEgarERGEDeOIiNBRaz7mk5Y0udlTnTzcQcWmSF%2BMcak8Ps2SY%2FLdTtW2Dm%2FWjDOLK0uMhHuNBs%2BHoblOBTr93cKTfi5l7Gg%3D%3D%7Ctkp%3ABk9SR77L3eGtYw)
Did I figure this correctly? Thanks
-
Yes!
STM32F103C8/CB for 48-pin devices.
STM32F103R8/RB/RC for 64-pin.
-
The picture is of my previous black PCB, and then one with with the MM32 chip. So do I understand properly that replacing the MM32 with the STM32F103C8T6 will fix the compatibility issues?
It is completely possible to replace stm32f103cb/c8 on MM32. I also have a green board like you and replaced the stm32 chip which works perfectly except for the clock which is redundant because it doesn't have it in the firmware.
-
I am logged in to OpemSTM , I see no download option for Workbench. Please advise.
Thank You.
-
Why are you using that? It's clearly indicated, please read! Building the firmware (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Build.md)
-
Wow, so all the variations of ksger HW3.1 are very confusing. I have an older one and worked great, the black board with the switch regulator, and Davids fine firmware. I got 2 more and they have different boards, discussed a few posts back, got proper chips from digkey and started to get read to swap them. I was worried about the battery hooked to the chip to I removed it, without removing the display. Managed to get a solder bridge between the battery pins. This instantly smoked the diode into the V reg. Got desperate and removed the display, fixed the short, replaced the diode. I spend time looking at all the boards and schematics. And first I don't understand how shorting the battery pins could pull that much current. I get several hundred ohms from 3V3 to the battery. But fixing the short fixed the overload, was testing injecting 3V3 with a current limited power supply.
Looks to actually be named V20 Has anyone made a schematic? Is there a topic about this board somewhere? The crystal doesn't hook to the processor. There is a time data chip and it has a trickle charger function, maybe this blew. I guess that can all be removed from the board anyway. But I'm honestly about to start designing and building my own board. What would be the wish list for David's firmware. No RTC, crystal, or eprom? Then a proper voltage regulator and battery. What was the best board as far as the op amp for the temperature sensing? Any other advice? I've had several handles short and blow the mosfet, some circuit to shutdown the output would be nice if it was shorted.
-
Why a RTC for a soldering station? Would you like the temperature widget 50% smaller to make room for a clock?
You'll see no station with this dumb feature, maybe in newer ones with large LCDs...
As for the EEPROM, it's useless, the settings are pretty large and won't fit there, and not all stations have it anyways, will only add complexity and complicate my existence when maintaining the firmware.
I have a simple vision: One rule thems all!
-
I agree the clock is dumb. Did some of the STM chips have an internal time clock since the crystal was hooked to the STM in many versions? Also confused as it looks like the battery only hooks to the RTC on this model, does this mean the battery doesn't keep flash memory alive on this models even when it's present?
Overall the battery is good to have?
My main design criteria is to work seamlessly with your existing firmware, you do excellent work and I lack the skill and have no desire to fork it. But from the models being released now it seems like it getting harder and harder to get compatible hardware. Just looking to design something that is simple and is the best of the different models. What worked well, and what didn't. ie I think i remember a post about one model having a crappy op-amp for the temperature feedback.
My only firmware change question I have for you is: If I detect a major overload and shut the output mosfet off. The only options would be to latch it until power cycle and make someone wonder what was wrong, or detect the overload and shut down every for every individual pulse of the PWM which would most likely burn it up anyway by keeping it inside the linear region all l the time. My desire to fix this is I had it happen and short the mosfet, when I discovered this the handle was ruined and was almost on fire. The question is are you open to a signal to the processor that a over current has happened and lock out the PWM drive and throw a error message? You pick the pin. Thanks.
-
The rtc also has some user RAM, used in this FW (After enabling battery option) to store last temperature, tip and profile, so yeah it's a good thing, but not essential, will be stored to the flash otherwise
-
What about the versions with out an off board RTC, do they also have user memory? I assume the STM32 has an onboard RTC since the schematic show a time crystal hooked to the STM32. So is there any point in the battery without the off board RTC? I think storing the last settings are worthwhile so trying to get this straight. I might start another thread on this project. But would greatly value your input, I wouldn't have known about the RTC without your input.
-
I have no idea. I have no feedback, no schematic... But if the battery is connected to stm23 vbat pin, it will work normallly.
No crystal neeeded, just the battery.
I wouldn't have known about the RTC without your input.
Most is there, it only takes some reading!
https://github.com/deividAlfa/stm32_soldering_iron_controller#battery-mod
-
Yes, thank you. I did read that at least once. I did not connect that there was an internal RTC. I've gotten lost looking at the seemingly 100 versions of the board.
-
Dear David. Is it possible for you to combine your firmware with the COMBO ksger firmware? This will interest a lot of people.
-
No, sorry. I don't have a combo.
-
For some reason I decided to build a open version of this board. Mostly after getting the latest version of the ksger.
Is the OPA366N a good opamp for the tip temp?
The latest version of the board doesn't work with the battery as the battery only goes to the off board RTC and not to processors, I assume the MM32 they are using doesn't have a RTC onboard. That's going away for sure.
Decided on using a switching power supply like on my first station with the black pcb. I keep second guessing this.
NTC is internal only on this version. Is there a 'best' default value of NTC?
Will post the schematic when I get it done. Should this be here? Or in a different thread? Any interest?
-
The fix is easy, just a small wire from stm32 pin 1 connected to the RTC battery pin.
Why? I don't know,aybe longer battery life.
For lower noise, don't use a 24->3.3V buck converter, better 24->5V, then use a LDO to lower it to 3.3.
Internal NTC will cause higher temperature drift, as you're designing it from scratch there's no excuse to do it right.
-
The fix is easy, just a small wire from stm32 pin 1 connected to the RTC battery pin.
Why? I don't know,aybe longer battery life.
The RTC comment was just a heads up if the issue got brought to your attention. I kinda asked before since I was confused, but now that i've traced all the circuits out the battery doesn't send any power to the processor. I'm sure it was the cheapest option they could take, but still no idea why they added so many parts for a clock.
For lower noise, don't use a 24->3.3V buck converter, better 24->5V, then use a LDO to lower it to 3.3.
Internal NTC will cause higher temperature drift, as you're designing it from scratch there's no excuse to do it right.
If I have room for the second regulator, plus just having a SMPS on the board could be an issue. We'll see.
I'll just figure out what RTD is in the ksger handle and also add the option for one on the PCB if someone wants one with different handle.
I think you misspoke there, lol, no excuse to do it wrong either.
-
If I have room for the second regulator, plus just having a SMPS on the board could be an issue. We'll see.
There are a lot of buck converters compatible with 7805 pinout. I used it successfully in my custom controller (5V version and 3.3V LDO), you can also use WE 173950536 or something similar.
-
If I have room for the second regulator, plus just having a SMPS on the board could be an issue. We'll see.
There are a lot of buck converters compatible with 7805 pinout. I used it successfully in my custom controller (5V version and 3.3V LDO), you can also use WE 173950536 or something similar.
Thanks. The WE part is kinda expensive, I've used similar RECOM parts before, also expensive.
How can you buy a whole switching regulator for less than the parts just buy the controller chip? I'm pretty much doing copy and paste from the TI controller designer page. People keep saying the newer SMPS are very quite, so I'm going to give that a shot 1st. Should be easy to do a version 2. The black pcb ksger I've used for years now has a SMPS and hasn't caused issues.
-
Looks like the ksger used 10K NTC. Was getting everything setup to measure the betas and find the correct part numbers for them. Then I found that 2 of the 3 new ksger handles don't have NTC in them at all. So they fault my old controller too. Too many variations to comprehend here anymore.
Who sells handles these days? I can't keep track of what is what. Are the quicko handles better with NTC and shake switches? These have actual mercury switches in them, lol
-
T12 handles compatability is a real pain, mine are all rewired to the same pinout and with the same NTC.
Not a big problem with NTC because you can switch beetween 10k/100k in FW or disable it completely, but it can be very difficult to find a stand that fits...
BTW I think it is worth to consider T245 also, it is a bit more expensive option, but heat up time is excellent.
-
T12 handles compatability is a real pain, mine are all rewired to the same pinout and with the same NTC.
Not a big problem with NTC because you can switch beetween 10k/100k in FW or disable it completely, but it can be very difficult to find a stand that fits...
BTW I think it is worth to consider T245 also, it is a bit more expensive option, but heat up time is excellent.
Adding them is my current plan. What NTC do you use? 10K, but several different options exist. When you say "stand' you mean the thing you rest the handle in when not using it?
I'm trying to make a simple, yet high quality PCB, and avoid feature creep. Started to design a super cap circuit for the battery function tonight. Had to talk myself down, lol. The T245 doesn't have a thermistor iirc, I planned to have one on the board and jumpers to snip to choose, so that it not an issue. I also think there is no shake function on the T245? Does the firmware support it? I have no interest if not. I hate programming.
Another question I'm facing do I use only leads for the output jack? Or also a 4 or 5 pin jack? Looks like quicko never used NTCs?
Full disclosure. My intention(providing I complete this) is to put everything I design and most of the reference and directions on github. I have built several other things that I ordered a 100 pcbs for as it didn't cost anything significantly more(VTVM probe, battery eliminator, RF probe, clones of the heathkit probe shells, things I wanted to do anyway), so I think I'm going to setup an ebay store. Not thinking it'll make any money, just as a hobby and being helpful.
Which brings me to another point I've kinda been meaning to bring up. David would loading your firmware onto them as a few dollar option be acceptable if I send it to you? Really trying to just be honest and fair about it.
Parts are ordered, schematic is mostly done except for power and gnd to the processor, CADing the old board now to everything lines up with the faceplate, hopefully I'll mill a PCB tomorrow.
-
What NTC do you use? 10K, but several different options exist.
Any (small) 10k NTC with known beta will be good.
When you say "stand' you mean the thing you rest the handle in when not using it?
Yes.
The T245 doesn't have a thermistor iirc, I planned to have one on the board and jumpers to snip to choose, so that it not an issue.
That's a good idea, I've got possibility to mount NTC directly on PCB but with T245 I've mounted it in a connector.
I also think there is no shake function on the T245? Does the firmware support it? I have no interest if not. I hate programming.
FW supports shake mode and stand mode as well (T245 doesn't have vibration switch, placing handle in stand triggers standby mode).
-
Any (small) 10k NTC with known beta will be good.
Had to educate myself on NTCs. The numbers I found online for the ksger handle is BF58 10k B3950. Since it seems that most handles with NTCs are probably ksger, using the same one would reduce issues if people are swapping handles. When I went to digikey I can find 10K but had options for a B3950 in across categories of B0/50, B25/50, B25/75, B25/85, and B25/100. Being that B25/50 results in many more parts I assume that is the correct category. I need to find a hobby to relax, this one doesn't work.
That's a good idea, I've got possibility to mount NTC directly on PCB but with T245 I've mounted it in a connector.
FW supports shake mode and stand mode as well (T245 doesn't have vibration switch, placing handle in stand triggers standby mode).
Putting it in the connector makes a lot of sense. Should be close to room temp, but doesn't catch the handle getting hot.
I was asking if the firmware and hardware supported the T245, obviously the wiring needs changed a bit.
I think the stand switch and the option of putting the NTC in the connector finalizes the decision to go with the 5 pin connector. It leaves room for an NTC being added, and a pigtail for a stand switch. Leave solder pads for wires and some bites to snap that area of the board off to clear a connector if anyone needs too. Really wish that connector would come out the back of the front panel instead of the front. I appreciate the advice.
-
That's a good idea, I've got possibility to mount NTC directly on PCB but with T245 I've mounted it in a connector.
FW supports shake mode and stand mode as well (T245 doesn't have vibration switch, placing handle in stand triggers standby mode).
I was asking if the firmware and hardware supported the T245, obviously the wiring needs changed a bit.
Daves firmware does support the T245, when it comes to hardware the KSGER and Quickos and others that use similar boards can support either handle, but it takes modification (remove a trace) which I believe essentially makes it unable to be returned to be used in its original configuration. Someone had a great idea, a page or two ago, that if you went with a 6 pin output, that would allow easy switching between a T12 handle and a T245 handle without modifying the hardware or use other means of "non-destructive" hardware methods of changing handle configurations that would likely require someone to open the station to do so (like using jumpers or a switch). Of course that would mean people who built your design would have to either get a new connector for their handles or use a patch cord if they use their handles on different stations that use the 5 pin connector.
Just a thought.
Good luck. :-+
-
Daves firmware does support the T245, when it comes to hardware the KSGER and Quickos and others that use similar boards can support either handle, but it takes modification (remove a trace) which I believe essentially makes it unable to be returned to be used in its original configuration. Someone had a great idea, a page or two ago, that if you went with a 6 pin output, that would allow easy switching between a T12 handle and a T245 handle without modifying the hardware or use other means of "non-destructive" hardware methods of changing handle configurations that would likely require someone to open the station to do so (like using jumpers or a switch). Of course that would mean people who built your design would have to either get a new connector for their handles or use a patch cord if they use their handles on different stations that use the 5 pin connector.
Just a thought.
Good luck. :-+
Interesting thought. Someone who is inclined to do such a thing could easily do that, I think, I haven't looked into the T245 handle yet. I would like to keep it easy for the people that need easy. I've thought about making face plates as an option so people wouldn't have to solder. But the displays are stupid expensive. I don't know the answers yet, I'm not going to make any money competing against the Chinese brands. But after buying this last controller I was fed up and decided to build one, actually I need 3, but I enjoy this. I figured a few other people would want the same thing, so I'll share that. Thought a kit would be nice, but it'd take more time to bag up the parts than build one.
-
Putting it in the connector makes a lot of sense. Should be close to room temp, but doesn't catch the handle getting hot.
No, the thermoelectric effect of the tip probe ends in the socket, where the tip is connected to the handle.
The generated voltage is based on the temperature difference between the hot and the cold part across the whole tip.
So, you want to read that junction temperature, not in the board or the connector.
If the handle gets to 45ºC, but you put the sensor somewhere else at 25ºC, you'll have a drift of 20ºC.
-
Putting it in the connector makes a lot of sense. Should be close to room temp, but doesn't catch the handle getting hot.
No, the thermoelectric effect of the tip probe ends in the socket, where the tip is connected to the handle.
The generated voltage is based on the temperature difference between the hot and the cold part across the whole tip.
So, you want to read that junction temperature, not in the board or the connector.
If the handle gets to 45ºC, but you put the sensor somewhere else at 25ºC, you'll have a drift of 20ºC.
Yeah, that is what I was figuring since you need to read the temp of the cold junction to correct for it.
Are the ntc settings constant? Or set up for each tip?
-
Daves firmware does support the T245, when it comes to hardware the KSGER and Quickos and others that use similar boards can support either handle, but it takes modification (remove a trace) which I believe essentially makes it unable to be returned to be used in its original configuration. Someone had a great idea, a page or two ago, that if you went with a 6 pin output, that would allow easy switching between a T12 handle and a T245 handle without modifying the hardware or use other means of "non-destructive" hardware methods of changing handle configurations that would likely require someone to open the station to do so (like using jumpers or a switch). Of course that would mean people who built your design would have to either get a new connector for their handles or use a patch cord if they use their handles on different stations that use the 5 pin connector.
Just a thought.
Good luck. :-+
When we cut the PCB trace to use T245 handles, we can rewire that cut connection inside the T12 handle socket.
This way it will keep working with both T12 and T245 handles.
Changing the number of wires in the handle is not necessary, it's additional work and cost.
Also some T245 handles are impossible to open and others very difficult.
The only thing we need to do to the handles (T12 and T245) is to change the wires order in the handle socket and put the said shunt in T12 handle socket to remake the PCB cut we did.
The ksger PCB has a 5 pin socket, with 2 ground PINs, we can isolate one of those pins from the PCB and rewire it to reconnect the cut trace inside the T12 handle socket.
Other option that was explained to me, is to stop using the NTC inside the T12 handle and use that wire to remake the said cut trace, this will avoid the additional work of isolation one of the ground pins from the PCB in an already made station.
Looking at the schematics will help understand the options for the already made stations.
-
So, you want to read that junction temperature, not in the board or the connector.
If the handle gets to 45ºC, but you put the sensor somewhere else at 25ºC, you'll have a drift of 20ºC.
Any chance you are only sampling the NTC when the heater is off? Laying out the board and being paranoid, then thought I should ask before worrying. Thanks
-
Everything is sampled with tip power off. I can't understand how this would affect the layout?
Just copy any Quicko/KSGER design, but with better op-amp, ground planes, power decoupling and regulator design. I won't be making custom firmwares!
-
Everything is sampled with tip power off. I can't understand how this would affect the layout?
Just copy any Quicko/KSGER design, but with better op-amp, ground planes, power decoupling and regulator design. I won't be making custom firmwares!
Because I crossed the heater on trace with the NTC signal under a resistor, hence the question. I want to be able to make the PCB on a mill and can't do plated through holes, so vias are limited to places where they can be soldered. Not asking you to make custom firmware, that is the main design criteria.
-
Do you expect your board to be better than Ksger when you're placing the lower vias posible?
Why not do it properly and order to jlcbpcb.
You can fit 3x pcbs in 120x102mm, so you'll get 15 PCBs for ~$4 including shipping.
-
Do you expect your board to be better than Ksger when you're placing the lower vias posible?
Why not do it properly and order to jlcbpcb.
You can fit 3x pcbs in 120x102mm, so you'll get 15 PCBs for ~$4 including shipping.
I think I can do better. A better power supply, better opamp, better ground plane, actually read the STM32 on bypass capacitors as ksger obviously did not. I will proof it out and then have them made. I don't understand "lower vias" I managed a layout that does not need many. Maybe I'm missing something. I do not believe this is a multi-layer board if you are referring to buried vias.
-
Parts are here, now I need to find time to build it. Anyone have a lead on the OLED displays? I got one from digikey made by adafruit and pinout is way wrong. Another issue with flexible compatibility.
-
Hi everyone. Long time not loged in.
I was using one stm32 based board v2.1s with a jbc c210 tip.
Now i need a duplicate of that. I have the same board but with some reason, i can not access the MCU. The error is "read protection turned on". Can't read, can't write. MCU version is STM32F103. If i replace the STM, is it possible to copy the firmware from the other STM into the new one? In this case it will copy also the tip parameters stored in the old STM? Or do i have to calibrate again?
I wouldn't do that, i burned already 2 jbc tips when tried to calibrate... 😔
-
Hi everyone. Long time not loged in.
I was using one stm32 based board v2.1s with a jbc c210 tip.
Now i need a duplicate of that. I have the same board but with some reason, i can not access the MCU. The error is "read protection turned on". Can't read, can't write. MCU version is STM32F103. If i replace the STM, is it possible to copy the firmware from the other STM into the new one? In this case it will copy also the tip parameters stored in the old STM? Or do i have to calibrate again?
I wouldn't do that, i burned already 2 jbc tips when tried to calibrate... 😔
Why create a problem - install a new chip, flash it and, yes, you will have to calibrate again. It is advisable to install the original chip, problems may arise with clones. As a solution, you can buy a bluepill board with the original chip, they are sold on aliexpress, and many sellers have them as well they sign - just f103c8t6 and f103c8t6 original. I have a soldering station assembled on a c245 assembled on a bluepill board, there was a problem with the clones, but when I installed the board with the original chip everything began to work perfectly.
-
Can't read, can't write.
Hey cosmin, long time no see!
(Yeah I saw your WhatsApp, just too freaking busy!)
Check the option bits, clear RDP / WRP.
And yeah cloning a STM32 should preserve everything, there isn't anything device-specific in the CFW, only the original KSGER firmware will refuse to work as the stm32 unique ID changed, asking for the activation key.
About the C210 issue, no idea, it's connected in the same way as T12, but the output is much lower, about ADC 1500 for 400°C.
Try a manual calibration in CALIBRATION > SETTINGS.
Cheers!
-
Yes, it's connected as the T12. But in calibration process... it glow like a nice red bulb and burned out... |O
So i was thinking if i copy the fw from a same version pcb already calibrated with the C210, maybe no need to calibrate again.
-
About the C210 issue, no idea, it's connected in the same way as T12, but the output is much lower, about ADC 1500 for 400°C.
Try a manual calibration in CALIBRATION > SETTINGS.
Tip will heat up when adjusting default cal250 value in calibration setting menu.
It's no sense that you need to insert tip first when changing default cal value, or maybe these settings should move to iron menu.
Yes, it's connected as the T12. But in calibration process... it glow like a nice red bulb and burned out... |O
So i was thinking if i copy the fw from a same version pcb already calibrated with the C210, maybe no need to calibrate again.
You can dump chip's full data(ADDR:0x8000000 SIZE:0x20000) from the old one and write it into new chip.
-
I used this calibration method. Can't calibrate without the inserted tip.
https://www.youtube.com/watch?v=bPQqpM8UJT8&t=185s (https://www.youtube.com/watch?v=bPQqpM8UJT8&t=185s)
Is there a way to erase the chip's content? It has the original Ksger fw, can't read, can't write, can't erase...
Or the only way is to replace the STM and program it as i wish?
I am using the JBC C210 tip in this configuration on KSGER 2.1S board, with 12V power supply.
Same way the T245, but with 24V power supply.
Green wire not connected.
-
Are you even reading? I said to clear the option bits.
This is explained in the programming Readme.
Same as why you need to insert the tip, also explained in the operation manual.
Guys, don't be lazy and read!
-
No need to argue, i don't know what option bits you are talking about.
I am using the original firmware, not yours. With yours i get checksum error and continously restarting.
The meaning of the forum is to ask what we don't know.
I finally succeeded to erase the "locked" MCU.
But no matter how i try, the fw copied from the other MCU is only 4kb... So not working when i upload in the new MCU.
The original file is 74kb and working. But i still have the calibration problem.
So... in the calibration process the c210 tip is turning glue red. I can't calibrate him without burning out. Can anyone help me out with this. I tried to calibrate without the tip, but did't help.
-
Then you have a fake/clone! Newer firmware uses different features which unfaced lots of fake stm32!
Option bytes unlocking and fake device detection are described in the programming section:
https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Programming.md
But no matter how i try, the fw copied from the other MCU is only 4kb
Because when reading with ST-Link you must set size to 0x20000.
-
Greetings.
I have a ksger 2.1S board with an old handle and a 5-wire cable. I want to change the handle to a more comfortable one, but the new handle has 3 wires. Is it possible to adapt the new handle to my board?
Thank you.
-
Greetings.
I have a ksger 2.1S board with an old handle and a 5-wire cable. I want to change the handle to a more comfortable one, but the new handle has 3 wires. Is it possible to adapt the new handle to my board?
Thank you.
Handle with 3 wires can be used without NTC or with NTC placed in a connector (not the best solution but ok for 3 wires).
If you want to use vibration switch it is possible also, but in such case heater ground and tip ground should be connected together.
-
Understood. Thank you.
-
Hello David! I installed firmware 1.13.8 on my stations, everything works fine! It’s very good that the choice of station operating mode in the menu is back, it was sorely missed! In my plans I want to assemble a station that operates in two modes - c245 and t12, that is, at the station itself it will be possible to connect both handles, and the choice of operating mode will be carried out in the menu. From this I have a question - saving the calibration data of the tips will only be for one mode or will it be for both?
P.S. Maybe you remember I once complained to you about the fact that my battery was draining very quickly and that the new firmware version was not always installed correctly? The problem was solved by replacing the bluepill board on my custom station with a board with the original chip and everything worked like a Swiss watch! Also, at a sale on Aliexpress in the official ksger store, I finally bought myself a T12 station version 2.1 with an LED display (replaced the display with a white one, installed a mercury bibrosensor in the handle and installed an LED to indicate the operation of the handle) and, of course, immediately installed your firmware during installation There were no problems, everything works great!
-
Each profile (T12, C245 and C210) can store 85 tips concurrently, changing between the different profiles won't affect the others.
People with those fake/clones that worked well in older versions but failed with the new settings storage:
Please try v1.13.9a (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.9a), hopefully the issues will be fixed by now!
-
To David:
Firmware modification allowing automatic determination of profile T12, C245 and C210 according to the type of handle of the Soldering Iron, obtaining an accurate resistor 10k, 20k, 30k or other values up to 100k in series on the NTC sensor in the handle and defining the resistor for each profile. This will allow the profile to be defined according to the chained handle. You already have a procedure for automatically determining the NTC 10k or 100k
An example of an additional precision resistor:
0k = T12
50k = C245
100k = C210
Each of us can exchange NTC for 10k.
-
This seems a mess to me, sorry but no, there's a mix of handles coming with 100K, 10K NTCs, plus the tolerances.
-
100% of the handles for C245 and C210 are without NTC and have a three-wire cable.
They are being reworked to be NTC and five wire cable anyway.
-
Sorry for my English (using the translation).
Ksger v.2.1, C245, firmware v1.13.9a.
When turning on, the temperature grows by +60 degrees
above from the installation (awakening +30) on all 3 my tips.
Then it decreases to installation and holds.
So it should be?
Cold Boost is turned off, I did not notice changes.
Reset away, installed
PWM 3x, Kp - 40, Ki - 55, Kd - 25
It became above +15 degrees.
-
First: is it calibrated? Default values are pretty low, so the controller will easily overshoot.
If It overshoots +60°C for only 1-2 seconds and it quickly returns to normal, it's likely to be noise or a crappy tip, poorly bonded tips from AliExpress will overshoot very easy because the heater isn't well attached to the tip.
Power of C245 must be limited to 120W or so.
Try reducing Imax to 0.5
-
@DavidAlfa, Thanks for the answer, you are doing a great job!
1) not calibrations, there is no good thermocouple, the solder begins to melt by 205 degrees (I do 250 must be reduced by 20 degrees, by 400 don't be changed)
2) yes, temperature exceeds +60 ° C for only 1-2 seconds and it quickly returns to normal,
the tips with AliExpress of course :)
3) Pmax = 105W installed
KD = 30 almost solved the problem: +15 has become now
It is also planned the handle T12, and therefore the question:
I can't understand how to change the "profile", in the main menu it is not
ps: version 1.13.9a KSGER_v2_OLED.zip in menu writen 1.13.7
-
Have you read the operation manual?
-
Have you read the operation manual?
sorry
"Issue a clockwise drag-rotation to show the tip selection." - google translates this phrase very poorly :(
"Click and hold and turn clockwise encoder" - so better translation.
-
the tips with AliExpress of course :)
Aliexpress C245 perform terribly bad, cheap T12 do better.
"Issue a clockwise drag-rotation to show the tip selection." - google translates this phrase very poorly :(
This is properly explained in Basic Controls (https://github.com/deividAlfa/stm32_soldering_iron_controller/blob/master/Readme_files/Operation.md#basic-controls):
For some actions you might be instructed to issue a Drag rotation.
This means clicking the button (Helding down) and rotating at the same time.
-
Hello David!
Today I used the KSGER_v2_OLED soldering station, FW v1.13.9 05.03.24.
Some settings are selected in the Menu:
Wake mode STAND
In stand STBY
Delay 15s
After installing the soldering iron in the stand, I pressed the encoder twice to turn off the heating. The transition to SLEEP mode has occurred. However, after the expiration of the Delay 15s, STBY mode turned on again. :o
If you have the time and desire, please fix this issue in future releases. Thank you. :)
-
Is it in shake or stand mode? Will have a look at it.
Edit: Sorry, I read it in a hurry, my question was stupid ::)...
-
Stand mode.
-
You have stand setting = standby, right?
Stand mode didn't check whether the new system mode was a higher power mode, so it now checks for this and ignores it when necessary, avoiding this issue.
Fixed in v1.13.10 (https://github.com/deividAlfa/stm32_soldering_iron_controller/releases/tag/v1.13.10).
-
I'm drowning in information. I could really use some guidance.
1) Of the different versions, which is more preferred? There are quite a few slight differences between brands/models. Thanks to the documentation on github it does give me some ways to identify different version.
Since they all seem to fall into primarily two version; 955/v2 or 958/v3, which should I go for?
2) My plans are to start with T12 tips and then if I get more involved and can justify the cost, convert to T245 tips. But I would like to continue to be able to use T12 tips. I assume I may have a few different types of T12 tips while only having maybe one T245 tip. So I would like to switch back and forth. Ideally whichever model is easier to do the mods on and switch between handles the better.
3) I can't seem find information on if stand sleep detection can be made to work for the T245, if the hardware supports it and if so what modifications might be necessary to make that work.
This will my first legit soldering iron, after using a crappy old school plug directly into the wall with a little knob on it version for many years. While I don't do a lot of soldering I would like to think having a much better station will encourage me to do take on additional and more challenging projects.
-
My board KSGER v2.1 works with C245 and T12
-
Any station is very much the same, and the same mod applies for C245 tips.
-
Thanks. I ordered this one: https://www.aliexpress.com/item/32971888371.html (https://www.aliexpress.com/item/32971888371.html) set 12. It's still in transit. I'll open it up when it gets here and see where to go from there.
-
Hello. Today I got my ksger station. Can anybody tell me the pin out for the 5 pins? I want to resolder my Handskit iron to use it. Br
-
Pinout is on a diagram.
-
I received a PM from a user a month or two ago.. but I haven't been on the forum for a while. Today I wanted to find the time to post an update. Since Christmas I have had serious health issues and haven't been able to complete this project. I hope to return to it at some point in the future. But now for now, I don't have the time or energy to try. There are other things in the way, and if I return to it, I want to be able to give it full concentration while working with the electrical side. I wanted to thank DavidAlfa and others for the open nature of this firmware, and sharing ideas or help with each other. It's a really fun thing to have a small soldering iron like this and I hope to finish it at some point this year. I have all the parts sitting in a box waiting to be completed.
So far, the only thing completed is some customized settings and UI changes in the firmware. With a script that can take a new version of the firmware and apply my custom stuff over the top of it (it's mainly just custom visual stuff so that it looks the way I prefer on my version of the screen). There's two splash screens for example.. it shows STM32 logo then JBC/Hakko logo for a second or two. And resizing some of the icons or fonts in a certain way. There's an icon for each tip type, but they are so small it's hard to get a lot of detail. It was all just a bit of fun to play around. Creating the script was complicated, if one thing is wrong.. the firmware won't boot up.. it requires a lot of backups and troubleshooting, but once it's created properly, it works. I used AutoHotkey, but I'm sure the same idea would work with AutoIt or C++ or something else. AutoHotkey is the only one I have a lot of experience with.
I was already very happy with no changes from DavidAlfa's firmware, the other side was just a bit of fun. After the first time I flashed the firmware, I must have flashed it a 1000 times before Christmas. This worked reliably. Even though the mechanical connections became strained. I recommend soldering a 2.0 PH connector to the PCB, and also to the STM32 Programmer connectors. My connections were improvised because I didn't have any connectors when I received the PCB. They have become loose over time, and you need to be careful not to bump the PCB or wires while they connected. Or if you turn the rotary knob. I used the PC's power via USB to power the screen and chip. But it all worked. As long as you are careful not to touch the the wires too much.
I have yet to plug in any iron handles or tips, and that side of the code is stock so far. Except for some profiles created for the specific tip sizes that I have in the box of parts. This is fun stuff, and I hope to return to it at some point in the future. And to make it work with the different iron handles. There's just serious life stuff in the way at the moment.
-
Hello. I have this chip on my new ksger 3.1. this is not a smt32 chip correct? I can connect it with st link software, but I can’t remove the write protection. Br
-
Search "mm32" in this thread ;). (Not compatible with cfw).
-
Hello, I'm quite new to this place and field, so apologies in advance for my inexperience.
I was wondering if it would be possible to modify this board to work with c245 tips. is it possible to do so by modifying how the wires are connected to the gx12 connector? I plan on hooking up a couple of relays so that I can switch between c245 and t12/c210 (c210 apparently works along with the t12 without requiring modifications).
For clarification, I have not purchased this board yet, this is a picture from another customer that bought it from the same listing.
feel free to recommend me a board that would be easy to modify.
Thanks :)
The image doesn't work properly with "end-of-post expandable thumbnail", extremely unlucky first post.... spent way too long trying to make it work, another image worked fine
had to convert it to png instead of saving it as png (from webp)
-
I use the blue one, very easy to mod.
After modding board, you need connect "+" and "TC" in male GX12 connector (For T12).
-
had to convert it to png instead of saving it as png (from webp)
Use jpg dude! Png is good for vectors and simple colours, but gets gigantic with photos.
Edit: FYI, I bought several tips from the Quicko store.
To my surprise they worked great for the start, hadn't the usual jumping/madness.
https://www.aliexpress.com/item/1005006101561984.html (https://www.aliexpress.com/item/1005006101561984.html)
-
Use jpg dude! Png is good for vectors and simple colours, but gets gigantic with photos.
My bad, will do from now on!
Edit: FYI, I bought several tips from the Quicko store.
To my surprise they worked great for the start, hadn't the usual jumping/madness.
https://www.aliexpress.com/item/1005006101561984.html (https://www.aliexpress.com/item/1005006101561984.html)
Possibly manufacturing process ironed out/improved, or it could be a different factory altogether, good to know though!
-
I use the blue one, very easy to mod.
After modding board, you need connect "+" and "TC" in male GX12 connector (For T12).
I see. Does the mod consist of the soldered resistor on "G" and "N", and the trace cut beneath it?
As for "+" and "TC", I'm a little confused, are those referring to the black JBC cable, and the solder blob on "+" ( why is there a blob there anyway?).
-
Finally, I bought a KSGER v3 for my dad, replaced the stinky MM32 with a STM32, flashed the CFW, all good.
PID was a bit off, slowly oscillating back and forth.
After some tuning I got it pretty decent with the following settings:
FILTER MENU
- Filter: 75%
- Threshold: 60
- Min: 40%
PID:
- Kp: 45
- Ki: 15
- Kd: 6
Though the response with the Quicko tips are close to perfect compared to my old ones!
-
I see. Does the mod consist of the soldered resistor on "G" and "N", and the trace cut beneath it?
As for "+" and "TC", I'm a little confused, are those referring to the black JBC cable, and the solder blob on "+" ( why is there a blob there anyway?).
I soldered a 10K resistor as "NTC" for a static temperature reference, but it's not a general modding.
You should connect real "NTC" in tip handle or in GX12 connector.
Original board has a 0 ohm resistor on "J1" (below "R1"), it connect "+" and "JBC" together on board.
T12 tip connect heater and thermal-couple in serial but C245 is not, so you need connect it back to use T12 tips.
And why has a solder blob on "+", because I think it might help current flow while using C245?
Finally, I bought a KSGER v3 for my dad, replaced the stinky MM32 with a STM32, flashed the CFW, all good.
PID was a bit off, slowly oscillating back and forth.
...........
I add a new building profile for chinese firmware build in my main branch, can you take a look if having free time.
-
Ah okay, thanks for the clarification ^^