This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problem about proprietary protocol and ack

Hi,

In my develop environment , there have many proprietary device.  One device is working on PTX mode, and the other devices is working in PRX mode.

If the PTX device send a broadcast proprietary packet (need ACK), all of PRX devices may  send ACK message back. Does it correct?

How can "PTX device" know the "ACK message" is send from which PRX device?

Thank you,

Chianglin

Parents
  • Hi Chianglin, 

    If you have multiple RX and one TX , I would suggest not to use require ACK packet. The PTX will switch of RX right after the first ACK packet received. 

    My suggestion is to send it as a NO_ACK packet, but then switch to PRX mode and listen. 

    On the normal PRXs when it receives a packet from the PTX, after giving a certain delay will switch to TX mode and send a (NOACK) packet back to acknowledge. In your packet you can add an ID of the PRX in the payload so that the PTX would know from where the packet comes from. 

  • Hi Hung,

    Thank you for your answer.

    I still have following questions:

    1. Would you please give me the bast and most quickly method to switch between PTX and PRX?

    2.  if I have multiple TX and multiple RX node in the same position and all of the TX node send broadcast packet.  Does all of the RX node will receive these broadcast packet and send ACK packet back to TX node (if use require ACK packet)?.  Does RX node know the address of TX node by analyze the content of received TX packet?

    3. Does the RX node can create a black-list of TX node?  I means: If the address of TX node is add into the black list of RX node, then RX will not receive any packet of this TX-node.

    Thank you,

    Chianglin

  • Hi,

    I have to correct my self, in last reply, the first sentence please read as "PTX will switch back to TX right after the first ACK received"

    1. You can use a SHORT  to join END event and DISABLE task to disable TX after you sent and a short to join DISABLED event to RXEN task to start RX. 

    2. You are talking about 1 TX talking to 1 RX and there are several pair of them ? The ACK packet is sent to the same address as it received. Note that there isn't a TX address and a RX address, they are the same on each pair. 

    A PRX can have different address, but a PTX has only one address, it's the address it sends data to and receive ACK from. 

    3. No. And as mentioned in 2, If there are multiple PTX sending to one address on PRX they all have the same address. But it's possible to disable a pipe, meaning you don't listen on that address anymore. 

  • Hi,

    Sorry, I have to explain the detail condition about previous question 2:

    For example, there have 6 proprietary devices, 3 devices are working in TX mode (continue send PTX packet) and 3 device are working in RX mode (run in PRX mode).

    a. Do these 3 PRX had received all of the 3 PTX packet and send ACK back to each PTX device?.

    b. After each TX device transmits a PTX Packet, it will receive an ACK packet from "different RX devices"?

    Thank you,

    Chianglin

  • Hi Chianglin, 

     

    Let me explain you how it work with ESB (I assume you use ESB)

    - A PRX device would have 8 pipes to receive data, each pipe has an address. It could be 2 or 3 bytes address, but let's think of them as address number 1 2 3 ...8. 

    Each PTX device would have a TX address, and a RX address to receive ACK from, they are the same number. So if a PTX send a packet to address 2 on TX, it will expect to hear ACK that has address 2 on RX. 

    And the address the PTX send to match with the address on the PRX, in this case number 2. 

    In your case you have 3PRX and 3 PTX. It depends on how you configure it. If you configure all PRX to have same address, say number 3. And all three PTXs has address configure to 3. Then whenever a PTX send a packet, all three PRX will receive and send a ACK back. But it's where the problem is, if all of them receive and send at the same time, there will be collision and the PTXs wouldn't receive anything because messages are collided. Even if message was not  collided by somehow you implement a random delay (as suggested) the PTX wouldn't listen after it gets the first ACK. So no, a PTX can't receive ACK from multiple PRX. You need to switch it to PRX to receive. 

    Also another note is that PTX will not listen if it's not expecting ACK. So when a PTX not sending data, it will not receive anything. 


     

  • Hi  Hung,

    Thank you for you detail explain.

    If I configure all PRX to have same address, say number 3. And one PTX has address configure to 3 and send a packet out.  All of three PRX will ACK this packet, is it right?

    If the PTX silt had enable ACK receive and the three ACK packet do not collided, the PTX will receive three ACK packet, is it correct?

    About the "random delay", does it implement in PRX site?  Would you please tell me how can I implement this function?

    Thank you,

    Chianglin

Reply
  • Hi  Hung,

    Thank you for you detail explain.

    If I configure all PRX to have same address, say number 3. And one PTX has address configure to 3 and send a packet out.  All of three PRX will ACK this packet, is it right?

    If the PTX silt had enable ACK receive and the three ACK packet do not collided, the PTX will receive three ACK packet, is it correct?

    About the "random delay", does it implement in PRX site?  Would you please tell me how can I implement this function?

    Thank you,

    Chianglin

Children
  • No, the PTX wouldn't receive 3 ACKs. As I mentioned several times, PTX stops receiving ACK after the first ACK it receives. 

    We don't make the ESB for this use case. PRXs will immediately retransmit and 3 ACK packets will most probably collide. You would need to add the random delay on your own. 

    That's why I suggest don't do the normal ACK. 

    What you do is to configure all 4 devices as PRX, all listen to address 3. When a node (we call it NODE A) want to transmit it switch itself to PTX mode, send a NOACK packet, and then switch back to PRX mode again. Other nodes (B, C, D) when receiving that packet (and check if it's for him) will switch to PTX and send another NOACK response packet , this NOACK contain the ACK and the ID of the PRX. 

    "NODE A" now in PRX mode, and can receive those response packets and can detect which PRX send the response. 

    This way it's much easier to implement as you don't have to modify the ESB protocol to receive ACK from multiple nodes. 

     

  • Hi Hung,

    When PTX (name Node-A) broadcast a packet without ACK, all of the three PRX (name Node B, C, D) will receive this packet.

    By your recommend, node-B, C, D should be delay a random time before switch to PTX and send a packet back to node-A.

    If  node B 's PTX buffer already have a packet (name packet-A), and it need to send a new packet (name packet-B) to Node-A, how can I drop packet-A when I execute "nrf_esb_write_payload()" function?

    Thank you,

    Chianglin

  • Hi Hung,

    Continue the previous question.  Node-A is working in PTX and Node-B,is working in PRX.

    If Node B's TX FIFO have one packet (name packet-A), and Node-A send a packet to Node-B.  Node-B will send ACK packet (the content is packet-A) no meter Node-A's "noack" flag is turn-on or turn-off. 

    Would you please tell me how to solve this problem?

    Thank you,

    Chianglin

  • Hi Chianglin, 

     

    To clear TX buffer you can call nrf_esb_flush_tx() 

    Maybe it's not clear in the documentation on infocenter (but it's clearer in the datasheet of nRF24 series, I would suggest to have a look at those), but noack bit will be used on the PRX to check if it should send the ACK packet back or not when the selective_auto_ack is set (Please have a look at the on_radio_disabled_rx() function where we have this check: 

     if ((m_config_local.selective_auto_ack == false) || ((m_rx_payload_buffer[1] & 0x01) == 1))

    This is the check if it should send ACK or not. This also requires you to use NRF_ESB_PROTOCOL_ESB_DPL instead of NRF_ESB_PROTOCOL_ESB (always ACK, as far as I understand)

Related