IRQ and CE on same pin ??

[jerryneedell]

Thank you for providing this library. I'm just starting to play with it --I hope to be hooking up hardware soon.
In reviewing the code, I noticed that in your example, the IRQ and CE pins are both assigned to D4. Is this a typo or intentional ? Not sure how it can be both an output and an input.

[jerryneedell]

FYI -- I hooked up some HiLetGo inexpensive nRF24L01+ modules https://www.amazon.com/gp/product/B00LX47OCY/ref=ppx_yo_dt_b_asin_title_o02_s00?ie=UTF8&psc=1 and the "simpletest" is working -- woohoo!

I had some issues with some other HiLetGo nRF24L01+PA+LNA modules https://www.amazon.com/gp/product/B00WG9HO6Q/ref=ppx_yo_dt_b_asin_title_o02_s01?ie=UTF8&psc=1. When I mix them with the other modules, They seem to receive, but report send failures.... some quick google searching suggested possible issues with these https://forum.arduino.cc/index.php?topic=562954.0 I'll explore further at another time -- Happy to play with the working modules for now.

Overall, a great success!
Still curious about the IRQ pin setting -- I have not tried it yet. When I do, I think I'll use a different pin for IRQ.

[2bndy5]

Sorry for the delayed response (github didn't notify me for some reason)

The irq pin setting was a typo from when I consolidated the examples from both Raspberry Pi and itsybitsy M4 separated files. The master branch has been updated, but not re-released yet (contains some other changes like renaming the irq_DX attributes to all lower case, and most recently blank ACK payloads return None while timeout transmissions return False). I'm also taking another stab at faking BLE advertisements, but I got distracted with trying to port someone's work on reverse engineering the Logitech unifying dongle (may be unifying model specific as I think Logitech switched to TI radios at some point -- so far, its been fruitless for me).

As for your

They seem to receive, but report send failures....

This means that the receiver node validated the payload and reciprocated with an ACK, but the ACK never made it to the transmitter node (it can happen and is likely not a library problem).

Possible Solution

I wonder if you're using a data_rate higher than 250Kbps. The specification sheet warns against using 250Kbps for non-plus nRF24 models (includes mixed models in a network) as there is a hardware bug native to the non-plus models design (can't remember exactly where I read it, but its in there). I also made note of this in the docs The TMRh20 library also makes note of that. Now the forum link you mentioned talks about something completely different (unless I missed something). and I have no knowledge of the RadioHead library pertaining to the nRF24L01.

[jerryneedell]

Thank you for the clarification of the IRQ Pin. I will also give the data rate change a try with the boards that are not working properly.

[2bndy5]

You might also want to tweak the ard (and maybe arc) attribute a bit higher. That would allow more RX time when waiting for ack packet on the TX side