Wondering if others are having similar issues with pattern match triggers vs edge trigger, (fwiw, I'm running 6.0, 6.5beta in single/multiple analyzers)

[jdavies0]

The background:
Using an interface board in development from @eosits on windows 10 (current) with 2 analyzers to capture 6502 CPU activity. Was running 6.0 but moved to 6.5beta for profile support. The 6.5 migration started with a profile file configured with labels for all channels with the 6502 decoder as mentioned in the 6.5 release notes correctly configured.

The 6.0 code was working ok but I had only been using one analyzer due to the manual configure every time. Mentioning because I know there are differences in the profiles stored in /users/{user}/AppData/roaming/LogicAnalyzer the 6.0 multi configuration json file was overwritten with a 6.5 profile file configured within in analyzer software. The capture configuration appeared to be correct, all channel numbers and labels looked correct. But the decoder signal assignments weren't correct. There are 16 address lines (0-15) and A0 to A9 came in correct, but A10 to A15 are all assigned to A9. So those were manually fixed, and some other signals assigned so the decoder should be correctly configured.

The capture is configuring in pattern mode since edge is not available in multi-mode. Configured a pattern of 01 for the channel 6 of the first analyzer (CPU RST) and thought that would be good, but isn't working. The ch6 01 pattern is to match the rising edge trigger, or so I think.

What I get from the software is most channels are missing most of their data for most of the samples. There's some random traffic on the address lines at the start, and data channels have data throughout. But other than data lines there's a lot of flat-line low channels for most of the capture and this includes the trigger channel which is 0 the entire capture! But, the trigger was correctly detected, and that channel should be high, but it's not (ch6 is light blue):

The "traffic" are the data lines, the address lines are the flat low lines that are below the data lines (visible in the graph view)

So I backed out, removed the app data settings and started over with 6.0. What I found is, if do a multi-capture with the pattern match I get the same results every time. 6.0 fw and software, or 6.5 fw and software same results in multimode with pattern match.

But if I switch to one analyzer and configure edge trigger on ch6 I get this, which is what I'd expect to see:

Couple more rounds of testing and have determined there's something with the pattern match affecting the data capture and it doesn't matter if it's one or two analyzers connected and in single or multi mode. But since pattern is the only option for trigger on multiple units there's no way to work around it that I've been able to find.

Here you can see the two different capture configurations with the last capture for each in the background:
Pattern match Ch 6

Edge Trigger Ch 6

Can anyone duplicate this with their setup?

While I got you, can anyone confirm if the configuration json files should contain something that looks like captured data?

If others can confirm behavior I'll report, but until then I'll assume it a user error. Thanks

[gusmanb]

Hi.

Your trigger is incorrectly set up. A pattern "01" configured starting on channel 6 does not mean "wait for a 0 on ch6 and then for a 1 on ch6" but "whenever you see a 0 on channel 6 and a 1 on channel 7 start capture", that explains what you are seeing, your device is capturing when RST is 0 and D0 is 1, you can see in the captures that's exactly what is happening, so there must be activity in the bus by another devices before the CPU is active and that's what you are seeing.

If you set the pattern to "1" on channel 6 you will have exactly the same behavior as if you set a positive edge trigger on channel 6.

Regarding the captured data in the profiles, it should not be there. Internally there is only a kind of object, a "capture session", it contains settings and captured data, a profile set is nothing else than a set of capture sessions. Said that, the profile should have the capture data cleared before being saved, I will check why it has not cleared the data as it should not be there.

[jdavies0]

Thanks, user error it is! Was clearly confusing this with some other piece of software or some other part of the software (maybe decoder config?) Thanks for confirming a single 1 would be a single sample of 1 would be identical to a rising edge trigger.

Was thinking that if this is just looking for a single 1 on the channel it's not quite the same as a rising edge trigger when the signal starts high, but discovered that LA starts capture with sample 0 at 0 rather than first read value as can be seen here with system running and starting a new capture. There's not change on 6 as seen here:

Will keep this in mind when working with the software. Since this is a parallel sequential pattern match, will there be a Don'tCare options for channels to ignore? Thanks again, looking forward to some fun with your work!!

[gusmanb]

Since this is a parallel sequential pattern match, will there be a Don'tCare options for channels to ignore?

It is implicit on the pattern. Whatever channel is above the start channel is ignored, and any channel not covered by the pattern is also ignored.
If you for example set start channel to 3 and the pattern to "010", channels 1 and 2 are ignored, and channels above 5 also are ignored, only channels 3, 4 and 5 that are covered by the pattern are taken into account.

[jdavies0]

It is implicit on the pattern. Whatever channel is above the start channel is ignored, and any channel not covered by the pattern is also ignored. If you for example set start channel to 3 and the pattern to "010", channels 1 and 2 are ignored, and channels above 5 also are ignored, only channels 3, 4 and 5 that are covered by the pattern are taken into account.

Thanks again. Yes, that had made sense but was likely thinking about something which may not have come up yet and hope you'd consider for a future update.

Full disclosure, I'm working on a hardwired setup, so I can't move signals around and the signals and needing to trigger on channels which are not always side-by-side.
For example, match staring on channel 5 for: 101XX10
Where we care about states of channels 5, 6, 7, 10, and 11 but don't care about state of channels 8 and 9 so those should be ignored. Suggesting to be able to mask out channels in the match pattern definition with an X (ie X acts as 0 in an AND mask in pattern match)
Not sure if it would be super helpful to others, but I'd be using it right now! I also expect someone some day will ask for fully customizable complex triggers by channel/state like you find in other software analyzers. So may be best to ignore for now if you have any thoughts to revisiting triggers in the future. ;)