Moteino responds to RFM69 packet not addressed to it

[CallMeYaz]

I am using the latest RFM69 library that Felix posted a few weeks ago with the Arduino IDE 1.61.

I have 2 nodes in my design. The master has a NODEID of 1 and the slave has a NODEID of 2. The master sends a short "poll" packet addressed to the slave and the slave responds as I have coded. No ACK is requested and no ACK is sent. This works great.

Then, the master sends the same "poll" packet addressed to NODEID 3 to verify that my timeout code works by not locking up waiting for a response from a missing node. If the master doesn't wait about 80 ms or more from the reception of the existing slave's response to the transmission of the missing slave's poll, the existing slave responds by mistake. The existing slave takes about 40 ms longer than normal to respond in this case, though. I don't change anything except the delay between the version that works and the version that doesn't.

Has anyone seen this before? Does anyone have any ideas about what I could be doing wrong?

Thanks

[TomWS]

I am using the latest RFM69 library that Felix posted a few weeks ago with the Arduino IDE 1.61.

I have 2 nodes in my design. The master has a NODEID of 1 and the slave has a NODEID of 2. The master sends a short "poll" packet addressed to the slave and the slave responds as I have coded. No ACK is requested and no ACK is sent. This works great.

Then, the master sends the same "poll" packet addressed to NODEID 3 to verify that my timeout code works by not locking up waiting for a response from a missing node. If the master doesn't wait about 80 ms or more from the reception of the existing slave's response to the transmission of the missing slave's poll, the existing slave responds by mistake. The existing slave takes about 40 ms longer than normal to respond in this case, though. I don't change anything except the delay between the version that works and the version that doesn't.

Has anyone seen this before? Does anyone have any ideas about what I could be doing wrong?

Thanks

Dumb question maybe, but is promiscuous mode set on by mistake???  That's the only explanation I can think of.  Also, do you have encryption set or not?  This should improve data transfer reliability.

Finally, just out of curiosity, why don't you want to use sendWithRetry and Ack?  It seems that you have to build some other code (like your timers) to achieve a similar result, unless I'm missing something.

Tom

[CallMeYaz]

Tom,

Thanks for the questions. I will try to answer them and provide additional information that I have learned tonight.

These modules are modified versions of the examples provided by Felix, so :

1.  Promiscuous mode is still off
2.  Encryption is still set
3.  ACKs - This is where my ignorance may shine through. It is my belief that anytime 2 or more radios are transmitting at the same time, there will be a collision and no receiver will receive a valid packet. If sendWithRetry and Ack were relied upon, this could happen fairly often with many nodes transmitting asynchronously to each other. The result would be the nodes wait awhile and resend and thereby probably colliding again. My plan with the master/slaves was that no slave transmission would ever occur unless the master requested it (about every 5 seconds). Therefore, no collisions. There is no point to using sendWithRetry and Ack in this scenerio because even if that handshake was successful, the master still did not get the actual data from the slave. Yet another transmission must be done for that. I will consider having the slave retry with Ack when I get that far.

I have renamed the Subject because additional testing has proven that the problem is not in the slave. It is a result of the master calling the receiveDone() function after sending a very short packet to a nonexistent node address. That function is erroneously returning true about 39 ms after I initiate the transmission unless I put the delay in that I described in my original post. It only takes about 10 ms for it to correctly return true when the packet is sent to an existing node address.

Hopefully, someone else will try this, confirm my results, and offer a solution.

Thanks,
Ron

[Felix]

@CallMeYaz
The RFM69 library ignores packets not addressed to the node, unless in promiscuous mode.
receiveDone() is used for receiving, not for sending. You say you call that function after a pure send (no ACK) and expect a true after sending to an existing node. That makes no sense unless the node responds with a packet of its own. Also, ACKs are just regular packets (usually empty payload) but with a header byte flag set to indicate the ACK-ness.

[CallMeYaz]

I believe that I am sending a packet to and receiving a reply back from the addressed node correctly because that part works when the node exists.

I was calling receiveDone() because I had just sent a pure packet (no ACK) to a node that usually exists and was expecting a reply pure packet (no ACK, but including data) from the other node. If the other node is "offline" the return packet is obviously not going to be sent. Is there some other function I should be calling to see if the other node sent a packet?

So, you are saying that I could include data in the same packet that has the ACK header byte flag set if I used sendWithRetry and ACK? I'm sorry, but I didn't realize that. I will look into it.

Thanks,
Ron

[Felix]

Ok now it's more clear what you're trying to achieve.
So all you'd have to do is call receiveDone(). That polls the library to check if a packet was received and is ready for pickup from the library buffer.
That should only return true when a packet is truly received and was addressed to this node or node is in promiscuous mode.
And yes you could totally send an ACK and include some data in the payload, use this:

void RFM69::sendACK(const void* buffer, uint8_t bufferSize)