shmups.system11.org

The high frequency content that some people are experiencing can be handled probably with a little bypassing.

The noise NoAffinity was seeing looks exactly like the noise I was seeing before fixing the composite video ground. That was when we were seeing that banding effect on the solid backgrounds.

Thanks for the advice mobius. I will check those things you've suggested and make the ground connection on the board. I spent the morning removing the internal mod, removing the interface connector, lifting the necessary pins and wiring them to the fu-rgb, which is now on the top side of the ssds3. I was ready to wire up rgbs and test again, but had to head out for work. Glad I didnt quite get there because I wouldve been sorely disappointed if after all that I'm still getting noise but not yet knowing about the other minor mods needed to the fu-rgb. I will report back with progress tonight - hopefully good news.

Sent from my SM-G955U using Tapatalk

Absolutely. I took scope plots from a completely isolated signal with the analog connections removed from the SSDS3 and on a separate board. When compared with having the connections on the board and off the board the difference was basically nothing. It may have changed a mV or 2 but if so it was so negligible that we went right back to testing with all the connections still on board.

The composite video ground "might" be all you need to clean up your signal. If not, like Voultar said, some bypassing might be all that is needed. Definitely post up your results. Before the final rev comes out it would be awesome to cover any other little edge cases we can.

I grabbed a different PC-E that had some persistent noise. With this particular system, I believe it's behaving more in line with what FBX and NoAffinity is encountering.



I'm going to play around on the 'ole battered test board to see what we can come up with. But this is exactly what I was talking about earlier. All of these odd corner cases.

Yes, a lot of this could've been avoided by TerraOnion. But unfortunately, a lot of this is simply out of their hands, too. Everyone's gonna have to chip in. I thought that we had plenty of data, but there's abolutely no sense and benefit in rushing this along. Everyone dump your loins into this thread.

Good to know, thanks!

I'll get it installed when I can and let you know how it goes.

lmfao

I have some data to provide that might or might not be helpful since it's more general and not specific to the FU-RGB board (I don't have one yet). Short version is that even with all the SSDS3's video components on top removed (are there any on bottom?), the mini-DIN isolated from video ground, ALL video related pins on the SSDS3 female expansion port disconnected, and using Voultar's internal RGB amp in my Core Grafx....the SSDS3 _still_ leaks noise back into the internal RGB that isn't there when the SSDS3 isn't connected (or is connected but a real hucard is being used, thus basically turning off the SSDS3 from my understanding).
NOTE: My Core Grafx has been recapped and had the voltage regulator replaced with a L78S05

-------------------------------------------------------------------
Longer version previous posts from the main SSDS3 thread:
1st:
So I tried to replicate FBX's work on the video circuit to clean up the video signal on my PC-Engine when using the SSDS3. Like him I've got a Voultar PCE RGB amp in my PC-Engine, but mine is a Core Grafx rather than a Super Grafx like FBX has (seems like people with a Super Grafx are having better luck with video quality in general). I've also been turning off the video low pass filter (LPF) on the OSSC to see just how much noise is being introduced.

I got in my hot air station today and removed the video components from the SSDS3 and there was little or no visual difference, as expected basically. Next I was going to clip the video pins, but I can't get to all of them while the expansion connector is still attached to the SSDS3. I was able to clip RGB and csync however, so those pins never make it to the SSDS3. However, I can still see interference added by the SSDS3 even when loading hucard games from the SSDS3. This interference is far reduced (and not even the same pattern) when loading a real hucard.

All that's left for me to cut/disconnect is composite video A22 and analog video ground A21. To do this I'll have to pretty much desolder the expansion connector. Before I do this, I have some questions about analog video ground that I'm hoping FBX or someone can answer.

(Note, I am getting RGB from the PCE DIN port, and audio from the SSDS3 mini-DIN port)
So when I was checking things with a multimeter on the SSDS3, it appears only analog video ground (A21) is connected to the SSDS3's mini-DIN. Analog audio ground (A2) was not connected to the mini-DIN. If I disconnect A21, will that not cause some audio issues or at least make the audio cable shielding worse since the mini-DIN's ground would effectively be floating? I know eventually that the mini-DIN would need to be removed and remounted in a way that it's not connected to the SSDS3 in the future if I were to ever put a RGB amp in the SSDS3, but I was hoping to avoid that for now if possible while I'm just getting the video perfect and waiting for a thorough audio solution.

2nd:
Well, I got impatient . I desoldered the mini-DIN and expansion connector on the SSDS3, clipped composite video and analog video ground, glued the mini-DIN back in place on it's side with a piece of electrical tape between it and the PCB so ground would not reconnect, reconnected audio, and connected analog audio ground to the mini-DIN........ and it didn't really seem to do anything :\ (I also tested before putting the mini-DIN back in and it was the same).

I'm wondering if the Super Grafx just has more filtering or something inside the console. I recorded a video, but the recording plus youtube transcoding softened the noise effect some, but it's still visible. https://www.youtube.com/watch?v=Kmyds4gSsLc . When playing a game on the SSDS3 with the OSSC LPF disabled, there's 'digital looking snow', kinda like the 'snow' of a old bad antenna signal on an old tv. There's also some diagonal lines going across the screen at different speeds.

First game loaded is direct from hucard. The other ones are from the SSDS3. The LPF on the OSSC is off most of the time, but I turn it on for a couple of seconds twice or so (I was going to add annotations to the youtube video specifying where, but didn't realize they've discontinued the ability to do that).

Okay, here's where I'm at. cr4zymanz0r ^ it seems we're running somewhat of parallel paths...and getting similar results.

I grounded the 10uf/.1uf/75R cluster to the AGND pad. Is that the correct ground path? I poked around the FU-RGB and could find any other grounds, other than those that are continuous to the input connector and AGND (both continuous to each other). No noticeable improvement.

I removed all video components, I believe. Somebody please look and tell me if I missed any. No noticeable improvement.

I had to repair the Vout and GNDa pins that I had clipped. The system would not boot properly without these connected. They are not continuous on the SSDS3 to other Vout and GNDa pins. I'm expecting there's continuity within the CG2, but with those pins clipped and only routing to the FU-RGB with my makeshift wiring scheme, other components on the SSDS3 PCB that may be relying upon them are no longer connected to them. One verified component that needs that 5V source is the SD card LED.

My FU-RGB's do have the via at the tantalum cap - one via on the side closest to the 10uf/.1uf/75R cluster, no via on the opposite side.

Ohh, and those jailbars, as you can see in conjunction with the "SSDS3 Noise". I did the jailbar fix at C131 and C135, but no noticeable improvement on that either. That's a separate subject, just me whining.

With the FU-RGB LPF jumpered to 'on', the noise is relatively constant, regardless of the OSSC LPF setting. With the FU-RGB LPF jumpered to 'off', the noise is simlilar at 9mhz OSSC LPF, and gets more pronounced, cycling through 16mhz, 35mhz, 95mhz and off.

Those are my observations. I'm open to more guidance/advice.

All things equal to the previous screenshots:
OSSC default settings, line5x, Video In Proc LPF @ 9Mhz. OSSC output -> Elgato Camlink -> OBS capture @ Lossless (AMD R285 hardware processing), 1920x1080 @ 129Mb/s.

PCE jailbars are whack.
Sometimes they can be apparent or not just by power cycling the system.
Also I've noticed if you press against the RF shield on the lower pcb whilst the system is running you can alter the jailbars.


Tried to power the system with a OKI-78SR-5, dear god that was the worst so far...

Ok. Sorry I was extremely busy and didn't get time to respond to anyone. NoAffinity, the vias I was referring to are in between the pads for the tantalum capacitor. Basically if you check continuity at the On pad for the LPF, then you should have continuity with the AGrnd pad. If you don't, then you will need to connect a wire between those pads. I would also turn the LPF on.

What cables are you using for connecting to the OSSC? Is there anything in between the console and the OSSC, like a SCART switch. I'm not trying to blame noise on components being used, just trying to see a comparison with what all I used for testing.

Hey, no worries. The ongoing help is appreciated. Hopefully my efforts are of value, in return.

I checked - LPF on is continuous with AGND. I went ahead and solder bridged LPF to 'on'.

The SCART cable is a Genesis/MD Model 2 from retro-access: Genesis 2 32X/CDX RGB SCART cable with csync Multicore coax 5ft

I do use a SCART switch, from Otaku store. Before you pass judgement on that, please compare the pictures below. I grabbed screenshots from both scenarios - direct-connected to the OSSC, and connected through the switch. When connected through the switch, the connection is made from switch to OSSC via retro-access male-to-male lead.

SSDS3 direct to OSSC:


SSDS3 through SCART switch:


SSDS3 direct to OSSC:


SSDS3 through SCART switch:

No judgement here on the switcher. We tested with the switchers I have access to as well as direct connection. So if the on pad has ground connection, that's good. So we know that any noise isn't being caused by issues with the LPF floating. I have a few cables, most of which are from retro-access so similar setup there.

Just to cover bases do you know what tolerances you used for the onboard components? The ones I have built are all 1% except the tantalum cap. The majority of testing on my end was done with bone stock consoles. No new regulators, caps, or even jailbar fix applied. Just to keep things as controlled as possible. Although I did also test with console that had those changes made as well.

Now one thing you could try is connecting the outputs directly to the pins for the miniDIN. It seems unlikely that you are picking up interference from the traces but honestly with this, nothing is off the table in my opinion. I did not test with connections made at the pads, mine were all done directly to the miniDIN. Again, I doubt this would have an effect but stranger things have happened.

For those of you that are having a lot of noise problems despite the things you try, give this a go:

Do you see the picture I posted with all of the bypass capz? Look at the mini-din 9 port. See the 10uF ceramic that goes +5v to ground? Put a bypass right there. Do it for fun.

The only mod I have on the console is the jailbar fix. The internal bypass has been completely removed, and stock a/v out re-installed. I haven't touched it otherwise.

Component tolerances:
.1uf - +-5%
10uf - +-10%
75R - 1%
1.4k - +-.5%
1.8k - .5%
10K - +-.05%
220UF - 10%

Time to re-order some caps?

:edit: I just checked mouser and digikey, and the cap tolerances are the best available through them. I ordered the tightest tolerances. Is there a better source?

I will give the mini din removal and direct wiring a try also.

Voultar, could you post that pic here or link to it? I'm not finding it.

@NoAffinity, it's in the spoiler here. Been following the thread, learning a lot about circuit design here. Don't have an SSDS3 and probably won't get one, but it's still very interesting. PCE series has been a thorn in my side in terms of video quality whereas everything else has been pretty easy to clean up.

I already had the caps on hand but I bought them from Mouser a while ago. All the other values are as good or better than what I am using, So you should be good there too. Again, not trying to place blame on the components, just getting as much info as I can. I have a few more prototype boards that I can swap in to see if the results change in anyway.

I am guessing this is a no, but do you have an oscilloscope? If so, grabbing plots on a pure white screen would be awesome but not totally necessary. I have a very noisy white PC Engine that I have been doing testing with the most and I am betting these issues can be corrected, like Voultar has said.

^Ah, thank you sir. I will give that a try too.

Voultar - it looks like you had a 10uf between 5V and ground at the FU-RGB inputs, and at the mini din? Should I do both?

Capacitors. Capacitors everywhere! I would try both but do one then the other. If it cleans up after the second one, then remove the first and check again.

cr4zymanz0r, in your YouTube video around the 1 minute mark where the man is walking left and right is that some shadow or ghosting noise I can see moving with the character? I'm pretty sure I'm getting that too with my SSDS3 and internal rgb mod that doesn't appear with just a regular hucard or the turbo Everdrive from Krikzz.

By the way, Along with Bonk's adventure, Pac-Land is also a good game to test with its plain solid colors.

I would be more interested to see the results of putting the bypass right on top of the mini-din. Try it, first.


I'm just testing a variety of things, hence all of the capacitors. This absolutely isn't necessary, I'm just analyzing some other data and some AC stuff.

I put a 10uf at 5v->gnd on the mini din and tested. No improvement. Then added a 10uf at 5v->gnd at the fu-rgb input. Also no improvement. I will mess with mini din removal and direct wiring off the fu-rgb this weekend.

Sent from my SM-G955U using Tapatalk

I am watching this thread with great interest, thanks to anyone involved in finding a solution to this or just provide feedback.
I will hold on modifying my SSS3 until the best workaround is found atm I am just connecting the SSS3 output to a 14" PVM and I have good results with my recapped SGX.
There is some noise but it's not that bad for me... I really hate that I will have to remove my internal v69 amp - that thing is sensual and it produces a great result when I use my SGX with an ED

I finally got around to pulling the SSDS3 av out, and rotating it so the FU-RGB is directly wired to pins at the av out that are not touching the SSDS3 PCB. I made sure to put the 10uf cap back, between 5V and ground, at the av connector pins, also. No improvement. This screenshot from Fantasy Zone captures the interference more so than previous screen shots...it is quite visible in the gray and pink areas. I'm open to any other suggestions, but at the same time, there's no need to hold up the project just for this one edge case, unless there are likely more out there that could benefit from continued efforts. What I'm trying to say is - it would be nice to get rid of the interference on my setup, but I'm perfectly fine living with it. The benefits of the SSDS3 far outweight the minor annoyance of that interference in the image.

Voultar has some theories but I don't want to speak for him. I know I am going to test out a couple things myself. I would like to see something that ultimately cleans up the majority of the cases.

While in my testing I haven't see what you or others have reported, that doesn't mean we can't try a little more.

Installed another bypass board today. All new components. Different SSDS3 that was previously untested. Noisy white PC Engine I got for $20 and have never done anything to.
If anyone wants these photos sent to them, just ask. I am happy to share. All photos are PNG and should be lossless.
All pictures captured with OSSC at 720p with no settings changed otherwise. All captured using Datapath E1S.

Stock SSDS3




FU-RGB Board installed





For comparison, I also captured a completely recapped/jailbar fixed Duo R with Voultars V.69 RGB Board

On those last two pics, were they with the SSDS3 as well? Were all the pins hooked up?

The final 2 pictures in that post are of a fully recapped Duo R with jailbar fix and Voultars V.69 RGB board installed. I included them as a reference.

Here are a couple more pictures that are with the OSSC LPF expressly set to off. All other settings are default and capture parameters are exactly the same as before with the noisy white PC Engine and SSDS3 with FU-RGB bypass installed.

I'm open to any and all suggestions. I'd like to get everyone's input in before we really start spinning up the actual FU-RGB PCB for everyone to use.

I wish I could catch all corner cases, there's just so much diversity between PC-E hardware.

I have another SSDS3 board and another FU-RGB I am hoping to test tonight. I will be attempting to verify the same results I had seen previously. I can also try out some of the other consoles again if we want more diversity. I have been primarily using the noisy white PCE since it's the worst one I have.