discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with Correlation Estimator in GNURadio


From: Marcus Müller
Subject: Re: Problems with Correlation Estimator in GNURadio
Date: Sat, 16 May 2020 14:49:00 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

Hi SG,

well, packets getting broken over the air is normal. That's what happens!

Also, really, we've removed quite a bit of broken packet infrastructure
in GNU Radio 3.8; you should really be using GNU Radio 3.8 and when
starting to develop anything in this day and age. GNU Radio 3.7 is
something we maintain for legacy reasons, mainly.

Best regards,
Marcus


On 15.05.20 15:04, 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
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]