Connect with us

Recording digital data to analog tape... revisited

Discussion in 'Electronic Design' started by Lewin A.R.W. Edwards, Oct 2, 2004.

Scroll to continue with content
  1. Hi all,

    I'm trying to debug a problem - or even decide if I have a problem - in
    a system that records data to tape. (This is my camcorder-telemetry
    device, in a slightly different incarnation). This thing works very
    nicely on my digital camcorder. However I want to use the same circuit
    to lay down a data track on an audio cassette, and I'm encountering odd
    bit errors.

    To describe the format very briefly: The system has a 6.250kHz interrupt
    handler which toggles a digital output, resulting in a nominal 3.125kHz
    square wave going out to the recorder. Every odd interrupt, a bit is
    taken off the head of the Tx queue. If that bit is '0', the toggle
    operation is skipped for this interrupt. IOW, the bit cell is bracketed
    by edges, and if there's an edge in the middle it's a '1' and if there
    is no edge in the middle, it's a '0'.

    For those who want gory details, the actual format has another layer on
    top of this. The outbound data is divided into packets comprised of:

    48 bits '1' - timing header
    1 bit '0' - sync bit
    48 x - 9-bit bytes (data byte followed by a '0' spacer)
    2 x - 9-bit CRC bytes (data byte followed by '0' spacer)

    The decoder listens for a burst of at least 10 consecutive "1" bits
    (which can't occur in the middle of a data stream). While acquiring
    this, it measures the bit cell timing. Once it has acquired enough "1"s,
    it keeps sampling until either an excessively out-of-time edge occurs
    (>25% of nominal bit cell deviation), or the sync bit is found. In the
    latter case, it gathers the incoming data, checks the CRC, and decides
    whether to pass the data on to the host.

    Now the part where I'd like suggestions. When I record the above signal
    on my digital camcorder, the output waveform on playback looks almost
    exactly like the input waveform, except that it's understandably
    centered around the 0V line. When I record on a simple cheap cassette
    player, however, I get a very spiky waveform, which I guess (thinking
    about the physics of it) makes sense. Traces are at
    <http://www.larwe.com/camctrl.jpg>, sorry for the fuzzy photo.

    This spiky waveform actually works quite well with the decoder, because
    the decoder only looks for edges, and misses the trailing edge of each
    spike due to interrupt latency. The higher BER I'm finding *could* be
    attributable entirely to the much lower quality tape and transport in
    the cassette unit.

    But I am wondering what I can do to make the signal look more like what
    I expect. I'm wondering in particular if I should be doing something to
    the signal before sending it on to the recorder, or if the
    processing/interface circuit I need should be on the playback side. For
    instance, should I be trying to match the speaker impedance the recorder
    expects to see, probably 8 or 16 ohms? My input is very high-impedance.

    Any comments/suggestions?
     
  2. I read in sci.electronics.design that Lewin A.R.W. Edwards
    ink.net>) about 'Recording digital data to analog tape... revisited', on
    Sat, 2 Oct 2004:
    Does it make sense? It looks as if the cassette recorder can't even
    handle the fundamental and low-order harmonics in your 3.125 kHz square
    wave. Can you try recording a 3 kHz sine wave?

    You don't need to simulate the loudspeaker impedance at the output.
     
  3. Dave VanHorn

    Dave VanHorn Guest

    Use a current to voltage converter on the head to receive.
    You'll be surprised at the difference.
     
  4. CBFalconer

    CBFalconer Guest

    .... snip ...

    This is a purely off-the-cuff thought, and may be totally faulty.
    I suspect your problems may be based on the lack of DC operating
    position control, because your modulation automatically varies the
    DC content of the waveform. Something, somewhere, is
    automatically AC coupled in your system, which can lead to
    saturation, changes in trip points, etc.

    You might consider changing the 8 bits + 0 sync bit to an RLE
    encoding. That could simultaneously avoid any long streams of 1
    bits, and could be organized to maintain DC balance over any
    particular 8 bit equivalent. That might well require a 10 bit
    frame rather than 9, since it is fairly hard to guarantee constant
    DC content over an odd number of bits. I haven't checked it, but
    the code set consisting of 5 1-bits and 5 0-bits, in some
    sequence, needs to have at least 256 possibilities. If it has
    more you could even use 1111100000 as the initial sync sequence
    and preserve DC balance everywhere. The inverse could be used as
    an 'idling' character, relieving the time pressure to have data
    ready.

    The following shows the possibilities from a 6 bit stream, which
    gives 20 unique codes. Thus 12 bits have to be able to handle at
    least 400 codes. I can supply you the brute force jumble code if
    desired. Other combinations show a minimum of 900 codes.

    c:\>jumble 111000
    string="111000", max=720, len=6
    000111 001011 001101 001110 010011 010101 010110
    011001
    011010 011100 100011 100101 100110 101001 101010
    101100
    110001 110010 110100 111000

    Notice that the subset with less than three successive 1 bits is
    16 codes, which may be useful in supplying syncs. The 010101 or
    101010 group may also be useful for similar games.
     
  5. I suppose you're too young to remember the Kansas City Tape Interface. This
    worked quite well for storing computer programmes for the early PC's (pre
    IBM version machines like the AIM, BBC Micro, NASCOM-1 & 2, ZX81 and
    Sinclair Spectrum). It uses FSK to put the data down onto the audio track
    and gets through the DC blocking. You should be able to easily add
    Manchester Encoding or any other form of data error reduction scheme to
    this as well.

    http://www.evenson-consulting.com/flexusergroup/fug3.htm gives some
    indication of the historical context for this interface.

    http://www.ps8computing.co.uk/CPM/heathkit.htm has some descriptive text
    about the interface and may form some sort of a specification for you. The
    schematic at http://www.swtpc.com/mholley/AC30/AC30_SchematicA.jpg seems to
    be close to the interface circuitry that you will need. Maybe, from the
    specification and the circuit, you may find yourself able to make an
    improvement.

    --
    ********************************************************************
    Paul E. Bennett ....................<email://[email protected]>
    Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
    Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
    Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
    Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
    ********************************************************************
     
  6. I think you may be saturating the input channel. Do you have a level
    adjust pot? The cassette recorder probably expects a signal in the
    0.5V range for a line input and a few dozen millivolts for a microphone
    input.

    I would add a level control pot and some RC filtering at perhaps twice
    your square wave frequency. The high frequency content on your signal,
    if the recorder can handle it at all, may be interacting poorly with
    the AC erase frequency or AC bias on the tape.
    Mark Borgerson
     
  7. I read in sci.electronics.design that Mark Borgerson <>
    wrote (in <>) about
    'Recording digital data to analog tape... revisited', on Sat, 2 Oct
    2004:
    The output signal is strongly differentiated. While this might be due to
    severe overload of the recording amplifier, I would expect the output to
    be unsymmetrical in that case. I think something else is wrong, like
    (crazy suggestion) the signal is applied to the mic input (giving a lot
    of gain), but there is an open circuit connection, so only the high
    harmonics get through the stray capacitance.

    Filtering at twice the fundamental of a square wave leaves you with a
    somewhat bent sine wave, since the first non-zero harmonic is the third
    at an amplitude of 0.33 times the fundamental.
     
  8. Mr Rogers

    Mr Rogers Guest

    Lewin,

    What you are seeing is to be expected on an analog (magnetic tape) recorder,
    your spikes are the sudden flux change on the tape which is the result of
    your input waveform. Mag tape only records delta information (i.e. Flux
    change), not a known state. It works for audio as its essentially an AC
    signal (from the mag heads perspective), but when you attempt to use a DC
    signal (such as your waveform) all you will see is the sudden flux change
    from 0~1. If you want get hold of some mag tape developer (iron filings
    suspended in alcohol) and spray it onto the tape and you will be able to see
    what's happening.

    Hope it helps.

    Heath


    PS. Your encoding method is commonly known as F2F (as used on CR80 cards -
    aka Credit Cards). This is an extremely reliable method of encoding your
    data as its self clocking, and you always sample at the 2/3 mark to
    determine the bit value (in practice the 3/4 mark actually works better).
     
  9. Rich Grise

    Rich Grise Guest

    The waveforms look to me like his recorder has no bias. It looks exactly
    like what I'd expect if I were recording a 3 KHz rectangular wave. The
    DC during the highs and lows puts a constant, same-direction magnet bias
    on the tape, like scraping a magnet along a screwdriver. The current
    reverses, the magnetic stuff on the tape lines up the other way for
    a while.

    Now, when you play it back, the "DC" magnetization doesn't induce any
    current in the head - only the flux changes.

    So it's doing exactly what it's supposed to do. I'd either look into
    a 25-40 KHz bias oscillator, or find a scheme that exploits this "feature."
    ;-)

    Cheers!
    Rich
     
  10. Dave VanHorn

    Dave VanHorn Guest

    An I-V amplifier for the read side will work wonders.
     
  11. Fred Bloggs

    Fred Bloggs Guest

    Lewin A.R.W. Edwards wrote:

    You should attenuate the digital signal into the cassette- you want
    5Vpp->1Vpp or 1/5- so something like a 10k->2.2k ohms divider and the
    input should already have a DC block. Your waveform looks like what you
    see when you overdrive the cassette input amplifier through a capacitor-
    which then clamps to the rails, lowers the input impedance, and causes
    the input capacitor to charge especially fast. The preamp signal drops
    to zero when the capacitor is peak charge and this causes the spike in
    the opposite direction immediately after the leading edge spike. Your
    main problem is too much amplitude, attenuate it.
     
  12. Dave VanHorn

    Dave VanHorn Guest

    Trying to do digital data on magtape, using an audio path, is fighting a
    loosing battle.
    Yes, it can be done, but at the expense of complexity and bandwidth.

    You'll have a much easier time recording the data directly as manchester
    encoded (F/2F) flux reversals, and recovering them with an I-V amplifier
    directly from the head. The I-V amp pretty much squashes the head's
    self-resonances, and it's actually the right way to treat the transducer.
    The head's output current is proportional to the rate of change of the flux
    on the tape.

    For recording, a V-I converter is best, but you can just feed the voltage to
    the head, and let the resistance do the rest.. You DO need a bipolar supply
    though. You'll have to experiment for how much current to use, it won't be
    much. Think uA rather than mA. When you have the receive circuit working,
    adjust the send current so that the amplitude of the recovered data begins
    to drop off (tape < saturation), then take it back just into saturation.

    The great news is, you don't have to hack up the recorder much to do this,
    leave everything else alone, and just wire directly to the head.

    You'll have to experiment to see what your best data rate works out to be,
    due to gap length, tape speed, and head inductance.

    Although it's tough to get ahold of, Finn Jorgensen's "Handbook of Magnetic
    Recording" is a good reference.
     
  13. Fred Bloggs

    Fred Bloggs Guest

    Do you think this is necessary for a kHz data stream? It's analog right-
    so a simple lowpass schmitt should recover it nicely.
     
  14. Fred Bloggs

    Fred Bloggs Guest

     
  15. Dave VanHorn

    Dave VanHorn Guest

    Depends greatly on the tape recorder.
    Try recording white noise, then on playback, see what the response curve
    looks like.
    In order to get clean edges at 3kHz, you'll need at least 6kHz bandwidth.
    Otherwise, the output will be a triangle wave, at best.

    What I'm proposing is really pretty simple, other than the manchester
    encode/decode.
     
  16. Hi,
    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.
     
  17. Followup to: <>
    Well, it's sort of.

    A very good format for recording to magnetic tape in the low kbps
    range is MFM; it's simple, quite robust w.r.t. speed differentials,
    and polarity-independent (unlike Manchester coding.)

    MFM works like this:

    For each bit time, at t = 0 there is an edge (toggle whatever level
    the output is at the time.) If the bit value at 1, at t = 0.5 there
    is another edge; otherwise the level stays the same.

    During decode, use the first edge for synchronization; if there is
    another edge between t = 0.25 and t = 0.75 or so per your own clock,
    then record a 1 otherwise a 0. For higher bit rates you may want to
    try to produce a clock from the synchronization pulses instead of
    using your own "nominal" clock, but the error window is huge so it
    works well.

    This was used by the ABC series computers used in Sweden 1978-1986; a
    full schematic of the ABC80 machine is at:

    http://www.abc80.net/Datorerna/Luxor/Luxor_HW_Info/abc80schema.zip

    The ABC80 used 700 bps; the later 800 machine used 2400 bps but the
    same modulation technique.

    If you want higher bit rates you should start to consider some of the
    techniques used by modems, like quadrature decode and multilevel. The
    biggest issue about using those on a cassette tape is that you have
    nonlinear distortion due to speed differences; those are hard to
    analyze in the context of especially quadrature decode. An
    alternative is to use digital techniques which put in synchronization
    pulses in fewer places (if you remember RLL hard drives, that was one
    such technique.)

    -hpa
     
  18. MFM works like this:
    Is this not _exactly_ what I described? :) (Serious question. I can't
    see the difference between what you just wrote and what I described as
    being the actual encoding system in use).
    That's exactly what I do. I calculate the average bit cell during the
    sync acquisition phase. There are several sources of clock instability -
    tape fluctuation is one, but also both the encoder and decoder are
    implemented on AVR micros using the internal RC oscillator, and the
    encoder at least can be subjected to temperature extremes. So I thought
    it best to adapt the decoder dynamically, since the signal clock rate
    will be drifting around more or less constantly.
     
  19. nospam

    nospam Guest

    It doesn't make sense it looks bloody awful.

    The recorder is broken or you have some gross (ac and/or dc) overload of
    the front end or something strange with the way you have connected the
    output.

    Is the trace you referenced even showing playback? Unless one of them is
    stored how can you show the recorded input and played back output on the
    same screen?

    If the trace is monitoring the recorder output while recording then the
    spikes might be capacitive coupling from the fast edges on the input.

    Are you just stuffing 5v TTL square waves into the recorder mic (or even
    line) input? that isn't gong to work.
     
  20. Dave VanHorn

    Dave VanHorn Guest

    This is an interesting approach, but it's not appropriate. The aim is to
    This is kind of like "The best way to ski, is to use skis, but I want to use
    a bathtub"..
    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.
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-