NRF24L01 unreliability

I did some long running sending tests with different situations:

1. Sending just from within the DHT callback > package loss wasn't too big and was still sending data after 12hrs
   
2. Sending data just from within the TSL callbacks > package loss starts very fast and moved to sending nearly 100% junk after a few hours
   
3. Sending data with an interval, separate from the callbacks > some package loss and was still sending after 12hrs
   
4. Just sending "Hello World" without using doing any sensor readings in an interval > some package loss and still sending after while
   
5. Sending in shorter/longer intervals (every 5seconds vs. every minute) > less package loss on smaller intervals and nearly no "noise" in the received data packages, over time the noise did not increase while using longer intervals resulted in an increased loss of data/more noise in the data packages over time
   
   

What I learned from these tests, is that I should send data not within callbacks but rather in an independent scope/interval outside of all the callbacks.

I tried to fine tune the sending process by:

1. using different data rates, which didn't change a lot
   
2. using .setTXPower(3) to maybe send a stronger signal, which didn't change anything as far as I can tell (while setting it to 0 resulted in no data sent anymore)
   
3. re-sending the data if .sendString() fails for some reason, which helps a lot but results in strange results. Failed sendings produce the error message TX not received 30 but still send some part of the data.
   
   

What I've seen in the very beginning, became very strange and repeatable when I re-sent data that was not successfully sent. Data packages arrived combined at the target node.

For example:

Sending Hello World sometimes arrived as HelloSªorldHello World or WorSªiQ¦llo World or WorSªiQ¦llo WorldrS¶‘=Q¦llo World.
Which looks like sent data is combined at the recipients end and the data packages are not correctly differentiated when received. It's maybe the NULL or EOT Byte thats not correctly received sometimes, leading to merged data packages.

I am using a slightly modified version of the example code from the website at the recipients side which seems to be very stable:

  var dataLine = "";
  setInterval(function() {
    while (nrf.getDataPipe() !== undefined) {
      var data = nrf.getData();

      for (var i in data) {
        var ch = data[i];
        if ((ch===0 || ch===4) && dataLine!=="") {

          status.lastNrfLine = dataLine;

          // remove noise in the beginning of the line
          if ( dataLine.indexOf('{') > 0 ) {
            dataLine = dataLine.substr(dataLine.indexOf('{'));
          }

          // remove noise at the end of the line
          if ( (dataLine.lastIndexOf('}')+1) != dataLine.length ) {
            dataLine = dataLine.substr(0, dataLine.lastIndexOf('}') + 1);
          }

          if ( dataLine.substr(0,1) == "{" && dataLine.substr(-1) == "}" ) {
            status.lastNrfPacket = dataLine;
            try {
              // replace -1 values because JSON.parse fails on them
              // https://github.com/espruino/Espruino/issues/456
              while ( dataLine.indexOf(":-1") >= 0 ) {
                dataLine = dataLine.replace(':-1', ':\"-1\"');
              }
              handleNrfInput(JSON.parse(dataLine));
            }
            catch (e) {
              // ignore failed packets...
            }
          }

          dataLine = "";
        } else if (ch!==0 && ch!==4 && ch >= 32) { // 0 = NULL, 4 = EOT, <32 = all command codes
          dataLine += String.fromCharCode(ch);
        }
      }
    }
  }, 50);

So much from my NRF-adventures, I think, now I can get to a stable solution with an independent interval that sends the data in the global scope instead of sending data within the callback-scopes. I also think that I will find out more about the real problems with further testing and networking more nodes.

Is there anywhere I can lookup the error codes for the sending? What doesTX not received 30 mean?

Cheers,
Mario