Re: [USRP-users] Independent use of ethernet ports on Ettus x310?

[Neel Pandeya via USRP-users]

Hello Chad:

If you are using 1 Gigabit Ethernet, then only one of two SFP ports in the
rear of the X300/X310 can be used. If you have 10 Gigabit Ethernet, then
the second SFP port can be used. Please see the link below. The SFP ports
are configured depending on which FPGA image is being used.

http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_load_fpga_imgs_fpga_flavours

Regarding your use-case, if you have a second daughterboard in your
X300/X310, then you can simultaneously receive in parallel. With two
daughterboards, the X300/X310 provides two transmit chains and two receive
chains.

What is the configuration of your system?

--Neel Pandeya



On 15 November 2017 at 17:34, Chad Spooner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> All:
>
> I'm wondering how to use the second ethernet port on my x310. I've been
> going through the
> online Ettus SDR help, but can't seem to find the right pages.
>
> The short version of my question is: Can I use the two ethernet ports
> independently, say
> when each of them is connected to a separate computer? If so, how do I set
> up the second
> port? I'm using computers with 1 GiG Ethernet only.
>
> Details/Context: I have a working gnuradio companion flowgraph that
> generates a signal indefinitely
> and applies it to (A:0, Tx/Rx). That output port is connected by a cable
> to (B:0, RX2).  All indications are
> that this is working well. At irregular intervals, I want to obtain large
> numbers of samples from
> (B:0, RX2) by calling, say, uhd_rx_cfile or the like, outside of the
> flowgraph, which is still
> running. I'm prevented from doing that while the flowgraph is running. Can
> I do it using the
> second 1 GiG port if I set it up properly?
>
> Thanks for any advice you can offer.
>
> Chad
>
> --
> Chad M. Spooner
> NorthWest Research Associates
> 301 Webster Street
> Monterey, CA 93940cmspooner@nwra.com831 582 4904 <(831)%20582-4904>
> cyclostationary.blog
>
>
> ___
> 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] Problem burning image to SD card for E312

[Anon Lister via USRP-users]

You want the raw block device /dev/sdb,  not the partition /dev/sdb1, no?
Could that be it?

On Nov 16, 2017 5:28 PM, "Mann, John - 0662 - MITLL via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> I tried issuing a sync command after the dd command - no help.
>
> I also tried using bmaptool to burn the image.  It still doesn’t work.
> And it still took around 10 minutes - no faster than dd.
>
> Both commands finish without any error messages.
>
> The image file's md5 checksum is correct, so the image did not get
> corrupted during the download.
>
> I have even tried 2 different SD cards.
>
> I'm running out of ideas... should I try a different host computer?  Any
> way to do this from Windows 7 or Windows 10?
>
> -Original Message-
> From: Philip Balister [mailto:phi...@balister.org]
> Sent: Thursday, November 16, 2017 4:43 PM
> To: Anon Lister 
> Cc: Mann, John - 0662 - MITLL ; usrp-users <
> usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] Problem burning image to SD card for E312
>
> On 11/16/2017 04:37 PM, Anon Lister wrote:
> > Make sure to run sync after to dd.
>
> Interesting, I thought dd would run below the buffer cache layer.
>
> >
> > Also curious as to reason for the recommendation against dd?
> >
>
> bmaptool is faster. bmaptool also checks to see if the device has a
> mounted file system, so prevent you form overwriting something like
> /dev/sda. Basically, safer and faster.
>
> Philip
>
>
> > On Nov 16, 2017 12:35 PM, "Philip Balister via USRP-users" <
> > usrp-users@lists.ettus.com> wrote:
> >
> >> Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.
> >>
> >> https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card
> >>
> >> The might even be package with Ubuntu. After writing, re-insert the
> >> card in the writer and see if it mounts the partitions.
> >>
> >> Philip
> >>
> >> On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
> >>> Running Ubuntu 16 on my host computer...
> >>>
> >>> I downloaded the image from:
> >>>
> >>> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-
> >> e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-
> >> 4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
> >>>
> >>> Then I decompressed the xz file using xzdec:
> >>>
> >>> xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
> >>>
> >>> And burned the sd image using the dd command:
> >>>
> >>> sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
> >>>
> >>> The dd command apparently finishes without error after about 10
> >>> minutes,
> >> and I can see flashing lights on the SD card USB adapter, so I'm
> >> pretty sure it is getting written to the correct place.
> >>>
> >>> But the card does not work in the E312.  When I turn it on, the 4
> >>> LEDs
> >> next to the Tx/Rx ports light up, but there is no activity on the
> >> console window.  I have another SD card that boots up fine, so I know
> >> the E312 is fine.  There is clearly something wrong with the SD card.
> >> When I plug the old working card into my Ubuntu host machine, I can
> >> actually see the files on the card.  When I plug the newly burned
> >> card back into the Ubuntu machine, I see nothing.
> >>>
> >>> Any idea what I am doing wrong?
> >>>
> >>> John Mann
> >>> MIT Lincoln Laboratory
> >>>
> >>> ___
> >>> USRP-users mailing list
> >>> USRP-users@lists.ettus.com
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>
> >> ___
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problem burning image to SD card for E312

[Ron Economos via USRP-users]

Make sure you unmount the SD card file system first before using dd.

Ron

On 11/16/2017 02:24 PM, Mann, John - 0662 - MITLL via USRP-users wrote:

I tried issuing a sync command after the dd command - no help.

I also tried using bmaptool to burn the image.  It still doesn’t work.  And it 
still took around 10 minutes - no faster than dd.

Both commands finish without any error messages.

The image file's md5 checksum is correct, so the image did not get corrupted 
during the download.

I have even tried 2 different SD cards.

I'm running out of ideas... should I try a different host computer?  Any way to 
do this from Windows 7 or Windows 10?

-Original Message-
From: Philip Balister [mailto:phi...@balister.org]
Sent: Thursday, November 16, 2017 4:43 PM
To: Anon Lister 
Cc: Mann, John - 0662 - MITLL ; usrp-users 

Subject: Re: [USRP-users] Problem burning image to SD card for E312

On 11/16/2017 04:37 PM, Anon Lister wrote:

Make sure to run sync after to dd.

Interesting, I thought dd would run below the buffer cache layer.


Also curious as to reason for the recommendation against dd?


bmaptool is faster. bmaptool also checks to see if the device has a mounted 
file system, so prevent you form overwriting something like /dev/sda. 
Basically, safer and faster.

Philip



On Nov 16, 2017 12:35 PM, "Philip Balister via USRP-users" <
usrp-users@lists.ettus.com> wrote:


Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.

https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card

The might even be package with Ubuntu. After writing, re-insert the
card in the writer and see if it mounts the partitions.

Philip

On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:

Running Ubuntu 16 on my host computer...

I downloaded the image from:

http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-

e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-
4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz

Then I decompressed the xz file using xzdec:

xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct

And burned the sd image using the dd command:

sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M

The dd command apparently finishes without error after about 10
minutes,

and I can see flashing lights on the SD card USB adapter, so I'm
pretty sure it is getting written to the correct place.

But the card does not work in the E312.  When I turn it on, the 4
LEDs

next to the Tx/Rx ports light up, but there is no activity on the
console window.  I have another SD card that boots up fine, so I know
the E312 is fine.  There is clearly something wrong with the SD card.
When I plug the old working card into my Ubuntu host machine, I can
actually see the files on the card.  When I plug the newly burned
card back into the Ubuntu machine, I see nothing.

Any idea what I am doing wrong?

John Mann
MIT Lincoln Laboratory

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


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


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



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

[USRP-users] Independent use of ethernet ports on Ettus x310?

[Chad Spooner via USRP-users]

All:

I'm wondering how to use the second ethernet port on my x310. I've been
going through the
online Ettus SDR help, but can't seem to find the right pages.

The short version of my question is: Can I use the two ethernet ports
independently, say
when each of them is connected to a separate computer? If so, how do I
set up the second
port? I'm using computers with 1 GiG Ethernet only.

Details/Context: I have a working gnuradio companion flowgraph that
generates a signal indefinitely 
and applies it to (A:0, Tx/Rx). That output port is connected by a
cable to (B:0, RX2).  All indications are 
that this is working well. At irregular intervals, I want to obtain
large numbers of samples from
(B:0, RX2) by calling, say, uhd_rx_cfile or the like, outside of the
flowgraph, which is still
running. I'm prevented from doing that while the flowgraph is running.
Can I do it using the
second 1 GiG port if I set it up properly?

Thanks for any advice you can offer.

Chad

-- 
Chad M. Spooner
NorthWest Research Associates
301 Webster Street
Monterey, CA 93940
cmspoo...@nwra.com
831 582 4904
cyclostationary.blog

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

Re: [USRP-users] Problem burning image to SD card for E312

[Mann, John - 0662 - MITLL via USRP-users]

I tried issuing a sync command after the dd command - no help.

I also tried using bmaptool to burn the image.  It still doesn’t work.  And it 
still took around 10 minutes - no faster than dd.

Both commands finish without any error messages.

The image file's md5 checksum is correct, so the image did not get corrupted 
during the download.

I have even tried 2 different SD cards.

I'm running out of ideas... should I try a different host computer?  Any way to 
do this from Windows 7 or Windows 10?

-Original Message-
From: Philip Balister [mailto:phi...@balister.org] 
Sent: Thursday, November 16, 2017 4:43 PM
To: Anon Lister 
Cc: Mann, John - 0662 - MITLL ; usrp-users 

Subject: Re: [USRP-users] Problem burning image to SD card for E312

On 11/16/2017 04:37 PM, Anon Lister wrote:
> Make sure to run sync after to dd.

Interesting, I thought dd would run below the buffer cache layer.

> 
> Also curious as to reason for the recommendation against dd?
> 

bmaptool is faster. bmaptool also checks to see if the device has a mounted 
file system, so prevent you form overwriting something like /dev/sda. 
Basically, safer and faster.

Philip


> On Nov 16, 2017 12:35 PM, "Philip Balister via USRP-users" < 
> usrp-users@lists.ettus.com> wrote:
> 
>> Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.
>>
>> https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card
>>
>> The might even be package with Ubuntu. After writing, re-insert the 
>> card in the writer and see if it mounts the partitions.
>>
>> Philip
>>
>> On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
>>> Running Ubuntu 16 on my host computer...
>>>
>>> I downloaded the image from:
>>>
>>> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-
>> e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-
>> 4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
>>>
>>> Then I decompressed the xz file using xzdec:
>>>
>>> xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
>>>
>>> And burned the sd image using the dd command:
>>>
>>> sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
>>>
>>> The dd command apparently finishes without error after about 10 
>>> minutes,
>> and I can see flashing lights on the SD card USB adapter, so I'm 
>> pretty sure it is getting written to the correct place.
>>>
>>> But the card does not work in the E312.  When I turn it on, the 4 
>>> LEDs
>> next to the Tx/Rx ports light up, but there is no activity on the 
>> console window.  I have another SD card that boots up fine, so I know 
>> the E312 is fine.  There is clearly something wrong with the SD card.  
>> When I plug the old working card into my Ubuntu host machine, I can 
>> actually see the files on the card.  When I plug the newly burned 
>> card back into the Ubuntu machine, I see nothing.
>>>
>>> Any idea what I am doing wrong?
>>>
>>> John Mann
>>> MIT Lincoln Laboratory
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Receive samples at exact time_spec_t

[Dario Fertonani via USRP-users]

You may want to look at my messages in the thread "UHD command delay is
different in the first recv stream".
You'll see that: delays have been there for a long time, are still there in
UHD 3.10.x, delay values depend on sampling rate (and/or master clock
rate), and, more critically, the very first delay value in each run is
typically an outlier (this matters only if you issue multiple stream
commands in your app).

On Thu, Nov 16, 2017 at 9:42 AM, ROBIN TORTORA via USRP-users <
usrp-users@lists.ettus.com> wrote:

> If you are using UHD 3.9.x or earlier, I would guess filter delay...
>
> On November 16, 2017 at 5:31 AM Hojoon Yang via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi.
>
>
>
> I use USRP B200 with external on-board GPSDO.
>
>
> 1. I set the clock source and time soure to GPSDO
>
> usrp->set_clock_source("gpsdo", 0);
>
> usrp->set_time_source("gpsdo", 0);
>
>
>
> 2. Set_time_next_pps and sleep 2 secs.
>
> usrp->set_time_next_pps(uhd::time_spec_t(0.0), 0);
>
> boost::this_thread::sleep(boost::posix_time::seconds(2));
>
>
>
> 3. Issue the stream command to start the stream from 3.0 seconds.
>
> uhd::stream_cmd_t stream_cmd(uhd::stream_cmd_t::
> STREAM_MODE_NUM_SAMPS_AND_DONE);
>
> stream_cmd.num_samps = 100;
>
> stream_cmd.stream_now = false;
>
> const uhd::time_spec_t stream_time = uhd::time_spec_t(3.0);
>
> stream_cmd.time_spec = stream_time;
>
> rx_stream->issue_stream_cmd(stream_cmd);
>
>
>
> 4. Start the Rx streams and check received time.
>
> size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md,
> 5.0);
>
> 
> ---
>
> Received packet: 100 samples, 3 full secs, 0.37 frac secs
>
> Stream time was: 3 full secs, 0.00 frac secs
>
> Difference between stream time and first packet: 37.093750 us
>
>
>
> I command to start receving from 3.0 seconds, but the USRP B200 does not
> start at exact time(there are some delay, 37us).
>
>
>
> I guess it seems normal.
>
>
>
> (a)But is there any method to overcome this tiny difference? at least
> below 10 us.
>
>
>
> (b)Is the difference always same? If not, Could you tell me which things
> could change the difference?
>
>
>
> (c)Can I solve the problem If I set the stream time to 3.0s - 37us?
>
>
>
> It will be very appreciated if someone could answer the above three
> questions!
>
>
>
> Thanks in advance.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problem burning image to SD card for E312

[Anon Lister via USRP-users]

Afaik, no, dd is just a normal command, you can pass conv=fdatasync
and not have
to worry about cache, but otherwise it's won't know about it.

Cool, never heard of bmaptool. The faster writes sounds awesome. Thanks for
the info.

On Nov 16, 2017 4:42 PM, "Philip Balister"  wrote:

> On 11/16/2017 04:37 PM, Anon Lister wrote:
> > Make sure to run sync after to dd.
>
> Interesting, I thought dd would run below the buffer cache layer.
>
> >
> > Also curious as to reason for the recommendation against dd?
> >
>
> bmaptool is faster. bmaptool also checks to see if the device has a
> mounted file system, so prevent you form overwriting something like
> /dev/sda. Basically, safer and faster.
>
> Philip
>
>
> > On Nov 16, 2017 12:35 PM, "Philip Balister via USRP-users" <
> > usrp-users@lists.ettus.com> wrote:
> >
> >> Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.
> >>
> >> https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card
> >>
> >> The might even be package with Ubuntu. After writing, re-insert the card
> >> in the writer and see if it mounts the partitions.
> >>
> >> Philip
> >>
> >> On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
> >>> Running Ubuntu 16 on my host computer...
> >>>
> >>> I downloaded the image from:
> >>>
> >>> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-
> >> e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-
> >> 4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
> >>>
> >>> Then I decompressed the xz file using xzdec:
> >>>
> >>> xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
> >>>
> >>> And burned the sd image using the dd command:
> >>>
> >>> sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
> >>>
> >>> The dd command apparently finishes without error after about 10
> minutes,
> >> and I can see flashing lights on the SD card USB adapter, so I'm pretty
> >> sure it is getting written to the correct place.
> >>>
> >>> But the card does not work in the E312.  When I turn it on, the 4 LEDs
> >> next to the Tx/Rx ports light up, but there is no activity on the
> console
> >> window.  I have another SD card that boots up fine, so I know the E312
> is
> >> fine.  There is clearly something wrong with the SD card.  When I plug
> the
> >> old working card into my Ubuntu host machine, I can actually see the
> files
> >> on the card.  When I plug the newly burned card back into the Ubuntu
> >> machine, I see nothing.
> >>>
> >>> Any idea what I am doing wrong?
> >>>
> >>> John Mann
> >>> MIT Lincoln Laboratory
> >>>
> >>> ___
> >>> USRP-users mailing list
> >>> USRP-users@lists.ettus.com
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>>
> >>
> >> ___
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problem burning image to SD card for E312

[Philip Balister via USRP-users]

On 11/16/2017 04:37 PM, Anon Lister wrote:
> Make sure to run sync after to dd.

Interesting, I thought dd would run below the buffer cache layer.

> 
> Also curious as to reason for the recommendation against dd?
> 

bmaptool is faster. bmaptool also checks to see if the device has a
mounted file system, so prevent you form overwriting something like
/dev/sda. Basically, safer and faster.

Philip


> On Nov 16, 2017 12:35 PM, "Philip Balister via USRP-users" <
> usrp-users@lists.ettus.com> wrote:
> 
>> Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.
>>
>> https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card
>>
>> The might even be package with Ubuntu. After writing, re-insert the card
>> in the writer and see if it mounts the partitions.
>>
>> Philip
>>
>> On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
>>> Running Ubuntu 16 on my host computer...
>>>
>>> I downloaded the image from:
>>>
>>> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-
>> e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-
>> 4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
>>>
>>> Then I decompressed the xz file using xzdec:
>>>
>>> xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
>>>
>>> And burned the sd image using the dd command:
>>>
>>> sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
>>>
>>> The dd command apparently finishes without error after about 10 minutes,
>> and I can see flashing lights on the SD card USB adapter, so I'm pretty
>> sure it is getting written to the correct place.
>>>
>>> But the card does not work in the E312.  When I turn it on, the 4 LEDs
>> next to the Tx/Rx ports light up, but there is no activity on the console
>> window.  I have another SD card that boots up fine, so I know the E312 is
>> fine.  There is clearly something wrong with the SD card.  When I plug the
>> old working card into my Ubuntu host machine, I can actually see the files
>> on the card.  When I plug the newly burned card back into the Ubuntu
>> machine, I see nothing.
>>>
>>> Any idea what I am doing wrong?
>>>
>>> John Mann
>>> MIT Lincoln Laboratory
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
> 

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

Re: [USRP-users] Problem burning image to SD card for E312

[Anon Lister via USRP-users]

Make sure to run sync after to dd.

Also curious as to reason for the recommendation against dd?

On Nov 16, 2017 12:35 PM, "Philip Balister via USRP-users" <
usrp-users@lists.ettus.com> wrote:

> Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.
>
> https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card
>
> The might even be package with Ubuntu. After writing, re-insert the card
> in the writer and see if it mounts the partitions.
>
> Philip
>
> On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
> > Running Ubuntu 16 on my host computer...
> >
> > I downloaded the image from:
> >
> > http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-
> e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-
> 4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
> >
> > Then I decompressed the xz file using xzdec:
> >
> > xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
> >
> > And burned the sd image using the dd command:
> >
> > sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
> >
> > The dd command apparently finishes without error after about 10 minutes,
> and I can see flashing lights on the SD card USB adapter, so I'm pretty
> sure it is getting written to the correct place.
> >
> > But the card does not work in the E312.  When I turn it on, the 4 LEDs
> next to the Tx/Rx ports light up, but there is no activity on the console
> window.  I have another SD card that boots up fine, so I know the E312 is
> fine.  There is clearly something wrong with the SD card.  When I plug the
> old working card into my Ubuntu host machine, I can actually see the files
> on the card.  When I plug the newly burned card back into the Ubuntu
> machine, I see nothing.
> >
> > Any idea what I am doing wrong?
> >
> > John Mann
> > MIT Lincoln Laboratory
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Receive samples at exact time_spec_t

[ROBIN TORTORA via USRP-users]

If you are using UHD 3.9.x or earlier, I would guess filter delay...

> On November 16, 2017 at 5:31 AM Hojoon Yang via USRP-users 
>  wrote:
> 
> Hi.
>  
> I use USRP B200 with external on-board GPSDO.
> 
> 1. I set the clock source and time soure to GPSDO
> usrp->set_clock_source("gpsdo", 0);
> usrp->set_time_source("gpsdo", 0);
>  
> 2. Set_time_next_pps and sleep 2 secs.
> usrp->set_time_next_pps(uhd::time_spec_t(0.0), 0);
> boost::this_thread::sleep(boost::posix_time::seconds(2));
>  
> 3. Issue the stream command to start the stream from 3.0 seconds.
> uhd::stream_cmd_t 
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
> stream_cmd.num_samps = 100;
> stream_cmd.stream_now = false;
> const uhd::time_spec_t stream_time = uhd::time_spec_t(3.0);
> stream_cmd.time_spec = stream_time;
> rx_stream->issue_stream_cmd(stream_cmd);
>  
> 4. Start the Rx streams and check received time.
> size_t num_rx_samps = rx_stream->recv(&buff.front(), buff.size(), md, 
> 5.0);
> 
> ---
> Received packet: 100 samples, 3 full secs, 0.37 frac secs
> Stream time was: 3 full secs, 0.00 frac secs
> Difference between stream time and first packet: 37.093750 us
>  
> I command to start receving from 3.0 seconds, but the USRP B200 does not 
> start at exact time(there are some delay, 37us).
>  
> I guess it seems normal.
>  
> (a)But is there any method to overcome this tiny difference? at least 
> below 10 us.
>  
> (b)Is the difference always same? If not, Could you tell me which things 
> could change the difference? 
>  
> (c)Can I solve the problem If I set the stream time to 3.0s - 37us?
>  
> It will be very appreciated if someone could answer the above three 
> questions!
>  
> Thanks in advance.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Problem burning image to SD card for E312

[Philip Balister via USRP-users]

Try bmaptool. dd is a bad idea, yeah I killed my hard drive once.

https://wiki.gnuradio.org/index.php/Copy_an_image_file_to_the_SD_card

The might even be package with Ubuntu. After writing, re-insert the card
in the writer and see if it mounts the partitions.

Philip

On 11/16/2017 10:54 AM, Mann, John - 0662 - MITLL via USRP-users wrote:
> Running Ubuntu 16 on my host computer...
> 
> I downloaded the image from:
> 
> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
>  
> 
> Then I decompressed the xz file using xzdec:
> 
> xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct
> 
> And burned the sd image using the dd command:
> 
> sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M
> 
> The dd command apparently finishes without error after about 10 minutes, and 
> I can see flashing lights on the SD card USB adapter, so I'm pretty sure it 
> is getting written to the correct place.
> 
> But the card does not work in the E312.  When I turn it on, the 4 LEDs  next 
> to the Tx/Rx ports light up, but there is no activity on the console window.  
> I have another SD card that boots up fine, so I know the E312 is fine.  There 
> is clearly something wrong with the SD card.  When I plug the old working 
> card into my Ubuntu host machine, I can actually see the files on the card.  
> When I plug the newly burned card back into the Ubuntu machine, I see nothing.
> 
> Any idea what I am doing wrong?
> 
> John Mann
> MIT Lincoln Laboratory
> 
> ___
> 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] Running UHD-examples in windows

[Jacob Knoles via USRP-users]

Hi Mirit,

Assuming that by following the Getting started guide you have a copy of
GNURadio installed then you need to open a GNURadio Command Prompt, either
from start menu or C:\Program Files\GNURadio\bin.

>From here you have access to the UHD tools such as uhd_find_devices.exe and
uhd_usrp_probe.exe which can be run directly from the open command line.

To use one of the examples you need to change to the directory where all
the example exe's are, or use the full path name for each example.

The examples are located in C:\Program
Files\GNURadio-3.7\share\uhd\examples for instance.  To change directories
from the start location "bin" enter:

cd ..\share\uhd\examples

Each example is run from the command line and has a help feature. For
example: "rx_samples_to_file.exe --help" will provide information on how to
use the program.

Hope this helps.

-
Jacob Knoles


On Tue, Nov 14, 2017 at 6:46 AM, Mirit Ochayon via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
>
> I did all the necessary installations from the ‘UHD B210 Getting Started
> Guides’,
>
> how to run UHD examples in windows? (windows 7)
>
> for test and verify the operation of the USRP…
>
>
>
> Thanks!
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Problem burning image to SD card for E312

[Mann, John - 0662 - MITLL via USRP-users]

Running Ubuntu 16 on my host computer...

I downloaded the image from:

http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
 

Then I decompressed the xz file using xzdec:

xzdec sdimage-gnuradio-dev.direct.xz >> sdimage-gnuradio-dev.direct

And burned the sd image using the dd command:

sudo dd if=sdimage-gnuradio-dev.direct of=/dev/sdb1 bs=1M

The dd command apparently finishes without error after about 10 minutes, and I 
can see flashing lights on the SD card USB adapter, so I'm pretty sure it is 
getting written to the correct place.

But the card does not work in the E312.  When I turn it on, the 4 LEDs  next to 
the Tx/Rx ports light up, but there is no activity on the console window.  I 
have another SD card that boots up fine, so I know the E312 is fine.  There is 
clearly something wrong with the SD card.  When I plug the old working card 
into my Ubuntu host machine, I can actually see the files on the card.  When I 
plug the newly burned card back into the Ubuntu machine, I see nothing.

Any idea what I am doing wrong?

John Mann
MIT Lincoln Laboratory

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

[USRP-users] Test failed when executing test_messages.cpp

[Hojoon Yang via USRP-users]

Hi all.When I executed the uhd example(test_messages.cpp) using USRP B200, lots 
of test failed.I want to know whether following results are normal or not.I 
executed each of the following three commands twice.1. sudo 
./test_messagesSummary:Test Burst ACK-> 8 successes,   4 failuresTest 
Underflow-> 2 successes,   4 failuresTest Time Error   -> 0 
successes,  13 failuresTest Late Command   ->19 successes,   0 
failuresDone!Summary:Test Burst ACK-> 7 successes,   3 failuresTest 
Underflow-> 5 successes,  10 failuresTest Time Error   -> 0 
successes,  11 failuresTest Late Command   ->14 successes,   0 
failuresDone!*once moreSummary:Test Burst ACK-> 6 successes,   3 
failuresTest Underflow-> 4 successes,   8 failuresTest Time Error   ->  
   0 successes,  15 failuresTest Late Command   ->14 successes,   0 
failuresDone!2. sudo ./test_messages --ntests 100Summary:Test Burst ACK->   
 16 successes,   7 failuresTest Underflow-> 8 successes,  12 
failuresTest Time Error   -> 0 successes,  37 failuresTest Late Command   
->20 successes,   0 failuresDone!Summary:Test Burst ACK->27 
successes,   6 failuresTest Underflow->14 successes,  11 failuresTest 
Time Error   -> 0 successes,  19 failuresTest Late Command   ->23 
successes,   0 failuresDone!3. sudo ./test_messages --test-chainSummary:Test 
Burst ACK->12 successes,   3 failuresTest Underflow-> 6 
successes,   3 failuresTest Time Error   -> 0 successes,   8 failuresTest 
Late Command   -> 9 successes,   0 failuresTest Broken Chain   -> 0 
successes,   9 failuresDone!Summary:Test Burst ACK-> 8 successes,   6 
failuresTest Underflow-> 6 successes,   3 failuresTest Time Error   ->  
   0 successes,  10 failuresTest Late Command   ->13 successes,   0 
failuresTest Broken Chain   -> 0 successes,   4 failuresDone!___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] spectrum analyzer USRP N210

[Michał Wróbel via USRP-users]

Ok, this makes things clearer :-).

Is there any difference in the obtained spectra between the stock and my
compilation of FPGA firmware for the whole original range of frequencies
(i.e. like in the initial screenshots, 400 - 1000 MHz) without the "80%
sewing"?

2017-11-16 12:48 GMT+01:00 Ivan Zahartchuk :

> I'm sorry that I misled you. The fact is that after the ftft there is a
> constant component that I am removing in the code by zeroing.
> 1)
>
> def reciev():
> n = int(math.ceil((config.stop_freq - config.start_freq) / 
> config.band*0.8))
> fft1 = np.array([], dtype=np.complex64)
> fft2 = np.array([], dtype=np.complex64)
> for i in range(0, n):
> usrp.set_rx_freq(lib.types.tune_request(config.start_freq + 
> config.band / 2 + (config.band*0.8) * i), 0)
> streamer.recv(recv_buff, config.metadata)
> if config.metadata.error_code == 
> lib.types.rx_metadata_error_code.timeout:
> print ("ERRROR")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.late:
> print ("ERR1")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.broken_chain:
> print ("ERR2")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.overflow:
> print ("ERR3")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.alignment:
> print ("ERR4")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.bad_packet:
> print ("ERR5")
> prom1 = np.fft.fft(recv_buff*w)
>
> prom1=np.fft.fftshift(prom1)
>
> fft1 = np.hstack((prom1,fft1))
>)
> stream_cmd.time_spec = lib.types.time_spec(0)
> streamer.issue_stream_cmd(stream_cmd)
> 2.
> def reciev():
> n = int(math.ceil((config.stop_freq - config.start_freq) / 
> config.band*0.8))
> fft1 = np.array([], dtype=np.complex64)
>
> for i in range(0, n):
> usrp.set_rx_freq(lib.types.tune_request(config.start_freq + 
> config.band / 2 + (config.band*0.8) * i), 0)
> streamer.recv(recv_buff, config.metadata)
> if config.metadata.error_code == 
> lib.types.rx_metadata_error_code.timeout:
> print ("ERRROR")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.late:
> print ("ERR1")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.broken_chain:
> print ("ERR2")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.overflow:
> print ("ERR3")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.alignment:
> print ("ERR4")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.bad_packet:
> print ("ERR5")
>
> prom1 = np.fft.fft(recv_buff*w)
>* prom1[0:5]=**0*
> *prom1[num_samps-5:num_samps]=**0*
> prom1=np.fft.fftshift(prom1)
> fft1 = np.hstack((prom1,fft1))
> stream_cmd.time_spec = lib.types.time_spec(0)
> streamer.issue_stream_cmd(stream_cmd)
>
>
> 2017-11-16 13:35 GMT+02:00 Michał Wróbel :
>
>> I mixed the files
>>
>>
>> Context: I sent Ivan my FPGA and FW compilation. My FW didn't work, so I
>> recommended "mixing" the images - taking my FPGA and stock FW.
>>
>> the carriers as they were and remained
>>
>>
>> Do I see correctly that previously you had spikes at DC (-60..-58 dBm)
>> _and_ at some other frequencies (-50..-42 dBm) and now you have only DC
>> spikes (~-40 dBm)? Sorry, it's not very easy to me to read it from the
>> plots.
>>
>> Was this change a result "sewing" or the FPGA image change? It would be
>> helpful to see the effect of each of these actions separately.
>>
>> 2017-11-16 12:10 GMT+01:00 Ivan Zahartchuk :
>>
>>> I mixed the files and the card was sewn but the carriers as they were
>>> and remained.
>>>
>>> 2017-11-16 12:30 GMT+02:00 Michał Wróbel :
>>>
 Hey Derek,


 Hi Ivan, it's Michał here. ;-)

 uhd_image_loader --args="type=usrp2,addr=192.168.10.2,overwrite-safe"


 DON'T use "overwrite-safe" here! It's only for unbricking the device.
 If the firmware I sent you is incorrect - it might do the opposite -
 *brick* the firmware, so that you'll have to use a JTAG to recover it
 afterwards (BTW. do you have it, just in case?)

 Just use --args="type=usrp2,addr=192.168.10.2" as described in the
 "Load the Images onto the On-board Flash (USRP-N Series only)" / "Use the
 image loader" section (not the one in "Unbricking an N-Series Device").

 Regarding the "The file at path (...) is not a valid firmware image"
 error - indeed the firmware file I sent you is not compatible with
 uhd_image_loader. I'll check that later (maybe today evening).

 In the meantime I think you might try to mix stock FW image (i.e. from
 uh

Re: [USRP-users] spectrum analyzer USRP N210

[Michał Wróbel via USRP-users]

>
> I mixed the files


Context: I sent Ivan my FPGA and FW compilation. My FW didn't work, so I
recommended "mixing" the images - taking my FPGA and stock FW.

the carriers as they were and remained


Do I see correctly that previously you had spikes at DC (-60..-58 dBm)
_and_ at some other frequencies (-50..-42 dBm) and now you have only DC
spikes (~-40 dBm)? Sorry, it's not very easy to me to read it from the
plots.

Was this change a result "sewing" or the FPGA image change? It would be
helpful to see the effect of each of these actions separately.

2017-11-16 12:10 GMT+01:00 Ivan Zahartchuk :

> I mixed the files and the card was sewn but the carriers as they were and
> remained.
>
> 2017-11-16 12:30 GMT+02:00 Michał Wróbel :
>
>> Hey Derek,
>>
>>
>> Hi Ivan, it's Michał here. ;-)
>>
>> uhd_image_loader --args="type=usrp2,addr=192.168.10.2,overwrite-safe"
>>
>>
>> DON'T use "overwrite-safe" here! It's only for unbricking the device. If
>> the firmware I sent you is incorrect - it might do the opposite - *brick*
>> the firmware, so that you'll have to use a JTAG to recover it afterwards
>> (BTW. do you have it, just in case?)
>>
>> Just use --args="type=usrp2,addr=192.168.10.2" as described in the "Load
>> the Images onto the On-board Flash (USRP-N Series only)" / "Use the image
>> loader" section (not the one in "Unbricking an N-Series Device").
>>
>> Regarding the "The file at path (...) is not a valid firmware image"
>> error - indeed the firmware file I sent you is not compatible with
>> uhd_image_loader. I'll check that later (maybe today evening).
>>
>> In the meantime I think you might try to mix stock FW image (i.e. from
>> uhd-images package) with my FPGA image. Let me know if that works for you.
>>
>> Best,
>> Michał
>>
>> 2017-11-16 8:31 GMT+01:00 Ivan Zahartchuk :
>>
>>> Hey Derek,
>>> when the board was flashed, I got an error:
>>>
>>> uhd_image_loader --args="type=usrp2,addr=192.168.10.2,overwrite-safe"
>>> --fw-path=usrp_n210_fw1.bin --fpga-path=usrp_n210_r4_fpga1.bin
>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_003.010.002.heads-release_003_010_002_000-0-gbd6e21dc
>>>
>>> Unit: USRP N210 r4 (311D7A1, 192.168.10.2)
>>> Error: RuntimeError: The file at path "/home/suppression/usrp_n210_fw1.bin"
>>> is not a valid firmware image.
>>>
>>> Best regards,
>>> Ivan
>>>
>>> 2017-11-15 22:12 GMT+02:00 Michał Wróbel :
>>>
 Hey Ivan,

 I compiled the firmware for you. I assumed that you are using USRP N210
 R4. See the attachment. As said before - I didn't check it as I have no
 such hardware - it might completely not work (i.e. not even boot up). Let
 me know if it works.

 Best,
 Michał

 2017-11-15 18:12 GMT+01:00 Ivan Zahartchuk :

> Hi again.
>
> I've tried everything described in the article you're refering to. I'd
> be extremely grateful if you could try to compile FPGA bitstream for USRP
> N210 and send it to me.
>
> Best regards,
> Ivan
>
> 2017-11-15 17:21 GMT+02:00 Michał Wróbel :
>
>> Hey Ivan,
>>
>> if the problem with the spikes is what I think it is, you'll need a
>> new build of the FPGA bitstream. I can try to compile one with the most
>> fresh version from GitHub, but as I don't have USRP N210 (I only own
>> USRP2), I have no way to confirm that it works properly before I will 
>> send
>> it to you. Have you ever flashed your USRP (i.e. like described here
>> )?
>>
>> Also, Derek Kozel's has some other really good advice about spectrum
>> flatness, device calibration, etc. You should definitely try that too.
>>
>> Best,
>> Michał
>>
>>
>> 2017-11-15 14:51 GMT+01:00 Ivan Zahartchuk :
>>
>>> Tell me how to fix this problem. I'm not very versed in the FPGA
>>>
>>> 2017-11-15 15:51 GMT+02:00 Ivan Zahartchuk :
>>>
 Tell me how to fix this problem. I'm not very versed in the FIG.

 2017-11-15 15:39 GMT+02:00 Michał Wróbel >>> >:

> Hi Ivan,
>
> these spikes look similar to what I am experiencing with my
> USRP2+WBX and what seems to be already fixed in the GitHub repository:
>
> https://github.com/EttusResearch/fpga/pull/4
>
> I have asked about that just yesterday:
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
> 2017-November/027054.html
>
> Best regards,
> Michał
>
> 2017-11-15 14:26 GMT+01:00 Ivan Zahartchuk via USRP-users <
> usrp-users@lists.ettus.com>:
>
>> Hello. I'm trying to make a broadband spectrum analyzer. I
>> encountered some difficulties with the USRP N210 board. At
>> certain frequencies, I get such a picture. And there are
>> problems with the presence of central frequencies. Advise me ho

Re: [USRP-users] spectrum analyzer USRP N210

[Ivan Zahartchuk via USRP-users]

I mixed the files and the card was sewn but the carriers as they were and
remained.

2017-11-16 12:30 GMT+02:00 Michał Wróbel :

> Hey Derek,
>
>
> Hi Ivan, it's Michał here. ;-)
>
> uhd_image_loader --args="type=usrp2,addr=192.168.10.2,overwrite-safe"
>
>
> DON'T use "overwrite-safe" here! It's only for unbricking the device. If
> the firmware I sent you is incorrect - it might do the opposite - *brick*
> the firmware, so that you'll have to use a JTAG to recover it afterwards
> (BTW. do you have it, just in case?)
>
> Just use --args="type=usrp2,addr=192.168.10.2" as described in the "Load
> the Images onto the On-board Flash (USRP-N Series only)" / "Use the image
> loader" section (not the one in "Unbricking an N-Series Device").
>
> Regarding the "The file at path (...) is not a valid firmware image" error
> - indeed the firmware file I sent you is not compatible with
> uhd_image_loader. I'll check that later (maybe today evening).
>
> In the meantime I think you might try to mix stock FW image (i.e. from
> uhd-images package) with my FPGA image. Let me know if that works for you.
>
> Best,
> Michał
>
> 2017-11-16 8:31 GMT+01:00 Ivan Zahartchuk :
>
>> Hey Derek,
>> when the board was flashed, I got an error:
>>
>> uhd_image_loader --args="type=usrp2,addr=192.168.10.2,overwrite-safe"
>> --fw-path=usrp_n210_fw1.bin --fpga-path=usrp_n210_r4_fpga1.bin
>> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.002.heads-release_
>> 003_010_002_000-0-gbd6e21dc
>>
>> Unit: USRP N210 r4 (311D7A1, 192.168.10.2)
>> Error: RuntimeError: The file at path "/home/suppression/usrp_n210_fw1.bin"
>> is not a valid firmware image.
>>
>> Best regards,
>> Ivan
>>
>> 2017-11-15 22:12 GMT+02:00 Michał Wróbel :
>>
>>> Hey Ivan,
>>>
>>> I compiled the firmware for you. I assumed that you are using USRP N210
>>> R4. See the attachment. As said before - I didn't check it as I have no
>>> such hardware - it might completely not work (i.e. not even boot up). Let
>>> me know if it works.
>>>
>>> Best,
>>> Michał
>>>
>>> 2017-11-15 18:12 GMT+01:00 Ivan Zahartchuk :
>>>
 Hi again.

 I've tried everything described in the article you're refering to. I'd
 be extremely grateful if you could try to compile FPGA bitstream for USRP
 N210 and send it to me.

 Best regards,
 Ivan

 2017-11-15 17:21 GMT+02:00 Michał Wróbel :

> Hey Ivan,
>
> if the problem with the spikes is what I think it is, you'll need a
> new build of the FPGA bitstream. I can try to compile one with the most
> fresh version from GitHub, but as I don't have USRP N210 (I only own
> USRP2), I have no way to confirm that it works properly before I will send
> it to you. Have you ever flashed your USRP (i.e. like described here
> )?
>
> Also, Derek Kozel's has some other really good advice about spectrum
> flatness, device calibration, etc. You should definitely try that too.
>
> Best,
> Michał
>
>
> 2017-11-15 14:51 GMT+01:00 Ivan Zahartchuk :
>
>> Tell me how to fix this problem. I'm not very versed in the FPGA
>>
>> 2017-11-15 15:51 GMT+02:00 Ivan Zahartchuk :
>>
>>> Tell me how to fix this problem. I'm not very versed in the FIG.
>>>
>>> 2017-11-15 15:39 GMT+02:00 Michał Wróbel 
>>> :
>>>
 Hi Ivan,

 these spikes look similar to what I am experiencing with my
 USRP2+WBX and what seems to be already fixed in the GitHub repository:

 https://github.com/EttusResearch/fpga/pull/4

 I have asked about that just yesterday:

 http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
 2017-November/027054.html

 Best regards,
 Michał

 2017-11-15 14:26 GMT+01:00 Ivan Zahartchuk via USRP-users <
 usrp-users@lists.ettus.com>:

> Hello. I'm trying to make a broadband spectrum analyzer. I
> encountered some difficulties with the USRP N210 board. At
> certain frequencies, I get such a picture. And there are problems
> with the presence of central frequencies. Advise me how to remove
> these shortcomings.
> My code:
>
> n = int(math.ceil((config.stop_freq - config.start_freq) / 
> config.band))
> fft1 = np.array([], dtype=np.complex64)
> for i in range(0, n):
> usrp.set_rx_freq(lib.types.tune_request(config.start_freq + 
> config.band / 2 + config.band * i), 0)
> streamer.recv(recv_buff, config.metadata)
> if config.metadata.error_code == 
> lib.types.rx_metadata_error_code.timeout:
> print ("ERRROR")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.late:
> print ("ERR1")
> elif config.metadata.error_cod

[USRP-users] Receive samples at exact time_spec_t

[Hojoon Yang via USRP-users]

Hi.I use USRP B200 with external on-board GPSDO.1. I set the clock source and 
time soure to GPSDOusrp->set_clock_source("gpsdo", 0);
usrp->set_time_source("gpsdo", 0);2. Set_time_next_pps and sleep 2 secs.
usrp->set_time_next_pps(uhd::time_spec_t(0.0), 0);
boost::this_thread::sleep(boost::posix_time::seconds(2));3. Issue the stream 
command to start the stream from 3.0 seconds.uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.num_samps = 100;stream_cmd.stream_now = false;const 
uhd::time_spec_t stream_time = uhd::time_spec_t(3.0);stream_cmd.time_spec = 
stream_time;rx_stream->issue_stream_cmd(stream_cmd);4. Start the Rx streams 
and check received time.size_t num_rx_samps = 
rx_stream->recv(&buff.front(), buff.size(), md, 5.0);    
---
Received packet: 100 samples, 3 full secs, 0.37 frac secs Stream 
time was: 3 full secs, 0.00 frac secs Difference between stream time 
and first packet: 37.093750 usI command to start receving from 3.0 seconds, but 
the USRP B200 does not start at exact time(there are some delay, 37us).I guess 
it seems normal.(a)But is there any method to overcome this tiny difference? at 
least below 10 us.(b)Is the difference always same? If not, Could you tell me 
which things could change the difference? (c)Can I solve the problem If I set 
the stream time to 3.0s - 37us?It will be very appreciated if someone could 
answer the above three questions!Thanks in advance.___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] spectrum analyzer USRP N210

[Derek Kozel via USRP-users]

I've added back on the mailing list, just include usrp-users@lists.ettus.com
as a to: address. If you use reply-all in the future it will keep the list
up to date.

The "n" value needs to be adjusted now that the step size is 20% smaller.

On Thu, Nov 16, 2017 at 9:34 AM, Ivan Zahartchuk 
wrote:

> Yes, thanks to the spectrum is much better. the only negative is the
> central frequencies they are formed in the USRP itself. This can be seen
> on the graph in the time domain. Unfortunately I do not know how to add
> more people to this discussion. If you can do this I will be very grateful
>
> 2017-11-16 11:26 GMT+02:00 Derek Kozel :
>
>> Your spectrum looks far better, good. Are you happy with it?
>>
>> The large noiseless signals between each step look too identical and
>> clean. I recommend taking the samples from a single window and examining
>> the FFT at full bandwidth, at 80% bandwidth, and after your fftshift and
>> seeing if you can identify when that occurs.
>>
>> I recommend adding the usrp-users mailing list back onto this thread and
>> seeing anyone else can give advice on further improvements.
>>
>> On Thu, Nov 16, 2017 at 8:52 AM, Ivan Zahartchuk 
>> wrote:
>>
>>> Hi,
>>> Derek
>>> I did as you said. Here's what I got:
>>>
>>> n = int(math.ceil((config.stop_freq - config.start_freq) / config.band))
>>> fft1 = np.array([], dtype=np.complex64)
>>> fft2 = np.array([], dtype=np.complex64)
>>> for i in range(0, n):
>>> usrp.set_rx_freq(lib.types.tune_request(config.start_freq + config.band 
>>> / 2 + (config.band*0.8) * i), 0)
>>> streamer.recv(recv_buff, config.metadata)
>>> if config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.timeout:
>>> print ("ERRROR")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.late:
>>> print ("ERR1")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.broken_chain:
>>> print ("ERR2")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.overflow:
>>> print ("ERR3")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.alignment:
>>> print ("ERR4")
>>> elif config.metadata.error_code == 
>>> lib.types.rx_metadata_error_code.bad_packet:
>>> print ("ERR5")
>>>   # np.array(recv_buff,dtype=np.float16)
>>> prom1 = np.fft.fft(recv_buff)
>>> prom1[0:5]=0
>>> prom1[num_samps-5:num_samps]=0
>>> prom1=np.fft.fftshift(prom1)
>>> prom1= 
>>> prom1[math.ceil(num_samps*0.1):num_samps-math.ceil(num_samps*0.1)]
>>>
>>> #prom1= np.fft.fftshift(prom1)*w
>>> fft1 = np.hstack((fft1,prom1))
>>> #print(fft1.shape)
>>> stream_cmd.time_spec = lib.types.time_spec(0)
>>> streamer.issue_stream_cmd(stream_cmd)
>>>
>>>
>>> 2017-11-15 15:56 GMT+02:00 Derek Kozel :
>>>
 Hello Ivan,

 The rule of thumb is that the digital filters are flat over 80% of the
 passband. A good start would be to exclude the first and last 10% of each
 FFT and reduce your frequency step size to 80% of the sample rate. This
 will flatten your spectrum considerably.

 USRPs have a calibration routine for many of the daughterboards, which
 one are you using? Some DC offset spur is usually inevitable, but there are
 correction algorithms built into the USRP's FPGA. The tool will calculate
 values for these APIs but also they can be set manually.
 http://files.ettus.com/manual/page_calibration.html
 http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usr
 p.html#a263ab7f0364c03e8a6e330c546769e4f
 http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usr
 p.html#a586c52db545664cb2caf830ac90c051e

 Regards,
 Derek



 On Wed, Nov 15, 2017 at 1:26 PM, Ivan Zahartchuk via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello. I'm trying to make a broadband spectrum analyzer. I
> encountered some difficulties with the USRP N210 board. At certain
> frequencies, I get such a picture. And there are problems with the
> presence of central frequencies. Advise me how to remove these
> shortcomings.
> My code:
>
> n = int(math.ceil((config.stop_freq - config.start_freq) / config.band))
> fft1 = np.array([], dtype=np.complex64)
> for i in range(0, n):
> usrp.set_rx_freq(lib.types.tune_request(config.start_freq + 
> config.band / 2 + config.band * i), 0)
> streamer.recv(recv_buff, config.metadata)
> if config.metadata.error_code == 
> lib.types.rx_metadata_error_code.timeout:
> print ("ERRROR")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.late:
> print ("ERR1")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_error_code.broken_chain:
> print ("ERR2")
> elif config.metadata.error_code == 
> lib.types.rx_metadata_err