More triggers

More triggering options. Let's say I want to decode on a I2C protocol. A very handy trigger will be by Address or Address & Data (like most MSO have). Let's say I have more than one I2C devices on bus, and I'm interested to see only one device (address) communication, writing or reading to a particular register or command. I should expect to see only that particular event captured. Look at the most real time logic analyzers and try to implement those triggers, cause without them we will end up searching the capture, and be limited by duration of that capture.

  • Adi
  • Jul 11 2018
  • Planned
  • larry_c commented
    July 11, 2018 20:32

    Also add a feature like trace before, trace around to the current "trace after" feature.

  • Mark Garrison commented
    July 11, 2018 20:32

    Hi Your flat-headness,
    Our current products all trigger in software, by searching the data as it's streamed over USB. Triggering in software is tricky because ideally it needs to be done in real time, which gets limited based on the processing power of the system, and other factors. We have a basic fallback right now, which allows the product to work even if the trigger isn't running real time, but it results in significant memory usage.
    However, the door is left open for searching existing captures for features, which I would like to do a lot more of. We did add the feature to let you change the trigger settings and then use is as a pattern search for an existing capture. This, combined with the measurements feature, which lets you run statistics over ranges of data on a specific channel, can be used to help find specific features in a capture. I'd love to really expand features for that though.
    In the future, we'll need to start doing triggering in hardware for future product generations though, as I think we're already a little past the limit of what we can expect to do in software in real time.

  • Lord Dimwit Flathead (the excessive) commented
    July 11, 2018 20:32

    Yes, yes, YES! This logic analyzer is very cute and I love the simplicity of the interface. But without more sophisticated triggering, it is little more useful on my bench than my memory O-scope. This is supposed to be a LOGIC analyzer. To anyone that has ever used an HP 124x or DAS, that means I should be able to wait for bit 0 to be low, bit 1 to be high, trigger on the nth rising edge of bit 2 and only sample state when bit 3 is low, high, rising, or falling at my discretion.

    Sadly, I suspect the existing hardware will not support anything close to this level of sophistication. But you might be able to get closer with some small realtime improvements and post-capture processing..... I'll keep watching and hoping...

  • Mark Garrison commented
    July 11, 2018 20:33

    ChrisR, we have trigger on pulse duration now - you can find details on that here:

  • ChrisR commented
    July 11, 2018 20:33

    Or simpler triggers, trigger on pulse duration

  • Kelvin commented
    July 11, 2018 20:33

    Yes, Triggering on and address, block header or even more complex Head-Tail block.