"Time" data

[dimondjack]

I've just logged a bunch of data on RCP at Loudon, and am trying to take a look at it. I started using RaceAnalyzer but had a few questions about the data so imported it in to Excel to take a look at it.

My question hinges on the "Time" column. I'm assuming this is time from the GPS unit, but I can't figure out how to translate it in to an actual date/time. If I assume that the units are some sort of seconds (1 = 1 second), I get slightly worried as the interval between each data point is not the same. Over my first 40 or so data points it averages an index of ".182" per data point, and ranges from .094 to .406 between each data point.

Not knowing how the system works, it feels like the system should be logging at a consistent interval, or at the very least, averaging .2 seconds per data point (my logging speed was set to 5Hz). Any ideas on why this might be occuring?

[blalor]

This is just HHMMSS.ss (24-hour, minute, second, fraction of a second) in UTC. There's no date, however.

[dimondjack]

Hm. Shouldn't the spacing between each data point be 0.2 seconds then if I'm logging at 5Hz?

Here is what I have:
Time|"Time"|5
144214.594
144214.703
144214.906
144215.094
144215.297
144215.500
144215.594
144215.797
144216.000
144216.203
144216.406
144216.500
144216.703
144216.906

As you can see, the deltas go as such:
0.109
0.203
0.188
0.203
0.203
0.094
0.203
0.203
0.203
0.203
0.094
0.203
0.203
0.188
0.203
0.109
0.188

Any idea why it goes from .094 to .203? It seems like it should be at an even 0.2 seconds. If I take an average it ends up being from around 0.18 seconds to quite over that, depending on the sample I take.

[blalor]

Hm, that looks a little funny. You're getting 4 samples spaced 0.2s apart followed by one 0.1s later (with a little wiggle on either side). Can you share the rest of your config, or at least the full header of the CSV file? It's possible (and this is a total WAG) that Time is getting sent when it shouldn't be, maybe when the position is being sent at a lower rate. It would also be instructive to see the full lines that contain the Time fields you just posted, as well.

[dimondjack]

Does this help? I also attached a file which has the same phenomena from the day earlier (the one from day 2 is reasonably large)
"FuelLevel"|"%"|1,"Battery"|"Volts"|1,"AccelX"|"G"|5,"AccelY"|"G"|5,"AccelZ"|"G"|5,"Yaw"|"Deg/Sec"|5,"LapCount"|""|1,"LapTime"|"seconds"|1,"Latitude"|"Deg"|5,"Longitude"|"Deg"|5,"Speed"|"MPH"|5,"Time"|"Time"|5,"SplitTime"|"seconds"|1

0.116 0.06 1.138 3.198 43.360378 -71.46125 22.84 144214.594
0.143 0.005 1.077 3.625 43.360374 -71.461243 22.78 144214.703
0.12 -0.061 1.118 3.838 43.360367 -71.46122 22.02 144214.906
0.193 0.14 1.173 4.478 43.360363 -71.461197 21.5 144215.094
51.52 14.1 0.238 0.215 1.045 4.691 40 1.673 43.360355 -71.461174 21.06 144215.297
0.265 0.248 0.985 4.691 43.360352 -71.461151 20.77 144215.5
0.288 0.188 0.73 4.691 43.360352 -71.461144 20.44 144215.594
0.286 0.12 0.484 4.478 43.360344 -71.461121 19.96 144215.797
0.336 0.192 0.206 3.838 43.36034 -71.461098 19.14 144216
48.73 14.1 0.259 0.109 0.569 2.985 40 1.673 43.360336 -71.461075 19.09 144216.203
0.238 0.048 0.479 1.919 43.360332 -71.46106 18.72 144216.406
0.203 -0.04 0.538 0.64 43.360329 -71.461052 18.78 144216.5
0.187 -0.048 0.712 -1.279 43.360325 -71.461029 18.57 144216.703
0.181 -0.096 0.748 -4.051 43.360317 -71.461014 18.26 144216.906
57.11 14 0.171 -0.11 0.8 -6.823 40 1.673 43.360313 -71.460991 18.07 144217.094
0.193 -0.186 0.684 -9.595 43.360306 -71.460976 18.04 144217.297
0.217 -0.178 0.934 -12.58 43.360298 -71.460968 18.04 144217.406
0.244 -0.072 1.253 -15.352 43.360291 -71.460953 17.78 144217.594
0.275 0.022 1.486 -17.91 43.360283 -71.460938 17.95 144217.797
60.91 14.1 0.339 0.054 1.598 -20.469 40 1.673 43.360271 -71.460922 18.16 144218
0.33 0.005 1.604 -22.388 43.36026 -71.460907 18.19 144218.203
0.355 -0.005 1.424 -23.667 43.360252 -71.460907 18.26 144218.297
0.371 0.057 1.534 -23.881 43.360241 -71.460899 18.34 144218.5
0.361 -0.024 1.293 -23.028 43.360226 -71.460892 18.91 144218.703
60.66 14.1 0.333 0.027 1.284 -21.322 40 1.673 43.36021 -71.460884 18.89 144218.906
0.295 0.04 1.353 -18.763 43.360195 -71.460876 18.93 144219.094
0.253 0.118 1.354 -15.991 43.360191 -71.460876 19.29 144219.203
0.215 0.05 1.067 -12.793 43.360176 -71.460869 19.29 144219.406
0.159 -0.038 1.063 -9.808 43.360157 -71.460869 19.23 144219.594
51.78 14.1 0.104 -0.101 0.722 -6.183 40 1.673 43.360142 -71.460861 19.23 144219.797
0.066 -0.035 0.86 -2.559 43.36013 -71.460854 18.66 144220
0.004 0.011 1.04 0.853 43.360123 -71.460854 18.7 144220.094
-0.021 0.017 1.013 4.051 43.360107 -71.460854 18.18 144220.297
-0.083 0.067 1.045 7.249 43.360092 -71.460846 18.17 144220.5
47.53 14 -0.12 -0.018 0.955 10.448 40 1.673 43.360081 -71.460838 17.68 144220.703
-0.144 0.038 0.917 13.433 43.360065 -71.460831 17.78 144220.906
-0.215 -0.05 0.783 16.205 43.360054 -71.460823 17.44 144221.094
-0.278 -0.063 0.869 19.19 43.360046 -71.460815 17.37 144221.203
-0.311 -0.027 0.775 22.601 43.360035 -71.460808 17.22 144221.406
56.85 14.1 -0.361 -0.029 1.095 25.586 40 1.673 43.360024 -71.460793 17.17 144221.594
-0.375 0.005 0.972 28.358 43.360016 -71.460785 16.76 144221.797
-0.415 -0.137 0.652 30.704 43.360008 -71.46077 17.26 144222
-0.487 -0.154 0.458 32.836 43.360004 -71.460762 17.76 144222.094
-0.527 -0.217 0.523 34.542 43.359997 -71.460739 18.41 144222.297
51.27 14.1 -0.549 -0.19 0.537 35.821 40 1.673 43.359993 -71.460724 18.37 144222.5
-0.574 -0.265 0.694 36.674 43.359989 -71.460701 18.93 144222.703
-0.667 -0.471 0.471 36.674 43.359989 -71.460678 19.51 144222.906
-0.584 -0.215 0.562 36.674 43.359989 -71.46067 20.12 144223
-0.419 0.027 0.542 36.247 43.359989 -71.460648 20.57 144223.203
55.84 14.1 -0.366 -0.004 0.573 34.968 40 1.673 43.359993 -71.460625 21.47 144223.406
-0.521 -0.286 0.794 33.475 43.359997 -71.460602 21.96 144223.594
-0.614 -0.134 1.122 31.983 43.360004 -71.460579 23.27 144223.797
-0.589 -0.061 0.85 29.851 43.360008 -71.460564 23.93 144223.906
-0.57 -0.018 0.794 27.079 43.360016 -71.460541 24.88 144224.094
48.81 13.9 -0.579 -0.125 0.817 24.52 40 1.673 43.360027 -71.460518 25.92 144224.297
-0.575 -0.139 0.762 21.962 43.360035 -71.460495 26.68 144224.5
-0.376 0.045 1.127 19.616 43.36005 -71.460464 28.4 144224.703
-0.488 -0.228 1.243 17.271 43.360058 -71.460457 29.47 144224.797
-0.713 -0.612 0.919 14.925 43.360069 -71.460426 31.01 144225
49.52 14 -0.68 -0.534 0.585 13.22 40 1.673 43.360085 -71.460396 32.4 144225.203
-0.415 -0.446 0.103 11.727 43.3601 -71.460365 33 144225.406
-0.315 -0.404 0.093 10.021 43.360119 -71.460335 34.22 144225.594
-0.23 -0.255 0.591 9.595 43.360126 -71.46032 35.2 144225.703
-0.172 -0.171 0.863 9.382 43.360146 -71.460289 35.8 144225.906
52.28 14 -0.112 0.067 0.607 9.382 40 1.673 43.360165 -71.460258 35.54 144226.094
-0.051 0.382 0.667 9.382 43.360184 -71.460228 35.48 144226.297
-0.326 0.2 0.186 9.808 43.360207 -71.460197 36.95 144226.5
-0.137 0.504 -0.269 10.021 43.360218 -71.460182 38.82 144226.594

[dimondjack]

Ok,

I've logged more data recently, which you can see here: https://docs.google.com/file/d/0B9Dlhiz ... sp=sharing

Hopefully that worked and you can see my excel doc.

All sensors are logging at 10Hz except for battery voltage, which is logging at 1 Hz.

You'll notice that once the logger starts rolling, it will record 9 data points at an interval of .1 seconds and then one point at 0 seconds. The GPS data is always the same for the next data point. It looks like it is simply grabbing an extra data point a fraction of a second before the next data point.

Something I noticed was that the Battery Voltage actually shifts relative to the "extra" data point, which means that logger is using the UTC time to trigger recordings rather than an internal timer. My question to this: What happens if I'm not using the GPS?

I'm more interested in why this happens and if it means any of the data is "off". Seems like it is a harmless addition, but I'd like to hear if anyone else has the problem and what causes the system to do it.


David

[ehorner]

Sorry to bring this back from the dead, but I am seeing no resolution to this issue so far, and am suffering from the same problem.
Did you ever resolve this problem with your data analysis diamondjack?

Additionally to the jacked-up clock intervals, I am getting a bunch of "null" value (empty) cells if I log any channel above the GPS-limited 10 Hz. Does anyone have an explanation for the cause of this? I would like to analyze the data I collect outside of Race Analyzer, but am unable to do anything with it because of the empty cells and screwy clock.

Thanks,
Evan

[gizmodo]

I talked with Brent about something similar a while back. What I noticed is that over a 20 minute the time would drift by a few seconds. During that conversation I also asked for a time column that starts at 0 when the log starts and counts up from there. If I remember correctly he said he fixed the time drift problem and was going to add a new time column to v2 of the firmware.

[ehorner]

Well that sounds annoying. Was it drifting forward or backwards? I'm still trying to figure out the empty cells and inconsistent clock intervals before I can start looking for drift.

[gizmodo]

I don't remember which way it was drifting. I think the it was falling behind the video I was trying to overlay. As for the empty cell problem, I just set everything to log at 10hz hoping that would make things work a bit better, but I still have the same problem. I'm just going to wait for v2 of the firmware and hope for the best.

[ehorner]

Ok that makes sense. My output log files have been longer (in time) than what is recorded in Race Analyzer, which seems like we are having the same issue.
Logging everything at 10Hz seemed to solve the empty cell issue, and there was ~0.05s time "drift" (in a ~13 second test log) which is less than I've seen in my test logs with multiple frequencies, but the clock interval was inconsistent, and never 0.1 seconds.

We are not alone in this. I started working with Brent yesterday on trying to identify and solve this problem. He is aware of it, and will make sure that it doesn't exist in V2.

[gizmodo]

Yeah, Brent was really good about responding and had said he had a fix for this in v2 of the firmware, which is why I haven't really bothered to do more with it.

[brentp]

In the V2 firmware coming Real Soon Now we're planning on changing the time column to a decimal Unix epoch time with milliseconds. This should provide a clean incrementing numeric value.

The V2 sample rate timing has been dramatically improved with the V2 firmware as well.