serialplot icon indicating copy to clipboard operation
serialplot copied to clipboard

Feature requests: Multiple features

Open consultron-len opened this issue 1 year ago • 0 comments

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.

consultron-len avatar Oct 05 '23 14:10 consultron-len