[HCL] <Santak> <MT*-PRO / Castle C*K> PARTIALLY supported by <blazer_ser>

[whc2001]

Background

Santak is a Chinese company focused on manufacturing UPSes. They have some strange but close relationship with the world-famous brand Eaton. Almost all their UPSes are equipped with an RS232 communication port with an extended version of the classic Blazer (Q1) communication protocol.

Testing with blazer_ser

I have a Castle C1K on hand, which is an online ("double conversion") UPS with two built-in 12V batteries and 1kVA output capacity. I can make it work by using blazer_ser driver:

root@Debian-Builder:/etc/nut# upsc c1k@localhost
Init SSL without certificate database
battery.voltage: 2.28
battery.voltage.high: -1.08
battery.voltage.low: -0.87
device.type: ups
driver.name: blazer_ser
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyUSB0
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.internal: 1.57
input.frequency: 50.0
input.voltage: 231.3
input.voltage.fault: 0.0
output.voltage: 220.0
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 0
ups.status: OL
ups.temperature: 40.0
ups.type: online

Most thing works. The battery voltage reports 2.28 because the Castle C*K series it reports the battery voltage as the multiplier of voltage of single piece of battery (2.28 * 12V = 27.36V), unlike the MT*-PRO series that reports the voltage directly. This can be solved by setting flag

override.battery.voltage.nominal = 24
override.battery.packs = 12

in theory, but seems like it does not work:

root@Debian-Builder:/etc/nut# upsc c1k@localhost
Init SSL without certificate database
battery.packs: 12
battery.voltage: 2.28
battery.voltage.high: -1.08
battery.voltage.low: -0.87
battery.voltage.nominal: 24
device.type: ups
driver.name: blazer_ser
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyUSB0
driver.parameter.synchronous: no
driver.version: 2.7.4
driver.version.internal: 1.57
input.frequency: 49.9
input.voltage: 232.0
input.voltage.fault: 0.0
output.voltage: 219.5
ups.beeper.status: disabled
ups.delay.shutdown: 30
ups.delay.start: 180
ups.load: 0
ups.status: OL
ups.temperature: 40.0
ups.type: online

Further commands Q6 by reverse engineering

Santak provided a companion software written in Java to use with their product called WinPower. It has almost everything we need on the display panel, including estimated battery percentage, estimated remain time and so on. I have contacted Santak to ask for a copy of the communication protocol document, but they require me to apply as an enterprise and sign a copy of NDA. So official support is not feasible. Thus, I decided to decompile the application in an attempt to seek for something useful.

I would say this first, that the process is definitely not easy. The decompiled class file that contains logic about processing serial port communication and parse for the response is 700KB in size, and every field in response has a magic number as an identifier. Luckily after analyzing with serial port packet capture, I found the most interesting query command: Q6. It has the same request and response format as Q1, just differences in response fields. I made some notes about each field, but pay attention that I was not able to understand some of them, and others might not actually being used.

Field Index	Usage	Remark (The field ID "magic number", and corresponding variable name)
0	AC Input Voltage (Volt)	[902] iInputVolt
1	AC Input Voltage Phase 2 (Volt)	[909] iInputVoltS
2	AC Input Voltage Phase 3 (Volt)	[910] iInputVoltT
3	AC Input Frequency (Hz)	[901] iInputFreq
4	AC Output Voltage (Volt)	[1003] iOutputVolt
5	AC Output Voltage Phase 2 (Volt)	[1007] iOutputVoltS
6	AC Output Voltage Phase 3 (Volt)	[1008] iOutputVoltT
7	AC Output Frequency (Hz)	[1002] iOutputFreq
8	?	Unused in code?
9	?	Unused in code?
10	?	Unused in code?
11	Battery Voltage (Volt)	[802] iBatteryVolt
12	?	[801] iBatteryVoltNeg
13	Temperature (Degree Celsius)	[803] iBatteryTemperature
14	Estimated Remaining Time with Current Load (Seconds)	[805] iEstTimeRemaining
15	Battery Percentage	[806] iEstChargeRemaining
16	?	Unable to understand, first digit unknown, second digit [601] iTestResultsSummary
17	Error Report?	[725] sFaultCode
18	?	[918] iInputLineType
19	?	[1023] iOutputVoltFlag

Example

<< Q6\r
>> (232.2 ---.- ---.- 50.0 219.9 ---.- ---.- 50.0 008 --- --- 027.3 ---.- 41.0 17785 100 30 00000000 00000000 11\r

• AC Input Voltage = 232.2V (Single phase model, no readings on other phases)
• AC Input Frequency = 50Hz
• AC Output Voltage = 219.9V (Single phase model, no readings on other phases)
• AC Output Frequency = 50Hz
• Battery Voltage = 27.3V
• Temperature = 41℃
• Estimated Run Time after AC Loss = 17785s = 04:56:25
• Battery Percentage = 100%

I tried to look through the code of blazer_ser but programming in C is still a little difficult for me. Hope someone would add this query (maybe as an extension to blazer_ser, something like protocol = santak) to the driver sometime.

[linser233]

What specific model do you use? My 'SANTAK Castle 1K (6G)' doesn't seem to be recognized by blazer_ser.

[jimklimov]

@linser233 : which NUT version are you using? The 2.7.4 in original report was latest release at the time, but is 9 years old now.

Also, try nutdrv_qx as the newer driver which combines a number of Megatec Q* protocol dialect supports over USB and serial links, including code from older independent drivers. Some things did get developed differently over time, and for some people blazer reportedly works better so we are still not ready to let it go, but eventually we should...

[whc2001]

What specific model do you use? My 'SANTAK Castle 1K (6G)' doesn't seem to be recognized by blazer_ser.

I have tested with MT-1000PRO and Castle C1K (standard, tower style) that are manufactured before 2021. It could be possible that they changed protocol afterwards, but I am not exactly sure since I no longer possess any Santak machines. As the maintainer said you can try the newer Qx driver to see if it's recognized