Re: [time-nuts] GPS 18 behavior
Thanks Jim Was not aware that 10 Ghz signals could penetrate so deeply. I work for a enterprise wifi company on the RF side and one of our key challenges is signal attenuation/distortion by building materials Any pointers to papers on this? I did know that /tvb was using seismic sensors but moles are small you would need a high resolution seismic grid to accurately place them Woodchucks are much larger and they also tunnel and undermine things so easier to find with seismic sensor Sent from my iPhone On Jul 23, 2013, at 12:03 AM, Jim Lux jim...@earthlink.net wrote: On 7/22/13 10:39 AM, Scott McGrath wrote: Moles are a bit small it would probably work better for woodchucks. who are in the process of undermining all lawns in neighborhood now. In a more serious vein most ground penetrating radar is low frequency and I was not aware that THz waves could penetrate ground more than a few CM I believe tvb was using seismic sensors. low microwave (10 GHz) penetrates just fine to tens of meters. I wouldn't want to run a comm link at any sort of data rate, but for 1 Hz bandwidth and coherent detection, it works just fine. ___ 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] GPS 18 behavior
On 7/23/13 4:51 AM, Scott McGrath wrote: Thanks Jim Was not aware that 10 Ghz signals could penetrate so deeply. I work for a enterprise wifi company on the RF side and one of our key challenges is signal attenuation/distortion by building materials Any pointers to papers on this? there's tons of papers (and Master's theses) on propagation of 2.45 and 5.8 GHz signals in buildings. It seems that every grad student goes out and hooks up a VNA to some antennas. As for other frequencies, there's some papers out there on propagation in various building materials and substances. I put a list of some useful references (there's others, at the end of theis email) from a modeling standpoint: Target Propagation Models for the FINDER Radar Authors: Vaughn Cable; Jet Propulsion Laboratory, California Institute of Technology, United States James Lux; Jet Propulsion Laboratory, California Institute of Technology, United States Salman Haque; Jet Propulsion Laboratory, California Institute of Technology, United States Was presented at URSI a couple weeks ago. T he attenuation is quite high compared to free space, but the dominant factor in the propagation is not the resistive losses, but is the multiple changes in dielectric media: lots of reflections, and many scatter energy in directions other than where you want it to go (e.g. sideways). It's like shining a laser pointer into milk. So, I'm not surprised you have trouble with high speed digital comm. There's two things biting you. One is just the signal strength issue: A few dB/meter adds up quick. The other is the delay spread in the path, which will limit your symbol rate, and getting to a more time-nuts-y area. Our models (and measurements) show that in dense rubble with smallish chunks (few cm to tens of cm scale), the delay spread is on the order of 10-20% of the propagation time. On a 10 meter path (about 50 nanoseconds), the delay spread is on the order of 5-10 nanoseconds. Clearly, you're not going be sending 100 megasymbols/second. 802.11 sends 250 ksymbols/second, so it doesn't have a big problem with ISI, but it does get bitten by the frequency selective fading of these paths: and that fading varies dramatically on the scale of a wavelength: move 5-10 cm and a completely different set of OFDM channels are alive. I did know that /tvb was using seismic sensors but moles are small you would need a high resolution seismic grid to accurately place them Actually, you don't need that high resolution to do location. You just need good timing resolution The challenge would be the uncertainty in propagation velocity in the medium. It's like acoustic location of gunshots, which works pretty well in free space, but not so well in an echoey environment. Now if he were looking for diamond toothed rock boring gophers deep in a granite pluton, where the medium is more uniform, it would work better. Here's some possibilities. There's tons of others.. J. A. Boan, “Radio Propagation in Fire Environments”, University of Adelaide, Australia, 2009. C. Dissanayake, M. N. Halgamuge, K. Ramamohanarao, B. Moran, P. Farrell, “The Signal Propagation Effects on IEEE 802.15.4 Radio Link in Fire Environment”, 5th International Conference on Information and Automation for Sustainability, 17-19 December 2010 G. L. Charvat, L. C. Kempel, E. J. Rothwell, C. M. Coleman, E. L. Mokole, “A Through -Dielectric Radar Imaging System”, IEEE Transactions on Antennas and Propagation, Vol. 38, No. 8, August 2010 M. C. Dobson, F. T. Ulaby, M. T. Hallikainen, H. A. El-Rayes, “Microwave Dielectric Behavior of Wet Soil – Part II: Dielectric Mixing Models”, IEEE Transactions on Geoscience and Remote Sensing, Vol. GE-23, No. 1, January 1985 M. T. Hallikainen, F. T. Ulaby, M. C. Dobson, M. A. El-Rayes, L-K Wu, “Microwave Dielectric Behavior of Wet Soil – Part 1: Empirical Models and Experimental Observations”, IEEE Transactions on Geoscience and Remote Sensing, Vol. GE-23, No. 1, January 1985 W. A. Wensink, “Dielectric Properties of Wet Soils in the Frequency Range 1-3000 MHz”, Geophysical Prospecting, Vol. 41, Issue 6, 27 April 2006 ___ 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] GPS 18 behavior
On 23/07/13 05:55, Jim Lux wrote: On 7/21/13 6:42 PM, Chris Albertson wrote: I think the way to keep the sensors in sync is to use the same method they use to keep cell towers in sync. Basically each tower has a GPS receiver and also a good local oscillator. The GPS disciplines the oscillator and the timing is taken from that oscillator, not directly from the GPS. If the GPS signal is blocked the system continues normally however the oscillator may drift without the connection to GPS. Then later when the GPS is available again the oscillator is corrected. The system can run for a few days in holdover with no GPS connection. I think you were talking about a system that switches to a backup 1PPS signal. Today, I have a system with multiple modules physically connected by a cable that need to be sync'd to maybe 1 millisecond. I was thinking about using the 1pps from the GPS as the sync, if it was available all the time, even in GPS denied areas; that would make it always use the same sync from the same device, even if it's not synchronized to some external time scale. Since the GPS receiver doesn't put out the 1pps all the time, I can sync another way, and drive that sync process from the GPS if it's available. The long term system will have multiple modules separated by some distance that need to be synced and frequency disciplined, but they might have GPS, so that could be used to discipline a clock in the usual way. As a practical matter, I'm more a fan of using GPS for knowledge and adjust the output using a DDS rather than steer the oscillator, because that allows a higher Q resonator, but that's a matter of engineering details. There's also the situation where you're totally GPS denied, but that's an even more tricky problem. That is not the way to do it. The GPS should discipline a 10MHz crystal (or whatever) and then you divide that by 10,000,000 to get your 1PPS. Then when the GPS fails there is no interruption, no mode change. Such a system only needs to have access to GPS now and then. So if you have to go under a pile of concrete and loose access to the sky there is no hiccup. This would work for the distributed system too. Your 1E-11 over 10 to 100 seconds would be met even if GPS were out for a few hours. Yes, that would do. It turns out, though, that although you could tolerate a slow drift, assuming you can figure out what it is, it makes life harder if the two modules have drifted 1E-9 relative to each other after 10 minutes. The movie-business have similar problems, so a sync-ones and keep drift low system emerged to make field recordings easier. If it would be tolerable to have a central transmitter, putting a PN code over a voice radio system would suffice to keep the drift fairly well kept together for this form of system. If you choose to do it on the audio channel, then you can use of the shelf radios, and replace those or re-program those as needed. Also, they are dirt cheap nowdays. Cheers, Magnus ___ 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] GPS 18 behavior
For what it's worth, the application is a radar that detects buried victims in disaster rubble, so the data we are collecting is basically heartbeats and breathing. the when was the data taken is a where were we when the data was collected need. The sync requirement comes from being able to find the same heartbeat in multiple data streams. Jim, That's a fascinating application. Ok, one last comment then. As much as GPS is an obvious solution, did you consider the use of multiple homebrew timing pulse pseudolites instead? If one placed a couple of them around the vicinity of the disaster area you could triangulate for your ranging and timing information. Since the transmitters would then be less than 1 km away instead of more than 20,000 km away, you avoid all the limitations of GPS. Moreover, the solution would work if GPS were functional or not, something perhaps important for a disaster situation. Using some clever waveform (like what Loran-C did) you could better penetrate into all sorts of rubble and overcome multi-path at the same time. I'm pretty sure there are a number of papers on local ranging and navigation based on these technique (e.g., UAV, robotics). The advantage is that it's a local solution, it can work indoors, underground, underwater, even on the moon; in general, it doesn't rely on a functioning GPS constellation with its inherently weak or jammable signals. Of course all this from the guy who once tried to use seismic sensors and GPSDO to triangulate moles in his backyard... /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.
Re: [time-nuts] GPS 18 behavior
On 7/22/13 6:30 AM, Tom Van Baak wrote: For what it's worth, the application is a radar that detects buried victims in disaster rubble, so the data we are collecting is basically heartbeats and breathing. the when was the data taken is a where were we when the data was collected need. The sync requirement comes from being able to find the same heartbeat in multiple data streams. Jim, That's a fascinating application. Ok, one last comment then. As much as GPS is an obvious solution, did you consider the use of multiple homebrew timing pulse pseudolites instead? If one placed a couple of them around the vicinity of the disaster area you could triangulate for your ranging and timing information. Since the transmitters would then be less than 1 km away instead of more than 20,000 km away, you avoid all the limitations of GPS. Moreover, the solution would work if GPS were functional or not, something perhaps important for a disaster situation. Using some clever waveform (like what Loran-C did) you could better penetrate into all sorts of rubble and overcome multi-path at the same time. Great minds think along similar paths.. Yes, in the long term plan, that's essentially what we'll do: multilateration among the multiple units. But for the mean time, we need to mark the locations with GPS derived coordinates. The search and rescue folks currently use Garmin handhelds, so they're aware of where it works and where it doesn't. I'm pretty sure there are a number of papers on local ranging and navigation based on these technique (e.g., UAV, robotics). The advantage is that it's a local solution, it can work indoors, underground, underwater, even on the moon; in general, it doesn't rely on a functioning GPS constellation with its inherently weak or jammable signals. Interestingly, there's a whole lot of laboratory demos of various and sundry techniques, but the GPS-denied time/frequency/position problem is very non-trivial. For instance propagation through rubble is a fairly harsh multipath/scattering environment. The delay spread is about 10% of the distance traveled, and knowing what the average epsilon is, so you can turn propagation time into distance, is not easy to determine. Anyone who claims that they can do centimeter level position determination at a range of 10 meters in rubble (or can do microwave imaging/SAR/etc, which implies the same thing) is, I think, blowing smoke, unless they have a VERY sophisticated measurement setup and a huge amount of computational horsepower to solve the inversion problem. (essentially, look at the first returns in time, use that to solve for the EM parameters of the first layer; then move the analysis front forward a step, do it again, etc., etc.,etc.) Fortunately, unlike seismic data processing, for the most part the medium is linear, albeit somewhat anisotropic. Of course all this from the guy who once tried to use seismic sensors and GPSDO to triangulate moles in his backyard... A valiant effort I'm sure.. And, I'll bet you learned all about the propagation anisotropy of soilgrin But yes, in general there are general strategies to do multilateration (and multiangulation using direction of arrival as well) among multiple nodes that are cooperating. Taking a general strategy to something that actually works in the field, preferably using off the shelf hardware modules of some sort, is a bit of a chore. ___ 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] GPS 18 behavior
Have you considered WWVB? Works fine within structures. Even though the carrier today is phase modulated one can probably glean 1 ms accuracy from it or the data transmitted. Regards Brian On 7/23/2013 14:05, Magnus Danielson wrote: On 23/07/13 05:55, Jim Lux wrote: On 7/21/13 6:42 PM, Chris Albertson wrote: I think the way to keep the sensors in sync is to use the same method they use to keep cell towers in sync. Basically each tower has a GPS receiver and also a good local oscillator. The GPS disciplines the oscillator and the timing is taken from that oscillator, not directly from the GPS. If the GPS signal is blocked the system continues normally however the oscillator may drift without the connection to GPS. Then later when the GPS is available again the oscillator is corrected. The system can run for a few days in holdover with no GPS connection. I think you were talking about a system that switches to a backup 1PPS signal. Today, I have a system with multiple modules physically connected by a cable that need to be sync'd to maybe 1 millisecond. I was thinking about using the 1pps from the GPS as the sync, if it was available all the time, even in GPS denied areas; that would make it always use the same sync from the same device, even if it's not synchronized to some external time scale. Since the GPS receiver doesn't put out the 1pps all the time, I can sync another way, and drive that sync process from the GPS if it's available. The long term system will have multiple modules separated by some distance that need to be synced and frequency disciplined, but they might have GPS, so that could be used to discipline a clock in the usual way. As a practical matter, I'm more a fan of using GPS for knowledge and adjust the output using a DDS rather than steer the oscillator, because that allows a higher Q resonator, but that's a matter of engineering details. There's also the situation where you're totally GPS denied, but that's an even more tricky problem. That is not the way to do it. The GPS should discipline a 10MHz crystal (or whatever) and then you divide that by 10,000,000 to get your 1PPS. Then when the GPS fails there is no interruption, no mode change. Such a system only needs to have access to GPS now and then. So if you have to go under a pile of concrete and loose access to the sky there is no hiccup. This would work for the distributed system too. Your 1E-11 over 10 to 100 seconds would be met even if GPS were out for a few hours. Yes, that would do. It turns out, though, that although you could tolerate a slow drift, assuming you can figure out what it is, it makes life harder if the two modules have drifted 1E-9 relative to each other after 10 minutes. The movie-business have similar problems, so a sync-ones and keep drift low system emerged to make field recordings easier. If it would be tolerable to have a central transmitter, putting a PN code over a voice radio system would suffice to keep the drift fairly well kept together for this form of system. If you choose to do it on the audio channel, then you can use of the shelf radios, and replace those or re-program those as needed. Also, they are dirt cheap nowdays. Cheers, Magnus ___ 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. - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2242 / Virus Database: 3204/6013 - Release Date: 07/23/13 - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2242 / Virus Database: 3204/6013 - Release Date: 07/23/13 ___ 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] GPS 18 behavior
Of course all this from the guy who once tried to use seismic sensors and GPSDO to triangulate moles in his backyard... I don't recall seeing that on leapsecond.com... Sounds like something that could become an obsession that rivaled clocks in cost. I'm picturing Bill Murray and a Caddyshack sequel on steroids... Brent ___ 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] GPS 18 behavior
Moles are a bit small it would probably work better for woodchucks. who are in the process of undermining all lawns in neighborhood now. In a more serious vein most ground penetrating radar is low frequency and I was not aware that THz waves could penetrate ground more than a few CM Scott Sent from my iPhone On Jul 22, 2013, at 9:46 AM, brent evers brent.ev...@gmail.com wrote: Of course all this from the guy who once tried to use seismic sensors and GPSDO to triangulate moles in his backyard... I don't recall seeing that on leapsecond.com... Sounds like something that could become an obsession that rivaled clocks in cost. I'm picturing Bill Murray and a Caddyshack sequel on steroids... Brent ___ 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] GPS 18 behavior
I think the way to keep the sensors in sync is to use the same method they use to keep cell towers in sync. Basically each tower has a GPS receiver and also a good local oscillator. The GPS disciplines the oscillator and the timing is taken from that oscillator, not directly from the GPS. If the GPS signal is blocked the system continues normally however the oscillator may drift without the connection to GPS. Then later when the GPS is available again the oscillator is corrected.The system can run for a few days in holdover with no GPS connection. I think you were talking about a system that switches to a backup 1PPS signal.That is not the way to do it. The GPS should discipline a 10MHz crystal (or whatever) and then you divide that by 10,000,000 to get your 1PPS. Then when the GPS fails there is no interruption, no mode change. Such a system only needs to have access to GPS now and then. So if you have to go under a pile of concrete and loose access to the sky there is no hiccup. This would work for the distributed system too. Your 1E-11 over 10 to 100 seconds would be met even if GPS were out for a few hours. You cn do the same for location data too. When you walk under a concrete roof the GPS goes away. So you use an inertial system. The GPS continuously corrects the inertial nag and if you loose GPS they is some drift but you don't loose position data. All of this can be done in a small hand held battery powered system. On Sun, Jul 21, 2013 at 1:55 PM, Jim Lux jim...@earthlink.net wrote: On 7/21/13 1:35 PM, Tom Van Baak wrote: when I'm in a GPS denied environment, it's not just because we're indoors, it's because we're somewhere that GPS isn't available, so what I'm really doing is providing a sort of flywheel to keep my little modules synced with each other. I don't need super accuracy in an absolute sense: I just need to tag the data all with the same time tag within a few seconds. Jim, If the requirement is just a couple of seconds, did you consider one of the high-accuracy Dallas RTC chips? That might be a simpler solution than a GPS receiver (knowing when and when not to trust its 1PPS, decoding NMEA, trusting NMEA, needing antenna with sky view). We have two requirements.. one is know when the data was collected in an absolute sense: that's a few seconds kind of requirement because we're collecting data for 30 seconds anyway. But we have another requirement to be able to align multiple simultaneous takes within a millisecond or so. For what it's worth, the application is a radar that detects buried victims in disaster rubble, so the data we are collecting is basically heartbeats and breathing. the when was the data taken is a where were we when the data was collected need. The sync requirement comes from being able to find the same heartbeat in multiple data streams. http://www.dhs.gov/st-snapshot-tech-foraging has a picture of the radar and a test site. If the requirement were sub-second, the solution is GPS; if the requirement were minutes, it's TCXO. Sounds like you're in the gray area where GPS is not necessarily the simplest, cheapest, or robust solution. As it happens, we already need to have GPS position of the data take (where possible), so the GPS is there and available (sometimes). It's the what do I do when the GPS isn't there that I'm working through. The other thing about multiple, portable or remote sensors is that in some cases they don't actually need to agree on time or rate internally as long as you can post-process the data and retroactively apply a time and frequency correction to the data they have already collected or are collecting. For example, if you know one is 2.3 seconds ahead and slow by 45 ppm you can still obtain highly accurate time-stamps from it -- the unit itself does not need to be on-time, or on-frequency. Indeed. For this application, knowledge is actually more important for sync. The XO on the board setting the sample rate is good enough that if I just count clocks, and timestamp when I get the sync pulse, I can line things up with a few seconds one way or another.. the data take is 30 or 60 seconds, and even if we're WAY off, it's not going to be a millisecond off from a rate error at the end of 60 seconds. The distributed sensor problem down the road, though, I'm doing coherent microwave demodulation, so that's why I need the 1E-11 over 10-100 seconds. I'm looking for signals at 0.1 to 1 Hz (breathing and heartbeats) and if the transmitter and receiver are off by 1 Hz, then the difference looks just like a heartbeat. To be honest, I'm not sure the distributed sensor (basically a bistatic radar) is doable with totally independent systems. What I might wind up doing is detecting the direct path and the reflected path simultaneously and looking for it that way. It's basically a sort of phased array problem, and if you can somehow manage to get your
Re: [time-nuts] GPS 18 behavior
You might want to look at what these guys have done for 40 years or so. Www.geophysical.com They have the ability to embed GPS coordinates while recording. Sent from my iPhone On Jul 21, 2013, at 4:55 PM, Jim Lux jim...@earthlink.net wrote: On 7/21/13 1:35 PM, Tom Van Baak wrote: when I'm in a GPS denied environment, it's not just because we're indoors, it's because we're somewhere that GPS isn't available, so what I'm really doing is providing a sort of flywheel to keep my little modules synced with each other. I don't need super accuracy in an absolute sense: I just need to tag the data all with the same time tag within a few seconds. Jim, If the requirement is just a couple of seconds, did you consider one of the high-accuracy Dallas RTC chips? That might be a simpler solution than a GPS receiver (knowing when and when not to trust its 1PPS, decoding NMEA, trusting NMEA, needing antenna with sky view). We have two requirements.. one is know when the data was collected in an absolute sense: that's a few seconds kind of requirement because we're collecting data for 30 seconds anyway. But we have another requirement to be able to align multiple simultaneous takes within a millisecond or so. For what it's worth, the application is a radar that detects buried victims in disaster rubble, so the data we are collecting is basically heartbeats and breathing. the when was the data taken is a where were we when the data was collected need. The sync requirement comes from being able to find the same heartbeat in multiple data streams. http://www.dhs.gov/st-snapshot-tech-foraging has a picture of the radar and a test site. If the requirement were sub-second, the solution is GPS; if the requirement were minutes, it's TCXO. Sounds like you're in the gray area where GPS is not necessarily the simplest, cheapest, or robust solution. As it happens, we already need to have GPS position of the data take (where possible), so the GPS is there and available (sometimes). It's the what do I do when the GPS isn't there that I'm working through. The other thing about multiple, portable or remote sensors is that in some cases they don't actually need to agree on time or rate internally as long as you can post-process the data and retroactively apply a time and frequency correction to the data they have already collected or are collecting. For example, if you know one is 2.3 seconds ahead and slow by 45 ppm you can still obtain highly accurate time-stamps from it -- the unit itself does not need to be on-time, or on-frequency. Indeed. For this application, knowledge is actually more important for sync. The XO on the board setting the sample rate is good enough that if I just count clocks, and timestamp when I get the sync pulse, I can line things up with a few seconds one way or another.. the data take is 30 or 60 seconds, and even if we're WAY off, it's not going to be a millisecond off from a rate error at the end of 60 seconds. The distributed sensor problem down the road, though, I'm doing coherent microwave demodulation, so that's why I need the 1E-11 over 10-100 seconds. I'm looking for signals at 0.1 to 1 Hz (breathing and heartbeats) and if the transmitter and receiver are off by 1 Hz, then the difference looks just like a heartbeat. To be honest, I'm not sure the distributed sensor (basically a bistatic radar) is doable with totally independent systems. What I might wind up doing is detecting the direct path and the reflected path simultaneously and looking for it that way. It's basically a sort of phased array problem, and if you can somehow manage to get your phase reference distributed among all the elements with small phase error over the measurement interval, that's a good thing: less post processing, and all that. /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.
Re: [time-nuts] GPS 18 behavior
On 7/21/13 6:42 PM, Chris Albertson wrote: I think the way to keep the sensors in sync is to use the same method they use to keep cell towers in sync. Basically each tower has a GPS receiver and also a good local oscillator. The GPS disciplines the oscillator and the timing is taken from that oscillator, not directly from the GPS. If the GPS signal is blocked the system continues normally however the oscillator may drift without the connection to GPS. Then later when the GPS is available again the oscillator is corrected.The system can run for a few days in holdover with no GPS connection. I think you were talking about a system that switches to a backup 1PPS signal. Today, I have a system with multiple modules physically connected by a cable that need to be sync'd to maybe 1 millisecond. I was thinking about using the 1pps from the GPS as the sync, if it was available all the time, even in GPS denied areas; that would make it always use the same sync from the same device, even if it's not synchronized to some external time scale. Since the GPS receiver doesn't put out the 1pps all the time, I can sync another way, and drive that sync process from the GPS if it's available. The long term system will have multiple modules separated by some distance that need to be synced and frequency disciplined, but they might have GPS, so that could be used to discipline a clock in the usual way. As a practical matter, I'm more a fan of using GPS for knowledge and adjust the output using a DDS rather than steer the oscillator, because that allows a higher Q resonator, but that's a matter of engineering details. There's also the situation where you're totally GPS denied, but that's an even more tricky problem. That is not the way to do it. The GPS should discipline a 10MHz crystal (or whatever) and then you divide that by 10,000,000 to get your 1PPS. Then when the GPS fails there is no interruption, no mode change. Such a system only needs to have access to GPS now and then. So if you have to go under a pile of concrete and loose access to the sky there is no hiccup. This would work for the distributed system too. Your 1E-11 over 10 to 100 seconds would be met even if GPS were out for a few hours. Yes, that would do. It turns out, though, that although you could tolerate a slow drift, assuming you can figure out what it is, it makes life harder if the two modules have drifted 1E-9 relative to each other after 10 minutes. You cn do the same for location data too. When you walk under a concrete roof the GPS goes away. So you use an inertial system. The GPS continuously corrects the inertial nag and if you loose GPS they is some drift but you don't loose position data. Interestingly, there's a lot of people who have tried this, and it doesn't work quite as well as they hope. Basically you're talking a strapdown IMU, and such an IMU on a person doesn't work all that well. Imagine a policeman with a walkie talkie.. the radio gets picked up and used and sees fairly high accelerations over short durations, with high jerk as well. If you were to strap a bunch of accelerometers and gyros to a person's skin (not their clothes, which bounce around and slide) you could do better. I was at a DARPA thingie the other day where there were a bunch of exhibitors with personal tracking systems.. there's a lot of handwaving about whether they can actually reliably achieve, say, 1-2 meter position accuracy. In a tactical environment, 1-2 meters is the difference between life and death (e.g. which side of the wall or street are you on). All of this can be done in a small hand held battery powered system. m.. maybe. how long does the battery lastgrin... You're not going to be running a 10811 Double Oven XO on a couple AAA batteries. The CSAC is 120 mW. A single AAA battery is about 1 Watt hour, for comparison. Yeah, it's doable, but it's non trivial.. ___ 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] GPS 18 behavior
On 7/22/13 5:48 AM, Scott McGrath wrote: You might want to look at what these guys have done for 40 years or so. Www.geophysical.com ground penetrating radar doesn't work very well in the typical disaster rubble enviroment which has uneven surfaces and a lot of random scattering in the medium. It works great dragging it across a smooth field looking for buried pipes, drums of hazmat, buried bodes, etc. It depends on the impulse response of the medium and target being relatively clean. GPR also doesn't typically have the ability to detect moving targets with displacements of 1mm (which is what heartbeats are). Our scenario has an impulse response that looks like a Rayleigh distribution with a half power width of about 20% of the distance, and a very long trailing tail. The CW radar approach we have works great through rubble and collapsed buildings, etc., we're just looking to improve it somewhat with coarse range and azimuth binning, and to synchronize data takes from multiple sensors dispersed around the site. The latter is really synchronized well enough to match heartbeats, so milliseconds is good enough. ___ 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] GPS 18 behavior
On 7/22/13 10:39 AM, Scott McGrath wrote: Moles are a bit small it would probably work better for woodchucks. who are in the process of undermining all lawns in neighborhood now. In a more serious vein most ground penetrating radar is low frequency and I was not aware that THz waves could penetrate ground more than a few CM I believe tvb was using seismic sensors. low microwave (10 GHz) penetrates just fine to tens of meters. I wouldn't want to run a comm link at any sort of data rate, but for 1 Hz bandwidth and coherent detection, it works just fine. ___ 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] GPS 18 behavior
I don't have a GPS-18 in front of me, and I'm modifying some software remotely, and I ran across an issue that someone on this list probably knows off the top of their head. Does the GPS-18 put out 1pps pulses even if it hasn't got a fix yet? That is, when you apply power, does it just start putting out 1pps pulses (at some random phase), and then when it gets a fix, it snaps to the correct timing. The manual says that it puts out 1pps pulses until power is removed, so I assume that when the GPS signal goes away, it keeps on as best it can. I would assume that the clock isn't great, but it's reasonably close to 1pps. What's the behavior when it reacquires? Say the free-running 1pps is something like 1.1 Hz, so in 10 seconds, we've got an extra 1pps. Does it then skip pulses, or what? And a sort of background hardware question... The manual is also not very forthcoming on the electrical characteristics.. is it a pull up with a switch pulling it down to ground? or does it source significant current? That is, if you wanted to wire or the output from the GPS-18 with another 1pps source, would it be diodes or resistors you'd use. = Jim, My own notes on the GPS-18 LVC are here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm You may be able to gather something about the electrical characteristics from that note - the device will happily feed to PC RS-232 ports connected in parallel (driving receive signals, that is) without problem. I recall that during initial testing it takes some time for the PPS to start, so think it needs at least a minimal lock. I have less recollection about how long the PPS takes to stop in the event of lack of satellite signal, but it does stop at some time and does not continue for ever. Being crystal-controlled, I imagine that the free-running PPS would be pretty accurate, not 10% out as you suggest. 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] GPS 18 behavior
The GPS-18 does NOT output 1PPS until it acquires lock. Then the 1PPS stays on even if lock is lost, running from the internal crystal. I have not checked, but once it reacquires lock I presume it jumps to the correct second. All outputs including 1PPS are CMOS levels, so it drives both low and high. David On 7/21/13 9:02 AM, Jim Lux wrote: I don't have a GPS-18 in front of me, and I'm modifying some software remotely, and I ran across an issue that someone on this list probably knows off the top of their head. Does the GPS-18 put out 1pps pulses even if it hasn't got a fix yet? That is, when you apply power, does it just start putting out 1pps pulses (at some random phase), and then when it gets a fix, it snaps to the correct timing. The manual says that it puts out 1pps pulses until power is removed, so I assume that when the GPS signal goes away, it keeps on as best it can. I would assume that the clock isn't great, but it's reasonably close to 1pps. What's the behavior when it reacquires? Say the free-running 1pps is something like 1.1 Hz, so in 10 seconds, we've got an extra 1pps. Does it then skip pulses, or what? And a sort of background hardware question... The manual is also not very forthcoming on the electrical characteristics.. is it a pull up with a switch pulling it down to ground? or does it source significant current? That is, if you wanted to wire or the output from the GPS-18 with another 1pps source, would it be diodes or resistors you'd use. ___ 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] GPS 18 behavior
On 7/21/13 7:15 AM, David McGaw wrote: The GPS-18 does NOT output 1PPS until it acquires lock. Then the 1PPS stays on even if lock is lost, running from the internal crystal. I have not checked, but once it reacquires lock I presume it jumps to the correct second. All outputs including 1PPS are CMOS levels, so it drives both low and high. David OK.. so my wire or question can be answered.. I've got a bunch of microcontrollers (teensy3 from pjrc) with High Z inputs that I want to sync, and since the Garmin 1pps can both source and sink, a diode and resistor might work well. When I don't have 1pps, I can have one of the modules reconfigured to be a source, with a series resistor. Thanks all.. ___ 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] GPS 18 behavior
On 7/21/13 6:59 AM, David J Taylor wrote: My own notes on the GPS-18 LVC are here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm You may be able to gather something about the electrical characteristics from that note - the device will happily feed to PC RS-232 ports connected in parallel (driving receive signals, that is) without problem. I see you're driving a LED through a 1.5k resistor, and still getting above the notional 3V threshold for the RS232 input, so that PPS must be able to source a fair amount of current. So it's definitely not a 1 k pullup and an open collector driving it. I recall that during initial testing it takes some time for the PPS to start, so think it needs at least a minimal lock. I have less recollection about how long the PPS takes to stop in the event of lack of satellite signal, but it does stop at some time and does not continue for ever. Being crystal-controlled, I imagine that the free-running PPS would be pretty accurate, not 10% out as you suggest. Oh, I didn't actually think it would be 10% off.. more like a few ppm, depending on temperature. I was wondering more what would happen if you were indoors for a couple days, then went back out, what the box does. realistically, I don't expect that it smoothly brings it back into line, rather, I would expect it to jump to the correct time and timing. I think, realistically, I should be looking at the actual sentences coming out and figuring out whether our GPS synchronized state has changed, and maybe deal with it appropriately. ___ 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] GPS 18 behavior
From: Jim Lux [] Oh, I didn't actually think it would be 10% off.. more like a few ppm, depending on temperature. I was wondering more what would happen if you were indoors for a couple days, then went back out, what the box does. realistically, I don't expect that it smoothly brings it back into line, rather, I would expect it to jump to the correct time and timing. I think, realistically, I should be looking at the actual sentences coming out and figuring out whether our GPS synchronized state has changed, and maybe deal with it appropriately. = Jim, My experience is limited, but I recall that the PPS stopped soon after the signal disappeared, and would only re-appear when the unit had sufficient lock on the GPS. There is indeed a valid/not-valid bit in the output stream (perhaps referring to position, it's in the manual). My GPS 18x LVC is noticeably more sensitive than the GPS 18 LVC, and will work almost all of the time indoors. I am on the second floor of a two storey house, and I have the 18x up against a south-facing brick wall perhaps 5m above ground level. Most of the other GPS devices I have which work from puck antennas get satisfactory reception indoors as well. Only the old Garmin GPS 12XL and a Rapco 1904M GPSDO need more attention to the signal - they are both turn of the century devices IIRC. More modern devices seem to be more sensitive. You might like to go for an 18x and put it in view of the sky, if possible, or even use a module like: http://www.adafruit.com/products/746 which works nicely indoors here as well, that particular unit being in a walk-in cupboard with a north-facing wall. I'm at 56 degrees north, so you may be better located. Perhaps that module may be more in keeping with your other devices? 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] GPS 18 behavior
On 7/21/13 9:28 AM, David J Taylor wrote: From: Jim Lux [] Oh, I didn't actually think it would be 10% off.. more like a few ppm, depending on temperature. I was wondering more what would happen if you were indoors for a couple days, then went back out, what the box does. realistically, I don't expect that it smoothly brings it back into line, rather, I would expect it to jump to the correct time and timing. I think, realistically, I should be looking at the actual sentences coming out and figuring out whether our GPS synchronized state has changed, and maybe deal with it appropriately. = Jim, My experience is limited, but I recall that the PPS stopped soon after the signal disappeared, and would only re-appear when the unit had sufficient lock on the GPS. There is indeed a valid/not-valid bit in the output stream (perhaps referring to position, it's in the manual). when I'm in a GPS denied environment, it's not just because we're indoors, it's because we're somewhere that GPS isn't available, so what I'm really doing is providing a sort of flywheel to keep my little modules synced with each other. I don't need super accuracy in an absolute sense: I just need to tag the data all with the same time tag within a few seconds. I have a GPS in the system, so that was convenient. My GPS 18x LVC is noticeably more sensitive than the GPS 18 LVC, and will work almost all of the time indoors. snip You might like to go for an 18x and put it in view of the sky, if possible, or even use a module like: http://www.adafruit.com/products/746 Mostly, I'm trying to use what's already in the system. I have the GPS-18 already there feeding a PC with position and time (when available), and as long as it has the 1pps, I figured I could use that to sync the modules with a hardline (that talk to the host PC via USB). Right now, I sync them (without GPS) by having one be a master and send a pulse that the others receive. They're little teensy3 modules (like a fast Arduino with more memory and peripherals), so I just have one of the GPIO pins wired together. Somewhere down the road, I'm going to be changing the system architecture so that the modules aren't all in the same physical box and a wire for sync isn't practical. So the idea is to put a GPS with each module, and assuming they all see the GPS at the same time, they each sync with the 1pps. If I can figure out how get the sync to garmin, but have flywheel work in the present system, then I can start to get that piece of the future system done now. Or, at least, go through the first half dozen iterations. In a very much down the road scenario, I'll be looking at trying to synchronize the modules to 100 microseconds AND try to make the RF section stay on the same frequency within a fraction of a Hz (at 3-30GHz). *that* is a substantially more challenging chore. Basically implementing a GPSDO good to 1E-11 over 30 seconds in each module. And small, and battery powered, and cheap, of course grin For today, though, sync to 1 millisecond among the physically connected modules is plenty good. ___ 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] GPS 18 behavior
when I'm in a GPS denied environment, it's not just because we're indoors, it's because we're somewhere that GPS isn't available, so what I'm really doing is providing a sort of flywheel to keep my little modules synced with each other. I don't need super accuracy in an absolute sense: I just need to tag the data all with the same time tag within a few seconds. Jim, If the requirement is just a couple of seconds, did you consider one of the high-accuracy Dallas RTC chips? That might be a simpler solution than a GPS receiver (knowing when and when not to trust its 1PPS, decoding NMEA, trusting NMEA, needing antenna with sky view). If the requirement were sub-second, the solution is GPS; if the requirement were minutes, it's TCXO. Sounds like you're in the gray area where GPS is not necessarily the simplest, cheapest, or robust solution. The other thing about multiple, portable or remote sensors is that in some cases they don't actually need to agree on time or rate internally as long as you can post-process the data and retroactively apply a time and frequency correction to the data they have already collected or are collecting. For example, if you know one is 2.3 seconds ahead and slow by 45 ppm you can still obtain highly accurate time-stamps from it -- the unit itself does not need to be on-time, or on-frequency. /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.
Re: [time-nuts] GPS 18 behavior
On 7/21/13 1:35 PM, Tom Van Baak wrote: when I'm in a GPS denied environment, it's not just because we're indoors, it's because we're somewhere that GPS isn't available, so what I'm really doing is providing a sort of flywheel to keep my little modules synced with each other. I don't need super accuracy in an absolute sense: I just need to tag the data all with the same time tag within a few seconds. Jim, If the requirement is just a couple of seconds, did you consider one of the high-accuracy Dallas RTC chips? That might be a simpler solution than a GPS receiver (knowing when and when not to trust its 1PPS, decoding NMEA, trusting NMEA, needing antenna with sky view). We have two requirements.. one is know when the data was collected in an absolute sense: that's a few seconds kind of requirement because we're collecting data for 30 seconds anyway. But we have another requirement to be able to align multiple simultaneous takes within a millisecond or so. For what it's worth, the application is a radar that detects buried victims in disaster rubble, so the data we are collecting is basically heartbeats and breathing. the when was the data taken is a where were we when the data was collected need. The sync requirement comes from being able to find the same heartbeat in multiple data streams. http://www.dhs.gov/st-snapshot-tech-foraging has a picture of the radar and a test site. If the requirement were sub-second, the solution is GPS; if the requirement were minutes, it's TCXO. Sounds like you're in the gray area where GPS is not necessarily the simplest, cheapest, or robust solution. As it happens, we already need to have GPS position of the data take (where possible), so the GPS is there and available (sometimes). It's the what do I do when the GPS isn't there that I'm working through. The other thing about multiple, portable or remote sensors is that in some cases they don't actually need to agree on time or rate internally as long as you can post-process the data and retroactively apply a time and frequency correction to the data they have already collected or are collecting. For example, if you know one is 2.3 seconds ahead and slow by 45 ppm you can still obtain highly accurate time-stamps from it -- the unit itself does not need to be on-time, or on-frequency. Indeed. For this application, knowledge is actually more important for sync. The XO on the board setting the sample rate is good enough that if I just count clocks, and timestamp when I get the sync pulse, I can line things up with a few seconds one way or another.. the data take is 30 or 60 seconds, and even if we're WAY off, it's not going to be a millisecond off from a rate error at the end of 60 seconds. The distributed sensor problem down the road, though, I'm doing coherent microwave demodulation, so that's why I need the 1E-11 over 10-100 seconds. I'm looking for signals at 0.1 to 1 Hz (breathing and heartbeats) and if the transmitter and receiver are off by 1 Hz, then the difference looks just like a heartbeat. To be honest, I'm not sure the distributed sensor (basically a bistatic radar) is doable with totally independent systems. What I might wind up doing is detecting the direct path and the reflected path simultaneously and looking for it that way. It's basically a sort of phased array problem, and if you can somehow manage to get your phase reference distributed among all the elements with small phase error over the measurement interval, that's a good thing: less post processing, and all that. /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.
