Re: Sending a file through a LimeSDR mini with a loopback cable using PSK modulation

[Paul Martin]

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.dib1984@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 <m4rtinpf@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.dib1984@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 <evgymail@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.dib1984@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 <evgymail@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 <m4rtinpf@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>

Pkt_xmt_gr38_no_pycharm.txt
Description: Text document