[time-nuts] E1938A source code/ firmware

[Bob kb8tq]

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 <glenlist at pacificmedia.com.au> 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 -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.