Jump to content

Is there a demand for custom sync sound motors?


Aapo Lettinen

Recommended Posts

  • Premium Member

Just experimenting with a 20x4 display which I will probably use for diagnostics when making experiments. This is too big of a display to include to the camera motor but I was just testing the layout and simulated what kind of information could be included if a display would be attached. 

Preset speed fps,  True fps the motor is rotating at the moment. Motor state (speed up, speed down, stabile) , drift (how much the true speed deviates from the preset speed) , the state of the two tuning trimmer potentiometers on board. 

A voltage meter could be added but I prefer to use separate small 3-digit led meters for voltage measurement. it would reserve one channel of the Arduino if I would need the volt displayed here and it would not be super precise measurement because I would use resistors to drop the input voltage to measurable level (0-30v dropped to 0-5v input level) .

the display update speed is about 1Hz or 1.5Hz which is not much but is OK for checking parameters. If I will add displays to the final products I will probably use small OLED displays in the 1.5 to 2" range.

49589478081_d40b144812_b.jpg

  • Upvote 1
Link to comment
Share on other sites

  • Premium Member
1 minute ago, Gregg MacPherson said:

Hey Aapo,

I have not time to follow all the detail, but can I just ask what the fps accuracy will be at sync speed, and at the other speeds?

Cheers.

Hi!

that depends on a lot of things, especially the accuracy of the speed measurements and the sample rate which the system can use to update the motor pwm cycle information. I am just rewriting the program code to make some fundamental changes to its behavior so that it kind of automatically stabilizes the speed when it is nearing the target speed. I will also make custom inertia+torque adjustment curves based on real life motor+camera system behavior and I will do this by actually testing physical motor combinations. this addresses the different inertia response and different torque requirements on different motor+camera combinations on different framerates so that good stability could be archived at all the preset speeds. 

all this should improve the stability a lot. I don't know how much before I have actually tested it but I am aiming to at least two decimal accuracy on the speed stability. We'll see how it goes, will probably get accuracy results in April or so. 

There is technically no reason why the system could not resemble true crystal sync with 3 digit framerate accuracy. I just need to figure out a lot of things to improve it and it needs lots of program versions and prototyping. Even the original design goal where the drift would be a frame per 2 minutes or so, would be useful for indie films etc which are not shooting a full roll at the same time and the max take duration would probably be a minute or two.

So I am currently aiming for 2 decimal accuracy on the fps. We will see before Summer what actually can be done but in any case this will be useful for most indie film needs I think. 

Link to comment
Share on other sites

  • Premium Member
36 minutes ago, Simon Wyss said:

There was a standard for speed and deviation, I can’t find it in this moment, but I remember the tolerance. Image and sound should not differ in length more than half a frame over 16,000 frames.

It sounds like they based the tolerance on 2000ft reels so no more than half a frame difference every about 2000ft of film shot on 35.

This kind of accuracy is not needed in real use though so I am aiming to more practical tolerances. The less than a frame per 2 or 3 mins is clearly usable for basic indie and it would be nice to have max of one frame drift per a whole roll which is a little over 10 minutes of footage. That would be excellent for every use unless someone custom orders 2000ft rolls and could magically fit them in the camera and would actually afford to shoot full 20min takes which would be used from start to end for some reason.

No one would still notice the quarter frame differences nor could sync the sound and image in post with that kind of accuracy. So by my opinion there is no need to follow this kind of accuracy expectations in real life. A one frame difference is noticeable but one does not shoot longer takes than a single roll lasts....

Link to comment
Share on other sites

  • Premium Member
5 hours ago, Brian Drysdale said:

There are CP16Rs around that can no longer run because the electronics have died. Just note that they are 20 volt, but if replacing the motor etc, fitting a 4 pin XLR socket shouldn't be a big deal. 

I found a very good image of the insides of the CP16 from some Flick user.  What components generally tend to 'die' there or is it just overall unreliability? 

https://live.staticflickr.com/3054/2926284910_4adadf00c8_k.jpg  

 

2926284910_4adadf00c8_k.jpg

there seems to be a nand gate and couple of dividers and a operational amplifier. the encoder disc and motor and mechanics could be utilized as is if all the other electronics would be changed. I can't see clearly those custom looking components so would need a closer look to determine what they are. All the parts which can be clearly seen have modern equivalents available so someone should be able to repair most of the original boards or make new ones if having the schematics and board masks or in the very best case, gerber files so that they could just be ordered from any electronics manufacturing company.  

I don't know though how much a newly made or repaired board would cost and who would make them for reasonable price. 

 

Link to comment
Share on other sites

I considered mentioning the CP-16r too because I think it's a great camera. It has a lot of modern components and it can be further modified to be even more functional. I understand there is a battery inside that was intended to keep track of footage when you change camera battery and that battery leaked on some cameras damaging some electronic components. I have two CP-16rs and they work fine, but looks like other people had that issue and I know a technician can remove that battery which doe no longer hols charge anyways. The CP-16 is kind of weird in some ways, but very functional and similar in ergonomics to what we have today in modern cameras.

The operation and maintenance manual is avaibale online, but I can email it directly to you if you want it, it contains several schematics. I also have the "Inetrim Professional Technical Manual" another manual that has a  lot of info about the camera, list of parts and components and at some point it has a lot of detailed information of the crystal sync system and some more schematics. Now that I saw that manual again I think it could provide you with a lot of information and you may get the idea of what they were looking for back in the day when designing those systems. I can send detailed high definition pictures of the gut of the camera too if you decide to take a look at it. Nobody wants to record sound on film anymore, so don't worry about the sound part, but some interesting things are the camera can be converted to U16 or S16 and a video tap can be mounted without removing the viewfinder. I have some other plans for that camera too that could make it more functional.

  • Like 1
Link to comment
Share on other sites

  • Premium Member
10 hours ago, Ruben Arce said:

The operation and maintenance manual is avaibale online, but I can email it directly to you if you want it, it contains several schematics. I also have the "Inetrim Professional Technical Manual" another manual that has a  lot of info about the camera, list of parts and components and at some point it has a lot of detailed information of the crystal sync system and some more schematics. Now that I saw that manual again I think it could provide you with a lot of information and you may get the idea of what they were looking for back in the day when designing those systems. I can send detailed high definition pictures of the gut of the camera too if you decide to take a look at it. Nobody wants to record sound on film anymore, so don't worry about the sound part, but some interesting things are the camera can be converted to U16 or S16 and a video tap can be mounted without removing the viewfinder. I have some other plans for that camera too that could make it more functional.

Please do! I would definitely get new ideas from those documents and could maybe reverse engineer something if needed. I don't personally own any cp16 lenses so will probably never purhase one of those cameras but maybe if there is one with broken electronics I could try to modify it ?

I sent a PM ?

Link to comment
Share on other sites

  • Premium Member

One of the ideas which came to mind was to crystal update the electrically stabilized Konvas 15EPSS motor to get rid of the large controller/battery box and get more stable speeds. This would help with the shortage of the original Konvas crystal motors. It may be one of my projects in the future but we'll see ?

Link to comment
Share on other sites

  • Premium Member

inspired by the CP16R schematics, I started to write another program for smaller microcontroller (Attiny85 at the moment). I will still do the other system as well, this is just a side project for other purposes.

The program emulates traditional crystal sync logical functions but is intended to replace the physical NAND gates and all but the first frequency divider after the Crystal. So it should function the same than the traditional crystal sync motor but can be made with less parts because most of the parts are emulated by the microcontroller.

it is also suitable for uses where one wants to create the motor controller and user interface by themselves but wants the actual crystal sync parts to be made by me. The current code version has a speed selector switch with three pre programmed speeds, a input for crystal signal and another input for the motor encoder signal. It outputs the correction signal in relation with how much the motor and crystal are out of sync, and it outputs another signal which shows if the motor speed is too high or too low or if it's the same.

So it outputs easily manageable signals which one could input to Arduino or other type of microcontroller and use the information to drive the motor speed correctly. This makes it easy enough to build your own user interface, display functions etc. to the camera if you want without needing to worry about the sync accuracy.

I decided to do this type of separate small microcontroller system because it is more reliable to calculate high-ish frequency pulses if the same processor does not need to manage extensive amounts of user interface and motor control code. This type of system also makes it a bit easier to make variable speed crystal sync systems.

Link to comment
Share on other sites

  • Premium Member
5 hours ago, aapo lettinen said:

inspired by the CP16R schematics, I started to write another program for smaller microcontroller (Attiny85 at the moment). I will still do the other system as well, this is just a side project for other purposes.

The current code version has a speed selector switch with three pre programmed speeds

though I THINK it would still be possible for me to have 5 selectable speeds even with this very small microcontroller. 

Anyway, the working principle is QUITE similar to the original system I am developing but it has small important differences. 

My original system measures input frequency from the motor encoder to get a frequency number which it compares to the speed preset number and does X or Y action depending on how much these numbers differ or if they are the same. 

My "traditional crystal sync emulation"  divides the input crystal oscillator frequency to get similar number of pulses per second which it expects to get from the encoder. then it compares these pulses directly against the encoder pulses to both see if they are in same frequency AND IN SAME PHASE.

this is why it is called "crystal sync" : the system tries to get the encoder disc pulses in sync with the crystal oscillator pulses so that there is both the same number of pulses per second and the pulses are also happening the same time. So "the oscillator and the encoder are rotating together like they would be on the same axle" so to speak.

So my "original system" compares frequency numbers against each other but the altered "traditional crystal sync emulator" compares both frequency AND phase of the pulses. Depending on the encoder disc characteristics the newer design will be a little bit more accurate and stable though the original system will also be stable and pretty accurate when it is fine tuned.

The new system of course has some disadvantages. It is a little bit more complicated and a bit more expensive to manufacture and there is some limitations what kind of frequencies (-->framerates) can be divided cleanly from the crystal oscillator. This basically means that when it has to divide with odd numbers there will be a little bit more drift in the stability. Should not be much but probably a measurable amount which would not affect real world performance at all (I expect something like couple of 1000th's of fps difference)

Link to comment
Share on other sites

  • Premium Member

Updated design specs. I will start making circuit board prototypes this month and test the new v.26 code. Will need to learn how to build multi-megaherz crystal oscillators so the "real crystal sync" versions will take some additional time. Maybe will happen in April or May or so.

There will be couple of different basic systems. Here is what I am planning to do before Summer:

System A: 

6 preset speeds selectable with rotary switch. More presets can be made available if needed (depends on the in-outs I have available. I should be able to make 12 speed presets available at the same time if needed). Speed stabilizing with numerical frequency comparison. No limitations in speed presets. a single microcontroller design. Display to see the selected preset speed and the real speed of the motor and some other parameters. Trimmers for fine tuning the system to individual camera+motor. Planned circuit board size about 60mm x 90mm x 20mm for now.

System B: 

4 or 5 preset speeds selectable with rotary switch. Some limitations on the speed presets because of the different working principle. Emulated crystal sync done with a multi-MHz crystal oscillator, dividers and 2 microcontrollers. Very accurate speeds. Display to see the selected speed and real speed and some other parameters. Maybe fine tuning trimmers if needed. Planned circuit board size about 60mm x 90mm x 25mm for now.

System C: 

from 2 to 4 preset speeds depending on the speed selector used. The goal is to make this system as small as possible. I think I could make this fully with one of those very small microcontrollers. I will need to do some experimentation what kind of crystal oscillator I will fit to this but I believe a 32Khz oscillator could be the best option. No displays possible on this model. Planned circuit board size about 50mm x 35mm x 15mm for now. 

 

The display options at the moment! these may change but the most viable options at the moment. I will add a display if it's possible. with the smallest system (C) it is not but with others it is relatively easy.

Display option 1:

LCD display 20x4 characters. Very big display, the display area about 76mm x 26mm and the outer dimensions for display itself are about 40mm x 95mm. the circuit board of it is 60mm x 100mm. So this will not fit in most camera bodies. Useful for diagnostics though and I will maybe use this on my large sized Soyuz-US3N camera. Low update speed.

Display option 2: 

LCD display 16x2 characters. Smaller than the option 1 and I will probably use this on my own cameras. Typical display area is about 14mm x 64mm , the outer dimensions of the display itself are about 24mm x 72mm and the circuit board size is about 37mm x 81mm. Low update speed. I will probably use this for my Kinor2M.

Display option 3:

A little bit more expensive but small LCD display. Display area widths are about 26mm or 12.1mm depending on the model. Should fit every camera body. I haven't tested these yet but they look very promising. The larger is 4x20 characters and the smaller is 4x10 characters. I will test these and will probably recommend these for all the systems which could use them. Update speed should be OK but I will need to test it first. 

-----

I tested the OLED display code and it may be too complicated to get it working reliably with the systems. The OLED displays are very handy though but will need lots of code to get them working. I will need to write my own optimized libraries to get them working reasonably well with the camera motor systems so I won't promise any OLED models for now. Nor use them with my own cameras even if I'd get them working reliably.

 

 

  • Like 1
Link to comment
Share on other sites

  • Premium Member

The thinner you can make any single version the easier it will go into housings. Best would be a flexible board that can be pasted. Not quite serious but as thin as possible, please. C is my favourite, four speeds.

Link to comment
Share on other sites

  • Premium Member
46 minutes ago, Simon Wyss said:

The thinner you can make any single version the easier it will go into housings. Best would be a flexible board that can be pasted. Not quite serious but as thin as possible, please. C is my favourite, four speeds.

the boards are possible to divide into segments if needed but I will need to build the prototypes first to see how far they can be split. the thickness is possible to manage with SMD parts but I don't have much experience working with them yet, especially the ones which need to be soldered under the part as well which would need a special oven and solder paste working method. I think I could make the C version less than 10mm thick with normal parts and keeping the dip connector for the microcontroller without needing to solder it in place. Soldering it in place would save lots of thickness but it would be more difficult to repair the boards if something goes wrong. Have to see what parts are needed for the oscillator. At the moment I am planning on board sizes which can be done with small scale hand assembling and not special production lines with reflow process needed.

The catch with the C type design is that it does not have as sophisticated PWM motor control. So it has to be fine tuned to individual motor/camera combination in the code. It is a simple and reliable design but it will need this "lab tuning" stage to work well with the camera

Link to comment
Share on other sites

  • Premium Member
3 hours ago, Gregg MacPherson said:

Hey Aapo,

any chance your couriosity extends to speed ramping for SRs. Some interest in that exists, or is infered elswhere on the forum...

.....https://cinematography.com/index.php?/topic/82964-16mm-footage-has-vertical-streaks-aaton-ltr7/.....

Hi!

I don't own any SR3's so it might be pretty challenging for me to test it. Do you mean something which has similar style options than the Arri CCU-1 but is easy to adjust the speed with knob like the old style Arri Speed Control like this one?  

https://www.ebay.com/itm/NEW-NOS-ARRI-SPEED-CONTROLLER-for-ARRIFLEX-IIC-2C-35MM-MOVIE-CAMERA-/292606125158

For SR1 and SR2 this should be easy if having one of those old varispeed controllers available to take measurements from. But to me it looks like the SR3 uses some kind of unknown control protocol between the camera and the speed unit... without knowing exactly how the protocol works it would be impossible to create this type of accessories.

So it is not impossible but it might be too much work to do... I would need to contact Arri to ask for the protocol details and then drive back and forth to the rental house when testing the prototypes. It depends on the protocol how much actual coding work there is, some of them are relatively easy like basic Lanc and dmx. Some are not, like the EOS lens control for example. 

It might be better to contact a company which already has experience developing SR3 accessories, they might know the protocol used and would need much less work to get a working system available. Here in Finland the Elokuvakonepaja has lots of experience developing custom accessories for Arri cameras, they might have some ideas how this type of accessory can be done

Link to comment
Share on other sites

4 hours ago, aapo lettinen said:

I asked Arri about the protocol, we'll see what they answer ?

Maybe nothing. Last year I have asked them about different SRs and protocols, connectors and the like.

They told me whoever was part of the SR projects has since left and they do not have any documentation left and cannot tell me anything anymore... I was surprised. Maybe you have more luck now.

There used to be one guy on Ebay Germany some months ago who was selling a big amount of SR technical specifications (hard copies). I just checked again if anything is still there but cannot find it anymore unfortunately.

Link to comment
Share on other sites

  • Premium Member
33 minutes ago, Bernhard Kipperer said:

Maybe nothing. Last year I have asked them about different SRs and protocols, connectors and the like.

They told me whoever was part of the SR projects has since left and they do not have any documentation left and cannot tell me anything anymore... I was surprised. Maybe you have more luck now.

There used to be one guy on Ebay Germany some months ago who was selling a big amount of SR technical specifications (hard copies). I just checked again if anything is still there but cannot find it anymore unfortunately.

In the absolutely worst case scenario one could try to reverse engineer the data signal transferred between the camera and the CCU1 controller and then try to emulate it with completely other type of hardware. Of course one would need both the working camera and the working controller for this. One would hijack the data lines between them and spy what kind of signal goes back and forth when a button is pressed or a setting changed.  This would be EXTREMELY time consuming though and my experience and resources would not be enough for that type of project.

I would expect it taking about 1 to 2 years working full-time to make something useful if the whole control protocol would first need to be reverse engineered and then completely new software and hardware built from scratch. Maybe if someone would order 1000 control boxes or more, then it would be possible.

OR one could open the CCU1 and write down the exact circuit design and get a copy of the firmware out of it so it can be examined and studied. Would still be enormous amount of work. 

I hope that Arri has even something available ? 

Link to comment
Share on other sites

1 minute ago, aapo lettinen said:

In the absolutely worst case scenario one could try to reverse engineer the data signal transferred between the camera and the CCU1 controller and then try to emulate it with completely other type of hardware.

Last September I got a chance to borrow an ARR16SR1 for one day in a different city.

I was using a Saleae logic analyzer connected to my laptop, a bread board and few jumper wires, a Fischer plug I bought from Fischer directly where I had soldered jumper wires to it at home already and a multimeter to carefully check what is connected to what.

I could find out quite a lot in one evening in my hotel room.

I recorded the shutter signal coming from the SR1 for example and after some extra work fed the recorded shutter signals back into an Arduino Pro Mini. Later on I used that Arduino to "play back" the signals to another device of mine to test that, without needing the actual camera itself anymore. Worked pretty well, I could continue testing at home without any camera at hand anymore.

But your case maybe totally different of course.

Link to comment
Share on other sites

  • Premium Member

as far as I know the SR3 uses the same controllers than Arri 535. some kind of digital protocol it is but no idea about the specifics because can't find any documentation. 

A controller for SR1 or SR2 would be much much simpler and easier to make, I believe the old speed controller is basically a potentiometer with some additional parts. If I would own an Arri camera I would probably make a Arduino based replacement right away. It could probably even be possible to use my crystal sync control driving a SR1 or 2 externally if it would listen the shutter signals and use simple analog means by controlling the motor speed. This would enable more stabilised speed presets to the old SR cameras so could be handy

Link to comment
Share on other sites

  • Premium Member

Assembling the first circuit board test prototype. This is the "A" model design but I will alter it a bit and will make it smaller. It is much easier to test the prototypes when they are firmly soldered down and no loose breadboard contacts anymore.

This is for the Kinor16CX-2M camera. All the functionality is there: the voltage regulator, the two trimmers, dual inputs for motor speed metering, pwm output for power transistors driving the motor, parts for attaching the rotary selector for 6 individual speeds, and a output for i2c lcd display. 

During the tests this new prototype is going the live in the "magical black box" to make the testing easier. Maybe I could even take this version out later and shoot something with the camera :) 

 

Attaching the parts and making wire connections. Figuring out the layout when nothing is permanently attached yet.

49632407242_ef4d172043_c.jpg

 

The back side of the board with some of the parts installed

49631620333_571ef712df_c.jpg

Soldering the parts in place one connection at a time. Very time consuming process.

49632407887_822f06f2f4_c.jpg%20

 

Work in progress. I will cut the excess wire after the soldering to finish the connection and to make room to solder the nearby connections. I will add parts and wires when I get more room by cutting the excesses out. 

49631620583_2cb278be6c_c.jpg%20

 

Finished prototype board without the Arduino. I use rubber gloves when soldering to reduce lead exposure.

49632408372_c62d3055a4_c.jpg

 

Arduino installed. It is possible to make the board lower profile by installing the Arduino and the voltage regulator differently but that is not critical at this stage.

49632140686_123f39c3a7_c.jpg%20

 

Other angle of the finished board.

49632408787_3b810cae92_c.jpg

 

The prototype will live inside this "Black Box" for now.

The next version will be a bit smaller though this version is already about 80 x 90mm which is close to the design specs. There is a little bit of excess on the board so making it smaller would be very easy. I won't cut this board smaller because the bakelite resin is pretty fragile. The final boards will be fiberglass which is very tough and does not shatter.

49631619968_c66e314e5d_c.jpg

 

The next version will probably already be on standard fiberglass board and made with the normal etching techniques. These proto boards are handy when making this type of design experiments because they are pre-drilled which saves lots of work.

-----------

I will post results later when testing the new code versions with this hardware version. If it works well, then I could maybe already shoot something with this external box system  :)

  • Upvote 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...