Hello Jeon,

you're right -- since antennas can't transmit DC, and DC would put
stress on the amplifiers, all RF frontends usually try to eliminate DC
offset.

Now, things differ a bit depending on whether you're using a modular
USRP (USRP1,2, B100, N2x0, X3x0, E1x0...) or a USRP with integrated
frontend (B2x0, E3x0), but assuming you have one of the modular ones
(which one do you actually use?):

Your USRP motherboard is, so to speak, a sound card without filters with
an incredibly high sampling rate. The daughterboards do the mixing to
and from RF frequency.
You don't really seem to actually desire that modulation -- you
basically want to use the DAC of the motherboard to directly drive your LED.
You can do that with a daughterboard that doesn't do any modulation --
that's what LFTX [1] is actually for. It's but a buffer for the DAC, and
can thus be used with signals that have a DC component. Note that the
maximum bandwidth of LFTX is rather limited[2] -- if you actually need
more than that, you might also modify a BasicTX[3] (circumventing the
transformer on it), which would give you completely raw access to the
DAC; please make sure you don't accidentially fry it in the process.

Greetings,
Marcus

[1] http://files.ettus.com/schematics/lftx/lftx.pdf
[2] http://files.ettus.com/manual/page_dboards.html#dboards_basictx
[3] http://files.ettus.com/schematics/basic_dbs/BasicTX.pdf

On 02/06/2015 09:02 AM, Jeon via USRP-users wrote:

Thanks for answer, Marcus.

Since I'm not a much good at circuit,
modifying BasicTX would be the second option, it's scary.
Thus, I will be using LFTX/RX and I can use USRP1, 2, N2x0, E1x0.

I'm a bit confused what you said that
LFTX can transmit a signal which have a DC component.

If I set a center frequency argument in a USRP sink block,
I think LFTX will transmit DC unbiased signal,
where a signal fed into the USRP sink block will be an 'envelope'.
May be, am I thinking wrong?
Does the center frequency argument have no effect on LFTX/RX?

Can I just shape a signal in GNU Radio and feed into USRP with LFTX?
If it is true, can shaping a symbol stream (10101101010101....)
into a physical signal achieved by interpolating FIR filter,
where taps is a sequence of discrete sinusoid? Or other better approaches?

And one another question which might be not relevant is that, if I use bias
tee,
I think the reference point, GND of an AC signal and DC signal should be
same,
where the AC signal comes from USRP,
so should I feed DC into bias tee from USRP?

I think I should apologize that I am asking too much basic things.
I will google for those questions while looking forward to answers.

Regards,
Jeon.

2015-02-07 2:38 GMT+09:00 Marcus Müller usrp-users@lists.ettus.com:

Hello Jeon,

On 02/07/2015 01:42 PM, Jeon via USRP-users wrote:

Not really wrong. Maybe a bit. The LFTX doesn't have a tuner -- it
really just takes whatever it gets from the DAC.
However, the FPGA is able to shift your signal in frequency digitally --
still, the upper limit on your signals frequency is 33MHz, due to the
analog filtering on the LFTX.

No, not on the LFTX itself (please have a look at the schematic), but on
the digital frequency shifting in the FPGA.

Note that I really don't think you should be using an envelope when you
actually want to use DC!

Yes.

Um, I don't really understand: I thought you wanted DC? Or do you
actually want to drive your LED with sines?
If you actually just want something that transforms 10101101010101 to
high-low-high-low-high-high-low-high-low-high-low-high-low-high , you'd
just use the symbols, multiply them with your desired high-low
difference, (add an offset if you need that), and repeat them as many
times as you need to match your symbol rate to your sampling rate. You'd
get a sample stream that might look like [1.0, 0.3, 1.0, 0.3, 1.0, 1.0,
0.3, 1.0, 0.3, 1.0, 0.3, 1.0, 0.3, 1.0] (assuming a scaling of 0.7 and
an offset of 0.3) -- which you could directly feed into the USRP. Now,
your USRP will have to interpolate that to its physical sampling rate
(the N2x0 has 100MS/s), so there will be filtering in the FPGA -- but
that's only to avoid the aliases above your user sampling rate (e.g.
everything above 2MHz).

Uff, this really depends. You can have a bias tee that actually contains
a transformer, so that your USRP and your LED don't share GND. Most
bias-tees are really just capacitors in series with your RF signal, and
a inductance to your DC source on the signal-carrying conductor, in
which case the bias will be relative to USRP ground.

Don't worry :) You're asking relevant question to a specific application
of a USRP -- which is exactly what this list is meant for!

I'd really be interested if you could elaborate on which signal you
actually want to use to drive your LEDs -- things

Dear, Marcus

Thanks again for your kindness and answers.

What I've meant in 'shaping signal' is that,

For a given stream of pseudo random binary symbols like '101101011010101...'
with some symbol rate, say... 32k (just an example, can be changed),

I want to drive an LED with an amplitude, or a brightness functions of time:
(don't care about forward voltage of an LED).
f1(t) = A0 * sin(fc * t + phi)+ B for symbol 0
f2(t) = A1 * sin(fc * t + phi)+ B for symbol 1,
where f1(t) and f2(t) are always nonnegative, A1> A0
and time duration of each f1(t) and f2(t) will be 31.25 us (e.g. 1/32k)

The final output (amplitude, brightness of LED) will be:
s(t)  = Sum_{j=1,4,6,9,...} {f0(t - t_j}} + Sum_{k = 0 2,3,5,7,8,...} {f1(t

• t_k}}

Then, maybe I can detect A0 + B and A1 + B on a receiver side with
photodiode/detector
(of course, there is attenuation)
and make them into symbol 0 and 1 with decision maker, slicer...?
Maybe it would be little harder than RF, since it is not a complex but a
real signal...?
Anyway, the receiver side is not on priority.

For the question about shaping a signal,I have a plan like:
map symbols 0 and 1 to float A0 and A1
-> for each symbol in a stream, apply FIR filter, where taps are samples of
sin(fc * t + phi)
-> add constant B

Am I thinking reasonable, or
do you see some theoritical incorrect, or limitations on implementing?

Regards,
Jeon.

2015-02-07 23:04 GMT+09:00 Marcus Müller usrp-users@lists.ettus.com: