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

2014-10-28 Thread Jason Noble
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
  , 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 t...@trondeau.com wrote:

 On Mon, Oct 13, 2014 at 4:30 PM, Jason Noble jason.noble...@gmail.com
 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 
 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




qam16_txrx_polyphase_debug.grc
Description: application/gnuradio-grc


sample-16qamdump.bin
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

2014-10-16 Thread Tom Rondeau
On Mon, Oct 13, 2014 at 4:30 PM, Jason Noble jason.noble...@gmail.com
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  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
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio