• The firmware was on 2.16, so i've upgraded to 2.17 (no release formpost?) but that did not matter in this case.

    So i've changed the code, so the send command is done on BRN press (in stead of interval). Then i could single shot capture the full signal for 160 leds (at the input for the first LED) and record a sample for a 'right' and 'wrong' moment by pressing the BTN a couple of times while resetting the single shot in between.

    When inspecting the last few bits of the long data signal (see attached file, where i've photoshopped the two captures over each other), it was noticable that a few bits have shifted/flipped? Where exactly the first change occures, i have not checked (as it is a very long data stream). But if that matters, i could investigate/compare further/deeper (however i doubt that this means a lot because the issue starts randomly along the line after about 16 leds, mostly in blocks.

    The total length of the captured signal is the same length most of the time, so it's more like there are bits shifted as apposed to delays in the full data signal.

    Just to be clear, in order to compare the data signals, i set all values to 20 (arr.fill(20)) and console.logging the arr before the send command, i can confirm that the arr data is allways the same, but the leds change (are not equally lit) everty 1-5 send command.

    Please let me know if you would like to have more info (video, source code, scope data...).

    1 Attachment

    • apa106-signal-difference.png

Avatar for Eddie @Eddie started