Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Accurately Measuring Drive RPM
2020-08-03 16:07
chatGPZ

Registered: Dec 2001
Posts: 11108
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....
 
2020-08-11 17:15
tlr

Registered: Sep 2003
Posts: 1714
Quote: The deviation can be expected to increase after running a stress test for a while, no? Especially on a 1541 with that built-in PSU.

Maybe, although it seems to be running quite hot at all times really. If it gets hotter, I guess it would pass the 0-line further down.
2020-08-11 17:29
Flavioweb

Registered: Nov 2011
Posts: 447
Just searching the net, i found this jpg:
http://www.bertinettobartolomeodavide.it/programmazione/commodo..

where we can see that quartz is a "Toyocom TCO-/745A" of which i can found this:

https://www.datasheetarchive.com/pdf/download.php?id=caa472aa5e..

in which is stated that "Frequence stability" is from "-50" to "50" ppm.

I don't know if/how this can be useful, but that is.
2020-08-11 17:33
Zibri
Account closed

Registered: May 2020
Posts: 304
Quoting Krill
The deviation can be expected to increase after running a stress test for a while, no? Especially on a 1541 with that built-in PSU.

It has been observed in some drives but I think it's because of the old capacitors. If speed increases after 2-3 minutes running my programs it means is time to recap :D
2020-08-11 17:36
tlr

Registered: Sep 2003
Posts: 1714
Quoting Flavioweb
Just searching the net, i found this jpg:
http://www.bertinettobartolomeodavide.it/programmazione/commodo..

where we can see that quartz is a "Toyocom TCO-/745A" of which i can found this:

https://www.datasheetarchive.com/pdf/download.php?id=caa472aa5e..

in which is stated that "Frequence stability" is from "-50" to "50" ppm.

I don't know if/how this can be useful, but that is.

That's a good find, and an interesting data point! So at least some drives have +/- 50ppm (the oscillator was produced in 84 in this case). Tighter tolerance than I would have expected. I wonder if I'm likewise mistaken on the accuracy of crystals used in the c64 and older drives?
2020-08-11 17:42
Zibri
Account closed

Registered: May 2020
Posts: 304
Quoting tlr
Quoting Zibri
They will _not_ sweep around randomly within that interval, hence the _precision_ is much better.
The important point is that these are two completely different aspects of the crystal's behaviour.

From what I read, the frequency "sweep" is dependent also from the ambient temperature.
Anyway I think is not as big as the deviation in speed caused by old capacitors.
I saw some drives starting at 298 and slowly go up to 302 rpm as they get hotter.
That's also why I wrote my program as I wrote it:
it's very easy to assess the drive health just but letting it run for a few minutes.
You can see differences even from a disk to another due to friction.
If you have any suggestions for improvement, I would be glad to hear them.
I think my next program will be about checking the head alignment in a new way but I need to wait for DHL to pack the material and send it to me:
A C64, a boxed 1541 21 sealed disks and a C64 SX (just for fun since it will soon be my birthday) :)
2020-08-11 17:55
tlr

Registered: Sep 2003
Posts: 1714
Quoting Zibri
Quoting tlr
Quoting Zibri
They will _not_ sweep around randomly within that interval, hence the _precision_ is much better.
The important point is that these are two completely different aspects of the crystal's behaviour.

From what I read, the frequency "sweep" is dependent also from the ambient temperature.
Anyway I think is not as big as the deviation in speed caused by old capacitors.
I saw some drives starting at 298 and slowly go up to 302 rpm as they get hotter.

Yes, frequency will change with temperature. It will also change a little with voltage, though the speed change you see with presumed bad caps is probably caused by an actual change in motor speed (voltage to motor controller fluctuating).
These oscillator cans (as opposed to discrete crystals) can in some cases have temperature compensation in them, although then more expensive.
Quoting Zibri
A C64, a boxed 1541 21 sealed disks and a C64 SX (just for fun since it will soon be my birthday) :)

Getting new hardware is always nice!
2020-08-11 18:11
tlr

Registered: Sep 2003
Posts: 1714
Quoting tlr
Quoting Flavioweb
Just searching the net, i found this jpg:
http://www.bertinettobartolomeodavide.it/programmazione/commodo..

where we can see that quartz is a "Toyocom TCO-/745A" of which i can found this:

https://www.datasheetarchive.com/pdf/download.php?id=caa472aa5e..

in which is stated that "Frequence stability" is from "-50" to "50" ppm.

I don't know if/how this can be useful, but that is.

That's a good find, and an interesting data point! So at least some drives have +/- 50ppm (the oscillator was produced in 84 in this case). Tighter tolerance than I would have expected. I wonder if I'm likewise mistaken on the accuracy of crystals used in the c64 and older drives?

1541 board (hackaday.io)
This oscillator is similar to the one I have on my older (white) 1541 drive. Anyone have a guess on which manufacturer?

EDIT: KSS seems to be a Japanese manufacturer
2020-08-11 18:29
chatGPZ

Registered: Dec 2001
Posts: 11108
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.
2020-08-11 18:34
Oswald

Registered: Apr 2002
Posts: 5017
https://play.google.com/store/apps/details?id=com.javiery.rpmga..
2020-08-11 18:36
chatGPZ

Registered: Dec 2001
Posts: 11108
Quote: https://play.google.com/store/apps/details?id=com.javiery.rpmga..

The comments remind me of this thread :o)
Previous - 1 | ... | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 94
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 MWS  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.075 sec.