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

[Paul Atreides]

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 
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  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
>>
>
>

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?



> On Nov 11, 2021, at 09:44, Evgeny Hahamovich  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  
>> 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  
>>> 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  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/Zv

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  wrote:
>
> Answers below.
> Barry, can you fill in where my understanding is weak here?
>
> 
>
> On Nov 11, 2021, at 09:44, Evgeny Hahamovich  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  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  
>> 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  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.gnurad

newsched (GR4 proposed runtime) v0.1.0 Released

[Josh Morman]

Hello GR Community!

It has finally come time to put out a newsched release - up to this point
the codebase has been rapidly evolving, but has converged on a set of core
features as of recently.

https://github.com/gnuradio/newsched/releases/tag/v0.1.0

Newsched is the proof of concept framework for a future GNU Radio 4.0

Core Features

   - Modular Scheduler Framework
  - interfaces based on a single input queue
  - default scheduler with N blocks/thread
   - Custom Buffers
   - YAML-driven Block Workflow
   - Consolidated Parameter Access Mechanisms
   - Simplified Block APIs

Detailed documentation can be found here


With this release of newsched, you can easily create your own blocks,
custom buffers, and even your own scheduler if you are so inclined

Special thanks to Bastian Bloessl and Marcus Müller for leading the effort
to architect the runtime and provide guidance as to the design decisions

Also want to acknowledge the Scheduler Working Group who have consulted and
provided feedback and ideas on a regular basis about design decisions. I
apologize if I have left anyone out here, but another special thanks to:
Seth Hitefield, Jeff Long, David Sorber, Mike Piscopo, Jacob Gilbert, Marc
Lichtman, Philip Balister, Jim Kulp, Wylie Standage, Garrett Vanhoy, John
Sallay, and all the people associated with with the DARPA DSSoC program
that shared their research giving valuable insight.

Please reach out to me here or on chat.gnuradio.org - #scheduler room if
you have any questions or would like to get involved

Josh

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

[Paul Atreides]

Glad to hear you didn’t give up!
H. 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. 



> On Nov 11, 2021, at 12:38, Paul Martin  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  wrote:
>> 
>> Answers below.
>> Barry, can you fill in where my understanding is weak here?
>> 
>> 
>> 
>> On Nov 11, 2021, at 09:44, Evgeny Hahamovich  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  
>> 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  
>>> 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.
 Ev

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  wrote:
>
> Glad to hear you didn’t give up!
> H. 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.
>
> 
>
> > On Nov 11, 2021, at 12:38, Paul Martin  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  wrote:
> >>
> >> Answers below.
> >> Barry, can you fill in where my understanding is weak here?
> >>
> >> 
> >>
> >> On Nov 11, 2021, at 09:44, Evgeny Hahamovich  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, 

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

[Barry Duggan]

Hi!



Here are my answers:



1. The access code is created in the Embedded Python block, and is 
225,90,232,147 (at the end of the preamble). It is necessary for the receiver 
https://wiki.gnuradio.org/index.php/Correlate_Access_Code_-_Tag_Stream



2. The sync header (preamble) is the 16 decimal 85 bytes (giving alternating 
1's and 0's. More frequent messages will hold the synchronization better than 
long delays.



3. Don't clip or saturate the signal going into the SDR.



---

Barry Duggan KV4FV

https://github.com/duggabe



On Thu, 11 Nov 2021 11:50:36 -0500, Paul Atreides wrote:

 


Answers below. 

Barry, can you fill in where my understanding is weak here? 



 



> On Nov 11, 2021, at 09:44, Evgeny Hahamovich  
> 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 

>