If it was not for some deadlines I'd be trying your test code this afternoon - unfortunately it will be 1-2 weeks before I have time for the nRF24L01+ again... but by that time, I'll have some SparkFun modules too !
Leon & Mark_T
Sounds like the problems I had are an exception, not the rule. I am VERY glad to hear that, as the price/performance on these little guys is great.
I will order some modules from the ebay link Mark posed as well.
I've just added some pads to my PCB so that some of the PIC18F24J11 I/Os can be used. I managed to squeeze six of them in: Pins 9,10, 11, 22, 23, and 24.
I might make design a simple PCB with just the PIC and a module, that I can make at home, just for testing purposes.
Ron asked if I had a version of the Nordic driver that uses SPI_ASM from the Prop Tool library. It turns out I didn't have working code using that object. So I modified my driver to use SPI_ASM.
This is not at all an elegant solution. I'd suggest those wishing to use these Nordic modules, look at my other drivers.
I originally didn't use SPI_ASM because it has a lot of overhead to set the data rate and the pins (which are set with each call to the object).
I found some bugs in my earlier code I've posted. I'll try to get fixes posted soon (hopefully today).
This driver is slower than the the others I've posted in this thread. Don't think of this as a Nordic nRF24L01+ driver; think of this code as a SPI_ASM demo.
This code displays the data received from a SparkFun Nordic FOB.
Ron has decoded the FOB data. I was just using the first byte to identify which button was pressed, Ron shows how mutiple button presses are also transmitted.
Ron also has some Basic Stamp code for these modules (there is a link in the same thread as the FOB data).
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
This driver is slower than the the others I've posted in this thread. Don't think of this as a Nordic nRF24L01+ driver; think of this code as a SPI_ASM demo.
Thanks Duane! I had not used the SPI_Asm object before and was having trouble so this should really help me out!
So did you write your own object? I don't suppose I could talk you into posting it?
I was just adding up instructions in my SPI driver and I think it's sending data to the device at 3.6Mb/s (454.5kB/s) @80MHz. Since I'm using packets there is some overhead. I haven't tested what kind of continuous data rate I can get with these transceivers. So far I haven't needed much speed but it would be nice to know what they are capable of.
I just ordered six of the transceivers you linked to on ebay. (The six cost less than buying two from SparkFun.)
Duane
Yes, I did write one - in fact since my last posting I've modularized it into a better shape - I got a little more work to do I think to make it pretty, I'm hoping to do that this week. My SPI loop is 24clocks per bit I think, not allowing for call/return overhead - I'm driving MOSI and sensing MISO even when both aren't necessary - I can get 2Mb in and out but the SPI rate is close to the wire.
Also I've discovered an even cheaper nRF24L01+ clone, the RFM70, although its not directly compatible - it has an alternate register bank that needs programming to make it work correctly (and I haven't succeeded in getting this right yet on the Prop). It also seems to lack 250kHz mode. The datasheet is a bit confused (for instance output power is quoted as both 1mW and 5dBm).
I used "5" because I didn't remember if zero would work correctly with that driver. The Nordic modules don't need any delay. I changed the driver to eliminate the delay caused by the code allowing a variable delay amount (and a bunch of other changes).
Also I've discovered an even cheaper nRF24L01+ clone, the RFM70, although its not directly compatible - it has an alternate register bank that needs programming to make it work correctly (and I haven't succeeded in getting this right yet on the Prop). It also seems to lack 250kHz mode. The datasheet is a bit confused (for instance output power is quoted as both 1mW and 5dBm).
Well I've spent far too long tonight getting the RFM70 module to work - it has a number of non-compatibilities and semi-compatibilities with the NRF24L01+... I was using a 3 byte packet address (you can have 3 4 or 5 bytes) and for the RFM70 you must still write 5 bytes to get those 3 bytes in - that was the hardest problem to find.
The main problem with the RFM70 though is that its receive side is rubbish. There is a configurable LNA (low noise amp) option - with it on the thing overloads drastically with a nearby 1mW signal, with it off you are 20dB down in sensitivity. There is scope to set up RSSI detection (you have to program the threshold and then get a single flag back to say if its above that or not). I think using this awkward RSSI sensing is going to be mandatory to get the thing to behave at all usefully - by comparison the NRF module just works (and with no detectable overload problems).
Having said that it does put out a little more power and seems a bit more sensitive with the LNA on (despite having a smaller PCB antenna) - I've only tried 2Mb so far and I am inter-working between NRF24L01+ and the RFM70 modules both directions OK.
The basic difference in driver is setting up the second register bank correctly (lots of magic 32 bit values with a handful of tweakable bits documented amongst them).
Yes, 24bit at 48k samps/s - only one channel but that already takes > 1Mb/s.
The idea is linking two battery powered PA speakers wirelessly. Input is WM8783 stereo sigma/delta 24bit ADC with I2S interface -> prop -> local speaker (class D) and RF link to other identical unit for other stereo channel.
WM8783 is about $1 (and only 8 pin so easier to solder than many SM chips). Class D is 8bit PWM at 384kHz driven from sigma-delta 2 pole noise-shaping filter with ability to phase-lock to the incoming data rate (since the Xtals will be slightly different at tx and rx sides).
The bit I'm specially happy with is the automatic compensation in the PWM for the stretched and shrunk cycles (needed for locking to TX clock) in the noise-shaping feedback. There will be more info at some point.
Well I've spent far too long tonight getting the RFM70 module to work - it has a number of non-compatibilities and semi-compatibilities with the NRF24L01+...
I really like XBEEs and their ease of use.
The only reason I decided to get the Nordics was the FOB module. Even thought it's range is limited, the small size and long battery life make it attractive for applicatiions like Duane's Panic Buttons...
I got a few of the Sparkfun modules and ran the demo code, works good so far, not sure what do to from here except study the code and see how it works. Thanks Duane and Leon for working on this demo, this is a major head start.
I removed a lot of stuff from the demo to try to see how fast a module could send and receive on the other end. The screen is set to 2millisecond, the top line is the xmit LED, the line just below it is the receive LED. There are 50 divisions wide, the pulses are 2 divisions apart from xmit to readpayload. So is this correct 2/50 = .04millisecond per div, X 2 divisions = 80microsecond delay from send to read?
I uploaded the demo with changes.
No tests yet involving reading any real data testing.
I've just barely tried optimizing this object for speed (other than speeding up the base SPI object).
There's a delay in the "NordicBeta" file inside the method "TransmitString".
outa[SpiCe]~~
waitcnt(1000 + cnt) ' > 10us 800 = 10 us @ 80MHz
outa[SpiCe]~ ' Spin might be slow enough not to need a delay
I don't recall if I tested if this delay is needed. If it is, it might be able to be reduced. 381 is the shortest delay that can be used with a Spin waitcnt. You could try a 381 cycle wait if commenting out the line doesn't work.
I've sure there are lots of other places this code could be optimized.
Also the demo uses a 24 byte payload and CRC. You'd want to use a 1 byte payload and turn off CRC.
Change:
configNew byte %00111111
To:
configNew byte %00110011
I believe that should turn of the error checking.
To reduce the payload, change:
rxPayload byte 24
To:
rxPayload byte 1
I'll look through the code and make sure there are other changes require for the small payload. I don't think there are any other changes needed.
I've been asked a couple of times about how to hook up the inexpensive ebay Nordic modules.
Here's a pinout diagram.
Here's a schematic.
You'll need to make sure the pin constants used in the demo match the pins used with your setup.
Yes, these devices use six I/O pins. I believe it's possible to use these without using the interrupt pin (IRQ). To use the modules without using the interrupt pin requires the module be read to determine if there's a new packet or not. The driver I posted requires the interrupt pin be used. It may be possible to combine the MOSI and MISO pins but I'm not sure. If it is possible to combine the data pins, it would require a change in the driver.
The Nordic nRF24L01+ requires a microcontroller on both the transmitting module and the receiving module in order to provide the necessary SPI communication protocol the device requires for communication. These can't be used like a XBee to pass a serial connection in transparent mode.
I've used these module for remote control in several projects. One example of using these as a remote was my remote controlled Roomba. To control the Roomba I used a PlayStation 2 controller connected to a Propeller Proto Board. This Propeller Proto Board also had a Nordic module attached to it. The Propeller would read the inputs from the PlayStation 2 controller and send packets with this input data to the Nordic module. The Nordic module would then pass the packet on to a second Nordic module connected to a Propeller QuickStart board on the Roomba. The Propeller on the QuickStart board would then convert the input data to appropriate messages which the Roomba would accept through its serial port.
In general, any project where I use these Nordic modules with a Propeller will require my using two Propeller in order to control the modules on both the transmitting and receiving devices. Since these are transceivers, they can both send and receive data. This allows your robot to send information back to the controller so it's possible to monitor the robot's battery power and other sensor input from your remote control unit.
An exception to this two Propeller configuration are times I've used one of SparkFun's Nordic fobs. These Nordic fobs use an ATTiny24 microcontroller to communicate with the Nordic chip. In most cases, when I've used a Nordic fob, the communication was one way with the fob sending button press information and not receiving any data back. (I was able to reprogram the ATTiny in order to both receive as well and send data but theres much the Nordic fob with the received information.) My mood enhancing LED project is an example of a project using Nordic modules where I only used one Propeller.
I've mentioned several times on the forum I have an improved driver for these transceivers. The improved code has most of the driver running in PASM. I just need to make a few minor changes to it and write a demo program for the driver before I post it. I'll make a point of posting some sort of demo and the improved driver within a week.
This is great, I'm excited to see your new demo code. I've always wanted to try doing wireless without an xBee and saw these (https://www.tindie.com/products/Propellerpowered/nrf24l01-wireless-module-24g/) which got me searching around for demo code which led me to here on the eve of new demo code! Very exciting!
This is great, I'm excited to see your new demo code. I've always wanted to try doing wireless without an xBee and saw these (https://www.tindie.com/products/Propellerpowered/nrf24l01-wireless-module-24g/) which got me searching around for demo code which led me to here on the eve of new demo code! Very exciting!
Dave
My most recent attempt of writing demo code with the faster driver didn't work. I got out my logic analyzer but then I got busy doing something else. With enough of you reminding me to get the new demo out, I'll probably make time to work on it again soon.
The demo code posted in this thread should work in the meantime.
Make sure an check out post #1 of my index to an ebay link for a bunch of cheap nRF24L01+ modules and their pinouts.
I hope you don't mind, I'm replying to your PM here so I can give the same info to the rest of the forum.
So far, the most up to date demo is in post #9 of this thread. I have a faster all PASM version I worked on with T Chap but my attempt to make a demo for the PASM driver didn't work. I'll need to dig out my logic analyzer to get it working correctly. I do plan to work on the new driver in the near future.
One of my current projects is this robot remote. The remote uses a Nordic transceiver. Once I have the touchscreen interface working correctly with the SD card menu data, I'll want to use it to control a robot. I'm pretty sure I'll want to get the faster driver usable once I'm using the remote with a robot.
I think I saw a post in the Propeller C forum about a driver for these modules being finished in C. I haven't tried it myself. I think there are C libraries available to make networks with these modules. I'll probably investigate the C options once I get myself to make the transition to C. I used to like C but now I prefer writing programs in Spin much more than programming in C.
If any of you try the C driver for the nRF24L01+ modules I hope you let us know how you liked it.
My guess is I'm a couple of weeks away from having an upgraded Spin/PASM driver for these modules (though this has been my estimate for about a year now).
If any of you haven't tried these, you really ought to. They're awfully inexpensive and they're fast. You can get a dozen of these modules for about the same price as a XBee. They do require more pins and you need to send your data in packets. These things are so cheap you can add a transceiver to all your Propeller projects.
Comments
Teens today have no love of country.
What next? Buy bridges in China? lol
I ordered 4 (from China of course), 18 days ago and arrived today. When I have time we make any tests.
If it was not for some deadlines I'd be trying your test code this afternoon - unfortunately it will be 1-2 weeks before I have time for the nRF24L01+ again... but by that time, I'll have some SparkFun modules too !
Leon & Mark_T
Sounds like the problems I had are an exception, not the rule. I am VERY glad to hear that, as the price/performance on these little guys is great.
I will order some modules from the ebay link Mark posed as well.
I might make design a simple PCB with just the PIC and a module, that I can make at home, just for testing purposes.
This is not at all an elegant solution. I'd suggest those wishing to use these Nordic modules, look at my other drivers.
I originally didn't use SPI_ASM because it has a lot of overhead to set the data rate and the pins (which are set with each call to the object).
I found some bugs in my earlier code I've posted. I'll try to get fixes posted soon (hopefully today).
This driver is slower than the the others I've posted in this thread. Don't think of this as a Nordic nRF24L01+ driver; think of this code as a SPI_ASM demo.
This code displays the data received from a SparkFun Nordic FOB.
Ron has decoded the FOB data. I was just using the first byte to identify which button was pressed, Ron shows how mutiple button presses are also transmitted.
Ron also has some Basic Stamp code for these modules (there is a link in the same thread as the FOB data).
Duane
Edit(3/11/15): Warning, the code attached is an old version. There are better options available.
I plan to upload this program or an improved version to my GitHub account
If there isn't a replacement on GitHub send me a message and I'll make sure to upload the replacement code.
Mark,
A couple of days ago, I received six modules from the seller you suggested. All six work fine. Thanks for the suggestion.
Duane
Thanks Duane! I had not used the SPI_Asm object before and was having trouble so this should really help me out!
- Ron
Yes, I did write one - in fact since my last posting I've modularized it into a better shape - I got a little more work to do I think to make it pretty, I'm hoping to do that this week. My SPI loop is 24clocks per bit I think, not allowing for call/return overhead - I'm driving MOSI and sensing MISO even when both aren't necessary - I can get 2Mb in and out but the SPI rate is close to the wire.
http://www.hoperf.com/rf_fsk/24g/rfm70.htm
My attempt at using SPI_Asm wasn't too far off.
I had two main problems.
The first was was a careless mistake - I had the MOSI and MISO pin assigments reversed.
The second was in not knowing which value to use for the Clock State in the SPI_Asm "Start" call.
How do you know to use 0 (start low) rather than 1 (start high)? From the datasheet?
Also how did you decide "5" was the correct Delay value in the "Start" call?
Thanks for taking time to create and post that code - it really helped me!
- Ron
Yes, I knew to start low from the datasheet.
I used "5" because I didn't remember if zero would work correctly with that driver. The Nordic modules don't need any delay. I changed the driver to eliminate the delay caused by the code allowing a variable delay amount (and a bunch of other changes).
Duane
I've posted the updated demos in the original post.
The driver used in the demos has been updated. I think the new driver is more useful that the earlier driver.
Duane
Well I've spent far too long tonight getting the RFM70 module to work - it has a number of non-compatibilities and semi-compatibilities with the NRF24L01+... I was using a 3 byte packet address (you can have 3 4 or 5 bytes) and for the RFM70 you must still write 5 bytes to get those 3 bytes in - that was the hardest problem to find.
The main problem with the RFM70 though is that its receive side is rubbish. There is a configurable LNA (low noise amp) option - with it on the thing overloads drastically with a nearby 1mW signal, with it off you are 20dB down in sensitivity. There is scope to set up RSSI detection (you have to program the threshold and then get a single flag back to say if its above that or not). I think using this awkward RSSI sensing is going to be mandatory to get the thing to behave at all usefully - by comparison the NRF module just works (and with no detectable overload problems).
Having said that it does put out a little more power and seems a bit more sensitive with the LNA on (despite having a smaller PCB antenna) - I've only tried 2Mb so far and I am inter-working between NRF24L01+ and the RFM70 modules both directions OK.
The basic difference in driver is setting up the second register bank correctly (lots of magic 32 bit values with a handful of tweakable bits documented amongst them).
And the link that stopped me giving up: http://www.dioda.com.pl/forum/topics40/c-rfm70-24ghz-vt4261.htm
Apparently its also called the BK2421
Glad to hear it BTW - and now for my driver code at last
Are the RFM70 modules worth the hassle?
The eBay price for the Nordic modules is pretty darn good. All six of mine have been working fine.
I think the RFM70's would have be very inexpensive to be worth the bother.
Does this mean the RFM70 modules can communicate with the Nordic modules (and visa-versa)?
Duane
Mark,
Thanks for posting your code. I'll look at it sometime soon.
Is this the driver you're using to transmit audio?
Duane
The idea is linking two battery powered PA speakers wirelessly. Input is WM8783 stereo sigma/delta 24bit ADC with I2S interface -> prop -> local speaker (class D) and RF link to other identical unit for other stereo channel.
WM8783 is about $1 (and only 8 pin so easier to solder than many SM chips). Class D is 8bit PWM at 384kHz driven from sigma-delta 2 pole noise-shaping filter with ability to phase-lock to the incoming data rate (since the Xtals will be slightly different at tx and rx sides).
The bit I'm specially happy with is the automatic compensation in the PWM for the stretched and shrunk cycles (needed for locking to TX clock) in the noise-shaping feedback. There will be more info at some point.
Oh yes, and clock is 6.144MHz x 16
I really like XBEEs and their ease of use.
The only reason I decided to get the Nordics was the FOB module. Even thought it's range is limited, the small size and long battery life make it attractive for applicatiions like Duane's Panic Buttons...
I uploaded the demo with changes.
No tests yet involving reading any real data testing.
http://www.youtube.com/watch?v=oD9wJ84mOYg
I've just barely tried optimizing this object for speed (other than speeding up the base SPI object).
There's a delay in the "NordicBeta" file inside the method "TransmitString".
I don't recall if I tested if this delay is needed. If it is, it might be able to be reduced. 381 is the shortest delay that can be used with a Spin waitcnt. You could try a 381 cycle wait if commenting out the line doesn't work.
I've sure there are lots of other places this code could be optimized.
Also the demo uses a 24 byte payload and CRC. You'd want to use a 1 byte payload and turn off CRC.
Change:
To:
I believe that should turn of the error checking.
To reduce the payload, change:
To:
I'll look through the code and make sure there are other changes require for the small payload. I don't think there are any other changes needed.
The code to turn off error checking and to set the payload size is in the top object.
Use 1 instead of 3 as the value to load to register three (three bytes after the the first "configNew" byte).
Master
Slave
Are ther any updates to the code that i have missed ?
I am currently using the 110719a build.......
Here's a pinout diagram.
Here's a schematic.
You'll need to make sure the pin constants used in the demo match the pins used with your setup.
Yes, these devices use six I/O pins. I believe it's possible to use these without using the interrupt pin (IRQ). To use the modules without using the interrupt pin requires the module be read to determine if there's a new packet or not. The driver I posted requires the interrupt pin be used. It may be possible to combine the MOSI and MISO pins but I'm not sure. If it is possible to combine the data pins, it would require a change in the driver.
The Nordic nRF24L01+ requires a microcontroller on both the transmitting module and the receiving module in order to provide the necessary SPI communication protocol the device requires for communication. These can't be used like a XBee to pass a serial connection in transparent mode.
I've used these module for remote control in several projects. One example of using these as a remote was my remote controlled Roomba. To control the Roomba I used a PlayStation 2 controller connected to a Propeller Proto Board. This Propeller Proto Board also had a Nordic module attached to it. The Propeller would read the inputs from the PlayStation 2 controller and send packets with this input data to the Nordic module. The Nordic module would then pass the packet on to a second Nordic module connected to a Propeller QuickStart board on the Roomba. The Propeller on the QuickStart board would then convert the input data to appropriate messages which the Roomba would accept through its serial port.
In general, any project where I use these Nordic modules with a Propeller will require my using two Propeller in order to control the modules on both the transmitting and receiving devices. Since these are transceivers, they can both send and receive data. This allows your robot to send information back to the controller so it's possible to monitor the robot's battery power and other sensor input from your remote control unit.
An exception to this two Propeller configuration are times I've used one of SparkFun's Nordic fobs. These Nordic fobs use an ATTiny24 microcontroller to communicate with the Nordic chip. In most cases, when I've used a Nordic fob, the communication was one way with the fob sending button press information and not receiving any data back. (I was able to reprogram the ATTiny in order to both receive as well and send data but theres much the Nordic fob with the received information.) My mood enhancing LED project is an example of a project using Nordic modules where I only used one Propeller.
I've mentioned several times on the forum I have an improved driver for these transceivers. The improved code has most of the driver running in PASM. I just need to make a few minor changes to it and write a demo program for the driver before I post it. I'll make a point of posting some sort of demo and the improved driver within a week.
I’ve got a 10 pack of these I bought a few months ago. This info will come in handy when I get some time to test them out.
This is great, I'm excited to see your new demo code. I've always wanted to try doing wireless without an xBee and saw these (https://www.tindie.com/products/Propellerpowered/nrf24l01-wireless-module-24g/) which got me searching around for demo code which led me to here on the eve of new demo code!
Dave
My most recent attempt of writing demo code with the faster driver didn't work. I got out my logic analyzer but then I got busy doing something else. With enough of you reminding me to get the new demo out, I'll probably make time to work on it again soon.
The demo code posted in this thread should work in the meantime.
Make sure an check out post #1 of my index to an ebay link for a bunch of cheap nRF24L01+ modules and their pinouts.
I hope you don't mind, I'm replying to your PM here so I can give the same info to the rest of the forum.
So far, the most up to date demo is in post #9 of this thread. I have a faster all PASM version I worked on with T Chap but my attempt to make a demo for the PASM driver didn't work. I'll need to dig out my logic analyzer to get it working correctly. I do plan to work on the new driver in the near future.
One of my current projects is this robot remote. The remote uses a Nordic transceiver. Once I have the touchscreen interface working correctly with the SD card menu data, I'll want to use it to control a robot. I'm pretty sure I'll want to get the faster driver usable once I'm using the remote with a robot.
I think I saw a post in the Propeller C forum about a driver for these modules being finished in C. I haven't tried it myself. I think there are C libraries available to make networks with these modules. I'll probably investigate the C options once I get myself to make the transition to C. I used to like C but now I prefer writing programs in Spin much more than programming in C.
If any of you try the C driver for the nRF24L01+ modules I hope you let us know how you liked it.
My guess is I'm a couple of weeks away from having an upgraded Spin/PASM driver for these modules (though this has been my estimate for about a year now).
If any of you haven't tried these, you really ought to. They're awfully inexpensive and they're fast. You can get a dozen of these modules for about the same price as a XBee. They do require more pins and you need to send your data in packets. These things are so cheap you can add a transceiver to all your Propeller projects.