Random flicker

[caiosilva1993]

I'm having small problems with my GBS with Nintendo win emulators and games in 240p. Sometimes the image flickers randomly with Nintendo wii emulators in 240p. I did several tests. I disabled and enable the clock generator, disabled and enabled the frame time, checked the cables, enabled the sync button, changed the power source and updated the firmware. But nothing resolved. Any solution?

[nyanpasu64]

Did you connect a Wii to the GBS-C using component cables?

In the web UI, on the fourth Settings tab, check Developer Mode. What messages appear in the console to the right when the flickers occur?

[caiosilva1993]

I have two nintendo wii, NTSC and PAL, I tested using Ypbpr and RGB, in both cases this anomaly occurs, more specifically when emulating in 240p. Consoles like the SNES this is not observed. The only information that appears in Developer Mode is a dot. Most of the time, nothing appears. When the nintendo wii is connected to my CRT or through OSSC this is not observed. I tested with three powers supply and nothing solves. Flicker is a vertical oscillation that occurs quickly and ends.

[nyanpasu64]

The image shifts up or down for a frame or so? Maybe you're losing sync. Possibly the issue is related to https://ramapcsx2.github.io/gbs-control/Wiki/Sync-on-Green-Capacitor-Replacements.html. Not sure, this page says you shouldn't replace the capacitors anymore? I don't know if you could have a bad GBS8200 either.

I haven't noticed any sync dropping on my Wii, and I didn't implement sync myself, so I don't know how to debug the problem further.

[caiosilva1993]

Here is a example. https://user-images.githubusercontent.com/81496717/229400868-72709c6e-a359-47c0-9670-202b37ebb8d1.mp4

[ramapcsx2]

In the Web UI, is there a developer option to disable the syncwatcher? If so, please try that, once the console shows a normal image.

[caiosilva1993]

I turned off Syncwatcher but without success, the flicker continues. I believe it is an incompatibility of the Wii in 240p mode with the GBS, because in the ossc this is not observed. I have another GBS without the genarator clock and curiously I don't observe this happening intensely. Despite having disabled the clock genarator nothing resolved. As I said, the SNES works perfectly.

[caiosilva1993]

I'm using the latest firmware and testing with the wii at 240p with the fce ultra gx emulator through the component cable connected directly to the GBS. This time I got this message. What does that mean?

[nyanpasu64]

Disregard the frame sync errors, it's a warning that appears during console reboots, maybe video mode transitions. Perhaps I should hide that message by default, since it's a normal occurrence when the input video signal is interrupted? (It was useful when I was still developing the algorithm and making sure it handled video interruptions correctly.)

[mastercheff]

I had similar issues with xbox connected with component cable. Replacing capacitors c33, c35 fixed the issue for me.

https://ramapcsx2.github.io/gbs-control/Wiki/Sync-on-Green-Capacitor-Replacements.html

[mastercheff]

The xbox was in 480p/passthrough for clarification. One issue I'm still having on some units (did like 8 gbs builds overall for LAN purposes) is the lack of balance on red color, similar to this thread:

https://github.com/ramapcsx2/gbs-control/issues/186 https://github.com/ramapcsx2/gbs-control/issues/282

manual adjustments would be sweet...

[nyanpasu64]

Flicker

I've built a rig which sends the video signal across a set of RCA jacks. By flicking the thin metal prong to momentarily break contact with the wire, I've been able to make the image flicker (glitch and shift horizontally/vertically), in a way which resembles caiosilva1993's description of "a vertical oscillation that occurs quickly and ends". In passthrough mode, the same flick of the wire causes the image to cut out altogether for half a second.

@mastercheff did you feed 480p into the GBS-C? When you encountered the loss of signal, did you set the GBS-C to fixed passthrough mode, fixed 480p scaling mode, or a saved preset (and which scaling mode)? Did the image cut out for half a second, or glitch out momentarily and resume frames as usual?

Color tint

When you refer to lack of balance, do you mean that black/dark colors appear tinted because offset is wrong, or all colors including white appears tinted because color gain is wrong?

• calibrateAdcOffset is supposed to switch to a null input and increase offsets ADC_GOFCTRL etc. until the image changes from gray/colored to near-black.
  • Then at runtime, since IF_AUTO_OFST_EN (chip internal auto offset) is turned off // not reliable yet, the boot-time offsets adco->g_off etc. are applied.
• However, the current code always writes the same gain to all 3 channels.
  • This could be changed (add 3 separate types of gain commands, perhaps n{rgb.} and o{rgb.} to avoid taking up more character slots), at the cost of complicating the UI with 3 sets of RGB gain buttons, on top of all-gain buttons.
  • In theory you could change runAutoGain to adjust all 3 gains separately, and read them separately as well by writing to GBS::DEC_TEST_SEL like calibrateAdcOffset does. But if exposed to a screen that isn't uniformly white, it might separately fail to reduce gain sufficiently for each of the RGB/YCbCr input channels, leading to random RGB color tints or component saturation errors (even on otherwise-unaffected hardware), which IMO is harder to diagnose and fix than merely too-light images.
  • Note that I could be completely wrong in any of this; I'm going off my limited fallible understanding of the hardware.

I don't see how color gain errors (not offsets) can even happen due to component input gain errors. If you are getting color gain errors, I'd conjecture that the output gain is wrong. To test that, can you open a white screen, click the "+ gain" button until brightness is clipping, then check for output color tint (perhaps post a picture if it preserves white balance) on both black/dark gray and white screens? (If the color tint increases with "+ gain", then it might be an input offset error, or not, I'll have to see pictures.)

[mastercheff]

Regarding sync losses before changing capacitors, there were split second screen flashes on busy and bright scenes , like every 40 seconds of gameplay . Source was xbox set to output 480p, high quality diy component cable , gbs settings was just passthrough button in the gui (it gave me better colors on vga crts than scaled? 480p), i've not tinkered with presets at all.

Color issue is a bit complicated because it varies by unit. Documented cases talk about red color being most prominent, my one troublesome unit lacks blue. I've tried manual override suggested by my programmer friend

but the resulting picture has instead blueish tint on all colors

with stock unmodified .ino, and default settings (ADC on) blue dashboard looked like this

severe lack of blue, I'm expecting it may be hardware related malfunction, It's a cheapo chinesium board after all. My other units behave as intended...

[nyanpasu64]

I got flickers much less often, on the order of minutes to hours. By "split second screen flashes" do you mean the screen went black for half a second? That sounds like the same problem I have but much worse. Maybe the issue occurs more or less often due to hardware variation.

Honestly I think it's time to open a separate issue for the color malfunctions. Can you create a new issue, post all the images (and link to past color issues), and reference this issue there so I can find it? Also if possible take images of solid black and white screens, as well as 240p Test Suite's SMPTE Color Bars (do you have a Wii to run it?), with the unmodded .ino file (and optionally modded)?

[mastercheff]

screen blinked momentarily rather than went black for half a second. I will try to document my issues and open separate issue, but that will be couple of days from now (I do have a wii but no component cables atm)

[nyanpasu64]

What color did the screen blink? Did the image contents shift or not?

One interesting thing I noticed is that in passthrough mode, when I briefly interrupt the GBS-C's input signal, I get half a second of black screen on my CRT (Gateway VX720, like Diamond Pro 710), and two seconds of black screen on a 2011 LCD with VGA input (Dell U2312HM). This means that when you interrupt the GBS-C's input and output sync, different monitors take different amounts of time to show an image again.

It's possible your screen blinks very quickly because the GBS-C actually drops sync for only a frame or so, and your monitor regains sync faster than both of mine. After rebuilding my VGA probing rig (with an actual PCB this time, instead of just dead-bug wiring on cardboard and snapping off SMD resistor pads every time the cardboard or wires flexed) and hooking up to my audio interface, I found that artificially introducing a luma glitch would produce a single long/short, missing, or extra vsync pulse. Despite the extremely short length of the glitch, it would take 0.5-1 second for my CRT to recover, and 2 seconds for my LCD to recover. I suspect your natural sync glitches cause the same effects in the GBS-C. One remaining I don't know if natural glitches cause long, short, extra, or missing vsync pulses, or hsync distortion.

All in all, I suspect that on bad boards prone to natural sync glitches (everyone in this thread), swapping the SoG capacitors is necessary to avoid random sync drops. Should I keep spending time experimenting with various GBS-C configurations and video modes, and testing for hours at a time, to gather more data about when and how exactly the issue naturally crops up? (So far I've only experienced it in custom passthrough, but you said it also appears on fixed passthrough, and @caiosilva1993 says it happens on 240p upscaling.) Or should I proceed under the assumption that on marginal boards, sync glitches are inevitable and the current firmware fails to fully avoid them, and swap the caps and hope it solves things?

I do have a wii but no component cables atm

You can hook up composite video sources to GBS-C luma input, and get a monochrome 240p/480i only image. If your Wii is homebrewed (https://wii.guide/), that should be enough for black and white screen tests, but not color bars.

[mastercheff]

The screen blinked, and that's the only thing i can recall now, I did them almost full year ago, and all units showed similar behaviour. Luckily changing smd caps worked first try, the wiki says it's redundant now for me it was not.

My wii has only euro scart cable, I enjoy it most on consumer sony, but with some spare time I will attempt to build component too. I think I will just use genesis/md emulator on the xbox to run 240p test suite (despite being rendered in wrong resolution) should do the job

[nyanpasu64]

@mastercheff can you verify that C35 and C34 are bridged on your PCB (on the side away from the chip), and C33 and R34 too? I hope I didn't make any solder bridges by mistake, and when trying to clean the C33-R34 bridge with a X-Acto knife and replace/resolder C33 I managed to break the solder mask on the PCB and expose what looks like a a copper trace connecting the SMDs.

---

EDIT: i replace the sync caps and tried custom passthrough on wii 480p.

while dusting my CRT monitor, i got a static shock, as well as sync dropout again. this time accompanied by text:

.
2

this time i know the shock killed sync. but was it my crt's internal arcing all along? or the bad clock generator? idk.

[mastercheff]

No bridges on mine, just proper value caps in place of the old ones. Surplus amount of flux is a must , fine iron tip and a pair of tweezers. I always re-check my job.

Funny thing is I experienced similar arcing on my diamondtron crt, when the humidity got high and the monitor was not in use for longer amount of time. I suspect there was condensation in back of the tube (neckboard area) , in my case it healed itself after prolonged use and water must have evaporated, no zaps past year - effects on screen were strangely similar to dropping sync

Clockgen only affects screen tearing when upscaling to hd afaik, first gbs I build (with clockgen board) works the same on vga crts as units without one , it has nothing to do with sync (or am i wrong)

[nyanpasu64]

No bridges on mine

After resoldering my caps I checked that the ends were not continuous with adjacent caps using a multimeter. It beeped for continuity even with no visible bridge. Looking at https://ramapcsx2.github.io/gbs-control/Wiki/Sync-on-Green-Capacitor-Replacements.html, I see a PCB trace between the bottom of C33 and R34 (can't tell between C35 and C34):

• [ ] Can you check if the two pairs of SMDs are continuous, using a multimeter?

I experienced similar arcing on my diamondtron crt

I remember several months back I heard a pop when I was not touching the screen and collecting static electricity, and the CRT image shook out the corner of my eye. I assume that was an internal arc, and it hasn't recurred (fingers crossed). I've lost sync from static EMI when touching my screen, and getting electricity between the glass and my hand (and whatever wires I touch) without an internal tube/neckboard/flyback short.

or the bad clock generator

sorry you're right, i had scrambled brain and was mixing this up with other people's bad clockgens I was debugging in parallel. I don't know if the past CRT losing sync was caused by CRT EMI shock/interference, or bad SoG caps. I hope it was the caps and my monitor isn't dying.

[mastercheff]

The troublesome unit is at the moment at my friend's house aka lan place, I can't check it until weekend and that is not guaranteed...

Your case sounds more likely to be anode cap leaking, or flyback issues. I would definitely open the unit and check for cold solder joints near the flyback and reseat anode with fresh silicone , corona discharges would be easily visible in the dark, Fingers crossed dude it's just slightly dangerous :D

[YoImLee]

@nyanpasu64 I took an up close image of the SMDs, as you can see there is indeed a trace between both C33-R34 and C34-C35.

This was taken of a v4.0 board, but I've performed the SoG capacitor mod on all of my boards (v4.0, v5.0 and an 8220 v3.0) and the arrangement is the same. In my experience the mod eliminates sync loss/glitches on bright/flashing screens on all 3 of my boards. (Except when using my PAL Wii using RGB Scart, possibly because it's the only cable using composite video as sync. Integrating a sync stripper circuit in the cable fixes that.)

[nyanpasu64]

In any case I still experienced flicker on my board (https://github.com/ramapcsx2/gbs-control/issues/461#issuecomment-1555393476) after replacing the capacitors with https://www.lcsc.com/product-detail/_YAGEO-_C100040.html. I think my issues are caused by a different root cause than purely sync voltage glitches, and I'll have to debug further when it occurs and if I introduced it by mistake (perhaps in https://github.com/ramapcsx2/gbs-control/pull/446 while fixing a different bug?).

Or did I order bad capacitors that don't meet the SoG filter spec? I think this is rather unlikely, but I can't rule it out yet.

@caiosilva1993 you should still try replacing the sync capacitors and see if it fixes your issue.