Recording digital data to analog tape... revisited

Followup to: By author: "Lewin A.R.W. Edwards" In newsgroup: comp.arch.embedded

If all you've got is a bathtub, sometimes using the bathtub will work just fine.

-hpa

Reply to
H. Peter Anvin
Loading thread data ...

On Sunday 03 October 2004 06:46 pm, Lewin A.R.W. Edwards did deign to grace us with the following:

Is there any possibility of injecting a video signal? Like a video out/ video in, where you could or-in some titles or VBI data or something? That'd be the obvious choice if there's a lot of digital data. I've seen pro-grade video decks, and they have a time track, that you could probably stuff some data on, but that all requires getting to the video stream before it hits the tape.

Good Luck! Rich

Reply to
Rich Grise

... snip ...

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.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

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.

Reply to
Lewin A.R.W. Edwards

On Monday 04 October 2004 08:04 am, Lewin A.R.W. Edwards did deign to grace us with the following:

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

Reply to
Rich Grise

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.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

One of the things that enabled the use of > 33kbit modems was the noise reduction offered by one end of the system being totally digital, so there's only a single DAC -> ADC stage.

--
Burn the land and boil the sea,
 You can't take the sky from me.
Reply to
Geoff McCaughan

On Monday 04 October 2004 11:59 am, Paul Carpenter did deign to grace us with the following:

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

Reply to
Rich Grise

Another factor is that the communication is actually synchronous, thus eliminating start and stop bits and giving a 20% speedup.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

[...]

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.

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.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

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:

formatting link

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

Reply to
H. Peter Anvin

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 =)

Reply to
pbdelete

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.

Reply to
Lewin A.R.W. Edwards

snipped-for-privacy@spamnuke.ludd.luthdelete.se.invalid

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

Reply to
JeffM

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

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

On Wednesday 13 October 2004 12:35 pm, Lewin A.R.W. Edwards did deign to grace us with the following:

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

Reply to
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.

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).

Reply to
Lewin A.R.W. Edwards

Followup to: By author: snipped-for-privacy@larwe.com (Lewin A.R.W. Edwards) In newsgroup: comp.arch.embedded

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

Reply to
H. Peter Anvin

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.

--
KC6ETE  Dave's Engineering Page, www.dvanhorn.org
Microcontroller Consultant, specializing in Atmel AVR
Reply to
Dave VanHorn

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).

Reply to
Lewin A.R.W. Edwards

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.