Pocket-Sized 6 GHz 1 TS/s ET Scope

[SJL-Instruments]

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.   

Yep, this is why we spec the start time at 11 ns. 

The DC shift is not due to rectification and should be independent of the signal. We're actually reasonably sure it can be compensated for. The only reason we haven't is that we're not 100% sure it won't change with temperature, aging, etc.
Internally, the threshold voltage for the Channel 1 comparator must be rapidly switched from the trigger voltage to the CDF query voltage. The compensation network for this isn't perfect, and you're seeing the residual transient. You could avoid this problem this with two comparators and a resistive splitter, but that draws more power, increases the noise floor, and opens up matching issues.
This is also why decreasing the CDF search range improves the trigger sensitivity.
***
Perhaps a good middle ground for the software is to show data down to 8 ns by default, for all channels except CH1.

[joeqsmith]

Thanks for the added information on the DC.   

I wouldn't limit it in software, or if you do, set it to your absolute minimum (76486).  I would rather have it be documented that 11 is the recommended start of acquisition and that it may be possible to use lower values with reduced performance.  Let the user decide if it is useful to them or not but don't lock them out.

For a default power up, it doesn't matter to me as I will save the setup for my personal use.   It would be nice if it supported an initialization file where, if present, the software would automatically load these settings without the need to do it manually.   It would be no different than your other setup files, except for a unique name that your software looks for.

Shown with 7GHz 70mVp-p signal applied to Ch1.  Other channels have ground caps inserted.  Manual doesn't mention isolation.  Is this coupling from Ch1 to Ch2 normal? 

[SJL-Instruments]

I wouldn't limit it in software, or if you do, set it to your absolute minimum (76486).  I would rather have it be documented that 11 is the recommended start of acquisition and that it may be possible to use lower values with reduced performance.  Let the user decide if it is useful to them or not but don't lock them out.

We are not planning to set any limits if extended timebase settings and/or power-user mode are enabled. We trust the user to understand the limitations and consult the manual.
But in the default mode, we will still keep a limit at 11 ns (at least on CH1), to prevent confusion if CH1 appears distorted.
The exact minimum delay is unit-dependent and subject to process variation. 8 ns is at the 2 sigma level (~95% of units), and 8.5 ns is ~3 sigma.

For a default power up, it doesn't matter to me as I will save the setup for my personal use.   It would be nice if it supported an initialization file where, if present, the software would automatically load these settings without the need to do it manually.   It would be no different than your other setup files, except for a unique name that your software looks for.

Easy enough to implement (except on macOS, for reasons...). We'll add this to the Windows + Linux versions.

Shown with 7GHz 70mVp-p signal applied to Ch1.  Other channels have ground caps inserted.  Manual doesn't mention isolation.  Is this coupling from Ch1 to Ch2 normal? 

This coupling is normal and increases at higher frequencies. Later units also have a revised top case which improves the crosstalk.
Do note that the CH2 waveform you're seeing is below the "nominal" RMS noise floor. 

[joeqsmith]

When looking at the start of collection, what determines the minimum value before it reports an underflow? The manual states:

Error Response: WARNING: Delay underflow -inf  This error occurs when the requested value is outside the range of the delay generator and cannot be achieved.  If you are certain the requested delay falls within acceptable bounds, contact us for
a diagnosis.

Above it states:

Undefined behavior may occur if the requested delay is lower than 11 ns (D110000) or higher than the holdoff minus 25 ns. It is the user’s responsibility to stay within these bounds.

The term bounds must be referring to different boundary conditions as it does not appear to be constant for a fixed holdoff time.  Can you provide the equations?   7.7ns seems to work in all of my test cases so far. 

The document does mention the delay generator in 2.3 but doesn't mention how it ties into the underflow warning. 

Later units also have a revised top case which improves the crosstalk. Do note that the CH2 waveform you're seeing is below the "nominal" RMS noise floor. 

I dare say pretty much everything I have looked at over the last two days was outside of nominal.      

Showing 8.5GHz signal applied with varying amplitudes.  Start of collection was set to 7.7ns and a 1ps resolution.  Indeed channel 2 doesn't exhibit the same tailing as channel 1.   Based on this, I plan to remove 3ns worth of coax. 

***
I suggest as you make changes to the hardware, you consider sending a set of replacement parts for this unit anyone working on a review so they remain current.   For a while, I was thinking to have you ship a production unit that you bless as a gold standard to have as a reference.  I no longer feel that will be useful.   After all of my testing and our conversation, I'm now fairly confident that the electronics on this particular unit represent production. 

[joeqsmith]

Let it run overnight and saw no problems using the 7.7ns start of collection.  Showing both the time domain and distortion.   

Drift is dominated by open loop YIG, not the scope.

[SJL-Instruments]

When looking at the start of collection, what determines the minimum value before it reports an underflow? The manual states:

Error Response: WARNING: Delay underflow -inf  This error occurs when the requested value is outside the range of the delay generator and cannot be achieved.  If you are certain the requested delay falls within acceptable bounds, contact us for
a diagnosis.

Above it states:

Undefined behavior may occur if the requested delay is lower than 11 ns (D110000) or higher than the holdoff minus 25 ns. It is the user’s responsibility to stay within these bounds.

The term bounds must be referring to different boundary conditions as it does not appear to be constant for a fixed holdoff time.  Can you provide the equations?   7.7ns seems to work in all of my test cases so far. 

The document does mention the delay generator in 2.3 but doesn't mention how it ties into the underflow warning. 

The minimum delay is determined by the combined gate delays of all chips between the CH1 input and the sampling circuit. This is unit-dependent, and there isn't a useful way to calculate it. The easiest method is to simply try smaller delays until you receive an underflow warning (as you've done).

The maximum delay is determined by the 25 ns reset time of the sampling circuit. If less than 25 ns is allocated between the sampling time and the end of the trigger holdoff, the sampling circuit will be in an indeterminate state at the next trigger and yield incorrect results.

I suggest as you make changes to the hardware, you consider sending a set of replacement parts for this unit anyone working on a review so they remain current.   For a while, I was thinking to have you ship a production unit that you bless as a gold standard to have as a reference.  I no longer feel that will be useful.   After all of my testing and our conversation, I'm now fairly confident that the electronics on this particular unit represent production. 

We are also confident, given the last several posts, that your unit is within production spec.
We can certainly send you an updated case, if you'd like. (We did recently send a revised version to Shahriar.)

[joeqsmith]

The minimum delay is determined by the combined gate delays of all chips between the CH1 input and the sampling circuit. This is unit-dependent, and there isn't a useful way to calculate it. The easiest method is to simply try smaller delays until you receive an underflow warning (as you've done).

Could you explain the actual hardware/firmware mechanism in further details which sets this warning?  Block diagram of that area of the hardware design? 

For keeping the unit up to date, I would suggest anything that effects the performance of the scope, automatically send it.   I'm not concerned with the cosmetics.  If you do decide to start including probes, I suggest sending these out to reviewers as well.   


Besides decreasing the sampling resolution, is there a way to speed up the sweeps while reducing performance?  What limits the sweep rates? 

I have not yet measured it but it seems pulling all four channels vs one makes little difference.  Same with reducing the number of CDFs.  Would adding a mode where you tell the firmware/hardware to sweep a range and just have it stream the data back rather than requesting each delay, speed up the process?   I'm not thinking small changes in sweep times but 10X, 100X faster.   

If do decide to go after some sort of auto setup mode, it would be nice if it not only set the vertical and horizontal but also the trigger level.  I have not attempted to automate this myself.

***
I checked the Signal Path channel yesterday to see if he had his review up yet.   I keep postponing mine as you are making so many improvements in such a short time,  by the time I release a review, it would be obsolete.   I would have a different view if you were not using the feedback I am providing and working at such a rapid pace. 

[SJL-Instruments]

The minimum delay is determined by the combined gate delays of all chips between the CH1 input and the sampling circuit. This is unit-dependent, and there isn't a useful way to calculate it. The easiest method is to simply try smaller delays until you receive an underflow warning (as you've done).

Could you explain the actual hardware/firmware mechanism in further details which sets this warning?  Block diagram of that area of the hardware design?

 
Essentially, the entire delay generator is looped back on itself to form a ring oscillator, and we measure the period to verify the delay. If the calibration is still valid, this should be correct to within 1 ps. If it differs from the target by more than 2 ps, the warning is issued.
If the requested delay is too small, the delay generator will clamp to its minimum delay. This will be caught by the above check, but where this occurs is subject to process variation.

For keeping the unit up to date, I would suggest anything that effects the performance of the scope, automatically send it.   I'm not concerned with the cosmetics.  If you do decide to start including probes, I suggest sending these out to reviewers as well.   

We'll ship you an updated case by EOD tomorrow. Probes are quite far from production, but we'll keep you updated.

Besides decreasing the sampling resolution, is there a way to speed up the sweeps while reducing performance?  What limits the sweep rates? 

I have not yet measured it but it seems pulling all four channels vs one makes little difference.  Same with reducing the number of CDFs.  Would adding a mode where you tell the firmware/hardware to sweep a range and just have it stream the data back rather than requesting each delay, speed up the process?   I'm not thinking small changes in sweep times but 10X, 100X faster.   

If do decide to go after some sort of auto setup mode, it would be nice if it not only set the vertical and horizontal but also the trigger level.  I have not attempted to automate this myself.

First, there is the theoretical minimum time needed to take the CDF samples themselves. At 40 ns holdoff, with 20 samples/CDF and 100 triggers/sample (which would give degraded but still "acceptable" performance), this is 80 us per point, corresponding to 12 kCDF/s.

There is a fixed minimum overhead per sample due to FPGA/DAC communication, analog settling time, and MCU processing time. With some optimization, this can be brought down to probably ~10 us per sample, so ~200 us per point.

Then there is the time required to set a delay. Right now this takes ~8 ms, and gives a precision of ~0.1 ps @ 20 ns delay.
We can cut this down to ~50 us by skipping the verification step. This will substantially degrade the ENOB.

Combining the above, this limits the speed to ~3 kCDF/s.

Each CDF requires 60 bytes. Given the 921600 baud rate, this limits the speed to 1920 kCDF/s. Many of the CDF entries are strictly-speaking, redundant, and with pruning we can probably achieve 3 kCDF/s.
The current speed with default settings is ~50 CDF/s. This will take some time to develop, but a factor of ~100x is possible, with degraded noise and jitter performance.

I checked the Signal Path channel yesterday to see if he had his review up yet.   I keep postponing mine as you are making so many improvements in such a short time,  by the time I release a review, it would be obsolete.   I would have a different view if you were not using the feedback I am providing and working at such a rapid pace. 

We appreciate the amount of feedback you've provided, and the time you've put into testing the scope. Keep in mind that we won't stop improving the product for the foreseeable future - be careful not to postpone the review indefinitely. 

[joeqsmith]

Essentially, the entire delay generator is looped back on itself to form a ring oscillator, and we measure the period to verify the delay. If the calibration is still valid, this should be correct to within 1 ps. If it differs from the target by more than 2 ps, the warning is issued.  If the requested delay is too small, the delay generator will clamp to its minimum delay. This will be caught by the above check, but where this occurs is subject to process variation.

Thanks.   Makes sense why you need to constantly align it and why it changes a few counts.     

I'll check the isolation again once the new parts arrive and post any improvements.   Obviously I had the PCB out of the case to perform the rework.  The thermal pads appear to still be fine if you did not want to include them. 

We appreciate the amount of feedback you've provided, and the time you've put into testing the scope. Keep in mind that we won't stop improving the product for the foreseeable future - be careful not to postpone the review indefinitely. 

   Are you getting any feedback from Signal Path? 

[SJL-Instruments]

I'll check the isolation again once the new parts arrive and post any improvements.   Obviously I had the PCB out of the case to perform the rework.  The thermal pads appear to still be fine if you did not want to include them.

We have included new pads with the revised case. They are ~1 mm thick, and will compress significantly upon first assembly to obtain best thermal contact. Will be shipped out tomorrow.

   Are you getting any feedback from Signal Path? 

We can't comment on that, sorry. (Not sure whether Shahriar wants his schedule publicized.)

[joeqsmith]

   Are you getting any feedback from Signal Path? 

We can't comment on that, sorry. (Not sure whether Shahriar wants his schedule publicized.)

I wasn't referring to his schedule.   I want to know if he is finding other problems or offering suggestions outside of what had been mentioned here.... 

[SJL-Instruments]

I wasn't referring to his schedule.   I want to know if he is finding other problems or offering suggestions outside of what had been mentioned here.... 

Not yet - although if he does have suggestions or finds any problems, we will be similarly responsive in addressing them (and have mentioned this to him).

[joeqsmith]

Too bad.  It may prove helpful to hear from others who are trying it out. 

Using the GigaWave to look at the output from my frequency extender.   LiteVNA set to 10GHz.   250ps sweep time with 500fs resolution.   I have to say, the more I play around with it, the more surprised I am with just how well it works.   

[joeqsmith]

LiteVNA set to 11GHz, 100ps sample time with the start of collection at 7.7ns, ran overnight.  What is interesting about this plot is while the signal is all negative, the trigger is set to a positive value.   

Is there a sign problem or is it possible that voltage values calculated are not the same as what the trigger circuit sees?   

4.5.2 L (Set Trigger Level)
Command Format: Lx
Expected Response: OK Lx.
Available in all firmware revisions.
Sets the trigger level on a scale from –1.5 V (L0) to +1.5 V (L65535).

I limit it to +1 (54612) to -1 (11909).   Trigger level with this test was set to +3mV or 32833. 

[SJL-Instruments]

LiteVNA set to 11GHz, 100ps sample time with the start of collection at 7.7ns, ran overnight.  What is interesting about this plot is while the signal is all negative, the trigger is set to a positive value.   

Is there a sign problem or is it possible that voltage values calculated are not the same as what the trigger circuit sees?   

This is essentially the reverse of the DC transient on CH1 prior to the spec'd start time. When the trigger circuit is reset, there can be a residual offset of a few mV when switching from the CDF query voltage to the trigger voltage. (Anecdotally, this offset is always negative, but we again haven't characterized this thoroughly).
This is mainly important if you are pushing the frequency beyond spec, as the trigger sensitivity tends to drop with frequency.

[joeqsmith]

Thanks. This makes sense. 

You may want to consider creating a forum for your products that you could direct customers to from your website.  The groups.io reflector seems to be popular.   As sales grow, you may also want to start thinking about putting a FAQ together.

[joeqsmith]

The software I put together to test your scope is pretty barbaric.  Send a command, wait for a response.  Because your protocol is not consistent for all messages, I have unique handlers for the types.  It was just a brute force to try some things out and not meant as a solid platform to build on. 

If I were to write something for it, I wonder how your firmware handles say back to back commands?  How deep is your message queue? 
If you are in the middle of sending CDF data and I send you a command that could potentially change the collection, how do you handle it?  Do you wait for the current data to be sent to act on the new command? ignore the command until it is sent?   Just thinking how I would structure the software. 

I wonder if you came up with a better protocol, would you be able to change it this late in the game?   For example, if you always handled your send messages the same rather than append "SJLI" rather than a CRLF?  Adding a CRC or other error checking/correction....    For now, I don't think it's too big of a deal but down the road, it may be more difficult to change it.  Maybe you feel it is good enough to build on?

[SJL-Instruments]

You may want to consider creating a forum for your products that you could direct customers to from your website.  The groups.io reflector seems to be popular.   As sales grow, you may also want to start thinking about putting a FAQ together.

Thanks, these are both good ideas. We do plan on doing this once as our userbase expands. For the time being, we are following up with users individually (mostly via email), and they generally appreciate the one-on-one communication.
Our focus for now is user support and software development. We think our current communication model works well in these early stages, but the tradeoffs will change as sales increase. (A forum enables users to help each other and share knowledge, but this is most useful above some critical number of participants.)

The software I put together to test your scope is pretty barbaric.  Send a command, wait for a response.  Because your protocol is not consistent for all messages, I have unique handlers for the types.  It was just a brute force to try some things out and not meant as a solid platform to build on. 

If I were to write something for it, I wonder how your firmware handles say back to back commands?  How deep is your message queue? 
If you are in the middle of sending CDF data and I send you a command that could potentially change the collection, how do you handle it?  Do you wait for the current data to be sent to act on the new command? ignore the command until it is sent?   Just thinking how I would structure the software. 

I wonder if you came up with a better protocol, would you be able to change it this late in the game?   For example, if you always handled your send messages the same rather than append "SJLI" rather than a CRLF?  Adding a CRC or other error checking/correction....    For now, I don't think it's too big of a deal but down the road, it may be more difficult to change it.  Maybe you feel it is good enough to build on?

The current serial interface is designed to be simple to use as possible. We think the current specifications do give us enough leeway in the future. If we were to add CRCs, for example, we would have a command to enable them. We also have a command schema (anything starting with #) reserved for future use. We will never break backwards compatibility - that's just asking for trouble.

For terminators, we use CRLF everywhere we can, for ease of use from an interactive terminal. For binary responses, a CRLF is too likely to appear in the data. The SJLI "terminator" is less likely to appear. Of course, it may still happen (1 in 4 billion chance), so in our software we read based on the expected length of the message.
(As to why it's there at all: for some users, it might be acceptable to look for the SJLI and discard responses with the wrong length, which is much easier to implement.)

There is currently not a message queue, to minimize bugs and edge cases (e.g. changing the parameters during collection, as you've mentioned). If it becomes necessary, we can add one without breaking any existing user programs. Currently, the firmware ignores any command sent before the previous response is read. A message queue would process each command in order (so, still no issues with parameter changes during collection).

[joeqsmith]

Simple is fine as long as it is robust. 

I have completely restructured my test code which has turned up an odd behavior that I would like to understand.   

I send a CAL command and wait for the scope to respond with the OK CAL.  I then immediately send the Delay command.  What I am seeing is the scope will respond with a Delay underflow -inf.    I would assume that as soon as the scope sends the OK CAL, it is ready to take the next command but it doesn't appear that is always the case.  It never gives me this warning except when performed right after a CAL.  If I get this underflow and immediately resend the D command, it never fails that I have seen, on the second attempt.   

***
If after receiving the OK CAL, I wait an additional 50ms for the scope to do what ever it is doing, then send the D command, it never seems to throw the underflow warning.   It seems that OK doesn't really mean it's OK when it comes to the calibration.   

[joeqsmith]

In anticipation of the new power user mode,  I trimmed my delay line to center around the 8ns start of collection.  Time to remeasure it on the VNA.

[SJL-Instruments]

I send a CAL command and wait for the scope to respond with the OK CAL.  I then immediately send the Delay command.  What I am seeing is the scope will respond with a Delay underflow -inf.    I would assume that as soon as the scope sends the OK CAL, it is ready to take the next command but it doesn't appear that is always the case.  It never gives me this warning except when performed right after a CAL.  If I get this underflow and immediately resend the D command, it never fails that I have seen, on the second attempt.   

***
If after receiving the OK CAL, I wait an additional 50ms for the scope to do what ever it is doing, then send the D command, it never seems to throw the underflow warning.   It seems that OK doesn't really mean it's OK when it comes to the calibration.   

We can reproduce this, but only when operating outside of the specified timebase range.
The calibration is valid immediately after OK CAL is returned, and sending (for example) D110000 immediately afterwards should not result in a warning.
If the delay command you're sending is near the hardware limit, what you're seeing is likely a momentary increase in chip temperature which pushes the minimum possible delay above 7.7 ns.

[joeqsmith]

We can reproduce this, but only when operating outside of the specified timebase range.
The calibration is valid immediately after OK CAL is returned, and sending (for example) D110000 immediately afterwards should not result in a warning.
If the delay command you're sending is near the hardware limit, what you're seeing is likely a momentary increase in chip temperature which pushes the minimum possible delay above 7.7 ns.

Attached showing the returned warning and the target delay. 

The previous delay was 120000.  The software runs the cal, waits for the OK CAL, then sets it to 110000.  Adding a delay after the OK CAL seems to correct it. 

My old software was much slower.  As I said, just something quick and dirty to test the product.  I restructured the code to allow me to more easily expand it.  Part of that was speeding up the communications.  This is when the problem showed up.  I can throttle my software or resend the D command but everything else seems solid and I would like to understand if this is an underlying problem with the calibration.   

***
Maybe a clue but if I add 30ms delay after the calibration returns the OK CAL, the D110000 never seems to fail.  Using 20ms will cause an occasional fault.   Without any delay, it will frequently fault.   It only appears to be a problem when running the calibration.   

I let it run about 10 minutes with a 30ms delay and no warnings were sent from the scope. 

***
Looking at delayunderflow3.jpg, the last number is the number of ms from the time the D110000 command was sent and the scope returned the warning.   This time varies a lot and can be as low as 2ms.  Again, dealing with Windows but it at least doesn't appear that anything was wrong, like the scope was hung or something odd like that. 

[SJL-Instruments]

The previous delay was 120000.  The software runs the cal, waits for the OK CAL, then sets it to 110000.  Adding a delay after the OK CAL seems to correct it. 

My old software was much slower.  As I said, just something quick and dirty to test the product.  I restructured the code to allow me to more easily build from it.  Part of that is speeding up the communications.   This is when the problem showed up.    I can throttle my software or resend the D command but everything else seems solid and I would like to understand if this is an underlying problem with the calibration.   

***
Maybe a clue but if I add 30ms delay after the calibration returns the OK CAL, the D110000 never seems to fail.  Using 20ms will cause an occasional fault.   Without any delay, it will frequently fault.   It only appears to be a problem when running the calibration.   

This is quite odd, and so far we cannot reproduce this on any of our units. We can send D120000, CAL, D110000 in a loop with no extra wait time.

Checking the firmware, the "Delay underflow -inf" message is sent before the delay verification is performed. It occurs when the calibration result implies that the requested delay cannot be achieved even in theory. (i.e. it depends only on stored values from the CAL command) But, the calibration results are finalized before OK CAL is sent, and do not change afterwards, so the wait time between receiving OK CAL and sending the next D command should be irrelevant.

In short, the only explanation we can think of is a serial issue. The 30 ms wait time may have something to do with flushing a serial buffer. Just to verify, are you terminating all commands with \r only, and waiting to receive the full response (including CRLF) before sending the next message?

[joeqsmith]

My code uses state machine.  Send command, wait for a valid response.  I would like to send more than one command but you can't handle that so I don't. 

Yes, all commands are sent with a CR.  Actually, when I resend the D command, its just executing that same state a second time.  I only need this delay for the calibration, nothing else.

I wonder if your software just doesn't send the commands fast enough to replicate what I am seeing.   Certainly possible it is on my end as well.  No idea. 

[SJL-Instruments]

My code uses state machine.  Send command, wait for a valid response.  I would like to send more than one command but you can't handle that so I don't. 

Yes, all commands are sent with a CR.  Actually, when I resend the D command, its just executing that same state a second time.  I only need this delay for the calibration, nothing else.

I wonder if your software just doesn't send the commands fast enough to replicate what I am seeing.   Certainly possible it is on my end as well.  No idea. 

For this test, we wrote a short script using the Python serial library, sending and receiving commands as fast as possible. Here are some measured timings, if you'd like to compare:
1. Send CAL -> Received OK CAL: 61.5 ms
2. Send CAL, Received OK CAL, Send D110000, Received OK D: 65.9 ms

It's certainly possible that LabView handles serial in a subtly different way. But the "Delay underflow -inf" message leads us to believe that the scope is somehow receiving the wrong command. For example, D11000 (1.1 ns) will always trigger this warning.

***

Another possibility: The D command will return OK D even if the warning is issued. (i.e. two CRLF will be included in the response.) The state machine may be looking at a response from a previous command, depending on how it is implemented.