Hey Mark and Frank,
I've copied this to the GEEZ list as well, hope you don't mind. And
forgive the rather large snips at places...
Mark Sirota wrote:
> I got some useful data out of the G-Cube this weekend, for the first
> time. Last weekend was the first time I tried it, and I had an odd
> problem, that I got lots of 22-second runs and lots of 200+ second
> runs... It seemed like the autostart mechanism wasn't working well.
> I did record a couple of runs last weekend by manual start and stop;
> I'll have to go back and work with those now that I know more about
> what I'm doing. I know Frank Adams has been suffering from the same
> problem (and I've copied him in on this message).
Frank's difficulties were related to an incorrect calibration, our
number 1 helpcall item, and one that we'll address in the software
shortly. But your calibration string was accurate, as we discussed on
the phone earlier.
>
> If you want this to count towards my two hours, let me know. I'm
> hoping I can use that time for some real coaching on how to read the
> runs, rather than how to use the software, but whatever seems fair.
> I don't suppose you'll have any time to give me at Topeka, will you?
> If so, that would be great... If not, then we'll work by e-mail and/or
> phone.
I'm pretty flexible, as long as I don't have to keep an actual stopwatch
running...let me know when you've gotten your money's worth!
> I have a couple of questions to ask you, primarily related to the GEEZ!
> software, and to the configuration of the autostart/autostop triggers on
> the Palm.<SNIP>
> How would you recommend that I configure my autostart parameters?
I suggest setting the Autostart threshhold pretty high, as long as you
know you'll hit it. For instance, I typically use 0.40 - 0.45 on my
Miata. For AutoStop, I set to 0.05g's for 3 seconds. This shorter cut
allows me to stop and count one-mississippi two-mississippi
three-mississippi in the stop box, and know that it's going to shut off.
From our phone call it became clear that you were attempting to have
the autostop kick in on the slow drive back to your grid spot. I think
this isn't going to work.
> I ask because during my long drive back, I show consistent acceleration
> of -0.04 or -0.05g's (that is, slight deceleration). That's still
> below my autostop threshhold of 0.08g's for four seconds, so I don't
> understand why it didn't stop by itself. In the case of the run I'm
> looking at now, this occured for 15 seconds.
Here's the problem. What you see in the final output is smoothed over 4
periods. But the AutoStop, for reasons having to do with the Palms
processing speed and capabilities, is checked against the raw,
unsmoothed data. At low speeds you will still have surface bumps and
other vibrations to deal with. So it's unlikely that you'll be able to
shut the system off with the vehicle moving. I've never been able to do
it. So I use the 3 second trigger so that I can sit still for a
relatively short amount of time and know I got it shut off.
Alternately, I suppose you could use a very high AutoStop Threshhold,
say 0.15 or so, but my fear would be that you might hit this on course
somewhere and lose part of the run.
In order to eliminate the short 22 second type runs, I like to set the
Minimum Run setting to whatever I think I'll run on course. If it's a
60 second course, I'll set minimum run to 60 seconds. This is okay
because you have 5 seconds in the AutoStart loop, and whatever you chose
for the AutoStop loop, in my case 3 more seconds. So if I run 60
seconds, I'll have a minimum run of 68 seconds. And to run so fast that
the 60 second run would be discarded I'd have to run 52 seconds...not
too likely if it's a 60 second course.
These strategies will help you to get the AutoStart and AutoStop working
well. If you can use AutoStart and AutoStop you'll be able to eliminate
the "fiddle factor" before and after runs, and you'll be more satisfied
with the product, I believe. I think it's one of the best things about
the system.
>
> Now, on to my software questions... I have a number of things that
> appear to be misbehaving. Given that all my runs have dozens of seconds
> of extra data on either end, I'm trying to "cut" that data out -- but
> it's very hard to be precise about my starting and stopping points. In
> particular, it's nearly impossible to start at the very first data point
> or finish at the very last one; it would seem that end-trimming like
> this would be popular, and so it would be helpful to make that easier.
There is a default setting for "Autotrim start", which shows up under
the Options button on the speedbar. This is a neat feature (most of the
time) but it's what's causing you grief. Because your AutoStart
Triggered too soon, then tried to keep the run, you have a falst start
which you are trying to trim off of the run. Autotrim start does just
that, it clips off the front of the run from the viewed data. But it
doesn't actually kill off the data at the start, it just doesn't display
it. When you try to trim the start of the run, this unviewed section
will not be accessible, and hence will reappear, probably a little bit
at a time, until you finally get it all. The solution is
simple...de-select the Autotrim start selection on the Options menu. Or
better yet, try getting better AutoStart threshholds as described above.
> Last, I frequently get this problem where I have multiple runs
> displayed, and I want to select one to change its colors or something,
> and all of a sudden it maximizes and I can't see the other ones. Is
> there some way to disable this frustrating behavior?
Is this from double clicking the title bar? That behavior is standard
Windows fare. I don't think there's a way to disable it. Of course
pressing F7, the shortcut for Windows|Tile will put everthing on screen
and in sight, or better yet, just press the "two box button" to restore
the window to it's previous mode.
> (It's also frustrating that the software doesn't understand filenames
> longer than eight characters... As a human factors engineer who's been
> in the software development world, if you'd like more feedback on making
> this more usable, I'd be happy to provide some -- but be prepared...)
This is of course a side-effect of us compiling the program as a 16 bit
application, which is done to try to maintain compatability with older
3.1 Windows computers. Because those that use laptops to record are
often using ancient old laptops (rather than putting their slick and
pricey new machines into the race car environment) we are perhaps a bit
hypersensitive about maintaining 3.1 compatibility. Heck, when I record
with a laptop, it's my old trusty (and rusty?) Toshiba 486-50 running
3.1.
But with that said, at some point we'll re-compile the whole thing into
Delphi 2+ (I think they are up to Delphi 5 now, but everything from
Delphi 2 on is 32 bit), and pick up the longfilenames at the same time.
--Byron
|