-
Notifications
You must be signed in to change notification settings - Fork 164
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
Device can send or receive only depending on wiring #205
Comments
The adapter boards typically have voltage regulators, so it is likely that the radios aren't getting enough power from the 3v supply line. Maybe I read that wrong... |
In this case, I have two different adapter boards. One with a regulator, and one without. If I use either breakout board, it can only receive data, the other board will never successfully transmit data. If I use a board that is directly wired to the pico(header pins -> jumper wire -> RF24 board) it can send data and will rarely receive it( only in tests with both directly attached). I have swapped out all of the parts and double checked all the wiring but this is the result I consistently get. I also have tested to see if the power on order has any effect, but it does not. The only variable is how the RF boards are wired up. |
Strictly speaking, if a RF24 module fails to transmit, then that usually means there is something up with the power lines to the radio. Transmitting (including ACK packets) requires the most current, so this is a big hint to me. Are there capacitors at play here? |
When I first tested, only the breakout board without a regulator had a 10uF cap added, none of the others did. Adding a 10uF cap has worked on one of the directly connected boards(it now receives most of the packets), but has had no impact on the other one(it can still only send). |
To be clear, if it has a voltage regulator, are you feeding it 5v? Usually the regulator is meant to provide a stable 3v from a 5v input.
If it sends successfully with auto-ack enabled, then it can receive. Maybe check to make sure the time interval used for receiving aligns with the other nodes' time interval used for transmitting. Are you using a RF24 lib example to test? |
I am using 5 volts with the regulator. Here is my own code I have been testing with: #include <RF24.h>
#include <RF24Network.h>
// Define the radio pins
RF24 radio(20, 17); // CE, CSN
RF24Network network(radio);
const uint16_t living_room = 01;
unsigned long last_request_time = 0;
unsigned long request_interval = 10000; // 10 seconds
void setup() {
Serial.begin(115200);
while (!Serial) {
// some boards need this because of native USB capability
}
Serial.println("Starting up");
radio.begin();
radio.setPALevel(RF24_PA_MAX);
radio.setDataRate(RF24_250KBPS);
network.begin(/*channel*/ 80, /*node address*/ 00);
radio.printDetails();
}
void loop() {
network.update();
unsigned long current_time = millis();
if (current_time - last_request_time > request_interval) {
last_request_time = current_time;
requestTemperature(living_room);
Serial.println("Asking for temp");
}
while (network.available()) {
RF24NetworkHeader header;
float temperature;
network.read(header, &temperature, sizeof(temperature));
Serial.print("Temperature from Node ");
Serial.print(header.from_node, OCT);
Serial.print(": ");
Serial.print(temperature);
Serial.println(" °C");
}
}
void requestTemperature(uint16_t node_address) {
RF24NetworkHeader header(node_address, 'T');
network.write(header, 0, 0);
} and for the other unit: #include <RF24.h>
#include <RF24Network.h>
// Define the radio pins
RF24 radio(20, 17); // CE, CSN
RF24Network network(radio);
const uint16_t living_room = 01;
unsigned long last_request_time = 0;
unsigned long request_interval = 10000; // 10 seconds
void setup() {
Serial.begin(115200);
while (!Serial) {
// some boards need this because of native USB capability
}
Serial.println("Starting up");
radio.begin();
radio.setPALevel(RF24_PA_MAX);
radio.setDataRate(RF24_250KBPS);
network.begin(/*channel*/ 80, /*node address*/ 00);
radio.printDetails();
}
void loop() {
network.update();
unsigned long current_time = millis();
if (current_time - last_request_time > request_interval) {
last_request_time = current_time;
requestTemperature(living_room);
Serial.println("Asking for temp");
}
while (network.available()) {
RF24NetworkHeader header;
float temperature;
network.read(header, &temperature, sizeof(temperature));
Serial.print("Temperature from Node ");
Serial.print(header.from_node, OCT);
Serial.print(": ");
Serial.print(temperature);
Serial.println(" °C");
}
}
void requestTemperature(uint16_t node_address) {
RF24NetworkHeader header(node_address, 'T');
network.write(header, 0, 0);
} I had a temp sensor connected to one of the boards, I removed it to see if it had any effect, but it didn't. |
Sorry, I forgot this was a RF24Network issue. Have you tried any RF24 examples to ensure basic radio functionality works?
This is indicative of another node failing to transmit the auto-ack response. Another reason why we should check that all radios satisfy RF24 lib functionality. What radio modules are you using? |
I swapped to the "Getting Started" example, edited to match the CE and CSN pins and got the following:
Node 1:
One thing I noticed is that node one was far more reliable in receiving the packets then node zero for some reason. As for the model they are nRF24L01+ modules. |
I swapped out the setup, the direct attached I plugged into a Pico W I have lying around, and the paired it up with the powered breakout on a standard breakout board. That seems to be working perfectly with the Getting Started code so I think you were right on the power draw being the issue. I do find it a bit odd though, I would think that it should have enough power given that these modules shouldn't be demanding much current. |
Check for ambient noise (RF24 scanner example)? Honestly, if this isn't a power issue, then I don't know what else to check. Last I checked (before the shortage), the pico boards use a switching 3v regulator, so there's likely a lot of noise (due to the nature of switching regulators) in the 3v power lines that needs to be filtered out with capacitors. |
Maybe try introducing a small capacitor and a larger capacitor in parallel to the radio's VCC and GND pins. Fighting noise is best done with multiple varying capacitance in parallel... |
I will give that a try. I have also run the scanner, it looks like I am mostly in the clear. Just on section used up by the neighbors WiFi and a bit of noise occasionally on other channels. Even in the range being used by that network, I never see higher then a 4 and most of the time they are 1 or 2 so I may be able to use them for some short range stuff. I'll play around with the capacitors and see how it goes. If/when I find some that work I'll post back here. |
Power supply noise could of course be both high- and low-frequency, so it might take both low ESR tantalum/ceramic and (higher ESR) electrolytic capacitors to fully filter out. |
I played around a bit and found that using a 10uF and 100nF capacitors in parallel worked the best, though I still only got a 75% receive success and about a 90% transmit success to a unit using an external regulator. I remember reading something about the Pico's power supply having two different operating modes so I will look further into that. For now though it seems that you can't reliably power a NRF24L01+ from the Pico directly. Thanks @2bndy5 and @Avamander for the help. |
I have four Pi Picos attached to four nRF24L01+ radios. Depending on if I have them wired directly to the Picos with jumpers or if I use a breakout board, the module will only be able to send or receive data respectively. I have no idea why this is the case, I have swapped to the code between the four setups and unless the sender is attached to the Pico with jumpers, and the receiver is using a breakout board the code fails to run.
Any idea as to why this is happening? I am hoping to get these on to protoboards so I will need to use breakout boards but I can't move the transmitter due to this.
The text was updated successfully, but these errors were encountered: