Go Down

Topic: Unusual LED Cube and Shift Register Behaviour? (Read 609 times) previous topic - next topic

PaulRB

Yes, the refresh rate is determined by your code, or could be.

Right now, your code repeats refreshes as fast as it can, and speed of animation is controlled by how many repeats of the refresh cycle are done. So your refresh rate is unknown and too high, and the number of repeats to achieve the desired animation speed has to be arrived at by trial and error because the refresh rate is unknown. This is what I was getting at in post #7 when I said there is no proper timing control.

If you put a known delay in your code, say 1ms for each layer of the cube, then you will get a known refresh rate, in this case 1000/8=125 refreshes per second. It won't be exactly that because of the execution time of the rest of your code, but it will be a reasonably good estimate.

You can control the speed of animation better by giving the displayCube() function a parameter which is in milliseconds (instead of a count of refreshes required). For example displayCube(50) would repeat the 8ms refresh loop until 50ms had passed (so in practice it would be more like 56ms, having done 7 repeats).

Yojimbo55

OP again


FYI regarding this:

Quote
If you put a known delay in your code, say 1ms for each layer of the cube, then you will get a known refresh rate, in this case 1000/8=125 refreshes per second. It won't be exactly that because of the execution time of the rest of your code, but it will be a reasonably good estimate.

You can control the speed of animation better by giving the displayCube() function a parameter which is in milliseconds (instead of a count of refreshes required). For example displayCube(50) would repeat the 8ms refresh loop until 50ms had passed (so in practice it would be more like 56ms, having done 7 repeats).
I did some experimenting with my cube display function along the lines you suggested, and the ghosting I was experiencing disappeared.  The problem I was having was whenever a voxel in the top layer turned on, the same voxel in the bottom layer would turn on as well, but at a much reduced intensity level.  I still don't understand why this happens for only these two layers, but changing the display function made it go away.  I haven't yet decided how I will finally implement it, but I will probably go with some kind of time based delay using either milli() or micro().

Thanks for the tip.

Paul__B

You only need to do that 8 times to refresh the cube once, and only refresh the cube ~100 times per second to avoid flickering. So that's around 800 layer changes per second. Doing it more often, as your code is doing now, could make the ghosting worse.
So using millis() is just perfect - either wait for it to advance by 1 to get a whole cube refresh of 125 Hz, or advance by 2 to get 62.5 Hz which is similar to the field rate of your TV.  No need to use micros() at all.

There is no need to attach an image to the post here to show it - it is perfectly fine to host it on imgur or another reputable site, albeit with two caveats.
  • You must as I explained, post a link to the image, not a Web page.
  • You are at the mercy of the image posting site as to how long the image is available.  You can argue that this site could be more reliable to host images or any other attachment used by posts on this site as other sites may not be so reputable or concerned about longevity.  Notionally, if this site were to go down one would expect both attachments and forums would go do down together!   :smiley-eek:

What can happen is that when you trigger the latch line ("SS" in your code), not all the SRs update at exactly the same instant.
Really?  How could that happen?  :smiley-eek:

PaulRB

Really?  How could that happen?  :smiley-eek:
I really don't know. I would have thought any discrepancy between the times that shift registers take to propagate the update to their outputs would be so incredibly small that it would not produce any visible ghosting. But in similar forum topics to this one, that was the conclusion of more experienced forum members than me. The fix was to use OE to blank the outputs while the new data "settled" in some way before re-enabling the outputs. Why the Latch signals cause different propagation delays in different chips but OE signals do not, I don't understand. As in this topic, the latch and OE lines in those previous topics were shared between the chips and connected to the same Arduino pins. Maybe it was bunkum, but I didn't feel I had the level of experience to call it out!

Go Up