I am using USRP embedded series. Actually I want to transmit a pulse
train. Probably 60% duty cycle with respective modulation.
Yes, this should be possible using UHD directly or with GNU Radio.

Which USRP and daughterboard are you using?

Could you provide more details about what you want to do? What kind of
pulse? 10 ms, 50% duty cycle? What kind of modulation?

--Neel

On 25 March 2015 at 09:53, Rana Arslan Ahmad via USRP-users <
usrp-users@lists.ettus.com> wrote:

Please keep this conversation on the mailing list.

If I recall, you're using E110, right?
Which daughterboard?

What kind of modulation?

--Neel

On 25 March 2015 at 10:19, Rana Arslan Ahmad rarslanad@gmail.com wrote:

One thing you should note is that I personally don't recommend using the
Embedded E-series devices for prototyping of signal waveforms. These
devices integrate an embedded linux machine with USRP hardware, which makes
it very easy to develop applications that require standalone operation, for
example remote sensors, base stations, beacons, etc.

However, if you want to prototype your RF application, it's general
advisable to not start with the embedded device, but with one of the
peripheral USRPs (B2x0, N2x0, X3x0), since these allow execution of your
SDR software on a real PC, and take the burden of developing and debugging
for/on an embedded platform of your shoulders. The E310 and E110 are
specialized pieces of embedded hardware, which, for example, means that you
can't run matlab on it. Depending on your toolboxes, you might be able to
export code that you can compile for these platforms, but that requires
that you have the time to get to know a bit about software development.

If you use a peripheral USRP and develop your software on a linux PC, once
you have a proof of concept, transferring the software to the embedded
device will usually be relatively easy -- the UHD driver running on the
embedded devices has exactly the same interface as UHD running on a full
PC, talking to a peripheral USRP, over network, PCIe or USB, and after all,
it's running a normal linux kernel.

A typical GNU Radio based workflow would be to design one's flow graph in
the GNU Radio companion interface graphically, if necessary writing one's
own signal processing blocks in Python or C++, and verifying operation on
the PC with a peripheral USRP. When everything works, one would simply take
the resulting code, and compile (only necessary if C++ was used) it for the
E310/E110, and copy it to the embedded device.

Greetings,
Marcus

On 03/25/2015 06:36 PM, Rana Arslan Ahmad via USRP-users wrote:

ok and you're right, at the moment looking forward to work on E110 for
time being or maybe order E310 soon.
I don't have much experience of Gnuradio programming but I've done a lot
of digital communications labs via MATLAB.

WBX daughterboard.

On Wed, Mar 25, 2015 at 10:29 AM, Neel Pandeya neel.pandeya@ettus.com
wrote:

USRP-users mailing listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Hi Rana,

On 03/26/2015 07:54 AM, Rana Arslan Ahmad wrote:

Not generally, but if you don't need standalone operation, I see no
sense in spending additional money, and mostly, in taking the route
where you have to do both, DSP and embedded development.

You can of course simply compile GNU Radio for both you PC and the
E-device, and develop stuff on your PC, and then copy it over. You'd
still have the "cross-compile" and the "copying it over" steps
additionally to the DSP development effort. The E310 doesn't have a
built-in display controller, and the E110's processor is not optimized
for graphical workload, so the typical workflow for developing GNU Radio
applications and testing them with a click of a button or the execution
of a command won't work, as you can't display the data the device is
currently transmitting (or that displaying consumes a significant amount
of CPU power, making it harder to implement working algorithms).

A guide starts by asking where someone wants to go. So far, I only know
you want to transmit a single pulse -- that surely isn't your
application's whole purpose.

For me, the basic decision is clear: If you don't need to do it in a
standalone embedded device, don't by an E-series embedded device.
If you need to do it on an embedded device, buy an E-series device;
typically, you'd also buy an B2x0, N2x0 or even an X3x0 to develop your
application on a PC, before moving it to the embedded device, as it will
be easier to develop and test algorithms on a proper PC.

Greetings,
Marcus

Thanks for your detailed guidance.

Can I run proposed FM application like FM receiver on Embedded E-series??
#excluding desired waveform generation or avoiding in this series
#A standalone FM Receive

On Thu, Mar 26, 2015 at 1:30 PM, Marcus Müller
<marcus.mueller@ettus.com mailto:marcus.mueller@ettus.com> wrote:

 Hi Rana,

 On 03/26/2015 07:54 AM, Rana Arslan Ahmad wrote:

 Not generally, but if you don't need standalone operation, I see no
 sense in spending additional money, and mostly, in taking the route
 where you have to do both, DSP and embedded development.

 directly

 You can of course simply compile GNU Radio for both you PC and the
 E-device, and develop stuff on your PC, and then copy it over. You'd
 still have the "cross-compile" and the "copying it over" steps
 additionally to the DSP development effort. The E310 doesn't have a
 built-in display controller, and the E110's processor is not optimized
 for graphical workload, so the typical workflow for developing GNU
 Radio
 applications and testing them with a click of a button or the
 execution
 of a command won't work, as you can't display the data the device is
 currently transmitting (or that displaying consumes a significant
 amount
 of CPU power, making it harder to implement working algorithms).

 A guide starts by asking where someone wants to go. So far, I only
 know
 you want to transmit a single pulse -- that surely isn't your
 application's whole purpose.

 For me, the basic decision is clear: If you don't need to do it in a
 standalone embedded device, don't by an E-series embedded device.
 If you need to do it on an embedded device, buy an E-series device;
 typically, you'd also buy an B2x0, N2x0 or even an X3x0 to develop
 your
 application on a PC, before moving it to the embedded device, as
 it will
 be easier to develop and test algorithms on a proper PC.

 Greetings,
 Marcus