Re: [Discuss-gnuradio] Queue Source not being processed by DPSK Demod Block

[Travis Collins]

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

On Tue, Sep 4, 2012 at 10:26 AM, Tom Rondeau <address@hidden> wrote:
> On Mon, Sep 3, 2012 at 5:44 PM, Travis Collins <address@hidden> wrote:
>> 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: http://pastebin.com/M2CrVPwP
>>
>> -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
>
>
>
>> On Sat, Sep 1, 2012 at 11:32 AM, Tom Rondeau <address@hidden> wrote:
>>> On Fri, Aug 31, 2012 at 3:13 PM, Travis Collins
>>> <address@hidden> 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