-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
Compatibility issue to Arduino RF24 ? #26
Comments
What type of radio module are you using? Are you using a PA/LNA module? 100nF + 10uF seems small. I usually use 100uF capacitor. Are you using an adapter board for the nRF24 modules? |
Did you uncomment the lines for compatibility with the RF24 arduino lib? Each compatible example had a set of lines commented out |
If i uncomment the lines, transmitting from the pi to the arduino stops working. I've added additional 330uF. Makes no difference. What makes me wonder: I've used those modules with arduino <-> teensy with the nrflite library and it was working without any caps. I have this power adapter, but i'm not using it. Its the version without antenna. |
the capacitance used largely depends on the power regulating circuit on the MCU board.
That doesn't make sense. Those lines are there specifically for this task. Just to be clear, you are running the simple_test.py on the RPi and the RF24 lib's gettingStarted.ino on the arduino, right? I'm guessing you made no other alterations to the mentioned examples' code. |
Exactly. I only changed the pins. So, after updateing the CP firmware to 6.2 stable, i've resoldered everything. AAAND finally after adding another cap on the pi side it seems that receiving is quite stable. transmitting and receiving the ack is still a bit unstable. Mayadding more caps. I've now around 200uF. |
OH! you're using the RPi Pico board. Last I tried this lib on my Feather RP2040, I was successful using CircuitPython v6.2.0 (stable) which now ships with a faster version of the p.s. we are working on Pico SDK support over at the RF24 repo (nRF24/RF24#727). We have uf2 files uploaded as workflow artifacts on each commit. (you could also give those example a try - but that's bleeding edge stuff) |
reposting my advice from another thread:
For what its worth I use an adapter board (which regulates the VUSB down to 3V for me). |
default SPI pins (according to SDK) are: #define PICO_DEFAULT_SPI 0 // as in `spi0`
#define PICO_DEFAULT_SPI_SCK_PIN 18
#define PICO_DEFAULT_SPI_TX_PIN 19
#define PICO_DEFAULT_SPI_RX_PIN 16
#define PICO_DEFAULT_SPI_CSN_PIN 17 |
I can't reproduce this on my Feather RP2040. I had to un-comment the lines to get the simple_test.py OTA compatible with RF24's gettingStarted.ino example.
import board
import busio
spi = busio.SPI(clock=board.GP2, MOSI=board.GP3, MISO=board.GP4) You also have to change the ce & csn pins in the example. did you do that? from digitalio import DigitalInOut
ce = DigitalInOut(board.GP5)
csn = DigitalInOut(board.GP6) |
Sry for late response. I added a 1117 3.3 voltage regulator and a 100uF cap on the pico pi side. I guess without an additional regulator around 400uF might work stable. But those 3 lines need to be commented out for transmitting to work. Receiving always works.
|
Hmm, that's just not right. Try un-commenting only the |
Interesting. I'm glad you solved it, but could you post the output of Preferably, I need to see what print("BEFORE")
nrf.printDetails()
nrf.dynamic_payloads = False
print("AFTER")
nrf.printDetails() Alternatively, you can use |
The only problem I can see in that function is this line when disabling dynamic_payloads. Try taking out that |
Here is the output
using Patching rf24.py makes no difference. Is there anything special to have dynamic_payload disabled? |
if it works when dynamic_payloads are enabled, then the other program must have it enabled also. Dynamic payloads feature isn't meant to work with static payloads.
The fix in that commit I tagged you on should have removed any doubt that the proper registers' bits are set. print("BEFORE: 0x1c={} 0x1d={}".format(
hex(nrf._reg_read(0x1C)), # register for feature in RX
hex(nrf._reg_read(0x1D)) # register for feature in TX
))
nrf.dynamic_payloads = False
print("AFTER: 0x1c={} 0x1d={}".format(
hex(nrf._reg_read(0x1C)), # register for feature in RX
hex(nrf._reg_read(0x1D)) # register for feature in TX
)) |
Hi. Read the above replies. And in the example code, there are 3 lines said to uncomment for compatibility with Arduino rf24, one of which is only for the Chinese altered board. |
Technically, the
Not sure what you are referring to. I don't really know what this means. Basically the setting must match on both ends. If using Arduino RF24 defaults, then disable |
I'm trying to connect a Pi Pico to an arduino nano using nrf24l01 module.
I'm using the most recent versions of the libraries and i only uploaded the basic example on both devices.
So if the arduino is set to the transmitter and the pi to reciever, all packets are lost. The pi recieves nothing.
If the pi is transmitter and the arduino reciever, some/most packets shows up, but the ack is missing.
i've just installed a 100nF C on both modules. The arduino one has an additional 10uF attached.
This seems to fix the lost packets if the pi sends them. But the other way and ack packets are still not working.
The text was updated successfully, but these errors were encountered: