Hi,
Looking at the RFM69 library, I see that Node ID and broadcast filtering are not done by default by the hardware, but by optional software configuration.
The consequence is that each frame must be fully received by a node, before filtering occurs, while with the hardware filtering a frame is discarded at an earlier stage. This looks to me more efficient especially in a low power consumption environment.
What is the reason the hardware filtering is not done by default?
Thanks in advance
Robert
Hi Robert,
It's a tradeoff and basically there's a little more control that you have by owning that control in software, although it might not be apparent.
If hardware does it you never know you got that message, and in fact the message is actually clocked into the RF chip before the RF chip decides to discard it, so the transfer is complete and it's not saving anything on the RX end. The only overhead with software filtering is that the chip raises the interrupt and the filtering is done in the interrupt handler, so some extra cycles on the MCU. You can always switch back if you want by altering the header and the interrupt.
Felix,
Thanks for your reply, I understand your concern in a test environment, but I believe that in a "production" one it should help to keep the power consumption as less that possible.
I will try to see if I can prove that by actually measuring battery consumption.
Robert
My guess is you will not be able to tell a noticeable or significant difference. To actually see the consumption at that level I think you will need a very good scope.
Also the node that is running on batteries will likely be in sleep most of the time and will never receive the vast amount of other packets.
@Robert, I would like to see your data when you've collected it, but I have to agree with Felix, I'd be stunned if the difference is even measurable. The bulk of the power is consumed in the radio front end which would be active whether receiving or simply sitting in RX mode (in fact, due to AGC circuit, it might even be less if there is an RF signal to receive although this is purely WAG).
As Felix pointed out, the lowest power is achieved by sleeping (no RX at all) with the lowest permissible duty cycle required to meet your application requirements.
I'm not sure what you meant comparing 'test' vs 'production' mode. I didn't pick up any reference to either in Felix's post.
Tom
Hi Tom,
Yes a agree that may point is more theoretical than practical, if most of the time of a node is spent in sleep mode. However I refer to several notes of JC Wippler (JeeLabs), looking at all the ways to save energy.
Activating node address and broadcast filtering is straight forward, so why not to used by default if there is no drawback.
Another aspect is the analogy with Ethernet; to avoid network flooding, a controller looks at the destination address (unicast/multicast) and protocol type (or SAP), if it doesn't match the receiver configuration, the subsequent bytes of a datagram are discarded, this to save computer cycles.
Talking about 'production' environment, I mean a well configured network of nodes, for which actual testing of the destination address should not be necessary, avoiding each node to listen to the full RF frame before deciding if the dadagram is to be computed yes or not.
Robert