| Products > Test Equipment |
| Pocket-Sized 6 GHz 1 TS/s ET Scope |
| << < (95/107) > >> |
| SJL-Instruments:
--- Quote from: joeqsmith on March 23, 2024, 05:27:52 am --- --- Quote from: SJL-Instruments on March 23, 2024, 05:15:00 am ---... This is only an issue if the user has both the old and new version of the software installed, and runs the new software, then the old software, without the scope being unplugged in between ... --- End quote --- To be clear, you are considering the software I wrote as being old software. I could care less about your old software having problems outside of it demonstrating the problem you have caused with my custom software. Why wouldn't you return the scope to what ever the older software requires on exit? I suggest at minimum, adding at least a comment to the start of the programming manual that describes this. As you now require I modify my software to force it back to the original mode. *** I am not a fan of having to power cycle test equipment to work around firmware, FPGA and software problems. --- End quote --- Point taken - in the next software revision, we will return all parameters to default upon exiting the software. We have linked a prerelease below that incorporates this change. It should no longer cause a problem with your custom software, or with any older version of our software. https://gigawave-releases.s3.us-east-2.amazonaws.com/GigaWave_v2.6.3_PREVIEW20240323_Windows.zip |
| joeqsmith:
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. *** I should mention, this is the same test I had ran a few weeks back. The older firmware survived this test for several hours. https://www.eevblog.com/forum/testgear/pocket-sized-6-ghz-1-tss-et-scope/msg5337386/#msg5337386 |
| joeqsmith:
--- Quote from: SJL-Instruments on March 22, 2024, 08:58:39 pm --- --- Quote from: joeqsmith on March 22, 2024, 08:28:40 pm ---Power user mode, why when I select a start of 11n, the actual start is 10.997n? 12 is 11.998. End at 18 gives 18.003. --- End quote --- This is so that the timebase lines up correctly in intensity/color-grading mode. This is more clear with few points in the timebase. As an extreme example, consider having only two points in the timebase at 10ns and 11ns. Then the intensity-grading at 10 ns would fill the region from 9.5 to 10.5 ns, and the intensity grading at 11 ns would fill the region from 10.5 to 11.5 ns. If the endpoints were labeled as 10 ns and 11 ns, the timebase and cursors would not line up correctly. --- End quote --- --- Quote from: SJL-Instruments on March 23, 2024, 04:40:40 am --- --- Quote from: joeqsmith on March 23, 2024, 04:00:53 am ---Sorry but I don't understand. Using your example, I would sample at 10n & 11n. I would end up with a set of PDF data at each time. I would just plot the intensity of these two data sets. At least that is how my software currently works. --- End quote --- We have attached an explicit example. The timebase contains three points at 10.5, 10.75, and 11.0 ns. If the horizontal timebase was labeled to start at 10.5 and end at 11.0, the intermediate tick marks would not line up correctly. If there is a better scheme we haven't thought about, we are open to changing this behavior. --- End quote --- 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. |
| SJL-Instruments:
--- Quote from: joeqsmith on March 23, 2024, 08:18:40 pm ---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. --- End quote --- 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. --- 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. |
| joeqsmith:
--- Quote from: SJL-Instruments on March 24, 2024, 03:37:21 am --- --- Quote from: joeqsmith on March 23, 2024, 08:18:40 pm ---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. --- End quote --- 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. --- End quote --- In your previous example where you show the plot using 10.5, 10.75, and 11.0 ns, you actually plot 4 data points, even though the software is showing only 3. If I use my software to collect data starting from 10.5n with a range of 0.5n and a 250ps resolution, I get a start of 10.5 and a stop of 11 with three data points. This is what I would expect to see. *** :palm: :palm: So ... I looked at LabView's intensity graph and sure enough, it has the same problem as what you show. I had not noticed it until I looked at the three sample example. When I scaled the graph originally, I just used the two end points. Looking at a lot of data, I did not see the error. |
| Navigation |
| Message Index |
| Next page |
| Previous page |