All:
I am very new to gnuradio. I have installed GRC using radioconda-2024.05.29-Windows-x86_64 & I have made my way thru the ADALM PLUTO related tutorials. As a result, everything seems to be working well with my ADALM PLUTO + gnuradio. I recognize that this is a very powerful capability & I appreciate all who have worked to make it what it is !!
Now, I am interested in learning more & understanding as much of what is going on under the covers with gnuradio controlling my ADALM PLUTO as I can. With this in mind, I have attempted to put together a series of flowgraphs that allow me to experiment with BPSK & QPSK operations.
My "instrumented_bpsk.grc" & "instrumented_qpsk.grc" flowgraphs are heavily based upon the respective tutorial flowgraphs. I am very pleased with being able to tweak the controls & directly observe the effects of doing so. I have only a fundamental understanding of BPSK & QPSK, but having this capability has been educational & enlightening.
As my next step, I have created my "digital_modem_bpsk.grc" & "digital_modem_qpsk" flowgraphs, which are an amalgam of many parts from the respective tutorials, as well as other parts from a variety of examples that I found elsewhere. I hope that I have mixed & matched everything logically & properly.
So, in general, in my flowgraphs, I have included a virtual sink & a virtual source to allow me to verify that everything works before injecting my ADALM PLUTO into the mix. Everything does, in fact, work as expected/desired when flowing thru these virtual connections. However, when I enable the PlutoSDR Sink & PlutoSDR Source in place of the virtual connections, things no longer work as expected/desired & I'm trying to understand why.
I am very interested in understanding exactly what may be going wrong, as well as what & why a particular mod/fix will result in correct behavior. This is the primary objective of my experimentation.
So, here's what I'm seeing (by modulation type):
ASSUMPTIONS:
============
- I am sending a canned message stream with a series of characters preceding the actual message (a three-character Neuman-Hoffman sequence) that allow me to properly detect the intended byte (character) boundaries (I have an external utility that I wrote which allows me to enter the raw hex bytes as received & to selectively bit shift them to verify the receive stream when it is bit aligned appropriately), along with a fixed message, with all of this surrounded by padding bytes to allow modulation lock preceding the actual message, plus character stuffing following the message to allow the desired message to be flushed thru the radio transmitter & receiver
BPSK
====
- with the virtual connections, everything works perfectly
- with the ADALM PLUTO in the flow, the following is observed:
- it appears that I am actually able to demodulate/decode the BPSK data stream
- the front-end padding bytes seem to be slightly sliding in time as the received value of the bytes changes within the stream (which I don't expect)
- if the front-end padding is too short, the demodulation fails completely (expected)
QPSK
====
- with the virtual connections, everything works perfectly
- with the ADALM PLUTO in the flow, the following is observed:
- it does not appear that I can actually demodulate/decode the QPSK data stream
- the received data has no resemblance to anything that was sent (no series of front-end padding, no recognizable message data, and no series of post-message stuffing)
With my limited detailed understanding, I am unable to even guess where to start looking. Can anyone please point me in a direction ?? I'm not necessarily looking for just a "do this & everything will be fine" recommendation, but rather & more importantly, I'm looking for what to change & I also have a strong desire to understand why the change makes the positive difference that it does.
Thank-you in advance for any assistance that you can provide !!
Mark J Culross
KD5RXT
No comments:
Post a Comment