Friday, 24 November 2017

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






Thursday, 10 August 2017

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!



Thursday, 3 August 2017

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

Friday, 28 July 2017

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!



Thursday, 20 July 2017

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!

Friday, 5 May 2017

Spring Scheduling

I had the need to implement a periodic process where the period between runs was configurable from a properties file. I am using Spring with XML descriptors so this is a brief how-to on getting this working.

Scheduler

Spring implements a task scheduler and a task executor. My understanding is you need both to run a scheduled task. To add one of these to your spring application you have to add the task schema to your descriptor like this:

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jpa="http://www.springframework.org/schema/data/jpa"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:task="http://www.springframework.org/schema/task"
       xsi:schemaLocation="
http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.1.xsd
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd 
http://www.springframework.org/schema/data/jpa http://www.springframework.org/schema/data/jpa/spring-jpa.xsd
http://www.springframework.org/schema/task http://www.springframework.org/schema/task/spring-task-3.1.xsd>

Then you add these lines to configure a scheduler and a executor. In my case I only wanted this to be executed in one thread.

        <task:annotation-driven executor="scheduleExecutor" scheduler="scanScheduler"/>
        <task:executor id="scheduleExecutor" pool-size="1"/>
        <task:scheduler id="scanScheduler" pool-size="1"/>

Scheduled Code

The code to be scheduled was created using an annotation. The class was annotated as a component and the method to be called was annotated with the @Scheduled annotation so spring picked it up.

The documentation describes how to use the fixedDelay, cron etc parameters to control how frequently the scheduled operation runs but I needed this to be controlled from a properties file. I found that I could use a property-placeholder to load a properties file and use this in the @Scheduled annotation.

First add the place holder in your XML above the component scan

    <context:property-placeholder location="WEB-INF/tuning.properties"/>
    <context:component-scan base-package="com.somecompany.myproject"/>

Then you can use the fixedDelayString argument to the @Scheduled annotation to access a property (called transactionScanTime in the tuning.properties file)

@Component
public class TransactionScanner
{
    @Scheduled(fixedDelayString="${transactionScanTime}")
    public void scanTransactions()
    {
        // ...
    }
}


Wednesday, 26 April 2017

Two repairs

So I recently did two more repairs although neither was terribly interesting and I didn't take enough photos. Still worth a quick entry though.

Sharp JH1600E Solar Inverter

I am a member of a small sailing club and a few years ago the government were offering what was probably a way to generous incentive for people to install solar panels. They would pay 66c per kW.h for the electricity you produce where here in Australia we pay around 25c when buying the same power off the grid. I signed up the sailing club and the unit paid itself of in around 18 months and then continued to pay healthy dividends for the next few years.

The scheme ended last December and now they only pay 6c per kW.h for electricity produce but we now have the option of changing to a nett metering system so we can consume the power we produce and save 25c per kW.h consumed.

The inverter also went out of warranty at about the same time and then within a few weeks of this it failed. We got quotes of between $350 and $450 for repairs but when we earn so little from the system this becomes a major outlay. Interestingly these units seem to fail often and there are a lot of broken ones on ebay. The company that repairs them seems to be doing a good trade.

I decide to have a shot at it. The concern is if I get it wrong the unit could catch fire and damage the sailing club (which is empty most of the week so nobody would notice until it was too late). Trusting that the circuit protection will save the club I had a go anyway.

There is a service manual for the unit here but it only contains a block diagram and no schematics. As you'd the service manual shows a DC boost converter (to level the DC voltage coming in off the solar array) feeding a full-bridge converter. There is loads of EMI protection (both DC and AC) plus transient protection. The system can monitor the DC voltage, AC voltage as well as the power being pushed back onto the grid. There are loads of temperature sensors so it presumeably can shut itself off in case of trouble.

The unit failed after a thunderstorm. The AC breaker had opened and the system reported an F01 error indicating it didn't have a grid connection. Restoring the breaker didn't fix it so I dug deeper and found there is a 20A fast blow HRC fuse between the breaker and the AC output of the unit and this had opened. I ordered some of these, replaced the fuse and the unit then detected the grid and began its sequence to connect to the grid. As it got towards the end it made a loud pop, opened the AC breaker and destroyed the fuse again.

My theory was that a MOSFET in the full bridge converter had failed short either due to heat (it has been *really* hot here last summer with days as high as 47C) or line transient.

Taking the unit apart wasn't much fun. You have to unscrew the end caps, undo the bolts holding the lower section on, undo the screws holding the outer extrusion on and lift it off. Then you are looking at the bottom of the board so you have to unscrew the heatsinks from the back panel and lift the board out (which is insanely heavy).

There is a digital board on top that interfaces with button, generates the warning lights and has the LED numerical display. The main board has a small daughter board that contains the controller for the main inverter but this is hard to access and soldered in. The main board is conformally coated also which made just getting continuity readings difficult.

After some poking around with a DMM I found one MOSFET that was a dead-short. Even though it was screwed to a heatsink I had to desolder the four MOSFETs on that heatsink and unscrew the heatsink from the board to get it out as there was no clearance to get a screwdriver onto the transistor.

Here you can see the heatsink desoldered and unscrewed. In the forground are the heatsinks for the AC EMI, the DC boost converter and .. actually I'm not sure what the other one is. Lots of fist-sized transformers for filtering. There are some massive capacitors for the DC coming in (left side) and loads of MOVs inside little sleeves complete with thermal fuses.

The transistor was a SPW47N65C3 from Infineon. Unfortunately it wasn't carried by RS or Element14 so I had to get one from Xon (via ebay) for an eye-watering $28.

There wasn't really a safe way to test this and in fact it was going to be difficult trouble shooting the unit unless I partially re-assembled it. I couldn't find anything else that looked suspicious so I took a chance and put it back together with the new transistor. Sure enough it worked fine (with a new fuse) so the repair was a success.

The only annoying thing was I somehow lost a space for the selection button and haven't been able to get that working again. Given how much effort it takes to disassmble and reassemble the device I decided I would fix that another day.

DENON DCM-270 Five Disk CD Player

This was my sister's CD player from the 90s that started to skip and have problems playing CDs. It got worse progressively until it wouldn't play CDs at all anymore. When I tested it the unit would spin up the CD, click the focus a few times and then stop and move on. It couldn't even read the table of contents.

I found a service manual for the unit complete with schematics and exploded diagrams. The schematic was truly awful - lines everywhere and the lines were so illogically laid out it made the whole thing really hard to follow. The device uses a bunch of special purpose ICs for controlling the motors, processing the signals from the CD mechanism and decoding the audio. Thankfully the manual showed internal block diagrams for these so you have some clue what is going on.

First off I checked the power supply and inspected the board. There was a big hots spot around the -26V supply and signs of corrosion near a capacitor. The capacitor measure ok in circuit and the voltages looked ok so I moved on (more on this later).



From some googling I discovered that the usual failure mode of these devices is the laser sled. They use a pretty common Sony KSS213C mechanism and these are available all over ebay. I ordered a replacement and parked the troubleshooting.

When the replacement mechanism failed I found that it worked worse than the original! The replacement mechanism didn't even spin the disk where the original at least tried to read.  I checked the motors and they were fine (I could make them go with my bench supply).

I started looking at the Sony chipset used to drive the CD mechanism and decode the signals. Meanwhile I was trying to understand how the mechanism worked and understand what was going on.

A Quick CD Player Primer

So the CD mechanism had connections for:
  • The disc motor
  • The sled motor (to move the laser)
  • Laser focus
  • Laser power
Then it had a bunch of other connections labeled A-E. It turns out these are opto-diodes and the way they work is quite clever. The opto-diodes are arranged as follows (see below - this was stolen from here ).
                     |<--- ----="" array="" photodiode="">|
                               +---+---+
   ---------_________ +---+  +-| A | B |-+  +---+
   Track--->          | E |- | +---+---+ | -| F | ________
                      +---+  | | C | D | |  +---+         ---------
                        |    | +---+---+ |    |           Track--->
                  /|    |    |   |   |   |    |
    Focus       / +|----|----+---|---+   |    |    
    Error o---<    |    |    |   |   *   |    |    |\
    (A+D)-(B+C) \ -|----|----|---+-------+    +----|+ \       Tracking
                  \|    |    |   *       |         |    >---o Error
              FE Amp    +--------------------------|- /       (E-F)
                             |           |         |/ TE Amp
    * Since the photodiodes  |           |           
      are current sources,   |           |         |\
      the simple junctions   |           +---------|+ \       Data Out
      implement a sum.       |                     |    >---o RF Test Point
                             +---------------------|- /       (A+B+C+D)
    All Amps: current mode inputs.                 |/ DO Amp

So there are 6 opto-diodes in total (A-F). The four centre diodes are used both the read the disk and to keep the laser focused on the disk. The laser optics cause the laser spot to become elliptical along one or other diagonal depending on if the focus is to close or too far. By comparing the power at A and D with the power and B and C you can tell if one diagonal has more brightness than the other. This tells you if you need to focus in or out.

The focus mechanism has to be accurate to within 1um (!!) and this is while the disk is moving at 500RPM and could even be a little warped (spin unevenly).

The E and F sensors are placed such that one is inward of the current track and one outward. By comparing the power detected by E an F the mechanism keeps the track centred. The track is a continuous spiral over the whole CD. The data on the disk is read by summing the four centre detector outputs (A-D).  

The encoding of the disk data is such that by tracking the signal edges you can detect the speed of rotation. The system uses this to manage the rotation of the CD and keep it at a fixed velocity (using a PLL).

CD Chipset and Debugging

The CD player uses a Sony CXA1782BQ for the RF signal processing and CD mechanism servo control and a Sony CXD2500BQ to handle the signal processing of the CD data.

I figured out that the CXA has a FOK (Focus Ok) output and with the original mechanism in the CD player this would go high while it tries to read the CD but with the new mechanism it didn't.

I assumed the mechanism was broken and worked with the original. I was trying to understand what was going wrong as clearly the motors were working and I could hear the laser focus operating.

I found there was an RF_O signal that is effectively the processed data signal coming off the CD. This is supposed to be very closely synchronized and you should be able to measure the jitter in the CD speed control by triggering the oscilloscope of either the positive or negative slope and viewing an 'eye' diagram of the signal. In the case of this CD player the signal was a total mess. You could see the waveform get shorter as it speed up the disk to try and lock onto the signal but it was like the waveform was moving up and down (i.e ripples at the top then bottom).

I looked at the FE (Focus Error) output but this too was pretty messy and it wasn't clear if it was failing to focus, failing to track or what. I wasn't sure if the problem was the mechanism or something else.

Mechanism

So I thought maybe the laser power was too low and this was why it couldn't get a good signal. I read that you can't really adjust the power without a power meter since if you even slightly over power the laser diode it will fail in a matter of hours. I took a risk and turned up the power on the new mechanism but it responded exactly as before (no focus).

Doing some more reading I found out that new mechanisms are sold with a solder bridge across a critical spot on the board. This is to prevent damage from electrostatic discharge through the board during transit. I found this guide explaining where the bridge was located and how to remove it. With some excitement I removed the bridge on the new unit and installed it in the CD player. Unfortunately while it now spins the disk it still didn't read the CD. Basically it was the same as the original mechanism.

There is a FE (Focus Error) bias adjustment pot on the board and I tried changing this. I noticed that if I adjusted this I could make the problem worse but not better. When it was worse the player wouldn't spin the disk or would give up reading the TOC sooner.

Back to the Power Supply

Removing and re-fitting the laser unit is quite difficult and requires the removal of a number of connectors from the main PCB and removal of the CD loading mechanism from the chassis (as you can only access the laser unit from the bottom). I had done it a few times now and at some point I must have left the power connector for the front panel off and when I re-connected it the VFD didn't come on.

I decided I needed to tackle this. The VFD supply is powered by a separate transformer tap but is referenced to a -28V supply generated from another transformer tap. After a bit of poking around I realized this was missing. The -28V supply is generated with a pretty dumb linear supply consisting of a PNP transistor and a 27V zener diode. It turned out the zener was a dead short in both directions so I replaced it. This brought the supply back and now the VFD worked again.

The CD reading still didn't work however. While looking at the RF_O signal I noticed that even when it wasn't reading a CD there was a bit of noise. The noise looked like a 2MHz signal but only at about 200mV. At some point it dawned on me that this is actually a pretty significant proportion of the RF signal amplitude and is probably why the signal is so messed up.

I then proceeded to go hunting for the source of this noise. I think in part I ignored this before as I assume it was just bad grounding but even with the ground point closer to the power supply section the noise is loud and clear.

The CD Player has +14V, -14V, 8V which is generated by a monolithic regulator and 5V which is generated from the 8V by the motor driver chip and the -28V I fixed above.

The corroded cap in the image above was part of the -28V circuit so I decided I would replace it anyway. I pulled it out of circuit and the ESR measurement was through the roof at over 10K plus the capacitance was way off what it should be. I replaced it but the noise was still there (maybe a little less).

I found the 8V signal was most noisy and the 5V signal was also pretty noisy. There is a transistor controlled by the motor driver that generates the 5V line and this had an output capacitor. This tested Ok in circuit but I replaced it anyway. When I pulled it out of circuit the capacitor measured way off spec and again a very high ESR.

Replacing this capacitor fixed it! The RF_O signal now looked as it should and the CD player played CDs! I stepped through tracks and left it running for about an hour and all was well. I replaced a few more capacitors that looked suspicious but overall this was the extent of the repair.

So at least I learned a few things about CD players. I now have a spare Sony CD mechanism too.