Author Topic: Power supply ripe for the picking  (Read 9762 times)

0 Members and 1 Guest are viewing this topic.

Offline peepsalot

  • Contributor
  • Posts: 6
  • Country: us
Re: Power supply ripe for the picking
« Reply #25 on: April 26, 2021, 05:24:56 pm »
Well I went ahead and picked up one of the newer HM310T from amazon.

I figured I'd post some teardown pics in case anyone is interested.


Display in startup mode (bad color rendering is camera's fault.  eg red display is actually deep red, not pink as it appears. LED colors overall are quite pleasant)

OK, lets peek inside


Main board.  It does look pretty much the same as in the product pic which seemed to show the "305" board.
I guess the PCBs are re-used with just some of the power handling components being different across them (primary transformer, toroid, maybe some others)  I suspect the 310 transformer is same footprint, but a little taller?

edit: Forgot to mention there's also curious unused 2 pin connector labeled "COM" below the fan connector(and in the same style), which is maybe barely visible in the pic.  I wonder if there's even a secondary way to communicate with the power board?


"Overhead" viewpoint (relative to the case) of the mainboard.


Just three heatsinked components
1x SR20200CT dual schottky
2x "13N50SJ" MOSFETs  (by "EST"?, not sure what that logo is)

Heatsink is plain aluminum plate, with a 90deg bend at the bottom to mount to steel case.


MOSFET closeup


Bottom of heattsink, attachment to case


Looks like a thermistor to monitor heatsink temps


Back side of heatsink, solid plate except for two cutouts which seem to only have purpose of indicating the 110V version of PCB?
Ground "output" jack wire mounted on left, mains ground on the right.


Output jacks with some caps. 
Looks like each side has one each of 1nF, 4.7nF, 10nF, and 100nF
And a 220uF 50V electrolytic in the middle.


Quick look at the power supply for the USB charging ports.  Seems to be some sorta generic module "CA08B" just popped in there.  Construction style/quality seems different than rest of the unit.


Rear of the USB charging board.  Solder mask seems to have "fingers" extending around all the pads that make it a bit odd.

The output wires and that resistor seem a bit of a mess



PCB for front USB charger jacks, doesn't seem to have any data pins connected.  its dual USB type-A and claims 5V 1.5A, but I guess you won't get more than 500mA "slow charging" in most cases since there's no power negotiation?


Quick peek at other side of USB port PCB, not much to see, just one cap.


Rear panel with USB communication interface, fused input (250V 5A iirc), and fan.

All these plugged connectors in white were secured annoyingly well with some very stretchy rubber cement.  I didn't remove this one, but for the others around the front I found an x-acto around the seams helped a bit, and a flathead to pry them off.


Front panel overview with display pcb, power output jacks, USB charger ports, and power switch.


DIsplay PCB. 
The 4 pin connector on the left goes straight to the rear USB communication port.
Largest package IC is TM(Shenzhen Titan Micro Elec) TM1640 LED driver for the 8 segment displays.
The smaller SOIC is a TM1650 LED driver + "keyboard scanner" for handling the button inputs and lighting I suppose.


Main MCU: Nuvoton "NUCO29LAN" Arm Cortex M0 32bit microcontroller


Unconnected 5 pin 0.1" header labeled J6, (maybe could be used to reprogram the MCU if someone were so inclined?)


Other side.  All the buttons have LED indicators except OVP and OCP.
Knob has basic 20 position rotary encoder with clicky switch.


A bit of a stray component lead was magnetically stuck on, plus a tiny circular shaving (looked like from tapping a screw thread).
I guess someone forgot to wash the speaker  ;)

Also, I only briefly actually tested the unit and twiddled the knobs a bit (all post-teardown of course  ;D ), but I never heard any beeps, not sure if its off by default or I just didn't exercise the particular use-case to activate beeps.  I should maybe look at the manual eventually


Front panel again, with output on, and leads shorted.  It let me set current up to 10.10A (and voltage to 32V)

Well hopefully someone found that interesting or useful.  If anyone is curious about some particular component part numbers that I may have glossed over, let me know.  I had some more pics and notes about other part #s and even started collecting datasheets, but I figured it was maybe all a bit boring and pointless to go into too much detail unless someone plans to hack this thing in some way.

I still have yet to test the PC connectivity, if its using same protocol etc as previous versions.
« Last Edit: April 26, 2021, 05:36:56 pm by peepsalot »
 
The following users thanked this post: HerbTarlek

Offline peepsalot

  • Contributor
  • Posts: 6
  • Country: us
Re: Power supply ripe for the picking
« Reply #26 on: April 30, 2021, 12:15:35 am »
I was probing around and found that the unused "COM" 2-pin connector (JST-XH i think) seems to have constant ~10.5V on it, so I guess it's a "Common rail", rather than communications that I originally suspected.
The voltage doesn't seem particularly stable though, I measured 10.2 - 10.6 over a few different power cycles.  Anyways, kinda neat you could add some little modules and tap that power source if you needed it.

I've also done A LOT of messing around with the communications based on the hm305.py script posted earlier in the thread, and I ended up making many modifications to the script to see if I could find any more secrets about the device.

Firstly, from everything I've seen so far, the serial interface on my HM310T is 100% indistinguishable from a HM310P.
It reports the exact same Class ID: 0x4B50 ("KP" in ASCII, btw) and Model Number: 3010

So, one of the first things I tried after studying up on modbus, was reading multiple contiguous registers (up to 125 at a time) , and I found that the device responds just fine.  Its the same modbus Function Code 3, just request a count > 1.
This can greatly speed up reading various values as long as your registers are close enough together.

Then I started trying to dump all 65536 possible register addresses, at a maximum per request, although I had to increase the timeout when requesting so many.  Timeout was 0.1s, and I bumped it to 0.5s.
...and then I realized each read command was slowed down by this timeout value (even reading a single register).

So I optimized the function for receiving the response packets.  The way it originally worked was to read one byte at a time from the serial port, until no more bytes remained (which is determined when the serial read times out).
But if you know the expected number of response bytes (2x register count + header and crc bytes), then you can instead read the exact number of bytes, and return without waiting for a timeout.  It is still able to timeout in the event that the device sends less than the expected number of bytes, i.e. an error response.

Now reads were really speeding along (well, as much as they can on a 9600 baud connection) and I found I can do a full dump of all registers in under 3 minutes.

So I made a dump, split the results into lines of 16 registers (a mostly arbitrary number for display purposes) and printed out any line that contained a non-zero register value.
There weren't actually very many total lines, so I'll just show a full example dump here.  Address offsets are in hex, but all register values are decimal representations of 16bit unsigned integers:
Code: [Select]
Offset  --00  --01  --02  --03  --04  --05  --06  --07  --08  --09  --0A  --0B  --0C  --0D  --0E  --0F
@0000:     0     1     0  3010 19280   563     0     0     0     0     0     0     0     0     0     0
@0010:    18  4329     0   779     1 12386     0     0     0     0     0     0     0     0     0     0
@0020:  3210  9999     4 47856     0     0     0     0     0     0     0     0     0     0     0     0
@0030:  1234  4321  3111     0     0     0     0     0     0     0     0     0     0     0     0     0
@0040:  3200 10100     0     0     0     0     0     0     0     0     0     0     0     0     0     0
@1000:  1111  2111  3111     1     0     0     0     0     0     0     0     0     0     0     0     0
@1010:  1222  2222  3222     0     0     0     0     0     0     0     0     0     0     0     0     0
@1020:  1333  2333  3333     1     0     0     0     0     0     0     0     0     0     0     0     0
@1030:  1444  2444  3444     0     0     0     0     0     0     0     0     0     0     0     0     0
@1040:  1555  2555  3555     1     0     0     0     0     0     0     0     0     0     0     0     0
@1050:  1666  2666  3666     0     0     0     0     0     0     0     0     0     0     0     0     0
@8800:     0    10     0     0     1     0     0     0     0     0     0     0     0     0     0     0
@8880:     0     0     0     0     0     0     0     0    10     0     0     0     0     0     0     0
@9990:     0     0     0     0     0     0     0     0     0     1     0     0     0     0     0     0
@A010:    18  4331     4     0     0     0     0     0     0     0     0     0     0     0     0     0
@A020:  1234  4321     4     0     0     0     0     0     0     0     0     0     0     0     0     0
@C110:    10     0     0     0     0     0     0     0     0     0     0     0     0     0  3200     1
@C120:    21     1     0     0     0     0     0     0     0     0     0     0     0     0 10100     1
@C210:    10     0     0     0   960     1     0     0     0     0  2240     1     0     0  3200     1
@C220:    21     1     0     0  3030     1     0     0     0     0  7070     1     0     0 10100     1

This indicated quite a few "undocumented" registers, not mentioned in the xml of the software that came with it.
Unfortunately, after spending way too much time trying to analyze diffs between various dumps, I determined that nearly all these additional registers are not editable, boring constants, and/or duplicated data of other known registers.

There was just one that I found potentially useful @0xA012, which seems to indicate Output status of  (Off / CV / CC) with values of (2 / 4 / 6) respectively.

Along the way I documented as much as I could about the various locations, which I put in the source comments of hm305.py
I just created a fork and pushed my changes if anyone wants to look or try it out: https://github.com/thehans/py_test_interface/blob/master/hm305.py


... Oh, and I also tried a bunch of messing around in the "hidden menu" (Hold "Output" button during power up to enter.  Power cycle to exit.),
and couldn't confirm the meaning or effect of most of these settings besides "bEEP", "O.U.T.", and "Addr".

At one point I saw a web page or forum comment where someone else went over the menu options (I think with about the same level of understanding as I managed, i.e. not much), but I can't find it now, so I'll post my own notes and guesses about meanings of these settings.

I've listed the range of values and placed parenthesis around which one mine came defaulted to, although for a couple of the simple toggles ("PUL-", "S.F.": and "A--o") I am no longer 100% sure if they defaulted ON or OFF and I took a best guess.  I would appreciate if anyone who hasn't already mixed up all their settings :palm: could tell me if their defaults corresponds to what I wrote.

I think the only difference between this unit's factory settings and 305P or 310P was that "bEEP" was already OFF for me, whereas those came with it ON, as I understand.

  • bEEP: Enable/Disable beep on keypress etc.
    M2 toggles (OFF) | ON
  • O.U.T.: Auto enable output when power on.
    M2 toggles (OFF) | ON
  • PUL-: ??
    M1 toggles (OFF) | ON, M5 sets value 0.300-(0.500)-9.999
  • AC.F: AC Frequency?
    (50) | 60
    Not sure what effect this has, if any, but 50Hz default is incorrect for my US sold model.
  • C.Err: Communications (modbus) error handling?  Not sure why disableable, not tested.
    M2 toggles (ON) | OFF
  • C.crc: Communication (modbus) crc check?  Also no idea why disableable, not tested.
    (ON) | OFF
  • S. F. ??
    M2 toggles (ON) | OFF
    *noticed random blinking of 1st digit's "minus segment" on the 4th display(seconds) when this option on screen.  Glitch? or ~~secret code~~
  • -Uo.- and -Ao.-: ??
    M1++,M4-- 000-(003)-010 and  M2++,M5-- 000-(003)-010
  • OtP: Over temp protection in Celsius?  (no apparent way to query temp sensor :( )
    Cycles through: (70) | 80 | 90 | 100 | 110 | 120 | 130 | 140 | OFF
  • -S- (or -5-): ??  Maybe adjustment for other model with dedicated 5V CV output? (USB charge port output is not adjustable)
    Cycles through: 5-0 | (5-1) | 5-2 | 5-3 | F-0 | F-1 | F-2 | F-3
  • A--o: Amps offset?
    (ON) | OFF
    *Observed difference in displayed current.  With disconnected leads, output reads 0.006A when OFF, 0.000A when ON
  • Addr: Modbus device address
    (001)-250

I also didn't notice any correlation between modbus registers and the various settings (aside from "bEEP" and "Addr").  Part of the reason this ended up being an enormous time sink for me, was power cycling, changing a menu option, and dumping registers over and over to look for such changes.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf