Frame Lock Working!

[Andrew Davie]

Frame lock is working! Not very well, but it IS working. I have just one hole on my disc, and I just got the PID working to synch to the hole position - it's terribly tuned and takes minutes to settle. But when it does settle it does so at the same spot every time, and demonstrates reliable 100% consistent frame lock. I just need to get that PID tuned and see how well it works then. But as I said, it's working.

What I ended up doing is keeping two values - one is the current video playback file pointer (essentially a sample # currently being played) which is incremented by whatever the sample size is, at the sample rate (e.g., 2 bytes at 22050Hz). When the IR interrupt comes along, I grab this current play position to let me know what's being displayed NOW. I also have a "what the disc is displaying" counter - that's incremented by a whole frame's amount every time the IR interrupt comes along (i.e., when the synch hole is detected). I increment it by "one frame" of values (e.g., signal frequency / 12.5 (frames/sec) * sample rate). So it says "after the first rotation, the current playback counter should be X if I'm spinning at the right rate. Of course after the first rotation it's WAY behind. This delta (expected playback counter vs actual playback counter) is used as the PID "current" value - it's a delta (or error, if you like). When the delta is 0, the disc is spot-on the correct pixel. When it's negative, the disc is too slow, and positive too fast. However, when the televisor starts the disc is slow to get up to speed, so the IR counter is getting WAY behind - so the disc eventually spins very fast to "catch up" to the correct position. Then it overshoots and spends a lot of time slowing down. The oscillation takes a while but eventually it settles on exactly the right scanline position and is consistent both horizontally and vertically.


youtu.be/4jxZTNUmht8

I'm not sure about the slight jerkiness, but I suspect a contributor is the gearing of the motor to disc; I only need PWM duty of about 40/255 to keep on-speed, and that means that the alternates are 41/255 or 39/255 - not a terribly subtle jump. I could/should change the relative size of the gears so that the motor is spinning faster to keep the disc on-speed, and this will give much more finesse in the PWM control. Also, I have my dodgy 3d-printed pulley, and the probably unsuitable rubber ring I'm using to drive (I'm using an o-ring). I might get myself a toothed band and some appropriate toothed pulleys to really "lock" the motor and disc together.

[Andrew Davie]

I've just been looking through the source code of the PID library and have found out that it uses the 'millis()' time function. This is no longer valid to use, as I have appropriated the timer that the base system uses for time-based functions. Also, I'm not exactly sure if the PID expects to be called at a fairly constant frequency itself; for me it's got to be at the frequency of the disc spinning. So, there's a few things to consider there. I may end up modifying the library somewhat. These issues might explain some of the difficulty I have had tuning the beast.

[Klaas Robers]

Andrew, why do I see a sync-jump at the place where the scanning goes from line 31 to line 0? I would expect a sync bar that is straight, not a step of the height of the bar, which is now visible. It looks as if this is a problem in your video file, or a play-back problem.

And then the jerkyness, also that could be a play-back problem in your time base corrector.

Now that your time to get a stable synchronisation is this long, you should see that the disc is synchronised to an internal clock in the Arduino, and that the video files are also read / displayed locked to this internal clock. Then the time consuming synchronistion is needed only once: after switching on.

A good stabilisation point for your PWM value is 128. Then there is equal "headroom" above as below.

[Harry Dalek]

Good work Andrew just using the frame for locking was something i was wondering about in the past as well so interesting seeing it at work ....
Working but slowly was a problem that put me off a bit trying it but as you say work it does.
On the pulley side of things this is something i have tested a bit with and i found the tension is sort of critical so i put my little motor on an arm so i could adjust this and then lock it in place when it was correct.
Another idea i wonder if you could use the line and frame to lock the picture 33 holes the 33rd at some other position ...or perhaps half line 64 holes you would think the more you have the quicker more accurate the lock becomes so on ?

[Andrew Davie]

Good work Andrew just using the frame from locking was something i was wondering about in the past as well so interesting seeing it at work ....
Working but slowly was a problem that put me off a bit trying it but as you say work it does.
On the pulley side of things this is something i have tested a bit with and i found the tension is sort of critical so i put my little motor on an arm so i could adjust this and then lock it in place when it was correct.
Another idea i wonder if you could use the line and frame to lock the picture 33 holes the 33rd at some other position ...or perhaps half line 64 holes you would think the more you have the quicker more accurate the lock becomes so on ?

Early days yet! I believe I can get the PID working for a rapid frame lock with a single hole. That was the whole point of this build (to start with, anyway). Now I need to play with PIDs and really understand the characteristics of the motor/disc and how to get a reliable and quick lock. In my mind it's easy - accellerate until you're at the right speed, then run a little faster or slower while the lines shift horizontally to correct 'phase' and then go back up to speed and hold. This is what I do when I manually lock the frame anyway; I don't see why an algorithm can't do it faster.

As to the motor position - yes, good idea. I have considered some sort of mount that can be adjusted. I think I'll design and print a 3D one.

[Andrew Davie]

Andrew, why do I see a sync-jump at the place where the scanning goes from line 31 to line 0? I would expect a sync bar that is straight, not a step of the height of the bar, which is now visible. It looks as if this is a problem in your video file, or a play-back problem.

Eagle eyes! Yes, this is/was a playback problem that I think I have already fixed. When the infrared comparator interrupt (IR) occurs, then the PID calculations are done. Figuring the delta error, etc. This takes a few lines of code, but during that time no other interrupts could happen. Given that there's a main interrupt handling the playback (in this case at 22050Hz) then that has to wait, so you see a discontinuity in the visuals. I think that's what it was, as it seems not to be there anymore, now that I re-enable interrupts as early as I possibly can in the IR. My last few videos don't have this jump; I'll come back to it if it's something different.

And then the jerkyness, also that could be a play-back problem in your time base corrector.

Possibly, but it's low frequency and I just don't know what that is at the moment. I think this is the large difference between PWM duty cycle values when it decides it needs to go faster or slower. Currently duty cycle hovers around 40, so + or -1 is a reasonably big difference and visible to the eye.
This is a good reason to have the motor spinning as fast as possible. See notes below on (X+1) etc...

Now that your time to get a stable synchronisation is this long, you should see that the disc is synchronised to an internal clock in the Arduino, and that the video files are also read / displayed locked to this internal clock. Then the time consuming synchronistion is needed only once: after switching on.

This is only the very first pass - let me spend some time getting a properly working version with the current approach. The disc IS synchronised to an internal clock, because it is tied to the video signal which is tied to an interrupt (at the playback frequency) which of course is triggered by the internal clock. So the video signal at least is definitely locked to correct speed, and consequently the disc is too, in an indirect way. I don't really understand what you are suggesting - the motor is driven by PWM duty cycle value which is increased/decreased based on the PID. Synchronisation code is actually pretty small/fast, relatively speaking so it's not that time consuming.

A good stabilisation point for your PWM value is 128. Then there is equal "headroom" above as below.

I understand this suggestion, but I don't think this is the best way. What I think I want is minimal difference between motor speed for duty cycle (X-1) and (X) and (X+1) so that as the disc is basically at the right speed, give or take, the PID is making small adjustments and these result in choosing one of those duty cycles which of course result in minimal changes. It seems to me I should gear the motor/disc so that the motor has to spin quite fast to keep the disc at speed (say, 80% capacity so we have some reserve to spin up quickly for the initial bit).

One other thing - the delta value I calculate is in terms of disc rotations. So, -1 means the disc is one whole revolution slow. +2 means it's two revolutions fast. And of course the fractions mean what you would expect. The PID currently tries to get this to zero, which means that the timing of the expected signal and the actual time of the signal are the same. I can, in future, adjust this calculated delta to give me a vertical adjust - I should be able to easily shift the frame up or down (by, say, a half frame if I want) just by changing the delta and (conceptually) shifting where the synch hole on the disc is with software.

[Klaas Robers]

I doubt that the IR interrupt is the problem. That always occurs when the hole 31 is followed by the hole 0, so at a fixed moment in the rotation of the disc. I saw this jump in the sync bar moving horizontally, fixed to the 31-0 change in the video signal.

Any way, for me it looks a better idea to have a continuous interrupt in the Arduino each 80 msec (12.5 Hz), and synchronise the disc to that events as a separate process, and synchronise the video too to that events as a second separate process. Synchronising the video is much easier than synchronising the mass inert disc. Your Arduino has a crystal stable clock, so use that.

[Andrew Davie]

I doubt that the IR interrupt is the problem. That always occurs when the hole 31 is followed by the hole 0, so at a fixed moment in the rotation of the disc. I saw this jump in the sync bar moving horizontally, fixed to the 31-0 change in the video signal.

Any way, for me it looks a better idea to have a continuous interrupt in the Arduino each 80 msec (12.5 Hz), and synchronise the disc to that events as a separate process, and synchronise the video too to that events as a second separate process. Synchronising the video is much easier than synchronising the mass inert disc. Your Arduino has a crystal stable clock, so use that.

I will come back to your first point after I have done some more testing.

As to your second point, this is not clear. The data (video signal) is read from the SD card into a buffer. The data in the buffer is played by an interrupt running at exactly the frequency of the source. So, in the video 22050Hz. It is playing at precisely this speed, within the limits of the accuracy of the system crystal. it is very precise. There is no "synchronising" the video; it plays at exactly the rate it is supposed to, locked exactly to the accuracy of the system clock.

And the disc is synchronised based on the speed of that video signal but NOT from the signal itself - instead a counter that triggers once per detected rotation of the disc, telling the PID exactly how many samples (i.e., 22050ths) per second it is fast/slow by. So it, too, is precisely locked to the system clock. I don't see any inaccuracies or leeway in this system - it seems to be very logical to me.

In short -
video is synchrnoised precisely as a result of how it is implemented in interrupts
disc is synchronised precisely as a result of locking to the expected video position

[Klaas Robers]

Yes I understand you. But:
- what happens if the end of file is reached? Are the sync pulses then gone and is the disc running unsynchronised?
- what happens if a new file is started playing? Are the frame sync pulses then in a random phase and has the disc to be resynchronised? Then you mis at least the first seconds of the file.

When you create an internal crystal stable frame sync it should be rather easy to synchronise the output buffer of the video very fast to that internal frame sync. Then the disc IS already synchronised and you can enjoy the video from the second frame of the new scene. In this way all latency problems of the running disc are solved in an elegant way.

[Andrew Davie]

Yes I understand you. But:
- what happens if the end of file is reached? Are the sync pulses then gone and is the disc running unsynchronised?
- what happens if a new file is started playing? Are the frame sync pulses then in a random phase and has the disc to be resynchronised? Then you mis at least the first seconds of the file.

When you create an internal crystal stable frame sync it should be rather easy to synchronise the output buffer of the video very fast to that internal frame sync. Then the disc IS already synchronised and you can enjoy the video from the second frame of the new scene. In this way all latency problems of the running disc are solved in an elegant way.

OK, I understand your thinking. But that's not what I want because...
1) The disc spins down and stops. This is the behaviour I want.
2) The disc spins up and synchs. I want to have that experience as part of using my televisor. Yes, you miss the first few seconds.

I definitely don't want my disc spinning all the time - I want a disctinct start-up and stop.
The synching process is fascinating to watch - I'd like to keep that experience.

[Andrew Davie]

When you create an internal crystal stable frame sync it should be rather easy to synchronise the output buffer of the video very fast to that internal frame sync. Then the disc IS already synchronised and you can enjoy the video from the second frame of the new scene. In this way all latency problems of the running disc are solved in an elegant way.

The more I think about this, the more I agree with you. Spin up the disc based on a 12.5Hz signal, then the framing is automatic because the video playback is also synched to that signal (insofar as each new frame should start at the 12.5Hz pulse). Furthermore, fine adjustments can be made by simply adding an offset to the video playback pointer, so both vertical and horizontal adjustment of the framing should be possible too.

[Andrew Davie]

When you create an internal crystal stable frame sync it should be rather easy to synchronise the output buffer of the video very fast to that internal frame sync. Then the disc IS already synchronised and you can enjoy the video from the second frame of the new scene. In this way all latency problems of the running disc are solved in an elegant way.

The more I think about this, the more I agree with you. Spin up the disc based on a 12.5Hz signal, then the framing is automatic because the video playback is also synched to that signal (insofar as each new frame should start at the 12.5Hz pulse). Furthermore, fine adjustments can be made by simply adding an offset to the video playback pointer, so both vertical and horizontal adjustment of the framing should be possible too.

Following up on my post. The two systems are identical in all respects but for one - in "my" system, the disc "catches up" to the video by spinning super-fast to make up for the slow rotations at the beginning. In other words, after (say) 100 seconds, my system will have spun the disc 12.5 * 100 = 1250 revolutions. In Klaas's system, the number of times the disc has spun after 100 seconds is ALSO 1250 revolutions, but that's assuming it was already spinning full speed at second 0. Mine has the disc stationary at second 0. Other than that, the actual concept of the disc spinning on its own at 12.5Hz managed by a timer is identical in both systems. In Klaas's he has proposed an 80ms timer. In mine, I base it on the sample rate of the video and ticks of the video playback interrupt. But it's exactly the same. Finally, in Klaas's suggestion the video is also "locked" to the system clock in the same way the disc is locked to the system clock with the timer. My system is exactly the same, locked to the system clock through the interrupt at the sample rate. It's not apparent at first blush, but the systems are totally identical, except...

1) my system starts with disc not spinning
2) klaas's system starts with disc locked to correct speed

I prefer Klaas's system, although they are conceptually identical, because my system has to spend some amount of time trying to "catch up" to the video signal, whereas in Klaas's system I can pretty much see good video as soon as the disc is at speed. Another way of saying this; after the disc IS at correct speed, the two systems are TOTALLY identical. It's only what happens at the start that is different.

[Andrew Davie]

Thinking about this overnight, this will be a single line change in my code.
Currently I calculate the PID error ("current") value by incrementing every rotation a counter showing where the playback sample # is expected to be. It's incremented by one frame's worth of samples, every time the synch hole is detected. So that accounts for the disc speeding up and going way overspeed to "catch up" and then slowly settling.
The single line change is to change this PID error ("current") value to be just a delta from the last time the synch hole was detected, with the target being exactly the number of samples per frame.
The PID will then just synch the disc to an absolute physical position rather than both a physical position AND a "time in the video" position.
Then, of course, the scanlines won't be synched.
But the nice thing is that the disc and the video are still synched - we just need an offset for video playback. We would expect to detect the synch hole at exactly the same time as the start of a new frame. The delta will be the (playback sample pointer) MODULUS (samples per frame). I simply add/subtract this offset to the seek position reading from the file, and the frame will shift left/right by the appropriate amount of scanlines.

[Klaas Robers]

Even simpler it will be to:
- bring the disc to speed. This is a separate routine that is only run when starting.
- When at speed switch to a "hold" routine just at the moment that the IR hole is sensed.
- This routine locks the disc IR hole to a cristal stable 12.5 Hz.
- Then play the files locked to the same cristal stable 12.5 Hz.

Because you are only playing files from your SD-card, you have got an extra degree of freedom (the precise moment to start play back). It is unwise not to use that. You can easily prepare your files such that they start at a frame sync. I did that too for the files on the CDs.

[Andrew Davie]

Even simpler it will be to:
- bring the disc to speed. This is a separate routine that is only run when starting.
- When at speed switch to a "hold" routine just at the moment that the IR hole is sensed.
- This routine locks the disc IR hole to a cristal stable 12.5 Hz.
- Then play the files locked to the same cristal stable 12.5 Hz.

Yes, I was thinking along the same lines. But perhaps tune it a little to turn to the hold routine a bit earlier so there's minimal overshoot.