I've been trying to suss out the protocol on pins 6 and 7 of the charger, when used with the CAN interface. RS232 is easier for experimentation than CAN bus, at least until our Tritium Drivers Controls box arrives (should be soon).
Pin 7 of the charger seems to send crude RS232 (approx 0.2 to 7 V) from the charger; it seems to expect data on pin 6. Pin 2 is ground.
The protocol is 2400/N/8/1; yes, that's 2400 baud! I was expecting at least 9600, possibly 19200 or even 115200. I suppose there is still plenty time to send 12 bytes (~ 50 ms) every second. This is perhaps why sending more than 2 packets per second confuses the charger; the 2400 baud link is a bottleneck.
The charger sends these 12 bytes every second: 18 FF 50 E5 VVVV IIII SS 00 00 00
VVVV is the voltage in tenths of a volt, MSB first, e.g. 03 F0 = 100.8 V
IIII is the current in tenths of an amp, e.g. 00 0A = 1.0 A
SS is the status, as per the lithiumate page, e.g. $10 = communications error (no CAN packet in 10 seconds).
Initially, this comes through as 18 FF 50 E5 00 0A 00 00 10 00 00 00
meaning as far as I can tell "I'm sending 1 packet per second, 8 bytes, some code = $3F destination = all (broadcast), my ID is E5 (charger), present voltage is 1.0 present current is 0.0 status is comms error". Indeed, there does seem to be about 0.67 VDC on the charger output; I'm guessing it's leakage.
I relied very heavily on this Lithiumate page
for most of this.
18FF50E5 happens to be the ID mentioned on that page for the status packet from the Elcon charger. The message generated by the Lithiumate BMS is 1806E5F4, which happens to match the number printed on the top of the CAN interface box. So it seems that this is the ID that the Elcon must be expecting.
So presumably what I need to send back is 18 06 E5 F4 10 08 00 0A 00 00 00 00
which I think says "Charger, I'm the BMS, please dial up 410.4 V @ 1.0 A and turn yourself on".
I've written a simple program to send these bytes continuously with a 1 second delay between them. Unfortunately with Windows, you can't run two comms programs on the same port (Linux has no problem with this), so it's not easy to see the results coming back from the charger (at least until I find some example serial port reading code to adapt).
Alas, when I run this, I still get the seven-light code which means "communications interface fault".
So now I'm considering what might be wrong.
I measure about 1M resistance from pin 6 to pin 2, so there seems to be something "listening" (and there isn't an open circuit in the RXD wire). Maybe it wants the RS232 to be clipped at 0V like the charger is sending, but that seems unlikely. I suppose it could be expecting opposite polarity, but that also seems unlikely.
Maybe I need to wait for the status packet to come out before sending back the "BMS" packet. Comments welcome.
[Edit: other code -> broadcast address; E5 = charger]
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, PIP-4048MS inverter, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.