# GetCharTest **URL:** \ **Category:** Uncategorized\ **Created:** [June 1, 2002, 6:10pm UTC](https://psychtoolbox.discourse.group/t/getchartest/1029 "2002-06-01T18:10:49Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![denispelli](https://avatars.discourse-cdn.com/v4/letter/d/cdc98d/32.png) [@denispelli](https://psychtoolbox.discourse.group/u/denispelli)\ **Post date:** [June 1, 2002, 6:10pm UTC](https://psychtoolbox.discourse.group/t/getchartest/1029/1 "2002-06-01T18:10:49Z")
dear dan i enhanced your GetCharTest.m and polished GetChar.mex slightly. I think that it's now self explanatory. help getchartest now says this: GetCharTest evaluates the accuracy of the timing information returned by GetChar. GetChar returns two values: when.ticks and when.secs. when.ticks is passed on directly from the Mac OS. when.secs is an estimate, based on when.ticks, of what GetSecs would have returned. There are three issues that limit the accuracy of the timing: 1. The time, in ticks, of the keypress returned by the Mac OS is inaccurate, with errors of more than one tick. This may reflect coarse quantization of time in the the hardware interface to the keyboard. Different kinds of keyboard interface (built-in laptop keyboard, ADB, USB) may have different quantizations. 2. A tick is an integer, with a unit of 1/60.15 s. 3. The value of when.secs necessarily inherits all the inaccuracies of when.ticks, and has a further problem. If you know the rates of two clocks, it's easy to convert times from one kind of time to the other. We do that by estimating Tick0Secs, the value of GetSecs at the moment when GetTicks was zero. tick0Secs=GetSecs-GetTicks/60.15; We can then convert any value of ticks to secs by the formula: secs=ticks/60.15+tick0Secs; However, it turns out that the Mac OS tick counter often misses ticks when the computer is very busy. I.e. the ticks clock may be slow. Thus, the value of tick0Secs, which tracks the slippage, will keep changing. It's fine to measure it once and use it for a few minutes, but not for hours. It should be remeasured. GetCharTest begins by asking SCREEN to remeasure Tick0Secs. best denis p.s. i'm enclosing all the relevant new files: GetChar.mex, GetChar.m, GetCharTest.m, SCREEN.mex, ---
**Author:** ![denispelli](https://avatars.discourse-cdn.com/v4/letter/d/cdc98d/32.png) [@denispelli](https://psychtoolbox.discourse.group/u/denispelli)\ **Post date:** [June 4, 2002, 6:19am UTC](https://psychtoolbox.discourse.group/t/getchartest/1029/2 "2002-06-04T06:19:58Z")
dear dan thanks for the report on how it worked out. i prefer to do support strictly on the forum. as a lurker, i think it's always interesting to find out how well the proposed solution worked. incidentally i think it may be significant that you're using Mac OS 9.0 whereas i'm using 9.2.2. It used to be that GetSecs ran at a rate that was about 1% fast or slow (i've forgotten). i even wrote a routine (getsecstest) to compensate for it. but one of the more recent releases of the Mac OS has eliminated the error. if you run TimingTest, it will test all the clocks against each other. here's a printout for mac os 9.2.2: timingtest WaitSecs and GetSecs are based on the VideoToolbox Seconds.c, which uses the UpTime timebase (a counter in your PowerPC chip), if available. WaitTicks and CPUTIME are based on the Mac OS Time Manager. WaitTicks : GetSecs says it took 1.0001 of nominal. WaitSecs : GetSecs says it took 1.0001 of nominal. WaitTicks : cputime says it took 1.0000 of nominal. WaitSecs : cputime says it took 1.0001 of nominal. TimingTest is enclosed. (it's probably unchanged from the version you already have.) best denis > \>Dear Denis, > \> > \>Thank you very much for all your efforts this weekend. I certainly read your > \>posts, and I have been working with your GetCharTest.m and making > \>adjustment to > \>my own experimental program. > \> > \>The key to valid response times definitely seems to be including the line: > \>screen('Preference','Tick0Secs',nan); > \>before each stimulus/response period. I tried putting that line in > \>the program > \>just once at the top, but that resulted in inaccuracies that were > \>similar to the > \>ones I encountered before, but less severe. But the returned value of > \>when.ticks was always good. > \> > \>I know that it vague. I am still trying to understand and quantify that > \>when.secs error. But at least adding that SCREEN command before each > \>stimulus/response period seems to fix things. > \> > \>By the way, my machine is a PowerMac G3, OS 9.0, 333 MHz running > \>Matlab 5.2.1. > \>I don't suppose that might explain why I would have to reset Tick0Secs before > \>each stimulus/response period (each being just a few seconds) instead of > \>restting it just once per run (less than a minute total)? > \> > \>Finally, to address your question below, I would leave when.secs in GetChar. > \>It is a convenient convenience (for me at least) and you clearly inform the > \>user about the Tick0Secs issue in the current help for it. Caveat emptor, or > \>something like that. > \> > \>I will continue to look more closely at it all, the C-code for the MEX > \>as well. I'll let you know if I have any new ideas. Thanks again. > \> > \>- Dan > \> > \>P.S. Would you prefer that I posted this to the forum? I didn't > \>have anything > \>particulary new to add, just a little feedback to you, so I figured not this > \>time. > \> > \> > \>On Fri, 31 May 2002 22:18:15 -0400 Denis Pelli \<[denis.pelli@...](mailto:denis.pelli@...)\> wrote: > \> > \>\> i wouldn't have expected the time difference to be negative. it's > \>\> possible that my algorithm to do the conversion from ticks to secs > \>\> could be enhanced. > \>\> > \>\> i'm not sure what to do at this point. there isn't any extra > \>\> information in when.secs; it's merely a convenience. should i delete > \>\> it, to avoid confusing users? or should i leave it? > \>\> > \>\> i haven't tried to think through the implications of the integer > \>\> quantization of ticks. if you can suggest an improved formula for > \>\> conversion i'd be happy to use it to enhance GetChar.mex.