Rohde & Schwarz CMU200 RxTx module issues, help needed.

[richnormand]

You might remember this previous thread troubbleshooting issues with a dead PSU, and then a dead display for good measure.
https://www.eevblog.com/forum/repair/rohde-schwartz-universal-radio-communication-tester-cmu200-psu-issues/

Now that I have some more time I ran the self diagnostics and it came back with error messages about the RxTx module voltages. The 8VTx is supposed to be between 7 to 8V (measured 2.3V) and the 6VTx is supposed to be between 5 to 6V (measured 1.7V).

The Rx seems to work fine and so is the Aux RF source as I can get a nice trace using the spectrum analyzer. The main Tx source seems to be dead however. Not a surprise.

As you can see on the photos I opened the unit and using extenders for the cables I was able to ascertain that there is no output from the Tx side of the RxTx module. If I inject RF (100 MHz at -20dBm) in the RF head module I can actually switch it properly. So, at least for the moment, it looks like the RF frontend module works OK.

It looked like several of the green leds on the Tx side of the board were not lighting up. Of course I have no idea what they should look like in normal operation. The Rx side seem to be lit like a xmas tree with only a few led off.

Since the diagnostic mentioned two power supply lines I located what looked like a voltage reference on the Rx side with a quad opamp (LM1458) near a reference voltage ic (REF02). As shown in the photo two BCP68 seemed to be the pass transistor for the regulator. The photo show the location with the defective (open emitter collector) pass transistor removed.

Replaced the BCP68 and so far so good. The CMU200 RxTx module now passes the system self-test with no errors.

However: it now fails the internal RX-Tx test as I still do not have a valid RF output from the board. When I set the CMU main Tx to generate a 100 MHz signal and used an loop pickup with my HP8561 spectrum analyzer I can pick up a 100MHz over various places on the board. I assume this means that the LO3Tx and the LO2 and the LO1Tx are working OK since I do endup with a 100MHz signal somewhere after all three mixers. This would point out to issues near the Tx output and attenuator?

No schematics beyond the block diagram from the "service" manual. Lots of jumpers in various modules on the board and , of course, no markings....



Anyone out there familiar with this RxTx board?
Help and suggestions appreciated

[richnormand]

Some progress.

After the pass transistor repair all the voltages passed the self-diagnostic test OK but the internal loop-back RF test failed. All the measured RF output for each frequency and power level read nothing.
Of course the 1>4 and 2>3 loop test failed also. The GSM application could not communicate with my phone and gave a "power too low" error message,

After setting the Tx output to be 500MHz I could clearly pick a 500MHz stray signal with my sniffer probe and HP8561E spectrum analyser. I interpret that as a sign the three LO and mixers are OK.

Although the Tx side of the board is fairly populated at least it is compartmentalized with RF shielding. On the other hand the lower layers of the board are not visible at all, making following the inner connections impossible. (Photo)

I was able to locate a Macom MADRCC0004 quad driver chips for FET switches and attenuators (Yellow in photo) driving an HMC307 Hittite attenuator (orange box) with the raw RF most likely coming from the module below and SBW-5089 amp chip. I then created a jumper from that point, a 0.1uF dc blocking cap and connected it to the Tx output (blue path). That way I would bypass most of the whole set of G4C (UPG2179) SPDT RF switch matrix (red path).

Running the self test for internal loopback gave some results with blocks of "pass" for some, "overdrive" errors for others and no measured output for some. Considering the jump wire is not coax and how crude this setup is at RF frequency this was interesting. I even managed connect, run audio tests and to send SMS text to my phone with it!

Still to investigate are possible:
1) dead RF amp chip (there are a few to compensate the switching losses)
2) dead switching chip in the path
3) bad drive signals to the RF switch chips (the yellow wire at the bottom is connected at one of the control pin and I am trying to find where the signal comes from on the board. All the switching signals
for the RF switch are from an inside layer on the printed circuit board and not visible. Also there are tens of these RF switches all over the board.
4) low initial RF level at input (from bottom module, no idea what it should be and it looks like there are two inputs paths and a switch before the attenuator input)
5)something else

If anyone has played with these any help would be appreciated. Even suggestions on the general layout of the Tx side beyond the simple block diagram from the R&S "service" manual would be greatly appreciated.

Progress is slow as I have to remove the board and put it under the microscope each time and then reconnect everything to test.


Edit: started to work on #3 to figure out where the RF switch control signals are coming from. Unfortunately they all seem to be on an inside layer. X-ray seem to be the only way to see where they are coming from. I gave up after soldering a probe wire after the resistor and cap on one of the switch and doing systematic probing around the board. Not that easy to follow even with x-ray due to the many layers and seeing all the components on the other side..... underground trace in orange, RF switch IC in green. This is the region at the lower right on photo 1 and lower left on photo 2, with the yellow wire connected.

[Brainbox]

I am reading Your postings with interest.
Because I have an defective RxTx board myself with a broken Rx path.
What I wonder is how You extended the multi pole digital connector to the main board ?
Dis You made an extension cable for this purpose yourself ?

[richnormand]

I am reading Your postings with interest.
Because I have an defective RxTx board myself with a broken Rx path.
What I wonder is how You extended the multi pole digital connector to the main board ?
Dis You made an extension cable for this purpose yourself ?

The only extensions I did were for the TX and Rx coax because the rigid ones are a pain to install and remove each time. Now I undo the snap connector (32) in the back and pull the board halfway and unscrew the SMA connectors by hand inside the chassis. For some changes I do not have to remove the three top connectors (36,37,38), pull the board out and have access to most of the board to solder signal pickup wires. For operation I do have to re-plug the coax RxTx lines as well as the back connector and seat the assembly properly on the motherboard connector.

I also found the removing the edge tensioners (top) made sliding the board easy and reduced the wear on the RF edge plating.

[rastro]

You may want to post a request for the CLIP of your specific board on the RS yahoo group:
https://groups.yahoo.com/neo/groups/Rohde_Schwarz/info

I don't have direct experience with the CMU200 but I have repaired RF issues on RS SMIQ PCB's.
Some general suggestions:
1. Any of the MMIC's would be my first suspect.  Even without schematics you should be able to identify them by part marking, location in signal path, and usually the hottest running components.  I would expect 10-15dB gain out of a good amp. 

2. The connectors mounted on the surface of PCB are probably key test points.  On the SMIQ they are disconnected.  In order to use them you have to typically de-solder a coupling capacitor from the RF path and re-orientate it to a nearby pad which goes to the center conductor of the test connector.  This is risky and you are probably better probing directly on the RF path looking for "relative" changes in power.  The test point connectors do point to locations of interest for "relative" probing.

3. Make a quick and dirty RF probe.  Yes it will introduce losses and noise on the signal but it is good for tracing gross discrepancies/problems. 
-- Important caution :  Make sure you use a DC block on the front end of your spectrum analyzer since there are DC voltages on parts of the RF signal path. 
-- MMIC's have a DC voltage 5-18VDC typically applied to the output which is later removed with a coupling capacitor.
-- Don't take any chances with the front end of you SA and always use a DC block!
I use an SMA connector with a pin soldered on the center pin connector. 
a. Then touch it to the RF path prior to the component of interest. 
b. Use peak hold or note signal amplitude in dBm.
c. Touch to RF path after component.
d. Note the signal level dBm.
e. The difference between b and c is the relative gain/loss.

I've used this to great effect with my DC-block & HP 8593E.  Hope this helps.

-rastro

[richnormand]

Thanks for your feedback rastro:

Good suggestion for the Yahoo group. I scanned it but no luck. I'll post a request.

To answer your comments in the order:
1)
I have checked the gain of a few of the SBW-5089 and the gain looked OK, about 10dB. But it is hard to tell in the sections that have no signal. I have a few on order from Mouser.
2)
Probing points are indeed activated in that region even if there are no physical connector on them. This is how I identified the 500MHz but I have no idea what the levels should be.
Since 500MHz is a frequency I asked the Tx channel to generate I know the three LO oscillators are working.
3)
I have a DC block prior to the input of my HP8561. Pays to be paranoid: I also measure DC before connecting.
I like your probe. I'll make one for my kit. The photo shows the loop that I used to locate the area of the board with my 500MHz signal in a "blind" non contact way by sliding it on edge along the board and looking at signal strength.
In this particular case, since I do not have good access (between other modules) to the board once plugged and running, direct probing is sort of dangerous in creating a short between components (in addition to what I already have in problems). That is why I have been soldering short coax or wirewrap wire to bring the signals outside.

I have now located the driver chip for the RF switches (Macom MADRCC0004). I had assumed they would be in the same RF shielded area as the switches they drive but that was not the case. X-ray of the inner layers of the board helped to locate the traces. I am now in the process of mapping the several tens of RF switches drive lines to see if a patch is dead. Unfortunately the input for the Macon ICs seems to be an R&S big asic chip. If that is faulty it's probably an end-game situation.

Again thanks for the help, most appreciated. If you think of anything else don't hesitate.

Cheers.

[rastro]

Sounds like you already suspect the MMIC's.  You could also check the DC bias voltage at the MMIC RF output pin.  The DC level may have a noticeable difference on a failed amp.  If you have a known good SBW-5089 you can compare the bias voltage to a suspect SBW-5089.

If you are measuring RF at the RF connector (test points) is it possible that someone previously (re)routed the coupling capacitor away from the normal system RF path to the RF test jack???  If the TX section of the system was not functioning since you acquired the unit it's possible someone else was troubleshooting the RF path and opened the normal RF path in the process of hooking up some of the test jacks.  I don't think the RF test points should be active unless the RF is (re)routed to them - but I could be wrong.  It may be worth while to ensure the normal RF path near the RF test point jack hasn't been interrupted due to a moved/missing surface mount feed through capacitor.

-rastro

[richnormand]

Some more progress during the weekend.

As previously stated I started to map all the RF switches in the section of the board.
As can be seen in the photos they are grouped and switched all at the same time in that group.There are 5 groups.
Group 1 does switch while running the 1->4 RF test. Group 2 did not change at all in all the modes I tried (needs checking).
Both 1 and 2 are driven by the Macom chip "C" as seen in the scan.

All the other groups are driven by the Macom chip "A". They all switch with various settings of RF frequency or dBm or test mode.

Next thing was to check the BW5Z RF amplifier chips (as suggested by rastro). I started with #2 as a likely suspect.
RF level was low at the input of the BW5Z but seemed OK on the other side of the coupling capacitor (shown by the red arrow). Looked like a huge loss going through that capacitor.
I changed that capacitor and the RF chip showed a bit over 20dB gain.

I then reinstalled the RF shielding box to run the internal tests.

The CMU200 now passes almost all the internal RF loop test except for a small range (see photo).

This is good progress. Now I need to find why that range of frequency and power fails.

[rastro]

...  BW5Z RF amplifier chips ... #2 as a ... low at the input but seemed OK on the other side of the coupling capacitor (shown by the red arrow). I changed that capacitor and the RF chip showed a bit over 20dB gain. I then reinstalled the RF shielding box to run the internal tests.  ...

Your update is a little unclear:
At first you get good output for amp#2 but then you decide to replace a capacitor??
1. You said you replaced a capacitor.  Was the coupling capacitor at the output of amplifier #2 bad?  Causing amplitude loss?
2. The capacitor replacement appears to have fixed a subset of the internal loop tests?  Which loop tests did it fix?  Did any change or stop working?
3. In the last picture (loop test screen) are these the only remaining failed loop tests after replacing amp#2's output capacitor?
4. Currently the instrument is not completely passing all the internal loop tests - so basically fails that section?(yes/no)
5. Are you maintaining a list/record of the loop test value/results as you make changes to the system?  Are the results consistent/stable across multiple tests?

You mentioned that the RF input to amp#2 seems a little low.  Is it fed by amp#1?
You may want to check amplitudes using 2 different frequencies settings?  One frequency that has passing results and the 2nd in the frequency range that fails the loop test.
Where did you get the replacement capacitor?  Unless you are careful of component selection the replacement may induce unintended frequency response in the RF path. 


Thanks for keeping us posted
-rastro

[richnormand]

Did a small edit to make it clearer (I hope).
To address your points in order:
1)
At first glance it looked like the signal to the input of the BW5Z was very low. The signal was nice at the output of the Hittite digital attenuator chip but by the time it got the the input pin of the BW5Z amplifier it was almost gone. The loss all happened across the input coupling capacitor to the amplifier. So I changed it to test and the circuit came to life. After the repair it gave a  clean 20dB gain, about spec for the chip. Before, with just a weak signal (-45dBm) the gain looked like less than 5-10dB at best and quite noisy. Perhaps the cap was leaking dc and upsetting the amp...
2)
Indeed the cap replacement resulted in all the loop test passing everything (about 100+), except for a few in the region of freq and amplitude shown in the photo. Before it failed everything with next to no signal.
3)
Yes these are the only remaining fails on the loop test.
4)
Yep. One fail on one of the hundred tests and you get an overall "Fail" for the whole thing.
5)
Yep. I have a folder about 2cm of notes on the progress, things to do, schematics on that unit. Some are in my original post, referenced initially here.

6)
"You mentioned that the RF input to amp#2 seems a little low.  Is it fed by amp#1?"
The three amps are different parts of the board. Amp#2 is fed by the Hittite digital attenuator (via the problem cap). Amp#1 is near the board output (after group 4,5 of RF switches). Amp3 is near the LO mixer.

The fact the input to amp#2 seemed low (-45dBm or less) and noisy is what caused me to measure from the Hittite attenuator output that is feeding that circuit and focus on the bad coupling capacitor on the BW5Z input pin.

7)
"ou may want to check amplitudes using 2 different frequencies settings?"
Indeed. The quickest way was to run the internal loop test since it goes through tens of frequencies and amplitudes combinations to map the whole operating range.
I was surprised it came out that good.


"Where did you get the replacement capacitor?" "induce unintended frequency response in the RF path"
From my box of salvaged smd components.  I intend to locate one of the other BW5Z amp on the board and remove the input coupling cap to measure its capacitance at least. According to the BW5Z spec sheet they should all use bypass caps at both the input and output for the dc biases, That is on the list of things to do.

It is interesting that when I got this CMU200 the PSU had issues, the display was dead, the HD would not boot the system consistently (clone the software and replaced it), the RxTx board was dead (voltage reg) and now this. I guess I got the lab "mule" with all the defective parts...... The most frustrating is not having access to decent schematic diagrams for troubleshooting. the plus side are the array of self test for the unit.

[rastro]

Thanks for the quick and detailed reply.

To recap:
1. It was a bad input coupling capacitor to the RF amp#2 (BW5Z) that was causing significant RF attenuation. 
2. Now 10 loop test frequencies that are consecutive between 1.2GHz and 1.82GHz fail with readings ranging -84.6dBm to -79.1dBm
3. Only these same 10 frequency test points consistently fail the loop tests.

In the loop test picture I noticed that an adjacent frequency is passing with -78.6 dBm.  So it looks like a 2-6dB margin on the failing frequencies.
I strongly suspect you found the primary problem with the capacitor - for the loop test at least.
Since you plan on unsoldering from another section to measure you should use that for the input of amp#2 and see if that solves the specific loop problem.

I guess my point is that the coupling capacitors on your system are specifically designed for RF/microwave.  Although it is good to match the capacitance value it may not be sufficient.  There are other factors like inductance and temperature stability that may not be critical at lower frequencies. 

Good news is that it sounds like getting close to resolving the loop issues.
-rastro

[RF_fanatic]

From my experience with the CMU the results can also be highly influenced by the DSP module.

Replacing the DSP from a known good device (even without firmware update after hardware change) can determine if the influence from the DSP is causing deviations.

I will try to make some pictures to show the difference

[RF_fanatic]

Here some examples.

Only difference between these test was a swap of a DSP unit.

[richnormand]

Thanks RF_fanatic, this does look somewhat like my issue. Did some extra tests today.

I hooked up the output Tx of the RxTx module to the HP8561 and looked at the levels in the problem area. There were no big drops in the affected region Looks like the TxRx board might be OK.

So I plugged the lines back to the CMU200 and looked at the worst case (1430MHz at -73dBm with a result of -84dBm in the internal selftest) using out 2 to in 4 in spectrum mode. Got -74.4dBm, well within specifications. Then I used 1-> 4 and got -87.5dBm and 1->2 for -65.3 dBm

Redid the test at several frequencies and amplitudes, much like the self test, including the 1->1 channel and the others.

Since the internal loop test uses 1->1  this might be the issue. looks like the channel 1 of the RF head is likely the problem here and the RxTx has been fixed successfully. Also of note it looks like the 1 channel on the RF head has about -40dBm of noise to it......

Is every bloody module bad on this unit......

 

[rastro]

Wow, sounds like you do have a special needs instrument. 
Good thing you used a SA to verify the final output of of the txrx board. 
Apparently you can't trust any feedback/measurements on the system.

So are all the results from the loop tests bogus?

-rastro

[RF_fanatic]

What is the respons when using RF2 > RF2

(not often known but you can check this after the RF1 > RF1 test by pressing the cont/halt button again (same process as changing between RF1>RF4 and RF2>RF3

[richnormand]

What is the respons when using RF2 > RF2

(not often known but you can check this after the RF1 > RF1 test by pressing the cont/halt button again (same process as changing between RF1>RF4 and RF2>RF3

Nice. I did not know that.

I ran the 2->2 and got two extra errors and a similar set of errors in the same region as the 1->1 unit. Perhaps the RxTx board still has issues or needs a better tolerance than my previous measurements would indicate. Or both the RxTx and RF front-head units have issues simultaneously....

Next steps:
1)
use the HP8561E spectrum analyser at the output of the RxTx board on the Tx output and map the dBm response at the same frequencies  as the selftest. This will be done at both conditions asking the software to switch the 1->1 and 2->2 outputs as I noticed the output mapping of the RxTx board Tx output seems to be scaled differently for each requested frontend output. Probably done in anticipation of different losses in each routing path or even pre-programmed for calibration?

2)
Use the HP8648D frequency generator with a set of output levels as input to the RF-head unit, again requesting different routing, and map the output response of each channels for different dBm and frequencies.

That will take a while. Should help me to sort out RxTx board issues or/and RF head module issues, I hope.

[RF_fanatic]

Hello Rich

Based on the equipment you have I would suggest a simpler and quicker way.

First of all I wouldn;t focus on the problem points but on the full range. As you see R&S uses quite some large steps but they do not cover the in between points. So how I usually set up these tests:

Test outputs:

Connect the outputs to a any spectrum analyser. Set the analyser to peak hold. Set the CMU generator to 10 Mhz, set step size to 10Mhz and spin the rotary switch in a pace that the spectrum analyzer can follow. You will than see a complet trace, with also the option to focus on certain problem areas depending on the span of the range.

Test inputs

Acutally this is quite similar. Set the CMU in spectrum mode. Press the spectrum button (with the yellow marker) again, you will now see a configuration menu. Select display mode and toggle to maximum. Press spectrum button again to get back to display mode. Use the signal generator to sweep between 10Mhz and 2700Mhz in a continues mode with decent stepsize and wait till the trace is completed several times. Any hickups can occur if the speed of the generator is faster than the analyser speed, therefore you have to wait several sweeps.

If all goes well you will see a nice straight line without abnormalities.

You can off course also do this with the CMU itself if you know you can trust either one of them. But at this stage you are now you must use an external known source

[richnormand]

Hello Rich

Based on the equipment you have I would suggest a simpler and quicker way.

First of all I wouldn;t focus on the problem points but on the full range. As you see R&S uses quite some large steps but they do not cover the in between points. So how I usually set up these tests:

Test outputs:

Connect the outputs to a any spectrum analyser. Set the analyser to peak hold. Set the CMU generator to 10 Mhz, set step size to 10Mhz and spin the rotary switch in a pace that the spectrum analyzer can follow. You will than see a complet trace, with also the option to focus on certain problem areas depending on the span of the range.

Test inputs

Acutally this is quite similar. Set the CMU in spectrum mode. Press the spectrum button (with the yellow marker) again, you will now see a configuration menu. Select display mode and toggle to maximum. Press spectrum button again to get back to display mode. Use the signal generator to sweep between 10Mhz and 2700Mhz in a continues mode with decent stepsize and wait till the trace is completed several times. Any hickups can occur if the speed of the generator is faster than the analyser speed, therefore you have to wait several sweeps.

If all goes well you will see a nice straight line without abnormalities.

You can off course also do this with the CMU itself if you know you can trust either one of them. But at this stage you are now you must use an external known source

Sounds like a plan!
Thanks RF_Fanatic

[RF_fanatic]

Any luck on finding out the reason for the band errors?

If the errors are significant than there is a hardware error, if only a few errors but other signals are OK within the band than it can be altered during the calibration.

Calibration can be done in the startup menu (edit tables) but of course you need to know the exact datapoint to alter.

Helpfull perhaps is to read the repair of a Rohde & Schwarz FSEM in which also some frequenties did not respond correct. Of course its a totally different device but strategy might be quite similar to calibrate (page 59 and further). (sorry report is in Deutsch)

http://www.bymm.de/documents/35/FSEM_V1_16.pdf

Most easy way would be to alter the tables if you pull out the HDD and directly edit the files

[rastro]

Hello RF_fanatic,

Are you the author of "FSEM_V1_16.pdf"?  This is really excellent work and documentation. 

Also I found a similar report from the same author (you?) "SMIQ06B_6GHz-Modul_V1_11.pdf" which I found pivotal  in repairing my SMIQ06.  I had the same issue in the RF chain of the 6GHz EXT PCB.  Apparently the revision of board on my system used a different MMIC.   I ended up replacing it with a comprable MMIC but had to change the bias resistors on the back of the board to accommodate the new MMIC.

Thanks for posting

-rastro

[RF_fanatic]

No I'm not the author of these great repair documents. But I always read them with great interest.

I do quite some repair but wouldnt have the time to make such great reports.

[richnormand]

Any luck on finding out the reason for the band errors?


http://www.bymm.de/documents/35/FSEM_V1_16.pdf

Most easy way would be to alter the tables if you pull out the HDD and directly edit the files

I did not have much time to play with it this week. Prepping up the basement to install a new furnace and hot water heater before the cold season arrives. And, boy, do I have lots of junk and stuff to move around to get the furnace in...

Read the FSEM_V1_16.pdf.  This is very nicely done and you are right the calibration strategy will likely be similar. Thanks for the link. It also helped to spruce up my high school German too I guess learning a language young is like riding a bike: it comes back even if you have not used it in a long while.

I did have time  to do a few things before removing my workbench however.

First:

I removed the Tx cable and put the RxTx module Tx output in the HP8561 SA and calibrated the SA levels in dBm.
Then I requested the CMU200 to use the RFout2 out on the RF frontend (even though it is disconnected from the TxRx module).
I asked the CMU200 to go to 1430MHz (frequency with worst self-test error) and systematically changed the levels from 0 dBm to -90 dBm in -10 dBm increments.
The TxRx module output did not follow the requested step sizes. It went down in steps of -10 then -20, another  -20 and finally -10 db.   

I then requested the CMU200 to use RF1 out. Same setup, RF front end not connected to the TxRx module.
I got steps of 20db, 10dB, 10 dB, 20dB between the levels.

I then requested the RF3out and got steps of 10, 10, 15, 10, 10, 20 between the -10dBm levels requested.
Again, a different pattern.

Since these are different patterns for the same level requests it means the TxRx module is told to compensate differently according to the various losses/gain expected in the RF frontend module path to the front panel outputs.... Also, since the RF frontend is not getting any RF, if there is a feedback loop or AGC implemented it will go nuts and that might be the cause of this behaviour.


Next I did the same using RF4in, RF2in and RF1in using the RFfront end connected to the TxRx module normally with a HP8648 signal generator at 1430MHz. The CMU200 power and SA readings were all OK on the CMU200 display. So now I assume the receive chain portion of the CMU200 is most likely OK and that all my issues are indeed on the RF generation side. (I could be wrong still )

I now have to redo this feeding RF to the RF front end and see if the output is varied in a complementary fashion to the TxRx module output.

Really looks like there is an interplay between the DSP, TxRx module and RF frontend module depending on levels and paths requested. Not a surprise, considering the matrix of RF switches and amplifiers on each. Also since a do not get precise 10, 20 etc dB variations at each step there might also be correction values applied in each module that are specific to each freq/dBm combo

Final run before gutting my workshop bench.
Since these measurement would take a long time to do by hand I downloaded FreRes from R&S and set it up to scan from 50 to 2500MHz.
I reconnected the TxRx module to the RF frontend module correctly and did scans at "requested" 0dBm, -20dBm, -40dBm, -60dBm and -80dBm for both RF3out into RF2in and also for RF2out into RF2in.
Just to see a better picture than the selftest was providing.

Interesting:
for RF3out/RF2in the response is fairly flat for 0, -20 and -60dBm. There is a switching step around 2.2GHz visible in all traces in addition to the deviation around 1.5GHz for -40 and -80 dBm.....

for RFout2/RFin2... well yikes

Did not do other runs yet but it looks like there are possibly many players here between all three modules and how they are implementing the RF chain ....

My next step will be to input RF from my freq gen  in the RF frontend in place of the TxRx output and see how the three RFout behave and if it is related to the gain variation seen at the TxRx module output..
I also need to understand better the architecture before trying to modify files in the OS. FSEM_V1_16.pdf is great to help here

 

[Brainbox]

Last weekend I spend some time to my suspected RXTX board.

When using the "software update after hardware change" I noticed a lot of information passing the screen.

By attaching a keyboard I was able to pause the process and have a closer look at it.
Many of them concerning reading, calculating and flashing tables, including temperature deviations.
So I thought I would make sense to have a better insight in the whole software part of the CMU.
As I did not have the floppy drive option I needed an other way to work in DOS mode at a comfortable way.
I do have a PCMCIA FlashCard reader and also found a 256MB CF card, that combination shows up as drive D: in DOS
That made things a lot easier because now I could examine the software in DOS mode.
For more convenience I installed the good old Norton Commander at the HD of the CMU.
So now I am able to examine the HD and transfer files easy to the CF card, and thus to a PC.
Not surprisingly I found a directory "tables" and more specific I was interested in the sub directory RXTX.
There it was the file EEP_RXTX.ASC that was very interesting.
Its a quite large file with structures looking like this:

# Frequency characteristics 1200.. 1700 MHz (TX)
ID:                 USER_14060
UPDATE_INDEX:       01.01
ROWS:               23
COLUMNS:            2
ROW_ID_TYPE:        FIX32D3
COLUMN_ID_TYPE:     UINT8
DATATYPE:           FIX16D2
AUX1:                 30.15
AUX2:                 34.41
AUX3:                  0.00
#===================================
#          MHz       IDs...
# COL                    1        2 
#===================================
   0:                    1       53 
#-----------------------------------
   1:    1200.000     2.40     0.02 
   2:    1215.000     2.45     0.02 
   3:    1235.000     2.44     0.02 
   4:    1250.000     2.44     0.02 
   5:    1260.000     2.45     0.02 
   6:    1270.000     2.48     0.01 
   7:    1280.000     2.52     0.02 
   8:    1290.000     2.54     0.01 
   9:    1300.000     2.57     0.00 
  10:    1330.000     2.67    -0.02 
  11:    1350.000     2.67    -0.02 
  12:    1370.000     3.01    -0.02 
  13:    1400.000     3.47    -0.04 
  14:    1415.000     3.24    -0.05 
  15:    1430.000     2.96    -0.06 
  16:    1450.000     2.56    -0.11 
  17:    1470.000     2.46    -0.12 
  18:    1500.000     2.43    -0.20 
  19:    1530.000     2.40    -0.25 
  20:    1570.000     2.33    -0.35 
  21:    1585.000     2.28    -0.37 
  22:    1595.000     2.25    -0.38 
  23:    1607.000     2.25    -0.39 


ROWS:               9
COLUMNS:            25
ROW_ID_TYPE:        FIX32D3
COLUMN_ID_TYPE:     UINT8
DATATYPE:           FIX16D2
AUX1:                 29.91
AUX2:                 34.54
AUX3:                  0.00
#==================================================================================================================================================================================================================================================
#          MHz       IDs...
# COL                    1        2        3        4        5        6        7        8        9       10       11       12       13       14       15       16       17       18       19       20       21       22       23       24       25 
#==================================================================================================================================================================================================================================================
   0:                   51       52      101      102      103      104      105      106      107      108      109      110      111      112      113      114      115      116      117      118      119      120      121      122      123 
#--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
   1:    1200.000     0.40    -0.34     0.01    -0.18    -0.13    -0.29    -0.22    -0.32    -0.25    -0.18    -0.16    -0.32    -0.30    -0.38    -0.36    -0.42    -0.41    -0.36    -0.28    -0.39    -0.31    -0.40    -0.33    -0.40    -0.34 
   2:    1250.000     0.47    -0.33    -0.03    -0.25    -0.19    -0.35    -0.29    -0.41    -0.33    -0.20    -0.19    -0.36    -0.35    -0.42    -0.41    -0.47    -0.46    -0.43    -0.35    -0.46    -0.38    -0.50    -0.42    -0.51    -0.44 
   3:    1300.000     0.50    -0.31     0.01    -0.24    -0.18    -0.36    -0.29    -0.42    -0.34    -0.24    -0.24    -0.37    -0.37    -0.40    -0.41    -0.46    -0.45    -0.41    -0.32    -0.47    -0.39    -0.51    -0.42    -0.53    -0.47 
   4:    1350.000     0.56    -0.31     0.03    -0.20    -0.12    -0.29    -0.21    -0.34    -0.24    -0.22    -0.23    -0.28    -0.29    -0.31    -0.31    -0.34    -0.33    -0.29    -0.21    -0.35    -0.26    -0.42    -0.32    -0.41    -0.37 
   5:    1400.000     0.62    -0.28     0.06    -0.11    -0.01    -0.19    -0.09    -0.20    -0.10    -0.13    -0.14    -0.14    -0.14    -0.14    -0.15    -0.13    -0.15    -0.15    -0.06    -0.19    -0.10    -0.27    -0.17    -0.27    -0.17 
   6:    1450.000     0.67    -0.28     0.10    -0.02     0.10    -0.04     0.06    -0.01     0.10     0.02     0.01     0.08     0.06     0.08     0.06     0.13     0.10     0.02     0.12     0.01     0.11    -0.07     0.03    -0.03     0.03 
   7:    1500.000     0.74    -0.24     0.13     0.06     0.19     0.05     0.17     0.13     0.25     0.24     0.21     0.31     0.27     0.30     0.26     0.36     0.33     0.10     0.18     0.12     0.23     0.07     0.17     0.13     0.18 
   8:    1550.000     0.76    -0.28     0.12     0.08     0.20     0.06     0.18     0.16     0.27     0.43     0.39     0.46     0.41     0.42     0.36     0.47     0.41     0.04     0.13     0.10     0.18     0.06     0.15     0.12     0.17 
   9:    1607.000     0.74    -0.36     0.06     0.00     0.09    -0.05     0.04    -0.01     0.10     0.53     0.48     0.46     0.41     0.37     0.30     0.37     0.31    -0.21    -0.12    -0.15    -0.07    -0.16    -0.07    -0.11    -0.06 

(sorry for the poor layout of the last part)

# Frequency characteristics 10 ... 600 MHz (TX)
ID:                 USER_14040
UPDATE_INDEX:       02.02
ROWS:               32
COLUMNS:            2
ROW_ID_TYPE:        FIX32D3
COLUMN_ID_TYPE:     UINT8
DATATYPE:           FIX16D2
AUX1:                 29.66
AUX2:                 33.34
AUX3:                  0.00
#===================================
#          MHz       IDs...
# COL                    1        2 
#===================================
   0:                    1       53 
#-----------------------------------
   1:       1.000    -0.61    -1.75 
   2:       3.000    -0.85    -2.01 
   3:       5.000    -0.81    -1.86 
   4:       7.000    -0.88    -1.64 
   5:      10.000    -0.95    -1.45 
   6:      15.000    -0.99    -1.32 
   7:      20.000    -0.95    -1.28 
   8:      25.000    -0.89    -1.25 
   9:      30.000    -0.83    -1.26 
  10:      40.000    -0.72    -1.25 
  11:      50.000    -0.67    -1.27 
  12:      75.000    -0.55    -1.32 
  13:     100.000    -0.40    -1.40 
  14:     125.000    -0.23    -1.50 
  15:     150.000    -0.02    -1.61 
  16:     175.000     0.12    -1.74 
  17:     200.000     0.32    -1.85 
  18:     250.000     0.55    -2.00 
  19:     275.000     0.64    -1.97 
  20:     300.000     0.71    -1.86 
  21:     325.000     0.76    -1.66 
  22:     350.000     0.80    -1.41 
  23:     375.000     0.83    -1.14 
  24:     400.000     0.86    -0.89 
  25:     435.000     0.90    -0.57 
  26:     470.000     0.93    -0.34 
  27:     500.000     0.96    -0.19 
  28:     525.000     0.98    -0.12 
  29:     550.000     1.01    -0.05 
  30:     575.000     1.02    -0.01 
  31:     600.000     1.06     0.03 
  32:     632.000     1.05     0.05 



And so there are many of them.

At a first glance the TX spectrum is divided in the following divisions:
10    -600  MHz
600  -1200MHz
1200-1700MHz
1700-2200MHz
2200-2700MHz

There also are AUX1, AUX2 and AUX3, which are likely the 3 output channels at the RF frontend.
That would explain @richnormand´s conclusion that there are different levels at the RXTX output, depending on the selected connector.

But what to think about this?

# optimal absolute level at 1. mixer (X14 & X17) (TX)
ID:                 USER_14200
UPDATE_INDEX:       02.00
ROWS:               3
COLUMNS:            1
ROW_ID_TYPE:        0
COLUMN_ID_TYPE:     0
DATATYPE:           FIX16D2
AUX1:                  0.00
AUX2:                  0.00
AUX3:                  0.00
#==============
#        level
#==============
   1:   -15.00 
   2:   -25.00 
   3:    -5.00 




# measured relative level at 1. mixer (X14 & X17) (TX)
ID:                 USER_14210
UPDATE_INDEX:       03.00
ROWS:               2
COLUMNS:            2
ROW_ID_TYPE:        0
COLUMN_ID_TYPE:     0
DATATYPE:           FIX16D2
AUX1:                 48.34
AUX2:                 54.55
AUX3:                  0.00
#=======================
#           db
# COL        1        2 
#=======================
   1:   -23.00   -33.12 
   2:   -36.00   -45.94

Fortunately I have another complete and working CMU200 at hand, so can cross-reference  some measured results.

To be continued !

[richnormand]

Interesting Brainbox.
I'll have a look (as soon as I get my bench back!)