In my last post I explained that I couldn't transmit continuous QPSK from my Raspberry Pi 3B because the single-threaded RRC function couldn't keep up with the transmitter. In other words the transmitter was transmitting and consuming the data buffer faster than the RRC function could supply it. This led to a situation in which there were short data bursts separated by slightly longer empty sections.
Tonight I resolved that. I carefully examined the RRC function until I understood how it worked and was sure that nothing depended on previous results, then split it into 4 equal parts, since the Pi has a quad-core CPU. The code uses pthreads in C to run a method that does 1/4 of the work. It populates the start and end indices for each thread, starts all 4, and waits for them to finish. The Pi can now transmit smooth QPSK with just a few sparse dropouts. I was using composite video for this test so it might be fast enough with HDMI which lets the system clocks run faster.
This comment has been removed by the author.
ReplyDeleteI assume you found the single- and multi-threaded versions on GitHub.
Deleteyes, found both sources.
Deletewhich ARM architecture or Raspberry OS is relevant? Still 32 Bit? Or could we assume 64 Bit?
by the way: can you provide me a useful input/test file?
Deletehow could i generate an input file?
you might contact me directly via email h_ayguen@web.de
suppose, any random file could be used for performance testing, right?
I sent an email.
DeleteAwesome insights on implementing multithreaded RRC for Raspberry Pi! It’s a game changer for performance. Check out Better Joy for more Raspberry Pi projects!
ReplyDelete