NRF24 weirdness - doesn't seem to work reliably with [0,0,0,0,1] and [0,0,0,0,2].

Very simple setup - Two NRF's talking to eachother, connected to a single Espruino. I figure this is a best case scenario, right?

SPI3.setup({sck:B3, miso:B4, mosi:B5}); // B6, 7 used for other pins. 
SPI1.setup({sck:A5, miso:A6, mosi:A7}); // B0, 1 used for other pins.

var nrf1 = require("NRF24L01P").connect( SPI1, B0, B1, 16);
nrf1.init([0,0,0,0,1], [0,0,0,0,2]);

var nrf2 = require("NRF24L01P").connect( SPI3, B6, B7, 16);

nrf2.init([0,0,0,0,2], [0,0,0,0,1]);


var test=[222,173,190,239,222,173,190,239,222,173,190,239,222,173,190,239];
var test2=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16];

function test1() {
  console.log(nrf1.send(test2));
  while (nrf2.getDataPipe()) {
    console.log(nrf2.getData());
  }
}

function clear() {
  while (nrf1.getDataPipe()) {
    console.log(nrf1.getData());
  }
  while (nrf2.getDataPipe()) {
    console.log(nrf2.getData());
  }
}

Using the addresses above, I get stuff like:

>test1();
true
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
=undefined
>test1();
true
[0,129,1,130,2,131,3,132,4,133,5,134,6,135,7,136]
=undefined
>test1();
true
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
=undefined
>test1();
true
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
=undefined
>test1();
TX not received 82
false
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
[0,129,1,130,2,131,3,132,4,133,5,134,6,135,7,136]
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
=undefined
>test1();
TX not received 82
false
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
[0,129,1,130,2,131,3,132,4,133,5,134,6,135,7,136]
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
=undefined
>test1();
TX not received 82
false
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
[0,129,1,130,2,131,3,132,4,133,5,134,6,135,7,136]
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16]
=undefined
> 

Note here that it worked well for a while, sometimes quite a while at a time without going into fail-every-time mode, but throughout that time, it's occasionally receiving bogus data (!) shifted one bit to the right - which tells you something about the value of the NRF's CRC check...

Well, that's discouraging isn't it?

Except... This works:

nrf1.init([0,0,127,0,1], [0,0,127,0,2]);
nrf2.init([0,0,127,0,2], [0,0,127,0,1]);

In fact, every combination of addresses I've tried so far - except [0,0,0,0,1] and [0,0,0,0,2] - seem to work just fine.

Am I the only one encountering this behavior?

Strange... I'm not sure why that wouldn't work (I've been using those addresses when I do stuff) - I'm happy to change the example code though :) It's not that there's some other set of NRF devices near you that might be using those addresses??

On mine, after some time (roughly 2 days?) the module seems to lock up. Software reset won't do it, and I have to power cycle it. I was talking to someone at the Maker faire who'd come across this with Arduino, and said that the only solution they'd found was to move the transmit power down from maximum to the next lowest.