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...
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 Otherwise it's all theory and speculation.And yes, the library lets users set the channel to anything the chip allows.
Quote from: MarkT on Aug 04, 2011, 10:30 pmBTW 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.
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.
I don't think its a good idea to release a library that permits out-of-band transmission out of the box
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!).
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
No, its the same interface, same FIFOs, same registers, same 'shockburst' style retries, I've had it interworking with the NRF.
Suggest adding RF24::setAddressLengths() and changing the address types from uint64_t to byte*.
Are you planning to add proper asynchronous support?
Quote from: copet_pitik on Aug 04, 2011, 11:12 amI use RF24's sketch example : pingpair_test.pdeDon't use the sketches in the test directory. Use the examples in 'examples'. Start with examples/pingpair.
I use RF24's sketch example : pingpair_test.pde
Quote from: MarkT on Aug 05, 2011, 02:35 amSuggest 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. Quote from: MarkT on Aug 05, 2011, 02:35 amAre 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.
Please enter a valid email to subscribe
We need to confirm your email address.
To complete the subscription, please click the link in the
email we just sent you.
Thank you for subscribing!
via Egeo 16