Pocket-Sized 6 GHz 1 TS/s ET Scope

[SJL-Instruments]

It would be nice to have some of the features mentioned for the review as I would rather avoid having to use my software.   At the same time, I understand that completing that list of features is going to take some time.

Yep, we're aiming to have the most useful features implemented by Saturday.

Yes, DC linearity.   There was a reason I asked about this undocumented X1 command...

From that, I assume it is linear up to where it starts to clip.   Any idea what the recovery time is?  Can I drive the input into saturation without damaging it? 

DC linearity is 0.1%, although we don't characterize this on a per-unit basis.
There is no recovery time as the signal does not clip. This is inherent to our choice of architecture. You can apply any signal within the absolute maximum range (±1.2V) indefinitely.
(The official software soft-clips the signal to 1.1V, but this isn't a hardware limit.)

[joeqsmith]

I think you are stating that as long as the signal remains within some defined limits, the front end will not saturate, clip or compress.  I guess you could say that about any circuit.   That is not what I am asking.   Early on you mention driving it with 5V.  Far outside the specified limit.  What happens under this condition?

[SJL-Instruments]

I think you are stating that as long as the signal remains within some defined limits, the front end will not saturate, clip or compress.  I guess you could say that about any circuit.   That is not what I am asking.   Early on you mention driving it with 5V.  Far outside the specified limit.  What happens under this condition?

We haven't characterized this in detail, as it's outside the absolute maximum operating conditions.
We still expect zero recovery time and no compression, as there is no amplifier to saturate.
If the signal exceeds 1.5V, you will not be able to measure it, since the CDF query voltage ranges only from -1.5V to 1.5V.

The accuracy within the operating band (±950 mV) will likely remain unaffected even if the signal itself goes up to ±2V. Beyond that, the frontend chip may eventually experience thermal failure, and the input will fail open (high-impedance). You can probably get away with larger spikes if they are infrequent.

Any damage to the frontend is covered by warranty.

[joeqsmith]

Can you provide a sketch of the front end?

[SJL-Instruments]

Can you provide a sketch of the front end?

The frontend consists of a latched comparator with the signal sent into one input and the other input held at the CDF query voltage.
If you're asking about the saturation recovery time of the comparator (which contains a limiting amplifier), it's independent of the overdrive voltage and equal to the 40 ps rise/fall time of the scope.
(It's in this sense that there's zero recovery time - it doesn't depend on what signal you put in.)

[joeqsmith]

If the signal exceeds 1.5V, you will not be able to measure it, since the CDF query voltage ranges only from -1.5V to 1.5V.

(The official software soft-clips the signal to 1.1V, but this isn't a hardware limit.)

When you applied your 5V signal, I assumed you did not have the software limit.  What does the GigaWave read?  1.5V? I assume with X1, you can force the trigger and would think it would limit at the +/-1.5V. 

Any damage to the frontend is covered by warranty.

If it were a handheld DMM that should be somewhat robust,  you should have some concern.  If I damage your scope with my testing, it will not be intentional.  With all the high voltages I play with, I have never damaged any of my equipment.  I did loose a good amplifier last year when working with those microwave horns without a wrist strap.  Who would have guessed....    

***
Attached showing the data from last night after updating the fitter.   

[SJL-Instruments]

The reading would depend on how you processed the data - all of the returned CDF values would be zero, indicating that the signal exceeds the requested upper bound. The official software would clip it to 1.1V.

What’s your setup for the overnight data? Internal trigger with all inputs shorted?

[joeqsmith]

What’s your setup for the overnight data? Internal trigger with all inputs shorted?

Marconi 2024 (1GHz) to Wilkinson to GigaWave to PC to LabView

See PE2012
https://www.pasternack.com/sma-4-way-50-ohm-rf-power-dividers-category.aspx

External trigger. 

[SJL-Instruments]

Marconi 2024 (1GHz) to Wilkinson to GigaWave to PC to LabView

See PE2012
https://www.pasternack.com/sma-4-way-50-ohm-rf-power-dividers-category.aspx

External trigger. 

Got it - so in #205, you're plotting with the mean waveform subtracted?
Since the small spikes you're seeing are on CH2 and CH3 only, this rules out a timing problem.
We've been unable to reproduce the small spikes so far using the same signals.

It's odd that they only occur on CH2 and CH3. You can try running with a falling-edge trigger to see if the spikes then appear on CH1.
Internally, CH4 has a different polarity from CH2/CH3 and is inverted in firmware. A falling-edge trigger will invert CH1 internally.

[joeqsmith]

I wasn't too concerned by this bit of noise. 

Got it - so in #205, you're plotting with the mean waveform subtracted?

That data represented about an hour.  I took the mean for each individual channel for that entire 1 hour data set.  I then subtract each mean from their respective channel.

Since the small spikes you're seeing are on CH2 and CH3 only, this rules out a timing problem.
We've been unable to reproduce the small spikes so far using the same signals.

It's odd that they only occur on CH2 and CH3. You can try running with a falling-edge trigger to see if the spikes then appear on CH1.

The previous data was taken using the falling edge but I can repeat the test with the rising edge if you like.  I'm not big on changing multiple variables at once but I'll double the input voltage as well.  Manual states edge amplitude is 200mVp-p min and my test signal was about 250mVp-p.   Still you don't think it is timing.  Also, the scope was off all day as well and the office is much cooler.       

Internally, CH4 has a different polarity from CH2/CH3 and is inverted in firmware. A falling-edge trigger will invert CH1 internally.

Sharing a bit of insider information....

[joeqsmith]

I ran a few tests to try and help answer what is going on with noise.   

For starts, rotate the original date where we are looking at the sweep time rather than the number of sweeps.  Again, subtracting off the mean as previously described.   Note how channels 2,3&4 show the disturbance around 11.75ns.   

[joeqsmith]

As I mentioned, I repeated the test doubling the input voltage and using the rising edge trigger.  Showing about 2.5 hours of data.  The p-p noise is greatly improved.

[joeqsmith]

To try and narrow down why we are seeing this improvement, the input signal was returned to the same level that was used during the original test but the trigger remained set to the rising edge.   Here we are looking at about 5 hours of data. 

[joeqsmith]

So, is it the trigger edge?  Time to repeat the original test using the same signal levels and falling edge.   I let it run about a half hour longer than the original test.   

[joeqsmith]

I'm at a loss of what to suggest.   Same cables, generator, scope, splitter, PC, USB port, software...  Scope and splitter resting on a ground plane next to my VNA.   The setup wasn't taken apart between tests.   I wasn't playing with my spark gap transmitter, ignition systems or anything else I would expect would cause a disturbance. 

The only thing that has really changed is or course, its a different day and the office temperature was lower.  As you know, I had tried to look at the stability with temperature but at that time we did not have the new FPGA/firmware.  I plan to repeat these tests once your software has evolved.  Maybe that has something to do with it. 

Let me know if you have any ideas. 

***
If the setup is not clear, see attached sketch.

[SJL-Instruments]

Thanks for the detailed experiments. The noise level in the last three results are consistent with our test units. We have run a few temperature tests after the firmware update and saw nothing unusual, but it will be interesting to see your results.

Your results from #210 again rule out any timing issue (since CH1 is clean), and anything to do with the internal inversion (since CH4 behaves similarly to CH2, CH3).

I plan to repeat these tests once your software has evolved.  Maybe that has something to do with it. 

We think the software is an unlikely culprit - all channels are processed in the same way at all delays.

[joeqsmith]

Thanks for the detailed experiments. The noise level in the last three results are consistent with our test units

No problem. Wish things would have repeated.  You can see from the first and last data sets how channel 1&4 matched up very close to the original data.   

Your results from #210 again rule out any timing issue (since CH1 is clean), and anything to do with the internal inversion (since CH4 behaves similarly to CH2, CH3).

Signal generator is common across all 4 channels.  Doubt the 4 cables or splitter is bad. 

We think the software is an unlikely culprit - all channels are processed in the same way at all delays.

Can you think of anything with the hardware that could cause this?  I'm not referring to the FPGA but the physical hardware like soldering, artwork, contamination.     

[SJL-Instruments]

Can you think of anything with the hardware that could cause this?  I'm not referring to the FPGA but the physical hardware like soldering, artwork, contamination.     

Nothing special happens in the hardware at 11.8 ns - a physical issue might cause a problem, but it's odd that the increased noise would only show up at one delay.

Your unit was from our first small-run batch (earmarked for test/review only). Since we improve our process and QA with each run, the first batch is also the most likely to have physical issues. We've sent you an email with more specifics on which chips/etc might cause a problem. But any physical issue we can think of would cause random spikes everywhere, not just at one time.

[joeqsmith]

Can you think of anything with the hardware that could cause this?  I'm not referring to the FPGA but the physical hardware like soldering, artwork, contamination.     

Nothing special happens in the hardware at 11.8 ns - a physical issue might cause a problem, but it's odd that the increased noise would only show up at one delay.

Your unit was from our first small-run batch (earmarked for test/review only). Since we improve our process and QA with each run, the first batch is also the most likely to have physical issues. We've sent you an email with more specifics on which chips/etc might cause a problem. But any physical issue we can think of would cause random spikes everywhere, not just at one time.

Like all multifaceted problems, it takes time to peel away the layers of the onion.   I suspect we are not dealing with so much an 11.8ns time, but rather what was happening with the signal at that time.  When I attempted to measure channel 1's return loss, it was unstable.  Reworking the connector solved that.  Now, channel 1 appears to be the most stable.  After your updates to the FPGA and firmware, I have yet to see anything I would consider a glitch on that channel after several hours of testing. 

Upon further inspection, I have some concerns with the soldering which I plan to address.  I wonder with the spikes showing at the peak apex of the sinewave, are we dealing with a noise problem in the hardware.  With it being a prototype I am not at all concerned about your production soldering.  Of course, this means I will be removing the PCB from the case to address any bottom side issues as well.  If after rework I continue to see any problems, I may have a look at the BGA. 

On the upside, you have time to work on your software.  I want both of us to have full confidence in that hardware before getting back to the review.

[joeqsmith]

Could you provide details on what all the self test entails?   

Thinking about my comment about it not being so much related to time but rather it being the positive apex of the signal, look at the last set of plots.  Note that the highest noise for all 4 channels is in that region.  Oddly we don't see that with the negative apex.  If you think the signal's shape is exacerbating the problem with this particular hardware, should we test it with say a squarewave?  Higher frequency?   

Basically, I am looking for your thought on proving out the hardware after rework.

[SJL-Instruments]

Could you provide details on what all the self test entails?   

The self-test verifies FPGA communication, checks the minimum and maximum range of the delay generator, checks the delay generator calibration is valid, checks that all channels are returning data (verify the CDF is >0.7 at 1V and <0.3 at -1V), and verifies that the internal trigger source is working.
The self-test does not verify any of the external trigger settings.

Thinking about my comment about it not being so much related to time but rather it being the positive apex of the signal, look at the last set of plots.  Note that the highest noise for all 4 channels is in that region.  Oddly we don't see that with the negative apex.  If you think the signal's shape is exacerbating the problem with this particular hardware, should we test it with say a squarewave?  Higher frequency?   

Basically, I am looking for your thought on proving out the hardware after rework.

To be honest, we're not sure, as we can't reproduce the noise spikes you're seeing with our test units. Higher frequency will increase sensitivity to timing jitter (but as CH1 is fine, that's likely not the problem). Given that a 1 GHz sine wave is known to reveal the issue on your unit (at least sometimes), we'd recommend staying with this signal to keep things consistent. But if you find a signal that reliably causes increased noise, we'll see if we can reproduce your results.

[joeqsmith]

Thanks for the added details on the self test.    Attached showing the raw data from #210. 

***
Spent a few hours today inspecting every joint (except the BGA) and reworking anything questionable (major).  Also cleaned it to remove all the loose balls and residue.   

It appears to have had some effect as the channels are not matched near as well.  Do you align the scopes for gain, offset, other...  Store in NVRAM?  Can this be performed outside of factory?  What tools are required? 

Of course, the big question is if it had any effect on the noise.  This is going to take some time to answer. 

[SJL-Instruments]

It appears to have had some effect as the channels are not matched near as well.  Do you align the scopes for gain, offset, other...  Store in NVRAM?  Can this be performed outside of factory?  What tools are required? 

We do not individually calibrate every channel - all the analog components are tightly toleranced to obtain good matching.
In what way are the channels no longer matched? (DC offset, THD, overall gain, etc.)

[joeqsmith]

It appears to have had some effect as the channels are not matched near as well.  Do you align the scopes for gain, offset, other...  Store in NVRAM?  Can this be performed outside of factory?  What tools are required? 

We do not individually calibrate every channel - all the analog components are tightly toleranced to obtain good matching.
In what way are the channels no longer matched? (DC offset, THD, overall gain, etc.)

Looking at post 197 showing all 4 channels prior to rework.  You can see, they were never really matched well.  After rework, they have spread apart even further.   I would need to run some tests to determine how much is due to gain vs offset but it sounds like it currently isn't  possible to correct for them anyway.  Are there plans to add some sort of alignment procedure to your software that could be saved?

https://www.eevblog.com/forum/testgear/pocket-sized-6-ghz-1-tss-et-scope/msg5306536/#msg5306536

The manual has a max offset with inputs shorted and a tolerance for the input impedance at 1GHz and we also now know your return loss is in the 17dBish range.   

Maybe it's not an issue for most users.  I wouldn't normally make measurements with the inputs shorted to ground or with a 1GHz signal.  It would be difficult for me to know how mismatched the channels really are when looking at them with your software.  I would wonder, how much is the scope contributing to the error compared with my signals.  Maybe there is a way to clarify this.

When you specify the maximum DC RMS (section 1.5), are you running internal trigger with all inputs shorted?   

****
In general, it appears that the gain has increased.  However, I suspect there may be more to it.  The attached data is for channel 2 only.  Yellow trace was from post 197 during the start of the collection.   The orange trace was taken the day after with the same settings.  Notice how the gain has increased.   Violet was taken after the scope had ran for about 3 hours after my rework.   

[joeqsmith]

Again, looking at channel 2.  Showing the first set of data after I reworked the board.  We are looking at sweeps on the X-axis, hourish of time.  This is subtracting the mean from the signal as previously described.  Note how the noise level decreases as it warms up.