| Products > Test Equipment |
| Pocket-Sized 6 GHz 1 TS/s ET Scope |
| << < (94/107) > >> |
| SJL-Instruments:
--- Quote from: joeqsmith on March 23, 2024, 04:00:53 am ---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? --- End quote --- We can do this in the next revision of the firmware. Ideally, with the USB DFU method, this compatibility issue should never occur, as all future .dfu update files will contain matching MCU and FPGA firmware files. Nevertheless, it would be a good failsafe. --- 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. --- Quote from: joeqsmith on March 23, 2024, 04:00:53 am ---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. --- End quote --- We had run similar tests to validate the firmware before releasing it, and did not find this problem. These tests may not have been long enough. We'll run some much longer tests and see if we can reproduce this behavior. --- Quote from: joeqsmith on March 23, 2024, 04:00:53 am ---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. --- End quote --- The serial protocol is fully backwards-compatible. All previous software versions do work with the new firmware. The difference is in the new bootloader, which now inserts a 2 second delay upon startup to listen for a firmware update command. If the scope is plugged in for at least 2 seconds prior to starting the software, it should work correctly. This goes for your custom software as well. We will document this change in the next manual revision. The bootloader delay is necessary as a failsafe to allow recovery from a bricked MCU update, or an incompatible firmware file being flashed (especially if users later wish to develop open-source or custom firmware). --- Quote from: joeqsmith on March 23, 2024, 04:00:53 am ---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? --- End quote --- The Y parameter is optional and does default to the old behavior if omitted. The serial interface is fully backwards-compatible. The 8-bit precision is the old operating mode, which uses 1 byte for the CDF return format. If the optional parameter is omitted, the behavior is exactly the same as previous revisions. We're not sure what you mean by "assumes everything is integer based" - could you clarify? |
| joeqsmith:
--- Quote from: SJL-Instruments on March 23, 2024, 04:40:40 am ---The serial protocol is fully backwards-compatible. All previous software versions do work with the new firmware. The difference is in the new bootloader, which now inserts a 2 second delay upon startup to listen for a firmware update command. If the scope is plugged in for at least 2 seconds prior to starting the software, it should work correctly. This goes for your custom software as well. --- End quote --- That is not what I am seeing. The scope has been running a half hour. Older software does not appear to work with it. The latest appears to still work fine. Using v2.5.12, there appears to be nothing I can change in the settings that will cause it to start a collection. I only see the flashing Wait. I see this same behavior with all of the older versions of your software that I tried. Really odd is that you're not seeing this and it works for you. With mine, I can't get any of them to work except the latest. *** Odd too, looking at the main graph of v2.5.12 for example, the horizontal axis begins at -102 ns and ends at 138 ns. Guessing this is because it never sees a trigger. Odd is the internal trigger doesn't even kick. Yet it all works on your end? Crazy. Must be a user problem. |
| joeqsmith:
Found how to reproduce the problem easy enough. Run your new software, collect some data. Exit your software. Now run v2.5.12. Should be dead. Exit the software and run the new software again, should return to normal. Exit and run the old software, again should be dead. Now power cycle the scope. Should work. In case it has something to do with my setup, I have attached the defaults. |
| SJL-Instruments:
To be clear, we are claiming that the following should work: 1. Plug in the scope. 2. Run v2.5.12. We can reproduce the issue you are describing. It occurs because the new software sets the scope to the new 16-bit CDF return format, which the old software cannot understand. 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. In general, we will guarantee backwards compatibility, but not forwards compatibility. A workspace settings file created in v2.5.12 will load correctly in v2.6.2, but not the other way around. It is possible to maintain forwards compatibility, but this would add a very large overhead to our software development. We could do it if it's important to our users, but this does not appear to be the case at the moment. |
| joeqsmith:
--- 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. |
| Navigation |
| Message Index |
| Next page |
| Previous page |