Raspberry Pi output

damona said:

damo1271That is not how multicast works. Its less load on the network. Its less Packets, if your universe are setup correctly. One person on this form had issues with to many universe, his computer could not transmit all the data in time. Multicasting allows you to have less universe with less packets.

Multicasting is the Standard for E131. Unicast does not existing in the standard at all.

Here is a thread on Multicasting.
http://auschristmaslighting.com/forums/index.php?topic=6283.0

Click to expand...

Thanks for pointing out the flaws in my analogy. The multicast part wasn't quite right. It is more like the "to the householder" letters rather than junk mail. You have to open the "to the householder" to see if it is important, then you throw it away if it isn't, or act on it if it is.

I would have to question some of your other statements regarding multicast, but it has been a long time since I studied this and I stand to be corrected.
As I understand, IP addressing occurs at the layer 2 and layer 3 (approx since the OSI model doesn't exactly fit the internet protocol) and this is where unicast multicast is addressed. Multicast - I think - works at the layer 2 level - MAC Addresses.
sACN and then within that, E1.31, is simply encapsulated within the IP packets, eg it is at level 4, or higher. Therefore it is not expected that unicast and multicast addressing are part of the protocol.

I acknowledge that multicast is referred to in section 82 for determination of universe numbers, but so is unicast. I expect the primary reason for not using unicast is that there is no discovery mechanism available for the source destinations. If you look at ANSI E1.17-2010 (ACN on Homogeneous Ethernet Networks) it specifically cautions on the possible impacts with the use of multicast traffic, E.g. Layer 2 switches usually treat multicast traffic in the same way as broadcast which has implications for efficiency and network saturation.

If my understanding is correct, then when sending multicast packets the destination device must process the content of the multicast packet to determine if the content is intended for the device, in this case via universe numbers. As per section 8.2 - Note: The identity of the universe shall be determined by the universe number in the packet and not assumed from the multicast address.
With unicast the processing happens at the layer 2 level, eg the packet is discarded and the content is never analysed if it's not specifically addressed to the destination device.

There is probably little difference between unicast and multicast on a simple network and I agree that multicast is easier to set up. When you have the sACN running over your home network with internet routers, switches, NAS and multiple PCs, plus the show controllers, I find it slows the network down terribly. Now that I am using the Pi, and even though it is unicast, I still disconnect it from the network most of the time to avoid the 'slowing' effects of the packet transmission.

Thanks for the info Damo & Damona. It seems it's not quite straight forward for Multi vs Unicast, especially as I don't have a great understanding of how it all works (despite re-reading your posts!)

At the end of the day, my current issue seems to be that my Pi has an IP similar to my home network (192.168.x.x) and my D2 does not (possibly 10.10.x.x) however I cannot get into the D2 to change this. From what I understand I need to try to access the D2 to change it to 192.168.x.x range and in theory all will be restored in my blinky world.

So that said, if anyone can please assist me in advising how to change the IP on my D2 that would be great. I've connected it to my home network but Windows cannot get into it (I've tried 10.10.10.10, and it is not accessible via the Network section of Windows.)

Can you connect the P2 to your computer via the USB cable use the UBL to look at the IP address?

Can you look at the status page of your home network router/switch to see the connected devices. You might be able to see a weird IP address there that would be your Pi.

Jon

Unicast you give the IP of the specific device to the show software. e.g. 192.168.5.1
With Multicast the show software already knows the IP Address to broadcasted too, as the standard maps an Multicast IP address to a Universe.

The Packet sent contains a whole universe worth of data, multicast packets are only received by the devices register to receive the packets (if you have a IGMP Snooping switch).

Example
Physical Controller 1 Device Universe 1 DMX Channels 1 to 100 IP Address 192.168.5.1, Plus the E131 Multicast Address for Universe 1

Physical Controller 2 Device Universe 1 DMX Channels 101 to 200 IP Address 192.168.5.2, Plus the E131 Multicast Address for Universe 1

Using Unicast would require two packets to be sent 192.168.5.1 & 192.168.5.2. Multicast would require one packet to be sent to the standard Multicast IP address for Universe 1.

Note you can not configure the device using the Multicast Address, you can only send E131 to the Multicast address.

See this thread for more information http://auschristmaslighting.com/forums/index.php?topic=6283.0


Even though the address you have on the device is 10.10.10.10 you can still send it multicast if you have already configured the Universe. (assume the Software and the device are plug into the same network). Because Multicast E131 does not care what IP address the device is, as it does not use it.

If you have single universes spread across different physical controllers then multicast might reduce the total packet count by a few packets when sending to these universes. However the processing of every multicast packet by every other controller device on the network still happens so the load doesn't change by much.
Personally I don't spread a single universe across multiple physical controllers. I would like to understand the rationale for doing that as on first thoughts it seems very complex to me?

A IGMP Snooping Switch only sends it to the devices which register to receive the packet. This is how multicasting works. It does not flood the network. You can get them for $100 to $200 for 8 ports.


Your Lights control registers with the switch (with IGMP Snooping) to say I want Multicast IP A.B.C.D. As soon as it does this, it is the only one which receives the packet, no matter how many devices are connected into the switch. If another device comes along and says I want A.B.C.D, then only two devices will get the packet and so on.

If you have a dump switch (i.e. without IGMP Snooping), all the packets will go to everything plugged into light controller device, and cause an interrupt that the device needs to handle. Which may may prevent cheap device from changing the lights. Keep in mine that these pixel controls are design to lots of light changes, and they will just ignore anything which is not for the Universe they are controlling. An ADSL router without IGMP Snooping might even burn up CPU sending it to a wireless network, causing dropped packets.


Buy a switch with IGMP Snooping (especial if you wish to do a big show). This thread is for people looking for IGMP Snooping switches http://auschristmaslighting.com/forums/index.php?topic=4669.0 Plug the device sending the E131 Multicast packets (e.g. Raspberry Pi with its 100MBit Ethernet port) directly into the switch, not your ADSL router without IGMP Snooping.

Here is the thread with discussion on multicasting http://auschristmaslighting.com/forums/index.php?topic=6283.0

thanks for the clarification
So what you are saying is that if you have a dumb switch (not an IGMP snooping switch) then multicast can cause processing of every packet by every device attached to the network, thereby flooding the network and causing additional load, including dropped packets.
By inference, then unicast is the best option when using dumb network switches because it causes less load on the network.

Just to add my 2c in, for all us people that are not IT guru's I found it difficult to try and get my head around IP addresses and Networking, I was having issues with multicast so I switched to Unicast and I find that it is the easiest for me. I am running 12000 channels across 6 controllers with no problems and no network flooding. Unicast works for me.

I am running 32,000 channels on Multicast and LSP Scheduler is struggling I am in the process of changing to a PI but WILL be using Multicast as was suggested in chat that Uni is no value or benefit without a specific type of harware...the name of which escapes me.


Will let u know how we go in the next few days. Busy resesting channels for the LSP- Xlights - Pi transfer

When I get upto a 100 posts I will write a wiki page on this and the Pi.

This is not technically correct but just think of Multicast as a second IP address the device is listing on for E131
e.g.
239.255.<UHB>.<ULB> where UHB is the Universe high byte and LHB is the Universe low byte. As an example, the address for universe '1' would be 239.255.0.1. This is why using multicast addressing can be simpler to configure since this address is always the same for any device using that universe.

When LSP/Vixen send a packet to the multicast address they use 239.255.0.1 for Universe 1

If LSP/Vixen are plugged into the same network switch as controllers, let say its 192.168.1.1
And controller 1 is IP address 10.10.10.10. Multicast will still work, in general Unicast to 10.10.10.10 would not, because they are different networks and you do not have a router to route the traffic between 192.... and 10....

So not technically correct, but just think of Multicast as second IP address which just listens for E131.
And more than one physical device can have the same Multicast IP address. i.e. Physical Controller 1 Universe 1 DMX 0 to 100, Physical Controller 2 Universe 1 DMX 101 to 200 Lets say that Controller 1 Controls 2 Candy Canes, Controller 2 Controls 2 Candy Canes. The Packet would be receive by both at the same time, and the Candy canes would be in sync.


The next version of E131 supports syncing. Do not know the details but more than likely.
A single Multicast packet will be sent to all Devices to say, show the next light pattern. Those on Unicast (not the standard) will not be able to do this. Those using Matrix will like the sync feature when software/devices support it.

Beacy,

I'll be keeping an eye on your progress with the transfer. I think you took part in the thread I had discussing 30,000 channels lagging in LSP... but when I shifted my macros down to 10fps, all my lagging went away... and I am using unicast... I really want to switch to the pi, and I guess multicast, but when I tried it a week ago, I couldn't get the sequences to play correctly out of the pi... there was something goofy with the file conversion or something... It just didn't look right... I tried exporting from LSP to nutcracker / xlights, which didn't work well, then tried the Light Elf program with an LSP file directly and it was better, but still not perfect... I'll be curious to see what you do and how it goes...

Louie

I do have the probs with 30K + channe;ls but dont use any transtions. I think the biggest issue is channel matching across 3 platforms.... does ur head in

How are you sequencing 30,000 channels without any transitions?! That sounds incredibly time consuming bordering on impossible!

Louie

I have update an existing feature request for FPP (Pi) to have a way to import configurations, not just the show.

So tools like Vixen can out everything needed.

I have also put in a request to the FPP Guys to have a tick box to allow the Raspberry Pi to be a DNS Server and DHCP Server.

So all you would need to run a show is a Rasberry Pi (with a clock), IGMP Snooping Ethernet Switch, and all of your light controllers. Rasberry would hand out the IP address to your light controller.

Make everyone life a lot easier.