I have a raspberry 2 with 433mhz moteino as gateway and multiple moteinos communicating sensor data to the gateway. The sensors typically sleep and at defined intervals send updates to the gateway.
The sensors regulate their transmit power based on packet loss according to the following scheme: if a packet doesn't get acknowledged by the gateway three times powerLevel gets incremented by one. Every 5 updates powerLevel gets reduced by one. Since I'm using RFM69HW's almost all Moteinos converge to a powerLevel of 0 with this scheme. Since the gateway is AC powered it always sends acks to the clients at full power.
I used to have lots of trouble with interference from the raspberry, but since switching to a model 2 everything is much smoother. I do however frequently receive the same packet multiple times at the gateway. This means that the clients do not receive the ack from the gateway and resend even though the gateway did receive and ack the message. This is especially surprising since the sensors send at powerLevel 0 and the gateway acks at 31.
I used to think this might still be interference from the Pi. But since I developed my own wireless boot system I know that the Pi can send packets to the clients even at 200kbps using my own radio code almost flawlessly (I rarely get more than 1% retransmits using wireless boot). As an example check this out:
05/26 10:17:51: !boot,nd:13,c:26631,ac:54924
Boot request from 13, checksum 26631
Starting to boot 13
Bootloader CRC matches
Installing new app
Serving Client
New profile: 1, timeout: 30
New profile: 0, timeout: 10
Got ack in: 2534, drop rate: 8 empty: 0
Boot client done
05/26 10:17:53: [13] [RX_RSSI:-56]
05/26 10:17:53: >nd:13,nr:0,pw:0,vc:341,it:24,l:1,rs:8,h:376,t:197,ls:0
05/26 10:18:05: [3] [RX_RSSI:-28]
05/26 10:18:05: >nd:3,nr:21,pw:0,vc:332,it:29,l:1,hp:1,mc:0,h:314,t:209
05/26 10:18:13: [13] [RX_RSSI:-56]
05/26 10:18:13: >nd:13,nr:1,pw:0,vc:340,it:24,l:1,h:373,t:197,ls:0
05/26 10:18:14: [5] [RX_RSSI:-82]
05/26 10:18:14: >nd:5,nr:527,pw:0,vc:330,it:16,h:415,t:173
05/26 10:18:28: [4] [RX_RSSI:-67]
05/26 10:18:28: >nd:4,nr:528,pw:0,vc:329,it:12,h:429,t:152
05/26 10:18:28: [4] [RX_RSSI:-53]
05/26 10:18:28: >nd:4,nr:528,pw:0,vc:329,it:12,h:429,t:152
05/26 10:18:33: [13] [RX_RSSI:-56]
05/26 10:18:33: >nd:13,nr:2,pw:0,vc:340,it:24,l:1,h:372,t:197,ls:0
05/26 10:18:45: [3] [RX_RSSI:-28]
05/26 10:18:45: >nd:3,nr:22,pw:0,vc:332,it:29,l:1,hp:1,mc:0,h:315,t:209
05/26 10:18:53: [13] [RX_RSSI:-57]
05/26 10:18:53: >nd:13,nr:3,pw:0,vc:341,it:24,l:1,h:373,t:197,ls:0
05/26 10:18:53: [13] [RX_RSSI:-56]
05/26 10:18:53: >nd:13,nr:3,pw:0,vc:341,it:24,l:1,h:373,t:197,ls:0
Here I'm wirelessly booting node 13 in 2.5s. I get a drop rate of 8 which means 0.8% packet loss. Further down you see that the same nd:13 transmits update nr:3 twice at stock 55kbps, not seeing the ack from the server - something that should not happen given how stable the connection is at 200kpbs. nd:4 also sends a duplicate update.
I'm using 40ms timeouts which should be sufficient and I've experimented with adding a delay before the ack on the server - but it makes no difference.
I remember from when I developed my wireless boot code that I made some changes to the radio code that brought significant benefits in terms of retransmits. But before I start digging that deep again I wanted to see what others' experiences where like rg retransmits with the RFM69 lib. What kind of drop rates are you seeing and do you see double packets due to missed acks?