Re: [Discuss-gnuradio] benchmark_tx and rx : too many FALSE packet

[SangHyuk Kim]

Hi,

Sorry I'm late for reply

Did you use two device (Tx,Rx) at a time ?

I expect like these messages on Rx machine

ok = FALSE  pktno = 1  n_rcvd = 1  n_right = 0
ok = FALSE  pktno = 2  n_rcvd = 2  n_right = 0
ok = FALSE  pktno = 3  n_rcvd = 3  n_right = 0
...
ok = TRUE  pktno = N  n_rcvd = N  n_right = 1
...

I think you tested only RX test, right ?

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

Re: [Discuss-gnuradio] benchmark_tx and rx : too many FALSE packet

[Nikos Balkanas]

Hi,

Nope, as i told you, my x300 has only rx tuners :(

BR
Nikos

On Tue, Mar 15, 2016 at 4:13 AM, SangHyuk Kim  wrote:

> Hi,
>
> Sorry I'm late for reply
>
> Did you use two device (Tx,Rx) at a time ?
>
> I expect like these messages on Rx machine
>
> ok = FALSE  pktno = 1  n_rcvd = 1  n_right = 0
> ok = FALSE  pktno = 2  n_rcvd = 2  n_right = 0
> ok = FALSE  pktno = 3  n_rcvd = 3  n_right = 0
> ...
> ok = TRUE  pktno = N  n_rcvd = N  n_right = 1
> ...
>
> I think you tested only RX test, right ?
>
> Thanks Nikos
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Picking up RF cellular signals

[Nikos Balkanas]

Indeed, there is phone locator protocol, and a service offered as by some
companies. They work through provider contracts. The problem is that you
have to know the phone number beforehand and the carrier. Not very useful
in a disaster case :(

BR,
Nikos

On Mon, Mar 14, 2016 at 5:50 PM, Marcus Müller 
wrote:

> True, at least unless you send them something they have to react to.
> Which the phone will only do if you're the infrastructure, and usually
> implies you authenticate as such[2]. Which will hence most likely only work
> if the cellular providers cooperate with you.
>
> ​[...snip...]​
>
>
>
> On 03/14/2016 03:54 PM, Meny Sidar wrote:
>
> Hi guys,
>
> I am currently working on a project for my university, where i'm trying to
> locate cellular phones using SDR (USRP B210).
> The idea of the project is to be able to find survivors/victims in
> disaster areas, such as earthquakes, by assuming they have their cellular
> on them.
>
> What i did so far, is a program that calculates and outputs in a loop the
> power transmitted from a cellular phone from it's uplink channel. that can
> tell me my distance to it.
> problem is, that cellular phones are usually in idle mode and not
> transmitting at all.
> So it works, but only if the phone is currently transmitting to the
> network (phone call, internet, etc..)
>
> I'm trying to find a solution for this,
> There has to be a way of knowing that some kind of RF transmitter/receiver
> is near me...
> If anyone can shed some light on this subject, what can i do or if i need
> to go in another way, i'll be very grateful!
> right now i'm stuck.
>
> Thanks a lot,
> Meny
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PDU to Tagged Stream with BIG PDUs

[Bastian Bloessl]

Hi,


> On 14 Mar 2016, at 16:56, Francisco Albani  wrote:
> 
> I wrote a custom message block that produces a PDU with complex samples. My 
> plan is to connect it to a PDU to Tagged Stream and then to a UHD Sink (with 
> len_tag_name = 'packet_len').
> 
> The goal is to transmit a burst for each packet. This packets are made of 
> approximately 14k samples and sometimes more.
> 
> I'm unable to do this because of this error:
> 
> thread[thread-per-block[1]: ]: Buffer too 
> small for min_noutput_items
> 
> I tried rising the PDUtoTaggedStream block min/max output buffer size to its 
> maximum values with no success.
> 
> Attached is the minimum equivalent flowgraph that shows the same problem.
> 
> Is this a Scheduler hardcoded limitation?
> 
> Anybody knows a workaround?
> 

the Tag Debug and Null Sink seem to not have an interface for adjusting the 
buffers, but if I add it (manually) to the python file, it works for me

(self.blocks_pdu_to_tagged_stream_0).set_min_output_buffer(10)
(self.blocks_null_sink_0).set_min_output_buffer(10)
(self.blocks_tag_debug_0).set_min_output_buffer(10)

Best,
Bastian
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about output/input buffers

[Gonzalo Arcos]

Anyone? Is there a way to keep the buffer array for subsequent executions
of work() ?

Also, ive searched everywhere for the meaning of the return value of the
work function. The documentation explains the function and its parameters,
but not what the return value is for.

2016-03-13 16:11 GMT-03:00 Gonzalo Arcos :

> So basically i tried assigning the sync words only in the first call to
> work() and the result was that only the first packet was transmitted
> successfully, so either gnuradio scheduler is erasing all the output buffer
> before the call to the work function, or the output buffer is a new
> allocation and has nothing to do with the output buffer of the previous
> call to work.
>
> In any case, is there a way i can make that gnuradio just allocs that
> buffer once and does not change the values of it, so i can be sure that in
> successive calls to work the buffer retains the values written by previous
> calls to work, if none of the consumer blocks changes their input buffer?
>
> Thanks in advantage.
>
> 2016-03-13 14:44 GMT-03:00 Gonzalo Arcos :
>
>> Do output buffers of a block are always allocated in the same address
>> throughout the same execution of the flowgraph? I need to know this because
>> it would allow me to do some optimization.
>>
>>
>> For example:
>>
>> Suppose i have the OFDM Carrier Allocator Block connected to the IFFT
>> block.
>>
>> On every execution of work() the carrier allocator copies the synch words
>> to the beggining of the output buffer. However, i know that my synch words
>> will always remain the same throughout the entire execution of the
>> flowgraph. Additionally, the fft should not change anything in its input
>> buffer, which is ofdm carrier allocator's output buffer.
>>
>> So basically, i only need to copy that information once, on the first
>> run, since then that data will remain in the buffer.
>>
>> This happens ONLY if the ofdm carrier allocator output buffer is not
>> freed/alloc'ed by the gnuradio scheduler more than once per execution of
>> the flowgraph.
>>
>> Can somebody confirm this?
>>
>> Thanks
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [UHD] Signed Windows Drivers

[Martin Braun]

Dear Windows aficionados,

we've been getting requests for signing our Windows USB drivers for our
USRPs. Signed Windows drivers are now available here:
http://files.ettus.com/binaries/misc/, and will be part of any images
package going forward.

Note that we have seen issues with Windows 10, where installing the
signed drivers produces a warning that seems to imply something went
wrong. However, the drivers still get installed and can get used.

Cheers,
Martin

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

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

[Martin Braun]

Yan,

simply convert "freq" and your frequency to a PMT before passing into
cons().

Cheers,
Martin

On 03/14/2016 03:44 PM, Yan Huang wrote:
> Hi Martin,
> 
> Thank you for your kind reply. But I'm still comfused that I already have to 
> input in pmt::cons(“freq”,2.4e9), cause in the manual it said:
> 
> pmt::cons(KEY, VALUE): This format is useful for commands that take a single 
> value. Think of KEY and VALUE as the argument name and value, respectively. 
> For the case of the QT GUI Frequency Sink, KEY would be "freq" and VALUE 
> would be the new center frequency in Hz. 
> 
> Could you please give me an exmaple about it?
> 
> Thank you a lot,
> 
> Yan
> 
> From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org 
> [discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] on behalf of 
> Martin Braun [martin.br...@ettus.com]
> Sent: 14 March 2016 17:18
> To: discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Change frequency in USRP source automatically
> 
> Yan,
> 
> check the PMT manuals. cons() takes 2 PMTs as input.
> 
> 
> Cheers,
> Martin
> 
> On 03/14/2016 09:09 AM, Yan Huang wrote:
>> Hi all,
>>
>>
>>
>> I want to change the frequency in “USRP source” automatically, for
>> example 2.37GHz-2.43GHz with each time stepping 2MHz.
>>
>>
>>
>> 1. As you know, the USRP source has an input message port, so I want to
>> connect it to a “Message strobe” to control the frequency change. But
>>  after I see [1][2], I write PMT type commands  in “Message PMT” in
>> “Message Strobe” as:
>>
>> pmt::cons(“freq”,2.4e9)
>>
>> it comes up error “invalid syntax(,line 1)”, so I don’t know how
>> to further stepping the frequency.
>>
>> 2. If I use the “Message Strobe” to define frequency, what can I put in
>> the “frequency” in “USRP source” block? Put it as 0?
>>
>>
>>
>> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
>>
>> [2]
>> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_commands
>>
>>
>>
>> Many thanks ,
>>
>>
>>
>> Yan
>>
>>
>>
>>
>>
>> This message and any attachment are intended solely for the addressee
>> and may contain confidential information. If you have received this
>> message in error, please send it back to me, and immediately delete it.
>>
>> Please do not use, copy or disclose the information contained in this
>> message or in any attachment.  Any views or opinions expressed by the
>> author of this email do not necessarily reflect the views of the
>> University of Nottingham.
>>
>> This message has been checked for viruses but the contents of an
>> attachment may still contain software viruses which could damage your
>> computer system, you are advised to perform your own checks. Email
>> communications with the University of Nottingham may be monitored as
>> permitted by UK legislation.
>>
>>
>>
>> ___
>> 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
> 
> 
> 
> 
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it. 
> 
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
> 
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
> 


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

[Discuss-gnuradio] PDU to Tagged Stream with BIG PDUs

[Francisco Albani]

Hi again!

I wrote a custom message block that produces a PDU with complex samples. My
plan is to connect it to a PDU to Tagged Stream and then to a UHD Sink
(with len_tag_name = 'packet_len').

The goal is to transmit a burst for each packet. This packets are made of
approximately 14k samples and sometimes more.

I'm unable to do this because of this error:

thread[thread-per-block[1]: ]: Buffer too
small for min_noutput_items

I tried rising the PDUtoTaggedStream block min/max output buffer size to
its maximum values with no success.

Attached is the minimum equivalent flowgraph that shows the same problem.

Is this a Scheduler hardcoded limitation?

Anybody knows a workaround?

Many thanks and bye!

Francisco.


test_big_pdus_to_ts.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Cyberspectrum: Software Defined Radio Meetup (this Wed, 16th Mar) 6:30pm

[Balint Seeber]

Dear all,

Announcing the fourteenth Cyberspectrum meetup in San Francisco!

Come along at 6:30 PM for a 7 PM sharp kickoff in the Hackatorium. For
those unable to attend the event in person, you can live stream it here:
https://www.youtube.com/watch?v=P971PcQexFI
There's also IRC: #cyberspectrum on Freenode.

Full details, including the speaker lineup/topics, are here:
http://www.meetup.com/Cyberspectrum/events/228537038/

And the Noisebridge event page is here:
https://noisebridge.net/wiki/Cyberspectrum

We'll be hearing about:

   - Paul David: gr-minecraft
   - Matt Knight: "Attacking ZigBee Locks with Commodity Wireless Tools"
   - Special remote appearance from Marc Newlin, discoverer of MouseJack
   

If you're not familiar with Cyberspectrum: "The Bay Area SDR Meetup will
serve as a forum to exchange knowledge and ideas related to Software
Defined Radio (the software and hardware), and generally aim to get people
excited about all the applications that can be realised with the
technology. At each meetup, attendees will have the opportunity to present
their work/ideas to the group. Engineers, enthusiasts, hobbyists and people
of all experience levels are welcome, no matter what your software/hardware
background."

As always, if you would like to present at a future event about a project
you're working on, or something interesting you've discovered, please get
in touch!

Hope to see you there,
Balint
@spenchdotnet 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

[Yan Huang]

Hi Martin,

Thank you for your kind reply. But I'm still comfused that I already have to 
input in pmt::cons(“freq”,2.4e9), cause in the manual it said:

pmt::cons(KEY, VALUE): This format is useful for commands that take a single 
value. Think of KEY and VALUE as the argument name and value, respectively. For 
the case of the QT GUI Frequency Sink, KEY would be "freq" and VALUE would be 
the new center frequency in Hz. 

Could you please give me an exmaple about it?

Thank you a lot,

Yan

From: discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org 
[discuss-gnuradio-bounces+eexyh22=nottingham.ac...@gnu.org] on behalf of Martin 
Braun [martin.br...@ettus.com]
Sent: 14 March 2016 17:18
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Change frequency in USRP source automatically

Yan,

check the PMT manuals. cons() takes 2 PMTs as input.


Cheers,
Martin

On 03/14/2016 09:09 AM, Yan Huang wrote:
> Hi all,
>
>
>
> I want to change the frequency in “USRP source” automatically, for
> example 2.37GHz-2.43GHz with each time stepping 2MHz.
>
>
>
> 1. As you know, the USRP source has an input message port, so I want to
> connect it to a “Message strobe” to control the frequency change. But
>  after I see [1][2], I write PMT type commands  in “Message PMT” in
> “Message Strobe” as:
>
> pmt::cons(“freq”,2.4e9)
>
> it comes up error “invalid syntax(,line 1)”, so I don’t know how
> to further stepping the frequency.
>
> 2. If I use the “Message Strobe” to define frequency, what can I put in
> the “frequency” in “USRP source” block? Put it as 0?
>
>
>
> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
>
> [2]
> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_commands
>
>
>
> Many thanks ,
>
>
>
> Yan
>
>
>
>
>
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it.
>
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
>
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
>
>
>
> ___
> 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




This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


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

[Discuss-gnuradio] Calling start() in gr.sync_block

[devin kelly]

Hello,

I have a block that's like the message strobe - it has one output message
port and no other connections.

For whatever reason GR isn't calling the start() function on my block when
I call top_block.start().  I've written a few other blocks that do this
without any problem but this I can't figure out.


Here's part of my class:

class app_strobe(gr.sync_block):
"""
"""
def __init__(self,
 filename,
 node_id,
 iterations='all',
 repeat=False,
 interval=0.1):
gr.sync_block.__init__(self,
   name="app_strobe",
   in_sig=None,
   out_sig=None)

 self.message_port_register_out(PDUS)

def start(self):

super(gr.sync_block, self).start()
print 'starting'

self.timer = threading.Timer(self.interval, self.callback)
self.timer.start()

Here's my unit test for the block:

def test_001(self):

self.tb = gr.top_block()

self.app_out = swarm_app_strobe("events.csv", 1)
self.app_in = gr.message_debug()

self.tb.msg_connect(self.app_out,
"pdus",
self.app_in,
"store")

self.tb.start()
sleep(5)
self.tb.stop()
self.tb.wait()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] declare_sample_delay cannot handle large delay?

[Liyang Zhang]

Hi all,

I am playing with gnuradio and USRP but find something “weird”.
I am using a custom block with history samples. Since delay on stream tags is 
introduced, I use declare_sample_delay to offset it. So in the constructor of 
my custom block it is like:
set_history(hist_len+1);
declare_sample_delay(hist_len);

In experiments I found that it works well when hist_len is small. But if I set 
it to a rather large value (e.g., 1000), the output just lose all the tags the 
block is supposed to pass.
So I presume the scheduler cannot handle large delay?

Thanks.

-
Liyang Zhang
PhD Candidate
Department of Electrical and Computer Engineering
Northeastern University
Email: liyan...@ece.neu.edu




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

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Marcus D. Leech]

On 03/14/2016 10:11 AM, Tom Rondeau wrote:


I've been running the GNU Radio project for over five years. In this 
time, we've dramatically expanded its capabilities, prominence, and 
performance. We have attracted great developers and a fantastic user 
base. And we have built the highly successful and growing annual GNU 
Radio conference.

[Bunch of stuff deleted for brevity]



I'd just like to chime in and say that Tom, you've done a fantastic job 
over the last five years, along with your "supporting cast".  I hope that
  you thoroughly enjoy your new role in DARPA, and we all expect 
amazing things :)


For Ben, Jonathan, and Nathan, I offer my congratulations, and I know 
you will all do great things.  The ecosystem that Gnu Radio has spawned
  since 2004 is one I think we can all be proud of, and the addition of 
"new blood" at the top can only help!


Thanks everyone involved...



___
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] Hardware "jitter", particularly USB

[Martin Braun]

We call this the two-clock problem, and yeah, it's quite common.

Cheers,
M

On 03/14/2016 11:14 AM, Gregory W. Ratcliff wrote:
> GnuRadio community,
> 
> I have been using various hardware interfaces to gnuradio lately.
> In the simplest example, I noticed an issue with Funcube Pro Plus with
> broadcast wideband FM (about 4 GRC blocks) whereby it would consistently
> underflow, even though every rate appeared to be perfect.  A crude but
> effective fix has been to interpolate by 500, decimate by 499.
> 
> I occasionally notice a similar problem with DVB modules, never with Hermes.
> 
> This has caused me to wonder if some subtle error has crept into OSMOCOM
> or the Funcube module has a timing error (that had been masked
> previously by OSMOCOM). 
> 
> Am I alone in this (in which case I will look closely at usb/audio/pc
> hardware)?
> 
> Thanks in advance,
> 
> Greg
> NZ8R
>  
> Gregory W. Ratcliff
> 
> 
> 
> 
> 
> 
> 
> ___
> 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] GNU Radio Organizational Changes to Address Growth

[Eric Blossom]

Congratulations to all of you on this new phase of GNU Radio!

Tom, thanks for all you've done serving as the project lead since I stepped
down some 5 years ago.  I'm happy to hear about your new adventure as a
DARPA PM!

Johnathan and Ben, thanks for all that you've already done for GNU Radio,
and thank you for stepping into these expanded roles!

I looking forward to seeing what the next 5 years brings for GNU Radio!

Best wishes,
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to measure throughput (data rate)

[West, Nathan]

Every block has a throughput performance counter:
http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a78a27917edcd3b32f10b2166f3362a68

The output is items/sec.

On Mon, Mar 14, 2016 at 1:47 PM, Diyar Muhammed 
wrote:

> Dear All,
> I have made a transceiver in gnuradio software with using usrp B210, and I
> would like to measure data transmission between Tx and Rx, is there any way
> to measure that?
> --
> Regards,
> Diyar Muhammed
> Ministry of Higher Education and Scientific Research
> Duty: Network Administration and Design
> Website:  www.mhe-krg.org
> Cell Phone: 009647504690060
> Office Phone:   00964662554683
>
> ___
> 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] Bug in tag processing

[Eugene Grayver]

I think there's a bug in tag processing.  Here's a simple script to demonstrate 
the problem.  If DELAY is set to a small value <6000,  we get the expected 
output. However, if DELAY is set to 8000, the tag never comes out.  The same 
problem can be observed using the blocks.vector_insert_b block, indicating that 
the bug is in the runtime.





DELAY = 8000
from gnuradio import gr, blocks
import pmt
print "Version", gr.version()
top = gr.top_block()
tag = gr.python_to_tag((0, pmt.to_pmt('A'), pmt.to_pmt(1), pmt.PMT_NIL))
src = blocks.vector_source_s(range(1), tags=[tag], repeat=False)
dly = blocks.delay(gr.sizeof_short, DELAY)
snk = blocks.tag_debug(gr.sizeof_short, 'A')
top.connect(src, dly, snk)

--
 expected output:


Version v3.7.9.1-97-gc0381e0e

--
Tag Debug: A
Input Stream: 00
  Offset: 6000  Source: n/a Key: A   Value: 1
--




Eugene Grayver, Ph.D.
Aerospace Corp., Sr. Eng. Spec.
Tel: 310.336.1274

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

[Discuss-gnuradio] Multiplexing and Demultiplexing

[Diyar Muhammed]

Dear All,
Is there any way to do multiplexing and demultiplexing in GNU radio
software?
-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.or g
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Grc RFNOC block error

[Nikos Balkanas]

tyvm:)​

On Mon, Mar 14, 2016 at 7:58 PM, Jonathon Pendlum <
jonathon.pend...@ettus.com> wrote:

> Hi Nikos,
>
> 1) The Fosphor RFNoC block does not compute a FFT. It does the averaging
> and persistence.
> 2) For RFNoC flowgraphs, you want to use a RFNoC Radio block so you do not
> transition out of the FPGA processing domain as would happen the USRP
> source / sink block. We want to stay in the FPGA processing domain for as
> long as possible before transitioning to host processing.
> The QT display is used to display Fosphor's output on your PC / laptop's
> monitor. Everything related to actually displaying graphics is done on the
> host, but the computation to generate those graphics is done on the FPGA.
>
>
>
> Jonathon
>
> On Fri, Mar 11, 2016 at 7:15 PM, Nikos Balkanas 
> wrote:
>
>> Correction: Spectrum shows fine. Just had to enlarge the panel:)
>>
>> On Sat, Mar 12, 2016 at 1:26 AM, Nikos Balkanas 
>> wrote:
>>
>>> Thanks Jonathan,
>>>
>>> That helps a lot. I still don't get a spectrum, but I get a nice fosphor
>>> panel and no timeout errors. A couple of questions:
>>>
>>> 1) You seem to be using 2 ffts: RFNoC FFT and RFNoC Fosphor. You can
>>> only do 1 FFT. What's the difference between those 2?
>>> 2) You start with an RFNoC Radio instead of a USRP source. Does that
>>> mean that the flow is intended to run from the FPGA? What is the meaning of
>>> the QT display in such a scenario?
>>>
>>> BR,
>>> Nikos
>>>
>>>
>>> On Sat, Mar 12, 2016 at 12:52 AM, Jonathon Pendlum <
>>> jonathon.pend...@ettus.com> wrote:
>>>
 Hi Nikos,

 Have you tried running the example fosphor flowgraph in
 gr-ettus/examples/rfnoc?



 Jonathon

 On Fri, Mar 11, 2016 at 2:14 PM, Nikos Balkanas 
 wrote:

> Upon closer inspection I do get a few runtime errors:
>
> timeout on chan 0
>
> Looks like smt is amiss in my flow. Any ideas about that?
>
> TIA
> Nikos
>
> On Sat, Mar 12, 2016 at 12:07 AM, Nikos Balkanas 
> wrote:
>
>> Tyvm Jason,
>>
>> That did it. I don't actually need to set the X300's addr and type to
>> anything. It defaults to the first one it finds, and I got only 1 ;-)
>> I got the top block running without any errors. Not much of a fosphor
>> display, like I'm used to, but I'm happy i didn't get any errors:)
>>
>> BR,
>> Nikos
>>
>> On Fri, Mar 11, 2016 at 5:13 PM, Jason Matusiak <
>> ja...@gardettoengineering.com> wrote:
>>
>>> (accidentally sent original response to the wrong mailing list.
>>> sorry)
>>>
>>>
>>> Nikos, All RFNoC scripts require a Device3 block.  If you look under
>>> UHD>RFNoC in GRC you will see Device3.  Just add that to your design (no
>>> connections needed) and if you are using an X310, set your device 
>>> argument
>>> to "addr=xx.yy.zz.aa" and device address to "type=x300".
>>>
>>> Make sense?
>>>
>>
>>
>
> ___
> 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] Spectral Survey with GRC?

[Marcus D. Leech]

On 03/02/2016 09:02 AM, Bruce E. Kahn wrote:

Hi GRC companions

Has anyone used GRC to acquire a large range RF spectral survey? 
Basically, step from range to range, and save the output in a (text) 
file. I would like to be able to average each frequency/range for some 
(variable) period of time, or do peak hold, much like some of the nice 
FFT sinks do. I have been doing this in Python with a modification of 
osmocom_spectrum_sense, but I would rather use GRC since it is more 
intuitive. I just need a starting point, and particularly how to save 
to file, and time average. This seems like it would be pretty 
straightforward, but I haven't seen it done anywhere (with GRC).


A little background. I am working on a research project on ambient RF 
energy harvesting (using printed metamaterial antennas). I recently 
got a HackRF One to help understand the ambient RF energy present and 
correlate it with energy harvesting performance.


Thanks in advance!

There have been various of these over the years.Most recently, I put 
together a scanner type application for scanning filters.  This

  might be a good starting point:

http://www.sbrac.org/files/filter_scan.grc
http://www.sbrac.org/files/scanning.py

This takes ruthless advantage of the newest "Python Module" block in 
GRC, which is a more-convenient way to integrate "helper"

  python code into .grc flowgraphs.

Cheers



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

[Discuss-gnuradio] How to measure throughput (data rate)

[Diyar Muhammed]

Dear All,
I have made a transceiver in gnuradio software with using usrp B210, and I
would like to measure data transmission between Tx and Rx, is there any way
to measure that?
-- 
Regards,
Diyar Muhammed
Ministry of Higher Education and Scientific Research
Duty: Network Administration and Design
Website:  www.mhe-krg.org
Cell Phone: 009647504690060
Office Phone:   00964662554683
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] tx <-> rx transmission

[Landsman, Arik]

P.S. - thread name is "costas ambiguity and correlate-and-sync block in qpsk"



From: Landsman, Arik
Sent: Monday, March 14, 2016 1:49 PM
To: przelew...@gmail.com
Cc: discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] tx <-> rx transmission



HI,

mfsk is the digital implementation of FM and analytically very similar to mpsk. 
psk is spectrally more efficient though. QAM is not feasible in wireless 
transmission (undeterministic amplitude of Rx stream) and is typically used for 
wired channels (say, docsis for cable). So I would focus on mpsk.

I had done the following, still working on recovering the 90* ambiguity for 
costas (see other thread), but overall here is what I have on the rx side:

power squalch --> AGC2 --> FLL (not required for a largely static channel) --> 
 --> Polyphase sync (or MM) --> CMA equalizer --> 
costas --> demod

note that AGC is needed for CMA and costas, but would not be ok for QAM of 
course.

the CMA eq likes > 1sample/sec, so set the polyphase output sps appropriately. 
Without CMA, costas has trouble locking with real signals (ok in most sims 
though). This isn't a particular problem for diff encoding, but not ok for a 
preamble sync and traditional psk demod. I use sps_out = 1/2*sps_in.

Tx sps should be > 2. I use 8 typically. sps=2 is not enough for most 
algorithms to converge. you could optimize (reduce) this value later - the 
N210's are limited to ~15MSPS, or 1/8 of that with sps=8..

keep in mind that for qpsk, the psk_mod transmits QPSK at 45*, 135* [...] where 
as costas aims to lock onto 0*,90*, etc. This can be easily corrected, but the 
default decision making for the psk_demod would not be happy about this, 
especially since it is a canned block with built in FLL/PPCS/Costas under 
default settings (no hooks to change from GRC besides loop bw). so unless using 
diff encoding you may want to design your own rx signal chain as you suggested.

to do that, you would need to pass your own constellation object to a 
"demapping block" (sorry the actual name escapes me, search in GRC, it is a 
remapper with a user-defined RRC taps). There are some good examples that Tom R 
put together in the gr-digital/examples folder that show how to manipulate 
constellation objects.

What did you mean by "blocker-problems"?

See also Andy Walls' comments in the "90* ambiguity" thread, some additional 
insights there.

Best Regards,
Arik


Hello friends, does anybody know where I can find some full example with
one way transmission in one of this modulations: m-psk, m-fsk, m-qam ??? -
But not Differential m-psk
I would like to   see full recovery path (carrier, symbol, equalization) in
radio receiver.
I know that there is example on gnuradio site but it doesnt involve real
devices, and if I tried myself to reconnect with devices this example I had
few blocker-problems :)
I have B210 and RTL.

PS.
What is a proper path of signal receiving in digital modulation receiver:
in my logic :

device -> clock recovery -> symbol recovery (costas loop) -> equalization
->demodulator -> packet deckoder
 ??
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Hardware "jitter", particularly USB

[Gregory W. Ratcliff]

GnuRadio community,
I have been using various hardware interfaces to gnuradio lately.In the 
simplest example, I noticed an issue with Funcube Pro Plus with broadcast 
wideband FM (about 4 GRC blocks) whereby it would consistently underflow, even 
though every rate appeared to be perfect.  A crude but effective fix has been 
to interpolate by 500, decimate by 499.
I occasionally notice a similar problem with DVB modules, never with Hermes.

This has caused me to wonder if some subtle error has crept into OSMOCOM or the 
Funcube module has a timing error (that had been masked previously by OSMOCOM). 
 

Am I alone in this (in which case I will look closely at usb/audio/pc hardware)?
Thanks in advance,
GregNZ8R
 Gregory W. Ratcliff




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

Re: [Discuss-gnuradio] tx <-> rx transmission

[Landsman, Arik]

HI,

mfsk is the digital implementation of FM and analytically very similar to mpsk. 
psk is spectrally more efficient though. QAM is not feasible in wireless 
transmission (undeterministic amplitude of Rx stream) and is typically used for 
wired channels (say, docsis for cable). So I would focus on mpsk.

I had done the following, still working on recovering the 90* ambiguity for 
costas (see other thread), but overall here is what I have on the rx side:

power squalch --> AGC2 --> FLL (not required for a largely static channel) --> 
 --> Polyphase sync (or MM) --> CMA equalizer --> 
costas --> demod

note that AGC is needed for CMA and costas, but would not be ok for QAM of 
course.

the CMA eq likes > 1sample/sec, so set the polyphase output sps appropriately. 
Without CMA, costas has trouble locking with real signals (ok in most sims 
though). This isn't a particular problem for diff encoding, but not ok for a 
preamble sync and traditional psk demod. I use sps_out = 1/2*sps_in.

Tx sps should be > 2. I use 8 typically. sps=2 is not enough for most 
algorithms to converge. you could optimize (reduce) this value later - the 
N210's are limited to ~15MSPS, or 1/8 of that with sps=8..

keep in mind that for qpsk, the psk_mod transmits QPSK at 45*, 135* [...] where 
as costas aims to lock onto 0*,90*, etc. This can be easily corrected, but the 
default decision making for the psk_demod would not be happy about this, 
especially since it is a canned block with built in FLL/PPCS/Costas under 
default settings (no hooks to change from GRC besides loop bw). so unless using 
diff encoding you may want to design your own rx signal chain as you suggested.

to do that, you would need to pass your own constellation object to a 
"demapping block" (sorry the actual name escapes me, search in GRC, it is a 
remapper with a user-defined RRC taps). There are some good examples that Tom R 
put together in the gr-digital/examples folder that show how to manipulate 
constellation objects.

What did you mean by "blocker-problems"?

See also Andy Walls' comments in the "90* ambiguity" thread, some additional 
insights there.

Best Regards,
Arik


Hello friends, does anybody know where I can find some full example with
one way transmission in one of this modulations: m-psk, m-fsk, m-qam ??? -
But not Differential m-psk
I would like to   see full recovery path (carrier, symbol, equalization) in
radio receiver.
I know that there is example on gnuradio site but it doesnt involve real
devices, and if I tried myself to reconnect with devices this example I had
few blocker-problems :)
I have B210 and RTL.

PS.
What is a proper path of signal receiving in digital modulation receiver:
in my logic :

device -> clock recovery -> symbol recovery (costas loop) -> equalization
->demodulator -> packet deckoder
 ??
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Debug GNU Radio and executing flowgraphs attaching to them

[Martin Braun]

On 03/12/2016 05:45 AM, Mabel Pita wrote:
> However, i am having trouble to find an IDE that even comes close to
> what visual studio has to offer.. and the practicality it has in windows
> to debug applicatons.
> 
> 
> So i ask here, because im probably too ignorant and there is an
> equivalente tool in linux that does this job.

Eclipse is quite popular, although I haven't used it in a long time.
QTCreator actually has great gdb support and looks really nice, too. If
I need a lot of windows (e.g. for watches), that's my choice.
Kdevelop also has debug integration. And many others probably do, too.

You'll still find people using gdb from the command line. There's many
reasons for that, habit being one of them, and the fact that the
lightweight UI also works well on embedded devices (e.g. when you're
ssh'd into a machine). Personally, I also just love having a command
line for pretty much everything. I'm still trying to find a really good
UI for gdb that gives me both the command line, and good editor
integration. cgdb isn't bad, but not quite what I'd prefer.
But I digress. There's a bajillitude of tools on Linux, and you can pick
whatever you prefer.

Cheers,
Martin

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

Re: [Discuss-gnuradio] Change frequency in USRP source automatically

[Martin Braun]

Yan,

check the PMT manuals. cons() takes 2 PMTs as input.


Cheers,
Martin

On 03/14/2016 09:09 AM, Yan Huang wrote:
> Hi all,
> 
>  
> 
> I want to change the frequency in “USRP source” automatically, for
> example 2.37GHz-2.43GHz with each time stepping 2MHz.
> 
>  
> 
> 1. As you know, the USRP source has an input message port, so I want to
> connect it to a “Message strobe” to control the frequency change. But
>  after I see [1][2], I write PMT type commands  in “Message PMT” in
> “Message Strobe” as:
> 
> pmt::cons(“freq”,2.4e9)
> 
> it comes up error “invalid syntax(,line 1)”, so I don’t know how
> to further stepping the frequency.
> 
> 2. If I use the “Message Strobe” to define frequency, what can I put in
> the “frequency” in “USRP source” block? Put it as 0?
> 
>  
> 
> [1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
> 
> [2]
> https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_commands
> 
>  
> 
> Many thanks ,
> 
>  
> 
> Yan
> 
>  
> 
> 
> 
> This message and any attachment are intended solely for the addressee
> and may contain confidential information. If you have received this
> message in error, please send it back to me, and immediately delete it. 
> 
> Please do not use, copy or disclose the information contained in this
> message or in any attachment.  Any views or opinions expressed by the
> author of this email do not necessarily reflect the views of the
> University of Nottingham.
> 
> This message has been checked for viruses but the contents of an
> attachment may still contain software viruses which could damage your
> computer system, you are advised to perform your own checks. Email
> communications with the University of Nottingham may be monitored as
> permitted by UK legislation.
> 
> 
> 
> ___
> 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] [Discuss- gnuradio] Nanoseconds Signal Time of Arrival on GRC

[Martin Braun]

It also depends on the algorithm you're using for detection. It's
unlikely they have sub-sample accuracy.

M

On 03/14/2016 08:58 AM, Marcus Müller wrote:
> Hi Ernest,
> 
>> Can GRC go Nanoseconds?
> GRC is just a frontend to baseband sample processing blocks. So there's
> not really an answer to this. If you had a device that would be giving
> you 2GS/s, yes, and if you can build an application that estimates the
> phase of an incoming signal, then also, maybe:
> 
> well, first of all, you will need to bring your receiver to an exact
> time, within whatever "exact" means to you. For USRPs, you might use the
> GPSDOs, and further timing refinement tricks (see Johannes Schmitz' talk
> at FOSDEM this year).
> Then, you'll need to determine a reference phase for your downconverted
> signal. Then, basically with the methods of interferometry, you can
> determine a sub-sample accurate estimate of the receive signal timing.
> 
> There's not a "ready to use" for your problem, because it depends on
> such an enormous number of specifics of your problem (chief amongst
> these hardware, accuracy demands, observation time, SNR, modulation of
> the CW). If your signal is really just a continuous wave, you'll always
> be signal-period ambiguous, unless you have another source of timing
> information.
> 
> It might be really worthwhile pointing you to the GNU Radio Guided
> Tutorials; you seem to have quite a good idea of what you want to
> implement, but your understanding of what GNU Radio does, and doesn't
> do, where the boundaries between GRC, GR, a flow graph and the whole SDR
> system lie might be lacking a bit behind that:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
> 
> Best regards,
> Marcus
> 
> On 03/13/2016 07:50 AM, ERNEST MATEY wrote:
>> Hi All,
>>
>> I am running a signal analysis on GRC. 
>> I will receive satellite CW signal and I want to know the exact
>> accurate time I received the CW signal.  I'm expecting the CW signal
>> as a sudden burst ‎. 
>>
>> What methods can I use in my GRC. Which blocks or Flow graph can I do
>> to achieve this?
>>
>> I am looking for accuracy in Nanoseconds. 
>> How can I achieve this? Can GRC go Nanoseconds?
>>
>> Thank you all GRC experts for helping!
>> Ernest
>>
>>
>>
>> Sent from my BlackBerry 10 smartphone.
>>
>>
>>
>> ___
>> 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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Change frequency in USRP source automatically

[Yan Huang]

Hi all,

I want to change the frequency in "USRP source" automatically, for example 
2.37GHz-2.43GHz with each time stepping 2MHz.

1. As you know, the USRP source has an input message port, so I want to connect 
it to a "Message strobe" to control the frequency change. But  after I see 
[1][2], I write PMT type commands  in "Message PMT" in "Message Strobe" as:
pmt::cons("freq",2.4e9)
it comes up error "invalid syntax(,line 1)", so I don't know how to 
further stepping the frequency.
2. If I use the "Message Strobe" to define frequency, what can I put in the 
"frequency" in "USRP source" block? Put it as 0?

[1] https://gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax
[2] https://gnuradio.org/doc/doxygen/page_msg_passing.html#msg_passing_commands

Many thanks ,

Yan





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

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

Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk

[Landsman, Arik]

Hi Andy, 

Thank you for the detailed answer, I am certainly going to try what you suggest 
in the next couple of days. will post with updates as progressing along.  

As a side, I tried to hack the corr_and_sync block using a preamble which in 
BPSK looks the same as both I and Q of the QPSK data (e.g. [1,-1] in bpsk is 
[1+j,-1-j] in qpsk). This does not quite work in practice, I was getting 
sinusoids with very weak correlation (amplitude in 30's 40's) from the corr 
port. Strange, since the block should ignore the imaginary portion of the 
stream anyways since designed for BPSK. 

in terms of a clock pattern for preamble, looks like Barker codes is the way to 
go, at least statistically speaking for low correlation with any random 
"preamble-like" bit combinations in the payload. So avoiding clock patterns for 
sure.  

Will look to tag the end of preamble, from your comments it appears to be the 
more universal approach. In my case freq lock should be fairly good though,  
channel is largely stationary, and I am using a FLL (although it does require 
longer bit combinations that are to result in a balanced spectrum to detect 
band edges). point well noted though. 

You mentioned M for timing recovery, have you tried the Polyphase  block?  
without passing tags, I had better results with the latter for whatever reason. 
 MM is more efficient though as I read. 

Just to clarify, were you capturing the time_est tags, or just relying on a 
combination of phase_est for costas and MM converging fast enough ahead of 
payload?

finally, would you know of any good references for passing tags in gnuradio? I 
will certainly search around, but in case anything comes to mind (?) 

Best Regards,
Arik



P.S. - In case it helps future causes - see "Phase-ambiguity resolution for 
QPSK modulation systems" by Nguyen, Tien Manh, NASA, 1989. Part1 outlines the 
basic two approaches for correcting phase, which are diff encoding or preamble 
correlation. The preamble algorithm there is very much similar to the one Andy 
describes, although likely implemented as an IC (aka ASSP). In this case the 
author suggests diff encoding for burst transmissions, since bits are wasted on 
a preamble (which theoretically has 2x BER compared to diff encoding). 

That said, if phase rotation occurs in mid-payload the full packet is lost, 
unless some form of post-processing is used to recover - so at higher SNR diff 
encoding is possibly better. But I am yet to find a publication that compares 
real data on the topic.  

http://ntrs.nasa.gov/search.jsp?N=0=All=Phase-ambiguity%20resolution%20for%20QPSK%20modulation%20systems=mode%20matchallpartial



 
From: Andy Walls [a...@silverblocksystems.net]
Sent: Sunday, March 13, 2016 8:51 AM
To: discuss-gnuradio@gnu.org
Cc: Landsman, Arik
Subject: Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block 
in qpsk

On Sun, 2016-03-13 at 01:35 -0500, discuss-gnuradio-requ...@gnu.org
wrote:
> Message: 1
> Date: Sat, 12 Mar 2016 21:34:03 +
> From: "Landsman, Arik"

>
> Hello folks,
>
> I am trying to resolve the 90* ambiguity of costas for a QPSK
> receiver, and was hoping folks could weigh-in in case anyone had
> success with this in the past.
>
> yes, diff encoding works.. :) trying to make it work without though.
>
> Also, I had seen Tom R's example of his cor-and-sync block
> implementation in BPSK (but not qpsk). maybe the block could be
> "hacked" to support qpsk, such as by passing the preamble as bpsk but,
> say, upsampling the block to make the generated complex reference
> align with the incoming qpsk stream. going to try this when I get home
> tonight.
>
> Since Trx will be bursty and will use a preamble anyways, another
> thought was to correlate the stream with the 4 possible versions of
> the preamble (i.e. constellation rotations), and pass the best
> candidate downstream to select the proper constell object for demod
> (as opposed to adjusting costas, as in cor-and-sync block), or use the
> result for post-processing the incorrectly demodulated data. But both
> seem a bit indirect or wastefull..
>
> Any thoughts?

Using a preamble makes sense to me.

Do not use the correlate_and_sync block; it is unreliable and provides
and errant "phase_est" value.

Use the corr_est block; it does correctly and more generically what the
correlate_and_sync block aimed to do.

To use the corr_est block:

1. Generate a vector of samples which represents your preamble.  A
test_corr_est.grc file can be found here:

https://github.com/gnuradio/gnuradio/tree/master/gr-digital/examples/demod

which should give an example of how to use gnuradio modulator blocks to
build the preamble samples vector for you.  You could also use, pyhton,
Matlab, octave, or whatever.


2. Tell the corr_est block where on the preamble you want it to place
the tags.  You must give the tag delay in units of samples.  Common
choices are:
a. start of preamble
b. middle of first 

Re: [Discuss-gnuradio] [Discuss- gnuradio] Nanoseconds Signal Time of Arrival on GRC

[Marcus Müller]

Hi Ernest,

> Can GRC go Nanoseconds?
GRC is just a frontend to baseband sample processing blocks. So there's
not really an answer to this. If you had a device that would be giving
you 2GS/s, yes, and if you can build an application that estimates the
phase of an incoming signal, then also, maybe:

well, first of all, you will need to bring your receiver to an exact
time, within whatever "exact" means to you. For USRPs, you might use the
GPSDOs, and further timing refinement tricks (see Johannes Schmitz' talk
at FOSDEM this year).
Then, you'll need to determine a reference phase for your downconverted
signal. Then, basically with the methods of interferometry, you can
determine a sub-sample accurate estimate of the receive signal timing.

There's not a "ready to use" for your problem, because it depends on
such an enormous number of specifics of your problem (chief amongst
these hardware, accuracy demands, observation time, SNR, modulation of
the CW). If your signal is really just a continuous wave, you'll always
be signal-period ambiguous, unless you have another source of timing
information.

It might be really worthwhile pointing you to the GNU Radio Guided
Tutorials; you seem to have quite a good idea of what you want to
implement, but your understanding of what GNU Radio does, and doesn't
do, where the boundaries between GRC, GR, a flow graph and the whole SDR
system lie might be lacking a bit behind that:
https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials

Best regards,
Marcus

On 03/13/2016 07:50 AM, ERNEST MATEY wrote:
> Hi All,
>
> I am running a signal analysis on GRC. 
> I will receive satellite CW signal and I want to know the exact
> accurate time I received the CW signal.  I'm expecting the CW signal
> as a sudden burst ‎. 
>
> What methods can I use in my GRC. Which blocks or Flow graph can I do
> to achieve this?
>
> I am looking for accuracy in Nanoseconds. 
> How can I achieve this? Can GRC go Nanoseconds?
>
> Thank you all GRC experts for helping!
> Ernest
>
>
>
> Sent from my BlackBerry 10 smartphone.
>
>
>
> ___
> 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] Picking up RF cellular signals

[Marcus Müller]

Hi Meny,
>
> What i did so far, is a program that calculates and outputs in a loop
> the power transmitted from a cellular phone from it's uplink channel.
> that can tell me my distance to it.
That won't really work, as I explained already[3]. Cell phones of any
generation since 2G can (and must) scale their output power depending on
link quality, and cellular antennas are far from omnidirectional, so the
power density depends on the orientation from the phone. We've discussed
this with you [1], and Tom pointed you to these problems of that being a
very crude way of measuring distance.

> problem is, that cellular phones are usually in idle mode and not
> transmitting at all.
True, at least unless you send them something they have to react to.
Which the phone will only do if you're the infrastructure, and usually
implies you authenticate as such[2]. Which will hence most likely only
work if the cellular providers cooperate with you.

> I'm trying to find a solution for this,
> There has to be a way of knowing that some kind of RF
> transmitter/receiver is near me...
> If anyone can shed some light on this subject, what can i do or if i
need to go in another way, i'll be very grateful!

We've already discussed this [1][2][3]; I think the right approach here
would be to address the concerns that Sylvain, Trip, Tom, Neel, and I
had about your way of approaching this.
> right now i'm stuck.
Might really be because your approach isn't feasible in its current form.


Best regards,
Marcus

[1] "[USRP-users] Questions about LTE and SDR" from Meny Sidar:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-December/017035.html
[2] "[USRP-users] Mobile phones interrogation using the B210" from Meny
Sidar:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-December/017393.html
[3] "[USRP-users] Measuring distance from usrp to cellular phone with RF
power" from Meny Sidar:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-December/017154.html




On 03/14/2016 03:54 PM, Meny Sidar wrote:
> Hi guys,
>
> I am currently working on a project for my university, where i'm
> trying to locate cellular phones using SDR (USRP B210).
> The idea of the project is to be able to find survivors/victims in
> disaster areas, such as earthquakes, by assuming they have their
> cellular on them.
>
> What i did so far, is a program that calculates and outputs in a loop
> the power transmitted from a cellular phone from it's uplink channel.
> that can tell me my distance to it.
> problem is, that cellular phones are usually in idle mode and not
> transmitting at all. 
> So it works, but only if the phone is currently transmitting to the
> network (phone call, internet, etc..)
>
> I'm trying to find a solution for this,
> There has to be a way of knowing that some kind of RF
> transmitter/receiver is near me...
> If anyone can shed some light on this subject, what can i do or if i
> need to go in another way, i'll be very grateful! 
> right now i'm stuck.
>
> Thanks a lot,
> Meny
>
>
> ___
> 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] Picking up RF cellular signals

[Sylvain Munaut]

> So it works, but only if the phone is currently transmitting to the network
> (phone call, internet, etc..)
>
> I'm trying to find a solution for this,
> There has to be a way of knowing that some kind of RF transmitter/receiver
> is near me...

Well ... no, not realistically.

An idle phone doesn't TX. It only powers up periodically to check the
paging channel. (For GSM it would be roughly 16ms every couple of
seconds).
During the RX the only thing you could detect is the LO leaking ...
that would be 50+ dB weaker than the phone itself (and I'm being
generous). Good luck detecting that ...


> If anyone can shed some light on this subject, what can i do or if i need to
> go in another way, i'll be very grateful!
> right now i'm stuck.

For disaster sites the most realistic option is a portable basestation
where the victim phone would automatically register to. Then once the
phone is on that BTS instead of the real network, establish an active
channel (doesn't need to be audio) so you can track it.

Cheers,

Sylvain

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

Re: [Discuss-gnuradio] Picking up RF cellular signals

[Meny Sidar]

It would be very helpful, but of course isn't an option...

2016-03-14 17:11 GMT+02:00 Dan CaJacob :

> I don't know much about cell phones, but would it help if you placed a
> call to a known number?  Does that force a response?  Of course, this might
> be counter-productive in a congested disaster environment.
>
> - Dan
>
> On Mon, Mar 14, 2016 at 10:56 AM Meny Sidar  wrote:
>
>> Hi guys,
>>
>> I am currently working on a project for my university, where i'm trying
>> to locate cellular phones using SDR (USRP B210).
>> The idea of the project is to be able to find survivors/victims in
>> disaster areas, such as earthquakes, by assuming they have their cellular
>> on them.
>>
>> What i did so far, is a program that calculates and outputs in a loop the
>> power transmitted from a cellular phone from it's uplink channel. that can
>> tell me my distance to it.
>> problem is, that cellular phones are usually in idle mode and not
>> transmitting at all.
>> So it works, but only if the phone is currently transmitting to the
>> network (phone call, internet, etc..)
>>
>> I'm trying to find a solution for this,
>> There has to be a way of knowing that some kind of RF
>> transmitter/receiver is near me...
>> If anyone can shed some light on this subject, what can i do or if i need
>> to go in another way, i'll be very grateful!
>> right now i'm stuck.
>>
>> Thanks a lot,
>> Meny
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> --
> Very Respectfully,
>
> Dan CaJacob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Picking up RF cellular signals

[Dan CaJacob]

I don't know much about cell phones, but would it help if you placed a call
to a known number?  Does that force a response?  Of course, this might be
counter-productive in a congested disaster environment.

- Dan

On Mon, Mar 14, 2016 at 10:56 AM Meny Sidar  wrote:

> Hi guys,
>
> I am currently working on a project for my university, where i'm trying to
> locate cellular phones using SDR (USRP B210).
> The idea of the project is to be able to find survivors/victims in
> disaster areas, such as earthquakes, by assuming they have their cellular
> on them.
>
> What i did so far, is a program that calculates and outputs in a loop the
> power transmitted from a cellular phone from it's uplink channel. that can
> tell me my distance to it.
> problem is, that cellular phones are usually in idle mode and not
> transmitting at all.
> So it works, but only if the phone is currently transmitting to the
> network (phone call, internet, etc..)
>
> I'm trying to find a solution for this,
> There has to be a way of knowing that some kind of RF transmitter/receiver
> is near me...
> If anyone can shed some light on this subject, what can i do or if i need
> to go in another way, i'll be very grateful!
> right now i'm stuck.
>
> Thanks a lot,
> Meny
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
-- 
Very Respectfully,

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

[Discuss-gnuradio] Picking up RF cellular signals

[Meny Sidar]

Hi guys,

I am currently working on a project for my university, where i'm trying to
locate cellular phones using SDR (USRP B210).
The idea of the project is to be able to find survivors/victims in disaster
areas, such as earthquakes, by assuming they have their cellular on them.

What i did so far, is a program that calculates and outputs in a loop the
power transmitted from a cellular phone from it's uplink channel. that can
tell me my distance to it.
problem is, that cellular phones are usually in idle mode and not
transmitting at all.
So it works, but only if the phone is currently transmitting to the network
(phone call, internet, etc..)

I'm trying to find a solution for this,
There has to be a way of knowing that some kind of RF transmitter/receiver
is near me...
If anyone can shed some light on this subject, what can i do or if i need
to go in another way, i'll be very grateful!
right now i'm stuck.

Thanks a lot,
Meny
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Johnathan Corgan]

Most of you already know me, as I’ve been in the GNU Radio community for
eleven years in various roles, including release manager, integration
manager, Live SDR developer, infrastructure manager, engineering
consultant, and technical trainer.  Today I’m happy to move on to the role
of Chief Architect.

It is an exciting time of transition for GNU Radio.  Recently there has
been large growth in several areas--growth in our user base, our number of
contributors, the types of radio applications and computing environments
that GNU Radio is running in, and hardware vendor support for interfacing
with GNU Radio applications.

Much of this success comes from the efforts of unpaid volunteer
contributors whose code they have made freely available to others in the
community.  This is the nature of open source development, and to a large
extent this has been accomplished without much formal direction from the
project.  As the GNU Radio codebase has grown more complex, we’ve seen the
need for more structured guidance and coordination across development
efforts.

As Ben has outlined, we’re filling out the new organizational roles of Tech
Leads, whom we are looking to champion their respective areas of
development.  This includes:


   -

   Developing a roadmap for feature development and communicating that
   roadmap to the user community and code contributors across the project
   -

   Identifying and recruiting individual code contributors
   -

   Shepherding feature proposals in their area through the process of
   getting community feedback and clarification
   -

   Coordinating code integration in their area of the code tree prior to
   final review and merging
   -

   Ensuring support issues and questions in their area of responsibility
   are properly resolved


In the next few weeks, Ben and I will be sharing more details about how we
will fill out the organization and how we will be operating the project and
the new Foundation.  Key among these are:


   -

   A new process for proposing, getting community feedback on, and
   documenting new (significant) feature development, patterned after the
   Python Improvement Proposal process many of you are already familiar with
   -

   A more structured code review, unit testing, integration, and release
   management process
   -

   Roadmap-based development tracks that allow better coordination among
   different developers, especially for feature sets that cross organizational
   lines
   -

   Improved communication among our globally distributed community and
   developer base


As Chief Architect, I’ll be working closely with Ben, our user community,
and each of our Tech Leads to accomplish these goals.

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

Re: [Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Ben Hilburn]

Hi all -

I have been involved with GNU Radio for the last seven years or so, and
have always greatly enjoyed being part of the project. I'm continually
impressed by our community, and I have met many of my closest colleagues
through GNU Radio. I’m very happy to now be stepping into this role. Tom
has done an amazing job of leading the project for the last 5+ years, and
I'm honored to pick up the baton from him.

My Role

As part of this leadership transition, Tom's responsibilities are being
split into two distinct roles. My role, Project Lead, is focused on the
organization, project direction & strategy, and external relationships.
Ownership of the GNU Radio code itself is now the responsibility of the Chief
Architect, Johnathan Corgan. Many of you already know Johnathan, and I'll
let him talk about his new role in more detail. In short, if something
touches the codebase, Johnathan is fundamentally responsible. For
everything else, it's me.

The Organization

With a community and project of our size and capability, GNU Radio benefits
greatly from having strong area leaders tackling specific efforts. We are
now formalizing the leadership roles necessary to run a project like GNU
Radio, and have identified key individuals to fill many of them.

[image: GNU Radio Organization.jpg]

Martin Braun's role of Community Manager will stay the same. In this
capacity, Martin will continue to manage community events, outreach, and
our presence in many external venues. Recent examples of Martin's work
include the Hackfest at c-base in Berlin, the SDR Track at FOSDEM, and our
involvement with Google Summer of Code.

In addition to his leadership of Volk, Nathan West has stepped up to fill
Johnathan Corgan's previous role of Release Manager. Nathan has been
managing the release process for GNU Radio over the last few months, and he
will now formally take over the role.

Tech Leads and Working Groups

You probably noticed a new type of leadership role in the image above, Tech
Lead, and the absence of 'Working Groups'. We created the concept of
'Working Groups' in 2013 as a way to bring focused development to a
particular effort within the project or community. After much discussion
post-GRCon16, we believe that this can be better accomplished with a
different leadership structure.

We have identified key technical areas of the project, each of which will
be driven & maintained by a Tech Lead. A Tech Lead is directly responsible
for the GNU Radio code in their area of leadership - you may notice that
the crew of Tech Leads is comprised of people who have established
themselves as core developers of the project. The GNU Radio codebase
contains highly complex algorithms spread across otherwise unrelated fields
- we have both advanced modulation techniques (e.g., OFDM) as well as Qt
GUI code, for example. The Tech Leads are area experts that are responsible
for these more focused & manageable portions of the project.

The Tech Leads are a key part of our software engineering process &
development leadership going forward. As such, I will defer to Johnathan
for further discussion of these topics.

Packaging

Packaging is a critical piece of our project success and growth, and we
have been fortunate to have some excellent and very active maintainers
working on GNU Radio. Going forward, these developers will have recognized
roles within the organization, and Maitland Bottoms, whom many of you have
met at Meetups and GRCons, has taken the role of Tech Lead for the Build
System & Packaging.

Unfilled Roles

As you can see from the image, we also have a number of unfilled roles in
the organization. If you are interested in becoming part of the GNU Radio
leadership, please don't hesitate to get in touch!

The Foundation

As GNU Radio grows into a more mature and professional project, its
organization must do the same to support it. Thus, we are very excited to
announce that we will be incorporating a GNU Radio Foundation. Our goal is
to eventually make the Foundation a proper 501(c)(3) non-profit, but as
that takes considerable time and effort, our first step will be a
corporation that will act under the same guidelines, but without the legal
status as a non-profit.

At the time of its creation, the GNU Radio Foundation will be immediately
responsible for:

   -

   Acting as the contract authority & legally responsible body for the
   organization (e.g., contracts signed in support of GRCon will be in the
   name of the Foundation, not individuals).
   -

   Managing all finances; all expenses come from the Foundation, and all
   revenues go to the Foundation.
   -

   Owning & managing all GNU Radio assets (e.g., domains, logins / access
   rights, PGP keys, IP not assigned to FSF, etc).


Creating the foundation will provide continuity independent of individuals
in the organization, will provide a central authority to manage our assets
and IP, and will act as the legal body representing the organization and
project.

The 

[Discuss-gnuradio] GNU Radio Organizational Changes to Address Growth

[Tom Rondeau]

I've been running the GNU Radio project for over five years. In this time,
we've dramatically expanded its capabilities, prominence, and performance.
We have attracted great developers and a fantastic user base. And we have
built the highly successful and growing annual GNU Radio conference.

I feel that I have accomplished a great deal of what I was hoping to when I
took over this role. Part of my job (and much of the fun) was being
hands-on with the code almost daily. But there's a lot more to do in GNU
Radio, and it is time for a new vision to move it forward to where we see
it going next.

While I was thinking about this role change, the opportunity arose for me
to become a DARPA program manager, which is one of the most exciting
opportunities I can imagine. I will still be working on radio,
communications, and, of course, software radio, and I still hope to support
the project and continue working with the community we have in whatever
ways that I can. But this new position gives me an opportunity to pursue
engineering, science, technology, and research in areas and ways that I
haven't been able to do in my current role.

I am pleased to announce our new leadership team, who are already very
familiar to many of you. Ben Hilburn will be taking over as Project Lead
while Johnathan Corgan will become the Chief Architect in charge of the
codebase. They have already been doing a great job of building up their
team structure and their vision for the next stages of this project, which
is exactly what we need to grow and move the project forward.

The transition is already happening, and we can all consider Ben and
Johnathan to have taken up their roles today. I will still be actively
involved in GNU Radio over the next couple of months until I start my new
position at the end of May.

You'll be hearing more details from them soon. But I hope that everyone
knows how proud I am of this project and what we're doing here as well as
my confidence in Ben, Johnathan, and what is coming next.

Thank you all!

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

Re: [Discuss-gnuradio] GSOC 2016 : Implement optimized, standardized channel codes

[Jan Krämer]

Hi Tanero,

Yes a general LDPC encoder/decoder pair was implemented during GSoC2013.
However as far as I know it is not yet volk enhanced. Tom should know more
about that, as he was the mentor for this project if I remember correctly.
This could also be a feasible GSoC project, though I have to admit that I
am no expert on LDPC codes. It could be a lot harder than BCJR/Viterbi
based decoders, as LDPC implies random memory accesses all over the place,
so an efficient data shuffling algorithm is crucial here (Again Tom might
know more about that). However I know for sure that the decoder for
standardized codes like DVBT2 can be enhanced by SSE/AVX operations. This
could also be a valid GSoC project where also gr-dtv core modules should
benefit. You could also have a look at this.

One last thing. Please keep all conversations about GSoC on the mailing
list. We want to keep the discussion as open and transparent as possible
and it is also for your own good if as many people/mentors read your
proposals/ideas. This is the best way for you to get feedback. Also keep in
mind that the decision about whether you can participate in GSoC is made by
all mentors, so if the other mentors know you better because you kept your
ideas visible on the GNURadio mailing list, your chances will better (given
you provided a good proposal).

Cheers,
Jan

2016-03-13 22:14 GMT+01:00 Tanero Juthero :

>   I have read the following resources you suggested I read.For the project
> I was intending to implement encoder and
>
> decoder for LDPC ,but going through the gr-fec module ,I noticed there
> were already encoders and decoders for ldpc.I came
>
> across a pdf on this same project for GSOC 2013 by Perez , I don't  know
> if I am right but it seems they had not yet been
>
> fully integrated as modules to add to the already existing convolution
> decoders and encoders.My question is will this
>
> project be about reusing the existing ldpc encoder and decoder
> codes,optimizing them with volk or having something
>
> new?  Thanks
>
> On Tue, Mar 8, 2016 at 8:38 AM, Jan Krämer  wrote:
>
>> Hi Tane,
>>
>> great to hear that you want to contribute to GSoC and GNURadio. Bad
>> things first (well not really too bad ;) ), you should have some knowledge
>> about the operations used in forward error correction. There are several
>> techniques used (LDPC, Turbo-Decoder, Viterbi) but you don't have to know
>> all of them. It is also a plus if you know in advance what kind of channel
>> code you want to implement as it affects the way it can be optimized. If
>> you don't know anything about decoders, a strong knowledge in optimizing,
>> especially vectorizing, algorithms might help equally.
>> If you want some good places to start I would recommend the "GNURadio
>> Guided Tutorials" [0], the documentation on VOLK [1] and the FEC-API [2]
>> (the GNURadio Forward Error Correction Framework).
>>
>> Hope that answers some of your questions.
>> Cheers,
>> Jan
>>
>> [0] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
>> [1] http://libvolk.org/
>> [2] https://gnuradio.org/doc/doxygen/page_fec.html
>>
>>
>> 2016-03-07 11:35 GMT+01:00 Tanero Juthero :
>>
>>>  Hello I am Tane Juth , Third year student studying Software
>>> engineering  at the Faculty Of Engineering and technology,University of
>>> Buea .I wish to contribute to Gnuradio for the Google Summer Of Code
>>> period.I have looked at the project   " Implement optimized,
>>> standardized channel codes" ,and I am interested to know the difficulty
>>> level and any resources to get me started.I have followed the tutorial on
>>> OOT to completion and ran the test cases.I looked at the gr-fec module
>>> codes encoders and decoders ,if there is any link to get me practicing more
>>> with gnuradio I'll love to have it.Thanks
>>>
>>> ___
>>> 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