@markgarrison
I am using a Logic Pro 16
Sampling I2C , at 50Ms/s , threshold at >3v3 volts and still sometimes I see 0.2us spikes, the clock period of the I2C is 10us.
So yes, this is annoying for analysis, borderline a defect.
When bothered by this (usually by getting annoyed by data that does not make sense or checksums that does not match, I solved this a few times by adding a 3-sample filter.
I do feel that this should be solved on a hardware level, but for some applications, like I2C , signals at with known timing, detection and mitigation could be even done automatically. (knowing that this I2C screenshot should not contain any 0.2us high’s)
can I say again that this is a nasty hardware issue ? - done. please take care of it.
You wrote: “If we had a maximum limit of 10ms or 100ms for the glitch filter, would that be a problem?”
no , I did not even dream such long lasting “glitches” could ba a problem (unless you think of a very slow sample-rate), in most of what I do , such anomalies would be a complete disaster.
Loving the 2.1.0 release! What a long ways this software has come.
I’ve been using it for a couple days now, and I love that I can make the channels narrower (vertically) so I can cram more of them on a screen at once. Fantastic. Honestly, I’d love it if the digital channels could be compressed even further (vertically):
There just seems to still be quite a bit of vertical space on the trace display that’s “wasted”.
The other thing I’d sincerely appreciate would be the ability to hide the “channel name” column on the left (like you can hide all of the capture settings and analyzer stuff on the right already - so awesome!). Sometimes having those names there is really important, but much of the time I’d prefer more horizontal space for traces rather than the names. What if that whole column were re-sizable (like columns are in Excel) so you could expose as much or as little of the ‘channel name’ as you wanted?
The analyzer terminal looks just brilliant - I haven’t used it much yet, but based on past experience it’s going to be very appreciated.
Thanks, I’m glad to hear that you can tell the difference
The “wasted” space is used for showing the measurements. Would you like to be able to turn them off and remove this space? (You can turn them off even now but it won’t affect the spacing)
The channel name column will be resizable soon. It’s on our roadmap, which we’re planning to share here soon as well
+1 for Python analyzers. Have you considered making the API compatible with the sigrok API? Then we can get access to hundreds of additional analyzers.
Yeah, I guess it would be ‘nicer’ if that space only got used if there was in fact a measurement that needed it. But I’m not sure how smooth an interaction you could make that would create space when needed, but not be intrusive. It’s not that big a deal.
Using it on windows i could not stop a running capture by pressing the stop button even if the set time expired.
On Linux this worked but i have another question:
Is it possible to adjust the voltage scale at analog capturing?
Like it is at ±13V and my captured signals are at ±3V so there is a lot of unused space
I’m sorry about that. Can you provide us some more details? Does it happen every time? Which device are you using? What capture settings are you using?
Is it possible to adjust the voltage scale at analog capturing?
You can zoom in using Ctrl + scroll up on the channel. We’re planning on adding “auto-fit” that will do that for you.
I was using a Logic 8 device.
I was capturing serial data at 115k2 baud rate with 1MS/s for a set duration of 5 seconds.
After the 5 seconds expired or pressing stop button it looks like this:
Internally I’ve been discussing this with Joe, the CEO, after your last message. There are 3 levels of fixes we’ve discussed. Realistically it would be great to solve this on the FPGA level, but in the near term we’re going to have to stay with this SW based solution.
The ideal solution, which we’re planning on putting into the next generation hardware, would be to include two high speed comparators for each digital input, one connected to an input-high reference voltage and the other connected to an input-low reference. (both controllable via DACs). This way we could precisely mimic the I/O standards used by almost every single-ended IO standard. (e.g. 5V cmos has different thresholds than 5V TTL, etc). There are also comparators with configurable hysteresis, but back when we designed the pro devices, it wasn’t available on the comparators at the speeds we needed.
The best solution for existing customers would be to implement an always-on, 2 sample glitch filter in the FPGA, at the 500 MSPS speed before we downsample the signal. The advertised bandwidth limit of the device is 100 MHz, so a fixed, 2-sample wide filter would still allow for the high bandwidth while eliminating all single sample glitches.
The FPGA glitch filter could also be variable based on the decimation rate, which would make it functionally similar to an analog anti-aliasing, decimation filter.
The biggest problem with doing the glitch filter in software is that at lower sample rates, we can’t differentiate between valid single sample states (e.g. 1us at 1MSPS) and glitches (2ns).
We need to discuss this a little more internally and we’re not at the point where we’re ready to commit to making the FPGA changes in the near term, but I did want to get some sort of reply, so you are aware this is an issue we take seriously.
please take care of it.
