I am having a bit of trouble running two of these little adapters with an Arduino Mega and a Arduino Nano... it seems to me that the Mega is having trouble reading anything, as I can't get any kind of reply, only a "Failed, response timed out"... However, the Nano receives the packet and sends the ACK. When I reverse the roles, absolutely nothing happens. It does not see any kind of traffic. Packets can go out and never be received. I've attached a screen shot showing what goes on... I'll attach more screen shots later when I get them.
Oh, I'm using the pingpair sketch... also, the GettingStarted sketch does the same thing. One way it works, the other way it doesn't.
This is the results from the pingpair_test.pde sketch...
This is using the Mega to transmit:
and this is the Nano as a receiver:
I noticed that both images do not reflect the same "test", but the results are the same no matter what configuration I use..
It receives it, but the mega doesn't receive the ACK... I'm kind of thinking the Mega is faulty. I know the voltage regulator is bad, for sure. I can't even use the barrel plug to power it.
the nano receive the packet transmited by the mega because adress TX from mega is RC adress of nano.
But the TX adress from nano is not the RX adress of mega. So from ACK isn't received for the mega.
Considering the pingpair code, you've got :
if ( role == role_ping_out )
{
radio.openWritingPipe(pipes[0]);
radio.openReadingPipe(1,pipes[1]);
}
else
{
radio.openWritingPipe(pipes[1]);
radio.openReadingPipe(1,pipes[0]);
}
It shows that there is 2 pipes that allow 2 RF24 to communicate together. Each pipe works in ONE way. That's means that 1 pipe is sending datas in one way, and the other is doing the same in opposite way.
We could show it like considering this code :
The ping out RF24 writes datas on pipe1 and reads data on pipe0
The other RF24 writes on pipe0 and reads datas on pipe1 !!!
Thanks for the reply, and I totally understand what you mean... I am truly sorry that I may have confused you with different screen shots. I've re-assembled everything and repeated what I did, and got the same exact result, and created two more images.
I must add that I connected the Nano exactly as maniacbug shows on his blog... As for the Mega, I'm using pins 9/10 for CE/CSN, and then pins 50, 51, 52 for MOSI MISO and SCK. Power is coming from the 3.3v from the Mega, however, I may try to use an external regulator when I get home.
Still majorly confused, and thanks for any help, if any.
As I read specs of SPI of nano and mega we can discover that :
MEGA :
SPI: 50 (MISO), 51 (MOSI), 52 (SCK), 53 (SS). These pins support SPI communication using the SPI library. The SPI pins are also broken out on the ICSP header, which is physically compatible with the Uno, Duemilanove and Diecimila.
NANO:
SPI: 10 (SS), 11 (MOSI), 12 (MISO), 13 (SCK). These pins support SPI communication, which, although provided by the underlying hardware, is not currently included in the Arduino language.
So, use the PIN 53 instead of PIN10 with the Mega board.
Thanks for the input, Grag... I emailed the guy with the bajdi website, since I seen a thread posted by him somewhere in the forum from google results, and he said that his problem was resolved by adding a 22uF or higher capacitor across the Mega's 3.3v and ground. The problem instantly went away!
I have a very similar problem yesterday when using a NANO and a vero/UNO board (with seperate ucb/serial)
I seemed to have All the symptoms above, I nearly threw the whole lot in the bin...
In the end, I made a second vero/UNO board
My assumption was that 'maybe' the USBinterface on the NANO board was in someway conflicting with timings of the RF board when viewing serial data
All I want is a high speed on way data transfer with no acks, and I got it...
Perhaps I still have some tweaking to go but it seems to work for me :@)
Big thanks for this amazing libary, at the momment I already tried all the examples included, and even made some modifications.
I want to go further but there are some basic concepts I miss, tried on google, in the main site, taking closer look to the examples, but nothing, I just dont understand some things. I really want to go deeper but I feel a good tutorial is missing. Here are some of the things I dont get.
Whats a pipe? How it changes if I want 2 or 6 nodes to speak.
const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };
What the numbers mean?
Maybe after the explanation, I will figure how to solve the next issue, but just in case; How do I need to set the pipes if my network is static 6 nodes, one base. The nodes some times send data to the base and then the base answers with some other data back to the emiting node…
finnduino:
It's still showing this when I look status of module:
Data Rate = 1MBPS
Model = nRF24L01
CRC Length = 16 bits
PA Power = PA_HIGH
Should radio.setDataRate(RF24_250KBPS); affect immediately?
This will never work, because the 250KBPS speed is only available on the newer nRF24L01+ chip, not the older nRF24L01. Get the data sheets from Nordic and read up on the chip differences.
Thanks much this thread, PaulS and Pico, I got this working at least some way. Now I've Mega which has W5100 ethernet to connect Cosm, and with 433Mhzh transmitter to control Nexa by using it's webserver, and now also nRF24L01+ to read temperatures from Nano with nRF24L01+ ds18b20. This works ok but code looks bad, I think I need to use interrupts, more studying
Can you please tell us more details of how you have the nRF24L01 and Ethernet interfaces wired? What did you need to do to get them both working together?
finnduino:
Thanks much this thread, PaulS and Pico, I got this working at least some way. Now I've Mega which has W5100 ethernet to connect Cosm, and with 433Mhzh transmitter to control Nexa by using it's webserver, and now also nRF24L01+ to read temperatures from Nano with nRF24L01+ ds18b20. This works ok but code looks bad, I think I need to use interrupts, more studying
hey finnduino,
just like terryking228, i think it would be interesting to know how you managed to get an ethernet shield working together with a NRF24l01+ module at the same time
Having following Arduino (clone) 1280 <--> NRF24L01, hopefully I checked these ok:
51: MOSI
GND: GND
52: SCK
50: MISO
48: CE
49: CSN
3V: VCC
GND: GND
Pin6 is connected to 433Mhz transmitter
Pin5 is connected to 433Mhz receiver (not used but just connected)
Pin22 has thermometers (2pcs)
w5100 network board is normally attached to default pins of 1280, not yet any other problems than this is slow...
Some parts of my currently ugly code: #include <ERxPachube.h> #include <SPI.h> #include <Client.h> #include <Ethernet.h> #include <Server.h> #include <Udp.h> #include <OneWire.h> #include <DallasTemperature.h> #include <NexaTransmitter.h> #include <RF24Network.h> #include <RF24.h>
--- clip -- ... and so on
byte mac[] = { 0xE8, 0xB3, 0x3A, 0x30, 0x41, 0x65};
IPAddress ip(192,168,1,13);
IPAddress device(192, 168, 1, 13); // Only if useDhcp is false
IPAddress gateway(192, 168, 1, 1); // Only if useDhcp is false
IPAddress subnet(255, 255, 1, 0); // Only if useDhcp is false
IPAddress dnsIP(192, 168, 1, 1); // Only if useDhcp is false
int ONE_WIRE_BUS = 22 ;
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensors(&oneWire);
DeviceAddress thermometer;
struct payload_t
{
unsigned long ms;
unsigned long counter;
};
void setup(){
Ethernet.begin(mac, ip,dnsIP,gateway,subnet);
pinMode(ledPin, OUTPUT);
dataout.addData(0);
dataout.addData(1);
dataout.addData(2);
pinMode(txPin, OUTPUT);
// clip enabling Nexa 433Mhz ---
NexaTransmitter remote(6, 12345678); // Create the nexa remote on pin6 with remote id
// radio up:
SPI.begin();
radio.begin();
network.begin(/channel/ 90, /node address/ this_node);
// end setup
//After that there is void loop(), having things like:
network.update();
while ( network.available() )
{
// If so, grab it and print it out
RF24NetworkHeader header;
payload_t payload;
network.read(header,&payload,sizeof(payload));
Serial.print("Received packet #");
Serial.print(payload.counter);
//and so on
}
Here screenshot how test version is currently working, I go to web page, then it at least somehow shows current temperature 25,12'C from sensor connected directy to Mega1280 but also 22'C received from 2.4Ghz sensor. It's sending those values to Cosm and 433Mhz switches are controlled by http GET commands
Stanley:
Are you expecting issues or facing such power issues ??
In the light of your comment, no. I believe these things should be addressed by the board manufacturer in accordance with the recommendations of the chip manufacturer and should not be something for the end user to get too paranoid about.
However there have been some issues and bypass caps have been seen as solution. See the abovementioned link. As to it being the routine solution, who would know?
For all that, I have reserved space on my proto for a tantalum right next to the power pins, so I have no qualms about installing it. I have not yet received my transceivers and I'm just trying to have all the ducks lined up as I have to have everything up and running by the end of May.