Dealing with multiple master nodes in range of each other

[SirWillian]

I'm currently developing an application where I may have 2 master network nodes in range of each other and I was wondering what was the best way of dealing with the situation.

I faced some problems like nodes from network A reconnecting on network B and I worked around that by keeping some network ID so nodes only interact with nodes on the same network, but it seems like I'm still getting false positives when sending messages since nodes with the same address on different networks can auto-ACK messages (on hardware level) for each other, which seems to throw things off.

Nodes may dynamically enter a network and they need to report to their master so I couldn't think of a way of maybe combining the two networks together since the nodes just entering the network wouldn't know the address of their master and each master would need to keep up with addresses handed by the other master. (I'm actually using RF24Mesh, but I believe that the issue lies in the Network side of things, so let me know if this discussion should move over to RF24Mesh).

I thought of maybe requiring NETWORK_ACKs for every message sent and not just for routed payloads (as long it's an ACK type of message), but I'm not sure if that's the best way to go. Any suggestions on how to deal with this scenario? I'm fine with implementing adjustments on a private fork of the library myself, since I've played around with it for a little while now and I think I roughly know the ins and outs of these libraries.

[2bndy5]

Try using a different channel for one of the networks (preferably not within 2 channels of the other network). So, one network would use network.begin(90, node_address) and the other network would use network.begin(95, node_address). I'm also still learning these network libs 🤓

Technically speaking, If you change the address_translation array to different values, then 2 networks could co-exist on the same channel. However the values in that array were carefully chosen to avoid packet loss due to transmissions' preamble (of alternating bits).

[SirWillian]

The networks must be pretty much independent and a node that enters a network doesn't know which network it's going to be part of until a master node contacts it. Slave nodes periodically broadcast some unique key until a master node responds to them (also via broadcast since they don't have an address yet). After that point, the new node stays in that network. If I were to separate networks by using different frequencies, how would I go about making this frequency choice automatic?

I imagine the master nodes would need to detect the existence of another network and then frequency hop until it finds a safe frequency and the new nodes will need to do some frequency scanning to present themselves for every master that may be there and masters would need to try for a while to contact the slave until it scans back to the frequency that the master trying to contact it is in.

At least so far, I haven't found a reasonable way to use alternate frequencies in a dynamic situation like this

[2bndy5]

Sorry, I misunderstood the problem a bit. Sounds like you want 2 networks to exist while their non-master nodes can connect to either network? I don't think the libs were written for this scenario. You could try to implement timeslots, where in each timeslot is a window of time devoted to a certain channel (like channel hopping behavior of bluetooth). For a visual aid I'd defer to the Gazel lib from Nordic Semi

[SirWillian]

Yeah, non-master nodes can connect to any network initially (they would persist on this network afterwards). I figured by now the libs weren't made for this scenario, but I need to handle it somehow. Timeslots sounds like an interesting idea as long as it doesn't introduce too much delay. I'll study this possibility along with manual acknowledgement like I mentioned originally.

[2bndy5]

non-master nodes can connect to any network initially (they would persist on this network afterwards)

then only check for master node (of a certain channel) in a non-master node's setup()

as long as it doesn't introduce too much delay

The network topology and radio limitations don't really satisfy speedy implementation, but my advice about only changing channels in setup() would help limit the detriment of latency in loop()

[SirWillian]

I wasn't as worried about the latency in loop() as I was worried about the latency in the communication between the master and the slave until they sync their frequencies and do the actual connection. It's the master that decides "this node will be part of my network now". If I waited in setup() until I get my connection, it would turn into a loop at that point.

[2bndy5]

@SirWillian Have you been able to reach a solution for this? I'd be interested in implementing/PR-ing an optional solution for this.