ellen

ps. i am wondering what could be the reason why it takes 5 milliseconds to send 32 bytes (each packet) at 2mbps with your library (i did set radio.setRetries(0,0); else it was even more if the receiver is off or out of range, 45ms)

ps. is it also possible to read out the pipe address so that a reveiver can set up an receiving pipe with that address? (needed for unknown/unique adresses) just like how tcpip works for examplebecause now it seems i can only use upto 6 devices/addresses :~

and/or is it possible to send/read raw packets?seems it can only receive when the (pipe)address is known, i try to disable shockburst but then i have no clue how to receive the datathere is no clear example in the nrf24l01+ product specification pdf.

ps. i am wondering what could be the reason why it takes 5 milliseconds to send 32 bytes (each packet) at 2mbps with your library (i did set radio.setRetries(0,0); else it was even more if the receiver is off or out of range, 45ms)

ps. is it also possible to read out the pipe address so that a reveiver can set up an receiving pipe with that address? (needed for unknown/unique adresses) just like how tcpip works for example

What you would want to do is disable Auto-Acknowledge, and have all your transmitters use the same pipe. Of course you'd have to implement a carrier-detect system where a transmitted made sure the line was clear before transmitting. Like Ethernet does.

Yup. That's the simplest case. It would be interesting to extend it for multiple units on the same pipe. I just haven't needed that. For multiple nodes, I use a multi-hop system, my RF24Network network layer. In my use, rarely are >6 nodes within speaking distance from each other.

for sending multiple packets with radio.write 5-6ms delay is way to much to get a decent speedto send send data at full speed (250kbit/1mbit/2mbit) succesfully with only 0-1ms delay i had to change it into this:

// ------------ // At this point we could return from a non-blocking write, and then call // the rest after an interrupt

// Instead, we are going to block here until we get TX_DS (transmission completed and ack'd) // or MAX_RT (maximum retries, transmission failed). Also, we'll timeout in case the radio // is flaky and we get neither.

// The part above is what you could recreate with your own interrupt handler, // and then call this when you got an interrupt // ------------

// Call this when you get an interrupt // The status tells us three things // * The send was successful (TX_DS) // * The send failed, too many retries (MAX_RT) // * There is an ack packet waiting (RX_DR) //bool tx_ok, tx_fail; <-- excluded because i had to exclude whatHappened //whatHappened(tx_ok,tx_fail,ack_payload_available); //causes 2ms delay in TX :(

//printf("%u%u%u\n\r",tx_ok,tx_fail,ack_payload_available);

//result = tx_ok; <-- excluded because i had to exclude whatHappened IF_SERIAL_DEBUG(Serial.print(result?"...OK.":"...Failed"));

maniacbug

Ok, I see the overall problem. This library is tuned to send packets occasionally with high reliability and low power consumption, not to send a non-stop stream of high-speed data. Your modifications root out some of those optimizations, in favor of higher throughput.

You also should skip the power down/power up cycle. Where you are just jamming data as fast as you can, you want the transmitter powered up the entire time.

The delay(2)'s are too high, although 280us delay is needed after power-up. The CE(high)/15us delay/CE(low) is useful to conserve power in the case where transmissions are infrequent. Obviously in your case, that's not needed because you're always jamming packets through.

Are you sure 'whatHappened' causes a 2ms delay? Anyway if you don't call it, you won't know whether your packet went through. Ah but then again, you don't care, because you have ACK's off.

ellen

well i am realizing it is maybe better to write my own library since yours is optimized for sending/reading packets occasionally like you say, anyway your library is still very useful to me together with the product specification how to use the chip

i will have a base station and 5 remote units...maniacbug, can you help me out... (maybe some newbie questions)

do i need to go with the "complex" mesh network or can i make it a simple client to base from each remote sensor to the base...

if i understand correct the mesh network example if i setup all the sensors as "relays" i can increase the distance from the base to the last sensor because the packet is rerouted between each sensor i.e

if sensor5 is not in range with base but sensor5 is in range with sensor4 and sensor 4 with base the packet will go s5->s4->base , is this correct ?(maybe one advantage in the mesh network)..

reading you mesh code example, i don't understand how to set the role, is the role hard encoded on the table

The first thing to understand is that RF24 is only a driver for the wireless module. It does not include any networking of any sort. It's just a way to send messages between radios.

In your case, you may not need anything fancy. A radio using RF24 can communicate easily with 6 other radios as long as they are all in range of the base. The starping is the example to try out in this case.

If you really want something a bit more complex, you can check out RF24Network. This includes a minimal networking feature set to provide static addressing and routing across the network. It doesn't implement a true 'mesh' topology, but rather a 'tree' topology.

Quote

if sensor5 is not in range with base but sensor5 is in range with sensor4 and sensor 4 with base the packet will go s5->s4->base , is this correct ?

If you use RF24Network, yes you can set the network up to do as you say, but it's all STATIC. So you set up node 5 to ALWAYS transmit to node 4, and node 4 to always transmit to the base. In this case, 5 is a leaf and so it can sleep, but 4 should stay awake to catch traffic from 5.

Quote

reading you mesh code example, i don't understand how to set the role, is the role hard encoded on the table

fca

Hi the code is from the rf24network..But I believe that i will have all the modules in range of the base.So the the starexample is a good start..I will remove the code from the pong on ping units and ping code from the pong...Will these have issues with sensors sending at the same time ?I would prefer to have the base pulling from the sensors but then I couldnt put the sensors sleeping...

Thanks

maniacbug

I will remove the code from the pong on ping units and ping code from the pong...

That's fine. I prefer them together because it makes it much easier to maintain a single sketch rather than 2 and have to keep track of which sketch is on which board. Totally personal preference of course.

Quote

Will these have issues with sensors sending at the same time ?

Shouldn't have problems because the radios have built-in retries. You can also crank up the retries to 15 retries, which should totally overcome any collisions.

Quote

I would prefer to have the base pulling from the sensors but then I couldnt put the sensors sleeping...

Right. The usual design is to have the sensors send for this very reason.

luxeomni

just a quick question from a project of mine point of view:In theory could the r24network library could work with something like 0 to 99 nodes ? ( the nodes won't necessary send data at the same time) ?

And a little other question : do you know if someone came up with a pcb design as small as possible with mcu + nrf24l01+ integrated ?

maniacbug

just a quick question from a project of mine point of view:In theory could the r24network library could work with something like 0 to 99 nodes ? ( the nodes won't necessary send data at the same time) ?

RF24Network is pretty specialized and bare-bones. Any given node will only listen to 6 other nodes at once, taking advantage of the chip's built in pipes. If you weren't worried about collisions, you could have many nodes with the same node address. So the parent node would listen to all of those nodes thinking it was a single node.

direk

I was trying to upload other samples, restart whole devices or only nRF module, etc... without success... I have no idea what is going wrong, If it will be SPI problem I belive that other config values will be zeros or FF's...

luxeomni

RF24Network is pretty specialized and bare-bones. Any given node will only listen to 6 other nodes at once, taking advantage of the chip's built in pipes. If you weren't worried about collisions, you could have many nodes with the same node address. So the parent node would listen to all of those nodes thinking it was a single node.

You could take a look at my sensor node. This is the small PCB I use, although it's still through-hole so it could be even smaller with SMD parts.

So basically i could have multiple nodes with same adress, but with different IDs? ( not bothering with collisions ).