| Products > Test Equipment |
| Pocket-Sized 6 GHz 1 TS/s ET Scope |
| << < (98/107) > >> |
| SJL-Instruments:
--- Quote from: joeqsmith on March 27, 2024, 03:23:19 am ---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. --- End quote --- 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.) --- Quote from: Kean on March 28, 2024, 03:14:42 pm ---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. --- End quote --- For the reasons you mentioned, we don't think this would be a reliable mechanism for this use case. If a serial connection is closed by one program and opened by another, the SUSPEND pin will not necessarily go high in between, so the FIFO responses will continue to be processed and sent to the second program. Our current plan is to nominally (in the documentation) require waiting for one response to start before sending the next command. We will keep the FIFO for backwards compatibility, but will mention the potential lockup issue if this guideline is not followed, as well as how to request immediate cancellation/flushing if needed. |
| joeqsmith:
--- Quote from: SJL-Instruments on March 31, 2024, 12:11:46 am ---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.) --- End quote --- As I previously wrote, I have never understood your desire to use a terminal to control the scope. You can't get any meaningful data without some sort of custom software. As I also mentioned, I would rather have all communications processed the same way. https://www.eevblog.com/forum/testgear/pocket-sized-6-ghz-1-tss-et-scope/msg5327255/#msg5327255 If you do decide to implement some sort of abort command, make sure you think through it. You already have no error checking in the protocol and two different terminators. Using your company name as a terminator to work around binary data being sent.... Make sure that as you expand the protocol, you don't piecemeal it. This is the reason I had mentioned the automotive standards. |
| SJL-Instruments:
--- Quote from: joeqsmith on March 31, 2024, 03:21:14 am ---As I previously wrote, I have never understood your desire to use a terminal to control the scope. --- End quote --- 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. --- Quote from: joeqsmith on March 31, 2024, 03:21:14 am ---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. --- End quote --- We are working on implementing the SCPI standard for test equipment. Given that most of our planned changes for v15 concern the serial interface, we'll bite the bullet and commit to implementing this standard for v15 (rather than make piecemeal adjustments in between), even if it delays the update somewhat. |
| joeqsmith:
--- Quote from: SJL-Instruments on March 31, 2024, 03:53:39 am --- --- Quote from: joeqsmith on March 31, 2024, 03:21:14 am ---As I previously wrote, I have never understood your desire to use a terminal to control the scope. --- End quote --- 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. --- End quote --- That seems odd as the newer software allows ways to export the data. Then there are other shortcomings, for example, they have something beyond a single state signal. I could see having only the voltage could confuse them when taking measurements. Guessing they understand the limitations of the scope and how it works. IMO, the way it is today, if someone needed a feature beyond what the software support, I would suggest just asking you to add it. Other's may be able to leverage these features. If you really need something custom, there's no reason not to roll it from scratch. It's not that complicated especially now with the improved documentation. If you continue to make changes to a protocol that you do not intend to support long term, you're just making work for yourself and anyone else who writes an interface for it. This is why I wanted you do make sure you had a clear path moving forward early on. |
| SJL-Instruments:
We have just released v2.6.3 of the software and revision H16 of the manual. This fixes the bugs discussed here since the last update, adds tooltips (built-in help) for all controls, and FFT cursors. The manual now has a changelog, and we have added documentation on the MCU update protocol (per request). We tried implementing Rj/Dj decomposition for Tj(BER) as well as mask testing for this update, but after several iterations we were not satisfied with the results. This is largely due to the single-comparator hardware limiting the BER fidelity to ~1e-4 in a reasonable acquisition timeframe. We did mention this in the manual, and made this clear to anyone asking about SI applications; but just in case, we've contacted all customers who mentioned SI, and extended their return period in case they were expecting this capability in the future. A bit disappointing on our end, as we do want to push the hardware as far as it can go for the end-user. But best to be transparent about the limits of the hardware, once we reach them. More advanced jitter decomposition/BER analysis will require a future hardware model. Seems like the most successful applications for this scope as of now are high-speed timing analysis (setup/hold, rise/fall times, phase-matching) , TDR/TDT, qualitative eye diagram evaluation, and pulsed laser measurements. |
| Navigation |
| Message Index |
| Next page |
| Previous page |