Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature requests: Multiple features #51

Open
consultron-len opened this issue Oct 5, 2023 · 0 comments
Open

Feature requests: Multiple features #51

consultron-len opened this issue Oct 5, 2023 · 0 comments

Comments

@consultron-len
Copy link

Hi. I'm impressed by your SerialPlot tool. I can see there is much hard work that went into it.

I've noticed the tool ha many feature found in an oscilloscope.

Feature #1: Multi-channel plot triggering events
One of the features lacking is plot triggering. This is where the plot starts advancing and capturing into the buffer upon a user-defined event. This can be for example when a specific channel goes above or below a 'trigger' threshold. Other trigger events can be based on:

  • multiple simultaneous channel thresholds.
  • single channel threshold crossing counts.
  • many, many more triggering event types. (For example check the triggering events supported by the KeySight oscilloscopes.)
    Note: I realize that the BEST place to start plotting on trigger events is within the client. Your reaction time to the event will be delayed. Only a deep buffer, can properly capture enough data to provide enough time for a decision. Also, you can only make a decision on the data rate supplied by the client device feeding the data. If the data rate is too slow, your decision is only good as the data supplied.
    Usually on an embedded system there are better and much faster decision of a good triggering event to start dumping data.

This feature can be useful on making more efficient use of the buffer.

Feature #2: Multi-channel plot filtering
This is somewhat related to Feature #1. The user can provide search/filter criteria (which may include thresholds) to find a search index where the criteria is satisfied. This is a post-processing of the buffer data.
Theoretically, this search can be done as the data is being acquired. The plot can display a 'caret' where the search criteria is met both in the static or dynamic running of the plot.
A deep buffer is usually preferred.

Feature #3: Channel labelling and unit designation
You already have the ability to define and save) the Label name. You you see a benefit for the client to 'push' these labels? Theoretically, this might be done with a 'two-way' request from the host for label info.

This label info request can be also augmented with unit designation.

If such a two-way communication is added, theoretically, your "Data Format" info about the data to plot can be sent to allow SerialPlot to automatically sync up without requiring the user to know the plotting specifics.

Feature #4: Using the Frame Start as a packet sync with automatic detection
You can add a Button next to the "Frame Start:" field. This button can perform an auto-detect on the packet and fill in the field.
I realize with random-ish data this feature can be tricky.
If the Frame Start pattern is detected during the data, Simple Binary and ASCII can be ignored.

These are suggestions that I hope you might find useful to include in future versions. They are targeted to improve the user experience in setup and gathering useful data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant