Re: [USRP-users] X310 RFNoC transmission issues

[Jonathon Pendlum via USRP-users]

Hello Leon,

Did you check to see if your custom image failed timing?

Jonathon

On Thu, May 9, 2019 at 12:12 AM zluudg via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello!
>
> I'm having some issues while trying to transmit a signal using the
> RFNoC: Radio block in Gnuradio. My block diagram is:
>
>
>  Signal Source (constant) -> RFNoC: DmaFIFO -> RFNoC: Radio (in
> TX mode).
>
>
> I run the block diagram by calling "python top_block.py" from the
> command line and I'm not getting any errors while it's running .
> However, I'm unable to quit it properly without having to close the
> terminal window and power-cycle the USRP. When connecting the USRP to a
> spectrum analyzer I see no signal whatsoever (I expect to see a peak at
> 2.4 GHz).
>
>
> Removing the DmaFIFO does not seem to make any difference. My FPGA image
> is a custom image with some of my CEs, but it was built smoothly using
> the "uhd_image_builder.py" script. I've also experienced similar
> problems while having a RFNoC: DUC between the DmaFIFO and the Radio
> block, also with a custom FPGA image. With the stock FPGA image I was
> able to get a signal with more or less the same Gnuradio block diagram.
>
>
> Why am I not seeing any output with my custom FPGA images? All
> suggestions appreciated.
>
>
> I'll happily provide more info if needed, so don't hesitate to ask. For
> know, I'll just provide the basics:
>
>
>  OS: Ubuntu 18.04
>
>  uhd: rfnoc-devel, eec24d7b0
>
>  gnuradio: maint-3.7, c6c575309
>
>  gr-ettus: master, a909447
>
>
> Thanks in advance!
>
> //
>
> Leon
>
>
> ___
> 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] USRP N320 and N321 questions

[Ali Dormiani via USRP-users]

Hello all,

I don't see why PCIe cards wont work. There are plenty of them out there
with Intel and Mellonox chips (2 QSFP+ ports per PCIe 3.0 x8 card).

Note that you need to check your host machine has the correct PCIe
revision. A lot of boards have one 3.0 x16 slot and a bunch of 2.0 x4 or x8
slots.

Here is one:

https://www.amazon.com/StarTech-com-Dual-Port-QSFP-Server/dp/B07983NGQH

I recommend you gravitate towards cards based on Intel chips/controllers.
Intel's open source commitment/drivers is above every other network gear
company (in my experience). Broadcom is by far the worst for open source
drivers.

I agree with Marcus on the CPU issue. That ARM dual-core is going to get
annihilated at the full rate.

On Wed, May 8, 2019 at 2:11 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/08/2019 04:55 PM, Minutolo, Lorenzo (389I) via USRP-users wrote:
> > Hi,
> > I have some question about your new products.
> >
> > 1) What is the suggested hardware for communicating with the QSFP+ port?
> As I understand this a normal 40 Gbit PCIe card won’t work.
> >
> > 2) Does the embedded linux system gives any error while handling two
> channels at 200Msps full duplex without any signal processing (i.e.
> benchmark rate)?
> I'm going to go ahead and guess that an 800MHz CPU would be unable to
> consume 400Msps in any possible way, since that would imply an
>average of only 2 CPU clocks/sample. Even just bringing those samples
> into the CPU realm and into user-space would be some kind of
>minor miracle, even with multiple instruction issues/clock.
>
>
>
>
> >
> > Lorenzo
> > ___
> > 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Relationship between IQ values, gain and noise on B205mini transmitter

[Brian Padalino via USRP-users]

What does the signal look like in the time domain?

Is it driving the amplifier on the B205mini into saturation?

Brian

On Wed, May 8, 2019 at 7:57 PM Michael Deacon  wrote:

> I added some attenuation. The overload is gone but the condition persists.
>
>
>
> Thanks,
>
>
>
> Mike
>
>
>
> *From:* Brian Padalino 
> *Sent:* Wednesday, May 8, 2019 4:37 PM
> *To:* Michael Deacon 
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Relationship between IQ values, gain and
> noise on B205mini transmitter
>
>
>
> On Wed, May 8, 2019 at 7:28 PM Michael Deacon via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello,
>
>
>
> I have a simple transmitter consisting of a file source connected to a
> USRP sink (attached image radio.png). The file contains interleaved
> floating point IQ representing a few seconds of LTE. The IQ amplitude
> values are normalized between +1.0 and -1.0. The sink is configured to
> 60db, 7.5MHz sample rate, 385MHz center frequency and 5MHz bandwidth. The
> output looks exactly like the original on a spectrum analyzer (see attached
> good.jpg). If I turn up the gain on the sink or increase the amplitude of
> the IQ data I get what looks to be noise on either side of the signal
> spectrum (see attached bad.jpg). Any idea what is going on here?
>
>
>
> Your bad.jpg picture has the spectrum analyzer saying OLVD.  Try changing
> your reference level of the spectrum analyzer to be higher so you don't
> saturate the input of the spectrum analyzer.
>
>
>
> Tell us if that fixes it for you.
>
>
>
> Brian
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

I see.  Okay.  I would like to investigate the precompiled packages back as far 
as the Ettus repository has them but being new to Linux I’m ignorant about how 
to use PPAs to actually get to the code I need and use it so I’ll need to do 
some intensive research to find a tutorial or instructions as to how to use 
them.  So this will take me a little while to come up to speed on it.

Joe

> On May 8, 2019, at 5:38 PM, Marcus D. Leech via USRP-users 
>  wrote:
> 
> On 05/08/2019 07:34 PM, Joe Martin via USRP-users wrote:
>> Thanks Philip, I’ll check out the precompiled versions on the link Robin 
>> provided, to see if they go back far enough first.  I tried the 3.9.0 so I’m 
>> thinking 3.8.x might still be too recent but if none of these work perhaps I 
>> can ask you to take a look for something earlier.  Thanks!
>> 
>> Joe
> The basic issue is that there never were that many R2s about that I recall, 
> before the R3 and the ADC input change was made, so I don't think there
>  was much push to retain compatibility for modern versions.
> 
> 
>> 
>>> On May 8, 2019, at 4:02 PM, Philip Balister  wrote:
>>> 
>>> I've got the 3.8.4 images zipfile lying around in my OE download
>>> directory, if it helps I can put it on dropbox. I might be able to find
>>> some older ones if needed.
>>> 
>>> Yeah, I save ancient source in case of a GPL compliance exercise :)
>>> 
>>> Philip
>>> 
>>> On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:
 You could try using the .deb or .rpm pre-built binaries if you're running
 on Linux.  See, for instance:
 http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/
 
 On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
 usrp-users@lists.ettus.com> wrote:
 
> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
> complains that it is expecting compatibility number 11 but is receiving 6.
> So I think that means I need an earlier version of UHD than 3.9.0.
> 
> I will dig into the earliest version in the git tag -l, namely
> 003_007_002_rc1, that would not build without errors and try to work out
> the compiler errors then.  Unless someone has a better idea to try.
> Thanks!
> 
> Regards,
> 
> Joe
> 
> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
> Okay, thanks, that’s what I thought but that isn’t useful for me until I
> find a UHD version that can communicate with it.  I’ve been trying to 
> build
> older UHD versions from 003_007_002_rc1 forward but all so far fail to
> build due to compiler errors.  Am up to 003_008_005_rc1 now, moving 
> forward
> until I can successfully build one to try.  Are there any old pre-built
> versions I could simply try without having to build each one myself?
> 
> Joe
> 
> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
> 
> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
> way to figure out what image is loaded other than asking UHD to query it
> for FPGA compat number.
> 
> On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:
> 
>> I guess the proper way to ask is “Is there a way to determine what fpga
>> .bin file is in the N210?”, since the .bit file that I loaded into the 
>> fpga
>> is volatile code that disappears upon power cycling to be reloaded from 
>> an
>> EEPROM or something, yes?
>> 
>> Joe
>> 
>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> 
>> Hi Nick,
>> 
>> Thanks for the comments.  Is there a way to determine what bit file is
>> currently in the N210?  If so, how please?
>> 
>> Joe
>> 
>> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>> 
>> I see you got there already! If you're still having trouble, I'll see
>> what I can dig up over here.
>> 
>> On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
>> 
>>> You might be best off reverting to a UHD old enough to support the
>>> bitfile currently loaded on your N210. You could then bootstrap your 
>>> N210
>>> by using the old UHD to load a newer FPGA image.
>>> 
>>> Otherwise, it's fairly simple to convert the binfiles (which still exist
>>> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
>>> usrp_n210_r3_fpga.bit and just stick it onto the front of
>>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
>>> header is everything up until FF FF FF FF AA 99 55 66.
>>> 
>>> Lastly, the source is all there, so building using ISE should still be
>>> possible.
>>> 
>>> Nick
>>> 
>>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
>>> usrp-users@lists.ettus.com> 

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Thanks, Marcus.

Joe

> On May 8, 2019, at 6:41 PM, Joe Martin  wrote:
> 
> I see.  Okay.  I would like to investigate the precompiled packages back as 
> far as the Ettus repository has them but being new to Linux I’m ignorant 
> about how to use PPAs to actually get to the code I need and use it so I’ll 
> need to do some intensive research to find a tutorial or instructions as to 
> how to use them.  So this will take me a little while to come up to speed on 
> it.
> 
> Joe
> 
>> On May 8, 2019, at 5:38 PM, Marcus D. Leech via USRP-users 
>>  wrote:
>> 
>> On 05/08/2019 07:34 PM, Joe Martin via USRP-users wrote:
>>> Thanks Philip, I’ll check out the precompiled versions on the link Robin 
>>> provided, to see if they go back far enough first.  I tried the 3.9.0 so 
>>> I’m thinking 3.8.x might still be too recent but if none of these work 
>>> perhaps I can ask you to take a look for something earlier.  Thanks!
>>> 
>>> Joe
>> The basic issue is that there never were that many R2s about that I recall, 
>> before the R3 and the ADC input change was made, so I don't think there
>> was much push to retain compatibility for modern versions.
>> 
>> 
>>> 
 On May 8, 2019, at 4:02 PM, Philip Balister  wrote:
 
 I've got the 3.8.4 images zipfile lying around in my OE download
 directory, if it helps I can put it on dropbox. I might be able to find
 some older ones if needed.
 
 Yeah, I save ancient source in case of a GPL compliance exercise :)
 
 Philip
 
 On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:
> You could try using the .deb or .rpm pre-built binaries if you're running
> on Linux.  See, for instance:
> http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/
> 
> On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 
>> did
>> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
>> complains that it is expecting compatibility number 11 but is receiving 
>> 6.
>> So I think that means I need an earlier version of UHD than 3.9.0.
>> 
>> I will dig into the earliest version in the git tag -l, namely
>> 003_007_002_rc1, that would not build without errors and try to work out
>> the compiler errors then.  Unless someone has a better idea to try.
>> Thanks!
>> 
>> Regards,
>> 
>> Joe
>> 
>> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> 
>> Okay, thanks, that’s what I thought but that isn’t useful for me until I
>> find a UHD version that can communicate with it.  I’ve been trying to 
>> build
>> older UHD versions from 003_007_002_rc1 forward but all so far fail to
>> build due to compiler errors.  Am up to 003_008_005_rc1 now, moving 
>> forward
>> until I can successfully build one to try.  Are there any old pre-built
>> versions I could simply try without having to build each one myself?
>> 
>> Joe
>> 
>> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
>> 
>> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
>> way to figure out what image is loaded other than asking UHD to query it
>> for FPGA compat number.
>> 
>> On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:
>> 
>>> I guess the proper way to ask is “Is there a way to determine what fpga
>>> .bin file is in the N210?”, since the .bit file that I loaded into the 
>>> fpga
>>> is volatile code that disappears upon power cycling to be reloaded from 
>>> an
>>> EEPROM or something, yes?
>>> 
>>> Joe
>>> 
>>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>> 
>>> Hi Nick,
>>> 
>>> Thanks for the comments.  Is there a way to determine what bit file is
>>> currently in the N210?  If so, how please?
>>> 
>>> Joe
>>> 
>>> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>>> 
>>> I see you got there already! If you're still having trouble, I'll see
>>> what I can dig up over here.
>>> 
>>> On Wed, May 8, 2019 at 12:31 PM Nick Foster  
>>> wrote:
>>> 
 You might be best off reverting to a UHD old enough to support the
 bitfile currently loaded on your N210. You could then bootstrap your 
 N210
 by using the old UHD to load a newer FPGA image.
 
 Otherwise, it's fairly simple to convert the binfiles (which still 
 exist
 -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
 usrp_n210_r3_fpga.bit and just stick it onto the front of
 usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
 header is everything up until FF FF FF FF AA 99 55 66.

Re: [USRP-users] Relationship between IQ values, gain and noise on B205mini transmitter

[Michael Deacon via USRP-users]

I added some attenuation. The overload is gone but the condition persists.



Thanks,



Mike



From: Brian Padalino 
Sent: Wednesday, May 8, 2019 4:37 PM
To: Michael Deacon 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Relationship between IQ values, gain and noise on 
B205mini transmitter



On Wed, May 8, 2019 at 7:28 PM Michael Deacon via USRP-users 
mailto:usrp-users@lists.ettus.com> > wrote:

Hello,



I have a simple transmitter consisting of a file source connected to a USRP 
sink (attached image radio.png). The file contains interleaved floating 
point IQ representing a few seconds of LTE. The IQ amplitude values are 
normalized between +1.0 and -1.0. The sink is configured to 60db, 7.5MHz 
sample rate, 385MHz center frequency and 5MHz bandwidth. The output looks 
exactly like the original on a spectrum analyzer (see attached good.jpg). If 
I turn up the gain on the sink or increase the amplitude of the IQ data I 
get what looks to be noise on either side of the signal spectrum (see 
attached bad.jpg). Any idea what is going on here?



Your bad.jpg picture has the spectrum analyzer saying OLVD.  Try changing 
your reference level of the spectrum analyzer to be higher so you don't 
saturate the input of the spectrum analyzer.



Tell us if that fixes it for you.



Brian

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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Marcus D. Leech via USRP-users]

On 05/08/2019 07:34 PM, Joe Martin via USRP-users wrote:

Thanks Philip, I’ll check out the precompiled versions on the link Robin 
provided, to see if they go back far enough first.  I tried the 3.9.0 so I’m 
thinking 3.8.x might still be too recent but if none of these work perhaps I 
can ask you to take a look for something earlier.  Thanks!

Joe
The basic issue is that there never were that many R2s about that I 
recall, before the R3 and the ADC input change was made, so I don't 
think there

  was much push to retain compatibility for modern versions.





On May 8, 2019, at 4:02 PM, Philip Balister  wrote:

I've got the 3.8.4 images zipfile lying around in my OE download
directory, if it helps I can put it on dropbox. I might be able to find
some older ones if needed.

Yeah, I save ancient source in case of a GPL compliance exercise :)

Philip

On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:

You could try using the .deb or .rpm pre-built binaries if you're running
on Linux.  See, for instance:
http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/

On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:


I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
complains that it is expecting compatibility number 11 but is receiving 6.
So I think that means I need an earlier version of UHD than 3.9.0.

I will dig into the earliest version in the git tag -l, namely
003_007_002_rc1, that would not build without errors and try to work out
the compiler errors then.  Unless someone has a better idea to try.
Thanks!

Regards,

Joe

On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

Okay, thanks, that’s what I thought but that isn’t useful for me until I
find a UHD version that can communicate with it.  I’ve been trying to build
older UHD versions from 003_007_002_rc1 forward but all so far fail to
build due to compiler errors.  Am up to 003_008_005_rc1 now, moving forward
until I can successfully build one to try.  Are there any old pre-built
versions I could simply try without having to build each one myself?

Joe

On May 8, 2019, at 2:31 PM, Nick Foster  wrote:

Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
way to figure out what image is loaded other than asking UHD to query it
for FPGA compat number.

On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:


I guess the proper way to ask is “Is there a way to determine what fpga
.bin file is in the N210?”, since the .bit file that I loaded into the fpga
is volatile code that disappears upon power cycling to be reloaded from an
EEPROM or something, yes?

Joe

On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

Hi Nick,

Thanks for the comments.  Is there a way to determine what bit file is
currently in the N210?  If so, how please?

Joe

On May 8, 2019, at 1:33 PM, Nick Foster  wrote:

I see you got there already! If you're still having trouble, I'll see
what I can dig up over here.

On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:


You might be best off reverting to a UHD old enough to support the
bitfile currently loaded on your N210. You could then bootstrap your N210
by using the old UHD to load a newer FPGA image.

Otherwise, it's fairly simple to convert the binfiles (which still exist
-- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
usrp_n210_r3_fpga.bit and just stick it onto the front of
usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
header is everything up until FF FF FF FF AA 99 55 66.

Lastly, the source is all there, so building using ISE should still be
possible.

Nick

On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:


Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
email adr can be of use.

Joe

On May 8, 2019, at 10:44 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

Joe, I think you might be SOL.  If you take a look at this thread from
me last year, I had no luck:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html


Also, when I pinged Ettus directly, here is some info I got back from
them (from two different emails in the thread):
"we've been having some trouble tracking down Rev2 bitfiles, because no
one here was around when that was built. If you're trying to unbrick
them, Rev3 bitfiles might be OK, but I'm not completely sure.

supp...@ettus.com might know more by know.
really sorry, but those Rev2s are just so old. And all the people from
that era seem to be gone. Sorry, can't help you with those Rev2s."

--
*From:* USRP-users  on behalf of
Joe Martin via USRP-users 
*Sent:* Wednesday, May 8, 2019 11:55 AM
*To:* Joe Martin via 

Re: [USRP-users] Relationship between IQ values, gain and noise on B205mini transmitter

[Brian Padalino via USRP-users]

On Wed, May 8, 2019 at 7:28 PM Michael Deacon via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> I have a simple transmitter consisting of a file source connected to a
> USRP sink (attached image radio.png). The file contains interleaved
> floating point IQ representing a few seconds of LTE. The IQ amplitude
> values are normalized between +1.0 and -1.0. The sink is configured to
> 60db, 7.5MHz sample rate, 385MHz center frequency and 5MHz bandwidth. The
> output looks exactly like the original on a spectrum analyzer (see attached
> good.jpg). If I turn up the gain on the sink or increase the amplitude of
> the IQ data I get what looks to be noise on either side of the signal
> spectrum (see attached bad.jpg). Any idea what is going on here?
>

Your bad.jpg picture has the spectrum analyzer saying OLVD.  Try changing
your reference level of the spectrum analyzer to be higher so you don't
saturate the input of the spectrum analyzer.

Tell us if that fixes it for you.

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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Thanks Philip, I’ll check out the precompiled versions on the link Robin 
provided, to see if they go back far enough first.  I tried the 3.9.0 so I’m 
thinking 3.8.x might still be too recent but if none of these work perhaps I 
can ask you to take a look for something earlier.  Thanks! 

Joe

> On May 8, 2019, at 4:02 PM, Philip Balister  wrote:
> 
> I've got the 3.8.4 images zipfile lying around in my OE download
> directory, if it helps I can put it on dropbox. I might be able to find
> some older ones if needed.
> 
> Yeah, I save ancient source in case of a GPL compliance exercise :)
> 
> Philip
> 
> On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:
>> You could try using the .deb or .rpm pre-built binaries if you're running
>> on Linux.  See, for instance:
>> http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/
>> 
>> On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> 
>>> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
>>> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
>>> complains that it is expecting compatibility number 11 but is receiving 6.
>>> So I think that means I need an earlier version of UHD than 3.9.0.
>>> 
>>> I will dig into the earliest version in the git tag -l, namely
>>> 003_007_002_rc1, that would not build without errors and try to work out
>>> the compiler errors then.  Unless someone has a better idea to try.
>>> Thanks!
>>> 
>>> Regards,
>>> 
>>> Joe
>>> 
>>> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>> 
>>> Okay, thanks, that’s what I thought but that isn’t useful for me until I
>>> find a UHD version that can communicate with it.  I’ve been trying to build
>>> older UHD versions from 003_007_002_rc1 forward but all so far fail to
>>> build due to compiler errors.  Am up to 003_008_005_rc1 now, moving forward
>>> until I can successfully build one to try.  Are there any old pre-built
>>> versions I could simply try without having to build each one myself?
>>> 
>>> Joe
>>> 
>>> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
>>> 
>>> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
>>> way to figure out what image is loaded other than asking UHD to query it
>>> for FPGA compat number.
>>> 
>>> On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:
>>> 
 I guess the proper way to ask is “Is there a way to determine what fpga
 .bin file is in the N210?”, since the .bit file that I loaded into the fpga
 is volatile code that disappears upon power cycling to be reloaded from an
 EEPROM or something, yes?
 
 Joe
 
 On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
 usrp-users@lists.ettus.com> wrote:
 
 Hi Nick,
 
 Thanks for the comments.  Is there a way to determine what bit file is
 currently in the N210?  If so, how please?
 
 Joe
 
 On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
 
 I see you got there already! If you're still having trouble, I'll see
 what I can dig up over here.
 
 On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
 
> You might be best off reverting to a UHD old enough to support the
> bitfile currently loaded on your N210. You could then bootstrap your N210
> by using the old UHD to load a newer FPGA image.
> 
> Otherwise, it's fairly simple to convert the binfiles (which still exist
> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
> usrp_n210_r3_fpga.bit and just stick it onto the front of
> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
> header is everything up until FF FF FF FF AA 99 55 66.
> 
> Lastly, the source is all there, so building using ISE should still be
> possible.
> 
> Nick
> 
> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
>> Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
>> email adr can be of use.
>> 
>> Joe
>> 
>> On May 8, 2019, at 10:44 AM, Jason Matusiak <
>> ja...@gardettoengineering.com> wrote:
>> 
>> Joe, I think you might be SOL.  If you take a look at this thread from
>> me last year, I had no luck:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>> 
>> 
>> Also, when I pinged Ettus directly, here is some info I got back from
>> them (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>> 
>> supp...@ettus.com might know more by know.
>> really sorry, but 

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Ah, okay, thanks!  I’ll give them a try to see if it makes any difference.

Joe

> On May 8, 2019, at 3:40 PM, Robin Coxe  wrote:
> 
> You could try using the .deb or .rpm pre-built binaries if you're running on 
> Linux.  See, for instance:
> http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/ 
>   
> 
> On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did 
> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still 
> complains that it is expecting compatibility number 11 but is receiving 6.  
> So I think that means I need an earlier version of UHD than 3.9.0.  
> 
> I will dig into the earliest version in the git tag -l, namely 
> 003_007_002_rc1, that would not build without errors and try to work out the 
> compiler errors then.  Unless someone has a better idea to try.   Thanks!
> 
> Regards, 
> 
> Joe
> 
>> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Okay, thanks, that’s what I thought but that isn’t useful for me until I 
>> find a UHD version that can communicate with it.  I’ve been trying to build 
>> older UHD versions from 003_007_002_rc1 forward but all so far fail to build 
>> due to compiler errors.  Am up to 003_008_005_rc1 now, moving forward until 
>> I can successfully build one to try.  Are there any old pre-built versions I 
>> could simply try without having to build each one myself?
>> 
>> Joe
>> 
>>> On May 8, 2019, at 2:31 PM, Nick Foster >> > wrote:
>>> 
>>> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy 
>>> way to figure out what image is loaded other than asking UHD to query it 
>>> for FPGA compat number.
>>> 
>>> On Wed, May 8, 2019 at 1:04 PM Joe Martin >> > wrote:
>>> I guess the proper way to ask is “Is there a way to determine what fpga 
>>> .bin file is in the N210?”, since the .bit file that I loaded into the fpga 
>>> is volatile code that disappears upon power cycling to be reloaded from an 
>>> EEPROM or something, yes?
>>> 
>>> Joe
>>> 
 On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users 
 mailto:usrp-users@lists.ettus.com>> wrote:
 
 Hi Nick, 
 
 Thanks for the comments.  Is there a way to determine what bit file is 
 currently in the N210?  If so, how please?
 
 Joe
 
> On May 8, 2019, at 1:33 PM, Nick Foster  > wrote:
> 
> I see you got there already! If you're still having trouble, I'll see 
> what I can dig up over here.
> 
> On Wed, May 8, 2019 at 12:31 PM Nick Foster  > wrote:
> You might be best off reverting to a UHD old enough to support the 
> bitfile currently loaded on your N210. You could then bootstrap your N210 
> by using the old UHD to load a newer FPGA image.
> 
> Otherwise, it's fairly simple to convert the binfiles (which still exist 
> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from 
> usrp_n210_r3_fpga.bit and just stick it onto the front of 
> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The 
> header is everything up until FF FF FF FF AA 99 55 66.
> 
> Lastly, the source is all there, so building using ISE should still be 
> possible.
> 
> Nick
> 
> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, 
> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email 
> adr can be of use.  
> 
> Joe
> 
>> On May 8, 2019, at 10:44 AM, Jason Matusiak 
>> mailto:ja...@gardettoengineering.com>> 
>> wrote:
>> 
>> Joe, I think you might be SOL.  If you take a look at this thread from 
>> me last year, I had no luck: 
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>  
>> 
>> 
>> 
>> Also, when I pinged Ettus directly, here is some info I got back from 
>> them (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>> 
>> supp...@ettus.com  might know more by know.
>> really sorry, but those Rev2s are just so old. And all the people from
>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>> 
>> From: USRP-users > 

[USRP-users] Burst Tagging with B205-mini/B210

[Krishna Makhija via USRP-users]

Hello,

I'm trying to implement a burst transmitter with the B205-mini. I would
like to set it to transmit a sine wave, phase modulated wave, or arbitrary
waveform for a given duration and stop for set duration. Repeat for several
bursts and then terminate program. It is crucial that the bursts are
in-phase with each other across bursts and initializations.

On the receiver side I am hoping to use a B210 to receive the bursts and
record only the burst data. It appears the Tagged File Sink within GNU
Radio is ideal for this. I would like to tag the burst ON data from the
transmitter side and have the receiver begin saving only those data. I have
simulated that using GNU Radio only and it works fine (see
pulsed_signal_simulation.grc). However, when I try to implement the same
thing using USRP (B205-mini) I see no tags on the receiver side (see
pulsed_signal_SDR.grc). As you can see, the signal is indeed pulsed at a
duty cycle/rate that I choose and is phase-consistent. The B205-mini was
set in loopback mode for my tests. Questions:

1. How does one set a tag using a USRP? I tried setting tx_sob and tx_eob
tags using similar methods and I could not get those to work either. Can
one do this in GRC?
2. Is it possible to set "custom" tags such as "burst" in UHD?
Alternatively, can I define another custom tag and then modify the Tagged
File Sink to parse for that tag and only save those data?

Sorry for the long email. Thanks in advance.

Regards,
Krishna Makhija


pulsed_signal_simulation.grc
Description: Binary data


pulsed_signal_SDR.grc
Description: Binary data
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Philip Balister via USRP-users]

I've got the 3.8.4 images zipfile lying around in my OE download
directory, if it helps I can put it on dropbox. I might be able to find
some older ones if needed.

Yeah, I save ancient source in case of a GPL compliance exercise :)

Philip

On 05/08/2019 05:40 PM, Robin Coxe via USRP-users wrote:
> You could try using the .deb or .rpm pre-built binaries if you're running
> on Linux.  See, for instance:
> http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/
> 
> On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> 
>> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
>> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
>> complains that it is expecting compatibility number 11 but is receiving 6.
>> So I think that means I need an earlier version of UHD than 3.9.0.
>>
>> I will dig into the earliest version in the git tag -l, namely
>> 003_007_002_rc1, that would not build without errors and try to work out
>> the compiler errors then.  Unless someone has a better idea to try.
>> Thanks!
>>
>> Regards,
>>
>> Joe
>>
>> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Okay, thanks, that’s what I thought but that isn’t useful for me until I
>> find a UHD version that can communicate with it.  I’ve been trying to build
>> older UHD versions from 003_007_002_rc1 forward but all so far fail to
>> build due to compiler errors.  Am up to 003_008_005_rc1 now, moving forward
>> until I can successfully build one to try.  Are there any old pre-built
>> versions I could simply try without having to build each one myself?
>>
>> Joe
>>
>> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
>>
>> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
>> way to figure out what image is loaded other than asking UHD to query it
>> for FPGA compat number.
>>
>> On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:
>>
>>> I guess the proper way to ask is “Is there a way to determine what fpga
>>> .bin file is in the N210?”, since the .bit file that I loaded into the fpga
>>> is volatile code that disappears upon power cycling to be reloaded from an
>>> EEPROM or something, yes?
>>>
>>> Joe
>>>
>>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>> Hi Nick,
>>>
>>> Thanks for the comments.  Is there a way to determine what bit file is
>>> currently in the N210?  If so, how please?
>>>
>>> Joe
>>>
>>> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>>>
>>> I see you got there already! If you're still having trouble, I'll see
>>> what I can dig up over here.
>>>
>>> On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
>>>
 You might be best off reverting to a UHD old enough to support the
 bitfile currently loaded on your N210. You could then bootstrap your N210
 by using the old UHD to load a newer FPGA image.

 Otherwise, it's fairly simple to convert the binfiles (which still exist
 -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
 usrp_n210_r3_fpga.bit and just stick it onto the front of
 usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
 header is everything up until FF FF FF FF AA 99 55 66.

 Lastly, the source is all there, so building using ISE should still be
 possible.

 Nick

 On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
> Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
> email adr can be of use.
>
> Joe
>
> On May 8, 2019, at 10:44 AM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
> Joe, I think you might be SOL.  If you take a look at this thread from
> me last year, I had no luck:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>
>
> Also, when I pinged Ettus directly, here is some info I got back from
> them (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>
> supp...@ettus.com might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
>
> --
> *From:* USRP-users  on behalf of
> Joe Martin via USRP-users 
> *Sent:* Wednesday, May 8, 2019 11:55 AM
> *To:* Joe Martin via USRP-users
> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
> current firmware/fpga images
>
> I am trying to bring an elderly N210 r2.0 with unknown 

Re: [USRP-users] Running E310 in Network Mode

[Chris Gobbett via USRP-users]

Also Ramazan note that even then you will still get far reduced
bandwidth as compared to N210/B210 over ethernet or USB:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/041697.html
[1]
If cutting FPGA code isn't an option but you wish to have a larger
bandwidth with the small form-factor, perhaps something like the B200
mini might suffice?- Original Message -From: "Jason Matusiak" 
To:"usrp-users@lists.ettus.com" , "Ramazan Çetin" 
Cc:
Sent:Wed, 8 May 2019 14:14:46 +
Subject:Re: [USRP-users] Running E310 in Network Mode

 See
here: https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
[2] 

-
FROM: USRP-users  on behalf of Ramazan Çetin via USRP-users 
SENT: Wednesday, May 8, 2019 8:02 AM
TO: Ettus Research Support; usrp-users@lists.ettus.com
SUBJECT: [USRP-users] Running E310 in Network Mode     Hello,

 We want to run USRP E310 in network mode. I think the samples coming 
 from FPGA passing through CPU before sending to network. This
decreases 
 bandwidth because of CPU limitations.

 So, is there any ettus image or suggestions that we can run E310 
 directly from FPGA to network without speed limitations? (like N210
or B210)

 Best regards.

 Ramazan

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


Links:
--
[1]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-April/041697.html
[2]
https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
[3] 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] Bringing an elderly N210 to life by loading current firmware/fpga images

[Robin Coxe via USRP-users]

You could try using the .deb or .rpm pre-built binaries if you're running
on Linux.  See, for instance:
http://files.ettus.com/binaries/uhd/uhd_003.004.000-release/

On Wed, May 8, 2019 at 2:09 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did
> before (“Received invalid reply 32 from device”) and uhd_usrp_probe still
> complains that it is expecting compatibility number 11 but is receiving 6.
> So I think that means I need an earlier version of UHD than 3.9.0.
>
> I will dig into the earliest version in the git tag -l, namely
> 003_007_002_rc1, that would not build without errors and try to work out
> the compiler errors then.  Unless someone has a better idea to try.
> Thanks!
>
> Regards,
>
> Joe
>
> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Okay, thanks, that’s what I thought but that isn’t useful for me until I
> find a UHD version that can communicate with it.  I’ve been trying to build
> older UHD versions from 003_007_002_rc1 forward but all so far fail to
> build due to compiler errors.  Am up to 003_008_005_rc1 now, moving forward
> until I can successfully build one to try.  Are there any old pre-built
> versions I could simply try without having to build each one myself?
>
> Joe
>
> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
>
> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
> way to figure out what image is loaded other than asking UHD to query it
> for FPGA compat number.
>
> On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:
>
>> I guess the proper way to ask is “Is there a way to determine what fpga
>> .bin file is in the N210?”, since the .bit file that I loaded into the fpga
>> is volatile code that disappears upon power cycling to be reloaded from an
>> EEPROM or something, yes?
>>
>> Joe
>>
>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hi Nick,
>>
>> Thanks for the comments.  Is there a way to determine what bit file is
>> currently in the N210?  If so, how please?
>>
>> Joe
>>
>> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>>
>> I see you got there already! If you're still having trouble, I'll see
>> what I can dig up over here.
>>
>> On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
>>
>>> You might be best off reverting to a UHD old enough to support the
>>> bitfile currently loaded on your N210. You could then bootstrap your N210
>>> by using the old UHD to load a newer FPGA image.
>>>
>>> Otherwise, it's fairly simple to convert the binfiles (which still exist
>>> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
>>> usrp_n210_r3_fpga.bit and just stick it onto the front of
>>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
>>> header is everything up until FF FF FF FF AA 99 55 66.
>>>
>>> Lastly, the source is all there, so building using ISE should still be
>>> possible.
>>>
>>> Nick
>>>
>>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
 Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
 email adr can be of use.

 Joe

 On May 8, 2019, at 10:44 AM, Jason Matusiak <
 ja...@gardettoengineering.com> wrote:

 Joe, I think you might be SOL.  If you take a look at this thread from
 me last year, I had no luck:
 http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html


 Also, when I pinged Ettus directly, here is some info I got back from
 them (from two different emails in the thread):
 "we've been having some trouble tracking down Rev2 bitfiles, because no
 one here was around when that was built. If you're trying to unbrick
 them, Rev3 bitfiles might be OK, but I'm not completely sure.

 supp...@ettus.com might know more by know.
 really sorry, but those Rev2s are just so old. And all the people from
 that era seem to be gone. Sorry, can't help you with those Rev2s."

 --
 *From:* USRP-users  on behalf of
 Joe Martin via USRP-users 
 *Sent:* Wednesday, May 8, 2019 11:55 AM
 *To:* Joe Martin via USRP-users
 *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
 current firmware/fpga images

 I am trying to bring an elderly N210 r2.0 with unknown history to life
 by loading current UHD firmware and fpga images from a 1Gigabit ethernet
 connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
 UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.

 Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
 and N2x0 Series”:

 My initial action was to load the “usrp_n210_r4_fpga.bit" file into the

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

I’ve successfully built UHD v3.9.0 but it has the same error as 3.14.0 did 
before (“Received invalid reply 32 from device”) and uhd_usrp_probe still 
complains that it is expecting compatibility number 11 but is receiving 6.  So 
I think that means I need an earlier version of UHD than 3.9.0.  

I will dig into the earliest version in the git tag -l, namely 003_007_002_rc1, 
that would not build without errors and try to work out the compiler errors 
then.  Unless someone has a better idea to try.   Thanks!

Regards, 

Joe

> On May 8, 2019, at 2:40 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Okay, thanks, that’s what I thought but that isn’t useful for me until I find 
> a UHD version that can communicate with it.  I’ve been trying to build older 
> UHD versions from 003_007_002_rc1 forward but all so far fail to build due to 
> compiler errors.  Am up to 003_008_005_rc1 now, moving forward until I can 
> successfully build one to try.  Are there any old pre-built versions I could 
> simply try without having to build each one myself?
> 
> Joe
> 
>> On May 8, 2019, at 2:31 PM, Nick Foster > > wrote:
>> 
>> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy 
>> way to figure out what image is loaded other than asking UHD to query it for 
>> FPGA compat number.
>> 
>> On Wed, May 8, 2019 at 1:04 PM Joe Martin > > wrote:
>> I guess the proper way to ask is “Is there a way to determine what fpga .bin 
>> file is in the N210?”, since the .bit file that I loaded into the fpga is 
>> volatile code that disappears upon power cycling to be reloaded from an 
>> EEPROM or something, yes?
>> 
>> Joe
>> 
>>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> Hi Nick, 
>>> 
>>> Thanks for the comments.  Is there a way to determine what bit file is 
>>> currently in the N210?  If so, how please?
>>> 
>>> Joe
>>> 
 On May 8, 2019, at 1:33 PM, Nick Foster >>> > wrote:
 
 I see you got there already! If you're still having trouble, I'll see what 
 I can dig up over here.
 
 On Wed, May 8, 2019 at 12:31 PM Nick Foster >>> > wrote:
 You might be best off reverting to a UHD old enough to support the bitfile 
 currently loaded on your N210. You could then bootstrap your N210 by using 
 the old UHD to load a newer FPGA image.
 
 Otherwise, it's fairly simple to convert the binfiles (which still exist 
 -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from 
 usrp_n210_r3_fpga.bit and just stick it onto the front of 
 usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The 
 header is everything up until FF FF FF FF AA 99 55 66.
 
 Lastly, the source is all there, so building using ISE should still be 
 possible.
 
 Nick
 
 On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users 
 mailto:usrp-users@lists.ettus.com>> wrote:
 Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, 
 the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email 
 adr can be of use.  
 
 Joe
 
> On May 8, 2019, at 10:44 AM, Jason Matusiak 
> mailto:ja...@gardettoengineering.com>> 
> wrote:
> 
> Joe, I think you might be SOL.  If you take a look at this thread from me 
> last year, I had no luck: 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>  
> 
> 
> 
> Also, when I pinged Ettus directly, here is some info I got back from 
> them (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
> 
> supp...@ettus.com  might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
> 
> From: USRP-users  > on behalf of Joe Martin via 
> USRP-users  >
> Sent: Wednesday, May 8, 2019 11:55 AM
> To: Joe Martin via USRP-users
> Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
> firmware/fpga images
>  
> I am trying to bring an elderly N210 r2.0 with unknown history to life by 
> loading current UHD firmware and fpga images from a 1Gigabit ethernet 
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with 
> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
> 
> Following instructions in 

Re: [USRP-users] USRP N320 and N321 questions

[Marcus D. Leech via USRP-users]

On 05/08/2019 04:55 PM, Minutolo, Lorenzo (389I) via USRP-users wrote:

Hi,
I have some question about your new products.

1) What is the suggested hardware for communicating with the QSFP+ port? As I 
understand this a normal 40 Gbit PCIe card won’t work.

2) Does the embedded linux system gives any error while handling two channels 
at 200Msps full duplex without any signal processing (i.e. benchmark rate)?
I'm going to go ahead and guess that an 800MHz CPU would be unable to 
consume 400Msps in any possible way, since that would imply an
  average of only 2 CPU clocks/sample. Even just bringing those samples 
into the CPU realm and into user-space would be some kind of

  minor miracle, even with multiple instruction issues/clock.






Lorenzo
___
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] USRP N320 and N321 questions

[Minutolo, Lorenzo (389I) via USRP-users]

Hi,
I have some question about your new products.

1) What is the suggested hardware for communicating with the QSFP+ port? As I 
understand this a normal 40 Gbit PCIe card won’t work.

2) Does the embedded linux system gives any error while handling two channels 
at 200Msps full duplex without any signal processing (i.e. benchmark rate)?

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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Okay, thanks, that’s what I thought but that isn’t useful for me until I find a 
UHD version that can communicate with it.  I’ve been trying to build older UHD 
versions from 003_007_002_rc1 forward but all so far fail to build due to 
compiler errors.  Am up to 003_008_005_rc1 now, moving forward until I can 
successfully build one to try.  Are there any old pre-built versions I could 
simply try without having to build each one myself?

Joe

> On May 8, 2019, at 2:31 PM, Nick Foster  wrote:
> 
> Yes, code loaded over JTAG is gone at next boot. I can't think of an easy way 
> to figure out what image is loaded other than asking UHD to query it for FPGA 
> compat number.
> 
> On Wed, May 8, 2019 at 1:04 PM Joe Martin  > wrote:
> I guess the proper way to ask is “Is there a way to determine what fpga .bin 
> file is in the N210?”, since the .bit file that I loaded into the fpga is 
> volatile code that disappears upon power cycling to be reloaded from an 
> EEPROM or something, yes?
> 
> Joe
> 
>> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Hi Nick, 
>> 
>> Thanks for the comments.  Is there a way to determine what bit file is 
>> currently in the N210?  If so, how please?
>> 
>> Joe
>> 
>>> On May 8, 2019, at 1:33 PM, Nick Foster >> > wrote:
>>> 
>>> I see you got there already! If you're still having trouble, I'll see what 
>>> I can dig up over here.
>>> 
>>> On Wed, May 8, 2019 at 12:31 PM Nick Foster >> > wrote:
>>> You might be best off reverting to a UHD old enough to support the bitfile 
>>> currently loaded on your N210. You could then bootstrap your N210 by using 
>>> the old UHD to load a newer FPGA image.
>>> 
>>> Otherwise, it's fairly simple to convert the binfiles (which still exist -- 
>>> usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from 
>>> usrp_n210_r3_fpga.bit and just stick it onto the front of 
>>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The 
>>> header is everything up until FF FF FF FF AA 99 55 66.
>>> 
>>> Lastly, the source is all there, so building using ISE should still be 
>>> possible.
>>> 
>>> Nick
>>> 
>>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, 
>>> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email 
>>> adr can be of use.  
>>> 
>>> Joe
>>> 
 On May 8, 2019, at 10:44 AM, Jason Matusiak >>> > wrote:
 
 Joe, I think you might be SOL.  If you take a look at this thread from me 
 last year, I had no luck: 
 http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
  
 
 
 
 Also, when I pinged Ettus directly, here is some info I got back from them 
 (from two different emails in the thread):
 "we've been having some trouble tracking down Rev2 bitfiles, because no
 one here was around when that was built. If you're trying to unbrick
 them, Rev3 bitfiles might be OK, but I'm not completely sure.
 
 supp...@ettus.com  might know more by know.
 really sorry, but those Rev2s are just so old. And all the people from
 that era seem to be gone. Sorry, can't help you with those Rev2s."
 
 From: USRP-users >>> > on behalf of Joe Martin via 
 USRP-users mailto:usrp-users@lists.ettus.com>>
 Sent: Wednesday, May 8, 2019 11:55 AM
 To: Joe Martin via USRP-users
 Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
 firmware/fpga images
  
 I am trying to bring an elderly N210 r2.0 with unknown history to life by 
 loading current UHD firmware and fpga images from a 1Gigabit ethernet 
 connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with 
 UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
 
 Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and 
 N2x0 Series”:
 
 My initial action was to load the “usrp_n210_r4_fpga.bit" file into the 
 N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming 
 cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program 
 Succeeded” for the action.  Ethernet LEDs on the N210 are variously 
 lighted showing activity on the connection port.
 
 With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
 following commands result in the responses shown in the screenshot image 
 below: 
 
 
 
 My (naive!) interpretation of the above responses is that the FPGA may not 
 actually have been programmed with 

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Nick Foster via USRP-users]

Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
way to figure out what image is loaded other than asking UHD to query it
for FPGA compat number.

On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:

> I guess the proper way to ask is “Is there a way to determine what fpga
> .bin file is in the N210?”, since the .bit file that I loaded into the fpga
> is volatile code that disappears upon power cycling to be reloaded from an
> EEPROM or something, yes?
>
> Joe
>
> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Nick,
>
> Thanks for the comments.  Is there a way to determine what bit file is
> currently in the N210?  If so, how please?
>
> Joe
>
> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>
> I see you got there already! If you're still having trouble, I'll see what
> I can dig up over here.
>
> On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
>
>> You might be best off reverting to a UHD old enough to support the
>> bitfile currently loaded on your N210. You could then bootstrap your N210
>> by using the old UHD to load a newer FPGA image.
>>
>> Otherwise, it's fairly simple to convert the binfiles (which still exist
>> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
>> usrp_n210_r3_fpga.bit and just stick it onto the front of
>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
>> header is everything up until FF FF FF FF AA 99 55 66.
>>
>> Lastly, the source is all there, so building using ISE should still be
>> possible.
>>
>> Nick
>>
>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
>>> Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
>>> email adr can be of use.
>>>
>>> Joe
>>>
>>> On May 8, 2019, at 10:44 AM, Jason Matusiak <
>>> ja...@gardettoengineering.com> wrote:
>>>
>>> Joe, I think you might be SOL.  If you take a look at this thread from
>>> me last year, I had no luck:
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>>
>>>
>>> Also, when I pinged Ettus directly, here is some info I got back from
>>> them (from two different emails in the thread):
>>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>>> one here was around when that was built. If you're trying to unbrick
>>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>>>
>>> supp...@ettus.com might know more by know.
>>> really sorry, but those Rev2s are just so old. And all the people from
>>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>>>
>>> --
>>> *From:* USRP-users  on behalf of
>>> Joe Martin via USRP-users 
>>> *Sent:* Wednesday, May 8, 2019 11:55 AM
>>> *To:* Joe Martin via USRP-users
>>> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
>>> current firmware/fpga images
>>>
>>> I am trying to bring an elderly N210 r2.0 with unknown history to life
>>> by loading current UHD firmware and fpga images from a 1Gigabit ethernet
>>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
>>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>>>
>>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
>>> and N2x0 Series”:
>>>
>>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
>>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
>>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
>>> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
>>> showing activity on the connection port.
>>>
>>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
>>> following commands result in the responses shown in the screenshot image
>>> below:
>>>
>>> 
>>>
>>> My (naive!) interpretation of the above responses is that the FPGA may
>>> not actually have been programmed with the *.bit code even though iMPACT
>>> reported success in programming.  Can someone assist me in understanding
>>> whether my interpretation is correct or not and, most importantly, suggest
>>> what I might try next to bring this N210 to life?
>>>
>>> The “Please run:” suggestion results in the “Received invalid reply 32
>>> from device” error.  It seems no matter what I try the “Received invalid
>>> reply 32 from device” RuntimeError is reported back when I try to load any
>>> new firmware/FPGA images.
>>>
>>> Thanks!
>>>
>>> Joe
>>>
>>>
>>> ___
>>> 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] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

I guess the proper way to ask is “Is there a way to determine what fpga .bin 
file is in the N210?”, since the .bit file that I loaded into the fpga is 
volatile code that disappears upon power cycling to be reloaded from an EEPROM 
or something, yes?

Joe

> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Hi Nick, 
> 
> Thanks for the comments.  Is there a way to determine what bit file is 
> currently in the N210?  If so, how please?
> 
> Joe
> 
>> On May 8, 2019, at 1:33 PM, Nick Foster > > wrote:
>> 
>> I see you got there already! If you're still having trouble, I'll see what I 
>> can dig up over here.
>> 
>> On Wed, May 8, 2019 at 12:31 PM Nick Foster > > wrote:
>> You might be best off reverting to a UHD old enough to support the bitfile 
>> currently loaded on your N210. You could then bootstrap your N210 by using 
>> the old UHD to load a newer FPGA image.
>> 
>> Otherwise, it's fairly simple to convert the binfiles (which still exist -- 
>> usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from 
>> usrp_n210_r3_fpga.bit and just stick it onto the front of 
>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The header 
>> is everything up until FF FF FF FF AA 99 55 66.
>> 
>> Lastly, the source is all there, so building using ISE should still be 
>> possible.
>> 
>> Nick
>> 
>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, 
>> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email adr 
>> can be of use.  
>> 
>> Joe
>> 
>>> On May 8, 2019, at 10:44 AM, Jason Matusiak >> > wrote:
>>> 
>>> Joe, I think you might be SOL.  If you take a look at this thread from me 
>>> last year, I had no luck: 
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>>  
>>> 
>>> 
>>> 
>>> Also, when I pinged Ettus directly, here is some info I got back from them 
>>> (from two different emails in the thread):
>>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>>> one here was around when that was built. If you're trying to unbrick
>>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>>> 
>>> supp...@ettus.com  might know more by know.
>>> really sorry, but those Rev2s are just so old. And all the people from
>>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>>> 
>>> From: USRP-users >> > on behalf of Joe Martin via 
>>> USRP-users mailto:usrp-users@lists.ettus.com>>
>>> Sent: Wednesday, May 8, 2019 11:55 AM
>>> To: Joe Martin via USRP-users
>>> Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
>>> firmware/fpga images
>>>  
>>> I am trying to bring an elderly N210 r2.0 with unknown history to life by 
>>> loading current UHD firmware and fpga images from a 1Gigabit ethernet 
>>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with 
>>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
>>> 
>>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and 
>>> N2x0 Series”:
>>> 
>>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the 
>>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming 
>>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program 
>>> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted 
>>> showing activity on the connection port.
>>> 
>>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
>>> following commands result in the responses shown in the screenshot image 
>>> below: 
>>> 
>>> 
>>> 
>>> My (naive!) interpretation of the above responses is that the FPGA may not 
>>> actually have been programmed with the *.bit code even though iMPACT 
>>> reported success in programming.  Can someone assist me in understanding 
>>> whether my interpretation is correct or not and, most importantly, suggest 
>>> what I might try next to bring this N210 to life?  
>>> 
>>> The “Please run:” suggestion results in the “Received invalid reply 32 from 
>>> device” error.  It seems no matter what I try the “Received invalid reply 
>>> 32 from device” RuntimeError is reported back when I try to load any new 
>>> firmware/FPGA images.  
>>> 
>>> Thanks!
>>> 
>>> Joe
>> 
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com 
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 
>> 
> 
> ___
> 

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Hi Nick, 

Thanks for the comments.  Is there a way to determine what bit file is 
currently in the N210?  If so, how please?

Joe

> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
> 
> I see you got there already! If you're still having trouble, I'll see what I 
> can dig up over here.
> 
> On Wed, May 8, 2019 at 12:31 PM Nick Foster  > wrote:
> You might be best off reverting to a UHD old enough to support the bitfile 
> currently loaded on your N210. You could then bootstrap your N210 by using 
> the old UHD to load a newer FPGA image.
> 
> Otherwise, it's fairly simple to convert the binfiles (which still exist -- 
> usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from 
> usrp_n210_r3_fpga.bit and just stick it onto the front of 
> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The header 
> is everything up until FF FF FF FF AA 99 55 66.
> 
> Lastly, the source is all there, so building using ISE should still be 
> possible.
> 
> Nick
> 
> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, the 
> Rev3 bit file doesn’t work; tried it.  I’ll see if the support email adr can 
> be of use.  
> 
> Joe
> 
>> On May 8, 2019, at 10:44 AM, Jason Matusiak > > wrote:
>> 
>> Joe, I think you might be SOL.  If you take a look at this thread from me 
>> last year, I had no luck: 
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>  
>> 
>> 
>> 
>> Also, when I pinged Ettus directly, here is some info I got back from them 
>> (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>> 
>> supp...@ettus.com  might know more by know.
>> really sorry, but those Rev2s are just so old. And all the people from
>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>> 
>> From: USRP-users > > on behalf of Joe Martin via 
>> USRP-users mailto:usrp-users@lists.ettus.com>>
>> Sent: Wednesday, May 8, 2019 11:55 AM
>> To: Joe Martin via USRP-users
>> Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
>> firmware/fpga images
>>  
>> I am trying to bring an elderly N210 r2.0 with unknown history to life by 
>> loading current UHD firmware and fpga images from a 1Gigabit ethernet 
>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with UHD 
>> 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
>> 
>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and 
>> N2x0 Series”:
>> 
>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the N210 
>> xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming cable 
>> from a Win7 PC running Xilinx ISE iMPACT, which reported “Program Succeeded” 
>> for the action.  Ethernet LEDs on the N210 are variously lighted showing 
>> activity on the connection port.
>> 
>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
>> following commands result in the responses shown in the screenshot image 
>> below: 
>> 
>> 
>> 
>> My (naive!) interpretation of the above responses is that the FPGA may not 
>> actually have been programmed with the *.bit code even though iMPACT 
>> reported success in programming.  Can someone assist me in understanding 
>> whether my interpretation is correct or not and, most importantly, suggest 
>> what I might try next to bring this N210 to life?  
>> 
>> The “Please run:” suggestion results in the “Received invalid reply 32 from 
>> device” error.  It seems no matter what I try the “Received invalid reply 32 
>> from device” RuntimeError is reported back when I try to load any new 
>> firmware/FPGA images.  
>> 
>> Thanks!
>> 
>> Joe
> 
> ___
> 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] Bringing an elderly N210 to life by loading current firmware/fpga images

[Nick Foster via USRP-users]

I see you got there already! If you're still having trouble, I'll see what
I can dig up over here.

On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:

> You might be best off reverting to a UHD old enough to support the bitfile
> currently loaded on your N210. You could then bootstrap your N210 by using
> the old UHD to load a newer FPGA image.
>
> Otherwise, it's fairly simple to convert the binfiles (which still exist
> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
> usrp_n210_r3_fpga.bit and just stick it onto the front of
> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
> header is everything up until FF FF FF FF AA 99 55 66.
>
> Lastly, the source is all there, so building using ISE should still be
> possible.
>
> Nick
>
> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
>> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
>> adr can be of use.
>>
>> Joe
>>
>> On May 8, 2019, at 10:44 AM, Jason Matusiak <
>> ja...@gardettoengineering.com> wrote:
>>
>> Joe, I think you might be SOL.  If you take a look at this thread from me
>> last year, I had no luck:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>
>>
>> Also, when I pinged Ettus directly, here is some info I got back from
>> them (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>>
>> supp...@ettus.com might know more by know.
>> really sorry, but those Rev2s are just so old. And all the people from
>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>>
>> --
>> *From:* USRP-users  on behalf of Joe
>> Martin via USRP-users 
>> *Sent:* Wednesday, May 8, 2019 11:55 AM
>> *To:* Joe Martin via USRP-users
>> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
>> current firmware/fpga images
>>
>> I am trying to bring an elderly N210 r2.0 with unknown history to life by
>> loading current UHD firmware and fpga images from a 1Gigabit ethernet
>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>>
>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
>> and N2x0 Series”:
>>
>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
>> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
>> showing activity on the connection port.
>>
>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
>> following commands result in the responses shown in the screenshot image
>> below:
>>
>> 
>>
>> My (naive!) interpretation of the above responses is that the FPGA may
>> not actually have been programmed with the *.bit code even though iMPACT
>> reported success in programming.  Can someone assist me in understanding
>> whether my interpretation is correct or not and, most importantly, suggest
>> what I might try next to bring this N210 to life?
>>
>> The “Please run:” suggestion results in the “Received invalid reply 32
>> from device” error.  It seems no matter what I try the “Received invalid
>> reply 32 from device” RuntimeError is reported back when I try to load any
>> new firmware/FPGA images.
>>
>> Thanks!
>>
>> Joe
>>
>>
>> ___
>> 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] Bringing an elderly N210 to life by loading current firmware/fpga images

[Nick Foster via USRP-users]

You might be best off reverting to a UHD old enough to support the bitfile
currently loaded on your N210. You could then bootstrap your N210 by using
the old UHD to load a newer FPGA image.

Otherwise, it's fairly simple to convert the binfiles (which still exist --
usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
usrp_n210_r3_fpga.bit and just stick it onto the front of
usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
header is everything up until FF FF FF FF AA 99 55 66.

Lastly, the source is all there, so building using ISE should still be
possible.

Nick

On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
> adr can be of use.
>
> Joe
>
> On May 8, 2019, at 10:44 AM, Jason Matusiak 
> wrote:
>
> Joe, I think you might be SOL.  If you take a look at this thread from me
> last year, I had no luck:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>
>
> Also, when I pinged Ettus directly, here is some info I got back from them
> (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>
> supp...@ettus.com might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
>
> --
> *From:* USRP-users  on behalf of Joe
> Martin via USRP-users 
> *Sent:* Wednesday, May 8, 2019 11:55 AM
> *To:* Joe Martin via USRP-users
> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
> current firmware/fpga images
>
> I am trying to bring an elderly N210 r2.0 with unknown history to life by
> loading current UHD firmware and fpga images from a 1Gigabit ethernet
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>
> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and
> N2x0 Series”:
>
> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
> showing activity on the connection port.
>
> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
> following commands result in the responses shown in the screenshot image
> below:
>
> 
>
> My (naive!) interpretation of the above responses is that the FPGA may not
> actually have been programmed with the *.bit code even though iMPACT
> reported success in programming.  Can someone assist me in understanding
> whether my interpretation is correct or not and, most importantly, suggest
> what I might try next to bring this N210 to life?
>
> The “Please run:” suggestion results in the “Received invalid reply 32
> from device” error.  It seems no matter what I try the “Received invalid
> reply 32 from device” RuntimeError is reported back when I try to load any
> new firmware/FPGA images.
>
> Thanks!
>
> Joe
>
>
> ___
> 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] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

FYI, I have created a “usrp_n210_r2_fpga.bit" file by adding the additional 
header to the usrp_n210_r2_fpga.bin file, renamed it, and loaded it into the 
N210’s FPGA.  Will report back on the ability to install an older version of 
UHD than the current version to see if the elderly N210 can be made to come 
alive again using rev2 firmware/fpga images.  

Joe

> On May 8, 2019, at 12:11 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Thanks, Robin, I’ll certainly try that!  
> 
> As I mentioned, we are amenable to running this particular N210 with an old 
> version of UHD to gain some functionality.  
> 
>> On May 8, 2019, at 12:07 PM, Robin Coxe > > wrote:
>> 
>> You might want to try this:  
>> https://forums.xilinx.com/t5/Configuration/Is-it-possible-to-convert-bin-file-to-bit-file-or-mcs-file/td-p/870351
>>  
>> 
>>but YMMV.
>> 
>> -Robin
>> 
>> 
>> On Wed, May 8, 2019 at 11:04 AM Joe Martin > > wrote:
>> Very good, Marcus.  I would greatly appreciate it.
>> 
>> If we can get our hands on the “usrp_n210_r2_fpga.bit” from anywhere we 
>> could load it and install an ancient UHD version that has the associated 
>> .bin files for rev2 and run with that setup to have at least a minimal 
>> amount of utility from the N210, albeit not all the niceties and 
>> functionality of a modern UHD version.  
>> 
>> Thanks Jason, Marcus, and Robin for the information.  Much appreciated.  At 
>> least we know now what we need for this N210 and what to expect from it in 
>> terms of performance if we ever find the .bit file too.  
>> 
>> Best regards to all, 
>> 
>> Joe
>> 
>>> On May 8, 2019, at 11:30 AM, Marcus D. Leech via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> On 05/08/2019 01:24 PM, Robin Coxe wrote:
 Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered that 
 the N210 was first released by Ettus Research in November 2010, which was 
 about 6 months after we were acquired by National Instruments.
 It is a true statement that v2 of the hardware is quite geriatric and no 
 longer supported in modern versions of UHD.   However, all hope is not 
 lost.
 
 There *is* support for N200/N210 in the oldest version of UHD that is 
 still downloadable on files.ettus.com , UHD 
 v.3.8.0.0.   The FPGA images are in this zip file:
 http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip
  
 
 
 We unfortunately don't have a v2 in the office to confirm that it still 
 works, but you might want to take a look.  
 
 -Robin
>>> I'm going to go through some old disk drives on mine from "back in the 
>>> day", and see if I have the r2 .bit files.
>>> 
>>> That can't happen until the weekend, however...
>>> 
>>> 
 
 
 
 On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users 
 mailto:usrp-users@lists.ettus.com>> wrote:
 On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, 
> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email 
> adr can be of use.  
> 
> Joe
> 
 There was a hardware change, as I recall, between Rev2 and Rev3 involving 
 the inputs to the ADCs.
 
 
>> On May 8, 2019, at 10:44 AM, Jason Matusiak 
>> mailto:ja...@gardettoengineering.com>> 
>> wrote:
>> 
>> Joe, I think you might be SOL.  If you take a look at this thread from 
>> me last year, I had no luck: 
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>  
>> 
>> 
>> 
>> Also, when I pinged Ettus directly, here is some info I got back from 
>> them (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>> 
>> supp...@ettus.com  might know more by know.
>> really sorry, but those Rev2s are just so old. And all the people from
>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>> 
>> From: USRP-users > > on behalf of Joe Martin via 
>> USRP-users > >
>> Sent: Wednesday, May 8, 2019 11:55 AM
>> To: Joe Martin via USRP-users
>> Subject: [USRP-users] Bringing an elderly N210 to life by loading 
>> current firmware/fpga images
>>  
>> I am 

[USRP-users] Announcing USRP N320 and N321

[Markus Unger via USRP-users]

Hi USRP Users!



Ettus Research is proud to announce the USRP N320 and USRP N321 software
defined radios (SDRs). These high-performing, stand-alone SDRs deliver
frequency coverage from 3 MHz to 6 GHz with 200 MHz of instantaneous
bandwidth per channel. With reliability and fault tolerance and the ability
to share local oscillators (LO) and multiple synchronization methods, the
USRP N320 and N321 are ideal for deploying phase-coherent wireless systems.



The N320 and N321 feature a Xilinx Zynq-7100 SoC, providing a large user
programmable FPGA for real-time and low-latency processing and a dual-core
ARM CPU for stand-alone operation. Users can deploy applications directly
onto the preinstalled embedded Linux OS or stream samples to a host
computer using high-speed interfaces such as 1 Gigabit Ethernet, 10 Gigabit
Ethernet, and Aurora over two SFP+ ports and a QSFP+ port.



The N320 and N321 will be fully supported in UHD and RFNoC, but LabVIEW
support is not planned at this time. Please check ettus.com or reach out to
Ettus Research/National Instruments directly for more information about
these products!



Thanks!



*Markus Unger* | Principal Product Planner | National Instruments Dresden
GmbH | markus.un...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Thanks, Robin, I’ll certainly try that!  

As I mentioned, we are amenable to running this particular N210 with an old 
version of UHD to gain some functionality.  

> On May 8, 2019, at 12:07 PM, Robin Coxe  wrote:
> 
> You might want to try this:  
> https://forums.xilinx.com/t5/Configuration/Is-it-possible-to-convert-bin-file-to-bit-file-or-mcs-file/td-p/870351
>  
> 
>but YMMV.
> 
> -Robin
> 
> 
> On Wed, May 8, 2019 at 11:04 AM Joe Martin  > wrote:
> Very good, Marcus.  I would greatly appreciate it.
> 
> If we can get our hands on the “usrp_n210_r2_fpga.bit” from anywhere we could 
> load it and install an ancient UHD version that has the associated .bin files 
> for rev2 and run with that setup to have at least a minimal amount of utility 
> from the N210, albeit not all the niceties and functionality of a modern UHD 
> version.  
> 
> Thanks Jason, Marcus, and Robin for the information.  Much appreciated.  At 
> least we know now what we need for this N210 and what to expect from it in 
> terms of performance if we ever find the .bit file too.  
> 
> Best regards to all, 
> 
> Joe
> 
>> On May 8, 2019, at 11:30 AM, Marcus D. Leech via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> On 05/08/2019 01:24 PM, Robin Coxe wrote:
>>> Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered that 
>>> the N210 was first released by Ettus Research in November 2010, which was 
>>> about 6 months after we were acquired by National Instruments.
>>> It is a true statement that v2 of the hardware is quite geriatric and no 
>>> longer supported in modern versions of UHD.   However, all hope is not lost.
>>> 
>>> There *is* support for N200/N210 in the oldest version of UHD that is still 
>>> downloadable on files.ettus.com , UHD v.3.8.0.0.   
>>> The FPGA images are in this zip file:
>>> http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip
>>>  
>>> 
>>> 
>>> We unfortunately don't have a v2 in the office to confirm that it still 
>>> works, but you might want to take a look.  
>>> 
>>> -Robin
>> I'm going to go through some old disk drives on mine from "back in the day", 
>> and see if I have the r2 .bit files.
>> 
>> That can't happen until the weekend, however...
>> 
>> 
>>> 
>>> 
>>> 
>>> On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
 Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, 
 the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email 
 adr can be of use.  
 
 Joe
 
>>> There was a hardware change, as I recall, between Rev2 and Rev3 involving 
>>> the inputs to the ADCs.
>>> 
>>> 
> On May 8, 2019, at 10:44 AM, Jason Matusiak 
> mailto:ja...@gardettoengineering.com>> 
> wrote:
> 
> Joe, I think you might be SOL.  If you take a look at this thread from me 
> last year, I had no luck: 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>  
> 
> 
> 
> Also, when I pinged Ettus directly, here is some info I got back from 
> them (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
> 
> supp...@ettus.com  might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
> 
> From: USRP-users  > on behalf of Joe Martin via 
> USRP-users  >
> Sent: Wednesday, May 8, 2019 11:55 AM
> To: Joe Martin via USRP-users
> Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
> firmware/fpga images
>  
> I am trying to bring an elderly N210 r2.0 with unknown history to life by 
> loading current UHD firmware and fpga images from a 1Gigabit ethernet 
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with 
> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
> 
> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 
> and N2x0 Series”:
> 
> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the 
> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG 
> programming cable 

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Robin Coxe via USRP-users]

You might want to try this:
https://forums.xilinx.com/t5/Configuration/Is-it-possible-to-convert-bin-file-to-bit-file-or-mcs-file/td-p/870351
 but YMMV.

-Robin


On Wed, May 8, 2019 at 11:04 AM Joe Martin  wrote:

> Very good, Marcus.  I would greatly appreciate it.
>
> If we can get our hands on the “usrp_n210_r2_fpga.bit” from anywhere we
> could load it and install an ancient UHD version that has the associated
> .bin files for rev2 and run with that setup to have at least a minimal
> amount of utility from the N210, albeit not all the niceties and
> functionality of a modern UHD version.
>
> Thanks Jason, Marcus, and Robin for the information.  Much appreciated.
> At least we know now what we need for this N210 and what to expect from it
> in terms of performance if we ever find the .bit file too.
>
> Best regards to all,
>
> Joe
>
> On May 8, 2019, at 11:30 AM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> On 05/08/2019 01:24 PM, Robin Coxe wrote:
>
> Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered that
> the N210 was first released by Ettus Research in November 2010, which was
> about 6 months after we were acquired by National Instruments.
> It is a true statement that v2 of the hardware is quite geriatric and no
> longer supported in modern versions of UHD.   However, all hope is not lost.
>
> There *is* support for N200/N210 in the oldest version of UHD that is
> still downloadable on files.ettus.com, UHD v.3.8.0.0.   The FPGA images
> are in this zip file:
>
> http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip
>
> We unfortunately don't have a v2 in the office to confirm that it still
> works, but you might want to take a look.
>
> -Robin
>
> I'm going to go through some old disk drives on mine from "back in the
> day", and see if I have the r2 .bit files.
>
> That can't happen until the weekend, however...
>
>
>
>
>
> On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
>>
>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
>> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
>> adr can be of use.
>>
>> Joe
>>
>> There was a hardware change, as I recall, between Rev2 and Rev3 involving
>> the inputs to the ADCs.
>>
>>
>> On May 8, 2019, at 10:44 AM, Jason Matusiak <
>> ja...@gardettoengineering.com> wrote:
>>
>> Joe, I think you might be SOL.  If you take a look at this thread from me
>> last year, I had no luck:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>
>>
>> Also, when I pinged Ettus directly, here is some info I got back from
>> them (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>>
>> supp...@ettus.com might know more by know.
>> really sorry, but those Rev2s are just so old. And all the people from
>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>>
>> --
>> *From:* USRP-users  on behalf of Joe
>> Martin via USRP-users 
>> *Sent:* Wednesday, May 8, 2019 11:55 AM
>> *To:* Joe Martin via USRP-users
>> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
>> current firmware/fpga images
>>
>> I am trying to bring an elderly N210 r2.0 with unknown history to life by
>> loading current UHD firmware and fpga images from a 1Gigabit ethernet
>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>>
>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
>> and N2x0 Series”:
>>
>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
>> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
>> showing activity on the connection port.
>>
>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
>> following commands result in the responses shown in the screenshot image
>> below:
>>
>> 
>>
>> My (naive!) interpretation of the above responses is that the FPGA may
>> not actually have been programmed with the *.bit code even though iMPACT
>> reported success in programming.  Can someone assist me in understanding
>> whether my interpretation is correct or not and, most importantly, suggest
>> what I might try next to bring this N210 to life?
>>
>> The “Please run:” suggestion results in the “Received invalid reply 32
>> from device” error.  It seems no matter what I try the “Received invalid
>> reply 32 from device” RuntimeError is reported back when I 

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Very good, Marcus.  I would greatly appreciate it.

If we can get our hands on the “usrp_n210_r2_fpga.bit” from anywhere we could 
load it and install an ancient UHD version that has the associated .bin files 
for rev2 and run with that setup to have at least a minimal amount of utility 
from the N210, albeit not all the niceties and functionality of a modern UHD 
version.  

Thanks Jason, Marcus, and Robin for the information.  Much appreciated.  At 
least we know now what we need for this N210 and what to expect from it in 
terms of performance if we ever find the .bit file too.  

Best regards to all, 

Joe

> On May 8, 2019, at 11:30 AM, Marcus D. Leech via USRP-users 
>  wrote:
> 
> On 05/08/2019 01:24 PM, Robin Coxe wrote:
>> Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered that 
>> the N210 was first released by Ettus Research in November 2010, which was 
>> about 6 months after we were acquired by National Instruments.
>> It is a true statement that v2 of the hardware is quite geriatric and no 
>> longer supported in modern versions of UHD.   However, all hope is not lost.
>> 
>> There *is* support for N200/N210 in the oldest version of UHD that is still 
>> downloadable on files.ettus.com , UHD v.3.8.0.0.   
>> The FPGA images are in this zip file:
>> http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip
>>  
>> 
>> 
>> We unfortunately don't have a v2 in the office to confirm that it still 
>> works, but you might want to take a look.  
>> 
>> -Robin
> I'm going to go through some old disk drives on mine from "back in the day", 
> and see if I have the r2 .bit files.
> 
> That can't happen until the weekend, however...
> 
> 
>> 
>> 
>> 
>> On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
>>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, 
>>> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email 
>>> adr can be of use.  
>>> 
>>> Joe
>>> 
>> There was a hardware change, as I recall, between Rev2 and Rev3 involving 
>> the inputs to the ADCs.
>> 
>> 
 On May 8, 2019, at 10:44 AM, Jason Matusiak >>> > wrote:
 
 Joe, I think you might be SOL.  If you take a look at this thread from me 
 last year, I had no luck: 
 http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
  
 
 
 
 Also, when I pinged Ettus directly, here is some info I got back from them 
 (from two different emails in the thread):
 "we've been having some trouble tracking down Rev2 bitfiles, because no
 one here was around when that was built. If you're trying to unbrick
 them, Rev3 bitfiles might be OK, but I'm not completely sure.
 
 supp...@ettus.com  might know more by know.
 really sorry, but those Rev2s are just so old. And all the people from
 that era seem to be gone. Sorry, can't help you with those Rev2s."
 
 From: USRP-users >>> > on behalf of Joe Martin via 
 USRP-users mailto:usrp-users@lists.ettus.com>>
 Sent: Wednesday, May 8, 2019 11:55 AM
 To: Joe Martin via USRP-users
 Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
 firmware/fpga images
  
 I am trying to bring an elderly N210 r2.0 with unknown history to life by 
 loading current UHD firmware and fpga images from a 1Gigabit ethernet 
 connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with 
 UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
 
 Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and 
 N2x0 Series”:
 
 My initial action was to load the “usrp_n210_r4_fpga.bit" file into the 
 N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming 
 cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program 
 Succeeded” for the action.  Ethernet LEDs on the N210 are variously 
 lighted showing activity on the connection port.
 
 With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
 following commands result in the responses shown in the screenshot image 
 below: 
 
 
 
 My (naive!) interpretation of the above responses is that the FPGA may not 
 actually have been programmed with the *.bit code even though iMPACT 
 reported success in programming.  Can someone assist me in understanding 
 whether my interpretation is correct or not and, most importantly, suggest 
 what I might try next to bring this N210 to life?  

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Marcus D. Leech via USRP-users]

On 05/08/2019 01:24 PM, Robin Coxe wrote:
Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered 
that the N210 was first released by Ettus Research in November 2010, 
which was about 6 months after we were acquired by National Instruments.
It is a true statement that v2 of the hardware is quite geriatric and 
no longer supported in modern versions of UHD.   However, all hope is 
not lost.


There *is* support for N200/N210 in the oldest version of UHD that is 
still downloadable on files.ettus.com , UHD 
v.3.8.0.0.   The FPGA images are in this zip file:

http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip

We unfortunately don't have a v2 in the office to confirm that it 
still works, but you might want to take a look.


-Robin
I'm going to go through some old disk drives on mine from "back in the 
day", and see if I have the r2 .bit files.


That can't happen until the weekend, however...






On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:

Wow, okay; that’s disheartening. Thanks much for the info, Jason.
 Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the
support email adr can be of use.

Joe


There was a hardware change, as I recall, between Rev2 and Rev3
involving the inputs to the ADCs.



On May 8, 2019, at 10:44 AM, Jason Matusiak
mailto:ja...@gardettoengineering.com>> wrote:

Joe, I think you might be SOL.  If you take a look at this
thread from me last year, I had no luck:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html


Also, when I pinged Ettus directly, here is some info I got back
from them (from two different emails in the thread):
"we've been having some trouble tracking down Rev2 bitfiles,
because no
one here was around when that was built. If you're trying to unbrick
them, Rev3 bitfiles might be OK, but I'm not completely sure.

supp...@ettus.com might know more by know.
really sorry, but those Rev2s are just so old. And all the
people from
that era seem to be gone. Sorry, can't help you with those Rev2s."


*From:*USRP-users mailto:usrp-users-boun...@lists.ettus.com>> on behalf of Joe
Martin via USRP-users mailto:usrp-users@lists.ettus.com>>
*Sent:*Wednesday, May 8, 2019 11:55 AM
*To:*Joe Martin via USRP-users
*Subject:*[USRP-users] Bringing an elderly N210 to life by
loading current firmware/fpga images
I am trying to bring an elderly N210 r2.0 with unknown history
to life by loading current UHD firmware and fpga images from a
1Gigabit ethernet connection on an AMD 2950X, 3.4GHz, 2TB SSD PC
running Ubuntu 18.04 with UHD 3.14.0.HEAD-0-gd20a7ae2 software
but having difficulty.

Following instructions in “USRP Hardware Driver and USRP Manual:
USRP2 and N2x0 Series”:

My initial action was to load the “usrp_n210_r4_fpga.bit" file
into the N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB
II JTAG programming cable from a Win7 PC running Xilinx ISE
iMPACT, which reported “Program Succeeded” for the action. 
Ethernet LEDs on the N210 are variously lighted showing activity

on the connection port.

With the N210 connected to the Linux PC 1Gbps ethernet port,
issuing the following commands result in the responses shown in
the screenshot image below:



My (naive!) interpretation of the above responses is that the
FPGA may not actually have been programmed with the *.bit code
even though iMPACT reported success in programming.  Can someone
assist me in understanding whether my interpretation is correct
or not and, most importantly, suggest what I might try next to
bring this N210 to life?

The “Please run:” suggestion results in the “Received invalid
reply 32 from device” error.  It seems no matter what I try the
“Received invalid reply 32 from device” RuntimeError is reported
back when I try to load any new firmware/FPGA images.

Thanks!

Joe




___
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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Marcus D. Leech via USRP-users]

On 05/08/2019 01:24 PM, Robin Coxe wrote:
Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered 
that the N210 was first released by Ettus Research in November 2010, 
which was about 6 months after we were acquired by National Instruments.
It is a true statement that v2 of the hardware is quite geriatric and 
no longer supported in modern versions of UHD.   However, all hope is 
not lost.


There *is* support for N200/N210 in the oldest version of UHD that is 
still downloadable on files.ettus.com , UHD 
v.3.8.0.0.   The FPGA images are in this zip file:

http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip

We unfortunately don't have a v2 in the office to confirm that it 
still works, but you might want to take a look.


-Robin

Unfortunately, the *.bit* files aren't in that images collection--only 
the .bin files.






On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:

Wow, okay; that’s disheartening. Thanks much for the info, Jason.
 Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the
support email adr can be of use.

Joe


There was a hardware change, as I recall, between Rev2 and Rev3
involving the inputs to the ADCs.



On May 8, 2019, at 10:44 AM, Jason Matusiak
mailto:ja...@gardettoengineering.com>> wrote:

Joe, I think you might be SOL.  If you take a look at this
thread from me last year, I had no luck:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html


Also, when I pinged Ettus directly, here is some info I got back
from them (from two different emails in the thread):
"we've been having some trouble tracking down Rev2 bitfiles,
because no
one here was around when that was built. If you're trying to unbrick
them, Rev3 bitfiles might be OK, but I'm not completely sure.

supp...@ettus.com might know more by know.
really sorry, but those Rev2s are just so old. And all the
people from
that era seem to be gone. Sorry, can't help you with those Rev2s."


*From:*USRP-users mailto:usrp-users-boun...@lists.ettus.com>> on behalf of Joe
Martin via USRP-users mailto:usrp-users@lists.ettus.com>>
*Sent:*Wednesday, May 8, 2019 11:55 AM
*To:*Joe Martin via USRP-users
*Subject:*[USRP-users] Bringing an elderly N210 to life by
loading current firmware/fpga images
I am trying to bring an elderly N210 r2.0 with unknown history
to life by loading current UHD firmware and fpga images from a
1Gigabit ethernet connection on an AMD 2950X, 3.4GHz, 2TB SSD PC
running Ubuntu 18.04 with UHD 3.14.0.HEAD-0-gd20a7ae2 software
but having difficulty.

Following instructions in “USRP Hardware Driver and USRP Manual:
USRP2 and N2x0 Series”:

My initial action was to load the “usrp_n210_r4_fpga.bit" file
into the N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB
II JTAG programming cable from a Win7 PC running Xilinx ISE
iMPACT, which reported “Program Succeeded” for the action. 
Ethernet LEDs on the N210 are variously lighted showing activity

on the connection port.

With the N210 connected to the Linux PC 1Gbps ethernet port,
issuing the following commands result in the responses shown in
the screenshot image below:



My (naive!) interpretation of the above responses is that the
FPGA may not actually have been programmed with the *.bit code
even though iMPACT reported success in programming.  Can someone
assist me in understanding whether my interpretation is correct
or not and, most importantly, suggest what I might try next to
bring this N210 to life?

The “Please run:” suggestion results in the “Received invalid
reply 32 from device” error.  It seems no matter what I try the
“Received invalid reply 32 from device” RuntimeError is reported
back when I try to load any new firmware/FPGA images.

Thanks!

Joe




___
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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Robin Coxe via USRP-users]

Hi Joe and Jason.  So, I took a walk down Memory Lane and discovered that
the N210 was first released by Ettus Research in November 2010, which was
about 6 months after we were acquired by National Instruments.
It is a true statement that v2 of the hardware is quite geriatric and no
longer supported in modern versions of UHD.   However, all hope is not lost.

There *is* support for N200/N210 in the oldest version of UHD that is still
downloadable on files.ettus.com, UHD v.3.8.0.0.   The FPGA images are in
this zip file:
http://files.ettus.com/binaries/images/uhd-images_003.008.000-18-g6647f8cc.zip

We unfortunately don't have a v2 in the office to confirm that it still
works, but you might want to take a look.

-Robin



On Wed, May 8, 2019 at 10:02 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
>
> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
> adr can be of use.
>
> Joe
>
> There was a hardware change, as I recall, between Rev2 and Rev3 involving
> the inputs to the ADCs.
>
>
> On May 8, 2019, at 10:44 AM, Jason Matusiak 
> wrote:
>
> Joe, I think you might be SOL.  If you take a look at this thread from me
> last year, I had no luck:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>
>
> Also, when I pinged Ettus directly, here is some info I got back from them
> (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>
> supp...@ettus.com might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
>
> --
> *From:* USRP-users  on behalf of Joe
> Martin via USRP-users 
> *Sent:* Wednesday, May 8, 2019 11:55 AM
> *To:* Joe Martin via USRP-users
> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
> current firmware/fpga images
>
> I am trying to bring an elderly N210 r2.0 with unknown history to life by
> loading current UHD firmware and fpga images from a 1Gigabit ethernet
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>
> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and
> N2x0 Series”:
>
> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
> showing activity on the connection port.
>
> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
> following commands result in the responses shown in the screenshot image
> below:
>
> 
>
> My (naive!) interpretation of the above responses is that the FPGA may not
> actually have been programmed with the *.bit code even though iMPACT
> reported success in programming.  Can someone assist me in understanding
> whether my interpretation is correct or not and, most importantly, suggest
> what I might try next to bring this N210 to life?
>
> The “Please run:” suggestion results in the “Received invalid reply 32
> from device” error.  It seems no matter what I try the “Received invalid
> reply 32 from device” RuntimeError is reported back when I try to load any
> new firmware/FPGA images.
>
> Thanks!
>
> Joe
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Marcus D. Leech via USRP-users]

On 05/08/2019 12:56 PM, Joe Martin via USRP-users wrote:
Wow, okay; that’s disheartening.  Thanks much for the info, Jason. 
 Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the 
support email adr can be of use.


Joe

There was a hardware change, as I recall, between Rev2 and Rev3 
involving the inputs to the ADCs.



On May 8, 2019, at 10:44 AM, Jason Matusiak 
> wrote:


Joe, I think you might be SOL.  If you take a look at this thread 
from me last year, I had no luck: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html



Also, when I pinged Ettus directly, here is some info I got back from 
them (from two different emails in the thread):

"we've been having some trouble tracking down Rev2 bitfiles, because no
one here was around when that was built. If you're trying to unbrick
them, Rev3 bitfiles might be OK, but I'm not completely sure.

supp...@ettus.com might know more by know.
really sorry, but those Rev2s are just so old. And all the people from
that era seem to be gone. Sorry, can't help you with those Rev2s."


*From:*USRP-users > on behalf of Joe Martin 
via USRP-users >

*Sent:*Wednesday, May 8, 2019 11:55 AM
*To:*Joe Martin via USRP-users
*Subject:*[USRP-users] Bringing an elderly N210 to life by loading 
current firmware/fpga images
I am trying to bring an elderly N210 r2.0 with unknown history to 
life by loading current UHD firmware and fpga images from a 1Gigabit 
ethernet connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running 
Ubuntu 18.04 with UHD 3.14.0.HEAD-0-gd20a7ae2 software but having 
difficulty.


Following instructions in “USRP Hardware Driver and USRP Manual: 
USRP2 and N2x0 Series”:


My initial action was to load the “usrp_n210_r4_fpga.bit" file into 
the N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG 
programming cable from a Win7 PC running Xilinx ISE iMPACT, which 
reported “Program Succeeded” for the action.  Ethernet LEDs on the 
N210 are variously lighted showing activity on the connection port.


With the N210 connected to the Linux PC 1Gbps ethernet port, issuing 
the following commands result in the responses shown in the 
screenshot image below:




My (naive!) interpretation of the above responses is that the FPGA 
may not actually have been programmed with the *.bit code even though 
iMPACT reported success in programming.  Can someone assist me in 
understanding whether my interpretation is correct or not and, most 
importantly, suggest what I might try next to bring this N210 to life?


The “Please run:” suggestion results in the “Received invalid reply 
32 from device” error.  It seems no matter what I try the “Received 
invalid reply 32 from device” RuntimeError is reported back when I 
try to load any new firmware/FPGA images.


Thanks!

Joe




___
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] Bringing an elderly N210 to life by loading current firmware/fpga images

[Jason Matusiak via USRP-users]

R3 didn't work for me either.  I am not sure I would even bother with the 
support email, I think they tried hard for me last year and they couldn't 
revive that rev's source code at all.  We abandoned our r2 Ns and just worked 
on the ones that were already working.


From: Joe Martin 
Sent: Wednesday, May 8, 2019 12:56 PM
To: Jason Matusiak
Cc: Joe Martin via USRP-users
Subject: Re: [USRP-users] Bringing an elderly N210 to life by loading current 
firmware/fpga images

Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, the 
Rev3 bit file doesn’t work; tried it.  I’ll see if the support email adr can be 
of use.

Joe

On May 8, 2019, at 10:44 AM, Jason Matusiak 
mailto:ja...@gardettoengineering.com>> wrote:

Joe, I think you might be SOL.  If you take a look at this thread from me last 
year, I had no luck: 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html


Also, when I pinged Ettus directly, here is some info I got back from them 
(from two different emails in the thread):
"we've been having some trouble tracking down Rev2 bitfiles, because no
one here was around when that was built. If you're trying to unbrick
them, Rev3 bitfiles might be OK, but I'm not completely sure.

supp...@ettus.com might know more by know.
really sorry, but those Rev2s are just so old. And all the people from
that era seem to be gone. Sorry, can't help you with those Rev2s."


From: USRP-users 
mailto:usrp-users-boun...@lists.ettus.com>> 
on behalf of Joe Martin via USRP-users 
mailto:usrp-users@lists.ettus.com>>
Sent: Wednesday, May 8, 2019 11:55 AM
To: Joe Martin via USRP-users
Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
firmware/fpga images

I am trying to bring an elderly N210 r2.0 with unknown history to life by 
loading current UHD firmware and fpga images from a 1Gigabit ethernet 
connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with UHD 
3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.

Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and N2x0 
Series”:

My initial action was to load the “usrp_n210_r4_fpga.bit" file into the N210 
xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming cable 
from a Win7 PC running Xilinx ISE iMPACT, which reported “Program Succeeded” 
for the action.  Ethernet LEDs on the N210 are variously lighted showing 
activity on the connection port.

With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
following commands result in the responses shown in the screenshot image below:



My (naive!) interpretation of the above responses is that the FPGA may not 
actually have been programmed with the *.bit code even though iMPACT reported 
success in programming.  Can someone assist me in understanding whether my 
interpretation is correct or not and, most importantly, suggest what I might 
try next to bring this N210 to life?

The “Please run:” suggestion results in the “Received invalid reply 32 from 
device” error.  It seems no matter what I try the “Received invalid reply 32 
from device” RuntimeError is reported back when I try to load any new 
firmware/FPGA images.

Thanks!

Joe

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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Joe Martin via USRP-users]

Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope, the 
Rev3 bit file doesn’t work; tried it.  I’ll see if the support email adr can be 
of use.  

Joe

> On May 8, 2019, at 10:44 AM, Jason Matusiak  
> wrote:
> 
> Joe, I think you might be SOL.  If you take a look at this thread from me 
> last year, I had no luck: 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>  
> 
> 
> 
> Also, when I pinged Ettus directly, here is some info I got back from them 
> (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
> 
> supp...@ettus.com  might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
> 
> From: USRP-users  > on behalf of Joe Martin via 
> USRP-users mailto:usrp-users@lists.ettus.com>>
> Sent: Wednesday, May 8, 2019 11:55 AM
> To: Joe Martin via USRP-users
> Subject: [USRP-users] Bringing an elderly N210 to life by loading current 
> firmware/fpga images
>  
> I am trying to bring an elderly N210 r2.0 with unknown history to life by 
> loading current UHD firmware and fpga images from a 1Gigabit ethernet 
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with UHD 
> 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
> 
> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and 
> N2x0 Series”:
> 
> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the N210 
> xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming cable 
> from a Win7 PC running Xilinx ISE iMPACT, which reported “Program Succeeded” 
> for the action.  Ethernet LEDs on the N210 are variously lighted showing 
> activity on the connection port.
> 
> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
> following commands result in the responses shown in the screenshot image 
> below: 
> 
> 
> 
> My (naive!) interpretation of the above responses is that the FPGA may not 
> actually have been programmed with the *.bit code even though iMPACT reported 
> success in programming.  Can someone assist me in understanding whether my 
> interpretation is correct or not and, most importantly, suggest what I might 
> try next to bring this N210 to life?  
> 
> The “Please run:” suggestion results in the “Received invalid reply 32 from 
> device” error.  It seems no matter what I try the “Received invalid reply 32 
> from device” RuntimeError is reported back when I try to load any new 
> firmware/FPGA images.  
> 
> Thanks!
> 
> Joe

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

Re: [USRP-users] X310 RFNoC transmission issues

[Nick Foster via USRP-users]

Have you simulated your RFNoC CEs with Verilog testbenches?

On Wed, May 8, 2019 at 8:12 AM zluudg via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello!
>
> I'm having some issues while trying to transmit a signal using the
> RFNoC: Radio block in Gnuradio. My block diagram is:
>
>
>  Signal Source (constant) -> RFNoC: DmaFIFO -> RFNoC: Radio (in
> TX mode).
>
>
> I run the block diagram by calling "python top_block.py" from the
> command line and I'm not getting any errors while it's running .
> However, I'm unable to quit it properly without having to close the
> terminal window and power-cycle the USRP. When connecting the USRP to a
> spectrum analyzer I see no signal whatsoever (I expect to see a peak at
> 2.4 GHz).
>
>
> Removing the DmaFIFO does not seem to make any difference. My FPGA image
> is a custom image with some of my CEs, but it was built smoothly using
> the "uhd_image_builder.py" script. I've also experienced similar
> problems while having a RFNoC: DUC between the DmaFIFO and the Radio
> block, also with a custom FPGA image. With the stock FPGA image I was
> able to get a signal with more or less the same Gnuradio block diagram.
>
>
> Why am I not seeing any output with my custom FPGA images? All
> suggestions appreciated.
>
>
> I'll happily provide more info if needed, so don't hesitate to ask. For
> know, I'll just provide the basics:
>
>
>  OS: Ubuntu 18.04
>
>  uhd: rfnoc-devel, eec24d7b0
>
>  gnuradio: maint-3.7, c6c575309
>
>  gr-ettus: master, a909447
>
>
> Thanks in advance!
>
> //
>
> Leon
>
>
> ___
> 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] Bringing an elderly N210 to life with current firmware/fpga images

[Joe Martin via USRP-users]

Apologies, the instruction document I’m following is “USRP_Hardware Driver and 
USRP Manual: USDRP2 and N2x0 Series” not what is mentioned below.

Joe

> On May 8, 2019, at 9:11 AM, Joe Martin  wrote:
> 
> I am trying to bring an elderly N210 r2.0 with unknown history to life by 
> loading current UHD firmware and fpga images from a 1Gigabit ethernet 
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with UHD 
> 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty. 
> 
> Following instructions in “USRP Hardware Driver and USRP Manual: Internal 
> GPSDO (USRP-N2x0/E1X0 Models)”:
> 
> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the N210 
> xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming cable 
> from a Win7 PC running Xilinx ISE iMPACT, which reported “Program Succeeded” 
> for the action.  Ethernet LEDs on the N210 are variously lighted showing 
> activity on the connection port.
> 
> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the 
> following commands result in the responses shown in the screenshot image 
> below: 
> 
> 
> 
> My (naive!) interpretation of the above responses is that the FPGA may not 
> actually have been programmed with the *.bit code even though iMPACT reported 
> success in programming.  Can someone assist me in understanding whether my 
> interpretation is correct or not and, most importantly, suggest what I might 
> try next to bring this N210 to life?  
> 
> The “Please run:” suggestion results in the “Received invalid reply 32 from 
> device” error.  It seems no matter what I try the “Received invalid reply 32 
> from device” RuntimeError is reported back when I try to load any new 
> firmware/FPGA images.  
> 
> Thanks!
> 
> Joe
> 


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

[USRP-users] X310 RFNoC transmission issues

[zluudg via USRP-users]

Hello!

I'm having some issues while trying to transmit a signal using the 
RFNoC: Radio block in Gnuradio. My block diagram is:



    Signal Source (constant) -> RFNoC: DmaFIFO -> RFNoC: Radio (in 
TX mode).



I run the block diagram by calling "python top_block.py" from the 
command line and I'm not getting any errors while it's running . 
However, I'm unable to quit it properly without having to close the 
terminal window and power-cycle the USRP. When connecting the USRP to a 
spectrum analyzer I see no signal whatsoever (I expect to see a peak at 
2.4 GHz).



Removing the DmaFIFO does not seem to make any difference. My FPGA image 
is a custom image with some of my CEs, but it was built smoothly using 
the "uhd_image_builder.py" script. I've also experienced similar 
problems while having a RFNoC: DUC between the DmaFIFO and the Radio 
block, also with a custom FPGA image. With the stock FPGA image I was 
able to get a signal with more or less the same Gnuradio block diagram.



Why am I not seeing any output with my custom FPGA images? All 
suggestions appreciated.



I'll happily provide more info if needed, so don't hesitate to ask. For 
know, I'll just provide the basics:



    OS: Ubuntu 18.04

    uhd: rfnoc-devel, eec24d7b0

    gnuradio: maint-3.7, c6c575309

    gr-ettus: master, a909447


Thanks in advance!

//

Leon


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

Re: [USRP-users] Running E310 in Network Mode

[Jason Matusiak via USRP-users]

See here: https://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode



From: USRP-users  on behalf of Ramazan 
Çetin via USRP-users 
Sent: Wednesday, May 8, 2019 8:02 AM
To: Ettus Research Support; usrp-users@lists.ettus.com
Subject: [USRP-users] Running E310 in Network Mode

Hello,

We want to run USRP E310 in network mode. I think the samples coming
from FPGA passing through CPU before sending to network. This decreases
bandwidth because of CPU limitations.


So, is there any ettus image or suggestions that we can run E310
directly from FPGA to network without speed limitations? (like N210 or B210)

Best regards.

Ramazan


___
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] how can i receive 2 different signals with the USRP B210

[Brian Padalino via USRP-users]

On Wed, May 8, 2019 at 5:43 AM Marwa Boukhari via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I want to send and receive a Signal  at the frequency 900MHz with the
> Channel 0 , and want to receive another Signal from the generator at the
> frequency 5,68GHz with the other channel.
> I tried to realize this but it didn't work.
> Has someone maybe an idea what's the problem is.
>

The two receivers use a shared LO, so this won't work.

To receive two different frequencies, you need two radios.

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

[USRP-users] Running E310 in Network Mode

[Ramazan Çetin via USRP-users]

Hello,

We want to run USRP E310 in network mode. I think the samples coming 
from FPGA passing through CPU before sending to network. This decreases 
bandwidth because of CPU limitations.



So, is there any ettus image or suggestions that we can run E310 
directly from FPGA to network without speed limitations? (like N210 or B210)


Best regards.

Ramazan


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

[USRP-users] how can i receive 2 different signals with the USRP B210

[Marwa Boukhari via USRP-users]

Hi,
I want to send and receive a Signal  at the frequency 900MHz with the 
Channel 0 , and want to receive another Signal from the generator at the 
frequency 5,68GHz with the other channel.

I tried to realize this but it didn't work.
Has someone maybe an idea what's the problem is.

Thanks.

Marwa



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

[USRP-users] USRP not detected by Laptop

[VINAYAK KARANDIKAR via USRP-users]

Hello everyone,

   I have a NI USRP 2954 and when i am trying to
connect it with my Laptop, with a working Ethernet cable,in the "network
connections" window i notice that the Ethernet connection status stands at:
"Network cable unplugged".



Can someone help me sort this issue?



In case further information is required, my Laptop is an ASUS product(64
bit) and the OS is windows 10.



Thanks a lot.,

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