Hi,
here is what I found/figured out regarding the usage of Broadcast and promiscuous mode:
all listening radios will receive all packets but will filter out the packets not addressed to them unless promiscuous mode is true.
if promiscuous mode is true the listening radios can query who the packet is for with radio.TARGETID
and read the data if it wants to and possible reply to the sender (radio.SENDERID) I heard you but your send is not for me.
I wonder how promiscuous mode true differs from setting the destination nodeid to BROADCAST address 255?
I think sending to address 255 aka BROADCAST mode will never request an ACK
I think a receiver can reply to a Broadcast by sending to radio.SENDERID.
I think in promiscuouse mode true the listener can decide whether or not to send the ACK if one is requested.
see https://lowpowerlab.com/forum/index.php/topic,228.msg976.html#msg976
or an example of send and receive in promiscuous mode true
Question:
Do I have the differences correct?
Thanks
Promiscuous is a word with a bad connotation. But in the library it means a node can listen to all the traffic on the same network, from any node to any node. Broadcast means a packet sent by a node will be received by all listening nodes on the same network.
Yes you can reply to a broadcast but it makes no sense in most cases and the broadcaster would have to listen for the reply. When the broadcaster speaks nobody else talks back, except in exceptional situations.
Quote from: Felix on December 16, 2014, 10:03:03 AM
Promiscuous is a word with a bad connotation. But in the library it means a node can listen to all the traffic on the same network, from any node to any node. Broadcast means a packet sent by a node will be received by all listening nodes on the same network.
Yes you can reply to a broadcast but it makes no sense. When the president speaks nobody else talks back, or they get arrested. Makes sense?
To my mind, the roles for Broadcast and Promiscuous are very different. Promiscuous would be used (assuming you have the proper encryption key) to monitor and possibly log traffic or if you are a 'repeater', then this allows you to forward traffic to other repeaters/gateways. Broadcast, on the other hand is where 'you' have something to 'say' and either don't know who to send it to OR want to send it to EVERYONE (again, assuming you have the same Network ID & Encryption key - thanks for that!). For example, you're a new Mote that has just been deployed and you don't know the id of your nearest Gateway - you could Broadcast, "HEY! Is there is gateway or repeater out there?!!"
A Gateway or repeater might reply to this, other nodes would think, "Go away, I want to sleep..."
This allows a new Mote to get set up with an ID that doesn't conflict with anyone (assuming the Gateway or infrastructure manages that) or get connected to a specific type of endpoint.
An example of this latter case is my Dust Collection system in my workshop. There is the Dust Collector controller, which turns on/off the Dust Collector and open/closes blast gates based on which equipment needs dust collecting, and there are a bunch of DC remotes that monitor current of the equipment plugged into them and sends a signal to the DC Controller when there is any change. When first deployed, the DC Remotes don't know WHO (ie, which NodeID) the DC Controller is. The DC Remote, on first deployment, can Broadcast for a Gateway to get a non-conflicting node ID and then use Broadcast to find a DC Controller (there is only one, thank goodness).
Net: I'm glad you've implemented both and they both have a distinct purpose.
Tom
Quote from: TomWS on December 16, 2014, 07:48:56 PM
To my mind, the roles for Broadcast and Promiscuous are very different. Promiscuous would be used (assuming you have the proper encryption key) to monitor and possibly log traffic or if you are a 'repeater', then this allows you to forward traffic to other repeaters/gateways. Broadcast, on the other hand is where 'you' have something to 'say' and either don't know who to send it to OR want to send it to EVERYONE (again, assuming you have the same Network ID & Encryption key - thanks for that!). For example, you're a new Mote that has just been deployed and you don't know the id of your nearest Gateway - you could Broadcast, "HEY! Is there is gateway or repeater out there?!!"
...
Net: I'm glad you've implemented both and they both have a distinct purpose.
Tom
Tom, you've done a better job explaining than I did. In my mind broadcasting is generally like you mentioned, and I think the definition implies - a one way message from someone to everyone else. In certain situations one or more nodes could reply BUT that only makes sense when the broadcaster is expecting an answer. Your example is spot on - for instance when a node wants to inform a network about joining, or if looking for a gateway/router to pair with, it might broadcast a message, then listen for an answer - in which case the routers might reply after waiting a random amount to avoid collisions (if not already solved by carrier sense multiple access).
Promiscuous if really for situations where you have a working network and you want to "inject" a node that is able to capture the network traffic for debugging purposes for instance, but without disturbing the network at all with its own messages.
Felix and Tom,
I think I now understand how to use Broadcast and Promiscuous Mode.
I will try to write a packet sniffer using promiscuous mode and another module for Broadcasting.
For Broadcasting, in my radio senddata routine I will just change the SendTo NodeID (aka GATEWAYID) to RF69_BROADCAST_ADDR and use a send to send the packet (no ack requested) and in my Gateway receiver module I will listen for my GATEWAYID or the RF69_BROADCAST_ADDR. I can then process the packet data and decide to Ack or not.
For Promiscuous Mode, I will set up my radio receiver receiver routine to get both the radio.SENDERID and radio.TARGETID. If the TARGETID is not my NODEID I know the packet is not for me and will not send an Ack even if one is requested.
Your help has been terrific. The more I read thru your RFM69 lib code and your examples the more it makes sense.
Thanks
Tom
Quote from: Tomega3 on December 17, 2014, 09:23:48 AM
...
For Broadcasting, in my radio senddata routine I will just change the SendTo NodeID (aka GATEWAYID) to RF69_BROADCAST_ADDR and use a send to send the packet (no ack requested) and in my Gateway receiver module I will listen for my GATEWAYID or the RF69_BROADCAST_ADDR. I can then process the packet data and decide to Ack or not.
...
Rather than ALWAYs using Broadcast to reach the Gateway, what I do is have all of my nodes programmed to start with a NodeId of 250 (totally arbitrary, but normally not used in my networks). Then, when they first power up, they try to find a gateway using Broadcast. When the gateway responds, it sends to the device at ID 250 a message to change the ID to something totally unique on the network (how it determines that is entirely outside the scope of this post) and the receiving Node then saves the new ID AND the Gateway ID into EEPROM and will, henceforth, use these values, even on subsequent powerups. No longer Broadcasting.
Think of Broadcasting as shouting in a crowded room. When you're looking for someone, it may be necessary, but if you continue to do it, after you've found that someone, everyone in the room is bound to get very annoyed at you :D
Tom to Tom...
Tom to Tom
That's the best explanation to date.
It makes sense now.
Thanks