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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> wrote: >> >>> What sample rate ranges have you tried? >>> >>> Sent from my iPhone >>> >>> On Jun 23, 2020, at 12:57 PM, Cameron Matson <[email protected]> >>> 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 >>> >>> >>
