Trigger in hardware instead of software.

If you need to trigger on a rare event, there is no reason why the software should be parsing the ongoing data looking for the trigger. The software should tell the hardware what event to look for, then let it handle the trigger.

With the current method I can only sample at 5MS/s when triggering on 1 channel for continuous running without the memory footprint going up forever. If the trigger was in the hardware, it could sit there for days at 100MS/s looking for the trigger.

  • John Vickers
  • Jul 11 2018
  • Plixo commented
    July 11, 2018 21:10

    +1 on this, and having a stop trigger would allow for example to let it run and jut get the specific time frame we are looking at

  • Adrian-Autoliv commented
    July 11, 2018 21:10

    Ideally, there'd be a separate pin - SYNC_IN - that could be configured to start/stop the sample clock.
    I'm using Logic Pro 16 with a 16-bit micro and I'd like to be able to synchronize the internal logic pro 16 sampling clock with a bunch of other Vector CANtech measurement IO stuff.

    Having the SYNC_IN line be separate from the other 16-pins would be best so that I can use the full 2bytes worth of pins to bit-bang my protocol.

    Of course, the SYNC_IN line might as well be dual-purpose and be used as a normal digital input too.
    And while you're at it, ... adding one more channel - total of 18 - would be good so that I can use the 2 extra bits for CLOCK and FRAME (chip select) signal.

  • rchapman commented
    July 11, 2018 21:10

    +1 on this as well. It would also be nice if you had a live mode and only start storing data when a trigger event has been met.

  • ahamilton commented
    July 11, 2018 21:10

    +1 on this. And adding state triggering to allow a sequence of events to trigger the analyzer would be a big plus.

  • Guest commented
    August 05, 2018 06:28

    happy to sacrifice the use of 1 or 2 pins for a physical start stop trigger function...