There's little information on the CRTU-RU out there; I can't wait to see a teardown. For the CMU 200, it's a bit better, but I don't know how much of the architecture they share.
As I wrote before, they share almost everything. The CRTU
*is* a CMU200 with an additional Windows 2000 controller, a slightly different chassis (CRTU has additional RF ports where the CMU200 has 9pin Sub-Ds and a speaker) and different software. The CRTU also doesn't support all the options that the CMU200 supports (i.e. Audio Analyzer).
Here's the service manual for the CMU200: https://www.ntecusa.com/docs/RS_CMU200_CMU300_other.pdf ; section 3 has a block diagram. If we compare this with the "block diagram" in http://cdn.rohde-schwarz.com/pws/dl_downloads/dl_common_library/dl_news_from_rs/magazin/Neues171_englisch_72dpi.pdf (which also claims that the CRTU-RU uses the same RF components as the CMU200), then we can draw the following conclusions:
- The CRTU-RU is basically a two-channel (2x RX, 2x TX) CMU200.
Not really. Both CRTU and CMU200 can have one or two RF generators, as well as an optional two-channel audio generator. As I said, there's not much difference between them in terms of hardware, aside from some options not being available in the CRTU.
There's also a difference in bandwidth with the second generator, depening on which option is installed.
- But it gets better; on the "digital board", there's an ADC/DAC stage already. Everything further works on this digital data. (There's an optional hook for the I/Q analog data with the option CRTU-B7; it appears that it contains a separate DAC to get the digital I/Q RX back to analog, and just passes through the TX I/Q via a switch.)
- It's a bit unclear whether the "link handler" is part of the CRTU-RU or CRTU-PU; in the latter case, it'd mean that the digitalized data would be already available on an external port.
If I remember right all CRTUs have the digital output at the back, which is meant when they are part of the Protocol Analyzer (a separate large box with a DVD drive on the front).
(I'm not sure how the spectrum analyzer fits into this. The CMU200 _does_ appear to have the spectrum analyzer and signal generator ability; not sure why this is commonly mentioned as a difference to the CRTU-RU. It's probably just a power detector on the .. digital board?)
No, it's not. The spectrum analyzer is a Vector Spectrum Analyzer, i.e. no detector diode but an ADC that digitizes the whole frequency band and gets the individual frequency components via FFT. SA performance is quite good, it's pretty fast, although the sensitivity is pretty low.
And yes, all CMU200 have the Spectrum Analyzer, it's part of the Basic Functionality that comes with every unit. The same is true for the Power Meter btw. The difference to the CRTU is the software, and (if I remember right) the Spectrum Analyzer and Power Meter functionality wasn't available on the CRTU (which would be understandable, since the CRTU was designed as automated test system). But I haven't had that much to do with the CRTU, so I might be wrong on that.
I think this device is promising. Tapping the ADC data, and injecting the DAC data (for example via USB) would be an interesting extension to build; together with a plugin to gnuradio, this should make a wonderful RF frontend for SDR. Only limitation could the bandwidth.
Good luck. I'd say your're severely underestimating how complex these devices really are. For example, I'm pretty sure the ADC data isn't directly available from outside, but only via the proprietary DSPs which in turn connect to the backplane via an old-style 16bit ISA bus. You could of course connect directly to the ADC on the PCB but this will result in the unit failing during initialization (and probably powering down the module). There's also the mechanical component, as you would have to lead wires into the Digital Module which is a completely encapsulated unit with two small openings to provide sufficient airflow. In terms of SDR, the internal controllers in these devices are pretty slow (well, they don't need to be very fast for what they're doing) so that means you would have to use an external PC, for which you would have to design a suitable interface (the available GPIB and serial ports are too slow, and the optional network ports are for feeding IP data into the cell phone transmitter, not for communication with the system's controller). In short, it sounds like a mess and a very good way to produce a nice doorstop. Which would really be a shame.
If you want a RF front end for an SDR go and buy a $7 USB digital TV tuner, or any other of the wide range of suitable devices.[/list]