Traction Control problems

[Speedy_G]

The Traction-Control function is not very well thought out.

I solved the first most obvious problems:

1) The Slip Threshold is not transfered to TS, i solved this by using outpc.status4
2) Not even the actual slip is transmitted to TS, i solved this by using outpc.istatus5

But there are still problems.
Only the TC Spark retard is available for datalogging. So

3) TC Spark Cut is missing
4) TC Add Fuel is missing.


Since i already used the only free available outpc values i can't send the other two missing.

So after all, how should it be possible to find a good TC setting, when you even can't see what is acutally happening when you're drving??
That makes this function totally useless. By using the two free outpc values its better, but with those other two missing, its still far away from good.

[Reverant]

+1.

[arran]

I'll add that if using a switch to enable or disable TC, it needs to be a toggle switch, whereas other MS functions (Data logging) need a momentary. Switch requirements should be the same
Also, if a light output is enabled, it only illuminates when TC is actually in effect (a slip has been detected), most OEMs have a light to advise that the function is armed, and it flashes when it is in effect

[Speedy_G]

I'm not sure i found another problem.

I tried to transfer the Slip and the Slip Threshold values with two Decimal places.
This was no problem for the Slip value.

But the Slip threshold seems not to have any decimal places when its interpolated from that slipx,slipy table. (For this i used istatus5 for the threshold)
So i multiplied it with 100 and for example when the slip threshold was between 12 and 13, it just transfered 1200.
I made a few tests and it seems like there are no decimal places for that value.
but this could be a problem.
For example when the Slip-Threshold according to the table should be 11.9, then Megasquirt is calculating with a threshold of 11.0.
The result is, that the Megasquirt retards, cut ignition and so on, when the slip is still okay.

Then i noticed the following in the ms3_misc and in the MainController.ini/Core.ini.
It seems like the datatypes for tcslipx and slipy are interchanged.
In the maincontroller tcslipx=U16 but in the firmware its INT.
And tcslipy=U08 but in the firmware its Unsigned Char.
So i think normally it should just be the other way around?
Or maybe to allow decimal places both U16 ????

[jsmcortina]

All of the maths we do in MS2 and MS3 is integer maths, there are no decimal places. While we've not actually tried it, using the floating point libraries would certainly chew up CPU cycles that we cannot afford to waste.

That cast to int* is required and unrelated to your question.

James

[Speedy_G]

okay. Then do i understand you right that the intrp_1dctable function does not output decimal places in first time?
Would it be possible to use another table interpolate function? I took a short look into the firmware, and for example the Oil Pressure Setting allows 1 decimal place and uses intrp_1ditable function. And there are some others.

As far as i understand it, i would say the slip_threshold is the obstacle.
Because the Slip calculation itself outputs decimal places.
So i think there it would be possible to multiply it with *100 and take this value for the calculation.
When this would be possible for the Slip_Threshold too, you could do this to both values:
Then for example when you set 11.9 slip threshold and your slip is 12.45, Megasquirt would compare 1245 > 1190.
After this it starts the slipxtime timer like always. if (lt > slipth) { .....}

[jsmcortina]

So i think there it would be possible to multiply it with *100 and take this value for the calculation.
When this would be possible for the Slip_Threshold too, you could do this to both values:
Then for example when you set 11.9 slip threshold and your slip is 12.45, Megasquirt would compare 1245 > 1190.

Yes, that's the way decimal values are handled in integer maths.

James

[Speedy_G]

So i think there it would be possible to multiply it with *100 and take this value for the calculation.
When this would be possible for the Slip_Threshold too, you could do this to both values:
Then for example when you set 11.9 slip threshold and your slip is 12.45, Megasquirt would compare 1245 > 1190.

Yes, that's the way decimal values are handled in integer maths.

James

jep, but how do i get the slip threshold with decimal places in first time?
Like written multipling the input for slip_th (so the stuff on the right side of the equation) with 100 doesnt help.

So back to my question from my last post: Is it somehow possible with intrp_1ditable instead of intrp_1dctable ??

I tried to compile it, but it only takes int or unsigned int for input for the interpolation. So no Char.
So when i just change to intrp_1ditable and slipy to unsigned int, then i get decimal places. But the number makes no sense, as i need to declare slipy as a wrong datatype.

[jsmcortina]

So back to my question from my last post: Is it somehow possible with intrp_1ditable instead of intrp_1dctable ??

Both "int" and "char" are both integer (non decimal) types, "int" is 16 bits, "char" is 8 bits. You'd probably need to allow more space for the data by re-arranging the configuration data in ms3.h and adjusting core.ini to match.

James

[Speedy_G]

okay thanks for the help. Now its working.

I had to delete all the OUTMSG stuff. I hope i don't need it
But those were directly after the TC SLIP stuff, so i get a lot of free space in the right position.
So now i could change both to U16, which made it possible to use the intrp_1ditable.
And this made it possible to get decimal places.

For the slip value i tried alot. And finally used *1000UL instead of *100L.
Dont know if the UL instead L is necassary ?? But i found another example in the firmware, where this was done like this.
And when testing 1000L or 1000UL made no difference.
At first i was afraid because slightly theoretical slip values (for example front wheel +0.1m/s than rear wheel) always resulted in crasy high positive slip-values.
A bit higher negative values were (for example +0.9 m/s on the front wheel) were reasonable.
After alot of testing i remembered that in that case (vss2>vss1) the traction control is deactivated anyway. So no reason to worry here

With both changes it was no problem to get 1 decimal place.
Somehow there were some problems on the slip_threshold with two decimal places. It was interpolating wrong values.
And as i only can enter one decimal place in tunerstudio i left it this way.
Or specificaly, when i entered 123.45, megasquirt was actually calculating with that value and stored that into the memory. But in the 2dtable (or better curve) tunerstudio always rounds that value. So it would make no sense anyway.

As there was alot of empty space i could also raise the size of the slip_threshold stuff. Which is normally 9 cells.

And I managed it to transmit the other missing TC-Values, like Spark Cut and Add Fuel by using some (for me) unused outpc variables (for example nitrous duty1&2, boost_target 1&2 and so on.

So for the moment, i have implemented all the features i wanted to have. Will test it in a few weeks on the racetrack.
But of course it would be much better, when those features were implemented in a clean way into a release firmware.
So not by misusing any other functions.