LDU temp reading problem (not logic)

[guillemonde]

For reference, I have my limits set to:
"tmphsmax": 85,
"tmpmmax": 300,

I had the same params, but I think the tmpm can't go (return) upper than 155 so tmpmmax:300 will never be reached this is a problem for everybody, my too high temp it's my configuration problem, maybe not enough fan, maybe wrong way, certainly too heavy vehicle, thanks to help me, but it's a secondary problem.

For the science, next week I'll try running coolant from the motor side (because it worked better in this side) and without rotor liquid coolant, I'll use air compressed to cool it, I want to know what is the thermal effect of coolant delete, I'll add a sensor inside the pipe to monitor the rotor temp with and without air cooling.
For the stator temp, for now, I'll add 70° when the temp fall of 70° and I'll remove 70° when it rise of 70°. And I'll never go upper than 165°. And I'll never start when stator temp is upper than 70° (because I'm not sure where I'm on the curve)
This time I'll take a second stator on board so I could fix a problem quickly (hope to not need).

[guillemonde]

So I changed the stator, and the value is the same so I made a script on my dashboard to have the right temp displayed

One unusual thing I noticed in the parameters is the high minimum slip (fslipmin). The default is 0.9 Hz or so, try dialing it back and check for changes.

I changed the value to 1Hz and it seem to be better, but I still have the temps curve not logical.
The problem is that with this value the regen is really too low. With the old gear set I changed dynamically the fslipmin to something low when I drive and to something high during regen. Maybe their is another params to set the regen correctly and keep fslipmin low ?

thanks four your help

[johu]

Maybe their is another params to set the regen correctly and keep fslipmin low ?

Yes, they are called "offthrotregen" (for when you come off throttle) and brakeregen (when you touch the brake). You have them set to -20% and -40%. But they go to -100%

[guillemonde]

You have them set to -20% and -40%. But they go to -100%

Yes I change this value with the retarder command, I've 6 level from 0% / 20% to 100% / 100%
In fact when my potnom is at -100% my regen is low if I set a low fslipmin 20kW for a fslipmin at 0.9Hz, but with a fslipmin at 2 I can go to more than 100kW.
I imagine it should be like acceleration from min at 0% potnom to max at 100% potnom, but with fslipmax for 100% and for -100%. Something like use an absolute value of potnom.
Now it's like -100% is less than 0% so fslip is fslipmin.
To run around this, when I have a negative power (with some level), I set fslipmin higher and when I have positive value I set it back to lower.
With the new gearset it work good also for starting with high fslipmin, but maybe it's a problem for the stator. I said maybe, because today I gone to climb a little bit and I feel it was same than with high fslipmin.
So maybe I'll use the retarder command to change the fslipmin and let the offthrotregen and brakeregen to 100%
For now my priority is the fix the heating problem, but I don't know really what is the maximum temps for the stator neither the rotor, so I'm trying to have the lower temps possible.

[johu]

Finally got around to testing the motor temp sensor inputs. I either fixed one input at a fixed low temperature voltage or sweeped them both simultaneously. The result is as expected though:

The °C/mV ratio becomes pretty high at high temperatures, I wonder if that might cause issues. But apart from that the lookup table works and temperature saturates at 190°C

Understood with the regen. Sounds like the default 0.9 Hz is indeed too low. Not sure where it comes from.

EDIT: bug!
This line

Code: Select all

isLdu = tmpmi > 50

is the culprit. If the second motor temperature drop below 140°C it changes over to SDU code

So you were right:

I didn't read all the code but on the VehicleControl::GetTemps the isLdu is set to false on declaration and is checked inside the case 1 and 2 without possibility to be true.
I didn't know how work the input switch mux, but seems not necessary to check if we know the value.

So now is the question how to bugfix. Easiest would be to only conduct this test once after startup. But then if you start into a hot motor you might be stuck with the wrong lookup table.
Another option would be to add a selection to snsm and remove the auto detection

[johu]

Try this: https://github.com/jsphuebner/stm32-sin ... 3637730724

Lowered threshold to 20 digits

[guillemonde]

Thank you so much,
I'll try it on Tuesday

If the second motor temperature drop below 140°C it changes over to SDU code

Yes, but the phenomenon occurs when the temperature drops, but also when it rises.

On my last trip the temperature rise up to 205 degree (supposed by adding 70 degree) without rotor coolant, just some air compressed, and when I checked the rotor it was like a new one, without color change, so I'm not sure about the adding of 70 degree.

I don't know when, but I'll try to put the stator into a oven and check the temps returned by the OpenInverter Board.
So we'll have the real 190 degree temperature rising and falling curve.

[uhi22]

To split the search range I propose to make a test software which provides the ADC value AnaIn::tmpm.Get() to a spot value, and log this value.
If it does not have the step, the issue is in the software behind. If it has the step, the issue is electrical.
Some ideas:
- ground shift of the sensor ground due to a high current on/off load.
- analog crosstalk from an digital signal to the sensor signal
- multiplexer timing

A second point for measuring would be a multimeter on the sensor wires. This would distinguish a real voltage jump from a processing issue.

[johu]

Nono, 99% sure it's a software issue and 95% sure the above version fixes it. Let's wait for the results

[uhi22]

Maybe I got the point. Correct me if I'm wrong.
There are two temperature sensors. The value of one is shown in the diagrams above, and is calculated by a lookup table. Depending on LDU/SDU, different lookup tables are used, because of different sensor characteristics. The second sensor is compared with 50, to decide whether we are on LDU or SDU. This decision is made cyclically, thats why we see multiple jumps during one driving cycle, in both directions.
The two sensors have similar but not exactly the same temperatures, that's why the "jump points" are varying by some degrees.
The fix with the new threshold makes sense. If the threshold is chosen in a way that a real sensor never will hit this new limit.

Still open is from my understanding, why the measured value is in general different to the expected value. Is there a data sheet available? Or did somebody measure the characteristics?

[johu]

After all these years I'm not sure where I got the lookup table from. It is here: https://github.com/jsphuebner/stm32-sin ... aster/misc

Like said, in the upper temp range I expect a lof of inaccuracy because voltage only changes very little with temperature

The software always picks the larger of the 2 temperatures and displays it.

[PoloLbricolo]

Hello,
I did the oven test, here is the setup, an old Stator from a LDU sport, extended wires for the temps sensors and a thermo couple hoked up to my multi meter to have the actual temperature and an other multi meter to measure the resistance of the two stator thermistors.
The thermo couple was wedged in a crack of the resin of the stator.
a few pics attached
And the most important, the Look up table, where i have the thermo couple temp, the oven temp (inacurate), and the resistances.

I will be able to test new software version to confirm that it works well.

[johu]

Thanks, quite different to the old table. Almost looks like the old one was generated from a polynomial, because it's so smooth
I fudged the new one to look sort of smooth in the lower temps

Edit: more fudging with logarithmic scale

[guillemonde]

Try this: https://github.com/jsphuebner/stm32-sin ... 3637730724

I tried it today, I've seen 160 degrees, so it seem to work, thank you so much.

And the most important, the Look up table, where i have the thermo couple temp, the oven temp (inacurate), and the resistances.

Thanks for you help, it seem to explain the difference on starting the trip.
This morning the tmpm was -2 degree but the ambient was 8 degrees

[PoloLbricolo]

I can test a new software version, to confirm that all is correct.

[johu]

https://github.com/jsphuebner/stm32-sin ... 3931863114