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 <t...@trondeau.com> wrote: > On Mon, Sep 3, 2012 at 5:44 PM, Travis Collins <travisfcoll...@gmail.com> > 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 <t...@trondeau.com> wrote: >>> On Fri, Aug 31, 2012 at 3:13 PM, Travis Collins >>> <travisfcoll...@gmail.com> 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
