Products > Test Equipment

Pocket-Sized 6 GHz 1 TS/s ET Scope

<< < (60/107) > >>

SJL-Instruments:

--- Quote from: joeqsmith on February 10, 2024, 06:28:19 pm ---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.   

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

--- Quote from: SJL-Instruments on February 10, 2024, 08:43:24 pm ---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.

--- End quote ---

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:

--- Quote from: joeqsmith on February 10, 2024, 10:11:39 pm ---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.   

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

--- Quote from: joeqsmith on February 10, 2024, 10:56:59 pm ---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. 

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

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