natevw / node-nrf

Pure-JavaScript nRF24L01 driver library
117 stars 31 forks source link

autoAck does not work when packet size provided #29

Open atomicus opened 9 years ago

atomicus commented 9 years ago

If I open a pipe like that: var rx = radio.openPipe('rx', 0xF0F0F0F0F1, {size: '5'}); node-nrf get's the data, but does not send back ACK, my Arduino sender says that transmission failed.

This does not help: var rx = radio.openPipe('rx', 0xF0F0F0F0F1, {size: '5', autoAck: true});

natevw commented 9 years ago

This may be a hardware limitation, but I could be wrong. Thanks for the report!

Vuurbaard commented 9 years ago

Any luck getting your arduino to work? My RPi does receive and logs some data twice and then just plain stops doing stuff... I write back the data to the tx pipe but it never gets to the arduino properly. Any idea?

atomicus commented 9 years ago

To clarify - it works all right, except that RPI doubles the packets.

Check if you have correct pipes addresses on both sides - in short, they should be reversed. So RPI uses adresses rx:A,tx:B while Arduino uses rx:B,tx:A where A&B are proper adresses.

natevw commented 9 years ago

@atomicus This is not a hardware limitation, as you probably knew. Unless I can reproduce this once I get my (non-"production") RasPi and Arduino devices jumpered back together for testing this, a debug log of the initial setup and a few packets coming might be helpful.

You do need to include {autoAck:true} when creating the pipe then the requisite bit of EN_AA should be set and the only other reason I see for ACK to fail according to the "Enhanced ShockBurstTM receive payload" on p76 of the datasheet would be if the sender is setting the NO_ACK bit which seems unlikely.

natevw commented 9 years ago

The hardware limitation I may have been thinking of was this:

An ACK packet can contain an optional payload from PRX to PTX. In order to use this feature, the Dynamic Payload Length (DPL) feature must be enabled.

…found in Section 7.4.1 on page 33 of the datasheet. But all this is referring to is sending data payloads in reverse to the TX unit along with the ACK packet.

natevw commented 9 years ago

Oh, one other potential cause of this @atomicus — the sender needs to have RX_ADDR_P0 set to its TX address [i.e. "your" address] to see the ACK packets as well. The RF24 Arduino library usually handles this, but one other thing to confirm.

gonAlonso commented 9 years ago

Any help solving this? I'm facing this same issue. My config on the RX side (RPi) is:


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
PONG back
RX_ADDR_P0–1:    0xf0f0f0f0e1 0xf0f0f0f0d2
RX_ADDR_P2–5:    0xc3 0xc4 0xc5 0xc6
TX_ADDR:         0xf0f0f0f0e1
RX_PW_P0–5:      0x20 0x20 0x0 0x0 0x0 0x0
EN_AA:           0x3f
EN_RXADDR:       0x03
RF_CH:           0x4c
RF_SETUP:        0x27
CONFIG:          0x0f
DYNPD/FEATURE:   0x03 0x07
Data Rate:       250kbps
Model:           nRF24L01+
CRC Length:      16 bits
PA Power:        PA_MAX

And TX (Arduino):


STATUS       = 0x0e RX_DR=0 TX_DS=0 MAX_RT=0 RX_P_NO=7 TX_FULL=0
RX_ADDR_P0-1     = 0xf0f0f0f0e1 0xf0f0f0f0d2
RX_ADDR_P2-5     = 0xc3 0xc4 0xc5 0xc6
TX_ADDR      = 0xf0f0f0f0e1
RX_PW_P0-6   = 0x20 0x20 0x00 0x00 0x00 0x00
EN_AA        = 0x3f
EN_RXADDR    = 0x02
RF_CH        = 0x4c
RF_SETUP     = 0x27
CONFIG       = 0x0f
DYNPD/FEATURE    = 0x3f 0x04
Data Rate    = 250KBPS
Model        = nRF24L01+
CRC Length   = 16 bits
PA Power     = PA_MAX

Both sides share RX0 address, so no problem with this. On the Arduino it states _ENRXADDR=0x02, so it's like RX0 is disabled :( am I wrong? RPi states _ENRXADDR:0x03, both RX0 and RX1 enabled. And _ENAA if 0x3f on both sides Apparently, the problem is shown when Arduino send to RPi, not the other way around. At least, it doesn't trigger on('error') on the RPi as emitter

atomicus commented 9 years ago

It's quite a long time I've coded for this, so I'm not sure pipe adresses are correct RX addr of arduino should be TX adr of PI, while TX of Arduino should be RX of PI.

My problem was that I've connected hw to RPI without interrupt pin, so it had some race condition issues on pooling loop.

Simply adding a interrupt cable solved all my issues with auto ack + double packets. If I remember correctly, it might be that I've added some software solution to remove doubled packetes.

I'll send you my config within couple hours, as I'm at work now, so you will be able to compare it.

gonAlonso commented 8 years ago

Thanks for your time @atomicus I was curious about your appointments so I tried tmrh20's pingpaitirq sample code. I just edited the addresses, PINs and changed message to 'Hello'_. The strange part is, it works the firsts pings, then it blocks.

RPI as TX, Arduino as RX

RPi correctly sends 2 messages and Arduino receives them. Then the Ardiuno gets blocked but RPi keeps sending without complying. No on('error') triggered on RPi, neither it detects PWR down of Arduino. But the RPi detects the error if it starts with the Arduino off.

RPi as RX, Arduino as TX

RPi receives the 1st message on every Arduino reset. Arduino sends a message and shows an error: Send:Failed

I'm using this nodejs code as test

atomicus commented 8 years ago

Sorry for delay, I'll present how I have it configured.

On node.js side, nrf connected with interupt pin and such setup (I hope it's clear):

var RadioSettings =
{
    dev: "/dev/spidev0.0",
    csi: 22,
    channel: 0x4c,
    dataRate: "1Mbps",
    crcBytes: 2,
    txPipeAdr: 0xF0F0F0F0D2,
    rxPipeAdr: 0xF0F0F0F0F1
}

On Arduino, such setup:

const uint64_t pipes[2] = { 0xF0F0F0F0F1LL, 0xF0F0F0F0D2LL };

        radio.begin();
    radio.enableDynamicPayloads();
    radio.setAutoAck(1);
    radio.setRetries(15,15);
    radio.setDataRate(RF24_1MBPS);
    radio.setPALevel(RF24_PA_MAX);
    radio.setChannel(76);
    radio.setCRCLength(RF24_CRC_16);
    radio.enableDynamicAck();
    radio.openWritingPipe(pipes[0]); 
    radio.openReadingPipe(1,pipes[1]);

And this is working. No double-packets are found, as this was fixed by adding interupt pin on RPI.

Your situation is a bit different, as it sends packets and stops - I would start from checking the Arduino code, or using any other example from tmrh20 - I know that most of the times this is on Arduino side. Check if your not getting your RAM full by accident, as it might cause strange things.