Using NRF24L01+ with pure assembler programing

[o.hojvat]

Dear people

I have connected NRF24!01+ with PIC16F1826 for use as PRX and have also another similar for PRX

For an initial test I tryed to trasmit a closed / open switch state to a LED and as ussually hapens it does not work

Also I have a Tx packets each 200ms with one Data byte incremented in each Tx
I get SPI write an read ok but at PRX have not getting any received packet

There is the same program for PTX an PRX with  #define    PRX  o rnot at compiling so most of defined values are the same

What I get reading with SPI : in PRX , Reg 0x17 FIFO_STATUS  bit4 TX_EMPTY:
 is 1 before loading data
0 after loading payload   (4 bytes)
1 after CE goes H

At PRX side  not IRQ arises , not changes in Reg 07 bit RX_DR

I only use assembler programming and I didn´t found in the web any complete and working assembler example.

--> I am asking please the simplest example with a detailed list of commands to send for configuring and useing TPX
and PRX, similar at Appendix B, pag 77 in NRF24L01+ data sheet.

*** But please include the waiting delays and other instructions that may be  needed ***

For some address, default values may be used in a first test ? ( only 1 Pipe )

Is it posible not  using CRC ?

I need to have something working before going to a complete use of full NRF24L01+ capabilities

Finally I will insert well tested software in bigger assembler programs

I like to  replace a RS485 conexion with this RF link

I will1452.Control_NRF.rar send the assembler that I am testing if somebody like to see it, but RF part is not working

Waiting some help, Best Regards, Osvaldo Hojvat

[ovrebekk]

Hi 

o.hojvat said:

- I guess dynamic payload  also applies to the ack payload length,

and the Tx FIFO need to be loaded before receiving the packet    Please confirm

Yes and yes. The ACK payload can be any length between 1 and 32 bytes, and you need to upload the ACK payload before you receive the packet from the PTX, otherwise it will not be included until the next packet arrives. 

o.hojvat said:

- If there are Tx from two PTX devices at the same time, I guess no one will be received OK

I think it may be needed to use diferent ARD in each PTX for avoiding the same problem in the retry

In case of packet collisions you will most likely lose both packets, yes, but if one of the packets have a higher signal strength than the other there is a chance you will receive it correctly. 

It is correct that configuring a different ARD in different PTX's can help reduce interference between them, since they will not retransmit lost packets at the same time. 

o.hojvat said:

-  I need in a big room a 15m secure link ,  Is it convenient to use 250 Kb rate or 1 Mb rate is OK ?

You should be able to reach 15m in 1M mode, as long as you don't have a lot of things blocking the signal (such as people, walls or heavy furniture). 

The actual transfer rate is considerably lower than the PHY rate, so using 1M mode would be beneficial in ensuring you can reach 57k of actual throughput even if you have some packet loss and need to retransmit some of the packets. 

o.hojvat said:

- At the RX unit, as it will have a power supply cable I can use a board with amplifier and external antena if it is necessary or the simplest available board may be OK ?

You should be fine without this, but it depends on the environment. If there is a lot of interference in the area from WiFi, Bluetooth etc then you might benefit from having a FEM (front end module) on the receiver, but using a FEM device  only on one side of the link is obviously not as efficient as having a FEM device both in the PTX and PRX. 

Whatever you end up doing it is important that you run testing in an environment as realistic as possible, to see how well your implementation works in practice. 

Best regards
Torbjørn