Pocket-Sized 6 GHz 1 TS/s ET Scope

[SJL-Instruments]

Indeed, at 5.8GHz the required level is different than 1GHz.  Is the sensitivity vs frequency defined somewhere?   I assume that we can bias that 200mV anywhere as long as we stay within the common mode range (+/-950mV).

We do not have an official spec for sensitivity vs. frequency. To give you a rough idea, generally the GigaWave can trigger off 60 mVpp @ 1 GHz. The trigger level must be centered within the peak-to-peak range. The 200 mVpp edge can have any DC bias within the specified range.
   

0.2 X 20 (probe attenuation) or 4V swing which is CMOS.  Even if you work reliably at 100mvp-p, or a 2V swing, that rules out most logic?  Are you expecting it to work with say LVDS and a 20X resistive probe?    The manual doesn't  offer any suggestions or guidelines when it comes to probing.

We would not recommend using a 20x resistive probe - even a 0.3 pF input capacitance, which is the lowest we've seen for a 20x commercial resistive probe, presents as ~270 ohm @ 2 GHz. The fastest transition time we've found is ~80 ps for a 20x passive probe, which is twice the 40 ps spec of the GigaWave.
At that point, we'd recommend using a 5x probe which has a flat 250 ohm input impedance up to 6 GHz. We have such a design, and plan to include a few as a standard accessory in the future. We are actually considering open-sourcing this design.

A 5x probe with LVDS would give a ~70 mVpp swing, which we have found that the GigaWave can trigger on directly @ 2 Gbps. However, we would recommend using an external clock or CDR for generating an eye diagram.

The THD will display as invalid if there isn't enough resolution to get an accurate measurement. You should have five full periods (ideally 10) to get a meaningful result. We'll clarify this in the manual.

Is the THD in your software calculated differently than the calibration certification?  If the settings are critical as far as replicating what you call out, you may want to define them.   

The THD in the calibration certificate is obtained via a time-domain regression, not an FFT. With only a few periods, the THD calculated from the FFT will depend on the windowing method used and the timebase range. The time-domain method is immune to these considerations (and gives statistical uncertainties on the extracted parameters).
We will mention this, as well as the exact timebase settings used, in the manual.

[SJL-Instruments]

As promised, we have released v2.5.7 of the software which adds math channels, histograms, and various other improvements. The accompanying manual has also been updated (revision H7).

[joeqsmith]

Interesting idea about including probes.  5X is getting down there.  I try to keep loading under 10% error and use 10X (500ohms) in many cases.   100 ohm differential termination with another 200 to ground on each leg .... maybe...   I guess as long as people understand the limits of the trigger it's fine.  Leave it up to them to sort out if it can be used or not.  Consider you may be using a delay line with the 5X probe, knocking another 6dB off.   A lot to consider.  As you said, it's down to price point.   

After starting the software, set all offsets to 0.  Entering 50 for scale on channel 1 will randomly select 50 V/div or 50 mV/div.  I would expect it to be predictable and was surprised that 50V would be valid.  Seems easy enough to reproduce. 

I have had the software appear to hang.  Basically it was displaying wait, but appeared not to be updating the plots as nothing was being displayed on the graph for all 4 channels.  Nothing, meaning a blank screen.  I changed the scale to 500mV/div, and it remained blank.   Offsets all set to 0.   I increased the input voltage to 500mVp-p with no triggers.  10MHz.   All I did was exit the software and restart, everything was working as expected.  I have not been able to replicate this but I have seen the software hang like this before with an earlier revision.

I am curious if you are getting any feedback on the UI.  It's easy enough to run but IMO, not very smooth.   

It's a real pain to hunt down your waveforms with manually setting the offset and scale.  Typing in the scales rather than the drop down selection do allow me to set it to what ever I want, but now its a bigger time waste entering all that data.   

I would like to see this thing have some sort of intelligent mode where is autoscales the vertical, locks the start of acquisition to the left, changing the vertical scale resets or at least causes min/max to track.    It's the same with dragging the waveform to change the offset, the min/max doesn't track it. It's a constant close waveforms and recreate.    Or if I change the vert scale for channel 1, the scale for the min/max don't track it. 

Having that start of acquisition time moving all over based on the Base is a pain.  I am constantly dragging waveforms.   

It's very possible that your customers like the UI.  Consider I am up there in years and have used a lot of different scopes, it could just be my bias on how they should work.   Years ago, I looked at a brand new logic analyzer from HP.  That is all I have ever used and for the most part, they all drove the same.  Even with the touch screen and single knob.  This new thing was like they had fired the entire staff, brought in new management that had no idea what a LA was, and decided to make a product that worked (in their minds) better than the old systems.  Or they had no idea how their old products drove.  To me it seemed they were trying to target software people for the end user rather than hardware.    It was so bad, I gave a simple test to other EEs to see if they could run it.  In the end, the software was why I didn't procure it. 

A few years ago I wanted to buy a better VNA for home hobby use.  Get out of the 1970s...   I looked at Picotech.  Really liked the hardware.  Price was high but specs are good.  4-receiver....  Then I tried their software and ditched the idea.   I reached out to them last year to make a series of videos on their VNA but no bites.   

Point being, software for these is IMO, is every bit as important as the hardware.   If it drives different than every product out there, it may not get a lot of acceptance.   Again, MO. 

[SJL-Instruments]

Interesting idea about including probes.  5X is getting down there.  I try to keep loading under 10% error and use 10X (500ohms) in many cases.   100 ohm differential termination with another 200 to ground on each leg .... maybe...   I guess as long as people understand the limits of the trigger it's fine.  Leave it up to them to sort out if it can be used or not.  Consider you may be using a delay line with the 5X probe, knocking another 6dB off.   A lot to consider.  As you said, it's down to price point.

Yes, the loading is not ideal. The 5x probe prioritizes flatness over loading. Perhaps we could offer both 5x and 10x probes. At high frequencies, you become limited by the characteristic impedance of the probe tips themselves, which (thought of as a transmission line) are ~200 ohm. This is close enough to 250 ohm that a 5x probe is easy, but a 10x probe is harder to get right.

After starting the software, set all offsets to 0.  Entering 50 for scale on channel 1 will randomly select 50 V/div or 50 mV/div.  I would expect it to be predictable and was surprised that 50V would be valid.  Seems easy enough to reproduce.
...
It's a real pain to hunt down your waveforms with manually setting the offset and scale.  Typing in the scales rather than the drop down selection do allow me to set it to what ever I want, but now its a bigger time waste entering all that data.   

Entering "50" will give 50V/div, and entering "50m" will give 50 mV/div. We'll change this back to a dropdown in the next update, with an option to change it to a textbox if you need arbitrary scales. This change was made primarily for compatibility with high-voltage probes.

I have had the software appear to hang.  Basically it was displaying wait, but appeared not to be updating the plots as nothing was being displayed on the graph for all 4 channels.  Nothing, meaning a blank screen.  I changed the scale to 500mV/div, and it remained blank.   Offsets all set to 0.   I increased the input voltage to 500mVp-p with no triggers.  10MHz.   All I did was exit the software and restart, everything was working as expected.  I have not been able to replicate this but I have seen the software hang like this before with an earlier revision.

That's odd - nothing, as in the axis labels were gone also? Or only the traces?
Shortly after v2.5.7 released, we noticed that de-embedding did not work at 128 pts/div (screen would blank), and re-uploaded a patched version. This may or may not be the issue.

It's the same with dragging the waveform to change the offset, the min/max doesn't track it. It's a constant close waveforms and recreate.    Or if I change the vert scale for channel 1, the scale for the min/max don't track it. 

Got it - next update, we will implement the min/max so that it tracks the offset/scale properly. (And waveform persistence as well.)
The current way (with math channels) gives more flexibility, but is non-standard.

Having that start of acquisition time moving all over based on the Base is a pain.  I am constantly dragging waveforms.   
...
I would like to see this thing have some sort of intelligent mode where is autoscales the vertical, locks the start of acquisition to the left[...]

To clarify: the software currently references the "timebase position" to the center of the screen. Changing the base (or zooming in with the scroll wheel) will zoom in keeping the center of the screen fixed. This lets you put the event of interest in the center of the screen, and zoom in.
It was implemented this way by customer request.
Are you proposing that changing the timebase scale should instead keep the left side of the screen fixed? Or the T=0 marker fixed? It's easy enough to make this an option.

Point being, software for these is IMO, is every bit as important as the hardware.   If it drives different than every product out there, it may not get a lot of acceptance.   Again, MO. 

We agree with this - your feedback so far has been immensely helpful. We want to be as responsive as possible to customer feedback, to push the software in the right direction.

[joeqsmith]

After starting the software, set all offsets to 0.  Entering 50 for scale on channel 1 will randomly select 50 V/div or 50 mV/div.  I would expect it to be predictable and was surprised that 50V would be valid.  Seems easy enough to reproduce.
...
It's a real pain to hunt down your waveforms with manually setting the offset and scale.  Typing in the scales rather than the drop down selection do allow me to set it to what ever I want, but now its a bigger time waste entering all that data.   

Entering "50" will give 50V/div, and entering "50m" will give 50 mV/div. We'll change this back to a dropdown in the next update, with an option to change it to a textbox if you need arbitrary scales. This change was made primarily for compatibility with high-voltage probes.

I guess I wasn't clear.  Entering "50" does not always give 50V/div.  It will sometimes give 50mV/div.   Try setting channel 1 using 50m.  You should see 50 mV/div.   Now set it to 50.  Does it stay at 50 mV/div or does it change to 50 V?   Try it a few times.  It's not repeatable every time.   Appears random.

I have had the software appear to hang.  Basically it was displaying wait, but appeared not to be updating the plots as nothing was being displayed on the graph for all 4 channels.  ...

That's odd - nothing, as in the axis labels were gone also? Or only the traces?
Shortly after v2.5.7 released, we noticed that de-embedding did not work at 128 pts/div (screen would blank), and re-uploaded a patched version. This may or may not be the issue.

Sorry I did not take a screen capture.  It was showing wait.  Signal input was more than enough to trigger device.   Trigger level set to 0.   It was like the internal trigger was not working and it wasn't able to detect a valid trigger.   Restart of the software cleared it. 

To clarify: the software currently references the "timebase position" to the center of the screen. Changing the base (or zooming in with the scroll wheel) will zoom in keeping the center of the screen fixed. This lets you put the event of interest in the center of the screen, and zoom in.
It was implemented this way by customer request.
Are you proposing that changing the timebase scale should instead keep the left side of the screen fixed? Or the T=0 marker fixed? It's easy enough to make this an option.

Exactly.  I want to lock the timebase position to the left, center or right.  Adjusting anything else in the timebase would not effect its location.   

I would also like to be able to set the acquisition length rather than the samples per division.   I want to start at T0, or 11ns, record for 2ns with a resolution of 1ps.  Today, it's not that flexible.   

Point being, software for these is IMO, is every bit as important as the hardware.   If it drives different than every product out there, it may not get a lot of acceptance.   Again, MO. 

We agree with this - your feedback so far has been immensely helpful. We want to be as responsive as possible to customer feedback, to push the software in the right direction.

I downloaded the PicoTech software for their scope and tried it out. 

Is the THD in your software calculated differently than the calibration certification?  If the settings are critical as far as replicating what you call out, you may want to define them.   

The THD in the calibration certificate is obtained via a time-domain regression, not an FFT. With only a few periods, the THD calculated from the FFT will depend on the windowing method used and the timebase range. The time-domain method is immune to these considerations (and gives statistical uncertainties on the extracted parameters).
We will mention this, as well as the exact timebase settings used, in the manual.

Is there a reason why you do not implement the same method in your software as what was used to derive the calibration cert?

[SJL-Instruments]

I guess I wasn't clear.  Entering "50" does not always give 50V/div.  It will sometimes give 50mV/div.   Try setting channel 1 using 50m.  You should see 50 mV/div.   Now set it to 50.  Does it stay at 50 mV/div or does it change to 50 V?   Try it a few times.  It's not repeatable every time.   Appears random.

Got it. Entering 50 will give 50 mV/div if the setting was previously in mV/div. Entering 50V will always give 50V/div. This was intentional, and we can change this behavior. In any case, we'll revert to the dropdown in the next update unless a custom scale is requested.

Sorry I did not take a screen capture.  It was showing wait.  Signal input was more than enough to trigger device.   Trigger level set to 0.   It was like the internal trigger was not working and it wasn't able to detect a valid trigger.   Restart of the software cleared it. 

Thanks - we thought we tracked down this issue, but evidently it can still happen. We'll run more careful tests to see if we can reproduce this.

Exactly.  I want to lock the timebase position to the left, center or right.  Adjusting anything else in the timebase would not effect its location.   

I would also like to be able to set the acquisition length rather than the samples per division.   I want to start at T0, or 11ns, record for 2ns with a resolution of 1ps.  Today, it's not that flexible.

Got it - we'll add these options (hopefully by next update).

Is there a reason why you do not implement the same method in your software as what was used to derive the calibration cert?

Mostly due to the nonlinear fit being computationally intensive - it will be significantly slower than real-time. The FFT implementation gives the same result to within ~1 dB.

[joeqsmith]

This was intentional,

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

Showing screen capture of PicoTech's 9400 software.  This is the first time I have ever looked at their software and it seems fairly intuitive.  Note the time base settings.  Trigger would need to take on a new meaning with your product.   I like their quick button press for most settings returns them to center.   

Most of the menus are easy enough to locate.  Like any new UI, it would take me time to get used to.       

I'm not liking that it crashed after a few clicks.... 

[SJL-Instruments]

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

We had it implemented as you stated, and changed it after receiving complaints that e.g. typing 50 into the offset box would set it to 50V instead of 50mV.
If we have a box for the step size in the timebase, for example, if a user typed 10 they likely meant 10 ps or 10 ns instead of 10 s.
But for the vertical division, as you stated, it makes less sense. We could make an exception for this setting, but then the consistency would be lost (which is the worst of both worlds, in our opinion).
We are erring on the side of keeping the current behavior, just because we've received more feedback in that direction.

Showing screen capture of PicoTech's 9400 software.  This is the first time I have ever looked at their software and it seems fairly intuitive.  Note the time base settings.  Trigger would need to take on a new meaning with your product.   I like their quick button press for most settings returns them to center.   

Thanks for this. We'll take this into account, and look around at other software as well, when implementing the extended settings for the timebase. A quick reset button for each setting is easy enough to add.

[joeqsmith]

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

We had it implemented as you stated, and changed it after receiving complaints that e.g. typing 50 into the offset box would set it to 50V instead of 50mV.

Interesting.  The idea of using the previously set value to determine how to interpret the entry isn't user intuitive IMO.  I can't believe someone would want it work this way. 

I'm sure as sales grow, you will receive lots of opinions and I wouldn't be surprised if some of those are not how things typically work.   If I get 20 people to suggest you should scan right to left with the earliest time always on the right side, will you do it?   Just remember it's your product.   

[joeqsmith]

Thinking about your UI and idea of dragging waveforms.  Set up a waveform to say 400mV.  Now set the scale to 10mV/div.  Now try and drag the waveform into view.  If you release the mouse and try to drag again, it resets back to the original offset.   You can only drag to -125mV.   You have to zoom out to get it back on the screen, take small adjustments and then you can set the offset to keep it on the screen all the way to 10mV/div.   

[SJL-Instruments]

Interesting.  The idea of using the previously set value to determine how to interpret the entry isn't user intuitive IMO.  I can't believe someone would want it work this way. 

I'm sure as sales grow, you will receive lots of opinions and I wouldn't be surprised if some of those are not how things typically work.   If I get 20 people to suggest you should scan right to left with the earliest time always on the right side, will you do it?   Just remember it's your product.   

We're currently rethinking this. Really, the complaints were from situations where a unit with no prefix doesn't make sense. (For example, setting the timebase position to "50" can only mean 50 ns, not 50 s.)
On the other hand, the vertical offset is debatable - requesting "200" probably means "200 mV", but if a high-voltage probe is used, it could mean "200 V".

Perhaps the best thing to do is implement things as you suggested, requiring an explicit prefix (so "200" would always mean "200 V"). The only exception would be for things like the timebase, where a 50s position is outside the capability of the hardware. This would make things as consistent as possible, and the software would only "correct" the user entry if it's completely unambiguous.

[joeqsmith]

I've received comments about people trying to use my VNA software where they enter for example 140m for frequency and can't understand that isn't 140MHz.  Failure of our education system isn't something I can address with my software.  I assume the user knows what they want.  I fully understand our friends reasoning  in the attached clip.

10MHz, voltage set just above where the scope will trigger.  Lots of back and forth to center the waveform at 10mV/div.  Now set it to 5mV/div.  Now change it back to 10mV/div.  What is the cause of it going unstable?   It's channel 2, so nothing to do with the trigger.   Easy to repeat.   

[nctnico]

Really?  Personally, I'm not a fan of software that tries to outguess me.  If it units are volts and I enter 50, it should give me 50, not m,u,n...  It should always do the same thing.  But that's just MO.   

We had it implemented as you stated, and changed it after receiving complaints that e.g. typing 50 into the offset box would set it to 50V instead of 50mV.

I agree with Joe here. Don't try to guess at typing errors. All test equipment I have uses values as they are typed in. If they are outside the range, you'll get an error. Otherwise the punched in value is used.

[SJL-Instruments]

Thanks nct and joe for the pointers. We'll change all input methods to the standard behavior in the next release (this weekend).

10MHz, voltage set just above where the scope will trigger.  Lots of back and forth to center the waveform at 10mV/div.  Now set it to 5mV/div.  Now change it back to 10mV/div.  What is the cause of it going unstable?   It's channel 2, so nothing to do with the trigger.   Easy to repeat.

We've tried to replicate this setup, but can't reproduce the behavior you're seeing (attached). It would be helpful to capture the raw CDF data when this occurs.
Just to be clear, you're putting a 10 MHz sine wave into CH1 & CH2? Or all channels?
As to why the vertical division has any effect at all: the displayed vertical region changes the CDF search bounds. This in principle shouldn't affect anything (just gives higher resolution), but gives a starting point if you want to investigate it over serial.

[joeqsmith]

If there truly is a problem with customers entering out of range values, you may want to consider coercing the entry to the boundary conditions.

The low cost VNAs keep evolving and I don't want to waste time changing the limits when a new model is released, so I don't coerce the settings.   I had a person trying to set their VNA outside of it's upper frequency limit.  Somehow they seemed to feel the software could magically turn a 4GHz VNA into a 10GHz VNA.  For something I give away for free, I refuse to work to the least common denominator.   You may not have a choice but to add some checks.   

***
Looking at the PicoTech software, they appear to set boundary conditions.

[joeqsmith]

Looks like the EEVBLOG site is having problems again.  I'll try and get back with you later on in the day.

***
I am using an RF generator to a DC splitter to ch1&2.  3&4 are turned off.  10MHz signal, 0V trigger, 100ps/div, 64pts/div, 500ns holdoff.  Start with around 200mVp-p level.   Center the waveforms at 10mV/div.  Set ch2 to 5mV/div.  Decrease signal level.   See attached.

[joeqsmith]

As to why the vertical division has any effect at all: the displayed vertical region changes the CDF search bounds. This in principle shouldn't affect anything (just gives higher resolution), but gives a starting point if you want to investigate it over serial.

Learned something new about the product.  Reading the manual:

The parameters s0…s7 represent the lower bound (“start voltage”) of the region to sample
for each channel, on a scale from –1.5 V (0) to +1.5 V (65535). This will be the lowest voltage
returned in the corresponding CDF data. The number of parameters required depends on
the model of the oscilloscope, and is equal to the number of channels (regardless of the
bitmask).
• Likewise, the parameters e0…e7 represent the upper bound (“end voltage”) of the region
to sample on each channel, and will be the highest voltage returned in the corresponding
CDF data.
• The parameters s0…s7 and e0…e7 are optional and will retain previously set values if omitted.
Modifying them can be useful for obtaining higher vertical resolution when the samples
per CDF K is low.
The search region (e0 - s0, e1 - s1, etc.) for any channel should not be smaller than 200 units
(∼9 mV). Undefined behavior will occur if this range is too small.

There is no mention at all of the boundaries having any effect on the trigger.  But it seems they do.  Adjusting these to a smaller value for channel 1 allows the scope to trigger on some very small signals.   

Showing channel 1&2 attached to the spillter.  -26dBm 2.4GHz signal applied and having no problem with the trigger. 

[SJL-Instruments]

Thinking about your UI and idea of dragging waveforms.  Set up a waveform to say 400mV.  Now set the scale to 10mV/div.  Now try and drag the waveform into view.  If you release the mouse and try to drag again, it resets back to the original offset.   You can only drag to -125mV.   You have to zoom out to get it back on the screen, take small adjustments and then you can set the offset to keep it on the screen all the way to 10mV/div.

Easy enough to allow the marker to be dragged down indefinitely once it hits the bottom of the screen. Will be implemented in next version.

If there truly is a problem with customers entering out of range values, you may want to consider coercing the entry to the boundary conditions.

Looking at the PicoTech software, they appear to set boundary conditions.

Thanks for the suggestion - this is already implemented in some places (e.g. the trigger holdoff), and we'll systematically go through each input and check when this makes sense.

I am using an RF generator to a DC splitter to ch1&2.  3&4 are turned off.  10MHz signal, 0V trigger, 100ps/div, 64pts/div, 500ns holdoff.  Start with around 200mVp-p level.   Center the waveforms at 10mV/div.  Set ch2 to 5mV/div.  Decrease signal level.   See attached.

Based on the CDFs you've sent, this might be metastability in the trigger circuit. It looks like the CDFs are a mixture between the correctly triggered samples, and samples taken at uncorrelated times throughout the waveform. This can occur if you're working on the very edge of the trigger sensitivity (below the recommended 200 mVpp). We'll look into a way to detect or mitigate this. (For now, we can mention this effect in the manual.)

There is no mention at all of the boundaries having any effect on the trigger.  But it seems they do.  Adjusting these to a smaller value for channel 1 allows the scope to trigger on some very small signals.   

Showing channel 1&2 attached to the spillter.  -26dBm 2.4GHz signal applied and having no problem with the trigger.

The exact way in which these interact, and the precise minimum signal level required for a trigger, is subject to process variation. The recommended 200 mVpp is a "safe" guideline. We can briefly mention some of these effects in the documentation (e.g. smaller range leading to increased trigger sensitivity), but can't give exact numbers applicable to every unit.

[joeqsmith]

Dang, -42dBm and it will trigger well enough to detect the 2.4GHz just above the noise floor.  I was thinking it would be a problem to trigger some basic logic levels.  Apparently this is not the case, at least with this particular scope.

You've been holding out on us!      

***
Now that I have had a small taste,  I want these settings exposed in your software!  Time to add a power user mode and let us push the hardware!   
***

The recommended 200 mVpp is a "safe" guideline.

  I don't want to play it safe!   

[SJL-Instruments]

Dang, -42dBm and it will trigger well enough to detect the 2.4GHz just above the noise floor.  I was thinking it would be a problem to trigger some basic logic levels.  Apparently this is not the case, at least with this particular scope.

You've been holding out on us!      

We generally try to keep all the specs conservative  . Since it's early in the lifecycle, with relatively low volume and low statistics, it's better to play it on the safe side, in case a 3 sigma event occurs (violating a min/max spec) and we get an angry customer.

Perhaps this is a bad idea from a marketing perspective. But much better to underpromise than overpromise.

Now that I have had a small taste,  I want these settings exposed in your software!  Time to add a power user mode and let us push the hardware!   
***

The recommended 200 mVpp is a "safe" guideline.

  I don't want to play it safe!   

Got it - we will add this mode. With all the necessary disclaimers, etc.
UI might be less polished than the "standard" mode at first. Always open to feedback on which options should be extended, preferred layout, etc.

[joeqsmith]

We generally try to keep all the specs conservative  . ...
Perhaps this is a bad idea from a marketing perspective. But much better to underpromise than overpromise.

The rise time on this particular scope puts it closer to 10 than 6G.  Trigger sensitivity below 10mV (assuming you provided access).  I would say your use of the the word "conservative" is an understatement!

[joeqsmith]

... this might be metastability in the trigger circuit.

Is it possible this could have been the cause of my locking up the sweeps?  If so, is there actually a way the restarting the software can somehow shake it loose?   I could believe when it hung both times, I was working with very low trigger levels.

[SJL-Instruments]

... this might be metastability in the trigger circuit.

Is it possible this could have been the cause of my locking up the sweeps?  If so, is there actually a way the restarting the software can somehow shake it loose?   I could believe when it hung both times, I was working with very low trigger levels.

Interesting possibility - we'll do some tests. If the scope is hung or unresponsive, there is a 10 second timeout after which the query is retried. Do you remember if the software hung for more than 10 seconds?

Now that I have had a small taste,  I want these settings exposed in your software!  Time to add a power user mode and let us push the hardware!   
***

The recommended 200 mVpp is a "safe" guideline.

  I don't want to play it safe!   

Along these lines, you can push the timebase down to 8 or 9 ns if you need it. There will be more distortion on Channel 1, but the other channels should be ok.

[joeqsmith]

Do you remember if the software hung for more than 10 seconds?

Sorry, I can't say with certainty.  If it ever locks like this again, I will take a screen shot and collect some other metrics for you.  It's rare and I have no idea how to replicate it.  I am certain that the last time I was bringing up the signals amplitude slowly at the time it hung.  I was waiting for it to change to Run and noticed nothing was being shown like I normally see with Wait.  I zoomed way out vertically and still did not see a trace.  Restarted the software and everything started working normally.   

Along these lines, you can push the timebase down to 8 or 9 ns if you need it. There will be more distortion on Channel 1, but the other channels should be ok.

I read this and I thought, surely he isn't suggesting that the start of collection can be set lower than 11, potentially leading to shorter length, lower loss....  A quick test and sure enough, channel 1 about 7.5ns!  If using the scope this way, I really don't care about channel 1 distortion anyway.  I just need the trigger to be stable.   

Add all the disclaimers you want to the manual.  IMO, specifying the minimums and  typical numbers is good enough.  But it's a shame to have the hardware crippled by software.    If you add support, the first thing I'm going to do is shave off 3ns of cable....     Still plenty of margin. 

[joeqsmith]

Shown with channel1 boundary set to +/-50mV,  7.5ns start of collection, 1ns sweep range, 1ps resolution.  Test signal at 7GHz. THD is around -22dB, down in the muck. 

I am curious on the cause of the DC shift?  The test signal is CW, so I expect something in your front end is doing some rectification that is somehow tied to the trigger.   Granted, I know I am pushing this thing to look at VERY small signals at much higher frequencies than you spec it to and pushing that start of collection way early.   

To be clear, by no means am I suggesting this is a problem.  I just want to understand what is going on internally.