Pocket-Sized 6 GHz 1 TS/s ET Scope

[hpw]

IMHO, the crappy TXCO is here a limitation factor.

As no external connection for any better reference OXCO to connect. 

As 1Ts/s as 1ps sampling rate, IMHO any 1...5ps deviations will be hard to analyze. Or any live measurements Videos convince.

 my 2 cents

Hp

[SJL-Instruments]

1.1. Does it mean that the USB link is USB.2 ?

The USB communications are USB 2.0 FS (12 Mbaud) but the device requires USB 3.0 power levels (900 mA @ 5V). The actual power draw is around 650 mA @ 5V to allow for a factor of safety (e.g. running over a USB extension cord).
The USB 2.0 spec only allows 500 mA @ 5V, so the device requires a USB 3.0 port. (Many USB 2.0 ports can deliver more power than specified, but don't risk it.)

1.2. Did you test the performance of the device with different "power supply" :
for instance
=> the USB link
vs
=> a tweaked USB link that enable to get power from an external PS, for instance a "nice" linear PS (less noisy than the power coming from a hub / PC...)

We have seen no observable effect with different USB power supplies. Your standard laptop/desktop/tablet USB power is almost certainly fine.

2. Trigger frequency : internal vs external.
I guess this question is valid to any sampling scope... (?)
Is it better to rely on (your advice) =>
2.1. the hardware to find out the trigger frequency & stick to it (timebase + PLL ; given that both have their own jitter)
2.2. OR, using an external clock signal (that match the frequency to trigger) ; for instance, a DIY clock based on a "good" tcxo ? (as I don't deal with >100 different frequencies,    , it is cheap to buy a fixed-frequency oscillator from a vendor..., and quite easy to get a rather good stability)

Not quite sure what you mean here - there is no PLL in the hardware. The trigger is just an edge trigger, behaving the same as with any other scope.
If you're referring to eye diagrams in particular, you need to do clock data recovery (CDR) to obtain a clock signal that (to some extent) tracks the jitter of the data signal. If you want to do this 'properly,' you'll need to get into some weeds about e.g. choosing PLL bandwidth - lots of reading to do.
Trying to match the data frequency with an independent oscillator is likely to cause headaches. Using a simple edge trigger will force the jitter to "zero" (really, the trigger jitter) on one edge of the pseudo-eye-diagram, and so increase the jitter on the other edge. (It also "looks like" a 01 or 10 serial trigger - you need to look a few eyes down the line.) It can be useful to get a qualitative sense of your signal integrity, but shouldn't be used to quantitatively characterize your signal.

IMHO, the crappy TXCO is here a limitation factor.

As no external connection for any better reference OXCO to connect. 

As 1Ts/s as 1ps sampling rate, IMHO any 1...5ps deviations will be hard to analyze. Or any live measurements Videos convince.

 my 2 cents

Hp

A better reference wouldn't help for two reasons. The current typical timebase precision is 15 ppm, which is 1.5 ps at 100 ns. The effective jitter floor (Section 2.3 in manual) at 100 ns delay is ~8 ps RMS. What actually happens in practice is the 1.5 ps deviation "gets absorbed" into the measured effective jitter and increases the value of alpha (technically, only the portion of the phase noise integrated up to the sampling timescale, Section 2.2.2). So decreasing the reference phase noise at 10 kHz and up doesn't do much (since it adds in quadrature, it will still be ~8 ps RMS).

A larger issue is that the timebase is used to continuously calibrate the delay generator, which can only hold 15 ppm precision. In that light, the 2.5 ppm TCXO precision is plenty, and improving the phase noise below 10 kHz wouldn't help either. We think that beating this would require a completely different architecture (e.g. TDC random sampling), and drive up the price a lot.

[joeqsmith]

How do I save/recall  the settings?  Is there an option to have the program use the last settings? 

[SJL-Instruments]

How do I save/recall  the settings?  Is there an option to have the program use the last settings? 

The software currently doesn't support this. We'll add this to our queue as well - thanks for the suggestion.
This has been implemented as of v2.5.5 (released 2024-01-21).

[joeqsmith]

Your documentation mentions different firmware revisions.  How are you making these available and what tools are in place to upgrade the product in the field?  Or are you requiring that the product is returned to be upgraded?   

[SJL-Instruments]

Your documentation mentions different firmware revisions.  How are you making these available and what tools are in place to upgrade the product in the field?  Or are you requiring that the product is returned to be upgraded?   

We'll first note that the reason we don't have this procedure currently documented is that it is not an issue yet. All devices are on the latest firmware revision except for one review unit which will eventually be sent back.

In the future, our plan is to allow the user to either (a) request the firmware file from us and flash it themselves, or (b) return it for upgrade. If the user does not have the necessary hardware, we will send a kit for free upon request. We will document the upgrade procedure and hardware shortly before the next firmware version is released.

The request for the firmware is technically necessary, as the firmware file is device-specific. This has to do with how we achieve the specified 1 ps delay precision.

Let us know your thoughts. This procedure isn't set in stone yet.

[joeqsmith]

From your post, I get the feeling the case must be opened to use this hardware you mention.

I would have thought any calibration data would be stored into an isolated area.  If it is not, that you would have tools to merge it with the firmware. 

Are you considering the FPGA part of the firmware?   Or is everything done in the FPGA?   If so, is that the tools you are referring to?

[SJL-Instruments]

From your post, I get the feeling the case must be opened to use this hardware you mention.

I would have thought any calibration data would be stored into an isolated area.  If it is not, that you would have tools to merge it with the firmware. 

Are you considering the FPGA part of the firmware?   Or is everything done in the FPGA?   If so, is that the tools you are referring to?

Yes, the case must be opened, and we provide the tool to do so with all orders.

There is an FPGA and an STM32 MCU that can both be flashed over the Tag-Connect debug header. The hardware would likely consist of the appropriate Tag-Connect cable and ST-Link. The device-specific portion is only partially calibration data - creating the unique part of the firmware essentially requires compiling from source.

We do not anticipate needing to upgrade the FPGA firmware, but a similar policy would apply. The FPGA firmware is not device-specific, and we will have the bitstream downloadable directly from our website if an update is needed.

[joeqsmith]

Reading your manual and thinking to write some simple software to try it out.   I'm curious with the calibration, you talk about when the device has reached steady state that the need for calibration every second reduces.   With that in mind, do you have a way to monitor the Xilinx or other parts for temperature?   The manual does not mention this and I don't see it in your software.

The commands seem fairly easy to follow, until I get to the Acquire CDF (R) command.    I assume the software pulls the data for what ever channels are selected and increments the delay, runs a cal, pulls the next data, repeating the cycle for however much data we want.   

The binary data consists of d chunks of 3Nch bytes each, where Nch is the number of channels requested via the bitmask. Each chunk contains Nch three-byte entries, each representing a single CDF value F(V ;Δt) for each requested channel.

No problem...

The first two bytes of each entry represent the voltage V on a scale from –1.5 V (0x0000) to +1.5 V (0xFFFF) in big-endian format.

No problem...

The third byte represents the value of F(V ;Δt) multiplied by 255.

I'm lost. 2.2.1 doesn't explain things in simple enough terms with enough detail for me to follow along with my limited math skills.  An example in plain text would be helpful.   

Or, do I need to find a stats book and start reading? 

[SJL-Instruments]

Reading your manual and thinking to write some simple software to try it out.   I'm curious with the calibration, you talk about when the device has reached steady state that the need for calibration every second reduces.   With that in mind, do you have a way to monitor the Xilinx or other parts for temperature?   The manual does not mention this and I don't see it in your software.

When using the serial interface, we only guarantee proper operation when calibrating once per second or faster (i.e a 6% duty cycle of calibration, 60 ms every second).
We do not recommend decreasing the calibration frequency even in thermal steady-state.
The comment about steady-state in the manual is rough guidance for those who want/need to push this frequency down - we then no longer guarantee 1 ps timing accuracy, and it's up to you to check if the resulting accuracy is sufficient for your application.
There are not thermometers to measure individual chips. From our testing, no arrangement of thermometers was anywhere near as accurate as "using the delay chip itself" as a thermometer - this is what we do in practice.

For the next manual revision, we have modified this section as follows:

The 1 ps timing precision of the GigaWave is guaranteed only up to one second after this com-
mand is issued. We therefore recommend issuing this command at least once per second. If
data acquisition (R) takes more than one second, the CAL command must be issued immediately
before the corresponding delay (D) and data acqusition (R) commands.
If the device is in thermal steady-state (∼5 minutes after warmup), the 1 ps precision can often
be maintained for up to 30 seconds without recalibration. If calibrating at a reduced frequency,
the 1 ps specified accuracy is not guaranteed, and it is the user’s responsibility to verify that the
timing precision meets the application requirements.

The commands seem fairly easy to follow, until I get to the Acquire CDF (R) command.    I assume the software pulls the data for what ever channels are selected and increments the delay, runs a cal, pulls the next data, repeating the cycle for however much data we want.   

The R command only takes data and does not perform a cal or increment the delay. For example, in normal operation the official software more-or-less issues the sequence:
CAL D R D R D R ... D R CAL D R D R D R ... D R ... (you get the picture)
This gives you lots of flexibility on which delays you want to take data at.

The third byte represents the value of F(V ;Δt) multiplied by 255.

I'm lost. 2.2.1 doesn't explain things in simple enough terms with enough detail for me to follow along with my limited math skills.  An example in plain text would be helpful.

Or, do I need to find a stats book and start reading? 

The cumulative distribution function (CDF), denoted F(V; Δt), gives the probability that the signal at the post-trigger delay Δt is less than V.
If you're trying to measure a sine wave, for example, you'd expect F(V; Δt) at any fixed Δt to be equal to zero for V < V0 and equal to one for V > V0, where V0 is the actual voltage of the sine wave at Δt. In other words, a step function at V0.

For single-valued signals (e.g. a simple periodic waveform), you can more-or-less average the two neighboring voltages where F(V; Δt) first goes from <0.5 to >0.5 to find the location of the step (V0). (The software does something fancier, fitting a Gaussian error function.)

For more intricate stuff (e.g. eye diagrams), you would need to take the derivative with respect to V to obtain the probability density function. In practice, you'd implement this as a finite difference (F2-F1)/(V2-V1).

We've added this explanation as well as an example program to the next manual revision (see attached).

Hope that cleared things up a bit - let us know if not.

[joeqsmith]

I tell people that when I wrote that software for the VNAs, the time spent actually writing/maintaining the software is very little when compared to researching all the math behind it.   And while there are many good papers on-line, published by the leaders of the industry, they are not perfect and so you run into bugs, compounding the problem.   

Your example code does the easy part.  Collecting all the chunks.  It's what you do with these chunks that I would have liked to see a simple walk through.  If your example code were to set the Q (samples per CDF) to 30, we get 30 chunks for each sample interval consisting of 30 voltages and 30 F(V ;Δt) multiplied by 255.    In your example of 5ns @ 100ps resolution, you end up with 50 of these sets of chunks.  Now we do something with this mess to get it back to a meaningful signal.   That IMO, it the part that would be good to include. 

No doubt, the stats book is one option.  Like the VNA, certainly possible to do that research.  I'm looking for a shortcut.  If there is one trait I have, it's being lazy. 

[SJL-Instruments]

We've attached an explicit example of how to process each chunk.
We describe simplest method that gets you a viewable waveform - it should be a good first "test" if you're writing custom software.

This will be added to the upcoming revision of the manual. Let us know if this explanation is clear.

[joeqsmith]

Big thanks.  I took decided to go ahead and attempt to talk with it.  How hard can it be? 

I have not divided the CDF values by 255 yet.  The waveform is not using the 0.5 CDF but rather just the average of the three center values.   I'll go ahead and add that along with time axis.   Doesn't seem to bad to code up.   

For single-valued signals (e.g. a simple periodic waveform), you can more-or-less average the two neighboring voltages where F(V; Δt) first goes from <0.5 to >0.5 to find the location of the step (V0). (The software does something fancier, fitting a Gaussian error function.)

Do you always use a Gaussian fit to get the centroid?

[SJL-Instruments]

Nice work with the custom software! 

Do you always use a Gaussian fit to get the centroid?

A bit complicated, but details if you're interested: to a first approximation, you can use the interpolation procedure we described in the last post. This usually gets you close, but the noise performance is poor since you're only using two samples.
Fitting a Gaussian error function is theoretically the best thing to do (in the sense of Fisher information), but in practice is overly sensitive to outliers on the wings. What we've found works well in practice is to fit a line to the inverse Gaussian CDF applied to the data, but truncated within a certain region (say 10-90%) of the CDF, with the truncation also seeded by the interpolation method. (This is also faster on the CPU.) You need to weight samples with some care to maintain equal sensitivity to all values (which minimizes the total propagated noise, and improves outlier robustness).

This gives a significantly lower noise floor than the interpolation method alone, but is still robust to spurious errors.

[joeqsmith]

I didn't want you to feel that your posts and updates to the manual were a wasted effort.   It was an evenings work to see that GHz sinewave.  Says a lot about your choice of a protocol. 

The remaining parts for the delay line arrived today.  I plan to assemble it over the weekend, so no rush on the s-parameter support.   

[Kean]

I have no need for such a scope, but it is certainly interesting to read about it and see the great interaction here.  As usual, Joe dives right in.

In the above example of processing the chunks of data titled "4.3.2 Example", the commentary mentions 0.476 mV - but I am pretty sure that is meant to be 0.476 V or 476 mV?

[SJL-Instruments]

In the above example of processing the chunks of data titled "4.3.2 Example", the commentary mentions 0.476 mV - but I am pretty sure that is meant to be 0.476 V or 476 mV?

You're right, keen eye! Thanks for catching that.

[joeqsmith]

I suspect there is still some critical component I am missing.  If I power up the GigaWave and attempt to control it with my software, it appears like it does not run.  All the commands seem to return a valid response and the it sends back data but there its a flat line.  Almost like it is not running.   If I run your software first, then I can run my software and everything works.  I can disconnect, restart and it works just fine.  It acts like there is a command you are sending that I am not that sets the data collection into motion.  Or, perhaps there is an order to commands that are sent to kick it off.

***
I'm sure all these problems are on my side of things.  Not being a programmer by any stretch of the word...

Another thing I noticed as I increase the resolution of the delay something happens with the DSO and it starts to complain about no triggers.   If I increase the trigger holdoff time, it appears to correct it.  I have been testing with a 1GHz source, and I need to push this this number out to 1us for example to use a resolution of 20ps, for example.  The first several reads are always correct.  How soon it fails depends on the combination of the holdoff and resolution  (how much I increment the post trigger delay by. 

[SJL-Instruments]

I suspect there is still some critical component I am missing.  If I power up the GigaWave and attempt to control it with my software, it appears like it does not run.  All the commands seem to return a valid response and the it sends back data but there its a flat line.  Almost like it is not running.   If I run your software first, then I can run my software and everything works.  I can disconnect, restart and it works just fine.  It acts like there is a command you are sending that I am not that sets the data collection into motion.  Or, perhaps there is an order to commands that are sent to kick it off.

Thanks, we are able to reproduce this problem. This is due to some parameters in the R command that we forgot to document (and are only needed once). 

Updated documentation is attached, and will be added to the next revision of the manual. We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

We have now tested the example program with a just-plugged-in scope and were able to see a 1 GHz sine wave. Let us know if you still run into issues.


***

Another thing I noticed as I increase the resolution of the delay something happens with the DSO and it starts to complain about no triggers.   If I increase the trigger holdoff time, it appears to correct it.  I have been testing with a 1GHz source, and I need to push this this number out to 1us for example to use a resolution of 20ps, for example.  The first several reads are always correct.  How soon it fails depends on the combination of the holdoff and resolution  (how much I increment the post trigger delay by. 

Unfortunately, we can't reproduce this problem - modifying the example program to take 101 samples between 15 ns and 15.1 ns (i.e. 1 ps resolution) works as intended with a just-plugged-in scope. Could you report if the read failure is persistent (i.e. if you retry the command a few times, does it fail every time after the first)?

[Kean]

Updated documentation is attached, and will be added to the next revision of the manual. We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

Rather than s8 & e8, should those be s0...s7 and e0...e7? (for an 8 channel model).

Also having "Rx s0 s1 s2 s3 e0 e1 e2 e3" as the example command format was confusing to me, as that assumes a 4 or 8 channel model with a specific bitmask with 4 enabled channels.
Maybe "Rx s0 ... e0 ..."?

Or I may have misunderstood the syntax completely.

[SJL-Instruments]

Updated documentation is attached, and will be added to the next revision of the manual. We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

Rather than s8 & e8, should those be s0...s7 and e0...e7? (for an 8 channel model).

Also having "Rx s0 s1 s2 s3 e0 e1 e2 e3" as the example command format was confusing to me, as that assumes a 4 or 8 channel model with a specific bitmask with 4 enabled channels.
Maybe "Rx s0 ... e0 ..."?

Or I may have misunderstood the syntax completely.

Thanks again - that should indeed be s7 and e7. The number of parameters does not depend on the bitmask, only the model.
We've explicitly written out the format now (see attached) - hopefully that eliminates any confusion.

[joeqsmith]

I was confused by the R1 10000 10000 50000 50000 command.  It appears to me that you are telling it you only have one channel enabled but are setting the limits for two channels.   

Does the number of channels selected have no purpose in this context?  Are you in this example showing that you have a 2-channel scope and are just setting the limits for both as a one time setup (assuming they do not change) and later requesting the number of channels (1 and/or 2) to read?

Unfortunately, we can't reproduce this problem - modifying the example program to take 101 samples between 15 ns and 15.1 ns (i.e. 1 ps resolution) works as intended with a just-plugged-in scope. Could you report if the read failure is persistent (i.e. if you retry the command a few times, does it fail every time after the first)?

Once it failed, it continues to fail every time.  Is there a reason I couldn't request any number of samples I want?  If I keep the delays and resolution the same where it would fail, I can reduce the number of requested samples and it ran fine.  I was assuming there was no limit to how many requests I make.   I thought it may have something to do with my asynchronous calibration command, so I disabled that and it has no effect.  It's almost like I am causing some overflow condition by asking for too much data.   I tried to throttle how fast I send these requests but I currently wait for the end of the frame before changing states.

We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

To be clear, we take the (1 - (third number from each chunk divided by 255)) to get the 0-1 you show in your example?  You are not wanting to add 1 to the third number divided by 255.   Examples are good.     

When you perform your Gaussian fit, you truncated the CDF within 10-90%) then  mirror the CDF, then fit to that shape?  I assume you are not fitting to the CDF's S shape directly.

[SJL-Instruments]

I was confused by the R1 10000 10000 50000 50000 command.  It appears to me that you are telling it you only have one channel enabled but are setting the limits for two channels.   

Does the number of channels selected have no purpose in this context?  Are you in this example showing that you have a 2-channel scope and are just setting the limits for both as a one time setup (assuming they do not change) and later requesting the number of channels (1 and/or 2) to read?

Internally, the scope takes data on all channels in parallel, and the requested ranges change what physically happens in the hardware. The bitmask only chooses which data to include or omit in the serial response.
We chose this interface so that you can issue one range command at the start for all channels, and later issue only short commands depending on which channels you want selected.

Unfortunately, we can't reproduce this problem - modifying the example program to take 101 samples between 15 ns and 15.1 ns (i.e. 1 ps resolution) works as intended with a just-plugged-in scope. Could you report if the read failure is persistent (i.e. if you retry the command a few times, does it fail every time after the first)?

Once it failed, it continues to fail every time.  Is there a reason I couldn't request any number of samples I want?  If I keep the delays and resolution the same where it would fail, I can reduce the number of requested samples and it ran fine.  I was assuming there was no limit to how many requests I make.   I thought it may have something to do with my asynchronous calibration command, so I disabled that and it has no effect.  It's almost like I am causing some overflow condition by asking for too much data.   I tried to throttle how fast I send these requests but I currently wait for the end of the frame before changing states.

There is no limit on the number of samples you can take. (In fact, there should be nothing "stateful" in the firmware, and issuing the R command repeatedly should result in identical behavior.)
Does the point of failure always occur at the same number of samples? If so, then this may be caused by the serial buffer filling up. When implementing the example program, we issue a read immediately after sending each command to clear all serial buffers. We can take an arbitrary number of samples without issue.
The timing shouldn't be critical, and no throttling is done in our official software.

We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).

To be clear, we take the (1 - (third number from each chunk divided by 255)) to get the 0-1 you show in your example?  You are not wanting to add 1 to the third number divided by 255.   Examples are good.     

Yes, this is correct. We'll add this calculation to the example analysis.

When you perform your Gaussian fit, you truncated the CDF within 10-90%) then  mirror the CDF, then fit to that shape?  I assume you are not fitting to the CDF's S shape directly.

We don't mirror the CDF, but instead apply the inverse CDF to the data, such that a perfect Gaussian error CDF would become a straight line. When you do this, the points on the edges will have their noise significantly amplified, and you need to weight them by 1 over the squared derivative of the inverse CDF to avoid blowing up the fit. The points are truncated to the 10-90% CDF region, as well as dropping any points that are more than 2 standard deviations from the central value determined via the interpolation method.

[joeqsmith]

There is no limit on the number of samples you can take. (In fact, there should be nothing "stateful" in the firmware, and issuing the R command repeatedly should result in identical behavior.)
Does the point of failure always occur at the same number of samples? If so, then this may be caused by the serial buffer filling up. When implementing the example program, we issue a read immediately after sending each command to clear all serial buffers. We can take an arbitrary number of samples without issue.
The timing shouldn't be critical, and no throttling is done in our official software.

Ok, I will need to dig into it.  I am waiting for the GigaWave to acknowledge each request before sending another.  I never clear out the PC's serial buffers and assume you can take the data as fast as I send requests.   I would think that waiting for the ack would throttle it.    I'll get back with you on it. 

***
It repeats at the same location which is dependent on the Trigger Holdoff.   GigaWave will start to send "NO TRIG ZERO SJLI" or "NO TRIG TIMEOUT n SJLI".   With Trigger Holdoff set to 50, it will start kicking out these messages very soon.  Set it to 500, and it will run for a long time.   I don't see why this would cause any problems with a GHz waveform.  Both values are certainly longer than the 1ns period.   

I am sending the R command separate without setting up the trigger and see the error as expected but it seems fine and will start the collection.  So, this was the reason it would not initially start without running your program first. 

***
Moving the R level setting into the first Read command as your example shows has no effect.  It still behaves the same.  I'm sure I am missing something obvious.

[SJL-Instruments]

It repeats at the same location which is dependent on the Trigger Holdoff.   GigaWave will start to send "NO TRIG ZERO SJLI" or "NO TRIG TIMEOUT n SJLI".   With Trigger Holdoff set to 50, it will start kicking out these messages very soon.  Set it to 500, and it will run for a long time.   I don't see why this would cause any problems with a GHz waveform.  Both values are certainly longer than the 1ns period.   

Can you specify exactly which delays you are trying to take data at, and the delay/number of commands at which you start seeing an error (for e.g. a trigger holdoff of 50 ns and at 500 ns)? This will help us when trying to reproduce your error.

If you are able to, it would be helpful to provide a text file listing of all the serial commands you're sending in order.

Moving the R level setting into the first Read command as your example shows has no effect.  It still behaves the same.  I'm sure I am missing something obvious.

To clarify what you mean by "behaves the same:" are you referring to the need to start our software first, or that you are seeing errors past some number of samples? If the former, then the extra parameters to the R command should have resolved the issue. If the latter, then the level settings are likely not related to the root cause.