Performance issues

[tobiasmuecksch]

I'm having a sender and a receiver.

The sender constantly sends packages (32byte), and the receiver prints out the number of packages received per second.

These are my relevant settings (the are the same for sender and receiver):

PALevel: nrf24.RF24_PA_MAX DataRate: nrf24.RF24_2MBPS CRCLength: nrf24.RF24_CRC_DISABLED PayloadLength: 32

I can't get it to transmit more than 78 packages per second which is (78*32) 2496 Bytes per second. (2496 / 1000) = ~2.5 kB/s.

I assumed that 2Mb/s = 250 kB/s = 25000 B/s and therefore 25000 / 32 = ~780 Packages per second. I know these rates are theoretical, but I thought at least 75 % were possible.

Is it possible, that the DataRate option is currently ignored?

P.S.: Sorry, if I did the math wrong. In my daily work, I'm not confronted with it very often.

[ludiazv]

2.5K/s is very low. I need to test this.

However typical speeds reported using the C++ libray will be arround 40-60K KB/s. Nodejs will add some overhead so it could be less.

The main idea to improve performance is is done by:

• Using max payload size (32)
• Disable auto-retries.
• Disable autoack.
• Disable CRC or use 8-bit CRC.
• Use TX FIFO in transsmiter (not suported by the libray).
• Use IRQ in receiver (this is not supported yet by the library)
• Compile the C++ libraries with BCM driver not SPIDEV.

Also I recommend for testing not using PA_MAX. If your power supply is not good it could cause reception or transfer problems can happen. Also in testing do not place the radios to far as distance could affect also transmission rates.

I will do some tests to check this performance problem.

Regards,

[tobiasmuecksch]

Thank you for the performance improvements tips. I will keep them in mind 👍

Distance: Both modules are on the same table. Distance is around 1 meter.

PA_LEVEL: I've also tested PA_HIGH and had the same problem.

[ristomatti]

@tobiasmuecksch You might also be experiencing one of the many problems one can have with these modules. I suggest to read through the tips on the below sites. You might find a solution to your problem this way also.

• Fixing your cheap nrf24l01+ pa/lna module
• NRF24L01 : Fixing connection issues
• RF24L01 2.4GHz Radio/Wireless Transceivers How-To

[tobiasmuecksch]

@ristomatti Thank you for that very useful information. Maybe it's a hardware issue. I will try to fix the hardware and report back here.

[ludiazv]

As @ristomatti hw is a problem because of clones and power requirements (this is why decoupling capacitors a must specially on clones). Long dupont wires also could also cause problems on the SPI interface.

If you want to focus on your project I recommend to buy a break-out board for the radios. I designed this Hat/pHat perfect for Pi 2,3 and Zeros https://github.com/ludiazv/borosRF2.

I'm investigating performance problems. You are write, with current implementation I'm getting also 2-3Kb/s reception. With minimal changes I can get up to 6-7 K/s. I think this could be improved but i need to do some tests.

On writing with your code i get about 10-11 k/s. It seems that the overhead is on nodejs. If I change "setTimeout(emmitLoop)" to "setImmediate(emmitLoop)" the transfer rate jumps to 19-20Kb/s. This could be improved possibly transfer arrays of frames to the library. This imply a huge increment of CPU usage how ever. So here is a trade-off btw speed and cpu available for your application. On Pi Zero this is big problem as it has only one core.

I will keep track of this question. However, I you plan to stream audio check first the bandwith requirements of your signal. I you need stereo CD quality, I think it would be very complex to archive the data rate required without compression. But it could do with less quality for example mono with 22Khz.

Regards,

[tobiasmuecksch]

@ludiazv I'm currently working on mp3 compression to 128kbit/s - that would be perfectly sufficient for my needs.

But I'm still confused by the big loss of speed.

Regarding setTimeout() I only used this to prevent blocking the console output. I'll make a test script with only a loop (without setTimeout or setImmediate).

[tobiasmuecksch]

@ludiazv FYI, the tindie store is empty. There aren't any products: https://www.tindie.com/stores/boros/

[ludiazv]

Hi @tobiasmuecksch , I have been doing serveral test and I can confirm that the upper limits of transmission of the cpp library (under heavy cpu load and no nodejs overhead) will be arround 43Kb/s at 1MBPS and 65Kb/s at 2MBPS. If you dont use Ack-feature this could go up x2. But you need to implement a more complex protocol to steer the transmission.

I've been testing a new version of the node module to implement buffered writes and reads of several kb at once from nodejs. This will make simple to stream a process larger chunks of data in one callback and get similar speeds for sending data, at both speeds. For the reception of data the thing is a more complex as you need to play with polling times that will reduce the performance to 10%-20%. This can be improved with interruptions but this option is not implemented yet.

So being conservative I think you can assume that you can get arround 25K/s at 1MBPS with Ack with reliability. The CPU will be hurt also so take that in acount.

Check if with this data rate will fit your specs. In principle 128kbps are 16K/s but you need to add the ovehead of your final transmission protocol. As your a going to need to control that, do some prebuffering and work with retransmissions if ack is not valid.

Regards,

[ludiazv]

Hi @tobiasmuecksch

The new version on the master branch will enable to transfer at >40Kb/s with ACK 1MBPS. You have to use the method stream to send biger buffers. Use changeWritePipe & stream APIs to configure streaming and sending.

For recepteption you need to use the IRQ line on the reciver and inform about it in the configureAPI. Using also the ChangeReadPipe for mergin incoming frames will also help improve reception rate in

In the test folder there is a sample script test_speed.js that will show you how. I've been testing with Pis and getting similar transfer rates to the bare cpp library. >40K @ 1MBPS and >65K @ 1MBPS.

Could test it?

[tobiasmuecksch]

@ludiazv Thank you very much for your effort. I will test it next week!

[ludiazv]

New relese published in npm with performance fixed