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
Its no bug in GRC. It seems the qam8 demodulator is empty:
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
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 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
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
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p31655276.html
Sent from the GnuRadio mailing list archive at Nabble.com.
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 <
Wouldn’t one normally use differential encoding to avoid this problem?
Maybe I’m missing something important.
Ben
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.
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
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
–
View this message in context:
http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p26314919.html
Sent from the GnuRadio mailing list archive at Nabble.com.
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
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
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p31679995.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On Mon, May 23, 2011 at 12:09 PM, Josh B. [email protected] wrote:
It would probably be easier to use Simulink, which I’d rather not do.
Discuss-gnuradio Info Page
In the psk8 branch of my github repo
(GitHub - benreynwar/gnuradio: GNU Radio) 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
On Mon, May 23, 2011 at 10:37 PM, Ben R. [email protected] wrote:
functionality you are referring to.
In the psk8 branch of my github repo
(GitHub - benreynwar/gnuradio: GNU Radio) 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
On Tue, May 24, 2011 at 5:29 PM, Colby B. [email protected]
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
On Wed, May 25, 2011 at 10:00 AM, Tom R.
[email protected]wrote:
On 05/23/2011 03:29 AM, Vlad Stoianovici wrote:
thepull 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 aThanks, 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, thoughTom
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
On Tue, May 24, 2011 at 3:13 AM, Tom R. [email protected]
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
[email protected]
Discuss-gnuradio Info Page
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