[Discuss-gnuradio] CRC boost library
Hi all guys, I've just been wondering has anybody of you tried this: http://www.boost.org/doc/libs/1_53_0/libs/crc/crc.html and how it fits if yes. Best regards, -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to save/read sc8 format to/from file and convert it to complex float 32?
Hi gurus, - Which is the simplest way, preferably directly in grc, to compactly save 8bit I/Q data (sc8) from an UHD source to a file instead the of the standard format complex float 32 (which is 4 times larger) ? - Then also, how to convert received and saved sc8 data to the normal complex float 32 in grc? The reason is that I want to take advantage of the sc8 reduced precision by reducing the file size when storing received data to file. That is, not only halve the bandwidth "over the wire" (compared to sc16) but also reduce the file size when storing. Or is there alternative and better ways to accomplish this when receiving and saving raw 8 bit I/Q data? In GRC I see its possible to select the output format "complex int 16", instead of the standard "complex float 32", but I don't find how to process or interpret this format further (e.g. saving, reading, converting to complex float 32, etc). Thanks, Rickard ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CRC boost library
On Thu, Jun 06, 2013 at 10:17:24AM +0200, Nemanja Savic wrote: > Hi all guys, > > > I've just been wondering has anybody of you tried this: > > http://www.boost.org/doc/libs/1_53_0/libs/crc/crc.html Tim just pushed a change to master where the crc32_bb stream block uses just that. Plus we might use it in the packet header generators/parsers. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpocNfFdQhBa.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CRC boost library
Thank you Martin. Meanwhile I tried, and works just fine. Best On Thu, Jun 6, 2013 at 3:12 PM, Martin Braun (CEL) wrote: > On Thu, Jun 06, 2013 at 10:17:24AM +0200, Nemanja Savic wrote: > > Hi all guys, > > > > > > I've just been wondering has anybody of you tried this: > > > > http://www.boost.org/doc/libs/1_53_0/libs/crc/crc.html > > Tim just pushed a change to master where the crc32_bb stream block uses > just that. Plus we might use it in the packet header generators/parsers. > > MB > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fwd: time_recov and freq_recov in generic_mod_demod
Ada, >As I looked up from the documents, it was said that the signal after the usrp source at the receiver, is baseband signal, whose central >frequency is around 0 Hz, and already take off the carrier frequency. But in the demodulation, there are still freq_recov and time_recov block. >Are they at the symbol level? Yes and there is always a freq-difference between Tx and Rx LO due to this there will always be some freq-offset http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#Why-is-there-always-a-frequency-offset-when-transmitting-from-one-USRP-to-another >I'm quite confused with how the benchmark, actually the demodulation in generic_mod_demod.py works. When does the carrier frequency is >taken off? In USRP. Timing recovery for compensating timing-offset, Freq-Recovery for freq-offset. http://gnuradio.org/doc/doxygen/classdigital__pfb__clock__sync__ccf.html http://gnuradio.org/doc/doxygen/classdigital__fll__band__edge__cc.html -Adeel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to save/read sc8 format to/from file and convert it to complex float 32?
On 06/06/2013 06:38 AM, Rickard wrote: > Hi gurus, > > - Which is the simplest way, preferably directly in grc, to compactly > save 8bit I/Q data (sc8) from an UHD source to a file instead the of > the standard format complex float 32 (which is 4 times larger) ? > > - Then also, how to convert received and saved sc8 data to the normal > complex float 32 in grc? > A block that implements this conversion w/ a configurable scalar would be ideal. But there may not be such a direct block: there are float to char, char to float converters. And you can use this with complex to/from float and vector to/from streams block to get the two lanes of data into one. -josh > The reason is that I want to take advantage of the sc8 reduced > precision by reducing the file size when storing received data to > file. That is, not only halve the bandwidth "over the wire" > (compared to sc16) but also reduce the file size when storing. > > Or is there alternative and better ways to accomplish this when > receiving and saving raw 8 bit I/Q data? > > In GRC I see its possible to select the output format "complex int > 16", instead of the standard "complex float 32", but I don't find how > to process or interpret this format further (e.g. saving, reading, > converting to complex float 32, etc). > > Thanks, Rickard ___ > 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] How to save/read sc8 format to/from file and convert it to complex float 32?
On Thu, Jun 06, 2013 at 11:27:02AM -0400, Josh Blum wrote: > > A block that implements this conversion w/ a configurable scalar would > be ideal. That would be very nice. I've been using (for input from sc8 file to a complex flowgraph): UChar to Float -> Deinterleave => Float to Complex Since my samples are unsigned chars, this gives me an offset of approximately 128 that I can correct with Add Const either before Deinterleave or after Float to Complex (where it is 128+128j). Unsigned sc8 is the primary data format used by HackRF, so this may be interesting to other HackRF users. The conversion is handled by gr-osmosdr when communicating with a HackRF directly from GNU Radio, but files transmitted or received via the hackrf_transfer utility are in the unsigned sc8 format. Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Companion isn't aware of custom pythonpath(s)
I bumped into a strange issue in the past few days. When i launch GRC by the desktop link generated, the program itself isn't aware of my custom pythonpath set in the .bashrc settings file. I tried to modify the desktop link also by checking the option to *launch the program in a terminal* and putting into the blank space : /export PYTHONPATH=$PYTHONPATH: \ gnuradio-companion/ but without any results. I have never experienced this issue with the past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio 3.6.4.1. The only way it works is by making a script and launch it from my desktop. No issues if i launch GRC from shell, after all the pythonpath is embedded in the launched shell. thanks in advance for helping me. Kind Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of custom pythonpath(s)
On 06/06/2013 02:54 PM, Arturo Rinaldi wrote: > I bumped into a strange issue in the past few days. When i launch GRC by > the desktop link generated, the program itself isn't aware of my custom > pythonpath set in the .bashrc settings file. I tried to modify the > desktop link also by checking the option to *launch the program in a > terminal* and putting into the blank space : > > /export PYTHONPATH=$PYTHONPATH: \ gnuradio-companion/ > > but without any results. I have never experienced this issue with the > past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio > 3.6.4.1. The only way it works is by making a script and launch it from > my desktop. No issues if i launch GRC from shell, after all the > pythonpath is embedded in the launched shell. > > thanks in advance for helping me. I can confirm that this is an issue. There may need to be a helper gnuradio-companion script that sets the env vars and then calls the actual python script. The gnuradio-grc.desktop would call this script instead. Not sure of a better way to do that. -josh > > Kind Regards, > > Arturo > > > > > > > > ___ > 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] Tun/Tap Problem while Running tunnel.py while wireshark recognizes
We are working on establishing a tunnel for MAC protocol design using tunnel.py given as example in GNU Radio but are unable to receive ping reply from the other node. We created tun/tap interface using ./tunnel.py -f 990M and ipconfig 192.168.200.1 on Machine A connected to N210 series of USRP. and ./tunnel.py -f 990M and ifconfig 192.168.200.2 on machine B. 1. Now on pinging machine B from A we can see ping packets being sent to B by A using wireshark, but there is no reply on node A. 2. We went into details and saw there were ARQ requests from B repetitively. I manually added the mac address to update the table. Now ARQ request ceased to exist but still there were no replies on A. 3. Since we knew the Packaging details of ICMP we read the packets being received by B and found the exact source address of A from the frame. It means message have been successfully decoded by the destination and it knows whom to reply for the ping but still I don't find any reception confirmation on source side. What may be the possible problems?USRP antenna gain?Packets collision? In short we are unable to use tunnely.py and are seeking for possible causes. Jay Prakash Senior Undergraduate ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Companion isn't aware of custom pythonpath(s)
On 06/06/2013 02:54 PM, Arturo Rinaldi wrote: I bumped into a strange issue in the past few days. When i launch GRC by the desktop link generated, the program itself isn't aware of my custom pythonpath set in the .bashrc settings file. I tried to modify the desktop link also by checking the option to *launch the program in a terminal* and putting into the blank space : /export PYTHONPATH=$PYTHONPATH: \ gnuradio-companion/ but without any results. I have never experienced this issue with the past versions of gnuradio. I'm running Kubuntu 13.04 with gnuradio 3.6.4.1. The only way it works is by making a script and launch it from my desktop. No issues if i launch GRC from shell, after all the pythonpath is embedded in the launched shell. thanks in advance for helping me. I can confirm that this is an issue. There may need to be a helper gnuradio-companion script that sets the env vars and then calls the actual python script. The gnuradio-grc.desktop would call this script instead. Not sure of a better way to do that. -josh In Ubuntu, terminals aren't automatically "login" terminals, and so don't run your .bashrc, although for terminals at least, you can configure them to pretend to be "login" terminals, and thus run your .bashrc. -- 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] Ucla Zigbee compiling issues on MacOs X and Ubuntu 12.04.2 LTS
Il 06/06/13 07:23, Bastian Bloessl ha scritto: Hello Arturo, On 06/06/2013 01:55 AM, Arturo Rinaldi wrote: I have recently bumped into some issues when building the ucla_zigbee platform both on macos and ubuntu 12.04.2. I'll shortly sum up my two setups : I think the UCLA blocks were not updated to work with GNU Radio 3.6.4. I made some 802.15.4 blocks based on the UCLA Phy. Maybe you want to give them a try. https://github.com/bastibl/gr-ieee802-15-4 The last commits port the blocks to v3.7 API. If you want to use 3.6.4 you should go back some commits git checkout v3.6 Best, Bastian Hi Sebastian, I've just successfully built the zigbee platform with gnuradio-3.6.4.1 on Kubuntu 13.04. I already found your zigbee port some time ago but I need the whole complete distro. I have done another tweak in the *Makefile.common* file I attached last night, to fine tuning the python installation directory of the files with : /grpythondir = /usr/lib/python2.7/dist-packages/gnuradio/ and all went smoothly. Tomorrow i'll test my 12.04 machine hoping that this is the reason why i couldn't install zigbee on it. MacOS X issues still persist. Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make test errors
I'm new to this, and I'm sure it will show... I am trying to install and run Gnu Radio in an Ubuntu 12.10 environment. I followed the instructions at http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Installation-Overview and am getting errors on four modules when I run make test. They are: 86 - qa_fir_filter 91 - qa_freq__xlating_fir_filter 150 - qa_constellation_receiver 169 - qa_codec2_vocoder Here is the output of ctest -V -R qa for each of those modules. I'd really appreciate any guidance on how to resolve these failures. 86: Test command: /bin/sh "/home/dave/gnuradio/build/gr-filter/python/qa_fir_filter_test.sh" 86: Test timeout computed to be: 9.99988e+06 86: .FF 86: == 86: FAIL: test_fir_filter_scc_001 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line 262, in test_fir_filter_scc_001 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 47, in assertComplexAlmostEqual 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places 86: 86: == 86: FAIL: test_fir_filter_scc_002 (__main__.test_filter) 86: -- 86: Traceback (most recent call last): 86: Using Volk machine: avx_32_mmx 86: File "/home/dave/gnuradio/gr-filter/python/qa_fir_filter.py", line 281, in test_fir_filter_scc_002 86: self.assertComplexTuplesAlmostEqual(expected_data, result_data, 5) 86: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 74, in assertComplexTuplesAlmostEqual 86: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 86: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 47, in assertComplexAlmostEqual 86: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 86: AssertionError: (0.5+1j) != (nan+nanj) within 5 places 86: 86: -- 86: Ran 11 tests in 0.035s 86: 86: FAILED (failures=2) 1/1 Test #86: qa_fir_filter ***Failed0.30 sec 0% tests passed, 1 tests failed out of 1 Total Test time (real) = 0.31 sec The following tests FAILED: 86 - qa_fir_filter (Failed) Errors while running CTest 91: Test command: /bin/sh "/home/dave/gnuradio/build/gr-filter/python/qa_freq_xlating_fir_filter_test.sh" 91: Test timeout computed to be: 9.99988e+06 91: 91: == 91: FAIL: test_fir_filter_scc_001 (__main__.test_freq_xlating_filter) 91: -- 91: Traceback (most recent call last): 91: File "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line 412, in test_fir_filter_scc_001 91: self.assertComplexTuplesAlmostEqual(expected_data, result_data[-20:], 5) 91: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 74, in assertComplexTuplesAlmostEqual 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 91: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 47, in assertComplexAlmostEqual 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 91: AssertionError: (-0.00775564694777+0.0437113791704j) != (nan+nanj) within 5 places 91: 91: == 91: Using Volk machine: avx_32_mmx 91: FAIL: test_fir_filter_scc_002 (__main__.test_freq_xlating_filter) 91: -- 91: Traceback (most recent call last): 91: File "/home/dave/gnuradio/gr-filter/python/qa_freq_xlating_fir_filter.py", line 442, in test_fir_filter_scc_002 91: self.assertComplexTuplesAlmostEqual(expected_data, result_data[-20:], 5) 91: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 74, in assertComplexTuplesAlmostEqual 91: self.assertComplexAlmostEqual (a[i], b[i], places, msg) 91: File "/home/dave/gnuradio/gnuradio-runtime/python/gnuradio/gr_unittest.py", line 47, in assertComplexAlmostEqual 91: (msg or '%s != %s within %s places' % (`first`, `second`, `places` )) 91: AssertionError: (-0.0080680437386-0.00158522999845j) != (nan+nanj) within 5 places 91: 91: =
