Today I started messing with the idea of getting an arduino uno to autoconnect with another arduino uno using the nrf24l01 breakouts.
I dont have a particular goal in mind per se but was just wanting to get the logistics down so I started simple as pie. One arduino at address 0x000000000B LL sends a one element array over and over. Easy.
The second arduino goes through a for loop in the void loop().
The for loop is set to loop 16 times. It starts with the address 0x0000000000 LL and checks to see if radio.available is true. if it is, the program simply states it has found an address over serial. If not it states the address is invalid. afterwards it increments the address by one and repeats until the address gets to 0x000000000F LL (or the for loop repeats 16 times.)
once the address gets to 0x000000000B (or the transmitter address) it states that it has found an address over serial. So far so good!
Now the problem arises when the address increments to the next address. No matter what I seem to do or change, once radio.available() becomes true once....it seems to stay true until the function is called again from the main loop in which case it repeats the same scenario. I have worked hours on such a small program to no avail. Can someone help please??? I must be overlooking the most simple of things but for the life of me I have no idea what.
I have figured out that if you take out the myRadio.read(rxData, sizeof(rxData) ) function in the searchAddresses function myRadio.available() returns true every time there after instead of just everytime thereafter until the searchAddresses function is complete.
i dont need help to get the nrf24s working. i have been using them for quite a while on a basic level. I just cant get this specific example working and was wondering if anyone knows what simple thing I am overlooking. I didnt see anything in the examples you posted that help out. I did update my rf24 library to the one you referenced. After recompiling both arduinos it didnt change anything.
crs90:
i dont need help to get the nrf24s working. i have been using them for quite a while on a basic level.
You still do not know how the chip works, or this
crs90:
I have figured out that if you take out the myRadio.read(rxData, sizeof(rxData) ) function in the searchAddresses function myRadio.available() returns true every time there after instead of just everytime thereafter until the searchAddresses function is complete.
would be just logical, because radio.available() returns true if a packet was received and is available for download.
BTW you are using "not recommended" or "warned against" addresses.
7.3.2 Address
This is the address for the receiver. An address ensures that the packet is detected and received by the
correct receiver, preventing accidental cross talk between multiple nRF24L01+ systems. You can configure
the address field width in the AW register to be 3, 4 or 5 bytes, see Table 28. on page 63. Note: Addresses where the level shifts only one time (that is, 000FFFFFFF) can often be detected in noise and can give a false detection, which may give a raised Packet Error Rate. Addresses as a continuation of the preamble (hi-low toggling) also raises the Packet Error Rate.
Whandall:
You still do not know how the chip works, or this
would be just logical, because radio.available() returns true if a packet was received and is available for download.
BTW you are using "not recommended" or "warned against" addresses.
well i was just trying to say I know enough about them that i can get their full cooperation if I hard code addresses for them in their sketches. Ill try the recommendation for the address scheme. I have been using this range for quite a while happily but ill change it and see. That doesn't make too much sense tho. radio.available() returns false every time until at which point the address of the transceiver is reached in the for loop. It then will return true every time thereafter. Hitting perfect on the 12th repeat of every loop consistently tells me its not a noise or interference problem.
What little that is mentioned on the subject online all seem to point to the rx buffer needing to be flushed. flush_rx() is a private method in the rf24 class unfortunately. I did alter the cpp file. Under rf24::startListening() function the line....
//flush_rx();
was found but obviously commented out. I took out the '//' it and recompiled my project and it made radio.available return false every time so i changed it back thinking it was commented out for a reason.
Whandall:
I would not call checking 16 addresses out of 1099511627775 autodetect.
usually you start small to make a working example easier to obtain.
secondly there is only 255 unique address available according to the rf24 class reference. Since the rf24 class is what my question is about I figured Id read the class reference first. It states the first 32 bits have to be the same on all nodes leaving only a byte to be distributed to nodes on the network.
16^1 was the first hurdle
16^2 would cover all possible addresses.
sorry im not some genius. if i was i wouldnt be asking for help on the arduino forum.
crs90:
secondly there is only 255 unique address available according to the rf24 class reference. Since the rf24 class is what my question is about I figured Id read the class reference first. It states the first 32 bits have to be the same on all nodes leaving only a byte to be distributed to nodes on the network.
This is simply wrong.
The limitation of the common prefix is only a limitation of pipes 2-5.
void RF24::openReadingPipe ( uint8_t number,
uint64_t address
)
Open a pipe for reading.
Up to 6 pipes can be open for reading at once. Open all the reading pipes, and then call startListening().
See also:
openWritingPipe
Warning:
Pipes 1-5 should share the first 32 bits. Only the least significant byte should be unique, e.g.
openReadingPipe(1,0xF0F0F0F0AA);
openReadingPipe(2,0xF0F0F0F066);
Pipe 0 is also used by the writing pipe. So if you open pipe 0 for reading, and then startListening(), it will overwrite the writing pipe. Ergo, do an openWritingPipe() again before write().
Todo:
Enforce the restriction that pipes 1-5 must share the top 32 bits
Parameters:
number Which pipe# to open, 0-5.
address The 40-bit address of the pipe to open.
no pipes 1 thru 5. I dont use many single pipe projects. Plus 255 is plenty for me. Im not trying to sniff any nrf24 chip out there...I just want to detect arduinos that are set up to talk to arduinos they are meant to talk to.
how many addresses are irrelevant anyways. My question involves getting 16 to work. I never asked how many addresses can I talk to.
You're quoting the documentation of an old and obsolete library (maniacbug).
From the reply to Robin2's post I got the impression that you do not use that library,
but the far superior library Robin2 linked to.
The maniacbug stuff is a very good base, but has a couple of errors and misunderstandings in it.
The real information is in the datasheet.
Sorry when I misintrepreted your wish to 'autoconnect' as 'autodetect'.
As there is no connection in the nRF communication besides the ack-process,
there is no need to connect to somebody.
You can listen to addresses (any 2 at a time, plus 4 more with restrictions).
You can send to any address, with or without expecting an acknowledgement.
Likewise each rx-address can be configured to give acknowledges and up to 32 bytes optional data
(for three addresses at a time).
You 'only' have to take care that only one module acknowledges a specific address at the same time.
Having some modules flooding the air with junk, and one module trying to detect which addresses
are used to overload the medium is not a good strategy anyway IMHO.
well right now I am just trying to detect which ones are out there. I would eventually store all found addresses in an array for communication.
as for the switch to the updated rf24 library, I ended up rolling back since it didnt help my purpose and I was afraid of backwards compatibility with my older projects.
with so many addresses available what would be the proper logistics be of sniffing out compatible addresses. I dont need code...just the thought process.
I am just looking for clean modular compatibility. If I want to add another wireless sensor to a old project I sure dont want to take the atmega chip and upload a new sketch with a hard coded address every time.
You should not use the ManiacBug library if you do not overhaul it.
If you have control over the nodes you want to detect, you could make them
send to a 'discovery-address' without acknowledgment from time to time.
The discovering station could just listen to this channel (again without acks).
The packet that the nodes send could bear more information about the node.
Like an address that this station acks to, what type of node it is, which capabilities it has,
its location, uptime, ... You have 32 bytes in each packet and nobody stops you from having
a 'segment field' that denotes which part of the bigger information chunk this packet is.
You don't have to include a length field, as the chip reports the packet length.
well on a side note i realized my problem from my original post. my "simple tx code" was a little too simple. No delay was overfilling the rx buffer??? And since the address was so close to hex 16 it just looked like radio.available() was returning true for the rest of the functions duration.
If a packet is received while all three rx buffers are already filled I think it will replace the 3rd waiting one.
Do you believe in Voodoo also?
hence the question marks. i changed the address to a lower one and realized that radio.available() was only returning true like 4 times and false for the rest. I added a 75 milli delay in the transmitter and now the rx arduino can "detect" up to 5 different nodes and store them into an array. I dont know if its voodoo or not but it works like Id expect the code i typed up to behave. Does arduino have roots in Haiti?
im researching the better strategy now. Im just mad that I spent so much time not realizing I had no delay in the transmitter once I looked over the code yet again.
You asking if I believe in voodoo in a condescending tone for simply stating that radio.available() was not returning false for the duration of the function it just looked like it was is pretty ridiculous. I literally have serial output to prove it wasnt returning true the whole function. So why do I have to believe in mysticism to know radio.available() was not returning true the whole function only looking like it was.
I will retort ridiculous questions with another