Products > Test Equipment
Pocket-Sized 6 GHz 1 TS/s ET Scope
<< < (67/107) > >>
joeqsmith:
Of course, if you had a simple checksum and other checks builtin to the protocol like most,  I would still write scripts to create valid checksums with an invalid payload.   I like things that are solid.   If it were a $50 nanovna, I would say who cares.
SJL-Instruments:

--- Quote from: joeqsmith on February 15, 2024, 03:02:23 am ---
--- Quote from: SJL-Instruments on February 15, 2024, 02:58:04 am ---The first command is interpreted as "S2", since the third byte (0xDA) is non-printable and the rest of the command is ignored.
This will cause subsequent commands to fail, as a minimum of 3 triggers per sample (S3) is required. The default value is 4096.
We will document this in the next manual revision.

--- End quote ---

I think you are missing the point.  I don't think pointing out that your firmware is not robust and to treat it like a princess or it will require a power cycle is time well spent.  Far better to harden the firmware so it handles all unforeseen conditions gracefully.  Again just MO. 

--- End quote ---
We understand your point, and intend to harden the firmware, likely in the same release where we add SCPI support.
Until then, we want to document where all the edge cases occur. Our comment was to point out that your fuzzing uncovered one of the bounds we forgot to document - we wanted to be public about this change to the documentation.
joeqsmith:
I'll try to work around the firmware and see if I can replicate the spamming issue. 

With that first script, sending only the first command should not hang the scope.  It should still respond to other commands.  It seems to need both to cause the scope to only send the CH1 BAD response. 

Attached 1st column is sent command in ASCII, 2nd is command in HEX, 3rd is the response.   T is not a documented command in the manual.   A lot of these where it responds, it has an invalid payload that does not match with the manual.  The firmware decides to use it anyway.   :palm:   My guess is some random miss without any error checking/recovery and then interpreting bad payloads as somehow good it the reason I have seen the scope hang when using it normally.   Personally, adding SCPI doesn't really bring much.  Hardening what you have would be far more beneficial.   
SJL-Instruments:

--- Quote from: joeqsmith on February 15, 2024, 01:23:07 pm ---I'll try to work around the firmware and see if I can replicate the spamming issue. 

With that first script, sending only the first command should not hang the scope.  It should still respond to other commands.  It seems to need both to cause the scope to only send the CH1 BAD response. 

Attached 1st column is sent command in ASCII, 2nd is command in HEX, 3rd is the response.   T is not a documented command in the manual.   A lot of these where it responds, it has an invalid payload that does not match with the manual.  The firmware decides to use it anyway.   :palm:   My guess is some random miss without any error checking/recovery and then interpreting bad payloads as somehow good it the reason I have seen the scope hang when using it normally.   Personally, adding SCPI doesn't really bring much.  Hardening what you have would be far more beneficial.   

--- End quote ---
We're working on hardening the firmware. The command parser itself is solid. As a first pass, we just need to add range checks for the parameters in each command.
The T command is aliased to the *TST? command. We will document this in the next manual revision.
For clarity, the sequence S2, then T will reproduce your result.
joeqsmith:
What about a these?  None are valid commands at the time it crashes.   

3&4, I changed my test to run up till five failures so you can see how the scope only returns CH1 BAD responses. 

I suspect you are going to spend a lot of time documenting  outlier cases.  IMO, it would be better to address the root problem.  Once the communications are robust, you can start to build off that solid foundation.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod