[Discuss-gnuradio] USRP Custom Filter Taps

[Daniel Garcia]

I am working on an NTSC receiver using the USRP/TVRX board. I am tunning the 
board to 63.25 MHz with decimation set to 10; this gives me 6.4 MHz of 
bandwidth. The NTSC channel is 6 MHz wide so with these settings I get some 
interference from the adjacent channels. 

Is there a way to set the filter taps used by the USRP so that I could make a 
filter to remove the frequency infomation at the extreme right and left of the 
sampled data? I can use an FIR filter in the PYTHON runtime but it uses lots of 
CPU power.

I read on a previous thread that it is possible to invert the spectrum of the 
sampled signal so that the tuned frequency would be the FM carrier. The end 
result being a stream from the USRP where 0 Hz is the center frequency of the 
audio carrier the the video carrier is at 4.5 MHz. Is this possible? The 
advantage here is that the baseband audio does not need to be shifted before fm 
demodulation; also the video carrier does not need to be shifted before 
demodulation (AM). 


Regards,
Daniel







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

[Discuss-gnuradio] Re: gnuradio trellis

[Toby Oliver]

Achilleas,

Okay. I am primarily interested in the equalization for the time being,
but I can see it would seem to make a lot of sense to create the
sequence detection as well.

In terms of making the isi lookup table for multidimensional
modulations, whats the best way to go about it? Is there any published
literature on this that I could base it on?

Kind Regards,
Toby

Anastasopoulos Achilleas wrote:
> Oliver,
>
> You are right:
> Trellis implementation supports multi-dimensional constellations etc
> (through the metric calculation block abstraction, etc), however,
> in the examples and the supporting fsm_utils.py files
> I have not included support for GMSK, and the automatic
> generation of lookup tables for ISI channels is for-one dimensional
> modulations.
> I think the extension should be straightforward and I'll be glad
> to help you in this.
>
> May I suggest you separate the task into two subproblems for reasons
> of usability by others:
>
> 1) GMSK sequence detection in AWGN channels
> (which is a modulation with memory and in theory requires Viterbi
> even in the absense of ISI),
> and
> 2) GMSK equalization (ie, GMSK + ISI channel + noise -> Viterbi)
>
> For 1) a modification of test_tcm.py is required and hopefully
> an "automated" way to project any given GMSK modulation to its
> N-dimensional components; maybe a python implementation of
> the Gram-Schmidt (QR decomposition) algorithm...
>
> For 2) a modification of the test_viterbi_equalization.py or
> test_viterbi_equalization1.py is required together with
> generalizing the code in fsm_utils.py to generate the lookup table
> for multi-dimensional modulations.
>
> best,
> Achilleas
>
> On Wed, 27 Sep 2006, Toby Oliver wrote:
>
>> Achilleas,
>>
>> I hope you don't mind me emailing you, but I have just been having a
>> look at your gnuradio trellis code which is very cool. In fact I was
>> looking to try it out as an equalizer on some GMSK signals but it seems
>> the make_isi_lookup in fsm_utils currently only supports one-dimensional
>> modulations. Am I right in assuming the I will need to extend this for a
>> GMSK signal? Or am I missing something?
>>
>> Thanks for adding this to Gnuradio, its a really useful (and incredibly
>> flexible) addition.
>>
>> Kind Regards,
>> Toby
>>
>>
>>




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

[Discuss-gnuradio] window code

[Patrick Strasser]

Hello!

I'm trying the code from gr.window. For the blackmanharris window 
everthing works fine:


>>> from gnuradio import window
>>> window.blackmanharris(3)
[0.217469997, 0.217470014, 0.217469989]

but bartlett has problems findeing midn:

>>> window.bartlett(7)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/site-packages/gnuradio/window.py", line 91, 
in bartlett

for index in xrange(midn(fft_size)+1):
NameError: global name 'midn' is not defined

The code for bartlett is:

def bartlett(fft_size):
mfrq = freq(fft_size)
angle = 0
window = [0 for i in range(fft_size)]
j = fft_size-1
for index in xrange(midn(fft_size)+1):
window[j] = window[index] = angle
angle += freq
j -= 1
return window

window.midm1 and window.midp1 exist, though.

Bit rot?

Patrick
--
Engineers motto: cheap, good, fast: choose any two
Patrick Strasser 
Student of Telematik, Techn. University Graz, Austria



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

Re: [Discuss-gnuradio] AGC loop and digital mods

[Robert McGwier]

svn co svn://206.216.146.154/svn/repos_sdr_dttsp/trunk dttsp

'Eric Blossom' wrote:

On Wed, Sep 27, 2006 at 01:44:34PM -0400, Robert W McGwier wrote:
  
The feedforward AGC system in DttSP is more complex in that it is two 
track (fast and "user set").   I  believe I already mentioned this so I 
won't go over it again.  But let me reiterate one important feature of 
our work.  One of the things that was important to its success as a 
feedforward agc was to respond to a level change 3 times constants early 
in a simple predictive system.   The 3 time constants varied depending 
on the changing speed of the agc as set by the user.


Bob



Thanks!

BTW, what's the link to the current/svn/cvs DttSP code?

Eric


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

  



--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
"You see, wire telegraph is a kind of a very, very long cat.
You pull his tail in New York and his head is meowing in Los
Angeles. Do you understand this? And radio operates exactly
the same way: you send signals here, they receive them there.
The only difference is that there is no cat." - Einstein



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

Re: [Discuss-gnuradio] AGC loop and digital mods

['Eric Blossom']

On Wed, Sep 27, 2006 at 01:44:34PM -0400, Robert W McGwier wrote:
> The feedforward AGC system in DttSP is more complex in that it is two 
> track (fast and "user set").   I  believe I already mentioned this so I 
> won't go over it again.  But let me reiterate one important feature of 
> our work.  One of the things that was important to its success as a 
> feedforward agc was to respond to a level change 3 times constants early 
> in a simple predictive system.   The 3 time constants varied depending 
> on the changing speed of the agc as set by the user.
> 
> Bob

Thanks!

BTW, what's the link to the current/svn/cvs DttSP code?

Eric


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

Re: [Discuss-gnuradio] AGC loop and digital mods

[Bob McGwier]

The feedforward AGC system in DttSP is more complex in that it is two 
track (fast and "user set").   I  believe I already mentioned this so I 
won't go over it again.  But let me reiterate one important feature of 
our work.  One of the things that was important to its success as a 
feedforward agc was to respond to a level change 3 times constants early 
in a simple predictive system.   The 3 time constants varied depending 
on the changing speed of the agc as set by the user.


Bob


'Eric Blossom' wrote:


On Mon, Sep 25, 2006 at 11:35:33PM -0400, Tom Rondeau wrote:
 


Eric,

Here's a brief write-up on the tests I ran for the AGC loops. It looks like
the feedforward has a slight advantage over most of the test cases. 


I thought I'd email this to the listserv in case anyone is interested in the
digital modulations. Basically, we're working on getting stable DBPSK and
DQPSK modulators into the code base. The AGC loops seems to be producing
problems, much of which is caused by driving the Costas loop crazy at the
next stage of the receiver. Future work will include creating a non-coherent
receiver for the differential modulations to take out the Costas loop.

Tom
   



Hi Tom,  thanks for making the measurements and writing them up.

I'll be merging the results of all this work into the trunk tomorrow.
Thanks to Tom for all the effort he's put into sorting out the DBPSK
and DQPSK.  And thanks to Matt for suggesting the feed forward AGC.

Eric
 




--
Robert W. McGwier, Ph.D.
Center for Communications Research
805 Bunn Drive
Princeton, NJ 08540
(609)-924-4600
(sig required by employer)




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

Re: [Discuss-gnuradio] to prevent damages

[Marcus Leech]

Matt Ettus wrote:

0 dBm, or 1 mW into a receiver will not damage it.
Matt
Under ordinary conditions, a radio receiver receiving a 0dBm signal 
would be close

 to overload, but not in "input amplifier damage" territory.

You average FM radio receiver is quite happy receiving a few microwatts 
(-30dBm or less), and

 producing a quite-acceptable demodulated signal.

In my application, a few microwatts is burning-the-house-down strong :-)



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

Re: [Discuss-gnuradio] Daughter board pins

[Eric Blossom]

On Wed, Sep 27, 2006 at 04:28:08PM +0100, Andrew Borg wrote:
> Hi Eric. Thanks for your help. It all works exactly how you said. I was 
> enabling the correct pins using "usrp.source_c(0, 64)"   - the code I 
> pasted "usrp.sink_c(0, 64)" was a blind copy-paste from Oussama's email. 
> Sorry about the confusion.
> 
> All I was missing was the " u._write_oe(1, 0x, 0x) ". I put that it 
> and it all worked nicely.
> 
> I have another question. I'm outputting two pieces of information on my 2 
> BasicRX daughter boards - (1) 3 clocks and (2) the USB data. The Verilog 
> code looks as follows:
> 
>   master_control master_control
> ( .master_clk(clk64),.usbclk(usbclk),
>   
> .serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe),
>   .tx_bus_reset(tx_bus_reset),.rx_bus_reset(rx_bus_reset),
>   .tx_dsp_reset(tx_dsp_reset),.rx_dsp_reset(rx_dsp_reset),
>   .enable_tx(enable_tx),.enable_rx(enable_rx),
>   .interp_rate(interp_rate),.decim_rate(decim_rate),
>   .tx_sample_strobe(tx_sample_strobe),.strobe_interp(strobe_interp),
>   .rx_sample_strobe(rx_sample_strobe),.strobe_decim(strobe_decim),
>   .tx_empty(tx_empty),
>   //.debug_0(rx_a_a),.debug_1(ddc0_in_i),
>  .debug_0(rx_debugbus),.debug_1(usbdata_out),
>  .debug_2({rx_sample_strobe,strobe_decim,serial_strobe,serial_addr}),
>  .debug_3(usbclk,clk64,clk128),
> // 
> .debug_3({rx_dsp_reset,tx_dsp_reset,rx_bus_reset,tx_bus_reset,enable_rx,tx_underrun,rx_overrun,decim_rate}),
>   .reg_0(reg_0),.reg_1(reg_1),.reg_2(reg_2),.reg_3(reg_3) );
> 
> 
> Now I'm getting some signals on my oscilloscope that I'm not happy with.
> 
> 1) First of all, the clk64 signal looks like a sine - wave. The frequency 
> is 64MhZ according to my oscilloscope. I was expecting a square wave. Is 
> this correct?

You'll need good probing techniques to see a 64MHz clock and have it
not look like a sine wave.  You won't be able to do this with a scope
probe with a 2 inch ground lead.  For this kind of stuff I usually use
a small wire ground lead wrapped around the ground ring on the tip.
The traditional scope vendors make a special little spring loaded gadget
for this.  Ideally you want the tip of the probe and the ground probe
to be within a 1/4" of each other.

> 2) I get nothing from clk128 - it may just not be connected. Is this 
> correct?

I don't think this is being used.

> 3) The usbclk is also outputting a signal that looks like a sine-wave at 
> around 50MHz. Is this correct?

More probing problems.  The signal is 48MHz.

> 4) The USB data signals look very very unsteady. They look nothing like a 
> square wave or a sine wave - almost somewhere in between with slow rising 
> edges and then fast drops to 0.

Beats me, I've never tried probing them.  They're running at
480Mb/sec.  My scope won't run that fast.  

> I'll explain briefly what I am trying to do. Essentially I've got another 
> FPGA board that I want to get the output from the USRP board to be 
> trasferred onto. Essenitally, I want the I,Q pairs that go to the USB on 
> the USRP board to go to the daughterboard pins so that I can sample them on 
> this second FPGA board.

OK

> I've written some python code to output 1, and 0s onto the daughter board 
> pins (that's why I needed the previous help - thanks again Eric).  The 
> python code is basically a loop that outputs 0x0 and 0x alternately to 
> the daughter board pins. My oscilloscope shows a nice clean square wave 
> which comes out at about 3KHz when I remove all delays (delays made with 
> python's sleep). I guess this speed is the fastest at which the python code 
> can be interpreted, and the signal sent up the usb to the FPGA and then to 
> the daughter board pins.

FWIW, most of the delay is the round trip on the USB each time you set the pins.

> This has led to me to believe that, perhaps I'm 
> having a problem of speed - perhaps the USB data coming out of the FPGA is 
> changing too fast for a clear wave to show up on the daughter-board pins. 
> Would this be a correct analysis?

With good probing techniques you should be able to see
the pins moving.  To figure out what's going on a logic analyzer is a
better choice.  Also, how fast is your o'scope?

If you've got any EE friends, they can probably help you with the
probing techniques.

> Any help would be greatly appreciated as I'm hitting a bit of a wall now.
> 
> Thanks a lot for the already received help.
> 
> Andrew

Eric


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

Re: [Discuss-gnuradio] to prevent damages

[Matt Ettus]

Vincenzo Pellegrini wrote:

hi, 
I've just been reading the thread about the broken RX board.

some days ago I've just denied to one of my fellows the permission to
connect an amplified HF antenna to the LFRX for fear it could overload
the input...we used a passive half-wave (@ band centre) dipole
instead.  
 


That should not be a problem.


just to be sure about what we can or cannot do with our fantastic piece
of hardware, is there anything published detailing exactly what we must
avoid and what we can feel free to do?
 

0 dBm, or 1 mW into a receiver will not damage it. 


Matt


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

Re: [Discuss-gnuradio] Daughter board pins

[Brian Padalino]

Just wondering, what is the make and model of your oscilloscope you
are using?  Also, what is the sample rate?

Thanks,
Brian

On 9/27/06, Andrew Borg <[EMAIL PROTECTED]> wrote:

Hi Eric. Thanks for your help. It all works exactly how you said. I was
enabling the correct pins using "usrp.source_c(0, 64)"   - the code I pasted
"usrp.sink_c(0, 64)" was a blind copy-paste from Oussama's email. Sorry
about the confusion.

All I was missing was the " u._write_oe(1, 0x, 0x) ". I put that it
and it all worked nicely.

I have another question. I'm outputting two pieces of information on my 2
BasicRX daughter boards - (1) 3 clocks and (2) the USB data. The Verilog
code looks as follows:

   master_control master_control
 ( .master_clk(clk64),.usbclk(usbclk),
   
.serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe),
   .tx_bus_reset(tx_bus_reset),.rx_bus_reset(rx_bus_reset),
   .tx_dsp_reset(tx_dsp_reset),.rx_dsp_reset(rx_dsp_reset),
   .enable_tx(enable_tx),.enable_rx(enable_rx),
   .interp_rate(interp_rate),.decim_rate(decim_rate),
   .tx_sample_strobe(tx_sample_strobe),.strobe_interp(strobe_interp),
   .rx_sample_strobe(rx_sample_strobe),.strobe_decim(strobe_decim),
   .tx_empty(tx_empty),
   //.debug_0(rx_a_a),.debug_1(ddc0_in_i),
  .debug_0(rx_debugbus),.debug_1(usbdata_out),
  .debug_2({rx_sample_strobe,strobe_decim,serial_strobe,serial_addr}),
  .debug_3(usbclk,clk64,clk128),
//
.debug_3({rx_dsp_reset,tx_dsp_reset,rx_bus_reset,tx_bus_reset,enable_rx,tx_underrun,rx_overrun,decim_rate}),
   .reg_0(reg_0),.reg_1(reg_1),.reg_2(reg_2),.reg_3(reg_3) );


Now I'm getting some signals on my oscilloscope that I'm not happy with.

1) First of all, the clk64 signal looks like a sine - wave. The frequency is
64MhZ according to my oscilloscope. I was expecting a square wave. Is this
correct?

2) I get nothing from clk128 - it may just not be connected. Is this
correct?

3) The usbclk is also outputting a signal that looks like a sine-wave at
around 50MHz. Is this correct?

4) The USB data signals look very very unsteady. They look nothing like a
square wave or a sine wave - almost somewhere in between with slow rising
edges and then fast drops to 0.

I'll explain briefly what I am trying to do. Essentially I've got another
FPGA board that I want to get the output from the USRP board to be
trasferred onto. Essenitally, I want the I,Q pairs that go to the USB on the
USRP board to go to the daughterboard pins so that I can sample them on this
second FPGA board.

I've written some python code to output 1, and 0s onto the daughter board
pins (that's why I needed the previous help - thanks again Eric).  The
python code is basically a loop that outputs 0x0 and 0x alternately to
the daughter board pins. My oscilloscope shows a nice clean square wave
which comes out at about 3KHz when I remove all delays (delays made with
python's sleep). I guess this speed is the fastest at which the python code
can be interpreted, and the signal sent up the usb to the FPGA and then to
the daughter board pins. This has led to me to believe that, perhaps I'm
having a problem of speed - perhaps the USB data coming out of the FPGA is
changing too fast for a clear wave to show up on the daughter-board pins.
Would this be a correct analysis?

Any help would be greatly appreciated as I'm hitting a bit of a wall now.

Thanks a lot for the already received help.

Andrew





- Original Message -
From: "Eric Blossom" <[EMAIL PROTECTED]>
To: "Andrew Borg" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, September 26, 2006 5:35 PM
Subject: Re: [Discuss-gnuradio] Daughter board pins


> On Tue, Sep 26, 2006 at 03:15:16PM +0100, Andrew Borg wrote:
>
>> Hi Oussama. I managed to get the signals I want out of my daughter
>> board (BasicRX) on RxA. So thanks a lot for your help (and by proxy
>> to Eric too!). However, I have one more problem. I need to get some
>> other signals out from the FPGA on my other daughterboard that is on
>> the board marked RxB. The Verilog code I can handle - no problems
>> there. What I am unsure about is the python code. So far I have the
>> following code which outputs the signals I need from RxA:
>
>>
>>  u = usrp.sink_c(0, 64)
>>  u._write_oe(0, 0x, 0x)
>
> Note that this is output enabling the pins on the TX_A daugterboard.
> Is that what you wanted?  I hope so ;)
> It's the TX_A because you opened the sink_c, and you're passing 0 as
> the "which" argument to _write_oe
>
>
> Assuming you've got two Basic Rx d'boards installed, one on the A side
> and one on the B side, you'll want:
>
>  u = usrp.source_c(0, 64)  # note that we're opening the source
>  u._write_oe(0, 0x, 0x)
>  u._write_oe(1, 0x, 0x)
>  u._write_fpga_reg(FR_DEBUG_EN, bmFR_DEBUG_EN_RX_A | bmFR_DEBUG_EN_RX_B)
>
>
>>  u._write_fpga_reg(FR_DEBUG_EN, bmFR_DEBUG_EN_RX_A)
>>
>> The above is basically what you sent me. Now if I change the last 

Re: [Discuss-gnuradio] Daughter board pins

[Andrew Borg]

Hi Eric. Thanks for your help. It all works exactly how you said. I was 
enabling the correct pins using "usrp.source_c(0, 64)"   - the code I pasted 
"usrp.sink_c(0, 64)" was a blind copy-paste from Oussama's email. Sorry 
about the confusion.


All I was missing was the " u._write_oe(1, 0x, 0x) ". I put that it 
and it all worked nicely.


I have another question. I'm outputting two pieces of information on my 2 
BasicRX daughter boards - (1) 3 clocks and (2) the USB data. The Verilog 
code looks as follows:


  master_control master_control
( .master_clk(clk64),.usbclk(usbclk),
  
.serial_addr(serial_addr),.serial_data(serial_data),.serial_strobe(serial_strobe),
  .tx_bus_reset(tx_bus_reset),.rx_bus_reset(rx_bus_reset),
  .tx_dsp_reset(tx_dsp_reset),.rx_dsp_reset(rx_dsp_reset),
  .enable_tx(enable_tx),.enable_rx(enable_rx),
  .interp_rate(interp_rate),.decim_rate(decim_rate),
  .tx_sample_strobe(tx_sample_strobe),.strobe_interp(strobe_interp),
  .rx_sample_strobe(rx_sample_strobe),.strobe_decim(strobe_decim),
  .tx_empty(tx_empty),
  //.debug_0(rx_a_a),.debug_1(ddc0_in_i),
 .debug_0(rx_debugbus),.debug_1(usbdata_out),
 .debug_2({rx_sample_strobe,strobe_decim,serial_strobe,serial_addr}),
 .debug_3(usbclk,clk64,clk128),
// 
.debug_3({rx_dsp_reset,tx_dsp_reset,rx_bus_reset,tx_bus_reset,enable_rx,tx_underrun,rx_overrun,decim_rate}),

  .reg_0(reg_0),.reg_1(reg_1),.reg_2(reg_2),.reg_3(reg_3) );


Now I'm getting some signals on my oscilloscope that I'm not happy with.

1) First of all, the clk64 signal looks like a sine - wave. The frequency is 
64MhZ according to my oscilloscope. I was expecting a square wave. Is this 
correct?


2) I get nothing from clk128 - it may just not be connected. Is this 
correct?


3) The usbclk is also outputting a signal that looks like a sine-wave at 
around 50MHz. Is this correct?


4) The USB data signals look very very unsteady. They look nothing like a 
square wave or a sine wave - almost somewhere in between with slow rising 
edges and then fast drops to 0.


I'll explain briefly what I am trying to do. Essentially I've got another 
FPGA board that I want to get the output from the USRP board to be 
trasferred onto. Essenitally, I want the I,Q pairs that go to the USB on the 
USRP board to go to the daughterboard pins so that I can sample them on this 
second FPGA board.


I've written some python code to output 1, and 0s onto the daughter board 
pins (that's why I needed the previous help - thanks again Eric).  The 
python code is basically a loop that outputs 0x0 and 0x alternately to 
the daughter board pins. My oscilloscope shows a nice clean square wave 
which comes out at about 3KHz when I remove all delays (delays made with 
python's sleep). I guess this speed is the fastest at which the python code 
can be interpreted, and the signal sent up the usb to the FPGA and then to 
the daughter board pins. This has led to me to believe that, perhaps I'm 
having a problem of speed - perhaps the USB data coming out of the FPGA is 
changing too fast for a clear wave to show up on the daughter-board pins. 
Would this be a correct analysis?


Any help would be greatly appreciated as I'm hitting a bit of a wall now.

Thanks a lot for the already received help.

Andrew





- Original Message - 
From: "Eric Blossom" <[EMAIL PROTECTED]>

To: "Andrew Borg" <[EMAIL PROTECTED]>
Cc: 
Sent: Tuesday, September 26, 2006 5:35 PM
Subject: Re: [Discuss-gnuradio] Daughter board pins



On Tue, Sep 26, 2006 at 03:15:16PM +0100, Andrew Borg wrote:


Hi Oussama. I managed to get the signals I want out of my daughter
board (BasicRX) on RxA. So thanks a lot for your help (and by proxy
to Eric too!). However, I have one more problem. I need to get some
other signals out from the FPGA on my other daughterboard that is on
the board marked RxB. The Verilog code I can handle - no problems
there. What I am unsure about is the python code. So far I have the
following code which outputs the signals I need from RxA:




 u = usrp.sink_c(0, 64)
 u._write_oe(0, 0x, 0x)


Note that this is output enabling the pins on the TX_A daugterboard.
Is that what you wanted?  I hope so ;)
It's the TX_A because you opened the sink_c, and you're passing 0 as
the "which" argument to _write_oe


Assuming you've got two Basic Rx d'boards installed, one on the A side
and one on the B side, you'll want:

 u = usrp.source_c(0, 64)  # note that we're opening the source
 u._write_oe(0, 0x, 0x)
 u._write_oe(1, 0x, 0x)
 u._write_fpga_reg(FR_DEBUG_EN, bmFR_DEBUG_EN_RX_A | bmFR_DEBUG_EN_RX_B)



 u._write_fpga_reg(FR_DEBUG_EN, bmFR_DEBUG_EN_RX_A)

The above is basically what you sent me. Now if I change the last line to 
:






then I still get the signals I need from RxA but still nothing from
RX_B (I've changed the Verilog code as required - I understand that
part fine). I also tried adding u._write_oe(1, 0x, 0x) b

Re: [Discuss-gnuradio] to prevent damages

[michael taylor]

On 9/27/06, Brian Padalino <[EMAIL PROTECTED]> wrote:

It might not be a bad idea for Ettus Research to also stock some other
items such as SMA cables/adapters/attenuators.


Attenuators might a good idea. I think a model to match the 100mW
transmitters would be Mini-Circuits' VAT-15 (50 ohm, SMA, 1W, 15dB,
usable up to 4GHz) if I've done my loss calculations correctly
. A 9 or 6 dB for the BasicTX should be  usable
if I haven't messed up my calculations.



It might also be handy to have some nice block diagrams with max power
recommendations and recommended attentuations for cabled setups as
well as a table in the Wiki with such recommendations.


Here is what I think the calculation is:

transmit power converted to dBm (1 dBm == 1 mW) minus the attenuator
loss = output power in dBm.

E.g.
 100 mW -> 20dBm
 20dBm - 15 db att = 5 dBm
 5 dBm -> 3.2 mW

So if the receiver can handle 3.2 mW input, this would be adequate
attenuation. Off hand I don't know what is acceptable input power
range.

dBm ref: 


That might save some of the more software oriented people from burning
out their hardware without intentionally doing so.


Agreed.


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

Re: [Discuss-gnuradio] to prevent damages

[Brian Padalino]

It might not be a bad idea for Ettus Research to also stock some other
items such as SMA cables/adapters/attenuators.

It might also be handy to have some nice block diagrams with max power
recommendations and recommended attentuations for cabled setups as
well as a table in the Wiki with such recommendations.

That might save some of the more software oriented people from burning
out their hardware without intentionally doing so.

On 9/27/06, Vincenzo Pellegrini <[EMAIL PROTECTED]> wrote:

hi,
I've just been reading the thread about the broken RX board.
some days ago I've just denied to one of my fellows the permission to
connect an amplified HF antenna to the LFRX for fear it could overload
the input...we used a passive half-wave (@ band centre) dipole
instead.

just to be sure about what we can or cannot do with our fantastic piece
of hardware, is there anything published detailing exactly what we must
avoid and what we can feel free to do?

thanks

vincenzo



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




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

[Discuss-gnuradio] Re: gnuradio trellis

[Anastasopoulos Achilleas]

Oliver,

You are right:
Trellis implementation supports multi-dimensional constellations etc
(through the metric calculation block abstraction, etc), however,
in the examples and the supporting fsm_utils.py files
I have not included support for GMSK, and the automatic
generation of lookup tables for ISI channels is for-one dimensional 
modulations.

I think the extension should be straightforward and I'll be glad
to help you in this.

May I suggest you separate the task into two subproblems for reasons of 
usability by others:


1) GMSK sequence detection in AWGN channels
(which is a modulation with memory and in theory requires Viterbi
even in the absense of ISI),
and
2) GMSK equalization (ie, GMSK + ISI channel + noise -> Viterbi)

For 1) a modification of test_tcm.py is required and hopefully
an "automated" way to project any given GMSK modulation to its
N-dimensional components; maybe a python implementation of
the Gram-Schmidt (QR decomposition) algorithm...

For 2) a modification of the test_viterbi_equalization.py or
test_viterbi_equalization1.py is required together with
generalizing the code in fsm_utils.py to generate the lookup table
for multi-dimensional modulations.

best,
Achilleas

On Wed, 27 Sep 2006, Toby Oliver wrote:


Achilleas,

I hope you don't mind me emailing you, but I have just been having a
look at your gnuradio trellis code which is very cool. In fact I was
looking to try it out as an equalizer on some GMSK signals but it seems
the make_isi_lookup in fsm_utils currently only supports one-dimensional
modulations. Am I right in assuming the I will need to extend this for a
GMSK signal? Or am I missing something?

Thanks for adding this to Gnuradio, its a really useful (and incredibly
flexible) addition.

Kind Regards,
Toby






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

[Discuss-gnuradio] to prevent damages

[Vincenzo Pellegrini]

hi, 
I've just been reading the thread about the broken RX board.
some days ago I've just denied to one of my fellows the permission to
connect an amplified HF antenna to the LFRX for fear it could overload
the input...we used a passive half-wave (@ band centre) dipole
instead.  

just to be sure about what we can or cannot do with our fantastic piece
of hardware, is there anything published detailing exactly what we must
avoid and what we can feel free to do?

thanks

vincenzo 



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