-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comments
This may be a hardware limitation, but I could be wrong. Thanks for the report! |
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? |
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. |
@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 |
The hardware limitation I may have been thinking of was this:
…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. |
Oh, one other potential cause of this @atomicus — the sender needs to have |
Any help solving this? I'm facing this same issue. My config on the RX side (RPi) is:
And TX (Arduino):
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 |
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. |
Thanks for your time @atomicus RPI as TX, Arduino as RXRPi 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. RPi as RX, Arduino as TXRPi receives the 1st message on every Arduino reset. I'm using this nodejs code as test |
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. |
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});
The text was updated successfully, but these errors were encountered: