LCD Instrumentation for Cougar Controller

[jackbauer]

Just to let everyone know my resistive fuel gauge is working fine. The hum is not noticable once the vehicle gets moving. I just turn up the stereo The bmw gauge dooes move but................very.....................slowly .............must be the software filtering that djbecker mentioned. Once i install the new controller i'll fit the lem and try out the charging mode.

[ianbartie]

A curious thing happened yesterday. I had the controller apart to replace a popped mosfet. I also found an open circuit gate resistor which I replaced. The mosfet popped about a week ago & the controller was still working as was the display.
Replaced the two components, put the controller back together, turned the car on, no pops or smoke (good thing).
Car drives fine but the display isn't working. I traced the problem to the controller serial output voltages.
TB2 to TB3 measures about 5.45V instead of about -9V & TB2 to TB measures the same instead of 0V.
The bit that has me stumped is both RTD Explorere & Hyperterminal work fine. I can see the data & I can change settings.
Any suggestions?

[Freyguy]

Originally Posted by jackbauer

Just to let everyone know my resistive fuel gauge is working fine. The hum is not noticable once the vehicle gets moving. I just turn up the stereo The bmw gauge dooes move but................very.....................slowly .............must be the software filtering that djbecker mentioned. Once i install the new controller i'll fit the lem and try out the charging mode.

Hi Jackbauer, thanks for the update!
I guess a cap on the sender wire to ground didn't help?
488hz and the default 1.95Khz are both in the audible. You could try 7.8kHz
by changing value loaded in T2CON from 0x06 to 0x04. The coil's inductive reactance might create an issue at this higher frequency, but never know until you try. Be nice to drive with the stereo off once in a while

[Freyguy]

Originally Posted by ianbartie

TB2 to TB3 measures about 5.45V instead of about -9V & TB2 to TB measures the same instead of 0V.
The bit that has me stumped is both RTD Explorere & Hyperterminal work fine. I can see the data & I can change settings.
Any suggestions?

Ian,
Did you mean -5.54V? Default "mark state" level should lower than -3 although 0 has been know to work. But if it was positive then that makes it look like a "space state". Might want to disconnect the 3 wires and measure the controller TXD and LCD TXD seperately. Also do not measure with DMM if controller is transmitting as the TXD line (receive for LCD) will not measure correctly.
Levels aside, I feel the mosfet event probably compromised the RS232 transceiver on the controller. Output levels may have fallen gradually over time and finally reached the "threshold" where the RS232 chip on the LCD no longer recognized it as valid. RTD and hyperterminal both use the R232 tranceiver on the laptop which may have a lower "threshold" allowing it to continue working (for now). I have a 120 ohm resistor in the comm ground path on the LCD (R6). Just provides a little protection in the event of ground loop between LCD and controller. It is probably dropping a bit of voltage too which would account for the higher threshold required for the RS232 chip.
As a test you could short across it and see if the serial comm works. But if the RS232 chip on controller is dying a slow death, this will only postpone the inevitable.

[mora]

What did I mess up when changing battery capacity to 90Ah and pmile to 13? I get 49 KTE when at 100% SOC, but it lowers faster than odometer is showing. Today I drove a bit over 30km and KTE read 0. Battery amps look correct on the screen and pack voltage is less than 0.1V off. User manual says more aggressive driving lowers MTE/KTE faster than actual miles travelled, but can it be this far off?

Fuel gauge also shows full after certain point (can't remember if it was under 20% SOC or after 0 KTE). It starts lowering from there but looks like its status gets reset somehow.

[Freyguy]

Originally Posted by mora

What did I mess up when changing battery capacity to 90Ah and pmile to 13? I get 49 KTE when at 100% SOC, but it lowers faster than odometer is showing. Today I drove a bit over 30km and KTE read 0. Battery amps look correct on the screen and pack voltage is less than 0.1V off. User manual says more aggressive driving lowers MTE/KTE faster than actual miles travelled, but can it be this far off?

Fuel gauge also shows full after certain point (can't remember if it was under 20% SOC or after 0 KTE). It starts lowering from there but looks like its status gets reset somehow.

Mora,
Accuracy of KTE/MTE is dependent on accuracy of the SOC meter. You can enter in your capacity and Peukert exponent as a starting point, but you’ll need to monitor the calculated SOC value compared to actual measured capacity and make adjustments.
I don’t know if you’re using lithium or lead acid, but get the peukert right first.
For my lead acids, I used a peukert of 1.30 based on battery datasheet 100A rate. But SOC was dropping too fast relative to measurements made on the batteries 15 minutes after a long drive (I measured using both “no load” voltage and hydrometer readings).
Readjusting to 1.25 was better, but 1.20 put me spot on.
Once the SOC meter appears right, then charge to 100%, go for a drive to drop it to 60% and note the kilometers driven on odometer. Doubling this gives the kilometers you can drive down to 20% capacity or basically your usable range. This is the value you should set the pmile to generate. Pmile represents % capacity used per mile and is a fixed value.
Driving aggressively will use a higher % capacity per mile and would create an error.
The only way to make this more accurate is to have a speed sensor interfaced to the LCD board. It could then determine % capacity used per mile and change it dynamically to reflect driving habits.

As for SOC resetting down ~ 20%, I haven’t seen it. Granted I haven’t run my batteries that low, but on bench simulations months ago I would run SOC down to 0 repeatedly without issue. I did see the SOC change from power down to power up, but I posted the fix for that. It will be implemented in version 1.4.

[ianbartie]

The 120 ohm resistor on the display checked out fine. Will check out the controller serial port tomorrow.
Wierd thing was that the display was showing the controller temp OK but neither the bat amps or the motor amps were showing anything except 0.
Not a big deal to replace the RS232 transceiver in the controller. Might even stick in a DIP socket instead.

[Freyguy]

Originally Posted by ianbartie

Wierd thing was that the display was showing the controller temp OK but neither the bat amps or the motor amps were showing anything except 0.

Ahh, not so weird. This means the serial message gets through when the motor is not pulling amps. When you are pulling amps, the message gets corrupted and the LCD code discards the bad message and never updates.
How do I know this? It happened to me!
My controller sits on a platform made from 12mm thk plastic cutting board. The case was therefore not grounded. Serial message was fine when I wasn't pulling amps, but when I pushed on the throttle even the slightest, it turned to garbage data. I grounded the case and everything was fine. Your situation might be different, but it does point to serial stream getting corrupted somehow when motor pulls amps. Something connected differently since you had the controller apart and back together? I'd somehow rig laptop w/hyperterminal to interface to same cable that was going to TB2. That way it follows same path (induced noise and all). See what the hyperterminal data looks like when throttle is pressed.

[mora]

I'm already using peukert value of 1.10. I have lithium pack and thought it would be close. I'll try 1.05 and see if I get closer. I know I can go 39 miles and DOD is somewhere between 95 and 100%. So after 19 miles I should see 50% SOC reading. Fuel gauge should be halfway when SOC is at 60%, right? (because fuel gauge shows empty at 20% SOC).

[Freyguy]

Yes, that's correct.

With the compiling/programming problems you were having eariler, I wonder if it is compiling with the right peukert tables?
There is an if/else statement specifying which group of peukert multipliers to use. You may want to simply delete the if/else statement and the first group of peukert multipliers (1.30~1.20). This will force it to use the right tables.