[Discuss-gnuradio] Dayton SDR Forum speaker list, times
Dayton SDR Forum is exciting this year. 4/5 of the talks are about HPSDR-related and that is good with a great list of speakers. Friday, 2:30-5 PM Gerald Youngblood, Flex updates 2:30 Lyle Johnson, Embedded Processors for SDR 3:00 John Melton, SDR GUI 3:30 Scott Cowling, HPSDR update 4:00 Jeremy McDermond, MacHPSDR 4:30 Bob McGwier N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple digital data transmitter
On Thu, May 13, 2010 at 1:18 AM, marcin_w wrote: > > > Eric Blossom wrote: >> >> Your baseband sample rate is 100M/32 -> 3.125MS/s >> >> You're using 2 samples/symbol, thus your symbol rate is >> 3.125MS/s / 2 -> 1.5625Msymbols/s >> And since you're using DBPSK, you're getting 1 bit/symbol, thus your >> raw over-the-air bit rate is 1.5625Mbit/s >> > > Hi Eric, a quick question about this. > > According to: > _pick_bitrate(bitrate, bits_per_symbol, samples_per_symbol, xrate, > converter_rate, xrates, gen_info) in pick_bitrate.py > > when the samples per symbol and interpolation are given, then our bitrate > can be determined straight away. > i.e Bitrate = converter_rate / xrate / samples_per_symbol > > Is this correct though, in determining the bitrate for both dbpsk & dqpsk? > For instance if we passed the_pick_bitrate() function an interpolation of > 128 and Samples/symbol of 2, then according to the code, our bit rate for > both dqpsk and dbpsk will be 500kbs. > > But according to what your saying: > 1) for dbpsk > > if DAC rate = 128e6 Interpolation = 128 Samples/symbol = 2 > Bitrate = 128e6 / 128 / 2 = 500k > > 2) for dqpsk > > Using the same parameters > Bitrate = 128e6 / 128 / 2 / 2bits per symbol = 256K > > Have i missed something here, or in the code? > > Regards, > > Marcin This does appear to be a bug. That calculation in pick_bitrate.py should also be divided by bits_per_symbol. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re:Re: [Discuss-gnuradio] PACKET FORMAT "error"
Hi, can u help me?
I want to know which are the step and the file to recompile after a changing
in .cc codeAfter add the printf code in .cc what have u done?
I have to modify a .cc code to use this modification in a py script as a new
methodbut i don't get on with the job
Thanks,
Domenico
zzw.1012 wrote:
>
> Hi, Thomas
> thanks for your help ! you are right!
> I add printf code in the function of usrp_basic.cc like this:
> int usrp_basic_tx::write(const void *buf, int len, bool *underrun)
> {
> ...
> printf ("len = %d\n", len);
> if (len < 0 || (len % 512) != 0)
> {
> fprintf(stderr, "usrp_basic_tx::write: invalid length= %d\n", len);
> }
> }
> then I run the example of benchmark_tx.py :
> ./benchmark_tx.py -f 2500M -s 1500 -M 0.001
> it really send 194560 bytes = 190k for the default case using 4 samples
> per symbol and it send 380k with -M 0.002.
> but , I still have some question. first , after making packet with 1520
> bytes, then whether is it going on gmsk(default) modulation? I think the
> 1520-bytes packet changes to 190kbytes occur in the process of gmsk. Is it
> right? how to calculate the number from 1520 to 194560?
> second, in the process of sending packet, the printf information as
> follow:
> (./benchmark_tx.py -f 2500M -s 1500 -M 0.001)
> len = 16384
> len = 15872
> len = 16384
> len = 16384
> len = 16384
> len = 15872
> len = 16384
> len = 512
> len = 16384
> len = 16384
> len = 16384
> len = 16384
> len = 14848
> Is there have some discipline in sending data? I find it seems unorderly.
>
> thank you again
>
> best wishes
>
>
>>
>> On Sun, May 9, 2010 at 11:28 PM, zzw.1012 wrote:
>> > Hi,
>> > I'm studying benchmark_tx.py now. I find that the packet size is
>> not
>> > right (at least I'd like to think so) in the process of making packet,
>> which
>> > can be seen in pkt.py and packet_utils.py. In the packet consist of 2
>> bytes
>> > packed_preamble, 8 bytes packed_access_code, 4 bytes header, 4 bytes
>> > outband_crc with default 1500 bytes size, padding bytes and
>> endbyte"\x55" .
>> > I use default gmsk modulatiom. So, the packet have 2 + 8 + 4 + 1504 + 1
>> + 1
>> > = 1520bytes.
>> > However, in the function of _npadding_bytes(pkt_bytes_len,
>> > samples_per_symbol, bits_per_symbol) , there have such description:
>> > "generate sufficient padding such that each packet ultimately ends up
>> being
>> > a multiple of 512 bytes when sent across the USB, we send 4-byte
>> samples
>> > across the USB (16-bit I and 16-bit Q), thus we want to pad so that
>> after
>> > modulation the resulting packet is a multiple of 128 samples". Also ,
>> in the
>> > function "int usrp_basic_tx::write(const void *buf, int len, bool
>> > *underrun)"in the usrp_basic.cc, there have similar code like "if (len
>> < 0
>> > || (len % 512) != 0){fprintf(stderr, "usrp_basic_tx::write: invalid
>> length
>> > = %d\n", len}".
>> > they both tell me that the data across the USB must be a multiple
>> of 512
>> > bytes .but in the example of benchmark_tx.py, the packet size is 1520
>> > bytes. what's wrong ?
>>
>> 1520 bytes only refers to the packet size. The transmitted sample
>> stream at the physical layer includes a number of other factors
>> including conversion to bits, samples per symbol, and sample size. So
>> for the default case, a 1520 byte packet using 4 samples per symbol
>> yields 48640 samples or 194560 bytes, which is a multiple of 512.
>>
>> Thomas
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://old.nabble.com/PACKET-FORMAT-%22error%22-tp28507552p28547711.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: Re:Re: [Discuss-gnuradio] PACKET FORMAT "error"
HI Domenico,
You can 'make'(from terminal) the folder in which you have modified .cc and
.py files.
It should work fine if there are not errors in your modifications..
Regards,
Kuntal Ray
-Original Message-
From: discuss-gnuradio-bounces+kray2=mail.uh@gnu.org
[mailto:discuss-gnuradio-bounces+kray2=mail.uh@gnu.org] On Behalf Of
meco1982
Sent: Thursday, May 13, 2010 8:46 AM
To: Discuss-gnuradio@gnu.org
Subject: Re: Re:Re: [Discuss-gnuradio] PACKET FORMAT "error"
Hi, can u help me?
I want to know which are the step and the file to recompile after a changing
in .cc codeAfter add the printf code in .cc what have u done?
I have to modify a .cc code to use this modification in a py script as a new
methodbut i don't get on with the job
Thanks,
Domenico
zzw.1012 wrote:
>
> Hi, Thomas
> thanks for your help ! you are right!
> I add printf code in the function of usrp_basic.cc like this:
> int usrp_basic_tx::write(const void *buf, int len, bool *underrun)
> {
> ...
> printf ("len = %d\n", len);
> if (len < 0 || (len % 512) != 0)
> {
> fprintf(stderr, "usrp_basic_tx::write: invalid length= %d\n", len);
> }
> }
> then I run the example of benchmark_tx.py :
> ./benchmark_tx.py -f 2500M -s 1500 -M 0.001
> it really send 194560 bytes = 190k for the default case using 4 samples
> per symbol and it send 380k with -M 0.002.
> but , I still have some question. first , after making packet with 1520
> bytes, then whether is it going on gmsk(default) modulation? I think the
> 1520-bytes packet changes to 190kbytes occur in the process of gmsk. Is it
> right? how to calculate the number from 1520 to 194560?
> second, in the process of sending packet, the printf information as
> follow:
> (./benchmark_tx.py -f 2500M -s 1500 -M 0.001)
> len = 16384
> len = 15872
> len = 16384
> len = 16384
> len = 16384
> len = 15872
> len = 16384
> len = 512
> len = 16384
> len = 16384
> len = 16384
> len = 16384
> len = 14848
> Is there have some discipline in sending data? I find it seems unorderly.
>
> thank you again
>
> best wishes
>
>
>>
>> On Sun, May 9, 2010 at 11:28 PM, zzw.1012 wrote:
>> > Hi,
>> > I'm studying benchmark_tx.py now. I find that the packet size is
>> not
>> > right (at least I'd like to think so) in the process of making packet,
>> which
>> > can be seen in pkt.py and packet_utils.py. In the packet consist of 2
>> bytes
>> > packed_preamble, 8 bytes packed_access_code, 4 bytes header, 4 bytes
>> > outband_crc with default 1500 bytes size, padding bytes and
>> endbyte"\x55" .
>> > I use default gmsk modulatiom. So, the packet have 2 + 8 + 4 + 1504 + 1
>> + 1
>> > = 1520bytes.
>> > However, in the function of _npadding_bytes(pkt_bytes_len,
>> > samples_per_symbol, bits_per_symbol) , there have such description:
>> > "generate sufficient padding such that each packet ultimately ends up
>> being
>> > a multiple of 512 bytes when sent across the USB, we send 4-byte
>> samples
>> > across the USB (16-bit I and 16-bit Q), thus we want to pad so that
>> after
>> > modulation the resulting packet is a multiple of 128 samples". Also ,
>> in the
>> > function "int usrp_basic_tx::write(const void *buf, int len, bool
>> > *underrun)"in the usrp_basic.cc, there have similar code like "if (len
>> < 0
>> > || (len % 512) != 0){fprintf(stderr, "usrp_basic_tx::write: invalid
>> length
>> > = %d\n", len}".
>> > they both tell me that the data across the USB must be a multiple
>> of 512
>> > bytes .but in the example of benchmark_tx.py, the packet size is 1520
>> > bytes. what's wrong ?
>>
>> 1520 bytes only refers to the packet size. The transmitted sample
>> stream at the physical layer includes a number of other factors
>> including conversion to bits, samples per symbol, and sample size. So
>> for the default case, a 1520 byte packet using 4 samples per symbol
>> yields 48640 samples or 194560 bytes, which is a multiple of 512.
>>
>> Thomas
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
--
View this message in context:
http://old.nabble.com/PACKET-FORMAT-%22error%22-tp28507552p28547711.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Alamouti Implementation
I am trying to implement the Alamouti 2x1 scheme but i have some problems. I create 2 channel in order to use 2 antennas but one of the channel has less power than the other and i am thinking that the signal is not being transmited by both antennas . Does it matter the distance between the 2 antennas? or do i have smth else to fix? (I use the interleaver in the creation of the signal). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Simultaneous send and receive with USRP2 and RFX900 Daughterboard
I'm trying to simultaneously send and receive a sine signal with the
USRP2 with a RFX900 Daughterboard. My setting is:
- An arbritary signal generator sends a sinus signal to RX2
- The USRP2 sends a sine signal through TX/RX to an external Scope
- The sampling rate is 1e6
- Interpolation at the sink and decimation at the source are both 100
- The center frequency is 900MHz
- I use gnuradio 3.3git-696-glae689f
- The USRP2 has the latest firmware on it
I use the following computer:
Thinkpad T41, 1.4GHz, 768MB RAM
Intel Corporation 82540EP Gigabit Ethernet Controller
The sine signal sent out by the USRP2 looks nice on the scope and has no
gaps in it.
The signal received by the USRP2 on RX2 is only once or twice visible
with some gap inbetween and then disapears completely.
Attached is a picture of the received signal and the code I used.
When I only receive a signal without sending, the signal looks nice.
Only sending signals works as well without any problems.
Does anyone has an idea what went wrong and/or how to fix it? Is there
any possibility to chose the antenna for transmission and reception?
Thanks for any hint and answer
Pascal Sachs
<>#!/usr/bin/env python
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import usrp2
from gnuradio.eng_option import eng_option
from gnuradio.gr import firdes
from optparse import OptionParser
class top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "Send and Receive")
self.samp_rate = samp_rate = 1e6
self.gr_complex_to_mag_0 = gr.complex_to_mag(1)
self.gr_file_sink_2 = gr.file_sink(gr.sizeof_float*1, "rx2_signal")
self.gr_float_to_complex_0 = gr.float_to_complex(1)
self.gr_sig_source_x_0 = gr.sig_source_f(samp_rate, gr.GR_SIN_WAVE, 1000, 0.1, 0)
self.usrp2_sink__0 = usrp2.sink_32fc()
self.usrp2_sink__0.set_interp(100)
self.usrp2_sink__0.set_center_freq(900e6)
self.usrp2_sink__0.set_gain(0)
self.usrp2_source_32fc = usrp2.source_32fc()
self.usrp2_source_32fc.set_decim(100)
self.usrp2_source_32fc.set_center_freq(900e6)
self.usrp2_source_32fc.set_gain(30)
self.connect((self.gr_complex_to_mag_0, 0), (self.gr_file_sink_2, 0))
self.connect((self.usrp2_source_32fc, 0), (self.gr_complex_to_mag_0, 0))
self.connect((self.gr_sig_source_x_0, 0), (self.gr_float_to_complex_0, 0))
self.connect((self.gr_float_to_complex_0, 0), (self.usrp2_sink__0, 0))
def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
self.gr_sig_source_x_0.set_sampling_freq(self.samp_rate)
if __name__ == '__main__':
parser = OptionParser(option_class=eng_option, usage="%prog: [options]")
(options, args) = parser.parse_args()
tb = top_block()
tb.start()
raw_input('Press Enter to quit: ')
tb.stop()
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: Re:Re: [Discuss-gnuradio] PACKET FORMAT "error"
Thanks so much
I'm deeply sorry but i have to disturb u again...
I changed the file "db_dbsrx.c" in "/gnuradio/usrp2/firmaware/lib" to
insert a new method and c++ compiling at command window is not my best
assetWhich are the command to type...?
$ gcc db_dbsrx.c..and what else? which option have i to add to
compile it?
The python file is in a different folder cause i have to recall a new method
in usrp2.source_32fc() that now is not defined
Thanks
Domenico
Kuntal-2 wrote:
>
> HI Domenico,
> You can 'make'(from terminal) the folder in which you have modified .cc
> and
> .py files.
>
> It should work fine if there are not errors in your modifications..
>
> Regards,
> Kuntal Ray
>
> -Original Message-
> From: discuss-gnuradio-bounces+kray2=mail.uh@gnu.org
> [mailto:discuss-gnuradio-bounces+kray2=mail.uh@gnu.org] On Behalf Of
> meco1982
> Sent: Thursday, May 13, 2010 8:46 AM
> To: Discuss-gnuradio@gnu.org
> Subject: Re: Re:Re: [Discuss-gnuradio] PACKET FORMAT "error"
>
>
> Hi, can u help me?
> I want to know which are the step and the file to recompile after a
> changing
> in .cc codeAfter add the printf code in .cc what have u done?
> I have to modify a .cc code to use this modification in a py script as a
> new
> methodbut i don't get on with the job
> Thanks,
> Domenico
>
>
>
>
> zzw.1012 wrote:
>>
>> Hi, Thomas
>> thanks for your help ! you are right!
>> I add printf code in the function of usrp_basic.cc like this:
>> int usrp_basic_tx::write(const void *buf, int len, bool *underrun)
>> {
>> ...
>> printf ("len = %d\n", len);
>> if (len < 0 || (len % 512) != 0)
>> {
>> fprintf(stderr, "usrp_basic_tx::write: invalid length= %d\n", len);
>> }
>> }
>> then I run the example of benchmark_tx.py :
>> ./benchmark_tx.py -f 2500M -s 1500 -M 0.001
>> it really send 194560 bytes = 190k for the default case using 4 samples
>> per symbol and it send 380k with -M 0.002.
>> but , I still have some question. first , after making packet with 1520
>> bytes, then whether is it going on gmsk(default) modulation? I think the
>> 1520-bytes packet changes to 190kbytes occur in the process of gmsk. Is
>> it
>> right? how to calculate the number from 1520 to 194560?
>> second, in the process of sending packet, the printf information as
>> follow:
>> (./benchmark_tx.py -f 2500M -s 1500 -M 0.001)
>> len = 16384
>> len = 15872
>> len = 16384
>> len = 16384
>> len = 16384
>> len = 15872
>> len = 16384
>> len = 512
>> len = 16384
>> len = 16384
>> len = 16384
>> len = 16384
>> len = 14848
>> Is there have some discipline in sending data? I find it seems unorderly.
>>
>> thank you again
>>
>> best wishes
>>
>>
>>>
>>> On Sun, May 9, 2010 at 11:28 PM, zzw.1012 wrote:
>>> > Hi,
>>> > I'm studying benchmark_tx.py now. I find that the packet size is
>>> not
>>> > right (at least I'd like to think so) in the process of making packet,
>>> which
>>> > can be seen in pkt.py and packet_utils.py. In the packet consist of 2
>>> bytes
>>> > packed_preamble, 8 bytes packed_access_code, 4 bytes header, 4 bytes
>>> > outband_crc with default 1500 bytes size, padding bytes and
>>> endbyte"\x55" .
>>> > I use default gmsk modulatiom. So, the packet have 2 + 8 + 4 + 1504 +
>>> 1
>>> + 1
>>> > = 1520bytes.
>>> > However, in the function of _npadding_bytes(pkt_bytes_len,
>>> > samples_per_symbol, bits_per_symbol) , there have such description:
>>> > "generate sufficient padding such that each packet ultimately ends up
>>> being
>>> > a multiple of 512 bytes when sent across the USB, we send 4-byte
>>> samples
>>> > across the USB (16-bit I and 16-bit Q), thus we want to pad so that
>>> after
>>> > modulation the resulting packet is a multiple of 128 samples". Also ,
>>> in the
>>> > function "int usrp_basic_tx::write(const void *buf, int len, bool
>>> > *underrun)"in the usrp_basic.cc, there have similar code like "if
>>> (len
>>> < 0
>>> > || (len % 512) != 0){fprintf(stderr, "usrp_basic_tx::write: invalid
>>> length
>>> > = %d\n", len}".
>>> > they both tell me that the data across the USB must be a multiple
>>> of 512
>>> > bytes .but in the example of benchmark_tx.py, the packet size is 1520
>>> > bytes. what's wrong ?
>>>
>>> 1520 bytes only refers to the packet size. The transmitted sample
>>> stream at the physical layer includes a number of other factors
>>> including conversion to bits, samples per symbol, and sample size. So
>>> for the default case, a 1520 byte packet using 4 samples per symbol
>>> yields 48640 samples or 194560 bytes, which is a multiple of 512.
>>>
>>> Thomas
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/PACKET-FORMAT-%22error%22-tp28507552p28547711.html
> Sent from the GnuRadio mailing list archive at Nabbl
Re: Re:Re: [Discuss-gnuradio] PACKET FORMAT "error"
On Thu, May 13, 2010 at 9:29 AM, meco1982 wrote: > > Thanks so much > I'm deeply sorry but i have to disturb u again... > I changed the file "db_dbsrx.c" in "/gnuradio/usrp2/firmaware/lib" to > insert a new method and c++ compiling at command window is not my best > assetWhich are the command to type...? > > $ gcc db_dbsrx.c..and what else? which option have i to add to > compile it? You shouldn't be calling gcc directly here. You just need to call 'make' from the firmware directory, and it will re-build your changes. -- John Orlando CEO/System Architect Epiq Solutions www.epiq-solutions.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How to set bitrate
Hi all, How to set the bitrate and the DAC output amplitude, if only need to generate baseband signal as a 25kHz square wave and tune to RF? Thank you so much Regards, Yan <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP vs USRP2
On 05/12/2010 04:37 AM, Manne Tallmarken wrote: Hello all, I want to start expereiment with software defined radio but can't make up my mind which one of the usrp and usrp2 is the most suitable. I am new to FPGAs but want to start playing with these as well. I use GNU/Linux and GCC as much as I can. Some questions: The usrp and usrp2 uses FPGAs from different manufacturers so I assume the development environment will differ as well. Is anyone of the two more suited for a linux system than the other? I don't want to pay any license costs (and I'm glad if I can use the dev environment longer time than a trial period... btw, I am a student). The development environments are different, supplied by the vendor. Both are available for Linux. The Altera one is free, but the Xilinx one is for pay (there is a free one, but it doesn't work with our device). As a student, though, you can probably get a free copy of the Xilinx software. To play around with a FPGA on a system like this, will I need the extra size and speed xilinx spartan 3 gives me? (Maybe I want to bruteforce some cryptos, doing some FIR filters or event wavelet transformations) The Xilinx one has multipliers, the altera one does not. Since the usrp2 only have one tx/rx channel I would need two usrp2's to get the same number of tx/rx channels as the usrp and this is not currently an affordable option. In which cases will I need two tx/rx channels? Examples? The usrp2 is faster in many ways. In what applications will I need the extra speed and extra bandwidth? Examples? Any other cool stuff I can do with one of the boards but not the other? The USRP2 has a much bigger and faster fpga. Are gnuradio programs written for usrp compatible with usrp2? Most programs will work with both. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Which version of UHD firmware should I be using?
On 05/09/2010 12:40 AM, Charles Brain wrote: Hello, I am a bit confused, there seems to be two versions of the UHD firmware a "Raw Ethernet version" and a "UDP version". I am about to try and move my USRP2 application to UHD and I was wondering which version I should be using? I have a USRP2 and a WBX board. Everything is here: http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries For the FPGA there are 2 versions. One is raw ethernet, and works with the mainline GNU Radio code. The other is UDP. The UDP image is for use with UHD and for some other deprecated versions which you are not using, but some of my customers are, which do UDP without the UHD. For the firmware, there are 7 versions. If you are using raw ethernet, chose from one of the 3 for it based on which daughterboard you are using. If you are using UHD, choose the UHD version. The remaining 3 versions are for use with UDP without UHD, which is deprecated. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX900 Duplex
Hello, I understand that the new firmware supports full duplex for RX900. Would anyone happen to know how I would augment my c++ code (similar to rx_streaming_samples.cc) so that I can select antenna port RX2 for my reciever. I see how it is done in python, but wondering how to do it in c++. ANy help would be greatly appreciated. Thanks, Sharif ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX900 Duplex
> Hello, > > I understand that the new firmware supports full duplex for RX900. > Would anyone happen to know how I would augment my c++ > code (similar to rx_streaming_samples.cc) so that I can select > antenna port RX2 for my reciever. I see how it is done in python, > but wondering how to do it in c++. ANy help would be greatly > appreciated. > > Thanks, > Sharif > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > usrp2_source_base::set_antenna(int ant) Seems to be the C++ function that the Python code uses. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX900 Duplex
Thank you Marcus, will give it a try and let you know if I have a success. Sharif - Original Message - From: "Marcus D. Leech" To: Sent: Thursday, May 13, 2010 3:41 PM Subject: Re: [Discuss-gnuradio] RFX900 Duplex Hello, I understand that the new firmware supports full duplex for RX900. Would anyone happen to know how I would augment my c++ code (similar to rx_streaming_samples.cc) so that I can select antenna port RX2 for my reciever. I see how it is done in python, but wondering how to do it in c++. ANy help would be greatly appreciated. Thanks, Sharif ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio usrp2_source_base::set_antenna(int ant) Seems to be the C++ function that the Python code uses. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] old USRP inband code
I'm trying to grab a copy of the GNU Radio code through git which still has the old USRP inband code. I noticed this commit from Jonathan in my search: Author: jcorgan Date: Thu Jul 9 02:55:51 2009 + Merged r11377:11390 from jcorgan/usrp-headers in to trunk. * Removed usrp-inband code from tree (put into limbo directory.) This code has become unmaintained and has started to suffer from bitrot. A checkpoint tag has been made for anyone still needing to use it: http://gnuradio.org/svn/gnuradio/tags/checkpoints/trunk-20090708-pre-usrp-reorg -- How I do get the tags with the current git structure? I'm struggling a bit with GIT :P Thanks a bunch. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] old USRP inband code
On Thu, May 13, 2010 at 4:25 PM, George Nychis wrote: > I'm trying to grab a copy of the GNU Radio code through git which still has > the old USRP inband code. I noticed this commit from Jonathan in my search: > > Author: jcorgan > Date: Thu Jul 9 02:55:51 2009 + > > Merged r11377:11390 from jcorgan/usrp-headers in to trunk. > > * Removed usrp-inband code from tree (put into limbo directory.) > This code has become unmaintained and has started to suffer > from bitrot. A checkpoint tag has been made for anyone still > needing to use it: > > > http://gnuradio.org/svn/gnuradio/tags/checkpoints/trunk-20090708-pre-usrp-reorg > > -- > > How I do get the tags with the current git structure? I'm struggling a bit > with GIT :P Thanks a bunch. The can create a branch and reset to the state before the inband code was moved to limbo. Lets call it inband. git checkout -b inband git reset --hard eefb51c0c0fac68d Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] new inband plan? message passing?
Hi all, What is the gameplan for the new inband infrastructure? VRT now defines the protocol/structure of the messages between the USRP and host... but what about message passing at the host? This is something I'm going to need in the near future, and if the price (a very, very, solid plan) is right, I may be able to contribute to the code. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc0 available for testing
Johnathan Corgan wrote: GNU Radio release 3.3.0-rc0 is available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc0.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc0.tar.gz This is the first release candidate for the 3.3 release series. This builds and runs on MinGW/MSYS except that it has the same problem as the 3.3git-594 tarball: The supplied version of ltmain.sh does not handle interlibrary dependencies on Windows. I have attached a diff file showing the slight differences between the ltmain.sh in the tarball (2.2.6b Debian-2.2.6b-2ubuntu1, which fails) and the ltmain.sh downloaded from packages.debian.org (plain 2.26b). It looks like it was broken in Ubuntu 2.2.6a-3 (change log says "Don't pull in depedency libs when linking a binary"). GNU Radio builds ok if I run ./bootstrap locally. It would be nice if we could ship a tarball with a ltmain.sh that works on Windows. -- Don W. P.S.: I have brought the MinGW install page on the wiki up to date (I hope to add instructions for git soon). ltmain.sh.diff Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc0 available for testing
On Thu, May 13, 2010 at 18:10, Don Ward wrote: > I have attached a diff file showing > the slight differences between the ltmain.sh in the tarball [...] > It would be nice if we could ship a tarball with a ltmain.sh that works on > Windows. This has been applied. Rather, ltmain.sh from libtool 2.2.6b has been added to the repository. Previously, this was not under version control, and we relied on the bootstrap process to copy it over from the installed libtool on whatever system was being used. Now with it in the repository, the bootstrap process will defer to our copy. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Ubuntu 10.04 installation
Anyone seen this type of problem trying to build fairly-recent GIT, on a "out of the box" Ubuntu 10.04 system: *Make[6]: Entering directory `/usr/local/src/gnuradio/gruel/src/lib/pmt'* */bin/bash ../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../.. -DOMNITHREAD_POSIX=1 -I/usr/include -I/usr/local/src/gnuradio/gruel/src/include -I/usr/local/src/gnuradio/gruel/src/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT pmt.lo -MD -MP -MF .deps/pmt.Tpo -c -o pmt.lo pmt.cc* *libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../.. -DOMNITHREAD_POSIX=1 -I/usr/include -I/usr/local/src/gnuradio/gruel/src/include -I/usr/local/src/gnuradio/gruel/src/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT pmt.lo -MD -MP -MF .deps/pmt.Tpo -c pmt.cc -fPIC -DPIC -o .libs/pmt.o* *In file included from /usr/include/c++/4.4/complex:46,* * from /usr/local/src/gnuradio/gruel/src/include/gruel/pmt.h:29,* * from pmt.cc:27:* */usr/include/c++/4.4/cmath:363: internal compiler error: Segmentation fault* *Please submit a full bug report,* *with preprocessed source if appropriate.* *See for instructions.* *make[6]: *** [pmt.lo] Error 1* *make[6]: Leaving directory `/usr/local/src/gnuradio/gruel/src/lib/pmt'* *make[5]: *** [all] Error 2* *make[5]: Leaving directory `/usr/local/src/gnuradio/gruel/src/lib/pmt'* *make[4]: *** [all-recursive] Error 1* *make[4]: Leaving directory `/usr/local/src/gnuradio/gruel/src/lib'* *make[3]: *** [all-recursive] Error 1* *make[3]: Leaving directory `/usr/local/src/gnuradio/gruel/src'* *make[2]: *** [all-recursive] Error 1* *make[2]: Leaving directory `/usr/local/src/gnuradio/gruel'* *make[1]: *** [all-recursive] Error 1* *make[1]: Leaving directory `/usr/local/src/gnuradio'* *make: *** [all] Error 2 * Seems to provoke an internal compiler error. Yikes! -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 10.04 installation
On Thu, May 13, 2010 at 19:29, Marcus D. Leech wrote: > Anyone seen this type of problem trying to build fairly-recent GIT, on a > "out of the box" Ubuntu 10.04 system: > /usr/local/src/gnuradio/gruel/src/include/gruel/pmt.h:29, > from pmt.cc:27: > /usr/include/c++/4.4/cmath:363: internal compiler error: Segmentation fault Ouch. FWIW, I've been using Ubuntu 10.04 with its gcc 4.4.3 successfully in my lab (eight machines). All but one have been upgrades, though, not "out-of-box." Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 10.04 installation
On Thu, May 13, 2010 at 10:54 PM, Johnathan Corgan wrote: > On Thu, May 13, 2010 at 19:29, Marcus D. Leech wrote: > >> Anyone seen this type of problem trying to build fairly-recent GIT, on a >> "out of the box" Ubuntu 10.04 system: > >> /usr/local/src/gnuradio/gruel/src/include/gruel/pmt.h:29, >> from pmt.cc:27: >> /usr/include/c++/4.4/cmath:363: internal compiler error: Segmentation fault > > Ouch. > > FWIW, I've been using Ubuntu 10.04 with its gcc 4.4.3 successfully in > my lab (eight machines). All but one have been upgrades, though, not > "out-of-box." > > Johnathan I installed 10.04 on my laptop as a full, fresh install. I haven't had any issues building GNU Radio. I don't have anything constructive for you, Marcus, just that bit of info. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble in x86_64 land?
On 05/10/2010 09:04 PM, Marcus D. Leech wrote: >> > Well, I just turned gl rendering back on, but displayed via an SSH > tunnel back to a different machine > with a different video card. Works just fine. > > So, some badness in GL I spoze. Not much that Gnu Radio can do about > it, I guess. > > Just to follow up on this. The "x86_64" part seems indeed to have been a red herring. I just installed a new video card in the machine that was giving trouble when "gl" rendering was turned on in Gnu Radio, and it works fine now. The card I had in there was a ca 2000, ATI Rage 128 card. Not very capable, to be sure. The new card is a 8400 GS based card, and it works fine with the GL rendering. Seems to me, that provoking a segfault is a not very polite way of telling you that your video card is too old and creaky to support GL. But maybe I'm just old-fashioned :-) Furthermore, perhaps GL should be able to detect this situation and "fall back" to something that will work, but perhaps have slower performance or sometime. [Talking quite distinctly through my hat here, because I have only the vaguest notion of how GL does what GL does]. So, for anyone else who runs into a problem where *any* of the Gnu Radio example apps that use the GUI, and the GUI is configured for "gl", and all you can get out of it is a segmentation fault. Try upgrading to a "modern" video card. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ubuntu 10.04 installation
On 05/13/2010 11:01 PM, Tom Rondeau wrote: > I installed 10.04 on my laptop as a full, fresh install. I haven't had > any issues building GNU Radio. > > I don't have anything constructive for you, Marcus, just that bit of info. > > Tom > > Hm.Curiouser, and curiouser. It's not my machine, I'm "proxying" for a colleague who was so keen on the Gnu Radio-based application I've been developing that he went out and got himself a 2nd machine, identical to the first, to run another instance on. The second machine is a "fresh from the box", while the first is a upgrade from 9.04. I don't think I've seen GCC dumpeth the core in many many years. Makes me wonder about weird hardware problems. It's an Atom D510-based system. I wonder if there are kernel subtleties. Like the upgrade from 9.04 leaves you with a different kernel than a "out of the box" 10.04? I'm not a Ubuntu guy, just doing my friend a favour trying to debug this. Life was so much simpler when disk drives were only 30 megabytes, and you could fit a printout of the kernel in your lunchbox :-) And you could demodulate network traffic on your dental work, etc. Oh, I'm in a geezerly mood tonight, aren't I? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Radio release 3.3.0-rc0 available for testing
Still getting this error message when trying to play with the new block
>>> gr_fir_ccf: using SSE
thread[thread-per-block[1]: ]: gr_complex must be
8-byte aligned
I've pasted the py program code below - it's trivial. An initial offhand
diagnosis might suggest this is coming from somewhere in GR C++-land and isn't
caused by anything in the py source code...
73
Max
~
$ uname -a
Linux mhp 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686
GNU/Linux
~
#!/usr/bin/env python
import math, sys
from math import pi
from gnuradio import gr, gru, audio, eng_notation, blks2, optfir, clock
from gnuradio.eng_option import eng_option
from optparse import OptionParser
class app_top_block(gr.top_block):
def __init__(self, options, queue):
gr.top_block.__init__(self, "mhp")
IN = gr.file_source(gr.sizeof_gr_complex, options.input_file)
OUT = gr.file_sink(gr.sizeof_gr_complex, options.output)
if 1:
theta = pi / 4.0
alpha = 0.15
beta = 0.25 * alpha * alpha
mu = 0.5
gain_mu = 0.15
omega = 10
gain_omega = 0
fmin = -0.025
fmax = 0.025
omega_rel = 0.005
RX = gr.dd_mpsk_sync_cc (alpha, beta, fmax, fmin, theta, omega,
gain_omega, mu, gain_mu)
self.connect(IN, RX, OUT)
def main():
parser = OptionParser(option_class=eng_option)
parser.add_option("-i", "--input-file", type="string", default="in.dat",
help="specify the input file")
parser.add_option("-o", "--output", type="string", default="out.dat",
help="specify the output file")
(options, args) = parser.parse_args()
queue = gr.msg_queue()
tb = app_top_block(options, queue)
try:
tb.run()
except KeyboardInterrupt:
tb.stop()
if __name__ == "__main__":
main()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
