[Top][All Lists]
[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