discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: Packet TX and RX on E312


From: Cameron Matson
Subject: Re: Packet TX and RX on E312
Date: Thu, 25 Jun 2020 11:44:09 -0500

I moved my setup from e312s to n310s so that I could run the flowgraphs with the gui blocks to help with debugging.  It looks like the phase is off at the RX as the constellation gui from the USRP (the one before the Packet Rx block) is rotating.  I'm able to adjust the magnitude of the IQ data by playing with the tx and rx gain, but I can't get the phase to lock.  

What are some of the knobs I can turn to help the Packet Rx block detect the signal given the phase offset?

Thanks,
Cameron


On Wed, Jun 24, 2020 at 8:53 AM Cameron Matson <ncmatson95@gmail.com> wrote:
Marcus,
Thanks for that information, maybe I'll look more into the FPGA.

As for the other problem I agree, it's probably setup.  The radios are "connected" via antennae.  Both USRPs have VERT900 antennae to the TRX terminals.

I've run other experiments successfully transmitting data from one to the other.  For example I've used the (deprecated I know) Packet Encoder/Decoder block to send a file from one to the other.  But nothing since I started using the Packet TX/RX hier blocks.

Cameron


On Tue, Jun 23, 2020, 2:14 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:
On 06/23/2020 01:17 PM, Cameron Matson wrote:
I've tried from 125K to 16M (which if I request anything higher is what the device seems to cap it at).  The lower sample rates on the RX side actually do solve the O problem, which I guess makes sense, but the tG and U are still there on the TX side, and no packets seem to be decoded.

Cameron
The CPU on the E310 is a dual-core ARM9 CPU clocked at 866MHz.  That means that it can't move very many samples (particularly full-duplex)
  per second for a "complex" signal flow that involves modulaton/demodulation.  When doing pretty-much *nothing* to the samples, the interface
  can move a few Msps.  That goes down quickly as you actually have to do anything to the samples.  The E310 has a larger FPGA, and the
  "marketted use case" is to do most processing in the FPGA.

Now, as to why, at lower rates, you cannot decode, that's a debugging exercise perhaps not related, per se, to the E310, but just
  the experimental setup.

How are the two radios "connected" -- via antennae or a cable?  If cable, make sure you have plenty of attenuation in-line (30-40dB),
  otherwise you risk damage to the receiver at worst, and at best, driving the receive chain into non-linearity, producing distortions and
  unwanted mixing products within the first gain stage(s).



On Tue, Jun 23, 2020 at 12:03 PM Marcus D Leech <patchvonbraun@gmail.com> wrote:
What sample rate ranges have you tried?

Sent from my iPhone

On Jun 23, 2020, at 12:57 PM, Cameron Matson <ncmatson95@gmail.com> wrote:


Hello all,

I'm new to gnuradio and SDR so I hope there isn't something obvious I'm missing.  I'm trying to get a packet based system set up.  I'm using gnuradio 3.7 and UHD 3.14 that I cross compiled and loaded onto two E312s.

I'm trying to use the uhd_packet_tx and uhd_packet_rx examples as a staring point.  I made the necessary modifications to run it as a non-gui flowgraph, but left all the variables untouched.  Both the flow graphs run, but:
  • the Tx flow graph shows an initial tG flag and then a  U flag after every burst (which I understand has something to do with tag offsets mismatching https://github.com/gnuradio/gnuradio/issues/1976)
  • The Rx flow graph immediately starts outputing O flags, and no packets are recieved.
I've tried playing around with the frequency and sampling rates without much success.

Any help on where to start would be greatly appreciated.

Thanks,
Cameron


reply via email to

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