Pages: 1 2 [3] 4 5 ... 17   Go Down
Author Topic: RF24 Library: Driver for nRF24L01(+) 2.4GHz Wireless Transceiver  (Read 97183 times)
0 Members and 1 Guest are viewing this topic.
Seattle, WA
Offline Offline
God Member
*****
Karma: 11
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Cost is definitely important.  iTeadStudio sells nRF24L01+ modules for $4.  Hard to beat that!

The Hope RF units don't allow multiple transmissions at the same time, right?  And don't do ACK's or auto-retry's, right?  That's the original reason I went with these.  Less complicated link-layer protocols to write.

Anyway, regarding the 70% drop in range...  That's why it's important to measure smiley  Otherwise it's all theory and speculation.

And yes, the library lets users set the channel to anything the chip allows.
Logged


Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

BTW I've just noticed the library allows channels less than 2 and above 80 to be specified - in other words to transmit outside the 2.4GHz band...

There has been some discussion on things like channels and channel spacing enforcement within the driver. I personally would like to see a standardized number of channels* and channel spacing enforcement (basically channel abstraction) unless an option is given to disable. At this point I'm not sure it will be permitted in the defacto driver.

Also, my understanding is that some countries do allow use above channel 80 - but the US is not one of them. And thanks for the heads up on the lower end. I honestly never looked on the low end. I just assumed it started at the legal (US) limit. Good to know. Thanks.

* I saw this because you don't normally see WIFI APs deployed on channels 1, 2, 3, 4, 5, 6... Rather, you typically see channels 1, 6, 11 used because of their channel spacing.
Logged


0
Offline Offline
Shannon Member
****
Karma: 206
Posts: 12076
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Cost is definitely important.  iTeadStudio sells nRF24L01+ modules for $4.  Hard to beat that!

The Hope RF units don't allow multiple transmissions at the same time, right?  And don't do ACK's or auto-retry's, right?  That's the original reason I went with these.  Less complicated link-layer protocols to write.
No, its the same interface, same FIFOs, same registers, same 'shockburst' style retries, I've had it interworking with the NRF.

I don't think you mean 'multiple transmissions at the same time' do you smiley-wink
Quote
Anyway, regarding the 70% drop in range...  That's why it's important to measure smiley  Otherwise it's all theory and speculation.

And yes, the library lets users set the channel to anything the chip allows.
I don't think its a good idea to release a library that permits out-of-band transmission out of the box...  And defaulting to channel 1 is just wrong - that spills out of band.
Logged

[ I won't respond to messages, use the forum please ]

0
Offline Offline
Shannon Member
****
Karma: 206
Posts: 12076
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

BTW I've just noticed the library allows channels less than 2 and above 80 to be specified - in other words to transmit outside the 2.4GHz band...

There has been some discussion on things like channels and channel spacing enforcement within the driver. I personally would like to see a standardized number of channels* and channel spacing enforcement (basically channel abstraction) unless an option is given to disable. At this point I'm not sure it will be permitted in the defacto driver.

Also, my understanding is that some countries do allow use above channel 80 - but the US is not one of them. And thanks for the heads up on the lower end. I honestly never looked on the low end. I just assumed it started at the legal (US) limit. Good to know. Thanks.
The ISM band ends at 2.485.  _Spread-spectrum_ (such as WiFi) is allowed at low power in some parts of the US above 2.485 AFAICT but I don't believe from what I've found that licence-free GFSK is legal outside the ISM band.  Unless you have a more authoratative reference.
Quote

* I saw this because you don't normally see WIFI APs deployed on channels 1, 2, 3, 4, 5, 6... Rather, you typically see channels 1, 6, 11 used because of their channel spacing.

Logged

[ I won't respond to messages, use the forum please ]

0
Offline Offline
Shannon Member
****
Karma: 206
Posts: 12076
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Ah, I've finally found something more authoratative (FCC online frequency table - which amusingly is a word document and not online in the sense I'd assume - it also lacks a TOC!).  US does allow ISM between 2.400 and 2.500 GHz.

Note that microwave ovens are centred at 2.5GHz so channels 80-98 are not necessarily a useful part of the band !!

Might be useful to have a setRegion() call to say what the current legal channels are (assuming they don't change very often!).
Logged

[ I won't respond to messages, use the forum please ]

Seattle, WA
Offline Offline
God Member
*****
Karma: 11
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Ah, I've finally found something more authoratative (FCC online frequency table - which amusingly is a word document and not online in the sense I'd assume - it also lacks a TOC!).  US does allow ISM between 2.400 and 2.500 GHz.

Fascinating.  Can you share the link?

Yeah, I was going to change the default channel anyway, up to 100 or higher, which always seems to be free from interference.  But gauging from your earlier comment, I'll guess you don't find that satisfactory smiley

Quote
I don't think its a good idea to release a library that permits out-of-band transmission out of the box

My view here is that the lowest-level library exists to drive the hardware.  Whatever the hardware  allows, so too should the driver.  Regulatory issues belong up at a higher layer.  Having this available for users in the documentation would be super-useful, though.
Logged


Dallas, Texas
Offline Offline
Sr. Member
****
Karma: 3
Posts: 267
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Ah, I've finally found something more authoratative (FCC online frequency table - which amusingly is a word document and not online in the sense I'd assume - it also lacks a TOC!).  US does allow ISM between 2.400 and 2.500 GHz.

Note that microwave ovens are centred at 2.5GHz so channels 80-98 are not necessarily a useful part of the band !!

Might be useful to have a setRegion() call to say what the current legal channels are (assuming they don't change very often!).


That's the general concept I desire. From what I can tell, a large portion of the world shares the US as a subset. So, based on your comment, 2-80 as basically a gimme. And unless additional spectrum is unlocked through such mechanisms, IMOHO, they should be excluded.

Quote
I don't think its a good idea to release a library that permits out-of-band transmission out of the box

I completely agree so long as "out of the box" means, by default. In my opinion, so long as the developer must explicitly take action to violate common limits, its good enough. Not to mention, it also ensures reasonable FCC liability protection for the driver developers.

Quote
Yeah, I was going to change the default channel anyway, up to 100 or higher, which always seems to be free from interference.  But gauging from your earlier comment, I'll guess you don't find that satisfactory

Ya,  that was on my list of things to discuss with you. In some variations of code I had the default channel set to 1. And that was based on assumptions of bleed so as to not interfere with devices below.

Logged


Seattle, WA
Offline Offline
God Member
*****
Karma: 11
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

No, its the same interface, same FIFOs, same registers, same 'shockburst' style retries, I've had it interworking with the NRF.

Wow, indeed it is.  The datasheet is shockingly similiar to the nRF.  Any idea where to get them in the US?
Logged


0
Offline Offline
Shannon Member
****
Karma: 206
Posts: 12076
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

No I don't...


BTW I've tried using the library from Arduino now, found that it doesn't support setting address lengths - so I've hacked round that to allow it to talk to my test rig (3 byte addresses).  Something's still not quite right as the receive side is happy but the transmit side (Arduino) is getting max retries...

Suggest adding RF24::setAddressLengths() and changing the address types from uint64_t to byte*.

Are you planning to add proper asynchronous support?
Logged

[ I won't respond to messages, use the forum please ]

Seattle, WA
Offline Offline
God Member
*****
Karma: 11
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Suggest adding RF24::setAddressLengths() and changing the address types from uint64_t to byte*.

Ah, yeah 3 byte address lengths is something that should be supported, that's true.  I quite like uint64_t's for simplicity.

Are you planning to add proper asynchronous support?

What is 'proper asynchronous support'?
« Last Edit: August 05, 2011, 01:57:31 pm by maniacbug » Logged


Indonesia
Offline Offline
Newbie
*
Karma: 1
Posts: 49
ayooo,,,DAB!!!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I use RF24's sketch example : pingpair_test.pde

Don't use the sketches in the test directory.  Use the examples in 'examples'.  Start with examples/pingpair.

thanks a lot..the code works..
Logged

Program Studi Instrumentasi Medis
Politeknik Mekatronika Sanata Dharma
Yogyakarta Indonesia

0
Offline Offline
Shannon Member
****
Karma: 206
Posts: 12076
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Suggest adding RF24::setAddressLengths() and changing the address types from uint64_t to byte*.

Ah, yeah 3 byte address lengths is something that should be supported, that's true.  I quite like uint64_t's for simplicity.

Are you planning to add proper asynchronous support?

What is 'proper asynchronous support'?
The ability to run code while transmitting a packet or waiting/receiving a packet, with both interrupt and polling methods to re-synchronize.  For instance on a different microController I needed to transmit packets every 208us and the time it took to populate a packet buffer was about  100us.  The transmit time for 32byte packet at 2Mb is 152us, which done synchronously would only leave 208-152 = 56us to populate the fifo (faster than SPI could do it).

It was possible to do this without interrupts by filling the FIFO, waiting for previous TX to finish, then starting a new one asynchronously. The same considerations applied at the receive side.
Logged

[ I won't respond to messages, use the forum please ]

Seattle, WA
Offline Offline
God Member
*****
Karma: 11
Posts: 673
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

The ability to run code while transmitting a packet or waiting/receiving a packet, with both interrupt and polling methods to re-synchronize.  For instance on a different microController I needed to transmit packets every 208us and the time it took to populate a packet buffer was about  100us.  The transmit time for 32byte packet at 2Mb is 152us, which done synchronously would only leave 208-152 = 56us to populate the fifo (faster than SPI could do it).

It was possible to do this without interrupts by filling the FIFO, waiting for previous TX to finish, then starting a new one asynchronously. The same considerations applied at the receive side.

Interesting...  Wouldn't interrupts be the classic way to handle this problem?  But still, it makes sense how this could be useful.  To answer your question, though, I do not have plans myself to make such a change.
Logged


0
Offline Offline
Shannon Member
****
Karma: 206
Posts: 12076
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Interrupts might be, but not on the Propeller which was the uController I've been using for this.  The whole reason the chip has a FIFO on it is to allow pipelining the data transfer with transmit/receive for these high data rates (well high for SPI).   

And I'll admit the Arduino isn't really the host to take advantage of high sustained data rates smiley-wink   (actually it would be an issue at lower on-air datarates as a packet at 250kbps takes 1.3ms to send (including TX power up) which is a long time...)

Further research has shown the the RFM70 doesn't interwork with the nRF24L01+ for auto-acknowledge - when a RFM70 sends to a nRF24L01+ the receiver sees a valid packet and is happy but the transmit keeps retrying until max retries is reached.  I suspect the time window for acknowledge packets is different (well at 2M at least).   Haven't tried the other direction yet.
Logged

[ I won't respond to messages, use the forum please ]

Offline Offline
Edison Member
*
Karma: 8
Posts: 1341
If you're not living on the Edge, you're taking up too much space!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Is there a library I can use with RFM70?
Code?
Logged

If you fall... I'll be there for you!
-Floor

Skype Brighteyes3333
(262) 696-9619

Pages: 1 2 [3] 4 5 ... 17   Go Up
Jump to: