File: ?\pic\GPSDO\html\gpsdo_pic.htm Web: www.qsl.net/dl4yhf/gpsdo/html/gpsdo_pic.htm Author: Wolfgang Büscher, DL4YHF Date: 2016-02-21
Under construction !
This file descibes the PIC microcontroller firmware for a GPS-disciplined oscillator (GPSDO).
It is closely related with the sourcecode (gpsdo_pic_main.c),
available on the author's website (see links above).
Details are in the sourcecode itself; this document actually links into it.
Those links into the sourcecode (mainly "C") only work if the sources are located
in the same directory as this document. The sources also 'link back' into this file,
when loaded with an HTML browser.
The output of the CIC filter, decimated to fs_out = 12.5 kSamples/second, can be sent via the PIC's serial port.
Samples are sent with 16 bit per sample, because the decimation-by-four increases the resolution to more than
the 12 bits from the ADC (with 'dithering noise' being always present with real signals).
In addition to the 16 bits per sample, each sampling frame contains an additional byte for sychronisation,
and to deliver additional information from the GPSDO to the receiving PC (details in a future chapter).
The baudrate is fixed to 500 kBit, which is far below the maximum a modern USB <-> RS422 or RS323 adapter
can handle. With a FTDI-chip-based USB (2.0) to 'RS-232' adapter ("Delock USB 2.0 to serial"),
this baudrate worked perfectly, and during a long test run (plotting the phase of the subsampled DCF77 signal over many hours),
not a single byte was lost on the serial port.
Figure 2: Input noise of the analog input, with a 1 kHz 0.1 mVpp test signal (-90 dBfs).
FFT bin width ~ 0.8 Hz (12500 Hz / 16384 points).
Green: Peak holding graph. Red: Long term average.
Yellow: Momentary spectrum. Blue: Averaged spectrum with input fed with 'DC'.
Passband droop of the CIC filter not compensated here yet.
Warning [1273] ; . Omniscient Code Generation not available in Free mode
(...)
You have compiled in FREE mode.
Using Omnicient Code Generation that is available in PRO mode,
you could have produced up to 60% smaller and 400% faster code.
See http://www.microchip.com/MPLABXCcompilers for more information.
Fortunately much of the "C" code is only used for initialisation, and since up to now
there are no really time-critical parts in the program, it doesn't matter much if the code
"could be 400% faster" (it's a bit hard to believe why a chip manufacturer makes a
development tool, which can only be used to develop code for their own product (PICs) so inefficient
- see 'rants' in a later chapter. > How do you turn off ALL of the 'clever' formatting in MPLABX's editor ?
> It seems like it took me forever to get MPLABX to stop doing stuff I didn't want it to do.
> I would like the cursor to stay where I put it when start typing.
No much to add to that quote from a PIC forum. Don't waste your time on it
- you simply cannot turn off that annoying feature (at least not in "MPLAB-X IDE V3.15", anno 2015).
But for debugging, we are doomed to use MLPAB X, because MPLAB 8
still cannot keep sourcecode lines and breakpoints in sync while debugging,
as soon as subroutines (or functions in C) are called... aaargh !
Where is the "MPLAB-X" project file to "build" the firmware with ?
There is no project file. MPLAB-X makes everything as complicated
and obfuscated as possible :
> When you try to open a project with MPLAB X, every directory you select
> (in the file browser opened via File->Open project for example) looks for
> an nbproject subdirectory which contains all the 'project' files.
> There are file such as configurations.xml, etc that tell MPLAB X that
> this folder is an MPLAB X project.
(..)
> When you create a project in MPLABX, none of the files that it creates
> can be used to open MPLABX. Instead, you have to open MPLABX and then
> open your project by navigating to it (or leave it open in MPLABX when you
> close the IDE).
(..)
> (MPLABX is based on Netbeans version 6, so I imagine something similar
> could be done to open Netbeans projects. I'm not familiar with the
> native Netbeans or other types of Netbeans projects, so I'm just guessing here.)
NETBEANS ? JAVA-BASED IDE ? That explains why MPLAB-X is such a sluggish, bulky monster !
* Two Capture/Compare/PWM modules (CCP):
- 16-bit capture, maximum resolution 12.5 ns
12.5 nanoseconds timer capture resolution for a chip with a maximum specified clock frequency of 32 MHz ?
Whow, almost too good to be true, because 12.5 ns would mean the timer (connected to the capture unit)
could run at 80 MHz input clock. -> May have to try a dsPIC30, not dsPIC33, instead...
more on that in C:\pic\GPSDO_dsPIC\GPSDO_dsPIC.c .
* One of the two PSMCs (Programmable Switch Mode Controllers)
should be 'kept free' to produce a two-phase ("I/Q") signal
to drive an external VLF-, LF-, or even MF-downconverter;
* But both PSMCs share the same clock frequency input pin
( PSMC1CLK == PSMC2CLK == "OSC1/CLKIN" == RA7 ),
so the same source must be used for the "core" and the PSMCs anyway
( who wants to run the "core" and other peripherals from an R/C oscillator? )
* To measure the instantaneous frequency (and possibly phase)
of the VOCXO with the best possible resolution, the 1-pps
sync signal from the GPS receiver must capture the value
of a timer (clocked by the VCOCXO) running at the highest
possible frequency. There is an "internal 64 MHz signal"
in the PIC16F1783, originating from the PIC's "4 x PLL"
[PIC16F1783 DS page 54]. But that PLL's input frequency
range (or VCO tuning range) is limited, and jitter not
specified, so we better don't rely on that !
The sync output from a Garmin GPS 18 LVC seemed to "step"
by 40 ns ( 1 / 25MHz) when compensating its own oscillator drift
so a capture timer resolution of 20 .. 40 ns would be sufficient;
the loop's low-pass filtering must remove the phase noise anyway.
To lock the SDR-IQ's 66.666 MHz clock to the 10 MHz OXCO,
the greatest common divisor (GCD, deutsch GGT) would be
GCD = 3.3333 MHz = 10 MHz / 3 = 66.666 MHz / 20 .
With the OCXO frequency doubled to 20 MHz (simple doubler):
GCD = 6.6666 MHz = 20 MHz / 3 = 66.666 MHz / 10 .
On a PIC16F1783, it's worse: Despite Fosc=40 MHz (internal PLL),
the damned timer (which feeds the capture unit)
is still restricted to "Fcyc" = Fosc/4 = 10 MHz,
i.e. 100 ns "true" capture resolution
(not 12.5 ns - the datasheet makes some funny assumptions).
See details in the next chapter and ProcessCapturedSyncPulse().
IC16F178x "64 MHz" source for the PSMC (PWM) ??
-----------------------------------------------
If what the datasheet calls "64 MHz" (output from the "4 x PLL")
could be used to produce 40 MHz from the 10 MHz OCXO, things start
looking better:
GCD = 13.3333 MHz = 40 MHz / 3 = 66.6666 MHz / 5 .
Is this possible (with a PIC16F1783) ?
Trying to find answers in the data sheet [PIC16F1783 DS, rev "E"]:
- what the PSMC appnote calls "64 MHz" in figure 1 is in fact
the output of the "4 x PLL" in the datasheet (figure 6-1,
"Simplified PIC MCU Clock Source Block Diagram" .
- the INPUT to the "4 x PLL" is a multiplexer ("PSMCMUX").
ONE of the inputs to that multiplexer is another multiplexer,
"PRIMUX", which also provides the CPU input clock.
The other input to "PSMCMUX" is useless here (internal osc).
- One of the INPUTS to the "PRIMUX"-multiplexer is one of
"LP, XT, HS, RC, EC" = Clock fed into pin "OSC1" .
Here: "EC" (External Clock) from the 10 MHz (V)OCXO .
- The PIC's "4x PLL" must "fall within specifications".
> See the PLL Clock Timing Specifications in Section 30.0
> "Electrical Specifications" .
If those are what they shout out in upper case,
"PLL CLOCK TIMING SPECIFICATIONS", in "TABLE 30-8" :
Param "F11" = "Fsys" = "On-Chip VCO System Frequency" 16 to 32 MHz,
Param "F10" = "Fosc" = "Oscillator Frequency Range" 4 to 8 MHz .
WTF !? Where should the "64 MHz" signal for the PSMC
come from, if the "4x PLL"'s VCO can produce a maximum
frequency of 32 MHz ? ?
The merchants promise "a PWM with 64 MHz input clock"
but the internal PLL can only provide 32 MHz for the PSMC ?
( -> Forget about the "64 MHz" anyway. For the GPSDO,
the PSMC clock must be based on the OXCO signal,
so 4 * 10 MHz = 40 MHz is the maximum we can achieve. )
Other users (on piclist.com) stumbled across another issue :
> Fig 16-1 in the datasheet seems to imply that a 4xPLL could
> be used on a 16MHz EC input to get 64MHz. (for the PSMC)..
Response from Jesse Lackey :
> Unfortunately not... for external input, FOSC<2:0> is 010.
> See that table in 6.1. For all modes not 100
> (i.e. not from internal oscillator), you can either enable
> the PLL or not (the PLLEN or SPLLEN column).
> If you enable the PLL, then that 16Mhz becomes 64Mhz
> and goes to Fosc @ 64Mhz, because PLLMUX is 00.
> You can't control PLLMUX.
> So... doesn't work.
- Beware of yet another pitfall: The datasheet says (..)
> "This selection should not be made when the PSMC
> is using the 64 MHz clock option."
> The Internal 64 MHz clock utilizes the system clock
> 4x PLL. When the system clock source is external and
> the PSMC is using the Internal 64 MHz clock, the
> 4x PLL should not be used for the system clock
Ok. We promise to be careful.
2015-12 : No problem to run the PSMC at 40 MHz (Fosc, not Fcyc),
slightly violating the spec.
But what else can you do with a '4 x PLL' and a 10 MHz OCXO.. :)