> And i still read in the thread <Suitable Sink required> something > about <gr.message_sink and gr.msg_queues>. > Both are written in c++, not python, further on <gr.message_sink> > is a sink and can not connected to another sink. > Is the gr.msg_queues a sink and source ?
message_sink, message_source, and msg_queues operate hand in hand to create a procedure for transferring your packets (arrays in python) into the streams used in gnuradio modulation blocks. Basically, when you call the function (instance of: blks2.mod_pkts).send_pkt(payload, eof), it creates the packet with the necessary headers and footers then places into the message queue. The modulator is then connected to an instance of gr.message_source to read the packets from the queue, serialized them and stream them to the modulator. The setup for message_source is the opposite of this. I would have a look at 'blks2impl/pkt.py' for more information. >From your questions on the board I'm starting to wonder if your application isn't complex enough that it would warrant being built in strict python rather than GRC, it would certainly make your life easier in terms of doing things like this: > i want to save my incoming values of peaks to a file, but with > the depending date. The file should also limited to size X or > to a number of samples. Jason _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
