changing nodeid at runtime

[lemonforest]

Hi,

I don't have the devices in my  hands at the moment, otherwise I'd give it a shot. I'm interested in changing the nodeid at runtime and was curious if this is done with SetAddress(). Comments in the header say that it isn't used in packet mode which leads me to believe that this is not the function I'm looking for. Are nodeid and address the same thing or no? I did find subject matter on SetNetwork which I believe I could still use to accomplish one-time randomized pairing of two devices, and with a greater range of values it would appear.  It just seemed more obtuse to go about changing the network vs nodeid since traffic on another network is either not observed or simply ignored.

Also found out that I should have been using doxygen longer than just today after searching the forum for a general reference to all the things so that was a nifty find!

Thanks!

[Felix]

Here's that function:

Code: [Select]

//set this node's address
void RFM69::setAddress(uint16_t addr)
{
  _address = addr;
  writeReg(REG_NODEADRS, _address); //unused in packet mode
}

The register written value is not used in packet mode, which is how the library works, but it is written for completeness sake. I should probably either remove that since it's not done in the initialize() either, or uncomment it in initialize() for consistency.

Anyway the answer to your Q is YES, calling this function will change this node's ID. This is TRUE for both sending and receiving, unless you turn on spyMode for receiving to disable address filtering when receiving.

[lemonforest]

Thank you for the reply! I think were I'm confused then is in thinking that your library is focused around rxtx in packet mode. Clearly I'm far being done reading.

[lemonforest]

Okay, I'm back after some SX1231H reading.  It looks like Node ID and Address Byte are regularly used interchangeably and not part of the packet header but NodeAddress only comes up when they talk about address based filtering but then mentions that it does pull it out of the payload indicating that all 3 nomenclatures are the same thing.  From what I'm also seeing, it looks like it does support address based filtering in packet mode and even uses the same sync word match interrupt.  I am seeing that if the Tx radio doesn't have address filtering reg set and is using encryption, then it will encrypt the address byte.  Is it maybe the SX1231 that didn't use it in packet mode? I only checked the SX1231H datasheet.

On a different note, well two - 1; is gatewayid in the preamble or is the nodeid? 2; node.ino says address id's are 10bit now but does that mean network id's? I see where the datasheet says it can be set from 0 to 8 bytes whereas address is just a byte.

[Felix]

Here's the current packet structure with 10bit addressing, this should answer all your questions:

[lemonforest]

Thanks for the graphic! I didn't even know to look for that and just figured I'd study the source eventually to see how the packets are formed (and I still should/shall).

Ok, I think I see where things become different vs the datasheet;



The address byte there, as it's optional, is not used the way your library forms the packet and the nodeID is actually contained inside what the radio considers the message block.

However, that does leave me with more questions/thoughts.  Regarding encryption of the to-NodeID, from what I gathered yesterday looking over the datasheet, the only way to enable the radio defined address byte is to enable address based filtering which can only be set to match the NodeAddress or match the NodeAddress or BroadcastAddress.

So possible advantages of do so would be;

• the NodeAddress is not part of the AES encrypted payload (when encryption is enabled on Tx and Rx endpoints) and can keep the radio from triggering an interrupt instead of having the uC decide if it should be the packet recipient allowing it to stay asleep if other nodes are chatting on the same NetworkID. (the NodeAddress is not stripped from the packet and remains on the FIFO so the uC can still see if it was a NodeAddress or BroadcastAddress which set SyncAddressMatch)
• the frame now only includes from-NodeID byte, ctrl byte, and msg bytes whose length can now be up to 62 bytes and still support AES ops.

Disadvantages would be;

• rework on the library would be required for sorting out NodeAddress/BroadcastAddress from the FIFO since it's no longer apart of what the radio considers the Message Bytes
• NodeID is no longer 10 bits causing further library rework and requiring existing projects to go back and re-implement nonzero 8 bit NodeIDs
• loss of the current method which offers easy adjustments to NodeID size (quite cheaply be taking away a single message byte) if ever warranted

Seems like I could go on arguing for and against address based filtering vs NodeID in the frame and, frankly, more disadvantages seem to tumble out of my head with the only real advantage of address based filtering being that it would allow neighbor nodes to let the uC continue sleeping if it wasn't an address match but similar results could be had from using an unused sync word.  What this does seem to indicate is that there could be a public member to change a nodes ID at runtime and, since it is message byte data, could take place at any time and is something I should be able to figure out on my own.

I expect these are things that have already been talked about by the top brass so this is more of an exercise in understanding of what goes on behind the scenes and putting myself at the mercy of the cruel world internets to steer me right if I got it wrong.

[Felix]

These are very valid points, both pros and cons. When I created this library and spent a few days in the datasheet, I thought long and hard where I want to have this library be in a few years.
It was apparent that there are more advantages to have full control of the address filtering in the library, than do it natively in the radio.

Some people are upset that there is the added expense is the extra cycles of doing things in firmware, and this and other things like that are breaking the ten commandments of low power. MEH.

Here is something real: this library is out there in very many Moteinos and custom boards I designed and manufactured myself, in environments where they have be be solid for "eternity" and cant fail, very low power lasting many years on small batteries. Everyone has been super happy with the performance and low power, haven't had performance issues or someone complain that a library feature is limiting them in any way. When the rubber meets the road, what matters is that the library works, with the same base structure and RF settings since inception. I have nodes programmed 7+ years ago and they still work with today's library.

[lemonforest]

Oh, don't get me wrong. I'm perfectly satisfied with the library. The previous post was to find out if what I thought I knew was actually correct and that I wasn't off course.  I could say that not having a dedicated usage manual was bothersome but the fact is that I wouldn't have developed the same understanding that I have now had I just used a programmer's reference or settled for defaults in the examples to get me to the end. The examples were actually enough to get a project to completion but still wanting for a programming reference has brought me a doxygen reference of the library with code snippets that's quicker to break down and much more knowledge of the sx1231h than a programmer's reference would ever included. This post is from my phone so apologies for the wall of text about to appear.


Edit: Well look what I found doing a reverse image search; https://lowpowerlab.com/2013/06/20/rfm69-library/ Dated in 2013, you explicitly stated the reason for not using the radio's address based filtering! I kinda feel bad now asking questions that you'd already addressed 7 years ago and have probably been answering again and again for folks like myself late to the party. 

For the sake of completeness, from what I've gleaned in this thread and the datasheet, one could argue that (and again, I'm not. I'm simply looking at it from the opposing viewpoint) if the broadcast address was used and address based filtering was explicitly set to accept self and broadcast targets, promiscuous mode should still snoop the packet 1) address based filtering is enabled on the endpoint and listener 2) encryption is enabled on the endpoint and listener 3) non-zero 8 bit NodeID must be used 4) packet target must have broadcast address set as destination all the time to take advantage of packet sniffing 5) you like arguing for the sake of the argument.

Now that's a lot of conditions, most of which don't even meet the criterion rational logic of needing to capture all traffic on a syncWord unless you fancy making the broadcast address always set and encode the real recipient in the library frame.

I think I'm developing a hankering to find and consolidate these bits of quite useful information so that it's easier to find, and thus consume, for those of us (or just me) that don't even realize many, if not all, the answers related to the library have already been answered, quite possibly, several years ago.

Starting to feel like a broken record with this line but, again, thank you for making this all possible and the willingness to answer the same things over and over, year after year!

Another Edit: I failed to notice at first that the post also pertained to the 12B of which I've read nothing about so it's quite likely that everything I said about the sx1231h might not apply to the IC that radio uses. My bad :/