Race Capture 2
 

Apparenly Autosports Labs are coming out with a second version of their data logger.

The original one was, in my opinion, quite amazing. They had a crowdfunding campaign for $250 and I was sad that I missed out on it.

Now they are coming out with a new version and and its pretty baller
Specifications

RaceCapture/Pro 2 | Autosport Labs

Hi soviet, thanks for sharing! let us know if we can answer any specific questions as it pertains to Miatas / turbo Miatas especially :)

A couple of weeks ago we were talking with Keith Tanner and the topic of Hydra integration via CAN bus came up. After looking at their CAN bus protocol it'll be very easy to injest that data via one of the CAN ports on RCP.

Most of the members use megasquirt so if you can get that CAN protocol to work the Miata turbo community would be happy.

Very nice price for the system. 50Hz gps rate is crazy fast. What data analysis software does your system use?

Hi cyotani, Good point about megasquirt. Basically we can accept any CAN bus format and translate them into virtual channel data, so long as the format is known.

On the topic of analysis, we'll have 3 options:

1) web based analysis of session data at RaceCapture/Live - Wireless race car data and telemetry system . Data flows to the cloud in real-time via telemetry for live analysis of data, and afterwards.

2) The new V2 app will offer analysis features and be targeted for touch-oriented devices (phone / tablet) - so you won't need your laptop trackside. The app will also run on Windows / OS X / Linux as well. Some app screenshots: http://imgur.com/a/bsyDt

3) For the more traditional approach, we'll provide an easy export to the industry-standard, free-to-use GEMS analysis software: GEMS - General Engine Management Systems Ltd - GEMS Data Analysis - GDA

So the pre-order price is basically the same as the old RCP price?

Correct. We haven't yet established pricing after the pre-order phase is complete.

I didnt see it on the site, whats the end date of the pre-order?

A good question! Pre-order phase will end when we start shipping the-pre orders. Likely near the beginning of November.

Will the the temetry module cost the same $129.99 after the preorder is over? Or is it discounted at pre-order price?

We don't have pricing for post-pre-order phase, sorry! It may or may not change. Likely not drastically.

Is the software free or included with you hardware? Their website says free with use of their hardware but I couldn't find a stand alone price.

Also I thought you have to build your own CAN PIDs in the MS code to configure messages which would make it not a standard OBDII style layout.

MegaSquirt-II Controller Area Network

Or does the MS code send out CAN packets with the usual RPM, CLT, etc in OBDII style formats, and this document linked about just an optional feature you can develop.

There is a free-to-use version of the GEMS software that you can download and use.

Actually, this started out when one of our users contributed a conversion script that transforms our data files into GEMS format. ( https://github.com/autosportlabs/RCP2GEMS ) We'll be incorporating this script as a 'save as' option in our software.

We don't officially endorse the the use of GEMS nor do we have a business relationship with them - just that it's a data format we support. Kind of like how OpenOffice supports saving in MS Office format.

Also worth noting that the analysis features we'll be creating will have many of the essential capabilities of the desktop software, but in a tablet / touch oriented interface and be connected to the cloud and real-time data, so you can mix/match data comparisons between your sessions, sessions from your friends, and so on. Hope that helps!

Whatever format MS emits on CAN we'll be able to decode and transform into virtual channels, using the appropriate mapping script. These virtual channels can be combined with the built in sensor channels, GPS, accelerometer/gyro, etc.

Is the analysis software also scheduled to improve/improved recently? It was lack luster enough last time I looked that I would pay more money for inferior hardware that comes with better software.

Hi Leafy, we hear you :) We're improving the software quite a bit - both in features and moving it to a modern, touch-oriented interface, where the data will be accessible in real-time and also for off-line analysis.

And, for the traditional software route, we'll also have an export to the GEMS format so you can do your analysis there too.

Doesn't Rev sell a converter to make a MSIII look like a standard OBD-II ECU?

I'd have to learn more about how MS's CAN interface works, but if it can be configured to continuously stream CAN bus messages that would be much higher performance than the OBD-II style request / reply for PIDs.

In fact, on Sunday we tapped into the instrument cluster stream for a 2006 Lotus Elise; here's a little write-up on how we did it: Pre- CAN/OBD-II Lotus elise – you CAN data! | Autosport Labs

Yep: https://www.miataturbo.net/ms-labs-m...s3-ecus-79429/

Brent Picasso: Go work with Reverant to make this Plug & Play with the MS2/MS3 and I dare say you will sell quite a few of these units.

Nice, reminds me of a LabView CAN data logger I wrote for my FSAE team using the user configurable AEM ECU CAN stream.

RaceCapture/Pro supports standard OBD-II PID querying right out of the box, so if that's the case we're already good to go.

If there's a streaming protocol, that can be adapted as well for super-awesome mode :)

That's all kinds of win. Thanks for coming over and hanging out with us and sharing the awesome :)

thanks too! Any more questions, just let me know. In the meantime, I have an evaluation Hydra on the way from Flyin Miata to do some CAN bus integration.

:o

Direct CAN will have all the parameters and not only the ones that can exists in the OBD-II. And with direct CAN to MS2/3 no extra thingy needed, just two wires.

I have no idea how fresh this is but it's a start and contains more facts that I can digest.
MegaSquirt-II Controller Area Network

I am very interested in this. I recently bought a tablet and was thinking about mounting it in my Miata. With my need for telemetry, this looks like my ticket. Like others, I am running a MS2. From my understanding in this thread, that should not be a problem.

Thanks, XeNoMoRpH - if we can get the channel to CAN message protocol we can certainly help create the script to make it work.

Well, I preordered. I guess I can start working on a tablet mount :) and have a project for the winter.

MS3 offers CAN broadcasting using standard 11 bit headers. I assume you can map it out if I supplied a dbc file?

Email me (ben@diyautotune.com) and we'll get things lined out for mutual interoperability.

Hi Ben,

MS3 would likely be very straightforward to integrate. I'll drop you an email and we'll do a write-up.

thanks!

We got our hands on a Race Capture box this afternoon and installed it in the Chump car, the evening of a 14 hour race. We don't have power at our pit, so we worked under lights until our generator failed, at which point we found a Mexican restaurant with fajitas and margaritas.


So for this event, the Race Capture doesn't have near as many inputs set up as we would like, but it is in the car and transmitting data. I'm really looking forward to crunching data at pit side tomorrow. The ability to access this telemetry data real-time has the ability to transform the way we endurance race.


Anyone interested in watching live streaming can do so at this link:
ChumpCar Frozen Peaches and Cream - RaceCapture/Live


Green flag 2-7-15 @ 8am eastern. Checkered at 10 pm eastern. Go #8 Hong Norrth Tr0nsAm!


Expect a more comprehensive write up and review later. Off to bed now.

Glad we got you up and running! Just wait until we get CAN bus data flowing. :)

Live data is available and running. Race Capture's GPS based lap timing is showing within .03 of transponder. Pretty good!

Pretty good timing with the 50Hz module; and we still have some optimization tricks to do!

You can also click on multiple laps on the left, compare the lap-lap data in the charts, and also zoom in on the GPS and see the actual line taken between laps.

Race fast and smooth!

Sub for a full review and MS3 compatibility.

Progress - Got the MS3-Pro and RCP wired together on the bench with power and CAN bus connections.

We've added to our CAN bus database the MS channels we think people would find most interesting. More can be added, of course: CAN Bus database - Autosport Labs

Next, need to enable CAN channels in the MS3-Pro and write the script to map the CAN bus data to RCP virtual channels.

Attachment 235188

I think I'm going to be picking up one of these.

Any word on CAN integration with DIYPNP and MS2 ecus?

We have the initial mapping in place with what we would call the Megasquirt standard mode CAN support. Ben advised me there's a more concise "Dashboard" mode which we will also add support.

This is a trivial integration for us - it's going to work great. Our MS3 Pro will soon see life in the Exocet kit - arriving SOON :)

Beginnings of the documentation is here:
Megasquirt CAN - Autosport Labs
CAN Bus database - Autosport Labs

Looks like its working nicely for the MS3 pro but I just want to make sure I can get this set up on my DIYPNP as well. They both have CAN output so I'd imagine it's capable but I just want to make sure it would be just as easy to integrate as the ms3pro or close to it.

There's absolutely no CAN system we cannot integrate. If it's undocumented, that just makes the reverse engineering more fun. :)

So, yeah.

Ben can speak to MS2 / DIYPNP better.

The MS2 'standard' CAN broadcast mode should work now (probably just need a little more documentation from Brent, unless you're pretty code savy). If you're not adventurous, wait for the MS2 'simple' CAN broadcast mode to be finished. I don't have an ETA, but I don't think it will be long.

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
https://www.miataturbo.net/attachmen...ine=1427427981

enclosure printing
https://www.miataturbo.net/attachmen...ine=1427427981

https://www.miataturbo.net/attachmen...ine=1427427981

All wired up, This makes it much easier to add new sensors and pass everything through the firewall with a single cable.
https://www.miataturbo.net/attachmen...ine=1427427981

Messy engine bay
http://i36.photobucket.com/albums/e1...8/IMG_6289.jpg

Finished the install
https://www.miataturbo.net/attachmen...ine=1427427981

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.

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.

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.

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.

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.

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.

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.

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.

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.

Sending you a PM

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?

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.

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.

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.