Logic Analyzer display, functional and unit issues

[alcorhythm]

• I'm submitting a ...

  • bug report
  • feature request

• What is the current status?

Using the Logic Analyzer to grab a 1MHz SPI signal, using all four channels (capturing the SDI, SDO, SCK and CS of a SPI flash memory chip in this case).

• Most of the time when hitting Analyze, it will only show some small condensed data on the right side of the screen, with most of the screen left blank.
• The triggering settings don't seem to have any effect.
• The X axis of the graph should be using microsecond units (μsec), but it says mSec (which is milliseconds and is inconsistent with how it is spelled for Capture Time, ms).
• Clicking on the Capture Time to enter it using the keyboard brings up a popup, but you cannot enter any value into it.
• The Capture Time slider allows 0.01 to 1 ms, the popup asks for 0 to 5.
• What does the Capture Time do anyway?

• If the current behavior is a bug, please provide the steps to reproduce it

A screenshot of the issue may be sufficient for UI bugs

Most of the time when hitting Analyze, we get nothing, simply because the Analysis stops before any events occurred and there is no triggering.

If we do get something, then most of the time, this is what we get:

Only by hitting the Analyze button many times, you may get lucky and see something more useful:

If you are not in control of the device that you are measuring, this is pretty much unusable. In this case I am specifically sending the same thing over and over on the SPI, with other devices on the bus physically disconnected, in hopes of capturing something.

• What is the expected behavior?

• Scaling so that the data is displayed in a useful way
• Correct and consistent units and values
• Some meaning/functionality to the triggering settings
• Explanation of, and correctly functioning, Capture Time setting

It would also be nice if you can name the channels ;)

• Please tell us about your environment:

  • OS with version number: [ Windows / OSX / Linux Distro ]
    Windows 10

• Other information ( Any research that you may have done which you think is the cause of problem )

In the firmware there seems to be a limit on the maximum amount of time between events, and the total number of events that can be captured. When using 4 (or 3) channels, the time limit is (much) shorter than for 2 (or 1) channels. This time limit only depends on the number of channels captured. That only deepens the confusion about the meaning of Capture Time.

It would be better if we can just keep capturing until some trigger event actually happens. That is, if no events are detected, just capture again, until something is captured.

• Would you like to work on it?
  No... (well I would, but I have no time any time soon).

[bessman]

I will address those issues that pertain to pslab-python.

• Most of the time when hitting Analyze, it will only show some small condensed data on the right side of the screen, with most of the screen left blank.

This is due to fossasia/pslab-firmware#56. Essentially, the logic analyzer sometimes/often returns false timestamps at the start of a capture series. pslab-python tries to remove them, but cannot always distinguish false timestamps from real ones. When that distinction cannot be made, pslab-python defaults to returning possibly false timestamps, rather than removing real ones.

Nope, that's not it at all, see comment below.

• The triggering settings don't seem to have any effect.

Last I checked this was working. I'll check again this weekend.

Works for me.

• What does the Capture Time do anyway?

Exactly what you might expect: The logic analyzer runs for <capture time> before returning any captured timestamps. I'd say that either 1 ms or 5 ms are rather conservative upper limits here. This should be easy to change (for someone who's familiar with the UI code), as the back end has no such limitation. As you noticed, there is a limitation on time between events, but that is not what Capture Time does.

[bessman]

OK, I took a look at the code, and the behavior you're seeing with regards to the long initial period of no logic level changes is actually the intended behavior. It happens when the trigger condition to start the capture is disabled, i.e. when capture begins immediately. In this situation, the initial state (high/low) of the digital input is recorded as timestamp 0.

All that means it is possible to fix this in pslab-desktop by just not plotting the first data point. I'll patch it.

[orangecms]

Duh, it said "partly fixes", and GitHub nicely interprets that and closes the issue when merging a PR. Sorry!