Sorry but I am still not understanding why the mismatch. In this last example, you start at 10.5. The software shows data 125 ps prior. If I send the D command with a 10ns delay, I assume the data the scope sends is at the delay I specify, not 125ps prior. Your plot shows switch points between the sample times. Again, not what I would expect. In my software, I am just setting the delay and reading back the data for each discrete point in time. If I program 10.0 as a start, it starts at 10.0. If the scope is sending me data at some other time, I am not aware of it.The data returned always corresponds to the time requested. What we are talking about pertains only to the display of the data.
Suppose we take data from 10 ns to 11 ns in 0.1 ns steps. Conceptually, the data is plotted as shown in the attached image. To make the data visible in intensity-graded mode, we shade a finite width of the screen centered around each point in time.
This means that the start and end point of the time axis does not correspond to the first and last time in the data.
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.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.
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.
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.
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.
It's possible to queue up hundreds of these read commands in the serial buffer, effectively "locking up" the scope for several minutes.
The reason this causes a lockup is that the timeout for the R command is scaled based on the CDF tolerance (the expected amount of time needed to reach the specified tolerance), and we did not put a cap on this. In v15 firmware we will get rid of this, and allow the user to specify a max timeout manually, in seconds.
There is a question of whether to actually remove the FIFO, or just remove it as part of the documented interface.
Consider that what ever you come up with, there needs to be a way to abort a command (without pulling the USB cable). As I mentioned, I use a full handshake today. However, if the scope doesn't respond in N time, I do some sort of recovery. Normally, resending the last command. There isn't any mention in the manual how you want to handle such cases.
Are you able to detect software disconnection of the communication port to flush the FIFO. e.g. via the CP2102 hardware handshaking signals or maybe the SUSPEND pins.
Not sure if SUSPEND is useful, as that probably cannot be triggered under app software control, and only by host power management.
We could immediately cancel the current command, and flush the FIFO, when the Control-C (or Command+C) byte is received. This has the benefit of being natural for interactive terminal use. (We do not anticipate needing to send binary data in a command, other than during USB firmware update, where throughput is not a major concern.)
As I previously wrote, I have never understood your desire to use a terminal to control the scope.
As I also mentioned, I would rather have all communications processed the same way. ...
Make sure that as you expand the protocol, you don't piecemeal it.
This is the reason I had mentioned the automotive standards.
As I previously wrote, I have never understood your desire to use a terminal to control the scope.We have one user who has requested a bulk voltage read mode (specify start/end/step and receive a voltage array), and would prefer using this from an interactive terminal. We do agree that for now, a custom program is needed to interpret the CDF data.
Although, on second thought, anybody using an interactive terminal would never build up a FIFO backlog anyway, so this concern is a moot point for the current discussion.
Tooltips is nice. Consider providing a means to disable it and include that setting when saving the setup.
Bug wise, of course if you run that script I provided, and run your software without a power cycle, you still can't detect the scope is present. I'm guessing you are aware of this and it will require a firmware change to solve it.
I imagine if you turn the crank again (new products) it will get easier based on what you have learned.
Perhaps the current interface is already easy enough to get started with. We are the worst possible judge of whether this is true for new users, given how long we’ve spent thinking about the protocol. You did mention inconsistencies with the return terminators being a possible sticking point. SCPI would define all the low-level considerations like this in a standard way.
Concatenating commands
Multiple commands can be issued to an instrument in a single string. They are made of simple commands separated by a semicolon character (. For example, the command to "Measure a DC voltage then measure an AC current" would be issued as MEASure:VOLTage:DC?;:MEASure:CURRent:AC?.
I recently made a review of lexmux's active probe and had used the GigaWave 6400 as part of the evaluation.
https://www.eevblog.com/forum/testgear/12-ghz-active-probe-project/
During the review, you can how I am saving the waveforms and recalling them for a reference. Something I commonly do when using a scope. Note the number of steps required. You have to manually select a file name, manually reload them, then manually set the gain and offset. I like the idea of having a memory rather than a file and having the software automatically show the data, properly scaled like my other scopes. The less buttons I need to press and typing I need to do, the better. Something you may want to consider with future releases.