Low data rate when receiving via nRF24L01 with ATmega32U4

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello everyone,

So, as mentioned in the title, I have interfaced the nRF with the mega. These are the settings used:

nRF settings:

Data rate = 2Mbps

Auto-ack = ON

Retransmission delay = 750µs

Retransmission count = 15

Payload count = 1 Byte

 

The data is received whenever the IRQ is activated by new data.

The received data is then sent via UART @57600 Baud and displayed in a Terminal.

 

This is where the issue lies. The data is updated at a painfully slow rate ~50 bytes per second.

 

I have also tried disabling the Auto-ack and auto-retransmission but the data rate at the UART side remains constant.

 

Could someone please point out where the issue is?

I have attached the TX and RX source files.

Thanks!

 

Attachment(s): 

This topic has a solution.

Regards,
Frederic Philips

Last Edited: Sun. Aug 26, 2018 - 04:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Thruput vs speed....

 

Similar to the interrecord gaps in mag tape recording, an RF transmitter needs time to come up to full power, let the receiving end sync, and then send a data packet with address and data checking headers all for one byte payload!!!  Not counting ACK/NAK retries, etc, in summary a lot of overhead for a one byte payload!

 

You need to examine your real data needs and expected thruput requirements and understand how your radio's work.

 

Jim

 

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

Last Edited: Wed. Aug 15, 2018 - 08:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

50 bytes per second is 20 msec per byte. That matches with the two _delay_ms(10) calls in transmit_data().

A little googling tells me the nRF24L01 has a 32-byte transmit buffer. You need to change transmit_data() to send more than one payload byte at a time (up to 32) via SPI.

You'll also want to change the loop in nRF_Put_String() to break-up long strings into chunks 32 bytes or les in length.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

balisong42 wrote:
50 bytes per second is 20 msec per byte. That matches with the two _delay_ms(10) calls in transmit_data(). A little googling tells me the nRF24L01 has a 32-byte transmit buffer. You need to change transmit_data() to send more than one payload byte at a time (up to 32) via SPI. You'll also want to change the loop in nRF_Put_String() to break-up long strings into chunks 32 bytes or les in length.

That's right! I was too much in hurry to check the transmit function for the delays. Was able to optimise it and bought the data rate to about 1 byte per 1.3 ms. Could reduce that further by using larger payloads (working on it). Thanks a lot balisong and ki0bk.

Regards,
Frederic Philips

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So time to mark the solution?

 

See Tip #5

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...