[Discuss-gnuradio] USRP for GPS

[Walter Barmak]

hi,

i was wondering whether the usrp can be used as a "gps receiver". if so,
1) how can i achieve this? 

2) any link you could provide for me to read?


3) what daughterboards should be used?

4) Can the usrp be used with OpenGTS (for example) for tracking (usrp as
a gps receiver)?

thanks in advance,
walter


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Want to help? Here's something....

[Tom Rondeau]

Hello everyone,
Here's a general call for help on the GNU Radio project if you are so
inclined. If you've wanted to contribute back to the code, but weren't sure
how to make a difference, there are lots of little things to look at. We've
set up a Jenkins continuous integration server that keeps track of the code
issues, including enumerating all "TODO" and "FIXME" comments through the
source code. It also tests and graphs the test code we've put in there. You
can see these results here:

http://www.gnuradio.org/jenkins/job/GNURadio-master/

What we want to see is the red and yellow graph lines going down and the
blue lines going up. The blue graph is the number of QA tests run. Any more
QA tests for a) blocks that do not currently have any QA code or b) more
corner cases for blocks already being tested would be most welcome.

The red and yellow lines mostly represent compiler warnings and TODO/FIXMEs.
Many of these might be very quickly resolvable with a few lines changed.
Some of them are probably more complex to know what the right answer is, so
if you have some ideas, start a thread on the mailing list to discuss what
the right fix might be.

Keep in mind on the warnings that libusrp and libusrp2 seem to be the cause
of most of them. I wouldn't worry about fixing these because those have been
deprecated and will be removed from the code when we release the next
version.

So while many of these bugs/issues/warnings/todo's have been around for a
while and haven't seemed to hurt anything, any time we remove one of these,
we've made the code better, more robust and reliable, and less likely to
cause headaches in the future. Every little bit helps.

Thanks!
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Want to help? Here's something....

[Philip Balister]

On 10/03/2011 11:32 AM, Tom Rondeau wrote:

Hello everyone,
Here's a general call for help on the GNU Radio project if you are so
inclined. If you've wanted to contribute back to the code, but weren't sure
how to make a difference, there are lots of little things to look at. We've
set up a Jenkins continuous integration server that keeps track of the code
issues, including enumerating all "TODO" and "FIXME" comments through the
source code. It also tests and graphs the test code we've put in there. You
can see these results here:

http://www.gnuradio.org/jenkins/job/GNURadio-master/

What we want to see is the red and yellow graph lines going down and the
blue lines going up. The blue graph is the number of QA tests run. Any more
QA tests for a) blocks that do not currently have any QA code or b) more
corner cases for blocks already being tested would be most welcome.

The red and yellow lines mostly represent compiler warnings and TODO/FIXMEs.
Many of these might be very quickly resolvable with a few lines changed.
Some of them are probably more complex to know what the right answer is, so
if you have some ideas, start a thread on the mailing list to discuss what
the right fix might be.


I am looking at the warnings in audio_alsa_sink.cc, but I do not see 
them output on the console when I do compiles. Any ideas? I believe I 
see why they occur and how to fix them, just trying to make sure the 
warnings are really there. Is libtool screwing us over?


Philip

 >

Keep in mind on the warnings that libusrp and libusrp2 seem to be the cause
of most of them. I wouldn't worry about fixing these because those have been
deprecated and will be removed from the code when we release the next
version.

So while many of these bugs/issues/warnings/todo's have been around for a
while and haven't seemed to hurt anything, any time we remove one of these,
we've made the code better, more robust and reliable, and less likely to
cause headaches in the future. Every little bit helps.

Thanks!
Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Work on USRP source and sink stream

[Feng Andrew Ge]

Josh,

Thanks for posting your work on stream tag.

I'd like to try out your code. Would you please tell me which version of 
GNU Radio to use with your code examples? Any other specific requirements?


I will let you know what I will get.

Thanks,
Andrew


On 09/24/2011 12:01 PM, discuss-gnuradio-requ...@gnu.org wrote:

Message: 3
Date: Fri, 23 Sep 2011 14:08:39 -0700
From: Josh Blum
To:"Discuss-gnuradio@gnu.org"  
Subject: Re: [Discuss-gnuradio] Work on USRP source and sink stream
tagging for gr-uhd
Message-ID:<4e7cf557.6010...@ettus.com>
Content-Type: text/plain; charset=ISO-8859-1

Added an example C++ app to demonstrate source and sink tagging:

http://gnuradio.org/cgit/jblum.git/tree/gr-uhd/examples?h=uhd_features&id=ddfddc5c20e2ee4f9a12796100089c203aa4ef27

gr-uhd/examples/tags_demo --help
UHD Tags Demo Allowed options:
   --help help message
   --addr arg the device address in string format
   --rate arg (=100)  the sample rate in samples per second
   --freq arg (=1000) the center frequency in Hz
   --burst arg (=0.10001) the duration of each burst in seconds
   --idle arg (=0.050003) idle time between bursts in seconds

The tags sink demo block will print USRP source time stamps.
The tags source demo block will send bursts to the USRP sink.
Look at the USRP output on a scope to see the timed bursts.

-Josh



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Want to help? Here's something....

[Tom Rondeau]

On Mon, Oct 3, 2011 at 1:27 PM, Philip Balister  wrote:

> On 10/03/2011 11:32 AM, Tom Rondeau wrote:
>
>> Hello everyone,
>> Here's a general call for help on the GNU Radio project if you are so
>> inclined. If you've wanted to contribute back to the code, but weren't
>> sure
>> how to make a difference, there are lots of little things to look at.
>> We've
>> set up a Jenkins continuous integration server that keeps track of the
>> code
>> issues, including enumerating all "TODO" and "FIXME" comments through the
>> source code. It also tests and graphs the test code we've put in there.
>> You
>> can see these results here:
>>
>> http://www.gnuradio.org/**jenkins/job/GNURadio-master/
>>
>> What we want to see is the red and yellow graph lines going down and the
>> blue lines going up. The blue graph is the number of QA tests run. Any
>> more
>> QA tests for a) blocks that do not currently have any QA code or b) more
>> corner cases for blocks already being tested would be most welcome.
>>
>> The red and yellow lines mostly represent compiler warnings and
>> TODO/FIXMEs.
>> Many of these might be very quickly resolvable with a few lines changed.
>> Some of them are probably more complex to know what the right answer is,
>> so
>> if you have some ideas, start a thread on the mailing list to discuss what
>> the right fix might be.
>>
>
> I am looking at the warnings in audio_alsa_sink.cc, but I do not see them
> output on the console when I do compiles. Any ideas? I believe I see why
> they occur and how to fix them, just trying to make sure the warnings are
> really there. Is libtool screwing us over?
>
> Philip
>

I'm only seeing a FIXME as a way of avoiding the generation of
a compiler warning. So I don't think you would see this when compiling. It
looks like the question is what's the right way to set these and use them?
It comes from this:

  snd_pcm_access_mask_t *access_mask;
  snd_pcm_access_mask_t **access_mask_ptr = &access_mask; // FIXME:
workaround for compiler warning

I think the question is, is this level of indirection the right thing to do?

Let me know if you were talking about something else that I've missed.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Want to help? Here's something....

[Philip Balister]

On 10/03/2011 02:00 PM, Tom Rondeau wrote:

On Mon, Oct 3, 2011 at 1:27 PM, Philip Balister  wrote:


On 10/03/2011 11:32 AM, Tom Rondeau wrote:


Hello everyone,
Here's a general call for help on the GNU Radio project if you are so
inclined. If you've wanted to contribute back to the code, but weren't
sure
how to make a difference, there are lots of little things to look at.
We've
set up a Jenkins continuous integration server that keeps track of the
code
issues, including enumerating all "TODO" and "FIXME" comments through the
source code. It also tests and graphs the test code we've put in there.
You
can see these results here:

http://www.gnuradio.org/**jenkins/job/GNURadio-master/

What we want to see is the red and yellow graph lines going down and the
blue lines going up. The blue graph is the number of QA tests run. Any
more
QA tests for a) blocks that do not currently have any QA code or b) more
corner cases for blocks already being tested would be most welcome.

The red and yellow lines mostly represent compiler warnings and
TODO/FIXMEs.
Many of these might be very quickly resolvable with a few lines changed.
Some of them are probably more complex to know what the right answer is,
so
if you have some ideas, start a thread on the mailing list to discuss what
the right fix might be.



I am looking at the warnings in audio_alsa_sink.cc, but I do not see them
output on the console when I do compiles. Any ideas? I believe I see why
they occur and how to fix them, just trying to make sure the warnings are
really there. Is libtool screwing us over?

Philip



I'm only seeing a FIXME as a way of avoiding the generation of
a compiler warning. So I don't think you would see this when compiling. It
looks like the question is what's the right way to set these and use them?
It comes from this:

   snd_pcm_access_mask_t *access_mask;
   snd_pcm_access_mask_t **access_mask_ptr =&access_mask; // FIXME:
workaround for compiler warning

I think the question is, is this level of indirection the right thing to do?

Let me know if you were talking about something else that I've missed.

Tom



Arg, I get it. The warning only occurs on 32 bit machines since 
sizeof(long) = sizeof(int)


Philip

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Want to help? Here's something....

[Tom Rondeau]

On Mon, Oct 3, 2011 at 2:17 PM, Philip Balister  wrote:

> On 10/03/2011 02:00 PM, Tom Rondeau wrote:
>
>> On Mon, Oct 3, 2011 at 1:27 PM, Philip Balister
>>  wrote:
>>
>>  On 10/03/2011 11:32 AM, Tom Rondeau wrote:
>>>
>>>  Hello everyone,
 Here's a general call for help on the GNU Radio project if you are so
 inclined. If you've wanted to contribute back to the code, but weren't
 sure
 how to make a difference, there are lots of little things to look at.
 We've
 set up a Jenkins continuous integration server that keeps track of the
 code
 issues, including enumerating all "TODO" and "FIXME" comments through
 the
 source code. It also tests and graphs the test code we've put in there.
 You
 can see these results here:

 http://www.gnuradio.org/jenkins/job/GNURadio-master/
 http://www.gnuradio.org/jenkins/job/GNURadio-master/>
 >


 What we want to see is the red and yellow graph lines going down and the
 blue lines going up. The blue graph is the number of QA tests run. Any
 more
 QA tests for a) blocks that do not currently have any QA code or b) more
 corner cases for blocks already being tested would be most welcome.

 The red and yellow lines mostly represent compiler warnings and
 TODO/FIXMEs.
 Many of these might be very quickly resolvable with a few lines changed.
 Some of them are probably more complex to know what the right answer is,
 so
 if you have some ideas, start a thread on the mailing list to discuss
 what
 the right fix might be.


>>> I am looking at the warnings in audio_alsa_sink.cc, but I do not see them
>>> output on the console when I do compiles. Any ideas? I believe I see why
>>> they occur and how to fix them, just trying to make sure the warnings are
>>> really there. Is libtool screwing us over?
>>>
>>> Philip
>>>
>>>
>> I'm only seeing a FIXME as a way of avoiding the generation of
>> a compiler warning. So I don't think you would see this when compiling. It
>> looks like the question is what's the right way to set these and use them?
>> It comes from this:
>>
>>   snd_pcm_access_mask_t *access_mask;
>>   snd_pcm_access_mask_t **access_mask_ptr =&access_mask; // FIXME:
>>
>> workaround for compiler warning
>>
>> I think the question is, is this level of indirection the right thing to
>> do?
>>
>> Let me know if you were talking about something else that I've missed.
>>
>> Tom
>>
>>
> Arg, I get it. The warning only occurs on 32 bit machines since
> sizeof(long) = sizeof(int)
>
> Philip
>

Ah, I see. Yes, the machine that's running Jenkins is 32-bit. This should be
fixed in any case.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC graphs

[Feng Andrew Ge]

Michael,

Good description of the TPB running mechanism!

Here is a more detailed explanation with some graph illustrations (see 
page 2 of the linked paper):


http://gnuradio.org/redmine/attachments/download/264


Andrew

On 09/23/2011 12:01 PM, discuss-gnuradio-requ...@gnu.org wrote:

Message: 6
Date: Thu, 22 Sep 2011 15:52:17 -0400
From: Michael Dickens
To: Nick Foster
Cc: Achilleas Anastasopoulos,
discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] different CPU loads with 2 similar GRC
graphs
Message-ID:<1fc1f942-d97c-49c9-9a05-bd38f250b...@alum.mit.edu>
Content-Type: text/plain; charset=us-ascii

On Sep 22, 2011, at 1:00 PM, Nick Foster wrote:

>  Well, in answer to question 1, you don't need a throttle to avoid system 
instability. You really use the throttle to keep your computer from becoming 
entirely unresponsive when you have multiple threads with high priority running 
simultaneously as fast as they can

That would make an interesting test for Achilleas: Do test 1 using real-time 
priority&  see if that locks up the system or not.


>  I don't know the answer to question 2 -- I suspect to find the answer you're 
going to have to do some deep hunting in the scheduler.

Let me see if I can work anything out:

Roughly: In the TPB model when "progress is made" for a given block (e.g., data is generated or 
consumed), the appropriate thread(s) containing adjacent blocks are signaled (IIRC, from waiting on a 
condition)(e.g., if data is consumed then the prior block(s) [those generating the data] are notified).  When 
those threads wake up, they check to see whether or not they have enough input data and output space to do 
processing.  This check is done by the TPB "scheduler" -- it's an algorithm that you can read about 
in "gnuradio-core/src/lib/runtime/gr_block_executor.cc" if you really want to.  A given block 
cannot do processing until enough input data and output space area simultaneously available, and the TPB 
scheduler tries to maximize data processing.

For case #1, the signaling and scheduler's job is simple because each block is 
connected only to adjacent blocks.  If you were to plot out the block execution 
pattern, I'd guess it was something like:

(source == 1; sink == 2; E == "executing"; W == "waiting"):

Thread  Time ->
1E E E E E ...
AW E E E E ...
2W W E E E ...

For this case data is well-pipelined -- A can process as soon as 1 is finished, and 
2 can process as soon as A is finished.  Assuming A is CPU intensive&  the 
graph isn't otherwise throttled, then each block could easily saturate a single CPU 
(if that's how much processing each requires).

For case #2, the signaling and scheduler's job is complicated by the dual paths 
from source to sink.  If you were to plot out the block execution pattern, I'd 
guess it was something like:

(X == "waiting, unsuccessful execution, and then more waiting"; I switch from "W" to 
"X" because of the signaling between threads):

Thread  Time ->
1E E X E E X E E ...
AW E E X E E X E ...
2W X E X X E X X ...

So, in this case because of the odd data shuffling, you'll see somewhat less than full 
CPU usage (on the average).  The above "diagram" assumes that 1 is generating a 
sizable chunk of data (relative to the total buffer size), such that it can do one or two 
writes before its output buffer is full (that's roughly how the TPB scheduler works, 
btw).  The actual wait time-duration I think depends primarily on how long it takes A to 
do processing.  Either way: The basic idea is that the data is not well-pipelined, and 
hence there are waits that reduce the average CPU usage [another possible factor is how 
much overhead time is spent during X's (emerging from wait, checking for processing, then 
going back into wait)].

I hope this is reasonably accurate, makes sense, and helps! - MLD




--



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Work on USRP source and sink stream

[Josh Blum]

On 10/03/2011 10:50 AM, Feng Andrew Ge wrote:
> Josh,
> 
> Thanks for posting your work on stream tag.
> 
> I'd like to try out your code. Would you please tell me which version of
> GNU Radio to use with your code examples? Any other specific requirements?
> 

I believe the work is all merged into the master branch now.

Good luck!
-Josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP for GPS

[Wolfarth, Ryan]

Hi Walter,

My group is using the USRP to record raw RF data at GPS and GLONASS
frequencies.  We do all of our signal processing in post right now, but are
interested in developing a stand alone receiver.  If you search the mailing
list you'll find some other folks who are implementing GPS receivers on the
FPGA.  What kind of performance metrics are you hoping to obtain?  As far as
the daughter boards go, we use the RFX1200 and RFX1800.  I've also heard of
people using the SBX.

I have no answer to your question regarding OpenGTS: I'm fairly new to this
system as well.  If you're going to do real time tracking your best bet is
probably to modify the FPGA for performance considerations.  Hope this
helps!

Ryan

On Mon, Oct 3, 2011 at 11:00 AM, Walter Barmak wrote:

> hi,
>
> i was wondering whether the usrp can be used as a "gps receiver". if so,
> 1) how can i achieve this?
>
> 2) any link you could provide for me to read?
>
>
> 3) what daughterboards should be used?
>
> 4) Can the usrp be used with OpenGTS (for example) for tracking (usrp as
> a gps receiver)?
>
> thanks in advance,
> walter
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP for GPS

[Walter Barmak]

Hi Ryan,

Thanks very much for your answer! You mean you are inetersted in
developing a stand alone receiver "with" the USRP?

I'm sorry, what do you mean by performance metrics?

thanks again,
Walter

On Mon, 2011-10-03 at 15:52 -0300, Wolfarth, Ryan wrote:
> Hi Walter,
> 
> My group is using the USRP to record raw RF data at GPS and GLONASS
> frequencies.  We do all of our signal processing in post right now,
> but are interested in developing a stand alone receiver.  If you
> search the mailing list you'll find some other folks who are
> implementing GPS receivers on the FPGA.  What kind of performance
> metrics are you hoping to obtain?  As far as the daughter boards go,
> we use the RFX1200 and RFX1800.  I've also heard of people using the
> SBX.
> 
> I have no answer to your question regarding OpenGTS: I'm fairly new to
> this system as well.  If you're going to do real time tracking your
> best bet is probably to modify the FPGA for performance
> considerations.  Hope this helps!
> 
> Ryan
> 
> On Mon, Oct 3, 2011 at 11:00 AM, Walter Barmak
>  wrote:
> hi,
> 
> i was wondering whether the usrp can be used as a "gps
> receiver". if so,
> 1) how can i achieve this?
> 
> 2) any link you could provide for me to read?
> 
> 
> 3) what daughterboards should be used?
> 
> 4) Can the usrp be used with OpenGTS (for example) for
> tracking (usrp as
> a gps receiver)?
> 
> thanks in advance,
> walter
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [PATCH] Fix for warning

[philip]

From: Philip Balister 

Here is a proposed fix for a compile warning on 32 bit machines. I am
interested in feedback on how I replace the shift with 2^(NBITS-1). I
don't see any reason to keep teh shift, since the compiler should do the
math at compile time. I am a little worried about the NBITS=32 case and how
is implicitedly converted to a float.

Philip Balister (1):
  audio_alsa_sink : Fix warning on 32 bit builds.

 gr-audio/lib/alsa/audio_alsa_sink.cc |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

-- 
1.7.6.4


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [PATCH] audio_alsa_sink : Fix warning on 32 bit builds.

[philip]

From: Philip Balister 

On machines where sizeof(long) = sizeof(int) the code for calculating
scale factors produced an overflow warning. This change simplifies the
code by eliminating the shift. The compiler should calculate the constant
at compile time anyway.

Signed-off-by: Philip Balister 
---
 gr-audio/lib/alsa/audio_alsa_sink.cc |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gr-audio/lib/alsa/audio_alsa_sink.cc 
b/gr-audio/lib/alsa/audio_alsa_sink.cc
index 5fd197e..2aa6fc0 100644
--- a/gr-audio/lib/alsa/audio_alsa_sink.cc
+++ b/gr-audio/lib/alsa/audio_alsa_sink.cc
@@ -343,7 +343,7 @@ audio_alsa_sink::work_s16 (int noutput_items,
 bi = 0;
 for (unsigned int i = 0; i < d_period_size; i++){
   for (unsigned int chan = 0; chan < nchan; chan++){
-   buf[bi++] = (sample_t) (in[chan][i] * (float) ((1L << (NBITS-1)) - 1));
+   buf[bi++] = (sample_t) (in[chan][i] * ((2^(NBITS-1)) - 1));
   }
 }
 
@@ -385,7 +385,7 @@ audio_alsa_sink::work_s32 (int noutput_items,
 bi = 0;
 for (unsigned int i = 0; i < d_period_size; i++){
   for (unsigned int chan = 0; chan < nchan; chan++){
-   buf[bi++] = (sample_t) (in[chan][i] * (float) ((1L << (NBITS-1)) - 1));
+   buf[bi++] = (sample_t) (in[chan][i] * ((2^(NBITS-1)) - 1));
   }
 }
 
@@ -427,7 +427,7 @@ audio_alsa_sink::work_s16_1x2 (int noutput_items,
 // process one period of data
 bi = 0;
 for (unsigned int i = 0; i < d_period_size; i++){
-  sample_t t = (sample_t) (in[0][i] * (float) ((1L << (NBITS-1)) - 1));
+  sample_t t = (sample_t) (in[0][i] * ((2^(NBITS-1)) - 1));
   buf[bi++] = t;
   buf[bi++] = t;
 }
@@ -469,7 +469,7 @@ audio_alsa_sink::work_s32_1x2 (int noutput_items,
 // process one period of data
 bi = 0;
 for (unsigned int i = 0; i < d_period_size; i++){
-  sample_t t = (sample_t) (in[0][i] * (float) ((1L << (NBITS-1)) - 1));
+  sample_t t = (sample_t) (in[0][i] * ((2^(NBITS-1)) - 1));
   buf[bi++] = t;
   buf[bi++] = t;
 }
-- 
1.7.6.4


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] New Product Announcements from Ettus Research

[Matt Ettus]

=

New Product Announcements from Ettus Research

=

We are very excited to announce the immediate availability of the
latest low cost Software Radio product from Ettus Research, the
USRP(tm) B100.  The B100 has the following features:

- USB 2.0 interface
- Xilinx Spartan 3A-1400 FPGA
- Compatibility with our entire daughterboard family
- Fully supported by UHD drivers
- Dual 64 MS/s 12-bit ADCs
- Dual 128 MS/s 14-bit DACs
- Onboard TCXO for precise frequency control
- 10 MHz and 1 PPS inputs for external references
- Flexible clocking from 10 MHz to 64 MHz
- 8 MHz of RF bandwidth with 16 bit samples
- 16 MHz of RF bandwidth with 8 bit samples


The price is $650 each, and the B100 is in stock and ready to ship.

=

The USRP E110 has a larger FPGA (Spartan 3A-DSP 3400) than
the E100, but is otherwise the same.  This is perfect for those who
wish to offload DSP operations from the main ARM processor.

Both the E100 and E110 are now fully compatible with the GPSDO.

The price of the USRP E110 is $1500 and the E100 is $1300.
Both the E100 and E110 are in stock and ready to ship.

=

As always, you can purchase all of our products through:

http://www.ettus.com/order

and you can contact sa...@ettus.com if you have any further
questions.

Thanks,
Matt Ettus
President, Ettus Research LLC
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New Product Announcements from Ettus Research

[Richard Clarke]

Hi Matt,

just wondering what the PPM spec is of the onboard TCXO? Will the datasheet
be available soon?

Thanks

Regards
Richard

On 4 October 2011 10:05, Matt Ettus  wrote:

>
> =
>
> New Product Announcements from Ettus Research
>
> =
>
> We are very excited to announce the immediate availability of the
> latest low cost Software Radio product from Ettus Research, the
> USRP(tm) B100.  The B100 has the following features:
>
> - USB 2.0 interface
> - Xilinx Spartan 3A-1400 FPGA
> - Compatibility with our entire daughterboard family
> - Fully supported by UHD drivers
> - Dual 64 MS/s 12-bit ADCs
> - Dual 128 MS/s 14-bit DACs
> - Onboard TCXO for precise frequency control
> - 10 MHz and 1 PPS inputs for external references
> - Flexible clocking from 10 MHz to 64 MHz
> - 8 MHz of RF bandwidth with 16 bit samples
> - 16 MHz of RF bandwidth with 8 bit samples
>
>
> The price is $650 each, and the B100 is in stock and ready to ship.
>
> =
>
> The USRP E110 has a larger FPGA (Spartan 3A-DSP 3400) than
> the E100, but is otherwise the same.  This is perfect for those who
> wish to offload DSP operations from the main ARM processor.
>
> Both the E100 and E110 are now fully compatible with the GPSDO.
>
> The price of the USRP E110 is $1500 and the E100 is $1300.
> Both the E100 and E110 are in stock and ready to ship.
>
> =
>
> As always, you can purchase all of our products through:
>
> http://www.ettus.com/order
>
> and you can contact sa...@ettus.com if you have any further
> questions.
>
> Thanks,
> Matt Ettus
> President, Ettus Research LLC
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
*SCOTT ADAMS: Normal people believe that if it ain't broke, don't fix it.
Engineers believe that if it ain't broke, it doesn't have enough features
yet.*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Fix for warning in audio_alsa_sink.cc

[Philip Balister]

A sane fix:

https://github.com/balister/GNU-Radio/commit/fd21bd2c74677d2c1722bc585ccdeaf1522e0d59

Philip

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Rx data streaming in C++ for custom firmware

[Michael Hadmack]

Hi Everyone,

I am running custom FPGA firmware for a low latency control system on
a USRP1.  Presently I am using a variant of the usrper.cc tool for
loading firmware and control of command registers in the FPGA.  I need
to be able to stream data over USB into a file or other application
but this is not a straightforward addition to the usrper code since
the implementation in usrp_basic_rx relies on the low level fusb code.
I have attempted to subclass usrp_basic_rx to make use of
usrp_basic::read().  This works fine except that when my program quits
the usrp_basic destructors reset some FPGA registers intrupting
operation of the device.
What I really need is a program like usrper which can interact with
the USRP1 interactively without reinitialization/deinitialization but
with the ability to stream data over USB.  Is there something like
this in the gnuradio codebase that I am missing?  It seems I have
three options:

1. Reimplement the usrp_basic::read functionality withing usrper
2. Subclass usrp_basic rather than usrp_basic_rx and to avoid
destructor behavior (still need to reimplement read())
3. Try to do this with the UHD driver instead (I don't know if this
will help at all)

I appreciate any suggestions.

-Mike

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] New Product Announcements from Ettus Research

[Matt Ettus]

On Mon, Oct 3, 2011 at 2:34 PM, Richard Clarke  wrote:

> Hi Matt,
>
> just wondering what the PPM spec is of the onboard TCXO? Will the datasheet
> be available soon?
>
>
2.5 ppm.  Datasheet may not be ready for a week or two.

Matt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] truncating bits

[sirjanselot]

Hello,

I have a question in bit truncation. 

Say I have a 14-bit FM waveform, digitized.  Underneath that signal
assuming they are both in the same frequency, there is another signal say
an AM signal.  The difference between the two is about 40 dB.  Is there way
such that I can remove the AM signal that is below the FM signal by bit
truncation?

I am curious as how the operation of truncating bits work.  If I do this,
since the FM signal is still about 56 dB higher than the AM signal, if I
were to take the MSBs and and truncate the LSBs that contain AM signal,
will I still be able to demodulate the FM signal?  

I am having a hard demonstrating this in matlab to myself since I do know
how to use fixed-point toolbox (yet) so if somebody could please explain I
would be very greatful.  

How can I do truncate bits in gnuradio?
-- 
View this message in context: 
http://old.nabble.com/truncating-bits-tp32586703p32586703.html
Sent from the GnuRadio mailing list archive at Nabble.com.


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio