Dear Mister Ahmed Zaheer-
You might find answers to your questions about receiving and
transmitting in Digital at the DECT project website.
Have A Nice Day!
----- Original Message -----
Sent: Monday, October 22, 2012 5:24
PM
Subject: Discuss-gnuradio Digest, Vol
119, Issue 24
Send Discuss-gnuradio mailing list submissions to
address@hidden
To
subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or,
via email, send a message with subject or body 'help' to
address@hidden
You
can reach the person managing the list at
address@hidden
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
Chowdhury)
2. Northern hemisphere notice: Winter is
approaching (Patrik Tast)
3. Re: Very weird about my N210
board. (Nowlan, Sean)
4. No Digital Modulation Working (Ahmed
Zaheer)
5. Re: Problems passing the control between blocks -
message
passing (Jose Torres
Diaz)
----------------------------------------------------------------------
Message:
1
Date: Mon, 22 Oct 2012 16:52:13 -0400
From: Sakib Chowdhury <address@hidden>
To: address@hidden
Cc: address@hidden
Subject:
Re: [Discuss-gnuradio] Blocks missing from GRC after
pre-cog
installation
Message-ID:
<address@hidden>
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 Blum <address@hidden>
wrote:
>
>
> On 10/18/2012 11:07 AM, Sakib Chowdhury
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-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/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 Corgan
> > <address@hidden>wrote:
>
>
> >> On Wed, Oct 17, 2012 at 2:30 PM, Sakib Chowdhury
<
> address@hidden>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.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.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.png>
------------------------------
Message:
2
Date: Mon, 22 Oct 2012 23:58:58 +0300
From: Patrik Tast <address@hidden>
To:
Discuss-GNURadio <address@hidden>
Subject:
[Discuss-gnuradio] Northern hemisphere notice: Winter
is
approaching
Message-ID: <address@hidden>
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).
http://poes-weather.com/~patrik/1.7GHz/Screenshot%20from%202012-10-22%
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" <address@hidden>
To:
Ben Hilburn <address@hidden>, "address@hidden"
<address@hidden>
Cc: "address@hidden" <address@hidden>
Subject:
Re: [Discuss-gnuradio] Very weird about my N210 board.
Message-ID: <address@hidden>
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: address@hidden
[mailto:address@hidden On
Behalf Of Ben Hilburn
Sent: Monday, October 15, 2012 3:11 PM
To: address@hidden
Cc: address@hidden
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 Blum <address@hidden<mailto:address@hidden>>
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
>
>
>
> address@hidden:/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
> address@hidden:/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
<module>
> 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
> address@hidden:/usr/local/bin$
>
>
>
>
_______________________________________________
> Discuss-gnuradio
mailing list
> address@hidden<mailto:address@hidden>
>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio
mailing list
address@hidden<mailto:address@hidden>
https://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.html>
------------------------------
Message:
4
Date: Mon, 22 Oct 2012 15:03:02 -0700 (PDT)
From: Ahmed Zaheer <address@hidden>
To: "address@hidden" <address@hidden>
Subject:
[Discuss-gnuradio] No Digital Modulation Working
Message-ID:
<address@hidden>
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.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.png>
------------------------------
Message:
5
Date: Tue, 23 Oct 2012 08:54:38 +1030
From: Jose Torres Diaz <address@hidden>
To:
address@hidden
Subject:
Re: [Discuss-gnuradio] Problems passing the control between
blocks -
message passing
Message-ID:
<address@hidden>
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
Torres Diaz <address@hidden
>
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 Torres Diaz
<
> address@hidden>
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
Malsbury <address@hidden>wrote:
>>
>>>
Can you send me the files?
>>>
>>>
-John
>>>
>>>
>>>
>>>
>>>
On Wed, Oct 17, 2012 at 4:16 PM, Jose Torres Diaz <
>>> address@hidden>
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 1.
>>>> 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;
>>>>
>>>> 3. 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 Malsbury <address@hidden
>>>>
> 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 Torres Diaz
<
>>>>> address@hidden>
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 Malsbury
<
>>>>>> address@hidden>
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 Torres Diaz
<
>>>>>>> address@hidden>
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
>>>>>>>> address@hidden
>>>>>>>>
https://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.html>
------------------------------
_______________________________________________
Discuss-gnuradio
mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End
of Discuss-gnuradio Digest, Vol 119, Issue
24
*************************************************
|
