GPS Timing Receiver

[Magnox]

This is the first step in making myself a GPS disciplined 10MHz reference oscilator, followed by a frequency/timing counter. It would probably be cheaper just to buy them, certainly easier, but I want to design and make my own for the fun of it. I made a bad mistake in this design which I didn't realise until after I had populated the PCB. It doesn't stop it working for what I want, but it's very annoying after all my hard work! I blame my recent cognitive problems (seriously). I'll get to that later anyway.

The receiver is based around a Ublox NEO-M8T module. That is the timing-enhanced version of their feature-packed GPS receiver module. The module comes on a tiny PCB with castellated edges for soldering to another PCB. It includes the GPS receiver itself, flash memory and antenna LNA/filter/power. Nicely, it has a USB interface built in (really a serial-USB converter) to make PC interfacing easy. In addition to the usual 1PPS (pulse per second) output which is the key to using these things for timing, it has a second timing output. Both are reprogrammable to a wide range of frequencies/periods/duty cycles.

This is the first proper thing I've designed in years. While quite simple, it had a bit of a learning curve. Impedance controlled PCB microstips for the antenna and USB and hand soldering 0603 components among them. I decided to have the PCBs made by JLCPCB. There's no way I could hand make a good enough one.

I wanted the board to be suitable both for prototyping and learning to use the thing, followed by using it in the final GPSDO design. I can't afford to buy a second NEO-M8T for that. Hence some of the design decisions.

Design

The circuit requires 3.3V and can be powered from 5V, 3.3V or USB bus power. USB bus power can be enabled with a jumper. I wanted to be able to disable that completely when I put it to its final use (no way USB can power the GPSDO) but it's useful to have for prototyping at first. A couple of diodes and a LDO regulator take care of either 5V source. The regulator is fine with having 3.3V applied at the output if there is no 5V, according to the datasheet. One should only connect 3.3V directly if there is no 5V source. A CR1220 cell keeps the NEO's memory when not powered, to make startup quicker.

Although the NEO already has an additional LNA inside, an active antenna is still advisable if it is on a long cable. The NEO has a filtered, 3.3V power output to drive the active antenna but lacks a bias-T, so one is required. The trace from the module to the antenna is a 50 ohm microstrip with the bias-T and ESD protection connect to this trace directly with no stubs. The bias-T power can be enabled or not by the zero-ohm resistor link R13, just in case I want to use an unpowered patch antenna in the future. Currently I'm using a TomTom external, active GPS antenna I picked up cheaply.

The USB interface has a TVS protection device and the proper 90-ohm differential pair microstrips to the NEO. Well, near enough anyway. A standard asynchronous serial interface is also available on the header pins, at 3.3V, for connection to an MCU. The serial interface can be changed to SPI by fitting a link at R12.

The all-important timing outputs are available on both header pins and SMA connectors, each with an individual buffer. Here is where I made the mistake. My first design used TinyLogic individual buffers for these, an idea I borrowed from ublox's own development kit. At some point in the design I thought it would be simpler to change these for a single IC, a hex buffer. I completely forgot about my intention of being able to drive a 50ohm load. The single IC cannot handle the current required for that. So, despite having 50ohm microstrips to the sockets and termination resistors, it needs to drive a high impedance load. That's not likely to be a problem really, given the low frequency and short connections, but it's really annoying to have made the mistake. If necessary I could probably bridge two buffers together with a bit of wire under the chip to get enough current for one 50ohm load. Of course, I realised this after I had built the board up. If I could afford another NEO module I would go back to the original and have another PCB made.

I used Saturn PCB Design Toolkit (free software) to calculate the microstrips. The PCB is made from 0.8mm FR4 because 1.6mm needed much wider microstrip traces. A drawback of only using two layers. The PCB could have been made half the size, but I wanted to make it easy to use. Besides, it's the first design I've done with almost exclusively SMD parts, and the first I've ever had made for me.

I'm still playing around with KiCad and I've attached the design files in case anyone wants to make one. I'm not sure I like KiCad though. My next design might be with something else. Note that I've included some libraries for the parts, including two for the NEO. I used one (from the repository) in the schematic, only to find the PCB footprint was wrong. So I found another one with a correct footprint and used that for the PCB. C7, C13 and C15 are ESD protection devices, not capacitors. KiCad gave them that symbol from its library, silly KiCad.

The board works (other than the 50ohm termination thing) perfectly. I populated the power parts first and checked power lines, because I didn't want to blow up a very expensive NEO-M8T. Then the rest of the components apart from the NEO and another continuity check and voltage level check on important pins. Finally, I soldered on the NEO itself. That was a pain to do. The castellated pads didn't seem to want to take solder on some of them, probably ground planes, even with my 'big' iron tip. I did most of the soldering under a 20x binocular microscope because my eyesight is so bad I can't even see an 0603 on my desk without my glasses now (literally).

Seeing the PPS LED start flashing about 15 seconds after I applied power from a PSU was so good! That meant that I hadn't managed to kill the NEO with the dodgy soldering; it had got a satellite lock and was functioning. The NEO 8 is really sensitive. My antenna is inside on the windowledge and other GPS units really struggle to get a signal there; I usually have to hold them out of the window for a few minutes while they find some satellites. The NEO 8 took 15 seconds from a cold start to be up and running!

The board also works fine from USB power and talked nicely to the PC. It shows up as a virtual COM port. Ublox's U-Center software talked to it, as did Lady Heather (a free, very useful program for GPS timing systems). Within a couple of minutes of powering up again, it was tracking so many satellites they were overlapping on the display. I used U-Center to program the NEO to fixed location timing mode, and the second timing output to 10KHz and checked outputs with a 'scope. All is as it should be.

Next step... use this to prototype my GPSDO. More designs (hopefully with fewer mistakes) to follow when I figure out how to make that.

[Wizpic]

Congratulations on your project, well documented and presented. Something I’ve never really played with may be one day, that’s the beauty of working on projects you lean from your mistakes and learn more along the way. It’s like my wireless meter I did, the first one worked really well but then the second one I did where I improved on the design changed the case which was better suited and now looking at making mk3 of it with it’s own integrated battery/charger built in.

I’ve never used kidcad I’d recommend Altium a bit of steap learning curve but the best program by far in my opinion

[Magnox]

Thank you Wizpic! Yes, it's all a learning experience. That's what I want, and why I want to design my own things rather than just take the easy option and grab someone else's from the 'net. I want the challenge.

Which version of Altium do you use? I'll take a look at it. I've been trying to decide which software to settle on, but I don't want to spend ages trying out and re-learning every software package when I could be concentrating on making things instead. I'm not familiar enough with any of them to have a preference at the moment. I need to pick one and stick with it.

I use Multisim often for testing things out, and I have a big, partially finished project done on Proteus from a few years back that I might resurrect.

My designs go up to relatively complex things (for a hobbyist) with CPLDs and small FPGAs, so software suitable for perhaps a four layer design would be beneficial.

Being able to have PCBs made, affordably, is a game changer for me.

Edit: I've just remembered why I had not considered Altium: all the talk about codearmor and Altium trying hard to identify unlicensed users. Although I have good firewalling in place, I don't like the thought of that.

[Wizpic]

I use the latest version, luckily I’ve not had any issues so far but then again I’m only a hobby person and not a company. Only use it from time to time.
It is easy to use if you have used other pcb software.
My designs don’t get that complex so I use my CNC to make a one off for testing and if all is good and I need more I just get my pcbs from e-bay very cheap for 10 off, can’t be done with the chemicals these days very messy.

[gurksallad]

I must admit your PCB is very well layout, way better than my boards. Clean, and still to the point.

Well done.

[Magnox]

Thanks!

My GPSDO is coming along nicely. So far I have the 10MHz OCXO accurate to within 1 part per trillion, based on a running average of the GPS PPS signal. The uncertainty caused by the jitter of the PPS is less than that over the measurement time. It's harder to judge the instability but I've never measured over any period with more than +/-1 count away from perfect. It's certainly far more accurate and precise than anything I have to measure it with, or than I will ever actually need.

I decided on a simple PLL method to lock the OCXO to the GPS timing. That has pros and cons compared to the MCU controlled solution I originally had planned, but it works and I like it.

That was so easy it was an anticlimax.

The MCU (a PIC running at 50 MIPS) is instead being used to monitor the OCXO's accuracy, give a status display and logging output, and generate a stable PPS signal locked to the GPS PPS average but with much less jitter (basically whatever jitter the stabilized OCXO has). I'm working on measuring the generated PPS offset to within about 1ns using the PIC as a TIC (Timing Interval Counter), which then tweaks the PPS clock to adjust the phase.

Right now I'm deciding whether to use a handful of discrete logic, a CPLD, or some small PICs (winning so far) to do some tricky, timed division. I also have a Maxim DS1023S programmable delay line (with a 0.5ns step) on the way to enable really fine tuning of the PPS output synchronization.

It's all good fun!

[Magnox]

(I accidentally edited this and mucked it up, trying to put it back...)

An update to my GPSDO, delayed due to life, drunkenness and girls. Not so many of the latter unfortunately. (Duck's out of way of wife reading over shoulder)

After extensive testing of the dsPIC's CTMU, I've decided it's rubbish. It looks really useful but is let down by sever instability and erratic behaviour.

I set up a carefully wired signal delay line to it, with a stable 50ns delay. I had already measured the CTMU's minimum switching time as 4ns, and it supposedly has a resolution of <1ns. The dsPIC has a massive offset from zero (not mentioned in the fine documents, possibly charge injection?) which is so unpredictable as to make it almost useless. On successive reboots, the offset varied randomly from 20 to 290, on a 10-bit reading! I gave it up as a bad job.

I've been through a number of options on my breadboard, including a 20-bit DAC and MCU control of the OCXO voltage instead of the basic PLL, and even a two-step software method of FLL followed by PLL using a TI TIC chip and the DAC. I felt it offered little benefit over the basic PLL method other than the novelty factor.

Back to the old-fashioned PLL it is.

Right now it's been running for 24 hours. The frequency is long-term stable at 1ppt. Any short-term variation is below my capability to measure. My DMM shows the voltage to the OCXO is stable within 50uV. That's less than 1/3 of a millihertz. I think I can live with that.

Best of all, I've used the TIC chip to lock my derived PPS (DPPS) to the centre of the GPS's jittery PPS. That gives me a low jitter (the OCXO jitter +a few ps) second pulse aligned to within 250ps of the 'real' second start used by the GPS system. Just in case I want to coordinate lightning strikes or earthquakes, or something. Well, you never know.

The TI TDC7200 TIC (Time Interval Counter) chip is great. It has a resolution of 55ps and a minimum measurement time of 12ns, up to 8ms. I'm using a Maxim DS1023 500ps step delay line to adjust the phase of the DPPS, once I've measured it with the TIC.

I've implemented a Kalman filter on the TIC measurements. The longer it runs, the more accurate it gets but it's pretty good after 30 minutes or so. That compliments the whole thing as I've plotted changes and the whole system takes about that long to fully stabilize from cold. I would say it's usable, within 1ppb and a few ns for the DPPS, within ten minutes though.

Here are some pictures of the breadboard layout tonight. I'm continually amazed that it works at all, like this. Oh, and the "Dodgy Chinese level converters" caused no end of trouble, that I finally realized was them causing signal integrity problems. some resistors cured that.

ETA: I forgot, I found another nasty bug in CCS: When using spi_xfer, it would suddenly (after working for a while) decide to stop sending the three bytes it was given and told to send, and only send two of them from then on. Took me ages to spot that, wondering why my DAC was suddenly not working as expected.

One more small detail I forgot to add: The "DPPS Divider" is another PIC, a 16F18313. Those are quite remarkable little things, 8-pin chips packed full of peripherals and cheaper than a couple of logic gates. Great for 'little' jobs.

It divides down a 10MHz clock generated by the dsPIC's PWM to 1Hz. The dsPIC can control that clock in 10ns steps by tweaking the PWM phase cycle by cycle, thus I can move the DPPS phase in 10ns steps for a coarse adjustment. The little PIC also has a built-in sync to the PPS to bring it within adjustability and measuring range to begin with.

When the DPPS is 100ns leading the PPS, I then take over with the TIC, Kalman filtering and Maxim delay line. That allows user-controlled adjustment of DPPS lead in 500ps steps from 100ns leading up to dead-on, or a bit past if I want. It can accounts for cable delay and logic propagation delay to other kit.

[micropcb]

Compliments for a nicely executed job. Your PCB looks very neat
And yes , you learn much more when you do it on your own !

[towlerg]

Wow, I have enough trouble getting a circuit on one breadboard working (and never reliably).

[Magnox]

Yes, I think I was hitting the limits of breadboarding with the 20-bit DAC and TIC method; just too many criss-crossing wires carrying 10MHz clocks and fast rise time pulses. I was getting hit with too many random bugs and glitches to be able to actually develop the thing. I'm sure the method would work well if I had a PCB made for it, or laid it out much more neatly.

Although, as I later found out, those dodgy Chinese level converters were messing things up so it could have just been those causing all my problems. That, and the buggy CCS compiler which wasted another couple of troubleshooting hours.

[gurksallad]

I thought CCS was dead and buried ages ago.

Is there no other compiler you can use? (Because, you know, it's buggy  )

[Magnox]

I use CCS because I made the choice, years ago, to buy their programmer. Their system worked more smoothly for debugging than Microchip's (I couldn't afford Microchip's more expensive hardware) and it's nice having the libraries built in that CCS has. When they work. Now I'm just used to it. It's easy to use.

I ported my CTMU code to MPLab/xc16, to see if CCS was causing my problems, and hit a different snag. xc16 would not trigger the CTMU conversion, despite setting the registers manually exactly the same as in CCS. It's only one bit in a register. Everything else worked if I triggered the conversion manually instead. It was as if xc16 had a fault in the CTMU registers or something. Plus I really don't like some things about MPLab. Especially the way it kept telling me it couldn't compile my code to program the chip, despite have just compiled it successfully a moment before. None of the fixes found on the net worked. It took a while to get to the bottom of that - it didn't like the "!" symbol in the path!

I'm still thinking of converting to MPLab and dropping CCS. If I do a big project, I probably will.