Electronics > Projects, Designs, and Technical Stuff
Yep, it's ANOTHER GPSDO - Development rig MKII
(1/4) > >>
intabits:
I'm just so excited by my first results, I just had to tell someone...

This GPSDO is inspired by the project in Silicon Chip magazine, September 2018:-
http://www.siliconchip.com.au/Issue/2018/October/GPS-synched%2C+lab-quality+frequency+reference+(Part+2)
(select #5 at left)

(I won't reveal any details of that project not visible above, out of consideration for the magazine. If you're interested, the article can be purchased )

I've used the voltage controlled, oven stabilized oscillator part of the project, and will use it's multiple output frequency synthesizer in the final build.
But I've used a different processor (Arduino Nano - that may change), and implemented the counter function in external hardware.

The oscillator produces 40MHz nominal, which is counted during the GPS PPS pulse. After the count, the control voltage to the oscillator (with quasi 24 bit resolution) will adjust the frequency until a count of 40,000,000 is obtained. The counter can operate over multiple PPS periods (up to 106 seconds) to reduce jitter effects, and get very fine resolution measurements of the output frequency.

I'm excited because the first test, with no oven cover (and a ceiling fan blowing cool air all over the place), and with the heater turned off, shows only one count deviation. Which is *far* better than I expected.
The measured frequency is 39,999,469 to 39,999470 - I've seen only those two numbers after operating for well over an hour now.
(And that variation could simply be because the actual oscillator frequency is 39,999,469.5Hz)

This is my development rig:-


Top left PCB: Oven and oscillator, with cover removed.
Bot left PCB: Counter and gating logic
Top right PCB: Just a 32 bit divider to get a bunch of frequencies (not completed)
Bot right PCB: Output frequency synthesizer (not completed)
Middle: Bodge board with oscillator buffers, ambient temp sensor, shift register to read counter output.
Bottom: Small GPS module (covered by wires), and Arduino Nano
(if there's interest, I can share details of the counter and gating logic used here)


Here is the first page of output:-



This setup could be used for any voltage controlled oscillator, but I really like the idea of the SC design, since it's a TCXO built from scratch, using all brand new parts, and therefore no need to use whatever can be found on eBay.

Earlier development of the oven control shows a very stable 35C, with only +/-1 resolution unit of the DS18B20 sensor (0.0625C):-


Now to work on the software combining the oven control  and get to adjusting for 40,000,000Hz...
intabits:
So I hard-coded a DAC value to push the oscillator frequency up to 40MHz, but got some strange count values:-



Values of 39999999,40000000,40000001 and 39999744.
That last one had me tossed until I realized that 39999744=40000000-256.
So I believe the 39999744's are actually 40000000 with two bits crossed up:- 


--- Code: ---      value        hex                       ** *
 39,999,744 = 262 5900 = 10 0110 0010 0101 1001 0000 0000
 40,000,000 = 262 5A00 = 10 0110 0010 0101 1010 0000 0000
 39,999,872 = 262 5980 = 10 0110 0010 0101 1001 1000 0000 

--- End code ---

The first two have bits 8 and 9 swapped, and I've occasionally also got the last one, where bits 7 and 8 have flipped.
I thought of a solder bridge, but no. And anyway, everything, hardware and code, is common for all four bytes, so I can't see how just these 3 bits out of 32 are getting screwed up.

The counter, gating and readout circuitry is:-


And my code to read from it is:-


--- Code: ---unsigned long ReadCounterRegister() {
unsigned long CV; byte BV;
  CV=0;                                       // Clear result
  BV=ReadCtrRegByte(0); CV=CV|BV; CV=CV<<8;   // Get MS Byte,
  BV=ReadCtrRegByte(1); CV=CV|BV; CV=CV<<8;   // OR into result, shift 8 bits,
  BV=ReadCtrRegByte(2); CV=CV|BV; CV=CV<<8;   // making room for the next byte
  BV=ReadCtrRegByte(3); CV=CV|BV;             // Get LS Byte, OR into result, but no shift
  return CV;
}
 
byte ReadCtrRegByte(byte BI) {
byte CB,BT,BM,BC;
  // Set 74HC138 select lines for specified 74HC590 chip. LSB is chip 3, should be reversed...
  digitalWrite(CtrRegOS1,(BI&2)>>1); 
  digitalWrite(CtrRegOS0,(BI&1));     
  // Pulse ParSerCtl High to latch selected CtrReg output byte into CD4021
  digitalWrite(ShfRegLoad,1);
  digitalWrite(ShfRegLoad,0);
  // Serial shift CD4021 data into byte
  CB=0; BM=0x80;                      // Reset result byte and Bit Mask
  for (BC = 0; BC < 8; BC++) {        // Loop to get 8 bits...
    BT=digitalRead(ShfRegData);       // Get CD4021 output on Q8 pin
    if (BT!=0)                        // A 1?
      CB=(CB|BM);                     // if so, insert bit mask bit into result byte
    BM=(BM>>1);                       // Shift bit mask to next bit   
    digitalWrite(ShfRegClok,1);       // Pulse Shift Clock High
    digitalWrite(ShfRegClok,0);       // to shift next bit to Q8
  }
  return CB;
}

--- End code ---

I've tried inserting short delays all over the place, in case of a marginal timing issue, but I still get the swapped bits.

Any ideas on why this might be happening?
metrologist:
Just saying Thanks for posting! I love these GPSDO projects.
NorthGuy:

--- Quote from: intabits on January 18, 2019, 09:24:49 am ---Now to work on the software combining the oven control  and get to adjusting for 40,000,000Hz...

--- End quote ---

You don't read the bytes at the same time. After you read byte 2, byte 3 may roll over (and you're actually deliberately trying to catch it at this bad time). Hence you get - 256.

Same goes with bits within Q0-Q7 - you may latch them while they're changing.

Latching must be synchronized to the 40 MHz clock and done all at the same time, such as with 4 different shift registers.

<edit>My mistake. I see you gate the clock with PPS, so what you're doing should work. Since it doesn't, one may suspect the gating is not working properly and you're reading the data while the clock is still running.
intabits:

--- Quote from: NorthGuy on January 19, 2019, 01:31:31 am ---
--- Quote from: intabits on January 18, 2019, 09:24:49 am ---Now to work on the software combining the oven control  and get to adjusting for 40,000,000Hz...

--- End quote ---

You don't read the bytes at the same time. After you read byte 2, byte 3 may roll over (and you're actually deliberately trying to catch it at this bad time). Hence you get - 256.

Same goes with bits within Q0-Q7 - you may latch them while they're changing.

Latching must be synchronized to the 40 MHz clock and done all at the same time, such as with 4 different shift registers.

--- End quote ---

No, (unless I'm screwing something up - I'll check to be sure) the counter has been stopped when I read it. I can pull the bytes out at my leisure...

Here is the timing diagram (a bit busy, with some small errors, but it shows what's going):-


1/ Top trace is counter enable
2/ is PPS signal
3/ is Arm signal from CPU
4/ is Disarm signal from CPU

Basically, it holds the counter disabled, but "armed", waiting for the next PPS, which immediately enables the counter.
During the PPS period (or during the last, if counting over more than one), "disarm" is set to stop the counter at the next PPS.

Anytime after that, the count is latched into the 74590 registers, and then one by one, each byte is enabled onto the shared bus to the 4021, then clocked into the CPU, and repeated for the other three bytes.  All this can occur at any speed, because the counter has stopped.
Navigation
Message Index
Next page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod