Hi.
I'm planning to build one simple schematics / device which will convert analog video signal to digital. The analog video signal comes from camera over bnc and it has PAL / RGB format.
Could this kind of chip do the job :
or
On a sunny day (Fri, 14 Dec 2012 15:20:59 +0100) it happened h200 wrote in :
Get a video digitizing USB stick with build in mpeg[2] encoder. Those are dirt cheap these days (25 $ or so). Else you get a data rate problem if not encoding to some compressed format, where is the data going?
Do you mean PAL or RBG format? Most cameras produce composite video ie PAL or NTSC and not RGB.
If the former there are many cheap decoders. Digkey has the TVP5150 at £4.47 for one-off though I have never used it. I currently use a Techwell TW9900.
Decoders accepting RGB inputs are less common, probably since they require 2 ADCs like the ones you mention.
-- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
--------------- You are correct, PAL is mostly used and I will take this as base. I was thinking to take any analog camera, maybe some cctv camera, connect the BNC output of this camera to my portable device and transfer the data over rf. Maximum distance is around 20 meters.
Camera --> video ADC ---> RF transfer ---> video DAC ----> monitor/ TV.
I can not use USB because this should be some kind of camera adapter an it has to be portable.
TW9900 looks like very good solution. What do you think, can i use it in my project ?
There are some cheap video transmitters and receivers that would do precisely what you want without recourse to the digital domain.
Why does it need to be so complicated?
-- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
-------------- :-) because i want to upgrade this project in the future. So what do you think, can TW9900 do the job ?
Most video decoders are simple to use and fairly forgiving. They are all much of a muchness. The TW9910 will do the job of converting a composite video input into 8 bit parallel YUV 4:2:2 data with embedded syncs. All you need is attach a crystal and set the device up through a I2C interface.
I feel Decoding/conversion is the easy bit. How were you going to transmit this with RF over 20 metres? Have you calculated the data rates?
-- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
------------------------------------------------------------------------ OK. I will use TW900 as ADC. How would you construct the DAC part ?
I didn't calculated the data rates but i was planning to do this after i'v done the ADC / DAC part. You see, the transmit part should be fully adaptable to all kind of transfer options.
I still have a considerable stock of an old Conexant video encoder which is now obsolete. So I'm afraid until these are exhausted I'm not going to be much good when it comes to sourcing alternative video encoders.
All I can suggest is have a look at Digikey or equivalent for video encoders.
-- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
The PAL composite format is intended to be simple to transmit/receive over RF carriers. So, why convert it to something digital, which is NOT simple to transmit/receive? Put your PAL decoding at the endpoint, not the origin, of the RF transmission.
Digital transmission over RF is very noise-sensitive, and the kind of error-correction that digital TV does nowadays is beyond the scope of most 'project' work.
--------------------------- Digital conversion give me more space for some future , advanced use. In some time, i will try to transfer this video over laser....
Simple modulation systems are actually multipath sensitive, even if the average field strength is quite high.
For this reason DMT/COFDM systems are typically used.
For a point-to-point link with direct line of sight (LOS) path, the laser is a good solution and it might be enough to amplitude modulate the laser with the baseband signal. However, this requires that the transmitting laser is aimed _exactly_ towards the receiver, thus. any portable/mobile applications are more or less out of the question.
I'd convert the video to streaming MPEG so you can transport it anywhere you want. Wireless? No problem, just setup a Wifi bridge.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
--------------- I was thinking about streaming MPEG but i dont know if this could be the solution. Maybe it cauld be because this is standard for something like this.
I dont want to use WIFI. There are bunch of problems regarding this kind of transfer. I'm in cctv security line of work and trust me, wifi is not something that you want to use. Of course there are some quality solutions but they cost like hell.
Back to the subject :-)
What kind of video ADC and video DAC would you use to make the encoding / decoding ?
TW9900 is for me still the best solution for video ADC but i dont know how to decode this digitalized signal.
On a sunny day (Sun, 16 Dec 2012 18:54:56 +0100) it happened h200 wrote in :
Try some math, for a 720 x 576 RGB picture at 25 fps that is 8 bit deep, you need:
720 x 576 x 3 x 25 = 3,110,400 bytes per second, makes 248,832,000 bits per secondA 248 MHz wide radio channel. Sending YUV is a bit less (1.5 x) and JPEG is also better. JPEG is better for security as it has no motion blur (each frame is sharp).
A 248 MHz wide radio channel is not in your country or on earth unless you go THz, and then the distance sucks. And that is just as easy to jam from a security POV as WiFi. I run 2 WiFi security cams, and it works perfectly. With jpeg compression you get at most 20 fps over normal WiFi. Modern webcams already compress to H264 or some variant of mpeg.
Only wired is sort of safe for security, but then they do other things(tm) to it. All depends on what you want to protect.
That was 1000$ advice, now go to sleep and tomorrow think of some other thing.
Oops: Try some math, for a 720 x 576 RGB picture at 25 fps that is 8 bit deep, you need:
720 x 576 x 3 x 25 = 31,104,000 bytes per second, makes 248,832,000 bits per second ^^ dropped a zero
need:
second
While in an uncompressed format, loosing a few pixels, perhaps some lines or even a whole frame is no big deal, since the next frame will contain valid data, hiding any transmission errors.
However, in any delta-modulated systems (such as JPEG) loosing some pixels will propagate along the line. In MPEG, any bit errors in the I-frame will propagate through the P and B frames (typically 0.5 s).
Thus, in an uncompressed (analog/digital) video stream some random errors are acceptable, however, if you are going to use some compressed format, a 100 % reliable transmission path is required (such as TCP), but of course, the latencies can be anything.
need:
second
THz,
it.
One Hz of bandwidth is not required to transmit 1 bps of information. It all depends on your SNR.
I doubt some self made solution is going to cut it if you want low cost. Developments costs can rise quickly. If cost is an issue I'd go for commercially available network camera's with Wifi like the ones from Axis. Proprietary wireless connections are prone to jamming without people knowing it. If someone jams the wifi frequencies it will get noticed.
Come to think of it. AFAIK one of my customers sells a high resolution (several Mpixels) wifi or wired security camera which records video and audio locally if the connection is not available. They also have a central storage facility where people can access the recordings through internet. Its a pretty neat package and relatively low cost.
Like others pointed out: if you don't know about the wireless link then it is no use to look into coding/decoding. Besides that PAL signals are already intended to be transferred over wired and wireless connections. I'd concentrate on transferring PAL over wirelles or wired connections. This is old and well known technology.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
On a sunny day (Sun, 16 Dec 2012 20:49:53 +0200) it happened snipped-for-privacy@downunder.com wrote in :
Same for jpeg (moption jpeg only uses that one pictrure, it is just a stream of jpeg pictures)!
No, you are confused with mpeg h264 liek systems where you have a whole frame transmitted only very so often
In case you care, I wrote all the soft for that stuff:
Actually the current version has support for those cheap movable Chinese JPEG cameras too (I have one). Their format is slightly different from the DCS900. Not sure if I uploaded that to the website, Have not had much time for the website... Else ask me if you want to use those cheap cams.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.