Analog export timestamp does not match capture


When I export analog data from a Logic 2.3.19, the timestamps in the CSV file do not match the times shown at the top of the capture file. For instance, in the screenshot below, the capture shows a sample of 1.568V at 0s : 82 ms : 670 us : 500-ish ns. However, the CSV file (row highlighted in yellow) shows the same sample at 0s : 82 ms : 592 us : 320 ns. My data was sampled at 12.5 MS/s with 4 analog channels (I am only exporting one of these channels).

I have also tried exporting binary data and implement some C# code following the Python example, and arrive at the same result as the CSV file. I tried calculating the sample time using both Single and Double with the same result.

Is this a bug in Logic 2.3.19, or is there something else I need to change in my export to get the timestamps correct?



1 Like

Thanks for reporting this. This is certainly unexpected behavior. I tried reproducing this on my end and couldn’t. I checked samples at the beginning and end of some sample captures I took and the time stamps were all correct in the raw data export.

I’d like to get a support ticket open for this, and I can give an upload link via email so you can share your capture file (.sal file) privately with us.

Can you attach your .sal file below? As a first step, I’d like to see if I can reproduce the issue at the exact same time point you shared in your image here.

In the “description” section, please share the link to this discuss post and direct the message to me (Tim). That way, I’ll know it’s you.


I attached a different (smaller) capture that shows the same issue, along with a few CSV exports and screenshots showing the same behavior under a couple of different conditions.



Thanks @dybalabj . I got your files and support ticket over here. We’ll review this bug in the meantime. We can continue our conversation via email.

I just stumbled over the same issue in Logic 2 Version 2.3.36.

@florian.exner Sorry about this. Unfortunately, it doesn’t look like I provided any further updates on this forum post. Let me look into this and check to see if this was in fact solved. I’ll run some tests on my end and let you know my findings.

@florian.exner I ran some tests over here, as well as looked into our backlog for software bugs and it does look like we had this bug fixed. Can you let me know the following?

  • Is the issue reproducible in 2.3.37? Download link below:
    Logic analyzer software from Saleae

  • Can you provide detailed steps on how to reproduce the issue?

  • Photos/videos of the issue would also help tremendously.

Looking forward to hearing back.

So this is what I did this morning:

  • updated to 2.3.37
  • opened a previously recorded *.sal data file. The file contains 1 analog trace and 2 digital traces.
  • put down two markers to extract the data inbetween (see screenshot in *.zip archive).
  • I exported the data inbetween the two markers as csv
  • I open up a jupyter notebook and plot the extracted traces (see html file in *.zip archive)

This issue is not limited to the current file, but is present in all my recordings (at least done with the same setup). From the test setup I can tell you that the way it is displayed in the Logic 2 software should be correct, and the lag of the digital signals in the *.csv output makes no sense to me. (169.4 KB)

@florian.exner Oh wow… the time shift is quite clear in your html file.

  1. Can you share you .sal file with me?
  2. In your .sal file, can you include the two timing markers?
  3. Can you share the exact options you select for when you export your data?
  4. Can you perform the export, then also send the .csv to us?

In case any of this information is private, feel free to send these via the link below, and include a link to this discuss post in the Description section so that I know it’s you. Once that message comes in, in case the files cannot fit as an attachment, I can send you a private upload link via email as well. (1.1 MB)

Here is what I did:

  • I placed the markers T0 and T1.
  • In order to reduce filesize I then cut some examples from the original file with the markers. While doing that I created a file that did not exhibit the issue after exporting (saleae-timing-issue-tightcut-noissue.sal).
  • So I made two additional cuts: one with about the same length (saleae-timing-issue-tightcut.sal) and a longer one (saleae-timing-issue.sal). But these files show the aformentioned issue.
  • I then exported the data inbetween the markers (settings shown in export-settings1.png and export-settings2.png). The *.csv files can be found in the subfolders 2.3.37_test2 for saleae-timing-issue.sal, and 2.3.37_tightcut for …-tightcut.sal, and subfolder …-noissue for …-noissue.sal
  • My plotting of the *.csv files is shown in the *.ipynb and *.html files

I did also do another test:

  • I exportet the whole file (not inbetween markers) to *.csv. The timing between digital and analog is wrong here, too. So I assume it is not connected to the markers.

@florian.exner Thanks for sending that over. There’s quite a lot to unpack and review here. I’ve scheduled a meeting with our software team later this week. I’ll keep you updated on our findings.

@florian.exner Oh wow… we ran some tests with your saleae-timing-issue.sal file. The issue was quickly seen in the export csv just by comparing voltage values at a specific time point. I’ll continue to keep you updated. This definitely looks like a bug.

@florian.exner I had a chance to discuss this further with the software team. Sorry for the trouble with this bug. I did want to let you know that this is on our priority backlog now. We plan to fix this as soon as we can!

@florian.exner @dybalabj The fix should now be implemented in the latest version of the Logic 2 app — v2.3.39. You can download it below. Let me know if you continue to run into issues with it!