Need help decoding RS232 data from Mastervolt inverter/charger - Page 1
Forum section: electronics / beginners

author: Lomax
author_rank: Frequent Contributor
timestamp: April 30, 2021, 04:35:02 pm
content: I've gotthis Mastervolt combined inverter/chargerthat 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 F0This 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 bytesAnd the responses:Responses are always 9 bytes in lengthA response always begins with F0 C1The next two bytes repeat the address given in the request, though the second byte differs if 00 was requestedThe following four bytes contain the requested dataThe last byte is a modulo 256 checksum of the preceding bytesI 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!

author: Lomax
author_rank: Frequent Contributor
timestamp: April 30, 2021, 04:39:57 pm
content: Side note: why can I no longer insert attached images inline?Edit:Added the images manually, sorry for the large size of some of them!

author: Lomax
author_rank: Frequent Contributor
timestamp: April 30, 2021, 04:47:08 pm
content: Here is the raw sample data from when mains power was removed and restored:f1002000 f5061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f4061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f5061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f4061a00 00050000 05380000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f3061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f2061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f3061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f2061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f3061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f4061a00 00050000 05370000 00040000 0000f404 00000000 fc000000 00000000 ffffff2d 01000000 38055312 01000000 06000000 03000000 02570000f1002000 f4061a00 00050000 05280000 00040000 0000f404 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000f3002500 ec061400 00010000 05000000 00020000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000f3002500 e6061400 00000000 05000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000f3003500 e6061400 00000000 05000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e3003500 e6061400 00000000 05000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e3003500 e6061400 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e3002000 e6061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e3002000 eb061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e3002000 f2061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e3002000 f3061c00 00000000 04000000 00030000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000091002000 f4031a00 00030000 05000000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000091002000 f4051a00 00040000 050c0000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000091002000 f4051a00 00040000 05250000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000091002000 f4051a00 00040000 053c0000 00010000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000081002000 f3081a00 00070000 05550000 00050000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000081002000 f30a1a00 00080000 056b0000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000081002000 f30b1a00 00090000 05810000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 0257000081002000 f30c1a00 000b0000 059a0000 000a0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30d1a00 000b0000 059f0000 000b0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f20d1a00 000b0000 05970000 000a0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30d1a00 000b0000 05910000 000a0000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30c1a00 000a0000 058c0000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30c1a00 000a0000 05880000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30c1a00 000a0000 05840000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30c1a00 000a0000 05800000 00090000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30c1a00 000a0000 057c0000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30b1a00 00090000 05780000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30b1a00 00090000 05740000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30b1a00 00090000 05710000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30b1a00 00090000 056e0000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30b1a00 00090000 056b0000 00080000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 05690000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 05660000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 05630000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 05610000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 055e0000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 055c0000 00070000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 055a0000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f30a1a00 00080000 05580000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f3081a00 00070000 05550000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f3081a00 00070000 05540000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000e1002000 f3081a00 00070000 05520000 00060000 0000f304 00000000 fc000000 00000000 ffffff33 01000000 38055312 01000000 06000000 03000000 02570000The third and fourth values appear to be the most interesting.

author: ledtester
author_rank: Super Contributor
timestamp: April 30, 2021, 04:54:38 pm
content: Since you seem to have a good idea of what the protocol is you could use an Arduino to replay modified versions of the replies to see how the numbers in the UI change.

author: Lomax
author_rank: Frequent Contributor
timestamp: April 30, 2021, 05:05:07 pm
content: Thanks, that's a nice idea - I will keep it in mind!Right now I'd like to try with the bits all flipped; I've got a suspicion their data may use the opposite levels, but just how to do this in Python eludes me for the moment.

author: ledtester
author_rank: Super Contributor
timestamp: April 30, 2021, 05:27:09 pm
content: Maybe you're looking for the bitwise xor operator:https://python-reference.readthedocs.io/en/latest/docs/operators/bitwise_XOR.htmlXOR-ing with 0xFFFF will invert the lower 16-bits, for instance.

author: Lomax
author_rank: Frequent Contributor
timestamp: April 30, 2021, 08:45:45 pm
content: Thanks! Alas, that gave me far too large numbers, also with big-endian order, and pairs of bytes showed nothing that could be relevant. I must have missed something very basic!

author: Lomax
author_rank: Frequent Contributor
timestamp: May 01, 2021, 12:59:29 am
content: Some further digging. I noticed that the high frequency polling (all 49 requests repeat roughly every 0.5s) is interrupted if I change a value in the GUI. This makes sense since there needs to be time to update the device and read the value back for confirmation. I thought I'd take a look at this data, and managed to capture four presses of the increment button for one of the values ("Transfer Switch Min. AC Voltage"), increasing the value by 1 with each click. It looks on the scope as if each press generates two requests, each with a corresponding response, which seems reasonable. BUT. The data makes no sense whatsoever. For example I would have expected to see some value that incremented by the same amount with each click, but here's what I get (again, requests are in red, followed by the response in black - and grouped for each press):The first two bytes again can probably be ignored; that's not where the data is, but a command of some sort. The valueshouldbe contained in some combination of the following bytes, but I certainly can't see it (should be between 180-200 in decimal, or possibly 1800/18000 depending on precision). Instead I find it in thelastbyte - which was clearly achecksumin the big chunks of polling data I looked at in my first post (I carefully double checked this on a number of records, both TX & RX - they all matched). The first responses for each press (rows 2,7,12,17) end with BC, BD, BE, BF, which corresponds to 188, 189, 190 and 191 in decimal - the correct values. Whoa.What kind of oddity am I dealing with here, sometime checksums sometimes not? Why do these four clicks produce such different looking requests? Why aren't the responses always the same length? Does the command sent tell the device to increment the value rather than set it to X?Here's what the four clicks look like on the scope, overview followed by zoomed in view of one request/response (TX in blue, RX in red):

author: RoGeorge
author_rank: Super Contributor
timestamp: May 01, 2021, 02:00:39 am
content: Have you checked if the protocol is MODBUS? It's one of the most common protocols when it comes to RS232 or 485 serial devices.Just out of curiosity, I've searched for"mastervolt" serial protocoland it looks like others tried to decode the protocol, not sure if any of these applies to your charger:https://github.com/langemeijer/mastervolt-phphttps://download.copadata.com/fileadmin/user_upload/Downloads/Dokumentation/760SP0/ENGLISH/Driver/Masterbus32.pdf

author: Lomax
author_rank: Frequent Contributor
timestamp: May 01, 2021, 12:45:43 pm
content: Quote from: RoGeorge on May 01, 2021, 02:00:39 amGood point, but I'm pretty sure it isn't: I would expect to see 0x01 to 0x16 in the first few TX bytes, these being the Modbus "commands". And I don't think you see much Modbus over RS232; Modbus handles multiple slaves while RS232 can only be connected between two devices. The whole "which slave am I talking to?" part of Modbus would be wasted here. It does have some similarities in how it seems to read consecutive registers though (see the lines beginning C1 F0 26).Quote from: RoGeorge on May 01, 2021, 02:00:39 amYeah, I've looked at those. The "mastervolt-php" protocol has some similarities, but uses different commands and seems less granular. For example, a "get status" command begins B6 00 00 00 and returns a whole bunch of parameters (ten in fact). My "read" commands all begin with C1 F0 and each one only returns four bytes of data (so could hardly contain more than one or two numerical parameters). The "mastervolt-php" protocol runs at 9600 baud, mine at 19200 baud.The other protocol you mention, "MasterBus", is Mastervolt's current standard. Like so many other manufacturers of this kind of equipment they've switched to a CANBus based network which is totally different from what my older device uses. Unfortunately it seems Mastervolt like changing their mind on this stuff, because I've seen them use several different physical layers and a handful of different protocols, adding to the confusion (yet another example isthe protocol used by their "Soladin" PV controllers). The interface and protocol that I have ("PC-Link") is only used on the following devices:IVO smart chargersMagic DC/DC convertersMass chargersMass Combi charger/invertersDakar Generator controlsBTM-I battery monitorsBTM-III battery monitorsInterestingly, I see now that the "MasterAdjust" software supports all MasterBus devices as well as those I listed above, although they use a completely different physical layer (CANBus vs RS232). Perhaps this is a hint that my protocol is similar to the MasterBus protocol after all. Hmmm.

author: Lomax
author_rank: Frequent Contributor
timestamp: May 01, 2021, 01:21:16 pm
content: Some things I think I know about the TX data:It always starts with "C1", followed by either "F0" (read?), "31" (unknown), "42" (write?) or "1B" (unknown). These appear to be the commands, with the first two seen in the polling data and the second two when I alter a setting in the GUI.The next two bytes in the polling requests very much look like an address, as they can be seen increasing by four bytes with each request in the polling data (see rows 12 to 42). This is followed by four bytes which presumably would be the actual data - usually "00 00 00 00", but sometimes "00 00 00 01", both of which could make sense when you're just doing a read. Following the four data bytes there's a checksum byte, which I have verified to be correct for a dozen requests and responses - the chance that it could be anything else is basicallyzero.When changing a setting in the GUI (i.e. doing a "write") there are fewer data bytes, and each change results in two TX packets. The first starts "C1 42" followed by four bytes of something -with no checksum at the end. I know the last byte isn't a checksum here because none of the 16 TX/RX packets I looked at validate usingany common checksum algorithm. This strikes me as rather odd, since the "read" commands have checksums, and I'd be interested in hearing your thoughts on this.The second TX packet, which is sent after the device has replied to the first, is always "C1 1B 00 00 CC", to which the device will also reply. Could this be some kind of acknowledgment?

author: Lomax
author_rank: Frequent Contributor
timestamp: May 01, 2021, 01:39:43 pm
content: Following the idea that PC-Link and MasterBus may use a similar structure (since the software supports both), I dug around insomeone's reverse engineering effort on GitHuband foundthe following dictionary:Code:const uint16_t MastervoltDictionary::INVERTER_DC_VOLTAGE_IN=0x06;const uint16_t MastervoltDictionary::INVERTER_DC_AMPS_IN=0x07;const uint16_t MastervoltDictionary::INVERTER_AC_AMPS_OUT=0x0b;const uint16_t MastervoltDictionary::INVERTER_LOAD_PERCENT=0x11;const uint16_t MastervoltDictionary::INVERTER_AC_VOLTAGE_OUT=0x0a;const uint16_t MastervoltDictionary::INVERTER_SHORE_FUSE=0x13; //4 Amp offsetconst uint16_t MastervoltDictionary::INVERTER_MODE=0x14; //1.0=On 0.0=Off 3==Standby?const uint16_t MastervoltDictionary::INVERTER_POWER_STATE=0x38; //1.0=On 0.0=Offconst uint16_t MastervoltDictionary::CHARGER_STATE=0x3a; //1.0=On 0.0=Offconst uint16_t MastervoltDictionary::INVERTER_INPUT_GENSET=0x0e; //1.0=On 0.0=OffPerhaps this will get me a little further.

author: Lomax
author_rank: Frequent Contributor
timestamp: May 01, 2021, 03:59:24 pm
content: No, I think that's a red herring - tried a few but the register numbers don't seem to match. So looking at MasterBus will probably not help much. But I've had one significant break through: I've got the first 100% definite query and the first 100% definite response!With this query request:C1 F0 26 94 00 00 00 00 6B^ ^ ^ ^ ^ ^ ^ ^ ^?? Read Register n/a ChecksumI get the response:F0 C1 26 94 00 00 EA 04 59^ ^ ^ ^ ^ ^ ^ ^ ^Read ?? Register Data Data Checksum"EA 04", or 1258 in little-endian decimal, happens to match exactly the value for "Lowest DC Voltage" on the "History" tab of the MasterAdjust software (12.58 V). If I "clear history" this value defaults to 18.00 V, and a subsequent request for the "26 94" register's data returns "00 00 08 07", with the two last bytes now reading 1800 in little endian decimal. If I disconnect mains input and let the inverter take over the value will start to fall, eventually following the declining battery voltage. There is no doubt whatsoever, this parameter isnailed. One down, 48 to go

author: Lomax
author_rank: Frequent Contributor
timestamp: May 14, 2021, 11:36:44 pm
content: I won't bore you with the gory details, but after tinkering on and off with this for a couple of weeks, some progress has been made:Still many unknowns - most importantly I haven't been able to extract the battery voltage, which is probably the value I'm most interested in. I've also found quite a few curious quirks, such as not being able to check whether the inverter or charger are switched on without changing their state, forcing me to store state on the application side. Which byte(s) the data arrives in, and what multiplier it uses varies wildly between parameters. PM me if you have one of these units and want to know more; at some point I'll turn my (copious) notes into something others can understand, but that's some way off still...

author: james_s
author_rank: Super Contributor
timestamp: May 14, 2021, 11:41:09 pm
content: I think I'd start by trying to identify which blocks represent specific parameters. Find one you can control easily such as the load on the inverter and watch the data coming out as you vary the load, or connect it to a variac and vary the mains voltage. Once you know which group of data represents that value you can capture a series of them representing known values and try to work out how it's encoded. It probably is not anything very complicated, encrypted or deliberately obfuscated.

author: Lomax
author_rank: Frequent Contributor
timestamp: May 14, 2021, 11:46:37 pm
content: Quote from: james_s on May 14, 2021, 11:41:09 pmThis is precisely what I have been doing. Also graphing all the unknowns and changing the conditions, then looking at which values change, when, and by how much. At the same time I try to look at it from the engineer who designed it's perspective, finding patterns, concepts. It is not very complicated, encrypted or deliberately obfuscated, but it's also clearly not designed with third party use in mind. Reeks of "internal tool".Edit:Forgot to mention that I've also spent a lot of time capturing and analysing the data sent/received by the official application - very useful to be able to look at this, but difficult to capture the right snippets since the app fires off bursts of 40+ queries every second (this cannot be turned off or slowed down), burying the needle I'm looking for in a hexadecimal haystack. Only by diffing parts of repeated captures have I been able to figure out the more involved parts, such as how to alter the state of the device and its configuration parameters.

author: james_s
author_rank: Super Contributor
timestamp: May 14, 2021, 11:52:50 pm
content: Quote from: Lomax on May 14, 2021, 11:46:37 pmThat's to be expected, my guess is that it's designed to interface with a remote panel. I remember my dad had a very similar inverter/charger on his sailboat and it used some kind of digital link to a control panel mounted next to the nav station alongside the AC and DC electrical panels and radio gear. It's also possible that it's just for a factory test fixture, but either way it makes sense that they would design it without any regard to 3rd party use.

author: Lomax
author_rank: Frequent Contributor
timestamp: May 15, 2021, 12:00:26 am
content: Quote from: james_s on May 14, 2021, 11:52:50 pm100% correct, and very obvious when looking at the data; for some responses individual bits directly represent different LEDs on the panel. Once I saw this pattern a lot of stuff came falling out. But it meant I had to look at each 4-byte response in binary to see it. Tedious!Edit:It really helps that I have an actual remote panel, so I can compare what it shows with the data I see. It's a pretty basic panel though, and there's a lot more data to be fetched from the device itself.

author: Lomax
author_rank: Frequent Contributor
timestamp: May 15, 2021, 12:07:41 am
content: Here's a snippet from my notes - only covering two out of 40+ queries/commands seen in the wild:Code:37 (0x25) - state:sample response :240 193 37 [240 193 0 0 0] 1350xF0 0xC1 0x25 [0xF0 0xC1 0x00 0x00 0x00] 0x87first byte (payload)11 11100 0 252 discharged?11 11010 1 245 Error mode?11 11111 0 254 100% DC-load (also when switched off)11 11110 0 252 75% DC-load11 11100 0 248 50% DC-load11 11000 0 240 25% DC-load11 10000 0 224 5% DC-load11 00000 0 192 0% DC-load01 00000 0 64 Charger off, inverter off00 11111 0 62 100% on inverter?00 11110 0 60 75% on inverter?00 11100 0 56 50% on inverter00 11000 0 48 25% on inverter00 10000 0 32 5% on inverter00 00000 0 0 cut off / inverter offsecond byte (payload)1111 0011 2431111 0001 241 100%1110 0011 227 75% inverter soc1100 0011 195 50% inverter soc1000 0011 131 25% inverter soc0000 0011 3 5% inverter soc0000 0010 2 0% blinking1111 0001 241 charging (float, 17:29, 0.5 Ampere)1110 0001 225 charging (absn 2, 16:44, 6 Ampere)1100 0001 193 charging (absn 1, 15:41, 32 Ampere)1000 0001 129 charging (bulk 2, 15:21, 34 Ampere)0000 0001 1 charging (bulk 1, 14:26, 34 Ampere)0010 0100 36 low voltage error (inverter)third byte (payload)0000 00000100 0000 64 cut off, alarm output?fourth byte (are these warnings/errors?) (payload)0011 0101 53 inverter error?0010 0101 37 low voltage error?0001 0101 21 shore power off? (it's still 21 when inverter off & no shore power)0000 0101 50000 0000 0 shore power on?fifth byte - unexplored! (payload)0000 0000========================================================================50 (0x32) - change (cannot read without write):0x06 = both off0x04 = inverter off0x02 = charger off0x00 = ???first byte (payload) output voltage?241 after sending 0x00 or 0x04240 after sending 0x001110 1111 239 ??? after sending 0x00 or 0x020000 0000 0 ??? after sending 0x04 or 0x06second byte (payload) output current?0010 0100 36 ??? after sending 0x000001 1100 28 ??? after sending 0x02 (charger off)0001 1011 27 after sending 0x00 or 0x040000 0000 0 ??? after sending 0x04 or 0x06third byte (payload)0001 1010 26 ??? after sending 0x02 (charger off) or 0x04 or 0x000001 1000 24 AC present? after sending 0x04 or 0x06 or 0x02fourth byte (payload) state?0000 0110 6 both off0000 0100 4 charger on0000 0010 2 inverter on0000 0000 0 both on

author: james_s
author_rank: Super Contributor
timestamp: May 16, 2021, 12:52:51 am
content: Quote from: Lomax on May 15, 2021, 12:00:26 amIt might be interesting to try going the other direction and connect the panel to your PC and see how it responds to data you send it and what it sends when you operate controls on the panel. It ought to be easier to determine exactly what it will send since you aren't relying on parameters measured by the inverter.