Power Supply PS3005D / KA3005D RS232 protocol

[hexreader]

Can anyone help me out and shed some light on the RS232 protocol used on Velleman PS3005D PSU please.

Seems to be the same unit as Korad KA3005D.

I have seen this already http://sigrok.org/wiki/Velleman_PS3005D/Info ... but it seems to be related to the USB port, not the RS232 port, as far as I can guess.

I have sniffed the RS232 port and have worked out a few sketchy bits of information.

The following mikroElectronica C code seems to work well when writing.

Code: [Select]

// Operate Velleman PS3500D Power Supply
// 9600,8,n,1 with cross-over cable RS232
// for EasyPIC7 board with PIC18F45K22 fitted
// 8MHz crystal x4 PLL gives 32MHz clock
// turn on switches SW1-1 and SW2-1

// amateur code - use at your own risk - author accepts no responsibility for anything

// make up a cable DB9M to DB9M with the following three wires:
//     pin 2 Tx    to   pin 3 Rx
//     pin 3 Rx    to   pin 2 Tx
//     pin 5 gnd   to   pin 5 gnd

// This program sends a 24 byte message to PS3500D power supply
// PSU appears to send two 24 byte messages in reply
// one message just a byte or two after the send message
// a second message after 100mS
// can only guess at what information the messages contain
// cannot find any official information

// prototypes
void checksum_out();                              // calculate checksum

// power supply parameters
unsigned int volts = 300;                         // x0.01 Volts e.g. 400 = 4 Volts
unsigned int milliamps = 110;                     // milliamps

unsigned char txt_out[26];                        // transmit message is 24 bytes (0 to 23)
unsigned char txt_in[26];                         // receive message is 24 bytes (0 to 23)

void main() {
char n;                                           // general purpose counter

    UART1_Init(9600);                             // PS3005D power supply requires 9600,8,n,1
   
    while(1){
        Delay_ms(1000);                           // repeat control string every second
        txt_out[0] = 0xaa;                        // header
        txt_out[1] = 0x20;                        // header
        txt_out[2] = volts/256;                   // voltage x 0.01  high byte
        txt_out[3] = volts&0xff;                  // voltage x 0.01  low byte
        txt_out[4] = milliamps / 256;             // milliamps high byte
        txt_out[5] = milliamps & 0xff;            // milliamps low byte
        txt_out[6] = 0x00;                        // ?
        txt_out[7] = 0x00;                        // ?
        txt_out[8] = 0x00;                        // ?
        txt_out[9] = 0x00;                        // ?
        txt_out[10] = 0x00;                       // ?
        txt_out[11] = 0x00;                       // ?
        txt_out[12] = 0x00;                       // ?
        txt_out[13] = 0x00;                       // ?
        txt_out[14] = 0x01;                       // 01 for ?, 00 for ?
        txt_out[15] = 0x01;                       // 01 for output on, 00 for output off
        txt_out[16] = 0x01;                       // 01 for ?, 00 for ?
        txt_out[17] = 0x00;                       // ?
        txt_out[18] = 0x00;                       // 01 for OverCurrent Protection on, 00 for off
        txt_out[19] = 0x00;                       // ?
        txt_out[20] = 0x00;                       // ?
        txt_out[21] = 0x00;                       // ?
        txt_out[22] = 0x00;                       // ?

        txt_out[23] = 0xc2;                       // dummy checksum (ignored)
       
        checksum_out();                           // calculate a real checksum for byte txt_out[23]
       
        for(n=0;n<24;n++){                        // 24 bytes in total
            UART1_Write(txt_out[n]);              // send each byte to UART
        }
       
        //while(!UART1_Data_Ready());               // wait until data is received
        //UART1_Read_Text(txt_in, "zz", 24);        // reads 24 text bytes ("zz" will never be found)
        volts++;                                    // just for fun
        if(volts > 3000){
            volts = 3;
        }
    }
}

// calculate a checksumm by adding bytes 0 to 22
// result goes to byte 23
void checksum_out(){
char n;
unsigned char chksum;

    for(n=0;n<23;n++){
        chksum += txt_out[n];
    }
    txt_out[23] = chksum;
}
You may, or may not want to follow my progress here: http://www.libstock.com/projects/view/1016/easypic7-control-velleman-ps3005d-power-supply-korad-ka3005d

...but I would love to have a better understanding of the protocol.

Is there anyone out there that knows any more than I do please?

Many thanks,

[biot]

Hi,

I'm one of the people behind the sigrok project, where you found the protocol description you linked to.

What you found doesn't match that page's protocol in the slightest. It shows an ASCII-based protocol, but you found it to be 24-byte packet based. But this seemed familiar, and sure enough, here's the protocol:

http://sigrok.org/wiki/Atten_PPS3000_Series#Protocol

As it happens I wrote that page, and the sigrok driver that implements that protocol. It all works quite well.

Now we need to figure out whether that PS3005D page is just wrong, or if Velleman has shipped completely different models with the same name. Both are possible :-(

[hexreader]

@biot

How can I ever thank you enough?   You are wonderful - this fits perfectly.

I can progress with my project now.

Thank you

[hexreader]

Now for the next problem...

There seems to be some cross-talk between transmit and receive.

My suspicion is that the cross-talk happens within the PS3005D power supply itself, but I have not yet gained any evidence for such an assertion.

When connected to PC, cross-talk (as seen on an oscilloscope) is minimal, and there are no obvious problems.

When connected to EasyPIC7 development board, I receive three messages as replies, instead of one, confirmed by an oscilloscope.

Loading the Tx line up with a 150 Ohm resistor reduces cross-talk enough to prevent the first erroneous message, but still leaves what looks like a repeat of the sent message, delayed 100mS, and then a good 24-byte return message 100mS after that.

Not really expecting anyone to come up with a fix for this (but it would be nice if there was one). I will filter out the extra messages in software.

I am just wondering if anyone else has had similar difficulties?

[biot]

I've had confirmation that the Velleman PS3005D page at sigrok.org really does work with the protocol at that page, by the guy who wrote it up. So it looks like Velleman has been shipping entirely different units under the same model name.

I also found this post: https://www.eevblog.com/forum/testgear/need-advice-on-a-new-oscilloscope-1500-dollar-budget/msg380866/#msg380866

You might reasonably assume Velleman changed suppliers from Korad to Atten.

[hexreader]

thanks biot

You really are great 

I am happy now.

Thanks to you, I have succeeded in doing everything I want to in the way of communicating from PIC microcontroller.

The PC software is truly terrible, but luckily that does not bother me.

It is interesting the way that there are very different models with very different characteristics.

[hermankopinga]

Thank you for the information in this thread! I'll add to it for other Googlers finding this.

Although I let myself be misdirected by the information on http://sigrok.org/wiki/Velleman_PS3005D (and I'm stubborn) so it took me hours instead of minutes to get going. This you got me in the right direction and now everything seems to run like it should with pps-tools via USB on a Raspberry PI.

Things to note about the/my new? revision of the PS3005D from Velleman:

• It shares the lsusb -v identification with the previous model (still based on the same Winbond chip). This made me more stubborn than I needed to be.
• Connecting with serial (9600,8,n,1) and sending it some text does make it beep (if interface is not set to silent) and lock the front interface but doesn't respond with any serial data. It unlocks after a couple of seconds. This is the best way I can think of now to identify this model.
• It works beautifully with the https://github.com/mturquette/pps-tools from the Atten page on Sigrok: http://sigrok.org/wiki/Atten_PPS3000_Series#Protocol
• On the software-cd I got with the devide there is a file PS Series Communication Protocol 1.3.pdf that describes the older protocol, not the one for my device.
• I bought it in a brick and mortar store Okaphone www.okaphone.nl in the Netherlands about 2 years ago.
• My device has serial number 008150006780, this curiously is lower than de photographed device on http://sigrok.org/wiki/Velleman_PS3005D

http://sigrok.org/wiki/Atten_PPS3000_Series#Protocol
As it happens I wrote that page, and the sigrok driver that implements that protocol. It all works quite well.

Thank you for that page. I think it would help if you add a remark to the page that it also supports newer versions of the Velleman PS3005D (1 channel, 0-30V, 0-5A). And perhaps a note on the page for the PS3005D? I was on my way to add it myself but I'm not that comfortable with IRC.

Now we need to figure out whether that PS3005D page is just wrong, or if Velleman has shipped completely different models with the same name. Both are possible :-(

Given the information in this thread and my experience: 2 different models with the same name.

Thanks!

[nuno]

There's at least another related thread:
https://www.eevblog.com/forum/testgear/korad-ka3005p-io-commands/

[biot]

Thank you for that page. I think it would help if you add a remark to the page that it also supports newer versions of the Velleman PS3005D (1 channel, 0-30V, 0-5A). And perhaps a note on the page for the PS3005D? I was on my way to add it myself but I'm not that comfortable with IRC.

So done. Life is like a box of Velleman: you never know what you're gonna get.

[dsandber]

Just wanted to post something to help the next person --- if you're trying to control a LABPS3005DN over the serial/USB port (perhaps with pyserial or some-such), and you look at the manual and it says to send a command like:

STATUS?\n

the "\n" is not a new line.  That would make sense.  No, it is a backslash followed by an n because the developers of this protocol are sadists, or more charitably, idiots.

You're welcome