@SmokeyVW -- DC motors. Knockoff Mabuchis... they're the RF500 type.

OK. I guess you need some sort of phase-locked loop circuit. One motor can free-run and serve as the "clock" to a PLL circuit that controls the other motor. You can probably find a schematic on the web. I'll try looking around a bit.

see http://electronicdesign.com/analog/use-pwm-maintain-motor-speed-and-phase-while-eliminating-loop-filter  -- you would drive "ref in" with a pulse from the other motor using a copy of the circuit in the upper right of their schematic (connect the "PPL out" of the copy to the "ref in" of the original circuit)  

THANK YOU. This is EXACTLY what I needed :)

The article specifies that the optical sensor they're using is a reflective sort. I'm using a more conventional C-shape beam interrupter, probably scavenged. How do I adjust the circuit for that, or is it not necessary to do so?

also see this page:  http://hackaday.com/2015/08/07/logic-noise-4046-voltage-controlled-oscillator-part-one/

That helps with another, very different project, actually, but for this it's a little short on theory. Theory first, /then/ practice ;) otherwise I've no real idea what I'm doing as I go through the motions.

Are you using AC motors to rotate the drums? If so, maybe you don't need to sync them. If the motors are lightly loaded perhaps they would sync up to the mains frequency and naturally remain in sync. (I'm thinking of electric clocks that sync to the line frequency.) 

If that is correct, you would simply need to initially manually slow one of them down slightly to visually sync up the frames. After that, they ought to stay in sync indefinitely.

The drum method was very similar to a Nipkow disc, actually. It's just that the edge of the disc was a tad thicker at the edge, as that's where the light comes through ;)

Remember, though, that the Lsync appears more often than the Fsync -- L is line (horizontal), F is frame (vertical). Across, /then/ down. I don't see the logic in syncing to the (much slower) Fsync signal, when the Lsync is more frequent -- and, therefore, permits better syncing, in terms of both precision and accuracy. Maybe I'm missing something?

...I was thinking this would come down to PLLs, though. I was hoping it wouldn't, actually, because I have absolutely zero understanding of them and how they work and how to work them... hence why I'm basically panhandling for schematics here. I'd personally be more inclined to try and use a 7485 or the like (I suspect I'll be operating mostly within its voltage tolerances) -- but that would make for one very complicated circuit indeed.

If you can tell me how to use the 4046, though -- please use explain-like-I'm-five language with this stuff, since I'm really not kidding when I say I know nothing about PLLs -- I'm wide open. I can handle it, if I know what I'm doing ;)

Yes -- but the same is true in reverse, and if I'm going to discard one sync signal, it's going to be the less-frequently-sent Fsync...

I admittedly did think of that. I'm not sure why I'm even keeping Fsync around, other than that it "feels right" to do that -- which is a rationalization, not a reason. I can shed it if it's not useful...

Two questions for you:

1. Say you only have Fsync. Can you easily recreate Hsync from that?

2. Imagine you only have Hsync. Can you easily recreate Fsync from that?

1. Not really. You can derive an /implied/ Hsync aka Lsync by multiplying Fsync by thirty... but it may or may not match the /real/ one, because you're deriving it from a much slower signal.

2. Yes. Divide the frequency by thirty.

In unrelated news -- I've got some errands coming up at 1pm (it's about noon, here), and I've got to prep for that, so I'll be MIA for a little bit. I'll be back at 3-4pm... I won't be able to reply till I return.

OK, I think we need to take a step back here, and re-examine the scope of the problem. So, another question - one I should have asked much much earlier:

0. What do *you* believe is the *purpose* of sync signals – i.e. what is problem that you think they solve?

I'm home from errands :)

The way the drum system works, is similar to the disc system -- light "parsed" by the drum enters the photosensor on the camera end, such that a lamp in a properly synchronized televisor at the other end emits light in the same pattern.

In more detail -- as each hole in the disc or drum lines up with the photosensor, the light let through is sensed (of course) and a corresponding amplitude signal is transmitted to the receiving televisor. (There's an amplifier in there, but that's not terribly important -- it's just operating as a driver for the televisor's lamp.) The televisor, if the holes are lined up exactly the same way, reproduces the image by varying the brightness of the lamp in response to the signal sent, such that the light is let through the hole in its drum at the exact same position. As the drum spins and the lamp dims and brightens, it reproduces the image as sent.

Synchronization to the /line/ matters -- really, to the /pixel/ -- because you get image wraparound or skew, if the two mechanisms are at all out of sync... however, due to the way the mechanisms work, there's literally no difference between being exactly one whole frame out of sync, and being exactly in sync... if you think about how it works, as I described above, you'll understand pretty quickly why I say that. There's /only/ lines and pixels... (which, of course, means that the Fsync signal is irrelevant -- I should've thought of that a lot sooner!)

As an aside -- there's no real reason to have a rectangular screen here, except for convention and ease of implementation. Remember how the early electronic televisions had /round/ screens? With a televisor, really any shape screen is possible... square, round, oval... heck, you could do a diamond or star or something if you wanted to -- but the camera and the televisor have to match exactly in terms of mechanical structure. Drum size, drum rotation speed, aperature (light-hole) size, and overall screen shape and resolution, those are all mission-critical points that must be identical on both machines, or it won't work.

Not that it matters electronically -- it actually doesn't -- but I may do a 32*32 pixel square screen. Sure, 4:3 is a conventional aspect ration (and square is definitely not!) -- but, for this, you then need to have oblong holes (and nonsquare pixels!) and I really would prefer to not have to bother with that. I don't really have the tools to drill small capsule-shaped holes like that with any real ease... I'd have to drill two holes that overlapped, and smooth them out with an X-Acto afterwards... no thanks.

> if the holes are lined up exactly the same way

OK, you have just described the problem you need to solve.

So, at the start of every frame you need to make sure that:

* the top line of the camera is in the correct position
AND
* the top line of the televisor is in the EXACT SAME POSITION

When both drums are rotating at EXACTLY THE SAME SPEED, then a short time later:

* the second line of the camera will be in the correct position
AND
* the second line of the televisor will be in the exact same position

Since both drums are STILL rotating at exactly the same speed, a short time later:

* the next line of the camera will be in the correct position
AND

* the next line of the televisor  will in the exact same position

... and so on until the end of the frame.

It should be clear that the ONLY things you need to control are:

* The position of both drums at the START of the frame
* The speed of both drums THROUGHOUT the frame

Q: How do you ensure that both drums start each frame in the same place?

A: By generating a pulse every time a drum is at the start of the top line (i.e. once per frame) and ensuring that the pulses of both drums happen at the same time.

Q: How do you ensure that both drums spin at the same speed?

A: By generating a pulse every time a drum is at the start of the top line (i.e. once per frame) and ensuring that the pulses of both drums happen at the same time.

"Hang on!", you say, "You gave the same answer to both questions!"

That's right – if the two drums start in the same place, and always travel at the same speed, then EVERY hole on the ENTIRE drum will always be in the same position as the corresponding hole on the OTHER drum.

Sending a pulse once per FRAME allows you to sync your system.

[Edit: Punctuation for clarity ;]

Fair enough... but sending a pulse every /line/ allows the system to correct itself /within/ each frame... remember that there's inertia to be dealt with here ;) if the system undercorrects one frame and overcorrects on the next, it's /still/ going to be off-kilter... and far, far too imprecisely so to be practical.

Each drum is a roughly eight-inch diameter (I think they're actually 7.5" dia but I'm too lazy to go check) butter cookie tin. Sheet steel, sans cookies and lid. Even assuming that they're properly balanced and perfectly mounted (which, with my skillset, makes for two very questionable assumptions) -- they aren't going to change rotation speeds on a dime. It takes time to spin one up and time to slow it down. I anticipate that the system will be "hunting" most of the time and will take plenty of that time to "settle down" and stay it. That means lots of picture 'jitter' -- but the original televisors did that, too, so I'm willing to live with it.

I'm probably going to do 16*16 resolution for the first televisor/camera, since I've got just the two tins... I really don't like the idea of having half a Tamagotchi's worth of screen, so I may do a later, more capable version with something a bit larger. Sixteen by sixteen is still a 256px screen, though... two hundred and fifty-six holes to drill in each tin! (...or 512 of them --gaah!-- if I go back to the idea of doing two frames per rotation, which would let me balance the drum with a single pulse/signal per frame.)

...tell you what, maybe every line is too often, and (at least to me) every frame is not enough -- what about doing half- or quarter-frame signalling? I'd personally prefer quarter, being who I am -- since, that way, it would be a bit more precise -- but I guess I could live with half-frame. (I was thinking, briefly, that a two-phase clock signal would be even /better/ and would allow treating this thing like a rotary encoder -- but I'm pretty sure that constitutes overthinking the problem, so never mind.) Doing even-divisor fractions of a frame would also aid with the mechanics -- two or four holes, instead of one, balances out the drum more easily, and therefore dampens potential vibrations, which, in turn, reduces bearing and motor stresses, along with picture 'jitter' -- all of which are good.

"Everything should be as simple as possible, but not simpler"

"The best is the enemy of the good".

"If you have a problem – for instance a nineteen stone man in pyjamas trying to beat you into a pulp, the trick is to use this problem to solve itself. If you can trip or throw or deflect him as he hurtles towards you, then the fact that he weighs nineteen stone quickly becomes his worry instead of yours."

In an engineering project, you should be aiming to solve the problem in the most elegant way possible – i.e. getting the maximum return on *your* efforts.

> there's inertia to be dealt with here

> they aren't going to change rotation speeds on a dime.

If true, then this is to your advantage. It means that once they're both spinning at the same speed, their natural inclination is to stay that way – with maybe the occasional nudge to keep them on course.

That "occasional nudge" is the vsync pulse.

If the televisor drum is running too slow, then the camera's vsync will arrive earlier than the televisor's, which means the televisor's motor needs to run a *tiny* bit faster.

If the televisor drum is running too fast, then the camera's vsync will arrive later than the televisor's, which means the televisor's motor needs to run a *tiny* bit slower.

This is the perfect scenario for a self-correcting feedback system.

You don't really have an electronics problem, you have a conceptual problem. You need to think very hard –not about HOW to solve the problem – but WHAT the problem actually is.

Focussing on synchronising the two drums in the SIMPLEST way possible will lead you to an elegant solution, and will very likely give you an "ahah!" moment into the whole principle of PLLs.

Start off with the simplest, least complex, easiest-to-debug solution.

If that works, hurrah, you've saved yourself a massive amount of work. If it's not quite perfect, then make small incremental changes and see whether they actually solve the problem.

Just using a vsync pulse may not work – but you won't know until you try it.

If you try it, and it works, you've saved yourself a whole bunch of work.

If it doesn't work, you have a baseline – a minimum viable product.

It's a working system that isn't ideal – but you can use it to compare against subsequent changes to the design to see whether they are actual improvements.

One last quote:
"“Premature optimisation is the root of all evil”.

Good luck with the project – I look forward to seeing its progress posted here on Lackaday!

"Fair is fair, Fred." A bit lowbrow of a source (Superchicken, specifically the "Laundry Man" episode), but it'll do ;)

I can always add extra sync holes. I have a drill :) and there's no programming to adjust or anything...

Alright... /now/ the trouble is, as stated before, I know jack squat about PLLs. I can't design that circuit. That's actually what I was asking for at the beginning... not so much advice on how to make it work, but a schematic that I could implement without too much trouble, that would do the job.

If the two drums are physically identical and spinning at the same speed with synchronised Fsync signals, wouldn't that mean that their Lsync signal are already synchronised? 

(Analogy: Imagine two drums locked on the same mechanical shaft, driven by a single motor – isn't alignment simply a case of making sure that the top of each drum is in the same position?)

Oh, whoops. See above for my reply because I'm too dumb to see and hit the "reply here" button, lol.

Ah, sorry, my point was:

If you *know* that Lsync is always locked to Fsync, then all you need to send between the camera and viewer is the Fsync!

Since you can explicitly derive the Lsync (because it's hard-coded into both drums), all you then need to do is transmit the Fsync, and synchronise the two drums to that.

Synchronising a pair of signals is a *lot* easier – the complexity is massively reduced, and a single 4046 Phase Locked Loop (PLL) chip could probably do the job :)

I'm willing to bet if you get the Fsyncs synced, and then compare the Hsyncs at either end, you'll find them  astonishingly close – this was the brilliance of the Nipkow disk – it massively reduced the complexity of the problem you're trying to solve :)

Dammit, did it again! See above for reply :(