Re: Reliable "virtual RF channel" between two grc applications (UDP Source/Sink?)

Hi, Derek Kozel wrote: > For an example of that check out the Simulation tutorial. > https://wiki.gnuradio.org/index.php/Simulation_example:_AM_transmitter_and_receiver On 22/04/2020 19:08, Marcus Müller wrote: > Use zeromq; that should do just fine, and if the default TCP transport feels > like

Time synchronization for small burst of PAM-2/NRZ bits

Hi, I am receiving just a few bits at a time over a radio link and I need to time align them due to phase mismatch. Let me briefly discuss what I mean: https://snipboard.io/8vUgdM.jpg This plot shows the bits I am receiving (blue) triggered on the incoming bits (10100110011101). The red line s

Re: Reliable "virtual RF channel" between two grc applications (UDP Source/Sink?)

On Wed, Apr 22, 2020 at 10:48 AM Lukas Haase wrote: > > Has anyone done something like this before and has a recommendation for a > reliable setup? > Is UDP Source/Sink over localhost even the best way to go? > If you just want to connect two local processes, you could try using mkfifo

Re: Reliable "virtual RF channel" between two grc applications (UDP Source/Sink?)

For an example of that check out the Simulation tutorial. https://wiki.gnuradio.org/index.php/Simulation_example:_AM_transmitter_and_receiver On 22/04/2020 19:08, Marcus Müller wrote: Use zeromq; that should do just fine, and if the default TCP transport feels like too much overhead, you can try

Re: Reliable "virtual RF channel" between two grc applications (UDP Source/Sink?)

Use zeromq; that should do just fine, and if the default TCP transport feels like too much overhead, you can try the ipc:// transport, iirc. Best regards, Marcus On 22/04/2020 19.40, Lukas Haase wrote: Hi, Before going to hardware (and since my HW access is limited in Corona times) I want to

Reliable "virtual RF channel" between two grc applications (UDP Source/Sink?)

Hi, Before going to hardware (and since my HW access is limited in Corona times) I want to build my "TRX1" with a behavioral model of "TRX2" (TRX2 will eventually be a simple hardware TRX on PCB, TRX1 a more signal processing heavy gnuradio application). I thought UDP Source/Sink over localhos

Re: Output variables - Python Block

Thank you very much, Derek! =) Best regards Artur Em qua., 22 de abr. de 2020 às 05:55, Derek Kozel escreveu: > Hi Artur, > > Yes, the Python Block follows the same API as other blocks so the > input/output signatures can be defined as a list. > > in_sig = [np.complex64, np.float32, np.float32]

Re: Output variables - Python Block

Hi Artur, Yes, the Python Block follows the same API as other blocks so the input/output signatures can be defined as a list. in_sig = [np.complex64, np.float32, np.float32] On 22/04/2020 04:09, Artur Nogueira wrote: Hi all, Is it possible to make the 'work' function from the Python Block t