Re: Queue Source not being processed by DPSK Demod Block

GNU Radio
1

Ive change the connected block from a dbpsk_demod to a null_sink and a
file_sink and the queue is processed, but I’m still having an issue
with the demod block.

I believe the problem has to be with the data type conversion
“processed.tostring()”. Should I convert each individual value of the
numpy array to a string and append them together or is there a better
way? The numpy array itself is made up of complex data.

-Travis

2

On Fri, Aug 31, 2012 at 3:13 PM, Travis Collins
[email protected] wrote:

Ive change the connected block from a dbpsk_demod to a null_sink and a
file_sink and the queue is processed, but I’m still having an issue
with the demod block.

I believe the problem has to be with the data type conversion
“processed.tostring()”. Should I convert each individual value of the
numpy array to a string and append them together or is there a better
way? The numpy array itself is made up of complex data.

-Travis

Hi Travis,

Can you provide more details when you say that it’s not processing the
data? What does that actually mean? Is it not doing anything or just
not doing what you expect?

The numpy array shouldn’t be a problem since you are converting it to
a string directly. Although make sure that what tostring() returns is
what you think it should return.

As for the dpsk modulator: is that the modulator from GNU Radio? Are
you basically trying to do what we do in
examples/narrowband/benchmark_tx.py? If so, that modulator expects
(packed) bits, not complex samples. It will convert the bits to
complex samples internally.

Tom

3

By “not processing data” I mean I look at the size of the source
queue, which is attached to the dpsk_demod block and it just grows
without data being removed. I just use the queue.count() method to
observe this. I can even stop adding data to the message source block
and the queue count remains the same.

Yes I’m using the dpsk_demod supplied with GNU-Radio. When you
mention the modulator, that doesnt apply here correct? Since Im using
only a demod and that should take complex data and then output packet
bits.

When I convert the numpy array to a large string I get segmentation
faults now even at very low sample rates. Here is a link to the
flow-graph if you wanna take a look: #!/usr/bin/env python################################################### Gnu - Pastebin.com

-Travis

4

I’m trying to get a channel estimate, therefore I need to access the
data before the demodulator, since the demodulator will quantize the
data. My flow-graph isnt using USRP’s for the meantime, just a channel
model. So my system receiver goes like this:

CHANNEL_MODEL -> MESSAGE_SINK -> DO SOME PYTHON PROCESSING ->
MESSAGE_SOURCE -> DEMODULATOR -> FILE_SINK

I was trying to do this in C++ originally but ran into a lot of
problem with external Linear Algebra libraries with SWIG.

-Travis

5

On Mon, Sep 3, 2012 at 5:44 PM, Travis Collins
[email protected] wrote:

When I convert the numpy array to a large string I get segmentation
faults now even at very low sample rates. Here is a link to the
flow-graph if you wanna take a look: #!/usr/bin/env python################################################### Gnu - Pastebin.com

-Travis

Ah, I see my confusion. You’re talking about adding to the
demodulators queue. Inserting into the message queue made me think you
were working on the modulator side. In this case, the demodulator
itself is what inserts the messages. It’s your task (or, more
precisely, the application’s task) to remove the messages from the
queue; in other words, the queue holds the frames created by the
demodulator/receiver chain. Look in gr-digital/python/pkt.py in the
_queue_watcher_thread function. That’s where the messages are being
popped off the queue.

The demodulator expects a stream of complex values as inputs (from,
say, a USRP source).

Tom