Recording digital data to analog tape... revisited

[Lewin A.R.W. Edwards]

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?

 

[John Woodgate]

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:

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.co
m/camctrl.jpg>, sorry for the fuzzy photo.

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.

 

[Dave VanHorn]

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

 

[CBFalconer]

.... snip ...

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.

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

 

[Paul E. Bennett]

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

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://peb@a...>
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..
********************************************************************

 

[Mark Borgerson]

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.

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.

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?

Mark Borgerson

 

[John Woodgate]

I read in sci.electronics.design that Mark Borgerson <[email protected]>
wrote (in <[email protected]>) about
'Recording digital data to analog tape... revisited', on Sat, 2 Oct
2004:

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.

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.

 

[Mr Rogers]

Hi all,

I'm trying to debug a problem - or even decide if I have a problem - in

Any comments/suggestions?

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
[email protected]

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

 

[Rich Grise]

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

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

 

[Dave VanHorn]

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

 

[Fred Bloggs]

Lewin A.R.W. Edwards wrote:

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?

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.

 

[Dave VanHorn]

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.

 

[Fred Bloggs]

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.

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

 

[Fred Bloggs]

Do you think this is necessary for a kHz data stream? It's analog right- ^^^^
3kHz


so a simple lowpass schmitt should recover it nicely.

 

[Dave VanHorn]

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.

 

[Lewin A.R.W. Edwards]

Hi,

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

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.

 

[H. Peter Anvin]

Followup to: <[email protected]>

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

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

 

[Lewin A.R.W. Edwards]

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.

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

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

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.

 

[nospam]

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.

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.

 

[Dave VanHorn]

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

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

If the right way to get this thing working reliably is to drop down to
lower frequencies, then I can do that.

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.