Voltcraft DPS-4005PFC Strange Voltage Readback

[TonyBe]

Dear Forum,

i've worked on a repair of a Voltcraft DPS-4005PFC Switching Powersupply. After solving several issues due to a short of both main switching transistors, i'm now able to set an output voltage. The current limiting works fine as well.

When turning the voltage up, i recognized that the voltage written on the display is roughly 1/10 of the actuall output voltage - while the current measurement is absolutely on point.

I thought of this issue to be solved very easy.. like a dead resistor which divides the voltage down to much. But then i've checked every resistor in the signal path to be fine. After analyzing the circuit a little further, i've recognized that the basic topology of the unit is quiet smart.

To get us all to the same point, let's have look at the schematics (https://drive.google.com/file/d/0BxilARsN_3FqUWxNbTl4WWE2eEk/view?resourcekey=0-2zYfrC0Jqb43xgG-HSZDkA):


One single DAC is used to set the output voltage, the current limit and for measuring the output voltage and current as well. For doing so, the DAC output is routed to two comparators (N11) on the right which are responsible for measuring current (upper) and voltage (lower) in SAR fashion. The two switches on the left side are switched when the DAC is giving target output voltage (upper switch) and current limit (lower switch). Looking at the DAC Voltage with no load at the output, shows the 4 stages of the time multiplex:



In the second "Vist" stage, you can clearly see the SAR fashioned approximation.
So far so good, now the weird thing:

The picture example shows clearly, that the DAC Value of the target Voltage equals the SAR DAC Value of the measurement. This makes sense to me, since they use the fullscale of the DAC (~10VDC) for controlling 0-40VDC output.  So why shouldn't they use a smaler range for the readback (and lost juicy resolution by doing so).
So an example from the actuall unit:
setting the output voltage to 20VDC, the DAC value in the first time slot is exactly 5V. The value in the second time slot is approximated to 5V as well. The display shows 02.01V. So: why is it so? I cannot understand how any other hardware fault can cause this issue.

I've further done two other things to check this behaviour. I've used my linear power supply to inject a voltage directly to the comaprators input by tapping of the wire of X15 on the right. When turning the voltage at this wire to 5V, i again get a reading of 02.01V. Further increasing the voltage clipps the DAC Value in the second slot at around +10V, which shows 03.99V in the Display approving once more, that this should be the 40V max (but 1/10 of it appears).

Since the Unit has a RS232 interface, i've checked the measured voltage values over that interface to make sure that it isn't just a display error. And jet again that exakt same results.

So my question here: is there anything left that could be hardware related? I cannot imaging that somebody changed the firmware on the MCU, since it's not available and the Lock Bit is set (so no read and disassembly is even possible). Besides that, why should somebody do this? 
I surely can ignore the decimal point, but that is not a nice solution either.

I'm looking forward to your suggestions, really appreciate it

Thank you all in advance, have a good time!
Tony

[TonyBe]

Hi Folks,

I've managed to find the issue and want to share it with you, since there is not much information on that unit out there.
The reason for the wrong measurement of voltage is due to an memory error on the connected I2C EEPROM Chip N3 (AT24C02). It seems that only the bytes who carried the calibration factor are corrupted since all other functions of the device are totally fine.

After dumping the EEPROM Image using a raspberry and i2ctools "i2cdump" i've started to repeatedly change the values of the limits and the measured current with the unit it self, dumping the memory again and compare it to the other dumped images. It became obvious, that the unit stores it's data in 16Bit format, LSByte first. An example: if the measured voltage is 21.05V (ignore the decimal -> 2105) it's representation in HEX would be 0x0839. The unit stores this value as 0x39 0x08.
By playing around like that for 5min, I was able to narrow down the possible memory addresses of the cal factor down to ~5 possible values. After that i've recognized, that one of those remaining byte-pairs was located at an byte-pair (addresses: 0xaa, 0xab), which was quiet a bit offset to the rest of the Bytes. Therefore i've started my trail and error at those values. And sure enough, after changing them to a random value, the voltage measurement was affected. After finding the right spot, it was simply a matter of cross-multiplication to get into the ballpark of the perfect value. To finishing the calibration, I combined some toggeling of the LSB and some trimmer pot (RP5) action, to get the accuracy over the whole 40V range within the spec.

If you facing a similiar issue, here is the EEPROM Image, that works fine for my unit:

Code: [Select]

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
80: 07 d0 03 e8 00 00 00 06 00 00 00 2a 00 5f 00 c3    ????...?...*._.?
90: 01 8e 06 3f 06 47 0c 96 0f bc ff ff ff ff ff ff    ?????G????......
a0: ff ff ff ff ff ff ff ff ff ff 0f 18 ff ff ff ff    ..........??....
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................

   

If you have an Raspbi, feel free to use my ultra-lazy-crude python script to flash it on the EEPROM:

Code: [Select]

import smbus
import numpy as np
import time

origin = [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,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,0xff,0xff,
            0x07,0xd0,0x03,0xe8,0x00,0x00,0x00,0x06,0x00,0x00,0x00,0x2a,0x00,0x5f,0x00,0xc3,
            0x01,0x8e,0x06,0x3f,0x06,0x47,0x0c,0x96,0x0f,0xbc,0xff,0xff,0xff,0xff,0xff,0xff,
            0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0x0f,0x18,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,0xff,0xff,0xff,0xff,0xff,
            0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff]

DEV_ADDR = 80
            
def blank():
    for i in range(255):
        bus.write_byte_data(DEV_ADDR, i, int(0x00))
        print ("Writing at Addr: "+str(i))
        time.sleep(.01)

def orig():
    for i in range(255):
        print (origin[i])
        bus.write_byte_data(DEV_ADDR, i, int(origin[i]))
        print ("Writing at Addr "+str(i)+" with Value "+str(origin[i]))
        time.sleep(.01)

bus = smbus.SMBus(1)

orig()

Make sure to check the device address of the I2C EEPROM!!

Hope I could help some one with this,
Feel free to contact me if you need further information on the repair of that unit. I've analyzed it quiet well (I think).
Cheers

Tony

[shakalnokturn]

Good thinking and congratulations on the repair, thanks for sharing.
I have a similar Voltcraft supply, it's working for now and seldom used. Let me know if you want a copy of the EEPROM next time I drag it out.

Once more the conclusion is that it can be worth making memory dumps of your favourite equipment while it's working.
Sometimes on top of having a copy on my computer, I'll go and solder a EEPROM copy to a ground plane in the equipment itself as a spare.

[TonyBe]

Thanks
Well if this is possible for you, it surely will be helpful. Feel free to post it here so that everybody can use it if necessary.

A few months ago I also run into the firmware issue which costs me weeks of repairing work to get to a firmware copy. So yes. Absolutely agree with you. Better have a copy as long as it is possible.

Regards
Tony

[avrusb]

Hi there,

I just finished solving a similar problem. The "McVoice SNNT4005PC" I got had a problem displaying proper values for actual current. It didn't get beyond 0.250 A on the LCD, setting current limit was working. So after changing some values here and there, setting address 0x0090 and 0x0091 to 0x01 0x8C did the trick. Without changing anything else.