Replacing RS485 link with NRF24L01+

As Pevious ticket: Using NRF24L01+ with pure assembler programing becomes very long,  I open a new one as Torbjørn suggested

This is a description about what I have doing in my proyect and at the end there are some questions.

.......................................................................................

My application has a Central unit connected to several Handheld controllers  with RS485 cable.
Bit rate is 62.500 , 9bits

The central unit is sending in secuence a Callbyte for each Handheld address (from1 to 31) and wait about 100 us for a reply, before it will send a Callbyte to the following address
In this cable system a Handheld only changes to Tx mode after a Callbyte with his address is received.

The Central unit has connected two rails for Model Electric trains. (Ferromedelism)

I will add an interfase  with a uP and a NRF24L04p that will handle the RF link and connected to the Central by 485 cable
No modifications at the Central unit hadware or software willbemade.

The the handheld will be re-designated by adding one NRF24L01+, removing the 485 part and modifying the program as needed.

Using the usual star configuration , the intefase will use PRX mode and may be up to 6 handheldwill using the NRF part in PTX mode.

All the 485 packets are 9 bits but the MSB is only for the information about if the byte is an Address (= 1) or a DATA  (= 0)

Only the Central may send Address and Data bytes.   Handheld units only send DATA bytes

In my aproach the interfase unit decodes only the Callbytes and the NRF will need to handle only 8 bits.

There are 3 types of Callbytes:

1) Callbytes with no more bytes in the packet, that allows the matching address Handheld to

send a packet to the central

2) Callbytes with 1 or more DATA with information requested before by one specific handheld.

The regarding address will be in the Callbyte

3) Broadcast Callbytes: The packet will have information that must be sent to all the Handhelds units.

The program for the interfase unit has 6 RX buffers and 6 TX buffers for the USART and 485 , one pair for each PIPE

Data send from a Handheld by NRF is received by interfase and stored in the TX buffer , for case 1)

Data received by USART (from RS485) is stored in Rx buffer and loaded in NRF TXFIFO  for sending it as an ACK PAYLOAD

I will use some time slots system (not defined yet) for each PTX for avoid collitions and to get back  information when available

------------------------- Some quetions here ---------------------

At the moment the matter  1) is working OK   

Each information sent from Handheld is received at interfase side and sent by RS485 when type 1) Callbyte arrives.

For cases 2) and 3)  ,  information from Handheld is received but ACK PAYLOAD is sent some times yes  other times no

uP reset do not helps .  If the NRF supply is disconected and reconected, ACK PAYLOAD begins to work

It may be  working in all the PTX packets or alternately one yes one not.

I have a low cost , 8 channels Logic Analizer and I will investigate this problem by reading STATUS and FIFO_STATUS

I guess the problem is at PRX side, not sending ACK, but I am no sure.

Please send any suggestion about where it may be the problem.

Also how to diferenciate  which side is not working well.

Best Regards, Osvaldo Hojvat

  • Hi Torbjørn

    My proyect is neart o be  finished. 

    I did an important change in operating mode

    Original way with 1 Rx and 6 Tx becomed to complicated for debug

    In logic analizer there are two packets to be analized for each message.

    Two consecutive TX to same device works well with time sincronized  schema but when usind more than one devices and many sucesive messages some problems arises

    So I move to the same configuration of my RS 485 system

    One master (PTX) sends a Call with individual number for each PRX device (authorizing a reply) and when no reply or ending messages with this PRX, it sends a Call for the following device.

    It is much easyer to analize and debug. There is no complicated to change Address for each new trasmition ( only LSB byte).

    It becomes very simple sending a broadcast message ( the same for all PRX):

    Only matter:  it needs to be send with no ACK option. 

    I for this purpose y stated the same PIPE0 addr. for all the PRX.   5A 5A 3B

    for PIPE1  5A 5A A1    5A 5A B1   -----   5A 5A F1      Allows individual access to each PRX

    for PIPE2  5A 5A A2    5A 5A B2   -----   5A 5A F1      also  individual messages allowed

    -------------------- I have some last questions -----------------

    1) I can´t find in data sheet the max. load (mA) for the IRQ output.
    please give me this information

    2) From NRF2401 data sheet, instruction E2 ( FLUSH Rx FIFO ):  Should not be used when ACK be transmited and not completed ( for a PRX device )
    ¿ I guess that the ack payload is stored in RX FIFO ?

    I use this secuence at PRX side (payload length from 2 to 7 bytes, ussualy)
    - load ACK payload
    - when IRQ arises for a RX packet arrived, I read it and after that I do E1 and E2 commands
    and erase STATUS flags.
    - If there is some message to be load as ACK payload , I do it
    SPI uses 4MHz so reading packet and flushes may occur meanwhile the ack and payload be
    trasmited
    So I must use some delay about 300us from IRQ fall to the flush commands

    I know that may be not need of use as frequently E1 and E2 commands.

    I will study this question later.


    3) I move from 2MHz rate to 1 MHz rate and got an better distance with no errors , about 7 m
    changes to about 10 m
    I use the smaller usually available 15mm x 30mm board.
    I also tested with the board with amplifiers and antena at PTX side but have not more distance, it seems to be worst.
    I guess the program needs no change
    Using the amplfied board with antena at two sides, there is an improved working distance.

    Thank you in advanced for your reply

    Best Regard, Osvaldo Hojvat

  • Hello,

    We do not really provide technical support for the nRF24-series anymore, the device is 15+ years, and we have provided other nRF series afterwards that provide better solutions.

    You should not draw any specific current from the IRQ output, if you need a number I would simply say max 10uA. 

    As a PRX, after receiving a packet, make sure that you wait a period of time to ensure the ack is sent before you try to reconfigure the radio or change operation or similiar on the PRX.

    Kenneth

  • Thank you for your reply

    At the moment I have a lot of parts of my proyect working ok , with PTX sending  packets with ack with payload and also with only ack received 

    At PTX I have enbled IRQ for RX_DR and also for TX_SD , for the case of ACK with no payload.

    PRX dvice remains in PRX mode all the time.   Only TX for the automatic ack  

    One kind of packet sent from PTX  has ack received after 400us from the tx  - OK

    At PRX  there is the ack by RX_RD at 200us but  many times IT IS NOT PRESENT

    There are not SPI activity at this time.

    So I can see in logic analyzer the IRQ at PTX but not at PRX side for the same packet (????)

    Followinq packet may be normal.

    Please give any suggestion about the matter 

    Best  Regards, Osvaldo

  • Hello,

    If you haven't already, do check out the application notes (with code example) on how to use the nRF24L with ack payload for comparison:

    https://infocenter.nordicsemi.com/topic/struct_appnotes/struct/appnotes_nan24-12.html 

    Kenneth

Related