| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
Accurately Measuring Drive RPM
To bring the discussion from 1541 Speed Test into the forum....
first lets recapitulate:
The general idea is: have a "marker" on a track, then measure the time for one revolution using timers. Generally there are different ways to achieve this:
- wait for the marker and toggle a IEC line. the C64 measures the time using CIA timer. this is what eg the well known "Kwik Load" copy does, the problem is that it is PAL/NTSC specific, and it can never be 100% exact due to the timing drift between drive and C64.
- wait for the marker and measure the time using VIA timers on the drive. the problem with this is that VIA timers are only 16bit and can not be cascaded, so you either have to measure smaller portions at a time, or rely on the wraparound and the value being in certain bounds at the time you read it.
now, to make either way slightly more accurate, a special kind of reference track can be used. typically this track will contain nothing except one marker - which makes the code a bit simpler and straightforward. this is what 1541 Speed Test does. the DOS also does something similar when formatting, to calculate the gaps. This obviosly has the problem that we are overwriting said track.
Now - the question isn't how to do all this, that's a solved problem. The question is, given a specific implementation, how *accurate* is it actually, and why?
The basic math to calculate the RPM is this:
expected ideal:
300 rounds per minute
= 5 rounds per second
= 200 milliseconds per round
at 1MHz (0,001 milliseconds per clock)
= 200000 cycles per round
to calculate RPM from cycles per round:
RPM = (200000 * 300) / cycles
two little test programs are here: https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri.. ... the first reads timer values between each sector header and then the total time for a revolution is accumulated from the delta times. the second leaves the timer running for one revolution and then indirectly gets the time for a revolution from that. to my own surprise, both appear to be accurate down to 3 cycles (in theory the second one should be more accurate, at least thats what i thought. i also expected some more jitter than just 3 cycles)
1541 Speed Test writes a track that contains one long sync, and then 5 regular bytes which serve as the marker. it then reads 6 bytes and measures the time that takes, which equals one revolution. somehow this produces a stable value without any jitter, which was a bit surprising to me too (i expected at least one cycle jitter, due to the sync waiting loops) (i am waiting for the source release and will put a derived test into the vice repo too)
So, again, the question is... how accurate are those and why? (a stable value alone does not tell its accurate). Some details are not quite clear to me, eg if we are writing a reference track, how much will that affect the accuracy of the following measurement? how will the result change when the reference track was written at a different speed than when doing the measuring? Will using a certain speedzone make it more or less accurate?
Bonus question: can we use https://en.wikipedia.org/wiki/Chinese_remainder_theorem with two VIA timers to make this more accurate? or is it a pointless exercise? |
|
... 263 posts hidden. Click here to view all posts....
|
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: So, assuming 50ppm, the oscillator deviation can be taken as +/- 10 cycles per revolution, or ~ +/- 0.015 RPM, ie ~6 times as much as the supposed 3 cycles jitter of the measurement on the drive.
yes.
Also, that diagram by Unseen shows quite a lot of dynamic frequency change (90 Hz). That is roughly 40-50 ppm to one direction. Isn't that quite much if the actual accuracy of the oscillator measured is +/- 50 ppm? Could be that most of the +/- 50 ppm is to account for just that though, I'm not sure.
And, those 100us stated for the measurement program in the service manual indicates much less accuracy. It could be that a wider tolerance was allowed (and used in some batches), or it could just be a left over from the late 70's PET drives.
Many questions...
Finding data sheets for a few more oscillators and crystals used would help. I find the crystals trickiest. Often they just say NHK and a frequency. How do you know which type? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: So, assuming 50ppm, the oscillator deviation can be taken as +/- 10 cycles per revolution, or ~ +/- 0.015 RPM, ie ~6 times as much as the supposed 3 cycles jitter of the measurement on the drive.
In the wrost case.
But i guess, in most cases, fully operational, we should be below 0,01 rpm.
Maybe more than three cycles. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
You always have to consider the worst case, thats precisely(!) what defines the accurracy(!) |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: You always have to consider the worst case, thats precisely(!) what defines the accurracy(!)
Technically speaking, you are absolutely right.
I have practically never checked the rpm at 0 or + 70c.
(Just kidding... huh ... =)) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
see Unseens diagram - you can see that devation at normal operation over time
Quote:Also, that diagram by Unseen shows quite a lot of dynamic frequency change (90 Hz). That is roughly 40-50 ppm to one direction. Isn't that quite much if the actual accuracy of the oscillator measured is +/- 50 ppm? Could be that most of the +/- 50 ppm is to account for just that though, I'm not sure.
Well, of course it is, its the max. deviation guaranteed under all conditions (within the limits defined in the datasheet). That includes drift over time and temperature, of course. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Technically speaking, you are absolutely right.
I have practically never checked the rpm at 0 or + 70c.
(Just kidding... huh ... =))
Bring out your temp chambers! :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11377 |
As if the heat wouldnt be bad enough right now >_< |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
So?
Did anyone try the new version?
https://github.com/Zibri/C64-1541-Speed-Test/blob/master/rpm4.p..
I would like some feedback.
Personally I prefer the "official" one, but this should work as well.
The only drawback of this version is that it may not give results if the speed is too low or too high, but this has still to be tested.
In this version is also possible to disable/enable the reference track writing. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting ZibriIn this version is also possible to disable/enable the reference track writing.
Yay! Amazing it only took 251 posts :) |
| |
Joe
Registered: Apr 2002
Posts: 227 |
Lol, this is called trolling perhaps. But out of curiousity, what will you all guys do now when you found out measuring this and that from a drive named this and that on that and that revision of a computer. à quoi ça sert? |
| Previous - 1 | ... | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 - Next |
