Quote:
Originally Posted by MPaulHolmes
Yes I'm definitely interested in figuring out the CAN codes.
|
Excellent - step one complete!
Quote:
|
I'm sure I'll need help, but I could use the AC board to capture some can data, and then stream it over serial.
|
Everyone needs help. Some of us just don't know that ... or accept that .. sometimes
As far as I understand, EVTV had to use the GEVCU to timestamp and buffer the data, since it IS order dependant and the Tesla uses much of the bandwidth available. A 115K serial link may keep up to the 250K or 500K CANbus if it is not saturated with data. 250K and 500K are common for CANbus. 125K does not seem to be used. I have heard of a higher rate - 1 MB or 2MB? I have not seen anything that uses the higher data rate, either.
Quote:
|
I've got CAN working, and have tested it on a BMS I did a couple years ago based on Fran Sabolich's suggestions. I used it to send 48 battery voltages over CAN to a charger, and it worked great. The nice thing about it was, you could just blast your messages willy nilly, not caring what other CAN nodes were doing, and the people (charger) who were supposed to get the message just got the message, and the people (other battery groups) who were supposed to ignore it, ignored it!
|
I'm sure that I would have remembered if I had seen this posted elsewhere. Was it posted anywhere on ECOMODDER? Good job, in any case.
Blasting out the info and letting any node that is interested in the data use it for whatever they like ... that's one of the big plus's on CANbus. The big negative is that in order to consume the data, you need a map - what does each bit or byte mean, and what is the scaling? This is fine if you did both sides (data source and data consumer), or you have the documentation. Not so great if you are reverse engineering .. say the Leaf .. and don't even have a starting point
Quote:
|
So, if I added a CAN node to the group, I could just have a mask that says I should receive everything, and I just sit back and listen?
|
That's how I understand it. Mask matches all, let me know when ANYTHING comes in. I'm not sure if timing is a big deal on the LEAF bus ... but I expect that it may be. If just playing back the captured data as fast as you can (with the ECU disconnected from the bus) does not power up the car and do stuff, it may need to be timestamped before being stored (relative to start of capture should be OK) so that you can play it back with the correct delays between the messages
The other concern is missing a message that was important. If it does not fit through the 115K (or whatever you are using) serial link it may be dropped but you may not know that.
Quote:
|
And I should leave the spot on the board for the 120Ohm resistor unpopulated, because those 120Ohm resistors are probably somewhere else in the car already (between CANH and CANL)?
|
Perhaps a 2 pin connector? For bench testing you can add the resistor but in the car I wold not expect the controller to be one end of the bus?
The CANbus is used by Rockwell (with 2 more network layers added, they call it Devicenet) so I have some experience with that. If you are under 10 feet, termination resistors are sort of optional. You can make it work on your bench with cat5 network cable, no terminators, and the ugliest splices you'd ever want to see.
In the environment of an Motor Control Center (MCC) room, with AC and DC controllers running nearby, UPS systems on the same AC supply, etc you need the correct cabling, terminators at the ends and only 1 at each end, the drop cables and taps need to be properly sealed to keep out moisture and other gunk.
In my experience, the Devicenet controller works better in the center of the bus. It still works on one end of the bus, but unscheduled throughput is lower. Like saving the configuration of a VFD. That is no likely a factor in a car .. but who knows?
Another post that is too darned long .. sigh! ..