Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Questions about input data in USRP n210 (???)
2. Re: Questions about input data in USRP n210 (Marcus M?ller)
3. Re: B210 over Network? (Jason A. Donenfeld)
4. Re: B210 over Network? (Raj Bhattacharjea)
5. Re: B210 over Network? (Marcus M?ller)
6. Re: USRP UHD Library Release suggestion (hossein talaiee)
7. Re: USRP UHD Library Release suggestion (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Apr 2015 10:00:59 +0900 (KST)
From: ??? <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Questions about input data in USRP n210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Sorry to vague explain about my experiments.
Simply, I want to receive the external source packet(802.3 Ethernet packet) and
transmit the packet by using USRP N210 with X2450 Daughterboard
and receive the signal the USRP receiver. And then sends packets to other
devices.
Ex,
External signal(ex. music packet) ---> Transmitter USRP --> wireless
channel --> Receiver USRP --> external receiver(ex. speaker)
Thanks
Jaehoon
-----Original Message-----
From: "Marcus M?ller"<[email protected]>
To: "???"<[email protected]>;
Cc: <[email protected]>;
Sent: 2015-04-20 (?) 00:39:46
Subject: Re: [USRP-users] Questions about input data in USRP n210
Dear Jaehoon,
I'm sorry, I did not understand your question. Could you try to say it a bit
simpler?
Best regards,
Marcus
On April 19, 2015 1:45:31 PM CEST, "???" <[email protected]> wrote:
Thanks for replying my questions.
Anyone who uses the grc example about take a sampled signal and convert it to
an analog band-limited signal and mix it to the desired frequency
and sends analog signal to other devices such as switch?
Thanks
-----Original Message-----
From: "Marcus M?ller via USRP-users"<[email protected]>
To: <[email protected]>;
Cc:
Sent: 2015-03-25 (?) 19:33:03
Subject: Re: [USRP-users] Questions about input data in USRP n210
Dear Jaehoon,
in what form does the external source supply these frames to you?
Generally, the USRPs are designed to do exactly what you describe:
take a sampled signal, convert it to an analog band-limited signal
and mix it to the desired frequency. You can use UHD (the USRP
driver) directly in C++; for an example on how to do that, see the
tx_samples_from_file example [1]. But there is also a lot of signal
processing frameworks [2] that have some kind of interface to UHD,
so if your signal comes from one of these, using the appropriate
"adapter" might be a lot easier.
Best regards,
Marcus M?ller
[1]
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_samples_from_file.cpp
[2] GNU Radio, Mathwork's framework, LabView, Redhawk ...
On 03/25/2015 03:18 AM, ??? via
USRP-users wrote:
Dear all
Hi, I have 2 USRP n210 (sender/ receiver) with XCVR2450
daughterboard.
I want to get input 802.3 frames from external devices to
USRP sender and USRP sender transmit the frames to USRP
receiver.
How to get input frames to our USRP n210 and send USRP
receiver?
Thanks
Best regards
Jaehoon
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/66b786e1/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 20 Apr 2015 09:21:14 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Questions about input data in USRP n210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Jaehoon,
that's exactly what USRPs are designed to do. You will need to write
some signal processing software to make a digital baseband signal out of
your digital data, and then you can just transmit that with the USRP.
On the receiving side, you will have to write signal processing software
that takes the digital baseband samples that come out of the USRP, and
remove the influence of the wireless channel, and then decode the
packet, and then produce audio.
The USRP doesn't "know" what kind of signal it sends, it just takes the
samples you give it, converts them to analog and mixes them to RF.
The same applies for receive signals: It doesn't understand what signals
it senses, it just mixes them to baseband, and samples them.
You will have to implement all meaningful functionality (ie.
transmitting packets of data, decoding data) in software on your PC.
Maybe you would want to have a look at the introduction [1] and the
"using with hardware" part [2] of the GNU Radio tutorials, as they
illustrate what this might look like. To understand "using GNU Radio
with hardware", you might also want to read the other tutorials.
Best regards,
Marcus
[1]
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Introduction
[2]
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Hardware_Considerations
On 04/20/2015 03:00 AM, ??? via USRP-users wrote:
>
> Sorry to vague explain about my experiments.
>
>
>
> Simply, I want to receive the external source packet(802.3 Ethernet
> packet) and transmit the packet by using USRP N210 with X2450
> Daughterboard
>
>
>
> and receive the signal the USRP receiver. And then sends packets to
> other devices.
>
>
>
> Ex,
>
>
>
> External signal(ex. music packet) ---> Transmitter USRP --> wireless
> channel --> Receiver USRP --> external receiver(ex. speaker)
>
>
>
> Thanks
>
>
>
> Jaehoon
>
>
>
> -----Original Message-----
> *From:* "Marcus M?ller"<[email protected]>
> *To:* "???"<[email protected]>;
> *Cc:* <[email protected]>;
> *Sent:* 2015-04-20 (?) 00:39:46
> *Subject:* Re: [USRP-users] Questions about input data in USRP n210
>
>
> Dear Jaehoon,
>
> I'm sorry, I did not understand your question. Could you try to say it
> a bit simpler?
>
> Best regards,
> Marcus
>
> On April 19, 2015 1:45:31 PM CEST, "???" <[email protected]> wrote:
>
> Thanks for replying my questions.
>
>
>
> Anyone who uses the grc example about take a sampled signal and
> convert it to an analog band-limited signal and mix it to the
> desired frequency
>
>
>
> and sends analog signal to other devices such as switch?
>
>
>
> Thanks
>
>
>
> -----Original Message-----
> *From:* "Marcus M?ller via USRP-users"<[email protected]>
> *To:* <[email protected]>;
> *Cc:*
> *Sent:* 2015-03-25 (?) 19:33:03
> *Subject:* Re: [USRP-users] Questions about input data in USRP n210
>
>
> Dear Jaehoon,
>
> in what form does the external source supply these frames to you?
> Generally, the USRPs are designed to do exactly what you describe:
> take a sampled signal, convert it to an analog band-limited signal
> and mix it to the desired frequency. You can use UHD (the USRP
> driver) directly in C++; for an example on how to do that, see the
> tx_samples_from_file example [1]. But there is also a lot of
> signal processing frameworks [2] that have some kind of interface
> to UHD, so if your signal comes from one of these, using the
> appropriate "adapter" might be a lot easier.
>
> Best regards,
> Marcus M?ller
>
> [1]
>
> https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_samples_from_file.cpp
> [2] GNU Radio, Mathwork's framework, LabView, Redhawk ...
>
> On 03/25/2015 03:18 AM, ??? via USRP-users wrote:
>>
>> Dear all
>>
>>
>>
>>
>>
>> Hi, I have 2 USRP n210 (sender/ receiver) with XCVR2450
>> daughterboard.
>>
>>
>>
>> I want to get input 802.3 frames from external devices to USRP
>> sender and USRP sender transmit the frames to USRP receiver.
>>
>>
>>
>> How to get input frames to our USRP n210 and send USRP receiver?
>>
>>
>>
>> Thanks
>>
>>
>>
>>
>>
>> Best regards
>>
>>
>>
>> Jaehoon
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/7720b9d3/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 20 Apr 2015 12:09:16 +0200
From: "Jason A. Donenfeld" <[email protected]>
To: Raj Bhattacharjea <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 over Network?
Message-ID:
<cahmme9pvsb4et4m32bozqjmpye1tvhc2xsf1qgxyaa16-bb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Sat, Apr 18, 2015 at 11:36 PM, Raj Bhattacharjea via USRP-users <
[email protected]> wrote:
> There is no built in functionality to do this kind of thing in UHD. It
> would be great if Ettus provided a daemon that handled talking to the B210
> over USB and looked like an available USRP over the network (just like an N
> series). I see why they don't though: 1 GBPS of network bandwidth can't
> keep up with the 54 MSamps/s
>
I second the notion that it would be nice if Ettus provided a daemon that
made the B210 look like an N series. Some labs have 10gbps networking in
fact. For weaker networks, the B210's full bandwidth would simply not be
available, but the software would still remain useful at lower megasamples.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/484798e3/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 20 Apr 2015 08:49:33 -0400
From: Raj Bhattacharjea <[email protected]>
To: "Jason A. Donenfeld" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 over Network?
Message-ID:
<cap3eqjd0bxtsri_e6ulqb5pmtwkyjnbpalwovbj-wyfw-w8...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I've thought of recording the network traffic to/from an N-series using
wireshark and looking into the N-series UHD source code / FPGA code to try
to figure out the protocol and make my own implementation for some of the
functionality for the B series. If I ever get this idea off the ground and
post a git repo, I'll send it out to this list.
Just a quick note, although you might have a 10gbps network backbone (a
10gbps switch), no small form factor motherboard that I know of has onboard
10 gig networking. So now your're talking at least a micro ITX size
motherboard with a PCIe slot and room to mount the card, or a full blown
server with integrated 10 gigE. Either way, the hope of a very compact,
sleek setup goes out the window if you want the full B210 bandwidth.
On Mon, Apr 20, 2015 at 6:09 AM, Jason A. Donenfeld <[email protected]> wrote:
>
>
> On Sat, Apr 18, 2015 at 11:36 PM, Raj Bhattacharjea via USRP-users <
> [email protected]> wrote:
>
>> There is no built in functionality to do this kind of thing in UHD. It
>> would be great if Ettus provided a daemon that handled talking to the B210
>> over USB and looked like an available USRP over the network (just like an N
>> series). I see why they don't though: 1 GBPS of network bandwidth can't
>> keep up with the 54 MSamps/s
>>
>
> I second the notion that it would be nice if Ettus provided a daemon that
> made the B210 look like an N series. Some labs have 10gbps networking in
> fact. For weaker networks, the B210's full bandwidth would simply not be
> available, but the software would still remain useful at lower megasamples.
>
--
Raj Bhattacharjea
http://www.prism.gatech.edu/~gtg037s/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/45d0dc8b/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 20 Apr 2015 15:08:30 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 over Network?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Raj,
On 04/20/2015 02:49 PM, Raj Bhattacharjea via USRP-users wrote:
> I've thought of recording the network traffic to/from an N-series
> using wireshark and looking into the N-series UHD source code / FPGA
> code to try to figure out the protocol and make my own implementation
> for some of the functionality for the B series. If I ever get this
> idea off the ground and post a git repo, I'll send it out to this list.
No need to dig/reverse engineer, the sample packets are simply VITA-49.
There's a dissector for that in wireshark, and there's a dissector for
the UHD control protocol, too.
The N210's control protocol is very simple, and is based around the host
asking and instructing the USRP on a low level to talk to the
daughterboard, set up DSP chains etc. I'd recommend having a look at the
uhd/host/lib/usrp/usrp2/usrp2_impl.cpp and usrp/cores/*200.cpp and
comparing that to usrp/b200/b200_impl.cpp.
The b200 architecture is not really closely similar to the usrp2/n200
architecture; you can't just change a few things in usrp2_impl and
transparently move to ethernet, I'm afraid.
In essence: Due to overhead and latency, encapsulating the raw USB
packets (which there are implementations of) is not an option;
everything higher-level sounds a bit application-specific, so there
wasn't much need to do a network server for that on the B2x0.
In fact, for the E310, we have such a diagnostic network mode, but there
the samples are moved from the FPGA into the CPU's cache, and handling
is a bit closer to the metal than for external busses, and throughput is
really not considerable for application purposes, though things are
heavily optimized.
To put it a bit nicer: The N2x0 is designed and strongly optimized to be
a network device, the B2x0 a USB3 device -- since this puts some
constraints on how things have to be done, there's no easy "universal"
way to put one's control and data flow through the other's transport.
Best regards,
Marcus
------------------------------
Message: 6
Date: Mon, 20 Apr 2015 18:09:42 +0430
From: hossein talaiee <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP UHD Library Release suggestion
Message-ID:
<CAAiBEBQ5=EOsfQxeW=x04ZnyYh_ZfRsBbX=ac3abrfqbsjx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
About VC runtime, yah, I and probably any other developer has it or know
how to get it, but we want to distribute our application to non developers,
why you dont staticly link it? what harm it may cause?
On Fri, Apr 17, 2015 at 7:44 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> Hi Hossein,
>
> the requirement to install VC runtime is actually quite common, and if we
> included it in our binaries, they'd become huge. Also, if you're a
> developer there's a high chance those runtimes are already installed, and
> for a lot of our users, that's true.
>
> As for Boost, there's no reason for us to update that unless we run into
> bugs or require more features, so we'll be sticking to our current version
> for another while.
>
> Regards,
> Martin
>
>
> On 17.04.2015 04:37, hossein talaiee via USRP-users wrote:
>
>> I noticed that UHD.dll file linked dynamicly against VS C++ run-time
>> library that make this dll needy of VS-C-Runtime installation to work,
>> and I wonder why?
>> Why when we can do it staticly and have an absolutely portable UHD driver!
>>
>> As a matter of fact, boost compile must be done with this option too
>> that can be done with passing "runtime-link=static link=static" to b2
>> command line of boost compile.
>>
>> Also, boost libraries updated now to 1.57 (1.58 also will be out very
>> soon, they testing 1.58-RC version now), consider upgrading boost
>> libraries in release version.
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/fe60ae08/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 20 Apr 2015 16:09:30 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP UHD Library Release suggestion
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
> About VC runtime, yah, I and probably any other developer has it or
> know how to get it, but we want to distribute our application to non
> developers, why you dont staticly link it?
Because that would unnecessarily increase library size for those 90% of
developers who don't want that.
If you want to distribute your UHD-based application statically linked
to the VC runtime, you're free to do so -- but it's simply not what the
majority of developers or users need.
Best regards,
Marcus M?ller
On 04/20/2015 03:39 PM, hossein talaiee via USRP-users wrote:
> About VC runtime, yah, I and probably any other developer has it or
> know how to get it, but we want to distribute our application to non
> developers, why you dont staticly link it? what harm it may cause?
>
> On Fri, Apr 17, 2015 at 7:44 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Hossein,
>
> the requirement to install VC runtime is actually quite common,
> and if we included it in our binaries, they'd become huge. Also,
> if you're a developer there's a high chance those runtimes are
> already installed, and for a lot of our users, that's true.
>
> As for Boost, there's no reason for us to update that unless we
> run into bugs or require more features, so we'll be sticking to
> our current version for another while.
>
> Regards,
> Martin
>
>
> On 17.04.2015 04:37, hossein talaiee via USRP-users wrote:
>
> I noticed that UHD.dll file linked dynamicly against VS C++
> run-time
> library that make this dll needy of VS-C-Runtime installation
> to work,
> and I wonder why?
> Why when we can do it staticly and have an absolutely portable
> UHD driver!
>
> As a matter of fact, boost compile must be done with this
> option too
> that can be done with passing "runtime-link=static
> link=static" to b2
> command line of boost compile.
>
> Also, boost libraries updated now to 1.57 (1.58 also will be
> out very
> soon, they testing 1.58-RC version now), consider upgrading boost
> libraries in release version.
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150420/76fb8f7d/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 56, Issue 20
******************************************
