Hi, I just pushed a commit to github.
Would be great, if you could update the module and let me know if that fixes your problem. Best, Bastian > On 01 Mar 2016, at 15:25, Abhinav Jadon <abhinav12...@iiitd.ac.in> wrote: > > Hi , > Sorry for the delay in following up. Had mid semester exams to prepare for. > I have a 8GB RAM Core i7 PC. Just to be sure that this wasn't a PC issue. I > ran it on a 16GB RAM Core i5 PC. Same issue propped up. So that leaves out > the memory leak option. > > 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 Sun, Feb 21, 2016 at 3:34 AM, Bastian Bloessl <bloe...@ccs-labs.org > <mailto:bloe...@ccs-labs.org>> wrote: > Hi, > >> On 20 Feb 2016, at 12:05, Abhinav Jadon <abhinav12...@iiitd.ac.in >> <mailto:abhinav12...@iiitd.ac.in>> wrote: >> >> >> new mac frame (length 10) >> ========================================= >> frame too short to parse (<20) >> thread[thread-per-block[3]: <block ofdm_mac (30)>]: std::bad_alloc >> [Thread 0x7fffad60d700 (LWP 4907) exited] > > > Looks like you run out of memory :-/ > > How much memory does your PC have? > > If it’s not your PC, it’s a memory leak. Unfortunately, I’ve never had memory > problems (for simulations, I often start up to 10 instances in parallel…) > > If you have a decent PC and still have problems, you could try valgrind to > debug potential memory leaks or compile the module with debug symbols. Maybe > this reveals more information about what’s going wrong. > > Best, > Bastian > > >> >> >> >> On Thu, Feb 18, 2016 at 4:44 AM, Bastian Bloessl <bloe...@ccs-labs.org >> <mailto:bloe...@ccs-labs.org>> wrote: >> Hi, >> >>> On 17 Feb 2016, at 11:45, Abhinav Jadon <abhinav12...@iiitd.ac.in >>> <mailto: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
