GNU Radio, One Step at a Time: April 2011

Saturday, April 30, 2011

Re: [Discuss-gnuradio] Some questions for the USRP2

Hello, Bomi. Welcome to the new world!

1. USRP2 uses GbE(gigabit ethernet) interface to transmit and receive data(raw samples and control messages). It has a UART available, but you cannot see it unless you open the case.

2. The term 'reliably' largely depends on the circumstances. Especially on the host computer. Matt and community members once compiled a list of GbE lan cards/chipsets works with USRP2. See this page : http://gnuradio.org/redmine/wiki/1/USRP2GigEReports

3. For the connector, I cannot help you at this moment because my USRP2 is at home and I'm 4,000 miles away. :-( But I expect somebody here would help you soon with this. Are you planning to design your own board?

It seems that you did not stop by the gnuradio wiki page. Please check this page : http://gnuradio.org/redmine/wiki/gnuradio/USRP2GenFAQ

I'm sure it would help you a lot.

Regards,

Ilkyoung

2011년 4월 28일 오후 6:01, 김보미 <bomikim@postech.ac.kr>님의 말:

Hello. J

I am a novice usrp2 user.

So my questions might do not make sense.

I hope you understand me.

1)

I wonder how USRP2 transmit and receive the data with host(com).

Which UART model does the USRP2 contain?

2)

How many samples does USRP2 transmit to the host reliably?

Is the sample rate related rather than the number of sample?

3)

I want to know which connector(? or port?) is used between the mother board and daughter board.

I knew that this has 64 pins from the schematic. But I couldn’t get more information about that.

Thank you in advance for your support.

-Bomi

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

Re: [Discuss-gnuradio] Questions about the qt frequency display.

So the spectrum looks correct. To get the x-axis to display a center
frequency of 22050, you need to check the box "display RF frequencies".

I think that "display RF frequencies" should be the default behavior,
but I will leave that decision to Tom.

-Josh

On 04/30/2011 07:47 AM, Stefan Gofferje wrote:
> On 04/30/2011 05:38 PM, Marcus D. Leech wrote:
>> The bandwidth is used to determine both the axis labels, and the correct
>> decimation parameters
>> to use to produce the desired display rate. The center frequency is
>> purely used set axis labels.
>
>> I'd still recommend posting your .GRC file here.
>
> <?xml version='1.0' encoding='ASCII'?>
> <flow_graph>
> <timestamp>Sat Apr 30 17:25:44 2011</timestamp>
> <block>
> <key>options</key>
> <param>
> <key>id</key>
> <value>top_block</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>1200,600</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>variable</key>
> <param>
> <key>id</key>
> <value>samp_rate</value>
> </param>
> <param>
> <key>_enabled</key>
> <value>True</value>
> </param>
> <param>
> <key>value</key>
> <value>44100</value>
> </param>
> <param>
> <key>_coordinate</key>
> <value>(10, 170)</value>
> </param>
> <param>
> <key>_rotation</key>
> <value>0</value>
> </param>
> </block>
> <block>
> <key>gr_add_xx</key>
> <param>
> <key>id</key>
> <value>gr_add_xx_0</value>
> </param>
> <param>
> <key>_enabled</key>
> <value>True</value>
> </param>
> <param>
> <key>type</key>
> <value>float</value>
> </param>
> <param>
> <key>num_inputs</key>
> <value>2</value>
> </param>
> <param>
> <key>vlen</key>
> <value>1</value>
> </param>
> <param>
> <key>_coordinate</key>
> <value>(579, 223)</value>
> </param>
> <param>
> <key>_rotation</key>
> <value>0</value>
> </param>
> </block>
> <block>
> <key>gr_throttle</key>
> <param>
> <key>id</key>
> <value>gr_throttle_0</value>
> </param>
> <param>
> <key>_enabled</key>
> <value>True</value>
> </param>
> <param>
> <key>type</key>
> <value>float</value>
> </param>
> <param>
> <key>samples_per_second</key>
> <value>samp_rate</value>
> </param>
> <param>
> <key>vlen</key>
> <value>1</value>
> </param>
> <param>
> <key>_coordinate</key>
> <value>(716, 235)</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>float</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>22050</value>
> </param>
> <param>
> <key>bw</key>
> <value>44100</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>False</value>
> </param>
> <param>
> <key>gui_hint</key>
> <value>:0,0,1,1</value>
> </param>
> <param>
> <key>_coordinate</key>
> <value>(913, 212)</value>
> </param>
> <param>
> <key>_rotation</key>
> <value>0</value>
> </param>
> </block>
> <block>
> <key>gr_sig_source_x</key>
> <param>
> <key>id</key>
> <value>gr_sig_source_x_0</value>
> </param>
> <param>
> <key>_enabled</key>
> <value>True</value>
> </param>
> <param>
> <key>type</key>
> <value>float</value>
> </param>
> <param>
> <key>samp_rate</key>
> <value>samp_rate</value>
> </param>
> <param>
> <key>waveform</key>
> <value>gr.GR_SIN_WAVE</value>
> </param>
> <param>
> <key>freq</key>
> <value>1000</value>
> </param>
> <param>
> <key>amp</key>
> <value>1</value>
> </param>
> <param>
> <key>offset</key>
> <value>0</value>
> </param>
> <param>
> <key>_coordinate</key>
> <value>(364, 137)</value>
> </param>
> <param>
> <key>_rotation</key>
> <value>0</value>
> </param>
> </block>
> <block>
> <key>gr_sig_source_x</key>
> <param>
> <key>id</key>
> <value>gr_sig_source_x_1</value>
> </param>
> <param>
> <key>_enabled</key>
> <value>True</value>
> </param>
> <param>
> <key>type</key>
> <value>float</value>
> </param>
> <param>
> <key>samp_rate</key>
> <value>samp_rate</value>
> </param>
> <param>
> <key>waveform</key>
> <value>gr.GR_SIN_WAVE</value>
> </param>
> <param>
> <key>freq</key>
> <value>5000</value>
> </param>
> <param>
> <key>amp</key>
> <value>1</value>
> </param>
> <param>
> <key>offset</key>
> <value>0</value>
> </param>
> <param>
> <key>_coordinate</key>
> <value>(361, 282)</value>
> </param>
> <param>
> <key>_rotation</key>
> <value>0</value>
> </param>
> </block>
> <connection>
> <source_block_id>gr_sig_source_x_0</source_block_id>
> <sink_block_id>gr_add_xx_0</sink_block_id>
> <source_key>0</source_key>
> <sink_key>0</sink_key>
> </connection>
> <connection>
> <source_block_id>gr_sig_source_x_1</source_block_id>
> <sink_block_id>gr_add_xx_0</sink_block_id>
> <source_key>0</source_key>
> <sink_key>1</sink_key>
> </connection>
> <connection>
> <source_block_id>gr_add_xx_0</source_block_id>
> <sink_block_id>gr_throttle_0</sink_block_id>
> <source_key>0</source_key>
> <sink_key>0</sink_key>
> </connection>
> <connection>
> <source_block_id>gr_throttle_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>
> </flow_graph>

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

Re: [Discuss-gnuradio] Assertion "imu >= 0" failed on random times

Hi Tom,

thanks for your explanation and sorry for my late reply.

> What block are you using to call the interpolator? What values is the block working off? If it's the M&M clock recovery block, it's possible that the amplitude your input signal is too high, which is causing overly-large error values that are resulting in mu being driven negative.
You're right, it's the M&M clock recovery block, which calls the interpolator.

What do you mean with "that the amplitude your input signal is too high"?
Are there any restricts concerning amplitudes inside the flowgraph?

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

Re: [Discuss-gnuradio] How to delete and create a new top_block?

> So to me that sounds like the scheduler called the work() routine after
> the block was stopped (which is what seems to have happened). This seems
> incorrect... Perhaps its because tb.stop() stops the streaming, but
> tb.wait() can continue to call work()?
>

Can you try this diff, I think it solves the problem if my hunch above
is correct: http://pastebin.com/zMCP6LHh

-Josh

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

Re: [Discuss-gnuradio] Questions about the qt frequency display.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/30/2011 05:38 PM, Marcus D. Leech wrote:
> The bandwidth is used to determine both the axis labels, and the correct
> decimation parameters
> to use to produce the desired display rate. The center frequency is
> purely used set axis labels.
>
> I'd still recommend posting your .GRC file here.

<?xml version='1.0' encoding='ASCII'?>
<flow_graph>
<timestamp>Sat Apr 30 17:25:44 2011</timestamp>
<block>
<key>options</key>
<param>
<key>id</key>
<value>top_block</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>1200,600</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>variable</key>
<param>
<key>id</key>
<value>samp_rate</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>value</key>
<value>44100</value>
</param>
<param>
<key>_coordinate</key>
<value>(10, 170)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>gr_add_xx</key>
<param>
<key>id</key>
<value>gr_add_xx_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>float</value>
</param>
<param>
<key>num_inputs</key>
<value>2</value>
</param>
<param>
<key>vlen</key>
<value>1</value>
</param>
<param>
<key>_coordinate</key>
<value>(579, 223)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>gr_throttle</key>
<param>
<key>id</key>
<value>gr_throttle_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>float</value>
</param>
<param>
<key>samples_per_second</key>
<value>samp_rate</value>
</param>
<param>
<key>vlen</key>
<value>1</value>
</param>
<param>
<key>_coordinate</key>
<value>(716, 235)</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>float</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>22050</value>
</param>
<param>
<key>bw</key>
<value>44100</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>False</value>
</param>
<param>
<key>gui_hint</key>
<value>:0,0,1,1</value>
</param>
<param>
<key>_coordinate</key>
<value>(913, 212)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>gr_sig_source_x</key>
<param>
<key>id</key>
<value>gr_sig_source_x_0</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>float</value>
</param>
<param>
<key>samp_rate</key>
<value>samp_rate</value>
</param>
<param>
<key>waveform</key>
<value>gr.GR_SIN_WAVE</value>
</param>
<param>
<key>freq</key>
<value>1000</value>
</param>
<param>
<key>amp</key>
<value>1</value>
</param>
<param>
<key>offset</key>
<value>0</value>
</param>
<param>
<key>_coordinate</key>
<value>(364, 137)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<block>
<key>gr_sig_source_x</key>
<param>
<key>id</key>
<value>gr_sig_source_x_1</value>
</param>
<param>
<key>_enabled</key>
<value>True</value>
</param>
<param>
<key>type</key>
<value>float</value>
</param>
<param>
<key>samp_rate</key>
<value>samp_rate</value>
</param>
<param>
<key>waveform</key>
<value>gr.GR_SIN_WAVE</value>
</param>
<param>
<key>freq</key>
<value>5000</value>
</param>
<param>
<key>amp</key>
<value>1</value>
</param>
<param>
<key>offset</key>
<value>0</value>
</param>
<param>
<key>_coordinate</key>
<value>(361, 282)</value>
</param>
<param>
<key>_rotation</key>
<value>0</value>
</param>
</block>
<connection>
<source_block_id>gr_sig_source_x_0</source_block_id>
<sink_block_id>gr_add_xx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>gr_sig_source_x_1</source_block_id>
<sink_block_id>gr_add_xx_0</sink_block_id>
<source_key>0</source_key>
<sink_key>1</sink_key>
</connection>
<connection>
<source_block_id>gr_add_xx_0</source_block_id>
<sink_block_id>gr_throttle_0</sink_block_id>
<source_key>0</source_key>
<sink_key>0</sink_key>
</connection>
<connection>
<source_block_id>gr_throttle_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>
</flow_graph>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk28IRIACgkQbQKZlCdPOMNCBwCfc2++pWqm7HUm80Hxkk1QL11m
e7MAn34aLlXuqbiJk+RD6p/BdjjTiQWH
=HRuz
-----END PGP SIGNATURE-----

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

Re: [Discuss-gnuradio] Questions about the qt frequency display.

> On 04/30/2011 05:07 PM, Marcus D. Leech wrote:
>
> > In situations like this, it's usually helpful to the assembled multitude
> > here to post
> > your .grc file, to help in diagnosis, or, post a screen-shot of your
> > GRC flow-graph
> > at least. Just makes it easier for people to spot the obvious errors.
>
> Well, as I said - I did nothing else but connect a signal source
> (cosine, 1kHz) to the qt sink. Sample rate 44.1kHz, center frequency
> 22050Hz.
>
> In a spectrum display I would expect a spike, well, at 1khz, i.e. pretty
> much left in the display. With 2 signal sources (at 1 and 5KHz), I would
> expect 2 spikes.
> Maybe I didn't get the concept of the qt frequency display right...
> Is it a plain stupid spectrum display or does it do some processing on
> it's own? It also doesn't really seem to matter what I set as bandwidth
> and center frequency. Are those parameters only for the axis labels?
>
The bandwidth is used to determine both the axis labels, and the correct
decimation parameters
to use to produce the desired display rate. The center frequency is
purely used set axis labels.

I'd still recommend posting your .GRC file here.

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

--
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] Questions about the qt frequency display.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/30/2011 05:07 PM, Marcus D. Leech wrote:

> In situations like this, it's usually helpful to the assembled multitude
> here to post
> your .grc file, to help in diagnosis, or, post a screen-shot of your
> GRC flow-graph
> at least. Just makes it easier for people to spot the obvious errors.

Well, as I said - I did nothing else but connect a signal source
(cosine, 1kHz) to the qt sink. Sample rate 44.1kHz, center frequency
22050Hz.

In a spectrum display I would expect a spike, well, at 1khz, i.e. pretty
much left in the display. With 2 signal sources (at 1 and 5KHz), I would
expect 2 spikes.
Maybe I didn't get the concept of the qt frequency display right...
Is it a plain stupid spectrum display or does it do some processing on
it's own? It also doesn't really seem to matter what I set as bandwidth
and center frequency. Are those parameters only for the axis labels?

- --
(o_ Stefan Gofferje | SCLT, MCP, CCSA
//\ Reg'd Linux User #247167 | VCP #2263
V_/_ Heckler & Koch - the original point and click interface
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk28HNUACgkQbQKZlCdPOMN4NACgnhWY+ioIVdMzrfPHb+F90afX
H5EAoJXzAbK9oke6vl2GQ5GF/uSmekmo
=/Qp2
-----END PGP SIGNATURE-----

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

Re: [Discuss-gnuradio] Questions about the qt frequency display.

> Hi,
>
> during my experimenting I connected the qt freq display just directly to
> an audio source. sample_rate is set to 44.1k, center freq to 22.05k.
>
> I absolutely did not see what I expected to see, so I connected the
> display to a signal source, sending a 1k sinus tone.
>
> Instead of seeing one spike pretty much left on the display, I saw a
> spike in the center.
> Next I took a 2nd signal source at 5k, put both sources through an add
> operator into the display and instead of 2 spikes, there still was only
> one spike in the center.
>
> What do I miss here?
>
> -S
>
>
In situations like this, it's usually helpful to the assembled multitude
here to post
your .grc file, to help in diagnosis, or, post a screen-shot of your
GRC flow-graph
at least. Just makes it easier for people to spot the obvious errors.

Cheers

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

--
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

[Discuss-gnuradio] Questions about the qt frequency display.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

during my experimenting I connected the qt freq display just directly to
an audio source. sample_rate is set to 44.1k, center freq to 22.05k.

I absolutely did not see what I expected to see, so I connected the
display to a signal source, sending a 1k sinus tone.

Instead of seeing one spike pretty much left on the display, I saw a
spike in the center.
Next I took a 2nd signal source at 5k, put both sources through an add
operator into the display and instead of 2 spikes, there still was only
one spike in the center.

What do I miss here?

- -S

iEYEARECAAYFAk276YgACgkQbQKZlCdPOMNuKQCgrYd81zx4Om2mLypmuJ62kpRv
JIMAn0tqaWoSIfgat7ZonR4YeUu6A3tT
=07/9
-----END PGP SIGNATURE-----

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

Friday, April 29, 2011

Re: [Discuss-gnuradio] Audio sink busy / segfaults of WX FFT + WX Waterfall

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Now also the WX scope segfaults.
I tried any combination of setting/unsetting LIBGL_ALWAYS_INDIRECT
(found via Google) and style=nongl / gl. I can't see a pattern.

iEYEARECAAYFAk27skgACgkQbQKZlCdPOMNKJwCgrSPvnAfMTEhdyIdmrlPOjSaH
sv4An166Xt4LKGdwIfY+p/ZVdu6KJ2S0
=Ys3k
-----END PGP SIGNATURE-----

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

Re: [Discuss-gnuradio] How to delete and create a new top_block?

On 04/29/2011 06:58 AM, Patrik Eliardsson wrote:
> Hi,
>
> After I stop a top_block, is it possible to create a new top_block and start it without exiting my python application?
>
> My experience is that it doesn't work very well. I get the following error when I instantiate a new top_block and start it.
> "UHD source block got error code 0x1
> gr_block_executor: source <gr_block gr uhd usrp source (9)> produced no output. We're marking it DONE."
>

If it helps, that error is from a timeout where the uhd recv() function
timed out getting samples causing the work() function to return 0. Now,
the tb.stop() called the source block's stop() function to tell the USRP
to stop streaming.

So to me that sounds like the scheduler called the work() routine after
the block was stopped (which is what seems to have happened). This seems
incorrect... Perhaps its because tb.stop() stops the streaming, but
tb.wait() can continue to call work()?

-Josh

> I've attached a small example that triggers the error.
>
> Best regards
> Patrik
>
>
>
> _______________________________________________
> 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] FSK modulation

HI Pascal,

If you google for GRC tutorials, you should easily find some good ones on the web. FSK is definitely possible to the best of my knowledge.

Data packets with header,.. CRC can be transmitted but I think you need to store the bit sequence in a file and the received and demodulated data also gets stored in a file. I think it might be possible to dynamically generate CRC, data and all, but this needs some special custom block at least within GRC (anyone please feel free to correct me). If you do figure out how to do this, please do write up a tutorial on this :-)

You can easily get I/Q data at least with python and GRC. Alexandru Csete, a poster on this forum has written some good examples that cover all of the above (you can easily google his website and download all the GRC examples that he has written; thank you Alex!!).

Best regards,
-Vijay

--- On Fri, 4/29/11, Pascal Matthieu <pascalmatthieu75@yahoo.com> wrote:

From: Pascal Matthieu <pascalmatthieu75@yahoo.com>
Subject: [Discuss-gnuradio] FSK modulation
To: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
Date: Friday, April 29, 2011, 2:05 PM

Hi,

I would like to ask a few questions regarding USRP, UHD and GNU Radio. I have 2 USRP devices and one module I bought that's able transmitt and receive on 433.92 MHz. I installed UHD on 2 computers (both with Win XP OS), connected to each one a USRP1 that has a WBX daughterboard and a Log Periodic type antenna by Kent Electronics that's on Ettus order page. Both USRP's are recognized.

1. I would like to send some data packets that will have FSK and GFSK modulation. With one USRP I will receive data coming from the module and data coming from the second USRP. Each packet will have some data in it to be identified, so that I could log it. As I am a newbie I would like to ask if there are any test examples for GRC or simply Python to modify it to meet my requirements. Honestly I don't know where to start. There are blocks for AM, FM, DPSK, GMSK, QAM and others, each one heaving a MOD and DEMOD block but no blocks for FSK.

2. My packets will have the following layout a Preamble, a Header for identification, a number of bytes of data, and CRC data at the end. At transmitter I send data packets (many 1/0 values that are put on a carrier signal - in FSK signal we have a frequency for the 1 and a different frequency for 0). If there were a block to demodulate FSK modulated sugnals it would pass me some 1 0 1 0 1 1 0 1 1 1 1 1 0 0 1 .... from which I would have to recognize my header, if I recognize it, then the next byte of data should be the representation of the length of data, to know how many bytes I will have to receive until I reach to the end where I will have to know the length of my CRC data. After I receive the CRC the packet is finished, I can process data that I will put previously into a buffer and start to interprete bytes of data (who sent the packet, etc.). If CRC is not the same as received then it means it has errors and data is not usable. Is it correct how I'm thinking the problem or I should tink in a different way.

3. My first steps will be to try some source code in Python but after that I plan to make my own interface to control these devices (the second USRP and the module). I don't really know how to get the I/Q data from USRP, how to set different parameters like center frequency and others. There's any partial or full documentation related to this. If I could use the Visual Studio I would be able to make some GUI. If there's no souce code written for FSK maybe based on other codes written for other modulation types, I will make one, but ther's little chance for that to work, anyway I will have to know how to get I/Q data from USRP, how to write .rbf file to FPGA, and others.

Thank you very much.

Pascal.

-----Inline Attachment Follows-----

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

Re: [Discuss-gnuradio] Cross band relais / bridge - DMR?

Hi Nick,

High end fractional N PLL's generally have a settling time of 100us or less if it is shifting to another frequency in the same band (say within 100MHz) assuming a high enough loop bandwidth. If it is starting up for the first time, then a few ms of settling time is ok.

I am just wondering what other factors/latencies that cause a settling time of several ms all the time?

Best regards,
-Vijay

--- On Fri, 4/29/11, Nick Foster <nick@ettus.com> wrote:

From: Nick Foster <nick@ettus.com>
Subject: Re: [Discuss-gnuradio] Cross band relais / bridge - DMR?
To: "Feng Andrew Ge" <gefengflorry@gmail.com>
Cc: discuss-gnuradio@gnu.org
Date: Friday, April 29, 2011, 3:51 PM

On Fri, 2011-04-29 at 15:42 -0400, Feng Andrew Ge wrote:
> Nick,
>
> Could you confirm that switching TX frequency takes "a few ms"? How did
> you get this number? Is it the same for switching TX frequency after
> the code has been running for a while, that is, reconfiguring the TX
> frequency dynamically?

We don't have a guaranteed spec for PLL settling time on the WBX, and we
encourage users to experimentally determine the settling time for their
particular setup and frequency. The figure I gave is based on what I've
seen in the lab, to the best of my recollection. =) It should be pretty
straightforward to determine the settling time for your setup and
frequency step by taking a data capture of a known source.

Any time you retune a PLL VCO, it will take some time to settle. If you
need to avoid that settling time, you can do CORDIC-only tuning with the
advanced tuning parameters to shift around within the bandwidth of your
ADC. This will provide a basically instantaneous tuning speed within a
range of 50MHz for USRP2/N2XX, or 32MHz for USRP1/E100.

--n

>
> Andrew
>
> On 04/29/2011 12:00 PM, discuss-gnuradio-request@gnu.org wrote:
> > Every time you tune the TX you'll have to wait a few ms for it to become
> > stable. For voice transmission purposes, a few ms is effectively
> > instantaneous anyway. And if you aren't retuning, then it will come up
> > instantly, because the LO will still be running in between sample
> > bursts.
> >
> > --n
> >
>

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

Re: [Discuss-gnuradio] Question for installation of UHD driver

That is where ever you checked the repository out to. So if I am in my
home directory (/home/me/) and I ran the git command to checkout the
repository, <uhd-repo-path> would be /home/me/uhd/. The same is true
if you downloaded the archive (zip or tar.gz)

Mike

On Fri, Apr 29, 2011 at 8:05 PM, Nakajo Tomoyuki <nakajo@fukui-ut.ac.jp> wrote:
> Hello,
>
> I have a question about installation of UHD driver.
> Please teach me the location of directory "<uhd-repo-path>".
>
> In the stage of generation of makefiles with cmake, the following comannd,
>
> cd <uhd-repo-path>/host
>
> is needed, but I cannot find the directory <uhd-repo-path>/host.
>
>
> Regards
>
> --
> ---------------------------------------------------
> Nakajo Tomoyuki
> Fukui University of Technology
> Department of Electrical,Electronics and Computer Engineering
> e-mail:nakajo@fukui-ut.ac.jp
> ---------------------------------------------------
>
>
>
> _______________________________________________
> 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

[Discuss-gnuradio] Question for installation of UHD driver

Hello,

I have a question about installation of UHD driver.
Please teach me the location of directory "<uhd-repo-path>".

In the stage of generation of makefiles with cmake, the following comannd,

cd <uhd-repo-path>/host

is needed, but I cannot find the directory <uhd-repo-path>/host.

Regards

--
---------------------------------------------------
Nakajo Tomoyuki
Fukui University of Technology
Department of Electrical,Electronics and Computer Engineering
e-mail:nakajo@fukui-ut.ac.jp
---------------------------------------------------

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

Re: [Discuss-gnuradio] FSK modulation

Hi Marcus,

   yes I read a while ago and I will use code from FM.

   GNURadio is a very interesting software development toolkit. It's very usefull when trying to make some research, to try out many interesting things, but if you intend to make something that will be installed on certain computers in hundreds of different locations, you can't tell that they should install GNURadio, and install Python and Install I don't know how many dependencies, and an application will run some python code that will glue together some functions written in C++ and so on; you have to give a single executable, that will interact with some DLL files like the UHD to get data from different SDR platforms (the USRP in my case or maybe other Ettus devices).

  In Visual Studio I can make a professional GUI. As you said, yes I can use UHD to program USRP's FPGA, to get I/Q data and after that I could make my own software (containing GNURadio source code) to be able to do many interesting things. Anyway if GNURadio is compiled (gnuradio-core.dll) I could call functions directly from this DLL (I saw how functions are exported), anyway I don't know if functions use anything from boost and other libraries. So the idea is to be able to make own GUI in Visual Studio not python, to use functions from these libraries (UHD, gnuradio-core and others that might help) to make a fully functional software without the need to install Python; I will use some custom scripting language to set different parameters and specify some other libraries to modulate/demodulate or respectively encode/decode data.

  The only thing to make my custom software is to find out how to use and how to call different functions from compiled DLL files and for this I will use example source codes.

  So as a final word GNURadio together with UHD are very valuable, what I don't like is python, and the idea that I would have to run some extra program to glue together C++ blocks, I like native code :). Anyway at the beginning I will use these tools to learn, and to make the project, after that I will move everything to my software. I was only interested if what I described at point nr. 2 is correct, with the received data, and the logic.

Thanks you Marcus for your answers. Have a nice day.

Pascal.

While I agree that the GUI elements within Gnu Radio leave something to be desired in terms of functionality and beauty, I think that concepts
within Gnu Radio+UHD are quite sound, and it would be a shame to abandon them.

I have my own application that uses Gnu Radio "under the skirts", but uses an entirely different GUI, based on XForms, and it communicates
with the Gnu Radio flow-graph (which was constructed with GRC) via both the XMLRPC server code, and FIFO files (although this is for
Linux, not Windows).

But you should also know that you no longer need to use Python to "string together" underlying C++ blocks. It can all be done from
C++ these days. There *are* some hierarchical blocks that were only implemented in Python, but all of the core "stuff" you can string
together using C++, instead of Python.

Feel free to build your application any way you want, but the fact is that, these days, just about *all* software has a daunting
dependency graph. Fact of life. You can either re-invent *everything* within your own code, so that it's standalone, or you can
rely on the excellent work of others, and focus more on whatever functionality you're bringing to the table.

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

Re: [Discuss-gnuradio] FSK modulation

Hi Marcus,

yes I read a while ago and I will use code from FM.

GNURadio is a very interesting software development toolkit. It's very usefull when trying to make some research, to try out many interesting things, but if you intend to make something that will be installed on certain computers in hundreds of different locations, you can't tell that they should install GNURadio, and install Python and Install I don't know how many dependencies, and an application will run some python code that will glue together some functions written in C++ and so on; you have to give a single executable, that will interact with some DLL files like the UHD to get data from different SDR platforms (the USRP in my case or maybe other Ettus devices).

In Visual Studio I can make a professional GUI. As you said, yes I can use UHD to program USRP's FPGA, to get I/Q data and after that I could make my own software (containing GNURadio source code) to be able to do many interesting things. Anyway if GNURadio is compiled (gnuradio-core.dll) I could call functions directly from this DLL (I saw how functions are exported), anyway I don't know if functions use anything from boost and other libraries. So the idea is to be able to make own GUI in Visual Studio not python, to use functions from these libraries (UHD, gnuradio-core and others that might help) to make a fully functional software without the need to install Python; I will use some custom scripting language to set different parameters and specify some other libraries to modulate/demodulate or respectively encode/decode data.

The only thing to make my custom software is to find out how to use and how to call different functions from compiled DLL files and for this I will use example source codes.

So as a final word GNURadio together with UHD are very valuable, what I don't like is python, and the idea that I would have to run some extra program to glue together C++ blocks, I like native code :). Anyway at the beginning I will use these tools to learn, and to make the project, after that I will move everything to my software. I was only interested if what I described at point nr. 2 is correct, with the received data, and the logic.

Thanks you Marcus for your answers. Have a nice day.

Pascal.

From: Marcus D. Leech <mleech@ripnet.com>
To: discuss-gnuradio@gnu.org
Sent: Friday, April 29, 2011 9:18 PM
Subject: Re: [Discuss-gnuradio] FSK modulation

On 29/04/2011 2:05 PM, Pascal Matthieu wrote:

Hi,

I would like to ask a few questions regarding USRP, UHD and GNU Radio. I have 2 USRP devices and one module I bought that's able transmitt and receive on 433.92 MHz. I installed UHD on 2 computers (both with Win XP OS), connected to each one a USRP1 that has a WBX daughterboard and a Log Periodic type antenna by Kent Electronics that's on Ettus order page. Both USRP's are recognized.

1. I would like to send some data packets that will have FSK and GFSK modulation. With one USRP I will receive data coming from the module and data coming from the second USRP. Each packet will have some data in it to be identified, so that I could log it. As I am a newbie I would like to ask if there are any test examples for GRC or simply Python to modify it to meet my requirements. Honestly I don't know where to start. There are blocks for AM, FM, DPSK, GMSK, QAM and others, each one heaving a MOD and DEMOD block but no blocks for FSK.

One thing to observe is that FM and FSK are essentially the same thing, with FM having a "continuous" modulation input, and FSK having
a "discrete" (1s and 0s) input.
rors and data is not usable. Is it correct how I'm thinking the problem or I should tink in a different way.

3. My first steps will be to try some source code in Python but after that I plan to make my own interface to control these devices (the second USRP and the module). I don't really know how to get the I/Q data from USRP, how to set different parameters like center frequency and others. There's any partial or full documentation related to this. If I could use the Visual Studio I would be able to make some GUI. If there's no souce code written for FSK maybe based on other codes written for other modulation types, I will make one, but ther's little chance for that to work, anyway I will have to know how to get I/Q data from USRP, how to write .rbf file to FPGA, and others.

Use the source, Luke. All of the source code for Gnu Radio, UHD, and the FPGA code is all there. If you want to build your own interface
to the hardware, all the information is there, in the form of the source code, to do so. But I have to ask--why? Unless you have some
very-stringent requirements, it doesn't sound like what you want to do can't be accomplished with UHD+Gnu Radio. In terms of interesting
intellectual exercises, I can think of others that would be more productive than re-inventing Gnu Radio and UHD.

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

[Discuss-gnuradio] DySPAN

Ettus Research is proud to announce that we are a patron/sponsor of the
IEEE Dynamic Spectrum Access Networks (DySPAN) conference being held in
Aachen, Germany next week. For those who are not familiar with it,
DySPAN is one of the premiere SDR, Cognitive Radio, and Dynamic Spectrum
conferences in the world. You can find more information about it here:

http://www.ieee-dyspan.org/about.html

Nick Foster and I will be at DySPAN in Aachen next week. If you're
attending, or just in town, make sure to come by the Ettus Research
table in the demo area. We will have multiple USRP N210 and E100 demos
running, and would love to talk to any GNU Radio or USRP users.

Those who can't make it can also follow @MattEttus and #dyspan on Twitter.

Matt Ettus

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

Re: [Discuss-gnuradio] Tunnel.py exception

From my experience, the patch does the trigger.

if (string_len> 18)& (string_len< 4095) :

Andrew

On 04/29/2011 04:00 PM, David Barton wrote:

Ok. Would the case I described also cause the same shape exception killing the receive chain. Because anytime it fails on me it always is with 4095 which I cant figure out why.

Thanks,

Dave

From: Feng Andrew Ge <gefengflorry@gmail.com>
To: David Barton <david.barton33@yahoo.com>
Cc: discuss-gnuradio@gnu.org
Sent: Fri, April 29, 2011 2:57:28 PM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception

Dave, yes, what you described is more likely to happen. That will corrupt your received data.

What I described is a special case (with less probability) explaining why you got a payload with a length of 4095 bytes.

Andrew

On 04/29/2011 01:52 PM, David Barton wrote:

Thank you for the explanation. I will try this and let you know.

I had one question though. It seems odd to me that the interference will always cause the header to be corrupted to all ones for both sets of 2 bytes . Wouldnt it be more likely to have sent 80 bytes payload and have lets say 1 bit corrupted ineach (like both change to 81 instead of 80 ) which would cause a error I would think. Since I always see 4095 length as error it seems weird that so many bits are corrupted and all corrputed to be all 1's. I just want to make sure I understand the root cause of the issue.

Thanks,

Dave

From: Feng Andrew Ge <gefengflorry@gmail.com>
To: discuss-gnuradio@gnu.org; David Barton <david.barton33@yahoo.com>
Sent: Fri, April 29, 2011 10:35:52 AM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception

Dave,

In the patch I told you, please change 4096 to 4095, that is,

if (string_len> 18)& (string_len< 4095) :

Here is how this happened:

When you send a packet in GNU Radio, there is a header right ahead the payload (plus CRC bits).
The header has 4 bytes which consist of two same 2-byte information. In each 2-byte, the 12 least significant bits represent the length
of your payload plus CRC; the 4 most significant bits represent whitening offset information.

When you receive the packet, the two lengths contained in each of the 2-byte in the header are compared. If they are the same, say, both x, the receiver
will get the next x bytes information; otherwise, the receiver assumes that the packet is corrupted.

Currently GNU Radio doesn't have any error correction code. Therefore, the header can be corrupted under low SNR or interference.
Even with corruption or interference, in probability, sometimes you will still see the two length information in the header are the same.

In your case (of course it happened to me before, otherwise I won't know), you see 4095 of string_len, it means that the 12 least significant bits
in each of the 2 bytes (in the header) are all 1's, that is " 1111 1111 1111 " (=4095). However, the contained payload---not matter what it is---is actually wrong.

Therefore, the cause is corruption under low SNR or interference. The missing part is error correction code.

By applying the above patch, you can bypass this python code problem.

Andrew

Posted by David Barton (Guest)
on 2011-04-29 15:26

I tried the previously suggested patch that checked the str_len of the
message
before unmaking the packet but errors still occurred. I noticed that
when
printing the size fo packet out the errors occur when the str_len is
exactly
equal to 4095. There is no reason it should be that length as I am only
periodically sending short ping packets. I have yet to figure out why it
is
mistaking the message length. Anyone have any ideas?

Thomas,

What do you mean that the receiver couldnt handle the sender speed?
Where were
the sleeps put in?

Thanks,
Dave

Re: [Discuss-gnuradio] Tunnel.py exception

Ok. Would the case I described also cause the same shape exception killing the receive chain. Because anytime it fails on me it always is with 4095 which I cant figure out why.

Thanks,

Dave

From: Feng Andrew Ge <gefengflorry@gmail.com>
To: David Barton <david.barton33@yahoo.com>
Cc: discuss-gnuradio@gnu.org
Sent: Fri, April 29, 2011 2:57:28 PM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception

Dave, yes, what you described is more likely to happen. That will corrupt your received data.

What I described is a special case (with less probability) explaining why you got a payload with a length of 4095 bytes.

Andrew

On 04/29/2011 01:52 PM, David Barton wrote:

Thank you for the explanation. I will try this and let you know.

I had one question though. It seems odd to me that the interference will always cause the header to be corrupted to all ones for both sets of 2 bytes . Wouldnt it be more likely to have sent 80 bytes payload and have lets say 1 bit corrupted ineach (like both change to 81 instead of 80 ) which would cause a error I would think. Since I always see 4095 length as error it seems weird that so many bits are corrupted and all corrputed to be all 1's. I just want to make sure I understand the root cause of the issue.

Thanks,

Dave

From: Feng Andrew Ge <gefengflorry@gmail.com>
To: discuss-gnuradio@gnu.org; David Barton <david.barton33@yahoo.com>
Sent: Fri, April 29, 2011 10:35:52 AM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception

Dave,

In the patch I told you, please change 4096 to 4095, that is,

if (string_len> 18)& (string_len< 4095) :

Here is how this happened:

When you send a packet in GNU Radio, there is a header right ahead the payload (plus CRC bits).
The header has 4 bytes which consist of two same 2-byte information. In each 2-byte, the 12 least significant bits represent the length
of your payload plus CRC; the 4 most significant bits represent whitening offset information.

When you receive the packet, the two lengths contained in each of the 2-byte in the header are compared. If they are the same, say, both x, the receiver
will get the next x bytes information; otherwise, the receiver assumes that the packet is corrupted.

Currently GNU Radio doesn't have any error correction code. Therefore, the header can be corrupted under low SNR or interference.
Even with corruption or interference, in probability, sometimes you will still see the two length information in the header are the same.

In your case (of course it happened to me before, otherwise I won't know), you see 4095 of string_len, it means that the 12 least significant bits
in each of the 2 bytes (in the header) are all 1's, that is " 1111 1111 1111 " (=4095). However, the contained payload---not matter what it is---is actually wrong.

Therefore, the cause is corruption under low SNR or interference. The missing part is error correction code.

By applying the above patch, you can bypass this python code problem.

Andrew

Posted by David Barton (Guest)
on 2011-04-29 15:26

I tried the previously suggested patch that checked the str_len of the
message
before unmaking the packet but errors still occurred. I noticed that
when
printing the size fo packet out the errors occur when the str_len is
exactly
equal to 4095. There is no reason it should be that length as I am only
periodically sending short ping packets. I have yet to figure out why it
is
mistaking the message length. Anyone have any ideas?

Thomas,

What do you mean that the receiver couldnt handle the sender speed?
Where were
the sleeps put in?

Thanks,
Dave

Re: [Discuss-gnuradio] Cross band relais / bridge - DMR?

On Fri, 2011-04-29 at 15:42 -0400, Feng Andrew Ge wrote:
> Nick,
>
> Could you confirm that switching TX frequency takes "a few ms"? How did
> you get this number? Is it the same for switching TX frequency after
> the code has been running for a while, that is, reconfiguring the TX
> frequency dynamically?

We don't have a guaranteed spec for PLL settling time on the WBX, and we
encourage users to experimentally determine the settling time for their
particular setup and frequency. The figure I gave is based on what I've
seen in the lab, to the best of my recollection. =) It should be pretty
straightforward to determine the settling time for your setup and
frequency step by taking a data capture of a known source.

Any time you retune a PLL VCO, it will take some time to settle. If you
need to avoid that settling time, you can do CORDIC-only tuning with the
advanced tuning parameters to shift around within the bandwidth of your
ADC. This will provide a basically instantaneous tuning speed within a
range of 50MHz for USRP2/N2XX, or 32MHz for USRP1/E100.

--n

>
> Andrew
>
> On 04/29/2011 12:00 PM, discuss-gnuradio-request@gnu.org wrote:
> > Every time you tune the TX you'll have to wait a few ms for it to become
> > stable. For voice transmission purposes, a few ms is effectively
> > instantaneous anyway. And if you aren't retuning, then it will come up
> > instantly, because the LO will still be running in between sample
> > bursts.
> >
> > --n
> >
>

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

Re: [Discuss-gnuradio] Cross band relais / bridge - DMR?

Nick,

Could you confirm that switching TX frequency takes "a few ms"? How did
you get this number? Is it the same for switching TX frequency after
the code has been running for a while, that is, reconfiguring the TX
frequency dynamically?

Andrew

On 04/29/2011 12:00 PM, discuss-gnuradio-request@gnu.org wrote:
> Every time you tune the TX you'll have to wait a few ms for it to become
> stable. For voice transmission purposes, a few ms is effectively
> instantaneous anyway. And if you aren't retuning, then it will come up
> instantly, because the LO will still be running in between sample
> bursts.
>
> --n
>

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

Re: [Discuss-gnuradio] Tunnel.py exception

Dave, yes, what you described is more likely to happen. That will corrupt your received data.

What I described is a special case (with less probability) explaining why you got a payload with a length of 4095 bytes.

Andrew

On 04/29/2011 01:52 PM, David Barton wrote:

Thank you for the explanation. I will try this and let you know.

I had one question though. It seems odd to me that the interference will always cause the header to be corrupted to all ones for both sets of 2 bytes . Wouldnt it be more likely to have sent 80 bytes payload and have lets say 1 bit corrupted ineach (like both change to 81 instead of 80 ) which would cause a error I would think. Since I always see 4095 length as error it seems weird that so many bits are corrupted and all corrputed to be all 1's. I just want to make sure I understand the root cause of the issue.

Thanks,

Dave

From: Feng Andrew Ge <gefengflorry@gmail.com>
To: discuss-gnuradio@gnu.org; David Barton <david.barton33@yahoo.com>
Sent: Fri, April 29, 2011 10:35:52 AM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception

Dave,

In the patch I told you, please change 4096 to 4095, that is,

if (string_len> 18)& (string_len< 4095) :

Here is how this happened:

When you send a packet in GNU Radio, there is a header right ahead the payload (plus CRC bits).
The header has 4 bytes which consist of two same 2-byte information. In each 2-byte, the 12 least significant bits represent the length
of your payload plus CRC; the 4 most significant bits represent whitening offset information.

When you receive the packet, the two lengths contained in each of the 2-byte in the header are compared. If they are the same, say, both x, the receiver
will get the next x bytes information; otherwise, the receiver assumes that the packet is corrupted.

Currently GNU Radio doesn't have any error correction code. Therefore, the header can be corrupted under low SNR or interference.
Even with corruption or interference, in probability, sometimes you will still see the two length information in the header are the same.

In your case (of course it happened to me before, otherwise I won't know), you see 4095 of string_len, it means that the 12 least significant bits
in each of the 2 bytes (in the header) are all 1's, that is " 1111 1111 1111 " (=4095). However, the contained payload---not matter what it is---is actually wrong.

Therefore, the cause is corruption under low SNR or interference. The missing part is error correction code.

By applying the above patch, you can bypass this python code problem.

Andrew

Posted by David Barton (Guest)
on 2011-04-29 15:26

I tried the previously suggested patch that checked the str_len of the
message
before unmaking the packet but errors still occurred. I noticed that
when
printing the size fo packet out the errors occur when the str_len is
exactly
equal to 4095. There is no reason it should be that length as I am only
periodically sending short ping packets. I have yet to figure out why it
is
mistaking the message length. Anyone have any ideas?

Thomas,

What do you mean that the receiver couldnt handle the sender speed?
Where were
the sleeps put in?

Thanks,
Dave

Re: [Discuss-gnuradio] FSK modulation

On 29/04/2011 2:05 PM, Pascal Matthieu wrote:

Hi,

I would like to ask a few questions regarding USRP, UHD and GNU Radio. I have 2 USRP devices and one module I bought that's able transmitt and receive on 433.92 MHz. I installed UHD on 2 computers (both with Win XP OS), connected to each one a USRP1 that has a WBX daughterboard and a Log Periodic type antenna by Kent Electronics that's on Ettus order page. Both USRP's are recognized.

1. I would like to send some data packets that will have FSK and GFSK modulation. With one USRP I will receive data coming from the module and data coming from the second USRP. Each packet will have some data in it to be identified, so that I could log it. As I am a newbie I would like to ask if there are any test examples for GRC or simply Python to modify it to meet my requirements. Honestly I don't know where to start. There are blocks for AM, FM, DPSK, GMSK, QAM and others, each one heaving a MOD and DEMOD block but no blocks for FSK.

3. My first steps will be to try some source code in Python but after that I plan to make my own interface to control these devices (the second USRP and the module). I don't really know how to get the I/Q data from USRP, how to set different parameters like center frequency and others. There's any partial or full documentation related to this. If I could use the Visual Studio I would be able to make some GUI. If there's no souce code written for FSK maybe based on other codes written for other modulation types, I will make one, but ther's little chance for that to work, anyway I will have to know how to get I/Q data from USRP, how to write .rbf file to FPGA, and others.

[Discuss-gnuradio] FSK modulation

Hi,

I would like to ask a few questions regarding USRP, UHD and GNU Radio. I have 2 USRP devices and one module I bought that's able transmitt and receive on 433.92 MHz. I installed UHD on 2 computers (both with Win XP OS), connected to each one a USRP1 that has a WBX daughterboard and a Log Periodic type antenna by Kent Electronics that's on Ettus order page. Both USRP's are recognized.

1. I would like to send some data packets that will have FSK and GFSK modulation. With one USRP I will receive data coming from the module and data coming from the second USRP. Each packet will have some data in it to be identified, so that I could log it. As I am a newbie I would like to ask if there are any test examples for GRC or simply Python to modify it to meet my requirements. Honestly I don't know where to start. There are blocks for AM, FM, DPSK, GMSK, QAM and others, each one heaving a MOD and DEMOD block but no blocks for FSK.

2. My packets will have the following layout a Preamble, a Header for identification, a number of bytes of data, and CRC data at the end. At transmitter I send data packets (many 1/0 values that are put on a carrier signal - in FSK signal we have a frequency for the 1 and a different frequency for 0). If there were a block to demodulate FSK modulated sugnals it would pass me some 1 0 1 0 1 1 0 1 1 1 1 1 0 0 1 .... from which I would have to recognize my header, if I recognize it, then the next byte of data should be the representation of the length of data, to know how many bytes I will have to receive until I reach to the end where I will have to know the length of my CRC data. After I receive the CRC the packet is finished, I can process data that I will put previously into a buffer and start to interprete bytes of data (who sent the packet, etc.). If CRC is not the same as received then it means it has errors and data is not usable. Is it correct how I'm thinking the problem or I should tink in a different way.

3. My first steps will be to try some source code in Python but after that I plan to make my own interface to control these devices (the second USRP and the module). I don't really know how to get the I/Q data from USRP, how to set different parameters like center frequency and others. There's any partial or full documentation related to this. If I could use the Visual Studio I would be able to make some GUI. If there's no souce code written for FSK maybe based on other codes written for other modulation types, I will make one, but ther's little chance for that to work, anyway I will have to know how to get I/Q data from USRP, how to write .rbf file to FPGA, and others.

Thank you very much.

Pascal.

Re: [Discuss-gnuradio] Tunnel.py exception

Thank you for the explanation. I will try this and let you know.

I had one question though. It seems odd to me that the interference will always cause the header to be corrupted to all ones for both sets of 2 bytes . Wouldnt it be more likely to have sent 80 bytes payload and have lets say 1 bit corrupted ineach (like both change to 81 instead of 80 ) which would cause a error I would think. Since I always see 4095 length as error it seems weird that so many bits are corrupted and all corrputed to be all 1's. I just want to make sure I understand the root cause of the issue.

Thanks,

Dave

From: Feng Andrew Ge <gefengflorry@gmail.com>
To: discuss-gnuradio@gnu.org; David Barton <david.barton33@yahoo.com>
Sent: Fri, April 29, 2011 10:35:52 AM
Subject: Re: [Discuss-gnuradio] Tunnel.py exception

Dave,

In the patch I told you, please change 4096 to 4095, that is,

if (string_len> 18)& (string_len< 4095) :

Here is how this happened:

When you send a packet in GNU Radio, there is a header right ahead the payload (plus CRC bits).
The header has 4 bytes which consist of two same 2-byte information. In each 2-byte, the 12 least significant bits represent the length
of your payload plus CRC; the 4 most significant bits represent whitening offset information.

When you receive the packet, the two lengths contained in each of the 2-byte in the header are compared. If they are the same, say, both x, the receiver
will get the next x bytes information; otherwise, the receiver assumes that the packet is corrupted.

Currently GNU Radio doesn't have any error correction code. Therefore, the header can be corrupted under low SNR or interference.
Even with corruption or interference, in probability, sometimes you will still see the two length information in the header are the same.

In your case (of course it happened to me before, otherwise I won't know), you see 4095 of string_len, it means that the 12 least significant bits
in each of the 2 bytes (in the header) are all 1's, that is " 1111 1111 1111 " (=4095). However, the contained payload---not matter what it is---is actually wrong.

Therefore, the cause is corruption under low SNR or interference. The missing part is error correction code.

By applying the above patch, you can bypass this python code problem.

Andrew

Posted by David Barton (Guest)
on 2011-04-29 15:26

I tried the previously suggested patch that checked the str_len of the
message
before unmaking the packet but errors still occurred. I noticed that
when
printing the size fo packet out the errors occur when the str_len is
exactly
equal to 4095. There is no reason it should be that length as I am only
periodically sending short ping packets. I have yet to figure out why it
is
mistaking the message length. Anyone have any ideas?

Thomas,

What do you mean that the receiver couldnt handle the sender speed?
Where were
the sleeps put in?

Thanks,
Dave