Re: [time-nuts] distirbuted sync
You can prototype a system with off the shelf parts get a few computers, old notebook computers, Raspburry pI' or repurposed routers, what ever you have. Connect a Trimble Thunderbolt GPS to each one. Each one runs NTP. Connect them all to a isolated network. It could be wired, WiFi or whatever. Let's say you have three systems. When all three can se the sky they have good timing.Now cover lone, two or all three GPS antenna and you are stil doing OK for a while. With all thre antennacovered you ar will still have the system time sync'd even it it drifes from real UTC by a few tens of milliseconds. But if just one of the three can see the sky for a little while the time gets corected in all systems You can't use Eithernet in the real system but you can rig some other media. Blue Toth works over a short distance but you have radar. It seems like you should be able to use the radar for data communications. Radars if they ca hear the echo at all would be senitive for very long range lateral communications. You say you don't want more radios on the devices so just use the radar signal for low data rate local communications. Put TCP/IP stack on it On Tue, Jul 23, 2013 at 8:19 PM, Jim Lux jim...@earthlink.net wrote: On 7/23/13 9:15 AM, Chris Albertson wrote: I don't think those requirements are hard. You can build a system that works in three cases 1) GPS is available full time 2) GPS is available intermittently. 3) there is not GPS system, world war III has destroyed it. or you're in an urban canyon or you're underground or you're working in a GPS-denied environment (battlefield scenario) I think what you want is a system that is failure tolerant and can make use of the best available source of timing and degrade performance gracefully. And you need this is be automatic with the only control maybe being a status LED that shows free/yellow/red I'm not sure failure tolerance is actually the right approach: more like selecting the appropriate mode. There's probably no need to smoothly change between GPS available and not available, for instance, so one doesn't need some sort of optimal estimator that combines all available sources. You can just jump There is a desire to leverage other assets that are available (there's already too many radios.. we don't need to add more). Each system has a GPS receiver that disciplines a crystal oscillator. This oscillator is used for timing. I think it's clear that this handles cases #1 and #2. Then use you Blue Tooth or whatever other short distance communications system you have to support an IP network. TCP/IP over zBlueTooth works well and is a standard now. Using this you can configure a NTP based network of peers. Each of the above systems, when they are close enough will share timing with the other peers. Time is probably not the hard part. There's tons of ways to sync to 1 millisecond, and for the ranges of interest, light/propagation time isn't an issue. The challenge is finding something that gives me the 1 millisecond without having to add some sort of hardware. For instance, the system *is* a 3 GHz radar, and the challenge is to synchronize transmitters and receivers, but hey, the transmitter can transmit at a known time, the receiver can detect when it sees the transmitted signal. I could even modulate the transmitter. The system runs on a consensus time. If one or more systems has access to GPS those system will supply timing to any other system in range of the blue tooth. If there is no GPS at all the systems will form what they call an orphan network and will remain synced to each other untill some outside source of time connects and puts them all back on GPS time. NTP is pretty good at handing the case where timing sources come on and off line and where network connects connect and then go away. It is very failure tolerant. Or an NTP-like algorithm that handles the communications dynamics of the system. NTP is tuned/designed for networks in terms of adaptation rates and the filters. What you'd have is a kind os graceful degradation. When GPS is visible to all units they are all dead-on and running well above you specs. If GPS is hidden (perhaps in an urban canyon or you happen to be inside a tunnel) the systems ail remain in spec for many hours or even days depending on how much money you spent on the crystal (or Rubidium) oscillators Power mass is more an issue than cost, although $1000 oscillators are probably out of the question. Imagine you have to carry one or more of these things for 12 hours across a disaster site along with your other gear. Power turns into mass, too. Finally if there is no GPS at all but several systems are within blue tooth range that can sync to each other at the few millisecond level. but because you did spend $$ on a god crystal will stay sync'd for hours even when out of bluetooth range with no GPS.
Re: [time-nuts] distirbuted sync
albertson.ch...@gmail.com said: Then use you Blue Tooth or whatever other short distance communications system you have to support an IP network. TCP/IP over zBlueTooth works well and is a standard now. Using this you can configure a NTP based network of peers. .., I'm a big NTP fan, but I wouldn't use NTP for this. (I assume we are talking about the standard NTP reference package from ntp.org.) It's too big and complicated and will be hard to debug if something goes wrong. The real problem is that it will do the best it can rather than scream and shout when something unexpected happens. On the other hand, I like playing with low level things like packets and clocks, and I'm not good at paying attention to the big picture when resources (manpower, time) are limited. It might work fine. It's probably easy to try it. If I was doing something like this (and I could be way off by what this is), I'd try roughly: Measure the clock drift rate on a sample of typical systems. These systems need a clock good to 1E-10. If that can be used by the OS time keeping code the drift should be hard to measure. If not, measure whatever the system will be using. Most likely, it will be way off, as in 10s to 100s of PPM. (The 100s covers software bugs in the OS and design errors in the hardware.) Linux (on a PC) measures the CPU crystal at boot time. There is lots of noise in that. You can bypass that noise if you build your own kernel and find that chunk of code and patch in a constant. (I'm thinking of one kernel build per set of boxes rather than one per box.) Now you have a good thermometer. Ballpark is 1 PPM per C. If you measure the drift on each system and save it in ROM/Flash/file-system, you can add some code to the startup area to tell the system how to tweak its clock. (I'll fish out the API details if anybody wants it.) Is that good enough? Do you even need to do the drift measurement and correction on each box? ... That's some combination of the requirements, how much drift is left and how well the boxes in the field track each other (temperature, manufacturing batch) and if you need the correct time or just closely tracked time. Are some boxes in the sun and others in the shadow? ... Another quirk to consider is that happens if you reboot a box half way through the battery lifetime. Does it get the time from its brothers or from the master PC? Does the PC drift track the others or track GPS or...? -- 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] distirbuted sync
On 7/23/13 11:03 PM, Chris Albertson wrote: You can prototype a system with off the shelf parts get a few computers, old notebook computers, Raspburry pI' or repurposed routers, what ever you have. Connect a Trimble Thunderbolt GPS to each one. Each one runs NTP. Connect them all to a isolated network. It could be wired, WiFi or whatever. This is at work. No junker old laptops.. there isn't enough time in the world to try and figure out their idiosyncracies. Let's say you have three systems. When all three can se the sky they have good timing.Now cover lone, two or all three GPS antenna and you are stil doing OK for a while. With all thre antennacovered you ar will still have the system time sync'd even it it drifes from real UTC by a few tens of milliseconds. But if just one of the three can see the sky for a little while the time gets corected in all systems I think that's overkill for this system. 1 millisecond relative timing is an easy bar to meet with almost any comm link; that's more of an integration challenge: what off the shelf widget comes with the ability to do the sync. The challenge is in the frequency control, without resorting to OCXOs or atomic standards. You can't use Eithernet in the real system but you can rig some other media. Blue Toth works over a short distance but you have radar. It seems like you should be able to use the radar for data communications. Radars if they ca hear the echo at all would be senitive for very long range lateral communications. It's not a pulsed radar. CW, at a milliwatt or ten. the bandwidth of the communications channel, if it can be called that, is on the order of 10-50 Hz. The way the system works is to look at the received signal reflected from the rubble and victim. That signal has a very strong fixed component (the rubble isn't moving) and a very weak component (heartbeats cause a phase shift of around 10 degrees). With a sufficiently large dynamic range receiver one could just digitize, calculate the baseline, subtract it, and look for the changes. However, this is impractical for a variety of reasons. So we coherently subtract a sample of the transmitted signal from the received signal to reduce the overall dynamic range requirement. Then we digitize and process. It's sort of like an nulling interference canceller in the RF comm world, or a flavor of Wheatstone bridge. If the transmitter and receiver are separated (say on opposite sides of a collapsed building, with no direct path), the problem becomes how do I get that copy of the transmitted signal to subtract. We also use the transmitted signal as a coherent LO for the demodulation. (Called homodyne detection in the radar world, and widely used in familiar applications like radar speed guns) You say you don't want more radios on the devices so just use the radar signal for low data rate local communications. Put TCP/IP stack on it Hmm.. TCP/IP at 10 bits/second? I think we can go simpler. We already have to have some sort of data link to send the sampled data for processing, but it's in the 1-10kbps range. Whatever that winds up being, I think that 1 millisecond sync won't be a problem. The challenge is the frequency control (or perhaps frequency knowledge. One additional challenge with the separated Tx and Rx is that we now have two phase noise sources, and we can't leverage the inherent cancellation with homodyne detection. ___ 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] distirbuted sync
On Wed, Jul 24, 2013 at 12:45 AM, Hal Murray hmur...@megapathdsl.net wrote: albertson.ch...@gmail.com said: .. It's too big and complicated and will be hard to debug if something goes wrong. The real problem is that it will do the best it can rather than scream and shout when something unexpected happens.x can be used by the OS time keeping code the drift should be hard to measure. If not, measure whatever the system will be using. Most likely, it will be way off, as in 10s to 100s of PPM. (The 100s covers software bugs in the OS and design errors in the hardware.) Hard to debug? It runs of every router and (non MS Windows) computer on Earth every day 24x7 How often do people have to debug it? I'd guess that 99.99% of the people who use it don't know it even exists. (for example NTP runs on Android phones, along with NITZ for cell signals) It is pretty easy to keep track of how well it is doing You run ntpq and have it output some numbers, then look at the numbers and do what's needed. But then, intersystem communications between two or more radar should be EASY. You can put some data bits on the radar pulses. Same for timing if the PRF (pulse repetition frequency) is well timed then the radar is broadcasting a timing reference The infamous radar range equation pretty much ensures that every radar can hear all the pulses from the other radars. The receivers need to be very sensitive relative to the transmit power MUCH more so then in a communications system. There is also a good reason to modulate a radar pulse with psudorandom-like bits, The receiver knows what was sent and looks for it with an autocorellation function. This allows good noise and jamming resistance. Good plan if you have multiple radars in the same general area. Sounds like a lot of processing but I think this gets done inside a FPGA -- Chris Albertson Redondo Beach, California ___ 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] distirbuted sync
Hi Jim, On 23/07/13 16:55, Jim Lux wrote: Starting a new thread... Good idea! Brian wrote: 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. -- disasters occur world wide, any time day or night, so depending on WWVB won't work. Magnus wrote: 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. -- yes, I'd thought about that, but that's another piece of gear (the centralized transmitter). And if we added another radio into the system, you get into the whole size, weight, power aspect. We already have to have the GPS (for those places where GPS is available). We already have a comm link of some sort (TBD.. long range Bluetooth possibly) between the modules, so we could transmit a sync signal on that. The question would then be whether *that signal* has modulation and propagation characteristics that allow the frequency disciplining. BT is 2.45 GHz, and subject to all the multipath and other ills we encounter with the radar at 3 GHz. This is a bit down the road a bit, so what might wind up being the ticket for GPS denied is putting up GPS pseudolites at the site. that's back to the extra piece of gear problem, but maybe we could make a case that it isn't *our* piece of geargrin. Or have our modules have the ability to transmit a GPS-like signal that the GPS-18 would appropriately handle (oh yeah, I can see the regulatory issues looming for that one!) It *is* an interesting problem.. It's sort of weird, though, as I write the requirements.. High frequency accuracy (1E-10, 1E-11) ideally.. or high stabiity over 1-100 seconds, with a way to get knowledge. But relatively low timing accuracy: 1-3 milliseconds over the same 100 second interval (1E-5) Often you have a time requirement that is commensurate with the frequency requirement. Consider my audio channel over radio-sets. Consider a 1 kHz sine being modulated. Consider that lock your 10 MHz to that 1 kHz. Keeping within a few degrees on that 1 kHz should not be too hard, unless you bump/turn the crystal too much. A little intelligence to bridge the gaps when radio fading occurs is naturally needed. Let's assume you maintain within +/- 1.8 degrees, that's 1/100th of the 1 ms period. You have a maximum of 10 us drift in 1 s, which really is measly 1E-5, but as it is locked, it moves *tau which means 100 us at 10 s and 1 ms at 100 s... for the peak error as you go into hold-over. It will naturally be better as it maintains track. Seems feasible to maintain the needed tracking requirement on the back-of-envelope level of analysis. Oh, if you have a number of these devices spread out, and coordinated time between them is important, just assign one of the devices as master. That way it disappears as extra device. 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] distirbuted sync
I don't think those requirements are hard. You can build a system that works in three cases 1) GPS is available full time 2) GPS is available intermittently. 3) there is not GPS system, world war III has destroyed it. I think what you want is a system that is failure tolerant and can make use of the best available source of timing and degrade performance gracefully. And you need this is be automatic with the only control maybe being a status LED that shows free/yellow/red Each system has a GPS receiver that disciplines a crystal oscillator. This oscillator is used for timing. I think it's clear that this handles cases #1 and #2. Then use you Blue Tooth or whatever other short distance communications system you have to support an IP network. TCP/IP over zBlueTooth works well and is a standard now. Using this you can configure a NTP based network of peers. Each of the above systems, when they are close enough will share timing with the other peers. The system runs on a consensus time. If one or more systems has access to GPS those system will supply timing to any other system in range of the blue tooth. If there is no GPS at all the systems will form what they call an orphan network and will remain synced to each other untill some outside source of time connects and puts them all back on GPS time. NTP is pretty good at handing the case where timing sources come on and off line and where network connects connect and then go away. It is very failure tolerant. What you'd have is a kind os graceful degradation. When GPS is visible to all units they are all dead-on and running well above you specs. If GPS is hidden (perhaps in an urban canyon or you happen to be inside a tunnel) the systems ail remain in spec for many hours or even days depending on how much money you spent on the crystal (or Rubidium) oscillators Finally if there is no GPS at all but several systems are within blue tooth range that can sync to each other at the few millisecond level. but because you did spend $$ on a god crystal will stay sync'd for hours even when out of bluetooth range with no GPS. The good thing is that you only need to integrate existing technology to make this happen. The software, hardware and all the parts are available. You'd not have to pay to advance the state of the art. You would have to balance things like crystal oscillator stability vs. power. Ovenized units suck up power. TCOXs use less power but maybe hours and not days of hold over time is enough. The LED's color depends on the estimated timing error, NTP is good at computing that based on if GPS is connected and working, the network status and so on. So it might be green for microsecond level, yellow for millisecond level error and red for few seconds level, flashing for no-sync On Tue, Jul 23, 2013 at 7:55 AM, Jim Lux jim...@earthlink.net wrote: It *is* an interesting problem.. It's sort of weird, though, as I write the requirements.. High frequency accuracy (1E-10, 1E-11) ideally.. or high stabiity over 1-100 seconds, with a way to get knowledge. But relatively low timing accuracy: 1-3 milliseconds over the same 100 second interval (1E-5) Often you have a time requirement that is commensurate with the frequency requirement. ___ 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. -- Chris Albertson Redondo Beach, California ___ 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] distirbuted sync
Starting a new thread... Brian wrote: 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. -- disasters occur world wide, any time day or night, so depending on WWVB won't work. Magnus wrote: 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. -- yes, I'd thought about that, but that's another piece of gear (the centralized transmitter). And if we added another radio into the system, you get into the whole size, weight, power aspect. We already have to have the GPS (for those places where GPS is available). We already have a comm link of some sort (TBD.. long range Bluetooth possibly) between the modules, so we could transmit a sync signal on that. The question would then be whether *that signal* has modulation and propagation characteristics that allow the frequency disciplining. BT is 2.45 GHz, and subject to all the multipath and other ills we encounter with the radar at 3 GHz. This is a bit down the road a bit, so what might wind up being the ticket for GPS denied is putting up GPS pseudolites at the site. that's back to the extra piece of gear problem, but maybe we could make a case that it isn't *our* piece of geargrin. Or have our modules have the ability to transmit a GPS-like signal that the GPS-18 would appropriately handle (oh yeah, I can see the regulatory issues looming for that one!) It *is* an interesting problem.. It's sort of weird, though, as I write the requirements.. High frequency accuracy (1E-10, 1E-11) ideally.. or high stabiity over 1-100 seconds, with a way to get knowledge. But relatively low timing accuracy: 1-3 milliseconds over the same 100 second interval (1E-5) Often you have a time requirement that is commensurate with the frequency requirement. ___ 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] distirbuted sync
On 7/23/13 9:15 AM, Chris Albertson wrote: I don't think those requirements are hard. You can build a system that works in three cases 1) GPS is available full time 2) GPS is available intermittently. 3) there is not GPS system, world war III has destroyed it. or you're in an urban canyon or you're underground or you're working in a GPS-denied environment (battlefield scenario) I think what you want is a system that is failure tolerant and can make use of the best available source of timing and degrade performance gracefully. And you need this is be automatic with the only control maybe being a status LED that shows free/yellow/red I'm not sure failure tolerance is actually the right approach: more like selecting the appropriate mode. There's probably no need to smoothly change between GPS available and not available, for instance, so one doesn't need some sort of optimal estimator that combines all available sources. You can just jump There is a desire to leverage other assets that are available (there's already too many radios.. we don't need to add more). Each system has a GPS receiver that disciplines a crystal oscillator. This oscillator is used for timing. I think it's clear that this handles cases #1 and #2. Then use you Blue Tooth or whatever other short distance communications system you have to support an IP network. TCP/IP over zBlueTooth works well and is a standard now. Using this you can configure a NTP based network of peers. Each of the above systems, when they are close enough will share timing with the other peers. Time is probably not the hard part. There's tons of ways to sync to 1 millisecond, and for the ranges of interest, light/propagation time isn't an issue. The challenge is finding something that gives me the 1 millisecond without having to add some sort of hardware. For instance, the system *is* a 3 GHz radar, and the challenge is to synchronize transmitters and receivers, but hey, the transmitter can transmit at a known time, the receiver can detect when it sees the transmitted signal. I could even modulate the transmitter. The system runs on a consensus time. If one or more systems has access to GPS those system will supply timing to any other system in range of the blue tooth. If there is no GPS at all the systems will form what they call an orphan network and will remain synced to each other untill some outside source of time connects and puts them all back on GPS time. NTP is pretty good at handing the case where timing sources come on and off line and where network connects connect and then go away. It is very failure tolerant. Or an NTP-like algorithm that handles the communications dynamics of the system. NTP is tuned/designed for networks in terms of adaptation rates and the filters. What you'd have is a kind os graceful degradation. When GPS is visible to all units they are all dead-on and running well above you specs. If GPS is hidden (perhaps in an urban canyon or you happen to be inside a tunnel) the systems ail remain in spec for many hours or even days depending on how much money you spent on the crystal (or Rubidium) oscillators Power mass is more an issue than cost, although $1000 oscillators are probably out of the question. Imagine you have to carry one or more of these things for 12 hours across a disaster site along with your other gear. Power turns into mass, too. Finally if there is no GPS at all but several systems are within blue tooth range that can sync to each other at the few millisecond level. but because you did spend $$ on a god crystal will stay sync'd for hours even when out of bluetooth range with no GPS. Most off the shelf BT interfaces don't have timing outputs, and I'm not exactly thrilled about implementing BT from scratch. It's sort of like getting timing from Ethernet. Sure, you *could* modify a standard ethernet transceiver to be driven from a 10 MHz, or to recover 10 MHz from the Ethernet signals, and you could modify it to tag when you get a sync detect. But it's a heck of a lot easier to buy someone's PTP enabled interface. The good thing is that you only need to integrate existing technology to make this happen. The software, hardware and all the parts are available. You'd not have to pay to advance the state of the art. You would have to balance things like crystal oscillator stability vs. power. Ovenized units suck up power. TCOXs use less power but maybe hours and not days of hold over time is enough. The LED's color depends on the estimated timing error, NTP is good at computing that based on if GPS is connected and working, the network status and so on. So it might be green for microsecond level, yellow for millisecond level error and red for few seconds level, flashing for no-sync In this system, the user doesn't care what the time uncertainty is. either it's good enough, or it's not.
