NRF24 works strange with Espruino

Hi,
my NRF24 module adressed properly, sometimes works well, but sometimes goes to some strange state:
it clears all the registers to [0,0,0,0,0] himself, without any command like nrf.init from the Espruino, or other obvious reasons. It is impossible to change this state using nrf.init - adress doesn't change.
In this state module continue sending data on Air, but always saying nrf.sendString("someth") = "true", even if reciever switched off. It returns to normal state only after power off. What can be the problem with It?

I'm not sure - I've noticed this once or twice too... I was talking to someone at a Maker Faire and they mentioned that they were having problems when working with Arduinos.

Their solution was to take the transmit power down one stop from the maximum. I'm afraid there's no function for it, so you'd have to make your own by accessing the relevant register. Let me know if you're not sure though and I'll paste up an example.

Yes, Gordon, share It to me please.

Ok, I had to dig out the datasheet anyway so I just updated the module. Use:

nrf.setTXPower(2)

the default value is equivalent to nrf.setTXPower(3). Using 2 will lower TX power and will hopefully (according to the guy I spoke to) sort out these problems.

Thanks, I'm testing it now. I'll report if it helps or not...

here is the test case with 2xNRF modules: 2 F4 discovery boards with very simple program. It repeats the state of B8 pin on another board. Sender side:

SPI1.setup({sck:A5, miso:A6, mosi:A7});
var nrf = require("NRF24L01P").connect( SPI1, B0, B1 );
function onInit() {
  E.enableWatchdog(20);
  Serial1.setConsole();
  nrf.setTXPower(2);
  nrf.setDataRate(250000);
  nrf.init([0,0,0,0,2], [0,0,0,0,1]);
}

function ledOn(){
  on=!on;
  digitalWrite(B8,on);
  nrf.sendString("digitalWrite(B8,"+on+")"­);
  digitalWrite(B9,on);
  //nrf.sendString("digitalWrite(B9,"+on+"­)");
  digitalWrite(B6,!on);
  //nrf.sendString("digitalWrite(B6,"+!on+­")");

}

//onInit();
setInterval(function() {
  ledOn();
  
}, 1000);

and reciever with modified slaveHandler method:

SPI1.setup({sck:A5, miso:A6, mosi:A7});
var nrf = require("NRF24L01P").connect( SPI1, B0, B1 );
function onInit() {
  E.enableWatchdog(20);
  Serial1.setConsole();
  nrf.setTXPower(2);
  nrf.setDataRate(250000);
  nrf.init([0,0,0,0,1], [0,0,0,0,2]);
}

function slaveH(){
while (nrf.getDataPipe()!==undefined) {
    var data = nrf.getData();
    for (var i in data) {
      var ch = data[i];
      if (ch===0 && nrf.cmd!=="") {
        var c = nrf.cmd;
        nrf.cmd = "";
        //var nrf = this;
        /** evaluate and return a result in the timeout, 
        so that evaluation errors don't cause the slaveHandler
        interval to get removed */
        setTimeout(function() {
          print(""+c);
          var result = ""+eval(c); // evaluate
          //print("...="+result);
          // send the result back after a timeout
        }, 1);
      } else if (ch!==0) {
        nrf.cmd += String.fromCharCode(ch);
      }
    }
  }
}

//onInit();
setInterval(function() {
  slaveH();
}, 50);

It works well, but after ~10 minutes reciever stops with the message:

Execution Interrupted during event processing.
Uncaught SyntaxError: Got ?[128] expected EOF
 at line 1 col 1

 ^
in function called from system

Execution Interrupted during event processing.
Uncaught SyntaxError: Got ?[128] expected EOF
 at line 1 col 1

 ^
in function called from system
digitalWrite(B8,digitalWrite(B8,digitalW­rite(B8,digitalWrite(B8,digitalWrite(B8,­digitalWrite(B8,digitalWrite(******

//  lots of It //

******(B8,digitalWrite(B8,digitalWrite(B­8,digitalWrite(B8,digitalWrite(B8,digita­lWrite(B8,digitalWrite(B8,digitalWrite(B­8,digitalWrite(B8,d 

seems to some buffer overflow or someth similar. Nrf addressing looks well. Bad thing is, that I can't launch It again: clearInterval() and setInterval(){function(){slaveH();},50);­ didn't start It.
What is the problem ?

Are the modules next to each other, or quite far apart?

It looks like one of the modules is able to send data, but it doesn't get an acknowledgement back - so it just keeps sending the same packet over and over.

I think that's something in the NRF module itself. About all we could do to protect against that is to tag each packet with an incrementing counter, and to then throw away duplicate packets.

30 cm between them. As i understood there is no way to manage this fail on the sender side, right?

No... I think the sender is unaware of a problem - this is all the NRF module sending too many packets. You could reconfigure it not to try so many times - but then you'd just lose the data completely.

ouhh.. Seems to this module not fit for my task... I need something more stable. Gordon, could you please recommend some other, stable, maybe 433Mhz cheaper $25, which can work in point-multipoint mode.
Thanks!

Well, you could work around that issue with the NRF24 by changing the JavaScript code in the module. I don't have time to do it all for you, so I'm afraid you need to dig around and make the changes yourself.

I've heard good things about http://shop.ciseco.co.uk/erf-0-1-pin-spa­ced-radio-module/ - it works using serial comms, so you can actually program Espruino over it. Personally I haven't used it though, and I'm not sure if it does multipoint.

Otherwise there's http://www.espruino.com/433Mhz - which is very basic (and one-way). You'd have to make all your own transmitter/receiver code for it though, which could be hard to get right.

Sure, I'll try to do, but in the module, in NRF.prototype.send and sendString I can't see the cycle which resends packets in case of transmitting fail. could you show me where to dig, very basically

Retransmitting is done by the chip itself. It's best to read the datasheet and you should get a pretty good idea what it's capable of.

Hi! You were right Gordon!
this.setReg(C.SETUP_RETR, 0b01011111); // setup ARD 0101 (6*250uS retransmit delay) and ARC 1111 (15 retransmit count)
15 retran's were to much for me, I used 1 instead, and now it works stable.
Thanks again!

Some new things i've got about the NRF: after reducing output power the module works a bit more stable, but still sometimes goes to state, when all the registers == 0. Last night It worked well, but today, if I try to read some register it drops once in 5 minutes. Bad thing is, that i couldn't restore It any way, except power off for stm and module together. Some guys from other forums recomend to initialise all the registers before each sending, but It difficult to do It using existing js module, and I do not believe that It will help.
Another trouble (maybe I just misunderstood someth.) - if i switch off acknowledgement (En_AA = 0x0) PTX stops to send any data, but IMO It must only stop acknowledgement.

I'm not sure about the ack - I only know enough about the module to implement data I'm afraid.

There must be an official solution to the crashes... Surely they can't sell a chip that has this problem?

All I can suggest about trying to stop it breaking is to attach the power line to a GPIO rather than to 3.3v. You can then totally power off the module between sends, so even if it breaks, it should work the next time.

I agree, Gordon, It's a bit strange situation, I've seen a lot of threads in forums, but nothing about official recomendation according to It. I thought about module supply as you described, and tryed to do so, but with no success. - After power off\on and nrf.init(...) registers stay in zero, even if I switch off the power for 5-10sec. It sounds crazy, but It's so with my pair - f3 and NRF.

Ahh. Perhaps you could set all the SPI pins/etc to digitalRead? It might be that they are keeping the chip powered...

I even tryed to disconnect all the wires from module... I don't know...

Hi guys,
do you have a decoupling capacitor close to the nRF24 chip? I did experience your same issues with those cheap nRF24 boards you can get from eBay and I discovered that the problem was noise on the power line: adding a capacitor (anything between 1 to 100 uF) fixed all my issues and I got 100% reliability.

@rlogiacco Thanks! I should have tried that before - it makes a huge amount of sense :) I'll update the page on them and will give it a go!