Re: Problems with Correlation Estimator in GNURadio

[Shruti Gupta]

Hi!

I have installed GRC3.8 and was working on BPSK based packet 
communication using LimeSDR. It doesn't seem o improve things much. All 
the packets that I receive are rejected due to errors in reception and 
header parser fails. I think it's the correlation estimation block of 
the AGC in the system which is creating this issue.How should I ensure 
that the calibration of correlation estimator and AGC is correct and its 
not introducing errors at receiver? Could someone point me to the 
sources  that can help.

Thanks
SG

On 19/05/20 3:37 pm, Shruti Gupta wrote:
> Hi!
>
> Thanks for your reply.
>
> While I'll work on installing and working with GRC 3.8, I was just 
> wondering will the over the air communication be bad enough to not 
> even receive a single correct packet? Is it to do with loop_bw for 
> FLL, PFB and Costas_Loop or the digital gain values (a multiply block 
> for the source signal) in RX? What is the logic behind setting of the 
> loop_bw of these blocks?
>
> Thanks and Regards
> SG
>
> On 15/05/20 6:34 pm, Shruti Gupta wrote:
> > Hi!
> >
> > I have been trying to use the packet communication examples under 
> > gr-digital in GNURadio(v 3.7.14.0) on ubuntu machines with LimeSDR 
> > Mini for over the air communication.  I am using the 
> > usrp_packet_tx.grc and uspr_packet_rx.grc  to transmit and receive 
> > BPSK modulated packets respectively. I have modified these examples 
> > for LimeSDR Mini by including LimeSDR source and sink blocks and 
> > setting up the parameters. Now, I am running TX on one machine and RX 
> > on another machine tuned to same frequency. However, when I keep the 
> > gain values for RX low since the distance between TX and RX is few 
> > feet and eliminating the possibility of RX saturation, the packets 
> > are not being detected, while for higher gain values packets get 
> > detected but the correlation start tags are tagged before the 
> > position of estimation tags. I am not too sure if that's how it is 
> > suppose to work.
> >
> > Moreover, even after being detected the packets are not decoded and I 
> > receive following message  on console:
> >
> > INFO: Parser returned #f
> >
> > I think this is due to either incorrect header decoding or incorrect 
> > packet detection which freezes the header/payload demux block in the 
> > flowgraph. Also, even for very few packets that are decoded, the 
> > header is incorrect so why does the packet even gets decoded? Is 
> > there a way to work around this problem? Can we use some other block 
> > for packet detection?
> >
> > Any suggestion or help is highly appreciated.
> >
> > Thanks in anticipation
> > SG