Recording digital data to analog tape... revisited

I read in sci.electronics.design that Dave VanHorn wrote (in ) about 'Recording digital data to analog tape... revisited', on Sun, 3 Oct 2004:

OK, for me that is the perfect excuse. I often use 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.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

I read in sci.electronics.design that Lewin A.R.W. Edwards wrote (in ) about 'Recording digital data to analog tape... revisited', on Sun, 3 Oct 2004:

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.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

... snip ...

They don't. They get it down a 64 Kbps digital link. They get it into that link with a combination of carefully compensated limited length twisted pair link and complex modulation schemes.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

Has anybody actually seen a "56 kbit/s" modem download at 56 kbit/s ? It appears that most you can get out of these is about 53 kbit/s, even when the modem is a few meters away from the telephone exchange codec in the same room. Apparently the A-law compression makes it practically impossible to get the full 7 bit/symbol, when the lowest segment drops into noise.

Removing any FDM or TDM equipment and loading coils helps a lot :-).

Did you actually get the full 5 MHz bandwidth out of it ? Did you start from scratch or did you have the BBC 405/50 telephone line equalisers from 1937-39 as a reference ?

Paul

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

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

I read in sci.electronics.design that Dave VanHorn wrote (in ) about 'Recording digital data to analog tape... revisited', on Sun, 3 Oct 2004:

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.
The bad news is that everything is prohibited.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk

If you had looked at the picture closely enough you would probably have noticed a possible DUT behind the keyboard. ;>

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
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..
********************************************************************

I remember reading an article some years ago talking about the fact that the

56kbit modems (V.90?) had to be throttled down a little due to FCC regs, in the US. Here's one saying about the same thing as I recall reading:

In Australia, I found this, which suggests and even slightly lower rate as maximum, there:

Jon

It's not even a 3kHz channel, if memory serves. I think the US tarifing requires only 300Hz to 3000Hz bandpass, with some modest specifications on "group delay" and roll-off near the edges. I seem to recall that the phone companies provide a pretty decent cutoff on the 3000Hz edge, but a lousy gradual edge on the 300Hz side, so the usable width is actually closer to 600Hz to

3000Hz.

You can get an approximate idea of the cutoff if you have a piano and play the keys to someone at the other end. At some point, they will just here "click, click, click" instead of a tone.

Unlike V.32, which I believe is symmetric, V.90 is an asymmetric protocol supporting a lower rate up (33.6k, I think, relying on quadrature amplitude modulation, QAM, as does V.32 and V.34) and a higher rate down (the 56k) from the central office line card. That's in part because the phone company has can control things using their 8-bit DAC for better SNR on the downlink side to your modem by using pulse amplitude modulation (PAM.) However, apparently the FCC (in the US) further limits this to a little less, by rule or regulation.

Look up the words "constellation" and "baud" on google. Or "constellation diagram" or "network diagram" or "decision region" or just see:

Jon

Followup to: By author: snipped-for-privacy@worldnet.att.net In newsgroup: comp.arch.embedded

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:

| | | |

Followup to: By author: "Dave VanHorn" In newsgroup: comp.arch.embedded

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

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.

Hi Rich,

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

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

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.

Most of my really cool stuff - such as my original PDP-11/23 and my CRDS

11/23 clone (with 14" hard disk!) had to stay behind in Australia :( I have however built up something of a collection of old friends here. The only thing I really miss is a ZX Spectrum.

Yes!! Some brands are much, much worse than others though. I'm currently working on a vpr Matrix 120-180B5 (Samsung P10 in the rest of the world). I was given this laptop due to a heat problem, and in fixing it I picked up at least half a dozen such units on eBay.. every single one of them has partial or complete hinge failures.

Toshiba's new swiveling hinge arrangement looks good.

I go down the street every week on trash day looking for computers and printers mainly for the motors, but in some cases

Note I did say it was "part"... that's about 1/3rd of one wall, and three walls are occupied with work materials in that room.

The scopes serve different purposes to me. The TDS210 is great for debugging serial communications where I need to freeze the signal and count bits. The Tek 2445 is great for debugging odd timing issues where I need more bandwidth than the TDS210. It's also my weapon of choice when debugging strange analog issues, investigating ringing on signals, etc. The Nicolet 3091 is strictly for long-term analysis of circuits with very slow operation (battery chargers). It has a built-in RS232 interface, and that was an optional extra on the TDS210.

Ah, the easiest way is for me to wait until my workplace throws some out. I don't need much bandwidth. We have some VERY nice equipment in our FCC Part 15 open-air test site, but that's at least $50k worth. Oh well. It's not something I _need_, it's just something I know I would occasionally use if I owned it.

I'll take a look. I was recently asked by my manager to research capital expenses in a certain price range, as apparently my division has been obscenely profitable and management is looking to plough some of those profits back into test equipment.

I haven't posted new photos of myself in a while, but they're not incredibly out of date. I turn 30 in a few weeks (i.e. I had my last birthday last year, and there will never be another).

I really enjoyed the BBC B. Did you ever see that Amstrad Z80-based portable machine (very small and light) which included BBC BASIC?

Exactly so. Imagine that you were looking at a channel that showed

5-minute stills of fine art. You wouldn't notice the freeze-frame.

Hi Lewin,

You are using Manchester coding (biphase'M' I think). The problem is that the cassette recorder introduces a lot of phase shift. If you put an all-pass filter after it with a pot to adjust the turnover frequency (I can't remember if you need lead or lag) you should be able to get the waveform a lot better.

With the Spectrum I wrote routines that used a similar coding scheme to record at 4800 baud. The nice thing about this coing scheme is that it is self clocking.

The only difference in the method I used was that I sent a lot of zeroes (the low frequency) so that the clock edge sync occurred as quickly as possible and then sent a '1' to indicate start of data.

I used to regularly save & load up to 48k of data error free.

Good luck

Robert

Followup to: By author: "Lewin A.R.W. Edwards" In newsgroup: comp.arch.embedded

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.

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