Re: [Discuss-gnuradio] Question about OFDM Transmitter/Receiver

Maicon, I would suggest looking at the examples (rx_ofdm.grc and tx_ofdm.grc) as well as the manual pages for those blocks: * http://gnuradio.org/doc/doxygen/page_ofdm.html * http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1ofdm__carrier__allocator__cvc.html#details If that leaves any open

Re: [Discuss-gnuradio] Convert 16-bit IQ File to CFile

If, by 'cfile format', you mean raw, native fc32 (== std::complex) files, you can do file source -> ishort to complex -> file sink in GRC. Cheers, M On 12/01/2016 08:30 AM, AndroidT Tester wrote: > I have a 16-bit IQ pair recording sample, I can load it in GnuRadio with > IShort to Complex block

Re: [Discuss-gnuradio] pybombs and mako

Does python -c 'import mako' also fail? What does python --version print? I'm wondering if this is maybe a Python version mismatch. PyBOMBS wouldn't raise an error if a Py2k mako is installed, but you actually need a Py3k version. Cheers, M On 12/01/2016 06:57 AM, Robert McGwier wrote: > This

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

No, I think the data is fine I’m just telling you it isn’t normalized to +/- 1 as the USRP does when you record fc32 format versus sc16. No big deal, just a constant scale factor throughout the record. I don’t really know what you are looking for, so I can’t really tell you if it looks good or

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Paul, This is indeen NI-USRP capture. So you think the Cfile that I've created using gr_fileman and gr_mkheader isn't correct? I can see lots of good data by loading the cfile in Gqrx. I think it's working, am I wrong? Also I had another question, I converted my file to Wav file after

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Cheers, and thanks for finding the error. Also, you should note that the USRP scales fc32 format to +\- 1, but the sc16 format is ADC levels. gr_fileman doesn't scale during the conversion, so .sc16 converted to .fc32 will be scaled differently than straight out of the USRP. Paul Garver On

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Hello Paul, Indeed it's working now :) I successfully converted my 16-bit IQ sample file to a Cfile :) Thanks for all your help!! On Thu, Dec 1, 2016 at 4:04 PM, Garver, Paul W wrote: > I think you found an error in gr_mkheader! In truth, it isn’t particularly > well tested

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

I think you found an error in gr_mkheader! In truth, it isn’t particularly well tested so I’m glad you are using it. I just pushed a commit to fix this to github. git pull the changes, rebuild, and try again. Let me know if it solves the issue for you. PWG On Dec 1, 2016, at 11:46 AM, AndroidT

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

Effective integration time was about 40 minutes. The beamshape is roughly 42 x 18 degrees from our array antenna. On 2016-12-01 15:54, Daniel R. Marlow wrote: > Hello, > > First, congrats to Marcus and CCERA. > > We are working at 21 cm (1420 MHz) and find that there are at least a few

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

Hello, First, congrats to Marcus and CCERA. We are working at 21 cm (1420 MHz) and find that there are at least a few pulsars not that far below B0329+54 (now called J0332+5434) in signal strength. Indeed, one of the interesting things is that owing to scintillation effects,

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

Keep in mind also that B0329+54 is really the only one within reasonable "reach" for an amateur in the northern hemisphere--the others are much fainter, although if one simply added another "gulp" of antenna every paycheque or two... Also, you need a stable clock--I'm using an OCXO, but a TCXO

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

Yes, they are Digiwave ANT2084--available on-line through WalMart as it happens. But any similar 4-bay antenna will work. We use 6 of them in a 2 x 3 array. I was using a commercial combiner, but it was lossy and had poor phase balance (actually any hybrid-tree style combiner will have issues

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

Hi Marcus, Brilliant. I am in the middle of assembling my own radio telescope, but had not thought Pulsar reception would be possible. I have a couple of questions on the RF Hardware. I see from some other updates, that the antenna is essentially sets of a 4 bay HDTV antenna. How are you

Re: [Discuss-gnuradio] rx_time tag after drop

Hello Meelis, My understanding is that the offset is the index of the sample within GNU Radio which the tag is attached to. Since dropped samples never enter GNU Radio the behavior is correct. The rx_time is one of the few tags where this behavior is potentially confusing since the rx_time is a

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

This is 6MHz, centered at 611MHz (a notionally-TV channel that is allocated in North America and Caribbean to Radio Astronomy). I used a PFB channelizer with individual detectors, and then delay adjustment after the detectors and then simply added, low-pass filtered, then resampled to a precise

Re: [Discuss-gnuradio] Probable pulsar observing success at CCERA

That's awesome work! Thanks for sharing it. How much bandwidth are you observing and did you also use de-dispersion? Matt On Thu, Dec 1, 2016 at 10:45 AM, Marcus D. Leech wrote: > One of the many goals we set for ourselves at the Canadian Centre for > Experimental Radio

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Thank you once again Paul. ls -la drwx-- 1 Username Username 4096 Dec 1 13:40 . drwx-- 1 Username Username 12288 Nov 30 16:21 .. -rwx-- 1 Username Username 7683964928 Nov 20 18:23 Sample-408MHz gr_mkheader -r 1.8e6 -t sc16 -f 408e6 -l 1920991232 Sample-408MHz Now I have

[Discuss-gnuradio] Probable pulsar observing success at CCERA

One of the many goals we set for ourselves at the Canadian Centre for Experimental Radio Astronomy was to successfully observe pulsar B0329+54 before spring. This pulsar is the only one bright enough for a small observatory in the northern hemisphere to observe. See our update:

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

It probably can’t find the header. The command # gr_mkheader -r 1.8e6 -t sc16 -f 408e6 -l 1920991232 Sample-408MHz should produce the file "Sample-408MHz.hdr" Check that the file Sample-408MHz.hdr is produced. You can read it with # gr_read_file_metadata Sample-408MHz.hdr -D Then, #

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Thank you Paul, I got this; sample_cnt_end=50,final_index=1920991232 Empty Header, quitting. I followed all your instructions and double checked all parameters. I did filesize / 4 for sample count. I did this first: gr_mkheader -r 1.8e6 -t sc16 -f 408e6 -l 1920991232 Sample-408MHz Then

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Marcus, Thanks for taking the time. It is possible I re-installed a new version of VOLK. I'll try a fresh build and see what that gets me. I also should have mentioned that the filter works OK for a while then segfaults. A couple of packets always pass through the clock sync block I'm using

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

There are two different metadata types: 1) Inline 2) Detached Here, you are using the detached headers. With detached, the raw samples are in a file, say myfile.sc16, and the metadata in myfile.sc16.hdr. See [1] for more information on GNURadio metadata. So suppose you have myfile.sc16 as your

Re: [Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Hi Devin, I don't think it's a kernel problem – all your calculations happen in userland, and the kernel has not much to say with respect to the instructions used. The most common reason for this kind of misbehaviour is in fact a problem with how the application (in this case, your GNU Radio

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Thank you Paul, I never heard of gr-analysis before. So I tried this: gr_mkheader -r 1.8e6 -t sc16 -f 408e6 myheader This only created myheader.hdr file. How can I link this to my actual recording sample which is 16-bit IQ pair and then convert it to CFile? Do I concatenate the files? put

Re: [Discuss-gnuradio] [Newbie] Decoding a signal and printing binary data

Here are a few posts that I've found helpful in the past. They make for a good jumping-off point and will help you get familiar with the steps, terminology, and tools involved. [1] https://nccgroup.github.io/RFTM/fsk_receiver.html [2]

Re: [Discuss-gnuradio] Loading 16-bit IQ pairs in GnuRadio Companion

Please copy the list next time so other folks can respond besides me. Just attach a file sink to the ishort to complex block. There’s also a command-line tool called gr_fileman in gr-analysis [1] which will do this, but the file needs headers. If you don’t have them, you can generate with

[Discuss-gnuradio] Convert 16-bit IQ File to CFile

I have a 16-bit IQ pair recording sample, I can load it in GnuRadio with IShort to Complex block and it works well. Now how can I convert it to a Cfile where I will be able to use Gqrx and other tools that only accept "Cfile" format? Thank you ___

[Discuss-gnuradio] Segfault with volk_32fc_32f_dot_prod_32fc_a_avx

Hello, I'm having a problem with the above VOLK function segfaulting. I don't think I'm passing any incorrect values to VOLK. My problem could be that I'm on RHEL7 with (obviously) an older kernel: $ uname -a Linux 520842-mitll 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55 EST 2016

Re: [Discuss-gnuradio] Tunnel.py with USRP x310

Hi Julian, I’m using UHD 3.9.1. For now, I’m trying to run the example with only 1 PC, so I have the PC and the USRP both connected to a network switch. Then, I plan to add the second PC with its USRP to the switch as well. I think it’s should be the configuration in order to have two PCs with

Re: [Discuss-gnuradio] Reg: gr-ieee 802.11 and wireshark settings for commercial NIC

Sumit, try the 5 GHz band, not the 2.4GHz band. gr-ieee can decode ERP-OFDM PPDUs used in 5GHz but can't decode DSSS-OFDM PPDUs (=OFDM packets with DSSS PLCP header) typically used in 2.4GHz band. On Tue, Nov 29, 2016 at 9:17 PM, Bastian Bloessl wrote: > Hi, > > On

[Discuss-gnuradio] pybombs and mako

This is ubuntu 16.04 on an Intel machine (high end). usual startup with recipe install, prefix init, etc. find . | grep mako yields /usr/lib/python2.7/dist-packages/mako and much underneath it. pybombs install gnuradio yields Install tree: | \- gnuradio | +- uhd | \-

Re: [Discuss-gnuradio] Question about OFDM Transmitter/Receiver

Thank you Martin, do you have a valid example on how to configure such parameters? I tried something like this: occupied_carriers = ([x for x in [y for y in range(-31,33) if y not in range(-31,33,3)]], ) But it did not work. I also tried to change the pilot_carriers configuration. But then

Re: [Discuss-gnuradio] Tunnel.py with USRP x310

Hi Danilo, what version of UHD are you using and how exactly does your network configuration look like? Also, you might want to post this question to the usrp-users mailing list. Cheers, Julian On 12/01/2016 11:29 AM, Danilo De Donno wrote: > Dear all, > for several days, I made attempts to run

[Discuss-gnuradio] [Newbie] Decoding a signal and printing binary data

Hey, Sorry for the newbie question, but I have a signal where I found it's center frequency and with +12khz and -12khz of the center, I have peaks. So as far as I know, if you have 2 peaks on different frequencies, it's 2FSK modulation. Now knowing this, how can I demodulate and finally print out

[Discuss-gnuradio] Tunnel.py with USRP x310

Dear all, for several days, I made attempts to run the GNUradio ofdm/tunnel.py example, without any success. I have GNUradio 3.7.10 installed on a Desktop PC connected to a USRP x310. Whenever I try to run the tunnel.py example and use ifconfig to set my IP address, I receive the following

[Discuss-gnuradio] rx_time tag after drop

Hello everyone We have been wondering about rx_time tags after drop. In [1] it is stated that "Then, if a dropped packet or overflow are detected, it sends a new rx_time tag." The tag debugger output is shown below. Initially we thought that in the tag the time and the offset are bound together.