Firmware mod for GWInstek GPP series lab bench power supply

[Pr Utser]

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

[coromonadalix]

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

[Pr Utser]

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


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

[Pr Utser]

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.

[ArcticGeek]

@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!

[bux98]

I upgraded my GPP3323. It's great.
Finally a display of usable current.
Great job.
THANKS

[Pr Utser]

Now you can harness the power of the beeper

Mod version 1v01
New features:
• Beeper volume configuration

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

[Pr Utser]

@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).

[ArcticGeek]

@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

[blackdog]

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

[Pr Utser]

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

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.

[blackdog]

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  )

Kind regards,
Bram

[Pr Utser]

@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

[ArcticGeek]

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!!!

[blackdog]

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

[alm]

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]

@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!

[Pr Utser]

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


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

[ArcticGeek]

@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.

[rattnallen]

Outstanding @Pr Utser!
Now my GPP-4323's current readings is readable
Nice work

[Dagobert1]

could you describe how you were able to modify the software ? What tools did you use?

[Pr Utser]

@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

[Dagobert1]

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.

[Cavhat]

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):



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:



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).

[Cavhat]

Here's that first attachment missing from my post above: