Video Time Inserter (VTI) using a GPS time source
If you set the 'time' manually, about the best you can achieve is 'within 1s'. To get better than that requires input from a computer with access to a NTP Time Server. However writing code on the PIC to support a serial link is not easy. Further, even the best 32kHz clock crystals will 'wander' at bit as the hours (and days) go by = so regular time 'updates' will be required to stop the time 'drifting'. This means having to keep plugging in a cable, which is somewhat inconvenient
Now that a GPS can be had for as little as £10 or so (eBay, China, antenna included) why not just connect one direct to the PIC and solve most of these problems at a stroke ?
The main problem not addressed is the need to write serial link code for the PIC (needed not to talk to a PC but to talk to the GPS) - and since most GPS units default to 9600 baud, this is not as easy as you might think (especially for a low frequency CLK PIC) However, if we take advantage of the GPS '1 second' tick output (the leading edge of which is typically accurate to within 1uS) it's even possible to avoid the need for serial link code. This lets you use a PIC with a 32kHz OSC (which is hard pressed to achieve even 300 baud) The trick is to manually set the time on your VTI to within 1s and then use the GPS '1 second' tick to count complete seconds. The PIC Timer/Counter, which is zero'd by the GPS, then counts PIC CLK cycles to determin fractions of a second. With some clever coding, the GPS 'tick' can even be used by the PIC to determin it's own CLK speed (when using R-C mode i.e. a non-crystal controlled OSC) This approach means you don't have to 'understand' the archaic NMEA 'sentence' structure - or even 'talk' to the GPS chip at all !
Manual time entry is not as hard as you might think. 3 buttons is all you need = one to 'select the (next) digit', one to 'increment' and one to 'decrement' the digit. To indicate which digit is currently 'selected', the PIC needs to 'blink' that digit. If neither the 'inc' not 'dec' button has not been pressed for some time-out, the PIC goes back to 'no digit selected'.
Using the GPS 'one second' pulse
First you need a make sure the GPS circuit 'exposes' the '1s' (1 second) pin. Whilst all GPS chips have this, not all circuit boards allow you to access it (most GPS chips are 'surface mount' and soldering a wire to one of the 'lands' is not easy !)
Although the rising edge is accurate to within 1uS, the pulse length is typically 100mS. So the PIC has to be 'spot' (i.e. Interrupt on) the edge, otherwise the 100mS level will only get you 1/10th second accuracy (ie. about the same as the 'serial transmitted' time) NB. If you need the time to this accuracy (1uS), your PIC has to be running at 20MHz (5 MIPS) or better (for a CPU CLK of 200nS). The PIC Interrupt latancy is in the order of 3-4 CPU CLK's (so at 5 MIPS that's 600-800nS and well within 1uS). In R-C mode, the PIC OSC tops out at 4MHz, so the CPU CLK is 1uS and your accuracy is 'only' 3-4 uS :-)
Using the GPS time
As with all things, you have to watch the specs .. whilst the 'best' GPS chip-sets will run at 9600 baud, some of the 'cheaper' devices default to 4800 baud or even less.
It's not just 'talking' to the GPS chip that's the problem .. The typical GPS chip will output the time in a 'sentence' something like :- $GPZDA,hhmmss.ss,dd,mm,yyyy,xx,yy*CC At 9600 baud, 9 bits per character (about 1,000 characters per second i.e. 1 mS per character) this takes at least 36mS to send (twice that at 4800 baud) This makes the 'ss.ss' part of the time, to 1/100th of a second i.e. 10mS, a bit of nonsense = at best it will be more like ss.s accuracy (1/10th second, 100mS accuracy) - and whilst some chips send 'ss.ssss', this takes even longer to send (and is thus even less accurate) ! ... unless, that is, you KNOW the chip has a 'constant latancy', in which case you can 'plug in' the offset