Is there a way to get ACK when the capture starts

Logic 1.x (Legacy) Software
1

This question has been cross-posted as issues on the GitHub repositories of the C# API and the python wrapper.

TL;DR Is there a way to start a capture and get an acknowledgment for when the capture starts?

The problem, roughly, is the following: If capture_start is called and a signal arrives at the recording device, say, a nanosecond later, will that signal be recorded? Probably not. What about a second later? Probably. I would like to know for sure, in other words, I would like to get an acknowledgment which, one received by the host, guarantees that the recording is running. I’m fine with waiting a couple of seconds. So, for example:

handle = s.capture_start()
# The recording may or may not be running at this point.
handle.wait()  # Blocks until the capture was acknowledged by the logic analyser.
# Now the recording is guaranteed to be running.
time.sleep(1.0)
s.capture_stop()
# The recording is at least 1.0 seconds long.

It appears to me that the socket/C# API does not offer this capability. For example, the docs have this to say about the capture command:

Socket Command: capture

This command starts a capture. It will return NAK if an error occurs.

The function will return ACK when the capture is complete.

I find this quite frustrating, as the only alternative is to sleep for a fixed amount of time and hope that this is sufficient, essentially creating a race condition between the python wrapper and the device.

Is there any way to achieve this functionality? Does the logic analyzer send an acknowledgment when the capture starts?

2

@maltekliemann Sorry for the trouble this is causing…

Unfortunately, the API was not built to acknowledge the start of capture. Only the end of capture is acknowledged. You may have read though this before, but Mark highlights some details on this behavior here:

I’m also not familiar with a way to block until the capture is guaranteed to be running. This is likely not possible, though I’ll run this by the software team here in case there may be a workaround.

3

I appreciate the speedy reply, Tim. Thanks!

As ppannuto pointed out, the ACK behavior of the capture socket command is an upstream problem. I did read the linked issue, but only now understand the implications, especially this:

To summarize, the C# API is essentially synchronous. You issue a command and must wait for the ACK/NAK reply before issuing another command. In particular, you should never issue a command while a capture is in progress.

It seems to me like this is a fault of Socket API, which doesn’t allow you to identify which reply is for which issued command (I’m guessing by looking at the code of the C# API), so I don’t see how this could be done without replying on implementation details and/or undefined behavior.

I understand that most users start the device manually and therefore get immediate feedback from the UI when the recordings start. However, I would like to stress that for the API, especially when working on test automation, getting an acknowledgement is cruicial - otherwise, all you’ve got left is the very questionable solution of waiting a fixed amount of time. So I must strongly emphasize the importance of the proposal Application / Automation API - Logic 2 - Ideas and Feature Requests - Saleae and ask that a new Socket API for Logic2 be made that allows asynchronous communication and a way of determining if a capture is currently in progress.

Thanks again for your time!

4

You’re absolutely right. We need to make several improvements to our automation API when we port it over to Logic 2, including a more robust ACK/NAK implementation. Thanks for sharing all these details on what you think should be improved.

Apologies again that there’s currently no way to ACK the start of capture in the API’s current state.

I ended up adding a comment for you in the idea post you shared previously.
https://ideas.saleae.com/b/feature-requests/application-api/

Interest in this feature is extremely high, and I wanted to make sure we log your notes on this topic properly in that post.

5

Thanks again for the update, Tim! Looking forward to the new API!

1 Like