[Discuss-gnuradio] USRP HF setup
Has anyone had Any success with amateur HF with the usrp? I would like to purchase a basic rx and maybe a basic tx for monitoring the hf amateur bands. I know i need lownoise amplifaction and filtering but not sure what to get. I know i could just use the IF output of transciever, but im not sure if thats what i wanna do. if anyone has setup something i would be curious to hear about it thanks, Dave Sent from my iPad ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP HF setup
On Sat, Sep 25, 2010 at 8:38 AM, Davek dave_k_...@yahoo.com wrote: Has anyone had Any success with amateur HF with the usrp? I would like to purchase a basic rx and maybe a basic tx for monitoring the hf amateur bands. I know i need lownoise amplifaction and filtering but not sure what to get. I know i could just use the IF output of transciever, but im not sure if thats what i wanna do. if anyone has setup something i would be curious to hear about it thanks, Dave Hi Dave, I have had the USRP1 and LFRX connected to a Butternut HF2V antenna with 30m and 160m extensions using ~30 meters of RG213 coax. No preamp or filter or anything else, and I could hear lots of SSB/CW traffic (even DX) and AM broadcast. I have two video recordings: AM on medium waves: http://www.youtube.com/watch?v=317Iu6HRA0w Hamradio SSB/CW on 7MHz: http://www.youtube.com/watch?v=t1FEq6h7Z1c I have measured the sensitivity in CW to 3-4 microvolts so yeah, a preamp would be useful above 10 MHz. I think one can get these acrtive whip antennas for shortwaves, I guess the filter and preamp could be used with a real antenna. I have not tried the transmitter on the air. For sure that will need power amplifier and low pass filters! Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP HF setup
Alex, thanks for the reply. I have seen most of your vids, they are excellent. Your site is full of great information. If i didnt get any replies, i was actually gonna mail u off list ... Anyway, i will consider this antenna, it looks to be relatively simple, which i like :) dave Sent from my iPad On Sep 25, 2010, at 6:14 AM, Alexandru Csete oz9...@gmail.com wrote: On Sat, Sep 25, 2010 at 8:38 AM, Davek dave_k_...@yahoo.com wrote: Has anyone had Any success with amateur HF with the usrp? I would like to purchase a basic rx and maybe a basic tx for monitoring the hf amateur bands. I know i need lownoise amplifaction and filtering but not sure what to get. I know i could just use the IF output of transciever, but im not sure if thats what i wanna do. if anyone has setup something i would be curious to hear about it thanks, Dave Hi Dave, I have had the USRP1 and LFRX connected to a Butternut HF2V antenna with 30m and 160m extensions using ~30 meters of RG213 coax. No preamp or filter or anything else, and I could hear lots of SSB/CW traffic (even DX) and AM broadcast. I have two video recordings: AM on medium waves: http://www.youtube.com/watch?v=317Iu6HRA0w Hamradio SSB/CW on 7MHz: http://www.youtube.com/watch?v=t1FEq6h7Z1c I have measured the sensitivity in CW to 3-4 microvolts so yeah, a preamp would be useful above 10 MHz. I think one can get these acrtive whip antennas for shortwaves, I guess the filter and preamp could be used with a real antenna. I have not tried the transmitter on the air. For sure that will need power amplifier and low pass filters! Alex ___ 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] want to achieve the symbol rate to 270.833kb/s
The communication protocol that you are looking into should have a predefined symbol rate. At the very least in the pilot sequence of a frame. --Colby 2010/9/18 intermilan tianxia...@hotmail.com hi Tom: thank you for your answer,I get it .Besides, how do we know the symbol rate if the data in the air?what did you do to measure the symbol rate? Thank you in advance From: trondeau1...@gmail.com Date: Fri, 17 Sep 2010 08:21:23 -0400 Subject: Re: [Discuss-gnuradio] want to achieve the symbol rate to 270.833kb/s To: tianxia...@hotmail.com CC: discuss-gnuradio@gnu.org 2010/9/17 intermilan tianxia...@hotmail.com: hi Tom: I can not find the examples what you asked me to look for.so what the version of your Gnuradio? Mine is 3.2.2. Besides, I still wonder why I can not use the resampler block in the /gnuradio-core/src/python/gnuradio/blks2impl in which I can set the value of the interpolation and decimation.and the program will automatic to set the parameters of the filter I need.I think it is capable. So can you tell some specific reasons? thank you You'll need either GNU Radio 3.3.0 or the latest checkout from git. Then yes, you can use the rational resampler. I misunderstood what you were saying in your original email. I thought you were having problems using the rational resampler to make the values work out properly. The nice thing about the arbitrary resampler is that you don't have to find a valid set of integers for the interp/decim to get your sample rate; instead, you pass it a real number to get out the sample rate that you want. But running through the numbers, it looks to me like you'll get the desired sample rate. So yes, that should work. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
The problem being that /usr/local/lib/pkgconfig isnt honoring the users prefix and possibly libdir. Perhaps we can still make this right... Does this patch work for you? -Josh Still no worky. Must set PKG_CONFIG_PATH manually. I confirmed that the patch had been applied to the .m4, then did a make distclean then a ./bootstrap, then a ./configure. The configure fails to find UHD unless I explicitly set PKG_CONFIG_PATH. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Application run longevity
I have an application that has run for 12 days without wedging--this exact application (no changes) used to hang after no more than 3 days, and it uses only audio source/sinks. So, some combination of up-to-date Gnu Radio, and up-to-date system patches appears to have cured (at least in this instance) applications hanging after a few days. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
This turns out to be a bug in gnuradio configure - when --prefix is not
specified with ./configure, the ${prefix} variable is set to NONE
http://www.mail-archive.com/autoc...@gnu.org/msg15772.html
The following code with yeild a PKG_CONFIG_PATH of NONE/lib/pkgconfig
dnl add ${prefix}/lib${gr_libdir_suffix}/pkgconfig to the head of the
PKG_CONFIG_PATH
if test x${PKG_CONFIG_PATH} = x; then
PKG_CONFIG_PATH=${prefix}/lib${gr_libdir_suffix}/pkgconfig
else
PKG_CONFIG_PATH=${prefix}/lib${gr_libdir_suffix}/pkgconfig:${PKG_CONFIG_PATH}
fi
export PKG_CONFIG_PATH
if may be more appropriate to do the following somewhere at the top of
configure.ac
if test ${prefix} = NONE; then
prefix=${ac_default_prefix}
fi
gr_standalone.m4 and configure.ac both seem to have this issue
-Josh
On 09/25/2010 09:32 AM, Marcus D. Leech wrote:
The problem being that /usr/local/lib/pkgconfig isnt honoring the
users prefix and possibly libdir. Perhaps we can still make this
right... Does this patch work for you?
-Josh
Still no worky. Must set PKG_CONFIG_PATH manually. I confirmed that
the patch had been applied to the .m4, then did a make distclean
then a ./bootstrap, then a ./configure. The configure fails to
find UHD unless I explicitly set PKG_CONFIG_PATH.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] very god news
very god news i just bought an Iphone 4 from this company : link-theworld.com all new original . i like it much they also have thousands of other products welcome to the site and enjoy here !! ___ 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
This is part of the reason we used a 52 MHz clock for the public release of the OpenBTS GSM stack. It makes 13/48 MHz rational. We would have used 13 MHz, but the USRP-1 FPGA code fails to transmit for clock rates below about 48 MHz. If you use the stock 64 MHz clock you will need a polyphase resampler for most telecom applications. You will also have wicked temperature drift problems. Sent from my Verizon Wireless BlackBerry -Original Message- From: Colby Boyer colby.bo...@gmail.com Sender: discuss-gnuradio-bounces+dburgess=kestrelsp@gnu.org Date: Sat, 25 Sep 2010 09:27:44 To: intermilantianxia...@hotmail.com Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] want to achieve the symbol rate to 270.833kb/s ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
This turns out to be a bug in gnuradio configure - when --prefix is
not specified with ./configure, the ${prefix} variable is set to
NONE
Listen guys, you may not like this behavior, but it's not a bug.
If you read the makefile standards, it's to allow a package to be
installed into a different location at make install time.
http://www.mail-archive.com/autoc...@gnu.org/msg15772.html
The following code with yeild a PKG_CONFIG_PATH of NONE/lib/pkgconfig
dnl add ${prefix}/lib${gr_libdir_suffix}/pkgconfig to the head of the
PKG_CONFIG_PATH
if test x${PKG_CONFIG_PATH} = x; then
PKG_CONFIG_PATH=${prefix}/lib${gr_libdir_suffix}/pkgconfig
else
PKG_CONFIG_PATH=${prefix}/lib${gr_libdir_suffix}/pkgconfig:${PKG_CONFIG_PATH}
fi
export PKG_CONFIG_PATH
There definitely shouldn't be any PKG_CONFIG_PATH special case
handling for anything in grc_component_name.m4.
A ton of effort was put into making the building system work reliably
and consistently (mostly by Michael Dickens). A lot of the details
are quite subtle, and the effort took a long time to stabilize, and
has proven itself to work on a wide variety of OS's and distributions.
All of the grc_component_name.m4's should follow the same pattern.
There shouldn't be any divergence in the boilerplate.
I removed the offending code because it was causing my build to break,
and noticed at that time that it shouldn't have been there in the
first place.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
There definitely shouldn't be any PKG_CONFIG_PATH special case handling for anything in grc_component_name.m4. A ton of effort was put into making the building system work reliably and consistently (mostly by Michael Dickens). A lot of the details are quite subtle, and the effort took a long time to stabilize, and has proven itself to work on a wide variety of OS's and distributions. All of the grc_component_name.m4's should follow the same pattern. There shouldn't be any divergence in the boilerplate. I removed the offending code because it was causing my build to break, and noticed at that time that it shouldn't have been there in the first place. Eric Fair enough, Eric. So do you suggest another approach that allows boostrap/configure/make to just work, or simply more notes about this in the build instructions when you're using UHD? -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
On Sat, Sep 25, 2010 at 03:09:47PM -0400, Marcus D. Leech wrote:
There definitely shouldn't be any PKG_CONFIG_PATH special case
handling for anything in grc_component_name.m4.
A ton of effort was put into making the building system work reliably
and consistently (mostly by Michael Dickens). A lot of the details
are quite subtle, and the effort took a long time to stabilize, and
has proven itself to work on a wide variety of OS's and distributions.
All of the grc_component_name.m4's should follow the same pattern.
There shouldn't be any divergence in the boilerplate.
I removed the offending code because it was causing my build to break,
and noticed at that time that it shouldn't have been there in the
first place.
Eric
Fair enough, Eric. So do you suggest another approach that allows
boostrap/configure/make to just work, or simply more notes
about this in the build instructions when you're using UHD?
This really doesn't have anything to do with UHD. You'd see
the same problem with any other dependency installed outside of
/lib{,64} or /usr/lib{,64}
Just as you have to set your PYTHONPATH for stuff in /usr/local...,
set your PKG_CONFIG_PATH for stuff in /usr/local/lib{,64}
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
On 09/25/2010 12:01 PM, Eric Blossom wrote:
On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
This turns out to be a bug in gnuradio configure - when --prefix is
not specified with ./configure, the ${prefix} variable is set to
NONE
Listen guys, you may not like this behavior, but it's not a bug.
If you read the makefile standards, it's to allow a package to be
installed into a different location at make install time.
Thats fine, but is it fine that configure.ac sets PKG_CONFIG_PATH to
NONE/lib/pkgconfig when --prefix is not specified. Thats not a problem?
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
Fair enough, Eric. So do you suggest another approach that allows
boostrap/configure/make to just work, or simply more notes
about this in the build instructions when you're using UHD?
The issue being that all the gnuradio dependencies are distribution
installable (on linux) so you dont need to set special paths and
environment variables. However, UHD is not ready to be handed out as
rpms and debs (though it can be) so it may need special paths set to use
on operating system X.
However, it looks like gnuradio wants to set your PKG_CONFIG_PATH to
include the ${prefix}/lib${lib_suffix}/pkgconfig. So, if you happen to
use the same prefix and lib_suffix as you built for UHD, gnuradio should
be able to find the uhd.pc file without you needing to set
PKG_CONFIG_PATH by hand.
The problem with this being, if --prefix is not set, gnuradio sets this
to NONE/lib${lib_suffix}/pkgconfig which isnt going to work. Maybe
${ac_default_prefix} can be used when ${prefix} is set to NONE
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
On Sat, Sep 25, 2010 at 12:23:19PM -0700, Josh Blum wrote:
On 09/25/2010 12:01 PM, Eric Blossom wrote:
On Sat, Sep 25, 2010 at 10:24:18AM -0700, Josh Blum wrote:
This turns out to be a bug in gnuradio configure - when --prefix is
not specified with ./configure, the ${prefix} variable is set to
NONE
Listen guys, you may not like this behavior, but it's not a bug.
If you read the makefile standards, it's to allow a package to be
installed into a different location at make install time.
Thats fine, but is it fine that configure.ac sets PKG_CONFIG_PATH to
NONE/lib/pkgconfig when --prefix is not specified. Thats not a
problem?
I agree with you it's not exactly right.
I'm not sure about the right action.
This issue should probably go onto the list of things to be considered
in the grand build restructuring that was discussed by some of us a
couple of weeks ago.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
On Sat, Sep 25, 2010 at 12:32:36PM -0700, Josh Blum wrote:
Fair enough, Eric. So do you suggest another approach that allows
boostrap/configure/make to just work, or simply more notes
about this in the build instructions when you're using UHD?
The issue being that all the gnuradio dependencies are distribution
installable (on linux) so you dont need to set special paths and
environment variables. However, UHD is not ready to be handed out as
rpms and debs (though it can be) so it may need special paths set to
use on operating system X.
However, it looks like gnuradio wants to set your PKG_CONFIG_PATH to
include the ${prefix}/lib${lib_suffix}/pkgconfig. So, if you happen
to use the same prefix and lib_suffix as you built for UHD, gnuradio
should be able to find the uhd.pc file without you needing to set
PKG_CONFIG_PATH by hand.
The problem with this being, if --prefix is not set, gnuradio sets
this to NONE/lib${lib_suffix}/pkgconfig which isnt going to work.
Maybe ${ac_default_prefix} can be used when ${prefix} is set to NONE
That would probably be better than what we've got.
Independent of the use case you brought up, there's a couple of other
places we run afoul the same issue (prefix == NONE). IIRC it gets
baked into some C/C++ strings somewhere too.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Announcement - September 23rd 2010
I agree with you it's not exactly right.
I'm not sure about the right action.
This issue should probably go onto the list of things to be considered
in the grand build restructuring that was discussed by some of us a
couple of weeks ago.
Autotools is trying to be helpful by setting the unspecified prefix to
NONE during configure. But since gnuradio is using it as if it was
always set I suggest we do the following at the top of configure.ac
if test ${prefix} = NONE; then
prefix=${ac_default_prefix}
fi
We can put it on the next branch and hope it fixes more things than it
breaks... at least until the grand rebuild structuring comes along. :-)
-Josh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR
In the April/May 2010 SARA Journal, Marcus Leech had an article entitled Building an SDR SID Receiver in an Afternoon which was highly information and inspirational. While my sound card only goes to 48 KHz sampling, I decided to try his implementation and in terms of entry into GRC, things have gone well except for the taps and their variables and a non-cooperative import box. While the screenshot in the article shows variables of ID: c1..4_taps and value of gr.firdes.complex_b... the text hints are band_pass and the variable blocks do accept this though it is displayed as value: functio 0x8801ae4 , however, the Decimating FIR Filters complain about: Problem 1 Param - Taps(taps): Expression [function complex_band_pass at 0x8801ae4] is invalid for type complex vector. no matter which type I specify for the filter. Problem 2 import :notchfilt Param - Import(import): Bad import syntax: notchfilt. have tried notchfilter etc. but without success. Not sure if this is related to Problem 1? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 1pps synchronization delay
We are trying to determine how much delay there is between the 1pps pulse and when the samples come out properly time tagged. Using a GPS timing receiver we connected up the 10MHz clock and 1pps to the USRP2. The software is set up to reset on the next 1pps pulse. With a GPS software receiver we determined that there is a delay of 3 - 6 microseconds which curiously was 3 with a smaller decimation and 6 at a higher decimation. We've checked over the setup and can't find any reason for this. Does anyone have any ideas? Thanks, Cliff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Decimating FIR Filter Taps and gr.firdes.complex_band_pass incompatibility - Marcus SARA SID SDR
In the April/May 2010 SARA Journal, Marcus Leech had an article entitled Building an SDR SID Receiver in an Afternoon which was highly information and inspirational. While my sound card only goes to 48 KHz sampling, I decided to try his implementation and in terms of entry into GRC, things have gone well except for the taps and their variables and a non-cooperative import box. While the screenshot in the article shows variables of ID: c1..4_taps and value of gr.firdes.complex_b... the text hints are band_pass and the variable blocks do accept this though it is displayed as value: functio 0x8801ae4 , however, the Decimating FIR Filters complain about: Problem 1 Param - Taps(taps): Expression [function complex_band_pass at 0x8801ae4] is invalid for type complex vector. no matter which type I specify for the filter. Problem 2 import :notchfilt Param - Import(import): Bad import syntax: notchfilt. have tried notchfilter etc. but without success. Not sure if this is related to Problem 1? Kind Regards, John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio John, let me send you the latest TAR image of my SID receiver work--it has progressed quite a bit beyond that article, and Gnu Radio has also changed since I wrote that article. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 1pps synchronization delay
Does this describe what you are seeing? http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg26328.html On 09/25/2010 08:50 PM, Kelley, Clifford W wrote: We are trying to determine how much delay there is between the 1pps pulse and when the samples come out properly time tagged. Using a GPS timing receiver we connected up the 10MHz clock and 1pps to the USRP2. The software is set up to reset on the next 1pps pulse. With a GPS software receiver we determined that there is a delay of 3 - 6 microseconds which curiously was 3 with a smaller decimation and 6 at a higher decimation. We've checked over the setup and can't find any reason for this. Does anyone have any ideas? Thanks, Cliff ___ 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
