Hi, after setting up two nodes on the correct band, with id 1 and 2, node 1 is not returning OK when sending 1,1,1,2a from node 2. All I receive is >1a ->3b
when I send 1,1,1,0a I receive OK 194. Is this the correct behavior
This forum has moved to forum.jeelabs.net - this read-only archive is for reference only!
Hi, after setting up two nodes on the correct band, with id 1 and 2, node 1 is not returning OK when sending 1,1,1,2a from node 2. All I receive is >1a ->3b
when I send 1,1,1,0a I receive OK 194. Is this the correct behavior
You're sending from node 2 to node 2. Can't work. Try "1,1,1,1a" on node 2 (or "1,1,1,2a" on node 1).
Sorry, that was a typo only. I am sending the following string 1,1,1,1a.
But the result is as stated. Node 1 only replies with OK when sending a broadcast...
What happens when you exchange the two nodes?
From what you're saying I conclude that both nodes can send and receive packets, i.e. a round trip works.
I'm sure you've double-checked that node 1 is really o n e ?
Very odd. I can't think of any other explanation.
Hi, I also tried it the other way around, i.e. send 1,1,1,2a from node 1, unfortunately with the same result. Again no OK reply. But a breadcast is again acknowledged with OK
Can you show the first 3 lines or so of what each of the two nodes sends to the serial port on startup?
Node # 1 output: Current configuration: A i1 g212 @ 868 MHz ? 149 98 180 130 170 129 1 112 56 105 194 133 171 98 7 223
Node # 2 output: Current configuration: B i2 g212 @ 868 MHz
Thx (there's a special "collect mode" which doesn't ack, but that's not the case here).
Please get in touch by email and I'll arrange a replacement. Sounds like one of the RFM12B's is flakey.
when I send 1,1,1,1a from Node 2, the serial output at Node 2 is:
1a ->3b
That means it has sent 3 bytes (only the last int before the 'a' command is shown). On node 1, you should see "OK 34 1 1 1", and then "-> ack".
Oh, wait. I know what's going on!
The RF12demo doesn't ACK on packets sent exclusively to it, it only responds to broadcasts requesting an ACK.
I knew the ACK logic was tricky. Now I have proof that it's too complex - since it was wrong.
Ok, I've uploaded an update to RF12demo. The current protocol is a bit strange in that it only has room for either a destination node ID or the ID of the sender. I've got reasons to do it this way, but evidently it's confusing ... myself included.
The updated code will give you an ACK. Just keep in mind that this will be a broadcast packet, so every node will get the same ACK. What nodes need to do is ignore ACKs if they haven't sent out a packet very recently.
Please download the updated RF12demo - now also in the [ZIP](http://jeefiles.equi4.com/RF12.zip).