Hi all, I've been working on this issue w/
@HighTechLab. Props to him for really enthusiastic customer support.
My inverter is a Sun Gold SP6548. My understanding is that it is a relabel of the MPP, so presumably there is a shared root cause.
Here's a brief recap of my exploration:
At first I thought the battery was not configured for the correct protocol.
@HighTechLab helped me out with this, but the configuration turned out to be correct. Also tested with a replacement cable, no dice.
So then I started digging. I made some breakout cables and inspected the signals with an oscope, and man, dirty signals. Lots of switching transients and just plain noisy on the inverter side (the SOK side was clean BTW). Figure maybe it was a data corruption issue. Played with terminations and filtering, cleaned up a little, but still no love.
Then I attached a RS-485 adapter to the line to monitor. Turns out the data seemed okay. Yay for differential signaling! Even checked all the packet checksums and they were all good. I also confirmed that the battery was indeed responding to query/commands from the inverter. Conclusion: it is not a data link integrity issue.
So, using protocol definitions found on the web, I started digging into the messages. The inverter scans for and queries the battery for its protocol version (CID2=4F) several times and then issues commands that are not in my documentation, but the battery responds. E.g. CID2 = 61, 62, 63. After several seconds of this, the inverter throws comms (61) error. Sometimes (I don't think every time, but I may be missing it) it throws a "low battery" (04) error first.
My current hypothesis is that the inverter and BMS have incompatible protocol implementations. Unfortunately, I don't have any documentation for what the messages *should* be, so it's hard to make more progress from here. I would suspect the Sun Gold was in error due to the undocumented command IDs, but the battery does respond, so... *shrug*
I'll be waiting to hear from Sun Gold support. Hopefully a firmware upgrade can fix this.
@Scotts954, did you ever get any response from Sun Gold?
If anyone has anymore information about the Pylontech protocol, please share!
A data capture for the interested:
~0002464F0000FD9A
~200246000000FDB2
~0002464F0000FD9A
~200246000000FDB2
~0002464F0000FD9A
~200246000000FDB2
~20024661E00202FD32
~200246008062CFCDFF8E510001000164640CFA000F0CF900100BB50BB900020BB200040BC30BC300010BC300010BC20BC200010BC20001E897
~20024661E00202FD32
~200246008062CFCDFF8E510001000164640CFA000F0CF900100BB50BB900020BB200040BC30BC300010BC300010BC20BC200010BC20001E897
~20024661E00202FD32
~200246008062CFCDFF8E510001000164640CFA000F0CF900100BB50BB900020BB200040BC30BC300010BC300010BC20BC200010BC20001E897
~20024662E00202FD31
~20024663E00202FD30
~20024600D012E100AF0003B603B6C0F9B5
~20024661E00202FD32
~200246008062CFCDFF8E510001000164640CFA000F0CF900100BB50BB900020BB200040BC30BC300010BC300010BC20BC200010BC20001E897
~20024662E00202FD31
~20024663E00202FD30
~20024600D012E100AF0003B603B6C0F9B5
~20024661E00202FD32
~200246008062CFCCFF8E510001000164640CFA000F0CF900100BB50BB900020BB200040BC30BC300010BC300010BC20BC200010BC20001E898
~20024662E00202FD31
~20024600800800000000FC22
~20024663E00202FD30
~20024600D012E100AF0003B603B6C0F9B5
~20024661E00202FD32
~200246008062CFCCFF8D510001000164640CFA000F0CF900100BB50BB900020BB200040BC30BC300010BC300010BC20BC200010BC20001E899
~20024662E00202FD31
~20024600800800000000FC22
~20024663E00202FD30
~20024600D012E100AF0003B603B6C0F9B5
~20024661E00202FD32
~200246008062CFCCFF8D510001000164640CFA000F0CF900100BB50BB900020BB200040BC30BC300010BC300010BC20BC200010BC20001E899
~20024662E00202FD31
~20024600800800000000FC22
~20024663E00202FD30
~20024600D012E100AF0003B603B6C0F9B5
<repeats>