Products > Test Equipment

Pocket-Sized 6 GHz 1 TS/s ET Scope

<< < (6/107) > >>

SJL-Instruments:
For automated tests, we have an open-source Python API available on the software page that exposes (in principle) the same functionality as the main software. (We know isn't quite the same thing as an interface toolkit.) EDIT 2024-01-13: The serial interface is now documented in Section 4 of the manual.

Yes, the interface currently allows saving only one trace at a time. We will improve this feature to support multi-channel export by the end of the week.
Implemented as of 2024-01-11.

We'd like to clarify what you mean about showing all the data: samples are taken while the trigger-to-sample delay is increased incrementally from t_min (left screen) to t_max (right screen). The data on the screen is the only data that can be reasonably assumed to be up-to-date (within a couple seconds). For example, if you unplug the signal source and then zoom out, the revealed data will be stale.
We choose to erase this potentially stale data. Keeping this data is an equally consistent option. Is this what you are proposing?

By "time marker," you mean a marker at T=0, correct?
EDIT: Implemented 2024-01-11.

The minimum trigger-to-sample delay is 11 ns. We recognize this disqualifies some measurement setups.
During development, we made prototypes with minimum trigger-to-sample delays of ~2 ns, but either at the expense of (1) worse time accuracy of ~3 ps RMS and thus worse ENOB, (2) significantly higher cost, or (3) exceeding USB 3 power budget. We chose lower cost, higher ENOB, and power-over-USB with 11 ns dead time.
(There isn't a good way around the delay itself - any sequential sampling scope will not be able to view the edge it is triggering on, without a synchronized clock signal or an analog delay line.)

Low rep-rate signals:
There are three ways to speed up acquisition for low-rep-rate signals:
1. Decrease timebase resolution (pts/div option in "Timebase"),
2. Decrease number of samples per CDF. [Default 30, not currently exposed in software]
3. Decrease the number of triggers per CDF sample. [Default 4096, not currently exposed in software]
The second option gives limited speedup since you really need >=10 samples to get something meaningful.
The third option defaults to 4096 triggers per sample and decreases with increasing trigger holdoff to maintain roughly constant sweep rate.

We will expose these options to the user (next update, by EOW now implemented). As they affect the reconstruction timescale [User Manual Sec 2.2] and other details, there are also some subtleties we need to explain in the documentation.
(This is one of the things that we hope to demonstrate better in our planned videos).

An ignition system @ 1 ktrig/s would take 30 seconds per sweep @ 3 triggers/sample for 1 kpts @ 10 samples/CDF.
A source @ 120 ktrig/s would take 8 seconds per sweep @ 30 triggers/sample for 1 kpts @ default 30 samples/CDF.
(For your Tektronix pulse source, you would need to tap into a >11 ns pretrigger for CH1 and send the rising edge into CH2.)

Curious to hear your honest opinions on the above.

Edit re: mask testing. We currently do not have this implemented in software. We have this planned, and the firmware has provisions for fast mask testing (i.e. direct counts of mask failures, which is important when you are trying to count rare events).

Edit 2 re: Rewrite the discussion on low rep rates.

mawyatt:

--- Quote from: azonenberg on January 05, 2024, 05:29:13 pm ---Oooooh you're directly measuring the CDF not the PDF?

Sounds like you built the concept I tossed over years ago called FREESAMPLE (as in "free/open source sampling scope").  I have an incomplete design https://github.com/azonenberg/freesample if you're curious but realized I didn't know enough about high speed design at the time and tabled it. I had successfully prototyped the concept at 10 Gsps in a PMOD hanging off a Xilinx FPGA but never took it to its logical conclusion so I'm happy someone else is exploring the technology.

Your docs are light about internal details and I understand if you don't want to share all your secrets yet but here's my crack at theory of operation based on how my design worked: Variable delay line after trigger comparator (my design had a CDR PLL option as well, not sure if you have that... looks not?) driving the latch port of a high speed latching comparator fed by the signal. At the time I did my design the best option was the Hittite (now ADI) HMC674/675 which had around 10 GHz analog BW. Other input of the comparator driven by a DAC (12 bits in your case).

Each trigger collects one bit of data: the input was or was not greater than Vdac at time offset T.

Repeat a large number of times and divide by the number of triggers to get the probability of the signal being less than Vdac at time T, then sweep Vdac and T across the display range to measure the CDF of the signal.

Partial derivative of CDF with respect to dV then gives the PDF, aka intensity graded waveform.

EDIT: Not sure how your capture system works. The advantage of my architecture was that if you went with the PLL based sampler rather than the delay line sampler you'd get multiple samples per trigger at the PLL output frequency (which could be divided down a lot from your symbol rate, say one sample per 8 UIs or something). You could then capture this with an FPGA input at fairly high rates. I forget the details but I think I was aiming for circa 1 Gsps realtime (1 bit) sample rate using a 7 series ISERDESE2. This approach also avoids jitter getting too high due to excessive analog delay (since you can delay by fractional or integer PLL cycles to get arbitrarily long delays) and allows arbitrarily deep memory.

Am I pretty close? :)

--- End quote ---

At the time did you look into the Hittite HMC661 Sampler?

The origins of which date back to 1999~2000 when we were developing the first RF/MW SoC and worried about Digital and Analog/RF isolation/corruption. As a "Plan B" we employed Q Dot to develop an Emitter Follower based Sampler in IBM SiGe to sample the MW signal between the digital clock edge "quiet time". Plan B wasn't required as we developed and patented a chip isolation scheme that worked, however the Sampler also worked well and became a product after Semtech acquired Q Dot and later sold to Hittite. Q Dot became a means for Hittite moving into SiGe technology.

Best,

joeqsmith:

--- Quote from: SJL-Instruments on January 07, 2024, 06:06:13 am ---For automated tests, we have an open-source Python API available on the software page that exposes (in principle) the same functionality as the main software. (We know isn't quite the same thing as an interface toolkit.)

Yes, the interface currently allows saving only one trace at a time. We will improve this feature to support multi-channel export by the end of the week.

--- End quote ---

Thanks on both of these.  I'll check into it the API. 


--- Quote from: SJL-Instruments on January 07, 2024, 06:06:13 am ---We'd like to clarify what you mean about showing all the data: ...

By "time marker," you mean a marker at T=0, correct?

--- End quote ---

Assuming you define T=0 as the trigger, then yes.  I expect to be able to see data before and after the trigger but it seems this isn't possible with your oscilloscope.

My comments about the displaying the various channels on separate graphs is common. Having four  traces on a single graph can get cluttered. 


--- Quote from: SJL-Instruments on January 07, 2024, 06:06:13 am ---The minimum trigger-to-sample delay is 11 ns. We recognize this disqualifies some measurement setups.
...(There isn't a good way around the delay itself - any sequential
sampling scope will not be able to view the edge it is triggering on, without
a synchronized clock signal or an analog delay line.)
--- End quote ---

My old sampling scope uses RIS. I recently used it to demonstrate using a low cost VNA for TDR/TDT measurements.  Time stamped:

https://youtu.be/9CwQ5Z7XF0w?t=1127

I am surprised by your 20 page manual.  The software shown in that video not a commercial application and is offered free of charge with a 200 page manual. 


--- Quote from: SJL-Instruments on January 07, 2024, 06:06:13 am ---Low rep-rate signals:
...
We will expose these options to the user (next update, by EOW). As they affect the reconstruction timescale [User Manual Sec 2.2] and other details, there are also some subtleties we need to explain in the documentation.
(This is one of the things that we hope to demonstrate better in our planned videos).

--- End quote ---

Thanks.


--- Quote from: SJL-Instruments on January 07, 2024, 06:06:13 am ---An ignition system @ 1 ktrig/s would take 30 seconds per sweep @ 3 triggers/sample for 1 kpts @ 10 samples/CDF.
A source @ 120 ktrig/s would take 8 seconds per sweep @ 30 triggers/sample for 1 kpts @ default 32 samples/CDF.

--- End quote ---

Consider a gasoline engine may idle at 600RPM, or 60RPS or 60Hz trigger.  I assume 10X slower trigger rate = 300 seconds. I think I would just need to try some of the previous work arounds you mention.   I think the bigger problem is the lack of a pretrigger to see what is going on.   


--- Quote from: SJL-Instruments on January 07, 2024, 06:06:13 am ---(For your Tektronix pulse source, you would need to tap into a >11 ns pretrigger for CH1 and send the rising edge into CH2.)

Curious to hear your honest opinions on the above.

--- End quote ---

I had modified that old tunnel diode pulser I mentioned to replace the trigger connector with an SMA. The trigger preceeds the rising edge by 85ns.  I assume I would just trigger on Ch1 and delay 85ns with edge shown on Ch2.  Shouldn't require any changes.  You can't use a level trigger with this device.  Normally, like with an ignition signal, there is no good way to create a pretrigger and the signals are not stable enough to delay a full period to capture the pre and post trigger data.  So we would never see what the rise time for example looks like.   

SJL-Instruments:

--- Quote ---My comments about the displaying the various channels on separate graphs is common. Having four  traces on a single graph can get cluttered. 
--- End quote ---
Got it. This will go into the next software update, or the one after.


--- Quote ---I am surprised by your 20 page manual.  The software shown in that video not a commercial application and is offered free of charge with a 200 page manual.
--- End quote ---
Yes, our software does not have nearly as many features as LeCroy's. We are actively working to improve it, but do not have the resources of a large company. One of the motivations for this forum post is to get feedback on which features we should prioritize.
(On the flip side, we would argue that our software has little to no learning curve, for precisely this reason.)


--- Quote ---I assume I would just trigger on Ch1 and delay 85ns with edge shown on Ch2.  Shouldn't require any changes.
--- End quote ---
Should work exactly as you expect.


--- Quote ---Normally, like with an ignition signal, there is no good way to create a pretrigger and the signals are not stable enough to delay a full period to capture the pre and post trigger data.  So we would never see what the rise time for example looks like.
--- End quote ---
In that case, a sequential sampling oscilloscope like the GigaWave is not suitable - you need random sampling. We don't think random sampling is viable at this bandwidth and price point (at least for a new, commercial product).

perdrix:
I am correct to think that this is for repetitive signals only, not single shot 6GHz?

D.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod