GNU Radio, One Step at a Time: June 2011

Thursday, June 30, 2011

[Discuss-gnuradio] OFDM preamble

Hi.
I wanted to know about the preambles that are inserted in the ofdm packet. I know they are inserted for the synchronization and frequency offset purposes.
But I want to know where in the OFDM packet they are inserted. I have following questions.

1. How can I vary the length of preambles? Can I do that ?

2. On which parameters length of preamble depends?

3. What is the length of preamble sequence if I am using fft-length=512, occupied carriers=200 cp-length=128, size of ofdm packet=400 bytes, modulation='bpsk'.

4. Where are they inserted in the OFDM packet? I mean before Payload?

       --------------------------------------------
      preamble| payload|
       --------------------------------------------
5. Both the preambles are inserted at the start ?

6. Which modulation is used for preambles?

Need your help

Regards

[Discuss-gnuradio] MAC layer questions

Hi,

I've been working on building a CSMA/CA MAC for the past couple of
weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
working now, but I don't think it's very efficient. I ended up having
to relax a lot of timing parameters to get it working, so my
throughput is pretty bad. I also get a lot of dropped packets. I think
this is also because my timing isn't very accurate, and I end up with
more collisions than I would expect.

I was wondering if anyone else had had any luck building a CSMA/CA
MAC. I saw a few posts on the mailing list from several years ago
about people who were working on it, but I don't see any example code
anywhere. I also checked out CMUmacs on CGRAN, but that relies on a
deprecated version of GNURadio.

Is my best bet to rewrite the MAC as a block in C++? Can anyone tell
me what kind of speedup that's likely to get me?

Thanks,
Morgan Redfield

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OFDM modulation in tunnel.py example [USRP2 platform]

Hi Juan,

It isn't too hard to modify the OFDM tunnel script to use UHD instead
of the old USRP blocks.

You have to change the flow graph in tunnel.py to use new sink and
source blocks and update all of the sample rate and frequency setting
functions.

You can take a look at how I did it here:
https://github.com/mogar/uhd_ofdm/blob/master/tunnel.py

Hope that helps,
Morgan

On Thu, Jun 30, 2011 at 7:07 AM, Juan Ramon Gutierrez <jgutierrez@umh.es> wrote:
> Dear GNU Radio list,
>
> I've being diving into some GNU Radio examples in order to communicate
> two USRP2s (e.g. USRP2 #1 pings USRP2 #2). Following the example
> "tunnel.py", in $GNURADIO_PATH/gnuradio-examples/python/digital, I've
> been able to do it, but with a GMSK/DBPSK/DQPSK modulation scheme.
>
> My goal is to use the tunnel.py example but using a different modulation
> scheme, i.e. OFDM. I've seen the example "tunnel.py" in another
> directory ($GNURADIO_PATH/gnuradio-examples/python/ofdm), which uses a
> OFDM modulation scheme but it seems that it's only working for USRP1.
>
> Is it possible nowadays to use tunnel.py (transmit and receive
> flow-graph in the same USRP2) with OFDM in an USRP2 platform?
>
> Thank you for your help.
>
> My equipement is:
> 2x USRP2s + XCVR2450 daughterboard
> Linux 10.04 (Lucid) - 32 bits
> GNU Radio version 3.3.0 (stable version)
>
> Kind Regards,
>
> Juan Ramon Gutierrez Agullo
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Max temperature for usrp2

Eric, in your 2009 experiment indicated below, did the USRP2 sustain the high temperature of 150 F?

Is there anybody else who has tried to use USRP2 continuously at a temperature above 105 F? Your feedback is highly appreciated.

Andrew

On Mon, Jul 13, 2009 at 1:13 PM, Eric Matlis<emat...@nd.edu> wrote:

> Hi all-
>
> I'm about to conduct some measurements on a running GE aircraft jet engine
> with the USRP2. The test cell temps could reach 150 F. Is that going to
> fry my USRP?
>
> Thanks,
> eric
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UDP broadcasting

Hi, I'm trying to get a basic IP-based network running between 2 or 3 USRPs and I'm having trouble trying to send broadcast UDP packets via dial_tone_sink.py in the network examples. I'm sending the packets addressed to 192.168.200.255 with port 0 but this continuously results in a "can't open socket" error. If I address the packets directly to another machine 192.168.200.30, it works fine. Is there something else I need to do to broadcast packets?

Re: [Discuss-gnuradio] WBX CW transmit problem

I have seen the same issue in the last couple of days.

My setup:
Ubuntu 10.04 laptop
UHD + GNUradio 3.3
USRP2 with WBX

TX parameters:
15dB gain, 1090MHz center frequency
4MS/s transmission

RX parameters:
25dB gain, 1090MHz center frequency
4MS/s acquisition

transmitted signal:
U(t) = 10mV + 5mV * sin(2*pi*f*t)
f = 100 kHz

I observe unexpected sinusoidal oscillations in the amplitude at about
400kHz
Oscillation amplitude is on the order of 1mV.

Dave

Aleš Povalač wrote:
>
> Dear all,
>
> I have been testing USRP2 with WBX board (#957). Using GNU Radio, I
> have created a simple CW TX system. The problem: output signal is
> oscillating when I set the TX frequencies to 900MHz band. Signal
> output (in time domain) at TX/RX connector from the FSL analyzer is in
> the attachment.
>
> Settings:
> 868 MHz, 200 kSps, gain 15 dB
>
> Same results with:
> ./tx_waveforms --rate 250000 --freq 868000000 --gain 15
>
> The oscillation with ca. 1dB amplitude is present for almost all gain
> settings except the lowest values. I have observed the problem at
> several frequencies from 700M to 1G, sometimes with amplitude over
> 2dB.
>
> Any ideas about the cause of this problem? Some PA instability or AGC
> loop issue?
>
> Thanks,
> Ales
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context: http://old.nabble.com/WBX-CW-transmit-problem-tp31963722p31964536.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD FPGA problem

Hello!

I bypassed successfully the ADC lines directly to the DAC lines using the GNU Radio FPGA code but I tried to do the same with the UHD code and it was impossible, I always get zero as amplitude. I am doing this bypass into the u2_core module.

Does anyone have an idea about what is going on?

A lot of thanks!

Eduardo.

[Discuss-gnuradio] WBX CW transmit problem

Dear all,

I have been testing USRP2 with WBX board (#957). Using GNU Radio, I
have created a simple CW TX system. The problem: output signal is
oscillating when I set the TX frequencies to 900MHz band. Signal
output (in time domain) at TX/RX connector from the FSL analyzer is in
the attachment.

Settings:
868 MHz, 200 kSps, gain 15 dB

Same results with:
./tx_waveforms --rate 250000 --freq 868000000 --gain 15

The oscillation with ca. 1dB amplitude is present for almost all gain
settings except the lowest values. I have observed the problem at
several frequencies from 700M to 1G, sometimes with amplitude over
2dB.

Any ideas about the cause of this problem? Some PA instability or AGC
loop issue?

Thanks,
Ales

[Discuss-gnuradio] OFDM modulation in tunnel.py example [USRP2 platform]

Dear GNU Radio list,

I've being diving into some GNU Radio examples in order to communicate
two USRP2s (e.g. USRP2 #1 pings USRP2 #2). Following the example
"tunnel.py", in $GNURADIO_PATH/gnuradio-examples/python/digital, I've
been able to do it, but with a GMSK/DBPSK/DQPSK modulation scheme.

My goal is to use the tunnel.py example but using a different modulation
scheme, i.e. OFDM. I've seen the example "tunnel.py" in another
directory ($GNURADIO_PATH/gnuradio-examples/python/ofdm), which uses a
OFDM modulation scheme but it seems that it's only working for USRP1.

Is it possible nowadays to use tunnel.py (transmit and receive
flow-graph in the same USRP2) with OFDM in an USRP2 platform?

Thank you for your help.

My equipement is:
2x USRP2s + XCVR2450 daughterboard
Linux 10.04 (Lucid) - 32 bits
GNU Radio version 3.3.0 (stable version)

Kind Regards,

Juan Ramon Gutierrez Agullo

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 Performance

Am 30.06.2011 um 11:27 schrieb Ralf:
> Am 29.06.2011 16:34, schrieb Marcus D. Leech:
>> On 29/06/2011 9:11 AM, Ralf wrote:
>>> Hi,
>>>
>>> the simple GRC in the attachment creates lots of underflows on our E100 ("U" on console)
>>> and dropouts when looking at the spectrum.
>>>
>>> Is this as expected or how can this overload of the embedded Linux be avoided?
>>>
>>> Thanks,
>>> Ralf
>> Well, for one, 60Khz isn't a proper divisor of the 128MHz sample rate of the DAC, which means it can't be properly interpolated.
>>
>> The minimum sample rate that you can deliver to the USRP-E100 is 128MHz/512 = 250kHz, so you'll have to interpolate your
>> data stream up to 250kHz prior to "presentation" to the UHD sink block.
>>
>
> Hi Marcus, thanks for your reply.
>
> That is very important for us to understand. How is the divider 512 determined? It is in the FPGA I suppose.
> Where can read more about the FPGA besides this small text?
> http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html#fpga
>
> Can we only put proper divisors of 128MHz in terms of datarate into the UHD sink even above 250kHz?
>
> Actually we need to put ~10kbit/s of data onto a ~400kHz carrier. Is the GRC repeater the right functionality
> to interpolate the small datarate as shown in the attached setup?
>
> Regards,
> Ralf

There is a collection of lots of internal details of the USRP1 under
www.gnuradio.org/redmine/attachments/129/USRP_Documentation.pdf

They might also apply to the operation of the E100's FPGA logic.

You can also look at the source code directly
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/master/show/fpga

Regards,
Matthias
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 Performance

On 06/30/2011 05:27 AM, Ralf wrote:
>
>
> Hi Marcus, thanks for your reply.
>
> That is very important for us to understand. How is the divider 512
> determined? It is in the FPGA I suppose.
> Where can read more about the FPGA besides this small text?
> http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html#fpga
The FPGA supports a maximum interpolation ratio of 512. Interpolation
ratios must be even.
>
> Can we only put proper divisors of 128MHz in terms of datarate into
> the UHD sink even above 250kHz?
Yup. Only bandwidths that result in an even interpolation ratio from
the 128MHz DAC sample
rate can be used.

>
> Actually we need to put ~10kbit/s of data onto a ~400kHz carrier. Is
> the GRC repeater the right functionality
> to interpolate the small datarate as shown in the attached setup?
>
Normally, if you need to use a "weird" sample rate, you'd use something
like the fractional interpolator
block just before you send the stream to the UHD sink. Do you mean a
carrier that is 400kHz in
bandwidth, or a carrier at 400kHz center frequency? The center
frequency isn't really relevant
to this discussion, but the bandwidth is.

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 Performance

<?xml version='1.0' encoding='ASCII'?>
<flow_graph>
<timestamp>Thu Jun 30 11:09:05 2011</timestamp>
<block>
<key>options</key>
<param>
<key>id</key>
<value>tx</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>title</key>
<value></value>
</param>
<param>
<key>author</key>
<value></value>
</param>
<param>
<key>description</key>
<value></value>
</param>
<param>
<key>window_size</key>
<value>1280, 1024</value>
</param>
<param>
<key>generate_options</key>
<value>qt_gui</value>
</param>
<param>
<key>category</key>
<value>Custom</value>
</param>
<param>
<key>run_options</key>
<value>prompt</value>
</param>
<param>
<key>run</key>
<value>True</value>
</param>
<param>
<key>realtime_scheduling</key>
<value></value>
</param>
<param>
<key>_coordinate</key>
<value>(10, 10)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>blks2_dxpsk_mod</key>
<param>
<key>id</key>
<value>blks2_dxpsk_mod_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>dqpsk</value>
</param>
<param>
<key>samples_per_symbol</key>
<value>4</value>
</param>
<param>
<key>excess_bw</key>
<value>0.35</value>
</param>
<param>
<key>gray_code</key>
<value>True</value>
</param>
<param>
<key>verbose</key>
<value>False</value>
</param>
<param>
<key>log</key>
<value>False</value>
</param>
<param>
<key>_coordinate</key>
<value>(313, 259)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>random_source_x</key>
<param>
<key>id</key>
<value>random_source_x_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>byte</value>
</param>
<param>
<key>min</key>
<value>0</value>
</param>
<param>
<key>max</key>
<value>255</value>
</param>
<param>
<key>num_samps</key>
<value>10</value>
</param>
<param>
<key>repeat</key>
<value>True</value>
</param>
<param>
<key>_coordinate</key>
<value>(73, 259)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>uhd_usrp_source</key>
<param>
<key>id</key>
<value>uhd_usrp_source_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>complex</value>
</param>
<param>
<key>dev_addr</key>
<value></value>
</param>
<param>
<key>ref_clk</key>
<value></value>
</param>
<param>
<key>sync</key>
<value></value>
</param>
<param>
<key>clock_rate</key>
<value>0.0</value>
</param>
<param>
<key>num_mboards</key>
<value>1</value>
</param>
<param>
<key>sd_spec0</key>
<value></value>
</param>
<param>
<key>sd_spec1</key>
<value></value>
</param>
<param>
<key>sd_spec2</key>
<value></value>
</param>
<param>
<key>sd_spec3</key>
<value></value>
</param>
<param>
<key>nchan</key>
<value>1</value>
</param>
<param>
<key>samp_rate</key>
<value>1000000</value>
</param>
<param>
<key>center_freq0</key>
<value>0</value>
</param>
<param>
<key>gain0</key>
<value>0</value>
</param>
<param>
<key>ant0</key>
<value></value>
</param>
<param>
<key>bw0</key>
<value>0</value>
</param>
<param>
<key>center_freq1</key>
<value>0</value>
</param>
<param>
<key>gain1</key>
<value>0</value>
</param>
<param>
<key>ant1</key>
<value></value>
</param>
<param>
<key>bw1</key>
<value>0</value>
</param>
<param>
<key>center_freq2</key>
<value>0</value>
</param>
<param>
<key>gain2</key>
<value>0</value>
</param>
<param>
<key>ant2</key>
<value></value>
</param>
<param>
<key>bw2</key>
<value>0</value>
</param>
<param>
<key>center_freq3</key>
<value>0</value>
</param>
<param>
<key>gain3</key>
<value>0</value>
</param>
<param>
<key>ant3</key>
<value></value>
</param>
<param>
<key>bw3</key>
<value>0</value>
</param>
<param>
<key>center_freq4</key>
<value>0</value>
</param>
<param>
<key>gain4</key>
<value>0</value>
</param>
<param>
<key>ant4</key>
<value></value>
</param>
<param>
<key>bw4</key>
<value>0</value>
</param>
<param>
<key>center_freq5</key>
<value>0</value>
</param>
<param>
<key>gain5</key>
<value>0</value>
</param>
<param>
<key>ant5</key>
<value></value>
</param>
<param>
<key>bw5</key>
<value>0</value>
</param>
<param>
<key>center_freq6</key>
<value>0</value>
</param>
<param>
<key>gain6</key>
<value>0</value>
</param>
<param>
<key>ant6</key>
<value></value>
</param>
<param>
<key>bw6</key>
<value>0</value>
</param>
<param>
<key>center_freq7</key>
<value>0</value>
</param>
<param>
<key>gain7</key>
<value>0</value>
</param>
<param>
<key>ant7</key>
<value></value>
</param>
<param>
<key>bw7</key>
<value>0</value>
</param>
<param>
<key>center_freq8</key>
<value>0</value>
</param>
<param>
<key>gain8</key>
<value>0</value>
</param>
<param>
<key>ant8</key>
<value></value>
</param>
<param>
<key>bw8</key>
<value>0</value>
</param>
<param>
<key>center_freq9</key>
<value>0</value>
</param>
<param>
<key>gain9</key>
<value>0</value>
</param>
<param>
<key>ant9</key>
<value></value>
</param>
<param>
<key>bw9</key>
<value>0</value>
</param>
<param>
<key>center_freq10</key>
<value>0</value>
</param>
<param>
<key>gain10</key>
<value>0</value>
</param>
<param>
<key>ant10</key>
<value></value>
</param>
<param>
<key>bw10</key>
<value>0</value>
</param>
<param>
<key>center_freq11</key>
<value>0</value>
</param>
<param>
<key>gain11</key>
<value>0</value>
</param>
<param>
<key>ant11</key>
<value></value>
</param>
<param>
<key>bw11</key>
<value>0</value>
</param>
<param>
<key>center_freq12</key>
<value>0</value>
</param>
<param>
<key>gain12</key>
<value>0</value>
</param>
<param>
<key>ant12</key>
<value></value>
</param>
<param>
<key>bw12</key>
<value>0</value>
</param>
<param>
<key>center_freq13</key>
<value>0</value>
</param>
<param>
<key>gain13</key>
<value>0</value>
</param>
<param>
<key>ant13</key>
<value></value>
</param>
<param>
<key>bw13</key>
<value>0</value>
</param>
<param>
<key>center_freq14</key>
<value>0</value>
</param>
<param>
<key>gain14</key>
<value>0</value>
</param>
<param>
<key>ant14</key>
<value></value>
</param>
<param>
<key>bw14</key>
<value>0</value>
</param>
<param>
<key>center_freq15</key>
<value>0</value>
</param>
<param>
<key>gain15</key>
<value>0</value>
</param>
<param>
<key>ant15</key>
<value></value>
</param>
<param>
<key>bw15</key>
<value>0</value>
</param>
<param>
<key>_coordinate</key>
<value>(300, 418)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>qtgui_sink_x</key>
<param>
<key>id</key>
<value>qtgui_sink_x_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>complex</value>
</param>
<param>
<key>name</key>
<value>QT GUI Plot</value>
</param>
<param>
<key>fftsize</key>
<value>1024</value>
</param>
<param>
<key>wintype</key>
<value>firdes.WIN_BLACKMAN_hARRIS</value>
</param>
<param>
<key>fc</key>
<value>0</value>
</param>
<param>
<key>bw</key>
<value>1000000</value>
</param>
<param>
<key>plotfreq</key>
<value>True</value>
</param>
<param>
<key>plotwaterfall</key>
<value>True</value>
</param>
<param>
<key>plottime</key>
<value>True</value>
</param>
<param>
<key>plotconst</key>
<value>True</value>
</param>
<param>
<key>gui_hint</key>
<value></value>
</param>
<param>
<key>_coordinate</key>
<value>(540, 411)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>gr_multiply_const_vxx</key>
<param>
<key>id</key>
<value>gr_multiply_const_vxx_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>complex</value>
</param>
<param>
<key>const</key>
<value>0.1</value>
</param>
<param>
<key>vlen</key>
<value>1</value>
</param>
<param>
<key>_coordinate</key>
<value>(528, 279)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>uhd_usrp_sink</key>
<param>
<key>id</key>
<value>uhd_usrp_sink_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>complex</value>
</param>
<param>
<key>dev_addr</key>
<value></value>
</param>
<param>
<key>ref_clk</key>
<value></value>
</param>
<param>
<key>sync</key>
<value></value>
</param>
<param>
<key>clock_rate</key>
<value>0.0</value>
</param>
<param>
<key>num_mboards</key>
<value>1</value>
</param>
<param>
<key>sd_spec0</key>
<value>:A</value>
</param>
<param>
<key>sd_spec1</key>
<value></value>
</param>
<param>
<key>sd_spec2</key>
<value></value>
</param>
<param>
<key>sd_spec3</key>
<value></value>
</param>
<param>
<key>nchan</key>
<value>1</value>
</param>
<param>
<key>samp_rate</key>
<value>samp_rate</value>
</param>
<param>
<key>center_freq0</key>
<value>400000</value>
</param>
<param>
<key>gain0</key>
<value>3</value>
</param>
<param>
<key>ant0</key>
<value></value>
</param>
<param>
<key>bw0</key>
<value>0</value>
</param>
<param>
<key>center_freq1</key>
<value>0</value>
</param>
<param>
<key>gain1</key>
<value>0</value>
</param>
<param>
<key>ant1</key>
<value></value>
</param>
<param>
<key>bw1</key>
<value>0</value>
</param>
<param>
<key>center_freq2</key>
<value>0</value>
</param>
<param>
<key>gain2</key>
<value>0</value>
</param>
<param>
<key>ant2</key>
<value></value>
</param>
<param>
<key>bw2</key>
<value>0</value>
</param>
<param>
<key>center_freq3</key>
<value>0</value>
</param>
<param>
<key>gain3</key>
<value>0</value>
</param>
<param>
<key>ant3</key>
<value></value>
</param>
<param>
<key>bw3</key>
<value>0</value>
</param>
<param>
<key>center_freq4</key>
<value>0</value>
</param>
<param>
<key>gain4</key>
<value>0</value>
</param>
<param>
<key>ant4</key>
<value></value>
</param>
<param>
<key>bw4</key>
<value>0</value>
</param>
<param>
<key>center_freq5</key>
<value>0</value>
</param>
<param>
<key>gain5</key>
<value>0</value>
</param>
<param>
<key>ant5</key>
<value></value>
</param>
<param>
<key>bw5</key>
<value>0</value>
</param>
<param>
<key>center_freq6</key>
<value>0</value>
</param>
<param>
<key>gain6</key>
<value>0</value>
</param>
<param>
<key>ant6</key>
<value></value>
</param>
<param>
<key>bw6</key>
<value>0</value>
</param>
<param>
<key>center_freq7</key>
<value>0</value>
</param>
<param>
<key>gain7</key>
<value>0</value>
</param>
<param>
<key>ant7</key>
<value></value>
</param>
<param>
<key>bw7</key>
<value>0</value>
</param>
<param>
<key>center_freq8</key>
<value>0</value>
</param>
<param>
<key>gain8</key>
<value>0</value>
</param>
<param>
<key>ant8</key>
<value></value>
</param>
<param>
<key>bw8</key>
<value>0</value>
</param>
<param>
<key>center_freq9</key>
<value>0</value>
</param>
<param>
<key>gain9</key>
<value>0</value>
</param>
<param>
<key>ant9</key>
<value></value>
</param>
<param>
<key>bw9</key>
<value>0</value>
</param>
<param>
<key>center_freq10</key>
<value>0</value>
</param>
<param>
<key>gain10</key>
<value>0</value>
</param>
<param>
<key>ant10</key>
<value></value>
</param>
<param>
<key>bw10</key>
<value>0</value>
</param>
<param>
<key>center_freq11</key>
<value>0</value>
</param>
<param>
<key>gain11</key>
<value>0</value>
</param>
<param>
<key>ant11</key>
<value></value>
</param>
<param>
<key>bw11</key>
<value>0</value>
</param>
<param>
<key>center_freq12</key>
<value>0</value>
</param>
<param>
<key>gain12</key>
<value>0</value>
</param>
<param>
<key>ant12</key>
<value></value>
</param>
<param>
<key>bw12</key>
<value>0</value>
</param>
<param>
<key>center_freq13</key>
<value>0</value>
</param>
<param>
<key>gain13</key>
<value>0</value>
</param>
<param>
<key>ant13</key>
<value></value>
</param>
<param>
<key>bw13</key>
<value>0</value>
</param>
<param>
<key>center_freq14</key>
<value>0</value>
</param>
<param>
<key>gain14</key>
<value>0</value>
</param>
<param>
<key>ant14</key>
<value></value>
</param>
<param>
<key>bw14</key>
<value>0</value>
</param>
<param>
<key>center_freq15</key>
<value>0</value>
</param>
<param>
<key>gain15</key>
<value>0</value>
</param>
<param>
<key>ant15</key>
<value></value>
</param>
<param>
<key>bw15</key>
<value>0</value>
</param>
<param>
<key>_coordinate</key>
<value>(887, 260)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>variable</key>
<param>
<key>id</key>
<value>samp_rate</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>value</key>
<value>10000</value>
</param>
<param>
<key>_coordinate</key>
<value>(9, 89)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>gr_repeat</key>
<param>
<key>id</key>
<value>gr_repeat_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>complex</value>
</param>
<param>
<key>interp</key>
<value>128</value>
</param>
<param>
<key>vlen</key>
<value>1</value>
</param>
<param>
<key>_coordinate</key>
<value>(709, 282)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<connection>
<source_block_id>blks2_dxpsk_mod_0</source_block_id>
<sink_block_id>gr_multiply_const_vxx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>random_source_x_0</source_block_id>
<sink_block_id>blks2_dxpsk_mod_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>uhd_usrp_source_0</source_block_id>
<sink_block_id>qtgui_sink_x_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>gr_multiply_const_vxx_0</source_block_id>
<sink_block_id>gr_repeat_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>gr_repeat_0</source_block_id>
<sink_block_id>uhd_usrp_sink_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
</flow_graph>
Am 29.06.2011 16:34, schrieb Marcus D. Leech:
> On 29/06/2011 9:11 AM, Ralf wrote:
>> Hi,
>>
>> the simple GRC in the attachment creates lots of underflows on our
>> E100 ("U" on console)
>> and dropouts when looking at the spectrum.
>>
>> Is this as expected or how can this overload of the embedded Linux be
>> avoided?
>>
>> Thanks,
>> Ralf
> Well, for one, 60Khz isn't a proper divisor of the 128MHz sample rate
> of the DAC, which means it can't be properly interpolated.
>
> The minimum sample rate that you can deliver to the USRP-E100 is
> 128MHz/512 = 250kHz, so you'll have to interpolate your
> data stream up to 250kHz prior to "presentation" to the UHD sink block.
>

Hi Marcus, thanks for your reply.

That is very important for us to understand. How is the divider 512
determined? It is in the FPGA I suppose.
Where can read more about the FPGA besides this small text?
http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html#fpga

Can we only put proper divisors of 128MHz in terms of datarate into the
UHD sink even above 250kHz?

Actually we need to put ~10kbit/s of data onto a ~400kHz carrier. Is the
GRC repeater the right functionality
to interpolate the small datarate as shown in the attached setup?

Regards,
Ralf

Wednesday, June 29, 2011

Re: [Discuss-gnuradio] Re g : Building gr-uhd and usrp2-firmware

On 06/29/2011 06:01 PM, sumitstop wrote:
> Hi Marcus I got the answer for the question in this thread.Actually I was
> using an outdated version of UHD which doesn't had USRP2 firmwares.Hence
> during configure it was showing the above error.
> I just downloaded the latest images and firmwares.
> I need to ask that whether it is needed to uninstall the older UHD before
> installing the new one.
> If yes then
> will "make uninstall" will work in the directory from which i did "make
> install" ?
> or some other way .......
As long as you're always installing from source, it should be OK.

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re g : Building gr-uhd and usrp2-firmware

Hi Marcus I got the answer for the question in this thread.Actually I was
using an outdated version of UHD which doesn't had USRP2 firmwares.Hence
during configure it was showing the above error.
I just downloaded the latest images and firmwares.
I need to ask that whether it is needed to uninstall the older UHD before
installing the new one.
If yes then
will "make uninstall" will work in the directory from which i did "make
install" ?
or some other way .......

sumitstop wrote:
>
> Hi Marcus.... I have used your script.Its superb! I just wanted to build
> step by step :)
> Btw I just got all things build properly.Actually I put mb-gcc in the home
> folder and set the path variables accordingly.And it worked :)
>
> Marcus D. Leech wrote:
>>
>> On 06/23/2011 06:50 PM, sumitstop wrote:
>>> I am using ubuntu Lucid 10.04 LTS.
>>>
>>> Did the following thing
>>>
>>> Step-1 Installed all the dependencies for ubuntu Lucid 10.04 from the
>>> script
>>> given here
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall
>>>
>>> step-2 git clone http://gnuradio.org/git/gnuradio.git
>>> then
>>>
>>> step-3 git clone http://github.com/EttusResearch/UHD-Mirror.git
>>> after that
>>>
>>> step-4 cd gnuradio
>>> step-5 ./bootstrap
>>> step-6 ./configure
>>>
>>> I got following messages
>>> *********************************************************************
>>> The following components were skipped either because you asked not
>>> to build them or they didn't pass configuration checks:
>>>
>>> usrp2-firmware
>>>
>>> These components will not be built.
>>>
>>>
>>> *********************************************************************
>>> The following GNU Radio components have been successfully configured:
>>>
>>> config
>>> gruel
>>> volk
>>> gnuradio-core
>>> usrp
>>> usrp2
>>> gr-usrp
>>> gr-usrp2
>>> gr-msdd6000
>>> gr-audio
>>> gr-atsc
>>> gr-cvsd-vocoder
>>> gr-gpio
>>> gr-gsm-fr-vocoder
>>> gr-noaa
>>> gr-pager
>>> gr-radar-mono
>>> gr-radio-astronomy
>>> gr-trellis
>>> gr-video-sdl
>>> gr-wxgui
>>> gr-qtgui
>>> gr-sounder
>>> gr-utils
>>> gnuradio-examples
>>> grc
>>> docs
>>>
>>> You my now run the make command to build these components.
>>>
>>> *********************************************************************
>>> The following components were skipped either because you asked not
>>> to build them or they didn't pass configuration checks:
>>>
>>> gcell
>>> gr-gcell
>>> gr-comedi
>>> gr-uhd
>>>
>>> These components will not be built.
>>>
>>> Configured GNU Radio release v3.4.0-2-g081497e7 for build.
>>>
>>> **********************************************************************
>>>
>>> I searched a lot and found answer to many of questions
>>>
>>> > From the following link(in the summary) i found that no need to build
>>> gr-comedi
>>> http://lists.gnu.org/archive/html/discuss-gnuradio/2006-06/msg00225.html
>>>
>>> Also in the following link I read that gcell and gr-gcell are needed
>>> only
>>> for IBM cell processor.
>>> http://www.ruby-forum.com/topic/201112
>>>
>>> So I want to ask what should I do to build
>>>
>>> gr-uhd and usrp2-firmware
>>>
>>> I also did
>>>
>>> ./configure --enable-gr-uhd
>>>
>>> but it shows following message
>>>
>>> checking for UHD... no
>>> gr-uhd requires libuhd 3.x.x
>>> configure: error: Component gr-uhd has errors; stopping.
>>>
>>> I also did
>>>
>>> ./configure --enable-usrp2-firmware
>>>
>>> and got following message
>>>
>>> checking whether byte ordering is bigendian... no
>>> checking for mb-gcc... no
>>> usrp2 firmware requires mb-gcc. Not found
>>> configure: error: Component usrp2-firmware has errors; stopping.
>>> configure: error: ./configure.gnu failed for usrp2/firmware
>>>
>>> I saw several posts with the same problem but honestly I couldn't
>>> understand
>>> what to do next.
>>>
>>> Regards
>>>
>>>
>>>
>>>
>>> -----
>>> Sumit Kr.
>>> Research Assistant
>>> Communication Research center
>>> IIIT Hyderabad
>>> India
>> I'll once again do some personal horn-tooting, if y'all can stand it:
>>
>> http://www.sbrac.org/files/build-gnuradio
>>
>>
>> It takes care of downloading/building UHD+Gnu Radio, including
>> downloading the latest firmware, installing pre-requisites, and
>> uninstalling
>> any installed-from-binary-packages "stuff" that might interfere with
>> a "built from source" build of Gnu Radio.
>>
>> It works for Ubuntu and Fedora recent releases.
>>
>> It's a shell script. It takes quite a while to run, and generally
>> operates as silently as is practical.
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortium
>> http://www.sbrac.org
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>

-----
Sumit Kr.
Research Assistant
Communication Research center
IIIT Hyderabad
India
--
View this message in context: http://old.nabble.com/Reg-%3A-Building-gr-uhd-and-usrp2-firmware-tp31915462p31958690.html
Sent from the GnuRadio mailing list archive at Nabble.com.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief

On Wed, Jun 29, 2011 at 09:24, Marcus D. Leech <mleech@ripnet.com> wrote:

On 29/06/2011 12:12 PM, Johnathan Corgan wrote:
GNU Radio achieves its streaming performance in part due to a circular buffer design that maps the same physical memory twice in the virtual memory map for the process, directly adjacent to each other. This allows work function code to avoid doing any bounds checking or modular index arithmetic operations when reading and writing its input and output buffers. Going "off the end" of the buffer just results in accessing the start of the buffer which is mapped into the next block of memory. Not only does this make the code and I/O much faster, but the work function code gets a lot simpler.

I wonder if that assertion is generally true, or only in some cases? Increment and test shouldn't be *that* expensive.

I'm sure the benefit varies depending on the situation, including some where there is no benefit. But modulo increments add a conditional operation for every pointer increment, which can cause a processor pipeline stall, and takes up register file space to hold the array boundaries for every input and output stream. It also forces the author of the work() function to know about how GNU Radio handles circular buffers. The double-mapped circular buffer lets the work() function treat all its inputs and outputs as linear arrays in memory, no matter the actual case.

My recollection is that sizes get ballooned outwards based on the degree of decimation downstream from the source block, which is
a policy I've never quite gotten my head around. The FFT in my flow-graph might get decimated by a factor of 10 or more, which given
the policy I mentioned, might lead to chunky allocations.

Ah, I think I remember this discussion a while back. It's the gr.keep_one_in_n block used to decimate the sample stream into blocks that update the FFT sink at the requested screen update rate. Decimator blocks tell the runtime their decimation ratio via set_relative_rate(). Knowing this, GNU Radio expands the buffer allocation by twice the decimation rate, to allow enough room for the upstream block thread to be simultaneously writing a full set of inputs and the downstream block thread to be reading a full set of inputs:

http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/master/annotate/gnuradio-core/src/lib/runtime/gr_flat_flowgraph.cc#L106

Since gr.keep_one_in_n is simply discarding n-1 input items, and doesn't need to actually process them like most decimators would, there may be an alternative way to handle this for this particular block.

Johnathan

Re: [Discuss-gnuradio] using fftw for neon with gnuradio

I don't think you have to change the parameters you're giving to
./configure for gnuradio. You actually want to change the parameters
used by ./configure for fftw.

This worked for me:
./configure --enable-single --enable-neon --enable-shared
CFLAGS='-fPIC -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O2'

And then I built gnuradio as normal.

Morgan

On Wed, Jun 29, 2011 at 2:46 AM, Phelps Williams <phelpsw@gmail.com> wrote:
> Could somebody post the whole configure call once the vesperix fftw lib was
> installed?
> I'm giving this a try here myself but want to make sure I'm on the right
> track.
> ./configure --disable-volk --disable-usrp2 --disable-usrp1
> --disable-gr-video-sdl --enable-shared CFLAGS="-march=armv7-a
> -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC"
> CXXFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
> -O3 -fPIC" -with-qwt-incdir=/usr/include
> On Wed, Jun 22, 2011 at 5:26 PM, Thomas Tsou <ttsou@vt.edu> wrote:
>>
>> On Wed, Jun 22, 2011 at 2:13 PM, Philip Balister <philip@balister.org>
>> wrote:
>> >
>> > Did you rerun configure adding -fPIC to CFLAGS? I ddi get the library to
>> > build as a shared library.
>>
>> That worked for me.
>>
>> Thomas
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error on "Assertion `imu >= 0' failed" when using gr.udp_source/sink

On Wed, Jun 29, 2011 at 07:44, Zhen <zkongcn@yahoo.com.cn> wrote:

The reason is that in gnuradio-examples, UDP default payload size is set to 1471. In gr_udp_source.cc, all received data will be round down to a multiple of d_itemsize. Since sizeof_gr_complex is 8, so only 1464 Bytes are received correctly, while the left 7 byte are abandoned. This will in turn disturb the position of the following data stream, and also affect the mmse_fir_interpolator and make imu negative.

Actually, the default UDP payload size in gr_udp_source.h is set to 1472, but in examples, it is set to 1471. I am not sure if this is a bug. A simple way to bypass this problem is to set MTU size as a multiple of itemsize, such as 1464 or 1472, then everything works as expected.

Very nice catch. I have yet looked at the code to verify this, but your description sounds plausible. Thanks!

Johnathan

Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief

On 29/06/2011 12:12 PM, Johnathan Corgan wrote:

On Tue, Jun 28, 2011 at 21:38, Marcus D. Leech <mleech@ripnet.com> wrote:

I'll make the observation that there's just got to be a better buffer allocation policy than the existing one. Should it *really* take
Gigabytes of VM, and hundreds of MB of RSS to execute the flow-graph I've attached? The largest inter-block objects--the vectors
in front of and behind the FFT, are on the order of a few MB, and even accounting for some ballooning factor so you can have
several such vectors "in flight", that doesn't add up to hundreds of MB of RSS, and several GB of Virtual Size.

GNU Radio achieves its streaming performance in part due to a circular buffer design that maps the same physical memory twice in the virtual memory map for the process, directly adjacent to each other. This allows work function code to avoid doing any bounds checking or modular index arithmetic operations when reading and writing its input and output buffers. Going "off the end" of the buffer just results in accessing the start of the buffer which is mapped into the next block of memory. Not only does this make the code and I/O much faster, but the work function code gets a lot simpler.

I wonder if that assertion is generally true, or only in some cases? Increment and test shouldn't be *that* expensive.

In order to make this strategy work, however, the buffer memory must end on an exact multiple of the size of a single stream item. Thus, the allocated buffer size has to be the LCM (least common multiple) of the machine page size and the item size. The machine page size is typically 4096 bytes, so in simple cases when the item size is a small power of two, the minimum buffer size remains 4096 bytes. (In practice, other things the user might ask of the runtime can increase the size by an integer factor of this.) The usual GNU Radio buffer in these cases is 32K, which can hold 16K shorts, 8K floats, 4K complex floats, etc.

If your stream item size is larger than 4K, things can get ugly. The best case is that your item size is a power of two, so the LCM will end up being the same as the item size. Then GNU Radio can allocate memory for however many items it needs to hold in the buffer simply as a multiple of that. The worst case is when the item size is relatively prime to the page size, and then LCM is the product of the page size and the item size. Asking GNU Radio to allocate a buffer for items of size 4097 results in a minimum buffer size of 4096*4097 or slightly over 16Mbytes. The virtual memory footprint will be twice that.

The worst-case item is the FFT, which is typically large--sometimes as much as 512K, but it's always a power-of-two size, and given
that it's "complex", the result should also be a power-of-two size, since each complex-float takes 8 bytes.

I'm guessing something like this last is what is happening in your flowgraph. I'd trace through all the blocks in your graph and their configuration parameters, then manually calculate what the item size is and the LCM with 4096 that results.

My recollection is that sizes get ballooned outwards based on the degree of decimation downstream from the source block, which is
a policy I've never quite gotten my head around. The FFT in my flow-graph might get decimated by a factor of 10 or more, which given
the policy I mentioned, might lead to chunky allocations.

Re: [Discuss-gnuradio] A simple flow-graph that is giving me infinite grief

On Tue, Jun 28, 2011 at 21:38, Marcus D. Leech <mleech@ripnet.com> wrote:

I'll make the observation that there's just got to be a better buffer allocation policy than the existing one. Should it *really* take
Gigabytes of VM, and hundreds of MB of RSS to execute the flow-graph I've attached? The largest inter-block objects--the vectors
in front of and behind the FFT, are on the order of a few MB, and even accounting for some ballooning factor so you can have
several such vectors "in flight", that doesn't add up to hundreds of MB of RSS, and several GB of Virtual Size.

GNU Radio achieves its streaming performance in part due to a circular buffer design that maps the same physical memory twice in the virtual memory map for the process, directly adjacent to each other. This allows work function code to avoid doing any bounds checking or modular index arithmetic operations when reading and writing its input and output buffers. Going "off the end" of the buffer just results in accessing the start of the buffer which is mapped into the next block of memory. Not only does this make the code and I/O much faster, but the work function code gets a lot simpler.

In order to make this strategy work, however, the buffer memory must end on an exact multiple of the size of a single stream item. Thus, the allocated buffer size has to be the LCM (least common multiple) of the machine page size and the item size. The machine page size is typically 4096 bytes, so in simple cases when the item size is a small power of two, the minimum buffer size remains 4096 bytes. (In practice, other things the user might ask of the runtime can increase the size by an integer factor of this.) The usual GNU Radio buffer in these cases is 32K, which can hold 16K shorts, 8K floats, 4K complex floats, etc.

If your stream item size is larger than 4K, things can get ugly. The best case is that your item size is a power of two, so the LCM will end up being the same as the item size. Then GNU Radio can allocate memory for however many items it needs to hold in the buffer simply as a multiple of that. The worst case is when the item size is relatively prime to the page size, and then LCM is the product of the page size and the item size. Asking GNU Radio to allocate a buffer for items of size 4097 results in a minimum buffer size of 4096*4097 or slightly over 16Mbytes. The virtual memory footprint will be twice that.

I'm guessing something like this last is what is happening in your flowgraph. I'd trace through all the blocks in your graph and their configuration parameters, then manually calculate what the item size is and the LCM with 4096 that results.

If you are writing your own blocks, there is a technique where you can "lie" to the GNU Radio runtime and say your item size is the next higher power of two, but your own custom written blocks on either end of the buffer know the "real" size of the item and how to access them spaced out in the buffer accordingly. But this hack obviously won't work with existing blocks.

Johnathan

Re: [Discuss-gnuradio] Error on "Assertion `imu >= 0' failed" when using gr.udp_source/sink

I just solved this problem!

The reason is that in gnuradio-examples, UDP default payload size is set to 1471. In gr_udp_source.cc, all received data will be round down to a multiple of d_itemsize. Since sizeof_gr_complex is 8, so only 1464 Bytes are received correctly, while the left 7 byte are abandoned. This will in turn disturb the position of the following data stream, and also affect the mmse_fir_interpolator and make imu negative.

Actually, the default UDP payload size in gr_udp_source.h is set to 1472, but in examples, it is set to 1471. I am not sure if this is a bug. A simple way to bypass this problem is to set MTU size as a multiple of itemsize, such as 1464 or 1472, then everything works as expected.

发件人： Zhen <zkongcn@yahoo.com.cn>
收件人： "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
发送日期： 2011年6月28日, 星期二, 上午 2:34
主题: [Discuss-gnuradio] Error on "Assertion `imu >= 0' failed" when using gr.udp_source/sink

Hello,

I modified "benchmark_tx.py and benchmark_rx.py" by replacing the usrp_source/sink with gr.udp_source/sink and gr.file_source/sink, to see if the generated IQ data from tx side can be correctly captured and processed at rx side via UDP socket or trace file instead of USRP. If it does, then I can analyze the signal off-line or transmit the captured data to others via socket.

The modified program with gr.file_source/sink works correctly and the results are exactly the same when using usrp_source/sink.

But when using udp_source/sink, the tx side can send packets to udp_sink well, but the rx side program is aborted with error
"python: gri_mmse_fir_interpolator.cc:71: float gri_mmse_fir_interpolator::interpolate(const float*, float) const: Assertion `imu >= 0' failed."

My python codes are configured like the following:
rx side:

----------------------------------------------------------------------

self.u = gr.udp_source(gr.sizeof_gr_complex, options.host, options.port, options.packet_size, not options.no_eof, not options.no_wait)
rx_path = receive_path.receive_path(demod_class, rx_callback, options)

self.connect(self.u, rx_path)

---------------------------------------------------------------------

tx side:
------------------------------------------------------------------
self.u = gr.udp_sink(gr.sizeof_gr_complex, options.host, options.port, options.packet_size, options.no_eof);
tx_path = transmit_path.transmit_path(modulator_class, options)
self.connect(tx_path, self.u)
------------------------------------------------------------------

Then I added a printf in "gri_mmse_fir_interpolator.cc", and found imu is −2147483648, .i.e, -0x80000000;

But in normal situation when using usrp_source/sink or file_source/sink, it is between 63--67.

I searched the mailing list and knew that the imu value is used to tell the interpolating filter where in the filter to takethe output from, but got few clues to solve this problem.

I wonder if udp_source/sink modifies the complex data stream it transmits then the gnuradio can't process it correctly?
Or is there any suggestion to solve it?

Thanks in advance!

Zhen

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] E100 Performance

On 29/06/2011 9:11 AM, Ralf wrote:
> Hi,
>
> the simple GRC in the attachment creates lots of underflows on our
> E100 ("U" on console)
> and dropouts when looking at the spectrum.
>
> Is this as expected or how can this overload of the embedded Linux be
> avoided?
>
> Thanks,
> Ralf
Well, for one, 60Khz isn't a proper divisor of the 128MHz sample rate of
the DAC, which means it can't be properly interpolated.

The minimum sample rate that you can deliver to the USRP-E100 is
128MHz/512 = 250kHz, so you'll have to interpolate your
data stream up to 250kHz prior to "presentation" to the UHD sink block.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] DPSK2 Demodulator

Hi,

we are trying to use DPSK2 modulator and demodulator during our first
trials.
As far as we can see there is hardly any documentation available on this.

We would appreciate a few explaining words from somebody who knows how to
configure the demodulator so that data is correctly received.
What synchronization method(s) is/are included?
Raised-cosine-filter for matched filtering seems to be included?

We tried like this with no success:
Modulator:
Type: DQPSK
Sample/Symbol: 2
Excess BW: 0.35
GrayCode: YES
Verbose: OFF
Logging: OFF

Demodulator:
Sample/Symbol: 2
Excess BW: 0.35
FLL Alpha: 0.01
Phase Alpha: 0.1
Timing Max Dev: 1.5
Omega Relative Limit: 0.005
GrayCode: YES
Verbose: OFF
Logging: OFF
Sync Out: ON

Thanks in advance!
Ralf

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] E100 Performance

<?xml version='1.0' encoding='ASCII'?>
<flow_graph>
<timestamp>Wed Jun 29 14:59:09 2011</timestamp>
<block>
<key>uhd_usrp_sink</key>
<param>
<key>id</key>
<value>uhd_usrp_sink_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>complex</value>
</param>
<param>
<key>dev_addr</key>
<value></value>
</param>
<param>
<key>ref_clk</key>
<value></value>
</param>
<param>
<key>sync</key>
<value></value>
</param>
<param>
<key>clock_rate</key>
<value>0.0</value>
</param>
<param>
<key>num_mboards</key>
<value>1</value>
</param>
<param>
<key>sd_spec0</key>
<value>:A</value>
</param>
<param>
<key>sd_spec1</key>
<value></value>
</param>
<param>
<key>sd_spec2</key>
<value></value>
</param>
<param>
<key>sd_spec3</key>
<value></value>
</param>
<param>
<key>nchan</key>
<value>1</value>
</param>
<param>
<key>samp_rate</key>
<value>samp_rate</value>
</param>
<param>
<key>center_freq0</key>
<value>400000</value>
</param>
<param>
<key>gain0</key>
<value>3</value>
</param>
<param>
<key>ant0</key>
<value></value>
</param>
<param>
<key>bw0</key>
<value>0</value>
</param>
<param>
<key>center_freq1</key>
<value>0</value>
</param>
<param>
<key>gain1</key>
<value>0</value>
</param>
<param>
<key>ant1</key>
<value></value>
</param>
<param>
<key>bw1</key>
<value>0</value>
</param>
<param>
<key>center_freq2</key>
<value>0</value>
</param>
<param>
<key>gain2</key>
<value>0</value>
</param>
<param>
<key>ant2</key>
<value></value>
</param>
<param>
<key>bw2</key>
<value>0</value>
</param>
<param>
<key>center_freq3</key>
<value>0</value>
</param>
<param>
<key>gain3</key>
<value>0</value>
</param>
<param>
<key>ant3</key>
<value></value>
</param>
<param>
<key>bw3</key>
<value>0</value>
</param>
<param>
<key>center_freq4</key>
<value>0</value>
</param>
<param>
<key>gain4</key>
<value>0</value>
</param>
<param>
<key>ant4</key>
<value></value>
</param>
<param>
<key>bw4</key>
<value>0</value>
</param>
<param>
<key>center_freq5</key>
<value>0</value>
</param>
<param>
<key>gain5</key>
<value>0</value>
</param>
<param>
<key>ant5</key>
<value></value>
</param>
<param>
<key>bw5</key>
<value>0</value>
</param>
<param>
<key>center_freq6</key>
<value>0</value>
</param>
<param>
<key>gain6</key>
<value>0</value>
</param>
<param>
<key>ant6</key>
<value></value>
</param>
<param>
<key>bw6</key>
<value>0</value>
</param>
<param>
<key>center_freq7</key>
<value>0</value>
</param>
<param>
<key>gain7</key>
<value>0</value>
</param>
<param>
<key>ant7</key>
<value></value>
</param>
<param>
<key>bw7</key>
<value>0</value>
</param>
<param>
<key>center_freq8</key>
<value>0</value>
</param>
<param>
<key>gain8</key>
<value>0</value>
</param>
<param>
<key>ant8</key>
<value></value>
</param>
<param>
<key>bw8</key>
<value>0</value>
</param>
<param>
<key>center_freq9</key>
<value>0</value>
</param>
<param>
<key>gain9</key>
<value>0</value>
</param>
<param>
<key>ant9</key>
<value></value>
</param>
<param>
<key>bw9</key>
<value>0</value>
</param>
<param>
<key>center_freq10</key>
<value>0</value>
</param>
<param>
<key>gain10</key>
<value>0</value>
</param>
<param>
<key>ant10</key>
<value></value>
</param>
<param>
<key>bw10</key>
<value>0</value>
</param>
<param>
<key>center_freq11</key>
<value>0</value>
</param>
<param>
<key>gain11</key>
<value>0</value>
</param>
<param>
<key>ant11</key>
<value></value>
</param>
<param>
<key>bw11</key>
<value>0</value>
</param>
<param>
<key>center_freq12</key>
<value>0</value>
</param>
<param>
<key>gain12</key>
<value>0</value>
</param>
<param>
<key>ant12</key>
<value></value>
</param>
<param>
<key>bw12</key>
<value>0</value>
</param>
<param>
<key>center_freq13</key>
<value>0</value>
</param>
<param>
<key>gain13</key>
<value>0</value>
</param>
<param>
<key>ant13</key>
<value></value>
</param>
<param>
<key>bw13</key>
<value>0</value>
</param>
<param>
<key>center_freq14</key>
<value>0</value>
</param>
<param>
<key>gain14</key>
<value>0</value>
</param>
<param>
<key>ant14</key>
<value></value>
</param>
<param>
<key>bw14</key>
<value>0</value>
</param>
<param>
<key>center_freq15</key>
<value>0</value>
</param>
<param>
<key>gain15</key>
<value>0</value>
</param>
<param>
<key>ant15</key>
<value></value>
</param>
<param>
<key>bw15</key>
<value>0</value>
</param>
<param>
<key>_coordinate</key>
<value>(828, 246)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>gr_multiply_const_vxx</key>
<param>
<key>id</key>
<value>gr_multiply_const_vxx_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>complex</value>
</param>
<param>
<key>const</key>
<value>0.1</value>
</param>
<param>
<key>vlen</key>
<value>1</value>
</param>
<param>
<key>_coordinate</key>
<value>(635, 263)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>options</key>
<param>
<key>id</key>
<value>tx</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>title</key>
<value></value>
</param>
<param>
<key>author</key>
<value></value>
</param>
<param>
<key>description</key>
<value></value>
</param>
<param>
<key>window_size</key>
<value>1280, 1024</value>
</param>
<param>
<key>generate_options</key>
<value>qt_gui</value>
</param>
<param>
<key>category</key>
<value>Custom</value>
</param>
<param>
<key>run_options</key>
<value>prompt</value>
</param>
<param>
<key>run</key>
<value>True</value>
</param>
<param>
<key>realtime_scheduling</key>
<value></value>
</param>
<param>
<key>_coordinate</key>
<value>(10, 10)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>blks2_dxpsk_mod</key>
<param>
<key>id</key>
<value>blks2_dxpsk_mod_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>dqpsk</value>
</param>
<param>
<key>samples_per_symbol</key>
<value>4</value>
</param>
<param>
<key>excess_bw</key>
<value>0.35</value>
</param>
<param>
<key>gray_code</key>
<value>True</value>
</param>
<param>
<key>verbose</key>
<value>False</value>
</param>
<param>
<key>log</key>
<value>False</value>
</param>
<param>
<key>_coordinate</key>
<value>(425, 238)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>random_source_x</key>
<param>
<key>id</key>
<value>random_source_x_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>byte</value>
</param>
<param>
<key>min</key>
<value>0</value>
</param>
<param>
<key>max</key>
<value>255</value>
</param>
<param>
<key>num_samps</key>
<value>10</value>
</param>
<param>
<key>repeat</key>
<value>True</value>
</param>
<param>
<key>_coordinate</key>
<value>(183, 239)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>variable</key>
<param>
<key>id</key>
<value>samp_rate</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>value</key>
<value>60000</value>
</param>
<param>
<key>_coordinate</key>
<value>(10, 170)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<connection>
<source_block_id>random_source_x_0</source_block_id>
<sink_block_id>blks2_dxpsk_mod_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>gr_multiply_const_vxx_0</source_block_id>
<sink_block_id>uhd_usrp_sink_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>blks2_dxpsk_mod_0</source_block_id>
<sink_block_id>gr_multiply_const_vxx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
</flow_graph>
Hi,

the simple GRC in the attachment creates lots of underflows on our E100
("U" on console)
and dropouts when looking at the spectrum.

Is this as expected or how can this overload of the embedded Linux be
avoided?

Thanks,
Ralf

Re: [Discuss-gnuradio] Raised Cosine Filter design

That is the best source currently in my opinion especially his discussion of HOW BAD RAISED COSINE FILTERS ARE AS NYQUIST FILTERS FOR DATA TRANSMISSION.

Bob

On Jun 29, 2011 4:11 AM, "John Andrews" <gnu.fanz@gmail.com> wrote:
> Yep! Done. fred harris' book helped the most.
>
> Thanks
>
> On Tue, Jun 28, 2011 at 12:25 PM, Colby Boyer <colby.boyer@gmail.com> wrote:
>
>> Look at the source code used to generate the raised cosine, gr_firdes.h
>> should point to it. Making your own should follow directly from that; also
>> the wikipedia page on the raised cosine is also nice.
>>
>> Its not black magic, so do not fear the source. :P
>>
>> --Colby
>>
>> On Tue, Jun 28, 2011 at 9:12 AM, John Andrews <gnu.fanz@gmail.com> wrote:
>>
>>> Hi,
>>> I want a raised cosine filter for the transmitter and can someone lead me
>>> to a place where I can develop one similar to what we have in gr_firdes.h
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>

Re: [Discuss-gnuradio] using fftw for neon with gnuradio

Could somebody post the whole configure call once the vesperix fftw lib was installed?

I'm giving this a try here myself but want to make sure I'm on the right track.

./configure --disable-volk --disable-usrp2 --disable-usrp1 --disable-gr-video-sdl --enable-shared CFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC" CXXFLAGS="-march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -O3 -fPIC" -with-qwt-incdir=/usr/include

On Wed, Jun 22, 2011 at 5:26 PM, Thomas Tsou <ttsou@vt.edu> wrote:

On Wed, Jun 22, 2011 at 2:13 PM, Philip Balister <philip@balister.org> wrote:
>
> Did you rerun configure adding -fPIC to CFLAGS? I ddi get the library to
> build as a shared library.

That worked for me.

Thomas

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cannot import name VERSION

On Tue, Jun 28, 2011 at 08:41:24AM -0400, Randy Westlund wrote:
> Problem solved. It works if I launch with the command `gnuradio-companion' and
> not with `grc.' I still don't know why that changed overnight, but now this
> machine launches with the first command and my other machines only launch with
> `grc.' I'm running Ubuntu 10.10 on all of them, and I installed gnuradio in
> parallel on my machines. But so long as it runs, I'm not complaining. Thanks
> for the help guys.

Hi Randy,

the name was changed from grc to gnuradio-companion many, many revisions
ago. If you still have a grc executable, you still have old stuff on
your machine.

--
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association