Missing sync pulse and the club standard --- Why?

Forum for discussion of narrow-bandwidth mechanical television

Moderators: Steve Anderson, Dave Moll, Andrew Davie

Postby AncientBrit » Wed Jun 20, 2007 11:30 pm

There's always this device that interfaces between USB and TTL RS232

Also ftdi do USB interfacing to memory cards.

Not had time to research further.

(Hope this embedded link works)


http://www.ftdichip.com/Products/EvaluationKits/UM232R.htm


Graham
AncientBrit
Green padded cells are quite homely.
 
Posts: 858
Joined: Mon Mar 26, 2007 10:15 pm
Location: Billericay, UK

Postby gary » Thu Jun 21, 2007 12:12 am

AncientBrit wrote:There's always this device that interfaces between USB and TTL RS232

Also ftdi do USB interfacing to memory cards.

Not had time to research further.

(Hope this embedded link works)


http://www.ftdichip.com/Products/EvaluationKits/UM232R.htm


Graham


I have one of these (or one similar) but haven't got around to playing with it yet. I might wander out to the shed tomorrow and check it out...
User avatar
gary
"Fester! Don't do that to 'Thing'"
 
Posts: 2303
Joined: Sat Jan 27, 2007 11:29 am
Location: Bundanoon, Australia

Postby Klaas Robers » Thu Jun 21, 2007 8:50 am

It looks as if the subject faded away from sync to computers.....

The sync is / was needed if you record NBTV video onto compact cassettes or even reel to reel recorders. You never know which speed they run. So a CCIR-like sync was not at all a bad idea in the time that the word computer was very uncommon and digital sound was impossible to think about.

With a running video and a synchronised Nipkow disc you need no frame sync, after you synchronised the frame by hand. The Baird type 30 line monitors still work that way. Even cathode ray tube monitors don't need it, as the frame was alligned at just above 30 lines and synced by the 30th line pulse.

Then we wanted to have an indication of the beginning of a new frame, or the end of a past frame, which is indeed the same. The aim was not to spoil any video information, so a longer sync pulse, like CCIR does, was not an option. Then the missing sync pulse was suggested and accepted, although the knowlegde that it was missing is coming afterwards, somewhere during line 1. But this is not a problem as you are running on some sort of flywheel.

My monitor syncs in this way:
- The disc gives a frame pulse too, which should coïncide with line 1.
- When the two frame pulses are not almost coïnciding the disc is running without sync.
- When the video frame pulse leads, the disc is speeded up slightly
- When the video frame pulse lags, the disc is slowed down slightly
- When both coïncide almost the disc speed is "nominal" and line sync is applied.
To be clear: the disc has a nominal speed, set by hand, in which the frame is almost stable. At this speed the sync circuit can be connected. The other two speeds are slightly higher and slightly lower. Graham would program a pic for it, I did it in discrete logic.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1529
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Postby ac7zl » Thu Jun 21, 2007 10:20 am

It seems that the standard missing-pulse-for-line-1 scheme requires that everything be running close to sync to start with.

My thought was that a missing pulse prior to a REAL pulse denoting start of frame is a more robust expression of both the the phase of the video and the position of the wheel.

Perhaps I am over-engineering here, but ideally, I want my circuity to be able to lock the wheel to the reference source over wide ranges of frequency. Why? This allows for significant variations in frame speed in the source material, permits intelligent management of motor speed from the moment it is first energized to the moment it accomplishes sync, and in a broader sense, allows for experimentation with widely varying frame rates without having to readjust pots or change capacitor values in a bunch of one-shots.

Pete


Klaas Robers wrote:It looks as if the subject faded away from sync to computers.....

The sync is / was needed if you record NBTV video onto compact cassettes or even reel to reel recorders. You never know which speed they run. So a CCIR-like sync was not at all a bad idea in the time that the word computer was very uncommon and digital sound was impossible to think about.

With a running video and a synchronised Nipkow disc you need no frame sync, after you synchronised the frame by hand. The Baird type 30 line monitors still work that way. Even cathode ray tube monitors don't need it, as the frame was alligned at just above 30 lines and synced by the 30th line pulse.

Then we wanted to have an indication of the beginning of a new frame, or the end of a past frame, which is indeed the same. The aim was not to spoil any video information, so a longer sync pulse, like CCIR does, was not an option. Then the missing sync pulse was suggested and accepted, although the knowlegde that it was missing is coming afterwards, somewhere during line 1. But this is not a problem as you are running on some sort of flywheel.

My monitor syncs in this way:
- The disc gives a frame pulse too, which should coïncide with line 1.
- When the two frame pulses are not almost coïnciding the disc is running without sync.
- When the video frame pulse leads, the disc is speeded up slightly
- When the video frame pulse lags, the disc is slowed down slightly
- When both coïncide almost the disc speed is "nominal" and line sync is applied.
To be clear: the disc has a nominal speed, set by hand, in which the frame is almost stable. At this speed the sync circuit can be connected. The other two speeds are slightly higher and slightly lower. Graham would program a pic for it, I did it in discrete logic.
User avatar
ac7zl
Mad Scientist
 
Posts: 62
Joined: Thu Feb 01, 2007 5:04 am
Location: Tucson, Arizona, U.S.A.

Tangental thinking.

Postby Steve Anderson » Thu Jun 21, 2007 1:07 pm

Klaas Robers wrote:It looks as if the subject faded away from sync to computers.....


Yes, it's interesting how threads go off on a tangent, I feel partly to blame for that!

Yes, the missing pulse is a tricky little fellow, it's like missing the 10:30 bus. You arrive at the bus-stop at 10:25, at 10:30 you check your watch, "Hmm, I'll give it a while." At 10:40 you decide "That bus isn't coming." and go off and make alternative travel arrangements, but you're already running late.

It's an after-the-event situation. What I had considered was a compatable frame identifier, where the missing pulse is put in a burst of (say) 20kHz between black and white levels. It's most unlikely that the 'real' video signal would ever generate something like that.

But if you do the maths it not really possible. If the sync period is 5% of the line-time, that comes out at 125uS, that would allow for only 2.5 cycles of 20kHz. Darn!

Given enough headroom and bandwidth in the record/playback system, during line 32 mix in a full amplitude 20kHz signal as if to say "Hey folks, here doesn't come that pulse you've all been waiting for." The 20kHz could easily be filtered out so it doesn't reach the display proper.

In essence it becomes a predictive frame sync and the easy way of decoding it is using something like a NE/LM567 tone decoder. These are sadly now out of production, but still can be found. These little babies will decode a tone of only six cycles if configured correctly, but with 2.5mS on our hands that means we have 50 cycles to play with, so it's detection bandwidth could be reduced, thereby lessening the chances of false triggering.

Again, this is just an idea, not a proposal.

Steve A.

An alternative is to mix the 20kHz into the right channel along with the sound, unless you're 16 years old and have a good sound system, it's unlikely that you would hear it. But it might upset Gromit.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 4231
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

PCs again, sorry.

Postby Steve Anderson » Thu Jun 21, 2007 1:52 pm

AncientBrit wrote:There's always this device that interfaces between USB and TTL RS232. Graham


I had considered that as well as USB to parallel 'cables'. These are obviously more than just a cable. But I wonder just how well they emulate a real LPT1/2/3 port.

If you write to the address for LPT1 data register &H378, does it really work? Similarly reading the status register and writing to the control register.

Anyone have experience with these?

Maplin in the UK have an example, stock code A94BF.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 4231
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Postby Klaas Robers » Thu Jun 21, 2007 9:53 pm

A different way to regenerate a unique frame pulse from the missing frame pulse is to generate first an ongoing line pulse. This could be done by comparing your continuous line pulse with the incoming line pulse and adjusting the frequency and phase so they coïncide completely. A small micro computer could do this easily, even if the line frequency is much higher or lower.
Then by exclusive or-ing the incoming sync with the self generated line sync will provide you with a well timed frame sync pulse.

Indeed I prefer to have a kind of synchronisation by hand. My monitor gives me that as a possibility. First all synchronisation is off and I am bringing the disc to speed with a variable 10 turn resistor.
Then I switch to a position where the disc is synchronised to a cristal oscillator. It runs the correct speed, but there is no connection to the incoming video.
The next position gives line synchronisation to the video. This ignores any missing sync pulses.
The last position gives frame sync as well.
In cases where I know of standard video, e.g. from the club-CD's, I switch from 1 to 4 immediately. This will do. When the disc is running for a while I have to set the initial speed (1) again, as the motor warms up and the speed changed. I don't know why, but it does. After that synchronisation is kept automatically, even when the video is interrupted and restarted in a different phase.
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1529
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

Re: PCs again, sorry.

Postby gary » Fri Jun 22, 2007 12:04 am

Steve Anderson wrote:
AncientBrit wrote:There's always this device that interfaces between USB and TTL RS232. Graham


I had considered that as well as USB to parallel 'cables'. These are obviously more than just a cable. But I wonder just how well they emulate a real LPT1/2/3 port.

If you write to the address for LPT1 data register &H378, does it really work? Similarly reading the status register and writing to the control register.

Anyone have experience with these?

Maplin in the UK have an example, stock code A94BF.

Steve A.


I did buy one of these when I was trying to get Ralphs Virtual Televisor going. At the time I has a windows 95 desktop machine and I was getting little 'speckles' on the video and I wanted to rule out a flakey parallel port and as I had a laptop with no parallel port I thought I would get one of these so I could try it on both machines. I never got it going anywhere. I suppose it must have been just a faulty unit or it didn't like being connected to Ralphs' unit and blew up (although I doubt this).

The one thing I noticed when buying this is that most of them have a Centronics parallel port connector (i.e. for printers) rather than a DB25 (I actually found and bought one that was DB25). This leads me to feel that whilst they may work for most printers that they do not necessarily provide the full parallel port functionality.

In any case I think your fears are valid as they provide a virtual comms port not a physical one, meaning that they will work under a windows OS but not under DOS, or at least they cannot be directly accessed via a memory address.

Going back to Grahams suggestion about using a FT232R Modules. I mentioned I had something similar and I have looked it up. I bought a USBMOD4 USB Plug and Play parallel 8-bit FIFO Development Module from Futurlec at a very reasonable $A24 a couple of years ago meaning to connect it up to an AD as an alternative to using a soundcard to record NBTV signals (mostly in order to allow direct coupling). The unit has a 384 byte buffer allowing it to work with windows non-deterministic nature. It supports a throughput of 1 Megabytes per second. The module comes with Virtual Port Driver and a direct access API driver so you can choose which to use, in either case it takes all the hassle out of writing USB specific code. I haven't got around to doing this yet but if you are interested the data on the unit can be found at:

http://www.futurlec.com/USBMOD4.shtml
User avatar
gary
"Fester! Don't do that to 'Thing'"
 
Posts: 2303
Joined: Sat Jan 27, 2007 11:29 am
Location: Bundanoon, Australia

Re: PCs again, sorry.

Postby Steve Anderson » Fri Jun 22, 2007 12:59 pm

gary wrote:This leads me to feel that whilst they may work for most printers that they do not necessarily provide the full parallel port functionality.


Hmm, this is exactly what I feared, having a Centronics connector also hints at this as you say. But those with a 25-pin D-type connector should provide full support for all modes, note the word should. What if you wanted to use a Zip Drive? Mine had two D-types on the back so you could daisy-chain it and a printer. I use the past tense as it was ejected from my 6th-floor apartment window 'cos it was so unreliable. (The 'Click of Death').

The Futurelec product looks ideal, and they have a branch in Bangkok. And for once, a decent datasheet!

Now please don't snigger, but the only computer language I program in is Qbasic, I used to do assember on 6809s, but you can't get the chips any more, at least at a sane price.

I considered Visual Basic and started to read "Visual Basic for Dummies". Just like "USB in a Nutshell", I gave up after a few pages. I just can't be bothered learning yet another language!

When you analyse the requirements all we want is a storage device, a PC and all this external paraphernalia is like using a sledgehammer to crack a nut.

A simple stand-alone device that read/writes to a CF card would be fine. So I downloaded the Compact Flash specification. Guess what? I gave up yet again.

I've got several spare operational hard disc drives kicking around....I wonder?

Steve A.

I might start a new thread on this subject, I don't want to clog up this thread which started on the subject of sync pulses.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 4231
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: PCs again, sorry.

Postby gary » Fri Jun 22, 2007 1:39 pm

Steve Anderson wrote:The Futurelec product looks ideal, and they have a branch in Bangkok. And for once, a decent datasheet!


Well, I'm going to have to write some software myself when I get around to using the module. if you wanted to pursue it I would be happy to handle the software part for you (and it could be integrated into my other software).

Steve Anderson wrote:When you analyse the requirements all we want is a storage device, a PC and all this external paraphernalia is like using a sledgehammer to crack a nut.


True, although it is handy to be able to interface to a PC during development.


Steve Anderson wrote:A simple stand-alone device that read/writes to a CF card would be fine. So I downloaded the Compact Flash specification. Guess what? I gave up yet again.



Damn! I came across a site that showed how to interface such a device to a PIC using an PCB edge connector or something as I remember. I didn't keep the link but if I come across it again I'll let you know. Sample code was provided so that part should be trivial. Of course whether it could handle the data rates is another thing, not many of the PICs do.


Steve Anderson wrote:I've got several spare operational hard disc drives kicking around....I wonder?


Very hard, I looked into it with the idea of creating a homemade PVR. Too difficult for me. If you sorted that one out it opens up lots of possibilities.

Steve Anderson wrote:I might start a new thread on this subject, I don't want to clog up this thread which started on the subject of sync pulses.


Yep. That would be good.
User avatar
gary
"Fester! Don't do that to 'Thing'"
 
Posts: 2303
Joined: Sat Jan 27, 2007 11:29 am
Location: Bundanoon, Australia

Frame Frustration.

Postby Steve Anderson » Fri Jun 22, 2007 11:11 pm

You know, for years I've wracked my brains (what's left of them) over this whole subject of frame sync for NBTV, you have to admit that with the current arrangement only its mother could love it.

There has to be a better way without losing a whole line, or even part of one, to it. I'm not keen on a 'Super White' pulse or a 'Super black-more-than-normal Sync' pulse. Here I'm only concerned with an analogue signal, for a digital one it's real easy.

Come on guys, it can be done. But it has to be compatable with the missing sync system too. Time to get creative. Just because it's been done a certain way for quite a while doesn't mean we need to stick rigidly to it.

Automatic and reliable frame sync has been a pain for such a long time. It's time to put it to bed.

Steve A.
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 4231
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Re: Frame Frustration.

Postby Andrew Davie » Fri Jun 22, 2007 11:35 pm

Steve Anderson wrote:You know, for years I've wracked my brains (what's left of them) over this whole subject of frame sync for NBTV, you have to admit that with the current arrangement only its mother could love it.

There has to be a better way without losing a whole line, or even part of one, to it. I'm not keen on a 'Super White' pulse or a 'Super black-more-than-normal Sync' pulse. Here I'm only concerned with an analogue signal, for a digital one it's real easy.

Come on guys, it can be done. But it has to be compatable with the missing sync system too. Time to get creative. Just because it's been done a certain way for quite a while doesn't mean we need to stick rigidly to it.

Automatic and reliable frame sync has been a pain for such a long time. It's time to put it to bed.

Steve A.


My first approach would be to assume the same hardware configuration (that is, a 31 hole system, missing hole marking start of frame) and software (31 line synch pulses, missing pulse for frame synch).

Then I'd draw up a state diagram that shows, given particular states of the system, what would cause a transistion from each state to another (eg: when I'm in state X and event Y happens, change to state Z). Given a properly done state system, I would imagine that it would then be possible to create a hardware implementation.

I do seem to recall that this can all be expressed in some sort of boolean algebra (I'm stretching here, it's been a number of years), and converted down to the level of simple gates. I'll have to chase that up; it was quite interesting when I was learning it.

But I'm very strong on the idea that a properly described state system is where I'd start. Define exactly what sort of modes we expect, and what sort of transitions are possible.

For example, when the system is first turned on, we might call this "state 0". At this point, we have no power to motor, and an incoming sync pulse (or not!). With no power to motor, and no synch pulse, we remain in state 0. But if there's a synch pulse we know that the motor is running slow -- we should expect to have a simultaneous "hole" pulse.

So we'd transition to sate 1. In state 1 we know we're trying to speed up the motor, because we expected to have a hole pulse earlier. Whilst in this state, we might get a hole pulse, or another synch pulse. If we get another synch pulse, we are still running too slow (synchs are coming faster than.... etc).

I believe it would be interesting to draw up a complete state diagram for this system, given the inputs of synch pulse and hole pulse... and go from there. This would give a system that would work for a simple "motor on, motor off" control.

My gut feeling, though, is that a variable motor speed, rather than a pulsed system, would be a much easier system to stabilise.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1548
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Postby Andrew Davie » Sat Jun 23, 2007 1:26 am

The following is an initial attempt to define a sort of “state system” describing the relationship of the motor, the synch pulse (S) and the hole pulse (H) in a mechanical TV system. The idea is that the system is in a known ‘state’ at every time, and the motor is turned on or off at the start of the state ‘processing’ and the state then handles ‘events’ that are the hole and synch pulses, transitioning to another state as appropriate.

In the states shown below, first is a simple description of what the state is doing, then the status of the motor, then a table which indicates the values of the hole pulse, the synch pulse and --> state to go to when the values thus shown are found. For example, in state 1 if a synch pulse ‘arrives’ with no hole pulse, then the next state of the system is state 1.

A note about the values of ‘hole pulse’ (H) and ‘synch pulse’ (S) – this system assumes that a pulse is a one-off event, triggering to 1 when it is first detected, and returning to 0 immediately the value is ‘read’. I’d call this a buffered input, in computing terms. In any case, it’s important that an external system ‘feeds’ the pulses to this state system in this way (that is, when a hole pulse comes, then it immediately becomes “1” in value, but upon reading returns to “0” and remains at 0 until the start of the NEXT hole pulse (even though the current hole may still be sending a pulse signal)).

This state description is assuming that we have 32 holes on our disk, and 32 synch pulses per frame in our signal. That is, NO missing pulses. We’ll tackle frame synch a little later.

The system starts in state 3 –the disk could be anywhere and there may or may not be a synch signal.

---------------------------------------------------------------------------------------------------------
State 1 – a synch pulse has come but no hole pulse
So we should speed up the motor

TURN MOTOR ON

H S
0 0 --> 1 (still waiting for the hole pulse, speed up motor)
0 1 --> 1 (STILL waiting for hole pulse, speed up motor)
1 0 --> 2 (we now have our hole pulse, so back to the standard “all OK”)
1 1 --> 2 (we were waiting for a hole, but we also got another synch)
---------------------------------------------------------------------------------------------------------
State 2 (all OK – here the system thinks everything is in synch)

TURN MOTOR ON

H S
0 0 --> 2 ( all OK )
0 1 --> 1 (synch received, no hole)
1 0 --> 3 (hole but no synch -- disk spinning too quickly)
1 1 --> 2 (hole and synch in synchronization)
---------------------------------------------------------------------------------------------------------
State 3 -- startup state (unknown)
or a hole has come before a synch
Either the disk is spinning too quickly, or there is no video playing
OR the disk is stationary over a hole

TURN MOTOR OFF

H S
0 0 --> 3 (still slowing down motor)
0 1 --> 2 (our synch has now arrived)
1 0 --> 3 (another hole, so we’re way too fast – continue slowing down or stay stopped)
1 1 --> 2 (our synch has arrived – with the next hole)


I think the above works for the simple hole/synch pulse pairs, and makes sure the motor will be turned on or off appropriately. It’s pretty simple, just three states, and doesn’t really care too much about how much ‘kick’ the motor has. What it doesn’t do is any sort of frame synchronization.

My feeling is that there should be a separate frame synchronization hole, and no missing hole on the disc for the normal pulses.

Assuming, then, a simple hole/sync pulse indicating frame timing, then the states would be… EXACTLY THE SAME. That is, the above ‘circuit’ or system could be used firstly to achieve frame synch, and then as soon as that was achieved, to switch over to using the line synch pulses to achieve line synch. This is, then, assuming that we have 32 line pulses and 32 holes. And an additional frame synch pulse/hole.

Once synch on the frames was achieved, giving a good ‘framing’, then the synch on the lines could take over. I’ve not addressed the switching between the two modes… perhaps there could be a counter of some sort, counting delays between entering a state and the receipt of the expected signal to move back to state 2 (the OK state). In any case, it’s late here so I’ll throw this system to the sharks (that’s you) and see what comes of it.
User avatar
Andrew Davie
"Gomez!", "Oh Morticia."
 
Posts: 1548
Joined: Wed Jan 24, 2007 4:42 pm
Location: Queensland, Australia

Re: Frame Frustration.

Postby Steve Anderson » Sat Jun 23, 2007 2:03 pm

Andrew Davie wrote:My gut feeling, though, is that a variable motor speed, rather than a pulsed system, would be a much easier system to stabilise.


I have seen somewhere a motor control circuit that uses pulse-width modulation to control the motor speed. I've dug through all my NBTV folders and cannot find it.

It's conceptually the same as the motor control circuit you are using now, except the MOSFET is driven by pulses, so it's either on or off. this has the advantage that the MOSFET dissipation is vastly reduced, the same idea as is used in switched-mode power supplies.

The pulses can be fixed frequency but variable width controling the ratio of off to on time. Or fixed width but variable frequency.

Seeing that we're heading in a logic-based direction it would seem logical (pun intended) to use one of the above methods.

Just wish I could find that diagram! Still, no big deal, we can start from scratch, it's not rocket science.

Steve A.

I found it. Where it came from I don't know, and what all that clobber is at the top right I have no idea! I didn't resize it, it's hard enough to read it as it is. I zipped it, it made the pages here too wide.
Attachments
PWM Motor 1.zip
(21.79 KiB) Downloaded 663 times
User avatar
Steve Anderson
"Fester! Don't do that to 'Thing'"
 
Posts: 4231
Joined: Fri Mar 30, 2007 10:54 pm
Location: Bangkok, Thailand

Postby Klaas Robers » Sat Jun 30, 2007 3:50 am

Steve, be aware that a Permanent Magnet DC motor cannot be driven by pulse width "hard" voltages. Then the motor current goes to very high values. I assume then that outside the pulse the motor is shorted, i.e. voltage = zero.

You can use pulse width modulation, but then the pulse frequency should be so high, that the self inductance of the coil of the motor defines the current. I think of a frequency of 20 kHz.

But on the other hand I think that the dissipation of the transistor is not a problem. We are working in the watts region. Don't make things more complicated than they are....
User avatar
Klaas Robers
"Gomez!", "Oh Morticia."
 
Posts: 1529
Joined: Wed Jan 24, 2007 8:42 pm
Location: Valkenswaard, the Netherlands

PreviousNext

Return to Mechanical NBTV

Who is online

Users browsing this forum: No registered users and 13 guests

cron