Matt,
What did your math look like for changing the time stamp in to a running time? Are you using excel?
I agree it would be nice to have running time, and some other stuff, but I'm not sure that it should be done in hardware, as I'd vote to keep the logging as lean as possible to help performance. I'd be happy if the software converted everything after the fact when we import.
RaceRender 2
-
- Posts: 101
- Joined: Tue Jan 15, 2013 1:37 pm
Oh, I forgot. Did you run your video through any processing? I did with mine and happened to find that it changed the frame rate on me, screwing up the video length!! I don't think this is common, but I'd make sure that your source video and your processed (before RR) video were the same length.
Also, did you make sure to specify your new, running time as the time channel? It won't pick it automatically.
Also, did you make sure to specify your new, running time as the time channel? It won't pick it automatically.
I was just using some perl to translate. Basically subtracting the time from the previous time and subtracting 4040 if the difference > 4000 and subtracting 40 if the difference > 30. (This doesn't take into account days incrementing but I didn't have any of that in my data.)dimondjack wrote:Matt,
What did your math look like for changing the time stamp in to a running time? Are you using excel?
I agree it would be nice to have running time, and some other stuff, but I'm not sure that it should be done in hardware, as I'd vote to keep the logging as lean as possible to help performance. I'd be happy if the software converted everything after the fact when we import.
Looking over the times, they all look reasonable.
You might be right there. I imported to iMovie and used the files it stored there. I'm using the "raw" clip though, not stabilized or anything. But just the import may have changed some characteristics maybe.dimondjack wrote:Oh, I forgot. Did you run your video through any processing? I did with mine and happened to find that it changed the frame rate on me, screwing up the video length!! I don't think this is common, but I'd make sure that your source video and your processed (before RR) video were the same length.
Also, did you make sure to specify your new, running time as the time channel? It won't pick it automatically.
Yeah, I moved the "time" field to the first and made sure it was set properly.
Everything "works" it just ends up skewing more and more each lap.
I'll have to pay more attention to the data I gather this coming weekend.
-
- Posts: 12
- Joined: Fri Aug 02, 2013 5:14 am
That seems backward. Acceleration pushes you back in your seat, hence +G. Braking pulls you out of your seat, hence -G. (Though if everybody else has standardized on being stupid, I guess you're better off sticking with them rather than doing it right.)brentp wrote:Y Axis (Braking / Accelerating) : +G is braking and -G is acceleration
Comments ?
The ChumpCar/LeMon: 1988 Ford Mustang, with '87-'88 Thunderbird Turbo Coupe turbocharged engine. Covered in stickers, was #74, then #94, now #75.
We race in Texas and vicinity.
We race in Texas and vicinity.
Not sure why everyone thinks the Y-axis is for braking and acceleration.....Mr. Wednesday wrote:That seems backward. Acceleration pushes you back in your seat, hence +G. Braking pulls you out of your seat, hence -G. (Though if everybody else has standardized on being stupid, I guess you're better off sticking with them rather than doing it right.)brentp wrote:Y Axis (Braking / Accelerating) : +G is braking and -G is acceleration
Comments ?
Industry standard is that the X-axis is for longitudinal, and Y-axis is for lateral acceleration. +X is acceleration and +Y is right turn. And that's how I configured my unit.
I sent an email to the RaceRender people, and they put in a fix for this. Here is the email I got back from them:
Thanks for sending the file and info… It turns out that the issue was just that the time was in hhmmss.nnn format, but was being interpreted by RaceRender as if it was just a simple number of seconds, so that ended up introducing 40 second gaps once per minute.
This is resolved in RaceRender 2.9.3, which will identify files that use that specific time column name, and then interpret the format correctly. It is now available here: http://RaceRender.com/RR2/Download.html
Thanks for sending the file and info… It turns out that the issue was just that the time was in hhmmss.nnn format, but was being interpreted by RaceRender as if it was just a simple number of seconds, so that ended up introducing 40 second gaps once per minute.
This is resolved in RaceRender 2.9.3, which will identify files that use that specific time column name, and then interpret the format correctly. It is now available here: http://RaceRender.com/RR2/Download.html