[Discuss-gnuradio] Can we use any sampling rate in tunnel.py or benchmark_tx.py

[Mir Ali]

Hi friends,

This question may sound stupid but I cannot really know if I am thinking
right or wrong.

Can I set the sampling rate of tunnel or benchmark_tx to be anything (of
course to those supported by the system) as I think as far as the data rate
of USB is maintained I should be able to do that. Isn't it?

If yes, then can I just use the "-S samplingrate" option while running the
program or is there anything more that I need to consider.

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

[Discuss-gnuradio] [matej.kova...@owca.info: [airprobe-main] Ofono]

[Eric Blossom]

FYI,

Eric
--- Begin Message ---
Hi,

just for information, if someone is interested: http://ofono.org/

bye, Matej

-
To unsubscribe, e-mail: main-unsubscr...@lists.airprobe.org
For additional commands, e-mail: main-h...@lists.airprobe.org

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

[Discuss-gnuradio] Re: Syncrinization of two USRP2s

[Changkyu Seol]

Johnathan Corgan wrote:
> On Thu, May 14, 2009 at 7:32 AM, Juha Vierinen  
> wrote:
> 
> Calling:
> 
> ->config_mimo(MC_WE_LOCK_TO_SMA)
> 
> Johnathan

It will be grateful if python bindings for "config_mimo", 
"sync_every_pps"
are added to usrp2_base.h and usrp2.i in gr-usrp2.
(Until now, I have added them everytime when I updated the gnuradio.)

I am using "sync_every_pps" for synchronizing boundaries of frames 
transmitted
from multiple USRP2. Since the samples are discarded when the samples 
arrive
later than the preset timestamp value, I use "sync_every_pps" and set 
timestamp value to  in order to guarantee transmission of the 
frame.

Changkyu Seol



-- 
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] [Douglas Geiger BBN 802.11b] Porting code on USRP2 problems

[Miklos Christine]

Hello,

I don't encounter this problem anymore. Someone else was trying to debug the
code.

I tried to run both USRP2's on one machine with 2 gigabit ethernet ports. It
did not seem to work.
Does anyone know if it is possible to run both USRP2's on one machine?

Thanks,
Miklos Christine

On Mon, May 11, 2009 at 1:45 AM, Ben Yahmed <
maher.ben_yah...@sophia.inria.fr> wrote:

> Hi,
>
> I do not encounter this problem, the simple_mac run in a correct way for
> me. Do you use the latest versions of the firmware and fpga?
>
> Ben Yahmed
>
> Miklos Christine wrote:
>
>> Hello Ben,
>>
>> When I try to run the version of simple_mac that you posted, I get an
>> error.
>> It seems like an infinite loop that prints to stdout:
>>
>> 2nstreams:
>> It happens at the call to fg.rxpath.start() .
>>
>> Do you have the same problem?
>>
>> Thanks,
>> Miklos Christine
>>
>> On Wed, May 6, 2009 at 10:46 AM, Ben Yahmed <
>> maher.ben_yah...@sophia.inria.fr >
>> wrote:
>>
>>Hi all,
>>I modified the gain in the bbn_80211_rx.py file from 46 to 27 and
>>the loss ratio has fallen down to 15-20%. Do you have any idea
>>about the best value to put?
>>this is the ping capture:
>>
>>
>># ping 10.0.0.1PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
>>64 bytes from 10.0.0.1 : icmp_seq=1 ttl=64
>>time=51.9 ms
>>64 bytes from 10.0.0.1 : icmp_seq=2 ttl=64
>>time=52.0 ms
>>64 bytes from 10.0.0.1 : icmp_seq=3 ttl=64
>>time=52.0 ms
>>64 bytes from 10.0.0.1 : icmp_seq=4 ttl=64
>>time=49.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=5 ttl=64
>>time=49.4 ms
>>64 bytes from 10.0.0.1 : icmp_seq=6 ttl=64
>>time=46.3 ms
>>64 bytes from 10.0.0.1 : icmp_seq=7 ttl=64
>>time=45.7 ms
>>64 bytes from 10.0.0.1 : icmp_seq=10 ttl=64
>>time=35.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=12 ttl=64
>>time=35.1 ms
>>64 bytes from 10.0.0.1 : icmp_seq=13 ttl=64
>>time=34.3 ms
>>64 bytes from 10.0.0.1 : icmp_seq=15 ttl=64
>>time=32.5 ms
>>64 bytes from 10.0.0.1 : icmp_seq=16 ttl=64
>>time=33.0 ms
>>64 bytes from 10.0.0.1 : icmp_seq=17 ttl=64
>>time=29.7 ms
>>64 bytes from 10.0.0.1 : icmp_seq=18 ttl=64
>>time=29.8 ms
>>64 bytes from 10.0.0.1 : icmp_seq=19 ttl=64
>>time=28.7 ms
>>64 bytes from 10.0.0.1 : icmp_seq=20 ttl=64
>>time=28.1 ms
>>64 bytes from 10.0.0.1 : icmp_seq=21 ttl=64
>>time=27.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=22 ttl=64
>>time=25.8 ms
>>64 bytes from 10.0.0.1 : icmp_seq=23 ttl=64
>>time=24.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=24 ttl=64
>>time=23.6 ms
>>64 bytes from 10.0.0.1 : icmp_seq=25 ttl=64
>>time=22.4 ms
>>64 bytes from 10.0.0.1 : icmp_seq=26 ttl=64
>>time=20.4 ms
>>64 bytes from 10.0.0.1 : icmp_seq=27 ttl=64
>>time=21.5 ms
>>64 bytes from 10.0.0.1 : icmp_seq=28 ttl=64
>>time=11.1 ms
>>64 bytes from 10.0.0.1 : icmp_seq=29 ttl=64
>>time=10.9 ms
>>64 bytes from 10.0.0.1 : icmp_seq=30 ttl=64
>>time=10.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=31 ttl=64
>>time=11.3 ms
>>64 bytes from 10.0.0.1 : icmp_seq=32 ttl=64
>>time=11.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=33 ttl=64
>>time=10.7 ms
>>64 bytes from 10.0.0.1 : icmp_seq=34 ttl=64
>>time=11.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=36 ttl=64
>>time=9.74 ms
>>64 bytes from 10.0.0.1 : icmp_seq=38 ttl=64
>>time=11.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=39 ttl=64
>>time=10.7 ms
>>64 bytes from 10.0.0.1 : icmp_seq=40 ttl=64
>>time=11.2 ms
>>64 bytes from 10.0.0.1 : icmp_seq=41 ttl=64
>>time=10.8 ms
>>64 bytes from 10.0.0.1 : icmp_seq=44 ttl=64
>>time=9.83 ms
>>64 bytes from 10.0.0.1 : icmp_seq=45 ttl=64
>>time=10.4 ms
>>64 bytes from 10.0.0.1 : icmp_seq=47 ttl=64
>>time=9.91 ms
>>64 bytes from 10.0.0.1 : icmp_seq=48 ttl=64
>>time=10.1 ms
>>64 bytes from 10.0.0.1 : icmp_seq=49 ttl=64
>>time=11.1 ms
>>64 bytes from 10.0.0.1 : icmp_seq=50 ttl=64
>>time=10.4 ms
>>64 bytes from 10.0.0.1 : icmp_seq=51 ttl=64
>>time=10.4 ms
>>64 bytes from 10.0.0.1 : icmp_seq=52 ttl=64
>>time=10.7 ms

Re: [Discuss-gnuradio] [BBN_USRP2] Barker (de)spreading

[Jason Uher]

> are using a raised cosin as the TX/RX filter.  Perhaps you can swap out that
> filter with the barker filter to test if the bits are being decoded
> correctly.

You will still need the RRC filter after barker coding.  You can't
really send direct plus/minus one data to the USRP because you can't
reproduce that in hardware, not to mention if you try you will end up
with a terrible spectrum.  There needs to be a nice transition between
bits, which the RRC helps with.

Jason


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

Re: [Discuss-gnuradio] Further explain about receiving packets using 2 daughter

[Ling Huang]

actualy, I set the wrong mux value so that the wave form is very bad. And I
set mux to 0x2310, it now work well.

James Byrne-2 wrote:
> 
> I'm encountering the same problem over where I am, and have come to the 
> same conclusion.
> -- 
> Posted via http://www.ruby-forum.com/.
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Further-explain-about-receiving-packets-using-2-daughterboads-in-2-framer-sink-didn%27t-work-correctly.-tp22682442p23551427.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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

Re: [Discuss-gnuradio] standard squelch crashing?

[davek]

Works! thanks

On Thu, May 14, 2009 at 6:49 PM, Josh Blum  wrote:

> fixed in gnuradio trunk r11033
>
> _josh
>
> davek wrote:
>
>> im trying to implement standard squelch into one of my flowgraps however
>> crashes when excuted.
>>  a test flowgraph null source -> squelch -> null sink heres what i get in
>> top_block.py
>>
>> ##
>> # Blocks
>> ##
>> self.blks2_standard_squelch_0 = >
>> cannot find 'set_threshold' while searching for 'set_threshold':
>> blks2.standard_squelch(audio_rate=$audio_rate)
>> $id.set_threshold($threshold)
>> <
>> self.gr_null_sink_0 = gr.null_sink(gr.sizeof_float*1)
>> self.gr_null_source_0 = gr.null_source(gr.sizeof_float*1)
>>
>>
>> Any ideas?
>> dave
>>
>>
>>
>> 
>>
>> ___
>> 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] standard squelch crashing?

[Josh Blum]

fixed in gnuradio trunk r11033

_josh

davek wrote:

im trying to implement standard squelch into one of my flowgraps however
crashes when excuted.
 a test flowgraph null source -> squelch -> null sink heres what i get in
top_block.py

##
# Blocks
##
self.blks2_standard_squelch_0 = >
cannot find 'set_threshold' while searching for 'set_threshold':
blks2.standard_squelch(audio_rate=$audio_rate)
$id.set_threshold($threshold)
<
self.gr_null_sink_0 = gr.null_sink(gr.sizeof_float*1)
self.gr_null_source_0 = gr.null_source(gr.sizeof_float*1)


Any ideas?
dave





___
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] [BBN_USRP2] Barker (de)spreading

[Colby Boyer]

Hi Andrea,

In the GNU Radio code base
(trunk/gnuradio-core/src/python/gnuradio/blks2impl) you can find DBPSK and
DQPSK modulators, which are used by the benchmark_tx/rx files found in the
gnuradio-example directory.  I looked at the python code and the modulators
are using a raised cosin as the TX/RX filter.  Perhaps you can swap out that
filter with the barker filter to test if the bits are being decoded
correctly.

--Colby

On Thu, May 14, 2009 at 6:51 AM, Costantini, Andrea wrote:

> Dear all (especially people working on BBN code with USRP2),
>
> I know that some of you are working on simple_mac, higher modulation rates
> and so on.
>
> From my side I decided to spend some more time in understanding why the
> bbn_802.11_tx.py doesn't work when trying to receive with real 802.11
> chipsets in monitor mode (modified to disable the mac CRC check).
>
> After some inspection of the code, I believe that this is due to the Barker
> implementation.
>
> The code (bbn_firdes_barker.cc) does a convolution between an oversampled
> sinc function and the barker sequence (and takes by default exactly 8
> samples).
> The IEEE 802.11b standard doesn't say anything about how the barker
> sequence should be applied.
> Therefore I don't understand why the sinc convolution is used in the
> original code.
> (This could be (?) originally related to the limits in bandwidth of the
> USRP1?)
>
> Anyway the fft of the signal generated by the BBN code (with the -b option)
> has a spectrum completely different than the one generated by the 802.11
> chipset (compared by using usrp2_fft.py).
>
> I decided to re-implement the barker (de)spreading.
> I wrote a Matlab program where I simulated a usrp2 transmission in terms of
> fpga rate, interpolation, timing, and so on.
> As opposed to the convolution of the original BBN code, I used simple
> rectangular windows to represent the Barker sequence.
> I examined the spectrum of a train of these Barker sequences.
> In order to obtain exactly 22 Mhz bandwidth, the usrp2 parameters must be
> set in this way:
>
> - Samples per chip = 2;
> - Interpolation = 4;
>
> I did the following thoughts:
> - With barker sequence in DSSS mode we need to transmit 11Mchip/s in order
> to obtain a real transmission at 1MSymbols/s (= 1Mbit/s in this particular
> case).
> - 11Mchip/s means that we must transmit a single chip in about 91ns.
> - The FPGA is able to process exactly 9 samples in this time interval
> (100Msample/s -> a sample every 10ns).
>
> Now, if we consider that a barker sequence has to be transmitted in
> 1microsecond and the minimum interpolation is 4, we have to take 25 samples
> for each barker sequence in order to obtain EXACTLY 1Mbit/s.
>
> For the sake of simplicity I have tried with 22 samples per barker sequence
> (2 samples per chip) and I obtained a spectrum very similar to the one
> received from the chipset.
>
> I'm working on this right now. But I am still not able to receive frames on
> the real chipset.
> Do you see any mistake in my reasoning?
> Any suggestions/feedbacks/comments/critics/etc. :-) is very welcome.
>
> Regards,
> Andrea
>
>
>
> ___
> 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] standard squelch crashing?

[davek]

im trying to implement standard squelch into one of my flowgraps however
crashes when excuted.
 a test flowgraph null source -> squelch -> null sink heres what i get in
top_block.py

##
# Blocks
##
self.blks2_standard_squelch_0 = >
cannot find 'set_threshold' while searching for 'set_threshold':
blks2.standard_squelch(audio_rate=$audio_rate)
$id.set_threshold($threshold)
<
self.gr_null_sink_0 = gr.null_sink(gr.sizeof_float*1)
self.gr_null_source_0 = gr.null_source(gr.sizeof_float*1)


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

Re: [Discuss-gnuradio] Re: save date and value to an rotating file

[Josh Blum]

and you can always add custom blocks that you write:
http://gnuradio.org/trac/wiki/GNURadioCompanion#AddingCustomBlocks

But Custom Blocks rely on custom sinks and sources. I need to
process the data through an own python file sink method, with rotate
and time feature.
Or is this still possible ?
As i understood, processing of data is made in c++ and the
connection+gui is made in python.


You can do it all in python by making a hier block, and using gr message 
sinks and sources. See pkt.py as an example:


http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-core/src/python/gnuradio/blks2impl


x**.5

Thanks for the hint.
But which grc modul apply this mathematical function on incoming data
and outputs it ?
I mean to apply mathematical function to incoming data from an Usrp
Source not a constant variable.





I think there is a block for this gr_feval_cc, gr_feval_ll, gr_feval_dd. 
I have never used it, but I think the idea is that you can inherit from 
this class and override the eval function in python.


-Josh


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

Re: [Discuss-gnuradio] Pin indication of TX for LF d-board

[Dustin Torres]

I found a solution to my previous problem of toggling a GPIO to indicate 
transmit or receive for the LFRX and LFTX boards. It is posted here:

http://www.opensubscriber.com/message/discuss-gnuradio@gnu.org/4966537.html

Dustin

--- On Sun, 5/3/09, Dustin Torres  wrote:

From: Dustin Torres 
Subject: [Discuss-gnuradio] Pin indication of TX for LF d-board
To: discuss-gnuradio@gnu.org
Date: Sunday, May 3, 2009, 5:54 PM

Hi, 

I am trying to toggle a GPIO pin high when the lftx board is transmitting and 
low otherwise, similar to the io_tx_06 pin on the rfx boards. What is the best 
way to do this?

Thanks,
Dustin



  
-Inline Attachment Follows-

___
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] Re: save date and value to an rotating file

[Markus Feldmann]

Josh Blum schrieb:



There is a block called gr.head (misc->head) that shuts-off after N 
samples pass through.

I mean to cut off the last line in the file and append the new data
to the file. But as i saw this is still a performance problem, however
it would work for me, because i do not save as much data to the file.



and you can always add custom blocks that you write:
http://gnuradio.org/trac/wiki/GNURadioCompanion#AddingCustomBlocks

But Custom Blocks rely on custom sinks and sources. I need to
process the data through an own python file sink method, with rotate
and time feature.
Or is this still possible ?
As i understood, processing of data is made in c++ and the
connection+gui is made in python.


There are many simple function not realized in grc like the 
mathematical root operation.


Many doesn't work, and so you have to do many by hand !


Anything that you can fit into a line of python is possible, so for 
square root:


1)
x**.5

Thanks for the hint.
But which grc modul apply this mathematical function on incoming data
and outputs it ?
I mean to apply mathematical function to incoming data from an Usrp
Source not a constant variable.


2)
add an import block: import math
math.sqrt(x)

Do you mean,
import math; math.sqrt(x)

In one line with a semicolon ?
Yes thats working. I still tested it.

Regards Markus



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

Re: [Discuss-gnuradio] grc dynamic variables

[Josh Blum]

No, currently the forms.slider cannot have its min and max changed 
during runtime.


Usually, the work around would be to use more variables to scale the 
output of the slider according to another variable:


output_value = scalar*slider_value + offset

where offset and scalar can also be graphical variables that can be 
changed at runtime.


-Josh


davek wrote:

Is there anyway to change the limits of a slider variable during runtime in
grc?





___
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] Re: change size of scrollarea of grc

[Markus Feldmann]

Josh Blum schrieb:

Thats a big flow graph! In pixels, how big should it be?


Yes that is a good Question. Generally it would be nice to
know how to change this, but i think 4096x4096 would be nice
for me, or maybe more for the students which proceed with my
task after me. :-)

regards Markus



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

[Discuss-gnuradio] grc dynamic variables

[davek]

Is there anyway to change the limits of a slider variable during runtime in
grc?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] (no subject)

[[ Cosmin ]]

Hello,
I have 2 USRP model 1.
On the first one (called Alpha) I've put the Basic RX and the LFRX daughter 
boards.
On the second one (called Beta) I've put the TVRX and the DBSRX.
I've connected both Alpha and Beta on a mac mini via the usb cables.
What I expect to do is a relative hudge bandwich (from DC to 2.4GHz) RX tunning 
system.
Now I would like to know if plugging the 2 USRP in the same time is safe for 
the hardware.
Am I forced to synchronyse the clock?
And if yes Where could I find some visuals helping me doing that.
Best Regards,
Cosmin
_
Téléphonez gratuitement à tous vos proches avec Windows Live Messenger  !  
Téléchargez-le maintenant ! 
http://www.windowslive.fr/messenger/1.asp

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

Re: [Discuss-gnuradio] dbpsk modulation

[Jason Uher]

> modulator, given a desired bit rate and carrier frequency?  I can't
> seem to figure out how excess_bw and samples_per_symbol affect the
> parameters I ultimately want to set (bit rate and carrier freq).

I would examine the 'pick_bitrate.py' file in the digital examples in
detail.  This file shows the derivation for calculating
decimation/interpolation and samples per symbol to achieve desired
rates bitrates.  It can be passed a combination of desired
samples/symbol, bitrate,and {interp|decim} rate and calculate the rest
for you.

Carrier frequency is handled differently, and is usually based on the
daughter card you are using, though the 'tune' method should work for
almost all of them, again, see the examples in the digital folder.

Jason


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

[Discuss-gnuradio] dbpsk modulation

[Tom Lutz]

Would someone mind explaining how to appropriately use the dbpsk
modulator, given a desired bit rate and carrier frequency?  I can't
seem to figure out how excess_bw and samples_per_symbol affect the
parameters I ultimately want to set (bit rate and carrier freq).

Thanks,
Tom


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

Re: [Discuss-gnuradio] Re: change size of scrollarea of grc

[Josh Blum]

Thats a big flow graph! In pixels, how big should it be?

feldmaus wrote:

feldmaus  gmx.de> writes:

Hi Gnuradio folks, 


how can i change the scrollarea size of grc ?


I mean, ho can i change the size to greater than 2048x2048 ?




___
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] Re: save date and value to an rotating file

[Josh Blum]

Yes, my application is not complex, but not general. So there is no
support i think in grc.
Further on, if you make grc moduls, you have to use the sink and source
elements from gnuradio and can not process the input data through some
python functions.
connect(SOURCE(Gnuradio Source) ---> SINK(Gnuradio Sink))
Thats it ! No Python between this connection.

It would be nice to make all in GRC, but there is no module in GRC to
limit the size of an file. Further on i need to save the creation time and the
finish time of the saved file. This simple task is only be done by
python or c++.



There is a block called gr.head (misc->head) that shuts-off after N 
samples pass through.


and you can always add custom blocks that you write:
http://gnuradio.org/trac/wiki/GNURadioCompanion#AddingCustomBlocks

There are many simple function not realized in grc like the 
mathematical root operation.


Many doesn't work, and so you have to do many by hand !


Anything that you can fit into a line of python is possible, so for 
square root:


1)
x**.5

2)
add an import block: import math
math.sqrt(x)

-Josh


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

Re: [Discuss-gnuradio] Syncrinization of two USRP2s

[Matt Ettus]

Ulrika Uppman wrote:

Hi,

We've set up a test comparing a recieved white noise signal recieved
by two usrp2 recievers. The two receivers were clocked (1PPS and
refclk) by a GPS diciplined OCXO which outpus a 1PPS signal which is
phase locked to the 10 MHz reference. The daughterboard was the
RFX400 configured with a center frequency of 450 MHz and a decimation
factor of 4. Several cross spectrums between the two received signals
shows that the syncronisation is drifting by +/- 1 sample. We would
like the difference to not drift. Is this possible?



I am not sure exactly what you mean by drifting by 1 sample.  Are you 
making use of the time fields in the received data?


The first thing to do would be to make sure that both USRP2s are locked 
to the reference.  You can do this by calling


clocks_enable_test_clk(true, 1);

in the firmware.  This will turn on the clock on J503 of the USRP2 
motherboards.  Pins 1 and 4 of that connector are ground, and 2 and 3 
are the differential clock.  Connect an oscilloscope to those pins on 
each USRP2 and make sure that the clocks do not drift relative to each 
other.  They should be perfectly locked and in phase.



The second issue is the 1 pps signal.  It must be synchronous with the 
10 MHz reference clock.  GPSDOs have 2 types of PPS outputs, those that 
are synchronous to the OCXO (often called ocxo-derived) and those that 
are directly generated by the GPS.  You need to use the former.


One final issue is that depending on the relative delay of your PPS and 
10 MHz signals, you might want to sample PPS on the positive edge or 
negative edge.  If you are using the wrong edge, there may be timing 
issues.  To set this, in the firmware call:


timesync_regs->tick_control = 0xC;  // Positive edge
or
timesync_regs->tick_control = 0x4;   // Negative edge, default

Matt


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

Re: [Discuss-gnuradio] question about BasicTX and BasicRX

[mayur_CEN]

Hi,
I am also experimenting with FM signals .
I am using a single usrp for RX/TX
TVRX board is used for reception
Basic tx for Transmission.
I am running two programs simultaneously in gnuradio
i am using the wfm_receiver  example program in GRC for RX and a fm
transmission code at terminal
Hope it solves some of your problem.
 you need to separate antennas for tx/rx
Mayur


Woody Dickson wrote:
> 
> Hi,
> 
> I would like to conduct an experiment with using BasicTX to send AM/FM
> signal ( voice ) and have BasicRX to receive AM/FM signal.
> 
> Basically, a way to transmit voice and another way to receive voice
> using USRP.
> 
> Do I need two USRPs for this task?
> 
> If I already have a USRP, is it true that I only need to buy one
> BasicTX and one BasicRX only? Or do I need one more USRP in additional
> to one that I have?
> 
> Also, do I also need to purchase two antenna?
> 
> Regards,
> Woody
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://www.nabble.com/question-about-BasicTX-and-BasicRX-tp23536549p23544605.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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

Re: [Discuss-gnuradio] question about BasicTX and BasicRX

[mayur_CEN]

Hi,
I am also experimenting with FM signals .
I am using a single usrp for RX/TX
TVRX board is used for reception
Basic tx for Transmission.
I am running two programs simultaneously in gnuradio
i am using the wfm_receiver  example program in GRC for RX and a fm
transmission code at terminal
Hope it solves some of your problem.

Mayur


Woody Dickson wrote:
> 
> Hi,
> 
> I would like to conduct an experiment with using BasicTX to send AM/FM
> signal ( voice ) and have BasicRX to receive AM/FM signal.
> 
> Basically, a way to transmit voice and another way to receive voice
> using USRP.
> 
> Do I need two USRPs for this task?
> 
> If I already have a USRP, is it true that I only need to buy one
> BasicTX and one BasicRX only? Or do I need one more USRP in additional
> to one that I have?
> 
> Also, do I also need to purchase two antenna?
> 
> Regards,
> Woody
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 

-- 
View this message in context: 
http://www.nabble.com/question-about-BasicTX-and-BasicRX-tp23536549p23544602.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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

Re: [Discuss-gnuradio] Syncrinization of two USRP2s

[Johnathan Corgan]

On Thu, May 14, 2009 at 7:32 AM, Juha Vierinen  wrote:

> Ok. I managed to get a lock only after modifying the firmware. Is
> there some example for doing this on the host, I'm just wondering what
> I did wrong.

Calling:

->config_mimo(MC_WE_LOCK_TO_SMA)

...from your host code usrp2 instance pointer commands the firmware to
invoke the same function you are calling in your modified firmware;
the results are identical.

Johnathan


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

Re: [Discuss-gnuradio] How to control the transmit power of USRP 1, rx2400 daughter board?

[Jason Uher]

> I want to make a experiment by generating interferer using Benckmark_tx.py on
> RX2400 daughter board. I am confused when I want to control the transmit
> power.  How can I control the power. With set_gain(), I see no difference.

If I remember correctly the RFX boards do not have controllable
transmit gain.  You control the power of the transmitter by adjusting
the multiplier prior to sending the data to the USRP.

If you were to do a ".\benchmark_tx.py -h" you would see a whole bunch
of options, one of which adjusts this value (It's called tx-amplitude
or similar)

Jason


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

Re: [Discuss-gnuradio] Syncrinization of two USRP2s

[Juha Vierinen]

>>  We do call config_mimo(MC_WE_LOCK_TO_SMA) when we set up the usrp2 (before 
>> the start of receiving). Is clocks_mimo_config() different from 
>> config_mimo()?
>
> This is correct.  The host driver has the function call to cause the
> USRP2 clock to synchronize with an external reference on the SMA, as
> you are doing. Modifying the firmware to add a call to the firmware's
> internal clocks_mimo_config() function is possible, but not needed
> unless you are creating a standalone USRP2 application.

Ok. I managed to get a lock only after modifying the firmware. Is
there some example for doing this on the host, I'm just wondering what
I did wrong.

juha


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

[Discuss-gnuradio] Dynamically updating vector sources

[Davide Zanetti]

Hello!

I have a question regarding vector_source_c:

After the 
src = gr.vector_source_c (xxx, 1) where xxx is a list of samples

self.connect (src, dst)  where dst is the ursp
and having started the flow (fg.start())

is it possible to change/append/add values to the complex vector ("src" 
in the previous lines) in a way of dynamically changing what it is sent 
to the usrp?


For the big picture, this what I am trying to do:
I want to build a simple UHF rfid reader, partially implementing the EPC 
G2C1 standard.  Basically, only the part used to read the ID from a 
single tag (no writing on the tag, no multiple tags).
The encoding is PIE and the modulation PR-ASK. The commands needed to 
read a single tag are just 4, having between 8 and ~44 bits each.


My initial idea was to build vectors containing the baseband signal for 
each of the 4 commands, and then use those vectors as source for the 
uspr.sink.


I actually did this: I created two lists that represent the bit 0 and 
bit 1 (each one containing the samples that represent bit 0, resp. bit 
1, as PIE-encoded and PR-ASK-modulated with sampling rate at 1MS/s), and 
put together those lists to compose the individual commands (which are 
simply a sequence of bits).
Then, I properly concatenated those commands ("properly" = respecting 
the order and timing of the standard), created the vector source, and 
linked to the usrp sink (as shown above).
The sequence is correctly transmitted (so, the baseband signal contained 
in the vector source is up-mixed and sent out by the usrp) and the tag 
is actually responding back.


Now, I would like to decide which command to send (and set its fields) 
and a step-by-step mode. That is, set and send command A, then do 
something (e.g., receiving a tag response), set and send B (e.g., 
setting it according to the previous tag response), and so on, instead 
of composing the entire communication at once with possibility of 
interacting.


Thanks!!

Davide


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

[Discuss-gnuradio] How to control the transmit power of USRP 1, rx2400 daughter board?

[njlyf6]

I want to make a experiment by generating interferer using Benckmark_tx.py on
RX2400 daughter board. I am confused when I want to control the transmit
power.  How can I control the power. With set_gain(), I see no difference.
-- 
View this message in context: 
http://www.nabble.com/How-to-control-the-transmit-power-of-USRP-1%2C-rx2400-daughter-board--tp23541404p23541404.html
Sent from the GnuRadio mailing list archive at Nabble.com.



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

[Discuss-gnuradio] [BBN_USRP2] Barker (de)spreading

[Costantini, Andrea]

Dear all (especially people working on BBN code with USRP2),

I know that some of you are working on simple_mac, higher modulation 
rates and so on.


From my side I decided to spend some more time in understanding why the 
bbn_802.11_tx.py doesn't work when trying to receive with real 802.11 
chipsets in monitor mode (modified to disable the mac CRC check).


After some inspection of the code, I believe that this is due to the 
Barker implementation.


The code (bbn_firdes_barker.cc) does a convolution between an 
oversampled sinc function and the barker sequence (and takes by default 
exactly 8 samples).
The IEEE 802.11b standard doesn't say anything about how the barker 
sequence should be applied.
Therefore I don't understand why the sinc convolution is used in the 
original code.
(This could be (?) originally related to the limits in bandwidth of the 
USRP1?)


Anyway the fft of the signal generated by the BBN code (with the -b 
option) has a spectrum completely different than the one generated by 
the 802.11 chipset (compared by using usrp2_fft.py).


I decided to re-implement the barker (de)spreading.
I wrote a Matlab program where I simulated a usrp2 transmission in terms 
of fpga rate, interpolation, timing, and so on.
As opposed to the convolution of the original BBN code, I used simple 
rectangular windows to represent the Barker sequence.

I examined the spectrum of a train of these Barker sequences.
In order to obtain exactly 22 Mhz bandwidth, the usrp2 parameters must 
be set in this way:


- Samples per chip = 2;
- Interpolation = 4;

I did the following thoughts:
- With barker sequence in DSSS mode we need to transmit 11Mchip/s in 
order to obtain a real transmission at 1MSymbols/s (= 1Mbit/s in this 
particular case).

- 11Mchip/s means that we must transmit a single chip in about 91ns.
- The FPGA is able to process exactly 9 samples in this time interval 
(100Msample/s -> a sample every 10ns).


Now, if we consider that a barker sequence has to be transmitted in 
1microsecond and the minimum interpolation is 4, we have to take 25 
samples for each barker sequence in order to obtain EXACTLY 1Mbit/s.


For the sake of simplicity I have tried with 22 samples per barker 
sequence (2 samples per chip) and I obtained a spectrum very similar to 
the one received from the chipset.


I'm working on this right now. But I am still not able to receive frames 
on the real chipset.

Do you see any mistake in my reasoning?
Any suggestions/feedbacks/comments/critics/etc. :-) is very welcome.

Regards,
Andrea



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

Re: [Discuss-gnuradio] Tx amplifier non-linearity

[Johnathan Corgan]

On Thu, May 14, 2009 at 6:01 AM,   wrote:

> I use USRP 1 and RFX2400..I try to find if the amplifier of the transmitter 
> has
> a non-linear region. Do you know anything about this topic? Is there a
> non-linear region that i could find? I try to find a relation of P_in versus
> P_out at the amplifier of the transmitter.
>
> If there is only linear region, please tell me...

The RFX2400 (and other RFX boards) begin to go into nonlinearity at
about 20 dB below its maximum output power, though this is a rough
approximation and varies board-to-board.  In practice, you can stay in
the linear region by ensuring the amplitude of your TX signal stays
below 0.1 or so (when using USRP2), or below 3000 (when using USRP1).

If making this precise is important to you, you can perform a two-tone
test using usrp_siggen.py and a spectrum analyzer to measure the IMD
products directly and adjust the transmit power until they meet your
specification.

Johnathan


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

Re: [Discuss-gnuradio] Syncrinization of two USRP2s

[Johnathan Corgan]

On Thu, May 14, 2009 at 4:44 AM, Ulrika Uppman  wrote:

>  We do call config_mimo(MC_WE_LOCK_TO_SMA) when we set up the usrp2 (before 
> the start of receiving). Is clocks_mimo_config() different from config_mimo()?

This is correct.  The host driver has the function call to cause the
USRP2 clock to synchronize with an external reference on the SMA, as
you are doing. Modifying the firmware to add a call to the firmware's
internal clocks_mimo_config() function is possible, but not needed
unless you are creating a standalone USRP2 application.

Johnathan


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

[Discuss-gnuradio] Re: save date and value to an rotating file

[feldmaus]

Jason Uher  gmail.com> writes:

> From your questions on the board I'm starting to wonder if your
> application isn't complex enough that it would warrant being built in
> strict python rather than GRC, it would certainly make your life
> easier in terms of doing things like this:
> 
Yes, my application is not complex, but not general. So there is no
support i think in grc.
Further on, if you make grc moduls, you have to use the sink and source
elements from gnuradio and can not process the input data through some
python functions.
connect(SOURCE(Gnuradio Source) ---> SINK(Gnuradio Sink))
Thats it ! No Python between this connection.

It would be nice to make all in GRC, but there is no module in GRC to
limit the size of an file. Further on i need to save the creation time and the
finish time of the saved file. This simple task is only be done by
python or c++.

There are many simple function not realized in grc like the 
mathematical root operation.

Many doesn't work, and so you have to do many by hand !

Thanks for your reply
regards Markus



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

[Discuss-gnuradio] Tx amplifier non-linearity

[kardaras]

Hi,

I use USRP 1 and RFX2400..I try to find if the amplifier of the transmitter has
a non-linear region. Do you know anything about this topic? Is there a
non-linear region that i could find? I try to find a relation of P_in versus
P_out at the amplifier of the transmitter.

If there is only linear region, please tell me...


Thanks in advance,
Kardaras Giannis


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

Re: [Discuss-gnuradio] save date and value to an rotating file

[Jason Uher]

> And i still read in the thread  something
> about .
> Both are written in c++, not python, further on 
> is a sink and can not connected to another sink.
> Is the gr.msg_queues a sink and source ?

message_sink, message_source, and msg_queues operate hand in hand to
create a procedure for transferring your packets (arrays in python)
into the streams used in gnuradio modulation blocks.  Basically, when
you call the function (instance of: blks2.mod_pkts).send_pkt(payload,
eof), it creates the packet with the necessary headers and footers
then places into the message queue.  The modulator is then connected
to an instance of gr.message_source to read the packets from the
queue, serialized them and stream them to the modulator.  The setup
for message_source is the opposite of this.

I would have a look at 'blks2impl/pkt.py' for more information.


>From your questions on the board I'm starting to wonder if your
application isn't complex enough that it would warrant being built in
strict python rather than GRC, it would certainly make your life
easier in terms of doing things like this:

> i want to save my incoming values of peaks to a file, but with
> the depending date. The file should also limited to size X or
> to a number of samples.

Jason


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

SV: [Discuss-gnuradio] Syncrinization of two USRP2s

[Ulrika Uppman]

 We do call config_mimo(MC_WE_LOCK_TO_SMA) when we set up the usrp2 (before the 
start of receiving). Is clocks_mimo_config() different from config_mimo()?

I also read about the troubles with config_mimo before revision 10471, but we 
use 10899 of the software, so that problem should be solved i guess. The 
firmware used is the built version of 10766.

/Ulrika

-Ursprungligt meddelande-
Från: Juha Vierinen [mailto:jvier...@gmail.com] 
Skickat: den 14 maj 2009 12:39
Till: Ulrika Uppman
Kopia: discuss-gnuradio@gnu.org
Ämne: Re: [Discuss-gnuradio] Syncrinization of two USRP2s

I was just recently fighting with this, and Matt told me that I have to modify 
the firmware to get the USRP2 to lock (or at least this is the easiest way to 
get the lock). Have you modified the firmware yet?
You need to add

clocks_mimo_config(MC_WE_LOCK_TO_SMA);

in the main() function of txrx.c and u2_init();

juha


On Thu, May 14, 2009 at 09:32, Ulrika Uppman  wrote:
> Hi,
>
> We've set up a test comparing a recieved white noise signal recieved by two 
> usrp2 recievers. The two receivers were clocked (1PPS and refclk) by a GPS 
> diciplined OCXO which outpus a 1PPS signal which is phase locked to the 10 
> MHz reference. The daughterboard was the RFX400 configured with a center 
> frequency of 450 MHz and a decimation factor of 4. Several cross spectrums 
> between the two received signals shows that the syncronisation is drifting by 
> +/- 1 sample. We would like the difference to not drift. Is this possible?
>
> Regards,
> //Ulrika
>
> ___
> 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] Syncrinization of two USRP2s

[Juha Vierinen]

I was just recently fighting with this, and Matt told me that I have
to modify the firmware to get the USRP2 to lock (or at least this is
the easiest way to get the lock). Have you modified the firmware yet?
You need to add

clocks_mimo_config(MC_WE_LOCK_TO_SMA);

in the main() function of txrx.c and u2_init();

juha


On Thu, May 14, 2009 at 09:32, Ulrika Uppman  wrote:
> Hi,
>
> We've set up a test comparing a recieved white noise signal recieved by two 
> usrp2 recievers. The two receivers were clocked (1PPS and refclk) by a GPS 
> diciplined OCXO which outpus a 1PPS signal which is phase locked to the 10 
> MHz reference. The daughterboard was the RFX400 configured with a center 
> frequency of 450 MHz and a decimation factor of 4. Several cross spectrums 
> between the two received signals shows that the syncronisation is drifting by 
> +/- 1 sample. We would like the difference to not drift. Is this possible?
>
> Regards,
> //Ulrika
>
> ___
> 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] Syncrinization of two USRP2s

[Ulrika Uppman]

Hi,

We've set up a test comparing a recieved white noise signal recieved by two 
usrp2 recievers. The two receivers were clocked (1PPS and refclk) by a GPS 
diciplined OCXO which outpus a 1PPS signal which is phase locked to the 10 MHz 
reference. The daughterboard was the RFX400 configured with a center frequency 
of 450 MHz and a decimation factor of 4. Several cross spectrums between the 
two received signals shows that the syncronisation is drifting by +/- 1 sample. 
We would like the difference to not drift. Is this possible?

Regards,
//Ulrika

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

[Discuss-gnuradio] question about BasicTX and BasicRX

[Woody Dickson]

Hi,

I would like to conduct an experiment with using BasicTX to send AM/FM
signal ( voice ) and have BasicRX to receive AM/FM signal.

Basically, a way to transmit voice and another way to receive voice
using USRP.

Do I need two USRPs for this task?

If I already have a USRP, is it true that I only need to buy one
BasicTX and one BasicRX only? Or do I need one more USRP in additional
to one that I have?

Also, do I also need to purchase two antenna?

Regards,
Woody


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

[Discuss-gnuradio] Re: change size of scrollarea of grc

[feldmaus]

feldmaus  gmx.de> writes:

> 
> Hi Gnuradio folks, 
> 
> how can i change the scrollarea size of grc ?

I mean, ho can i change the size to greater than 2048x2048 ?




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

[Discuss-gnuradio] change size of scrollarea of grc

[feldmaus]

Hi Gnuradio folks, :-)

how can i change the scrollarea size of grc ?
It is a little bit to small for my application. :-)

regards Markus



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