Using NRF24L01+ with pure assembler programing

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

Parents
  • I undestand well tis matter.

     I will ask about some to specific questions that may be not usefull for other people , I guess it will better to no use the forum.

    Anyway yo can go back this  to public tickets if consider there may be usefull for other peoples.

    I will begin with one order from one PTX to the PRX inside the handheld unit program but I am thinking in advance for posible problems with other orders received at central unit 

    Basically a handheld must have updated information before sending an order.

    So at the moment I find 3 aproach: 

    1) Using the proposed star 1PRX to up to 6 PTX, as in data sheet

    In this case the PRX does not knows which PTX will send the next packet and can not upload the regarding information in ack payload. The PTX may repeat the Tx in a very short time to  get it.

    2)  each PTX can use a diferent  frequency channel and the PRX may be receiving about 20 ms at one freq. and if there is no received packet, PRX  moves to other diferent freq.   not adyacent channel).

    Please answer if there are posible interference for 2  PTX trasmiting at the same time but diferent frequency.

    3) One PTX and up to 6 PRX devices (one in each handheld).  Disadvantage may be Increased battery consumption.  Most probabely RFmay be OFF most of  the time

    As I am using with RS485 cable , PTX sends a short packet for each PRX  and wait a short time for a reply.   If not, It moves to other PRX address

    Best Regards

Reply
  • I undestand well tis matter.

     I will ask about some to specific questions that may be not usefull for other people , I guess it will better to no use the forum.

    Anyway yo can go back this  to public tickets if consider there may be usefull for other peoples.

    I will begin with one order from one PTX to the PRX inside the handheld unit program but I am thinking in advance for posible problems with other orders received at central unit 

    Basically a handheld must have updated information before sending an order.

    So at the moment I find 3 aproach: 

    1) Using the proposed star 1PRX to up to 6 PTX, as in data sheet

    In this case the PRX does not knows which PTX will send the next packet and can not upload the regarding information in ack payload. The PTX may repeat the Tx in a very short time to  get it.

    2)  each PTX can use a diferent  frequency channel and the PRX may be receiving about 20 ms at one freq. and if there is no received packet, PRX  moves to other diferent freq.   not adyacent channel).

    Please answer if there are posible interference for 2  PTX trasmiting at the same time but diferent frequency.

    3) One PTX and up to 6 PRX devices (one in each handheld).  Disadvantage may be Increased battery consumption.  Most probabely RFmay be OFF most of  the time

    As I am using with RS485 cable , PTX sends a short packet for each PRX  and wait a short time for a reply.   If not, It moves to other PRX address

    Best Regards

Children
  • Hi

    I made public the ticket - there are not private information here.

    ----------------------------- Data rate ----------------------

    From one handheld they may be two orders sent in 1 second, by example playing a short horn sound,
    or turning ON / OFF some ligth for a controled locomotive
    At maximun 5 Data in one second while modifying speed control position. But the most important is the last value, when the control stop moving.
    .
    I will prefer the 3) procedure because it is more clear for me, and it will have no interference or colitions problems.

    It is a good idea your suggestion of sincronizing  RF activationat PRX  when it is expected a packet.
    It is rather easy to do for only 6 devices.   Probabely total 100 ms for the 6 PRX , so this will be the maximum delay to trasmit an handheld order.

    I case of no receiving the packet at the expected time, PRX can extend the RF ON time.  I will be not very often

    ---  I guess in each transmition, the PTX will change the tx adress (PIPE 0 ?) and also it will place the same address for PIPE 0 rx.

    --- It may be used PIPE 0 in all 6 PRX ?

    --- Perhaps it may be better to use a diferent PIPE for each PRX.

    Please comment about this matters.

    Anyway I must work (1 to 2 month) with TX / RX devices complete hardware and programms and some other problems may arises.

    Thank you very much for your help.    Now I can use the RF link with my own assembler.

    Best Regards

    Osvaldo

  • Hi Osvaldo

    If each device only sends a couple of packets every second then the chance of collision should be very small. Sending one packet at 1M PHY takes at most ~320us when sending 32 bytes, even less if you send shorter packets. Sending 10 of these packets pr second means you only spend ~0.3% of the available RF time, and even if some other PTX is also transmitting it is very unlikely to send at the same time. 

    Once in a rare while it will collide, but then you can use the retransmission mechanism with different ARD to ensure that they will retransmit the packets at different times. 

    So that would be my recommendation, but obviously you are free to choose which option you prefer. 

    o.hojvat said:
    ---  I guess in each transmition, the PTX will change the tx adress (PIPE 0 ?) and also it will place the same address for PIPE 0 rx.

    The PTX doesn't change the address. You need to ensure that both the TX address and the RX PIPE0 address is configured to the same value, otherwise the PTX will not be able to receive the ACK. 

    o.hojvat said:
    --- It may be used PIPE 0 in all 6 PRX ?

    Yes, you can use whatever pipe you want on the PRX side. The critical point is that you configure the addresses differently for all PRX's, so you don't get two or more receivers responding to the same packet. 

    o.hojvat said:
    --- Perhaps it may be better to use a diferent PIPE for each PRX.

    It is up to you. Either you configure the same address set in all PRX's, but enable different pipes in each of them (use pipe 0-5 for PRX 0-5), or you just use pipe 0 for all of them but make sure to configure unique pipe 0 addresses for each PRX. 

    The pipe system is optimized for the use case where you have 6 PTX's and 1 PRX, and is not as streamlined when you have multiple PRX's and one PTX. It still works, but in this mode you will need to configure the TX and pipe 0 address on the PTX every time you want to switch to another PRX, you can't just tell the PTX to transmit to a different pipe (more modern Nordic devices like the nRF52 series have removed this limitation). 

    Best regards
    Torbjørn

  • Hi

    I will keep all  yours comments. Thank you

    By the moment  I am working on the complete system programms and it may arises reasons to prefer the use of one of the methods

    Best Regards

  • Hi Osvaldo

    I am glad I could help. The best of luck with your project Slight smile

    Best regards
    Torbjørn

Related