Author Topic: new killer scope in town - a true game changer from R&S - RTB2002 & RTB2004 (Read 818030 times)

hwj-d · « **Reply #2650 on:** March 06, 2020, 02:04:28 am »

Quote from: Chefbastler on March 05, 2020, 11:14:45 pm

Quote from: Harjit on March 05, 2020, 05:57:26 pm
Is there a new version of FW for the RTB2004 coming out anytime soon? The last release was more than a year ago.

I hope too.
The actual version have some bugs around the logik protocol analyzer, signal generator, ...
I sent a bug report to R&S last year.

What's about to share your buglist here?

agdr · « **Reply #2651 on:** March 09, 2020, 11:25:33 pm »

Quote from: Rich@RohdeScopesUSA on February 28, 2020, 02:34:50 pm

... it sounds like all future revisions) won't change the FFT behavior for low frequencies.

.
.

And since I'm sure I'll get asked "why", I didn't get a lot of details but it sounds like there are some limitations in finding a sweet spot for the FFT and the team has decided to optimize for other areas outside of low frequency.

-Rich

Just curious, how low? What frequency "minimum" did they optimize for? Audio guy here.

Thanks!

bayjelly · « **Reply #2652 on:** March 10, 2020, 12:50:57 am »

The problem is really that the FFT function is insisting on filling its 128k FFT points, even if that takes a very long time and the actual FFT window size is much much smaller than that.

The benefit is that you can change window side and position after capture, which is normally nice, but not worth the downside in low-freq applications.

It would be very nice if instead you could simply force the capture size to be the much smaller window size. But I have a suspicion that the reason this is not changed, is that that could require a larger-than-tiny change of the FPGA logic, rather than just a software change.

maginnovision · « **Reply #2653 on:** March 10, 2020, 01:16:08 am »

Is there any chance of making r&s instrument view useful? I can't even connect over USB, only Ethernet. Is this in active development or just maintenance?

Hydron · « **Reply #2654 on:** March 10, 2020, 10:21:54 am »

Quote from: bayjelly on March 10, 2020, 12:50:57 am

The problem is really that the FFT function is insisting on filling its 128k FFT points, even if that takes a very long time and the actual FFT window size is much much smaller than that.

The benefit is that you can change window side and position after capture, which is normally nice, but not worth the downside in low-freq applications.

It would be very nice if instead you could simply force the capture size to be the much smaller window size. But I have a suspicion that the reason this is not changed, is that that could require a larger-than-tiny change of the FPGA logic, rather than just a software change.

Thanks for the good explanation - much better than my attempt a few pages back.
This is why I was asking for something as simple as a toggle for the acquisition behaviour - either operate as now (which would keep the benefit of changing window parameters after acquisition), or limit acquisition memory depth to the current window size (allowing for much faster update rate and more interactive use at low sample rates).

Rich@RohdeScopesUSA · « **Reply #2655 on:** March 10, 2020, 05:36:32 pm »

Quote from: maginnovision on March 10, 2020, 01:16:08 am

Is there any chance of making r&s instrument view useful? I can't even connect over USB, only Ethernet. Is this in active development or just maintenance?

I'm embarrassed to admit I haven't even used it $:-\$ Is there something specific you're looking for? If so, feel free to PM me and I'll talk with Munich about it.

-Rich

Minter · « **Reply #2656 on:** March 19, 2020, 03:35:52 am »

I'm not sure if this has been brought up before but I think I'm seeing a bug in the SPI protocol decoder. I have a SPI master configured for Mode 0 (CPOL=0, CPHA=0), and I have the protocol decoder configured to latch data on the rising edge of SCLK. The SPI master controller that I'm looking at is a little naughty; it sends out 32-bit words in 8-bit bursts, asserting MOSI between bursts. However the data on the MOSI line is always valid at the rising edge of SCLK. The transaction consists of multiple 32-bit words with CS asserted for the duration of the transaction.

In the attached screenshots the master is sending the word 0x01000040 but the scope is decoding the data as 0x30000161. It seems like the decoder is latching MOSI on the falling edge of SCLK, however if I configure the decoder for falling edge I get a different result (0x03010141). Am I just missing something here?

Thanks

JoHr · « **Reply #2657 on:** March 19, 2020, 08:52:13 am »

Quote from: Minter on March 19, 2020, 03:35:52 am

In the attached screenshots the master is sending the word 0x01000040 but the scope is decoding the data as 0x30000161. It seems like the decoder is latching MOSI on the falling edge of SCLK, however if I configure the decoder for falling edge I get a different result (0x03010141). Am I just missing something here?

Thanks

Hi, have you tried with rising slope on your clock source?

For the fourth image you have send you are decoding on a falling clock slope, which is the same slope when data is changing.
Due to some jitter and the high frequency you get wrong decodings.

A rising edge on clock slope shall bring up a clean decoding for your setup.

Minter · « **Reply #2658 on:** March 19, 2020, 06:15:38 pm »

Quote from: JoHr on March 19, 2020, 08:52:13 am

Hi, have you tried with rising slope on your clock source?

Yes, the protocol decoder was configured for a rising edge clock for the first 3 screenshots. I purposefully misconfigured the scope in the 4th screenshot only to try and get a better understanding of how the decoder is handling clock edges.

Now that I've looked more closely, it looks like there is more granularity on the protocol decoder's MOSI bit trace vs. the corresponding logic analyzer trace. I wonder if the protocol decoder is processing undersampled data? I assumed it was a software decoder operating on the 1.25Gsps trace data.. it would be a shame if not.

nctnico · « **Reply #2659 on:** March 19, 2020, 06:35:10 pm »

The protocol decoder is using decimated data. What is your clock rate? You are running the SPI at around 60MHz if I'm not mistaken which is over the maximum SPI clock rate.

Minter · « **Reply #2660 on:** March 19, 2020, 08:40:41 pm »

Quote from: nctnico on March 19, 2020, 06:35:10 pm

The protocol decoder is using decimated data. What is your clock rate? You are running the SPI at around 60MHz if I'm not mistaken which is over the maximum SPI clock rate.

You're correct, the SPI clock is close to 70 MHz. Do you happen to know the sampling rate or maximum supported clock rate? The only bus speed limitations I could find in the user manual pertained to the UART decoder (3 Mbps.)

Thanks!

nctnico · « **Reply #2661 on:** March 19, 2020, 08:46:14 pm »

Quote from: Minter on March 19, 2020, 08:40:41 pm

Quote from: nctnico on March 19, 2020, 06:35:10 pm
The protocol decoder is using decimated data. What is your clock rate? You are running the SPI at around 60MHz if I'm not mistaken which is over the maximum SPI clock rate.

You're correct, the SPI clock is close to 70 MHz. Do you happen to know the sampling rate or maximum supported clock rate? The only bus speed limitations I could find in the user manual pertained to the UART decoder (3 Mbps.)

Thanks!

I have managed to push the RTM3004 to 62.5MHz during my testing but the official limit is 25MHz. I assume the RTB2004 has similar limits.

Harjit · « **Reply #2662 on:** March 21, 2020, 05:17:58 pm »

On my RTB2004, I'm moving the screen left / right using the Horizontal Position knob and the waveforms are moving up and down.

Please find attached four pictures that were taken in sequence with the Horizontal Position knob rotated one click between them.

If you are running on Windows, put the four pictures in the same folder, open one with Photo Viewer and then use the left / right arrow to move between the pictures and you can easily seem them moving up / down. The Orange waveform is the easiest to see the effect on because it is on top of a grid line.

This makes measurements difficult.

matches · « **Reply #2663 on:** April 04, 2020, 03:09:10 pm »

Quote from: skench on June 07, 2017, 10:07:30 am

So after upgrading to the latest firmware version I thought I would run the Self Alignment routine.

It failed with this message:

Channel: 1
Alignment not possible.

ERROR-ID: 201-59.1.23014

I followed the instruction to the letter.
I then retried but with a terminator on Channel 1 input and then the Self Alignment passed.

Do I have a problem?

Thanks

Hi, where did you find the instructions?
I have a similar Error.

"Channel: 0
Alignment not possible.

Description: 201-59.0:6"

In the User Manual I could not find any error description.

Regards

Hydron · « **Reply #2664 on:** April 05, 2020, 10:00:47 am »

Are you running the latest firmware (a bit over a year old at this point)? I think there was a fix for calibration issues somewhere along the line - I had similar issues with one firmware but managed to coax it into self-aligning once, and never had problems on later firmwares.

matches · « **Reply #2665 on:** April 07, 2020, 08:41:58 am »

Jep, the latest 2.202 FW is installed.

As it was new, id had an older FW and I could perform a self alignment without errors.

Regards

Rich@RohdeScopesUSA · « **Reply #2666 on:** April 07, 2020, 04:13:47 pm »

Quote from: matches on April 07, 2020, 08:41:58 am

Jep, the latest 2.202 FW is installed.

As it was new, id had an older FW and I could perform a self alignment without errors.

Regards

I'll see what I can find out!

-Rich

Rich@RohdeScopesUSA · « **Reply #2667 on:** April 07, 2020, 04:16:11 pm »

Quote from: Harjit on March 21, 2020, 05:17:58 pm

On my RTB2004, I'm moving the screen left / right using the Horizontal Position knob and the waveforms are moving up and down.

Please find attached four pictures that were taken in sequence with the Horizontal Position knob rotated one click between them.

If you are running on Windows, put the four pictures in the same folder, open one with Photo Viewer and then use the left / right arrow to move between the pictures and you can easily seem them moving up / down. The Orange waveform is the easiest to see the effect on because it is on top of a grid line.

This makes measurements difficult.

Hi Harjit - running a self alignment should help.

-Rich

stafil · « **Reply #2668 on:** April 20, 2020, 03:36:25 am »

Is there a hack for this?

KaneTW · « **Reply #2669 on:** April 20, 2020, 03:43:23 am »

Not to my knowledge. R&S running promotions for most of the time made it not particularly interesting to develop a hack.

stafil · « **Reply #2670 on:** April 20, 2020, 08:02:24 pm »

Quote from: KaneTW on April 20, 2020, 03:43:23 am

Not to my knowledge. R&S running promotions for most of the time made it not particularly interesting to develop a hack.

Are the promotions for upgrade, after you buy the scope, or you have to take advantage of them when purchasing the scope?

maginnovision · « **Reply #2671 on:** April 20, 2020, 08:24:11 pm »

RTB - https://www.tequipment.net/Rohde-&-Schwarz/RTB2K-COM4/Mixed-Signal-Oscilloscopes-(MSO)/

RTM - https://www.tequipment.net/Rohde-&-Schwarz/RTM-COM4US/Mixed-Signal-Oscilloscopes-(MSO)/

RTA - https://www.tequipment.net/Rohde-&-Schwarz/RTA-COM4US/Mixed-Signal-Oscilloscopes-(MSO)/

bayjelly · « **Reply #2672 on:** April 20, 2020, 08:44:29 pm »

Are there any promotions for just the upgrades? I bought my RTB2004 with all software options except for the bandwidth upgrade, so it's still at 70MHz. I thought several times about upgrading the bandwidth, but it's easily $1000.

stafil · « **Reply #2673 on:** April 21, 2020, 08:35:56 pm »

Quote from: KaneTW on April 20, 2020, 03:43:23 am

Not to my knowledge. R&S running promotions for most of the time made it not particularly interesting to develop a hack.

That's a pity. I would really love an RTB or even an RTM, but I don't think I can justify buying a non-hackable scope.

KaneTW · « **Reply #2674 on:** April 21, 2020, 08:46:21 pm »

It's unfortunate that no hack exists but I'm not regretting my RTB-COM4 purchase, except maybe that I should've gotten a RTM.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: new killer scope in town - a true game changer from R&S - RTB2002 & RTB2004 (Read 818030 times)

Share me