Aapo Lettinen

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

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

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.

Great that you got the camera fixed easily! Just wanted to say that one never needs to throw the camera away even if the electronics are burned and no spare parts available. With today's technology is is possible to install completely new custom made electronics to the existing camera body... even a different type of motor if needed. I am for example developing a DIY crystal sync solution which would be adaptable to multiple different camera types and is customisable. It will cost a bit of course but it can give a new life to a camera body. Something finished is probably available in Summer or so :) https://cinematography.com/index.php?/topic/82711-is-there-a-demand-for-custom-sync-sound-motors/ (If the original electronics can be repaired, then it usually is best to just keep them as is. If they cannot be repaired, then a completely new motor control system like my design may be the best option. If the camera body is MECHANICALLY trashed completely then it might be best to let it go and purchase a new one. Just something to know of... there is still hope even if the camera's electronics are trashed and non repairable. A new control system can be developed even from scratch, it is much easier to do nowadays than in the 70's or 80's. Most of it can be done with programming and standard parts and 1/10th of the work)

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)

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.

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 ?

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 ?

what are those "custom looking parts" with the labels on which cannot be seen clearly?

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 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.

they did try some recovery programs on it? broken cards do happen and in the case of those it may require significant lab work and expense to get the footage out. On one occasion it cost close to 10K to get the data out from a badly damaged card but all the clips were restored in the end. was still cheaper than reshooting the whole day. much more common is though that the file system on the card develops issues. the most common I have came by is broken partition tables which can happen if the card is for example unmounted the wrong way or the camera just decides to trash it. this type of filesystem damage is most easy to make by removing the card from the camera in the middle of recording a take so that it is removed when the camera is writing on it and the partition table is not updated correctly so that the memory addresses go missing. Data recovery programs can be used in this case and are often very successful. these cases often throw the "the disk is not readable by this computer" error when trying to attach the card to the computer. it may be challenging to find out though what went wrong with the card. But if they gave up on it already then it won't hurt to try recovery programs on it. sometimes it may help the recovery if the card is formatted first but DON'T RECORD ANYTHING ON IT YET. formatting does not erase the images but rewriting will. (formatting just updates and recreates the partition table so it nulls the disk content on the tables but all the data is still there in the memory, its location and type is just not specified anywhere so the operating system does not know it is there. a recovery program reads all the data in the memory without minding the partition table at all and then the program tries to figure out what type of a files are in question and where is the file start and file end. then it can restore everything which it figured out. ) if recovery does not work then it may be some kind of physical damage. this is rare but it is not totally uncommon. I see it about once in every three or four productions or so. For example there was 3 tv series seasons shooting where one production had one broken cfast card. Flash memory is not totally bulletproof and if shooting long enough with it something will most likely happen sooner or later

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....

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.

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.

I am not familiar with those motors. only shot with the normal spring motor bolexes. Do you happen to have schematics of the ESM motor? is it one of those which were meant for pilot tone use and not having "real" sync stabilized sync speeds? Solar cell extension should be easily doable. some kind of lithium ion battery should be added for power storage

I got some new ideas when walking the dog. When I got home I started to rewrite the code... and there will be fundamental changes to its structure and behavior. This is to address better the different torque requirements and inertia response of different types of motors on different types of cameras on different speed settings. This means the design specs will change as well. The main advantage is that it is easier to fine tune the camera by the end user if needed and the speed will be much more stable than with the old code versions. The disadvantage is that if the code needs to be changed it may become incredibly tricky for the end user to do by themselves and that is why it may be too complicated for them to change the response curves directly in the code from now on. I could, however, make some kind of mechanical selector which switches between different response curves if someone would absolutely need that. it would cost a little more of course. Most of the persons have asked for a custom system per camera model so an all-rounder design may not be beneficial goal anymore. I think I will rather change this being a custom product which is specially adapted by me for different camera models and then the system can either be installed by the end user or someone else can do the mechanical work of installing the boards and encoder discs and such. I can do it as well but it will cost more, especially because of the high shipping costs to here from the US. ------ WHY I CHANGED IT! that is because the preset speeds scale is so wide (my current prototype uses speeds from 12fps to 32fps but people have asked for top speeds of 50fps or more) which means there needs to be multiple different response + torque level combinations across the range. a simple adjustment does not correct all the speeds at the same time so with the old design the tuning could be done for mid speeds so that the high speeds were off and the lows were unstable, or for low speeds and then the mid speeds were unstable and the mids and highs were off. That is because the inertia of the moving parts and the friction (especially the one caused by the moving film itself) change different amount on different framerates on different cameras. it is a logarithmic change and the previous linear adjustment approach could not address it fully. The other reason is that I added a auto-stabilizing feature which reduces oscillation around the target speed to get closer and closer to it quickly. This feature needs the custom response curves as well. ------ Design specs at the moment: - there will still be the 6 pre-programmed preset speeds. The rotary switch is the easiest way to select these reliably without a display so I will keep it in the design. - two fine tuning trimmers on the circuit board which the end user can access if needed. The basic response curves are made in the code but the fine tuning changes how these curves are implemented. - I will make different style of response curves when I get the encoder disc testing motor working. Maybe at least a dozen different curves for starters. And later on, curves on every adapted camera+motor combination. Then I can choose from them and fine tune when adapting the system to an actual camera. - if I already have the data for a particular camera motor and body, then it is possibly to upload the appropriate custom software version to the board and ship the electronics for someone else to install it to the camera. I could probably do the installing here if needed but it may be more expensive because of the shipping costs. The code is customized per camera+motor combination. - if the camera body / motor combination is new, then I will need to get the motor and the camera body here to do measurements and possibly rewrite parts of the code for this exact combination. also for getting measurements for the circuit boards which could fit to the camera, this changes from model to model. I may need to custom design the boards if there is not enough space for existing designs to fit. The benefit of this is that if you need a custom feature it may be possible to add it. For example if someone wants a DIP switch on the board which selects between different style of response curves it could be made. ---- Price estimates! Everyone is always interested in these so I am just trying to figure out how much it could cost per camera. Nothing includes shipping costs of course. The benefit of an user installable product would be that the shipping costs would be very small so it would be significantly cheaper. The goal is to make the installing relatively easy even if the end user does that. - new camera model and motor to be adapted. some customizing needs to be done and maybe limited designing of new parts. the price depends on the time it will need from me but I estimate it could be from 1K to 2K per camera model to do this. This would include adapting one camera body. In the very best case it might be two bodies. Depends on the amount of work needed. I would recommend a minimum of two cameras to be adapted if the model needs serious design work but singles could be done as well, it is just more expensive per camera. - boards and installed software for known camera model and motor which is already adapted sometime earlier so that I have the data available to choose the right response curves and board sizes right away. Someone else will do the installing of the boards and encoder disc etc. and I will just supply the parts kit. Includes email support and some spare components if the board or sensors need to be repaired locally. Price estimate could be about 300 - 400 bucks or so if the boards are done in small runs and could be lower if mass production is possible and there is high demand. Minimum order one board but there has to be enough demand so that I can sell at least couple of them per year. I would recommend pooling two or three cameras and then ordering the conversion kits at the same time. - known camera model and motor. I have all the data available, the board sizes and designs etc and just need to install the boards and software here. the camera is shipped to me and I will send the fine tuned setup back. Price estimate could be from about 500 to 700 bucks or so if custom mechanical parts don't need to be manufactured and the installing takes about one day maximum. Installing tends to need drilling of the housings etc and the fitting of the encoder takes some work and may require a custom spacer which I will need to machine by myself. - mass production is a different matter. for example the system Simon described would be more standardized and cheaper to produce because the boards could be done in at least couple of hundred boards at a time and no hand assembling needed by me. -------------- So there will be different style of models and always some customizing done. The one-design-rules-them-all approach was maybe not something people were interested in so I changed the approach ? I might investigate later on if it's possible for me to do small runs of complete 16mm camera modifications and selling them as well. For example crystal sync modified Krasnogorsk 3 cameras for reasonable prices. Might be doable but we'll see. I will probably do some designs with other type of microcontrollers as well. Just need to get more familiar with them. Probably PIC or custom programmed AVR which don't run the Arduino code. We'll see. I will probably release some old software versions to open source sometime later. The new code is so fundamentally different and better that I will abandon the old design and could as well write a simple version of it for everyone to use if someone wants to try by themselves. Release date TBA but probably next year or so. Let me know what you think ? I though it would be interesting for people to read these updates because they reveal the design and thought process used and how the goals and features change during the project timeline. I saw there was some earlier crystal sync threads on the forum as well but they did not end to a final product. I have a little different approach so I am pretty confident that some type of final products will be done already this year.

I considered reverse engineering too before starting this project. But by my opinion and based on the advancement so far I would say that in my situation it actually IS much simpler to design a system completely from scratch instead of reverse engineering and copying an existing design. Especially in the case of the US3N camera which is so rare that there is not even pictures of it on the internet except the ones I have uploaded there. Maybe one manual cover or something but thats it. It is a Soviet X35/Mitchell bncr hybrid and no motors available anywhere. Someone mentioned that bncr crystal motors might be adapted maybe but they are also rare. And I want the motor to be more lightweight and smaller because the camera body itself is not super heavy, maybe around 30lbs or so and it is self blimped so I would have serious use for it even when it is KS perf at the moment. An old video showing the camera body. I have a better temporary wild motor solution for it but would like to shoot sync sound with it https://m.youtube.com/channel/UCRQ4FduL9HyTBzX34CDtY4Ahttps://m.youtube.com/channel/UCRQ4FduL9HyTBzX34CDtY4A

sounds interesting! after I have gotten the encoder disc prototype working correctly and tested with larger cameras it would be possible to start prototyping a Leicina or similar style project. My current plan is to first finish the Kinor2m motor project, then to do the prototype encoder disc standalone motor for finessing the speed control stability on higher sampling rate system. Then I will probably adapt my 35mm Soyuz US3N camera for crystal sync because I use the same type of motor with it than the encoder disc test system will use so I can practically just throw the prototype in and fine tune and start shooting film. then it could be possible to maybe adapt some "easier" cameras like NPR and ACL if it does not need too much custom parts. The most challenging step is to try to fit all the needed parts in a small enough space so that they fit inside the existing motor housing without needing an additional box. If someone could live with the additional about palm or usb hard drive sized control box with 5 or 7 pin wire connecting it to the camera body, then it would make adapting very easy because I could even assemble the components by hand on pre drilled proto boards. After that (probably this Autumn or so) it would be possible to start to miniaturize the setup and parts. It may be worth investigating to use hall sensors for rpm feedback on the Leicina motor if it seems more practical than the encoder disc. I would need a full camera with the intended motor replacement for tests but I believe it could be possible to start the project this year or at least the next Spring if it seems financially viable to do.

it is a pretty nice package with great image quality especially for the price. have handled some of the material from it already. I would just hope it had slightly better quality codec which would use the full potential of the sensor. One can still get the traditional XAVC artifacts on the material if underexposing. the new colour profile is nice. much easier to grade by my opinion. One of the annoyances is that Sony messed up the standard metadata order on this model and I had to upgrade to OSX Catalina to get the latest Resolve version working on the computer (took a whole day of work to do. Very counterproductive and unnecessary). All the previous versions of Resolve crashed instantly if you tried to open the FX9 xavc files in them. Totally unnecessary douchebag move by Sony to mess up the standard XAVC files without any apparent reason just to make them incompatible with some programs ?

that sounds doable though because of the size restrictions a different type of Arduino need to be used. or another type of microcontroller which would make the programming a bit more time consuming. it would also necessitate small circuit board and SMD components with full cad design and larger batch manufacturing. I believe something from couple hundred to a thousand board per batch or something like that. probably there would be some brushless motors which could fit the cameras. Sounds completely doable but the price of the modification may cause some restrictions. Probably the best approach would be to pre-sale the modified cameras and then do them in large batch to ensure efficiency. It seems the cameras are something around 100e price range at the moment. I believe the modification would raise the price to couple of hundred euros. Would that be too much for such a camera compared to the 8mm cameras which already have crystal speeds built in?

Thanks ? this is exactly the type of input I am gathering to figure out how to advance with the project and what the end user's needs would be. Another person already asked me about the Eclair motors as well. Seems to be that there is more camera bodies than good motors available so it may be worth it to investigate what kind of solutions could be made for these cameras and if there is a possibility to make the system more standardized and user friendly. The system is in very early prototyping stage ( I started the project in January this year and expect to have the fist working motor done by June) so it will take some time before it is refined enough to be used by other people. ---------------- I tested the re-designed prototype circuit today with the actual Kinor camera. At this stage it is important to do the tests with actual cameras as well and preferably the cameras need to have a dummy film roll inside so that it resembles the real life torque requirements. By today's tests the oscillation becomes slightly stronger when you add more load to the motor which was expected... it is easy to fine tune the motor when it turns freely but when you add the actual film transport to the equation it changes dramatically. That was exactly what I wanted to test. with the real camera and film at 720rpm target the rpm stability was pretty usable at about +10 / -15 range from the target. from the sound of the system it was clear though that I would need a little bit more accurate speed measurement with slightly higher sample rate. This is only specific to the Kinor motor, remember that I use the pilot tone generator of the motor for my speed measurements and it only gives one pulse per revolution from the single generator winding. With the "normal crystal sync setup" where one uses slotted encoder disc for speed measurements the system is much more stable because one gets dozens of measurements per revolution instead of the one in my current test setup. I think I will try to add more accuracy to the speed readings on the Kinor motor by adding another input from the second winding of the pilot tone generator so that I'll get two different speed readings on Arduino which can be compared in the code. I will also test a different approach to the motor speed control when "too high" / "too low" reading is detected by the system. At least with the Kinor motor the motor load generated too much oscillation for my tastes when running at low speeds (this is because the PWM level for "motor power low" needs to be substantially low value so that the speed does not rise too high. But the torque requirements are pretty high even at low speeds so the PWM level for "motor power high" needs to be substantially high to be able to drive the film forward. this generates kind of oscillation where the controller detects lower than target RPM so it gives the "motor power high" command, then the speed rises considerably over the target RPM. the system detects that and gives instantly the "motor power low" command which drops the speed considerably lower than the target RPM and the cycle repeats over and over again. This is what I was talking about earlier when mentioning "fine tuning the PWM values for each RPM" . The current version of the code specifies 6 preset RPM speeds (associated with the corresponding frame rates but the code handles RPM, not fps ) .For each RPM preset I can specify the motor speed "high" and "low" values separately. But the desired settings change based on the specific motor input voltage + torque requirements (they change the response speed/momentum) which is why there cannot be a single setting for all the 6 preset speeds but each one needs to be individually tuned to get the oscillation to the minimal level around the target speed. For example in the free spinning motor tests the fine tuning reduced oscillation in one test from + 30 / - 40 rpm to about +4 / - 3 rpm. The problem is that this is gonna change if there is considerable change in the camera load. With higher sampling rate (using the encoder disc) the tuning is easier because the mechanical parts have less time to react to the individual changes in the motor driving power. The prototype is running at adjustment rates of about 10 to 50 speed adjustments per second whereas with higher rpm sampling rate I could get from 200 to 500 adjustments per second which would probably be stable enough to resemble true crystal sync in best cases. I will test some options of "auto-tuning" the stability in the program code. It will take some time and we'll see how it goes. The feature will improve all speed stability whether the system is "fine-tuned" or not but it is not that simple to write as one could think of. ---------- Long story short, this "motor attitude control" is the reason why this type of system cannot be completely "plug and play". It should be much easier tuned when the sampling rate is higher due to a slotted encoder disc giving much faster and more accurate speed measurement data but the system still needs some fine tuning to work, especially the low speeds. Every person could easily do this by watching a 10min tutorial and reading some documentation (even if the changes need to be made in the code directly) but it might be a small barrier to the people who just want to shoot great stuff and not think about technology too much. ------ One thing I was aiming with the user installable product was that this type of system would be much much easier and faster to repair if there would be something wrong with it. This was also why I started this project in the first place, it would have been easy to just send my Kinor motor to Olex for crystal sync modification or diy adapt my existing Konvas 2m crystal motor to work with it. But I would be totally screwed if the motor would develop problems with it in the middle of the shoot (either send your motor back to Ukraine for repairing or in case of the Konvas motor, try to hunt down a working specimen from eBay which is not overly expensive and works correctly. That can easily take months or more). Instead I wanted a system more similar to an Arduino "shield" where you just have a circuit board with connector for popping in the Arduino and I could just have a spare board and spare Arduino with me as a backup on set so I could replace every part of the system easily and continue shooting in couple of minutes. Or if all my Arduinos would magically be burned or something, I could just go to the nearby electrics store and buy a new one, then use a laptop to upload the program code to it ON SET and continue shooting. I could even show the 2nd AC how to do that, the Arduino IDE (the software used to write, test and upload the code to the controller) is so simple to use that it would take 2 minutes to show them what to do. Or couple of extra minutes and they could tune the values directly in the code when shown what to look for. Watching a tutorial video and reading some documentation would enable them to install the whole system to the camera and troubleshoot it and tune it to their tastes. The reason there is no this type of products commercially available yet is because there is not much demand for this type of custom speed stabilizing systems in other than the very narrow and rare camera motors market so no one has any interest in developing new products in this field. Other industries use different type of solutions for speed control so a system like this is very cinematography specific which is why I don't see a lot of commercial potential in it either (I have a small company here but don't see much commercial value in the project at this point, other than modifying my own cameras to work better on paid projects). One of the ideas I had was that this could make a pretty OK kickstarter project which would pay the developing costs and the beta testers would get working prototypes which would be used to collect user data and help the further modifications of popular cameras like the NPR and the ACL. then the project would probably go open source at some point so that I could concentrate on other projects ( I have lots of them going on all the time, for example couple of film scanner projects etc. ) ? ----- Finding a partner in US who would do modifications would be nice but I don't see real benefit in it commercially compared to another type of expensive sync motor modifications. I own a small company here in Finland which I could use for doing the modification work locally if needed but as said I see this as a user installable / user repairable product which would be customizable to individual needs, even in the middle of the shoot ?

more testing and testing. I updated the input and output electronics completely which made a dramatic improvement to the speed calculations accuracy. the output circuit is pretty OK but I cannot get full speeds with 12V battery so have to do more drawing later on. In the meantime, I changed the code a little just to test what kind of RPM range the trimmer potentiometers can stabilize. I set the lowest rpm preset to 360 rpm and the next were 540, 720, 780, 790 and 920 rpm. (I can't get over 1100 rpm with 12v battery before the output circuit is updated so the 920 was pretty good maximum setpoint) When I tuned the rpm to be as stable as possible at 720 then the 780 was pretty accurate (about 778 - 782 ) as well as the 790 rpm was only off by couple of rpm. The 920 rpm was varying between 910 and 924 . The 540 was about 550 and much more unstable whereas the 360 was very unstable oscillating at around 400 rpm. It seemed that the 360 rpm (6fps framerate) was too optimistic for this particular motor and I have to change the minimum framerates considerably up. So I will probably change the framerate presets to be 12fps (720rpm) , 16fps (960rpm) , 23.976fps (1438.56rpm) , 24.00fps (1400rpm) , 25.00fps (1500rpm) and 32fps (1920rpm). From this test I would say that one could do with one set of trimmer potentiometers if concentrating on the mid range of speeds and can tolerate the high speeds being a little off from target but still stable. However the low speeds are problematic in this regard and I would recommend changing them in the code. Additionally there was not much torque at the very low speeds so it might be wise to just concentrate on the mid range for now or leave the very low speeds completely off and only including the speeds of over about 600 rpm which can be tuned correctly and have enough torque. The great news is that when tuned to 720 rpm the system was able to keep it easily around -4 / +3 rpm on the target and it seemed it could probably be tuned further to about 2 or 3 rpm accuracy especially if the power supply is regulated. Checking the serial data from the Arduino's speed calculations I think that the main reason for this type of rpm variation (it would already be enough stability for sync sound with this kind of much better than 10rpm accuracy) is that there is just not enough pulses for the Arduino to count from because the Kinor motor gives only one pulse per revolution. This means that with the encoder disc the rpm stability would be much much better and I would expect the speed to be at least 1 rpm accurate or in one decimal range when the setup is tuned.

Project update: more prototyping and testing the code updates I made. - the speed selector system works correctly. I use a rotary switch with 6 position to select 6 pre-programmed speeds. - the trimmer potentiometers for manually adjusting the PWM high and PWM low limits work correctly. I will just change one resistor to get full adjustment range. - the analog input circuit still had some problems with Kinor motor under about 400rpm so I will redesign the circuit completely. this is a transistor setup, not the operational amplifier based system which I will assemble later. - the current system is based on Arduino Micro because I will want to reserve the I2C bus in case I will add the display sometime later. The selection of the Micro is beneficial in every other way but there is no cheap Chinese knockoffs of it as far as I have seen. I will use genuine Arduinos anyway so that is not a problem for me :) Still a lot of work to do but I will surely finish the project this year. Some prototype testing I did yesterday for the speed selector switch. I am using the serial monitor and laptop to tune the code and monitor the behavior of the system especially when checking the function of the analog input circuit. The small grey box next to the camera motor is a Chinese tachometer I use for monitoring the motor rpm during the tests, it uses the other winding on the pilot tone generator and is thus completely separate from the Arduino setup.

one huge PITA with the cheaper end LED lights and LED lights in general is that most of them can't tolerate humidity/rain very well. This has caused numerous problems on our last project where LEDs were extensively used. A very low wattage LED light is easy to waterproof with a clear plastic bag if you don't have anything else... but if it has anything usable wattage (like over 20W or so) it generates so much heat that it cannot survive without ventilation which can make it very challenging to protect it from the rain (you cannot block any ventilation holes but the light does not generate enough heat to evaporate the water which gets inside like would happen with the good old Tungsten lights). For example one of the Aputure lights survived bagging without melting but the glue on one of the batteries melt and the battery literally fell to pieces after it had heated enough. I am absolutely sure the light would have melted too if it would have been a longer shoot. And it is pretty ridiculous to need to have a dedicated person with an umbrella just for a small led light ? This is probably not a problem for you but just something to take into account when considering a LED light... most of them cannot tolerate water and they may be challenging to waterproof if they generate any heat

design specs update, added features: - two trimmer potentiometers to easily fine tune the PWM values on the most critical mid range speeds (these are the 23.976, 24.00 and 25.00) . The fine tuning of the system on these speeds can be done with a screwdriver and no need to touch the code at all. The other speeds still need fine tuning to be really stable, especially the low speeds where high torque is generally needed - I will test off-the-shelf slot-type speed sensors to speed up the prototyping process a bit and standardize a critical part. If it works correctly, then a very common eBay sensor part can be used and it does not need preamplifier which makes circuit board designing much easier and would enable the end user to assemble all the mechanical parts of the system - function added to the program code which enables using a encoder disc with the system very easily. Just add the slot count of the disc to the code and it should work out of the box. I have more time for prototyping next month. I will probably make a dedicated test motor for this project with custom diy made encoder disc. this way it is easier to finesse the speed control functions. I will probably use a motor of 10A to 15A power draw range which also helps testing the power electronics of the system.