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

[Paul Atreides]

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>