Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Don W, thank you very much, I uninstalled the old one and installed the new one version 1.0, but unfortunatelly it doesn't change anything. I can see in DeviceManager the libusb (WinUSB) devices -> Ettus Research LLC USRP1 (VID=FFFE; PID=0002; REV=0004). If I run uhd_find_devices.exe the result is the same as before, no error, from ...\UHD\bin>uhd_find_devices.exe comes back to ...\UHD\bin>, so it's a situation of everything is installed but nothing works. Anyway thank you very much for the information. Have a nice day. Best regards, Mark. From: Don Ward To: Mark Colin Cc: discuss-gnuradio@gnu.org Sent: Thu, April 14, 2011 3:56:45 PM Subject: Re: [Discuss-gnuradio] Gnuradio and Uhd on windows, Mark Colin wrote: > When I power up the USRP1 it shows in the DeviceManager the LibUSB-Win32 Devices -> USRP filter (VID=FFFE; PID=0004 Isn't LibUSB-Win32 the old libusb 0.1 driver? What happens if you uninstall the driver in the device manager and reinstall with the libusb 1.0 driver? -- Don W.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Josh,
> Just to verify things, I decided to try this out on an old XP laptop. I
>installed uhd and set my UHD_IMAGE_PATH, updated the driver to the
>WinUSB. The probe and find devices worked just fine.
>I recommend you try a different computer, a different usb cable, or a
>different os. Just to eliminate the variables. You only need to install
>uhd to test this.
I tried it on a different PC I installed UHD, when I wanted to try the
uhd_find_devices.exe (previously I set the UHD_IMAGE_PATH in the SYSTEM
VARIABLES not USER VARIABLES as Markus mentioned in one of his posts) it told
me
that can't find MSVCP100.dll, after I downloaded the MSVCP100.dll it asked for
MSVCR100.dll, after that it started with some error saying that it wasn't able
to locate an entry point into MSVCR100.dll. So, unfortunatelly it's not working.
I tried to check if gnuradio is OK, yes I have the most recent installer. I
have tested python.exe -c "from gnuradio import gr" and python.exe -c "from
gnuradio import uhd". It can't find the path to the DLL file (like the problem
of Ryan van den Bergh in one of these posts) even if I changed theyr path from
User Variables Path to System Variables Path.
d:\Docs\Code\Python27>python.exe -c "from gnurad
io import gr"
Traceback (most recent call last):
File "", line 1, in
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\__init__.py", line 43, in
from gnuradio_core import *
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\gnuradio_core.py", line 23, in
from gnuradio_core_runtime import *
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\gnuradio_core_runtime.py", line 25, in
_gnuradio_core_runtime = swig_import_helper()
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\gr\gnuradio_core_runtime.py", line 21, in swig_import_helper
_mod = imp.load_module('_gnuradio_core_runtime', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
d:\Docs\Code\Python27>python.exe -c "from gnurad
io import uhd"
Traceback (most recent call last):
File "", line 1, in
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\__init__.py", line 87, in
_prepare_uhd_swig()
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\__init__.py", line 26, in _prepare_uhd_swig
import uhd_swig
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\uhd_swig.py", line 24, in
_uhd_swig = swig_import_helper()
File "d:\Docs\Code\gnuradio\lib\site-packages\
gnuradio\uhd\uhd_swig.py", line 20, in swig_import_helper
_mod = imp.load_module('_uhd_swig', fp, pathname, description)
ImportError: DLL load failed: The specified module could not be found.
I checked files with Dependency walker and it reports that can't find file. To
tell you the truth I don't know why it can't find DLL files, I'm making
softwares for more than 5 years but only once or twice happend to have some
problems with paths, anyway that's not a good practice to use hardcoded things
into the application, maybe this is why it can't find the DLL files.
Thanks you very much Josh.
Best regards,
Mark.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio and Uhd on windows,
Hi Josh, excuse me, right now I checked your website and read about MSVC redistributable package from microsoft and the recomandation to install it to c:\program files (x86). I will check if it's working with these changes. Thanks, Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error when using UHD, GRC
Hi, I installed latest UHD (on a WinXP SP3 OS) but when I'm trying to run the uhd_find_devices.exe I receive this error: C:\program files (x86)\uhd\bin>uhd_find_devices Win32; Microsoft Visual C++ version 10.0; Boost_104400; UHD_003.000.001-release Device discovery error: An existing connection was forcibly closed by the remote host -- -- UHD Device 0 -- Device Address: type: usrp1 name: serial: 4bd1fd09 when I try the uhd_usrp_probe.exe I receive the following error message: C:\program files (x86)\uhd\bin>uhd_usrp_probe Win32; Microsoft Visual C++ version 10.0; Boost_104400; UHD_003.000.001-release Error: An existing connection was forcibly closed by the remote host Could anybody explain me why I'm getting this error? I would like to ask a second question, maybe I don't understand it well. I installed UHD, GNURadio latest versions, Python and many dependencies, but when I'm trying to make a simple flowgraph in Gnuradio companion (a Signal source connected to a NULL sink) it says that I don't have installed grc_wxgui, the error is: Traceback (most recent call last): File "D:\TestProjects\Test\top_block.py", line 12, in from grc_gnuradio import wxgui as grc_wxgui ImportError: cannot import name wxgui It means GRC when parsing schematic writes in source code that it requires wxgui, but WXGUI is not ported as I saw on joshknows.com. Could anybody tell me what the problem could be? Thank you very much. Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error when using UHD, GRC
Hi, regarding my previous question I checked GRC and saw that WX GUI or QT GUI can be choosed, for some example I added some sliders for variables from QT GUI Widgets and I received some other error: Traceback (most recent call last): File "D:\TestProjects\Test\dial_tone.py", line 17, in import PyQt4.Qwt5 as Qwt File "D:\Environment\Python27\lib\site-packages\PyQt4\Qwt5\__init__.py", line 32, in from Qwt import * RuntimeError: the PyQt4.QtCore module is version -1 but the PyQt4.Qwt5.Qwt module requires version 0 I tried to find any explanation to this error but no success. Why it requires other version? I installed latest versions from each installer. Thanks, Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error when using UHD, GRC
Hi Josh, I have an USRP1 working on USB therefore it shouldn't give such kind of errors like "Error: An existing connection was forcibly closed by the remote host"? It has nothing to do with firewalls (I'm not opening UDP sockets, it's not a USRP2 or newer device) therefore the big question is why it's not working as intended. It recognized my USRP1, but nothing more. What is the order of finding devices. I suppose it starts to look around for USB devices after that other devices on other interfaces, so when running uhd_usrp_probe it should start to do it's job with USB devices, NO? therefore I should see results from uhd_usrp_probe and after thet this error. I'll have to check the source code for these examples. Thank you very much. Best regards, Mark.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error when using UHD, GRC
Hi, OK, the uhd_find_devices --args="type=usrp1" is working, there's no device discovery error message, but when I tried to run the uhd_usrp_probe --args="type=usrp1" the uhd_usrp_probe broke down giving a nice error message: "uhd_usrp_probe.exe has encountered a problem and needs to close. We are sorry for the inconvenience." If I disconnect from the Internet (I have internet connection on PPPOE) then I don't get any error when running uhd_find_devices.exe instead when I run uhd_usrp_probe.exe I get the mentioned error. I even tried to disable Local Area Network, and VirtualBox Network, but the error is there. I tried many packet sniffer (TCP, UDP) programs but there's no data transfer (I couldn't find any packet sent by UHD) when running uhd_usrp_probe --args="type=usrp1" therefore it might be some error in the test program uhd_usrp_probe before sending out any packet. What could be the problem? Thank, Best Regards, Mark. From: Josh Blum To: Mark Colin Cc: Discuss-gnuradio@gnu.org Sent: Wed, April 27, 2011 3:13:39 AM Subject: Re: Error when using UHD, GRC On 04/26/2011 04:59 PM, Mark Colin wrote: > Hi Josh, > >I have an USRP1 working on USB therefore it shouldn't give such kind of > errors like "Error: An existing connection was forcibly closed by the remote > host"? > Sorry, I missed that it was a USB based USRP. Even though its USB, the discovery logic still tries to send out broadcast packets to your network interfaces. (I am assuming that this error is a network issue.) I think if you add these arguments, the discovery logic wont attempt to search the network. uhd_find_devices --args="type=usrp1" uhd_usrp_probe --args="type=usrp1" It still might be worth it to fix the issue. Maybe disable a few extra network interfaces (or virtual ones like VPN). I have no idea, so I am curious as to what might cause this. -josh I assume you did do this: http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Windows-USB-driver ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error when using UHD, GRC
Hi Josh, thanks for your answer. Anyway if the UHD makes trouble because of the USRP2 than I decided to build my own UHD.dll from source code with MSVC 2008. I set in CMake environment that I don't want to include USRP2 stuff into the UHD driver (it won't look for USRP2 devices only for USRP1 devices on USB). I installed BOOST. I compiled the UHD, I got the DLL and utils files (uhd_usrp_probe and uhd_find_devices), I copied the DLL to location C:\program files (x86)\uhd\bin and the LIB file to location C:\program files (x86)\uhd\lib (both from D:\uhd\host\build\lib\Release\) but it's not working, so the problem is due to paths. I downloaded UHD source code to D:\uhd. Maybe I set wrong some parameters in CMake. Do you have any idea regarding this? Thanks, Mark. From: Josh Blum To: Mark Colin Cc: Discuss-gnuradio@gnu.org Sent: Thu, April 28, 2011 9:05:44 AM Subject: Re: Error when using UHD, GRC On 04/27/2011 02:34 PM, Mark Colin wrote: > Hi, > > OK, the uhd_find_devices --args="type=usrp1" is working, there's no >device > > discovery error message, but when I tried to run the uhd_usrp_probe > --args="type=usrp1" the uhd_usrp_probe broke down giving a nice error message: > > "uhd_usrp_probe.exe has encountered a problem and needs to close. We are > sorry > > for the inconvenience." > The last time I saw this, was when I learned that the libusb callbacks needed to be defined w/ a different calling convention. If you got UHD from this installer then I don't know the problem: http://www.ettus.com/downloads/uhd_releases/003_000_001/UHD-003.000.001-win32-with-LIBUSB_CALL-fix.exe > If I disconnect from the Internet (I have internet connection on PPPOE) then > I > don't get any error when running uhd_find_devices.exe instead when I > run uhd_usrp_probe.exe I get the mentioned error. I even tried to disable > Local > > Area Network, and VirtualBox Network, but the error is there. > If I read your message right, then it seems that the interaction between PPPOE and UHD may be the culprit. But it wasnt consistent between find and probe? but I would expect them to behave identically. > I tried many packet sniffer (TCP, UDP) programs but there's no data transfer > (I > > couldn't find any packet sent by UHD) when running uhd_usrp_probe > --args="type=usrp1" therefore it might be some error in the test > program uhd_usrp_probe before sending out any packet. > It may be the act of opening up a socket on that interface for broadcast. > > What could be the problem? > Windows is that nosey neighbor who always manages to get into your house at those awkward moments; even though you know you locked the door. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] benchmark OFDM Question
Hi everyone,
I am working on OFDM in gnuradio. I ran the benchmark_ofdm.py file.
Everything worked well, I want to ask one thing that I didn't see the last
packet on the terminal.
I set the packet size to 400 bytes and total number of bytes to be
transmitted to 1600. I should see 4 packets but i see only 3 packets. Where
is the problem??
Portion of the code is given blelow:
nbytes = int(1600 * 1) //line that I changed
n = 0
pktno = 0
pkt_size = int(400) //line that I changed
while n < nbytes:
pkt_contents = struct.pack('!H', pktno) + (pkt_size - 2) * chr(pktno & 0xff)
send_pkt(pkt_contents)
n += pkt_size
pktno += 1
-
Output is shown below:
>>> gr_fir_ccf: using SSE
>>> gr_fir_ccc: using SSE
>>> gr_fir_fff: using SSE
ok: True pktno: 0 n_rcvd: 1 n_right: 1
ok: True pktno: 1 n_rcvd: 2 n_right: 2
0101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
ok: True pktno: 2 n_rcvd: 3 n_right: 3
0202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202
Why fourth packet is not sent ? Or if it is sent then why it is not
displayed in the output. I am using gnuradio 3.3.0. Please help me in this.
Regards
Smith
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] trellis help please
Hi everyone, I want to implement convolutional coding using the trellis block. I don't want to use any modulation scheme or anything else after the encoder. The flow graph I want is shown below vector source>trellis encoder> viterbi or any decoder--->sink Part of the code is shown below src_d = (1,0,1,0,0,0,1,1,0,0,1) sorc = gr.vector_source_b (src_d) //source encoder = trellis.encoder_bs(f,0)//encoder s2f= gr.short_to_float() dec=trellis.viterbi_s(f,len(src_d),0,-1) //decoder dst = gr.vector_sink_s () //sink tb.connect (sorc,encoder,s2f,dec,dst) return(dst.data()) When I run the above flow graph I get nothing just empty, ( ), list. I am using "awgn1o2_4.fsm" file. I got the correct result after encoder. I can't use the trellis.metric or trellis.viterbi_combined_X to implement decoder as I am not using any modulation :( . Can anybody please help me in this ?? Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Please Help in trellis gnuradio
Hi Thanks Achilleas, after doing this I got the desired result. One more question please What if I want to simulate a noisy channel? If my flow graph is like the one shown below: vector source>trellis encoder> channel noise>viterbi or any decoder--->sink Do I have to make any further changes or the previous solution 'll work? Thanks again, Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Muliple top_block()
Hi all, I wanted to know that whether one can have multiple gr.top_block() or not? for example tb1=gr.top_block() tb2=gr.top_block() tb1.run() tb2.run() and have them running at the same time. Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Missing gr_plot_ofdm.py
Hi all I want to plot the .dat files that are created by the benchmark_ofdm code. But I didn't find the "gr_plot_ofdm.py" file anywhere in the my gnuradio directory. I am using gnuradio 3.3.0. I did find the "plot_ofdm.m" file but I want to use python only. I downloaded gnuradio3.2.2 but didn't find the file there too. Please tell me from where I can download this file.. Regards Usman Haider ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Muliple top_block()
Hi Thanks for the reply. I used tb1.start() and tb2.run() and I think that is working. The two blocks don't have connections with each other. The flow is like: tb1=gr.top_block() 1. tb1.start() 2. Some variable declaration... Repeat step 3 and 4, five times 3. A function that creates tb2 and runs it and return the result --- tb2=gr.top_block() --- vector source--->convolution coding->destination --- tb2.run() --- return destination.data() 4. send the result to the tb1 for processing 5 . tb1.wait() As far as the result is concerned it seems right. But, I want to know that whether this type of thing is conceptually right or not ?? I read that there must be only one top_block(). Please guide me in this.. Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Missing gr_plot_ofdm.py
Thanks :) On Tue, Jun 21, 2011 at 3:21 AM, John Andrews wrote: > > http://vps.gnuradio.org/redmine/repositories/entry/gnuradio/gnuradio-examples/python/ofdm/gr_plot_ofdm.py?rev=ab6cf111c1d00b22d9016524b31cfcc6b09ffdc7 > > On Mon, Jun 20, 2011 at 1:21 PM, smith mark wrote: > >> Hi all >> I want to plot the .dat files that are created by the benchmark_ofdm code. >> But I didn't find the "gr_plot_ofdm.py" >> file anywhere in the my gnuradio directory. I am using gnuradio 3.3.0. I >> did find the "plot_ofdm.m" file but I want to >> use python only. I downloaded gnuradio3.2.2 but didn't find the file there >> too. >> >> Please tell me from where I can download this file.. >> >> Regards >> Usman Haider >> >> ___ >> 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] Muliple top_block()
Thank you very much all for such clear explanation of things. Actually I want to implement the coded OFDM. And was trying to figure out how can I run the trellis-encoder and OFDM flow graphs together. Your posts did help me a lot :). Smith On Tue, Jun 21, 2011 at 1:45 AM, Johnathan Corgan < jcor...@corganenterprises.com> wrote: > On Mon, Jun 20, 2011 at 11:03, smith mark wrote: > > >> As far as the result is concerned it seems right. But, I want to know that >> whether this type of thing is conceptually right or not ?? >> > > It is functionally correct, as you noted, but using GNU Radio this way is > not very common except perhaps in automated QA code. > > Typically, flowgraphs run continuously, with data being injected into the > graph via one or more sources and being removed via one or more sinks, and > don't get started and stopped or re-run except in response to some > application level event (like startup and shutdown, or for flowgraph > reconfiguration). > > I think your use case would be better served by connecting your two > flowgraphs using a message sink and a message source that share a common > message queue, or even merging the two together, but it is hard to say > without more information about what you are trying to accomplish. > > >> I read that there must be only one top_block(). Please guide me in this.. >> > > Having more than one top block is fine since release series 3.3, but > requires more attention to detail as you have to use the > start()/stop()/wait() sequence on each instead of the simpler run(). > > Johnathan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Python code error on Windows
(default=first one with
a
daughterboard)")
parser.add_option ("-c", "--cordic-freq", type="eng_float",
default=434845200,
help="set Tx cordic frequency to FREQ", metavar="FREQ")
parser.add_option ("-r", "--data-rate", type="eng_float", default=38400)
parser.add_option ("-f", "--filename", type="string",
default="rx.dat", help="write data to FILENAME")
parser.add_option ("-g", "--gain", type="eng_float", default=0,
help="set Rx PGA gain in dB [0,20]")
parser.add_option ("-N", "--no-gui", action="store_true", default=False)
(options, args) = parser.parse_args ()
print "cordic_freq = %s" % (eng_notation.num_to_str(options.cordic_freq))
tb = transmit_path(options)
tb.start()
for i in range(100):
print "send message %d:"%(i+1,)
tb.send_pkt(payload=struct.pack('9B', 0x1, 0x80, 0x80, 0xff, 0xff, 0x10,
0x0, 0x20, 0x0))
time.sleep(0.1)
if __name__ == '__main__':
main ()
Maybe I should learn more python, anyway I will use it only to learn how all
these stuff works. Anyway I feel I'm close to make it work (maybe I'm wrong - I
know it's one thing to make something and than another thing to debug it and
make it work). Could anybody help me with some ideas, what to do, what's wrong.
One test file didn't report any error uhd_cc2420_txtest.py, and I can't figure
out why this code has this error.
Thank you very much.
Mark.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Open Sound Control block for GRC?
Hello all, I'm in the process of putting together an SSB/CW receiver using GNU Radio + a USRP1, and just came across the GNU Radio Companion, which is a truly wonderful thing… One thing that seems to be missing from the Companion is the ability to easily interface with other software or to control it from another networked machine / device, so the Open Sound Control (OSC) protocol seems like a no-brainer… OSC uses UDP packets formatted like URL strings (e.g. /filter/width 500) to communicate between software locally or over a network: http://opensoundcontrol.org/spec-1_0 It sports some handy features such as pattern-matching & time tags, and has been implemented in a number of programming languages and development environments as well as numerous commercial software applications, (including Python, Ruby, PHP, Java, Processing, OpenFrameworks, Cinder, SuperCollider, PD, Max/MSP, Reaktor…) on most platforms you can think of: http://opensoundcontrol.org/implementations Given that OSC has been implemented in Python already, starting from Simple OSC: http://www.ixi-audio.net/content/body_backyard_python.html or pyOSC: https://trac.v2.nl/wiki/pyOSC should make this a straightforward enough process, but not having written a GRC block before, I'm wondering if anyone might have pointers on where to begin, or might be interested in a quick port. Warm regards, Mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CATV on USRP ??
Hi all, I want to know that if there is any possibility of having CATV on USRP ? If yes please guide me. Regards Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] floats over UDP into GRC?
Hi all, I would like to stream floating point numbers from another application into GRC; currently sending them over UDP as char arrays, which I was hoping to convert back into floats in GRC. Seems like kind of a basic thing, but I can't get my head around how this is possible. Any pointers / advice would be greatly appreciated… Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] floats over UDP into GRC?
I'm producing the stream in C++ (using openFrameworks) and sending the data as
char arrays,
and have confirmed that this is indeed all that is being sent (e.g. "1.25")…
I think what I'm missing is how to unpack them from the char arrays in GRC,
tried various conversions, ("Packed to Unpacked," "Char to Float," etc.)
but am just not getting my head around how GRC would handle this…
Cheers,
Mark
--
mark.cetilia.org | mem1.com | reduxproject.com
On Sep 13, 2011, at 7:21 PM, Marcus D. Leech wrote:
> On 09/13/2011 07:05 PM, Mark Cetilia wrote:
>> Hi all,
>> I would like to stream floating point numbers from another application into
>> GRC;
>> currently sending them over UDP as char arrays, which I was hoping to
>> convert back into floats in GRC.
>>
>> Seems like kind of a basic thing, but I can't get my head around how this is
>> possible.
>> Any pointers / advice would be greatly appreciated…
>>
>> Cheers,
>> Mark
>>
>>
> How are you producing the UDP stream? ARe you saying that in your
> "producer" you don't know how to pack complex-floats into
> a UDP buffer, or something else?
>
> The UDP source in GRC is perfectly happy to unpack complex-floats (or floats,
> or whatever) from a UDP-based stream.
>
>
>
>
> --
> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] floats over UDP into GRC?
Thanks so much Marcus, this makes perfect sense… Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Sep 13, 2011, at 7:45 PM, Marcus D. Leech wrote: >> I'm producing the stream in C++ (using openFrameworks) and sending the data >> as char arrays, >> and have confirmed that this is indeed all that is being sent (e.g. "1.25")… > So, you're sending them in ASCII? As ASCII strings? > > GRC/gnuradio has no method for dealing with that. The UDP block assumes > native machine-binary format for data coming in > over UDP. Doing it in ASCII (Or Unicode, or whatever) strings will be > hugely inefficient, both in terms of bandwidth required-- > it takes many more bytes to represent a floating-point number in ASCII, than > in the native binary format, and converting from > strings back into the native binary format is also quite expensive. Since > UDP is entirely binary transparent, there's no reason > to send them as ascii strings. The only thing you have to watch out for is > if the raw floating-point format between your two > machines is different. But between x86-family machines, it's all the same. > > > > -- > 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] floats over UDP into GRC?
Ok so I have made some headway & am now sending floats over UDP as binary data (4 bytes), followed by a null packet (1 byte of "\0") but am not sure how to unpack the data into a float in GRC… It's all happening within the same machine on an Intel Mac so there shouldn't be any issues with endianness. Any ideas / suggestions? Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Sep 13, 2011, at 8:24 PM, Mark Cetilia wrote: > Thanks so much Marcus, this makes perfect sense… > > Cheers, > Mark > > -- > mark.cetilia.org | mem1.com | reduxproject.com > > On Sep 13, 2011, at 7:45 PM, Marcus D. Leech wrote: > >>> I'm producing the stream in C++ (using openFrameworks) and sending the data >>> as char arrays, >>> and have confirmed that this is indeed all that is being sent (e.g. "1.25")… >> So, you're sending them in ASCII? As ASCII strings? >> >> GRC/gnuradio has no method for dealing with that. The UDP block assumes >> native machine-binary format for data coming in >> over UDP. Doing it in ASCII (Or Unicode, or whatever) strings will be >> hugely inefficient, both in terms of bandwidth required-- >> it takes many more bytes to represent a floating-point number in ASCII, than >> in the native binary format, and converting from >> strings back into the native binary format is also quite expensive. Since >> UDP is entirely binary transparent, there's no reason >> to send them as ascii strings. The only thing you have to watch out for is >> if the raw floating-point format between your two >> machines is different. But between x86-family machines, it's all the same. >> >> >> >> -- >> 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Cheap portable antenna for SSB + CW w/ USRP1?
Hi all, Just curious if anyone might have some suggestions for a cheap (ideally < $100) portable antenna for receiving (not transmitting) SSB + CW? Something that can easily fit into a carryon bag, can be used indoors and set up / broken down quickly would be great. It would be nice to cover as much of the LFRX's range as possible—160 to 6 meters I guess? The Ettus site mentions DC to 30 MHz, but the board has DC to 50 MHz silkscreened onto it—not sure which is correct? I've got my eye on an MFJ-1622 right now, which supposedly covers 40 to 2 meters. Not completely optimal, but it's looking decent for the price + form factor… Anybody out there have experience with that antenna? Other possible leads would be greatly appreciated as well. Thanks so much! Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cheap portable antenna for SSB + CW w/ USRP1?
Thanks Marcus, I realize I'm asking for the impossible at a certain level—"adequate but not stellar" should be fine :) Glad to know that the roll-off is not so steep as to make >30MHz / <50MHz unusable as well… Btw, I finally managed to get UDP between my external app and GnuRadio up & running—thanks again for all the help! Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 7, 2011, at 12:03 AM, Marcus D. Leech wrote: > On 06/10/11 11:51 PM, Mark Cetilia wrote: >> Hi all, >> Just curious if anyone might have some suggestions for a cheap (ideally < >> $100) portable antenna for receiving (not transmitting) SSB + CW? >> Something that can easily fit into a carryon bag, can be used indoors and >> set up / broken down quickly would be great. >> >> It would be nice to cover as much of the LFRX's range as possible—160 to 6 >> meters I guess? >> The Ettus site mentions DC to 30 MHz, but the board has DC to 50 MHz >> silkscreened onto it—not sure which is correct? >> >> > The LFRX has a not-very-steep roll-off above 30MHz, so it's usable above > 30MHz. > >> I've got my eye on an MFJ-1622 right now, which supposedly covers 40 to 2 >> meters. >> Not completely optimal, but it's looking decent for the price + form factor… >> >> Anybody out there have experience with that antenna? >> Other possible leads would be greatly appreciated as well. >> >> Thanks so much! >> >> >> > The MFJ-1622 is probably adequate, but not stellar. Its hard to make an > antenna that is both a good > match, *and* a good radiator over wide frequency radiators, *and* is > physically compact. > > > > > -- > 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Cheap portable antenna for SSB + CW w/ USRP1?
Hi Louis, Thanks for the leads—the mini-loop tuner looks like a great possibility, though it seems like I'd need to swap out for a different size loop each time I want to change bands—1/4 wavelength, they say— but is there maybe some flex room in there? Also confused as to whether it would help to have an active loop for receiving, or if that's just for sending? Apart from having built a square loop antenna for receiving VLFs (from the Calvin R. Graf book), I'm a total newbie when it comes to antennas, so it all seems a bit daunting, as I'm sure you can imagine :) Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 7, 2011, at 10:20 PM, Louis Brown wrote: > > On Oct 7, 2011, at 11:01 AM, discuss-gnuradio-requ...@gnu.org wrote: > >> [Discuss-gnuradio] Cheap portable antenna for SSB + CW w/ >> USRP1? > > Since you are only interested in RX, a loop would probably work well. You > could probably rig up compact, muti-turn wire loop that could be broken down > and folded. A simple passive loop requires a high-Q, variable plate > capacitor you must tune for resonance, so it is inherently narrow band, but > that also gives you rejection. They are lossy too, but HF is dominated by > atmospheric noise so noise figure is not a prime concern. MFJ-952 is a > mini-loop tuner; just add your own wire. There are active loops too. This is > a list: > > http://homepages.tig.com.au/~vk5vka/antnews.htm > > Active loop design: > > http://sivantoledotech.wordpress.com/2010/09/18/a-tuned-active-receiving-loop/ > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fan replacement for usrp1?
wondering if anybody out there has replaced their usrp1 fan with something a bit quieter? i find myself listening to its incessant whine many hours a day, and it's starting to make me a little crazy— especially when i am trying to listen to subtle details… anybody have a suggestion for a decent replacement? cheers, mark -- mark.cetilia.org | mem1.com | reduxproject.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fan replacement for usrp1?
ah yes, i feel it coming back, slowly. thank you :) m -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 9, 2011, at 3:39 AM, Mike Jameson wrote: > Hi Mark, > > If you take off the top of the enclosure on the USRP1 then you don't even > need a fan! > > Your sanity should then return :) > > Mike > M0MIK > > > On 9 October 2011 06:43, Mark Cetilia wrote: > wondering if anybody out there has replaced their usrp1 fan with something a > bit quieter? > i find myself listening to its incessant whine many hours a day, and it's > starting to make me a little crazy— > especially when i am trying to listen to subtle details… anybody have a > suggestion for a decent replacement? > > cheers, > mark > > -- > mark.cetilia.org | mem1.com | reduxproject.com > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fan replacement for usrp1?
ok so this has been working just fine at home, but i am actually beginning to use the usrp in performances fairly regularly, and you never know what might happen in such situations… so just to be on the safe side, i'd really rather replace the fan. unfortunately i'm not having much luck finding the exact fan that came with it in stock anywhere, but i've found a possible replacement that seems to basically meet the specs: http://search.digikey.com/us/en/products/F410T-05LC/563-1130-ND/1165524 the only thing that doesn't match up is the air flow— it's rated at 3.9CFM rather than the cooltron's 4.6CFM. anyone have a clue as to whether or not this would be enough of a difference to cause concern? otherwise the specs look fine, and it's supposed to have a noise floor of 12 dBA instead of ~21, so we're talking roughly half the volume… could really make a difference. thanks in advance, mark p.s. does anyone else have this same issue or is it just me? i'm wondering if maybe it's just that my fan is defective… 20 dBA should be "a whisper" and mine seems to be much louder than that. -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 9, 2011, at 2:04 PM, Mark Cetilia wrote: > ah yes, i feel it coming back, slowly. > thank you :) > > m > > -- > mark.cetilia.org | mem1.com | reduxproject.com > > On Oct 9, 2011, at 3:39 AM, Mike Jameson wrote: > >> Hi Mark, >> >> If you take off the top of the enclosure on the USRP1 then you don't even >> need a fan! >> >> Your sanity should then return :) >> >> Mike >> M0MIK >> >> >> On 9 October 2011 06:43, Mark Cetilia wrote: >> wondering if anybody out there has replaced their usrp1 fan with something a >> bit quieter? >> i find myself listening to its incessant whine many hours a day, and it's >> starting to make me a little crazy— >> especially when i am trying to listen to subtle details… anybody have a >> suggestion for a decent replacement? >> >> cheers, >> mark >> >> -- >> mark.cetilia.org | mem1.com | reduxproject.com >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fan replacement for usrp1?
Ah good, glad to hear it's not just me… Do you run it with the top on or leave it open? Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 18, 2011, at 11:02 PM, Robert McGwier wrote: > Yes I have. I disconnected it. In my opinion, it is overkill for anything > going on in a USRP1. > > YMMV, > Bob > > > On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia wrote: > wondering if anybody out there has replaced their usrp1 fan with something a > bit quieter? > i find myself listening to its incessant whine many hours a day, and it's > starting to make me a little crazy— > especially when i am trying to listen to subtle details… anybody have a > suggestion for a decent replacement? > > cheers, > mark > > -- > mark.cetilia.org | mem1.com | reduxproject.com > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > -- > Bob McGwier > Facebook: N4HYBob > ARS: N4HY > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Warning! Warning!
What does this mean in terms of using older non-UHD-native daughterboards such as the DBSRX & BasicRX? To be honest, I haven't checked into the UHD driver, since the daughterboards I have been working fine without it… Best, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 19, 2011, at 5:58 PM, Tom Rondeau wrote: > We are REMOVING the USRP and USRP2 components from GNU Radio! > > It's been mentioned in the past, but the change on the next branch is > imminent. As of GNU Radio 3.5, we will no longer support libusrp, libusrp2 or > the GNU Radio interfaces, gr-usrp and gr-usrp2. Everything is moving to using > UHD. > > If you have not started to port your code over to using the UHD driver, start > thinking about it now. Follow the changes that were made in 'next' to convert > the old examples that used to use the gr-usrp/usrp2 interfaces to gr-uhd. > > This also reduces the number of dependencies required. Updates on this will > be posted on the wiki when it becomes the stable release. > > Tom > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fan replacement for usrp1?
Thanks Robert, I hadn't ever noticed it getting hot to the touch, but I haven't tried running it w/ no fan & top on either… Best, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 19, 2011, at 10:40 AM, Robert McGwier wrote: > Top on. Fire up the fastest card you have (widest band signal you can > process) and put your finger on the FPGA. It is cool. > > If the oscillator in the USRP1 were most stable and accurate, it might make > some sense but it just doesn't in my opinion make sense so I disconnected > them all in my USRP 1's. > > Bob > > > On Tue, Oct 18, 2011 at 11:39 PM, Mark Cetilia wrote: > Ah good, glad to hear it's not just me… > Do you run it with the top on or leave it open? > > Cheers, > Mark > > -- > mark.cetilia.org | mem1.com | reduxproject.com > > On Oct 18, 2011, at 11:02 PM, Robert McGwier wrote: > >> Yes I have. I disconnected it. In my opinion, it is overkill for anything >> going on in a USRP1. >> >> YMMV, >> Bob >> >> >> On Sun, Oct 9, 2011 at 1:43 AM, Mark Cetilia wrote: >> wondering if anybody out there has replaced their usrp1 fan with something a >> bit quieter? >> i find myself listening to its incessant whine many hours a day, and it's >> starting to make me a little crazy— >> especially when i am trying to listen to subtle details… anybody have a >> suggestion for a decent replacement? >> >> cheers, >> mark >> >> -- >> mark.cetilia.org | mem1.com | reduxproject.com >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> -- >> Bob McGwier >> Facebook: N4HYBob >> ARS: N4HY >> >> > > > > > -- > Bob McGwier > Facebook: N4HYBob > ARS: N4HY > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Warning! Warning!
Great, thanks for the clarification, Marcus (and Tom)… Looking forward to the new developments! Cheers, Mark -- mark.cetilia.org | mem1.com | reduxproject.com On Oct 20, 2011, at 12:01 PM, Marcus D. Leech wrote: > > On 20/10/2011 11:58 AM, Mark Cetilia wrote: >> What does this mean in terms of using older non-UHD-native daughterboards >> such as the DBSRX& BasicRX? >> To be honest, I haven't checked into the UHD driver, since the >> daughterboards I have been working fine without it… >> >> Best, >> Mark >> >> > UHD supports ALL of the previous daughtercards, even ones that are no longer > in production and pre-date UHD. > > > ___ > 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] Gnuradio locking up
On Tue, Nov 22, 2011 at 12:29 PM, Philip Balister wrote: > On 11/21/2011 10:24 PM, Matt Mills wrote: > > Hello all, > > > > I seem to be having an issue that, after about 30-45 minutes of running > > normally my gnuradio based python app will just lock up. It wont respond > to > > control C, it holds all of its existing file handles open but doesnt do > > anything with them, and an strace attach shows only: > > futex(0xb2ff54f4, FUTEX_WAIT_PRIVATE, 1, NULL > > > > I dont really have any experience troubleshooting this type of thing, > could > > anyone provide some guidance on what to look for (in gdb I assume)? > > Memory leak? Run top in another window and watch the memory usage numbers. > > I've seen lockups of this sort when multi-threaded python processes exit. You might also like to take a look at what each thread is up to in gdb. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
Hi, 1) I got my USRP 1 and RFX900 and 1800 daughterboards. The LED on the USRP flashes when its powered on. I wanted to test the USRP but when I ran the follwowing command >> ./usrp_probe or sudo ./usrp_probe I got the following error Traceback (most recent call last): File "./usrp_probe", line 114, in USRPProbeWindow() File "./usrp_probe", line 71, in __init__ vbox.pack_start(get_input(usrp_which_param), False) File "./usrp_probe", line 42, in get_input input = param.get_input() AttributeError: 'Param' object has no attribute 'get_input' I am using gnuradio 3.2 and Ubuntu(Lucid) 2) Also I got N210. How can I test it. Please help. Waiting for a quick response as I am worried. Any help in this regards is highly appreciated. Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP testing plesae help
Hi, 1) I got my USRP 1 and RFX900 and 1800 daughterboards. The LED on the USRP flashes when its powered on. I wanted to test the USRP but when I ran the follwowing command >> ./usrp_probe or sudo ./usrp_probe I got the following error Traceback (most recent call last): File "./usrp_probe", line 114, in USRPProbeWindow() File "./usrp_probe", line 71, in __init__ vbox.pack_start(get_input(usrp_which_param), False) File "./usrp_probe", line 42, in get_input input = param.get_input() AttributeError: 'Param' object has no attribute 'get_input' I am using gnuradio 3.2 and Ubuntu(Lucid) 2) Also I got N210. How can I test it. Please help. Waiting for a quick response as I am worried. Any help in this regards is highly appreciated. Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Subject: Re: USRP testing plesae help
>You may have a version mismatch between the installed python modules in lib and installed python scripts in bin. Either that, or its a very old bug. Whatever the case, I recommend you nuke your gr install(s) and grab a recent release. First of all bundle of thanks. Last post did help me alot. I installed a fresh gnruadio 3.4.0. Connected the USRP1 and usrp_probe ran successfully. Both the boards were detected. :) When I tried to connect DBSRX2 to RXB or RXA the it wasn't detected. I mean when I ran usrp_probe the model shown was 'unkown' and frequency range was from -900.0 to 9.00. Any help what I need to do in order to check the DBSRX2 ? > 2) Also I got N210. How can I test it. Please help. > > Waiting for a quick response as I am worried. Any help in this regards > is highly appreciated. > What do you want to test? If you want connectivity, install UHD and the command uhd_usrp_probe will tell you all the USRP devices connected to your pc: http://code.ettus.com/redmine/ettus/projects/uhd/wiki If you want to test signal integrity, configure gnuradio with gr-uhd support. There is a very basic signal generator and analyzer display that comes with the component. uhd_siggen_gui.py uhd_fft.py I believe. Or make a quick flowgraph in gnuradio-companion :-) == I downloaded UHD from link above, then I did following. cd UHD. cd host mkdir build cd build cmake ../ make make install ldconfig But then when I ran uhd_find_devices I got following output: "Ignoring discovered device RuntimeError: Expected protocol compatibility number 9, but got 7: The firware build is not compatible with the host code build. No UHD Devices Found" Lights D and F are on the N210. No other lights. Another question what is minimum speed required for LAN(Etherenet) interface on PC ? 100Mbps or 1000Mbps ? Regards, Smith ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Subject: Re: USRP testing plesae help
Thanks for the response, I did sudo make and sudo make install when I was installing the UHD. My UHD folder is in my home directory. Sorry, I am not getting you with your last post because I am not very good at Linux. Any help further is highly appreciated. Regards, Smith On Sat, Jan 14, 2012 at 7:12 PM, LRK wrote: > On Sat, Jan 14, 2012 at 05:33:17PM +0500, smith mark wrote: > > > > I downloaded UHD from link above, then I did following. > > cd UHD. > > cd host > > mkdir build > > cd build > > cmake ../ > > make > > make install > > ldconfig > > You can install in userspace but then you need to be sure PYTHONPATH > and maybe LD_LIBRARY_PATH are pointing to your install. Most users > do 'sudo make install' to install in /usr/local. > > ldconfig will not find things in userspace and elf-ld can't figure out > that a program in /something/bin might have libraries in /something/lib. > > After you do cmake, the Makefile should be able to clean out old > stuff with 'make uninstall' and 'make clean' before the new make and > sudo make install. > > > -- > LRK > gr-user . ovillatx.sytes.net > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] tun/tap OS X for tunneling
Has anyone gotten tun/tap running on OS X 10.5 so they can tunnel packets to the USRP? I have the tun/tap driver installed (from http://tuntaposx.sourceforge.net/index.xhtml) and I am already having issues. So I'm wondering if it is even worth using OS X or if I should just start working this in Linux like tunnel.py does by default. The error I'm getting on OS X is: I type "ifconfig /dev/tun0 create" with permissions to create the interface and it says "ifconfig: SIOCIFCREATE: Invalid argument." tun0 is listed in the my /dev, so that's rather confusing. So I'm trying to save some time here. If anyone has any experience with this, any advice would be appreciated. I'm just tying to connect the USRP to some upper layer functionality. Thanks. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: tun/tap OS X for tunneling
Using the provided tuntaposx package (http://tuntaposx.sourceforge.net/index.xhtml
), I finally got the error resolved. I did not have to compile from
the source code. Basically, you just have to open the tap or tun
interface for reading from python first, then you can see the device
using "ifconfig -l" and assign it an address. The kext automatically
creates the device when it is opened for reading.
As for getting it to work with GNU radio, I'm trying to get the
tunnel.py example script to run for testing purposes. Without making
changes to tunnel.py, I am currently receiving the "OError: [Errno 25]
Inappropriate ioctl for device" error on this command:
ifs = ioctl(tun, TUNSETIFF, struct.pack("16sH", "gr%d", mode))
I'm guessing there is a difference in the ioctl implementation between
linux and OS X. I'm working through it and will post any progress.
But if someone can point out what's wrong that would be helpful.
Mark
On Jan 6, 2009, at 8:22 AM, Michael Dickens wrote:
Mark Kuhr wrote:
Has anyone gotten tun/tap running on OS X 10.5 so they can tunnel
packets to the USRP?
tun/tap has been mentioned before on this list, but I know of noone
who's actively using it with GNU Radio on OSX; if anyone is, please
speak up! Hence I'm going to try it out & see what it does. Can
you / someone provide me with a quick example script to test the
functionality of a tun/tap device, with or without GNU Radio?
Please note that the pre-compiled PKG version (not the source which
you would then compile) of tuntaposx is meant as a universal binary
for 10.4 or higher, but not specifically compiled for 10.5. Given
that this is a kext, that might make a difference in correct
functionality (or not).
I've submitted updates to MacPorts to correct the compile behavior
of "tuntaposx" source code, to allow it to compile correctly on, and
specifically for, 10.4 and 10.5 when using MacPorts. I expect those
change to propagate through the system in the next couple of days.
If anyone wants these files (as an archive which can overwrite that
provided by MacPorts) for testing purposes, I'm happy to provide
them. - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: tun/tap OS X for tunneling
I've got a small update on this.
To read the tap devices on OS X, just issue the os.open command.
self.tap_fd = os.open("/dev/tap0", os.O_RDWR)
Once this open is completed, you can setup the interface with
ifconfig. Spawning this off into a subprocess with popen works well
inside the script.
To write to the tap device, just use os.write(self.tap_fd,DATA)
The ioctl command is challenging since it is implemented differently
as previously discussed. The request constant (second argument) used
by the osxtuntap kernel extensions are different from Linux. Two
request constants are used and defined as follows:
#define TUNSIFHEAD _IOW('t', 96, int)
#define TUNGIFHEAD _IOR('t', 97, int)
Translated they become the following:
TUNSIFHEAD = 2147775584
TUNGIFHEAD = 1074033761
So, in tunnel.py, you can modify the ioctl command to be as follows on
os x and it should not crash.
ifs = ioctl(tun, TUNSIFHEAD, struct.pack("16sH", "gr%d", mode))
I think it is possible to create a cross-platform abstraction of this
functionality that manages the differences between the OSs. Maybe a
tun/tap module that is part of gnuradio, however the reliance on
external pieces such as the os x tun tap kernel extensions could be
problematic. Might want to roll that into the code base as well to
maintain some control of the versioning.
On Jan 6, 2009, at 12:00 PM, Eric Blossom wrote:
On Tue, Jan 06, 2009 at 09:52:14AM -0800, Johnathan Corgan wrote:
On Tue, Jan 6, 2009 at 8:59 AM, Ed Criscuolo
wrote:
There also seems to be a fundamental difference between the
way the TUN/TAP driver works on the two OS's.
Ah, then it's not so easy. It would be very useful to GNU Radio to
have a cross-platform implementation of this functionality, written
in
C++, that abstracts the differences and presents a simple
write/callback API. I've written a TAP/TUN mblock that has the right
C++ guts that could be extracted and reused, but it would still have
the same problem on OS X.
-Johnathan
IIRC there was a discussion about an OS neutral wrapper for tap/tun
several months back. I don't remember any solution being found,
proposed or built.
Eric
___
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] Any implementation of Spread Spectrum
Johnathan, So your DSSS code is not yet public? How did you manage waveform synchronization among multiple USRPs? Thanks. Mark On Jan 29, 2009, at 5:36 PM, Johnathan Corgan wrote: On Wed, Jan 28, 2009 at 9:31 AM, Mir Ali wrote: I want to know if ever any work was done on Spread Spectrum (DSSS) in Gnuradio? Yes. I have done both host code and FPGA code implementation of DSSS with the USRP1 and in progress with USRP2. These will eventually make into the public GNU Radio tree, but it might be some time before that happens. Johnathan ___ 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] Modifying the USRP FPGA core
Hi, Since the USB data rate is the limiting factor in my current setup I figured I would implement some functions on the FPGA itself since they are likely to be simple to implement. I have loaded the project in Quartus and have been looking at the Schematic for some time. I already figured I have to configure with a reduced number of RX, TX channels to free up some FPGA resources. I was wondering where to put my extra logic in this diagram. To be more precise, the logic will only be affecting the RX side and I don't mind the 16-bit values coming out of USB, as long as it's processed with my logic. I was thinking about putting the logic between the rx_chain blocks and the rx_buffer i.e. taking the I and Q values coming out of the DDCs and adding an extra block to do my transformations. I am assuming the rx_buffer only takes the values presented to it and shifts them out USB according to the multi-channel scrambling *e.g.* I0, Q0, I1, Q1, etc. Could you confirm/infirm that my proposed design is valid ? Will the extra block delay affect the functioning of the system ? Thank you, -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Quartus project same version as GNURadio ?
Hi, I'm trying to RUN my own RBF file with the Quartus project (usrp_std.qpf). The compilation goes through and I get usrp_std.rbf . However when I try to create a usrp source like so : self.fpga_filename = "usrp_std.rbf" self.u = usrp.source_c (decim_rate = self.usrp_decim, fpga_filename=self.fpga_filename, mux =0) I get an error File "/usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py", line 1607 in source_c return _usrp_swig.source_c(*args, **kwargs) *RuntimeError: can't open usrp* *Using the precompiled rbf works flawlessly (e.g. std_4rx_0tx.rbf)* Does the Quartus project have to come from the exact same gnuradio version as the one running on the device (I have release 3.1.3 on Quartus and 3.1.3+svn10302 r6.1 on the device itself) ? Thanks -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Quartus project same version as GNURadio ?
Thanks for the pointers. I had already put my RBF where the others are (/usr/share/usrp/rev4) and the others (e.g. std_4rx_0tx.rbf) are working. I fixed my file permissions, it is still not working, I was root anyway... Other hypotheses : Newer version of Quartus, gnuradio not built on Windows machine (only using fpga files in /usrp/fpga/...), std.ihx from same version as the one used to compile verilog. Thanks for your input Mark On Fri, May 22, 2009 at 1:08 PM, Sebastiaan Heunis wrote: > Mark > > Have you made sure that the .rbf is in /usr/local/share/usrp/rev4? > Also, I think that when you issue ls -l when you are in the directory > containing the .rbf file, you should get: > > -rw-r--r-- usrp_std.rbf > > Sebastiaan > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Quartus project same version as GNURadio ?
Issue fixed thanks. On Fri, May 22, 2009 at 1:28 PM, Mark Porter wrote: > Thanks for the pointers. > > I had already put my RBF where the others are (/usr/share/usrp/rev4) and > the others (e.g. std_4rx_0tx.rbf) are working. > I fixed my file permissions, it is still not working, I was root anyway... > > Other hypotheses : Newer version of Quartus, gnuradio not built on Windows > machine (only using fpga files in /usrp/fpga/...), std.ihx from same version > as the one used to compile verilog. > > Thanks for your input > > Mark > > > On Fri, May 22, 2009 at 1:08 PM, Sebastiaan Heunis wrote: > >> Mark >> >> Have you made sure that the .rbf is in /usr/local/share/usrp/rev4? >> Also, I think that when you issue ls -l when you are in the directory >> containing the .rbf file, you should get: >> >> -rw-r--r-- usrp_std.rbf >> >> Sebastiaan >> > > > > -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Quartus project same version as GNURadio ?
Sure, The RBF was loading properly, except that my test decimation value (256) was invalid for the new RBF, which was not clear to me. I thank you for your help in eliminating causes. Mark On Fri, May 22, 2009 at 2:45 PM, Eric Blossom wrote: > On Fri, May 22, 2009 at 02:30:19PM -0400, Mark Porter wrote: > > Issue fixed thanks. > > So that the archive has the answer, what was the fix? > > Eric > > > > On Fri, May 22, 2009 at 1:28 PM, Mark Porter >wrote: > > > > > Thanks for the pointers. > > > > > > I had already put my RBF where the others are (/usr/share/usrp/rev4) > and > > > the others (e.g. std_4rx_0tx.rbf) are working. > > > I fixed my file permissions, it is still not working, I was root > anyway... > > > > > > Other hypotheses : Newer version of Quartus, gnuradio not built on > Windows > > > machine (only using fpga files in /usrp/fpga/...), std.ihx from same > version > > > as the one used to compile verilog. > > > > > > Thanks for your input > > > > > > Mark > > > > > > > > > On Fri, May 22, 2009 at 1:08 PM, Sebastiaan Heunis >wrote: > > > > > >> Mark > > >> > > >> Have you made sure that the .rbf is in /usr/local/share/usrp/rev4? > > >> Also, I think that when you issue ls -l when you are in the directory > > >> containing the .rbf file, you should get: > > >> > > >> -rw-r--r-- usrp_std.rbf > > >> > > >> Sebastiaan > > >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Slowing down USB rate in USRP (related to strobes)
Hi, I have added a block to the receive path of USRP -- between the DDCs and rx_buffer. It was my understanding that rx_buffer would only fetch a new sample to send through usb after "rx_strobe" was up for one clock cycle. Therefore my block processes 32 samples of I and Q and THEN asserts rx_strobe (sample strobe) for one clock cycle, making rx_buffer sample the data on ch0 and ch1 in this case but 32 TIMES less often than normal. Are there any other signals to take care of? My design does not seem to work, since my custom block (which by design should assert rx_strobe *32 times*less often) gives the same file size as the "stock" design, suggesting they provide the same data rate over USB since I'm doing a straight file sink. -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Compiling custom blocks for ARM
Hi, I've had some success recently in building my own GNURadio custom blocks on my Ubuntu machine. However I want to port my custom blocks to an ARMv7a platform (gumstix, Beagleboard). I do have the cross compiler binaries for ARM, however I am confused as to how to use them to compile custom blocks... does it only involve changing the makefiles to reflect the new target platform ? Thanks, -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error in running a custom block
Hi all, I have compiled a custom block for GNURadio, and it is not running properly. My error message below seems to indicate a problem with swig or something similar. self.usrp is the usrp source, self.minmax is the custom block ### File "script.py", line 76, in tb = my_top_block() File "script.py", line 64, in __init__ self.connect (self.usrp, self.minmax, self.nullsink) File "/usr/lib/python2.6/site-packages/gnuradio/gr/top_block.py", line 99, in connect self._connect(points[i-1],points[i]) File "/usr/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1481, in connect return _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self,*args) NotImplementedError: Wrong number of arguments for overloaded function 'gr_top_block_sptr_connect'. Possible C/C++ prototypes are: connect(boost::shared_ptr< gr_top_block > *, gr_basic_block_sptr) connect(boost::shared_ptr< gr_top_block > *, gr_basic_block_sptr,int,gr_basic_block_sptr,int) swig/python detected a memory leak of type 'gr_basic_block_sptr *', no destructor found. ### Here's the kicker. The script works with a block compiled for an x86 PC. However the above error occurs with a block compiled for an ARM platform using openembedded and bitbake. It seems to compile just fine and I have put all the necessary files in the /usr/include and /usr/lib on the platform. I am looking at any input from this list as to where the problem might be... Thanks -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error in running a custom block
I have : my block is closely based on the howto example. It compiles fine on the x86 machine as well. I'm starting to point the finger at the gnuradio installation. It seems that in the /usr/lib/python2.6/site-packages/gnuradio/gr folder, the gnuradio_swig_py_runtime.py is the culprit. Is it a file that changes often from one version of gnuradio to the other ? Does it depend on the version of swig ? Thanks On Wed, Jun 24, 2009 at 3:36 PM, Eric Blossom wrote: > On Wed, Jun 24, 2009 at 12:10:29PM -0400, Mark Porter wrote: > > Hi all, > > > > I have compiled a custom block for GNURadio, and it is not running > properly. > > My error message below seems to indicate a problem with swig or something > > similar. > > > Did you define an out-of-line virtual destructor for your block? > > > > self.usrp is the usrp source, self.minmax is the custom block > > ### > > File "script.py", line 76, in > > tb = my_top_block() > > File "script.py", line 64, in __init__ > > self.connect (self.usrp, self.minmax, self.nullsink) > > File "/usr/lib/python2.6/site-packages/gnuradio/gr/top_block.py", line > 99, > > in connect > > self._connect(points[i-1],points[i]) > > File > > > "/usr/lib/python2.6/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", > > line 1481, in connect > > return > _gnuradio_swig_py_runtime.gr_top_block_sptr_connect(self,*args) > > NotImplementedError: Wrong number of arguments for overloaded function > > 'gr_top_block_sptr_connect'. > > Possible C/C++ prototypes are: > > connect(boost::shared_ptr< gr_top_block > *, > gr_basic_block_sptr) > > connect(boost::shared_ptr< gr_top_block > *, > > gr_basic_block_sptr,int,gr_basic_block_sptr,int) > > > > swig/python detected a memory leak of type 'gr_basic_block_sptr *', no > > destructor found. > > ### > > > > Here's the kicker. The script works with a block compiled for an x86 PC. > > However the above error occurs with a block compiled for an ARM platform > > using openembedded and bitbake. It seems to compile just fine and I have > put > > all the necessary files in the /usr/include and /usr/lib on the platform. > I > > am looking at any input from this list as to where the problem might > be... > > > > Thanks > > > > -- > > Mark > > -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FYI: Google results for "GNU radio" point to a broken link
Asked in IRC and was directed to the mailing list, so here it is. If you google for "GNU Radio", the links returned point to http://gnuradio.org/tracwhich is now gone. It might be worthwhile to add a redirect match for /trac* so that people don't land at a default Apache 404 page. Regards, -Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: WBX
It amazes me how much people will pay for a piece of FR-4 and an SMA connector. -Mark On Fri, Jan 15, 2010 at 10:32 AM, John Ewan wrote: > Another antenna to look at. > > > http://www.ramseyelectronics.com/cgi-bin/commerce.exe?preadd=action&key=LPY41 > > > > > > From: > discuss-gnuradio-bounces+jewan=its.bldrdoc@gnu.org[discuss-gnuradio-bounces+jewan= > its.bldrdoc@gnu.org] On Behalf Of Marcus D. Leech [mle...@ripnet.com] > Sent: Friday, January 15, 2010 12:10 AM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Re: WBX > > On 01/15/2010 12:26 AM, Matt Ettus wrote: > > > > The Vert400 antenna will work well over several separate bands: > > > > 118-160MHz, 250-290MHz, > > 360-390MHz, 420-470MHz, 820-960MHz, 1260-1300MHz > > > > It will radiate but will not be optimal in areas outside of that. For > > this wide a bandwidth you could also look into a discone antenna. > > Radio shack and some other companies carry them. > > > > Matt > Here's a good discussion of the discone antenna: > > http://www.northcountryradio.com/Articles/discone.htm > > > > > ___ > 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] starting out
Hi I have been looking at GNUradio for a while, and decided to start playing with it. I purchased one of the USRPs with the TV receiver daugherter board and the 800 MHz - 2.4 GHZ receiver board. I am trying to get some of the USRP basic example scripts to run and some do, one error I keep getting is RuntimeError: can't open usrp1 I get this error when I run the gnuradio-examples/usrp/usrp_oscope.py script This I suspect may be a path problem the second error I get is ImportError: No module named ephem When I run usrp_ra_receiver.py. Any suggestions. Mark Rader ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Getting Started
Hi I have GNUradion up and running with the USRP board. I have two daughter cards installed. One is the DBSRX, the second is the RFX1800, and I have a 3rd dauther board the TVRX that is not installed. I can get the thing to respond, but I get an error on most of the python scripts. USRP Open Interface:Usb_claim_interface: failed interface 2. Next it tells me usrp_basic_rx: cant open rx interface. Does anyone have any ideas? My suspicission is that the device wants all slots to be filled. Mark RAder ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio at Field Day
Just curious if anyone used their gnuradio/USRP platform this past Field Day? If yes, I'd like to hear in what capacity. For those of you who may not know what FD is http://en.wikipedia.org/wiki/Field_Day -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FCC issues SDR/CDR rules in the Federal Register
I'm having a bit of trouble locating the passages of interest in the link below. Is it possible to be a bit more specific about where to look? Thanks. On 7/6/07, Robert McGwier <[EMAIL PROTECTED]> wrote: That means they are now U.S. law. http://dw.com.com/redir?destUrl=http%3A%2F%2Fenterprise.spawar.navy.mil%2Fbody.cfm%3Ftype%3Dc%26category%3D27%26subcat%3D60&siteId=22&oId=2100-3513-6195102&ontId=3513&lop=nl.ex Amateur radio is mentioned explicitly. Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "If you're going to be crazy, you have to get paid for it or else you're going to be locked up." Hunter S. Thompson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Please connect with me :)
Hi, I looked for you on Reunion.com, but you weren't there. Please connect with me so we can keep in touch. -Mark Do You Know Mark? YES - Connect with Mark, and see who's searching for you http://www.reunion.com/showInviteRegistration.do?uid=278237227 NO - I don't know Mark http://www.reunion.com/showInviteRegistration.do?unsub=true&uid=278237227&[EMAIL PROTECTED] Reunion.com - Find Everyone from Your Past. You have received this e-mail because a Reunion.com Member sent an invitation to this e-mail address. For assistance, please refer to our FAQ or Contact Us. http://help.reunion.com/selfhelp?lid=2 Our Address: 2118 Wilshire Blvd., Box 1008, Santa Monica, CA 90403-5784___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using PCI DAS4020/12 with the example program provided
Hi, I have the PCI DAS4020/12 installed on my PC. I am attempting to run the FM demodulator example provided in the gnuradio examples (in gnuradio-examples-0.3). I have two questions. 1. What input frequency ranges is the program looking for? 2. When I run the program inputing 104 as the input freq, I get the following error: /dev/parport0: permission denied. Aborted. Is anyone using the PCI DAS4020/12 and able the run the FM demodulator example provided? I have installed the mc4020 module as well. Thanks for any help. Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fm_demod.py
Hi, I am executing the FM demodulator example provided in the gnuradio examples (gnuradio-examples-0.3) and have three questions. 1. Does the program require two input frequencies or one? 2. If I type ./fm_demod.py 97.5 94.5 does this mean that signal between 97.5MHz and 94.5MHz will be demodulated? Will this then demodulate 96.5MHz. 3. If I type ./fm_demod.py 104.7 does this mean that signal at 104.7 will be demodulated? Thanks for the advice, Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Boost: regarding not found shared_ptr.hpp
I installed boost in nonstandard location $HOME/gr, and thereby produced the same build failure as this gentleman http://lists.gnu.org/archive/html/discuss-gnuradio/2005-06/msg00282.html In my Linux environment, I set CPPFLAGS=-I$HOME/gr/include/boost-1_33_1export CPPFLAGSand where $ ls $HOME/gr/include/boost-1_33_1boostThis constitutes a third fix for this failed build situation. The first two being 1) install boost in a standard location so the preprocessor can find stuff without being told, and 2) pass --with-boost-include-dir=$HOME/gr/include/boost-1_33_1 to configure hth somebody.-- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Which LinuxOS to use?-->1.Unbuntu, Fedora, Mandrake, FreeBSD
I , too, am an Ubuntu 6.06 user. What were you attempting to fix by modifying gnuradio-core/aclocal.m4?MarkOn 6/26/06, Robert McGwier < [EMAIL PROTECTED]> wrote:Lamar:I installed Ubunto 5.X and GnuRadio just made and ran after I used apt (synaptic) to download any package GnuRadio could not find. With Ubunto6.0X I had to make a modification to aclocal.m4 (and I am sure thereare other ways to fix it) in gnuradio-core but otherwise, it just compiled and ran. It is easy to install and maintain and with theopening up to universe, multiverse, nongpl code as opposed to Debian onwhich it is based, I find I am not building out of necessity. I haveCHOSEN (for example) to build swig.1.2.latest for various reasons but Idid not need to.BobLamar Owen wrote:> On Monday 26 June 2006 11:42, Marcus Leech wrote:>>> FC6 is just around the corner--the TEST1 release is already available. >> Sigh. Yeah, I had sworn I wasn't going to get back on the Fedora roller coaster;> that's why I use CentOS of the servers. But the needs of the bleeding edge> have conspired to cause me to go with FC5 the needs being driven by > GNUradio in part, and Plone in part. But with YUM, it's relatively painless to "keep up". Depending upon your bandwidth, at least.> --AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp ChairmanTime for a new motto, what should I choose?___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- MarkAE6RT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Creating a CW receiver for 20m ham band
Good day.Does anyone have GNU Radio code I can inspect to learn how to decode and render to audio CW transmissions in, say, the US amateur bands?Thank you.-- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Python docs
Good day.I'd like to know more about the Python doc problem.http://lists.gnu.org/archive/html/discuss-gnuradio/2005-01/msg00249.html
From what I can tell, generating python docs for gnuradio is an outstanding taskhttp://www.comsec.com/wiki?SuggestedProjectsI say this because I do not see xsltproc, for example, called anywhere during build, and I think if this problem were already solved, I probably would.
While I cannot yet volunteer to work on this problem, a bit of status on where it is would be helpful.Some things I believe and/or have executed:- Being new to swig and python and its uses in given situations, I'm still a bit disoriented wrto which gnuradio-core ("core") piece dovetails into what other piece.
I think it goes like this:In the beginning, there was C++. From that follows python interfaces into C++ via swig. From there we find utility python code in the core written by some human and not a code generating tool. And from there we find python application code here and there.
- True or false (and why so either way): the documentation task above must be solved before we can produce, presumably with epydoc, html docs for *any* core python code.- Having compiled the core with --enable-doxygen, I notice that there are xml files in the output, presumably the ones mentioned in the mailing list post.
- I notice some %feature("autodoc","1") instances in some .i swig files. It appears we are incrementally solving the problem that is the subject of the mailing list posting above. - I see many .i files that do not contain "autodoc"/"docstring" directives. Not sure why, or what the implications are. (Notice how
this can mean "I disagree with what I see" or "Someone tell me why I see what I see, because I just don't know". I mean the latter.).- assuming we get to swig_doc.i files mentioned in the post, would there be one swig_doc.i file for every other .i file in the core?
- a general backing question: a python module can have code that originates in high level python code (a .py file) as well as code that comes to us by way of a swig interface. gnuradio.gr
, e.g., has a flow_graph via 'native' python code as well as a file_sink that comes to us via swig. Presumably we lack input that can generate docs for that swig interface object.- if this problem were already solved, can I get an example of an html file that would exist as a result? Just the file name, not the contents.
Thank you.-- Mark
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP - hotplug / udev / auto-loading of firmware
I also added to the rules fileSYSFS{idVendor}=="077d", SYSFS{idProduct}=="0410", MODE="0666"so I could access the Powermate without becoming root.
On 6/29/06, Lee Patton <[EMAIL PROTECTED]> wrote:
On Thu, 2006-06-29 at 07:44 +0100, Kalen Watermeyer wrote:> I ask because I run Ubuntu 6.06 (Dapper), which uses> udev, and will need to edit my device manager's rules> to identify my custom board, and am not sure if this
> is necessary. Oh, and the OS detects my FX2 micro when> I run lsusb (albeit unconfigured).>> Finally, if I do have to edit the rules (SYSFS,> VendorId etc), what exactly will I need to let my
> system know? (I have read udev docs briefly, but was a> little confused)You don't necessarily have to do this, but it is useful to run as anon-root user. See the following link for specific details:
http://lists.gnu.org/archive/html/discuss-gnuradio/2006-06/msg00213.html___
Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-- MarkAE6RT
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] multi-antenna example
Hi all, I got my USRP up and running just fine after a fresh install of Suse 10.1 I'm working on a "walkthrough" that describes some of the problems I encountered; I'd be happy to add it to the Wiki if anybody is interested. After running the USB benchmark (32M, no problem) and seeing the FFT display work, just for fun I attached an antenna directly to my basic RX and keyed an FRS radio nearby. No problem seeing the 465 MHz FM signal pop up. Very cool. Now for the only problem I've encountered. I have two basic RX cards installed, and I'm injecting a single signal into the "RX-A" input of the A side card at a level of about 45 dBm or so. I run the multi-antenna capture to file code with maximum decimation (256) and software filtering turned off for a 50 millisecond collect. I then look at the spectrum of the resulting four files with MATLAB (sorry!). I see my carrier in both channels 0 and 1 (but not 3 or 4) at nearly the same level. I didn't see any error messages during the collect; is it possible that the software couldn't keep up with the data and got out of sync? I'm going to try writing some test code to pull in the data to memory before writing out to disk next. Any thoughts? Best regards, Mark Sullivan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Suse10.1 walkthrough and a question concerning crosstalk
When I inject a signal at a -45 dBm level on the "RX-B" sma connector on a Basic RX daughtercard, I see a copy of the signal on the "RX-A" side when I use usrp_fft.py. The level is 10-20 dB below that of what I see if I move the signal from "RX-B" to "RX-A," but this seems like too much coupling. Using a 50 ohm termination on the unconnected sma connector helps a little bit. I see no copy of the signal from either input of the other Basic RX daughtercard. Any thoghts, anyone? Best regards, Mark Sullivan Here is a walkthough I put together for Suse10.1. I found a few "gotchas" not described in the build instructions on the Wiki. Installing GnuRadio and the USRP on Suse 10.1 for the Linux-impaired. Version 0.1 22 September 2006 What you will need: PC with USB 2.0 and DVD drive, Suse 10.1 DVD, USRP, An internet connection, The better part of an afternoon. INSTALLING LINUX Boot from the DVD. Don't use the CD version; it is missing fftw3f.pc and the FFTW package will not install. Choose your language of choice and click on NEXT. Select "YES" to accept the license and click on NEXT. On the "System Analysis" screen select "New Installation" and click on NEXT. On the "Time Zone" screen set up your clock and click on NEXT. On the "Desktop" screen select "Gnome" and click on NEXT. On the "Installation Summary" screen click on "Software" (it should be displaying "Standard Software Gnome 2"). The "Software Selection" screen appears. Click on "Details" to customize your selection. Select "Package Groups" as the Filter; you should get a tree on the left of the screen. Click on the "development" branch; click on the "package" menu on the toolbar, scroll down to "All in this list," in the pull down menu, then select "Install." Under the "Development" tree, click on "KDE" sub-branch; click on the "package" menu on the toolbar, scroll down to "All in this list," in the pull down menu, then select "Do not install." Under the "Productivity" tree, click on "Scientific" sub-branch; click on the "package" menu on the toolbar, scroll down to "All in this list," in the pull down menu, then select "Install." Click on the "Libraries" tree; click on the "package" menu on the toolbar, scroll down to "All in this list," in the pull down menu, then select "Install." Click on "Accept." You will get a pop-up window with three warnings. Click on the circles next to "do not install flex-old" for the first two warnings and click on the circle next to "do not install gtkl-compat-devel" for the remaining warning. Click on the "OK, try again" button at the bottom of the pop up window. An Adobe license window appears; click on the "Accept" button. A flash player license window appears, click on the "Cancel" button. The "Installation Settings" window reappears after a long pause. Click on "Accept" at the lower right hand corner. A "Confirm" window appears; click "Install." A "Package Installation" screen appears. Click on the "Details" tab to watch the progress of the install. This would be a good time to take a break; installation will take about 1 hour to complete. The system will reboot and the Install screen re-appears. Enter your hostname and domain and click on Next. Enter your root password and click on Next. Write down your root password so you don't forget it! A "Network Configuration" screen appears. If you have DHCP set up, select that option and click on Next. A "Test Connection" window appears. Click on Next. Assuming all is well with the connection, click on Next again after the test is complete. An "Online Update" screen appears; select "Configure now" and click on Next. Wait for a while for the server to be selected. An "Online Update Configuration" window appears; click on "OK." Click on the circle next to "Run Update," then click on Next. A "Update Select" screen appears; click on "Accept" The YAST package will now be updated. You can update the rest of your system later. After "Total Progress" reaches 100%, click on Next. After a pause, the "Update Select" screen reappears. Click on Cancel. The "Authentication Method" screen appears. Click on the circle next to "Local." The "New Local User" screen appears. Enter your name, username, and password. The "Release Notes" screen appears. Click on Next. The "Hardware Configuration" screen appears. Click on Next. The "Installation Com
Re: [Discuss-gnuradio] Suse10.1 walkthrough and a question concerning crosstalk
Eric, As an additional experiment I hacked multi_file.py in the multi-antenna folder so that the multiplexor was set to channel 0 for all four "I" inputs; with a carrier injected into channel 1, I saw identical leakage. I then changed the mux setting to channel 1 for all "I" and saw the injected carrier. This isn't sounding like software. Best regards, Mark SullivanOn 9/22/06, Eric Blossom <[EMAIL PROTECTED]> wrote: On Fri, Sep 22, 2006 at 05:38:54PM -0400, Mark Sullivan wrote:> When I inject a signal at a -45 dBm level on the "RX-B" sma connector on a> Basic RX daughtercard, I see a copy of the signal on the "RX-A" side when I > use usrp_fft.py. The level is 10-20 dB below that of what I see if I move> the signal from "RX-B" to "RX-A," but this seems like too much coupling.> Using a 50 ohm termination on the unconnected sma connector helps a little > bit. I see no copy of the signal from either input of the other Basic RX> daughtercard. Any thoghts, anyone?>> Best regards,>> Mark SullivanHi Mark,There's a chance that the code that determines the rx digital mux setting isn't handling this case properly.Assuming that the Basic Rx is on the "A" side, please try this: $ usrp_fft.py -R a:0 -f and try moving the test signal from RX-A to RX-B and this: $ usrp-fft.py -R a:1 -f and move the test signal from RX-A to RX-BWhat happens?Thanks,Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Suse10.1 walkthrough and a question concerning crosstalk
Pascal, Thanks for the tip, I'll add that to version 0.2. I can tell that you are much less "linux impaired" than I! Best regards, Mark SullivanOn 9/26/06, Pascal Charest <[EMAIL PROTECTED]> wrote: On 9/22/06, Mark Sullivan <[EMAIL PROTECTED] > wrote: (...) INSTALLING SDCC Log on to your account (not root). You need to install the SDCC package. Get the source tarball from Sourceforge at http://sourceforge.net/project/showfiles.php?group_id=599. (it will be called "sdcc-src-2.6.0.tar.gz" unless a newer version is available now) Do NOT load the Suse RPMs- the pair of RPMs depend upon each other, and the RPM command won't install either. Put the tarball in your home directory. Double-click on the icon for the tarball. A window will appear; click on "Extract." Click on "Extract" in the new window that appears. This will create a directory called "SDCC" in your home directory. Open up a terminal. (Click on "Applications" on the menu toolbar,scroll up to "System" in the menu that appears,scroll down to "Terminal" in the *next* menu that appears, then click on "Gnome Terminal" in yet another menu that appears) In the terminal window, type "cd SDCC" and hit Enter. Now type "./configure" and hit Enter. Now type "make" and hit Enter. now type "sudo make install" and hit Enter. When asked for the root password, enter it. type "cd .." and hit Enter. (...)Yeah, when trying a command like 'rpm -ivh sdcc-xxx.rpm', the system complains about dependencies with sdcc-common and when trying 'rpm -ivh sdcc-common-xxx.rpm', it complains about dependencies with sdcc... But, if you download both packages in the same directory and try 'rpm -ivh sdcc*.rpm', it works! Rpm will find cross-dependencies between package if they are installed at the same time. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Suse10.1 walkthrough and a question concerning crosstalk
Matt, Coupling problem solved. Doh! -45 dBm is *way* too low; only the very low order A/D bits were toggling. When I put in something closer to +10 dBm I get a nice strong signal and the image on the other port of the same daughtercard is down about 60 dB. I can't measure the crosstalk from one daughtercard to the other. I guess that the tiny amount of crosstalk at -45 dBm was just enough to flip the LSB of the unconnected port often enough to give me a spectral line at a very low level. With more amplitude the A/Ds are acting more "linear" and I can now see the difference in levels more accurately. The upside is that I know a lot more about the code now than when I started. Best regards, Mark SullivanOn 9/24/06, Matt Ettus <[EMAIL PROTECTED]> wrote: Mark Sullivan wrote:> When I inject a signal at a -45 dBm level on the "RX-B" sma connector> on a Basic RX daughtercard, I see a copy of the signal on the "RX-A"> side when I use usrp_fft.py. The level is 10-20 dB below that of what > I see if I move the signal from "RX-B" to "RX-A," but this seems like> too much coupling. Using a 50 ohm termination on the unconnected sma> connector helps a little bit. I see no copy of the signal from either > input of the other Basic RX daughtercard. Any thoghts, anyone?>I don't know what's happening here, but I see about -80dB couplingbetween the channels.>> Here is a walkthough I put together for Suse10.1. I found a few> "gotchas" not described in the build instructions on the Wiki.Thanks! I put this on the wiki, but didn't "wikify" the formatting.Feel free to edit it. It is linked to from the Suse install page. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio overview podcast
Eric was kind enough to spend time with me to produce an overview podcast of GNU Radio, targetted at teh curious or newcomer.It's my first recorded podcast, so the audio quality is not what I would have hoped, but I believe it is usable. http://www.petrovic.org/blog/2006/10/18/gnu-radio-podcast/-- MarkAE6RT ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP/gnuradio Issues in OS X
Hi! I'm new to gnuradio, and I just got my USRP several days ago. I'm trying to use it with my Mac running Snow Leopard, and I'm having some issues with some of the USRP utilities and examples. I've built the gnuradio software from the head revision in the git repository, with the pre-requisite libraries supplied by MacPorts. My USRP hardware appears to be working correctly, since I can run many of the examples such as usrp_fft.py, usrp_wfm_rcv.py, usrp_nbfm_rcv.py and usrp_siggen.py, all with reasonable results. Some of the other examples and utilities aren't working for me though. In this message I'll just focus on two of them: usrper and usrp_benchmark_usb.py. I've tried running the test routine (?), and it fails like this: ~% usrper load_standard_bits Assertion failed: (ctx != NULL), function usrp_find_device, file usrp_prims_libusb1.cc, line 184. Abort ~% I've also tried running the bandwidth benchmark, and it fails like this: ...examples/usrp% ./usrp_benchmark_usb.py Testing 2MB/sec... usrp: libusb_control_transfer failed: Unknown error usrp: failed to get hash usrp: libusb_control_transfer failed: Unknown error write_internal_ram failed usrp: failed to load firmware /usr/local/share/usrp/rev4/std.ihx. Traceback (most recent call last): File "./usrp_benchmark_usb.py", line 106, in main () File "./usrp_benchmark_usb.py", line 96, in main ok = run_test (rate, verbose) File "./usrp_benchmark_usb.py", line 67, in run_test usrp_rx = usrp.source_s (0, rx_decim, 1, 0x32103210, usrp.FPGA_MODE_LOOPBACK) File "/usr/local/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py", line 2067, in source_s return _usrp_swig.source_s(*args, **kwargs) RuntimeError: can't open usrp ...examples/usrp% Some notes on my build environment: I found that I need to use the native gcc instead of the one provided by MacPorts in order for gr-audio-osx to build (it can't find some of the core audio headers otherwise), and that I need to pass some flags into configure so that the required libraries and headers are found. Also, MacPorts installs "libtoolize" as "glibtoolize" to avoid a name collision with the native Mac "libtool" program, so I created a symbolic from /usr/local/bin/libtoolize to /opt/local/bin/glibtoolize in order to get the bootstrap script to run. I configured the gnuradio software this way: ./configure CC="/usr/bin/gcc" \ CXX="/usr/bin/g++" \ CPPFLAGS="-I/opt/local/include -I/opt/local/include/qwt -I/opt/local/include/qwtplot3d" \ LDFLAGS="-L/opt/local/lib -F/opt/local/Library/Frameworks" \ --with-fusb-tech=libusb1 \ --enable-gr-qtgui \ --enable-gr-audio-osx The two --enable* flags probably aren't strictly necessary, but they are leftover from when I was finding the pre-requisites for those packages by trial and error. Everything seems to build OK, and I can use the USRP with some of the examples. I tried "make check", and it passes a whole bunch of tests and then chokes when a test that I haven't identified yet complains about failing to connect to a socket. There are other examples which presently don't work for me, such as hfx2.py and usrp_am_mw_rcv.py... I'll try debugging those some more myself before I ask about them here. Have any of y'all seen these kinds of failures before? Thanks in advance for any hints or suggestions. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] External clock source Info?
On Aug 17, 2010, at 2:24 PM, William Pretty Security Inc wrote: > It seems that 52MHz /64MHz precision clock references are like hen’s teeth, > so I’m working on a design. > What I need to know is what sort of level is the USRP1 looking for ? Is it > 3.3V CMOS ? > > Once I get the design working, I’ll make them available at a reasonable price > J I think you will get bonus points if your design can accept an external 10MHz reference provided by a GPS-disciplined oscillator. If there was some convenient way to adjust out the crystal aging for use when the external reference isn't available, that would be even better. I've been thinking of designing something along these lines, but I won't complain if you do the hard work and I can just buy one from you. ;) -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] External clock source Info?
On Aug 17, 2010, at 2:24 PM, Gregory Maxwell wrote: > I'd also like to echo the 10MHz comment. GPSDOs Clocks with excellent > long term stability show up at fairly low prices on ebay all the time > (excess from cell site deployments, I assume). I have a couple of > them. What they don't usually have is the very low phase noise that > I'd want for a clock which is eventually going to multiplied up to GHz > levels. So a USRP1 clock board which was primarily a 10->64MHz > up-converter with very low phase noise would be exactly what I would > want. For my bench frequency reference, I selected a surplus Trimble Thunderbolt with the newer version of OCXO that's supposed to be nearly as good as the HP double-oven OCXOs. I'll power it from an HP bench supply, since the switchers that are often supplied with the surplus Thunderbolts are said to add a lot of phase noise to the oscillator output. If the statistics from the monitoring program that I used during my first test run of the oscillator are to be trusted, then it should be able to provide a reference accurate to within tens of parts per trillion. I haven't finished installation of my GPSDO yet; I still need to finish repairing the (cheap, broken) HP bench supply that I got from eBay and assemble a power cable. I may get this done tonight, as the parts I needed just arrived today. The outdoor antenna (a surplus Lucent +26dB antenna as used at cell sites) is already installed and cabled into my house. My own idea for a USRP clocking replacement was to use a common and fairly inexpensive VCTCXO rated for temperature stability of around +/-2.5ppm (available at Digi-Key in frequencies commonly used in cell phones, GPS receivers, etc.), drive a PLL+VCO with that to generate 64 MHz (or 52 MHz, or any other frequency that the TCXO+PLL+VCO can generate), with an additional PLL to lock the VCTCXO to an external 10 MHz input. I'd also include a microcontroller which could measure the VCTCXO control voltage while locked to an external reference, and then drive that same voltage with a DAC when the external reference isn't present. Thus, while attached to the GPSDO the internal reference would be slaved to a very good reference, and then when that reference isn't available (such as when operating "in the field") the on-board VCTCXO would at least be trimmed to compensate for aging. The memorization of the nominal VCTCXO tuning voltage might be triggered automatically, or by a push button, or by a GPIO controlled by the USRP hardware. The VCTCXO might be replaced with a voltage-controllable OCXO if desired for better holdover stability, but I figured that VCTCXO should be adequate for my needs. Does that architecture sound reasonable? If so, would anybody like to save me the trouble of designing and building it myself? ;) -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OCXO ' s
On Aug 17, 2010, at 5:07 PM, William Pretty Security Inc wrote: > More Info on the parts I plan to use: > At this point I have two possible fixed frequency parts: > > Silicon Labs Si590 series: > http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=590PC-BDG-ND > Pletronics OHM4 Series: http://www.pletronics.com/products/select/ocxo1.php I think that the Pletronics part looks like a much better option. If I'm not mistaken, the SiLabs part is a computer-grade oscillator with much lower stability and accuracy than is typically required in radio communications applications. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sma adapters?
On Aug 19, 2010, at 5:15 AM, dave k wrote: > has anyone done a permanent install of a usrp1 or usrp2 with heavy duty feed > line? pictures?? how to secure everything? my coax is just lmmr400 with a N > Male, i need either a jumper cable or adapter. which has method works best? > suggested vendors? thanks A short jumper cable between the thick LMR400 cable and the USRP might be a good idea for strain relief. You can order all of the required adapters and cables from a distributor like Digi-Key, or a cable/adapter vendor like Pasternack. Pasternack will also make custom cables in single quantity. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sma adapters?
On Aug 19, 2010, at 11:10 AM, Marcus D. Leech wrote: > When I've had to do this, I've put an 'N' to SMA on the fat cable, and > used a short piece of thin flexible cable with SMAs on it. That's exactly what I did in my semi-permanent GPS-disciplined oscillator installation. I also do the same thing when I connect my outdoor discone antenna to my USRP. Both of them have thick feedlines (similar to RG8, LMR400, etc.) terminated with male N connectors, and that's a lot of mass and leverage to hang off a little SMA connector. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get dqpsk2 block?
On Aug 20, 2010, at 12:56 AM, Thunder87 wrote: > Somehow managed to install git and get gnuradio source. Now I have a problem > with source installation. "sudo ./configure" says: > > The following components were skipped either because you asked not > to build them or they didn't pass configuration checks: > > gruel > gcell > gnuradio-core [...] > > These components will not be built. You're probably missing at least one required library, so it's not building any of the important parts of the gnuradio code. Look at the config.log file that was created by running configure, and find the first critical component that it decided not to build (probably gruel, and you'll most likely find it by searching for the word "building"), then try to figure out why it didn't build it. I think it's ok for gcell to not be built on most systems, but other components like gruel or gnuradio-core are critical. Here's a snippet of my config.log file as an example: [...] configure:21465: checking for byteswap.h configure:21465: result: no configure:21548: result: Component gruel passed configuration checks; building. configure:21590: checking whether host_cpu is powerpc* configure:21599: result: no configure:21606: checking for spu-gcc configure:21634: result: noconfigure:21667: result: Not building component gcell. configure:21937: checking for cblas_sgemm [...] Notice that it decided to build gruel, and not to build gcell, and that it didn't build gcell because it couldn't find the spu-gcc compiler. In your config.log file, it'll say "...result: Not building component gruel.", and the lines (lots of them, including dumps of the test programs that failed) are what you'll need to study to determine what's missing. Some of the failures are probably innocuous (like my missing byteswap.h file, I think), and just indicate the sorts of system-specific variances that the configure script is looking for. However, there'll probably be at least one failure to find a critical library or header file, and that'll be your first clue about what else you'll need to look for and install. You will probably need to repeat the process many times before all of the critical components will build. You might also need to pass more arguments to the configure script, if you determine that it's not finding something that you're sure is installed on your system. While you're working your way through finding all of your missing required libraries, it may be helpful to temporarily add flags such as "--with-gruel" or "--with-gnuradio-core" to the ./configure invocation to make the script abort immediately after deciding not to build the specified component, rather than continuing on and making a zillion more lines of output for you to sift through. For example, since the critical gruel component isn't building on your system, nothing that comes after it in the configuration script matters until you fix that, and the "--with-gruel" flag should tell it to give up immediately after deciding not to build gruel. By the way, you should only need to use sudo to run the final "make install" step. None of the configuration and compilation steps before that should require root privileges. Good luck! -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get dqpsk2 block?
On Aug 21, 2010, at 1:46 AM, Thunder87 wrote: > log repeatedly says: > failed program was /* confdefs.h */ > > So I guess it's confdefs.h )) You have any idea what is it? That "/* confdefs.h */" is just the first line of a temporary C program generated by the configure script to check whether some header file or function can be found. It's not the thing that configure is complaining that it can't find. For example, here's a snippet of my config.log file where it looks for the header file minix/config.h, and doesn't find it: configure:5554: checking minix/config.h presence configure:5554: /usr/bin/gcc -E -I/opt/local/include -I/opt/local/include/qwt -I/opt/local/include/qwtplot3d conftest.c conftest.c:21:26: error: minix/config.h: No such file or directory configure:5554: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define PACKAGE "gnuradio" | #define VERSION "v3.3.1git-47-gf6337c62" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | /* end confdefs.h. */ | #include configure:5554: result: no See, first it says that it's checking for the presence of minix/config.h. Next, it prints the command it used to check for that file (the /usr/bin/gcc line). Next, it prints the output of that command, where the C compiler said that it couldn't find minix/config.h. After that attempted little compilation fails, the configure script prints out the contents of the temporary little program it created for the failed test compilation (all of the lines beginning with "|"). Finally, is prints that the result of its test was "no". In this case, it's not a problem for me that minix/config.h wasn't found. It's just a system-specific variation that the configure script is testing for. But when a gnuradio component isn't built, there will usually be come output that looks like this: configure:25705: result: no configure:25707: result: gr-audio-alsa requires package alsa, not found. configure:25742: result: Not building component gr-audio-alsa. There was a whole bunch of output right before this from configure's tests to see if it could find the "alsa" package, but the part that I would care about if I wanted to build gr-audio-alsa is just the line where configure tells me that it's not building gr-audio-alsa because it couldn't find the alsa package... so then I'd go looking for the alsa package and install it on my system to fix the missing dependency. At this point, you're not so much having a gnuradio problem yet... you're still learning how to understand the output of the "configure" script, which is created by the Gnu Autoconf tools. It's kind of complicated, but once you get over the learning curve this knowledge will apply towards working with lots of other open-source stuff, too. Keep plugging along, and you'll get there! -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Aug 23, 2010, at 11:52 AM, Michael Dickens wrote: > Hi Mark - I don't know where to point you exactly, since some tests work for > you while others don't. You're using "--with-fusb-tech=libusb1", which > should work but hasn't been thoroughly tested (at least on OSX). Have you > tried configuring without this flag & then re-testing to see what happens? > The native FUSB/OSX drivers do use the "legacy libusb" (as found on > MacPorts), but they are well tested & just as fast as those provided by > libusb1. - MLD I have the lib...@1.0.8 port installed rather than the libusb-leg...@0.1.12 port, because (I think) I have other stuff that wants the newer libusb port. I discovered that I needed to use the "--with-fusb-tech=libusb1" flag to get the configure script to properly identify my libusb version. Before I used that flag everything would compile, but the usrp executables would fail to find a symbol they needed in libusb and then crash. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Aug 23, 2010, at 12:09 PM, Michael Dickens wrote: > Hi Mary - So long as you use MacPorts for background dependencies, libusb1 > and libusb-legacy (v0.1.12) can be installed at the same time & you can > easily choose between them (different PKGCONFIG files). Do note that > "libusb-compat" does NOT work with FUSB/Darwin since GNU Radio's FUSB/LIBUSB > code uses internals that are not in the 'compat' version (only the API is > compat, not the internal implementation). On my MacBook Pro (10.5.8, i386), > GNU Radio compiles and executes just fine using libusb-legacy -- so, if > you're having issues using it let me know & I'll see what I can do to help > out. That said, I've also used libusb1 with some success -- so, you might > have some other issue (e.g., a bad USB cable). - MLD I'll give libusb-legacy a try tonight (I don't have my USRP with me at work today). I'm sure I don't have a cable problem since I can transmit and receive signals with my USRP. Thanks for the suggestions! -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
So far, the only way I've been able to get gnuradio to link against libusb-legacy has been to uninstall libusb-1.0. Even when I overrode pkg-config by setting the USB_* variables, it'd still (apparently) link against libusb-1.0 and then crash at runtime when it couldn't find the "_usb_debug" symbol. Hopefully I'll be able to find a workaround for this since I'd like to use some other stuff that requires libusb-1.0, but in the mean time this seems to have fixed my usrper problem. I configured this way: ./configure \ CC=/usr/bin/gcc \ CXX=/usr/bin/g++ \ LDFLAGS="-F/opt/local/Library/Frameworks -L/opt/local/lib" \ CPPFLAGS="-I/opt/local/include -I/opt/local/include/qwt -I/opt/local/include/qwtplot3d" \ --with-fusb-tech=darwin Now usrper appears to be happy: ~/gnuradio% usrper -v load_standard_bits usrper: found unconfigured usrp; needs firmware. ~/gnuradio% usrper -v get_hash0 hash: ???7???g8!?_Md ~/gnuradio% usrper -v set_hash0 deadbeef ~/gnuradio% usrper -v get_hash0 hash: deadbeef ~/gnuradio% While I don't know what any of those usrper commands are actually doing, at least they seem to be not-crashing! -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP/gnuradio Issues in OS X
On Aug 24, 2010, at 4:58 PM, Michael Dickens wrote: > Hi Mark - I'm glad you got it working; if you installed all of the background > dependencies with MacPorts, compiling GNU Radio should be as simple as: > > [fix bootstrap] > ./bootstrap > ./configure Should be... but isn't. > with no other options. IIRC, the 3 primary environment variables you need to > have set are PATH (so that /opt/local/bin comes first), PYTHONPATH (so that > /opt/local/lib/python2.6/site-packages comes first), and PKG_CONFIG_PATH (so > that /opt/local/lib/pkgconfig comes first). You do not need to set > "--with-fusb-tech" at all; it will auto-detect. You also don't need to set > LDFLAGS as you have. Further, I don't think gr-qtgui is working on OSX just > yet, so you really don't need to set CPPFLAGS either. And, you can have > MacPorts select the CC and CXX for you via "gcc_select" -- so those aren't > necessary. The --with-fusb-tech probably isn't necessary for me since I temporarily uninstalled libusb-1.0, but with that installed I found it to be necessary to specify --with-fusb-tech=libusb1 to get it to work. Anyhting else would cause the USRP code to crash when it failed to find the _usb_debug symbol. I have /opt/local/lib in my path, but I found it necessary to force the compilation to use the native compilers in /usr/bin instead in order to find the Mac frameworks. I chose to do this with the CC and CXX variables instead of gcc_select in this case. I modified my site.py file so it wouldn't be necessary to add that site-packages directory to my PYTHONPATH. The CPPFLAGS and LDFLAGS variable settings were necessary to get gr-qtgui to build, though I don't know if it actually works yet. In particular, some of the code included qwt and qwtplot3d headers without specifying their subdirectories (i.e., vs. ), so I had to add the -I flags to get them to be found. I also had to add that -F flag for the linker to find the QtOpenGL framework. I don't know if there's something screwy about my system configuration, but that's what I had to do to get things to build and run. > My question now is whether or not the other tests you talked about work > (e.g., usrp_benchmark_usb.py). If that works, then you're good to go & can > play around with all the other pieces of GNU Radio & USRP. Ah, good question. I've already been playing with some of the scripts such as usrp_fft.pw, usrp_siggen.py and a few others, and with grc, but there have been a bunch of pieces that didn't work. I'll try the benchmark script now that I've fixed (?) the USB stuff... Success! It consistently gives me one USB under-run (I think; it prints "uU") at the beginning, but then runs and declares I can get 32MB/sec throughput. One of the other things that hasn't been working still isn't, but I think it's an unrelated error. When I run usrp_am_mw_rcv.py it complains: RuntimeError: gr_remez: insufficient extremals -- cannot continue > But, I'm glad you've gotten this far. - MLD Thanks! I didn't expect it to be entirely painless (particularly since I'm running not-Linux here), and I'll keep plugging along. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: making a small USRP board
On Aug 30, 2010, at 6:52 AM, William Cox wrote: > As of yet, I'm trying to figure out if reducing the size of the USRP1 baord, > by removing one of the transceivers, is feasible. I'm a GNURadio/USRP newbie > and I'm just going off looking at the pysical board and thinking I didn't > need half of it. Are you considering keeping the same form factor and connectors for the RF daughterboards (i.e., mounting regular RF daughterboards on a reduced-size USRP motherboard), or further shrinking the package size by integrating the RF and digital stuff onto a single, smaller board dedicated to a specific RF band? -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: making a small USRP board
On Aug 30, 2010, at 8:24 AM, William Cox wrote: > Right now I'm thinking the easiest thing would be to keep everything the > same, except remove the 2nd mixed-signal chip, and move the power circuit off > the board. > So, yes, same form factor for daughterboard connections. That seems like a lot of effort and expense to make something just a little bit smaller. Now, if you could make the equivalent of a USRP + WBX board about the size of a pack of playing cards, and powered from the USB port, that would be quite interesting! -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Warning in usrp_benchmark_usb.py
On Aug 30, 2010, at 8:15 AM, Federico Battaglia wrote: > in testing the USRP I came across several warnings. Can someone tell me what > they mean and if they are irrelevant? [...] > @ubuntu:/usr/share/gnuradio/examples/usrp$ ./usrp_benchmark_usb.py > Testing 2MB/sec... > Warning: Treating daughterboard with invalid EEPROM contents as if it were a > "Basic Tx." > Warning: This is almost certainly wrong... Use appropriate burn-*-eeprom > utility. > > > Warning: Treating daughterboard with invalid EEPROM contents as if it were a > "Basic Rx." > Warning: This is almost certainly wrong... Use appropriate burn-*-eeprom > utility. Those look relevant to me. Each RF daughterboard is supposed to have an EEPROM (memory chip) whose contents tell the gnuradio software what kind of board is installed. Your software is complaining that it couldn't identify the installed daughterboard(s), so their EEPROM(s) may need to be reprogrammed. There's some discussion of the EEPROMs here that might be helpful: http://gnuradio.org/redmine/wiki/gnuradio/UsrpFAQDBoards -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: making a small USRP board
Ah, I see. That sounds like a neat project. On Aug 30, 2010, at 10:44, William Cox wrote: > Mark, > Going from 36 sq-in to 18 sq-in is a big improvement for us. We'll be using > it on an underwater vehicle, and space is a premium. Your idea for a smaller > WBX board is cool, but would be a lot of work. > -William > > On Mon, Aug 30, 2010 at 11:44 AM, Mark J. Blair wrote: > > On Aug 30, 2010, at 8:24 AM, William Cox wrote: > > Right now I'm thinking the easiest thing would be to keep everything the > > same, except remove the 2nd mixed-signal chip, and move the power circuit > > off the board. > > So, yes, same form factor for daughterboard connections. > > That seems like a lot of effort and expense to make something just a little > bit smaller. Now, if you could make the equivalent of a USRP + WBX board > about the size of a pack of playing cards, and powered from the USB port, > that would be quite interesting! > > > > -- > Mark J. Blair, NF6X > Web page: http://www.nf6x.net/ > GnuPG public key available from my web page. > > > > > > ___ > 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] s/Eric/Tom/g
I'm new here, but I can already tell that GNU Radio is Really Cool Stuff. Thank you for your great contributions, and I welcome our new overlord! -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio via MacPorts Updated
On Sep 7, 2010, at 7:28 AM, Michael Dickens wrote: > I've updated the GNU Radio install via MacPorts to 3.3.0. I'm sorry that I'm so terribly late trying this out, but I got distracted from working with gnuradio stuff for a while. I finally got around to trying this tonight, and it seems to be working for me so far. Hooray! I'll probably put my efforts at perfecting a build from the git repository on hold for the time being, since i was mostly doing that to get around issues I had with the older MacPort version. Some details: * 2.66 GHz Intel Core 2 Duo MacBook Pro w/ 4G RAM, running 10.6.4. * All sorts of extra stuff installed under MacPorts previously to get the git codebase to build, so I'm not a good test case for dependencies on a fresh system. * I uninstalled the git codebase with "sudo make uninstall" to get it out of the way, then installed gnuradio from MacPorts. * usrper, usrp_fft.py, usrp_wfm_rcv.py and gnuradio-companion appear to be working correctly. Thank you very much for updating the MacPorts release, and I'll speak up if I find any problems or come up with any suggestion. Gack, I have about 200 messages to clear out from my discuss-gnuradio inbox now... :) -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] want to achieve the symbol rate to 270.833kb/s
On Sep 25, 2010, at 10:41 AM, dburg...@kestrelsp.com wrote: > We would have used 13 MHz, but the USRP-1 FPGA code fails to transmit for > clock rates below about 48 MHz. Does anybody know why this is? -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Strange side-band when transmitting using WBX on USRP1
On Oct 13, 2010, at 8:45 PM, Drew Read wrote: > We're having some problems with transmitting using the WBX board on a > USRP1 (not an old one). > We have a flow graph with a NULL source going into a NBFM, then > through a multiply_const and into the USRP. > At low frequencies (100MHz) the signal looks ok, but when we get up > passed 500MHz we can see/hear that what should be an unmodulated > carrier also has a single side-band (and is audible as a tone when > demodulated) . And by increasing the const in the multiply_const, we > can see our wanted signal getting stronger while the side-band remains > there at a constant level. That sounds (and looks) like an issue that I encountered yesterday with my USRP + WBX. I was using it to generate some test signals in the 1.5-1.7 GHz range, and I found that there was a constant spur about 1-2 kHz above the transmitter's center frequency. I also found that I could reduce its effects by playing with the signal level, transmitter gain and an external attenuator. For now, I think I can work around it by simply generating my test signals at an offset from the transmitter center frequency and adjusting the center frequency to put them back where I want them, thus moving the spur out of the middle of my test signal. > We've had a play with manually adjusting the DC offset of the USRP > sink, which seems to change the size of the side-band a bit, but we > don't really know what to do with that. I also found a bit of the transmitter center frequency bleeding through when I modulated it with no DC component. I haven't tried to mitigate this yet, but my workaround for the spur should also let me ignore this little bit of unwanted carrier for the time being. I presume that it's due to a small DC offset error in the DACs, based on the my observation of what appears to be a small (sub-LSB) DC error in the receiver ADCs. In my receive path, I found there to always be a received component at the tuned receiver frequency, and I found that I could null it out by adding a small (magnitude < 1.0) complex constant to the USRP source output before it passed to the rest of my receive chain. Over the course of a few hours and a power-cycle, I found that I had to readjust the constant once or twice. This little error is pretty negligible when receiving larger signals, but it was annoying while I was trying to look at some pretty weak signals. I may be able to swamp it out with some external gain, but I didn't have an LNA handy yesterday to try that. For the time being, I'm going to try to ignore these DC components in both the receiver and transmitter by simply offsetting the LO a bit from the signal that I want to transmit or receive. I have to do some more tests tomorrow using my USRP as a signal generator, so I hope this will work. In the longer term, I'm interested in looking into whether there's a better approach to trimming out any DC offsets in the DACs and ADCs. I'm also interested in learning more about that unwanted spur in the transmit output (particularly since it's quite a bit larger than the component that appears to be caused by a small DC error). > We've tried several USRPS and several WBX boards and seen the same > problem on all of them. > We don't see it on the USRP2. Interesting. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help with USRP wire?
On Oct 17, 2010, at 2:07 AM, Thunder87 wrote: > Which type is this small wire, which connects USRP daughterboard with > antenna? The coaxial cables that came with my USRP set appear to be made of type RG-316 cable. The LFTX and LFRX boards have SMA connectors. I think that the antenna connectors on the WBX board are MMCX connectors. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WBX and USRP1 on GnuRadio 3.3
On Oct 17, 2010, at 11:27 PM, Ed Criscuolo wrote: > Is it possible to use a WBX daughtercard on a USRP1 with the > 3.3 stable release of GnuRadio Yes. I am presently using my WBX in my USRP with the 3.3 release of GNU Radio via macports on my Mac. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum antenna input voltage on LFRX
On Dec 24, 2010, at 3:37 PM, Nick Smith wrote: > I've looked through the mailing list archive and found a few messages related > to this, but they referred to signal generators and power in dBm. > In my case, I plan to use it with an antenna and eventually a pre-amp. > However, I've found that by measuring the voltage from even a 3ft (90cm) > antenna using a multimeter with a probe on the antenna and a probe to ground > gives a reading of four volts RMS. With a 25ft (7.6m) antenna, I can slightly > light up an LED (I don't remember the voltage), and with a 100ft (30.5m) > antenna, I got about 140V. A multimeter has very high input impedance. If you attach a 50 ohm resistor(*) between the antenna and ground to simulate the input impedance of a radio receiver, then you should no longer see a measurable voltage with a multimeter. Also, a multimeter won't properly measure RF voltage. You're probably just seeing 60 Hz power line noise, unless you're very close to a high-powered transmitter. If there's a 100kW broadcast transmitter next door, then all bets are off. :) (*) or any other value you can get your hands on between around 25 and 500 ohms -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fw: Need Advice for SDR choice
On Jan 2, 2011, at 1:31 PM, Andrew Rich wrote: > I have a MacBook PRO I7 it can run OS X or windows I have been successfully using the Ettus Research USRP with LFRX, LFTX and WBX boards on my 17" MacBook Pro under OS X (Snow Leopard). Installing the software portion is pretty easy: Install the MacPorts package, then run "sudo port install gnuradio" in a terminal window. You can play with the gnuradio software to see if it's right for you before committing to buying any hardware, since it can use the audio device and/or data files as a source/sink, or even run entirely simulated flowgraphs. I haven't used any gnuradio-based canned ham radio USB/LSB/whatever applications (if any exist). I have successfully received 2m FM transmissions with one of the examples that comes with the gnuradio distribution. I've mostly used my hardware to generate fairly simple test signals for other radio hardware (i.e., a number of simultaneous CW tones within a fairly narrow bandwidth) and simple spectrum analysis. At the moment, I'm playing around with writing blocks and flowgraphs for sending and receiving high-speed Morse code, due to my current interest in devices such as the AN/GRA-71 code burst keyer (*). This is all pretty simple stuff that the USRP hardware is overkill for, but I'm just beginning to learn about gnuradio and SDR design in general. Based on what you've stated so far, I think that a USB-based USRP with a WBX board and the gnuradio software should work nicely for you, and you can work with it directly under OS X. You may also want to get an RFX2400 board to hit the 2.4GHz band (I have one, but haven't done much with it yet). This board combination will leave a hole between 2.2GHz and 2.3GHz. If I recall correctly, I've generally set my hardware decimation to limit sampled bandwidth to about 2 MHz in order to avoid USB over-runs and/or under-runs. I've been able to look at a 4 MHz bandwidth with occasional over/under-runs. The occasional over/under-run doesn't seem to cause problems when just visually watching an FFT plot (i.e., to look for activity within a band). I don't know if the Ethernet-based USRP platforms work on Macs yet. (*) More info here if you're curious: http://www.militaryradio.com/spyradio/gra71.html These are available (though rare) on the surplus market, but I'm unaware of any of the original receiving equipment that has made it out to the hands of collectors. A SDR setup seems like a natural way to handle receiving the code burst and then either playing it back at low speed for manual decoding, or automatically decoding the transmission at normal speed. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: "Open-Hardware"
On Jan 11, 2011, at 5:15 PM, Patrick Strasser wrote: > The only problem is that Microsoft promised in 2005 to implement UAC2, > but "forgot" to do it until now. BTW they have a big mess with USB, as > Daniel Mack, Linux UAC2 author wrote: "Inevery cruel reincarnation of > their OS, it has different issues." I spare you the terrible details an > leave out the rest of his summary. I have to give MS credit for backwards-compatibility, though. As of Windows 7, they still support mis-identifying a GPS receiver as a serial port mouse, thus causing all sorts of delightful hijinks with the mouse pointer. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] re: Low cost hardware option
On Jan 12, 2011, at 9:17 PM, Jamie Morken wrote: > That sounds like a pretty good system. I should say right off the bat that > if I am involved to make this I would want to add a clause in the open source > hardware license to not allow the hardware to be used for military > applications. I think it is important to state this at the start before I > would get involved working on a new gnu radio board. If people can live with > that requirement I am happy to do the layout work. How would you define "military applications"? I collect surplus military gear as a hobby, and I'm presently working on a GNUradio-based implementation of a decoder for high-speed Morse code transmissions from my vintage AN/GRA-71 code-burst keyer (for which key pieces of the original reception hardware is unobtainium). I'm presently working entirely in simulation, but my USRP will get pressed into service for this before long. Would you consider that application to be "military"? Or how about if I were to use the hardware to intercommunicate with other military radio hardware (such as any of the countless surplus military radios used on the ham radio bands every day)? What if I throw it in my HMMWV and use it on a ham band during a Veteran's Day parade? What if a soldier wishes to use the hardware on-base for MARS activities? If any such things would be considered "military", then I'd neither use nor contribute towards any hardware that's shackled by such a silly restriction. Furthermore, I doubt very much that the restriction would be at all enforceable. Personally, I don't think that any prior restraint placed upon end use of the hardware (beyond the requirement to keep derivative works open in most cases) is compatible with the very libertarian principles of the open software movement. I've released code under GPL. I thus place certain limited restrictions on the use of the code to keep it open, but beyond those limited restrictions, it's really none of my business to tell people what they can and can't do with it. If I wanted to control its end use to that degree, then I wouldn't have released it in the first place. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Who actually *does* use GNU Radio?
I've been using GNU Radio + USRP as general RF test equipment, and GNU Radio by itself as a simulation environment for learning about SDR. I'm interested in the ongoing discussion of alternate RF hardware platforms for use with GNU Radio. While I'm quite happy with my USRP hardware, I can see plenty of room in the SDR user base for hardware with different feature sets and price points. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IS USRP safe for the human body?
On Feb 8, 2011, at 5:07 AM, Nick Othieno wrote: > Do I sense a Marie Curie in the making? Remember, kids: It's not the volts that kill you. It's the amps. -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] choice of antenna and daughter board
On Mar 3, 2011, at 2:34 AM, ranjini ram wrote: > can any body tell which is the antenna and daughter board that has to be used > in receiving FM...which is the best TVRX of Basic RX? Any antenna or daughter board can receive FM transmissions. FM is just a modulation type, and it can be used at any frequency, and with other variations such as different amounts of frequency deviation. The point of a software-defined radio is that it can send and/or receive *any* modulation type within its constraints of center frequency, bandwidth, and (in some cases) latency. The question is, what frequency range do you need to be able to receive? For example, FM broadcast band transmissions (i.e., what a car stereo can receive) occur between 88 MHz and 108 MHz in the US. FM amateur radio or commercial radio transmissions might occur anywhere between around 27 MHz and well over 1 GHz. The frequency range(s) you need to cover will determine which daughter board(s) might work for you. Your antenna selection will depend on the frequency range(s) you need to cover, as well as other constraints such as required polarization, directional gain, etc. So, what exactly are you interested in receiving? -- Mark J. Blair, NF6X Web page: http://www.nf6x.net/ GnuPG public key available from my web page. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
