Output to BBB - P10

[uzelessknowledge]

Is there a way to output directly from XL4 to the BBB for P10's. I've got my working, but would like to see the effects directly without having to save the FSEQ and upload.
Maybe I don't have something configured right.


Travis
Sent from my iPhone using Tapatalk

[flyinverted]

Yes, put the BBB in bridge mode and just play from the NC sequencer tab.

[uzelessknowledge]

That's what I thought, but I can't make it work. With my Pi's controlling my pixels through a PixLite it works.
Since I'm not using XL4 to control the show maybe I have it set up wrong.
I have the first 16 universes/channels for my PixLite.
The next channels are for my P10 3x3 matrix.
The following are for expansion into my Falcon v2 when I need it. Does this look right? The IP of the BBB is right.
I didn't know if the universes had to be consecutive or if they should start back at 1 for each controller.
Thanks,
Travis

[flyinverted]

You have duplicated universes on multicast. Channel #1 and #22441 are duplicate as they're both on Multicast Universe 1.  If you set the controller to Unicast, then they will be in their own DMX realms.

A realm is a DMX Universe container or boundary.

Think of the address 123 Main Street as being duplicated all over the country.

What is OK about having duplicates of 123 Main Street, is the boundary is the City or Zip code.  In the lighting case here, there is no boundary with Multicast Universe IDs.  If you use Unicast instead, then the boundary is the IP address of the controller and every controller can have Universe #1, just as every city can have a 123 Main Street address.

Multicast is great for simplicity sake but it increases the network traffic significantly.  If you normally send 20 Christmas cards to folks, its like sending 20 cards to each of the 20 people and telling them to take theirs and throw away the other 19.  Same for multicast network traffic. Every port on the network will receive all the multicast traffic and the device will figure out of it's to respond or ignore. Unicast is how you send your Christmas cards today I hope. One address, one packet, one recipient, much more efficient.

[gerry]

To add to the above, on the BBB just define the universes that you need there ie that pertain to the panels.

To test in bridge mode, (in addition to setting that FP to Bridge mode) , I think you need to tick the E131 attribute.
Otherwise (ie in standalone or remote mode) , it should not be ticked.

[uzelessknowledge]

Do I define the IP of the FPP or the IP of the controller. I know in the case of the BBB that is also the controller for the panels, but for my PixLite and Falconv2 which is it?

[gerry]

For the Pixlite and Falcon , u need to define the IP address of the controllers if u are using Unicast.

For multicast , u dont have to define the ip addresses.

[uzelessknowledge]

For the Pixlite and Falcon , u need to define the IP address of the controllers if u are using Unicast.

For multicast , u dont have to define the ip addresses.

Thanks Gerry. Did that, but still can't get the BBB to display even in Bridge.

[gerry]

Can u please post your E131 screen definition of the BBB . What is its IP address ?

I must say that in my case the universes are unique ie i don't use the same ones for different controllers. Is there a reason why u are setting it up this way ?


 

[uzelessknowledge]

Can u please post your E131 screen definition of the BBB . What is its IP address ?

I must say that in my case the universes are unique ie i don't use the same ones for different controllers. Is there a reason why u are setting it up this way ?

Thanks for your help Gerry!
I guess lack of knowledge.I didn't know if the BBB should start at universe 1 or 17. Can you help me understand this? So if I do consecutive universes then on the controller, say the Falcon v2, I can start at some high universe like 29? Didn't know this.

I ddin't have any e1.31 data configured on the BBB and just saw the comment from earlier.
Once I configured e1.31 it's working.

[gerry]

Any controller can have any universe defined (and start with any one).

Suggest you change that , so that they are all unique . The change should be simple. Do one controller at a time and change the xl setup as well. Test it.
 
Then do the next controller and xl setup , and then the last one.

[uzelessknowledge]

Thanks Gerry. It won't be hard. I'm only using the PixLite and BBB this year.


Travis
Sent from my iPhone using Tapatalk

[Gilrock]

I'm switching everything to Multicast this year.  My high channel count stuff like the P10 panels run in slave mode so their traffic doesn't go across the network anyways.  One problem with Unicast is if one controller goes dead it can lag the whole show.

[uzelessknowledge]

I'm switching everything to Multicast this year.  My high channel count stuff like the P10 panels run in slave mode so their traffic doesn't go across the network anyways.  One problem with Unicast is if one controller goes dead it can lag the whole show.

Hey Gil. So, I saw you posted you now have a show router. I set mine up this way too.
The master Pi is Ethernet to my home network. Wifi to the show router.
Remote Pi and BBB are wifi to my home network and Ethernet to show router.
Show router is standalone and not connected to home network.
I did this so I can remote into my desktop and then control everything or connect to show router from the yard and control. I like control. Hehe.

Since I have a standalone show network then multicast wouldn't be an issue for me. Right?

What causes the lag if a controller goes out? Does the FPP wait for a response or fire and forget?

I guess I see both sides and still not sure which I like. I use unicast in the FPP because of the network setup, but usually use multicast on the computer because then I don't have to change my network settings.


Travis
Sent from my iPhone using Tapatalk

[JonB256]

What causes the lag if a controller goes out? Does the FPP wait for a response or fire and forget?

If you are using Unicast, the FPP is sending TCP/IP packets. That protocol wants a response so that it knows that data was received. When it doesn't get a response (controller lost power or cable or wireless problem), there is a delay while it uses ARP requests to find the controller.

Multicast sends UDP packets and they require no response, so no lag induced if something is off line.