# Re: Queue Source not being processed by DPSK Demod Block **URL:** \ **Category:** GNU Radio\ **Created:** [August 31, 2012, 9:14pm UTC](https://www.ruby-forum.com/t/re-queue-source-not-being-processed-by-dpsk-demod-block/222535 "2012-08-31T21:14:21Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![aris](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/258eb7/32.png) [@aris](https://www.ruby-forum.com/u/aris)\ **Post date:** [August 31, 2012, 9:14pm UTC](https://www.ruby-forum.com/t/re-queue-source-not-being-processed-by-dpsk-demod-block/222535/1 "2012-08-31T21:14:21Z")
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 ---
**Author:** ![Travis\_Collins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/6f9a4e/32.png) [@Travis\_Collins](https://www.ruby-forum.com/u/Travis_Collins)\ **Post date:** [September 1, 2012, 5:33pm UTC](https://www.ruby-forum.com/t/re-queue-source-not-being-processed-by-dpsk-demod-block/222535/2 "2012-09-01T17:33:54Z")
On Fri, Aug 31, 2012 at 3:13 PM, Travis Collins [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![Travis\_Collins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/6f9a4e/32.png) [@Travis\_Collins](https://www.ruby-forum.com/u/Travis_Collins)\ **Post date:** [September 3, 2012, 11:45pm UTC](https://www.ruby-forum.com/t/re-queue-source-not-being-processed-by-dpsk-demod-block/222535/3 "2012-09-03T23:45:17Z")
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](http://pastebin.com/M2CrVPwP) -Travis ---
**Author:** ![Travis\_Collins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/6f9a4e/32.png) [@Travis\_Collins](https://www.ruby-forum.com/u/Travis_Collins)\ **Post date:** [September 4, 2012, 8:37pm UTC](https://www.ruby-forum.com/t/re-queue-source-not-being-processed-by-dpsk-demod-block/222535/4 "2012-09-04T20:37:14Z")
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 ---
**Author:** ![Travis\_Collins](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/6f9a4e/32.png) [@Travis\_Collins](https://www.ruby-forum.com/u/Travis_Collins)\ **Post date:** [September 4, 2012, 4:27pm UTC](https://www.ruby-forum.com/t/re-queue-source-not-being-processed-by-dpsk-demod-block/222535/5 "2012-09-04T16:27:36Z")
On Mon, Sep 3, 2012 at 5:44 PM, Travis Collins [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](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