Can't get node-nrf to work

[Manawyrm]

Hi,

I was trying to get node-nrf to work right.
At first, I had to downgrade node to v0.10.16. After downgrading I was able to compile the needed spi libs.

My hardware is OK, because I'm able to get the chip running with the C++ lib RF24:

#include <cstdlib>
#include <iostream>
#include "./RF24.h"
RF24 radio(RPI_V2_GPIO_P1_18, RPI_V2_GPIO_P1_24, BCM2835_SPI_SPEED_4MHZ); 

int main(int argc, char** argv)
{
  radio.begin();
  radio.setPayloadSize(32);
  radio.setChannel(2);
  radio.setPALevel(RF24_PA_MAX);
  radio.setDataRate(RF24_2MBPS);
//    radio.openReadingPipe(1,0x746D610000);
  radio.openReadingPipe(0,0x0000616D74);
  radio.setCRCLength(RF24_CRC_8);

  radio.startListening();
  radio.printDetails();
    while (1)
    {
            if ( radio.available() )
            {
                uint8_t data[32];
                bool done = false;

                while (!done)
                {
                    done = radio.read( &data, 32 );

                    int i;
                    for (i = 0; i < 32; i++)
                    {
                        if (i > 0) printf(":");
                        printf("%02X", data[i]);
                    }
                    printf("\n");
                    delay(20);
                }
            }
    }

  return 0;
}

Using this javascript I was not able to get the chip running:

var NRF24 = require("nrf/index.js"),
    spiDev = "/dev/spidev0.0",
    cePin = 24, irqPin = 25,            //var ce = require("./gpio").connect(cePin)
    pipes = [0x746D610000, 0x0000616D74];

var nrf = NRF24.connect(spiDev, cePin, irqPin);

nrf.channel(2);
nrf.transmitPower('PA_MAX');
nrf.dataRate('2Mbps');
nrf.crcBytes(1);
nrf.autoRetransmit({count:15, delay:500});

nrf.begin(function () {
    var rx = nrf.openPipe('rx', pipes[0]),
        tx = nrf.openPipe('tx', pipes[1]);

    nrf.printDetails();
    rx.on('data', function (d) {
        console.log(d);
        //tx.write(d);
    });
    tx.on('error', function (e) {
        console.warn("Error sending reply.", e);
    });
});

printDetails outputted the following instead of the correct variables:

SPI device:  /dev/spidev0.0
CE GPIO:     24
IRQ GPIO:    25
STATUS:      0x40 RX_DR=1 TX_DS=0 MAX_RT=0 RX_P_NO=0 TX_FULL=0
RX_ADDR_P0–1:  0x4040404040 0x4040404040
RX_ADDR_P2–5:  0x40 0x40 0x40 0x40
TX_ADDR:     0x4040404040
RX_PW_P0–5:    0x0 0x0 0x0 0x0 0x0 0x0
EN_AA:       0x40
EN_RXADDR:   0x40
RF_CH:       0x40
RF_SETUP:    0x40
CONFIG:      0x40
DYNPD/FEATURE:   0x40 0x40
Data Rate:   1Mbps
Model:       nRF24L01
CRC Length:  Disabled
PA Power:    PA_MIN

Any ideas what I did wrong here?

Thanks,
Tobias

[natevw]

Thanks for the report. I've filed the pi-spi compilation issue at natevw/pi-spi#8 — I'm hoping it won't be too much trouble to get it working for both node.js versions but I want it to work on the latest at least!

If you've been testing with the C++ library, it probably ± broke the Linux SPI driver and you'll need to either reboot your Pi or follow the modprobe instructions in #1 (comment) before "/dev/spidev0.0" will work as it should for node-nrf.

It's really kind of odd that you're getting [mostly] 0x40 back over the SPI instead of just 0x00 or 0xFF but until the driver is working I wouldn't pay too much attention to it yet. I think your pinouts are correct, but you might want to double check that too. Here's the connections that I'm using for the included test.js file: https://gist.github.com/natevw/5789019 (Note that the only connections that effect printDetails are the SPI ones, the CE and IRQ are only used when RF is active.)

Hope this helps!

[Manawyrm]

OK, now its getting strange...
After a reboot:

SPI device:  /dev/spidev0.0
CE GPIO:     24
IRQ GPIO:    25
STATUS:      0xe RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0–1:  0xe7e7e7e7e7 0xc2c2c2c2c2
RX_ADDR_P2–5:  0xc3 0xc4 0xc5 0xc6
TX_ADDR:     0xe7e7e7e7e7
RX_PW_P0–5:    0x0 0x0 0x0 0x0 0x0 0x0
EN_AA:       0x3f
EN_RXADDR:   0x03
RF_CH:       0x2
RF_SETUP:    0x0f
CONFIG:      0x0b
DYNPD/FEATURE:   0x03 0x07
Data Rate:   2Mbps
Model:       nRF24L01+
CRC Length:  8 bits
PA Power:    PA_MAX

and then after a

sudo modprobe -r spi_bcm2708
sudo modprobe spi_bcm2708

THIS happens:

SPI device:  /dev/spidev0.0
CE GPIO:     24
IRQ GPIO:    25
STATUS:      0xe RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0–1:  0xe7e7616d74 0x746d616d74
RX_ADDR_P2–5:  0xc3 0xc4 0xc5 0xc6
TX_ADDR:     0xe7e7e7e7e7
RX_PW_P0–5:    0x0 0x0 0x0 0x0 0x0 0x0
EN_AA:       0x3f
EN_RXADDR:   0x03
RF_CH:       0x2
RF_SETUP:    0x0f
CONFIG:      0x0b
DYNPD/FEATURE:   0x03 0x07
Data Rate:   2Mbps
Model:       nRF24L01+
CRC Length:  8 bits
PA Power:    PA_MAX

And THIS is strange. Because as you can see here, there are some bits of my set adress, but not all (wth?!) (my set address was 0x746D610000)

Any ideas? The connections are correct.

[natevw]

Sorry for the delay on this, keep encountering setbacks wiring up a second radio/RasPi to test on. (You'd think it'd be easier the second time…) If I can't get a "development" setup going soon I'll just have to borrow the "in-use" system for an evening or two instead.

Any news on your end, in the meantime?

[Manawyrm]

Not quite, I couldn't get any data events out of it, but seemed to be able to program the chips registers after a reboot of the raspberry. But still -- that weird issue with the bits of the addresses persists too.

Thanks,
Tobias

[natevw]

I saved your example script as "issue4.js" and the basic setup is working on my Pi. The first time I run it reports the previous pipe numbers (the script doesn't wait for pipe setup to complete before the printDetails starts talking with the chip too), but when running again I see the correct address:

pi@rubus-officinalis ~/radio/node-nrf $ sudo node issue4.js 
SPI device:  /dev/spidev0.0
CE GPIO:     24
IRQ GPIO:    25
STATUS:      0xe RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0–1:  0xe7e7e7e7e7 0xc2c2c2c2c2
RX_ADDR_P2–5:  0xc3 0xc4 0xc5 0xc6
TX_ADDR:     0xe7e7e7e7e7
RX_PW_P0–5:    0x0 0x0 0x0 0x0 0x0 0x0
EN_AA:       0x3f
EN_RXADDR:   0x03
RF_CH:       0x2
RF_SETUP:    0x0f
CONFIG:      0x0b
DYNPD/FEATURE:   0x03 0x07
Data Rate:   2Mbps
Model:       nRF24L01+
CRC Length:  8 bits
PA Power:    PA_MAX
^Cpi@rubus-officinalis ~/radio/node-nrf $ sudo node issue4.js 
SPI device:  /dev/spidev0.0
CE GPIO:     24
IRQ GPIO:    25
STATUS:      0xe RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0–1:  0xe7e7616d74 0x746d610000
RX_ADDR_P2–5:  0xc3 0xc4 0xc5 0xc6
TX_ADDR:     0xe7e7e7e7e7
RX_PW_P0–5:    0x0 0x0 0x0 0x0 0x0 0x0
EN_AA:       0x3f
EN_RXADDR:   0x03
RF_CH:       0x2
RF_SETUP:    0x0f
CONFIG:      0x0b
DYNPD/FEATURE:   0x03 0x07
Data Rate:   2Mbps
Model:       nRF24L01+
CRC Length:  8 bits
PA Power:    PA_MAX
^Cpi@rubus-officinalis ~/radio/node-nrf $

[natevw]

(Note that I'm only looking at the RX address, which is getting associated with the P1 "slot" by design. I wouldn't expect the TX address to be set, since that only gets set as needed, i.e. a packet gets sent.)

[natevw]

Hmm, it is interesting that in both our cases the P0 address ends up as 0xe7e7616d74. I turned my little debug flag on (nrf._debug = true near the top) which helped me see why. Basically when you open the TX pipe with a numeric (rather than buffer) address because of the leading zeroes it gets treated internally as a shorter width address.

I need to review a couple different things about this (I'm not sure the TX pipe should be claiming P0 to begin with, and also it needs to check its address width better…) but you may get farther along with pipes = [Buffer("746D610000",'hex'), Buffer("0000616D74",'hex')]; in the meantime.

[natevw]

For my reference, the followup items here are:

• should PTX really be setting P0 when initializing?
• document caveats of "numeric" address shortcut better
• how can we properly enforce TX address width? it bypasses the usual slotForAddr logic…