[Discuss-gnuradio] gr-radar make issue
Hi , I use an Ubuntu 14.04 machine. 64 bit processor. UHD version 003.010 | QWT version 6.0.0 | Boost version 1.54 When i run the cmake command, everything gets built just fine (no errors). But when I open the flowgraphs in the examples folder, there are some gr-radar blocks that are not identified by grc ( probably they were not built properly). Also, 21 out of the 27 ctests are failures. Any help would be appreciated. Regards Abhinav Jadon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM Constellation Issue
Hi, I made two flowgraphs. 1st flowgraph : Source -> BPSK modulation -> Constellation Sink 2nd flowgraph : Source -> BPSK modulation -> IFFT -> FFT -> Constellation Sink The source is configured such that if only transmits 1s. Therefore one would expect the constellation plot to have one dot on the x-axis around the point (1,0). This is what happens :) But in the second flowgraph one would expect the same result but the flowgraph is not what it should look like. The link for the screenshots : https://drive.google.com/folderview?id=0Bwh_xvBu7PpWaTRZX0VqQzBxNU0&usp=sharing p1 and p2 correspond to the second flowgraph Regards Abhinav Jadon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] IEEE 802.11 Transmitter in X310s
Hi, My setup consists of two X310s - one transmitter and one receiver - connected with SMA cable. The receiver code has been independently tested by capturing the AP packets. The transmitter code was tested in a software loopback with the receiver. The gains on both sides were adjusted such that there was no clipping. attenuator (-10db) were used to connect the two USRPs over SMA link. The transmitter transmits the packet but at the receiver end, these packets are not successfully decoded. A deeper look reveals that for a high correlation value (0.8) , packets are being detected by the packet detection mechanism but the signal field is decoded wrongly in all the packets detected. . Since unit testing of every block was successful, it was my hypothesis that the source of error lies on the transmitter-hardware side. I began scraping thorough the mail archives and got hold of this : http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-September/015576.html This thread details on the problem related to burst transmissions in X310. Apparently, the successive bursts are not same - the end of first burst is appended to the second burst. I don't have the hardware to verify the claim, but assuming that it is correct. It still doesn't explain the wrong decoding of the signal field. What am I missing ? Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11 transceiver issue
The overflow warning occurs when the period parameter is set to 1 for a pdu_length of 100. The rate is around 1.9e6. I am sorry but I didn't get the point of this exercise. Were you trying to figure out the optimal value of the buffer size ? Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Thu, Mar 31, 2016 at 1:51 PM, Marcus Müller wrote: > What probably would be even more insightful is if you could enable > ctrlport and add a ctrlport monitor to your flow graph; that way we could > see whether the output buffer of OFDM mapper is constantly full. > > On 31.03.2016 10:13, Marcus Müller wrote: > > Hi Abhinav, > > On 31.03.2016 02:42, Abhinav Jadon wrote: > > I ran the volk_profile just after the installation so that is not an issue > i guess. Also, I played around with the parameters of the message strobe ( > the period parameter), it did have an effect on the underruns and the async > message buffer overflow warning. Low values of the period parameter > prompted async message overflow warnings and high values of the period > parameter prompted underruns ( a lot of them) . > > Sooo, ok. > My head was stuck on UHD/the USRP being a problem here, but: > "asynchronous message buffer overflowing, dropping message" > is a GNU Radio warning! > So what happens here is that messages are sent to a block that's not > processing them fast enough, and at some point, the message buffer just > gets too big. > There's basically two candidates for this, because your message passing > chain is: > > Message Strobe-> OFDM MAC->OFDM Mapper(->stream) > > so my guess is that this happens at the OFDM Mapper, because that is the > block whose message processing rate is limited by the amount of samples it > can produce, which is defined by how fast the USRP sink consumes those, in > the end. > > Quick test: Take the "Message Strobe -> OFDM MAC -> OFDM Mapper" and just > attach a "->Probe Rate->Message Debug". > How many items per second do your generate with the settings you use when > you get a lot of the "async mess. buff. overflow" warnings?" > > Best regards, > Marcus > > What I dont understand is if the USRP is in the burst mode, why does the > period parameter change things ? If the USRP is set to sample rate of 20e6, > then it expects period*sample_rate samples to be supplied to it. That > requires to change the length of the message again. > Whats wrong here ? > > Regards > > Abhinav PS Jadon > 2012122 > Electronics and Communication Engineering Undergraduate > IIIT - Delhi > IASc Summer Research Fellow 2015 > *E*: jadonabhi...@gmail.com > *M*: +919650936845 > > > > On Wed, Mar 30, 2016 at 3:48 AM, Marcus Müller > wrote: > >> Did you run volk_profile? That one tries out all volk kernels, and notes >> down which one works best on your PC, so they'll be used automatically the >> next time. Maybe that increases performance! >> >> >> On 29.03.2016 22:24, Abhinav Jadon wrote: >> >> gcc version is 4.8.4 >> cpuinfo output : >> flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca >> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx >> pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl >> xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor >> ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic >> movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida >> arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase >> tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt >> >> Since sse4_2 figures in the list and all the SIMD architectures are >> backward compatible, i think its right to say that sse4_2 is the answer we >> are looking for ? >> >> Also , >> gnuradio version - '3.7.9.1' >> volk version - is in latest version as I pulled it from github yesterday. >> >> Abhinav PS Jadon >> 2012122 >> Electronics and Communication Engineering Undergraduate >> IIIT - Delhi >> IASc Summer Research Fellow 2015 >> *E*: jadonabhi...@gmail.com >> *M*: +919650936845 >> >> >> >> On Wed, Mar 30, 2016 at 1:27 AM, Alexander Levedahl < >> alexanderleved...@gmail.com> wrote: >> >>> Abhinav, >>> >>> I am not certain what to make of the asynch message buffer overflowing. >>> >>> The __SSE2_MATH__, __SSE_MATH__, __SSE2__, __S
Re: [Discuss-gnuradio] 802.11 transceiver issue
I ran the volk_profile just after the installation so that is not an issue i guess. Also, I played around with the parameters of the message strobe ( the period parameter), it did have an effect on the underruns and the async message buffer overflow warning. Low values of the period parameter prompted async message overflow warnings and high values of the period parameter prompted underruns ( a lot of them) . What I dont understand is if the USRP is in the burst mode, why does the period parameter change things ? If the USRP is set to sample rate of 20e6, then it expects period*sample_rate samples to be supplied to it. That requires to change the length of the message again. Whats wrong here ? Regards Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Wed, Mar 30, 2016 at 3:48 AM, Marcus Müller wrote: > Did you run volk_profile? That one tries out all volk kernels, and notes > down which one works best on your PC, so they'll be used automatically the > next time. Maybe that increases performance! > > > On 29.03.2016 22:24, Abhinav Jadon wrote: > > gcc version is 4.8.4 > cpuinfo output : > flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx > pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl > xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor > ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic > movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida > arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase > tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt > > Since sse4_2 figures in the list and all the SIMD architectures are > backward compatible, i think its right to say that sse4_2 is the answer we > are looking for ? > > Also , > gnuradio version - '3.7.9.1' > volk version - is in latest version as I pulled it from github yesterday. > > Abhinav PS Jadon > 2012122 > Electronics and Communication Engineering Undergraduate > IIIT - Delhi > IASc Summer Research Fellow 2015 > *E*: jadonabhi...@gmail.com > *M*: +919650936845 > > > > On Wed, Mar 30, 2016 at 1:27 AM, Alexander Levedahl < > alexanderleved...@gmail.com> wrote: > >> Abhinav, >> >> I am not certain what to make of the asynch message buffer overflowing. >> >> The __SSE2_MATH__, __SSE_MATH__, __SSE2__, __SSE__ defines are the SIMD >> preprocessor defines. Can you run gcc --version and do cat /proc/cpuinfo | >> grep flags? The former will indicate the gcc version number. The latter >> will indicate what SIMD instructions the processor actually supports. Also >> do you know what version of VOLK and gnuradio you have? >> >> On Tue, Mar 29, 2016 at 3:50 PM, Abhinav Jadon < >> abhinav12...@iiitd.ac.in> wrote: >> >>> Hi Alex , >>> The output in the console was all 'U's before I disabled the WX/GUI >>> blocks. >>> Now, it seems to run fine initially before throwing this message : >>> >>> "WARN: asynchronous message buffer overflowing, dropping message" >>>> >>> >>> >>> >>> The output of gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX" was : >>> #define __USER_LABEL_PREFIX__ >>> #define __SSE2_MATH__ 1 >>> #define __ATOMIC_HLE_RELEASE 131072 >>> #define __SSE_MATH__ 1 >>> #define __SSE2__ 1 >>> #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1 >>> #define __SSE__ 1 >>> #define __ATOMIC_SEQ_CST 5 >>> #define __ATOMIC_RELEASE 3 >>> >>> >>> I have an idea about what SIMD is, although I could not find any SIMD >>> preprocessor defines. >>> Am I missing something here? >>> >>> Abhinav PS Jadon >>> 2012122 >>> Electronics and Communication Engineering Undergraduate >>> IIIT - Delhi >>> IASc Summer Research Fellow 2015 >>> *E*: jadonabhi...@gmail.com >>> *M*: +919650936845 >>> >>> >>> >>> On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl < >>> alexanderleved...@gmail.com> wrote: >>> >>>> Abhinav, >>>> >>>> When you run the flowgraph, can you look at system monitor? This will >>>> give some indication whether the problem is that all the cores are pegged >>>> or if RAM is filling up. >>>> A couple of other things to look at: >>>> 1) Is ther
Re: [Discuss-gnuradio] 802.11 transceiver issue
gcc version is 4.8.4 cpuinfo output : flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt Since sse4_2 figures in the list and all the SIMD architectures are backward compatible, i think its right to say that sse4_2 is the answer we are looking for ? Also , gnuradio version - '3.7.9.1' volk version - is in latest version as I pulled it from github yesterday. Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Wed, Mar 30, 2016 at 1:27 AM, Alexander Levedahl < alexanderleved...@gmail.com> wrote: > Abhinav, > > I am not certain what to make of the asynch message buffer overflowing. > > The __SSE2_MATH__, __SSE_MATH__, __SSE2__, __SSE__ defines are the SIMD > preprocessor defines. Can you run gcc --version and do cat /proc/cpuinfo | > grep flags? The former will indicate the gcc version number. The latter > will indicate what SIMD instructions the processor actually supports. Also > do you know what version of VOLK and gnuradio you have? > > On Tue, Mar 29, 2016 at 3:50 PM, Abhinav Jadon > wrote: > >> Hi Alex , >> The output in the console was all 'U's before I disabled the WX/GUI >> blocks. >> Now, it seems to run fine initially before throwing this message : >> >> "WARN: asynchronous message buffer overflowing, dropping message" >>> >> >> >> >> The output of gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX" was : >> #define __USER_LABEL_PREFIX__ >> #define __SSE2_MATH__ 1 >> #define __ATOMIC_HLE_RELEASE 131072 >> #define __SSE_MATH__ 1 >> #define __SSE2__ 1 >> #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1 >> #define __SSE__ 1 >> #define __ATOMIC_SEQ_CST 5 >> #define __ATOMIC_RELEASE 3 >> >> >> I have an idea about what SIMD is, although I could not find any SIMD >> preprocessor defines. >> Am I missing something here? >> >> Abhinav PS Jadon >> 2012122 >> Electronics and Communication Engineering Undergraduate >> IIIT - Delhi >> IASc Summer Research Fellow 2015 >> *E*: jadonabhi...@gmail.com >> *M*: +919650936845 >> >> >> >> On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl < >> alexanderleved...@gmail.com> wrote: >> >>> Abhinav, >>> >>> When you run the flowgraph, can you look at system monitor? This will >>> give some indication whether the problem is that all the cores are pegged >>> or if RAM is filling up. >>> A couple of other things to look at: >>> 1) Is there any text being printed to the console? >>> 2) What happens if you disable the GUI blocks? Simple method would be >>> to open the flowgraph select the blocks that have GUIs associated with >>> them, hit D (for disable) and then run the graph. >>> 3) Would you happen to know which SIMD instructions it is using? Run >>> gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX" >>> The gcc -dM -E will print out the preprocessor defines. The - < >>> /dev/null forces gcc to exit immediately. The "SE" flag filters the >>> preprocessor defines for any of the SSEE SIMD instructions; the "AVX" flag >>> filters for the AVX SIMD instructions. >>> >>> >>> Sometimes the processor supports SIMD instructions that the compiler >>> (due to age) does not support. >>> >>> Alex >>> >>> >>> On Tue, Mar 29, 2016 at 2:57 PM, Marcus Müller >> > wrote: >>> >>>> That's pretty much impossible to say. >>>> My prime suspect would be the WX Gui visualization sink. Really, a >>>> couple of 64 FFTs aren't that terrible performance-wise. >>>> >>>> >>>> On 29.03.2016 20:53, Abhinav Jadon wrote: >>>> >>>> Marcus, >>>> Thanks for all the help. >>>> But Is my system underpowered ? >>>> Also, I just observed that if I bunch few blocks in the tx flowgraph in >>>> a similar way as phy_h
Re: [Discuss-gnuradio] 802.11 transceiver issue
Hi Alex , The output in the console was all 'U's before I disabled the WX/GUI blocks. Now, it seems to run fine initially before throwing this message : "WARN: asynchronous message buffer overflowing, dropping message" > The output of gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX" was : #define __USER_LABEL_PREFIX__ #define __SSE2_MATH__ 1 #define __ATOMIC_HLE_RELEASE 131072 #define __SSE_MATH__ 1 #define __SSE2__ 1 #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1 #define __SSE__ 1 #define __ATOMIC_SEQ_CST 5 #define __ATOMIC_RELEASE 3 I have an idea about what SIMD is, although I could not find any SIMD preprocessor defines. Am I missing something here? Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Wed, Mar 30, 2016 at 12:42 AM, Alexander Levedahl < alexanderleved...@gmail.com> wrote: > Abhinav, > > When you run the flowgraph, can you look at system monitor? This will > give some indication whether the problem is that all the cores are pegged > or if RAM is filling up. > A couple of other things to look at: > 1) Is there any text being printed to the console? > 2) What happens if you disable the GUI blocks? Simple method would be to > open the flowgraph select the blocks that have GUIs associated with them, > hit D (for disable) and then run the graph. > 3) Would you happen to know which SIMD instructions it is using? Run > gcc -dM -E - < /dev/null | grep -e "SE" -e "AVX" > The gcc -dM -E will print out the preprocessor defines. The - < /dev/null > forces gcc to exit immediately. The "SE" flag filters the preprocessor > defines for any of the SSEE SIMD instructions; the "AVX" flag filters for > the AVX SIMD instructions. > > > Sometimes the processor supports SIMD instructions that the compiler (due > to age) does not support. > > Alex > > > On Tue, Mar 29, 2016 at 2:57 PM, Marcus Müller > wrote: > >> That's pretty much impossible to say. >> My prime suspect would be the WX Gui visualization sink. Really, a couple >> of 64 FFTs aren't that terrible performance-wise. >> >> >> On 29.03.2016 20:53, Abhinav Jadon wrote: >> >> Marcus, >> Thanks for all the help. >> But Is my system underpowered ? >> Also, I just observed that if I bunch few blocks in the tx flowgraph in a >> similar way as phy_hier block in the wifi_loopback flowgraph, I dont >> receive any more underruns. >> >> >> Regards >> >> Abhinav PS Jadon >> 2012122 >> Electronics and Communication Engineering Undergraduate >> IIIT - Delhi >> IASc Summer Research Fellow 2015 >> *E*: jadonabhi...@gmail.com >> *M*: +919650936845 >> >> >> >> On Wed, Mar 30, 2016 at 12:17 AM, Marcus Müller > > wrote: >> >>> When you set the length tag field in the USRP sink, it starts looking >>> for that stream tag, which contains number of samples in the starting burst. >>> >>> Technically, that starts a uhd::tx_streamer for a finite number of >>> samples, which means different things for different hardware. >>> >>> Best regards, >>> Marcus >>> >>> >>> On 29.03.2016 20:44, Abhinav Jadon wrote: >>> >>> Hi Marcus, >>> I am working on a Core i7 8GB system, I dont know if its underpowered, >>> if it is I have access to another Corei5 16 GB station. >>> I know this is going to sound dumb but, >>> how does the USRP sink go into burst mode, I was under the impression >>> that USRP could only transmit data continuously. Do you toggle the RF >>> frontend using a switch on receiving a message ? >>> >>> >>> >>> Regards >>> Abhinav PS Jadon >>> >>> >>> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Data Formatting in GNURadio (WiFi)
I am using the floating type values to generate the samples using matlab. Am I correct in assuming that gr_complex = float16(half-precision IEEE 754) + iota*float16(the Q sample) ? Regards Abhinav PS Jadon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11 transceiver issue
Marcus, Thanks for all the help. But Is my system underpowered ? Also, I just observed that if I bunch few blocks in the tx flowgraph in a similar way as phy_hier block in the wifi_loopback flowgraph, I dont receive any more underruns. Regards Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Wed, Mar 30, 2016 at 12:17 AM, Marcus Müller wrote: > When you set the length tag field in the USRP sink, it starts looking for > that stream tag, which contains number of samples in the starting burst. > > Technically, that starts a uhd::tx_streamer for a finite number of > samples, which means different things for different hardware. > > Best regards, > Marcus > > > On 29.03.2016 20:44, Abhinav Jadon wrote: > > Hi Marcus, > I am working on a Core i7 8GB system, I dont know if its underpowered, if > it is I have access to another Corei5 16 GB station. > I know this is going to sound dumb but, > how does the USRP sink go into burst mode, I was under the impression that > USRP could only transmit data continuously. Do you toggle the RF frontend > using a switch on receiving a message ? > > > > Regards > Abhinav PS Jadon > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.11 transceiver issue
Hi Marcus, I am working on a Core i7 8GB system, I dont know if its underpowered, if it is I have access to another Corei5 16 GB station. I know this is going to sound dumb but, how does the USRP sink go into burst mode, I was under the impression that USRP could only transmit data continuously. Do you toggle the RF frontend using a switch on receiving a message ? Regards Abhinav PS Jadon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 802.11 transceiver issue
Hi , I was working on the transmitter of gr-ieee80211. I will first explain my setup and then go on to detail the problem. Setup : X310 (transmitter) -> SMA cable -> Attenuator -> SMA cable -> X310 (receiver) The transmitter runs the wifi_tx.grc. The receiver runs the wifi_rx.grc The tx gain was intelligently set to 10 db . Same goes for rx gain. The attenuation was set to -10db The gains and attenuation value were set after conducting a small experiment where the transmitter was transmitting a sin wave of 0.8 amplitude and while the attenuation and tx gain were fixed, the value of rx gain was varied to see up till what value the received signal is not distorted. The packet that was being transmitted by the transmitter was seen on a WX GUI scope sink and was consequently multiplied with an appropriate constant value to scale the max of the amplitude of the packet to 0.8. The TX and RX chains were checked using the wifi_loopback flowgraph. Now , The problem is that on the TX front, the flowgraph throws a lot of Underruns, my understanding is that the samples are not being created at the rate hardware is expecting them to be generated. The USRP block is configured on 20e6 sample rate in accordance with the Wifi Standard. An educated guess is to increase the output of the flowgraph to the rate hardware is expecting. The message strobe block then needs to be configured to he expected rate but it exceeds the maximum pdu length. I modified the tx and rx flowgraphs a bit, so here are the links to the flowgraphs : https://drive.google.com/file/d/0Bwh_xvBu7PpWaEZobF9KX1NMaTA/view?usp=sharing :wifi_rx https://drive.google.com/file/d/0Bwh_xvBu7PpWUGJzT2ItU0p3OE0/view?usp=sharing :wifi_tx Regards Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Data Formatting in GNURadio (WiFi)
Hi, I wrote a matlab scripts that generates the wifi packets for a given payload. The output is of the format I dumped the output in a bin file. It is my understanding that the complex type file source reads the input (bin) file in a gr_complex data type format ie reading 32 bits from the bin file at a time and then converting the first 16bits (corresponding to real part/I) and last 16bits (corresponding to img part/Q) to float16 format and thus with this understanding, I formatted the data accordingly while dumping the data into the bin file. The issue is I plug that file source on repeat mode to the UHD block. The packet is not detected on the receiver side.Is there something wrong with my understanding of data formatting ? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue
Hi, Updated the module, the same problem persists although this time the transmitter took longer than usual to turn off. Cheers Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Wed, Mar 2, 2016 at 5:09 AM, Bastian Bloessl 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 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 > *M*: +919650936845 > > > > On Sun, Feb 21, 2016 at 3:34 AM, Bastian Bloessl > wrote: > >> Hi, >> >> On 20 Feb 2016, at 12:05, Abhinav Jadon wrote: >> >> >> new mac frame (length 10) >> = >> frame too short to parse (<20) >> thread[thread-per-block[3]: ]: 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 >> wrote: >> >>> Hi, >>> >>> On 17 Feb 2016, at 11:45, Abhinav Jadon >>> 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 >>> *M*: +919650936845 >>> >>> >>> >>> On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl >>> wrote: >>> >>>> Hi, >>>> >>>> >>>> On 14 Feb 2016, at 14:46, Abhinav Jadon >>>> wrote: >>>> >>>> >>>> There are no overruns and the connections to the antenna ports are >>>> correct. >>>> The frame detection is working &
Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue
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 *M*: +919650936845 On Sun, Feb 21, 2016 at 3:34 AM, Bastian Bloessl wrote: > Hi, > > On 20 Feb 2016, at 12:05, Abhinav Jadon wrote: > > > new mac frame (length 10) > = > frame too short to parse (<20) > thread[thread-per-block[3]: ]: 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 > wrote: > >> Hi, >> >> On 17 Feb 2016, at 11:45, Abhinav Jadon 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 >> *M*: +919650936845 >> >> >> >> On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl >> wrote: >> >>> Hi, >>> >>> >>> On 14 Feb 2016, at 14:46, Abhinav Jadon >>> 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 >>> >>>
Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue
oving_average_" 0x7476a270 in gettimeofday@plt () from /usr/local/lib/libgnuradio-runtime-3.7.8.so.0.0.0 45 Thread 0x7fff817fa700 (LWP 4914) "multiply_cc20" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 44 Thread 0x7fff81ffb700 (LWP 4913) "conjugate_cc24" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 43 Thread 0x7fff827fc700 (LWP 4912) "delay22" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 42 Thread 0x7fff82ffd700 (LWP 4911) "moving_average_" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 41 Thread 0x7fff837fe700 (LWP 4910) "complex_to_mag2" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 40 Thread 0x7fff83fff700 (LWP 4909) "gr uhd usrp so2" 0x778e8337 in ioctl () at ../sysdeps/unix/syscall-template.S:81 39 Thread 0x7ffface0c700 (LWP 4908) "ofdm_parse_mac2" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 37 Thread 0x7fffade0e700 (LWP 4906) "file_sink36" pthread_cond_timedwait@@GL---Type to continue, or q to quit--- IBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 36 Thread 0x7fffae60f700 (LWP 4905) "python" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 35 Thread 0x7fffaf7fe700 (LWP 4904) "wireshark_conn3" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 34 Thread 0x7fffa700 (LWP 4903) "message_strobe3" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 25 Thread 0x7fffb7fff700 (LWP 4893) "python" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 23 Thread 0x7fffb4a5a700 (LWP 4878) "python" 0x778f1b13 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 13 Thread 0x7fffb77fe700 (LWP 4867) "pool" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 11 Thread 0x7fffc48f5700 (LWP 4865) "gmain" 0x778e412d in poll () at ../sysdeps/unix/syscall-template.S:81 10 Thread 0x7fffc5a51700 (LWP 4864) "gdbus" 0x778e412d in poll () at ../sysdeps/unix/syscall-template.S:81 9Thread 0x7fffc6252700 (LWP 4863) "dconf worker" 0x778e412d in poll () at ../sysdeps/unix/syscall-template.S:81 8Thread 0x7fffe0f95700 (LWP 4862) "python" pthread_cond_wait@ @GLIBC_2.3.2 ---Type to continue, or q to quit--- () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 7Thread 0x7fffe3796700 (LWP 4861) "python" pthread_cond_wait@ @GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 6Thread 0x7fffe5f97700 (LWP 4860) "python" pthread_cond_wait@ @GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 5Thread 0x7fffe8798700 (LWP 4859) "python" pthread_cond_wait@ @GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 4Thread 0x7fffeaf99700 (LWP 4858) "python" pthread_cond_wait@ @GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 3Thread 0x7fffed79a700 (LWP 4857) "python" pthread_cond_wait@ @GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 2Thread 0x7fffedf9b700 (LWP 4856) "python" pthread_cond_wait@ @GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 * 1Thread 0x77fc2740 (LWP 4854) "4907" 0x778e412d in poll () at ../sysdeps/unix/syscall-template.S:81 Regards Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Thu, Feb 18, 2016 at 4:44 AM, Bastian Bloessl wrote: > Hi, > > On 17 Feb 2016, at 11:45, Abhinav Jadon 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 >
Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue
Hi Bastian , There is another issue regarding the same topic I would like to bring to the fore. I use a pair of X310. Due to some constraints, I shifted to one X310. 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. 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 flowgraph. 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. Regards Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Mon, Feb 15, 2016 at 9:51 AM, Bastian Bloessl wrote: > Hi, > > > On 14 Feb 2016, at 14:46, Abhinav Jadon 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 > wrote: > >> Hi >> >> > On 10 Feb 2016, at 15:13, Abhinav Jadon >> 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
[Discuss-gnuradio] Seeking word of advise on gr-ieee802.11n
Hi, I was wondering what are the major bottlenecks to the implementation of the MIMO WIFI standard on Gnuradio ? Regards Abhinav Jadon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue
Hi Bastian, There are no overruns and the connections to the antenna ports are correct. The frame detection is working 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 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 ? Regards Abhinav PS Jadon 2012122 Electronics and Communication Engineering Undergraduate IIIT - Delhi IASc Summer Research Fellow 2015 *E*: jadonabhi...@gmail.com *M*: +919650936845 On Thu, Feb 11, 2016 at 6:13 AM, Bastian Bloessl wrote: > Hi > > > On 10 Feb 2016, at 15:13, Abhinav Jadon > 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
[Discuss-gnuradio] GNU Radio Architecture and Implementation ?
Hi , I was reading up about the architecture of GNU Radio. Its primarily an inheritance based architecture, the blocks that pass data to other block are actually implemented as subclass and superclass pair. Am I right about this? Also whats the need for the flowgraph to be a subclass of the top_block. Also, whats the difference between top_block and block ? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-ieee 802.11 Wifi Transceiver Issue
Hi , I was working on the Wifi Transceiver Flowgraph. I created a loopback in the flowgraph itself to be sure that atleast the transceiver works in theory. It did work like magic. 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. Can you please provide your feedback on this ? Regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scanning frequency GSM
Hi Marcus, I was reading your reply. I had implemented a similar system but on a different band (TV). I did not understand this section of your reply. If you actually want to retune (e.g. because your device bandwidth is > smaller than the Downlink you want to find unused channels in, or > because you want to do EGSM900 and 1800), then things get slightly more > complicated, and you'll probably end up using message passing and stream > tags. Still not "complex", but not as conceptually trivial. > Why do we require message passing and stream tags for scanning a frequency band ? Aren't they supposed to be used for decoding bursty data/communication ? Can you please elaborate on this further ? Thanks Abhinav PS Jadon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] build-gnuradio script issue
HI , I was installing gnuradio on a new system today using the build-gnuradio script. I encountered an unexpected error . [ 85%] Building CXX object > gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o > /home/usrp-1/Documents/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx: > In function ‘void init_uhd_swig()’: > /home/usrp-1/Documents/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46693:91: > error: ‘ATR_REG_IDLE’ is not a member of ‘uhd::usrp::dboard_iface’ >SWIG_Python_SetConstant(d, > "dboard_iface_ATR_REG_IDLE",SWIG_From_int(static_cast< int > >(uhd::usrp::dboard_iface::ATR_REG_IDLE))); > > ^ > /home/usrp-1/Documents/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46694:94: > error: ‘ATR_REG_TX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’ >SWIG_Python_SetConstant(d, > "dboard_iface_ATR_REG_TX_ONLY",SWIG_From_int(static_cast< int > >(uhd::usrp::dboard_iface::ATR_REG_TX_ONLY))); > > ^ > /home/usrp-1/Documents/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46695:94: > error: ‘ATR_REG_RX_ONLY’ is not a member of ‘uhd::usrp::dboard_iface’ >SWIG_Python_SetConstant(d, > "dboard_iface_ATR_REG_RX_ONLY",SWIG_From_int(static_cast< int > >(uhd::usrp::dboard_iface::ATR_REG_RX_ONLY))); > > ^ > /home/usrp-1/Documents/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:46696:98: > error: ‘ATR_REG_FULL_DUPLEX’ is not a member of ‘uhd::usrp::dboard_iface’ >SWIG_Python_SetConstant(d, > "dboard_iface_ATR_REG_FULL_DUPLEX",SWIG_From_int(static_cast< int > >(uhd::usrp::dboard_iface::ATR_REG_FULL_DUPLEX))); > > ^ > make[2]: *** > [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/uhd_swigPYTHON_wrap.cxx.o] Error 1 > make[1]: *** [gr-uhd/swig/CMakeFiles/_uhd_swig.dir/all] Error 2 > make: *** [all] Error 2 > make failed > Exiting Gnu Radio build/install > So clearly there is something wrong with the SWIG installation I suppose. Also , this system had ROS installed while the system I had been working on did not have ROS installed. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] AttributeError: 'module' object has no attribute 'hamming'
Hi ,
Sorry for not providing all the info . I dont know what happened to the
link though .
I used gr_modtool to create the OOT module ;
I wrote the module in C++ and i am using GNU Radio 3.7.6
I have created a git repository :
https://github.com/Jadoobaba/gr-wsi/tree/master/Documents/gr-wsi
ldd on the .so file has the following output .
iiitd@iiitd-ThinkPad-W530:/usr/local/lib$ ldd libgnuradio-wsi.so
linux-vdso.so.1 => (0x7fffc59fe000)
libboost_system.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.53.0 (0x7f79fc959000)
libgnuradio-runtime-3.7.6.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-runtime-3.7.6.1.so.0.0.0 (0x7f79fc689000)
libgnuradio-pmt-3.7.6.1.so.0.0.0 =>
/usr/local/lib/libgnuradio-pmt-3.7.6.1.so.0.0.0 (0x7f79fc44)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f79fc13c000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f79fbf26000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f79fbb5d000)
libvolk.so.0.0.0 => /usr/local/lib/libvolk.so.0.0.0 (0x7f79fb80f000)
libboost_filesystem.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.53.0 (0x7f79fb5f9000)
libboost_thread.so.1.53.0 =>
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.53.0 (0x7f79fb3e2000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f79fb1c5000)
liblog4cpp.so.5 => /usr/lib/liblog4cpp.so.5 (0x7f79faf85000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f79fad7c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f79faa78000)
/lib64/ld-linux-x86-64.so.2 (0x7f79fcd87000)
liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0
(0x7f79fa7f8000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f79fa5de000)
While running gdb --args python hamming.py has the following result .
(gdb) run
Starting program: /usr/bin/python hamming.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe2576700 (LWP 4704)]
[New Thread 0x7fffe1d75700 (LWP 4705)]
[New Thread 0x7fffe0a9a700 (LWP 4706)]
[New Thread 0x7fffd3fff700 (LWP 4707)]
[New Thread 0x7fffd37fe700 (LWP 4708)]
Traceback (most recent call last):
File "hamming.py", line 62, in
tb = hamming()
File "hamming.py", line 33, in __init__
self.wsi_hamming_0 = wsi.hamming(3)
AttributeError: 'module' object has no attribute 'hamming'
[Thread 0x7fffd37fe700 (LWP 4708) exited]
[Thread 0x7fffe0a9a700 (LWP 4706) exited]
[Thread 0x7fffe1d75700 (LWP 4705) exited]
[Thread 0x7fffe2576700 (LWP 4704) exited]
[Thread 0x7ffff7fd6740 (LWP 4699) exited]
[Inferior 1 (process 4699) exited with code 01]
Thanks in advance
Abhinav Jadon
On Tue, Feb 17, 2015 at 8:37 PM, Tom Rondeau wrote:
> On Sat, Feb 14, 2015 at 6:41 PM, Richard Bell
> wrote:
>
>> I ran into this myself with a custom Python block. I was unable to
>> resolve it. I gave up. Interested to learn a fix as well.
>>
>
> I don't think this is a Python block since he's linking against ITPP, but
> it's not specified in his original question, so I can't be sure.
>
> Anyways, I just tried making a Python block in an OOT project and it works
> just fine.
>
> $ gr_modtool nm
> Name of the new module: testpy
> Creating out-of-tree module in ./gr-testpy... Done.
> Use 'gr_modtool add' to add a new block to this currently empty module.
>
> $ cd gr-testpy
> $ gr_modtool add
> GNU Radio module name identified: testpy
> ('sink', 'source', 'sync', 'decimator', 'interpolator', 'general',
> 'tagged_stream', 'hier', 'noblock')
> Enter block type: sync
> Language (python/cpp): python
> Language: Python
> Enter name of block/code (without module name prefix): test01
> Block/code identifier: test01
> Enter valid argument list, including default arguments:
> Add Python QA code? [Y/n]
> Adding file 'python/test01.py'...
> Adding file 'python/qa_test01.py'...
> Editing python/CMakeLists.txt...
> Adding file 'grc/testpy_test01.xml'...
> Editing grc/CMakeLists.txt...
>
>
>
> $ mkdir build; cd build
> $ cmake -DCMAKE_INSTALL_PREFIX=/opt/gr ../
> $ make
> $ make install
> $ ipython
> In [1]: import testpy
>
> In [2]: dir(testpy)
> Out[2]:
> ['__builtins__',
> '__doc__',
> '__file__',
> '__name__',
> '__package__',
> '__path__',
> 'test01']
>
> In [3]: a = testpy.test01()
>
>
>
> Worked fine. You're not the only person with this problem, but no one has
&
[Discuss-gnuradio] AttributeError: 'module' object has no attribute 'hamming'
Hi , I wrote a Out of Tree module for hamming code using ITPP library . It compiled when i ran the cmake.. , make and make install commands without error . I used the block in a flowgraph and the python script thus generated throws an error while executing it which looks like this . Traceback (most recent call last): File "/home/iiitd/Desktop/hamming.py", line 62, in tb = hamming() File "/home/iiitd/Desktop/hamming.py", line 33, in __init__ self.wsi_hamming_0 = wsi.hamming(3) AttributeError: 'module' object has no attribute 'hamming' I then checked the $PYTHONPATH and made sure it points to the directory where the files associated with the block are installed during make install ie /usr/local/lib/python2.7/dist-packages instead to /opt/qt/lib/python2.7/dist-packages . It would be really thankful if somebody helps me sort this out . The link to the my OOT code is https://www.dropbox.com/sh/8tstm4ckaphsis/AAD0cbS5eelaoaIe0gUExCBea?dl=0 Thanks Abhinav Jadon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Difference between QT/WX
Hi all , A basic doubt , i have been having since i started working on GR was what is the difference between QT and WX GUIs ? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU radio Image for NI-USRP 2943
Hi community , I was wondering if there is a FPGA image compatible with the NI-USRP 2943 available ? and how do i backup the pre-installed NI fpga image . Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
