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

nRF51822 - Proprietary Protocol - Using micro_esb library - Need Help Improving TX Function

Hey guys, I am currently using the proprietary protocol on the micro_esb.c library with the nRF51822. So far everything has been working great, but I am certain my transmission function could be improved.

Here is what I have so far:

void transmit_payload()
{
	uesb_stop_rx();
	uesb_disable();
	uesb_config.mode = UESB_MODE_PTX;
	uesb_init(&uesb_config);
	uesb_start_tx();
	
	uesb_write_tx_payload(&tx_payload);

	nrf_delay_ms(2);
	uesb_disable();
	uesb_config.mode = UESB_MODE_PRX;
	uesb_init(&uesb_config);
	uesb_start_rx();
}

Notice the "nrf_delay_ms(2)", if I don't have that there, the payload will not transmit, and I will not get a TX success interrupt.

The problem is that the device is mostly sitting in RX mode, receiving payloads. It periodically switches over to TX mode to transmit some payloads. Because of how I have it set up, it basically takes 2ms per payload, which is way too long to be not in RX mode (since the device will miss payloads while in TX).

I have a stack full of payloads that are queued up in memory, so when its time to transmit, its calling this function for each individual payload that needs to go out.

Are you aware of a better way of doing this, or a better function? I'm imagining if there is a way I could switch over to TX mode, and send off a whole bunch of payloads, then switch back to RX mode, instead of switching back and forth for each individual payload.

Can I just use the "uesb_write_tx_payload" function multiple times, and keep track of how much time has gone by, and if it has not exceeded 2ms yet after multiple calls, then add in delays?

Thanks and any help/advice is greatly appreciated!

Parents
  • Hi Mahonroy,

    I'm sorry for late response. We are low on staff here at the moment.

    I would suggest you instead of putting a delay of ms, you should wait for the event callback after the TX packet is sent. Please have a look here, at the uesb_event_handler. The event you should wait for is UESB_INT_TX_SUCCESS_MSK.

    Also be noted that the micro esb is deprecated. We integrated it inside the normal ESB library in our SDK v11. We suggest you to use that library (SDK v11 and up) instead.

Reply
  • Hi Mahonroy,

    I'm sorry for late response. We are low on staff here at the moment.

    I would suggest you instead of putting a delay of ms, you should wait for the event callback after the TX packet is sent. Please have a look here, at the uesb_event_handler. The event you should wait for is UESB_INT_TX_SUCCESS_MSK.

    Also be noted that the micro esb is deprecated. We integrated it inside the normal ESB library in our SDK v11. We suggest you to use that library (SDK v11 and up) instead.

Children
  • Thanks for the response! You don't happen to know the time it takes for that event UESB_INT_TX_SUCCESS_MSK to occur do you?

  • Well, it's depends on how many re-transmission you set, or if you enable re-transmission or not. You can have a look at the nRF51 radio spec to do calculation. It starts from RAMP-UP from TXRU to TXIDLE, then START and sending packet. Then the period to wait for ACK (if you enable ACK)

    It's easiest that you can toggle a pin when you calling uesb_write_tx_payload, and toggle again when you receive the event.

    One quesiton, which tx mode are you using ? UESB_TXMODE_AUTO or UESB_TXMODE_MANUAL*?

    If you are using the default mode UESB_TXMODE_AUTO, why did you call uesb_start_tx() ? Please follow the micro esb example included on Github

Related