UHD support for USRP1

GNU Radio
1

Hello

Forgive me if the question has already been answered.

In the announcement made at 25/4-10, it was stated that support for
USRP1
was planned for a later point. May I ask what the anticipated timeframe
for
UHD support for the USRP1 is?

Kind regards

Jesper Kristensen
Aalborg University

2

Its rough to predict these things… but making an educated guess,
expect USRP1 support by the end of the month. Lets call it
beta-testing-state, it may only work on linux for the time being, some
more polish will be needed… something like that. :slight_smile:

-Josh

3

Hi Josh

Great, thanks.

Allow me to add a follow up question.

Say that I want to interface the USRP1 to Simulink using the UHD and
supporting timed TX samples. Would that be feasible with the anticipated
state of the USRP1 support?

Kind Regards

Jesper Kristensen

Message: 14
Date: Sun, 08 Aug 2010 11:14:25 -0700
From: Josh B. [email protected]
Subject: Re: [Discuss-gnuradio] UHD support for USRP1
To: [email protected]
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Its rough to predict these things… but making an educated guess,
expect USRP1 support by the end of the month. Lets call it
beta-testing-state, it may only work on linux for the time being, some
more polish will be needed… something like that. :slight_smile:

-Josh

On 08/08/2010 06:13 AM, Jesper Kristensen wrote:

Hello

Forgive me if the question has already been answered.

In the announcement made at 25/4-10, it was stated that support for USRP1
was planned for a later point. May I ask what the anticipated timeframe
for

4

On Mon, Aug 09, 2010 at 04:32:17PM -0700, Josh B. wrote:

Say that I want to interface the USRP1 to Simulink using the UHD and
supporting timed TX samples. Would that be feasible with the anticipated
state of the USRP1 support?

The USRP1 does not feature timed samples, and simulink support is
really up to the folks at simulink inc, unless you want to roll your
own driver.

For libusrp-based drivers, I’d like to remind you of
http://www.cel.kit.edu/downloads.php

Cheers
MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-3790
Fax: +49 721 608-6071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

5

Say that I want to interface the USRP1 to Simulink using the UHD and
supporting timed TX samples. Would that be feasible with the anticipated
state of the USRP1 support?

The USRP1 does not feature timed samples, and simulink support is really
up to the folks at simulink inc, unless you want to roll your own
driver.

-Josh

6

On 08/10/2010 01:49 AM, Sylvain M. wrote:

I was hoping that with the UHD api featuring timing control, that it
would become the default firmware.

The UHD will use the same images that gnuradio uses for fpga and
firmware because its known to work and there is source code for it. I am
not opposed to future enhancement once the basic features work. And I
hear there is some hobbyist interest in implementing a VRT like packet
structure and time control…

I dont know anything about the state of the ‘inband signalling’. It
works but its not stable? There is an fpga image but no source code?
Chime in if you know!

If there is an underflow during a RX capture, will the samples just be
missing (and therefore potentially desyncing the receiver) or have a
‘hole’ of zeroes of the correct length (it would be way better as a sync
at least would be preserved).

The USRP1 under uhd will behave like the gnuradio USRP1 driver. So
samples will just be missing and maybe an ‘O’ is printed.

If the packets had timestamps, it would be easy to integrate with the
uhd’s rx_metadata. :slight_smile:

-Josh

7

On 08/10/2010 01:32 AM, Josh B. wrote:

Say that I want to interface the USRP1 to Simulink using the UHD and
supporting timed TX samples. Would that be feasible with the anticipated
state of the USRP1 support?

The USRP1 does not feature timed samples,

Well, there is a firmware that does (the so called ‘inband signalling’
one, even tough it’s a misnomer).

I was hoping that with the UHD api featuring timing control, that it
would become the default firmware.

If there is an underflow during a RX capture, will the samples just be
missing (and therefore potentially desyncing the receiver) or have a
‘hole’ of zeroes of the correct length (it would be way better as a sync
at least would be preserved).

Cheers,

Sylvain
8

as far as I know, I was the last one to work on the “inband” firmware.
I used it extensively for a project I was working on and didn’t have
problems with it, but more testing would be warranted before considering
for the default firmware. (Which I would like to see)

After we get the USRP1 uhd support with the vanilla images, I think this
would be a worthwhile endeavor.

As to the rationale for not making it the default firmware, I’m not
sure. The only downside I can think of is a slight decrease in signal
bandwidth due to the packet header.

I think we are overstating the effect of the overhead. It may be fine,
and this would be an opportune time to test and break things. :slight_smile:

I was planning on doing some further revision to revamp the Tx / control
packet side logic (my work was a rewrite of the Rx side to ensure
accurate timestamps). At that time there was talk about putting a VRT
stack on the USRP1, which I am skeptical about. So I decided to just
wait.

Im not very concerned about VRT, but it would be nice because there is a
lot of shared code in UHD that uses vrt headers. What I really think we
need more than a specific packet format is timestamping consistent with
the USRP2 (seconds count and fractional seconds/ticks).

If there is interest in further development, I guess git hub or the like
is the place to put further development? (Or svn on cgran?)

yes. The firmware and fpga code is all in the uhd git repo. So we can
work something out with git.

-josh

9

Hi,

I dont know anything about the state of the ‘inband signalling’. It
works but its not stable? There is an fpga image but no source code?
Chime in if you know!

There is a inband project in the git fpga source.

It doesn’t build out of the box (but then then _std firmware either).
You need to convert the timing constraint to the new .sdc format and
then put back & fix includes for the fpga_regs_common.v &
fpga_regs_standard.v files that were never put in that directory.

Then it compiles and meets timing.

Didn’t check if it worked yet tough …

Sylvain
10

Josh,

as far as I know, I was the last one to work on the “inband” firmware.
I used it extensively for a project I was working on and didn’t have
problems with it, but more testing would be warranted before considering
for the default firmware. (Which I would like to see)

As to the rationale for not making it the default firmware, I’m not
sure. The only downside I can think of is a slight decrease in signal
bandwidth due to the packet header.

I was planning on doing some further revision to revamp the Tx / control
packet side logic (my work was a rewrite of the Rx side to ensure
accurate timestamps). At that time there was talk about putting a VRT
stack on the USRP1, which I am skeptical about. So I decided to just
wait.

If there is interest in further development, I guess git hub or the like
is the place to put further development? (Or svn on cgran?)

–Eric S.

11

Hi all

Thank you for your replies.

We are at Aalborg University using the Karlsruhe Simulink interface
together
with Simulink code supporting inband signalling on the FPGA. Our
interest
would be to code a new interface based on the UHD. We handle tx samples
by
embedding timestamps into packets send to the USRP as well as
de-embedding
timestamps in the RX direction.

If possible we would be most interested in gaing insight into the
concept of
metadata and how to use it in connection with inband signalling and the
UHD.
Any references to information are most welcome :slight_smile:

Our interest is to be able to easily move applications between USRP1&2
as we
have both platforms available.

Kind regards

Jesper Kristensen

Message: 13
Date: Tue, 10 Aug 2010 02:19:44 -0700
From: Josh B. [email protected]
Subject: Re: [Discuss-gnuradio] UHD support for USRP1
To: Sylvain M. [email protected]
Cc: [email protected]
Message-ID: [email protected]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 08/10/2010 01:49 AM, Sylvain M. wrote:

I was hoping that with the UHD api featuring timing control, that it
would become the default firmware.

The UHD will use the same images that gnuradio uses for fpga and
firmware because its known to work and there is source code for it. I am
not opposed to future enhancement once the basic features work. And I
hear there is some hobbyist interest in implementing a VRT like packet
structure and time control…

I dont know anything about the state of the ‘inband signalling’. It
works but its not stable? There is an fpga image but no source code?
Chime in if you know!

If there is an underflow during a RX capture, will the samples just be
missing (and therefore potentially desyncing the receiver) or have a
‘hole’ of zeroes of the correct length (it would be way better as a sync
at least would be preserved).

The USRP1 under uhd will behave like the gnuradio USRP1 driver. So
samples will just be missing and maybe an ‘O’ is printed.

If the packets had timestamps, it would be easy to integrate with the
uhd’s rx_metadata. :slight_smile:

-Josh