Hi, @anon43292299
Have you had a look at the FastLED library to see how they do it?
Tom.... 
I used the sketch below and a $10 logic analyser.
I monitored the 7th LED on the 8 LED real strip I attached. The test writes to 500 neopixels twice per loop.
For the exact LEDs I was using the transition to a newly delivered 24 bits comes at the end of the total strip data packet, about 60 us after the last bit. This is in excess of the 50 us reset time from the datasheet. All timing was entirely nominal.
My LED sensor was a phototransitor pulled up and fed to the logic analyser channel. It was not connected to the UNO.
This is one trip though loop():
# include <Adafruit_NeoPixel.h>
# define NLAMPS 500
# define aDataPin A2
Adafruit_NeoPixel theOneTrueStrip = Adafruit_NeoPixel(NLAMPS, aDataPin, NEO_GRB + NEO_KHZ800);
# define SOT_ON 7
# define SOT_OFF 6
void setup()
{
theOneTrueStrip.begin();
pinMode(SOT_ON, OUTPUT); // strip.show that turns LED On.
pinMode(SOT_OFF, OUTPUT); // strip.show that turns LED Off.
pinMode(LED_BUILTIN, OUTPUT);
}
void loop()
{
digitalWrite(LED_BUILTIN, HIGH);
theOneTrueStrip.setPixelColor(7, 0xff0000);
digitalWrite(SOT_ON, LOW);
theOneTrueStrip.show();
digitalWrite(SOT_ON, HIGH);
delayMicroseconds(333);
theOneTrueStrip.setPixelColor(7, 0);
digitalWrite(SOT_OFF, LOW);
theOneTrueStrip.show();
digitalWrite(SOT_OFF, HIGH);
delayMicroseconds(500);
digitalWrite(LED_BUILTIN, LOW);
delayMicroseconds(500);
}
Now I wonder about the APA clock and data timing…
a7
I don’t think it happens in order. Each LED controller starts measuring time after receiving low. if this low changes to high within specified timing for 1 or 0 it is decoded as such and pushed into the register. If it exceeds the given reset timing for low, the pixel is commanded to light up. because after the last bit is shifted through all of the pixels, all pixels start countdown almost simultaneously, not all pixels are identical, so some will determine that enough time passed for this to be a reset earlier than others and some later than others, but the difference is probably insignificant and unnoticeable but unordered
Seems pretty convincing. I see what you're doing with the SOT_ON and SOT_OFF lines. But, out of curiosity, what does "SOT" stand for?
So, a little update for you guys.
I was ready to do my first timing measuring and transmission of data, everything was running flawlessly on simulation (Thanks for all the tips).
But my Arduino just can't change the physical I/O state that fast, asked on discord server if anyone could confirm the actual rise time of an I/O and they got <5ns...i got about 2.34µs with mine.
The code actually can run at full speed, but every pin in this chip is a LOT slower than it's supposed to be. I will maybe replace the chip or even upgrade to another board.
that’s horrible, what chip is this?
It's an Iduino Uno board, the chip is a regular ATMega 328p. The board itself seems to be well build, not sure if it's a fake chip or because it had a long life already
Would be interesting to know, I know I bought MSGEQ7 and it appeared to be fake but it didn’t even work so it was obvious, but something like fake LM1875 is definitely far inferior to the genuine one, even though it appears ok at first sight. And if you buy any amp boards with this chip, the chances are you have fake.
@er_name_not_found has provided a link to another topic. Doesn't FAB LED work for you?
How did you measure it? Do you have 10x or even 100x probes? A scope with a bandwidth of at least 100MHz?
No, you're right.
Welcome to my perfect world, where every neoplixel is synchronized to the global frequency standard and every reshaping/forwarding circuit has exactly the same propagation delay…
in which circumstances the change would ripple neatly on down the strip.
Some further logic analysising shows that a pixel puts out the rest of the data with a very slight delay - evident but too small to accurately measure , talking like 100 ns neighborhood.
So a strip of 300 might see the last pixel to count off its reset period illuminate 30 us after the very first to do. I haven't a 300 pixel strip to try this on. In any case, that's small enough compared to the potential 9 ms if each LED changed immediately it has 24 new bits.
The instrument ($10 24 MHz logic analyser) was not showing me any reshaping (wouldn't, I know) or reforming (couldn't?) that is claimed for the neopixels.
Imma leave the experiments, I hope to do these tests again with "real" instruments.
@gfvalvo SOT was a leftover symbol, in my origianle test sketch I was making a little positive pulse at each end of a strip.show(), one was SOT and the other EOT, start and end of transmission.
a7
There's no need for a scope with those specs to make this simple measure. It's an Arduino uno @16MHz, there's no need for a scope capable of >1ns precision...the Arduino itself doesn't do anything under 62ns.
Why "at least 100MHz" if 40MHz with a good sample rate is enough? 100x probes are well beyond what would be needed too, any standard 10x probe can deal with 50MHz or more.
But yeah, i thought that my scope or my probe had some problem, but in real life test it managed to read down to 5ns signals
That is the CPU machine cycle time. It has nothing to do with output pin state transition times. I simply don't believe any chip would produce microsecond long transition times. Not even a fake.
You probably slipped up one time and made some measurement error.
A 40MHz scope with 10x probes would be fine. I ask because many, many posters here have previously not understood how to make valid scope measurements. It's not aimed at you in particular.
Did you remember to set the pin to OUTPUT mode? your curve looks about like I'd expect if the "HIGH" level is driving the line via the input pullup register (which is what will happen if your change PORTBn without having set DDRBn or used pinMode())