Forum: GNU Radio QAM demod Error in GRC

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
w w (Guest)
on 2009-05-26 16:32
(Received via mailing list)
Greetings,
I'm getting the following error in GRC:    Runtime error: hierarchical
block
'qam8_demod' input 0 is not connected internally'

Any Suggestions?

Cheers,
Jody
Josh B. (Guest)
on 2009-05-26 21:17
(Received via mailing list)
Its no bug in GRC. It seems the qam8 demodulator is empty:

http://gnuradio.org/trac/browser/gnuradio/trunk/gn...
w w (Guest)
on 2009-05-29 14:36
(Received via mailing list)
Josh,
I noticed that the QAM demod is not in the 3.2 release....do you know
when
it will be included?   Also, on the BPSK challenge/award thread, Rene
said
that there was a 99.9% GRC soultion....do you happen to know about this
solution and if so, can you share it with me?

Thanks,
Jody
Josh B. (Guest)
on 2009-05-30 20:56
(Received via mailing list)
> I noticed that the QAM demod is not in the 3.2 release....do you know when
> it will be included?   Also, on the BPSK challenge/award thread, Rene said

Someone has to invent it. Most of the blocks are there in the d8psk
demodulator, you just have to run a packet receiver on each different
phase orientation of the constellation, and pick whichever one gets a
packet. Ugly solution codewise, perhaps that is why no one has
implemented it.

> that there was a 99.9% GRC soultion....do you happen to know about this
> solution and if so, can you share it with me?

I have no idea.

-Josh
udadidd (Guest)
on 2009-11-12 10:18
(Received via mailing list)
Hi Josh
I am trying to implement this qam8_demod()
I did not follow this statement that u have mentioned in one of ur
previous
mails "you just have to run a packet receiver on each different phase
orientation of the constellation"

Can u plz explain me the same?
I have an understanding that the demod structure follows the same as
that of
dqpsk/d8psk.
This is how i see the constellation of the demod
http://old.nabble.com/file/p26314919/qam8_eye.png qam8_eye.png
I really need to implement this and need some suggestion on this

Thanks a lot
Udaya

Someone has to invent it. Most of the blocks are there in the d8psk
demodulator, you just have to run a packet receiver on each different
phase orientation of the constellation, and pick whichever one gets a
packet. Ugly solution codewise, perhaps that is why no one has
implemented it.

> that there was a 99.9% GRC soultion....do you happen to know about this
> solution and if so, can you share it with me?

I have no idea.

-Josh


_______________________________________________
Discuss-gnuradio mailing list
removed_email_address@domain.invalid
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio



--
View this message in context:
http://old.nabble.com/QAM-demod-Error-in-GRC-tp237...
Sent from the GnuRadio mailing list archive at Nabble.com.
Josh B. (Guest)
on 2009-11-12 10:36
(Received via mailing list)
udadidd wrote:
> http://old.nabble.com/file/p26314919/qam8_eye.png qam8_eye.png
> I really need to implement this and need some suggestion on this
>

Well, when you receive a qam signal, and lock to it, you still have some
unknown phase offset. Lets suppose qam8 has two possible phases: 0 and
180 degrees. Since you don't know which phase is correct, you can look
for the packet header in the received signal at 0 degrees and
simultaneously at 180 degrees. Whichever phase offset yields a valid
packet is the winner. Of course, this all assumes that you are framing
your data with some kind of packet headers.

Anyone else have some qam demodulation ideas to share?

-josh
Vlad S. (Guest)
on 2011-05-19 15:56
(Received via mailing list)
Dear list and Josh,
I'm still getting this error when using the QAM Demod block (qamX_demod
is
not connected internally).
Are there any new developments concerning these blocks?

Vlad.


Josh B.-2 wrote:
>
> -josh
> _______________________________________________
> Discuss-gnuradio mailing list
> removed_email_address@domain.invalid
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

--
View this message in context:
http://old.nabble.com/QAM-demod-Error-in-GRC-tp237...
Sent from the GnuRadio mailing list archive at Nabble.com.
Robert McGwier (Guest)
on 2011-05-19 21:23
(Received via mailing list)
Vlad

It is apparent to me that you did not understand Josh's explanation.
 Possibly he was not forceful enough. ;-).

This is not an error.  It is the mathematical consequence of doing QAM
with
rotational symmetries.  YOU MUST provide your OWN synchronization to
remove
the phase ambiguity.  It is not a bug or an error. It is a feature.  It
is
the mathematical nature of the beast.

Bob


On Thu, May 19, 2011 at 7:55 AM, Vlad Stoianovici <
Ben R. (Guest)
on 2011-05-19 22:15
(Received via mailing list)
Wouldn't one normally use differential encoding to avoid this problem?
Maybe I'm missing something important.

Ben
Marcus D. Leech (Guest)
on 2011-05-19 22:47
(Received via mailing list)
On 19/05/2011 1:21 PM, Robert McGwier wrote:
> Bob
>
Perhaps I have only part of the conversation here, but it sounds like
the main complaint is that there are internal errors inside the
   QAMx, x=8,16,64,256 demod blocks--they're implemented as hierarchical
blocks in Python.

Looking into it, it seems like there still aren't any implementations of
QAMx demodulators--what is there is basically a hollow shell that
   does nothing useful.
Vlad S. (Guest)
on 2011-05-23 14:30
(Received via mailing list)
Dear Marcus and Bob,
I did understand that the block was hollow, but this thread is kindda
old,
so I thought that in the mean time maybe someone implemented the code
and
functionality you are referring to.
I'm using GRC, but I don't have time to start learning python with the
sole
purpose of being able to write the QAM block.
It would probably be easier to use Simulink, which I'd rather not do.

Vlad.



Marcus D. Leech wrote:
>> feature.  It is the mathematical nature of the beast.
>    does nothing useful.
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> removed_email_address@domain.invalid
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context:
http://old.nabble.com/QAM-demod-Error-in-GRC-tp237...
Sent from the GnuRadio mailing list archive at Nabble.com.
Josh B. (Guest)
on 2011-05-23 21:10
(Received via mailing list)
On 05/23/2011 03:29 AM, Vlad Stoianovici wrote:
>
> Dear Marcus and Bob,
> I did understand that the block was hollow, but this thread is kindda old,
> so I thought that in the mean time maybe someone implemented the code and
> functionality you are referring to.
> I'm using GRC, but I don't have time to start learning python with the sole
> purpose of being able to write the QAM block.
> It would probably be easier to use Simulink, which I'd rather not do.
>

This is a motivating example for a new gr-digital component that can
make use of tags: the QAM deframer block. :-)

-josh
Ben R. (Guest)
on 2011-05-24 01:38
(Received via mailing list)
On Mon, May 23, 2011 at 12:09 PM, Josh B. <removed_email_address@domain.invalid> 
wrote:
>> It would probably be easier to use Simulink, which I'd rather not do.
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

In the psk8 branch of my github repo
(www.github.com/benreynwar/gnuradio/) there is QAM modulation and
demodulation within the "digital" category of GRC.  I haven't tested
it recently though.  Let me know if you try it and it doesn't work.

Cheers,
Ben
Tom R. (Guest)
on 2011-05-24 14:15
(Received via mailing list)
On Mon, May 23, 2011 at 10:37 PM, Ben R. <removed_email_address@domain.invalid> 
wrote:

> >> functionality you are referring to.
>
> In the psk8 branch of my github repo
> (www.github.com/benreynwar/gnuradio/) there is QAM modulation and
> demodulation within the "digital" category of GRC.  I haven't tested
> it recently though.  Let me know if you try it and it doesn't work.
>
> Cheers,
> Ben



Ben's branch is based off of my 8psk branch in github, too. I still need
to
pull in his changes. I have a feeling we might be going back and forth a
bit
in the development of the gr-digital top-level directory. This will make
it
into the upcoming 'next' branch for the 3.5 release.

Currently, it includes a more robust version of the Costas loop (you
specify
the natural freq and damping factor instead of the gains; it sets the
gains
properly so that the system is more tolerant and locks better) as well
as a
reworking of the CMA equalizer. I have yet to use this equalizer on a
real
signal, only simulated multipath channels, so more experience would be
good.

Note that if you are using this branch you should --disable-gr-trellis.
I
banged up the API that is used in gr-trellis and haven't got back to fix
it,
yet.

Tom
Colby B. (Guest)
on 2011-05-24 20:31
(Received via mailing list)
On Tue, May 24, 2011 at 3:13 AM, Tom R. <removed_email_address@domain.invalid>
wrote:
>> >> so I thought that in the mean time maybe someone implemented the code
>> >
> Ben's branch is based off of my 8psk branch in github, too. I still need to
> yet.
> Tom
>
> _______________________________________________
> Discuss-gnuradio mailing list
> removed_email_address@domain.invalid
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

Tom, somewhat related.

In the next week or so (when I have time), I will be contribute a
Gardner timing sync block to GNURadio. It should be a nice addition
for the DxPSK blocks, as it is carrier phase independent.

--Colby
Tom R. (Guest)
on 2011-05-25 18:45
(Received via mailing list)
On Tue, May 24, 2011 at 5:29 PM, Colby B. <removed_email_address@domain.invalid>
wrote:

> >> >> I did understand that the block was hollow, but this thread is kindda
> >> >
> >> Cheers,
> specify
> it,
> --Colby
>


Thanks, Colby, it'd be good to have that one in the toolbox. The M&M
loop
and PFB clock sync blocks are also phase independent, though :)

Tom
Tom R. (Guest)
on 2011-05-25 19:17
(Received via mailing list)
On Wed, May 25, 2011 at 10:00 AM, Tom R.
<removed_email_address@domain.invalid>wrote:

>> >> > On 05/23/2011 03:29 AM, Vlad Stoianovici wrote:
>> the
>> >>
>> > pull in his changes. I have a feeling we might be going back and forth a
>> > reworking of the CMA equalizer. I have yet to use this equalizer on a
>>
> Thanks, Colby, it'd be good to have that one in the toolbox. The M&M loop
> and PFB clock sync blocks are also phase independent, though :)
>
>  Tom
>

Let me amend that. The PFB is absolutely phase independent. Our
implementation of the M&M loop is not quite text-book, and it has some
phase
immunity (based on the way we update mu), but it can get caught in a
local
minimum if the phase offset is close to +/- 90 deg. It really should be
phase-locked beforehand.

Tom
This topic is locked and can not be replied to.