Re: [USRP-users] New (soon) owner question (USB3 over Ethernet)

[Sylvain Munaut via USRP-users]

>> I will be using a Raspberry Pi 3B+ (gigabit Ethernet), GNUradio, and
>> am wondering if anyone has used/tried network attached USB hubs to
>> use a USB3 device with a computer that only has USB2 ports?

Huh ... the Gigabit ethernet on the RPi is a USB 2.0 attached network
controller.

So you would essentially be doing :

USB2 <-> Gigabit <-> Eth USB Hub <-> B200

At that point you might as well plug the B200 directly in the RPi.

Cheers,

   Sylvain

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Difference between master_clock_rate and rate in UHD

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hi all,

As the title mentioned, what is the difference between master_clock_rate and 
rate in UHD? Which one is the DAC's sampling rate? I'm using USRP B210.

Thank you in advance!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] What is wrong?

[Hojoon Yang via USRP-users]

Ah, sorry. there are some typos.manual : start_of_burst = true.exapmle : 
start_of_burst = false.Sorry about that.-hojoon
---원본메일---보낸사람 : Hojoon Yangvia 
USRP-users 받는사람: usrp-users@lists.ettus.com보낸날짜: 
2018-04-30 11:34:48 GMT +0900 (ROK)제목: [USRP-users]What is wrong?
 
 
  Hi,
  
  For synchronization, manual(i.e. 
https://files.ettus.com/manual/page_sync.html) said md.start_of_burst = false.
  
  However, in tx_timed_samples.cpp, md.start_of_burst = true.
  
  Both manual and tx_timed_samples.cpp are latest version.
  
  which uage is right?
  
  -hojoon 
  
 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] What is wrong?

[Hojoon Yang via USRP-users]

Hi,For synchronization, manual(i.e. 
https://files.ettus.com/manual/page_sync.html) said md.start_of_burst = 
false.However, in tx_timed_samples.cpp, md.start_of_burst = true.Both manual 
and tx_timed_samples.cpp are latest version.which uage is right?-hojoon___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] New (soon) owner question (USB3 over Ethernet)

[Marcus Müller via USRP-users]

Hi Brian!

It probably won't work great: since USB and ethernet are fundamentally
different, the round-trip delay won't be of any fun, and I really don't
see why you should spend your money on a network-connected USB3 hub
(wasn't even aware something like that existed!) to couple a computer
with USB2 to a USB3 device.

You should really directly opt for a computer with a USB3 port. Also,
Software Defined Radio at rates that require USB3 (instead of only
USB2, since you can also use USB2 if your sampling rates are below ca
10 MS/s) usually means a high CPU demand – not sure that the Pi3 is the
universally best choice here. (I want so say that: very likely it's
not.)

So, to be honest: simply start with a decent desktop or laptop PC,
preferably running Linux; you might already be using one, so this is a
zero cost option initially. Whatever you design there can (unless you
do something architecture-specific) be ported to an ARM like that in
the Pi easily (if necessary at all), but you're not subject to the
computational limitations of the Pi while you design your system. When
you've shown it works, you can try to make it work on a Pi - optimize
the things that are bottlenecks and so on.

But: you surely wouldn't be considering the Pi up front if you didn't
have an application for such a device: What are you working on? Can we
help you with feedback, suggestions or just encouragement?

Best regards,
Marcus

On Sun, 2018-04-29 at 15:54 -0600, Brian Gieryk via USRP-users wrote:
> Forgive me, please, if this has been asked before, but I find no way
> to search the archives.
> 
> I am currently shopping for a B200/B200 mini for experimenting.
> 
> I will be using a Raspberry Pi 3B+ (gigabit Ethernet), GNUradio, and
> am wondering if anyone has used/tried network attached USB hubs to
> use a USB3 device with a computer that only has USB2 ports?
> 
> Good bad or indifferent, does it work?
> 
> Thank you in advance,
> 
> Brian
> KE6IYC 
> 
> 
> 
> Sent from my iPhone
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] New (soon) owner question (USB3 over Ethernet)

[Brian Gieryk via USRP-users]

Forgive me, please, if this has been asked before, but I find no way to search 
the archives.

I am currently shopping for a B200/B200 mini for experimenting.

I will be using a Raspberry Pi 3B+ (gigabit Ethernet), GNUradio, and am 
wondering if anyone has used/tried network attached USB hubs to use a USB3 
device with a computer that only has USB2 ports?

Good bad or indifferent, does it work?

Thank you in advance,

Brian
KE6IYC 



Sent from my iPhone
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel to rfnoc-maint HEAD

[Yacine Bouguechal via USRP-users]

Thank you very much for your quick answer. 
(I thought you changed the commit of UHD that's why I asked) 
Best Regards, 



Yacine BOUGUECHAL 



Élève ingénieur 3ème année 
[ https://www.ensta-paristech.fr/?utm-source=mails ]


ENSTA ParisTech 

828, boulevard des Maréchaux 

91120 PALAISEAU [ [ https://www.ensta-paristech.fr/fr/venir-ensta-paristech | 
plan ] ] 

[ https://www.ensta-paristech.fr/ | www.ensta-paristech.fr ] 


Nos réseaux : [ https://www.facebook.com/ENSTA.ParisTech | Facebook ] | [ 
https://www.twitter.com/ENSTAParisTech | Twitter ] | [ 
https://plus.google.com/+ENSTA-ParisTechFr/posts | Google+ ] | [ 
https://www.youtube.com/user/ENSTAParisTech | YouTube ] | [ 
https://www.linkedin.com/company/ensta | LinkedIn ] 


De: "switchlanez"  
À: "Yacine Bouguechal"  
Cc: "Nicolas Cuervo" , "USRP-users@lists.ettus.com" 
 
Envoyé: Dimanche 29 Avril 2018 21:41:12 
Objet: Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel 
to rfnoc-maint HEAD 

It's in my first reply to Nicolas. These checkouts are from the "rfnoc-devel" 
branch of uhd, gr-ettus, and fpga and the master branch of gnuradio: 

cd uhd 
git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3 

cd gnuradio 
git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf 
git submodule update --init --recursive 

cd gr-ettus 
git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10 

cd uhd-fpga 
git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486 

On Sun, Apr 29, 2018 at 12:29 PM, Yacine Bouguechal < [ 
mailto:yacine.bouguec...@ensta-paristech.fr | 
yacine.bouguec...@ensta-paristech.fr ] > wrote: 



Hello, 
Can you please tell me what versions of the different packages you used because 
I am also trying to revert back to old commit. 
Thank you. 






De: "switchlanez via USRP-users" < [ mailto:usrp-users@lists.ettus.com | 
usrp-users@lists.ettus.com ] > 
À: "Nicolas Cuervo" < [ mailto:nicolas.cue...@ettus.com | 
nicolas.cue...@ettus.com ] > 
Cc: " [ mailto:USRP-users@lists.ettus.com | USRP-users@lists.ettus.com ] " < [ 
mailto:usrp-users@lists.ettus.com | usrp-users@lists.ettus.com ] > 
Envoyé: Dimanche 29 Avril 2018 21:22:05 
Objet: Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel 
to rfnoc-maint HEAD 

I got uhd to build. Thanks for your help. 

On Sun, Apr 29, 2018 at 11:33 AM, switchlanez < [ mailto:switchla...@gmail.com 
| switchla...@gmail.com ] > wrote: 

BQ_BEGIN

Thank you for the response, Nicolas. I realized the aec2fe9 commit from 
27-JUN-17 only applies to the "maint" branch in the "fpga" repo. Instead I 
should checkout commits from the "rfnoc-devel" branch of the "fpga," 
"gr-ettus," and "uhd" repos and "master" branch of the "gnuradio" repo (from 
gnuradio/gnuradio github, not ettusresearch/gnuradio). So after uninstalling 
whatever builds I had of uhd, gnuradio, and gr-ettus (I guess uhd-fpga isn't 
installed), I checked out commits on or before 27-JUN-17: 

cd uhd 
git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3 

cd gnuradio 
git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf 
git submodule update --init --recursive 

cd gr-ettus 
git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10 

cd uhd-fpga 
git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486 

Then built in that order but I get a make error in "uhd": 

/home/switchlanez/rfnoc/src/uhd/host/include/uhd/rfnoc/block_ctrl_base.hpp:74:69:
 error: invalid new-expression of abstract class type 
‘uhd::rfnoc::magnesium_radio_ctrl_impl’ 
return block_ctrl_base::sptr(new CLASS_NAME##_impl(make_args)); \ 
... 
lib/CMakeFiles/uhd.dir/build.make:3088: recipe for target 
'lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o' 
failed 


I guess I'll try a different commit from "uhd" repo/"rfnoc-devel" branch unless 
you or someone can see something else I'm doing fundamentally wrong. 

Andrew 

On Sun, Apr 29, 2018 at 10:40 AM, Nicolas Cuervo < [ 
mailto:nicolas.cue...@ettus.com | nicolas.cue...@ettus.com ] > wrote: 

BQ_BEGIN

Hello Andrew, 

BQ_BEGIN



I did a fresh install of the latest rfnoc-devel (using pybombs prefix init 
~/rfnoc -R rfnoc -a rfnoc) and RFNoC blocks do not work (such as FIR and Rx 
Radio, possibly related to USRP-users mailer subject: Core dump with UHD_3.11, 
X310, and LFTX). So I am trying to checkout and build rfnoc-devel to a known 
stable commit: aec2fe9. I ran git checkout aec2fe9 in rfnoc/src/uhd, 
rfnoc/src/gnuradio, and rfnoc/src/gr-ettus. Then from uhd/host/build I ran 
cmake ../ but got this error: 




CMake Error: The source directory "/home/switchlanez/rfnoc/src/uhd/host" does 
not appear to contain CMakeLists.txt 



Please correct me if I'm wrong, but did you run "git checkout aec2fe9" in *all* 
those repositories? that Git hash might be correct for only one of them, and 
the corresponding according commit in the other repositories remains unknown. 
Where did you take that hash from? 

If what I understood is what you did, that might be causing you problems. You 

Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel to rfnoc-maint HEAD

[switchlanez via USRP-users]

The make error I posted about in uhd was due to a dumb mistake on my end
(made custom modifications to radio driver files incorrectly). uhd built
fine when I didn't modify those files.

On Sun, Apr 29, 2018 at 12:41 PM, switchlanez  wrote:

> It's in my first reply to Nicolas. These checkouts are from the
> "rfnoc-devel" branch of uhd, gr-ettus, and fpga and the master branch of
> gnuradio:
>
> cd uhd
> git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3
>
> cd gnuradio
> git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf
> git submodule update --init --recursive
>
> cd gr-ettus
> git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10
>
> cd uhd-fpga
> git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486
>
> On Sun, Apr 29, 2018 at 12:29 PM, Yacine Bouguechal <
> yacine.bouguec...@ensta-paristech.fr> wrote:
>
>> Hello,
>> Can you please tell me what versions of the different packages you used
>> because I am also trying to revert back to old commit.
>> Thank you.
>>
>>
>> --
>> *De: *"switchlanez via USRP-users" 
>> *À: *"Nicolas Cuervo" 
>> *Cc: *"USRP-users@lists.ettus.com" 
>> *Envoyé: *Dimanche 29 Avril 2018 21:22:05
>> *Objet: *Re: [USRP-users] Revert rfnoc-devel to older commit / update
>> rfnoc-devel to rfnoc-maint HEAD
>>
>> I got uhd to build. Thanks for your help.
>>
>> On Sun, Apr 29, 2018 at 11:33 AM, switchlanez 
>> wrote:
>>
>>> Thank you for the response, Nicolas. I realized the aec2fe9 commit from
>>> 27-JUN-17 only applies to the "maint" branch in the "fpga" repo. Instead I
>>> should checkout commits from the "rfnoc-devel" branch of the "fpga,"
>>> "gr-ettus," and "uhd" repos and "master" branch of the "gnuradio" repo
>>> (from gnuradio/gnuradio github, not ettusresearch/gnuradio). So after
>>> uninstalling whatever builds I had of uhd, gnuradio, and gr-ettus (I guess
>>> uhd-fpga isn't installed), I checked out commits on or before 27-JUN-17:
>>>
>>> cd uhd
>>> git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3
>>>
>>> cd gnuradio
>>> git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf
>>> git submodule update --init --recursive
>>>
>>> cd gr-ettus
>>> git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10
>>>
>>> cd uhd-fpga
>>> git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486
>>>
>>> Then built in that order but I get a make error in "uhd":
>>>
>>> /home/switchlanez/rfnoc/src/uhd/host/include/uhd/rfnoc/block_ctrl_base.hpp:74:69:
>>> error: invalid new-expression of abstract class type
>>> ‘uhd::rfnoc::magnesium_radio_ctrl_impl’
>>>  return block_ctrl_base::sptr(new CLASS_NAME##_impl(make_args));
>>> \
>>> ...
>>> lib/CMakeFiles/uhd.dir/build.make:3088: recipe for target
>>> 'lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o'
>>> failed
>>>
>>>
>>> I guess I'll try a different commit from "uhd" repo/"rfnoc-devel" branch
>>> unless you or someone can see something else I'm doing fundamentally wrong.
>>>
>>> Andrew
>>>
>>> On Sun, Apr 29, 2018 at 10:40 AM, Nicolas Cuervo <
>>> nicolas.cue...@ettus.com> wrote:
>>>
 Hello Andrew,

> I did a fresh install of the latest rfnoc-devel (using pybombs prefix
> init ~/rfnoc -R rfnoc -a rfnoc) and RFNoC blocks do not work (such as FIR
> and Rx Radio, possibly related to USRP-users mailer subject: Core dump 
> with
> UHD_3.11, X310, and LFTX). So I am trying to checkout and build 
> rfnoc-devel
> to a known stable commit: aec2fe9. I ran git checkout aec2fe9 in
> rfnoc/src/uhd, rfnoc/src/gnuradio, and rfnoc/src/gr-ettus. Then from
> uhd/host/build I ran cmake ../ but got this error:
>
>
>
> CMake Error: The source directory "/home/switchlanez/rfnoc/src/uhd/host"
> does not appear to contain CMakeLists.txt
>

 Please correct me if I'm wrong, but did you run "git checkout aec2fe9"
 in *all* those repositories? that Git hash might be correct for only one of
 them, and the corresponding according commit in the other repositories
 remains unknown. Where did you take that hash from?

 If what I understood is what you did, that might be causing you
 problems. You need to identify which commits for each of the repositories
 is according to an "stable" version, and checkout accordinglu and
 respectively.


> So I downloaded that file from GitHub with the closest date on or
> before aec2fe9 was released and tried cmake ../ again. But then it could
> not find a bunch of load files: UHDComponent, UHDPackage, etc. And the
> cycle continues.
>

 See my previous comment.


>
> 1) What am I doing wrong here? Reverting to older commits seems like a
> typical thing RNFoC users would do but I haven't found specific steps in
> the mailer (links to topics would help).
>

 See my previous comment. Reverting to older commits is something that
 is commonly done, yes. From what I understood you run to a same hash in all

Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel to rfnoc-maint HEAD

[switchlanez via USRP-users]

It's in my first reply to Nicolas. These checkouts are from the
"rfnoc-devel" branch of uhd, gr-ettus, and fpga and the master branch of
gnuradio:

cd uhd
git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3

cd gnuradio
git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf
git submodule update --init --recursive

cd gr-ettus
git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10

cd uhd-fpga
git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486

On Sun, Apr 29, 2018 at 12:29 PM, Yacine Bouguechal <
yacine.bouguec...@ensta-paristech.fr> wrote:

> Hello,
> Can you please tell me what versions of the different packages you used
> because I am also trying to revert back to old commit.
> Thank you.
>
>
> --
> *De: *"switchlanez via USRP-users" 
> *À: *"Nicolas Cuervo" 
> *Cc: *"USRP-users@lists.ettus.com" 
> *Envoyé: *Dimanche 29 Avril 2018 21:22:05
> *Objet: *Re: [USRP-users] Revert rfnoc-devel to older commit / update
> rfnoc-devel to rfnoc-maint HEAD
>
> I got uhd to build. Thanks for your help.
>
> On Sun, Apr 29, 2018 at 11:33 AM, switchlanez 
> wrote:
>
>> Thank you for the response, Nicolas. I realized the aec2fe9 commit from
>> 27-JUN-17 only applies to the "maint" branch in the "fpga" repo. Instead I
>> should checkout commits from the "rfnoc-devel" branch of the "fpga,"
>> "gr-ettus," and "uhd" repos and "master" branch of the "gnuradio" repo
>> (from gnuradio/gnuradio github, not ettusresearch/gnuradio). So after
>> uninstalling whatever builds I had of uhd, gnuradio, and gr-ettus (I guess
>> uhd-fpga isn't installed), I checked out commits on or before 27-JUN-17:
>>
>> cd uhd
>> git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3
>>
>> cd gnuradio
>> git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf
>> git submodule update --init --recursive
>>
>> cd gr-ettus
>> git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10
>>
>> cd uhd-fpga
>> git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486
>>
>> Then built in that order but I get a make error in "uhd":
>>
>> /home/switchlanez/rfnoc/src/uhd/host/include/uhd/rfnoc/block_ctrl_base.hpp:74:69:
>> error: invalid new-expression of abstract class type
>> ‘uhd::rfnoc::magnesium_radio_ctrl_impl’
>>  return block_ctrl_base::sptr(new CLASS_NAME##_impl(make_args)); \
>> ...
>> lib/CMakeFiles/uhd.dir/build.make:3088: recipe for target
>> 'lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o'
>> failed
>>
>>
>> I guess I'll try a different commit from "uhd" repo/"rfnoc-devel" branch
>> unless you or someone can see something else I'm doing fundamentally wrong.
>>
>> Andrew
>>
>> On Sun, Apr 29, 2018 at 10:40 AM, Nicolas Cuervo <
>> nicolas.cue...@ettus.com> wrote:
>>
>>> Hello Andrew,
>>>
 I did a fresh install of the latest rfnoc-devel (using pybombs prefix
 init ~/rfnoc -R rfnoc -a rfnoc) and RFNoC blocks do not work (such as FIR
 and Rx Radio, possibly related to USRP-users mailer subject: Core dump with
 UHD_3.11, X310, and LFTX). So I am trying to checkout and build rfnoc-devel
 to a known stable commit: aec2fe9. I ran git checkout aec2fe9 in
 rfnoc/src/uhd, rfnoc/src/gnuradio, and rfnoc/src/gr-ettus. Then from
 uhd/host/build I ran cmake ../ but got this error:



 CMake Error: The source directory "/home/switchlanez/rfnoc/src/uhd/host"
 does not appear to contain CMakeLists.txt

>>>
>>> Please correct me if I'm wrong, but did you run "git checkout aec2fe9"
>>> in *all* those repositories? that Git hash might be correct for only one of
>>> them, and the corresponding according commit in the other repositories
>>> remains unknown. Where did you take that hash from?
>>>
>>> If what I understood is what you did, that might be causing you
>>> problems. You need to identify which commits for each of the repositories
>>> is according to an "stable" version, and checkout accordinglu and
>>> respectively.
>>>
>>>
 So I downloaded that file from GitHub with the closest date on or
 before aec2fe9 was released and tried cmake ../ again. But then it could
 not find a bunch of load files: UHDComponent, UHDPackage, etc. And the
 cycle continues.

>>>
>>> See my previous comment.
>>>
>>>

 1) What am I doing wrong here? Reverting to older commits seems like a
 typical thing RNFoC users would do but I haven't found specific steps in
 the mailer (links to topics would help).

>>>
>>> See my previous comment. Reverting to older commits is something that is
>>> commonly done, yes. From what I understood you run to a same hash in all of
>>> the involved repos. I might have understood wrong, but that's not what
>>> you'd want to do.
>>>


 2) I was told the maint branch head will be updated "very soon."
 Assuming I do another fresh new install (using pybombs prefix init ~/rfnoc
 -R rfnoc -a rfnoc like I did above) but with a different prefix, how would
 the steps be different to start from the latest

Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel to rfnoc-maint HEAD

[Yacine Bouguechal via USRP-users]

Hello, 
Can you please tell me what versions of the different packages you used because 
I am also trying to revert back to old commit. 
Thank you. 






De: "switchlanez via USRP-users"  
À: "Nicolas Cuervo"  
Cc: "USRP-users@lists.ettus.com"  
Envoyé: Dimanche 29 Avril 2018 21:22:05 
Objet: Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel 
to rfnoc-maint HEAD 

I got uhd to build. Thanks for your help. 

On Sun, Apr 29, 2018 at 11:33 AM, switchlanez < [ mailto:switchla...@gmail.com 
| switchla...@gmail.com ] > wrote: 



Thank you for the response, Nicolas. I realized the aec2fe9 commit from 
27-JUN-17 only applies to the "maint" branch in the "fpga" repo. Instead I 
should checkout commits from the "rfnoc-devel" branch of the "fpga," 
"gr-ettus," and "uhd" repos and "master" branch of the "gnuradio" repo (from 
gnuradio/gnuradio github, not ettusresearch/gnuradio). So after uninstalling 
whatever builds I had of uhd, gnuradio, and gr-ettus (I guess uhd-fpga isn't 
installed), I checked out commits on or before 27-JUN-17: 

cd uhd 
git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3 

cd gnuradio 
git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf 
git submodule update --init --recursive 

cd gr-ettus 
git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10 

cd uhd-fpga 
git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486 

Then built in that order but I get a make error in "uhd": 

/home/switchlanez/rfnoc/src/uhd/host/include/uhd/rfnoc/block_ctrl_base.hpp:74:69:
 error: invalid new-expression of abstract class type 
‘uhd::rfnoc::magnesium_radio_ctrl_impl’ 
return block_ctrl_base::sptr(new CLASS_NAME##_impl(make_args)); \ 
... 
lib/CMakeFiles/uhd.dir/build.make:3088: recipe for target 
'lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o' 
failed 


I guess I'll try a different commit from "uhd" repo/"rfnoc-devel" branch unless 
you or someone can see something else I'm doing fundamentally wrong. 

Andrew 

On Sun, Apr 29, 2018 at 10:40 AM, Nicolas Cuervo < [ 
mailto:nicolas.cue...@ettus.com | nicolas.cue...@ettus.com ] > wrote: 

BQ_BEGIN

Hello Andrew, 

BQ_BEGIN



I did a fresh install of the latest rfnoc-devel (using pybombs prefix init 
~/rfnoc -R rfnoc -a rfnoc) and RFNoC blocks do not work (such as FIR and Rx 
Radio, possibly related to USRP-users mailer subject: Core dump with UHD_3.11, 
X310, and LFTX). So I am trying to checkout and build rfnoc-devel to a known 
stable commit: aec2fe9. I ran git checkout aec2fe9 in rfnoc/src/uhd, 
rfnoc/src/gnuradio, and rfnoc/src/gr-ettus. Then from uhd/host/build I ran 
cmake ../ but got this error: 




CMake Error: The source directory "/home/switchlanez/rfnoc/src/uhd/host" does 
not appear to contain CMakeLists.txt 



Please correct me if I'm wrong, but did you run "git checkout aec2fe9" in *all* 
those repositories? that Git hash might be correct for only one of them, and 
the corresponding according commit in the other repositories remains unknown. 
Where did you take that hash from? 

If what I understood is what you did, that might be causing you problems. You 
need to identify which commits for each of the repositories is according to an 
"stable" version, and checkout accordinglu and respectively. 

BQ_BEGIN



So I downloaded that file from GitHub with the closest date on or before 
aec2fe9 was released and tried cmake ../ again. But then it could not find a 
bunch of load files: UHDComponent, UHDPackage, etc. And the cycle continues. 

BQ_END

See my previous comment. 

BQ_BEGIN






1) What am I doing wrong here? Reverting to older commits seems like a typical 
thing RNFoC users would do but I haven't found specific steps in the mailer 
(links to topics would help). 

BQ_END


See my previous comment. Reverting to older commits is something that is 
commonly done, yes. From what I understood you run to a same hash in all of the 
involved repos. I might have understood wrong, but that's not what you'd want 
to do. 

BQ_BEGIN





2) I was told the maint branch head will be updated "very soon." Assuming I do 
another fresh new install (using pybombs prefix init ~/rfnoc -R rfnoc -a rfnoc 
like I did above) but with a different prefix, how would the steps be different 
to start from the latest rfnoc-devel installation and update it to the maint 
branch head? Or is there a pybombs recipe to build the latest rfnoc-maint? 

BQ_END

There is no "rfnoc-maint". All RFNoC development is done in the "rfnoc-devel" 
branch. If you change the branch, you wouldn't be able to use all the RFNoC 
features needed for development. 

Cheers, 
- Nicolas 

BQ_END



BQ_END



___ 
USRP-users mailing list 
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel to rfnoc-maint HEAD

[switchlanez via USRP-users]

I got uhd to build. Thanks for your help.

On Sun, Apr 29, 2018 at 11:33 AM, switchlanez  wrote:

> Thank you for the response, Nicolas. I realized the aec2fe9 commit from
> 27-JUN-17 only applies to the "maint" branch in the "fpga" repo. Instead I
> should checkout commits from the "rfnoc-devel" branch of the "fpga,"
> "gr-ettus," and "uhd" repos and "master" branch of the "gnuradio" repo
> (from gnuradio/gnuradio github, not ettusresearch/gnuradio). So after
> uninstalling whatever builds I had of uhd, gnuradio, and gr-ettus (I guess
> uhd-fpga isn't installed), I checked out commits on or before 27-JUN-17:
>
> cd uhd
> git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3
>
> cd gnuradio
> git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf
> git submodule update --init --recursive
>
> cd gr-ettus
> git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10
>
> cd uhd-fpga
> git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486
>
> Then built in that order but I get a make error in "uhd":
>
> /home/switchlanez/rfnoc/src/uhd/host/include/uhd/rfnoc/block_ctrl_base.hpp:74:69:
> error: invalid new-expression of abstract class type
> ‘uhd::rfnoc::magnesium_radio_ctrl_impl’
>  return block_ctrl_base::sptr(new CLASS_NAME##_impl(make_args)); \
> ...
> lib/CMakeFiles/uhd.dir/build.make:3088: recipe for target
> 'lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o'
> failed
>
>
> I guess I'll try a different commit from "uhd" repo/"rfnoc-devel" branch
> unless you or someone can see something else I'm doing fundamentally wrong.
>
> Andrew
>
> On Sun, Apr 29, 2018 at 10:40 AM, Nicolas Cuervo  > wrote:
>
>> Hello Andrew,
>>
>> I did a fresh install of the latest rfnoc-devel (using pybombs prefix
>>> init ~/rfnoc -R rfnoc -a rfnoc) and RFNoC blocks do not work (such as FIR
>>> and Rx Radio, possibly related to USRP-users mailer subject: Core dump with
>>> UHD_3.11, X310, and LFTX). So I am trying to checkout and build rfnoc-devel
>>> to a known stable commit: aec2fe9. I ran git checkout aec2fe9 in
>>> rfnoc/src/uhd, rfnoc/src/gnuradio, and rfnoc/src/gr-ettus. Then from
>>> uhd/host/build I ran cmake ../ but got this error:
>>>
>>>
>>>
>>> CMake Error: The source directory "/home/switchlanez/rfnoc/src/uhd/host"
>>> does not appear to contain CMakeLists.txt
>>>
>>
>> Please correct me if I'm wrong, but did you run "git checkout aec2fe9" in
>> *all* those repositories? that Git hash might be correct for only one of
>> them, and the corresponding according commit in the other repositories
>> remains unknown. Where did you take that hash from?
>>
>> If what I understood is what you did, that might be causing you problems.
>> You need to identify which commits for each of the repositories is
>> according to an "stable" version, and checkout accordinglu and respectively.
>>
>>
>>> So I downloaded that file from GitHub with the closest date on or before
>>> aec2fe9 was released and tried cmake ../ again. But then it could not find
>>> a bunch of load files: UHDComponent, UHDPackage, etc. And the cycle
>>> continues.
>>>
>>
>> See my previous comment.
>>
>>
>>>
>>> 1) What am I doing wrong here? Reverting to older commits seems like a
>>> typical thing RNFoC users would do but I haven't found specific steps in
>>> the mailer (links to topics would help).
>>>
>>
>> See my previous comment. Reverting to older commits is something that is
>> commonly done, yes. From what I understood you run to a same hash in all of
>> the involved repos. I might have understood wrong, but that's not what
>> you'd want to do.
>>
>>>
>>>
>>> 2) I was told the maint branch head will be updated "very soon."
>>> Assuming I do another fresh new install (using pybombs prefix init ~/rfnoc
>>> -R rfnoc -a rfnoc like I did above) but with a different prefix, how would
>>> the steps be different to start from the latest rfnoc-devel installation
>>> and update it to the maint branch head? Or is there a pybombs recipe to
>>> build the latest rfnoc-maint?
>>>
>>
>> There is no "rfnoc-maint". All RFNoC development is done in the
>> "rfnoc-devel" branch. If you change the branch, you wouldn't be able to use
>> all the RFNoC features needed for development.
>>
>>
>> Cheers,
>> - Nicolas
>>
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel to rfnoc-maint HEAD

[switchlanez via USRP-users]

Thank you for the response, Nicolas. I realized the aec2fe9 commit from
27-JUN-17 only applies to the "maint" branch in the "fpga" repo. Instead I
should checkout commits from the "rfnoc-devel" branch of the "fpga,"
"gr-ettus," and "uhd" repos and "master" branch of the "gnuradio" repo
(from gnuradio/gnuradio github, not ettusresearch/gnuradio). So after
uninstalling whatever builds I had of uhd, gnuradio, and gr-ettus (I guess
uhd-fpga isn't installed), I checked out commits on or before 27-JUN-17:

cd uhd
git checkout ba11bf2d699957e9a5d9b587de045162d2fce3e3

cd gnuradio
git checkout 11d59e9f227e3d3f5c388c376ee59e0cfa021dcf
git submodule update --init --recursive

cd gr-ettus
git checkout fbea7f763460ffb42592c6c1c389047b6e0e1a10

cd uhd-fpga
git checkout 8b731c3b277fb2caee0b9633c9b159e55f175486

Then built in that order but I get a make error in "uhd":

/home/switchlanez/rfnoc/src/uhd/host/include/uhd/rfnoc/block_ctrl_base.hpp:74:69:
error: invalid new-expression of abstract class type
‘uhd::rfnoc::magnesium_radio_ctrl_impl’
 return block_ctrl_base::sptr(new CLASS_NAME##_impl(make_args)); \
...
lib/CMakeFiles/uhd.dir/build.make:3088: recipe for target
'lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o'
failed


I guess I'll try a different commit from "uhd" repo/"rfnoc-devel" branch
unless you or someone can see something else I'm doing fundamentally wrong.

Andrew

On Sun, Apr 29, 2018 at 10:40 AM, Nicolas Cuervo 
wrote:

> Hello Andrew,
>
> I did a fresh install of the latest rfnoc-devel (using pybombs prefix init
>> ~/rfnoc -R rfnoc -a rfnoc) and RFNoC blocks do not work (such as FIR and Rx
>> Radio, possibly related to USRP-users mailer subject: Core dump with
>> UHD_3.11, X310, and LFTX). So I am trying to checkout and build rfnoc-devel
>> to a known stable commit: aec2fe9. I ran git checkout aec2fe9 in
>> rfnoc/src/uhd, rfnoc/src/gnuradio, and rfnoc/src/gr-ettus. Then from
>> uhd/host/build I ran cmake ../ but got this error:
>>
>>
>>
>> CMake Error: The source directory "/home/switchlanez/rfnoc/src/uhd/host"
>> does not appear to contain CMakeLists.txt
>>
>
> Please correct me if I'm wrong, but did you run "git checkout aec2fe9" in
> *all* those repositories? that Git hash might be correct for only one of
> them, and the corresponding according commit in the other repositories
> remains unknown. Where did you take that hash from?
>
> If what I understood is what you did, that might be causing you problems.
> You need to identify which commits for each of the repositories is
> according to an "stable" version, and checkout accordinglu and respectively.
>
>
>> So I downloaded that file from GitHub with the closest date on or before
>> aec2fe9 was released and tried cmake ../ again. But then it could not find
>> a bunch of load files: UHDComponent, UHDPackage, etc. And the cycle
>> continues.
>>
>
> See my previous comment.
>
>
>>
>> 1) What am I doing wrong here? Reverting to older commits seems like a
>> typical thing RNFoC users would do but I haven't found specific steps in
>> the mailer (links to topics would help).
>>
>
> See my previous comment. Reverting to older commits is something that is
> commonly done, yes. From what I understood you run to a same hash in all of
> the involved repos. I might have understood wrong, but that's not what
> you'd want to do.
>
>>
>>
>> 2) I was told the maint branch head will be updated "very soon." Assuming
>> I do another fresh new install (using pybombs prefix init ~/rfnoc -R rfnoc
>> -a rfnoc like I did above) but with a different prefix, how would the steps
>> be different to start from the latest rfnoc-devel installation and update
>> it to the maint branch head? Or is there a pybombs recipe to build the
>> latest rfnoc-maint?
>>
>
> There is no "rfnoc-maint". All RFNoC development is done in the
> "rfnoc-devel" branch. If you change the branch, you wouldn't be able to use
> all the RFNoC features needed for development.
>
>
> Cheers,
> - Nicolas
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Updated BSP for e3xx

[Philip Balister via USRP-users]

On 04/28/2018 12:39 PM, Kurt Kiefer via USRP-users wrote:
>> On Apr 19, 2018, at 2:21 PM, Martin Braun  wrote:
>>
>> On 04/16/2018 09:25 PM, Kurt Kiefer via USRP-users wrote:
>>> The last release of the BSP and firmware for e3xx devices is either back at 
>>> fido, which was over two years ago, or jethro a year ago (though it's still 
>>> listed as "beta" on files.ettus.com). This age makes it increasingly 
>>> difficult to find compatible tooling without performing complicated manual 
>>> builds of software on the host and device, we miss out on features only 
>>> present in newer kernels, and miss out on updates to various packages that 
>>> would be included in an up-to-date Yocto build.
>>>
>>> Moving forward, does Ettus Research plan to keep the BSP updated for these 
>>> radios?
>>
>> Kurt,
>>
>> yes we plan to update the E310 and keep its BSP aligned with other BSPs
>> that we have (e.g., the N310 BSP). There is significant work required to
>> get the architectures aligned, and we have not started migrating the
>> E310 to a newer BSP (and won't until we've come out of some other projects).
>>
>> I apologize for the delay in this -- you're correct, fido is pretty old.
>> We don't have a schedule for this yet.
>>
>> Regards,
>> Martin
> 
> If anyone is interested, I've done the work to update the E310 BSP to Rocko 
> with the latest versions of everything available. You can find the layer 
> here, forked from upstream meta-ettus/rocko/n3xx:
> https://github.com/kekiefer/meta-ettus/tree/rocko+e3xx
> 
> Here is the updated manifest:
> https://github.com/kekiefer/e300-manifest/tree/rocko
> 
> The BSP is set up to use the current u-boot from upstream (2017.09) and 
> Kernel from meta-xilinx (2017.03, which is version 4.9). This was a fair 
> amount of work, so I really hope this helps people out and kickstarts the 
> Ettus efforts to get the platform back up-to-date.
> 

Nice work. I may have a chance to poke it next week.

Philip

> Kurt
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Revert rfnoc-devel to older commit / update rfnoc-devel to rfnoc-maint HEAD

[Nicolas Cuervo via USRP-users]

Hello Andrew,

I did a fresh install of the latest rfnoc-devel (using pybombs prefix init
> ~/rfnoc -R rfnoc -a rfnoc) and RFNoC blocks do not work (such as FIR and Rx
> Radio, possibly related to USRP-users mailer subject: Core dump with
> UHD_3.11, X310, and LFTX). So I am trying to checkout and build rfnoc-devel
> to a known stable commit: aec2fe9. I ran git checkout aec2fe9 in
> rfnoc/src/uhd, rfnoc/src/gnuradio, and rfnoc/src/gr-ettus. Then from
> uhd/host/build I ran cmake ../ but got this error:
>
>
>
> CMake Error: The source directory "/home/switchlanez/rfnoc/src/uhd/host"
> does not appear to contain CMakeLists.txt
>

Please correct me if I'm wrong, but did you run "git checkout aec2fe9" in
*all* those repositories? that Git hash might be correct for only one of
them, and the corresponding according commit in the other repositories
remains unknown. Where did you take that hash from?

If what I understood is what you did, that might be causing you problems.
You need to identify which commits for each of the repositories is
according to an "stable" version, and checkout accordinglu and respectively.


> So I downloaded that file from GitHub with the closest date on or before
> aec2fe9 was released and tried cmake ../ again. But then it could not find
> a bunch of load files: UHDComponent, UHDPackage, etc. And the cycle
> continues.
>

See my previous comment.


>
> 1) What am I doing wrong here? Reverting to older commits seems like a
> typical thing RNFoC users would do but I haven't found specific steps in
> the mailer (links to topics would help).
>

See my previous comment. Reverting to older commits is something that is
commonly done, yes. From what I understood you run to a same hash in all of
the involved repos. I might have understood wrong, but that's not what
you'd want to do.

>
>
> 2) I was told the maint branch head will be updated "very soon." Assuming
> I do another fresh new install (using pybombs prefix init ~/rfnoc -R rfnoc
> -a rfnoc like I did above) but with a different prefix, how would the steps
> be different to start from the latest rfnoc-devel installation and update
> it to the maint branch head? Or is there a pybombs recipe to build the
> latest rfnoc-maint?
>

There is no "rfnoc-maint". All RFNoC development is done in the
"rfnoc-devel" branch. If you change the branch, you wouldn't be able to use
all the RFNoC features needed for development.


Cheers,
- Nicolas
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] B210 FPGA Code

[Yeo Jin Kuang Alvin (IA) via USRP-users]

Hello,

I want to create a chirp signal starting with a 32 bit. I have created the 
chirp signal internally in the FPGA from 32 bit and truncate down to 12 bit. 

I have removed the original connection from GPIF_D to tx_code_d. The input of 
the 32 bit chirp signal is applied internally and the 12 bit output is then 
connected to the tx_code_d.

I not sure if this works, but I have tried uploading this .bin file to the UHD 
C++ using command prompt and generated out something and looked something like 
a chirp signal. But however, when I changed the input of my chirp signal, the 
bandwidth is always around 35 MHz. 

For example, my signal suppose to be starting from 15 MHz to 35 MHz, with a BW 
of 20 MHz. When I enter the value of - - freq = 100, I thought this center 
frequency is suppose to shift the signal to 115 to 135 MHz centered at 125 MHz. 
But what I see in the spectrum analyser is centered at 100 MHz, with a 
bandwidth of about ~ 35MHz.

Did I misinterpreted something or somewhere wrongly? 

Thanks in advance!

From: Derek Kozel [derek.ko...@ettus.com]
Sent: 26 April 2018 18:39
To: Yeo Jin Kuang Alvin (IA)
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B210 FPGA Code

Hello Yeo Jin Kuang Alvin,

I am not Ettus' expert in the B210 FPGA, but it would be highly unusual if 
there were arbitrary bit width changes. I believe that the GPIF bus is 16 bits 
of I and Q in parallel. The FX3 GPIF bus definition is included in the source 
and you can use Cypress's tools to look at the configuration of the bus in 
addition to the FPGA source code. There is considerable DSP implemented in the 
FPGA, including the decimation, interpolation, and frequency shifting 
operations. At minimum you would have to make changes to the UHD driver to 
remove support for those features if you bypass them.

My apologies if I've missed this in another email, but what is your goal with 
these changes?

Regards,
Derek

On Thu, Apr 26, 2018 at 10:18 AM, Yeo Jin Kuang Alvin (IA) via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hi everyone!

For the FPGA source code written for b210, I noticed that the input to the 
GPIF_D that is 32 bits, and then in went through some FIFOs up converting to 64 
bits and then down to 12 bits output (tx_codec_d).

May I know what is the purpose of up converting and then down convert again?

Will it affect anything if I remove all these and just connect GPIF_D (32 bits) 
input and take 12 bits MSB (truncation) and connect directly to tx_codec_d (12 
bits) ?

Thanks in advance!

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Time tagging in the FPGA

[Marcus Müller via USRP-users]

One time long ago, a friend of mine wrote a tool necessary to
compensate for the TX / RX delay in USRP radar applications.
What he basically did was test the delay of crosstalk.

Best regards,
Marcus

On Sat, 2018-04-28 at 16:39 -0400, Marcus D. Leech via USRP-users
wrote:
> There's no example code in the Ettus examples, but there may be folks
> on this list who might share their wisdom in this regard.

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com