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
«1

Comments

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

    https://github.com/parallaxinc/propeller/tree/1c72a5e433b33dd3703178f71a57c45393ffcf95/libraries/community/p1/All/nRF24L01pDriver

    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 https://github.com/avsa242/spin-standard-library

    Or separately at https://github.com/avsa242/nrf24l01-spin

    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


    Cheers,
    Jesse
  • thanks all, i will give it a try, and will come back after mine results
    regards Rob
  • MAElektronikMAElektronik Posts: 5
    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

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

    Sure...those are in the spin-standard-library at: https://github.com/avsa242/spin-standard-library
    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,576
    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,362
    edited 2020-03-06 - 14:05:45
    Has anyone tried these?
    avsa242 wrote: »
    I have one I added to the spin-standard-library https://github.com/avsa242/spin-standard-library

    Or separately at https://github.com/avsa242/nrf24l01-spin

    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


    Cheers,
    Jesse
    Jim

    Edit
    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,362
    edited 2020-03-06 - 14:43:31
    Jesse,
    I am attempting to compile your programs under bst in Linux. However without all of the named obj, It won’t compile.
    Jim
    Edit
    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 https://github.com/avsa242/spin-standard-library
  • RS_JimRS_Jim Posts: 1,362
    edited 2020-03-07 - 13:35:47
    Jesse,
    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.
    Thanks,
    Jim
  • 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.

    Cheers,
    Jesse
  • 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
  • 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.

    Jesse
  • RS_JimRS_Jim Posts: 1,362
    edited 2020-03-10 - 15:41:00
    Jesse:
    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?
    Jim
    Edit
    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 #include...no 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
  • 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.

    Cheers,
    Jesse
  • 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. https://www.digikey.com/products/en/rf-if-and-rfid/rf-transceiver-modules/872?k=nrf24l01
    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: https://www.mouser.com/Embedded-Solutions/Wireless-RF-Modules/RF-Modules/_/N-6sri4?Keyword=nrf24l01&FS=True
    though not many in stock.
  • Jessie,
    I am attaching a file that captures what I see in minicom when the shockburst demo is running from the transmit side.. The .odt is a Libre Office text file. The received file, without interrupt, is in the .odt file attached to the interupts thread.
    Jim
  • avsa242 wrote: »
    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. https://www.digikey.com/products/en/rf-if-and-rfid/rf-transceiver-modules/872?k=nrf24l01
    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: https://www.mouser.com/Embedded-Solutions/Wireless-RF-Modules/RF-Modules/_/N-6sri4?Keyword=nrf24l01&FS=True
    though not many in stock.

    Wow, those modules are from DigiKey and Mouser are pretty expensive.

    SparkFun also sells nrf24l01+ modules.

    It's too bad there are so many counterfeits. It was nice to be able to use nrf24l01+ modules for about $2.

    I've been a fan of the nrf24l01+ modules for many years but I tend to use Bluetooth modules for most of my wireless projects these days.

    The HC-05 can be used as either a master or slave Bluetooth device. I also like the ESP-32 modules. The ESP-32 has Bluetooth, WiFi and a relatively powerful microconroller.

    Both the HC-05 and the ESP32 can communicate between modules (when configured appropriately). These modules can also be used to communicate with Android device. I've also used the HC-05 and ESP-32 devices to communicate with Bluetooth equipped PCs.

    I think the nrf24l01+ still has applications where fast wireless responses are important. I think Bluetooth has a lot of overhead not present in the nrf24l01+ chip so the nrf24l01+ chip can have a lower latency for time critical communication.

    I'm pretty sure the nrf24l01+ has the advantage of using less power than HC-05 and ESP-32 Bluetooth devices.
  • Yeah :-( it seems ymmv, though. I bought 3 of the unamplified ones you can find everywhere... Maybe back in 2015? Out of those three, I found one had a genuine looking chip, the other two counterfeit (but they all worked fine). Just this past year I bought two more, this time the ones that have the external amplifier chip w/external antenna. Both counterfeit. One of them worked ok, the other I couldn't get to communicate at all (OTA). That's what triggered me to research a bit and found out how bad the counterfeit problem is with these. The one that wouldn't work looked an absolute *mess* spectrally... Just wideband noise. Once I plopped on a real chip, it looked like a nice neat 1 or 2 MHz wide stream and it worked great.
    Agreed...I love these chips. They're not as configurable as a lot of other packet radio ICs (cc2500, sx12##, etc) but so much easier to get going. Still not many can match its speed either :smiley:
  • @Duane Degn my nRF24L01 driver, "tweaked", was adapted from your driver. Thanks. Yours was the only driver that worked. You're a brilliant guy. I could buy some IC's from Sparkfun except I'm not ready to invest in a reflow oven yet. In addition I'd have to do a couple of practice runs. I think another option is to look into fab houses that do SMT assembly. I wouldn't mind the extra expense to get a working module.
Sign In or Register to comment.