Thinking about the FPGA, have you considered adding a revision register that would be exposed to both the firmware and software? Rather than the crash and burn when there is an incompatibility problem, you could report the issue. With the new method of programming, are you suggesting users will never run into the possibility that the firmware and FPGA are not compatible?
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.
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.
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.
I repeated my random data test, allowing it to run several hours. I noticed that it appeared the scope had stopped responding to all messages. So I shutdown my software and started yours. It does not find the scope. Windows sees the communications port. Using my software, I am able to establish a connection to the port but the scope does not respond to any commands.
I had asked about how to program the device with custom software and wonder if these new commands could have locked up the unit. Still, if that was possible, I would have expected your software would be able to clear it. Power cycling the scope did return it to normal operation.
I also tried to collect data using the new firmware/FPGA with my software. It appears that something has been changed that broke my code. So, I tried the original software that you provided (v2.5.3) and it also no longer is able to run the scope. Guessing you are aware of this and the new manual documents these changes.
***
v2.5.12 also does not work with the latest firmware/FPGA. This version is new enough, I would expect it to notify the user with some sort of error about the firmware being too new. Instead, it just doesn't collect any data.
***
Looking at the new manual, there isn't a section about what was changed to the protocol. I was expecting something big enough to break the software would have been in a "whats new" in the Programming Guide. I guess I need to diff the two versions of manual to find out what was changed.
***
Comparing the two PDF manuals Programming Guide section, I see the following changes:
Note: Revision 14 of the firmware will perform this monotonicity correction automatically.
Internally, the delay will be measured and fine-tuned to achieve an accuracy of 0.2 ps or better.
This process takes ∼8 ms. If the optional argument y is set to 1, the verification will be skipped,
saving time in exchange for a typical accuracy of ∼2 ps.
Note: The parameter y is ignored in firmware revisions v13 and earlier.
• [Firmware v14 and later] The optional parameter y determines the CDF return format. If y
is set to 2, then the returned CDF values have 16-bit precision. Otherwise, 8-bit precision
is used.
Note there is no mention of the Y parameter in the latest manual's example code. This may be the problem, but I would expect it to default to what ever the old firmware did as to not break your own software. Odd also is the manual makes no further mention of the 8-bit precision in this section and assumes everything is integer based. Seems like a last second feature (fast mode?) and wasn't well thought out?