discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 199, Issue 17


From: Qasim Chaudhari
Subject: Re: [Discuss-gnuradio] Discuss-gnuradio Digest, Vol 199, Issue 17
Date: Wed, 15 May 2019 05:49:41 +1000

Hi Hasan,
    When a digital signal is demodulated, the symbols should ideally map to the constellation. However, simply from the definition of frequency 2pi F = change in phase per unit time, we know that a rotating constellation implies that there is a carrier frequency offset between the Tx and the Rx local oscillators (which every real device naturally has). You would have seen it like a spinning wheel.
    There are many methods to correct for a frequency offset. The first thing to consider is that how large the frequency offset is.

- If it is greater than around 15% of your symbol rate, you need it to correct it before the matched filter and at a rate higher than the symbol rate.
- Otherwise, you can match filter first, downsample to 1 sample/symbol and then apply a compensation technique. The second point is that some methods use known data from the Tx (training or pilots) and some use blind or non-data-aided synchronization. Choose one depending on your system specifications.
- For a very small offset, a PLL or a Costas loop are sufficient for this purpose.

     Since your constellation is just rotating but otherwise okay, I guess your case is either the second or the third above. Also, it seems to me that you are not embedding known sequences or symbols in the Tx signal, so you need to implement a non-data-aided solution. Try the Costas loop first and in case it doesn't work, FLL band edge block second.

Cheers,
Qasim


On Wed, May 15, 2019 at 2:06 AM <address@hidden> wrote:
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: About GNURadio (Kyeong Su Shin)
   2. Re: [GSoC2019]: First report from Bowen (Bowen Hu)
   3. Re: UART block in GNU RADIO? (Albin Stig?)
   4. free(): invalid pointer for AM demod block at Gnuradio
      3.7.13.5 (Ignatius Rivaldi)
   5. Re: free(): invalid pointer for AM demod block at Gnuradio
      3.7.13.5 (Volker Schroer)


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

Message: 1
Date: Tue, 14 May 2019 02:03:49 +0000
From: Kyeong Su Shin <address@hidden>
To: Hasan Konan? <address@hidden>,       "address@hidden"
        <address@hidden>
Subject: Re: [Discuss-gnuradio] About GNURadio
Message-ID:
        <address@hidden>

Content-Type: text/plain; charset="utf-8"

Hello Hasan,


If you are transmitting from one hardware to another hardware, that is an expected behavior (due to various hardware imperfections - especially the master clock mismatch. ). Synchronization and equalization blocks on the receiver flowgraph must correct such problems. If you have such blocks on the receiver, but the angles of the symbols are rotating, then you know that there are problems on your synchronizer codes.


Also, please note that many GNU Radio PSK demodulation tutorials use blind synchronization & equalization methods using a polyphase clock sync, CMA equalizer, and a costas loop, which may not work very well unless the transmitter starts first and is persistently transmitting strong signals to the receiver. You are better off using non-blind synchronization & equlization methods (using training symbols and a matched filter). Unfortunately, I haven't done that using GNU Radio's synchronization blocks (so I cannot give much recommendations about that).


Finally, the "DPSK Mod" block in your Tx flowgraph is deprecated, and I am not sure why it has a Polyphase Clock Sync (which is something that I expect to see on the Rx flowgraph).


Regards,

Kyeong Su Shin


________________________________
?? ??: Hasan Konan? <address@hidden> ?? Discuss-gnuradio <discuss-gnuradio-bounces+ksshin=address@hidden>
?? ??: 2019? 5? 13? ??? ?? 8:21:50
?? ??: address@hidden
??: [Discuss-gnuradio] About GNURadio


Hello,

I'm Hasan. We are working on GNURadio. When broadcasting from a USRP device, we are experiencing some difficulties in the broadcast from other USRP devices.

For example, we send a 4PSK modulated signal from the transmitter. Then we observe the signal sent from the constellation diagram. However, this constellation diagram is constantly rotating around itself, with a continuous phase shift.

How do you think we can handle this problem?



Thank you so much.

Good work.



Hasan KONAN?

Y?ld?z Technical University | Electronic and Communication Engineering | 3th Grade

Tel: +90 546 402 7343




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20190514/5b00a4c3/attachment.html>

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

Message: 2
Date: Tue, 14 May 2019 05:42:16 +0000
From: Bowen Hu <address@hidden>
To: "address@hidden" <address@hidden>,
        "address@hidden" <address@hidden>
Subject: Re: [Discuss-gnuradio] [GSoC2019]: First report from Bowen
Message-ID:
        <address@hidden>

Content-Type: text/plain; charset="utf-8"

Hi Johannes,

Thank you for your advice. The source code of GNU Radio in GitHub repository is definitely a great reference, I have fork and clone it.

As I discussed with my mentor, Marcus, for OOT module which I am going to work on, the stable version acquired through distros would be enough.

I might port the code to a newer version later.

Best regards,
Bowen
?

________________________________
From: Johannes Demel <address@hidden>
Sent: Mon, 13 May 2019
To: Bowen Hu
Subject: Re: [Discuss-gnuradio] [GSoC2019]: First report from Bowen

Hi Bowen,
it's great that you start to work on your project right away. Since you
want to implement a new feature for GNU Radio, I'd suggest to use the
latest GNU Radio version which is the one in the repository. To rephrase
it, I recommend to use GNU Radio 3.8. Though, I assume you already
discussed this with your mentors or will do so.
Therefore I suggest to use a source build/install instead of the version
provided by your distribution.
Cheers
Johannes
Am 12.05.19 um 18:18 schrieb Bowen Hu:
> Hi all,
>
> I am happy to be accepted by GSoC 2019 working on cycle-accurate
> simulation of Verilog. Here
> <https://b0wen-hu.github.io/2019/05/12/First-report/>
> (https://b0wen-hu.github.io/2019/05/12/First-report/)
> is my first report.
>
>
> ## Progress this week
> I have set up the working environment and read some tutorials for GNU
> Radio development in the last few days.
>
> My current working environment is Ubuntu 18.04 LTS installed GNU Radio
> version 3.7.11 by apt, but I am considering switch to newest Ubuntu
> 19.04 which shipped with GNU Radio version 3.7.13 by apt.
>
> I am following the tutorial and created my first module gr-howto (This
> may not be a good name, so I will change the module name in the coming
> week). I will continue to read tutorials, hopefully I could finish them
> (from chapter 2 to chapter 7) in the next week.
>
> I also managed to run the simulation of a simple Verilog module with
> Verilator, it works as anticipated, you can find it here. This is just a
> standalone simulation program, in order to let the GNU Radio work with
> the Verilator-generated file, there are much work to do.
>
> ## Plan next week
> Finish all the tutorials from chapter 2 to chapter 7.
>
> Try to make the Verilator related header file available in GNU Radio
> blocks. A source block like this (flicker.v) would be a good start.
>
> ## Issue(s)
> The module name gr-howto need to be changed.
>
>
> Best regards,
> Bowen
>
> _______________________________________________
> 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/20190514/d4336519/attachment.html>

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

Message: 3
Date: Tue, 14 May 2019 08:28:56 +0200
From: Albin Stig? <address@hidden>
To: mehtap ?zkan <address@hidden>
Cc: M?ller, Marcus (CEL) <address@hidden>,     GNURadio Discussion List
        <address@hidden>
Subject: Re: [Discuss-gnuradio] UART block in GNU RADIO?
Message-ID:
        <CAMc++1WPJXvOU6ufRp-kPvdm3yt_bFy=+address@hidden>
Content-Type: text/plain; charset="utf-8"

You mean a block where you input bytes, and the block adds start bit, stop
bit and parity bit(s)?

Albin

On Mon, May 13, 2019, 23:04 mehtap ?zkan <address@hidden> wrote:

> Well, I would gladly pay for a c++ block. Anyone interested?
>
> 13 May 2019 Pzt 23:40 tarihinde M?ller, Marcus (CEL) <address@hidden>
> ?unu yazd?:
>
>> I doubt you'd find a ready-made block. However, writing that would take
>> literal minutes in Python or C++!
>>
>> https://wiki.gnuradio.org/index.php/Guided_Tutorials Chapters 2,3,4 and
>> 5 should be an easy read for you at this point.
>>
>> Best regards,
>> Marcus
>>
>> On Mon, 2019-05-13 at 23:09 +0300, mehtap ?zkan wrote:
>> > Dear All,
>> >  Is there an OOT block where the input is UnPacked Data and the output
>> is UART formatted UnPacked data.
>> > The UART Protocol is shown in
>> http://www.circuitbasics.com/wp-content/uploads/2016/01/Introduction-to-UART-Packet-Frame-and-Bits-2.png
>> .
>> > _______________________________________________
>> > Discuss-gnuradio mailing list
>> > address@hidden
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
> _______________________________________________
> 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/20190514/b767e725/attachment.html>

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

Message: 4
Date: Tue, 14 May 2019 23:02:08 +1000
From: Ignatius Rivaldi <address@hidden>
To: GNURadio Discussion List <address@hidden>
Subject: [Discuss-gnuradio] free(): invalid pointer for AM demod block
        at Gnuradio 3.7.13.5
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset="utf-8"

I'm running Arch Linux with Gnu Radio 3.7.13.5 and
Python 2.7.16 (default, Mar 11 2019, 18:59:25)
[GCC 8.2.1 20181127] on linux2

and if I try to use AM demod block with anything the flowgraph crashes
with this:

>>> Warning: This flow graph may not have flow control: no audio or RF hardware blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion.

Executing: /usr/bin/python2 -u /home/feanor/Development/SDR/top_block.py

free(): invalid pointer

>>> Done

This is just a AM demod block with null sink and null source attached
to it, reproduction flowgraph is attached to this email
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug2.grc
Type: application/octet-stream
Size: 5772 bytes
Desc: not available
URL: <http://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20190514/baf656b0/attachment.obj>

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

Message: 5
Date: Tue, 14 May 2019 17:54:06 +0200
From: Volker Schroer <address@hidden>
To: address@hidden
Subject: Re: [Discuss-gnuradio] free(): invalid pointer for AM demod
        block at Gnuradio 3.7.13.5
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8; format=flowed

You have set passband frequency to 0 ! So your passband reaches from 0
to 0. That make no sense. Probably a parameter check should be
introduced to the demod block Further  you should add a throttle block
after your source.

Same problem can be found in 3.8.


Am 14.05.19 um 15:02 schrieb Ignatius Rivaldi:
> I'm running Arch Linux with Gnu Radio 3.7.13.5 and
> Python 2.7.16 (default, Mar 11 2019, 18:59:25)
> [GCC 8.2.1 20181127] on linux2
>
> and if I try to use AM demod block with anything the flowgraph crashes
> with this:
>
>>>> Warning: This flow graph may not have flow control: no audio or RF hardware blocks found. Add a Misc->Throttle block to your flow graph to avoid CPU congestion.
>
> Executing: /usr/bin/python2 -u /home/feanor/Development/SDR/top_block.py
>
> free(): invalid pointer
>
>>>> Done
>
> This is just a AM demod block with null sink and null source attached
> to it, reproduction flowgraph is attached to this email
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>




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

Subject: Digest Footer

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


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

End of Discuss-gnuradio Digest, Vol 199, Issue 17
*************************************************

reply via email to

[Prev in Thread] Current Thread [Next in Thread]