[last updated: 2020-03-16]
nRF24 Home page
go to: nRF24 Software
(link to:) tmrh20.blogspot.com
-----
This is a proposed/tentative configuration
- System composed of a Master node 0 and some number of remote nodes.
- All nodes, each in receive mode by default, listen on their pipes[nodeID] address for messages addressed to them. This of course requires that pipes[ ] is defined with an element for each node in the system.
- Each remote node has an ID assigned to it (its nodeID). The master node assigns ID's sequentially when the remote node comes online and requests to join the network. This means that a given node, ie. a specific piece of hardware, may sometimes be connected to the network with one nodeID, and if taken offline and then put back, may be assigned a different nodeID.
-----------------------------
- Master node 0:
- always listening on pipes[0] (its nodeID)
- also always listening on pipes[IRQ] for emergency RTS
- if IRQ RTS request is received, everything in process (on task list) is suspended to handle the new emergency request.
-
- maintains (and periodically verifies) list of online nodes.
- how handle nodes that are out of reach with one hop?
- bool iAmMaster flag will be set and saved to eeprom.
After reset (ie in setup), eeprom is checked to see if this node was master before reset,
and restored if so - but can other nodes have taken over as master?
another flag for nodeID of actingMaster?
-----------------------------
- Master Task List:
- a list stored in eeprom containing two fields: first is priority rank of the task, second is a code to identify the task itself.
- when a task is finished, it's removed from the list
- a timer in main loop will periodically add tasks to the list (eg. check status of all remote nodes)
- if a RTS IRQ request is received, the task requested is added to the task list
-----------------------------
- Message/Traffic Control:
- Some nodes just monitor things and report back to master when they're polled
- Some nodes connect to time-critical sensors, so that when they are triggered,
they need priority communication to the master;
therefore: an additional receive pipe open on all nodes
designated as emergency IRQ
- When a node has an emergency communication to send, it first sends a RTS on the IRQ pipe
- When master rcvs it, it evaluates the request, and puts it onto its task list in appropriate ranking
- ?? an additional receive pipe open on all nodes
designated as request to transmit (ie non-emergency)?
-----------------------------
- Functions needed:
- void nodesOnline() {}
polls list of potential nodes and sees which respond
makes a list of those that are online
- void addNode() {}
adds a node to the network
-----------------------------
- Hardware:
- PB to toggle enable/disable of panel LED's
- LED to blink number of this node?
initiated/triggered by what?
- PB to initiate changing nodeID?
- PB to reset Arduino? PB to reset nRF module?
- PB to initiate requestJoin network;
master responds by assigning a nodeID
- Each hardware node, however, will have a unique ID, that being its MCU ID, eg. UN-008 or whatever. This ID is already saved to eeprom.
-----------------------------
.
.
.
eof