Ideas Test

5 VOTE

Show time-of-day on log/in decoded trace

Saleae probes are great for running extended traces. Though the time on the trace and on decoded buses is only relative to the start of the capture -- not much help if you're trying to correlate this to other logs captured on the computer that have timestamps of the current day/time.

Could we include a time-of-day rather than just seconds from start of capture?

E.g. for the bus decoding.. instead of:

Time [s] Packet ID Address Data Read/Write ACK/NAK
11.3167523 0 0x10 0x01 Write ACK
11.316798 0 0x10 0x02 Write ACK
11.3168437 0 0x10 0x02 Write ACK

Could we have:

Time [hr:min:sec] Packet ID Address Data Read/Write ACK/NAK
12:02:27.5655 0 0x10 0x01 Write ACK
12:02:27.5815 0 0x10 0x02 Write ACK
12:02:27.9811 0 0x10 0x02 Write ACK

At the very least, a record of **exactly** (time/date) when the trace was started/stopped?

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Jun 26 2018
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 26, 2018 18:34

    Accuracy is important, but it matters more that know when in real time the capture was made. For example if I am looking for state change events that only happen during a glitch that can be hours or even days apart, wall clock time is important.

    Also, if I know when something happened in real time, I need to be able to see what was going on in the trace at that point in time that matches.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 26, 2018 18:34

    Thanks, I agree completely. We've actually got quite a few requests like this coming in recently, and we're pretty sold on this idea. I just can't provide a public announcement on when this will be done yet, but feel free to check back in a couple months. We might have some updates on this progress then.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 26, 2018 18:34

    @ Tim Reyes:
    I suggest to round the real time to the nearest second (or e.g. thenth of a second or some other sensible amount) on begin of capturing and use this as an offset for displayed time as per user's individual check mark decision. Then, I think, accuracy shouldn't be a problem.
    I don't know, but I assume that one can get real time by an OS call without virtual any dire straits.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 26, 2018 18:34

    Please reconsider this, the wall clock need not be micro-second accurate for the start of the trigger.

    As for setting a realtime clock in the logic you only need implement a NTP like algorithm.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    June 26, 2018 18:34

    I think that's a great idea and I could definitely see it being useful. Also, a similar request has been submitted as titled below:
    "Add more capture length time options"
    http://ideas.saleae.com/forums/214303-saleae-ideas/suggestions/5946067-add-more

    As much as we would love to add this, right now, we don't feel that we can do it at a high enough accuracy, but we are continuously monitoring the interest for this feature. Thanks for suggesting!