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.ReplyDelete
I assume you found the single- and multi-threaded versions on GitHub.Delete
yes, found both sources.Delete
which 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?Delete
how could i generate an input file?
you might contact me directly via email email@example.com
suppose, any random file could be used for performance testing, right?
I sent an email.Delete