johnnybravo

For all Mac users: why don't you keep the security on and start the unsigned package holding the option key? I remember, it was the solution for my own compiled apps. It should work for energies as well.
 
 
Sent using Tapatalk

Oh gotcha... Umm, couldn't quite follow what you wrote but let me explain addressing:
 
The RX address is the only address the transceiver will look for when watching the air in RX mode.
The TX address is just stored on an internal buffer in the transceiver so it knows where to send the next packet you transmit.  There is no way to supply both the TX address and the packet payload in one SPI command, so instead you have to load the TXaddr using .setTXaddress() and then issue your writes and/or flush.
 
nRF24L01+ packets only have one address in the frame--the destination address.  There is no "source" address to reveal who the packet came from.  Therefore you can have any address you want loaded into the TXaddr buffer for any of the transceivers, in terms of response the transceiver will only react to packets bearing its RX address.  You just have to make sure you change the TXaddr value if you wish to send data to a different transceiver/MCU node.

Q1: It certainly is, in fact there is no such concept as a "broadcast" with the nRF24L01+ (multiple devices can listen on one address but you have to turn autoack off to do that).  Just have each node register with a unique RX address and the root node/gateway can hit them individually.
Q2: It is possible to switch quickly, and my latest git commit to Enrf24 reworks flush() so it will do just that--it detects if RX mode is enabled and makes sure to re-enable it once it's done transmitting.
Scanning about 100 nodes per second gives you around 10ms per node, which might be a tall order with this stuff though.  I'm assuming for the size of the network you're talking you'll probably have the various nodes spread apart a bit, so I'd suggest 250Kbps mode which doesn't allow auto-ack anyhow (autoack can consume a good bit of time).  Keep the "scan" message very short and 10ms per node might be doable.  Never really tried it myself.  If your main loop is pretty tight on the slave nodes (watches the .available() method frequently and reacts quickly, turning around to TX when it's validated a scan request from the root) it should be fast.
 
Just be sure the root node spends a short delay--start with 10ms perhaps, watching for an RX reply from the slave node before it gives up & goes on to the next one.  You don't want the root node to move on to the next slave node, entering TX mode when in fact the previous slave node is trying to transmit (the root node will miss its message and/or cause an over-the-air collision).
 
An example of implementing this 10ms delay would be:
boolean rxready; unsigned long mstart = millis(); while ( (millis() - mstart) < 10 && !(rxready = nrf24.available(TRUE)) ) ; if (rxready) { // Process slave node's reply } // Else the slave node never replied, and we timed out the 10ms window.  
 
On both the remote node and the root node, use .available(TRUE) for performance; it will check the IRQ pin state first to determine if there's any IRQ present, saving some time by having it NOT poll the transceiver over SPI to determine whether an IRQ has fired or not.  It should help tighten up the response time all around.  (With .available() or .available(FALSE), it will go out and physically talk to the nRF24L01+ chip over SPI to determine if the RX queue is empty in order to determine whether data is available or not.  Takes a little more time.)
 
Anyway I realize you are new to Energia so I apologize if I explained a bit too much