I'm working on a BPSK transceiver/modem. This is meant to be a hierarchical block for an FHSS ad-hoc network, but right now I'm tweaking some of the settings and testing it on a single frequency. The pulse shape should be roughly 50kHz to fit in my 50kHz sub-channels for the FHSS system. If the sample rate seems high, it's because I will (eventually) combine it with a bladeRF, and the bladeRF's minimum bandwidth is 1.5MHz, so I set the sample rate to 3MHz and have been adjusting the samples per symbol to get the system working.
I THOUGHT I had everything worked out (flowgraph attached is this baseline configuration) until I attempted these changes (these are all individual A/B tests compared to the flowgraph). Note: some of the disabled blocks require gr-mac. I'm running the development version of GNU Radio (GRC states: 3.7.10git-31-gb17bcb88) on Lubuntu Xenial. 1. This is the most baffling issue for me: if I change the number of bits in the vector input to (1,0,1,1,0) or something, basically changing the length of the bit sequence before it repeats, the output constellation collapses to only ONE of the two BPSK points. Why? If the vector is outputting single bits, and those bits go through the packer to make full bytes regardless before being output to the next block, why is the received signal changing so much? 2. Likewise, if I enable the random source and disable the vector/byte packer blocks, the received constellation is a giant noisy cloud. 3. What is the difference between the DPSK Mod block and the PSK Mod block with "Differential Encoding" set to "Yes"? Can we get the distinction worked into the documentation? 4. When I set the PSK Mod block for Differential Encoding, the constellation becomes a unit circle. If I understand the PSK Demod tutorial on the GNU Radio site, the Costas Loop is supposed to correct for this, yes? But I've put in a slider to adjust the loop bandwidth and it seems to do nothing. 5. If I increase the samples per symbol past ~30, I get the following error: sched: <block pfb_clock_sync_ccf (9)> is requesting more input data than we can provide. I had another flowgraph with all of the blocks before/including the pfb configured exactly the same and it ran with sps = 100 just fine. Also, sometimes if I closed GRC and reopened it, it would run with no problems. 6. If I enable the Bit Error Rate block (so I can do something more robust than a cursory visual inspection of the time sink).....the flowgraph freezes almost instantly. Thanks for any assistance....I'm really struggling to finish my Master's thesis (<30 days now), and while I can handle troubleshooting/debugging C++ the RF stuff is still immensely frustrating.
test3 - dpsk_sch_radio.grc
Description: Binary data
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
