Right! and that's the same type I'm using as input, so that is not really
the problem.
Actually, one time I got lucky and acquired a nice looking signal with my
implementation. But that only happened once, so I'm thinking there must be
a way to solve this issue, I just don't know how.
Best regards,
Verónica
On Fri, Nov 26, 2021 at 12:40 AM Marcus Müller <muel...@kit.edu> wrote:
> Hi,
>
> pretty sure that thing actually emits complex64/gr_complex/fc32.
>
> Best regards,
> Marcus
>
> On 25.11.21 19:58, Verónica Toro Betancur wrote:
> > Hi Marcus,
> >
> > Thanks for the explanation.
> > In fact, the block I'm having trouble with is self.iio_pluto_source_0_0,
> which is defined as
> >
> > pluto_source_impl::pluto_source_impl(fmcomms2_source::sptr block) :
> > hier_block2("pluto_source",
> > io_signature::make(0, 0, 0),
> > io_signature::make(1, 1, sizeof(gr_complex))),
> > fmcomms2_source_f32c(true, false, block)
> >
> > As far as I understand, the variable type of the output here is
> gr_complex, which in
> > Python corresponds to numpy.complex64. So, in that sense, I think my
> input variable type
> > is correct, otherwise, I would probably get an error. But, I'd like to
> know if the output
> > variable in pluto_source_impl is fixpoint and, in that case, how do I
> define my input
> > variable in Python to match the fixpoint type?
> >
> > Thanks in advance.
> >
> >
> > - Verónica
> >
> > On Thu, Nov 25, 2021 at 7:49 PM Marcus Müller <marcus.muel...@ettus.com
> > <mailto:marcus.muel...@ettus.com>> wrote:
> >
> > Hi Verónica,
> >
> > in your long/short_sync_block's __init__, you set the in_sig to
> [np.complex64], which is
> > of a complex number composed of two 32 bit floats.
> >
> > You can change that to other types!
> >
> > But: your wifi_phy block outputs something specific, it needs to
> match that.
> >
> > Best regards,
> >
> > Marcus
> >
> > On 25.11.21 17:47, Verónica Toro Betancur wrote:
> > > Hi Martin,
> > >
> > > Yes, that could definitely be the case. I don't have my radios
> right now with me, but
> > > I'll try it tomorrow. And sorry for the silly question, but how
> should I define it in
> > > Python to be fixpoint?
> > >
> > > On Thu, Nov 25, 2021 at 6:25 PM Martin Braun <
> martin.br...@ettus.com
> > <mailto:martin.br...@ettus.com>> wrote:
> > >
> > > Verónica,
> > >
> > > have you maybe mismatched data types? Like, the real signals
> are fixpoint, but your
> > > Python is doing floating point?
> > >
> > > --M
> > >
> > > On Thu, Nov 25, 2021 at 2:59 PM Verónica Toro Betancur <
> vetor...@gmail.com
> > <mailto:vetor...@gmail.com>> wrote:
> > >
> > > Hi,
> > >
> > > I am trying to detect and decode WiFi and ZigBee signals
> in GNURadio. For the
> > > detection, I have implemented my own blocks in Python. It
> all works well with
> > > simulated signals but the problem comes when I use radios
> to acquire real
> > > signals. I'm using Pluto SDR and it works perfectly when
> I use it in workflow
> > > examples but not in my own implementation. I mean, I plot
> the data that comes
> > > directly from the radio and it looks good in the given
> examples but, in
> > mine, it
> > > looks like noise.
> > >
> > > I am using the exact same parameters in both cases. The
> only difference I
> > see is
> > > that the blocks in the example are all in C++ while mine
> are in Python. Could
> > > this be the problem? If so, is there a way to solve it
> other than writing the
> > > blocks in C++?
> > >
> > > Thanks in advance.
> > >
> > >
> > > Best regards,
> > > Verónica
> > >
> >
>
