[CSDb] - User Forums - Accurately Measuring Drive RPM

Welcome to our latest new user Critikill ! (Registered 2024-09-19)

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: 11290

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-03 17:48

Zibri
Account closed

Registered: May 2020
Posts: 304

Another note:
it's totally useless to use both VIA timers.
Considering the speed range of VICE, the difference between 275 RPM and 325 is 33566.4 cycles which is fine because it's smaller than the 65536 cycles the timer can give us.
Obviously the timer will underflow 3 times.. but we don't care because we already know the range.
Believe me there is no better way to determine the rpm than my program does.
For sure you could have a "sort of" accurate result in other ways but you will need more rounds and mathematical averaging. This is the fastest direct way to get it.

2020-08-03 17:50

Krill

Registered: Apr 2002
Posts: 2940

Quoting Zibri

Note, don't put in vice repository a "derived" test (i.e. copied). Just put my program.

Pretty sure they'll add an unmodified version if you make it VICE test suite compliant (so it can be run in batch mode, without manual intervention).

They did with skew1.prg provided by me (https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/dri..) which also measures RPM, but only as a bonus.

2020-08-03 17:51

Krill

Registered: Apr 2002
Posts: 2940

Quoting Zibri

Another note:
it's totally useless to use both VIA timers.
Considering the speed range of VICE, the difference between 275 RPM and 325 is 33566.4 cycles which is fine because it's smaller than the 65536 cycles the timer can give us.

The point is that 2 timers can give accurate measurements of at least 30 bits, even without hardware cascading.
A revolution takes 200,000 cycles plus/minus tolerance, so you could measure that time pretty much directly.

2020-08-03 18:36

chatGPZ

Registered: Dec 2001
Posts: 11290

The question still is: by doing that, do we gain accurracy over the free running timer? Like Zibri said, we know already we will measure something close to 200000 cycles, and we dont have to be able to measure arbitrary times.

And yes, i'd prefer a simple small non interactive test program, similar to the existing ones :)

2020-08-03 18:44

Krill

Registered: Apr 2002
Posts: 2940

Quoting Groepaz

The question still is: by doing that, do we gain accurracy over the free running timer? Like Zibri said, we know already we will measure something close to 200000 cycles, and we dont have to be able to measure arbitrary times.

Granted, possibly no gain by extending the range. But there may be something with, e.g., using an additional timer with a period co-prime to the main free-running timer (maybe also pretty small, like 3 cycles). Could maybe be used to increase accuracy and counter the polling loop's jitter.

Or a second timer with exactly the polling loop's period... mh. :)

2020-08-03 18:49

Copyfault

Registered: Dec 2001
Posts: 468

Never thought this would become *that* mathmatical ;)

Well, reading the word "Chinese remainder theorem" triggered me, so if we set the two VIAs to different (and coprime) timer values and trigger different irqs, we could implement the chinese remainder theorem 1:1.

But the approach with the differences is even better. While the Chin.remainder theorem states a certain "equality" between different modulo-class-rings, one can proof in a more or less direct way that, given M<N

Z_M  X  Z_N  ->  Z_N; (m, n) |-> n-m

is surjective with kernel isomorphic* to Z_M (the "smaller one").

Putting this straight (and less algebraic;)) this means that the difference (in Z_N, mind!) gives a measure of the relative positions of the numbers in Z_N and Z_M. Aplplying this to continously running timers, it exactly gives the no. of underflows modulo M.

At certain points the difference can result in a negative value; but since we're in modulo-class-rings, there's always a non-negative representative: in Z_N, this means n-m = N+n-m in case of n-m<0.

So the widest range should be achieved by setting one VIA timer to $ffff (as far as I understand timers, this effectively means 65536=$10000 cycles since it underflows after reaching 0) and the other to $fffe. Since the larger value is $ffff, we have N=65536 in the algebraic sense and the modulo is given automagically by the way the binary system works ;)

Really nice! Never thought that such "algebraic nonsense" *does* occur in practice. Makes me happy :)

*) "isomorphic" is usually used in mathmatics when certain abstract construction and maps between them are considered. It extends the idea of "being equal" to these concepts. Here we "only" take a closer look at modulo-class-rings, so it's ok to think of "numbers are equal modulo a certain number" here.

2020-08-03 19:27

Zibri
Account closed

Registered: May 2020
Posts: 304

As already stated in my program instructions, all you have to do is:

"U30"+chr$(tracknumber) (I suggest track 36 but any can be chosen) crates the test track.

"U31" times the "actual track" (so run in a loop after U30 can give you a result every revolution).

The result is on channel #15 and it's a "0" followed by 2 bytes which are the ramainder timer in little endian.

Then to get rpm all you have to do is:

RPM = 6000000000/(196603-Timer)

P.S.
The drive code is the last block of my program.

By doing
LOAD"rpm",8

even without running it the code is already loaded and ready in the drive :D

and you can, for example create the test track by just issuing:
open,15,8,15,"U30"+chr$(36)
get #15, a$,a$,b$
close15
The timer will be: TT=chr$(a$+chr$(0))+chr$(b$+chr$(0))*256
RPM will be as the formula above.

Remember to add 0.5 before doing INT in basic or you'll get a wrong result.

Later today I will post an example in basic that just gives a one shot result if you want.

2020-08-03 20:05

chatGPZ

Registered: Dec 2001
Posts: 11290

I figured out how to do it before, see my comment in the release :) I'd still prefer a simple self contained test program for the testbench :)

PS: this thread is about the accuracy of the mentioned methods and how to determine/proove it

2020-08-03 22:25

Zibri
Account closed

Registered: May 2020
Posts: 304

Quote: I figured out how to do it before, see my comment in the release :) I'd still prefer a simple self contained test program for the testbench :)

PS: this thread is about the accuracy of the mentioned methods and how to determine/proove it

proof: set VICE to 275.00 then increment to .01 .02 .03 up until 325.00.

My program: accurate.
Every other program: not accurate.

Period.

I told you how my program works, that should be enough to prove the accuracy. 2/200000 is it's accuracy.

At speeds lower than 300 obviously the accuracy will be always 2/LONGERTIME but at speeds higher it will be lower accuracy.

In both cases even at the extreme edges the accuracy is more than anough to always get 2 decimal digits.

It's also interesting when you test "direct drive" drives with my program (the ones without the elastic belt).
There you will see a 0.01 wobbling or even none at all. Depending on how "stiff" is the diskette you tested it on.

About self contained program, just tell me what you need and I can code it easily. Basic program with single output? Multiple?

The real "program" I coded is the one inside the drive which allows:

1) The most accurate reading of rotation speed.
2) A new (customizable) routine do align to track 42.
3) A way to change track using DOS but in an agnostic way (not even needing a disk inside) which nobody did so far.

About (3), everyone until now coded a routine to physically address $1c00 lower bits to move the step motor. That's fine if done correctly, but I liked more "the commodore way", so I studied it and implemented it.

As I already said, for me this was just a mental gymnastic exercise, I learned a lot and implemented what I learned.

2020-08-03 22:33

Zibri
Account closed

Registered: May 2020
Posts: 304

In a nutshell:

30 open 15,8,15,"u30"+chr$(36)
40 get #15,a$,a$,b$
50 tt=asc(a$+chr$(0))+256*asc(b$+chr$(0))
60 if tt > 32767 then tt = tt-65536
70 t=3*65536-tt-5
80 rpm=int(0.5+6000000000/t)/100
90 print "rpm="rpm
100 close15

for a single reading.
for multiple (and fast) ones:
just do a print#15,"U31" and then the same code from line 40 to line 90 in a loop.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 28 - Next

Refresh

Subscribe 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

Sentinel/Excess/TREX
iceout/Avatar/HF
csabanw
Drees
Guests online: 78

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 Comaland 100%  (9.6)
8 Wonderland XIV  (9.6)
9 No Bounds  (9.6)
10 Unboxed  (9.6)

Top onefile Demos

1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Rainbow Connection  (9.5)
6 It's More Fun to Com..  (9.5)
7 Morph  (9.5)
8 Dawnfall V1.1  (9.5)
9 Onscreen 5k  (9.5)
10 Daah, Those Acid Pil..  (9.5)

Top Groups

1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Nostalgia  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.2)

Top Original Suppliers

1 Derbyshire Ram  (9.7)
2 Fungus  (9.3)
3 Black Beard  (9.2)
4 Baracuda  (9.2)
5 hedning  (9.2)

Page generated in: 0.135 sec.