[Discuss-gnuradio] Simple TX/RX test problem
I made a GRC flow graph like this image http://lh5.ggpht.com/_byQV8nmc5FA/TOJtmsZcuiI/AQY/ylUoDqXpXbw/s800/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7.png And the result is like this image http://lh5.ggpht.com/_byQV8nmc5FA/TOJtm9GDpXI/AQc/1MsP1mXFUNQ/s800/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7-Top%20Block.png The upper is the sender side, the lower is the receiver side How can I receive normally? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multi-port NIC for laptop
Hi all, Now I use laptop PC (Dell Studio 1737 ) with USRP2. I want to connect 2 or more USRP2s to that laptop PC. When I connect, I want to use PCI Express card ( don't use ether-hub). Does any one know any products to use that proposal? regards, youhei ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-port NIC for laptop
On Tue, 2010-11-16 at 21:12 +0900, YouheiFujii wrote: Hi all, Now I use laptop PC (Dell Studio 1737 ) with USRP2. I want to connect 2 or more USRP2s to that laptop PC. When I connect, I want to use PCI Express card ( don't use ether-hub). Does any one know any products to use that proposal? regards, youhei ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I use an ExpressCard/34 GigaNet 1000BASE-T Ethernet in my Dell Latitude E6400 laptop. I can stream to the two ports (built + the above) with decimation factor eight (four does not work, haven't tried anything in-between). However, interestingly, I can send short bursts of data (simultaneously) at decimation rate four. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Problem...usrp2 no control response
The error occurs on recieve and transmit. It only occurs on the eth1 interface with the 192.168.20.2 Usrp2. I also get the error when I run uhd_usrp_probe. It all isolated to that one usrp2. The usrp2 on eth0 works fine. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simple TX/RX test problem
Your TX amplitude is effectively zero, see the docs in the usrp sink block. Also, do not use a throttle block when you have a physical device (such as a usrp) in the stream. -josh On 11/16/2010 03:42 AM, Songsong Gee wrote: I made a GRC flow graph like this image http://lh5.ggpht.com/_byQV8nmc5FA/TOJtmsZcuiI/AQY/ylUoDqXpXbw/s800/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7.png And the result is like this image http://lh5.ggpht.com/_byQV8nmc5FA/TOJtm9GDpXI/AQc/1MsP1mXFUNQ/s800/%EC%8A%A4%ED%81%AC%EB%A6%B0%EC%83%B7-Top%20Block.png The upper is the sender side, the lower is the receiver side How can I receive normally? ___ 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
Re: [Discuss-gnuradio] UHD Problem...usrp2 no control response
Bitten by the ethernet pause frames? You may want to try the flow control branch and fpga images. See the flow_ctrl branch on the uhd repo and the flow control images here: http://www.ettus.com/downloads/uhd_images/ On 11/16/2010 07:41 AM, Justin Bracken wrote: The error occurs on recieve and transmit. It only occurs on the eth1 interface with the 192.168.20.2 Usrp2. I also get the error when I run uhd_usrp_probe. It all isolated to that one usrp2. The usrp2 on eth0 works fine. Ok, it should not happen with just the probe app. Thats just nice slow request/response transactions over UDP. You may have to put eth1 down. -Josh ___ 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] UHD Problem...usrp2 no control response
It looks like the uhd image is: uhd-images-20100901.003255.b5461fc-linux Maybe that helps. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Unstable Behavior
I set up a two-node link using tunnel.py, two nodes continuously exchanged data with each other. Quite often, GNU Radio stopped in one node because of the following error. Any hints to resolve this problem will be highly appreciated. Andrew Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 532, in __bootstrap_inner self.run() File /home/titan/new_multi_chan/pkt.py, line 95, in run ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) File /usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py, line 183, in unmake_packet payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset) File /usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py, line 95, in dewhiten return whiten(s, o)# self inverse File /usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py, line 91, in whiten z = sa ^ random_mask_vec8[o:len(sa)+o] ValueError: shape mismatch: objects cannot be broadcast to a single shape ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD IP Address Setting Issue
Hi all, I'm trying to get a MIMO setup working using USRP2s with the UHD drivers. I have a PC with 2 gigabit Ethernet interfaces, and a USRP2 connected to each. My problem is that I can't change the USRP2 IP address so that the two devices have different addresses. I can set the IP address in the motherboard EEPROM using usrp_burn_mb_eeprom, and I can see the updated IP address reported when I run uhd_usrp_probe, but the IP address the USRP2 answers to is still 192.168.10.2. Power-cycling the device has no effect, nor does trying another PC in case of any address caching. I've tried with UHD firmware fpga images built myself from the latest git, and also with the 01/09/2010 release. I've seen on the mailing list archives that some people have had success with MIMO and UHD, and I haven't found any reference to IP address problems. I must be missing something. Could anyone help please? Thanks in advance, Adam -- Roke Manor Research Ltd, Romsey, Hampshire, SO51 0ZN, United Kingdom Part of the Chemring Group Registered in England Wales at: Chemring Group PLC, Chemring House, 1500 Parkway, Whiteley, Fareham, Hampshire PO15 7AF, ENGLAND Registered Number: 267550 Visit our website at www.roke.co.uk The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. Please consider the environment before printing this email ~ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help: usrp tune not working in wbx daughter board
On Tue, Nov 16, 2010 at 1:26 AM, ton ph ph.ton.sha...@gmail.com wrote:
Thanks steven ,
I am able to tune steven , but same old problem in which the tune
start before and the information which i see is a little bit late , as it
seems reading from the previous buffer of the fifo. And my tuning happens
dynamically when i got a particular info after processing the fifo contents,
i have to tune at that time and i cannot determine the time when it will
come.
And i was thinking ,if after tuning if i flush out the fifo contents wont
it give proper result .. i m attaching the logic part how i m reading the
fifo using subprocess in python hope it will make more clearer
explaination of my problem
# this is inside a thread run part
# reads the fifo with usrp info
cmd = [' ./pythonProg1.py | ./pythonProg2.py ']
proc = subprocess.Popen(cmd, shell=True, bufsize=0, stdout=subprocess.PIPE,
stderr=subprocess.STDOUT )
count = 0
next_frequency = [123,435,456]
while flag == True:
line = proc.stdout.readline()
# returns the tuned frequency only and YES when satisfy
some problem
print line
if line == YES:
# tune to another frequency
usrp.tune_frequency(next_frequency[count])
count =count +1
Might be i have implemented in a very wrong way but my situation is this
steve.
the subprocess runs a command in cmd variable using pipe. pythonProg1
output is fed to
pythonProg2.py and after this the output which i get in line variable is
YES , until then the usrp
stay tune to that frequency and returns frequency tuned to and when i get
the YES i tune to another frequency and tunes until end of
contents in the list next_frequency
Hope i explain my problem thorougly ... and may be i can implement in a
different way , but i cant as imy system
has become bigger now.Please guide me if you have any means to solve my
problem
i want to see line variable to show me the tuned frequency the moment i
tune to that frequency.
Thanks for your concern
On Mon, Nov 15, 2010 at 8:17 PM, Steven Clark steven.p.cl...@gmail.comwrote:
On Sun, Nov 14, 2010 at 11:49 PM, ton ph ph.ton.sha...@gmail.com wrote:
hi steven,
Definitely yes , i am not getting any error and also no effect in tune,
i can see ... but i dont know why its not been affected.Moreover i am using
a fifo file and simultaneously reading the fifo using another thread. I was
also having a doubt if is it that the usrp is tuned , but i am reading the
info from the buffer of the previous frequency... means thou its tuned but
we get a display of the previous info of my previous frequency from the
buffer can you please guide me
Thanks.
The error is probably in the FIFO mechanism, or as you say you might not
be reading out to where the newly-tuned data starts. Try to simplify the
setup. Something like this, where you only write the file, rather than
trying to write read at same time. After the program finishes, analyze the
file and make sure it has the frequency tune near the middle of the file.
class MyTopBlock(gr.top_block):
def __init__(self):
samp_rate = 125e3 #or something low, match with decimation rate
num_samps = samp_rate * 5 #roughly 5 seconds of capture
self.u = usrp.source_c()
self.limiter = gr.head(gr.sizeof_gr_complex, num_samps) #limit
number of samples to file
self.fileout = gr.file_sink(...)
...
self.connect(self.u, self.limiter, self.fileout)
class MyTunerThread(threading.Thread):
def __init__(self, topblock):
threading.Thread.__init__(self)
self.topblock = topblock
def run(self):
time.sleep(2.5)
self.topblock.tune(new_freq)
def main():
tb = MyTopBlock()
tt = MyTunerThread(tb)
tt.start()
tb.run()
print('top block done')
tt.join()
print('tuner thread exited')
if __name__ == '__main__':
main()
Ok, so there is no problem with tuning (initially you said i am not able to
use my thread to tune the usrp).
Instead, you have a problem with timing/synchronization. I don't know if you
will ever be able to achieve the perfect timing you are looking for...after
you issue a tune command, there will always be some number of samples that
come out of the USRP at the old frequency (due to buffering) followed by
some number of samples (~200us worth) during which the LO is unstable
(locking to new frequency), followed by samples at new frequency. The best
you can do is to try to keep the FIFO as empty as possible to minimize the
lag, and try to calibrate out the remaining lag as best as possible, and
throw away samples in the uncertain period. Otherwise, you can stop the
flowgraph when your condition is met, let the remaining samples flush out,
issue the tune, wait a little bit, then
[Discuss-gnuradio] Re: get fatal IO error 11 when running usrp2_fft.py (USRP2 + XCVR2450)
Hi Marcus D. Leech, Thanks for your response. I try the -d 40 on the command usrp2_fft.py. The problem is still here. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD IP Address Setting Issue
Hi, usrp2_card_burner_gui.py in share/uhd/utils worked fine for me on Ubuntu 10.04. Did you set the network interfaces addresses properly? Cheers, Veljko On Tue, Nov 16, 2010 at 8:57 AM, Gregory, Adam adam.greg...@roke.co.uk wrote: Hi all, I’m trying to get a MIMO setup working using USRP2s with the UHD drivers. I have a PC with 2 gigabit Ethernet interfaces, and a USRP2 connected to each. My problem is that I can’t change the USRP2 IP address so that the two devices have different addresses. I can set the IP address in the motherboard EEPROM using usrp_burn_mb_eeprom, and I can see the updated IP address reported when I run uhd_usrp_probe, but the IP address the USRP2 answers to is still 192.168.10.2. Power-cycling the device has no effect, nor does trying another PC in case of any address caching. I’ve tried with UHD firmware fpga images built myself from the latest git, and also with the 01/09/2010 release. I’ve seen on the mailing list archives that some people have had success with MIMO and UHD, and I haven’t found any reference to IP address problems. I must be missing something. Could anyone help please? Thanks in advance, Adam -- Roke Manor Research Ltd, Romsey, Hampshire, SO51 0ZN, United Kingdom Part of the Chemring Group Registered in England Wales at: Chemring Group PLC, Chemring House, 1500 Parkway, Whiteley, Fareham, Hampshire PO15 7AF, ENGLAND. Registered No: 267550 Visit our website at www.roke.co.uk The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. Please consider the environment before printing this email ___ 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
Re: [Discuss-gnuradio] UHD IP Address Setting Issue
On 11/16/2010 11:57 AM, Gregory, Adam wrote: Hi all, I'm trying to get a MIMO setup working using USRP2s with the UHD drivers. I have a PC with 2 gigabit Ethernet interfaces, and a USRP2 connected to each. My problem is that I can't change the USRP2 IP address so that the two devices have different addresses. I can set the IP address in the motherboard EEPROM using usrp_burn_mb_eeprom, and I can see the updated IP address reported when I run uhd_usrp_probe, but the IP address the USRP2 answers to is still 192.168.10.2. Power-cycling the device has no effect, nor does trying another PC in case of any address caching. I've tried with UHD firmware fpga images built myself from the latest git, and also with the 01/09/2010 release. I've seen on the mailing list archives that some people have had success with MIMO and UHD, and I haven't found any reference to IP address problems. I must be missing something. Could anyone help please? Thanks in advance, Adam -- Send us an ifconfig of your two GiGe interfaces ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: get fatal IO error 11 when running usrp2_fft.py (USRP2 + XCVR2450)
On Tue, Nov 16, 2010 at 12:27:07PM -0500, XIAN PAN wrote: Hi Marcus D. Leech, Thanks for your response. I try the -d 40 on the command usrp2_fft.py. The problem is still here. Is your system running out of memory? Look at the output of $ dmesg and look at /var/log/messages $ sudo tail -1000 /var/log/messages | less Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2+WBX - How to use precisely an 8 MHz band?
Thank you all, for your replies! I am a bit confused about the 10 rate decimation, which just gets one halfband (the low rate one) - as explained in USRP2 FAQ. Does this affect the power level that I will later measure? I thought about using 8 which is also a multiple of 4, but it is a very unfortunate fraction and I would like to keep as much as possible from the original band, plus the 10 rate will also decrease the load on my processor. So, is the 10 rate decimation in fact a good candidate for what I'm trying to do or I'm better of using 8 with a 1.5625 rational resampler? Thank you all. Vlad. Matt Ettus wrote: On 11/11/2010 07:46 AM, Vladutzzz wrote: Dear all, I am trying to receive with my USRP2 + WBX daughterboard a signal band of precisely 8 MHz in order to measure it's power. The problem is that since USRP2 has a 100 MSample/s sampling and I can't just devide it by 12.5 to get the desidered 8 MHz band, I need to use an FPGA decimation of 100 together with an interpolation of 8 in order to get the desidered results (I am not using decim 25 and interpol 2, because it is said in the specification of USRP2 that both parameters have to be at least 4, and multiples of 4, in order to get the full band). Is this the only way of going about this operation? Doesn't this eliminate too much usefull information? Please let me know if you would this in a different way! Thank you for your time! I would suggest decimating by 8 or 10, and then filtering in software to get the exact bandwidth you need. Matt ___ 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/USRP2%2BWBX---How-to-use-precisely-an-8-MHz-band--tp30191243p30231121.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: [Discuss-gnuradio] GNU Radio Unstable Behavior
On Tue, Nov 16, 2010 at 11:51:51AM -0500, g...@vt.edu wrote: I set up a two-node link using tunnel.py, two nodes continuously exchanged data with each other. Quite often, GNU Radio stopped in one node because of the following error. Any hints to resolve this problem will be highly appreciated. Andrew Exception in thread Thread-1: Traceback (most recent call last): File /usr/lib/python2.6/threading.py, line 532, in __bootstrap_inner self.run() File /home/titan/new_multi_chan/pkt.py, line 95, in run ok, payload = packet_utils.unmake_packet(msg.to_string(), int(msg.arg1())) File /usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py, line 183, in unmake_packet payload_with_crc = dewhiten(whitened_payload_with_crc, whitener_offset) File /usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py, line 95, in dewhiten return whiten(s, o)# self inverse File /usr/local/lib/python2.6/dist-packages/gnuradio/packet_utils.py, line 91, in whiten z = sa ^ random_mask_vec8[o:len(sa)+o] ValueError: shape mismatch: objects cannot be broadcast to a single shape I looks like you may be passing a zero-length string to unmake_packet, and that whiten doesn't not properly deal with a zero length string. Try not calling unmake_packet if msg.to_string() returns a zero length string. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD IP Address Setting Issue
A fix has been pushed (the eeprom offset was wrong). -Josh On 11/16/2010 08:57 AM, Gregory, Adam wrote: Hi all, I'm trying to get a MIMO setup working using USRP2s with the UHD drivers. I have a PC with 2 gigabit Ethernet interfaces, and a USRP2 connected to each. My problem is that I can't change the USRP2 IP address so that the two devices have different addresses. I can set the IP address in the motherboard EEPROM using usrp_burn_mb_eeprom, and I can see the updated IP address reported when I run uhd_usrp_probe, but the IP address the USRP2 answers to is still 192.168.10.2. Power-cycling the device has no effect, nor does trying another PC in case of any address caching. I've tried with UHD firmware fpga images built myself from the latest git, and also with the 01/09/2010 release. I've seen on the mailing list archives that some people have had success with MIMO and UHD, and I haven't found any reference to IP address problems. I must be missing something. Could anyone help please? Thanks in advance, Adam -- Roke Manor Research Ltd, Romsey, Hampshire, SO51 0ZN, United Kingdom Part of the Chemring Group Registered in England Wales at: Chemring Group PLC, Chemring House, 1500 Parkway, Whiteley, Fareham, Hampshire PO15 7AF, ENGLAND Registered Number: 267550 Visit our website at www.roke.co.uk The information contained in this e-mail and any attachments is proprietary to Roke Manor Research Ltd and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. Please consider the environment before printing this email ~ ___ 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
Re: [Discuss-gnuradio] Re: get fatal IO error 11 when running usrp2_fft.py (USRP2 + XCVR2450)
On 11/16/2010 12:27 PM, XIAN PAN wrote: Hi Marcus D. Leech, Thanks for your response. I try the -d 40 on the command usrp2_fft.py. The problem is still here. If you *dont* use Peak Hold, does it work? There was a problem, deep in the bowels of OpenGL related to the Peak Hold function that seemed to cause this behaviour. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD Problem...usrp2 no control response
It was the ethernet card. Just a suggestion but it might be nice to add this to the debugging network problems section of UHD-USRP2 Application Notes. Thank you very much Josh! Specifically I found uhd_find_devices and uhd_usrp_probe --args device-specific-address-args to be useful next steps after pinging the usrp2s to find them. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Amplifier
Hi Everyone, Does anyone have a suggestion for an off the shelf low frequency amplifier to use with the USRP? I have a USRP2 with a LFTX board and I run the RF output to a Bias T attached to an LED driver (I'm using the system as a Visual Light Commmunication setup). I noticed that the Ettus FAQ suggests using a simple connectorized amplifier, but the minimum operating frequency for anything I've found is around 10MHz, and the max frequency my system can operate at is 5MHz (bandwidth limitations of the LED). Any suggestions would be greatly appreciated, Michael Rahaim Graduate Research Assistant Smart Lighting Engineering Research Center Boston University mrah...@bu.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-XCVR2450 receive problem
HI Josh, Thanks for your response. The firmware I used is txrx_xcvr_raw_eth_20100608.bin. I think it is the latest version for xcvr2450. I guess there is a problem be shown in the waveform after using the usrp2_fft.py (see the attachment, the red cycle part in the screenshot). In my test, the red cycle part shows . But other person's test result shows XCVR2450 at the same position. I also attach this person's result in the attach (the only difference is this person uses USRP1 + XCVR2450). Is there any different between using USRP2+xcvr2450 with using USRP1+XCVR2450?? I have two USRP2+XCVR2450 and none of them can get the signal. I really want to know what is happen. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio on F14
Marcus: I'm curious about that last statement you made, F14 is running python2.7, so I had to update my .bashrc to reflect this. I might be running Fedora 14 with GNU Radio 3.3.0 soon too, so I'm curious what you had to change in your .bashrc file. Also, I noticed that you did NOT use GNU Radio 3.3.0, but rather you used the latest branch in Git. What branch specifically did you use? I guess I will need to do the same. Fedora 14 uses gcc version 4.5.1, right? Thanks. Steve McMahon --- On Tue, 11/16/10, Marcus D. Leech mle...@ripnet.com wrote: From: Marcus D. Leech mle...@ripnet.com Subject: [Discuss-gnuradio] Gnu Radio on F14 To: Discuss-gnuradio@gnu.org Date: Tuesday, November 16, 2010, 7:30 AM Got my F14 system together today, and build Gnu Radio, with UHD from the latest GIT source. It went without incident. My new F14 machine is an x86_64 machine, an AMD Phenom X3, with 4GB of memory. F14 is running python2.7, so I had to update my .bashrc to reflect this. -- 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] How to connect LP0410 to the daughter board?
Hi, We bought several LP0410 antennas, but not sure how to connect them to the daughter board. The LP0926 has a male SMA connector to it, but the LP0410 doesn't. That means we need to buy an SMA connector and solder it to the LP0410. My question is what kind of SMA connector will fit? What type of SMA connector did you use for the LP0926? Will it fit in LP0410? I saw a list of SMA connectors here: http://www.rfconnector.com/sma-end-launch-jack-pcb-connectors.html Which one do you think is the appropriate one for LP0410? Also, what kind of stand do you use to mount the antenna? Thanks! Ming___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio on F14
On 11/16/2010 02:48 PM, Steve Mcmahon wrote:
Marcus:
I'm curious about that last statement you made, F14 is running python2.7, so
I had to update my .bashrc to reflect this. I might be running Fedora 14
with GNU Radio 3.3.0 soon too, so I'm curious what you had to change in your
.bashrc file.
I had to change my PYTHONPATH to reflect the new version of Python:
PYTHONPATH=/usr/local/lib/python2.7/site-packages
or
PYTHONPATH=/usr/local/lib64/python2.7/site-packages
depending on whether you're on a 64 or 32-bit machine.
I've attached a little shell script that can set the PYTHONPATH
appropriately, by finding
the appropriate bits dynamically.
Also, I noticed that you did NOT use GNU Radio 3.3.0, but rather you used the
latest branch in Git. What branch specifically did you use? I guess I will
need to do the same.
I use the next branch, because I'm a UHD user.
Fedora 14 uses gcc version 4.5.1, right?
Yes.
--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
#!/bin/sh
mach_type=`uname -m`
lib=lib
if [ $mach_type = x86_64 ]
then
lib=lib64
fi
for version in 2.9 2.8 2.7 2.6
do
if [ -d /usr/local/$lib/python${version}/site-packages ]
then
break
fi
done
PYTHONPATH=/usr/local/$lib/python${version}/site-packages:$HOME/python:$HOME/bin
export PYTHONPATH
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to connect LP0410 to the daughter board?
2010/11/16 Ming Wah wanmingw...@163.com: Hi, We bought several LP0410 antennas, but not sure how to connect them to the daughter board. The LP0926 has a male SMA connector to it, but the LP0410 doesn't. That means we need to buy an SMA connector and solder it to the LP0410. My question is what kind of SMA connector will fit? What type of SMA connector did you use for the LP0926? Will it fit in LP0410? The same SMA connector should have come with the LP0410 and requires soldering it into place. This document shows how to connect either an SMA connector or cable to the LP0410: http://www.ettus.com/downloads/LP0410.pdf The connector you want is: LTI-SASF54GT from rfconnector.com (lighthorse) or another PCB Mount SMA with compatible footprint Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to connect LP0410 to the daughter board?
The connector should have been included. Send an email to sa...@ettus.com with your order number and we'll have them sent to you. Matt Ming Wah wanmingw...@163.com wrote: Hi, We bought several LP0410 antennas, but not sure how to connect them to the daughter board. The LP0926 has a male SMA connector to it, but the LP0410 doesn't. That means we need to buy an SMA connector and solder it to the LP0410. My question is what kind of SMA connector will fit? What type of SMA connector did you use for the LP0926? Will it fit in LP0410? I saw a list of SMA connectors here: http://www.rfconnector.com/sma-end-launch-jack-pcb-connectors.html Which one do you think is the appropriate one for LP0410? Also, what kind of stand do you use to mount the antenna? Thanks! Ming ___ 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
Re: [Discuss-gnuradio] Multi-port NIC for laptop
(2010/11/17 0:24), Per Zetterberg wrote: On Tue, 2010-11-16 at 21:12 +0900, YouheiFujii wrote: Hi all, Now I use laptop PC (Dell Studio 1737 ) with USRP2. I want to connect 2 or more USRP2s to that laptop PC. When I connect, I want to use PCI Express card ( don't use ether-hub). Does any one know any products to use that proposal? regards, youhei ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio I use an ExpressCard/34 GigaNet 1000BASE-T Ethernet in my Dell Latitude E6400 laptop. I can stream to the two ports (built + the above) with decimation factor eight (four does not work, haven't tried anything in-between). However, interestingly, I can send short bursts of data (simultaneously) at decimation rate four. BR/ Per Which products do you use? If you don't mind, please tell me the name of products. regard,youhei ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Build broken today
I did a git pull for both UHD (master) and gnuradio (next) today, and a make clean; make in both places. The build is currently broken: eech/gnuradio/gruel/src/include -I/home/mleech/gnuradio/gruel/src/include -I/usr/include -I/usr/local/include -I../../gr-uhd/lib \ -MD -MF .deps/uhd_swig.Std \ -module uhd_swig -o uhd_swig.cc uhd_swig.i; then \ if test linux-gnu = mingw32; then \ /bin/rm -f .deps/uhd_swig.Sd; \ /bin/sed 's,,/,g' .deps/uhd_swig.Std \ .deps/uhd_swig.Sd; \ /bin/rm -f .deps/uhd_swig.Std; \ .deps/uhd_swig.Sd .deps/uhd_swig.Std; \ fi; \ else \ /bin/rm -f .deps/uhd_swig.S*; exit 1; \ fi; /usr/local/include/uhd/types/ranges.hpp:59: Error: Syntax error in input(3). make[5]: *** [.deps/uhd_swig-generate-stamp] Error 1 make[5]: Leaving directory `/home/mleech/gnuradio/gr-uhd/swig' ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build broken today
I pushed the wrong thing... ok fixing, please wait... On 11/16/2010 01:38 PM, Marcus D. Leech wrote: I did a git pull for both UHD (master) and gnuradio (next) today, and a make clean; make in both places. The build is currently broken: eech/gnuradio/gruel/src/include -I/home/mleech/gnuradio/gruel/src/include -I/usr/include -I/usr/local/include -I../../gr-uhd/lib \ -MD -MF .deps/uhd_swig.Std \ -module uhd_swig -o uhd_swig.cc uhd_swig.i; then \ if test linux-gnu = mingw32; then \ /bin/rm -f .deps/uhd_swig.Sd; \ /bin/sed 's,,/,g' .deps/uhd_swig.Std \ .deps/uhd_swig.Sd; \ /bin/rm -f .deps/uhd_swig.Std; \ .deps/uhd_swig.Sd .deps/uhd_swig.Std; \ fi; \ else \ /bin/rm -f .deps/uhd_swig.S*; exit 1; \ fi; /usr/local/include/uhd/types/ranges.hpp:59: Error: Syntax error in input(3). make[5]: *** [.deps/uhd_swig-generate-stamp] Error 1 make[5]: Leaving directory `/home/mleech/gnuradio/gr-uhd/swig' ___ 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
Re: [Discuss-gnuradio] Build broken today
On Tue, Nov 16, 2010 at 4:38 PM, Marcus D. Leech mle...@ripnet.com wrote: I did a git pull for both UHD (master) and gnuradio (next) today, and a make clean; make in both places. The build is currently broken: ... /usr/local/include/uhd/types/ranges.hpp:59: Error: Syntax error in input(3). make[5]: *** [.deps/uhd_swig-generate-stamp] Error 1 make[5]: Leaving directory `/home/mleech/gnuradio/gr-uhd/swig' Different but possibly related breakage in my applications after today's pull. Looks like the API may have changed a bit. UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘max’ UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘min’ Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio on F14
Marcus: Thanks for your help and feedback, and for the script. I really appreciate you taking the time. One more question: Since I am not a UHD user and I use my USRP2 with raw Ethernet, which Git branch should I use? Thanks again! Steve McMahon --- On Tue, 11/16/10, Marcus D. Leech mle...@ripnet.com wrote: From: Marcus D. Leech mle...@ripnet.com Subject: Re: [Discuss-gnuradio] Gnu Radio on F14 To: Steve Mcmahon steve.mcmaho...@yahoo.com Cc: GNR discuss-gnuradio@gnu.org Date: Tuesday, November 16, 2010, 3:06 PM On 11/16/2010 02:48 PM, Steve Mcmahon wrote: Marcus: I'm curious about that last statement you made, F14 is running python2.7, so I had to update my .bashrc to reflect this. I might be running Fedora 14 with GNU Radio 3.3.0 soon too, so I'm curious what you had to change in your .bashrc file. I had to change my PYTHONPATH to reflect the new version of Python: PYTHONPATH=/usr/local/lib/python2.7/site-packages or PYTHONPATH=/usr/local/lib64/python2.7/site-packages depending on whether you're on a 64 or 32-bit machine. I've attached a little shell script that can set the PYTHONPATH appropriately, by finding the appropriate bits dynamically. Also, I noticed that you did NOT use GNU Radio 3.3.0, but rather you used the latest branch in Git. What branch specifically did you use? I guess I will need to do the same. I use the next branch, because I'm a UHD user. Fedora 14 uses gcc version 4.5.1, right? Yes. -- 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] Build broken today
Thats why i was waiting to push. But I did it anyway so... The ranges are now meta-ranges (ranges of ranges) that can hold discontinuous ranges and discrete values. The members min, max, and step were replaced with start(), stop(), and step(). That will give you the overall range. Also, since this is a range of ranges, you can iterate through it and get each sub-range (also with start, stop, and step). A good example of this is the XCVR2450 that has two discontinuous frequency ranges. BTW, the fixes are pushed to next on gnuradio. -Josh On 11/16/2010 02:01 PM, Thomas Tsou wrote: On Tue, Nov 16, 2010 at 4:38 PM, Marcus D. Leechmle...@ripnet.com wrote: I did a git pull for both UHD (master) and gnuradio (next) today, and a make clean; make in both places. The build is currently broken: ... /usr/local/include/uhd/types/ranges.hpp:59: Error: Syntax error in input(3). make[5]: *** [.deps/uhd_swig-generate-stamp] Error 1 make[5]: Leaving directory `/home/mleech/gnuradio/gr-uhd/swig' Different but possibly related breakage in my applications after today's pull. Looks like the API may have changed a bit. UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘max’ UHDDevice.cpp:260: error: ‘struct uhd::gain_range_t’ has no member named ‘min’ Thomas ___ 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
Re: [Discuss-gnuradio] Ettus Research Announcements -- Nov 2010
Hello Matt: Why the name USRP N210 instead of just USRP3? I just want to understand the new naming scheme. You imply that the N210 is but the first in a series of future N200-family devices. Could you comment on your plans for these devices? What is the product roadmap for the N220, N230, etc.? Thanks. Steve McMahon --- On Thu, 11/11/10, Matt Ettus m...@ettus.com wrote: From: Matt Ettus m...@ettus.com Subject: [Discuss-gnuradio] Ettus Research Announcements -- Nov 2010 To: gnuradio Discuss-gnuradio@gnu.org, usrp-us...@lists.ettus.com usrp-us...@lists.ettus.com, usrp-annou...@lists.ettus.com Date: Thursday, November 11, 2010, 6:32 PM === Ettus Research Announcements November 2010 1 USRP Nominated for Technology of the Year! 2 USRP N210 Product Announcement 3 DBSRX2 Product Announcement 4 RFX2200 Product Announcement 5 Rackmount Product Announcement 6 UHD Driver status 7 New Simulink Drivers for the USRP2 8 New Mailing List 9 DBSRX and TVRX End of Life 10 SDR'10 Conference and GNU Radio Meeting === 1 USRP Nominated for Technology of the Year! The USRP Family of Products has been nominated for the 2010 Technology of the Year award from the Wireless Innovation Forum. We are very honored to have the USRP family be nominated from among the many exciting products and technologies in the Software Radio field. Members of the Wireless Innovation Forum may cast their vote online for the winner here: http://groups.winnforum.org/p/su/rd/sid=56 Votes need to be in by 12 Pacific Time on Friday Nov 12th. === 2 USRP N210 Product Announcement The USRP N210 software radio system builds on the success of the USRP2, offering higher performance and increased flexibility. The N210 offers the following improvements over the USRP2: - Xilinx Spartan 3A-DSP3400 FPGA - on-board TCXO frequency reference - Flash configuration memory. - An improved ADC (still 14 bits, 100 MS/s) The flash memory replaces the SD card used on the USRP2, and is reprogrammable over the network. The N210 is usable with our entire line of daughterboards. The USRP N210 introductory price is $1700, and orders placed now will ship in mid- to late- December. The USRP2 will continue to be available for those who cannot use the N210, but lead times may be longer. === 3 DBSRX2 Product Announcement The DBSRX2 is now shipping. It has the same price ($150) and features as the original DBSRX, including an 800 MHz to 2.4 GHz frequency range, with the following improvements: - Better phase noise - No modifications necessary to use with the USRP2 The DBSRX2 works with all USRP motherboards, including USRP1, USRP2, and USRP N210. The DBSRX2 requires the use of the UHD drivers. Please see below for status of the original DBSRX. === 4 RFX2200 Product Announcement The RFX2200 is now shipping. This transceiver covers 2.0 GHz to 2.45 GHz, has 50+ mW output power, and is otherwise similar to the other members of the RFX-series. It is full duplex capable, and is ideal for use in the satellite up and downlink bands. It costs $275 and works with all USRP systems. === 5 Rackmount Product Announcement We are now selling a rack mount frame for the USRP2 and USRP N210 products. This frame allows 4 systems to be mounted in a standard 19 rack, occupying 3 Units of space. It costs $250. You can see a picture of it here: http://www.ettus.com/images/U2-Rackmount.JPG === 6 UHD Driver status The UHD is now the preferred driver system for all USRP products. It supports all of our hardware, and works well with GNU Radio as well as other software packages. It is strongly recommended that users migrate their applications to the new system. More information about the UHD can be found here: http://www.ettus.com/uhd_docs/manual/html/ === 7 New Simulink Drivers for the USRP2 The MathWorks latest version (release R2010b) of Communications Blockset™ for Simulink® now ships with receiver and transmitter interface blocks to the USRP2. These blocks allow engineers to speed development of communications systems in a design environment that streams real world signals to and from the USRP2 radio. More information can be found here:
Re: [Discuss-gnuradio] Ettus Research Announcements -- Nov 2010
Hello Matt: Sorry, one more question. Will the USRP N210 still support the raw Ethernet interface to the host (like for the USRP2), or will it only support the new UHD interface? Secondly, what is performance penalty of UHD interface versus the raw Ethernet interface? UHD is based on UDP, so certainly there must be some reduction in the maximum data rate (and thus the bandwidth) compared the raw Ethernet interface. UDP certainly adds overhead... Finally, if the USRP N210 only supports the new UHD interface, what is the reason that the current raw Ethernet interface is being deprecated in favor of UHD? What are the advantages of UHD compared to raw Ethernet? What are the disadvantages? Thanks a lot for answering all these questions!! Steve McMahon --- On Thu, 11/11/10, Matt Ettus m...@ettus.com wrote: From: Matt Ettus m...@ettus.com Subject: [Discuss-gnuradio] Ettus Research Announcements -- Nov 2010 To: gnuradio Discuss-gnuradio@gnu.org, usrp-us...@lists.ettus.com usrp-us...@lists.ettus.com, usrp-annou...@lists.ettus.com Date: Thursday, November 11, 2010, 6:32 PM === Ettus Research Announcements November 2010 1 USRP Nominated for Technology of the Year! 2 USRP N210 Product Announcement 3 DBSRX2 Product Announcement 4 RFX2200 Product Announcement 5 Rackmount Product Announcement 6 UHD Driver status 7 New Simulink Drivers for the USRP2 8 New Mailing List 9 DBSRX and TVRX End of Life 10 SDR'10 Conference and GNU Radio Meeting === 1 USRP Nominated for Technology of the Year! The USRP Family of Products has been nominated for the 2010 Technology of the Year award from the Wireless Innovation Forum. We are very honored to have the USRP family be nominated from among the many exciting products and technologies in the Software Radio field. Members of the Wireless Innovation Forum may cast their vote online for the winner here: http://groups.winnforum.org/p/su/rd/sid=56 Votes need to be in by 12 Pacific Time on Friday Nov 12th. === 2 USRP N210 Product Announcement The USRP N210 software radio system builds on the success of the USRP2, offering higher performance and increased flexibility. The N210 offers the following improvements over the USRP2: - Xilinx Spartan 3A-DSP3400 FPGA - on-board TCXO frequency reference - Flash configuration memory. - An improved ADC (still 14 bits, 100 MS/s) The flash memory replaces the SD card used on the USRP2, and is reprogrammable over the network. The N210 is usable with our entire line of daughterboards. The USRP N210 introductory price is $1700, and orders placed now will ship in mid- to late- December. The USRP2 will continue to be available for those who cannot use the N210, but lead times may be longer. === 3 DBSRX2 Product Announcement The DBSRX2 is now shipping. It has the same price ($150) and features as the original DBSRX, including an 800 MHz to 2.4 GHz frequency range, with the following improvements: - Better phase noise - No modifications necessary to use with the USRP2 The DBSRX2 works with all USRP motherboards, including USRP1, USRP2, and USRP N210. The DBSRX2 requires the use of the UHD drivers. Please see below for status of the original DBSRX. === 4 RFX2200 Product Announcement The RFX2200 is now shipping. This transceiver covers 2.0 GHz to 2.45 GHz, has 50+ mW output power, and is otherwise similar to the other members of the RFX-series. It is full duplex capable, and is ideal for use in the satellite up and downlink bands. It costs $275 and works with all USRP systems. === 5 Rackmount Product Announcement We are now selling a rack mount frame for the USRP2 and USRP N210 products. This frame allows 4 systems to be mounted in a standard 19 rack, occupying 3 Units of space. It costs $250. You can see a picture of it here: http://www.ettus.com/images/U2-Rackmount.JPG === 6 UHD Driver status The UHD is now the preferred driver system for all USRP products. It supports all of our hardware, and works well with GNU Radio as well as other software packages. It is strongly recommended that users migrate their applications to the new system. More information about the UHD can be found here: http://www.ettus.com/uhd_docs/manual/html/
[Discuss-gnuradio] waterfall question
Hello All, I began coding my own waterfall for a program using the Python specgram function, but noticed that gnuradio has some python files with waterfall in the title. I cannot figure out what exactly I need to do to include a gnuradio waterfall gui block in my program. Yes, I am a gnuub. It seems like I need to have from gnuradio.wxgui import waterfallsink_gl or something similar. What function or object should I use in my python program? Any help or comments are greatly appreciated. Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus Research Announcements -- Nov 2010
On 11/16/2010 05:12 PM, Steve Mcmahon wrote: Hello Matt: Why the name USRP N210 instead of just USRP3? I just want to understand the new naming scheme. You imply that the N210 is but the first in a series of future N200-family devices. Could you comment on your plans for these devices? What is the product roadmap for the N220, N230, etc.? Thanks. Steve McMahon Steve, Thanks for the question. Even internally we get confused about the new naming scheme. Each product number is one letter and 3 digits. The letter denotes how the device is attached to the computer -- B stands for bus (i.e. USB) N for network (ethernet in this case) E for embedded computer The first digit roughly indicates a product generation. In this case, 2 for the 2nd generation of our network devices. The 2nd digit indicates option levels. In this case 1 indicates the larger S3A-3400 DSP FPGA. The third digit indicates major revisions. In this case we are on the zeroth revision. Had this naming system been around when the USRP1 was introduced, it would have been called the USRP B100. There's no point in renaming it now, so we'll continue calling it the USRP1. Similarly, the USRP2 would have been called the USRP N100, but we won't be renaming it. There is a USRP N200 planned for March which will have a smaller Spartan 3A DSP 1800 FPGA instead of the 3400 in the already-announced N210. This will cost $200 less than the N210 because of the smaller FPGA. We also will be making a formal announcement very soon about the USRP E100 and USRP E110 which will be embedded radio systems with 2 different sizes of FPGA. We have other products in development which will further exercise this new naming system :) Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus Research Announcements -- Nov 2010
On 11/16/2010 08:20 PM, Steve Mcmahon wrote:
Secondly, what is performance penalty of UHD interface versus the raw Ethernet
interface? UHD is based on UDP, so certainly there must be some reduction in
the maximum data rate (and thus the bandwidth) compared the raw Ethernet
interface. UDP certainly adds overhead...
With UHD, you can manipulate the maximum frame sizes to an extent that
the extra bytes in the header disappear into the noise, so one
(IMHO) shouldn't be concerned that UHD is a lesser beast in terms
of on-the-wire performance.
I run a Rx-only UHD USRP2+DBS_RX in my lab
(http://science-radio-labs.com) at 25Msps, and it's fine. I don't think
that the packet
overhead is really that big an issue.
Finally, if the USRP N210 only supports the new UHD interface, what is the
reason that the current raw Ethernet interface is being deprecated in favor of
UHD? What are the advantages of UHD compared to raw Ethernet? What are the
disadvantages?
** STRICTLY WEARING MY USRP1/USRP2
USER/CUSTOMER HAT HERE **
From my point of view, as a *user* of Ettus hardware with Gnu Radio,
UHD provides a more uniform abstraction layer for various physical
devices that fit in the Analog-goop+{ADC,DAC}+FPGA+data-pump
category. It's nice not having your application need to know
too much about the devices it'll be connected to. Prior to UHD,
there was no convenient way to do that (not that there was *no* way,
just no *convenient* way). Plus UHD is more platform-neutral than
what went before. It will allow Ettus (and anyone else who licenses
UHD technology, I guess) devices to be used in a broader eco-system
of SDR technology, and that's never a bad thing.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] waterfall question
On 11/16/2010 07:16 PM, Michael Civ wrote: Hello All, I began coding my own waterfall for a program using the Python specgram function, but noticed that gnuradio has some python files with waterfall in the title. I cannot figure out what exactly I need to do to include a gnuradio waterfall gui block in my program. Yes, I am a gnuub. It seems like I need to have from gnuradio.wxgui import waterfallsink_gl or something similar. What function or object should I use in my python program? Any help or comments are greatly appreciated. Thanks, Mike There's a Waterfall Sink object. Available through GRC (gnuradio-companion), and presumably instantiated in plain Python as well. I tend not to use plain Python these days, since GRC does most of what one needs, and one can write ancillary Python/C++ code to handle the things it doesn't contemplate. But if you're clever using GRC, you can do just about anything with it, I've found. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus Research Announcements -- Nov 2010
On 11/16/2010 05:20 PM, Steve Mcmahon wrote: Hello Matt: Sorry, one more question. Will the USRP N210 still support the raw Ethernet interface to the host (like for the USRP2), or will it only support the new UHD interface? We have no intention of supporting the raw ethernet interface on there. If someone wanted to port it over from the USRP2 it is certainly possible, but not worthwhile. Secondly, what is performance penalty of UHD interface versus the raw Ethernet interface? UHD is based on UDP, so certainly there must be some reduction in the maximum data rate (and thus the bandwidth) compared the raw Ethernet interface. UDP certainly adds overhead... UDP/IP only add a very small amount of overhead since we are using 1500 byte packets. Our max sample rate is 25 MS/s at 16 bits I, 16 bits Q. That gives us 800mbps, which is enough under the 1 Gbps capability that there is plenty of room for the overhead. Finally, if the USRP N210 only supports the new UHD interface, what is the reason that the current raw Ethernet interface is being deprecated in favor of UHD? What are the advantages of UHD compared to raw Ethernet? What are the disadvantages? That is really 2 separate questions: The first is raw ethernet vs. UDP/IP. UDP/IP allows packets to pass through routers. Raw ethernet requires root access on Linux, and is extremely tough to get at on Windows. UDP/IP plays nicer with the rest of the network stack. The 2nd question is UHD vs. the drivers we had before. UHD consolidates all the control of the hardware in one place, so everybody doesn't have to reinvent those wheels. It allows you to switch between all of our motherboards and daughterboards (past, present, and future) transparently to the application writer and user. UHD gives a much better interface for timed transmission and reception, and other advanced features that just weren't available otherwise. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bandwidths 400Khz no longer work with USRP2
On 11/14/2010 02:28 PM, Marcus D. Leech wrote: I did a git pull for both UHD GnuRadio yesterday. I'm on the next branch for gnuradio, and on master for UHD. Since doing a rebuild yesterday, bandwidths below 400KHz no longer work on the USRP2. I did a test with a dead-simple flowgraph: UHD single source--multi-const x 32767--FFT For bandwidths= 400KHz, the resulting FFT, with my existing RF front-end with 40dB gain feeding the BASIC_RX on my USRP2, the FFT looks just fine (showing a level around -40dB). But anything below 400KHz bandwidth (I tried various bandwidths between 200KHz and 400KHz), produces an FFT with nothing useful in it, and a level around -400dB. This used to work just fine below 400KHz. What happened? So, nobody has answered my question yet. Even with the latest and freshest UHD (master) and GnuRadio (next), Rx bandwidths below 400KHz don't appear to work correctly on a USRP2 with UHD, giving a flat-line at -410dB in the FFT display. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] question about import a new block in gnuradio-3.3.0
hi all:
I use the command create-gnuradio-out-of-tree-project to bulid a new
block,and after that I use the following command:
./bootstrap
./configure
make
make check
sudo make install
Then I thought I had installed the new block.then I want to import the new
block in the python to make sure it is successfully installed.Then I got this:
tianxia...@ubuntu:~/gnuradio-3.3.0/test_example$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
import test_example
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.6/dist-packages/test_example/__init__.py, line
40, in module
from test_example_swig import *
File
/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py,
line 24, in module
_test_example_swig = swig_import_helper()
File
/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py,
line 20, in swig_import_helper
_mod = imp.load_module('_test_example_swig', fp, pathname, description)
ImportError: libgnuradio-test_example.so.0: cannot open shared object file: No
such file or directory
My python is not very well,so I hope someone can help me figure it out.
Thank you in advance. ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bandwidths 400Khz no longer work with USRP2
On Tue, Nov 16, 2010 at 6:13 PM, Marcus D. Leech mle...@ripnet.com wrote: On 11/14/2010 02:28 PM, Marcus D. Leech wrote: I did a git pull for both UHD GnuRadio yesterday. I'm on the next branch for gnuradio, and on master for UHD. Since doing a rebuild yesterday, bandwidths below 400KHz no longer work on the USRP2. I did a test with a dead-simple flowgraph: UHD single source--multi-const x 32767--FFT For bandwidths= 400KHz, the resulting FFT, with my existing RF front-end with 40dB gain feeding the BASIC_RX on my USRP2, the FFT looks just fine (showing a level around -40dB). But anything below 400KHz bandwidth (I tried various bandwidths between 200KHz and 400KHz), produces an FFT with nothing useful in it, and a level around -400dB. This used to work just fine below 400KHz. What happened? So, nobody has answered my question yet. Even with the latest and freshest UHD (master) and GnuRadio (next), Rx bandwidths below 400KHz don't appear to work correctly on a USRP2 with UHD, giving a flat-line at -410dB in the FFT display. No answer or insight, just another data point. I've been running UHD apps today at 200 KHz sample rates with not problem. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bandwidths 400Khz no longer work with USRP2
On 11/16/2010 11:34 PM, Tom Rondeau wrote: On Tue, Nov 16, 2010 at 6:13 PM, Marcus D. Leech mle...@ripnet.com wrote: No answer or insight, just another data point. I've been running UHD apps today at 200 KHz sample rates with not problem. Tom Hmm, that *is* interesting. What daugthercard? What firmware? And you're running latest GnuRadio and UHD? I haven't run my hardware under 400KHz for several weeks, and then a coupla days ago, after updating UHD and GnuRadio, it starts showing the -410dB behaviour. Even in a simple, simple flow-graph. But anything = 400Khz, and it's fine and dandy again. -- 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] question about import a new block in gnuradio-3.3.0
On Wed, Nov 17, 2010 at 10:48:11AM +0800, intermilan wrote:
hi all:
I use the command create-gnuradio-out-of-tree-project to bulid a new
block,and after that I use the following command:
./bootstrap
./configure
make
make check
sudo make install
Then I thought I had installed the new block.then I want to import the
new block in the python to make sure it is successfully installed.Then I got
this:
tianxia...@ubuntu:~/gnuradio-3.3.0/test_example$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more information.
import test_example
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib/python2.6/dist-packages/test_example/__init__.py,
line 40, in module
from test_example_swig import *
File
/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py,
line 24, in module
_test_example_swig = swig_import_helper()
File
/usr/local/lib/python2.6/dist-packages/test_example/test_example_swig.py,
line 20, in swig_import_helper
_mod = imp.load_module('_test_example_swig', fp, pathname, description)
ImportError: libgnuradio-test_example.so.0: cannot open shared object file:
No such file or directory
My python is not very well,so I hope someone can help me figure it out.
Thank you in advance.
Assuming you've got /usr/local/lib in /etc/ld.so.conf...
$ sudo ldconfig
Or
$ export LD_LIBRARY_PATH=/usr/local/lib
BTW, it's always helpful to tell us what OS and distribution you're using...
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] surprising behavior of atsc_field_sync_demux
I am seeing a surprising behavior with atsc_field_sync_demux: every time i run it i get slightly different results (in terms of output file sizes/values). I have uploaded two testfiles here (they are the two equalizer output streams): http://www.eecs.umich.edu/~anastas/gnuradio/atsc_4eq0 http://www.eecs.umich.edu/~anastas/gnuradio/atsc_4eq1 and the python test script: http://www.eecs.umich.edu/~anastas/gnuradio/eq-fsd.py I would appreciate if someone can verify this behavior. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] md5sum error on Ettus website for USRP2 firmware
Hello: Sorry to nit-pick at little details, but I think there is an error on the Ettus website. On the page listed below, in the table Firmware Images, the md5sum d784c4321114a83454493337393c5e2f is listed three times for three different images, dated June 08, 2010. This can't be correct. I downloaded txrx_wbx_raw_eth_20100608.bin to use on my WBX daughterboard, and I get a different md5sum of 769db035df296eca90abab43ceb291c8, which I assume is correct since the image seems to be working. Could someone fix the md5sums listed in the table on the webpage? Thanks a lot!! http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries Steve McMahon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bandwidths 400Khz no longer work with USRP2
On Tue, Nov 16, 2010 at 8:42 PM, Marcus D. Leech mle...@ripnet.com wrote: On 11/16/2010 11:34 PM, Tom Rondeau wrote: On Tue, Nov 16, 2010 at 6:13 PM, Marcus D. Leech mle...@ripnet.com wrote: No answer or insight, just another data point. I've been running UHD apps today at 200 KHz sample rates with not problem. Tom Hmm, that *is* interesting. What daugthercard? What firmware? WBX with latest firmware downloaded from Ettus Monday. And you're running latest GnuRadio and UHD? Working from next and pulled from uhd/master yesterday. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bandwidths 400Khz no longer work with USRP2
On 11/17/2010 02:00 AM, Tom Rondeau wrote: WBX with latest firmware downloaded from Ettus Monday. Hmmm, I'm using Basic_Rx. That should make *zero* difference. I discovered that there's a magic break at any sample rate that requires a decimation 256. So *somewhere* is having a hard time with greater-than-eight-bit integers. -- 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] bandwidths 400Khz no longer work with USRP2
On 11/17/2010 02:00 AM, Tom Rondeau wrote: WBX with latest firmware downloaded from Ettus Monday. That's the 20100901 firmware or something more recent? And you're running latest GnuRadio and UHD? Working from next and pulled from uhd/master yesterday. Tom -- 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] bandwidths 400Khz no longer work with USRP2
On 11/16/2010 11:13 PM, Marcus D. Leech wrote: On 11/17/2010 02:00 AM, Tom Rondeau wrote: WBX with latest firmware downloaded from Ettus Monday. Hmmm, I'm using Basic_Rx. That should make *zero* difference. I discovered that there's a magic break at any sample rate that requires a decimation256. So *somewhere* is having a hard time with greater-than-eight-bit integers. Decimation is filtering. When you decimate by 512 you are reducing noise by a factor of 512 (27dB). Since you are using a BasicRX, there will be very little noise, and 27dB less after decimation. In fact, there is so little noise that the output of the filters is a constant 0 once it is rounded to 16 bit ints. That is why the FFT results essentially show negative infinity. The solution is to decimate less in hardware and more in software, or to use more amplification. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bandwidths 400Khz no longer work with USRP2
On Tue, Nov 16, 2010 at 11:15 PM, Marcus D. Leech mle...@ripnet.com wrote: On 11/17/2010 02:00 AM, Tom Rondeau wrote: WBX with latest firmware downloaded from Ettus Monday. That's the 20100901 firmware or something more recent? Yes, that's the firmware date I'm using (firmware and FPGA). Tom And you're running latest GnuRadio and UHD? Working from next and pulled from uhd/master yesterday. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem in designing Coded OFDM Rxr (using, trellis-viterbi )
Hi Achilleas Anastasopoulos, Thanks for the reply and clarification on trellis metric computation. I tried your idea to connect the ofdm demod block to trellis metric (to perform both hamming and euclidean distance metrics;as the soft or hard decision decoding can be performed on output ofdm symbols.)and connect it to viterbi ,but it was unsuccessful. So,*I'm suspicious about * *the approach of implementation and integrity of packet.* For Transmission : I have achieved the transmitter blocks by passing the packet (containing header,payload and CRC) into a message queue that counts the incoming items, when reached certain limit passes the message to a trellis encoder that is bypassed from a unpack to pack module(for proper input stream to the encoder).The output of trellis encoder is packed into a message and passed through the ofdm_mod block. *Flow Graph Model * *packets from message source pack to unpack--trellis encoder unpack to pack---stream to vector -packets to a message sink ofdm_mod(packets from message sink) --- ampl usrp.* Suppose my uncoded packet size is of 256 bytes and if my coding rate is 1/2, then the output packet size of trellis encoder should be 512 bytes. Questions ?? 1. * I doubt in losing packet modularity in my approach for packing byte stream of coded data back into a packet??? * *2. Also, i used a trellis step size for decoder as K=256 * 8(packet size in bits) /1 (bits per symbol).* *Is it correct ??* *3. The removal of header and packing back (payload and CRC) that is usually done in ofdm_frame sink should be performed after the viterbi decoding.How can I achieve it ??* For question 3.I added a access code to my packet, so at the receiver the output of viterbi is provided to a access_ correlator block and then to a framer_sink_1 block(similar to the benchmark_tx,py and benchmark_rx.py implementation).Is it correct ?? Hope you respond to the email.Thanks for the help. On Fri, Nov 12, 2010 at 1:23 PM, Achilleas Anastasopoulos anas...@umich.edu wrote: = *Problem:* The channel decoding should be performed on the output of ofdm_demod block(ofdm_frame_sink ; the last block that produces demodulated OFDM symbols). But, the combined_ viterbi block performs the demodulation of BPSK or QPSK based on the signal constellation and provides appropriate metrics to viterbi_algorithm. == This is NOT true. The Viterbi block (combined or not) can work with a number of different metrics (eg, symbol wise Hamming distance!) So you can implement your approach with this block as well. In fact this kind of modularity was the MAIN design feature of the gr-trellis! Of course, this does not mean that your approach is not going to work; indeed you are trying to perform soft-input decoding which is better. let me know if you have further problems with that, Achilleas -- Venkat Vinod Patcha Tel: +1 225 328 7356 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bandwidths 400Khz no longer work with USRP2
On 11/17/2010 02:20 AM, Matt Ettus wrote: Decimation is filtering. When you decimate by 512 you are reducing noise by a factor of 512 (27dB). Since you are using a BasicRX, there will be very little noise, and 27dB less after decimation. In fact, there is so little noise that the output of the filters is a constant 0 once it is rounded to 16 bit ints. That is why the FFT results essentially show negative infinity. Well, OK, I'll buy that. But there's a significant change below decimation=256. A non-linear jump from reasonable-looking data to negative infinity. I'm seeing a jump from a level of around -20dB to negative infinity by changing decimation from 256 to 260, which is a noise bandwidth change of something like 0.04dB. So while I'm totally willing to believe that a gross change from 400KHz to 200KHz might cause a bit of weirdness, it seems highly counter-intuitive that a small change as implied by decimation=256 to decimation=260 would cause a huge nonlinear leap in filter output in the decimator. -- 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] Gnuradio package description
Hi! Could anyone please describe what are these packages for: gr-gpio gr-trellis gr-utils gcell gr-gcell gr-msdd6000 gr-atsc gr-comedi gr-noaa -- View this message in context: http://old.nabble.com/Gnuradio-package-description-tp30235916p30235916.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
