Network Default Address (clarification please)

[luudee]

Hi !

First of all I would like to say you are doing an absolutely excellent job developing this library !
I am working on a large project that will deploy thousands of nodes over a wide area !

I understand the network topology, and you state in the online description that 05555 would
be the highest address achievable, supporting 3,125 nodes. However, it appears you are
using 04444 as the network "default address". I am not sure I would really use the 3,125
nodes, but I can see how in my case 04444 could belong to a valid node.

Is it ok to change this value to 07777 as there would be no real node with that address ?
I am a bit confused what the purpose if this address is anyway. Could you be so kind and
comment on this ?

Also, may I humbly suggest to not hard code values like 04444 but rather use defines for
this ? It would make future changes and upgrades so much easier. :)

Many Thanks,
rudi

[TMRh20]

Is it ok to change this value to 07777 as there would be no real node with that address ?

Good question.

The 04444 address is from RF24Mesh development. New nodes use it while requesting addresses. It should be changed to an unused address like 07777, but the details need to be worked out & tested.

Also, may I humbly suggest to not hard code values like 04444 but rather use defines for
this ?

Yeah, it is defined in RF24Mesh, but maybe should be defined in network layer... the whole thing needs a review.

[2bndy5]

Is it ok to change this value to 07777 as there would be no real node with that address ?

I was going to ask the same thing, but we need to use an address that would pass is_valid_addr() check (0777 will not). So, the default address needs to only have digits 1-5 (0 is reserved for master & 0100 is reserved for multicasting). I like the idea of using 07777, but it would require adding a conditional statement to is_valid_addr(). Not to mention that this change would also break compatibility with existing network nodes that don't get updated if we do change the network default address... I'll add a note to the RF24Network docs.

[2bndy5]

Is it ok to change this value to 07777

I was pondering this again... With the recent addition of nRF5x support (which can use 8 pipes), I think the sentinel value 07777 becomes a valid address when NUM_PIPES is set to 8. Ultimately, I'm hesitant to change NETWORK_DEFAULT_ADDRESS value at all due to backward compatibility issues because every node in the network would need to be updated.

If we do change this (to properly allow a mesh child node to actually use the assigned address 04444), then it would have to be something that is not a valid address under any situation.

Given that there are 5 network levels and level 0 is master, the addresses rarely use the 3 MSBits in a signed 16 bit variable (excluding the signed bit); 3 bits are allocated for levels 1-4, meaning signed octal 7777 is signed binary 000 1111 1111 1111. I believe these top 3 bits could be compared with sentinel masks to quickly identify when the address is being used for a special purpose.

• 0b101 << 12: multicast to level 0. This is probably never needed as level 0 only has 1 node, but if multicasts are relayed to higher levels...
• 0b001 << 12: multicast to level 1
• 0b010 << 12: multicast to level 2
• 0b011 << 12: multicast to level 3
• 0b100 << 12: multicast to level 4
• 0b110 << 12: MESH_BLANK_ID (see RF24Mesh::getNodeID())
• 0b111 << 12: NETWORK_DEFAULT_ADDRESS (& synonymous with MESH_DEFAULT_ADDRESS)

Notice the above mask examples do not use the MSBit (1 << 15). This is because RF24Mesh::getAddress() & RF24Mesh::getNodeID() currently can return a negative number (-1 and -2).

[TMRh20]

If we do change this (to properly allow a mesh child node to actually use the assigned address 04444), then it would have to be something that is not a valid address under any situation.

And I'm not sure that would work, because it would need a valid address of some sort to function with RF24Mesh.

I believe these top 3 bits could be compared with sentinel masks to quickly identify when the address is being used for a special purpose.

Interesting, would that make things more or less confusing? 😄

[2bndy5]

All of this conjecture is aimed at allowing mesh child nodes to be assigned 04444.

I think it could be made just as confusing if the code is written "adequately." 😝

because it would need a valid address of some sort to function with RF24Mesh

Yeah, I glossed over this. I think that valid addresses could still be used, but the identity of nodes without an assigned address would be determined by masking the address...

#define NETWORK_DEFAULT_ADDRESS 070000 // 0b111 << 12
if (header->from_node & NETWORK_DEFAULT_ADDRESS == NETWORK_DEFAULT_ADDRESS) {
    // node is trying to connect
}

bool isValid = is_valid_addr(header->from_node & 07777);

[2bndy5]

Looking at how my masking idea would be implemented, I see how it would compromise multicasting. I really thought I was on to something, but to use a mask instead of a sentinel would need an overhaul of address-to-pipe handling... Nevermind. I guess child nodes can never actually use address 04444. 😞

[TMRh20]

Well ideas are like that sometimes, you gotta poke around a little to see if they work.