DIGITAL RX and TX?

GNU Radio
1

Dear Mister Ahmed Z.-

You might find answers to your questions about receiving and
transmitting in Digital at the DECT project website.

https://dedected.org/trachttps://dedected.org/trac

Have A Nice Day!
----- Original Message -----
From:
[email protected]mailto:[email protected]
To: [email protected]mailto:[email protected]
Sent: Monday, October 22, 2012 5:24 PM
Subject: Discuss-gnuradio Digest, Vol 119, Issue 24

Send Discuss-gnuradio mailing list submissions to
[email protected]mailto:[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
Discuss-gnuradio Info Pagehttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body ‘help’ to
[email protected]mailto:[email protected]

You can reach the person managing the list at
[email protected]mailto:[email protected]

When replying, please edit your Subject line so it is more specific
than “Re: Contents of Discuss-gnuradio digest…”

Today’s Topics:

 1. Re: Blocks missing from GRC after pre-cog installation
    (Sakib C.)
 2. Northern hemisphere notice: Winter is approaching (Patrik T.)
 3. Re: Very weird about my N210 board. (Nowlan, Sean)
 4. No Digital Modulation Working (Ahmed Z.)
 5. Re: Problems passing the control between blocks - message
    passing (Jose T. Diaz)

Message: 1
Date: Mon, 22 Oct 2012 16:52:13 -0400
From: Sakib C.
<[email protected]mailto:[email protected]>
To: [email protected]mailto:[email protected]
Cc: [email protected]mailto:[email protected]
Subject: Re: [Discuss-gnuradio] Blocks missing from GRC after pre-cog
installation
Message-ID:
<[email protected]mailto:[email protected]>
Content-Type: text/plain; charset=“iso-8859-1”

Hi,

I cannot figure out the source of the problem. I don’t have multiple
installations of gnuradio. While I’m installing gnuradio and grextras
(either by the installation script from gnuradio.org website or by
manually), I run git clone commands in ~/Downloads directory. Thus I
have
gnuradio and grextras folders in ~/Downloads folder. So, in the usual
way I
proceed to install, and they are properly installed in /usr/local/ . I
run
GRC and get all the blocks. I attached the screenshot. Then I run git
clone
command for pre-cog in ~/Downloads folder, so I have a pre-cog folder
in
~/Downloads. I then proceed to install it in usual manner (mkdir
build,
cmake, make etc.) and it is properly installed. Then if I run GRC,
blocks
are missing, those that start with gr_*.xml. I have attached the
screenshot
too.

Is there any other specific installation instructions?

Thanks.

On Thu, Oct 18, 2012 at 9:44 PM, Josh B.
<[email protected]mailto:[email protected]> wrote:

On 10/18/2012 11:07 AM, Sakib C. wrote:

Hi,

Unfortunately reinstalling didn’t solve the problem. I tried twice
already.
What I did is first I removed all relevant gnuradio and uhd files
and
folders from /usr/* folders and installed gnuradio, uhd, grextras
using
the
script linked on gnuradio.org website:

Would you perhaps have multiple installs of gnuradio both in /usr
and
/usr/local? That could be one issue

Also, while its ok to put gnuradio in /usr and grextras and pre-cog
into
/usr/local. You will need to set the GRC_BLOCKS_PATH environment
variable to have entries for both block paths. The paths would be
your_install_prefix/share/gnuradio/grc/blocks

-josh

http://www.sbrac.org/files/build-gnuradiohttp://www.sbrac.org/files/build-gnuradio
. I opened GRC and found some

newer blocks (obviously because of some updates to the source)
along with
my previously missing blocks. So, everything is fine. Then I
installed
pre-cog using the set of commands at the end of the page:

https://github.com/buoyboy/pre-cog/wiki/Installationhttps://github.com/buoyboy/pre-cog/wiki/Installation
. After that I

opened

GRC and blocks that start with gr_*.xml are gone.

Please let me know if I’m doing something wrong with the
installation.
Isn’t pre-cog supposed to be installed in this way? Or if pre-cog
is
required, I have to install gnuradio in some other way apart from
using
that script?

Thanks.

On Wed, Oct 17, 2012 at 5:32 PM, Johnathan C.

[email protected]wrotemailto:[email protected]>wrote:

On Wed, Oct 17, 2012 at 2:30 PM, Sakib C. <
[email protected]>wrotemailto:[email protected]>wrote:

I noticed that actually all block files (xml) are still there
in /usr/local/share/gnuradio/grc/blocks/ . What GRC is not
displaying
are
the blocks whose names start with gr_*.xml . I’ll try to
reinstall.

This was a recently fixed bug on GNU Radio master branch, related
to the
gr-blocks work Josh mentioned.

Johnathan

-------------- next part --------------
An HTML attachment was scrubbed…
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/a56703a1/attachment.htmlhttp://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/a56703a1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Before pre-cog installation.png
Type: image/png
Size: 37113 bytes
Desc: not available
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/a56703a1/attachment.pnghttp://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/a56703a1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed…
Name: After pre-cog installation.png
Type: image/png
Size: 27936 bytes
Desc: not available
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/a56703a1/attachment-0001.pnghttp://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/a56703a1/attachment-0001.png>

Message: 2
Date: Mon, 22 Oct 2012 23:58:58 +0300
From: Patrik T.
<[email protected]mailto:[email protected]>
To: Discuss-GNURadio
<[email protected]mailto:[email protected]>
Subject: [Discuss-gnuradio] Northern hemisphere notice: Winter is
approaching
Message-ID:
<[email protected]mailto:[email protected]>
Content-Type: text/plain; charset=“UTF-8”

A note for those who receive >= 1 GHz and have their antennas outside
at

60 North (I’m at +63 North). Water/Ice/Snow will attenuate your
signal
dramatically if you don’t protect your antenna.

A sample when air temperature was +2C and dish temperature was -1C
(1.5m
prime focus).
Loading...
2020:50:49.png

The signal should have been (left/right) straight arc lines not hairy
FFT. But now it was full of ice and erroneous since it was uncovered.

A simple solution could be to cover it with foam and have a fan
blowing
in +C air and one sucking out. The dish/antenna should always be dry
(>1013 mbar)

Just a reminder when receiving microwave up North,
Patrik

Message: 3
Date: Mon, 22 Oct 2012 21:24:02 +0000
From: “Nowlan, Sean”
<[email protected]mailto:[email protected]>
To: Ben H. <[email protected]mailto:[email protected]>,
“[email protected]mailto:[email protected]”
<[email protected]mailto:[email protected]>
Cc: “[email protected]mailto:[email protected]”
<[email protected]mailto:[email protected]>
Subject: Re: [Discuss-gnuradio] Very weird about my N210 board.
Message-ID:
<195933287DC65748BA7AE867BA8E430B622E5301@apatlisdmbx02mailto:195933287DC65748BA7AE867BA8E430B622E5301@apatlisdmbx02>
Content-Type: text/plain; charset=“utf-8”

Sorry for the late reply here, but 1 more thing to check: is the
device getting consistent power? We?ve noticed that if the voltage is
too low or the connector is loose, the radio can be thrown into a state
that produces those errors.

From:
discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalidmailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid] On
Behalf Of Ben H.
Sent: Monday, October 15, 2012 3:11 PM
To: [email protected]mailto:[email protected]
Cc: [email protected]mailto:[email protected]
Subject: Re: [Discuss-gnuradio] Very weird about my N210 board.

Also, are you using Network Manager on your PC? If so, have you told
it to ignore the ethernet interface? If not, NM will try to re-negotiate
DHCP on that interface over and over, bringing down your link every
time.

Cheers,
Ben
On Mon, Oct 15, 2012 at 9:40 AM, Josh B.
<[email protected]<mailto:[email protected]mailto:[email protected]<mailto:[email protected]>>
wrote:

On 10/15/2012 09:36 AM, Pan wrote:

Hi,

Sorry for bothering you guys. I encountered some very weird thing
about my
N210 board.

When the board is powered up, it seems very thing works well.
Actually, I
can even ping this board. However, if I run any applications in the
applications?such as uhd_fft? uhd/siggen in the /usr/local/bin
folder, the
terminal shows there are many errors as following. After that, this
board
reset again and again for several minutes. It is very weird! Is
there
anyone can tell me what happened with my N210 board. Any suggestion
or hint
will be very appreciated. Thank you so much.

Looks like the ethernet link is dying on you. Could be an issue w/ the
driver for your ethernet card. Can you try a different ethernet or PC
and see if the problem follows?

Best,

Pan

pan@pan-XPS-8300:/usr/local/bin$mailto:pan@pan-XPS-8300:/usr/local/bin$
./uhd_siggen

linux; GNU C++ version 4.6.3; Boost_104601;
UHD_003.004.003-255-gc7054ce5

– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
– Detecting internal GPSDO… not found

UHD Error:
The daughterboard manager encountered a recoverable error in
init.
Loading the “unknown” daughterboard implementations to continue.
The daughterboard cannot operate until this error is resolved.
RuntimeError: fifo ctrl timed out looking for acks

UHD Error:
Control packet attempt 0, sequence number 318:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 1, sequence number 319:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 2, sequence number 320:
RuntimeError: no control response, possible packet loss

UHD Error:
An unexpected exception was caught in a task loop.
The task loop will now exit, things may not work.
RuntimeError: link dead: timeout waiting for control packet ACK

UHD Error:
Control packet attempt 0, sequence number 321:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 1, sequence number 322:
RuntimeError: no control response, possible packet loss

UHD Error:
Control packet attempt 2, sequence number 323:
RuntimeError: no control response, possible packet loss
RuntimeError: fifo ctrl timed out looking for acks

pan@pan-XPS-8300:/usr/local/bin$mailto:pan@pan-XPS-8300:/usr/local/bin$
./uhd_fft

linux; GNU C++ version 4.6.3; Boost_104601;
UHD_003.004.003-255-gc7054ce5

Traceback (most recent call last):
File “./uhd_fft”, line 337, in
main ()
File “./uhd_fft”, line 333, in main
app = stdgui2.stdapp(app_top_block, “UHD FFT”, nstatus=1)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 38, in init
wx.App.init (self, redirect=False)
File
“/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7981, in init
self._BootstrapApp()
File
“/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7555, in _BootstrapApp
return core.PyApp__BootstrapApp(*args, **kwargs)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 42, in OnInit
self._max_noutput_items)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 64, in init
self.panel = stdpanel (self, self, top_block_maker, max_nouts)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py”,
line 86, in init
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File “./uhd_fft”, line 91, in init
otw_format=options.wire_format, args=options.stream_args))
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/init.py”,
line 116, in constructor_interceptor
return old_constructor(*args)
File
“/usr/local/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py”,
line 2834, in usrp_source
return _uhd_swig.usrp_source(*args)
RuntimeError: LookupError: KeyError: No devices found for ----->
Empty Device Address

pan@pan-XPS-8300:/usr/local/bin$mailto:pan@pan-XPS-8300:/usr/local/bin$

Discuss-gnuradio mailing list

[email protected]<mailto:[email protected]mailto:[email protected]<mailto:[email protected]>

Discuss-gnuradio Info Pagehttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Discuss-gnuradio mailing list
[email protected]<mailto:[email protected]mailto:[email protected]<mailto:[email protected]>
Discuss-gnuradio Info Pagehttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed…
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/b7e770fe/attachment.htmlhttp://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/b7e770fe/attachment.html>

Message: 4
Date: Mon, 22 Oct 2012 15:03:02 -0700 (PDT)
From: Ahmed Z.
<[email protected]mailto:[email protected]>
To: “[email protected]mailto:[email protected]”
<[email protected]mailto:[email protected]>
Subject: [Discuss-gnuradio] No Digital Modulation Working
Message-ID:
<[email protected]mailto:[email protected]>
Content-Type: text/plain; charset=“iso-8859-1”

Hi all,?
I was trying to make a transceiver working on any digital modulation.
I have tried GMSK, PSK, QPSK, QAM and other blocks available in gnuradio
companion. But non of them works. All of them works in loop back manner
but when ever I try to transmit and receive on air it simply doesn’t
work. In the attached file I am using GMSK while transmitting a video
file. I have also tried audio file, and even a simple sine wave but all
in vain. I am using USRP N210 with SBX daugherboard with VERT 2450
antenna. All of the equipment works as I was succeeded in transmitting
my voice while doing frequency modulation. If anybody can tell me about
any mistake while seeing the attached file or provide me with any
transceiver using any digital modulation which should work on latest
gnuradio with USRP N210 that would really be a great help.?
I really appreciate your help.
Regards.
Ahmed.
-------------- next part --------------
An HTML attachment was scrubbed…
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/91b3e520/attachment.htmlhttp://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/91b3e520/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed…
Name: GMSK_Trans_Receive.png
Type: image/png
Size: 273347 bytes
Desc: not available
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/91b3e520/attachment.pnghttp://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121022/91b3e520/attachment.png>

Message: 5
Date: Tue, 23 Oct 2012 08:54:38 +1030
From: Jose T. Diaz
<[email protected]mailto:[email protected]>
To: [email protected]mailto:[email protected]
Subject: Re: [Discuss-gnuradio] Problems passing the control between
blocks - message passing
Message-ID:
<[email protected]mailto:[email protected]>
Content-Type: text/plain; charset=“iso-8859-1”

Hi Community,

In following up this issue, we’ve tried different options (ie. returns
0,
yield or returns -1 in work function). What is happening is the block
are
running exactly once. In other words, the work() function never comes
back
and run again.

Anyone can suggest a way to solve this issue?.

Thanks for your comments,

Jose.

On Mon, Oct 22, 2012 at 5:55 PM, Jose T. Diaz
<[email protected]mailto:[email protected]

wrote:

Hi John,

Also, I am trying to use boost::this_thread::yield() between blocks,
but
when I add a third block into the chain, the control passes between
BLOCK 1
↔ BLOCK 2. When they finish, the control is passed to BLOCK 3.

Thanks again for your suggestions,

Jose

On Mon, Oct 22, 2012 at 9:17 AM, Jose T. Diaz <
[email protected]mailto:[email protected]> wrote:

Hi John,

Please, find attached the codes (.cc) for BLOCK 1 and BLOCK 2. I’m
still
unable to control the correct order of them, when I generated an
infinite
loop.

Thanks a lot for your help in this issue,

Regards,

Jose

On Thu, Oct 18, 2012 at 9:58 AM, John M.
[email protected]wrotemailto:[email protected]>wrote:

Can you send me the files?

-John

On Wed, Oct 17, 2012 at 4:16 PM, Jose T. Diaz <
[email protected]mailto:[email protected]>
wrote:

Hi John,

Yes, I also checked the examples in your branch. In regards to
your
questions.

1. BLOCK 2 is processing the data from BLOCK 1, but only when
BLOCK
1 has finished the routine “N times”. Let me post a piece of code
from
BLOCK 1:

int work(
const InputItems &,
const OutputItems &
){

    for (int i = 0; i < d_pkt_len; i++) {
           if (d_mode == 2)
      { elements[i] = ((i % d_pkt_len) + d_num_pkts_output) &

0xff;

              }
    else if (d_mode == 0)
      {elements[i]=0;
             }
         else // ones
    {elements[i]=0xFF;
    }
    num_output++;
  } //End of for
  d_num_pkts_output++;

  //(4.1) adding data into the dictionary
  dictionary = pmt::pmt_dict_add(dictionary, data_key,

vector_data);

  std::cout << std::endl << "(4) Now, the dictionary is" <<

dictionary <<std::endl;

  //Posting a message downstream
  this->post_msg(0, AMSG_KEY, dictionary, _d_my_unique_id);
  std::cout << std::endl << "posting the message downstream "

<<std::endl;

  return -1;  // <--The problem seems to be here

}

2. N is the number of packet that I want to transmit from BLOCK

In my code, I’m using the variable d_max_pkts. So, when
d_num_pkts_output

= d_max_pkts, the program stops:

if (d_num_pkts_output >= d_max_pkts)
  return 0;
  1. Yes, my BLOCK 1 is as follows:

block(
//“gr uhd amsg source”,
“BLOCK 1”,
gr_make_io_signature(0, 0, 0),
gr_make_io_signature(0, 0, 0),
msg_signature(false, 1)

Thanks again for your advice,

Regards,

Jose

On Wed, Oct 17, 2012 at 5:14 PM, John M.
<[email protected]mailto:[email protected]

wrote:

So, block 2 is never processing the data? What are you using to
set
the “N”? Does the uhd_amsg_source have the same i/o as the
original block

  • no inputs, one msg output?

If you’re looking to something to generate periodic msg’s with
arbirtrary key and value, the heart_beat block in my pre-cog
branch might
help…

-John

On Tue, Oct 16, 2012 at 11:34 PM, Jose T. Diaz <
[email protected]mailto:[email protected]>
wrote:

Hi John,

I wrote the code in C++ based on UHD_AMsg_source.cc, provided
in
GRExtras. In my work function, I’ve finished it using return -1
(ie. the
block has finished processing correctly) as shown below:

int work(
const InputItems &,
const OutputItems &
){
//work definition here (ie. generate a packet and post
downstream)
return -1; //done running, work done status
}

However, in that way the block in GNU Radio Companion runs only
once.
The other possibility is not to use “return” at all, but in
that case what
I have is:

  1. BLOCK 1 generates a packet
  2. BLOCK 1 post the packet downstream

Step 1 and 2 repeats “N times”. When finishes, it gives the
control
to BLOCK 2 to process the message. However, I need a sequence
as follows:

  1. BLOCK 1 generates a packet
  2. BLOCK 1 post the packet downstream
  3. BLOCK 2 process the packet
  4. BLOCK 2 post the message again downstream and so on…

Step 1 to 4 should repeat “N times”.

Thanks again for your help,

Jose

On Wed, Oct 17, 2012 at 4:52 PM, John M. <
[email protected]mailto:[email protected]> wrote:

Jose,

Try a while(1) with a block and a blocking call to pop msg’s
off
the queue:

self.pop_msg_queue()

Should help you avoid the return -1

Or maybe I’ve misunderstood your problem…?

-John

On Tue, Oct 16, 2012 at 11:18 PM, Jose T. Diaz <
[email protected]mailto:[email protected]>
wrote:

Hi All,

I’m working with 2 blocks that I’ve created using
“UHD_AMsg_Source”
as a reference model. In these blocks, I am passing pmt_dict
type as
messages, ie:

this->post_msg(0, AMSG_KEY, dictionary,_id);

Where, dictionary contains data/metadata that I can read in
the
next block downstream.

BLOCK 1 – (pmt_dict included in the message) → BLOCK 2

The blocks are working ok, but the problem is that when I
want to
generate several packets and post them downstream, BLOCK 1
runs until
finishes and then BLOCK 2 takes the control until finishes.
The problem is
the “return” sentence in my work function. I did 2 possible
ways

Option 1: Using -1

work {
//work here
return -1
}

In this way BLOCK 1 stops working after one iteration and it
does
not run as many times as I want.

Option 1: Not using return

work {
//work here
}

In this way BLOCK 1 runs many times and posts messages
downstream
all those times, but it gives the control to BLOCK 2 when it
finishes.
Then, BLOCK 2 takes the messages from the message queue.
However, this
implementation is not useful for me. BLOCK 1 should post a
message
downstream and then, BLOCK 2 takes the message and work with
the packet.

Any suggestion is welcome, thanks a lot for your time,

Regards,

Jose

Discuss-gnuradio mailing list
[email protected]mailto:[email protected]

Discuss-gnuradio Info Pagehttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-------------- next part --------------
An HTML attachment was scrubbed…
URL:
<http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121023/3d1d24e6/attachment.htmlhttp://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20121023/3d1d24e6/attachment.html>

Discuss-gnuradio mailing list
[email protected]mailto:[email protected]
Discuss-gnuradio Info Pagehttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio

End of Discuss-gnuradio Digest, Vol 119, Issue 24