Oh sorry for the confusion, I'm NOT running gnuradio from the pycharm venv, I just put the folder there so pycharm handles the version control. Just in case, I did what you suggested, but the same as before happened (new log attached).
I've just finished setting up a VM and both flowgraphs work, so it must be something to do with my install. On the VM I only get a warning on the transmitter: "Warning: failed to XInitThreads()", but as far as I can tell it doesn't change anything. I tried Evgeny's simplified flowgraph with a LimeSDR mini and it also works. Tomorrow I'll experiment a little more and let you know if I find anything interesting. Again, thanks a lot to both of you! Paul On Thu, 11 Nov 2021 at 15:37, Paul Atreides <maud.dib1...@gmail.com> wrote: > > Glad to hear you didn’t give up! > Hmmmm. I haven’t seen this one on my machines. I see you’re using pycharm > (which is what i use). I think I had to setup pycharm to find GNURadio. IIRC > Pycharm typically sets up its own environment, so it might be missing a > module? That may not be valid, just my first thought. > > Try getting pycharm out of the equation temporarily by creating your own > embedded block (name it something different) and use the default editor > (gedit on my machine). Then copy past the code from the wiki into that, see > if the error persists. Again, just first thoughts to simplify the problem. > > I’ll see if there’s anything on my end I can see that’s obvious. > > <end transmission> > > > On Nov 11, 2021, at 12:38, Paul Martin <m4rti...@gmail.com> wrote: > > Evgeny, Paul: > > Thanks so much for replying! I was actually about to give up after all. > > > > I've tried to use the updated flowgraphs from the wiki, but got an > > error message while running the transmitter (log attached). Google > > didn't help to figure out what was wrong, besides the fact that it's > > the python embedded block. > > > > The receiver seems to work fine, although it has no data to receive at > > the moment. > > > > Paul > > > > On Thu, 11 Nov 2021 at 13:50, Paul Atreides <maud.dib1...@gmail.com> wrote: > >> > >> Answers below. > >> Barry, can you fill in where my understanding is weak here? > >> > >> <end transmission> > >> > >> On Nov 11, 2021, at 09:44, Evgeny Hahamovich <evgym...@gmail.com> wrote: > >> > >> > >> Indeed it works great out of the box :) Thanks Paul for fixing this! > >> > >> My pleasure, thanks for testing it! > >> > >> > >> But when I upgraded the setup by replacing the ZMQ with LimeSDR (Tx on one > >> LimeSDR is transmitting to an Rx of another LimeSDR through an > >> attenuator), the Rx wasn't able to recover the message. I simplified the > >> flow by removing the resamplers and using a single sampling rate and added > >> a squelch block to the Rx to stop the idle signals and it's working well > >> this way. My Tx and Rx flowcharts are attached. > >> > >> Any time you introduce the “real world” of hardware there are many new > >> variables. Things like DC offset, dynamic range, etc. can really effect > >> your outcome. > >> Sounds like you stripped it down pretty aggressively. I think you need to > >> get more familiar with your analog environment and play with it a bit. > >> This part is not as “drag and drop” as some of the digital parts. > >> > >> > >> There are some questions that are still open... > >> 1. There is an access code for Rx. Where was it created? Do I need it? > >> > >> The access code is created in the embedded Python block. The code is > >> commented, copy and paste the values into a Python IDE and display them as > >> bits, you’ll see the sync word there. As to whether or not you need it, I > >> think that’s up to you and your implementation. Generally I’d say yes, but > >> you should read up on the use of sync words/access codes to understand > >> their uses better. > >> > >> 2. The Tx should send some sync header before the data, that would be used > >> by the Rx while locking on the clock frequency and this data won't be > >> recovered. I don't see such sync data here, am I correct? > >> > >> Answered above. I think it’s a difference of terminology. Again, the > >> embedded block is commented and answers this question. > >> > >> I increased the delay between every 2 messages to 5 sec and timed the > >> detected messages, it seems that part of them are not detected. Actually, > >> I am surprised that anything at all gets detected! How is the clock > >> locking so fast?! > >> > >> I think this speaks to the “conclusions” section on the wiki that Barry > >> wrote up extremely well. Read that, it will explain what your seeing. > >> > >> 3. (a side question) Why do you multiply the signal by 1/2 before > >> transmitting? Are you aiming to get to +-1 levels to avoid clipping? > >> > >> I didn’t write the flowgraph, but I know what your talking about. There is > >> probably a fundamental DSP principle here that eludes me at the moment as > >> I don’t have it in front of me, but avoiding clipping sounds correct, > >> maybe Barry can answer this? > >> > >> > >> > >> Evgeny > >> > >> > >> On Thu, Nov 11, 2021 at 11:54 AM Paul Atreides <maud.dib1...@gmail.com> > >> wrote: > >>> Evgeny: > >>> I just updated the wiki. If you are willing to test them out, please try > >>> the new GR3.8 tutorials under the subsection > >>> "Using BPSK with Hardware Simulation (version 3.8)" > >>> https://wiki.gnuradio.org/index.php/Packet_Communications > >>> On Wed, Nov 10, 2021 at 12:07 PM Evgeny Hahamovich <evgym...@gmail.com> > >>> wrote: > >>>> Hi Paul, > >>>> I tried to perform a similar experiment and unfortunately after > >>>> investing a significant effort, still haven't figured out how the > >>>> packets method works :( > >>>> For now, I pack the data in python, send the packed data to GNURadio and > >>>> LimeSDR_Tx. and on the Rx side, I detect by LimeSDR_Rx, perform all the > >>>> clock recovery procedure in GNURadio and then send the extracted bits to > >>>> python via ZeroMQ where I do the unpacking with my code. It's definitely > >>>> not optimal, but it works. > >>>> Evgeny > >>>> On Wed, Nov 10, 2021 at 5:16 PM Paul Martin <m4rti...@gmail.com> wrote: > >>>>> Hi! > >>>>> I'm trying to send a file through a LimeSDR mini with a loopback cable > >>>>> using PSK modulation. > >>>>> The gr-limesdr plugin only works with gnuradio 3.8, so I'm on that > >>>>> version. > >>>>> OS is Linux Mint 20.2: > >>>>> $ cat /proc/version > >>>>> Linux version 5.11.0-37-generic (buildd@lcy01-amd64-021) (gcc (Ubuntu > >>>>> 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) > >>>>> #41~20.04.2-Ubuntu SMP Fri Sep 24 09:06:38 UTC 2021 > >>>>> CPU: 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz > >>>>> The examples that I could find all used the deprecated packet > >>>>> encoder/decoder, so I set up to adapt the packet_loopback_hier example, > >>>>> which relies on packet_tx and packet_rx (documentation here > >>>>> https://www.gnuradio.org/doc/doxygen/page_packet_comms.html). > >>>>> My flowgraph is here: > >>>>> grc packet_loopback_hier.grc https://pastebin.com/w1cQxTLJ > >>>>> screen capture packet_loopback_hier.png https://imgur.com/wccyfwC > >>>>> (modified from > >>>>> https://github.com/gnuradio/gnuradio/blob/maint-3.8/gr-digital/examples/packet/packet_loopback_hier.grc). > >>>>> The packet_tx and packet_rx are here: > >>>>> packet_tx.grc https://pastebin.com/fhqQ1Y4n > >>>>> packet_rx.grc https://pastebin.com/Zvr3x7vK > >>>>> (these are exactly the ones from the repo > >>>>> https://github.com/gnuradio/gnuradio/blob/maint-3.8/gr-digital/examples/packet/packet_tx.grc > >>>>> > >>>>> https://github.com/gnuradio/gnuradio/blob/maint-3.8/gr-digital/examples/packet/packet_rx.grc). > >>>>> At first, I removed the channel model and got it working with a file > >>>>> source and sink, albeit with some limitations: > >>>>> The file needs to be "small" or I get a buffer overflow error (I'm > >>>>> using an ~8 KiB file, attached), and I had to pad the byte amount of > >>>>> the file to be an integer number of the packet_len, plus an additional > >>>>> full packet (I've attached the sample file that I'm using, > >>>>> input_file_padded.dat > >>>>> https://drive.google.com/file/d/1f3Os_okrn-d-DJrm0L1CyEKUxnOS_TDE/view?usp=sharing). > >>>>> These limitations don't bother me so I didn't look for the cause, I'm > >>>>> just mentioning them in case they are relevant. > >>>>> Then I added the LimeSDR source and sink, but I don't get any data at > >>>>> the output of Packet Rx. Looking at the constellations at output out of > >>>>> Packet Tx (left) and the LimeSDR source (right) I get this > >>>>> (constellations.png https://imgur.com/a/vGz4sHO). > >>>>> From what I could research, the left constellation isn't the four dots > >>>>> that I initially expected because of the RRC filter. > >>>>> On the right constellation, I have no clue if what I'm seeing makes > >>>>> sense. > >>>>> Before moving forward and investigating why the different blocks of > >>>>> Packet Rx aren't outputting anything, I'm trying to make sure that the > >>>>> received signal is correct. > >>>>> I've also made a video of the flowgraph running > >>>>> (https://imgur.com/a/opY6dV9): on the first GUI sink from the left is > >>>>> the correlation estimator output, then the output of Packet Tx, LimeSDR > >>>>> source, and Packet Rx; and attached the console output > >>>>> (packet_loopback_hier.txt https://pastebin.com/r3ivn4eq). > >>>>> Summarizing: Is the output of the LimeSDR source right or am I doing > >>>>> something wrong? > >>>>> Thanks for taking the time to read my question! > >>>>> Regards, > >>>>> Paul > >> <RX_PKT.png> > >> <TX_PKT.png> > >> <cant_recover.png> > > <Pkt_xmt_gr38.txt>
Generating: '/home/paul/Downloads/packet_communications/xmt/pkt_xmt_gr38.py' Executing: /usr/bin/python3 -u /home/paul/Downloads/packet_communications/xmt/pkt_xmt_gr38.py qt5ct: using qt5ct plugin handler caught exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 78, in eval try: self._callback(arg) File "/home/paul/Downloads/packet_communications/xmt/packet_format_gr38.py", line 22, in handle_msg inMsg = pmt.to_python (msg) File "/usr/lib/python3/dist-packages/pmt/pmt_to_python.py", line 126, in pmt_to_python return to_python(p) File "/usr/lib/python3/dist-packages/pmt/pmt_to_python.py", line 57, in pmt_to_dict for i in range(pmt.length(items)): File "/usr/lib/python3/dist-packages/pmt/pmt_swig.py", line 2647, in length return _pmt_swig.length(v) RuntimeError thread[thread-per-block[12]: <block Packet Format GR38(3)>]: SWIG director method error. Error detected when calling 'feval_p.eval' >>> Done Generating: '/home/paul/Downloads/packet_communications/xmt/pkt_xmt_gr38.py' Executing: /usr/bin/python3 -u /home/paul/Downloads/packet_communications/xmt/pkt_xmt_gr38.py qt5ct: using qt5ct plugin handler caught exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gnuradio/gr/gateway.py", line 78, in eval try: self._callback(arg) File "/home/paul/Downloads/packet_communications/xmt/epy_block_0.py", line 22, in handle_msg inMsg = pmt.to_python (msg) File "/usr/lib/python3/dist-packages/pmt/pmt_to_python.py", line 126, in pmt_to_python return to_python(p) File "/usr/lib/python3/dist-packages/pmt/pmt_to_python.py", line 57, in pmt_to_dict for i in range(pmt.length(items)): File "/usr/lib/python3/dist-packages/pmt/pmt_swig.py", line 2647, in length return _pmt_swig.length(v) RuntimeError thread[thread-per-block[12]: <block Packet Format GR38b(4)>]: SWIG director method error. Error detected when calling 'feval_p.eval' >>> Done