Re: [USRP-users] USRP X310

[Joe Martin via USRP-users]

Marcus: 

Yes. Thanks.  As I said. 

Regards, 

Joe

> On Jul 14, 2020, at 8:29 AM, Marcus D Leech  wrote:
> 
> Joe:
> 
> The input levels that cause distortion vary quite a bit from daughtercard to 
> daughtercard, and even within a daughtercard there will be variability 
> depending on frequency. 
> 
> The performance data can be consulted for this:
> 
> https://files.ettus.com/performance_data/ 
> 
> 
> What you’re looking for is IP3 and P1dB data. 
> 
> But “damage limits” are given 
> Sent from my iPhone
> 
>> On Jul 14, 2020, at 10:17 AM, Joe Martin  wrote:
>> 
>> Arash, 
>> 
>> Marcus L.’s response has some definitive info in the links.  For example, in 
>> the TwinRX link it is stated: 
>> 
>>> Never apply more than +10 dBm of power into any RF input.
>> 
>> So there you have it.  Thanks for the details Marcus. 
>> 
>> Regards, 
>> 
>> Joe
>> 
>>> On Jul 14, 2020, at 7:55 AM, Marcus D. Leech via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> On 07/14/2020 05:53 AM, Marcus Müller via USRP-users wrote:
 Hi Arash,
 
 The input power is not defined by the motherboard (X310) you're using,
 but by the analog frontend daughterboard (like TwinRX, UBX-160, SBX,…)
 you've plugged in to these.
 
>>> For example, see the "Care and Handling" for the SBX here:
>>> 
>>> https://kb.ettus.com/SBX_Getting_Started_Guides#Proper_Care_and_Handling 
>>> 
>>> 
>>> And for the TwinRx
>>> 
>>> https://kb.ettus.com/TwinRX_Getting_Started_Guides#Proper_Care_and_Handling
>>> 
>>> 
>>> ___
>>> 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 X310

[Joe Martin via USRP-users]

Arash, 

Marcus L.’s response has some definitive info in the links.  For example, in 
the TwinRX link it is stated: 

> Never apply more than +10 dBm of power into any RF input.

So there you have it.  Thanks for the details Marcus. 

Regards, 

Joe

> On Jul 14, 2020, at 7:55 AM, Marcus D. Leech via USRP-users 
>  wrote:
> 
> On 07/14/2020 05:53 AM, Marcus Müller via USRP-users wrote:
>> Hi Arash,
>> 
>> The input power is not defined by the motherboard (X310) you're using,
>> but by the analog frontend daughterboard (like TwinRX, UBX-160, SBX,…)
>> you've plugged in to these.
>> 
> For example, see the "Care and Handling" for the SBX here:
> 
> https://kb.ettus.com/SBX_Getting_Started_Guides#Proper_Care_and_Handling
> 
> And for the TwinRx
> 
> https://kb.ettus.com/TwinRX_Getting_Started_Guides#Proper_Care_and_Handling
> 
> 
> ___
> 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 X310

[Joe Martin via USRP-users]

Arash, 

While Marcus’ response is certainly correct it does little in providing a 
practical answer to your question.  

I use an X310 with TwinRX daughterboards and have found that it is inadvisable 
to use input levels to the TwinRX daughterboard greater than -30dBm because 
higher levels than that tend to result in distortion/compression issues.  I 
don’t know what the damage threshold is for the input ports on the TwinRX 
daughterboard.  For my radio astronomy applications I use an input level of 
-60dBm and that seems to work quite well for me.  I don’t know if other 
daughterboards for the X310 have different input-level behavior.  Perhaps this 
response will give you ball park answers that you can use.

Regards, 

Joe


> On Jul 14, 2020, at 3:53 AM, Marcus Müller via USRP-users 
>  wrote:
> 
> Hi Arash,
> 
> The input power is not defined by the motherboard (X310) you're using,
> but by the analog frontend daughterboard (like TwinRX, UBX-160, SBX,…)
> you've plugged in to these.
> 
> On 14.07.20 11:38, Arash Jafari via USRP-users wrote:
>> National Instrument congratulation!! very bad documentation.
> 
> …
> 
> Best regards,
> Marcus Müller
> 
> ___
> 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] UHD 3.15 LTS, X310 performance

[Joe Martin via USRP-users]

I meant 25Msps per channel, not 25Mbps, of course. 

Joe

> On Feb 23, 2020, at 7:38 AM, Joe Martin via USRP-users 
>  wrote:
> 
> Hi Simon, 
> 
> Yes, indeed, my X310 streams via 10G ethernet without a hitch using dual 
> channels at 25Mbps/channel in my radio astronomy application and I could go 
> more if I needed to do that.  It’ll work fine for you I’m sure.
> 
> Joe K5SO
> 
>> On Feb 23, 2020, at 12:23 AM, Simon G4ELI via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Hi,
>>  
>> Some feedback: I’ve been reading the UHD code and now have the X310 running 
>> well albeit at 20Msps as the user has only GigE, but he’s buying a 10 GigE 
>> card  and does have a ‘stonking’ Windows PC so I’ll document the experience. 
>> I expect we’ll stream sustained at 50 Msps, quite possibly much more.
>>  
>> My B200 is streaming superbly at 28 Msps on a mid-range PC.
>>  
>> Simon Brown, G4ELI
>> https://www.sdr-radio.com <https://www.sdr-radio.com/>
>>  
>> From: Michael Dickens > <mailto:michael.dick...@ettus.com>> 
>>  
>> Hi Simon - When you say "but performance is not great" ... beyond CPU load: 
>> do you get good Tx and Rx rates (e.g., if you run "benchmark_rate") without 
>> underruns / overflows / late packets (etc)? What is the MTU set to for this 
>> ENET link? 1 GbE or 10 GbE? Can you provide a little more detail for us to 
>> work with here? Thx! - MLD
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/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] UHD 3.15 LTS, X310 performance

[Joe Martin via USRP-users]

Hi Simon, 

Yes, indeed, my X310 streams via 10G ethernet without a hitch using dual 
channels at 25Mbps/channel in my radio astronomy application and I could go 
more if I needed to do that.  It’ll work fine for you I’m sure.

Joe K5SO

> On Feb 23, 2020, at 12:23 AM, Simon G4ELI via USRP-users 
>  wrote:
> 
> Hi,
>  
> Some feedback: I’ve been reading the UHD code and now have the X310 running 
> well albeit at 20Msps as the user has only GigE, but he’s buying a 10 GigE 
> card  and does have a ‘stonking’ Windows PC so I’ll document the experience. 
> I expect we’ll stream sustained at 50 Msps, quite possibly much more.
>  
> My B200 is streaming superbly at 28 Msps on a mid-range PC.
>  
> Simon Brown, G4ELI
> https://www.sdr-radio.com 
>  
> From: Michael Dickens  > 
>  
> Hi Simon - When you say "but performance is not great" ... beyond CPU load: 
> do you get good Tx and Rx rates (e.g., if you run "benchmark_rate") without 
> underruns / overflows / late packets (etc)? What is the MTU set to for this 
> ENET link? 1 GbE or 10 GbE? Can you provide a little more detail for us to 
> work with here? Thx! - MLD
> ___
> 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] UHD 4.0.0 X310 Images

[Joe Martin via USRP-users]

Pardon my bit of syntax error:   These work for me on my X310: 

sudo /usr/local/lib/uhd/utils/uhd_images_downloader.py

/usr/local/bin/uhd_image_loader —args=“type=x300,addr=192.168.30.2”

Joe

> On Feb 14, 2020, at 4:31 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Hi Simon, 
> 
> You can do this (assuming you installed UHD components into the given 
> directories below): 
> 
> sudo /user/local/lib/uhd/utils/iuhd_images_downloader.py
> 
> cd /usr/local/bin
> uhd_image_loader —args=type=x300,addr=192.168.30.2
> 
> The addr I show is for a 10 G ethernet connection, will be different for a 1G 
> ethernet connection, of course. 
> 
> Regards, 
> 
> Joe K5SO
> 
>> On Feb 14, 2020, at 4:09 PM, Simon G4ELI via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Hi,
>>  
>> Having compiled UHD from the latest source master branch, I’m looking for 
>> the X310 images for a user, apparently we’re looking for FPGA 38.
>>  
>> “Exception 054F (1359), RuntimeError: Expected FPGA compatibility number 
>> 38, but got 36”
>>  
>> Any ideas please?
>>  
>> Simon Brown, G4ELI
>> https://www.sdr-radio.com <https://www.sdr-radio.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] UHD 4.0.0 X310 Images

[Joe Martin via USRP-users]

Hi Simon, 

You can do this (assuming you installed UHD components into the given 
directories below): 

sudo /user/local/lib/uhd/utils/iuhd_images_downloader.py

cd /usr/local/bin
uhd_image_loader —args=type=x300,addr=192.168.30.2

The addr I show is for a 10 G ethernet connection, will be different for a 1G 
ethernet connection, of course. 

Regards, 

Joe K5SO

> On Feb 14, 2020, at 4:09 PM, Simon G4ELI via USRP-users 
>  wrote:
> 
> Hi,
>  
> Having compiled UHD from the latest source master branch, I’m looking for the 
> X310 images for a user, apparently we’re looking for FPGA 38.
>  
> “Exception 054F (1359), RuntimeError: Expected FPGA compatibility number 
> 38, but got 36”
>  
> Any ideas please?
>  
> Simon Brown, G4ELI
> https://www.sdr-radio.com 
>  

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

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Holy smoke!  SUCCESS!!  Nick pointed out that there are two switches on the 
N210; S1 and S2 and S1 is a reset, so an upload of FPGA code fails if that is 
held (which I was holding for his suggested test!).  Holding S2 during iMPACT 
loading of the .bit image results in the uhd_image_loader step being 
SUCCESSFUL!!  I am so happy to see that!  Uhd_usrp_probe works wonderfully.  
Finally.  We now can put this little to work doing some tough things!  

Thank you all SO MUCH for your assistance with reviving this N210.  A 
monumental achievement in my book!   I don’t know what to say except that we 
TOTALLY appreciate you efforts to get us running.  You guys are GREAT! 

Very best wishes to you each and every one!   

Joe

> On May 10, 2019, at 5:30 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Ian and all, 
> 
> I have been very careful to avoid the pitfalls you detailed.  I began with a 
> fresh installation of Ubuntu 18.04 then performed a successful build of UHD 
> 3.9.7, then used command:
> 
> uhd_images_downloader
> 
> to load the appropriate/associated images into the PC. 
> 
> Then used ISE iMPACT to load the “usrp_n210_r3_fpga.bit” file into the FPGA 
> of the N210.  iMPACT reports “PROGRAM SUCCESSFUL”. 
> 
> Then without power cycling the N210 used the command: 
> 
> usrp_image_loader —args=“type=usrp2,addr=192.168.10.2,overwrite-safe” 
> —fw-path=/usr/local/share/uhd/images/usrp_n210_fw.bin 
> —fpga-path=/usr/local/share/uhd/images/usrp_n210_r3_fpga.bin
> 
> To load the non-volatile memory of the N210 but I always get the 
> “RuntimeError: Received invalid 32 reply from device” error when running 
> usrp_image_loader. 
> 
> I am able to successfully ping 192.168.10.2 but no matter what combinations 
> of r2 or r3 .bit file and firmware and fpga image .bin files I use the 
> response when invoking the usrp_image_loader is always the same, namely 
> “invalid reply 32 from device”.  
> 
> The command uhd_find_devices returns by reporting it can find a usrp2 device 
> at address 192.168.10.2, as you would hope.  
> 
> After trying every conceivable combination of these actions with numerous 
> versions of UHD and r2/r3 .bit FPGA files and r2/r3 .bin files on several 
> fresh installations of Ubuntu 18.04 and 16.04 the result is always the same 
> in that things proceed normally as the various documents concerning 
> un-bricking an N210 explains, until the step of using the usrp_image_loader 
> is executed, at which point a RuntimeError returns stating that the “invalid 
> 32 reply” has occurred.  
> 
> I was hopeful that careful use of rev3 .bit and .bin files with UHD 3.9.7 
> would do the trick but alas that is not the case.  
> 
> I suspect that you are near the bottom of the list of suggestions for me and 
> I do appreciate the time and thinking you have afforded me on this issue.  If 
> there is anything remaining to try I’d be most willing to try it. 
> 
> BTW, the suggestion made by someone earlier to try holding the safe button 
> down during the loading of the FPGA from iMPACT causes the programming to 
> fail (as reported by iMPACT), so that’s apparently not a good thing to do.  
> But one can recover from that state by simply by re-programming with the safe 
> button not held but the fundamental problem with the uhd_image_loader step in 
> the unbricking process always seems to result. 
> 
> Joe
> 
>> On May 10, 2019, at 9:31 AM, Ian Buckley > <mailto:ian.buck...@gmail.com>> wrote:
>> 
>> Joe, 
>> To save you time, It may well be worth you trying jumping to the 3) step 
>> initially and seeing if your current loaded image or safe image is capable 
>> of being upgraded …it likely is since that protocol is widely compatible 
>> across UHD variants. The key here I have to emphasize (since you appear to 
>> have been previously getting stuck with incompatibility between whatever is 
>> loaded in the USRP and your host UHD installation) is to be sure your new 
>> UHD installation is the only one on your system, and that you have the 
>> binary images that are version matched with it…people often get caught out 
>> by reminants of various UHD versions installed in various system directories 
>> from different install methods.
>> -Ian
>> 
>>> On May 10, 2019, at 5:58 AM, Joe Martin via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> Ian, 
>>> 
>>> Very good, that’s encouraging at least.  Yes, I am familiar with using ISE 
>>> iMPACT to load the FPGA with .bit code and even how to create the .bit from 
>>> the associated .bin file and did try doing that earlier but perhaps not 
>>> identically to your prescribed ste

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Ian and all, 

I have been very careful to avoid the pitfalls you detailed.  I began with a 
fresh installation of Ubuntu 18.04 then performed a successful build of UHD 
3.9.7, then used command:

uhd_images_downloader

to load the appropriate/associated images into the PC. 

Then used ISE iMPACT to load the “usrp_n210_r3_fpga.bit” file into the FPGA of 
the N210.  iMPACT reports “PROGRAM SUCCESSFUL”. 

Then without power cycling the N210 used the command: 

usrp_image_loader —args=“type=usrp2,addr=192.168.10.2,overwrite-safe” 
—fw-path=/usr/local/share/uhd/images/usrp_n210_fw.bin 
—fpga-path=/usr/local/share/uhd/images/usrp_n210_r3_fpga.bin

To load the non-volatile memory of the N210 but I always get the “RuntimeError: 
Received invalid 32 reply from device” error when running usrp_image_loader. 

I am able to successfully ping 192.168.10.2 but no matter what combinations of 
r2 or r3 .bit file and firmware and fpga image .bin files I use the response 
when invoking the usrp_image_loader is always the same, namely “invalid reply 
32 from device”.  

The command uhd_find_devices returns by reporting it can find a usrp2 device at 
address 192.168.10.2, as you would hope.  

After trying every conceivable combination of these actions with numerous 
versions of UHD and r2/r3 .bit FPGA files and r2/r3 .bin files on several fresh 
installations of Ubuntu 18.04 and 16.04 the result is always the same in that 
things proceed normally as the various documents concerning un-bricking an N210 
explains, until the step of using the usrp_image_loader is executed, at which 
point a RuntimeError returns stating that the “invalid 32 reply” has occurred.  

I was hopeful that careful use of rev3 .bit and .bin files with UHD 3.9.7 would 
do the trick but alas that is not the case.  

I suspect that you are near the bottom of the list of suggestions for me and I 
do appreciate the time and thinking you have afforded me on this issue.  If 
there is anything remaining to try I’d be most willing to try it. 

BTW, the suggestion made by someone earlier to try holding the safe button down 
during the loading of the FPGA from iMPACT causes the programming to fail (as 
reported by iMPACT), so that’s apparently not a good thing to do.  But one can 
recover from that state by simply by re-programming with the safe button not 
held but the fundamental problem with the uhd_image_loader step in the 
unbricking process always seems to result. 

Joe

> On May 10, 2019, at 9:31 AM, Ian Buckley  wrote:
> 
> Joe, 
> To save you time, It may well be worth you trying jumping to the 3) step 
> initially and seeing if your current loaded image or safe image is capable of 
> being upgraded …it likely is since that protocol is widely compatible across 
> UHD variants. The key here I have to emphasize (since you appear to have been 
> previously getting stuck with incompatibility between whatever is loaded in 
> the USRP and your host UHD installation) is to be sure your new UHD 
> installation is the only one on your system, and that you have the binary 
> images that are version matched with it…people often get caught out by 
> reminants of various UHD versions installed in various system directories 
> from different install methods.
> -Ian
> 
>> On May 10, 2019, at 5:58 AM, Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Ian, 
>> 
>> Very good, that’s encouraging at least.  Yes, I am familiar with using ISE 
>> iMPACT to load the FPGA with .bit code and even how to create the .bit from 
>> the associated .bin file and did try doing that earlier but perhaps not 
>> identically to your prescribed steps below.  I’ll revisit it.  I 
>> successfully built UHD 003_009_000 earlier so I can probably also 
>> successfully build UHD 003_009_007 too.  I’ll do that and give it a go.  I 
>> am familiar with the documents you mentioned.  Generally things have gone 
>> exactly as described right up until UHD needs to communicate with the stored 
>> images at which point it never does; so far anyway.
>> 
>> Thanks much for the additional information.  I’ll certainly hammer on it 
>> some more now that I have a few more pertinent details under my belt to 
>> guide the process appropriately. 
>> 
>> Joe
>> 
>>> On May 10, 2019, at 12:32 AM, Ian Buckley >> <mailto:ian.buck...@gmail.com>> wrote:
>>> 
>>> Joe, 
>>> This is generally all good news and somewhat hopeful. The fact you can ping 
>>> 192.168.10.2 in safe mode tell’s you that the FPGA has loaded an image from 
>>> Flash, that it’s passed CRC and booted the embedded micro controller on the 
>>> FPGA and run the firmware that replies to ICMP packets…that’s a sign the 
>>> hardware is in reasonable shape, reg

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Ian, 

Very good, that’s encouraging at least.  Yes, I am familiar with using ISE 
iMPACT to load the FPGA with .bit code and even how to create the .bit from the 
associated .bin file and did try doing that earlier but perhaps not identically 
to your prescribed steps below.  I’ll revisit it.  I successfully built UHD 
003_009_000 earlier so I can probably also successfully build UHD 003_009_007 
too.  I’ll do that and give it a go.  I am familiar with the documents you 
mentioned.  Generally things have gone exactly as described right up until UHD 
needs to communicate with the stored images at which point it never does; so 
far anyway.

Thanks much for the additional information.  I’ll certainly hammer on it some 
more now that I have a few more pertinent details under my belt to guide the 
process appropriately. 

Joe

> On May 10, 2019, at 12:32 AM, Ian Buckley  wrote:
> 
> Joe, 
> This is generally all good news and somewhat hopeful. The fact you can ping 
> 192.168.10.2 in safe mode tell’s you that the FPGA has loaded an image from 
> Flash, that it’s passed CRC and booted the embedded micro controller on the 
> FPGA and run the firmware that replies to ICMP packets…that’s a sign the 
> hardware is in reasonable shape, regardless of what actually version of image 
> ins currently loaded. If you had the internal UART connected to a 3.3V 
> interface you would be seeing the FPGA and FW compatibility numbers for this 
> image printed at boot if it got this far.
> (Sorry if I’m telling you stuff you know here, too many messages in this 
> thread to go reread them)
> 
> You should now refer to these 2 pages:
> https://kb.ettus.com/N200/N210_Device_Recovery 
> <https://kb.ettus.com/N200/N210_Device_Recovery>
> http://files.ettus.com/manual/page_usrp2.html#usrp2_load 
> <http://files.ettus.com/manual/page_usrp2.html#usrp2_load> (N-series 
> sections, not USRP2)
> 
> The general outline of what to try is as follows:
> 1) Start with a relatively modern and stable UHD version: Any 3.9.x version 
> is pretty ideal, it’s well supported in Gnuradio, is perhaps the most stable, 
> and has N210 support. If you are building UHD yourself from GitHub, then 
> checkout the tag “release_003_009_007”.
> (Note there is no reason to look for old UHD versions to support your H/W, 
> the N210 specific code has changed very little for some time, but you will 
> benefit from much improved general UHD functionality and much better 
> community support)
> 2. (Given you understand how to load a new image via JTAG) Follow the 
> procedure outlined in “Unbricking an N Series Device”. Run 
> “uhd_images_downloader” under UHD3.9.x to be sure you have a compatible set 
> of FPGA images for this version of UHD. Use an R3 .bit file (Stay away from 
> R4 images since we know that is electrically incompatible with your H/W) and 
> load this via JTAG. Verify you can ping this once it’s loaded. Remember this 
> is a volatile load, no flash has changed yet, if you reset the H/W this 
> download is lost. The goal now is to use the embedded firmware in this JTAG 
> image to load the same images in .bin format via the ethernet network and 
> update both slot’s in the flash memory with non-volatile images that load 
> automatically after reset/power cycle.
> 3) Follow the instructions in 
> http://files.ettus.com/manual/page_usrp2.html#usrp2_load 
> <http://files.ettus.com/manual/page_usrp2.html#usrp2_load> to perform the 
> image update via the network. You can also take a peek at the settings in 
> your EEPROM (“Recovery process” instructions) to verify that all fields are 
> sane and match your case label.
> 4) At this point, if all has gone as intended, USRP and UHD should be in 
> sync, power cycling H/W should work, and tools like “uhd_usrp_probe” should 
> find the USRP and print it’s detailed H/W config. There are a few common 
> useful things to check in the “Troubleshooting” section if things still don’t 
> seem to have worked.
> 
> -Ian
> 
> 
>> On May 9, 2019, at 2:48 PM, Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Oh, okay, I didn’t get that.  Understood now.  I have UHD 3.14.0 running on 
>> my main machine so I could try again some newer .bit files into the FPGA 
>> than I previously have tried (I tried the current version of UHD and N210 
>> usrp_n210_r4_fpga.bit to no avail) to see if any of them are compatible.  I 
>> also was able to build UHD 3.9.0 on a different machine so I can try that 
>> too with some of the other .bit files.  Will hold the safe button down while 
>> loading the FPGA this time around.  
>> 
>> Joe
>> 
>>> On May 9, 2019, at 3:38 PM, Nick Foster >> <mailto:bistrom...@gmail.com>> 

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Oh, okay, I didn’t get that.  Understood now.  I have UHD 3.14.0 running on my 
main machine so I could try again some newer .bit files into the FPGA than I 
previously have tried (I tried the current version of UHD and N210 
usrp_n210_r4_fpga.bit to no avail) to see if any of them are compatible.  I 
also was able to build UHD 3.9.0 on a different machine so I can try that too 
with some of the other .bit files.  Will hold the safe button down while 
loading the FPGA this time around.  

Joe

> On May 9, 2019, at 3:38 PM, Nick Foster  wrote:
> 
> I'm saying that you might try to continue the effort to JTAG load a more 
> modern FPGA image. It's possible you have to hold down the safe mode button 
> while loading the image. 
> 
> On Thu, May 9, 2019, 2:22 PM Joe Martin  <mailto:k...@k5so.com>> wrote:
> Thanks for digging into that for us, Nick.  Interesting.  As the hardware 
> change to rev4 occurred around mid 2011 and the earliest UHD version that 
> exists on the files.ettus.com/uhd <http://files.ettus.com/uhd> page is Feb 
> 2104, what is the likelihood in your opinion that the UHD version will be 
> compatible with the rev2/3 hardware from 2011?   
> 
> So far I’ve not been successful in reviving the 2014 UHD version so I’m 
> asking to determine whether continued effort to do so is likely to yield 
> anything positive with respect to interfacing with the 2011 hardware.  
> 
> Joe
> 
>> On May 9, 2019, at 3:06 PM, Nick Foster > <mailto:bistrom...@gmail.com>> wrote:
>> 
>> So I really dug into the old archives here and literally pulled an old hard 
>> drive out of a closet, and found a copy of the old hardware repository from 
>> back in the days when N210 was called "USRP2+". Best that I can tell, we 
>> only ever released two versions to the public. We might have sold R3 
>> stickered as R2 -- I don't see anything in the repository that would 
>> indicate otherwise. Rev 2/3 was sold until around June or July 2011, when we 
>> moved to rev 4. The only firmware/host code changes I can see between any of 
>> the versions are that R4 used LVDS clocking to the daughterboard where 
>> previous versions used CMOS. So I think you should be able to run r3 
>> firmware on your N210.
>> 
>> That said, the very very old N210s with very very old firmware might not 
>> have used the same safe/production firmware/fpga image arrangement that we 
>> later arrived at. The hardware is still fine, but you might be in for a bit 
>> of a deep dive to get it all running again.
>> 
>> If you have a TTL-serial adapter or a logic analyzer that works as such, you 
>> can connect to the debug UART header and get printout information from the 
>> firmware at boot time. Another good idea would be to take a video of the 
>> front panel LEDs as you apply power -- the boot LED lights give good 
>> indication of the firmware/FPGA image loading process.
>> 
>> Nick
>> 
>> On Thu, May 9, 2019 at 1:42 PM Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> Thanks for the info, Marcus.  However, seeing that Jason went through this 
>> last year with a couple of N210 he has it would seem unlikely that all three 
>> of the N210 are broken.  That being said and considering what you jus said 
>> it seems that I should’ve been able to find some version of UHD that will 
>> successfully communicate with the firmware and fpga images stored in the 
>> unit;  I have not, using UHD versions from 3.9.0 to 3.14.0.  
>> 
>> I wanted to try with even earlier versions of UHD but am finding trouble in 
>> utilizing UHD v3.4.0 (earliest version I could find) as it seems that 
>> “prebuilt” v3.4.0 needs only Ubuntu 10.10 or 11.10 which so far I’m not able 
>> to successfully install and run.   Seems we’re running out of option on this 
>> one so the Deep Space Exploration Society, who I’m trying to help with this, 
>> may have to come to grasps with the notion that their N210 is a true brick. 
>> 
>> Joe
>> 
>>> On May 9, 2019, at 2:23 PM, Marcus D. Leech via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> On 05/09/2019 04:18 PM, Joe Martin via USRP-users wrote:
>>>> Nick, Ian, 
>>>> 
>>>> If this unit happens to be incorrectly labeled as a rev 2 N210 and it is 
>>>> actually a rev 3 N210, is there hope in being able to load rev 3 firmware 
>>>> and fpga images (which I have located previously and tried actually) with 
>>>> some available UHD version?  If so, would you be able to tell me which UHD 
>>>> version(s) might 

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Thanks for digging into that for us, Nick.  Interesting.  As the hardware 
change to rev4 occurred around mid 2011 and the earliest UHD version that 
exists on the files.ettus.com/uhd <http://files.ettus.com/uhd> page is Feb 
2104, what is the likelihood in your opinion that the UHD version will be 
compatible with the rev2/3 hardware from 2011?   

So far I’ve not been successful in reviving the 2014 UHD version so I’m asking 
to determine whether continued effort to do so is likely to yield anything 
positive with respect to interfacing with the 2011 hardware.  

Joe

> On May 9, 2019, at 3:06 PM, Nick Foster  wrote:
> 
> So I really dug into the old archives here and literally pulled an old hard 
> drive out of a closet, and found a copy of the old hardware repository from 
> back in the days when N210 was called "USRP2+". Best that I can tell, we only 
> ever released two versions to the public. We might have sold R3 stickered as 
> R2 -- I don't see anything in the repository that would indicate otherwise. 
> Rev 2/3 was sold until around June or July 2011, when we moved to rev 4. The 
> only firmware/host code changes I can see between any of the versions are 
> that R4 used LVDS clocking to the daughterboard where previous versions used 
> CMOS. So I think you should be able to run r3 firmware on your N210.
> 
> That said, the very very old N210s with very very old firmware might not have 
> used the same safe/production firmware/fpga image arrangement that we later 
> arrived at. The hardware is still fine, but you might be in for a bit of a 
> deep dive to get it all running again.
> 
> If you have a TTL-serial adapter or a logic analyzer that works as such, you 
> can connect to the debug UART header and get printout information from the 
> firmware at boot time. Another good idea would be to take a video of the 
> front panel LEDs as you apply power -- the boot LED lights give good 
> indication of the firmware/FPGA image loading process.
> 
> Nick
> 
> On Thu, May 9, 2019 at 1:42 PM Joe Martin via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> Thanks for the info, Marcus.  However, seeing that Jason went through this 
> last year with a couple of N210 he has it would seem unlikely that all three 
> of the N210 are broken.  That being said and considering what you jus said it 
> seems that I should’ve been able to find some version of UHD that will 
> successfully communicate with the firmware and fpga images stored in the 
> unit;  I have not, using UHD versions from 3.9.0 to 3.14.0.  
> 
> I wanted to try with even earlier versions of UHD but am finding trouble in 
> utilizing UHD v3.4.0 (earliest version I could find) as it seems that 
> “prebuilt” v3.4.0 needs only Ubuntu 10.10 or 11.10 which so far I’m not able 
> to successfully install and run.   Seems we’re running out of option on this 
> one so the Deep Space Exploration Society, who I’m trying to help with this, 
> may have to come to grasps with the notion that their N210 is a true brick. 
> 
> Joe
> 
>> On May 9, 2019, at 2:23 PM, Marcus D. Leech via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> On 05/09/2019 04:18 PM, Joe Martin via USRP-users wrote:
>>> Nick, Ian, 
>>> 
>>> If this unit happens to be incorrectly labeled as a rev 2 N210 and it is 
>>> actually a rev 3 N210, is there hope in being able to load rev 3 firmware 
>>> and fpga images (which I have located previously and tried actually) with 
>>> some available UHD version?  If so, would you be able to tell me which UHD 
>>> version(s) might be able to communicate with it?  
>>> 
>>> Joe
>>> 
>> Theoretically, most versions in the last several years should be able to 
>> talk to it.  In *general* UHD never drops support for older hardware,
>>   and tries to maintain compatibility.  Now, it is the case that newer 
>> features are almost never "back-ported", but basic functionality should
>>   always be there.  
>> 
>> What this *should* mean is that you should be able to use the firmware tools 
>> once the device is in "safe mode" to get yourself to where you
>>   want to be.  If that doesn't work, that may well mean that the hardware is 
>> broken, and it's unlikely to be economical to repair.
>> 
>> 
>>>> On May 9, 2019, at 2:12 PM, Joe Martin via USRP-users 
>>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>>> 
>>>> Okay.  I’ve asserted from the outset that it’s a rev 2, based on the 
>>>> factory label.  Is this N210 a lost cause if it is actually a Rev2 N210? 
>>>> 
>>>> Joe
>>>> 

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Thanks for the info, Marcus.  However, seeing that Jason went through this last 
year with a couple of N210 he has it would seem unlikely that all three of the 
N210 are broken.  That being said and considering what you jus said it seems 
that I should’ve been able to find some version of UHD that will successfully 
communicate with the firmware and fpga images stored in the unit;  I have not, 
using UHD versions from 3.9.0 to 3.14.0.  

I wanted to try with even earlier versions of UHD but am finding trouble in 
utilizing UHD v3.4.0 (earliest version I could find) as it seems that 
“prebuilt” v3.4.0 needs only Ubuntu 10.10 or 11.10 which so far I’m not able to 
successfully install and run.   Seems we’re running out of option on this one 
so the Deep Space Exploration Society, who I’m trying to help with this, may 
have to come to grasps with the notion that their N210 is a true brick. 

Joe

> On May 9, 2019, at 2:23 PM, Marcus D. Leech via USRP-users 
>  wrote:
> 
> On 05/09/2019 04:18 PM, Joe Martin via USRP-users wrote:
>> Nick, Ian, 
>> 
>> If this unit happens to be incorrectly labeled as a rev 2 N210 and it is 
>> actually a rev 3 N210, is there hope in being able to load rev 3 firmware 
>> and fpga images (which I have located previously and tried actually) with 
>> some available UHD version?  If so, would you be able to tell me which UHD 
>> version(s) might be able to communicate with it?  
>> 
>> Joe
>> 
> Theoretically, most versions in the last several years should be able to talk 
> to it.  In *general* UHD never drops support for older hardware,
>   and tries to maintain compatibility.  Now, it is the case that newer 
> features are almost never "back-ported", but basic functionality should
>   always be there.  
> 
> What this *should* mean is that you should be able to use the firmware tools 
> once the device is in "safe mode" to get yourself to where you
>   want to be.  If that doesn't work, that may well mean that the hardware is 
> broken, and it's unlikely to be economical to repair.
> 
> 
>>> On May 9, 2019, at 2:12 PM, Joe Martin via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> Okay.  I’ve asserted from the outset that it’s a rev 2, based on the 
>>> factory label.  Is this N210 a lost cause if it is actually a Rev2 N210? 
>>> 
>>> Joe
>>> 
>>>> On May 9, 2019, at 2:05 PM, Nick Foster >>> <mailto:bistrom...@gmail.com>> wrote:
>>>> 
>>>> Well, it's not a rev 4. It's either 2 or 3 in terms of hardware revision. 
>>>> 
>>>> On Thu, May 9, 2019 at 12:58 PM Joe Martin >>> <mailto:k...@k5so.com>> wrote:
>>>> …able to ping 192.168.10.2 successfully.
>>>> 
>>>>> On May 9, 2019, at 1:54 PM, Joe Martin >>>> <mailto:k...@k5so.com>> wrote:
>>>>> 
>>>>> Ian, 
>>>>> 
>>>>> Yes, I have tried many times to boot in safe mode, same result 
>>>>> regardless.  Yes, I am able to pin to 192.168.10.2 successfully. 
>>>>> 
>>>>> Joe
>>>>> 
>>>>>> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users 
>>>>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>>>>> 
>>>>>> Ian and Nick, 
>>>>>> 
>>>>>> Thanks for the assistance.  Attached are dropbox links to two snapshot 
>>>>>> photos:  1) the factory label on the back of the N210, showing N210 
>>>>>> r:2.0 and 2) a top side view of the N210. 
>>>>>> 
>>>>>> 1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 
>>>>>> <https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0>
>>>>>> 2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 
>>>>>> <https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0>
>>>>>> 
>>>>>> Seems this unit is indeed a rev 2 N210, yes? 
>>>>>> 
>>>>>> Joe
>>>>>> 
>>>>>>> On May 9, 2019, at 12:40 PM, Nick Foster >>>>>> <mailto:bistrom...@gmail.com>> wrote:
>>>>>>> 
>>>>>>> Moreover, the best "tell" is to look at the N210 motherboard. If the 
>>>>>>> SRAM chip is on the top side, it's a rev 2/3. If the SRAM is on the 
>>>>>>> bottom side, it's a rev 4. If you send a picture along of the top of 
>>>>&g

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Nick, Ian, 

If this unit happens to be incorrectly labeled as a rev 2 N210 and it is 
actually a rev 3 N210, is there hope in being able to load rev 3 firmware and 
fpga images (which I have located previously and tried actually) with some 
available UHD version?  If so, would you be able to tell me which UHD 
version(s) might be able to communicate with it?  

Joe

> On May 9, 2019, at 2:12 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Okay.  I’ve asserted from the outset that it’s a rev 2, based on the factory 
> label.  Is this N210 a lost cause if it is actually a Rev2 N210? 
> 
> Joe
> 
>> On May 9, 2019, at 2:05 PM, Nick Foster > <mailto:bistrom...@gmail.com>> wrote:
>> 
>> Well, it's not a rev 4. It's either 2 or 3 in terms of hardware revision. 
>> 
>> On Thu, May 9, 2019 at 12:58 PM Joe Martin > <mailto:k...@k5so.com>> wrote:
>> …able to ping 192.168.10.2 successfully.
>> 
>>> On May 9, 2019, at 1:54 PM, Joe Martin >> <mailto:k...@k5so.com>> wrote:
>>> 
>>> Ian, 
>>> 
>>> Yes, I have tried many times to boot in safe mode, same result regardless.  
>>> Yes, I am able to pin to 192.168.10.2 successfully. 
>>> 
>>> Joe
>>> 
>>>> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users 
>>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>>> 
>>>> Ian and Nick, 
>>>> 
>>>> Thanks for the assistance.  Attached are dropbox links to two snapshot 
>>>> photos:  1) the factory label on the back of the N210, showing N210 r:2.0 
>>>> and 2) a top side view of the N210. 
>>>> 
>>>> 1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 
>>>> <https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0>
>>>> 2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 
>>>> <https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0>
>>>> 
>>>> Seems this unit is indeed a rev 2 N210, yes? 
>>>> 
>>>> Joe
>>>> 
>>>>> On May 9, 2019, at 12:40 PM, Nick Foster >>>> <mailto:bistrom...@gmail.com>> wrote:
>>>>> 
>>>>> Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM 
>>>>> chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom 
>>>>> side, it's a rev 4. If you send a picture along of the top of the N210, I 
>>>>> can tell you if it's early or late rev.
>>>>> 
>>>>> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users 
>>>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>>>> Joe,
>>>>> So I scratched my head about this a little late last night and looked 
>>>>> back through the development repository for the N210 and as far as I can 
>>>>> tell there was never customer facing FPGA code for a Rev2 N210. Chatting 
>>>>> with Matt this morning he shared my feeling that a Rev2 wasn't sold to 
>>>>> customers, so I'm curious if you have a unit that has a factory label 
>>>>> that says N210Rev2 or if you have seen "usrp2 rev2.0" on the PCB (which 
>>>>> can be missleading).
>>>>> 
>>>>> Also have you tried booting into the safe image and verifying that it at 
>>>>> least pings on 192.168.10.2?
>>>>> 
>>>>> If we can conclusively identify which rev of h/w you have I can probably 
>>>>> help further.
>>>>> 
>>>>> Ian
>>>> 
>>>> ___
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>>>> http://lists.ettus.com/mailman/listinfo/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] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Okay.  I’ve asserted from the outset that it’s a rev 2, based on the factory 
label.  Is this N210 a lost cause if it is actually a Rev2 N210? 

Joe

> On May 9, 2019, at 2:05 PM, Nick Foster  wrote:
> 
> Well, it's not a rev 4. It's either 2 or 3 in terms of hardware revision. 
> 
> On Thu, May 9, 2019 at 12:58 PM Joe Martin  <mailto:k...@k5so.com>> wrote:
> …able to ping 192.168.10.2 successfully.
> 
>> On May 9, 2019, at 1:54 PM, Joe Martin > <mailto:k...@k5so.com>> wrote:
>> 
>> Ian, 
>> 
>> Yes, I have tried many times to boot in safe mode, same result regardless.  
>> Yes, I am able to pin to 192.168.10.2 successfully. 
>> 
>> Joe
>> 
>>> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> 
>>> Ian and Nick, 
>>> 
>>> Thanks for the assistance.  Attached are dropbox links to two snapshot 
>>> photos:  1) the factory label on the back of the N210, showing N210 r:2.0 
>>> and 2) a top side view of the N210. 
>>> 
>>> 1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 
>>> <https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0>
>>> 2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 
>>> <https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0>
>>> 
>>> Seems this unit is indeed a rev 2 N210, yes? 
>>> 
>>> Joe
>>> 
>>>> On May 9, 2019, at 12:40 PM, Nick Foster >>> <mailto:bistrom...@gmail.com>> wrote:
>>>> 
>>>> Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM 
>>>> chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom 
>>>> side, it's a rev 4. If you send a picture along of the top of the N210, I 
>>>> can tell you if it's early or late rev.
>>>> 
>>>> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users 
>>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>>> Joe,
>>>> So I scratched my head about this a little late last night and looked back 
>>>> through the development repository for the N210 and as far as I can tell 
>>>> there was never customer facing FPGA code for a Rev2 N210. Chatting with 
>>>> Matt this morning he shared my feeling that a Rev2 wasn't sold to 
>>>> customers, so I'm curious if you have a unit that has a factory label that 
>>>> says N210Rev2 or if you have seen "usrp2 rev2.0" on the PCB (which can be 
>>>> missleading).
>>>> 
>>>> Also have you tried booting into the safe image and verifying that it at 
>>>> least pings on 192.168.10.2?
>>>> 
>>>> If we can conclusively identify which rev of h/w you have I can probably 
>>>> help further.
>>>> 
>>>> Ian
>>> 
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>>> http://lists.ettus.com/mailman/listinfo/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] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

…able to ping 192.168.10.2 successfully.

> On May 9, 2019, at 1:54 PM, Joe Martin  wrote:
> 
> Ian, 
> 
> Yes, I have tried many times to boot in safe mode, same result regardless.  
> Yes, I am able to pin to 192.168.10.2 successfully. 
> 
> Joe
> 
>> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Ian and Nick, 
>> 
>> Thanks for the assistance.  Attached are dropbox links to two snapshot 
>> photos:  1) the factory label on the back of the N210, showing N210 r:2.0 
>> and 2) a top side view of the N210. 
>> 
>> 1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 
>> <https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0>
>> 2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 
>> <https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0>
>> 
>> Seems this unit is indeed a rev 2 N210, yes? 
>> 
>> Joe
>> 
>>> On May 9, 2019, at 12:40 PM, Nick Foster >> <mailto:bistrom...@gmail.com>> wrote:
>>> 
>>> Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM 
>>> chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom side, 
>>> it's a rev 4. If you send a picture along of the top of the N210, I can 
>>> tell you if it's early or late rev.
>>> 
>>> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> Joe,
>>> So I scratched my head about this a little late last night and looked back 
>>> through the development repository for the N210 and as far as I can tell 
>>> there was never customer facing FPGA code for a Rev2 N210. Chatting with 
>>> Matt this morning he shared my feeling that a Rev2 wasn't sold to 
>>> customers, so I'm curious if you have a unit that has a factory label that 
>>> says N210Rev2 or if you have seen "usrp2 rev2.0" on the PCB (which can be 
>>> missleading).
>>> 
>>> Also have you tried booting into the safe image and verifying that it at 
>>> least pings on 192.168.10.2?
>>> 
>>> If we can conclusively identify which rev of h/w you have I can probably 
>>> help further.
>>> 
>>> Ian
>> 
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto: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] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Ian, 

Yes, I have tried many times to boot in safe mode, same result regardless.  
Yes, I am able to pin to 192.168.10.2 successfully. 

Joe

> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Ian and Nick, 
> 
> Thanks for the assistance.  Attached are dropbox links to two snapshot 
> photos:  1) the factory label on the back of the N210, showing N210 r:2.0 and 
> 2) a top side view of the N210. 
> 
> 1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 
> <https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0>
> 2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 
> <https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0>
> 
> Seems this unit is indeed a rev 2 N210, yes? 
> 
> Joe
> 
>> On May 9, 2019, at 12:40 PM, Nick Foster > <mailto:bistrom...@gmail.com>> wrote:
>> 
>> Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM 
>> chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom side, 
>> it's a rev 4. If you send a picture along of the top of the N210, I can tell 
>> you if it's early or late rev.
>> 
>> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> Joe,
>> So I scratched my head about this a little late last night and looked back 
>> through the development repository for the N210 and as far as I can tell 
>> there was never customer facing FPGA code for a Rev2 N210. Chatting with 
>> Matt this morning he shared my feeling that a Rev2 wasn't sold to customers, 
>> so I'm curious if you have a unit that has a factory label that says 
>> N210Rev2 or if you have seen "usrp2 rev2.0" on the PCB (which can be 
>> missleading).
>> 
>> Also have you tried booting into the safe image and verifying that it at 
>> least pings on 192.168.10.2?
>> 
>> If we can conclusively identify which rev of h/w you have I can probably 
>> help further.
>> 
>> Ian
> 
> ___
> 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] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Ian and Nick, 

Thanks for the assistance.  Attached are dropbox links to two snapshot photos:  
1) the factory label on the back of the N210, showing N210 r:2.0 and 2) a top 
side view of the N210. 

1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0 

2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0 


Seems this unit is indeed a rev 2 N210, yes? 

Joe

> On May 9, 2019, at 12:40 PM, Nick Foster  wrote:
> 
> Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM 
> chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom side, 
> it's a rev 4. If you send a picture along of the top of the N210, I can tell 
> you if it's early or late rev.
> 
> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> Joe,
> So I scratched my head about this a little late last night and looked back 
> through the development repository for the N210 and as far as I can tell 
> there was never customer facing FPGA code for a Rev2 N210. Chatting with Matt 
> this morning he shared my feeling that a Rev2 wasn't sold to customers, so 
> I'm curious if you have a unit that has a factory label that says N210Rev2 or 
> if you have seen "usrp2 rev2.0" on the PCB (which can be missleading).
> 
> Also have you tried booting into the safe image and verifying that it at 
> least pings on 192.168.10.2?
> 
> If we can conclusively identify which rev of h/w you have I can probably help 
> further.
> 
> Ian

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

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

Argh.  Yes, maybe that’s what I will need to do then.  I’ll try it. 

Looks like the earliest vintage of UHD that’s available is Feb 2014 (v3.4.0), 
which is about 4 years after the Rev2 N210, I think.  So that UHD version may 
still be too recent to work with the Rev2 N210.  That’ll be my last attempt 
before abandoning the thing as you did with yours.  

Thanks for the comments and help, Jason.  Good luck with your projects!

Joe

> On May 9, 2019, at 8:20 AM, Jason Matusiak  
> wrote:
> 
> Maybe try running a VM of a version of Ubuntu that is roughly the vintage of 
> that version of UHD?
> 
> 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: Thursday, May 9, 2019 9:53 AM
> To: Joe Martin
> Cc: usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>
> Subject: [USRP-users] Need a little help with running legacy prebuilt UHD 
> versions
>  
> I need a bit of help to understand how to run legacy prebuilt UHD versions 
> from the files.ettus.com/binaries/uhd <http://files.ettus.com/binaries/uhd> 
> repository.  
> 
> I would like to try various UHD versions to try to find a version that will 
> run with an elderly (Rev 2) N210 with unknown firmware/fpga images in it.  
> After downloading a legacy version, e.g., 
> uhd_003.004.000-release_Ubuntu-11.10-x86_64.deb, and clicking “install” I am 
> not understanding what I need to do next to actually run the version, as 
> uhd_usrp_probe —version reports the version of UHD that I originally had 
> installed, not the legacy version I intended to install.  
> 
> I am running Ubuntu 18.04, should I expect to be able to run the legacy 
> versions labeled, for example, *_Ubuntu-11.10-x86_64.deb, as in the example 
> above ? 
> 
> Clearly I’m missing something fundamental, and likely simple, in my 
> understanding about how to use these prebuilt older versions.  I have had no 
> problem building, installing, and running UHD versions from source but I have 
> never tried to run a “prebuilt” version before. 
> 
> Joe

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

[USRP-users] Need a little help with running legacy prebuilt UHD versions

[Joe Martin via USRP-users]

I need a bit of help to understand how to run legacy prebuilt UHD versions from 
the files.ettus.com/binaries/uhd  
repository.  

I would like to try various UHD versions to try to find a version that will run 
with an elderly (Rev 2) N210 with unknown firmware/fpga images in it.  After 
downloading a legacy version, e.g., 
uhd_003.004.000-release_Ubuntu-11.10-x86_64.deb, and clicking “install” I am 
not understanding what I need to do next to actually run the version, as 
uhd_usrp_probe —version reports the version of UHD that I originally had 
installed, not the legacy version I intended to install.  

I am running Ubuntu 18.04, should I expect to be able to run the legacy 
versions labeled, for example, *_Ubuntu-11.10-x86_64.deb, as in the example 
above ? 

Clearly I’m missing something fundamental, and likely simple, in my 
understanding about how to use these prebuilt older versions.  I have had no 
problem building, installing, and running UHD versions from source but I have 
never tried to run a “prebuilt” version before. 

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]

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?
>>>&g

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?
>

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:
>>>>> 
>>&

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/ 
> <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 >> <mailto:bistrom...@gmail.com>> 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 >> <mailto:k...@k5so.com>> 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 >>>> <mailto:bistrom...@gmail.com>> 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 >>>> <mailto:bistrom...@gmail.com>> 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:
>&

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 > <mailto:bistrom...@gmail.com>> 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 > <mailto:k...@k5so.com>> 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 >>> <mailto:bistrom...@gmail.com>> 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 >>> <mailto:bistrom...@gmail.com>> 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
>>>>>  
>>>>> <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...

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  <mailto:k...@k5so.com>> 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 >> <mailto:bistrom...@gmail.com>> 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 >> <mailto:bistrom...@gmail.com>> 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
>>>>  
>>>> <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 <mailto: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

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 > <mailto:bistrom...@gmail.com>> 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 > <mailto:bistrom...@gmail.com>> 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
>>>  
>>> <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 <mailto: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 und

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  <mailto:bistrom...@gmail.com>> 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
>>  
>> <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 <mailto: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 <mailto:USRP-users@lists.ettus.com>
> http://lists.ettus.com/mailman/listinfo/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 > <mailto:robin.c...@ettus.com>> 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
>>  
>> <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 > <mailto:k...@k5so.com>> 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 <http://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
>>>>  
>>>> <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
>>>>>>  
>>>>>> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html>
>>>>>> 
>>>>&g

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
>  
> <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  <mailto:k...@k5so.com>> 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 <http://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
>>>  
>>> <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
>>>>>  
>>>>> <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 <mailto: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.co

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 <http://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
>>  
>> <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
>>>>  
>>>> <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 <mailto: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 programm

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
>  
> <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 <mailto: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 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

Re: [USRP-users] X310 unable to connect after recovery procedure

[Joe Martin via USRP-users]

Thanks, Nicolas.  I am interested to hear how you eventually clear the problem 
as I also have an X310 and so far all works fine but someday I may face the 
same issue as you are experiencing so please when you find a solution please 
post it.  I am not experienced enough yet with mine to be able to suggest a 
solution for you unfortunately.  Maybe someone else can. 

 I (like you) am eager to hear any suggestion(s) to resolve your issue.

Regards, 

Joe

> On Mar 25, 2019, at 9:28 AM, Nicolas GALLAND  wrote:
> 
> Hi,
> 
> it is indeed a typo here. I did ping 192.168.10.2 first, and then I tried on 
> 192.168.10.3 to see if the error message was the same. In any case (even 
> using ping broadcast on all the sub network my computer is connected to) i 
> have this message. It looks like there is a connection between the computer 
> and the device, since my computer says there is no more network when I switch 
> off the USRP.
> 
> Kind regards
> 
> Nicolas
> Le 22/03/2019 à 18:52, Joe Martin a écrit :
>> Nicolas,
>> 
>> It appears you were pinging 192.168.10.3, not 192.168.10.2.  Maybe this 
>> particular example was simply a typo and you used the correct IP address to 
>> ping during your other tests?
>> 
>> Regards,
>> 
>> Joe
>> 
>>> On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users 
>>>  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> I had some trouble with my X310 and I needed to upload my UHD installation 
>>> and consequently to update the FPGA image on the board. After doing it 
>>> through eternet port, I lost connection so I decide to follow the recovery 
>>> procedure to upload the FPGA image using the JTAG port (following 
>>> https://kb.ettus.com/X300/X310_Device_Recovery).
>>> 
>>> The upload is fine, and the computer recognises the network with IP address 
>>> 192.168.10.1, but when I try to ping 192.168.10.2 (as explained in the 
>>> procedure) I have
>>> 
>>> PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
>>> From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=5 Destination Host Unreachable
>>> 
>>> until I stop it. I have two x310 in the same situation, and I tried on two 
>>> different computers with different ethernet cables.
>>> 
>>> Could the hardware be broken ? (If so, isn't it strange that the computer 
>>> still sees the network ?)
>>> 
>>> Thanks a lot, and nice week end !
>>> 
>>> Kind regards,
>>> 
>>> Nicolas
>>> 
> 


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

Re: [USRP-users] X310 unable to connect after recovery procedure

[Joe Martin via USRP-users]

Nicolas, 

It appears you were pinging 192.168.10.3, not 192.168.10.2.  Maybe this 
particular example was simply a typo and you used the correct IP address to 
ping during your other tests?

Regards, 

Joe

> On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users 
>  wrote:
> 
> Hello everyone,
> 
> I had some trouble with my X310 and I needed to upload my UHD installation 
> and consequently to update the FPGA image on the board. After doing it 
> through eternet port, I lost connection so I decide to follow the recovery 
> procedure to upload the FPGA image using the JTAG port (following 
> https://kb.ettus.com/X300/X310_Device_Recovery).
> 
> The upload is fine, and the computer recognises the network with IP address 
> 192.168.10.1, but when I try to ping 192.168.10.2 (as explained in the 
> procedure) I have
> 
> PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
> From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
> From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
> From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
> From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
> From 192.168.10.1 icmp_seq=5 Destination Host Unreachable
> 
> until I stop it. I have two x310 in the same situation, and I tried on two 
> different computers with different ethernet cables.
> 
> Could the hardware be broken ? (If so, isn't it strange that the computer 
> still sees the network ?)
> 
> Thanks a lot, and nice week end !
> 
> Kind regards,
> 
> Nicolas
> 


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

Re: [USRP-users] link led colour

[Joe Martin via USRP-users]

No problem, Marcus.  Thanks! 

Best regards, 

Joe

> On Mar 12, 2019, at 2:31 AM, Marcus Müller  wrote:
> 
> Hi Koyel, Wade and Joe,
> 
> ah! My bad. I got my X310 out of the cupboard and was so concentrated
> on figuring which red LED was meant that I really focused on the back
> panel – and forgot there's literally a "LINK" LED on the front of the
> USRP. My apologies!
> 
> You'll have to do a bit of a deeper dive, but you'll find out that the
> LINK indicator basically shines whenever there's rx or tx active, far
> as I read db_control.v.
> 
> Best regards, and again, my apologies,
> Marcus
> 
> On Mon, 2019-03-11 at 17:27 -0500, Wade Fife wrote:
>> As far as I can tell, the LED color hasn't changed. Page 13 has the
>> SFP status LEDs, which show through the panel above the SFPs. These
>> are green for link (left, above the SFP) and yellow for activity
>> (right, above the SFP).
>> 
>> Page 14 has the "LINK" LED, which shows through on the opposite end
>> of the USRP (next to the RF ports). This one is a RED/GREEN bicolor.
>> I think this LED is a combination of the PCIe and Ethernet status.
>> Orange is what you get when both RED and GREEN are on at the same
>> time. I have an X310 on my desk and this LED varies between red,
>> orange, yellow, and green, depending on how the LEDs are flashing.
>> 
>> I think the behavior Koyel is seeing is expected and just means
>> there's data being transferred, assuming Koyel is looking at the LINK
>> LED that's next to the RF ports.
>> 
>> Thanks,
>> 
>> Wade
>> 
>> On Thu, Mar 7, 2019 at 7:48 PM Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>> Interestingly, my X310 front panel LED occasionally, very briefly
>>> shows red too.  Maybe the schematic isn’t current with what is
>>> actually used in the unit these days(?).  
>>> 
>>> Regards, 
>>> 
>>> Joe
>>> 
>>>> On Mar 7, 2019, at 3:36 PM, Marcus Müller via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>> 
>>>> So that's built on an X3x0 platform. As said, no, the link leds
>>> really
>>>> just display link status, nothing about the data.
>>>> Also, when you look at the schematic of the X300, PDF [1] page
>>> 13,
>>>> you'll find no red LED – only green and yellow, so I must admit
>>> I'm a
>>>> bit confused about what you witnessed?
>>>> 
>>>> Best regards,
>>>> Marcus
>>>> 
>>>> [1] http://files.ettus.com/schematics/x300/x3xx.pdf
>>>> On Thu, 2019-03-07 at 09:56 +, Koyel Das (Vehere) wrote:
>>>>> I am using USRP 2955 R
>>>>> 
>>>>> Koyel Das 
>>>>> Senior – Product Engineer
>>>>> Vehere | Proactive Communications Intelligence & Cyber Defence
>>>>> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
>>>>> www.vehere.com
>>>>> 
>>>>> 
>>>>> 
>>>>> Vehere is the proud recipient of the Fastest Growing Technology
>>>>> Company Awards in India & Asia since 2012!
>>>>> 
>>>>> The content of this e-mail is confidential and intended solely
>>> for
>>>>> the use of the addressee. The text of this email (including any
>>>>> attachments) may contain information, which is proprietary
>>> and/or
>>>>> confidential or privileged in nature belonging to Vehere
>>> Interactive
>>>>> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If
>>> you
>>>>> are not the addressee, or the person responsible for delivering
>>> it to
>>>>> the addressee, any disclosure, copying, distribution or any
>>> action
>>>>> taken or omitted to be taken in reliance on it is prohibited and
>>> may
>>>>> be unlawful. If you have received this e-mail in error, please
>>> notify
>>>>> the sender and remove this communication entirely from your
>>> system.
>>>>> The recipient acknowledges that no guarantee or any warranty is
>>> given
>>>>> as to completeness and accuracy of the content of the email. The
>>>>> recipient further acknowledges that the views contained in the
>>> email
>>>>> message are those of the sender and may not necessarily reflect
>>> those
>>>>> 

Re: [USRP-users] Problem with usrp-2900 and GNU Radio

[Joe Martin via USRP-users]

…and I’m using GNURadio version 3.7.13.4. 

Joe

> On Mar 9, 2019, at 12:35 PM, Joe Martin via USRP-users 
>  wrote:
> 
> Hi Thomas, 
> 
> I also am new to USRP so if I tell you something that is not correct perhaps 
> someone more knowledgeable will weigh in and correct me for both our 
> benefits.  
> 
> The error you received indicates (I think) that the FPGA firmware version and 
> the UHD version you have installed are incompatible.  I obtained this same 
> type of error when first bringing up my x310.  To cure it, I had to find a 
> pair of versions of firmware and software that are compatible.  In my case I 
> found that X300 firmware version 36.0 works with UHD version 3.14.0 so that’s 
> what I am currently using.  
> 
> It wasn’t clear to me (and still isn’t) how one determines which firmware and 
> software versions are compatible.  If there is a way to do that I’ll be 
> interested in learning about how to do it.  I simply used a trial and error 
> method until I found a pair that worked together.  Basically, I installed the 
> latest UHD version of software and found that X300 XG FPGA v36.0 firmware 
> worked with it on my USRP.  
> 
> Good luck, I know it can be frustrating when you don’t know all that you need 
> to know to make things work smoothly, but things do get better in terms of 
> your understanding if you hammer on the issues long enough.  
> 
> Maybe this is enough of a hint to allow you to make progress on it for your 
> USRP?  
> 
> Joe
> 
>> On Mar 9, 2019, at 12:00 PM, Thomas Lavarenne via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> 
>> Yes, it worked, but the script were on /usr/lib/uhd/utils/ and same error...
>> 
>> sudo /usr/lib/uhd/utils/uhd_images_downloader.py
>> [sudo] Mot de passe de user : 
>> [INFO] Images destination: /usr/share/uhd/images
>> [INFO] Target usrp1_b100_fw_default is up to date.
>> [INFO] Target x3xx_x310_fpga_default is up to date.
>> [INFO] Target usrp2_n210_fpga_default is up to date.
>> [INFO] Target n230_n230_fpga_default is up to date.
>> [INFO] Target usrp1_b100_fpga_default is up to date.
>> [INFO] Target b2xx_b200_fpga_default is up to date.
>> [INFO] Target usrp2_n200_fpga_default is up to date.
>> [INFO] Target e3xx_e320_fpga_default is up to date.
>> [INFO] Target n3xx_n310_fpga_default is up to date.
>> [INFO] Target b2xx_b205mini_fpga_default is up to date.
>> [INFO] Target x3xx_x300_fpga_default is up to date.
>> [INFO] Target octoclock_octoclock_fw_default is up to date.
>> [INFO] Target usrp2_usrp2_fw_default is up to date.
>> [INFO] Target usrp2_n200_fw_default is up to date.
>> [INFO] Target usrp2_usrp2_fpga_default is up to date.
>> [INFO] Target b2xx_common_fw_default is up to date.
>> [INFO] Target b2xx_b200mini_fpga_default is up to date.
>> [INFO] Target usrp1_usrp1_fpga_default is up to date.
>> [INFO] Target usb_common_windrv_default is up to date.
>> [INFO] Target usrp2_n210_fw_default is up to date.
>> [INFO] Target n3xx_n300_fpga_default is up to date.
>> [INFO] Target e3xx_e310_fpga_default is up to date.
>> [INFO] Target b2xx_b210_fpga_default is up to date.
>> 
>> 
>> Le sam. 9 mars 2019 à 19:58, Brian Padalino > <mailto:bpadal...@gmail.com>> a écrit :
>> On Sat, Mar 9, 2019 at 1:45 PM Thomas Lavarenne via USRP-users 
>> mailto:usrp-users@lists.ettus.com>> wrote:
>> Hello,
>> I'm new here and pretty new with usrp. I'm trying to use usrp-2900 with GNU 
>> Radio and Ubuntu 18.04, but i have this problem (latest driver uhd from 
>> source):
>> 
>> '''
>> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
>> 
>> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
>> -- Detected Device: B200
>> -- Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... done
>> -- Operating over USB 3.
>> Traceback (most recent call last):
>>   File "/home/user/top_block.py", line 166, in 
>> main()
>>   File "/home/user/top_block.py", line 154, in main
>> tb = top_block_cls()
>>   File "/home/user/top_block.py", line 78, in __init__
>> channels=range(1),
>>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 
>> 122, in constructor_interceptor
>> return old_constructor(*args)
>>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 
>> 2683, in make
>> return _uhd_swig.usrp_source_make(*args)
>> RuntimeError: RuntimeError: Expected FPGA compatibility number 14, but got 
>

Re: [USRP-users] Problem with usrp-2900 and GNU Radio

[Joe Martin via USRP-users]

Hi Thomas, 

I also am new to USRP so if I tell you something that is not correct perhaps 
someone more knowledgeable will weigh in and correct me for both our benefits.  

The error you received indicates (I think) that the FPGA firmware version and 
the UHD version you have installed are incompatible.  I obtained this same type 
of error when first bringing up my x310.  To cure it, I had to find a pair of 
versions of firmware and software that are compatible.  In my case I found that 
X300 firmware version 36.0 works with UHD version 3.14.0 so that’s what I am 
currently using.  

It wasn’t clear to me (and still isn’t) how one determines which firmware and 
software versions are compatible.  If there is a way to do that I’ll be 
interested in learning about how to do it.  I simply used a trial and error 
method until I found a pair that worked together.  Basically, I installed the 
latest UHD version of software and found that X300 XG FPGA v36.0 firmware 
worked with it on my USRP.  

Good luck, I know it can be frustrating when you don’t know all that you need 
to know to make things work smoothly, but things do get better in terms of your 
understanding if you hammer on the issues long enough.  

Maybe this is enough of a hint to allow you to make progress on it for your 
USRP?  

Joe

> On Mar 9, 2019, at 12:00 PM, Thomas Lavarenne via USRP-users 
>  wrote:
> 
> Yes, it worked, but the script were on /usr/lib/uhd/utils/ and same error...
> 
> sudo /usr/lib/uhd/utils/uhd_images_downloader.py
> [sudo] Mot de passe de user : 
> [INFO] Images destination: /usr/share/uhd/images
> [INFO] Target usrp1_b100_fw_default is up to date.
> [INFO] Target x3xx_x310_fpga_default is up to date.
> [INFO] Target usrp2_n210_fpga_default is up to date.
> [INFO] Target n230_n230_fpga_default is up to date.
> [INFO] Target usrp1_b100_fpga_default is up to date.
> [INFO] Target b2xx_b200_fpga_default is up to date.
> [INFO] Target usrp2_n200_fpga_default is up to date.
> [INFO] Target e3xx_e320_fpga_default is up to date.
> [INFO] Target n3xx_n310_fpga_default is up to date.
> [INFO] Target b2xx_b205mini_fpga_default is up to date.
> [INFO] Target x3xx_x300_fpga_default is up to date.
> [INFO] Target octoclock_octoclock_fw_default is up to date.
> [INFO] Target usrp2_usrp2_fw_default is up to date.
> [INFO] Target usrp2_n200_fw_default is up to date.
> [INFO] Target usrp2_usrp2_fpga_default is up to date.
> [INFO] Target b2xx_common_fw_default is up to date.
> [INFO] Target b2xx_b200mini_fpga_default is up to date.
> [INFO] Target usrp1_usrp1_fpga_default is up to date.
> [INFO] Target usb_common_windrv_default is up to date.
> [INFO] Target usrp2_n210_fw_default is up to date.
> [INFO] Target n3xx_n300_fpga_default is up to date.
> [INFO] Target e3xx_e310_fpga_default is up to date.
> [INFO] Target b2xx_b210_fpga_default is up to date.
> 
> 
> Le sam. 9 mars 2019 à 19:58, Brian Padalino  > a écrit :
> On Sat, Mar 9, 2019 at 1:45 PM Thomas Lavarenne via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> Hello,
> I'm new here and pretty new with usrp. I'm trying to use usrp-2900 with GNU 
> Radio and Ubuntu 18.04, but i have this problem (latest driver uhd from 
> source):
> 
> '''
> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown
> 
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
> -- Detected Device: B200
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b200_fpga.bin... done
> -- Operating over USB 3.
> Traceback (most recent call last):
>   File "/home/user/top_block.py", line 166, in 
> main()
>   File "/home/user/top_block.py", line 154, in main
> tb = top_block_cls()
>   File "/home/user/top_block.py", line 78, in __init__
> channels=range(1),
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line 122, 
> in constructor_interceptor
> return old_constructor(*args)
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line 
> 2683, in make
> return _uhd_swig.usrp_source_make(*args)
> RuntimeError: RuntimeError: Expected FPGA compatibility number 14, but got 16:
> The FPGA build is not compatible with the host code build.
> Please run:
> 
>  "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
> 
> >>> Done
> 
> Any ideas accepted!
> 
> Have you tried running:
> 
>   $ sudo /usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py
> 
> As the message suggests?
> 
> Brian
> ___
> 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] Recording the full X3x0 bandwidth

[Joe Martin via USRP-users]

Thank you Mark-Jan for the additional information.  I’ll study it and compare 
with my system.  Much appreciated. 

Best regards, 

Joe

> On Mar 9, 2019, at 11:19 AM, Mark-Jan Bastian  wrote:
> 
> Hi Joe,
> 
> With sudo lspci -vvv you will see the capabilties, including the low-level
> PCIe bus speed and link count negotiation of the devices. The sudo is needed
> to get the low-level LnkCap and LnkCtl bits:
> 
> For a 16-lane videocard on a laptop here, likely soldered right on the 
> motherboard:
> 
> The PCIe capabilities: 8 GT/sec, max 16 lanes:
>   LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit 
> Latency L0s <1us, L1 <4us
>   ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
> What the speed ended up to be 8GT/sec, 16 lanes:
>   LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
>   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
>   LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ 
> DLActive- BWMgmt- ABWMgmt-
>   DevCap2: Completion Timeout: Range AB, TimeoutDis+, LTR+, OBFF 
> Via message
>   DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR+, 
> OBFF Disabled
> Below is a variant of the LnkCtl record, providing even more information on 
> even the equalisation of the
> SERDES link that is used by this PCIe device: (equalisation is the analog RF 
> signal processing to overcome 
> losses while routing the signal over the motherboard and the connectors):
>   LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
>Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>Compliance De-emphasis: -6dB
>   LnkSta2: Current De-emphasis Level: -6dB, 
> EqualizationComplete+, EqualizationPhase1+
>EqualizationPhase2+, EqualizationPhase3+, 
> LinkEqualizationRequest-
> 
> Above could be regarded as a 'depth first' approach for those who would like 
> to stay purely software-oriented.
> I like to treat a PC in such scenario as an embedded system,  first get the 
> powersupplies, clocks and other 
> hardware right, design the clockdomains and datarates, then gradually move up 
> the software/control/kernel/driver 
> stack to verify for anomalies that could trigger such intermittent problems.
> 
> Mark-Jan
> 
> On Sat, Mar 09, 2019 at 10:40:39AM -0700, Joe Martin wrote:
>> Hi Mark, 
>> 
>> I am intrigued by your response and have obtained a tree view for my system 
>> as you suggested to Paul.  I???m unfamiliar with the tree view and don???t 
>> understand how to check the number of PCIe lanes that are available to the 
>> disk controller and disks and how to check how many PCIe bridges are in 
>> between on my motherboard configuration.  
>> 
>> I have a screenshot of the tree view showing my 10G ethernet connection (but 
>> it is 220KB in size so I didn???t attach it here) but I am not familiar with 
>> how to determine what you asked about from the tree and what to do about the 
>> configuration in any case.  Is the configuration fixed and not changeable, 
>> in any case?  
>> 
>> If so, then perhaps your alternative suggestion regarding booting from a USB 
>> stick into a ramdisk is a viable route?  I???m unfortunately not familiar 
>> with the details of how to do that so perhaps a couple of brief comments 
>> about implementing that process would help me understand better if that???s 
>> the only viable alternative to pursue given the present hardware 
>> configuration?  
>> 
>> Joe
>> 
>>> On Mar 9, 2019, at 5:14 AM, Mark-Jan Bastian via USRP-users 
>>>  wrote:
>>> 
>>> Hi Paul,
>>> 
>>> I can record from the X310 to disk to nvme x4 PCIe at 800 MB/sec 
>>> for a few minutes. There is still a risk of O 's appearing.
>>> 
>>> First thing to check is the number of PCIe lanes available to the disk
>>> controller and disks, and how many and which PCIe bridges are in between
>>> on your motherboard configuration. Try to avoid other traffic over these
>>> PCIe bridges. lspci -vt for a tree view.
>>> 
>>> Then one can do benchmarking from DRAM to disk. Perhaps you will not need
>>> a filesystem for your very simple storage purpose.
>>> You can ultimately just boot from some other media (USB stick or CD-ROM
>>> loaded into a ramdisk) just to make sure there is absolute no need to 
>>> read-access any other data on said disks, via cached pages or otherwise.
>>> 
>>> Hickups by system management mode or other unexpected driver interrupt 
>>> sources
>>> should be minimized. Other networking code and chatter might need be 
>>> reduced,
>>> just as SMM related thermal management events in the BIOS.
>>> First tune everthing for maximum performance, then optimize for very 
>>> constant 
>>> write performance.
>>> 
>>> Mark-Jan
>>> 
>>> On Sat, Mar 09, 2019 at 12:32:05PM +0100, Paul Boven via USRP-users wrote:
 Hi,
 
 I'm trying to record the full 

Re: [USRP-users] Recording the full X3x0 bandwidth

[Joe Martin via USRP-users]

My apologies, I meant to say “Mark-Jan”!

> On Mar 9, 2019, at 10:40 AM, Joe Martin  wrote:
> 
> Hi Mark, 
> 
> I am intrigued by your response and have obtained a tree view for my system 
> as you suggested to Paul.  I’m unfamiliar with the tree view and don’t 
> understand how to check the number of PCIe lanes that are available to the 
> disk controller and disks and how to check how many PCIe bridges are in 
> between on my motherboard configuration.  
> 
> I have a screenshot of the tree view showing my 10G ethernet connection (but 
> it is 220KB in size so I didn’t attach it here) but I am not familiar with 
> how to determine what you asked about from the tree and what to do about the 
> configuration in any case.  Is the configuration fixed and not changeable, in 
> any case?  
> 
> If so, then perhaps your alternative suggestion regarding booting from a USB 
> stick into a ramdisk is a viable route?  I’m unfortunately not familiar with 
> the details of how to do that so perhaps a couple of brief comments about 
> implementing that process would help me understand better if that’s the only 
> viable alternative to pursue given the present hardware configuration?  
> 
> Joe
> 
>> On Mar 9, 2019, at 5:14 AM, Mark-Jan Bastian via USRP-users 
>>  wrote:
>> 
>> Hi Paul,
>> 
>> I can record from the X310 to disk to nvme x4 PCIe at 800 MB/sec 
>> for a few minutes. There is still a risk of O 's appearing.
>> 
>> First thing to check is the number of PCIe lanes available to the disk
>> controller and disks, and how many and which PCIe bridges are in between
>> on your motherboard configuration. Try to avoid other traffic over these
>> PCIe bridges. lspci -vt for a tree view.
>> 
>> Then one can do benchmarking from DRAM to disk. Perhaps you will not need
>> a filesystem for your very simple storage purpose.
>> You can ultimately just boot from some other media (USB stick or CD-ROM
>> loaded into a ramdisk) just to make sure there is absolute no need to 
>> read-access any other data on said disks, via cached pages or otherwise.
>> 
>> Hickups by system management mode or other unexpected driver interrupt 
>> sources
>> should be minimized. Other networking code and chatter might need be reduced,
>> just as SMM related thermal management events in the BIOS.
>> First tune everthing for maximum performance, then optimize for very 
>> constant 
>> write performance.
>> 
>> Mark-Jan
>> 
>> On Sat, Mar 09, 2019 at 12:32:05PM +0100, Paul Boven via USRP-users wrote:
>>> Hi,
>>> 
>>> I'm trying to record the full X310 bandwidth, for a few hours, without any
>>> missed samples. Which of course is a bit of a challenge - does anyone here
>>> already achieve this?
>>> 
>>> We're using a TwinRX, so initially I wanted to record 2x 100MS/s (from both
>>> channels), which amounts to 800MB/s, 6.4Gb/s. At first I tried uhd_rx_cfile,
>>> but have been unable to get it to a good state without showing an 'O' every
>>> few seconds at these speeds.
>>> 
>>> As a recorder I have a SuperMicro 847 chassis with 36 disks (Seagate
>>> Ironwolf 8TB T8000VN0022, 7200rpm). In this particular server, the disks are
>>> connected through an 'expander' backplane, from a single HBA (LSI 3008). CPU
>>> is dual Xeon 4110, 2.1 GHz, 64 GB of ram.
>>> 
>>> At first I tried a 6 disk pool (raidz1), and eventually ended up creating a
>>> huge 36 disk ZFS stripe, which in theory should have no trouble with the
>>> throughput, but certainly kept dropping packets.
>>> 
>>> Note that recording to /dev/shm/file works perfectly without dropping
>>> packets, until the point that the memory is full.
>>> 
>>> Given that ZFS has quite a bit of (good) overhead to safeguard your data, I
>>> then switched to creating a mdadm raid-0 with 18 of the disks (Why not 36? I
>>> was really running out of time!)
>>> 
>>> At that point I also found 'specrec' from gr-analyze, which seems more
>>> suitable. But, even after enlarging its circular buffer to the largest
>>> supported values, it would only average a write speed of about 300MB/s.
>>> 
>>> In the end I had to settle for recording at only 50MS/s (200MB/s) from only
>>> a single channel, a far cry from the 2x 6.4Gb/s I'm ultimately looking to
>>> record. Although I did get more than an hour of perfect data out of it, over
>>> time the circular buffer did get fuller in bursts, and within 2 hours it
>>> exited due to exhausting the buffers. Restarting the application made it
>>> work like fresh again, with the same gradual decline
>>> in performance.
>>> 
>>> Specrec, even when tweaking its settings, doesn't really take advantage of
>>> the large amount of memory in the server. As a next step, I'm thinking of
>>> adapting specrec to use much larger buffers, so that writes are at least in
>>> the range of MB to tens of MB. From earlier experiences, it is also
>>> important to flush your data to disk often, so the interruptions due to this
>>> are more frequent, but short enough to not cause receive buffers to
>>> 

Re: [USRP-users] Recording the full X3x0 bandwidth

[Joe Martin via USRP-users]

Hi Mark, 

I am intrigued by your response and have obtained a tree view for my system as 
you suggested to Paul.  I’m unfamiliar with the tree view and don’t understand 
how to check the number of PCIe lanes that are available to the disk controller 
and disks and how to check how many PCIe bridges are in between on my 
motherboard configuration.  

I have a screenshot of the tree view showing my 10G ethernet connection (but it 
is 220KB in size so I didn’t attach it here) but I am not familiar with how to 
determine what you asked about from the tree and what to do about the 
configuration in any case.  Is the configuration fixed and not changeable, in 
any case?  

If so, then perhaps your alternative suggestion regarding booting from a USB 
stick into a ramdisk is a viable route?  I’m unfortunately not familiar with 
the details of how to do that so perhaps a couple of brief comments about 
implementing that process would help me understand better if that’s the only 
viable alternative to pursue given the present hardware configuration?  

Joe

> On Mar 9, 2019, at 5:14 AM, Mark-Jan Bastian via USRP-users 
>  wrote:
> 
> Hi Paul,
> 
> I can record from the X310 to disk to nvme x4 PCIe at 800 MB/sec 
> for a few minutes. There is still a risk of O 's appearing.
> 
> First thing to check is the number of PCIe lanes available to the disk
> controller and disks, and how many and which PCIe bridges are in between
> on your motherboard configuration. Try to avoid other traffic over these
> PCIe bridges. lspci -vt for a tree view.
> 
> Then one can do benchmarking from DRAM to disk. Perhaps you will not need
> a filesystem for your very simple storage purpose.
> You can ultimately just boot from some other media (USB stick or CD-ROM
> loaded into a ramdisk) just to make sure there is absolute no need to 
> read-access any other data on said disks, via cached pages or otherwise.
> 
> Hickups by system management mode or other unexpected driver interrupt sources
> should be minimized. Other networking code and chatter might need be reduced,
> just as SMM related thermal management events in the BIOS.
> First tune everthing for maximum performance, then optimize for very constant 
> write performance.
> 
> Mark-Jan
> 
> On Sat, Mar 09, 2019 at 12:32:05PM +0100, Paul Boven via USRP-users wrote:
>> Hi,
>> 
>> I'm trying to record the full X310 bandwidth, for a few hours, without any
>> missed samples. Which of course is a bit of a challenge - does anyone here
>> already achieve this?
>> 
>> We're using a TwinRX, so initially I wanted to record 2x 100MS/s (from both
>> channels), which amounts to 800MB/s, 6.4Gb/s. At first I tried uhd_rx_cfile,
>> but have been unable to get it to a good state without showing an 'O' every
>> few seconds at these speeds.
>> 
>> As a recorder I have a SuperMicro 847 chassis with 36 disks (Seagate
>> Ironwolf 8TB T8000VN0022, 7200rpm). In this particular server, the disks are
>> connected through an 'expander' backplane, from a single HBA (LSI 3008). CPU
>> is dual Xeon 4110, 2.1 GHz, 64 GB of ram.
>> 
>> At first I tried a 6 disk pool (raidz1), and eventually ended up creating a
>> huge 36 disk ZFS stripe, which in theory should have no trouble with the
>> throughput, but certainly kept dropping packets.
>> 
>> Note that recording to /dev/shm/file works perfectly without dropping
>> packets, until the point that the memory is full.
>> 
>> Given that ZFS has quite a bit of (good) overhead to safeguard your data, I
>> then switched to creating a mdadm raid-0 with 18 of the disks (Why not 36? I
>> was really running out of time!)
>> 
>> At that point I also found 'specrec' from gr-analyze, which seems more
>> suitable. But, even after enlarging its circular buffer to the largest
>> supported values, it would only average a write speed of about 300MB/s.
>> 
>> In the end I had to settle for recording at only 50MS/s (200MB/s) from only
>> a single channel, a far cry from the 2x 6.4Gb/s I'm ultimately looking to
>> record. Although I did get more than an hour of perfect data out of it, over
>> time the circular buffer did get fuller in bursts, and within 2 hours it
>> exited due to exhausting the buffers. Restarting the application made it
>> work like fresh again, with the same gradual decline
>> in performance.
>> 
>> Specrec, even when tweaking its settings, doesn't really take advantage of
>> the large amount of memory in the server. As a next step, I'm thinking of
>> adapting specrec to use much larger buffers, so that writes are at least in
>> the range of MB to tens of MB. From earlier experiences, it is also
>> important to flush your data to disk often, so the interruptions due to this
>> are more frequent, but short enough to not cause receive buffers to
>> overflow.
>> 
>> In terms of network tuning, all recording was done with MTU 9000, with wmem
>> and rmem at the recommended values. All recordings were done as interleaved
>> shorts.
>> 
>> Does anyone have hints or 

Re: [USRP-users] Recording the full X3x0 bandwidth

[Joe Martin via USRP-users]

Hi Paul, 

Thanks for your post.  I am new to USRP devices and UHD and GNURadio but I have 
recently obtained an X310 with dual TwinRX daughterboards to do pulsar radio 
astronomy and I have been exploring exactly the issue you raise in order to 
help me with my  requirements to record data for hours at a time.  

Thus far, my results are similar to your results it seems as I am able to write 
dual-channel 32-bit complex samples from the X310 to disk at 25Msps without 
loss of any samples, or at 50Msps using a single channel for hours at a time.  

I’m using a single 10G ethernet connection of a dual-channel 10G interface to 
the PC.  The PC is an AMD Threadripper 2950x CPU @3.4GHz with an Intel 2TB SSD 
and an 8TB HDD for storage.  To achieve the above throughput I am writing 
directly to the SSD only as the HDD can’t keep up with these data rates.  

At the moment I am using a GNURadio-Companion flowchart program to control the 
X310 but I will shortly be exploring use of my own C++ program utilizing only 
UHD routines to perform the transfer task if I can arrange that.  The effort to 
use my own program is driven by my desire to explore using 16-bit complex or 
even 8-bit sample sizes from the X310 to allow me to record 100Msps from dual 
channels but I don’t think GRC allows those choices of sample format into the 
File Sink block, unless I’m misunderstanding the capabilities of GRC, so I’ll 
attempt to write my own in C++ using UHD to do this instead.  

Being new to much of this I don’t know if I can be of any help to you but I 
thought I’d let you know that I for one am very interested in hearing of your 
progress as your and my goals appear to be similar with respect to achieving 
dual-channel, wide-bandwidth output from the X310 to disk.  

Regards, 

Joe

> On Mar 9, 2019, at 4:32 AM, Paul Boven via USRP-users 
>  wrote:
> 
> Hi,
> 
> I'm trying to record the full X310 bandwidth, for a few hours, without any 
> missed samples. Which of course is a bit of a challenge - does anyone here 
> already achieve this?
> 
> We're using a TwinRX, so initially I wanted to record 2x 100MS/s (from both 
> channels), which amounts to 800MB/s, 6.4Gb/s. At first I tried uhd_rx_cfile, 
> but have been unable to get it to a good state without showing an 'O' every 
> few seconds at these speeds.
> 
> As a recorder I have a SuperMicro 847 chassis with 36 disks (Seagate Ironwolf 
> 8TB T8000VN0022, 7200rpm). In this particular server, the disks are connected 
> through an 'expander' backplane, from a single HBA (LSI 3008). CPU is dual 
> Xeon 4110, 2.1 GHz, 64 GB of ram.
> 
> At first I tried a 6 disk pool (raidz1), and eventually ended up creating a 
> huge 36 disk ZFS stripe, which in theory should have no trouble with the 
> throughput, but certainly kept dropping packets.
> 
> Note that recording to /dev/shm/file works perfectly without dropping 
> packets, until the point that the memory is full.
> 
> Given that ZFS has quite a bit of (good) overhead to safeguard your data, I 
> then switched to creating a mdadm raid-0 with 18 of the disks (Why not 36? I 
> was really running out of time!)
> 
> At that point I also found 'specrec' from gr-analyze, which seems more 
> suitable. But, even after enlarging its circular buffer to the largest 
> supported values, it would only average a write speed of about 300MB/s.
> 
> In the end I had to settle for recording at only 50MS/s (200MB/s) from only a 
> single channel, a far cry from the 2x 6.4Gb/s I'm ultimately looking to 
> record. Although I did get more than an hour of perfect data out of it, over 
> time the circular buffer did get fuller in bursts, and within 2 hours it 
> exited due to exhausting the buffers. Restarting the application made it work 
> like fresh again, with the same gradual decline
> in performance.
> 
> Specrec, even when tweaking its settings, doesn't really take advantage of 
> the large amount of memory in the server. As a next step, I'm thinking of 
> adapting specrec to use much larger buffers, so that writes are at least in 
> the range of MB to tens of MB. From earlier experiences, it is also important 
> to flush your data to disk often, so the interruptions due to this are more 
> frequent, but short enough to not cause receive buffers to overflow.
> 
> In terms of network tuning, all recording was done with MTU 9000, with wmem 
> and rmem at the recommended values. All recordings were done as interleaved 
> shorts.
> 
> Does anyone have hints or experiences to share?
> 
> Regards, Paul Boven.
> 
> ___
> 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] link led colour

[Joe Martin via USRP-users]

Interestingly, my X310 front panel LED occasionally, very briefly shows red 
too.  Maybe the schematic isn’t current with what is actually used in the unit 
these days(?).  

Regards, 

Joe

> On Mar 7, 2019, at 3:36 PM, Marcus Müller via USRP-users 
>  wrote:
> 
> So that's built on an X3x0 platform. As said, no, the link leds really
> just display link status, nothing about the data.
> Also, when you look at the schematic of the X300, PDF [1] page 13,
> you'll find no red LED – only green and yellow, so I must admit I'm a
> bit confused about what you witnessed?
> 
> Best regards,
> Marcus
> 
> [1] http://files.ettus.com/schematics/x300/x3xx.pdf
> On Thu, 2019-03-07 at 09:56 +, Koyel Das (Vehere) wrote:
>> I am using USRP 2955 R
>> 
>> Koyel Das 
>> Senior – Product Engineer
>> Vehere | Proactive Communications Intelligence & Cyber Defence
>> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
>> www.vehere.com
>> 
>> 
>> 
>> Vehere is the proud recipient of the Fastest Growing Technology
>> Company Awards in India & Asia since 2012!
>> 
>> The content of this e-mail is confidential and intended solely for
>> the use of the addressee. The text of this email (including any
>> attachments) may contain information, which is proprietary and/or
>> confidential or privileged in nature belonging to Vehere Interactive
>> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you
>> are not the addressee, or the person responsible for delivering it to
>> the addressee, any disclosure, copying, distribution or any action
>> taken or omitted to be taken in reliance on it is prohibited and may
>> be unlawful. If you have received this e-mail in error, please notify
>> the sender and remove this communication entirely from your system.
>> The recipient acknowledges that no guarantee or any warranty is given
>> as to completeness and accuracy of the content of the email. The
>> recipient further acknowledges that the views contained in the email
>> message are those of the sender and may not necessarily reflect those
>> of Vehere Interactive Pvt Ltd. Before opening and accessing the
>> attachment please check and scan for virus. WARNING: Computer viruses
>> can be transmitted via email. The recipient should check this email
>> and any attachments for the presence of viruses. The company accepts
>> no liability for any damage caused by any virus transmitted by this
>> email.
>> From: Marcus Müller 
>> Sent: Thursday, March 7, 2019 3:21:40 PM
>> To: Koyel Das (Vehere); 'USRP-users@lists.ettus.com'
>> Subject: Re: [USRP-users] link led colour
>> 
>> The link LEDs on our USRPs don't indicate validness of data. It's
>> highly likely this is normal. What USRP are you using?
>> 
>> Best regards,
>> Marcus
>> 
>> On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users
>> wrote:
>>> Hi,
>>> 
>>> When I am receiving data using ethernet my link LED is orange most
>> of
>>> the times and blinking to red for momentarily, which is not so
>>> noticeable. Am I receiving wrong data? It is not turning green.
>>> 
>>> Regards,
>>> Koyel
>>> 
>>> Koyel Das 
>>> Senior – Product Engineer
>>> Vehere | Proactive Communications Intelligence & Cyber Defence
>>> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
>>> www.vehere.com


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