Products > Test Equipment
Pocket-Sized 6 GHz 1 TS/s ET Scope
<< < (96/107) > >>
joeqsmith:

--- Quote from: SJL-Instruments on March 24, 2024, 03:37:21 am ---
--- Quote from: joeqsmith on March 23, 2024, 03:40:38 pm ---Repeating the random test, attached showing the commands sent just prior to the DSO going unresponsive.    Once it enters this mode, it will no longer respond to any commands.

--- End quote ---
We cannot reproduce a lockup by sending this exact sequence of commands. We have been performing similar fuzzing tests on several units in parallel (integrated 200 hours) with no lockup.
There may be some difference between the way we are performing these tests. We are sending between 1 and 100 commands, each containing between 1 and 10000 random bytes, and then reading the responses. If possible, it would be helpful to have a sequence of commands that reproduces the problem. We are looking for codepaths that could cause what you're seeing, but not being able to cause the problem makes debugging difficult.

--- End quote ---

If we are calling a command one packet of data,  I send them until I decide to stop it.   The packet size is between 1 and 12 bytes.  All packets are CR terminated (adding one additional byte).    There are no filters as to what the payload contains.   It's just random data of a random length. 

Sure, I can create a test file of commands for you like last time.  It seems easy enough to reproduce. 
joeqsmith:
Power cycle the scope and send these commands.   Next run your software.  You should find that the software will connect to the scope.   The scope should not trigger no matter what settings you make.

Next, power cycle the scope.  Run your latest software then exit.  Send these command to the scope.  Run your software.  The scope should not be detected.

***
Note this is a CSV file.  The file type isn't supported for uploading.  Packets are CR terminated.
joeqsmith:
Not that is will help your situation but with LabView, I just clip off the first and last half time and then process the X axis normally.   Nice thing about this approach besides aligning the screen to the requested start and stop locations, it's also simple (at least with LabView) to add. 
SJL-Instruments:

--- Quote from: joeqsmith on March 24, 2024, 05:42:45 pm ---Not that is will help your situation but with LabView, I just clip off the first and last half time and then process the X axis normally.   Nice thing about this approach besides aligning the screen to the requested start and stop locations, it's also simple (at least with LabView) to add. 

--- End quote ---
Thanks for the suggestion. We will implement this behavior in the next revision (half-width shaded region on first and last points). You're not the first to ask about the axis labeling - hopefully this will prevent future confusion.



--- Quote from: joeqsmith on March 24, 2024, 04:43:36 am ---Power cycle the scope and send these commands.   Next run your software.  You should find that the software will connect to the scope.   The scope should not trigger no matter what settings you make.

Next, power cycle the scope.  Run your latest software then exit.  Send these command to the scope.  Run your software.  The scope should not be detected.

--- End quote ---
We have tried sending these commands in several configurations (in one large binary blob, or with commands separated by 0.1, 1, 10, 100, ms, both with or without reading the responses) but cannot induce a lockup.
We have attached a log from one of these tests if you'd like to verify that we are interpreting your file correctly, and splitting the commands as you'd expect. In this log, some commands take longer than the 10 ms timeout, and so the corresponding response appears after a later command (with the intermediate commands queued).
Based on your response #472, does the scope always lockup at the command "72 2D 72 0D"? If so, this may be enough information for us to track down the root cause in firmware (even if it is unit-dependent).
joeqsmith:
I am not sure if it actually locks up.  It ends up in one of two modes, depending on if I had ran the new software or not.  One mode, it will not trigger after connecting to the scope with your latest software.  The other, it seems to go unresponsive and your software can not detect it on startup.  Windows still sees the connection.  In this state, I am able to use my software to connect to the scope but it will not respond to any commands.

Both cases, the scope will recover only after a power cycle. 

I just tried it again with the script I provided and was able to repeat the same results.   

Looking at your txt file, it appears correct.   

It appears that it is related to the new R command as symptom is tied to if I run your new software or not.   Currently I give the scope a ms to respond.  If it doesn't respond, I send the next packet.   This is the same way I tested the previous firmware.   I wonder if I am overflowing some internal buffer in your firmware.   I slowed down my transmission and it's up to 50k packets.   I'll let it continue to run but it is starting to look like an overflow problem.     

You mentioned you had looked at my VNA software.   If so, did you get the 32-bit application to run? 

Not that it helps, but on the graphing, LabView allows you to have multiple markers per axis on a graph.  The horizontal would normally be 0 - 10 for example, but I can have a second scale of say 10n - 10.5n on that same axis.   I can also manually scale the graphs.  So, I send the data to the graph and set the min and max horizontal to a half sample from the actual min/max.  I then set the second scale to what the actual time is.  There's no math or anything to track.  It's very clean to do it this way and I don't have a dead spot on the graph which is sounds like you will have based on your description.  If I tell the scope to sweep from 10-11, I am not expecting the graph to be from 9-12 with data only showing up between 10 and 11.  I expect it to start at 10 and stop at 11. 

***
Appears to be some type of overflow.  I suspect when I run your software and allow the scope to start to sweep, it places it into a mode where it is more susceptible to the overflow.   If you have LabView, I can give you the source code.  Or, if you have the runtime engine installed for 2011 (would have been required to run the original software I provided for the NanoVNA) I can supply you with an EXE.  My guess is there is nothing really unique about the data I am sending the scope, it's just how fast I am able to send it.  But you tried it with a 100us throttle, which should be faster than what I am doing.   
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod