Thursday, October 29, 2015

[Random Teardowns] XL4005 5A step-down module with display

Device: XL4005 constant-current/constant-voltage buck converter with LED display
Origin: eBay / China
Reason for teardown: Project
Impressions: Ok so there isn't much to tear down on this given that it's just two PCBs screwed together with standoffs but oh well.

I got two of these for a project because they're just so cheap now. Supposedly they do 5amps and you get current limiting as well.

Already a bit modified



The modules themselves work reasonably well based on my limited testing. The display/monitor boards are pretty terrible though.

My gripes with them:
  • Horrible accuracy as-is and no calibration pot.  (FWIW you can hook up 10k trim pots to the two unpopulated resistor pads near the LM358 to fix this.)
  • Horrible resolution and pointless, wasted digits on the 7segment displays. (I'd take an extra digit over the lower-case u moonlighting as V ...)
  • Painfully slow update-rate
  • Serial feature poorly documented but also borderline worthless (see below)
All of these issues could be fixed in firmware. I'm almost tempted to get an ST-LINK dongle and reverse engineer the thing but it'd probably take about as much time as reimplementing the whole board using a microcontroller I'm actually familiar with and not bothering with the STM 8S003F3P6 it has which is to say: too long either way to be worth it. Anyone up for the challenge?

As for the worthless serial interface: the biggest issue is that the serial processing code takes too long to run and the micro isn't updating the screen while it's running so you get a really noticeable dip in brightness every time you send a query for voltage or current. And of course they're separate commands which compounds the problem.
If you're continuously polling the board with something you basically won't be able to see anything on the display.

If after all that you still want to use it, here's the info they give you:







Baud Rate : 9600 Bps
BB CC ADDR 00 XX XX CRC ( current return command )
 
BB CC ADDR 01 XX XX CRC ( voltage returns to the command )
Among
BB CC for the header ( 2 bytes )
ADDR for the module address ( 1 byte )
00 to read the current command ( 1 byte )
 
01 is a read voltage command ( 1 byte )
XX XX arbitrary value ( 2 bytes )
CRC CRC checksum ( 1 byte )


Not bad. CRC is undocumented though and ADDR varies with board revision. (0 and 1 definitely exists)
Serial is standard 9600bps with no parity, 8 data and 1 stop-bits with no flow-control.
 
The revision with ADDR 0 may ignore CRC as long as it's not 0 because these have been reported to work with it:

Get current: BBCC00000000B4
Get voltage: BBCC00010000DF

It also doesn't return a CRC in it's replies and returns voltage and current in millivolts and milliamps (so a higher resolution than it displays) which is nice.


ADDR 1 on the other hand checks CRC and also returns it in replies. A brute-force loop later I got two replies with CRC and it was pretty obvious that it's just a simple addition you take the least significant byte of.

So the proper commands for ADDR 1 boards are:
Get current: BBCC0100000088 (  BB+CC+01+00+00+00 = 0188 so 0x88 )
Get voltage: BBCC0101000089 (  BB+CC+01+01+00+00 = 0189 so 0x89 )

Unfortunately this revision of the board returns values in 100 millivolts and 100 milliamps so for 4 volts you only get the value 40 .. FAIL!
And in case you're wondering if there's maybe an undocumented command you could use to get a higher resolution value or maybe a raw ADC value.. there isn't.

So in conclusion:
ADDR1 boards give you a low resolution value in exchange for a flickering or completely unreadable display.
ADDR0 boards give you a higher resolution value and I'm not sure if the flickering is present or not. Anyone know?

2 comments:

  1. Hello, do you have any program to "brute-force loop"?
    I have 3 module types and no one respond in terminal.
    Also 2y ago I have other type that sent data continuously in format like:
    2.23V 1.23A

    ReplyDelete
    Replies
    1. I don't have the script anymore, sorry.
      It wasn't terribly complicated though, I just looped through the possible values for the addr and checksum bytes and wrote all the commands to a file then used CoolTerm's "Send File" option to send it all in bulk to the module. It was easy from there since it returned the correct addr and checksum in the reply for the ones it accepted.
      If your modules use this protocol you could do the same. The script shouldn't be hard to reproduce in your programming language of choice.
      If they're completely different and you have no info at all on them then reverse-engineering the original firmware is probably your only realistic option.
      Good luck!

      Delete