Hey Cy,
it's getting a bit late here in Germany¹, I'll try to come up with a test setup tomorrow;
haven't tried that feature (it being rather fresh).
Excellent debugging by the way; my first reaction was that, hm, if MAC address resolution
fails, the device might be trying to inadvisably stream out the wrong port, and then throw
errors… But you precluded that by specifying the MAC address. Just to verify, since that
is a supermicro built-in interface, is this 10 Gb/s ethernet? If it is, fine, otherwise,
my reproduction will aim for lower rates than 200 MS/s, and gigabit ethernet.
Regarding what might be going wrong on the host side of things: the actual error you're
seeing is thrown in lib/rfnoc/link_stream_manager.cpp; it checks capabilities that the
streamer controlling sfp1 really needs to have for this to work. Now the question becomes
whether it doesn't have these, or whether the self-diagnosis is wrong.
Best,
Marcus (the one of lesser wisdom)
¹ Just as Marcus Leech, I'm a contractor – I moonlight, but it's getting a bit too much
moon and to little light mentally for me tonight.
On 17.05.23 21:20, cjohnson . wrote:
Hi Marcus,
Okay, thanks for that information.
What should we try next?
Thanks,
--Cy
On Wednesday, May 17, 2023 at 12:05:39 PM PDT, Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
On 17/05/2023 14:49, cjohn...@serranosystems.com
<mailto:cjohn...@serranosystems.com> wrote:
Hi Marcus,
I am still interested to know how your team tests to verify the FPGA is sending the
data….meanwhile I did two quick experiments based on your suggestions.
I have no visibility into the details of the R&D teams testing apparatus, but I have
been told that this feature was tested
in the automated test jig they use. That's all I know.
I'm a (very) part-time contractor, and not an Ettus/NI R&D employee. So I'm singularly
unqualified to talk about the
test setup.
1) Same setup using the second interface I setup on the network card for the remote
port @192.168.30.30, “./remote_rx.py --rate=200e6 --freq=1223e6 --gain=20
--dest-addr=192.168.30.30 --dest-port=54321 --adapter=sfp1
--dest-mac-addr=3c:ec:ef:c2:43:47”.
Setup netcat -ul 54321 to listen to this port, and can be verified as listening (bottom
line):
|Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0
127.0.0.53:53
0.0.0.0:* udp 0 0 0.0.0.0:111 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0
0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:50237 0.0.0.0:* udp 0 0
0.0.0.0:54321 0.0.0.0:* |
Still no traffic to 192.168.30.30 (remote streaming dest), only control data between
USRP (192.168.30.2) and host (192.168.30.1) when sniffing.
2) Set the dest-addr to be the host (192.168.30.2), which I would think would be
equivalent to “normal streaming”. “./remote_rx.py --rate=200e6 --freq=1223e6 --gain=20
--dest-addr=192.168.30.2 --dest-port=54321 --adapter=sfp1
--dest-mac-addr=3c:ec:ef:c2:43:47”
Setup netcat -ul 54321 to listen to this port, and can be verified as listening (bottom
line):
|Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0
127.0.0.53:53
0.0.0.0:* udp 0 0 0.0.0.0:111 0.0.0.0:* udp 0 0 0.0.0.0:631 0.0.0.0:* udp 0 0
0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:50237 0.0.0.0:* udp 0 0
0.0.0.0:54321 0.0.0.0:* |
I don’t see any high speed IQ data going between 192.168.30.1 (host) and 192.168.30.2
(USRP), only the normal control trickle.
Thanks,
—Cy
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
<mailto:usrp-users@lists.ettus.com>
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
