No dice @Daniel_Garcia . I was seeing the same artifacts with the data rate set to >8 whenever I dropped to a delay less than 2500 usecs between columns. So I added the CMinWait<500> you suggested earlier:
void loop() {
static CMinWait<500> waiter;
if (!myFile.open(“abpat3.bin”, O_READ)) {
cout << “Can’t open file! Call Scotty!\n”;
return;
} else {
// read file header to get columns and rows
myFile.read(SD_buffer.receiveBuffer, 9);
char version = SD_buffer.hdr.version;
unsigned char rows = SD_buffer.hdr.rows;
unsigned char columns = SD_buffer.hdr.cols;
// display image, one column at a time
while(1) {
for (int myCol = 0; myCol < columns; myCol++) {
myFile.read((char*)leds, NUM_LEDS * 3);
waiter.wait();
LEDS.show();
_delay_us(2500L - (timeEnd - timeStart)); // myDelay!
waiter.mark();
}
// Rewind back to the beginning of the file, AFTER the header
myFile.seekSet(3);
}
}
}
Without the delay in place, it’s completely scrambled. When I add the delay back in, starting at 2500 usecs, it looks great! As soon as I drop that to 2000, it starts showing artifacts.
I’m at a loss … And I’m willing to keep pointing a finger at the WS2801.
One thing is noticeable: with the waiter in place, the images look a lot better, a lot smoother. Without, the edges become “staircased”, no longer a smooth arc. So it appears to indicate that this particular string needs more than 24usecs to latch. At least for this particular setup. I’m able to run the test sketch that comes with the library without issues, at least, not anything that I can see.
a bit off track, but with these pov units do you spit the image out at a set rate and then move the leds at the right speed, or do you have some sort of gyroscope detecting movement?
Neither. This specific one does not use a gyro and simply reads data and spits it out. Eventually I will add some ability to stabilize the image, but for the purpose I’m going after, I’m not worrying about it.
I’m thinking some of these may just come down to a frame rate issue.
Without the delay, you’re looking at 969 lines/second, with the delay, you’re looking at (assuming timeEnd/timeStart are 0 - what are those values set from and what are they set to?) more like 283 lines/second.
If this is a 48 column image, that’s 20 full frame displays in a second vs. just under 6.
What’s your exposure time for these photos?
I’m going to guess about 1/4-1/5s - judging by the fact that you’ve got a bit more than one frame in that first image. In that case, with the other image you’ve got 4-5 copies of the image overlaid on top of each other.
Another possibility is the ws2801’s refresh rate. It has a refresh rate of 2.5khz/second. that’s only 2.6 on/off cycles available to the ws2801’s PWM clock per pixel per line that you’re painting with no delay, vs 9 with your delay.
With POV you need to match the frame rate to either the motion of the thing showing POV, or the motion of the thing that’s moving to see the POV effect, if the strip is staying stationary. Otherwise, your photos are going to end up coming up off 
Or - one other possibility - which, if this is what’s going on is going to drive me batshit nuts.
I’ve always assumed that the ws2801’s will start showing color data as soon as they’ve received 24 bits - however, if they don’t latch in the data until after 500µs have passed, the question becomes - what are they doing while receiving data - are they still displaying the old values, or do they stop the pwm clock entirely while receiving?
If they stop - then just having that 500µs wait block means that the amount of time that the ws2801’s are showing any color information is going to be really really short 
Might be another source of glitching.
Also - to get even finer, clearer control over your frame rate, I would move the waiter.mark() line to just before the show, get rid of your call to _delay_us, then set CMinWait<2500> or whatever µs value you need to get the framerate that you want. Then there will be 1 call to show made every X µs necessary to keep that framerate.
Actually - some of this may be even more annoying. The ws2801 doesn’t start showing the data when latched, it starts showing it at the start of the “next PWM cycle” - so, what isn’t clear to me is if the 2.5Khz refresh rate is the number of PWM cycles or if there’s only 6 or so PWM cycles per second. I’m really hoping its the former, if so - that makes things a little bit better, though that means a pwm cycle is 400µs. If the timing of the latch is off, it could be up to 399µs until the “start of the next PWM cycle”.
So - from the end of writing to the ws2801 (which is 531µs), you need 500µs to latch the data, but also another 400µs, worst case scenario, to ensure that the ws2801 even starts to show PWM data from the frame you just pushed out (again, wish I could find information on what the ws2801’s are doing while data is being written to them), and then probably another 400µs so that you can get at least one full pwm cycle out before you start writing things out - and you’re at 1831µs, ignoring any other overhead.
None of this is making me more of a fan of the ws2801s 
(though, compared to the hl1606 and lpd6803 at the time, they were fantastic! Amazing how quickly we get spoiled).
In the meantime, I have to go back to drawing board’ing some other things because the compiler arduino uses for the due is 4 years old and does a terrible job of, well, existing. (I’m sure it’s just fine as a compiler, it just happens to be right atrocious at the one thing I need it to do well to support the clock less chips).
One small detail: all the images have 48 ROWS, and variable columns. Meaning all the images are the same height, but variable width. And I’m displaying an entire column at a time, which consists of 48 pixels (or rows).
I’m not sure that second image is displaying multiple frames on top of each other. The columns that are “off” actually have the correct data on them. I can open the image in Photoshop and manually move the columns down and everything matches up. So the data is there … why they’re off I don’t know.
I’m at that point where I’m going to put this to rest till I get an LPD8806 rig build. After all, that is what the end product will be running on. We could very well be chasing our tail here and nothing we do will decrease the timing. I certainly don’t have any ideas. And rather than having you keep beating what’s turning out to be the equivalent of a dead horse, I’m willing to just say, screw it. Move on.
But, on the whole clock cycle thing, specifically the latching. That was my question earlier too. How, or when does it start to display data. If I remember correctly, way back when I was talking to someone in China who had some intimate details about the WS2801 and WS2803 drivers. Looking back at my e-mails, this person seems to indicate that the data won’t actually latch till the reset signal is received. Reset being the 500usecs LOW on the clock line. So yeah, what does it do while waiting for that 500 usecs to expire? Nothing. It keeps displaying the old data, it keeps the new data in buffer, and not till the reset expires does it shove it out. Now keep in mind, this was close to a year ago. What are the chances that things have changed now? Very likely … but I wouldn’t know what the current specs are.
So yeah … it’s starting to drive ME up the wall and less and less likely to use these anymore.
So if you’re willing to call uncle (for now) and focus on your other project, that’s fine by me. I’ll let this sit and pick it up again later when I have hardware ready.
