[hydrochloric]

Originally Posted by DaveAK

Not sure if it relates to your particular problem or not, but you do mention it in the OP. It's my understanding that CAN Bus does require a common ground.

I had the same understanding (though I never found anything that said it HAD to be so). However, the way the CAN connects more or less prevents grounding the charger's communication port. Basically, these chargers have a 7-pin connector, which can be wired up to a contactor and other bits. That's the basic system, wherein the BMS turns the contactor on and off.

The other way, and the way our charger is hooked up, is that 7-pin connector goes to a pre-made module that has two pins: CAN-H and CAN-L. I would link a manual, but I can't find any that have the pins and control scheme layout. So if the connector needs to be grounded, it will be VERY difficult to extract the wires (especially since the interior of the module has been covered in... epoxy, I guess). I did find some info from the eLithion BMS, where there's a wiring diagram for the charger. http://lithiumate.elithion.com/php/elcon.php Way down at the bottom of the page. Weirdly though, the only reason THEY extract the wires is to activate a relay telling the BMS the charger is working, not to ground the unit.

There is some additional info on the eLithion page, like our charger, which is older, can only handle 2 messages/second, and at a speed of 250kHz. I can't try changing the BMS CAN speed, however, because of the BMS issue.

The BMS issue was partially fixed. The newer software caused the cells to automatically start balancing. I haven't had a chance to further diagnose to see if it's a software issue, or a user error. The BMS is currently running the old software, but that doesn't allow any control over the CAN interface (and removes the hopefully very convenient feature that shunts CAN messages to the USB output).

I'm in school from 8-3 most days, and here in NY, while we are still enjoying (absurdly warm) 50-60 degree weather, the actual time that can be spent in an unheated barn is about 11-3 (though I usually get too absorbed and end up coming in at about 7, completely frozen ). Basically, I'm having a hell of a time having time to diagnose it.

I think the next step will be to try to get the charger communicating sans battery pack, then dealing with the dead cells, and charging it all finally. Hopefully I'll be able to work on it tomorrow. Otherwise I don't think I'll have a chance to work on it until the weekend.

[Elithion]

Originally Posted by hydrochloric

I did find some info from the eLithion BMS, where there's a wiring diagram for the charger. http://lithiumate.elithion.com/php/elcon.php

Well, it makes us feel good when users of other BMSs end up looking for tech support on our website .

Originally Posted by hydrochloric

Weirdly though, the only reason THEY extract the wires is to activate a relay telling the BMS the charger is working, not to ground the unit.

It's not to tell whether the charger is working.
It's to power the BMS whenever the EV is plugged in.

Indeed, technically CAN is a 2-wire bus, meaning that ground is not required; thought, in practice, is it is usually connected.

[hydrochloric]

Originally Posted by Elithion

Well, it makes us feel good when users of other BMSs end up looking for tech support on our website .

Your site is a Godsend for info on the ElCon charger. Their site doesn't even have a complete manual, and their support is... brusque, at best.

Originally Posted by Elithion

It's not to tell whether the charger is working.
It's to power the BMS whenever the EV is plugged in.

Indeed, technically CAN is a 2-wire bus, meaning that ground is not required; thought, in practice, is it is usually connected.

Ah. Not knowing the pinout, it was a guess that the wire enabled the charger, not the other way around.

That's more or less what I had discovered (and inferred). Since there's a Low and a High, the potential is the bias across them, not to ground.

I managed to fix the battery drain issue, it was in fact my own error. The max charge voltage had been set to 2V, so the modules were doing what they were supposed to- draining the cells to 2V.

It still hasn't fixed the charger issue. I've fiddled with the settings to no avail, so the next step is to get a CAN to USB hookup, see what the bus is actually seeing. Also, haven't had a chance to see if the dead cells have recovered far enough for the main charger to charge them (>2.2V).

[Elithion]

Originally Posted by hydrochloric

It still hasn't fixed the charger issue.

Again, from Elithion's site, here's a troubleshooting guide for CAN bus issues.
It is geared to people with just a voltmeter / ohmmeter.

[Coulomb]

If you want to debug the CAN circuitry and/or protocol yourself, you may find the following pages helpful:

Elcon charger RS232 experiments and partial CAN box circuit; using Driver Controls to send and receive CAN packets; using a CRO; 74C04 based converter (circuits here and here); how CAN IDs are constructed.

I hope I got those links right.

[hydrochloric]

Originally Posted by Coulomb

If you want to debug the CAN circuitry and/or protocol yourself, you may find the following pages helpful:

Elcon charger RS232 experiments and partial CAN box circuit; using Driver Controls to send and receive CAN packets; using a CRO; 74C04 based converter (circuits here and here); how CAN IDs are constructed.

I hope I got those links right.

I had found your Miata project on AEVA before I even posted here, when I was searching around about charger information, but I never saw these pages! The amount of information is mind-boggling, and I fear my very limited hardware knowledge will present a large impediment. I only got to basic digital circuits before I switched from EE to ME...

Part of the issue is that I've been having trouble finding basic info on CAN busses, everything I've found seems to assume that I already know how to setup a network, and understand all the data. ...which I don't.

So, from what I've read, the CAN data that the BMS sends out needs to have the same ID as the charger's CAN module (in my case, 0X 18 06 E5 F4 - this is written on the case of the charger CAN module)? I have configured the BMS to use 250kbps speed, and Extended 29bit IDs. I didn't set the ID to the above number, I wasn't aware that should matter.

One of the other things I noticed you had done was viewed the charger's 7-pin output via RS232? It had been decided to get a CAN>USB adaptor, but this would make it seem that's not necessary? The BMS has an option to "Send to RS232/USB", but this doesn't appear to be working (I think it needs to have a confirmed connection before the forwarding occurs). I know you have a different BMS, so that's probably not helpful.

In a previous post, Elithion linked to a bit of troubleshooting without a scope. The bus measured at 80Ω, IIRC, with 2 120Ω resistors. The voltmeter section had this:

Originally Posted by Elithion

Voltmeter testing

Power up all the devices on the CAN bus
Measure the voltage of the 2 CAN bus lines.
The voltage should be about 2.5 V to ground, on both lines
If a line is sitting at 0 V, it is shorted to ground, or there is no connection to it
If a line is at 4 V or so, a CAN driver on the bus is broken, or various devices on the CAN bus are set for different data rates
The voltage of the CANH line should be more positive than the voltage on the CANL line (on the order of 100 mV, depending on how much data is on the bus)
If the other way around, the CAN bus lines are reversed
If no difference in the voltages, there is no CAN communication, or the 2 lines are shorted to each other

When just the BMS is powered, the voltages read at 2.6 and 2.4 (or thereabouts). When the charger is powered on, the voltages change significantly- Low ends up at about 1.7, High at about 3. This is from memory, and before I changed the BMS bus speed, so it's not totally accurate, but it still seems to point to an issue with the charger's CAN, correct?

[DJBecker]

CAN bus uses a differential pair. Transceiver chips can handle a significant offset (difference in local ground potential), some over 40V of offset. But an offset degrades reliability and noise immunity.

This ability is mostly useful in an industrial installation. In an automotive system there isn't any good reason to have more than an incidental offset (a volt or two) from frame ground. You certainly don't want to rely on the differential pair to establish the common ground.

Debugging CAN messages doesn't require expensive equipment, just a $20 bluetooth or USB OBD2 reader from FleaBay. Keep in mind that CAN bus is a little quirky in that it requires at least two active nodes. A sending node needs at least one active listener to send a single bit ACK at the end of the message, or it thinks the transmission didn't work. And most code readers don't act as an active listener -- they don't send the ACK bit.

[hydrochloric]

So the CAN devices SHOULD share a common ground? This has been one of the most difficult things to find an answer to. From what I found, the data is transferred by the difference across the High and Low, not referenced to ground. Do all the devices need to be referenced to ground just to have a voltage on High/Low at all?

The nodes might be the main issue- I don't think both are active. I do have a WiFi OBD2 reader (PLX Kiwi WiFi), but I don't know of any way to hook that up to a computer in any useful way (nor any way to use it as a monitor device, since it is set up specifically for OBD codes).

What software would one use for such a device? A straight serial port viewer?

[Coulomb]

Originally Posted by hydrochloric

So the CAN devices SHOULD share a common ground? This has been one of the most difficult things to find an answer to.

I think so. The electronics on the charger is connected to the negative of the pack, but they seem to use an isolating CAN chip, so the CAN wires (CAN-HI, CAN-LO, and CAN-GND) are all isolated from the pack. So connect CAN-GND from the charger to CAN-GND of the BMS. (Also CAN-HI and CAN-LOW need to connect, obviously).

From what I found, the data is transferred by the difference across the High and Low, not referenced to ground. Do all the devices need to be referenced to ground just to have a voltage on High/Low at all?

My recollection is that the bus normally has about two volts on it, I forget where that comes from, and for an active, bit, the two ends are "shorted" together. In order for the electronics to be able to pull the two pins together, they can't be hundreds of volts different from the CAN-GND that the chips are referenced to.

[ Edit: My recollection wasn't very good. The absolute voltage of CANH and CANL doesn't matter, within limits. Most of the time (with no messages on the bus), the bus will be in a "recessive" state, where the difference between the two signals is less than about 0.4 V. When (I think) a zero is being transmitted, the voltage difference is at least 0.9 V. If you are measuring a bus where there is nothing acknowledging the messages, they will be re-transmitted over and over with no gap, so it's quite possible to see about 2V more on one wire than the other, as averaged by a multimeter. ]

Remember that while I'm using the CAN version of the charger, I'm not using an actual CAN bus, just the RS232 that I reverse engineered. So I'm not familiar with the details of the actual CAN bus. We're not using the separate CAN box, just the cable.

What software would one use for such a device? A straight serial port viewer?

You could, if you built up the simple circuit I was using, and set the straight serial viewer to 2400 bps. That's assuming that they haven't changed the RS232 details; since it's not published, they are free to change how it works internally. Be aware that if you build the simplest of circuits like I did, then that circuitry will be connected to the negative output of the charger. It would not be hard to use a circuit that did opto isolation as well. With my early circuits, I was just wanting to talk to the charger at all.

[Coulomb]

Originally Posted by hydrochloric

So, from what I've read, the CAN data that the BMS sends out needs to have the same ID as the charger's CAN module (in my case, 0X 18 06 E5 F4 - this is written on the case of the charger CAN module)?

Yes, this is necessary. Actually, there are two magic numbers, that's only one of them. This is the ID that the charger is looking for to accept voltage and current commands. The other will be the ID that the charger outputs present voltage and present current (I didn't say current current :-) ) which the BMS should be looking for, unless it has access to the battery voltage and charge current already. I was assuming that the BMS was all set up for talking to this exact charger - a few of them are, since the Elcon is fairly common. Oh, the ID the charger outputs on seems to be 0x18FF50E5. So you might have to configure the BMS to listen for that number, too.

I have configured the BMS to use 250kbps speed, and Extended 29bit IDs.

Good. That's important.

I didn't set the ID to the above number, I wasn't aware that should matter.

Well, maybe the addresses are fairly standard... but I'd certainly check. If you can see what the charger and BMS are putting out, then you can see what they are sending, but you can't explicitly see what they are listening for. I guess that's why the listening number is on the side of the CAN box.

One of the other things I noticed you had done was viewed the charger's 7-pin output via RS232?

Yes, since at least the old models didn't support a "real" CAN bus, and we were using RS-485 anyway for the BMS, we figured it was easier to not use the CAN box at all. Fortunately, the protocol was very easy to figure out, once I got past a few issues (such as blowing up an opto in the charger... sigh.)

The BMS has an option to "Send to RS232/USB", but this doesn't appear to be working

Well, maybe it's worth pursuing that. I would exect to see the BMS sending out packets, even if the charger isn't responding to them. But you may be right.