Rohde & Schwarz CMU200 RxTx module issues, help needed. - Page 1
Forum section: electronics / repair

author: richnormand
author_rank: Unknown
timestamp: September 06, 2016, 07:04:20 pm
content: 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

author: richnormand
author_rank: Unknown
timestamp: September 11, 2016, 07:14:57 pm
content: 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 path3) 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 signalsfor 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 elseIf 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.

author: Brainbox
author_rank: Contributor
timestamp: September 12, 2016, 06:30:31 am
content: 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 ?

author: richnormand
author_rank: Unknown
timestamp: September 12, 2016, 04:26:49 pm
content: Quote from: Brainbox on September 12, 2016, 06:30:31 amThe 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.

author: rastro
author_rank: Frequent Contributor
timestamp: September 13, 2016, 05:47:43 pm
content: 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/infoI 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 aDC blockon 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

author: richnormand
author_rank: Unknown
timestamp: September 13, 2016, 08:46:21 pm
content: 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.

author: rastro
author_rank: Frequent Contributor
timestamp: September 13, 2016, 10:41:53 pm
content: 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

author: richnormand
author_rank: Unknown
timestamp: September 19, 2016, 04:44:10 pm
content: 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 testexcept for a small range (see photo).This is good progress. Now I need to find why that range of frequency and power fails.

author: rastro
author_rank: Frequent Contributor
timestamp: September 19, 2016, 05:59:11 pm
content: Quote from: richnormand on September 19, 2016, 04:44:10 pmYour 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

author: richnormand
author_rank: Unknown
timestamp: September 19, 2016, 06:50:42 pm
content: 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.

author: rastro
author_rank: Frequent Contributor
timestamp: September 19, 2016, 09:34:16 pm
content: 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.1dBm3. 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: September 20, 2016, 05:01:56 pm
content: 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: September 20, 2016, 08:31:09 pm
content: Here some examples.Only difference between these test was a swap of a DSP unit.

author: richnormand
author_rank: Unknown
timestamp: September 21, 2016, 12:53:55 am
content: 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 regionLooks 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 dBmRedid 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......

author: rastro
author_rank: Frequent Contributor
timestamp: September 21, 2016, 03:54:00 am
content: 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: September 21, 2016, 08:16:21 pm
content: 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

author: richnormand
author_rank: Unknown
timestamp: September 22, 2016, 01:23:35 am
content: Quote from: RF_fanatic on September 21, 2016, 08:16:21 pmNice.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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: September 22, 2016, 06:43:43 pm
content: Hello RichBased 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 inputsAcutally 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

author: richnormand
author_rank: Unknown
timestamp: September 23, 2016, 12:36:50 am
content: Quote from: RF_fanatic on September 22, 2016, 06:43:43 pmSounds like a plan!Thanks RF_Fanatic

author: RF_fanatic
author_rank: Regular Contributor
timestamp: September 30, 2016, 10:04:47 pm
content: 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.pdfMost easy way would be to alter the tables if you pull out the HDD and directly edit the files

author: rastro
author_rank: Frequent Contributor
timestamp: October 01, 2016, 12:50:10 pm
content: 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 01, 2016, 03:17:02 pm
content: 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.

author: richnormand
author_rank: Unknown
timestamp: October 02, 2016, 08:12:53 pm
content: Quote from: RF_fanatic on September 30, 2016, 10:04:47 pmI 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 tooI 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 comboFinal 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 yikesDid 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

author: Brainbox
author_rank: Contributor
timestamp: October 03, 2016, 09:42:42 am
content: 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 DOSThat 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_14060UPDATE_INDEX: 01.01ROWS: 23COLUMNS: 2ROW_ID_TYPE: FIX32D3COLUMN_ID_TYPE: UINT8DATATYPE: FIX16D2AUX1: 30.15AUX2: 34.41AUX3: 0.00#===================================# MHz IDs...# COL 1 2#===================================0: 1 53#-----------------------------------1: 1200.000 2.40 0.022: 1215.000 2.45 0.023: 1235.000 2.44 0.024: 1250.000 2.44 0.025: 1260.000 2.45 0.026: 1270.000 2.48 0.017: 1280.000 2.52 0.028: 1290.000 2.54 0.019: 1300.000 2.57 0.0010: 1330.000 2.67 -0.0211: 1350.000 2.67 -0.0212: 1370.000 3.01 -0.0213: 1400.000 3.47 -0.0414: 1415.000 3.24 -0.0515: 1430.000 2.96 -0.0616: 1450.000 2.56 -0.1117: 1470.000 2.46 -0.1218: 1500.000 2.43 -0.2019: 1530.000 2.40 -0.2520: 1570.000 2.33 -0.3521: 1585.000 2.28 -0.3722: 1595.000 2.25 -0.3823: 1607.000 2.25 -0.39ROWS: 9COLUMNS: 25ROW_ID_TYPE: FIX32D3COLUMN_ID_TYPE: UINT8DATATYPE: FIX16D2AUX1: 29.91AUX2: 34.54AUX3: 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.342: 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.443: 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.474: 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.375: 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.176: 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.037: 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.188: 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.179: 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_14040UPDATE_INDEX: 02.02ROWS: 32COLUMNS: 2ROW_ID_TYPE: FIX32D3COLUMN_ID_TYPE: UINT8DATATYPE: FIX16D2AUX1: 29.66AUX2: 33.34AUX3: 0.00#===================================# MHz IDs...# COL 1 2#===================================0: 1 53#-----------------------------------1: 1.000 -0.61 -1.752: 3.000 -0.85 -2.013: 5.000 -0.81 -1.864: 7.000 -0.88 -1.645: 10.000 -0.95 -1.456: 15.000 -0.99 -1.327: 20.000 -0.95 -1.288: 25.000 -0.89 -1.259: 30.000 -0.83 -1.2610: 40.000 -0.72 -1.2511: 50.000 -0.67 -1.2712: 75.000 -0.55 -1.3213: 100.000 -0.40 -1.4014: 125.000 -0.23 -1.5015: 150.000 -0.02 -1.6116: 175.000 0.12 -1.7417: 200.000 0.32 -1.8518: 250.000 0.55 -2.0019: 275.000 0.64 -1.9720: 300.000 0.71 -1.8621: 325.000 0.76 -1.6622: 350.000 0.80 -1.4123: 375.000 0.83 -1.1424: 400.000 0.86 -0.8925: 435.000 0.90 -0.5726: 470.000 0.93 -0.3427: 500.000 0.96 -0.1928: 525.000 0.98 -0.1229: 550.000 1.01 -0.0530: 575.000 1.02 -0.0131: 600.000 1.06 0.0332: 632.000 1.05 0.05And so there are many of them.At a first glance the TX spectrum is divided in the following divisions:10 -600 MHz600 -1200MHz1200-1700MHz1700-2200MHz2200-2700MHzThere 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_14200UPDATE_INDEX: 02.00ROWS: 3COLUMNS: 1ROW_ID_TYPE: 0COLUMN_ID_TYPE: 0DATATYPE: FIX16D2AUX1: 0.00AUX2: 0.00AUX3: 0.00#==============# level#==============1: -15.002: -25.003: -5.00# measured relative level at 1. mixer (X14 & X17) (TX)ID: USER_14210UPDATE_INDEX: 03.00ROWS: 2COLUMNS: 2ROW_ID_TYPE: 0COLUMN_ID_TYPE: 0DATATYPE: FIX16D2AUX1: 48.34AUX2: 54.55AUX3: 0.00#=======================# db# COL 1 2#=======================1: -23.00 -33.122: -36.00 -45.94Fortunately I have another complete and working CMU200 at hand, so can cross-reference some measured results.To be continued !

author: richnormand
author_rank: Unknown
timestamp: October 06, 2016, 05:12:37 am
content: Interesting Brainbox.I'll have a look (as soon as I get my bench back!)

author: richnormand
author_rank: Unknown
timestamp: October 10, 2016, 08:26:15 pm
content: 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 15, 2016, 10:25:26 pm
content: 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 measurementsFrom 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 to1.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.

author: Brainbox
author_rank: Contributor
timestamp: October 16, 2016, 08:15:12 am
content: 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.

author: richnormand
author_rank: Unknown
timestamp: October 17, 2016, 07:10:37 pm
content: Quote from: Brainbox on October 16, 2016, 08:15:12 amYou 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 CMU200Keep fighting.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 17, 2016, 09:26:47 pm
content: As mentioned it should be possible to compensate with the correction to get a flat linePlease 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.

author: Brainbox
author_rank: Contributor
timestamp: October 18, 2016, 02:38:45 pm
content: 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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 18, 2016, 08:38:46 pm
content: @BrainboxYes 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)

author: richnormand
author_rank: Unknown
timestamp: October 23, 2016, 10:23:41 pm
content: Quote from: rastro on September 19, 2016, 05:59:11 pmFinally got the replacement caps from Mouser, designed for high frequency use. No difference.So back to the software table correction approach.....

author: rastro
author_rank: Frequent Contributor
timestamp: October 24, 2016, 02:46:03 pm
content: Quote from: richnormand on October 23, 2016, 10:23:41 pmJust 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 24, 2016, 09:08:14 pm
content: Quote from: richnormand on October 23, 2016, 10:23:41 pmSorry to read it didn't solve the problemI 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 manuallyLthat it will download the module specific settings and stores it in the files starting with EEP_

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 25, 2016, 07:37:44 pm
content: Another interesting thingbesides the different corrections for each channel it also is more stricked in measuring criteria if you measure 1>4 or instance 1>1In 1>4 path I have seen RED failures even if the deviation is 2,3 dBIn 1>1 I saw some measurements indicated as correct even with 5dB differencesI also notices in the past that it also uses different deviation criteria between Bands

author: richnormand
author_rank: Unknown
timestamp: October 26, 2016, 03:39:56 am
content: Thanks for the feedback rastro and RF_fanaticHope 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 ACS100No 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.

author: rastro
author_rank: Frequent Contributor
timestamp: October 26, 2016, 01:49:42 pm
content: 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

author: richnormand
author_rank: Unknown
timestamp: October 28, 2016, 08:03:10 pm
content: Quote from: Brainbox on October 03, 2016, 09:42:42 amFound 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?

author: Brainbox
author_rank: Contributor
timestamp: October 28, 2016, 08:17:51 pm
content: 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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 28, 2016, 09:26:05 pm
content: 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 directoryAs 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.bineep_rxt2.bineep_cor.bineep_cor2.bineep_rxif.bineep_rxi2.bineep_auc.bineep_auc2.bineep_adc.bineep_adc2.bineep_fe.bineep_auxt.bineep_iqif.bineep_txm.bineep_mb.bin

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 28, 2016, 09:37:32 pm
content: During the update procedure it will do the following:First it will update the correction board firmware, the firmware are the ihx filesAfter that it will update the data of the boards using the following files :#------------------------------- AUC ----------------------------------------# adding the temperature table 20150 to all AUCNAME: AUCBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: auctdev.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 2.00) to AUC with TAZ 0.00 to TAZ 2.08NAME: AUCBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 0.00TAZEND: 2.08FILENAME: auc_200.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 2.01 or 2.10) to AUC with TAZ 2.09 to TAZ 4.01NAME: AUCBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 2.09TAZEND: 4.01FILENAME: auc_201.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 4.02 to TAZ 4.04NAME: AUCBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 4.02TAZEND: 4.04FILENAME: auc_301.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 2.01) to AUC with TAZ 5.00# In the file the UI is already 2.10NAME: AUCBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 5.00TAZEND: 5.00FILENAME: auc_201.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 5.02 to TAZ 5.04NAME: AUCBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 5.02TAZEND: 5.04FILENAME: auc_301.ascOPTUPDATE: 1#------------------------------- RXTX ---------------------------------------# adding temperature tables to all RXTX boardsNAME: RXTXBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: rttdev.ascOPTUPDATE: 1# adding LO3 setting table 15620 to all RXTX boardsNAME: RXTXBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: lo3sett.ascOPTUPDATE: 1# adding if temperature table 14026 to RXTX 11001404 with TAZ 0.00 to TAZ 8.99NAME: RXTXBOARDINDEX: 0PARTNUMBER: 11001404TAZSTART: 0.00TAZEND: 8.99FILENAME: rt_200.ascOPTUPDATE: 1# adding if temperature table 14026 to RXTX 11001733 with TAZ 9.00 to TAZ 10.21NAME: RXTXBOARDINDEX: 0PARTNUMBER: 11001733TAZSTART: 9.00TAZEND: 10.21FILENAME: rt_210.ascOPTUPDATE: 1# adding if temperature table 14026 to RXTX 11356702 with TAZ 1.00 to TAZ 1.15NAME: RXTXBOARDINDEX: 0PARTNUMBER: 11356702TAZSTART: 1.00TAZEND: 1.15FILENAME: rt_220.ascOPTUPDATE: 1#------------------------------- COR ----------------------------------------# adding default tables to CORNAME: CORBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: cordef.ascOPTUPDATE: 1#****************** CHANNEL 2 ************************#------------------------------- AUC ----------------------------------------# adding the temperature table 20150 to all AUCNAME: AUCBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: auctdev.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 2.00) to AUC with TAZ 0.00 to TAZ 2.08NAME: AUCBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 0.00TAZEND: 2.08FILENAME: auc_200.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 2.01 or 2.10) to AUC with TAZ 2.09 to TAZ 4.01NAME: AUCBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 2.09TAZEND: 4.01FILENAME: auc_201.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 4.02 to TAZ 4.04NAME: AUCBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 4.02TAZEND: 4.04FILENAME: auc_301.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 2.01) to AUC with TAZ 5.00# In the file the UI is already 2.10NAME: AUCBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 5.00TAZEND: 5.00FILENAME: auc_201.ascOPTUPDATE: 1# adding the temperature table 20151 (UI: 3.01) to AUC with TAZ 5.02 to TAZ 5.04NAME: AUCBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 5.02TAZEND: 5.04FILENAME: auc_301.ascOPTUPDATE: 1#------------------------------- RXTX ---------------------------------------# adding older temperature tables to all RXTX boardsNAME: RXTXBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: rttdev.ascOPTUPDATE: 1# adding LO3 setting table 15620 to all RXTX boardsNAME: RXTXBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: lo3sett.ascOPTUPDATE: 1# adding if temperature table 14026 to RXTX 11001404 with TAZ 0.00 to TAZ 8.99NAME: RXTXBOARDINDEX: 1PARTNUMBER: 11001404TAZSTART: 0.00TAZEND: 8.99FILENAME: rt_200.ascOPTUPDATE: 1# adding if temperature table 14026 to RXTX 11001733 with TAZ 9.00 to TAZ 10.21NAME: RXTXBOARDINDEX: 1PARTNUMBER: 11001733TAZSTART: 9.00TAZEND: 10.21FILENAME: rt_210.ascOPTUPDATE: 1# adding if temperature table 14026 to RXTX 11356702 with TAZ 1.00 to TAZ 1.15NAME: RXTXBOARDINDEX: 1PARTNUMBER: 11356702TAZSTART: 1.00TAZEND: 1.15FILENAME: rt_220.ascOPTUPDATE: 1#------------------------------- COR ----------------------------------------# adding default tables to CORNAME: CORBOARDINDEX: 1PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: cordef.ascOPTUPDATE: 1#******************** OTHERS *************************#------------------------------- FE -----------------------------------------# adding temperature table to all FENAME: FEBOARDINDEX: 0PARTNUMBER: 0TAZSTART: 0TAZEND: 0FILENAME: fetdev.ascOPTUPDATE: 1#------------------------------- IQIF ----------------------------------------# adding iqif tables to iqifboard 11356002.02NAME: IQIFBOARDINDEX: 0PARTNUMBER: 11356002VARIANT: 2TAZSTART: 0TAZEND: 0FILENAME: iqif204.ascOPTUPDATE: 1# adding iqif tables to iqifboard 11356002.03NAME: IQIFBOARDINDEX: 0PARTNUMBER: 11356002VARIANT: 3TAZSTART: 0TAZEND: 0FILENAME: iqif204a.ascOPTUPDATE: 1# adding iqif tables to iqifboard 11356125.02NAME: IQIFBOARDINDEX: 0PARTNUMBER: 11356125VARIANT: 2TAZSTART: 0TAZEND: 0FILENAME: iqif303.ascOPTUPDATE: 1# adding iqif tables to iqifboard 11356125.03NAME: IQIFBOARDINDEX: 0PARTNUMBER: 11356125VARIANT: 3TAZSTART: 0TAZEND: 0FILENAME: iqif303a.ascOPTUPDATE: 1# adding iqif tables to iqifboard 11356290.02NAME: IQIFBOARDINDEX: 0PARTNUMBER: 11356290VARIANT: 2TAZSTART: 0TAZEND: 0FILENAME: iqif400.ascOPTUPDATE: 1# adding iqif tables to iqifboard 11356290.03NAME: IQIFBOARDINDEX: 0PARTNUMBER: 11356290VARIANT: 3TAZSTART: 0TAZEND: 0FILENAME: iqif400a.ascOPTUPDATE: 1#------------------------------- AUXTX --------------------------------------# change diagnosis limits in AUXTXNAME: AUXTXBOARDINDEX: 0PARTNUMBER: 11359530TAZSTART: 0TAZEND: 0FILENAME: atx_000.ascOPTUPDATE: 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 usedthe rest is not that interesting

author: richnormand
author_rank: Unknown
timestamp: October 28, 2016, 09:50:13 pm
content: Thanks for the feedback both of you.Looks like its going to get more complicated....

author: RF_fanatic
author_rank: Regular Contributor
timestamp: October 29, 2016, 10:36:57 am
content: 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 settingson 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 aso-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

author: richnormand
author_rank: Unknown
timestamp: November 05, 2016, 04:51:54 pm
content: 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 usuallymeasured and stored as correctionMOBILE RADIO Radiocommunication testersRFIN1 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 3The 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 tableentries are the correction values. A semicolon indicates the end of a table line. During operation, thecorrection value is linearly interpolated between the individual frequency points; there is no interpolationbetween the level points. The frequency and level points are user-definable. A correction tablecan contain a total of 120 values.The user-specific correction of frequencyresponse and level response of the UniversalRadio Communication TesterR&S CMU200 is designed to be versatile(FIG 1, 2). Separate correction tables canbe compiled for each RF input and RFoutput. The user is free to decide on theUser-specific correction of frequency response and levelresponse: a snap with the R&S CMU20013number of frequency and level pointsto be set up. The tester linearly interpolatesthe level correction to be usedbetween the frequency points. The correctiontables (FIG 3) are easy to compileon any PC by means of a normal texteditor, or automatically by a measurementprogram, and are then loaded intothe mobile radio tester via the IEC / IEEEbus, RS-232-C interface or PCMCIA card,where they can be activated or deactivatedat 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)orhttps://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 :

author: RF_fanatic
author_rank: Regular Contributor
timestamp: November 05, 2016, 11:01:46 pm
content: 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.binIt 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.ascInfo: Number of bytes read from EEPROM: 22386Info: EEPROM content read successfully.Start conversion from binary to ASCIIIn 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_e2bI think you should read e2b as: Eeprom 2 BinaryExample : eep_e2b FE eep_fe.binI know that to write ascii to eeprom the command is:eep_a2elike is used in eep_a2e wcdmarx.ascSo 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?

author: richnormand
author_rank: Unknown
timestamp: November 06, 2016, 01:28:06 am
content: 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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: November 06, 2016, 06:24:09 pm
content: 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 worksSo now I have the same data both binary and ascii. The ascii files are identical from the format as the files in the _TABLES directorySo EUREKAThis 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 commandsSo this will at least solve how we can change the EEprom dataNext 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 thinkAs 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 addeep_e2a RXTX -idx0 eep_rxtx.asceep_e2a RXTX -idx1 eep_rxt2.asceep_e2a COR -idx0 eep_cor.asceep_e2a COR -idx1 eep_cor2.asceep_e2a RXIF3 -idx0 eep_rxif.asceep_e2a RXIF3 -idx1 eep_rxi2.asceep_e2a AUC -idx0 eep_auc.asceep_e2a AUC -idx1 eep_auc2.asceep_e2a ADC -idx0 eep_adc.asceep_e2a ADC -idx1 eep_adc2.asceep_e2a FE eep_fe.asceep_e2a AUXTX eep_auxt.asceep_e2a IQIF eep_iqif.asceep_e2a WCDMATX eep_txm.asceep_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

author: richnormand
author_rank: Unknown
timestamp: November 07, 2016, 10:11:00 pm
content: ""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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: November 08, 2016, 09:21:28 pm
content: 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,RXTXDSP module: ADC,AUCFE module: FEREF module: not tested yetIn 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 theRX 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 100No influence:OCXO, B21, B52, B41,So the COR fileshould be changedbut 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: November 10, 2016, 08:09:26 pm
content: Not much progress to change the correction for the pathI have focussed on the EEP_COR.BINAs mentioned above I converted it from module directly to readable asciiStrange 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 boardFor 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)

author: richnormand
author_rank: Unknown
timestamp: November 10, 2016, 09:11:07 pm
content: 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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: November 10, 2016, 10:31:55 pm
content: 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.ascUpload : eep_a2e -opt eep_cor.ascSo I use the following sequence: (you can copy paste it including comments); Upload changed COR data back to CMUeep_a2e -opt eep_cor.asc; Check if upload was accepted by downloading new COR eeprom dataeep_e2a COR -idx0 eep_cor.ascI'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 110x = path 220x = path 3These numbers are the numbers in the EEP_COR file in the frequency tablesThe subsequent numbers describe various gain level settings.But changing the frequency files doesn not have an effect so far..

author: richnormand
author_rank: Unknown
timestamp: November 10, 2016, 11:55:40 pm
content: I guess we need to find more info on what the ACS100 actually does to correct the response using these files?

author: RF_fanatic
author_rank: Regular Contributor
timestamp: November 11, 2016, 11:19:28 pm
content: 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 modulesI need to reverse engineer were the following tables are stored:eep_cor -force update.logStarting update of RX tables. Please wait...Clearing EEPROM ...Creating if filter index table 18378Creating IQIF temp deviation table 18915Creating IQIF module deviation table 18910Creating RX-IF3-level table 18980Creating mixer level table 18890Creating frequency band table 18900Creating standard RF1 setting table 18510Creating standard RF2 setting table 18505Creating standard IF setting table 18500Creating standard path setting table 18710Creating IF path deviation table 18940Creating standard RF1 temperature deviation table 18605Creating standard RF2 temperature deviation table 18535Creating standard RF2 temperature deviation table 18545Creating standard RF2 temperature deviation table 18555Creating standard RF2 temperature deviation table 18565Creating standard RF2 temperature deviation table 18575Creating standard RF2 temperature deviation table 18585Creating standard RF2 temperature deviation table 18595Creating standard IF temperature deviation table 18525Creating standard RF1 module deviation table 18600Creating standard RF2 module deviation table 18530Creating standard RF2 module deviation table 18540Creating standard RF2 module deviation table 18550Creating standard RF2 module deviation table 18560Creating standard RF2 module deviation table 18570Creating standard RF2 module deviation table 18580Creating standard RF2 module deviation table 18590Creating standard IF module deviation table 18520Creating standard path deviation table 18730Creating standard path deviation table 18740Creating standard path deviation table 18750Creating standard path deviation table 18760Creating standard path deviation table 18770Creating standard path deviation table 18780Creating standard path deviation table 18790Creating RF1 gain hardware table 18920Creating RF2 gain hardware table 18922Creating IF gain hardware table 18924Creating path deviation index table 18720Creating LCU fine gain table 18515Creating data dependency table 18960Creating data dependency table 18970Creating RF gain index table 18933Creating IF gain index table 18934Creating user correction table 18700Storing tables ...Starting update of TX tables. Please wait...Clearing EEPROM ...Creating if filter index table 18378Creating IQIF temp deviation table 18415Creating IQIF module deviation table 18410Creating COPRO-AUC deviation table 18355Creating TX-IF3-level table 18480Creating mixer level table 18390Creating frequency band table 18400Creating tuning filter table 19000Creating standard RF1 setting table 18010Creating standard RF2 setting table 18005Creating standard IF setting table 18000Creating standard path setting table 18210Creating IF path deviation table 18440Creating standard RF1 temperature deviation table 18105Creating standard RF2 temperature deviation table 18035Creating standard RF2 temperature deviation table 18045Creating standard RF2 temperature deviation table 18055Creating standard RF2 temperature deviation table 18065Creating standard RF2 temperature deviation table 18075Creating standard RF2 temperature deviation table 18085Creating standard RF2 temperature deviation table 18095Creating standard IF temperature deviation table 18025Creating standard RF1 module deviation table 18100Creating standard RF2 module deviation table 18030Creating standard RF2 module deviation table 18040Creating standard RF2 module deviation table 18050Creating standard RF2 module deviation table 18060Creating standard RF2 module deviation table 18070Creating standard RF2 module deviation table 18080Creating standard RF2 module deviation table 18090Creating standard IF module deviation table 18020Creating standard path deviation table 18230Creating standard path deviation table 18240Creating standard path deviation table 18250Creating standard path deviation table 18260Creating standard path deviation table 18270Creating standard path deviation table 18280Creating standard path deviation table 18290Creating RF1 gain hardware table 18420Creating RF2 gain hardware table 18422Creating IF gain hardware table 18424Creating path deviation index table 18220Creating LCU fine gain table 18015Creating data dependency table 18460Creating data dependency table 18470Creating RF gain index table 18433Creating IF gain index table 18434Creating user correction table 18200Storing 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: November 24, 2016, 12:00:05 am
content: 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

author: richnormand
author_rank: Unknown
timestamp: November 24, 2016, 02:25:34 am
content: ""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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: December 04, 2016, 08:21:37 pm
content: 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 RXInternal TXInternal DefaultI 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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: December 04, 2016, 09:02:02 pm
content: 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 tablesRX\RX_ 18500 standard IF setting tableRX\RX_ 18505 standard RF2 setting tableRX\RX_ 18605 standard RF1 temperature deviation tableRX\RX_ 18720 path deviation index tableRX\RX_ 18730 standard path deviation tableRX\RX_ 18890 mixer level tablesRX\RX_ 18920 RF1 gain hardware tableRX\RX_ 18922 RF2 gain hardware tableRX\RX_ 18924 IF gain hardware tableRX\RX_ 18933RX\RX_ 18934 IF gain index tableTX\TX_ 2TX\TX_ 18000 standard IF setting tableTX\TX_ 18005 standard RF2 setting tableTX\TX_ 18085 standard RF2 temperature deviation tableTX\TX_ 18095 standard RF2 temperature deviation tableTX\TX_ 18105 standard RF1 temperature deviation tableTX\TX_ 18220 path deviation index tableTX\TX_ 18390 mixer level tablesTX\TX_ 18420 RF1 gain hardware tableTX\TX_ 18422 RF2 gain hardware tableTX\TX_ 18424 IF gain hardware tableTX\TX_ 18433TX\TX_ 18434 IF gain index tableDE\DE_ 2 IdentDE\DE_ 12100DE\DE_ 12600DE\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_ 14241DE\DE_ 14245DE\DE_ 14248DE\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_ 14745DE\DE_ 14746DE\DE_ 14747DE\DE_ 14748DE\DE_ 14750 # Bounds of frequency bands (RX)DE\DE_ 14760 # SAW-filter characteristic (RX)DE\DE_ 15000 # Output level with calsource (TX)DE\DE_ 15005DE\DE_ 15020 # voltage characteristic of tuning filter (TX)DE\DE_ 15021DE\DE_ 15120 # PLL settings of TX-LO3 with temp.-dyn.-IF2-sweepDE\DE_ 15125DE\DE_ 15550 # Comb generator settingsDE\DE_ 15620 # PLL settings of RX-LO3 with temp.-dyn.-IF2-sweepDE\DE_ 15625DE\DE_ 15900 # RXTX gain and offset values for diagnosisDE\DE_ 15910 # diagnosis settingsDE\DE_ 15920 # limits of diagnosis voltagesDE\DE_ 15940DE\DE_ 17000DE\DE_ 17010DE\DE_ 17500DE\DE_ 17510DE\DE_ 18000DE\DE_ 18005DE\DE_ 18010DE\DE_ 18500 standard IF setting tableDE\DE_ 18505 standard RF2 setting tableDE\DE_ 18510 standard RF1 setting tableDE\DE_ 20000DE\DE_ 20100

author: RF_fanatic
author_rank: Regular Contributor
timestamp: December 04, 2016, 09:03:58 pm
content: Affected tables which are made by the CMU after calculating and taking all modules into account:RX\RX_ 18515 LCU fine gain tableRX\RX_ 18520 standard IF module deviation tableRX\RX_ 18525 standard IF temperature deviation tableRX\RX_ 18530 standard RF2 module deviation tableRX\RX_ 18535 standard RF2 temperature deviation tableRX\RX_ 18540 standard RF2 module deviation tableRX\RX_ 18545 standard RF2 temperature deviation tableRX\RX_ 18550 standard RF2 module deviation tableRX\RX_ 18555 standard RF2 temperature deviation tableRX\RX_ 18560 standard RF2 module deviation tableRX\RX_ 18565 standard RF2 temperature deviation tableRX\RX_ 18570 standard RF2 module deviation tableRX\RX_ 18575 standard RF2 temperature deviation tableRX\RX_ 18580 standard RF2 module deviation tableRX\RX_ 18585 standard RF2 temperature deviation tableRX\RX_ 18590 standard RF2 module deviation tableRX\RX_ 18595 standard RF2 temperature deviation tableRX\RX_ 18600 standard RF1 module deviation tableRX\RX_ 18710 standard path setting tableRX\RX_ 18740 standard path deviation tableRX\RX_ 18750 standard path deviation tableRX\RX_ 18760 standard path deviation tableRX\RX_ 18770 standard path deviation tableRX\RX_ 18780 standard path deviation tableRX\RX_ 18790 standard path deviation tableRX\RX_ 18875RX\RX_ 18876RX\RX_ 18877RX\RX_ 18878RX\RX_ 18940RX\RX_ 18960 data dependency tableRX\RX_ 18970 data dependency tableTX\TX_ 18015 LCU fine gain tableTX\TX_ 18020 standard IF module deviation tableTX\TX_ 18025 standard IF temperature deviation tableTX\TX_ 18030 standard RF2 module deviation tableTX\TX_ 18035 standard RF2 temperature deviation tableTX\TX_ 18040 standard RF2 module deviation tableTX\TX_ 18045 standard RF2 temperature deviation tableTX\TX_ 18050 standard RF2 module deviation tableTX\TX_ 18055 standard RF2 temperature deviation tableTX\TX_ 18060 standard RF2 module deviation tableTX\TX_ 18065 standard RF2 temperature deviation tableTX\TX_ 18070 standard RF2 module deviation tableTX\TX_ 18075 standard RF2 temperature deviation tableTX\TX_ 18080 standard RF2 module deviation tableTX\TX_ 18090 standard RF2 module deviation tableTX\TX_ 18100 standard RF1 module deviation tableTX\TX_ 18210 standard path setting tableTX\TX_ 18230 standard path deviation tableTX\TX_ 18240 standard path deviation tableTX\TX_ 18250 standard path deviation tableTX\TX_ 18260 standard path deviation tableTX\TX_ 18270 standard path deviation tableTX\TX_ 18280 standard path deviation tableTX\TX_ 18290 standard path deviation tableTX\TX_ 18375TX\TX_ 18376TX\TX_ 18377TX\TX_ 18378TX\TX_ 18460 data dependency tableTX\TX_ 18470 data dependency tableTX\TX_ 18480 TX-IF3-level tableTX\TX_ 19000 tuning filter tableTX\TX_ 19050

author: RF_fanatic
author_rank: Regular Contributor
timestamp: December 04, 2016, 09:05:16 pm
content: Tables which changed but have no effect (as change was caused by other influence (version))RX\RX_ 18510 standard RF1 setting tableRX\RX_ 18980 RX-IF3-level tableTX\TX_ 18010 standard RF1 setting table

author: richnormand
author_rank: Unknown
timestamp: December 08, 2016, 09:18:16 pm
content: Quote from: RF_fanatic on December 04, 2016, 08:21:37 pmInteresting progress here but they don't make it easy or simple it looks likeSorry 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

author: Velund
author_rank: Regular Contributor
timestamp: March 03, 2017, 02:36:29 am
content: 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?

author: RF_fanatic
author_rank: Regular Contributor
timestamp: March 14, 2017, 09:36:04 pm
content: Quote from: richnormand on October 17, 2016, 07:10:37 pmPerhaps 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

author: RF_fanatic
author_rank: Regular Contributor
timestamp: March 22, 2017, 12:59:14 pm
content: Quote from: Brainbox on October 16, 2016, 08:15:12 amReplace : 1100.2500.02 board from the DIG unit (at least that solved it here with a band gap like yours)

author: RF_fanatic
author_rank: Regular Contributor
timestamp: March 27, 2017, 09:02:38 pm
content: 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.

author: lowtension
author_rank: Contributor
timestamp: May 04, 2017, 08:44:05 pm
content: Quote from: RF_fanatic on September 20, 2016, 08:31:09 pmJust 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

author: richnormand
author_rank: Unknown
timestamp: May 04, 2017, 09:05:21 pm
content: Quote from: lowtension on May 04, 2017, 08:44:05 pmFor 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.

author: RF_fanatic
author_rank: Regular Contributor
timestamp: May 06, 2017, 09:22:01 pm
content: 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 -20dB1100.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 slow1100.3220.02 (100%)* Bandgap dips1100.2500.02 (100%)* slightly to high >5 or to low <5 over full range1100.2500.02 (100%)

author: MavMitchell
author_rank: Contributor
timestamp: February 14, 2019, 06:03:59 am
content: 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.CheersEdit: Actually This was a self inflicted problem. I forgot to replace the large power connector on the Digital card.All self test now pass.

author: piotrekjan
author_rank: Contributor
timestamp: July 18, 2020, 04:14:35 pm
content: 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