Actually, the whole project is to measure time difference of arrival of this satellite signal at different locations about kilometers away.
Each station will have the same oscilloscope and GPS setup and the radios will be hearing to receive this signal which will be sent at the same time to all the stations. Each station oscilloscope will pick up the signal and measure the arrival time of the signal and then we know the time difference of arrival. Therefore I need GPS to synchronize the timing of the stations. DOES CONNECTING GPS TO EXTERNAL TRIGGER AS REFERENCE AT EACH STATION SYNCHRONIZE THE STATIONS?
I would go an entirely different direction. Without going into details, let's just say that I have some background in doing this type of work (if you want my CV I can give it).
Figure out how to tie a GPS module to a microcontroller with a high precision clock and some sort of timer capture peripheral. I personally use a GPS module with a 1PPS output and NMEA outputs. The NMEA will tell you which second you're in, the 1PPS will tell you alignment.
I'm most familiar with the microchip PIC controllers. As a specific example, the PIC18f26K22 with a 16Mhz clock will run at 64Mhz internally. The counters should be able to increment at this rate or at almost this rate.
Because you're measuring difference of arrival, you can take some shortcuts. You really don't care if you're clock is exactly on UTC time to the microsecond. What you do care is that both clocks are running on UTC time with exactly the same offset. As a result, I'd do the following:
1) Set up a timer to freerun at either the maximum achievable rate, or a slightly slower rate if the higher rate is too fast for whatever reason.
2) Set up a normal/low priority interrupt to capture timer overflows and increment a counter so you effectively expand the 16 bit timer to a much higher value.
3) Use one serial port hooked to the NMEA output of the GPS, a second to a usb->serial chip to a PC.
4) In the main loop of the program, receive the NMEA data and parse it for the hours minutes seconds. store this in a temporary global variable and set a flag that this has been updated.. This is non-critical timing wise so the main loop is ok for this.
5) Set up a non-maskable interrupt which is triggered by the leading edge of the 1PPS signal. In this interrupt routine, capture the timer value (including the number of overflows), paying attention to potential overflows occuring while in the interrupt routine itself, and storing it into another temporary global variable. Also, copy the nmea time value which was captured in #4 into a second temporary value, clearing the flag mentioned in #4 and setting another one. What you're doing here is storing the H:M:S of the pulse along with the internal timer value into a variable for the main program to use.
6) Also in the main loop of a program, once you see the data appear from the NMI (#5), output this data to the serial port toward the pc. Be as compact as possible. This will be logged by the PC using a standard serial program. The idea is that you'll get an output which tells you the timer value (including the overflow count).
7) Hook your signal to a CCP peripheral. the CCP peripheral will automatically capture the timer value when the signal changes. Set an interrupt on CCP capture events, and then in that interrupt routine, do the same thing as #5, except capture the value from the CCP, again paying attention to potential rollover events.
Also in the main loop of the program ooutput the captured data from #7.
If you get this all correct, what you will effectively end up with is a serial output stream with events 'timestamped' using the 64Mhz oscillator clock (which should be a XTAL). You'll have 1PPS pulse events and also signal events. The 1PPS events will occur exactly once a second (assuming you have a good quality GPS with a good quality 1PPS signal), so you can use the difference between them as a measurement of exactly what frequency the clock is running at in the microcontroller. For example, if you find the counts for the 1PPS signal are exactly 64,000,000 counts apart, then you can assume there's 64,000,000 counts per second, and use that as a divisor in math related to your actual signal reception times.
The above description is based on a specific microcontroller I'm familiar with. I will point you toward another resource I've recently become aware of and that's the micropython project. See
https://micropython.org/store/#/store for the boards themselves. There's also docs on this site. It appears this MIGHT work for you as well - you'd do a similar procedure, but the code would be in python - although I'm not sure the timer resolution will be high enough for you. Other controllers may work as well.
Home
Help
Search
Login
Register
