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 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 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 localhost is the way to go but this
>> works very unreliably here.
>>
>> For TRX1 I use (simple demo):
>>
>>    Signal Source (fs=5MHz, f=1MHz) --> Throttle (5MHz) --> UDP Sink
>> (127.0.0.1:1235)
>>                                                         |
>> \-----> |
>> | QT GUI Time Sink
>>                        UDP Source (127.0.0.1:1234) ------------> |
>>
>> For TRX2 I use (simple demo):
>>
>>    UDP Source (127.0.0.1:1235) --> Throttle (5MHz) --> MultiplyConst
>> (2) --> UDP Sink (127.0.0.1:1234)
>>
>>
>> I start TRX2 first and then TRX1. Initially this simple demo worked
>> well with default values (payload_size=1500-20, sendnullpkt=false)
>> but frequently I got the following error messages (from both TRX1 and
>> TRX2):
>>
>>    Too much data; dropping packet.
>>
>> This surprised me a lot because it's localhost which should be
>> insanely fast. I run USRP with 200 MSps (10Gbe) on the same machine
>> without a single packet drop!
>> Well, I checked the MTU of lo is not 1500 but 65536. Still baffled
>> how this can happen with a ridiculously low sampe_rate=5M, I set
>> payload_size=65516.
>> Now the error is largely gone. However, here and there I get a new
>> nasty error message:
>>
>>    ERROR: send error: send_to: Message too long
>>
>> This only seems to happen for TRX2.
>> After this error I have to restart both flowgraphs.
>> Unfortunately this only happens with more complicated stuff
>> implemented within TRX1/TRX2 and not reproducibly.
>>
>>
>> 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?
>>
>> Best,
>> Lukas
>>
>>
>>
>>
>