Re: [Discuss-gnuradio] Compatible GNU Radio $500 2x2 full duplex MIMO SDR coming to a Kickstarter Shortly
To whom so ever it may concern... This work is been Patented and Copyrights are with Agile Solutions. This PCB Layout work and RF designs are panted work of Agile Solutions. We have the NDA signed by Xxillence Incorporate and we have started the legal action against them. Any sort of communication this way is illegal by Mr. Puspraj as per the NDA signed by him. Any kind proliferation of this work will be direct liability of XxiLLENCE Incorporate for compensations as per the law of the land. The claim of Mr. Puspraj is completely wrong as we have paid for this work. All the payment for this work has been done directly to him as we have all the bank transactions for proof. PS: Our new product lines are much better than ASRP1. We will be soon releasing new series of products offering better solutions and capabilities at same price of ASRP1. Martin O'Shield is closely working with us for creating a new and better SDR platforms. Regards Akash On 06-07-2013, Martin O'Shield wrote: Pusraj, Please reach me on my Mobile # 1-773-531-7312 If Akash really did this, and its been listed on his website since last year, I am not seeing how you wouldn't be aware of this, especially considering Akash mentioned this last year on this mailing list as well. We really need to talk as things are already in motion. Sincerely, Martin On Sat, Jul 6, 2013 at 2:01 AM, Puspraj Prasad Yadav wrote: Hi; Everybody reached me on below nos. I don’t know how you are not able to contact us. We are in the process of filing a patent in India and display on our own website as we have the design ownership. I have not received any details or any intimation regarding this update as we came to know today only. Regarding this we need to discuss. Thanks and Regards Puspraj CEO & Founder Xxillence Incorporate MOB#9449014171,9341714272,OFFICE#080-23195646 FAX NO-080-23195646 Mailto- puspraj@xxillence [4].in, i...@xxillence.in [5] No-29,Basement Floor,5th Cross,Ganesha Block,Nandini Layout,Bangalore-560096, Karnataka,INDIA "A winner is not who never fails,But who never quits" _ We have our own responsibilities to protect our planet.Act fast or preapare ourselves for the questions to be asked by the generations to come._ FROM: Martin O'Shield [mailto:mar...@windycitysdr.com [6]] SENT: Saturday, July 06, 2013 11:51 AM TO: Puspraj Prasad Yadav; discuss-gnuradio@gnu.org [7] SUBJECT: Re: [Discuss-gnuradio] Compatible GNU Radio $500 2x2 full duplex MIMO SDR coming to a Kickstarter Shortly Puspraj, Akash has had this listed for over 7 months, and I've just tried to reach you on both of the telephone #s you have listed on this post, which neither of them works. Did you patent any of this? And you can contact me off list as you've only replied here. Again, Akash has had this listed and announced on the GNU Radio mailing list and yet nothing from you to date? Did you patent this within India as I checked, believe me? Sincerely, Martin On Sat, Jul 6, 2013 at 12:21 AM, Puspraj Prasad Yadav wrote: Dear Sir ; We have the original schematic, board files, Gerber files, Assembly files, Bom . It is our design. The same things Akash Kosgi may have provided you. Because we worked with him. He was previously working as a partner is some company named as “Radion Technology”. But he has dismantled the company and run away with all the data with him. We had a tie up with Radion. But Mr. Akash Kosgi duped us and Radion also. You are a respected client . You must have verified the credentials of any individual before dealing with him. In India there are many people who claim to be genuine but somewhere they stole the data and try to sell overseas clients to make money. Thanks and Regards Puspraj CEO & Founder Xxillence Incorporate MOB#9449014171,9341714272,OFFICE#080-23195646 FAX NO-080-23195646 Mailto- puspraj@xxillence [9].in, i...@xxillence.in [10] No-29,Basement Floor,5th Cross,Ganesha Block,Nandini Layout,Bangalore-560096, Karnataka,INDIA "A winner is not who never fails,But who never quits" _We have our own responsibilities to protect our planet.Act fast or preapare ourselves for the questions to be asked by the generations to come._ FROM: Martin [mailto:mar...@windycitysdr.com [11]] SENT: Saturday, July 06, 2013 10:34 AM TO: Puspraj Prasad Yadav SUBJECT: Re: [Discuss-gnuradio] Compatible GNU Radio $500 2x2 full duplex MIMO SDR coming to a Kickstarter Shortly Pups raj, This is my first learning about this. Please provide me with proof. Sincerely,
Re: [Discuss-gnuradio] Compatible GNU Radio $500 2x2 full duplex MIMO SDR coming to a Kickstarter Shortly
Unfortunately, I have been traveling while these emails have been going on and just now got connected to respond. Please stop this email thread on the mailing list now. Any more emails about this subject and I will remove you from the list. This is a mailing list dedicated to a free and open source software project and is really not the place to discuss your patent issues. Let's please get back to discussing GNU Radio. Tom On Sun, Jul 7, 2013 at 3:34 AM, wrote: > To whom so ever it may concern... > > This work is been Patented and Copyrights are with Agile Solutions. This PCB > Layout work and RF designs are panted work of Agile Solutions. We have the > NDA signed by Xxillence Incorporate and we have started the legal action > against them. Any sort of communication this way is illegal by Mr. Puspraj > as per the NDA signed by him. > > Any kind proliferation of this work will be direct liability of XxiLLENCE > Incorporate for compensations as per the law of the land. > > The claim of Mr. Puspraj is completely wrong as we have paid for this work. > All the payment for this work has been done directly to him as we have all > the bank transactions for proof. > > PS: Our new product lines are much better than ASRP1. We will be soon > releasing new series of products offering better solutions and capabilities > at same price of ASRP1. Martin O'Shield is closely working with us for > creating a new and better SDR platforms. > > Regards > Akash > > > On 06-07-2013, Martin O'Shield wrote: >> >> Pusraj, >> >> Please reach me on my Mobile # 1-773-531-7312 >> >> If Akash really did this, and its been listed on his website since >> last year, I am not seeing how you wouldn't be aware of this, >> especially considering Akash mentioned this last year on this mailing >> list as well. >> >> We really need to talk as things are already in motion. >> >> Sincerely, >> >> Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qa_qtgui test fails
On Sun, Jul 7, 2013 at 12:59 AM, Richard Farina wrote: > On 07/06/2013 03:39 AM, Volker Schroer wrote: >> I compiled gnuradio-3.7 from scratch on my gentoo (64 bit ) system. >> The qa_qtgui test works as non privileged user as well as privileged user. >> So I think there is another problem on your system. >> Maybe there are some weird qwt- dependencies. > > When you build with portage it drops privs to user "portage" which > obviously has no rights to my X server, on the rare chance that I'm > running one at all. > > If there is no way to easily disable the test right now I understand, > but it would be nice to have a way to disable some of these tests which > are simply not going to work on headless boxes (like the one I have > building every commit that goes into git as a test). > > Thanks, > Zero You can disable a test using a regex expression and the -E flag to ctest. So instead of running 'make test', run it as: $ ctest -E qtgui That will prevent that particular test from being run (or any test that regex matches to qtgui, which is only that one test). If you are building on a headless box, you can also simply not build gr-qtgui. Just pass '-DENABLE_GR_QTGUI=False' to cmake. Tom >> >> >> -- Volker >> >> Am 05.07.2013 18:47, schrieb Richard Farina: >>> I'm one of the maintainers for gnuradio in gentoo, and have a silly >>> question. I've noticed the following test failure: >>> >>> 161/174 Testing: qa_qtgui >>> 161/174 Test: qa_qtgui >>> Command: "/bin/sh" >>> "/var/tmp/portage/net-wireless/gnuradio-3.7.0/work/gnuradio-3.7.0_build/gr-qtgui/python/qtgui/qa_qtgui_test.sh" >>> >>> Directory: >>> /var/tmp/portage/net-wireless/gnuradio-3.7.0/work/gnuradio-3.7.0_build/gr-qtgui/python/qtgui >>> >>> "qa_qtgui" start time: Jul 05 12:21 EDT >>> Output: >>> -- >>> No protocol specified >>> : cannot connect to X server :0.0 >>> >>> Test time = 0.33 sec >>> -- >>> Test Failed. >>> "qa_qtgui" end time: Jul 05 12:21 EDT >>> "qa_qtgui" time elapsed: 00:00:00 >>> -- >>> >>> >>> Due to multiple factors there is no way for this test to pass in gentoo >>> as builds are done as a non-privledged user. Is there a simple way to >>> disable just this test? If not, could something be added? >>> >>> Thanks, >>> Zero >>> >>> ___ >>> 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 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
Re: [Discuss-gnuradio] GNU Radio Companion v3.7.0-1-g2c05acc1 python name-spaces not working
On Fri, Jul 5, 2013 at 6:31 PM, Andrew Davis wrote: > Thanks for the suggestion, I removed every trace of GNU Radio off this > machine and re-installed, it did not fix the problem. After further > investigation the problem appears to be related to another problem I have > been having, when I would run any block using filters I would get: > >> ImportError: /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0: undefined >> symbol: volk_32f_x2_dot_prod_16i_a > > And now when I manual pull in 'analog' in python I get: > >> ImportError: /usr/lib/libgnuradio-blocks-3.7.1git.so.0.0.0: undefined >> symbol: volk_64u_byteswap_u > > So this link problem is what is keeping 'analog' undefined. > > When I run 'readelf -d /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0' I get: > >> 0x0001 (NEEDED) Shared library: [libvolk.so.0.0.0] > > So I think It is being linked, and when I run 'nm -D > /usr/lib/libvolk.so.0.0.0' I get: > >> 002d69f0 D volk_32f_x2_dot_prod_16i >> 002d6a10 D volk_32f_x2_dot_prod_16i_a <--- >> 00042130 T volk_32f_x2_dot_prod_16i_get_func_desc > > So I think libvolk exports it ( although i'm not sure why the 'D' is there > ). > > What else could I check to see why VOLK functions are not getting linked? > > Thank you > -Andrew Ok, that clears up the import error. Have you just tried running 'ldconfig' to see if that fixes your linking problems? Tom > On Thu, Jul 4, 2013 at 5:17 PM, Stephen Harrison > wrote: >> >> I had the same problem, but realized I was using the GRC .xml definitions >> from the previous version (in /usr/local/share/gnuradio/blocks). >> >> >> On Thu, Jul 4, 2013 at 2:12 PM, Tom Rondeau wrote: >>> >>> On Thu, Jul 4, 2013 at 4:58 PM, Andrew Davis >>> wrote: >>> > Hello all, >>> > >>> > I'm using Xubuntu 13.04 and compiled from 3.7git, when I try to run GRC >>> > almost any block that uses constants from the updates name-spaces GRC >>> > fails >>> > with: >>> > >>> >> Value "firdes.WIN_HAMMING" cannot be evaluated: >>> >> name 'firdes' is not defined >>> > >>> > or for signal source and related: >>> > >>> >> Value "analog.GR_SIN_WAVE" cannot be evaluated: >>> >> name 'analog' is not defined >>> > >>> > I'm not sure where in GRC these are defined but I will continue to look >>> > for >>> > a fix. >>> > >>> > Thank you >>> > ~Andrew >>> >>> Have you removed all other GNU Radio versions from your machine? >>> >>> Also, if these are your own GRC files, might just try typing it in >>> again as the state might be a bit confused after an update. >>> >>> The specific cases you've mentioned have been tested for in the 3.7 >>> release, so I think it's something local and/or a confusion after an >>> upgrade (the latter are bound to happen). >>> >>> Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Pilot Subcarrier in new OFDM PHY
On Sat, Jul 6, 2013 at 9:31 AM, YAXIONG XIE wrote: > Hi all, > I am using the new OFDM PHY to get data from USRP. The new OFDM PHY is > using pilot subcarrier. I think that it using the pilot because it want > using pilot to help decode the data subcarrier. But when I checking the > source code in the channel equalizer, I didn't find any code that using > pilot to help decoding. >According my opinion, the equalizer just updating the channel state and > didn't do anything except that. We should do interpolation using the pilot > subcarrier channel state to help decoding the data, right? But the source > code didn't do that. >So I am wondering why the new ofdm PHY code using the pilot. >Thanks >Yaxiong > > -- > > Yaxiong Xie Correct, currently the pilots are not being used. This is future work for the OFDM project. You still need to declare which subcarriers are pilots at the receiver, though, so that you know not to try and use them for data. The current implementation uses a 1-tap equalizer that is calculated based off the preamble. For slowly changing channels, this is ok and you can still receive the entire packet. Obviously, using the pilots throughout will be more robust and handle other channel conditions, and we really look forward to seeing this implemented :) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr::buffer::allocate_buffer: warning:
On Fri, Jul 5, 2013 at 5:01 AM, Manu T S wrote: > A block that i designed takes a vector of length 408 with numpy.int32 > components. Work function just copies input to output. Work function > definition is given below. > > def work(self, input_items, output_items): > for i in range(len(input_items[0][0])): > print input_items[0][0][i], > output_items[0][0][i] = input_items[0][0][i] > return len(input_items[0]) > - > > I'm getting the following warning. > > gr::buffer::allocate_buffer: warning: tried to allocate >40 items of size 1632. Due to alignment requirements >128 were allocated. If this isn't OK, consider padding >your structure to a power-of-two bytes. >On this platform, our allocation granularity is 4096 bytes. > gr::buffer::allocate_buffer: warning: tried to allocate >40 items of size 1632. Due to alignment requirements >128 were allocated. If this isn't OK, consider padding >your structure to a power-of-two bytes. > > What could be the reason for this warning? What could be done to correct > this? > > -- > Manu T S Manu, This has more to do with your io_signature declaration in the constructor than the work function. It's simply that for memory handling purposes, the buffers are set up to use multiples of pages, and you are asking for a strange size. Basically, this should still work, but you might be using a lot more memory for your buffers than required. I wouldn't worry about this for now. I'm assuming this is for your GSoC project? If so, just keep going and make sure you get the math right. You'll want to move this into a C++ block eventually, anyways, and do further optimizations there. We can worry about this problem at that point. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FM Mod / Demod Sensitivity and Quad. Gain Parameters
On Thu, Jul 4, 2013 at 10:50 PM, Dan CaJacob wrote: > Thanks Tom, > > I think I have it worked out now. The sensitivity and gain parameters for > the FM Mod and Quad. Demod blocks are reciprocals of one another. To > control deviation, in these parameters, you can just calculate Modulation > Index. I was doing it the other way around. The bit that made everything > make sense for me was reading that Modulation Index can be thought of as > having units of Radians. Understanding that, the rest makes perfect sense. > > So, the parameters become: > > sensitivity = (pi * modulation_index) / samples_per_symbol > > and on the receive side: > > gain = samples_per_symbol / (pi * modulation_index) > > Modulation index itself can be set explicitly or derived from a desired > deviation and baud rate: > > modulation_index = deviation / (baud_rate / 2) > > So, for a Minimum Modulation Index of 0.5, as is used in GMSK, the > sensitivity reduces to: > > sensitivity = (pi / 2) / samples_per_symbol, just as it is in the example. > > The nbfm_tx.py example is probably different because it isn't for data > transmission, but for audio, I think. > > Thanks for your help! > > Very Respectfully, > > Dan CaJacob Hey Dan, Great! I've edited your post and put the calculations here on our Signal Processing wiki page (http://gnuradio.org/redmine/projects/gnuradio/wiki/SignalProcessing). And yes, converting to radians is key for this. I should have thought to mention that. Tom > On Wed, Jul 3, 2013 at 10:38 AM, Tom Rondeau wrote: >> >> On Thu, Jun 27, 2013 at 3:54 PM, Dan CaJacob >> wrote: >> > We use the FM Mod and Quadrature Demod blocks to modulate and demodulate >> > GFSK packetized data. In the past, we have used sensitivity values for >> > these blocks that were provided for us, but their meaning was opaque. >> > >> > I did some digging in the list and the web and found two prevalent >> > definitions for sensitivity from examples. Both definitions were >> > consistent >> > in saying that the Demod parameter 'Quadrature Gain' should be the >> > inverse >> > of the sensitivity parameter for the Mod block. >> > >> > The competing definitions for sensitivity were: >> > >> > 1. sensitivity = (pi / 2) / samples_pr_symbol # from >> > gnuradio/blksimpl/gmsk.py >> > >> > and >> > >> > 2. sensitivity = 2 * pi * max_deviation / sample_rate # from >> > gnuradio/blks2impl/nbfm_tx.py >> > >> > In my own recent work, I have been using the second definition because >> > it >> > seems to work and it gives me control over the deviation (I define max >> > deviation using modulation index and baud rate). >> > >> > However, when I attempt to use 1/sensitivity for the Quadrature Gain of >> > the >> > RX, it does not seem to work, while altering the RX definition of >> > sensitivity to be 1 / (2 * pi * max_deviation / baud_rate) does seem to >> > work. >> > >> > Am I missing something fundamental about how these parameters work? >> >> Hi Dan, >> >> The quadrature_demod converts from phase/frequency modulation back to >> amplitude. So in the case of FSK signals (and let's treat GMSK as FSK >> for this), we want to convert frequency f1 into -1 and frequeuncy f2 >> to +1. Also, "let's assume the system is synchronized" so that f1 = >> -fm and f2 = +fm. What you want to do is convert those frequencies to >> -1's and 1's, right? So there's some rotation around the unit circle >> that maps to this based on the number of samples per symbol you are >> using. So hopefully that explains where the pi and sps in the >> calculations come from. >> >> Hope this helps. >> >> Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Default value of "Taps" in GRC
On Thu, Jul 4, 2013 at 7:50 PM, Stephen Harrison wrote: > The XML for filter_rational_resampler_xxx sets the default value of Taps to > None. However, this gives the error Expression "[None]" is invalid for type > complex vector. > > Deleting "None" from this box fixes the problem. Is it safe to change my XML > definition to have no default value? Stephen, There is a bug filed on our Redmine Issues page about the use of '[' and ']' on different systems. I think this might be the same problem you're seeing with the '[None]' instead of just 'None'. The rational_resampler is a hier_block2 (in gr-filter/python/filter), and if you tell it the taps are None, it will automatically calculate a set of taps for you. It makes an allpass filter for the original signal. Off the top of my head, I'm not sure what happens if you leave this block empty. It might be fine since the taps argument for this block has a default of 'None', or it might think that the you are passing an empty list of taps, in which case it wouldn't be correct. You can easily test this by using the rational_resampler block as an integer upsampler and looking at the output. If you see big images that aren't being supressed, you aren't filtering. My guess is that the latter is happening. If 'None' is being read as '[None]', then I think '' will become '[]'. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with GRC after installation with build-gnuradio
On Fri, Jun 28, 2013 at 4:24 AM, Tim Esemann wrote: > Hi, > > I have installed GR with the build-gnuradio script from Marcus. In the past > it worked well on several machines, but now I have a problem with the > gnuradio companion after installation. Once I start the grc from the command > line I get a segmentation fault: > > esemannt@gr01-desktop:~/source$ gnuradio-companion Segmentation fault (core > dumped) > > Unfortunately I get no more error information. After "dmesg" I got: > > [91365.599988] gnuradio-compan[28920]: segfault at 26356 ip 00026356 > sp 7fffa6004ca8 error 14 in python2.7[40+271000] > > In the past (with an older GR version) GRC worked fine on this machine. Does > anyone have an idea that might help me? > > Everything else, i.e uhd_find_devices and other python code, works fine. > I've uploaded the logfile from installation with build-gnuradio to: > > http://www.cosa.fh-luebeck.de/download/gnuradio/ > > I'm using a: > Intel® Core™ i7 CPU 920 @ 2.67GHz × 8 > ubuntu 12.04 LTS (64-bit) > > Thanks in advance and best regards, > Tim Esemann Tim, I suggest you try running build-gnuradio again (after removing any currently installed versions of GNU Radio). You might have gotten hit when we updated the branches for the 3.7 release and before Martin was able to update the build script. If you run build-gnuradio now, you should be installing version 3.6.5.1, which should be the same as you've been using for a while (with some bug fixes). You can use 'gnuradio-config -v' to see what version is installed to make sure. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Problem in uhd_fft
H i Marcus, I got it. It is a case of bandpass sampling. .Thank you. On Fri, Jul 5, 2013 at 6:12 PM, Marcus D. Leech wrote: > ** > On 07/04/2013 11:51 PM, Karan Talasila wrote: > > Hi Josh, > can you explain how and why the frequency translation > occurs? secondly when the same basic tx chip is used on a usrp N210, the > translation occurs at 50Mhz and after. So for USRP N210, the entire range > from 0-250 Mhz is represented by alternating between -50Mhz to +50Mhz. Why > is it that way? > > The BASIC_RX and LF_RX have no downconversion hardware in them at all. > They are basically just "buffers" for the ADCs. The BASIC_RX has an > analog reponse that starts to fall off at about 250Mhz, which is why > it's rated to 250Mhz. > > In the USRP1/B100/E1XX systems, the sampling clock is at 64MHz by > default. That means the first aliases start to show up at the 1st Nyquist > frequency of 32Mhz (half of sample rate). Similarly in the N2XX, which > a 100MHz sampling clock, those aliases start to show up at 50Mhz. > > My suggestion would be to look into so-called bandpass sampling, and also, > importantly, Nyquist Sampling Theorem. > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Regards Karan Talasila ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Channel filter in new OFDM PHY
Hi all, I have a question about the channel filter usage in OFDM PHY. In the benchmark, there is a channel filter used before ofdm syn. In the new OFDM PHY, especially in the GRC example, there is not such a block. So, should I use a channel filter when i want to using the New OFDM PHY implementation? Thanks. Yaxiong -- *Yaxiong Xie / **谢亚雄* School of Computer Engineering Nanyang Technological University, Singapore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compatible GNU Radio $500 2x2 full duplex MIMO SDR coming to a Kickstarter Shortly (Martin O'Shield)
Hello Martin, Where did you got this patent done in US or Abroad?. Can you please point to it ?. Is the patent granted or in application/review stage ?. Hi Matt Does the patent impact the Ettus/NI Current/Future SDR products and hence clipping wings of free/open source nature of gnuradio in anyway?. Thanks, Justin Bracken ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Upgrading from 3.6 to 3.7....how?
Hi! 2 weeks ago i installed gnu radio using the famous script on the wiki... Now I would like to upgrade to 3.7 How can i upgrade? Is there a procedure to follow? (remove 3.6 then how to install 3.7) Many thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Upgrading from 3.6 to 3.7....how?
On 07/07/2013 12:04 PM, Favati wrote: Hi! 2 weeks ago i installed gnu radio using the famous script on the wiki... Now I would like to upgrade to 3.7 How can i upgrade? Is there a procedure to follow? (remove 3.6 then how to install 3.7) Many thanks! You can build-gnuradio -m which will checkout from master, which is 3.7. Lots of apps haven't yet been converted to 3.7 -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] qa_qtgui test fails
On 07/07/2013 04:15 AM, Tom Rondeau wrote: > On Sun, Jul 7, 2013 at 12:59 AM, Richard Farina wrote: >> On 07/06/2013 03:39 AM, Volker Schroer wrote: >>> I compiled gnuradio-3.7 from scratch on my gentoo (64 bit ) system. >>> The qa_qtgui test works as non privileged user as well as privileged user. >>> So I think there is another problem on your system. >>> Maybe there are some weird qwt- dependencies. >> >> When you build with portage it drops privs to user "portage" which >> obviously has no rights to my X server, on the rare chance that I'm >> running one at all. >> >> If there is no way to easily disable the test right now I understand, >> but it would be nice to have a way to disable some of these tests which >> are simply not going to work on headless boxes (like the one I have >> building every commit that goes into git as a test). >> >> Thanks, >> Zero > > You can disable a test using a regex expression and the -E flag to > ctest. So instead of running 'make test', run it as: > > $ ctest -E qtgui Thanks, that works great! -Zero > > That will prevent that particular test from being run (or any test > that regex matches to qtgui, which is only that one test). > > If you are building on a headless box, you can also simply not build > gr-qtgui. Just pass '-DENABLE_GR_QTGUI=False' to cmake. > > Tom > > >>> >>> >>> -- Volker >>> >>> Am 05.07.2013 18:47, schrieb Richard Farina: I'm one of the maintainers for gnuradio in gentoo, and have a silly question. I've noticed the following test failure: 161/174 Testing: qa_qtgui 161/174 Test: qa_qtgui Command: "/bin/sh" "/var/tmp/portage/net-wireless/gnuradio-3.7.0/work/gnuradio-3.7.0_build/gr-qtgui/python/qtgui/qa_qtgui_test.sh" Directory: /var/tmp/portage/net-wireless/gnuradio-3.7.0/work/gnuradio-3.7.0_build/gr-qtgui/python/qtgui "qa_qtgui" start time: Jul 05 12:21 EDT Output: -- No protocol specified : cannot connect to X server :0.0 Test time = 0.33 sec -- Test Failed. "qa_qtgui" end time: Jul 05 12:21 EDT "qa_qtgui" time elapsed: 00:00:00 -- Due to multiple factors there is no way for this test to pass in gentoo as builds are done as a non-privledged user. Is there a simple way to disable just this test? If not, could something be added? Thanks, Zero ___ 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 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
Re: [Discuss-gnuradio] gr::buffer::allocate_buffer: warning:
Tom, Yes, it is for my GSoC project. Till now I have prototyped in python encoder, decoder and construction of LDPC codes from Reed Solomon codes. The encoder and decoder input sizes vary based on the code block length and dimension. I hope to switch gears to C++ soon. Thanks. On Sun, Jul 7, 2013 at 1:55 PM, Tom Rondeau wrote: > On Fri, Jul 5, 2013 at 5:01 AM, Manu T S wrote: > > A block that i designed takes a vector of length 408 with numpy.int32 > > components. Work function just copies input to output. Work function > > definition is given below. > > > > > def work(self, input_items, output_items): > > for i in range(len(input_items[0][0])): > > print input_items[0][0][i], > > output_items[0][0][i] = input_items[0][0][i] > > return len(input_items[0]) > > > - > > > > I'm getting the following warning. > > > > gr::buffer::allocate_buffer: warning: tried to allocate > >40 items of size 1632. Due to alignment requirements > >128 were allocated. If this isn't OK, consider padding > >your structure to a power-of-two bytes. > >On this platform, our allocation granularity is 4096 bytes. > > gr::buffer::allocate_buffer: warning: tried to allocate > >40 items of size 1632. Due to alignment requirements > >128 were allocated. If this isn't OK, consider padding > >your structure to a power-of-two bytes. > > > > What could be the reason for this warning? What could be done to correct > > this? > > > > -- > > Manu T S > > Manu, > > This has more to do with your io_signature declaration in the > constructor than the work function. It's simply that for memory > handling purposes, the buffers are set up to use multiples of pages, > and you are asking for a strange size. Basically, this should still > work, but you might be using a lot more memory for your buffers than > required. > > I wouldn't worry about this for now. I'm assuming this is for your > GSoC project? If so, just keep going and make sure you get the math > right. You'll want to move this into a C++ block eventually, anyways, > and do further optimizations there. We can worry about this problem at > that point. > > Tom > -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr::buffer::allocate_buffer: warning:
Hi Manu, Tracie, I wouldn't worry about this for now. I'm assuming this is for your GSoC project? If so, just keep going and make sure you get the math right. You'll want to move this into a C++ block eventually, anyways, and do further optimizations there. We can worry about this problem at that point. I would like to stress this point. First you two have to get something high level working. Even Octave or (Octave-compatible) Matlab is fine if you are more familiar with that. Jens ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to to add a "non-block" code using mod_tool.
Hi Everyone, >From the tutorial on out of tree module I followed how to install a block, and access it in GRC. Now I have a block, "encoder.py" but the actual encoding operation defined in another class in file "gf2mat.py" . Inside the work function I just call that operation. Using modtool how do I get this helper file "gf2mat.py" installed along with the encoder. Is it required to move the class definitions inside the helper file into the "encoder.py" file? -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple QAM project
I am new to linux and GNURadio. I don'g follow where the 1 bit/byte is coming from. Does the audio source not deliver 8bit/sample or how do you figure that out? I don't see anything such as "gnuradio>digital>generic_mod_demod.py " in my directories. Thanks for the help. Tom -- Tom, There are few changes required in ur FG 1: PSK/QAM Modulator takes packed byte input (8 bits per byte) instead of 1 bit per byte see gnuradio>digital>generic_mod_demod.py 2: Constellation sink work only for PSK modulation M=2,4,8. To see output constellation of QAM-16 u will have to first downsample it to 1 sample_per_symbol and then use wx-scope-sink in XY-Mode Down-sampling can be done using symbol-timing blocks or manually (delay+keep1inN combination) as in attached FG -Adeel > > From: Adeel Anwar >To: tom sutherland ; discuss-gnuradio@gnu.org >Sent: Friday, July 5, 2013 10:25 PM >Subject: Re: [Discuss-gnuradio] Simple QAM project > > > > >Can u attach ur GRC file? > >-Adeel > > > > >On Fri, Jul 5, 2013 at 5:48 AM, tom sutherland wrote: > >I am trying to get data through a QAM-16 Modulator and just display the data >stream on a Constellation Sink. I have 8khz sampled 8-bit data(char) going >into the QAM Mod block. I have the output of the QAMmod block going directly >into the Const Sink. I am not seeing anything on the Constellation Sink. I put >a throttle block in but that didn't help. >>Any thoughts on what could be wrong? I have followed the GNUradio tutorial: >>Part 4 by balint256 but didn't help. >>Thanks...DT >> >> >> >>___ >>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
Re: [Discuss-gnuradio] GNU Radio Companion v3.7.0-1-g2c05acc1 python name-spaces not working
OK, it appears a previous install hid an extra libvolk in /usr/lib/x86_64-linux-gnu, removing that everything is working well so far, thank you for the help everyone. -Andrew On Sun, Jul 7, 2013 at 4:12 AM, Tom Rondeau wrote: > On Fri, Jul 5, 2013 at 6:31 PM, Andrew Davis > wrote: > > Thanks for the suggestion, I removed every trace of GNU Radio off this > > machine and re-installed, it did not fix the problem. After further > > investigation the problem appears to be related to another problem I have > > been having, when I would run any block using filters I would get: > > > >> ImportError: /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0: undefined > >> symbol: volk_32f_x2_dot_prod_16i_a > > > > And now when I manual pull in 'analog' in python I get: > > > >> ImportError: /usr/lib/libgnuradio-blocks-3.7.1git.so.0.0.0: undefined > >> symbol: volk_64u_byteswap_u > > > > So this link problem is what is keeping 'analog' undefined. > > > > When I run 'readelf -d /usr/lib/libgnuradio-filter-3.7.1git.so.0.0.0' I > get: > > > >> 0x0001 (NEEDED) Shared library: [libvolk.so.0.0.0] > > > > So I think It is being linked, and when I run 'nm -D > > /usr/lib/libvolk.so.0.0.0' I get: > > > >> 002d69f0 D volk_32f_x2_dot_prod_16i > >> 002d6a10 D volk_32f_x2_dot_prod_16i_a <--- > >> 00042130 T volk_32f_x2_dot_prod_16i_get_func_desc > > > > So I think libvolk exports it ( although i'm not sure why the 'D' is > there > > ). > > > > What else could I check to see why VOLK functions are not getting linked? > > > > Thank you > > -Andrew > > Ok, that clears up the import error. Have you just tried running > 'ldconfig' to see if that fixes your linking problems? > > Tom > > > > On Thu, Jul 4, 2013 at 5:17 PM, Stephen Harrison < > msteveharri...@gmail.com> > > wrote: > >> > >> I had the same problem, but realized I was using the GRC .xml > definitions > >> from the previous version (in /usr/local/share/gnuradio/blocks). > >> > >> > >> On Thu, Jul 4, 2013 at 2:12 PM, Tom Rondeau wrote: > >>> > >>> On Thu, Jul 4, 2013 at 4:58 PM, Andrew Davis > >>> wrote: > >>> > Hello all, > >>> > > >>> > I'm using Xubuntu 13.04 and compiled from 3.7git, when I try to run > GRC > >>> > almost any block that uses constants from the updates name-spaces GRC > >>> > fails > >>> > with: > >>> > > >>> >> Value "firdes.WIN_HAMMING" cannot be evaluated: > >>> >> name 'firdes' is not defined > >>> > > >>> > or for signal source and related: > >>> > > >>> >> Value "analog.GR_SIN_WAVE" cannot be evaluated: > >>> >> name 'analog' is not defined > >>> > > >>> > I'm not sure where in GRC these are defined but I will continue to > look > >>> > for > >>> > a fix. > >>> > > >>> > Thank you > >>> > ~Andrew > >>> > >>> Have you removed all other GNU Radio versions from your machine? > >>> > >>> Also, if these are your own GRC files, might just try typing it in > >>> again as the state might be a bit confused after an update. > >>> > >>> The specific cases you've mentioned have been tested for in the 3.7 > >>> release, so I think it's something local and/or a confusion after an > >>> upgrade (the latter are bound to happen). > >>> > >>> Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Channel filter in new OFDM PHY
Hi all, I have a question about the channel filter usage in OFDM PHY. In the benchmark, there is a channel filter used before ofdm syn. In the new OFDM PHY, especially in the GRC example, there is not such a block. So, should I use a channel filter when i want to using the New OFDM PHY implementation? Thanks. -- *Yaxiong Xie / **谢亚雄* School of Computer Engineering Nanyang Technological University, Singapore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
