Hi, > On 17 Feb 2016, at 11:45, Abhinav Jadon <abhinav12...@iiitd.ac.in> wrote:
> Upon running the transceiver code on a single X310, the transceiver shuts > down after few seconds of action (the LED ceases to blink) while the RX > continues to be up and decodes the packets. I can’t tell you much about the LEDs of the X310, but is there an error message, a seg fault, output from UHD (like ‘O's, ’T's, ‘D’s printed on the console), or any other indicator that something went wrong? Maybe start the flow graph in a debugger to get more information. If you use my Packet Pad block, try disabling the delay. > If I run only the RX ( replacing the UHD sink with a null sink), it continues > to decode the packet. > If I run only the TX ( replacing the UHD source with a null source), it > continues to transmit, the LED stays on until I stop the flow graph. What happens if you use just one transceiver flow graph (it has RX and TX)? > > I also ran simple tests (single tone transmission and reception) on the same > device. The TX and RX LEDs remain up until the flowgraph is stopped. This was > done at the behest of James Humpheris of Ettus Research. > I raised the issue on the Ettus mailing list and they asked me to put this up > on the GNURadio Mailing List. Just read the thread… I see... How about piping the samples to the UHD Sink also in a Tag Debug block or something to check whether samples are generated at all. Best, Bastian > Regards > > > Abhinav PS Jadon > 2012122 > Electronics and Communication Engineering Undergraduate > IIIT - Delhi > IASc Summer Research Fellow 2015 > E: jadonabhi...@gmail.com <mailto:jadonabhi...@gmail.com> > M: +919650936845 > > > > > On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl <bloe...@ccs-labs.org > <mailto:bloe...@ccs-labs.org>> wrote: > Hi, > > >> On 14 Feb 2016, at 14:46, Abhinav Jadon <abhinav12...@iiitd.ac.in >> <mailto:abhinav12...@iiitd.ac.in>> wrote: > >> There are no overruns and the connections to the antenna ports are correct. >> The frame detection is working > > Note, that this also means that frame detection is only triggered once per > frame. Sometimes, it can be triggered all the time (if there is a DC offset > or LO leakage for example). > Since you connected the devices via cable I would try to change LO offset of > sender and receiver. > (Btw, I guess you use attenuators) > >> >> I tried all the stuff you told me to try ie I tried LMS ansd LO offset, they >> worked as in I saw some packets being decoded by the wireshark connector. >> But the packet content was incorrect . Each packet decoded looked like this >> >> >> new mac frame (length 10) >> ========================================= >> frame too short to parse (<20) >> WIRESHARK: received new message >> message length 10 >> WIRESHARK: d_msg_offset: 0 to_copy: 43 d_msg_len 43 >> WIRESHARK: output size: 32768 produced items: 43 > > You should check in Wireshark if the content makes sense. I just implemented > a very minimal parser for demo purposes. > >> >> While the packet that is being transmitted has the following characteristics >> >> WIRESHARK: received new message >> message length 624 >> WIRESHARK: d_msg_offset: 0 to_copy: 657 d_msg_len 657 >> WIRESHARK: output size: 32768 produced items: 657 >> >> Is the signal field being wrongly interpreted ? > > That would be one thing to find out. The easiest way is to enable the log > option of the Decode Signal block (not the Wireshark block) to print what it > decoded. > > In general, I would recommend to try to find out where things break. (is the > frame detected, is the signal field decoded, does the constellation plot look > OK, etc.) > > Best, > Bastian > > >> >> >> >> On Thu, Feb 11, 2016 at 6:13 AM, Bastian Bloessl <bloe...@ccs-labs.org >> <mailto:bloe...@ccs-labs.org>> wrote: >> Hi >> >> > On 10 Feb 2016, at 15:13, Abhinav Jadon <abhinav12...@iiitd.ac.in >> > <mailto:abhinav12...@iiitd.ac.in>> wrote: >> > Next I replaced the loopback with a uhd source and sink and connected the >> > RF frontends using a SMA cable. It fails to give me any packet (the >> > wireshark connector). I tried playing with the value of rx_gain and >> > tx_gain. I also tried playing with the value of the the correlation >> > threshold. >> > I then chose to debug using the data flow. The data in the flowgraph flows >> > until the Decode MAC block where it gets dropped with checksum wrong >> > message. >> > >> >> Your debugging sounds already pretty good. Some more stuff you could try >> >> - assert that there are no overruns (‘O’s or ‘D’ on the console) >> - check that frame detection is working (there are no frames detected when >> the transmitter is turned off) >> - test with antennas >> - assert that you connected the correct antenna ports (RX and TX use a >> different ports by default) >> - set a different LO offset >> - use the LMS equaliser >> - try a different sample rate / bandwidth >> - check if the signal field is decoded correctly (log or debug option) >> >> Best, >> Bastian >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
