SignalCapture hangs on FEZ Spider (NETMF 4.3)

I’m seeing a pattern where, when I attempt to get the signal from an IR remote control, if I have a buffer that is larger than the size of the IR command pattern, and I do not shorten it by using the overloaded Read method of SignalCapture, like so:

int edges = irSignal.Read(false, signal, 0, 100);

to only capture the first x number of transitions (where x is shorter than the full length of the IR command), then the program appears to hang. Additionally, if I stop debugging in Visual Studio, and try to restart, the debugger will not attach unless I restart the board, suggesting there’s a tight loop taking place somewhere in the SignalCapture code.

As long as the last argument to Read is shorter than the actual signal, it works. If I use this syntax, however:

int edges = irSignal.Read(false, signal);

Or if the last argument to Read is larger than the number of transitions in the signal, it appears to hang the board. No exceptions, just no response. Another symptom is that the IDE bogs down as well. For example, it takes many seconds to set or unset a breakpoint, once the issue arises, and it takes longer than usual to stop debugging.

Any suggestions?

@ devhammer - The read methods block internally until it has as much data as you asked for. When you don’t pass the length, we pass the length of the array you pass. Since you are only filling part of that array, the code blocks internally waiting for more data which will never come. If you know exactly how much data will arrive, I would resize your buffer or send that in the overload. Alternatively, the ReadTimeout property will let the method return eventually, with potentially incomplete data if you set it too short.

So, if I set the ReadTimeout (is that property in ms or us, by the way), it will still capture data up until the timeout takes place…is that correct?

Is this the same behavior as in 4.2? Seems different to me, but I may be misremembering how it worked before.

@ devhammer - I believe it is in ms, and that is correct. I do remember any major changes occurring since 4.2, so it should have functioned the same. I think I just moved the timeout parameter to a property.

@ John - Great. Just modified my code to test, and yes it appears to be in ms. Can we get the docs updated for the next version to specify that?

Should I add an item to Task Tracker for that?

@ devhammer - I added a note at

1 Like

Great, thanks!