# CAN Bus problems....



## cruisin (Jun 3, 2009)

hydrochloric said:


> Hello all,
> 
> About 3 years ago (ish. It's been a while) my father and I began converting a '95 Probe GT to electric. It went through some necessary changes (read: newer controller when we blew up the first one) and we've now had it to the point where it drives for most of the summer. It's got an auto, annoyingly, but having found all the threads on here detailing ways to keep pressure, that shouldn't be an issue (though I myself would have preferred a manual). Recently, I began finishing all the little bits, making power cables, doing the little bits of wiring, etc.
> 
> ...


Get a hold of the distributor and repair agency for Elcon in Sacramento, CA and they will help you.


----------



## Brute Force (Aug 28, 2010)

As chance has it, I came across this as I was reading yesterday:

"The engineers at ElCon designed a CAN engine in software and used the RS232 lines to drive a CAN buffer. The result is a CAN implementation that works, but only if there are no messages on the CAN bus other that the ones it expects. The presence of more than one CAN message per second on the CAN bus will freeze the charger's CAN engine."

Footnote 3, Page 196, Battery Management Systems by Davide Andrea


----------



## MindMil (Jul 22, 2008)

Hi,

I am one of the designers of Emus BMS and we are investigating this issue. A suggested possible interim solution with new software version was provided to Hydrochloric in private.

We are ready to discuss this issue to resolve it.

Best Regards,
Mindaugas Milasauskas


----------



## PhantomPholly (Aug 20, 2008)

Nothing like the internet to bring about better customer service!


----------



## hydrochloric (Oct 23, 2011)

Well, new issue (both with the BMS and the board here). I have attempted to reply to MindMil's PM, but the system seems to not be working, as there is never a new message in my sent box. I can post my message here, if it is not actually sending.


----------



## hydrochloric (Oct 23, 2011)

cruisin said:


> Get a hold of the distributor and repair agency for Elcon in Sacramento, CA and they will help you.


I also tried this. They were... unwilling to help. Something about they hate dealing with End-users, for this very reason. I have since tried going through our source for purchasing, but am getting no response.


----------



## DaveAK (Jun 28, 2009)

No mention of the baud rate for either charger or BMS. Have you checked they're both set to the same baud rate?


----------



## hydrochloric (Oct 23, 2011)

Well, I'd love to play around with it, but at the moment, the car is dead. The problem is, the modules failed and started discharging the pack across the balance resistors, and due to the way we constructed the pack, we had to partially disassemble it to disconnect the modules (and cease the discharging).

Right now, we have three separate cells that have dropped to 1.5V. Hopefully we'll be able to recover these separately.

Strangely, even after the removal of the cell modules' power, when they are re-connected, they immediately begin discharging the cells again, and the red (presumably "Error") LED comes back on.

So currently, the car is dead, and the BMS is not functioning. I have sent an email to Elektromotus (since I can't seem to get a PM to send here). Once this issue is resolved, I'll go back to trying to get the charger online.

EDIT: I am currently discussing this issue through email.


----------



## DaveAK (Jun 28, 2009)

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.


----------



## hydrochloric (Oct 23, 2011)

DaveAK said:


> 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 (Oct 6, 2009)

hydrochloric said:


> 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 .



hydrochloric said:


> 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 (Oct 23, 2011)

Elithion said:


> 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.



Elithion said:


> 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 (Oct 6, 2009)

hydrochloric said:


> 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 (Apr 22, 2009)

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.
http://forums.aeva.asn.au/forum_posts.asp?TID=980&PID=27016#27016


----------



## hydrochloric (Oct 23, 2011)

Coulomb said:


> 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 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:



Elithion said:


> Voltmeter testing
> 
> Power up all the devices on the CAN bus
> Measure the voltage of the 2 CAN bus lines.
> ...


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 (Nov 3, 2010)

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 (Oct 23, 2011)

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 (Apr 22, 2009)

hydrochloric said:


> 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 (Apr 22, 2009)

hydrochloric said:


> 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.


----------



## hydrochloric (Oct 23, 2011)

Coulomb said:


> 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.


Well, a small update, actually from yesterday. I had enough time (and just enough heat) to attempt changing the "Can ID Base" in the BMS software, and it didn't work. However, I couldn't even enter the whole base. Basically, the BMS allows four characters, and no letters. Assuming that I only need the "18 06 E5 F4", I can't enter it all, and I can't enter any of the letters...

I also checked the voltages on CanL and H again. When the BMS is on, the voltages are correct. When the Charger is turned on, they still sag and raise, by about 1 volt and half a volt. I'm beginning to suspect the charger's CAN module is damaged. It was suggested (and I will hopefully attempt this tomorrow) that I try using a pair of headphones to listen if both units are outputing anything.

Otherwise, no updates, besides that I'm currently trying to resurrect the dead cells. I have one of my R/C chargers, set on LiPo mode, 2A rate, with the highest capacity I can choose, 9.9Ah... Only 110Ah away!  So far, it's been charging for 276 minutes, it's at 3.3V, and the charger'll soon time out. I may leave it be at that point, if it holds 3.3V.










The little black thing in front of the charger and DMM is a webcam, so I could monitor it on my iPod, around the house.


----------



## hydrochloric (Oct 23, 2011)

Actually, one more thing now I think about it.

I did manage to get the CAN module's charger-side connector apart with no damage, with the intent to run a GND wire. However, just like the CAN module itself, the connector backing has been filled with the rubbery silicone stuff, and because the connector is completely symmetrical (and it only labels the center pin- NOT HELPFUL) I can't be sure which wire is GND. However, knowing that the four wires to the module are +12V (IIRC, might be 5), GND, RX+ and TX+, and the physical wires are red, black, green and blue, I'll bet on GND being the black one.

That a safe assumption?


----------



## Coulomb (Apr 22, 2009)

hydrochloric said:


> I did manage to get the CAN module's charger-side connector apart with no damage, with the intent to run a GND wire. However, just like the CAN module itself, the connector backing has been filled with the rubbery silicone stuff, and because the connector is completely symmetrical (and it only labels the center pin- NOT HELPFUL) I can't be sure which wire is GND.


The ground at the 7-pin connector end is isolated (I believe) from the ground at the CAN bus end. So access to the ground in the 7-pin connector is not helpful, and would be dangerous since it connects to pack negative when charging.

Doesn't your CAN box come with a connector like this?










If so, I think you want to connect to the ground that is the shroud of the CAN connector (the screw holes in the foreground).

Wikipedia article on the physical CAN bus: http://en.wikipedia.org/wiki/Controller_area_network#Layers . So we can see that the bus is either floating (with no voltage between CANL and CANH), or one or more transcievers pulls CANL to ground, and CANH to +5V.

Reading between the lines, it seems to work like this. Each transceiver either leaves the bus alone, or pulls the wires apart. They attempt to pull CANL towards their own ground, but through a diode so that if CANL is already negative with respect to the transceiver's ground, no harm is done. But that means that another transceiver is pulling the wires apart, so CANH will be around 5V more positive than CANL, but the total will still be less than the +5 V rail for the local transceiver, so its top transistor will still turn on. If all the power supplies are isolated, they will all just align when they are turned on, and float when off.




> That a safe assumption?


As indicated above, I don't think so, and I now believe you don't need a common ground after all.


----------



## Coulomb (Apr 22, 2009)

I'll see if I can make it clearer with this:









Suppose another unisolated transceiver is pulling CANL to -10V (with respect to the local ground), and CANH to -5V. Now this transceiver tries to turn on. The lower diode is reverse biased, protecting the lower transistor. The upper diode is not, so the bus gets pulled from -5V to +5V (all WRT to the local ground). So now the bus has 15 V on it, and the resistors will draw 125 mA each, and dissipate almost 1.9W, so this would be an extreme example. If the local supply is isolated, it will float while the transistors are on, and approximately align itself with the other power supplies when on (since the lower transistors will effectively connect the grounds).

But as per the Wikipedia article, and to keep the resistors from getting too hot (and the CAN transceiver receivers from getting overvoltaged), it's probably a good idea to connect the CAN grounds. So I would still do this, using the shroud of the CAN connector (assuming it connects to anything).


----------



## hydrochloric (Oct 23, 2011)

Your second picture doesn't show.

Our CAN module is the later version, with plastic everything:








I am beginning to wonder what those two exposed pins are inside the module...

I was using the circuit you had reverse engineered to decide the GND should be connected.








I note (now) that it does mention GND is isolated. This seems to be yet another vote in favor of don't use/doesn't need a common ground.

I also read through the layers section of the Wiki.


wikipedia said:


> The standard (ISO11898-2) describes the electrical implementation formed from a multi-dropped single-ended balanced line configuration with resistor termination at each end of the bus. In this configuration a dominant state is asserted by 1 or more transmitters switching the CAN- to supply 0 V and (simultaneously) switching CAN+ to the +5 V bus voltage thereby forming a current path through the resistors that terminate the bus. As such the terminating resistors form an essential component of the signalling system and are included not just to limit wave reflection at high frequency. During a recessive state the signal lines and resistor(s) remain in a high impedances state with respect to both rails. Voltages on both CAN+ and CAN- tend (weakly) towards ½ rail voltage. During a dominant state the signal lines and resistor(s) move to a low impedance state with respect to the rails so that current flows through the resistor. CAN+ voltage tends to +5 V and CAN- tends to 0 V. A recessive state is only present on the bus when none of the transmitters on the bus is asserting a dominant state. Irrespective of signal state the signals lines are always in low impedance state with respect to one another by virtue of the terminating resistors at the end of the bus.


That sounds exactly like the way this bus communicates, though why it would enter a "dominant state" only when the charger is turned on is something I don't understand.

It's also barely broken 4ºC here, so I've been very reluctant to go out to the barn to try using the headphone technique to detect CAN data...


----------



## Coulomb (Apr 22, 2009)

hydrochloric said:


> Your second picture doesn't show.
> 
> Our CAN module is the later version, with plastic everything


Ah. Are there only two wires in the CAN cable? If so, assuming it really is isolated, then there is no way to get access to the CANGND (without digging out a lot more potting mixture than I did).



> I note (now) that it does mention GND is isolated.


Do you mean my page mentioned that, or TCCharger.com/english ?



> why it would enter a "dominant state" only when the charger is turned on is something I don't understand.


The +5V local that it needs to put the bus into a dominant state (more than 0.9 V between CANH and CANL) presumably comes from an isolated 5V to 5V DC/DC converter, which is powered from the charger. You can't (reliably) get power from the CAN bus, since it can stay in the 6recessive state (less than about 0.4 V difference between CANH and CANL) for arbitrarily long periods of time.



> I've been very reluctant to go out to the barn to try using the headphone technique to detect CAN data...


Wit the data rate at 250 kbps, headphones may not register anything. One entire CAN message is some 20 bytes, or 160 bits, which is still only 640 us, which is the time of one half cycle of a 1.5 kHz signal. I don't know if one half cycle can be heard, but I suppose you'd hear at least a faint click. The inductance of the headphones at 250 kHz would be high as well, further reducing output. So don't take it as definitive if you hear nothing.


----------



## Coulomb (Apr 22, 2009)

I've gone back and re-read the post where you said that the voltages had changed when the charger is plugged in. I've added an edit to correct my bad recollection of how CAN bus wires behave.

Here's what I think is happening. I think that your BMS doesn't care about messages from the charger. It only seems to be able to accept small CAN IDs. (There are two sizes of IDs, 11 bits and 29 bits; the charger is using 29 bits, and it looks like your BMS can only handle 11 bits). The charger will send out packets at ~1 second intervals, with the present voltage and current. Maybe your BMS doesn't care about that information, it will know the total pack voltage, and maybe it has some other way of measuring the pack current, or doesn't care. But the way the CAN bus works, you need some CAN device to acknowledge the message; otherwise, the transmitter assumes that the message was corrupted and re-transmits. Often there is absolutely no delay (or maybe just a microsecond or two). Any CAN receiver can acknowledge the message, and it doesn't have to be listening for it. But it does have to judge that it is a valid message. (There is no point in acknowledging bad messages).

Maybe if your BMS only handles 11 bit CAN IDs, any messages with 29 bit IDs may be considered invalid, and so it won't acknowledge them. Thus, once the charger transmits its first message, you will get infinite retries, and no messages can get onto the bus.

Then again, if the BMS can't transmit 29-bit IDs, it has no hope of talking to the Elcon/TC charger. It would be very strange if it could transmit 29-bit CAN IDs, but could not receive them.

So the big question is... is your BMS designed to talk to an Elcon or TC charger?

I see its an Electromotus BMS... I'm not familiar with it.

[ Edit: according to the Electromotus web site, it does seem to support TC chargers. So either that shoots down my theory, or the BMS just needs more configuration to talk to the TC charger. It only seems to support one type of CAN charger, so presumably it should be correctly set up, if the CAN bus is enabled at all. ]

In fact, running the charger with no BMS or battery connected should guarantee that you see lots of CAN bus activity, which you should be able to detect by a significant difference (at least half a volt) between CANH and CANL on a multimeter, and perhaps as a weird noise through headphones. Note that the headphones will be rather low impedance, and may disturb the CAN bus. I'd connect a resistor of at least 33 ohms, up to 100 or so ohms, in series with the headphones. That's another reason to not connect the BMS at least initially when using the headphones.

If you have the series resistor for the headphones, and can detect a noise, then when you connect the BMS, the noise should change from a continuous one to more of a series of clicks. That would indicate that the charger CAN messages are being acknowledged by the BMS, which means that the CAN bus is basically functional. But if it won't acknowledge messages with extended (29-bit) IDs, then you won't get the change of sound.

At work, I have a small box with a USB cable called a QuickCAN, which allows me to snoop on the CAN bus using a PC. If things get desperate, you might consider trying one of those. I seem to recall a check box where you can get the QuickCAN to acknowledge messages or not; the default is to not (so it doesn't disturb debugging of the system under test).

[ Edit: another test: does the LED flash code for "comms error" go away when the BMS is connected to the charger over the CAN bus? ]


----------



## hydrochloric (Oct 23, 2011)

Coulomb said:


> Ah. Are there only two wires in the CAN cable? If so, assuming it really is isolated, then there is no way to get access to the CANGND (without digging out a lot more potting mixture than I did).


I added that cable, but yes, there were only two pins originally in the connector.




Coulomb said:


> Do you mean my page mentioned that, or TCCharger.com/english ?


The schematic came from the AEVA page.



Coulomb said:


> Wit the data rate at 250 kbps, headphones may not register anything. One entire CAN message is some 20 bytes, or 160 bits, which is still only 640 us, which is the time of one half cycle of a 1.5 kHz signal. I don't know if one half cycle can be heard, but I suppose you'd hear at least a faint click. The inductance of the headphones at 250 kHz would be high as well, further reducing output. So don't take it as definitive if you hear nothing.


Well... I do hear something... But, uh... It's not exactly what I expected. What you see in the video is a little junction box I built, where the BMS' CAN goes in the side (In retrospect, I should have added a second 1/4" jack instead of hard-wiring the BMS' CAN), and it connects to a 1/4" jack to the charger's CAN, a 3.5mm jack for headphones/audio output, and a DB9, hopefully to see the data via the OBD2 monitor.
CAN comm. screaming
I should clarify what I'm doing, since I didn't say anything. Basically, when the charger's CAN is attached (the large mono plug), the headphones are screaming. It's WAY more piercing that it sounds in the video- so loud that when it first turned on I yanked the charger's power, unsure of what was going on. The BMS IS on here, so when I unplug the charger, I would expect to hear something as though the BMS's CAN were transmitting. But it goes dead. I also wasn't smart enough (read: my brain had frozen) to try unplugging the BMS to see if it changed. It should also be noted that I did hear distinct tone changes, though none appeared in the video.



> [ Edit: another test: does the LED flash code for "comms error" go away when the BMS is connected to the charger over the CAN bus? ]


Well... this is kinda the original problem. It doesn't matter what's done, the charger always flashes that code, the BMS always claims there's no charger.

Also, although it's not pertinent to the CAN issues, the "Top" cell module seems to have given up on us. It flashes it's green LED when first connected to power, but it won't communicate with the rest of the world. Sigh.


----------



## Coulomb (Apr 22, 2009)

hydrochloric said:


> Well... I do hear something... Basically, when the charger's CAN is attached (the large mono plug), the headphones are screaming.


Ok, good. It seems that the charger is sending packets, and isn't getting them acknowledged.



> It's WAY more piercing that it sounds in the video-


Yes, I suppose that basically 5 V square waves would make a hell of a racket in headphones. That's another good reason to use a resistor in series with the headphones.



> The BMS IS on here, so when I unplug the charger, I would expect to hear something as though the BMS's CAN were transmitting. But it goes dead.


Everything seems to point to the BMS not talking to the CAN bus. Maybe there is a setting for turning on the CAN bus? Maybe the charger uses other means of controlling the BMS by default.



> Well... this is kinda the original problem. It doesn't matter what's done, the charger always flashes that code, the BMS always claims there's no charger.


Right. So neither can see the other. That's still consistent with the BMS not talking on the CAN bus at all.



> Also, although it's not pertinent to the CAN issues, the "Top" cell module seems to have given up on us. It flashes it's green LED when first connected to power, but it won't communicate with the rest of the world. Sigh.


I've recently helped debugging an Elite Power Solutions BMS, which I think is one of the better ones, and there were several cell-top modules that weren't working. So it seems that you need a few spares for some of these BMS systems. Or at least good warranty service from the supplier.


----------



## hydrochloric (Oct 23, 2011)

Coulomb said:


> Everything seems to point to the BMS not talking to the CAN bus. Maybe there is a setting for turning on the CAN bus? Maybe the charger uses other means of controlling the BMS by default.


From what I understand about this setup, the charger is controlled by the BMS, not the other way around. The charger has to be ordered with the CAN control setup, so unless it was improperly setup from the factory, it should already be configured. While the BMS does have an option for turning the CAN on and off, but I've made sure it's on (according to the software, anyway).

This is the CAN config page of the BMS (no visible settings, since the BMS isn't connected). Under the "Charger" tab it allows the selection of either "Elcon with CAN" or "Non can-enabled charger". Of course, it's set to "Elcon with Can".









It's possible that the BMS won't send CAN data without having all the cells connected, I suppose, but I would think it would still acknowledge received data.

I need to get the OBD2 interface working, but last time I used it I didn't have any serial port software, just the OBD2 software, which needles to say won't work.


----------



## cruisin (Jun 3, 2009)

hydrochloric said:


> From what I understand about this setup, the charger is controlled by the BMS, not the other way around. The charger has to be ordered with the CAN control setup, so unless it was improperly setup from the factory, it should already be configured. While the BMS does have an option for turning the CAN on and off, but I've made sure it's on (according to the software, anyway).
> 
> This is the CAN config page of the BMS (no visible settings, since the BMS isn't connected). Under the "Charger" tab it allows the selection of either "Elcon with CAN" or "Non can-enabled charger". Of course, it's set to "Elcon with Can".
> 
> ...


Dont take a chance, use the non Elcon setting and turn the Elcon on and off with the red and black wires. This works best and is reliable.


----------



## hydrochloric (Oct 23, 2011)

At the moment I can't even take "the chance", since the charger simply sits there refusing to do anything. But regardless, the charger would have to be re-ordered, since they are configured for either CAN or Enable control. Besides, with LiFePo cells, I would rather have the on-cell monitoring and precise charger control the CAN bus offers, not to mention the ability to slow the charge rate for 120V outlets.


----------



## Coulomb (Apr 22, 2009)

hydrochloric said:


> But regardless, the charger would have to be re-ordered, since they are configured for either CAN or Enable control.


If you do get desperate, there is a company in the US that can reprogram Elcons, I think it's [URL]http://www.elconchargers.com;[/URL] they can re-program an Elcon to a different voltage (if within the range of the charger model, obviously), Lead acid verses lithium, different sets of curves, and presumably CAN vs non-CAN.

So you do have that option, without having to ship the charger back to China. You'd just be throwing away the ~ $45 for the CAN option.

But I agree, CAN is much more flexible and should give better control. If you get it working, of course.


----------



## bjfreeman (Dec 7, 2011)

DaveAK said:


> 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.


Can bus has nothing todo with the communication protocol (RS232, 422) I recommend 422 since it works in a noisy environment and at 5 volts.


----------



## Coulomb (Apr 22, 2009)

bjfreeman said:


> Can bus has nothing to do with the communication protocol (RS232, 422) I recommend 422 since it works in a noisy environment and at 5 volts.


Huh? CAN specifies everything except the connector, and you have 0-8 bytes of data that you can format any way you like.

From Wikipedia's RS-422 entry: "Protocols and pin assignments are defined in other specifications."


----------



## bjfreeman (Dec 7, 2011)

Coulomb said:


> Huh? CAN specifies everything except the connector, and you have 0-8 bytes of data that you can format any way you like.
> 
> From Wikipedia's RS-422 entry: "Protocols and pin assignments are defined in other specifications."


so how is what you said, any different from what I said.
http://en.wikipedia.org/wiki/Controller_area_network


----------



## DaveAK (Jun 28, 2009)

bjfreeman said:


> so how is what you said, any different from what I said.
> http://en.wikipedia.org/wiki/Controller_area_network


What's any of it got to do with what I said?


----------



## hydrochloric (Oct 23, 2011)

DaveAK said:


> What's any of it got to do with what I said?


^ *That's* what I was wondering. 

Finally got ahold of the group we got the hardware through, too. They're talking to the manufacturers.


----------



## bjfreeman (Dec 7, 2011)

DaveAK said:


> What's any of it got to do with what I said?


I have included a CAN driver to clarify about grounds.


----------



## hydrochloric (Oct 23, 2011)

...which appear to be isolated. That implies the ground would just be shielding around the CAN pair.


----------



## bjfreeman (Dec 7, 2011)

yes and the shield should be connected to one end common point. not both ends.
also this defines the physical layer not the Can protocal.


----------



## hydrochloric (Oct 23, 2011)

Good news!

It's taken a long while, but there's finally communication! The BMS controller simply had no CAN output. Replacement arrived, and all is well (sort of). It's currently trying to jog some life back into the batteries, but there were some really bad cells, so... The lowest one after I tried bringing them back was something like 2.7v, so it should be able to charge.

Although very oddly right now, it's reporting that there's no current flow. Hmm.


----------



## hydrochloric (Oct 23, 2011)

Oops, forgot to set the cell parameters in the new BMS controller.  Now that's done...ish and the batteries are charging. Tons of parameters the HiPower sheets don't give...

Anyone know what a typical charge temperature of LiFePo4 cells is? At about 4.5ºC?


----------



## Lipo Louis (Oct 29, 2012)

Hey People,

I have problems too, I have the EMUS BMS working and have connected my CAN charger Elcon PFC 2500.

Please see attachments, do I need to fill in the CAN ID Address ? It is not possible to enter and X or F only numbers, and if I change it, it will automatically change to 8191.

Charger is blinking green, I also added the 120 ohm resistor. between CAN H and L.

Any idea what else I could try ?


----------



## circuit (Jan 16, 2012)

This looks like a new CAN-serial adapter ID is being used by TC/Elcon, which is not yet supported by Emus BMS. Probably this new ID will be hardcoded into new firmware, when it is released. Or you can order adapter from TC/Elcon with old ID.

CAN ID base, specified in the software is not for charger, it is for internal Emus device network.


----------



## Lipo Louis (Oct 29, 2012)

So, now there is an update but is there something to configure ?
I cant get to charge now


----------



## circuit (Jan 16, 2012)

I have just checked and confirm that new ID is included in latest firmware update. No additional configuration is required for it to work.
Is CAN interface enabled and proper charger selected?


----------



## Lipo Louis (Oct 29, 2012)

Can Interface enabled ? Yes I did select Can Enable as you can see on the picture 2 replies above. If that is what you mean.

I also select Elcon Can Charger, but the charger stays blinking green, waiting for communication.


----------



## circuit (Jan 16, 2012)

Have you checked if wiring is correct? Maybe try to swap H and L.
Do you have at least one 120Ω termination resistor on CAN line?
Disable the checkboxes:
- Periodic Data Broadcast (if you are not capturing data with other CAN device)
- Broadcast Each Cell Value (lots of data on CAN line can confuse the charger)
- Send to RS232/USB (this forwards all data from can to RS232)


----------



## twright (Aug 20, 2013)

What baud rate are yo using? The Elvin will only talk at the correct rate . (And I don't remember what it is.)


----------



## Lipo Louis (Oct 29, 2012)

Thanks ! A 120 ohm resistor between CAN + and - did the trick, pack is charging now.

But SOC is shown getting less, it started at 80 % SOC and now it is almost fully charged it is about 70% 

Also at consumption I see strange numbers and don't know how to reset it, even after reset the BMS, consumption is never 0.


----------



## circuit (Jan 16, 2012)

When charging, you should be seeing positive current reading, when discharging - negative. If sign is inverted, SOC will go to wrong direction. Also make sure that cell capacity is correct and that "SOC compensation from voltage" is disabled. I am not sure which version you are using and whether this function is still there.
Also you might need to calibrate a current sensor. First, enter numbers, written on bottom of current sensor, then reset current to 0 (when no current is flowing) and tick current inversion checkbox if needed.


----------



## Lipo Louis (Oct 29, 2012)

Thanks, that also worked !

Now maybe a tip about getting consumption to zero ?


----------



## circuit (Jan 16, 2012)

Consumption should normalize when there will be real distance driven and real current drawn. I'm not sure how it can be reset, probably by resetting statistics?


----------



## Lipo Louis (Oct 29, 2012)

Ok thanks, I wait till I can make a real ride etc. and see what happens.


----------



## Mark F (Aug 13, 2011)

Has anyone switched the CAN module connector from plastic (newer style) to metal on the charger side of the CAN module? I have a charger with the older style metal connector and I want to use a can module that has the newer plastic connector. The connectors have mostly the same color wires, can I assume they go to the same positions on the different connectors? Is there a risk of damaging something if they do not line up the same? Here is a photo.

Thanks.


----------



## bwjunkie (Jul 31, 2013)

I'll be without my BMS for a while, so I want to use a laptop with my USB Canadapter to send the codes to my Elcon Can-enabled charger so I can still charge my batteries. I don't know what the Can codes are yet, just that they have to be continually sent every 1-2 seconds?
Anyone know where the can message documentation is to complete this task for this charger?
thanks
josh


----------



## Coulomb (Apr 22, 2009)

bwjunkie said:


> Anyone know where the can message documentation is to complete


I have it, but I don't remember where I got it from; somewhere on what is now tccharger.com I think.

You do need to send it regularly; from poor memory, the timeout is around 5 or 10 seconds. So every 1 or 2 seconds should do. It's normally sent once per second.

Here is code to request 410.4 V and 1.0 A:

can.address = 0x1806; // Charger is expecting 1806E5F4
can.address_ext = 0xE5F4;
can.data.data_u16[0] = SWAP16(4104); // Request 410.4 V
can.data.data_u16[1] = SWAP16(10); // Request 1.0 A
can.data.data_u32[1] = 0; // Clear the rest of the data
can_transmit();

Obviously, you'll need to adapt that to your CAN software.

If you're sending data serially via the other end of the CAN box, you need to send these 12 bytes:

18 FF 50 E5 VVVV CCCC SS 00 00 00

where VVVV is the voltage in tenths of a volt, MSB first. CCCC is the current in tenths of an amp, and SS is zero unless you want to turn off the charger; then it's 01. More details here:

http://forums.aeva.asn.au/topic980_post30773.html#30773

The serial port should be 2400/8/N/1.

Here is a simple program for sending the serial data from a Cygwin prompt; it should compile for Linux by just changing a #define:

http://forums.aeva.asn.au/uploads/689/elconsend.zip

Warning: the AEVA (Australian Electric Vehicle Association) website is about to be ported to a new, Linux based platform, so the above may become unavailable soon. It's not referenced from a web page (I just uploaded it), so it may not be transferred at all.

Here is the main part of the above, leaving out the serial port and other details. Alas, the forum software has stripped out the leading spaces.

int main(int argc, char* argv[]) {

unsigned int uVoltage, uCurrent;

if (argc != 4) {
fprintf(stderr, "Usage: elconsend comport vvv.v ii.i\n");
fprintf(stderr, "Example: elconsend com17 100.8 1.0\n");
exit(1);
}
#if LINUX
...
#else
..
#endif

uVoltage = (unsigned int) (atof(argv[2]) * 10.0);
uCurrent = (unsigned int) (atof(argv[3]) * 10.0);

while (1) {
writeID(0x1806E5F4); /* This is the ID on the CAN box that the charger is expecting */
writeTwo(uVoltage);
writeTwo(uCurrent);
writeTwo(0x000); /* Turn on charger (0x100=0ff) */
writeTwo(0);

#if SEND_101112
...
#endif
#if DEBUG
printf("\n");
#endif
sleep(1); /* Do nothing for next second */
}


#if LINUX
close(fd);
#else
CloseHandle(hComm);
#endif
printf("Done\n");
return 0;
}


----------



## Coulomb (Apr 22, 2009)

Oops, I see you mentioned a Candapter. Looks like it's a serial to CAN adapter, like the one that comes with the Elcon charger (CAN version only), so obviously you need to talk to that at whatever speed and protocol it wants. Hopefully, you can just send the 12 bytes every second, and nothing else.

You could adapt the elconsend program, or write a script, Arduino program, etc. The main hassle with a command line script is escaping all the hex values, and converting voltages and currents to characters to echo to the comm port.


----------



## bwjunkie (Jul 31, 2013)

awesome, thank you SO much, I'm getting started this weekend otherwise I won't be able to charge my batteries and drive my Cortina 

I'll try the elconsend program first via cygwin otherwise I'll have to try to run it on my Raspberry Pi, which is my only Linux box at the moment 

But finally if nothing else I can try to write a c#.net script to write to the candapter serial.

I'm sort of confused only because I didn't realize it was possible to remove from the picture the Can box that connects to the Elcon, leaving direct serial? I suppose I'll try with the can boxes first.

josh


----------



## Coulomb (Apr 22, 2009)

bwjunkie said:


> I'm sort of confused only because I didn't realize it was possible to remove from the picture the Can box that connects to the Elcon, leaving direct serial? I suppose I'll try with the can boxes first.
> 
> josh


Yes, you'll be going serial (RS232) to CAN to serial (NOTE: NOT RS232!).

If you want to try the direct route, check out other parts of the MX-5 build thread, but if you assume it's RS232, you WILL blow an opto-coupler in the charger. I know from painful experience.


----------



## bwjunkie (Jul 31, 2013)

update on progress:

I didn't have the heart to dive back into java and linux so I proceeded in C#.Net with framework serial objects, which is going pretty well I guess. edit: although if I ever want this to be an embedded electronics app then my choice isn't looking too smart, haha.

From the computer USB to the Candapter product I have to send the bytes with a prefix of "x" and a message length code after the ID after the F4 (which in these examples is "8"), so the final result looks like these two examples:

x1806E5F48068100B4000000008D2B
x1806E5F4805D8009680000000246A

I believe the 8D2B and 246A are timestamps (these examples were not part of the same feed when recorded live).

05D8 is 1496 or 149.6 volts?
0681 is 166.5 volts...
and then I'm not sure about current 

I can't send these codes because my new pack configuration is lower by 12v, so before I can try with the battery pack hooked up, I need to create a good command!

-josh


----------



## Coulomb (Apr 22, 2009)

bwjunkie said:


> 05D8 is 1496 or 149.6 volts?


Yes, that's right.


> 0681 is 166.5 volts...


Yes.



> and then I'm not sure about current


It's just the same. So 009B hex = 155 decimal representing 15.5 A.



> ... before I can try with the battery pack hooked up, I need to create a good command!


It won't matter if it takes you half an hour to get it right; presumably the pack won't be in voltage trouble till well after that. And if it is, just take a short ride to blow off some charge.


----------



## bwjunkie (Jul 31, 2013)

Today I was able to get charging working with this vb.net code and the Candapter:
Here is some partial code in case anyone is interested PM me:

'we need an event handler for incomming data:
Friend WithEvents SerialPort1 As System.IO.Ports.SerialPort

Private Sub SerialPort1_DataReceived(ByVal sender As System.Object, _
ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) _
Handles SerialPort1.DataReceived

'then a routine to send on a loop
SerialPort1 = New System.IO.Ports.SerialPort
With SerialPort1

.ParityReplace = &H3B 
.PortName = "COM5"
.BaudRate = 9600
.Parity = IO.Ports.Parity.None
.DataBits = 8
.StopBits = IO.Ports.StopBits.One
.Handshake = IO.Ports.Handshake.None
.RtsEnable = True
.ReceivedBytesThreshold = 1 'threshold: one byte in buffer > event is fired
.NewLine = vbCr ' CR must be the last char in frame. This terminates the SerialPort.readLine
.ReadTimeout = 10000

End With

SerialPort1.Open()

SerialPort1.WriteLine("V") 'ask for version number from candapter
SerialPort1.WriteLine("S5") 'set 250k can speed
SerialPort1.WriteLine("A0") 'set timestamp feature to off which is already default
SerialPort1.WriteLine("O") 'open can port
For i = 0 To 600
SerialPort1.WriteLine("x1806E5F4805FA0096") 'x = transmit 1806E5F4 = target ID 8 = length of msg 05FA is max voltage 0096 is max current
Threading.Thread.Sleep(990) 'pause in loop , this loop will send roughly 1 msg per second for 10 minutes (not the best way to pause)
Next


----------



## bwjunkie (Jul 31, 2013)

I'm still unclear when the "turn charger on" command is required. 
-josh


----------



## Coulomb (Apr 22, 2009)

bwjunkie said:


> I'm still unclear when the "turn charger on" command is required.
> -josh


My understanding is that is is normally not needed.

[ Edit: What I meant by that is that normally a separate command just to turn on the charger would not be needed. But with every packet, you have to specify charger on or charger off. So usually, every message will have the "charger on" part, except for the very last, which will say "charger off". ]

The charger defaults to on (once all connection conditions are met), and you would normally send a charger *off* message at the end of charging.

However, if your charger was maintaining a battery over a long period of time, and/or there was a load, if the SOC (however judged) went low enough, the controller could re-start charging by sending a "turn charger on" message. Essentially, this would turn on the relay, though it may also do something to reset the "current stage" counter so the charge process starts again.

If you need more detail, I can dig into the code when I get a chance.


----------



## bwjunkie (Jul 31, 2013)

That sounds about like what I am experiencing, meaning, in some case "I think" the charger gets set to off and my code doesn't turn it on. 

I have only been sending 8 bytes (ID / voltage / current), leaving off the last 4 bytes 01000000 or 00000000. I will try to include those next time I have issues to see if it fixes whatever my issue is.

josh


----------



## bwjunkie (Jul 31, 2013)

Coulomb, I realize you determined the charger's direct serial is not RS-232 (13v), did you determine if it is something like TTL 3.3v?

thanks again for your help
josh


----------



## Coulomb (Apr 22, 2009)

http://forums.aeva.asn.au/forum_posts.asp?TID=4349&PID=54092&title=problem-tc-charger#54092


bwjunkie said:


> Coulomb, I realize you determined the charger's direct serial is not RS-232 (13v), did you determine if it is something like TTL 3.3v?


It's just a photodiode and a phototransistor with 12 V behind it.

It's in red in this partial schematic of the CAN charger box.










The polarity is "nornally dark", i.e. normally (idle) high on receive to the charger, and normally (idle) low on transmit from the charger.

You can also see the optos on the schematic page.

Edit: there is also the schematic to my serial port interface here.


----------



## Coulomb (Apr 22, 2009)

bwjunkie said:


> I have only been sending 8 bytes (ID / voltage / current), leaving off the last 4 bytes 01000000 or 00000000. I will try to include those next time I have issues to see if it fixes whatever my issue is.


The 8 bytes in the data part of the message do not include the ID. There are two bytes for voltage, 2 for current, one for charger on/off and the rest are unused. [ Edit: only one bit of the charger on/off bytes is used, so 7/8 of that byte is also unused. ]

Every CAN message has an ID, even if it has zero data bytes.


----------

