Rohde & Schwarz CMU200 RxTx module issues, help needed.

[richnormand]

When I get my bench back in operation I'll either remove the HD (and try a compact flash in its place) and I'll also copy these files. The idea would be to do a quick graph of the number tables and see if they might match in "reverse" the traces I get out of the unit. That might give a clue about where the corrections could be applied. For example I could take one of those file and input a triangular "wave" in the table. (Easy to do in the Origin data plotting program)and reinstall it back on the HD. Then if I use FreRes again  and the RF output contains that signal I would know for which combination of RF path and level that file or table line applies to. 

Any progress with these Brainbox?

Cheers

[RF_fanatic]

What are your thoughts about this:

Using FreRes you can easily calculate the difference between reponse and expected respons.

This delta can be used to correct the measurements

From firmware version 5.? (5.2 for sure) it is possible to make correction file and place it in the coresponding directory which will be read during upgrade. Downside is that correction is limited to 1.9dB if I recall, 1,2 dB (both ways so 2.4 in total) 

Even better would be if the correction could be added to the original values in the EEProm of the corresponding unit. Difficulty is that you have to now where to correct it, but perhaps only changing the cor unit could solve the problem (total correction)

I think it would be possible to get a flat trace that way over the full span.

[Brainbox]

Less progress till now (time is not on my side).
I did en second test with another RxTx board which was missing the Rx spectrum between 1200 and 2200 Mhz.
After doing the software update after hardware change I expected to see the table changed.
Comparing the two files (before and after change) I found no differences.
However, I found some files changed in the folder CMU/BIN_V4.51/FW/RXTX (which is my actual firmware version)
There some .BIN files were changed but they are not in a readable format.
I will have to take a closer look at the "FSEM_V1_16.pdf" and try to find a pattern in the EEPROM data.

In the case of my board with the missing block, I am quite sure this is a hardware issue.
The whole block 1200-2200 drops down by about 20 dBm which looks like a complete stage is dis-functioning.

[richnormand]

In the case of my board with the missing block, I am quite sure this is a hardware issue.
The whole block 1200-2200 drops down by about 20 dBm which looks like a complete stage is dis-functioning.

You are most likely right.
There are so many RF switches, RF amplifiers to compensate and possible different paths that are also switched by software control.
If you look at previous posts I think I mapped a good fraction of them, including the Macom driver and the Hittete attenuator.
Any of those could cause your issue....

Very frustrating that R&S has not released useful schematics for the CMU200 
Keep fighting.
 

[RF_fanatic]

As mentioned it should be possible to compensate with the correction to get a flat line

Please see the following examples, same device, same rf out settings, only difference is the correction applied. This is an extreme example of +10 and -10 between 2700-2600 Mhz as you can see it will try to draw a line. You can spot a small band "jump" as well.

To be noted is that this correction is applied manually and therefore possible to go beyond the 1.2dB limit.

As mentioned you can use this to compensate over the complete range if you can determine the difference.

[Brainbox]

RF_fanatic; I know I can use user compensation tables to correct for deviations in a measurement setup.
However, this is not not the way I want  to "repair" a defective device.
Those manually correction is intend to correct for user specific errors.
Caused, for example, by frequency dependent cable or antenna loses.

Each normal functioning board has its own correction tables stored in its EEPROM after it is calibrated.
When a board is changed those tables are read during initiating and taken in account to create a new tables for the correction processor..
The correction processor will merge those data from all individual boards (RxTx, FE, Ref etc.) in the CMU to adjust for the deviations of each individual board.
When the correction processor is not able to reconstruct the input data to a trustable output, it means that either the correction processor or the calibration data are erroneous.
Most likely it means that the calibration data in the boards EEPROM not corresponds with the actual board behaving.
Small errors can be explained by ageing of components and should be gone after recalibration.
In my case, a deviation of a complete block by such a magnitude, can not be explained by ageing only, its must be a defect.

[RF_fanatic]

@Brainbox

Yes you are correct, that is also the way I see it. If its broken you must not compensate. In your case its clear that there is a hardware error. Most CMU's suffer from deviations which should be adjusted during the factory calibration but if these vary due to aging than its a very expensive adjustment at R&S and than you can do it yourself. Best way would be to directly edit the EEPROM data of the coresponding module.

As you have noticed all modules are working together, so in worse case you can encounter a max tolerance at multiple board which together cause too much deviation and cause a failure in selftest.

Best way to check which item is incorrect is by using a known reference. I have the luck that I have such but otherwise it would become very misty to look for the deviation.

Indeed all modules are factory set, this enables an easy replacement procedure by swapping units. But sometimes you see to odd responses which can not be declared by hardware errors but software errors (table errors), memory allocation error) (in your case its clearly hardware)

[richnormand]

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. 



-rastro

Finally got the replacement caps from Mouser, designed for high frequency use. No difference.  So back to the software table correction approach.....

[rastro]

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. 

-rastro

Finally got the replacement caps from Mouser, designed for high frequency use. No difference.  So back to the software table correction approach.....

Just for clarification, what do you mean by "no difference"?  I think at this point you would agree there are multiple issues with the system.  So after putting in this new capacitor did the frequency response change (please refer to prior two pictures/test in reply#16)?  Are you saying that after replacement of the capacitor you are getting the same power responses at those frequencies in the pictured table?

What if the new capacitor resolved some RF response issue(s) even though the system may still fail due to other outstanding issues.  My point is that right now it seems you are looking at marginal performance issues, possibly in several areas, so it's important to make these distinctions across the suspect sub-systems to know if you are making progress. 

-rastro

[RF_fanatic]

Finally got the replacement caps from Mouser, designed for high frequency use. No difference.  So back to the software table correction approach.....

Sorry to read it didn't solve the problem

I checked your tables and must say the deviation of 6-10dB in upper region is actually to high to be explained by correction tables unless you have swapped out hardware If you havent changed hardware than it is on the high side and I expect some hardware still to be involved.

This is how R&S deals with it:

* Modules are factory set including tables for the corresponding modules. This meets the criteria for individual modules.
* All modules together in the CMU should work without large devations, all should work ok except for level accuracy
* The system deviation is corrected by a correction table (of total system) during the use of the ACS100 calibration device.
* This correction file solves all deviations.

When changing hardware after a failure it is quite the same procedure :

* when installing a new device you must use the version manager (verm) to update after hardware change.
* All module specific information is centralised in the RXTX module, so the factory correction of the dsp, ref, fe etc.
* when performing the hardware update it will work OK accept for the system correction.

This is were most private users are stuck as we don;t have acces to ACS100 systems.

So how does an update after firmware work:

It can be seen in the command files :

* It will start updating firmware of correction board 1 and 2
* Than it will update the correction data and stores the data to the harddisk
* And than it sends the data back to the rxtx module.

I think the ACS100 will "inject " the correction file the same way so for private users it would be interesting to include a file with correct correction format and correct code to be accepted by the system. I think it must be very similar to the user correction table.

Challange would be to find out the format and how to "inject" it manually

L

that it will download the module specific settings and stores it in the files starting with EEP_

[RF_fanatic]

Another interesting thing

besides the different corrections for each channel it also is more stricked in measuring criteria if you measure 1>4 or instance 1>1

In 1>4 path I have seen RED failures even if the deviation is 2,3 dB
In 1>1 I saw some measurements indicated as correct even with 5dB differences

I also notices in the past that it also uses different deviation criteria between Bands

[richnormand]

Thanks for the feedback rastro and RF_fanatic
Hope this answer some of your questions.

1)
None of the internal errors on the 1>1 and 1>4 showed any difference after using the new cap compared to my replacement cap from a few weeks ago. If you remember, at the beginning of this exercise, I was getting NO output at all from the RxTx board. I also ran my replacement cap (from my "junk" bin of mostly RF SMD stuff) and a new one (from Mouser) on my test jig with my HP8551E and HP84640A with no difference in behaviour. The original I replaced was just a bad cap and my replacement was identical to these "high frequency" caps I just got. So that stage is most likely working fine now.

2)
Considering the PSU was dead, the screen was dead, the backup battery was dead, the Tx part of the RxTx module was dead and a few missing screws in various places in the whole unit I would assume that most of the defective modules came from different units. This was from a large manufacturer that got out of the cell phone business and they had many CMU200 with "identical" options.

3)
I did run the version manager for hardware change a few times.

4)
I don't have access to the ACS100 No such luck!

5)
That is why I am interested in identifying the proper files and try to do corrections manually in the right places and see what I can get.
I have good backups of the original software and also replaced the hard drive by a compact flash making changes fast and easy.
Going by your comment about: "Please see the following examples, same device, same rf out settings, only difference is the correction applied. This is an extreme example of +10 and -10 between 2700-2600 Mhz as you can see it will try to draw a line."
What file is responsible for that segment, in readable form, in binary, need to flash a eeprom?   As you pointed out: "module specific settings and stores it in the files starting with EEP_" during the hardware update there are a few mentions of missing files. I'll run it again and note the name of these missing files.

It might be easier to accept the unit as it is and do this than mess with every module until the whole assembly is within compliance.

6)
Since most of the CMU200 works (compared to when I got it) these few rough points do not deter too much from my primary use as a spectrum analyser for specific bands. The whole range was checked before and is pretty close in response when I input a signal from my HP8648D and also the TxAux is also working fine.

[rastro]

Not having the necessary test-fixture/test-software is a significant hurtle. 

Just an idea - it may not be worth pursuing: 

If you had the files/correction-constants from 4 to 5 working systems would it be possible to analyze them and establish a baseline and range for the various frequency/bands/channels?  If this is feasible and there was some consistency to the values it would be helpful in two ways.  You could compare where your system significantly deviates from the norm as an indication of hardware areas to focus on.  It could also act as a starting point to tailor adjustment to your particular system. 

Some problems with this approach might be firmware and hardware revisions having meaningful impact on what would be an "average" system response and correction.

-rasto

[richnormand]

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


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 
#-----------------------------------

Found the files in question. Noticed that it was not getting updated with content or date attribute when running the version manager for hardware change in the front screen.

Next I'll try to load up some dummy data in it for the failed region of the internal test and see if there are any changes in the selftest.
Has anyone tried this already?

[Brainbox]

I already mentioned in my last post that this file is not altered by the version manager after a board change.
You better have a look in the CMU/BIN_V4.51/FW/RXTX folder where the actual and updated EEProm files are stored.

[RF_fanatic]

The above is correct.

The tables files are not used even if you rename the directory and restart with firmware update it will stay identical.

The files that change are the files in the CMU version directory

As mentioned the RXTX module is the central module which uses the correction files of the installed FE end other signal path modules, therefore it will download the EEPROM data of the individual modules and store it to the following files in the RXTX directory before sending it to the RXTX:

eep_rxtx.bin
eep_rxt2.bin
eep_cor.bin
eep_cor2.bin
eep_rxif.bin
eep_rxi2.bin
eep_auc.bin
eep_auc2.bin
eep_adc.bin
eep_adc2.bin
eep_fe.bin
eep_auxt.bin
eep_iqif.bin
eep_txm.bin
eep_mb.bin

[RF_fanatic]

During the update procedure it will do the following:

First it will update the correction board firmware, the firmware are the ihx files

After that it will update the data of the boards using the following files :


#------------------------------- AUC ----------------------------------------

# adding the temperature table 20150 to all AUC
NAME:        AUC
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    auctdev.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 2.00) to AUC with TAZ 0.00 to TAZ 2.08
NAME:        AUC
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    0.00
TAZEND:      2.08
FILENAME:    auc_200.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 2.01 or 2.10) to AUC with TAZ 2.09 to TAZ 4.01
NAME:        AUC
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    2.09
TAZEND:      4.01
FILENAME:    auc_201.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 4.02 to TAZ 4.04
NAME:        AUC
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    4.02
TAZEND:      4.04
FILENAME:    auc_301.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 2.01) to AUC with TAZ 5.00
# In the file the UI is already 2.10
NAME:        AUC
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    5.00
TAZEND:      5.00
FILENAME:    auc_201.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 5.02 to TAZ 5.04
NAME:        AUC
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    5.02
TAZEND:      5.04
FILENAME:    auc_301.asc
OPTUPDATE:   1

#------------------------------- RXTX ---------------------------------------

# adding temperature tables to all RXTX boards
NAME:        RXTX
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    rttdev.asc
OPTUPDATE:   1

# adding LO3 setting table 15620 to all RXTX boards
NAME:        RXTX
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    lo3sett.asc
OPTUPDATE:   1

# adding if temperature table 14026 to RXTX 11001404 with TAZ 0.00 to TAZ 8.99
NAME:        RXTX
BOARDINDEX:  0
PARTNUMBER:  11001404
TAZSTART:    0.00
TAZEND:      8.99
FILENAME:    rt_200.asc
OPTUPDATE:   1


# adding if temperature table 14026 to RXTX 11001733 with TAZ 9.00 to TAZ 10.21
NAME:        RXTX
BOARDINDEX:  0
PARTNUMBER:  11001733
TAZSTART:    9.00
TAZEND:      10.21
FILENAME:    rt_210.asc
OPTUPDATE:   1

# adding if temperature table 14026 to RXTX 11356702 with TAZ 1.00 to TAZ 1.15
NAME:        RXTX
BOARDINDEX:  0
PARTNUMBER:  11356702
TAZSTART:    1.00
TAZEND:      1.15
FILENAME:    rt_220.asc
OPTUPDATE:   1

#------------------------------- COR ----------------------------------------

# adding default tables to COR
NAME:        COR
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    cordef.asc
OPTUPDATE:   1



#****************** CHANNEL 2 ************************

#------------------------------- AUC ----------------------------------------

# adding the temperature table 20150 to all AUC
NAME:        AUC
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    auctdev.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 2.00) to AUC with TAZ 0.00 to TAZ 2.08
NAME:        AUC
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    0.00
TAZEND:      2.08
FILENAME:    auc_200.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 2.01 or 2.10) to AUC with TAZ 2.09 to TAZ 4.01
NAME:        AUC
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    2.09
TAZEND:      4.01
FILENAME:    auc_201.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 4.02 to TAZ 4.04
NAME:        AUC
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    4.02
TAZEND:      4.04
FILENAME:    auc_301.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 2.01) to AUC with TAZ 5.00
# In the file the UI is already 2.10
NAME:        AUC
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    5.00
TAZEND:      5.00
FILENAME:    auc_201.asc
OPTUPDATE:   1

# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 5.02 to TAZ 5.04
NAME:        AUC
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    5.02
TAZEND:      5.04
FILENAME:    auc_301.asc
OPTUPDATE:   1

#------------------------------- RXTX ---------------------------------------

# adding older temperature tables to all RXTX boards
NAME:        RXTX
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    rttdev.asc
OPTUPDATE:   1

# adding LO3 setting table 15620 to all RXTX boards
NAME:        RXTX
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    lo3sett.asc
OPTUPDATE:   1

# adding if temperature table 14026 to RXTX 11001404 with TAZ 0.00 to TAZ 8.99
NAME:        RXTX
BOARDINDEX:  1
PARTNUMBER:  11001404
TAZSTART:    0.00
TAZEND:      8.99
FILENAME:    rt_200.asc
OPTUPDATE:   1


# adding if temperature table 14026 to RXTX 11001733 with TAZ 9.00 to TAZ 10.21
NAME:        RXTX
BOARDINDEX:  1
PARTNUMBER:  11001733
TAZSTART:    9.00
TAZEND:      10.21
FILENAME:    rt_210.asc
OPTUPDATE:   1

# adding if temperature table 14026 to RXTX 11356702 with TAZ 1.00 to TAZ 1.15
NAME:        RXTX
BOARDINDEX:  1
PARTNUMBER:  11356702
TAZSTART:    1.00
TAZEND:      1.15
FILENAME:    rt_220.asc
OPTUPDATE:   1

#------------------------------- COR ----------------------------------------

# adding default tables to COR
NAME:        COR
BOARDINDEX:  1
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    cordef.asc
OPTUPDATE:   1


#******************** OTHERS *************************

#------------------------------- FE -----------------------------------------

# adding temperature table to all FE
NAME:        FE
BOARDINDEX:  0
PARTNUMBER:  0
TAZSTART:    0
TAZEND:      0
FILENAME:    fetdev.asc
OPTUPDATE:   1


#------------------------------- IQIF ----------------------------------------

# adding iqif tables to iqifboard 11356002.02
NAME:        IQIF
BOARDINDEX:  0
PARTNUMBER:  11356002
VARIANT:     2
TAZSTART:    0
TAZEND:      0
FILENAME:    iqif204.asc
OPTUPDATE:   1

# adding iqif tables to iqifboard 11356002.03
NAME:        IQIF
BOARDINDEX:  0
PARTNUMBER:  11356002
VARIANT:     3
TAZSTART:    0
TAZEND:      0
FILENAME:    iqif204a.asc
OPTUPDATE:   1

# adding iqif tables to iqifboard 11356125.02
NAME:        IQIF
BOARDINDEX:  0
PARTNUMBER:  11356125
VARIANT:     2
TAZSTART:    0
TAZEND:      0
FILENAME:    iqif303.asc
OPTUPDATE:   1

# adding iqif tables to iqifboard 11356125.03
NAME:        IQIF
BOARDINDEX:  0
PARTNUMBER:  11356125
VARIANT:     3
TAZSTART:    0
TAZEND:      0
FILENAME:    iqif303a.asc
OPTUPDATE:   1
                   
# adding iqif tables to iqifboard 11356290.02
NAME:        IQIF
BOARDINDEX:  0
PARTNUMBER:  11356290
VARIANT:     2
TAZSTART:    0
TAZEND:      0
FILENAME:    iqif400.asc
OPTUPDATE:   1

# adding iqif tables to iqifboard 11356290.03
NAME:        IQIF
BOARDINDEX:  0
PARTNUMBER:  11356290
VARIANT:     3
TAZSTART:    0
TAZEND:      0
FILENAME:    iqif400a.asc
OPTUPDATE:   1

                   
#------------------------------- AUXTX --------------------------------------

# change diagnosis limits in AUXTX
NAME:        AUXTX
BOARDINDEX:  0
PARTNUMBER:  11359530
TAZSTART:    0
TAZEND:      0
FILENAME:    atx_000.asc
OPTUPDATE:   1

-----------------------------------------

Than it will download the EEPROM data from the boards to the harddisc these are the files mentioned in my above post.

Than it will update the precompiled data I think this is where the user defined correction will be used

the rest is not that interesting

[richnormand]

Thanks for the feedback both of you.
Looks like its going to get more complicated....

[RF_fanatic]

Actually it is some sort of easy as there is only 1 central module if you want to correct signal path deviations.

I think the ASC100 will also only aply it to the RXTX module ,to be more precise the correction processor as can be read in the manual:

The RXTX BOARD1 contains an extra correction processor with large flash PROM. It controls all the static and dynamic settings
 on the RXTX BOARD1 and, as a special feature, also the attenuator pads and amplifiers of the RX and TX attenuator on the RF FRONTEND.
Besides, the correction processor permits to read out the individual module error data from the EEPROMS of the respective modules in a
so-called correction procedure (automatic module data adjustment) and calculate the deviations for all possible signal paths. These deviations are stored as correction values in the flash PROM. The correction processor then sets the desired level settings, corrected by the correction values, in the flash PROM so that frequency, linearity and temperature responses of the modules are compensated for. This ensures the excellent level accuracy of the CMU which is essential for most measurements

[richnormand]

Update:

Had a long look at those files, in particular the ones dealing with the RxTx module.
Not much luck, even did some mods with my hex editor but just managed to create errors at boot time and sometime lock up the system. Much like what is described in one of the superb repair reports from Mark Michalzik.

The file architecture is not that obvious (to me at least) as to how and where to apply the corrections.

I came across this document from R&S that seem to inply that it could be done in an easy way but it probably requires much unobtanium equipment from mere mortals like me.

""Such frequency responses are usually
measured and stored as correction


MOBILE RADIO Radiocommunication testers
RFIN1 800 900 1075 1800 1905 1980 2000 ;
–50 0.5 0.6 0.7 0.9 1.0 0 –0.5 ;
–70 0 0 0.5 0.6 0.8 0.3 –0.2 ;
–80 0 0 0 0.1 0.2 0.3 –0.2 ;
–85 0 0 0 0.5 0.3 0.3 0 ;
–90 1.2 1 0.4 –0.5 0.4 0.3 0.2 ;
FIG 3
The first column in the correction table designates the RF input or output that is to be corrected.
The frequency points are on the horizontal axis, the level points on the vertical axis. The other table
entries are the correction values. A semicolon indicates the end of a table line. During operation, the
correction value is linearly interpolated between the individual frequency points; there is no interpolation
between the level points. The frequency and level points are user-definable. A correction table
can contain a total of 120 values.
The user-specific correction of frequency
response and level response of the Universal
Radio Communication Tester
R&S CMU200 is designed to be versatile
(FIG 1, 2). Separate correction tables can
be compiled for each RF input and RF
output. The user is free to decide on the
User-specific correction of frequency response and level
response: a snap with the R&S CMU200
13
number of frequency and level points
to be set up. The tester linearly interpolates
the level correction to be used
between the frequency points. The correction
tables (FIG 3) are easy to compile
on any PC by means of a normal text
editor, or automatically by a measurement
program, and are then loaded into
the mobile radio tester via the IEC / IEEE
bus, RS-232-C interface or PCMCIA card,
where they can be activated or deactivated
at any time. ""


The whole file is way too big to post as pdf but can be found on the R&S site in the news bulletins as: News from Rohde&Schwarz Number 177 (2003/ I)
or https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_common_library/dl_news_from_rs/magazin/Neues177_englisch_72dpi.pdf

"a snap with the R&S CMU200", ya,sure :

[RF_fanatic]

That is an intersting article, thank you for sharing.

I have some question of which the answer could lead to solutions of how they correct it:

The data of the modules (FE for instance) is stored to the HDD, from there it is uploaded again to the TXTX module.

The file format is BIN, so it produces as mentioned in logfile:

Start transfering EEPROM content to binary file eep_fe.bin

It also sends back as bin to the module but..........

If you read the files in the table environment (which doesnt seem to be used by cmu) you can find information like:

Info:    Start transfering EEPROM content to ascii file rxtx\eep_rxtx.asc
Info:    Number of bytes read from EEPROM: 22386
Info:    EEPROM content read successfully.
Start conversion from binary to ASCII

In the file itself it will be mentioned in the header of the asc files:


# # # # # # # # # # # # # # # # # # # # # # # # # #
# -==**> EEPROM ASCII file Rohde & Schwarz <**==- #
#                 generated by                    #
#                     EEP                         #
# # # # # # # # # # # # # # # # # # # # # # # # # #

Main question is : Could EEP it also be used to translate the BIN files into readable text so we can read what it actually the specific settings and can adjust it and also can send back to the CMU module.

The command to get EEProm data to BIN files is : eep_e2b
I think you should read e2b as: Eeprom 2 Binary 
Example : eep_e2b FE          eep_fe.bin

I know that to write ascii to eeprom the command is:
eep_a2e
like is used in eep_a2e wcdmarx.asc

So combining this information I think it should be possible to do the following:
eep_e2a (eeprom to ascii) but this is only guessing.

I do not have acces to dospromt with keyboard but it would be worth a try to get all the eeprom data translated back into ascii and than alter it and send back to eeprom to see the effect.

Second question : why would the files on R-S_CMU_HD\CMU\_TABLES exist? These seem to have module serial numbers of the modules in it so these are custom made. > How are the made ? especially since these files doesn't seem to be updated during firmware update..

Are these perhaps conversions of the BIN files made during production of the CMU?

[richnormand]

Thanks for the reply. Good ideas to try indeed. 

That will give some work for the next few days.
Instead of doing this from the CMU DOS prompt (Alt-F4) I'll create a new compact flash image and boot from that.

[RF_fanatic]

Based on my own thoughts of yesterday evening (without the acces to a CMU) I had some time today to play with the CMU and check if my thoughts were correct.

So I wrote a script to see if indeed the files could be converted to simultanious ascii and binary with the use of EEP as I thought of yesterday.

And it works

So now I  have the same data both binary and ascii. The ascii files are identical from the format as the files in the _TABLES directory

So EUREKA 

This means we now have a readable "binary file" which we can change and also upload back to the modules !!!

So as many have allready discovered the change of values in the _TABLES file had no influence but with these new files we can have the most recent module data and a change to change it and update the eeprom with vise versa commands

So this will at least solve how we can change the EEprom data

Next step is:

Get a known signal and calculatie the deviation and correct the files for it.

Please notice that now you directly change the data of the module which is a completly different correction than the use of the correction file itself (user correction).

Now we need to find out where the overall path correction takes place as this is the general correction also changed with ASC100 I think

As I modified a lot of files to get a clean and fast result I think that sharing all these modifications will not be very easy to copy, so I share the  easy work around (downside it you have to be patient as it will perform a full update).

* Go to the path where the current firmware version is running from
* Go to the FW directory
* Open the update.cmd file
* go to the READ EEPROMs TO DISK  part
* underneath "eep_e2b MB          eep_mb.bin" you add

eep_e2a RXTX  -idx0 eep_rxtx.asc
eep_e2a RXTX  -idx1 eep_rxt2.asc
eep_e2a COR   -idx0 eep_cor.asc
eep_e2a COR   -idx1 eep_cor2.asc
eep_e2a RXIF3 -idx0 eep_rxif.asc
eep_e2a RXIF3 -idx1 eep_rxi2.asc
eep_e2a AUC   -idx0 eep_auc.asc
eep_e2a AUC   -idx1 eep_auc2.asc
eep_e2a ADC   -idx0 eep_adc.asc
eep_e2a ADC   -idx1 eep_adc2.asc
eep_e2a FE          eep_fe.asc
eep_e2a AUXTX       eep_auxt.asc
eep_e2a IQIF        eep_iqif.asc
eep_e2a WCDMATX     eep_txm.asc
eep_e2a MB          eep_mb.asc

* Save the file
* perform firmware update after board change
* After update you can find both binary and ascii files in the directory of RXTX

[richnormand]

""so I share the  easy work around (downside it you have to be patient as it will perform a full update).""

Cant wait for your update on this RF_fanatic! Nice work.
I'll post what I find too.
Cheers

[RF_fanatic]

Today I have checked how the content of the following files ADC,AUC,FE,MB,COR,RXTX would change after changing hardware modules (I have multiple CMUs).

The following files are changed when changing:

RXTX module:COR,RXTX
DSP module: ADC,AUC
FE module: FE
REF module: not tested yet


In the beginning I had expected that the COR file would be changed if any hardware module would be changed based on the following information:

The RXTX BOARD1 contains an extra correction processor with large flash PROM.
It controls all the static and dynamic settings on the RXTX BOARD1and, as a special feature, also the attenuator pads and amplifiers of the
RX and TX attenuator on the RF FRONTEND. Besides, the correction processor permits to read out the individual module error data from the EEPROMS of the respective modules in a so-called correction procedure (automatic module data adjustment) and calculate the deviations for all possible signal paths. These deviations are stored as correction values  in the flash PROM. The correction processor then sets the desired level settings, corrected by the correction values, in the flash PROM so that frequency, linearity and temperature responses of the modules are compensated for. This ensures the excellent level accuracy of the CMU which is essential for most measurements.

But... the clue is that the correction values in the COR file are not corrected by firmware update. This is correct when taking the following into account:

Replacement of :

FE, REF, RXTX, DIG : After firmware update after board change :

After the adjustment has been terminated, the operating software starts automatically and the CMU is ready for use and complies with the specifications, except for the level accuracy.
In order to achieve the level accuracy described in the data sheet, a so-called path error data record is necessary.
To this end, the CMU must be measured using the test system ACS 100

No influence:

OCXO, B21, B52, B41,

So the COR file should be changed but it is not during firmware update, so this should be done manually when changing hardware modules (if you do not have ASC100). This means that all other files can and should stay original.

I have a large ammount of COR files from different units and will compare which parts stay identical over various CMU's