Printable View
Hi all,
I am having trouble using the data files from racecapture pro mk3 in Racerender.
I have tried exporting the log files from racecapture app and used the .log file that was exported but RR does not display any information from the log.
I tried renaming to .csv - still no data displayed. When viewing the files in notepad they appear to be csv formatted with comma as separator.
Anyone run into this?
Thanks,
Opy
If you can post the file here, or send it to me at Info@RaceRender.com, I'll take a look and see what's happening...
I managed to get the files to work. I had to delete early parts of the data log that were recorded without a GPS fix. My time stamps are from GPS data and I think RR was not able to resolve the lack of time records. I was then able to manually configure the data to work. :)
Thanks for sending the file. The column headings look like a different format than we've seen before. I'm working on parsing those right now, and will include that improvement in the version 3.5.7 update that will be released this coming week...
I'm having a hell of a time trying to get the latest version of the software to work with data from an RaceCapture Pro Mk3 in v3.5.7 of RaceRender. I used the raw log, since the changelog says it should be compatible. Biggest issue is that when I try to use the synchronization tool, or adjust the trim of the file int he input's configuration, the app hangs for a good 20+ seconds. This is making the process extremely frustrating to line up data with video. I'd like to upload a file but I get an invalid file error.
I loaded the update and found it works well. I did have a problem with one of my log files. I found parentheses in the wrong place in the headings section. After correcting the file it worked great with all fields set to automatic. I'm not sure if the log file was corrupt from the beginning or if it was later corrupted by opening it in an "Open Office" spreadsheet app.
I suspect the file will be too big for e-mail or the forum, but if you could upload it to a site like Dropbox, Google Drive, etc., and then share the link, I'll take a look and see what we can do...Quote:
Originally Posted by jpf11
Sure, here's the Google Drive link. https://drive.google.com/file/d/0B8I...ew?usp=sharingQuote:
Originally Posted by Weston@HPTuners
Thanks for linking the file. The problem was just that the timestamps in this data are erroneous at the very start... I starts at 905363 ms, then immediately goes backward to 905282, and then goes on to 905353, 905363 (repeated from before), and so on. Backwards or out of order data tends to be problematic, as there's no correct way to process it, and it can lead to some weird behavior. But if I were to guess, I'd expect that this is a rare fluke in the data, so hopefully it wont be something that happens very often with your data system.Quote:
Originally Posted by jpf11
In any case, once I deleted the first two data rows, all appears to be well. Here's a link to the fixed version: https://drive.google.com/file/d/0BxW...ew?usp=sharing
Yes, it seems that OpenOffice Calc rearranges some quotes...Quote:
Originally Posted by Opytuner
So, instead of:
"Interval"|"ms"|0|0|1
OpenOffice turns it into:
"Interval|""ms""|0|0|1"
I'll soon be releasing a minor update as v3.5.7a for other reasons, and will see if I can get it to handle both arrangements here too...
Thanks for finding the problem. I'll report it to the developer to see why the timestamps go out of order.Quote:
Originally Posted by Weston@HPTuners
I was thinking about this issue a bit. Is it technically wrong for the source to have log entries that are chronologically out of order since the data is still timestamped? I might argue it is the processor, in this case RaceRender, that should have to handle such issues (i.e. a timestamp based sort of the data prior to execution of everything else). The data's still there and valid. Putting this out there because I can see the RaceCapture guys arguing this isn't technically their problem and I have a hard time disagreeing.Quote:
Originally Posted by jpf11
While there might be cases where a particular system writes out-of-order data that it considers to be technically valid (requiring the user or us to sort it), that would be quite unusual. An added difficulty is that we have to support nearly everything, and for the vast majority of data systems I've encountered, out-of-order timing definitely does represent erroneous data (or at least invalid timing) that is best handled by filtering it out entirely. Logically, the data would have originally been logged in chronological order, so we wouldn't expect it to become out of order.Quote:
Originally Posted by jpf11
Trying to salvage data in that situation is filled with uncertainties, because we wont know if 1) the data system's clock just shifted/corrected, 2) the data is simply out of order and needs to be sorted, or 3) it's junk data samples entirely. #1 and #3 are by far the most common. Ultimately, nothing we could reasonably do here will shield the user from problems 100% of the time, and this is not intended to be a data recovery tool, so we do what works best for the majority of the situations and try to filter out the suspect data. If it's only one data sample at a time, as it appears to be in your case, that makes for a very tiny change to the data and should be virtually imperceptible to the user experience within RaceRender.
RaceRender is pretty flexible with its data input, because there are some other systems that give us some really messy or unreliable data, along with taking some interesting liberties with the CSV format, but there are still a few unusual situations that could trip it up. In this case, the problem you encountered with v3.5.7 was mostly caused by the data going backwards to a timestamp that was before the very first sample. Version 3.5.7a has expanded its bad data rejection logic a bit further, and should help with that.
Thanks for this update!
I had a question regarding the g meter. I put a video together using data logged from a RCP.
I notice the g meter seems off. See this video around 54seconds.
https://drive.google.com/file/d/0B-U...w?usp=drivesdk
Data log from run is attached.
https://drive.google.com/file/d/0B-U...w?usp=drivesdk
User error? Is the datalog bad?
I've confirmed on the race capture forum the datalog is solid.Quote:
Originally Posted by boggie1688
The g ball movement is spot on, however the calculated G value is incorrect.
Looks like the number being displayed there is your longitudinal acceleration (ie forward acceleration / braking), rather than the lateral that would normally be used for this. To change this option, double-click on your g-force display object to open its properties box on the right, and then change which "Show Number" option is checked... There's one associated with the "Left / Right" settings, and then another for "Accel / Decel" stuff below it. You probably want only the first one to be checked.Quote:
Originally Posted by boggie1688
Attachment 70075
Quote:
Originally Posted by Weston@HPTuners
DERP! ^_^
Thanks.