Anritsu PSN50 Power Sensor

As I got further with the Rohde and Schwarz sweep generator I realized I really had no accurate way of measuring the power output. My spectrum analyzer was pretty good but also not overly precise and not calibrated.

Power meters are pretty expensive and usually the power sensor is sold separately. Power sensors often are as much or more than the meter and for USB power sensors this is even more the case.

I found this Anritsu PSN50 power sensor very cheaply on eBay. I found there is some software for it that seems to support Windows but decided this was Ok and bought it.

Then I realized I couldn't download the software. After talking with Anritsu support it appears the sensor is only intended for use with Anritsu base-station test systems (portable spectrum analyzers) and the stand-alone software is intended only for calibrating the sensor and retails for $3K AUD!!

Anritsu support were not unhelpful but didn't help. I was essentially asking them to expose an internal interface. They basically told me they have no information on the interface. I asked again in a different way but the result was unless it is information they have already published they can't give me any more.

Before I put it back on eBay - can I hack it?

Talking to the Sensor

I found an Ada fruit guide on how to talk to unknown USB devices. It explained configuration, endpoints etc. The first step is using lsusb on linux to see what the device reports. In the case of the PSN50 I got this:

Bus 004 Device 002: ID 0b5b:ffc8  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0b5b 
  idProduct          0xffc8 
  bcdDevice            0.00
  iManufacturer           1 Anritsu Company
  iProduct                2 PSN50 Power Sensor
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      CDC Call Management:
        bmCapabilities       0x00
        bDataInterface          1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               2
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0001
  Self Powered

So that abstract modem looked pretty promising. It appears to be a USB serial device. This makes sense as the device has a serial port in addition to the USB. So how to talk to it?

Well it turned out Linux just quietly loaded a serial device for me. I found there was a /dev/serial/by-id/usb-Anritsu_Company_PSN50_Power_Sensor-if00 device. For some reason I couldn't get screen or mincom etc to talk to it properly. The device would just keep sending back 'NO TERM'. If I cat the device from one terminal while echoing a command from another terminal it would respond with a BAD CMD. That's pretty promising though - I can talk to it!

Commands

Anritsu make a number of other USB power sensors that you ARE supposed to talk to with a computer (like this one). For these they publish commands so I tried a few of those. Not many of the commands worked but I found a couple that did. For example I figured out that IDN? would respond with the ID of the device:

ANRITSU,PSN50,0748037,0748037,1.00

TEMP? Returned the current temperature of the device. 

AVG? Returns 0 and I figured out if I say AVG 1 it said 'OK'. So that means if I send a command with a question it queries (makes sense) and without it sets some state. If the state change is good it says 'OK'

STATUS? Returns a byte which contains the status of the device. I haven't figured this out yet.

ZERO Makes the device sit there for a long time and eventually say 'OK'. From reading the user guide it appears it is supposed to reset the zero power setting (i.e. you do this with nothing connected).

But nothing I tried gave me the power level. So what to do? Well I decided to try brute force. I used some code like that below to search for all 3 letter commands (assuming no numbers). Only looking for commands that return values too (like the power level!). I found the device would lock up if I sent the commands to quickly so I had to add a small delay between commands.

import serial
import time

commands = []

port = serial.Serial(timeout=5.0, port="/dev/serial/by-id/usb-Anritsu_Company_PSN50_Power_Sensor-if00")


def test_commands(prefix, seq_len, test_func):
    for charOrd in range(ord('A'),ord('Z')+1):
        if len(prefix) < 3:
            print("Starting "+prefix+chr(charOrd)+"...")

        test_func(prefix+chr(charOrd))

        if len(prefix) < seq_len-1:
            test_commands(prefix+chr(charOrd), seq_len, test_func)


def check_command(command):
    # print ("Trying "+command)
    port.write(command+"?\n")
    response = port.readline()
    if "BAD CMD" not in response:
        print("** Got One!! " + command+"?")
        print(response)
        commands.append(command)
    time.sleep(0.05);


test_commands("", 3, check_command)

port.close()

print commands

This took quite some time to run and it only gave me two more but it gave me an important one!

POW? Returns the power level in dbM (as a floating point)
VER? Returns the version of the firmware (1.0)

I tried running a four letter scan and it took a full two days and yielded nothing extra.

Anritsu publish an application note on using the device with their other equipment. This tallied with the commands I was seeing such as averaging mode, temperature etc. The application note also talked about setting the centre frequency of the device and that it had calibration constants for each 500MHz slab of bandwidth.

I modified my script a bit to search for commands with up to a three letter prefix before FREQ? so AAAFREQ? through to ZZZFREQ? and I found CFFREQ? returned a number. After a bit of fiddling it appears the number is from 0.05 through to 6.0 and is the frequency in GHz (0.05 is the lowest frequency and is 50MHz).

The application note also talked about a limit (min/max) mode but I haven't found commands for this. it could be they are doing it in software. Similarly they talk about setting an offset for doing relative power measurements but again this could be done in software. There is also a max hold mode in the manual and I would have thought this would have to be done in firmware but again I haven't found a command.

Power Measurements

By creating a couple of small python tools I can take power readings and switch the centre frequency. I took some readings from my signal generator and compared the readings my spectrum analyzer reported.

I found for signals over 1GHz the measurements were quite close and made me feel like the power sensor was working. But for frequencies below 1GHz they were miles out (20dB or more). Interestingly at 990MHz this was already quite wrong and got worse as you go down. The CFFREQ command didn't seem to make a whole lot of difference too which is odd. The numbers were consistent from run to run however so I could (if I had a source I could trust) make up adjustment factors. The size of the error though will limit the dynamic range significantly.

Hardware

The unit has four screws on the bottom and you can remove the bottom plate. Initially I thought this is as far as I could get in without undoing the power input connector (which would surely stuff up the calibration). Later I realized the screws at the end come undone so now I can fully access the board.

Here is the bottom side. Nothing much to see apart from some passives for the different power supplies etc. There is a light-pipe near the USB port. I figured out (accidentally) the LED is red/green as I tried to ZERO the device while I had a signal applied. The LED went red and it stopped talking to me for a while.

Here is the top side. The highlights are:

• Main micro is a PIC18F455 running at 20MHz
• LTC2444 high speed, 24bit 16 channel DAC. This seems like way overkill for this. Not really sure why...
• AD8629 Low offset, low drift, low noise op amps that look like they read the actual power off the detectors. The CalXpert software guide explains the internals of the sensor and how it has a high and a low power path. See section 1.2 here
• MAX32221 RS-232 Line driver
• LTC1258 4.1V LDO

I can't believe they machined the case. Wow.

Automation Experiments

Lots of my electronics lab equipment has some sort of automation interface that allows it to be remotely controlled. I used the Ethernet interface on one of my bench multi meters to automatically calibrate my home-brew power supply. I wanted to explore what else can be done with automation.

National Instruments VISA Drivers

VISA or the Virtual Instrument Software Architecture is a set of APIs for communicating with lab equipment. The VISA interface provides an API you can use to communicate with instruments regardless of whether the instrument is connected with Ethernet, USB or GPIB. VISA provides abstractions for device addresses and allows an application send commands and receive events generated by instruments.

VISA provides primarily a C interface however there is the pyVISA library that allows you to use VISA though Python.

National Instruments provides the VISA runtime for free on a large number of platforms including Windows, Mac and Linux. Using this with Python means I can run my scripts on all three platforms.

Keysight MSO-X-2024

My oscilloscope supports automation via Ethernet. Ethernet however is an expensive ($400) option as it also provide a VGA interface to allow the instrument to display the screen on a monitor. Luckily someone figured out that all the Ethernet capability was on the motherboard so all that is required is a couple of inductors and  MagJack.

Someone on the EEVBlog forum was selling surplus homebrew Ethernet boards (unpopulated) and so I bought one. It was pretty easy to assemble and the design also included STL files that can be 3D printed into a case to support the board when it is plugged into the oscilloscope.

The scope takes longer to boot and displays an error about the VGA functionality but otherwise the Ethernet works fine. The details about the board can be found here. There is also this github with KiCAD schematics etc but I think they are the same.

Here it is assembled

Siglent SDG1020 Signal Generator

This signal generator has served me quite well over the last couple of years. The unit has a USB interface that you can use to control it including uploading of custom waveforms.

Siglent provides Windows drivers and an application you can use to control the device. Initially I assumed I would have to use the Siglent driver to interface with the device and so I would have to use Windows. Siglent provide some tools to enable the signal generator to be used with NI Virtual Bench and to begin with I thought this is what I needed to talk to it via VISA.

I figured out that NI VISA can directly interface with USB devices without a driver.  I found a short step-by-step guide here for doing this. The trick is the instrument must implement the USB TMC protocol which the Siglent device does.

I followed the steps but it didn't initially work. I turns out you have to tell the signal generator to support USB TMC mode. You use the utility button and then select Interface, USB Setup and select USB TMC (instead of the default with is 'RAW'). Reboot the signal generator and then you can send commands to it via NI VISA. I opened the VISA interactive control tool (provided with NI VISA), selected the Siglent instrument and used the Input/Output option to send an *IDN? command which came back with the device ID!

There is a programmers guide for the signal generator here. The device includes commands to control pretty much everything you can do from the user interface.

GPIB

I have a few instruments that provide GPIB based control interfaces. In particular this would be useful for my old HP3478A multimeter as then I could do precision voltage/current measurements between that and the Keysight 34461A. In addition my 53131A and my Rohde & Schwarz signal generator provide GPIB.

I find everything about GPIB is expensive. The cables, the interface cards and even instruments that support GPIB tend to be more expensive. But then GPIB is also quite ancient (it was originally HPIB until IEEE published it as IEEE 488.2). Amusingly the Commodore 64 spent many hours hacking on when I was growing up had a GPIB interface. GPIB is not a terribly quick protocol and for most applications you don't even need as much speed as it provides.

GPIB allows instruments to be daisy-chained together on the bus. The cable connectors have a plug on one side and a socket on the other to allow them to be chained. Each instrument has an address which is usually adjustable via the instrument interface. For the most part the computer directs everything on the bus however it is possible for an instrument to generate a service request or to raise a trigger. 

The main ways people connect to GPIB seem to be these Agilent USB to GPIB modules. Recently these have become quite cheap on eBay ($100 instead of $400).  The major downside of these is that they only come with Windows drivers. It is possible to make them work on Linux but it is relatively painful as you have to upload firmware onto the USB device when it connects.

Another popular option is the ProLogix GPIB modules but these are quite pricey and don't support NI VISA.

By luck I found an older ICS-8065 Ethernet to GPIB gateway going quite cheaply on ebay. What interested me about this device is it uses the VXI-11 protocol over Ethernet. This protocol is a pre-cursor to LXI and is based on RPC. This means that in the future if I can't get software for this device I can always write something using RPC. NI VISA already supports VXI-11 so there is no need for that. An added plus is that as it requires no additional software (apart from NI VISA) I can run my scripts on my Mac with pyVISA.

The downside though was my unit was a bit old so it didn't have a web interface for configuration. I had to dowload some Windows software from the ICS Electronics website to configure it. I tried to update the firmware but after a couple of emails with support it turned out my device required a major (i.e. too big to do) hardware upgrade to run the newer firmware.

There is a slight trick to configuring the gateway in NI VISA. You select the hostname of the gateway but then you somehow have to select which instrument the alias is for. In the ICS 8065 configuration you can choose a device name but the default is gpib0. The way you select what instrument connected to the bus you want to talk to is by adding the GPIB address to the LAN device name. So the instrument with GPIB address 3 has a LAN Device name of gpib0,3. See below.

Using this I was able to get my HP3478A and my HP53131A to work. The HP3478A isn't SCPI so the commands are a bit different but it is relatively simple. Even though the 53131A is SCPI I actually found it hard to use. For some reason I couldn't get the R&S signal generator to work at all. Really not sure why but it may be a fault in the unit. I will look at that another time.

Bode Plotter

So I wanted to try using this for something. Frankly the possibilities with automatic measurements are quite large but recently I've been reading about active filter design so I thought it might be fun to make a bode plot.

The basic plan is to:

• Use the USB interface to the Siglent signal generator to sweep across a frequency range.
• For each frequency, use the oscilloscope to measure the amplitude of the output and to work measure the phase between the input and output.

You can measure the amplitude easily enough with the scope using a command like

MEAS:VPP? CHAN3

Phase is pretty easy too

MEAS:PHAS? CHAN3, CHAN1

Amusingly when you do this the Peak to Peak measurement and phase get displayed in the oscilloscope screen.

The problem is to measure the amplitude and phase you need to have at least one complete cycle on the screen. We know the frequency as we are controlling the signal generator so we can set the time base of the oscilloscope. We can set the seconds per division to whatever value using something like this:

TIME:RANG 1.1e-3

To set the signal amplitude we can use this command sent to the signal generator:

C1: BSWV, FRQ, 10e3,AMP, 0.25

This sets channel 1 to a basic wave (sine wave) of frequency 10kHz and amplitude 0.25V peek to peek.

So now I started to think about how I sweep the frequency across a range logarithmically but while maintaining an even number of points per decade. While looking up maths code for Python I found this numpy library which actually has a function for it!

for freq in numpy.logspace(numpy.log10(100),numpy.log10(1e5),num=100):

This for loop iterates over a set of 100 frequencies spread evenly (in logarithmic fashion) between 100Hz and 100kHz. Neat!

Now for frequency I 

• Change the signal generator frequency, 
• Move the scope time base to match the frequency, 
• Measure the peak to peak voltage of the input and the output
• Measure the phase difference between the input and the output.

Then to calculate the gain I just use:

gain = 20 * numpy.log10(output/input)

For each frequency I add the frequency, gain and phase to an array. But now what can I do with the data? I found this Python library called Matplotlib. This has loads of capability include log plots.

I use Matplotlib to graph the gain (in dbM on a linear scale) vs frequency (on a log scale).

When I tried this a bunch of things didn't work:

• I found that if I sent commands to the signal generator too quickly it would just ignore them! I had to add sleep commands to slow things down enough for this not to happen.
• At very low frequencies the scope automatically goes into 'roll' mode and is not able to make phase measurements.
• The output impedance of the signal generator would cause the signal at the input to drop at some frequencies. If the input impedance of the circuit under test is low at some frequencies the input amplitude drops and throws out the gain measurements. Instead I used the second signal generator channel to generate an identical input waveform and measured between this and the output.
• numpy.log() is the *natural* logarithm. I accidentally used this instead of log10() initially which threw all my gain calculations out (facepalm).
• I am manually setting the scope vertical adjustments but at regions of very low or very large gain I can't get phase or amplitude readings. I didn't fix this but ideally the script would adjust the scope's vertical range to correct for this.

Bode Plotting Things...

What can I plot? What about a bilinear active filter - like this:

So to understand what is going on imagine C1 and R1 are combined into an impedance (Z1) and C2 and R2 are combined into Z2. Then it is a simple inverting amplifier and the gain is just Z2/Z1,

At DC the capacitors are open circuits so the gain is 1 (0dBm) but at the peak the gain will be C2/C1 = 10 or 20dBm.

So because the gain is Z1/Z2 then we get a zero due to Z1 and a pole due to Z2. The corner frequency of the zero is 1/2 * pi * r1 * c1 which is 234Hz. Then the pole is calculated similarly and is at 2.3K Hz.

Here is the LTSpice Bode plot. There is an extra pole and zero created by the input capacitance of the of the op amp (I think). The actual amp I am using is a LM14588N so this will be different.

Here is the output of the bode-plotter:

It's not a totally silly approximation.  Unfortunate that the phase wraps but no matter. Still much study to do...

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...

Rohde & Schwarz SWP.339.0010.02 - Synchroniser

So in my last post I began debugging a fault with where the output of this sweep generator was stuck at one frequency because the 600MHz IF was disabled. This fault went away so I started debugging the next issue. I managed to make some progress before the 600MHz fault returned.

Playing with the Synchroniser

My main application for this unit as as a sythensizer and the sweep functionality isn't overly useful as I have the spectrum analyser with tracking generator. So now that the unit is generating an output I wanted to play with this.

Without the synchroniser enabled the output is miles off. 10MHz comes out as 7, 100MHz as 104MHz, 1GHz is nearly 15MHz off. My understanding is this is pretty normal as the YIG is hard to steer accurately.

With the synchroniser on the output is really close according my frequency counter. My counter can only count up to around 300MHz but at this frequency it is less than 20Hz off. No idea which of the two is more accurate at this point.

I noticed an anomaly however in that if I choose a frequency less than 20MHz the output was spot on. If I chose a frequency above this (like 20.001MHz for example) the output jumps off to 54MHz or so and wanders around. After experimenting a little I figured out that above 70MHz it comes back together again. So what is special about this frequency range?

Understanding the Synchroniser

The block diagram below shows the major functional components of the synchroniser. The bit highlighted in green is what I figured had to be in the signal path when it was going wrong.

The basic plan here is to take the output signal, divide it down enough that you can lock it to the reference frequency and then generate an phase error signal that can be fed back to the sweep board to adjust the frequency of the output. A big PLL in other words.

It's not that simple though as the frequency range is broad and because the unit can sweep rapidly across a range while maintaining lock on the reference. For now I'll neglect a lot of this detail and just focus on what was going wrong.

If the frequency is between zero and 20MHz the 97-122MHz VCO is locked with the reference and mixed with the 100MHz coming from the converter board to generate the output signal (doesn't use the YIG at all).

Over 20MHz it starts to look at the output signal and processes that down to something it can compare with the reference. There are three ways it can do this

• Take the output signal, filter it to cut-off anything above 70MHz and use this directly.
• Mix the output signal with a 1.2GHz signal produced by multiplying the 600MHz generated on the converter board. Then take the 0..700MHz output and divide this by 10 to give a 0..70MHz signal and process that
• Mix the output signal with a 1.8GHz signal produced as above and divided as above.

The path it chooses depends on the frequency range it is generating an output in. The first bit that is confusing is that the schematic shows the first of these paths as producing 0.1..70MHz where as in the 0...20MHz range a different path is used so this isn't true.

So in my case it had to be something in this 0.. 70MHz filter or the switch as everything else works in other bands.

Synchroniser RF Board

The synchorniser RF board is another fine work of RF voodoo. The multipliers and distributed element filters look pretty interesting although I have only the vaguest clue how they work.

Thankfully none of that mattered as I was looking at a relatively low-frequency path through this board. Here is a block diagram of just the RF section with the areas I was interested in high-lighted.

Now it did take some trial and error as well as head-scratching to narrow the schematics down to this. The other annoying thing is that two of the connectors on the RF board are the SMCs similar to the converter board but two are SMB connectors. I have patch leads for the SMCs but not SMBs so I also wasn't sure if what I was seeing was correct because things were disconnected.

As it turned out this wasn't a problem as the SMBs were generally outputs and even though the system might not have been working, the board I was looking at was running as it would if it were plugged in (and not up on riser boards).

The schematic below shows the low pass filter (shown as 100MHz but the other block diagram showed this as 70MHz).

The three amplifiers at the top marked D70 plus their associated components carried the signal in this 20..70MHz range. They use this ECL NOR gate chip (D90) as a sort of switch to control the signal path. One of the inputs is a control line and the other carries the RF signal.

Because this is ECL the logic levels are between -2.5V and ground which looks a bit odd at first but you get used to it.

At the top right are two gates (near R95 and R92) that feed into another one below (near R94). I was looking at the signals on the pins of D90 and it seemed like one of these gates wasn't switching it through. Eventually I figured out that pin 14, 7 and 4 should all have the same signal but they didn't.

I pulled the board out and checked continuity and sure enough there was no connection. Thankfully the chip was socketed so I pulled it out and checked continuity again.

It turned out that pins 14 and 3 are directly connected by a track and another track from 7 meets them at a via. The via was basically loose enough that it made intermittent contact. I soldered a jumper wire between the pins, re-tested and it basically worked.

Still more Problems

So at this point the unit is looking pretty good - the 600MHz problem seems to have gone and now the synchroniser problem is solved. All the self-tests pass and I can generate relatively accurate signals.

I did notice that if I used my spectrum analyzer to look at the output, as the frequency goes above 1GHz the accuracy gets steadily worse. At 1GHz it is less than 1MHz off but by 2GHz it is nearly 20MHz.

While looking at this and pondering if this is a fault or just a limitation of the device my 600MHz fault (self-test code 22 1C 00) came back again.

So I suppose I better look at that next!

Rohde & Schwarz SWP.339.0010.02

I have a new thing to fix! It's a sweep generator that can produce signals from 400kHz to 2.5GHz and -130dbM to +13dbM. It's very big, heavy, old and broken!

So What's it Do?

This thing is a specialized  sweep generator that can quickly sweep across a frequency range. In addition to the RF output the generator produces a voltage which is proportional to the output frequency that you can use as the X input to your oscilloscope in X-Y mode. This allows you to produce frequency vs amplitude response curves for filters, amplifiers etc using the generator and a scope. It's pretty much the tracking generator part of a modern spectrum analyser. R&S sell other bits of gear that work with this one to provide network analysis and other features.

The thing uses a YIG (Yttrium , Indium, Gallium) tuned oscillator to produce the output frequency since YIG oscillators can be rapidly tuned over a broad frequency band. Unfortunately they are not frequency accurate without additional circuitry. R&S sell a 'synchroniser' option which is pretty much a fancy PLL circuit that allows you to lock the output to a crystal oscillator to get frequency accuracy. My unit has this option fitted.

In addition R&S sold a marker option and while my unit is fitted with this option I've not really touched it. I think it generates pulses so you can create tick-marks on your scope at specific frequencies.

Another option is the mechanical step attenuator that allows the unit to generate a broad range of output levels. Mine is also fitted with one of these which is pretty nice and it makes an amusing array of clunks as you wind the knob to adjust the output level.

Physically the thing is massive - weighs nearly 20kgs and is packed with boards.  It's got a huge linear supply with a shielded torroidal transformer and the back panel (which acts as a heatsink) gets quite hot when operating.

It has a big bright LED user interface and lovely clunky keyboard interface. The adjustment knob feels lovely to use as it is really solid and has a gentle cogging that feels a bit like a turning a very soft stepper motor. The knob will easily whizz if you flick it and it comes to a gentle stop.

I found the user interface a bit confusing at first - still do really. You have three numerical displays which are the start, marker and stop frequencies. The keys have second functions that are activated by a second function button marked with a red circle. To get a constant frequency output you have to use the second function button for example. There is an LED marked RF off and a button. By default the output is on unless you hit RF-off and then the light comes on. I feel is exactly the opposite of what I would expect.

I had no idea what 'synchronizer' meant and assumed it was something to do with interfacing it to a network analyzer. 'Synthesizer' would have made more sense as that is what this option does - makes the unit a synthesizer.

Condition

Overall the unit is in pretty good physical condition for its age (I think it is an early 80s device). There are little bits of corrosion on some boards/connectors which is concerning but probably Ok. It's got minimal amounts of the usual cal sticker residue and the paint on the rear and top/bottom panels is in reasonable state.

The first time I turned it on it was apparent the switch is broken as I had to hold it in to keep the unit on. This might have been transit damage.

In the ebay listing the seller noted it displayed error 10 A when the self-test runs. Before I bought the unit I looked this up and found it indicates the settings battery is dead. Could I be that lucky? When I opened it up I found the battery is in fact a pair of AA alkaline batteries and they had not been replaced in such a long time that they have eaten their battery holder. The battery doesn't matter too much as it is only used to store pre-sets. The unit operates fine without it.

I connected the unit up to my spectrum analyzer to look at the RF output but unfortunately it didn't look like it was working. The output was constantly around 38Mhz regardless of the settings. Doing this test  required some creative operation  as I needed to keep my finger on the power button to keep the unit on!

Power Button

First things first - the power button had to be sorted out as I couldn't do anything sensible with  the sweep generator while holding the power button in. The power button is at the back of the unit near the mains input and is connected via a long shaft to a power button in the front panel.

Knowing the likely outcome I removed and disassembled the power button anyway. The main shaft that is pushed by the rod has a hole for a pin that implements the push-on/push-off mechanism and this hole had been wallored out from many years of use.

I started looking for a replacement but the switch was made by Petrick and they went out of business long ago. The other problem was I found it pretty hard to find the right keywords to specify a push-on/push-off  plunger type switch with a square rod. It also needs to handle quite a few amps at 240V.

Even if I could repair the existing plunger I don't think the one I had was going back together any time soon :)

In the end I found a replacement switch that is a KDC-A04 and they are pretty common in cheap Asian electronics. They have the right number of poles, roughly the right throw and the right size plunger. The one problem was the size of the tabs used to screw it down where different. I found I could get enough purchase under the screw on the opposite side (even though the screw didn't go through the hole) for the switch to be pretty secure. I did have to slightly shorten the plunger but it worked just fine.

No Output

I got a partial copy of the user and service manual before I bought the unit from the R&S yahoo forum. Unfortunately these included the first 20 pages or so and the manuals are a mixture of English and German. I realized quickly that I needed more and began looking around for the rest of the service manual. The most economical option was to buy the two service manuals for 20Euro each from an online vendor. The paper manuals were nearly triple that! That's actually more than I paid for the generator!

Once I got the service manuals and started reading the more I started to figure out the self-test mechanism. The generator has an extensive set of self-test lines and can localise faults to some extent by itself. The first error displayed was the battery failure but you can hit the clear key to get past this and see other errors.

The first error was a failure of the 600MHz IF. This explains the lack of output. The other errors were likely a result of this first error.

How it Works

So the YIG oscillator generates frequencies from 4.2GHz to 6.7GHz. The output is generated by mixing this with an internally generated 4.2GHz signal generated from the 10MHz reference clock. The YIG is then tuned by sweeping the control voltage to vary the output frequency. This is all achieved within one of the large, RF shielded boards called the converter board. The block diagram below illustrates how this works:

The process is broken into:

• A 100MHz VCO that is locked to the 10MHz crystal reference using a PLL
• A frequency multipler to generate the 600MHz
• A helical tuner to filter the 600MHz
• An amplifier for the 600MHz signal (as it is used elsewhere in the unit)
• A multiplier to generate the 4.2GHz signal from 600MHz
• A filter for the 4.2GHz 
• A mixer to combine the 4.2GHz with the YIG output

Debugging  down Rabbit holes

In my case the 600MHz was missing so I disassembled the converter and started tracing the signal through. The converter internally was quite interesting as it has a number of distributed element filters and a lot of hand construction.

Here you can see the 4.2GHz filter composed of the series of diagonal sections followed by a filter and at the top left is the mixer

The section at the top right is the 100MHz VCO and the bottom section to the right of the coils is the multiplier that generates the 600MHz from 100MHz. The  area at the top is the phase detector and frequency dividers etc that form the PLL.

The next trick was how to debug this. The case is quite closely packed so there is no hope of sneaking a scope probe down between the boards when they are in place. I found that R&S kindly supply a set of riser boards inside the unit that you can use to operate modules while they are up above the rest of the unit. The problem then is all the coaxial connectors that go in/out of the module which are all SMC (not SMA or anything common). I found a set of short SMC male to female patch leads that were perfect for the job on ebay. They look like this and allow me to connect the board to the coax cables inside the case

Running the converter board up on the extender boards with the patch cables plumbed in, I used a scope probe attached to my spectrum analyzer to measure what was going on. I found that the frequencies were way off. The 10MHz signal from the reference looked fine but...

The 100MHz was off a bit so instead it was more like 98MHz.

This got worse when it was multiplied so instead of 600MHz it was more like 589.

The output of the PLL PI filter was at the limits of the voltage range so clearly it was trying to force the VCO to 100MHz but couldn't. Because the 600MHz was so far off the filter was knocking it down a lot before it got to the next stage. Could this be the problem?

Apparently Not

I then looked at the service manual again. Apparently you can't operate the converter with the top cover removed as it effects the VCO (face-palm). Re-attaching the top cover and re-testing I found that the 100MHz signal was just fine as was the 600MHz coming into the following amplifier. What came out was pretty much nothing however. So in the schematic below the signal coming out of the 600MHz filter was fine but nothing was coming out of V82. What's more the test voltage at MP-10 and MP11 were off.

I also checked the circuit feeding V83 which is used to disable the 600MHz output (for example when re-tracing during a frequency sweep) but this appeared Ok.

So I ordered some BFR35 transistors and replaced V82 (feeling pretty sure this was it). I tested this again but no luck.

Intermittent

One really annoying thing about this unit is that the faults are very intermittent. I found that by fiddling with the controls it would randomly come good and start producing output. I figured out that the control that seemed to fix it was the one that disabled the output while the sweep re-traced.

I started monitoring the signal that disables HF output and looking at V249. See below.

On one of the occasions that this worked I realized that the 'HF off TTL' signal was effectively active-low. That is when the signal is high the HF is disabled and when it is low it is enabled. So actually when the signal coming in on pin C15 of the motherboard connector was high the output was disabled.

So actually the fault is elsewhere!

HF Enabled

The service manual is not much fun to read through. It's a huge file and so it is slow to scroll. The manual has been scanned as images so you can't search and it alternates the sections between English and German. Maybe this is because I don't have all  of the user manual but I couldn't find information anywhere that showed the location of each card. I had to effectively draw my own map by pulling each one out and comparing it with the drawings in the service manual.

Each schematic has the IDs of the connectors but then the cables have different designations and so it isn't always easy to figure out what signal is what and where it goes. The big block diagrams don't label the signals at all.

Now the HF off signal is referred to in other sections as HFSW1. There is also a HFSW and HFSW2 which are different! It turns out the HFSW1 signal is generated by the Sweep Control and Modulation amplifier.

So I connected up the sweep control and modulation board on the risers so I could start debugging this issue and half-way through I could no longer reproduce the fault. Before this I could re-start for the fault to return but now I can't in fact since then this fault has only come back a couple of times.

So I have to put this fault on the back-burner for now as I can't fix it if I can't reproduce it.

Next

So now it produces an but the frequency is pretty far off. The synchroniser does a good job of locking the frequency to the crystal but between 20.0MHz and 70.0MHz it totally looses it.

More debugging next time!