Recording digital data to analog tape... revisited

[Dave VanHorn]

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.

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

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

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.

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

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

 

[Dave VanHorn]

When I record on a simple cheap cassette

It doesn't make sense it looks bloody awful.

It does look like you need WAY less signal to the mic input.
I'd expect a distorted square wave, but not the pulse per edge.

Mic level is something like 20mV IIRC.

 

[Lewin A.R.W. Edwards]

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

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.

 

[Dave VanHorn]

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.

Well, then you'll have to encode the data into a signal that the audio
recorder is meant to handle.
FSK is probably your best bet.

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.

I'll be around for a while, I'm debugging a VB front end for a battery
charging system.
Each test cycle takes roughly an hour to complete.

 

[Lewin A.R.W. Edwards]

Okay... followup. I got lots of interesting comments and suggestions
here, thanks.

This problem turns out to be one of those utterly "DUH!" sorts of
things. I started by connecting the tape recorder in question up to a
ZX81. I saved a program and attempted to load it. No dice. The on-screen
datablocks didn't look right either (if you've used a ZX81, you'll know
what I mean - but in brief, the ZX81 outputs the audio data to the
raster while loading/saving).

Tried it with another tape recorder. No problems there. WTF?

To cut a long story short, this particular recorder I'm using, although
it is mono, uses stereo connectors for both mic and ear. Somehow (and
I'm not clear on why this is happening) when I insert my mono plug, it
doesn't get a reliable ground connection. If I use clipleads to connect
to the appropriate points directly on the recorder's PCB, the problem
goes away.

So, my workaround is to use the tip and barrel lines on a stereo plug
for both ear and mic, and with this arrangement I get the following:
<http://www.larwe.com/camctrl2.jpg> (lower trace). Observe that it is
pretty darn clean, 1V p-p centered around 0V, and somewhere between a
sine and a triangle. The decoder can read this signal happily with a
much lower BER than the spiky signal. No other changes were made in the
circuit.

By the way, the top trace in these pictures I've linked is 3kHz digital
out directly out of the micro's pin. I showed it mainly (a) because ch1
happens to be connected to that line, and the STK500 board can't be
switched off while connected to a PC, but also (b) to indicate what sort
of signal I was trying to lay down. It just so happened in the first
picture that the edges lined up very closely. There's a small phase
difference in the picture linked above. This doesn't mean anything at
all, since the signals are not directly related.

 

[Lewin A.R.W. Edwards]

I'll be around for a while, I'm debugging a VB front end for a battery

charging system.
Each test cycle takes roughly an hour to complete.

I know the feeling. I've just acquired this old (22yo) Nicolet DSO which
happens to make analyzing my battery charger circuits much easier. It's
got a 4096-sample memory, which is nothing to write home about, but the
interesting thing is that you can set it down as slow as 1 sample per
200 seconds. So you can start up a test operation, walk away for ten
days, and come back, hit the RS232 button and get a complete dump of
discharge or charge curve

 

[Dave VanHorn]

This problem turns out to be one of those utterly "DUH!" sorts of
things. I started by connecting the tape recorder in question up to a
ZX81. I saved a program and attempted to load it. No dice. The on-screen
datablocks didn't look right either (if you've used a ZX81, you'll know
what I mean - but in brief, the ZX81 outputs the audio data to the
raster while loading/saving).

I remember that little thing! A real one-chip wonder.
I had one for a while, but left it for a Vic-20, then an Ampro Little board.

Tried it with another tape recorder. No problems there. WTF?

To cut a long story short, this particular recorder I'm using, although
it is mono, uses stereo connectors for both mic and ear. Somehow (and
I'm not clear on why this is happening) when I insert my mono plug, it
doesn't get a reliable ground connection. If I use clipleads to connect
to the appropriate points directly on the recorder's PCB, the problem
goes away.

That's kinda odd..

So, my workaround is to use the tip and barrel lines on a stereo plug
for both ear and mic, and with this arrangement I get the following:
<http://www.larwe.com/camctrl2.jpg> (lower trace). Observe that it is
pretty darn clean, 1V p-p centered around 0V, and somewhere between a
sine and a triangle.

You're seeing bandwidth limits.
Try encoding that, and half that frequency, so that the waveform looks like:
HHHHLLLLHHLLHHHHLLLLHHLL and see what sort of distortion you get in the
timings.

The decoder can read this signal happily with a much lower BER than the
spiky signal. No other > changes were made in the circuit.

I'm surprised it could read the spiky stuff at all.
But you shouldn't have a BER to speak of, if the system's working right.

 

[Dave VanHorn]

I know the feeling. I've just acquired this old (22yo) Nicolet DSO which

happens to make analyzing my battery charger circuits much easier. It's
got a 4096-sample memory, which is nothing to write home about, but the
interesting thing is that you can set it down as slow as 1 sample per
200 seconds. So you can start up a test operation, walk away for ten
days, and come back, hit the RS232 button and get a complete dump of
discharge or charge curve

IF the power dosen't glitch on day nine!

We seem to fly in similar circles
I started with a TDS-420A because I already had one, then went to a radio
shack DVM with PC interface (ok, but only one channel) Now I'm using this
VB front end and a PMD-1208LS USB data aquisition pod which gives me four
differential inputs, as well as control outputs, and analog output, which I
haven't used yet.

Have you been to my web page? I have some output from my program on there.
It does a four trace scope at 4s/S but I only use three analog channels.
I plot volts, current, and temperature, plus delta volts, and delta temp.
I track min and max on temp and voltage, and accumulate Joules in charge and
discharge.

Today's experiment is to get my thermal pause working (wait for cool and
stable temp between charge and discharge cycles) and to get "discharge to X
joules" working. I already have "discharge to X volts" which is what I used
to get the NIMH memory effect plots that are on my web page.

 

[Jim Granville]

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.

The waveforms just don't 'make sense' : you have spikes that suggest
a >30KHz high pass filter, but an audio cassette should not do that.
It should have mediocre bandwidth, and phase wobble.
Try recording a range of levels, at 3KHz and 1KHz, and play
those back & try another unit.
-jg

 

[Lewin A.R.W. Edwards]

Hi Dave,

We seem to fly in similar circles

Hmm. Coincidences:

* I use AVRs a lot.

* I built a theremin while briefly working for [big toy company]. It was
a kind of hybrid digital-analog theremin; it used an external analog
circuit to get the difference between the reference frequency and the
operator-modified frequency, and fed that signal into a
frequency-to-voltage converter, thence to an ADC channel on a toy DSP
chip (yes, there is such a thing). The DSP applied the control signal to
set the frequency of a child-selected instrument. They put the prototype
in a case that looked rather like a set of bagpipes. It had two
channels, each of which could play a single note of two different
instruments (total library of 16 instruments). I always meant to feed
the raw "operator oscillator" into the DSP direct and do the
differencing in software, but didn't get around to it. The theremin idea
was abandoned in favor of an LDR fed to the same ADC.

* I had a Libretto 110 and a Libretto 70. Sold both not so long ago. Up
until just a month ago, I was using the 70 to do text-processing and to
flash micros on the road.

* My first computer was a VIC-20 (I have dozens in my collection now).
The first computer that was unconditionally mine, though (as opposed to
being a family computer) was a ZX81.

I started with a TDS-420A because I already had one, then went to a radio
shack DVM with PC interface (ok, but only one channel) Now I'm using this

My wife (not an electronics person) rolls her eyes when she sees the
stacks of equipment I need. She said "Don't most people have just one
oscilloscope?" (See part of my "electronics workspace" at home
<http://www.larwe.com/workspace.jpg>). The problem is, I actually need
at least one more scope - I'd like a HP 54645D like I use at work -
because I need something with deep memory. The 16-channel
mini-logic-analyzer is very useful too.

I'd like a spectrum analyzer, too. Oh well. Gotta pick up some more
contract work before I can buy those toys

For this particular battery experiment I was going to use the
DVM-with-serial method too, except that the vendors wouldn't give me a
straight answer about whether it was possible to capture simple data in
a terminal program without using their proprietary software. So this
Nicolet gift came along at just the right time. Saved me the $80 for a
serial DVM too

VB front end and a PMD-1208LS USB data aquisition pod which gives me four
differential inputs, as well as control outputs, and analog output, which I

I need to get into PC data acquisition at work. I have a "back burner"
project simmering on my to-do list which involves collecting long radio
transmissions (several days at least). The signal of interest consists
of a 4kHz or 10kHz baseband signal recovered from a test point on
devices we're trying to debug. Oftentimes problems with these designs
only appear after days or weeks of continuous uptime. We have various
tools for analyzing the behavior of systems under test, but none of them
are fully satisfactory. There's a lot of guesswork, followed by minor
tweaks then push the whole thing back into the test queue for another
week. It would be great to capture EVERYTHING that was said by all
stations over the week, synchronized with a couple of other signals that
would indicate specific states being reached by the device.

 

[Dave VanHorn]

Differences:

* pancreatitis.. Trust me, you'd rather not go there.

This is almost at toy prices, IIRC I paid something like $79.

I need to get into PC data acquisition at work. I have a "back burner"
project simmering on my to-do list which involves collecting long radio
transmissions (several days at least). The signal of interest consists
of a 4kHz or 10kHz baseband signal recovered from a test point on
devices we're trying to debug. Oftentimes problems with these designs
only appear after days or weeks of continuous uptime.

I know that feeling. I took on one bug that had been defying analysis by
some rather clever folks, for a couple of years. I had to examine the
assembler code for vulnerabilities, write some specialized software, then
make 7000 transactions (individual long-distance phone calls) to isolate the
problem. In the end, the problem was a vulnerability in our code, to a bug
that only existed in one of five computers on the host end. In our case,
the bug would just occasionally blow away a merchant's sales for the day..
People get so upset when you loose their money!

We have various
tools for analyzing the behavior of systems under test, but none of them
are fully satisfactory. There's a lot of guesswork, followed by minor
tweaks then push the whole thing back into the test queue for another
week. It would be great to capture EVERYTHING that was said by all
stations over the week, synchronized with a couple of other signals that
would indicate specific states being reached by the device.

Sounds like it is something very subtle, or you're looking in the wrong
place.

I saw one like this, an SMPS that would occasionally catch fire.
Many wrong guesses, by some pretty high $$$ people.
In the end, it was a reverse-polarized screw that everyone noticed, and
everyone discarded as a problem source.

 

[Lewin A.R.W. Edwards]

* pancreatitis.. Trust me, you'd rather not go there.

:/

People get so upset when you loose their money!

In this case, it's potentially even worse than that, since (in
principle) lives could be lost if these products fail. However the
structure of the systems into which they are installed is such that
failures are just annoyance and wasted money. The product still needs to
be tested and guaranteed as if lives depend on it, though.

Sounds like it is something very subtle, or you're looking in the wrong
place.

Well, these problems are sometimes subtle. But I wasn't actually
referring to a specific problem - I'm just looking for a general-purpose
tool to investigate future problems of the type I described - which I
know from personal experience and anecdotes from coworkers, have
occurred not infrequently in my current environment. Let's just say that
I've been involved in one already in four months of work, and I think
I'm on the cusp of discovering another. (These are problems in
unreleased products, by the way - the QA testing we do is very rigorous.
The reason I've been asked to investigate and set up a system of this
kind is so that we can analyze QA's reports more effectively).

I saw one like this, an SMPS that would occasionally catch fire.

No actual fires, but in my previous job we had a product that would melt
into a lump on the table (under certain conditions). Does that count?

 

[Dave VanHorn]

No actual fires, but in my previous job we had a product that would melt
into a lump on the table (under certain conditions). Does that count?

Sounds like fun..

After a few years, you learn all that stuff they don't teach in college,
like "What's That Smell?"

Hmm.. Sniff.. Resistor... Half-watt... Sniff... Allen Bradley, 1985.
Sniff... Hmm.... 10%!

 

[John Woodgate]

I read in sci.electronics.design that Dave VanHorn <[email protected]>

In order to get clean edges at 3kHz, you'll need at least
6kHz bandwidth.

You need at least NINE kHz. There is no second harmonic in a square
wave, but there is every odd harmonic. Preserving the third and fifth
gets you a fair approximation to a square wave, but the phase-shift in a
cassette recorder makes the 15 kHz response (if any) of little
advantage.

 

[John Woodgate]

I read in sci.electronics.design that Dave VanHorn <[email protected]>

In the end, it was a
reverse-polarized screw that everyone noticed, and everyone discarded as
a problem source.

A WHAT?

 

[John Woodgate]

I read in sci.electronics.design that Lewin A.R.W. Edwards
hlink.net>) about 'Recording digital data to analog tape... revisited',

This problem turns out to be one of those utterly "DUH!" sorts of
things. I started by connecting the tape recorder in question up to a
ZX81. I saved a program and attempted to load it. No dice. The on-screen
datablocks didn't look right either (if you've used a ZX81, you'll know
what I mean - but in brief, the ZX81 outputs the audio data to the
raster while loading/saving).

Tried it with another tape recorder. No problems there. WTF?

To cut a long story short, this particular recorder I'm using, although
it is mono, uses stereo connectors for both mic and ear. Somehow (and
I'm not clear on why this is happening) when I insert my mono plug, it
doesn't get a reliable ground connection. If I use clipleads to connect
to the appropriate points directly on the recorder's PCB, the problem
goes away.

If you were using the mono plugs from the ZX81, they are a non-standard
part that doesn't work properly with current mono or stereo 3.5 mm
jacks.

 

[Paul E. Bennett]

* My first computer was a VIC-20 (I have dozens in my collection now).
The first computer that was unconditionally mine, though (as opposed to
being a family computer) was a ZX81.

Recent house moves meant that I disposed of a number of my former computer
systems. As I have relied on laptops a lot in doing site based work you
soon find that the hinge arrangements are the biggest weak spot. So there
was about five laptops that got stripped down and sent to the great
junk-box in the sky. Some of the bits, like steppers out of ancient disc
drives, are useful to some robotic projects.

My wife (not an electronics person) rolls her eyes when she sees the
stacks of equipment I need. She said "Don't most people have just one
oscilloscope?" (See part of my "electronics workspace" at home
<http://www.larwe.com/workspace.jpg>). The problem is, I actually need
at least one more scope - I'd like a HP 54645D like I use at work -
because I need something with deep memory. The 16-channel
mini-logic-analyzer is very useful too.

Your workspace (presumably at home from the comments) is not as extensive
as mine was about three moves ago. I had a whole room with a long bench and
adjustable shelving, TEK486 scope (whose LOPT died recently) fixed voltage
power supplies (5V, 12V and 24V) distributed onto bench sockets, a variable
PSU (Farnell Dual 2A), laptop position, soldering iron position and links
to the audio systems auxilliary input (which was also my background audio
wallpaper - usually BBC Radio 4, sometimes BBC Radio 2, sometimes GWR).

I have never needed more than one scope at a time except at the current
workplace (where I have six available to me) when we were looking at
waveforms on the two ends of a spread out system. That was just to
eliminate having to lug the scope up and down stairs though.

I'd like a spectrum analyzer, too. Oh well. Gotta pick up some more
contract work before I can buy those toys

Hired a few but there are other ways if you are cash strapped (providing
you don't mind spending the time). One way to achieve a base-band spectrum
analyser is to build a very narrow filter and scan its passband along with
the sweep drive to the scopes X input. AT RF then wavemeters are useful. I
have a nice (home built) coaxial one for UHF.

I need to get into PC data acquisition at work. I have a "back burner"
project simmering on my to-do list which involves collecting long radio
transmissions (several days at least). The signal of interest consists
of a 4kHz or 10kHz baseband signal recovered from a test point on
devices we're trying to debug. Oftentimes problems with these designs
only appear after days or weeks of continuous uptime. We have various
tools for analyzing the behavior of systems under test, but none of them
are fully satisfactory. There's a lot of guesswork, followed by minor
tweaks then push the whole thing back into the test queue for another
week. It would be great to capture EVERYTHING that was said by all
stations over the week, synchronized with a couple of other signals that
would indicate specific states being reached by the device.

Triangle Digital Services produce the TDS2020 which, with the additional
boards they produce and the software library they have, is geared towards
data collection. You only have to add the input signal conditioning. I am
using some in my current workplace project for measurement and control of a
High Energy Plasma Physics experiment involving a cryogenic device. TDS are
linked from my Forth page.

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

 

[CBFalconer]

.... snip ...

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

How did you handle the final bit, especially if zero? Either you
create a final clock pulse to shift it out, or you need to specify
that the recording is terminated with an extra 0 bit, as I see it.
That way you use the clocking edge to set the detection window,
while shifting out the previous bit.

 

[Kryten]

After a few years, you learn all that stuff they don't teach in college,
like "What's That Smell?"

Hmm.. Sniff.. Resistor... Half-watt... Sniff... Allen Bradley, 1985.
Sniff... Hmm.... 10%!

Many years ago at a satellite engineering company I walked past a VMEbus
crate some softies had just switched off and saying "whoops, that burning
smell isn't a good sign". I sniffed and said "I think a couple of tantalum
caps have caught fire, have a look in the corners next to the bus
connectors".

They looked quietly impressed, and no I didn't sabotage it!

 

[Dave VanHorn]

A WHAT?

You heard me..

The screw was holding a transistor and it's heat sink, to the PCB.
It was supposed to be installed pointing up, with the nut on top, so that
the extra length pointed up into the heat sink area.. They installed it
pointing down, because it was easier to handle. This made the screw contact
the can of an electrolytic.

Now, the can is insulated from the cap terminals, > 10Mohms

Why did this cause the reg to go up in flames?