discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Fwd: QTGui Number Sink, Demodulation Problems


From: Jason Noble
Subject: Re: [Discuss-gnuradio] Fwd: QTGui Number Sink, Demodulation Problems
Date: Wed, 29 Oct 2014 05:12:54 +0900

Tom,

Thanks for the quick bug fix Re: the number sinks. In the interim I've been troubleshooting by dumping output to a binary file and discovered other mistakes on my part. But once again I'm at an impasse. I captured some data which I view in the terminal using xxd -b filename.

The interesting thing is that the first portion of the file is all 1's "1111 1111 1111", which is the correct output that I'm looking for. However, it transitions to outputting "0101 0101 0101" and stays with that output apparently indefinitely. Could this in some way be caused by the Polyphase Clock Sync?

Thanks,
-Jason


On Fri, Oct 17, 2014 at 1:56 AM, Tom Rondeau <address@hidden> wrote:
On Mon, Oct 13, 2014 at 4:30 PM, Jason Noble <address@hidden> wrote:

The purpose of my current experiments is to create a 16QAM transmitter and receiver, with UDP sources/sinks, and using bladeRFx40's to transmit/receive.

I'm using Number sinks to check values at various points of my flowgraph. If I use a constant source value of 1, a float input type to a Number sink displays a "1", but a byte input type displays a "0". This is problematic because I'm trying to troubleshoot the QAM demodulator which has an output type of byte.

I've got Number sinks throughout the flowgraph. The source, modulator, and polyphase clock all output correct values for samples/symbols of "1111" but the demodulator is giving outputs of "0".

Are these bugs, or am I doing something wrong?
Also, I tried replacing the QAM mod/demod blocks with 8PSK blocks and still have the save problem.

Thanks in advance for any assistance.

Yeah, this was a bug. Looks like a very stupid mistake on my part.

I've pushed a fix that mostly works, but we can't really fix it without breaking the api. It should work fine now for char, short, and float inputs. There's a note in the block's documentation about this.

Tom


Attachment: qam16_txrx_polyphase_debug.grc
Description: application/gnuradio-grc

Attachment: sample-16qamdump.bin
Description: Binary data


reply via email to

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