raplin / dps-1200fb Goto Github PK

Hey.

I'm currently adapting this to an Arduino, which is working just fine. link
But now i want to see Data from two PSUs which doesnt work. Im not sure how to use I2C isolators. Am I guessing correct if I say, that I need two of those: link
I imagine i would need to connect the i2c of one psu to one side of the chip and the arduino to the other?

I'm trying to get this working with smbus but I'm having trouble with the checksum list.

I changed this: return self.i2c.readVar(self.address,writeInts,count) to this:
return self.i2c.read_i2c_block_data(self.address,writeInts,count) but read_i2c_block_data is looking for an integer and not a list.

The error returned is an "integer is required" which has to do with the writeInts list.

What's the trick to passing the checksum when using smbus?

I'm able to read the eeprom using i2dump and can see the product info just fine.

In addition to 0x57 and 0x5f, I also see 0x4f.

Hi,

I creatd a circuit for controlling two PSU with opti isolator I2C for my rc hobby. I will publish it if I am finished e.g. it actually still works fine. But where I am unsure with DPS1200FB is:

1. PSOk is digital and not a analog value in with my DPS1200FB. Is that correct? Standby Status is not shown...
2. PS Interrupt/Alarm/... (Pin 38) is low everytime even on normal operation and indicated an error???

Actually I am thinking that it is a simple implementation of the Common Connector but is this the real normal behavior?

Regards,
Nils

When code is run a read error is printed. If code in modified then it shows the checksum is always off by 3 and any outputted data is garbage.

Hi!

I am opening this issue just to let you know that I am experimenting with the i2c bus using an esp8266.

Thanks to your project I have been able to calculate checksums and communicate with the PSU. I have spent a few days in different standard documents now, and I am starting to think that the DPS-1200FB is not using PMBus, but something else.

The communication seems to work fine. It is consistent and with less than .2% CRC errors. I can set and read fan speed. I have fuzzed the PSU with different bit-patterns and it has given me some clues to what some registers do (I have written my ideas in the .ino file).

It has fan speed at 0x20 (or 0x40 if you want the shifted values). All the PMBus specs I have seen has fan speed somewhere else.

Anyways, ideas welcome :) My src is at https://github.com/slundell/dps_charger/ Its just a first draft and is mainly full of redundant functions I use for experimenting :)
Best

I don't own one of these supplies so i can't test it, but in this documentation you state a high standby current of possibly 1+ A, but that sounds way too high, that would mean it wastes 12W in standby. could you get the input power in standby?

Not sure where to post this but figured you could add it to the collection. I got a PD30 with 2 PIC's on there!

https://drive.google.com/drive/folders/1T5wr3l3zmn4VAYcKgGfeoV2zda_dKJYr?usp=sharing

Ive gone through PMBus spec 1.2 and tried all the command codes and they do not seem to be working. command 37 seems to set fan speed on this one instead of 40

Hello,
I recently got my hands in two HSTNS-PL18 (750W version of the PSU) and started reading out data and experimenting with this code.
First thing I noticed is that the register named MIN_AMPS_IN should in fact be MAX_AMPS_IN. I guess you should have suspected it since the other two (power in & out) are also the maximum, and it makes no sense (for me) to keep track of the minimum input current.
The second thing I noticed was the temperature scaling. 32 did not cut it for me, even interpreting the result as degrees Fahrenheit, it was reporting freezing temperatures (~10 C) which is way off. One can easily find the correct scaling factor by taking a close look at the disassembly. here you can see the variable that holds the temperature being multiplied by 0x40 (64) before being copied to the RAM location that corresponds to the temperature register. If you read the register and divide by 64 you will get the temperature in Celsius, which makes much more sense! (25.9 C intake temperature)

I also noticed a couple of other small things, like wrong current and power scaling, but I have yet to confirm those by attaching a big known load to the supply. With the provided input power scaling factor I was getting 25 W quiescent which sounds like a lot for a PSU of this quality, and also did not match with the value I got when dividing the Watt-second energy value by the uptime register value (I get 12.25 W, which is very suspect, close to 25/2), but then again, the scaling for the Watt-second could also be wrong. By, once again, looking at the disassembly we can see that the input power is capped to a minimum of 0x32 (50), I don't know why. Also, I am pretty sure that surprise_more_flags, bit 2 is set when the input power is < 50 and is cleared when > 50, so it may indicate that the supply is not loaded (?). The output power seems to be capped too, at 36, but there isn't a flag to signal that.

Also, since I prefer using NodeJS than Python, I ported the essentials out of this code and uploaded a gist, if anyone is interested https://gist.github.com/vankxr/a7acad10b0ddfe273724b21b2dd46c1d