On this blog I have posted three previous entries related to the RX-888 (Mk2) which may be of interest to the reader:
 |
| Figure 1 - The (stock) RX-888 |
- Using an external clock with the RX-888 (Mk2) - link - On this page we detail the sort of signals that it takes to clock an RX-888 from an external source.
- Improving the thermal management of the RX-888 (Mk2) - link - This page talks about highly recommended modifications to the RX-888 to reduce internal heat to improve reliability.
- Measuring signal dynamics of the RX-888 (Mk2) - link - This is a discussion of how much (and little) signal is needed to stay within the dynamic range of the RX-888 and the effects of gain and attenuator settings.
- Frequency response of the RX-888 SDR at the high and low ends (above 30 MHz and below 1.5 MHz) - link - This page talks about how the RX-888 (Mk2) responds at very low frequencies (<1 MHz) and high frequencies (>30 MHz), including why an external low-pass filter may be a necessary addition and how to dramatically improve performance below 500 kHz.
Comment:
To date (12/24) I have repaired six RX-888s in which damage was done via the external clock interface - likely during the connecting/disconnecting of the cable in which the center conductor made electrical contact before the shield, inducing damaging voltages and currents into the clock. Replacing the Si5351 - and often the LVDS driver as well - restored these units to operation.
* * *
The "Thermal Dynamics" page referred to reliability issues experienced - possibly heat-related, but this page discusses vulnerabilities and repairs that may be needed if - when using an external clock - the device has stopped functioning.
Comment: There are many reasons why an RX-888 may not produce signals. One of the better, easier tools to diagnose/test an RX-888 is to use the SDDC "ExtIO" driver along with a problem like "HDSDR" on a Windows machine: A fairly fast computer (at least a quad-core Intel i7 at 3 GHz or better) is recommended and a USB3 port is required.
How did I know that the problem appeared to be due to no clocking of data from the A/D converter? On my Windows 10 machine I could see that the USB PHY enumerated properly, but the results of the waterfall/spectrum plot from HDSDR - and the fact that there was no difference in the (lack of) signal regardless of the frequency or sample rate - caused me to suspect such.
What finally clinched it was partially disassembling the '888 and probing it with an oscilloscope and finding the clocking to be absent from the A/D converter - and subsequent removal and probing under the shield covering the clock section.
Using the external clock:
Note: If your RX-888 failed after you have used an external clock, the damage described on this page may have happened to your device. If you have disabled the onboard 27 MHz clock (e.g. removed the jumper) you may wish to (temporarily) restore its operation for the purposes of diagnosing the problem and subsequent testing - and doing so is strongly recommended as it allow one to rule out other issues - particularly those that may be related to external clocking.
While the internal 27 MHz oscillator seems to be quite stable, there are instances where you might want to reference it to an external and more stable source such as that derived from a GPS or an atomic standard. Most commonly, this is done using one of the Leo Bodnar GPS-stabilized references allowing sub-milliHertz accuracy and stability across the HF spectrum.
 |
| Figure 2: Board |
Just above this is a jumper (green, in this case) which, when removed, disables the on-board clock so that the externally-applied oscillator does not conflict.
Reverse-engineering the clock circuit:
As
schematics for the RX-888 (Mk2) are not publicly available, exactly how
it worked was unknown and thus the type of external signal to be used
was unknown, found with trial and error. In the process of this repair I
had to figure out how the circuit worked, so here is a brief outline:
- The external clock input goes to a BAT99 dual diode (there is no blocking capacitor anywhere)
- one side grounded and the other side connected to the local 3.3 volt
supply: Under this shield, the oscillator, Si5351 and LVDS driver have
their very own 3.3 volt LDO regulator.
- From the BAT99, the external clock goes to the output pin of the
oscillator and to the clock input of the Si5351: The "enable/disable"
jumper simply disables the internal 27 MHz oscillator, putting its
output in a Hi-Z state which is why you get 27 MHz appearing on the
"external clock" connection if the onboard oscillator is enabled.
- The output of the Si5351 that feeds the main ADC goes to the LVDS
Driver chip (an SN65LVDS1DBVR) which provides buffering and biphase
clocking to the A/D converter.
- Also under this shield is a 3.3 volt regulator that provides power just for the Si5351 and LVDS driver to help ensure that their power supply (and clock signal) isn't "noised up" by other circuitry on board.
What seems to go wrong:
In the description you may note that the external clock input goes directly to the output of the crystal oscillator and also to the clock input of the Si5351 with no
blocking capacitor: There's the BAT99 dual diode that ostensibly
offers protection - but this is probably not the appropriate protection
device as we'll see: The BAT99 in conjunction with an appropriately-specified TVS diode (e.g. 4-5 volts) would have been better.
 |
| Figure 3: The clock section - under the shield. |
An RX-888 (Mk2) crossed my workbench that seemed "dead" - but critically, it would enumerate on the USB and would load the firmware, indicating that one of the apparent issues - that of the FX3 interface chip - appeared to be working OK. A quick check with the oscilloscope on the clock pins of the A/D converter showed that it was completely absent even with the internal clock enabled (jumper pins shorted). This indicated that the clock generator had failed in some way.
On
the RX-888 (Mk2) all of the clock generation circuitry - the 27 MHz
TCXO, the Si5351 synthesizer, the LVDS driver and a "local" 3.3 volt
regulator for the aforementioned devices - is located under the metal
shield. This was removed carefully using a hot-air rework tool and some large-ish tweezers to expose (and not disturb) the components underneath.
Figure 3 shows what's under the shield:
- The three terminal device in the upper-left corner is a BAT99 dual diode - one side connected to ground, the other connected to the local 3.3 volt supply.
- Just to the right of the the BAT99 diode you can see the metal can of the 27 MHz oscillator.
- Below it oscillator is the Si5351.
- To the right of the '5351 is the local 3.3 volt regulator.
- Just above the regulator - in an identical-looking package - is the SN65LVDS1DBVR LVDS driver.
With the shield removed, I could see that the 27 MHz clock (which was enabled by bridging the jumper) was making it to the input pin of the Si5351 synthesizer, but nowhere else. I could also probe the data and clock lines used for programming the Si5351 and when the firmware was loaded, I could see a brief string of pulses on each line indicating that the FX3 was attempting to program it.
At the time I had some "wrong" Si5351s available: I'd previously ordered a pre-programmed version (fixed frequency, non reprogrammable) by accident so I dropped one of those on the board (hot-air rework soldering) and was greeted with output signals (at the wrong frequency) but I observed that they stopped at the LVDS driver chip indicating that it, too, was dead: A signal was on its input, but only one output had anything at all and its output was only a few 10s of millivolts - possibly due to leakage from the input rather than the device actually doing anything.
Placing an order with DigiKey, I soon had in hand some proper Si5351s and a handful of the SN65LVDS1DBVR driver chips and dropped them on the board as well, restoring operation of this RX-888 (Mk2).
A few notes on chip replacement:
A modest hot-air rework station was used in the repair of this '888.
For removal of the defective parts, the board was set on a heatproof, stable service: My station has a set of aluminum bars with ridges to allow a board to be secured and sit flat. Using a pair of curved, ceramic-tipped (which have lower heat conductivity than metal) tweezers, just enough heat was applied to remove the defective device(s) once they had been appropriated warmed by targeted air from rework station's hot-air wand.
The defective devices remove, a very thin layer of solder past was added to the pads after removing the defective chip(s) and the new device was placed in position, being sure that the pin orientation was correct. Applying heat - but not enough air flow to cause the part to be blown out of position - the device will center itself once the solder melts and surface tension takes over.
Closely examining the part for solder bridges (magnification is helpful for this) and if there are some, apply a small amount of liquid solder flux (a low-residue "flux pen" is good for this) apply some heat from a clean, tinned iron through a small piece of "solder wick" whetted with flux should remove them.
What likely happened:
The key to the mode of failure is noting what had failed and how the components were related. As mentioned earlier, there is a "protection" diode (BAT99) connected between ground and the local 3.3 volt supply - but while this will prevent negative-going excursions, it is less effective in positive-going swings that exceed 3.3 volts as it dumps that energy into the local 3.3 volt supply. As the clock, the Si5351 and the LVDS driver are all on that same supply, it appears that much more than 3.3 volts appeared there, blowing up the '5351 and LVDS driver - and it is only by serendipity that the 27 MHz clock survived - likely due to its ability to handle much higher voltages by design (e.g. it may be 5 volt tolerant, built using a much larger fabrication process, etc.)
Obviously, the local 3.3 volt regulator survived as well - but one should remember that it, too, can take rather higher voltages on its input. Also note that typical regulators like this will only source current - they have no circuitry within to sink or clamp higher-than-expected voltages on their output so when the "high" voltage was applied to the clock input the BAT99 diode - and the protection diodes on the oscillator and Si5351 - shunted it to the 3.3 volt supply which is how the LVDS driver - which has NO direct connection to the external clock input - got destroyed as well from high supply voltage.
What probably happened to damage the '888 likely occurred when the external clock was being connected/disconnected. Typically, an SMA connector is used - mounted on one of the end panels - to feed the external clock into the unit but a problem with this type of connector (and others like the type "F" and "UHF") can make a connection with the center pin BEFORE the ground/shield is firmly connected.
What this means is that if there is a "ground" differential between pieces of equipment of several volts, this voltage can be dumped into the high-impedance and poorly protected input of the RX-888 (Mk2) as the connector is mated and tightened.
This voltage differential between pieces of equipment is actually quite common. Let us consider a possible scenario in which we have the following:
- An RX-888 connected to an antenna and a computer.
- An external clock source from a Leo Bodnar GPS reference that is powered by a different computer via the USB port and connected to a GPS antenna.
In the above we have four different "grounds" connected between the pieces of equipment:
- The receive antenna for the RX-888 may
be "grounded" somewhere - possibly distant from the local equipment
ground - say, at the entry panel where the antenna cable comes into the
building.
- The "ground" of the GPS antenna which may or may not
come in through the same cable entry as the RF antenna: If it comes in
elsewhere and is grounded at that point, that "ground" may have a
different voltage potential due to differential currents through the
local soil and/or building wiring. It is often the case that this
antenna isn't grounded at all, but "floating", with no connection
anywhere along the GPS signal cable except to the antenna and the
receiver.
- The "ground" of the computer connected to the
RX-888. It's unlikely that most users would think of tying their
computer chassis to an "earth" ground directly so it is either connected
via the safety ground (third prong on the power plug) or left floating - as in the case of a laptop or a computer with an external power supply (e.g. a "wall wart").
- The "ground" of the computer powering the Bodnar via USB. This may be the same as the computer running the RX-888, but if not, it may have a "different" grounding situation.
- If the Bodnar is powered not by USB but an external supply, it, too, may have a slightly different "ground".
The problem here is that what is called a "ground" colloquially does not mean that they are at exactly at the same potential: It is very common for a "ground" on an RF coaxial cable grounded some distance away nearer the antenna has a slightly different voltage on it than the wiring "ground" in a building: Ground has finite resistance and currents are always flowing around through the earth - and this is especially true during lightning storms where two "grounds" could be hundreds of volts apart for a brief instant if there is a nearby lightning strike.
The
other problem is that many computers may not be "grounded" in the way
that you think - particularly laptops small desktops powered by a remote
supply (e.g. a "wall wart"). Sometimes, these power supplies do
not have a DC connection between the "ground" pin of the mains supply
and the DC output meaning that they are "floating": Often - usually due
to EMI filtering of the switch-mode supply - this causes the DC output
to float at some (usually AC) voltage that may be many tens of volts away from the ground - a phenomenon usually caused by the (needed!) capacitors in the filter circuit. As these capacitors are often coupled in some way to the mains, they will conduct a small
amount of current - but if it's shorted to ground at the instant that
the mains voltage waveform is at a peak, the energy of the capacitor may
instantaneously be dump through that connection resulting in a very
brief - but surprisingly high - current spike, even if the capacitance
is quite low.
While the amount of current of the "floating" supply between its output and the "ground" (third prong on the outlet) is likely to be quite small, it can easily be enough to induce small currents through interconnecting cable. What's worse is that if you have two pieces of equipment - one being firmly grounded through its antenna such as the RX-888 and the source of the external clock which may be powered from a source that is "floating" as well - that when the connection is made between the output of the external clock and the signal source is made that there will be an elevated voltage: As it's common for the center pin of the cable to make contact first, this voltage - and the capacitors in whatever EMI filtering may be present on the "ground" of the device powering/connected to the external clock - will dump into the clock input of the RX-888 - and from there, into the other circuitry of the '888's clock circuit.
How to safely drive the RX-888 - or how to prevent this from happening again?
As it happens, I have already produced a blog entry on this very subject, so I'll leave it to the reader to peruse that article, found here:
Alternatively, you can get an external clock input board - which also provides a bit of protection - from TAPR - details here: https://tapr.org/product/rx888-clock-kit-and-thermal-pad/This kit also includes a large thermal pad that is strongly recommended to enhance the reliability of the RX-888.
No comments:
Post a Comment
PLEASE NOTE:
While I DO appreciate comments, those comments that are just vehicles to other web sites without substantial content in their own right WILL NOT be posted!
If you include a link in your comment that simply points to advertisements or a commercial web page, it WILL be rejected as SPAM!