[Discuss-gnuradio] Standalone USRP2

[Yongsang Kim]

We want to make several standalone transmitters which transmit OFDM
signals synchronized with 1pps signal and external 10MHz closk using
USRP2.

We want to implement the transmitters using FPGA, while daughter board
parameters and interpolation rate are fixed.

We will transmit "frames" which consist of preamble and fixed many data
OFDM symbols.

We want to ask following questions about above.

1. Where does the "making frame block" connect with?

2. What block may be deleted for elmenating corresponding GNU radio
block?

3. How do we modify the FPGA and/or firmware for fixing parameters
(interpolation rate, center frequency, etc.)

4. We may have to eliminate receiving buffer cause of shortage of
memory.
   How can we delete it?

5. If exists, please send us the whole system block diagram.


Thanks.
-- 
Posted via http://www.ruby-forum.com/.


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

[Discuss-gnuradio] generate 0s and 1s

[yufeng wang]

Hi, all,

Can anyone tell me which function in Python could I use to generate a
fixed length of 0s and 1s? I know in matlab we could just use
randsrc(x, y, 0:1), while I've no idea how to implement it in Python.
Thanks for ur help!


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

Re: [Discuss-gnuradio] generate 0s and 1s

[Ed Criscuolo]

yufeng wang wrote:

Can anyone tell me which function in Python could I use to generate a
fixed length of 0s and 1s? I know in matlab we could just use
randsrc(x, y, 0:1), while I've no idea how to implement it in Python.
Thanks for ur help!


Look at the linear shift feedback register (gr_lfsr_32k_source_s) block.
It should do what you want.

@(^.^)@  Ed







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

[Discuss-gnuradio] UDP do not work correctly

[feldmaus]

 Hi Gnuradio People, :-)

I tried to get the  and  to work.
But it didn't work as it should. The FFT Plots only
shows a white screen. The CPU of my Work PC is under
100% and my Server PC too. Should this be a Problem of
 ?
I have a network traffic between the connected pc's with
about 300Kbyte/s.

Do you have any hints for me?

Specification:
Work PC:
+ IP 194.94.26.158
+ Firewall with open UDP Port 13130:13133

Server PC:
+ IP 192.168.111.67
+ Firewall with open UDP Port 13130:13133

The Firewall was tested with .

So i created a Flow Graph:
###
###SERVER PC###
[SIN Source]--\/-->[USRP Sink]
  +-->+
[COS SOURCE]--/\-->[UDP Sink 1]

SETTINGS for UDP Sink 1:
  Local IP Address: 192.168.111.67
  Port: 13130
  Remote IP Address: 194.94.26.158
  Port: 13132


[USRP Source]-->[UDP SINK 2]

SETTINGS for UDP Sink 1:
  Local IP Address: 192.168.111.67
  Port: 13131
  Remote IP Address: 194.94.26.158
  Port: 13133




###WORK PC###
[UDP Source1]-->[FFT Plot TX]

SETTINGS for UDP Source1:
  IP Address: 194.94.26.158
  Port: 13132

[UDP Source2]-->[FFT Plot RX]

SETTINGS for UDP Source2:
  IP Address: 194.94.26.158
  Port: 13133
###

Regards Markus



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

[Discuss-gnuradio] change variables in the FFT Plot

[feldmaus]

Hi All again, :-)

i tried to change the Y/Div value with a slider, but this
do not work.
So how can i change the Variables of the FFT-Plot Sink
during execution?
Is there a possibility to change the x/Div ?

Regards Markus



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

Re: [Discuss-gnuradio] UDP do not work correctly

[Jason Uher]

> Do you have any hints for me?


Unless I am misunderstanding your diagram, I think you need something
to slow down rate of the cosine source ([COS SOURCE]--/\-->[UDP
Sink 1]).  If you connect it to a non-rate limited sink it will just
pump out samples as fast as it can, hence your 100% CPU usage.

Try a  gr.throttle() in between.


Jason


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

[Discuss-gnuradio] Congratulations Tom

[Robert McGwier]

http://www.vtnews.vt.edu/story.php?relyear=2009&itemno=83


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

Re: [Discuss-gnuradio] Congratulations Tom

[Marcus D. Leech]

Robert McGwier wrote:
> http://www.vtnews.vt.edu/story.php?relyear=2009&itemno=83
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>   
Way to go, Tom.

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



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

Re: [Discuss-gnuradio] Filterbank stuff

[Marcus D. Leech]

Frank Brickle wrote:
> On Thu, Feb 12, 2009 at 7:59 PM, Marcus D. Leech  > wrote:
>  
>
> I'm looking into this for a friend who wants to use his USRP2 for EME.
> I'll see if I can do something JT65-like (or exactly that!)
>  in Gnu Radio.
>
>
> You should be able to just use it via portaudio on top of JACK,
> talking to the USRP through GNU Radio. There may be some sample rate
> issues that need to be solved in GNU Radio -- last time I looked, WSJT
> only pretended to handle variable sample rates.
>
> Frank
>
>
> -- 
> ...we ain't going to hell, we're going to the rebel side of heaven. --
> Langhorne Slim
>
So, just feed the audio as if it's a baseband signal right into the
USRP?   Or do I need to put it through an SSB modulator
  first?

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



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

[Discuss-gnuradio] Re: generate 0s and 1s

[Patrick Strasser]

yufeng wang wrote am 2009-02-13 14:34:

Hi, all,

Can anyone tell me which function in Python could I use to generate a
fixed length of 0s and 1s? I know in matlab we could just use
randsrc(x, y, 0:1), while I've no idea how to implement it in Python.
Thanks for ur help!


If you want to have random sources in GNU Radio, you can use various 
sources, like a noise source or a LSFR source[2].


One method for a fixed length:

import random
length = 10
rand_sequence = random.sample(length/2*[1]+length/2*[0],length)

This first generates a list of 1s and 0s and permutates them. You can 
vary the length/2-part to get a not-even-distribution.

Or:
rand_sequence = [x%2 for x in random.sample(xrange(1000), length)]

These may not be the most efficient or random one, but it should do for 
a first shot. For really long sequences yu should construct a sequence 
from a random source with multiple invocations, like multiple 
random.choice([0,1]) if you need reproducible numbers, or 
random.SystemRandom([0,1]) to get good non-reproducible numbers. Read 
all about random numbers and Python in [0]


If you are unfamiliar with Python, just read the Python Tutorial[1], 
it's really great.


Patrick

[0] http://docs.python.org/library/random.html
[1] http://docs.python.org/tutorial/
[2] http://www.gnuradio.org/doc/doxygen/group__source.html

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



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

Re: [Discuss-gnuradio] change variables in the FFT Plot

[Josh Blum]

The y per div is controlled by the dB/div radio buttons to the right of 
the fft plot.


For the X axis, the max and min are set by the sample rate, and the 
number of tick marks are set by x_divs... the x_per_div setting is 
derived from this.


See http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl

I cant tell if you are using the gl or non gl fft sink, but I believe 
the non gl sink ignores settings for xdivs.



feldmaus wrote:

Hi All again, :-)

i tried to change the Y/Div value with a slider, but this
do not work.
So how can i change the Variables of the FFT-Plot Sink
during execution?
Is there a possibility to change the x/Div ?


Are you using GRC?
-josh


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

[Discuss-gnuradio] a real world testing using USRP in a free space environment, need help on some questions

[Bill Stevenson]

Hello, all!

Our team is trying to find out the relationship between PER and Received Signal 
Strength as well as the relationship between Distance and Received Signal 
Strength under DBPSK modulation scheme using two USRP borads. Our test was set 
up in a near free space environment, but the result was counterintuitive. Below 
lists the result from our test: PER = [7.602%, 0.583%, 0.2317%, 1.095%]; RSSI = 
[928.7573, 1296.6, 2386.2, 2587.7] which is the value of 
tb.rxpath.probe.level(); distance = [260,240,220,200]. There are two things 
confusing me. As can be seen, from 240feet to 220feet, the rssi was almost 
doubled, but the PERs were almost the same. For the same 20feet difference in 
distance, the PER declined from 7% to 0.5% while the rssi was only increased by 
300. Why is there a huge jump in RSSI when distance changed from 240 to 220 
compared with the case when distance decreased from 260 to 240, meanwhile the 
improvement of PER is not obvious? Why is there a huge
 plunge in PER when RSSI was increased only by 300 and distance was changed 
from 260feet to 240 feet? Is there any theshold or restriction in the USRP 
board? Could anyone tell me the reason for our problems? Thanks a lot!!!

Tianning



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

Re: [Discuss-gnuradio] Filterbank stuff

[Frank Brickle]

On Fri, Feb 13, 2009 at 10:28 AM, Marcus D. Leech  wrote:


> So, just feed the audio as if it's a baseband signal right into the
> USRP?   Or do I need to put it through an SSB modulator
>  first?


You'll want to modulate it. WSJT gives real output. Of course "modulating"
here means not much more than complexifying and filtering, since WSJT will
do the tuning on its own.

BTW if sample rates do turn out to be an issue with JACK, you can always use
the dummy driver simply for connecting your GR program and WSJT. Dummy will
take whatever sample rate you tell it, within reason. You can't monitor the
signal by ear that way, but in this case, big deal.

Frank


-- 
...we ain't going to hell, we're going to the rebel side of heaven. --
Langhorne Slim
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] USRP2 PPS and REF

[Douglas Geiger]

 Ok - so I have packets coming in from both USRP2's now, getting dumped
to their separate files.
 My app prints out the timestamp of each frame that gets sent to the
copy handler: if my 1PPS source is working properly, should the
timestamps coming out of the two USRP2's be identical?
 Another question: no matter what, there is going to be some time delay
between when I tell one USRP2 to start, and when I tell the other one to
start: with the timestamps I could do something like
align_on_samplenumbers (but with the timestamps - at least I could do
this in the copy handler where I have access to this information). Of
course this requires that the timestamps do end up being based on the
1PPS. Should I take that as a sign my USRP2's are not currently getting
sync'd to the 1PPS?
 Thanks,
 Doug

-- 
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.gei...@okstate.edu
doug.gei...@ieee.org


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

RE: [Discuss-gnuradio] USRP2 PPS and REF

[Newman, Timothy]

Couldn't you just tell the USRP's to start at a specific time to get
them to start in sync?  Rather than in real-time telling them to start
immediately and having that lag.

Tim

---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


> -Original Message-
> From: discuss-gnuradio-bounces+trnewman=vt@gnu.org
[mailto:discuss-gnuradio-
> bounces+trnewman=vt@gnu.org] On Behalf Of Douglas Geiger
> Sent: Friday, February 13, 2009 2:02 PM
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] USRP2 PPS and REF
> 
> 
>  Ok - so I have packets coming in from both USRP2's now, getting
dumped
> to their separate files.
>  My app prints out the timestamp of each frame that gets sent to the
> copy handler: if my 1PPS source is working properly, should the
> timestamps coming out of the two USRP2's be identical?
>  Another question: no matter what, there is going to be some time
delay
> between when I tell one USRP2 to start, and when I tell the other one
to
> start: with the timestamps I could do something like
> align_on_samplenumbers (but with the timestamps - at least I could do
> this in the copy handler where I have access to this information). Of
> course this requires that the timestamps do end up being based on the
> 1PPS. Should I take that as a sign my USRP2's are not currently
getting
> sync'd to the 1PPS?
>  Thanks,
>  Doug
> 
> --
> Doug Geiger
> Research Assistant
> Communications and Signal Processing Lab
> Oklahoma State University
> http://cspl.okstate.edu
> douglas.gei...@okstate.edu
> doug.gei...@ieee.org
> 
> 
> ___
> 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] USRP2 PPS and REF

[Matt Ettus]

Newman, Timothy wrote:

Couldn't you just tell the USRP's to start at a specific time to get
them to start in sync?  Rather than in real-time telling them to start
immediately and having that lag.




Yes, you need to use the "receive at" functionality.  The call to 
receive on the host side takes a control struct which contains this info.


Matt


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

RE: [Discuss-gnuradio] USRP2 PPS and REF

[Suprin, Charles E.]

Doug,

Working only on my single channel setup, what appears to happen is that there 
is the time stamp for the first sample in the frame. The frame alignment seems 
to remain a function of when the device was turned on.

Now if sync_every_pps worked with the 31 December 2008 firmware.  I think I 
need to wait for a newer FPGA/VHDL firmware release for that to happen.

Charles


-Original Message-
From: discuss-gnuradio-bounces+csuprin=mitre@gnu.org 
[mailto:discuss-gnuradio-bounces+csuprin=mitre@gnu.org] On Behalf Of 
Douglas Geiger
Sent: Friday, February 13, 2009 2:02 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP2 PPS and REF

 Ok - so I have packets coming in from both USRP2's now, getting dumped
to their separate files.
 My app prints out the timestamp of each frame that gets sent to the
copy handler: if my 1PPS source is working properly, should the
timestamps coming out of the two USRP2's be identical?
 Another question: no matter what, there is going to be some time delay
between when I tell one USRP2 to start, and when I tell the other one to
start: with the timestamps I could do something like
align_on_samplenumbers (but with the timestamps - at least I could do
this in the copy handler where I have access to this information). Of
course this requires that the timestamps do end up being based on the
1PPS. Should I take that as a sign my USRP2's are not currently getting
sync'd to the 1PPS?
 Thanks,
 Doug

-- 
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.gei...@okstate.edu
doug.gei...@ieee.org


___
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] USRP2 PPS and REF

[Matt Ettus]

Suprin, Charles E. wrote:

Doug,

Working only on my single channel setup, what appears to happen is
that there is the time stamp for the first sample in the frame. The
frame alignment seems to remain a function of when the device was
turned on.



NO.  Frame alignment is under explicit control from the host, as long as 
you do a "receive at" request.  That will allow you to specify EXACTLY 
when you want your samples.  If you do a "receive now" request, which is 
what you're doing, you'll get samples starting right away, which will be 
a function of host computer latency.



Now if sync_every_pps worked with the 31 December 2008 firmware.  I
think I need to wait for a newer FPGA/VHDL firmware release for that
to happen.



Honestly, sync_every_pps is a hack and I don't know why you would want 
it.  It causes you to not know what second it is, since the clock is 
reset every second.


The normal "sync at next pps" makes more sense.  Since all the 
oscillators are locked, you only need to sync once, and everyone will 
remain in sync forever.


Matt


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

RE: [Discuss-gnuradio] USRP2 PPS and REF

[Suprin, Charles E.]

Matt,

I had not seen your other post before I responded to the first one.  

How do you do a "receive at"?  Looking at 
usrp2/host/apps/include/usrp2/usrp2.h, the only function I see is 
start_rx_streaming which does not have a timestamp in it.

As for the sync_every_pps, if one is running two setup, physically separate, 
then the timestamps of the same time will agree if they both reset on separate 
GPS generated PPS's.  That way if one reboots or restarts the application, the 
time ambiguity is in units of seconds which can generally resolved with a NTP 
on the host computer.  

If I am missing something that could solve this more easily, let me know.

Charles


-Original Message-
From: Matt Ettus [mailto:m...@ettus.com] 
Sent: Friday, February 13, 2009 2:52 PM
To: Suprin, Charles E.
Cc: Douglas Geiger; discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] USRP2 PPS and REF

Suprin, Charles E. wrote:
> Doug,
> 
> Working only on my single channel setup, what appears to happen is
> that there is the time stamp for the first sample in the frame. The
> frame alignment seems to remain a function of when the device was
> turned on.


NO.  Frame alignment is under explicit control from the host, as long as 
you do a "receive at" request.  That will allow you to specify EXACTLY 
when you want your samples.  If you do a "receive now" request, which is 
what you're doing, you'll get samples starting right away, which will be 
a function of host computer latency.

> Now if sync_every_pps worked with the 31 December 2008 firmware.  I
> think I need to wait for a newer FPGA/VHDL firmware release for that
> to happen.


Honestly, sync_every_pps is a hack and I don't know why you would want 
it.  It causes you to not know what second it is, since the clock is 
reset every second.

The normal "sync at next pps" makes more sense.  Since all the 
oscillators are locked, you only need to sync once, and everyone will 
remain in sync forever.

Matt


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

Re: [Discuss-gnuradio] USRP2 PPS and REF

[Douglas Geiger]

Suprin, Charles E. wrote:
> Matt,
> 
> I had not seen your other post before I responded to the first one.  
> 
> How do you do a "receive at"?  Looking at 
> usrp2/host/apps/include/usrp2/usrp2.h, the only function I see is 
> start_rx_streaming which does not have a timestamp in it.
> 
> As for the sync_every_pps, if one is running two setup, physically separate, 
> then the timestamps of the same time will agree if they both reset on 
> separate GPS generated PPS's.  That way if one reboots or restarts the 
> application, the time ambiguity is in units of seconds which can generally 
> resolved with a NTP on the host computer.  
> 
> If I am missing something that could solve this more easily, let me know.
> 
> Charles
> 


 Johnathan mentioned the "receive at" call to me as well - and I see
there is a ticket #341 for USRP2 send-at and receive-at. So this is
something that is still in-development? Looks like it will be coming
with the new message passing architecture.
 Doug

-- 
Doug Geiger
Research Assistant
Communications and Signal Processing Lab
Oklahoma State University
http://cspl.okstate.edu
douglas.gei...@okstate.edu
doug.gei...@ieee.org


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

RE: [Discuss-gnuradio] Measuring SNR

[Tachwali, Yahia]

Hello Swapna,

The SNR in wireless channel cannot be measured but it can be "estimated". One 
way to do that for constant envelope modulation such as PSK is by measuring the 
variance in the received signal envelope. Ideally you should receive a constant 
stable envelope of your signal. However, due to the noise in the channel 
(assuming WGN channel, which is normally the assumption for the famous 
theoretical waterfall plots for BER vs SNR) you can find a relation between the 
variance in the envelope and SNR.

To get the exact relation I suggest you to look at the last chapter of

Optical Bit Error Rate: An Estimation Methodology by 
Stamatios
 V. 
Kartalopoulos

I hope that helps. Good luck!

Kind regards,
Yahia Tachwali

From: discuss-gnuradio-bounces+ytachwali=ou@gnu.org 
[discuss-gnuradio-bounces+ytachwali=ou@gnu.org] On Behalf Of Swapna Raj 
[swapna.ra...@gmail.com]
Sent: Thursday, February 12, 2009 8:57 AM
To: Discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] Measuring SNR

Hi,

I am trying to implement a particular channel coding technique as part of my 
work(Master's Thesis). I need to test this technique in a fading channel. But 
since I have no control over the channel I cannot quantify channel condition.I 
need SNR to analyze the performance of the coding technique.The only solution i 
thought was to inject noise at source and ensure that transmission.But this is 
more like a simulation. I would like to know if there are better ways to do 
this.


My second question is more related to Python programming. I need to run a 
series of scripts one after the other in my work.Though these scripts work fine 
independently. I get an error when I use os.popen(). In most cases I do not 
want the control to return back to the calling script.Could any one suggest 
what is the best way to do this, or atleast a reference?


Thanks
Swapna

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