Author Topic: Project Yaigol: Fixing Rigol scope design problems.  (Read 80058 times)

0 Members and 2 Guests are viewing this topic.

Offline Bud

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: ca
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #175 on: March 29, 2016, 05:07:23 pm »
Sorry I meant how did I manage to measure a 800MHz signal and get such good rise time on a 70/300MHz scope.
(the screenshots have some clues   :P )
 

Offline hendorog

  • Super Contributor
  • ***
  • Posts: 1324
  • Country: nz
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #176 on: March 29, 2016, 05:23:48 pm »
Doh - you even put red ellipses there.

I'm going back on holiday...
 

Offline hendorog

  • Super Contributor
  • ***
  • Posts: 1324
  • Country: nz
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #177 on: March 29, 2016, 05:32:47 pm »
So did ya hack the VGA into 900MHz mode?

Perhaps by resetting it after the scope had already started so it went into full bandwidth mode?
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 15014
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #178 on: March 29, 2016, 06:08:20 pm »
You're f***ing with our heads Bud, please put us out of our misery.  :-//
Avid Rabid Hobbyist
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 13086
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #179 on: March 29, 2016, 07:26:54 pm »
I'm going to say direct injection into ADC input.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline krivx

  • Frequent Contributor
  • **
  • Posts: 763
  • Country: ie
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #180 on: March 29, 2016, 07:58:51 pm »
I'm going to say direct injection into ADC input.

Tim

This seems likely, should it be surprising that the firmware will happily go along with this and give measurements well outside the specs? I'm not sure what the best method for handling this would be. 
 

Offline exe

  • Supporter
  • ****
  • Posts: 1175
  • Country: nl
  • self-educated hobbyist
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #181 on: March 29, 2016, 08:29:48 pm »
This seems likely, should it be surprising that the firmware will happily go along with this and give measurements well outside the specs? I'm not sure what the best method for handling this would be.

I would leave it as is because I don't see clear benefits in "sanity check" in this case because that would decrease "hackability". This also complicates the code, needless to say firmwares are not perfect, more complications potentially would make it less stable/feature rich.

Anyway, I think most measurements functions work with curves, not with measurement points. Performing sanity checks on this is just to tricky and quite pointless, imho.
 

Offline Circlotron

  • Super Contributor
  • ***
  • Posts: 1482
  • Country: au
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #182 on: March 29, 2016, 08:37:32 pm »
Sooo..... who's going to be the first to offer a drive-in-drive-out scope update service for this baby?
 

Online tautech

  • Super Contributor
  • ***
  • Posts: 15014
  • Country: nz
  • Taupaki Technologies Ltd. NZ Siglent Distributor
    • Taupaki Technologies Ltd.
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #183 on: March 29, 2016, 08:40:17 pm »
Sooo..... who's going to be the first to offer a drive-in-drive-out scope update service for this baby?
The parts won't cost much, but the labour........
Avid Rabid Hobbyist
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 9141
  • Country: gb
    • Having fun doing more, with less
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #184 on: March 29, 2016, 08:42:20 pm »
This seems likely, should it be surprising that the firmware will happily go along with this and give measurements well outside the specs? I'm not sure what the best method for handling this would be.

I would leave it as is because I don't see clear benefits in "sanity check" in this case because that would decrease "hackability".

Please explain the causal connection - if there is one.

Quote
This also complicates the code, needless to say firmwares are not perfect, more complications potentially would make it less stable/feature rich.

I can make it infinitely "feature rich", provided it isn't required that the features actually work.

Quote
Anyway, I think most measurements functions work with curves, not with measurement points.

I really don't understand what you are trying to say. A digitising scope can only measure points. Waveforms are only curves, until you are dealing at the level of individual photons and electrons and quantum, physics.

Quote
Performing sanity checks on this is just to tricky and quite pointless, imho.

If the manufacturers carelessly get that wrong, what else have they carelessly got wrong?

Old saying: "Fool me once, shame on you. Fool me twice, shame on me".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline exe

  • Supporter
  • ****
  • Posts: 1175
  • Country: nl
  • self-educated hobbyist
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #185 on: March 29, 2016, 08:56:27 pm »
I really don't understand what you are trying to say. A digitising scope can only measure points. Waveforms are only curves, until you are dealing at the level of individual photons and electrons and quantum, physics.

You move cursors on a waveform, not between points. Analytic functions (or whatever they called) work on waveforms. Why should they care how and what waveform was acquired? In some cases it can be an indication that something is wrong or outside the speck. But this is not a proper self-test for this.

If the manufacturers carelessly get that wrong, what else have they carelessly got wrong?

Why do you think this is wrong? Sorry, I feel like you just falling into "this is wrong and everyone who does not share my point of view is incompetent" without any reasoning.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 9141
  • Country: gb
    • Having fun doing more, with less
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #186 on: March 29, 2016, 09:26:53 pm »
I really don't understand what you are trying to say. A digitising scope can only measure points. Waveforms are only curves, until you are dealing at the level of individual photons and electrons and quantum, physics.
You move cursors on a waveform, not between points. Analytic functions (or whatever they called) work on waveforms. Why should they care how and what waveform was acquired? In some cases it can be an indication that something is wrong or outside the speck. But this is not a proper self-test for this.

Ah. You mean functions that work on continuous curve inferred by interpolating between the sampled points. So that is going to depend on the interpolation chosen, the circumstances undet which the interpolation is and isn't valid, and on whether the implementation is correct.

Is there a hint there?

Quote
If the manufacturers carelessly get that wrong, what else have they carelessly got wrong?
Why do you think this is wrong? Sorry, I feel like you just falling into "this is wrong and everyone who does not share my point of view is incompetent" without any reasoning.

Please don't snip the relevant bits in order to (try to) make a point. You wrote "Performing sanity checks on this is just to tricky and quite pointless".

If an instrument doesn't pass a sanity check, should you continue to put faith in the instrument?

Old saying: "Fool me once, shame on you. Fool me twice, shame on me".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 3408
  • Country: gb
  • Will design for cookies
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #187 on: March 29, 2016, 09:31:42 pm »
Sorry I meant how did I manage to measure a 800MHz signal and get such good rise time on a 70/300MHz scope.
(the screenshots have some clues   :P )

Display mode in the top screen is X-Y. You're feeding in an external, slower time base on the X channel.
 

Offline exe

  • Supporter
  • ****
  • Posts: 1175
  • Country: nl
  • self-educated hobbyist
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #188 on: March 29, 2016, 09:50:22 pm »
Okay, I think I was too strong on statements. I don't say "no check is ever needed". I say four things 1) I don't trust rigol implementing them 2) shouldn't be part of analytical functions. 3) may affect hackability 4) sanity check is very limited when analyzing unknown waveform. And here is why I think so.

1)
analytical functions != Input validation is a different thing. Checking the input range or "space between points" is fine. But...

2)
If it is too strict on checking inputs this may greatly harm hackability. How so? Imagine you removed restriction on bandwidth. But the scope "doesn't know" about this. So it can indicate a failure in this case. Or if I "overclock" it it may refuse work faster because "it checks the specs".

3)
It happened to me I'm a software developer, so I know a little bit about software. I didn't get your point about features, but I repeat my statement: more code -- more hassle to maintain it. If I knew they have good software specialists I would welcome more checks. But since it's rigol I have a fear that they don't have expertise. They can easily degrade scope performance when adding more validation. And it's not uncommon to see "software gone mad".

4) I think best check is the analysis of a signal with a known waveform. I'm not sure it is possible to catch most failures just by analyzing user input.
 

Offline Gixy

  • Regular Contributor
  • *
  • Posts: 192
  • Country: fr
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #189 on: March 29, 2016, 10:29:41 pm »
@AndyC:
This is the Cursor menu, X-Y is relative to the display of cursors, not the acquisition mode.
 

Offline Gixy

  • Regular Contributor
  • *
  • Posts: 192
  • Country: fr
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #190 on: March 29, 2016, 10:46:32 pm »
Bandwidth means -3dB at max frequency. Let's suppose your input signal amplitude is 5V, you have here 4mV, so an attenuation of more than -61dB, so clearly outside bandwidth. The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 9141
  • Country: gb
    • Having fun doing more, with less
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #191 on: March 29, 2016, 11:40:48 pm »
How did I make these screenshots ?

Is there any way that you can force the scope to show just the ADC samples, without interpolation / reconstruction / post-capture filtering?

For the rise/falltime, which points are being measured? What happens when the front-end is overloaded? Is it simply measuring noise and finding a signal?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: ca
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #192 on: March 30, 2016, 01:16:31 am »
Thanks guys for participating in the discussion. I will answer in the evening when get home, i do not like typing on my mobile. For now just can say there was no fiddling with the clock frequency, these are actual shots of high frequency and low rise/fall time signals. And still there is a common clue in both screenshots that seems has not been spotted yet.  :)
 

Offline exe

  • Supporter
  • ****
  • Posts: 1175
  • Country: nl
  • self-educated hobbyist
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #193 on: March 30, 2016, 01:28:14 am »
And still there is a common clue in both screenshots that seems has not been spotted yet.  :)

My guess is you hacked the input attenuator -- removed/modified low-pass filter.
 

Offline exe

  • Supporter
  • ****
  • Posts: 1175
  • Country: nl
  • self-educated hobbyist
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #194 on: March 30, 2016, 01:33:32 am »
The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.

I agree wit this. Removing interpolation and leaving only datapoints should show something triangle-like. Plus some input hacking imho.
 

Online AndyC_772

  • Super Contributor
  • ***
  • Posts: 3408
  • Country: gb
  • Will design for cookies
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #195 on: March 30, 2016, 01:39:36 am »
@AndyC:
This is the Cursor menu, X-Y is relative to the display of cursors, not the acquisition mode.

Ah, OK, fair enough.

Perhaps it's something to do with the signal level being extremely low (I see measurements of just a few mV... not sure how exactly they're being calculated)...? Very small amplitude means the system isn't limited by slew rate, because the V/sec rate is still within limits even if the input frequency is high.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 9141
  • Country: gb
    • Having fun doing more, with less
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #196 on: March 30, 2016, 03:07:11 am »
The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.

I agree wit this. Removing interpolation and leaving only datapoints should show something triangle-like. Plus some input hacking imho.

Why are you choosing that specific reconstruction? Why not  a zero-order hold or, better, just the impulses?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline exe

  • Supporter
  • ****
  • Posts: 1175
  • Country: nl
  • self-educated hobbyist
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #197 on: March 30, 2016, 08:41:21 am »
Why are you choosing that specific reconstruction? Why not  a zero-order hold or, better, just the impulses?

I think I meant "just impulses" (=no reconstruction?). I'm no expert in this stuff, it's just a picture that popped into my head -- dots connected with straight lines. May be because I saw this on youtube when the guy chose "no interpolation" on the scope. Probably, it was in "the signal path blog" and with a review of a 100GHz scope.
 

Offline hendorog

  • Super Contributor
  • ***
  • Posts: 1324
  • Country: nz
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #198 on: March 30, 2016, 09:21:48 am »
Thanks guys for participating in the discussion. I will answer in the evening when get home, i do not like typing on my mobile. For now just can say there was no fiddling with the clock frequency, these are actual shots of high frequency and low rise/fall time signals. And still there is a common clue in both screenshots that seems has not been spotted yet.  :)

The first screenshot has the bandwidth limit on - but is still measuring 800MHz...
Both traces look very sharp compared to the equivalent signal on my DS4k - is averaging turned on or is that typical when the scope is stopped?



 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 3233
  • Country: ca
Re: Project Yaigol: Fixing Rigol scope design problems.
« Reply #199 on: March 30, 2016, 01:23:09 pm »
Bandwidth means -3dB at max frequency. Let's suppose your input signal amplitude is 5V, you have here 4mV, so an attenuation of more than -61dB, so clearly outside bandwidth. The sampling rate being 2Gs/s, you're still in the Nyquist ratio of 2 samples/period, so the digitalized signal is still valid.

Nope, the waveform quickly becomes fuzzy after you cross the VGA set bandwidth limit.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf