Rohde & Schwarz CMU200 RxTx module issues, help needed.

[RF_fanatic]

Not much progress to change the correction for the path

I have focussed on the EEP_COR.BIN

As mentioned above I converted it from module directly to readable ascii

Strange thing is that I changed the values in for the eep_cor and uploaded them succesfull to the corresponding module as I could verify it with the same command as above but, whatever value I change in the frequency table, it doens affect the response on the analyser...

So at the moment sort of clueless.

For you who also want to change binary files in the boards, here are the commands to upload an edited ascii file to the board

For instance the eep_cor.asc can be uploaded back to the module with the command:

eep_a2e -opt eep_cor.asc

(the option -opt is not manditory, I think it means optimize table)

[richnormand]

I can send you my COR files from V4.30 and 5.03 running under DOS if that could help you. They seem to be only a tens of KBytes.

Not sure if it works between different versions but they do look to be significantly different in binary between 4.30 and 5.03 in their layout.
Yet the errors in the self-test is identical I think. I will check again to make sure. Of course if the RxTx fault happened after the COR were done you would expect the present "error" in response to be the same.

Other idea, if you send me a copy of your file (if same OS version) I could swap it in my system and see if it reacts at all to the changes.

[RF_fanatic]

Thanks, its appreciated but not needed as I have a couple of CMU images from various units to compare.

Good thing is that with the trick to convert EEPROM data back to readable ASCII it is no longer necessary to work with unreadable binary files.
And I can upload them again back to the CMU with the above mentioned code.

Download : eep_e2a COR   -idx0  eep_cor.asc
Upload : eep_a2e -opt eep_cor.asc

So I use the following sequence: (you can copy paste it including comments)

; Upload changed COR data back to CMU
eep_a2e -opt eep_cor.asc
; Check if upload was accepted by downloading new COR eeprom data
eep_e2a COR   -idx0  eep_cor.asc

I'm trying to change numbers to see what the effect would be on the response so I can figure out how the correction takes place before I start writing a script to measure all frequencies and levels and calculate the deviation to store back at the unit.

So i'm changing extreme numbers to see the change in freq response and figure out which port is 1,2,3, output and 1,2,3 input etc.

it is described :

1 =  path 1
10x = path 2
20x = path 3

These numbers are the numbers in the EEP_COR file in the frequency tables
The subsequent numbers describe various gain level settings.

But changing the frequency files doesn not have an effect so far..

[richnormand]

I guess we need to find more info on what the ACS100 actually does to correct the response using these files?

[RF_fanatic]

Some progress...

As the thinking mostly takes place during the night I think I have found a hint... how it should be corrected.

The table numbers of the COR file do not respond to the table numbers as shown during eep_cor upgrade. That is strange as the table numbers should appear in the ascii data of the EEproms... so perhaps there is another eeprom which I still have not identified during EEPROM download data. The specific eeprom is triggered with eep_cor command. Somewhere in the RXTX module sounds logical as in manual it is also mentioned that the rxtx has this role of gathering eeprom data form other modules

I need to reverse engineer were the following tables are stored:

eep_cor -force  update.log
Starting update of RX tables. Please wait...
Clearing EEPROM ...
Creating if filter index table 18378
Creating IQIF temp deviation table 18915
Creating IQIF module deviation table 18910
Creating RX-IF3-level table 18980
Creating mixer level table 18890
Creating frequency band table 18900
Creating standard RF1 setting table 18510
Creating standard RF2 setting table 18505
Creating standard IF setting table 18500
Creating standard path setting table 18710
Creating IF path deviation table 18940
Creating standard RF1 temperature deviation table 18605
Creating standard RF2 temperature deviation table 18535
Creating standard RF2 temperature deviation table 18545
Creating standard RF2 temperature deviation table 18555
Creating standard RF2 temperature deviation table 18565
Creating standard RF2 temperature deviation table 18575
Creating standard RF2 temperature deviation table 18585
Creating standard RF2 temperature deviation table 18595
Creating standard IF temperature deviation table 18525
Creating standard RF1 module deviation table 18600
Creating standard RF2 module deviation table 18530
Creating standard RF2 module deviation table 18540
Creating standard RF2 module deviation table 18550
Creating standard RF2 module deviation table 18560
Creating standard RF2 module deviation table 18570
Creating standard RF2 module deviation table 18580
Creating standard RF2 module deviation table 18590
Creating standard IF module deviation table 18520
Creating standard path deviation table 18730
Creating standard path deviation table 18740
Creating standard path deviation table 18750
Creating standard path deviation table 18760
Creating standard path deviation table 18770
Creating standard path deviation table 18780
Creating standard path deviation table 18790
Creating RF1 gain hardware table 18920
Creating RF2 gain hardware table 18922
Creating IF gain hardware table 18924
Creating path deviation index table 18720
Creating LCU fine gain table 18515
Creating data dependency table 18960
Creating data dependency table 18970
Creating RF gain index table 18933
Creating IF gain index table 18934
Creating user correction table 18700
Storing tables ...

Starting update of TX tables. Please wait...
Clearing EEPROM ...
Creating if filter index table 18378
Creating IQIF temp deviation table 18415
Creating IQIF module deviation table 18410
Creating COPRO-AUC deviation table 18355
Creating TX-IF3-level table 18480
Creating mixer level table 18390
Creating frequency band table 18400
Creating tuning filter table 19000
Creating standard RF1 setting table 18010
Creating standard RF2 setting table 18005
Creating standard IF setting table 18000
Creating standard path setting table 18210
Creating IF path deviation table 18440
Creating standard RF1 temperature deviation table 18105
Creating standard RF2 temperature deviation table 18035
Creating standard RF2 temperature deviation table 18045
Creating standard RF2 temperature deviation table 18055
Creating standard RF2 temperature deviation table 18065
Creating standard RF2 temperature deviation table 18075
Creating standard RF2 temperature deviation table 18085
Creating standard RF2 temperature deviation table 18095
Creating standard IF temperature deviation table 18025
Creating standard RF1 module deviation table 18100
Creating standard RF2 module deviation table 18030
Creating standard RF2 module deviation table 18040
Creating standard RF2 module deviation table 18050
Creating standard RF2 module deviation table 18060
Creating standard RF2 module deviation table 18070
Creating standard RF2 module deviation table 18080
Creating standard RF2 module deviation table 18090
Creating standard IF module deviation table 18020
Creating standard path deviation table 18230
Creating standard path deviation table 18240
Creating standard path deviation table 18250
Creating standard path deviation table 18260
Creating standard path deviation table 18270
Creating standard path deviation table 18280
Creating standard path deviation table 18290
Creating RF1 gain hardware table 18420
Creating RF2 gain hardware table 18422
Creating IF gain hardware table 18424
Creating path deviation index table 18220
Creating LCU fine gain table 18015
Creating data dependency table 18460
Creating data dependency table 18470
Creating RF gain index table 18433
Creating IF gain index table 18434
Creating user correction table 18200
Storing tables ...
Restart correction processor ...


So main question is:

Where are these stored and how to retrieve them so we can change them. The ASC100 most likely uses tables 182xx and 187xx (path deviation), user correction 18200 and 18700 are also a correction in the path deviation range so that make sense !

So next goal is to retrieve these table from the CMU

[RF_fanatic]

It took me quite a while to understand how the software deals with all the tables.

Eventually there was no other option than to revers engineer the cmu at software level.

The cmu debugger gave quite some usefull information on the available commands in relation to all cor_xxx options and eep_xxx options.

I just found out that not all tables are extracted by the eep_xxx options. This means that there are tables left out on purpose on module level like table 2 and 300 for instance. And I also noticed an internal rxtx table not accesable by a for me known eep_xxx command. These are in the  18000  range.

As reprogramming modules like the rxtx and filling them with completly other valeus did not have any effect I more and more am certain that it will use the hidden tables which are set back to default during update.

This also makes sense considering the documentation mentions that the rxtx serves as central module were corrections are stored. This seems to be truth but they didn't mention that an internal rxtx seems to be doing this. It also makes extra sense since the rxtx tables are only containing rxtx settings and i couldn't  find related files to for instance FE settings inside the rxtx.

I managed to extract as a trial a small part of such hidden table. But haven't analyzed it yet.

This would also explain why after a hw change levels are no longer within calibration as the default tables are set back. 

Will dig into this in the upcomming days

[richnormand]

""This would also explain why after a hw change levels are no longer within calibration as the default tables are set back. 

Will dig into this in the upcoming days""

Interesting, you are getting way ahead of me here.

[RF_fanatic]

Ok I needed some time to dig into it but have a very good impression on how it works.

All modules have their own individual factory calibration settings as far as I can see. All together they will work in any mixture of modules from various CMU's but the levels are not calibrated.

All the tables are taken into account in the overall settings. These overal settings are not the standard tables but are the "hidden tables"

I managed to get the data details of the "hidden tables" by using the Save Table to file command (cor_stf) instead of the eprom to ascii commands ( eep_e2a)

There are 3 hidden large tables and I have identified 137 of them with as table sets:

Internal RX
Internal TX
Internal Default

I have compared the effect of changing modules and unit to unit compare to see which tables are standard and which are changing.

To get the special tables was quite tricky as all tables are updated after module update so I needed to have a still sealed CMU to directly get the tables before any updates as I tried to find out where the calibration values are stored.

I could bring back 137 tables to 68 tables which acually changed. The content of these tabels is quite similar to tables of the RXTX units but with other values, so this is where all other modules are taken into account.

How exactly the values are made is not sure to me, but that is something to find out later.

After knowing how it worked I was able to inject changed tables into the machine, at the moment I'm chaning the TXTX tables to correct the spectrum but results are not yet what I expected. What I did was the sequence as I mentioned in one of my older posts, so to use a signal generator, measure the value with the CMU, calculate the difference and use the difference to change the calibrated value.

Important here to know is that you should not change the RXTX (even though it works) before making a copy of the eeprom with the original values. As there should be another place where this probably must be done.

Strange thing however is that it doesn;t exactly meet my expectations, it seems that just using the corrected value gets you closer to the result but not spot on. Actually chaning only a few values has an influence on many responses. So it's more complex. I need to find out the exact formula before I can do this more effective. At the moment I've written some codes to get the results and automaticly giving the corrected values which I can enter into the new Ascii file before uploading it again to the eeprom. But as the results are not exaclty what I expect I must do some more homework.

It would really help me if I would be able to use the user correction file to get quick results and see the effect before changing it in the tables itself but for some reason the correction table USERCOR1.DAT is seen by the CMU but doesn't do anything while checking it.

Has any of you got the 5.20 version? I only need that part of the cmu firmware as all my other versions uptill 5.10 did not accept the file.

To show the progress I will share some pictures of the band 5 adjustment (>2200mhz) In the first picture I had used extreme deviations of 20 which ends up giving approx 10dB difference. The other files are made after I recalculated the correction values. Goal ofcourse it to get a flat line (even though the CMU has a uncertaincy level of 0,9dB according the specs, so getting a straight line would be better than the specs of the CMU. As you see I'm getting close, actually very close sometimes, but in between frequencys not being part of the correction frequencies cause some strange spikes.

Will dig into it deeper in upcomming weeks.

[RF_fanatic]

Unchanged "hidden internal" tables.

The RX/RX_ path is for my internal use (that is the path were I stored the internal retrieved files) Comments are the function of the tables

 RX\RX_   18500   standard IF setting table
 RX\RX_   18505   standard RF2 setting table
 RX\RX_   18605   standard RF1 temperature deviation table
 RX\RX_   18720   path deviation index table
 RX\RX_   18730   standard path deviation table
 RX\RX_   18890   mixer level tables
 RX\RX_   18920   RF1 gain hardware table
 RX\RX_   18922   RF2 gain hardware table
 RX\RX_   18924   IF gain hardware table
 RX\RX_   18933   
 RX\RX_   18934   IF gain index table
 TX\TX_   2   
 TX\TX_   18000   standard IF setting table
 TX\TX_   18005   standard RF2 setting table
 TX\TX_   18085   standard RF2 temperature deviation table
 TX\TX_   18095   standard RF2 temperature deviation table
 TX\TX_   18105   standard RF1 temperature deviation table
 TX\TX_   18220   path deviation index table
 TX\TX_   18390   mixer level tables
 TX\TX_   18420   RF1 gain hardware table
 TX\TX_   18422   RF2 gain hardware table
 TX\TX_   18424   IF gain hardware table
 TX\TX_   18433   
 TX\TX_   18434   IF gain index table
 DE\DE_   2   Ident
 DE\DE_   12100   
 DE\DE_   12600   
 DE\DE_   14200   # optimal absolute level at 1. mixer (X14 & X17) (TX)
 DE\DE_   14210   # measured relative level at 1. mixer (X14 & X17) (TX)
 DE\DE_   14240   # Switch level for power settings (TX)
 DE\DE_   14241   
 DE\DE_   14245   
 DE\DE_   14248   
 DE\DE_   14250   # Bounds of frequency bands (TX)
 DE\DE_   14260   # SAW-filter characteristic (TX)
 DE\DE_   14700   # optimal absolute level at 1. mixer (X14 & X17) (RX)
 DE\DE_   14710   # measured relative level at 1. mixer (X14 & X17) (RX)
 DE\DE_   14740   # Switch level for power settings (RX)
 DE\DE_   14745   
 DE\DE_   14746   
 DE\DE_   14747   
 DE\DE_   14748   
 DE\DE_   14750   # Bounds of frequency bands (RX)
 DE\DE_   14760   # SAW-filter characteristic (RX)
 DE\DE_   15000   # Output level with calsource (TX)
 DE\DE_   15005   
 DE\DE_   15020   # voltage characteristic of tuning filter (TX)
 DE\DE_   15021   
 DE\DE_   15120   # PLL settings of TX-LO3 with temp.-dyn.-IF2-sweep
 DE\DE_   15125   
 DE\DE_   15550   # Comb generator settings
 DE\DE_   15620   # PLL settings of RX-LO3 with temp.-dyn.-IF2-sweep
 DE\DE_   15625   
 DE\DE_   15900   # RXTX gain and offset values for diagnosis
 DE\DE_   15910   # diagnosis settings
 DE\DE_   15920   # limits of diagnosis voltages
 DE\DE_   15940   
 DE\DE_   17000   
 DE\DE_   17010   
 DE\DE_   17500   
 DE\DE_   17510   
 DE\DE_   18000   
 DE\DE_   18005   
 DE\DE_   18010   
 DE\DE_   18500   standard IF setting table
 DE\DE_   18505   standard RF2 setting table
 DE\DE_   18510   standard RF1 setting table
 DE\DE_   20000   
 DE\DE_   20100   

[RF_fanatic]

Affected tables which are made by the CMU after calculating and taking all modules into account:

 RX\RX_   18515   LCU fine gain table
 RX\RX_   18520   standard IF module deviation table
 RX\RX_   18525   standard IF temperature deviation table
 RX\RX_   18530   standard RF2 module deviation table
 RX\RX_   18535   standard RF2 temperature deviation table
 RX\RX_   18540   standard RF2 module deviation table
 RX\RX_   18545   standard RF2 temperature deviation table
 RX\RX_   18550   standard RF2 module deviation table
 RX\RX_   18555   standard RF2 temperature deviation table
 RX\RX_   18560   standard RF2 module deviation table
 RX\RX_   18565   standard RF2 temperature deviation table
 RX\RX_   18570   standard RF2 module deviation table
 RX\RX_   18575   standard RF2 temperature deviation table
 RX\RX_   18580   standard RF2 module deviation table
 RX\RX_   18585   standard RF2 temperature deviation table
 RX\RX_   18590   standard RF2 module deviation table
 RX\RX_   18595   standard RF2 temperature deviation table
 RX\RX_   18600   standard RF1 module deviation table
 RX\RX_   18710   standard path setting table
 RX\RX_   18740   standard path deviation table
 RX\RX_   18750   standard path deviation table
 RX\RX_   18760   standard path deviation table
 RX\RX_   18770   standard path deviation table
 RX\RX_   18780   standard path deviation table
 RX\RX_   18790   standard path deviation table
 RX\RX_   18875   
 RX\RX_   18876   
 RX\RX_   18877   
 RX\RX_   18878   
 RX\RX_   18940   
 RX\RX_   18960   data dependency table
 RX\RX_   18970   data dependency table
 TX\TX_   18015   LCU fine gain table
 TX\TX_   18020   standard IF module deviation table
 TX\TX_   18025   standard IF temperature deviation table
 TX\TX_   18030   standard RF2 module deviation table
 TX\TX_   18035   standard RF2 temperature deviation table
 TX\TX_   18040   standard RF2 module deviation table
 TX\TX_   18045   standard RF2 temperature deviation table
 TX\TX_   18050   standard RF2 module deviation table
 TX\TX_   18055   standard RF2 temperature deviation table
 TX\TX_   18060   standard RF2 module deviation table
 TX\TX_   18065   standard RF2 temperature deviation table
 TX\TX_   18070   standard RF2 module deviation table
 TX\TX_   18075   standard RF2 temperature deviation table
 TX\TX_   18080   standard RF2 module deviation table
 TX\TX_   18090   standard RF2 module deviation table
 TX\TX_   18100   standard RF1 module deviation table
 TX\TX_   18210   standard path setting table
 TX\TX_   18230   standard path deviation table
 TX\TX_   18240   standard path deviation table
 TX\TX_   18250   standard path deviation table
 TX\TX_   18260   standard path deviation table
 TX\TX_   18270   standard path deviation table
 TX\TX_   18280   standard path deviation table
 TX\TX_   18290   standard path deviation table
 TX\TX_   18375   
 TX\TX_   18376   
 TX\TX_   18377   
 TX\TX_   18378   
 TX\TX_   18460   data dependency table
 TX\TX_   18470   data dependency table
 TX\TX_   18480   TX-IF3-level table
 TX\TX_   19000   tuning filter table
 TX\TX_   19050   

[RF_fanatic]

Tables which changed but have no effect (as change was caused by other influence (version))

 RX\RX_   18510   standard RF1 setting table
 RX\RX_   18980   RX-IF3-level table
 TX\TX_   18010   standard RF1 setting table

[richnormand]

But as the results are not exaclty what I expect I must do some more homework.



Has any of you got the 5.20 version? I only need that part of the cmu firmware as all my other versions uptill 5.10 did not accept the file.


Will dig into it deeper in upcomming weeks.

Interesting progress here but they don't make it easy or simple it looks like

Sorry I cant help for the 5.20 version I seem to have 5.03. Are the difference in functionality worth trying to update?

Keep fighting 

[Velund]

Hello everyone!

Now trying to repair CMU200 that after a number of small fixes started to boot, but analyzer shows 2 dB less than wideband power meter (correct level displayed there).

(started new thread - https://www.eevblog.com/forum/repair/rohde-schwarz-cmu200-repair-(analyzer-levels)/msg1145649/#msg1145649 )

I suspect that it is RxTx unit fault (if I'm correct that wideband power meter is a part of frontend - I do not see any details on block diagram in service manual). At the same time, I cannot check this, as I do not have spare RxTx unit to swap for testing.

Another question - if I will be able to "borrow" RxTx unit from calibrated CMU200 (which was cal'd in service center and probably have that path deviation tables), will I destroy that deviation tables if that RxTx unit will be put to my own CMU200 to test?

And one more question to gurus - does CRTU-RU have the same RxTx unit as CMU-200?

[RF_fanatic]

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.
 

Perhaps good news, I am back after a few months of absence. And yesterday focussed on the band problem issue with on of my units. and found the problem in the not very likely plugin on the DIG unit.

https://www.eevblog.com/forum/repair/rohde-schwarz-cmu200-repair-of-analyzer-level-dips/msg1160112/#msg1160112

[RF_fanatic]

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.

Replace : 1100.2500.02 board from the DIG unit (at least that solved it here with a band gap like yours)

[RF_fanatic]

At the moment I'm going to focus on the RXTX boards. I have some good working DIG and FE units so the only variable is the RXTX board, which enables me to check these boards for errors as the other boards are OK.

Seems like a tedious task, as it involves a lot of hardware and I have no schematic what so ever...

But well once this hurdle is taken it can open a lot of possibilities to repair these.

One thing which is easy to check is the correction processor, but these all seem to work (update firmware part is needed when replacing it)

Any clues were to check when levels are deviating is appreciated.

[lowtension]

Here some examples.

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

Just want to confirm that you are 100% correct, i had the same issue, red values on some frequencies and levels,  RF tests never passed,  have another cmu200 fully working, started to replace the front end and then the TXRX module, lastly replaced the DSP board (A7) then it worked and passad all the rf tests 

[richnormand]

Here some examples.

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

Just want to confirm that you are 100% correct, i had the same issue, red values on some frequencies and levels,  RF tests never passed,  have another cmu200 fully working, started to replace the front end and then the TXRX module, lastly replaced the DSP board (A7) then it worked and passad all the rf tests

For those of us that do not have a second unit to substitute do you have some insight of what to look for in the DSP board?
I'll locate mine and give it a good look for anything apparent next time I open the CMU200. Now on the "to do" list.

[RF_fanatic]

From my experience with the DIG /DSP unit:

* Hangs during initiation session (ser. nr. Not recognized)
   1100.3220.02 (28%)
   1100.2130.03 (72%)
* Level of TX to low -20dB
   1100.2130.03 (75%)
   1100.1956.04 (25%)
* Level of TX to low (endless)
   1100.2130.03 (50%)
   1100.1956.04 (50%)
* Crashes during measurement, or irregular measurement levels (flat lines etc), or very slow
   1100.3220.02 (100%)
* Bandgap dips
  1100.2500.02 (100%)
* slightly to high >5 or to low <5 over full range
  1100.2500.02 (100%)

[MavMitchell]

Hi, I know this is a really old thread, but I thought I would start here.

I am working on issues with recently acquired CMU200. After fixing the Keyboard/No boot issues I have found it wont generate on the main generator. The aux gen works and the levels look fine.  When enable the output the noise floor comes up around the selected frequency but no carrier. I'm just wondering if anyone has seen this before. It receives fine and the levels look good.

It fails all the RF internal Loop tests.

Cheers


Edit: Actually This was a self inflicted problem. I forgot to replace the large power connector on the Digital card.
All self test now pass.

[piotrekjan]

Hi,

Do you have some spare board 1100.2500.02 to sell/borrow ? I have band gap issue in my unit and want check does it do fixation ?

Regards,
Piotr