SignalCapture issue

I am reading simple 50% duty 10ms period signal.

I am using Gadgeteer template on Cobra II:

    public partial class Program
        SignalCapture pulseIn;
        GT.Timer timer;
        // This method is run when the mainboard is powered up or reset.   
        void ProgramStarted()
            Socket socket = Socket.GetSocket(10, false, null, "X");

            pulseIn = new SignalCapture(socket.CpuPins[4], Microsoft.SPOT.Hardware.Port.ResistorMode.Disabled);

            timer = new GT.Timer(1000); // every second (1000ms)
            timer.Tick += new GT.Timer.TickEventHandler(timer_Tick);

            // Use Debug.Print to show messages in Visual Studio's "Output" window during debugging.
            Debug.Print("Program Started");

        uint[] buffer = new uint[] { 0 };
        void timer_Tick(GT.Timer timer)

each capture should give a value around 5000, but for some reason once every 3-4 captures I am getting a random value (red values in second picture).

Signal looks good in logic analyzer (first picture).

Having not used SignalCapture, I have a question. As I understand it, the first argument to Read() is the trigger state ie. when the line toggles to that state the capture starts, so what happens if the read is initiated and the line is already in the trigger state? Does it wait for the first transition back to the trigger state or does it start the capture immediately?

If it is the latter case, is it possible that code is catching the pin high? Of course I would have expected the results to be a little more erratic, but I thought it might be worth asking anyway since I do not know the class.

1 Like

That is easy to check. Let me try.

You are right. Capturing 3 pulses (high,low,high) and using only second high shows consistent result.

        uint[] buffer = new uint[] { 0, 0, 0 };
        void timer_Tick(GT.Timer timer)

Now the question is: Is this the right way of capturing a signal? Looks like if pin is already in the trigger state SignalCapture should discard it and wait for next trigger. At least it would be consistent with other platforms (pulseIn on Arduino for example).

Any thoughts?

I guess it could go either way, there could potentially be a use case for both options. What you have now does effectively what you want while if the SignalCapture class always discarded the initial matching trigger state one of the potential use cases would be impossible.

I am just guessing here as I have not even thought about this functionality until you raised the point.

1 Like

Using pulseIn before I assumed SignalCapture would work the same, but I see that the way it works can be usefull as well.
For now I can go around this by capturing two states with low being the trigger. That way the high state will always be from start to end.