Paul & Sabrina's cheap DIY 144v motor controller

[MPaulHolmes]

Originally Posted by Greg Fordyce

#define THROTTLE_FAULT (1 << 0)
#define VREF_FAULT (1 << 1)
#define PRECHARGE_WAIT (1 << 5)
#define MOTOR_OS_FAULT (1 << 6)
#define HPL_FAULT (1 << 7)

So what is the values for the above faults, and can the controller set multiple faults at the same time?

1 << 5 (for example) means 2^5, which is 32. 1 << x means 2^x. So, you can set each of those bits individually. If everything is working,
fault_bits = 00000000 (in binary)

If fault_bits = 11100011, then that's just horrible! haha. That means that there is a high pedal lockout fault set, and a motor overspeed fault, and a precharge wait fault, and the current sensor is out of range, and the throttle is out of range.

fault_bits = 00100000 would mean a precharge wait fault.

[squiggles]

Originally Posted by Greg Fordyce

First, what is the formula to convert the temperature data to Celsius and Fahrenheit.

Celsius / 5 * 9 + 32 = Fahrenheit

Does anyone still use Fahrenheit?

Edit: Just realised you mean convert some published data value to a real value...

[DJBecker]

The Cougar board uses a NTC thermistor. It's inexpensive and easy to design around, but it's not linear. Combined with the loose tolerance of the surrounding resistors, you won't be able to do a direct conversion. Instead you'll need to create a curve fit polynomial to match your specific parts (as above) or a calibration table that you interpolate from.

Here are the notes I took when selecting the temperature sensors for our controller. We had a slightly different set of design goals.
- Most of the sensors were for reporting, rather than thermal limits, thus a calibrated result was important
- We wanted more sensors, and individual calibration would be a bit of a PITA
- We wanted automotive CAN bus reporting, thus needed degrees Celsius reporting.

---------------------


Temperature sensors

The LM335 is inexpensive and has an output voltage in "degrees Kelvin",
2.73V at 0C, 2.98V at 25C. We need a 2K ohm bias resistor for 5V operation
to get the approximately 1mA of operating current

A LM35 is a bit more expensive, but requires no bias resistor, uses
less current, and has a source lower impedance for a better A/D conversion.
(The A/D converter has trivial leakage current, but the sample
capacitor requires a low impedance source to charge correctly during the
short sample period.) The down-side is that it outputs 0V at 0C, and less
at lower temperatures.

The least expensive option is a themisor, where the output is non-linear
and depends on the bias reistor. The Cougar uses a B57862S103F40 thermistor
with a two resistor bias tree, and a 0.1uF cap.

An alternative is using digital sensors e.g. one wire. They aren't much
more expensive, and save on A/D channels, but may take a little more
processing time.

TI TMP75AIDGKT Digital temp sensor 2 wire 8 MSOP Digikey $1.54
Dallas DS18B20 One-wire, possible single pair operation, 750msec
$2 in medium quantity, $6 in a probe format

----------------------

And the comments from the CAN reporting code

case 0x05: /* Coolant temp A-40 -40C..+215C, use heatsink temp. */
/* Assume a LM335 where Kelvin = 100 * 5V * (count / 1024)
* Our baseline temp is -40C or 233.15 Kelvin, or 2.33V
* which is an A/D reading of about 477
* DataA = ((500 * rt_data.raw_hs_temp)/ 1024) - 233 */
can_cmd.dataA = (125 * (rt_data.raw_hs_temp - 477)) >> 8;
good = 3;
break;

[Greg Fordyce]

Thanks for all the info. DJBecker's write-up on the various temp sensors and what he is using is good, but one of my design goals is to keep the Cougar 2C "stock" and work with what I've got.

Squiggles mentioned

Does anyone still use Fahrenheit?

So for now I will just concentrate on Celsius and can add the Fahrenheit conversion later if it is desired.

Looking at Joe's graph, one idea that struck me is to come up with say half a dozen linear equations for the temperature conversion and have the display choose which one to use based on its value, for example for a raw value between 150 and 300 would be one equation, 301 to 500 another equation, etc. I will have to play with the equation in openoffice and see what I get. I am still open to any lookup tables that may be stashed away in some dusty corner of a hard drive, if any one has one.

Greg

P.S. Thanks Paul for explaining the fault bits, I knew it was something like that, just got a bit stuck.

[MPaulHolmes]

I had made a lookup table. Now it's just about finding the dang thing. A piecewise linear approach would be good too.

[DJBecker]

Originally Posted by Greg Fordyce

Looking at Joe's graph, one idea that struck me is to come up with say half a dozen linear equations for the temperature conversion

That's the table approach. Just pick a few point to measure the temperature response, build a table, and interpolate between the values. You can do a higher-order interpolation, but just a linear one with two points will work fine. An advantage of linear interpolation is that the math and overflow/rounding analysis is simple. You won't get math errors that lead to non-monotonic results.

Again, the challenge with a thermistor is that you'll to calibrate your particular installation. That's not a big deal when you have a single system with a single sensor.

Here is an untested function to do the interpolation. It should be good with 16 bit math as long as you have enough calibration points.

/* Temperature normalizaiton calibration using a linear interpolation table.
* The table is build using calibration numbers taken at a few temperatures,
* including an estimate for the extreme lower and upper raw values.
*/
struct {int raw, C; } temp_table[] = {
{0, -50}, /* Fake a lower bound: raw_adc of 0 is -50C */
{400, 0}, /* Measured value of ice at 0C */
{500, 20}, /* Comfy room at 20C */
{700, 100}, /* Measured value of boiling water at 100C */
{1024, 200}, /* Estimate upper bound: raw_adc of 1024 200C */
};
int raw_to_calibrated(int adc_raw)
{
int i;
int celsius;

/* Scan the table, knowing that we can't fall off the end. */
for (i = 1; adc_raw < temp_table[i].raw; i++)
;
/* i is now the index for the higher value. Interpolate. */
celsius = (adc_raw - temp_table[i-1].raw)*temp_table[i].C +
(temp_table[i-1].raw - adc_raw)*temp_table[i-1].C;
celsius /= temp_table[i].raw - temp_table[i-1].raw;
return celsius;
}

[jyanof]

Originally Posted by Greg Fordyce

Looking at Joe's graph, one idea that struck me is to come up with say half a dozen linear equations for the temperature conversion and have the display choose which one to use based on its value, for example for a raw value between 150 and 300 would be one equation, 301 to 500 another equation, etc. I will have to play with the equation in openoffice and see what I get.

i'm confused - why not just use the 3rd order curve fit equation? It'll take some time for the processor to crunch through it, but it's not like you need to display the temp at a high refresh rate...

[harlequin2]

Originally Posted by Georgia Tech

Hey guys!
Can some one give me a quick run down on where we are with the 1000 amp controller?

Yeah, I'd like to know about that too.
I have a LogiSystems controller (1000A, 250V) that I blew up, repaired, rebuilt and finally decided to not use because of the jerky starts, so I built a Cougar one instead. Works well, but not anywhere near the same performance so I am thinking of building a new Cougar control board to drive the LogiSystems power section. But I'd have to do a new layout to make it fit inside the case.
The LogiSystems thing has lots of IGBTs and plenty of headroom for 1000A, so that would make a pretty good controller I think.
I'd like to see what anyone has done towards a 1000A version of the Cougar though, just to compare.

[harlequin2]

Originally Posted by Greg Fordyce

Back to the topic of a touch screen graphic display. I have been looking at the products from 4D Systems, an Australian company, and today ordered one of these µLCD-32PT(GFX) - 4DGL Display Modules. I have mentioned this product before, so while I am waiting for it to arrive I thought I would start writing some code for it. They have an IDE, free to download, and the language is kind C like but optimized for doing tasks such as displaying graphics and parsing serial data strings, perfect for what is required for this project. The first goal is to read the real time data stream from the controller and display the information on the screen. I have a couple of questions about the data stream.

I've ordered one of these things too. Now thinking about just what/how to use it.
Presently using a NetBook running RTD Explorer.
I'd like to hear your ideas on what you are doing with the display and see if I can help out with the overall project.

[Greg Fordyce]

Originally Posted by jyanof

i'm confused - why not just use the 3rd order curve fit equation? It'll take some time for the processor to crunch through it, but it's not like you need to display the temp at a high refresh rate...

Really it's just down to processor time vs. accuracy. Unlike a desktop pc, most micro-controllers are limited in their math functions, this one is signed 16 bit integer maths. The look-up table approach will sacrifice some accuracy for speed and also ease of coding. I did have a play with the equation y = 0.0000007 * x^3 - 0.00081698 * x^2 + 0.40709038 * x - 41.63772692 in openoffice and got a graph that looked just like yours! so I can use that to create a look-up table for temperature conversion. One question, what is the equation R^2 = 0.99705769 for?