I get the impression that there is quite a bit of code regarding handling of GPS data, so I don't know how simple a feature request like this would be. I guess that could be a deviation from a concept that RaceRender just accepts the input as given and doesn't try to be smarter than the incoming data, but I don't think that's the paradigm that RaceRender typically uses especially with regards to interpolating GPS data and trying to improve accuracy/timing. I would absolutely agree that this is a way that RaceRender could be improved and could help users who might be a little less technical. As I wrote in that post ( ):ĭo you know whether anyone on staff has considered such defensive analysis and programming, or am I talking to a wall here?Weston seems to be the only staff member that posts here, and he doesn't seem to post much recently, but he has said that he reads the forum posts (also from your previous thread). OK to average out those rows, with the data appearing before and after?"ĭo you know whether anyone on staff has considered such defensive analysis and programming, or am I talking to a wall think this is another case of bad data sneaking in. At that point, if I were doing the programming - and I'm a retired geek - I would emit a dialog box, saying something like, "A few rows of data appear to be in error. OTOH, RR can have a look at ALL the data as it imports it, and with some simple programming can figure out that some rows of data are way out of whack.
That is, since a GoPro device is acquiring this data in real time, it's almost impossible (barring some tricky internal buffering calculations) for GoPro to catch any of its own mistakes. I mean, that kind of task is exactly the kind of work computers are good for. It would be a whole lot easier than having the user open a spreadsheet each time a straight line appears as the path of travel, searching for bad data, and adjusting it.
RACERENDER SOFTWARE
Since we can't assume perfection in hardware, the software - RR - should correct for this. Since you don't have laps, perhaps you could click the Laps button, then click Edit Lap Times in the pop-up, then delete everything in the textbox and think this is another case of bad data sneaking in.
This thread lists some of the details, but not everything there may apply to you. So if you see something that jumps from 41.5 to 0.2 and back to 41.5, then you could try just deleting the 0.2 row. In this instance, very far away would be anything greater than 0.1 degrees away (and probably not more than 0.01). This will cause RaceRender to interpret the first 10 seconds as staging time which don't count towards the map display.Īlternatively, you could try to open up the CSV in Excel or Google Sheets to try to find a row that is very far away from the rows around it for Latitude and/or Longitude.
To the lap times (or perhaps longer than 10 seconds to get beyond the coordinate that cause the issue). Since you don't have laps, perhaps you could click the Laps button, then click Edit Lap Times in the pop-up, then delete everything in the textbox and add: RaceRender does not seem to be good at detecting these anomalies and just ends up showing a giant line to the one bad row instead of just ignoring it. This ends up looking like a small map at one side and then a huge line to the row that is incorrect. One (or more) of the GPS coordinates are recorded or extracted incorrectly causing RaceRender to think that nearly everything is in one location, but one or two rows are in another country. I don't think this should be a big issue, but it might actually be causing the second possibility.Ģ. You do appear to have open sky, but there are a number of trees lining the road. It might not have a lock on all of the satellites when it first turns on. This could be the GoPro synchronizing with the satellites before it can fully triangulate its position. Here's a link to the screenshot: think there might be two possibilities here:ġ. Changing the firmware from 1.6 to 1.7 did not help.
0 kommentar(er)
