Request for enhangement: Presampling

[PencilGeek]

Here's something I've always found annoying about my VVBox. When it's in inertial start mode, the first sample is always a non-zero velocity. This is especially annoying when trying to analyze the files to find a 0-60 time, 0-100, etc -- since no 0-MPH record exists. So I've always added my own 0-MPH record so vBox Tools will be happy.

Why can't you pre-sample, or at least put a 0'th entry into the file? Or if it is possible, please tell me how to enable it. And if it's not possible, please add this feature.

Along the same lines, which is more accurate for launching from 0-MPH?
1. Free running (pre-running)
2. Inertial launch?

It seems that free running could hit the launch anywhere between 0.00 - 0.099 seconds; so the results could be as much as 0.099 second off. So what is the latency on inertial launch? I'd hate to miss as much as 0.033 seconds, or even 0.05 seconds. So which is preferred, and what is the latency of inertial launch?

[Newland46]

The 'only when moving' logging condition is in place primarily for customers on track events who want to only capture their track activity, and not all time in the pits. The minimum speed configuration is then in place to prevent the Video VBOX starting logging when receiving multipath reflections (causing speed jumps) when in the pits. So, the delay your box will have is dependant on how you have this set. By default this is 2.5km/h.

If you are performing 'sero to sixties' or any such test, then 'only when moving' would not be a recommended log setting. You should either log continuous or start the logging manually using a start/stop logging switch or the front panel button.

In a '0-60', '0-100' or any '0 to' test, starting from zero is configured from 0.5km/h in VBOX Tools to remove the affects of GPS speed noise.

Whilst this rules out the occurance of false starts (as long as not in poor satellite conditions), it also does not have a significant effect on the results.

Take a vehicle that can pull 1G from stationary, it will take 0.014s to get to 0.5km/h. Taking in to account your unit (assuming not a 20Hz VVB Pro) will be capturing data every 0.1s, then this value is even less significant.

Regarding the latency of intertial launch; assuming you use the 2.5km/h default then using our theoretical 1G from stationary, it will only take 0.07s to reach this speed. However this is still seven times the amount of time as when using 'continuous' logging, hence why is 'only when moving' is not recommended for such tests.

[PencilGeek]

Thanks for explaining the GPS noise problem; that definitely makes sense. But the original question remains: why not presample?

A missing 0'th sample in a vbox file isn't a good thing; and manually editing the vBox file to add it raises questions of tampering (for performance web sites that requre vbox file authentication).

So let's boil this down to the simple question: Is there a way to get the 0'th sample in the file without running in continuous mode?

[Newland46]

I presume we dont pre-sample 'log only when moving' so that data captured is always true to what is being measured. To create true representable data to pre-sample would require the unit to store past data in its buffer for a determined amount of time. The problems would then arise with the buffer filling up quickly due to the video.

I do completely see where you are coming from, and your thought is interesting so I will pose this question to the development team to see if they have any suggestions how best to complete this task.

So cutting to the chase, in direct answer to your question; No, there is no way currently to get the 0th sample in the file without running continuous.

[PencilGeek]

You're already plugged in and powered up; just waiting for an accelerometer event to start data logging. You could do something as simple as a 2-frame buffer for two vBox samples, and two video samples, then have a software flip-flop that points to one of the two buffer locations. When you get the accel event, you first store the current buffer and then go from there.

This would only work if memory is powered up while you're waiting for the accel event to kick things off. If memory is on, then it's probably a pretty straight-forward firmware change. But then again, everybody who doesn't know your HW design is an instant expert in how it works.

[Newland46]

Unfortunately it is not quite as straight forward as that, as the change would involve a complete rewrite of the 'only when moving' code rather than a simple ammendment.

After catching up with the guys in development, such behaviour of the 'only when moving' condition was discussed in the past. However it was decided due to resource reasons, taking in to account available memory and bandwidth to employ a seperate rolling buffer for both the video sync and avi header and index, the lack of demand for the ammendment meant it was unpractical.

For example, if you designated to buffer two VBOX samples (0.2s), this would contain 5 video samples (video @25Hz). Using a standard PAL scene (720x576) as there are 32 bit's per pixel the buffer would need to handle 8.2MB of just video data, ignoring any sync, indexing, audio, CAN or GPS information.

So ultimately customers are either encouraged to use 'continuous' logging when doing performance tests from zero, or use a considerable stop log delay in their scene setup, so that the logging will not stop immediately after becoming stationary (this is something racing customers use for when there are expected to be static for a dictated amount of time on a grid).

Hope this info clears things up a little.

Newland#46