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

[o.hojvat]

PTX   SPI

PRX  (MIRF)  SPI

Timers sincronizing oscillating and corrected.pdfTimers sincronizing oscillating and corrected.pdf

[ovrebekk]

Hi Osvaldo

Thanks for sharing the PDF, I can see it now.

What would you say is the amplitude of the oscillations, in time? 

I am guessing that the problem with oscillations stem from the fact that you are not properly correcting for delay caused by the transfer of time from the PTX to the PRX. 

There are several sources of delay to take into account. First the delay caused by the readout of the time and the assembly of the payload (relatively small I assume), then the delay introduced by the upload of the packet and the packet transmission, and then the delay caused by the readout and processing of the payload on the RX side. 

The result of the delay is that the real PTX timing will be further along than the number implies, and you need to add some constant factor to the PTX timestamp before you do any further processing. 

If the oscillations are consistent you can probably find this value just by experimentation. Start with 1 and work your way upwards. If your time resolution is 0.5ms I expect this value should be quite small, maybe somewhere in the 1-5 range. 

Best regards
Torbjørn

[o.hojvat]

Hi Torbjørn

Please note that  syncronizing are working OK as shown in captures 2 and 3

The correct procedure is to wait  the second ACK payload before  the PTX counter-timer update.

-----------------------------------------------------------------------

I have done a lot of work adding the PTX test  program with the existing  Handeld control one

All the program lines related with the USART was deleted to make room for the new lines for NRF

My actual question is about table 14 , page 20

It stated Power On reset 1ms to 100ms

I guess:

 --- It is needed waiting 100ms before any access to the  NRF  SPI after applied power supply to theNRF

 --- After this time It may be sent all NRF settitngs and an aditional 4.5 ms  is needed for  Power Down -  Standby mode.  ( Write command and status registers).

 I am using the usual 8 pins board  with NR24L01P , 16M cristal and printed antena

Please comment about  this two matters

I must consider that PTX side  may be powered after or before  than the PRX  and this times will be important.

Best Regards, Osvaldo

[ovrebekk]

Hi Osvaldo

o.hojvat said:

 --- It is needed waiting 100ms before any access to the  NRF  SPI after applied power supply to theNRF

 --- After this time It may be sent all NRF settitngs and an aditional 4.5 ms  is needed for  Power Down -  Standby mode.  ( Write command and status registers).

Correct. When the supply voltage to the nRF24L01+ is provided for the first time you have to wait at least 100ms after the supply voltage has stabilized before sending any commands to the nRF. 

The delay between power down and standby comes in addition to this, but depending on the crystal used the delay could be shorter than 4.5ms as detailed in the table. 

Best regards
Torbjørn

[o.hojvat]

Hi Torbjørn

My NRF project is behind schedule but close to completion.

I now need to enable and use the 6 PIPES and I want to confirm some points.

In each PTX I must choose a PIPE and set with the same value, TXaddress, RX address of pipe0 and also the RX address of the chosen PIPE, if it is not PIPE0
This is what the example on page 75 with PIPE5 explains.

It is necessary to set the corresponding bit of the reg. 02 EN_RXADDR ?

RXaddress of PIPE1 must be set in all cases, because it contains the MSBs of PIPES 2 to 5
as explained on page 60
.................................................. ..........

In the PRX  I understand that I must set all the bits of reg 02, since I want to enable 6 PTX, each with its PIPE
Additionally, for each PIPE  I must set the same RXaddress that I put in the corresponding PTX
__________________________________________________________________

One of the drawbacks to using assembler with Microchip microprocesors is that it can only use MPLABX version 5.35 or earlier.
Any more or less new microprocessor must be verified that it is included in the assembler of that version.
If it is new enough not to be in previous versions, the debug does not work well due to errors not yet resolved.
This forces me to have to make everything work with two models that are different in their internal registers, the more flexible pic16F18855 for production and the pic16F1936, easier to use for debugging.

Best Regards, Osvaldo