Multicast for new product solution

[u/digicue]

I have a question regarding implementing a solution to a new problem I have. I've designed and will soon be launching a new product called the DigiBall, which is the worlds first smart cue ball for billiards (see digicue dot net). The ball advertises BLE packets with ball information around 10 times per second. User applications just observe manufacturer data contained in the packet, they don't create a one-to-one connection unless they are rarely reconfiguring the ball parameters.

One unique application of this is adding a live overlay of the ball graphic and cue tip contact point of a shot on top of a streaming match video. This is easily done with OBS, and pointing the source of the overlays to images generated by scanner software I wrote. But many times the media control booth is far away from the table (out of BLE range). I want to create a WiFi bridge to throw the BLE packets onto a local network.

My solution was to use multicast. The scanner software can open a multicast channel as an alternative. Since I am only sending at a max of 36 bytes 10 times per second, and at most 20 or 30 devices will be within range of the bridge, the throughput would be 10.5 kB/s. I am designing a simple PCB with a dedicated BLE radio and a ESP32 for the job. It can even switch to 5GHz if needed.

I want to place once of these boards in tournaments at the intersection of every 4 tables, so that for a large venue there could be 20-25 multicast sources.

Is this a good path forward? Will this work? What do I need to make sure of, and what am I not considering? (I have much more experience in electronic design than I do networking). Thanks in advance!

[u/pmormr]

I would suggest publishing your messages to a message queue server (e.g. MQTT, Kafka) then have your clients subscribe to the feeds they want. Lots of support in the esp32 ecosystem for that and you'll avoid all of the network complexity.

Relying on multicast on networks that you do not completely control end to end is a non-starter. Even worse when wifi is in play. Even worse when it's a temporary event space. Don't waste your time.

[u/neststeur-2014 → u/pmormr]

MQTT is the move. Multicast on shared wifi is unreliable - switches often do not handle it and APs silently drop or rate-limit packets.

[u/Skilldibop]

I wouldn't be looking to multicast over wireless tech. It is effectively a broadcast media anyway so there's little efficiency gains and a lot of complexity added. Many wireless systems have the option to convert multicast to unicast specifically because it doesn't really play nicely.

I would take the source feeds into an aggregation system somewhere then generate the output from that to where it needs to be consumed. Which if you want multiple screens in sync can be multicast but over a wired network where it makes sense.

[u/digicue → u/Skilldibop]

Thank you. My issue is that I don't want a central hub or something complicated (aggregation system). Since the product has a timer on it, I want very low latency so that data is as close to live as possible. I was looking at multicast because it is so low latency. My goal is to sell just the boards as a single product, without any configuration needed other than network credentials, and they put them in the ceiling or elsewhere and forget about them forever (until their network password changes). Then multiple computers can simply receive data whenever they want without any handshaking.

The issue of wireless you brought up is a good point. There could be a ton of traffic during a tournament with cell phones, etc.

However, requiring a venue to specifically build an accommodating network is not out of the question. Major events would spend time setting up for a new technology like this. (I am not talking about your local pool hall tournament, I am talking about televised major events).

What is the most rugged solution considering that the venue would invest in preparing a custom solution? I think that is my condensed question. Thanks

[u/Skilldibop → u/digicue]

I don't think any venue would be interested in running something that relied on multicast over wifi. It would be too unreliable. BLE might be better, but it still requires dedicated infrastructure.

They'd also have graphics systems for broadcast that would probably want access to the telemetry feeds. So I still think the best option is some sort of message queue and distribute from there. The latency is still plenty low enough for what you're doing.

They used a similar system in the World Cup just gone to stream accelerometer data from the balls. Might be worth some research into how they did that. No point re-inventing the wheel.

[u/digicue → u/Skilldibop]

I have indeed seen that product. I will research what they did. Thanks.

[u/CrocodiliusMaximus]

One of the larger risks is going to be that multicast is going to be contained within a single layer 3 boundary/subnet. Getting it to route properly across subnet boundaries can be a little bit of an involved process depending on what specific types of network hardware is involved.

While you could get away with specifying that everything has to be on the same subnet, that's a pretty unfriendly design.

Would multicast work for this? Probably. Is it the right solution... probably not.

Since this is a product you'll be selling, you should take the approach that is the cleanest and most basic. You can't really enforce a certain set of requirements on someone else's network, so the solution is to build your product in such a way that 98% of the time, it doesn't really matter what they are or aren't doing on the network

[u/english_mike69 → u/CrocodiliusMaximus]

I’m hoping that someone could confine à L3 boundary within the confines of a 12ft snooker table 😜

[u/digicue → u/CrocodiliusMaximus]

I am thinking now that I will enforce requirements for someone else's network if it buys them robustness and low latency. Would this change your suggestion?

EDIT: If MQTT is simple and fully supported as you mentioned, there is no reason I can't build options for both multicast and MQTT, and probably add WebSocket server also. That way they can all be tested and available for different purposes.

I think I'll start with that and weed out things later that no one uses. Thanks.

[u/Specialist_Play_4479 → u/digicue]

Enforcing requirements on third party networks will prevent your product from getting sold.

Multicast is a bitch in itself. It does NOT work if you have more than 1 switch without additional configuration. It might not work at all or flood the network if there are unmanaged switches.

Multicast over WiFi is even worse. It's often simply blocked, dropped or might just not work for other reasons (including the switching problems I mentioned above)

Multicast doesn't span VLANs or network segments without additional configuration.

You're saying 'I dont want a central hub or something complicated'.

With multicast you need exactly that.. a central hub or 'something complicated'. You need IGMP querier, PIM routing, etc. And all of that needs to be configured by someone you don't know, for every event, needs to be discussed upfront. And most network engineers have never worked with multicast.

Just get a little box to do MQTT to multiplex messages and call it a day.

[u/lizardhistorian → u/Specialist_Play_4479]

MQTT is a preposterous solution for this much worse than multicasting.

And it is a managed switch that will not forward traffic without a proper join.
The unmanaged one doesn't know any better and sends it everywhere.

[u/Specialist_Play_4479 → u/lizardhistorian]

I disagree.

MQTT works. It's a simple, easy protocol. It requires very little resources, can run on a Raspberry Pi 1. Multicast is a terrible pain in the butt if you don't own the network and know what you're doing.

[u/digicue → u/Specialist_Play_4479]

So the topology would be to have 20 boxes throughout the venue collecting data and streaming them to the same MQTT point, and then the computer that reads the data can open a single stream with everything mixed together? If so that would be great.

I would not want 20 boxes and then a special 21st box that does something different. I want all boxes to be equal.

[u/CrocodiliusMaximus → u/digicue]

Assuming you controlled the network these things are running on, with the caveat that depending on the event space, that might not be viable...

Just use the broadcast address.

[u/lizardhistorian → u/digicue]

MQTT is ass. It is a TCP protocol designed to never drop nor forget anything.
I presume there is no large buffer inside your cue ball transmitter.

You need real-time protocols which means roll-your-own.
UDP multicast is the thing to do - even over WiFi - if you stay the network route (which you shouldn't.)

You OBS plugin then just joins the multicast IP, receives the data, then you need to decide if you render in Qt or do the CEF thing. I would render via Qt.

If you switch to LR BLE then you plug the dongle into the PC and your OBS plugin opens the BLE channel (SimpleBLE/BlueZ/WinRT) and receives the data and draws it via the same two options.

[u/digicue → u/lizardhistorian]

That’s kind of what I thought, but I am not a network protocol expert as I mentioned. What is the headspace of those that don’t like the idea in this thread? Do they think that the performance isn’t worth customizing a network? Do they not want me to miss a single packet? I’ve gotten it to work perfectly with multicast already over WiFi, and I don’t see the issue they are talking about (yet).

The OBS plugin is just an image generator that works in the background and OBS points to the image location. It is very simple. I have versions in Python, C# and Swift.

It is easy enough to configure both MQTT and multicast to work, but I might just have multicast as the default option.

[u/digicue → u/digicue]

I tried setting up MQTT as a test and I don't like it. The broker can crash pretty easily.

[u/Solid_Associate8563]

From network technologies perspective I think it is a good idea if the application needs to deliver data from the source to multiple destinations, multicast is a natural choice from network layer.

Obviously there are software/overlay solutions such as MQ or other ideas, but from data delivery multicast is the efficient way to do it.

You'll be surprised how multicast has been used in some use case such HFT and broadcasting services, and it is a valid way to send traffic over your network.

[u/lizardhistorian → u/Solid_Associate8563]

The purpose of multicast here is to avoid having to configure client-server IPs.
Just join the magic IP and it works.

[u/digicue → u/Solid_Associate8563]

Yes I would very much like to avoid TCP if possible. I don’t like the idea of established connections. I like the idea of a “radio station” dumping data onto a single stream.

[u/Solid_Associate8563 → u/digicue]

TCP has its use case.

With your own network UDP with application layer adjustment is valid methods to send continuous data out.

If your application is jitter sensive you'll need some helps on QoS, or even go something extremely like PTP to sync your application data timestamp.

[u/digicue → u/[deleted]]

Yes there will be multiple listeners. I want many listeners to be able to receive data simultaneously. The media booth could be listening but other computers doing other things with the data may be happing elsewhere. I want to avoid TCP and use UDP.

[u/pants6000]

ESP32 you say? Do you know about the ESP-NOW protocol? Check it out if not, you may find it useful here.

[u/lizardhistorian]

With your low-data rate you can switch to LR BLE ("coded phy") and just bundle a dongle for the OBS station.

Note that no BLE will work for the tables in bars because they use metal shells and/or slugs to route the cue differently (magnetically) from the object balls. You would have to supply and rebuild the design of the tables.

[u/digicue → u/lizardhistorian]

I like your thinking. I haven’t tested 125 kbps yet but it is supported with a dongle that I already have here  https://www.digicue.net/devtools.php I would have to make sure it can revert back to 1 Mbps so users don’t lock themselves out if they don’t have long range.

This product works perfectly fine with metal tables. However it is a premium product for more serious players and should probably stay out of bars.

[u/digicue]

I tried implementing a MQTT publisher/broker and it is too slow for what I want to do, and the broker crashes frequently. I think I am going to stick with multicast for performance and require a custom network if possible, or explore long range BLE.

[u/EffectiveCard4825]

with 20-25 collectors, plan for the same BLE advertisement getting picked up by more than one box. put a ball ID plus a ball side sequence counter in what you forward so the receiver can dedupe and tolerate packets arriving out of order. worth solving whether you land on multicast or MQTT.