Recording digital data to analog tape... revisited

[CBFalconer]

By author: [email protected]
.... snip ...

There was a preamble and a postamble; the data was also subdivided
into blocks. The preamble was, among other things, used to
establish the proper position of the byte boundaries.

However, it's not really necessary, at least in theory; for a
terminal zero bit it would look like:

| | | | <- bit times

+------------------------------------------ etc
|
------+

(no transition in the detection window, followed by nothing.)

... for a terminal one bit it looks like:

| | | | <- bit times

+-----+
| |
------+ +------------------------------------- etc

(transition in detection window, followed by nothing.)

Typically, though, you'd finish with a CRC or checksum and then
have a postable (usually of some number of zero bits.)

Without the postamble, I was thinking of implementation. There are
three times of interest during that final bit, the initial clock
transition, the sampling point, and the next clock transition.
Practically the initial will reset a data flop, the sample will
conditionally set it, and the next will shift that bit out while
reseting the data flop. The last transition is missing, which
brings up complications like missing clock detectors etc.

What you actually have to work with is the derivative of those
waveforms, possibly converted to unipolar pulses.

 

[Lewin A.R.W. Edwards]

Is there any possibility of injecting a video signal? Like a video out/

I abandoned this idea without even attempting it, because it is much
too invasive. It might be possible to achieve it on some particular
camcorders, but in other devices likely the signals you'd need to tap
are buried inside ASICs. Either way a lot of reverse-engineering is
required. Plus if you do it as a kind of OSD thing, you're obscuring
actual picture data.

To reiterate: The circuit already works well on camcorders The
audio cassette thing is an enhancement.

 

[Rich Grise]

I abandoned this idea without even attempting it, because it is much
too invasive. It might be possible to achieve it on some particular
camcorders, but in other devices likely the signals you'd need to tap
are buried inside ASICs. Either way a lot of reverse-engineering is
required. Plus if you do it as a kind of OSD thing, you're obscuring
actual picture data.

To reiterate: The circuit already works well on camcorders The
audio cassette thing is an enhancement.

Well, thanks for clearing that up for me. I was thinking of the old
days, with reel-to-reel recorders, where you could record and play
simultaneously, and had plugs & jacks & patch cords everywhere in
the signal path so you could mix stuff willy-nilly.

So, if you're stuck on audio cassette, I'd look at that Manchester
or Kansas City stuff, from the days of the Commodore and Sinclair
and like that, as has been mentioned.

How about just an ordinary acoustical modem?

Thanks!
Rich

 

[Paul Carpenter]

On 4 Oct, in article
<[email protected]>

I abandoned this idea without even attempting it, because it is much
too invasive. It might be possible to achieve it on some particular
camcorders, but in other devices likely the signals you'd need to tap
are buried inside ASICs. Either way a lot of reverse-engineering is
required. Plus if you do it as a kind of OSD thing, you're obscuring
actual picture data.

Even to do it as an OSD thingy on a camcorder (integral unit) is not
guaranteed from unit to unit. To do either method of VBI data (SMPTE timecoe
or similar) or OSD type, requires disrupting the signal between the
camera and the recorder part. So I say wise choice, laying down on sound
track is a good choice.

To reiterate: The circuit already works well on camcorders The
audio cassette thing is an enhancement.

Despite its startup glitches seems a sensible solution.

 

[Rich Grise]

On 4 Oct, in article
<[email protected]>


Even to do it as an OSD thingy on a camcorder (integral unit) is not
guaranteed from unit to unit. To do either method of VBI data (SMPTE
timecoe or similar) or OSD type, requires disrupting the signal between
the camera and the recorder part. So I say wise choice, laying down on
sound track is a good choice.


Despite its startup glitches seems a sensible solution.

And, of course, having seen the light, I have to mention that all in the
days of seeing data put on cassette, I've never seen one that used side A
for clock and side B for data, which I'm guessing is because they wanted
as much density as they could get.

But given that, I think that the technology for getting data onto a
cassette reliably is fairly mature, like 8" floppy disks, ;-p

Cheers!
Rich

 

[Hans-Bernhard Broeker]

Ah CAMCORDER! Now I understand the reluctance to modify.
You may have said that before, I've been rather under the weather this
weekend, I may have missed it.

[...]
a) to store telemetry data on the audio track of a camcorder,
synchronized with the image, or

In case you haven't done so yet, you may want to investigate the way
long-term (24h) electrocardiograms are recorded. My dad had to have
one a while ago. It was a device that he had to carry around with him
during an entire 24-hour day at home, and it did put the data on a
single audio cassette. It actually looked a bit like a converted
walkman.

b) to devise some reasonably solid method for putting sync marks onto
the videotape, so that a (flash or HDD-based) log could be
cross-referenced to the video stream.

What kind of tape? One serious design flaw of VHS, IIRC, is that it
lacks any standardized mechanism for in-band time-synching. Most VCRs
have invented their own system, and so did camcorders, I suspect, but
they are independent and incompatible with each other.

 

[H. Peter Anvin]

Sorry to post a late addition to this thread, but I did run into a
1995 paper with some interesting results on using more complex
encoding techniques on conventional audio cassette tape. If you're
willing to do some DSP on the receiving end (the transmitting side is
still quite simple) then it might be interesting:

http://kabuki.eecs.berkeley.edu/~abo/papers/224/224_report.pdf

This is one of the few places where I've seen discussed dealing with
the time jitter problem that's inherent in the use of tape for the
more advanced modulation techniques.

Note, though, that the best results for magnetic media are achieved
when the media is always magnetized to saturation, and the data is
encoded in binary flux transitions. Time-modulation techniques like
RLL can be used to increase the amount of data encoded per flux
transition. This is of course hard to achieve with analog recording
devices, of course, since they are designed exactly to avoid
saturation with the resulting distortion.

-hpa

 

[[email protected]]

Note also that this project is an _extension_ of an existing project.

I'm simply making it more general-purpose. The original project was to
record a running telemetry stream on the audio track of a camcorder, so
that an external box next to the TV set could decode the telemetry and
display it while the video was being played back. The requirement was
not to modify the camcorder at all.

How about a onboard pc or dsp that compress any arbitrary numbers of video and
audio streams + telemetry data ?

It all depends on the amount of telemetry data and budget I guess =)

 

[Lewin A.R.W. Edwards]

How about a onboard pc or dsp that compress any arbitrary numbers of video and

audio streams + telemetry data ?

A PC is out. I just removed an x86 SBC from the design; I am moving
the functionality into small micros. There is a power budget issue
here. Also, hard disks are not robust enough for this environment
(underwater vehicle). Flash media are not good value, comparatively
speaking.

Trust me, I want to do this on magnetic tape. The camcorder is in many
ways ideal.

 

[JeffM]

[email protected]

A 44-character screen name with no spaces.
Congratulations. You get the booby prize.
Ever thought about just using "pb"?

 

[CBFalconer]

[email protected]

A 44-character screen name with no spaces.
Congratulations. You get the booby prize.
Ever thought about just using "pb"?

Was your wife mean to you this morning? The dog? Kids fail to
show the proper respect?

 

[Rich Grise]

A PC is out. I just removed an x86 SBC from the design; I am moving
the functionality into small micros. There is a power budget issue
here. Also, hard disks are not robust enough for this environment
(underwater vehicle). Flash media are not good value, comparatively
speaking.

Trust me, I want to do this on magnetic tape. The camcorder is in many
ways ideal.

It seems whenever there's a home video on TV they've got the date and
time. But you want other stuff. So, what if you took, say, a 40-char
alpha display, and put it in the field of view of the camera? Take a
picture of your telemetry! Scroll it across like a little marquee.

Cheers!
Rich

 

[Lewin A.R.W. Edwards]

A 44-character screen name with no spaces.

Congratulations. You get the booby prize.

Can I get some boobies too if I change my return email address to
something really long? You can use
give.me.the.boobies...are.you.threatening.me...i.am.a.gringo...i.have.no.bunghole@larwe.com
if you want, it should work.

 

[Lewin A.R.W. Edwards]

time. But you want other stuff. So, what if you took, say, a 40-char

alpha display, and put it in the field of view of the camera? Take a
picture of your telemetry! Scroll it across like a little marquee.

Depth of field problems. My camera is inside a submarine and the
display must be within an inch or so of the lens. The objects I'm
interested in seeing are at infinity.

This was discussed way back in my earlier thread. I asked for ideas on
either putting a sync mark in the video stream (an LED was considered)
so that I could establish correspondence points between separate
telemetry and video streams, or ideas for putting my data directly
onto the camcorder without modifying it at all (if possible).

 

[H. Peter Anvin]

Followup to: <[email protected]>
By author: [email protected] (Lewin A.R.W. Edwards)
In newsgroup: comp.arch.embedded

Depth of field problems. My camera is inside a submarine and the
display must be within an inch or so of the lens. The objects I'm
interested in seeing are at infinity.

This was discussed way back in my earlier thread. I asked for ideas on
either putting a sync mark in the video stream (an LED was considered)
so that I could establish correspondence points between separate
telemetry and video streams, or ideas for putting my data directly
onto the camcorder without modifying it at all (if possible).

Not to mention that the bandwidth of scrolling text across the screen
wouldn't be anywhere close to what you can extract from the audio
tracks (and it wouldn't easily be machine readable.)

-hpa

 

[Dave VanHorn]

IIRC nasa does something like this, with a data stream on a couple of lines
of the video. They float it across the screen, so that it never consistently
obscures any part of the screen. Looks reasonable to encode, but decoding
could be a bear.

 

[Rich Grise]

Depth of field problems. My camera is inside a submarine and the
display must be within an inch or so of the lens. The objects I'm
interested in seeing are at infinity.

So give your camera a bifocal. °-)

Cheers!
Rich

 

[Rich Grise]

IIRC nasa does something like this, with a data stream on a couple of lines
of the video. They float it across the screen, so that it never consistently
obscures any part of the screen. Looks reasonable to encode, but decoding
could be a bear.

Problem is, he doesn't have access to the raw video.

But I been thinkin' - a freaking submarine has got to be a pretty
high-budget project, wouldn't you think? I think it'd be worth it to hack
into the stupid camera, and probe it, and figure out where to inject the
danged telemetry signal on top of the video. It will be only one point,
after all. You might want to pick up sync, so two. Not counting ground.
Well, you get the idea.

Good Luck!
Rich

 

[Lewin A.R.W. Edwards]

IIRC nasa does something like this, with a data stream on a couple of lines

of the video. They float it across the screen, so that it never consistently

It's not really related at all - the OP was talking about putting an
LCD in the field of view, which is very different from replacing video
lines with data lines. The latter method is impossible given my design
constraint - don't modify the camera. It would be impossible to
document a generic solution to do anything involving insertion of data
into the video stream, because the video path inside camcorders isn't
standardized (esp. not with respect to what parts of it are accessible
and what parts are buried in an ASIC).

 

[Mark Borgerson]

It's not really related at all - the OP was talking about putting an
LCD in the field of view, which is very different from replacing video
lines with data lines. The latter method is impossible given my design
constraint - don't modify the camera. It would be impossible to
document a generic solution to do anything involving insertion of data
into the video stream, because the video path inside camcorders isn't
standardized (esp. not with respect to what parts of it are accessible
and what parts are buried in an ASIC).

I agree wholeheartedly with your desire to keep the camcorder intact.
This is as a result of a few attempts to repair VCRs----which are
mechanically much larger. The idea of loosening a screw on the
camcorder and hearing "click, click, sproing!" gives me the
shivers! Replacing the whirring noise of the motors in the
submarine with a telemtry stream seems very sensible.

I've managed to get 230KB async from a UART through a kilometer of
intercom wire (simulating an oceanographic cable) by putting out
full cycles of pseudo sine waves for 1 bits and nothing at all for
zero bits. The signals were transformer coupled for impedance
matching and DC isolated so the cable could be used for HV power.

I think a similar approach would work on an audio recorder---but
probably at a lower baud rate. I used an SX chip from UBICOM as a
modulator/demodulator. For lower baud rates, a PIC would probably
do the job with less power dissipation.

Mark Borgerson