Page 2 of 2

Posted: Mon Jul 15, 2013 12:40 pm
by dimondjack
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.

Posted: Mon Jul 15, 2013 12:42 pm
by dimondjack
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.

Posted: Wed Jul 17, 2013 4:57 am
by mattlqx
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.
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.)

Looking over the times, they all look reasonable.
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.
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.

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.

Posted: Wed Jul 17, 2013 5:09 am
by brentp
We're looking at an issue initially reported by diamondjack where the data is logging about 10% too fast. Stand by for an update..

Posted: Wed Jul 17, 2013 6:46 am
by brentp
Firmware 1.1.13 has been released which dramatically improves the accuracy of the logging rate. Get it while it's hot!

Posted: Sat Aug 03, 2013 2:58 am
by Mr. Wednesday
brentp wrote:Y Axis (Braking / Accelerating) : +G is braking and -G is acceleration
Comments ?
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.)

Posted: Sat Aug 03, 2013 10:33 am
by GTIspirit
Mr. Wednesday wrote:
brentp wrote:Y Axis (Braking / Accelerating) : +G is braking and -G is acceleration
Comments ?
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.)
Not sure why everyone thinks the Y-axis is for braking and acceleration..... :?:

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.

Posted: Thu Aug 22, 2013 6:15 pm
by gizmodo
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

Posted: Mon Sep 16, 2013 9:27 pm
by mattlqx
I'm on 2.9.4 and it still doesn't seem to interpret the time correctly. :\

Posted: Tue Sep 17, 2013 2:00 pm
by gizmodo
Did you tell RaceRender which column to use for the time source?

Posted: Tue Sep 17, 2013 5:03 pm
by mattlqx
Yes, to which it has a data span of 1 second. So that's obviously no good.