EEVblog Electronics Community Forum

Products => Test Equipment => Topic started by: Pikoko on December 31, 2019, 09:01:52 am

Title: Power supply ripe for the picking
Post by: Pikoko on December 31, 2019, 09:01:52 am
Hey guys,

First post but i hope its a good one. I recently bought and Hanmatek HM305p programable power supply off amazon to help outfit my home lab.

Anyway. I was poking around on it and realized it would be fun to try to make it more useful on other system other than windows.
I started reversing the communication protocol which is just serial over usb with a 9600 baud. I documented some of my finding's on my website. http://nightflyerfireworks.com/home/fun-with-cheap-programable-power-supplies (http://nightflyerfireworks.com/home/fun-with-cheap-programable-power-supplies)

I also opened it up as an man or woman worth their salt would. I found it uses a Nuvoton NUC029LAN which is a pretty decent cortex m0+ given the price.

In my post i talk about wanting to hook up a ESP8266 and making a web interface for the thing. Just wanting to field the idea and see if anyone else might find it useful.

side note: There is a command the controls the built in buzzer. Might be fun to try to get it to play some chip tunes  :P
Title: Re: Power supply ripe for the picking
Post by: Pikoko on December 31, 2019, 09:28:51 am
This is the first time i've heard of SCPI. I'll have to look more into it.
Title: Re: Power supply ripe for the picking
Post by: trcm on January 20, 2020, 09:39:57 am
How are you getting on with this switched power supply?
Any thoughts about sharing your source code on github?
Title: Re: Power supply ripe for the picking
Post by: robzr on January 29, 2020, 01:52:44 am
Really nice work reverse engineering their protocol, thanks for sharing. I've been looking at power supplies and the HM305/310P caught my eye.

This is a *perfect* candidate for an ESP32/8266, writing a SCPI translation layer would be a fun project.  Want any help?

Curious if you cracked yours open and looked where USB chip is, and if it could easily be bypassed for the ESP to communicate directly with the MCU via UART?

That RS232 opening on the back could make for a nice spot to 3D print a little adapter for an SMA antenna connector and a reset button for the ESP...

Rob
Title: Re: Power supply ripe for the picking
Post by: robzr on January 29, 2020, 02:13:48 am
If you look at page 39 of the Siglent SPD1000X manual they list the SCPI commands they support, there is not too much there. It'd be totally do-able to emulate a SPD1168X/SPD1305X I suspect :)

https://www.siglenteu.com/wp-content/uploads/dlm_uploads/2018/05/SPD1000X_UserManual_UM0501X-E02A.pdf (https://www.siglenteu.com/wp-content/uploads/dlm_uploads/2018/05/SPD1000X_UserManual_UM0501X-E02A.pdf)

Assuming Siglent uses SCPI for their Labview driver and EasyPower software, then we'd have that......

Here some great details from a DIY power supply project that implemented SCPI:

https://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-commands-summary.html (https://www.envox.hr/eez/bench-power-supply/psu-scpi-reference-manual/psu-scpi-commands-summary.html)

Being a simple, concise, human readable/usable protocol, SCPI should be pretty easy to work with.

Rob
Title: Re: Power supply ripe for the picking
Post by: 3nigm4 on April 30, 2020, 08:25:09 am
Hello, I bought this unit too, the 10A version (HM310P).

The original software if written in C#, so it is easily reversible using ILSpy: attached the latest version with reversed source code.
The main class to look at is WSDeviceContral.cs than manages all the communication of the device.

I'm planning to create a tool under macOSX to manage the device.

Good job  8)
Title: Re: Power supply ripe for the picking
Post by: karamba on April 30, 2020, 03:54:44 pm
The original software if written in C#, so it is easily reversible using ILSpy: attached the latest version with reversed source code.
The main class to look at is WSDeviceContral.cs than manages all the communication of the device.
I'm planning to create a tool under macOSX to manage the device.
Not to start one more Mac vs Windows vs Linux discussion, but by creating Mac specific software you are locking out most of the potential users. It's OK if you do it for yourself only but not so if you plan to share it. I would personally create a web interface for this kind of application ( everything is going web these days).  If you still want to write a standalone application you can use one of many platform abstraction frameworks. I have had very good experience with Qt and C++ but there are others too.
Title: Re: Power supply ripe for the picking
Post by: 3nigm4 on April 30, 2020, 05:56:56 pm
Not to start one more Mac vs Windows vs Linux discussion, but by creating Mac specific software you are locking out most of the potential users. It's OK if you do it for yourself only but not so if you plan to share it. I would personally create a web interface for this kind of application ( everything is going web these days).  If you still want to write a standalone application you can use one of many platform abstraction frameworks. I have had very good experience with Qt and C++ but there are others too.

Yes I know, I'm a developer from about 30 years on both Win, Linux, Mac and mobile ;)
I'll going to write an app for myself... I don't know if for mac or for ios... and share for those who don't want to use Windows like me.

Qt is a great framework, and can be a solution if I choose for a desktop app.

PS: I hate Web interfaces for applications... I'm an old style developer... maybe I can write it in Assembly  8)
Title: Re: Power supply ripe for the picking
Post by: markrages on June 24, 2020, 04:16:25 am
I wrote a basic Python driver for the supply based on your notes.

It is at https://github.com/markrages/py_test_interface

Thanks for taking the trouble to write up your findings!
Title: Re: Power supply ripe for the picking
Post by: trcm on July 22, 2020, 03:25:35 pm
Do let me know if you can share this app when you're ready, would love to control this from my Mac
Title: Re: Power supply ripe for the picking
Post by: duckduck on July 23, 2020, 10:38:43 pm
From the Amazon listing: High quality toroidal pure copper transformer? That's not even high-quality pure marketeering wank! It's not even a linear supply, it's a SMPS! :-DD I guess it has several E-I transformers in there with copper windings. I don't see a toroidal tranny.

Also, notice that the back panel and side of the front panel have been photoshopped on. The back panel has a 2D look to it. I love the USB B jack on a PCB in the DB9 cutout. Make up new stampings? Hell no! Use the ones we can get cheaply!

I think that it is the cheapest functional programmable power supply in the 30 V / 5 A class that can be bought new in the USA. The RD6006 is close  in price if you get it direct, but a little more expensive once you throw in a power supply and case.

I wonder how hard it would be to get this thing talking to sigrok? https://sigrok.org/ (https://sigrok.org/)

How does this compare to the Korad KA3005P on specs? http://www.koradtechnology.com/product/14.html (http://www.koradtechnology.com/product/14.html)
Title: Re: Power supply ripe for the picking
Post by: SpeedProg on November 05, 2020, 01:40:37 pm
I wrote sigrok driver for an RS310P (just an other rebrand of the eTommens eTM-3010P), the HM305P is just an other rebrand also.

To add the HM305P to the driver, I would need to know the contents of the 0x04 (class details) and 0x03 (model).
I would assume the values are 0x4B50 (in 0x04) and 0x0131 (in 0x03) but I'd rather know for sure before adding it to the driver.

The easiest way to do this for you is proably using the script mentioned above in https://github.com/markrages/py_test_interface
Title: Re: Power supply ripe for the picking
Post by: Suimi on November 28, 2020, 01:07:49 pm
Thank you very much SpeedProg!!

I just unboxed my new Hanmatek HM310P and just started playing with it. The hm305.py is reporting the following values:
Model (0x03): 0x0BC2
Class (0x04): 0x4B50

Please let me know if I can be of any help with your driver. Thank you again.
Title: Re: Power supply ripe for the picking
Post by: Max3D on December 05, 2020, 04:54:45 pm
Great work in progress guys. Glad I found this forum as wireless control of the power supply would be awesome. I have a Rockseed 60V, 5A amp version, the RS605P. I hope the software will be compatible with this model.

For the moment I have a problem: the original software can't be downloaded as the link is dead and the mini CD I can't use. Does anyone have the latest software for me?
Title: Re: Power supply ripe for the picking
Post by: Miq1 on December 16, 2020, 05:35:05 pm
Hi guys,

I will be getting my HM305p tomorrow and already read this thread with  interest. I have done some stuff with Modbus and found it funny the PSU comes with a Modbus server built in  ;)

If you are still looking for a way to bring the device online, you might have a look at the ESP32 Modbus library we have been writing recently: eModbus at Github (https://emodbus.github.io/). The device that comes to my mind would be a "ModbusBridgeWiFi", that does accept requests over WiFi and will forward these to the PSU, then respond back with the data the PSU has sent. You of course will have to write the program yourself on your PC or whatever to talk to the Modbus bridge.

I am looking forward to examine the PSU closely to find what else might be hidden.
Title: Re: Power supply ripe for the picking
Post by: Max3D on December 29, 2020, 08:22:55 pm
Hi Miq and others,

I found the original software and I can communicate in both directions with the Hammatek / Rockseed / eTommens (the latter being the real manufacturer I believe). I can see the real time status and change voltage or amp settings.
However I have no idea how to set data points comparable to the memory buttons. The interface is there, but I can't see a way to set them. Anyone an idea?

This is the Chinese version with data points on the bottom half. I have exactly the same interface but no idea how to populate the bottom half at the left
(https://uicek5ftokcnv6l5jz46uwslze--www-etommens-com.translate.goog/uploadfile/ali/195854575/8557007250_1477468708.jpg)
Title: Re: Power supply ripe for the picking
Post by: tv84 on December 29, 2020, 09:56:34 pm
This is the Chinese version with data points on the bottom half. I have exactly the same interface but no idea how to populate the bottom half at the left

Looking a bit at those curve graphs, it seems that thing is a DMC DeLorean...   ::)
Title: Re: Power supply ripe for the picking
Post by: Max3D on December 29, 2020, 10:21:38 pm
Yeah, so far I didn't manage to get the settings to go back in time ;)

In reality the right hand side are a scrolling view of voltage/Amps over (sequential!) time.

the setting in the lower empty box are Model / Voltage / Current / Power / Duration (ms) / Inaccuracy  / GapOfAdjustments (ms) / Enable

I would love to be able to set these
Title: Re: Power supply ripe for the picking
Post by: SpeedProg on January 10, 2021, 05:07:19 pm
I belive the stuff in the bottom half, I was able to set in one of the config xml files in the programs folder.
Sorry I can't give you any more details, sadly I managed to lose my mini cd and seemed to have deleted the windows vm with the program too, that I used to do research for the rigrok driver.

For those who can compile their own stuff and want to use the HM310P, RS310P with sigrok the driver pull request is here:
https://github.com/sigrokproject/libsigrok/pull/100
for adding HM305P or 60V versions I would still the info to add it to drivers.

I did the pullrequest some time ago, but as it seems it will probably take some months for anything to happen.
Title: Re: Power supply ripe for the picking
Post by: trcm on January 31, 2021, 10:44:29 pm
I modified the https://github.com/markrages/py_test_interface code to report the Class and Model of my HM305P :
Code: [Select]
$ ./hm305.py
Class (0x04): 19280
Model (0x03): 305
1.8 Volts
0.0 Amps
0.0 Watts
Title: Re: Power supply ripe for the picking
Post by: trcm on February 01, 2021, 01:49:55 pm
Thanks for the efforts writing the Sigrok driver for this class of devices!
I've added some Sigrok wiki pages for these devices with some links to the software and manuals (English), and I've made a note of the known device class and models where we know them so far...

https://sigrok.org/wiki/ETommens_eTM-xxxxP_Series (parent page)
https://sigrok.org/wiki/Hanmatek_HM305P (oem / reseller model)
https://sigrok.org/wiki/RockSeed_RS310P (oem / reseller model)
Title: Re: Power supply ripe for the picking
Post by: trcm on February 02, 2021, 10:49:24 pm
One note about the Hanmatek HM305P is that when driving a PWM load in the region of very roughly 3hz, the rear fan cycles up and down almost in lock-step, implying (to me anyway) that it’s not driven off a thermal sensor.
This makes it fairly audibly-annoying for this load use-case!
Title: Re: Power supply ripe for the picking
Post by: peepsalot on April 21, 2021, 11:39:38 pm
I was looking for a cheap programmable bench supply recently, and came across a Hanmatek HM310T (as opposed to HM310P)
https://www.amazon.com/Programmable-Precision-Variable-Switching-Interface/dp/B08TZVZQR6 (https://www.amazon.com/Programmable-Precision-Variable-Switching-Interface/dp/B08TZVZQR6)
This one seems similar to HM310P but has 4! numeric displays (an added clock/timer) and looks pretty slick in the pics.
I'm guessing its just an updated faceplate with more-or-less same internals and hopefully same protocol?

Anyone seen/used one of these?  I wasn't able to find any youtubes about it or even a single picture in the wild besides the apparently rendered product page ones.  Could be a very recent revision/release :-//   

Says it could be shipped in a day from amazon though... I'm tempted to pull the trigger but still teetering on the fence.

Title: Re: Power supply ripe for the picking
Post by: trcm on April 22, 2021, 07:14:35 am
The Rockseed and Hanmateks were all rebadged eTommens units, but this one you link to doesn't appear to be shown as a product on eTommens product page?
The internals have also seemingly changed, a simplified/cheaper BOM perhaps?

HM305P : (https://www.dropbox.com/s/3j8u855uhuq4hwt/800px-Hanmatek_HM305P_inside_power_front_right.JPG?raw=1)
HM310T : (https://www.dropbox.com/s/cj85tngwxe1od38/81gOsgT21FL._SL1500_.jpg?raw=1)

(Other HM305P images here : https://sigrok.org/wiki/Hanmatek_HM305P (https://sigrok.org/wiki/Hanmatek_HM305P))
Title: Re: Power supply ripe for the picking
Post by: peepsalot on April 22, 2021, 05:03:52 pm
Yeah I'm not sure how much I trust that pic of internals anyways, as it appears to be the mainboard for a programmable 305 model.  The markings on the transformer being "TM150-305"

However the 305 variation from the same product listing page is not programmable (and the image of internals for that one is hilariously poorly edited though it appears to indicate that same mainboard, for whatever that's worth): [attach=1]

I also just found what looks like this style of board on another "programmable" (but no interface cable) 30V 5A, rebadged as A-BFastiron : [attach=2]
from here https://www.amazon.com/BFastiron-Programmable-Power-Supply-Variable/dp/B08C531D7T (https://www.amazon.com/BFastiron-Programmable-Power-Supply-Variable/dp/B08C531D7T)

So what is actually inside that HM310T is anyone's guess at this point...

edit: Also nice to see the 30V 5A version features "Lover Noice"  :-DD
Title: Re: Power supply ripe for the picking
Post by: peepsalot 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.

(https://i.imgur.com/ufeqtbO.jpg)
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

(https://i.imgur.com/A3zm6gw.jpg)
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?

(https://i.imgur.com/pI6eMRl.jpg)
"Overhead" viewpoint (relative to the case) of the mainboard.

(https://i.imgur.com/jAQNPTG.jpg)
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.

(https://i.imgur.com/0Gr6NKj.jpg)
MOSFET closeup

(https://i.imgur.com/YLB8aLj.jpg)
Bottom of heattsink, attachment to case

(https://i.imgur.com/K4Ap4yn.jpg)
Looks like a thermistor to monitor heatsink temps

(https://i.imgur.com/5D8ACgn.jpg)
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.

(https://i.imgur.com/8HKthiE.jpg)
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.

(https://i.imgur.com/hiXGHTK.jpg)
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.

(https://i.imgur.com/nS57ttj.jpg)
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
(https://i.imgur.com/xceiLkV.jpg)

(https://i.imgur.com/8xDqYtr.jpg)
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?

(https://i.imgur.com/0jdXKM5.jpg)
Quick peek at other side of USB port PCB, not much to see, just one cap.

(https://i.imgur.com/zDGZMHY.jpg)
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.

(https://i.imgur.com/y2vOZV4.jpg)
Front panel overview with display pcb, power output jacks, USB charger ports, and power switch.

(https://i.imgur.com/dO6Ijd2.jpg)
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.

(https://i.imgur.com/sPjq74A.jpg)
Main MCU: Nuvoton "NUCO29LAN" Arm Cortex M0 32bit microcontroller

(https://i.imgur.com/ahC90KS.jpg)
Unconnected 5 pin 0.1" header labeled J6, (maybe could be used to reprogram the MCU if someone were so inclined?)

(https://i.imgur.com/boV6glV.jpg)
Other side.  All the buttons have LED indicators except OVP and OCP.
Knob has basic 20 position rotary encoder with clicky switch.

(https://i.imgur.com/38xOZji.jpg)
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

(https://i.imgur.com/t2Mo4EN.jpg)
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.
Title: Re: Power supply ripe for the picking
Post by: peepsalot 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 (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:
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.


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.