CAN Wheel speeds from AIM dash to M150

[David Ferguson]

Sorry for the delay, my home internet connection was down last night when I was ready to respond.

What the M1 is expecting is a frequency. Assuming the wheel circumference in your M1 Package is correct (1.940 meters both front and rear), then to convert from km/h to rev/s we would first multiply by 1000 (meters/km) to get meters, then divide by 3600 (sec/hour) and by the circumference to get revolutions. So

SpeedRevPerSec(Rev/sec) = SpeedKmPerHour (km/h) * 1000 / (3600 * 1.94) or just SpeedKm * 0.14318442. Now according to the help in M1 Tune for "Sensor Scale", it says the CAN values are expected to be in mHz (milliHertz), so to convert this we multiply by 1000. Giving us SpeedmHz = SpeedKmPerHour * 143.18.

So in your Aim RS2, CAN Output, you change the output channels to multiply by 143.18 as shown below

Aim Race Studio 3 CAN Output Configuration

RS3 CAN Output.JPG (90.33 KiB) Viewed 143 times

In M1 Tune, I believe the Scale should now be 1.0, but you can change it as needed (have no data but there is data on the bus, then multiply by 10, 100 or 1000). Here is where I would start with M1 Tune on your package:

M1 CAN Wheelspeed Config

M1 CAN Wheelspeed Config.JPG (106.51 KiB) Viewed 143 times

Give that a try and see what happens.

[NathanB]

What David is saying is correct in that the wheel speeds are expecting a frequency signal as the wheel speed module is based around wired inputs ie. reading the sensor tone wheel.

It is possible to fudge this when transmitting a wheel speed value.

Dave has explained it all, however I have a different methodology for this, as multiplying the wheel speed value on transmit is more likely to get you into overflow for the two byte signed message.

In the ECU config do the following for each wheel speed:

- Set the scale to 1431.8
- Set the sensor teeth to 100
- Set the sample teeth to 1

This will allow you to leave the dash as transmitting wheel speeds.

[oversteer]

Thanks for your help David and Nathan.

I first tried David's config and this resulted in some wheel speeds but something's not right, the first wheel FL is doing something different to the rest in that it flashes to 256 and then a more or less correct number, with many Communications Timeouts happening what seems like every 1 sec, other 3 wheels cycle between correct number and near zero when the timeout happens.

I tried Nathans suggestion, but could not use "1" tooth, that's invalid, so used 0 and that resulted in the same behaviour as above, but wheel speeds were x 10 off(2.8 for 28).

Looking at can messages for 0x7F0 from first test(ran car from 0-~60Kmph-0, file 0000019.txt in drive folder below) I can see the correct speed bytes being transmitted, but only on every 3rd and 4th message with 01 00 00 00 00 00 00 00 in-between.
Same with the next test but with different numbers because of multiplier change in dash(file 0000020.txt)
Motec log file also in folder share, you can see FL speed jumping to 128 and 256, both tests are at end of log, but there is no power cycle marker between because I stopped engine with run switch.

https://drive.google.com/drive/folders/ ... sp=sharing

From what I know about CAN( not that much !) it must be the message speed data gaps with the 01 00 00 00 00 00 00 00 causing the timeouts and unstable readings, with the 01 in the 01 00 00 00 00 00 00 00 message throwing the 128 and 256 in there !!??

So the dash sending the message is the issue ?

Is it something to do with the message frequency ? which I have tried to keep consistent at 20Hz from the subaru can to the math to the transmit... How do I tell what the frequency is on the subaru bus to start ?

Getting closer !

[David Ferguson]

In my experience with Aim (I've been a dealer for them nearly as long as I've been a dealer for MoTeC!), it's certainly the math processing in the dash that is the problem. Our best chance at fixing this is probably fixing the input CAN protocol to create the 16bit wheel speed value directly. If you could export the CAN protocol "Justin - Subaru Wheelspd 500 Kbit/sec" from your Race Studio 3, I would be willing to take a look.

[oversteer]

Thanks David

https://drive.google.com/file/d/1g8G0k3 ... sp=sharing

In that I have taken the major and minor bit separate so I can apply the math to them(2nd bit * 256 + first), its likely a bad way of doing it !

[David Ferguson]

OK, the Subaru format is Little-Endian, so you just need to set that to do the byte combining correctly. The scaling of 0.0555 can be done as well, so the CAN protocol should be producing speed in km/hr directly.

Here is a new CAN protocol and your Config updated to use this protocol. Use the scaling that Nathan provided, but perhaps change the sensor teeth to 10 from 100 to account for the off-by-10x result.

Aim Dash Config.zip

(1.49 MiB) Downloaded 5 times

CAN Protocol.zip

(18.03 KiB) Downloaded 6 times

[oversteer]

Ok so that new config works in the dash and is a lot cleaner, but it has not solved the problem which I now know more about after spending so much time playing with this issue...

There is still a 01 00 00 00 00 00 00 00 message inbetween the correct data, and this message is related to the primary fuel pump running !, not sure if its the fuel pressure data being recieved by the dash or what, but if I just have ignition on with engine run off the data transmitted by the dash is all zeros, switch engine run on and there is a series of 01 00 00 00 00 00 00 00 in the data that happens with the fuel pump priming, then stops after prime, start the engine and its 01 00 00 00 00 00 00 00 again !(file run switch on off.txt is engine run switch on-off-on-off)

This shows up as 256(or 25.6Kmph) on FL wheel and causes the signal timeout to the other wheels. I have sniffed the suabru bus to make sure its not coming from there to the dash, its not(file Subaru bus engine run on off.txt).

So its the dash throwing that bad data when fuel pump runs... if it wasn't for that the speed signals would be fine.

Is there somthing in the dash config ? or is this a bug !?

*****EDIT******

Seems I have solved the problem by changing the ID from 0x7f0 to 0x10, some sort of cross over happening at the address closer to the normal dash data maybe...

Anyway its fixed now ! Still may have been cheaper to just buy a motec dash with all the time that has been put into getting this to work, but I guess that assumes it would have been straight forward to get a motec dash to do this !

Thanks again for everyones help.