How Crystal Sync Motors work and modern sollutions

Tyler Fukuda · January 4

Hey there. I'm hoping to find some information on crystal sync motors and how they are typically made, what their components consist of and how they work? Is there any resources on the web that can be found of a 'how-to-build' one of these? Thank you in advance!

Steve Switaj · January 4

How much do you know about electronics?

(Not meant to be a snarky answer, I'm trying to figure out how technical to be in response)

Steve Switaj · January 4

Also - What kind of camera are we talking about?

Tyler Fukuda · January 4

54 minutes ago, Steve Switaj said:

How much do you know about electronics?

(Not meant to be a snarky answer, I'm trying to figure out how technical to be in response)

Hey Steve, no offense taken. I have a fairly general understanding of electronics but I’d appreciate any information to be easily understood and I can always research more technical details on my own time. I’m hoping to understand it’s functions from sort of a start-to-finish basis—I understand that might be too much to provide here which is why I asked if there were any external resources on the web. However if such information can be broken down here I imagine it might help the community too! Thank you heaps!

Aapo Lettinen · January 4

-

Edited January 5 by Aapo Lettinen

Kamran Pakseresht · January 4

The fundamental idea behind crystal sync motors is very simple:

If you know how fast a motor is spinning, you can adjust its speed to run at a consistent rate.

How fast a motor is spinning can be determined using a Hall effect sensor and 1 or more magnets affixed to the motors shaft in some way.

Time is a funny thing because you can’t just say: tell me how long it took between detections of the magnet crossing my sensor, unless you can accurately measure how much time passed between those two moments.

Generally quartz crystals are used because of their accuracy and is why it is called crystal sync.

In modern times most microcontrollers contain a crystal oscillator and can be used for this purpose. The general process is: measure the speed of the motor, generate an offset ratio between desired speed and current speed, and use that ratio to modify the actual motor power. Do this many times in a loop over and over until you are at your desired speed and even then keep doing it to keep it locked.

Historically and even still now you can also use what’s called a Phase Locked Loop (PLL) IC to compare your motors speed to a crystal oscillator and output a voltage proportional their offset which drives a VCO (voltage controlled oscillator) and use that to drive a PWM signal for a brushed DC motor driver which then drives your motor. This setup would not require a microcontroller at all, and is generally how they were built before microcontrollers were common place.

You can also model a PLL in software.

I’m working on a video to explain how I built a crystal sync motor for the Arri 16S but the concept for building one for any other camera is basically the same, so hopefully it will be useful for just generally understanding the process.

I would say to not be discouraged in trying to build one but it has been incredibly helpful to have a 3d printer and a set of digital calipers for measuring and modeling.

It took me a couple months of working at it to end up with a motor accurate enough to record sync sound on lengths of film commonly available today. There are much more feature filled and accurate crystal sync systems available but if what you’re trying to do is just record some sync sound on one or two speeds, it’s definitely achievable, but you probably need to be a bit of an engineering/tinkering type.

Edited January 4 by Kamran Pakseresht

Tyler Fukuda · January 4

Aapo-- That is very commendable and like you, I have a similar interest in electronics and engineering. I'm not looking to build and sell these as a business model but more curious as to how they work and what components make them up. If hypothetically all it took was a few components like a DC/Stepper Motor, Arduino, Driver and a battery then I'd have some better knowledge knowing what components are what and how to create one.

I have a 16mm K3 i'm willing enough to modify on my spare time but that doesn't mean I wouldn't try this on a Bolex, ARRI 16s, etc etc.

Tyler Fukuda · January 4

29 minutes ago, Kamran Pakseresht said:

The fundamental idea behind crystal sync motors is very simple:

If you know how fast a motor is spinning, you can adjust its speed to run at a consistent rate.

How fast a motor is spinning can be determined using a Hall effect sensor and 1 or more magnets affixed to the motors shaft in some way.

Time is a funny thing because you can’t just say: tell me how long it took between detections of the magnet crossing my sensor, unless you can accurately measure how much time passed between those two moments.

Generally quartz crystals are used because of their accuracy and is why it is called crystal sync. In modern times most microcontrollers contain a crystal oscillator and can be used for this purpose.

Historically and even still now you can also use what’s called a Phase Locked Loop (PLL) IC to compare your motors speed to a crystal oscillator and output a voltage proportional their offset which drives a VCO (voltage controlled oscillator) and use that to drive a PWM signal for a brushed DC motor driver which then drives your motor. This setup would not require a microcontroller at all, and is generally how they were built before microcontrollers were common place.

You can also model a PLL in software.

I’m working on a video to explain how I built a crystal sync motor for the Arri 16S but the concept for building one for any other camera is basically the same, so hopefully it will be useful for just generally understanding the process.

I would say to not be discouraged in trying to build one but it has been incredibly helpful to have a 3d printer and a set of digital calipers for measuring and modeling.

It took me a couple months of working at it to end up with a motor accurate enough to record sync sound on lengths of film commonly available today. There are much more feature filled and accurate crystal sync systems available but if what you’re trying to do is just record some sync sound on one or two speeds, it’s definitely achievable, but you probably need to be a bit of an engineering/tinkering type.

VERY helpful -- Regarding the time measuring mechanism. I had seen a video of such a part (TCST1103) which uses a IR emitter on one side and a phototransistor on the other side. It was mounted with the shutter mirror passing inbetween so when the signal was interrupted, an arduino would record the interruption and you could somewhat accurately determine the speed on the shutter. Obviously the methods you have mentioned here seemed to be tried and true as well! I would love to see this video or any information in how you went about your builds. I also plan to purchase a 3D printer in the next few months here, specifically the P1S or a Prusa

Aapo Lettinen · January 4

-

Edited January 5 by Aapo Lettinen

Aapo Lettinen · January 4

-

Edited January 5 by Aapo Lettinen

Aapo Lettinen · January 4

-

Edited January 5 by Aapo Lettinen

Steve Switaj · January 4

35 minutes ago, Aapo Lettinen said:

... Almost all my motors are using bldc motor 's integrated Hall sensors to save money and mechanical work, they usually give 4 pulses per revolution so real crystal sync system is needed to get good accuracy with those.....

I had meant to ask you about that.

Do you actually close the speed loop with the hall feedback or is the motor torquey enough that you just feed it with the right drive frequency and use it as a synchronous motor, like a stepper?

Aapo Lettinen · January 4

-

Edited January 5 by Aapo Lettinen

Aapo Lettinen · January 4

I often get very depressed by trying to help people with their diy projects, that greatly affects my own work. I am trying to make something different than most people and have too much invested to not worry about anything or to give away stuff which I need the money back from to get food. Probably wont visit this thread later. Read the cp16r manual, it helps a bit with the research. Good luck with the project!

-----

Kamran's motor seems to work pretty well. I personally usually test motors, among other tests, with TF930 frequency counter linked to gpsdo at 10s and 100s gate times to get really good idea about the real running speed and to have kind of scientific results rather than empirical stuff but if a motor holds the frame for many minutes then it is perfectly fine for sync sound stuff.

Edited January 5 by Aapo Lettinen

Steve Switaj · January 4

By the way Tyler, here's some visual reference to what we've been talking about.

This is an appnote for the ST L6234, a popular chip for driving BLDC motors.

https://www.st.com/resource/en/application_note/an1088-l6234-three-phase-motor-driver-stmicroelectronics.pdf

It dives pretty deep, but ignore all that for now and look at the figure 14 at the bottom of page 7. It illustrates a typical PLL application, like you'd find in an older camera.

On the right side of the diagram is the motor. Attached to the motor is some device to sense speed. In this case it's a hall sensor, but in an older camera it would be a toothed wheel spinning in front of a magnetic pickup or a slotted disk spinning between a photo transistor and LED.

The technology is not important. What's important is that this sensor makes a signal whose frequency is directly proportional to the motor speed.

That signal is brought to the left hand side of the diagram where it is compared to a reference signal derived from a crystal oscillator and assumed to be accurate. The difference between these signals is the speed error. This error is applied as a correction to the amplifier circuit driving the motor, such that the motor speed is adjusted to match the reference speed.

Steve Switaj · January 4

5 hours ago, Tyler Fukuda said:

If hypothetically all it took was a few components like a DC/Stepper Motor, Arduino, Driver and a battery then I'd have some better knowledge knowing what components are what and how to create one.

Well, hypothetically, that's all it does take.

Granted, it won't be all that elegant, but steppers are totally viable camera motors. Back in the day we used to use them on Mitchells at live action speeds all the time.

I should note that as far as motors go, steppers do have an low upper speed limit related to drive voltage, but since you're talking about 1440 rpm you should be able to get that out of a smaller motor at reasonable battery voltage (say 24V).

Unfortunately, steppers have a distinct noise while operating, a combination of the driver current switching and torque cogging. But if you're not shooting sync-sound, they work just fine.

The best part is that steppers are not used closed-loop, which means no feedback or PLL.

Instead, steppers are controlled by manipulating the current through two interleaved sets of motor windings. If you do this in the right pattern, you can get the motor to rotate in discrete steps with each change of drive current. As long as you stay below certain torque and speed limits, the motor will follow along with the drive pattern, which is a 4 step cycle (this is often electrically subdivided further in a process called microstepping for smoother motion).

Better yet, most commercial stepper drivers handle all this internally, and you just have to supply two signals, 'direction' and a 'step' pulse, and the driver figures out the rest.

Most commercial motors are wound to have 200 full steps, so if a microcontroller, say an Ardunio, can keep up with posting 4800 steps/sec, it can drive a camera at 24FPS (again, you can subdivide this into microsteps, but at 1440 rpm you're below the time constant of the motor and it really doesn't matter).

Typically, someone programming this application will use one of the timers internal to the microcontroller to generate an interrupt at the right frequency, and the interrupt routine will generate a step signal for the driver electronics. Acceleration and deceleration phases manipulate the timer interval to ramp the motor up and down.

Accuracy is limited to how accurately you can generate step pulses, which are derived from the timer, which is in turn derived from a crystal oscillator feeding the microcontroller (most Ardunio-like boards have a real oscillator because they need accurate timing for their UART ports). Some camera speeds will not evenly divide from a given oscillator, so sometimes you have to play with the timer interval for each cycle.

Look up "Ardunio step motor shield". There are many manufacturers and they tend to have useful libraries for their boards. Even if you don't use them you can still examine the code for ideas (such as how to handle acceleration and deceleration)

Kamran Pakseresht · January 4

I was curious about what Aapo had said because I really am just measuring motor speed (with only 4 magnets and a hall effect sensor) and comparing it to my desired speed. I am using a number of hardware features on my board, the Raspberry Pi Pico, like PWM input edge counting and DMA (direct memory access) to avoid using up valuable CPU time - but it made me wonder if I am going to run into any real-world issues with this approach.

So I recorded the shutter on my Arri 16S with my motor running at 24fps speed on my black magic camera, also running at 24fps and set it at a high shutter speed and just let it go for 9 minutes.

I know there is much more experience in this thread than I have about this, I am fairly new, but I've recorded a number of tests already without noticeable issues and am just wondering - given the results in the video - would I ever really get an out of sync issue with this approach on realistic (up to 400ft?) film lengths?

Also, was it misleading of me to call this a crystal sync motor? I had assumed that because it was accurate enough to synchronize with audio and was using a 12mhz crystal to measure the motor frequency that it was a crystal motor. Should I rename it to something else? Maybe a sync sound motor?

Also I really love this thread - thank you everyone for sharing all this information, it was very difficult for me to find some of this information previously and I'm excited to gather some of it in one place.

Steve Switaj · January 5

4 hours ago, Kamran Pakseresht said:

Also, was it misleading of me to call this a crystal sync motor? I had assumed that because it was accurate enough to synchronize with audio and was using a 12mhz crystal to measure the motor frequency that it was a crystal motor. Should I rename it to something else? Maybe a sync sound motor?

This is fine. This is typical of the amount of flutter I would expect to see on an older camera. More modern cameras with a full resolution encoder on their motor and a tighter servo loop would have less flutter, but this is what every camera I used in the 90's looked like when you strobed it and and they were all just fine.

Now you've got me curious about your technical details, are you using a brushed motor or a BLDC?

Also, it sounds like you made your own speed sensor made of 4 magnets that pass in front of a hall sensor? Is that on the motor shaft? If so the Arri S has (IIRC) a 3x motor so that should give you 12 counts per frame, or a 288 Hz feedback signal, which should be plenty to close the servo loop.

I have a Fries 65 on my bench right now that I'm working on rebuilding and it only has a 24 slot speed sensor (Though, when I rebuild a camera like this I usually integrate a modern 200 cycle optical encoder, which makes the servo loop waaay tighter).

But yes, to answer your question, if you can get to the end of the roll and be on the right frame, it's a crystal motor. You don't need to be any tighter than that unless you are doing super long takes under some super-unusual discharge lighting or maybe doing 5 minute takes of an old CRT television.

The original term 'crystal sync' meant that both the camera and audio recorder had an on-board reference and could work independently. Before that there was pilot tone, where the camera had a little tachmoter on the motor that generated a nominal 4800(?) Hz tone that was mechanically coupled to the speed of the camera. This tone was fed to the audio guy who recorded it as a separate track. This tone became, in effect, the perfs for the audio track.

The camera might drift a bit, but so would the pilot tone, and they'd do it in sync. Later, in post where everything was held to 24 fps, the tape was played back with a player that kept so that the playback tone at 4800 hz regardless of what frequency it had originally been recorded at.

If the camera was a bit slow, say only 23fps (or 4.2% slow), the pilot tone went to tape at 4600HZ. On playback back in the post house, the tape machine there would speed up the tape 4.2% to get the pilot tone back to 4800Hz, and the playback speed would magically match the film, now also running at 24fps. (there would be a slight pitch change, but unless you were doing music it was never enough to worry about)

Steve Switaj · January 5

Incidentally, if you didn't provide an external pilot tone, the Nagra recorders built for film sound work would generate one internally at exactly 4800Hz and lay it down on the reference track. In the days before time code and digital formats this was the only way to get a true speed reference for the audio tape.

Kamran Pakseresht · January 5

34 minutes ago, Steve Switaj said:

Now you've got me curious about your technical details, are you using a brushed motor or a BLDC?

Also, it sounds like you made your own speed sensor made of 4 magnets that pass in front of a hall sensor? Is that on the motor shaft? If so the Arri S has (IIRC) a 3x motor so that should give you 12 counts per frame, or a 288 Hz feedback signal, which should be plenty to close the servo loop.

I am using a Brushed DC motor that’s rated for max of ~10k rpm at 12v and a high power motor driver from Pololu here - partly because the motor needs a lot of current for such a high rpm and partly because it’s a very compact driver that can fit in the enclosure I designed. It also had the added benefit of having a regulated 3.3v output that is juuuust enough to power the pico without needing an extra step down converter in the mix.

And yes I designed a base collar that fits on the back of the motor and holds a Hall effect sensor (Honeywell SS451A) with a little jst plug to make it easy to connect and then there is a disc that has 4 equally spaced tiny neodymium magnets which fits on the little bit of shaft that protrudes out the back of the motor. Seems to work pretty well with such fast speeds.

That is an awesome camera to have on your bench! Do you have an optical encoder that you can recommend? I’d like to try something like that out - is an optical encoder generally better than a Hall effect sensor for these type of projects?

Steve Switaj · January 5

Well, if your servo loop is stable, that means you've got enough feedback, so 12 pulses per frame is plenty for you.

Also, your motor is doing 4300 rpm, so the rotating mass of even a small motor has significant angular momentum which will definitely smooth things out.

But, as a genera rule, having more angular resolution on the motor allows for a faster servo loop, and a faster loop means tighter control. (It doesn't gain you much to have a servo loop faster than the angular interval between possible measurements because you can't detect any angular change.)

Whenever I do an electronics update I install an 800 count shaft encoder from USDigital. This is both fine resolution for the servo loop and it gives me a simple way to generate a 200PPF signal, which is the standard tach signal on the Arri Fischer-11 connector so you can use common accessories.

For your app that is overkill, but if you want to experiment with encoders, try this product from SameSky (used to be CUI devices)

https://www.sameskydevices.com/product/resource/amt10e-v.pdf

It's a small, modular, shaft encoder. It's not optical, it's magnetic with a small microcontroller deriving shaft position. It comes in a kit with a couple of installation tools and a set of sleeves to adapt it to a variety of shaft sizes.

Best of all it's cheap - about $35 for a fixed-resolution version, from Mouser or DigiKey. Perfectly priced for experimentation.

Steve Switaj · January 5

Now you've got me curious.

I have a 16S here on a shelf.

I'm thinking of getting a little high-velocity BLDC drone motor and seeing if I can build a camera motor without any feedback at all, just generate the 3-phase drive signals at the right frequency and let the motor be a synchronous motor. At these speeds and loads it might just work.

Well now, that's just great, Kamran. Now I have yet another project. Thanks a lot.

Tyler Fukuda · January 5

As I gather the information provided here, and hope this thread continues, that I greatly appreciate all of you that have shared within this post. It greatly helps those wanting to better understands these systems as there seems to be scarce information out there!

Tyler Fukuda · January 5

Here is one of the diagrams of the mathematics involved in determining rpms from the CP16r manual-- Does anyone know where the '2.4' and '2.5' figures are coming from in order to get our 3600 rpms? Are these just increased FPS from say 24 -> 60?