Re: [time-nuts] WWVB Chronverter update progress
paul swed writes: > Hello to the group its time for a wwvb chronverter update. I used the loop > antenna as Alex suggested. I added caps to resonate it sort of. I am still a bit puzzled by this desire to feed the time in via LF waves. Maybe WWVB clocks are more different from the MSF / DCF77 ones I see around here than I thought. All of the ones I've looked at had a small (but not tiny) module in them which does all the decoding and the clock itself really only sees the decoded bits. The module typically is only enabled around the update hour (mostly 4am, sometimes 2am) and switched off for the rest of the day (unless they couldn't sync in the about 15 minutes they usually keep trying). So if you really wanted to wean these off their LF source, it would be much easier to just send the time out via some ISM band (433MHz or 868MHz / 915MHz as appropriate for your location) and replace the module with a different one that provides the decoded bits these clocks expect, just from a different source. Both the RX modules (actually I see only TX/RX combos at the usual suspects) and the corresponding antennas (ceramic strip, helix or coil) should fit nicely in the space formerly used up by the RX module and the ferrite rod. You'd need another microC to convert the data or use one of the modules that are programmable. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] WWVB Chronverter update progress
paul swed writes: > Indeed anything could be used if you want to modify the clocks. I > don't. Fair enough. > They do what they do very well and consume 0 power. Well, I assume there's some sort of battery involved, but anyway, this line of discussion misses the point. Replacing one LF module with another HF module, both powered on for a maximum of half an hour a day shouldn't make much of a difference (as long as you do not use the transmit function of the module, which I can see uses for given the fact that there's nearly always a thermometer and hygrometer in these clocks). > Can be placed in any location in the house or garage and even the basement. > Interestingly without the real wwvb I can orient them any way I want > also. That's some indication that your transmitter may have more power or your general reception of the real WWVB is better than you think. The null on a ferrite rod is pretty steep, so finding no orientation where it stops working seems strange. I have had to open a number of my clocks specifically to reorient the ferrite so I could place them where I wanted. The only clock that didn't have that problem turned out to employ two modules with their antennas at 90° at the opposite sides of the case. Anyway, you don't want to modify the clock and I don't particularly want to build something that might be illegal if anybody can detect and complain about it, even when that chance is very small. > The last thing I want to do is hack them. But like you say if you are > willing to hack a set of 3 wires will do very well. Or just leave them > powered all the time. Many options. Actually, one of the reasons I even brought it up was that many years ago I needed a bunch of clocks driven from a master clock so they'd all show the same time synchronized to the sub-second and they needed to be readable from a fair distance, so their display had to be large. That was for a recording studio, so the electromechanical clocks were out due to the racket they make. The cheapest solution was in fact to have the master clock put DCF77 bits on a telephone wire and then run that into a set of DCF clocks with the biggest LCD that we could find. I didn't even remove the modules, they just never got their enable signal after the modification. The other bit to know about these clocks was that they had slide switches instead of todays typical buttons to set their modes and that meant you could put them into a continous reception mode easily. > But many on time-nuts have these clocks and should wwvb be turned off its > nice to know my weather stations will keep working and have the right time > and far more accurately then my mobile phone. That's why I was curious about their inner workings and if they might be much different than what I know from my side of the pond. > Last comment. Its a time nuts challenge just have to tinker and share. I wasn't commenting about the usefulness of the approach or your (or anyone elses) intentions or anything of that sort. I had hoped it was obvious that this omission was not meant as a back-handed critique, I just had nothing to add to the information that was already shared. But you seem to be offended nonetheless (ever-so-slightly), so I apologize. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Troubleshooting an HP 58503A
Matthew D'Asaro writes: > The concrete block is a generic 1 sqft paver stone which cost all > of $1.18. This is to provide a heavy base and avoid tipping. If you want to keep your roof undamaged, you need padding under that concrete block (some geotextile sheet plus perhaps a bit of rubber mat like they use for playgrounds) or it will cut through the roofing sheet over time. > It is sitting on the back railing of the house for now but I > ordered a 40' length of LMR-250 cable with N-connectors on both ends > from http://www.usacoax.com/ and once that comes I can set it up for > real on the roof with the cable running into my lab. Over and out. You'll want to have a good think about lightning protection before you run that cable near anything that enters your house. You should also check that the grounding of your electrical installation is properly done. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Noise of digital frequency circuits
Attila Kinali writes: > Yes. This effect has been known for a few decades at least. What kind > of puzzles me is, that I have not seen a mathematically sound > explanation of it, so far. I'm afraid I can't help with the rigor, but the fundamentals seem simple enough to me. > People talk of aliasing and sampling, but do not describe where the > sampling happens in the first place. After all, it's a > time-continuous system and as such, there is no sampling. That may be quibbling over terminology and definitions not actually specified in those papers. Localization in the frequency domain requires periodicity in the time domain (by definition) and moving spectral features around can be done by convolution of the noise spectrum with a localized signal (not necessarily of compact support, but assume for the moment it is so you get a clearly defined pivot frequency). That means you need to do multiplication in the time domain with something periodic, so all you need to produce noise folding is for instance a periodically varying NTF. I guess we can tick that box in all instances you've mentioned. > One could look at it as a (sub-harmonic) mixing system, but > even that analogy falls short, as there is no second input. Does it even matter if you call it a "second input"? Reading the Egan paper I guess the line of arguments that leads to "sampling", "mixing" and "aliasing" getting used is that the periodically varying NTF (or ISF if you like) looks and acts sufficiently like a Dirac comb that you can use sampling theory to interpret the results. Or conversely, that you can take the results and postulate a sampling process with a sampling aperture that happens to look virtually identical to (one period of) your NTF. This seems not much different than what gets routinely done when reasoning about real-world systems that do "proper" sampling, but of course do not sport a perfect dirac pulse sampling aperture. > It also fails at describing why there is not infinite energy being > down-mixed, as the resulting harmonic sum does not converge. The actual integral or sum to compute would likely be governed by something sinc-like, so convergence would eventually still happen with any physically realizable input. That assumes you don't already need to start with some generalization of the Fourier transform that has more strictly defined convergence behaviour. […] >> > If you divide by something that is not a power of 2, then it is important >> > that each stage produces an output waveform with a 50% duty cycle. >> > Otherwise >> > flicker noise which has been up-mixed by a previous stage, will be >> > down-mixed >> > into the signal band, increasing the close-in phase-noise. >> >> Wow, another thing I never knew. > > I do not think that anyone was aware of this. Funnily a paper I just read in TCAS-I (February 2017) by Pepe and Andreani about phase noise in harmonic oscillators seems to mention this (I think) as a known result w.r.t. flicker noise upconversion and generalize (ref. eq. 90) on previous results for several particular oscillator topologies which guarantee the necessary conditions. There is also lots of discussion about the relation to the ISF and results in conjunction with it that goes right above my head. The direction their math is taking looks intriguing, so maybe you are able to glean something from it to use. Whether there's any pre-existing link of those results specifically to frequency dividers I don't know. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Short term 10MHz source
Am 02.01.2019 um 12:49 schrieb Chris Burford: I'll give the window placement a try and see if I can maintain a usable lock. If you're using a patch or puck antenna, putting a ground plane under it can work wonders (I've seen 15dB gain in one particular case). I've been using larger cans to stick the magnetic pucks on, but a piece of aluminum foil is OK as well. If you can get hold of a datasheet for the antenna, it could have some information on how the directivity of the antenna changes with the diameter of the ground plane, which can be useful if you have problems with reflections from low angles. -- Achim. (on the road :-) ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] question about multi-way measurement
Charles Wyble wrote: > I’m using a raspberry pi with gps hat for my master time source. > Shortly I’ll be having a total of three systems (two using the same > hat, one using the adafruit hat and being a pi2). I’ve got some > interest in multiple way comparison and will follow this thread > shortly. I'd say three doesn't really get you good enough visibility. It depends somewhat on how good your GPS reception is and how stable the environment, especially temperature. At around five NTP servers with suitable precision you start to see "interesting" things like asymmetric latency in your local network and can more easily throw out the inevitable spurs from degraded GPS reception (unless you have a really good antenna location). I'd suggest you also log at least the PPS timestamps to correlate to the NTP logging. NTP peer logging will be dominated by network latency and jitter, provided you took care to tune the residual loop error to below 1µs. I'm running a Perl script that also records the CPU temperature and system utilization synchronized with the PPS. All my logging is into files at the moment, which puts some extra stress on the SD card that several no-name cards have not survived for long. I've salvaged an SSD that I plan to connect via an USB to SATA converter and then set up a proper time series database on one the boxes to feed all data into. Alternatively you could log into a tmpfs and rotate onto SD card whenever you've collected a full Flash block. I currently have seven stratum-1 NTP servers (five different rasPi and two TinkerBoard) on my LAN. I've self-ovenized six of them (the exception is the rasPi 1B+, which simply isn't powerful enought to pull that off) to keep the crystal temperature very near the turnover point of the f vs. T curve, which leaves me with just the jitter and drift of the (apparent) system frequency most of the time. The rasPi crystals (or the interrupt system on the SoC) are a bit noisy with seemingly unprovoked frequency jumps on a not too-long timescale, so that keeps you to within a 5ppb window after removing the drift. The TinkerBoard doesn't have those jumps and I keep both routinely within 1ppb of the expected drift curve. I've experimented with both low and high thermal mass designs, but so far I don't see a difference in timing performance between the two. The high-thermal mass design does smooth out the external temperature swings more effectively, so with further refinements to the oven controller it might eventually provide a usable advantage. -- Achim. (on the road :-) ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] question about multi-way measurement
Charles Wyble wrote: I built a dedicated server room in my house, with it's own air conditioner. I've been working on overall instrumentation , especially temperature. If the rasPi is a dedicated system and does not serve extra tasks, just record its CPU temperature, no extra sensor needed. The absolute temperature will be an almost constant offset from the ambient, so the changes are well preserved (except for short periods, e.g. when a cron job runs). Any temperature transient will show up in the timing error, however small. The FLL/PLL code in NTP will need to chase the changing crystal frequency and then eliminate the already accrued timing error. The faster the transient, the larger the error. So on-off aircon with forced convection is pretty close to worst case. Could you share the snippets of the PPS logging? I'm not 100% sure what you mean by the PPS timestamps. Just reading from /dev/pps0 (system time and capture timestamp in my case), really; additionally system load and CPU temperature and logging the everything into a file. Interesting. My ultimate application of this high precision timing is driving TDMA wifi links as low cost as possible. I'm not familiar with the requirements for that. I suspect that the absolute timing between stations is actually pretty unimportant. So the only thing that matters is that the relative timing error between beacons or syncs must keep below some threshold, which means the frequency offset of the system must be kept within (probably not too tight) bounds. The latter is much easier to achieve and maintain. Over wired Ethernet you can expect to synchronize a bunch of systems to within a ~200µs envelope of absolute time and maybe a factor of 2x-3x lower if you can control certain things more tightly than usual if you run those system on a single hop switched LAN that have a GPS-based stratum-1 NTP server. For anything better than that you'd need PTP, which unfortunately the rasPi is incapable of. Or do you plan to use the rasPi itself as the RX/TX? The few papers I've just looked up all use Atheros 9k hardware. -- Achim. (on the road :-) ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] new op amp for distribution amplifiers
Gerhard Hoffmann writes: > Have you seen the new THS3491 ? LMH6702 on steroids. > > This one begs to be designed into new distribution amplifiers: > > Everything from DC / 1pps to a few 100 MHz into 50 Ohms, without any > changes. While everybody is looking for opamps with even higher GBW figures… I'd think that for driving significant power into 50Ohms VDSL line drivers might actually be a better fit for output frequencies below 100MHz. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] SiT5155 GNSS/GPS VCTCXO modules
Bob kb8tq writes: > It would be nice to see an ADEV plot if indeed GPSDO use is a target market. The common datasheet for this part only seems to tabulate the phase noise specs, but the SiT5356 datasheet has actual ADEV/TDEV plots. For both series there are companion documents for the more common configurations that have more/extended plots including ADEV/TDEV. I seem to remember a whitepaper that had some more information, but I can't find it now. But here's a recent blog post that links to more documents, some of which seem to be new: https://www.sitime.com/company/news/blog/more-robust-stratum-3e-ocxo Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Good clean-up oscillators
Poul-Henning Kamp writes: > The TODO point is to take a RaspBerry Pi, run a tight loop with all > which wiggles a GPIO pin with all interrupts disabled, and measure > the phase noise. You'll quickly find out that the ARM part of the BCM SoC is not fully in command. The VC4 GPU is calling all the shots and can freeze the ARM cores whenever it feels like, which by default it does every half second to re-tune the SDRAM interface. > It's going to wander all over the place, because it comes up from > a 1 cent Xtal, but the phase noise will be from the on-chip resonator, > whatever that is. Now, _that_ you can have more easily: you can output the crystal or one of the unused PLL outputs to the GPIO header (one of the three GPIO_GCLK pins), you can use the hardware PWM to generate a lower frequency signal that is directly clocked by the crystal without any CPU intervention or you can use one of the HDMI/DSI clocks. The 19.2MHz crystal in question is made by AEL on all the boards I have (mostly from RS, but also one from element14). I haven't been able to find a datasheet online and it quite certainly isn't an AT cut. The temperature dependence is downward parabolic with the vertex around 60°C. I use the CPU to ovenize the crystal and regulate it to within 0.2K of the turnover point, which greatly reduces any load and environmental effects. All crystals have been a few ppm slow. The drift has been relatively fast and positive in the first few months, but settles to something around single digit ppb/day (almost zero drift on my oldest system). As you thought, the system clock is rather noisy, and wanders around about ±5ppb after drift elimination. All this is measured through NTP which gets steered via a PPS driven from a GPS module. I also have two TinkerBoard, those have a 24Mhz crystal for the system clock and also 5 PLL apparently. Not sure how to get any of those clocks out to GPIO and if one of them is unused like on the rasPi. The turnover point is even higher at around 70°C so you'll need to move the thermal throttling limits a bit, but then these can be ovenized with the CPU cores as well. They run around 10ppm fast and also drift positively with a very noticeable retrace if the temperature changes abruptly. But the noise (after removing drift and residual environmental influences) is under 1ppb. > If it's any good, buy a Pi-Zero, rip out the X-tal and feed it > from your LPRO instead. If you only need one GPIO pin, I doubt > the exact clock frequency matters much. I still want to use a GPS timing module and feed the 19.2MHz in from there. However, I'd rather lock the quartz from the external reference so when that input fails the quartz will at least keep the system running. It _should_ be possible to capacitively couple the reference to the board, but I haven't tried that yet. > (The BeagleBone is interesting too, since the PRU units run > autonomously at 200 MHz from their own memory, so the main > CPU could do other jobs for you.) In principle the VC4 could be used on a headless rasPi for this, however it's hard to find documentation on it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Yet another GPSDO project.
Tobias Pluess writes: > I once tried to use the internal PLL of the microcontroller to boost > the OCXO frequency to the max. 72 MHz which my microcontroller > accepts. While this would greatly increase the frequency measurement > resolution, it decreased stability because it appeared that the PLL > had some frequency modulation at its output. It's highly likely that the PLL on that micro is using a fractional divider (it probably tells you somewhere in the documentation). > I just tested different PLL multiplication factors, and according to > my tests, the stability of the PLL improves quite a bit if a power of > 2 multiplication factor is used, e.g. if the OCXO's 10MHz are > multiplied to 20 MHz or to 40 MHz. Yes, you'll have the best chances of getting the result you want with an integer ratio and for some implementations of the divider it should be either an even number or if you are really unlucky, a power of 2. In your case it might be possible to overclock the micro to 80MHz or, if even number ratios are OK, at least use 60MHz. It may be better to first divide the 10MHz down by two (the input circuit in the PLL might have a dedicated divider for doing that) and then multiply up to 60MHz or 70MHz with a ratio of 12 or 14. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Portable Time Standard
Joe Hobart writes: > Your accuracy results are impressive. I have questions: > >What manufacture or brand DS3231 do you have? There are two modules you can get easily from the usual places, prices and delivery times vary wildly. The first and larger variant used to be called ZS-042, but now generally has "DS3231" in inverse print in that spot on the PCB. These usually have the "SN" variant of the chip, but there are reports of random replacements with the "M" variant (which is a bit different when it comes to temperature compensation and has some errata to be aware of in the first revision of the chip). You should almost surely not use this variant as its shipped: they typically come with CR2032 coin cell that is not rechargeable, so you need to disable the charging circuit that is there for use with LiR2032. The charging circuit itself probably doesn't safely work with a LiR2032 either if you run with VCC at 5V (Arduino or something similar). Then there's a power indicator that is most often uselessly pulling current and pullup resistors for the I²C lines that get in the way when your bus already is terminated (most often directly by the µC these days) or you want to cascade devices on the bus, which is easy since this module has the bus lines looped through to an extra row of pads. https://components101.com/modules/ds3231-rtc-module-pinout-circuit-datasheet http://woodsgood.ca/projects/2014/10/21/the-right-rtc-battery/ The other variant can be directly plugged onto a rasPi: https://www.raspberrypi.org/forums/viewtopic.php?t=161133 I have not used these, but you can find some comments that the cell on these might need to be replaced more often than you'd like. Regards Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] statistical distribution of initial frequency error in tcxos
jimlux writes: > Here's the application: > 100 (or 1000) independent nodes (in space, as it happens) - I want to > calculate the probability that two nodes are within some delta f of > each other. Provided I get correctly what you are trying to do: perhaps it would be easier to take one of the programmable MEMS oscillators (and get a programmer or find someone who can do that for you) and just trim each of them the way you want it to. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Yet another GPSDO project.
Tobias Pluess writes: > I was reading on this list for quite a while, but still have some > questions I'd like to ask. Please forgive me my perhaps silly > questions since I am a newbie to the timenuts world :-) > > So I have built my own GPSDO. I used a low phase noise OCXO from > AXTAL, a LEA-M8T module and a small STM32F303 microcontroller. Since > this was my very first attempt in this topic, my approach was quite > basic: I used the OCXO as clock source for a free-running counter and > the rising edge of the 1PPS signal was used to sample the counter. I > then subtracted the last sampled value from the most recent one and > thus had a measure of the OCXO's frequency. Since the counter is > free-running, any frequency error should, at some point, accumulate > such that there is 1 count difference (at least I think so). Yes, but there are several wrinkles to take care of with that method. The first is that the PPS output of the GPS module has jitter that your OCXO should not try to chase. The other is that once the frequency difference becomes small enough you're having to wait a long time before you notice the frequency is still a bit off and then you don't know exactly by how much. > If there are more than 10e6 counts, my OCXO is too fast, and if there > are less than 10e6 counts I know the OCXO is too slow. So depending on > these two conditions, the value of a DAC is increased or decreased. If both the measurement and the OCXO are stable enough this will indeed work, but your problem is that you need to wait for 100ns of error to accumulate to make your next decision. So when you come very close to target frequency you will probably be in the rising portion of the ADEV for the oscillator again since your steering gets too sparse in time. > In theory, a GPSDO with this scheme should basically "lock" at some > time, however I expected that the performance wo uldn't be amazingly > good (but I wanted to see where I can get). Next step, I tested the > GPSDO. For this purpose I got an Oscilloquartz STAR4, and I let both > GPSDOs run and warm up for about a week before I did some > measurements. In my own design, I also implemented a 1PPS output (just > by dividing the 10MHz clock with timer), and I used the 1PPS of my > GPSDO and the STAR4 together with a HP 5335A time interval counter. > It was a bit disappointing to see that there is, even after a week of > warmup, still some drift visible. My own GPSDO (for sure it's not the > STAR4 :-)) appears to drift about 10ns in 10min, and I have the > impression that this is way too much. Provided the drift rate is almost constant, you'd be down to about 2e-11@1s with that figure. That's not too shabby given the simplicity of your scheme. > So I didn't even try to do some Allan Deviation measurements, I bet it > would be a nightmare. (I also made a timelapse video of the two OCXO > signals displayed on a 'scope. Nothing beautiful :-/ ) Instead I would > like to make a 2nd version. This time I would like to implement a > PLL. The reason is also that I want the 1PPS to be aligned to UTC, as > commercial GPSDOs seem to do this. And this is now the point where I > need some advice! :-) I think I will still divide the 10 MHz down to a > 1PPS signal, and then phase lock that to the 1PPS from the GPS > module. One could do this e.g. with a phase/frequency detector with > two D-flipflops, e.g. like this one: > > https://electronics.stackexchange.com/questions/301402/phase-frequency-detector-in-pll > > The signals UP and DN could then be used to steer the OCXO. A counter > could be incremented whenever an impulse comes from the UP signal, and > the very same counter could be decremented if there is an impulse from > the DN signal. However I think this is way too basic, I need a proper > loop filter. But what do I do with the phase detector signals and how > to interface them with a proper loop filter, say an FIR or even IIR > filter? the STAR4 GPSDO has an adjustable loop filter time constant, > default 200s. I want something similar, but it is currently not yet > clear how to interface a digital filter with a phase detector. > Later I would also like to add the sawtooth correction, but so far I > have not yet found out how to do that - I couldn't find out in the > uBlox manual where I can find info about the 1PPS timing. Considering you have a timing module, there are more possibilities inside that module you can use before going for external circuits. For starters, you can timestamp the PPS from the OCXO with the module itself and get a better estimate of how far off you are. Second, the module can ouptut an additional higher frequency clock that you can use for determining the phase difference to your OCXO more precisely. Last but not least, the timing modules have a frequency aiding mode where you can feed in a stable frequency to one of the EXTINT pins (I think up to 500kHz, see UBX-MGA-INI-FREQ message) and tell the module what frequency and
Re: [time-nuts] Accuracy/drift of Garmin GPS 16 HVS 1 PPS output under invalid fix conditions...
Steve Olney writes: > I think the level of precision you guys are aiming for is massive > over-kill for my application. Holding +/- 1 us over 15 minutes would > be a doddle by many means as has been mentioned by you guys. I just > wanted to know whether the basic GPS mouse PPS would stay accurate > enough to do the job for my application. The trouble is, you can't tell -- at least if all you have is a single GPS mouse. Until you try and compare to some other source of time you won't know what the firmware is doing. I have a bunch of NavSpark mini and for some of them the antenna location is bad enough that I see them getting in trouble at certain satellite constellations / wheather conditions regularly. These are not timing modules, so they need to see 4 "good" sats to get 3D fix and provide stable PPS. When they drop below that threshold, you'll see the position solution drifting and the PPS accuracy degrades almost immediately. The shift associated with the (wrong) position is almost immediate, if the bad reception continues the PPS is starting to drift further almost linearly. A typical drift rate of the PPS when losing lock is 100µs/hour (keep in mind I did shield the modules from air drafts). One or two times the GPS simply did not aquire a 3D fix again, but the PPS stopped drifting at about 5ms offset as long as they see at least one or two sats. Now, any other GPS or even the same one with a different firmware version might do a completely different thing. I wouldn't know about that either if I didn't have seven such systems scattered around my network, so I can clearly see the glitches on one of them as seen from the others. > Radio astronomy is a hobby - i.e., a source of fun - although I do > strive to maintain a level of scientific rigour to the best of my > abilities. One of the key drivers of the fun is doing things with > simple systems. I get extra pleasure in using a $20 DBTV dongle as > my pulsar receiver to achieve the detection of a pulsar glitch (AFAIK > the first time an amateur has ever done so on any pulsar). OK, that explains nicely why 1ms is your target as the USB frame jitter already introduces that much uncertainty. Now, why do you need that trigger contraption you were talking about rather than timestamping the USB frames from the SDR and keeping the computer clock in sync with NTP (you'll get to use the PPS from the GPS for that, otherwise a below-ms timing accuracy won't happen anyway)? Are you injecting a signal into the antenna as a sync? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Yet another GPSDO project.
Tobias Pluess writes: > By the way, this is the unit I built: > > https://hb9fsx.ch/wordpress/index.php/2018/11/14/my-own-gpsdo-part-i/ Nice build. Minor nit: Whatever foam you used to isolate your OCXO further is probably not SAGEX, but looks to be either cross-linked PE foam or (more likely) PU foam. Isolating the unit like that shifts down the maximum usable ambient temperature and may confuse the temperature controller if you overdo it. > I have also a homemade antenna for it, since I read somewhere that the > quadrifilar helix antennas are better than patch antennas, I made one > by myself. A choke ring antenna would perhaps be even more awesome, > but this is for a later project! That's a whole 'nother rabbit hole, search this list (and elsewhere) for "phase center". These days even the professional geodesic antennas are mostly using patches. The only Helix antennas you can still get seem to be wherever the original SAGEM have ended up getting owned. > @ Achim. Yes indeed, I encounter the problem that my measurement > resolution is only 100ns. So it takes ages until the frequency locks > and it takes longer and longer, the closer the frequency is... and I > exactly assumed what you have pointed out: perhaps my steering becomes > so sparse in time, that the OCXO's aging rate is faster. 2e-11 at 1s > is not bad, but hoped for something with e-12 or even better - I think > this should be possible, not? Yes. Even keeping everything the same as you have now, if you get better resolution on your phase difference it will imporve the performance considerably. What I was trying to tell you is that you can use the M8T to measure the phase difference to considerably better than 100ns and that you can (in addition, if your module has both EXTINT inputs available) use a divided-down frequency input to the module to more closely align its internal oscillator to your superior OCXO from the start. You can still add a TIC to go into sub-ns territory later on. > So I think I would really like to go the PLL route, I hope to achieve > faster lock time and a bonus would be that the PPS pulses derived from > my OCXO would be aligned to those of the GPS module. But how to > interface the PFD to a microcontroller and implement the loop filter > is still a mystery for me :-) You'll end up with some FLL/PLL hybrid most likely. Anyway, start with getting better PD measurements and take it from there. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Portable Time Standard
Joe Hobart writes: > I can read and write the DS3231 registers with a Raspberry Pi. Unfortunately, > the RPi kernel sends time to the RTC every 11 1/2 minutes. This time is > usually > moderately accurate, but I have measured errors of up to 0.264 second, which > is > unacceptable. That's the "11 minute mode" if you want a search term. To get rid of it you'd need to compile your own kernel (it's a compile-time option withz no run-time parameters). Only the first RTC found by the kernel should be affected, although I haven't yet confirmed this myself. I also don't know if the rasPi kernel uses the symlink from /dev/rtc (in which case you could perhaps simply point it to somewhere else) or if it picks the first RTC device that has the hctosys property set. This does not happen if the SYNC flag in the kernel timekeeping code is not set (but NTP will do that). Last but not least, if you don't use (or blacklist) the RTC driver and instead read the chip as a simple I²C device the kernel will also leave it alone. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Correcting measured PPS values with receiver sawtooth correction values
Mark Sims writes: > For all the receivers that I have tested there is only one combination > that jumps out as being the correct one. However, for the new Ublox > F9P, there are two combinations that produce virtually identical > measurements and statistics (add current sawtooth or subtract previous > sawtooth). Any ideas on how to determine which combination is the > "correct" one? I don't think that uBlox changed the defaults over their previous generation, so whatever worked for the M8 series should be applicable here. If you're using the UBX-TIM-TP message data, this always applies to the TIMEPULSE0 output following the message. The message and the measurement rate as well as the PPS frequency need to match up for this to work as expected. Now, if you want to check, I think you need to wait for a clear wraparound to appear in the sawtooth correction, which should coincide with a cycle slip on the next PPS pulse (not the previous one). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] F9T, was Re: Ublox F9P PPS output
Bob kb8tq writes: > It’s just like the other uBlox modules (and just like the F9T …) the external > input is a once a second time stamper with an 8 ns resolution (just like the > +/- 4 ns on the sawtooth ….). A minor nit: If it works as the M8 series does (which is very likely), the timestamp facility gives you the last positive and the last negative going transitions w.r.t. the configured message rate, plus the count of positive going transistions. This means you can get both higher timestamp rates by configuring a message rate of more than one per second (which does have some other implications, though) and can use (much) higher frequencies than just simply PPS (but get only the count + measurement of the last transitions). Also, if the hardware doesn't use the second EXTINT pin for something else (like power management), there actually should be two of these timestamp inputs useable. > One would *guess* they are using the same > free running / TCXO clock for both the PPS out and the timestamp coming in. It's not confirmed in any documentation that I've found, but the above characteristic hints at the timestamp facility being some counters and registers in hardware, so the system clock is the only thing that could be used for this. On a proper timing module with FTS firmware you could of course inject your own cleaned up clock to use as the timebase, plus you can use it to discipline an external frequency source. Btw, if anybody is thinking about getting the ardusimple F9P-RTK module, somewhere in their forum it is mentioned that a bug on the current board revision has the PPS output at 0.7V instead of the documented 3.3V. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Rooftop antenna and splitter
Bob kb8tq writes: > The first one is designed to mount on a ground plane (which is fine if it is > going > on a truck or airplane). It also is a bit low in gain for what I *think* the > F9 is looking > for. The only antenna that u-Blox themselves advertise for use with the (eval) F9P module is an unassuming 28dB gain puck (ANN-MB, not seen it anywhere for sale so far). So I don't think that the gain matters very much for this module unless you have to compensate for distribution losses, at which point you'll probably end up with the more typical 35…41db gain figures for fiyed installation antennas. Interestingly enough the antenna is mentioned in a comparison with two other multi-band patch antennas here: https://www.ardusimple.com/ardusimples-oem-antenna-vs-u-blox-tallysman/ You can apparently buy one from their store, with or without an accompanying F9P RTK-module. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Rooftop antenna and splitter
Hal Murray writes: > kb8tq-wyfad0z3...@public.gmane.org said: >> The first one is designed to mount on a ground plane (which is fine if it is >> going on a truck or airplane). > > How big a ground plane do they need? I'm thinking of a sheet of aluminum. Typically if they already have a ground plane mounted it's between 6cm…10cm in diameter (or side length if quadratic). Over that size you shouldn't see much effect anymore on the antenna sensitivity pattern, below that size you sometimes get a slight uplifting of the elevation response. I typically use the lid of a large enough can if I quickly need a circular ground plane, but a piece of aluminum foil just almost as well, too (wrap it around a piece of cardboard or plywood if you need structural stability). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Rooftop antenna and splitter
Denny Page via time-nuts writes: > Thanks Mark. For the cost, this seems like a worthwhile thing to > try. I don’t think the homeowners association would be too thrilled > about a pizza pan on a pole so I’ll probably have to do without. Use a resonant ground plane with four or eight tuned radials instead, that also has the advantage of way lower wind load… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Si5451B (was: Good clean-up oscillators)
Achim Gratz writes: >> If it's any good, buy a Pi-Zero, rip out the X-tal and feed it >> from your LPRO instead. If you only need one GPIO pin, I doubt >> the exact clock frequency matters much. > > I still want to use a GPS timing module and feed the 19.2MHz in from > there. However, I'd rather lock the quartz from the external reference > so when that input fails the quartz will at least keep the system > running. It _should_ be possible to capacitively couple the reference > to the board, but I haven't tried that yet. Towards that end, I found a small nice looking breakout board with an Si5351B for around $35 (you get to solder the SMA and headers on yourself, the SMD stuff is already done). Replacing the XO with a cheap OCXO would add another $35 it seems and I should be able to feed all rasPi and Tinkerboard with something a lot more stable. Has anybody worked with that chip before and can share some experiences? I'm also looking into getting one of my Spartan-6 boards to function as a TIC. Using ISERDES and overclocking a bit beyond the datasheet values should get me to 1ns resolution without any interpolation and at least the Atlys board has enough LVDS pairs to monitor all of my systems in parallel. Maybe I can even do some interpolation to go to somewhere in the 50…100ps resolution, although I don#t really think it'll give me much of an advantage for this application. For various reasons it seems preferable to move the signals around via LVDS instead of CMOS, so if anybody can share some experiences of which of the many single-ended to differential converters are useful and which ones to avoid (if any) would be helpful. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Si5351B
[typo in subject corrected] John Ackermann N8UR writes: > On 2/3/19 11:48 AM, Achim Gratz wrote: > I've been playing with the SiLabs 53xx series chips. There are two > that are quite interesting for time-nuts. I am really trying to go for the octal output parts. :-) I'd rather use the Si5351C since that one has a designated reference input, but the boards I'm looking at only come with the B part. Judging from the photos, these are factory pre-programmed to god knows what function, so my guess is that these are left-overs from some production run. Anyway, no later than I figured out that the "C" part would be the ideal one for me I found this: https://www.jackenhack.com/ntp-server-extreme-accuracy-for-under-200/ Actually I had looked at the article before, but didn't remember it. Anyway, this is almost exactly what I'm planning to do, except I plan to run off a OCXO at least initially and I don't want to remove the crystal. Feeding from a GPS timing module is in the cards, of course. For my application I don't really need outstanding noise performance, as the resulting clocks are used to run an SBC from, which in turn will run an NTP server. The SBC will create a lot more timing uncertainty than the difference between a good and a very good reference, I think. Anyway, I plan to use even divisors, so that should get me relatively good performance all the way to the output. The part has been used quite a lot for amateur radio, so I've also found a good deal of real-world data to look through. > The 5340/41 are pretty good, though there's a tradeoff in using them -- > with a good reference you can get decent close-in noise, but the noise > floor sucks. Using a cheap 48 MHz crystal you can get a pretty good > noise floor but the close in noise and ADEV suck. That's the first of your plots, right? That looks … interesting. Do you know were this behaviour originates? > The 5342/44/45 chips add an additional PLL using a cheap 48 MHz > crystal as a clean-up stage. It gives performance that's sort of like > the best of both 5340 reference options. These chips also allow you > to adjust the PLL bandwidth, though you can't get as narrow as our > applications might want. > > Attached are some PN plots at 144 MHz with both the 5340 and 5342, and > a few others for good measure. > > To decode the abbreviations for the reference oscillators, "XO" is the > cheap 48 MHz crystal on the evaluation board, "PP" is a PulsePuppy > board with a $20 eBay Isotemp 10 MHz OCXO, and "ULN" is an expensive > Wenzel Ultra Low Noise oscillator. All the external oscillators gave > similar noise performance, establishing that you don't need a > super-clean reference to drive these chips. > > I don't have plots to show it, but a higher frequency reference seems > to have a significant impact on the noise floor -- if you can provide > a 50 MHz source with decent PN, the 5342 will be quite a bit quieter > than with a 10 MHz reference. The Si5351 needs something between 25MHz and 27MHz as reference. I'm currently mulling if it's worth the risk going slightly lower, as there are nice and cheap OCXO at 24.576MHz I could actually buy, whereas my options at the actual range boil down to just a single unit (I've only looked at two distributors, though). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Cloudflare
Tim Shoppa writes: > I have been observing time.cloudflare.com latency and accuracy the past 3 > days. >From my home network it is actually pretty bad compared to some other servers. It's likely the network and not the server, though. > It is a stratum 3 server, so folks might think that it's not as good as a > Stratum 1 or Stratum 2. > > BUT... it has exceptionally low latency and it seems very likely it's > Stratum 3 because it is fed by a well-maintained set of highly redundant > sources. The NTP stratum hierarchy is not a bad idea but really no end-user > has any actual need to hook up to a real Stratum 1 and would almost always > be better suited to choose a lower stratum server fed with a highly curated > list of good Stratum 1/2's. The thing is that you can't really know that, since getting permission to use a particular NTP server by writing an email or even a snail mail has been falling out of favor. And even if you do know there's an awful lot of stuff going on with the routing these days that neither you nor the other end has any control over. > It seems possible given cloudflare's diverse geographic servers, that folks > will get directed to a nearby low-latency server every time they resolve > the name. That's the idea, yes. I actually get a pretty short route (in number of network hops), but latency should be about half what I'm getting considering the geographical distance. It's one particular intermediate link that adds most of that latency. Also there is extra asymmetry on top of what my VDSL line produces normally. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Rooftop antenna and splitter
Denny Page via time-nuts writes: > No, no ground plane. Don’t really have a lot of room for that in the > window. Out of curiosity, how large of an impact have you found with a > ground plane? As long as we're talking ceramic patch (puck) antennas, I've seen around 15dB improvement repeatedly (as reported by the receiver statistics) with otherwise non-optimal placement of the antenna (indoors, viewing the sky through a wooden roof covered with rolled roofing). As mentioned elsewhere in the thread, the better antennas come with their own (optimized) ground plane if they need one. Good luck finding data sheets for the puck antennas, but if you do get hold of one, sometimes they do show how the directivity changes with different sized ground planes. If you have a magnetic puck you best use a magnetic steel surface, the cap of a large diameter can works quite well also. Otherwise aluminum foil is just as effective and easily cut or folded away if you want to try to exclude reflections. With multiple active patch antennas going to different receivers, I've found that at least the antennas I have do not like to be placed very close to each other. Spacing them at least half a wavelength from each other seems to take care of that. If the backside shield of the active patch antenna is connected to ground, then the ground plane must be isolated from all (but possibly one) antenna; otherwise the resulting ground loop will degrade reception. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Neural net to control oven temperature ?
Glen English VK1XX writes: > Has anyone tried to use a Neural net to control oven tmep, rather than > the ye olde PID ? If you believe the marketing, that is why the Nest thermostat is connected to the cloud. > IE the algorithm learns from previous beheviour and successfully > predicts behaviour (or not). This part is (unsupervised) learning, not control. Depending on how much knowledge you bake into the neural network about the system, you either need to learn just the system parameters (say the PID constants) of a fixed system or figure out the system structure itself, the latter part is called system identification. Unless you expect the system to change over time it is usually (much) more practical to stop the learning at some point and just run the system with the best model available so far. Incidentally that is one reason why different hardware for neural network acceleration exists: the network for learning is usually much more complex and needs higher precision than the network running the extracted model. If you need to keep learning after the initial training (and if it has to be online learning rather than periodic offline re-training), the learning rate often has to be reduced significantly in order for the control to stay inside reasonable bounds. > I'm sure there are a few out there proficient with machine learning > algorithms. Neural networks are best applied to sparse, low-dimensional signals embedded in high-dimensional spaces. Oven temperature control doesn't fit that description, so more traditional methods are likely more efficient. > Might make a good masters thesis I bet. Maybe so, but there are probably sexier topics around for a master-to-be to pick up. > Given that oven control based on inputs and whatever is not random, > unlike say flicker etc. Randomness actually helps in many learning tasks. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Advantages of GNSS ???
Leo Bodnar writes: > Correction on all Ublox receivers including F9P is done at navigation > rate which can be set as high as 20Hz. If you are thinking of the sawtooth correction, then I think you'll find that this is only available for the full second. There is some mumbling in the manual that the timing firmware would really like you to only calculate one solution per second for best performance. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] E1938A source code/ firmware
Glen English VK1XX writes: > My intention is to use the average of multiple stationary mode GPS > 1PPS signals to drive a single OCXO, the idea to be a better 1pps > estimate. I'll upsample the inputs to get the control sample rate up. I'd expect a lot of correlation among multiple GPS receivers, especially when they're fed from the same antenna and are otherwise sharing the same environment. Averaging will only deal with the non-correlated errors in the signal. > Eventually I want to explore the use multiple OCXOs, but not until I > think of a good way to take an average of multiple OCXOs, or, even if > that is a useful idea. I think you'll have trouble isolating these well enough to not (at least occasionally) injection lock on each other. > FPGA based, I'll put the OCXO drive and the 1ppS to the FPGA > differentially into maybe 8 FPGA inputs (that is each signal into 8 > different FPGA pin pairs) , and use IDELAY blocks to delay the 8 > different inputs to provide more edge resolution for each signal. There are a few recent papers on that topic and the IDELAY blocks are indeed used in some of these. Getting them to track over voltage and temperature is apparently a problem, so different methods of implementing the TDC seem to be more useful depending on how far down you want to push the resolution. > The IDELAY blocks can be dynamic but I'll probably use then > fixed. output of the FPGA can be sigma-delta converter, which can > provide almost arbritary number of bits. LVDS output of the 1 bit FPGA > converter signal will go to an outboard LVDS buffer with its own power > supply so bumps on FPGA VCCIO dont affect the output. Getting the residual noise down on that signal will still be a challenge, so you might want to (optionally) consider a proper DAC there depending on how good an OCXO you intend to use. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Precision Time Protocol – Windows 10 implementation
Adam Kumiszcza writes: > After all your tips I just checked whether the roof itself blocks the > signal or not. I put the patch antenna together with a metal disk on top of > a high wardrobe, close to ceiling, and I guess it is the best position > here. See attached screenshots. Good, that looks more sensible. > Unfortunately, I will have to move this ntp server to another location (or > make another one and leave this one here). It will not have access to south > facing window there, only west is possible. Since the GPS antennas have a built-in LNA, you can extend the cable quite a bit if you use something that's not too lossy without impacting the performance much. The captive cable on these antennas is almost always the cheapest thing that will work (RG-174 mostly), so I tend to buy them with the shortest option on offer, then extend with H195 or LMR400 coax depending on required length and how much space is available for running the cable. You need to be careful when specifying the connectors, the GPS antennas are plain SMA (not RP-SMA) and many of the cables you'll find are for WLAN extension (which mainly uses RP-SMA). If you need a pair of extensions, look for twin-coax; you can easily separate the two individual cables and it's usually cheaper than getting two single cables of the same make and length. Your other option is running the rasPi headless from a PoE segment, then you can move it with the antenna relatively easily. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Precision Time Protocol – Windows 10 implementation
Adam Kumiszcza writes: > I've made a ca. 10.5 cm metal disc cut from an old car radio chasis and put > it under my gps antenna. It does not hang now, but lays on the window sill, > facing up. That way you changed three variables in one go. You'd be better off changing one single thing each time so you can see what changes cause which results. You do have a patch antenna (rectangular flat shape), not a quadrifilar helix, do you? > I cannot see any difference between these positions. I've made 10 > measurement for each position, getting 12 SNR values for satellites for > each measurement and then calculated the average of these. Looking at your gpsmon pictures you seem to see the low elevation sats at very similar SNR as (most) high elevation ones. Any RF reflecting things around in your neighbourhood? Also, as David already mentioned, thermo-pane windows are actually damping RF quite significantly and even reflect them at low incidence angles. You might try a few minutes with an open window and otherwise unchanged antenna location to see what happens. > Hanging antenna had 25.18 SNR average (2.21 standard deviation). Antenna on > a ground plane had 26.10 SNR average (2.08 standard deviation). The constellation providing your fix (four satellites minimum) should probably all be well over 30dB, peaking in the mid 40dB SNR range. > If I take into account single high elevation satellite with good SNR > (satellite 26 in the examples), the new placement and ground plane even > lowered it :( You may have to experiment with antenna position a bit more. I have seen more than 15dB changes from rather small changes in antenna placement. It's definitely worth experimenting a bit to find one that is good over the full cycle of the GPS constellation. > I guess the real benefit of the ground plane would be if the antenna was > outside, or my measurement method was wrong? No, the ground plane (if your antenna needs one, not all do) is there to improve the gain in the forward direction and make the elevation pattern more uniform. Outside oir inside doesn't matter, but antennas are influenced by many things in their near-field region (at around 1.5GHz, a few wavelengths at most, so ~30…50cm). Again, you may be too close to the window pane for instance. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Precision Time Protocol – Windows 10 implementation
Adam Kumiszcza writes: >> The key here is to have some conducting magnetic material under the >> antenna, not just sitting on its own. > > My GPS antenna hangs on the window handle and still gives the good result. > It's on the south facing window. Unfortunately, in the new location I will > have access only to west facing window. You should orient it correctly so that it is facing up, not simply dangling it from the cable. GPS antennas are directional. > Why is it good to have some conducting magnetic material under the antenna? > Is it to reduce multipath? The GPS dielectric patch antennas are designed to perform best with a ground plane. The optimum size varies a bit, but between 10…14cm in diameter is about right. The ground plane does normally not need to connect to anything, it has to be conductive but not necessarily magnetic (aluminum foil is OK, too). If you have a magnetic puck antenna, then using a magnetic surface has the advantage of the antenna staying in place more easily, though (try the bottom of a large can of vegetables). If you are unsure how large your ground plane really needs to be, just use one of the programs that visualize the signal strength on each sat in view and optimize for highest level over the visible part of the sky, but especially the higher elevations (sats directly above you). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Noob question, NTP stratum 1.
Achim Gratz writes: > The thing to note is that you need to boot with "nohz=off", Tom was asking what that kernel parameter meant and does. UNIX used to have a fixed frequency interrupt called TICK that would do its thing HZ times per second (typically HZ=100, but later on HZ=1000 on some systems). Without going to deep into the details, many powqer saving features don't really work if you wake up the CPU too often, so something called a "tickless" Linux kernel was developed and the config switch to use it is CONFIG_NO_HZ. The tick interrupt is still there in such a kernel, but it can be suppressed in order to save power. The kernel poarameter "nohz=off" tells the kernel to not use this facility and hence faithfully run a kernel interrupt for each TICK. It also prevents the kernel from shifting the deadlines of other kernel timers in order to create "bunches" of work, which is what I needed in this case. Just one reference, you can dive in from there if you need to know more: https://stackoverflow.com/questions/9775042/how-nohz-on-affects-do-timer-in-linux-kernel Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Noob question, NTP stratum 1.
wildylion via time-nuts writes: > The point is: do we ever need S1 NTPs? I think, this could be a nice > addition if properly realized, but right now I'm not sure if I can > propose it. You really can't properly monitor any stratum-2 sources you have configured if you don't have your own stratum-1 and you need at least three independent ones to rule out any irregularities in them with high enough probability. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Noob question, NTP stratum 1.
Tim Shoppa writes: > Real ntpd uses a drift file to track the local processor's frequency offset > and has a good estimate of processor clock drift after a day of tracking. That assumes stable median temperature and predictable temperature swings. > The Raspberry Pi processor clock, like any motherboards', will often be off > by off anywhere from +/-200ppm but the good news is that it usually varies > by less than +/-10ppm over a day and ntpd does a good job tracking this and > using the drift correction during no-signal periods. All rasPi I've bought so far (5 of them, all different models from three different sources) were ~10ppm slow at RT and within -6ppm and 0ppm at the apex temperature point of the crystal (around 60°C). It is possible to keep the temperature within about 0.2K of that point by using the CPU itself as a heater and thermometer and the resulting frequency within +-20ppb over a day when disciplined via pps-gpio. The residual drift is initially positive and gets smaller over time, mine are down to about 20~30ppb per week. > +/-10ppm over 24 hours is about +/-1 second. I've never tried to hold over since it's really hard to figure out when to start holding and when to switch back. A 24 hour holdover is pretty severe, but I guess you could keep it within double-digit ms territory without getting too fancy if you've got that right. Instead, by having enough independent NTP servers (all with their own antenna) the clients figure out by themselves when one is off by more than about a millisecond and switch to another one. Each server monitors the other ones and if it finds itself off from that bunch too much will drop down from stratum-1 to stratum-2. When exactly that happens depends a bit on how fast the drift rate is, but usually between 3ms and 5ms. > I would strongly discourage using a Raspberry Pi in any not-just-for-fun > application. Indeed. I'd opt for something like PCEngines' APU line since they have accessible GPIO and PTP capable ethernet. > I have had very poor luck keeping even brand-name hi-grade > microSD cards working for a year in 24x7 Raspberry Pi hardware. No-name or > store brand microSD cards seem to barely work at all when new. While I support that sentiment, after initial problems with off-brand cards the ones I have now are all getting into their third year with no signs of problems (knocks on wood). In a datacenter you'd almost certainly net boot the rasPi instead of giving them a microSD card. > Unless your server farms are completely isolated from the internet at > large, you should consider using a curated list of public NTP sources. The key to NTP reliability is copious redundancy, so you'll certainly want local servers in addition to that, even if you have redundant outside connectivity. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Noob question, NTP stratum 1.
wildylion via time-nuts writes: > Situation 1: > What I currently have is a uBlox M8N GPS puck I'm planning to use with > the Raspberry PI. Seems like it should work almost out of the box with > some kernel tuning, but I have a question about short term stability > in the event of GPS loss - how well will the board hold over if it's > lost GPS for, say, 24 hours? You can't say, really. It all depends on how the GPS gets lost, or what the environment does around the time of loss and after. If you have multiple such NTP servers you'll quickly learn by comparing them to each other that they sometimes do things you didn't think they should be doing. If you have just one, you'll probably never even know that. > Situation 2: > Also, there's a need for more dependable NTP time sources for our colocated > spaces. Colocated spaces == racks where paying customers put their stuff? > What we have is about 100 servers, some of them running DBMS that > wouldn't like clock drift at all. After a recent incident involving > NTP I've got an idea to install GPSDO time servers in each datacenter > and slave them to stratum2's that will be actually distributing time > to clients. You should really think about doing PTP instead on these systems, preferrably over a dedicated network. > All the certified GNSS disciplined clocks are really expensive (way > more than the management would approve), so what I'm planning to do is > possibly getting a couple LeoNTP units and using them as the root time > sources, would this be a good plan? Nothing against the LeoNTP (which I'm unfamiliar with), but if time actually is important (i.e. you need to guarantee some level of performance rather than hope for it) you'll end up doing the majority of the work that you'd otherwise buy with the certification. That almost certainly ends up being more costly than getting the certified gear. > Of course, all the NTP infrastructure will be monitored, and possibly > we'll use Stratum 2 servers which would be slaved to GPSDO S1's AND > the public NTP pool for sanity checks. > > Maybe BG7TBL's units instead of LeoNTP? > Is that a good idea? That really depends on what you are trying to achieve, but I'd say you have yet to define what the problem is that you're trying to solve. Do you just want your 100 servers to have the same time within some defined boundary, does that time need to track the official/legal time (at what maximum offset) or do you need to have traceable time stamps all the way back to the source (at what resolution and error)? For each set of answers entirely different architectures would be appropriate. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Noob question, NTP stratum 1.
Paul Theodoropoulos via time-nuts writes: > I've also found that my Raspi's give the best results with board temp > right around 60°C. However, I found that the 'CPU as heater', while it > does help dramatically compared to nothing at all, it introduces a lot > of jitter on its own. Much better results by keeping them in an > insulated enclosure in a relatively stable location (for me, a > closet!), and 'tuning' the insulation as needed to balance venting > against retention. Well, I have jitter (PPS timestamps) within ~2µs and the occasional "hair" that goes out to about 30µs. The distribution is a little bit wider on the three systems that are loaded with extra server tasks, but not much. The thing to note is that you need to boot with "nohz=off", set a fixed frequency as high as possible and use an interval timer for controlling the CPU load (I use all four cores as workers and adjust them at 40Hz). [I can post plots, but at ~500kiB I think I should rather ask for permission first.] Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Raspberry Pi TCXO Hat
Richard Laager writes: > I stumbled across this product listing: > https://www.teradak.com/products/115.html That site red-zones my BS detector… > It's a Pi hat that contains two TCXOs, one at 19.2 MHz for the CPU and > one at 25 MHz for the Ethernet controller. The one for the Ethernet controller is useless even for the seemingly intended application. Replacing the main crystal with a TCXO may or may not help NTP performance depending on how much temperature effects are currently dominating it. > It's a rather permanent modification, as you have to desolder the > stock crystals and replace them with wires going to the hat. I'm not > 100% sure how to order the hat yet, but they gave a price of $46 (USD) > via email. You'd be much better off taking not of the injection point and then use a GPS timing module that can produce a clean 19.2MHz clock. I still have that way down on my to-do list; although I was going to try and inject the clock without actually desoldering the crystal so it would still work even when the GPS module doesn't provide a clock. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Raspberry Pi TCXO Hat
Richard Laager writes: > How would it work to have two crystals connected in parallel? Not two crystals in parallel, a crystal plus the output of an (external) reference oscillator. If the two frequencies are close enough you can injection lock the crystal oscillator, but the more likely outcome is that you simply overdrive the input so the presence of the crystal doesn't really matter while the external signal is present (that's basically the mode you are using with no crystal present anyway). I have no idea if that is going to work (depending on how much power is delivered to the feedback), but I can always remove the crystal if not. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Question for my new GPSDO
ed breya writes: > I think the main need for the overall DAC system in these is not > linearity, but monotonicity - an increasing digital input always > causes an output change in one direction only, and never reverses. An y=x³ (cubic) transfer function is monotonic but not linear, yet you wouldn't necessarily want that in a feedback loop unless your target point is always zero. Monotonicity by itself is too weak a constraint, IMHO. However if you also constrain INL / DNL you will get better bracketing on the local feedback gain variation resulting from the slope changes around different output codes. Regards Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Question for my new GPSDO
Attila Kinali writes: > There is, as far as I know, only two types of DA converters that > are inherently linear: single-bit delta-sigma modulators and > Kelvin-Varley dividers. No, the Kelvin-Varley is not guaranteed to be linear, same story as a string DAC actually. Whether a delta-sigma modulator (for D/A conversion) is theoretically linear depends on a few things that are hard to ascertain, so in the end it is better than some other architectures but will still have nonlinearity if you look closely enough. For the application discussed here the two characteristics that matter are that sigma-delta modulators have no large spikes or lumps in the DNL curve and you can realize much higher resolution than the noise floor at DC. > If you are using used OCXOs from ebay and similar sources, they might > be quite a bit off in frequncy, so that you might need the whole tuning > range. These days it should be easy enough to use two or more DAC channels and effectively provide a small tuning window within the full EFC range. If you want to slide that window during long continous operation runs you'll have bit more of a challenge on the control side. > I would advice against using a CMOS switch. They are relatively slow and > their timing is not well defined. There are many variants of these tailored to different applications. You will need to check some more characteristics like charge injection if you go that route. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Syncing time via a VGA connector
folkert writes: > For fun I hooked up a TCXO to an Arduino. That Arduino then interfaces > the TCXO to the I2C in the VGA connector and then with some magic code, > it syncs the PPS signal to NTP. > https://vanheusden.com/misc/blog/2019-11-07.php On an actual VGA connector one of the monitor ID bits is still present as "reserved", so if your graphics card still implements it you may have an option of getting PPS in via that "GPIO". I haven't looked if that input might even allow interrupts. Likewise, HDMI (but not DVI) has a presence detect pin that should be usable as GPIO with some graphics cards. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Raspberry Pi TCXO Hat
David J Taylor via time-nuts writes: > The graph in ntpviz shows the jitter and temp almost perfectly correlated. Based on my experience it should really be a correlation of temperature rate of change vs. jitter. On my self-ovenized servers I see on average around 200ns jitter (close to the theoretical limit of 157ns based on the 19.2MHz clock) with the occasional peak to about three times the baseline. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Difference in antennas
John Ackermann N8UR writes: > One related question, especially with mixed systems -- how do you tell > if you have optimum signal level at the receiver? I don't think you're going to figure out an _optimum_ gain without proper measurements along the whole signal chain. As a proxy, the reported SNR should stay fairly constant with changing constellation and environmental conditions. > Most show some sort of SNR or Cn value. What should we look for? What > are the indication of *too much* signal? One issue in particular is how > to handle a modern GPS that expects modest antenna gain when it's > plugged into a system with a 50dB gain antenna at the top. That one is easy to solve with either a too long / too low quality cable. :-) Otherwise you may just have to add a 20..30dB damping plug on the receiver side. Keep in mind that a 50dB antenna typically either would not work at all with the supply coming from that GPS module (12V vs. 5V or even just 3.3V) or actually has lower gain because of the lower supply voltage. So you may need a DC block on the receiver and a bias-Tee at the antenna as well. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
Fiorenzo Cattaneo writes: > I have been quite puzzled about the asymmetric nature of my home Cable > Modem connection to the Internet in regard with the offset discrepancy > I observe. The "last mile" asymmetric nature of Cable Modem (Comcast > in my case) is not very high compared the delta I see between my > stratum-1 servers at home and the nearest public stratum-1 NTP server. > The upload/download discrepancy would be much less than 100 > microseconds - as you point out in your calculation the worst is 33 > microseconds for an upload speed of 12 Mbps, which is a drop in the > bucket compared to other potential sources of jitter, switch queueing > delays or asymmetric routing. The latter is not an issue in my case. The asymmetry from different bandwifth up-/downstream is only a small part of the effective up-/downstream difference. Dan Drown has measured that: https://blog.dan.drown.org/tag/asymmetric-latency/ I would think the jitter distributions are skewed as well, so some of that gets finally interpreted as an offset. If you can trust the clocks on either end of the connection to be accurate, then you can set the offset to zero and solve for the asymmetry instead of the usual assumption of zero asymmetry to solve for the offset. Plotting the offset against the RTT like Dan does is instructive, but you won't always get such nice graphs. I've attached a plot of how one of my stratum-1 has seen the three PTB servers through my DSL connection during the last three months. So while the connection is stable you can sort of remove the extra offset that comes from a changing RTT, but at any one time you might jump to one other set of correlation lines and get that "correction" wrong. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Question for my new GPSDO
Tobias Pluess writes: > Assume a timer is clocked with the 10MHz clock. The timer overflows > when it reaches 999 (=10e6-1). Further, this timer is used to > generate the 1PPS pulse output: each time when the timer reaches the > value of 0, a pulse is generated on one of the output pins. Since this > happens all in hardware, this should be fine and shouldn't have jitter > introduced (e.g. by interrupts or whatever). I don't know in detail about the particular part you are using, but I doubt that it is actually using an asynchronous clock into the hardware counter. The more typical arrangement is that it gets registered to some internal clock before the timer hardware deals with the signal (often via two stages to get metastability issues out of the way). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] can of worms: time-of-day in a community radio station
Adrian Godwin writes: > Off-the-wall thought : could you discipline a well-insulated raspberry pi > to NTP using heaters or workload to modify its temperature ? Yes you can, been doing that with four rasPi and two TinkerBoards for quite a while now to run the XTAL at its turnover temperature (which is roughly 60°C for the rasPi and slightly higher for the TinkerBoard). Depending on how much temperature swing you need to accomodate in total, you may not be able to cope without external heating or cooling, though. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Power supply for time source concerns
Am 22.12.2019 um 20:37 schrieb Taka Kamiya via time-nuts: > Most commercially manufactured time and frequency sources use > switching power supply. [...] The suggestion to "just use a linear power supply", especially if it was designed some decades ago is probably not getting the desired results these days. There is a lot more conducted noise on the power lines than there used to be, starting from several kHz right into RF territory. Linear regulators generally have bad PSRR at higher frequencies (often starting to degrade in the low kHz region already) and unless you have a clean input supply you pass any HF noise almost directly to the load. SPS are not necessarily worse than linear supplies when it comes to noise, but it generally shows up in different places frequency-wise (the detailed characteristics depend a lot on the exact topology chosen, so that's a whole 'nother dimension of things to consider when chosing). It is also harder to contain the switching noise as you have several high-current loops typically whose area must be kept as small as possible to not radiate noise. Conducted noise can be more easily filtered, but it gets out both through the input and the output side. The input side is often neglected a bit, which can come back to bite you when you have multiple supply rails in the system. Most switching topologies (or at least the ones that can be "clean" enough for the purposes under discussion) will produce a triangular ripple at the output at the switching frequency. You can make it smaller and smaller at the expense of load regulation, but it usually is easier to just deal with whichever number of millivolts that you're left with by putting an LDO post-regulator directly at the load (you put it at the load so you have better regulation and you can also use the supply line between the SPS and the LDO as part of a Pi filter). The LDO needs to have good PSRR at the switching frequency and maybe the first or second harmonic, the rest of the spectrum should already have been dealt with by filtering. Late Jim Williams' (RIP) application notes are always a good read: https://www.analog.com/media/en/technical-documentation/application-notes/an70.pdf https://www.analog.com/media/en/technical-documentation/application-notes/an101f.pdf https://www.analog.com/media/en/technical-documentation/application-notes/AN118fb.pdf -- Achim. (on the road :-) ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Power supply for time source concerns
Am 23.12.2019 um 16:03 schrieb jimlux: It is tough to build a "small" input filter that has good rejection at low frequencies (<100kHz?) Yes if you want a passive filter, but you can view an LDO as an active low-pass in some sense. Again you need to take care that noise cannot bypass it, but most of it should be conducted noise in the LF case. Active filtering is also a good option if the power you need to deliver is low. Buck converter to 8V (boost converters seem to have more noise) That again depends on topology and control type. The canned converters are almost always optimized to have the lowest number of switches and work with cheap magnetics (single coil) without easily entering problematic operation modes, noise is only a secondary concern. Producing less noise in the first place is possible if you change those constraints; i.e. allow more switches, more complicated energy storage (capacitors and magnetics) or employ control algorithms that are less robust and hence need to be tuned to the load to be stable. -- Achim. (on the road :-) ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
