B4R Library rRF24xt ... an extended library for nRF24L01+ radio modules

Discussion in 'B4R Libraries' started by Starchild, Sep 25, 2017.

  1. Starchild

    Starchild Active Member Licensed User

    I wanted to be able to send a single broadcast transmission to several receivers and change the RF channels. No handshakes or acknowledges. To do this I needed more detailed set up and control of the nRF24L01+ modules.

    I started with the rRF24 library published by Erel. I have revealed several more of the functions available from the RF24 GitHub project through to the B4R IDE including access to the full 5 byte address for Rx/Tx packets. The included XML also contains comprehensive information for all functions made available through the pop-ups in the IDE.

    Probably, one of the most useful functions for me was "PrintDetails()" which reads the current settings from the registers in the RF24 module itself. A great tool to verify SPI communications and get things going.

    I did my testing on the ESP8266 based WEMOS-D1 and NODEMCU modules. I don't have regular Arduino hardware. It would be good if other users could post confirmations when using this library on other mcu hardware.

    To show backward compatability and the available new functions, the example below uses my rRF24xt library to communicate with devices programmed with the original rRF24 library example provided by Erel.

    You may need to play around with this example a bit as although I wrote it, I don't have any MEGA or UNO hardware, so I haven't tested this specific example.

    Code:
    #Region Project Attributes
        
    #AutoFlushLogs: True
        
    #CheckArrayBounds: True
        
    #StackBufferSize: 300
    #End Region
     
    Sub Process_Globals
        
    Public Serial1 As Serial
        
    Private rf24 As RF24xt
        
    Private const MEGA = 1, UNO = 2 As long
        
    Private raf As RandomAccessFile
        
    Private ep As Wemos_D1_R2_Pins
    End Sub
     
    Private Sub AppStart
        Serial1.Initialize(
    115200)
        
    Log("AppStart")
        rf24.Initialize(ep.D4, ep.D8, 
    "rf24_NewData")
        rf24.SetChannel(
    76)
        rf24.SetGroupID(
    0xAB)   'high byte of address (for both TX and RX)
        rf24.SetDataRate(1)   '0=250kbs, 1=1Mbs, 2=2Mbs
        rf24.UseAutoAck(True)
        rf24.SetRetries(
    15,15)  'NB: only required if UseAutoAck(True)
        rf24.UseCRC(False)
        rf24.SetPower(
    0)    'low Tx power
         '0xABCDABCD00 is the address used by original RF24 library (plus 1 or 2)
        rf24.OpenReadingPipe(0xCDABCD00 + UNO)
        rf24.OpenWritingPipe(
    0xCDABCD00 + MEGA)
        rf24.Sleep(
    False)   'NB: Sleep(True) .. power-down RF24 module
     
        rf24.PrintDetails   
    'read the registers in the RF24 module and output to log
    End Sub
     
    Sub rf24_NewData (Data() As Byte)
        raf.Initialize(Data, 
    True)
        
    Log("UNO Millis: ", raf.ReadULong32(raf.CurrentPosition))
    End Sub
    This example requires inclusion of libraries; rCore, rESP8266extras, rRandomAccessFile, rRF24xt

    Here is my rRF24xt library for download.

    Now updated to v1.02
    See postings below for details on changes.
     

    Attached Files:

    Last edited: Oct 17, 2017
  2. Starchild

    Starchild Active Member Licensed User

    Updated my rRF24xt library to v1.02
    Available for download from the original top post.

    Changes:

    When used with Auto Acknowledgements turned off it is a common practise to send a data packet multiple times to assure its delivery. This is a Brute Force method of using the nRF24.
    Unfortunately, when the receiving MCU is momentarily busy (not polling for its incoming events), eg. say executing a Delay() function, it is possible for the hardware receiver in the nRF24 to be over-run with too many data packets for its buffers. In my case this was causing the occasional LOCKUP of the data receiver, no longer able to receive further data packets.

    To help with the management of this situation the Write Function has been altered.
    If NO auto acknowledgements mode is being used, then the data receiver is now reset on completion of the packet transmission to clear any pending over-run.
    NB: the Write function still works as before when Auto Acknowledgement mode is Enabled.

    and also added a new functions:
    ResetRx ... which can be used following any holdup in mainline event handling, say after a Delay() is executed.
    SetPower() ... allows the Tx power level to be set. (I have damaged modules next to each other testing at full power on the bench, can now use low power)
     
  3. Michael Sergio

    Michael Sergio Member Licensed User

Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice