nRF24L01(+) driver / demo available for propeller 1?

Hi, i have some Nordic nRF24L01+ wireless modules and struggle to get it work with a simple driver and demo.
In the OBEX there are 2 drivers available, one is complex (Erlend 2015), and the simple one from Nikita Kareev (nRF24L01) is not working with the demo (receiver only).

Are there new or update available to play and learn how to setup those modules, in the forum?

Regards, Rob


  • AwesomeCronkAwesomeCronk Posts: 925
    edited 2020-01-31 - 13:07:58
    Here is this fancy kit from the github obex:

    Comes with a nice multifunctional demo. I can only say that I have not yet gotten to test it.
  • I have one I added to the spin-standard-library

    Or separately at

    There are two separate demo apps, a TX and RX side. As with any unfamiliar device (radios especially), I'd recommend leaving as many settings at the default to make sure the setup works, first. If you try it, please let me know your experience with it

  • thanks all, i will give it a try, and will come back after mine results
    regards Rob
  • MAElektronikMAElektronik Posts: 4
    edited 2020-02-02 - 18:37:48
    Note that the (Erland) >corrected Erlend< code on OBEX has a couple of bugs.. If I remember correct, it had problems with setup of the 5byte unique ID when using multible modules. Also using two way communication Auto ACK_W_Payload had issues. Other thing I had to change was SPI from SPIN to PASM for fast communication.
  • Thanks MAElektronik, I had already read something like that on the forum.
  • Hi Jesse (avsa242): in jour demo's (NRF24L01-RXDemoWithAA, NRF24L01-TXDemoWithAA) you use 'special' objects, will you share this?
    or can i simple replace it to 'standard' objects

    ser : "com.serial.terminal.ansi"
    cfg : "core.con.boardcfg.flip"
    io : "io"
    time : "time"
    int : "string.integer"
  • avsa242avsa242 Posts: 196
    edited 2020-01-31 - 22:01:25
    @Rob v.d. berg

    Sure...those are in the spin-standard-library at:
    The same demos are available in that repository. I'd recommend downloading that entire repository, and ensuring the library/ folder is added to your spin compiler's path.
    Note that I've tested these using OpenSpin. I'm not sure if the Propeller Tool will build these. I don't think I used any special features of the compiler (like the preprocessor) so it may be fine.

    EDIT: Also, I only just now noticed this, but in your thread title you placed the + in parentheses; it just made me think you might want a driver that supports both. If you have the + model, this should work fine, but there was actually a previous model by Nordic that didn't have the +; I think I remember reading that these weren't (fully?) register compatible with the + model.
  • Jesse, I have the + version, so it should work
  • lardomlardom Posts: 1,573
    edited 2020-02-01 - 14:10:54
    I have a couple of objects that I use to test new modules. I had bogus modules that would not allow me to send multiple bytes in a single packet but the code does work.
    EDIT: I didn't clean it up because I only use it to make sure the modules can communicate.
  • Hi, Larry awesome!, exactly what I was looking for to start simple, and learn how it works.

    thank you
  • RS_JimRS_Jim Posts: 1,338
    edited 2020-03-06 - 14:05:45
    Has anyone tried these?
    avsa242 wrote: »
    I have one I added to the spin-standard-library

    Or separately at

    There are two separate demo apps, a TX and RX side. As with any unfamiliar device (radios especially), I'd recommend leaving as many settings at the default to make sure the setup works, first. If you try it, please let me know your experience with it


    I just downloaded these from dropbox and was disappointed. When Jesse archived these he did not include all of the obj files that he used. He has a serial object that is not standard, an ME(?) obj, and I think it was a string handler obj. I was hoping to compile and test his nrfl01 on a couple of my non flip Prop boards.
  • Hi Jim,

    I've chatted with Rob a few times and he has used them. I've since added a few Propeller Tool/PST compatible versions of the demos (I develop my drivers/tools primarily for OpenSpin and ANSI-compatible terminals as for me it's the best solution available in Linux for the P1. I can convert them to PropTool on demand)
  • RS_JimRS_Jim Posts: 1,338
    edited 2020-03-06 - 14:43:31
    I am attempting to compile your programs under bst in Linux. However without all of the named obj, It won’t compile.
    I am using quickstart boards and I probably can make a compatible config file. but still not sure about your serial and string obj’s.
  • Jim,

    The best way is to download the spin-standard-library. It has all the needed dependencies.
    It's at
  • RS_JimRS_Jim Posts: 1,338
    edited 2020-03-07 - 13:35:47
    I got it this AM and unzipped it. Great, has everything I was missing. Can’t wait to try it. May be a few days as I have to work the next 3.
  • Jim,

    No problem... I actively work on this and other drivers, as well as that fork of the spin-standard-library and I have very few (verified, at least) people that I know of that use it, so I would be greatly appreciative to hear of your experience with it.

  • Jim,

    Here's another driver option.

    It took me a while to find the link since the forum links have been broken. I haven't used these modules in a while so I have no idea how my driver compares with others available.
  • Jesse,
    I finally got things set up last night to compile correctly in Linux.. I throw an error about line 56 that reads: FLASH LED (#LED,100). Do I need to write a routine that flashes an LED for 100 times?
  • Jim,
    That method should be provided by the #include "lib.utility.spin" line... I'm not positive, as I don't use it personally, but I think bstc has a preprocessor, so this should've happened automatically. If not for some reason, the contents of that file can simply be pasted in to the demo (it's just that one method right now, anyway, IIRC). All it does is flash an LED with the 2nd param as the delay, in ms - just a debugging/status aid.

  • RS_JimRS_Jim Posts: 1,338
    edited 2020-03-10 - 15:41:00
    I spent 2 hours last night attempting to get your RFL01 demo to compile with no success. I have resolved all the errors I have encountered so far until this one:
    ser.Hexdump(@_fifo, 0, _payloadlen, _payloadlen, 0, 9)
    I cannot find this anywhere in the library. bst is not pre-processing some things correctly so have had to manually fix them.
    what did you compile this with originally?
    Also there’s a #include about twwidgets or something like that that goes unfound.
  • Hi Jim,
    Sorry you're having trouble with it. I've uploaded -PST variants of the demos to the demo folder. Those should work with the Propeller Tool and its serial terminal (they should also work work bst).

    I use OpenSpin for most everything on the P1 since Parallax endorsed its development. I'm guessing bst doesn't have a preprocessor or doesn't use standard syntax.
    With little exception, I only use special ifdefs or anything.
    That method is provided by lib.termwidgets.spin.
    Let me know if these work for you.
  • Hi Jesse,
    What an aid it is to RTFM on the compiler. The include function is not setup in bst so there is where all my headaches were coming from. I did find it ironic that all of the compile time issues came from the screen support. When I pasted the necessary files into the top file in place of the # references, all went well and I got the basic demos to work. Thanks for your patience and Handholding thru this process. Next to get the AA demos running, but knowing what I know now, that should be a piece of cake. I am not at my computer Right now is there a function available that can be put into a program that gets the RFL initialized?
    Again thanks for the help I will update you as I go along.
  • Jim,
    No problem. I stand by the code so if you have issues I'd like to get them resolved. I'm not at mine either but IIRC, most if not all of the settings I used in both demos are default settings; I just explicitly set them to give an idea of the driver's programming interface, should one want to change something. That said, I think it would make sense to add DefaultRX and DefaultTX methods to the driver; thanks for the idea.

  • Can anyone recommend a source of authentic nRF24L01 modules?
  • I've had a hard time with the usual sources (e.g., Amazon)...mostly counterfeit nRF's mounted on the boards. Didn't know of their existence until I ran into serious problems trying to get one of them I bought last year working at all. Bought some of the chips themselves off DigiKey (all of which appeared to be authentic) and replaced the ones on the board and they all worked perfectly fine.

    I see DK has only a couple modules they still stock, made by Talon Communications, inc.
    They're definitely pricier than a lot of the modules that can be found everywhere on the net but I think it's that much more likely they're the real ones. The footprint isn't quite the same as most modules, though.

    *** Actually, looks like Mouser has some made by Nordic themselves:
    though not many in stock.
Sign In or Register to comment.