Yes but most spectrum analyzers can compute allen variance now a days with just the push of a button. You also have dedicated time interval counters for just this task
Nowadays they have chip-scale atomic clocks; the Microsemi SA.45s has 0.05 ppb accuracy and 0.3 ppb/month aging at 115 mW power consumption. The application list includes "Underwater sensors for seismic research or gas and oil exploration", seemed quite obscure 'til now :P
Your method is basically an higher-tech version of the old trick of taking the two clocks, plugging them into the two axes of an X-Y scope, and timing how long it takes the eye to "wink" (every 180-degree change in phase is half a cycle slipped), which gives you the difference in the two frequencies. A higher-precision way is to use a time interval counter (TIC), which basically does the same trick of using a microcontroller to count the number of ticks of a sample clock between the rising edge of one signal and the rising edge of another, but then it adds on some analog electronics to measure time less than one clock (as a simple example, imagine charging a capacitor with constant current, dumping it back to zero once per clock, and having a way to isolate it after the STOP signal comes in. Then you can discharge it at a lower constant current and "stretch" the original time interval by the ratio of the currents). That *is* a device you can buy from Agilent or whoever. Then you can plug it into a PC and run the data into an app like TimeLab and get some nice plots.
I now realize that the crystal is not to be trusted. I use an esp32, using a built-in timer and the crystal, which should wake up twice in 24 hours and wait for a reset button. The crystal was drifting so much it was impossible. Changed the program, so now the esp32 wakes up every hour and checks against the internet if the time is less than an hour left, otherwise it goes back to sleep again. In one hour, the drift is so small that this works. My project is very small relation to yours but well explained and it helped. Thanks.
I may have one somewhere, I'd have to look. In this application it's only this resultant "skew corrected" data we are interested in. As it's the maximum drift deviation over the recording period that is the concern. And it ain't as "random" as you might think, that's what makes it all very interesting. The one shown is about as "random" as you'll find, the majority are usually more sinusoidal in shape.
I remember in one radar system, the crystal oscillator OCXO in the tracker unit required 20 minutes to stabilize. As little as the grease from the technicians fingers could change the "oven's temperature" enough to send the chassis back for repair. We needed the trackers out ASAP. So failure rates were high once the trackers got into the field.
I think a reason that wristwatches are relatively accurate is the fact that you wear them all the time. Therefore the temperature of the watch is kept relatively constant (near the temperature of your wrist). Also maybe due to the fact that shocks etc are pretty random they "cancel" each other out.
Usually there is not that much temperature variation. A wrist watch is usually on your wrist and in constant contact with your skin. As such, the temperature is rather constant.
the attenuation of the GPS signal that far underwater would be difficult to get around. Most GPS sensors cannot work indoors, even if you did get a signal you would then have to worry about the signal bouncing from the environment which can significantly affect its accuracy, its why in built up areas you can loose GPS position accuracy as the signal bounces of of buildings that create a canyon effect. I know that the post is quite old but it may be noteworthy to someone :D
The telco industry has spent a lot of time on this and the internal documentation on this subject at least where I worked, was good. We used TCX0's as the basic clock, there were 3 of which we took the best of 2 at any given time. The long haul communications nodes had rubidium oscillators to stabilise the long term drift of the TCXO's
OR'ing 3 oscillators is the best mean to stabilize and eliminate the radiation problem, your circuit works fine until a cosmic background microwave radiation resolve to shoot your oscillator out of phase.
Measuring clock stability is such an important part of the GNSS (GPS/Gallileo) system. The method involves using one master clock, which is known to be more stable than the unit under test, and to measure what is known as the Allan Deviation. The Allan Deviation provides all kinds of useful information about the performance of your clock, including what types of instabilities you're dealing with.
Dave... Very innovative method for measuring the drift over time, I am quite impressed. I guess this is the price to pay for using a natural-mineral based element for frequency control: there is some randomness thrown in for free. I wonder if it's possible to produce quartz with a reliably repeatable structure to make the drift characteristics also match very closely
you can make it fucking perfect, if it's small and get shot by radiation it will drift, whether it's completely pure or not doesn't matter. Rubidium is more precise and uses more energy because it needs more energy, from radiation's point of view it's like the difference between fighting sheldon cooper and fighting godzilla.
@sostenuto If you want to measure jitter or phase noise, your measuring equipment always has to be better than the DUT by quite a margin. The triggering on a scope may do for relatively jittery square wave sources like a CMOS VCO, but hardly for an XO. Phase noise analyzers go to great lengths in cancelling the contributions of major phase noise sources. I suggest you check out the websites of Leif SM5BSZ and Enrico Rubiola, those might give you an idea. Also look at drift cancellation.
I know I'm late to the party. However you could use a FM ramp up signal from your boat that the hydrophones can pick up and record as well to use in post DSP
@SolutionByEvolution I was thinking exactly the same thing. If this was a generic set of time-series data, you could end up with a completely wrong result by binning. But I assume Dave knew enough about the characteristics of the drift that he knew he could get away with that technique.
I guess the input to the reset of the flip flop must be inverted since the flip flops I have seen will always be low when reset is asserted. I also guess that D is tied to Vcc. When the 96Khz signal strobes past the 8Khz marks, I guess the counter will jump from zero to 104. I guess you could programmatically create a round-robin with 104 being equivalent to -1, 103, -2 etc. Many micros have two 16 bit counters so everything could be done in the sub-30 cents STM8S103F3 which is great silicon, although takes a little more getting used to developing (Avoid STs standard libraries, use gicking stm8as.h instead... Silicon-wise ST are VERY good, software-wise ST are CLOWNS.) . Clock the STM from the rubidium source, feed DTCXO into TIM2_CLK. Software handles the rest.
fantastic video. what a classic trick. good to see it done in discrete logic chips like that to get extreme speeds. gotta feel bad for the ocean life tho
I don´t known it for digital clocks, but mechanical watches have a asymmetric tolerance: Showing a "later time" then it is actually is more likely then showing a "to earlier" time. So your excuse would not work. Expect your blame their watch.
Why didn't you maintain an average of several counts to reduce the effects of jitter instead of using a binning technique? The averaging number crunching could have been done by the PIC and the results sent to the PC to reduce interface burdens.
I know this is an old video, but Dave, didn't you basically implement a time interval counter? We used to use TICs but ultimately switched to HP5071 cesium clocks for our project, and the TICs fell out of use. TICs are definitely test equipment you can buy "off the shelf" :-)
If you math out all simple temperature correlated stuff bei DTC (and do it right) then you have an output with artefacts which is not temperature correlated (or at least shows just remaining artefacts beyound your algorith). Anyway: Wouldn't it have been an option to resync the probes sitting on the bottom of the ocean by some radio pulse (low frequency... deep water.. long antenna rods) just before the actual acousting ping takes place?
ok so tell me this does for example my SOC in phones frequesncy drift? if it does it explain me why half of the phones start to lang dramatically despite software issues. also why not simply use a cheap XO sinc it with gps every some time and compensate a drift? wouldnt that be mutch easyer solution since GPS is like an external constant for all of those devices?
I have few questions: 1) Do you measured how many 96KHz positive triggered samples were their in 1 8KHz? There is huge possibility that you may have only 9 or 7 positive triggers in 1 8Khz clock cycle! & you may miss it depending on your sampling rate. 2) I am hoping that these calculations were done after taking out the individual data loggers(hydrophones) from the sea & you can't be sure if they follow the +ve curve or -ve curve every time. Or was their anyway that the drift in clock was in same direction or what was the way in which you concluded that? 3) Was it really worth it? As i am assuming knowing the final drift & drawing a linear curve can also do the job more or less consistently if the data is logged at pretty big sample rate so that some minor deviations can be ruled out in between individual oscillators! What was the data logging rate for the hydrophones?
Hi Dave, EE here.. This is interesting. I've done crystal osc design; in the 1-5 ppm range and didn't have to pay much attention to drift. ... Help me understand the "quadrants". Are these simply count ranges? Such as 0-25 then 26-50, then 51-75, then 76-100 ? I imagine you selected these quadrants based on the typical short term stability of the osc, no?. ... - Were these off the shelf oscillator modules or did you put crystals in your own oscillator? - What was the basic stability spec on the oscillators? - Was there any TC done, or is the ocean floor a constant temp? - Were the oscillators pre-aged, or selected for cut angle? ... - Which logic family did you use for the counter? Jitter can be introduced there and was that part of your 'quadrant' size choice? ... - I was always told that the long term drift was due to mechanical part aging and 'work-in'. so it was more asymptotic. So, does this simply give you the characteristics that you then assume continues in the field with the same period/frequency - centered along the linear average? ... - Was the time period of use short enough so the short term average was assumed approx. linear rather than worrying about the asymptotic curve? ... -- Cheers, Steve
Not sure if I understand how the compensation is applied. ... I don't understand if this is individual compensation or just getting the characteristics of the family. If it is for a family of oscillators were they all selected from one run from the manuf?. ... Is the maximum drift from the linear within the requirement so you don't need to track the individual (sine) variations, only take out the linear component as long as the short term variations are within the required? -- Cheers
Why not keep them in relative sync by broadcasting a standard pulse from a known location. Control for ocean conditions by transmitting a pulse from a standard location on the ocean floor and the relative difference should be consistent throughout your experiment and can be used to compensate for drift for each oscillator. Enough standard pulses and you can compensate for non linear and even non monotonic drift effects.
+NatureAndTech nop, i can sinchronize with the pulse i received then exactly 1s later send my id to the base station and they will know exactly the latency and send back the timing adjustment with the id of the receiver calibrated. Btw, there's nothing magical about sonar data transmission at low speed, except the limited bandwidth. Theoretically you can use transducers to dial up an internet connection to an island, but no one else can do this at the same time because you've got "only one pipe" for the signal to flow.
I think I would just have stuck a Rubidium Oscillator in it and check it periodically (e.g. every day) where the offset can be reasonably linearly approximated. Assume the Rubidum takes 20W and takes 30 Minutes to warm up and lock. That would be 18kJ or 10Wh per day, so 900Wh, 1.62MJ over the period of operation of 90 days. About the energy of two car batteries. Much but still tolerable in such an application.
If I am assuming correctly this looks similar to a project done by Shlumburger in the North Sea some years back. The sensors were hundreds and deployed by attaching them to underwater cables. There were something like underwater planes which took care of guiding these cables through the currents so that the cables are equally spaced and did not get entangled by the North Sea currents. Pretty exciting engineering challenge!! If this was the project Dave is referring to, attaching hundreds of lead acid batteries to the underwater cables would have been impossible.
you didn't understand, they need to lock the timers of that shit between multiple data collectors, fuck, if gps can do it why not use the exact same system but with ultrasound? they're both based on timings and tridimensional waves.
plus they are based on the propagation speed. The propagation speed of sound under water changes with pressure, water temperature, the density of the water and there is doppler shift from the water currents.
why not have a master clock on the surface send out a ping to all the individual modules through the water periodically, so when the data is gathered at the end of the experiment the pings along with the data can be realigned through time stretching? then the clocks can drift all they like. : )
Trust me José, what you're experiencing is not related to the oscillator. In my long carreer of computer engineer, I've built more than a hundred PC and I only met once a crappy oscillator, it was impossible to get a sharp picture with a PCI TV card. It only happened once. Your problem is more likely system and general hardware related. For example, if you encounter jitter while your software is accessing your harddrive, obviously it's not oscillator related. Remember the PC is at start a business machine and wasn't met for high precision timing and music. You can circumvent many timing problems by using a real time OS, an OS were kernel reaction time is known and constant. Hint : windows is not one of them.
But as far as i'm concerned the OS Kernel relies on motherboard's master clock to sync the threads. Not just that, but most peripheral, including the CPU, also relies on the master clock as a base frequency. Am i wrong? Also, i have an old SIS motherboard for Athlon XP that seems to perform smoother than recent boards. I noticed that the clock implementation on these old SIS boards is better, with more filters (capacitors) to delivery smoother power supply to oscillator. For some reason, the new hardwares can't keep the timigs right. But i don't know, im just a curious guy looking for some answers.
Would drift be why my laptops base clock has gotten more and more unstable and inaccurate over time? Base Clock flies all over the place now, fluctuating between 96 and 104 mhz.
if a clock drifts by 20 seconds a day i'd eat my hat, i'd expect that from a mechanical escapement (a real good one at that)... i've made picaxe based clocks using analogue clock tickers before which maybe lose maybe a few seconds a day. and a binary watch which i think gains less than a second a day using a 32.768 Xtal from a fax, and i usually set it to internet time regularly
He is 15 minutes in the 24 minute long video when reaching the actual subject for the first time! I know it's Dave's thing to go about this stuff totally unscripted, that he's done it for ages and thus my lowly rant here won't achieve anything, but since it's my thing to bitch about it I'll do it anyway. While I do find the info about seismic activity monitoring rather interesting, it is heavily irrelevant to the actual subject. Even if it presents a (single) use case for it, it becomes a distraction rather than serving the purpose of educating people about electronics. Anyone else finding this frustrating? I totally appreciate a lot of Dave's audience simply enjoy his random blabber, but since it's become such a big channel and shows a lot in the search results, there must be other's like me who keep ending up here while actually trying to learn about electronics. Again as I said it's Dave's thing and I'm 100% backing his right to do anything he wishes on his own channel which, simply looking at the numbers, is clearly working but at least I got it out of my system for a bit. Also, I AM thankful for the vast information internet is bringing to my reach free of charge but the vastness tends to make it equally hard to reach as if it was scarce. UA-cam's main goals is to distract you and it happens easily and even if you maintain your focus, it takes unreasonable amount of time to wallow through stuff like seismic activity monitoring to gain knowledge that could just as easily be delivered in less than 5 minutes.
I might just be stupid and unable to grasp these complex concepts, but I don't even get the 3rd row in the first chart on the whiteboard. I bet planning things ahead would save at least an equal amount of effort in editing the videos and correcting the human errors that could be at least more easily avoided with a bit more patience in advance.
then you would have either integrate a diving drive on the probe to submerge back each hour. Or you take a several hundred/thousand feet long cable with a gps dinghi at the end ;-)
I'm confused here. Dave states that rubidium clocks simply consume too much power to be used in the ocean floor sensors. Then he show's a circuit directly using a rubidium reference clock to determine whether or not the chosen crystals are drifting. So I'm going to assume that this was done on the surface in the lab. Dave also mentions that there were hundreds of these ocean floor sensors, so I'm guessing these month long tests were performed on hundreds of units? That sounds a bit impractical. Then what? For each of the several hundred crystals you create a drift profile then presume when you turn it on a few weeks or months later at the bottom of the ocean at 3 degrees Celsius that it will follow that same profile you measured in the lab. Then when you collect the data you correct for your lab measured drift. That seems a bit crazy to me, there is no way that's accurate. What am I missing. It seems the best you can do here is simply say "we will have X maximum error in our results", but I don't see how anything can be "corrected" for after the fact.
If you listened to the whole presentation, the Rb clock was used in a lab setting (constant temp, no vibe,etc) to characterize the drift over time of several samples. This in turn was used to construct a maximum drift over time characteristic. That characteristic was then applied to all other drift and error sources to determine if the oscillators selected would fulfill the customer requirements. This was not used to calibrate each oscillator, only to determine the normal characteristics of the family. The story/talk/tutorial was more about determining a characteristic of a component, not calibrating. Fascinating topic.
I had a regular quartz watch i set to my school clock at the beginning of the year, so that i could know the second the bell rings (rings for 5 seconds from :55 - :00). By the end of the school year, 8 months i think, it was still accurate to the second. I specifically looked for a drift, but found none. O_O
funny way to explain things but specifically for the topic of Oscillators unfortunately wrong explanations on the terminology for a TCXO and DTCXO was used… A TCXO is not a temperature Controlled Oscillator but just a temperature Compensated Oscillator… similar like DTCXO. It is again just a temperature compensated product but using a more complex compensation using a microprocessor.
arnt you just comparing drift to an also drifting clock? is there a way to compare two clocks in a reversal type way to get a true time? something like a vernier clock system?
you could have used two oscillators together with an or, then every time it flips you know it's drifting, you can compensate and get half the precision error, with 3 oscillators you'd get 8 times the precision or more, since you can compare two and adjust the third. Use nasa's solution, if you have more than one you get exponentially less problems.
radiation is the primary problem with oscillators, if you get two clocks agreeing that the third has drifted you know it was probably shot by cosmic background radiation and elevated to a higher energy state, resulting in out of phase oscillation. Nasa had almost the exact same problem with memory, when radiation hit the memory turning 0's in to 1's and vice versa.
I don't think cosmic radiation is a problem taking deep sea measurements. Yes, consensus vote is good for detecting defective devices and ignoring them. But with drift it's different - every oscillator drifts over time - you would have to physically compensate the drift of the detected oscillator i.e. with temperature in a servo loop and that for each oscillator. The beauty of compensating for the drift in post-processing is its simplicity.
Why get a super oscillator when you can have an atom clock for free? Glonas, Galileo or GPS deliver it right to your door (unless that is inside) it is good to the ns. GPS receivers must be dead cheap, I have four and I am rather poor.
Croz89 mind you power efficiency would be at a minimum as well. As Dave mentioned, the drift is something you roughly measure before hand and compensate later on in software after the data has been collected.
Croz89 mind you power efficiency would be at a minimum as well. As Dave mentioned, the drift is something you roughly measure before hand and compensate later on in software after the data has been collected.
JohannaMueller57 The RbXO was only used to characterise the drift prior to deployment of the UWMs. The results of this characterisation could potentially be used to correct the TCXO drift during post processing though I think the guy said that the worst case drift was found to be within tolerance for the application.
+billiepipersteeth radiation compensation is the problem, everything runs smooth until your oscillator gets hit by the energy of a bullet in a needle tip coming from a supernova or solar flares or even cosmic background radiation. No wonder rubidium oscillators are more stable, they have a lot of mass and each cycle of the oscillation consumes much more energy, from the perspective of the radiation it's like comparing a fight between you and sheldon cooper and a fight between you and godzilla.
cant you just use 1 MCU instead of all that to test the drift? if you use high precision 10MHz MCU clock and timers/counters and interupts inside of MCU. Then you dont need your external triger and counter, witch give you parasitic delays. At least thats my opinion.
Daata pls... dada is your mum's fellow. Brick !!! Drift is dependent on each individual silicon quartz grown crystal, hence you cannot define a standard drift rate. OK... back to mindless UA-cam :) ( This looks good on paper, btw )
No offense, sorry. I am a technician who works with engineers, scientists, and physicists. I have been well inundated ( beaten about the head ! ) with the community standard for the thing that makes my paycheck. I make Quartz Oscillators www.microsemi.com/products/timing-synchronization-systems/time-frequency-references/quartz-frequency-references/1000c-ultra-high-performance-crystal-oscillator and am the lowest rung of knowledge in the field, so no pretense to a judge, just parroting what I live by everyday, globally. I admire your work and wish you only the best. Thanks for posting ( what I should have said originally, must've had a bad corporate day; Edison is somewhat of a prick! )
Did you know that Rhonda Rousey's mother is a PhD Statistician? She calculated which one of her kids could take her experience and make it work! Rhonda made a lot of $$, so there must be something to your discipline! Shake 'em out, see which way they fall!
actually you kinda can, you can OR 3 oscillators and use the consensus of two or more of them to recalibrate the faulty one, drift is a radiation problem, you can't blame the tiny crystals for being shot by radiation coming from who knows where, rubidium is more precise because it need a fucking 2 orders of magnitude the quanta charge of quartz to oscillate, wich means that a radiation shot at a rubidium oscillator is an almost insignificant disturbance.
12 years and still fascinating 👏 👌
Yes but most spectrum analyzers can compute allen variance now a days with just the push of a button. You also have dedicated time interval counters for just this task
Applying logic to solve an unexplored problem. I love this kind of stuff :)
Nowadays they have chip-scale atomic clocks; the Microsemi SA.45s has 0.05 ppb accuracy and 0.3 ppb/month aging at 115 mW power consumption. The application list includes "Underwater sensors for seismic research or gas and oil exploration", seemed quite obscure 'til now :P
I realize it's pretty off topic but do anybody know a good site to watch new tv shows online?
@Lochlan Dominik I dunno I watch on flixportal. You can find it through google :) -duke
@Duke Fox thank you, I went there and it seems like a nice service :D I appreciate it !!
@Lochlan Dominik no problem =)
Your method is basically an higher-tech version of the old trick of taking the two clocks, plugging them into the two axes of an X-Y scope, and timing how long it takes the eye to "wink" (every 180-degree change in phase is half a cycle slipped), which gives you the difference in the two frequencies.
A higher-precision way is to use a time interval counter (TIC), which basically does the same trick of using a microcontroller to count the number of ticks of a sample clock between the rising edge of one signal and the rising edge of another, but then it adds on some analog electronics to measure time less than one clock (as a simple example, imagine charging a capacitor with constant current, dumping it back to zero once per clock, and having a way to isolate it after the STOP signal comes in. Then you can discharge it at a lower constant current and "stretch" the original time interval by the ratio of the currents). That *is* a device you can buy from Agilent or whoever. Then you can plug it into a PC and run the data into an app like TimeLab and get some nice plots.
Funny to see the dramatic change of the looks of the equipment in the background compared to the current video's in 2020 !!!
I now realize that the crystal is not to be trusted. I use an esp32, using a built-in timer and the crystal, which should wake up twice in 24 hours and wait for a reset button. The crystal was drifting so much it was impossible. Changed the program, so now the esp32 wakes up every hour and checks against the internet if the time is less than an hour left, otherwise it goes back to sleep again. In one hour, the drift is so small that this works. My project is very small relation to yours but well explained and it helped. Thanks.
I may have one somewhere, I'd have to look.
In this application it's only this resultant "skew corrected" data we are interested in. As it's the maximum drift deviation over the recording period that is the concern. And it ain't as "random" as you might think, that's what makes it all very interesting. The one shown is about as "random" as you'll find, the majority are usually more sinusoidal in shape.
That's awesome you measured without buying Synchronization tester, you saved a lot of money.
I remember in one radar system, the crystal oscillator OCXO in the tracker unit required 20 minutes to stabilize. As little as the grease from the technicians fingers could change the "oven's temperature" enough to send the chassis back for repair. We needed the trackers out ASAP. So failure rates were high once the trackers got into the field.
Interesting to see the comparison between the different types of oscillator.
I think a reason that wristwatches are relatively accurate is the fact that you wear them all the time.
Therefore the temperature of the watch is kept relatively constant (near the temperature of your wrist).
Also maybe due to the fact that shocks etc are pretty random they "cancel" each other out.
this is amazing I am dropping of high-school and watching this guy so I can actually learn something
As far as I know, radioactive isotopes used for accurate time measure. May be you could use some small samples for that :)
That's mains hum through the battery charger. Normally I film on battery, but sometimes I forget and don't hear it until editing time.
Usually there is not that much temperature variation. A wrist watch is usually on your wrist and in constant contact with your skin. As such, the temperature is rather constant.
the C in TCOX stands for compensated
Get a 10MHz OX, hook a 1GHz OX via PLL to it, then compare that to a GPS signal.
the attenuation of the GPS signal that far underwater would be difficult to get around. Most GPS sensors cannot work indoors, even if you did get a signal you would then have to worry about the signal bouncing from the environment which can significantly affect its accuracy, its why in built up areas you can loose GPS position accuracy as the signal bounces of of buildings that create a canyon effect. I know that the post is quite old but it may be noteworthy to someone :D
The telco industry has spent a lot of time on this and the internal documentation on this subject at least where I worked, was good. We used TCX0's as the basic clock, there were 3 of which we took the best of 2 at any given time. The long haul communications nodes had rubidium oscillators to stabilise the long term drift of the TCXO's
OR'ing 3 oscillators is the best mean to stabilize and eliminate the radiation problem, your circuit works fine until a cosmic background microwave radiation resolve to shoot your oscillator out of phase.
Isn't the time-reference of each of these units updated perodically via GPS?
At the bottom of the sea? =)
Measuring clock stability is such an important part of the GNSS (GPS/Gallileo) system. The method involves using one master clock, which is known to be more stable than the unit under test, and to measure what is known as the Allan Deviation. The Allan Deviation provides all kinds of useful information about the performance of your clock, including what types of instabilities you're dealing with.
Dave... Very innovative method for measuring the drift over time, I am quite impressed. I guess this is the price to pay for using a natural-mineral based element for frequency control: there is some randomness thrown in for free. I wonder if it's possible to produce quartz with a reliably repeatable structure to make the drift characteristics also match very closely
you can make it fucking perfect, if it's small and get shot by radiation it will drift, whether it's completely pure or not doesn't matter. Rubidium is more precise and uses more energy because it needs more energy, from radiation's point of view it's like the difference between fighting sheldon cooper and fighting godzilla.
@sostenuto If you want to measure jitter or phase noise, your measuring equipment always has to be better than the DUT by quite a margin. The triggering on a scope may do for relatively jittery square wave sources like a CMOS VCO, but hardly for an XO. Phase noise analyzers go to great lengths in cancelling the contributions of major phase noise sources.
I suggest you check out the websites of Leif SM5BSZ and Enrico Rubiola, those might give you an idea. Also look at drift cancellation.
I know I'm late to the party. However you could use a FM ramp up signal from your boat that the hydrophones can pick up and record as well to use in post DSP
@SolutionByEvolution I was thinking exactly the same thing. If this was a generic set of time-series data, you could end up with a completely wrong result by binning. But I assume Dave knew enough about the characteristics of the drift that he knew he could get away with that technique.
I guess the input to the reset of the flip flop must be inverted since the flip flops I have seen will always be low when reset is asserted. I also guess that D is tied to Vcc. When the 96Khz signal strobes past the 8Khz marks, I guess the counter will jump from zero to 104. I guess you could programmatically create a round-robin with 104 being equivalent to -1, 103, -2 etc. Many micros have two 16 bit counters so everything could be done in the sub-30 cents STM8S103F3 which is great silicon, although takes a little more getting used to developing (Avoid STs standard libraries, use gicking stm8as.h instead... Silicon-wise ST are VERY good, software-wise ST are CLOWNS.) . Clock the STM from the rubidium source, feed DTCXO into TIM2_CLK. Software handles the rest.
fantastic video. what a classic trick. good to see it done in discrete logic chips like that to get extreme speeds. gotta feel bad for the ocean life tho
I don´t known it for digital clocks, but mechanical watches have a asymmetric tolerance: Showing a "later time" then it is actually is more likely then showing a "to earlier" time. So your excuse would not work. Expect your blame their watch.
Why didn't you maintain an average of several counts to reduce the effects of jitter instead of using a binning technique? The averaging number crunching could have been done by the PIC and the results sent to the PC to reduce interface burdens.
this vid has that vintage 2010 smell! :P
crazy how dated these old vids are looking now Dave!
I know this is an old video, but Dave, didn't you basically implement a time interval counter? We used to use TICs but ultimately switched to HP5071 cesium clocks for our project, and the TICs fell out of use. TICs are definitely test equipment you can buy "off the shelf" :-)
@Films4You It shouldn't. It is does it's pure luck. Regular watch crystals are usually only accurate to maybe 10-15sec/month.
Hi Dave, do you know if jitter in PLL's and xtal oscillators can be measured without expensive instruments, like with a scope, and how?
at 13:55 some kind of background hum disappeared and it was much more pleasant!
If you math out all simple temperature correlated stuff bei DTC (and do it right) then you have an output with artefacts which is not temperature correlated (or at least shows just remaining artefacts beyound your algorith).
Anyway: Wouldn't it have been an option to resync the probes sitting on the bottom of the ocean by some radio pulse (low frequency... deep water.. long antenna rods) just before the actual acousting ping takes place?
ok so tell me this does for example my SOC in phones frequesncy drift? if it does it explain me why half of the phones start to lang dramatically despite software issues. also why not simply use a cheap XO sinc it with gps every some time and compensate a drift? wouldnt that be mutch easyer solution since GPS is like an external constant for all of those devices?
Unless the satellite drifts ;)
Dazzwidd
thanks
I don't understand that aswell. If a phone has gps, why doesn't sync it up from time to time automatically? Maybe they do, by the way.
GPS is hard to get a signal for under water
Could this be utilized for smooth irregular tempo in music, making it a breeze for remixing music?
really inventive dave
I have few questions:
1) Do you measured how many 96KHz positive triggered samples were their in 1 8KHz? There is huge possibility that you may have only 9 or 7 positive triggers in 1 8Khz clock cycle! & you may miss it depending on your sampling rate.
2) I am hoping that these calculations were done after taking out the individual data loggers(hydrophones) from the sea & you can't be sure if they follow the +ve curve or -ve curve every time. Or was their anyway that the drift in clock was in same direction or what was the way in which you concluded that?
3) Was it really worth it? As i am assuming knowing the final drift & drawing a linear curve can also do the job more or less consistently if the data is logged at pretty big sample rate so that some minor deviations can be ruled out in between individual oscillators! What was the data logging rate for the hydrophones?
Hi Dave, EE here.. This is interesting. I've done crystal osc design; in the 1-5 ppm range and didn't have to pay much attention to drift.
...
Help me understand the "quadrants". Are these simply count ranges? Such as 0-25 then 26-50, then 51-75, then 76-100 ? I imagine you selected these quadrants based on the typical short term stability of the osc, no?.
...
- Were these off the shelf oscillator modules or did you put crystals in your own oscillator?
- What was the basic stability spec on the oscillators?
- Was there any TC done, or is the ocean floor a constant temp?
- Were the oscillators pre-aged, or selected for cut angle?
...
- Which logic family did you use for the counter? Jitter can be introduced there and was that part of your 'quadrant' size choice?
...
- I was always told that the long term drift was due to mechanical part aging and 'work-in'. so it was more asymptotic. So, does this simply give you the characteristics that you then assume continues in the field with the same period/frequency - centered along the linear average?
...
- Was the time period of use short enough so the short term average was assumed approx. linear rather than worrying about the asymptotic curve?
...
--
Cheers, Steve
Not sure if I understand how the compensation is applied.
...
I don't understand if this is individual compensation or just getting the characteristics of the family. If it is for a family of oscillators were they all selected from one run from the manuf?.
...
Is the maximum drift from the linear within the requirement so you don't need to track the individual (sine) variations, only take out the linear component as long as the short term variations are within the required?
--
Cheers
ok i see you called them DTCs.
Let's say I have a DTCXO chip Maxim DS3231 and a GPS time reference u-blox 6010 with pps output. How do I calibrate my DS3231 against the GPS?
Now we need to see this test series done with DDS...
Amazing video! Thanks Dave!
Could pressure, humidity and other environmental factors influence this stability?
Why not keep them in relative sync by broadcasting a standard pulse from a known location. Control for ocean conditions by transmitting a pulse from a standard location on the ocean floor and the relative difference should be consistent throughout your experiment and can be used to compensate for drift for each oscillator. Enough standard pulses and you can compensate for non linear and even non monotonic drift effects.
dorbie from what I've read, getting any kind of radio signal to the ocean floor is quite nearly impossible.
+Ryan It wouldn't have to be radio waves. Acoustic would make the most sense.
+gblargg The speed of sound through water is not constant. It depends on temperature and pressure along the way from transducer to receiver.
NatureAndTech Yes but the relevance of that depends on the frequency of your data collection.
+NatureAndTech nop, i can sinchronize with the pulse i received then exactly 1s later send my id to the base station and they will know exactly the latency and send back the timing adjustment with the id of the receiver calibrated. Btw, there's nothing magical about sonar data transmission at low speed, except the limited bandwidth. Theoretically you can use transducers to dial up an internet connection to an island, but no one else can do this at the same time because you've got "only one pipe" for the signal to flow.
Very interesting stuff! You make me further wish I could afford my EE degree without putting myself in massive amount of dept...
Hi Dave. Just curious; how many oscillators did you use for these measurements?
I think I would just have stuck a Rubidium Oscillator in it and check it periodically (e.g. every day) where the offset can be reasonably linearly approximated. Assume the Rubidum takes 20W and takes 30 Minutes to warm up and lock. That would be 18kJ or 10Wh per day, so 900Wh, 1.62MJ over the period of operation of 90 days. About the energy of two car batteries. Much but still tolerable in such an application.
If I am assuming correctly this looks similar to a project done by Shlumburger in the North Sea some years back. The sensors were hundreds and deployed by attaching them to underwater cables. There were something like underwater planes which took care of guiding these cables through the currents so that the cables are equally spaced and did not get entangled by the North Sea currents. Pretty exciting engineering challenge!!
If this was the project Dave is referring to, attaching hundreds of lead acid batteries to the underwater cables would have been impossible.
you didn't understand, they need to lock the timers of that shit between multiple data collectors, fuck, if gps can do it why not use the exact same system but with ultrasound? they're both based on timings and tridimensional waves.
plus they are based on the propagation speed. The propagation speed of sound under water changes with pressure, water temperature, the density of the water and there is doppler shift from the water currents.
why not have a master clock on the surface send out a ping to all the individual
modules through the water periodically, so when the data is gathered at the end of the experiment the pings along with the data can be realigned through time stretching? then the clocks can drift all they like. : )
Some major muddlement around difference between 'compensated' and 'controlled' I think!
Do these oscillators drift the same each time?
You better talk with PTP GM vendors about drift clock.
How can i replace my motherboard's oscillator? Jitter is killing my experience on games and music. I can't take it anymore
is this a joke?
Change motherboard, choose a higher quality one in the server stuff.
Even the most expensive motherboard on the market has crap oscillator.
Trust me José, what you're experiencing is not related to the oscillator. In my long carreer of computer engineer, I've built more than a hundred PC and I only met once a crappy oscillator, it was impossible to get a sharp picture with a PCI TV card. It only happened once. Your problem is more likely system and general hardware related. For example, if you encounter jitter while your software is accessing your harddrive, obviously it's not oscillator related. Remember the PC is at start a business machine and wasn't met for high precision timing and music. You can circumvent many timing problems by using a real time OS, an OS were kernel reaction time is known and constant. Hint : windows is not one of them.
But as far as i'm concerned the OS Kernel relies on motherboard's master clock to sync the threads. Not just that, but most peripheral, including the CPU, also relies on the master clock as a base frequency. Am i wrong?
Also, i have an old SIS motherboard for Athlon XP that seems to perform smoother than recent boards. I noticed that the clock implementation on these old SIS boards is better, with more filters (capacitors) to delivery smoother power supply to oscillator. For some reason, the new hardwares can't keep the timigs right. But i don't know, im just a curious guy looking for some answers.
Would drift be why my laptops base clock has gotten more and more unstable and inaccurate over time? Base Clock flies all over the place now, fluctuating between 96 and 104 mhz.
Wow, I am surprised that they would drift this much. I have a new excuse for being late.
Love your video's, due you have a a basic electronics series. Thank you
Feels like a job for I Q encoding somehow... possible to just derive amplitude and relative phase via multiplicative means? Nice job tho
if a clock drifts by 20 seconds a day i'd eat my hat, i'd expect that from a mechanical escapement (a real good one at that)...
i've made picaxe based clocks using analogue clock tickers before which maybe lose maybe a few seconds a day. and a binary watch which i think gains less than a second a day using a 32.768 Xtal from a fax, and i usually set it to internet time regularly
I bet with enough time the drift would generally oscillate back and forth like a full sinusoid.
He is 15 minutes in the 24 minute long video when reaching the actual subject for the first time!
I know it's Dave's thing to go about this stuff totally unscripted, that he's done it for ages and thus my lowly rant here won't achieve anything, but since it's my thing to bitch about it I'll do it anyway.
While I do find the info about seismic activity monitoring rather interesting, it is heavily irrelevant to the actual subject. Even if it presents a (single) use case for it, it becomes a distraction rather than serving the purpose of educating people about electronics.
Anyone else finding this frustrating? I totally appreciate a lot of Dave's audience simply enjoy his random blabber, but since it's become such a big channel and shows a lot in the search results, there must be other's like me who keep ending up here while actually trying to learn about electronics.
Again as I said it's Dave's thing and I'm 100% backing his right to do anything he wishes on his own channel which, simply looking at the numbers, is clearly working but at least I got it out of my system for a bit.
Also, I AM thankful for the vast information internet is bringing to my reach free of charge but the vastness tends to make it equally hard to reach as if it was scarce. UA-cam's main goals is to distract you and it happens easily and even if you maintain your focus, it takes unreasonable amount of time to wallow through stuff like seismic activity monitoring to gain knowledge that could just as easily be delivered in less than 5 minutes.
I might just be stupid and unable to grasp these complex concepts, but I don't even get the 3rd row in the first chart on the whiteboard. I bet planning things ahead would save at least an equal amount of effort in editing the videos and correcting the human errors that could be at least more easily avoided with a bit more patience in advance.
then you would have either integrate a diving drive on the probe to submerge back each hour. Or you take a several hundred/thousand feet long cable with a gps dinghi at the end ;-)
I'm confused here. Dave states that rubidium clocks simply consume too much power to be used in the ocean floor sensors. Then he show's a circuit directly using a rubidium reference clock to determine whether or not the chosen crystals are drifting. So I'm going to assume that this was done on the surface in the lab. Dave also mentions that there were hundreds of these ocean floor sensors, so I'm guessing these month long tests were performed on hundreds of units? That sounds a bit impractical. Then what? For each of the several hundred crystals you create a drift profile then presume when you turn it on a few weeks or months later at the bottom of the ocean at 3 degrees Celsius that it will follow that same profile you measured in the lab. Then when you collect the data you correct for your lab measured drift. That seems a bit crazy to me, there is no way that's accurate. What am I missing. It seems the best you can do here is simply say "we will have X maximum error in our results", but I don't see how anything can be "corrected" for after the fact.
The rubidium oscillator was used in the lab to calibrate the error-correction circuits. It was not used on the final product.
If you listened to the whole presentation, the Rb clock was used in a lab setting (constant temp, no vibe,etc) to characterize the drift over time of several samples. This in turn was used to construct a maximum drift over time characteristic. That characteristic was then applied to all other drift and error sources to determine if the oscillators selected would fulfill the customer requirements.
This was not used to calibrate each oscillator, only to determine the normal characteristics of the family. The story/talk/tutorial was more about determining a characteristic of a component, not calibrating.
Fascinating topic.
Sir, is there a relation with crystal oscillator drift in computers ?
stop using sir
of course there is a relation
I had a regular quartz watch i set to my school clock at the beginning of the year, so that i could know the second the bell rings (rings for 5 seconds from :55 - :00).
By the end of the school year, 8 months i think, it was still accurate to the second. I specifically looked for a drift, but found none. O_O
Can a crystal ocilator switch a mosfet on and off? :P
Thanks for the video
funny way to explain things but specifically for the topic of Oscillators unfortunately wrong explanations on the terminology for a TCXO and DTCXO was used… A TCXO is not a temperature Controlled Oscillator but just a temperature Compensated Oscillator… similar like DTCXO. It is again just a temperature compensated product but using a more complex compensation using a microprocessor.
haha I realized while watching about halfway through this video how much you look like a space alien teaching technology
great vid man
arnt you just comparing drift to an also drifting clock? is there a way to compare two clocks in a reversal type way to get a true time? something like a vernier clock system?
It probably doesn't need to be that precise. The Rb drift was insignificant.
you could have used two oscillators together with an or, then every time it flips you know it's drifting, you can compensate and get half the precision error, with 3 oscillators you'd get 8 times the precision or more, since you can compare two and adjust the third.
Use nasa's solution, if you have more than one you get exponentially less problems.
consensus over time is much better.
radiation is the primary problem with oscillators, if you get two clocks agreeing that the third has drifted you know it was probably shot by cosmic background radiation and elevated to a higher energy state, resulting in out of phase oscillation. Nasa had almost the exact same problem with memory, when radiation hit the memory turning 0's in to 1's and vice versa.
I don't think cosmic radiation is a problem taking deep sea measurements.
Yes, consensus vote is good for detecting defective devices and ignoring them.
But with drift it's different - every oscillator drifts over time - you would have to physically compensate the drift of the detected oscillator i.e. with temperature in a servo loop and that for each oscillator.
The beauty of compensating for the drift in post-processing is its simplicity.
What do you mean by "reset" by shock? --
wish I found you earlier
What is meant by the quadrants here
Great video, thanks!
cool video
Because you wear it on your wrist, so it's temperature regulated by your own body ;)
Love it!
Why get a super oscillator when you can have an atom clock for free?
Glonas, Galileo or GPS deliver it right to your door (unless that is inside) it is good to the ns.
GPS receivers must be dead cheap, I have four and I am rather poor.
GPS doesn't work at the bottom of the ocean, the radio signals are far too weak to penetrate more than a few metres of water.
Croz89 mind you power efficiency would be at a minimum as well. As Dave mentioned, the drift is something you roughly measure before hand and compensate later on in software after the data has been collected.
Croz89 mind you power efficiency would be at a minimum as well. As Dave mentioned, the drift is something you roughly measure before hand and compensate later on in software after the data has been collected.
didnt you say you couldnt use a RbXO because of it's high power consumption? and then you were using it as a reference. oO
If I get it right, Dave used RbXO in post processing, this oscillator was not actually used in described underwater modules...
JohannaMueller57 The RbXO was only used to characterise the drift prior to deployment of the UWMs. The results of this characterisation could potentially be used to correct the TCXO drift during post processing though I think the guy said that the worst case drift was found to be within tolerance for the application.
+billiepipersteeth radiation compensation is the problem, everything runs smooth until your oscillator gets hit by the energy of a bullet in a needle tip coming from a supernova or solar flares or even cosmic background radiation. No wonder rubidium oscillators are more stable, they have a lot of mass and each cycle of the oscillation consumes much more energy, from the perspective of the radiation it's like comparing a fight between you and sheldon cooper and a fight between you and godzilla.
how stupid could a comment be... they used a pc for logging which had to be in the capsule as well, right???
Hey hi master
13 years ago lol
cant you just use 1 MCU instead of all that to test the drift? if you use high precision 10MHz MCU clock and timers/counters and interupts inside of MCU. Then you dont need your external triger and counter, witch give you parasitic delays. At least thats my opinion.
And now, you have a rubidium lol =D
I like this guy but sometimes it hard to know if hes being sarcastic or not :P
lol @ "for technical reasons that aren't really important"
glub glub glub glub, hydrophone
Daata pls... dada is your mum's fellow. Brick !!! Drift is dependent on each individual silicon quartz grown crystal, hence you cannot define a standard drift rate. OK... back to mindless UA-cam :) ( This looks good on paper, btw )
sandspar I'm a statistician and it's correctly, to us, pronounced either way. You cultural mileage varies...
No offense, sorry. I am a technician who works with engineers, scientists, and physicists. I have been well inundated ( beaten about the head ! ) with the community standard for the thing that makes my paycheck. I make Quartz Oscillators www.microsemi.com/products/timing-synchronization-systems/time-frequency-references/quartz-frequency-references/1000c-ultra-high-performance-crystal-oscillator and am the lowest rung of knowledge in the field, so no pretense to a judge, just parroting what I live by everyday, globally. I admire your work and wish you only the best. Thanks for posting ( what I should have said originally, must've had a bad corporate day; Edison is somewhat of a prick! )
sandspar no worries! Just pointing out that either way is commonly accepted....although I use your suggestion myself!
Did you know that Rhonda Rousey's mother is a PhD Statistician? She calculated which one of her kids could take her experience and make it work! Rhonda made a lot of $$, so there must be something to your discipline! Shake 'em out, see which way they fall!
actually you kinda can, you can OR 3 oscillators and use the consensus of two or more of them to recalibrate the faulty one, drift is a radiation problem, you can't blame the tiny crystals for being shot by radiation coming from who knows where, rubidium is more precise because it need a fucking 2 orders of magnitude the quanta charge of quartz to oscillate, wich means that a radiation shot at a rubidium oscillator is an almost insignificant disturbance.
I cant follow his eyes and mouth..
try to talk with a deeper voice
it's hurting my ears, literally
Low pass filters.
Michael Misch
You wouldn't hear anything then.
pitchshift