RE: [Discuss-gnuradio] GRC: Serial Port to Block Diagram Interface

[John Bonn]

Thanks for the pointer, Josh! It surely did help... But now I'm stuck up somewhere else..

I managed to hack up the grc_gnuradio/blks2/probe.py to make the source block I require. But before that, let me make clear my intention is to mainly use the Graphical Sinks / Operators in GRC, to be able to wire up blocks for processing and displaying the signals I acquire from my serial interface. Right now, I'm using the python random number generator to shove me samples (in a similar callback function ref:probe.py).

I wired up the blocks in this fashion in GRC:

[ My Block ] -> [ Throttle ] -> [ Variable Sink ]

and kept a Variable Text Box also in the window, referring to the ID in Variable Sink. Now I'm able to see the samples from the random number generator in the Variable Text Box.This works since Variable Sink is basically just a Message Sink with Callback. I could also use Operator Blocks like Multiply, Add on the incoming sample stream (placed after the Throttle block), whose output I'm able to see clearly on the Variable Text Box.

Now to the issue - when I replace the Variable Sink block with any of the typical Graphical Sink blocks [Scope, Number, Histo] or even File sink, nothing seems to come out in the Sink. I suspect this due to the format of data expected by these traditional Sink blocks to be different from what is coming out from the Message Queue.

This is the portion of the code I am using (from probe.py) to insert messages into the queue:
....
        arr = numpy.array(random.random(), numpy.float32)
        return gr.message_from_string(arr.tostring(), 0, gr.sizeof_float, 1)
        self._msgq.insert_tail(msg)
....

I'm not entirely clear about the argument structure for gr.message_from_string() function, for which I couldn't find much documentation. I could understand the second argument represents message type (0 for all data messages, 1 for End-Of-Message). I've no idea what the third and fourth argument actually conveys.

I do understand that message queues were not exactly built for this purpose. But I'm sure the mechanism to make the data acceptable to the traditional Sink blocks would have some good use, let alone this poor chap's ;)

Or am I in the wrong direction using message queues ?

Still Cheering,

John

> Date: Thu, 14 Jan 2010 14:46:12 -0800
> From: address@hidden
> To: address@hidden
> Subject: Re: [Discuss-gnuradio] GRC: Serial Port to Block Diagram Interface
>
> You should make a hier2 block that has a gr.message_source inside of it.
> You can put data you read from the serial port into a message queue.
> (internally) The message sink will pop items off of the queue and into a
> gnuradio stream.
>
> Take a look in grc/grc_gnuradio/blks2/* for example. Several of the
> blocks in there make use of these message blocks and message queues.
> Then, to get the block in grc, you can make an xml file modeled off of
> one of the blocks in grc/blocks/*.xml
>
> Hope that points your in the right direction.
> -Josh
>
> On 01/14/2010 02:17 PM, John Bonn wrote:
> >
> > Hello friends..
> >
> > I'm trying to setup some experiments to utilize the GRC environment. As a
> > part of it, I'm reading samples off an ADC connected to a microcontroller
> > connected to PC via UART/RS232 Serial, using PySerial module.
> >
> > I have been trying to write a Source block for GR, where a listening thread
> > would read the ADC samples from the Serial port into a global variable, and
> > then, another thread wud "probably" pass the data into a gr.vector_source
> > (like?) block within a hier2 block.
> >
> > Well, that was just the idea. But I guess the system doesn't work this way.
> > I'm not sure whether I'm entering the message-blocks domain, which is
> > expected to support such packetised(?) data. I read in the GRC Wiki - "add
> > custom blocks" section that it might be possible to make such "special"
> > functionality encapsulated in a block-diagram-safe block. Any suitable
> > examples ?
> >
> > Conflicting again is the thought that ultimately samples from USRP and Audio
> > sources are also probably caught in chunks and assembled into streams. But
> > the sources for them look too complex and spread out for me to look into
> > right now.
> >
> > I hope someone will make it clear for me and point me in a direction I can
> > look for a quick hack.
> >
> > Cheers,
> >
> > John
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

---

Keep your friends updated— even when you’re not signed in.