I modified the https://github.com/markrages/py_test_interface code to report the Class and Model of my HM305P :
$ ./hm305.py
Class (0x04): 19280
Model (0x03): 305
1.8 Volts
0.0 Amps
0.0 Watts
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 (https://en.wikipedia.org/wiki/Modbus#Function_code_4_(read_input_registers)_and_function_code_3_(read_holding_registers))) , 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:
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.