Replacing RS485 link with NRF24L01+

RE: Replacing RS485 link with NRF24L01+

Kenneth — Mon, 19 Aug 2024 09:37:18 GMT

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

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Fri, 16 Aug 2024 14:56:11 GMT

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

RE: Replacing RS485 link with NRF24L01+

Kenneth — Tue, 13 Aug 2024 13:53:47 GMT

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

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Fri, 26 Jul 2024 20:23:28 GMT

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

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Tue, 30 Apr 2024 07:56:32 GMT

Hi Osvaldo

Great, good luck finalizing your project 🙂

Best regards
Torbjørn

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Mon, 29 Apr 2024 16:11:59 GMT

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

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Sat, 27 Apr 2024 08:53:12 GMT

Hi Osvaldo

[quote user="o.hojvat"]In PRX mode, Tx address is not used . PIPE0 works similar to the others PIPES[/quote]

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

[quote user="o.hojvat"]In PRX mode, only Tx address and PIPE0 address are used and must be the same[/quote]

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.

[quote user="o.hojvat"]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.[/quote]

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

[quote user="o.hojvat"]This PIPE number must be detected in STATUS_REG and used for ACK payload.[/quote]

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.

[quote user="o.hojvat"]In production parts I will not use default values and channels.[/quote]

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

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Thu, 25 Apr 2024 23:11:38 GMT

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

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Thu, 25 Apr 2024 08:49:19 GMT

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

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Tue, 23 Apr 2024 04:22:29 GMT

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

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Mon, 31 Jul 2023 11:31:44 GMT

Hi Osvaldo

[quote user="o.hojvat"]

--- 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).

[/quote]

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

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Wed, 26 Jul 2023 16:07:55 GMT

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

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Mon, 10 Jul 2023 07:38:19 GMT

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

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Fri, 07 Jul 2023 03:37:17 GMT

PTX SPI

PRX (MIRF) SPI

devzone.nordicsemi.com/.../Timers-sincronizing-oscillating-and-corrected.pdf devzone.nordicsemi.com/.../Timers-sincronizing-oscillating-and-corrected.pdf

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Thu, 06 Jul 2023 06:49:42 GMT

Hi Osvaldo

You should be able to attach any file by drag dropping it onto the message reply window.

The window should turn gray when you drag a file over it, and then you can release it.

Best regards
Torbjørn

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Wed, 05 Jul 2023 17:24:08 GMT

Please tell me how to attach a PDF file

I am using WindowsXP but I can move to a W10 PC

Regards, Osvaldo

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Wed, 05 Jul 2023 16:39:08 GMT

Hi Torbjørn

The correct procedure to synchronize the timer of the PTX is the following;

PTX sends a packet

PRX responds with ACK and payload and at that moment loads the value of its timer as payload

PTX receives ACK but discards the possible payload because it does not have the information recently loaded.

PTX sends a second packet 128ms after the first one

PRX responds with ACK and in the payload it has the timer information. This information corresponds to 128 ms previous, but at that time both timers overflow and return to the same value (+/- 0.5ms in the case of PRX)

PRX gets an ACK payload and place the value received in its timer -> both are synchronized.

It can be repeated but always transmitting two packets and using the ack payload of the second.

The error was in modifying the time between the two packets sent by PTX, by updating the PTX timer when receiving the first ack.
If the correction was 0 or almost 0, the oscillation was not noticed.

I will send images in next post

Best Regads, Osvaldo

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Wed, 05 Jul 2023 16:12:38 GMT

Hi Osvaldo

[quote user="o.hojvat"] Every 128ms PTX sends a packet that starts with F5 and then the value of its PTXtimer, which will always be the same at this moment.

PRX recognizes F5 code and only loads the value of the difference (PRXtimer - PTXtimer) as ACK payload
.
PTX receives it and adds that value to the PTX timer with which it remains synchronized.[/quote]

You mean to say you send two packets from the PTX?

One with the F5 command and a second one to pick up the ACK payload?

[quote user="o.hojvat"]I used transmit the difference in case there is a delay due to ret-ransmissions o other, but I can measure and correct that.[/quote]

You can disable retransmission if you want, and do it manually. If you don't get an ACK just restart the process, and use an updated PTXtimer value to ensure that the timing is accurate.

[quote user="o.hojvat"]This way it seems to work OK, but a few times it initiates and remains oscillating indefinitely.[/quote]

Can you provide more details regarding this oscillation? You mean the timing keeps oscillating between different offsets?

Getting a trace of the SPI bus of hte PTX and PRX makes sense. Then you might be able to spot what the reason for the problem is. For instance it might be caused by packet loss somewhere, which should be easy to spot from the trace.

[quote user="o.hojvat"] I will send the result when I have it solved.[/quote]

Sounds like a plan. Just get back to me when you have the traces.

Best regards
Torbjørn

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Tue, 04 Jul 2023 20:43:33 GMT

Hi Torbjørn

Thank you very much for your always kind answer. I will take into account all your suggestions.

Now I'm trying to get the synchronization of the PTX timer with the PRX timer working, using the periodic transmission which is necessary anyway.

Every 128ms PTX sends a packet that starts with F5 and then the value of its PTXtimer, which will always be the same at this moment.

PRX recognizes F5 code and only loads the value of the difference (PRXtimer - PTXtimer) as ACK payload
.
PTX receives it and adds that value to the PTX timer with which it remains synchronized.

The total time is 420us and the timers advance every 500us, so there is no problem that they change during the process.

I used transmit the difference in case there is a delay due to ret-ransmissions o other, but I can measure and correct that.

This way it seems to work OK, but a few times it initiates and remains oscillating indefinitely.

It is not easy to start the fault. It is fixed when the PTX sends a normal use packet inserted and the next one with F5 does not update.

As it is a feedback system and with delays, I tried to correct using half the difference and the oscillation is damped in 1 to 2 seconds.

This is acceptable but I want to understand how it works and correct it properly.

Now I believe that it should not be corrected in all packets.

I have to analyze well the capture of the 8 channels of the logic analyzer, 4 of the SPI of the PTX and 4 of the PRX.

I will send the result when I have it solved.

Best Regards, Osvaldo

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Tue, 04 Jul 2023 06:45:55 GMT

Hi Osvaldo

[quote user="o.hojvat"] What happens if the upload is done in the first 20 us after the IRQ goes low at PRX side ?[/quote]

In order for the packet upload to be included in the ACK the entire packet upload procedure has to complete before the IRQ goes low as a result of an incoming packet. If the packet upload completes after the IRQ has gone low it is already too late, and the packet will only be returned on the next packet from the PTX.

[quote user="o.hojvat"]The RF part takes 300 us to go to TX (PLL lock) and may be at the beginning of this time the payload can be loaded in the TX FIFO, to be transmitted next .[/quote]

Unfortunately you can not upload a packet while the TX is settling and have it included immediately. If you check the state diagram in chapter 7.5.2 you will see that the FIFO status is checked before enabling the radio in TX mode. If there are no packets in the TX FIFO the radio will go back to RX mode immediately:

Also, please note that TX settling time is 130us, not 300us.

[quote user="o.hojvat"]There is a disappointing problem: the system works but it depends on the order of PRX or PTX started first.

The system may be locked because tx FIFO or Rx FIFO full or Max retry number.[/quote]

If you get into problems when starting the PRX first you could put some code on the PRX side to avoid uploading any ACK payloads until at least one packet is received from the PTX. Then you know that you won't fill the TX FIFO on the PRX side until the PTX is ready to pick them up.

[quote user="o.hojvat"]The system may be locked because tx FIFO or Rx FIFO full or Max retry number.

Since I have a Tx from PTx each 128ms , I can do some FLUSH for FIFOS and clear STATUS flags on PRX and/or PTX sides if there are no packets for example in 200ms.[/quote]

Yes, you can use a timeout on the PRX side to detect situations where the PTX is not sending any data for a long time, and flush the FIFO's accordingly.

If nothing is received for a certain amount of time you might want to just flush the FIFO and immediately upload a new, updated ACK payload. As long as nothing is received simply repeat this procedure. If nothing is received for a very long time you might consider using a longer timeout value, until the PTX starts responding again.

Best regards
Torbjørn

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Sun, 02 Jul 2023 21:25:49 GMT

Hi Torbjørn

I have many parts of my project working as expected.

There is a disappointing problem: the system works but it depends on the order of PRX or PTX started first.

The system may be locked because tx FIFO or Rx FIFO full or Max retry number.

Since I have a Tx from PTx each 128ms , I can do some FLUSH for FIFOS and clear STATUS flags on PRX and/or PTX sides if there are no packets for example in 200ms.

I am asking if there are some recommendations that are usual for this matter.

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

By the way I have one idea to share

About SPI speed, working with PIC18F26Q10 I have used 16 MHZ sending data to a flash memory and 5MHz when receiving data. This meets time specifications for both parts and works fine.

It is usefull in my aplication because I send 4bytes for command and address and get 4 data bytes in each access for reading.

For NRF I used 4MHz by the moment..

Best Regards

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Fri, 30 Jun 2023 02:04:54 GMT

I will try to explain myself better:

I know that the ack payload must be loaded before receiving the packet in the PRX, so that it goes transmitted together with the next ACK.

In the data sheet I can't find information about time margins regarding the IRQ go to low level and the upload timming

What happens if the upload is done in the first 20 us after the IRQ goes low at PRX side ?

The RF part takes 300 us to go to TX (PLL lock) and may be at the beginning of this time the payload can be loaded in the TX FIFO, to be transmitted next .

I can do some tests, but perhaps this matter has already been analyzed

Best Regards, Osvaldo Hojvat

RE: Replacing RS485 link with NRF24L01+

ovrebekk — Thu, 29 Jun 2023 11:02:36 GMT

Hi Osvaldo

You should be able to buffer regular payloads (PTX) or ACK payloads (PRX) independently of what the radio is currently doing. As an example, it is fine to upload multiple payloads while the radio is busy ramping up.

[quote user="o.hojvat"]For SPI it is posible to do an upload for the ack payload (6 byte packet) in about 20 us, inmediately IRQ of PRX goes low.[/quote]

You mean the IRQ goes low immediately after uploading an ACK payload?
This sounds odd.

On the PRX side you should not expect an interrupt unless you receive a packet from the PTX, uploading an ACK payload on the PRX side will have no influence on when the PTX sends you data.

Best regards
Torbjørn

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Thu, 29 Jun 2023 04:09:53 GMT

There is a time of about 130us for PRX changes from Rx to Tx

Meanwhile:

For SPI it is posible to do an upload for the ack payload (6 byte packet) in about 20 us, inmediately IRQ of PRX goes low.

But may it works ?

Regards, Osvaldo

RE: Replacing RS485 link with NRF24L01+

o.hojvat — Wed, 28 Jun 2023 17:42:10 GMT

I have measured some delay times and found that sending a packet from PTX and get the reply available again at PRX takes about 2,5ms in total

This includes NRF tx -rx times to interfase and USART times and reply from central unit by 485 cable

In my future time division schema , I guess 20ms for each PTX, so it will be 120ms from each PTX trasmition to the following for the ack payload of previus packet.

In the 20ms slot PTX can send a packet and after after 2,5 ms the reply will upload as ACK payload at PRX

My last idea is at by example 5ms from the first packet sent, the PTX will send a second special packet one byte length, only to geting the ACK PAYLOAD information.

This byte will have a special code ("F0" by example) that tells PRX it is not to be send by the USART (as it is done for all the usual packets)

In this way the reply will be at PRX in the same 20ms time slot

This one byte packet will be send all the lime to keep syncronized the PTx

Aditionally the most important advantage is to avoid TXFIFO full in PRX

The case 3) broadcast packet, it will be loaded in the 6 microprocesor buffers (in PRX = interfase) an loaded to the PRX TxFIFO one in each slot time , a little before the expected one byte repetitive packet.

So I will begin using all 6 address PIPES and time slot matter, before include the short test program in the complete handheld one.

Until now I never change the default address in NRF

The 6 USART address matter was make an well tested . Handheld with 485 cable with several different address was used for this purpose,

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

The problem with wrong address arises because I used a normal handheld with cable to generate and receive USART signals in the debug.

I was not the problem because an error remaining in the interfase (with the PRX) program but it was an error or confusion in the tests..

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

With the repetitive special packet it may be more simple to identificate PIPES not in use or out of range PTX

Best Regards, Osvaldo