GPS PLL ADC Synchronisation - Page 1
Forum section: electronics / projects

author: Aodhan145
author_rank: Frequent Contributor
timestamp: January 15, 2018, 11:55:33 pm
content: I am currently working on a large scale data collection project which involves collecting a large amount of data over a long distance. I am producing a data logger using the ADS131E08 24-bit ADC. I will run the ADCs at either a sample rate of 8ksps or 1ksps. To effectively synchronize them I plan to run their clock from a PLL based clock from the GPS PPS and use the PPS to initiate the conversions.The ADC clock rate is relatively high at 2.048MHz, this clock needs to be very accurate to ensure a constant sample rate across all devices and ensure they are sampling all at the same time.I have thought of multiple ways to overcome the problem:DPLL based of FPGASecond GPS UBLOX NEO-7M GPSAnalog PLL using VCXOThe DPLL from the FPGA seemed flawed as it wouldn't have enough resolution to accurately lock the signal to the PPS as it is very high frequency. There was not an FPGA on the board so this would need to be added if used.The UBLOX NEO-7M GPS has inbuilt PLL functionality which can generate any frequency, this would be an easy solution if it is accurate and low enough jitter as it wouldn't be an integer division of its 48MHz clock. The second GPS would also add an incredible extra cost to the boards. This is a personal project so the funding is limited. Also, the main source for these GPS is Chinese markets such as Aliexpress which are littered with fakes so this would be a gamble in itself.Another thought was to develop my own PLL loop on the board. I don't have any experience with this I understand how PLLs work but this would be a new experience for me. I want a robust solution as I am time-limited. My thought was to use a VCXO oscillator like this onehttps://www.digikey.co.uk/product-detail/en/VTEUPCJANF-2.048000/1664-1355-1-ND/6126651. It oscillates at the desired clock of 2.048MHz and has an APR of +/- 50ppm. This would be a cheap solution but I have no experience with it and I need to ensure it would work, so any help and comments on this are welcome.My last stupid thought was to use a precise enough oscillator to get a constant sample rate and then measure the time from the GPS pulse to the first data ready pulse using a timer on the microcontroller then send that time back with the data to the raspberry pi and use sin x / x interpolation to shift the sample time base to remove the time error.That was my thought process of trying to solve this problem, I'm open to any suggestions it's a major wall in this project.

author: Leo Bodnar
author_rank: Frequent Contributor
timestamp: January 16, 2018, 08:43:07 am
content: Quote from: Aodhan145 on January 15, 2018, 11:55:33 pmYou will see 21ns peak-to-peak jitter on both PPS or frequency outputs and correction jumps every navigation cycle update.Leo

author: David Hess
author_rank: Super Contributor
timestamp: January 16, 2018, 11:52:10 am
content: Phase locking a 2.048MHz TCXO to the GPS PPS signal is straightforward. I would divide by 16 and phase lock the resulting 128kHz to the PPS to prevent cycle skipping. The oldSimple GPSDOworks this way. Note that the Simple GPSDO relies on a 10kHz GPS timing reference however this does not provide any data in excess of the GPS solution timing.Note however that the ADS131E08 START pin or SPI start command is used to control conversion synchronization. Wouldn't the SPI start command be good enough even with separate clocks?When using the START command to control conversions, hold the START pin low. In multiple device configurations, the START pin is used to synchronize devices (see the Multiple Device Configuration subsection for more details).The datasheet lives up to TI's low standards:To use the internal oscillator in a daisy-chain configuration, one device must be set as the master for the clock source with the internal oscillator enabled (CLKSEL pin = 1) and the internal oscillator clock must be brought out of the device by setting the CLK_EN register bit to 1. The master device clock is used as the external clock source for the other devices....The internal oscillator output cannot be enabled because all devices in the chain operate by sharing the same DIN pin, thus an external clock must be used.What?

author: Aodhan145
author_rank: Frequent Contributor
timestamp: January 16, 2018, 12:32:26 pm
content: Quote from: David Hess on January 16, 2018, 11:52:10 amThat's the problem with the ADCs to be synchronized they all must share the same clock. Each data logger will be kilometers apart so I will have to use a GPS derived clock to synchronize them and also ensure a constant sample rate as the oscillators have a very low frequency tolerance.If I was to use different clocks and just synchronize with the start pin they would all start at the same point but they will sample and different frequency and the sample points will drift.I will only have a PPS pin so I need to divide the clock down by 2,048,000 to get a PPS out put for use with the phase comparator. I am unsure about the duty cycle error from the oscillator as it is 50% +/- 5% which could cause error using a simple XOR phase detector. How do I calculate the amount of filtering required?

author: ogden
author_rank: Super Contributor
timestamp: January 16, 2018, 12:45:51 pm
content: Quote from: Aodhan145 on January 15, 2018, 11:55:33 pmDo you really need 2.048MHz ADC clock? What about 2.000MHz?What you consider as "low enough" jitter? Please name a number. I doubt you need +/- 20ns timing for 8Ksps application. If you implement START pin synchronization for *every* ADC conversion, then you can do software DPLL using timer of microcontroller - very low cost/effort solution worth to consider.

author: Aodhan145
author_rank: Frequent Contributor
timestamp: January 16, 2018, 02:34:46 pm
content: Quote from: ogden on January 16, 2018, 12:45:51 pmLow enough jitter is jitter that will not reasonably effect the sampling time of the ADC and doesn't affect the SNR of the ADC which 22ns should do well enough, but the second GPS option is two expensive and I would rather implement a PLL.The ADC is designed to run from a 2.048 MHz clock, 2MHz is well with in its recommended clock frequency, but if you assume the sampling rate is directly derived from the clock that is a 256 division. 2.048MHz / 256 = 8ksps. 2MHz / 256 = 7812.5sps. Which is not a good sampling rate. You can not use the START pin synchronization for every conversion unless it was run at a very low sample rate due to the settling time of the ADC which is 0.56640625ms at 2.048MHz clock with 8ksps sampling rate.

author: Gribo
author_rank: Frequent Contributor
timestamp: January 16, 2018, 03:09:42 pm
content: What sort of link (Logger to collector) will you be using for these loggers?

author: Aodhan145
author_rank: Frequent Contributor
timestamp: January 16, 2018, 03:27:29 pm
content: Quote from: Gribo on January 16, 2018, 03:09:42 pmI am communicating through to a raspberry pi which will then log to a USB pen and if it can upload to a server. Sadly they are all rural so the most likely no internet connection to them so I'll mainly have to go manually collect them all and change the USB pen every two weeks to once a month.

author: ogden
author_rank: Super Contributor
timestamp: January 16, 2018, 04:30:20 pm
content: Quote from: Aodhan145 on January 16, 2018, 02:34:46 pmIf ADC settling time is 0.56ms at 8ksps - it averages heavily (as delta-sigma ADCs w/o S&H buffer usually do). In this case precise sample timing synchronization for all stations is unnecessary overkill/overengineering - because data is "blurred". All you need - register GPS time each 1PPS second in sample storage so you can calculate time of each ADC sample later. In addition to GPS time you can log least 21bits of 2.048MHz sample clock - then you can calculate absolute time of each ADC sample with around 1us precision which is more than you ever need for given ADC.I think case closed

author: Aodhan145
author_rank: Frequent Contributor
timestamp: January 16, 2018, 05:13:50 pm
content: Quote from: ogden on January 16, 2018, 04:30:20 pmThe storage capability of the data loggers is limited so the final sample rate will most likely be limited to 1ksps. This is a very large data project which a large amount of data will be analysed and a variety of measurements will be taken using these from solar irradiance to phasor measurements. Its crucial that these are all synchronised to begin with as it will greatly simplify the analysis. Calculating the absolute time of each ADC sample is simple enough and using that to interpolate the data and shift it to align the data would be as well but this is likely to be over 500GB of data so that over complicates things and is not feasible. PLL is a much simpler solution to this problem.This isn't overkill when it comes to having all the data aligned for analysis after as this will be heavy computationally.

author: ogden
author_rank: Super Contributor
timestamp: January 16, 2018, 05:56:00 pm
content: Quote from: Aodhan145 on January 16, 2018, 05:13:50 pm"Simpler for electronics engineer" but much more riskier solution which will require quite a testing to make sure that it works wellover long periods of time. When you discover that there is problem in your PLL - 1) all your data is more or less trash 2) you possibly need fix & re-spin of hardware and measurements as well. With my offer you can "fix" everything in software in case you still have initial data. Modern computers can process & align data/time "on fly" while reading flash drive, w/o significant added delay. Other option - station can sample at 8Ksps and align data at exact "absolute time" boundaries, write already aligned 1ksps data into flash storage.Just two cents how I would do it

author: mjs
author_rank: Regular Contributor
timestamp: January 16, 2018, 06:19:10 pm
content: I would use the approach proposed by ogden - syncing the data based on GPS 1pps with Octave/Python/whatever is not that difficult. Just run a timer/counter with the 2.048MHz and capture at 1PPS signal. Probably quite difficult to do with RPi, but very simple with almost any small MCU.You can get easily 12.288 VCTCXOs with +/-5ppm tuning range. Divide by 6 to get 2.048Mhz.What is your signal source and how have you reached the timing requirement ?

author: David Hess
author_rank: Super Contributor
timestamp: January 17, 2018, 04:12:57 am
content: Quote from: Aodhan145 on January 16, 2018, 12:32:26 pmThe idea would be to synchronize by driving the start pin with a signal based on the GPS 1 PPS but if that is not good enough then it is not good enough.QuoteYou actually do not want to divide down by 2,048,000 which is why I linked an example where this is not done. Doing so will allow the clock to start off out of phase by 1/2 second and it will take too long for the PLL to pull it into phase. Plus it is not necessary.If the VCXO could be off by +/-50ppm like you said, then over one second it will have a maximum uncertainty of +/-50uS. So the 2.048MHz clock only has to be divided down by say 256 (1) to yield 8kHz or a period of 125us and it will always lock on in a minimum of time without locking to the wrong frequency.If you do divide by by 2,048,000, then the counter can be reset or "jammed" initially to start off close in phase to the 1 pps signal but I think it is easier to phase lock against a higher frequency as described above.For the loop filter, what matters is the 1 second update time and not the VCXO frequency or divided VCXO frequency. Further, the GPS solution actually wanders over 10s to 100s of seconds so the loop filter will be considerably slower than that for best performance and the 1 pulse per second update rate is not a limiting factor. Calculation of the filter depends on the sampling frequency, phase detector gain, and VCXO tuning gain, but this gives an idea of the time constants involved.(1) This could be done with a standard 74 series dual 4 bit binary counter like the 74HC393.

author: Aodhan145
author_rank: Frequent Contributor
timestamp: January 17, 2018, 08:45:44 pm
content: Quote from: David Hess on January 17, 2018, 04:12:57 amYeah, I realize now if I was to use a VCXO as the oscillator with a low pull range and trying to lock to the PPS it could take a crazy amount of time. If I was to use a SN74LV4046A for the PLL, could I divide by 2,048,000 to achieve the 1PPS? I need to use the 1PPS from the GPS for other reasons and to get a high-frequency output such as the 10 kHz as you mentioned I would be stuck to add a second GPS which is part of the problem to begin with. If I use the SN74LV4046A will it lock to the PPS reasonably quickly?

author: ogden
author_rank: Super Contributor
timestamp: January 18, 2018, 12:42:35 am
content: Quote from: Aodhan145 on January 17, 2018, 08:45:44 pmWhy do you want to build it "oldskool way" by all means? I do not even want to invest time explaining why it is bad idea to even consider making PLL with 1Hz phase comparator frequency - there's lot of resources on internet about PLL loop filter design & tuning.Instead you shall buildDPLLdigital frequency-locked VCO steering - measure VCO frequency against GPS 1PPS using timer of microcontroller and steer VCO digitally using DAC or decently filtered PWM.