Beta 6.5 available

[gusmanb]

Hi!

It has been a while since I released last version, I'm still working in some major changes and I'm not sure how much it is going to take me to get it completed, so I have decided to release V6.5 beta that include some awaited changes.

• Support for the Pico 2 W. Firmware is available and works like the regular Pico W.
• Profiles! Yes, now you can create your own profiles and preconfigure everything. It will preserve channel settings, capture settings and decode settings. To create a profile first capture something, configure the decoding, test that everything works as you want and then from the Profiles menu create a new one, from now on with a single click you will get everything configured.
• Extended bursts. If burst measuring is disabled now the amount of available bursts is increased beyond 65k.
• Many QoL improvements.
• Many bugs corrected.

Also, there is a new MOS6502 decoder by Emile666, it is also in beta so if you find any problem you can open an issue on its repository.

If you want to help testing this version you can download it here.

Please do not open issues for bugs in this Beta version

If you find any problem with V6.5 Beta please add a mesage to this discussion.

Share your results with the Beta version

I would love to hear from you and how has been your experience with this new Beta.

Have fun!

[Emile666]

I just installed the firmware for my 2x Pico W Wifi devices. I could not find any bugs so far. Loading a Profile is a big help, it saves me the trouble of entering all these channels over and over again. There are a few remarks and they primarily deal with triggering in multidevice mode:

• Pattern trigger First channel is still limited to 1-16. In my case it would be nice to have channels 1-48 available for this. For example: I have !IRQ on channel 47, would love to have the logic analyzer trigger on a falling edge of this signal.
• Would it be possible to trigger on a group of channels, e.g. 17-24 and 36-40? I got my address bus located over different channels. Would be nice to be able to select that (in hex?) and trigger when a value is found. If not, I am going to make a hardware trigger and have this as input for the logic analyzer. But it would be nice if triggering could be done within the logic analyzer.
• My protocol decoder works perfectly with the new version!

Excellent work so far, the screen output with all the digital signals and the protocol decoder on top is just so beautiful to see!

[gusmanb]

• Pattern trigger First channel is still limited to 1-16.
  -- The trigger must always be on the master device channels, and with the PIO triggers the maximum possible ever will be 32 channels even using the RP2350B (the input size of the PIO units), and to maintain compatibility with all the supported boards I restricted it to 16, the channels must be consecutive and on the Zero there are some middle pins on the bottom of the board that I use for the trigger intercom, so I have to limit it to 16. In any case even for the Pico the maximum possible will be 20 because of the pins used by the pico for the led. If you are using only a single pin as the trigger the best is to set it on channel 1, you can sort your channels as you want, there is no restriction that force to have all of them sequentially connected. If it is only a matter of visualization I will try to add to the next version the possibility of reordering visually the channels on the viewer.
• Would it be possible to trigger on a group of channels, e.g. 17-24 and 36-40?
  -- Well... you can connect the pins you want to form the trigger on the first 16 channels 😄
• My protocol decoder works perfectly with the new version!
  -- Really glad!

[RudolphRiedel]

Can we please have a manual trigger as well? Just let it take a snapshot from now to the buffer is full.

[gusmanb]

I will think about it, for now what you can do is:

• Leave channel 1 unconnected
• Do not select channel 1 to be captured
• Set your trigger to a pattern "0" if you use multiple analyzers or negative edge on channel 1 if you use a single analizer
• Press capture

Now you have a manual capture button, and each time you press "Repeat last capture" it will refresh the capture 😄

[DeeJay]

This 'feature' reported against v6.0 on Linux Arm64 seems to have been carried forward into v6.5 beta -

Re: Protocol Decoder Menu

[retested] on linux-arm64 release of LA 6.5 beta under 64-bit RasPiOS Bookworm.

There is a Search box at the top of the Decoders panel at the right side of the LA GUI.

This search option is active and usable when no external LA probe device has been configured, and also when such a device has been specified and connected.

But the Search dialogue box ceases to accept typed input once a Capture has been acquired. (Or Accepted and then Aborted.)

A decoder can still be found and activated by using the drop-down menus below the Search box.

[gusmanb]

This is going to be hard to fix as I'm not able to reproduce it in x64 Debian, Ubuntu nor Windows 11, and no one else has reported the same problem... I will try to change the textbox layout and see if this helps.

[DeeJay]

I can confirm that on Windows 10 the x64 variant of 6.5beta works as expected in respect of the Decoder search dialog.

The issue is largely cosmetic and unimportant to me, but if I can help you to debug on 64-bit RasPiOS Bookworm by proxy then I am willing to help.

[DeeJay]

Thank you for your continued efforts with LogicAnalyzer and for bringing us the beta of V6.5 with support for RPi Pico 2 W boards.

I think I have a repeatably demonstrable Issue with the firmware for Pico2_W_WiFi.

If I use that firmware in non-networked mode (ie. directly tethered via USB/Serial) data capture works as expected, even at 100MHz.

If I configure the Pico_2_W to be a WiFi device and access it in 'Network' mode all attempted captures result in all samples being reported Low. Reducing the sample rate to 100KHz does not improve this.

The same behaviour is observed using either 64-bit RasPiOS Bookworm on RPi hardware, or Window10 on a 'wintel' desktop, as the Workstation to run the v65beta LogicAnalyzer.

(I initially wondered if this was an 'Errata9' artefact on the RP2350 hardware, but the fact that the USB/Serial acquisition is correct seems to dismiss that possibility.)

WiFi connected data capture works as expected using v65beta as the workstation if the probe device is an original RPi Pico (RP2040) W running v65beta firmware in wifi networked mode.

(Tests are being carried out in a 'barebones' config with the PicoW or Pico2W board plugged into a standard breadboard. Not using 'official' LogicAnalyzer motherboards.)

[gusmanb]

Thanks for the report, I will test it this weekend.

[DeeJay]

I have investigated further and reached the interim conclusion that mapping Physical I/O pins to LA channels gets changed if monitoring more than 8 channels.

For example, if I monitor Ch 1-8, a signal presented on Pico2W pin 6 (gp4) is correctly shown as Channel 3.

With no change to the wiring, if I specify a Capture of Ch 1-16 then the signal is shown by LA as being on Channel 11.

The above is the [mis]behaviour in wifi-connected mode. With no other substantive changes, if I change the LA6.5 config to use USB/serial direct connect mode to the Pico2W still running the same Pico_2_W_Wifi firmware, the expected display behaviour is resumed,

{Edit: added later.} A variety of other anomalous channel mappings could be itemised if it were helpful. My ill-informed hunch would be that in the Pico_2_W_WIFI firmware in wifi-networked mode something is going wrong in the mapping of LA channels onto the custom protocol packets used to convey the acquired data back over the network to the workstation running the LA app.
Or, equivalently, maybe the data request from the host workstation is being unpacked incorrectly from the network data received by the Pico firmware.

[DeeJay]

In case it helps isolate the issue, I can replicate the same (mis)behaviour using TerminalCapture to acquire the data from the Pico2W.

I can provide .LAC captures for all 4 test cases ( [ usb | wifi ] | [ la65 | tc65 ] ) if that helps.

[DeeJay]

In addition to the .lac captures I now have a Wireshark .pcapng packet trace of dialogs between a Win10 workstation running LA65 and a Pico2W in wifi-networked mode, demonstrating the 'off-by-8' issue. Are these additional sources of debugging of any interest?

[DeeJay]

And yet more v6_5_beta Pico_2_W_Wifi strangeness. I have just noticed that the 'Channels shifted by 8' error only occurs when using the Capture menu and entering Accept at the bottom right. A subsequent 'Repeat Last Capture' operation flips the channels back to where they should be.

[Emile666]

I have not really found a bug, but merely a feature that could be added. If you set the trigger (in my case the trigger will be a comparison of a 16-bit address bus), would it be possible to trigger on for example the 5th time the trigger is seen? Now it just triggers on the first occurrence, but it would be very handy if the trigger occurrence number could be entered. Don't know if that is possible though.

[MaikuMori]

There are a couple UI things I'd like:

• Zoom with mouse wheel when mouse is over the main capture (adjust samples per window)
• Click and drag at the bottom full capture. In fact, I would even make it permanently pinned and remove the scrollbar as effectively it does the same thing. Then, if you resize the height of the full capture panel, at small height it would effectively become the scrollbar.
• Probably worth looking at video editing tools (DaVinci, etc) as they have somewhat similar UX.

These are just minor things, overall I'm very happy with both the board and the software. I might even be interested in making a PR for some of the UI changes if there's interest.

[DeeJay]

I am just another user, not the Developer, but I can say that your first request is probably implemented already. Try some keyboard 'modifier' keys like Shift, Ctrl, or Alt while you use the mouse scroll wheel. I am not in front of a LogicAnalyzer workstation at present so I can't check exactly which keyboard key(s) are effective. I think this was a feature added in v6.0 of LA, but the documentation hasn't caught up yet.

{Added later:} [Shift] + Mouse Wheel mimics the 'Samples in screen' slider; [Ctrl] + Mouse Wheel mimics the 'timeline' slider at the foot of the screen.

[K5HJ]

II finally received a Pi Pico 2W and swapped out the Pico 2 that was on my board.

First, I tried it with the non WIFI version of 6.5 and everything works fine. I noticed the the max sample rate is only 100MHz as opposed to 200MHz on the Pico 2. Maybe this is a limitation with this board or it will be changed in future builds?

Then, I flashed the board with the WIFI version. It connected to my network and I did a capture. That was good to see. I then tried to see if it would work without USB serial, using a power only USB cable. No joy. It would not connect to my router. I also noticed that when I changed the reference voltage switch, the board goes through some sort of reset and no longer responds. If I put the USB data cable back on, it will allow me to connect to the board via a COM port but it won't capture. The reference voltage switch still does the weird "reset" and the COM port disconnects. Each of these "resets" causes the LED to go off and back on after a few seconds. I tried to change the WIFI settings to a different IP address but the board will not accept it.

I used a flash "nuke" download to erase flash, reflashed the app and nothing helped, After trying this a few times, I gave up.

If I flash the non-WIFI version back in, it works again using the COM port connection. Switching the reference voltage does nothing unusual.

I am truly puzzled as to why the WIFI worked one time and that was it. Very strange indeed.

Hope this provides some information for your development.

[idwpan]

Hi, do you accept any PRs for v6.5? Not sure what the state of development is here...

I added some code to allow configuring the min/max displayed samples because the other day I was struggling with sample rate and post samples to display my whole trace on screen. Also added a tooltip to the slider to show the number of samples.

https://github.com/idwpan/logicanalyzer/tree/add-slider-settings

I can open a PR if interested.

Thanks for your work, this project works more reliably for me than uLA + PulseView.

[gusmanb]

Hey! Sorry for the silence, i've been on vacations and got back yesterday :)

I will try to start checking this on the weekend.

[DeeJay]

For my part there is absolutely no urgency.

We are all entitled to "vacaciones anuales de verano".

[arwidcool]

@gusmanb Can you get in touch with me? I make an integrated version and wanna discuss some things with you before releasing it :)

[RudyRetroIntel]

Hello everyone!
I have been using this BETA 6.5 version and have not found any issues as of today. Love the profile feature!! I'm running this version on a PICO2 (non WIFI).

I would like to make 2 visual recommendations:

1. It would be great to have the whole right side panel hidden, if wanted. This would give greater viewing of the signals.
2. Have the "Sample in screen" as a slider up and down instead of left to right. This would allow you to add it to the top of the screen with a pull down. Again, this would give more screen for the signals. Just my thoughts.

Love the product and this new version is amazing with saving\loading profiles!

One more question for Dr Gusman. I would like to know if I can sell your boards on a website. Of course they would be built at PCBWay. Please let me know as people are asking me about that.

Finally, could I get permissions to show off the Logic Analyzer with BETA 6.5 software in a YouTube video? I know my subscribers would live it. I have made an interface board for the Apple SE30 computer, call "Peeker", and it has pins for monitoring CPU signals. This works great with this board and definitely helps with the SE30 repairs.

Thanks,

Rudy
Rudy's Retro Intel

[RudolphRiedel]

I just connected the V1.1 of my 8x board and played a little checking an SPI and I have a suggestion for the 6.5 software:
add the frequency to the tooltip that is shown when hovering over a signal.

Just use the the next pulse, regardless of high or low, and calculate the period from that.
Perhaps check the duty cycle and do not display the frequency if is not within 1%...99%.

[gusmanb]

Check the wiki 😃

[RudolphRiedel]

Checked the wiki and it really took me a while to figure this out.

So, there is a context menu that has a "Measure" option.
"For this we will use the context dialog from the sample marker."

Could at first not even figure out what this means, got no context menu.
Then I searched what "sample marker" means and found that you can mark a group of samples on the top and when you right click on it you get the mentioned context menu.

Ok, that is not only well hidden in the UI, but at lot more difficult to use than what I am asking for, that requires precise selection of the samples, can't be off by one, a right click to get the menu, a left click to open and then some scrolling to the channel I am interested in.
At this point I could as well fetch the calculator.

Would be a bit easier if you could select the samples directly from the channels.
Well, and even easier if the tooltip would just display the frequency.

Another observation, zooming is handled a bit oddly.
On the one side you can zoom with the "Samples in screen" display, this works without key qualifier, when you move the mousewheel up it increases the number of the samples displayed which effectively means that you are zooming out.
When you use the mousewheel over the channels display it moves the channels up and down.
When you use the mousewheel with CTRL over the channels display then the display is scrolling,
right for up and left for down.
When you use the mousewheel with SHIFT over the channels display then the view is zoomed, up for out and down for in.

How the mousewheel is supposed to be used like in software is that you move up/down with the mousewheel up/down, when you press SHIFT you move left/right instead.
And when you press CTRL then you zoom in for up and zoom in for down.
Examples? Firefox, LibreOffice, Altium Designer. I believe this is somewhere in Microsofts UI guidelines.

So you have SHIFT and CTRL and the directions "wrong" as in these are supposed to work differently.

Yes, totally first world problems. :-)

[gusmanb]

Well, if you think a second, you are asking for an impossible... the tooltip shows you the period of what is under it, to have a frequency you need a wave, so you need both periods, so now, what you want? the current period plus the next one or the previous one? I'm sure that whatever you answer, someone else will think the opposite, so at the end the only proper way to do it is to select at least the two phases of the signal to get a frequency... And you don't need to be really precise, select a bunch of periods and then the predominant frequency will give you what you look for, the "left overs" will vary the average, yes, but the predominant frequency will be the right one. And of course, you can argue that with one phase you could infer the frequency... but only for a clock or similar, anything which its periods aren't simetric will yield nothing but wrong values. PWM signals? Wrong. Manchester encoding? Wrong. Anything but a clock will be wrong.

Regarding the zoom, I would argue that you aren't changing the zoom but the ammount of samples on screen, the bar is called "Samples in screen", not "Zoom", so up/down is correct :)
In any case is a trivial change that I can do, but I'm 99.99999999% sure that someone will complain that using the wheel over the bar is working reversed... xD
Regarding ctrl/shift, I can change it, no problem :)

[RudolphRiedel]

As I wrote, just use the next period, if there is one, does not need to be perfect. :-)
And what I got when not selecting correctly was all over the place, the frequency is 10MHz and the measurement told me 14.xxx MHz,
perhaps this is not calculated for a period, but across all samples selected?

I would try to change SampleViewer.axaml.cs myself for the tooltip to feel the pain, but I have no idea where to even start to try to build the software, if that is actually is possible.
I do not do Desktop, I do Embedded, I do not even have Visual Studio installed. :-)

As for the zoom, or not zoom, I would remove the "Samples in screen" display completely.
Well, it could be displayed in the "Information" section, that number does not really mean anything though.
Samples is how this all works internally, I am currently looking at 460k samples in total, but that information means nothing to me.
I can hover over a waveform and the tooltip tells me that this segment is low for 23.84µs, this is the interesting part.
The tooltip also tells me that this segment has a length of 1192 samples which is useless information.
What the user needs to be aware of is that the sample-rate is defining the length of the samples and therefore the quality of the time measurement is improved with a higher sample-rate.
In this regard the "Frequency" that is displayed right now with 50MHz is not even the frequency, it is 50M samples per second.
And that also means that the time between two samples is 20ns.

Ok, I digress, and this is obviously not something that you did not know. I am trying to view this from the user perspective though.
And part of that is that I have seen way too many claims now that also with a logic analyzer you are fine if your sample rate is at least twice as high as the frequency of the signal, classic Nyquist–Shannon, only that Nyquist–Shannon does not apply when your goal is to not only see the basic 0/1 information, but details in the timing.
So educating users that the time measured has a resolution of 20ns would be a good thing.

Having played some more I also noticed that the limit of 10000 samples on screen is not enough for my application, I am looking at SPI frames sent to a display and I had to half the sample rate in order to see a full update frame with now 7095 samples in length.

Now zooming has another "issue", it is not using the mouse pointer as position if over the waveform display or the center of the waveform display, looks like it always zooms in on the left of the screen, so what you want to zoom in on has the tendency to move out of scope.

Another thing is that zooming with the mouse wheel is going by half the samples per step, so it currently drops from 10k to 5k, then (probably) to 2k5, 1k25 and so on.
Going with the keyboard it changes at a fixed rate of like 10 per click.
Have you considered of doing that more dynamic and using the same steps for keyboard as for the mousewheel?
Maybe, use 10% down / 11% up in terms of samples currently displayed as the modifier for the zoom with both the keyboard and the mousewheel?

And the why I was zooming, I tried to find the time between CS going low to the first high on SCK, eyeballing that from the top of the screen down to the waveforms is not easy. Even less so when you are looking at the SPI from an ESP32 which takes forever in comparision to the bit times.

[RudolphRiedel]

But according to your post you had to have thousands of samples to avoid the problems so...

No, not to avoid that problem of sampling slower than expected, that works with way less postsamples, however the measurements make way more sense when they are done for frames or packets of frames. That gap of 5ms shown in the screenshot is as expected.

[gusmanb]

Then this is again a case of not reading the documentation :)
As explained in the triggers section the burst takes at least 1 sample to rearm and that also may lead to a desync of half a sample.

[RudolphRiedel]

Then this is again a case of not reading the documentation :)

No, not again, still the same and I am already past that, I am not using way too low postsample values anymore. :-)

[gusmanb]

Sorry, no, you don't get it. When you set the samples to 10 each 10 samples there will be a sample "lost" because of the rearming of the trigger mechanism and there can be half a sample of desync, so that explains the "longer" phases you were seeing, so yes, it was again a case of not reading the documentation :)

[RudolphRiedel]

Yes, I did get that, this is why I am not doing it anymore.

[gusmanb]

Beta update

I have uploaded a new version that should solve the W2 WiFi problems, there was an error in the WiFi transfer routine and was using the incorrect buffer size so it was a hit or miss situation were it could send random blocks of the real buffer capture... :P

The new version also changes the behavior of the mouse wheel and the modifiers to accomodate more to the normal zoom usage.

Also, I have included some tests @DeeJay to try to find what is wrong in the pi version. First, if the textbox gets blocked, can you check if the background gets red? I know that the search and clear icons are now red, this is intentional to check if by any chance these are somehow changing their size and blocking the input. If it is not the case, try to press the "X" button and see if it reactivates the textbox and allows you to write.

The new beta is in the same link, remember to download both, the new software and the new firmware.

[gusmanb]

Yes, the changed firmwares are the WiFi ones, the non-wifi versions stay the same so no need to upgrade it.

[RudolphRiedel]

Yes, still works. :-)

[DeeJay]

" a new version that should solve the W2 WiFi problems, there was an error in the WiFi transfer routine and was using the incorrect buffer size"

To confirm what I wrote previously: the Pico_2_W in wireless-networked mode now seems to work reliably. Have checked with 8, 12, 16, 24 sampled channels, and at 100KHz and 100MHz sample rates.

[DeeJay]

"some tests to try to find what is wrong in the pi version. First, if the textbox gets blocked, can you check if the background gets red? I know that the search and clear icons are now red, this is intentional to check if by any chance these are somehow changing their size and blocking the input. If it is not the case, try to press the "X" button and see if it reactivates the textbox and allows you to write."

In respect of the release in all-in-one_6.5.0.0-beta2-linux-arm64.zip

I can see the Search and Clear icons in Red. Text entry box is a dark field, with a blue border.

A newly-discovered minimal trigger. On first opening LA65 the Decoder dialog is normal. Without Opening a probe device, simply invoke HELP / ABOUT and dismiss the resulting pop-up. Text entry to the decoder search is now blocked. Appearance is unchanged. Red icons, dark field, blue border. The Clear icon does not fix the issue.

After OPENing a probe device, other reproduceable triggers include displaying Device Information ( (i) ), or performing a Capture.

(To emphasise: this report is for feedback, not to insist on a solution. I regard the issue as trivial/cosmetic since a Decoder can still be applied via the decoders drop-down menu selection.)

[gusmanb]

I got an RPi 5 today, so I will try to test it this weekend, I'm really puzzled on what can be happening...

[YellowDog70]

Hi!

I am developing a USB adapter for the parallel port of an Amiga computer to copy files between PC and Amiga.
It would be nice to see the value of the 8 data lines at the same time, what byte is being transferred, is there a way to combine the data of 8 channels and show it in bytes?
If there is no such possibility, is such a development expected?

Thank you in advance for your answer!

[YellowDog70]

Thank you very much for the answer, this is good information for me!

[RudolphRiedel]

And tip, the decoders are written in python, if one is not working as you need it to, you have at least the chance to modify it.
I modified the SPI decoder for me, added a new option that when selected stops the decoder to display information I found to be redundant.

Amiga and PC, back in the day we used serial. :-) Well, no COM: ports either anymore, but at least USB/serial is a bit more common.
Today I would check what options are available to use SD cards.

[YellowDog70]

"Amiga and PC, we used to use serial ports. :-) Well, COM: ports are gone, but at least USB/serial is a bit more common."

Yes, it was, but the serial port is very slow, so I chose the parallel port. The theoretical speed is 709kB/s, but due to the protocol it will only be a fraction of that. My first attempt was an FT245 module, this is a parallel - USB adapter that appears as a serial port on the PC. The server runs on the Amiga side and TotalCommander (with modified Serial 2.0 plugin) under Windows, through which I can access the files on the Amiga side. I achieved a speed of about 180kB/s with it, now I'm trying to achieve higher speeds with an STM32F407 development board, here I have the opportunity to optimize the parallel port communication and achieve higher speeds. I hope I succeed :-)

[RudolphRiedel]

Well, this is becoming way off-topic, so have fun with that project! :-)

[YellowDog70]

You are right, thank you :-)

[eositis]

working on an adapter board for the 6502 in an Apple, and using 6.5 for testing the adapter - the profiles feature is excellent for this. I would like to share a profile with one of my testers. How can I export the profile from the SW and subsequently, how can the tester import the profile? No menu item for this, so I am assuming the profile is stored somewhere in the software tree.

Thanks

[gusmanb]

It should be in $HOME/Library/Application Support/LogicAnalyzer, there is a file called "profiles.json", copying that file will carry all the profiles from one machine to the other.

[eositis]

Thanks!

[eositis]

in the process of testing a 6502 processor adaptor for LogicAnalyzer using the 6.5 beta and the mos6502 decoder, one of the testers has run into an odd situation. When using pattern detection on a multi device, if the pattern to detect is 01, the LA will trigger when it senses zero, not 01. However, if the pattern is changed to 101, capture works correctly. almost.

use case for pattern 01 - catch system activity at power on. i.e. start data capture when reset line goes high. Theoretically, If pattern 101 is entered, then it will never capture the system start, as there was no high when there was no power. In the 01 pattern case, the trigger fires when it confirms zero level, not waiting for 1 to be achieved. If 101 is used for system start, data is captured as soon as reset line goes high - even though an initial high state was never seen. e.g. high-low-high

last, we have not yet identified the pattern, but after a while, one or both of the LA in the chain will start to ignore the trigger and capture data as soon as the instruction is sent off to the LA boards. If the slave gets into this state and there is a relatively long delay waiting for the trigger, it returns blank data. If the master breaks, then the data capture runs immediately upon submit and returns data from both LAs.

The observed behavior has been confirmed on both a windows deployment and a MacOS deployment. LogicAnalyzer boards are configured with the original pico. Uploaded two files one for case 01 and one for case 101.
case01.lac.zip
case101.lac.zip

[gusmanb]

You are using the pattern trigger incorrectly. The pattern is not for a channel in time, but an instant in a set of channels. "01" does not mean "wait for a zero in the specified channel and then wait for a 1 on the same one", it means "start capturing when channel specified as first is 0 and the next channel is 1", for example if starting channel is 6 then will mean "start capturing when channel 6 is 0 and channel 7 is 1".

Regarding the chain, has this happened to multiple users or only one? I'm asking because this could be a bad case of the GPIO bug, the device includes a resistor to "clear" the bugged GPIOs but may be the case that if in this particular unit the GPIO is way out of spec the resistor is not enough to clear the problem, haven't seen it ever but it's a possibility.

If you can, check the voltage at GPIO1 in the slave whenever this is happening, if on rest you see a voltage in the GPIO (anything that is not zero, usually stuck GPIOs get around ~2v) then the GPIO is stuck and the resistor is not enough to clear the situation, changing it to a lower value can solve the situation, will drain a bit more power but should solve the problem.

[eositis]

For the pattern matching... I have not found a way to add a 2nd channel for matching. In my MacOS client, only First channel is offered and there are no buttons anywhere to add a 2nd or more channels.

When the LAs start to misbehave, will take a look at GPIO1.

Digging further through the manual, the context menu for analyzing samples, editing, etc. also cannot be found. Below is a typical data display. No menu item for protocol analyzer, that is permanently on the right side.

Thanks

[gusmanb]

For the pattern matching... I have not found a way to add a 2nd channel for matching. In my MacOS client, only First channel is offered and there are no buttons anywhere to add a 2nd or more channels.

You select at wich channel the pattern starts and then is sequential, you don't select more channels, the pattern determines the channels.

if you start at channel 6 and set the pattern "10" then channels 6 and 7 are used, if you use the pattern "1011" then channels 6, 7, 8 and 9 are used.

Digging further through the manual, the context menu for analyzing samples, editing, etc. also cannot be found.

Is a context menu, and like any other context menu is invoked using the right click.

[eositis]

oOOO! now I understand the pattern match. was not clear in the documentation. We understood the pattern to be as observed on the specified channel, not specified and subsequent channels. Thanks. Also means I have to make a change to the channel assignments to make sure all 16 address lines are in sequence. This would then allow matching a specific address accessed.

Found the context menu. Thanks!