Author Topic: CMU200 repair attempt - boot error, stuck on "stuc.cpp".  (Read 5198 times)

0 Members and 1 Guest are viewing this topic.

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« on: October 12, 2020, 07:59:31 pm »
Hello,

I have recently decided to buy a CMU200. The first unit received lethal damage during transport and is waiting for spare parts. While having difficulty obtaining the parts, have decided and was able to buy another unit "for repair" I'd say ultra cheap.
(More about the first unit in this thread: https://www.eevblog.com/forum/rf-microwave/cmu200-repair-attempt-shipping-damage-(oh-those-post-monkeys-)/ )

So what is wrong with the unit? Description from the auction was "does not turn on". Turned out, it does turn on fine, but the LCD backlight has failed. Unfortunately, it is not the only error, the unit is failing with an error prompt like this:

1087938-0

What may be causing this issue? From my brief investigation I have done so far, this error might be caused by improperly connected ribbon cables in between the motherboard and the backplane. As someone has been inside the unit before I was, I have checked they are properly seated in their respective sockets. So likely not an issue there.

What else do you suggest to do or check?

Also, why the back side VGA ("monitor") connector seems to be dead? I though I could use an external monitor, until I fix the backlight. But it seems, there is no signal there.

Many thanks,
Jan

//EDIT: Have tried putting the HDD to PIO mode 0, no helper there. Seems the issue is likely not with an HDD.  Version manager can be accessed normally. How to troubleshoot further?

//EDIT: Have unplugged and reseated those three ribbon cables from the PCMCIA module. No change. Will look at the ribbon cable in the X215 socket - got a tip it may also be a contributing factor.
« Last Edit: October 12, 2020, 08:36:19 pm by Yansi »
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #1 on: October 15, 2020, 07:32:22 pm »
After some more checking, a fraeakin ribbon cable was half-plugged. Its retaining force is very low, so it may have jumped out during transport. Likely needs replacing the cable, and fitting new connections. (It is the cable that goes I think from the backplane to the input switching/attenuator module). After reseatign the cable, it fully booted! Yaaay!

After some more poking around in the computer, I have backed up the HDD drive. Fixing the backlight was as simple as replacing a fuse on the DCDC converter module - of course by another fuse, not a piece of wire. (Happened to have a fitting 1.6 A fuse, original one was I think 2.0 A, but the current draw seems to be just under 900 mA).

So now playing with the menus, feeling like a lost kid inside a shopping mall: How the hell do I make the spectrum analyzer work? All I see is an empty screen like this. If I happen to somehow switch from RF spectrum mode to Power vs. Time mode, it shows a trace. But, why is there no trace in the spectrum view? Am I missing some config?

Thanks for any hints.

//Note: The CCFL tube/s are pretty worn out, in desperate need of replacement. Probably a LED mod? Anyone attempted that?
 

Offline bdunham7

  • Super Contributor
  • ***
  • Posts: 7969
  • Country: us
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #2 on: October 15, 2020, 07:53:11 pm »
Which lights are lit up near the RF connectors?  You can go into the connect control menu and select which connectors are the inputs and outputs for the various modules.   The way you have it I think you should get a reading if everything is connected right.
A 3.5 digit 4.5 digit 5 digit 5.5 digit 6.5 digit 7.5 digit DMM is good enough for most people.
 

Offline Qw3rtzuiop

  • Regular Contributor
  • *
  • Posts: 220
  • Country: de
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #3 on: October 15, 2020, 08:21:13 pm »
Missing trace is most probably caused by a broken DIG board.

The CCFL tube is easily accessible.
You can replace it with led strips like this one:
https://www.ebay.com/itm/1Set-All-new-490mm-LED-backlight-strip-kit-update-CCFL-LCD-screen-to-LED-moni-ek/402334632262
Ive done that but i used an lm317 as a cc driver. That way you will lose the brightness control but it doesnt bother me. You just need to cut these strips.

Shahriar did a nice video on that topic:
« Last Edit: October 15, 2020, 08:31:01 pm by Qw3rtzuiop »
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #4 on: October 15, 2020, 09:14:49 pm »
Which lights are lit up near the RF connectors?  You can go into the connect control menu and select which connectors are the inputs and outputs for the various modules.   The way you have it I think you should get a reading if everything is connected right.

Already found out. The menu system is not that bad. Needs a bit of a learning curve, but now I can swim through it. The IO configuration is pretty nicely done.  Funny thing - RF in 2 was clearly used most, as the LED near it clearly has slightly lower luminosity, than others :)

Interesting thing happened - just after I've finished writing the missing trace complaint, the trace magically appeared. WTF
Later I have found, that if I gently tap the backplane under the RXTX board, the trace appears/disappears. Jeeez, love these electromechanical issues.  ::) :-\ :box:

Now it is in a state, where I can't invoke the failure by tapping the backplane.  ??? So it better stays working like it is now, or .... I will have a lot to debug.

After that, I have run through the Maintenance menu and tried all permissible tests. Luckily, NO errors and all passed, including the problematic DigiBoard and RxTx module.

But still haven't figured one thing out: How the heck do I change the Y axis scale (dBm) in the spectrum analyzer view? Setting the ref level has no effect on it.  :-//

The CCFL tube is easily accessible.
You can replace it with led strips like this one:
https://www.ebay.com/itm/1Set-All-new-490mm-LED-backlight-strip-kit-update-CCFL-LCD-screen-to-LED-moni-ek/402334632262
Ive done that but i used an lm317 as a cc driver. That way you will lose the brightness control but it doesnt bother me. You just need to cut these strips.

Shahriar did a nice video on that topic:


I think there is no brightness control, when I have diagnosed the faulty CFL converter, I think the brightness control pin was grounded directly on the other board (at least the multimeter measured short to ground on that pin). Here is the datasheet of the original inverter module, that was used inside my unit: http://www.farnell.com/datasheets/321020.pdf

The LED mod certainly seems more logical as an upgrade, instead of a CFL tube (that is otherwise also quite easy to get hold of).



And looksie what we have! An RF spectrum with an AM modulated signal in it! (loopback from the internal generator)
 

Offline Qw3rtzuiop

  • Regular Contributor
  • *
  • Posts: 220
  • Country: de
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #5 on: October 15, 2020, 09:26:05 pm »

But still haven't figured one thing out: How the heck do I change the Y axis scale (dBm) in the spectrum analyzer view? Setting the ref level has no effect on it.  :-//

To change the ref level you have to disable the auto ref level (its enabled on your screenshot). Otherwise the manual selected value has no effect.

 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #6 on: October 15, 2020, 09:31:55 pm »
But still haven't figured one thing out: How the heck do I change the Y axis scale (dBm) in the spectrum analyzer view? Setting the ref level has no effect on it.  :-//

Bingo! One needs to select MANUAL mode for "RF MODE" in the "Analyzer Level" menu.  :palm:
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #7 on: October 15, 2020, 09:57:11 pm »
So another strange thing:

Is it normal I get a quite significant crosstalk from the internal generator to the analyzer?

If I set the generator a 1GHz 0dBm tone from RF out 3, I get  like -35dBm on the spectrum analyzer, without any cable connected to the front N connectors.

If I connect RF out 3 to RF in 1 (where the analyzer listens at), no change in signal amplitude. Like if the RF out 3 is dead.  ???

If I select generator RF out at RF out 2, then the crosstalk is still bad, about -40dBc. But if i now connect RF port 1 to port 2, I get the level correctly.

What the heck is going on there?
 

Offline bdunham7

  • Super Contributor
  • ***
  • Posts: 7969
  • Country: us
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #8 on: October 15, 2020, 11:24:25 pm »
So another strange thing:

Is it normal I get a quite significant crosstalk from the internal generator to the analyzer?

If I set the generator a 1GHz 0dBm tone from RF out 3, I get  like -35dBm on the spectrum analyzer, without any cable connected to the front N connectors.

If I connect RF out 3 to RF in 1 (where the analyzer listens at), no change in signal amplitude. Like if the RF out 3 is dead.  ???

If I select generator RF out at RF out 2, then the crosstalk is still bad, about -40dBc. But if i now connect RF port 1 to port 2, I get the level correctly.

What the heck is going on there?

I would expect you need to terminate the RF output, not just leave it open.  And perhaps there are additional issues with the unit. 

EDIT:  I just checked on mine.  With open connectors and a +13.0dbM 350MHz signal on RF3 and the SA on RF2, I get a -95dbM reading against a -105dbM noise floor.  At 1GHz, I get -60dbM.  Termination didn't make a big difference, perhaps 3-5dbM.
« Last Edit: October 16, 2020, 12:12:29 am by bdunham7 »
A 3.5 digit 4.5 digit 5 digit 5.5 digit 6.5 digit 7.5 digit DMM is good enough for most people.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #9 on: October 17, 2020, 05:09:52 pm »
Hello,

so I have done a few more tests to try to determine what may have gone belly up in the input RF module.

First, I have tested the spectrum analyzer, on each of the three input ports 1, 2 and 4. On all of these, signal path is OK, signal goes through. Just one note: There is decent crosstalk from port 4 to port 2. Is this normal? Applying 2GHz -10dBm from external source to port 4, analyzer listening on port 2 I get about -50dBm (just about 40dB attenuation). In the opposite direction, -10dBm 2GHz into port 2, analyzer listening on port 4, there is about -70dBm  (60dB down). Is this normal?

By looking at the input section block diagram, I think this is OK, as obviously, the switch circled green is the only one providing port isolation in between port 2 and 4 in the receive path. In the opposite situation there are two switches providing the isolation (the other one below the circled one), hence I see double (60dB) the attenuation. Good, this makes sense.



Now on to the more interesting stuff:
Test with connectors open:
Analyzer listening on port 1. Internal generator output +13 dBm 350 MHz on port 3: Analyzer reading -42 dBm.
Analyzer listening on port 1. Internal generator output +13 dBm 1000 MHz on port 3: Analyzer reading -22 dBm.
Analyzer listening on port 2. Internal generator output +13 dBm 350 MHz on port 3: Analyzer reading -82 dBm.
Analyzer listening on port 2. Internal generator output +13 dBm 1000 MHz on port 3: Analyzer reading -57 dBm.
Analyzer listening on port 4. Internal generator output +13 dBm 350 MHz on port 3: Analyzer reading -95 dBm (noisefloor).
Analyzer listening on port 4. Internal generator output +13 dBm 1000 MHz on port 3: Analyzer reading -83 dBm.
Red marked values look suspicious.

So lets test more, now always connect respective RF ports together with a cable:
Analyzer listening on port 1. Internal generator output +13 dBm 350 MHz on port 3: Analyzer reading -42 dBm. Like without a cable!.
Analyzer listening on port 1. Internal generator output +13 dBm 1000 MHz on port 3: Analyzer reading -22 dBm. Like without a cable!
This certainly does not look right at all. Like no signal coming out. Connecting external spectrum analyzer to RF port 3 shows there is just -44 dBm signal at 350 MHz and a much stronger -35 dBm second harmonic.

So, we definitely have a dead RF out 3. Shiiiiit.

Trying to output the RF gen on port 2 and measuring it externally shows about the correct amplitude. So does when the generator's output is set to port 1.

Interesting things only happen when both the generator and analyzer are on the same RXTX port 1 or 2. It screams input overload and shows much higher input level then it is in reality. Not sure if it is due to the internal construction of the frontend or what.

Now I'll try to figure out what RF switch may be dead inside the frontend.


 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #10 on: October 17, 2020, 07:23:40 pm »
So, looking at the signal flow diagram from the service manual, few obvious things are apparent:

If you want the most of RX to TX isolation, you shall use the RF3OUT and RF4IN ports on the CMU.

There is just one likely path of the crazy TX crosstalk (from port 3) to the RX port 1, as per the diagram below. Port 1 in RX mode is the green path, port 3 in TX mode is the pink part. Likely path of leakage is the red circled RF switch.

Also, poort isolation from RF3 to RF2 can be explained by just two switches isolating the ports from each other - which is about in the expected ballpark of attenuation, as seen from other tests. Can someone please confirm, what is the isolation from RF3 to RF2 at 1 GHz?

I have gone one step further and removed the frontend assembly from the CMU. Luckily it is easy to both remove and disassemble. Even can be plugged back in without the cover, leaving the board easily accessible for probing. That is good!

Photo of the frontend below. I have expected to see charred component, but nope. Even at a close inspection, I see no burnt stuff. The signal path for RF3 port and RF1 port can be clearly identified on the board. The red circled switch is the MACOM SW-279 and the output amplifier was identified as NGA-589.

I can even see the diode amplitude detector near the four-path divider on the RF1 port path. Good to know the signal diagram from the service manual matches very closely.

 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #11 on: October 17, 2020, 07:44:48 pm »
So one step further:

Both MACOM SW-279 switches has correctly switching control voltages of 0V / -10V.  The RF3OUT port's amplifier get correctly switched on/off based on the output port selection.

What is a bit strange is that the bias voltage across the device is just about 2V. What does the datasheet say about this?

Datasheet says: Nope! Device operating voltage is about 4.9V. So, is just the output amplifier shot?



Could somebody please test these two things for me?

Set RFge in CW out +13 dBm (full blast) at 1GHz to port RF3OUT. What level is the signal at the analyzer on channel RF1 and on channel RF2?

//EDIT: Seems Rohde omitted RF port isolation figures from their specsheet. All I could find is this thread, confirming that RF3 and RF4 ports have the widest separation. Which is undoubtedly correct.

https://www.eevblog.com/forum/testgear/rs-cmu200-high-crosstalk/
« Last Edit: October 17, 2020, 08:04:38 pm by Yansi »
 

Offline YU7C

  • Regular Contributor
  • *
  • Posts: 76
  • Country: cs
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #12 on: October 17, 2020, 08:03:36 pm »
Hi Yansi,

While your Rx/Tx front module is still open, could you measure value of resistor in the input attenuator of RF4IN?

Vojislav
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #13 on: October 17, 2020, 08:25:33 pm »
The DC resistance measured from the RF4 port is 98.5 ohm, the series resistor is marked as "16R2" so assuming a 16.2 ohm, and from the other side of the attenuator measured across the shunt resistor is 82.3 ohm. Not sure what is on the other side, where else does it go.

Does this help any amount?

EDIT: assuming it is a 50ohm both ends attenuator, then it well may be a about 2.77 dB pad, where the series resistor is 16.2 ohm and shunts are 315 ohm. Both values from E96 series, giving a pretty good impedance match.

//EDIT2: Now looking at the photo closely, the pin solder joint is halfway cracked, so I have retouched it.
« Last Edit: October 17, 2020, 08:30:52 pm by Yansi »
 
The following users thanked this post: YU7C, YU7Q

Offline YU7C

  • Regular Contributor
  • *
  • Posts: 76
  • Country: cs
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #14 on: October 19, 2020, 04:48:49 pm »
Thank a lot for measurement!

In the attachment you could find  schematic of RF4IN.

I am trying to do math of shunt resistors with values you're measured, but unfortunately I don't have a luck. Always got equation w/o solution.

If you're measuring 98.5 Ohm on input it seems that shunt resistors have larger resistance (kohm)?

EDIT: Perhaps R1&R3 in schematic are capacitors and attenuator is T topology?

Vojislav
« Last Edit: October 19, 2020, 05:07:38 pm by YU7C »
 

Offline bdunham7

  • Super Contributor
  • ***
  • Posts: 7969
  • Country: us
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #15 on: October 19, 2020, 05:44:32 pm »
Could somebody please test these two things for me?

Set RFge in CW out +13 dBm (full blast) at 1GHz to port RF3OUT. What level is the signal at the analyzer on channel RF1 and on channel RF2?

Using a 1GHz center, 100MHz span and 10kHz RBW, I get about -35dbM against a -90dBm noise floor on RF1 and -70dbM against a -105dbM noise floor on RF2.
A 3.5 digit 4.5 digit 5 digit 5.5 digit 6.5 digit 7.5 digit DMM is good enough for most people.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #16 on: October 19, 2020, 07:36:18 pm »
That measured values seem a bit different than what I have measured, don't they?

Quote
Analyzer listening on port 1. Internal generator output +13 dBm 1000 MHz on port 3: Analyzer reading -22 dBm.
Analyzer listening on port 2. Internal generator output +13 dBm 1000 MHz on port 3: Analyzer reading -57 dBm.

I may have a bit more of toast in the RF frontend PCB.  Strangly, all receive paths seem to work absolutely fine (haven't checked the noise floor though).

Thank a lot for measurement!

In the attachment you could find  schematic of RF4IN.

I am trying to do math of shunt resistors with values you're measured, but unfortunately I don't have a luck. Always got equation w/o solution.

If you're measuring 98.5 Ohm on input it seems that shunt resistors have larger resistance (kohm)?

EDIT: Perhaps R1&R3 in schematic are capacitors and attenuator is T topology?

Vojislav

I think the measurement I have done may not be enough to determine the values. Do you know what components are on the other side of the board?

I did not want to desolder any of the resistors, but it seems I will need to desolder at least the 16.2 ohm resistor, otherwise there is no way to tell what values the shunt resistors have.  :-// But that measurement will have to wait to at least by the end of week. Currently I am outta my home lab.

//EDIT: R1, R3 unlikely to be capacitors.
« Last Edit: October 19, 2020, 07:38:33 pm by Yansi »
 
The following users thanked this post: YU7Q

Offline bdunham7

  • Super Contributor
  • ***
  • Posts: 7969
  • Country: us
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #17 on: October 19, 2020, 07:58:31 pm »
That measured values seem a bit different than what I have measured, don't they?

Yours are 35db apart, just like mine.  Make sure you are using the exact same settings--100MHz span, 10kHz RBW (the minimum at that span), RMS detection (not peak) and see where you are. 
A 3.5 digit 4.5 digit 5 digit 5.5 digit 6.5 digit 7.5 digit DMM is good enough for most people.
 

Offline capt bullshot

  • Super Contributor
  • ***
  • Posts: 3033
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #18 on: October 19, 2020, 08:00:34 pm »
So one step further:

Both MACOM SW-279 switches has correctly switching control voltages of 0V / -10V.  The RF3OUT port's amplifier get correctly switched on/off based on the output port selection.

What is a bit strange is that the bias voltage across the device is just about 2V. What does the datasheet say about this?

Datasheet says: Nope! Device operating voltage is about 4.9V. So, is just the output amplifier shot?

Most probably.
Do you need a replacement? Still got a few somewhere left over from my CMU200 repair.

Edit: Your RF front end is somewhat different from mine (http://wunderkis.de/cmu200/rawpic/) and gives somewhat different (but same ballpark) RF3 -> RF1 / RF2 results than bdunham7 got.
Anyway, the MMIC is a different one, mine has the "C4" marking and is a Sirenza SCA-14. Should work but might have a slightly different gain over frequency response so the calibration might somewhat off.
All the modules of a CMU200  have loads of individual calibration data stored in onboard nonvolatile memory, and the overall frequency response is calculated and corrected by SW from them. So if one replaces these MMICs, the calibration data aren't valid anymore (but should still yield useful results, so mine did).

« Last Edit: October 19, 2020, 08:18:03 pm by capt bullshot »
Safety devices hinder evolution
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #19 on: October 22, 2020, 06:35:01 pm »
That measured values seem a bit different than what I have measured, don't they?

Yours are 35db apart, just like mine.  Make sure you are using the exact same settings--100MHz span, 10kHz RBW (the minimum at that span), RMS detection (not peak) and see where you are.

Then you are probably mixing units? As if you have -35dBm signal left out of +13dBm, the port to port isolation is 48dB.  That is much higher than what I measure. If it is "35dB down" (ie. see a -22dBm signal left from those +13dBm) , then it is about what I see with my unit.
 

Offline bdunham7

  • Super Contributor
  • ***
  • Posts: 7969
  • Country: us
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #20 on: October 22, 2020, 06:42:45 pm »
Then you are probably mixing units? As if you have -35dBm signal left out of +13dBm, the port to port isolation is 48dB.  That is much higher than what I measure. If it is "35dB down" (ie. see a -22dBm signal left from those +13dBm) , then it is about what I see with my unit.

No, I'm saying that my levels on RF1 and RF2 differ by 35dbM.  And so, apparently, do yours.  Your absolute levels are higher, of course, but that is why I wanted to make sure you were using the exact same settings as far as span, RBW, etc, that I was.  Even if your absolute numbers are higher with identical settings, the fact they they differ in the same way may give you some clues about where the problem is.
A 3.5 digit 4.5 digit 5 digit 5.5 digit 6.5 digit 7.5 digit DMM is good enough for most people.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #21 on: October 22, 2020, 07:14:25 pm »
So one step further:

Both MACOM SW-279 switches has correctly switching control voltages of 0V / -10V.  The RF3OUT port's amplifier get correctly switched on/off based on the output port selection.

What is a bit strange is that the bias voltage across the device is just about 2V. What does the datasheet say about this?

Datasheet says: Nope! Device operating voltage is about 4.9V. So, is just the output amplifier shot?

Most probably.
Do you need a replacement? Still got a few somewhere left over from my CMU200 repair.

Edit: Your RF front end is somewhat different from mine (http://wunderkis.de/cmu200/rawpic/) and gives somewhat different (but same ballpark) RF3 -> RF1 / RF2 results than bdunham7 got.
Anyway, the MMIC is a different one, mine has the "C4" marking and is a Sirenza SCA-14. Should work but might have a slightly different gain over frequency response so the calibration might somewhat off.
All the modules of a CMU200  have loads of individual calibration data stored in onboard nonvolatile memory, and the overall frequency response is calculated and corrected by SW from them. So if one replaces these MMICs, the calibration data aren't valid anymore (but should still yield useful results, so mine did).

I have ordered a bunch of the NGA-589 amplifiers from Aliexpress, so hope they will be fine. I couldn't find them anywhere else (or for any sensible price).  If I'd need to slap something different in there, I would likely already have something fitting in my stash of components. But thanks for the offer, I will keep it as a backup if those amps from Ali won't work.  :-/O

Then you are probably mixing units? As if you have -35dBm signal left out of +13dBm, the port to port isolation is 48dB.  That is much higher than what I measure. If it is "35dB down" (ie. see a -22dBm signal left from those +13dBm) , then it is about what I see with my unit.

No, I'm saying that my levels on RF1 and RF2 differ by 35dbM.  And so, apparently, do yours.  Your absolute levels are higher, of course, but that is why I wanted to make sure you were using the exact same settings as far as span, RBW, etc, that I was.  Even if your absolute numbers are higher with identical settings, the fact they they differ in the same way may give you some clues about where the problem is.

They differ by 35dB (ratio) not by 35dBm (a unit of power, 3.16W actually).

Why would a span and RBW matter? The absolute value of the signal should be exactly the same.  :-//
 

Offline bdunham7

  • Super Contributor
  • ***
  • Posts: 7969
  • Country: us
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #22 on: October 23, 2020, 12:38:10 am »
They differ by 35dB (ratio) not by 35dBm (a unit of power, 3.16W actually).

Why would a span and RBW matter? The absolute value of the signal should be exactly the same.  :-//

If I select 'RMS' as the detection mode and set it up the way I said, (10kHz RBW) I get about -37dBm as a peak.  If I change the RBW to 1MHz, I get about a -23dBm peak.

If I select 'PEAK' as the detection mode, I get about -23dBm at any RBW and only the noise floor and the width of the peak change significantly.

The CMU200 functions differently than a traditional spectrum analyzer and I haven't quite figured out all the various ramifications of the differences.  I would expect the trace interval, or its equivalent here, to match the RBW, but perhaps there is some limitation I'm not aware of.  Could you check to see if yours behaves the same way?
A 3.5 digit 4.5 digit 5 digit 5.5 digit 6.5 digit 7.5 digit DMM is good enough for most people.
 

Offline YansiTopic starter

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #23 on: October 23, 2020, 08:18:17 am »
I still don't have a clue how the CMU200 works either, but from my brief experimenting and testing, "peak mode" is what seems to be similar to a classic SA measurement. The peak values, as far as I remember, corresponded very well with the input signal levels. So in peak mode, if I apply for example 0dBm signal on the input, I see 0dB signal peak in the spectrum, regardless of RBW and span - which is the expected behavior of a classic sweeping SA.

I have not explored what the "RMS mode" does, but it seemed it shows lower values in general.
 

Offline YU7Q

  • Newbie
  • Posts: 4
  • Country: cs
Re: CMU200 repair attempt - boot error, stuck on "stuc.cpp".
« Reply #24 on: October 27, 2020, 11:44:33 pm »
Thank a lot for measurement!

In the attachment you could find  schematic of RF4IN.

I am trying to do math of shunt resistors with values you're measured, but unfortunately I don't have a luck. Always got equation w/o solution.

If you're measuring 98.5 Ohm on input it seems that shunt resistors have larger resistance (kohm)?

EDIT: Perhaps R1&R3 in schematic are capacitors and attenuator is T topology?

Vojislav

Quote from: Yansi
I think the measurement I have done may not be enough to determine the values. Do you know what components are on the other side of the board?

I did not want to desolder any of the resistors, but it seems I will need to desolder at least the 16.2 ohm resistor, otherwise there is no way to tell what values the shunt resistors have.  :-// But that measurement will have to wait to at least by the end of week. Currently I am outta my home lab.

//EDIT: R1, R3 unlikely to be capacitors.


  Is there a chance to measure the values ​​of shunt resistors?
  Thanks
« Last Edit: October 27, 2020, 11:54:03 pm by YU7Q »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf