Re: [Discuss-gnuradio] Simple FM receiver GRC error
On 08/06/12 15:14, ki6njf wrote: On Friday, June 08, 2012 02:43:56 PM Phil wrote: > On 08/06/12 13:04, ki6njf wrote: [snip] > > run the export PYTHONPATH=$PYTHONPATH:/home/jim/bin > > Thanks Marcus and Jim for the detailed instructions, however I still > cannot get this to work! > > This my python path: > > [phil@localhost trunk]$ cat $PYTHONPATH > cat: /usr/local/src/gr-osmosdr/include/osmosdr/:/home/phil/bin > > The path points to osmosdr_source_c.h. > > And these are still the same errors: > > Error 0: > Block - import_1 - Import(import): > Param - Import(import): > Import "import simple_fm_helper" failed. > > > I'm at my wits end. That was the error I was getting. I've found that I still get it if I do not start gnuradio-companion in the directory where simple_fm_helper is located. Apparently, that Import block/function is very simplistic and will only import from the directory that companion was started in. Thanks again Jim, I moved the grc file into my bin directory. Three errors down one to go. I must be nearly there. Error 0: Block - gr_freq_xlating_fir_filter_xxx_0 - Frequency Xlating FIR Filter(gr_freq_xlating_fir_filter_xxx): Sink - in(0): Port is not connected. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple FM receiver GRC error
On Friday, June 08, 2012 02:43:56 PM Phil wrote: > On 08/06/12 13:04, ki6njf wrote: [snip] > > run the export PYTHONPATH=$PYTHONPATH:/home/jim/bin > > Thanks Marcus and Jim for the detailed instructions, however I still > cannot get this to work! > > This my python path: > > [phil@localhost trunk]$ cat $PYTHONPATH > cat: /usr/local/src/gr-osmosdr/include/osmosdr/:/home/phil/bin > > The path points to osmosdr_source_c.h. > > And these are still the same errors: > > Error 0: > Block - import_1 - Import(import): >Param - Import(import): > Import "import simple_fm_helper" failed. > > > I'm at my wits end. That was the error I was getting. I've found that I still get it if I do not start gnuradio-companion in the directory where simple_fm_helper is located. Apparently, that Import block/function is very simplistic and will only import from the directory that companion was started in. -- 73s jim KI6NJF___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Does not benchmark_tx.py use make_packet in ofdm_packet_utils.py??
I`m running benchmark_tx.py . In my thought, benchmark_tx has to use make_packet in gnuradio/gr-digital/python/ofdm_packet_utils.py . However, Although I inputted a print code for tracing in the middle of make_packet codes , I could not see output on screen. Does not benchmark_tx.py use make_packet in ofdm_packet_utils.py to make a packet?? -- View this message in context: http://old.nabble.com/Does-not-benchmark_tx.py-use-make_packet-in-ofdm_packet_utils.py---tp33979200p33979200.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple FM receiver GRC error
On 08/06/12 13:04, ki6njf wrote: Phil, I just got simple_fm_rcv working today. I had to: open up a terminal cd to my radio flowdiagram directory - /home/jim/gnu_radio svn co https://www.cgran.org/svn/projects/simple_fm_rcv cd to the directory - in my case - /home/jim/gnu_radio/simple_fm_rcv/trunk/ make install export PYTHONPATH=$PYTHONPATH:/home/jim/bin then run gnuradio-companion then open simple_fm_rcv.grc it works! Before this, I was getting an import error for simple_fm_helper no matter where I put the simple_fm_helper program or what I set the PYTHONPATH to. now each time I run gnuradio-companion or the python variant, I have to run the export PYTHONPATH=$PYTHONPATH:/home/jim/bin Thanks Marcus and Jim for the detailed instructions, however I still cannot get this to work! This my python path: [phil@localhost trunk]$ cat $PYTHONPATH cat: /usr/local/src/gr-osmosdr/include/osmosdr/:/home/phil/bin The path points to osmosdr_source_c.h. And these are still the same errors: Error 0: Block - import_1 - Import(import): Param - Import(import): Import "import simple_fm_helper" failed. Error 1: Block - cur_freq - Variable(variable): Param - Value(value): Value "simple_fm_helper.freq_select(ifreq,preselect)" cannot be evaluated: name 'simple_fm_helper' is not defined Error 2: Block - rtext_0 - WX GUI Static Text(variable_static_text): Param - Default Value(value): Value "cur_freq" cannot be evaluated: name 'cur_freq' is not defined Error 3: Block - gr_freq_xlating_fir_filter_xxx_0 - Frequency Xlating FIR Filter(gr_freq_xlating_fir_filter_xxx): Sink - in(0): Port is not connected. I'm at my wits end. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
On Thu, Jun 7, 2012 at 7:11 PM, Tom Rondeau wrote: > On Thu, Jun 7, 2012 at 1:30 PM, Nazmul Islam > wrote: > > I got a partial answer to my previously posted question :). When I pass > the > > complex baseband I & Q with a costas loop block, the output indeed looks > > like a square wave. > > > > Does it mean that external reference clock does not correct the > > phase/carrier offset error? Does it only solve the timing error issue? > > > > Thanks, > > > > Nazmul > > Glad that you are able to get far enough to recover it. As for the > remaining 6 kHz offset, what's the RF frequency? What does 6 kHz > translate into for a parts per million? While I would expect them to > be the same with both locked to the same external clock, we are > talking about reality here, so things aren't always that cooperative. > I can't think what would cause this kind of an offset, though, as it > seems rather large. > > Maybe someone with more hands-on hardware experience with precision > equipment can jump in here. > > Tom > 6kHz is way too high. They should be cycle-locked. What is the amplitude of the clock signal you're feeding into the USRP2? --n > > > > On Thu, Jun 7, 2012 at 12:00 PM, Nazmul Islam < > mnis...@winlab.rutgers.edu> > > wrote: > >> > >> Hi Tom, > >> > >> First of all, thanks a lot for your detailed reply. I appreciate it. I > did > >> as you told in the last email, i.e., I transmitted a square wave > (switching > >> between 0.5 to -0.5). The sqaure wave's period was 1 ms and the sampling > >> rate was 1 MHz. I have attached the real part of the outputs with the > >> email. > >> > >> The output shows a phase shift after every 500 samples, i.e., half > period > >> of the square wave with 1 MHz sampling rate. The sinusoidal nature of > the > >> output probably comes from frequency offset of the two USRP's. I > expected > >> this for an internal clock source. > >> > >> However, I see a 6 kHz frequency offset (3 sine period per 0.5 ms) even > >> with the presence of an external clock. The external clock is driving > both > >> USRP's. The E LED is on. I am using a sine wave with 10 MHz frequency & > 7 > >> dBm amplitude as the external clock. I also put the clock source > options in > >> grc as external. Do I need to make any other changes in the GRC blocks > to > >> inform USRP about the external source? > >> > >> Any suggestions will be appreciated. Thanks for all of your help. > >> > >> Nazmul > >> > >> On Fri, May 25, 2012 at 1:40 PM, Tom Rondeau wrote: > >>> > >>> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam > >>> wrote: > >>> > Hello, > >>> > > >>> > I want to transmit a continuous stream of 1's or 0's (with bpsk > >>> > modulation) > >>> > and record the received I-Q stream. I am trying to use the > >>> > 'digital_bert_tx.py' code for transmission and the uhd_rx_cfile code > >>> > (gr-uhd/apps) for reception. Thereafter, I use the > read_complex_binary > >>> > code > >>> > to read the data in Matlab. > >>> > > >>> > Surprisingly, I am receiving similar type of I-Q stream (around 0.3 > + j > >>> > 0.3) > >>> > for both 1 and 0 transmission. I am using the following commands: > >>> > > >>> > self._bits = gr.vector_source_b([1,], True) (I > >>> > either > >>> > transmit infinite 1 or infinit 0's. When I transmit infinite 0's, I > >>> > replace > >>> > '1' by '0' in the command) > >>> > > >>> > ./digital_bert_naz_tx.py -r 5M -m bpsk -f 450M --gain 0.1 > >>> > --non-differential(I am using non-differential since I want to > see > >>> > the > >>> > different amplitude levels for '1's or 0's) > >>> > > >>> > ./uhd_rx_cfile -N 1000 -f 450M --samp-rate 5M file.dat (Since I am > >>> > using > >>> > bpsk, sample-rate should be equal to bit rate, I assume) > >>> > > >>> > Ideally, the I-Q stream of bpsk should show 180 degree phase shift > for > >>> > 1 and > >>> > 0 transmission. I am getting the same value for both transmission. > Can > >>> > anyone suggest where I am making mistakes? > >>> > > >>> > > >>> > Thanks, > >>> > > >>> > Nazmul > >>> > >>> > >>> Nazmul, > >>> Hard to say from this info. A few things to note on, though. First, > >>> 1000 samples isn't that much. There are startup transients in > >>> hardware, so you might just be seeing effects of those. I'd capture > >>> ten thousand or a million and just read out the last 1000. > >>> > >>> Also, the transmitter and receiver are running on two different > >>> clocks, so their frequency and phases aren't going to match, unless > >>> you've locked them to the same source. It'd be hard to say what you'll > >>> see, exactly, due to this. That's why we use recovery loops for all of > >>> these things. > >>> > >>> What I would recommend is to create a transmitter that transmits a > >>> long string of 1's followed by a long string of 0's (100 or 200 each). > >>> When you plot the last 1000 samples, you should see something that > >>> moves between two amplitudes. I wouldn't trust what you see from one > >>> run to another, s
Re: [Discuss-gnuradio] Simple FM receiver GRC error
>
>
> On Friday, June 08, 2012 12:34:53 PM Phil wrote:
>
> > I'm sorry to have to ask more questions.
>
> >
>
> > The "Simple FM receiver" by Marcus Leech would seem to be simple in name
>
> > only. I'm sure that I have followed the installation instructions to the
>
> > letter but I still end up with an error as follows:
>
> >
>
> > <<< Welcome to GNU Radio Companion 3.5.3.2 >>>
>
> >
>
> > Loading: "/home/phil/bin/simple_fm_helper.py"
>
> > Error: Start tag expected, '<' not found, line 1, column 1
>
> >
>
> > >>> Failure
>
> >
>
> > Showing: ""
>
> >
>
> > In case I've missed something important, this is what I did. I opened
>
> > "simple_fm_rcv.grc" with gnuradio-companion and there aren't any '<' in
>
> > the file simple_fm_helper.py.
>
>
>
> Phil, I just got simple_fm_rcv working today.
>
>
>
> I had to:
>
>
>
> open up a terminal
>
>
>
> cd to my radio flowdiagram directory - /home/jim/gnu_radio
>
>
>
> svn co https://www.cgran.org/svn/projects/simple_fm_rcv
>
>
>
> cd to the directory - in my case -
> /home/jim/gnu_radio/simple_fm_rcv/trunk/
>
>
>
> make install
>
>
>
> export PYTHONPATH=$PYTHONPATH:/home/jim/bin
>
>
>
> then run gnuradio-companion
>
>
>
> then open simple_fm_rcv.grc
>
>
>
> it works! Before this, I was getting an import error for
> simple_fm_helper no matter where I put the simple_fm_helper program or
> what I set the PYTHONPATH to.
>
>
>
> now each time I run gnuradio-companion or the python variant, I have
> to run the export PYTHONPATH=$PYTHONPATH:/home/jim/bin
>
> statement from inside the terminal that I'll start gnuradio-companion
> from.
>
>
>
> {I've not figured out (yet) where Kubuntu 12.04 keeps the .profile or
> xxx file that would permanently set the python path and allow me to
> start companion from the GUI.}
>
>
>
> 73s
>
> jim
>
> ki6njf
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
Put the export commands in your $HOME/.bashrc
--
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] Simple FM receiver GRC error
On Friday, June 08, 2012 12:34:53 PM Phil wrote:
> I'm sorry to have to ask more questions.
>
> The "Simple FM receiver" by Marcus Leech would seem to be simple in name
> only. I'm sure that I have followed the installation instructions to the
> letter but I still end up with an error as follows:
>
> <<< Welcome to GNU Radio Companion 3.5.3.2 >>>
>
> Loading: "/home/phil/bin/simple_fm_helper.py"
> Error: Start tag expected, '<' not found, line 1, column 1
>
> >>> Failure
>
> Showing: ""
>
> In case I've missed something important, this is what I did. I opened
> "simple_fm_rcv.grc" with gnuradio-companion and there aren't any '<' in
> the file simple_fm_helper.py.
Phil, I just got simple_fm_rcv working today.
I had to:
open up a terminal
cd to my radio flowdiagram directory - /home/jim/gnu_radio
svn co https://www.cgran.org/svn/projects/simple_fm_rcv
cd to the directory - in my case - /home/jim/gnu_radio/simple_fm_rcv/trunk/
make install
export PYTHONPATH=$PYTHONPATH:/home/jim/bin
then run gnuradio-companion
then open simple_fm_rcv.grc
it works! Before this, I was getting an import error for simple_fm_helper no
matter where I put the simple_fm_helper program or what I set the PYTHONPATH
to.
now each time I run gnuradio-companion or the python variant, I have to run
the export PYTHONPATH=$PYTHONPATH:/home/jim/bin
statement from inside the terminal that I'll start gnuradio-companion from.
{I've not figured out (yet) where Kubuntu 12.04 keeps the .profile or xxx
file that would permanently set the python path and allow me to start
companion from the GUI.}
73s
jim
ki6njf___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simple FM receiver GRC error
I'm sorry to have to ask more questions. The "Simple FM receiver" by Marcus Leech would seem to be simple in name only. I'm sure that I have followed the installation instructions to the letter but I still end up with an error as follows: <<< Welcome to GNU Radio Companion 3.5.3.2 >>> Loading: "/home/phil/bin/simple_fm_helper.py" Error: Start tag expected, '<' not found, line 1, column 1 >>> Failure Showing: "" In case I've missed something important, this is what I did. I opened "simple_fm_rcv.grc" with gnuradio-companion and there aren't any '<' in the file simple_fm_helper.py. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
On Thu, Jun 7, 2012 at 1:30 PM, Nazmul Islam wrote: > I got a partial answer to my previously posted question :). When I pass the > complex baseband I & Q with a costas loop block, the output indeed looks > like a square wave. > > Does it mean that external reference clock does not correct the > phase/carrier offset error? Does it only solve the timing error issue? > > Thanks, > > Nazmul Glad that you are able to get far enough to recover it. As for the remaining 6 kHz offset, what's the RF frequency? What does 6 kHz translate into for a parts per million? While I would expect them to be the same with both locked to the same external clock, we are talking about reality here, so things aren't always that cooperative. I can't think what would cause this kind of an offset, though, as it seems rather large. Maybe someone with more hands-on hardware experience with precision equipment can jump in here. Tom > On Thu, Jun 7, 2012 at 12:00 PM, Nazmul Islam > wrote: >> >> Hi Tom, >> >> First of all, thanks a lot for your detailed reply. I appreciate it. I did >> as you told in the last email, i.e., I transmitted a square wave (switching >> between 0.5 to -0.5). The sqaure wave's period was 1 ms and the sampling >> rate was 1 MHz. I have attached the real part of the outputs with the >> email. >> >> The output shows a phase shift after every 500 samples, i.e., half period >> of the square wave with 1 MHz sampling rate. The sinusoidal nature of the >> output probably comes from frequency offset of the two USRP's. I expected >> this for an internal clock source. >> >> However, I see a 6 kHz frequency offset (3 sine period per 0.5 ms) even >> with the presence of an external clock. The external clock is driving both >> USRP's. The E LED is on. I am using a sine wave with 10 MHz frequency & 7 >> dBm amplitude as the external clock. I also put the clock source options in >> grc as external. Do I need to make any other changes in the GRC blocks to >> inform USRP about the external source? >> >> Any suggestions will be appreciated. Thanks for all of your help. >> >> Nazmul >> >> On Fri, May 25, 2012 at 1:40 PM, Tom Rondeau wrote: >>> >>> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam >>> wrote: >>> > Hello, >>> > >>> > I want to transmit a continuous stream of 1's or 0's (with bpsk >>> > modulation) >>> > and record the received I-Q stream. I am trying to use the >>> > 'digital_bert_tx.py' code for transmission and the uhd_rx_cfile code >>> > (gr-uhd/apps) for reception. Thereafter, I use the read_complex_binary >>> > code >>> > to read the data in Matlab. >>> > >>> > Surprisingly, I am receiving similar type of I-Q stream (around 0.3 + j >>> > 0.3) >>> > for both 1 and 0 transmission. I am using the following commands: >>> > >>> > self._bits = gr.vector_source_b([1,], True) (I >>> > either >>> > transmit infinite 1 or infinit 0's. When I transmit infinite 0's, I >>> > replace >>> > '1' by '0' in the command) >>> > >>> > ./digital_bert_naz_tx.py -r 5M -m bpsk -f 450M --gain 0.1 >>> > --non-differential (I am using non-differential since I want to see >>> > the >>> > different amplitude levels for '1's or 0's) >>> > >>> > ./uhd_rx_cfile -N 1000 -f 450M --samp-rate 5M file.dat (Since I am >>> > using >>> > bpsk, sample-rate should be equal to bit rate, I assume) >>> > >>> > Ideally, the I-Q stream of bpsk should show 180 degree phase shift for >>> > 1 and >>> > 0 transmission. I am getting the same value for both transmission. Can >>> > anyone suggest where I am making mistakes? >>> > >>> > >>> > Thanks, >>> > >>> > Nazmul >>> >>> >>> Nazmul, >>> Hard to say from this info. A few things to note on, though. First, >>> 1000 samples isn't that much. There are startup transients in >>> hardware, so you might just be seeing effects of those. I'd capture >>> ten thousand or a million and just read out the last 1000. >>> >>> Also, the transmitter and receiver are running on two different >>> clocks, so their frequency and phases aren't going to match, unless >>> you've locked them to the same source. It'd be hard to say what you'll >>> see, exactly, due to this. That's why we use recovery loops for all of >>> these things. >>> >>> What I would recommend is to create a transmitter that transmits a >>> long string of 1's followed by a long string of 0's (100 or 200 each). >>> When you plot the last 1000 samples, you should see something that >>> moves between two amplitudes. I wouldn't trust what you see from one >>> run to another, so just do it at the same time. >>> >>> Tom >> >> >> >> >> -- >> Muhammad Nazmul Islam >> >> Graduate Student >> Electrical & Computer Engineering >> Wireless Information & Networking Laboratory >> Rutgers, USA. >> > > > > -- > Muhammad Nazmul Islam > > Graduate Student > Electrical & Computer Engineering > Wireless Information & Networking Laboratory > Rutgers, USA. > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.or
Re: [Discuss-gnuradio] What interference signals exist in 5Ghz ?
On Thu, Jun 7, 2012 at 5:05 PM, Guanbo ZHENG wrote: > I checked the US spectrum allocation chart, there are some devices like > radar and satellite communication in the 5GHz bands. > > Based on the comment of Cisco, > "It is generally true that fewer devices currently operating at 5 GHz are > causing interference as compared to 2.4-GHz devices. But this will change > over time. Just as everyone moved from 900 MHz to 2.4 GHz to avoid > interference, the "band jumping" effect will catch up with 5 GHz. Some > devices that already exist at 5 GHz include cordless phones, radar, > perimeter sensors, and digital satellite." > > http://www.cisco.com/en/US/prod/collateral/wireless/ps9391/ps9393/ps9394/prod_white_paper0900aecd807395a9_ns736_Networking_Solutions_White_Paper.html > > Guanbo > > > On Thu, Jun 7, 2012 at 12:47 PM, Sangho Oh wrote: >> >> It is well know that microwaves, bluetooth, cordless phones are the major >> interference sources in 2.4Ghz. >> But what devices (with non WiFi standards) are using 5Ghz band used by >> 802.11n devices? >> Specifically for 5180-5350, 5745-5805Mhz. There are a handful of point-to-point and point-to-multipoint devices that exist that transmit at 5 GHz. How much of that is deployed, I can't say. The FCC's new Spectrum Dashboard is actually a nice tool for looking into who owns licenses in different frequencies and for different services in your area. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_rx kept showing 000000...
"O" = overrun (PC not keeping up with received data from usrp or audio card) "U" = underrun (PC not providing data quickly enough) You can try to reduce the sampling rate or use a better powerful machine. :) On Thu, Jun 7, 2012 at 2:15 PM, Weixian Zhou wrote: > I had successfully transmit data without any problems using > benchmark_tx/benchmark_rx moment ago: > *./benchmark_rx.py -f 2.42G -r 2M* > *./benchmkar_tx.py -f 2.42G -r 2M* > > But after a few tries, the rx end started to show ... The wired thing > is that I input the same parameters as before but the result is different: > *bell@bell-HP-Compaq-4000-Pro-SFF-PC:~/Desktop/USRP/gnuradio/gr-digital/end$ > ./benchmark_rx.py -f 2.47G -r 2M* > *linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.001-129-g23344268 > * > * > * > *>>> gr_fir_ccf: using SSE* > *-- Opening a USRP2/N-Series device...* > *-- Current recv frame size: 1472 bytes* > *-- Current send frame size: 1472 bytes* > * > * > *UHD Warning:* > *Unable to set the thread priority. Performance may be negatively > affected.* > *Please see the general application notes in the manual for > instructions.* > *EnvironmentError: OSError: error in pthread_setschedparam* > * > * > *No gain specified.* > *Setting gain to 49.50 (from [0.00, 99.00])* > *Warning: Failed to enable realtime scheduling.* > *Using Volk machine: ssse3_32* > * > OO > * > > I am using the two USRP N210, the daughter boards are both XCVR2450. > Ubuntu 12.04, latest version of UHD and GNU Radio. > -- > Regards, > Weixian Zhou > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Regards, Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What interference signals exist in 5Ghz ?
I checked the US spectrum allocation chart, there are some devices like radar and satellite communication in the 5GHz bands. Based on the comment of Cisco, "It is generally true that fewer devices currently operating at 5 GHz are causing interference as compared to 2.4-GHz devices. But this will change over time. Just as everyone moved from 900 MHz to 2.4 GHz to avoid interference, the "band jumping" effect will catch up with 5 GHz. Some devices that already exist at 5 GHz include cordless phones, radar, perimeter sensors, and digital satellite." http://www.cisco.com/en/US/prod/collateral/wireless/ps9391/ps9393/ps9394/prod_white_paper0900aecd807395a9_ns736_Networking_Solutions_White_Paper.html Guanbo On Thu, Jun 7, 2012 at 12:47 PM, Sangho Oh wrote: > It is well know that microwaves, bluetooth, cordless phones are the major > interference sources in 2.4Ghz. > But what devices (with non WiFi standards) are using 5Ghz band used by > 802.11n devices? > Specifically for 5180-5350, 5745-5805Mhz. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Regards, Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Funcube dongle issues and a solution
Dne Thursday 07 June 2012 ob 22:38:51 je Alexandru Csete napisal(a): > On Thu, Jun 7, 2012 at 10:27 PM, Gasper Zejn wrote: > > Dne Thursday 07 June 2012 ob 21:59:24 je Alexandru Csete napisal(a): > >> On Thu, Jun 7, 2012 at 11:13 AM, Gasper Zejn wrote: > >> > a bit more on my setup: I'm using funcube as a source, tuned to > >> > 868.48M, LNA gain 20dB, mixer gain 12dB, connected to simple squelch > >> > (threshold=-40dB, alpha=1) and on to quadrature demodulation block. > >> > This block then outputs clearly visible binary signal when funcube is > >> > initialized properly. > >> > > >> > The observed signal is rated at 20kbit, so it's a bit on the upper > >> > limit of what Funcube can do, but it's still possible to get a decent > >> > read. It's a burst of bits every 5s from a power meter[1][2], and the > >> > first part is a lead- in and stays the same even if readings change. > >> > > >> > Somewhere in the funcube source block there is obviously something > >> > wrong with initialization. Running qthid after starting flow changes > >> > something in funcube that makes it output correct signal. Using this > >> > and the fact, that the lead-in stays the same, it seems the "corrupt" > >> > signal (viewed in scope) is sometimes a derivative of the expected > >> > signal - most of the time on zero, with spikes up and down on > >> > transitions, with timing corresponding to transitions in expected > >> > signal. > >> > >> Do you have the same frequency correction value in both qthid and the > >> FCD source? If yes, what is the value? > >> > >> Alex > > > > Ahh, yes. I had 0 in my flow and qthid was -120. > > > > So sorry to waste your precious time. > > No problem, time wasn't wasted since there is actually a bug in the > init part of fcd_source_c.xml: it checks whether correction is 115 > whereas it should check -120, but this bug is only triggered if your > initial correction is set to 115 ppm. > > I also realized that I never added 1 Hz resolution to qthid. > > Alex > Ah, that explains something then. I remember experimenting with correction, but I was looking at fcd_source_c.xml and, influenced by it, used 120 instead of -120, therefore not getting correct result and dismissing it as not the right parameter to tune. Any way, it's allways nice to see bugs fixed. :) Gasper ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Funcube dongle issues and a solution
On Thu, Jun 7, 2012 at 10:27 PM, Gasper Zejn wrote: > Dne Thursday 07 June 2012 ob 21:59:24 je Alexandru Csete napisal(a): >> On Thu, Jun 7, 2012 at 11:13 AM, Gasper Zejn wrote: >> > a bit more on my setup: I'm using funcube as a source, tuned to 868.48M, >> > LNA gain 20dB, mixer gain 12dB, connected to simple squelch >> > (threshold=-40dB, alpha=1) and on to quadrature demodulation block. This >> > block then outputs clearly visible binary signal when funcube is >> > initialized properly. >> > >> > The observed signal is rated at 20kbit, so it's a bit on the upper limit >> > of what Funcube can do, but it's still possible to get a decent read. >> > It's a burst of bits every 5s from a power meter[1][2], and the first >> > part is a lead- in and stays the same even if readings change. >> > >> > Somewhere in the funcube source block there is obviously something wrong >> > with initialization. Running qthid after starting flow changes something >> > in funcube that makes it output correct signal. Using this and the fact, >> > that the lead-in stays the same, it seems the "corrupt" signal (viewed >> > in scope) is sometimes a derivative of the expected signal - most of the >> > time on zero, with spikes up and down on transitions, with timing >> > corresponding to transitions in expected signal. >> >> Do you have the same frequency correction value in both qthid and the >> FCD source? If yes, what is the value? >> >> Alex > > Ahh, yes. I had 0 in my flow and qthid was -120. > > So sorry to waste your precious time. No problem, time wasn't wasted since there is actually a bug in the init part of fcd_source_c.xml: it checks whether correction is 115 whereas it should check -120, but this bug is only triggered if your initial correction is set to 115 ppm. I also realized that I never added 1 Hz resolution to qthid. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Funcube dongle issues and a solution
Dne Thursday 07 June 2012 ob 21:59:24 je Alexandru Csete napisal(a): > On Thu, Jun 7, 2012 at 11:13 AM, Gasper Zejn wrote: > > a bit more on my setup: I'm using funcube as a source, tuned to 868.48M, > > LNA gain 20dB, mixer gain 12dB, connected to simple squelch > > (threshold=-40dB, alpha=1) and on to quadrature demodulation block. This > > block then outputs clearly visible binary signal when funcube is > > initialized properly. > > > > The observed signal is rated at 20kbit, so it's a bit on the upper limit > > of what Funcube can do, but it's still possible to get a decent read. > > It's a burst of bits every 5s from a power meter[1][2], and the first > > part is a lead- in and stays the same even if readings change. > > > > Somewhere in the funcube source block there is obviously something wrong > > with initialization. Running qthid after starting flow changes something > > in funcube that makes it output correct signal. Using this and the fact, > > that the lead-in stays the same, it seems the "corrupt" signal (viewed > > in scope) is sometimes a derivative of the expected signal - most of the > > time on zero, with spikes up and down on transitions, with timing > > corresponding to transitions in expected signal. > > Do you have the same frequency correction value in both qthid and the > FCD source? If yes, what is the value? > > Alex Ahh, yes. I had 0 in my flow and qthid was -120. So sorry to waste your precious time. Gasper ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble with gnuradio and AMD32
On 06/07/2012 01:14 PM, Josh Blum wrote: > > > On 06/07/2012 01:09 PM, Tom Rondeau wrote: >> On Fri, Jun 1, 2012 at 3:12 PM, Igor Volodin wrote: >>> Hello, all >>> >>> My configuration: >>> Linux Xubuntu 12.04 >>> AMD Athlon XP 2400 >>> Linux ghost32 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012 >>> i686 athlon i386 GNU/Linux >>> >>> >>> >>> I am compiled latest version of gnuradio, and tried to run simple grc file: >>> http://superkuh.com/simplest.grc , and got following error: >>> >>> >>> (python:3350): GLib-GObject-CRITICAL **: g_param_spec_double: assertion >>> `default_value >= minimum && default_value <= maximum' failed >>> >>> (python:3350): GLib-GObject-CRITICAL **: g_object_class_install_property: >>> assertion `G_IS_PARAM_SPEC (pspec)' failed >>> >>> (python:3350): GLib-GObject-WARNING **: g_object_notify: object class >>> `GdkScreenX11' has no property named `resolution' >>> Using Volk machine: generic >> >> Igor, >> >> I've updated the code in git that should fix this problem you're >> having. The 'generic' machine didn't have an alignment at all, so it's >> uncertain what was being returned. I've set it up to return 1 now, so >> it should work. >> > > No, the generic alignment defaulted to 1 already. > > The bug is that the multiply block is passing 0 into the set alignment > multiple > > 1/sizeof(complex) is 0 -> due to integer math > Heres how I handled it in gr extras. Not using the alignment call, but same basic idea. A std::max in the scheduler code would fix this issue everywhere though https://github.com/guruofquality/grextras/blob/master/lib/multiply.cc#L101 -josh >> Tom >> >> ___ >> 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] Trouble with gnuradio and AMD32
On 06/07/2012 01:09 PM, Tom Rondeau wrote: > On Fri, Jun 1, 2012 at 3:12 PM, Igor Volodin wrote: >> Hello, all >> >> My configuration: >> Linux Xubuntu 12.04 >> AMD Athlon XP 2400 >> Linux ghost32 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012 >> i686 athlon i386 GNU/Linux >> >> >> >> I am compiled latest version of gnuradio, and tried to run simple grc file: >> http://superkuh.com/simplest.grc , and got following error: >> >> >> (python:3350): GLib-GObject-CRITICAL **: g_param_spec_double: assertion >> `default_value >= minimum && default_value <= maximum' failed >> >> (python:3350): GLib-GObject-CRITICAL **: g_object_class_install_property: >> assertion `G_IS_PARAM_SPEC (pspec)' failed >> >> (python:3350): GLib-GObject-WARNING **: g_object_notify: object class >> `GdkScreenX11' has no property named `resolution' >> Using Volk machine: generic > > Igor, > > I've updated the code in git that should fix this problem you're > having. The 'generic' machine didn't have an alignment at all, so it's > uncertain what was being returned. I've set it up to return 1 now, so > it should work. > No, the generic alignment defaulted to 1 already. The bug is that the multiply block is passing 0 into the set alignment multiple 1/sizeof(complex) is 0 -> due to integer math > Tom > > ___ > 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] Trouble with gnuradio and AMD32
On Fri, Jun 1, 2012 at 3:12 PM, Igor Volodin wrote: > Hello, all > > My configuration: > Linux Xubuntu 12.04 > AMD Athlon XP 2400 > Linux ghost32 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012 > i686 athlon i386 GNU/Linux > > > > I am compiled latest version of gnuradio, and tried to run simple grc file: > http://superkuh.com/simplest.grc , and got following error: > > > (python:3350): GLib-GObject-CRITICAL **: g_param_spec_double: assertion > `default_value >= minimum && default_value <= maximum' failed > > (python:3350): GLib-GObject-CRITICAL **: g_object_class_install_property: > assertion `G_IS_PARAM_SPEC (pspec)' failed > > (python:3350): GLib-GObject-WARNING **: g_object_notify: object class > `GdkScreenX11' has no property named `resolution' > Using Volk machine: generic Igor, I've updated the code in git that should fix this problem you're having. The 'generic' machine didn't have an alignment at all, so it's uncertain what was being returned. I've set it up to return 1 now, so it should work. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Funcube dongle issues and a solution
On Thu, Jun 7, 2012 at 11:13 AM, Gasper Zejn wrote: > > a bit more on my setup: I'm using funcube as a source, tuned to 868.48M, LNA > gain 20dB, mixer gain 12dB, connected to simple squelch (threshold=-40dB, > alpha=1) and on to quadrature demodulation block. This block then outputs > clearly visible binary signal when funcube is initialized properly. > > The observed signal is rated at 20kbit, so it's a bit on the upper limit of > what Funcube can do, but it's still possible to get a decent read. It's a > burst of bits every 5s from a power meter[1][2], and the first part is a lead- > in and stays the same even if readings change. > > Somewhere in the funcube source block there is obviously something wrong with > initialization. Running qthid after starting flow changes something in funcube > that makes it output correct signal. Using this and the fact, that the lead-in > stays the same, it seems the "corrupt" signal (viewed in scope) is sometimes a > derivative of the expected signal - most of the time on zero, with spikes up > and down on transitions, with timing corresponding to transitions in expected > signal. Do you have the same frequency correction value in both qthid and the FCD source? If yes, what is the value? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] benchmark_rx kept showing 000000...
I had successfully transmit data without any problems using benchmark_tx/benchmark_rx moment ago: *./benchmark_rx.py -f 2.42G -r 2M* *./benchmkar_tx.py -f 2.42G -r 2M* But after a few tries, the rx end started to show ... The wired thing is that I input the same parameters as before but the result is different: *bell@bell-HP-Compaq-4000-Pro-SFF-PC:~/Desktop/USRP/gnuradio/gr-digital/end$ ./benchmark_rx.py -f 2.47G -r 2M* *linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.001-129-g23344268* * * *>>> gr_fir_ccf: using SSE* *-- Opening a USRP2/N-Series device...* *-- Current recv frame size: 1472 bytes* *-- Current send frame size: 1472 bytes* * * *UHD Warning:* *Unable to set the thread priority. Performance may be negatively affected.* *Please see the general application notes in the manual for instructions.* *EnvironmentError: OSError: error in pthread_setschedparam* * * *No gain specified.* *Setting gain to 49.50 (from [0.00, 99.00])* *Warning: Failed to enable realtime scheduling.* *Using Volk machine: ssse3_32* * OO * I am using the two USRP N210, the daughter boards are both XCVR2450. Ubuntu 12.04, latest version of UHD and GNU Radio. -- Regards, Weixian Zhou ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Front-end board for GPS / GNSS
I've been working on a front-end board suitable for GPS and other GNSS systems. It might be of interest to the GNU Radio community. Goals for the project: - high-quality signals from all current and near-future GNSS systems (GPS, Glonass, Galileo, Compass) - wide bandwidth---provides three 50 MHz channels, nominally at L1, L2, and L5 - low cost---currently about $170 parts cost in single quantity, ~$110 in qty 100 - simplicity of use---emits streams of 2-bit samples to gigabit Ethernet, feeding a downstream software-receiver farm - two baseband clock inputs for use by timing receivers---any combination of 10 MHz, 100 MHz, 1 PPS - tunability typically from 0.7 to 2.2 GHz on each channel independently, for non-GPS applications such as radio astronomy - easy to fabricate and procure parts---4-layer PCB, everything available from friendly distributors such as Digikey and Mouser - free and open-source licensing: TAPR Open Hardware License version 1.0 for hardware, GPLv2 for HDL, firmware, and software So far I have a prototype board outputting bits from which GPS signals on L1 and L2 have been successfully acquired and tracked. Next steps are to play with acquiring some GPS L5, Glonass, and Galileo signals, and to apply some minor cleanups to the hardware for the next spin. The current design files, including schematic, PCB layout and artwork, HDL, support software, and a sample sky recording of simultaneous wideband L1 and L2, are available here: http://pmonta.com/blog/2012/06/04/gnss-firehose/ http://github.com/pmonta/GNSS_Firehose The hardware and HDL are not quite in their final forms yet, but it seems best to at least announce and get a discussion going so I can benefit from any feedback, rather than waiting for every last thing to be complete, which might be a few months down the road. One could get similar overall capability with two or three USRP boxes (suitably synchronized), but this starts to get expensive. I've used a USRP1 for some time, and while it's a great tool, the bandwidth is limited and it seems geared toward high-spectral-efficiency signals with many (>=8) bits per sample. Cheers, Peter Monta ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What interference signals exist in 5Ghz ?
It is well know that microwaves, bluetooth, cordless phones are the major interference sources in 2.4Ghz. But what devices (with non WiFi standards) are using 5Ghz band used by 802.11n devices? Specifically for 5180-5350, 5745-5805Mhz. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recording continuous I-Q stream and frequency offset with an external reference clock
I got a partial answer to my previously posted question :). When I pass the complex baseband I & Q with a costas loop block, the output indeed looks like a square wave. Does it mean that external reference clock does not correct the phase/carrier offset error? Does it only solve the timing error issue? Thanks, Nazmul On Thu, Jun 7, 2012 at 12:00 PM, Nazmul Islam wrote: > Hi Tom, > > First of all, thanks a lot for your detailed reply. I appreciate it. I did > as you told in the last email, i.e., I transmitted a square wave (switching > between 0.5 to -0.5). The sqaure wave's period was 1 ms and the sampling > rate was 1 MHz. I have attached the real part of the outputs with the > email. > > The output shows a phase shift after every 500 samples, i.e., half period > of the square wave with 1 MHz sampling rate. The sinusoidal nature of the > output probably comes from frequency offset of the two USRP's. I expected > this for an internal clock source. > > However, I see a 6 kHz frequency offset (3 sine period per 0.5 ms) even > with the presence of an external clock. The external clock is driving both > USRP's. The E LED is on. I am using a sine wave with 10 MHz frequency & 7 > dBm amplitude as the external clock. I also put the clock source options in > grc as external. Do I need to make any other changes in the GRC blocks to > inform USRP about the external source? > > Any suggestions will be appreciated. Thanks for all of your help. > > Nazmul > > On Fri, May 25, 2012 at 1:40 PM, Tom Rondeau wrote: > >> On Thu, May 24, 2012 at 7:07 PM, Nazmul Islam >> wrote: >> > Hello, >> > >> > I want to transmit a continuous stream of 1's or 0's (with bpsk >> modulation) >> > and record the received I-Q stream. I am trying to use the >> > 'digital_bert_tx.py' code for transmission and the uhd_rx_cfile code >> > (gr-uhd/apps) for reception. Thereafter, I use the read_complex_binary >> code >> > to read the data in Matlab. >> > >> > Surprisingly, I am receiving similar type of I-Q stream (around 0.3 + j >> 0.3) >> > for both 1 and 0 transmission. I am using the following commands: >> > >> > self._bits = gr.vector_source_b([1,], True) (I >> either >> > transmit infinite 1 or infinit 0's. When I transmit infinite 0's, I >> replace >> > '1' by '0' in the command) >> > >> > ./digital_bert_naz_tx.py -r 5M -m bpsk -f 450M --gain 0.1 >> > --non-differential(I am using non-differential since I want to see >> the >> > different amplitude levels for '1's or 0's) >> > >> > ./uhd_rx_cfile -N 1000 -f 450M --samp-rate 5M file.dat (Since I am >> using >> > bpsk, sample-rate should be equal to bit rate, I assume) >> > >> > Ideally, the I-Q stream of bpsk should show 180 degree phase shift for >> 1 and >> > 0 transmission. I am getting the same value for both transmission. Can >> > anyone suggest where I am making mistakes? >> > >> > >> > Thanks, >> > >> > Nazmul >> >> >> Nazmul, >> Hard to say from this info. A few things to note on, though. First, >> 1000 samples isn't that much. There are startup transients in >> hardware, so you might just be seeing effects of those. I'd capture >> ten thousand or a million and just read out the last 1000. >> >> Also, the transmitter and receiver are running on two different >> clocks, so their frequency and phases aren't going to match, unless >> you've locked them to the same source. It'd be hard to say what you'll >> see, exactly, due to this. That's why we use recovery loops for all of >> these things. >> >> What I would recommend is to create a transmitter that transmits a >> long string of 1's followed by a long string of 0's (100 or 200 each). >> When you plot the last 1000 samples, you should see something that >> moves between two amplitudes. I wouldn't trust what you see from one >> run to another, so just do it at the same time. >> >> Tom >> > > > > -- > Muhammad Nazmul Islam > > Graduate Student > Electrical & Computer Engineering > Wireless Information & Networking Laboratory > Rutgers, USA. > > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] File sink file size mismatch problem.
Hey Tom,
I thought i was replying to the list.(Apologies) I was thinking
about it on similar lines as you have. If the fllow graph is stopped by
hand the latency when i hit stop and when the flow graph stops it should
put some more data but i tried over running the flowgraph for a time span
of atleast 15 more seconds after the image-sink(fyi the image sink in this
case is quite different from the gr_file_sink because the image sink
displays the image as soon as the last bit that completes the image is
received.) and that is when i stop the flow graph which brings me to my
next question
Can 1 second bring about a 11KB file change??
Also the flowgraph that i was talking about is as follows.
http://i.imgur.com/1lJzD.png
The reason why i convert a float to char is because when i connect
Image Source (Float) ---> Image Sink (Float)
|
|
|> File SInk (Float) { Tjhe size
of the output file was 336KB (6 times the size of the input image).
as opposed to a float to char which got me closer to the actual size of the
input file. What i was aiming for was to have 2 files of equal size (the
output of the file sink in the above mentioned flow graph and the output of
the packet decoder at the receiver end and convert those values into
binaries and do a BER .)
Thank you so much again for your help,
Josh.
On Mon, Jun 4, 2012 at 8:56 PM, Tom Rondeau wrote:
> On Mon, Jun 4, 2012 at 11:12 AM, Josh Stevens
> wrote:
> > Tom,
> >
> > What i was also able to find was that when an image source (type =
> > float) is connected to a file sink(type float) the size of the received
> file
> > is around 700 KB while the size of the transmitted file is 65 KB and
> when i
> > use a float2char converter the size of the received file is found to be
> 76
> > KB.
> >
> > Is there a way around this or would i have to use a char type
> conversion on
> > every file i receive and convert it into a readable file to then
> calculate
> > the error rate ? Seems like a lengthy process.
> >
> > Thanks,
> > Josh.
>
> Josh,
>
> Some of this might just be a mismatch of data types. I'm not sure I
> properly followed how everything worked. One thing that wasn't clear
> was how the flowgraph is stopped. Does the image source just keep
> running until you stop it by hand? If that's the case, then what is
> the image source reading after it's read the entire file? Does it loop
> around? And if you're just stopping it by hand, then there's a latency
> a) between the program and the display b) between your eye and when
> you hit stop and c) from the time you hit stop and when the flowgraph
> actually stops. The blocks are all in threads and likely in the middle
> of a work function that's handling some number of samples; this will
> finish before the program closes. Basically, it will flush what's left
> to the file before closing.
>
> Could this be what's happening?
>
> Also, please reply on-list. I think any conversation about GNU Radio
> should be held publicly for the records for anyone else looking at
> similar problems. Thanks.
>
> Tom
>
>
> >
> > On Sun, Jun 3, 2012 at 11:53 AM, Josh Stevens >
> > wrote:
> >>
> >> Hey Tom,
> >>Thank you for replying .
> >>
> >> So here is how i do the conversion. The packet decoder is connected to
> the
> >> image sink and file sink. The moment the output is displayed on the
> screen i
> >> stop the flowgraph at the receiver side and the size of the
> >> "received_file.dat" is achieved to be 64 KB (which is 1KB smaller in
> size
> >> and still not exact but is considerably better as opposed to a 11KB
> >> difference). I then use python command to convert this file into a
> readable
> >> format by using numpy.fromfile and throw in the name of the file as the
> >> first argument to the same but the dtype i choose is int8 . The received
> >> file contains values ranging from 0-127 since the image is choose is a
> Black
> >> and White image which when converted to binary would be 8 bits which
> also
> >> explains the range(0-127) .
> >>
> >> About the question that you asked , the extra bits that are added , are
> >> added to the end of the file , for example in this case the received
> file
> >> contains 65536 ( 64*1024) and these bytes match the first 65536 bytes
> of the
> >> numpy int8 converted transmitted file but the other 10,000 or so bytes
> are
> >> just different numbers but all within the 0-127 range .
> >>
> >>
> >> Thanks again and Kind regards,
> >> Josh.
> >>
> >> On Sun, Jun 3, 2012 at 10:41 AM, Tom Rondeau wrote:
> >>>
> >>> On Wed, May 30, 2012 at 3:04 PM, Josh Stevens <
> josh.stevens...@gmail.com>
> >>> wrote:
> >>> > Hello All,
> >>> >
> >>> > A couple of days ago i had installed a GNURadio digital image
> >>> > processing block that makes an image source and sink block available
> as
> >>> > displayed in the image below.
> >>> > Resource : https://githu
Re: [Discuss-gnuradio] Basic python question
Oops that's funny I muxed up the echo and export commands! This is what I meant: export $PYTHONPATH="/usr/local/lib64/python2.7/site-packages" On Thu, Jun 7, 2012 at 8:39 AM, Ryan Connelly wrote: > Type $PYTHONPATH in bash what does it return? Also from the Python > interpreter (type python in bash), type > > import sys > sys.path > > What does this return? > > They should return things like /usr/lib64 (and > lib)/python2.7/site-packages and /usr/local/lib64 (and > lib)/python2.7/site-packages. > > So what python does when it looks for a module to import, it looks in > those folders defined by pythonpath and sys.path. If you want to > import a package that's called rtlsdr, there should be a folder in one > of the site-packages folders called rtlsdr. Additionally in that > folder there should be a __init__.py file. That's how finding modules > works in a nutshell. > > If you didn't have a PYTHONPATH, type this into a bash prompt to set > one (it will set for that user only) > > export 1 >> $PYTHONPATH=/usr/local/lib64/python2.7/site-packages > > reference: http://docs.python.org/tutorial/modules.html > > On Wed, Jun 6, 2012 at 11:28 PM, Phil wrote: >> I'm almost afraid to ask such a basic question. A Google search shows that >> the Internet is awash with all sorts of tutorials but I still haven't >> discovered the answer. >> >> It dawned on me a couple of days ago that gnuradio is not a plug-and -play >> SDR, like several of the Windows SDR applications that I've played with, but >> a series of building blocks. My journey into gnuradio came to a halt very >> quickly. >> >> My question is, how do I tell Python (I'm using it from the command line, no >> IDE yet) where the modules are located? As in the following example. >> > from rtlsdr import * >> Traceback (most recent call last): >> File "", line 1, in >> ImportError: No module named rtlsdr >> >> -- >> Regards, >> Phil >> >> ___ >> 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] Programming FPGA
Also here's a link to a great paper containing a good analysis of how all the HDL modules come together. Worth reading to get a head start but you definitely will want to also look at the code in Xilinx ISE. FYI you need the full version of ISE to program to the N210. FYI2 the usrp-users mailing list is more appropriate for USRP hardware discussion. Paper: vbn.aau.dk/files/52688059/final.pdf R On Fri, Jun 1, 2012 at 1:34 PM, sibar002 wrote: > > Hello > > I am currently working on the USRP N210. I am trying to modify the VHDL code > for the FPGA in order to gain acccess to some of the unused pins. I am > unsure of how to do this, and I was wondering if anyone had any advice on > how to do this. I would greatly appreciate any help. Thank you. > > Sam > -- > View this message in context: > http://old.nabble.com/Programming-FPGA-tp33946275p33946275.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > 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] Multimode.py and osmsdr module
> Another question I'm afraid, > > I've resolved, I think, my previous question about the module path. > The module rtlsdr does not exist on my system even though I have the > rtlsdr library installed. So, I presume that the module has to be > created somehow. > > Moving on, I'm trying to get multimode.py going and again I've run up > against a missing module. This time it's osmosdr and again I have > osmosdr installed but not the module osmssdr.py. > > So my question is, how do I create the module osmosdr so that I can > continue my way through multimode.py? > If you're on Ubuntu or Fedora, just use: http://www.sbrac.org/files/build-gnuradio It will take care of installing everything you need to get multimode working. Then, just get the latest multimode: svn co https://www.cgran.org/svn/projects/multimode And then look at the README for multimode -- 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] Basic python question
Type $PYTHONPATH in bash what does it return? Also from the Python interpreter (type python in bash), type import sys sys.path What does this return? They should return things like /usr/lib64 (and lib)/python2.7/site-packages and /usr/local/lib64 (and lib)/python2.7/site-packages. So what python does when it looks for a module to import, it looks in those folders defined by pythonpath and sys.path. If you want to import a package that's called rtlsdr, there should be a folder in one of the site-packages folders called rtlsdr. Additionally in that folder there should be a __init__.py file. That's how finding modules works in a nutshell. If you didn't have a PYTHONPATH, type this into a bash prompt to set one (it will set for that user only) export 1 >> $PYTHONPATH=/usr/local/lib64/python2.7/site-packages reference: http://docs.python.org/tutorial/modules.html On Wed, Jun 6, 2012 at 11:28 PM, Phil wrote: > I'm almost afraid to ask such a basic question. A Google search shows that > the Internet is awash with all sorts of tutorials but I still haven't > discovered the answer. > > It dawned on me a couple of days ago that gnuradio is not a plug-and -play > SDR, like several of the Windows SDR applications that I've played with, but > a series of building blocks. My journey into gnuradio came to a halt very > quickly. > > My question is, how do I tell Python (I'm using it from the command line, no > IDE yet) where the modules are located? As in the following example. > from rtlsdr import * > Traceback (most recent call last): > File "", line 1, in > ImportError: No module named rtlsdr > > -- > Regards, > Phil > > ___ > 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] Multimode.py and osmsdr module
On 07/06/12 20:15, Alexandru Csete wrote: on my system. So I guessed that I have to build the modules, somehow. What exactly do you mean by "osmosdr" ? There is a package called osmo-sdr which is for the Osmo SDR hardware. You do not need that if you want to use RTL2832U-based dongles. Then there is gr-osmosdr (note the gr- prefix), which provides access to RTL2832U-based dongles in GNU Radio. If you install this you will have both C++ library, python module and gnuradio-companion block (assuming that you have them in your PYTHONPATH etc). On my system it is installed in /opt/gr-osmosdr/lib/python2.7/dist-packages/ because I used prefix /opt/gr-osmosdr during compilation (default prefix is usually /usr/local) So, which one have you installed, osmo-sdr or gr-osmosdr? Thanks again Alex and Fredie, I thought I had both osmo-sdr and gr-osmosdr installed but I only have gr-osmosdr which is what I need anyway. I'm wondering why you want to work in python instead of gnuradio-companion? I have gnuradio-companion installed but that looks even more unfathomable than trying to get a python application going. Do you have a suggestion on how I might get something going using gnuradio-companion? As far as I could see, the python application you referred to was generated from a gnuradio-companion file called multimode.grc: https://www.cgran.org/browser/projects/multimode/trunk/ so you can just open up that file in gnuradio-companion. So, the grc suffix now makes sense. I'll have another play and see how I go. All I'm looking for at the moment is a simple wideband FM receiver that will work with my ezcap USB dongle. -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multimode.py and osmsdr module
On Thu, Jun 7, 2012 at 11:27 AM, Phil wrote: > On 07/06/12 19:13, Alexandru Csete wrote: >> >> On Thu, Jun 7, 2012 at 10:46 AM, Phil wrote: >>> >>> Another question I'm afraid, >>> >>> I've resolved, I think, my previous question about the module path. The >>> module rtlsdr does not exist on my system even though I have the rtlsdr >>> library installed. So, I presume that the module has to be created >>> somehow. >>> >>> Moving on, I'm trying to get multimode.py going and again I've run up >>> against a missing module. This time it's osmosdr and again I have osmosdr >>> installed but not the module osmssdr.py. >>> >>> So my question is, how do I create the module osmosdr so that I can >>> continue >>> my way through multimode.py? >> >> You have to install gr-osmosdr to get proper RTL-SDR support in GNU Radio. >> Osmosdr is for the Osmo SDR hardware, gr-osmosdr is the wrapper into GNU >> Radio: >> http://cgit.osmocom.org/cgit/gr-osmosdr/ >> > > Thanks for your reply Alex, > > I have both rtlsdr and osmsdr installed. The applications that I'm trying to > get going both need either rtlsdr and or osmosdr python modules which aren't > on my system. So I guessed that I have to build the modules, somehow. What exactly do you mean by "osmosdr" ? There is a package called osmo-sdr which is for the Osmo SDR hardware. You do not need that if you want to use RTL2832U-based dongles. Then there is gr-osmosdr (note the gr- prefix), which provides access to RTL2832U-based dongles in GNU Radio. If you install this you will have both C++ library, python module and gnuradio-companion block (assuming that you have them in your PYTHONPATH etc). On my system it is installed in /opt/gr-osmosdr/lib/python2.7/dist-packages/ because I used prefix /opt/gr-osmosdr during compilation (default prefix is usually /usr/local) So, which one have you installed, osmo-sdr or gr-osmosdr? >> I'm wondering why you want to work in python instead of >> gnuradio-companion? > > I have gnuradio-companion installed but that looks even more unfathomable > than trying to get a python application going. > > Do you have a suggestion on how I might get something going using > gnuradio-companion? As far as I could see, the python application you referred to was generated from a gnuradio-companion file called multimode.grc: https://www.cgran.org/browser/projects/multimode/trunk/ so you can just open up that file in gnuradio-companion. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pulse signal generation
Hi, I did tried to generate using USRP_Source (with squarewave as option) & USRP_Sink (complex_float) blocks. However unable to see the desired o/p (I see sinewave is being generated). Pse advise if any additional settings to be made. Regds, Sudhir. On Tue, Jun 5, 2012 at 5:57 PM, Nazmul Islam wrote: > You can use UHD: USRP_Source an UHD:USRP_Sink block. You can define the > center frequency of transmission in that block. > > Thanks, > > Nazmul > > > > On Tue, Jun 5, 2012 at 1:20 AM, S'dir wrote: > >> Hi Roberts, >> >> Greetings. Thank you for your input. >> >> I am able to bring up my system with Ubuntu 10.10 and with latest >> gnuradio as well able to run the grc file successfully and see the output >> on screen. >> >> However, would like to know how the same to integrate and generate and >> take the signal from USRP1 do I need to add any UHD blocks? (Typically how >> to interface with USRP1) >> >> Regds, >> Sudhir. >> >> On Fri, May 11, 2012 at 11:07 PM, wayne roberts >> wrote: >> >>> Something to try: byte file source with one byte of 0xff, and the other >>> 9 is 0x00. >>> >>> grc is attatched, but Gaussian filter is very strongly filtering it and >>> i really dont understand it very well, which is needed for bandwidth >>> limiting. >>> But if you dont want any filtering, you could feed file source directly >>> to real input of float-to-complex (with only type conversion). >>> >>> also attached is file you can use xxd to convert binary file to & from >>> text file. >>> I dont know if binary file attaches to email, but you can put this into >>> xxd -r: >>> 000: ff00 >>> >>> >>> >>> On Thu, May 10, 2012 at 11:50 PM, S'dir wrote: >>> Hi, I am a starter. How to generate 100Hz (10% duty) pulsed signal using gnuradio & usrp1 Any help would be highly appreciated. Thanks & Regds, Sudhir. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multimode.py and osmsdr module
Hi
I got it recently running with the gnuradio 3.6 and a Noxon DAB stick.
I had to change the usb ID in librtlsdr.c line 205
//{ 0x0ccd, 0x00b3, "Terratec NOXON DAB/DAB+ USB dongle (rev 1)" },
{ 0x0ccd, 0x00c6, "Terratec NOXON DAB/DAB+ USB dongle (rev 1)" },
you cn get it with lsusb and check if yours is in the source.
Did you run ldconfig after installing, which is responsable for updating
the pathes to the modules I think.
Best fredi
On 06/07/2012 11:27 AM, Phil wrote:
> On 07/06/12 19:13, Alexandru Csete wrote:
>> On Thu, Jun 7, 2012 at 10:46 AM, Phil wrote:
>>> Another question I'm afraid,
>>>
>>> I've resolved, I think, my previous question about the module path. The
>>> module rtlsdr does not exist on my system even though I have the rtlsdr
>>> library installed. So, I presume that the module has to be created
>>> somehow.
>>>
>>> Moving on, I'm trying to get multimode.py going and again I've run up
>>> against a missing module. This time it's osmosdr and again I have
>>> osmosdr
>>> installed but not the module osmssdr.py.
>>>
>>> So my question is, how do I create the module osmosdr so that I can
>>> continue
>>> my way through multimode.py?
>>
>> You have to install gr-osmosdr to get proper RTL-SDR support in GNU
>> Radio.
>> Osmosdr is for the Osmo SDR hardware, gr-osmosdr is the wrapper into
>> GNU Radio:
>> http://cgit.osmocom.org/cgit/gr-osmosdr/
>>
>
> Thanks for your reply Alex,
>
> I have both rtlsdr and osmsdr installed. The applications that I'm
> trying to get going both need either rtlsdr and or osmosdr python
> modules which aren't on my system. So I guessed that I have to build the
> modules, somehow.
>
>> I'm wondering why you want to work in python instead of
>> gnuradio-companion?
>
> I have gnuradio-companion installed but that looks even more
> unfathomable than trying to get a python application going.
>
> Do you have a suggestion on how I might get something going using
> gnuradio-companion?
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multimode.py and osmsdr module
On 07/06/12 19:13, Alexandru Csete wrote: On Thu, Jun 7, 2012 at 10:46 AM, Phil wrote: Another question I'm afraid, I've resolved, I think, my previous question about the module path. The module rtlsdr does not exist on my system even though I have the rtlsdr library installed. So, I presume that the module has to be created somehow. Moving on, I'm trying to get multimode.py going and again I've run up against a missing module. This time it's osmosdr and again I have osmosdr installed but not the module osmssdr.py. So my question is, how do I create the module osmosdr so that I can continue my way through multimode.py? You have to install gr-osmosdr to get proper RTL-SDR support in GNU Radio. Osmosdr is for the Osmo SDR hardware, gr-osmosdr is the wrapper into GNU Radio: http://cgit.osmocom.org/cgit/gr-osmosdr/ Thanks for your reply Alex, I have both rtlsdr and osmsdr installed. The applications that I'm trying to get going both need either rtlsdr and or osmosdr python modules which aren't on my system. So I guessed that I have to build the modules, somehow. I'm wondering why you want to work in python instead of gnuradio-companion? I have gnuradio-companion installed but that looks even more unfathomable than trying to get a python application going. Do you have a suggestion on how I might get something going using gnuradio-companion? -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multimode.py and osmsdr module
On Thu, Jun 7, 2012 at 10:46 AM, Phil wrote: > Another question I'm afraid, > > I've resolved, I think, my previous question about the module path. The > module rtlsdr does not exist on my system even though I have the rtlsdr > library installed. So, I presume that the module has to be created somehow. > > Moving on, I'm trying to get multimode.py going and again I've run up > against a missing module. This time it's osmosdr and again I have osmosdr > installed but not the module osmssdr.py. > > So my question is, how do I create the module osmosdr so that I can continue > my way through multimode.py? You have to install gr-osmosdr to get proper RTL-SDR support in GNU Radio. Osmosdr is for the Osmo SDR hardware, gr-osmosdr is the wrapper into GNU Radio: http://cgit.osmocom.org/cgit/gr-osmosdr/ I'm wondering why you want to work in python instead of gnuradio-companion? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Funcube dongle issues and a solution
Dne Wednesday 30 May 2012 ob 12:01:59 je Alexandru Csete napisal(a): > On Wed, May 30, 2012 at 8:51 AM, Gasper Zejn wrote: > > Hi, > > > > I was using Funcube dongle and found a strange bug. Whenever I used the > > FCD source in my flow graph and started the flow, the (demodulated) > > signal came out corrupted. However, if I then just started qthid, it > > would correct itself and could see bits in waveform perfectly well. This > > was happening with different firmware versions. > > > > With a bit of experimenting in the earlier out of tree gr-fcd, I found > > out that reverting two commits[1][2] resulted in resolving the issue. > > > > I've made changes to in-tree gr-fcd and recompiled and it's now working > > in a way, but issues remain. One is setting frequency at runtime (via a > > variable), where FCD flips back into spitting out corrupted waveform. > > > > This is where the problem outgrows my knowledge. > > Hi Gasper, > > Sounds to me like you are having some interference on the frequency > you are trying to use. Or maybe your are using the center of the > passband where we have a strong DC peak. I'm only guessing since you > don't give any details about your setup, e.g. what modulation are your > using, and how do you determine that your signal is corrupted. > > The FCD source block in the master branch appears to work correctly > and I have no issues demodulating narrow band FM. I have no setup to > try digital modes. The commits you refer to are necessary for correct > setup and tuning of the FCD. If you revert them the FCD may not have > the correct initial setup or may have the settings from the last time > you were using it. > > As said, I suspect you have some noise or interference in your filter > passband. Please provide more details about your setup, flowgraph, > etc. I found that plugging the FCD directly into the PC is a bad idea > causing strong interference. Always use an extension cable and > preferably also a USB hub between PC and FCD. > > Alex Hi, a bit more on my setup: I'm using funcube as a source, tuned to 868.48M, LNA gain 20dB, mixer gain 12dB, connected to simple squelch (threshold=-40dB, alpha=1) and on to quadrature demodulation block. This block then outputs clearly visible binary signal when funcube is initialized properly. The observed signal is rated at 20kbit, so it's a bit on the upper limit of what Funcube can do, but it's still possible to get a decent read. It's a burst of bits every 5s from a power meter[1][2], and the first part is a lead- in and stays the same even if readings change. Somewhere in the funcube source block there is obviously something wrong with initialization. Running qthid after starting flow changes something in funcube that makes it output correct signal. Using this and the fact, that the lead-in stays the same, it seems the "corrupt" signal (viewed in scope) is sometimes a derivative of the expected signal - most of the time on zero, with spikes up and down on transitions, with timing corresponding to transitions in expected signal. Does this give any clues? Kind regards, Gašper Žejn [1] http://www.conrad.de/ce/de/product/125353/VOLTCRAFT-ENERGYCOUNT-3000- ENERGIE-MESSG [2] http://jeelabs.org/2009/11/14/energy-tracking-with-cost-control/ > ___ > 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] Multimode.py and osmsdr module
Another question I'm afraid, I've resolved, I think, my previous question about the module path. The module rtlsdr does not exist on my system even though I have the rtlsdr library installed. So, I presume that the module has to be created somehow. Moving on, I'm trying to get multimode.py going and again I've run up against a missing module. This time it's osmosdr and again I have osmosdr installed but not the module osmssdr.py. So my question is, how do I create the module osmosdr so that I can continue my way through multimode.py? -- Regards, Phil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
