I've got
this Mastervolt combined inverter/charger that I would like to poll for data, but I'm struggling to make sense of the returned bytes. The device has a "quasi" RS232 port (QRS232) operating at TTL levels. I've made my own cable using an FTDI USB > TTL converter, and I can communicate with the device using Mastervolt's own software (running in a WinXP VM).
This software seems to work by doing bursts of polling in blocks of 49 requests, returning 49 responses. I used my scope to capture the raw TX/RX data in hex and interleaved these in a spreadsheet, with each request (in red) followed by the response (in black):
Studying this told me a few things about the requests:
- Requests are usually 9 bytes in length, though a few are 8 or 7.
- A request always begins with C1 F0
- This is followed by what appears to be a register address made up of two bytes (the second byte is sometimes 00)
- The following three bytes of the request are always 00, and the fourth one either 00 or 01 (read/write?)
- The last byte is a modulo 256 checksum of the preceding bytes
And the responses:
- Responses are always 9 bytes in length
- A response always begins with F0 C1
- The next two bytes repeat the address given in the request, though the second byte differs if 00 was requested
- The following four bytes contain the requested data
- The last byte is a modulo 256 checksum of the preceding bytes
I wrote a simple Python program (attached) to replay some of the queries and see if I could get some meaningful numbers out of the responses. First I tried a little endian sum of the four bytes, but nothing stands out as an expected value:
To see which responses might contain data I'm interested in, I tried disconnecting from the mains and letting the inverter kick in for a few seconds, before restoring mains power again:
Much more interesting. I can see several values which drop dramatically as mains power is removed, only to increase again once restored. One of these might be battery charger current & voltage, mains voltage, battery voltage, etc, but the numbers are clearly wrong. Other values don't change at all, or very little - perhaps things like serial number, firmware revision, system or battery temperature, usage counters, etc.
Since I can't make sense of any of the numbers, I removed the integer conversion and printed the data bytes raw:
Ok, so it's clearly not big-endian; that would result in ridiculously high values. And it's probably not two values by two bytes each. I tried looking at it as an ASCII blob, to see if there was any text in there, but there was none. Feels like I'm close, but I've become completely stuck. This is the first time I'm trying to reverse-engineer an unpublished serial protocol, so it's likely I've overlooked something obvious - but what might that be? Grateful for any suggestions!