Re: [Discuss-gnuradio] RFX2400+USRP buffers

[kaleem ahmad]

Any ideas or comments will be helpful for me and I am anxiously waiting!!!.

Kaleem Ahmad

kaleem ahmad wrote:
> 
> Hello everyone,
> 
> I am trying to implement a simple FSK system to measure bit error rate
> (BER), and packet loss rate (PLR) using:
> 
> 1-Linux
> 2-USRP motherboard
> 3-RFX2400 daughter card
> 
> I want to implement an echo back system where one Transceiver (say Master)
> will transmit a small frame (let say 48 byte, and important thing is that
> I neccessarily need small payload) to other transceiver (say Slave). The
> Salve returns the frame immediatelly without any processing to Master  and
> Master measures BER and PLR.
> 
> The problem which I am facing is that I am unable to transmitt such small
> packets. I have noticed that if I have a large file with let say few
> Kbytes contents then it is transmitted (partially, the end of file is
> always missing...I guess it is stuck somewhere in buffer) but if I
> have such small packets as I metioned earlier then most of the time the
> packets are lost. If the packet is received then it is totally corrupt
> (say almost 100% BER) unlike large files which are received in very good
> quality (But important and notable point is that even the large files are
> 100% courrupt at the end). This makes me wonder why last few hundered
> bytes are always courrupt??? (for small file the whole file lies in that
> category of last few hundered bytes)
> 
> I have tried a lot but unable to solve the problem! Now can any one help
> me to understand what can be the problem? Is it somewhere in the buffers?
> Is it some sort of synchronization problem??? and which buffers (of
> USRP/RFX2400/GNURadio) are involved in such flowgraph. The flow graph with
> actual names of blocks used by me is given below (I have attached complete
> code if some one want to have a look):
> 
> Transmit path flowgraph:
> 
> gr.file_source -> gr.simple_framer -> gr.bytes_to_syms ->
> gr.interp_fir_filter_fff -> gr.frequency_modulator_fc ->
> gr.multiply_const_cc -> usrp.source_c
> 
> Receive path flowgraph:
> 
> usrp.source_c -> gr.fir_filter_ccf -> gr.quadrature_demod_cf ->
> simple_correlator -> gr.file_sink
> 
> Best Regards
> 
> Kaleem Ahmad
> 
>  http://www.nabble.com/file/p19415046/fsk_rx.py fsk_rx.py 
> http://www.nabble.com/file/p19415046/fsk_tx.py fsk_tx.py 
> 

-- 
View this message in context: 
http://www.nabble.com/RFX2400%2BUSRP-buffers-tp19415046p19430641.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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

Re: [Discuss-gnuradio] RFX2400+USRP buffers

[kaleem ahmad]

Dear All,

I have tried different packet sizes and I found that 2048 bytes data at the
end is always missing:

With 128 byte packet size 17 last packets were not received
With 256 byte packet size 8 last packets were not received
With 512 byte packet size 4 last packets were not received
With 1024 byte packet size 2 last packets were not received

Can some one give me any clue??? Actually one possible solution can be
to send 2048 bytes dummy data at the end of every packet, but the problem is
I want to send small packets of not more than 100 bytes...so it is large
overhead for me...So if someone can give me some clue about where this data
is being lost then it will be a great help

Best Regards



kaleem ahmad wrote:
> 
> Any ideas or comments will be helpful for me and I am anxiously
> waiting!!!.
> 
> Kaleem Ahmad
> 
> kaleem ahmad wrote:
>> 
>> Hello everyone,
>> 
>> I am trying to implement a simple FSK system to measure bit error rate
>> (BER), and packet loss rate (PLR) using:
>> 
>> 1-Linux
>> 2-USRP motherboard
>> 3-RFX2400 daughter card
>> 
>> I want to implement an echo back system where one Transceiver (say
>> Master) will transmit a small frame (let say 48 byte, and important thing
>> is that I neccessarily need small payload) to other transceiver (say
>> Slave). The Salve returns the frame immediatelly without any processing
>> to Master  and Master measures BER and PLR.
>> 
>> The problem which I am facing is that I am unable to transmitt such small
>> packets. I have noticed that if I have a large file with let say few
>> Kbytes contents then it is transmitted (partially, the end of file is
>> always missing...I guess it is stuck somewhere in buffer) but if I
>> have such small packets as I metioned earlier then most of the time the
>> packets are lost. If the packet is received then it is totally corrupt
>> (say almost 100% BER) unlike large files which are received in very good
>> quality (But important and notable point is that even the large files are
>> 100% courrupt at the end). This makes me wonder why last few hundered
>> bytes are always courrupt??? (for small file the whole file lies in that
>> category of last few hundered bytes)
>> 
>> I have tried a lot but unable to solve the problem! Now can any one help
>> me to understand what can be the problem? Is it somewhere in the buffers?
>> Is it some sort of synchronization problem??? and which buffers (of
>> USRP/RFX2400/GNURadio) are involved in such flowgraph. The flow graph
>> with actual names of blocks used by me is given below (I have attached
>> complete code if some one want to have a look):
>> 
>> Transmit path flowgraph:
>> 
>> gr.file_source -> gr.simple_framer -> gr.bytes_to_syms ->
>> gr.interp_fir_filter_fff -> gr.frequency_modulator_fc ->
>> gr.multiply_const_cc -> usrp.source_c
>> 
>> Receive path flowgraph:
>> 
>> usrp.source_c -> gr.fir_filter_ccf -> gr.quadrature_demod_cf ->
>> simple_correlator -> gr.file_sink
>> 
>> Best Regards
>> 
>> Kaleem Ahmad
>> 
>>  http://www.nabble.com/file/p19415046/fsk_rx.py fsk_rx.py 
>> http://www.nabble.com/file/p19415046/fsk_tx.py fsk_tx.py 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/RFX2400%2BUSRP-buffers-tp19415046p19433136.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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

Re: [Discuss-gnuradio] Important: New trunk dependency: GSL

[Greg Troxel]

  I'll be adding the GNU Scientific Library (GSL) as a new dependency
  on the trunk.  GSL is a huge numerical library that's been under
  active development for more than 10 years:

http://www.gnu.org/software/gsl

FYI this is in pkgsrc as math/gsl and it's at 1.11.



pgp7l7KkpdYAx.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reading carrier frequency

[Eric Blossom]

On Wed, Sep 10, 2008 at 11:46:26PM -0600, Gnu Radio Explorer wrote:
> Hi,
> I am new to GNU radio and want to experiment. From the mailing lists, I
> understood that the carrier frequency offsets change over time but that
> those offsets are within +/- 20ppm of the center frequency. Suppose I use
> two USRP boards; one for transmission and another for reception of signals.
> I want to know how I can read the carrier frequency of  the transmitted
> signal on the receiver side through a python or C++ program. Is there any
> program to do this? Or, which library routine can I use for this purpose?
> 
> Appreciate any kind of help you may provide on this.
> 
> Thanks.
> 
> G.

This is a FAQ that needs an answer.  Can someone please write
something up on carrier tracking and symbol timing recovery and post
it to the wiki?

Bottom line: there will always be a frequency offset between any two
radios and part of the receiver's job is to handle it.  There's a ton
of literature on this as well as complete text books.  In the simplest
case it's a PLL to track the carrier, but oftentimes it's more
complicated than that.

Eric


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

Re: [Discuss-gnuradio] RFX2400+USRP buffers

[Eric Blossom]

On Thu, Sep 11, 2008 at 01:59:39AM -0700, kaleem ahmad wrote:
> 
> Any ideas or comments will be helpful for me and I am anxiously waiting!!!.
> 
> Kaleem Ahmad
> 
> kaleem ahmad wrote:
> > 
> > Hello everyone,
> > 
> > I am trying to implement a simple FSK system to measure bit error rate
> > (BER), and packet loss rate (PLR) using:
> > 
> > 1-Linux
> > 2-USRP motherboard
> > 3-RFX2400 daughter card
> > 
> > I want to implement an echo back system where one Transceiver (say Master)
> > will transmit a small frame (let say 48 byte, and important thing is that
> > I neccessarily need small payload) to other transceiver (say Slave). The
> > Salve returns the frame immediatelly without any processing to Master  and
> > Master measures BER and PLR.
> > 
> > The problem which I am facing is that I am unable to transmitt such small
> > packets. I have noticed that if I have a large file with let say few
> > Kbytes contents then it is transmitted (partially, the end of file is
> > always missing...I guess it is stuck somewhere in buffer) but if I
> > have such small packets as I metioned earlier then most of the time the
> > packets are lost. If the packet is received then it is totally corrupt
> > (say almost 100% BER) unlike large files which are received in very good
> > quality (But important and notable point is that even the large files are
> > 100% courrupt at the end). This makes me wonder why last few hundered
> > bytes are always courrupt??? (for small file the whole file lies in that
> > category of last few hundered bytes)

Kaleem, until the inband code is completely sorted out, you'll need to
ensure that the number of samples generated for your burst always ends
up as a multiple of 512 bytes on the USB.  We use 16-bit I & Q on the
USB, so if you're using complex baseband, you need to make sure that
you're sending a multiple of 128 samples.  This includes any frame
synchronization header, the payload, crc, etc.

Eric


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

RE: [Discuss-gnuradio] Modulation Schemes

[Dumezie Maduike]

If it's done using -1 and +1, how are the numbers in the files converted to
1's and 0's.  NRZ encoding converts binary 1's to a + voltage and 0's to a -
voltage.  For example, how would a "5" or even a "Z" in the .dat file be
converted to binary 1's and 0's.

 

Thanks all

 

Dumezie

 

From: Murtuza [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 09, 2008 4:13 AM
To: Dumezie Maduike
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Modulation Schemes

 

Regarding your other question I think the following line in GMSK.py does the
work.

# Turn it into NRZ data.
self.nrz = gr.bytes_to_syms()

Each byte is converted to a symbol of -1 or +1.  I do not know any more
detail. Correct me if I am wrong.

Thanks
Ali




On Tue, Sep 9, 2008 at 3:56 AM, Murtuza <[EMAIL PROTECTED]> wrote:

Look into the directory
/usr/local/lib/python2.x/site-packages/gnuradio/blks2impl/ . It has many
modulation schemes already implemented in Gnuradio. GMSK is infact the
default scheme but one can choose various other provided in this directory. 

Bye
Ali

On Mon, Sep 8, 2008 at 11:34 PM, Dumezie Maduike <[EMAIL PROTECTED]>
wrote:

Hello all,  I'm new to GNU Radio and was wondering what kind of modulation
schemes were available.  I know that GMSK is the default scheme for the
"..digital/benchmark_tx.py" file.  I saw that the schemes are derived from
the "modulation_utils" file.  I'm not sure the available options though.

Also, when the benchmark_tx.py script transmits from a file, how does the
data in the file get transmitted.  For example if file.dat is transmitted
with contents "5123645AY...", are these converted to binary 1's and 0's
using ASCII or Hex conversion and then modulated and transmitted?

Any help will be greatly appreciated.  Thanks all.

Dumezietho





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




-- 
Mir Murtuza Ali
Graduate Student
Center for Wireless Communications
University of Mississippi
University, MS 38677
Ph : (M) 662-202-5472 , (R) 662-513-9903




-- 
Mir Murtuza Ali
Graduate Student
Center for Wireless Communications
University of Mississippi
University, MS 38677
Ph : (M) 662-202-5472 , (R) 662-513-9903

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

Re: [Discuss-gnuradio] Important: New trunk dependency: GSL

[Berndt Josef Wulf]

On Thursday 11 September 2008 21:28:53 Greg Troxel wrote:
>   I'll be adding the GNU Scientific Library (GSL) as a new dependency
>   on the trunk.  GSL is a huge numerical library that's been under
>   active development for more than 10 years:
>
> http://www.gnu.org/software/gsl
>
> FYI this is in pkgsrc as math/gsl and it's at 1.11.

G'day Greg,

FYI: GNU Radio currently won't built on pkgsrc as the versions of boost, wxGTK 
and py-wxWindows are too old. It also lacks py-gsl.

73, Berndt
VK5ABN


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

[Discuss-gnuradio] 802.11a source codes? or any OFDM implementation on GNU Radio

[Mohsen Baratvand]

Hi everyone,

Does anyone know if there is any source code available for OFDM type
standards like 802.11a/g/n?
I'd appreciate it if anybody knows.

Thanks a lot,
Mohsen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 802.11a source codes? or any OFDM implementation on GNU Radio

[Dimitris Symeonidis]

http://gnuradio.org/trac/wiki/BBN_Technologies_Internetwork_Research_ADROIT_Project

On Thu, Sep 11, 2008 at 18:50, Mohsen Baratvand <[EMAIL PROTECTED]>wrote:

> Hi everyone,
>
> Does anyone know if there is any source code available for OFDM type
> standards like 802.11a/g/n?
> I'd appreciate it if anybody knows.
>
> Thanks a lot,
> Mohsen
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with a
mosquito!" - Amnesty International
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 802.11a source codes? or any OFDM implementation on GNU Radio

[Douglas Geiger]

That code does implement an 802.11b receiver, and a transmitter that is 
very similar to 802.11b (since the USRP is limited by the USB bandwidth 
it can't really do real 802.11b - without doing some of the work in the 
FPGA at least).  However, that's all DSSS using a DBPSK/DQPSK modulation 
scheme - not OFDM (or even the 5.5Mbps and 11Mbps CCK data rates).  
Perhaps with the USRP2 - which will be able to do full-bandwidth 
802.11b/g someone will start that (perhaps I will even contribute to 
such work...).

Doug

Dimitris Symeonidis wrote:

http://gnuradio.org/trac/wiki/BBN_Technologies_Internetwork_Research_ADROIT_Project

On Thu, Sep 11, 2008 at 18:50, Mohsen Baratvand <[EMAIL PROTECTED] 
> wrote:


Hi everyone,

Does anyone know if there is any source code available for OFDM
type standards like 802.11a/g/n?
I'd appreciate it if anybody knows.

Thanks a lot,
Mohsen

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




--
Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with 
a mosquito!" - Amnesty International



___
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

Re: [Discuss-gnuradio] 802.11a source codes? or any OFDM implementation on GNU Radio

[Mohammad Hamed Firooz]

 The BBN code is implementation of 802.11b which uses DSSS in its 
physical layer.


hamed

Quoting Dimitris Symeonidis <[EMAIL PROTECTED]>:


http://gnuradio.org/trac/wiki/BBN_Technologies_Internetwork_Research_ADROIT_Project

On Thu, Sep 11, 2008 at 18:50, Mohsen Baratvand <[EMAIL PROTECTED]>wrote:


Hi everyone,

Does anyone know if there is any source code available for OFDM type
standards like 802.11a/g/n?
I'd appreciate it if anybody knows.

Thanks a lot,
Mohsen

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





--
Dimitris Symeonidis
"If you think you're too small to make a difference, try sleeping with a
mosquito!" - Amnesty International





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

Re: [Discuss-gnuradio] 802.11a source codes? or any OFDM implementation on GNU Radio

[Mohsen Baratvand]

Guy, all I need to do is changing some parameters such as preamble, LTF,
STF, modulation and etc of the OFDM transmitter and then send a predefined
pattern to the OFDM receiver, then estimate the channel. So I'm not gonna
pass all the information and data to PC via the USB link. Just sending some
report to my PC.


On Thu, Sep 11, 2008 at 1:52 PM, Douglas Geiger <
[EMAIL PROTECTED]> wrote:

> That code does implement an 802.11b receiver, and a transmitter that is
> very similar to 802.11b (since the USRP is limited by the USB bandwidth it
> can't really do real 802.11b - without doing some of the work in the FPGA at
> least).  However, that's all DSSS using a DBPSK/DQPSK modulation scheme -
> not OFDM (or even the 5.5Mbps and 11Mbps CCK data rates).  Perhaps with the
> USRP2 - which will be able to do full-bandwidth 802.11b/g someone will start
> that (perhaps I will even contribute to such work...).
> Doug
>
> Dimitris Symeonidis wrote:
>
>>
>> http://gnuradio.org/trac/wiki/BBN_Technologies_Internetwork_Research_ADROIT_Project
>>
>> On Thu, Sep 11, 2008 at 18:50, Mohsen Baratvand <[EMAIL PROTECTED]> [EMAIL PROTECTED]>> wrote:
>>
>>Hi everyone,
>>
>>Does anyone know if there is any source code available for OFDM
>>type standards like 802.11a/g/n?
>>I'd appreciate it if anybody knows.
>>
>>Thanks a lot,
>>Mohsen
>>
>>___
>>Discuss-gnuradio mailing list
>>Discuss-gnuradio@gnu.org 
>>http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>>
>> --
>> Dimitris Symeonidis
>> "If you think you're too small to make a difference, try sleeping with a
>> mosquito!" - Amnesty International
>> 
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 802.11a source codes? or any OFDM implementation on GNU Radio

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 11, 2008, at 11:26 AM, Mohsen Baratvand wrote:

Guy, all I need to do is changing some parameters such as preamble,  
LTF, STF, modulation and etc of the OFDM transmitter and then send a  
predefined pattern to the OFDM receiver, then estimate the channel.  
So I'm not gonna pass all the information and data to PC via the USB  
link. Just sending some report to my PC.


It's conceivable that by putting the modulation in the FPGA, you could  
get 802.11a OFDM modulation to work using the USRP -- just send the  
data across the bus. But no one has written such a firmware image yet  
- -- feel free! (Disclaimer: I have no idea whether an 802.11a modulator  
would fit into the small FPGA on USRP1, and haven't tried).


If you want to do modulation in the host, which doesn't involve FPGA  
coding and might allow you to use some of the existing OFDM code,  
you're going to be limited by the bandwidth of the USB -- 8 MHz isn't  
really enough. If you used 8-bit mode to get 16 MHz of bandwidth AND  
used one of the low bitrate encodings, high-SNR packets MIGHT get  
received by a good receiver. I don't know enough about 802.11's use of  
OFDM to decide. Maybe Kyle or Tom has a comment here.


- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjJaHsACgkQy9GYuuMoUJ6QFQCgrtkB7qISfljFS4mlxfZ7+4gL
gvgAn3OEN1ZhcZTGQqh/QljouhIjdiRK
=ksDR
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] 3rd party software

[George P Nychis]

> 
> The slightly longer response:
> 
> I think these are all great ideas, and I think they'd be a valuable 
> contribution to the GNU Radio community.  CPAN (The Comprehensive Perl 
> Archive Network) and CEAN (the Comprehensive Erlang Archive Network) are
> but two implementations of similar ideas.  CPAN has been wildly successful
> and is part of what has driven Perl's popularity.
> 
> If you want to try git -- or whatever -- please do, and keep us informed!
> 

OK, since this is for "us," and us being the GNU Radio community, this should 
be up for discussion with everyone here.

What would people like to see?  Do people have preferences in version control 
systems?  It seems as though most people familiar with GNU Radio are already 
familiar with SVN, so would sticking with SVN be a good idea?

What do people think of trac+SVN for a website and documentation of 
code/projects?

Eric has already provided us with a domain name, and I'm 100% sure CMU could 
host whatever we want... I just want some feedback from the community since 
it's for you (and me ;)) and it should be something people want to use.  Once 
we come up with a basic design and policy, we can move forward.  I just don't 
want to pop up with some website and system that nobody likes, and have to then 
have this discussion and reimplement.

Thanks!
George



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

Re: [Discuss-gnuradio] Reading carrier frequency

[Gnu Radio Explorer]

Thanks for the reply Eric. I am completely new to this field. I understand
the receiver should be able to accomodate these differences.

But is it possible for a GNU radio program running on the receiver computer
to be able to read the changing values of the sender's carrier frequency, or
is it just that the programs will only be able to read the values after the
carrier frequency is converted to the intermediate frequency and not
directly at carrier frequency?

Another question by the way. I am having a RFX 900 board. Suppose a
transmitter program desires that the USRP should produce a signal with
center frequency f1 = 925.123456 MHz, for example. But in reality will the
USRP be able to transmit the signal at this exact frequency f1 (at the
granularity of Hertz) by some way?


Thanks in advance.

G

On Thu, Sep 11, 2008 at 8:02 AM, Eric Blossom <[EMAIL PROTECTED]> wrote:

> On Wed, Sep 10, 2008 at 11:46:26PM -0600, Gnu Radio Explorer wrote:
> > Hi,
> > I am new to GNU radio and want to experiment. From the mailing lists, I
> > understood that the carrier frequency offsets change over time but that
> > those offsets are within +/- 20ppm of the center frequency. Suppose I use
> > two USRP boards; one for transmission and another for reception of
> signals.
> > I want to know how I can read the carrier frequency of  the transmitted
> > signal on the receiver side through a python or C++ program. Is there any
> > program to do this? Or, which library routine can I use for this purpose?
> >
> > Appreciate any kind of help you may provide on this.
> >
> > Thanks.
> >
> > G.
>
> This is a FAQ that needs an answer.  Can someone please write
> something up on carrier tracking and symbol timing recovery and post
> it to the wiki?
>
> Bottom line: there will always be a frequency offset between any two
> radios and part of the receiver's job is to handle it.  There's a ton
> of literature on this as well as complete text books.  In the simplest
> case it's a PLL to track the carrier, but oftentimes it's more
> complicated than that.
>
> Eric
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Reading carrier frequency

[Brian Padalino]

On Thu, Sep 11, 2008 at 4:22 PM, Gnu Radio Explorer
<[EMAIL PROTECTED]> wrote:
> Thanks for the reply Eric. I am completely new to this field. I understand
> the receiver should be able to accomodate these differences.
> But is it possible for a GNU radio program running on the receiver computer
> to be able to read the changing values of the sender's carrier frequency, or
> is it just that the programs will only be able to read the values after the
> carrier frequency is converted to the intermediate frequency and not
> directly at carrier frequency?
>
> Another question by the way. I am having a RFX 900 board. Suppose a
> transmitter program desires that the USRP should produce a signal with
> center frequency f1 = 925.123456 MHz, for example. But in reality will the
> USRP be able to transmit the signal at this exact frequency f1 (at the
> granularity of Hertz) by some way?

You know what might be a good place to start:

http://gnuradio.org/trac/wiki/SuggestedReading

Welcome to the field!  I am sure you will find it fascinating.

Brian


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

Re: [Discuss-gnuradio] 3rd party software

[Dan Halperin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sep 11, 2008, at 1:14 PM, George P Nychis wrote:


The slightly longer response:

I think these are all great ideas, and I think they'd be a valuable
contribution to the GNU Radio community.  CPAN (The Comprehensive  
Perl
Archive Network) and CEAN (the Comprehensive Erlang Archive  
Network) are
but two implementations of similar ideas.  CPAN has been wildly  
successful

and is part of what has driven Perl's popularity.

If you want to try git -- or whatever -- please do, and keep us  
informed!


OK, since this is for "us," and us being the GNU Radio community,  
this should be up for discussion with everyone here.


What would people like to see?  Do people have preferences in  
version control systems?  It seems as though most people familiar  
with GNU Radio are already familiar with SVN, so would sticking with  
SVN be a good idea?


What do people think of trac+SVN for a website and documentation of  
code/projects?


Eric has already provided us with a domain name, and I'm 100% sure  
CMU could host whatever we want... I just want some feedback from  
the community since it's for you (and me ;)) and it should be  
something people want to use.  Once we come up with a basic design  
and policy, we can move forward.  I just don't want to pop up with  
some website and system that nobody likes, and have to then have  
this discussion and reimplement.


My impression is that SVN+trac is working pretty well. My experience  
with git has been everything but positive; maybe because I _still_  
haven't found that simple, elegant reference that explains it well,  
but I'm just not a fan. Plus it would be nice to keep the same model  
as the existing repo so that the checkout and build process is as easy.


Just my 7c :).

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjJg0sACgkQy9GYuuMoUJ7M9ACggVcqrdxroGJalRlSM2LYxic/
CpUAnA1rO4w4eQUXRnOaQxmzp+tnNvZw
=v2QF
-END PGP SIGNATURE-


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

Re: [Discuss-gnuradio] 3rd party software

[George P Nychis]

> My impression is that SVN+trac is working pretty well. My experience with
> git has been everything but positive; maybe because I _still_ haven't
> found that simple, elegant reference that explains it well, but I'm just
> not a fan. Plus it would be nice to keep the same model as the existing
> repo so that the checkout and build process is as easy.
> 
> Just my 7c :).
> 

Thanks Dan!

I agree, svn+trac is the way to go here.  It's what everyone is already 
familiar with, and it works great.

I was thinking that the SVN structure should be something like:
/
/project_name
/project_name/trunk
/project_name/tags
/project_name/branches

and then everyone has read access to everything, and commit access is given to 
individuals working on a project, or pretty much anyone who wants it.  I just 
don't think we can leave it anonymous commit.

Then, there is a mandatory project summary page for each project.  It needs to 
include basic information like the platforms it runs on, the version of GNU 
Radio needed, and any other additional dependencies with a brief description of 
the project.  Probably some maintainer information too.

- George



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

[Discuss-gnuradio] lsusrp

[Brett L. Trotter]

I have a rev 2, rev 3 and a rev 4 usrp here. When I plug in either
the 2 or 3 (no serial #) and a 4 and do a lsusrp, both usrp's show
up as one or the other (daughter cards and everything) until I do a
second lsusrp.

Is this a bug? It's no big deal, but I was curious what's causing it.

This is the svn trunk (up to date) on FC7.


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

Re: [Discuss-gnuradio] lsusrp

[Johnathan Corgan]

Brett L. Trotter wrote:

> I have a rev 2, rev 3 and a rev 4 usrp here. When I plug in either
> the 2 or 3 (no serial #) and a 4 and do a lsusrp, both usrp's show
> up as one or the other (daughter cards and everything) until I do a
> second lsusrp.

The lsusrp program is buggy and incorrectly implemented besides (yes, I
wrote it, it'll be fixed for release 3.2)




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

[Discuss-gnuradio] [cell] videocard with onboard cell processor announced

[Martin Dvh]

http://www.tcmagazine.com/comments.php?id=21673&catid=2

Th Leadtek PxVC1100 card features a PCI-Express x1 interface, active cooling, 
it boasts a SE1000 SpursEngine chip which integrates four
Synergistic Processing Element (SPE) cores, at a currently unknown frequency 
and has 128MB of XDR memory clocked at 1.6 GHz.

Leadtek has yet to announce the card's price or release date.

This would be a nice GnuRadio coprocessor, if the specs and api's are open.

Greetings,
Martin


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

[Discuss-gnuradio] ATSC demod tips

[Ken Harris]

I just got a USRP, and I'm learning how it works.

I'm having trouble getting the ATSC demod to work.

The WFM demod works OK, so I know the antenna, etc works.

	I know I'm tuning the right frequency (KQED with a center 
frequency of 569MHz), because I can see the signal with usrp_fft.


	I got a few underruns during the "usrp_rx_cfile".  About 10 in 10 
seconds.  The raw data file is 446 meg.


	I get an empty output file and a file named "taps.txt", which is 
also empty.


	I tried both the Gnuradio v3.1.2 (in Fedora 9) and the Gnuradio 
from SVN.


	I get a few output strings, like ">>> gr_fir_fff: using SSE" from 
btl-fsd and ">>> gr_fir_fff: using SSE

Setting initial_freq: 3065000.00" from fpll

Do you have any tips on finding the problem?

Thanks.



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