What a difference 0.03Hz can make!
I had disabled the syncing of the output to the input while working on the NTSC input.
So it was time to reconnect this. It would be synced while converting from a 25Hz frame to 25 Hz frame of from a 30Hz frame to 30 Hz frame and left free running at other times.
So when reconnected the 25 Hz to 25 Hz worked well as it did before. But when going from 30 Hz to 30 Hz it wasn't syncing properly.
See photo below. There is bad hooking on one field.
The way the output clock is calculated is.
frame frequency * No. of lines * cycles in a line = output clock frequency.
This is calculated in the microcontroller and is passed to the FPGA where it is multiplied by a coefficient. The result is used as the coefficient for the output clock DTO. The clock driving the DTO is derived from the video decoders video clock.
All pretty straight forward and I couldn't see at first what was going on. Then it occurred to me that the frame frequency was in fact 29.97 Hz and not 30 that I was using.
Changing 30 to 29.97 in the calculation in the microcontroller could be done but instead I adjusted the coefficient in the FPGA if the input was a 30 Hz frame. As it was easier to implement.
This has also explained another problem that I noticed.
While connected to a 525 signal it could occasionally be seen to lose frame lock.
The Hedghog PSC that I am using as a 525 signal source had a 30 Hz frame and not 29.97. Regardless of this the video decoder was implementing a 29.97 frame on its output.
Because the two frame rates were slightly out there phase was forever drifting apart. When they drifted far enough apart lock was lost and the decoder had to then regain lock. This would show up on the picture as a brief loss of frame lock.
After changing both Hedghogs to 29.97 proper sync has been restored and there is no more loss of frame lock
Frank
I had disabled the syncing of the output to the input while working on the NTSC input.
So it was time to reconnect this. It would be synced while converting from a 25Hz frame to 25 Hz frame of from a 30Hz frame to 30 Hz frame and left free running at other times.
So when reconnected the 25 Hz to 25 Hz worked well as it did before. But when going from 30 Hz to 30 Hz it wasn't syncing properly.
See photo below. There is bad hooking on one field.
The way the output clock is calculated is.
frame frequency * No. of lines * cycles in a line = output clock frequency.
This is calculated in the microcontroller and is passed to the FPGA where it is multiplied by a coefficient. The result is used as the coefficient for the output clock DTO. The clock driving the DTO is derived from the video decoders video clock.
All pretty straight forward and I couldn't see at first what was going on. Then it occurred to me that the frame frequency was in fact 29.97 Hz and not 30 that I was using.
Changing 30 to 29.97 in the calculation in the microcontroller could be done but instead I adjusted the coefficient in the FPGA if the input was a 30 Hz frame. As it was easier to implement.
This has also explained another problem that I noticed.
While connected to a 525 signal it could occasionally be seen to lose frame lock.
The Hedghog PSC that I am using as a 525 signal source had a 30 Hz frame and not 29.97. Regardless of this the video decoder was implementing a 29.97 frame on its output.
Because the two frame rates were slightly out there phase was forever drifting apart. When they drifted far enough apart lock was lost and the decoder had to then regain lock. This would show up on the picture as a brief loss of frame lock.
After changing both Hedghogs to 29.97 proper sync has been restored and there is no more loss of frame lock
Frank
