[Discuss-gnuradio] "USRP2+XCVR2450 TxGain / RxGain meaning"
Hello, I'm using the USRP2 board with the daughterboard XCVR2450. As far as I know, the output power of the XCVR2450 is 100mW (20dBm), but I don't understand the meaning of the TxGain and RxGain factor when I use for example tunnel.py. I have been able to identify that the Tx Gain varies between 0https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dual usrp signal transmission problem
Hi all, i have been working on the simple sine transmission with 2 antennas on usrp but im having a little problem with that. My program doesnt give any error but when i check the output with the help of usrp_fft.py on the other system, i can see that one antenna is transmitting and the other is not... my code is: from gnuradio import usrp, gr class my_top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self) self.u = usrp.sink_c(0) #self.pick_subdev = usrp.pick_tx_subdevice(self.u) self.usrp_interp = 400 self.u.set_interp_rate(self.usrp_interp) usrp_rate = self.u.dac_rate()/self.usrp_interp self.subdev = (self.u.db(0,0), self.u.db(1,0)) #self.subdev = (self.u.db[0][0], self.u.db[1][0]) print self.subdev self.u.set_mux(0xba98) r0 = self.u.tune(0, self.subdev[0], 245000) r1 = self.u.tune(1, self.subdev[1], 248000) self.subdev[0].set_enable(True) self.subdev[1].set_enable(True) self.siggen1=gr.sig_source_c(100, gr.GR_COS_WAVE, 1, 16000) self.siggen2=gr.sig_source_c(100, gr.GR_COS_WAVE, 1, 16000) self.intr = gr.interleave(gr.sizeof_gr_complex) self.connect(self.siggen1, (self.intr,0)) self.connect(self.siggen2, (self.intr,1)) self.connect(self.intr, self.u) self.run() def main(): tb = my_top_block() tb.run() if __name__ == '__main__': main() Help me with this. Thanks in advance Regards, Ebtisam ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem DPSK Mod/ Demod - UHD USRP1 Blocks
Good morning, I am working in digital communications specifically with dpsk modulation in gnu radio. I made a very simple dpsk modulation and demodulation testing flow graph . this is the flow graph that I made for the transmitting part: https://picasaweb.google.com/101968292957887487468/DQPSKMODULATION#5733510080875799138 And the transmitted spectrum, before the UDH USRP1 sink block is : https://picasaweb.google.com/101968292957887487468/DQPSKMODULATION#5733510073889925042 And for the receiver I did this: https://picasaweb.google.com/101968292957887487468/DQPSKMODULATION#5733510072472332802 I receive this spectrum after the UHD-USRP1 source block: https://picasaweb.google.com/101968292957887487468/DQPSKMODULATION#5733510074110374626 I hope to see any spectrum there! Also I hope to see a kind of cosine signal in the scope at the final of the flow graph but I see nothing! I dont know what I am doing wrong. I am transmitting 16 samples/symbol with a symbol rate of 125 ksymbols/seg which is equal to a sample rate of 2 Msamples/s at the TX and RX UHD - USRP block.The center frequency of the UHD-USRP1 block was set at 2.4 GHz because the daughter board is a RFX 2400. Also when I run this program, I can see in the terminal : UOUOOUOUOUOUOUOUOUOUOUOUOUOUOUOUOUOUOUOUO Please, I hope anyone can help me. I have working on this for a long time and I dont know what else to do. Thanks!! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC programming problem--anyone with any bright ideas?
I've been working on a flow-graph for meteor-burst detection on VHF (more specifically using the NAVSPASUR "space fence" as a signal source). Part of the flow-graph involves probes that run at several-Hz rate and decide whether to start recording signal-power data, based on triggering criteria. This works just fine. The trigger-detection/recording function also returns a filename (either /dev/null if not triggered, or a dynamically-generated filename otherwise). The intention of this is to provide the filename for a gr_file_sink to use to record downsampled baseband data during triggering. The problem, of course, is that if this variable is handed to gr_file_sink, it'll be re-opening files (either /dev/null or the "real" file) at a many-Hz rate, which is not the desired semantic. So I modified gr_file_sink to check for a *change* in filename in the open() method, and only proceed with a re-open if the filename has changed. This isn't really clean and elegant. GRC doesn't lend itself particularly well to this type of processing. I suppose I could run the baseband streams into a vector sink, and have my poll function unload those vectors whenever the poll function is called. Any hints on how to do that? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USB Audio Device name
Hello Group; I am trying to use an external USB Audio DAC. According to the documentation in the audio source block, if I leave the device name blank, the block will use the default alsa audio device. My question is, how do I find out what the name of the USB device is ?? Typing lsusb -v produced the following: Bus 002 Device 004: ID 041e:3042 Creative Technology, Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x041e Creative Technology, Ltd idProduct 0x3042 bcdDevice1.00 iManufacturer 1 Creative Technology iProduct2 SB X-Fi Surround 5.1 iSerial 0 bNumConfigurations 1 - snip -- Can anybody help here ?? Thanks; Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB Audio Device name
I have the same audio device. If you use the command line alsamixer, you can get card information from the F2 menu. /proc/asound/devices contains information for each card. I use hw:3,0 (my sequence of sound cards as I have two PCI sound cards and two USB cards) for both capture and playback on my XFI USB device. It works without problems for me. If the USB card is the only one you have then the device will be the default alsa device otherwise, it will be hw:*,0. You can also do aplay -l and get a list of alsa devices and their addresses. Hope this helps! Fred On 04/20/2012 11:52 AM, William Pretty Security wrote: Hello Group; I am trying to use an external USB Audio DAC. According to the documentation in the audio source block, if I leave the device name blank, the block will use the default alsa audio device. My question is, how do I find out what the name of the USB device is ?? Typing lsusb --v produced the following: Bus 002 Device 004: ID 041e:3042 Creative Technology, Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x041e Creative Technology, Ltd idProduct 0x3042 bcdDevice1.00 iManufacturer 1 Creative Technology iProduct2 SB X-Fi Surround 5.1 iSerial 0 bNumConfigurations 1 - snip -- Can anybody help here ?? Thanks; Bill ___ 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] GRC programming problem--anyone with any bright ideas? (fwd)
-- Forwarded message -- Date: Fri, 20 Apr 2012 09:44:34 -0700 From: Nickolas Fotopoulos To: Vladimir Dergachev Subject: Re: [Discuss-gnuradio] GRC programming problem--anyone with any bright ideas? (fwd) Vladimir, I might suggest to Marcus that he try a ramdisk cache such that many-Hz open() calls are quite cheap. Not a perfect solution, but might be the quickest to implement. Alternatively, he might defer file-writing until arbitrarily later, storing a queue of lines to be written to each file. Take care, Nick On Fri, Apr 20, 2012 at 09:37, Vladimir Dergachev wrote: In case you are interested.. -- Forwarded message -- Date: Fri, 20 Apr 2012 12:26:08 -0400 From: Marcus D. Leech To: "Discuss-gnuradio@gnu.org" Subject: [Discuss-gnuradio] GRC programming problem--anyone with any bright ideas? I've been working on a flow-graph for meteor-burst detection on VHF (more specifically using the NAVSPASUR "space fence" as a signal source). Part of the flow-graph involves probes that run at several-Hz rate and decide whether to start recording signal-power data, based on triggering criteria. This works just fine. The trigger-detection/recording function also returns a filename (either /dev/null if not triggered, or a dynamically-generated filename otherwise). The intention of this is to provide the filename for a gr_file_sink to use to record downsampled baseband data during triggering. The problem, of course, is that if this variable is handed to gr_file_sink, it'll be re-opening files (either /dev/null or the "real" file) at a many-Hz rate, which is not the desired semantic. So I modified gr_file_sink to check for a *change* in filename in the open() method, and only proceed with a re-open if the filename has changed. This isn't really clean and elegant. GRC doesn't lend itself particularly well to this type of processing. I suppose I could run the baseband streams into a vector sink, and have my poll function unload those vectors whenever the poll function is called. Any hints on how to do that? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- == Nickolas Fotopoulos Postdoctoral Scholar LIGO Laboratory, Caltech Phone: 626-395-8740 Fax: 626-304-9834 ==___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] pthread_setchedparam error in grc
Hello, I'm receiving a pthread_setchedparam error when running grc projects under Ubuntu 11.04. After reading a post from Almohanad Fayez in an archive of this mailing list, I decided to try adding kernel.sched_rt_runtime_us = -1 to my /etc/sysctl.conf file. This did change the thread priority which I was able to verify with cat /proc/sys/kernel/sched_rt_runtime_us. However, I got the same error in grc. Thus far, the only thing that will get rid of this error is if I run grc as root. I never had to run it as root on my Ubuntu 10.04 machine though. Is there a setting that I can change so that grc doesn't need to be ran as root to be able to use scheduling? Thanks! -- View this message in context: http://old.nabble.com/pthread_setchedparam-error-in-grc-tp33722768p33722768.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] pthread_setchedparam error in grc
On 04/20/2012 02:02 PM, labarowski wrote: > > Hello, > I'm receiving a pthread_setchedparam error when running grc projects under > Ubuntu 11.04. After reading a post from Almohanad Fayez in an archive of > this mailing list, I decided to try adding kernel.sched_rt_runtime_us = -1 > to my /etc/sysctl.conf file. This did change the thread priority which I was > able to verify with cat /proc/sys/kernel/sched_rt_runtime_us. However, I got > the same error in grc. Thus far, the only thing that will get rid of this > error is if I run grc as root. I never had to run it as root on my Ubuntu > 10.04 machine though. Is there a setting that I can change so that grc > doesn't need to be ran as root to be able to use scheduling? Thanks! Does this help? http://files.ettus.com/uhd_docs/manual/html/general.html#thread-priority-scheduling -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC programming problem--anyone with any bright ideas? (fwd)
On 04/20/2012 03:45 PM, Vladimir Dergachev wrote: -- Forwarded message -- Date: Fri, 20 Apr 2012 09:44:34 -0700 From: Nickolas Fotopoulos To: Vladimir Dergachev Subject: Re: [Discuss-gnuradio] GRC programming problem--anyone with any bright ideas? (fwd) Vladimir, I might suggest to Marcus that he try a ramdisk cache such that many-Hz open() calls are quite cheap. Not a perfect solution, but might be the quickest to implement. Alternatively, he might defer file-writing until arbitrarily later, storing a queue of lines to be written to each file. Take care, Nick I actually worked out a different solution, involving reflexive FIFOs seems to work. On Fri, Apr 20, 2012 at 09:37, Vladimir Dergachev wrote: In case you are interested.. -- Forwarded message -- Date: Fri, 20 Apr 2012 12:26:08 -0400 From: Marcus D. Leech To: "Discuss-gnuradio@gnu.org" Subject: [Discuss-gnuradio] GRC programming problem--anyone with any bright ideas? I've been working on a flow-graph for meteor-burst detection on VHF (more specifically using the NAVSPASUR "space fence" as a signal source). Part of the flow-graph involves probes that run at several-Hz rate and decide whether to start recording signal-power data, based on triggering criteria. This works just fine. The trigger-detection/recording function also returns a filename (either /dev/null if not triggered, or a dynamically-generated filename otherwise). The intention of this is to provide the filename for a gr_file_sink to use to record downsampled baseband data during triggering. The problem, of course, is that if this variable is handed to gr_file_sink, it'll be re-opening files (either /dev/null or the "real" file) at a many-Hz rate, which is not the desired semantic. So I modified gr_file_sink to check for a *change* in filename in the open() method, and only proceed with a re-open if the filename has changed. This isn't really clean and elegant. GRC doesn't lend itself particularly well to this type of processing. I suppose I could run the baseband streams into a vector sink, and have my poll function unload those vectors whenever the poll function is called. Any hints on how to do that? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] pthread_setchedparam error in grc
Exactly what I was looking for Josh. Grc gave a prompt to check the documentation along with the error but I was unable to find this. Thanks and I'm sorry to bother you with something that should have been apparent with a little searching - I just wasn't looking in the right places. On 4/20/2012 8:51 PM, Josh Blum wrote: Does this help? http://files.ettus.com/uhd_docs/manual/html/general.html#thread-priority-scheduling -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
