Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Teensy 4.1 QNEthernet - Multi universe receive issue #12

Open
balla94 opened this issue Jan 8, 2025 · 3 comments
Open

Teensy 4.1 QNEthernet - Multi universe receive issue #12

balla94 opened this issue Jan 8, 2025 · 3 comments

Comments

@balla94
Copy link

balla94 commented Jan 8, 2025

Hi,

I'm trying to make a multi-universe receiver using this library, but I see a collision.

Based on the sACN example, the proper way to do this is by using multiple EthernetUDP instances, like this:

EthernetUDP sacn1;
EthernetUDP sacn2;
EthernetUDP sacn3;
EthernetUDP sacn4;

However, if I check the QNEthernet readme:

Since only one socket at a time can be bound to a specific port, you will need to use the same socket if you want to receive traffic sent to multiple groups on the same port. You can accomplish this by either calling beginMulticast(ip, port) multiple times, or by using begin(localPort) once, and then calling Ethernet.joinGroup(ip) for each group you want to join.

So if i make multiple EthernetUDP instances, only one of them can subscribe to multiple multicast groups, the rest will fail from the second.

If i try to use only one EthernetUDP instance and bind the Receivers to them, the multicast subscription seems fine, but the first parsePacket() in the sACN library eats the packets, and drops it, so the other Receiver objects can't read them.

@balla94
Copy link
Author

balla94 commented Jan 8, 2025

Minimal examples:

Only one instance, both of the multicast groups are received properly.

#include <Arduino.h>
#include <QNEthernet.h>
using namespace qindesign::network;

EthernetUDP udp1;

void setup()
{
  Ethernet.begin();

  if (udp1.beginMulticast(IPAddress(239, 255, 0, 50), 5568))
  {
    Serial.println("Failed to join multicast group 239.255.0.50");
  }
  if (udp1.beginMulticast(IPAddress(239, 255, 0, 51), 5568))
  {
    Serial.println("Failed to join multicast group 239.255.0.51");
  }

}

void loop()
{
  if (udp1.parsePacket() > 0)
  {
    Serial.println("UDP1 IN");
    udp1.read();
  }
}

Second example with 2 instances. The second will always throw the error.


#include <Arduino.h>
#include <QNEthernet.h>
using namespace qindesign::network;

EthernetUDP udp1;
EthernetUDP udp2;

void setup()
{
  Ethernet.begin();

  if (udp1.beginMulticast(IPAddress(239, 255, 0, 50), 5568))
  {
    Serial.println("Failed to join multicast group 239.255.0.50");
  }
  if (udp2.beginMulticast(IPAddress(239, 255, 0, 51), 5568))
  {
    Serial.println("Failed to join multicast group 239.255.0.51");
  }

}

void loop()
{
  if (udp1.parsePacket() > 0)
  {
    Serial.println("UDP1 IN");
    udp1.read();
  }
  if (udp2.parsePacket() > 0)
  {
    Serial.println("UDP2 IN");
    udp2.read();
  }
}

@sstaub
Copy link
Owner

sstaub commented Jan 8, 2025

Sorry that I can't help you because it is a problem with QNEthernet.
I wrote the library for use with Wiznet W5500 chips with the Arduino Ethernet library.

@ssilverman
Copy link

ssilverman commented Feb 21, 2025

This likely has something to do with the fact that there’s only a single network interface in the QNEthernet library at this time, and only one socket can be bound to a single port at a time. This means that, from the perspective of the stack, there’s only one place to receive data sent to a specific port, regardless of how it got there, either via multicast or via a specific non-multicast IP address.

From the discussion there, it sounds like the pure Wiznet stack operates a little differently, where you need one UDP socket per multicast input, even for the same port.

I’m working with @sstaub on this. (Please correct me if I got any details wrong.) Basically, the solution right now is to only have one UDP socket per port, depending on the library, somehow making a determination which underlying network library is being used. I’ll think more about this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants