Products > Test Equipment

Pocket-Sized 6 GHz 1 TS/s ET Scope

<< < (20/107) > >>

SJL-Instruments:

--- Quote from: Kean on January 17, 2024, 02:30:34 pm ---
--- Quote from: SJL-Instruments on January 17, 2024, 02:14:36 pm ---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).

--- End quote ---

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.

--- End quote ---
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?


--- Quote ---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)?
--- End quote ---

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.


--- Quote ---We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).
--- End quote ---
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:

--- Quote from: joeqsmith on January 17, 2024, 04:09:50 pm ---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?

--- End quote ---
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.


--- Quote from: joeqsmith on January 17, 2024, 04:09:50 pm ---
--- Quote ---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)?
--- End quote ---

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.

--- End quote ---
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.


--- Quote from: joeqsmith on January 17, 2024, 04:09:50 pm ---
--- Quote ---We also caught another minor mistake - the returned value is actually 1 - F(V; ∆t).
--- End quote ---
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.     

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


--- Quote from: joeqsmith on January 17, 2024, 04:09:50 pm ---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.

--- End quote ---
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:

--- Quote from: SJL-Instruments on January 17, 2024, 04:35:41 pm ---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.

--- End quote ---

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:

--- Quote from: joeqsmith on January 17, 2024, 04:45:03 pm ---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.   

--- End quote ---
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.


--- Quote from: joeqsmith on January 17, 2024, 04:45:03 pm ---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.

--- End quote ---
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.

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