Hey Everyone,
I am sending a signal from one USRP to another USRP through a UDP
network. It seems to work but I am getting data loss as gnu-radio runs
the flow graph. Hopefully someone could help me with this problem?
P.S. I have the sender side (RecieveStation.jpg) and the
Reciever/Display side (RecieveDisplay.jpg) attached
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Funny that I was doing the exact same thing last night, and I’m also
getting
warnings on the receive end at only 500 ksps on a home LAN.
Should the stream be vectorized before the UDP sink, and if so how long?
I
tried both stream and vectors but still get the warnings.
Lou
KD4HSO
Ward, Marcus D. wrote
Hey Everyone,
I am sending a signal from one USRP to another USRP through a UDP network.
It seems to work but I am getting data loss as gnu-radio runs the flow
graph. Hopefully someone could help me with this problem?P.S. I have the sender side (RecieveStation.jpg) and the Reciever/Display
side (RecieveDisplay.jpg) attached
–
View this message in context:
http://gnuradio.4.n7.nabble.com/Why-am-I-dropping-data-over-the-UDP-network-tp49283p49286.html
Sent from the GnuRadio mailing list archive at Nabble.com.
If I change the type to complex integer 16, you think I’ll have a better
outcome? Seeing as if there is a way to change the type to complex 16,
but I will have to incorporate converters.
From: Marcus L. [mailto:[email protected]]
Sent: Friday, July 11, 2014 1:38 PM
To: Ward, Marcus D.
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Why am I dropping data over the UDP
network?
Also, you’re sending data at 6.25Msps, with complex-float samples, which
chews up:
6.25e6 x 8 bytes/second
= 400Mbit/second, without accounting for headers and other overhead.
You might want to re-think your architecture, if you’re going to be
sending this data over the network.
on Jul 11, 2014, Ward, Marcus D.
<[email protected]mailto:[email protected]> wrote:
Hey Everyone,
I am sending a signal from one USRP to another USRP through a UDP
network. It seems to work but I am getting data loss as gnu-radio runs
the flow graph. Hopefully someone could help me with this problem?
P.S. I have the sender side (RecieveStation.jpg) and the
Reciever/Display side (RecieveDisplay.jpg) attached
The UDP sink doesn’t support complex int 16, so what would I be able to
change the type to in order to come to a close solution for this
problem?
Also, I have lowered the sample rate to very small amounts such as 1e6,
but I still lose packages on the receiving end. There is a 1-gigabit
switch between the two USRP’s, so it is a very simple network. I don’t
think the network is the problem.
I forgot to add that the 1e6 data rate was going to a null sink.
The data rate is only 1Mhz * 4bytes * 2 channels = 8M bytes per second
to a null sink, which should be fine. Does anyone have any suggestions
as to what settings I should have in my UDP source block in terms of
payload size, buffer size, etc.?
Thanks,
Marcus
No, building vectors out of streams would (in the best case) change
nothing, as you don’t send individual samples but always packets full of
payloads.
Also, if you have a hardware device defining your data rate, you will
never need a throttle, and having one will most likely only introduce
problems, so remove it from your flowgraph. All throttle really does is
trying to achieve a given average sample processing rate, and that
interferes with the hardware constantly providing a sample rate.
A few numbers in my head: 500ksps = 500 * 32kbps = 16000kbps, not very
much for a gigabit ethernet! So I think it’s safe to assume that the
physical network is not to blame here, and usually the CPU load, maybe
introduced by network handling might be to blame, if this doesn’t happen
with a null sink.
Greetings,
Marcus
Hi Marcus,
On 14.07.2014 22:01, Ward, Marcus D. wrote:
The UDP sink doesn’t support complex int 16, so what would I be able to change
the type to in order to come to a close solution for this problem?
It should, using the datatype “short”.Also, I have lowered the sample rate to very small amounts such as 1e6, but I
still lose packages on the receiving end. There is a 1-gigabit switch between the
two USRP’s, so it is a very simple network. I don’t think the network is the
problem.
I tend to agree, but dropped data indicates that either end (presumably
the receiving one) is having trouble getting the data out of the UDP
source fast enough.
Ok so now I went to try out my architecture this time with a TCP source
and sink. I have pictures included where the sending side is
(TCPrecievestation) and the receiving side is
(TCPreceivedisplaystation).
On the (TCPreceievestation), the last three lines in the bottom window
is as follows:
RuntimeError: LookupError: KeyError: No devices found for -------->
Device Address:
Addr: (My USRP’s IP address)
On the (TCPreceievedisplaystation), all I am getting is this:
using volk machine: avx_64_mmx_orc
To add, I have scopes for both the sending and receiving end, but as I
run them, the plots do not show.
Is there something that I could be missing since I am dealing with TCP
and not UDP?
On the machine that has the USRP connected (presumable this is a N2xx
or USRP2?), what does:
ping 192.168.10.2
return?
Ping 192.168.10.2 is returning data
what does uhd_usrp_probe --args “addr=192.168.10.2”
Return?
This returns an error message:
RuntimeError: LookupError: KeyError: No devices found for -------->
Device Address:
Addr: (192.168.10.2)
On 07/15/2014 01:21 PM, Ward, Marcus D. wrote:
To add, I have scopes for both the sending and receiving end, but as I run them,
the plots do not show.Is there something that I could be missing since I am dealing with TCP and not
UDP?
One thing I noticed immediately is that you have the sample rate set to
32k, which is not a valid sample rate for ANY USRP hardware.
On the machine that has the USRP connected (presumable this is a N2xx
or USRP2?), what does:
ping 192.168.10.2
return?
what does uhd_usrp_probe --args “addr=192.168.10.2”
Return?
On 07/15/2014 01:57 PM, Ward, Marcus D. wrote:
Return?
This returns an error message:
RuntimeError: LookupError: KeyError: No devices found for -------->Device Address:
Addr: (192.168.10.2)
And the firmware in the device matches the UHD you have?
Assuming that there’s nothing else on the network connection between
the host computer and the USRP device, that’s the only thing I can think
of that might cause it to be pingable, but UHD can’t communicate with
it, unless you have firewall rules preventing communications at the
UHD layer…
On 07/15/2014 02:58 PM, Ward, Marcus D. wrote:
And the firmware in the device matches the UHD you have? Based on my structure,
the firmware should be matching (since when I did the flow graph with the UDP,
everything went fine except for data loss) and correct me if I’m wrong, but an
error would come on saying that the firmware is not compatible?
A very-old firmware/FPGA image with a modern UHD may yield a “I can’t
find the device” error, such as you’ve seen.
I don’t think it’s a firewall rule problem, but do you think opening up
ports would solve my problem? I know the port I’m currently using on the
TCP connection is port#: 1234 which deals with Mercurial and git default
ports for serving Hyper Text.
When I had the UDP connection, I was using the same port (1234) except
that in UDP, that port deals with a VLC media player.
Marcus,
What OS are you using? I had the same issue (UDP not getting through on
receive side) with Fedora 20, even with Firewall “supposedly” turned off
(i.e. Trusted Zone selected). Manually adding the port exemption (I
believe
I used port 65000) let the UDP through and it worked.
Lou
KD4HSO
Ward, Marcus D. wrote
I don’t think it’s a firewall rule problem, but do you think opening up
ports would solve my problem? I know the port I’m currently using on the
TCP connection is port#: 1234 which deals with Mercurial and git default
ports for serving Hyper Text.When I had the UDP connection, I was using the same port (1234) except
that in UDP, that port deals with a VLC media player.
–
View this message in context:
http://gnuradio.4.n7.nabble.com/Why-am-I-dropping-data-over-the-UDP-network-tp49283p49387.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
And the firmware in the device matches the UHD you have? Based on my
structure, the firmware should be matching (since when I did the flow
graph with the UDP, everything went fine except for data loss) and
correct me if I’m wrong, but an error would come on saying that the
firmware is not compatible?
Assuming that there’s nothing else on the network connection between
the host computer and the USRP device, that’s the only thing I can think
of that might cause it to be pingable, but UHD can’t communicate with
it, unless you have firewall rules preventing communications at the
UHD layer…
I’ll dig into it more to see what else I can come up with.
Thank You,
Marcus
Take a look at netstat -s and see if that helps isolate if or
where packet loss is occurring. For example in the udp: section there
are statistics for total datagrams tx/rx along with dropped, bad
checksums, etc.
UDP has no retransmission feature built in
so bad checksums and bad packets get dropped. Any sort of retransmission
of dropped packets must be in the software.
[Brad H.]
It is my understanding that the UDP protocol does not quarentee delivery
to the destination. That is, it has no recovery mechanism for
undelivered packets.
Alan
From: discuss-gnuradio-bounces+alan.r.hill=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+alan.r.hill=removed_email_address@domain.invalid] On
Behalf Of Marcus L.
Sent: Wednesday, July 16, 2014 11:09 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] Why am I dropping data over the UDP
network?
I’m talking about the UDP traffic between the host and the N2xx device.
on Jul 16, 2014, madengr [email protected] wrote:
Marcus,
What OS are you using? I had the same issue (UDP not getting through on
receive side) with Fedora 20, even with Firewall “supposedly” turned off
(i.e. Trusted Zone selected). Manually adding the port exemption (I
believe
I used port 65000) let the UDP through and it worked.
Lou
KD4HSO
Ward, Marcus D. wrote
I don’t think it’s a firewall rule problem, but do you think opening up
ports would solve my problem? I know the port I’m currently using on the
TCP connection is port#: 1234 which deals with Mercurial and git default
ports for serving Hyper Text.When I had the UDP connection, I was using the same port (1234) except
that in UDP, that port deals with a VLC media player.
–
View this message in context:
http://gnuradio.4.n7.nabble.com/Why-am-I-dropping-data-over-the-UDP-network-tp49283p49387.html
Sent from the GnuRadio mailing list archive at Nabble.com.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs