Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers
From: Hal Murray david-tay...@blueyonder.co.uk said: Perhaps because NTP sees the offset in both send and receive packets and therefore, like any other network delay, it is subtracted out. The description of the change was to remove a delay on the receive side. There was no mention of a change on the send side. So I was expecting a change in the symmetry. (I don't know if it would make things better or worse, but something should change.) == Yes, I see what you mean. I will be updating the report in the next few days so we can see what the change is. At the moment, it seems that the mean offset has changed from +0.044 ms to -0.037 ms. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Greenwich Timekeeping
I wish it was coming to Canada. But according to http://www.sourcewire.com/news/85588/ships-clocks-stars-exhibition-in-greenwich-ends-sunday-january-4#.VRN-O_nF-uM, it is heading to two sites in the USA (Folger Shakespeare Library in Washington DC and Mystic Seaport Museum in Connecticut) plus the Australian National Maritime Museum. Perhaps a trip to Conecticut is in order this fall ... - Dave On Wed, Mar 25, 2015 at 7:39 PM, Tom Harris celephi...@gmail.com wrote: The public exhibition for this conference Ships, Clocks and Stars: The Quest for Longitude is apparently coming to the colonies (Canada Australia) this year, so us colonials might get a chance to feast on the Harrison timepieces in all their glory. True clock p**n. Tom Harris celephi...@gmail.com On 26 March 2015 at 03:27, Tom Van Baak t...@leapsecond.com wrote: For those of you near London with an interest in Greenwich, Harrison, and pendulum clocks there's an event on April 18 that might be worth your time. Harrison Decoded: Towards a Perfect Pendulum Clock http://www.rmg.co.uk/whats-on/events/harrison-decoded http://www.rmg.co.uk/sites/default/files/harrison_decoded_draft_programme_250215-3.pdf /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] Need advice for multilateration setup
I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. The idea is to use a transmitter in the rocket and have 4 or more ground stations about a mile apart each receive the signal. Multilateration based on TDOA (time difference of arrival) measurements would then be used to determine x, y, z, and t. With at least 4 ground stations, you don't need to know the time the pulse was transmitted. The main problem I'm running into is that most of the algorithms I've come across are very sensitive to the expected uncertainty in the time measurements. I had thought 100 ns of timing accuracy in the received signals would be good enough but I think I need to get down less than 40 ns to keep the algorithms from blowing up. My desired position accuracy is around 100 ft up to a range of 100k ft. There were two different methods I thought of. The first method would transmit a pulse from the rocket and then use a counter or TDC on the ground to measure the time difference between a GPS PPS and the pulse arrival. This is the most straightforward method but I'm worried about the timing accuracy of the pulse measurement. I should be able to find a timing GPS that has a PPS output with about +/- 30-40 ns of jitter (2 sigma) so that portion is in the ballpark. There also seem to be TDCs that have accuracy and resolution in the tens of picosecond range but they also have a maximum interval in the millisecond range. I'm not sure I can ensure the pulse sent from the rocket will be within a few miilliseconds of the 1 PPS value on the ground. I will have onboard GPS before launch so in theory I could initialize a counter to align the transmit pulse within a millisecond or so to the onboard PPS. But, once GPS is lost on ascent, unless I put an OCXO onboard that pulse may drift too far away (due to temperature, acceleration, etc.) for the TDC on the ground to pick it up. Plus an OCXO will add weight and require extra power for the heater. Another idea would be to send pulses at a very fast rate, say 1 kHz to stay within the TDC window. But then I need to worry about what happens if the pulses get too close to the edge of the TDC window. One other variable is the delay through the RF chain on the receive end but I figure I could calibrate that out. The other idea, and I'm not sure exactly how to implement it, would be to transmit a continuous tone (1 kHz for example) and perform some kind of phase measurement at each ground station against a reference. I could use a GPSDO to divide down the 10 MHz to 1 kHz to compare with the received signal but how can I assure the divided down 1 kHz clocks are synchronized between ground stations? Are the 10 MHz outputs from GPSDOs necessarily aligned to each other? I let two Thunderbolts sit for a couple of hours and the 10 MHz outputs seemed to stabilize with an offset of about 1/4 of a cycle, too much for this application. Another related idea would be to use the 10 MHz output to clock an ADC and then sample several thousand points using curve fitting, interpolation, and averaging to get a more accurate zero crossing than you could get based on the sample rate alone. Adding a TDC would allow the use of RIS (random interleaved sampling) for repetitive signals which could generate an effective sample rate of 1 GS/s. Does anybody have advice or practical experience on which method would work better? Thanks, -Bob ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Need advice for multilateration setup
Thanks for the suggestion. Does the DSSS make it easier to correlate between ground stations? I'm not sure how to handle the phase offset on the 10 MHz ref clocks. -Bob On Mar 26, 2015, at 07:25, Attila Kinali att...@kinali.ch wrote: On Wed, 25 Mar 2015 21:27:35 -0500 Robert Watzlavick roc...@watzlavick.com wrote: I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. The gods have apporved of your request. You may speak now. ;-) I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. Given you can synchronize the clocks of the ground stations well enough, then the rest is easy. Then you can get away with having a simple signal generator that only needs an XO. Or you can go for a TCXO to make your signal processing life easier. What you need to do, is actually the same as GPS does: Create a direct spread spectrum signal and track it on all ground stations. The DSSS has the advantage over the single pulse, that it's more resilient against noise and interference. The disadvantage is, that you have to have more complicated hardware. One viable way would be, that you have precisly synchronized sampling systems (e.g. SDR's like the bladeRF which can take an external clock) and then feed the data to a PC where you do the heavy lifting. Then you don't need to build custom hardware at least. Also, if the precision by the DSSS signal is not good enough, you can apply various tricks from the GPS world, like carrier phase tracking, etc. HTH Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Comparing the BeagleBone Black Raspberry Pi asNTP servers
On Thu, Mar 26, 2015 at 4:10 AM, David J Taylor david-tay...@blueyonder.co.uk wrote: Yes, I see what you mean. I haven't parsed the driver but asymmetry inverts the sign of the offset as viewed from each end (when each end is S1) so it's usually obvious. I'm not seeing it. I've always used smsc95xx.turbo_mode=N so I don't have a ready source to compare. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] serial parsing program
Python has a nice library struct that can take a binary buffer of just about anything, integers, strings, etc, with any alignment or byte ordering and parse it to a list of values. I've never had the need to use anything else. Perl probably has the same as well. Tom Harris celephi...@gmail.com On 25 March 2015 at 11:37, Bob Stewart b...@evoria.net wrote: Hi Cash, Have you looked at the sourcecode for the gpsd package? packet.c would probably be your starting point. The gpsd package parses pretty much every gps receiver. I'm not sure if this is what you're looking for, or if you specifically want something high-level. Bob From: Cash Olsen radio.kd5...@gmail.com To: time-nuts@febo.com Sent: Tuesday, March 24, 2015 5:22 PM Subject: [time-nuts] serial parsing program I'd like to find a program that has a very flexible serial input and can be easily setup to parse a binary sentence. Specifically, U-Blox timing but more general purpose would be nice for future projects. Has to be able to handle 1, 2, and 4 byte fields, and checksums would be nice also. Should run on Windows for the immediate project but Linux for next projects. -- S. Cash Olsen KD5SSJ ARRL Technical Specialist ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Need advice for multilateration setup
On Wed, 25 Mar 2015 21:27:35 -0500 Robert Watzlavick roc...@watzlavick.com wrote: I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. The gods have apporved of your request. You may speak now. ;-) I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. Given you can synchronize the clocks of the ground stations well enough, then the rest is easy. Then you can get away with having a simple signal generator that only needs an XO. Or you can go for a TCXO to make your signal processing life easier. What you need to do, is actually the same as GPS does: Create a direct spread spectrum signal and track it on all ground stations. The DSSS has the advantage over the single pulse, that it's more resilient against noise and interference. The disadvantage is, that you have to have more complicated hardware. One viable way would be, that you have precisly synchronized sampling systems (e.g. SDR's like the bladeRF which can take an external clock) and then feed the data to a PC where you do the heavy lifting. Then you don't need to build custom hardware at least. Also, if the precision by the DSSS signal is not good enough, you can apply various tricks from the GPS world, like carrier phase tracking, etc. HTH Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Need advice for multilateration setup
What's your budget? Put a white-rabbit switch (3.5keur) in the middle, and install a mile of single-mode fiber to each rx-station. Then use TDC or FDEL SPEC-cards (1.5keur each) at the RX-stations to time-stamp the incoming pulse. 1 ns systematic and 50 ps RMS random error should be doable. The systematic constant error in time-stamp for each rx-station can maybe be calibrated out in the TDOA-algorithm? The FDEL-card can time-stamp up to 100 kEdges/s (that results in a ca 4 Mb/s datastream). Anders On Thu, Mar 26, 2015 at 4:27 AM, Robert Watzlavick roc...@watzlavick.com wrote: I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. The idea is to use a transmitter in the rocket and have 4 or more ground stations about a mile apart each receive the signal. Multilateration based on TDOA (time difference of arrival) measurements would then be used to determine x, y, z, and t. With at least 4 ground stations, you don't need to know the time the pulse was transmitted. The main problem I'm running into is that most of the algorithms I've come across are very sensitive to the expected uncertainty in the time measurements. I had thought 100 ns of timing accuracy in the received signals would be good enough but I think I need to get down less than 40 ns to keep the algorithms from blowing up. My desired position accuracy is around 100 ft up to a range of 100k ft. There were two different methods I thought of. The first method would transmit a pulse from the rocket and then use a counter or TDC on the ground to measure the time difference between a GPS PPS and the pulse arrival. This is the most straightforward method but I'm worried about the timing accuracy of the pulse measurement. I should be able to find a timing GPS that has a PPS output with about +/- 30-40 ns of jitter (2 sigma) so that portion is in the ballpark. There also seem to be TDCs that have accuracy and resolution in the tens of picosecond range but they also have a maximum interval in the millisecond range. I'm not sure I can ensure the pulse sent from the rocket will be within a few miilliseconds of the 1 PPS value on the ground. I will have onboard GPS before launch so in theory I could initialize a counter to align the transmit pulse within a millisecond or so to the onboard PPS. But, once GPS is lost on ascent, unless I put an OCXO onboard that pulse may drift too far away (due to temperature, acceleration, etc.) for the TDC on the ground to pick it up. Plus an OCXO will add weight and require extra power for the heater. Another idea would be to send pulses at a very fast rate, say 1 kHz to stay within the TDC window. But then I need to worry about what happens if the pulses get too close to the edge of the TDC window. One other variable is the delay through the RF chain on the receive end but I figure I could calibrate that out. The other idea, and I'm not sure exactly how to implement it, would be to transmit a continuous tone (1 kHz for example) and perform some kind of phase measurement at each ground station against a reference. I could use a GPSDO to divide down the 10 MHz to 1 kHz to compare with the received signal but how can I assure the divided down 1 kHz clocks are synchronized between ground stations? Are the 10 MHz outputs from GPSDOs necessarily aligned to each other? I let two Thunderbolts sit for a couple of hours and the 10 MHz outputs seemed to stabilize with an offset of about 1/4 of a cycle, too much for this application. Another related idea would be to use the 10 MHz output to clock an ADC and then sample several thousand points using curve fitting, interpolation, and averaging to get a more accurate zero crossing than you could get based on the sample rate alone. Adding a TDC would allow the use of RIS (random interleaved sampling) for repetitive signals which could generate an effective sample rate of 1 GS/s. Does anybody have advice or practical experience on which method would work better? Thanks, -Bob ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/ mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Need advice for multilateration setup
Budget is a concern but not an overriding concern. I'd like to keep the whole system around $1k. I was planning on making it as portable as possible with each ground station being self contained and sending their data to the launch site over a serial RF modem at 9600 baud. I agree though - fiber connections would make it a lot easier. -Bob On Mar 26, 2015, at 08:41, Anders Wallin anders.e.e.wal...@gmail.com wrote: What's your budget? Put a white-rabbit switch (3.5keur) in the middle, and install a mile of single-mode fiber to each rx-station. Then use TDC or FDEL SPEC-cards (1.5keur each) at the RX-stations to time-stamp the incoming pulse. 1 ns systematic and 50 ps RMS random error should be doable. The systematic constant error in time-stamp for each rx-station can maybe be calibrated out in the TDOA-algorithm? The FDEL-card can time-stamp up to 100 kEdges/s (that results in a ca 4 Mb/s datastream). Anders On Thu, Mar 26, 2015 at 4:27 AM, Robert Watzlavick roc...@watzlavick.com wrote: I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. The idea is to use a transmitter in the rocket and have 4 or more ground stations about a mile apart each receive the signal. Multilateration based on TDOA (time difference of arrival) measurements would then be used to determine x, y, z, and t. With at least 4 ground stations, you don't need to know the time the pulse was transmitted. The main problem I'm running into is that most of the algorithms I've come across are very sensitive to the expected uncertainty in the time measurements. I had thought 100 ns of timing accuracy in the received signals would be good enough but I think I need to get down less than 40 ns to keep the algorithms from blowing up. My desired position accuracy is around 100 ft up to a range of 100k ft. There were two different methods I thought of. The first method would transmit a pulse from the rocket and then use a counter or TDC on the ground to measure the time difference between a GPS PPS and the pulse arrival. This is the most straightforward method but I'm worried about the timing accuracy of the pulse measurement. I should be able to find a timing GPS that has a PPS output with about +/- 30-40 ns of jitter (2 sigma) so that portion is in the ballpark. There also seem to be TDCs that have accuracy and resolution in the tens of picosecond range but they also have a maximum interval in the millisecond range. I'm not sure I can ensure the pulse sent from the rocket will be within a few miilliseconds of the 1 PPS value on the ground. I will have onboard GPS before launch so in theory I could initialize a counter to align the transmit pulse within a millisecond or so to the onboard PPS. But, once GPS is lost on ascent, unless I put an OCXO onboard that pulse may drift too far away (due to temperature, acceleration, etc.) for the TDC on the ground to pick it up. Plus an OCXO will add weight and require extra power for the heater. Another idea would be to send pulses at a very fast rate, say 1 kHz to stay within the TDC window. But then I need to worry about what happens if the pulses get too close to the edge of the TDC window. One other variable is the delay through the RF chain on the receive end but I figure I could calibrate that out. The other idea, and I'm not sure exactly how to implement it, would be to transmit a continuous tone (1 kHz for example) and perform some kind of phase measurement at each ground station against a reference. I could use a GPSDO to divide down the 10 MHz to 1 kHz to compare with the received signal but how can I assure the divided down 1 kHz clocks are synchronized between ground stations? Are the 10 MHz outputs from GPSDOs necessarily aligned to each other? I let two Thunderbolts sit for a couple of hours and the 10 MHz outputs seemed to stabilize with an offset of about 1/4 of a cycle, too much for this application. Another related idea would be to use the 10 MHz output to clock an ADC and then sample several thousand points using curve fitting, interpolation, and averaging to get a more accurate zero crossing than you could get based on the sample rate alone. Adding a TDC would allow the use of RIS (random interleaved sampling) for repetitive signals which could generate an effective sample rate of 1 GS/s. Does anybody have advice or practical experience on which method would work better? Thanks, -Bob ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/ mailman/listinfo/time-nuts and follow the
Re: [time-nuts] Need advice for multilateration setup
Hi Bob: There are many ways of doing this. To test artillery shells they have a GPS front end in the shell and transmit the IF. A receiver at the gun is locked to the satellites prior to firing. You would want one of the 10 Hz update rage GPS receivers for this. Another method is to transmit a pulse of RF from the ground. When the rocket receives the pulse it sends out a pulse. When the receiver sees that pulse it makes another pulse. The repetition rate depends on the range (and fixed delays in the circuits). Doppler was used to determine the orbit of Sputnik. (Note: the transmitter was near a WWV frequency so the beat note was the Doppler.) If the rocket has a stable CW transmitter and you have a few receivers in known locations on the ground and record the Doppler for each receiver you can work out the path. A blinking light on the rocket and video cameras on the ground. Hollywood uses reflective dots on an actor's face and body which are watched with video cameras in a motion capture setup. A 3-axis accelerometer in the rocket and 3 channels of telemetry. Etc. Mail_Attachment -- Have Fun, Brooke Clarke http://www.PRC68.com http://www.end2partygovernment.com/2012Issues.html http://www.prc68.com/I/DietNutrition.html Robert Watzlavick wrote: I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. The idea is to use a transmitter in the rocket and have 4 or more ground stations about a mile apart each receive the signal. Multilateration based on TDOA (time difference of arrival) measurements would then be used to determine x, y, z, and t. With at least 4 ground stations, you don't need to know the time the pulse was transmitted. The main problem I'm running into is that most of the algorithms I've come across are very sensitive to the expected uncertainty in the time measurements. I had thought 100 ns of timing accuracy in the received signals would be good enough but I think I need to get down less than 40 ns to keep the algorithms from blowing up. My desired position accuracy is around 100 ft up to a range of 100k ft. There were two different methods I thought of. The first method would transmit a pulse from the rocket and then use a counter or TDC on the ground to measure the time difference between a GPS PPS and the pulse arrival. This is the most straightforward method but I'm worried about the timing accuracy of the pulse measurement. I should be able to find a timing GPS that has a PPS output with about +/- 30-40 ns of jitter (2 sigma) so that portion is in the ballpark. There also seem to be TDCs that have accuracy and resolution in the tens of picosecond range but they also have a maximum interval in the millisecond range. I'm not sure I can ensure the pulse sent from the rocket will be within a few miilliseconds of the 1 PPS value on the ground. I will have onboard GPS before launch so in theory I could initialize a counter to align the transmit pulse within a millisecond or so to the onboard PPS. But, once GPS is lost on ascent, unless I put an OCXO onboard that pulse may drift too far away (due to temperature, acceleration, etc.) for the TDC on the ground to pick it up. Plus an OCXO will add weight and require extra power for the heater. Another idea would be to send pulses at a very fast rate, say 1 kHz to stay within the TDC window. But then I need to worry about what happens if the pulses get too close to the edge of the TDC window. One other variable is the delay through the RF chain on the receive end but I figure I could calibrate that out. The other idea, and I'm not sure exactly how to implement it, would be to transmit a continuous tone (1 kHz for example) and perform some kind of phase measurement at each ground station against a reference. I could use a GPSDO to divide down the 10 MHz to 1 kHz to compare with the received signal but how can I assure the divided down 1 kHz clocks are synchronized between ground stations? Are the 10 MHz outputs from GPSDOs necessarily aligned to each other? I let two Thunderbolts sit for a couple of hours and the 10 MHz outputs seemed to stabilize with an offset of about 1/4 of a cycle, too much for this application. Another related idea would be to use the 10 MHz output to clock an ADC and then sample several thousand points using curve fitting, interpolation, and averaging to get a more accurate zero crossing than you could get based on the sample rate alone. Adding a TDC would allow the use of RIS (random interleaved sampling) for repetitive signals which could generate an effective sample rate of 1 GS/s. Does anybody have advice or practical experience on which
Re: [time-nuts] Need advice for multilateration setup
I want to develop a tracking system for an amateur rocket ... Do you need the position in real time, or just after the rocket returns so you can find it? I had thought 100 ns of timing accuracy in the received signals would be good enough but I think I need to get down less than 40 ns to keep the algorithms from blowing up 40 ns is 25 MHz. It shouldn't be hard to find a uP with counter/timer that runs faster than that. I think you can get away without fancy oscillators. I'm assuming you can use GPS to get the the initial position of the rocket and the receiving stations. I'm also assuming that the rocket can start transmitting a few seconds/minutes before launch to calibrate things. Suppose the receiver puts out a pulse. Feed that to a uP with a counter/timer module that gives you a time stamp. Feed all the time-stamps to a central PC that will sort things out. If the pulses are far enough apart it will be easy to figure out which time-stamps go together. [1] The clocks used to make the time stamps don't need to agree on a base time. You can sort that out at the PC with data from before the rocket leaves the ground. How accurate do the oscillators need to be? If you can listen for a while before launch you can calibrate the individual oscillators. So the question becomes how long does it take to do the calibration? How stable do the oscillators need to be? How long does the flight last? The calibration error and noise/wander from calibration is part of your error budget. If a flight lasts 100 seconds (handy number for back of napkin calculations) and the calibration/drift is off by 1E9, that's 100 ns. So you will need an oscillator that is stable to better than 1E10 over 100 seconds. Ballpark/handwave. You can also calibrate the receiver oscillators again after the rocket lands. Does the transmitter survive the landing? Does the antenna survive well enough? measurements would then be used to determine x, y, z, and t Is Z interesting? I'm assuming you are firing rockets in flat desert terrain. All the receivers will be in the same plane. I'll bet the math has troubles if you try to calculate the Z when the rocket is near the plane of the receivers. Have you looked into a different set of algorithms that assume the rocket is on the ground? - 1) If you need more data, you can still sort things out if the transmitter sends pulses with non-uniform spacing. I think there is a whole branch of math for that problem but I don't know the name/term. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Need advice for multilateration setup
Sounds over complicated. Why not use an onboard triple-axis accelerometer? A few mm of real-estate, milliamp consumption, up to 16g, 600+ samples a sec. The code is probably already available. Le 26 mars 2015 à 03:27, Robert Watzlavick roc...@watzlavick.com a écrit : I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. The idea is to use a transmitter in the rocket and have 4 or more ground stations about a mile apart each receive the signal. Multilateration based on TDOA (time difference of arrival) measurements would then be used to determine x, y, z, and t. With at least 4 ground stations, you don't need to know the time the pulse was transmitted. The main problem I'm running into is that most of the algorithms I've come across are very sensitive to the expected uncertainty in the time measurements. I had thought 100 ns of timing accuracy in the received signals would be good enough but I think I need to get down less than 40 ns to keep the algorithms from blowing up. My desired position accuracy is around 100 ft up to a range of 100k ft. There were two different methods I thought of. The first method would transmit a pulse from the rocket and then use a counter or TDC on the ground to measure the time difference between a GPS PPS and the pulse arrival. This is the most straightforward method but I'm worried about the timing accuracy of the pulse measurement. I should be able to find a timing GPS that has a PPS output with about +/- 30-40 ns of jitter (2 sigma) so that portion is in the ballpark. There also seem to be TDCs that have accuracy and resolution in the tens of picosecond range but they also have a maximum interval in the millisecond range. I'm not sure I can ensure the pulse sent from the rocket will be within a few miilliseconds of the 1 PPS value on the ground. I will have onboard GPS before launch so in theory I could initialize a counter to align the transmit pulse within a millisecond or so to the onboard PPS. But, once GPS is lost on ascent, unless I put an OCXO onboard that pulse may drift t oo far away (due to temperature, acceleration, etc.) for the TDC on the ground to pick it up. Plus an OCXO will add weight and require extra power for the heater. Another idea would be to send pulses at a very fast rate, say 1 kHz to stay within the TDC window. But then I need to worry about what happens if the pulses get too close to the edge of the TDC window. One other variable is the delay through the RF chain on the receive end but I figure I could calibrate that out. The other idea, and I'm not sure exactly how to implement it, would be to transmit a continuous tone (1 kHz for example) and perform some kind of phase measurement at each ground station against a reference. I could use a GPSDO to divide down the 10 MHz to 1 kHz to compare with the received signal but how can I assure the divided down 1 kHz clocks are synchronized between ground stations? Are the 10 MHz outputs from GPSDOs necessarily aligned to each other? I let two Thunderbolts sit for a couple of hours and the 10 MHz outputs seemed to stabilize with an offset of about 1/4 of a cycle, too much for this application. Another related idea would be to use the 10 MHz output to clock an ADC and then sample several thousand points using curve fitting, interpolation, and averaging to get a more accurate zero crossing than you could get based on the sample rate alone. Adding a TDC would allow the use of RIS (random interleaved sampling) for repetitive signals which could generate an effective sample rate of 1 GS/s. Does anybody have advice or practical experience on which method would work better? Thanks, -Bob ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité. Benjimin Franklin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] Need advice for multilateration setup
On 3/25/15 7:27 PM, Robert Watzlavick wrote: I'm working on a project that I could use some advice on and also might be of interest to the list. If it's not appropriate for the list, my apologies. I want to develop a tracking system for an amateur rocket that can allow me to track the rocket even if onboard GPS is lost (as is typical during ascent and sometimes during descent) or if telemetry is lost. The idea is to use a transmitter in the rocket and have 4 or more ground stations about a mile apart each receive the signal. Multilateration based on TDOA (time difference of arrival) measurements would then be used to determine x, y, z, and t. With at least 4 ground stations, you don't need to know the time the pulse was transmitted. The main problem I'm running into is that most of the algorithms I've come across are very sensitive to the expected uncertainty in the time measurements. I had thought 100 ns of timing accuracy in the received signals would be good enough but I think I need to get down less than 40 ns to keep the algorithms from blowing up. My desired position accuracy is around 100 ft up to a range of 100k ft. The key is that you don't need *real time* position.. a few seconds or minutes delay is probably ok, right? So transmit a PN code modulated onto a carrier from your rocket at some convenient frequency that's legal. Drive the PN shift register from your carrier, divided down, so there's an integer number of carrier cycles per chip. Receive that signal and digitize it on the ground at a suitably high rate. Post process the sampled data to recover the timing of the PN (and carrier). To compensate for the receiver variability, simultaneously transmit a signal with a different PN code, at the same frequency (roughly) as the rocket's transmitter.. The receiver will receive both, but the signal from your ground reference transmitter isn't moving, so you can use the non-rocket signal as a calibration reference. What's your budget? The transmitter can be very cheap. The receiver is going to be the pricey part, depending on how it's implemented. A sort of brute force approach would be to use a USRP and a portable PC at each receiver site. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
