Electronics > Repair

CMU200 Rohde & Schwarz hangs during BaseDiscoverOptionsBegin

(1/9) > >>

RF_fanatic:
As the topic mentions this deals with the CMU200 from Rohde & Schwarz which hangs during startup.

This is a quite often occuring bug so I will deep into some details of it and will restrict the fault to plugin level.

The CMU is packed with modules and each module also packed with plugins so how to search for a fault....

The problem manifests itself as a hanging serial number detection during BaseDiscoverOptionsBegin eventually it will continue and even will mention the correct serial number but it takes time..... a lot of time..... while this normal would be done instantly.

So what is holding it?

As I have sort of specialized myself in the CMU and want to get to know every detail of it I was able to make a CMU test bench so I can quickly identify broken of defective modules and plugins.

It was not directly my intention to sort this specific problem out but as others on this board mentioned the same problem I decided to give it some more priority and narrow the problem down to plugin level and hope others will pick up where I stopped. Eventually I will also focus on repair of it but as I have so many projects running I just have a lack of time.

So lets cut the crap and start digging :

When you had enough patience to eventually load the serial number you will often find problems like dsp.cpp error or similar red screens on the CMU.

This allready gives you information that focussing on the dsp module would be interesting. By swapping the DIG module with a know good unit it an be confirmed that the DIG module is causing the problem.

Opening the DIG module you will see multiple plugins, the number will depend on the installed options.

The unit with 1100.3220.02 is the cause of the hickup

I have tested multiple not starting DIG modules and all come down to the 1100.3220.02 unit


richnormand:
I got a similar behaviour (with the same message. Perhaps about 10 minutes of delay. I will check tonight on the exact file name. That was with SW 5.03) in the course of fixing mine, but that issue went away when I decided to make a disk image (with several reading in case of read errors, and use a different drive.  It has been working for over a month now with no problems.

Could it be that the same error message screen be due to multiple causes, module hardware and/or corrupted software read from the HDD, bad data loaded to the eeproms or something else too?

Also posted here to be able to follow the thread.

Cheers and have fun!  :)

EB5AGV:

--- Quote from: richnormand on November 17, 2016, 11:02:17 pm ---I got a similar behaviour (with the same message. Perhaps about 10 minutes of delay. I will check tonight on the exact file name. That was with SW 5.03) in the course of fixing mine, but that issue went away when I decided to make a disk image (with several reading in case of read errors, and use a different drive.  It has been working for over a month now with no problems.

Could it be that the same error message screen be due to multiple causes, module hardware and/or corrupted software read from the HDD, bad data loaded to the eeproms or something else too?

Also posted here to be able to follow the thread.

Cheers and have fun!  :)

--- End quote ---

Yes, I think so. I have also a faulty CMU-200 with a similar problem. I also opened the DIGITAL board, which on my case was plenty of black dust, and carefully cleaned it along all the modules. But it still fails.

I have in the mail a new hard disk with working software for the CMU, so I will check if it is a matter of software of hardware fault. I guess the later... but I will know for sure soon.

I will let you know my findings. I guess that we can team to find a solution for this problem  :)

Regards,

Jose

SoundTech-LG:
Our (RF Lab) just obtained a CMU200 from another lab. We're trying to set it up and use it , so unsure of it's status so far. Will report back any problems we see...

RF_fanatic:

--- Quote from: richnormand on November 17, 2016, 11:02:17 pm ---I got a similar behaviour (with the same message. Perhaps about 10 minutes of delay. I will check tonight on the exact file name. That was with SW 5.03) in the course of fixing mine, but that issue went away when I decided to make a disk image (with several reading in case of read errors, and use a different drive.  It has been working for over a month now with no problems.

Could it be that the same error message screen be due to multiple causes, module hardware and/or corrupted software read from the HDD, bad data loaded to the eeproms or something else too?

Also posted here to be able to follow the thread.

Cheers and have fun!  :)



--- End quote ---

In my case (serveral units) the problem was 100% produced by a dead plugin module in the DIG board. In my CMU test bench I have kept the harddrive identical during all tests. just swapped the plugin as mentioned before.

But I have seen many problems with CMU's, a failing HDD is not very common, (only seen it once), one of the things I noticed when I suspected software issues I could "repair" them by using the function "delete non volatile RAM" and using scandisk both in the version manager environment.

It would be interesting if you place your original HDD back and do these things. If it starts hanging again than it can be confirmed that a HDD can also cause this.

Back to the dead plugin unit: The components are very dense and also some ball grid arrays are applied, so I'm a little bit affraid that one of the difficult components are the cause.

 

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod