GW instek PSP-series new revision (PSP-405) PSU calibration

[wraper]

I bought faulty GW instek PSP-405 PSU from Toploser recently. The issue is it outputs 60+V when anything above 20V is set and then goes into protection mode. This is the new revision with completely different control board (V05) which is now is placed instead of display/button board. Empty space where old control board was previously. And no pots on the PSU board. I found that this high control voltage is set directly from MCU DAC output pin (voltage just jumps up on it), so this should be corrupted calibration or something like this. There is another issue with it, sometimes I hear weird sound from PSU board and it apparently causes some power glitch and PSU restarts, I guess this is what caused CAL corruption. No reason to spend time investigating that unless I fix output voltage issue.
Does anyone know how to calibrate this PSU? It is completely different from the older units as those where adjusted by 4 pots on the PSU PCB.

[wraper]

UPDATE. It's certainly corrupted calibration. I soldered empty EEPROM and it works fine. Calibration is a little bit off, though. So I still need to know calibration procedure.

[Zucca]

Looks like this one is similar to the Voltcraft 4005.

I googled it and jumped in Germans forum where everybody was unhappy with the quality and some reported an EEPROM corrupted failure.
No traces of calibration procedure.

I think you need one or two gentleman who will read out their EEPROM and move on from there.

[wraper]

Yes instek is sold under other brands as well. EDIT: Voltcraft 4005 apperantly have same or similar CPU board as old revision of PSP-405 but otherwise it's different, PSP series are sold sold as RS Pro, ISO-TECH and others. I also have older revision PSP-405 made in around 2014, it also has EEPROM but dunno if it contains any CAL data as there are 4 pots for this. I found CAL procedure for that one http://docs-europe.electrocomponents.com/webdocs/1465/0900766b81465d8d.pdf. Probably they are talking about that older revision.
EEPROM should have only small corruption and has correct calibration when it works, the question is which byte is corrupted.

[wraper]

BTW about weird sound from power board. Seems it's gone, likely it was just MCU doing something weird with controlling power board. I also checked internal power rails when it was crapping out and they were stable. Sent a message to Instek support, will see what they'll say about adjustment manual.

[wraper]

I think you need one or two gentleman who will read out their EEPROM and move on from there.

I found 2 bytes which affect calibration on >18V range. However I cannot understand how to adjust them. I get voltage jumping higher/lower when adjusting voltage, staying max all of the time when 18+V set or staying low depending on values in those 2 bytes. There is also one byte that apparently indicates there is no voltage cal, if I set that to 0x00 instead of 0x01, default voltage cal is used independent on cal values and then it works fine. Having working EEPROM dump certainly would be very useful to understand how those values work.

[Zucca]

I found 2 bytes which affect calibration on >18V range.

Post your results details, and magically you will have lot of EE brains around the world trying to understand what is going on.

[wraper]

First is corrupted EEPROM. Second is dumped after starting with a clean EEPROM. If I change 0x00 to 0x01 on a clean EEPROM, cal becomes weird and voltage jumps around when you adjust it, so restored cal values are not fine. If I change 0x01 to 0x00 on corrupted EEPROM, Voltage cal becomes default, exactly as with clean EEPROM. Current CAL remains intact in this case. So, I guess, that byte indicates if voltage CAL was done. BTW MCU is m430fg4617 unlike with older revision.

[Zucca]

pfff now it´s hard work.

cal becomes weird and voltage jumps around when you adjust it, so restored cal values are not fine.

any red line in this jumping around? Is it just random stuff?

[wraper]

any red line in this jumping around? Is it just random stuff?

It just jumps higher and lower somewhere within the the full range when I add 1V at a time. I guess, could be overflow during calculations. If I had working values then there would be starting point to play with calibration. So far I tried adjusting that few tens of times but with results as said earlier:

I get voltage jumping higher/lower when adjusting voltage, staying max all of the time when 18+V set or staying low depending on values in those 2 bytes.

I don't have days of free time to do nothing but stupidly brute force that. So far I noticed that if I set values on high side, I get all low out, and high if values are on the low side. Jumping around if something in around the middle.

[TopLoser]

I have 2 working latest version PSP-405 units. I'll take the EEPROM out and read the contents for you.

[TopLoser]

24C08 contents of a latest version PSP-405 attached.

[wraper]

Thanks a lot Ian  . Today also got a reply from GW Instak after waiting a week, where they said:

we could not provide adjustment manual to end-user, you may contact the distributor who sold you the device for help.

I guess they did not expect such help  .

[wraper]

Managed to calibrate almost spot on, 50 mV off @ 40V by tweaking 32h. as fine adjustment as it gets. Adjusting 33h makes voltage jump. Still need to find byte for finer calibration.
EDIT: got it down to 1mV. Apparently there are two 32 bit coefficients in little endian for <18V and >18V. adjusted both of them. Still there is around 10mV offset at very low voltages. Should be separate adjustment.
There is also a quirk for both PSUs related to current measurements. Newer revision reads 5 mA higher current at low set voltages than at max voltage. Old revision has it exactly opposite. Also when I adjust current limit at old revision I have 2 choices - either correct low current readout at low voltages and +8mA constant current offset or correct CC and -5mA offset , impossible to adjust both to be exactly precise.

[Zucca]

Congrats!

[Armadillo]

by tweaking 32h. as fine adjustment as it gets. Adjusting 33h makes voltage jump.

It suggest that calibration data are parity and checksum encoded, and such tweaking will leads to oblivion unless you decode the encoding.
It wouldn't be just poking the bytes.

[wraper]

by tweaking 32h. as fine adjustment as it gets. Adjusting 33h makes voltage jump.

It suggest that calibration data are parity and checksum encoded, and such tweaking will leads to oblivion unless you decode the encoding.
It wouldn't be just poking the bytes.

There is no checksum. And CAL works fine.

[Armadillo]

by tweaking 32h. as fine adjustment as it gets. Adjusting 33h makes voltage jump.

It suggest that calibration data are parity and checksum encoded, and such tweaking will leads to oblivion unless you decode the encoding.
It wouldn't be just poking the bytes.

There is no checksum. And CAL works fine.

I was hoping that this brand of instrument is somewhat reputed, though not in the same rank and file with names like Agilent, Tektronix or even fluke... but to imagine that the programmer did not checksum or parity encode the calibration data for integrity checking before starting up is somewhat insane, so to speak.... if that's true, then we should drop the brand by mere reason that it is startup unsafe. Furthermore the ripple voltage is as huge as like the elephant boogies..

[wraper]

Furthermore the ripple voltage is as huge as like the elephant boogies..

It's a switch mode PSU, no surprise there.

[albin]

Sorry to bring and old thread to life, but it didn’t seem right to start a new one on this topic.

I have a faulty PSP-405 of this revision with a Texas Instruments MSP430FG4617 CPU on the Display/Buttons board (DPS CPU Board V05). When I turn it on, the backlight goes on, and in the bottom left corner the ”remote” and ”0000” segments are on (only 0000, not ”W” segment”). All the voltages seems ok, the oscillators are working, and the RST pin is high. I’m starting to suspect the EEPROM.

The circuit I’m guessing is the EEPROM is located in U2 and is marked ”ATML830 08B 1”. I can’t find much information on this circuit though.

From your  experience I guess that this can be replaced with a standard 24C08 if needed.

Wraper and TopLoser: Did you manage to read the data of the EEPROM without de-soldering the circuit? De-soldering it once is fine, but it will be a hassle calibrating using this method if the chip has to be de-soldered to be programmed. Was your EEPROM marked ”ATML830 08B 1”, or am I missing something?

[wraper]

Wraper and TopLoser: Did you manage to read the data of the EEPROM without de-soldering the circuit? De-soldering it once is fine, but it will be a hassle calibrating using this method if the chip has to be de-soldered to be programmed. Was your EEPROM marked ”ATML830 08B 1”, or am I missing something?

I desoldered it. When experimenting with calibration I soldered dip socket and used EEPROM in DIP. Your EEPROM is AT24C08B.

[coromonadalix]

Could j4 be an serial port with an unpopulated IC1 as rs232 transceiver   since it is written PC   maybe something could be done with this ?

[albin]

Could j4 be an serial port with an unpopulated IC1 as rs232 transceiver   since it is written PC   maybe something could be done with this ?

My thoughts exactly. There's probably a uart in J4, and maybe in the 7x2 header as well since there's obviously an easier way to do calibration than to reprogramming the EEPROM manually. The question is how likely it is that the protocol is easy to determine. Probably not an ascii based protocol, or at least not to easy to guess commands.

[albin]

I desoldered it. When experimenting with calibration I soldered dip socket and used EEPROM in DIP. Your EEPROM is AT24C08B.

Thanks for your help wraper! I was so sure that the EEPROM was corrupted, but as it turns out I probably have another problem. Just to be sure I borrowed an EEPROM from a working PSP-405, but this made no difference at all. After returning the borrowed EEPROM and re-soldering the original EEPROM on the broken board, I powered both units to see if there’s any noticeable difference. A big difference between the boards is that LED2 above the EEPROM is blinking fast on the broken board, but not blinking at all on the working board.

Since the display is saying “0000 remote”, I built a d-sub cable and connected the working unit to my computer. I sent a few commands to put the working unit into “remote-mode”, but LED2 was still off so it’s not indicating that the unit is controlled remotely.

I connected the d-sub cable to the broken unit instead, to see if there was any message being sent from the unit when powered up. Turns out that there is a message being sent on this port! Not at 2400 baud as is usually used for communication, but at 9600 baud. The message being sent at power up is “Check Again....Erase Flash....Update Ready !”. There’s no noticeable delay between these words. I’ve tried to send commands to the unit, but the only response I get is “Revice Error!”, over and over again no matter what I send. Yes, it says “Revice Error!”, not “Device”.

Seems to me like the CPU is stuck in some bootloader mode. I’m not sure if this unit has ever been working. If it has, it wasn’t for long, and now it’s been standing on a shelf for a few years.

I’ll try to see if there’s any short of some sort which could cause it to stop the bootloader. There are a few unmounted jumpers on this board which could potentially be used to enter bootloader mode. If I can’t find any difference between this board and the working board, I’ll try to read the flash in the MCU. It’s probably locked, but it’s worth a try.

[coromonadalix]

“Revice Error!”, not “Device” ..... maybe Receive error ??

[albin]

“Revice Error!”, not “Device” ..... maybe Receive error ??

Maybe! Definitely makes sense.

[wraper]

If it is stuck in bootloader, I guess you could try asking GW instek if they can send you a firmware update. Pot luck, but who knows.

[wraper]

BTW I would certainly check if both oscillators operate at correct frequency.

[albin]

BTW I would certainly check if both oscillators operate at correct frequency.

Rechecked the oscillators. 8 MHz ~2Vpp, 32.768 kHz ~200mVpp. Not much difference between the working unit and the broken unit. Measured the resistance of the unmounted jumpers. About 10.8 kOhm on both jumpers, same on both units.

I thought that I would be able to read/write MSP430 MCUs using a TI XDS100v2, but for some reason this is not possible. Apparently I need a TI MSP-FET430UIF, Olimex MSP430-JTAG-TINY-V2 or similar. Since it's unlikely that it's easy to read the flash, it's probably a waste of money buying an adapter solely for this purpose. Have to give this some thought.

Time to write an e-mail to GwInstek, even though it's highly unlikely that they want to help. Maybe at least the unit can be repaired somewhere for less money than it costs to buy a new.

[vintagepc]

I realize this is a bit of a necro but I think it beneficial to keep all this info together rather than spread across several posts.

My PSP-2010 is suffering from bad current cal, and with the info here and some i2c sniffing I think I've been able to reverse-engineer some of the EEPROM structure. (https://www.eevblog.com/forum/repair/gwi-psp-1020-repair/)

There are still gaps missing/unknown because I don't know what they correspond to, and there are some guesses (like the number of coeffs for V/I ... but I'll just drop this here for reference.

Alas it appears my cal is blank (bytes 18h and 40h are 0). This may be my fault for seeing what happened if I poked the un-populated jumpers on the front PCB, or it may have already been like that. AFAICT the offset is still the same as it was when I got the supply, so I think the latter. Alas, this also means I do not know what the calibration coefficients should be; it is an analog op-amp system so it could be as simple as the direct millivolt readings the MCU gets from these lines.

There's a doc out there for the PSH series that details calibration over GPIB, and these systems have a set of parameters based around the extremes (min V, maxA, maxV, minA, etc). so maybe that is also the case here.

This snippet is all that was read from the ROM at startup, (FFs were not accessed). Values are consistent against the psp-405.hex file posted in this thread earlier.

Bonus: It may very well be possible to change the V/I ratio of these supplies by altering byte 0xC0. I'm guessing the series is just a 200w SMPS and the max voltage determines the max current (20V@10A, 40V@5A, 60V@3.5A)

[vintagepc]

After dumping the EEPROM fully, my suspicion on the calibration parameters is that they are pairs  measured at half and 1 "unit":

e.g. for a 20v,10A unit, the 4 vcal parameters are:
voltage
10v
1v
10v
1v
current:
5A
1A
5A
1A

The dual pairs are, I think for readings across the range, e.g. 1v/10v at both min and max (or half, if the trend is to be followed?) current.

The first value of the pair being the measured value from your external measurement gear (e.g. 10.01... 0.999). The second coefficient I have not yet determined its origin as I do not have valid data to base it off. But in my current readings, the values I get on-screen for it at min/max V and 0 amps are suspiciously close to the raw values in the dump. I'm going to poke in some values and see what I get.

 

[vintagepc]

Update:
I had it backwards. I currently believe that the "coefficient' is the correction value.

for v-cal I believe the first set of parameters is meant to be for voltage under load, the second pair is no load. It may help to disconnect the current readback (orange wire in the larger header) to peg it at 0 while doing this part of voltage cal to avoid interpolation offsets.

For example, if my unit says 10.00v and delivers 9.8, Voltage coefficient value 1 or 3 is going to be -0.2 (i.e., measured - set value)
The "cal" item (first in the pair) is a display/readback correction value (e.g if the system is set to 10v, outputs 10v, but reads 9.8v on the display, then adjust this number to bring it back in line. I believe it is just set to what the display is actually showing when the setpoint is being output.

Byte 0x40 is indeed current calibration. it turns out my current cal was actually still intact. *but* the unit will clear the current cal flag if the voltage calibration has not been done.