Are you getting an “extra” edge (glitch) in the reference signal? If so, did you try to “deglitch” your waveform (glitch filter)?
You may also try choosing a different digital threshold, depending on the hardware voltage levels for your logic inputs and analyzer capability (as a different level might be more stable):
Even though the logic analyzer presents the digital signal as a 1 or 0 (high or low), the real world is still fundamentally analog – and the underlying signal is really above or below a certain logic level threshold limit that can be glitchy due to “bouncy” or " noisy" signals in the underlying hardware. The noise can be compensated by good grounding (did you connect the black ground wire of your reference channel?), good filtering (glitch filter), and good limits, etc.
Edit: re-considering the details of your question –
I believe that all of the Analyzer SDK traversal APIs appear to work in terms of a ‘sample_number’, or ‘num_samples’ (or the state via ‘NextEdge’) rather than using a value in units of time (i.e., seconds). However, I think that all of the channels do share a common data stream and therefore the ‘sample_number’ parameter used in the AdvanceToAbsPosition() API for each channel is a globally common reference point that is synchronized across all channels ( @timreyes ?)
Therefore, I assume if each channel would AdvanceToAbsPosition() to the same value of the ‘sample_number’ parameter, then you could individually query each channel’s state (via the GetBitState() API) to determine if a specific channel is either in the BIT_LOW or BIT_HIGH state at the same given ‘sample_number’ in the stream.
Thus, each channel may not have the same number of EDGES, but I think that ALL of the channels are being tracked together in the analyzer data stream with a shared ‘sample_number’ reference (clocked in ‘samples’ rather than ‘time’) and therefore each channel has a known value (i.e., specific state) at any given ‘sample_number’ within the stream.
Based on this, I think you can use AdvancToNextEdge() and GetSampleNumber() on the ‘main’ channel you’d like to use as your ‘clock’ reference (i.e., time reference point, expressed in terms of an absolute ‘sample_number’ vs. actual ‘time’ in seconds), and then use the AdvanceToAbsPosition() API on your other channel(s) to synchronize to the same ‘sample_number’ (point in ‘time’) as the ‘main’ channel.
Ultimately, there may not be the same number of ‘edges’ on a given channel, but I believe all of the channels share the same ‘sample_number’ as a ‘timestamp’ (in sample counts rather than time).
However, the ‘sample_number’ value can be related to time (in seconds) via other API functions, such as:
GetTimeString(), which uses the trigger sample and sample rate to calculate a time string, OR
GetSampleRate() API to get the sample rate (in Hz) as a 32-bit integer value (U32) which can be used to derive the sample period (in seconds) from the equation:
sample period (in seconds) = 1 / (sample rate (in Hz)
Note: If doing so, be sure to properly manage the data type conversion from U32 to double – as an integer division operation truncates to zero vs. returning any fractional result