Paul and Sabrina's Cheap 3 Phase Inverter (AC Controller) with Field Oriented Control

[e*clipse]

Originally Posted by MPaulHolmes

Maybe I should add a line or 2 in the code so that, when the car stops going forward, the regen is disabled, so the car won't fly into reverse at a stop light?

That brings up something - perhaps you can help w/ my confusion..

- What's the line between "regen braking" and reverse torque - IE power taken from the battery pack to provide the reverse torque?

Somewhere in the stopping mode, the reverse torque provided by the drive motor based on BEMF will go to zero, I would assume. Does the controller attempt to apply consistant reverse torque based on some user input? In that case there would be a lot more energy flowing to the battery at high speed. If the torque is supposed to remain constant, there would be some point the battery would have to supply energy. At that point, it would not help from an energy perspective, but might help from a consistant performance perspective.

Brake "feel" is all important - how much deceleration the car is doing coupled with brake pedal pressure should be pretty consistant. It seems controlling a stop would be difficult if that is all over the place. This is one of the toughest things to figure out - how to blend friction brakes with regen brakes for consistant feel and best energy return.

- E*clipse

[e*clipse]

With all the work you guys are doing with the data, I started thinking a bit about how to do this with the CAN bus.

It's really nice that you can stream data using standard serial data; that could be very useful in the future; not only for debugging.

Actually, the CAN bus really isn't a big deal; is mostly a communication protocol. There a quite a few requirements for meeting the protocol - actually more than the hardware requirements...

I think it would be nice to use the CAN/OBDII protocol for the communication - that way external devices could be used for monitoring, etc.

The main part of the protocol is pretty easy - there are two versions. The "standard" frame uses an 11 bit identifier and the "extended" frame uses a 29 bit identifier. Both frames can transmit up to 8 bytes of data.

All the other stuff, including bits that communicate message priority, a CRC check, etc are the same. The bus speed is somewhat adjustable, with the main tradeoff being noise immunity and processor time for high bus speeds.

The main problem is that outside the government regulated indentifiers, there is very little information about the identifier. Since the protocol was originally design for pollution control, there is nothing I can find about EV stuff.

For example, EVTV has those nice Andromeda interfaces that display a lot of useful EV stuff, all transmitted by CAN. However I can't find anything about which indentifiers they use.

It sure would be nice to come up with a set of identifiers that would be useful for EV's and readable by any CAN bus / OBDII scanner.

Thoughts?

- E*clipse

[e*clipse]

Well, ok then. I'll just keep jammering on...

After looking around a bit more, it seems that, um, Wikipedia is the best resource.
Not to say it's not the best resource; it's actually very good. It's more a statement of my searching...

So, wikipedia on OBDII PID's. (Parameter Identifiers)
https://en.wikipedia.org/wiki/OBD-II_PIDs

BTW, there's a more extensive list here that shows everything, including body control codes:
Complete List of OBD Codes: Generic OBD2 (OBDII) & Manufacturer | Car OBD Diagnostics, ECU Chip Tuning & Auto Repair Support

Notice that there are a LOT of parameters an EV will never use. For example, the long list of O2 sensor voltages: All these "addresses" are in hex.
O2 sensors: PID 14 > PID 1B
O2 lamda: PID 24 > PID 2B

Then there are the ones that could be useful for an EV:
Vehicle speed: PID 0D
engine rpm: PID 0C
7 throttle inputs: PID 45 > PID 4C


I haven't evens scratched the surface, but as you can see, an EV could make use of lots of OBDII protocol without requiring "EV" specific parameters.

This could be useful for ALL EV's, if we could just get together and agree on something. Of course folks who have probably already done something like this (Example, Orion BMS or the Curtis controllers) would want everyone to to what they did. At the same time, they don't want to tell anyone what they did.

Or, we could just make our own set - The OPEN REVOLT PID PIRATE list!! ARRRG!

- E*clipse

[e*clipse]

A while back, P-hack suggested that I just get a GM Volt pack to meet my weight goals.

He was right.

It's really a good idea for a few reasons:
1) without the huge metal t-shaped plate, the cells are significantly lighter than the equivalent Leaf cells.
2) It has liquid cooling built in - it's an extremely good system that actually flows coolant past every cell's large surface. This will be very important in my hot climate.
3) They are Silly Cheap at junkyards. A 16kWh pack for under $2k.

The cells are each 15Ah, and grouped in threes for 45Ah. It's difficult to separate the groups of three. Oh, and a complete pack comes with contactors, a safety disconnect, and current sensors.

The only downsides: 1) I have a leaf pack. 2) ego. In this case, the good definitely outweighs the bad.

Thank you, P-hack.

- E*clipse

[freebeard]

Thoughts? [badump...badump}Well, ok then. I'll just keep jammering on...

Is that Volt pack the one that has cells clamped together with a cooling rail down each side? The video I saw had two different size modules that one could mix and match.

I've seen quite a bit on EVTV about CAN. How CAN high and CAN low both go to 2.5v so the system can discriminate dominant and recessive message packets. But even though the Tesla drivetrain is all CAN controlled, except the throttle and brake, apparently there are differing firmware revisions.

What's the line between "regen braking" and reverse torque

'Hill holder'. I support spreading the OPEN REVOLT name.

[MPaulHolmes]

Once it is initialized CAN is very easy to use. You can set up each node to ignore or accept whatever types of messages you want. Then, everybody just willy nilly blasts whatever the crap they want with no regard to concern about collisions. And they just accept whatever messages are for them. I have used it between a charger and several bms boards. Each board sent a packet of 8 bytes long, which were the 8 voltages of that bms module's 8 batteries. There were 6 modules just blasting their 8 bytes randomly and each ignored each others 8 bytes. The charger would pick up all the packets. No problems with noise and no missed packets (i dont think). And the data was never corrupted. You just use a little 8 pin $1 part along with the dspic CAN module.

I don't think it would take very long for it to be all proper with the standard packets. I just havent done that because i was trying to make interface with the user as cheap as possible. And I've never done any obd2 or whatever it is called. I just pictured people in a car repair shop with a greasy handheld device that read cryptic codes.

[freebeard]

It's a weird network. No collision detection. No resent packets. I suspect there's a lot of redundant chatter.

EVTV has Arduino boards to read and inject CAN messages, with USB ports—no OBDII required.

[e*clipse]

Originally Posted by MPaulHolmes

Once it is initialized CAN is very easy to use. You can set up each node to ignore or accept whatever types of messages you want. Then, everybody just willy nilly blasts whatever the crap they want with no regard to concern about collisions. And they just accept whatever messages are for them. I have used it between a charger and several bms boards. Each board sent a packet of 8 bytes long, which were the 8 voltages of that bms module's 8 batteries. There were 6 modules just blasting their 8 bytes randomly and each ignored each others 8 bytes. The charger would pick up all the packets. No problems with noise and no missed packets (i dont think). And the data was never corrupted. You just use a little 8 pin $1 part along with the dspic CAN module.

I don't think it would take very long for it to be all proper with the standard packets. I just havent done that because i was trying to make interface with the user as cheap as possible. And I've never done any obd2 or whatever it is called. I just pictured people in a car repair shop with a greasy handheld device that read cryptic codes.

LOL - Actually the OBDII stuff does make wrenching quite a bit easier. I've got 2 code readers, one simply reads whatever you're interested in and displays that on a LCD. It does display the cryptic codes, but more importantly it also displays dynamic data. I use it on my Honda Insight to monitor stuff the dash doesn't display. The other one is a full code reader. It really made putting a new engine into my dad's Yota 4-runner possible. These new IC engines have sooooo many sensors that EV's with resolvers look positively simple by comparison. With the scanner I made sure all the systems were working properly; I can't imagine trying to guess at this stuff.

The reason I'm talking about OBDII at all is because the protocol works nicely for vehicles. Yes, the CAN bus doesn't need OBDII. But there are some nicely worked out message protocols that could be leveraged for our purposes.

It is a weird network, and it's ability to deal with random messages has a lot to do with it's robustness. Also, the differential signaling helps with noise. I think noise will be a major concern, especially with DIY EV's. No one in the DIY world cares about EMI until wierd "random" stuff starts happening.

That said, I really don't trust serial communications for critical inputs like throttle, etc. I'm trying to keep my use of it down to data acquisition and monitoring. Period.

- E*clipse

[hamsterpower]

When considering the use of the CAN protocol, be aware of security too. CAN is what those hackers used to take control of numerous cars. You are talking about critical propulsion control systems here. Yes currently small scale-low value targets but still. Security MUST start at the beginning or it will never be added at the end. Sure the worst of the hacking was because a certain manufacturer had the cellular enabled mobile entertainment system and the ECU and everything else cobbled together.

[Piotrsko]

What do you need to know about volt packs? Just ask.

And the cells do seperate with a hair dryer and gentle persuasion.

Fwiw Can is secure if it isnt connected to outside anywhere. It is the internet enabled interfaces that get hacked. Can is just a compliant accomplice that doesn't know how to say no to requests.