[Discuss-gnuradio] reading and writing registers

[seph 004]

HiI am having some trouble trying to get register writing and reading from the C++ level to work. I've created two methods:for writingstatic boolwrite_a_reg (usrp_basic *u, int address, int amount){  bool isit = u->_write_fpga_reg (address, amount);  return isit;}for  reading intread_a_reg (usrp_basic *u, int address){  int val = u->_read_fpga_reg (address);  return val;}When I use the write method:bool fine2 = write_a_reg (urx, 78, 60);The returned boolean indicates that the write was successful. If I try to read the same register though:int value = read_a_reg (urx, 78);it always returns zero no matter what I put in. The urx is the handle of a
 usrp_standard_rx object, and if I'm not mistaken, register number 78 (`FR_USER_14) shoul be free to use. What am I doing wrong?RegardsLance___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] PYTHONPATH on Fedora Core 6 x86_64

[Trond Danielsen]

Hi everyone!

I have followed the instructions on
http://gnuradio.org/trac/wiki/FC5Install, but I still have a problem.
Python does not find the modules unless I add all the necessary
subfolders to PYTHONPATH. Any ideas on what I am doing wrong?

Best Regards,
--
Trond Danielsen


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

[Discuss-gnuradio] Re: PYTHONPATH on Fedora Core 6 x86_64

[Trond Danielsen]

2006/11/3, Trond Danielsen <[EMAIL PROTECTED]>:

Hi everyone!

I have followed the instructions on
http://gnuradio.org/trac/wiki/FC5Install, but I still have a problem.
Python does not find the modules unless I add all the necessary
subfolders to PYTHONPATH. Any ideas on what I am doing wrong?



I found the problem. There is no __init__.py in
$PREFIX/lib64/python2.4/site-packages/gnuradio and the in the
subfolders, so python does not recognize them as modules.

--
Trond Danielsen


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

Re: [Discuss-gnuradio] What's the story on hpsdr.org

[Marcus Leech]

Robert McGwier wrote:

HPSDR grew up on its on from "Friends of Flex Radio".   It was an 
organic happening.  It is borrowing heavily from Gnu Radio.  It does 
have a more amateur radio centric focus.  TAPR and AMSAT are both 
supporters but we are supporters of Gnu Radio as well.  Matt, Eric, 
and others belong to AMSAT projects.  Matt is the principal 
investigator on the digital communications package for our next 
spacecraft.  Lyle is personally much more interested in the embedded 
controller applications (DSP chips) than desktop.  He is a Flex Radio 
owner and user.  Frank Brickle and I do both Gnu Radio and HPSDR.  We 
are heavily involved in the Sasquatch,  Odyssey,  and other pieces.  
If there is competition,  it is friendly and not hostile.  I do not 
perceive any competition and I am close to both.  Eric subscribes to 
the HPSDR group and contributes comments on occasion.  I comment 
wherever I am, whether I should or not ;-).   HPSDR is using the USB 
interface approach from Gnu Radio.  Hey!  Why reinvent the wheel?


I suspect there will be some competition for customers for the USRP 
and the Mercury/Ozy.  When the latter becomes real,  we can guage it 
better then.  I hope Matt is doing a USRP-2.  I continue to support 
both efforts.  My feeling is your perception is incorrect.  I do 
suspect that GnuRadio will be easily adapted to Ozy/Mercury when that 
becomes available since HPSDR has borrowed so heavily from GnuRadio.


As you say, HPSDR is an open source open hardware happening and it 
serves up everything from source to gerber files in its svn server.


Bob



Ah, Ok.


I looked at the specs for the Mercury board, and it's disappointing that 
it doesn't do complex sampling (at least,
 according to the diagram).   The receiver chips that I care about 
produce I and Q outputs, but that's just

 me :-)

The HPSDR project does look interesting, and I can see why, for some 
applications, you'd like to remove the

 PC from the picture (satellites come immediately to mind).


--
Marcus LeechMail:   Dept 1A12, M/S: 04352P16
Security Standards AdvisorPhone: (ESN) 393-9145  +1 613 763 9145
Strategic Standards
Nortel Networks  [EMAIL PROTECTED]



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

[Discuss-gnuradio] Easiest way to perform vector cross correlation on USRP?

[Lin Ji]

Hi,
  I wonder what if the easiest way to perform real-time cross correlation in the FPGA on USRP? I've worked weeks on writing a close form algebra doing cross correlation,but since all my algorithms are based on floating points and multiplication/division, I'm afraid it's hard to convert that to Verilog code later.

  All I need to do is for 2 sequence A and B, perform this:
 max(ifft(fft(A).*conj(fft(B;
 It's really easy to do in MATLAB and relativly simple in C++, but in Verilog? I have no idea...
 Please people, if any one has done this before or anything related, share some information with me, I would really preciate that!
/Lin Ji
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Easiest way to perform vector cross correlation on USRP?

[Brian Padalino]

With a Cyclone part with no dedicated multipliers, you are asking a
lot of logic to create your multipliers.  I would not suggest trying
to do this type of calculation in this particular FPGA.

If you want to know how to do it in Verilog, you need to take into
consideration your sample rate along with your clock rate.  Given
this, you have N clock cycles to perform the calculations.  If you
were to do something like this, you could possibly have a block that
performs the two FFT's in parallel and puts the results into a
BlockRAM.  By the time this is done, the next frame is ready for the
FFT, so while this is processing you can perform the cross correlation
and store those results in the next BlockRAM.  After doing this, you
can do the IFFT out of that BlockRAM and pass the results into a small
block to calculate the max value.

You can get Altera tools to generate cores that will perform FFTs and
IFFTs for you.  The cross correlation would then be the handcoded part
along with the max logic.

http://www.altera.com/products/ip/dsp/transforms/m-ham-fft.html

You can also try opencores.org and check out their FFT section, but as
I said earlier - without dedicated multipliers, it would require a
HUGE part and slow down your design significantly.

Hope this helps!

Brian

On 11/3/06, Lin Ji <[EMAIL PROTECTED]> wrote:

Hi,
  I wonder what if the easiest way to perform real-time cross correlation in
the FPGA on USRP? I've worked weeks on writing a close form algebra doing
cross correlation,but since all my algorithms are based on floating points
and multiplication/division, I'm afraid it's hard to convert that to Verilog
code later.
  All I need to do is for 2 sequence A and B, perform this:
 max(ifft(fft(A).*conj(fft(B;
 It's really easy to do in MATLAB and relativly simple in C++, but in
Verilog? I have no idea...
 Please people, if any one has done this before or anything related, share
some information with me, I would really preciate that!
/Lin Ji
___
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] HDTV Receiver and additional hardware

[Berkley, Antwong L.]

I want to build a SDR that can capture an HDTV (non-real
time) and then transmits.  I have a USRP and the Rx daughterboards. 
Are there any up to date HowTo’s on Building a HDTV Rx using USRP.? 

 

Do I have to buy any additional hardware, I am not cash
rich.

 

Regards,

 

Antwong Berkley 

 






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

[Discuss-gnuradio] HP Compaq

[Roberto Mastrodonato]

Hi all
 
Does anybody know if it's possible to install GNURADIO -usrp on a HP Compaq Thin Client Linux embedded (Linux 2.4)?
 
10x a lot Group!!!
Roberto
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] cygwin build

[Bob Vincent]

In gnuradio-core/src/swig make, I get the following error many times,
with the field value different.
Any idea what's wrong? 
/c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s: Assembler
messages:
/c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s:2106: Warning: .stabs:
description
 field '20cb4' too big, try a different debug format

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

Re: [Discuss-gnuradio] GNU SDR DSP backend question

[Jonathan Jacky]

On Thu, 2 Nov 2006, Garrett McGrath wrote:


If somebody
could link me some information on how the block code architecture was
concieved ...


The JSAC96 and JSAC98 papers linked below are informative.
As I understand it, the VuSystem and SpectrumWare/PSpectra
projects at MIT in the mid and late 1990's influenced GNU
Radio.  Early GNU Radio distributions included the PSpectra code, I 
recall.   According to the papers, VuSystem was the immediate ancestor of 
PSPectra.


VuSystem, multimedia
http://tns-www.lcs.mit.edu/vs/vusystem.html
http://tns-www.lcs.mit.edu/publications/JSAC96.html

SpectrumWare/PSpectra, software radio
http://www.sds.lcs.mit.edu/SpectrumWare/home.html
http://www.sds.lcs.mit.edu/~vanu/JSAC98.ps

Jon Jacky



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

[Discuss-gnuradio] usrp boards Configuration

[Roberto Mastrodonato]

Hi all
 
I have a question about usrp configuration:
there's a machine A having as gateway the machine B, which hosts a usrp board. Then I have a machine D having as gateway the machine C, which hosts another usrp board. I'm able to ping B form C and viceversa but I can't ping A from D and viceversa. How should I configure B and C in order to ping A from D?

 
BTW, are there some example about vhdl data processing inside the fpga?
 
Thanks in advance
 
Roberto 
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cygwin build

[Don Ward]

These are warnings only and are normal.  (It 
would be nice if there were a way to
get rid of them, though---it takes a lot of time to 
print a million of them!)
 
Are you building on MinGW?  How is it 
going?  Any tips for the wiki page (that I'm planning to 
write)?
 
-- Don W.

  - Original Message - 
  From: 
  Bob Vincent 

  To: discuss-gnuradio@gnu.org 
  Sent: Friday, November 03, 2006 11:46 
  AM
  Subject: [Discuss-gnuradio] cygwin 
  build
  
  In gnuradio-core/src/swig make, I get the following error many times, 
  with the field value different.Any idea what's wrong? /c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s: Assembler 
  messages:/c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s:2106: Warning: 
  .stabs: description field '20cb4' too big, try a different debug 
  format 
   
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cygwin build

[Bob Vincent]

At 12:13 PM 11/3/2006, Don Ward wrote:
These are
warnings only and are normal.  (It would be nice if there were a way
to
get rid of them, though---it takes a lot of time to print a million of
them!)
Thanks for the info. I'll just plug on.
 
Are you building on MinGW?  How is it
going?  Any tips for the wiki page (that I'm planning to
write)?
I'm trying cygwin.
So far, I had two conflicting versions of cppunit, and swig wasn't
installed right from cygwin distribution (maybe it was me?).
Anyway, I removed and reinstalled cppunit.
For the swig install, for some reason the cygwin prebult version didn't
have the swg files in it. So I built and installed the latest, and had to
manually link swig.exe to swig in /usr/bin. 
Not sure if these are just my personal cygwin installation or whether
others might have a similar experience...
 
-- Don W.


- Original Message - 

From: Bob Vincent 

To:
discuss-gnuradio@gnu.org


Sent: Friday, November 03, 2006 11:46 AM

Subject: [Discuss-gnuradio] cygwin build

In gnuradio-core/src/swig make, I get the following error many times,
with the field value different.

Any idea what's wrong? 

/c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s: Assembler
messages:

/c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s:2106: Warning: .stabs:
description

 field '20cb4' too big, try a different debug format 

 



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

[Discuss-gnuradio] Software Defined Radio - PowerPC

[Guillaume FORTAINE]

Hello,

Let me introduce myself : Guillaume FORTAINE, French engineer in informatics.
I would want to build a start up to sell mobile phones ( OEM Level ). I am 
currently in discussions with investors.

 We are currently searching people with a strong background in  Hardware 
Design and SystemC/ SystemC AMS.

Our business model is in its early stage, but we would be interested into a 
break oppposite to the legacy one of our competitors who are nearly all 
ARM based. Our choice is to use the PowerPC  architecture : all the challenge 
is here, that's why we need people with a strong background...   This is a 
very big project.

We are ready to sign a contract with people who will be able able to develop a 
modem around a PPC chip with the less modifications ( reuse a maximum of 
ALTIVEC std PPC instructions ).
 
 We look forward to your answer,

 Best Regards,

  Guillaume


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

[Discuss-gnuradio] ADS-B decoding

[Eric Blossom]

FYI,
Eric

http://tech-software.net/viewtopic.php?t=16
--- Begin Message ---
* High Performance Software Defined Radio Discussion List *

Bitscope has arrived , been playing with aircraft signals.

http://tech-software.net/viewtopic.php?t=16

Andy

-
Andrew Rich
Amateur radio callsign VK4TEC
email: [EMAIL PROTECTED] 
web: http://www.tech-software.net
Brisbane AUSTRALIA



-Original Message-
From: Cecilio Bayona [mailto:[EMAIL PROTECTED]
Sent: Friday, 3 November 2006 2:46 AM
Cc: High Performance Software Defined Radio Discussion List
Subject: Re: [hpsdr] New Altera toys


* High Performance Software Defined Radio Discussion List *

[EMAIL PROTECTED] wrote:
> * High Performance Software Defined Radio Discussion List *
>
> I see that Altera have announced a new Cyclone II evaluation board
>
> http://www.altera.com/products/devkits/altera/kit-cyc2-2C20N.html
>
>
> Pity that it only uses 12MHz USB since the audio, video and memory
facilities
> are nice.
>
> Also, ModelSim is free for a while
>
>
https://www.altera.com/support/software/download/eda_software/modelsim/msm-
> index.jsp
>
> Anyone tried it?
>
> 73's Phil...VK6APH
>

I've ordered one these boards a couple of weeks ago, estimated shipping
date 12/01/2006, I think they announced the product a little prematurely
to say the least.

--

Cecil
KD5NWA
www.qrpradio.com www.hpsdr.com


"Sacred Cows make the best Hamburger!"  Don Seglio Batuna
___
HPSDR Discussion List
To post msg: [EMAIL PROTECTED]
Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
HPSDR web page: http://hpsdr.org
Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/


___
HPSDR Discussion List
To post msg: [EMAIL PROTECTED]
Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
HPSDR web page: http://hpsdr.org
Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
--- End Message ---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Support for SUSE 10.1 on x64

[Ram]

Hi people,
 
Will GNU radio build and install on a X64 box running SUSE linux 10.1
 
Thanks,
 
Ram Ramani
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] reading and writing registers

[Eric Blossom]

On Fri, Nov 03, 2006 at 02:43:46AM -0800, seph 004 wrote:
> Hi
> 

> I am having some trouble trying to get register writing and reading
> from the C++ level to work. I've created two methods:
>
> for writing
> 
> static bool
> write_a_reg (usrp_basic *u, int address, int amount)
> {
>   bool isit = u->_write_fpga_reg (address, amount);
> 
>   return isit;
> }
> 
> for  reading 
> 
> int
> read_a_reg (usrp_basic *u, int address)
> {
>   int val = u->_read_fpga_reg (address);
> 
>   return val;
> }

> When I use the write method:
> 
> bool fine2 = write_a_reg (urx, 78, 60);
> 
> The returned boolean indicates that the write was successful. If I try to 
> read the same register though:
> 
> int value = read_a_reg (urx, 78);
> 
> it always returns zero no matter what I put in. The urx is the
> handle of a usrp_standard_rx object, and if I'm not mistaken,
> register number 78 (`FR_USER_14) shoul be free to use. What am I
> doing wrong?

> Regards
> Lance

Assuming that all registers are readable, or that they
are in the same address space as the writable registers would be a
mistake.

Try reading from registers 1, 2 or 3.  See
usrp/firmware/include/fpga_regs_standard.h, down toward the bottom.

Please also note that writing random values into random registers can
lead to permanent damage.  FR_USER_0 through FR_USER_15 are safe to
write with the .rbf's that we distribute.  We don't pay any attention
to them.

Eric


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

Re: [Discuss-gnuradio] PYTHONPATH on Fedora Core 6 x86_64

[Eric Blossom]

On Fri, Nov 03, 2006 at 12:25:33PM +0100, Trond Danielsen wrote:
> Hi everyone!
> 
> I have followed the instructions on
> http://gnuradio.org/trac/wiki/FC5Install, but I still have a problem.
> Python does not find the modules unless I add all the necessary
> subfolders to PYTHONPATH. Any ideas on what I am doing wrong?
> 
> Best Regards,
> -- 
> Trond Danielsen

You may need to create an empty file called __init__.py in the one or
more of the site-packages and/or site-packages/gnuradio directories.

Somebody who cares should file a bug report against this inconsistency
in whatever bug tracker FC* uses.  They treat system installed
packages different than third party packages.

Eric


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

Re: [Discuss-gnuradio] cygwin build

[Eric Blossom]

On Fri, Nov 03, 2006 at 11:46:58AM -0500, Bob Vincent wrote:
> In gnuradio-core/src/swig make, I get the following error many times, 
> with the field value different.
> Any idea what's wrong?
> 
> /c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s: Assembler messages:
> /c/DOCUME~1/bvincent/LOCALS~1/Temp/cciyQk1k.s:2106: Warning: .stabs: 
> description
>  field '20cb4' too big, try a different debug format 


gnuradio_swig_python.cc is huge (we will be chop it into smaller
pieces when we address ticket:69).  Try specifying --gdwarf2 option to
g++.  That uses the "DWARF2" debugging format which is known to work.
You could also try using the specifying

  $ CXXFLAGS="-O2" ./configure

I believe that this will result in the -g option (output debugger
info) being omitted from the call to g++.

Eric


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

Re: [Discuss-gnuradio] usrp boards Configuration

[Eric Blossom]

On Fri, Nov 03, 2006 at 05:55:42PM +0100, Roberto Mastrodonato wrote:
> Hi all
> 
> I have a question about usrp configuration:
> there's a machine A having as gateway the machine B, which hosts a usrp
> board. Then I have a machine D having as gateway the machine C, which
> hosts another usrp board. I'm able to ping B form C and viceversa but I
> can't ping A from D and viceversa. How should I configure B and C in order
> to ping A from D?

Please talk to a local networking expert.  
We're not the network sysadmin help list.

> BTW, are there some example about vhdl data processing inside the fpga?

The best example is the existing source code.
See usrp/fpga/toplevel/usrp_std/usrp_std.v

> Thanks in advance
> 
> Roberto

Eric


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

Re: [Discuss-gnuradio] Support for SUSE 10.1 on x64

[Eric Blossom]

On Fri, Nov 03, 2006 at 04:21:02PM -0500, Ram wrote:
> Hi people,
> 
> Will GNU radio build and install on a X64 box running SUSE linux 10.1
> 
> Thanks,
> Ram Ramani


Yes, that's what I'm running on my dual opteron.

Eric


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

[Discuss-gnuradio] usrp.source_s and usrp.source_c

[Dawei Shen]

Hi, GuysI am suddenly a little bit confused about the difference between usrp.source_s and usrp.source_c. Basically I have two questions:1. Since the ADC only has 12 bits, does it mean the short integers entering the computer have their last four bits as zeros? Or are their first four digits are zero (the first bit should be the sign)?
2. Is anything interesting done when the short integers converted to float values? Or are they simply converted to a different type without changing the values?Thank you~Dawei
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp.source_s and usrp.source_c

[Matt Ettus]

Dawei Shen wrote:
> Hi, Guys
>
> I am suddenly a little bit confused about the difference between
> usrp.source_s and usrp.source_c. Basically I have two questions:
>
> 1. Since the ADC only has 12 bits, does it mean the short integers
> entering the computer have their last four bits as zeros? Or are their
> first four digits are zero (the first bit should be the sign)?
When you decimate a 12-bit signal, more bits of precision are created. 
That is why all 16 bits are used.

>
> 2. Is anything interesting done when the short integers converted to
> float values? Or are they simply converted to a different type without
> changing the values?
Nothing other than a conversion -- Please see the code
(gr-usrp/src/usrp1_source_c.cc):

  *for* (*int* i = 0; i < nitems; i++){
out[i] = gr_complex ((*float*) usrp_to_host_short(s16[2*i+0]),
 (*float*) usrp_to_host_short(s16[2*i+1]));  }




Matt


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

Re: [Discuss-gnuradio] usrp.source_s and usrp.source_c

[Eric Blossom]

On Fri, Nov 03, 2006 at 06:58:41PM -0500, Dawei Shen wrote:
> Hi, Guys
> 
> I am suddenly a little bit confused about the difference between
> usrp.source_s and usrp.source_c. Basically I have two questions:
> 
> 1. Since the ADC only has 12 bits, does it mean the short integers entering
> the computer have their last four bits as zeros? Or are their first four
> digits are zero (the first bit should be the sign)?

The short integers entering the computer have been through the DDC and
have been processed as 16-bit ints.  Without looking at the verilog
code I don't recall how they're adjusted before being clocked into the
DDC.

> 2. Is anything interesting done when the short integers converted to float
> values? Or are they simply converted to a different type without changing
> the values?

At this point nothing besides the format conversion is done.

There have been some conversations about changing the _c format to be
normalized to +/- 1.0 but the details aren't worked out yet.   We'll
probably define a new interface so that we don't break a bunch of
code.  The normalization would also be a function of the kind of
daughterboard that's connected, and will probably factor in some kind
of two-tone IMD performance result.

Eric


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

[Discuss-gnuradio] Call for testing release 3.0.1

[Johnathan Corgan]

All,

The GNU Radio release 3.0 branch has accumulated a few bug fixes and
updates over the last several weeks since the 3.0 tarballs went out.
None of these have been serious, and the rate of new bugs has dropped to
nearly zero.  

The latest of these updates has been to fix the build issue with
automake 1.10.0.  Since that is now the default for Cygwin and Gentoo,
it will likely be the version shipping with other distributions or
systems soon.  So, at this point we'd like to cut a 3.0.1 cumulative bug
fix release.

I've created a Wiki page with the details of what's changed since
release 3.0:

http://gnuradio.org/trac/wiki/Release3.0Branch

To summarize here:

* Updated AUTHORS file (r3740, r3750)
* Changed line ending style on config/*.m4 (r3751, r3776, ticket:88)
* Improved gr-video-sdl configuration error message (r3752, ticket:84)
* Fixed 'make clean' breakage using BSD make (r3753, ticket:87)
* Fixed non-portable constructs in build (r3775, r3839, r3840)
* Remove bashisms in build system (r3797, r3838)
* Updated gr-how-to-write-a-block README (r3841)
* Improved error message on size mismatch in fg.connect (r3849)
* Eliminate compiler warnings (r3854)
* Fix for systems missing include/linux/compiler.h (r3914)
* Fix for working with automake >= 1.10.0 (r3923, ticket:92)

What we'd like is for people to test this in all the usual ways before
we cut tarballs.  You can point your svn client at:

http://gnuradio.org/svn/gnuradio/branches/releases/3.0

(This is not the same as the tagged 3.0 release, but rather is the part
of the repository we've been accumulating the bug fixes into.)

If you find an issue, please file a bug on the Trac system at:

http://gnuradio.org/trac

...by logging in as username 'guest' and password 'gnuradio' (without
quotes.)

Thanks!

-- 
Johnathan Corgan, AE6HO
Corgan Enterprises LLC
[EMAIL PROTECTED]



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

Re: [Discuss-gnuradio] am_rcv.py

[Eric Hill Matlis]

Matt-

thanks for getting back.  I've attached the code as it currently stands. 
What parts are out of date?  The important parts (formatted slightly to 
fit on the screen) are:

**
adc_rate = self.u.adc_rate()# 64 MS/s
usrp_decim = 250
self.u.set_decim_rate(usrp_decim)
usrp_rate = adc_rate / usrp_decim   # 256 kS/s
chanfilt_decim = 16
demod_rate = usrp_rate / chanfilt_decim # 16 kHz
audio_decimation = 1
audio_rate = demod_rate / audio_decimation  # 16 kHz

chan_filt_coeffs = gr.firdes.low_pass (1,   # gain
usrp_rate,   # sampling rate
9e3,# passband cutoff
10e3,   # stopband cutoff
gr.firdes.WIN_HANN)
self.ddc =  \
gr.freq_xlating_fir_filter_ccf(chanfilt_decim,chan_filt_coeffs,0,usrp_rate)

self.magblock = gr.complex_to_mag()
audio_coeffs = gr.firdes.low_pass (1.0,# gain
   usrp_rate,  # sampling rate
   9e3,
   4e3,
   gr.firdes.WIN_HANN)
audio_filter = gr.fir_filter_fff (audio_decimation, audio_coeffs)
*

any comments?  Particularly on the filter coefficients.  I'm not sure yet 
how to select these.  My requirements at this stage are to demodulate 
sidebands with frequencies of up to say 8 kHz riding on a 2 or 3 MHz 
carrier.  (using the LFRX DC-50MHz daughterboard).  Currently I don't care 
about the audio port as a sink; I simply want to display the fft's on the 
screen.  Eventually I may want to capture to file.


thanks!

p.s.- do you have pictures of the enclosure?  I just built one using an 
extruded aluminum case from Box Enclosures, Inc that has very similar 
dimensions.  It's a very handsome box, only I couldn't get the TVRX module 
to fit; the USRP would only go in one way.  If I rotated 90 (which would 
have allowed the TVRX to fit) then it wouldn't work because the 
motherboard was about 0.03" too big.  There are pics of it at 
www.nd.edu/~ematlis/z.gnuradio/z.enclosure_pics



Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355

On Thu, 2 Nov 2006, Matt Ettus wrote:



Have you solved this yet?  Is it possible that you are decimating too much?

The am_rcv code is very old. I would start fresh if I were you.

Matt

Eric Hill Matlis wrote:

I do have 5 kHz sidebands, and this is verified by the location of the
peaks in the first two fft graphs.  It's just the third graph which
showed an aliased signal.  Could the filter taps be incorrect?

eric

On Thu, 26 Oct 2006, Matt Ettus wrote:


Eric Hill Matlis wrote:

Hello-

I am attempting to demodulate an A.M. modulated signal using
am_rcv.py, the USRP, an LFRX daughterboard, and the latest svn
gnuradio distribution. At present the signal is being generated by a
function generator (Stanford Research Systems Model DS345) with a 2
MHz carrier and a 5 kHz modulation. I have some questions about the
demodulation being performed by the am_rcv.py program found in the
examples directory for the usrp.

1) The first graph is labeled as "Pre-Demodulation", yet it is
actually not representative of the original waveform as it has been
downshifted to the offset frequency of 30 kHz (as I recall, there is
an issue with the USRP that requires this 30 kHz offset, but I don't
know the particulars about that, perhaps somebody can explain?).  I
would like to plot the original waveform.  Is there a way of showing
the fft of the original waveform with the carrier at 2 MHz and
sidebands at 1.995 and 2.005 MHz?


We don't need that 30 kHz offset anymore.  To show the original
waveform, just follow the code in usrp_fft.py


2)  While the second "Post Demodulation" graph correctly shows the
sidebands at +/- 5 kHz, the decimation filters are aliasing the
sideband in the "Post Filter" graph to 2.5 kHz.  I have to reduce the
"audio_decimation" from 2 to 1 to prevent this aliasing.  Why would
this be happening?  The original final decimation of 2 produces an
effective sampling rate of 32 kHz, which should be sufficient to
resolve the sideband at 5 kHz.


Sounds odd.  Are you sure you have 5 kHz sidebands?

3) What sets the limits on the axes of these graphs?  Is it possible
to modify them?


The x-axis will match the sample rates.  The Y-axis can be modified by
right-clicking.

I am hopefully going to be using the USRP and gnuradio to demonstrate
a sensor 

Re: [Discuss-gnuradio] Call for testing release 3.0.1

[Berndt Josef Wulf]

G'day,

Will we see a release candidate tarball before the final release? It was the 
tarballed version that caused me grieve last time.

SVN based source built, checked, installed and runs fine on 
NetBSD-4.99.3-i386. I couldn't test usrp code since I'm away from home in 
Beijing at the moment.

Noted: gr-gsm-vocoder doesn't appear to execute any test code

barossa: {25} make check

Making check in src
Making check in lib
make  check-recursive
Making check in gsm
Making check in .
Making check in python
make  check-TESTS

--
Ran 0 tests in 0.000s

OK
PASS: run_tests
==
All 1 tests passed
==


BTW: Is it now save to use "make -j "?

cheerio Berndt

On Saturday 04 November 2006 11:52, Johnathan Corgan wrote:
> All,
>
> The GNU Radio release 3.0 branch has accumulated a few bug fixes and
> updates over the last several weeks since the 3.0 tarballs went out.
> None of these have been serious, and the rate of new bugs has dropped to
> nearly zero.
>
> The latest of these updates has been to fix the build issue with
> automake 1.10.0.  Since that is now the default for Cygwin and Gentoo,
> it will likely be the version shipping with other distributions or
> systems soon.  So, at this point we'd like to cut a 3.0.1 cumulative bug
> fix release.
>
> I've created a Wiki page with the details of what's changed since
> release 3.0:
>
> http://gnuradio.org/trac/wiki/Release3.0Branch
>
> To summarize here:
>
> * Updated AUTHORS file (r3740, r3750)
> * Changed line ending style on config/*.m4 (r3751, r3776, ticket:88)
> * Improved gr-video-sdl configuration error message (r3752, ticket:84)
> * Fixed 'make clean' breakage using BSD make (r3753, ticket:87)
> * Fixed non-portable constructs in build (r3775, r3839, r3840)
> * Remove bashisms in build system (r3797, r3838)
> * Updated gr-how-to-write-a-block README (r3841)
> * Improved error message on size mismatch in fg.connect (r3849)
> * Eliminate compiler warnings (r3854)
> * Fix for systems missing include/linux/compiler.h (r3914)
> * Fix for working with automake >= 1.10.0 (r3923, ticket:92)
>
> What we'd like is for people to test this in all the usual ways before
> we cut tarballs.  You can point your svn client at:
>
> http://gnuradio.org/svn/gnuradio/branches/releases/3.0
>
> (This is not the same as the tagged 3.0 release, but rather is the part
> of the repository we've been accumulating the bug fixes into.)
>
> If you find an issue, please file a bug on the Trac system at:
>
> http://gnuradio.org/trac
>
> ...by logging in as username 'guest' and password 'gnuradio' (without
> quotes.)
>
> Thanks!


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