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
