discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] strange problem with packet sink


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] strange problem with packet sink
Date: Sun, 15 Apr 2012 10:32:26 -0400

On Sun, Apr 15, 2012 at 10:29 AM, Josh Stevens
<address@hidden> wrote:
> Hey all,
>    The benchmark_rx.py file uses the generic_mod_demod.py and on the
> receiver side to be specific generic_demod whose input is
> gr.io_signature(1, 1, gr.sizeof_gr_complex), # Input signature    and the
> output signature is
> gr.io_signature(1, 1, gr.sizeof_char))       # Output signature .
> It also uses gr_framer_sink_1.cc which is for the basic benchmark purposes.
>    What i am currently working with is a modified packet structure at the
> transmitter side keeping the modulation- demodulation of the system intact
> but a slight modification in the way it is received. I placed a packet sink
> giving it the default_access_code , the msg_queue and the required threshold
> , but the problem comes in when the demodulation with a "CHAR" outpout
> signature is connected to a packet_sink whose signtaures are :
>     gr_make_io_signature (1, 1, sizeof(float)), #input signature
>     gr_make_io_signature (0, 0, 0)),               #output signature
>
> I didnt realise it at first when i did the usual self.connect(self
> ,self._demodulator , self._packet_sink) at the receiver side ,
> and i get a TypeError : Itemsize mismatch error . Is there another
> alternative to this or would i have to create another packet_sink according
> to my requirements ?
>
> Thanks,
> Joshua.


Yes, you will have to convert the types so they match properly. A sink
that's expecting floats won't know what to do with chars, anyways.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]