There has been much work in the past few months to get the VITA Radio
Transport (VRT) protocol working with the USRP2. You can read more about
the protocol here: http://www.digitalif.org/
These changes will break the current usrp2 api. If you are just using
the gr-usrp blocks in your python apps, there should be no difference.
However, users making C++ calls to the usrp2 should expect to see some
changes:
The channel numbers and metadata for the transmit and receive methods
have been replaced with the vrt::expanded header. Documentation for this
can be found in vrt/include/vrt/expanded_header.h Examples of how to use
the expanded header w/ api can be found in the usrp2/apps directory.
This new api should give users greater control over timestamped data. We
apologize for breaking the api, but this is an important step in the
right direction.
Note: The usrp2 is still using raw ethernet frames. Hence, the vita
packets are going over raw ethernet. udp support for the usrp2 is coming
soon.
It would be greatly appreciated if usrp2 users out there would try out
the branch and send us your bug reports and feedback. The usrp2 vita
code should be merged into the mainline within a few weeks, and your
feedback will help us greatly.
To use this branch with the usrp2, users must burn new firmware and fpga
images to their usrps2’s sd card. The images can be found here: http://www.ettus.com/usrp2_vrt
There has been much work in the past few months to get the VITA Radio
Transport (VRT) protocol working with the USRP2. You can read more about
the protocol here: http://www.digitalif.org/
Hmmm, not sure if it’s due to a git-related mistake on my end, but I’m
getting compilation errors - it looks like the vrt-related headers
aren’t getting the right -I line in the Makefile somehow
error: vrt/rx_packet_handler.h: No such file or directory
Looks like the $(VRT_INCLUDES) didn’t make it into the
usrp2/apps/Makefile.am line for AM_CPPFLAGS?
usrp2/lib/Makefile.am has it though, and built correctly.
Hmmm, looks like it might need to be in gr-usrp2/src/Makefile.am as
well.
That built at least - I’ll report back once I update the SD cards and
can do some tests with them. Diff attached below:
Along with the vrt changes, the raw ethernet protocol number has been
changed for the control packets. You must run the matching host code and
the firmware from the branch or it wont work. The firmware and fpga
files on that link were also built and tested from this branch.
Can you run wireshark and see what packets go in and out when you run
find_usrps? You should see a broadcast packet going out and a packet
coming back from the usrp2. The 2 byte transport type should read BEFO
in hex.
-Josh
Tim P. wrote:
try that and try connecting with a TTL cable attached to the debug port
tomorrow unless anyone else has a similar problem/ideas?
It should print out the standard booting verbose over the serial
terminal. This will make sure that at least the usrp2 microblaze is
booting.
I’ve just run find_usrps -e eth1 with wireshark running and can only see
the
outgoing packet:
1 0.000000 Toshiba_b4:52:54 Broadcast 0xbeef Ethernet II
Given the transport type is the old (I think) 0xbeef I guess this is
wrong,
I’m just about to recheckout the source code and compile again, but
“vrt” is
a directory present in where I compiled gnuradio from - I’ve just double
checked by:
make uninstall
check /usr/lib/python2.6/dist-packages/gnuradio/ doesnt exist/have
anything
in it (fresh install of ubuntu so I’ve only tried to compile this
version on
it too, there shouldnt be any non /usr prefix locations)
make clean
./configure --prefix=/usr (result = Configured GNU Radio release
3.3git-75429993 for build.)
make
sudo make install
sudo chmod +s /usr/bin/usrp2_socket_opener
find_usrps -e eth1 (I’ve tried running the non make installed compiled
versions in usrp2/host/apps with the same result)
and I still see the old transport type on the outgoing message (which
would
explain why it still worked when I used an older firmware version I
guess?)
Annoyingly I don’t have a TTL cable at home but will double check I get
the
standard verbose whilst booting tomorrow.
Given the transport type is the old (I think) 0xbeef I guess this is wrong,
I’m just about to recheckout the source code and compile again, but “vrt” is
a directory present in where I compiled gnuradio from - I’ve just double
checked by:
The vrt directory was there prior to this work. A good way to verify
that you pulled in the right branch would be to check
usrp2/firmware/include/usrp2_eth_packet.h and see that it has the
following defines:
#define U2_DATA_ETHERTYPE 0xBEEF // used in our data frames #define U2_CTRL_ETHERTYPE 0xBEF0 // used in our control frames
Thats where the firmware and host code gets the ethernet transport type
from.
Looking through the header files this looks really useful, thanks for
the
hard work guys
I’m having some problems getting it to work though, I’ve downloaded the
firmware/fpga builds from the link and with these running
python/find_usrps
isnt able to find the usrp2 - its fine with the latest non-vrt firmware.
The
leds flash and then the bottom right 2 leds come on. I’ve had a quick
look
and I think find_usrps/usrp2.source_32fc should still work.
I haven’t tried using firmware compiled from the git repository yet so
I’ll
try that and try connecting with a TTL cable attached to the debug port
tomorrow unless anyone else has a similar problem/ideas?
(Unfortunately I’ve only got access to the latest Xilinx ISE which I
understand (as ever) breaks compatability with fpga code written for
previous versions. I havent had much luck synthesising with it so far
anyway, although I’ve only really done a quick try so far – so I cant
try
making my own fpga file as well)
