Sync Drift with FPP Standalone - Bridge Mode Fine

[TastyHamSandwich]

::PREAMBLE
So lately I have been working to convert my LOR sequences to xLights, all of which is A/C programming. Through 'Import Effects', I brought in 32 channels worth of data: Channels 1-16, and Ch 49-64 (I'm trying to use a standard layout across all these LOR sequences, some have 16 channels of "main" programming, some have 32, and some have 48. Thus the space.). 49-64 are two sets of A/C-based singing faces, 8 channels each.

::THE PROBLEM
Of course, I struggled here and there with making this aspect or that piece work or fit right, especially when it came to the A/C programming using LOR controllers & LOR dongles. I've finally worked through all that, at least for now lol, but I'm finding now, watching my test singing face on my LOR controller, that though the sequence remains in perfect sync throughout when playing from xLights, with the FPP in Bridge mode, when I switch to Standalone mode and play a sequence from the RPi, the sync will start out fine but the lights will fall behind over time during playback.

I'm using 25ms timing in the sequences, for what its worth. If anyone has any leads or insight as to what might be causing this, or what can be done to rectify it, please let me know! Thanks! 

[JonB256]

My first guess as to why the lag appears is because you are outputting LOR protocol from an LOR Dongle rather than using DMX (which your LOR controllers can understand).

Even though xLights and FPP have improved tremendously over the last 4 years, the inefficiency of the LOR protocol is what drove me to 100% DMX and E1.31.

[Gilrock]

So its only 64 total channels?  Is so it doesn't matter which protocol you use it shouldn't lag.  I've heard about a similar issue reported with the FPP before but not sure what is the fix.

[TastyHamSandwich]

Dang... That seems like a pretty egregious bug, that sequences played from the FPP directly can't stay sync'd... I'm using a Pi B+ right now to test, just because my Pi3s are somewhere I havent been able to get to the last few days, but I want to confirm I don't see this same behavior on a Pi3.

Alternatively, it seems like it could potentially be a framerate issue, though I'm not sure how to check the recorded FPS (should be 40) to the actual playback framerate with these systems, necessarily.

[Gilrock]

I use a Pi B+ and have 40fps sequences that play just fine in my show.

[Gilrock]

Make sure you don't have any unicast IP addresses setup in the FPP that are from controllers that are not powered up.  If the FPP is trying to reach an unreachable unicast address it will lag.

[JonB256]

Make sure you don't have any unicast IP addresses setup in the FPP that are from controllers that are not powered up.  If the FPP is trying to reach an unreachable unicast address it will lag.

This is a more likely problem (sending unicast data to a device that isn't available) because a PC running xlights can handle the errors much better than a Pi.

Sent from my SM-G955U using Tapatalk

[TastyHamSandwich]

I don't think this is the case, having undefined/inactive Unicast addresses. In xLights, all that I have defined in my setup tab is the DDP connection to the FPP, and on the FPP itself there are no E1.31 definitions/entries listed, though I do think it is enabled. I'm not at the site right now so I can't log in to check, but I am reasonably confident this is the case, and I can confirm tomorrow. The only Channel Output definitions I've given the FPP at all in this instance is the LOR adapter definition, using ttyUSB1, as that is the only thing I am testing right now, and really is the only thing I need it to be able to output in this specific instance.

[TastyHamSandwich]

I wish I had a second Pi B+ on hand, because the sync drift issue does seem to exist solely on that board. I got ahold of my Pi3 today and sent all the same sequences up to it, swapped the dongle, defined my channels, and off I went. I'm on song 9 of 10 of my singing face sequences, and so far each one has remained in sync while in Standalone mode.

I swear, issues like these are all I ever deal with. That B+ was working just fine last I knew, and suddenly it has me chasing wild geese all over the place, with many red herrings to stop and examine along the way.

Thanks for everyone's input, I'm glad to have this seeming "Great, what do I do now?" issues out of the way, no matter the problem or fix, haha. Now if I can just figure out how to make xCapture recognize my MADRIX output, I think I'd be a happy man. 

Thanks again!

[keithsw1111]

I will take a look at madrix next week.


Sent from my iPhone using Tapatalk