Re: [time-nuts] E1938A source code/ firmware
OK so I have the NGOCOMM program for the E1938A. I see looking at the DLLs it was written in Borland OWL. Does anyone have the C++ source code, or know what is in it , and also does anyone know exactly what is in the E2PROM? all this for extending the MAINTAINABLE life of these excellent OCXOs. -glen ___ 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] E1938A source code/ firmware
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 > 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@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 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
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@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
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 the expected integrator term and hence allow more aggressive antiwindup. On Sat, Jul 6, 2019 at 9:00 AM Glen English VK1XX < glenl...@pacificmedia.com.au> wrote: > Hi Rick > > Thank you very much for the reply and the suggested leads. I think your > work on the balanced bridge oscillator was both preeminant and seminal . > > I have read all the papers on it, and there are few other things in my > 30 years of this field professionally that really impress me as much in > the new approaches and new thinking on the entire unit. Agreed on the > PII^2D control system. > > I've built a few OCXOs back in the 90s, the best I did on (inner) oven > control was using dual glass bead thermistors in a bridge configuration > with lots of gain driving a simple opamp integrator. The opamp was > chopper stabilized and I ensured the op amp never operated in the > crossover region of the opamp output driver. These were on AT cuts at > 97 deg C ... > > cheers > > Glen. AI6UM / VK1XX > > > > On 6/07/2019 2:37 PM, Richard (Rick) Karlquist wrote: > > On 7/5/2019 8:20 PM, Glen English VK1XX wrote: > >> Has anyone got this , is the PIC read data prohibited ? > >> > >> Is it still a closely guarded secret?, there were some very clever > >> and novel ideas used in that slab, in my opinion. > >> > >> Glen > >> > > > > Hi Glen. I worked on this project, but am an RF/Analog > > guy. The product line was sold to Symmetricom 20 years > > ago and they didn't continue the E1938A. At that point, > > there were no closely guarded secrets. I don't know what > > happened to the source code. The last contract manufacturer > > for the E1938A was Scotts Valley Magnetics. You could > > contact them and see if they have the PIC info. In theory, > > they would have had to have it to program the PIC's. > > > > The most clever thing in the PIC (AFAIK) is the oven > > controller with the double integrator. "P, I, I^2, D". > > Len Cutler was the mastermind behind this. I believe > > he leveraged his experience with double integrators used > > in Cs control loops. I remember him telling me that the > > secret was to have an "anti-windup" algorithm. Whatever > > he did, the results were phenomenal. I spent countless > > days in the lab exercising the loop and it always worked > > perfectly. > > > > Rick Karlquist, N6RK > > > > > > ___ > 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 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
On 7/5/2019 8:20 PM, Glen English VK1XX wrote: Has anyone got this , is the PIC read data prohibited ? Is it still a closely guarded secret?, there were some very clever and novel ideas used in that slab, in my opinion. Glen Hi Glen. I worked on this project, but am an RF/Analog guy. The product line was sold to Symmetricom 20 years ago and they didn't continue the E1938A. At that point, there were no closely guarded secrets. I don't know what happened to the source code. The last contract manufacturer for the E1938A was Scotts Valley Magnetics. You could contact them and see if they have the PIC info. In theory, they would have had to have it to program the PIC's. The most clever thing in the PIC (AFAIK) is the oven controller with the double integrator. "P, I, I^2, D". Len Cutler was the mastermind behind this. I believe he leveraged his experience with double integrators used in Cs control loops. I remember him telling me that the secret was to have an "anti-windup" algorithm. Whatever he did, the results were phenomenal. I spent countless days in the lab exercising the loop and it always worked perfectly. Rick Karlquist, N6RK ___ 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
Hi Rick Thank you very much for the reply and the suggested leads. I think your work on the balanced bridge oscillator was both preeminant and seminal . I have read all the papers on it, and there are few other things in my 30 years of this field professionally that really impress me as much in the new approaches and new thinking on the entire unit. Agreed on the PII^2D control system. I've built a few OCXOs back in the 90s, the best I did on (inner) oven control was using dual glass bead thermistors in a bridge configuration with lots of gain driving a simple opamp integrator. The opamp was chopper stabilized and I ensured the op amp never operated in the crossover region of the opamp output driver. These were on AT cuts at 97 deg C ... cheers Glen. AI6UM / VK1XX On 6/07/2019 2:37 PM, Richard (Rick) Karlquist wrote: On 7/5/2019 8:20 PM, Glen English VK1XX wrote: Has anyone got this , is the PIC read data prohibited ? Is it still a closely guarded secret?, there were some very clever and novel ideas used in that slab, in my opinion. Glen Hi Glen. I worked on this project, but am an RF/Analog guy. The product line was sold to Symmetricom 20 years ago and they didn't continue the E1938A. At that point, there were no closely guarded secrets. I don't know what happened to the source code. The last contract manufacturer for the E1938A was Scotts Valley Magnetics. You could contact them and see if they have the PIC info. In theory, they would have had to have it to program the PIC's. The most clever thing in the PIC (AFAIK) is the oven controller with the double integrator. "P, I, I^2, D". Len Cutler was the mastermind behind this. I believe he leveraged his experience with double integrators used in Cs control loops. I remember him telling me that the secret was to have an "anti-windup" algorithm. Whatever he did, the results were phenomenal. I spent countless days in the lab exercising the loop and it always worked perfectly. Rick Karlquist, N6RK ___ 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] E1938A source code/ firmware
Has anyone got this , is the PIC read data prohibited ? Is it still a closely guarded secret?, there were some very clever and novel ideas used in that slab, in my opinion. Glen ___ 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.
