Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: UHD protocol specifications (Giulio Mazzoleni)
2. Re: 1/f shaped noise floor on SBX - is this a normal feature?
(Rickard Radio)
3. Re: UHD protocol specifications (Ian Buckley)
4. Re: 1/f shaped noise floor on SBX - is this a normal feature?
(Marcus Leech)
5. Re: Sample OTW Format (Josh Blum)
6. Re: Sample OTW Format (Marcus Leech)
7. Re: UHD protocol specifications (Josh Blum)
8. Re: 1/f shaped noise floor on SBX - is this a normal feature?
(Rickard)
9. Re: UHD protocol specifications (Robert Watson)
10. Re: UHD protocol specifications (Giulio Mazzoleni)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 May 2013 18:01:42 +0200
From: Giulio Mazzoleni <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD protocol specifications
Message-ID: <[email protected]>
Content-Type: text/plain
Thank you Matt for your clarifications.
That seems reasonable.
For my current testing I think that going with a standard UDP stream may
be sufficient.
Thank you for answering.
Best regards,
Giulio
On Thu, 2013-05-30 at 08:55 -0700, Matt Ettus wrote:
>
> Giulio,
>
>
> The protocol itself is only documented through the code. It is in
> rapid development, and any documentation would quickly become out of
> sync with the code.
>
>
> The use of UHD with Matlab is governed by a separate license agreement
> between Ettus Research and The Mathworks. Use of UHD with Simulink
> (or Matlab or any other proprietary program) with radio hardware other
> than Ettus Research hardware would be a direct violation of that
> license. If you would like to discuss this further, please contact me
> off list.
>
>
> Matt Ettus
> President, Ettus Research LLC
>
>
>
>
> On Thu, May 30, 2013 at 1:58 AM, Giulio Mazzoleni
> <[email protected]> wrote:
> Dear USRP users,
> I am new to this mailing list, so greetings to everyone.
>
> I was looking at SDR support for GNU radio and Simulink and
> seems that
> USRP2/UHD is the most widely used and supported.
>
> I've been experimenting with the UHD driver in the last few
> days since I
> would like to create a compatible UHD endpoint (at least for a
> minor
> subset of functions, mostly related to rx and tx).
>
> I took a look at the driver implementation and at the host
> code, even if
> it seems a bit complex to understand at first and could
> accomplish some
> basic single channel transfers in gnu radio.
>
> The real problem is that the PC driver is doing many error
> checking
> based on data coming from I2C and FPGA registers and the data
> flow is
> somewhat difficult to follow in case of errors.
>
> Is there any formal specification of the UHD protocol? Or the
> source
> code is the only real source of information publicly
> available, as I
> guess?
>
> I see that this very question has alreaduy been posted in the
> past
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-March/003871.html
> but got no answer at that time.
>
> Thank you very much for any suggestion you could think of and
> best
> regards,
> Giulio
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 2
Date: Thu, 30 May 2013 18:06:14 +0200
From: Rickard Radio <[email protected]>
To: Marcus Leech <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] 1/f shaped noise floor on SBX - is this a
normal feature?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Works great - it was easy to move the annoying 1/f noise out of my passband!
However, I still have a fairly high DC offset left - a strong spike exactly at
zero digital freq (almost 20 dB above the noise floor).
https://www.dropbox.com/s/1lfhvr73405zvht/UHD_lo-offset.png
This DC-offset peak stays independent of the chosen offset tuning (lo_off) and
center frequency, bandwidth, etc.
Where does this come from and it is somehow possible to get rid of? (Not
that it seem to hurt as much as the 1/f noise)
Using the UHD calibrated values, or not, does not result in any difference.
Why?
Rickard
On May 29, 2013, at 7:06 PM, Marcus Leech <[email protected]> wrote:
> Yes, the lo_off parameter basically tells UHD to program the analog hardware
> for an offset (by lo_off) tuned frequency, and then the DDC in the FPGA
> downconverts so that your desired center frequency is still at DC in the
> digital sample stream, but the *analog* DC is offset (usually to somewhere
> outside your passband). This is conceptually very similar to a normla
> superhet approach with an actual real IF, rather than a zero IF.
>
> I encourage you to try it. Make your lo_off be half your passband
> bandwidth, which will place "analog DC" at the edge of your passband.
>
> on May 29, 2013, Rickard Radio <[email protected]> wrote:
> All I can get, i.e. 25 MHz 16 bit or 50 MHz 8 bit.
>
> I am not sure what you mean. Do you mean that with a certain wanted analog
> carrier (center) frequency, fc, which is what I normally use but then also
> with this "offset tuning", I still receive/transmit the whole bandwidth
> centered around fc in RF (analog domain in the air) but have just
> (circularly) shifted the whole spectrum after sampling in the digital domain
> which I can then just undo in digital domain by the DDC with the uhd? Or
> maybe I got this totally wrong?
>
> Is "offset tuning" equivalent to the "lo_off" parameter to use with the
> "uhd.tune_request(fc, lo_off)" ?
> I never really understood that parameter until perhaps now? I will try that
> tomorrow!
>
> On May 29, 2013, at 6:39 PM, Marcus Leech <[email protected]> wrote:
>
>> How much bandwidth are you using?
>>
>> With offset tuning, your desired center frequency is still slap-dab in the
>> middle, but UHD has arranged to tune the analog hardware differently, and
>> then use the DDC to move DC to somewhere else, and still have your desired
>> Fc exactly where you want it.
>>
>> on May 29, 2013, Rickard Radio <[email protected]> wrote:
>> OK, thanks! However, I want to utilize all the bandwidth I can get so the
>> passband need to stay in the centre. As a consequence then also the 1/f
>> noise peak has a relatively small total power, except when the received
>> signal is very weak which leads me to another related question I have...
>>
>> On May 29, 2013, at 6:26 PM, Marcus Leech <[email protected]> wrote:
>>
>>> The SBX is a direct-conversion receiver, so you'll see some 1/f noise. You
>>> can use offset tuning to move DC out of your passband, and as a happy
>>> consequence, move the 1/f noise out of your passband as well.
>>>
>>>
>>>
>>> on May 29, 2013, Rickard Radio <[email protected]> wrote:
>>> Hi USRP users,
>>>
>>> I have a (rather strong ?) 1/f shaped noise floor with the SBX
>>> daughterboards (rev 4 I think, acquired end of 2012).
>>> Running the uhd-calibration utilities does not give any visible difference,
>>> see links to pics below.
>>> As a comparison, the noise floor on the RFX2400 db is rather flat. Maybe
>>> generally a little higher but without the strong 1/f peak.
>>>
>>> Q1: Is this a normal and expected (1/f colored) noise floor with the SBX
>>> db?
>>> If I pump up the uhd gain (>0 dB) the 1/f shaped noise floor remains and
>>> gets amplified correspondingly.
>>> I know 1/f noise is a common notorious feature in electronics so perhaps it
>>> is included with the SBX too.
>>>
>>> Q2: Should I see (or not) a visible improvement with the uhd-calibration
>>> enabled (i.e., with the calibration values in .uhd/cal/) ?
>>> With the calibration enabled the gr-application tells me that the
>>> appropriate cal values are "loaded", which sounds reassuring? but maybe I
>>> do something wrong.
>>>
>>> Link to picture of PSD without calibration:
>>> https://www.dropbox.com/s/vl7x8c8i7qn3ueh/UHD_uncalibrated_SBX.png
>>>
>>> Link to picture of PSD with calibration (its identical to my eyes):
>>> https://www.dropbox.com/s/ngc98l71ugifqs4/UHD_calibrated_SBX.png
>>>
>>> Thanks for any comments,
>>> Rickard
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130530/2f1d85fc/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 30 May 2013 09:36:16 -0700
From: Ian Buckley <[email protected]>
To: Giulio Mazzoleni <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD protocol specifications
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Giulio,
The main root of UHD knowledge can be found here: http://uhd.ettus.com
Whilst the published API of UHD is designed to be stable and used by 3rd
parties for application development, the protocols it employs "under then hood"
are very specific to the USRP hardware implementations, with a primary design
goal of performance rather than enabling further 3rd party hardware
development. Locking down the internal protocols with a formal specification
would be counter productive to the goal of an increasingly diverse ecosystem of
Ettus/NI USRP hardware with very different internal designs. Thus the only
published documentation of the over the wire protocols is the open source code
for both host and the USRP's, and the protocols employed will by there nature
evolve significantly over time.
-Ian
On May 30, 2013, at 1:58 AM, Giulio Mazzoleni
<[email protected]> wrote:
> Dear USRP users,
> I am new to this mailing list, so greetings to everyone.
>
> I was looking at SDR support for GNU radio and Simulink and seems that
> USRP2/UHD is the most widely used and supported.
>
> I've been experimenting with the UHD driver in the last few days since I
> would like to create a compatible UHD endpoint (at least for a minor
> subset of functions, mostly related to rx and tx).
>
> I took a look at the driver implementation and at the host code, even if
> it seems a bit complex to understand at first and could accomplish some
> basic single channel transfers in gnu radio.
>
> The real problem is that the PC driver is doing many error checking
> based on data coming from I2C and FPGA registers and the data flow is
> somewhat difficult to follow in case of errors.
>
> Is there any formal specification of the UHD protocol? Or the source
> code is the only real source of information publicly available, as I
> guess?
>
> I see that this very question has alreaduy been posted in the past
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-March/003871.html
> but got no answer at that time.
>
> Thank you very much for any suggestion you could think of and best
> regards,
> Giulio
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Thu, 30 May 2013 16:40:48 +0000 (UTC)
From: Marcus Leech <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] 1/f shaped noise floor on SBX - is this a
normal feature?
Message-ID: <977539837.58324.1369932048973.JavaMail.mail@webmail04>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130530/557c814e/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 30 May 2013 13:23:00 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Sample OTW Format
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/29/2013 03:32 AM, Paola Madonna wrote:
> Hi Josh,
>
> I would like to increasethesample rate of USRP1 to 32Msps but this could be
> possible if the sample over the wire should be represented as 1
> byte(sc4)because
> the USB is 2.0 and its max rate is 480Mb/s.I have read the uhddocumentation
> and
> it seems that the minimum otw format is sc8 and the sc4 format is
> notyetimplementedin the latest uhd release.Will this feature be implementedin
> the future uhd releases?
>
I dont think we will be introducing complex 4bit samples anytime soon.
FWIW, this could be done with some FPGA customization. Also we do sell
devices with greater bandwidth than USRP1 w/ gigabit ethernet bandwidths.
-josh
> Thanksin advance,
>
> __________________
>
> Paola Madonna
>
> Senior SW Engineer
>
> Space&Navigation Unit
>
> TRS S.p.A.
>
> Via Giulio Cesare 105
>
> c/oSelex-SI, Stab. Fusaro
>
> 80070 Bacoli (NA)
>
> Italy
>
> Ph.: +39 081 0050 829
>
> Fax: +39 081 52 72 828
>
> <http://www.trs.it>
> Via della Bufalotta, 378 - 00139 Roma
> Tel: 06.872811 - Fax: 06.87281.550
> ---------------------------------------------------------
> Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute in
> questo
> messaggio sono riservate ed a uso esclusivo del destinatario. Qualora il
> messaggio in parola Le fosse pervenuto per errore, la preghiamo di eliminarlo
> senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente
> comunicazione.
> Grazie.
> This message, for the law 196/2003, may contain confidential and/or
> privileged
> information. If you are not the addressee or authorized to receive this for
> the
> addressee, you must not use, copy, disclose or take any action based on this
> message or any information herein. If you have received this message in
> error,
> please advise the sender immediately by reply e-mail and delete this message.
> Thank you for your cooperation.
> ---------------------------------------------------------
> This message has been scanned for viruses and dangerous content by
> *MailScanner*
> <http://www.mailscanner.info/>, and is believed to be clean.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 6
Date: Thu, 30 May 2013 18:32:13 +0000 (UTC)
From: Marcus Leech <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sample OTW Format
Message-ID: <839205106.59603.1369938733946.JavaMail.mail@webmail04>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130530/ac7139a4/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 30 May 2013 13:33:19 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD protocol specifications
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
>
> Is there any formal specification of the UHD protocol? Or the source
> code is the only real source of information publicly available, as I
> guess?
>
The sample data is encapsulated in VITA49 IF data packets.
http://wdv.com/Electronics/Reference/SDROoverWEB-VITA.pdf
For control, every device has a set of addressable registers. Sets of
registers correspond to modules in the FPGA. The control protocol to
address these registers differs from device to device.
For USRP2 and N210, this control protocol can be summed up in the
header: host/lib/usrp/usrp2/fw_common.h
-josh
> I see that this very question has alreaduy been posted in the past
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-March/003871.html
> but got no answer at that time.
>
> Thank you very much for any suggestion you could think of and best
> regards,
> Giulio
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Thu, 30 May 2013 21:41:20 +0200
From: Rickard <[email protected]>
To: Marcus Leech <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 1/f shaped noise floor on SBX - is this a
normal feature?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Thanks and yes of course increasing the gain helps to drown this little bias.
Just curious of any reason and glad to know its normal so I don't have to chase
ghosts. I am trying to get as clean signal as possible as I want to maximize
the reach between Tx and Rx, given reasonable gain in antennas, losses, etc.,
and then I pump up the gain both at Tx and Rx anyway.
However, I cannot manage to get the uhd-calibration to make a difference still,
also at Tx.
On 30 maj 2013, at 18:40, Marcus Leech <[email protected]> wrote:
> Try setting your RF gain to somewhere mid-range, and see how that changes
> things.
>
>
> -104dB FS is a very, very, very tiny DC offset, likely due to a slight
> numerical quantization bias somewhere in the chain. With any kind of
> *actual* signal, at any kind of reasonable gain levels, this very narrow
> spike at DC wil have effectively-zero effect on anything--it's a tiny amount
> of additional noise added to your signal
> .
>
>
> on May 30, 2013, Rickard Radio <[email protected]> wrote:
> Works great - it was easy to move the annoying 1/f noise out of my passband!
>
> However, I still have a fairly high DC offset left - a strong spike exactly
> at zero digital freq (almost 20 dB above the noise floor).
> https://www.dropbox.com/s/1lfhvr73405zvht/UHD_lo-offset.png
>
> This DC-offset peak stays independent of the chosen offset tuning (lo_off)
> and center frequency, bandwidth, etc.
> Where does this come from and it is somehow possible to get rid of? (Not
> that it seem to hurt as much as the 1/f noise)
>
> Using the UHD calibrated values, or not, does not result in any difference.
> Why?
>
> Rickard
>
>
>
> On May 29, 2013, at 7:06 PM, Marcus Leech <[email protected]> wrote:
>
>> Yes, the lo_off parameter basically tells UHD to program the analog hardware
>> for an offset (by lo_off) tuned frequency, and then the DDC in the FPGA
>> downconverts so that your desired center frequency is still at DC in the
>> digital sample stream, but the *analog* DC is offset (usually to somewhere
>> outside your passband). This is conceptually very similar to a normla
>> superhet approach with an actual real IF, rather than a zero IF.
>>
>> I encourage you to try it. Make your lo_off be half your passband
>> bandwidth, which will place "analog DC" at the edge of your passband.
>>
>> on May 29, 2013, Rickard Radio <[email protected]> wrote:
>> All I can get, i.e. 25 MHz 16 bit or 50 MHz 8 bit.
>>
>> I am not sure what you mean. Do you mean that with a certain wanted analog
>> carrier (center) frequency, fc, which is what I normally use but then also
>> with this "offset tuning", I still receive/transmit the whole bandwidth
>> centered around fc in RF (analog domain in the air) but have just
>> (circularly) shifted the whole spectrum after sampling in the digital domain
>> which I can then just undo in digital domain by the DDC with the uhd? Or
>> maybe I got this totally wrong?
>>
>> Is "offset tuning" equivalent to the "lo_off" parameter to use with the
>> "uhd.tune_request(fc, lo_off)" ?
>> I never really understood that parameter until perhaps now? I will try that
>> tomorrow!
>>
>> On May 29, 2013, at 6:39 PM, Marcus Leech <[email protected]> wrote:
>>
>>> How much bandwidth are you using?
>>>
>>> With offset tuning, your desired center frequency is still slap-dab in the
>>> middle, but UHD has arranged to tune the analog hardware differently, and
>>> then use the DDC to move DC to somewhere else, and still have your desired
>>> Fc exactly where you want it.
>>>
>>> on May 29, 2013, Rickard Radio <[email protected]> wrote:
>>> OK, thanks! However, I want to utilize all the bandwidth I can get so the
>>> passband need to stay in the centre. As a consequence then also the 1/f
>>> noise peak has a relatively small total power, except when the received
>>> signal is very weak which leads me to another related question I have...
>>>
>>> On May 29, 2013, at 6:26 PM, Marcus Leech <[email protected]> wrote:
>>>
>>>> The SBX is a direct-conversion receiver, so you'll see some 1/f noise.
>>>> You can use offset tuning to move DC out of your passband, and as a happy
>>>> consequence, move the 1/f noise out of your passband as well.
>>>>
>>>>
>>>>
>>>> on May 29, 2013, Rickard Radio <[email protected]> wrote:
>>>> Hi USRP users,
>>>>
>>>> I have a (rather strong ?) 1/f shaped noise floor with the SBX
>>>> daughterboards (rev 4 I think, acquired end of 2012).
>>>> Running the uhd-calibration utilities does not give any visible
>>>> difference, see links to pics below.
>>>> As a comparison, the noise floor on the RFX2400 db is rather flat. Maybe
>>>> generally a little higher but without the strong 1/f peak.
>>>>
>>>> Q1: Is this a normal and expected (1/f colored) noise floor with the SBX
>>>> db?
>>>> If I pump up the uhd gain (>0 dB) the 1/f shaped noise floor remains and
>>>> gets amplified correspondingly.
>>>> I know 1/f noise is a common notorious feature in electronics so perhaps
>>>> it is included with the SBX too.
>>>>
>>>> Q2: Should I see (or not) a visible improvement with the uhd-calibration
>>>> enabled (i.e., with the calibration values in .uhd/cal/) ?
>>>> With the calibration enabled the gr-application tells me that the
>>>> appropriate cal values are "loaded", which sounds reassuring? but maybe I
>>>> do something wrong.
>>>>
>>>> Link to picture of PSD without calibration:
>>>> https://www.dropbox.com/s/vl7x8c8i7qn3ueh/UHD_uncalibrated_SBX.png
>>>>
>>>> Link to picture of PSD with calibration (its identical to my eyes):
>>>> https://www.dropbox.com/s/ngc98l71ugifqs4/UHD_calibrated_SBX.png
>>>>
>>>> Thanks for any comments,
>>>> Rickard
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130530/d42fcbd7/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 30 May 2013 21:01:42 +0100
From: Robert Watson <[email protected]>
Cc: Giulio Mazzoleni <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD protocol specifications
Message-ID:
<cap4wt-dhaih1czbeykgb17sc8gp10mjwhc_vk_uuedyr17z...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Giulio,
I had cause to take a fairly low-level look at the UHD traffic with
Wireshark - using the recently incorporated UHD dissector by Alexander
Chemeris and the VITA49 dissector. Although I didn't dig too deeply, it
proved quite useful for me to get some further insights into how it UHD
does its thing when fetching sample data.
(I was actually looking to see how feasible it would be for a student
project to talk to a USRP N2XX directly from an FPGA dev board using the
GbE interface)
Regards,
R.
On 30 May 2013 17:36, Ian Buckley <[email protected]> wrote:
> Giulio,
> The main root of UHD knowledge can be found here: http://uhd.ettus.com
> Whilst the published API of UHD is designed to be stable and used by 3rd
> parties for application development, the protocols it employs "under then
> hood" are very specific to the USRP hardware implementations, with a
> primary design goal of performance rather than enabling further 3rd party
> hardware development. Locking down the internal protocols with a formal
> specification would be counter productive to the goal of an increasingly
> diverse ecosystem of Ettus/NI USRP hardware with very different internal
> designs. Thus the only published documentation of the over the wire
> protocols is the open source code for both host and the USRP's, and the
> protocols employed will by there nature evolve significantly over time.
>
> -Ian
>
>
> On May 30, 2013, at 1:58 AM, Giulio Mazzoleni <
> [email protected]> wrote:
>
> > Dear USRP users,
> > I am new to this mailing list, so greetings to everyone.
> >
> > I was looking at SDR support for GNU radio and Simulink and seems that
> > USRP2/UHD is the most widely used and supported.
> >
> > I've been experimenting with the UHD driver in the last few days since I
> > would like to create a compatible UHD endpoint (at least for a minor
> > subset of functions, mostly related to rx and tx).
> >
> > I took a look at the driver implementation and at the host code, even if
> > it seems a bit complex to understand at first and could accomplish some
> > basic single channel transfers in gnu radio.
> >
> > The real problem is that the PC driver is doing many error checking
> > based on data coming from I2C and FPGA registers and the data flow is
> > somewhat difficult to follow in case of errors.
> >
> > Is there any formal specification of the UHD protocol? Or the source
> > code is the only real source of information publicly available, as I
> > guess?
> >
> > I see that this very question has alreaduy been posted in the past
> >
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-March/003871.html
> > but got no answer at that time.
> >
> > Thank you very much for any suggestion you could think of and best
> > regards,
> > Giulio
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130530/d869b600/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 31 May 2013 08:56:57 +0200
From: Giulio Mazzoleni <[email protected]>
To: Robert Watson <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD protocol specifications
Message-ID: <[email protected]>
Content-Type: text/plain
Thank you Ian and Robert.
Yes. I tought it would be like this and it really makes sense.
I also tried the VITA49 and UHD dissectors for wireshark and they proved
to be quite useful.
At the moment there are not so many SDR products out there, and most of
them implement proprietary protocols for data transfer.
In the future, as they spread even more it would be good if there could
be a common minimal interface that would support single channel
transfers and basic settings manipulation (frequency, gain, ...).
As Ian states the UHD protocol goal is performance so many things are
carried under the hood, as nobody usually cares about what's going on.
For custom tests the simplest way to go would be using raw udp packets.
Thank you very much for your feedbacks.
Best regards,
Giulio
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 33, Issue 28
******************************************
