[Question] Issue using the ManualAcknowledgements.ino about rf24 HOT 11 CLOSED

This bugs me. Why? Because users shouldn't have to use special measure to make this work.

I recreated the issue between a Nano and a Due, then just added a simple delay call. Now it works.

I added delay(1) just before this line

I believe that the constant SPI polling via available is hindering the radio's attempts at handling the ACKS, Data, and switching between RX/TX. Lots of stuff going on internally.

@pfpp89 Please test this out if you can.

      while (!radio.available()) {             // wait for response
        if (millis() - start_timeout > 200){    // only wait 200 ms
          break;
        }
        delayMicroseconds(200);
      }

from rf24.

Hello

First of all, thank you very much for your confirmation that the sample is working fine, and for your suggestions. I only had little doubt about the sample, but I decided to confirm it anyway. According to my research, this sample does not seem to be the most used, and there seems to be a surprisingly small amount of people that used it as a basis for their projects and shared information about it online.

Due to the time-criticality mentioned by @2bndy5, I am decided to build a proper adaptor to interface the nRF24L01 and the Arduino, and have it built from something like PCBWay. This order may, however, take some time.
I will also consider a cap (something on the range 10uF to 100uF?) between VCC and GND mentioned almost everywhere, as close as possible to the module.

As for the missing cap on the antenna, also mentioned by @2bndy5, my module is somewhat different from the one on the image from the ITEAD website. However, the cap seems to also be missing from mine (image below).

I admit I disregarded this information because it mainly pertains PA+LNA versions (which I'm not using here), and touching mine doesn’t seem to help in any way. I will also save this tip for last, since these are microscopic components, and I honestly do not have the material nor the skill to handle them properly.

Thank you very much for your help!

PFPP

from rf24.

Hello again!

Ok, my PCBs arrived today from JLCPCB, and I couldn’t wait to make a quick test. There is indeed a huge improvement., thanks a lot @2bndy5!

The sample does not yet work 100%, but the message round-trip is complete, the TX node receives the response correctly and is very consistent.

My only remaining issue, which is persistently gnawing at my inner perfectionist, is the “Response failed” written systematically by the RX side, as shown on the following picture:

Reading the code, the issue seems to come from the txStandBy which, for some reason, keeps sending false:

radio.writeFast(&payload, sizeof(payload));  // load response to TX FIFO
bool report = radio.txStandBy(150);          // keep retrying for 150 ms

According to the documentation, it should send false if a payload has been sent by the RX but not acknowledged with an ACK packet by the TX. It also states that it can only be reported if the auto-ack feature is on, which, to my understanding is the case since we never call “setAutoAck(false)” on this sample, and it is enabled by default.

I show below the diagram I hastily designed last Sunday, and a preview of the PCB, in the case you think the issue may still related with the setup\hardware (and I am sorry if the board is not perfect, I am absolutely not an electronics\PCB design expert in any way).

The cap I settled with is 100uF electrolytic (without which almost every message fails).

Thank you very much for your help!

PFPP

from rf24.

We should probably add a comment to explain why the delayMicroseconds() is needed.

      while (!radio.available()) {             // wait for response
        if (millis() - start_timeout > 200){   // only wait 200 ms
          break;
        }
        delayMicroseconds(200);                // relax probing of available()
      }

Honestly, I hadn't thought to tweak the TX side. Probably better to use the IRQ pin (+ radio.maskIrq()) instead of radio.available() for this problem.

from rf24.

Hello!

@pfpp89 Please test this out if you can.

while (!radio.available()) {             // wait for response
   if (millis() - start_timeout > 200){    // only wait 200 ms
     break;
   }
   delayMicroseconds(200);
 }

Thank you very much for the tip @TMRh20, I tested it as soon as I could, and it works like a charm!

See for yourself. Same setup as yesterday, no more “Response failed.” from the TX node:

Also a big thanks to @2bndy5 for the first tips related to my initial hardware setup, which were definitely the cause of my original problem.

One last question @TMRh20: I noticed you changed the issue state to “bug”. Should I leave the issue open for now, even if I consider my issue solved (not using the “close with comment”)? Or do you wish me to close it?

Again, thanks a lot for your help, I can finally continue my project!

PFPP

from rf24.

The examples are generally well tested, especially on AVR devices.

Since you've tried multiple radios, I would suggest reading the common issues doc

a: Try using a capacitor connected to the GND and VCC pins
b: Try calling radio.setPALevel(RF24_PA_MIN,0);

This is likely not a problem with the library but a hardware or power supply related issue, so not much we can do. This type of question would typically go in an Arduino or other such forum.

from rf24.

The example is very time-critical. In testing it on my hardware (typically on ATSAMD21 or some other cortex processor or RPi) with known good non-PA/LNA radios, I never really got a 100% success rate (more like ~98%).

After playing with the example's code and TMRh20 reporting 100% on ATMega328p, I just left it as it is now.

Using auto-ACKs with ACK payloads is preferable to me since I don't have to deal with rewriting built-in functionality (like manual-ACKs). But, bad clones (like Si24R1) do present problems with auto-ACK.

from rf24.

From ITEAD site:

• Voltage: 3-3.6V (recommended 3.3V) V
• Maximum output power: +20dBm
• Emission mode current(peak): 115mA
• Receive Mode Current(peak): 45mA
• Power-down mode current: 4.2uA

The Max PA output seems inaccurate for radio's with builtin antennas (and the given peak emission current)... I can see from the pictures that they also skipped putting a capacitor by the antenna.

This means it would probably work better when you touch it with your finger (a problem also noted in the COMMON_ISSUES doc), in which case a suitable capacitor should be the answer.

from rf24.

I will also consider a cap (something on the range 10uF to 100uF?)

Maybe try both in parallel. We can't say for certain what values would work since it highly depends on how the module is manufactured. IIRC, the COMMON_ISSUES doc blindly recommends 100uF.

touching mine doesn’t seem to help in any way

Thanks for reporting. You shouldn't need to monkey with SMD caps yourself; just play with various capacitance on the VCC & GND lines.

PA_LEVEL, which doesn’t seem to change anything

Yeah, lowering the PA level is a software hack that is supposed to reduce the required current needed to transmit (including auto-ack packets). This is really beneficial for PA/LNA modules, but we have seen it occasionally help avoid an unstable power supply for non-PA/LNA modules.

from rf24.

bool report = radio.txStandBy(150);

This is the line I usually have to tweak. Remember when I said the example is very time critical? Now, you know why. Try playing with a higher value, like 200 instead of 150.

from rf24.

from rf24.