Sorry you guys dug in deep above… I did not read it all…sorry about that… but I don’t wonder if you can somehow resync when you get the signal and have the slave continue with the pattern. Or have it sync up after several iterations of the pattern? certainly a difficult problem when you are doing POV and have to get things syncing fast to keep the image
You can’t miss frames in a POV setup. You can slow or speed them up, but you can’t miss any.
sorry guess someone mentioned this above also… but I will say I agree with him… have the patterns just do what they do but adjust based on a master clock… ignore the remaining if you want… I
Huh ok. so what about if you pass a clock parameter around and you just do the pattern and re-adjust delay based on the difference between the master clock time. So if its ahead of you modify your delay to be less an match back up or vice versa. Would think you would at least keep them very close?
Not sure how sensitive that timing is… but would think you could keep them close enough to stay in sync to the human eye.
Yeah, I’ve been pondering that exact scenario as well. I need to pass a ‘tick’ from one to the other. If I define each ‘tick’ to be 1000ms, then I can compare it with elapsed time. If the elapsed time is 1015, I can adjust the next frame to be 985ms instead to catch up. If it’s shorter than 1000ms, I can delay the next frame.
My issue is that I’m working with usecs and introducing any sort of timing delays will cause havoc. Every cycle will take up a certain amount of time regardless. So it gets hard to time things. Introducing delays in a POV system is rather problematic. I can’t delay at the end of a frame as that will introduce either a black bar or a stretched last pixel. Whatever delay I have will have to be divided into the amount of frames and each one delayed that many usecs. It will cause problems no matter what. Or, I will have to send ticks more often than that so the delays are miniscule.
I like that solution because its “self-healing”. I recently did a pov project and mine was not moving so or needing to sync with anything and I could not get it to go fast enough! I understand you timing a bit… interesting dilemma to resolve…
The main difficulty here is that a single image, or pattern, will flash in under 30ms. Some faster.
Yeah, I’m flashing “columns” under 200usecs.
Ashley, If you still need a possible solution: Many years ago (in a galaxy far, far away) I did program a system that had this type of synchronisation problem and was as time critical, I’ll try and remember how it was implemented and update it to modern ways. I do remember that it used a dedicated watchdog synchronisation processor to calculate the correction and needed drift.
Would you like me to delve into the little grey cells and post something? It may take a few days…
When you say it used a ‘watchdog synchronisation processor’, was that a totally separate processor? Was it part of the main unit, or as an external (third) piece?
I am searching old CCTs to see if I can find the design. But I seem to remember that is was a totally separate processor (in your case you could use a Tiny I would think), and I think is was clocked from the same source as the main CPU.
But basically it picked up a primary sync pulse with an IRQ on a pin, an IRQ sync from the main CPU, calculated the time difference and the placed the result as a signed result on a couple of I/O pins.
The main CPU ‘kicked’ the sync CPU. like you would with a watchdog timer, and then read the result from the I/O pins and knew from this reading of +1, 0 or -1, than it needed to adjust its time at the next point by a small amount. Not trying to adjust all the way, but bit by bit.
This means that the sync CPU does all the communications with the syncs and all the hard maths, meaning there is never any maths to affect the main CPUs timing around critical loops. Bit like a co-processor in some respects too. I think we used a PAL at the time, because a second CPU was costly, but a Tiny is spot on today.
This was a long time ago, in the days of Z80s and alike…
Hrm. It’s worth a try. If you have the time and inclination to do some deep searching, I’m interested to see what it all entails and how it was implemented. There’s no need to rush on it, just whenever you have time. Maybe one afternoon with a beer in hand …