Flags in RFM69 header byte

Added by Rolf about 2 months ago

The RFM12 header byte leaves the three most significant bits free for flags (destination, ACK, ACK-request, as defined in JeeLib). With RFM69 there are only 2 bits available (should not be a problem, because the destination bit is obsolete in RFM69 native mode, as I understood). I was thinking to use these bits for an ACK-mechanism (not yet implemented?), and recognized that they are already taken, for a "group-parity". But again, no problem, I can still use the upper 2 header bits for flags when sending a packet, they just appear in the receivers "sender byte" (second byte of the payload). This makes the implemantation of an ACK-request-confirm mechanism easy. (Right? The information comes from my interpretation of the RF69 driver).

I have 2 questions in this context. Is it reasonable that I implement my own ACK-mechanism, perhaps there is already a plan for a general solution?

Why is this "group-parity" necessary? It rejects packets, when sender and receiver are not in the same group, which is set in RF-init. But, what are "groups", different RF-channels? In the RFM69 manual I saw "channels" and "carrier frequencies". Aren't "groups" filtered at the RF hardware level?

Replies (3)

RE: Flags in RFM69 header byte - Added by martynj about 2 months ago


The Group is a software-only multiplex mechanism - NodeID nests below Group so this acts as a nominal separator of traffic that is sharing the same carrier frequency (channel). The concept was established with the RFM12 packet format.
The Group is actually filtered by the receiver hardware during the incoming packet identification since it is part of the SyncAddressMatch mechanism, unfortunately this bit pattern is outside the CRC check mechanism. To reduce the small risk of a bit corruption in the header of a valid packet from a different group matching the expected group, a parity check is worthwhile. The alternative is to have Group encodings 'far apart' (e.g. at least 2 bits Hamming distance) to reduce the chance of misidentification to negligible. This would place the discipline on the user (who may well just assign sequential group numbers) rather than the driver.

RE: Flags in RFM69 header byte - Added by Rolf about 2 months ago

@Martyn: Thank you for the enlightment!

RE: Flags in RFM69 header byte - Added by jcw about 2 months ago

Maybe this helps clarify the group-parity:

The group parity bits only apply to the following scenario: node in group 1 sends a packet, node in group 3 is listening, and (accidentally) picks it up - if there is one bit error in the group, it could pass, but then the group parity will catch it. Same for any two groups which differ in at most 2 bits (since its parity is calculated separately over bits 0/2/4/6 and 1/3/5/7). In other words: these parity bits are only used in the case where you are using multiple groups (or your neighbour is). The key here is that a packet of which only the group is damaged between sender and receiver is still a valid packet, as far as the CRC is concerned, since the group ID is not part of the payload but part of the sync bytes before it.

Yes, the two remaining bits in the source are intended for the same bits as in the RF12 driver. The dst/src bit in the RF12 is not needed here since both fields are always included in every packet.

I have not yet implemented ACKs in the RF69 driver, but plan is to mimic what's in RF12, i.e. 3 cases: plain send, request ack, and reply ack. The fourth case is reserved for special packets, for node announce and other "out of band" control packets.