CRTU-RU software

[fisafisa]

Hi all
I have bought one of these monsters from ebay.
It comes with the dos opsw version 3.23.
I have read the posts from this july.
Anybody got ahead with improving usability of the instrument?
Linux, gpib etc?
Is there a windows version of the dos opsw?
As it is the windows partition is almost useless.

Regards
Filippo

[davorin]

Version 4.35 is the last version I have.....and the 5.xx cersion you mentioned couldn't be installed from PCMCIA card as it complained that untgz.exe is corrupt....
Maybe the CMU200 firmware is not compatible with the CRTU-RU...

Speaking of Linux and so on...that's why I currently have two of those CRTU-RUs....one for reverse engineering and hopefully one day running Linux....

[fisafisa]

Any progress on the linux front?
I definitely support your idea of putting linux there!

Ciao

BTW
I was able to extract the files from the intallation package.
the untgz program simply hangs.
I have used dosbox to create a dos environment where to play with the R&S files.
Infact I had to manually join the archive parts copy /b archiv.000 + archiv.001 + ......
This should have been performed by the archive.exe program which did not work. Maybe the dosbox emulation is not good enough.
Then I tried with the untgz.exe which hang without completing
Using a modern windows program I was the able to uncompress the file.

[fisafisa]

For anybody reading that might be interested:
I found version 5.21 from the R&S website (base sw)
http://www3.rohde-schwarz.com/www/FileTranCS.nsf/alias/SR001Z?OpenDocument
and version 5.22 of GSM sw
http://www3.rohde-schwarz.com/www/FileTranCS.nsf/alias/sr003z?OpenDocument

main question, for me, is whether I can use these in my CRTU-RU

[davorin]

Not much there to see on the Linux front.....have to pick up frist a USB to IDE Adapter for testing...unfortunately the CRTU-RU can't be booted from USB sticks or USB CDROMs.

But sure I document the progress as well as pictures from the inside to a new site I just registered a domain name...(will be hosting other measurement stuff as well there ;o)

[fisafisa]

Let me know if you need help in your porting to linux.
I am looking forward to your website
Ciao

[davorin]

At least I kept an old IDE CDROM drive....think I might hook it up today and try booting a Linux CD and see what "dmesg" reports....

[fisafisa]

The main issue will be to reverse engineer windows drivers.
The good news is that we have the apis.
One would expect that the apis will simply call funcions exported by the drivers.

...

[Wuerstchenhund]

Not much there to see on the Linux front.....have to pick up frist a USB to IDE Adapter for testing...unfortunately the CRTU-RU can't be booted from USB sticks or USB CDROMs.)

All CMU200 and all CRTU-RUs (except those with the old FMR5 controller with AMD K5/K6 CPU) can boot from USB drives. I've booted mine from USB CDROM many times.

[Wuerstchenhund]

Version 4.35 is the last version I have.....and the 5.xx cersion you mentioned couldn't be installed from PCMCIA card as it complained that untgz.exe is corrupt....
Maybe the CMU200 firmware is not compatible with the CRTU-RU...

CMU200 and CRTU-RU use the exact same DOS software and updates.

I was able to extract the files from the intallation package.
the untgz program simply hangs.
I have used dosbox to create a dos environment where to play with the R&S files.
Infact I had to manually join the archive parts copy /b archiv.000 + archiv.001 + ......
This should have been performed by the archive.exe program which did not work. Maybe the dosbox emulation is not good enough.
Then I tried with the untgz.exe which hang without completing
Using a modern windows program I was the able to uncompress the file.

DOSBox isn't a good tool as its made for DOS games mostly, plus the CRTU/CMU200 run DOS Embedded with a special virtual memory manager.

If the archive on those links you found (which look very much like abandoned parts of the R&S website and may or may not contain working software) are complete then you have to update the software with the Version Manager on the CRTU/CMU200. If the update via Version Manager doesn't work then it's very likely that the package is corrupt/incomplete.

Speaking of Linux and so on...that's why I currently have two of those CRTU-RUs....one for reverse engineering and hopefully one day running Linux....

As stated in earlier post the CRTU-RU is a pretty complex instrument, using proprietary ASICs which are completely undocumented, so while you can certainly run Linux on the FMR (controller PC) it's IMHO overly optimistic to believe that you can control any of its test and measurement hardware through it. It's magnitudes more complex than say hacking some Rigol firmware to unlock software options.

I'd rather focus on writing some better Windows software for it, which is much easier as Windows drivers for the hardware exist, the programming interface is documented and most CRTU-RUs even come with a copy of Microsoft Visual C++.

[fisafisa]

I could post CRC and sizes of all the files in the package to check whether they are ok.
Anybody willing to check them?

As for the software, I quite agree with Wuerstchenhund worries about the complexity of the endeavour.
Having linux on it would be more than great, but we could also use wine as a way to load and execute windows dll under linux.
The main issue remain the drivers which need to be reverse engineered, which is tough.

My CRTU says pentium III when booting, I guess that is one of the new versions that can boot off usb.
Any way to access the bios setup?
I tried F2 or esc but with no success.

Regards
Filippo

[tmbinc]

I tend to be less optimistic for reverse-engineering the Windows drivers, and more optimistic in reversing/extending the DOS software.

The Windows software is optimized towards GSM functionality. The RF functionality is very basic, essentially very little more than "tune path 1,2 to txfreq x, rxfreq y, with attenuations a,b" is exposed. Frequency Sweeping (necessary for the spectrum analyzer) is not exposed, for example. (Or I missed it.)

The DOS OPSW, at least the main software (i.e. not the tools), is a "modular" 32-bit system (using the PharLap extender; it's basically simulates a Win32 environment in DOS, so it shares the PE file format and some more things). Many symbols are exported, helping disassembly. For example the GSM functionality is a bunch of DLLs that get runtime-linked and provide the GSM features. It should be possible to add custom modules that neatly integrate into the main UI.,

Also there is, as far as I know, only a single ASIC in the system - the DDC chip. Everything else is "just" FPGAs (which tend do only do glue-logic/interfacing, and not a lot of functionality), or DSPs (which custom code, of course).

So, writing software (running under Linux for example) that uses the device can be accomplished. Sure it's harder than just hacking existing software. But this wouldn't be the first device where a linux-based replacement firmware was written for. Examples are d-Box II, gaming consoles, iPod, ... It's possible, it's just a lot of work.

[davorin]

Speaking of ASIC/FPGA....what is exactly reprogrammed when switching the version in version manager?

[G0HZU]

It's possible, it's just a lot of work.

Also, you have to decide if you are spending all this time polishing a turd

These CMU/CRTU instruments are not that great in terms of RF performance because they are heavily compromised towards being basic go/no go testers for mobile phones. Sure, you get an analyser, sig gen and power meter but the performance they offer is mediocre at best.

So I would argue that they simply aren't worth the time and effort involved unless you just want to do the work as a learning exercise or if you wanted to make a profit from the work by selling it on to others.  Even if you end up with complete control of the instrument you are stuck with mediocre performance because the overall hardware platform is so compromised.

If you added up all the hours it would take and then charge yourself at just $20/hour you would end up 'paying' a huge cost to just polish that obsolete turd

[davorin]

Well..if someone would offer me an electronic/software/network job that pays me for 100 hours I could easily afford a nicer instrument (o;

For me curiosity is the best teacher....so need to keep my brain occupied (o;

[tmbinc]

As so often, money is the wrong way to think about a problem. But let's say we'd do the math. Let's say I spent a ridiculous amount of 1000 hours on this project, and let's say we could make it wonderful things. At $20/h, that's 20k. In terms of R+S list price (since we're talking time == money, we also need to talk about list prices), I don't think you can buy a lot of tech that does wonderful things for ~$12k (=$20k minus taxes).

And I disagree with G0HZU's assessment of the turd-ness of the device, for the record.

[davorin]

+1 for you :-)

[Wuerstchenhund]

And I disagree with G0HZU's assessment of the turd-ness of the device, for the record.

You're not alone, I, too, disagree with that statement. Actually, the RF performance of CRTU and CMU200 actually isn't that bad, and in general performs much better than say the Rigol DSA815 which doesn't seem to attract similar criticism (but then it's not sold as cell phone tester). The RF generator performs at least roughly similar to many entry-level RF generators in the same frequency range. Which at the end of the day isn't that surprising considering that these devices weren't exactly cheap (a basic CRTU-G sold for in excess of $150k, the WCDMA variants for closer to $250k), so we're not talking about some primitive WaveTek GSM testers for cell phone shops here.

I'd say for the money these devices go for these days they're pretty much unbeatable. I do have a very good lab grade standalone SA (R&S FSP, which even out-perfoms the venerable HP 856x Series) but often find that the CRTU is good enough, plus it boots much faster.

[G0HZU]

If you spent a 'lot' of free time on writing code for this instrument you are still constrained to a platform with poor spurious performance, poor phase noise, limited capture bandwidth and (I'm guessing) 12bit technology in the IF ADC and the IQ modulator.

I would argue that someone with the time and talent to do this work would be far better off looking forwards with new (chipset?) technology rather than backwards at this old test set.

But at the end of the day it's up to the individual to decide...

I'd say for the money these devices go for these days they're pretty much unbeatable. I do have a very good lab grade standalone SA (R&S FSP, which even out-perfoms the venerable HP 856x Series) but often find that the CRTU is good enough, plus it boots much faster.

For basic use of the various HW features it offers yes, but would you really want to spend a whole lot of time rewriting code for them considering the performance limitations of the hardware?

I do have a very good lab grade standalone SA R&S FSP, which even out-perfoms the venerable HP 856x Series

FWIW the FSP analysers are medium class analysers rather than high end. Try measuring a fairly decent 4GHz oscillator for phase noise at 100kHz offset with the FSP. They aren't really designed for that because they compromise the synthesiser performance against cost. The dynamic range of the RF converter isn't that great either and the specs betray the obvious design compromises in the RF converter section when compared against a genuine high end analyser.

I basically wouldn't want to use the FSP series for everyday RF design work but I'd be happy to still use something from the HP856x range despite the lack of a modern digital IF. I think we have some FSP type analysers in the test dept at work but having looked at the specs I don't think I'll rush over to play with one

[Wuerstchenhund]

I'd say for the money these devices go for these days they're pretty much unbeatable. I do have a very good lab grade standalone SA (R&S FSP, which even out-perfoms the venerable HP 856x Series) but often find that the CRTU is good enough, plus it boots much faster.

For basic use of the various HW features it offers yes, but would you really want to spend a whole lot of time rewriting code for them considering the performance limitations of the hardware?

No, I wouldn't, especially since the existing software already works well enough and the user doesn't have to fight through cell phone testing specific menus as on other cell phone testers. So I would agree with you that this is pretty much a waste of time.

I do have a very good lab grade standalone SA R&S FSP, which even out-perfoms the venerable HP 856x Series

FWIW the FSP analysers are medium class analysers rather than high end. Try measuring a fairly decent 4GHz oscillator for phase noise at 100kHz offset with the FSP. They aren't really designed for that because they compromise the synthesiser performance against cost. The dynamic range of the RF converter isn't that great either and the specs betray the obvious design compromises in the RF converter section when compared against a genuine high end analyser.

Yes, the the FSP is a mid-range SA but it's a mid-range SA as of 2008 while the HP 856x were high end SAs back in the 1980's, and while the working principle of both is roughly the same, technology has improved noticeably in the roughly 35+ years since the the HP came out. The truth is that the HP 856x's performance is no longer high-end and looks a bit paltry when compared with a modern day high end SA like the R&S FSW or the older FSU Series, or even against the pretty old FSIQ (which came out in 2001).

The RF performance of the FSP Series is just fine, even more so for the later FSP models with FMR7 (which run XP instead of NT for the older models), as is it's phase noise, plus the FSP Series covers a much larger bandwidth (up to 40GHz). What the FSP lacks is some more advanced signal analysis capabilities (i.e. I/Q measurements) but then that was never available for the 856x boat anchors either.

I basically wouldn't want to use the FSP series for everyday RF design work but I'd be happy to still use something from the HP856x range despite the lack of a modern digital IF. I think we have some FSP type analysers in the test dept at work but having looked at the specs I don't think I'll rush over to play with one

I wouldn't use it for everyday RF design at work but that's similarly true for the 856x either, as both lack analysis functionality I need. I certainly wouldn't hesitate to use the FSP for some simpler measurements for which I wouldn't touch a 856x any more, simply because it's large, loud, slow, and has been out of support for over a decade while the FSP is compact, silent, pretty fast (aside from booting), fully supported and offers similar RF performance.

But each to their own I guess.

Don't get me wrong, the 856x were great back in the days, and still offer good RF performance, but they pretty much have had their days, and are no longer the gold standard that they once were.

[G0HZU]

Yes, the the FSP is a mid-range SA but it's a mid-range SA as of 2008 while the HP 856x were high end SAs back in the 1980's, and while the working principle of both is roughly the same, technology has improved noticeably in the roughly 35+ years since the the HP came out.

Sure, the FSP has various modern advantages compared to an old school swept analyser (eg a digital IF with extremely good log performance and a modern DSP engine) but its RF converter performance will not be in the same class in terms of far out phase noise, IP3 and 2HI across the frequency range of the analyser.

-108dBc/Hz typical phase noise at 100kHz offset at CF of 3GHz.
-118dBc/Hz typical phase noise at 1MHz offset at CF of 3GHz.

This is not lab grade performance. Even my ancient 8566 (HP's dev for this analyser began in the late 1960s) will be typically 10dB better than this and the 8566 phase noise performance isn't particularly stunning. I have a very old HP8566A/B here and it shows about -119dBc/Hz at a 100kHz offset here. It also shows -134dBc/Hz at a 1MHz offset at 3GHz CF when driven by an E4433B sig gen.

That's 16dB better than the published typical performance of the FSP at this frequency and a 1MHz offset.  Note that I don't know if the sig gen phase noise is the limit here or the analyser itself. Something like the 12-15 year old Agilent PSA could be about 10dB better than the 8566 here.

Also, have a look at how much the performance of the FSP falls away at low frequencies. eg noise floor and linearity. This is a clue towards the design compromises in its RF converter. However, it looks to be highly portable and has modern connectivity etc so I'm sure R&S sold quite a few of them.

[tmbinc]

Back to to the original topic, I was able to install the downloaded base software on my CRTU using the following steps:

1. Unpack BASEV5.21.exe; you'll get a number of ARCHIV.0?? files, and a CONFIG.INI (and a couple of more files)
2. copy /b ARCHIV.0?? archiv.tgz
3. un-gzip; depending on the tool, you may get a "trailing payload" warning.
3. Boot the CRTU into Windows. On the DOS OPSW partition (containing "CMU" etc.), create \CMU\BINV5.21.
4. Copy all files from "archive" into there - it will end up with \CMU\BIN_V5.21\BASE\bsw\dll etc.
5. Copy CONFIG.INI into \CMU\BIN_V5.21\CONFIG.INI
6. Optionally, unpack the GSM stuff, and add "GSMSV5.22" to CONFIG.INI
7. reboot into DOS OPSW, and keep pressing MENU/SELECT to enter version manager
8. "Activate Software"
9. It should list V5.21; select it, and activate it. (It will take a while)
10. If you get a "FATAL ERROR" about not being able to open "REFTREE.DAT", press alt-f4 (exit DOS OPSW to dos prompt), go into C:\CMU\BIN_V5.21, and run "tools\reftree", it will create tools\reftree.dat. Reboot.

[davorin]

Great finding :-)

Any new stuff/features found so far in 5.21?

[fisafisa]

...
you have beaten me to it.
Was just about to add the missing config.ini and try again.
Well any new feature?

Ciao F

[fisafisa]

it worked.
did not see any new feature yet.

f