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

[Paul Martin]

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
Description: Text document