Help coming up with Anti-BLUESCREEN device

I am wanting to make some sort of device that can take a video signal input (via RCA), and introduce it's own sync signals so that even if it is only static it will still show on a display that normally blue screens when no video signal is there. So does anyone know of any IC's (preferably DIP package) that are capable of doing this?

Are you trying to stop a BSOD or stop the annoying static noises and picture like a tv does?

Yes to stop BSOD, allow static to show on a device that would normally not. There must be a chip available capable of making it possible.

BSOD is not something you can just simply stop. It is what happens when a sever system error has occured in windows. BSOD changes according to what the error is. Not only is is it not easy, its also pretty important that you see what caused the error. When a BSOD happens, you may not understand everything, but there is one thing that you should look for, the file name of what caused it. Sometimes its an exe, sometimes its a dll, other times its other things.

You would rather see just static over a BSOD? with static, you have no idea what happened. Even with what you are talking about, it doesn't stop the BSOD, the computer will still run through the BSOD procedure, the only difference will be that you won't be able to see anything.

I am not talking about computer BSOD, someone else called it that, I am talking about ntsc and devices that show a blue screen when the sync signals degrade. I want to make a device capable of keeping a valid sync signal even when the input video feed degrades to a point where it's signal is no longer valid so that even if the video statics the display device will show it because a sync signal is there and valid regardless. I have seen some mention the lm1881 however it does not actually remove the original sync signal.

Hm, I don't quite understand, lemme call grumpy_mike, Crossroads, and James in on this one. They may know what to do.

I pass.

I know it is doable, there are video DVR's that will take video feeds and also have output that will cause a normally bluescreening device to not bluescreen, granted they are processing the video and re-creating the output, there must be a chip capable of taking NTSC video signal, stripping the sync signals out, and re-creating them for output. The purpose is for FPV/UAV flying, as many devices will show bluescreen once sync is lost, however when you are flying an aircraft that could be 1 mile+ away from you, and the video starts to screw up a blue screen is not what you want to see :). Some have suggested time based correction circuitry such as what a VCR used to use, but I am not sure on what that consists of.

To be quite honest, the arduino isn't that great of a video processing platform. It runs at a relatively low speed for that kind of work. Platforms such as the raspberry pi would be better for that. And to be quite frank, I don't think this project is very commonly done. We'll see what Grumpy_Mike says if he gets in on this but other than that, its more of a project for a stronger platform.

Oh I know that Arduino isn't strong enough to process any video, but I don't want it to necessarily process any video, just control another chip capable of doing so. Really all that needs to be done is strip sync signals and re-create them but synced up to the incoming video, that way if the broadcast video being input loses sync signal the device will fill it in allowing for what appears to be a valid video signal through to the viewing device. I also plan on making a video diversity system built in too, though that should be a much simpler task.

Producing a "Blue Screen" is a complex undertaking, For plain Video, NTSC or Computer> for NTSC (Never the Same Color... twice) you only need to generate the horiz and vert sync signals and the color signal necessary for blue. That's easy,,, the trick is to re-insert the signals in place of the other "Crashed" one and do so in the same EXACT PHASE as the ones that created the original video signal that you are trying to "recover" without that you will totally corrupt the existing signal, which is corrupted already and why the picture is "Pixelated". It is time determinant and possible but nearly impossible in practice without studio type gear. Which is network time determinate already since now most major video feeds are locked to a standard atomic time clock. Good Luck in the Contest...

Doc

I don't want to produce a blue screen, I want to AVOID it. A lot of video devices today will blue screen when sync signal is corrupted, I want to make it so it shows static and NOT blue screen. When flying model aircraft using a video feed (FPV, First Person View), you don't want the video to go blue just because the signal is getting screwed up, often times you will still be able to make out enough to still keep flying, but with blue screening devices you will lose all video well before the static is too bad to actually still see a picture. For example I use a DVD player with video input for viewing the live video feed from my model plane, it does not bluescreen so when the signal gets crappy I get static, however many modern video devices do not do this, nor do a lot of DVR devices, they will blue screen / stop recording when the signal starts to go, I want to circumnavigate this. There are devices such as the Japan DVR which can take a video input feed, record it, and output the feed but with a fully valid sync signal, therefore the device that is hooked up to it's output shows static even when that device would normally blue screen. There must be an IC out there capable of doing this!

Ok what I think you want is a system that will replace the sync signals on a video input if the original video input fails.
This can be tricky but it should be doable.
One way to do it would be to use a video switch that will select between your normal video and your replacement video source.
The replacement video source could just about be and arduino running a video overlay program. Then you are left with the task of spotting when the original video source fails. I would do this using a missing pulse detector on the line sync pulse, a 555 should be sufficient for this task. The output of this missing pulse detector then switches over the video source.
Is that the sort of thing you are after?

Well I don't want to switch to a different video feed, I want to keep the original input feed but keep a valid sync signal so that even if the input video goes bad, it will still output but with a valid sync signal, so that even if the picture starts to snow out the target viewing device will still see a valid sync and NOT bluescreen like would normally happen.

Basically get rid of the incoming videos sync signal, regenerate it and pump out the original video + new sync signal, that way output is ALWAYS a valid sync signal for NTSC (Supporting both NTSC and PAL would be prefered).

Not really possible because yu have to keep track of original sync time/phase and switch when the orignating synch/time becomes lost/unusable...

Doc

If you don't use the idea of switching video sources you need to syncronise the blank video source with the real video source. That is the sync pulses must be exactly in phase. This is a difficult thing to do and impossible on an arduino because these pulses must remain in phase even when the signal that syncronised them is gone. This would involve a complex phase locked loop and is not something that could be simply described in a forum post. It would be quite an involved design. Google the term genlock this reffers to a circuit that locks video sources together but requires your video source to be able to accept a syncronising oscillator input.
What form is this video in? Composite or RGBS or som other form. This is important for any solution.

I can't take not possible as an answer because there are devices that already do so, granted they are processing the video before output and if that is how it can be done then there must be a way to do it!

He didn't say it was flat out impossible. I said it was impossible on the arduino. The other platforms probably aren't using the arduino as the brains.

Grumpy_Mike:
What form is this video in? Composite or RGBS or som other form. This is important for any solution.

The MAX7456 video overlay IC can generate a sync signal - I've used it as a display driver, with no input at all. It has some modes for detecting sync in the input, too. Of course, it's for NTSC/PAL, not sure what resolution you are using.

As others have pointed out, it won't magically make a weak signal appear. Sounds like you need better gain at the receive station; maybe an amplifier or directional antenna.

-j

The problem with Genlock is that it requires the original information's synch signal and there is no (to the best of my knowledge as I date from the tube and early non digital systems information contained withing a video line to regenerate the synch information when it is lost and the data it was encoded with unless you can store a lot of lines of video or count them to try and detirmine the frame synch that way, either way it does exceed the limitations of this forum because of the nature of the task and it's inherent complexity... IMO

Doc