OSSC loses sync when receiving 13.75 Khz H Sync

[crippo2]

Be Kind please this my first post and still trying to understand the best way to sort this out!
I have 2 early naughties St Nav Units. Both run Analogue RGB with separate HV Sync. They are respectively NTG1 and NTG2.

The NTG1 System is to have its display upgraded, from ancient Analogue to more modern Digital Display.

My setup is simple. Analogue RGBHV from the NTG2 unit is sent by a 1.2m cable to the matching analog input of the OSSC. The OSSC HDMI output goes directly back to the new display driver Board (VS-TY2662-V1-99) and thence to the display (ATN065TN14). The OSSC is running Firmware V.90

All testing has been carried out on the NTG2 unit which produces 15.73Khz H Sync and 59.9hz V sync. The OSSC syncs perfectly, and upscales the original SDTV display by 2 to 768 x 476 progressive. The Configuration is saved in the OSSC

The NTG1 unit, when using an identical setup, is connected to the OSSC and syncs for a few seconds before losing the connection. The Displayed information during the short OSSC sync period is 13.75 Khz for H Sync and a Vertical sync rate of 49.72Hz.

An additional problem is that, for entirely unconnected reasons, the NTG1 turns off after 10 or so seconds.

The OSSC Configuration has been adjusted by me to work better with the NTG2 Sync rates (15.75 Khz for H Sync and 59.9Hz for V Sync) and I suppose my tweaking has affected the ability of the OSSC to sync with the different information from the NTG1 Unit.

What I need is a likely starting setup for the 13.57Khz H Sync/49.9Hz V Sync rates of the NTG1, so I can at least get a stable display. I can then start working on the improvements.

Anyone have any ideas, either with detail, or just to revert the OSSC to its Default settings and start from there?
thanks and regards

[marqs]

You could try enabling “AV3 interlacefix” from compatibility menu.

[crippo2]

Many thanks for your response.
However I now think I was a bit hasty in tasking the OSSC input Sync selection process as an issue.
Having put both H & V Sync streams onto a Tek Scope, I see that after initially (say 2 secs) pure sync pulses, both of an acceptable size and shape, during which the OSSC syncs fine, both H & V pulses become contaminated by, what I can only call ‘phantom’ pulses.
The scope has no problem triggering on the authentic pulse and the phantoms are barely visible, but seem to be frequent and random in the time domain. The issue could be caused by a number of factors, so more investigation is needed
I accept that the OSSC looks for clean, properly defined, Sync pulses and has no errant sync pulse lockout capability – that is not its job – so I will need to dig deeper into the problem at the transmission end of the delivery chain
More later

[crippo2]

An update from the earlier post.
If appears that the display is responsive to an LVDS pixel clock signal rathar than the H & V Sync signals also sent to it. The 6.678Mhz pixel clock counts cycles and synchronises the H & V Sync signals to them rather than just relying on the pulses created by the Sync generator. this magic hsappens in ICs for which I can find no datasheet, so remedies using similar technology are difficult, requiring an alternative approach

I wonder if a guru might please confirm that the OSSC inputs (and if only some, which ones) will accept and process the 13.75khz HSync rate and a frame rate of 50Hz.
thanks and regards

• This reply was modified 2 years ago by crippo2.

[marqs]

13.75KHz @ 50Hz indicates the board is outputting 275 lines per frame/field which is quite far from the usual number (312 or 313) you see with standard PAL sources. OSSC should process it but you might want to check the details on info screen (press INFO on remote). In any case you’d need quite tolerant display to accept the linedoubled signal.

[crippo2]

Apologies about the length of this post
Regrettably I misread the information I think I now better understand the problem I have.
In the 1st 2 seconds after switchon the OSSC syncs with 13.57Khz and an initial frame rate of 49.69 Hz increasing to 49.72 Hz within the 1st 2 seconds before sync is lost.
The frame rate appears to stay steady at 49.71/2Hz, but the HSync count changes. My Counter, when set to a 1ms gate period, shows the initial HSync regularly switching between 13.572Khz and 13.722Khz and then dropping back to 13.572Khz. With a 100ms gate period the HSync settles at 13.647Khz, the mean of the above two readings.
This happens on each of the 3 similar units I have (2 x UK & 1 x USA).
Each unit also drives the current display using a pixel clock, possibly to get the best possible display, but this also varies in frequency between the initial 6.6502 Mhz (1msec counter gate) and the post 2 second figure of 6.67244 MHz (10ms gate) and 6.68749 Mhz (100ms Gate).
Because the pixel clock must synchronise with the HSync signal, I believe the OSSC cannot see a regular HSync signal and will not remain in Sync.
I have tried combining the separate H & V Sync signals into CSync and injecting that into the SCART socket, but even using the HF filtering, sync is lost over the same 2 second time frame.

The Video setup was designed for a TFT LCD with 234 Horizontal Lines

What I now propose to do is to recreate an accurate pixel clock running at 13.560 Mhz, and using a binary ripple counter, divide that by 543 down to a horizontal line length of 73.69 us synced at the start of each frame to the VSync signal. The counter resets one the end of each horizontal line, on the negative edge of the just created HSync pulse (4.7us either from another counter or a timer)

My questions I suppose are these:
1) Is my suggestion of creating a new pixel clock and deriving my HSync pulese from that nonsense or workable? What, if anything do I need to look out for?
2) With a 13.57 Khz line rate each line is 73.69usec long Although I presume the Horizontal line timing length starts with the beginning of the Horizontal Sync pulse is this correct?
3) With a 49.72 Hz frame rate each frame is just over 20 ms. Again although I presume the frame timing starts with the beginning of the Vertical Sync pulse is this correct?
4) Do I need to take the writing speed of the RGB data into account when calculating line or frame timings. I cannot find any information about this in the datasheets
5) Just how accurate do my timings need to be in all this? What sort of tolerances am I allowed?
Thanks in advance for reading this – I hope you can shed some light on what is happening and how I propose to resolve the issues.

[marqs]

It’s a bit hard to follow your post (how come pixel clock suddenly change, and where are you suggesting it’d be fixed?), but it sounds like hsync period is not stable which is challenging to any video digitizer. You could try increasing “Hsync tolerance” from OSSC sync options (based on the numbers 2us could be enough), but even then there’s no guarantee the regenerated pixel clock is accepted by your display due to jitter.

[crippo2]

Thanks for your response
I can only surmise that the pixel clock rates changes are software driven in order to overcome a hardware limitation (cost/parts availability/design). The change, evened out over time (and possibly using an internal freewheel PLL within the display) might be the creative solution – who knows why, only that it happens and there is no way I can find out why (Commecially confidential etc)
As to reconstructing the pixel clock, I would take a commercially available 13.5600Mhz clock and divide it down, by 543 to give me a line length of 73.63us, some 60ns short of 73.69us. The Counter would start from 0 with the onset of the VSync pulse and each HSync pulse. The V Sync pulse would give the absolute counter reset once per frame with the H Sync once per line, relying on the accuracy of the count up to keep line sync in phase with the RGB data.
I will try your suggestion of adsjusting the HSync tolerance – and thanks for it.
kind regards

[Author]

Posts