Alan B. Pearce wrote: > The 'usual' method was to use a standard diode detector after the video IF. > This then provides the baseband video plus 6MHz audio carrier. The standard > trick was to use a parallel tuned circuit as a stop filter in series with > the video siganl, and have a secondary winding on this to feed the audio IF. Sounds reasonable. > I wouldn't use a SAW filter. You are not wanting the proper video, so I > beleive that a bandpass tuned circuit ith a few stages (probably a single IC > worth) of gain should get you enough. I was wondering if I could do this with an L/C filter, but figured that SAW filters were being used for a reason (they seem to have a much steeper falloff than most L/C filters). > Essentially you are looking for the > sync pulses and the data stream in the horizontal retrace periods. I cannot > remember the data rate, but it is fairly slow, and has lots of ECC info as > well. True. I don't care if the video looks like crap, as long as I can find the sync pulses, 66%-white TTX ones and black-level TTX zeroes. At 25fps with two fields, each line is 64us in length, consisting of (in time order, left-to-right as you'd see on a 'scope): 1.65us front-porch 4.7us horizontal sync 5.7us back-porch 51.95us visible area I'm going to round the visible area up to 52us to make the math easier. One teletext packet contains 45 bytes of data: a 2-byte clock run-in, a framing byte, then a 2-byte type and address and 40 bytes of text. 45 bytes * 8 bits = 360 bits 52us per line / 360 bits = 0.1444(recurring) us/bit 1/0.1444... = 6.92308MHz bit rate I've managed to find a copy of the BBC/IBA/BREMA spec (on ) which is a bit more concise and to the point than the current ETSI standard. In the BBC spec, the bit rate is specified as 6.9375MHz +/- 25ppm (or 444 times the TV line rate). I also spotted the closed-caption decoder on Eric Smith's website (), which looks like it'll be a nice starting point for the white level extraction/data slicing hardware. Recovering the clock back might be a little more "interesting"... My first idea was to use a PLL but I suspect that it either won't lock in fast enough, or will lock in and then lose lock once the data starts streaming in. I'm probably missing something obvious, but there doesn't seem to be a way to make a 4046 type chip hold the current VCO state, i.e. "ignore the reference, stay at the current frequency and hold". The other option would be to make use of some of the varicaps in my junkbox and make a "pullable" crystal oscillator, and only adjust the frequency when the run-in is running. > See if your local library has issues of Wireless World. They had a > good technical article or two when the service first started. I have a > feeling they also had a project to build a decoder from discrete chips. My local library has pulped all the electronics books, and the Central Library no longer allows access to the magazine collection... :( My university library on the other hand has a near complete set of E&WW from 1970 or so onwards. It's just not indexed in any sane fashion (i.e. no copies of the tables of contents, or anything useful like that). Cheers, -- Phil. piclist@philpem.me.uk http://www.philpem.me.uk/ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist