Auto sync mode selection

Home Forums OSSC OSSC – Feature Requests Auto sync mode selection


This topic contains 7 replies, has 4 voices, and was last updated by  nmalinoski 1 month, 3 weeks ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
  • #8882


    In order to play a game in 480p mode on the Playstation 2, for example OutRun 2006, I have to do the following:

    1. Start OSSC in 480i mode (#1 on the remote for RGBS)
    2. Start the game, then instruct it to switch to 480p
    3. On the OSSC, switch to 480p (#4 on the remote for RGsB)
    4. In the game, press a button before the time runs out to confirm that it’s working

    It would be nice if the OSSC could eliminate the need for step 3 by switching automatically when it sees the RGsB signal on the SCART input. It doesn’t affect gameplay and so it doesn’t need to be quick like switching between 240p and 480i, so anything under 3 seconds should be good.



    I don’t think this is possible to auto detect. As an alternative you could use an extron interface or similar to convert sync on green to RGBS.



    With 480i content (RGBS #1), the OSSC says “NO SYNC” when it’s in RGsB (#4) or YPbPr (#7). Then with 480p content (RGsB #4), the OSSC says “NO SYNC” when it’s in RGBS (#1) mode, but in YPbPr (#7) mode it shows an image but with the wrong colors. I think this is the issue that is impossible to auto detect: how would it choose between RGsB or YPbPr?

    But if I could tell the OSSC to exclude YPbPr (#7) from auto sync mode selection, then conceptually it seems like it should be able to switch automatically between RGBS (#1) and RGsB (#4) modes, unless there are underlying technical issues.



    It’d be possible to automatically cycle inputs e.g. after 1 sec of sync inactivity. However, the list of cyclable inputs would need to be user-defineable, so that each one of the 9 inputs/modes can be included/excluded separately so that e.g. RGsB and YPbPr don’t get mixed as mentioned. In the end, I’m not sure if the end result would be that helpful taking into account the configuration effort required from user, but I’ll put this into consideration nevertheless. For PS2, the best way to remove this annoyance is to mod it to output RGBs regardless whether it is in HD mode or not.



    For PS2, the best way to remove this annoyance is to mod it to output RGBs regardless whether it is in HD mode or not.

    I’ve ordered the SCART cable with csync for PS1/PS2/PS3 and will report back with the results in a few weeks.



    So the SCART cable wired for CSYNC using a built in sync separator circuit had no effect compared to the sync-on-luma cable. The OSSC still needs to be in RGBS mode when the PS2 outputs 480i and RGsB mode when it outputs 480p.



    The console itself needs to be modded for that.



    I know this thread is nearly a year old, but I’d like to see this as well. If at least some level of automatic mode detection can be implemented, it opens the door to automatic input switching. Please forgive me if I’m off-base with any of this.

    Assuming that the OSSC can determine whether or not it has a valid sync given a sync type, I think a good starting point would be to set a per-input default for muxed sync, then start checking[1] the H-sync/C-sync, V-sync (AV3 only), and G/Y lines on the current input for sync signals[2]. In order of priority: if sync on H-sync and V-sync, assume RGBHV (AV3 only); if sync only on H-sync/C-sync, assume RGBS; and, if sync on G/Y, assume RGsB/YPbPr[3].
    [1] Triggered by holding Button 0 for 1-2 seconds?
    [2] Select between RGsB or YPbPr; system defaults could be YPbPr for AV2, RGsB for AV1 and AV3. (YPbPr over SCART and HD15 are less common, yes?)
    [3] Perhaps tapping Button 0 when using auto-detect could toggle between RGsB and YPbPr? Remote could still manually set mode if needed.

    Getting into automatic input switching, if the OSSC doesn’t find a sync signal after a timeout period (1 second?), it could start sequentially checking each input until it finds something.

    Sure, it’s not elegant; but it’d be something until a better solution comes along.

    As for trying to autodetect YPbPr or RGsB, would it be possible to check for quirks in the voltages? I’m not quite sure which standards are in use, and I’m probably reading this PDF incorrectly, but it looks like if the B/Pb or R/Pr voltages center on +350mV during the sync tip (or go negative during color data), the signal is probably YPbPr.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.