Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autoAck does not work when packet size provided #29

Open
atomicus opened this issue Jan 28, 2015 · 10 comments
Open

autoAck does not work when packet size provided #29

atomicus opened this issue Jan 28, 2015 · 10 comments

Comments

@atomicus
Copy link

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
Copy link
Owner

natevw commented Jan 30, 2015

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

@Vuurbaard
Copy link

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
Copy link
Author

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
Copy link
Owner

natevw commented Feb 13, 2015

@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
Copy link
Owner

natevw commented Feb 13, 2015

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
Copy link
Owner

natevw commented Feb 13, 2015

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
Copy link

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 EN_RXADDR=0x02, so it's like RX0 is disabled :( am I wrong? RPi states EN_RXADDR:0x03, both RX0 and RX1 enabled. And EN_AA 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
Copy link
Author

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
Copy link

Thanks for your time @atomicus
I was curious about your appointments so I tried tmrh20's pingpait_irq 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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants