ACK using send/receive Struct example

[addotson]

I have been building wireless datalogger using the struct send/receive example code bits but am having issues with the ACK.

On the node loaded with the receive code, every 3rd transmit from the sending node is an ACK, but the ACK does not follow the payload format of the struct so it results in a message of invalid payload. 

Is there a code snippet to handle this that has been developed or will I have to develop my own?

Thanks in advance for the help.

-Aaron

[Felix]

If you use structs, then both ends have to be in agreement of what is sent and received (the struct itself).
You could interpret the payload differently if it's an ACK of course, you just need to know what to expect.
Usually ACKs are empty packets that only serve the purpose of saying "All is OK I got your real packet, you dont need to resend". But you're needing to also put a payload in the ACK?

[addotson]

No payload needed it was just not receiving it nicely because of the struct I think.  I will give it a few tries to try to allow it to receive something simple.

Thank Felix!

[DonpK]

As a newbie, I'm trying to understand better the utility of sending and responding to an ACK packet as a way to confirm the integrity of the previously sent "real" packet.

Is it not possible for the real packet to be sent and corrupted, but the ACK packet which follows it to be received okay?  How does the ACK know "All is OK I got your real packet..." when ACKs are basically empty packets? Why not attach something like a CRC to the real packet?

[Felix]

Depends what you mean by corrupted. A corrupted transmission or corrupted data?
I think you mean data. In which case a CRC would help ensure the data integrity is satisfied. The library is kept lean without too many bells and whistles. You can get fancy in your own implementation and add features like this. In most cases though, the empty ACK is a very good indicator that a sent packet was well received when the target responds with that empty packet marked as ACK.

[DonpK]

In most cases though, the empty ACK is a very good indicator that a sent packet was well received when the target responds with that empty packet marked as ACK.

Is this due in part because the ACK packet and its response follow the main packet in a matter of milliseconds and most signal disruptions are of longer duration so they would tend to affect both the main and ACK packets?

Would having the receiving node simply send a return packet which follows its receipt of real data packet saying "Yes, I just received your data packet" and possibly including the DATALEN in that return packet be as effective as sending a separate ACK request and a return ACK from the receiving node?

[Felix]

Again, depends how fancy and bullet proof you want to get.

I would not go as far as sending a "Yes, I just received your data packet" string back in an ACK, you're just going to spin CPU wheels and memory reading that back and forth.
A CRC would be much more appropriate. If you want really strong protection then make up a two or more bytes CRC. Even 2 bytes CRC is really strong.
You could calculate that same key at the sender and upon ACK receipt, you can compare the returned CRC to your local key.