Be able to save a capture and compare it to another. Basically, compare two tabs to each other, one above the other. Be able to slide them forward/backward together or independently to line up where you want them to be. Zoom should also be independent or together.
Bryce Nesbitt Jul 11, 2018
See also for a workaround
Bryce Nesbitt Jul 11, 2018
Just the ability to set a numeric zoom level (or in scope terms "set the time per division"), would go a long way. If I can enter "40ns" in each capture, I'm 90% there.
Though really I'd want to pick a reference point in each of several captures, and then be able to flip between them, keeping the reference point stable.
Mark Garrison Jul 11, 2018
This has been on our back burner for awhile, and something we'll keep in mind during the upcoming architecture update.
I can see how it would be nice to compare captures on several different levels:
just the protocol level - where do bytes change. potentially where packet timing changes.
At the timing level - assume two signals should be identical, after using some way to synchronize them - either by using the trigger as the same point in both, or by allowing the user to slide one capture relative to the other.
I think there would need to be a user selectable tolerance level for differences too, since sampling error alone can introduce small differences between different captures of an identical signal.
I would love to get more input on use cases for this.
My current thinking for this family of features start with the following:
1. the ability to clone an existing channel.
2. the ability to add an arbitrary time offset between different channels on the same capture.
3. The ability to move a channel from one capture to another.
4. support grouping channels to make this easier.
These should cover the following situations:
1. the ability to compare events from two different captures, by taking a channel from one capture to another, and then applying a time offset to align the area that you want to compare.
2. the ability to compare an event on one channel to another event on another channel in the same capture, that occur at different locations in the capture. For this, you would just offset one of the channels until the events were aligned.
3. The ability to compare two events that occur on the same channel at different times. To do so, the channel would be duplicated, and then a time offset would be applied to the duplicated channel, to align the two instances of the event.
The part where we start annotating the differences is pretty exciting too, and I would love feedback on both parts.
PaulZ Jul 11, 2018
This would be very helpful, especially for regression testing against previous designs (I use a Logic16 Pro to measure output timing of FPGA I/O). Reasonable requirements would be the signals, timebase, and capture length are the same. Perhaps show both versions of each signal, and highlight differences using change bars.
Tom-tech Jul 11, 2018
Exactly what I'm looking for, switching between tabs only gets you so far unfortunately.
Is there any update on this being a feature?
DanDan Jul 11, 2018
I guess adding this feature is tricky and not always possible. For instance when duty cycle for asynch signals and frequency for synch signals are too different, then keeping two channels for comparison is impossible. But, for signals with same frequency, this could definitely be helpful and very straightforward to implement I can imagine.
Anyhow, I would prefer to have freedom to:
1. Disconnect a channel and store all gathered data there.
2. Disconnect an instance of Logic program from device to be able to open a new one, when I have information on all channels that I don't want to loose.
I would also like to have a feature where I would be able to generate signals on a channel. For example, lets say that I am able to measure I/O line in an USART communication bus, but I do not have access to the clock pin by any reason. Then I would measure just I/O using logic analyzer and simulate the clock by generating signal artificially at software level to make sure the data is sent at the desired baudrate. This has happened several times for us, when we were not able to access the clock pin in a Secure Access Module (SAM) card holder, whole data pin could be accessed easily.
qwerty Jul 11, 2018
Please, please, please,please add this feature. It would make this such a usefull tool.
wholder Jul 11, 2018
Yes, yes, yes. I vote for this. I was recently trying to analyze an issue with serial data where I needed t compare one capture to another. I wound up making screen captures and trying to compare them, but I was unable to get the zoom settings to match up very well. Plus, I could only look at a small section of data at one time.
pk Jul 11, 2018
I posted a similar comment on the real time feature request. This is a widely used feature by people who use oscilloscopes. If you are planning to add the oscilloscope feature this feature should be considered along with it - otherwise the oscilloscope feature is incomplete.
Rafael Jul 11, 2018
I just need to overlap two captures to compare the results!
Martin Jul 11, 2018
Even if you just provide a means to set the "X-scale" in an input-field (say number of seconds displayed on the X-axis) on each tab separately it would be already an improvement and would allow comparing tabs (by switching)
Right now the scales are quite random and it is hard to control (mouse-clicks zoom in/out by a different factor then +/- - at least on OSX!)
Being able to see multiple tabs concurrently (maybe different window or a separate "read-only" process of logic for saved files) would be ideal.
NathanC Jul 11, 2018
Even without 'automatic' compare capabilities - having two waveforms on the screen at the same time to troubleshoot why one is working and one is not would save a lot of flipping back and forth. If I could just open the tab in a window and arrange the two tabs above/below each other that would be a nice step forward.
Jan Kok Jul 11, 2018
I'm currently working on a problem where this feature could be useful. I can talk to a SPI device in one scenario but it fails in another scenario. I'd like to compare two traces and find the first difference.
As Anton said, "But the timeline scales would never match. " Yes, but I think the protocol analyzers could help a lot to find the first logical difference. For example, the SPI analyzer could compare MOSI and MISO data only when ENABLE is active. The analyzers could ignore irrelevant differences. The analyzers could also provide operations like "scroll to the next (or previous) data byte in both waveforms" or "scroll to the next/previous rising/falling edge of the XYZ signal in both waveforms" etc.
They could also scroll to the next protocol error in either waveform.
I'm sure this would require a lot of software development, but yeah, I sure could use this feature right now!
KisCsillag Jul 11, 2018
Simple difference in SW would be possible, mark regions with red where it differs.
Boris Jul 11, 2018
Compare of analyzer output texts (right bottom frame of application) will be great too. Logically follows from waveform comparison.
And some math operations with saved analog data, for example subtraction of two waveforms...
Anton Jul 11, 2018
Yes! And scales should match too! I would open two software windows, live project in one and saved in another to do visual data comparisons. But the timeline scales would never match.