Jump to content
Light-O-Rama Forums

Recommended Posts

Background,

I am running a P-10 panel and a P-5 panel this year.  To drive them I am using Falcon Player in bridge mode.  So the data flow is LOR Show player > E1.31 packets to Raspberry Pi3B running FPP > ColorLight receiver card > the P10 panels.  It has been working great.  Like LOR, FPP is in a beta cycle.  I loaded the new beta branch version and can no longer light the panels.  According to FPP, it is hardly seeing any E1.31 packets.  I posted this last night on the FPP forum and one of the developers responded:

Quote

It's likely the updates for supporting the sync packets.   Previously, any e1.31 packets that came in where considered data packets and processed as such.  Now, it actually checks the packet flags to make sure it IS a data packet.  I wonder if LOR isn't setting a flag properly. 

So I ask the developers here, is LOR properly setting the data flag?

He also asked me to do a WireShark capture, but I'm on the road until Monday, so I can't do it until then.  BTW, because of the 5.0.18 update yesterday, this problem was observed in both 5.0.16 and 5.0.18.

 

Share this post


Link to post
Share on other sites

We will have to review the E1.31 spec as well as the code.  It could also be the other way around, that the FPP guys are interpreting the spec incorrectly with their new update.  It has happened before where someone did not read the spec correctly -- the HC thing from a couple of years ago boiled down to they were incorrectly relying on data they assumed was valid. 

Please tell them to send me an eMail (or open a help desk ticket) with what they think the issue is, the flag byte, etc.  Once we have that we'll take a look and post our findings and work with them.  If we are not performing to the spec we will fix our code. 

Share this post


Link to post
Share on other sites

Thanks Mike.  I fully understand that in this situation both the sender (LOR in this case), and the receiver (FPP in this case) need to adhere to the E1.31 standard.  No one so far is accusing either side of violating the standard, only posing the question.  FPP made a change that made it not work, but that does not necessarily mean that their code is broken.  I will be making a WireShark capture when get back home for analysis.  Although I have have at least figured out enough of what an E1.31 frame looks like to read part of the data, I don’t know enough of the details of the spec to be able to determine wherein lays the issue.

The purpose of this was to get you guys to be aware that there is an issue that MAY  be related to LOR’s code.  After the experts analyse a WireShark capture, we’ll have a better idea what’s going on.  I applaud your willingness to work with the FPP developers to make sure the issue gets resolved.  This is particularly true since P10 panels are becoming FAR more common and LOR has no way to directly drive them.

 

Share this post


Link to post
Share on other sites
Posted (edited)

Just downloaded 5.0.18 now cant insert Superstar Effects  what am I missing    Dennis  never mind found it

Edited by Dennis Laff

Share this post


Link to post
Share on other sites

NP Jim.  Like I said either way we can get with them and figure out what is wrong.  Just have them contact us.

Share this post


Link to post
Share on other sites
On 3/1/2018 at 11:45 AM, k6ccc said:

I loaded the new beta branch version and can no longer light the panels.

Which branch are you running? And which Git version?

Matt

Share this post


Link to post
Share on other sites

Matt,

it was working great in v1.11 beta, but when I updated to v2.x-master-468-gbcfcb309 (a beta version) I could no longer control the lights.  The FPP people did a change in the v2 beta branch to check for data flags (see my first post).  So the question is if LOR is not correctly generating the data flags, or if FPP is not correctly decoding it.  I will be generating a  WireShark capture to send them when I get back home on Sunday.  

 

Share this post


Link to post
Share on other sites

Last night I was able to do a dump from my laptop running LOR 5.0.18 to another laptop running WireShark.  I posted a WireShark capture of a five second segment of 36 universes to the FPP forum.  I had looked at the data and based on my limited knowledge, it appeared that the data flag was being set correctly.  However I'm not the expert here.  This morning one of the FPP developers responded as follows:

Quote

The wireshark dump looks OK.   Basically, we previously would only check two bytes out of the entire header: the two bytes that make up the universe number.    We now check three bytes: the two for the universe and now offset 21 which defines the e1.31 packet type.  It should be either 0x4 for normal e1.31 data or 0x8 for e1.31 extended packet.   The dump shows that it's outputting 0x4 correctly.   Thus, I'm not sure what would going on.

I just added more logging and error counts to the e1.31 bridge code.   If you could update your Pi/BBB and re-run, that would be great.  If there are e1.31 problems, there should be a "E1.31 Errors" line that appears on the status page.   If there are a lot of errors or if things aren't working, go to the FPP settings page and turn on debug logging.  Then send logs.

When I get back home tomorrow evening I will update my FPP version and see where it goes from there...

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×