Re: [Discuss-gnuradio] OFDM packets

2008-02-29 Thread Tom Rondeau

Crespi Floriana wrote:

Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received are correct.
CRC controller is perfect but i want a ber estimate, so I change the
payload (binary file) and I  receive check bit by bit.
The result of my alteration test is similar than CRC test.
I have a lot of frequency offset, therefore I change manually the frequency
receiver.
I use revision 6845 and RFX 2400.
Example with crc:
The final packet I receive:
ok: False  pktno 4602   n_rcvd 1300   n_right 83

Why can't i get all the packets?
Could you help me??

I'm testing OFDM system without USRP and none of the packets are lost.

Thanks a lot.
  


Crespi,

I'm not sure what state the OFDM code was in at that revision. That is 
likely a result of the timing issue I discussed in a previous email to 
the list.


The latest revision of the trunk has a much better implementation that 
works well over the air and perfectly in the loopback simulation. There 
is 1 minor problem left that I hope to get to over the weekend for the 
over the air operation. Remember, though, that we don't do any channel 
coding, so any wrong bit will cause a packet error. If you run the code 
currently over the air, BPSK is almost perfect while QPSK and QAMs will 
miss many packets due to only a few bit errors.


In general, the OFDM code is development work so it's likely to be 
buggy. We are working on it, but I can only spend a bit of my time with 
it currently. I would be very happy to see other people getting into the 
code and figuring out ways to make it better.


Thanks,
Tom


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


Re: [Discuss-gnuradio] OFDM packets

2008-02-28 Thread Dan Halperin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

George Nychis wrote:
> it seems to me like you're using antennas, you can try coax to isolate
> the problem maybe you're getting interference at 2.4GHz.  But answer
> Eric's questions too.

With suitable attenuation of course -- I think Matt says at least 30 dB.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHxzTQy9GYuuMoUJ4RAki7AJ98iYlWjoRTvjA21nMsOZQKKFnewACgq6nX
BFb3UQtYJRc36QesNydjKbI=
=km2M
-END PGP SIGNATURE-


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


Re: [Discuss-gnuradio] OFDM packets

2008-02-28 Thread George Nychis



Eric Blossom wrote:

On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote:

Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received are correct.
CRC controller is perfect but i want a ber estimate, so I change the
payload (binary file) and I  receive check bit by bit.
The result of my alteration test is similar than CRC test.
I have a lot of frequency offset, therefore I change manually the frequency
receiver.
I use revision 6845 and RFX 2400.
Example with crc:
The final packet I receive:
ok: False  pktno 4602   n_rcvd 1300   n_right 83

Why can't i get all the packets?
Could you help me??

I'm testing OFDM system without USRP and none of the packets are lost.

Thanks a lot.



Hi Crespi,

You have neglected to tell us virtually anything about your problem.
Could you please tell us:

  which version of GNU Radio?  trunk, tarball (which one), etc?
  what operating system, distribution and architecture?
  the command line you issued
  any modifications you may have made to distributed code?
  anything else that might be relevant




it seems to me like you're using antennas, you can try coax to isolate 
the problem maybe you're getting interference at 2.4GHz.  But answer 
Eric's questions too.


- George


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


Re: [Discuss-gnuradio] OFDM packets

2008-02-28 Thread Eric Blossom
On Thu, Feb 28, 2008 at 12:51:18PM +0100, Crespi Floriana wrote:
> Hi,
> I have a problem with OFDM system.
> I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
> Moreover, only half of the packets received are correct.
> CRC controller is perfect but i want a ber estimate, so I change the
> payload (binary file) and I  receive check bit by bit.
> The result of my alteration test is similar than CRC test.
> I have a lot of frequency offset, therefore I change manually the frequency
> receiver.
> I use revision 6845 and RFX 2400.
> Example with crc:
> The final packet I receive:
> ok: False  pktno 4602   n_rcvd 1300   n_right 83
> 
> Why can't i get all the packets?
> Could you help me??
> 
> I'm testing OFDM system without USRP and none of the packets are lost.
> 
> Thanks a lot.
> 

Hi Crespi,

You have neglected to tell us virtually anything about your problem.
Could you please tell us:

  which version of GNU Radio?  trunk, tarball (which one), etc?
  what operating system, distribution and architecture?
  the command line you issued
  any modifications you may have made to distributed code?
  anything else that might be relevant


Thanks,
Eric


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


[Discuss-gnuradio] OFDM packets

2008-02-28 Thread Crespi Floriana
Hi,
I have a problem with OFDM system.
I transmit OFDM signal at 2.4 GHz, but I receive half of the total packets.
Moreover, only half of the packets received are correct.
CRC controller is perfect but i want a ber estimate, so I change the
payload (binary file) and I  receive check bit by bit.
The result of my alteration test is similar than CRC test.
I have a lot of frequency offset, therefore I change manually the frequency
receiver.
I use revision 6845 and RFX 2400.
Example with crc:
The final packet I receive:
ok: False  pktno 4602   n_rcvd 1300   n_right 83

Why can't i get all the packets?
Could you help me??

I'm testing OFDM system without USRP and none of the packets are lost.

Thanks a lot.




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


Re: [Discuss-gnuradio] OFDM Updates

2008-02-14 Thread Tom Rondeau

Shravan Rayanchu wrote:

Hi Dan and Tom,

Thanks for your comments. I'll trying changing the parameters and look
at the log files to see what might be wrong.

Shravan
  


As you will see in my original email, the problem is inside of the OFDM 
receiver, and I pointed out what that issue is and how to see it. 
Changing the parameters externally will do nothing to solve this.


Tom



On Feb 13, 2008 6:15 PM, Tom Rondeau <[EMAIL PROTECTED]> wrote:
  

Dan Halperin wrote:


Shravan Rayanchu wrote:

  

Basically, I seem to completely lose some of the packets in the air.
Of the packets I receive, almost all the packets are received
correctly. Initially, the error rate was too high (The packets were
getting lost and also among the packets received, lot of them were in
errors), so I increased tx-amplitude to ~3000.

Am I using the right version of the code ? Is the tarball release
better to use ? Can you please let me know if there are any parameters
which I need to change ?



Tom mentioned an existing problem in the email you replied to, which you
didn't address in your response. Could that be the problem or have you
ruled it out?

  

Yes, thanks for pointing that out, Dan. The problem I discussed in my
original email is certainly the problem; it's exactly what I was seeing.



For debugging these types of errors, I really do suggest (from
experience!) that you start saving the outputs of the intermediate
stages to disk and seeing what they look like. It might require some
understanding of the receiver, but then again you probably want that
knowledge anyway...

  

Excellent point. Visualization tools are a key to understanding and
debugging this stuff.

By using the --log option, the receiver will dump output data files for
every important (and even some not-so-important) block in the chain. The
gr_plot_XXX.py scripts are useful for getting a quick look at the
output. There is a local gr_plot_ofdm.py script distributed as part of
the ofdm example directory that provides a specific way of looking at
the output of the OFDM system.



It's likely (as I found with older versions of the DBPSK code, for
instance) that some of the synchronization and/or timing algorithms
aren't working in your setup. But maybe there's lots of cochannel
interference. Maybe the RSSI is low. Maybe the frequency offset of your
daughterboards is too large to be handled by the PLLs...

  

Always the case, really. These methods are as straight-forward as we can
make them to do the basic receivers for different modulations. Most
standard/commercial digital radios do a whole lot more to make sure the
signal is properly received. Cochannel interference will quickly kill
these implementations. And in the case of the M-PSK code, my first
version was textbook while the second version was the right way; that
helps, too :)

Tom




___
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] OFDM Updates

2008-02-13 Thread Shravan Rayanchu
Hi Dan and Tom,

Thanks for your comments. I'll trying changing the parameters and look
at the log files to see what might be wrong.

Shravan

On Feb 13, 2008 6:15 PM, Tom Rondeau <[EMAIL PROTECTED]> wrote:
> Dan Halperin wrote:
> > Shravan Rayanchu wrote:
> >
> >> Basically, I seem to completely lose some of the packets in the air.
> >> Of the packets I receive, almost all the packets are received
> >> correctly. Initially, the error rate was too high (The packets were
> >> getting lost and also among the packets received, lot of them were in
> >> errors), so I increased tx-amplitude to ~3000.
> >>
> >> Am I using the right version of the code ? Is the tarball release
> >> better to use ? Can you please let me know if there are any parameters
> >> which I need to change ?
> >>
> >
> > Tom mentioned an existing problem in the email you replied to, which you
> > didn't address in your response. Could that be the problem or have you
> > ruled it out?
> >
> Yes, thanks for pointing that out, Dan. The problem I discussed in my
> original email is certainly the problem; it's exactly what I was seeing.
>
> > For debugging these types of errors, I really do suggest (from
> > experience!) that you start saving the outputs of the intermediate
> > stages to disk and seeing what they look like. It might require some
> > understanding of the receiver, but then again you probably want that
> > knowledge anyway...
> >
> Excellent point. Visualization tools are a key to understanding and
> debugging this stuff.
>
> By using the --log option, the receiver will dump output data files for
> every important (and even some not-so-important) block in the chain. The
> gr_plot_XXX.py scripts are useful for getting a quick look at the
> output. There is a local gr_plot_ofdm.py script distributed as part of
> the ofdm example directory that provides a specific way of looking at
> the output of the OFDM system.
>
> > It's likely (as I found with older versions of the DBPSK code, for
> > instance) that some of the synchronization and/or timing algorithms
> > aren't working in your setup. But maybe there's lots of cochannel
> > interference. Maybe the RSSI is low. Maybe the frequency offset of your
> > daughterboards is too large to be handled by the PLLs...
> >
> Always the case, really. These methods are as straight-forward as we can
> make them to do the basic receivers for different modulations. Most
> standard/commercial digital radios do a whole lot more to make sure the
> signal is properly received. Cochannel interference will quickly kill
> these implementations. And in the case of the M-PSK code, my first
> version was textbook while the second version was the right way; that
> helps, too :)
>
> Tom
>
>
>
>
> ___
> 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] OFDM Updates

2008-02-13 Thread Tom Rondeau

Dan Halperin wrote:

Shravan Rayanchu wrote:
  

Basically, I seem to completely lose some of the packets in the air.
Of the packets I receive, almost all the packets are received
correctly. Initially, the error rate was too high (The packets were
getting lost and also among the packets received, lot of them were in
errors), so I increased tx-amplitude to ~3000.

Am I using the right version of the code ? Is the tarball release
better to use ? Can you please let me know if there are any parameters
which I need to change ?



Tom mentioned an existing problem in the email you replied to, which you
didn't address in your response. Could that be the problem or have you
ruled it out?
  
Yes, thanks for pointing that out, Dan. The problem I discussed in my 
original email is certainly the problem; it's exactly what I was seeing.



For debugging these types of errors, I really do suggest (from
experience!) that you start saving the outputs of the intermediate
stages to disk and seeing what they look like. It might require some
understanding of the receiver, but then again you probably want that
knowledge anyway...
  
Excellent point. Visualization tools are a key to understanding and 
debugging this stuff.


By using the --log option, the receiver will dump output data files for 
every important (and even some not-so-important) block in the chain. The 
gr_plot_XXX.py scripts are useful for getting a quick look at the 
output. There is a local gr_plot_ofdm.py script distributed as part of 
the ofdm example directory that provides a specific way of looking at 
the output of the OFDM system.



It's likely (as I found with older versions of the DBPSK code, for
instance) that some of the synchronization and/or timing algorithms
aren't working in your setup. But maybe there's lots of cochannel
interference. Maybe the RSSI is low. Maybe the frequency offset of your
daughterboards is too large to be handled by the PLLs...
  
Always the case, really. These methods are as straight-forward as we can 
make them to do the basic receivers for different modulations. Most 
standard/commercial digital radios do a whole lot more to make sure the 
signal is properly received. Cochannel interference will quickly kill 
these implementations. And in the case of the M-PSK code, my first 
version was textbook while the second version was the right way; that 
helps, too :)


Tom



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


Re: [Discuss-gnuradio] OFDM Updates

2008-02-13 Thread Dan Halperin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Shravan Rayanchu wrote:
> Basically, I seem to completely lose some of the packets in the air.
> Of the packets I receive, almost all the packets are received
> correctly. Initially, the error rate was too high (The packets were
> getting lost and also among the packets received, lot of them were in
> errors), so I increased tx-amplitude to ~3000.
> 
> Am I using the right version of the code ? Is the tarball release
> better to use ? Can you please let me know if there are any parameters
> which I need to change ?

Tom mentioned an existing problem in the email you replied to, which you
didn't address in your response. Could that be the problem or have you
ruled it out?

For debugging these types of errors, I really do suggest (from
experience!) that you start saving the outputs of the intermediate
stages to disk and seeing what they look like. It might require some
understanding of the receiver, but then again you probably want that
knowledge anyway...

It's likely (as I found with older versions of the DBPSK code, for
instance) that some of the synchronization and/or timing algorithms
aren't working in your setup. But maybe there's lots of cochannel
interference. Maybe the RSSI is low. Maybe the frequency offset of your
daughterboards is too large to be handled by the PLLs...

The way that you can tell these things is by analyzing the output --
it's really hard for Tom to debug it offline. And he can't test his code
in all possible environments.

- -Dan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHs3iGy9GYuuMoUJ4RAtSyAJ9pyTdRSiJONyTSWtHZErCtzH8FrwCdFYNu
NMAnpoUeOInoFo1U2hRFSZs=
=Y0Jt
-END PGP SIGNATURE-


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


Re: [Discuss-gnuradio] OFDM Updates

2008-02-13 Thread Shravan Rayanchu
Hi Tom,

I checked out the latest version of gnuradio from the trunk (svn co
http://gnuradio.org/svn/gnuradio/trunk gnuradio). I am running the
OFDM code on 2 USRP nodes over the air. The nodes are placed pretty
close to each other (a separation of ~1-1.5 meters) but this is what I
get as the output ::

ok: Truepktno: 100   n_rcvd: 60   n_right: 59
ok: Truepktno: 103   n_rcvd: 61   n_right: 60
ok: Truepktno: 105   n_rcvd: 62   n_right: 61

Basically, I seem to completely lose some of the packets in the air.
Of the packets I receive, almost all the packets are received
correctly. Initially, the error rate was too high (The packets were
getting lost and also among the packets received, lot of them were in
errors), so I increased tx-amplitude to ~3000.

Am I using the right version of the code ? Is the tarball release
better to use ? Can you please let me know if there are any parameters
which I need to change ?

Thanks,
Shravan


On 2/7/08, Tom Rondeau <[EMAIL PROTECTED]> wrote:
> For anyone working with the OFDM code, my latest check-in to the trunk
> fixes some of the main issues of transmitting over the air. Using
> benchmark_ofdm_rx and benchmark_ofdm_tx on different machines, I am now
> able to successfully capture most packets with any modulation at the
> appropriate signal level.
>
> I say most packets because there is still an issue involved in the
> receiver where the regenerator signal pops up before the peak detector
> signal resets it and causes a problem in the packet sampler. To see what
> I mean, run
> "benchmark_ofdm.py --log"
>
> And look at the output of the regen and peak detector blocks:
> gr_plot_char.py ofdm_sync_pn-regen_b.dat ofdm_sync_pn-peaks_b.dat
>
> This will plot a series of 0's with a few 1's, where the peaks occur.
> The peak detector sends it out once, and then the regenerator takes
> over. For every packet, there is one output of the peak detector. If you
> look, sometimes the peak detector will hit just after a regenerated
> signal. By this point, it's too late and the ofdm_sampler has already
> triggered off of the regen signal and ignores the peak.
>
> It's a bit of a hassle, but I'll look into it soon. Any help is
> appreciated, though :)
>
> Tom
>
>
> ___
> 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] OFDM Updates

2008-02-07 Thread Tom Rondeau
For anyone working with the OFDM code, my latest check-in to the trunk 
fixes some of the main issues of transmitting over the air. Using 
benchmark_ofdm_rx and benchmark_ofdm_tx on different machines, I am now 
able to successfully capture most packets with any modulation at the 
appropriate signal level.


I say most packets because there is still an issue involved in the 
receiver where the regenerator signal pops up before the peak detector 
signal resets it and causes a problem in the packet sampler. To see what 
I mean, run

"benchmark_ofdm.py --log"

And look at the output of the regen and peak detector blocks:
gr_plot_char.py ofdm_sync_pn-regen_b.dat ofdm_sync_pn-peaks_b.dat

This will plot a series of 0's with a few 1's, where the peaks occur. 
The peak detector sends it out once, and then the regenerator takes 
over. For every packet, there is one output of the peak detector. If you 
look, sometimes the peak detector will hit just after a regenerated 
signal. By this point, it's too late and the ofdm_sampler has already 
triggered off of the regen signal and ignores the peak.


It's a bit of a hassle, but I'll look into it soon. Any help is 
appreciated, though :)


Tom


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


Re: Fwd: [Discuss-gnuradio] Ofdm parameters

2008-02-04 Thread Eric Blossom
On Sun, Feb 03, 2008 at 05:59:06PM +0100, Jacopo wrote:
> Thanks a lot
> 
> Another question: It's possible to have adaptive modulation, that is the
> possibility to use different modulation for any subcarrier?
> 
> Bye
> 
> Jacopo

It's definitely possible.  The main question is how to design an
interface that isn't hideous.  If you want this, I think you should
work on it and let us know what you come up with.

Eric


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


Re: Fwd: [Discuss-gnuradio] Ofdm parameters

2008-02-03 Thread Tom Rondeau

Jacopo wrote:

Thanks a lot

Another question: It's possible to have adaptive modulation, that is 
the possibility to use different modulation for any subcarrier?


Bye

Jacopo


No, not in the current implementation. You'll have to create a new 
ofdm_modulator block to handle this  behavior.


On that note, that's really the entire point of what we've created (or 
will have once the issues are all worked out). We wanted to show the 
basics of a general OFDM modulator/demodulator so that others can build 
from there with their own interesting stuff.


Tom



2008/2/3, Thomas Rondeau <[EMAIL PROTECTED] >:

Jacopo wrote:
> Thanks! But where can i check this parameter?
>
> Is it possible that fft_length= occupated carrier
(--occupied-tones in
> blksimpl/ofdm.py) + un_used carrier ? Where can i set the
position of
> the occupated_bins?
>
> bye

To modify the bandwidth, you have to set the interpolation and
decimation rates. Yes, fft_length is the size of the FFT or total
number
of subcarriers. Of this, only occupied-tones are used to carry
data. The
unused carriers are distributed evenly on the carriers and you cannot
modify this behavior in the parameters currently, i.e., we do not
support non-contiguous OFDM.

Tom


> 2008/2/2, Matt Ettus <[EMAIL PROTECTED] 
>>:
>
> Jacopo wrote:
> > Hello I'm studing an OFDM implementation on gnuradio. I
want to
> modify
> > benchmark_ofdm_tx.py.
> >
> > I have just read ofdm.py and trasmit_path.py but I can't
find how
> > change some parameters.
> >
> > I'd want a bandwith of 20Mhz, where I can set this option?
Where
> can I
> > set the carriers number? And the pilot bins?
> >
> > Is it possible to set an adaptive modulation for
differents carriers?
>
> The USRP hardware is not capable of bandwidths that
high.  You are
> best
> off staying around 6 MHz.
>
> Matt
>




--
www.fotofestefirenze.it 


___
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: Fwd: [Discuss-gnuradio] Ofdm parameters

2008-02-03 Thread Jacopo
Thanks a lot

Another question: It's possible to have adaptive modulation, that is the
possibility to use different modulation for any subcarrier?

Bye

Jacopo


2008/2/3, Thomas Rondeau <[EMAIL PROTECTED]>:
>
> Jacopo wrote:
> > Thanks! But where can i check this parameter?
> >
> > Is it possible that fft_length= occupated carrier (--occupied-tones in
> > blksimpl/ofdm.py) + un_used carrier ? Where can i set the position of
> > the occupated_bins?
> >
> > bye
>
> To modify the bandwidth, you have to set the interpolation and
> decimation rates. Yes, fft_length is the size of the FFT or total number
> of subcarriers. Of this, only occupied-tones are used to carry data. The
> unused carriers are distributed evenly on the carriers and you cannot
> modify this behavior in the parameters currently, i.e., we do not
> support non-contiguous OFDM.
>
> Tom
>
>
> > 2008/2/2, Matt Ettus <[EMAIL PROTECTED] >:
> >
> > Jacopo wrote:
> > > Hello I'm studing an OFDM implementation on gnuradio. I want to
> > modify
> > > benchmark_ofdm_tx.py.
> > >
> > > I have just read ofdm.py and trasmit_path.py but I can't find how
> > > change some parameters.
> > >
> > > I'd want a bandwith of 20Mhz, where I can set this option? Where
> > can I
> > > set the carriers number? And the pilot bins?
> > >
> > > Is it possible to set an adaptive modulation for differents
> carriers?
> >
> > The USRP hardware is not capable of bandwidths that high.  You are
> > best
> > off staying around 6 MHz.
> >
> > Matt
> >
>



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


Re: Fwd: [Discuss-gnuradio] Ofdm parameters

2008-02-03 Thread Thomas Rondeau

Jacopo wrote:

Thanks! But where can i check this parameter?

Is it possible that fft_length= occupated carrier (--occupied-tones in 
blksimpl/ofdm.py) + un_used carrier ? Where can i set the position of 
the occupated_bins?


bye


To modify the bandwidth, you have to set the interpolation and 
decimation rates. Yes, fft_length is the size of the FFT or total number 
of subcarriers. Of this, only occupied-tones are used to carry data. The 
unused carriers are distributed evenly on the carriers and you cannot 
modify this behavior in the parameters currently, i.e., we do not 
support non-contiguous OFDM.


Tom



2008/2/2, Matt Ettus <[EMAIL PROTECTED] >:

Jacopo wrote:
> Hello I'm studing an OFDM implementation on gnuradio. I want to
modify
> benchmark_ofdm_tx.py.
>
> I have just read ofdm.py and trasmit_path.py but I can't find how
> change some parameters.
>
> I'd want a bandwith of 20Mhz, where I can set this option? Where
can I
> set the carriers number? And the pilot bins?
>
> Is it possible to set an adaptive modulation for differents carriers?

The USRP hardware is not capable of bandwidths that high.  You are
best
off staying around 6 MHz.

Matt




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


Fwd: [Discuss-gnuradio] Ofdm parameters

2008-02-02 Thread Jacopo
Thanks! But where can i check this parameter?

Is it possible that fft_length= occupated carrier (--occupied-tones in
blksimpl/ofdm.py) + un_used carrier ? Where can i set the position of the
occupated_bins?

bye


2008/2/2, Matt Ettus <[EMAIL PROTECTED]>:
>
> Jacopo wrote:
> > Hello I'm studing an OFDM implementation on gnuradio. I want to modify
> > benchmark_ofdm_tx.py.
> >
> > I have just read ofdm.py and trasmit_path.py but I can't find how
> > change some parameters.
> >
> > I'd want a bandwith of 20Mhz, where I can set this option? Where can I
> > set the carriers number? And the pilot bins?
> >
> > Is it possible to set an adaptive modulation for differents carriers?
>
> The USRP hardware is not capable of bandwidths that high.  You are best
> off staying around 6 MHz.
>
> Matt
>
>


-- 
www.fotofestefirenze.it

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


Re: [Discuss-gnuradio] Ofdm parameters

2008-02-02 Thread Matt Ettus

Jacopo wrote:
Hello I'm studing an OFDM implementation on gnuradio. I want to modify 
benchmark_ofdm_tx.py.


I have just read ofdm.py and trasmit_path.py but I can't find how 
change some parameters.


I'd want a bandwith of 20Mhz, where I can set this option? Where can I 
set the carriers number? And the pilot bins?


Is it possible to set an adaptive modulation for differents carriers?


The USRP hardware is not capable of bandwidths that high.  You are best 
off staying around 6 MHz.


Matt



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


[Discuss-gnuradio] Ofdm parameters

2008-02-01 Thread Jacopo
Hello I'm studing an OFDM implementation on gnuradio. I want to modify
benchmark_ofdm_tx.py.

I have just read ofdm.py and trasmit_path.py but I can't find how change
some parameters.

I'd want a bandwith of 20Mhz, where I can set this option? Where can I set
the carriers number? And the pilot bins?

Is it possible to set an adaptive modulation for differents carriers?

Thanks a lot!

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


[Discuss-gnuradio] OFDM transmit/response recording problems

2007-10-29 Thread Dev Ramudit

Hello all,

	For an experiment I'm working on I need to transmit an OFDM signal from 
one USRP and 'respond' from another USRP with an OFDM message with 
(hopefully) millisecond timing. I've used elements of 
benchmark_ofdm_tx/rx and the tunnel examples to construct the following:


USRP A |USRP B
begin carrier sensing  |
   |
carrier sensed = True  |send 50 pkts
...|...
carrier sensed = False |done sending
send 50 pkts   |receive and wait ~.5 seconds
repeat |repeat

Both USRPs have a TX graph and an RX graph running. The TX path is the 
same as the one in the benchmark_ofdm_tx files. The RX path goes to a 
custom OFDM module which doesnt demod packets, but only provides carrier 
sense. The rx_graph looks something like this:


---
self.rxpath = receive_path(self, callback, options)
self.connect(self.u, self.rxpath)

self.logfile = gr.file_sink(gr.sizeof_short, "/mnt/rd/logfile" +
str(self._usrpnum) + "dat")
self.ctolshort = gr.complex_to_interleaved_short()syn
self.connect(self.u, self.ctolshort, self.logfile)
---

The receive_path goes up to the ofdm_recv.chan_filt, so that the 
gr.probe_avg_mag_sqrd_c can provide carrier sense. I had to cut out the 
demod, as it seemed to slow down each side so much that I'd have an 
abundance of underruns. Right now I just constantly record the data from 
each side to a file, then later run it through a script to demod and 
correlate the timings.


The script above runs OK at a decimation of 12, interpolation of 24 and 
200 occupied tones. I only get one uO every 1 pkts or so, which is 
acceptably low. However, if I run it with -d 10 and -i 20, I get a uO 
every 50 pkts and no usable data.


I've done everything I can to speed up the hard disk side of the 
equation by creating a RAID 0, running on both XFS and EXT2 with the 
fastest options I can find. However, it doesnt seem as if the drive 
writes are the issue. If I remove the file_sink or close the file socket 
while running, I still receive the uOs. I've kept track of both my RAM 
and CPU, but neither are maxing out during the runs, so I dont believe 
that's the problem either.


Basically, I want to run a tx and rx path at the same time on two USRPs, 
with the lowest decimation possible. I need to send from one and respond 
from the other within milliseconds. Any suggestions on how to reduce the 
number of uOs? Or a different approach?


Thanks,
Dev


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


Re: [Discuss-gnuradio] OFDM Benchmark- runtime error

2007-10-01 Thread Eric Blossom
On Mon, Oct 01, 2007 at 10:33:25PM +0200, Sarang Mandke wrote:
> Hello to all the experts!
> I am doing a mini project on GNU Radio using OFDM. Somehow I am getting
> runtime errors when i try to run the benchmark scripts .
> 
> The message i get when trying to run benchmark_ofdm_tx.py is
> 
> [EMAIL PROTECTED]:~/gnuradio/gnuradio-examples/python/ofdm$
> ./benchmark_ofdm_tx.py -f2.4e9 -i200 --tx-ampl=200
> usrp_open_interface:usb_claim_interface: failed interface 1
> could not claim interface 1: Device or resource busy
> usrp_basic_tx: can't open tx interface
> Traceback (most recent call last):
>   File "./benchmark_ofdm_tx.py", line 217, in 
> main()
>   File "./benchmark_ofdm_tx.py", line 190, in main
> fg = usrp_graph(options)
>   File "./benchmark_ofdm_tx.py", line 51, in __init__
> self._setup_usrp_sink()
>   File "./benchmark_ofdm_tx.py", line 66, in _setup_usrp_sink
> fusb_nblocks=self._fusb_nblocks)
>   File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp.py", line
> 212, in __init__
> fpga_filename, firmware_filename)
>   File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line
> 710, in sink_c
> return _usrp1.sink_c(*args)
> RuntimeError: can't open usrp1
> 
> 
> Can anyone suggest some solution to this problem. The USRP board is
> running fine since we tested the oscilloscope script on it

Is the o'scope running at the same time?
Note the message about "Device or resource busy"

Eric


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


[Discuss-gnuradio] OFDM Benchmark- runtime error

2007-10-01 Thread Sarang Mandke
Hello to all the experts!
I am doing a mini project on GNU Radio using OFDM. Somehow I am getting
runtime errors when i try to run the benchmark scripts .

The message i get when trying to run benchmark_ofdm_tx.py is

[EMAIL PROTECTED]:~/gnuradio/gnuradio-examples/python/ofdm$
./benchmark_ofdm_tx.py -f2.4e9 -i200 --tx-ampl=200
usrp_open_interface:usb_claim_interface: failed interface 1
could not claim interface 1: Device or resource busy
usrp_basic_tx: can't open tx interface
Traceback (most recent call last):
  File "./benchmark_ofdm_tx.py", line 217, in 
main()
  File "./benchmark_ofdm_tx.py", line 190, in main
fg = usrp_graph(options)
  File "./benchmark_ofdm_tx.py", line 51, in __init__
self._setup_usrp_sink()
  File "./benchmark_ofdm_tx.py", line 66, in _setup_usrp_sink
fusb_nblocks=self._fusb_nblocks)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp.py", line
212, in __init__
fpga_filename, firmware_filename)
  File "/usr/local/lib/python2.5/site-packages/gnuradio/usrp1.py", line
710, in sink_c
return _usrp1.sink_c(*args)
RuntimeError: can't open usrp1


Can anyone suggest some solution to this problem. The USRP board is
running fine since we tested the oscilloscope script on it
-- 
Posted via http://www.ruby-forum.com/.


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


Re: [Discuss-gnuradio] OFDM GRC block attempt

2007-09-17 Thread Josh Blum
>
> I'm still not entirely sure what the difference between the hier and
> hier2 versions are? Is there anywhere that discusses this? I've checked
> the wiki and the mailing list with no results.
>

The hier blocks were a way to hide a linear chain of blocks inside a
"macro block", and all blocks ultimately reside in one top level flow
graph. However, this method of doing things is being phased out of
gnuradio in favor of the hier2 blocks.

hier2 blocks offer a fully hierarchical approach. A hier2 block can
contain any number of gr blocks and hier2 blocks. These blocks may
connect to any number of input and output ports. A hier2 block is
itself, a flow graph. And the highest level hier2 block is nothing
more than a hier2 block with no IO ports, this is called gr.top_block.

hier2 blocks should offer everything that hier blocks offer, but also,
can do a lot more. The gnuradio trunk is towards the end of switching
from hier to hier2. Currently, both types of blocks work in the
gnuradio trunk, but are incompatible with one another. Also, the blks2
package is still missing some blocks that you would find in blks.

GRC uses the hier2 format, but continued to support the hier blocks
(due to some hackery) until the "incompatible trunk check in". Just
another week or so, and all the GRC blocks should be functional again.

-Josh

> Thanks,
> Dev
>


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


Re: [Discuss-gnuradio] OFDM GRC block attempt

2007-09-17 Thread Dev Ramudit
Josh Blum wrote:
> I reimplemented the packet modulator/demodulator in GRC, and updated the
>  packet_mod_demod.grc.xml example. The packet modulator can be used
> interchangeably with the gmsk, psk, and qam modulators (same for demod).
> 
> See PacketModHelper and PacketDemodHelper in
> http://gnuradio.org/trac/browser/grc/trunk/src/SignalBlockDefs/Packet.py
> 
> Here is a screen shot of the example that may help explain what I was
> talking about, and why:
> http://www.joshknows.com/tmp/packet_mod_demod.grc.xml.png
> 

Thanks! GRC has been a huge help for our development/testing efforts.

> 
> I suppose that until m-blocks come around, these packet blocks in grc
> are the only way a user can actually use a gmsk, psk, or qam de/modulator.
> 
> 
> 
> I will add the ofdm mod/demod, once its hier2 version is merged. The
> ofdm modulator will be implemented in a similar manner: GRC will have a
> ofdm wrapper block that reads from a message source and calls
> ofdm_mod.send_pkt. (I do this so that the output of any block in grc can
> be used with the ofdm_mod block). Again: similar story with ofdm demod.
> 

I'm still not entirely sure what the difference between the hier and
hier2 versions are? Is there anywhere that discusses this? I've checked
the wiki and the mailing list with no results.

Thanks,
Dev


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


Re: [Discuss-gnuradio] OFDM GRC block attempt

2007-09-15 Thread Josh Blum
I reimplemented the packet modulator/demodulator in GRC, and updated the 
 packet_mod_demod.grc.xml example. The packet modulator can be used 
interchangeably with the gmsk, psk, and qam modulators (same for demod).


See PacketModHelper and PacketDemodHelper in 
http://gnuradio.org/trac/browser/grc/trunk/src/SignalBlockDefs/Packet.py


Here is a screen shot of the example that may help explain what I was 
talking about, and why: 
http://www.joshknows.com/tmp/packet_mod_demod.grc.xml.png




I suppose that until m-blocks come around, these packet blocks in grc 
are the only way a user can actually use a gmsk, psk, or qam de/modulator.




I will add the ofdm mod/demod, once its hier2 version is merged. The 
ofdm modulator will be implemented in a similar manner: GRC will have a 
ofdm wrapper block that reads from a message source and calls 
ofdm_mod.send_pkt. (I do this so that the output of any block in grc can 
be used with the ofdm_mod block). Again: similar story with ofdm demod.


-Josh


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


Re: [Discuss-gnuradio] OFDM GRC block attempt

2007-09-15 Thread Johnathan Corgan
Josh Blum wrote:

> Its not quite that. I should explain. The packet modulator block in 
> blks is weird for another reason, it takes another gnuradio block (a
>  modulator) as an argument in the constructor. The problem being that
>  this does not fit into GRC too well.

OFDM is itself a modulation format, but each of the sub-carriers has
their own channel modulation scheme.  So we have to pass a modulator
into the OFDM block so it knows what to use to map incoming bits into
channel symbols for each sub-carrier.  This isn't weird; it's how OFDM
works.

> However, the "new" blks2 packet modulator has an io signature that 
> requires a byte input and a complex output.

If you are referring to blks2.mod_pkts, it's signature takes no inputs,
and outputs complex baseband.  You send it a payload via send_pkt().

If you are referring to the various digital modulator blocks, like
blks2.dqpsk_mod(...), then these all take a stream of bytes and output
complex baseband.  So the io signature you describe is the correct one.

> I think it is best to just make my own packet modulator block that 
> uses the code from the blks2.
> 
> This implementation of the packet modulator will take a data stream 
> (of any type), read data from a message sink, packetize, write data 
> to a message source. Then, a modulator (like dpsk) could be connected
>  to the output of this packet modulator using top_block.connect.

This would work, to take an arbitrary data stream and break it up into
packets for transmission. But...

> Maybe it would be useful to have a packet modulator/demodulator that
> fits into the typical gnuradio block model?

The "typical gnuradio block model" is that of a stream-based data flow,
with no boundaries.  Digital packet data has boundaries by definition.
Up until now we deal with this by turning specific lengths of bytes in a
stream into a "message" that gets sent to the packetizer, which then
formats the header, CRC, whitening, FEC (future), etc.

> Also, I was under the impression that the mblocks will eventually
> implement this kind of functionality (packets, error encoding,
> recovery..).

Yes.  The message block (m-block) data model is passing defined lengths
of data between I/O ports in a flow graph of blocks.  It was entirely
motivated by this more natural method of dealing with packet data and
meta-data.

So, once the m-block infrastructure is more mature, we'll be able to
re-write all the packet handling code in such a way that the
modulation/demodulation functions occur in the gr-block data flow model
and the packet handling, MAC layer, etc., occur in the m-block world.

Conceptually, a digital modulator will be a hybrid block that accepts
raw frame data as m-block messages and outputs a complex baseband data
stream.  A digital demodulator will accept a complex baseband data
stream and emit m-block messages containing raw frame data.  This is
very similar to the existing blocks except today we use gr_message's
instead of m-block messages.

The basic m-block code and infrastructure is in the trunk, but it is
undocumented and incomplete.  If you look through the QA code you can
see how to create your own m-blocks and wire them up much in the same
way you do with gr-blocks.

As an aside, the "in-band signaling" feature that is slated for release
3.2 depends upon m-block code, so you'll see it in use then.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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


Re: [Discuss-gnuradio] OFDM GRC block attempt

2007-09-14 Thread Josh Blum
Its not quite that. I should explain. The packet modulator block in blks 
is weird for another reason, it takes another gnuradio block (a 
modulator) as an argument in the constructor. The problem being that 
this does not fit into GRC too well.


My "old" solution was to feed the constructor a dummy block (just to 
forward data). And then, to connect the actual modulator block to the 
output of the packet modulator. Something like: gr data stream -> 
message sink -> packet modulator w/ dummy (byte out) -> dpsk_mod 
(complex out) -> data sink


However, the "new" blks2 packet modulator has an io signature that 
requires a byte input and a complex output. The io signature will not 
allow a dummy block (one that just forwards data) because the data types 
will not match. I think it is best to just make my own packet modulator 
block that uses the code from the blks2.


This implementation of the packet modulator will take a data stream (of 
any type), read data from a message sink, packetize, write data to a 
message source. Then, a modulator (like dpsk) could be connected to the 
output of this packet modulator using top_block.connect.


...Similar story for the packet demodulator.

Maybe it would be useful to have a packet modulator/demodulator that 
fits into the typical gnuradio block model? Also, I was under the 
impression that the mblocks will eventually implement this kind of 
functionality (packets, error encoding, recovery..).


Thoughts?

-Josh

[EMAIL PROTECTED] wrote:

The conversion of all the example code and blks code on the trunk to the new 
3.1 flow graph code is nearly complete.

This is being done in the jcorgan/t162 developer branch if you want to take a 
look.

Once this is merged into the trunk, you'll be able to restore GRC functionality.

Sent via BlackBerry by AT&T

-Original Message-
From: Josh Blum <[EMAIL PROTECTED]>

Date: Fri, 14 Sep 2007 20:34:40 
To:Dev Ramudit <[EMAIL PROTECTED]>

Cc:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] OFDM GRC block attempt


In short, the GRC code for the packet modulator was no good after the 
"incompatible trunk check in". So, I just deleted the packet mod/demod 
code in GRC.


To restore the functionality of the packet mod/demod (in grc), i would 
have to cannibalize the current blks.pkt code. I will be glad to do 
this, especially if someone is using the blocks.


The only thing about the packet mod/demod blocks is that they are 
implemented poorly. For example, to implement a packet modulation block, 
you have to sample the gnuradio stream with a message sink and a thread, 
the error coding/packetizing is done in python with packet utils, and 
then the data is pushed back into the gnuradio stream with a message 
source. Not too efficient. Any suggestions before I go ahead with the 
message source/sink idea?


Anyway, it would be great to get ofdm working with GRC.

-Josh



Dev Ramudit wrote:

Hello all,

I'm trying to write an OFDM mod/demod for the gnuradio companion and
I'm running into a problem. I'm following the (now deprecated?) packet
modulator code that was in GRC very closely. I have an OFDMDemod block
which creates the following class when its used:

---

class OFDMDemodHelper(gr.hier_block2):
"""Forward data from ofdm demod to the gr data stream."""
def __init__(self, item_size, options):
#create hier block
gr.hier_block2.__init__(
self, 'ofdm_demod',
gr.io_signature(1, 1, Complex().get_num_bytes()),
gr.io_signature(1, 1, item_size)
)
#the message source (handles the output data stream)
msg_source = gr.message_source(item_size, DEFAULT_QUEUE_LIMIT)
msgq = msg_source.msgq()
def callback(ok, payload):
if ok: msgq.insert_tail(gr.message_from_string(payload, 
0, item_size,
len(payload)/item_size))
ofdm_demod = blks.ofdm_demod(
fg=self,
options=options,
callback=callback,
)
#connections
self.connect(msg_source, self)
self.connect(self, ofdm_demod.head)

---

This is basically the same as the old packet demod code, with a few
small changes for OFDM. Unfortunately, I get the following error:

---

 File "/home/dramudit/work/gnuradio/grc/src/SignalBlockDefs/Packet.py",
line 337, in __init__
callback=callback,
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm.py", line
218, in __init__
options.log)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm_receiver.py",
line 56, in __init__
self.fg.connect(self.chan_filt, self.ofdm_sync)
  File
"

Re: [Discuss-gnuradio] OFDM GRC block attempt

2007-09-14 Thread jcorgan
The conversion of all the example code and blks code on the trunk to the new 
3.1 flow graph code is nearly complete.

This is being done in the jcorgan/t162 developer branch if you want to take a 
look.

Once this is merged into the trunk, you'll be able to restore GRC functionality.

Sent via BlackBerry by AT&T

-Original Message-
From: Josh Blum <[EMAIL PROTECTED]>

Date: Fri, 14 Sep 2007 20:34:40 
To:Dev Ramudit <[EMAIL PROTECTED]>
Cc:discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] OFDM GRC block attempt


In short, the GRC code for the packet modulator was no good after the 
"incompatible trunk check in". So, I just deleted the packet mod/demod 
code in GRC.

To restore the functionality of the packet mod/demod (in grc), i would 
have to cannibalize the current blks.pkt code. I will be glad to do 
this, especially if someone is using the blocks.

The only thing about the packet mod/demod blocks is that they are 
implemented poorly. For example, to implement a packet modulation block, 
you have to sample the gnuradio stream with a message sink and a thread, 
the error coding/packetizing is done in python with packet utils, and 
then the data is pushed back into the gnuradio stream with a message 
source. Not too efficient. Any suggestions before I go ahead with the 
message source/sink idea?

Anyway, it would be great to get ofdm working with GRC.

-Josh



Dev Ramudit wrote:
> Hello all,
> 
>   I'm trying to write an OFDM mod/demod for the gnuradio companion and
> I'm running into a problem. I'm following the (now deprecated?) packet
> modulator code that was in GRC very closely. I have an OFDMDemod block
> which creates the following class when its used:
> 
> ---
> 
> class OFDMDemodHelper(gr.hier_block2):
>   """Forward data from ofdm demod to the gr data stream."""
>   def __init__(self, item_size, options):
>   #create hier block
>   gr.hier_block2.__init__(
>   self, 'ofdm_demod',
>   gr.io_signature(1, 1, Complex().get_num_bytes()),
>   gr.io_signature(1, 1, item_size)
>   )
>   #the message source (handles the output data stream)
>   msg_source = gr.message_source(item_size, DEFAULT_QUEUE_LIMIT)
>   msgq = msg_source.msgq()
>   def callback(ok, payload):
>   if ok: msgq.insert_tail(gr.message_from_string(payload, 
> 0, item_size,
> len(payload)/item_size))
>   ofdm_demod = blks.ofdm_demod(
>   fg=self,
>   options=options,
>   callback=callback,
>   )
>   #connections
>   self.connect(msg_source, self)
>   self.connect(self, ofdm_demod.head)
> 
> ---
> 
> This is basically the same as the old packet demod code, with a few
> small changes for OFDM. Unfortunately, I get the following error:
> 
> ---
> 
>  File "/home/dramudit/work/gnuradio/grc/src/SignalBlockDefs/Packet.py",
> line 337, in __init__
> callback=callback,
>   File
> "/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm.py", line
> 218, in __init__
> options.log)
>   File
> "/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm_receiver.py",
> line 56, in __init__
> self.fg.connect(self.chan_filt, self.ofdm_sync)
>   File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
> line 46, in connect
> self._connect(points[i-1], points[i])
>   File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
> line 50, in _connect
> (dst_block, dst_port) = self._coerce_endpoint(dst)
>   File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
> line 61, in _coerce_endpoint
> raise ValueError("unable to coerce endpoint")
> ValueError: unable to coerce endpoint
> 
> ---
> 
> Any suggestions as far as fixing this error, or another approach?
> 
> Thanks,
> Dev
> 
> 
> ___
> 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] OFDM GRC block attempt

2007-09-14 Thread Josh Blum
In short, the GRC code for the packet modulator was no good after the 
"incompatible trunk check in". So, I just deleted the packet mod/demod 
code in GRC.


To restore the functionality of the packet mod/demod (in grc), i would 
have to cannibalize the current blks.pkt code. I will be glad to do 
this, especially if someone is using the blocks.


The only thing about the packet mod/demod blocks is that they are 
implemented poorly. For example, to implement a packet modulation block, 
you have to sample the gnuradio stream with a message sink and a thread, 
the error coding/packetizing is done in python with packet utils, and 
then the data is pushed back into the gnuradio stream with a message 
source. Not too efficient. Any suggestions before I go ahead with the 
message source/sink idea?


Anyway, it would be great to get ofdm working with GRC.

-Josh



Dev Ramudit wrote:

Hello all,

I'm trying to write an OFDM mod/demod for the gnuradio companion and
I'm running into a problem. I'm following the (now deprecated?) packet
modulator code that was in GRC very closely. I have an OFDMDemod block
which creates the following class when its used:

---

class OFDMDemodHelper(gr.hier_block2):
"""Forward data from ofdm demod to the gr data stream."""
def __init__(self, item_size, options):
#create hier block
gr.hier_block2.__init__(
self, 'ofdm_demod',
gr.io_signature(1, 1, Complex().get_num_bytes()),
gr.io_signature(1, 1, item_size)
)
#the message source (handles the output data stream)
msg_source = gr.message_source(item_size, DEFAULT_QUEUE_LIMIT)
msgq = msg_source.msgq()
def callback(ok, payload):
if ok: msgq.insert_tail(gr.message_from_string(payload, 
0, item_size,
len(payload)/item_size))
ofdm_demod = blks.ofdm_demod(
fg=self,
options=options,
callback=callback,
)
#connections
self.connect(msg_source, self)
self.connect(self, ofdm_demod.head)

---

This is basically the same as the old packet demod code, with a few
small changes for OFDM. Unfortunately, I get the following error:

---

 File "/home/dramudit/work/gnuradio/grc/src/SignalBlockDefs/Packet.py",
line 337, in __init__
callback=callback,
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm.py", line
218, in __init__
options.log)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm_receiver.py",
line 56, in __init__
self.fg.connect(self.chan_filt, self.ofdm_sync)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
line 46, in connect
self._connect(points[i-1], points[i])
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
line 50, in _connect
(dst_block, dst_port) = self._coerce_endpoint(dst)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
line 61, in _coerce_endpoint
raise ValueError("unable to coerce endpoint")
ValueError: unable to coerce endpoint

---

Any suggestions as far as fixing this error, or another approach?

Thanks,
Dev


___
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] OFDM GRC block attempt

2007-09-14 Thread Dev Ramudit
Hello all,

I'm trying to write an OFDM mod/demod for the gnuradio companion and
I'm running into a problem. I'm following the (now deprecated?) packet
modulator code that was in GRC very closely. I have an OFDMDemod block
which creates the following class when its used:

---

class OFDMDemodHelper(gr.hier_block2):
"""Forward data from ofdm demod to the gr data stream."""
def __init__(self, item_size, options):
#create hier block
gr.hier_block2.__init__(
self, 'ofdm_demod',
gr.io_signature(1, 1, Complex().get_num_bytes()),
gr.io_signature(1, 1, item_size)
)
#the message source (handles the output data stream)
msg_source = gr.message_source(item_size, DEFAULT_QUEUE_LIMIT)
msgq = msg_source.msgq()
def callback(ok, payload):
if ok: msgq.insert_tail(gr.message_from_string(payload, 
0, item_size,
len(payload)/item_size))
ofdm_demod = blks.ofdm_demod(
fg=self,
options=options,
callback=callback,
)
#connections
self.connect(msg_source, self)
self.connect(self, ofdm_demod.head)

---

This is basically the same as the old packet demod code, with a few
small changes for OFDM. Unfortunately, I get the following error:

---

 File "/home/dramudit/work/gnuradio/grc/src/SignalBlockDefs/Packet.py",
line 337, in __init__
callback=callback,
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm.py", line
218, in __init__
options.log)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm_receiver.py",
line 56, in __init__
self.fg.connect(self.chan_filt, self.ofdm_sync)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
line 46, in connect
self._connect(points[i-1], points[i])
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
line 50, in _connect
(dst_block, dst_port) = self._coerce_endpoint(dst)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/hier_block2.py",
line 61, in _coerce_endpoint
raise ValueError("unable to coerce endpoint")
ValueError: unable to coerce endpoint

---

Any suggestions as far as fixing this error, or another approach?

Thanks,
Dev


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


Re: [Discuss-gnuradio] OFDM update

2007-08-05 Thread Eric Blossom
On Sat, Aug 04, 2007 at 01:01:21PM -0400, Robert McGwier wrote:
> All resolvable with in-band signaling and RSSI with feedback to agc 
> hardware and software.
> 
> I know, I know, I am a broken record.
> 
> Bob

Hi Bob!

Good to hear that you're still out there ;)

Eric

> Tom Rondeau wrote:
> >Matt and I have had a bit of a chance to work out some kinks in the OFDM
> >world. My latest merge should allow people to operate over the air ok.
> >The problem turns out to be false correlations when using the BasicRX
> >boards because with the low gain, the noise only toggles the last 1 or 2
> >LSBs, which correlate nicely and caused the assertions down the chain.
> >The new version avoids that issue as well as provides better default
> >parameters to run over the air.
> >
> >I recommend testing this on an RFX board and not a BasicRX/TX. Also,
> >adjust the --tx-amplitude option on the command line for performance.
> >It's set low still (200) as opposed to 1. This should be fine for a
> >couple of feet. Watch going too high with the amplitude because of
> >clipping. I think 4000 was about the max we saw with an RFX400, but
> >between 1000 and 2000 should work nicely for in-house tests.
> >
> >I also set the default packet size to 400, down from 1450 bytes. We have
> >not implemented frequency/phase tracking throughout the packet, just on
> >the preambles, so rotation throughout the packet can cause high packet
> >loss with long packets.
> >
> >I think this current version provides a usable base for people to play
> >with, though it's by no means perfect. However, I've got to bury myself
> >in my dissertation, so I won't doing any more work on it for a couple of
> >months.
> >
> >Tom


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


Re: [Discuss-gnuradio] OFDM update

2007-08-04 Thread Robert McGwier
All resolvable with in-band signaling and RSSI with feedback to agc 
hardware and software.


I know, I know, I am a broken record.

Bob



Tom Rondeau wrote:

Matt and I have had a bit of a chance to work out some kinks in the OFDM
world. My latest merge should allow people to operate over the air ok.
The problem turns out to be false correlations when using the BasicRX
boards because with the low gain, the noise only toggles the last 1 or 2
LSBs, which correlate nicely and caused the assertions down the chain.
The new version avoids that issue as well as provides better default
parameters to run over the air.

I recommend testing this on an RFX board and not a BasicRX/TX. Also,
adjust the --tx-amplitude option on the command line for performance.
It's set low still (200) as opposed to 1. This should be fine for a
couple of feet. Watch going too high with the amplitude because of
clipping. I think 4000 was about the max we saw with an RFX400, but
between 1000 and 2000 should work nicely for in-house tests.

I also set the default packet size to 400, down from 1450 bytes. We have
not implemented frequency/phase tracking throughout the packet, just on
the preambles, so rotation throughout the packet can cause high packet
loss with long packets.

I think this current version provides a usable base for people to play
with, though it's by no means perfect. However, I've got to bury myself
in my dissertation, so I won't doing any more work on it for a couple of
months.

Tom



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




--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"If you're going to be crazy, you have to get paid for it or
else you're going to be locked up." Hunter S. Thompson


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


[Discuss-gnuradio] OFDM update

2007-08-04 Thread Tom Rondeau
Matt and I have had a bit of a chance to work out some kinks in the OFDM
world. My latest merge should allow people to operate over the air ok.
The problem turns out to be false correlations when using the BasicRX
boards because with the low gain, the noise only toggles the last 1 or 2
LSBs, which correlate nicely and caused the assertions down the chain.
The new version avoids that issue as well as provides better default
parameters to run over the air.

I recommend testing this on an RFX board and not a BasicRX/TX. Also,
adjust the --tx-amplitude option on the command line for performance.
It's set low still (200) as opposed to 1. This should be fine for a
couple of feet. Watch going too high with the amplitude because of
clipping. I think 4000 was about the max we saw with an RFX400, but
between 1000 and 2000 should work nicely for in-house tests.

I also set the default packet size to 400, down from 1450 bytes. We have
not implemented frequency/phase tracking throughout the packet, just on
the preambles, so rotation throughout the packet can cause high packet
loss with long packets.

I think this current version provides a usable base for people to play
with, though it's by no means perfect. However, I've got to bury myself
in my dissertation, so I won't doing any more work on it for a couple of
months.

Tom



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


[Discuss-gnuradio] OFDM and regenerate block

2007-07-15 Thread Tom Rondeau
I just checked in a fix for the regenerate block. It's possible this was
the cause of some of the assertions people were seeing when running the
receiver. Could someone who was seeing that problem would check out the
latest revision and see if it's still a problem?

Thanks,
Tom



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


Re: [Discuss-gnuradio] OFDM implementation

2007-06-15 Thread Tom Rondeau

Brett Trotter wrote:

Tom Rondeau wrote:
  
Just the status report from the work done the past couple of weeks on 
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully 
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I 
have merged the code into the trunk so others can use it, though I 
currently restricted the subcarrier modulations to use only BPSK or QPSK 
(M-QAM will be coming soon I hope). It's not complete; specificially, it 
lacks an adaptive equalizer over the entire packet and channel coding. 
Other features should be coming over time, too.


If you're interested, and for the good of the community, I have posted 
the presentation I gave last week to the [EMAIL PROTECTED] Symposium about the 
implementation details of the system. This includes the block-diagram 
representations of the flow graphs for the transmitter, receiver, and, 
most importantly, the synchronizers used in the system. I have made it 
available in both PPT and PDF format (the PPT opens just fine in the 
latest version of Open Office for those without MS Office). You can find 
it under the Presentations link on the front page of Trac (Johnathan, 
Eric, if you have a better place to put this kind of information, let me 
know; this seemed like a good place to start).


Tom


I seem to be having trouble- I've tried the usual suspects for arguments but
get

[EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py -f 13M -s 300 -i 200 -M 1
Traceback (most recent call last):
  File "./benchmark_ofdm_tx.py", line 217, in ?
main()
  File "./benchmark_ofdm_tx.py", line 190, in main
fg = usrp_graph(options)
  File "./benchmark_ofdm_tx.py", line 56, in __init__
self.txpath = transmit_path(self, options)
  File
"/root/gnuradio-normal/gnuradio-examples/python/ofdm/transmit_path.py", line
44, in __init__
self.ofdm_tx = \
  File "/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm.py",
line 88, in __init__
self._pkt_input = gr.ofdm_bpsk_mapper(msgq_limit,
options.occupied_tones, options.fft_length)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_general.py",
line 7060, in ofdm_bpsk_mapper
return _gnuradio_swig_py_general.ofdm_bpsk_mapper(*args)
TypeError: ofdm_bpsk_mapper expected 5 arguments, got 3

What options does it really need?

even if i go nuts and specify nearly everything with defaults
./benchmark_ofdm_tx.py -f 13M -s 300 -i 200 -M 1 --tx-amplitude=12000 -m
bpsk --fft-length=512 --occupied-tones=200 --cp-length=128

I still get the same 'got 3'

What'd I miss?
  


It's a SWIG problem. You'll probably need to clean out your 
gnuradio-core/src/lib/swig directory (make distclean inside it works and 
prevents you from having to build the whole thing again).


We switched the interface by handling the insertion of known symbols in 
another block, so we went from 5 inputs to 3. Try again after cleaning 
up the SWIG files and reinstalling.


Tom




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


Re: [Discuss-gnuradio] OFDM implementation

2007-06-14 Thread Brett Trotter



Tom Rondeau wrote:
> 
> Just the status report from the work done the past couple of weeks on 
> OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully 
> transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I 
> have merged the code into the trunk so others can use it, though I 
> currently restricted the subcarrier modulations to use only BPSK or QPSK 
> (M-QAM will be coming soon I hope). It's not complete; specificially, it 
> lacks an adaptive equalizer over the entire packet and channel coding. 
> Other features should be coming over time, too.
> 
> If you're interested, and for the good of the community, I have posted 
> the presentation I gave last week to the [EMAIL PROTECTED] Symposium about 
> the 
> implementation details of the system. This includes the block-diagram 
> representations of the flow graphs for the transmitter, receiver, and, 
> most importantly, the synchronizers used in the system. I have made it 
> available in both PPT and PDF format (the PPT opens just fine in the 
> latest version of Open Office for those without MS Office). You can find 
> it under the Presentations link on the front page of Trac (Johnathan, 
> Eric, if you have a better place to put this kind of information, let me 
> know; this seemed like a good place to start).
> 
> Tom
> 
> 

I seem to be having trouble- I've tried the usual suspects for arguments but
get

[EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py -f 13M -s 300 -i 200 -M 1
Traceback (most recent call last):
  File "./benchmark_ofdm_tx.py", line 217, in ?
main()
  File "./benchmark_ofdm_tx.py", line 190, in main
fg = usrp_graph(options)
  File "./benchmark_ofdm_tx.py", line 56, in __init__
self.txpath = transmit_path(self, options)
  File
"/root/gnuradio-normal/gnuradio-examples/python/ofdm/transmit_path.py", line
44, in __init__
self.ofdm_tx = \
  File "/usr/local/lib/python2.4/site-packages/gnuradio/blksimpl/ofdm.py",
line 88, in __init__
self._pkt_input = gr.ofdm_bpsk_mapper(msgq_limit,
options.occupied_tones, options.fft_length)
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_py_general.py",
line 7060, in ofdm_bpsk_mapper
return _gnuradio_swig_py_general.ofdm_bpsk_mapper(*args)
TypeError: ofdm_bpsk_mapper expected 5 arguments, got 3

What options does it really need?

even if i go nuts and specify nearly everything with defaults
./benchmark_ofdm_tx.py -f 13M -s 300 -i 200 -M 1 --tx-amplitude=12000 -m
bpsk --fft-length=512 --occupied-tones=200 --cp-length=128

I still get the same 'got 3'

What'd I miss?
-- 
View this message in context: 
http://www.nabble.com/OFDM-implementation-tf3917154.html#a11130078
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] OFDM implementation

2007-06-14 Thread Tom Rondeau

Martin Dvh wrote:

Tom Rondeau wrote:
  

Just the status report from the work done the past couple of weeks on
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM.
I have merged the code into the trunk so others can use it, though I
currently restricted the subcarrier modulations to use only BPSK or QPSK
(M-QAM will be coming soon I hope).



Is the not-completed QAM code in one of the developer branches (which one)
Maybe I can do some work at it as soon as I get to work on OFDM.
(I am now working on optimizing the wfm_rcv_pll code, my goal is a factor 4 
improvement)


It's actually in the trunk, it's just hidden from the benchmark code. 
For the modulator, we have built a few different versions called 
"gr_ofdm_bpsk_mapper" and "gr_ofdm_qpsk_mapper." There is also 
"gr_ofdm_qam_mapper" that's kind of in shambles to force QAM16. I'd much 
rather get rid of these and make one "gr_ofdm_mapper"  or 
"gr_ofdm_vector_mapper" function that receives a vector of constellation 
points as an argument. Then we can just use qam.py and psk.py to 
generate the constellation in Python and pass it to the mapper function 
that simply takes log2(len(constellation)) number of bits in at a time 
and maps them to constellation points. The only real trick is to handle 
residual bits on byte boundary (8PSK, 8QAM, etc.). We'll then have to 
have a corresponding demapper on the receiver.


Just a heads-up, I'm moving to Ireland over the next week and leaving my 
computer behind, so I'll be pretty much unavailable for about a week and 
a half to two weeks as I settle in over there (and get my new computer). 
The work on this is pretty trivial, but I won't be able to touch it for 
a while, so if you feel like working on it, great!


Tom



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


Re: [Discuss-gnuradio] OFDM implementation

2007-06-13 Thread ismail_itee_uq

I've checked out the latest version (5772) and tried running the
benchmark_ofdm files.  The benchmark_ofdm.py and ofdm_benchmark_tx.py seem
to be working.  But when I use the benchmark_ofdm_rx.py I get the following
error:

python: gr_ofdm_correlator.cc:105: gr_complex
gr_ofdm_correlator::coarse_freq_comp(int, int): Assertion `symbol_count <=
1000' failed.
Aborted (core dumped)


Currently I'm using two USRPs on one PC and tried transmitting across the
air. (I modified the benchmark_rx with 'which=1').  I ran the scripts as
follows:
./benchmark_ofdm_rx.py -f2.45e9 -d100
./benchmark_ofdm_tx.py -f2.45e9 -i200 --tx-ampl=200

I hope you can give me some pointers to solve this.

-Ismail
-- 
View this message in context: 
http://www.nabble.com/OFDM-implementation-tf3917154.html#a4206
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] OFDM implementation

2007-06-13 Thread Martin Dvh
Tom Rondeau wrote:
> Just the status report from the work done the past couple of weeks on
> OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully
> transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM.
> I have merged the code into the trunk so others can use it, though I
> currently restricted the subcarrier modulations to use only BPSK or QPSK
> (M-QAM will be coming soon I hope).

Is the not-completed QAM code in one of the developer branches (which one)
Maybe I can do some work at it as soon as I get to work on OFDM.
(I am now working on optimizing the wfm_rcv_pll code, my goal is a factor 4 
improvement)

> If you're interested, and for the good of the community, I have posted
> the presentation I gave last week to the [EMAIL PROTECTED] Symposium about the
> implementation details of the system. ..You can find
> it under the Presentations link on the front page of Trac
Thanks for this.

Martin
> 
> Tom
> 
> 
> 
> ___
> 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] OFDM implementation

2007-06-13 Thread Tom Rondeau
Just the status report from the work done the past couple of weeks on 
OFDM. With Matt Ettus, Bob McGwier, and Eric Blossom, we successfully 
transmitted and received OFDM over the air with BPSK, QPSK, and 16QAM. I 
have merged the code into the trunk so others can use it, though I 
currently restricted the subcarrier modulations to use only BPSK or QPSK 
(M-QAM will be coming soon I hope). It's not complete; specificially, it 
lacks an adaptive equalizer over the entire packet and channel coding. 
Other features should be coming over time, too.


If you're interested, and for the good of the community, I have posted 
the presentation I gave last week to the [EMAIL PROTECTED] Symposium about the 
implementation details of the system. This includes the block-diagram 
representations of the flow graphs for the transmitter, receiver, and, 
most importantly, the synchronizers used in the system. I have made it 
available in both PPT and PDF format (the PPT opens just fine in the 
latest version of Open Office for those without MS Office). You can find 
it under the Presentations link on the front page of Trac (Johnathan, 
Eric, if you have a better place to put this kind of information, let me 
know; this seemed like a good place to start).


Tom



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


Re: [Discuss-gnuradio] OFDM status

2007-03-07 Thread Dominik Auras
Hi!

> I kicked the can down the road with Matt Ettus and Tom Rondeau.  We have 
> spent two weeks on this total and others are welcome to contribute.  We 
> need to have the argument: How do we specify the constellations? How do 
> we map carrier usage (which are pilots, clocks, etc.)?

To open a discussion on that topic, here is my first proposition:

We create a generic OFDM mapper block. It should treat every occupied
carrier as a proper channel. I think of something like:

gr_make_io_signature (nchannels, nchannels, sizeof(unsigned char))

The input streams are unpacked bytes, containing 1 to 8 bits. In front
of the mapper, connect several packed_to_unpacked blocks and some
stream_to_streams. A parameter to the mapper block is a channel list
that assigns a modulation type to every subchannel.

The mapper's task is, in this model, to map chunks to symbols
independently for each subchannel. Additionally, it periodically outputs
known symbols that help synchronisation in the receiver(s).

Maybe a new packed_to_unpacked block can be created that fulfills two
tasks; to unpack and to split the input. I think of a block taking a
packed byte stream as input and outputting several unpacked byte streams
with different pack-sizes per output stream.

In the receiver, we do the inverse thing. Information exchange
transmitter <-> receiver could be done through a network (for a testing
platform).

By this, we can benefit of the OFDM's main advantage - to use the
optimal modulation to every subchannel. In the background, there can be
a control application that evaluates SNRs, receives them from the
clients (for first try: through network) and assigns modulation etc.

We can also insert pilot channels - simply connect a "pilot block" to a
subchannel input. This may help on synchronization and channel
estimation.

And it allows a new use case: 1 to N transmission, with one transmitter
and several receivers.

This system will allow to evaluate new algorithms for subcarrier
assignment, channel estimation, synchronization etc.

Greetings,
Dominik




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


Re: [Discuss-gnuradio] OFDM status

2007-03-07 Thread Robert McGwier

http://www.gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy

is the trac and


svn co http://gnuradio.org/svn/gnuradio/branches/developers/n4hy/ofdm

gets you the source.  I am merging the trunk into this about every 50 
revisions unless I see major progress on mblock,  usrp,  etc that is of 
immediate relevance.  Once we get a single instance running on hardware 
and over the air with some speed and reliability,  I will suggest that 
we be allowed to merge this into the trunk and we can all play.



I kicked the can down the road with Matt Ettus and Tom Rondeau.  We have 
spent two weeks on this total and others are welcome to contribute.  We 
need to have the argument: How do we specify the constellations? How do 
we map carrier usage (which are pilots, clocks, etc.)?


In order to be really credible,  we need mblock and we need the part 
that is running on the usrp because we need RSSI, it needs to be inband 
so we can do the gain management that is imperative for OFDM to work 
with its crest factor issues.




Bob



Kuntal Majumdar wrote:

Hello,

Who is doing the OFDM project? May I get some info on that, because my 
thesis project is on the same and  I would love help in this regard.


Thanks a lot.

Regards,
Kuntal


No need to miss a message. Get email on-the-go 

with Yahoo! Mail for Mobile. Get started. 






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



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine


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


Re: [Discuss-gnuradio] OFDM status

2007-03-07 Thread Kuntal Majumdar
Hello,

Who is doing the OFDM project? May I get some info on that, because my thesis 
project is on the same and  I would love help in this regard.

Thanks a lot. 

Regards,
Kuntal




 

Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] OFDM status

2007-03-07 Thread Brett L. Trotter
What is the current status of the OFDM project? Is it such that I could
give it a try using a tunnel.py type setup over a shared wireline - or
at least over two separate RX/TX wires?

Last I heard the receiver and transmitter were working but not over the air.


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


RE: [Discuss-gnuradio] OFDM - on air?

2007-02-28 Thread Dominik Auras
Hi!

Just curious on the channel transfer function, I did some modification
on the ofdm simulation to see the magnitude and the argument. I am
inverting your equalizer coefficients (and actually scaling them down).
The coefficients of the region of interest in frequency domain are sent
out through a new vector stream.

In order to have it visual, the simulation script now is a class derived
from stdgui.

Maybe you are interested in that, e.g. for some demo purposes. I
attached a patch.

Dominik


ofdm_gui.tar.gz
Description: application/compressed-tar
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


RE: [Discuss-gnuradio] OFDM - on air?

2007-02-28 Thread Dominik Auras
Hi!

So there is no obvious fault, e.g. that I set the wrong
decimation/interpolation rate? (the samplerate should be 400kS/s?)

I just compared "tx_ofdm.dat", recorded in your simulation, to my
recorded file. Therefore I modified usrp_fft.py. In tx_ofdm.dat, it
shows a large frequency band in use, as expected. Unfortunately, my file
does not show the same behavior :-( It looks like gaussian noise with a
small carrier in the middle. Maybe I did not setup correctly the
transmit path.

The first few seconds while recording, there were no signal
transmission. This stage can be recognized in a waterfall diagram. It
seems to me that "the gaussian noise" I saw could be the transmitted
OFDM signal.

> If you want to start playing around with it, benchmark_ofdm.py does a
> loopback simulation with optional AWGN and multipath channels between the Tx
> and Rx blocks. We're hoping to inject some quiet time into this simulation
> to test the signal acquisition capabilities. That is, we know that under
> steady-state conditions we synchronize pretty well, but we don't know the
> transient behavior when we first get s signal into the receiver.
Good work! I studied the simulation for some hours, before I started to
port the sim to use the usrp.

> Yes, we've injected a lot of debug information here, but I thought the code
> checked in had that output turned off. Are you using the newest code (and
> yes, I did just check a few new things in that we didn't do before Matt
> left).
The debug information appear because I turned it on. I am working on the
latest copy.

> Thanks! It's a bit premature still, but I'm sure we'll all be glad for more
> feedback as it comes together.
If you like, I can give you further feedback from time to time.

Dominik




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


RE: [Discuss-gnuradio] OFDM - on air?

2007-02-27 Thread Tom Rondeau

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:discuss-
> [EMAIL PROTECTED] On Behalf Of Dominik Auras
> Sent: Tuesday, February 27, 2007 10:09 AM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] OFDM - on air?
> 
> Hello,
> 
> I'm currently trying to make your ofdm simulation work with two usrp
> rev4. The scripts benchmark_ofdm_tx.py and ...rx.py are modified in
> order to send (I looked on the examples in the directory
> "examples/python/digital/").
> 
> Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two
> Flex2400RF boards used. (Maybe my first faults lay here)

Actually, your first fault was using the code ;) We made a lot of progress
last week, but we still have a ways to go before we get it to work over the
air. OFDM requires a high dynamic range, and clipping can happen easily. We
haven't really analyzed this yet. 

If you want to start playing around with it, benchmark_ofdm.py does a
loopback simulation with optional AWGN and multipath channels between the Tx
and Rx blocks. We're hoping to inject some quiet time into this simulation
to test the signal acquisition capabilities. That is, we know that under
steady-state conditions we synchronize pretty well, but we don't know the
transient behavior when we first get s signal into the receiver.
 
> I also recorded some seconds to a file so I can now replay the same
> scenario.
> 
> The first thing I observe is that the synchronisation needs to know a
> value for the SNR. Fiddling around with that, the synchronizer starts
> the sampler even if no signal present (at high SNR-value), but no
> samples get through it if the value is lower than 8.

Yes. We hope to make that more automatic if we can.
 
> The correlator block thinks to have found the known symbols sometimes in
> the noise. And, very confusing to me, the first ofdm symbol, after the
> correlation found a peak, is always the first known symbol - even in
> absence of a signal.
> 
> The message "found at search delta..." appears very often, compared to
> your simulation.
> It looks like the following lines (I also edited some blocks to output
> debug info):

That's a little disturbing. The search delta should only appear if we
correlate to the known PN sequences. Granted, we didn't do a good job in
creating these two symbols, I still don't think we should often randomly
correlate against noise with 200 symbols.
 
> found at search delta: 1,
> demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
> 9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
> bin 1   h_sqrd = ( 37442.839844, 1714.728149 )   power = 42633.847656
> real(h)/p = 0.878242angle = 0.045764
> 
> This is repeated until I kill the process. There are also other outputs,
> with more "demod out" lines grouped together etc.

Yes, we've injected a lot of debug information here, but I thought the code
checked in had that output turned off. Are you using the newest code (and
yes, I did just check a few new things in that we didn't do before Matt
left).
 
> e.g. the first lines after the gr_buffer warning
> bin 0   h_sqrd = ( 2.125927, 1.626051 )  power = 2.299746
> real(h)/p = 0.924418angle = 0.652948
> found at search delta: 0,
> demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
> 9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
> demod out:   18  3c  8d  b3  e7   9  5b  cf  f4  d6  52  3d  a0  d2  be
> 1a  a8  9c  4a  a7  a1  36  9a  85  19 len: 25
> demod out:   e9  9c  88  d9  c4  93  db  c7  c6  9d  87  49  21  b1  3a
> 40  12  6f  27  30  de  a5  c8  97  f2 len: 25
> demod out:   7f  a5  bb  14  54  b4  84  e5  e9  3f  e9  9d  f5  a5  44
> 54   0  fb   6  21   0  44  49  9f  fa len: 25
> 
> 
> Thank you very much in advance
> You did a great work on gnuradio!!
> Dominik

Thanks! It's a bit premature still, but I'm sure we'll all be glad for more
feedback as it comes together.

Tom




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


[Discuss-gnuradio] OFDM - on air?

2007-02-27 Thread Dominik Auras
Hello,

I'm currently trying to make your ofdm simulation work with two usrp
rev4. The scripts benchmark_ofdm_tx.py and ...rx.py are modified in
order to send (I looked on the examples in the directory
"examples/python/digital/").

Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two
Flex2400RF boards used. (Maybe my first faults lay here)

I also recorded some seconds to a file so I can now replay the same
scenario.

The first thing I observe is that the synchronisation needs to know a
value for the SNR. Fiddling around with that, the synchronizer starts
the sampler even if no signal present (at high SNR-value), but no
samples get through it if the value is lower than 8.

The correlator block thinks to have found the known symbols sometimes in
the noise. And, very confusing to me, the first ofdm symbol, after the
correlation found a peak, is always the first known symbol - even in
absence of a signal.

The message "found at search delta..." appears very often, compared to
your simulation.
It looks like the following lines (I also edited some blocks to output
debug info):

found at search delta: 1,
demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
bin 1   h_sqrd = ( 37442.839844, 1714.728149 )   power = 42633.847656
real(h)/p = 0.878242angle = 0.045764

This is repeated until I kill the process. There are also other outputs,
with more "demod out" lines grouped together etc.

e.g. the first lines after the gr_buffer warning
bin 0   h_sqrd = ( 2.125927, 1.626051 )  power = 2.299746
real(h)/p = 0.924418angle = 0.652948
found at search delta: 0,
demod out:   38  e6  55  d1  21  93  6f  d4  2b  ea  3a  e3  41  4f  d2
9  bf  f9  f5  16  73  45  9c   a  e2 len: 25
demod out:   18  3c  8d  b3  e7   9  5b  cf  f4  d6  52  3d  a0  d2  be
1a  a8  9c  4a  a7  a1  36  9a  85  19 len: 25
demod out:   e9  9c  88  d9  c4  93  db  c7  c6  9d  87  49  21  b1  3a
40  12  6f  27  30  de  a5  c8  97  f2 len: 25
demod out:   7f  a5  bb  14  54  b4  84  e5  e9  3f  e9  9d  f5  a5  44
54   0  fb   6  21   0  44  49  9f  fa len: 25


Thank you very much in advance
You did a great work on gnuradio!!
Dominik





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


Re: [Discuss-gnuradio] OFDM

2007-02-19 Thread Eric Blossom
On Mon, Feb 19, 2007 at 05:13:28PM -0800, Chris Stankevitz wrote:
> Robert McGwier wrote:
> >In the n4hy developers branch,  we spent today adding some new code and 
> 
> Congratulations on the cleanup!
> 
> What is ofdm?  
>

http://en.wikipedia.org/wiki/Orthogonal_frequency-division_multiplexing

> What is n4hy?

Bob's amateur radio call sign.

Eric


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


Re: [Discuss-gnuradio] OFDM

2007-02-19 Thread Chris Stankevitz

Robert McGwier wrote:
In the n4hy developers branch,  we spent today adding some new code and 


Congratulations on the cleanup!

What is ofdm?  What is n4hy?

Chris


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


[Discuss-gnuradio] OFDM

2007-02-19 Thread Robert McGwier
In the n4hy developers branch,  we spent today adding some new code and 
cleaning up a huge mess.  The old temporary mess (ofdm2) is gone and 
ofdm has replaced it.   This was current with the trunk this after and 
has the ofdm code.  We transmitted with this in the lab today.


My apologies for the svn confusion.  We have achieved svn stability and 
are working on code.   This will not be kept current with the trunk now 
until we are done with round one and ready to send and receive data and 
to give a compact description of the signaling to be used on the channel.


Bob

--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine



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


Re: [Discuss-gnuradio] OFDM PHY (802.11) ?

2007-02-18 Thread Eric Blossom
On Fri, Feb 16, 2007 at 09:56:39AM -0500, Brian Padalino wrote:
> On 2/16/07, Tom Rondeau <[EMAIL PROTECTED]> wrote:
> >Our biggest concern will probably be getting the signal to work on the RFX
> >boards, which (I think) all have the same output amplifier stage. What we 
> >do
> >with all of the modulators is scale it from +1 to -1 (even my QAM 
> >modulators
> >are normalized amplitudes), then digitally amplify it to +-16384. When you
> >look at the output power of the transmitter, at full power it only starts 
> >to
> >go non-linear and you can start to see the third-order product (Matt's done
> >a really good job with these guys). At around +-15000, I don't really see
> >anything, so that's about the arbitrary max I use.
> 
> Ah, so you really want to go full scale with this - neat.  I am
> worried about what type of transients you could see if you do some big
> impulse signal with the interpolation that happens when transmitting.
> I suppose your 1.0 normalized signal would really be the number of
> active frequency bins since you could possibly hit a peak at each one
> of those frequencies?  Does that sound right?
> 
> On the scale values - a complex signal going down to the USRP is
> 8-bits real / 8-bits imaginary if I remember correctly.  That should
> give +/-127 for those values.

We almost always use 16-bit I & Q across the USB.


> For a fixed-point model, maybe it would be worth while to choose a Q12
> or Q15 number to be the standard normalized value - therefore any
> bit-slicing done in the FPGA can be reliably done without the fear of
> a loss of data?

Of course you can build an arbitrary width data path in the FPGA...

Eric


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


Re: [Discuss-gnuradio] OFDM PHY (802.11) ?

2007-02-16 Thread Brian Padalino

On 2/16/07, Tom Rondeau <[EMAIL PROTECTED]> wrote:

Our biggest concern will probably be getting the signal to work on the RFX
boards, which (I think) all have the same output amplifier stage. What we do
with all of the modulators is scale it from +1 to -1 (even my QAM modulators
are normalized amplitudes), then digitally amplify it to +-16384. When you
look at the output power of the transmitter, at full power it only starts to
go non-linear and you can start to see the third-order product (Matt's done
a really good job with these guys). At around +-15000, I don't really see
anything, so that's about the arbitrary max I use.


Ah, so you really want to go full scale with this - neat.  I am
worried about what type of transients you could see if you do some big
impulse signal with the interpolation that happens when transmitting.
I suppose your 1.0 normalized signal would really be the number of
active frequency bins since you could possibly hit a peak at each one
of those frequencies?  Does that sound right?

On the scale values - a complex signal going down to the USRP is
8-bits real / 8-bits imaginary if I remember correctly.  That should
give +/-127 for those values.

Assuming a real-only signal, the AD9862 has a dual 14-bit DAC which
gives +/-8191 values.  This probably doesn't mean anything since it
goes through interpolation, but the whole normalization of this stuff
would seem to get quite hairy after a while.

For a fixed-point model, maybe it would be worth while to choose a Q12
or Q15 number to be the standard normalized value - therefore any
bit-slicing done in the FPGA can be reliably done without the fear of
a loss of data?


With the OFDM work, we still send modulate the maximum value to be 1 (for
example, we send a "known symbol" at the start of a frame of all 1's), then
we will digitally amplify it, so there shouldn't be a difference, and we
shouldn't see any problems with the high peak-to-average ratio. I say
shouldn't because I'm an experimentalist and don't like to make concrete
claims until I see it.


You just use the one symbol for a preamble of sorts?  Is that reliable
enough to not false acquire enough to get data through?


Is that what you're looking for?


Very much so.  Thank you very much!

Brian


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


RE: [Discuss-gnuradio] OFDM PHY (802.11) ?

2007-02-16 Thread Tom Rondeau
> -Original Message-
> From: Brian Padalino [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 15, 2007 3:15 PM
> To: Tom Rondeau
> Cc: gnuradio mailing list
> Subject: Re: [Discuss-gnuradio] OFDM PHY (802.11) ?
> 
> On an semi-related note, which of the RF front end cards will work
> with the OFDM waveform?  From my understanding, it has a pretty high
> peak-to-average ratio which might cause some problems with some
> transmitters.

An excellent question (which is academic speak for 'I don't have an
answer').

Hopefully we will know next week. You are right in the high peak-to-average
power, but we have to work a few more issues out before we will know how it
works over the air and through different daughterboards.
 
> How are the floating point numbers calculated on the PC going to be
> normalized into proper scale fixed-point numbers the FPGA works with?

Our biggest concern will probably be getting the signal to work on the RFX
boards, which (I think) all have the same output amplifier stage. What we do
with all of the modulators is scale it from +1 to -1 (even my QAM modulators
are normalized amplitudes), then digitally amplify it to +-16384. When you
look at the output power of the transmitter, at full power it only starts to
go non-linear and you can start to see the third-order product (Matt's done
a really good job with these guys). At around +-15000, I don't really see
anything, so that's about the arbitrary max I use.

With the OFDM work, we still send modulate the maximum value to be 1 (for
example, we send a "known symbol" at the start of a frame of all 1's), then
we will digitally amplify it, so there shouldn't be a difference, and we
shouldn't see any problems with the high peak-to-average ratio. I say
shouldn't because I'm an experimentalist and don't like to make concrete
claims until I see it.

Is that what you're looking for?

Tom


> This is very interesting to me, so I guess I am just a little curious
> how this is going to be done.
> 
> Thanks,
> Brian




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


Re: [Discuss-gnuradio] OFDM

2007-02-15 Thread Robert McGwier
The OFDM work has begun under my (n4hy) branch.  Next week it will 
continue as I travel to Virginia Tech to work with Tom, Matt, and others 
on this and other work.


When we have an OFDM transceiver and can drive one of the Flexible 
boards from Matt on the air,  we will move it into the trunk so we can 
add FEC, interleaving, etc.  easily and learn how Achilleas work needs 
to be optimized (if at all) to be used with this code.


Bob
(ARS  N4HY)

[EMAIL PROTECTED] wrote:

I'm pretty new to gnu radio and I want to transmit an OFDM signal using 
different modulation types (BPSK, QPSK, and 64-QAM).  The concept is pretty 
simple: read data, map it to a specified constellation map, and then send it 
through an IFFT.  I don't know if this code already exists but I could use some 
help.

Nick



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

  



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine



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


Re: [Discuss-gnuradio] OFDM PHY (802.11) ?

2007-02-15 Thread Brian Padalino

On an semi-related note, which of the RF front end cards will work
with the OFDM waveform?  From my understanding, it has a pretty high
peak-to-average ratio which might cause some problems with some
transmitters.

How are the floating point numbers calculated on the PC going to be
normalized into proper scale fixed-point numbers the FPGA works with?

This is very interesting to me, so I guess I am just a little curious
how this is going to be done.

Thanks,
Brian


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


RE: [Discuss-gnuradio] OFDM PHY (802.11) ?

2007-02-15 Thread Tom Rondeau
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:discuss-
> [EMAIL PROTECTED] On Behalf Of Shravan Rayanchu
> Sent: Thursday, February 15, 2007 2:56 PM
> To: gnuradio mailing list
> Subject: [Discuss-gnuradio] OFDM PHY (802.11) ?
> 
> Hi all,
> 
> Is the OFDM implementation (see below) compliant to that of 802.11 ?
> 
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm2/g
> nuradio-examples/python/ofdm
> 
> I am looking for source code which implements 802.11a scrambler,
> convolution encoder etc .. I couldn't find it in the above link. Can
> you please point me to the code if the above implementation has it ?
> In general, is there any open source implementation of the 802.11 OFDM
> PHY ?
> 
> Thank you,
> 
> Shravan


Shravan,

The OFDM code we're working on here is not specific to any standard. It is a
general modulator and demodulator for people to work with (later, once we
get some things worked out) and implement their own specific needs.

And just to point it out again, you're going to have a very difficult time
doing 802.11g in the current state with the bandwidth limitations. If you
are just looking to implement the way 802.11g is done, but not for use with
an actual commercial system, then great; hopefully, this OFDM code will give
you a good place to start.

Tom




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


Re: [Discuss-gnuradio] OFDM PHY (802.11) ?

2007-02-15 Thread Johnathan Corgan
Shravan Rayanchu wrote:

> Is the OFDM implementation (see below) compliant to that of 802.11 ?
> 
> http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm2/gnuradio-examples/python/ofdm

No.  This is a work in progress implementation of a generic,
parameterized OFDM modulator/demodulator.  You'd need to wrap it (once
it is finished) in a number of other blocks to implement an 802.11 PHY.




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


[Discuss-gnuradio] OFDM PHY (802.11) ?

2007-02-15 Thread Shravan Rayanchu

Hi all,

Is the OFDM implementation (see below) compliant to that of 802.11 ?

http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm2/gnuradio-examples/python/ofdm

I am looking for source code which implements 802.11a scrambler,
convolution encoder etc .. I couldn't find it in the above link. Can
you please point me to the code if the above implementation has it ?
In general, is there any open source implementation of the 802.11 OFDM
PHY ?

Thank you,

Shravan


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


Re: [Discuss-gnuradio] OFDM

2007-02-12 Thread Tom Rondeau

Johnathan Corgan wrote:

[EMAIL PROTECTED] wrote:

  

I'm pretty new to gnu radio and I want to transmit an OFDM signal
using different modulation types (BPSK, QPSK, and 64-QAM).  The
concept is pretty simple: read data, map it to a specified
constellation map, and then send it through an IFFT.  I don't know if
this code already exists but I could use some help.



There is work underway in this area to create a parameterized OFDM
modulator/demodulator pair, but it is incomplete and not yet merged into
the trunk.  You can see the code in:

http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm2/gnuradio-examples/python/ofdm

These examples depend on C++ elsewhere in the tree in this developer
branch so they won't run as-is. You can, however, see how the transmit
path is put together.

By the way, you're right--the modulator is the easy part.  It's the
receiver synchronization that always turns out to be the black magic
part. (Why is this always glossed over? :-)

Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


As Johnathan said, we've pretty much got the modulator and demodulator 
done. A few of us will be working next week on pulling it all together 
and finishing the synchronization. With any luck and the alignment of 
the Zodiac (or whatever astrological/mythological concept you want to 
wish on), we'll get this merged into the trunk by the end of next week.


From there, hack away and make improvements.

Tom



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


Re: [Discuss-gnuradio] OFDM

2007-02-12 Thread Johnathan Corgan
[EMAIL PROTECTED] wrote:

> I'm pretty new to gnu radio and I want to transmit an OFDM signal
> using different modulation types (BPSK, QPSK, and 64-QAM).  The
> concept is pretty simple: read data, map it to a specified
> constellation map, and then send it through an IFFT.  I don't know if
> this code already exists but I could use some help.

There is work underway in this area to create a parameterized OFDM
modulator/demodulator pair, but it is incomplete and not yet merged into
the trunk.  You can see the code in:

http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm2/gnuradio-examples/python/ofdm

These examples depend on C++ elsewhere in the tree in this developer
branch so they won't run as-is. You can, however, see how the transmit
path is put together.

By the way, you're right--the modulator is the easy part.  It's the
receiver synchronization that always turns out to be the black magic
part. (Why is this always glossed over? :-)

Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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


[Discuss-gnuradio] OFDM

2007-02-12 Thread njm25
I'm pretty new to gnu radio and I want to transmit an OFDM signal using 
different modulation types (BPSK, QPSK, and 64-QAM).  The concept is pretty 
simple: read data, map it to a specified constellation map, and then send it 
through an IFFT.  I don't know if this code already exists but I could use some 
help.

Nick



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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-28 Thread Tom Rondeau

Robert McGwier wrote:
Like all things in branches, until they are not in branches,  this is 
absolutely development code and here is no guarantee of completeness 
or even correctness.  It is the reason for doing this kind of work in 
branches rather than imposing it on everyone in the trunk.


In the gnuradio-examples/python/ofdm directory, the only functional 
up-to-date file as of this moment is ofdm_benchmark.py.   It does a 
loopback through noise test.


ofdm_benchmark_tx.py calls upon a tx_pick_bitrate  which is missing 
from the single computer where Tom, Matt, and I did the work.  I will 
make sure that this is not an accidental omission that was actually on 
Tom's laptop when he arrives tomorrow.


We are attempting a very difficult thing which requires some delicacy 
and art.  We want to be able to come up with a compact description of 
any kind of constellation,  cyclic prefix size, or complete absence of 
cyclic prefix and then have support for the requirement for sync 
channels of several types.  At the same time,  we have the design goal 
for this to be reasonably efficient and even dynamic.  We have chosen 
not to take the fast road to a single exemplar but to abstract as much 
of this as possible believing this will aid experimentation and serve 
the greatest possible good.


I have been so busy for the last few weeks that all of this slipped 
out of the sieve that is left of my mind ;-).


When Tom and I can get some work done tomorrow, one of the things we 
will be planning is the next big steps in the ofdm tree.  You may 
expect nothing to work until we say it does work.


Bob


A quick look showed that pick_bitrate.py was not checked into the 
repository, this has been corrected. However, I don't think we've ever 
tested running the OFDM modulator with the USRP yet, as the 
benchmark_ofdm_tx.py is meant to do.


The pick_bitrate.py file was copied over the digital examples; it will 
probably be modified in the future for OFDM-specific operation.


To test the OFDM system, we were using a loopback mode using 
benchmark_ofdm.py, which calls upon receive_path_simple and 
transmit_path_simple, which bypass the calls to the USRP and connect 
directly to each other. A checkout and install had this working with no 
issues. You should just be able to run:

   ./benchmark_ofdm.py
With no argument and you'll see a stream of packet info being spit out. 
You can change a lot of the parameters now, including the SNR.


As Bob said, this is development code. We have no synchronization in the 
receiver yet, so this will definitely not work over the air yet.


Tom



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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Robert McGwier
Like all things in branches, until they are not in branches,  this is 
absolutely development code and here is no guarantee of completeness or 
even correctness.  It is the reason for doing this kind of work in 
branches rather than imposing it on everyone in the trunk.


In the gnuradio-examples/python/ofdm directory, the only functional 
up-to-date file as of this moment is ofdm_benchmark.py.   It does a 
loopback through noise test.


ofdm_benchmark_tx.py calls upon a tx_pick_bitrate  which is missing from 
the single computer where Tom, Matt, and I did the work.  I will make 
sure that this is not an accidental omission that was actually on Tom's 
laptop when he arrives tomorrow.


We are attempting a very difficult thing which requires some delicacy 
and art.  We want to be able to come up with a compact description of 
any kind of constellation,  cyclic prefix size, or complete absence of 
cyclic prefix and then have support for the requirement for sync 
channels of several types.  At the same time,  we have the design goal 
for this to be reasonably efficient and even dynamic.  We have chosen 
not to take the fast road to a single exemplar but to abstract as much 
of this as possible believing this will aid experimentation and serve 
the greatest possible good.


I have been so busy for the last few weeks that all of this slipped out 
of the sieve that is left of my mind ;-).


When Tom and I can get some work done tomorrow, one of the things we 
will be planning is the next big steps in the ofdm tree.  You may expect 
nothing to work until we say it does work.


Bob





Eric Blossom wrote:

On Fri, Jan 26, 2007 at 07:22:58PM -0800, Eric Blossom wrote:
  

On Fri, Jan 26, 2007 at 06:25:29PM -0800, Brett Trotter wrote:


I took Dan Halperin's advice and totally deleted my build tree- I also
totally cleaned out all traces of gnuradio and re-checked out everything
from subversion and re-built (n4hy's tree) and am still missing
_gnuradio_swig_python.
  

There is no longer a _gnuradio_swig_python file.  It's not supposed to
be there.  I believe the problem you are seeing is related to stale
swig dependencies left over in the current build tree.

See http://gnuradio.org/trac/ticket/130

Either of these should fix the problem:

(1)
If you start with a fresh checkout -- into an *empty* directory -- I'm
pretty sure that you will not see the message.  By *empty* I mean
*empty*.  That is, no .deps or .libs files, or anything else for
that matter.

(2) 
cd gnuradio-core/src/lib/swig

for file in *.d do; cp /dev/null $file; done
make

Eric



I've given you somewhat incorrect info.

Bob's ofdm tree hasn't been updated with the changes that split
gnuradio_swig_python into 5 pieces.  Thus, there should be an
_gnuradio_swig_python file.

In any event, a checkout into an empty directory worked for me.

Eric


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

  



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine



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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Eric Blossom
On Fri, Jan 26, 2007 at 07:22:58PM -0800, Eric Blossom wrote:
> On Fri, Jan 26, 2007 at 06:25:29PM -0800, Brett Trotter wrote:
> > 
> > I took Dan Halperin's advice and totally deleted my build tree- I also
> > totally cleaned out all traces of gnuradio and re-checked out everything
> > from subversion and re-built (n4hy's tree) and am still missing
> > _gnuradio_swig_python.
> 
> There is no longer a _gnuradio_swig_python file.  It's not supposed to
> be there.  I believe the problem you are seeing is related to stale
> swig dependencies left over in the current build tree.
> 
> See http://gnuradio.org/trac/ticket/130
> 
> Either of these should fix the problem:
> 
> (1)
> If you start with a fresh checkout -- into an *empty* directory -- I'm
> pretty sure that you will not see the message.  By *empty* I mean
> *empty*.  That is, no .deps or .libs files, or anything else for
> that matter.
> 
> (2) 
> cd gnuradio-core/src/lib/swig
> for file in *.d do; cp /dev/null $file; done
> make
> 
> Eric

I've given you somewhat incorrect info.

Bob's ofdm tree hasn't been updated with the changes that split
gnuradio_swig_python into 5 pieces.  Thus, there should be an
_gnuradio_swig_python file.

In any event, a checkout into an empty directory worked for me.

Eric


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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Eric Blossom
On Fri, Jan 26, 2007 at 06:25:29PM -0800, Brett Trotter wrote:
> 
> I took Dan Halperin's advice and totally deleted my build tree- I also
> totally cleaned out all traces of gnuradio and re-checked out everything
> from subversion and re-built (n4hy's tree) and am still missing
> _gnuradio_swig_python.

There is no longer a _gnuradio_swig_python file.  It's not supposed to
be there.  I believe the problem you are seeing is related to stale
swig dependencies left over in the current build tree.

See http://gnuradio.org/trac/ticket/130

Either of these should fix the problem:

(1)
If you start with a fresh checkout -- into an *empty* directory -- I'm
pretty sure that you will not see the message.  By *empty* I mean
*empty*.  That is, no .deps or .libs files, or anything else for
that matter.

(2) 
cd gnuradio-core/src/lib/swig
for file in *.d do; cp /dev/null $file; done
make

Eric


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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Brett Trotter



Robert McGwier-2 wrote:
> 
> I am doubting the libtool error in this one.  If you have the libtool 
> error, it shows up well before this.   You cannot complete the make.
> 
> IF you cannot complete the make,  and it dies in making the mblock 
> message block code,  then you can go back to the pmt directory and in 
> that directory do  install
>  
> cd pmt
> make install
> cd ..
> make
> 
> the make will now complete mblock in a few seconds and the rest of the 
> tree will build.  From there,  I have no problems at all with the main 
> branch.
> 
> I have been UNBELIEVABLY tied up since the first of the year and I have 
> no revisited the Rondeau, Ettus, and McGwier (n4hy)  OFDM code since 
> that time.  I will make it tonight and see what happens.
> 
> Tom will be here through the weekend and possible we can check into it 
> if I discover a problem.
> 
> Bob
> (n4hy)
> 
> 
> 
> Eric Blossom wrote:
>> On Fri, Jan 26, 2007 at 02:55:29PM -0800, Brett Trotter wrote:
>>   
>>> Brett Trotter wrote:
>>> 
 I did a bootstrap, configure, make, make install on n4hy's tree and
 when I
 try to run ofdm_benchmark_tx, I get
 [EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
 Traceback (most recent call last):
   File "./benchmark_ofdm_tx.py", line 23, in ?
 from gnuradio import gr, gru, modulation_utils
   File
 "/usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py",
 line 27, in ?
 from gnuradio_swig_python import *
   File
 "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py",
 line 6, in ?
 import _gnuradio_swig_python
 ImportError:
 /usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_python.so:
 undefined symbol: _Z15gr_make_fft_vccibSt6vectorIfSaIfEE


 I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume
 there's a problem with my swig-python or swig- what versions of
 everything
 should I be using?

   
>>> Replying to myself here, I heard from someone that I should do make
>>> uninstall on the standard tree before doing make install on n4hy's tree.
>>> I
>>> make uninstalled both just to make sure it was cleaned out, and toasted
>>> /usr/local/lib/python2.4/site-packages/gnuradio (same for lib64) and did
>>> make install of n4hy's - only to discover that _gnuradio_swig_python is
>>> now
>>> missing. Another make uninstall, another rm, and reinstalled the stable
>>> tree- which yields the same error.
>>>
>>> Why is make install not putting _gnuradio_swig_python in place do you
>>> suppose? Have I missed something?
>>>
>>> 
>>
>> Which distribution are you guys using?
>>
>> I believe that the Ubuntu libtool problem is still unresolved.
>> I'd really appreciate it if somebody who uses ubuntu would test and
>> document a fix.  I suspect that it could be as easy as rolling libtool
>> back to libtool-1.5.22-3
>>
>> Eric
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>   
> 
> 
> -- 
> AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
> TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
> "Taking fun as simply fun and earnestness in earnest shows
> how thoroughly thou none of the two discernest." - Piet Hine
> 
> 
> 
> 

I took Dan Halperin's advice and totally deleted my build tree- I also
totally cleaned out all traces of gnuradio and re-checked out everything
from subversion and re-built (n4hy's tree) and am still missing
_gnuradio_swig_python.

As you may have seen from my first post in this thread, I was originally
getting an error about _Z15gr_make_fft_vccibSt6vectorIfSaIfEE being missing
using the n4hy's benchmark_ofdm_tx on after make installing n4hy's tree over
the stable..- and after make uninstalling the stable tree, and make
installing n4hy's, I now am missing the swig python bit.

So- I'm going to go and clean out everything again and rebuild the stable
tree and see if I get my swig_python bits back. Am I making a rookie mistake
here somewhere?
-- 
View this message in context: 
http://www.nabble.com/OFDM-in-n4hy%27s-tree-tf3124511.html#a8662232
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] OFDM in n4hy's tree

2007-01-26 Thread Robert McGwier
I am doubting the libtool error in this one.  If you have the libtool 
error, it shows up well before this.   You cannot complete the make.


IF you cannot complete the make,  and it dies in making the mblock 
message block code,  then you can go back to the pmt directory and in 
that directory do  install


cd pmt
make install
cd ..
make

the make will now complete mblock in a few seconds and the rest of the 
tree will build.  From there,  I have no problems at all with the main 
branch.


I have been UNBELIEVABLY tied up since the first of the year and I have 
no revisited the Rondeau, Ettus, and McGwier (n4hy)  OFDM code since 
that time.  I will make it tonight and see what happens.


Tom will be here through the weekend and possible we can check into it 
if I discover a problem.


Bob
(n4hy)



Eric Blossom wrote:

On Fri, Jan 26, 2007 at 02:55:29PM -0800, Brett Trotter wrote:
  

Brett Trotter wrote:


I did a bootstrap, configure, make, make install on n4hy's tree and when I
try to run ofdm_benchmark_tx, I get
[EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
Traceback (most recent call last):
  File "./benchmark_ofdm_tx.py", line 23, in ?
from gnuradio import gr, gru, modulation_utils
  File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py",
line 27, in ?
from gnuradio_swig_python import *
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py",
line 6, in ?
import _gnuradio_swig_python
ImportError:
/usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_python.so:
undefined symbol: _Z15gr_make_fft_vccibSt6vectorIfSaIfEE


I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume
there's a problem with my swig-python or swig- what versions of everything
should I be using?

  

Replying to myself here, I heard from someone that I should do make
uninstall on the standard tree before doing make install on n4hy's tree. I
make uninstalled both just to make sure it was cleaned out, and toasted
/usr/local/lib/python2.4/site-packages/gnuradio (same for lib64) and did
make install of n4hy's - only to discover that _gnuradio_swig_python is now
missing. Another make uninstall, another rm, and reinstalled the stable
tree- which yields the same error.

Why is make install not putting _gnuradio_swig_python in place do you
suppose? Have I missed something?




Which distribution are you guys using?

I believe that the Ubuntu libtool problem is still unresolved.
I'd really appreciate it if somebody who uses ubuntu would test and
document a fix.  I suspect that it could be as easy as rolling libtool
back to libtool-1.5.22-3

Eric


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

  



--
AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
"Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest." - Piet Hine



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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Eric Blossom
On Fri, Jan 26, 2007 at 02:55:29PM -0800, Brett Trotter wrote:
> 
> 
> Brett Trotter wrote:
> > 
> > I did a bootstrap, configure, make, make install on n4hy's tree and when I
> > try to run ofdm_benchmark_tx, I get
> > [EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
> > Traceback (most recent call last):
> >   File "./benchmark_ofdm_tx.py", line 23, in ?
> > from gnuradio import gr, gru, modulation_utils
> >   File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py",
> > line 27, in ?
> > from gnuradio_swig_python import *
> >   File
> > "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py",
> > line 6, in ?
> > import _gnuradio_swig_python
> > ImportError:
> > /usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_python.so:
> > undefined symbol: _Z15gr_make_fft_vccibSt6vectorIfSaIfEE
> > 
> > 
> > I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume
> > there's a problem with my swig-python or swig- what versions of everything
> > should I be using?
> > 
> 
> Replying to myself here, I heard from someone that I should do make
> uninstall on the standard tree before doing make install on n4hy's tree. I
> make uninstalled both just to make sure it was cleaned out, and toasted
> /usr/local/lib/python2.4/site-packages/gnuradio (same for lib64) and did
> make install of n4hy's - only to discover that _gnuradio_swig_python is now
> missing. Another make uninstall, another rm, and reinstalled the stable
> tree- which yields the same error.
> 
> Why is make install not putting _gnuradio_swig_python in place do you
> suppose? Have I missed something?
> 

Which distribution are you guys using?

I believe that the Ubuntu libtool problem is still unresolved.
I'd really appreciate it if somebody who uses ubuntu would test and
document a fix.  I suspect that it could be as easy as rolling libtool
back to libtool-1.5.22-3

Eric


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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Dan Halperin
Brett Trotter wrote:
> Replying to myself here, I heard from someone that I should do make
> uninstall on the standard tree before doing make install on n4hy's tree. I
> make uninstalled both just to make sure it was cleaned out, and toasted
> /usr/local/lib/python2.4/site-packages/gnuradio (same for lib64) and did
> make install of n4hy's - only to discover that _gnuradio_swig_python is now
> missing. Another make uninstall, another rm, and reinstalled the stable
> tree- which yields the same error.
>
> Why is make install not putting _gnuradio_swig_python in place do you
> suppose? Have I missed something?
When I updated after that whole set of emails, I ended up doing a make
uninstall, removing the entire svn tree, re-checking out the code, and
then reinstalling. That's what made it work.

-Dan


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


Re: [Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Brett Trotter


Brett Trotter wrote:
> 
> I did a bootstrap, configure, make, make install on n4hy's tree and when I
> try to run ofdm_benchmark_tx, I get
> [EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
> Traceback (most recent call last):
>   File "./benchmark_ofdm_tx.py", line 23, in ?
> from gnuradio import gr, gru, modulation_utils
>   File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py",
> line 27, in ?
> from gnuradio_swig_python import *
>   File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py",
> line 6, in ?
> import _gnuradio_swig_python
> ImportError:
> /usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_python.so:
> undefined symbol: _Z15gr_make_fft_vccibSt6vectorIfSaIfEE
> 
> 
> I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume
> there's a problem with my swig-python or swig- what versions of everything
> should I be using?
> 

Replying to myself here, I heard from someone that I should do make
uninstall on the standard tree before doing make install on n4hy's tree. I
make uninstalled both just to make sure it was cleaned out, and toasted
/usr/local/lib/python2.4/site-packages/gnuradio (same for lib64) and did
make install of n4hy's - only to discover that _gnuradio_swig_python is now
missing. Another make uninstall, another rm, and reinstalled the stable
tree- which yields the same error.

Why is make install not putting _gnuradio_swig_python in place do you
suppose? Have I missed something?

-- 
View this message in context: 
http://www.nabble.com/OFDM-in-n4hy%27s-tree-tf3124511.html#a8660301
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


[Discuss-gnuradio] OFDM in n4hy's tree

2007-01-26 Thread Brett Trotter

I did a bootstrap, configure, make, make install on n4hy's tree and when I
try to run ofdm_benchmark_tx, I get
[EMAIL PROTECTED] ofdm]# ./benchmark_ofdm_tx.py
Traceback (most recent call last):
  File "./benchmark_ofdm_tx.py", line 23, in ?
from gnuradio import gr, gru, modulation_utils
  File "/usr/local/lib/python2.4/site-packages/gnuradio/gr/__init__.py",
line 27, in ?
from gnuradio_swig_python import *
  File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/gnuradio_swig_python.py",
line 6, in ?
import _gnuradio_swig_python
ImportError:
/usr/local/lib/python2.4/site-packages/gnuradio/gr/_gnuradio_swig_python.so:
undefined symbol: _Z15gr_make_fft_vccibSt6vectorIfSaIfEE


I have FC6 on X86_64 with swig.x86_64 1.3.31-0.fc6 installed. I presume
there's a problem with my swig-python or swig- what versions of everything
should I be using?
-- 
View this message in context: 
http://www.nabble.com/OFDM-in-n4hy%27s-tree-tf3124511.html#a8656567
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


[Discuss-gnuradio] OFDM / DAB receiver progress...

2006-08-13 Thread Jens Elsner
Hello,

if someone is interested in OFDM / DAB, I posted what I did so far 
on http://www.1c3.de/gr-dab.tar.bz2.

It contains a small GI correlation based OFDM transmitter / receiver 
for experiments, and a mode 2 DAB receiver (just displays the
constellation).

Jens



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


Re: [Discuss-gnuradio] OFDM block that follow 802.11g standards

2006-06-16 Thread Johnathan Corgan
Gianni wrote:

> Hello,i'm an italian student and i'm studying gnu radio for writing my
> future degree.I need that someone give me informations about ofdm blocks
> that follow the 802.11g standards.. Thank you

Gianni--I think we all appreciate the persistence you've shown in asking
this question repeatedly when nobody answered you. But you're asking a
wide open question that doesn't really indicate what you're looking for.
What do you already know? What have you already figured out on your own?

A Google search for relevant terms shows a large amount of information
available to you for little effort:

http://www.google.com/search?q=802%2E11+ofdm+signal+processing+blocks

In first five search results, there is a pretty good overview:

http://www.us.design-reuse.com/articles/article10358.html

-Johnathan


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


[Discuss-gnuradio] OFDM block that follow 802.11g standards

2006-06-16 Thread Gianni
Hello,i'm an italian student and i'm studying gnu radio for writing my future degree.I need that someone give me informations about ofdm blocks that follow the 802.11g standards.. Thank you
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] OFDM block standard 802.11 help

2006-06-14 Thread Gianni
Hello,i'm an italian student and i'm studying gnu radio for writing my
future degree.I need that someone give me informations about how to write an ofdm
block that follow the 802.11g standards.. Thank you
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-29 Thread Jens Elsner
Hi Prateek,

yes - I sampled another radio station (this time at 1,5 GHz -> broader
subcarriers) and the "jitter" was significantly reduced. I implemented
deinterleavingi, channel coding, and descrambling - but so far no success in
demodulating. Yesterday I wrote a sender to check my receiver but I
didn't do any testing yet. 

This is pretty much where I am now. It's all Matlab but I'd be happy to
share the code with you next week as I'm not home over the weekend.

I took a look at the Dream code too - a lot of this code could be reused
(syncronisation, frequency estimation). 

If we do an OFDM implementation we should spend some time designing it.
The resulting code should be as flexible as possible.

My deadline for this project is the beginning of October.

Jens

On Sat, Apr 29, 2006 at 01:12:23AM +0530, Prateek Dayal wrote:
> hi jens,
> 
> did u make any progress in ur OFDM problem. I have some free time now and
> would like to work on this too in the gnuradio framework.
> 
> Have u captured any more data that you can please share with me ?
> 
> Regards
> Prateek
> 
> On 4/6/06, Jens Elsner <[EMAIL PROTECTED]> wrote:
> >
> >Achilleas,
> >
> >thanks for your comments. I am beginning to like this problem, as it has
> >extended my knowlegde of OFDM tremendously - thanks everybody.
> >
> >Nevertheless I'd like to see it solved. We have ruled out pretty much
> >every effect - I'm beginning to suspect that the transmitter actually
> >sends
> >shifted symbols. The remaindre of this week I'll be pretty busy, but I'll
> >come back to
> >the problem and get data from other radio stations to verify.
> >
> >> >Frequency offset results in ICI.
> >> > This is "white noise" interference.
> >>
> >> Correct: v0 will result in a time offset of N*v0
> >> which will manifest itself as ICI.
> >>
> >> There is MORE to it.
> >> It ALSO introduces an unknown phase offest (constant in each
> >subchannel):
> >> Consider the i-th component of consequtive OFDM symbols.
> >> They are effectively rotated by multiples of 2*pi*(N+G)*v0.
> >> This is the phase accumulated over an OFDM symbol duration.
> >> Although the linear phase increase will be compensated by D-QPSK, there
> >> will be a constant phase rotation equal to 2*pi*(N+G)*v0 in all
> >> demodulated QPSK symbols.
> >Yes, agreed. This effect can be seen nicely if you demodulate a symbol
> >and change the fractional frequency offset in small steps. The
> >constellation pulsates (white interference) and rotates (phase rotation).
> >
> >> BTW, If you make sure that you estimate v0 with an accuracy of 1e-6
> >> then the time offset is on the order of 1e-3 (negligible) and the
> >> frequency offset on the order of 1 degree (negligible).
> >I think I hit the right frequency by +- 1 Hz, subcarrier spacing being
> >1KHz. Should be alright.
> >
> >> BTW, because of the way you have coded your frequency correction (in
> >> your Matlab code) even perfect estimation of v0 will still result in the
> >> above phenomenon.
> >> If you correct for v0 INDIVIDUALLY in each OFDM symbol (as you do in
> >> your code), then--assuming perfect estimation of v0--there will be two
> >> effects:
> >> 1) within each OFDM symbol there will be no phase variation since you
> >> have corrected it already
> >> 2) each consequtive sample in the i-th subchannel will be advanced by
> >> 2*pi*(N+G)*v0 radians. This is the phase accumulated over an OFDM symbol
> >> duration.
> >> This is why it is important to derotate your entire frame at once.
> >Ok. I changed that in my code.
> >
> >> Having said that, it seems that even if this is done, the problem you
> >> observe is still there!
> >
> >> >I am clueless.
> >>
> >> I attach a piece of Matlab code that simulates both the Tx and Rx.
> >> Everything mentioned above can be demonstrated in this controled
> >experiment.
> >Great - nice way to learn about OFDM.
> >
> >> I still do not understand why the real-data application does not work.
> >Neither do I - I'll get other data next week.
> >
> >Jens
> >
> >
> >___
> >Discuss-gnuradio mailing list
> >Discuss-gnuradio@gnu.org
> >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> 
> 
> --
> Prateek Dayal
> http://flickr.com/photos/prateekdayal


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-06 Thread Jens Elsner
Achilleas,

thanks for your comments. I am beginning to like this problem, as it has 
extended my knowlegde of OFDM tremendously - thanks everybody. 

Nevertheless I'd like to see it solved. We have ruled out pretty much
every effect - I'm beginning to suspect that the transmitter actually sends
shifted symbols. The remaindre of this week I'll be pretty busy, but I'll come 
back to
the problem and get data from other radio stations to verify.

> >Frequency offset results in ICI. 
> > This is "white noise" interference.
> 
> Correct: v0 will result in a time offset of N*v0
> which will manifest itself as ICI.
> 
> There is MORE to it.
> It ALSO introduces an unknown phase offest (constant in each subchannel):
> Consider the i-th component of consequtive OFDM symbols.
> They are effectively rotated by multiples of 2*pi*(N+G)*v0.
> This is the phase accumulated over an OFDM symbol duration.
> Although the linear phase increase will be compensated by D-QPSK, there 
> will be a constant phase rotation equal to 2*pi*(N+G)*v0 in all
> demodulated QPSK symbols.
Yes, agreed. This effect can be seen nicely if you demodulate a symbol
and change the fractional frequency offset in small steps. The
constellation pulsates (white interference) and rotates (phase rotation). 

> BTW, If you make sure that you estimate v0 with an accuracy of 1e-6
> then the time offset is on the order of 1e-3 (negligible) and the
> frequency offset on the order of 1 degree (negligible).
I think I hit the right frequency by +- 1 Hz, subcarrier spacing being
1KHz. Should be alright.

> BTW, because of the way you have coded your frequency correction (in 
> your Matlab code) even perfect estimation of v0 will still result in the 
> above phenomenon.
> If you correct for v0 INDIVIDUALLY in each OFDM symbol (as you do in 
> your code), then--assuming perfect estimation of v0--there will be two 
> effects:
> 1) within each OFDM symbol there will be no phase variation since you 
> have corrected it already
> 2) each consequtive sample in the i-th subchannel will be advanced by
> 2*pi*(N+G)*v0 radians. This is the phase accumulated over an OFDM symbol 
> duration.
> This is why it is important to derotate your entire frame at once.
Ok. I changed that in my code. 

> Having said that, it seems that even if this is done, the problem you 
> observe is still there!

> >I am clueless.
> 
> I attach a piece of Matlab code that simulates both the Tx and Rx.
> Everything mentioned above can be demonstrated in this controled experiment.
Great - nice way to learn about OFDM.

> I still do not understand why the real-data application does not work.
Neither do I - I'll get other data next week.

Jens


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-06 Thread Jens Elsner
(comments inlined)

On Wed, Apr 05, 2006 at 02:02:23PM -0400, Robert McGwier wrote:
> Yes. Here is what you are missing:
> 
> Let us concentrate (as does your nice animated gif) on one channel in 
> the OFDM.
Yes, what's depicted are all decoded symbols in one OFDM frame.

> Let us suppose you have a variable delay into the signal after its 
> onset.  This will happen with probability one because your clock and the 
> transmitter clock will not be the same except in your computer simulation.
Agreed. But this delay will only be fractional, as I can determine the
exact start by correlation. The oscillators are pretty stable, so I can
exactly time one symbol. The offset will thus be fractional and constant.

I verified this by correlating every OFDM symbol with itself. This 
shows that the cyclic prefix does not move. 

> If you took the FFT beginning (say) 39 samples into the symbol at  t,  
> and then   52 samples after the beginning time for symbol at  t+1,   
> this will be an additional rotation due to the frequency offset of this 
> channel from zero.  Notice this means that every channel will have a 
> different rotation which will be a multiple of the frequency offset from 
> correct and the difference in time after symbol onset you go into the 
> symbol to take the FFT.
I agree. But, as stated above, my time offset is fractional and
constant.

Jens


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-05 Thread Achilleas Anastasopoulos


Jens,

I would like to elaborate on some of your comments.
I am using the following notation:
N fft size (2048)
G guard interval (504)
v0 fractional frequency offset
f0=v0 T absolute frequency offset
tau0 fractional time offset
t0=tau0 T absolute timne offset

To sum up: 

Frequency offset results in ICI. 
	This is "white noise" interference.


Correct: v0 will result in a time offset of N*v0
which will manifest itself as ICI.

There is MORE to it.
It ALSO introduces an unknown phase offest (constant in each subchannel):
Consider the i-th component of consequtive OFDM symbols.
They are effectively rotated by multiples of 2*pi*(N+G)*v0.
This is the phase accumulated over an OFDM symbol duration.
Although the linear phase increase will be compensated by D-QPSK, there 
will be a constant phase rotation equal to 2*pi*(N+G)*v0 in all

demodulated QPSK symbols.

BTW, If you make sure that you estimate v0 with an accuracy of 1e-6
then the time offset is on the order of 1e-3 (negligible) and the
frequency offset on the order of 1 degree (negligible).

BTW, because of the way you have coded your frequency correction (in 
your Matlab code) even perfect estimation of v0 will still result in the 
above phenomenon.
If you correct for v0 INDIVIDUALLY in each OFDM symbol (as you do in 
your code), then--assuming perfect estimation of v0--there will be two 
effects:
1) within each OFDM symbol there will be no phase variation since you 
have corrected it already

2) each consequtive sample in the i-th subchannel will be advanced by
2*pi*(N+G)*v0 radians. This is the phase accumulated over an OFDM symbol 
duration.

This is why it is important to derotate your entire frame at once.


Having said that, it seems that even if this is done, the problem you 
observe is still there!




Time offset results in 


a) ISI, if offset results in taking values from other symbols.
This is also "white" interference.

b) phase shift, if offset results in taking values from the
cyclic prefix. This results in a "circle" structure, as the
phase shift is higher for subcarriers of higher frequency.

The time offset effect b) is removed by differential demodulation, since
the phase shift will be the same.


I agree with the above.
Also, the above assumes that the offset tau0 remains fixed for
each OFDM symbol. Otherwise, the comment made by Bob is valid.
However, I think the DAB system is designed to operate under this 
assumption, since they have a single pilot in the begining of the frame.


The effect I am seeing is a constant phase shift for all subcarriers, 
different for each OFDM symbol. Nothing that could be explained with a
frequency offset or a time offset. 


I am clueless.


I attach a piece of Matlab code that simulates both the Tx and Rx.
Everything mentioned above can be demonstrated in this controled experiment.

I still do not understand why the real-data application does not work.

Achilleas
function [f0 ,t0] = freq_time_est(ff,M,sync,wframe)



rec=zeros(M,2);
for t=1:M,
%t

out=zeros(1,length(ff));
for k=1:length(ff)
f=ff(k);
s=sync.*exp(j*2*pi*f*[1:length(sync)]);
out(k)=mean(s.*conj(wframe(t:t+length(sync)-1)));
end
[value f0i]=max(out);

rec(t,:)=[value f0i];


end
[gvalue t0]=max(rec(:,1));
f0=ff(rec(t0,2));clear all;
%close all;


Q=76;
%data=zeros(1537,Q-1);
data=floor(rand(1537,Q-1)*4);

qpsk=exp(j*2*pi*data/4);
qpsk(769,:)=zeros(1,Q-1);

%dqpsk modulation
dqpsk=zeros(1537,Q);
sync=floor(rand(1537,1)*4);
%dqpsk(:,1)=ones(1537,1);
dqpsk(:,1)=exp(j*2*pi*sync/4);
dqpsk(769,1)=0;
for k=2:Q,
dqpsk(:,k)=dqpsk(:,k-1).*qpsk(:,k-1);
end

% initial phases of the oscilators
phase0=2*pi*rand(1537,1);
dqpsk=dqpsk.*(exp(j*phase0)*ones(1,Q));

% ofdm modulation
frame=zeros(504+2048,Q);
for l=1:Q
a=dqpsk(:,l).';
aa=[zeros(1,256) a zeros(1,255)];
aaa=fftshift(aa);
am=ifft(aaa); % OFDM symbol
amp=[am(end-503:end) am].'; % with prefix
amp=amp/sqrt(mean(abs(amp).^2)); % normalize power to 1
frame(:,l)=amp;
end
msync=frame(:,1);  % modulated sync (1st ofdm symbol with prefix) for later use

D=1000;   
frame_h=[zeros(1,D) reshape(frame,1,Q*(504+2048)) zeros(1,D)]; % zeros in head 
and tail








%===
%channel
% ISI
% Le=300;
% h=randn(1,Le)+j*randn(1,Le);
% h=h./sqrt(mean(abs(h).^2));
% frame_h=conv(h,frame_h);

% frequency error
df=1.0e-5;
f=frame_h.*exp(j*2*pi*df*[1:length(frame_h)]+j*rand(1,1)*2*pi);


% timing error (uncomment this if you want to introduce timing error)
% M=11;   % max integer error [-M,M] samples
% ts0=0;
% while ts0==0
%ts0=floor(rand(1,1)*M)-floor((M-1)/2);
% end
% ts0; % so the timing error is ts0 samples (so far) 
% 
% L=5;   % resolution of fractional errors
% tf0=0;
% while tf0==0
%tf0=floor(rand(1,1)*L)-floor((L-1)/2);
% end
% tf0; % so the timing error is tt0/L samples (fractional)
% 
% tt0=ts0*L+tf0; % total timing error
% [ts0 tf0/L tt0/L]
% framei_h=resample(f,L

Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-05 Thread Robert McGwier

Yes. Here is what you are missing:

Let us concentrate (as does your nice animated gif) on one channel in 
the OFDM.


Let us suppose you have a variable delay into the signal after its 
onset.  This will happen with probability one because your clock and the 
transmitter clock will not be the same except in your computer simulation.


If you took the FFT beginning (say) 39 samples into the symbol at  t,  
and then   52 samples after the beginning time for symbol at  t+1,   
this will be an additional rotation due to the frequency offset of this 
channel from zero.  Notice this means that every channel will have a 
different rotation which will be a multiple of the frequency offset from 
correct and the difference in time after symbol onset you go into the 
symbol to take the FFT.


This is definitely a nontrivial exercise to get right.

Bob



Jens Elsner wrote:
Thank you very much for the reference.   This was a very nice link to 
Mostofi's work.  The following paper is also pertinent to Jen's thinking 
on the guard interval offset being irrelevant.  It is not of course:


*Y. Mostofi*, D. Cox and A. Bahai, "Effect of Timing Synchronization 
Errors on Pilot-aided Channel Estimation in OFDM: Analysis and 
Solution," /Proceedings of 5^th IEEE International Symposium on Wireless 
Personal Multimedia Communications (WPMC),/ Honolulu, Hawaii, Oct. 2002, 
pp. 1309-1313.


http://www.cds.caltech.edu/~yasi/papers/WPMC02.pdf


Bob,

I am still convinced that using differential demodulation removes the
phase shift (see reply to Prateek). Or is there something I am not
seeing so far?

Jens


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

  



--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!



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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-05 Thread Jens Elsner
> Thank you very much for the reference.   This was a very nice link to 
> Mostofi's work.  The following paper is also pertinent to Jen's thinking 
> on the guard interval offset being irrelevant.  It is not of course:
> 
> *Y. Mostofi*, D. Cox and A. Bahai, "Effect of Timing Synchronization 
> Errors on Pilot-aided Channel Estimation in OFDM: Analysis and 
> Solution," /Proceedings of 5^th IEEE International Symposium on Wireless 
> Personal Multimedia Communications (WPMC),/ Honolulu, Hawaii, Oct. 2002, 
> pp. 1309-1313.
> 
> http://www.cds.caltech.edu/~yasi/papers/WPMC02.pdf
Bob,

I am still convinced that using differential demodulation removes the
phase shift (see reply to Prateek). Or is there something I am not
seeing so far?

Jens


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-05 Thread Jens Elsner
Thanks for the reply! I'm really struggeling here... 

> Yes, I think this is a critical step. small letters are time domain and
> capital letters are frequency domain.
> 
> x(n) ---> X(k)
>  FFT
> 
> x(n-n') -> e^(j*2*pi*n'*k/N) * X(k)
> FFT
> 
> for one OFDM symbol,  0 <= k <= N-1
> 
> Therefore as you can see the phase shift will increase with k. For k=0,
> there will be no phase shift and for k=N-1, there will be a phase shift of
> almost 2*pi*n'. Therefore for a QPSK, when you map symbols to bits, there
> will be more errors for higher subcarrier (index).  You have to start
> sampling exactly after the cyclic prefix ends. In general if your timing
> error is towards cyclic prefix, you effectively cyclic shift your data. In
> case your shift is away from the end of the cyclic prefix, you take some
> samples from next symbol and introduce ISI. You need to see how this will
> effect you in DQPSK case. Please look at this link for relevant papers

The phase shift doesn't matter in differential demodulated systems.

To sum up: 

Frequency offset results in ICI. 
This is "white noise" interference.

Time offset results in 

a) ISI, if offset results in taking values from other symbols.
This is also "white" interference.

b) phase shift, if offset results in taking values from the
cyclic prefix. This results in a "circle" structure, as the
phase shift is higher for subcarriers of higher frequency.

The time offset effect b) is removed by differential demodulation, since
the phase shift will be the same.

The effect I am seeing is a constant phase shift for all subcarriers, 
different for each OFDM symbol. Nothing that could be explained with a
frequency offset or a time offset. 

I am clueless.

> In general if your relative frequency offset is .01 or less, I think you
> will not be affected much. But again I am not too sure for DQPSK. Again QAM
> is more sensitive to these errors than QPSK.
A small frequency offset results just in a SNR degradation - my
estimation is pretty accurate.

Jens


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-05 Thread Jens Elsner
Achilleas,

my estimate is based on frequency domain correlation. Just count the
offset of the maximum (o). Then estimate the fractional offset (fo) by taking 
the
value left (l) and right (r) of the maximum and calculate fo = (r-l)/(r+l).
To compensate substract the resulting frequency offset (o+fo) from the 
received signal. Works as long the channel doesn't interfere too much.

Jens


On Tue, Apr 04, 2006 at 07:52:58PM -0400, Achilleas Anastasopoulos wrote:
> Jens,
> 
> I used a complete ad-hoc method for automatic frequency estimation:
> tracing the minimum ratio of the power of DC over the total power of the 
> remaining channels, averaged over all symbols in a frame.
> Your estimate seems quite good!
> 
> I atatch the .m file
> 
> I have not tried anything with the timing yet...
> 
> Achilleas

> clear all;
> close all;
> 
> % dab.dat contains data sampled from the USRP 2 MHz (decimation factor 32)
> 
> fid = fopen('dab_ml.dat', 'r');
> %skip 5 samples - bug in gnuradio?
> d = fread(fid, 5, 'float32');
> 
> %read real
> d_re = fread(fid, 100, 'float32',4);
> fclose(fid);
> 
> fid = fopen('dab_ml.dat', 'r');
> %skip 50001 samples - bug in gnuradio?
> d = fread(fid, 50001, 'float32');
> 
> %read imag
> d_im = fread(fid, 100, 'float32', 4);
> fclose(fid);
> 
> e = d_re + j*d_im;
> clear d*
> 
> % not all data need, file too big
> chunk = e(1:70);
> 
> % Generate phase reference symbol, frequency domain
> p = prs;
> 
> % resampling
> chunk_resamp = resample(chunk, 2048, 2000);
> 
> % this code is used to look for the synch frame manually
> if 1==0
> 
> glob_max = 0;
> for k = 3.6*105:length(chunk_resamp)
> data = chunk_resamp(k:k+2048);
> f = fftshift(fft(data,2048));
> 
> xc = abs(xcorr(p,f));
> 
> [m offset] = max(xc);
> if m > 107
> disp('found synch frame');
> plot(xc);
> axis([0 4000 0 2*107]);
> drawnow
> %pause
> k
> end
> if m > glob_max
> offset_max = offset
> glob_max = m
> glob_max_k = k
> plot(xc);
> axis([0 4000 0 2*107]);
> drawnow
> %pause
> end
> drawnow
> end
> 
> end
> 
> % decode one frame (75 symbols + synch symbol)
> for o = 0:75
> 
> % start of frame (after the end of null period), found manually
> start_resamp = 168988;
> s0=start_resamp-2656-504; % my start (begining of NULL)
> 
> %get the data for one OFDM symbol (2048 samples), skip guard intervall (504
> %samples)
> data_resamp = 
> chunk_resamp(start_resamp+(504+2048)*o:start_resamp+2048-1+(504+2048)*o);
> 
> % compensate frequency offset - done manually (how?)
> data2_resamp = 
> data_resamp.*exp(j*linspace(0,2*pi*(0.385-8),length(data_resamp)).');
> 
> % fft to decode data
> d_resamp = fftshift(fft(data2_resamp,2048));
> 
> % only 1536 subcarriers + DC carrier to display
> %data = d_resamp(256:1792);
> data = d_resamp(257:1793);
> 
> % first OFDM symbol is used for synchronization - no data.
> % if o == 0
> % plot(abs(d_resamp).^2);
> % drawnow
> % pause
> % end
> 
> % display decoded data symbols, including DC carrier
> if o ~= 0
> dem = data ./ data_l ;
> %dem = data .* conj(data_l) ;
> %dem=dem./abs(dem);
> 
> plot(real(dem), imag(dem), 'o');
> axis([-3 3 -3 3]);
> 
> drawnow
> 
> pause
> end
> 
> % DAB uses pi/4 DPSK, last frame is reference (I only see DQPSK in the 
> standard)
> data_l = data;
> 
> 
> end
> 

> ___
> 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] OFDM demodulation problem / example video

2006-04-04 Thread Robert McGwier

Prateek Dayal wrote:



On 4/4/06, *Robert McGwier* <[EMAIL PROTECTED] 
> wrote:




http://www.cds.caltech.edu/~yasi/publications.html 



Also for frequency offset, what really matters is not the frequency 
offset in Hz, but the relative frequency offset delta_f/F_s, where F_s 
is the subcarrier spacing. Please look at


*BER sensitivity of OFDM systems to carrier frequency offset andWiener 
phase noise*

Pollet, T.; Van Bladel, M.; Moeneclaey, M.
Communications, IEEE Transactions on
Volume 43, Issue 234, Feb/Mar/Apr 1995 Page(s):191 - 193
Digital Object Identifier   10.1109/26.380034

In general if your relative frequency offset is .01 or less, I think 
you will not be affected much. But again I am not too sure for DQPSK. 
Again QAM is more sensitive to these errors than QPSK.


Please correct me if I am wrong somewhere. I am sharing what I have 
recently learnt about these things 


Regards
Prateek Dayal
 



Thank you very much for the reference.   This was a very nice link to 
Mostofi's work.  The following paper is also pertinent to Jen's thinking 
on the guard interval offset being irrelevant.  It is not of course:


*Y. Mostofi*, D. Cox and A. Bahai, "Effect of Timing Synchronization 
Errors on Pilot-aided Channel Estimation in OFDM: Analysis and 
Solution," /Proceedings of 5^th IEEE International Symposium on Wireless 
Personal Multimedia Communications (WPMC),/ Honolulu, Hawaii, Oct. 2002, 
pp. 1309-1313.


http://www.cds.caltech.edu/~yasi/papers/WPMC02.pdf

Best wishes,
Bob

--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!



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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-04 Thread Prateek Dayal
On 4/4/06, Robert McGwier <[EMAIL PROTECTED]> wrote:
Jens Elsner wrote:> Achilleas,>> thanks for taking the time. My goal is to implement COFDM in gnuradio,> DAB is a nice start.>> To your points: Time sync is not a problem in OFDM - the guard interval takes care of
> that. Nice property. Try playing along with the "start_resamp" value -> it will work for an offset up to about 504 (this is the length of the guard> interval).>> Jens>
>>AHA!  Now we are getting some place.  This last paragraph was veryrevealing.  Time sync is not a problem because of the guard interval BUTvarying depth in to the guard interval will IMMEDIATELY translate into
phase shifts on each and every bin that will vary with frequency anddepth into the guard interval.  I am sorry I have not had time to spendon the code but I have a lot going at the moment.   There is simply no
such thing as a free lunch anywhere anytime, not even with OFDM.BobYes, I think this is a critical step. small letters are time domain and capital letters are frequency domain.x(n) ---> X(k)
 FFTx(n-n') -> e^(j*2*pi*n'*k/N) * X(k)    FFTfor one OFDM symbol,  0 <= k <= N-1 Therefore as you can see the phase shift will increase with k. For k=0, there will be no phase shift and for k=N-1, there will be a phase shift of almost 2*pi*n'. Therefore for a QPSK, when you map symbols to bits, there will be more errors for higher subcarrier (index).  You have to start sampling exactly after the cyclic prefix ends. In general if your timing error is towards cyclic prefix, you effectively cyclic shift your data. In case your shift is away from the end of the cyclic prefix, you take some samples from next symbol and introduce ISI. You need to see how this will effect you in DQPSK case. Please look at this link for relevant papers
http://www.cds.caltech.edu/~yasi/publications.htmlAlso for frequency offset, what really matters is not the frequency offset in Hz, but the relative frequency offset delta_f/F_s, where F_s is the subcarrier spacing. Please look at
BER sensitivity of OFDM systems to carrier frequency offset andWiener phase noise
Pollet, T.; Van Bladel, M.; Moeneclaey, M.
Communications, IEEE Transactions on
Volume 43, Issue 234, Feb/Mar/Apr 1995 Page(s):191 - 193
Digital Object Identifier   10.1109/26.380034In general if your relative frequency offset is .01 or less, I think you will not be affected much. But again I am not too sure for DQPSK. Again QAM is more sensitive to these errors than QPSK. 
Please correct me if I am wrong somewhere. I am sharing what I have recently learnt about these things RegardsPrateek Dayal 
--AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp ChairmanLaziness is the number one inspiration for ingenuity.  Guilty as charged!
___Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio-- Prateek Dayalwww.prateek.hostingzero.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-04 Thread Achilleas Anastasopoulos

Jens,

I used a complete ad-hoc method for automatic frequency estimation:
tracing the minimum ratio of the power of DC over the total power of the 
remaining channels, averaged over all symbols in a frame.

Your estimate seems quite good!

I atatch the .m file

I have not tried anything with the timing yet...

Achilleas
clear all;
close all;

% dab.dat contains data sampled from the USRP 2 MHz (decimation factor 32)

fid = fopen('dab_ml.dat', 'r');
%skip 5 samples - bug in gnuradio?
d = fread(fid, 5, 'float32');

%read real
d_re = fread(fid, 100, 'float32',4);
fclose(fid);

fid = fopen('dab_ml.dat', 'r');
%skip 50001 samples - bug in gnuradio?
d = fread(fid, 50001, 'float32');

%read imag
d_im = fread(fid, 100, 'float32', 4);
fclose(fid);

e = d_re + j*d_im;
clear d*

% not all data need, file too big
chunk = e(1:70);

% Generate phase reference symbol, frequency domain
p = prs;

% resampling
chunk_resamp = resample(chunk, 2048, 2000);

% this code is used to look for the synch frame manually
if 1==0

glob_max = 0;
for k = 3.6*105:length(chunk_resamp)
data = chunk_resamp(k:k+2048);
f = fftshift(fft(data,2048));

xc = abs(xcorr(p,f));

[m offset] = max(xc);
if m > 107
disp('found synch frame');
plot(xc);
axis([0 4000 0 2*107]);
drawnow
%pause
k
end
if m > glob_max
offset_max = offset
glob_max = m
glob_max_k = k
plot(xc);
axis([0 4000 0 2*107]);
drawnow
%pause
end
drawnow
end

end

% decode one frame (75 symbols + synch symbol)
for o = 0:75

% start of frame (after the end of null period), found manually
start_resamp = 168988;
s0=start_resamp-2656-504; % my start (begining of NULL)

%get the data for one OFDM symbol (2048 samples), skip guard intervall (504
%samples)
data_resamp = 
chunk_resamp(start_resamp+(504+2048)*o:start_resamp+2048-1+(504+2048)*o);

% compensate frequency offset - done manually (how?)
data2_resamp = 
data_resamp.*exp(j*linspace(0,2*pi*(0.385-8),length(data_resamp)).');

% fft to decode data
d_resamp = fftshift(fft(data2_resamp,2048));

% only 1536 subcarriers + DC carrier to display
%data = d_resamp(256:1792);
data = d_resamp(257:1793);

% first OFDM symbol is used for synchronization - no data.
% if o == 0
% plot(abs(d_resamp).^2);
% drawnow
% pause
% end

% display decoded data symbols, including DC carrier
if o ~= 0
dem = data ./ data_l ;
%dem = data .* conj(data_l) ;
%dem=dem./abs(dem);

plot(real(dem), imag(dem), 'o');
axis([-3 3 -3 3]);

drawnow

pause
end

% DAB uses pi/4 DPSK, last frame is reference (I only see DQPSK in the standard)
data_l = data;


end

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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-04 Thread Robert McGwier

Jens Elsner wrote:

Achilleas,

thanks for taking the time. My goal is to implement COFDM in gnuradio, 
DAB is a nice start.


To your points:

  


Time sync is not a problem in OFDM - the guard interval takes care of
that. Nice property. Try playing along with the "start_resamp" value -
it will work for an offset up to about 504 (this is the length of the guard
interval).

Jens


  



AHA!  Now we are getting some place.  This last paragraph was very 
revealing.  Time sync is not a problem because of the guard interval BUT 
varying depth in to the guard interval will IMMEDIATELY translate into 
phase shifts on each and every bin that will vary with frequency and 
depth into the guard interval.  I am sorry I have not had time to spend 
on the code but I have a lot going at the moment.   There is simply no 
such thing as a free lunch anywhere anytime, not even with OFDM.


Bob


--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!



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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-04 Thread Jens Elsner
I guess I was a little bit too quick with my answer...

In more detail:

> 2) You have done frequency correction manually: did you do this by 
> looking at the DC subcarrier (no power transmitted here) in the
> received signal prior to OFDM demod?
> Frequency synchronization in OFDM is very crucial, because the OFDM 
> symbol rate is small! To see why, try to understand the effect of a 
> small frequency error at the output of the FFT demodulator.
The fractional offset (0.35) was found manually by look at the
cross-correlation in the frequency domain and taking 

df = (left_of_max - right_of_max) / (left_of_max+right_of_max).

Should be correct, shouldn't it?

> 3) You have found the beginning of the frame manually. In your matlab 
> code you posted there is a variable  "start_resamp" that indicates this.
> How do you know that the begining of frame is not BETWEEN two samples?
> in other words there is no fine timing synchronization. I wonder what 
> the effect of a small timing error is at the output of the FFT demodulator.

I didn't quite understand what you are saying until I though about it:
This should be equivalent to a small modulation in the frequency domain?

I just simulated that by:

% simulate fractional offset
d_resamp = d_resamp .* exp(j*linspace(0,2*pi*0.1,length(d_resamp)).');

No effect - after all I did resampling before.

Jens


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-04 Thread Jens Elsner
Achilleas,

thanks for taking the time. My goal is to implement COFDM in gnuradio, 
DAB is a nice start.

To your points:

> I got interested in this discussion and looked at the
> standard briefly and at your matlab code.
> I have a couple of initial points; I will spend more time sometime this 
> week on your code:
> 
> 1) where in the standard it says that this is pi/4 DQPSK ?
> I only saw that the modulation used is DQPSK.
Page 161, 14.7. "pi/4 shift DQPSK" (standard ETSI EN 300 401 V1.4.1)

> 2) You have done frequency correction manually: did you do this by 
> looking at the DC subcarrier (no power transmitted here) in the
> received signal prior to OFDM demod?
Yes. As can be seen in the code, I used frequency domain correlation
with the pilot symbol. Works perfectly and can also be automated.
There are a lot of papers on frequency offset estimation in OFDM.

> Frequency synchronization in OFDM is very crucial, because the OFDM 
> symbol rate is small! To see why, try to understand the effect of a 
> small frequency error at the output of the FFT demodulator.
Of course - I need to hit the subcarriers within a few Hz. But that
works, as can be seen from the demodulated results.

> 3) You have found the beginning of the frame manually. In your matlab 
> code you posted there is a variable  "start_resamp" that indicates this.
> How do you know that the begining of frame is not BETWEEN two samples?
> in other words there is no fine timing synchronization. I wonder what 
> the effect of a small timing error is at the output of the FFT demodulator.
Time sync is not a problem in OFDM - the guard interval takes care of
that. Nice property. Try playing along with the "start_resamp" value -
it will work for an offset up to about 504 (this is the length of the guard
interval).

Jens


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-04 Thread Achilleas Anastasopoulos

Jens,

I got interested in this discussion and looked at the
standard briefly and at your matlab code.
I have a couple of initial points; I will spend more time sometime this 
week on your code:


1) where in the standard it says that this is pi/4 DQPSK ?
I only saw that the modulation used is DQPSK.

2) You have done frequency correction manually: did you do this by 
looking at the DC subcarrier (no power transmitted here) in the

received signal prior to OFDM demod?
Frequency synchronization in OFDM is very crucial, because the OFDM 
symbol rate is small! To see why, try to understand the effect of a 
small frequency error at the output of the FFT demodulator.


3) You have found the beginning of the frame manually. In your matlab 
code you posted there is a variable  "start_resamp" that indicates this.

How do you know that the begining of frame is not BETWEEN two samples?
in other words there is no fine timing synchronization. I wonder what 
the effect of a small timing error is at the output of the FFT demodulator.


Achilleas




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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-04 Thread Jens Elsner
Further more this means that the demodulated symbol (differences!) should
always have phase 0, pi/4, 2pi/4, 3pi/4 (plus a *constant* offset of pi/8).
But this offset is varying.

Am I right?

And why should the transmitter introduce a varying offset? The problem is 
somewhere in the demodulation chain.

Jens

On Mon, Apr 03, 2006 at 11:23:49AM -0400, Robert McGwier wrote:
> Jens:
> 
> Then this means that the demodulated symbol should always be on points  
> abs(X) = abs(Y) = 1.  HOWEVER,  this must be built correctly into the 
> transmit symbols BEFORE they are transmitted for them to be received by 
> the simple division you have done below.  I hope I get time to visit it 
> in greater detail today.
> 
> Bob
> 
> 
> 
> Jens Elsner wrote:
> >Bob, thanks for the reply.
> >
> >This is exactly what I am doing:
> >
> >[...]
> >dem = data ./ data_l;
> >[...]
> >
> >A point-wise division by the last OFDM symbol. This also restores
> >amplitude, but has the same effect on the phase.
> >
> >I do not control the receiver, my data is from a radio station. I am
> >only trying to demodulate. I am synchronised in the 
> >frequency domain. Time domain synch is also appropriate.
> >
> >I guess I'll just have to get new data to verify this. It seems just too
> >odd.
> >
> >Jens
> >
> >On Mon, Apr 03, 2006 at 10:48:32AM -0400, Robert McGwier wrote:
> >  
> >>Jens:
> >>
> >>This  pi/4-DQPSK.   That means
> >>
> >>New-symbol  *  (complex conjugate (Old-symbol)) is   pi/4 modulo pi/2.  
> >>Are you taking this into account on both the transmitter and the 
> >>receiver and it in all of the bins before your inverse fft provides the 
> >>time domain signal to transmit would be my best best.
> >>
> >>I will look at it more carefully today if I have time but this question 
> >>would be the first one I would ask the code to tell me.
> >>
> >>Bob
> >>
> >>
> >>
> >>Jens Elsner wrote:
> >>
> >>>Here is my little problem in animated frames.
> >>>
> >>>What you are seeing is already DQPSK. Displayed is the signal
> >>>constellation for one OFDM frame, 75 symbols. The code was posted 
> >>>earlier.
> >>>
> >>>The problem: The (differential!) signal constellation has a constant 
> >>>phase offset for each OFDM symbol. Why? What to do about it?
> >>>
> >>>Jens
> >>> 
> >>>  
> >>-- 
> >>AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
> >>NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
> >>Laziness is the number one inspiration for ingenuity.  Guilty as charged!
> >>
> >>
> >
> >  
> 
> 
> -- 
> AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
> NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
> Laziness is the number one inspiration for ingenuity.  Guilty as charged!
> 


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-03 Thread Jens Elsner
Bob, thanks for the reply.

This is exactly what I am doing:

[...]
dem = data ./ data_l;
[...]

A point-wise division by the last OFDM symbol. This also restores
amplitude, but has the same effect on the phase.

I do not control the receiver, my data is from a radio station. I am
only trying to demodulate. I am synchronised in the 
frequency domain. Time domain synch is also appropriate.

I guess I'll just have to get new data to verify this. It seems just too
odd.

Jens

On Mon, Apr 03, 2006 at 10:48:32AM -0400, Robert McGwier wrote:
> Jens:
> 
> This  pi/4-DQPSK.   That means
> 
> New-symbol  *  (complex conjugate (Old-symbol)) is   pi/4 modulo pi/2.  
> Are you taking this into account on both the transmitter and the 
> receiver and it in all of the bins before your inverse fft provides the 
> time domain signal to transmit would be my best best.
> 
> I will look at it more carefully today if I have time but this question 
> would be the first one I would ask the code to tell me.
> 
> Bob
> 
> 
> 
> Jens Elsner wrote:
> >Here is my little problem in animated frames.
> >
> >What you are seeing is already DQPSK. Displayed is the signal
> >constellation for one OFDM frame, 75 symbols. The code was posted earlier.
> >
> >The problem: The (differential!) signal constellation has a constant phase 
> >offset for each OFDM symbol. Why? What to do about it?
> >
> >Jens
> >  
> 
> -- 
> AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
> NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
> Laziness is the number one inspiration for ingenuity.  Guilty as charged!
> 


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


Re: [Discuss-gnuradio] OFDM demodulation problem / example video

2006-04-03 Thread Robert McGwier

Jens:

This  pi/4-DQPSK.   That means

New-symbol  *  (complex conjugate (Old-symbol)) is   pi/4 modulo pi/2.  
Are you taking this into account on both the transmitter and the 
receiver and it in all of the bins before your inverse fft provides the 
time domain signal to transmit would be my best best.


I will look at it more carefully today if I have time but this question 
would be the first one I would ask the code to tell me.


Bob



Jens Elsner wrote:

Here is my little problem in animated frames.

What you are seeing is already DQPSK. Displayed is the signal
constellation for one OFDM frame, 75 symbols. The code was posted earlier.

The problem: The (differential!) signal constellation has a constant phase 
offset for each OFDM symbol. Why? What to do about it?


Jens
  


--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!



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


Re: [Discuss-gnuradio] OFDM / DAB demodulation

2006-04-03 Thread Jens Elsner
Hi Clark,

thanks for trying out my code. The problem is that what you are seeing
is *already* DQPSK. 

The pilot is accounted for, it is the first symbol in every frame.

Demodulating might make sense, but I guess the BER is still way too high
to compensate it with channel coding. There has to be some kind of
reasonable explanation for the phenomenon we are seeing...

For those of you working with real OFDM data: What could be the cause of a 
"phase jitter", even after differential demodulation?

Jens

On Sun, Apr 02, 2006 at 10:01:29AM -0400, Clark Pope wrote:
> Tried your matlab code. Looks like fine QPSK symbols to me. The absolute 
> phase reference is not zero but that should not affect DQPSK demodulation 
> since the last symbol is the phase reference for the current symbol.
> 
> Maybe you need to adjust phase based on pilot bins?
> 
> I would proceed to demodulating the bins to see if the data you recover 
> makes sense. There must be some regular structure to the data stream that 
> you can identify.
> 
> -Clark
> 
> >From: Jens Elsner <[EMAIL PROTECTED]>
> >To: discuss-gnuradio@gnu.org
> >Subject: Re: [Discuss-gnuradio] OFDM / DAB demodulation
> >Date: Sat, 1 Apr 2006 18:30:33 +0200
> >
> >You are absolutely right - the matlab code is attached.
> >You can get my sample data (local radio station, 3 MBytes) from
> >http://www.1c3.de/dab_ml.dat.bz2.
> >
> >Jens
> >
> >On Sat, Apr 01, 2006 at 10:27:57AM -0500, Robert McGwier wrote:
> >> Why don't you allow us to provide you with help based on the reality as
> >> opposed to conjecture.  Post your matlab scripts.  This "remote viewing"
> >> exercise is inefficient.
> >>
> >>
> >> Bob
> >>
> >>
> >>
> >> Jens Elsner wrote:
> >> >I resampled all the data to do a proof-of-concept. The frames are only 
> >a
> >> >small part
> >> >of the "chunk" variable. What I am getting is a fairly nice pi/4 DPSK.
> >> >Only that
> >> >in between OFDM Symbols (there are 76 in a frame) there is some sort of
> >> >random
> >> >phase jitter. And I am clueless what it could be. Frequency offset is
> >> >compensated,
> >> >the channel doesnt vary that fast.
> >> >
> >> >Jens
> >> >
> >> >
> >>
> >>
> >> --
> >> AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
> >> NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
> >> Laziness is the number one inspiration for ingenuity.  Guilty as 
> >charged!
> >>
> 
> 
> ><< dabtest_ml.m >>
> 
> 
> ><< prs.m >>
> 
> 
> >___
> >Discuss-gnuradio mailing list
> >Discuss-gnuradio@gnu.org
> >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> _
> Express yourself instantly with MSN Messenger! Download today - it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 


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


Re: [Discuss-gnuradio] OFDM / DAB demodulation

2006-04-02 Thread Clark Pope
Tried your matlab code. Looks like fine QPSK symbols to me. The absolute 
phase reference is not zero but that should not affect DQPSK demodulation 
since the last symbol is the phase reference for the current symbol.


Maybe you need to adjust phase based on pilot bins?

I would proceed to demodulating the bins to see if the data you recover 
makes sense. There must be some regular structure to the data stream that 
you can identify.


-Clark


From: Jens Elsner <[EMAIL PROTECTED]>
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] OFDM / DAB demodulation
Date: Sat, 1 Apr 2006 18:30:33 +0200

You are absolutely right - the matlab code is attached.
You can get my sample data (local radio station, 3 MBytes) from
http://www.1c3.de/dab_ml.dat.bz2.

Jens

On Sat, Apr 01, 2006 at 10:27:57AM -0500, Robert McGwier wrote:
> Why don't you allow us to provide you with help based on the reality as
> opposed to conjecture.  Post your matlab scripts.  This "remote viewing"
> exercise is inefficient.
>
>
> Bob
>
>
>
> Jens Elsner wrote:
> >I resampled all the data to do a proof-of-concept. The frames are only 
a

> >small part
> >of the "chunk" variable. What I am getting is a fairly nice pi/4 DPSK.
> >Only that
> >in between OFDM Symbols (there are 76 in a frame) there is some sort of
> >random
> >phase jitter. And I am clueless what it could be. Frequency offset is
> >compensated,
> >the channel doesnt vary that fast.
> >
> >Jens
> >
> >
>
>
> --
> AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
> NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
> Laziness is the number one inspiration for ingenuity.  Guilty as 
charged!

>




<< dabtest_ml.m >>




<< prs.m >>




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


_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/




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


Re: [Discuss-gnuradio] OFDM / DAB demodulation

2006-04-01 Thread Jens Elsner
On Sat, Apr 01, 2006 at 01:59:09PM -0800, Matt Ettus wrote:
> Jens Elsner wrote:
> > I resampled all the data to do a proof-of-concept. The frames are
> > only a small part of the "chunk" variable. What I am getting is a
> > fairly nice pi/4 DPSK. Only that in between OFDM Symbols (there are
> > 76 in a frame) there is some sort of random phase jitter. And I am
> > clueless what it could be. Frequency offset is compensated, the
> > channel doesnt vary that fast.
> 
> I'm confused.  Are you seeing:
> 
> good symbol -- jitter -- good symbol -- jitter -- good symbol
> 
> or
> 
> good symbol 76 times and then jitter
> 
> ?
> 
> Are you accounting for the cyclic prefix?  I assume that COFDM has one.

I am seeing only good symbols, but with a random phase offset (up to pi/8). 
The prefix is accounted for. If I do not account for it correctly this
results in ISI. Looks like added noise, not like the effect I'm seeing.

Jens


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


Re: [Discuss-gnuradio] OFDM / DAB demodulation

2006-04-01 Thread Matt Ettus
Jens Elsner wrote:
> I resampled all the data to do a proof-of-concept. The frames are
> only a small part of the "chunk" variable. What I am getting is a
> fairly nice pi/4 DPSK. Only that in between OFDM Symbols (there are
> 76 in a frame) there is some sort of random phase jitter. And I am
> clueless what it could be. Frequency offset is compensated, the
> channel doesnt vary that fast.

I'm confused.  Are you seeing:

good symbol -- jitter -- good symbol -- jitter -- good symbol

or

good symbol 76 times and then jitter

?

Are you accounting for the cyclic prefix?  I assume that COFDM has one.

Matt


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


Re: [Discuss-gnuradio] OFDM / DAB demodulation

2006-04-01 Thread Matt Ettus
Charles Swiger wrote:
> On Sat, 2006-04-01 at 10:53 +0200, Jens Elsner wrote:
>> Well - you can download the standard at ETSI. It's open and published.
>> I don't know about the US.
>>
> 
> Ok - last time I asked about the US hdradio standard I got the
> impression that the lower levels of the stack were for licensee
> eyes only. 
> 

I've downloaded the iBOC standards (both AM and FM) and they seem to be
pretty detailed on the physical layer.  They don't mention the codec at
all, though.  It would be interesting to demod it to the point of
getting the bitstream out, for 2 reasons:  eventually there will be a
[probably non-free] software version of their codec, and there are data
portions of the stream which are not from the codec.

Matt



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


Re: [Discuss-gnuradio] OFDM / DAB demodulation

2006-04-01 Thread Jens Elsner
You are absolutely right - the matlab code is attached.
You can get my sample data (local radio station, 3 MBytes) from
http://www.1c3.de/dab_ml.dat.bz2.

Jens

On Sat, Apr 01, 2006 at 10:27:57AM -0500, Robert McGwier wrote:
> Why don't you allow us to provide you with help based on the reality as 
> opposed to conjecture.  Post your matlab scripts.  This "remote viewing" 
> exercise is inefficient.
> 
> 
> Bob
> 
> 
> 
> Jens Elsner wrote:
> >I resampled all the data to do a proof-of-concept. The frames are only a
> >small part
> >of the "chunk" variable. What I am getting is a fairly nice pi/4 DPSK.
> >Only that
> >in between OFDM Symbols (there are 76 in a frame) there is some sort of
> >random
> >phase jitter. And I am clueless what it could be. Frequency offset is
> >compensated,
> >the channel doesnt vary that fast.
> >
> >Jens
> >
> >  
> 
> 
> -- 
> AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
> NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
> Laziness is the number one inspiration for ingenuity.  Guilty as charged!
> 
clear all;
close all;

% dab.dat contains data sampled from the USRP 2 MHz (decimation factor 32)

fid = fopen('dab_ml.dat', 'r');
%skip 5 samples - bug in gnuradio?
d = fread(fid, 5, 'float32');

%read real
d_re = fread(fid, 100, 'float32',4);
fclose(fid);

fid = fopen('dab_ml.dat', 'r');
%skip 50001 samples - bug in gnuradio?
d = fread(fid, 50001, 'float32');

%read imag
d_im = fread(fid, 100, 'float32', 4);
fclose(fid);

e = d_re + j*d_im;
clear d*

% not all data need, file too big
chunk = e(1:70);

% Generate phase reference symbol, frequency domain
p = prs;

% resampling
chunk_resamp = resample(chunk, 2048, 2000);

% this code is used to look for the synch frame manually
if 1==0

glob_max = 0;
for k = 3.6*10^5:length(chunk_resamp)
data = chunk_resamp(k:k+2048);
f = fftshift(fft(data,2048));

xc = abs(xcorr(p,f));

[m offset] = max(xc);
if m > 10^7
disp('found synch frame');
plot(xc);
axis([0 4000 0 2*10^7]);
drawnow
pause
k
end
if m > glob_max
offset_max = offset
glob_max = m
glob_max_k = k
plot(xc);
axis([0 4000 0 2*10^7]);
drawnow
%pause
end
drawnow
end

end

% decode one frame (75 symbols + synch symbol)
for o = 0:75

% start of frame, found manually
start_resamp = 168988;

%get the data for one OFDM symbol (2048 samples), skip guard intervall (504
%samples)
data_resamp = 
chunk_resamp(start_resamp+(504+2048)*o:start_resamp+2048-1+(504+2048)*o);

% compensate frequency offset - done manually
data2_resamp = 
data_resamp.*exp(j*linspace(0,2*pi*(0.385-8),length(data_resamp)).');

% fft to decode data
d_resamp = fftshift(fft(data2_resamp,2048));

% only 1536 subcarriers + DC carrier to display
data = d_resamp(256:1792);

% first OFDM symbol is used for synchronization - no data.
if o == 0
plot(abs(d_resamp).^2);
drawnow
pause
end

% display decoded data symbols, including DC carrier
if o ~= 0
dem = data ./ data_l;

plot(real(dem), imag(dem), 'o');   
axis([-3 3 -3 3]);

drawnow
   
pause
end

% DAB uses pi/4 DPSK, last frame is reference
data_l = data;


end

function z = prs

% Generate phase reference symbol

%DAB standard, table 39, pp. 148
K = 1536;

% k = k', i, n
t39 = zeros(1536,3);
o = K/2+1;

for k = -768:-737
t39(k+o:k+o,:,:) = [-768,0,1];
end

for k = -736:-705
t39(k+o:k+o,:,:) = [-736,1,2];
end

for k = -704:-673
t39(k+o:k+o,:,:) = [-704,2,0];
end

for k = -672:-641
t39(k+o:k+o,:,:) = [-672,3,1];
end

for k = -640:-609
t39(k+o:k+o,:,:) = [-640,0,3];
end

for k = -608:-577
t39(k+o:k+o,:,:) = [-608,1,2];
end

for k = -576:-545
t39(k+o:k+o,:,:) = [-576,2,2];
end

for k = -544:-513
t39(k+o:k+o,:,:) = [-544,3,3];
end

for k = -512:-481
t39(k+o:k+o,:,:) = [-512,0,2];
end

for k = -480:-449
t39(k+o:k+o,:,:) = [-480,1,1];
end

for k = -448:-417
t39(k+o:k+o,:,:) = [-448,2,2];
end

for k = -416:-385
t39(k+o:k+o,:,:) = [-416,3,3];
end

for k = -384:-353
t39(k+o:k+o,:,:) = [-384,0,1];
end

for k = -352:-321
t39(k+o:k+o,:,:) = [-352,1,2];
end

for k = -320:-289
t39(k+o:k+o,:,:) = [-320,2,3];
end

for k = -288:-257
t39(k+o:k+o,:,:) = [-288,3,3];
end

for k = -256:-225
t39(k+o:k+o,:,:) = [-256,0,2];
end

for k = -224:-193
t39(k+o:k+o,:,:) = [-224,1,2];
end

for k = -192:-161
t39(k+o:k+o,:,:) = [-192,2,2];
end

for k = -160:-129
t39(k+o:k+o,:,:) = [-160,3,1];
end

for k = -128:-97
t39(k+o:k+o,:,:) = [-128,0,1];
end

for k = -96:-65
t39(k+o:k+o,:,:) = [-96,1,3];
end

for k = -64:-33
t39(k+o:k+o,:,:) = [-64,2,1];
end

for k = -32:-1
t39(k+o:k+o,:,:) = [-32,3,2];
end

for k = 0:0
t39(k+o:k+o,:,:) = [0, 0, 0];
end

for k = 1:32
t39(k+o:k+o,:,:) = [1,0,3];
end

for k = 33:64
t39(k+o:k+o,:,:) = [33,3,1];
end

for k = 65:96
t39(k+o:k+o,:,:) =

Re: [Discuss-gnuradio] OFDM / DAB demodulation

2006-04-01 Thread Jens Elsner
Forgot to answer your questions:
The subcarrier spacing is 1 KHz, 1536+DC Carrier (unused) = 1.537 MHz
I sampled 2 MHz (USRP, dec 32). Then I sampled up to 2.048 MHz since
1/2.048MHz is the basic timing unit in the standard.

I tried again without resampling - the random phase jitter is still
there. Plus the
timing problem - the standard requires 2.048 MHz to I get decimal offset
values.
For example at the 2.000 MHz the guard intervall has the length 492.1875.

Do you think downsampling will work better than upsampling? I'll try that
tomorrow.

3/31/2006, "Clark Pope" <[EMAIL PROTECTED]> вы писали:

>I would doubt that unless your USRP is defective. The phase noise should
>only become a major factor at baud rates below about 10 kbaud.
>
>What's the actual bandwidth of the DAB signal? Did you try collecting at 4
>MSPS and then downsampling to the FFT sample rate? Maybe the CIC or
>compensation filter transition are distorting the final result.
>
>-Clark
>
>>From: Jens Elsner <[EMAIL PROTECTED]>
>>To: discuss-gnuradio@gnu.org
>>Subject: Re: [Discuss-gnuradio] OFDM / DAB demodulation
>>Date: Fri, 31 Mar 2006 19:28:38 +0200
>>
>>After some thinking: Could this be phase noise? If it is, which
>>oscillator is at fault? The TVRX frontend? The max. phase jitter equals
>>roughly 100 Hz.
>>
>>On Fri, Mar 31, 2006 at 05:08:54PM +0200, Jens Elsner wrote:
>> > Good morning,
>> >
>> > I sampled a local DAB radio station at 225.648 MHz, decimation factor 32
>> > with the USRP/tvrx.
>> >
>> > DAB is using COFDM with pi/4-DPSK on 1536 subcarriers (see www.etsi.com,
>>standard
>> > EN300401 for details). I wrote some Matlab code to demodulate the
>> > signal. The data is resampled from 2 MHz (URSP) to 2.048 MHz (DAB
>>Standard).
>> > A frequency offset is compensated manually.
>> >
>> > It works so far, only one problem arises: The I/Q signal diagram jumps
>> > and jitters randomly by up to pi/8. What could be the problem? I am
>> > absolutely clueless - the frequency offset is compensated perfectly.
>> >
>> > My ultimate goal is to implement OFDM de/modulation and a DAB receiver
>> > in gnuradio.
>> >
>> > Greetings,
>> > Jens
>> >
>> >
>> >
>> > ___
>> > 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
>
>_
>Is your PC infected? Get a FREE online computer virus scan from McAfee®
>Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>


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


<    1   2   3   4   5   6   7   >