I have two voltronic (Kodak) inverters: an OG 5.6 and an OGPLUS 6.2.

The OGPLUS 6.2 has an extremely flaky USB port for comms. Every hour, or maybe 6 hours, the USB port resets, and the raspberry pi will eventually give up trying to reconfigure the USB port. I work around this by using uhubctl to power cycle the USB ports, and this sometimes works. Other times I need to power cycle the Pi. There are still many gaps of between 30 minutes and 3 hours where I have zero telemetry, but eventually it comes alive again. I initially used the RS232 port, but my RS232-to-USB adapter got cooked at some point, so now I've switched over to using direct USB cable with a USB isolator in between (https://www.pishop.co.za/store/usb-to-usb-isolator-12mbps-speed-adum4160adum316).

The OG 5.6 has been quite solid using the RS232 port (with an adapter from RS232 to USB), but lately it's beginning to get worse, with similar behavior to the OGPLUS 6.2.

I had similar issues with my previous Axpert VMIII, so I'm inferring this is a systemic issue with the voltronic inverters.

Is there any solution to improve the robustness of these ports?

Is the problem triggered by the relatively rare commands of more than 5 characters? With 2 CRCs and a carriage return, that makes more than 8 bytes per command, and with Python library functions (and possibly others), you have to split longer commands into two that are both 8 bytes or less.

Even USB comms goes through opto isolators (at neck breaking 2400 bps!), and these do degrade with time. Perhaps whatever cooked the RS-232 port damaged or "wounded" the optos. Part number COSMO1010 comes to mind. I believe that these optos and the rest of the comms circuitry are inside with the display drivers in models with the round display. Or they might be separate from the display.

Interesting! The only command I run every second is QPIGS, which looks like 8 bytes total for the transmit. The receive is much longer (around 150 bytes), and quite often has errors (on the order of 10 receive errors per hour). My program is written in C, and uses the virtual devices /dev/ttyUSB0 (RS232), or /dev/hidraw (direct USB) via open(). My soldering skills are in the range where it's probably not worth it for me to try replace that chip, but if it gets unbearable, I might try open it up. This is the one with the round display. Are you saying that the chip would be in that detachable bottom module, or inside the main big box?

20 hours ago, Ben Harper said:

This is the one with the round display. Are you saying that the chip would be in that detachable bottom module, or inside the main big box?

Oh, yes; the 5.6 models have the round display. On those, I believe that the detachable bottom panel is just a cover for the cabling, and all the display electronics is inside. I don't know much about those, except that from the display firmware, it looks like three separate displays.

I don't know if you might be able to buy just the display PCB(s) or not. Or even if the optos are on the display PCB, or on the "comms" board, similar to models with a removable display. Sorry.

20 hours ago, Ben Harper said:

The only command I run every second is QPIGS, which looks like 8 bytes total for the transmit. The receive is much longer (around 150 bytes), and quite often has errors (on the order of 10 receive errors per hour).

I think that some of this is poor design; they only have one RAM buffer for the command responses, and I think it's possible for two responses to become mangled under certain conditions, So it may not even be a hardware problem.

How often do you send the commands? It seems that you have to allow about 3.3 seconds between commands (3 sets per 10 seconds) to stop them tripping over each other. If they used a more reasonable serial bit rate, the chances of responses overlapping would be lower.

3 hours ago, Coulomb said:

Oh, yes; the 5.6 models have the round display. On those, I believe that the detachable bottom panel is just a cover for the cabling, and all the display electronics is inside. I don't know much about those, except that from the display firmware, it looks like three separate displays.

I don't know if you might be able to buy just the display PCB(s) or not. Or even if the optos are on the display PCB, or on the "comms" board, similar to models with a removable display. Sorry.

I think that some of this is poor design; they only have one RAM buffer for the command responses, and I think it's possible for two responses to become mangled under certain conditions, So it may not even be a hardware problem.

How often do you send the commands? It seems that you have to allow about 3.3 seconds between commands (3 sets per 10 seconds) to stop them tripping over each other. If they used a more reasonable serial bit rate, the chances of responses overlapping would be lower.

I wait 500ms between reads, so perhaps that explains why I frequently get CRC errors.

It's unbelievable how stagnant the software/firmware is on these things. I keep feeling like there's an opportunity for an open source inverter design, but you'd need to be independently wealthy to fund a low margin effort like that.