Re: RF signals are pure noise in Python implementation

[Verónica Toro Betancur]

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 <mueller@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.mueller@ettus.com
> <mailto:marcus.mueller@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.braun@ettus.com
>     <mailto:martin.braun@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 <vetorobe@gmail.com
>     <mailto:vetorobe@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
>      >
>