[Discuss-gnuradio] Gain distribution with Flex 400

[Sivan Toledo]

How is gain distributed when the UHD USRP block is told to set the total
gain to a particular value?

I am using GRC with UHD controlling a USRP with a Flex400 daughter board. I
set the gain in the GRC block to 20dB, which results in the line
"self.uhd_usrp_source_0.set_gain(20, 0)" in the Python output file.

My understanding is that the codec on the USRP has an internal PGA whose
gain can be set between 0 and 20dB and that the Flex400's mixer also has a
PGA whose gain can be set between 0 and 45dB.

Does this mean that I can set the gain in the USRP source block to anywhere
between 0 and 65dB (with the driver deciding how to distribute the gain
between the two PGAs), or is there a way to control separately the two PGAs?

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

[Discuss-gnuradio] access clock_recovery values from packet_sink

[bjoernm]

Hi,

I'm currently using the UCLA ZigBee PHY implementation by Thomas  
Schmid and have got the following question:


In the file "clock_recovery_mm_ff.cc" is a parameter "omega", which I  
would like to change from within "ucla_ieee802_15_4_packet_sink.cc".


Now there is the public function:
void set_omega(float omega)

but I wasn't able to access it from within the packet_sink.

Does anyone have a clue/idea how I could achieve this?

best regards and thank you for any help!
Bjorn



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

Re: [Discuss-gnuradio] error related to -ImportError: and swig_import_helper()

[Josh Blum]

On 08/03/2011 11:07 PM, patiljagdish154 wrote:
> 
> hi all ,
> i have write comedi block while running program i am getting error
> Traceback (most recent call last):
>   File "/home/jagdish/top_block.py", line 13, in 
> import comedi
>   File "/usr/local/lib/python2.6/dist-packages/comedi/__init__.py", line 40,
> in 
> from comedi_swig import *
>   File "/usr/local/lib/python2.6/dist-packages/comedi/comedi_swig.py", line
> 24, in 
> _comedi_swig = swig_import_helper()
>   File "/usr/local/lib/python2.6/dist-packages/comedi/comedi_swig.py", line
> 20, in swig_import_helper
> _mod = imp.load_module('_comedi_swig', fp, pathname, description)
> ImportError: /usr/local/lib/libgnuradio-comedi-3.3.0.so.0: undefined symbol:
> comedi_open
> 
> 

Did you link with libcomedi? http://www.comedi.org/doc/r4857.html

I just did some work on gr-comedi because it did not compile with the
recent versions of comedi that come with ubuntu package manager. So I
have no idea how you built the library in the first place.

Anyway work is here:
http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork

-josh

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

Re: [Discuss-gnuradio] GPS query get_mboard_sensors("gps_locked") fails sometimes

[Bastien Auneau]

Hi Nick

How do I get notice that code has been changed ?
should I directly check repository commit history ?
Are the changes you talk about in host code ? or firmware ?

Please do not hesitate to request me to test some code/firmware.
Or if there's anything else I can help with ?

Regards
Bastien


On 3 August 2011 19:36, Nick Foster  wrote:

> OK. My guess is the timeout requirement for communicating with the
> Firefly has changed with new firmware, and I'm not waiting long enough
> between commands. I'll poke at it today.
>
> --n
>
> On Wed, 2011-08-03 at 15:44 +0200, Bastien Auneau wrote:
> > Some more details
> > _ when Jackon Labs GPS detected as Generic NMEA GPS device, no need to
> > power cycle USRP to get back to normal. It just happen randomly to be
> > 3 times in a row when I tested it, but it's as random as other problem
> > with gps_time and gps_locked
> > _ when some problem occurs (GPS device detection, error when query
> > gps_time or gps_locked), it is very often that few query in a row, or
> > close to each others have such error
> >
> >
> > The common point I see from these calls is that data is fetched from
> > GPSDO serial. So there must be some problem with serial connection ?
> > Or with string manipulation coming out of serial ? Or maybe the way
> > it's sent to UHD-host ?
> >
> >
> > We have many USRP in our lab, but only one GPSDO. Nick, do you
> > have opportunities to try these sensor calls on some other devices ?
> > Then we'll see if it is related to our HW or the way GPSDO has been
> > installed (I followed strictly the procedure on the wiki, as far as I
> > know...) ? Or if it is SW problem
> >
> >
> > Regards
> > Bastien
> >
> > On 2 August 2011 17:44, Nick Foster  wrote:
> > Bastien,
> >
> > Does gps_time work correctly 100% of the time for you?
> >
> > --n
> >
> >
> > On Tue, 2011-08-02 at 17:08 +, Bastien Auneau wrote:
> > > Hi All
> > >
> > > On USRP N210, UHD 3.2.1
> > > GPS does lock, because it gets the right time (not the
> > 01/01/2006 set at
> > > init)
> > > using get_mboard_sensors("gps_locked") fails sometimes
> > >
> > > 1.
> > > It may print on console :
> > >
> > > UHD Error:
> > >   get_nmea(): unsupported GPS or no GPS detected
> > >
> > > while at the start of the code, it always prints :
> > >
> > > Found a Jackson Labs GPS
> > >
> > > At this pont, I have to reboot the USRP. I have seen this
> > error twice on
> > > 20 to 25 runs
> > >
> > > 2. Or :
> > >
> > > UHD Error:
> > >   get_token: too few tokens in reply $GPGGA,  [etc... then
> > there are
> > > more or less args after that, randomly)
> > > GPS lock status: locked
> > >
> > > This second error occurs 1% of the time, but following
> > > get_mboard_sensors("gps_locked") succeed (no need to restart
> > USRP)
> > >
> > > 3. Which leads me to :
> > > How do you check if a get_mboard_sensors(...) fails or not ?
> > > Because even when it fails, the value returned seems ok. And
> > there is no
> > > error field.
> > > Or should this not happen ?
> > >
> > > Thanks and Regards
> > > Bastien
> > >
> >
> > > ___
> > > 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] 'gr_top_block_sptr' object has no attribute '_setup_usrp'

[saketh kumar]

Hi

  I am trying to make digital-bert scripts work with USRP N200, RFX2400. I
have changed my code a little bit. But it shows me an error saying "object
has no attribute".


aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/digital-bert$
./benchmark_tx1.py -f 2500M
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-ba0e3c8

>>> gr_fir_ccf: using SSE
Modulation: 250k bits/sec
TX IF rate: 500k samples/sec
USRP interpolation: 256
DAC amplitude: 2000
Traceback (most recent call last):
  File "./benchmark_tx1.py", line 108, in 
tb = tx_bpsk_block(options)
  File "./benchmark_tx1.py", line 52, in __init__
self._setup_usrp(options.ip,
  File "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py",
line 94, in __getattr__
return getattr(self._tb, name)
AttributeError: 'gr_top_block_sptr' object has no attribute '_setup_usrp'

Can anyone help me out, how to resolve this error ? Attached is my little
modified code.
-- 
Saketh Kumar
#!/usr/bin/env python
#
# Copyright 2008 Free Software Foundation, Inc.
#
# This file is part of GNU Radio
#
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3, or (at your option)
# any later version.
#
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 51 Franklin Street,
# Boston, MA 02110-1301, USA.
#

from gnuradio import gr, eng_notation, uhd
from gnuradio.eng_option import eng_option
from optparse import OptionParser
from transmit_path import transmit_path
import sys


_dac_rate = 128e6

n2s = eng_notation.num_to_str

class tx_bpsk_block(gr.top_block):
def __init__(self, options):
gr.top_block.__init__(self, "tx_mpsk")

self._transmitter = transmit_path(options.sps,
  options.excess_bw,
  options.amplitude)

if_rate = options.rate*options.sps
interp = int(_dac_rate/if_rate)
 

print "Modulation:", n2s(options.rate), "bits/sec"
print "TX IF rate:", n2s(if_rate), "samples/sec"
print "USRP interpolation:", interp
print "DAC amplitude:", options.amplitude

#setup usrp
self._setup_usrp(options.ip,
 interp,
 options.gain,
 options.freq)

self.connect(self._transmitter, self._usrp)


def _setup_usrp(self, ip, interp, gain, freq):
   # Setup single usrp sink
   self._usrp = uhd.single_usrp_sink( device_addr="addr="+ip,
  io_type=uhd.io_type.COMPLEX_FLOAT32,
  num_channels=1,
)

   # Tune to center frequency
   tr = self._usrp.set_center_freq(freq, 0)
   if not (tr):
   print "Failed to tune to center frequency!"
 
   # Set TX gain
   self._usrp.set_gain(gain, 0)
   print "Gain d'board:", n2s(self._usrp.set_gain()), "dB"
  

def get_options():
parser = OptionParser(option_class=eng_option)
parser.add_option("--ip", "--device_addr", default=None, 
  help="device address", metavar="ip") 
parser.add_option("-g", "--gain", type="eng_float", default=None, 
  help="set Rx gain (default is mid-point)") 
parser.add_option("-f", "--freq", type="eng_float", default=None,
  help="set frequency to FREQ", metavar="FREQ")
parser.add_option("-a", "--amplitude", type="eng_float", default=2000,
  help="set Tx amplitude (0-32767) (default=%default)")
parser.add_option("-r", "--rate", type="eng_float", default=250e3,
  help="Select modulation symbol rate (default=%default)")
parser.add_option("", "--sps", type="int", default=2,
  help="Select samples per symbol (default=%default)")
parser.add_option("", "--excess-bw", type="eng_float", default=0.35,
  help="Select RRC excess bandwidth (default=%default)")
  
(options, args) = parser.parse_args()
if len(args) != 0:
parser.print_help()
sys.exit(1)

if options.freq == None:
print "Must supply frequency as -f or --freq"
sys.exit(1)

return (options, args)

if __name__ == "__main__":
(options, args) = get_options()

tb = tx_bpsk_block(options)

try:
tb.run()
except KeyboardInterrupt:
pass
_

[Discuss-gnuradio] Error Make gnuradio

[Sindy Acosta]

Hello, I using ubuntu 11.04 and I want to install the gnuradio, but
when I do "make" for gnuradio 3.3.0 or 3.3.2 i unfortunately get this:

gnuradio make[5]: * [libgnuradio-qtgui.la] Error 1

..and i've done this and i get the same error:
-sudo apt-get build-dep gnuradio
-install all the dependencies on the gnuradio build guide page ( i got
installed other stuff)
-then the usual steps of building from source

[image: :(] please help me!

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

Re: [Discuss-gnuradio] 'gr_top_block_sptr' object has no attribute '_setup_usrp'

[Marcus D. Leech]

On 04/08/2011 1:28 PM, saketh kumar wrote:

Hi

  I am trying to make digital-bert scripts work with USRP N200, 
RFX2400. I have changed my code a little bit. But it shows me an error 
saying "object has no attribute".



aravind@COE-2X85V91:~/gnuradio/gnuradio-examples/python/digital-bert$ 
./benchmark_tx1.py -f 2500M

linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.002-ba0e3c8

>>> gr_fir_ccf: using SSE
Modulation: 250k bits/sec
TX IF rate: 500k samples/sec
USRP interpolation: 256
DAC amplitude: 2000
Traceback (most recent call last):
  File "./benchmark_tx1.py", line 108, in 
tb = tx_bpsk_block(options)
  File "./benchmark_tx1.py", line 52, in __init__
self._setup_usrp(options.ip,
  File 
"/usr/local/lib/python2.6/dist-packages/gnuradio/gr/top_block.py", 
line 94, in __getattr__

return getattr(self._tb, name)
AttributeError: 'gr_top_block_sptr' object has no attribute '_setup_usrp'

Can anyone help me out, how to resolve this error ? Attached is my 
little modified code.

--
Saketh Kumar 

two things that immediately leap to mind:

   o Indentation matters in Python.  Your definition of _setup_usrp 
isn't within the class definition for tx_bpsk_block
   o The most recent UHD doesn't distinguish between "single_usrp" and 
"multi_usrp", there's just a "usrp_source" and "usrp_sink"

   object.




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

Re: [Discuss-gnuradio] Error Make gnuradio

[Marcus D. Leech]

On 04/08/2011 1:39 PM, Sindy Acosta wrote:

Hello, I using ubuntu 11.04 and I want to install the gnuradio, but
when I do "make" for gnuradio 3.3.0 or 3.3.2 i unfortunately get this:

gnuradio make[5]: * [libgnuradio-qtgui.la 
] Error 1


..and i've done this and i get the same error:
-sudo apt-get build-dep gnuradio
-install all the dependencies on the gnuradio build guide page ( i got 
installed other stuff)

-then the usual steps of building from source


If you're building from scratch, can I suggest:

http://www.sbrac.org/files/build-gnuradio

It takes care of most of the common situations, and leaves you with an 
installed Gnu Radio and UHD from the most recent
  GIT sources, along with installing pre-requisites, doing post-install 
tasks, and uninstalling any conflicting installed-from-binary

  componentry that might get in your way.




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

Re: [Discuss-gnuradio] Gain distribution with Flex 400

[Nick Foster]

On Thu, 2011-08-04 at 12:54 +0300, Sivan Toledo wrote:
> How is gain distributed when the UHD USRP block is told to set the
> total gain to a particular value?
> 
> I am using GRC with UHD controlling a USRP with a Flex400 daughter
> board. I set the gain in the GRC block to 20dB, which results in the
> line "self.uhd_usrp_source_0.set_gain(20, 0)" in the Python output
> file.
> 
> My understanding is that the codec on the USRP has an internal PGA
> whose gain can be set between 0 and 20dB and that the Flex400's mixer
> also has a PGA whose gain can be set between 0 and 45dB.
> 
> Does this mean that I can set the gain in the USRP source block to
> anywhere between 0 and 65dB (with the driver deciding how to
> distribute the gain between the two PGAs), or is there a way to
> control separately the two PGAs?

UHD handles gain distribution generally from the front end inward, for
best NF. You can control individual gains like so:

self.uhd_usrp_source_0.set_gain(20, "PGA0", 0)

You can get a list of gain controls with:

self.uhd_usrp_source_0.get_gain_names(0)

--n

> 
> Thanks, Sivan Toledo
> 
> ___
> 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] How to check at which GPS time correspond the pps edge of set_time_next_pps()

[Bastien Auneau]

Hi

USRP N210, UHD 3.2.1, GPSDO Jackson Labs installed
windows7

Using set_time_next_pps()
How can I be sure at which GPS time (in seconds from 01/01/1970) the pps
egde correspond to

So far, here is how I do :
_ get GPS time (get_mboard_sensors("gps_time")), let it be gps_t_0
_ set_time_next_pps(0, 1, 5400)
_ add + 2 sec to gps_t_0. +1 because time is set at next PPS, +1 because
this seems to be time needed to execute the sensor query on GPS
(practically, I was always 1 sec behind, before this last +1)

This has shown to be stable in development lab, for the last few days.
But is there another mechanism to map the "next pps" to a GPS time (in
seconds from 01/01/1970) ?
What bothers me, it's that the second +1 I add is based on the
get_mboard_sensors("gps_time") execution time (approx 1 sec). But this may
change randomly (depending on load, HW etc..)

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

Re: [Discuss-gnuradio] How to check at which GPS time correspond the pps edge of set_time_next_pps()

[Nick Foster]

On Thu, 2011-08-04 at 21:11 +0200, Bastien Auneau wrote:
> Hi
> 
> 
> USRP N210, UHD 3.2.1, GPSDO Jackson Labs installed
> windows7
> 
> 
> Using set_time_next_pps()
> How can I be sure at which GPS time (in seconds from 01/01/1970) the
> pps egde correspond to
> 
> 
> So far, here is how I do :
> _ get GPS time (get_mboard_sensors("gps_time")), let it be gps_t_0
> _ set_time_next_pps(0, 1, 5400)
> _ add + 2 sec to gps_t_0. +1 because time is set at next PPS, +1
> because this seems to be time needed to execute the sensor query on
> GPS (practically, I was always 1 sec behind, before this last +1)
> 
> 
> This has shown to be stable in development lab, for the last few days.
> But is there another mechanism to map the "next pps" to a GPS time (in
> seconds from 01/01/1970) ?
> What bothers me, it's that the second +1 I add is based on the
> get_mboard_sensors("gps_time") execution time (approx 1 sec). But this
> may change randomly (depending on load, HW etc..)

The extra second is required because the GPSDO only outputs a report
once per second. It returns immediately upon receiving a message, so as
long as you call set_time_next_pps soon after
get_mboard_sensors("gps_time"), you should be fine.

--n

> 
> 
> Regards
> Bastien
> ___
> 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] Full Duplex communication on E100, with separate antenna

[Meyer S. Jacobs]

I've seen this issue on a few other posts, and it comes up a lot in
searches, but I can't find a clear solution or answer.

I have two antennas for the E100 that both overlap the 915MHz range,
and would like to send a constant 915MHz wave with one, while
receiving a modulated 915MHz wave on the other (for communicating with
the RFID-style FasTrak Transponders used on the West Coast, US).

I've tried this by using separate flow graphs and separate programs,
but in all cases either TX or RX seems to take out a lock on the
device, preventing the other from accessing it.

If there any way to achieve full-duplex communication on the E100,
with or without two antennas?

-Meyer S. Jacobs

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

Re: [Discuss-gnuradio] Full Duplex communication on E100, with separate antenna

[Nick Foster]

On Thu, 2011-08-04 at 13:22 -0700, Meyer S. Jacobs wrote:
> I've seen this issue on a few other posts, and it comes up a lot in
> searches, but I can't find a clear solution or answer.
> 
> I have two antennas for the E100 that both overlap the 915MHz range,
> and would like to send a constant 915MHz wave with one, while
> receiving a modulated 915MHz wave on the other (for communicating with
> the RFID-style FasTrak Transponders used on the West Coast, US).
> 
> I've tried this by using separate flow graphs and separate programs,
> but in all cases either TX or RX seems to take out a lock on the
> device, preventing the other from accessing it.
> 
> If there any way to achieve full-duplex communication on the E100,
> with or without two antennas?

Use a single flowgraph with both a source and a sink in it.

> 
> -Meyer S. Jacobs
> 
> ___
> 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] Full Duplex communication on E100, with separate antenna

[Meyer S. Jacobs]

Using gnuradio-companion for code generation, with the UHD drivers for
the E100, it still locks up. I can provide my .grc files and generated
python code when I get back to my desk.

-Meyer S. Jacobs

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

Re: [Discuss-gnuradio] anyone help me understand usrp fpga code fragment which count rssi

[Page Jack]

Hi Colby,
I don't understand why compute RSSI need an IIR filter? as I know the rssi
can be compute
like that: (sample[0]*sample[0]+...sample[i]*sample[i]) / (i+1)


Regards!

On Thu, Aug 4, 2011 at 2:44 PM, Colby Boyer  wrote:

> On Wed, Aug 3, 2011 at 6:30 PM, Page Jack  wrote:
>
>> the code below is in sdr_lib/rssi.v I don't understand especially this
>> line: rssi_int <= #1 rssi_int + abs_adc - rssi_int[25:10];
>>
>>   wire [11:0] abs_adc = adc[11] ? ~adc : adc;
>>
>>reg [25:0]  rssi_int;
>>always @(posedge clock)
>>  if(reset | ~enable)
>>rssi_int <= #1 26'd0;
>>  else
>>rssi_int <= #1 rssi_int + abs_adc - rssi_int[25:10];
>>
>>assign  rssi = rssi_int[25:10];
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> It appears to be a clever way to implement a single pole IIR filter. Josh?
>
> If you recall an IIR is defined as y[n] = (1-alpha) * y[n-1] + x[n]
>
> Since multiplier are expensive in hardware, lets use a multiples of two so
> you can bit shift, then add and subtract. :D In this case alpha is 2^-10
>
> --Colby
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] anyone help me understand usrp fpga code fragment which count rssi

[Colby Boyer]

Cheaper in hardware. You only need one adder.

On Thu, Aug 4, 2011 at 6:13 PM, Page Jack  wrote:

> Hi Colby,
> I don't understand why compute RSSI need an IIR filter? as I know the rssi
> can be compute
> like that: (sample[0]*sample[0]+...sample[i]*sample[i]) / (i+1)
>
>
> Regards!
>
>
> On Thu, Aug 4, 2011 at 2:44 PM, Colby Boyer  wrote:
>
>> On Wed, Aug 3, 2011 at 6:30 PM, Page Jack  wrote:
>>
>>> the code below is in sdr_lib/rssi.v I don't understand especially this
>>> line: rssi_int <= #1 rssi_int + abs_adc - rssi_int[25:10];
>>>
>>>   wire [11:0] abs_adc = adc[11] ? ~adc : adc;
>>>
>>>reg [25:0]  rssi_int;
>>>always @(posedge clock)
>>>  if(reset | ~enable)
>>>rssi_int <= #1 26'd0;
>>>  else
>>>rssi_int <= #1 rssi_int + abs_adc - rssi_int[25:10];
>>>
>>>assign  rssi = rssi_int[25:10];
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>> It appears to be a clever way to implement a single pole IIR filter. Josh?
>>
>> If you recall an IIR is defined as y[n] = (1-alpha) * y[n-1] + x[n]
>>
>> Since multiplier are expensive in hardware, lets use a multiples of two so
>> you can bit shift, then add and subtract. :D In this case alpha is 2^-10
>>
>> --Colby
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] anyone help me understand usrp fpga code fragment which count rssi

[Page Jack]

Hi Colby,
I know cheaper in hardware, but now I don't understand how using IIR filter
can compute the RSSI?

On Fri, Aug 5, 2011 at 9:18 AM, Colby Boyer  wrote:

> Cheaper in hardware. You only need one adder.
>
>
> On Thu, Aug 4, 2011 at 6:13 PM, Page Jack  wrote:
>
>> Hi Colby,
>> I don't understand why compute RSSI need an IIR filter? as I know the rssi
>> can be compute
>> like that: (sample[0]*sample[0]+...sample[i]*sample[i]) / (i+1)
>>
>>
>> Regards!
>>
>>
>> On Thu, Aug 4, 2011 at 2:44 PM, Colby Boyer wrote:
>>
>>> On Wed, Aug 3, 2011 at 6:30 PM, Page Jack wrote:
>>>
 the code below is in sdr_lib/rssi.v I don't understand especially this
 line: rssi_int <= #1 rssi_int + abs_adc - rssi_int[25:10];

   wire [11:0] abs_adc = adc[11] ? ~adc : adc;

reg [25:0]  rssi_int;
always @(posedge clock)
  if(reset | ~enable)
rssi_int <= #1 26'd0;
  else
rssi_int <= #1 rssi_int + abs_adc - rssi_int[25:10];

assign  rssi = rssi_int[25:10];

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


>>> It appears to be a clever way to implement a single pole IIR filter.
>>> Josh?
>>>
>>> If you recall an IIR is defined as y[n] = (1-alpha) * y[n-1] + x[n]
>>>
>>> Since multiplier are expensive in hardware, lets use a multiples of two
>>> so you can bit shift, then add and subtract. :D In this case alpha is 2^-10
>>>
>>> --Colby
>>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] anyone help me understand usrp fpga code fragment which count rssi

[Marcus D. Leech]

On 08/04/2011 09:52 PM, Page Jack wrote:
> Hi Colby,
> I know cheaper in hardware, but now I don't understand how using IIR
> filter can compute the RSSI? 
>
>
The power estimate in a complex channel is computed as:

AVG(I**2 + Q**2)

An IIR filter is a simple way of approximating the AVG part of that
equation, and computing the
  absolute value is another approximation for the I**2 and Q**2 part. 
You'll notice in the RSSI
  section that it essentially computes the absolute value.




-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] anyone help me understand usrp fpga code fragment which count rssi

[Marcus D. Leech]

On 08/04/2011 09:52 PM, Page Jack wrote:
> Hi Colby,
> I know cheaper in hardware, but now I don't understand how using IIR
> filter can compute the RSSI? 
>
Seems to me that the RSSI-in-FPGA stuff was not really fully baked,
unless I'm mistaken, the RSSI
  function isn't used by any higher-level functions in the USRP2/N2XXX
implementations.

I always compute the signal strength at the final channel bandwidth, in
software, whereas the RSSI in
  the FPGA code seems to be running at the raw ADC bandwidth--which can
produce wildly
  different RSSI estimates than an estimate produced from your final
channel bandwidth.




-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] anyone help me understand usrp fpga code fragment which count rssi

[Josh Blum]

On 08/04/2011 07:12 PM, Marcus D. Leech wrote:
> On 08/04/2011 09:52 PM, Page Jack wrote:
>> Hi Colby,
>> I know cheaper in hardware, but now I don't understand how using IIR
>> filter can compute the RSSI? 
>>
> Seems to me that the RSSI-in-FPGA stuff was not really fully baked,
> unless I'm mistaken, the RSSI
>   function isn't used by any higher-level functions in the USRP2/N2XXX
> implementations.
> 

It was never used. That rssi.v file is just there so people can ask
about it every few weeks. Its probably one of the least interesting
things in the library of verilog components.

> I always compute the signal strength at the final channel bandwidth, in
> software, whereas the RSSI in
>   the FPGA code seems to be running at the raw ADC bandwidth--which can
> produce wildly
>   different RSSI estimates than an estimate produced from your final
> channel bandwidth.
> 
> 
> 
> 

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

Re: [Discuss-gnuradio] anyone help me understand usrp fpga code fragment which count rssi

[Marcus D. Leech]

On 08/04/2011 10:55 PM, Josh Blum wrote:
>
> It was never used. That rssi.v file is just there so people can ask
> about it every few weeks. Its probably one of the least interesting
> things in the library of verilog components.
>
>   
Because, hey, otherwise you might get lonely, right?  :-)



-- 
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



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

Re: [Discuss-gnuradio] error related to -ImportError: and swig_import_helper()

[patiljagdish154]

thanks
i am getting about linking comedilib.
i think the above error is sort out.now i am getting 
File "/home/jagdish/top_block.py", line 36, in 
tb = top_block()
  File "/home/jagdish/top_block.py", line 28, in __init__
self.comedi_source_s_0 = comedi.source_s( )
AttributeError: 'module' object has no attribute 'source_s'

is this error  due python path ?
i had installed 3 -4 block , i didn't get such kind of error.
i using ubuntu 10.10 , python2.6
all modules(gr, howto ,etc...) that i had installed are stored in
/usr/local/lib/(*.so , *.la *3.3.0.so.o , *.3.3.0.so.0.0.0) and in
/usr/local/lib/python2.6/dist-packages/
to compile comedi code i C compiler i used 
gcc filename.c -lcomedi -lm  and in GNURadio it compile it like normally gcc
filename.c.
is taht a problem ?

thanks
jagdish

 

Josh Blum-2 wrote:
> 
> 
> 
> On 08/03/2011 11:07 PM, patiljagdish154 wrote:
>> 
>> hi all ,
>> i have write comedi block while running program i am getting error
>> Traceback (most recent call last):
>>   File "/home/jagdish/top_block.py", line 13, in 
>> import comedi
>>   File "/usr/local/lib/python2.6/dist-packages/comedi/__init__.py", line
>> 40,
>> in 
>> from comedi_swig import *
>>   File "/usr/local/lib/python2.6/dist-packages/comedi/comedi_swig.py",
>> line
>> 24, in 
>> _comedi_swig = swig_import_helper()
>>   File "/usr/local/lib/python2.6/dist-packages/comedi/comedi_swig.py",
>> line
>> 20, in swig_import_helper
>> _mod = imp.load_module('_comedi_swig', fp, pathname, description)
>> ImportError: /usr/local/lib/libgnuradio-comedi-3.3.0.so.0: undefined
>> symbol:
>> comedi_open
>> 
>> 
> 
> Did you link with libcomedi? http://www.comedi.org/doc/r4857.html
> 
> I just did some work on gr-comedi because it did not compile with the
> recent versions of comedi that come with ubuntu package manager. So I
> have no idea how you built the library in the first place.
> 
> Anyway work is here:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/CMakeWork
> 
> -josh
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://old.nabble.com/error-related-to--ImportError%3A-and-swig_import_helper%28%29-tp32191826p32199446.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