[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

[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

[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.

[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, 7 months ago by crippo2.

[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

[Author]

Posts