EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: Pr Utser on October 14, 2023, 07:56:21 pm
-
Hi all,
I have been working on a firmware mod for the GWInstek GPP series lab bench power supply.
Firmware mod features:
• Voltage and current measurement averaging
• Voltage calibration correction
• Current calibration correction with output voltage dependent leakage current compensation
• Separate current/voltage calibration correction for power versus load mode
• Fast OCP/OVP response (10x faster than original firmware)
• Configurable OCP/OVP arming delay during channel switch on
• Configurable OCP/OVP trigger delay
• Channel on/off button also selects channel for data input
This mod has been developed and tested on a GPP-4323. Although not tested on a GPP-1326/2323/3323, I see no reason why it wouldn't work.
See attached zip for the mod files and documentation.
Unfortunately, I could not upload the gpp_mod.exe file because of it's file size. So there where the documentation mentions running gpp_mod, one should run python gpp_mod.py instead.
The python version used for this project is 3.11.2. Added python packages are:
• intelhex 2.3.0
• numpy 1.26.0
• scikit-learn 1.3.1
Best regards,
Prutser
-
you can use free file hosting for an executable in a zip file .... sure it may or will die eventually, just need to re-vive redo it ???
-
Via the WeTransfer link below, it is possible to download the gpp_mod_1v00.zip including gpp_mod.exe file.
Unfortunately the link will expire in 1 week from now.
Suggestions for better file sharing alternatives are welcome.
https://we.tl/t-B8Yg5GuByE (https://we.tl/t-B8Yg5GuByE)
SHA256 Size Name
---------------------------------------------------------------- ------------- ------------
66EDAB09E0D6C14D866979BCD7B4C40A1553DCD5E646B8595C3E452B84E9C99B 67690586 gpp_mod_1v00.zip
E8BB20313ACA4206F50F93BD757C3A12D3E1100A028B8A19E10A1442AEE08BAD 67508977 gpp_mod.exe
B2D260877322F3F8890AFEEE1D2D31FCDE18BD3020A716DF4C1AC0AFB6F04583 5624 gpp_mod.hex
DB6B26D191A02719D59848922F20FBE6B80C4DFA44065A5B36C7A2FC9933A5B0 628817 gpp_mod.pdf
741515FA7D517671DB70401DC84F0785ED03F324261F312FC477AB0324A764D1 12344 gpp_mod.py
1F4176EED0B13C2D4BDDD510FC352723E021DCDB08BF00DCE25D8E92D9D11F3A 4039 gpp_mod_template.json
-
The beeper of the GPP unit is insanely LOUD. However, I value the audible feedback on button presses so I don't like turning it off.
This is why the next topic in this project might be to PWM drive the beeper output.
Currently I have taped off my beeper. To still get some sound out of it, I punched a small hole in the tape with a needle. This works very well but to access the beeper a lot of disassembling is involved.
So if people are interested it may still get me motivated enough to solve this with a firmware solution.
-
@Pr Utser
Wow, this is an impressive feat you have accomplished - I can't wait to try this out. The averaging on the current is badly needed; in my opinion the standard FW has the display updating so frequently that it is practically useless.
I have another request - do you think it would be possible to change the display format on either of the "Type 1" or "Type 2" display options? I find the default Type 1 display font is too small to read when the supply is more than about 2 feet away from me. The voltage and current readback (and wattage) are readable, but the set voltage and set current is very small. I'd like that to be in a larger font, which could possibly be done by removing the wattage measurement. The other option would be to change the Type 2 display format to include the setpoints - that mode has voltage & current that is very large. If those value would be made slightly smaller it would make room to have the setpoints displayed. I also think it would make sense to have the channels displayed as channel 4-1-2-3 in Type 2 to match the order that the output posts are in.
What do you think about my idea? If this would be too much work to go through I understand, just my thoughts on it. In my opinion the GPP4323 has 2 major flaws:
1. The voltage and current readings fluctuation WAAAY too quickly and make the correct values sometimes impossible to discern
2. The diplay really isn't big enough to display all the info needed for 4 channels. The type 1 has all the info, but it gets too small to read. I think by adding the set values on Type 2 would be a great help.
Thanks again for your work - nice job!
-
I upgraded my GPP3323. It's great.
Finally a display of usable current.
Great job.
THANKS
-
Now you can harness the power of the beeper :-/O
Mod version 1v01
New features:
• Beeper volume configuration
https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v01.zip/download (https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v01.zip/download)
SHA256 Size Name
---------------------------------------------------------------- ------------- ------------
965931AEC4BF49CF00CC55E383AFFE39664F1FB56A7F740CE9A981B5798470BA 67712501 gpp_mod_1v01.zip
2C96997A5DC36370660C86C946AA129203DB75C0C4E56B63450C64CE26C2A946 67509049 gpp_mod.exe
C6F1EF1A31A89A11F71214041F53B230924C44F5027262A99548C0B69D789B10 5915 gpp_mod.hex
A8AA614669198A5985E3481FCB825ED8E0042FB7FAD34F8C1CB120B6738C19A1 644742 gpp_mod.pdf
8D342E70B1484FA47937AE793B420345E573FC800C30F9B2BE3FE0AD8614A451 12551 gpp_mod.py
7F8EDBF4C1E3B96A3CB5C4F7B4C8D2A0D410986424B9BF592D312B0E7070F1C4 4090 gpp_mod_template.json
-
@ArcticGeek
What comes to mind is that with a Raspberry Pi it should be possible to collect all data and display it on a big screen in any layout. Not my cup of tea though.
To understand the UI screen structure it requires quite some reverse engineering effort. I am wondering if the embedded fonts are of the bitmap or vector type. The bitmap fonts are the simplest but produce poor results when scaling.
It looks like some space is available on the type 1 screen when pushing and shoving the fields a bit. The setpoint fields are editable. I have no clue if that requires nitty gritty details to be updated as well. It depends on how it is currently implemented. If it is just some kind of configurable widget then it could be relatively easy (depending on the flexibility of the widget).
-
@Pr Utser
Thank you for the response and for thinking about my idea. I guess I should have been more clear when I mentioned that the display is too small. I didn't mean to imply that I want to replace the screen, it's just that I think Instek is trying to display TOO MUCH info on the screen for the 4 channels. For me, the parameters that I am most interested in on the screen are the set voltage & current, the actual voltage & current reading, and whether the channel is in CV or CC mode. But Instek also put the wattage and the OCP and OVP display in the Type 1 display, and in my opinion it would be more useful to get rid of wattage, OVP, and OCP in order to make the font of the setpoints larger.
Just my thoughts anyway. Thank you again for the v1.01 version of your code - I can't wait to try it out but right now I'm busy with my real job and don't have much time for my hobby :)
-
Hi,
I have the GPP-4323 and the latest firmware 1.22.
I looked at the latest version of Pr Utser's (Nice Name :-) ) files and then I'm talking about 1.01 but don't see any *.bin file with it that is required to install via USB flash drive.
It is not clear to me at the moment how to proceed.
I have had the gpp_mod.exe file started, briefly a Terminal in view and then nothing....
Can you please push me in the right direction?
Regards,
Bram
-
I looked at the latest version of Pr Utser's (Nice Name :-) ) files and then I'm talking about 1.01 but don't see any *.bin file with it that is required to install via USB flash drive.
It is not clear to me at the moment how to proceed.
I have had the gpp_mod.exe file started, briefly a Terminal in view and then nothing....
If you double click gpp_mod.exe from the Windows Explorer, it will start but if there is an error (because of a missing file or something) you'll have hardly any chance to read it. Instead, you should start gpp_mod.exe from the Windows cmd.exe command prompt. In that case you'll be able to see the logging including error message. You can then copy&paste the logging to this forum for help.
Things that typically go wrong:
- GPPV122.BIN not found (by default it expects the file in the current working directory)
- Config file gpp_mod.json not found (you can copy gpp_mod_template.json, rename it to gpp_mod.json and then edit the settings with notepad to customize if needed)
- Typo in the gpp_mod.json file. The JSON parser is very narrow-minded about punctuation. No comma too many or too few is allowed :palm:
So being able to read the error message is key. It should point you in the right direction and otherwise you can post it here to get help.
-
Hi Pr Utser, :)
My thanks for responding quickly.
Now, do I understand correctly that I should put the "GPPV122.BIN" I downloaded at GW-instek into the directory where I also unzipped your zip file?
Then this GPPV122.BIN file will be modified with your settings?
Then I place the modified GPPV122.BIN file on a USB flash drive and do a normal upgrade of my GPP-4323?
If so, then I will perform that tomorrow. (als ik weer fris en fruiting ben :-DD )
Kind regards,
Bram
-
@blackdog,
The easiest way is indeed to put GPPV122.BIN in the same directory as where the files from the zip were extracted.
For a successful run, the directory must contain the following files:
- GPPV122.BIN << firmware file downloaded from GWInstek
- gpp_mod.exe
- gpp_mod.hex
- gpp_mod.json << copy of gpp_mod_template.json and can be edited with the Windows notepad application
By running gpp_mod.exe the following file is created (in the same directory):
- GPPV122m.BIN << firmware file created by running gpp_mod.exe and to be installed on GPP unit via USB flash drive
Success!
Prutser
-
I was able to succesfully build several different version of the GPPV122m.bin firmware - I was experimenting with different beeper volumes and built 3 different versions to give it a try - it worked fine.
I haven't played with the calibration settings yet, I'll dig into that when I have a bit more time in the next day or so.
@Pr Utser The voltage and current readings are SIGNIFICANTLY improved over the original FW and are much more stable. However, I still see a little bit of jumpiness in the least significant digit; jumping 2-3 LSDs every so often. Its still more jumpy than my Keysight and Fluke meters. Is there any way to increase the number of samples in the averaging?
Thank you again for a much improved FW!!!
-
Hi,
Making the meters too slow again is not good, I like to see reasonably quickly if there is variation anywhere.
The biggest adjustment in my thinking on this, came when I switched to Keithley DVMs instead of KeySight.
By default the Keithley meters are set to 1PLC, this is a bit too fast, but 5PLC I have now come to appreciate. and as needed and I want resources I use the extra filters that are available.
I hooked up a Keithley DVM to the output of the GPP-4323 and changed the voltage.
The output voltage responds immediately at 1V steps and the Keithley meter is almost immediately stopped again.
The meter on the GPP-4323 slowly ramps up to the value.
This can take up to 3 seconds for the last digit to stop.
With more averaging this time may be even longer, I will investigate and test this this afternoon.
Kind regards,
Bram
-
The Keithley 2000 multimeters, and likely also their later meters, are using a rolling average with a window. As long as readings stay within this window, a rolling average is applied. But as soon as a reading is outside this window, the rolling average is reset. This allows lower noise in displayed readings as long as the signal is fairly stable, but fast response (and more noise) when the signal is varying, like when you twist the knob of a power supply or short the output.
-
@Pr Utser The voltage and current readings are SIGNIFICANTLY improved over the original FW and are much more stable. However, I still see a little bit of jumpiness in the least significant digit; jumping 2-3 LSDs every so often. Its still more jumpy than my Keysight and Fluke meters. Is there any way to increase the number of samples in the averaging?
Hi @ArcticGeek,
With the gpp_mod 1v02 version, you will be able to configure the window size of the moving average filter.
Enjoy!
-
GPP mod version 1v02
New features:
• Configurable window size of first stage measurement filter (moving average filter)
• Added second stage measurement filter with configurable window size and reset threshold
• Configurable display update interval
• Added gpp_mod.cmd batch script for starting gpp_mod directly from Windows Explorer
https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v02.zip/download (https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v02.zip/download)
SHA256 Size Name
---------------------------------------------------------------- ------------- ------------
6911FEC2138C8BE5AD48123D9DF2B65C981E5B2EE8A4419855238D2B435E99E6 67718030 gpp_mod_1v02.zip
97752D0AEFAEB1F48A04F3AA54F511B6556FA7C8D8574528BA32292A8F58DC73 1217 gpp_mod.cmd
79B6442CB5CEEF5FA310513FEE55CB520F7654F6914D094CDE08BDDB7947ABFF 67509643 gpp_mod.exe
3F0BAE540E9E977C8B69D36091ADB7FDC577A2D104CF4EA0AE4D879FF793BC0A 8713 gpp_mod.hex
4B7E81EB97198624AE86CDD41FFB24C914B04469F7E34A320E9B9DBD96F6A2B2 649049 gpp_mod.pdf
1B93DC917E7BF75C07F4A1E83ADF46826B2A787EE7451C6B40337678047C78BC 14527 gpp_mod.py
F99B389E30A2576D7A1591D1EA755BBDCD16DDB9B9BFFE37B273C4BBE16453D9 5003 gpp_mod_template.json
-
@Pr Utser
Thank you!!!! This works great. What I finally settled with was a sample size of 192 and an update rate of 2 (ie, 200 msec) on just the current; I left the voltage settings unchanged. This seems to work pretty good for most things I am working with.
One thing where I really noticed an issue with the original FW was measuring the current of a small 80mm fan - the current readings fluctuated so much it was unreadable. After your improvement it works quite nicely.
Well done - thanks again for the work and effort.
-
Outstanding @Pr Utser!
Now my GPP-4323's current readings is readable :)
Nice work :-+
-
could you describe how you were able to modify the software ? What tools did you use?
-
@Dagobert1,
Hardware tools:
- Silabs WSTK board for the J-Jink debug connection (with built-in Segger license)
Software tools:
- Segger Ozone J-Link debugger
- Arm GNU toolchain (to build the gpp_mod.hex file from source code written in C)
First, I did some reverse engineering on the hardware to find the debug interface of the NXP chip. This allowed me to access the NXP chip with Segger Ozone and reverse engineer the firmware. The method I used is stepping through the assembly code to find subroutines and memory variables of interest. But I started by making flash memory dumps and comparing the data to the GPPVxxx.BIN firmware file from the GWInstek site. This way I found out which part of the code is bootloader and which part is application.
There where the original code processes the data from the channel controllers, I put in some assembly code hooks to link in my own code which is written in C. I used the Arm GNU toolchain to build gpp_mod.hex from the C code.
To find a specific function in the original code (such as beeper control or UART communication), I put data read/write breakpoints on the relevant peripheral registers. From those low level functions, I worked my way up in the call stack to find the higher level functions of interest.
After developing the gpp_mod.hex patches, I reverse engineered the bootloader a bit to find found out what is needed to accept a modified firmware image. There is nothing fancy with firmware authentication checks. Just a matching checksum and a header is all that the bootloader cares about. Luckily there is a recovery method to install firmware which justifies the lack of firmware authentication a bit.
I discovered the recovery mode when reverse engineering the bootloader. The method can be found in the gpp_mod documentation.
Now I am wondering @Dagobert1, are you thinking about modding something yourself?
Best regards,
Prutser
-
Thank you very much for your detailed description. I find it very interesting to be able to customize the firmware of measuring devices. I'm currently working on porting my Keysight/Agilent MSO9254 from Windows 7 to Windows 10 and I also have to find out what the problems are through reverse engineering. That's why I'm always interested in how others approach such problems. I also have the power supply and will try out your firmware. You should consider publishing your sources. Then other developers can also contribute improvements.
-
I'm using the latest (1v02) mod and I've encountered a bug when using channels 1 or 2 as loads on my GPP-4323. (Note that the bug I will describe does not occur with the stock GWInstek V1.22 firmware.) When using some channel to source into a channel configured as a load, the GPP's over-power protection on the load channel will eventually trip (after a longer delay when sinking lower watts, after a much shorter delay when sinking higher watts) and turn off the load channel with a warning about the input power exceeding the 50W capacity of the equipment. This behavior makes the load mode of CH1 and CH2 unusable.
Usually there is no indication that the 50W power limit was violated, but occasionally the victim load channel will display an impossible number in its power field when the OPP trips the channel to off. For example, here's CH1 configured to sink 15V and 1A from CH4 immediately after the OPP tripped:
(ugh eevblog ate the attachement :( )
CH1 claims it received 6.2289A--which would certainly trip the OPP--but the GPP-4323 cannot source that much current. Furthermore, here's an image of my DMM shortly after the OPP-trip event showing it monitored a maximum current of 1.001A (in the white statistics area immediately above the softkey legends):
[attach=1]
The CH1 power of 92.51W displayed above is reasonable if it actually received the 6A it claims, and one could conclude that the channel's OPP worked as designed. But I also have an unreasonable example for you.
Here's CH1 configured to sink 20V and 1A from CH2, immediately after the OPP tripped:
[attach=2]
I'd like to draw your attention to the impossible claim by CH1 that it somehow received 449.49W from 19.9915V and an alleged 2.2646A, thereby tripping its OPP. While it's possible for CH2 to deliver the claimed current, my DMM again showed a maximum current of 1.001A through the OPP-trip event (which, as you can see in the image of CH1 above, was the configured current to sink from CH2). Nevertheless, the power claimed by CH1 is nonsensical.
Has anyone else run into this behavior?
EDIT: I’ve noticed that when running the firmware mod, the device doesn’t seem to spool up its cooling fan much, if at all, and I can get the OPP to trip quickly at higher power settings. Meanwhile, with Instek’s stock firmware I can run CH2 into CH1 at 50W all day long (while its fan runs at top speed, of course).
-
Here's that first attachment missing from my post above:
[attach=1]
-
@Cavhat,
Thanks for reporting this issue. While trying to reproduce I found that the web server interferes with the measurement readouts. Luckily there is an easy fix for it. The bug will be fixed in mod release 1v03 which I will post next.
-
GPP mod version 1v03
New features:
• None
Bug fixes:
• Fixed measurement readout interference from web server (applicable for units with LAN option). Special thanks go to member Cavhat for reporting this issue.
https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v03.zip/download (https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v03.zip/download)
SHA256 Size Name
---------------------------------------------------------------- ------------- ------------
BD7BC2C4DA56360A50968F05E3B67AE65C4EA10327C938F29843C5FD8E0A7658 67705459 gpp_mod_1v03.zip
97752D0AEFAEB1F48A04F3AA54F511B6556FA7C8D8574528BA32292A8F58DC73 1217 gpp_mod.cmd
BB2825729841DB31ECB218EB5194DDAFACE654D4429AC6EA0BD69FA5B8BB43BF 67509643 gpp_mod.exe
51979F9122A0E9F0F10AE4A845F7BD90B1AFA0282871EA2930ED57813EBFC9B6 8824 gpp_mod.hex
BAFD515E11A7F2787C581C0C68E362084A6E175A9B199364B285DB8F344EA66A 636517 gpp_mod.pdf
1B93DC917E7BF75C07F4A1E83ADF46826B2A787EE7451C6B40337678047C78BC 14527 gpp_mod.py
F99B389E30A2576D7A1591D1EA755BBDCD16DDB9B9BFFE37B273C4BBE16453D9 5003 gpp_mod_template.json
-
@Pr Utser
Hello, I have a GPP-1326, this firmware can be directly upgraded to GPP-1326？？？
-
Hi @Wade2019,
I have not tested the mod on a GPP-1326 myself but I see no reason why it would not work.
The mod has been developed to support all GPP-x32x models.
Personally I tested it on a GPP-4323 with LAN option but without GPIB option.
Maybe others could comment on what they are using.
-
@Pr Utser, thank you for this amazing mod!
One question about calibration arising from the instructions:
Step 5.j says to repeat measurements with a 20V setpoint voltage. That's suitable for CH1 and CH2, but what about CH3 and CH4?
-
Good point @pcee.
You can choose a stable voltage just below the max output voltage of the channel. It will be fine as long as cal0 and cal1 have different voltage settings and the actual value is taken over in the voltage field of the cal section in the json file. The larger the difference between the cal0 and cal1 voltages, the better.
-
GPP mod version 1v02
New features:
• Configurable window size of first stage measurement filter (moving average filter)
• Added second stage measurement filter with configurable window size and reset threshold
• Configurable display update interval
• Added gpp_mod.cmd batch script for starting gpp_mod directly from Windows Explorer
https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v02.zip/download (https://sourceforge.net/projects/gpp-mod/files/release/gpp_mod_1v02.zip/download)
SHA256 Size Name
---------------------------------------------------------------- ------------- ------------
6911FEC2138C8BE5AD48123D9DF2B65C981E5B2EE8A4419855238D2B435E99E6 67718030 gpp_mod_1v02.zip
97752D0AEFAEB1F48A04F3AA54F511B6556FA7C8D8574528BA32292A8F58DC73 1217 gpp_mod.cmd
79B6442CB5CEEF5FA310513FEE55CB520F7654F6914D094CDE08BDDB7947ABFF 67509643 gpp_mod.exe
3F0BAE540E9E977C8B69D36091ADB7FDC577A2D104CF4EA0AE4D879FF793BC0A 8713 gpp_mod.hex
4B7E81EB97198624AE86CDD41FFB24C914B04469F7E34A320E9B9DBD96F6A2B2 649049 gpp_mod.pdf
1B93DC917E7BF75C07F4A1E83ADF46826B2A787EE7451C6B40337678047C78BC 14527 gpp_mod.py
F99B389E30A2576D7A1591D1EA755BBDCD16DDB9B9BFFE37B273C4BBE16453D9 5003 gpp_mod_template.json
Thank you for the additional features for the GPP-4323, having the ability to calibrate such is quite useful indeed :-+ :clap:
A question on how the two Moving Average Measurement Filter works, specifically how the Reset Threshold behaves?
Is this in Absolute Value Volts (Amps) wrt the Output of the 1st Moving Average Filter?
Best,
-
A question on how the two Moving Average Measurement Filter works, specifically how the Reset Threshold behaves?
Is this in Absolute Value Volts (Amps) wrt the Output of the 1st Moving Average Filter?
Indeed, the resetThreshold value is compared against |stage2FilterIn - stage2FilterOut|.
You can also state |stage1FilterOut - stage2FilterIn|, because the output of the first stage filter is the input of the second stage filter.
-
As the recent owner of a GPP-4323 I would first like to thank Prutser (goede naam!) for the firmware improvements! Much appreciated!
I also have a request, with absolutely no idea if this is easy to do or not:
The calibration settings make the GPP metering (much) more accurate, but they do not improve the value that is dialed in (say, "10.000 Volt" or "0.020 Amp") vs. what is actually coming out once the 'enable' button is pressed. Yes, you can immediately see from the measured values on the display what the actual is that is being produced, but it would be nice to align the requested vs. actual.
Mind you, it's not off by much. It's mainly in the lower ranges of mV and mA that it really would make a difference. For example, I was playing around with some LEDs this morning and dialed up a current limit of 20 mA. The actual is more around the 16 mA mark for me, on channel 1.
Maybe an extra parameter added to <channel1_voltageCal> and <channel1_currentCal> with something like voltageCalEntry:= { "set": <set_voltage>, “ref”: <ref_voltage>, “gpp”: <gpp_voltage> }, and currentCal:= {"set": <set_current>, “cal0”: <currentCal_subsection>, “cal1”: <currentCal_subsection> }.
So it would do linear interpolation to correct the set/dialed value towards the actual, and of course correct the metered to measured/calibrated.
As I said, no idea if that's easy to do within the firmware, but thought I'd ask.
Thanks!
-Rob-
-
I also have a request, with absolutely no idea if this is easy to do or not:
The calibration settings make the GPP metering (much) more accurate, but they do not improve the value that is dialed in (say, "10.000 Volt" or "0.020 Amp") vs. what is actually coming out once the 'enable' button is pressed. Yes, you can immediately see from the measured values on the display what the actual is that is being produced, but it would be nice to align the requested vs. actual.
This should indeed not be too hard to implement. For the current setting this makes more sense to me than for the voltage setting. However, when implementing it does not matter much to do it for both current and voltage. Not sure though what the unit is of the setpoints that are sent to the channel MCU's. Most likely it is mV and 100uA which would provide sufficient calibration resolution of +/- 1 digit.
I don't know when (or if) I'll be working the mod again. But I'll definitely consider your request in case I make a new version. Another thing in mind is to limit the setpoint when OVP/OCP is enabled. With the original firmware, the output can overshoot the setpoint before OVP/OCP kicks in. Not nice when noticing a typo after entering a new setpoint.
-
Hi all,
Thank you for the great work, Prutser.
I would like to install the mod on a GPP-2323, mostly to improve the current readout and take care of the annoying beep, but I can only get the most current firmware from GW Insteak (GPPV126.BIN), which is not compatible with the mod. Can anyone share the older firmware file (GPPV122.BIN) with me?
Thank you!
-
Hi all,
Thank you for the great work, Prutser.
I would like to install the mod on a GPP-2323, mostly to improve the current readout and take care of the annoying beep, but I can only get the most current firmware from GW Insteak (GPPV126.BIN), which is not compatible with the mod. Can anyone share the older firmware file (GPPV122.BIN) with me?
Thank you!
I've attached v1.22 firmware for GPP series multi-output DC power supplies.
-
I've attached v1.22 firmware for GPP series multi-output DC power supplies.
Many thanks, cte! I've already flashed the power supply and it's working great. :)
-
Hi Pr Utser;
When I was testing the maximum power of GPP-1326, I found that the OTP protection was on. After analysis, I found that after flashing your latest firmware, even though the radiator was at 60 degrees, the fan did not start high speed to dissipate heat, causing the machine to be protected.
-
Hi @Wade2019,
Is this in supply mode, load mode or either mode? Could you share more details about the test?
Did you also check the behavior of the original GWInstek version 1.22 firmware?
I just checked it on a GPP-4323 (modded v1.22 firmware) with channel 1 sourcing 49.75W into channel 2 as load. Within a few minutes, the fan RPM started slowly stepping up to what sounds like full speed.
So the fan RPM seems to be temperature controlled (closed loop control). There does not seem to be a feed forward based on actual power delivery/sink. I do not have the schematics of this supply so I am wondering if OTP is based on the temperature sensor of the control loop or a redundant one.
GWInstek does not provide any release notes with their firmware updates so I do not know what the fixes or improvements are.
The GWInstek website states that you need to update from prior to v1.16 to v1.16 first before any later update. Could be important, but the v1.16 is nowhere to be found on their website. My unit was already on a more recent version when I got it. I do not know what the consequences are if this intermediate step is skipped.
Best regards,
Prutser
-
Attached a copy of 1.16 if anyone needs it.
Does anyone have any idea what was changed from 1.22 to the current 1.26? (Assuming not - as mentioned above they don't give any changelog :palm:)
-
Hi@ Utser;
I tested the power mode and ran it at 33V 6A, but did not test the load mode. I found that the power module had OTP protection, and I carefully observed that the fan was not running at high speed. My software was indeed upgraded to v1.16 and then upgraded to your modified version v1.22 firmware. The official website does not have version V1.16 firmware. I have downloaded version 1.16 from other locations of GW Instek. Version 1.16 is included in the attachment.
The test focuses on full power operation