Rosemary Ainslie Circuit Demonstration, June 1 2013

[TinselKoala]

The LeCroy WaveSurfer 103Xi that I used for a while certainly did have its math affected by the trace vertical positioning offset, and it did display the offset value in the trace settings box just like Ainslie's 324. To get accurate math with this scope you had to either put all the baselines at the center vertical graticule marker or add/subtract the offset in the math, like .99 shows. I made a comment to this effect on .99's YT vid.

[MileHigh]

I am a bit surprised about the trace displacement/offset issue.  I note that you are supposed to let DSOs warm up before making measurements but this seems unusual to me.

Sometimes if you change the amount of brightness on a monitor it can affect other analog components in a device.  I doubt it applies to LCD displays.  I am talking about analog CRT monitors.  From the YT clips it looks like the DSO has a colour bit-mapped analog RGB CRT display.  I am assuming the possible analog affects are due to the analog RGB display drawing more power when the display is bright, which then affects the power supply rail voltages.  The slight voltage change can affect other parts of a given device.

It's a real mystery, the power draw of the CRT is not changing, only the display timing is changing slightly.  How could the A/D conversion get affected?  When Poynt displaces the trace on the screen the processor is doing extra work to update the bit map in the video frame buffer.  That represents a very small increase in power draw but I really doubt it could affect anything.  Unless there is some kind of hysteresis type affect coming into play at the A/D conversion level itself or in the post-A/D software filtering.

I just don't see any logical feedback mechanism that might be causing this problem.

Also, there may be an issue with compensating for trace displacement on the screen changing the voltage reading with a settable offset value.  I suggest that you check what voltage reading you are getting when you short the probe.  If you are seeing an offset voltage and not zero volts then that's a problem.  That will skew all low-level voltage measurements.  I suppose the work-around is to export the data and then apply a gain compensation factor to the data with a spreadsheet formula.

[picowatt]

The LeCroy WaveSurfer 103Xi that I used for a while certainly did have its math affected by the trace vertical positioning offset, and it did display the offset value in the trace settings box just like Ainslie's 324. To get accurate math with this scope you had to either put all the baselines at the center vertical graticule marker or add/subtract the offset in the math, like .99 shows. I made a comment to this effect on .99's YT vid.

TK,

On her scope, the offset numbers only indicate vertical position.

"Offset", as used on .99's scope, injects a DC voltage into the analog preamp input prior to the ADC.

On a DSO with a true offset function like .99's, where the offset signal is injected into the analog front end (preamp), the offset value must be subtracted from readings made when visually reading the displayed traces using the graticule.

As well, it looks like .99's scope automatically subtracts the applied offset from the values displayed in the "boxes", as his Vbatt and math product displays were unaffected by the applied offset (other than the accuracy improvement).

I am surprised, however, that the offset values are not able to be displayed on .99's scope.  Perhaps that function is buried in a yet to be found menu.  Otherwise, one would have to always recall the values from the offset function or just remember the offet values in order to directly read values from the display (without using cursors or the numbers in the "boxes").

I wonder how the voltage cursors on .99's scope handle the applied offset...

PW

[MileHigh]

PW:

"Offset", as used on .99's scope, injects a DC voltage into the analog preamp input prior to the ADC.

I was also wondering where the offset was being done.  That suggests a possible explanation.   By playing with the offset you are moving the "digitizing window" up and down in the full sweep of the A/D converter range (I am assuming.)  So it's possible that the upper range of the A/D conversion window will have a slightly different conversion slope than the lower range of the A/D conversion window.  That slight nonlinearity in the A/D conversion gets quasi-amplified when you start playing with the offsets and doing all of your digitizing and processing in a narrower digitizing window.

If I am right about the architecture, then the issue of how many bits you are working with for the full A/D conversion range and how many effective bits your "digitizing window" has also comes into play.  If your digitizing window is less than 8-bits wide then you start playing with the granularity issues and how the software filters and processes the data.

Just my $0.02.

MileHigh

[poynt99]

PW,

I need the increased accuracy, and hopefully I will be able to demonstrate why later.

"0" is at the zero ref line on the display, "+255" is the top graticule, and "-255" is the bottom graticule. If you use bits (either from a DC level at your input, or DC shift with vertical position), you effectively lose resolution.