| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
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: histogram would tell quite nicely how bad the "wobble" is... less than trivial to implement unfortunately :)
I think plotting instantaneous vs running average (5 laps maybe) in the same graph would do. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
probably... not quite as nice, but sure... :) also a simple scrolling scatter plot like recorder justage does seems interesting enough. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting ChristopherJamQuoting ZibriAny accuracy below the 2 digits is not enough to assess the status of the belt or mechanics and disk.
I'm curious about this claim. I've been assuming that loaders need to be tolerant of anything from 295 to 305 RPM, in which case even 1 digit is somewhat overkill.
Have I been wrong all this time, in which case surely it would be safe to relax the GCR restrictions to allow runs of three zeros instead of just two? :)
You are not wrong at all. I even wrote it in the instructions.
A drive works even when set to 290 RPM! |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Quoting Zibri
You are not wrong at all. I even wrote it in the instructions.
A drive works even when set to 290 RPM!
So... why do you need to know the nearest 0.01RPM if the "safe zone" is 2000 times as wide as that? /puzzled |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting tlr
...thus to achieve the desired accuracy a better reference oscillator is required.
(with reservations for eventual miscalculations)
Yes, sorry, my bad, for me accuracy and precision were synonyms.
About your calculations, I don't know if they are right or wrong, but empyrically I don't see such deviations when measuring drives with no belt (motor is spinning the disk directly).
In that particular case I see a variation of 0.01 which is probably because of the diskette "stiffness". Different diskettes give different results. |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting Commodore service manual
TEST OVERVIEW
The Soft Error Test writes a worst case pattern to the diskette and then reads for the specified number
of passes. The number of sectors tested is fixed at 16 per track with all 35 tracks tested.
The program keeps a log on the diskette of the number of passes and errors which occur during program run time.
The drive speed is measured by writing a sync mark on a track which is outside the normal range
of the system and measuring the time (to 100 micro-second accuracy) the period of each revolution.
Belt quality is measured during the speed program by comparing two (2) successive revolutions of
the diskette. This comparison is repeated twenty (20) times and the results are displayed.
• If a failure occurs during this test, the drive belt should be either replaced or reversed.
LOL!
I found this by pure chance.
Apparently commdore used a similar method I used.
They wrote a reference track "outside the normal range" like my program does.
The only difference is that they used a SYNC mark which gave their program less accuracy than mine.
That's all.
Ok now you can also blame commodore along with me. :D
http://www.zimmers.net/anonftp/pub/cbm/schematics/drives/new/15.. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting ZibriQuoting Commodore service manual
TEST OVERVIEW
The Soft Error Test writes a worst case pattern to the diskette and then reads for the specified number
of passes. The number of sectors tested is fixed at 16 per track with all 35 tracks tested.
The program keeps a log on the diskette of the number of passes and errors which occur during program run time.
The drive speed is measured by writing a sync mark on a track which is outside the normal range
of the system and measuring the time (to 100 micro-second accuracy) the period of each revolution.
Belt quality is measured during the speed program by comparing two (2) successive revolutions of
the diskette. This comparison is repeated twenty (20) times and the results are displayed.
• If a failure occurs during this test, the drive belt should be either replaced or reversed.
LOL!
I found this by pure chance.
Apparently commdore used a similar method I used.
They wrote a reference track "outside the normal range" like my program does.
The only difference is that they used a SYNC mark which gave their program less accuracy than mine.
That's all.
Ok now you can also blame commodore along with me. :D
Maybe it asks before writing though, but yeah kind of funny. One of the earlier test programs I saw did something similar. I think it was SuperCopy 64. IIRC it gives readings that are really off when run in vice. Same for PAL and NTSC, not sure why. Haven't tested on hardware.
I tried a bit to find a specification on the rotational speed but couldn't find it. The service manual just says 300 rpm, and gives no tolerance. I would have guessed +/- 1 rpm or something like that. Maybe it's specified for the actual drive mechanics? The motor controller is part of that. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11379 |
You can find it in some datasheets for (shugart) drive mechanics (and then its usually +/- 1%). For the drives used in CBM drives i have not seen any datasheets, but its probably very similar. |
| |
Krill
Registered: Apr 2002
Posts: 2971 |
Quoting ZibriQuoting Commodore service manualThe drive speed is measured by writing a sync mark on a track which is outside the normal range
of the system and measuring the time (to 100 micro-second accuracy) the period of each revolution. The only difference is that they used a SYNC mark which gave their program less accuracy than mine. Pretty sure the 100 cycles of accuracy don't come chiefly from using a SYNC mark (7 cycles poll loop) vs BVC * (3 cycles poll loop) but more significantly from the discussed oscillator tolerance. |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quoting GroepazYou can find it in some datasheets for (shugart) drive mechanics (and then its usually +/- 1%). For the drives used in CBM drives i have not seen any datasheets, but its probably very similar.
297-303 rpm sounds a lot, but maybe that's the case. I've only seen the speed of a few drives, but I think they've all been tighter than that. Not that that would mean it's wrong of course. :) If they were calibrated using the strobe pattern it could be tighter. |
| Previous - 1 | ... | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 - Next |
