cyotani

iTrader: (8)

This seems like a good place to post this little project.

I recently picked up a Racecapture Pro 2. And so far, I am very impressed. The LUA scripting feature sets this logger apart from anything else. I was able to write CAN bus code to sync data for a arduino based 12 sensor IR tire temp system in just a few hours. The software is pretty straight forward and the android app display with predictive lap timing is a nice feature.

Unfortunately my car blew up on me the first time out on the track with the system but I'll post a more detailed review once I have more hands on experience with the system. In the mean time, here is some install pics and a DIY sensor breakout box. I wanted to clean up the wiring and make it easy to change sensors and provide the necessary pull up resistors for the passive temp sensors.

Material costs (about $35 total)
-5x 2 pin GX16 connectors ($7 ebay)
-5x 3 pin GX16 connectors ($7 ebay)
-DB25 breakout board ($12 amazon)
-DB25 cable ($9 amazon)
-Misc wires and resistors laying around the house
-3D printer enclosure

Pull up resistors for the new sensor breakout box for my racecapture


enclosure printing




All wired up, This makes it much easier to add new sensors and pass everything through the firewall with a single cable.


Messy engine bay


Finished the install

Leafy

iTrader: (1)

Chris, whats your sample rate with the canbus into the rcp with this setup? The most interesting part of having the IR thermo's on each wheel is the data you can gleam from logging them over 100hz. Anything much less than that and they're just easier to use pyrometers.

cyotani

iTrader: (8)

What do you mean by gleam?

Right now I can record data at about 10Hz. That's a limitation of how long it takes to write to and read from 12 different sensors using I2C protocal (not a limitation on the can bus or the RCP). I can put 1 arduino per corner and get it up to 40 Hz or so but 10Hz seems plenty for me.

A pyrometer really is not the same as an IR setup. You can not look at transient temperatures with a pyro and the readings are not accurate after the cool down lap and the 1+ min difference in time before you first reading and last reading.

With IR sensors I can see a 10+ deg increase in the outside wheels in a steady state turn and see it drop down back to near it's original reading a split second after straightening out the wheel on corner exit. It's really a completely different system then a pyro. I also don't see why you would need any more than 10 Hz unless you want to oversample and smooth.

Leafy

iTrader: (1)

Really? I'm working with some guys paralleling you more or less and their concern was the limited rate on the rcp2 can bus. I dont think they realized that the i2c was so slow since the documentation makes it seem like you can run it as fast as you want if you ramp up the clock speed.

cyotani

iTrader: (8)

I2c runs at 100kbps in standard mode. There is an option for 400kbps. I might give that a try if the sensors support that rate. CANbus is 500kbps standard up to 1000kbps.

To read the sensors you need to write 1 byte then read 3 bytes so 4 bytes total per sensor. In my CAN bus output I made each temp a byte of data so 1 CANbus Frame contains 8 temp readings. I might make it 2 bytes per reading for more resolution, but the bottle neck will still be the I2C.

Maybe one micrcontroller and CAN board per sensor if your set on 100Hz.

Leafy

iTrader: (1)

I know the IR sensors we were planning to use only support 100khz bus clock, probably case by case basis on how far they'd reliably overlock. But with 12 sensors at 4 cycles per sensor still gets you 2000ish readings per second on a 100khz bus.

cyotani

iTrader: (8)

Your missing the 8 bits per byte.

12 sensors * 4 bytes per sensor * 8 bits per byte = 384 bits per sample.
100000 bit/s / 384 = 260 theoretical max samples per second for just the communication section of the code.

The other overhead must come from the internal code processing and conversions to convert the raw data to temp. Also the overhead to transmit the CAN frames. The code might be optimizable for faster throughput but I'm not a CS/software major with that expertise.

I think when I had it programmed in LabView rather than the arduino I timed the temp sensor loop at 20ms for 12 readings which would be 50Hz. But I also slowed it down to 10Hz to allow overhead for other sub routines.

Leafy

iTrader: (1)

Holy crap I missed the bytes part entirely. Yeah the MLX90614 sensors we're planning to use only transmit at most 8 bits of sensor resolution. And if for some reason we do run into the i2c being too slow they have a normal pwm output option where the polling rate is determined by how large of a temperature range you care about, and that runs in a parallel setup to individual imputs rather than on a serial bus.

cyotani

iTrader: (8)

Sorry, the 10 Hz was with the a color LCD display the really slowed it down. I just clocked the loop rate for 12 sensor reading + CAN output at 18ms so I have my loop rate a 20ms for 50 Hz.

The system is still Arduino/I2c speed limited and not RCP/CAN bus limited. 2 arduinos can get you up to 100 Hz.

vtjballeng

iTrader: (1)

Great work guys, the MLX90614 is a great option. I've got a couple of teams ready for either a three sensor setup or the MLX90614 that can dump over CAN to the RCP currently. So if you are interested in selling a building a couple of units, I'm interested in buying a couple.

cyotani

iTrader: (8)

Sending you a PM

vtjballeng

iTrader: (1)

These are effectively on car pyrometers. A handheld pyrometer measures in the pits after the tires have cooled, only gets surface temperature, and is generally inferior to a carcass probe method.

1Hz provides very good data. 10Hz is excellent. 100Hz+ is overkill for this particular logging parameter unless you possess superior tire modeling skills and are performing development at the top levels of motorsports.

Or maybe I have missed something in the reasoning? So, walk through the logic. Why 100Hz?

Leafy

iTrader: (1)

If you are measuring the tire right as it comes off the pavement, at 100+hz, have steering angle, brake pressure, and throttle position, along with acceleration and speed you can exactly pinpoint how and why you are over/under driving along with a handful of other setup issues you cant find with slower tire readings (without changing something and seeing how it changes the slower tire temp data). Was the car washing out due to poor setup? hitting the bump stop mid turn? hitting a bump mid turn? going too fast? too much steering angle? not enough steering angle? braking too late? too much gas too soon? some combination of above? etc.

vtjballeng

iTrader: (1)

The answer is shock pots, which you log at 500hz or better. You get a far clearer picture of bump stop, hitting a bump, washing out, etc with the combination of those variables. You would not be guessing at say bump stops based on tire data. Understeer will still show up at 10Hz, late braking falls on wheel speeds, shock pots, pitch. Too much gas too soon is yaw, shock pots, wheel speed & tire (10Hz ok here).

Still, if you are in a good enough position with proper logging rates for your G values, wheel speeds, steering position, brake pressure, TPS, GPS data, yaw, pitch, roll, and a slew of other variables with ~1000hz rates on your shock pots, then 100Hz on your tire temperatures can provide relevant data. Making some productive use of that 100Hz tire data typically still falls into the upper levels of motorsports where you have a race engineer involved.

At the club level, 10Hz is still good and the data is still very useful at 10Hz compared to just looking at pit tire temps.

wnwright

Has there been any progress on CAN bus from Megasquirt to Racecapture? I'm trying to use a MSPNP in my 02 with Racecapture. The Megasquirt documentation published 5/19 references menus that aren't in my Tunerstudio, but I have the latest version.