Project

General

Profile

Acknowledge from RFM69 -> RFM12

Added by AndreasZoeller over 4 years ago

I have a system with several JeeNodes and JNµ with DS1820 and DHT22 sensors and a reed-relay as sensor at my gascounter. They are all sending the data to my “centralstation” in the heatingroom (without ACK). Two sensornodes which have the biggest distance to the heatingroom are using RFM69CW the other ones and the central-node are using a RFM12. This was working until I made some statistics on how many transmissions are not received by the central-node. I saw that there are a lot of transmissions are lost. To improve this I changed the central JeeNode to a RFM69CW. Everything works fine until my heating started again and the JeeNode with a RFM12 sends to the central JeeNode with a RFM69 and wants to have an ACK to ensure the transmission was received. The gasmeter JeeNode get this ACK but it always has a CRC-error. I have checked this with another JeeNode (with RFM12) and the sniffer-program. I could see that the packet from the gasmeter to the central is ok, but the ACK is claimed to have a CRC-error.

RFM69 —> RFM12 (no ACK) ok
RFM12 —> RFM69 (no ACK) ok
RFM12 —> RFM69 (with ACK) ACK has CRC-error

Does anybody has experience about this ?

best regards

Andreas


Replies (23)

Acknowledge from RFM69 -> RFM12 - Added by martynj over 4 years ago

@Andreas,

How large are the ‘CRC error’ ACK packets?

RE: Acknowledge from RFM69 -> RFM12 - Added by AndreasZoeller over 4 years ago

martynj

i am just sending an ACK without any additional data.

Andreas

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

@Andreas can you tell us which library version you are using

RE: Acknowledge from RFM69 -> RFM12 - Added by AndreasZoeller over 4 years ago

@JohnO

On the central JeeNode (with RFM69) i am using the RF12Demo-lib. I am using a modified version of the RF12demo software.
On the JNµ with RFM12 i am using an older version which just can handle the RFM12. This system is running now since 10 month. On the JeeNode with RFM12 and Sniffersoftware i am using the JeeLib master.

Are there any incompatibilities known ?

Andreas

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

Umh, quite a puzzle - the problem started when your heating came back on for autumn. Could you say more about your heating system, AC supply shared with JeeNode, spark ignition each time the gas boiler cycles perhaps?

Is the new central node with RFM69CW using the absolute latest RF12Demo library?

Do you have a spare ATMega328 based node equipped with RFM69CW ? If so, could you build a version of RF12Demo from the latest library and configure it to “1c” collect mode so that it won’t ACK then co-locate it with the GasMeter node and collect its output stream. Before posting the stream do a ‘p’ command and include the output with the post.

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

Are we sure that the bad ACK’s you are seeing are indeed Jee packets?

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

Could you post some logs showing the CRC errors & ACKs?

I am not aware of any incompatibility between ACK’s of older releases and the latest RF12Demo branch.

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

and…

Which group are you using in your network?

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

JohnO wrote:
> Do you have a spare ATMega328 based node equipped with RFM69CW ? If so, could you build a version of RF12Demo from the latest library and configure it to “1c” collect mode so that it won’t ACK then co-locate it with the GasMeter node and collect its output stream. Before posting the stream do a ‘p’ command and include the output with the post.

Could you also configure this monitoring node to be“i31”.

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

JohnO wrote:
> I am not aware of any incompatibility between ACK’s of older releases and the latest RF12Demo branch.

I have just tested inter-working a RFM12B JeeNode USB running Master branch code (7 months old) with a RFM69CW JeeLink running latest RM12Demo library and it looks good with ACK’s working in both directions.

RE: Acknowledge from RFM69 -> RFM12 - Added by flabbergast over 4 years ago

Sorry for jumping in with possibly an unrelated observation:
- I’ve got only RFM69CW’s.
- When I’ve tried the master branch of jeelib, two nodes running RF12Demo sketch, I’ve seen this behaviour: transmissions received correctly, ACK not recognised (but appeared as a “bad packet” when I turned off the filtering).
- When I’ve tried RF12Demo branch, all works fine in the same setup as above.

RE: Acknowledge from RFM69 -> RFM12 - Added by AndreasZoeller over 4 years ago

@JohnO

As i don’t have another JeeNode with a RFM69 i made some test instead. For all tests i am using the lastest JeeLib_master. I put my software on my Jµ with a RFM12. Here is the code which analyzes the acknowledge from the master :

#define ACK_TIME 1000
#define NB_ATTEMPTS_ACK 9

static byte waitForAck() {
    MilliTimer ackTimer;
    while (!ackTimer.poll(ACK_TIME)){
//      if (rf12_recvDone() && rf12_crc == 0 && ((rf12_hdr & RF12_HDR_ACK) == 0)/* && ((rf12_hdr & RF12_HDR_CTL) == 128)*/ ){
        if (rf12_recvDone() && rf12_crc == 0 &&
                // see http://talk.jeelabs.net/topic/811#post-4712
                rf12_hdr == (RF12_HDR_DST | RF12_HDR_CTL | myNodeID)) {
#if debug
                 mySerial.println("ACK Received");
             mySerial.print("Node ID:");mySerial.println(rf12_hdr & RF12_HDR_MASK); 
             mySerial.println("received something");
             mySerial.print("rf12_hdr=");mySerial.println(rf12_hdr,HEX);
             mySerial.print("rf12_crc=");mySerial.println(rf12_crc,HEX);
             mySerial.print("RF12_HDR_CTL=");mySerial.println(rf12_hdr & RF12_HDR_CTL);
             mySerial.print("RF12_HDR_ACK=");mySerial.println(rf12_hdr & RF12_HDR_ACK);
             mySerial.print("rf12_len=");mySerial.println(rf12_len,DEC);
#endif
            return 1;
        }
    }
#if debug
                 mySerial.println("ACK not Received");
             mySerial.print("Node ID:");mySerial.println(rf12_hdr & RF12_HDR_MASK); 
             mySerial.println("received something");
             mySerial.print("rf12_hdr=");mySerial.println(rf12_hdr,HEX);
             mySerial.print("rf12_crc=");mySerial.println(rf12_crc,HEX);
             mySerial.print("RF12_HDR_DST=");mySerial.println(rf12_hdr & RF12_HDR_DST);
             mySerial.print("RF12_HDR_CTL=");mySerial.println(rf12_hdr & RF12_HDR_CTL);
             mySerial.print("RF12_HDR_ACK=");mySerial.println(rf12_hdr & RF12_HDR_ACK);
             mySerial.print("rf12_len=");mySerial.println(rf12_len,DEC);
#endif
    return 0;
}

On the other side i am using a JeeNode with a RF12 and the RF12demo which is in the example-folder.

Here is the output of the code above :

ACK Received
Node ID:5
received something
rf12_hdr=C5
rf12_crc=0
RF12_HDR_CTL=128
RF12_HDR_ACK=0
rf12_len=0
ACK received

Here you can see what happens on the JeeNode with RFM12 :

Current configuration:
 A i1 g9 @ 868 MHz q1
OK 37 20 5 0 0 0 86 0 0 0 115
 -> ack

It gets a message from Node 5 and sends an ACK. The ACK is received and found as ok.

Now i changed the Jeenode to another one with a RFM69. Software is same, just changed RF69_COMPAT to 1.
Here is again the output of the Jµ :

ACK not Received
Node ID:5
received something
rf12_hdr=25
rf12_crc=467F
RF12_HDR_DST=0
RF12_HDR_CTL=0
RF12_HDR_ACK=32
rf12_len=0
ACK NOK received

and here is the output of the JeeNode with RFM69 and RF12demo :

 A i1 g9 @ 868 MHz q1
OK 37 20 7 0 0 0 151 0 0 0 115 (-27)
 -> ack
OK 37 20 7 0 0 0 151 0 0 0 117 (-27)
 -> ack
OK 37 20 7 0 0 0 151 0 0 0 117 (-27)
 -> ack
OK 37 20 7 0 0 0 151 0 0 0 117 (-27)
 -> ack
OK 37 20 7 0 0 0 151 0 0 0 117 (-27)
 -> ack
OK 37 20 7 0 0 0 151 0 0 0 117 (-27)
 -> ack
OK 37 20 7 0 0 0 151 0 0 0 117 (-27)
 -> ack
OK 37 20 7 0 0 0 151 0 0 0 117 (-28)
 -> ack

As you can see the header of the ACK is different (RFM12 : C5, RFM69 : 25) and the ACK from the RFM69 generates an crc-error.

flabbergast
I have just did the same with the JeeLib from RFM12demo-branch and it has the same behaviour.

Does anybody have an idea ?

I tried to find something in the sources of JeeLib, but this is very complicate and i couldn’t succeed until now.

Andreas

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

AndreasZoeller wrote:
> A i1 g9 @ 868 MHz q1
> OK 37 20 7 0 0 0 151 0 0 0 115 (27)
>
> ack
> OK 37 20 7 0 0 0 151 0 0 0 117 (27)
>
> ack
> OK 37 20 7 0 0 0 151 0 0 0 117 (27)
>
> ack
> OK 37 20 7 0 0 0 151 0 0 0 117 (27)
>
> ack
> OK 37 20 7 0 0 0 151 0 0 0 117 (27)
>
> ack
> OK 37 20 7 0 0 0 151 0 0 0 117 (27)
>
> ack
> OK 37 20 7 0 0 0 151 0 0 0 117 (27)
>
> ack

@Andreas

The above output doesn’t look like the output from the latest version of RF12Demo.cpp when run with the latest version of the RF12Demo library.

Could we be getting Arduino mixed up with library sources and it failing to rebuild library modukes?

RE: Acknowledge from RFM69 -> RFM12 - Added by AndreasZoeller over 4 years ago

@JohnO

Here is the output of the RF12demo-example of the latest JeeLib RF12demo-branch.
Result is the same.

Current configuration:
A i1 g9 @ 868 MHz q1
OK 37 20 2 0 0 0 163 1 0 0 117 (21.5dB)
New Node g9 i5 Index 6
~~> ack i5
OK 37 20 2 0 0 0 163 1 0 0 117 (
17.5dB)
> ack i5
OK 37 20 2 0 0 0 163 1 0 0 117 (
14.5dB)
> ack i5
OK 37 20 2 0 0 0 163 1 0 0 117 (
14.5dB)
> ack i5
OK 37 20 2 0 0 0 163 1 0 0 117 (
15dB)
> ack i5
OK 37 20 2 0 0 0 163 1 0 0 117 (
14.5dB)
> ack i5
OK 37 20 2 0 0 0 163 1 0 0 117 (
15dB)
~~> ack i5

and here is the output of the p-command :

> 0p
0 g9 i22 rx:0 post:0
1 g9 i10 rx:10 post:0 rssi(109/153/117/137) lna(3/255/4/5)
2 g9 i9 rx:2 post:0 rssi(123/161/123/128) lna(4/255/4/4)
3 g9 i7 rx:0 post:0
4 g9 i11 rx:0 post:0
5 g9 i8 rx:4 post:0 rssi(154/186/157/160) lna(2/255/2/2)
6 g9 i5 rx:16 post:0 rssi(28/43/68/70) lna(6/6/6/6)
Postings 0,0
Stability 10,8 3,4
32(0)0 48(32,16,0,16,0,0,0)
470

The output of the Jµ is the same as above :

ACK not Received
Node ID:5
received something
rf12_hdr=25
rf12_crc=467F
RF12_HDR_DST=0
RF12_HDR_CTL=0
RF12_HDR_ACK=32
rf12_len=0
ACK NOK received

My Jµ is a V1-version, i don’t know if this makes a difference.

How a correct ACK looks like, which bits are set ?

Andreas

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

Is node 5 the unit in question?

The signal strength is very high –15dB, is it very close by the central node? I wonder if the rfm12b is being swamped by the signal.

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

Also, can you set “0q”.

RE: Acknowledge from RFM69 -> RFM12 - Added by AndreasZoeller over 4 years ago

@JohnO

Yes the node 5 is the relevant one. I had them here for testing side by side on my desk. Normally the signal strength is about –70dB.

But the problem seems to be that a JeeNode with RFM69 send 0x25 as ACK (with a crc-error) and a JeeNode with RFM12 sends 0xC5 as ACK (which the Jµ with RFM12 accept as ok).

Andreas

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

I will take another look in the morning.

RE: Acknowledge from RFM69 -> RFM12 - Added by JohnO over 4 years ago

@Andreas

As you say the correct value of the ack should be 0xC5. When I simulate your node number 5 on a JNu1 with RFM12B I receive an ACK with 0xC5 when I request one. This suggests that the failed CRC is correct and that the code is good and we need to look at other issues.

My suggestion for the next steps are as follows:
With the latest RF12Demo library on your central RFM69CW node issue the command “1590o” this will drop the transmission frequency a fraction.
Try the JNu1 again, requesting an ACK and see what you get.
If still no joys then issue “1610o” to the your central RFM69CW node.
Try the JNu1 once more, requesting an ACK and see what you get.
Report back.

My thought on the above is that perhaps both devices are on opposite edges of their frequency tolerances.

RE: Acknowledge from RFM69 -> RFM12 - Added by martynj over 4 years ago

@Andreas,

Sorry to burden you with extra testing, but could you run with a different NodeID ? This is to get a different failing bit pattern in the bad CRC case.
Thanks.

RE: Acknowledge from RFM69 -> RFM12 - Added by AndreasZoeller over 4 years ago

martynj

I can do this in the evening. Do you recommend a special Node-ID (7 - 16 are occupied) ?

Andreas

RE: Acknowledge from RFM69 -> RFM12 - Added by martynj over 4 years ago

@Andreas,

ID=26 would be handy (as the complement of 5). Might as well change all the bits ;-)

RE: Acknowledge from RFM69 -> RFM12 - Added by AndreasZoeller over 4 years ago

martynj

I have now changed the node-id to 26 but the rf12_crc didn’t change :

ACK not Received
Node ID:26
received something
rf12_hdr=3A
rf12_crc=467F
RF12_HDR_DST=0
RF12_HDR_CTL=0
RF12_HDR_ACK=32
rf12_len=0
ACK NOK received

even with other node-ids, the rf12-crc is always the same value :

ACK not Received
Node ID:6
received something
rf12_hdr=26
rf12_crc=467F
RF12_HDR_DST=0
RF12_HDR_CTL=0
RF12_HDR_ACK=32
rf12_len=0
ACK NOK received

ACK not Received
Node ID:2
received something
rf12_hdr=22
rf12_crc=467F
RF12_HDR_DST=0
RF12_HDR_CTL=0
RF12_HDR_ACK=32
rf12_len=0
ACK NOK received

Andreas

    (1-23/23)