updated: 2012/04/06 10:42:35 +0200
24 November 2009
I've been reviewing the clock issues I've experienced with the PCM-X2 decoder. The problem is synchronizing with the rate at which samples arrive from the digital source (video tape). My experiments have shown that samples arrive up to 0.16% faster than the nominal rate. My plan was to have a VCO on the PCM-3 to enable it to sync with the source. The VCO, however, only has a pullability of +-200ppm (0.02%) which may not be enough. The decoder must have some sort of VCO whose frequency is adjusted dynamically to sync with the rate at which samples arrive from tape.
24 November 2009
I would like to run the encoder system clock synchronous with the digital source clock. To this end I have calculated the PLL settings for the dsPIC to run off of the recovered system clock from the DIR9001. With the DIR9001 providing a recovered clock of 11.2896MHz (256 x 44100Hz),
With these settings the dsPIC33 will run at 39.51MIPS. The difference is that this time the PIC is synchronous with the digital source (CD player). If samples arrive slightly faster, the video signal will have a slightly higher refresh rate and visa versa. This also means that a fixed sample to line ratio can be used, simplifying buffer management. It should also smooth the rate at which samples arrive from tape.
Data from PCM-X2
The system clock generator of the decoder should have a VCO running at close to the correct frequency of say 11.2896MHz (256 x 44100Hz). At 11.2896MHz (period = 88.577 ns), 722.53 cycles will fit into 64us.
At 22.579MHz (period = 44.288941 ns), 1445.056 cycles will fit into 64us. Round off to 1445. A small PIC can act as a counter connected to the VCO, if the VCO generates its' 1445th cycle before the next sync pulse begins, it's running too fast. If the VCO generates its' 1445th cycle after the next sync pulse has started, it's running too slow. An error per line of 0.056 cycles still exist. 0.056 is 38.754 ppm of 1445. To minimize the error several video lines can be used for example: If 1445.056 cycles fit into 64us then 28901.12 cycles will into 20 x 64us lines. 0.12 is 4.1521ppm of 28901 if 28901 is used as the counter. Similar equations will work for 11.2896MHz with the added advantage that the same PLL settings can be used on the decoder dsPIC33. Also consider the following:
Counting cycles over 1 video line produces less jitter. The clock generation may have to be done with discrete logic as a PIC may not be fast enough or accurate enough. A 12 bit synchronous counter can be used. 3 x SN74LV163A for the VCO cycle counter. A fast/slow decision is made depending on which counter reaches their terminal count first.
Alternatively the clock run-in can be used as a reference frequency, similar to a colour burst.
Clock run-in top left.
With each bit 400ns long, at 22.579MHz 9.03 cycles will fit into one cycle of the run-in clock. Rounded off to 9 cycles, the error is 1.32ns. The run-in clock would be the best bet for system clock generation as sync pulses from VCRs can be unreliable. If the clock run-in is locked to the digital source clock used during recording (CD-player) a 200ppm pull on the clock generator might be sufficient.
"The sampling rate coming from my Sherwood CD player is 44103 Hz (0.0068 % off). This confirms my suspicion that samples are coming in slightly too fast. The stereo rate would be 88206 samples/second." from PCM-X2 development blog.
0.0068% is 68ppm. Well within the +-200ppm pull range of the MAX9485
1 December 2009
Researching PLLs now. Below is a possible clock recovery circuit for the decoder board.
a CD74HCT4046A phase comparator can also be used
6 February 2010
It occurred to me that a simpler method of clock generation would be to use a system where the dsPIC monitors the internal sample buffer level. The goal is to keep the buffer half-full of samples at all times. If the buffer is more than half-full a "0" is output. If the buffer is less than half-full a "1" is output. This will have the effect, if filtered and applied to a VCO of speeding up the playback clock should the buffer become too full and slowing it down should the buffer become too low. This method would negate the need for a 44100 reference clock burst recorded on the tape. It also has the advantage of always playing back the samples at the rate at which they arrive.
Alternative playback clock recovery method using buffer monitoring
Decoder unit clock recovery, proposed circuit
7 February 2010
I'm planning to redesign the PCM-X3 encoder clock to run synchronously with the digital source clock. This will allow a fixed number of samples to be loaded per video frame, simplifying buffer management. It will also simplify playback as the 44100Hz sampling frequency will be locked to the incoming video signal. What concerns me though is jitter in the incoming video signal. Experimentation can determine how much of a problem this would be. Reclocking with a D flip-flop [74ACT374] operating from a high frequency crystal oscillator could remove or reduce jitter on the recovered clock used for playback.
9 May 2010
I'm so glad I managed to improve the performance of the PCM-X2 even more before starting the PCM-X3. Less to fix. I've decided to add a PLL to the PCM-X3, to lock onto the rate at which samples arrive from tape, using a CD74HCT4046 PLL with VCO. It has the phase comparator onboard as well. This is simpler than the MAX9485/crystal combination above. I've decided to use the circuit cards from the PCM-X2 for the PCM-X3 as the circuits would be 99% similar. I am making a special motherboard for the cards though.
1 January 2011
I've started construction of the PCM-X3 using the decoder and encoder boards from the PCM-X2. I have glued the encoder/decoder boards to the side of a piece of Vero board. On the Vero board will go two dsPIC33FJ128GPs. My regular job and writing my dissertation took up so much of my time in 2010, that I can only work on this again now. I don't know for how long though because I start work again on 17 January 2011. Fortunately most of the hardware is working since I just used the cards from the PCM-X2. I only need the dsPICs, power for the board, interconnects and ports for the ICD. Then I'll have something that works again that I can tweak. As stated earlier, I'm going to run the encoder dsPIC using a clock of 11.2896MHz which is a multiple of 44.1 kHz. This'll allow me to have a fixed number of samples per video field. The PIC16 board didn't allow me to introduce my own clock to the dsPIC, hence the creation of this version.
3 January 2011
DIR9001 configuration on encoder board, SCKO = 22.5792 MHz
The encoder unit will start up with the internal RC oscillator on the dsPIC, confirm the DIR9001 is locked, then switch to SCKO. Clock switch can occur if ERROR pin on DIR9001 is low. Doing further datasheet reading and planning. Summarised here so I can find the important bits easy.
DIR9001 configuration on encoder board, CKSEL = LOW
Re-mappable input/output pins IMPORTANT !
dsPIC33 Pin Layout encoder
DCI Interface Input, page 162 datasheet
SPI Output, page 163 datasheet
16 January 2011
Assembly of the PCM-3 is continuing. My day job and writing of my dissertation is interfering though...oh well.
18 January 2012
So nothing happened for a year. Too many other more important things happening. At least my Professor says my dissertation is "very close" to being finished. I'll hand in before middle of the year.
Working on Goldilocks rekindled my desire to finish PCM-3 so I've been reflecting on clocks and such. The encoder will definitely use a clock which is a multiple of the sampling frequency fs. This means the encoder will produce a fixed number of audio samples per field. So fixed number of samples per second in, fixed number of samples per second out. DIR9001 will feed recovered data clock to dsPIC33.
The issue I've been exploring is regeneration of the playback clock from the video signal at the decoder end. Like any good engineer I'd like to use the simplest solution possible and preferably as few additional chips as possible. The decoder dsPIC33 can perhaps be clocked from a crystal to run at 40MIPS, but it needs to be told how fast to send the samples to the DIT4096 so the buffers don't run empty.
The encoder will be running from the clock recovered by the DIR9001 from the digital source. This means the clock encoded on the video line will be directly related to the sampling frequency. This clock burst can be gated to a comparator circuit controlling a VCO.
In the decoder the interrupt service routine (ISR) reading data in is triggered every time a new line starts by detecting the rising edge of the video sync pulse. The data stream on the left (top) can be sent directly to a 4046 phase with a VCO. It shouldn't matter that there's data on it. Since the encoder ran locked to fs the data stream will have a frequency component at a multiple of fs that the VCO can lock to. This will allow synchronisation of the local VCO to the playback clock. A type II Phase Comparator will be used.
The resulting clock can then be used to clock the dsPIC33 and the DIT4096. Locking everything, including the PIC, to a single clock will allow the dsPIC SPI bus to dynamically follow minor changes in playback speed. The 4046 loop filter should remove jitter caused by the VHS transport.
Recovering a master clock from input data stream.
Centre frequency of 4046 is set by resistor/capacitor. 4046 Using phase comparator 2.
6 April 2012
I dismantled the prototype. There is NO WAY I'm using the 28 pin dsPIC33FJ128GP202. I'll make a new board. See Goldilocks for my reasons.