RF12Demo sketch - not sending ack

(6 posts) (3 voices)

Tags:

No tags yet.

mikep
I just built my first JeeNode (v4) and also hooked up an RFM12B to an arduino and loaded the latest version of the RF12Demo.pde sketch on it (from here http://code.jeelabs.org/viewvc/svn/jeelabs/trunk/libraries/RF12/examples/RF12demo/).
Everything is working fine, I can send data between the 2 nodes, except, the "ack" is not working. If I send a broadcast ("t"), the receiving node is sending back an "ack" My node ids are 5 and 6, if I do this from node 6: "1,2,3,5a", node 5 receives the data fine, but does not send an "ack" back.
If I do this from node 6: "t", node 5 receives the data fine and sends an "ack" back.
I think I tracked down the issue to this line in the RF12Demo sketch:
```
            if ((rf12hdr & ~RF12HDRMASK) == RF12HDRACK &&
                    (config.nodeId & COLLECT) == 0) {
                Serial.println(" -> ack");
```
If a broadcast is sent from node 6 to node 5 then the rf12hdr looks like this (binary): 00100110 If a data packet is sent using "1,2,3,5a" from node 6 to node 5 then rf12hrd looks like this: 01100101
Note that bit 6 is set now (which is the RF12HDRDST flag).
So the statement "if ((rf12hdr & ~RF12HDRMASK) == RF12HDRACK)" will not return true, even if the bit 5 is set (RF12HDRACK) and no "ack" is being sent.
The result of (rf12hdr & ~RF12HDRMASK) is 01100000 which is not equal to 0100000 (FR12HDRACK).
Am I using the demo sketch wrong? Is an ack only send back for broadcast packets or what is the purpose of the RF12HDRDST flag?
Thanks, Mike
Posted 13/06/2010 16:42:56

jmr

I discovered this behavior as well but i think it's just because of the lazy programmer :-) Have a look at the sketch:

    575             case 't': // broadcast a maximum size test packet, request an ack
    576	                cmd = 'a';
    577	                sendLen = RF12MAXDATA;
    578	                dest = 0;
    579	                for (byte i = 0; i < RF12MAXDATA; ++i)
    580	                    testbuf[i] = i;
    581	                break;
    582	            case 'a': // send packet to node ID N, request an ack
    583	            case 's': // send packet to node ID N, no ack
    584	                cmd = c;
    585	                sendLen = top;
    586	                dest = value;
    587	                memcpy(testbuf, stack, top);
    588	                break;

line 582 should be responsible for your problem: actually cmd 'a' and 's' are treated in the exact same way (note that there is no break). therefore, no ack because cmd a is mapped to c...of course this is only a sample sketch. i recommend writing your own sketch by looking at the pingpong-example and for acks and so on at the r12demo.

GER-AUS: 4:0 yeaaaahhhh

Posted 13/06/2010 21:27:13

jcw

> cmd 'a' and 's' are treated in the exact same way
I don't think that's it. The global "cmd" variable will be either 'a' or 's' and is checked later on in loop().
> Is an ack only send back for broadcast packets or what is the purpose of the RF12HDRDST flag?
This is a tricky case. Note that either a source node ID can be sent (in broadcasts) or a destination node ID can be sent. In the latter case, the RF12demo receiver has no knowledge who sent the packet. So it could only reply with a broadcast ACK. I haven't yet figured out what the implications are or broadcast acks, since nodes may not be tracking what they sent, so they might interpret the ack as applying to somethign different from what was intended.
There is a solution, at a higher level: 1) include the source node ID somewhere in the payload, if the received cannot deduce it implicitly (as would be the case if there always are only two nodes in the group), 2) generate the ACK from the receiving end, i.e. the code on the PC behind RF12demo.
As @jmr suggested, you could write your own receiver (or tahe RF12demo and create a custom version).
I'm trying to keep the protocol overhead absolutely minimal, and not including both source and destination IDs is one consequence, but I realize that I may be pushing a bit too hard toward this sort of minimalism.

Posted 13/06/2010 22:28:52
jcw

To follow up: the rf12hdr bits are a bit odd, in hindsight. I've not yet gone in to change this, because I haven't figured out yet how they should be in the next version of the protocol. I need to go through some more use cases. Suggestions / comments welcome.

Posted 13/06/2010 22:32:52
mikep

Thanks for the follow up. I realized the same thing by looking at the code some more: - if a broadcast is sent (RF12HDRDST == 0), then the source node is is sent in the lower bits - if a targeted packet is sent (RF12HDRDST == 1), then the destination id is in the lower bits so there is no way for the receiver to know who sent it.
I will probably just send the source node it somewhere in the payload, in order to be able to re-use the existing protocol. By the way, thanks for all your great work on this Jean-Claude, it definitely makes it much easier to get started with these little RFM12B modules.

Posted 13/06/2010 23:17:59
jcw

Heh - you're welcome. It's always nice to be appreciated :)

Posted 14/06/2010 00:09:32