Date   : Sun, 18 Feb 1996 00:51:07 +0100
From   : Robert Schmidt <robert@...>
Subject: Re: Tape decoding status

>Is this that big a problem? Is seems easiest to me to do what the UART
>does and wait for the zero bit to signal that start of a byte
>frame. You might like to make sure you get at least one correct (1)
>stop bit, however 2 stop bits shouldn't stop you from decoding
>correctly.

No, it wasn't a big problem.  At first I just assumed that all bytes had one
stop bit, because the first few files I decoded only had one.  Then I came
across a file with two, and at first I thought the decoder had gotten
desynched by a bit or two, and spent hours on this idea until I realised
that it might happen that a second stop bit slipped in.  Then it was a piece
of cake, of course.  I now allow for one or two stop bits, but complain if
there are none or more than 2.

>(as an afterthought, some sort of PLL arrangement to compensate for
>dodgy speed regulation on the tape may be nice also. I'd really like
>to do some hacking on this (which needs some tape samples), even if it
>is reinventing the wheel by now)

My bit scanning works by tracing the curves and flanks of the waves,
counting the number of samples spent in one wave length.  It calls a flank a
flank whenever the signal has departed from the last extrema by more than
1/3 (A) of the height (B) between the two last extremas (peaks).  

---
   \          /-\     | A   | B
    \        /   \    |     |
     \      /               |
      \----/                |

Did that make sense?  The height B varies a lot during a block.  The 1200 Hz
peaks tend to be much taller than the 2400 Hz ones, and after a 0 bit (1200
Hz), the next 1's tend to drift upwards (or downwards) instead of remaining
centered on the zero-line - so zero-crossings are essentially useless.  I've
even seen small parts of a block where 2 or three wave lengths of 2400 Hz
have been completely above the zero line.  

I compare the detected wave length to the average length acquired during the
initial synch with the 2400 Hz tone, and allow for some slack (10-50%).  I
also declare the signal as too weak (or "noise") when the height between the
last two peaks is smaller then 10 (assuming 8-bit samples), and then I start
waiting for the initial synch tone again.  This seems to work very good.  I
occasionally have to adjust the slack parameters to compensate for shitty
signals.

regards,
robert