[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Queue Source not being processed by DPSK Demod Bl
Re: [Discuss-gnuradio] Queue Source not being processed by DPSK Demod Block
Mon, 3 Sep 2012 17:44:36 -0400
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
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
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.
> 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.