Re: [EXTERNAL] Re: Complex Integer16 type conversion

2025-02-20 Thread GNU Radio, the Free & Open-Source Toolkit for Software Radio
Your comment is noted but moot at this point because a new issue has grabbed my attention. I will get a test working properly with std::complex and only then will I explore new territory. Rick On 2025-02-20 15:30, Jim Melton wrote: > I don't know if you are working in C++ or Python, but I mig

RE: [EXTERNAL] Re: Complex Integer16 type conversion

2025-02-20 Thread Jim Melton
I don't know if you are working in C++ or Python, but I might point out that std::complex is likely Undefined Behavior. Sure, it's attractive, but you deserve what you get when you tread in UB territory. Your best bet is to convert your std::pair into std::complex and be done with it. --- Jim

Re: Complex Integer16 type conversion

2025-02-20 Thread GNU Radio, the Free & Open-Source Toolkit for Software Radio
I was hoping for a simple work around of this type; thank you. Your suggestion looks promising but this block throws out an error message even within a very simple configuration using Complex Float data as the input type. I'll try the integer data when this current bug is fixed. Rick On 2025

Re: New OOT module gr-dl5eu

2025-02-20 Thread Ralf Gorholt
Hi Federico, thank you very much for the hint and the link. I have not looked at cour code yet but I will do that. What you describe is the reason why I had added TPP_DONT to my copy of GNU Radio's Viterbi Decoder. Unfortunately, when I do this (and only this), if I remember correctly only the f

Re: Complex Integer16 type conversion

2025-02-20 Thread Martin Braun
Try a stream-to-vector and make the output a vector length of 2. Then feed that into your other block. The runtime checks the item size, not the literal types IIRC. --M On Thu, Feb 20, 2025 at 2:03 AM aardric via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote: > Since 3.10.1

Re: New OOT module gr-dl5eu

2025-02-20 Thread Federico 'Larroca' La Rocca
Hi Ralf, Since the Viterbi Decoder has to wait for a tag to start (and is thus a general block), I've used TPP_DONT as its tag propagation policy. Furthermore, we also send a tag whenever a new frame begins under "normal operation" (see https://github.com/git-artes/gr-isdbt/blob/56b2556c14ecc5d710

Re: Complex Integer16 type conversion

2025-02-20 Thread GNU Radio, the Free & Open-Source Toolkit for Software Radio
Marcus, Thanks. Unfortunately, GRC connection is invalid (red) when connecting IShort to IComplex16. The easiest to do at this time is change the block property IComplex16 to Complex Float 32; of course IShort to Complex works as before. I am interested in comparing the speed between using Com

Re: Complex Integer16 type conversion

2025-02-20 Thread Marcus Müller
Hi Rick, the "Complex to IShort" and "IShort to Complex" blocks should fulfill that purpose. Best, Marcus On 2/20/25 1:51 AM, aardric via GNU Radio, the Free & Open-Source Toolkit for Software Radio wrote: Since 3.10.12.0-rc1 does not have a type converter from Integer 16 Re-Im pairs to Com

USRP channel frequency change from serial port data

2025-02-20 Thread Muhammad Anas
Dear Community, I want to control the channel frequency in the RF options in the USRP sink block on GNU Radio Companion from the float data coming from serial port through a custom python block and the data coming is showing in the GRC environment in bar sink as float values and I am trying to sav

Re: New OOT module gr-dl5eu

2025-02-20 Thread Ralf Gorholt
Hi Federico, I can imagine that you are very busy, so don't worry :-) In most cases reception is fine. However, I have noticed difficulties (already in the past) that are not related to the recognition of the OFDM symbols. It might be that I have now found the reason why but I don't know GNU Rad