NBTV Camera Question

[gary]

Hi Harry, it varies between 384 Hz and 436 Hz.

[Harry Dalek]

Hi Harry, it varies between 384 Hz and 436 Hz.

My scope frequency meter must be way off i am just seeing 396 397 steady on the adjustments tonight .But i can see the changes in hight in lines which is due to the frequency changes in the lines on play back i suppose .
I am taking the readings from after the lm311 would the monostable wouldn't change it ?
What i don't under stand is the clock is 400hz shows 400hz on the meter...i might test it via the pc and my multi meters ...
I might record my crystal clock as well.
I was thinking i had this problem beat looks like its going to be a bit more work..darn!
The test card i filmed to night is 2 i posted in the sound and images ,you can read the nbtv letters and such ...with the image delay i am getting trying to focus them they didn't come out to bad.
BTW i recorded them in mono 16k for some only seems to play on garys Alpha big screen and rolling a bit in Doms software

[gary]

My scope frequency meter must be way off i am just seeing 396 397 steady on the adjustments tonight .

Well it is probably just showing an average - the variation is too fast to display in any meaningful sense of a frequency meter - it would be nice if it gave the variation though.

But i can see the changes in hight in lines which is due to the frequency changes in the lines on play back i suppose .

Only if they were so way out that there was no zero crossing to measure - even then I am not sure it would affect a frequency meter.

I am taking the readings from after the lm311 would the monostable wouldn't change it ?

No, not in the manner I am seeing.

What i don't under stand is the clock is 400hz shows 400hz on the meter...i might test it via the pc and my multi meters ...

Well the clock is probably spot on, but I think your disk maybe "hunting" in a manner similar to Albert's nipper.

I might record my crystal clock as well.

Not a bad idea.

I was thinking i had this problem beat looks like its going to be a bit more work..darn!

Well to be honest it did seem to come together just a little too easily, my experience with speed control is it takes a lot of "tweaking" to get it spot on.

Harry, by far the best way to test it would be to modulate a led or leds with NBTV and view it through your disk - that will tell you immediately if you have correct speed.

EDIT: OTOH when viewing your output through TBP, WITHOUT sync processing selected, you will get a steady picture with a flat sync bar when you have 400 Hz.

BTW i recorded them in mono 16k for some only seems to play on garys Alpha big screen and rolling a bit in Doms software

Sorry, Harry, I don't quite understand that comment, what has recording mono 16k (too low BTW as you will be chopping of the top 2k or so of bandwidth) got to do with playing the file? If you could elaborate on that I might be able to recommend a better sample rate.

Edit: Oh, you meant 24k...

[gary]

Harry, further to measuring your disk speed. When viewing on TBP with sync processing turned OFF - the "sans TBC" video is what you will see with your current setting, and the "TBC" video is what you will see when speed is correct.

[Harry Dalek]

Thanks for the reply there Gary

Well it is probably just showing an average - the variation is too fast to display in any meaningful sense of a frequency meter - it would be nice if it gave the variation though.

It seems pretty fast to react on speed changes but must is off from what you say changes speed so fast it can't see it least that makes sense !

Well the clock is probably spot on, but I think your disk maybe "hunting" in a manner similar to Albert's nipper.

Ok looks like have another challange !...i read some time back I think it was panrock he was have trouble with the PLL and i think he swapped the pin 3 and 14 connections ...any way will reread Alberts build see if i missed something...Ok its working but not good enough.

Not a bad idea.

I will do a recording next time i set up might as well see whats happening for sure .

Well to be honest it did seem to come together just a little too easily, my experience with speed control is it takes a lot of "tweaking" to get it spot on.

Well i have had every problem you can have with this from the start with this so why not one more !

Harry, by far the best way to test it would be to modulate a led or leds with NBTV and view it through your disk - that will tell you immediately if you have correct speed.

Well thats a good excuse to get that going again ,i can sort of also tell with that strobe disk pasted on .

EDIT: OTOH when viewing your output through TBP, WITHOUT sync processing selected, you will get a steady picture with a flat sync bar when you have 400 Hz.

At the moment it reminds me of drum monitor ,,,,yes must go for that flat sync bar .

Sorry, Harry, I don't quite understand that comment, what has recording mono 16k (too low BTW as you will be chopping of the top 2k or so of bandwidth) got to do with playing the file? If you could elaborate on that I might be able to recommend a better sample rate.

I was trying to drop the file size tend to use 24 but i can see 16 is no good played fine on your Alpha TBS and Doms but your first big screen didn't like it at all .No worries i will stick to 24000 on the recording side my mistake .

[Harry Dalek]

Harry, further to measuring your disk speed. When viewing on TBP with sync processing turned OFF - the "sans TBC" video is what you will see with your current setting, and the "TBC" video is what you will see when speed is correct.

Yes i would much rather the correct speed one i would be happy with that .

Looks like i am going to have to do a bit of work to get to this Oh well keeps me off the streets as you said

[Harry Dalek]

Gary i have played around with the PLL i have got it steady heres a sync only wav ,when playing back even on Doms software its steady the sync bar is not what i call a nice line but best i can do tonight ...

[gary]

Well that's certainly more consistent Harry.

Max freq = 424.8 Hz @ 0.7 seconds
Min freq = 372 Hz @ 4.481 seconds

Average freq = 400 Hz

Yes the wavy sync bar could be hunting as in Albert's case, or aperture position inaccuracy.

BTW I suppose that your clock pulse train doesn't include a missing pulse? If not, then for testing purposes, it may be worth adding in the missing pulse from the disk to see if it locks better.

[gary]

BTW Harry are you using line in or mic input for these test?

[Harry Dalek]

Hi Gary

Well that's certainly more consistent Harry.

Max freq = 424.8 Hz @ 0.7 seconds
Min freq = 372 Hz @ 4.481 seconds

Average freq = 400 Hz

Still a bit of a swing...i had 3 gos at it and 3rd was the best ...the strobe disk doesn't move but must be a slight vibration happening ..and on the vibration side or wobble do you think a slight disk wobble on the mechanical side cause the above effect to ....the mechanical side must cause more trouble than the electronics .

But i will adjust it bit more .

Yes the wavy sync bar could be hunting as in Albert's case, or aperture position inaccuracy.

Again it so reminds me of vibration on a drum monitor ...i noticed because i cut my encoder slots out theres a slight difference in pulse widths perhaps this is a problem ...may be i should of tried the pot on the photo transistor for the encoder least i would of known this is not a cause .
I will do some reading and thinking about this tonight .

BTW I suppose that your clock pulse train doesn't include a missing pulse? If not, then for testing purposes, it may be worth adding in the missing pulse from the disk to see if it locks better.

No gary i have not even thought of that i am thinking its not in the sync for a monitor should work in reverse for a camera but ...are you saying feeding back the encoder pulses to sync the crystal clock ....if so thats an interesting idea ...

[gary]

do you think a slight disk wobble on the mechanical side cause the above effect to

Possibly, but I would think it would have to be a huge wobble to produce that much of a wave. Don't forget it is only the encoder/sensor that is involved and the little distance change due to wobble would not make that much difference I wouldn't have thought.

Come to think of it, I mentioned earlier it could be due to a variation in aperture position but that can't be as it is having an effect on the sync which, of course, doesn't travel through the apertures.

OTOH, if the encoder itself wasn't running concentrically with the sensor then the wedge shape of the segment may possibly cause this effect - again it would need to be quite out of concentricity.

....the mechanical side must cause more trouble than the electronics .

Don't bet on it

...may be i should of tried the pot on the photo transistor for the encoder least i would of known this is not a cause .

I can't see that having anything to do with this effect.

No gary i have not even thought of that i am thinking its not in the sync for a monitor should work in reverse for a camera but ...are you saying feeding back the encoder pulses to sync the crystal clock ....if so thats an interesting idea ...

Hmmm, I'm lost, how does your circuit work then? I thought you were using the PLL to compare your clock pulses to the encoder pulses - yes just the same way as a monitor speed control works.

[Harry Dalek]

Possibly, but I would think it would have to be a huge wobble to produce that much of a wave. Don't forget it is only the encoder/sensor that is involved and the little distance change due to wobble would not make that much difference I wouldn't have thought.

So more likly electronics ...rather that to be honest than mechanical .

Come to think of it, I mentioned earlier it could be due to a variation in aperture position but that can't be as it is having an effect on the sync which, of course, doesn't travel through the apertures.

Yes that part is a closed system to its self just mixed later ,thats another i am glad its not that !

OTOH, if the encoder itself wasn't running concentrically with the sensor then the wedge shape of the segment may possibly cause this effect - again it would need to be quite out of concentricity.

I don't really point the sensor right flat to the encoder its at a bit of an angle ,i think from my camera shots it picks up the light from the sensor ir led i think its half way ...

Don't bet on it

OK the electronics but i have one eye on that spinning disk


Hmmm, I'm lost, how does your circuit work then? I thought you were using the PLL to compare your clock pulses to the encoder pulses - yes just the same way as a monitor speed control works.[/quote]


Well yes when you were asking about adding a missing pulse to the crystal clocks i was wondering if you were meaning that .
my mistake

[gary]

Well yes when you were asking about adding a missing pulse to the crystal clocks i was wondering if you were meaning that .
my mistake

But then back to what I was saying if your clock has 32 pulses and your encoder has 31 I would expect that to have some effect as in fact you are then comparing apples with oranges, or at least Granny Smiths with Delicious'

Ideally with this kind of an arrangement, which I support as a good way of doing things - but have never implemented myself, you would have 32 segments on your encoder and a separate sensor and encoder to detect frame, you would then electronically remove the "missing pulse" based on that information*. I shouldn't think that would be too difficult, but not having gone down that track (well done Harry!) perhaps some other reader who has done something similar would care to comment?

* Exclusive Or ?

[Harry Dalek]

But then back to what I was saying if your clock has 32 pulses and your encoder has 31 I would expect that to have some effect as in fact you are then comparing apples with oranges, or at least Granny Smiths with Delicious' Ideally with this kind of an arrangement, which I support as a good way of doing things - but have never implemented myself, you would have 32 segments on your encoder and a separate sensor and encoder to detect frame, you would then electronically remove the "missing pulse" based on that information*. I shouldn't think that would be too difficult, but not having gone down that track (well done Harry!) perhaps some other reader who has done something similar would care to comment?

I have no idea the inner workings of the PLL but 32 32 sounds better than 31 32 ,the thing must jump how ever fast to sync again...i really don't understand this part ..
The missing sync part corrects yes the start postion of the scan where the start end postion is how it syncs better in the PLL me dumb dumb no idea ...so you are saying what if there was just another hole or 1 slot above the 32 slots so the pll or bistable what ever your using always has 32 clock and encoder ...this should work better for the pll locking ? and the then frame pulse is a bistable switch that gets its pulse from the extra one hole slot on th encoder , the pulses from the pll are feed to the bistable set reset what ever and same for the extra new one pulse from the encoder.

If its this what you are thinking gary ? i can give that a try but have to work out another IR light sensor ,might have something handy .

[gary]

erm, I'm not sure if that was what I am saying or not I think so.

With the encoder you have at present 32 slots but only 31 are filled, so you only have 31 pulses, but your PLL is comparing them against 32 pulses coming from you clock circuit - so yes you would expect some problems completely "locking" - I am saying to correct for that simply fill in the missing "slot" that should then allow "locking" but now you won't have the missing frame pulse. To correct that you can add another single slot either inside or outside the 32 slots and have another sensor pick that up - you can then mix the two pulse streams with an exclusive or to add in the missing frame pulse which is then sent to the PC (or whatever) - obviously this stream of pulses is not the one sent to the PLL it's the output of sensor 1 that is sent to PLL for locking purposes.

Of course, as a first iteration, you needn't add the second sensor etc - just get the locking working first is my suggestion.