> On 01 Mar 2016, at 16:04, Abhinav Jadon <abhinav12...@iiitd.ac.in> wrote: > > Hi, > Updated the module, the same problem persists although this time the > transmitter took longer than usual to turn off.
I’m running a bit out of ideas :-/ Since I cannot reproduce the problem, it would be great if you could compile GNU Radio and the module with debug symbols and run the code in the debugger again. Also is the memory usage growing over time, i.e., are you really running out of memory? As far as I understand, that’s what bad_alloc means. If you send me your transmit flow graph, I can test your exact configuration and check for any obvious errors. Best, Bastian > > > Cheers > > 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 Wed, Mar 2, 2016 at 5:09 AM, Bastian Bloessl <bloe...@ccs-labs.org > <mailto:bloe...@ccs-labs.org>> wrote: > 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 >> <mailto: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
