You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because only change is monitored, the first timing printed out to serial may correspond to a high or low state.
However, php code assumes that the first level is always low, and it plots it that way.
As a result, in several trials it is possible to get "symmetrical" plots in the vertical direction. Half of them will be unsuitable to interpret the protocol.
The text was updated successfully, but these errors were encountered:
I think that my previous fix (and my raspberry pi port, because it uses the same method) may fail in the rare occasions when the program stops recording exactly at the last position of the buffer or just one position before it. If the program has to "correct" the first position to ensure a low initial level it will not consider resetting the buffer position to 0 and will probably throw an error or provide wrong data.
I do not plan to write a fix for this in the near future. The fix seems easy to write but the testing environment would be complex, requiring a transmitter to emit exactly a certain number of level switches (or hard-wiring a transmitter pin of a device to a receiver-pin of another).
You should reconsider reopening the issue just to provide the warning that there is this chance of failure (I calculate 1 in 1000 runs).
Because only change is monitored, the first timing printed out to serial may correspond to a high or low state.
However, php code assumes that the first level is always low, and it plots it that way.
As a result, in several trials it is possible to get "symmetrical" plots in the vertical direction. Half of them will be unsuitable to interpret the protocol.
The text was updated successfully, but these errors were encountered: