Re: [Discuss-gnuradio] access_code: AKA

its a pattern that the packet deframer looks for to identify the start
of a received packet.

-Josh

On 05/31/2010 10:34 PM, Juan Quiroz wrote:
> Hi all
>
> What is it for param access_code: AKA sync vector in blks2.mod_pkts()??? I'm confused!
>
> thanks in advance
>
> Juan Quiroz
>
>
>
>
> _______________________________________________
> 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] access_code: AKA

Hi all

What is it for param access_code: AKA sync vector in blks2.mod_pkts()??? I'm confused!

thanks in advance

Juan Quiroz

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Hi all, how to use usrp and gnuradio support triangulation to locate a cell phone

On May 31, 2010, at 8:49 PM, John Wu wrote:

> hi Harley,
> I think I can bypass establishing communication with the cell phone I want to track, I can use app like airprobe to sniff the cell phone radio. So now the main task is find a good method to locate it. For now there are two methods. First is use three receiver receive the TDOA and use hyperbolic to locate the cell phone. this method need the three receivers synchronize the timer very accurate. the second is use two antenna arrays to use AOA to locate the cell phone, you have mentioned that you have support the antenna arrays in usrp to locate BTS. I want to build my receiver as a handset but if I choose AOA method the distance may be several meters between two antennas in a antenna array. So if it possible to reduce the distance between two antennas in a antenna array and keep the location accuracy? What is the smallest distance?

You are in a different world with a handheld device, my application has the array mounted on the belly of an aircraft so my worries are not with the antenna since I have lots of room for element spacing. The literature abounds with articles on direction finding techniques and what you are hoping to do is not out of the ordinary, but I am afraid you are on your own in that regard.

All that I have at this juncture, besides the fact that I have the software working on a virtual machine, is the explanation of how the unused GPIO ports can be accessed, which is essential for the antenna control that I require. We are on break right now, but next week I have some surprises in store for some of my unwitting students...perhaps they will post here as the system evolves.

Harley

CONFIDENTIALITY: Any information contained in this e-mail (including attachments) is the property of The State of Texas and unauthorized disclosure or use is prohibited. Sending, receiving or forwarding of confidential, proprietary and privileged information is prohibited under Lamar Policy. If you received this e-mail in error, please notify the sender and delete this e-mail from your system.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] read_aux_adc

Thanks for you reply, After reading the code, I think the argument 1,0 should be right.

But the result is strange. when there isn't a sender , the value returned is always 12. While there is a sender and the distance between sender and receiver is less than 1m, the value returned is between 0~24 (maybe less than 12), no matter what the tx-amplitude of sender is. Does the result make sense?

Thanks a lot.

P.S.

the result with a sender:

4 24 8 20 24 16 20 20 20 8 8 20 16 20 20 16 4 12 24 0 20 24 8 20 0 8 12 16 0 16 4;

the result without a sender:

12 12 12 12 12 12 12 12 12 12 12 12 12 12

2010/6/1 Eric Blossom <eb@comsec.com>

On Mon, May 31, 2010 at 04:42:47PM +0800, jf w wrote:
> I'm using RFX2400 daughterboard on side B, my arguments are  slot=2
> which_adc = 0 ,and I'm calling it from python.
>
> Your question inspire me that my arguments may be wrong. I think the slot
> argument should be 3(SLOT_RX_B), but I don't know the meaning of which_adc
> and how to set it.
>
> There are two aux_adc on one ad9862:aux_adc_a and aux_adc_b , but there are
> four pins : aux_adc_a1,aux_adc_a2, aux_adc_b1 and aux_adc_b2. But what is
> the input of the signal on these pins?
>
> Thanks a lot.
>

 /*!
  * \brief Read auxiliary analog to digital converter.
  *
  * \param which_side  [0,1] which d'board
  * \param which_adc   [0,1]
  * \returns value in the range [0,4095] if successful, else READ_FAILED.
  */
 virtual int read_aux_adc (int which_side, int which_adc) = 0;

Try

 v = u.read_aux_adc(1, 0)

I think the RSSI is on adc 0, but not 100% sure.

Eric

--
Thanks,
Jianfei
BUAA

Re: [Discuss-gnuradio] GNU Radio final release candidate 3.3.0-rc3 available for download

On Mon, May 31, 2010 at 3:00 PM, Michael Dickens <mlk@alum.mit.edu> wrote:
> 3.3.0-rc3 still passes "make check" on OSX; I can't test further, really,
> but previous candidates did work so this one probably does too.  Still does
> not pass "make distcheck"; errors on in gr-qtgui, as it did before (see
> below for error message).  BTW> gr-qtgui is not enabled; as before the Qt
> stuff is installed under strange names & hence not found.  Either way, the
> error below should be avoidable; I don't have time to work on this, and it's
> not critical for the release of 3.3.0 ... but it should be in the queue to
> be corrected. - MLD
>
> [snip]
> /bin/rm -f .deps/qtgui.d
> cp .deps/qtgui.Std .deps/qtgui.d
> echo "" >> .deps/qtgui.d
> /opt/local/bin/gsed -e '1d;s, \\,,g;s, ,,g' < .deps/qtgui.Std | \
>                awk '{ printf "%s:\n\n", $0 }' >> .deps/qtgui.d
> /bin/rm -f .deps/qtgui.Std
> touch .deps/qtgui-generate-stamp
> DQT_SHARED -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -p \
>   ../../../../gr-qtgui/src/lib \
>   ../../../../gr-qtgui/src/lib/spectrumdisplayform.h \
>   -o spectrumdisplayform_moc.cc
> make[3]: DQT_SHARED: Command not found
> make[3]: [spectrumdisplayform_moc.cc] Error 127 (ignored)
> [snip]

Ok, I have reproduced this problem on my machine. I know what's going
wrong. Now it's a matter of figuring out the right solution to it...

Tom

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Hi all, how to use usrp and gnuradio support triangulation to locate a cell phone

hi Harley,
I think I can bypass establishing communication with the cell phone I want to track, I can use app like airprobe to sniff the cell phone radio. So now the main task is find a good method to locate it. For now there are two methods. First is use three receiver receive the TDOA and use hyperbolic to locate the cell phone. this method need the three receivers synchronize the timer very accurate. the second is use two antenna arrays to use AOA to locate the cell phone, you have mentioned that you have support the antenna arrays in usrp to locate BTS. I want to build my receiver as a handset but if I choose AOA method the distance may be several meters between two antennas in a antenna array. So if it possible to reduce the distance between two antennas in a antenna array and keep the location accuracy? What is the smallest distance?

On Wed, May 26, 2010 at 10:22 PM, Harley Myler <h.myler@lamar.edu> wrote:

On May 26, 2010, at 5:25 AM, John Wu wrote:

> Harley Thanks
> I find another way call hyperbolic location method that is more accurate to locate a cell phone. and what u said is correct, I must first get a phone's communication. Now the easier way what I know is using openbts and usrp build a gsm bts to communicate with cell phone. Am I right?

That would be a good start since most of the complicated part (handset to USRP link), IMO, is done.

Harley

CONFIDENTIALITY: Any information contained in this e-mail (including attachments) is the property of The State of Texas and unauthorized disclosure or use is prohibited. Sending, receiving or forwarding of confidential, proprietary and privileged information is prohibited under Lamar Policy. If you received this e-mail in error, please notify the sender and delete this e-mail from your system.

Re:Re: [Discuss-gnuradio] usrp mux question

thanks Thomas!
i didn't state it clearly .i want to realize a MIMO system ,so I use two channels .and my daughterboards are RFX2400 MIMO B .
and another problem appears。in the receiver ,since the two channels receive the same signal simultaneously，i thought the two received signals from the two channels should be more or less the same(though they may go through different shading).but through the graph i find the signal from channel two seems 1/4 λ ahead of that from channel one<br><br>在2010-05-31 23:43:54，"Thomas Tsou" <ttsou@vt.edu> 写道：
>2010/5/31 weizhongshan <weizhongshan_1@163.com>:
>> hello every !
>> i use one usrp to transmit complex gr_sin_wave,and use another two_channel
>> usrp as the receiver.
>> i thought the mux should be set to "32103210",but when i did this ,i got
>> nothing but noisy .then i changed the mux to "33221100",i got the ecpected
>> orthogonal sin and cos wave .that confuses me
>
>What is your daughterboard setup and why are you using 2 channels?
>With 2 channels, the default "32103210" value uses all four ADC's and
>the first 2 DDC's. It sounds like you only want to read one channel
>and output separated I and Q components.
>
> Thomas

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: if only there was a way to fix those damn copyright dates on the tops of files...

its in git with some changes, enjoy!

http://gnuradio.org/cgit/jblum.git/commit/?h=fix_co_years

-Josh

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] if only there was a way to fix those damn copyright dates on the tops of files...

#!/usr/bin/env python

import re
import subprocess

def command(*args): return subprocess.Popen(args, stdout=subprocess.PIPE).communicate()[0]

def is_gnuradio_co_source(lines):
for line in lines[:20]:
if 'GNU Radio is free software' in line: return True
return False

def get_gnuradio_co_line(lines):
for i, line in enumerate(lines[:5]):
if 'Copyright' in line and 'Free Software Foundation' in line: return line, i
return None

if __name__ == "__main__":
#get recursive list of files in the repo
for file in command('git', 'ls-tree', '--name-only', 'HEAD', '-r').splitlines():
lines = open(file).readlines()
if not is_gnuradio_co_source(lines): continue

#extract the years from the git history
years = set(map(
lambda l: int(l.split()[-2]),
filter(
lambda l: l.startswith('Date'),
command('git', 'log', '--sparse', '--date=default', file).splitlines(),
),
))

#extract line and line number for co line
try: line, num = get_gnuradio_co_line(lines)
except: continue

#extract years from co string
co_years_str = re.match('^.*Copyright (.*) Free Software Foundation.*$', line).groups()[0]
co_years = set(map(int, co_years_str.split(',')))

#update the years if missing any
all_years = co_years.union(years)
if all_years != years:
print '%s missing %s'%(file, all_years - years)
new_text = ''.join(lines[:num] + [line.replace(co_years_str, ', '.join(map(str, all_years)))] + lines[num+1:])
open(file, 'w').write(new_text)

-Josh

Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc1 tarballs available for download

On Fri, May 28, 2010 at 07:36, Arturo Rinaldi <arty.net2@yahoo.it> wrote:

> i'm experiencing this problem in building on ubuntu 9.10 the 3.3 RC1

Could you try this again with the recently posted 3.3.0-rc3 tarballs?
I don't see how anything might affect this, but it would be good to
get another data point.

Johnathan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Output not showing in GRC

On Mon, May 31, 2010 at 14:57, Sammour <samy-1983@live.com> wrote:

> However, when I
> install my block in GRC, I connect the output to a file sink that stores
> nothing! I also tried to plot the magnitude of the complex output and
> nothing shows.

Are you returning the number of samples produced by your work function?

Johnathan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP with Basic_RX

On Mon, May 31, 2010 at 15:03, Marcus D. Leech <mleech@ripnet.com> wrote:

> I set the tuning parameter of the source to 38.5MHz, and what I get on
> the FFT is a flat-line at  -410dB!  Now, granted, I don't have the inputs connected to anything
> yet, but I would expect there  to be *some* noise, and -410dB seems, well, like bad physics :-)

The Basic RX has no gain. It's very likely your noise floor is either
below the LSB of the ADC, or the DDC is filtering the noise floor to
below the LSB of the filtered sample stream. Add a file sink and look
at the actual sample values.

Or, try connecting something to the input :-)

Johnathan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Output not showing in GRC

hi josh,

Unfortunately, the solution didnt work. I also want to reiterate that I used the graphical scope that failed as well.

Thanks

Sam

> Date: Mon, 31 May 2010 15:02:05 -0700
> From: josh@joshknows.com
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Output not showing in GRC
>
> the file sink is probably not flushing to disk (common issue).
>
> Try using a head block and the run to completion option and see what
> happens. Upon completion, the file sink destructor will flush.
>
> -Josh
>
> On 05/31/2010 02:57 PM, Sammour wrote:
> >
> > Hello guys,
> >
> > As my first gnuradio block, I have built a block to multiply two complex
> > numbers using MATLAB library. I compiled my block and wrote a python
> > programme to test it and everything went very nicely. I used this c++
> > statement in the general_work method to see the output of the block:
> > std::cout<< out[i]<< std::endl;
> > and indeed I can see the complex product for my inputs. However, when I
> > install my block in GRC, I connect the output to a file sink that stores
> > nothing! I also tried to plot the magnitude of the complex output and
> > nothing shows. The surprising part is that the output values of the above
> > c++ statement are printed in the output area in GRC and this means that my
> > c++ code is actually invoked.
> >
> > I wonder if this has to do with library linking or not. Any suggestions??
> >
> > Thanks a lot!
> >
> > Sam
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

---

Get a free e-mail account with Hotmail. Sign-up now.

[Discuss-gnuradio] USRP with Basic_RX

I'm trying to "carve off" about 250Khz of bandwidth around 38.5MHz,
(actually any frequency
between about 25MHz and 40MHz) using a Basic_RX and a USRP2.

In GRC, I created a simple flow-graph with a USRP2 source, and an FFT sink.

I set the tuning parameter of the source to 38.5MHz, and what I get on
the FFT is a flat-line at
-410dB! Now, granted, I don't have the inputs connected to anything
yet, but I would expect there
to be *some* noise, and -410dB seems, well, like bad physics :-)

Cribbing from hfx2.py in gnuradio/*examples*/python/apps it seems that
this should "just work".

Am I missing something? I thought that the FPGA would "do the right
thing" in the case of the Basic_RX,
and use the DDC to pull the "target" frequency down around DC, etc, etc.

--
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] Output not showing in GRC

the file sink is probably not flushing to disk (common issue).

Try using a head block and the run to completion option and see what
happens. Upon completion, the file sink destructor will flush.

-Josh

On 05/31/2010 02:57 PM, Sammour wrote:
>
> Hello guys,
>
> As my first gnuradio block, I have built a block to multiply two complex
> numbers using MATLAB library. I compiled my block and wrote a python
> programme to test it and everything went very nicely. I used this c++
> statement in the general_work method to see the output of the block:
> std::cout<< out[i]<< std::endl;
> and indeed I can see the complex product for my inputs. However, when I
> install my block in GRC, I connect the output to a file sink that stores
> nothing! I also tried to plot the magnitude of the complex output and
> nothing shows. The surprising part is that the output values of the above
> c++ statement are printed in the output area in GRC and this means that my
> c++ code is actually invoked.
>
> I wonder if this has to do with library linking or not. Any suggestions??
>
> Thanks a lot!
>
> Sam

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Output not showing in GRC

Hello guys,

As my first gnuradio block, I have built a block to multiply two complex
numbers using MATLAB library. I compiled my block and wrote a python
programme to test it and everything went very nicely. I used this c++
statement in the general_work method to see the output of the block:
std::cout << out[i]<< std::endl;
and indeed I can see the complex product for my inputs. However, when I
install my block in GRC, I connect the output to a file sink that stores
nothing! I also tried to plot the magnitude of the complex output and
nothing shows. The surprising part is that the output values of the above
c++ statement are printed in the output area in GRC and this means that my
c++ code is actually invoked.

I wonder if this has to do with library linking or not. Any suggestions??

Thanks a lot!

Sam
--
View this message in context: http://old.nabble.com/Output-not-showing-in-GRC-tp28735468p28735468.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio final release candidate 3.3.0-rc3 available for download

On Mon, May 31, 2010 at 01:02:27PM -0700, Johnathan Corgan wrote:
> On Mon, May 31, 2010 at 12:27, Eric Blossom <eb@comsec.com> wrote:
>
> >> DQT_SHARED -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -p \
> [snip
> > FWIW, it looks like the DQT_SHARED flag is missing the leading '-'
> > i.e., -DQT_SHARED, and/or there's a missing \ somewhere in some
> > definition somewhere, and/or the variable with the command (not
> > visible in the output), has a null value.
> >
> > Tom, if you get a chance, can you take a look at this?
>
> This appears to originate in line 79 of gr-qtui/src/lib/Makefile.am.
> There is a variable $(QT_MOC_EXEC) which is null when QT is not
> installed on the machine. I not sure this line should even be
> executed in this scenario, however, so it seems the real issue is
> deeper.
>
> This particular Makefile.am has been fragile in this area in the past;
> it's another consequence of the requirement for QT apps to use a
> pre-compiler to process header files. We may be better off putting
> the generated files under version control.

That almost never works, since the installed versions of Qt* (on the
user system) and the version on the "make dist" machine are most
likely different, and incompatible.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio final release candidate 3.3.0-rc3 available for download

On Mon, May 31, 2010 at 12:27, Eric Blossom <eb@comsec.com> wrote:

>> DQT_SHARED -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -p \
[snip
> FWIW, it looks like the DQT_SHARED flag is missing the leading '-'
> i.e., -DQT_SHARED, and/or there's a missing \ somewhere in some
> definition somewhere, and/or the variable with the command (not
> visible in the output), has a null value.
>
> Tom, if you get a chance, can you take a look at this?

This appears to originate in line 79 of gr-qtui/src/lib/Makefile.am.
There is a variable $(QT_MOC_EXEC) which is null when QT is not
installed on the machine. I not sure this line should even be
executed in this scenario, however, so it seems the real issue is
deeper.

This particular Makefile.am has been fragile in this area in the past;
it's another consequence of the requirement for QT apps to use a
pre-compiler to process header files. We may be better off putting
the generated files under version control.

Fortunately, 'make distcheck' is intended for maintainers and hackers
on GNU Radio itself, and not really an issue for end users that are
only compiling and installing so they can write their own code on top
of the GNU Radio API. So, as Michael said, it's probably not a
release issue. If Tom can straighten it out, great. But it's a risky
area of change that should get all its corner cases verified before
merging.

Johnathan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio final release candidate 3.3.0-rc3 available for download

On Mon, May 31, 2010 at 01:00:48PM -0600, Michael Dickens wrote:
> 3.3.0-rc3 still passes "make check" on OSX; I can't test further,
> really, but previous candidates did work so this one probably does
> too. Still does not pass "make distcheck"; errors on in gr-qtgui,
> as it did before (see below for error message). BTW> gr-qtgui is
> not enabled; as before the Qt stuff is installed under strange names
> & hence not found. Either way, the error below should be avoidable;
> I don't have time to work on this, and it's not critical for the
> release of 3.3.0 ... but it should be in the queue to be corrected.
> - MLD
>
> [snip]
> /bin/rm -f .deps/qtgui.d
> cp .deps/qtgui.Std .deps/qtgui.d
> echo "" >> .deps/qtgui.d
> /opt/local/bin/gsed -e '1d;s, \\,,g;s, ,,g' < .deps/qtgui.Std | \
> awk '{ printf "%s:\n\n", $0 }' >> .deps/qtgui.d
> /bin/rm -f .deps/qtgui.Std
> touch .deps/qtgui-generate-stamp
> DQT_SHARED -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -p \
> ../../../../gr-qtgui/src/lib \
> ../../../../gr-qtgui/src/lib/spectrumdisplayform.h \
> -o spectrumdisplayform_moc.cc
> make[3]: DQT_SHARED: Command not found
> make[3]: [spectrumdisplayform_moc.cc] Error 127 (ignored)
> [snip]

FWIW, it looks like the DQT_SHARED flag is missing the leading '-'
i.e., -DQT_SHARED, and/or there's a missing \ somewhere in some
definition somewhere, and/or the variable with the command (not
visible in the output), has a null value.

Tom, if you get a chance, can you take a look at this?

Thanks,
Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio final release candidate 3.3.0-rc3 available for download

3.3.0-rc3 still passes "make check" on OSX; I can't test further,
really, but previous candidates did work so this one probably does
too. Still does not pass "make distcheck"; errors on in gr-qtgui, as
it did before (see below for error message). BTW> gr-qtgui is not
enabled; as before the Qt stuff is installed under strange names &
hence not found. Either way, the error below should be avoidable; I
don't have time to work on this, and it's not critical for the release
of 3.3.0 ... but it should be in the queue to be corrected. - MLD

[snip]
/bin/rm -f .deps/qtgui.d
cp .deps/qtgui.Std .deps/qtgui.d
echo "" >> .deps/qtgui.d
/opt/local/bin/gsed -e '1d;s, \\,,g;s, ,,g' < .deps/qtgui.Std | \
awk '{ printf "%s:\n\n", $0 }' >> .deps/qtgui.d
/bin/rm -f .deps/qtgui.Std
touch .deps/qtgui-generate-stamp
DQT_SHARED -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -p \
../../../../gr-qtgui/src/lib \
../../../../gr-qtgui/src/lib/spectrumdisplayform.h \
-o spectrumdisplayform_moc.cc
make[3]: DQT_SHARED: Command not found
make[3]: [spectrumdisplayform_moc.cc] Error 127 (ignored)
[snip]

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] read_aux_adc

On Mon, May 31, 2010 at 04:42:47PM +0800, jf w wrote:
> I'm using RFX2400 daughterboard on side B, my arguments are slot=2
> which_adc = 0 ,and I'm calling it from python.
>
> Your question inspire me that my arguments may be wrong. I think the slot
> argument should be 3(SLOT_RX_B), but I don't know the meaning of which_adc
> and how to set it.
>
> There are two aux_adc on one ad9862:aux_adc_a and aux_adc_b , but there are
> four pins : aux_adc_a1,aux_adc_a2, aux_adc_b1 and aux_adc_b2. But what is
> the input of the signal on these pins?
>
> Thanks a lot.
>

/*!
* \brief Read auxiliary analog to digital converter.
*
* \param which_side [0,1] which d'board
* \param which_adc [0,1]
* \returns value in the range [0,4095] if successful, else READ_FAILED.
*/
virtual int read_aux_adc (int which_side, int which_adc) = 0;

Try

v = u.read_aux_adc(1, 0)

I think the RSSI is on adc 0, but not 100% sure.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp mux question

2010/5/31 weizhongshan <weizhongshan_1@163.com>:
> hello every !
> i use one usrp to transmit complex gr_sin_wave,and use another two_channel
> usrp as the receiver.
> i thought the mux should be set to "32103210",but when i did this ,i got
> nothing but noisy .then i changed the mux to "33221100",i got the ecpected
> orthogonal sin and cos wave .that confuses me

What is your daughterboard setup and why are you using 2 channels?
With 2 channels, the default "32103210" value uses all four ADC's and
the first 2 DDC's. It sounds like you only want to read one channel
and output separated I and Q components.

Thomas

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Europe

thank you for the link. yes it seem that the web site still there. but unfortunetly i think there is no more update this year. it is not active any more. are you staying at the Netherlands? is there anybody that i can meet in the Netherlands to discuss on the GNU radio?

best regards,
Adib

---

From: Dimitrios Symeonidis <azimout@gmail.com>
To: adib_sairi <adib_sairi@yahoo.com>
Cc: Discuss-gnuradio@gnu.org
Sent: Mon, May 31, 2010 5:56:02 PM
Subject: Re: [Discuss-gnuradio] GNU Radio Europe

You can find it here: http://gnuradio.eu/

Dimitrios Symeonidis
"If you think you're too small to make a difference, try sleeping with
a mosquito!" - Amnesty International



On Fri, May 28, 2010 at 16:04, adib_sairi <adib_sairi@yahoo.com> wrote:
>
>
>
> adib_sairi wrote:
>>
>> Dear All,
>>
>> one time ago there is a GNU Radio Europe if i am not www.gnuradio.nl forum
>> available. but today i try to access it and unfortunately i find out that
>> is is not available anymore. did any one know what is happening?
>>
>> I am looking for anybody in Netherlands that is using GNU Radio. I would
>> very interested to have a discussion and learn how to use GNU radio in the
>> better way (or maybe in the real and right way ;) ). can anybody direct me
>> to any person that i can meet with? any help is very appreciated.. thanks.
>>
>>
>>
>
>
> by the way, I am now a visiting researcher in TU Delft.
>
> -----
> Mohd Adib Sarijari
> Universiti Teknologi Malaysia
> www.fke.utm.my
> www.utm.my
> --
> View this message in context: http://old.nabble.com/GNU-Radio-Europe-tp28703057p28707325.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

Re: [Discuss-gnuradio] GNU Radio Europe

You can find it here: http://gnuradio.eu/

Dimitrios Symeonidis
"If you think you're too small to make a difference, try sleeping with
a mosquito!" - Amnesty International

On Fri, May 28, 2010 at 16:04, adib_sairi <adib_sairi@yahoo.com> wrote:
>
>
>
> adib_sairi wrote:
>>
>> Dear All,
>>
>> one time ago there is a GNU Radio Europe if i am not www.gnuradio.nl forum
>> available. but today i try to access it and unfortunately i find out that
>> is is not available anymore. did any one know what is happening?
>>
>> I am looking for anybody in Netherlands that is using GNU Radio. I would
>> very interested to have a discussion and learn how to use GNU radio in the
>> better way (or maybe in the real and right way ;) ). can anybody direct me
>> to any person that i can meet with? any help is very appreciated.. thanks.
>>
>>
>>
>
>
> by the way, I am now a visiting researcher in TU Delft.
>
> -----
> Mohd Adib Sarijari
> Universiti Teknologi Malaysia
> www.fke.utm.my
> www.utm.my
> --
> View this message in context: http://old.nabble.com/GNU-Radio-Europe-tp28703057p28707325.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to use forecast()?

Eric and Mir,
Thanks for the important infomation provided. I will try both of them and
reply to you.

Zohair
--
View this message in context: http://old.nabble.com/How-to-use-forecast%28%29--tp28705301p28728321.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] read_aux_adc

I'm using RFX2400 daughterboard on side B, my arguments are  slot=2 which_adc = 0 ,and I'm calling it from python.

Your question inspire me that my arguments may be wrong. I think the slot argument should be 3(SLOT_RX_B), but I don't know the meaning of which_adc and how to set it.  

There are two aux_adc on one ad9862:aux_adc_a and aux_adc_b , but there are four pins : aux_adc_a1,aux_adc_a2, aux_adc_b1 and aux_adc_b2. But what is the input of the signal on these pins?

Thanks a lot.

2010/5/31 Eric Blossom <eb@comsec.com>

On Mon, May 31, 2010 at 11:00:17AM +0800, jf w wrote:
> hi all,
>
> I want to use the read_aux_adc method to get the RSSI, but the results I got
> seem meaningless.
>
> 1. Everytime I call the read_aux_adc, the result increases step by step.
> 2. No matter whether there is a sender, the result is the same.
>
> Does anyone come up against this problem ?
> Any suggestion is helpful to me.

What daughterboard are you using?
Which side is it installed in, side A or side B?
What argument values are you passing to read_aux_adc?
Are you calling it from C++ or Python?

Eric

--
Thanks,
Jianfei
BUAA

[Discuss-gnuradio] usrp mux question

hello every !
i use one usrp to transmit complex gr_sin_wave,and use another two_channel  usrp as the receiver.
i thought the mux should be set to "32103210",but when i did this ,i got nothing but noisy .then i changed the mux to "33221100",i got the ecpected orthogonal sin and cos wave .that confuses me
   

---

网易为中小企业免费提供企业邮箱（自主域名）

[Discuss-gnuradio] GNU Radio final release candidate 3.3.0-rc3 available for download

GNU Radio release 3.3.0-rc3 is available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc3.tar.gz
http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc3.tar.gz

MD5 sums:

88913fb0417c3d6ef7b33e631674c4cf gnuradio-3.3.0-rc3.tar.gz
aac8f6a4beea56b68c80f47c5bcf407a gr-howto-write-a-block-3.3.0-rc3.tar.gz

GIT changelog:

Release 3.3.0-rc3

Johnathan Corgan (4):
build: refactor GR_GIT and GR_VERSION
Make C++ shared libraries versioned
howto: make versioned libraries
Update revision to 3.3.0-rc3

This is anticipated to be the last release candidate before release
3.3.0. Please test this thoroughly.

NOTE: This release candidate implements versioned C++ shared
libraries. The version of GNU Radio is now encoded into the filename
of all shared libraries installed into $prefix/lib. This makes it
very important to perform the 'make uninstall' operation prior to
installing GNU Radio from distribution tarballs or via a GIT checkout,
as new release versions of these libraries will no longer overwrite
the old ones when doing a 'make install'.

Johnathan Corgan

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Auto T/R and Squelch

Hi,

In my application I am attempting to use the USRP in full duplex mode.
RX on a TVRX side B
TX on a RFX 400 side A

A problem that I have come across is that there is always a carrier
present on my output frequency, which is an issue for my particular
application.
I have the USRP output configured as "Auto T/R" which I believe should
not output anything when it is being sent nothing. I have placed a
power squelch block before the USRP output which has gate set to "Yes"
to ensure that nothing it being sent to the usrp.
OR
Is there a way that I can set the RFX400 to receive mode based on the
status of a squelch block? Basically I am not sure how I can detect
weather or not the squelch block has activated using GRC. I would be
interested in being able to do this anyway so that a user can see the
status of the squelch.

Could someone give me some guidance on how to use these settings and
features? Or point me in the direction of documentation that I have
missed?

Thanks :-)
Andrew Gilbett
andrew.gilbett@gmail.com

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to use forecast()?

if you still wanna use forecast and general_work then this is how you do it ...

void your_block::forecast(int noutput_items,gr_vector_int &ninput_items_required){

ninput_items_required[0]=100 * noutput_items;

ninput_items_required[1]=100 * noutput_items;

}

the scheduler will choose the number for noutput_items and it will make sure that you have the required items on your input streams by calling forecast. 

Suppose your output items are a multiple of a specific item e.g. if you always want 100 items produced each time your general_work() is called then you have to tell the scheduler that the noutput_items must be a multiple of 100. Call set_output_miltiple() to let the scheduler know this. This is how it's done,

dsss_spreading_b::dsss_spreading_b(unsigned int length_PN):gr_block("spreading_b",

gr_make_io_signature(2,2,sizeof(unsigned char)),

gr_make_io_signature(1,1,sizeof(unsigned char))),

d_length_PN(length_PN)

{

set_output_multiple(d_length_PN);

}

for example the above constructor shows a block that has 2 input streams and one output stream and it calls set_output_multilple which has an integer parameter d_length_PN passed. The scheduler will make sure that the noutput_items that it selects will be a multiple of d_length_PN....

if d_length_PN=100 ...then scheduler will choose n*100 output_items ... where n in an integer.

Look into the examples or the blocks in the gnuradio. Read the comments in gr_block.h file. This will give you all the information.

Good luck.

On Sun, May 30, 2010 at 9:16 PM, Eric Blossom <eb@comsec.com> wrote:

On Sun, May 30, 2010 at 01:33:17PM -0700, Zohair wrote:
>
> Hello everybody,
>
> I'm working on building a block that accepts many inputs (say n) and has one
> output. For a single output item to be generated, 100 samples from each
> input port should be taken. How can I use forecast() and general_work() to
> serve my purpose? I read somewhere that we never call or modify the
> parameters explicitly, the scheduler does this instead. But how does the
> scheduler know that I need 100 samples exactly.
>
> Any help is highly appreciated.

No need to use general_work or forecast.

Derive from gr_sync_decimator.  There are many examples in
gnuradio-core/src/lib/general.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Multiple USRP2 sync

That would be useful for cases when your gpsdo does not have a serial
port or cannot be programmed to report a timestamp on the pps. I like
the idea; it would probably require an additional FPGA readback register
and some supporting host code.

-Josh

On 05/30/2010 07:57 AM, David Evans wrote:
> if I have two (or more) usrp2s, and I do a set_time_next_pps(), there is (or is there?) a chance
> that the pps could occur after the first call, so the second call will
> set the second usrp a second later. I would need to know when there is a pps or seconds transition prior to setup, then have one or two seconds
> to call set_time_next_pps(). Ok, I could read the system time, but I
> would need a gps with pps/ref out, and sync'd using ntpd or gpsd, and
> this may not be guaranteed. Or I could just monitor the pps level via
> the serial port (DCD, like ntpd does with nmea stream) to guarantee when the seconds tick over. If the pps state could be read back from the
> usrp (approx 80ns rtt) however, this would simplify the system and
> hardware requied (USB dongle, TTL to RS232 convertor, extra wires,
> etc...). So...
>
> while (get_pps_level() == 0); // wait for edge
> while (get_pps_level() == 1);
>
> u1->set_time_next_pps(...); // We are guaranteed at least one second to issue this to both usrp at
> once
> u2->set_time_next_pps(...);
>
> Thanks
> David
>
>
>
>
>
>
> _______________________________________________
> 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] Long-running app getting into trouble

On 05/31/2010 12:58 AM, Eric Blossom wrote:
>
> When it wedges, does it continue to consume CPU, or does it appear to
> be blocked?
>
Oooh, I forgot to check that, but clearly another clue that needs to be
gathered!
> When it wedges, you should be able to attach to it with gdb.
> Run gdb on /usr/bin/python, then attach it to the PID that corresponds
> to your app.
>
> (gdb) attach <pid>
> (gdb) thread apply all bt
>
> will generate a backtrace for all threads.
>
> Eric
>
>
Thanks for the tip! Will definitely do that next time it happens.
Really want to understand this
one and nip it in the aggravating little bud!

My intuition is telling me that it's weirdness in ALSA, but that's just
a gut feeling.

--
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] Long-running app getting into trouble

On Sun, May 30, 2010 at 11:26:34PM -0400, Marcus D. Leech wrote:
> I have a long-running Gnu Radio application--my VLF sid receiver. It
> seems to "wedge" after a few days
> of flawless operation.
>
> The application uses an audio source, and an audio sink, but usually the
> source and sink are on
> two different sound cards.
>
> The application uses a number of WxGUI widgets, and was generated using
> GRC. I don't see any evidence
> for a memory leak, the app reaches stable virtual and resident-set
> sizes fairly quickly, and they don't change.
>
> There's no evidence for a file-descriptor leak (checked /proc/XXXX for
> each of the 3 processes involved, and
> everything looks good).
>
> No kernel error messages (and this application behaves this way across
> different distributions of
> Linux--both Ubuntu and Fedora show this problem).
>
> Next time it happens, I'll force a core dump, and see if I can see where
> it's getting hung.
>
> But it's most puzzling, and a little worrying. I really need this app,
> and ones like it to run
> essentially indefinitely, doing what they do. If anyone has any kind
> of clue, and wants the
> code (most of it produced in GRC), please let me know.
>
> Cheers(?)
> Marcus

When it wedges, does it continue to consume CPU, or does it appear to
be blocked?

When it wedges, you should be able to attach to it with gdb.
Run gdb on /usr/bin/python, then attach it to the PID that corresponds
to your app.

(gdb) attach <pid>
(gdb) thread apply all bt

will generate a backtrace for all threads.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] read_aux_adc

On Mon, May 31, 2010 at 11:00:17AM +0800, jf w wrote:
> hi all,
>
> I want to use the read_aux_adc method to get the RSSI, but the results I got
> seem meaningless.
>
> 1. Everytime I call the read_aux_adc, the result increases step by step.
> 2. No matter whether there is a sender, the result is the same.
>
> Does anyone come up against this problem ?
> Any suggestion is helpful to me.

What daughterboard are you using?
Which side is it installed in, side A or side B?
What argument values are you passing to read_aux_adc?
Are you calling it from C++ or Python?

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re:"uU" 26

hi,Eric!
I have tested the usrp_siggen.py ,it works well.and I set the interpolate in my module to 128,it works too.so it seems my pc can only stand with 2 M speed ,but why the C++ program woks too?
thanks a lot<br><br>在2010-05-29 04:44:57，"Eric Blossom" <eb@comsec.com> 写道：
>On Fri, May 28, 2010 at 10:33:56AM +0800, weizhongshan wrote:
>> thanks Eric
>> I am sorry ,I will not do that again .but would you please help me figure out this problem. as I mentioned the USB speed is not a problem.and i have another C++ problem test_usrp ,it's a one channel receiver , the decim is set to 8.and it does work without any trouble .so i think my pc can keep up with the speed<br><br>在2010-05-28 02:35:37，"Eric Blossom" <eb@comsec.com> 写道：
>> >On Thu, May 27, 2010 at 05:29:56PM +0800, weizhongshan wrote:
>> >> hello everyone ,I want to use the fm_tx_2_daughters.py as a template to realize my own module ,so I copy it to my own folder.
>> >> but when I set the interpolate to 64 and test the copy module ,"uU" appears.then I run the usrp_benchmark_usb.py,the result shows "Max USB/USRP throughput = 32MB/sec".I wonder the "uU" appears
>> >> thanks forward<br><br>在2010-05-27 00:00:43，discuss-gnuradio-request@gnu.org 写道：
>
>Does usrp_siggen.py work for you?
>
>Eric
>
>
>> >Perhaps your machine can't keep up?
>> >uU is "USRP Underrun". You failed to send it samples fast enough.
>> >
>> >[Also, please don't top-post in general, and never top post on top of
>> >the digest. Pick a relevant subject, trim all unnecessary text from
>> >anything you're replying to. If you're starting a new thread, don't
>> >start by replying to an existing (non-relevant) thread.
>> >
>> >See also:
>> >
>> > http://gnuradio.org/redmine/wiki/gnuradio/ReportingErrors
>> >
>> >Eric
>>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Long-running app getting into trouble

I have a long-running Gnu Radio application--my VLF sid receiver. It
seems to "wedge" after a few days
of flawless operation.

The application uses an audio source, and an audio sink, but usually the
source and sink are on
two different sound cards.

The application uses a number of WxGUI widgets, and was generated using
GRC. I don't see any evidence
for a memory leak, the app reaches stable virtual and resident-set
sizes fairly quickly, and they don't change.

There's no evidence for a file-descriptor leak (checked /proc/XXXX for
each of the 3 processes involved, and
everything looks good).

No kernel error messages (and this application behaves this way across
different distributions of
Linux--both Ubuntu and Fedora show this problem).

Next time it happens, I'll force a core dump, and see if I can see where
it's getting hung.

But it's most puzzling, and a little worrying. I really need this app,
and ones like it to run
essentially indefinitely, doing what they do. If anyone has any kind
of clue, and wants the
code (most of it produced in GRC), please let me know.

Cheers(?)
Marcus

--
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] read_aux_adc

hi all,

I want to use the read_aux_adc method to get the RSSI, but the results I got seem meaningless. 

1. Everytime I call the read_aux_adc, the result increases step by step.

2. No matter whether there is a sender, the result is the same.

Does anyone come up against this problem ?

Any suggestion is helpful to me.

Thanks

P.S. the result is 

3232

3136

3152

3176

3192

3204

3200

3208

3220

3232

3244

3252

3264

3272

3280

3288

3292

3296

3304

3308

3316

3320

3324

3328

3324

3336

3332

3336

3340

3340

3344

3348

3352

3356

3356

3360

3364

3364

3368

3368

3372

3376

3376

3376

3380

3380

3380

3384

3384

3388

3388

3388

3392

3392

3392

3396

3396

3400

3400

3400

3400

3404

3404

3404

3404

3408

3408

3408

3408

3412

1. 

--
Thanks,
Jianfei
BUAA

Re: [Discuss-gnuradio] gnuradio.org server down right now

On Fri, May 28, 2010 at 12:50:52PM -0700, Eric Blossom wrote:
> FYI,
>
> The gnuradio.org server is down right now.
> We're working on it. Should be back later on this afternoon.
> Trying to find the real cause, as opposed to just rolling back to the
> latest snapshot.
>
> Eric
>

FYI,

The server's back up.

The primary problem was a directory of session state files that was
growing without bound, that eventually ran us out of inodes.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to use forecast()?

On Sun, May 30, 2010 at 01:33:17PM -0700, Zohair wrote:
>
> Hello everybody,
>
> I'm working on building a block that accepts many inputs (say n) and has one
> output. For a single output item to be generated, 100 samples from each
> input port should be taken. How can I use forecast() and general_work() to
> serve my purpose? I read somewhere that we never call or modify the
> parameters explicitly, the scheduler does this instead. But how does the
> scheduler know that I need 100 samples exactly.
>
> Any help is highly appreciated.

No need to use general_work or forecast.

Derive from gr_sync_decimator. There are many examples in
gnuradio-core/src/lib/general.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Increment / Decrement Button

Hi All;

 

I’m trying to implement an “Increment” button that when pressed, increments a variable.

This will be used to increment the tuned frequency by say 1 MHz every time it is pressed.

 

I tried a Variable Chooser, configured it as a button and gave it only one choice. The variable name was tune_inc.

For the default value I used “tune_inc”.

For the only choice I used “tune_inc+1e6”, hoping that every time I pressed the button the variable “tune_inc” would increment itself …

 

What I got was an error stating that the name “tune_inc” was not defined.

Am I going about his the wrong way ??

I have no clue how to write my own processing block to do this L

 

Thanks …

 

Bill

 

[Discuss-gnuradio] How to use forecast()?

Hello everybody,

I'm working on building a block that accepts many inputs (say n) and has one
output. For a single output item to be generated, 100 samples from each
input port should be taken. How can I use forecast() and general_work() to
serve my purpose? I read somewhere that we never call or modify the
parameters explicitly, the scheduler does this instead. But how does the
scheduler know that I need 100 samples exactly.

Any help is highly appreciated.
--
View this message in context: http://old.nabble.com/How-to-use-forecast%28%29--tp28705301p28705301.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC: wrong input declaration in sample_and_hold

Yes.
I had the "ctrl" sink declared as "<type>$type</type>" in my build (V3.2.2 built from the tarball).
I guess it has
been corrected now.
Thanks
Alberto

On Fri, 2010-05-28 at 17:05 -0700, Josh Blum wrote:
This is the sample and hold c++
io signature:
>
> @NAME@::@NAME@ ()
> : gr_sync_block ("@BASE_NAME@",
> gr_make_io_signature2 (2, 2, sizeof
(@I_TYPE@), sizeof(char)),
> gr_make_io_signature (1, 1, sizeof (@O_TYPE@))),
> d_data(0)
> {
> }
>
> this
is the grc xml block io signature:
>
> <sink>
> <name>in</name>
> <type>$type</type>
> </sink>
> <sink>
>
<name>ctrl</name>
> <type>byte</type>
> </sink>
> <source>
> <name>out</name>
> <type>$type</type>
> </source>

>
> Looks correct?
> -Josh
>
>
> On 05/28/2010 03:32 PM, Alberto Trentadue wrote:
> > Hello
> >
> > I think I found
a wrong input declaration in the sample_and_hold GRC block.
> > The "control" input is defined to be
> > of the same
data type of "in" and "out". Instead, it should be a byte.
> >
> > This is the fix I have applied:
> >
> >
> >
[alberto@iz0cez gnuradio]$ diff -c ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml.orig .
> >
/share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml
> > *** ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml.orig

> > 2010-05-28 23:29:32.953460291 +0200
> > --- ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml 2010-05-28 23:
29:
> > 57.655461060 +0200
> > ***************
> > *** 40,46 ****
> > </sink>
> > <sink>
> >
<name>ctrl</name>
> > ! <type>$type</type>
> >
> > </sink>
> > <source>
> > <name>out</name>
> > ---
40,46 ----
> > </sink>
> > <sink>
> > <name>ctrl</name>
> > !
> > <type>byte</type>
> > </sink>
>
> <source>
> > <name>out</name>
> >
> > BTW: what is the need to use a "char" as control in the
> >
correspondent gr block?
> >
> > Moreover, it seems to me that the Documentation is wrong, because the block samples the
input
> > when the ctrl is 1, and holds when is 0, not the opposite.
> > Do you agree?
> >
> > Alberto-
> >
> >
> >
Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 € al mese.
> >
> > Gratis la Sim Tiscali Mobile
con 25 euro di traffico!
> >
> > L'offerta è valida solo se attivi entro il 03/06/10
> >
> > http://abbonati.tiscali.
it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw
> >
> > _______________________________________________

> > 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

Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 € al mese.

Gratis la Sim Tiscali Mobile con 25 euro di traffico!

L'offerta è valida solo se attivi entro il 03/06/10

http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Multiple sheets in GRC

Hi All;

I while back I thought I saw a post about using multiple sheets in GRC.

I think it said something about the top block, but I can’t find the post now L

 

Does anyone know how to do this ??

 

Thanks …

 

Bill

[Discuss-gnuradio] Multiple USRP2 sync

if I have two (or more) usrp2s, and I do a set_time_next_pps(), there is (or is there?) a chance that the pps could occur after the first call, so the second call will set the second usrp a second later. I would need to know when there is a pps or seconds transition prior to setup, then have one or two seconds to call set_time_next_pps(). Ok, I could read the system time, but I would need a gps with pps/ref out, and sync'd using ntpd or gpsd, and this may not be guaranteed. Or I could just monitor the pps level via the serial port (DCD, like ntpd does with nmea stream) to guarantee when the seconds tick over. If the pps state could be read back from the usrp (approx 80ns rtt) however, this would simplify the system and hardware requied (USB dongle, TTL to RS232 convertor, extra wires, etc...). So...

while (get_pps_level() == 0); // wait for edge
while (get_pps_level() == 1);

u1->set_time_next_pps(...); // We are guaranteed at least one second to issue this to both usrp at once
u2->set_time_next_pps(...);

Thanks
David

[Discuss-gnuradio] An update on my repository (a repo for RHEL/CentOS which has gnuradio)

First please let me note that I will not and do not email this list
about the repo except when I have an update pertaining to gnuradio.

When I first started the repo, I was only building packages for x86_64,
but soon after adopted mock and built most of them for i386 as well, but
the sdcc source rpm had problems compiling under mock, leaving me unable
to build gnuradio for i386. It fell by the wayside and no one seemed to
care since i386 isn't the typical platform of power-users these days.
However, I had a recent request for an i386 package, gave sdcc another
whirl, and finally got a more recent sdcc package that builds
successfully under mock and was able to at last put gnuradio 3.2.2 for
i386 into the repository.

In the same request, it was noted that wxPython should have been called
wxPython25 so as not to conflict with the upstream for Python 2.4. I
repackaged wxPython and gnuradio with the appropriate obsoletes and was
updated to 3.2.2-5 from rawhide with the usual tweaks to use the python25.

Long story short, gnuradio 3.2.2-5 is now available pre-compiled for
x86_64 and i386.

Boost is still at 1.40 as the 1.41 didn't build on my last attempt and
haven't tried very hard to work it out as I'm holding out for a 1.43
source rpm. I have an eye out for it, but may up-package 1.43 using the
1.40 spec as a starting point, but I like to go with version specific
rpms with something as big and complex as boost whenever possible to
avoid missing files. If anything else is creeping out of date, please
let me know.

Last but not least, Gnuradio 3.3 final is nearly here- I'll do my best
to package it as soon as possible, but may need feedback whether it
works appropriately.

And to sign off- as always, please contact me if you have any problems,
complaints, suggestions, etc. Thanks to all who are making use of the
software and providing feedback.

-Brett

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ofdm reception affected by python threading?

On Fri, May 28, 2010 at 04:10:12PM -0700, Veljko Pejovic wrote:
> Hi Eric,
>
> Thanks for the tip. I tried it out on a faster machine, and I observed
> no such problems. The first machine that produces this problem has a
> single core 2.8GHz CPU and the second one, which works fine, has a
> dual core Intel Atom D510, both machines have 2GB of RAM each. I
> should note that the faster machine also has a better GIgEthernet
> card. Interestingly, I do not observe any other signs of CPU
> throttling, such as dropped packets when I see the problem.
>
> Cheers,
> Veljko

The message sink is usually configured to drop packets if the queue length
exceeds a threshold. This sheds load.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC: wrong input declaration in sample_and_hold

This is the sample and hold c++ io signature:

@NAME@::@NAME@ ()
: gr_sync_block ("@BASE_NAME@",
gr_make_io_signature2 (2, 2, sizeof (@I_TYPE@), sizeof(char)),
gr_make_io_signature (1, 1, sizeof (@O_TYPE@))),
d_data(0)
{
}

this is the grc xml block io signature:

<sink>
<name>in</name>
<type>$type</type>
</sink>
<sink>
<name>ctrl</name>
<type>byte</type>
</sink>
<source>
<name>out</name>
<type>$type</type>
</source>

Looks correct?
-Josh

On 05/28/2010 03:32 PM, Alberto Trentadue wrote:
> Hello
>
> I think I found a wrong input declaration in the sample_and_hold GRC block.
> The "control" input is defined to be
> of the same data type of "in" and "out". Instead, it should be a byte.
>
> This is the fix I have applied:
>
>
> [alberto@iz0cez gnuradio]$ diff -c ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml.orig .
> /share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml
> *** ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml.orig
> 2010-05-28 23:29:32.953460291 +0200
> --- ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml 2010-05-28 23:29:
> 57.655461060 +0200
> ***************
> *** 40,46 ****
> </sink>
> <sink>
> <name>ctrl</name>
> ! <type>$type</type>
>
> </sink>
> <source>
> <name>out</name>
> --- 40,46 ----
> </sink>
> <sink>
> <name>ctrl</name>
> !
> <type>byte</type>
> </sink>
> <source>
> <name>out</name>
>
> BTW: what is the need to use a "char" as control in the
> correspondent gr block?
>
> Moreover, it seems to me that the Documentation is wrong, because the block samples the input
> when the ctrl is 1, and holds when is 0, not the opposite.
> Do you agree?
>
> Alberto-
>
>
> Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 € al mese.
>
> Gratis la Sim Tiscali Mobile con 25 euro di traffico!
>
> L'offerta è valida solo se attivi entro il 03/06/10
>
> http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw
>
> _______________________________________________
> 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] ofdm reception affected by python threading?

Hi Eric,

Thanks for the tip. I tried it out on a faster machine, and I observed
no such problems. The first machine that produces this problem has a
single core 2.8GHz CPU and the second one, which works fine, has a
dual core Intel Atom D510, both machines have 2GB of RAM each. I
should note that the faster machine also has a better GIgEthernet
card. Interestingly, I do not observe any other signs of CPU
throttling, such as dropped packets when I see the problem.

Cheers,

Veljko

2010/5/24 Eric Blossom <eb@comsec.com>:
> On Fri, May 21, 2010 at 02:15:15PM -0700, Veljko Pejovic wrote:
>> Hi,
>>
>> I'm using two USRP2 with XCVR2450s, a week old gnuradio git master and
>> Ubuntu 9.10.
>>
>> A few months ago while using the OFDM code I observed that I tend to
>> receive (or send?) packets in groups, although I was sending them
>> individually.
>>
>> Now, I finally isolated the problem. I added a few simple print lines:
>>
>> "Message inserted in HAVE_HEADER" - whenever a message is enqueued in
>> STATE_HAVE_SYNC of ofdm_frame_sink.cc
>>
>> and
>>
>> "Message picked up from the queue" - in queue_watcher_thread in
>> ofdm.py, every time the message is fetched from the queue.
>>
>> The output that I expected was:
>>
>> Message inserted in HAVE_HEADER
>> Message picked up from the queue
>> Message inserted in HAVE_HEADER
>> Message picked up from the queue
>> ...
>>
>> However, I'm getting rather inconsistent output (this is a sample,
>> check the attachment for the first few seconds of the output):
>>
>> Message inserted in HAVE_HEADER
>> Message inserted in HAVE_HEADER
>> Message inserted in HAVE_HEADER
>> Message inserted in HAVE_HEADER
>> Message picked up from the queue
>> Message picked up from the queue
>> Message picked up from the queue
>> Message picked up from the queue
>> Message inserted in HAVE_HEADER
>> Message inserted in HAVE_HEADER
>> Message inserted in HAVE_HEADER
>> Message inserted in HAVE_HEADER
>> Message inserted in HAVE_HEADER
>> Message picked up from the queue
>> Message picked up from the queue
>> Message picked up from the queue
>> Message picked up from the queue
>> Message picked up from the queue
>>
>> So, it is definitely the receiver that has problems. It looks as if
>> "msg = self.rcvd_pktq.delete_head()" in queue_watcher_thread in
>> ofdm.py is not checked frequently enough. Could it be that Python does
>> not switch threads fast enough? Note, I do have real time scheduling
>> enabled.
>> Any ideas on how to get around this?
>
> Is your machine out of CPU cycles?
> If it's not fast enough, it won't keep up.
>
> Eric
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GRC: wrong input declaration in sample_and_hold

Hello

I think I found a wrong input declaration in the sample_and_hold GRC block.
The "control" input is defined to be
of the same data type of "in" and "out". Instead, it should be a byte.

This is the fix I have applied:

[alberto@iz0cez gnuradio]$ diff -c ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml.orig .
/share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml
*** ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml.orig
2010-05-28 23:29:32.953460291 +0200
--- ./share/gnuradio/grc/blocks/gr_sample_and_hold_xx.xml 2010-05-28 23:29:
57.655461060 +0200
***************
*** 40,46 ****
</sink>
<sink>
<name>ctrl</name>
! <type>$type</type>

</sink>
<source>
<name>out</name>
--- 40,46 ----
</sink>
<sink>
<name>ctrl</name>
!
<type>byte</type>
</sink>
<source>
<name>out</name>

BTW: what is the need to use a "char" as control in the
correspondent gr block?

Moreover, it seems to me that the Documentation is wrong, because the block samples the input
when the ctrl is 1, and holds when is 0, not the opposite.
Do you agree?

Alberto-

Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 14,95 € al mese.

Gratis la Sim Tiscali Mobile con 25 euro di traffico!

L'offerta è valida solo se attivi entro il 03/06/10

http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] "uU" 26

On Fri, May 28, 2010 at 10:33:56AM +0800, weizhongshan wrote:
> thanks Eric
> I am sorry ,I will not do that again .but would you please help me figure out this problem. as I mentioned the USB speed is not a problem.and i have another C++ problem test_usrp ,it's a one channel receiver , the decim is set to 8.and it does work without any trouble .so i think my pc can keep up with the speed<br><br>在2010-05-28 02:35:37，"Eric Blossom" <eb@comsec.com> 写道：
> >On Thu, May 27, 2010 at 05:29:56PM +0800, weizhongshan wrote:
> >> hello everyone ,I want to use the fm_tx_2_daughters.py as a template to realize my own module ,so I copy it to my own folder.
> >> but when I set the interpolate to 64 and test the copy module ,"uU" appears.then I run the usrp_benchmark_usb.py,the result shows "Max USB/USRP throughput = 32MB/sec".I wonder the "uU" appears
> >> thanks forward<br><br>在2010-05-27 00:00:43，discuss-gnuradio-request@gnu.org 写道：

Does usrp_siggen.py work for you?

Eric

> >Perhaps your machine can't keep up?
> >uU is "USRP Underrun". You failed to send it samples fast enough.
> >
> >[Also, please don't top-post in general, and never top post on top of
> >the digest. Pick a relevant subject, trim all unnecessary text from
> >anything you're replying to. If you're starting a new thread, don't
> >start by replying to an existing (non-relevant) thread.
> >
> >See also:
> >
> > http://gnuradio.org/redmine/wiki/gnuradio/ReportingErrors
> >
> >Eric
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio.org server down right now

FYI,

The gnuradio.org server is down right now.
We're working on it. Should be back later on this afternoon.
Trying to find the real cause, as opposed to just rolling back to the
latest snapshot.

Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio release 3.3.0-rc1 tarballs available for download

Il 22/05/2010 01:34, Johnathan Corgan ha scritto:

GNU Radio release 3.3.0-rc1 tarballs are available for download:  http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc1.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc1.tar.gz  md5sums:  b936f27cf106b15be0ad7e2066b023be  gnuradio-3.3.0-rc1.tar.gz 8d6ea3d7604dba4d920ce4721b76ceae  gr-howto-write-a-block-3.3.0-rc1.tar.gz  Changelog:  Release 3.3.0-rc1  Don Ward (1):      howto: fix make check for win32, darwin (untested)  Eric Blossom (1):      Remove bogus check for existence of prefix directory.  John Orlando (8):      Update incorrectly checked in Makefile.am      Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP1.      Add support for the Bitshark USRP RX (BURX) daughterboard for the USRP2.      Fixed issue with with wrong Makefile.am files being copied      Including bitshark_rx.h header file for USRP2 build      Updated db_bitshark_rx.c to the proper version that includes the      Once and for all, here is the properly updated Makefile.am for the apps      -Updated to allow BURX support to be built into standard txrx.bin  Johnathan Corgan (17):      usrp: Cleanup for merge of bitshark daughterboard code      Change default bandwidth to 25 MHz to match maximum USRP2 bandwidth      Merge branch 'master' into wip/burx_support      Merge remote branch 'nldudok1/gr-wxgui_emulate_analog' into master      gr-wxgui: Renamed "emulate analog" feature to "use persistence"      gr-wxgui: update copyrights      gnuradio-core: Disable (temporarily) interpolator tap calculation      build: force use of ltmain.sh from libtool 2.2.6b      build: use correct comment delimiter      build: distribute version controlled ltmain.sh in tarball      Merge remote branch 'bitshark/burx_support' into wip/burx_support      Revert "build: force use of ltmain.sh from libtool 2.2.6b"      Revert "build: distribute version controlled ltmain.sh in tarball"      Merge branch 'wip/burx_support'      gnuradio-core: removed gr.dd_mpsk_sync_cc block as obsolete      grc: rename execution binary from 'grc' to 'gnuradio-companion'      Update revision to release 3.3.0-rc1, update autotools  Martin Dudok van Heel (1):      Add analog CRT screen afterglow emulation for gr-wxgui   Regards,  Johnathan Corgan Corgan Enterprises LLC  _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio    

i'm experiencing this problem in building on ubuntu 9.10 the 3.3 RC1

/usr/include/qwt-qt4/qwt_plot_picker.h:106: warning: ‘virtual void QwtPlotPicker::move(const QPoint&)’ was hidden
/usr/include/qwt-qt4/qwt_plot_zoomer.h:88: warning:   by ‘virtual void QwtPlotZoomer::move(double, double)’
In file included from ./plot_waterfall.h:5,
                 from ./WaterfallDisplayPlot.h:9,
                 from WaterfallDisplayPlot.cc:4:
./waterfallGlobalData.h:12: error: ISO C++ forbids declaration of ‘uint64_t’ with no type
./waterfallGlobalData.h:18: error: ISO C++ forbids declaration of ‘uint64_t’ with no type
./waterfallGlobalData.h:26: error: ‘uint64_t’ does not name a type
./waterfallGlobalData.h:27: error: ISO C++ forbids declaration of ‘uint64_t’ with no type
./waterfallGlobalData.h:39: error: ‘uint64_t’ does not name a type
./waterfallGlobalData.h:40: error: ‘uint64_t’ does not name a type
./waterfallGlobalData.h:51: error: ISO C++ forbids declaration of ‘uint64_t’ with no type
./waterfallGlobalData.h:54: error: ISO C++ forbids declaration of ‘uint64_t’ with no type
/usr/include/qwtplot3d-qt4/qwt3d_function.h:30: warning: ‘virtual bool Qwt3D::Function::create(Qwt3D::SurfacePlot&)’ was hidden
./waterfallGlobalData.h:56: warning:   by ‘virtual bool Waterfall3DData::create()’
/usr/include/qwt-qt4/qwt_plot_picker.h:103: warning: ‘virtual QwtText QwtPlotPicker::trackerText(const QPoint&) const’ was hidden
WaterfallDisplayPlot.cc:189: warning:   by ‘virtual QwtText WaterfallZoomer::trackerText(const QwtDoublePoint&) const’
make[5]: *** [WaterfallDisplayPlot.lo] Errore 1
make[4]: *** [all] Errore 2
make[3]: *** [all-recursive] Errore 1
make[2]: *** [all-recursive] Errore 1
make[1]: *** [all-recursive] Errore 1
make: *** [all] Errore 2
make[5]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui/src/lib»
make[4]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui/src/lib»
make[3]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui/src»
make[2]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1/gr-qtgui»
make[1]: uscita dalla directory «/home/artynet/Scrivania/gnuradio-3.3.0-rc1»

an error in the waterfall sink.....where am i wrong ?  I installed all the dependencies required fot the 9.10, the configure goes like a charm without any error and then i have this error in building the source....

....hope you can help me :D

thx in advance

Re: [Discuss-gnuradio] GNU Radio Europe

adib_sairi wrote:
>
> Dear All,
>
> one time ago there is a GNU Radio Europe if i am not www.gnuradio.nl forum
> available. but today i try to access it and unfortunately i find out that
> is is not available anymore. did any one know what is happening?
>
> I am looking for anybody in Netherlands that is using GNU Radio. I would
> very interested to have a discussion and learn how to use GNU radio in the
> better way (or maybe in the real and right way ;) ). can anybody direct me
> to any person that i can meet with? any help is very appreciated.. thanks.
>
>
>

by the way, I am now a visiting researcher in TU Delft.

-----
Mohd Adib Sarijari
Universiti Teknologi Malaysia
www.fke.utm.my
www.utm.my
--
View this message in context: http://old.nabble.com/GNU-Radio-Europe-tp28703057p28707325.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Problem with USRP2

Hi Everyone,

I'm studying at the University of Witwatersrand in Johannesburg, South
Africa and we received a set of four USRP2s about 5-6 months ago. I
immediately unpacked two of them and after a few hiccups, got them
working. Two days ago, I needed to make use of the other two USRP2s and
the second one doesn't seem to work. All that happens when I plug it in
is that the 'd' LED lights up. I've tried swapping the Flash Card (i.e.
firmware) and the daughter boards (in case there's a hardware fault) and
nothing changes.

I'm seriously hoping this problem is fixable. Can anybody please provide
me with some guidance.

Kind regards,

Ryan van den Bergh

--
Ryan van den Bergh

PhD Candidate
Centre for Telecommunications Access and Services
School of Electrical and Information Engineering, University of the Witwatersrand

E-Mail: r.vandenbergh@ee.wits.ac.za
Cell: +27 83 353 9600
Work: +27 11 717 7225

This communication is intended for the addressee only. It is confidential. If you have received this communication in error, please notify the author immediately and destroy the original message. You may not copy or disseminate this communication without the permission of the author.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Europe

Dear All,

one time ago there is a GNU Radio Europe if i am not www.gnuradio.nl forum
available. but today i try to access it and unfortunately i find out that is
is not available anymore. did any one know what is happening?

I am looking for anybody in Netherlands that is using GNU Radio. I would
very interested to have a discussion and learn how to use GNU radio in the
better way (or maybe in the real and right way ;) ). can anybody direct me
to any person that i can meet with? any help is very appreciated.. thanks.

-----
Mohd Adib Sarijari
Universiti Teknologi Malaysia
www.fke.utm.my
www.utm.my
--
View this message in context: http://old.nabble.com/GNU-Radio-Europe-tp28703057p28703057.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] usrp1 data rate problem

 hello everyone ,I want to use the fm_tx_2_daughters.py as a template to realize my own module ,so  I copy it to my own folder. but when I set the interpolate to 64 and test the copy module ,"uU" appears.then I run the usrp_benchmark_usb.py,the result shows "Max USB/USRP throughput = 32MB/sec".I wonder why the "uU" appears. and i am sure my pc can keep up with the speed ,as i have another module ,which is a one channel receiver ,with the decim set to 8.and the program works well

---

网易为中小企业免费提供企业邮箱（自主域名）

Re:Re: [Discuss-gnuradio] Re:Discuss-gnuradio Digest, Vol 90, Issue 26

thanks Eric
I am sorry ,I will not do that again .but would you please help me figure out this problem. as I mentioned the USB speed is not a problem.and i have another C++ problem test_usrp ,it's a one channel receiver , the decim is set to 8.and it does work without any trouble .so i think my pc can keep up with the speed<br><br>在2010-05-28 02:35:37，"Eric Blossom" <eb@comsec.com> 写道：
>On Thu, May 27, 2010 at 05:29:56PM +0800, weizhongshan wrote:
>> hello everyone ,I want to use the fm_tx_2_daughters.py as a template to realize my own module ,so I copy it to my own folder.
>> but when I set the interpolate to 64 and test the copy module ,"uU" appears.then I run the usrp_benchmark_usb.py,the result shows "Max USB/USRP throughput = 32MB/sec".I wonder the "uU" appears
>> thanks forward<br><br>在2010-05-27 00:00:43，discuss-gnuradio-request@gnu.org 写道：
>
>Perhaps your machine can't keep up?
>uU is "USRP Underrun". You failed to send it samples fast enough.
>
>[Also, please don't top-post in general, and never top post on top of
>the digest. Pick a relevant subject, trim all unnecessary text from
>anything you're replying to. If you're starting a new thread, don't
>start by replying to an existing (non-relevant) thread.
>
>See also:
>
> http://gnuradio.org/redmine/wiki/gnuradio/ReportingErrors
>
>Eric

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Release 3.3.0-rc2 available for testing

Tarballs for GNU Radio release 3.3.0-rc2 are available for testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.3.0-rc2.tar.gz
http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.3.0-rc2.tar.gz

md5sums:

f93fed74a20b42ee5037aa5adf531456 gnuradio-3.3.0-rc2.tar.gz
3ddc1bd9c4461a7db8ea39c04cf7ddaf gr-howto-write-a-block-3.3.0-rc2.tar.gz

Main items:

* Rework/update of UDP source and sinks by Don Ward
* Removal of libvrt (will be reworked for 3.4git)
* Fix for missing files in USRP2 firmware directory

GIT changelog:

Release 3.3.0-rc2

Don Ward (10):
Changes to gr_udp_{source,sink} for MinGW
Ignore ENOPROTOOPT return from setsockopt(SO_LINGER)
Use getaddrinfo in gr_udp_{source,sink}
Discard data in gr_udp_sink until receiver is started.
Updates to udp source/sink (select(), wait, cleanup)
Merge branch 'master' into udp
Merge branch 'master' into udp
Rework UDP source and sink, with incompatible API changes
Merge branch 'master' into udp
Flush pending errors in gr_udp_sink on disconnect()

Eric Blossom (9):
Add additional conditionalization of networking includes
Use -1 as file descriptor "not open" value instead of 0
Identify memory leaks that occur on error conditions
Correct update of d_temp_offset (parallel construction)
Move initialization of select timeout
Defend against a peer that sends an invalid message length.
Return immediately when using d_residual.
Simplify USE_SELECT usage
Refactor Makefile.am to move common files from 3 libraries into a
single variable.

Eric Schneider (1):
Add USRP2 clock source parameter to GRC blocks.

Johnathan Corgan (9):
grc: update UDP source and sink block wrappers
gnuradio-core: allow swig to handle exceptions in UDP source/sink
gnuradio-core: update copyrights
libvrt: remove from 3.3 API.
Merge remote branch 'gnuradio/wip/udp_source_sink'
Fix erroneous file modes
usrp2-firmware: fix missing files in tarball
Merge remote branch 'ets/grc-usrp2-clock-source'
Update revision to 3.3.0-rc2

Johnathan Corgan
Corgan Enterprises LLC

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio