Rohde & Schwarz SWP.339.0010.02 Synchronizer PLL unlocked

Last time I fixed a problem in the sweep generator where the 600MHz IF was being disabled when it shouldn't. After that all the self-tests passed and the unit was working overall except that when using the Synchroniser with frequencies above about 980MHz it would lose lock.

Lock Loss

The loss of PLL lock would occur around 980MHz but is wasn't reliable. Sometimes the output would be stable up to 1GHz but then after the unit warmed up a bit it would revert back to the usual behaviour.

This is what the output look like on the spectrum analyzer when the PLL is locked and the frequency relatively is stable (in fact this snapshot isn't all that great - it got better later).

Then if you shift the frequency ever so slightly the output would loose it all together.

The Synchronizer PLLs

The synchronizer has two PLL loops used to lock the output frequency to the 10MHz reference.

In the block diagram below the 'fast' PLL is shown in green and the 'slow' PLL is red. The slow PLL locks a 87-122MHz VCO to the 10MHz reference. The fast PLL divides down the output using a set of frequency dividers

The way it all works is that there are a few paths depending on the frequency range.

• Below 20MHz the output is generated by mixing the VCO output with the 100MHz reference signal generator off the converter board. In this case the output is not fed back through the PLLs.
• Above 20MHz but below 70MHz the output frequency is band-pass filtered and fed to the PLLs
• Above 70Mhz and below 700MHz the output signal is divided by 10 and then fed to the fast PLL and the 700Mhz fed to the fast PLL
• Above 700MHz the output is mixed with a 1200MHz signal derived from the 600MHz IF generated on the IF board to down covert the frequency to 0..700Mhz. This is then divided by 10 to get 0..70MHz which is fed to the fast PLLs. The 700Mhz is again fed to the slow PLL
• Above 1200MHz the output is mixed with an 1800MHz signal generated from the 600MHz IF and the 0..700Mhz fed to the PLLs as above.

When the output is below 20MHz the slow PLL locks the VCO to the 10MHz signal.  There is a phase comparator that compares the VCO output with a 10kHz and a 1kHz signal generated from  the 10MHz reference. Because the 100MHz this is later mixed with is also locked to the 10MHz reference then this is all that is required.

When the output is above 20MHz the slow PLL takes the 0..70MHz signal derived from one of the paths listed above is divided by a factor K and compared with the 1kHz and 10kHz reference derived signals and used to control the VCO.  The VCO is then divided by 64 to generate a signal between 1.5Mhz and 1.9Mhz that is fed to another phase comparator and then used to control the output frequency.

The fast PLL does its own division of the 0..70Mhz signal (divides by M and then by N) to generate a frequency around 1.5MHz to 1.9MHz which gets fed to the phase comparator described above. The fast PLL has extra logic for sweeping so it can lock just at the beginning of a sweep and can handle fast frequency transitions that the slow PLL can't.

Debugging PLLs

So I was dreading this problem because of the  PLL loops. The problem is that if the loop is out of lock then all of the loop is out of lock and it's hard to tell where in the loop the fault lies. In this case it is even  worse because there are two PLL loops.

Initially I mistakenly thought I could check the slow PLL on its own. I thought it was totally derived from the reference and so should remain in lock regardless. That isn't the case as it does depend on the output. Therefore if the output is unlocked so is the slow PLL and the VCO.

With a brief warm up I could get the unit so it would be in lock and then if I shifted the frequency just a bit it would lose lock. This made debugging easier as I could compare the 'working' with the 'unlocked' states quite easily.

So I started with the slow PLL and began with the VCO. I found that when the loop is locked the VCO frequency was stable but when it lost lock the frequency would jitter. Also I found that the frequency would go to 132MHz which is outside the specified range. Stepping back through the VCO inputs I found that the control voltage was hitting the limits (going to zero) when it lost lock. I walked back further and found the two phase comparison signals (PHKOM11 and PHKOM12) coming from the digital board were hitting the rail (15V) when the PLL lost lock.

Digital Section

Debugging the digital section wasn't much fun. It has two SMB connectors through to the motherboard and I didn't have any SMB patch leads - I have SMC and SMA (both of which are used in this instrument) but not SMB. This meant I can't run the board on risers as the signals on the coaxial connectors are required to debug the PLL loop. I found I could connect to the test points with a wire and then stuff the board back in the unit.

First I looked at the test-points around the dividers (see below). To be honest I don't really understand this circuit. It's a messy mix of ECL and TTL with lots of TTL to ECL conversion going on. There are ECL D type flip-flops feeding ECL counters that adjust to either count by 10 or 11(??).

The core of this is this two chip set that implements a pre-scale and phase comparator. This is the HEF4751VD and HEF4750VD. The pre-scaler has more capability than what is used here but the circuit seems to be controlling these two 4 bit registers that are used to subtract from the count (to adjust the divide ratio). There is a feedback path that clocks out signals that then adjust the counters feeding into the pre-scaler.

Ok so I got a bit lost here but I could see the 10kHz and 1kHz signals at P9 and P10. When the loop lost lock the frequency of these would drop just a little. The phase comparator output would alter also and that matched what I was seeing on the analog board.

So the question is why is this happening? I thought about maybe the counters are not being setup correctly so the division ration is wrong, I traced signals in to check that they aren't being lost (and they weren't). It seemed to be working apart from the fact that it lost lock.

It was about here that I realized that the input is a 700Mhz signal and not the VCO. I also realized that if either PLL was wrong they would both lose lock.

I start looking at the fast PLL - I looked at the frequency of the P11 signal. This signal has already been divided by 10 on the analog board and is divided by another 1,2 or 4 depending on how many of the D flip-flops are enabled by the multiplexer (D140).

You can figure out the division easily from the table provided in the service manual below. You take the output frequency, work out the down converted freqency by subtracting it from either 1200 or 1800 (or don't subtract if it is less than 700Mhz) and you look up this frequency in table. Then you divide the frequency by M and that should be the frequency at P11.

Again I found this matched exactly - or at least it did when the PLL was locked. When it fell out of lock the frequency would wander off (lower).

New Piece of Test Gear

Up to this point my only way of checking the output frequency above 300MHz was with my spectrum analyzer and I wasn't confident this was correct. A while ago I ordered a pre-scaler for my frequency counter from this polish eBay seller and it finally turned up. The quality of the board and the wiring etc was excellent. I installed this in my 53131A and did some tests. It happily counts -30dBm signals up at 2.5GHz.

Tuning the YIG

One thought I had was that because the YIG output was very out of tune that this could effect the synchronizer PLL's ability to lock. Up to this point I could adjust it as I couldn't measure the output with any accuracy. I followed the procedure to adjust the low end (10MHz) and then the high end (2.5GHz) using my new pre-scaler.

Then I tried the synchronizer again - and it locked at 2.5GHz!

The problem was simply the YIG being too far out.

That was too easy. Well at least I learned a few things.

Final Cleanup

So here it is in my bench (gee it's getting crowded!).

I even took the time to polish up the BNCs with a bit of aluminium polish and a Dremel tool. They look good!

Rohde & Schwarz SWP.339.0010.02 - No Output

This is the third part of the project to refurbish an old Rohde and Schwarz sweep generator.

So I have had this one problem on and off since I got the unit. The output will be stuck at around 38MHz or sometimes 13MHz and if I run the self-test I get an error 22 1C 00 which translates to "the 600MHz IF is missing"

In the first part but the conclusion I reached was that it wasn't the IF generation at fault but something is turning it off.

Well this fault is back and now it is around more than it is not around. This makes working on anything else impossible so its time to kill it once and for all!

Where Does the control Signal Come From? 

In part 1 I found that the 600MHz IF was being blanked by this HF SW TTL signal from elsewhere. The line is labelled HF SW but actually there is a HF SW1 and HF SW2. So if you look at the schematic for the motheboard that carries the RF components, you can see that pin 15 of the converter board connector  is connected to pin 9 of the connector that bridges the RF motheboard to the main motherboard. This is labeled HFSW 1 on the left hand side connector (the bridge).

So this means HF SW 1 is actually controlling the converter and disabling the IF. I got a multimeter out and rang out this line and sure enough that connection is good.

So following this onto the main motherboard you can see HF SW 1 connects to the digital section of the synchroniser (pin 8A labelled HFSW1) . It's not that simple though as there is a jumper (X91) that if in place will bridge this onto a line labelled HFSW. Ok this is a worry - so should the jumper be in place or not?

So I looked at the logic controlling this HFSW 1 line on the digital part of the synchroniser (below). 

What you can see here is the HFSW 1 and HFSW 2 signals being generated from the HF SW1 coming in. The symbols are confusing but D96 is just an OR gates and D75 an inverter. Remember that HFSW 1 is active low - that is a low output turns the 600MHz IF on. 

I pulled the Synchorniser digital board out, unscrewed all the covers and put it on risers. The HFSW 1 was indeed high and the reason was that the signal labelled Y (in a circle) was high which was then inverted by D75 and no matter what HFSW did the HFSW1 signal would be high (as it is a NAND gate).

So then I went searching for this signal labelled Y and it turned out it is controlled via a register interfaced to the bus. So if this register output is high then HF SW 1 will be high and we get the error.

At one point the unit mysteriously worked and I could check my theory and sure enough when the value of Y was low the output worked.

I setup my logic probes to watch the input to that line from the bus (pin 18 of D118), the Y signal (pin 19) and triggered on the clock line (pin 11). I never got a trigger! It was never written to so the register output was at the default.

Debugging the Address Decoding Logic

First of all I hooked up my logic probes to the two inputs to D95 and the clock line feeding D118 to see why the clock pulse never happened. One of the inputs to the OR gate (D95) is from the decoder and this stays high until the address corresponding to this register is present and then it goes low. The other signal is from the EXTWR-N signal off the bus to signal a write is occurring.

I could see a longish (1uS) low pulse on the write signal but the decode line would go low for a brief bit and then high again before the write pulse went low. They needed to both be low for some time period to generate a low on the output of the OR gate and then when write goes high it will generate the positive going edge that triggers D118 to latch the data off the bus.

So why is it only going low briefly? I thought perhaps this was a write to some other address and that the low was just a transitory state while the bus settled. There are too many lines to decode the address bus, the clock line and the data port all at once (my scope has 8 logic probes and 4 analog channels). I decided to break it down bit by bit.

First I hooked probes up to all the inputs and outputs of D77 (the 8 input NAND gate that decodes the upper bits of the address bus). This was functioning correctly in that when the outputs were all high the output went low). The OR gate seems fine so what else? It can't be the decoder as it does go low for a bit. Can it?

I continued with my process and hooked up the 3 select lines plus G1. G2A and G2B of the decoder plus Y2 which triggers the latch. Again the output matched what I saw before - the decode signal stayed low for a bit but went up again. I thought perhaps the logic analyser was simplifying a slow rising waveform or a glitch so I connected an analog channel to Y2 also but sure enough it was staying low for a very short time.

In this scope trace the bottom three signal lines are the select lines (which I combined into a bus). You can see these have a value of 2 to select Y2. The next three lines are the G1, G2A and G2B signal lines which are high, low and low respectively - again this is good and should result in the decoder decoding. The next line is the decoder output and this is echoed by the yellow trace at the top which is the same signal connected to an analog line. You can see it goes low for a very short time.

The top digital line (D7) is the write pulse and you can see the decoder output has gone high again before this has been pulled low. This is why the latch is never triggered as they both need to go low together.

In fact on one occasion while I had this hooked up it worked and in that case the decoder output stayed low *just* long enough to overlap the write pulse.

It can't be a broken trace as the decode signal output is clean (not a slow ramp etc). But can a decoder fail in this way? This doesn't make sense. I bought a replacement decoder chip (as they are cheap), desoldered the one from the board and replaced it. It worked! The decode output then stayed low for as long as the select lines did which was long enough to overlap the write pulse and now the HF consistently (had to take the snapshot from my phone as the scope doesn't like the USB for some reason and  I couldn't hold the analog probe in place).

So what Now?

This is pretty good as now the unit is pretty functional. It sweeps, the power output looks correct and the synchroniser is now looking pretty good. Up to 300MHz (limit of my counter) the frequency has lots of zeros in the values. All the self-tests pass now too.

I thought there was a problem with modulation (as when you hit AM or FM button it doesn't affect the signal) but it turned out to be me being stupid. The unit doesn't generate an internal modulation signal but you have to provide one via a BNC on the front panel. When I did this it worked fine.

The final problem is that for some reason there is a lot of phase noise at higher frequencies when using the synchroniser. I figured out there is a spot around 970MHz where the signal would suddenly degrade. The frequency also gets less and less accurate above this point so by the time I get to 2GHz it is many MHz off.

But that's a problem for next time...