Re: [Discuss-gnuradio] Fwd: Proposal for GSoC on gr-gsm

2014-03-16 Thread zhenhua han 
Hi,

My proposal has been updated on github.
The proposal has been changed a lot according to the comments on Melange.

1.The flow graph has been changed. A new architecture is designed.
2.A state machine is added which explains more details on GSM decoder.
3.The deliverable list has been changed.
4.The schedule has been changed according to the new architecture.

Looking forward to further advises :)

Best wishes,
Zhenhua

2014-03-13 21:12 GMT+08:00 zhenhua han :

> The figure in the previous mail is incorrect.
> It is too weird that the ratio is so low and with narrow transition. And
> the sample count is not match the FB.
>
> After some debugs, I found the reason. I got the sample data with GNU
> Radio companion. When I execute the flow graph, it starts to write data
> into the file before my RTL-SDR started. So there are lots of invalid
> samples at the start.
>
> I have fixed this bug. Here is a correct (maybe :) ) figure. The sample
> rate is 1.25M sps. The FCCH burst lasts about 700 samples which equals 0.56
> ms. The duration of a standard FB is 0.57 ms. It seems correct.
>
> I have updated this part in my proposal. Sorry for my mistakes.[image:
> 内嵌图片 1]
>
>
> Best,
> Zhenhua
>
>
> 2014-03-13 11:27 GMT+08:00 zhenhua han :
>
> Oh, I forgot to say. The data is sampled by a RTL-SDR.
>>
>> Zhenhua
>>
>>
>> 2014-03-13 11:25 GMT+08:00 zhenhua han :
>>
>> Hi,
>>>
>>> I have implemented the algorithm in the paper for test and uploaded my
>>> code to github.
>>>
>>> https://github.com/hzhua/gr-fchdetection
>>>
>>> The result given by the algorithm seems great.
>>>
>>> Here is a figure generated by my program which is the ratio of average
>>> error power to input power. It is very low at frequency burst and high at
>>> other bursts.
>>> [image: 内嵌图片 1]
>>> I have also added this part in my proposal.
>>>
>>> Best,
>>> Zhenhua
>>>
>>>
>>>
>>> 2014-03-11 21:41 GMT+08:00 Bogdan Diaconescu :
>>>
>>> I totally agree with Martin regarding PFB channelizer. The PFB for gsm
 will be also a good challenge for gnuradio in general as obtaining only a
 moderate number of channels(say 50) takes a lot of processing power and
 achieving realtime processing is not possible currently. Split per thereads
 and VOLK should be taken in consideration.

 Bogdan





   On Tuesday, March 11, 2014 2:30 PM, Martin Braun <
 martin.br...@ettus.com> wrote:
   On 03/11/2014 11:14 AM, zhenhua han wrote:
 > -- Forwarded message --
 > From: *zhenhua han* mailto:hzhua...@gmail.com>>
 > Date: 2014-03-11 16:00 GMT+08:00
 > Subject: Re: [Discuss-gnuradio] Proposal for GSoC on gr-gsm
 > To: Bogdan Diaconescu >>> > >
 >
 >
 > Thank you, Bogdan. Your work is a great help in developing the channel
 > hopping part.
 > As there are only 14 weeks in GSoC, the schedule is a little tight.
 > However, I will continue working on this project after GSoC (if I am
 > selected). And Channel hopping will be the first task after I finish
 all
 > the tasks planned in GSoC.

 You should definitely check out the PFB channelization, though. For
 multi-ARFCN applications, this will always be a requirement.


 M


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



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


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

[Discuss-gnuradio] Throttle question

2014-03-16 Thread Volker Schroer 

For testing purposes I use
vector source (byte ) -> vector to stream -> throttle -> [blocks to test]
In the vector source "repeat" is set to "yes" and the sample rate is set 
to 1024 ( and in the throttle block , too ).


I would expect that the throttle delivers 1024 samples every second. But 
I see that the throttle delivers 32768 bytes about every 32 seconds. ( 
Which is on average 1024 samples per second ).
Is this the expected behavior or should the samples be delivered  every 
second ?


-- Volker


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

Re: [Discuss-gnuradio] Throttle question

2014-03-16 Thread Sylvain Munaut 
Hi,

> For testing purposes I use
> vector source (byte ) -> vector to stream -> throttle -> [blocks to test]
> In the vector source "repeat" is set to "yes" and the sample rate is set to
> 1024 ( and in the throttle block , too ).
>
> I would expect that the throttle delivers 1024 samples every second. But I
> see that the throttle delivers 32768 bytes about every 32 seconds. ( Which
> is on average 1024 samples per second ).
> Is this the expected behavior or should the samples be delivered  every
> second ?

Excpected I wouldn't say so, but there is no guarantee basically. Only
long term average rate is correct, the rest is kind of up to the OS
scheduler that says when thread runs ...

At every iteration of the work() function, the block will let as much
sample pass depending on the time since the last call.
But for very very low rates (like 1k/s) that's probably not going to
go over very well because things tend to be processed by "block".

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] For Sale: bladeRF x115 with GPIO expansion

2014-03-16 Thread Attila Kinali 
On Sat, 15 Mar 2014 20:57:02 -0500
Louis Brown  wrote:

> Quite so.  I have a GPSDO though, so it's nice to be able to lock to that. 
> Last week I recorded WWVB (60 kHz) amplitude and phase for 1 week to monitor
> propagation.  Interesting results to see the fades over 6 days  Phase was
> futile though as their new BPSK mod messes things up.

I'd be interested in the results of your analysis.
Heck, i'd be even interested in the raw data :-)

And yes, the insanly stupid PSK modulation scheme of WWVB is a pain for
everyone. :-(

Attila Kinali

-- 
I pity people who can't find laughter or at least some bit of amusement in
the little doings of the day. I believe I could find something ridiculous
even in the saddest moment, if necessary. It has nothing to do with being
superficial. It's a matter of joy in life.
-- Sophie Scholl

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

Re: [Discuss-gnuradio] Throttle question

2014-03-16 Thread Marcus Müller 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Volker,

yes, that is expected behaviour. Most probably ;)
For explanation: Since GNU Radio itself always passes around multiple
items at once (so your work doesn't get called), all throttle can do is
limit the average rate, unless it would consume one input item at a
time, stall work as long as necessary and then output that one item.
For higher sample rates (where the flow graph is nearly CPU-limited),
which is the original use case of throttle (stopping GNU Radio from
completely clogging the CPU) this would imply a considerable overhead.

What you can try is call the public
gr::block::set_max_noutput_items(int) method on your throttle block
*prior* to starting the flow graph. This should tell the scheduler to
call the throttle's work function with smaller numbers of input
samples (also, it reduces the output buffer size if that is feasible
for the downstream block).
Also, try smaller values for the max_output_buffer size of the vector
source, maybe (that could be even accessible in the GNU Radio
companion block property dialog).

one more question in that context: why the vector to stream? the
vector source can output single samples, too. Just set the vector
length to 1.

Greetings,
Marcus

On 16.03.2014 17:35, Volker Schroer wrote:
> For testing purposes I use vector source (byte ) -> vector to
> stream -> throttle -> [blocks to test] In the vector source
> "repeat" is set to "yes" and the sample rate is set to 1024 ( and
> in the throttle block , too ).
> 
> I would expect that the throttle delivers 1024 samples every
> second. But I see that the throttle delivers 32768 bytes about
> every 32 seconds. ( Which is on average 1024 samples per second ). 
> Is this the expected behavior or should the samples be delivered
> every second ?
> 
> -- Volker
> 
> 
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org 
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTJdimAAoJEBQ6EdjyzlHtheAH/iv6UnTFsr0z+BftZO535iDu
kKZa4ik0wnYMv83byngbqX9RClzCATeTxSKgav9EwKIF66jAwH3l5Ojb+wv9SA4C
4gSttXCktHwCU7lcSPaAQMQzJIKOEJUlHPgd67iGxMVuu67RPDZoFyQiWSHaRaV1
kwhk4KgZs/Ku+ORvaMNJk3caTs9OUJkBvbqxvr1DCWZyHXS/CDh3is7XJMONcLRR
d0XzELkMic9MdbkT/ljnjujlPaMtlw+VM3SvU8Cfvm/lLif9KsLE0PdjF4yWbFpZ
Ct+RoD1/HZMUhceBZL804ty7xlNrt73B7jZgT9ZmgzxkEqoyw54UeoXnrIZeIjg=
=+VI7
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Throttle question

2014-03-16 Thread Volker Schroer 

Thanks for the tips.

Setting the Max Output bufferin the throttle block did the trick.
Yes, the vector to stream block can be avoided. The default vector 
length is 1 in grc.


Now testing works much smoother.

Good to know.

-- Volker


Am 16.03.2014 18:00, schrieb Marcus Müller:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Volker,

yes, that is expected behaviour. Most probably ;)
For explanation: Since GNU Radio itself always passes around multiple
items at once (so your work doesn't get called), all throttle can do is
limit the average rate, unless it would consume one input item at a
time, stall work as long as necessary and then output that one item.
For higher sample rates (where the flow graph is nearly CPU-limited),
which is the original use case of throttle (stopping GNU Radio from
completely clogging the CPU) this would imply a considerable overhead.

What you can try is call the public
gr::block::set_max_noutput_items(int) method on your throttle block
*prior* to starting the flow graph. This should tell the scheduler to
call the throttle's work function with smaller numbers of input
samples (also, it reduces the output buffer size if that is feasible
for the downstream block).
Also, try smaller values for the max_output_buffer size of the vector
source, maybe (that could be even accessible in the GNU Radio
companion block property dialog).

one more question in that context: why the vector to stream? the
vector source can output single samples, too. Just set the vector
length to 1.

Greetings,
Marcus

On 16.03.2014 17:35, Volker Schroer wrote:

For testing purposes I use vector source (byte ) -> vector to
stream -> throttle -> [blocks to test] In the vector source
"repeat" is set to "yes" and the sample rate is set to 1024 ( and
in the throttle block , too ).

I would expect that the throttle delivers 1024 samples every
second. But I see that the throttle delivers 32768 bytes about
every 32 seconds. ( Which is on average 1024 samples per second ).
Is this the expected behavior or should the samples be delivered
every second ?

-- Volker


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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTJdimAAoJEBQ6EdjyzlHtheAH/iv6UnTFsr0z+BftZO535iDu
kKZa4ik0wnYMv83byngbqX9RClzCATeTxSKgav9EwKIF66jAwH3l5Ojb+wv9SA4C
4gSttXCktHwCU7lcSPaAQMQzJIKOEJUlHPgd67iGxMVuu67RPDZoFyQiWSHaRaV1
kwhk4KgZs/Ku+ORvaMNJk3caTs9OUJkBvbqxvr1DCWZyHXS/CDh3is7XJMONcLRR
d0XzELkMic9MdbkT/ljnjujlPaMtlw+VM3SvU8Cfvm/lLif9KsLE0PdjF4yWbFpZ
Ct+RoD1/HZMUhceBZL804ty7xlNrt73B7jZgT9ZmgzxkEqoyw54UeoXnrIZeIjg=
=+VI7
-END PGP SIGNATURE-

___
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] GSoC 2014 proposal

2014-03-16 Thread Chandan Pradhan 
Hi all,
I am giving link for my draft for the proposal for GSoC 2014. It would be
great if you could give your feedback before i file my final application.

https://github.com/201332539IIITH/GSoC-14/blob/master/Proposal%20for%20GSoc%2014.pdf
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] uhd_fft missing

2014-03-16 Thread Chris Stankevitz 
Hello,

Using gentoo linux I installed uhd and gnuradio with the commands
"emerge uhd" and "emerge gnuradio".  According to
http://gnuradio.org/redmine/projects/gnuradio/wiki/HowToUse:

"GNU Radio comes with a large variety of tools and programs... The
most commonly used tools include uhd_fft"

Unfortunately I do not have uhd_fft on my system.  I do have
uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance , uhd_images_downloader,
uhd_cal_tx_dc_offset, uhd_find_devices, and uhd_usrp_probe.

According to 
http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource:

"If you want to be able to use USRP devices, you need to install UHD
before installing GNU Radio."

Questions:

Q1: Why do I not have uhd_fft on my system?

Q2: What is the technically going on that leads to the warning about
installing UHD before gnuradio?  What are the consequences of
installing UHD after GNU Radio?

Q3: Which package provides the file uhd_fft: GNU Radio, UHD, or something else?

Thank you,

Chris

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

Re: [Discuss-gnuradio] uhd_fft missing

2014-03-16 Thread Marcus D. Leech 

On 03/16/2014 03:20 PM, Chris Stankevitz wrote:

Hello,

Using gentoo linux I installed uhd and gnuradio with the commands
"emerge uhd" and "emerge gnuradio".  According to
http://gnuradio.org/redmine/projects/gnuradio/wiki/HowToUse:

"GNU Radio comes with a large variety of tools and programs... The
most commonly used tools include uhd_fft"

Unfortunately I do not have uhd_fft on my system.  I do have
uhd_cal_rx_iq_balance, uhd_cal_tx_iq_balance , uhd_images_downloader,
uhd_cal_tx_dc_offset, uhd_find_devices, and uhd_usrp_probe.

According to 
http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource:

"If you want to be able to use USRP devices, you need to install UHD
before installing GNU Radio."

Questions:

Q1: Why do I not have uhd_fft on my system?

I can't answer that one


Q2: What is the technically going on that leads to the warning about
installing UHD before gnuradio?  What are the consequences of
installing UHD after GNU Radio?
If you're building from source, the source-build needs to know where UHD 
is installed on your system before it can build gr-uhd, since gr-uhd
  links again UHD libraries.  It can't very well do that until UHD has 
already been installed





Q3: Which package provides the file uhd_fft: GNU Radio, UHD, or something else?

It's part of gr-uhd/apps




Thank you,

Chris

___
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] uhd_fft missing

2014-03-16 Thread Sylvain Munaut 
> Q1: Why do I not have uhd_fft on my system?

Since you're using gentoo, I think the most likely scenario is that
the 'wx' USE flag is disabled.

uhd_fft is a python WXwidget application, so if you disabled this, you
will not have it.

Cheers,

   Sylvain

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

Re: [Discuss-gnuradio] uhd_fft missing

2014-03-16 Thread Chris Stankevitz 
On Sun, Mar 16, 2014 at 12:48 PM, Sylvain Munaut <246...@gmail.com> wrote:
> Since you're using gentoo, I think the most likely scenario is that
> the 'wx' USE flag is disabled.

Sylvain,

Thank you for your help.  Turns out I the wxwidgets USE flag us set...
but the uhd USE flag was unset.  Rebuilding now, but I'm sure this
will fix the problem.  BTW, as you might guess, the uhd USE flag
causes net-wireless/gnuradio to bring in net-wireless/uhd.  I should
have known something was up when I had to manually emerge uhd.

Chris

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

Re: [Discuss-gnuradio] uhd_fft missing

2014-03-16 Thread Chris Stankevitz 
On Sun, Mar 16, 2014 at 12:31 PM, Marcus D. Leech  wrote:
> If you're building from source, the source-build needs to know where UHD is
> installed on your system before it can build gr-uhd, since gr-uhd
>   links again UHD libraries.

Marcus,

Thank you.  In gentoo speak, what you said typically translates to
"The gnuradio ebuild has a uhd USE flag.  Make sure the uhd USE flag
is enabled."  Well, I checked and sure enough it was disabled.  I'm
rebuilding now but I'm sure it will work correctly.

Thanks again,

Chris

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

Re: [Discuss-gnuradio] uhd_fft missing

2014-03-16 Thread Marcus D. Leech 

On 03/16/2014 05:06 PM, Chris Stankevitz wrote:


Marcus,

Thank you.  In gentoo speak, what you said typically translates to
"The gnuradio ebuild has a uhd USE flag.  Make sure the uhd USE flag
is enabled."  Well, I checked and sure enough it was disabled.  I'm
rebuilding now but I'm sure it will work correctly.

Thanks again,

Chris
The nice thing about distribution-specific idioms isthere's too 
damned many from which to choose. :(


People often criticize build-gnuradio because it "doesn't cover *my* 
particular distribution", as if adding support for a new distrib

  is as easy as dumping Nigerian spam in your junk folder

One of Linux' most serious weaknesses has emerged from its most profound 
strength--there are now dozens of distribs extant, each
  with their own peculiar packaging tools, idioms, and filesystem 
layouts, and with that, troubleshooting strategies.  If I were in charge of

  the world, there would only be one Linux distribution :) :)



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

[Discuss-gnuradio] error with GR-DVB : macro missing

2014-03-16 Thread winston . smith . estasia 
Hi everybody,

I'm trying to install the gr-dvb project from Edmund Tse
(https://github.com/EdmundTse/gr-dvb) on gnruradio 3.5.3.2.

When I launch the ./configure command during the install process, I
get this kind of errors :

LF_COMMAND_CC : command not found
LF_COMMAND_CXX : command not found
LF_SET_WARNINGS : command not found
...

I searched on the Internet and I found that it would be macros missing
in the last autotools version. Could you tell me more about that ? Is
there any method to fix these errors ?

Thanks,

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

[Discuss-gnuradio] GNU Radio releases 3.7.3 and 3.7.2.2

2014-03-16 Thread Johnathan Corgan 
GNU Radio releases 3.7.3 and 3.7.2.2 are available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.3.tar.gz
http://gnuradio.org/releases/gnuradio/gnuradio-3.7.2.2.tar.gz

MD5 sums:

a51e1c2860d6b289233e453d4085514f  gnuradio-3.7.3.tar.gz
2b2c11c8df0bec0879033ca74b6264a3  gnuradio-3.7.2.2.tar.gz

The 3.7.2.2 release is a bug-fix only release, accumulating all the
fixes that have occurred since the 3.7.2.1 release.

Release 3.7.3 contains all of the above, and new features as well that
are compatible within the 3.7 API.

h2. Contributors to this release

We'd like to thank the large list of people below for their
contributions to the GNU Radio Project:

* Alistair Bird 
* Artem Pisarenko 
* Bastian Bloessl 
* Chuck Swiger 
* Clayton Smith 
* Doug Geiger 
* Ethan Trewhitt 
* Florian Franzen 
* Jakub Zy 
* Johannes Schmitz 
* Johnathan Corgan 
* Julien Olivain 
* Kevin Zheng 
* Marcus Müller 
* Martin Braun 
* Michael Dickens 
* Moritz Fischer 
* Nathan West 
* Nicholas Corgan 
* Nick Foster 
* Philip Balister 
* Ron Economos 
* Roy Thompson 
* Sebastian Koslowski 
* Steve Glass 
* Steve Haynal 
* Steve Markgraf 
* Sylvain Munaut <246...@gmail.com>
* Tim O'Shea 
* Tom Rondeau 
* Volker Schroer 

Release notes may be found at:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_7_3/

Enjoy!

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] WWVB monitoring with GNU radio

2014-03-16 Thread Louis Brown 

On Mar 16, 2014, at 12:00 PM, Attila Kinali  wrote:

> I'd be interested in the results of your analysis.
> Heck, i'd be even interested in the raw data :-)
> 
> And yes, the insanly stupid PSK modulation scheme of WWVB is a pain for
> everyone. :-(

I switched this reply to the thread I posted last night, which has the plot and 
python files.  Here is the raw data:


https://dl.dropboxusercontent.com/u/49570443/rms_amplitude.bin

https://dl.dropboxusercontent.com/u/49570443/phase.bin



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

[Discuss-gnuradio] GNU Radio Release 3.7.3 In MacPorts on OSX

2014-03-16 Thread Michael Dickens 
The GNU Radio 3.7.3 Release is in MacPorts, and contains a massive overhaul of 
the OSX native audio interface that fixes all known bugs / issues with it as 
well as adds device selection by name and other cool features.  To update, 
you'll want to do the following, minimally:

{{{
sudo port sync
sudo port upgrade gnuradio
}}}

or, if you want to be thorough:

{{{
sudo port selfupdate
sudo port upgrade outdated
}}}

This update should work for both gnuradio (3.7.3) and gnuradio-devel (3.7.4 git 
69dcaa75).  Enjoy! - MLD
--
Michael Dickens, OSX Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com


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

[Discuss-gnuradio] Ettus Research USRP N210

2014-03-16 Thread pauljonson72 
Hello!
I am selling SDR devices, used:

1 x Ettus Research USRP N210 
Datasheet:
https://www.ettus.com/content/files/07495_Ettus_N200-210_DS_Flyer_HR_1.pdf
+ 1 x Ethernet cable
+ 1 x Power supply

1 x Ettus Research SBX board rev.5 
SBX 400-4400 MHz Rx/Tx (40 MHz) USRP Daughterboard (400 MHz - 4.4 GHz)
Datasheet: https://www.ettus.com/product/details/SBX
+ 1 x SMA-Bulkhead

Please, you can talk with me about price!
All devices are working and in good condition. Devices was used not much.
Worldwide shipping.

pauljonso...@gmail.com



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Ettus-Research-USRP-N210-tp47016.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