I would need to communicate two separated gnuradio programs. I tried to
use udp_sink / udp_source in the same machine but there are many many
packets lost. Is there a way to use a kind of sink/source without losses
to communicate separated programs in Windows?
I also tried to use a tcp stack to obtain a fileno and then use
file_descriptor_source/sink but in windows is not possible to use
read/write on a socket descriptor (you can only use recv/send). So I
need to find another solution but I don’t know how to solve it.
Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
need to find another solution but I don’t know how to solve it.
Thanks for your help.
–
Pol H.
Pol,
What kind of packet losses are you seeing? It shouldn’t be that high,
but UDP gives you no guarantee that packets won’t be dropped or even
show up in order. Still, for loopback, I would expect less than 1%
packet loss rate (I think that I’m being overly pessimistic, but I’ve
heard reports for more), so I’m more just curious what kind of
performance you’re seeing on Windows.
You could try to recreate the UDP source/sink as TCP, instead. But if
you have the same kinds of losses, just know that with the
retransmissions, you’re going to have to slow things down.
If you were on Linux, I’d suggest using FIFOs on a RAM disk, but I’m
not sure you can do that in Windows.
I also tried to use a tcp stack to obtain a fileno and then use
file_descriptor_source/sink but in windows is not possible to use
read/write on a socket descriptor (you can only use recv/send). So I
need to find another solution but I don’t know how to solve it.
if it helps, there is a tcp socket block in GrExtras. Using blob to/from
socket with blob to/from stream might do the trick for you
Even though the loses are low, I would like to do not lose any sample. I
implemented a sink/source block using shared memory and I can guarantee
that there are no loses.
However I discovered a deeper problem. There is a strange behaviour with
hier_block2. I test the following topoly:
A → B → C → D, where B and C are sink/source blocks (using shared
memory or udp, it does not matter, they are basic blocks). A and D are a
CRC encoder and decoder but in a hier_block2. In more detail, in A there
are the following connections:
Data_Generator → CRC_attacher → self
D is the reciprocal block. CRC_attacher is also a hier_block2 in the
following way:
self → CRC_compute → self
Hence, I use a hier_block2 inside another one. Yes, I know I could use
CRC_compute without being encapsulated in the hier_block2 but in the
future will be additional blocks.
With this topology there are CRC fails. If I use CRC_compute without
hier_block2 all CRC decodings are ok. So it seems there is a rare
problem with hier_block2.
I read a similar problem in http://lists.gnu.org/archive/html/discuss-gnuradio/2009-04/msg00061.html
and therefore I put a kludge_copy after/before self connections. But the
problem still occurs.
Centre Tecnolgic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 30/07/2012 13:44, Tom R. escribi:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.