Searching \ for '[PIC]:using a pic to write video data to vcr' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/displays.htm?key=video
Search entire site for: 'using a pic to write video data to vcr'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:using a pic to write video data to vcr'
2001\10\22@200923 by DFansler

picon face
I am working on a conceptual project of using a VCR as a data storage
medium.  The idea is to use the audio channels to carry music and the video
channel to carry data that would be used to control things.  I did a search
on the Internet and found that there are data storage units available to run
off a PC, but I would rather have a data format of my own choosing.  I admit
up front that I do not know very much about video signals.  Has anyone else
developed such an idea, or does anyone have URL's available that I could
look at to get a better understanding of what I need to do?

Thanks,
David

David V. Fansler
spam_OUTDFanslerTakeThisOuTspamMindSpring.com
http://www.DV-Fansler.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\10\23@135041 by M. Adam Davis

flavicon
face
It sounds like you may be trying something like animatronics, where you
have audio coming out, and a data channel controlling devices.

Is there a reason you can't use audio tape?  Use the left channel for
data, right for audio, or encode stero onto one or both mixed in with
some filterable digital data?

How much data per second do you need to store, and what are your audio
requirements?

-Adam


David V. Fansler wrote:

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\10\23@154322 by Peter L. Peres

picon face
Someone already makes such a product, it's a PCI card with an ASIC on it
and RCA jacks for video in and out.

The way to go is to examine what you can afford in codec complexity and
then implement something that works. As long as you generate correct h and
v sync signals you can make the vcr record anything you want.

Peter

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2001\10\23@173234 by Mike Hardwick

flavicon
face
David,

I've done this, so I'll try to shed a little light...

Circuit Cellar published an article on a VCR data storage adapter several
years back. It might be worth looking up, or perhaps someone else on the
List can say which issue it was in. I recall that fairly elaborate
processing was used to correct for data corruption, much like a CD.

Video Demystified by Keith Jack is a good book on video.

Basically, you must generate the composite sync part of a video signal,
then add data modulation in the 'unblanked' portion of video scan lines. By
unblanked, I mean the portion that normally carries image modulation. You
need composite sync to fool the VCR into working normally, but most VCRs
don't require technically perfect color sync with all of the serrations and
equalizing pulses. Video head drum rotation is very tightly phase-locked to
vertical sync. Video head switching occurs 3~4 lines prior to vertical
blanking, so it's a bad idea to use scan lines in that area for data.

The Closed Caption system puts low-rate data on line 21 only, which is the
last line of the vertical blanking interval (VBI). Line 21 wasn't
previously used to carry any information. If you want high data bandwidth,
you might also take a look at Teletext system standards, e.g. WST. Among
other things, they add a clock preamble to each line of data, to circumvent
VCR playback timing jitter.

For simple applications, consider encoding just one big fat (up to 50uS)
data bit immediately after each horizontal blanking interval outside the
VBI. Net data rate is around 15Kbps. This scheme requires minimal data
encoding and recovery circuitry. Your data recovery micro has to get H and
V sync, and the output of a comparator that slices active video levels.
Comparator input video has to be DC-restored, of course, but cheap
comparators like the 311 are entirely adequate. Your code has to find V
sync, count H sync pulses to the first active line, then march in data bits
at some loosely defined time after each subsequent H sync pulse up 'til VBI
start.

Watch out for the VCR's dropout compensator (DOC) if you try this. The DOC
"fixes" video playback glitches by substituting good video from the
previous scan line (from a 1H delay line). Some VCRs have a switch to
defeat the DOC.

Mike Hardwick
Decade Engineering


>I am working on a conceptual project of using a VCR as a data storage
>medium.  The idea is to use the audio channels to carry music and the video
>channel to carry data that would be used to control things.  I did a search
>on the Internet and found that there are data storage units available to run
>off a PC, but I would rather have a data format of my own choosing.  I admit
>up front that I do not know very much about video signals.  Has anyone else
>developed such an idea, or does anyone have URL's available that I could
>look at to get a better understanding of what I need to do?

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


2001\10\24@184624 by DFansler

picon face
-----Original Messages----- cut

David,

I've done this, so I'll try to shed a little light...

Also written among others:

VCRs were tried and abandoned as data storage devices many years ago. Among
the problems with analog VCRs include the probability of loss of frames or
noise, etc.

The quickness of the list is great.  As with any questions there are the
answers you want to hear and the ones you wish you did not have to hear:)
What I am looking at doing is using a VCR as a playback/control unit for a
laser display.  Having the music sync'ed by being on the tape with the
control signals would be a plus.  I am also looking at getting out as
cheaply as possible. I understand that perhaps a VCR is not the highest
speed, best device around - but the cost makes it attractive.  So here is my
idea - given that one frame consists of 512 horizontal lines, repeated 30
times per second (NTSC), then if you were to encode just 8 bits on say 400
lines out of 512, there should be enough data - I imagine to do control and
display.  I would not think this would be asking a lot from a VCR setup.

After doing an initial search on "VCR data storage" I wrote the original
email to the list.  After sending the email, I did another search on
"understanding video signals".  One of the hits was for
http://www.rt66.com/dthomas/pic/pong.html .  This was a project a gentleman did
that used a single 16C711 PIC and a few other components to re-create the
famous Pong game.  The really neat thing is that the PIC program is divided
into two sections - 1st is a "video engine" that setups the timing and all
for outputting a NTSC signal.  The 2nd part of the program is the "user
part" which is the Pong game itself.  His whole reasoning was to create a
video engine that could be used for various applications by just changing
the user part of the program.  I have downloaded the info.  Unfortunately
for me, he wrote the program using the Tech Tools/Parallax PIC mnemonics.  I
am currently converting the code back to standard MicroChip mnemonics so I
can better understand it.

Thanks to the list for all the input.

David V. Fansler
KILLspamDFanslerKILLspamspamMindSpring.com
http://www.DV-Fansler.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\24@185245 by Tony Nixon

flavicon
picon face
"David V. Fansler" wrote:

> the user part of the program.  I have downloaded the info.  Unfortunately
> for me, he wrote the program using the Tech Tools/Parallax PIC mnemonics.  I
> am currently converting the code back to standard MicroChip mnemonics so I
> can better understand it.

You may be able to convert it quicker with this...

http://www.bubblesoftonline.com/parapic.zip

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
RemoveMEsalesTakeThisOuTspambubblesoftonline.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\24@203553 by Mike Hardwick

flavicon
face
>I understand that perhaps a VCR is not the highest
>speed, best device around - but the cost makes it attractive.  So here is my
>idea - given that one frame consists of 512 horizontal lines, repeated 30
>times per second (NTSC), then if you were to encode just 8 bits on say 400
>lines out of 512, there should be enough data - I imagine to do control and
>display.  I would not think this would be asking a lot from a VCR setup.

David,

For your purpose, it's probably better to think of video timing as 262.5
lines repeated 60 times per second. V sync is at 60Hz (give or take a
smidge). Of these 262.5 lines, about 240 are "live" video scan lines. If
you encode data reduntantly, possibly using several scan lines per bit, you
should be able to avoid media-related data integrity problems.

The scheme I suggested has considerable redundancy available though. Just
take multiple samples of each bit in the decoding process and discard
outliers (most UARTs do this). VCR dropouts tend to last for only small
fractions of a scan line unless you're pushing the tape past its wear
limit. Hint: Don't use cheap tape. I would also low-pass filter the video
upstream of the data recovery comparator, or perhaps deliberately choose a
comparator with slow response, in order to remove fast glitches. You can
add parity, checksums, etc. to enhance recovered data accuracy. Noisy
channels have been with us for a long time, and there are many techniques
available.

I think it was mainly the convenience factor that killed VCRs for hard disk
backup. It takes a HUGE amount of time to back up your data this way...

Mike Hardwick, for Decade Engineering -- <http://www.decadenet.com>
Manufacturer of the famous BOB-II Serial Video Text Display Module!

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2001\10\25@090916 by Olin Lathrop

face picon face
> I understand that perhaps a VCR is not the highest
> speed, best device around - but the cost makes it attractive.

Since you still need some hardware digitizing and interpreting the video
signal, how about using and IDE disk drive instead?  It can't be that hard
to make a little micro drive an IDE bus enough to grab streaming data from a
disk.  This has sufficient bandwidth to handle all the audio and control
information.

On the other hand, by the time you do all this, wouldn't it be a lot cheaper
to use a laptop with a sound card?  The audio is produced by the sound card
directly, and the control signals could be emitted via serial port to a PIC
that directly controls the hardware.

> So here is my
> idea - given that one frame consists of 512 horizontal lines,

Actually there are supposed to be 525 lines, of which about 486 (+-3 ?) are
displayable.  The remaining lines are during the vertical retrace interval
because the horizontal oscillator keeps running.  Remember, this was
designed to drive analog tank and deflection circuits directly.


********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, spamBeGoneolinspamBeGonespamembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...