Hi The gotcha with averaging multiple GPS modules is that there are a lot of common mode issues present. The averaging will help with the random noise stuff, but will not do much for the atmosphere, ephemeris, and other “external” limits. Unfortunately those limits are pretty significant contributors.
More or less: Sawtooth you can (and should) take care of with the correction information from the module. No need to average there. Random “I pick this / you pick that” stuff as constellations change will average out. ( = different signal to noise numbers will be present in the voting process on each module). You can see nanosecond level bumps from this. Since they are transient, exactly how much they contribute to a long term average is debatable. Ionosphere modeling errors will be the same for any rational group of modules running on the same system in the same area. The same is true of troposphere related issues. These can (but don’t always) get into the 10’s of nanosecond range. They can last long enough to pass through normal long averaging filters. The solutions are based on orbit and clock data broadcast in the ephemeris. Both can be off by nanoseconds. Again, they are long term so they pas through averaging filters. Probably better to focus on an ensemble of OCXO’s to lower the “local” noise floor: As you sum independent devices, it is reasonable to expect things like ADEV to improve by the square root of the number of devices. One limit to this is (as mentioned above) common mode issues. With OCXO’s temperature would be a common mode item. Controlling or correcting it would be a good idea. A group of 4 OCXO’s in some sort of controlled enclosure could indeed be 2X better than a single OCXO. Going up to 16 might get you 4X better. That range probably covers the range (even at eBay prices) that one would be working in. Improvements of this sort have been demonstrated in various (expensive) systems. The same principle would apply to things like telecom Rb’s, but at a bit higher price. I do not know of any commercial system doing that. Bob > On Jul 6, 2019, at 7:00 PM, Glen English VK1XX <[email protected]> > wrote: > > OK, good info, thanks. > > Well I have bought 7 x E1938As, with the intention of building a better GPSDO. > > My interest in the E1938A firmware hex was if I had to replace any of the > PICs at sometime in the future. > > 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. > > 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. > > 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 . 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. > > So first, I'll need to build a frequency/period counter in the same ilk > (same PCB) > > I'll make these PCBs loaded available to all. > > I have a protoype built and output at the moment is HD44780 LCD drive 8 bit > bus to surplus 40x4 char displays I have around here. and also a serial > stream output. best to do only what is necessary on the FPGA (rudimentary > time/frequency output onto the LCD) , and feed data to an analysis machine, > RPI, PC whatever for analysis and display in Python 2.7X. > > comments welcome. > > -glen VK1XX / AI6UM > > On 6/07/2019 10:06 PM, Adrian Godwin wrote: >> I would agree that antiwindup is important when you have integrators. They >> always seem to cause trouble without it, in applications as diverse as car >> throttle control and time-domain filtering of respiratory data. I would >> also recommend, sometimes, the use of feed-forward control to provide an >> estimate of power demand without relying on the integrator : although most >> useful for speeding the response, it can also reduce th > > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
