We are experiencing erratic usb to ve-direct communication issues between a mpii5gx and a bmv712 (as powermeter).
The issues occur with both the single as the quadruple duppa.net isolated usb to serial boards.
Another bmv712 (as batterymonitor) connected to the gx directly (no usb) works flawless.
The workaround that is holding up since this morning is to use a very short 30cm USB cable. Previously known good usb cables 1,5m fail to stay connected, that might hint to the root cause being in the usb driver.
Issues starting with f/w v3.60~68
Hi Jan, does this also happen with v3.55?
I did not test on v3.55. Its an erratic issue making it a bit harder to figure out how to replicate. If I manage to find a way to replicate/resolve the issue reliably I will report back but it may take some time before I get round to that.
Could you point me to any logs that I could monitor to see what’s going on under the hood?
Hi @mpvader ,
I failed to reliable replicate the issue on v36~69 which makes it hard to pinpoint the root cause. I’d be willing to dig a little deeper if I knew where to look under the hood for better indicators for what part of the signal chain is failing, instead of relying only on the end result of the BMV being recognized or not.
Speaking of the devil: I added a 1 meter USB extension cable and the USB to ve-direct connected BMV disappeared after an hour of high power charging, and reappeared when charging ended. Albeit anecdotal still, this behavior does not happen with the short USB cable only, this strengthens my hypothesis that the USB connection h/w and/or driver is running ‘on the edge’ of it’s electrical/interference limits.
PS, this all on a MPII5000GX so this could well be an issue limited to this GX h/w.
Further observation learns this connection issue is directly correlated to usb cable length and operational power of the inverter. This strongly suggest an EMI issue with the internal GX’s usb poort of the MPIIGX.
@mpvader : If at all posible, could you take a look our system during the next high price hours (evening) when the inverter is selling back to the grid at maximum power? If you let me know in time I will connect a longer usb cable to ensure the connection to the BMV will get lost.
Nearly the same Problem in my installation. Setup is MPII3000GX, Duppa 4 Channel, all 4 Ports connected to MPPT´s.
I digged a little bit deeper and discovered the following entry when executing dmesg in SSH.
[ timestamp] usb usbX-portX: disabled by hub (EMI?), re-enabling...
Therefore I put clip on ferrites on the ve.direct and USB-cables but this made it even worse.
I also checked the ve.direct signals with a oscilloscope an they looked very nice and crispy. It is an sporadic issue so maybe i checked the signals at the wrong time.
I did not check the USB-signals.
Any ideas to get around the problem? Should I try clip on ferrites only on the usb-cable? On the Duppa side or on GX side or both?
Hi @Paul-Gerhard,
After monitoring this issue for some time I’m pretty convinced it is usb & EMI related indeed. Any usb cable over one meter triggers connection issues when the inverter runs on high power. The only workaround that seems stable to me is to make the usb connection as short as possible and use extended ve-direct cabling (diy, not ideal).
Hi @UpCycleElectric ,
thanks for your reply and your suggestion. I will check if I can use a shorter USB-cable.
I also think it is caused by EMI.
By the way I do not use beta firmware, so I think it is hardware related.
It would be realy nice to have a portrait picture of the SmartSolar-GX-PCB/NanoPi-carrier-board, to check if vcitron put a common mode choke in the data lines of USB.
Maybe @mpvader or a hardware guy from victron can provide some information?
I am currently not willing to disassemble my MPII to have a look.