Electronics > Repair
CMU200 Rohde & Schwarz hangs during BaseDiscoverOptionsBegin
richnormand:
"sometimes suffers from worn out capacitors. Check them."
That would be appropriate indeed.
On mine the small fan was completely seized up. I had to test all the caps but only found one that was marginal. There was a tell-tale temperature sticker on one of the chip that was indicating an overtemperature to its max indication.
Also some of the ribbon connectors were at an angle. So I systematically reseated everything on the whole unit that I could get my hands on.
Radiosonde:
Thanks for the hints so far, and a happy new year all around!
I did so far:
Cleaned all modules and checked all connectors
Replaced BIOS battery etc.
I found that one module on the DIG board causes the CMU to hick up, as described above.
I started with removing all extra modules from the DIG board, now the CMU boots up quick as normal an even passes selftest, as long as it doesnt get to a "spectrum analyzer" function, here it will show me an error "dsp.cpp" "ddc_drv" or similar.
According to the service manual the DIG board hosts the following modules:
-ADC
-DDC
-TXDSP
-AUC (directly above TXDSP with the cooling mat on it, havent marked it in the image)
it is possible to have each module twice as an option, therefore the extra connectors.
The unit boots up normally only if the DDC module isnt fitted, otherwise it will take an eternity..
As said, without the DDC module everything seems fine until I start the spectrum analyzer or the unit itself tries to do so (selftest) which seems logical as the DDC module is there to preprocess the datastream it gets from the ADC.
From the service manual: (courtesy of Rohde & Schwarz)
"The sandwich DDC MODULE1 is directly plugged onto the DIGITAL
BOARD via three multipoint connectors and processes the digital data
stream of the receiver. In a special ASIC chip, the I/Q shaping, the
matching of the data rate and the respective filtering (bandwidth
shaping) of the digital data stream are produced. Then follows a DSP
(RX DSP) with further evaluation of the digital I/Q data for
measurement purposes. Besides, the digital I/Q data are passed on via
the MOTHERBOARD1 to the LINKHANDLER MODULE for evaluation."
I started to reverse engineer the module, and checked all the supply voltages which seem to be correct.
So I guess this isnt repairable at all, at least not without schematics and programmed spare parts.
What would the experts do?
Change the whole DIG assembly or is there a way to get hold of just the DDC board?
Regards
sardonyx:
Thanks RF_fanatic. I recently bought this tester. It looks like I have the same problem with the TXDSP module. CMU200 hung during BaseDiscoverOptionsBegin for about 5 minutes. I disassembled and cleaned the DIG board. And then by the method of elimination, I realized that the matter was in the indicated board. Without it, the device boots immediately. But now the problem is that the signal generator does not work (it did not work before).
Initially, I thought that the problem was in broken blocks on, or it was in the firmware. But it looks like a hardware problem.
I have not yet found where to buy a replacement board. And I want to try to find out what is wrong with it and maybe try to fix it. Does anyone have any ideas on this where to start or experience with a successful repair?
There are definitely no BGA chips on it. I looked at the board under a microscope - all the elements and connections are in order. At first glance, everything looks working.
sardonyx:
My attempt to repair the DIG-TXDSP board
I bought a CH341a programmer and tried to read the EEPROM with a clip - it was read without problems. From which you can see the following information.
DIG-TXDSP
VER ALTERA=05.01
BD_RAM_K=0256
DS_CKMHZ=100
DS_TYPEID=56303
DS_MASKNR=0K36ADS_HASVSL
Judging by the fact that this information corresponds to the board, I concluded that it is read correctly, there are no reading errors and there is no point in changing the EEPROM. Also, the most likely reason, as it seemed to me, is the failure of the SRAM. My CMU200 worked for more than 15k hours. And it is likely that the number of read/write cycles of SRAM has exceeded a certain limit. After which the crashes begin. Having made this assumption I decided to change all the memory chips on the board. They are relatively inexpensive. But I didn’t want to guess which one had failed and how long the other chips would last. Therefore, I ordered 6 microcircuits from Ali and replaced them immediately.
I must to say that original chip was CY7C1019CV33-10VC and I bought almost the same CY7C1019CV33-12VC. The only difference is a time for rising edge. For the first one it is 10ns, for the second one it's 12ns. I didn't know would it will work or not, but I dicided to risk.
To replace it, I also purchased an Aoyue 1257 hot air nozzle to heat only the ICs contacts. Aluminum foil were also useful to protect the plastic elements from overheating. To solder new SRAM ICs to PCB I used 1.0 mm microwave solder tip.
But these actions had no effect. Any ideas?
Bicurico:
Congratulation for your efforts, I am reading this with great interest, as I have several of these boards broken.
Unfortunately, I fear that the culprit is the Altera FPGA. Not sure if these are pre-programmed or if their FW is loaded during boot. This is just a guess, though.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version