Jump to content

Making new Crystal Sync electronics for CP16R


Aapo Lettinen

Recommended Posts

  • Premium Member

I finally got a cheap enough CP16R to start working with my own Crystal Sync update for it. 

The original camera has the only available Crystal speed of either 24fps or 25fps depending on the gears used.  All the other speeds are made with a RC oscillator which is not accurate enough for sync sound work and some of the available speed presets are not very practical.

I am going to make a completely new Crystal Sync system for this camera which allows setting ANY crystal speed from about 10fps to about 40fps in 1/1000fps increments. All speeds crystal and accurate. So one can easily set the camera to all the speeds one likes and one can get 23.976fps as well as 24.000, 25.000 and 29.98fps with the same camera. 

I will update work-in-progress videos on YouTube. You can follow my channel A Lettinen  or this thread for updates. 

The first video where I just briefly opened the camera and tested that the motor itself is working correctly and the mechanics are OK.  I will remove all the original circuit boards and speed selector etc. and will build completely new electronics to the camera. So this update is possible for cameras which have broken original boards as long as the motor itself and the mechanical parts are intact.

Part 1: opening the camera and testing the motor and mechanics

  • Like 1
Link to comment
Share on other sites

  • Premium Member
2 hours ago, Phil Rhodes said:

For what it's worth, I have used the lowish-cost TCXO modules from China and found them to be reasonably accurate, certainly accurate enough for a timecode slate or the like.

I like to use basic binary counters and bcd counters when only a couple of easily divided frequencies are needed and if it happens to be beneficial in other ways to. And when a more challenging speed is needed I am using a microcontroller running CTC program based which divides the frequency from the crystal the microcontroller uses for timing, mostly on the hardware level. 

In the case of this CP16R system, I am going to use only microcontroller (ctc) based frequency generation but it makes most sense to use my own software instead of choosing a factory made Chinese module for this. This is because it is easier to build the user interface for the system with minimal parts when I am making everything from ground up. I can eliminate most of the extra parts like additional microcontrollers which communicate with the Chinese module via serial connection. It sounds like it is more work to make everything from ground up but in this case it is beneficial and for me it is even slightly easier than to try to adapt an existing module to work with the system. The frequency generation is pretty easy after all and when building everything by myself I am able to choose all the parts I want to use for every design. Starting from choosing the crystals I will use and in which package every single part comes in :)

Link to comment
Share on other sites

  • Premium Member
11 minutes ago, Phil Rhodes said:

Hi Aapo

I understand what you mean. The TCXO is simply a very low drift clock source for the microcontroller; I've used them with ESP32 and AVR, so these ideas are not mutually exclusive.

 

P

oh I though you meant those serial controlled frequency generation modules. 

I use small-ish smd oscillators in some designs (for example one of the earliest designs was based on the Seiko VG-101JA  2.048MHz oscillator divided by binary counters and a bcd counter to frequencies of 125Hz, 160Hz, 250Hz, 320Hz and 500Hz at the same time and an additional 32kHz signal which is used as a sawtooth wave source of a analog PWM circuit) . Due to packaging options and price I am mostly using tht packaged crystals if a very specific frequency is needed (for example 2.4576MHz) or sometimes smd ones if the system is using microcontroller and ctc for frequency generation so I will just need to have some high frequency like 16MHz to work with. Though I like to use tht crystals for 16MHz as well because they are slightly easier to work with. Most of the other parts like all the resistors and capacitors and most of the microcontrollers are smd.

Link to comment
Share on other sites

  • Premium Member

the issue with most of the tcxo smd oscillators available here is that they are so small that it is challenging to solder them reliably with my tools. By small I mean the whole oscillator being from 2mm to 3.2mm in length and from 1.6mm to 2mm wide with 4 pads to connect to the circuit board. Additionally most models have the operating voltage around 3 to 3.6 volts max. when the 328 or other microcontroller I use needs to run at 5 volts to support the clock frequency of close to 20MHz.  So I have to arrange the around 3 to 3.2V regulator for the oscillator separately and additionally deal with a very small component which is challenging to solder in place (and I need a microscope to verify if it's properly soldered or not) .  So this is why crystals + smd capacitors has been much easier route for me than using smd tcxo oscillators (I have some but no design uses them yet. Some designs use those old Seiko VG-101JA though because one can divide usable frequencies from those directly using only a single binary ripple counter and nothing else)

Link to comment
Share on other sites

  • Premium Member

About the sound recording system I am developing for this camera. I checked the possibilities yesterday and most likely I will adapt the camera's original Auricon magnetic head to optical recording by removing the magnetic sound heads first and then building my own variable density optical head in place of them. The largest challenge is avoiding spill from the light beam to fog the rest of the film in the chamber so I will need to do lots of prototyping and testing.

The main purpose for optical variable density sound is that one would get a scratch audio track which helps syncing when shooting documentary style material. I will use a external digital recorder for the final recording when making my own projects but a scratch audio track enables storing timecode information or a analog scratch track on the film which enables shooting without clapperboard 1-man band style and helps saving film stock. I have couple of documentary projects which would benefit a lot from this in-camera sound feature.

A person who shoots for direct projecting can use the system for recording the final audio track directly on the film in camera. 

Price range of the optical sound recording feature will be under 1k but will need to make the full prototype first to determine the exact details. I will need to make a compensating system which varies the exposure according to the framerate and the sound quality needs to be reasonably good too. 

Link to comment
Share on other sites

  • Premium Member

The TCXOs I've experimented with have actually been pretty huge through-hole devices that have sort of the opposite problem; they're enormous by modern standards! That said I do entirely understand your reticence to get involved with too much SMD soldering; I've always avoided it. Smallest thing I ever attempted was some LED character displays which needed sixteen 0402 LEDs per character and four characters per module. It was grim, and I even ordered the solder paste stencil!

HTB1cLiTe8Cw3KVjSZFl763JkFXa4.png_.webp

Temperature-compensated module not absolutely required of course, but if you're going to specifically do a crystal sync module for a camera, I'd say do it.

As to the variable density LED sound exposure, sounds good, but I'd expect lots of experimentation getting things like pre-emphasis right. Wouldn't most people rather use that area for picture if it's in any sense possible?

I might consider doing something that could expose timecode or some other slating information into the first frame of a take.

Link to comment
Share on other sites

  • Premium Member
1 hour ago, Phil Rhodes said:

The TCXOs I've experimented with have actually been pretty huge through-hole devices that have sort of the opposite problem; they're enormous by modern standards! That said I do entirely understand your reticence to get involved with too much SMD soldering; I've always avoided it. Smallest thing I ever attempted was some LED character displays which needed sixteen 0402 LEDs per character and four characters per module. It was grim, and I even ordered the solder paste stencil!

 

Temperature-compensated module not absolutely required of course, but if you're going to specifically do a crystal sync module for a camera, I'd say do it.

As to the variable density LED sound exposure, sounds good, but I'd expect lots of experimentation getting things like pre-emphasis right. Wouldn't most people rather use that area for picture if it's in any sense possible?

I might consider doing something that could expose timecode or some other slating information into the first frame of a take.

I actually like SMD soldering. it depends on what kind of footprints you have used for the parts... much nicer if they are "handsoldering" style with slightly longer pads so that one can take advantage of the surface tension of the solder. but most of the oscillator parts are not really meant for hand soldering and are a pain to work with by my opinion.

All the normal crystals I have tested have been able to keep frequency accuracy of the camera accurate by at least 4 decimals so the accuracy of the crystal is better than the mechanical accuracy of an old camera system even if it's properly serviced. So in the most cases it is not necessary to use really accurate oscillators because you won't see any difference at all. Maybe if freezing the camera to -30°C or -40°C but most of the cameras don't work in that range anyway and one rarely sees that kind of conditions anywhere where sync sound shooting is actually needed (too cold for actors and crew)

Link to comment
Share on other sites

Why not a microcontroller with a TCXO reference? The PLL some have will give amazing clock stability and putting an absolute encoder onto the motor will let you know exact speed and position, so you could stop it exactly at a desired point and use a basic closed loop control to where it almost would not matter what is happening, since you can use a basic software feedback loop to hold a desired speed. It'd be easy to also then report errors such as underspeed, no movement, no feedback, or whatever you want.

Even a GPS module for GPS referenced timing isn't a very expensive part and would give extremely good stability at the cost of being possibly overkill for a reference but would be handy if deriving timecode from there.

Link to comment
Share on other sites

  • Premium Member
4 minutes ago, Selinica Harbinger said:

Even a GPS module for GPS referenced timing isn't a very expensive part and would give extremely good stability at the cost of being possibly overkill for a reference but would be handy if deriving timecode from there.

I actually pondered doing that for the timecode project, but I wanted something that'd work underground or in a big steel-framed building. That's why I went with the TCXO.

Link to comment
Share on other sites

  • Premium Member

By my opinion it is too much hassle for very little real benefit (at normal temperatures even the lowest quality normal crystals can generate a reference signal which is accurate by 4 decimals and the camera mechanics itself or the phase locking algorithm is not capable of doing any better than 3 decimals. The 4 decimal accuracy is barely detectable by instruments and one would definitely not see the difference in the final image. keep also in mind that the 16-bit ctc used for frequency generation does not divide all frequencies at exact accuracy and the 4th decimal is often a little off for this reason. that can't really be helped because it is mathematically impossible to divide all the frequencies by 5 or 6 decimal accuracy) . I can test how the current crystals behave in high and low temperatures but I am pretty sceptical that a extremely stable and accurate clock is really needed for this application (or atomic clock like the gps referenced system) . It is a marketing point which sounds nice but is it actually more useful? most likely not.

------------

It is, however, possible to wire a tcxo oscillator afterwards in place of the normal crystal if someone really wants it. I will need to add extra components anyway to make the tcxo work correctly with the 328 so I could just make a small additional circuit board which has its own power regulator and other parts, the oscillator and which outputs its signal to the same clock input pin of the controller than a normal crystal would. Then I could outsource the problem of the microscopic parts to the additional circuit board so it is less risky and more fun to assemble the system and I could use different style of parts according to the customer's needs.

Link to comment
Share on other sites

  • Premium Member
12 minutes ago, aapo lettinen said:

keep also in mind that the 16-bit ctc used for frequency generation does not divide all frequencies at exact accuracy and the 4th decimal is often a little off for this reason. that can't really be helped because it is mathematically impossible to divide all the frequencies by 5 or 6 decimal accuracy

I have a nice little Excel sheet which I use to verify the frequency calculations if needed. Here it is used to calculate the CTC countermatch value between 1/10th frame increments. As you can see one can't get 5 decimal accuracy for every and all speeds, that is mathematically impossible 

50547057972_b14d2f44ea_b.jpg

Link to comment
Share on other sites

  • 4 weeks later...
  • Premium Member

Today I removed the main board and some other electronics from my CP16R camera body and briefly tested how a simple DIY video tap could be mounted as well. I decided to remove the original optical sensor from the camera as well because it is easiest for me to just install a simple factory made sensor in place of it. I am trying to use as few original electrical parts as possible so that the update would be compatible with as many different cameras as possible whether the original electronics being in usable condition or not.

50629327537_c34517afe7_b.jpg

50629327752_00f6fa9860_b.jpg

I will need to do a lot of testing with the video tap system to find the best working camera-lens combination. But it is very easy to work with it because the CP16R camera does not need optical modifications for the tap... just correct video camera + lens combination and a suitable support for it. The camera I am using for tests is a Chinese microscope camera which costs about 40 bucks or so. One would probably want a better quality camera to get a usable image in normal lighting conditions. 

50628485128_8ed06f56f1_h.jpg

I will continue with the original plan of making a new Crystal motor control system which has any speed selectable from 10fps to 40fps in 1/1000th fps increments. No display is necessary. I will try to get the shutter parking working and I will test if the 200ft/400ft footage warning could be easily added as well :)  

  • Like 1
Link to comment
Share on other sites

  • Premium Member

As a side note, my camera had pretty OK looking main circuit board from the topside but when I removed it, it was revealed that about half of the board was heavily corroded from the underside and it was totally unusable. 

So no wonder people say these cameras often have broken electronics. I see that this Crystal update is thus a very necessary modification to return the old cameras back to service. 

Mechanically these cameras are pretty great. I have used Arriflex 16BL in the past and from the outside it is somewhat similar looking system but the CP16R is clearly a way better camera, especially the noise levels and the lens mount are way way better. And the video tap installation is very easy because it needs very little modifications to install.

I am probably going to update the lens mount to B4 mount because I have a great Fujinon zoom I can use with it. It seems to be pretty hard to find any native CP16 mount lenses or lens adapters from web but the B4 mount will be a much better choice for me anyway and it is way less machining work than fitting a PL mount to this camera model. 

For the viewfinder, I don't know. The original finders are pretty expensive on eBay so it is possible that I could even make my own viewfinder system to it :D 

 

Link to comment
Share on other sites

A few years ago, a guy in the US developed a modern electronic replacement for the motor controller system and also a replacement operator panel for the rear. They were to be marketed but it seems the project faded. 

The memory battery for the footage counter is the nemesis of the CP16R electronics. The battery leaks. Chemical gets into the crystal unit and also erodes the tracks on the PCB. 

Take care that the little teeth from a damaged belt do not get into any of the gears. 

Link to comment
Share on other sites

  • Premium Member
51 minutes ago, Robert Hart said:

A few years ago, a guy in the US developed a modern electronic replacement for the motor controller system and also a replacement operator panel for the rear. They were to be marketed but it seems the project faded. 

The memory battery for the footage counter is the nemesis of the CP16R electronics. The battery leaks. Chemical gets into the crystal unit and also erodes the tracks on the PCB. 

Take care that the little teeth from a damaged belt do not get into any of the gears. 

Thanks! I am aware of that previous development. It is sad that the project faded out. The working principle was slightly different than on my system, I am having real crystal frequency reference signal generated within the system because it is then easier to design and manufacture the system in manageable size modules to make it customisable and easy enough to manufacture (after the programs are complete. they need lots of physical testing to be finessed which is why it is so challenging to make these systems in the first place.... there is nothing factory made you could use. or factory made stuff would at least make the system very bulky and lacking features so you really need to build everything by yourself.

 

My camera had the battery leak problem too and the electrolyte had destroyed the back side circuit board tracks. So one would had had to make a new circuitboard by oneself if wanting to use the original electronics. 

The original Crystal unit itself is actually very simple construction and it is possible to make another one from off the shelf parts if needed. It should cost you about 4 or 5 dollars to get new parts for it... it is basically the crystal itself, couple of resistors and capacitors  and a binary ripple counter which both lowers the frequency of the 3.6MHz crystal to the desired level of 300Hz and 38kHz and ups the voltage of the signal to 10V level to be compatible with the other system. (I think it was CD4020 binary counter. I can check it if you want, there is schematics of the original system in the user manual) .  Alternatively you could just make a new crystal reference from scratch as long as it has the two needed output frequencies and outputs in 10V level. 

IF the hybrid integrated circuits on the CP16R board would get damaged then it would be much more serious. They contain lots of logic gates to mainly run the phase comparison logic. There is, however, their contents listed in the schematics as well so one could just make a similar functioning design from the standard logic gates which are available today. OR one could program a microcontroller or a PLD to do the same task.

Repairing the heavily damaged old electronics would have been more work for me than designing and manufacturing a completely new Crystal Sync system because I already have most of the components and programs designed for other camera models and will just need to tweak and adapt them to work with the CP16R.

Link to comment
Share on other sites

Wow this is a throwback. Thanks to Robert Hart for bringing this to my attention.

Reading through all you wrote Aapo I gotta say it's spot on, and it brings me back so hard. I went through the options you listed above, while deciding on the approach I would take. On my CP-16 the issue was the hybrid chips, but again you are right that they could be replaced either with Jelly Bean discrete logic gates, an FPGLA or you can make an incredibly simple program to replicate the function in software...but you don't get any cool new features.

I talked to a guy at Alan Gordon who knew the original Electronics Engineer who founded Cinema Products, and according to him he encouraged the guy to build something new. That is where I found out it was an adaptation of another camera's movement with new electronics (an eclair I think?) He also tipped me off to the fact the hardware might be able to do more than 30fps the original camera could do. I can't find the original development notes, but I think I recall the limit was not the mechanical hardware, but the control electronics didn't have the fineness to do off-speed. I think it used a more powerful motor than would be needed today, in order to be responsive enough with it's very simple control loop. I think I was exploiting that by having more finely tuned software to be able to drive it faster than advertised. (these are all 10 year old memories-take it with a grain of salt)

I remember distinctly those schematics, and just how detailed everything was. I wonder if I could redraw them from memory-I poured over them. I think it was a user manual, but it might have been a repair manual. Either way it was incredibly explicit and made it very easy to at least unwind how each signal worked, and its relevance in the overall system. Thinking of that makes me wish Apple would release manuals as detailed as that.

On 11/28/2020 at 10:43 AM, aapo lettinen said:

The working principle was slightly different than on my system, I am having real crystal frequency reference signal generated within the system because it is then easier to design and manufacture the system

I would argue our systems in this regard are actually very similar-the clock driving the microcontroller in my system was a crystal.  In the video I posted you can see it was a generic crystal, since that is what I had on hand for prototyping, but the final design included a temperature compensated oscillator. My crystal only acted as the CPU clock, and from there all timing was derived through software. Perhaps that is the difference your saying, maybe you have a separate clock to act as reference on an input comparator hardware, leaving your CPU clock to be an internal RC circuit or something. I am sure on many levels the solution is somewhat similar though.

I wish I could offer you some guidance, but these days I'm not sure my code would be any help. I took a look at the latest version I could find on my computer and I was definitely doing some creative things to make up for the slow 8 bit processor. If I remember right it was an 18F series chip from microchip, but I could be wrong. I wrote everything in assembly, and I didn't have the power to do floating point math to implement a proper PID algorithm. I could add and subtract 32 bit unsigned numbers and that is it. Still I could see my approach was kind of a meld between what the original CP-16 hardware did, and what a PID loop would do...albeit implemented in a way that worked well with the limits of the CPUs of the time.

These days for the same price or less it is nothing less than astounding what you can do. Manufacturers now include very advanced tooling that would have cost 10K or more back in 2010-all for free. For less than $1 you can get an arm-cortex level processor with a 32 bit data bus and lots of flash memory, lots of ram, internet connectivity, floating point co-processor, etc. Stack Overflow had just been started when I worked on the CP-16 project, but it was just a shadow of what it is today. Things have changed quite a bit.

Please update us often on this-I am watching this space with great interest. Also feel free to reach out if there is anything I can do to help, I am sure you've got everything you need, it seems your well down this path. If there is something I can do I would be happy to help.

Good Luck!

 

As a epitaph of sorts for my project-that fell off because the weak economy made it difficult to raise money, especially considering the sudden rise of affordable quality HD cameras. I don't recall the exact impetus for switching gears. I do know the few pre-orders I had built up quickly dropped off, and not because I hadn't released-at least I don't think. I recall a few telling me they decided to shoot less film around 2010. To this day I still get an email every few months asking about it, to inquire if I have any left to sell.

I still have my CP-16 in storage somewhere with the old prototype still attached to it. In fact in my electronics rack near my desk I still have my original CP-16 board and a few odds and ends. I think after that project I came up with a voltmeter that would automatically detect phase and a really cool idea for controlling lights on a set.

After that I moved from Alaska to LA, switched jobs from reality camera op to gaffer. I also founded a startup with some fellow Alaskans that focused on drone safety-that startup you can actually buy product from today, and you should if you have a drone. Now I'm off that startup I am back in LA gaffing-mostly commercials and music videos. Film tech-wise I might have something new in the works coming soon....Hit me up if your a Gaffer or a board op in LA!

Best of luck, I really want to see your success, and again feel free to reach out for any help.

  • Like 1
Link to comment
Share on other sites

  • Premium Member
45 minutes ago, Michael Collier said:

Wow this is a throwback. Thanks to Robert Hart for bringing this to my attention.

Reading through all you wrote Aapo I gotta say it's spot on, and it brings me back so hard. I went through the options you listed above, while deciding on the approach I would take. On my CP-16 the issue was the hybrid chips, but again you are right that they could be replaced either with Jelly Bean discrete logic gates, an FPGLA or you can make an incredibly simple program to replicate the function in software...but you don't get any cool new features.

I talked to a guy at Alan Gordon who knew the original Electronics Engineer who founded Cinema Products, and according to him he encouraged the guy to build something new. That is where I found out it was an adaptation of another camera's movement with new electronics (an eclair I think?) He also tipped me off to the fact the hardware might be able to do more than 30fps the original camera could do. I can't find the original development notes, but I think I recall the limit was not the mechanical hardware, but the control electronics didn't have the fineness to do off-speed. I think it used a more powerful motor than would be needed today, in order to be responsive enough with it's very simple control loop. I think I was exploiting that by having more finely tuned software to be able to drive it faster than advertised. (these are all 10 year old memories-take it with a grain of salt)

I remember distinctly those schematics, and just how detailed everything was. I wonder if I could redraw them from memory-I poured over them. I think it was a user manual, but it might have been a repair manual. Either way it was incredibly explicit and made it very easy to at least unwind how each signal worked, and its relevance in the overall system. Thinking of that makes me wish Apple would release manuals as detailed as that.

I would argue our systems in this regard are actually very similar-the clock driving the microcontroller in my system was a crystal.  In the video I posted you can see it was a generic crystal, since that is what I had on hand for prototyping, but the final design included a temperature compensated oscillator. My crystal only acted as the CPU clock, and from there all timing was derived through software. Perhaps that is the difference your saying, maybe you have a separate clock to act as reference on an input comparator hardware, leaving your CPU clock to be an internal RC circuit or something. I am sure on many levels the solution is somewhat similar though.

I wish I could offer you some guidance, but these days I'm not sure my code would be any help. I took a look at the latest version I could find on my computer and I was definitely doing some creative things to make up for the slow 8 bit processor. If I remember right it was an 18F series chip from microchip, but I could be wrong. I wrote everything in assembly, and I didn't have the power to do floating point math to implement a proper PID algorithm. I could add and subtract 32 bit unsigned numbers and that is it. Still I could see my approach was kind of a meld between what the original CP-16 hardware did, and what a PID loop would do...albeit implemented in a way that worked well with the limits of the CPUs of the time.

These days for the same price or less it is nothing less than astounding what you can do. Manufacturers now include very advanced tooling that would have cost 10K or more back in 2010-all for free. For less than $1 you can get an arm-cortex level processor with a 32 bit data bus and lots of flash memory, lots of ram, internet connectivity, floating point co-processor, etc. Stack Overflow had just been started when I worked on the CP-16 project, but it was just a shadow of what it is today. Things have changed quite a bit.

Please update us often on this-I am watching this space with great interest. Also feel free to reach out if there is anything I can do to help, I am sure you've got everything you need, it seems your well down this path. If there is something I can do I would be happy to help.

Good Luck!

 

As a epitaph of sorts for my project-that fell off because the weak economy made it difficult to raise money, especially considering the sudden rise of affordable quality HD cameras. I don't recall the exact impetus for switching gears. I do know the few pre-orders I had built up quickly dropped off, and not because I hadn't released-at least I don't think. I recall a few telling me they decided to shoot less film around 2010. To this day I still get an email every few months asking about it, to inquire if I have any left to sell.

I still have my CP-16 in storage somewhere with the old prototype still attached to it. In fact in my electronics rack near my desk I still have my original CP-16 board and a few odds and ends. I think after that project I came up with a voltmeter that would automatically detect phase and a really cool idea for controlling lights on a set.

After that I moved from Alaska to LA, switched jobs from reality camera op to gaffer. I also founded a startup with some fellow Alaskans that focused on drone safety-that startup you can actually buy product from today, and you should if you have a drone. Now I'm off that startup I am back in LA gaffing-mostly commercials and music videos. Film tech-wise I might have something new in the works coming soon....Hit me up if your a Gaffer or a board op in LA!

Best of luck, I really want to see your success, and again feel free to reach out for any help.

Glad to hear that you still around and working on electronics stuff! 

I understood from your original thread that you used ctc to generate in-chip "crystal reference timing signal" which was stored in variables and compared to the motor signal within the same chip. So that the motor control microcontroller would both generate the timing signal and compare it internally without needing to feed the timing reference outside of the controller. 

I am using the approach of making every part of the system a separate block so that it is easier to combine these "standard blocks" to make hybrid systems for different applications. This is why I am normally using one microcontroller to generate a reference frequency signal in 5V square wave and another controller is used to compare that to the motor signal and to adjust the motor power. This has the advantage that you can combine traditional oscillator-divider setups and microcontroller ctc based frequency generation to the same system and make different style of speed selector systems easily. Additionally it reduces the load to a single microcontroller so that one can get higher loop running speeds if needed. The disadvantage of the approach is that you will need multiple microcontrollers which are luckily cheap to purchase but can make the circuit board a bit larger. Writing the software is a bit easier because you will get some parts of the system finished earlier and will then just need to concentrate on shorter and easier codes to make the last adjustments without needing to worry that the final adjustments would affect the other parts of the system. 

 

The CP16 and CP16R are based on the Auricon film movement. In some later Auricons the movement is visually exactly similar than in CP16R, it even uses the same magnetic head assembly https://www.ebay.com/itm/Bach-Auricon-Sound-On-Film-16mm-Recorder-Camera-Vintage/193155848680?hash=item2cf8fc59e8:g:ccgAAOSwIBJeXDC7  

I am using Atmega and Attiny controllers in the design so the PIC programs would not work on them. I am probably going to implement PIC controllers in some further designs because they can have higher clock speeds for otherwise similarly functioning part. 

 

One of the serious issues with my crystal sync projects is that I am constantly running out of developing budget and I have lots of other stuff to use the money for as well so it is challenging to find motivation to continue at times. I have underwater stuff in development as well and could use some new lenses too so it can be depressing to throw money in basic electronic components when you could use it for film scanning costs or some other stuff ?

 

The schematics of the CP16/16R are in the user/maintenance manual. A forum member sent me copies of them a year ago and they helped developing the first Crystal prototype for another type of camera. the working principle of the control loop was explained pretty clearly which is very rare in any user manual. 

Link to comment
Share on other sites

11 minutes ago, aapo lettinen said:

Glad to hear that you still around and working on electronics stuff! 

I understood from your original thread that you used ctc to generate in-chip "crystal reference timing signal" which was stored in variables and compared to the motor signal within the same chip. So that the motor control microcontroller would both generate the timing signal and compare it internally without needing to feed the timing reference outside of the controller. 

I am using the approach of making every part of the system a separate block so that it is easier to combine these "standard blocks" to make hybrid systems for different applications. This is why I am normally using one microcontroller to generate a reference frequency signal in 5V square wave and another controller is used to compare that to the motor signal and to adjust the motor power.

Ok, I see where you're going. That is a difference from my system. I am not familiar with the CTC acronym, but I am sure I know the concept. My system was entirely software driven. When you started the motor there was a grace period to get up to speed (or close to it), and a special control routine to "soft start" the motor. Then an internal timer would start and update an estimate of what time the next optical interrupt would come. It would also create a timer based interrupt to keep that time. Working in assembly meant I could effectively count the clock cycles required for each interrupt, and what would happen if both came in at the same time. That allowed me to verify the max error possible for each scenario. Of course with much faster processors with multiple hardware timers, cycle counting wouldn't be necessary.

So when a new timing pulse came in it would do some math to see if (1) the motor was running slow or fast - from the starting point and not the last interrupt. (2) it would determine if the motor was trending closer or farther away from the target position. A variable I called "sensitivity" would scale the trend which would then be integrated into the motor position error. If it was trending farther away and the error was high it would step up the power by more than it would if it was trending away but very close to the target position. If it was trending toward it wouldn't increase the power at all. This meant that each frame would be on time, and errors would not integrate over time. So a 24.001 fps error doesn't become an extra frame after 1000 seconds. That also made tracking footage usage and shutter parking easy - although if I remember right, I think there's an optical sensor for shutter parking.

If you are on Arduino stuff, and it sounds like you may be from the 328 you mentioned, I would recommend looking into Atmels products outside of that ecosystem, since you're familiar with their chips already. If you're using Arduino code, there is a way to import sketches as a library, and the debugging tools are much much more powerful.  Atmel Studio is based on Microsoft's Visual Studio, so you basically get to walk into an IDE that cost billions of dollars to develop and is free to download. You can use development boards with built in programmers/debuggers that feel very similar to Arduino, but give you more power and and debugging tools. Other mfg's like STM have similar tools. I think you can also program Arduino's with Atmel Studio, though I've never tried personally.

You may be able to combine two controllers into one-I have found in times where multiple controllers necessary that a lot of work is needed to handle errors between the two. Especially if there are two, if there is an error, who is the "base truth" and how do you recover from that error. Something to consider, either way I'm sure you'll skin that cat.

31 minutes ago, aapo lettinen said:

One of the serious issues with my crystal sync projects is that I am constantly running out of developing budget and I have lots of other stuff to use the money for as well so it is challenging to find motivation to continue at times.

 

I totally get that, especially when you're bootstrapping. There are lots of ways to make even very sophisticated development cheap these days. Look into JLPCB for very cheap prototypes. Sounds like you're already skilled at SMT which is very useful. My biggest expense was film, development and telecine, which unfortunately is unavoidable. You gotta prove the thing is running at the right speed and the end goal of on-speed film is achieved. One tool I found very useful was to make a tach light. The optical encoder has a dot painted on it, so if your tach runs on speed, you can see visually what sort of errors you get. When I started the motor could be off by as much as 360 degrees, which would be stepped down by gearing to result in (I think) 0.4 frame error - which was unnacceptable. By the end you can see in my video it's maybe 20 degrees max cumulative error (I think 0.2 frames), which is more than acceptable. Sometimes those visual indicators are more powerful than that same data in a spreadsheet. It gives you a feel for how the motor responds.  I could lean on the main gear and see how it would accelerate the motor to keep proper time. Even on my film tests I would break out a variable into an LED to see how the system was performing in real time.

But you have to keep going. Even if this project doesn't form the way you hope it does, it will lead to something down the road, and you'll have new skills. I felt I developed as a programmer, and my logic skills improved which are also useful as a filmmaker. If it does work you'll have all of that and a pretty nifty camera to boot.

Link to comment
Share on other sites

Also if you're not already, subscribe to the EEVBLOG on youtube. I love that Australian bastard and hope to meet him one day. He makes complex things digestible and interesting. There are lots of others like him that you should subscribe to, but I find him to be both very knowledgeable and a good teacher.

Link to comment
Share on other sites

  • Premium Member
27 minutes ago, Michael Collier said:

Also if you're not already, subscribe to the EEVBLOG on youtube. I love that Australian bastard and hope to meet him one day. He makes complex things digestible and interesting. There are lots of others like him that you should subscribe to, but I find him to be both very knowledgeable and a good teacher.

He knows roughly what he's doing but it's the constant excitability I can't deal with!

Link to comment
Share on other sites

The excitability is what I love most. It's like if Bill Nye after "Bill Nye the Science Guy" did a show like "Bill Nye the Engineering Guy".  I loved the former, but the later would take that enthusiasm and get closer to his discipline as a scientist and could have been way more interesting. It feels more personal and free form, with a joy that's infectious. I just wish he did more applied theory and less mailbag.

Link to comment
Share on other sites

  • Premium Member
On 12/4/2020 at 10:14 AM, Michael Collier said:

If you are on Arduino stuff, and it sounds like you may be from the 328 you mentioned, I would recommend looking into Atmels products outside of that ecosystem, since you're familiar with their chips already. If you're using Arduino code, there is a way to import sketches as a library, and the debugging tools are much much more powerful.  Atmel Studio is based on Microsoft's Visual Studio, so you basically get to walk into an IDE that cost billions of dollars to develop and is free to download. You can use development boards with built in programmers/debuggers that feel very similar to Arduino, but give you more power and and debugging tools. Other mfg's like STM have similar tools. I think you can also program Arduino's with Atmel Studio, though I've never tried personally.

You may be able to combine two controllers into one-I have found in times where multiple controllers necessary that a lot of work is needed to handle errors between the two. Especially if there are two, if there is an error, who is the "base truth" and how do you recover from that error. Something to consider, either way I'm sure you'll skin that cat.

I am only using Arduino IDE for certain programs, especially when doing display functions. it is faster for me to work this way when making complicated stuff which needs to be customised quickly.

I am not using actual Arduino hardware at all, even if using the Arduino IDE for programming I am only using bare microcontrollers for the actual devices... programming them on breadboard if DIP packaged ones or using clamps if using SMD parts. and using a separate ISP programmer so no Arduinos used as ISP either (I found the UNO being unreliable in this use so I just purchased a cheap separate programmer for that use. it can be used with other IDEs as well)

So for example with one of the current projects I am running display functions and other user interface on Atmega 328PU but it is a bare DIP packaged controller and not any Arduino hardware used even when it is programmed using Arduino IDE to make it very easy to customise the user interface software. There is no sense to try to fit actual Arduinos inside cameras, they make the system very bulky and awkward even if using the smallest ones they sell. So the best approach is to just get bare microcontrollers in whichever package is the most suitable and then program them with the software most practical for that use. For display functions I have found that the Arduino IDE is useful because it is very fast to work with on that specific application (fast to write one-off customised programs efficiently as long as the memory usage is not an issue) and for other stuff I am happy to use other programs if needed. It is just about finding the best working  tools for the specific application... one needs to improvise continuously to find the best solutions

50690535151_42547d684d_h.jpg

For most uses I am using Attiny85 and Attiny84 at the moment and just starting to migrate to PIC18 family to replace some of the Attiny stuff on uses where more standardised software can be used with less frequent changes and higher clock speeds are useful. Like I mentioned previously it is beneficial in some applications to divide the software to smaller chunks which are run by separate microcontrollers so that one can finish one part of the software (for example the phase lock and motor control code) and then upload it to for example attiny85 or attiny84 and flash 20 or 30 of them on single run to make enough spares to last couple of months. Then you can archive that program and concentrate on for example display functions and every time the "motor control software v18.4" is needed you can just take one of those Attiny controllers from storage and use it as is without needing to upload the software again to get one single component working. One way of standardising workflow (has the additional benefit that it is easier to find software glitches this way and it is way easier to get the system working reliably. For example the lcd display communication via i2c bus cannot mess up the phase locking algorithm or the reference crystal frequency generation because the display is run on a separate microcontroller and the motor controller is separate microcontroller as well)

 

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