Recording digital data to analog tape... revisited - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Recording digital data to analog tape... revisited
In newsgroup: comp.arch.embedded
Quoted text here. Click to load it

Looks indeed what you described.  There was a whole bunch of
discussion about Manchester coding in between, which is polarity
dependent and therefore not appropriate.  I went back in the thread
and what you describe is indeed exactly MFM.

Quoted text here. Click to load it

Sounds good.  If you want to use your bandwidth a little more
efficiently you can use RLL, but if your tape deck/camcorder is of
decent quality you shouldn't have to.

Another option is to issue a sync signal on one of the stereo
channels, and the data signal on the other.

    -hpa




Re: Recording digital data to analog tape... revisited
Quoted text here. Click to load it

Sounds like what is used on bank cards, we always referred to it as F-2F

Quoted text here. Click to load it

I never translated our rates into BPS, but the card speeds were pretty
highly variable.
I wouldn't be surprised if we went up around 2400BPS.
The limit, once we figured out that you can't treat the head as a voltage
source :) seemed to be the user's ability to keep the card in the track.


Quoted text here. Click to load it

Differing phase delay at different frequencies, will also give you some
pretty interesting grief.



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




Re: Recording digital data to analog tape... revisited
By author:     snipped-for-privacy@worldnet.att.net
In newsgroup: comp.arch.embedded
Quoted text here. Click to load it

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

    -hpa

Re: Recording digital data to analog tape... revisited
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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 ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Recording digital data to analog tape... revisited
Hi,

Quoted text here. Click to load it

This is an interesting approach, but it's not appropriate. The aim is to
treat the cassette recorder as a black box, exactly the same way I
treated the camcorder as a black box. If I wanted to use a recorder
specifically built for data recording, I would just use a Commodore C2N
datassette, of which I have dozens :)

If the right way to get this thing working reliably is to drop down to
lower frequencies, then I can do that. The reason I chose ~3kHz was from
studying personal computers from the early 1980s. I limited my studies
to computers that could or did use off-the-shelf audio cassette
recorders. Observably, they solved this problem. They didn't use the
full bandwidth by a long shot, but on the other hand they also had a
whole lot less data redundancy.


Re: Recording digital data to analog tape... revisited
Quoted text here. Click to load it

This is kind of like "The best way to ski, is to use skis, but I want to use
a bathtub"..

Quoted text here. Click to load it

FSK at a lower baud rate will probably work a lot better.
You might get away with bell 202  encoding reasonably well.

What I described, is how data is recorded and recovered for credit card, and
other sorts of magstripe data. Wildly varying and somewhat inconstant speed
during a read, though not as bad as you might think. You can't accelerate
your arm as much as you think.  I spent a couple years developing this sort
of thing for Verifone.

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






Re: Recording digital data to analog tape... revisited

Quoted text here. Click to load it

It's more like saying "the best way to race cars is to buy F1 racing
cars, but if you want to open the sport to the common man, you establish
a category for regular commuter cars". It is a design requirement to use
off-the-shelf equipment, just like it was a design requirement for those
80s computers.

I've since had a very stupid discovery ("breakthrough"), which I'm going
to post as soon as I can take a pic of the trace - my camera is charging
as we speak.


Re: Recording digital data to analog tape... revisited
to analog tape... revisited', on Sun, 3 Oct 2004:

Quoted text here. Click to load it

Selenium dioxide SeO2. Very effective against throat infections. It
really doesn't smell all that bad (but it is toxic, so to be taken only
in minimal doses). Try ethyl mercaptan if you really want to cause a
mass evacuation.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
We've slightly trimmed the long signature. Click to see the full one.
Re: Recording digital data to analog tape... revisited
data to analog tape... revisited', on Sun, 3 Oct 2004:
Quoted text here. Click to load it

OK, for me that is the perfect excuse. I often use it.
Quoted text here. Click to load it
[Rude noise.]

People, the more elevated the more likely, get caught out by relatively
naive observers because they 'see what they expect to see'. I recall
some senior people in the lab I'd just joined marvelling at the fact
that the fault in a piece of important test gear had been causally
diagnosed by a passing quality technician, (who also happened to be a
Pakistani, and this was in 1955). What did they expect? He was
accustomed to see fried resistors while they were accustomed to 'see'
excessive differential phase-shift, or something similar.

An improvement to the method of assembly of a module containing a
transformer was introduced at one of our factories by a 15 year old
trainee.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
We've slightly trimmed the long signature. Click to see the full one.
Re: Recording digital data to analog tape... revisited
Quoted text here. Click to load it

Well, maybe I should have said "more memorable".

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



Re: Recording digital data to analog tape... revisited
data to analog tape... revisited', on Sun, 3 Oct 2004:
Quoted text here. Click to load it
You're a man after my own heart (but you can't have it!). I put
outrageously colourful phrases in dry-as-dust texts on standards, so
that people remember what I wrote, while they forget the others.
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
We've slightly trimmed the long signature. Click to see the full one.
Re: Recording digital data to analog tape... revisited
I read in sci.electronics.design that Lewin A.R.W. Edwards
ink.net>) about 'Recording digital data to analog tape... revisited', on
Sun, 3 Oct 2004:

Quoted text here. Click to load it

Believe it or not, this has been seriously discussed at one of the IEC
EMC committees. I threw in a passing remark about it, as a caution
against inadvertently introducing requirements that would lead to
creating ludicrous situations.

Most people don't have ANY oscilloscopes. The fact that I have five (and
up to three might be in operation simultaneously) doesn't create a
situation that affects the harmonic levels on the UK supply system to a
detectable extent!
--
Regards, John Woodgate, OOO - Own Opinions Only.
The good news is that nothing is compulsory.
We've slightly trimmed the long signature. Click to see the full one.
Re: Recording digital data to analog tape... revisited
Hi Rich,

Quoted text here. Click to load it

I'd probably ditch the Tek 210 if I got the 54645D.

Observe the STK500 behind the keyboard. The computer in question is
actually just doing datalogging; I do the actual programming on my
laptop, not shown in this picture (I did say it was _part_ of my
workspace - the workspace covers three walls of my room. There are
shelves of components above what's shown in the picture, the wall
alongside that table has more components, and the wall opposite that
table has my main computer workstation, printer, scanner, stationery,
more shelves of parts (mostly computer parts), etc).

Re: Recording digital data to analog tape... revisited
In newsgroup: comp.arch.embedded
Quoted text here. Click to load it

Using a cassette tape in 2004 is already using a bathtub.

Think about it: a MultiMediaCard requires only a handful of wires and
resistors to interface with, and can store 128 MB on a tiny device
costing $17.97 retail.  A CompactFlash needs more wires, but 128 MB
costs $9.99 retail and the interface is a lot simpler.  (FWIW, both
are current prices from tigerdirect.com.)

At 3125 bits per second, 128 MB is 5461 minutes (91 hours) of storage
even using "disk drive maker's megabytes."  Given that, it seems
downright ridiculous to build a device using a cassette tape for data
storage except in downright bizarre circumstances.

    -hpa



Re: Recording digital data to analog tape... revisited

Quoted text here. Click to load it

Partial contents of a destroyed cassette tape can be recovered in
fragments using nothing more than a home workbench and patience. A
damaged flash chip is gone forever.

Cassettes and tape players are cheap, standardized and readily available
around the world. Flash media are not as readily available, are
balkanized, and it's at least 2x, more like 3x the cost to put in a
flash device as it would be to put in a cassette recorder mechanism
(~$7) and tape (~$0.50).

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.


Re: Recording digital data to analog tape... revisited
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.

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



Re: Recording digital data to analog tape... revisited
Quoted text here. Click to load it

This is why the subject line said "revisited". I asked some questions
about this project in its initial incarnation a while ago. At that time
it was purely for camcorder use.

The original project - and it's going up on my web site soon, I promise-
was either:

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

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.

The design restriction is: minimum possible reverse-engineering of the
cameras in use. It's acceptable to put a few patch wires into the
switches and buttons so they can be controlled remotely. It's NOT
acceptable to reverse-engineer any part of the analog or digital signal
paths inside the device and tap in anywhere, since there's no guarantee
that any particular tap-point will be available in a different model of
camera.

The circuit controls either a camcorder or a digital still camera (DSC)
over either async serial or SPI. For example, in powerdown mode it
disconnects the main power input to the camcorder. When the vehicle's
main controller requests it to start recording, it:

* applies power to the camcorder's battery terminals
* activates outputs that set the camera's mode switch to "record"
* "presses" the record button
* monitors the REC LED and signals back to the host if that LED goes out
(which signifies end-of-tape).

It can do similar tricks with a DSC. Someone pointed out to me that the
DSC control functions would be even more useful if there was a way of
recording the telemetry stream (since it's being sent out anyway, may as
well use it). Audio cassettes are by far the best and easiest way of
doing this. So that's why I'm looking at the problem. Seems like I have
it almost solved.


Re: Recording digital data to analog tape... revisited
On Sunday 03 October 2004 06:46 pm, Lewin A.R.W. Edwards did deign to grace
us with the following:
Quoted text here. Click to load it

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


Re: Recording digital data to analog tape... revisited
Quoted text here. Click to load it

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.

Re: Recording digital data to analog tape... revisited
On Monday 04 October 2004 08:04 am, Lewin A.R.W. Edwards did deign to grace
us with the following:

Quoted text here. Click to load it

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


Site Timeline