Unstable HSync

[crippo2]

I Last contacted the forum several years ago about a system, using OSSC (now upgraded to V1.8 with f/w 1.11a)

OSSC input is Analogue RGBHV to AV3. Sync pulses are negative going from 5v.

With the input disconnected the OSSC test screen displays OK on the target..

VSync is stable over time @ 49.99Hz, but HSync is unstable once the initial 2 seconds had passed.

I have built a device which can independently alter the line and HSync pulse lengths. Lines are triggered from the end of each VSync pulse, last for a switchable period and continue until the start of the next frame, when all counters reset. VSync is negative going for 227us (source fixed in frequency size and length) HSync pulse is 47.71us (variable from 4us to 5.8us for testing purposes)

Connecting RGBHV out from source to OSSC, its HDMI out directly connected to target I Get:

Target displays a picture for 2 seconds post switchon with
OSSC onboard display showing 13.57KHz, 49.71Hz (fps) & 273 -p (lines per frame) and
The Green LED is fully lit.
Thereafter target blanks, but continues to acknowledge receipt of input and
OSSC onboard display shows 13.72KHz, what appears to be a 50.00/49.99 Hz VSync rate and a line rate of 274/5 -p and
The green LED remains fully lit.

Connecting my device between the HV portion of the analogue output and selecting a line frequency of 13.57KHz I get:

Target sees existence of HDMI output from OSSC but
there is nothing displayed.
OSSC onboard display shows 13.57KHz, with what appears to be a 50.00/49.99 Hz VSync rate and271/2 -p (lines per frame) and
The Green LED is fully lit.

Assuming the Green LED being lit = Sync is good, but the frame and line uncertainties mean errors,

and bearing in mind that the frame rate s fixed at 49.99 Hz are there any suggestions about nailing down the what I need to do to best remove any uncertainties

[marqs]

Sync signal widths are not important, only the interval on leading edges is. If I understood correctly, you have a stable Vsync interval (at 49.99Hz), but your Hsync is generated without using common reference, and thus the last line is always cut short if the first line is triggered at Vsync trailing edge. This can easily cause the H-PLL to lose lock if the last line is even a few % shorter than previous lines. Even if the PLL is able to maintain lock, the clock jitter propagates to HDMI output and many displays do not tolerate much jitter.

With a suitably selected period, you might be able to minimize the difference in line interval to small enough value. You can additionally tune H-PLL and FPGA PLL bandwidth to a lower value under Sync. Opt which may help to distribute the clock variation to longer time period if they still can maintain lock.

[crippo2]

Marqs

Thanks for this information, I will look into points you have raised.

Not sure my technology will allow me to look at the issues involved, but I will do some research on that.

Presumably I can, go to the pixel clock to act as a trigger point, presumong both H & V Sync pulses are locked to that.

Alternatively I can inhibit the V Sync pulse start until the end of the last line and shorten it until its end point (when the HSync pulses start) exactly matches the necessary length.

One point perhaps you can answer for me is the meaning of the green LED appearing to be fully bright. Does it mean that the sync is good/partially good/ just OK etc

Thanks again

[marqs]

Perhaps you could draw a diagram of the pulses to illustrate sync relationships. It’d be indeed better to start vsync pulse aligned to start of hsync, otherwise the signal might get decoded as interlace.

The green LED goes off (equals red LED being lit on native v1.8 board) when either of the following things happen (in addition to detecting IR code):
* PLL inside FPGA loses lock due to sudden change in sampling clock. Note that the PLL is bypassed in passthru and some 2x modes.
* Input vsync leading edge occurs too far from the expected position. This occurs during a mode change or if there is large variation in vsync interval.

Note that the signal goes thru downstream PLLs during (de-)serialization so even if ADC and FPGA PLL are able to maintain lock, something later may not if the clock signal is not clean. With the listed PLL BW settings you might be able to spread out disturbances in time domain, but having a periodic hsync (leading edge) has much bigger impact.

[Author]

Posts