Replacing RS485 link with NRF24L01+

[o.hojvat]

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

[ovrebekk]

Hi Osvaldo

Do you upload multiple ACK payloads in the nRF24L01+ FIFO's at once, or only one at a time? 

What if you flush the TX FIFO on the PRX side, is this not enough to get ACK payloads to work again?

Since the buffer is a simple FIFO it doesn't handle the situation very well where you have multiple packets intended for different pipes. The following snippet from the datasheet describes this issue:

If the TX FIFO (PRX) contains more than one payload to a PTX, payloads are handled using the first in – first out principle. The TX FIFO (PRX) is blocked if all pending payloads are addressed to a PTX where the link is lost. In this case, the MCU can flush the TX FIFO (PRX) by using the FLUSH_TX command.

Best regards
Torbjørn

[o.hojvat]

Thank you for your reply

I upload information for one pipe in case 2) or 3 pipes in case 3)

I had readed this data sheet information and used flush Tx FIFO and Rx FIFO at PTX side but not yet at PRX side

I will add and test again.

I guess that flush will erase the 3 levels of FIFO

I need to use the POWER ON delay of uP in the PRX because some unwanted signals arises in SPI at power-up

Recently I change Logic Analyzer cables with 4 to PRX SPI and 4 to PTX SPI and have a capture after / later re-seting PRX

I will check this information and I will make a summary

As I add some FIFO sate reading, it may be usefull information about the problem.

Regards, Osvaldo

[ovrebekk]

Hi Osvaldo

Did you figure this out, since you marked your reply as verified answer, or do you still have some questions you need help with? 

Best regards
Torbjørn

[o.hojvat]

Thank you for your reply

As the ticket seems to be closed , I press Verify answer but I did not know for what function it is, sorry.

I read again carefully page 75 of data sheet and I gess I undestand well the matter.

Please confirm:

In PRX mode, Tx address is not used . PIPE0 works  similar to the others PIPES

In PRX mode,  only Tx address and PIPE0 address are used and must be the same

PIPE number is not defined at Tx - The number of PIPE are detected at PRX device because  the matching with this PIPE rxaddres matces wiith the received packet.

This PIPE number must be detected in STATUS_REG and used for ACK payload.

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

I can use any of the 6 PIPEs ok

The minimal instructions are:

PRX    write 3F to Reg02    -  all Rx PIPES    ON

PTX6      tx and PIPE0  default addr..   E7E7E7E7E7

In each PTX 1 to 5    set TXaddr and PIPE0  RX addr with same default values  from PIPES 1 to 5 of the PRX.    C2C2C2C2C2 - C2C2C2C2C3 -C2C2C2C2C4-C2C2C2C2C5-C2C2C2C2C6

It is working.  I expect have no errors when writing this  information.

In production parts I will not use default values and channels.

Some remaining problems that are in my program will be solved using 8 ch. logic analyzer and MPLAB 8.92  with PIC16F1936 and PIC16F1826.

Best Regards, Osvaldo

[ovrebekk]

Hi Osvaldo

o.hojvat said:

In PRX mode, Tx address is not used . PIPE0 works  similar to the others PIPES

Correct. You don't need to worry about the TX address in PRX mode, setting the RX addresses is sufficient. 

o.hojvat said:

In PRX mode,  only Tx address and PIPE0 address are used and must be the same

Assuming you mean in PTX mode, then yes. Only TX and pipe 0 addresses are used, and they both need to be set to the same address as the device you are transmitting to. 

o.hojvat said:

PIPE number is not defined at Tx - The number of PIPE are detected at PRX device because  the matching with this PIPE rxaddres matces wiith the received packet.

Correct. You always use pipe 0 in PTX mode, but in PRX mode you can receive on any of the enabled pipes. 

o.hojvat said:

This PIPE number must be detected in STATUS_REG and used for ACK payload.

The RX_P_NO field of the STATUS register will contain the pipe number of the oldest payload in the FIFO. If you only have one packet in the FIFO it will be the pipe number of the previously received packet. 

o.hojvat said:

In production parts I will not use default values and channels.

Good

It is recommended to use a randomized address, and ensure that you have a certain number of bit shifts in the address (avoid several bytes of 0x00 or 0xFF). 

Best regards
Torbjørn

[o.hojvat]

Hi  Torbjørn

Thank you for yor reply.

I will do some testing about distances for RF link

Also I will add retrasmiting n times.

If I may need some aditional help I will open a new ticket.

Best Regards, Osvaldo

[ovrebekk]

Hi Osvaldo

Great, good luck finalizing your project

Best regards
Torbjørn