Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Implementing design on FPGA in X310 (Ryan Marlow)
2. Re: RX chain slow down due to TX chain U/L warnings (Michael West)
3. how to use the img file posted on the website to upgrade my
E310 ? (zhan siyu)
4. Re: how to use the img file posted on the website to upgrade
my E310 ? (Philip Balister)
5. Re: RX chain slow down due to TX chain U/L warnings
(Dario Fertonani)
6. Re: Cannot remove X310 image (Paul David)
7. Re: Cannot remove X310 image (Paul David)
8. Fwd: Demuxer Error : Bad Frames (My Solution So Far)
(Kevin McGuire)
9. Re: Issue with DmaFIFO uhd::lookup_error' (Jonathon Pendlum)
10. Re: RFNOC x310 image 2 bytes too large (Long, Jeffrey P.)
11. Re: RFNOC x310 image 2 bytes too large (Jonathon Pendlum)
12. Re: RFNOC x310 image 2 bytes too large (Long, Jeffrey P.)
13. Re: RFNOC x310 image 2 bytes too large (Jonathon Pendlum)
14. Re: Error Using X310 ( NI USRP 2940 R) (Marcus M?ller)
15. X310/UBX-160 Tx output power (Rob Kossler)
16. Re: X310/UBX-160 Tx output power (Matt Ettus)
17. Re: X310/UBX-160 Tx output power (Rob Kossler)
18. Re: X310/UBX-160 Tx output power (Matt Ettus)
19. Re: X310/UBX-160 Tx output power (Rob Kossler)
20. Re: X310/UBX-160 Tx output power (Matt Ettus)
21. Re: X310/UBX-160 Tx output power (Rob Kossler)
22. Re: X310/UBX-160 Tx output power (Marcus M?ller)
23. Re: X310/UBX-160 Tx output power (Rob Kossler)
24. Re: X310/UBX-160 Tx output power (Matt Ettus)
25. TX/RX Fixed Signal Phase Synchronization (Sam Carey)
26. Re: TX/RX Fixed Signal Phase Synchronization (Marcus M?ller)
27. API that clears recv buffer? (Dario Fertonani)
28. Fwd: Help In installing Yate BTS with B200 (ayush gupta)
29. Re: Cannot remove X310 image (David Miller)
30. Re: Fwd: Help In installing Yate BTS with B200 (Marcus M?ller)
31. Re: Cannot remove X310 image (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 30 Sep 2016 12:00:29 -0400
From: Ryan Marlow <[email protected]>
To: Nives Novkovi? <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Implementing design on FPGA in X310
Message-ID:
<cadve_uy5cerges-jfuyncjrn9kh6s++hgedkt8yjdnylxr5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Nives,
You need to look in usrp3_rfnoc for the x300 code.
Best,
Ryan
On Fri, Sep 30, 2016 at 11:40 AM, Nives Novkovi? via USRP-users <
[email protected]> wrote:
> Hi Jonathon,
>
> Thank you for the quick reply. I thought so too, but I cannot find the
> directory usrp3/top/x300. This is all I see
>
> 2016-09-30 17:32 GMT+02:00 Jonathon Pendlum <[email protected]>:
>
>> Hi Nives,
>>
>> The xdc files in the directory usrp3/top/x300 are the constraint files
>> you will want to use in a X3x0 design (x300.xdc, x300_dram.xdc, etc...).
>> You absolutely cannot use a E310 constraints file (such as e300.xdc) in a
>> X310 design or vice versa.
>>
>>
>>
>> Jonathon
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/7975ad73/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_17.png
Type: image/png
Size: 52898 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/7975ad73/attachment-0001.png>
------------------------------
Message: 2
Date: Fri, 30 Sep 2016 09:42:37 -0700
From: Michael West <[email protected]>
To: Dario Fertonani <[email protected]>
Cc: Tom Tsou <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RX chain slow down due to TX chain U/L
warnings
Message-ID:
<CAM4xKrrgrBLBYbsjsbs26eR=pyz0nmu5po7l-amj7vcaw7m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Dario,
This is by design. The metadata corresponds with the first sample in the
buffer. When an overflow occurs, the data received with no errors is
returned to the caller with ERROR_CODE_NONE to indicate that there was no
error with those samples. The ERROR_CODE_OVERFLOW is reported in the
metadata on the next call to return to indicate that the error occurred at
that point in the data stream so the caller can take appropriate action.
All data and data stream error messages coming from the USRP to host use
the same USB endpoint and transport. This means errors on TX will impact
RX performance. To completely decouple it would take major changes to the
FPGA and UHD code. Arguably, there should have separate endpoints and
transports per channel but that means more resource utilization in the FPGA.
There are a few things that can be done to improve the situation though:
First, align the buffer size in the application with the packet size. The
packet size (in number of samples) can be determined with a call to
tx/rx_streamer::get_max_num_samps(). If the buffer and packet size are the
same, the recv() call will never return with fewer samples and it will
minimize the time waiting to handle packets with TX errors.
Second, increase the num_recv_frames value to something like 256 or 512
(whatever your USB controller can handle). This will increase the number
of USB receive transfers queued up in libusb at any given moment. The
default is only 16, so it can easily be overwhelmed by a series of error
packets.
Third, and finally, do as Tom suggests and increase the priority of the
thread that creates the muli_usrp object. This will give priority to the
thread handling the USB transfers.
You may also want to increase the num_send_frames value and align the
buffer size on the TX side as well to see if it helps reduce the number of
U/Ls.
Hope this helps.
Regards,
Michael
On Thu, Sep 29, 2016 at 4:12 PM, Dario Fertonani via USRP-users <
[email protected]> wrote:
> I learned a bit more about the problem. The recv call returns with
> fewer-than-expected samples, which I assumed was due to a timeout (all of
> this is in the middle of a STREAM_MODE_START_CONTINUOUS recv stream) and
> hence called a "RX slowdown". However, I verified with other timers that no
> timeout actually happened. What else can be going on? More formally:
>
> *Why would the recv call return with fewer-than-expected samples if not
> for a timeout?*
>
> In case it matters, I'm referring to recv calls with four parameters
> (hence, with the fifth parameter one_packet left to its default value).
>
> This is the metadata dump for the call the returns unexpectedly:
> Has timespec: Yes Time of first sample: 145.803
> Fragmented: No Fragmentation offset: 0
> Start of burst: No End of burst: No
> Error Code: ERROR_CODE_NONE Out of sequence: No
>
> And this is the metadata dump for the following call (debug only, as the
> previous return kills everything in regular operations).
> Has timespec: Yes Time of first sample: 145.804
> Fragmented: No Fragmentation offset: 0
> Start of burst: No End of burst: No
> Error Code: ERROR_CODE_OVERFLOW (Overflow) Out of
> sequence: No
>
>
>
>
>
> On Thu, Sep 29, 2016 at 12:19 AM, Tom Tsou <[email protected]> wrote:
>
>> On Sat, Sep 24, 2016 at 11:32 AM, Dario Fertonani via USRP-users
>> <[email protected]> wrote:
>> > The following is seen on all B210 models we have, and is more
>> pronounced at
>> > high sampling rates (20+ MHz) in full-duplex MIMO operations.
>> >
>> > A stream of U/L warnings, caused by about 10-15 ms worth of IQ samples
>> > getting too late to the TX chain, causes the rx chain to slow down too.
>> > Specifically, the recv( ) call blocks for longer. If the U/L warnings
>> are a
>> > few ms worth of IQ samples, nothing that critical happens.
>>
>> Consider setting uhd::set_thread_priority() on the main thread (where
>> you call the usrp constructor). Then run the application as root or
>> setup priority user permissions. That should reduce I/O call blocking
>> by boosting the thread priority of the USB event handler internal to
>> UHD.
>>
>> Also, if you are using 16-bit samples over-the-wire, try setting the
>> streamers to 12-bits. If 12-bit samples perform worse, then there are
>> CPU limitations - 12-bit (un)packing trades lower I/O for higher
>> sample processing load.
>>
>> > Is there any way to configure UHD so that a better decoupling of TX and
>> RX
>> > chains is achieved? I'm assuming some buffer fills up, either in the
>> host
>> > machine or in the B210 FPGA, creating this unwanted coupling. Maybe
>> tuning
>> > some of the optional parameters in stream_args_t?
>>
>> USB is asynchronously driven by the host so Tx/Rx inherently have some
>> overlap. Pure buffer blocking can be addressed by increasing libusb
>> transport parameters. Buffer tuning gains are possible but I suspect
>> preemption where the I/O itself stalls (due to the OS or application
>> itself taking over) is the bigger issue.
>>
>> http://files.ettus.com/manual/page_transport.html#transport_usb_params
>>
>> > Another possibility I thought about... Maybe the RX slow down is due to
>> the
>> > async messages in charge of catching/dumping the TX warnings.
>>
>> Doesn't hurt, but probably won't help much either.
>>
>> -TT
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/43a01ace/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 30 Sep 2016 20:54:32 +0800
From: zhan siyu <[email protected]>
To: [email protected]
Subject: [USRP-users] how to use the img file posted on the website to
upgrade my E310 ?
Message-ID:
<CAGNex4g0-6fEJGyfANzjTHhNLEG69K4p1VQmCOg4MhJOMb_=z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear All,
Sorry to bother you. I'm new to the USRP field. Currently, I have 2 USRP
E310 of which the P/N are 156333C-01L. According to the readme file, I
downloaded the img files in the "ettus-e3xx-sg1" folder.
But it doesn't work after I burn the img to my new SD card. It seems that
the device can not boot up as the four lights above the antenna interfaces
are keeping "on" after I power on the device.
Dose anyone have met this before ? Can anyone help me ?
Thanks a lot.
zsy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/120b0b46/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 30 Sep 2016 10:58:10 -0700
From: Philip Balister <[email protected]>
To: zhan siyu <[email protected]>, [email protected]
Subject: Re: [USRP-users] how to use the img file posted on the
website to upgrade my E310 ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 09/30/2016 05:54 AM, zhan siyu via USRP-users wrote:
> Dear All,
>
> Sorry to bother you. I'm new to the USRP field. Currently, I have 2 USRP
> E310 of which the P/N are 156333C-01L. According to the readme file, I
> downloaded the img files in the "ettus-e3xx-sg1" folder.
>
> But it doesn't work after I burn the img to my new SD card. It seems that
> the device can not boot up as the four lights above the antenna interfaces
> are keeping "on" after I power on the device.
>
> Dose anyone have met this before ? Can anyone help me ?
How are you writing the image to the SD card? Since the lights stay on,
the E310 is not able to load any files from the card.
Philip
>
> Thanks a lot.
>
> zsy
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Fri, 30 Sep 2016 10:58:35 -0700
From: Dario Fertonani <[email protected]>
To: Michael West <[email protected]>
Cc: Tom Tsou <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RX chain slow down due to TX chain U/L
warnings
Message-ID:
<CAJGEdAj5A7Szv7a1buZjz=adsoxofone-5xua9jhc2mkhhw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thank you Michael, I understand better now.
My code already does all things you suggested about the stream params (see
below in red, if interested). Same for the thread settings, by default set
to SCHED_FIFO at priority 40 (right below OS stuff on "Ubuntu lowlatency",
but above everything else).
With default settings for FDD LTE at 20 MHz, I get spp=1920,
recv_frame_size=send_frame_size=8192, num_recv_frames=1536,
num_send_frames=384. I'll play a bit with the num_recv_frames=1536 number,
as you seem to suggest it may be too high for my USB controller to handle.
uhd::stream_args_t rxStreamParams( UhdHostSampleFormat_str ,
UhdWireSampleFormat_str );
uhd::stream_args_t txStreamParams( UhdHostSampleFormat_str ,
UhdWireSampleFormat_str );
rxStreamParams.channels = { 0 , 1 , 2 , 3 };
txStreamParams.channels = { 0 , 1 , 2 , 3 };
rxStreamParams.channels.resize( rxAntennas );
txStreamParams.channels.resize( txAntennas );
* rxStreamParams.args[ "spp" ] = str( boost::format( "%d" ) % uhdRecvSpp
);*
* txStreamParams.args[ "spp" ] = str( boost::format( "%d" ) % uhdSendSpp
);*
* rxStreamParams.args[ "recv_frame_size" ] = str( boost::format( "%d" )
% uhdRecvFrameSize );*
* txStreamParams.args[ "send_frame_size" ] = str( boost::format( "%d" )
% uhdSendFrameSize );*
* rxStreamParams.args[ "num_recv_frames" ] = str( boost::format( "%d" )
% uhdNumRecvFrames );*
* txStreamParams.args[ "num_send_frames" ] = str( boost::format( "%d" )
% uhdNumSendFrames );*
rxStreamPtr = rfBoardPtr->get_rx_stream( rxStreamParams );
txStreamPtr = rfBoardPtr->get_tx_stream( txStreamParams );
On Fri, Sep 30, 2016 at 9:42 AM, Michael West <[email protected]>
wrote:
> Hi Dario,
>
> This is by design. The metadata corresponds with the first sample in the
> buffer. When an overflow occurs, the data received with no errors is
> returned to the caller with ERROR_CODE_NONE to indicate that there was no
> error with those samples. The ERROR_CODE_OVERFLOW is reported in the
> metadata on the next call to return to indicate that the error occurred at
> that point in the data stream so the caller can take appropriate action.
>
> All data and data stream error messages coming from the USRP to host use
> the same USB endpoint and transport. This means errors on TX will impact
> RX performance. To completely decouple it would take major changes to the
> FPGA and UHD code. Arguably, there should have separate endpoints and
> transports per channel but that means more resource utilization in the FPGA.
>
> There are a few things that can be done to improve the situation though:
>
> First, align the buffer size in the application with the packet size. The
> packet size (in number of samples) can be determined with a call to
> tx/rx_streamer::get_max_num_samps(). If the buffer and packet size are
> the same, the recv() call will never return with fewer samples and it will
> minimize the time waiting to handle packets with TX errors.
>
> Second, increase the num_recv_frames value to something like 256 or 512
> (whatever your USB controller can handle). This will increase the number
> of USB receive transfers queued up in libusb at any given moment. The
> default is only 16, so it can easily be overwhelmed by a series of error
> packets.
>
> Third, and finally, do as Tom suggests and increase the priority of the
> thread that creates the muli_usrp object. This will give priority to the
> thread handling the USB transfers.
>
> You may also want to increase the num_send_frames value and align the
> buffer size on the TX side as well to see if it helps reduce the number of
> U/Ls.
>
> Hope this helps.
>
> Regards,
> Michael
>
> On Thu, Sep 29, 2016 at 4:12 PM, Dario Fertonani via USRP-users <
> [email protected]> wrote:
>
>> I learned a bit more about the problem. The recv call returns with
>> fewer-than-expected samples, which I assumed was due to a timeout (all of
>> this is in the middle of a STREAM_MODE_START_CONTINUOUS recv stream) and
>> hence called a "RX slowdown". However, I verified with other timers that no
>> timeout actually happened. What else can be going on? More formally:
>>
>> *Why would the recv call return with fewer-than-expected samples if not
>> for a timeout?*
>>
>> In case it matters, I'm referring to recv calls with four parameters
>> (hence, with the fifth parameter one_packet left to its default value).
>>
>> This is the metadata dump for the call the returns unexpectedly:
>> Has timespec: Yes Time of first sample: 145.803
>> Fragmented: No Fragmentation offset: 0
>> Start of burst: No End of burst: No
>> Error Code: ERROR_CODE_NONE Out of sequence: No
>>
>> And this is the metadata dump for the following call (debug only, as the
>> previous return kills everything in regular operations).
>> Has timespec: Yes Time of first sample: 145.804
>> Fragmented: No Fragmentation offset: 0
>> Start of burst: No End of burst: No
>> Error Code: ERROR_CODE_OVERFLOW (Overflow) Out of
>> sequence: No
>>
>>
>>
>>
>>
>> On Thu, Sep 29, 2016 at 12:19 AM, Tom Tsou <[email protected]> wrote:
>>
>>> On Sat, Sep 24, 2016 at 11:32 AM, Dario Fertonani via USRP-users
>>> <[email protected]> wrote:
>>> > The following is seen on all B210 models we have, and is more
>>> pronounced at
>>> > high sampling rates (20+ MHz) in full-duplex MIMO operations.
>>> >
>>> > A stream of U/L warnings, caused by about 10-15 ms worth of IQ samples
>>> > getting too late to the TX chain, causes the rx chain to slow down too.
>>> > Specifically, the recv( ) call blocks for longer. If the U/L warnings
>>> are a
>>> > few ms worth of IQ samples, nothing that critical happens.
>>>
>>> Consider setting uhd::set_thread_priority() on the main thread (where
>>> you call the usrp constructor). Then run the application as root or
>>> setup priority user permissions. That should reduce I/O call blocking
>>> by boosting the thread priority of the USB event handler internal to
>>> UHD.
>>>
>>> Also, if you are using 16-bit samples over-the-wire, try setting the
>>> streamers to 12-bits. If 12-bit samples perform worse, then there are
>>> CPU limitations - 12-bit (un)packing trades lower I/O for higher
>>> sample processing load.
>>>
>>> > Is there any way to configure UHD so that a better decoupling of TX
>>> and RX
>>> > chains is achieved? I'm assuming some buffer fills up, either in the
>>> host
>>> > machine or in the B210 FPGA, creating this unwanted coupling. Maybe
>>> tuning
>>> > some of the optional parameters in stream_args_t?
>>>
>>> USB is asynchronously driven by the host so Tx/Rx inherently have some
>>> overlap. Pure buffer blocking can be addressed by increasing libusb
>>> transport parameters. Buffer tuning gains are possible but I suspect
>>> preemption where the I/O itself stalls (due to the OS or application
>>> itself taking over) is the bigger issue.
>>>
>>> http://files.ettus.com/manual/page_transport.html#transport_usb_params
>>>
>>> > Another possibility I thought about... Maybe the RX slow down is due
>>> to the
>>> > async messages in charge of catching/dumping the TX warnings.
>>>
>>> Doesn't hurt, but probably won't help much either.
>>>
>>> -TT
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/f7568fb3/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 30 Sep 2016 11:10:25 -0700
From: Paul David <[email protected]>
To: David Miller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID:
<cacjvjtwyxzz-lg3l6r1k6bpbxgavfgxuefee1wdi4fykt7y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi David,
Are you certain you're on the same version of UHD as the FPGA image?
On Fri, Sep 30, 2016 at 3:42 AM, David Miller <[email protected]>
wrote:
> Hi Paul and usrp-users,
>
> So, I used Vivado hardware manager to program the FPGA with 3.9.4 bitfile
> (I'm stuck with 3.9.4 for the moment) and confirmed with uhd_usrp_probe
> that all appears OK.
> I did not power cycle the X310.
> But then trying to use uhd_image_loader with the 3.9.4 bitfile fails with
> the same "Error: RunTimeError: Device reported an error during
> initialization".
>
> Maybe I should re-program the 3.8.2 image back first?
>
> Any ideas?
>
> Thanks,
> Dave
>
>
> On 20/09/2016 19:07, Paul David wrote:
>
> Hi David,
>
> To answer your question: you do need Vivado in order to configure the FPGA
> over JTAG using the command: viv_jtag_program <bitfile path> .
>
> Or you can use the hardware manager in Vivado. After you do that, you'll
> need to use uhd_image_loader to burn the same FPGA image so that it
> persists after a power cycle.
>
> I would recommend upgrading UHD to a more recent tagged release as well.
>
> -- Paul
>
> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>>
>> I have acquired an X310 with an image based on the original uhd 3.8.2
>> image, not sure what it does but doing a uhd_usrp_probe with uhd 3.8.2 it
>> works as expected, however no samples are emitted with the utilities, it's
>> hosed!
>>
>> Anyways, I have tried the 3.8.2 burn program (usrp_x3xx_fpga_burner)
>> which fails, and currently tried the 3.9.4 uhd_image_loader.
>>
>> uhd_image_loader fails (and similarly usrp_x3xx_fpga_burner) with:
>>
>> Error: RunTimeError: Device reported an error during initialization.
>>
>> I hacked the code in the x310_send_and_receive() function, somewhere in
>> the code, to see if there is any kind of status message generated that
>> might help, the recv function returns a len of 4 (0 being a timeout), which
>> fails a subsequent check function that masks this len value (with 0x04, or
>> whatever the def is) to determine that this is a failure. Sorry to be a bit
>> vague, I don't have the setup in front of me at the moment.
>>
>> So, the real question is: How do I recover the unit and burn back a
>> working image, is it now only possible using Vivado/ISE/JTAG?
>>
>> Hope you can help?
>>
>> Thanks,
>> Dave
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
>
--
#* Paul David*
# *Staff Software Design Engineer*
#* Ettus Research - A National Instruments Company*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/68c54f9f/attachment-0001.html>
------------------------------
Message: 7
Date: Fri, 30 Sep 2016 11:12:31 -0700
From: Paul David <[email protected]>
To: David Miller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID:
<cacjvjtvj2mjb6k6pkvf76unsmlh5stk4idsnooq+fcyjac4...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Also, could you provide the arguments you're supplying to uhd_image_loader?
On Fri, Sep 30, 2016 at 11:10 AM, Paul David <[email protected]> wrote:
> Hi David,
>
> Are you certain you're on the same version of UHD as the FPGA image?
>
> On Fri, Sep 30, 2016 at 3:42 AM, David Miller <[email protected]>
> wrote:
>
>> Hi Paul and usrp-users,
>>
>> So, I used Vivado hardware manager to program the FPGA with 3.9.4 bitfile
>> (I'm stuck with 3.9.4 for the moment) and confirmed with uhd_usrp_probe
>> that all appears OK.
>> I did not power cycle the X310.
>> But then trying to use uhd_image_loader with the 3.9.4 bitfile fails with
>> the same "Error: RunTimeError: Device reported an error during
>> initialization".
>>
>> Maybe I should re-program the 3.8.2 image back first?
>>
>> Any ideas?
>>
>> Thanks,
>> Dave
>>
>>
>> On 20/09/2016 19:07, Paul David wrote:
>>
>> Hi David,
>>
>> To answer your question: you do need Vivado in order to configure the
>> FPGA over JTAG using the command: viv_jtag_program <bitfile path> .
>>
>> Or you can use the hardware manager in Vivado. After you do that, you'll
>> need to use uhd_image_loader to burn the same FPGA image so that it
>> persists after a power cycle.
>>
>> I would recommend upgrading UHD to a more recent tagged release as well.
>>
>> -- Paul
>>
>> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi,
>>>
>>> I have acquired an X310 with an image based on the original uhd 3.8.2
>>> image, not sure what it does but doing a uhd_usrp_probe with uhd 3.8.2 it
>>> works as expected, however no samples are emitted with the utilities, it's
>>> hosed!
>>>
>>> Anyways, I have tried the 3.8.2 burn program (usrp_x3xx_fpga_burner)
>>> which fails, and currently tried the 3.9.4 uhd_image_loader.
>>>
>>> uhd_image_loader fails (and similarly usrp_x3xx_fpga_burner) with:
>>>
>>> Error: RunTimeError: Device reported an error during initialization.
>>>
>>> I hacked the code in the x310_send_and_receive() function, somewhere in
>>> the code, to see if there is any kind of status message generated that
>>> might help, the recv function returns a len of 4 (0 being a timeout), which
>>> fails a subsequent check function that masks this len value (with 0x04, or
>>> whatever the def is) to determine that this is a failure. Sorry to be a bit
>>> vague, I don't have the setup in front of me at the moment.
>>>
>>> So, the real question is: How do I recover the unit and burn back a
>>> working image, is it now only possible using Vivado/ISE/JTAG?
>>>
>>> Hope you can help?
>>>
>>> Thanks,
>>> Dave
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>>
>
>
> --
> #* Paul David*
> # *Staff Software Design Engineer*
> #* Ettus Research - A National Instruments Company*
>
--
#* Paul David*
# *Staff Software Design Engineer*
#* Ettus Research - A National Instruments Company*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/e5d2cc12/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 30 Sep 2016 14:34:34 -0500
From: Kevin McGuire <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: Demuxer Error : Bad Frames (My Solution So
Far)
Message-ID:
<cacvsexkmc8zl1m2db91x0n7fvxf6ryhxdxjjavdmatk1d9c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, Sep 7, 2016 at 9:26 PM, Marcus D. Leech <[email protected]> wrote:
>
> The problem is that the consumer electronics end of the PC world changes
> very quickly. You can find that a card that was called
> a "wonderthing 5000 USB3 card" will change controllers mid-production.
> So, an early production run of it might be fine, and then
> a later run, it's something totally different.
>
Good news. My new system works great with Linux. It is a mid-performance
system as a HP Pavilion G7. I suppose as you said listing the hardware or
chipset is not very helpful; however, I did experience a bad VRT header
under VirtualBox'ed Linux system hosted by Windows. It may be that systems
that are too slow trigger the big also. I was able to test and get 56MSPS
(I believe I had to use scalar complex 8-bit over the wire) on this system
for RX--- and I am sure that RX and TX would work if properly sharing the
bandwidth.
So, a wonderful piece of engineering! Was wonderful even when it only did
6MSPS too, lol.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/e2208d7b/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 30 Sep 2016 14:40:13 -0500
From: Jonathon Pendlum <[email protected]>
To: Walter Maguire <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Issue with DmaFIFO uhd::lookup_error'
Message-ID:
<CAGdo0uQh4=ucsgsng+ylqpwa_r+64pwbapok3dyvzadwt2y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Walter,
The DMA FIFO RFNoC block is not a normal rfnoc block. It is meant to
interface with DRAM via a Xilinx MIG instance. You can look at x300_core.v
to see how it should be used. On the E310, we have a mig instance in the
e300/ip you can use.
Jonathon
On Tue, Sep 27, 2016 at 11:38 PM, Walter Maguire via USRP-users <
[email protected]> wrote:
> Hi all
>
> I am using this commit c41b8330f7d700feeae4819e7f7241fe3fd2bc7b on the
> rfnoc-devel branch.
>
> This should be the top of the commits.
>
> If I build the standard FPGA set with this commit all is fine. However,
> if I modify file rfnoc_ce_auto_inst_e310.v to have only 3 CEs as shown
> below and rebuild the uhd_usrp_probe command fails as shown below.
>
> root@ettus-e3xx-sg1:~# uhd_usrp_probe --init-only
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_004.000.000.rfnoc-devel-
> 641-g8773fb2c
>
> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
> -- Initializing core control (global registers)...
> -- Performing register loopback test... pass
> -- Initializing AD9361 using hard SPI core...OK
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 0 to be stream 0
> -- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:10)...O
> -- Port 16: Found NoC-Block with ID 12AD100000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- [E300] Setting up dest map for host ep 1 to be stream 1
> -- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:11)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- [RFNoC Factory] Using controller key 'E3XXRadio' and block name 'Radio'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
> -- Found valid blockdef
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] block_ctrl_base::clear()
> -- [0/Radio_0] node_ctrl_base::clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> -- [0/Radio_0] block_ctrl_base::_clear()
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1: type =
> 'sc16' pkt_size = '0' vlen = '0'
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] e3xx_radio_ctrl_impl::ctor()
> -- Setting time source to internal
> -- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
> -- [0/Radio_0] Creating internal GPIOs...
> -- [0/Radio_0] Setting tick rate...
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 2 to be stream 2
> -- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:20)...OK
> -- Port 32: Found NoC-Block with ID F1F0000000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_0
> -- [0/FIFO_0] block_ctrl_base::clear()
> -- [0/FIFO_0] node_ctrl_base::clear()
> -- [0/FIFO_0] block_ctrl_base::_clear()
> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/in/0: type = ''
> pkt_size = '0' vlen = '0'
> -- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/out/0: type = ''
> pkt_size = '0' vlen = '0'
> -- [RFNOC] ------- Block Setup -----------
> -- [E300] Setting up dest map for host ep 3 to be stream 3
> -- Setting up NoC-Shell Control for port #0 (SID: 00:03>02:30)...OK
> -- Port 48: Found NoC-Block with ID F1F0D00000000000.
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- [E300] Setting up dest map for host ep 4 to be stream 4
> -- Setting up NoC-Shell Control for port #1 (SID: 00:04>02:31)...OK
> -- [RFNoC Factory] block_ctrl_base::make()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- [RFNoC Factory] Using controller key 'DmaFIFO' and block name 'DmaFIFO'
> -- block_ctrl_base()
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/dma_fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0D00000000000 Block ID: 0/DmaFIFO_0
> -- [0/DmaFIFO_0] block_ctrl_base::clear()
> -- [0/DmaFIFO_0] node_ctrl_base::clear()
> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
> -- [0/DmaFIFO_0] block_ctrl_base::_clear()
> terminate called after throwing an instance of 'uhd::lookup_error'
> what(): LookupError: Path not found in tree: /mboards/0/tx_dsps/0
> Aborted
>
> The changes to the rfnoc_ce_auto_inst_e310.v file are as follows
>
> localparam NUM_CE = 2; // Must be no more than 14 (2 ports taken by
> radio core & PS-PL DMA).
>
> wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
> wire [63:0] ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
> wire [NUM_CE-1:0] ce_o_tlast, ce_o_tvalid, ce_o_tready, ce_i_tlast,
> ce_i_tvalid, ce_i_tready;
> wire [63:0] ce_debug[0:NUM_CE-1];
>
> // Flattern CE tdata arrays
> genvar k;
> generate
> for (k = 0; k < NUM_CE; k = k + 1) begin
> assign ce_o_tdata[k] = ce_flat_o_tdata[k*64+63:k*64];
> assign ce_flat_i_tdata[k*64+63:k*64] = ce_i_tdata[k];
> end
> endgenerate
>
> wire ce_clk = radio_clk;
> wire ce_rst = radio_rst;
>
> noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[0]), .i_tlast(ce_o_tlast[0]),
> .i_tvalid(ce_o_tvalid[0]), .i_tready(ce_o_tready[0]),
> .o_tdata(ce_i_tdata[0]), .o_tlast(ce_i_tlast[0]),
> .o_tvalid(ce_i_tvalid[0]), .o_tready(ce_i_tready[0]),
> .debug(ce_debug[0]));
>
>
> noc_block_axi_dma_fifo inst_noc_block_axi_dma_fifo (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[1]), .i_tlast(ce_o_tlast[1]),
> .i_tvalid(ce_o_tvalid[1]), .i_tready(ce_o_tready[1]),
> .o_tdata(ce_i_tdata[1]), .o_tlast(ce_i_tlast[1]),
> .o_tvalid(ce_i_tvalid[1]), .o_tready(ce_i_tready[1]),
> .debug(ce_debug[1]));
>
>
> I would be grateful for any feedback on this issue.
>
> Regards
>
>
> Walter
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/f11a3eca/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 30 Sep 2016 19:52:50 +0000
From: "Long, Jeffrey P." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<cy4pr09mb1367d3dc67147273fb8869ccd9...@cy4pr09mb1367.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Jonathon-
I just noticed something strange and maybe you can explain this so I understand
how it is supposed to build.
There appear to be two rfnoc_ce_XXXX_inst_x310.v files. There is a default one
and an auto one. There is an `ifdef to bring in one or the other in x300_core.v.
The auto one has all the example blocks in it and the default one has only the
DDC,DUC etc.. It seems that if RFNOC is defined you are going to bring in the
auto one and all the example ce.
I noticed that when I run image downloader and pull down the default images,
burn it and usrpprobe it that it is in fact the default image with only the
DDC,DUC etc..
So when I build a new image by doing make X310_RFNOC_HG am I doing the auto
file? In which case this is not what is being built by you guys and pushed to
us during an image download? Are the non RFNOC targets the way to build the
default images?
Thanks
Jeff
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Friday, September 30, 2016 11:37 AM
To: Long, Jeffrey P.
Cc: [email protected]
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Hi Jeff,
Another customer has reported this issue. I thought it might be an issue with
his setup, but now that you've ran into it as well I'll file a bug and try to
reproduce. Can you send me your rfnoc_ce_auto_inst_x310.v file?
Jonathon
On Wed, Sep 28, 2016 at 4:14 PM, Long, Jeffrey P. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
I just did a new build in the latest rfnoc-devel branch using the make.py and
adding in a couple stock ce?s (null sink and siggen). The build completed but I
just tried to burn it to my x310 and it told me the image was too large
15878034 vs 15878032
I saw reference to this issue last March but I thought it would have been fixed
by now.
Did I do something wrong here?
Thanks
Jeff
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/264907bf/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 30 Sep 2016 15:07:12 -0500
From: Jonathon Pendlum <[email protected]>
To: "Long, Jeffrey P." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<CAGdo0uRTGySpHx3Yx=gxnyskfowhsfyokq8hqeywuqq_mxq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
The make target X310_HG will use rfnoc_ce_default_inst_x310.v and
X310_HG_RFNOC will use rfnoc_ce_auto_inst_x310.v. On the master / maint
branch, the image we release is using rfnoc_ce_default_inst_x310.v, on the
rfnoc-devel branch it uses rfnoc_ce_auto_inst_x310.v.
On Fri, Sep 30, 2016 at 2:52 PM, Long, Jeffrey P. <[email protected]> wrote:
> Jonathon-
>
>
>
> I just noticed something strange and maybe you can explain this so I
> understand how it is supposed to build.
>
> There appear to be two rfnoc_ce_XXXX_inst_x310.v files. There is a default
> one and an auto one. There is an `ifdef to bring in one or the other in
> x300_core.v.
>
> The auto one has all the example blocks in it and the default one has only
> the DDC,DUC etc.. It seems that if RFNOC is defined you are going to bring
> in the auto one and all the example ce.
>
> I noticed that when I run image downloader and pull down the default
> images, burn it and usrpprobe it that it is in fact the default image with
> only the DDC,DUC etc..
>
>
>
> So when I build a new image by doing make X310_RFNOC_HG am I doing the
> auto file? In which case this is not what is being built by you guys and
> pushed to us during an image download? Are the non RFNOC targets the way to
> build the default images?
>
>
>
> Thanks
>
> Jeff
>
>
>
>
>
> *From:* Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Friday, September 30, 2016 11:37 AM
> *To:* Long, Jeffrey P.
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] RFNOC x310 image 2 bytes too large
>
>
>
> Hi Jeff,
>
>
>
> Another customer has reported this issue. I thought it might be an issue
> with his setup, but now that you've ran into it as well I'll file a bug and
> try to reproduce. Can you send me your rfnoc_ce_auto_inst_x310.v file?
>
>
>
>
>
>
>
> Jonathon
>
>
>
> On Wed, Sep 28, 2016 at 4:14 PM, Long, Jeffrey P. via USRP-users <
> [email protected]> wrote:
>
> I just did a new build in the latest rfnoc-devel branch using the make.py
> and adding in a couple stock ce?s (null sink and siggen). The build
> completed but I just tried to burn it to my x310 and it told me the image
> was too large 15878034 vs 15878032
>
>
>
> I saw reference to this issue last March but I thought it would have been
> fixed by now.
>
>
>
> Did I do something wrong here?
>
>
>
> Thanks
>
> Jeff
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/0b0dd54f/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 30 Sep 2016 20:24:24 +0000
From: "Long, Jeffrey P." <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<cy4pr09mb136768498ca2224b9ca8984ed9...@cy4pr09mb1367.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
OK so just to clarify, if I have rfnoc-devel(not maint or master) checked out
when I do the imagedownloader what am I getting default or auto?
My recent test seemed to me that I got the default image and not the rfnoc even
though I had checked out rfnoc-devel.
Thanks
Jeff
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Friday, September 30, 2016 4:07 PM
To: Long, Jeffrey P.
Cc: [email protected]
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
The make target X310_HG will use rfnoc_ce_default_inst_x310.v and X310_HG_RFNOC
will use rfnoc_ce_auto_inst_x310.v. On the master / maint branch, the image we
release is using rfnoc_ce_default_inst_x310.v, on the rfnoc-devel branch it
uses rfnoc_ce_auto_inst_x310.v.
On Fri, Sep 30, 2016 at 2:52 PM, Long, Jeffrey P.
<[email protected]<mailto:[email protected]>> wrote:
Jonathon-
I just noticed something strange and maybe you can explain this so I understand
how it is supposed to build.
There appear to be two rfnoc_ce_XXXX_inst_x310.v files. There is a default one
and an auto one. There is an `ifdef to bring in one or the other in x300_core.v.
The auto one has all the example blocks in it and the default one has only the
DDC,DUC etc.. It seems that if RFNOC is defined you are going to bring in the
auto one and all the example ce.
I noticed that when I run image downloader and pull down the default images,
burn it and usrpprobe it that it is in fact the default image with only the
DDC,DUC etc..
So when I build a new image by doing make X310_RFNOC_HG am I doing the auto
file? In which case this is not what is being built by you guys and pushed to
us during an image download? Are the non RFNOC targets the way to build the
default images?
Thanks
Jeff
From: Jonathon Pendlum
[mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, September 30, 2016 11:37 AM
To: Long, Jeffrey P.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Hi Jeff,
Another customer has reported this issue. I thought it might be an issue with
his setup, but now that you've ran into it as well I'll file a bug and try to
reproduce. Can you send me your rfnoc_ce_auto_inst_x310.v file?
Jonathon
On Wed, Sep 28, 2016 at 4:14 PM, Long, Jeffrey P. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
I just did a new build in the latest rfnoc-devel branch using the make.py and
adding in a couple stock ce?s (null sink and siggen). The build completed but I
just tried to burn it to my x310 and it told me the image was too large
15878034 vs 15878032
I saw reference to this issue last March but I thought it would have been fixed
by now.
Did I do something wrong here?
Thanks
Jeff
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/81ec3a7d/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 30 Sep 2016 15:38:42 -0500
From: Jonathon Pendlum <[email protected]>
To: "Long, Jeffrey P." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC x310 image 2 bytes too large
Message-ID:
<CAGdo0uT93tk38n2YZQRKSVMTvDfEHGu7mYsJyWbjbZ=gzst...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Right now you are getting the default image, but that isn't the normal
situation. We are in process of updating the rfnoc-devel image package and
that should be out sometime early next week.
On Fri, Sep 30, 2016 at 3:24 PM, Long, Jeffrey P. <[email protected]> wrote:
> OK so just to clarify, if I have rfnoc-devel(not maint or master) checked
> out when I do the imagedownloader what am I getting default or auto?
>
> My recent test seemed to me that I got the default image and not the rfnoc
> even though I had checked out rfnoc-devel.
>
>
>
> Thanks
>
> Jeff
>
>
>
> *From:* Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Friday, September 30, 2016 4:07 PM
>
> *To:* Long, Jeffrey P.
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] RFNOC x310 image 2 bytes too large
>
>
>
> The make target X310_HG will use rfnoc_ce_default_inst_x310.v and
> X310_HG_RFNOC will use rfnoc_ce_auto_inst_x310.v. On the master / maint
> branch, the image we release is using rfnoc_ce_default_inst_x310.v, on
> the rfnoc-devel branch it uses rfnoc_ce_auto_inst_x310.v.
>
>
>
> On Fri, Sep 30, 2016 at 2:52 PM, Long, Jeffrey P. <[email protected]>
> wrote:
>
> Jonathon-
>
>
>
> I just noticed something strange and maybe you can explain this so I
> understand how it is supposed to build.
>
> There appear to be two rfnoc_ce_XXXX_inst_x310.v files. There is a default
> one and an auto one. There is an `ifdef to bring in one or the other in
> x300_core.v.
>
> The auto one has all the example blocks in it and the default one has only
> the DDC,DUC etc.. It seems that if RFNOC is defined you are going to bring
> in the auto one and all the example ce.
>
> I noticed that when I run image downloader and pull down the default
> images, burn it and usrpprobe it that it is in fact the default image with
> only the DDC,DUC etc..
>
>
>
> So when I build a new image by doing make X310_RFNOC_HG am I doing the
> auto file? In which case this is not what is being built by you guys and
> pushed to us during an image download? Are the non RFNOC targets the way to
> build the default images?
>
>
>
> Thanks
>
> Jeff
>
>
>
>
>
> *From:* Jonathon Pendlum [mailto:[email protected]]
> *Sent:* Friday, September 30, 2016 11:37 AM
> *To:* Long, Jeffrey P.
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] RFNOC x310 image 2 bytes too large
>
>
>
> Hi Jeff,
>
>
>
> Another customer has reported this issue. I thought it might be an issue
> with his setup, but now that you've ran into it as well I'll file a bug and
> try to reproduce. Can you send me your rfnoc_ce_auto_inst_x310.v file?
>
>
>
>
>
>
>
> Jonathon
>
>
>
> On Wed, Sep 28, 2016 at 4:14 PM, Long, Jeffrey P. via USRP-users <
> [email protected]> wrote:
>
> I just did a new build in the latest rfnoc-devel branch using the make.py
> and adding in a couple stock ce?s (null sink and siggen). The build
> completed but I just tried to burn it to my x310 and it told me the image
> was too large 15878034 vs 15878032
>
>
>
> I saw reference to this issue last March but I thought it would have been
> fixed by now.
>
>
>
> Did I do something wrong here?
>
>
>
> Thanks
>
> Jeff
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/0f1dbf53/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 30 Sep 2016 13:52:49 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Error Using X310 ( NI USRP 2940 R)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Francesco,
can you do:
export UHD_LOG_LEVEL=1
uhd_usrp_probe
and share the generated /tmp/uhd.log?
Also, how did you get the FPGA image?
Best regards,
Marcus
On 09/30/2016 07:24 AM, Francesco Giannone via USRP-users wrote:
> Hi All,
>
> I?m quite new of this field. I started to use USRP because I?m working
> with a 5G network simulator/emulator.
>
> I have a NI USRP 2940 R in which I installed the Ettus X310 firmware.
> When I run the code I get this error:
>
> /
> /
> /UHD Warning:/
> / Unable to set the thread priority. Performance may be
> negatively affected./
> / Please see the general application notes in the manual for
> instructions./
> / EnvironmentError: OSError: error in pthread_setschedparam/
> /Checking for USRPs : UHD 003.010.000.000-release (3.10.0)/
> /Found USRP X300/
> /-- X300 initialization sequence.../
> /-- Determining maximum frame size... 1472 bytes./
> /-- Setup basic communication.../
> /-- Loading values from EEPROM.../
> /-- Setup RF frontend clocking.../
> /-- Radio 1x clock:184.32/
> /terminate called after throwing an instance of
> 'uhd::assertion_error'/
> / what(): AssertionError: block_def/
> / in void uhd::usrp::device3_impl::enumerate_rfnoc_blocks(size_t,
> size_t, size_t, const uhd::sid_t&, uhd::device_addr_t,
> uhd::endianness_t)/
> / at
> /build/uhd-SfT4TV/uhd-3.10.0.0/host/lib/usrp/device3/device3_impl.cpp:148/
> /
> /
> /Aborted (core dumped)/
> /
> /
>
> Any ideas?
>
> Thanks a lot in advance!!
>
> Best Regards.
>
> Francesco.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/e947c653/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 30 Sep 2016 17:31:15 -0400
From: Rob Kossler <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<CAB__hTRKVFB71gx7vFs0mJKSXGG8awh=huj84rw-kjhn9jv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am trying to see how much output power I can get from my X310/UBX-160.
Measuring on a spectrum analyzer (Agilent EXA), I am getting much lower
levels than I expected after reviewing the UBX performance data on the
Ettus website. In particular, I am only presently concerned with two
center frequencies: 2440 & 5800 MHz.
>From the UBX performance data (page 263), I expect in the ballpark of 20
dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am seeing 8.4
dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12 dB
lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than expected.
My signal is a linear FM chirp with constant amplitude at 0.9 full scale so
that could account for 1 dB of loss. I'm wondering if it is perhaps not
possible to achieve the UBX output powers shown in the document when the
UBX is installed in an X310. Was the performance data measured with the UBX
in an X310 or stand-alone?
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/8808bc59/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 30 Sep 2016 14:44:12 -0700
From: Matt Ettus <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<CAN=1kn8Sc+CyLU3v-Ykq8i03hQ64GN4ygxR=ncpyyn5iqcr...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
What did you set tx gain to?
On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> Hi,
> I am trying to see how much output power I can get from my X310/UBX-160.
> Measuring on a spectrum analyzer (Agilent EXA), I am getting much lower
> levels than I expected after reviewing the UBX performance data on the
> Ettus website. In particular, I am only presently concerned with two
> center frequencies: 2440 & 5800 MHz.
>
> From the UBX performance data (page 263), I expect in the ballpark of 20
> dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am seeing 8.4
> dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12 dB
> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than expected.
>
> My signal is a linear FM chirp with constant amplitude at 0.9 full scale
> so that could account for 1 dB of loss. I'm wondering if it is perhaps not
> possible to achieve the UBX output powers shown in the document when the
> UBX is installed in an X310. Was the performance data measured with the UBX
> in an X310 or stand-alone?
>
> Rob
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/ffd6b0b7/attachment-0001.html>
------------------------------
Message: 17
Date: Fri, 30 Sep 2016 17:47:31 -0400
From: Rob Kossler <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<cab__htq5agfpgc6g22ztqax8yunajy5tyazjmzqcttqdvux...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
31.5
On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <[email protected]> wrote:
>
> What did you set tx gain to?
>
> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>> I am trying to see how much output power I can get from my X310/UBX-160.
>> Measuring on a spectrum analyzer (Agilent EXA), I am getting much lower
>> levels than I expected after reviewing the UBX performance data on the
>> Ettus website. In particular, I am only presently concerned with two
>> center frequencies: 2440 & 5800 MHz.
>>
>> From the UBX performance data (page 263), I expect in the ballpark of 20
>> dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am seeing 8.4
>> dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12 dB
>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than expected.
>>
>> My signal is a linear FM chirp with constant amplitude at 0.9 full scale
>> so that could account for 1 dB of loss. I'm wondering if it is perhaps not
>> possible to achieve the UBX output powers shown in the document when the
>> UBX is installed in an X310. Was the performance data measured with the UBX
>> in an X310 or stand-alone?
>>
>> Rob
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/70299463/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 30 Sep 2016 14:48:58 -0700
From: Matt Ettus <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<CAN=1kn8UpxRcA21du7zMXkLT-+2PAfVd9zKmqsCcH=g+6ob...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You should be getting much more power out. But are you sure you are
measuring correctly? Are you looking at a power meter or a spectrum
analyzer?
On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler <[email protected]> wrote:
> 31.5
>
> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <[email protected]> wrote:
>
>>
>> What did you set tx gain to?
>>
>> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
>> [email protected]> wrote:
>>
>>> Hi,
>>> I am trying to see how much output power I can get from my
>>> X310/UBX-160. Measuring on a spectrum analyzer (Agilent EXA), I am getting
>>> much lower levels than I expected after reviewing the UBX performance data
>>> on the Ettus website. In particular, I am only presently concerned with
>>> two center frequencies: 2440 & 5800 MHz.
>>>
>>> From the UBX performance data (page 263), I expect in the ballpark of 20
>>> dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am seeing 8.4
>>> dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12 dB
>>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than expected.
>>>
>>> My signal is a linear FM chirp with constant amplitude at 0.9 full scale
>>> so that could account for 1 dB of loss. I'm wondering if it is perhaps not
>>> possible to achieve the UBX output powers shown in the document when the
>>> UBX is installed in an X310. Was the performance data measured with the UBX
>>> in an X310 or stand-alone?
>>>
>>> Rob
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/2bb549da/attachment-0001.html>
------------------------------
Message: 19
Date: Fri, 30 Sep 2016 17:51:17 -0400
From: Rob Kossler <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<cab__htrpbfhcrbwntwh0p4nghgcs6vizg3z3py4esznaa_g...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Spectrum analyzer (Agilent EXA). They are reasonably good power meters -
their spec for overall amplitude accuracy is +/- 0.3 dB.
On Fri, Sep 30, 2016 at 5:48 PM, Matt Ettus <[email protected]> wrote:
>
> You should be getting much more power out. But are you sure you are
> measuring correctly? Are you looking at a power meter or a spectrum
> analyzer?
>
>
> On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler <[email protected]> wrote:
>
>> 31.5
>>
>> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> What did you set tx gain to?
>>>
>>> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi,
>>>> I am trying to see how much output power I can get from my
>>>> X310/UBX-160. Measuring on a spectrum analyzer (Agilent EXA), I am getting
>>>> much lower levels than I expected after reviewing the UBX performance data
>>>> on the Ettus website. In particular, I am only presently concerned with
>>>> two center frequencies: 2440 & 5800 MHz.
>>>>
>>>> From the UBX performance data (page 263), I expect in the ballpark of
>>>> 20 dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am seeing
>>>> 8.4 dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12 dB
>>>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than
>>>> expected.
>>>>
>>>> My signal is a linear FM chirp with constant amplitude at 0.9 full
>>>> scale so that could account for 1 dB of loss. I'm wondering if it is
>>>> perhaps not possible to achieve the UBX output powers shown in the document
>>>> when the UBX is installed in an X310. Was the performance data measured
>>>> with the UBX in an X310 or stand-alone?
>>>>
>>>> Rob
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/1031ed20/attachment-0001.html>
------------------------------
Message: 20
Date: Fri, 30 Sep 2016 14:53:01 -0700
From: Matt Ettus <[email protected]>
To: Rob Kossler <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<CAN=1kn8oLU2Ek=bqbqt3j4iwmdnjbucjq0s0unwj5dwy11n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes, but if your signal is sweeping, then you can't just read the output
power level, as the power is spread over a wider frequency range. Turn off
the sweep and look at the power if you haven't already done that.
Matt
On Fri, Sep 30, 2016 at 2:51 PM, Rob Kossler <[email protected]> wrote:
> Spectrum analyzer (Agilent EXA). They are reasonably good power meters -
> their spec for overall amplitude accuracy is +/- 0.3 dB.
>
>
> On Fri, Sep 30, 2016 at 5:48 PM, Matt Ettus <[email protected]> wrote:
>
>>
>> You should be getting much more power out. But are you sure you are
>> measuring correctly? Are you looking at a power meter or a spectrum
>> analyzer?
>>
>>
>> On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler <[email protected]> wrote:
>>
>>> 31.5
>>>
>>> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <[email protected]> wrote:
>>>
>>>>
>>>> What did you set tx gain to?
>>>>
>>>> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi,
>>>>> I am trying to see how much output power I can get from my
>>>>> X310/UBX-160. Measuring on a spectrum analyzer (Agilent EXA), I am
>>>>> getting
>>>>> much lower levels than I expected after reviewing the UBX performance data
>>>>> on the Ettus website. In particular, I am only presently concerned with
>>>>> two center frequencies: 2440 & 5800 MHz.
>>>>>
>>>>> From the UBX performance data (page 263), I expect in the ballpark of
>>>>> 20 dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am seeing
>>>>> 8.4 dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12 dB
>>>>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than
>>>>> expected.
>>>>>
>>>>> My signal is a linear FM chirp with constant amplitude at 0.9 full
>>>>> scale so that could account for 1 dB of loss. I'm wondering if it is
>>>>> perhaps not possible to achieve the UBX output powers shown in the
>>>>> document
>>>>> when the UBX is installed in an X310. Was the performance data measured
>>>>> with the UBX in an X310 or stand-alone?
>>>>>
>>>>> Rob
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/0e1eb680/attachment-0001.html>
------------------------------
Message: 21
Date: Fri, 30 Sep 2016 17:56:11 -0400
From: Rob Kossler <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<cab__htrno8nat18yja6t38zz5w_m1qyfhufvojwljkcuqzs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I will change my sample rate to something small so that the chirp is over a
very narrow band and then turn off the spectrum analyzer sweeping as you
suggest. But, I'm pretty confident because I was measuring the power using
a marker function which integrates all power within a specified band. With
the very fast chirp compared to the very slow spectrum analyzer sweep, the
measurement should be ok.
Rob
On Fri, Sep 30, 2016 at 5:53 PM, Matt Ettus <[email protected]> wrote:
>
> Yes, but if your signal is sweeping, then you can't just read the output
> power level, as the power is spread over a wider frequency range. Turn off
> the sweep and look at the power if you haven't already done that.
>
> Matt
>
> On Fri, Sep 30, 2016 at 2:51 PM, Rob Kossler <[email protected]> wrote:
>
>> Spectrum analyzer (Agilent EXA). They are reasonably good power meters -
>> their spec for overall amplitude accuracy is +/- 0.3 dB.
>>
>>
>> On Fri, Sep 30, 2016 at 5:48 PM, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> You should be getting much more power out. But are you sure you are
>>> measuring correctly? Are you looking at a power meter or a spectrum
>>> analyzer?
>>>
>>>
>>> On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler <[email protected]> wrote:
>>>
>>>> 31.5
>>>>
>>>> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <[email protected]> wrote:
>>>>
>>>>>
>>>>> What did you set tx gain to?
>>>>>
>>>>> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi,
>>>>>> I am trying to see how much output power I can get from my
>>>>>> X310/UBX-160. Measuring on a spectrum analyzer (Agilent EXA), I am
>>>>>> getting
>>>>>> much lower levels than I expected after reviewing the UBX performance
>>>>>> data
>>>>>> on the Ettus website. In particular, I am only presently concerned with
>>>>>> two center frequencies: 2440 & 5800 MHz.
>>>>>>
>>>>>> From the UBX performance data (page 263), I expect in the ballpark of
>>>>>> 20 dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am seeing
>>>>>> 8.4 dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12
>>>>>> dB
>>>>>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than
>>>>>> expected.
>>>>>>
>>>>>> My signal is a linear FM chirp with constant amplitude at 0.9 full
>>>>>> scale so that could account for 1 dB of loss. I'm wondering if it is
>>>>>> perhaps not possible to achieve the UBX output powers shown in the
>>>>>> document
>>>>>> when the UBX is installed in an X310. Was the performance data measured
>>>>>> with the UBX in an X310 or stand-alone?
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/28e5f23f/attachment-0001.html>
------------------------------
Message: 22
Date: Fri, 30 Sep 2016 15:09:18 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Rob, and also: Dear future mailing list reader!
I typically go through the following checklist:
* measurement device input impedance set to 50 Ohm
* bandwidth of SA filter >> signal bw
* first test typically constant single-tone, small sweep step ->
verify filter shape visible
* two tone test next
* pseudo-white bw next
Best regards,
Marcus
On 09/30/2016 02:56 PM, Rob Kossler via USRP-users wrote:
> I will change my sample rate to something small so that the chirp is
> over a very narrow band and then turn off the spectrum analyzer
> sweeping as you suggest. But, I'm pretty confident because I was
> measuring the power using a marker function which integrates all power
> within a specified band. With the very fast chirp compared to the
> very slow spectrum analyzer sweep, the measurement should be ok.
>
> Rob
>
> On Fri, Sep 30, 2016 at 5:53 PM, Matt Ettus <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> Yes, but if your signal is sweeping, then you can't just read the
> output power level, as the power is spread over a wider frequency
> range. Turn off the sweep and look at the power if you haven't
> already done that.
>
> Matt
>
> On Fri, Sep 30, 2016 at 2:51 PM, Rob Kossler <[email protected]
> <mailto:[email protected]>> wrote:
>
> Spectrum analyzer (Agilent EXA). They are reasonably good
> power meters - their spec for overall amplitude accuracy is
> +/- 0.3 dB.
>
>
> On Fri, Sep 30, 2016 at 5:48 PM, Matt Ettus <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> You should be getting much more power out. But are you
> sure you are measuring correctly? Are you looking at a
> power meter or a spectrum analyzer?
>
>
> On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler
> <[email protected] <mailto:[email protected]>> wrote:
>
> 31.5
>
> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus
> <[email protected] <mailto:[email protected]>> wrote:
>
>
> What did you set tx gain to?
>
> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via
> USRP-users <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi,
> I am trying to see how much output power I can
> get from my X310/UBX-160. Measuring on a
> spectrum analyzer (Agilent EXA), I am getting
> much lower levels than I expected after
> reviewing the UBX performance data on the
> Ettus website. In particular, I am only
> presently concerned with two center
> frequencies: 2440 & 5800 MHz.
>
> From the UBX performance data (page 263), I
> expect in the ballpark of 20 dBm @ 2440 MHz
> and 9 dBm @ 5800 MHz. In my measurements, I
> am seeing 8.4 dBm @ 2440 MHz and 1 dBm @ 5800
> MHz. Thus, @ 2440 MHz, it is 11-12 dB lower
> than expected. Similarly, @ 5800 MHz, it is 8
> dB lower than expected.
>
> My signal is a linear FM chirp with constant
> amplitude at 0.9 full scale so that could
> account for 1 dB of loss. I'm wondering if it
> is perhaps not possible to achieve the UBX
> output powers shown in the document when the
> UBX is installed in an X310. Was the
> performance data measured with the UBX in an
> X310 or stand-alone?
>
> Rob
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> <mailto:[email protected]>
>
> 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
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/388709b8/attachment-0001.html>
------------------------------
Message: 23
Date: Fri, 30 Sep 2016 18:14:04 -0400
From: Rob Kossler <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<CAB__hTTjxjBgo4inuuA421h__+UR3Y+Kvd=w3t+42toxkk3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
ok. With 1 MHz chirp and spectrum analyzer in zero-span with 8 MHz RBW, I
see a bit more power - about 1 dB more than previously reported. Still
less than expecting though.
I can test with single tone, two tone, or noise. I'm wondering how Ettus
tested to create the performance data. Was this in a USRP or stand-alone?
If the latter, is there any data when testing in an X310?
Rob
On Fri, Sep 30, 2016 at 6:09 PM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi Rob, and also: Dear future mailing list reader!
>
> I typically go through the following checklist:
>
> * measurement device input impedance set to 50 Ohm
> * bandwidth of SA filter >> signal bw
> * first test typically constant single-tone, small sweep step -> verify
> filter shape visible
> * two tone test next
> * pseudo-white bw next
>
> Best regards,
>
> Marcus
>
> On 09/30/2016 02:56 PM, Rob Kossler via USRP-users wrote:
>
> I will change my sample rate to something small so that the chirp is over
> a very narrow band and then turn off the spectrum analyzer sweeping as you
> suggest. But, I'm pretty confident because I was measuring the power using
> a marker function which integrates all power within a specified band. With
> the very fast chirp compared to the very slow spectrum analyzer sweep, the
> measurement should be ok.
>
> Rob
>
> On Fri, Sep 30, 2016 at 5:53 PM, Matt Ettus <[email protected]> wrote:
>
>>
>> Yes, but if your signal is sweeping, then you can't just read the output
>> power level, as the power is spread over a wider frequency range. Turn off
>> the sweep and look at the power if you haven't already done that.
>>
>> Matt
>>
>> On Fri, Sep 30, 2016 at 2:51 PM, Rob Kossler <[email protected]> wrote:
>>
>>> Spectrum analyzer (Agilent EXA). They are reasonably good power meters
>>> - their spec for overall amplitude accuracy is +/- 0.3 dB.
>>>
>>>
>>> On Fri, Sep 30, 2016 at 5:48 PM, Matt Ettus <[email protected]> wrote:
>>>
>>>>
>>>> You should be getting much more power out. But are you sure you are
>>>> measuring correctly? Are you looking at a power meter or a spectrum
>>>> analyzer?
>>>>
>>>>
>>>> On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler <[email protected]> wrote:
>>>>
>>>>> 31.5
>>>>>
>>>>> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>> What did you set tx gain to?
>>>>>>
>>>>>> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I am trying to see how much output power I can get from my
>>>>>>> X310/UBX-160. Measuring on a spectrum analyzer (Agilent EXA), I am
>>>>>>> getting
>>>>>>> much lower levels than I expected after reviewing the UBX performance
>>>>>>> data
>>>>>>> on the Ettus website. In particular, I am only presently concerned with
>>>>>>> two center frequencies: 2440 & 5800 MHz.
>>>>>>>
>>>>>>> From the UBX performance data (page 263), I expect in the ballpark
>>>>>>> of 20 dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am
>>>>>>> seeing
>>>>>>> 8.4 dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is 11-12
>>>>>>> dB
>>>>>>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than
>>>>>>> expected.
>>>>>>>
>>>>>>> My signal is a linear FM chirp with constant amplitude at 0.9 full
>>>>>>> scale so that could account for 1 dB of loss. I'm wondering if it is
>>>>>>> perhaps not possible to achieve the UBX output powers shown in the
>>>>>>> document
>>>>>>> when the UBX is installed in an X310. Was the performance data measured
>>>>>>> with the UBX in an X310 or stand-alone?
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/d1ace4f3/attachment-0001.html>
------------------------------
Message: 24
Date: Fri, 30 Sep 2016 15:18:35 -0700
From: Matt Ettus <[email protected]>
To: Rob Kossler <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310/UBX-160 Tx output power
Message-ID:
<CAN=1kn-hbwxnv9mkfpwsxsfoblk8twppe+5mtn5wn7zrwaq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Measurements are taken in X310. Try with a single tone.
Matt
On Fri, Sep 30, 2016 at 3:14 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> ok. With 1 MHz chirp and spectrum analyzer in zero-span with 8 MHz RBW, I
> see a bit more power - about 1 dB more than previously reported. Still
> less than expecting though.
>
> I can test with single tone, two tone, or noise. I'm wondering how Ettus
> tested to create the performance data. Was this in a USRP or stand-alone?
> If the latter, is there any data when testing in an X310?
>
> Rob
>
> On Fri, Sep 30, 2016 at 6:09 PM, Marcus M?ller via USRP-users <
> [email protected]> wrote:
>
>> Hi Rob, and also: Dear future mailing list reader!
>>
>> I typically go through the following checklist:
>>
>> * measurement device input impedance set to 50 Ohm
>> * bandwidth of SA filter >> signal bw
>> * first test typically constant single-tone, small sweep step -> verify
>> filter shape visible
>> * two tone test next
>> * pseudo-white bw next
>>
>> Best regards,
>>
>> Marcus
>>
>> On 09/30/2016 02:56 PM, Rob Kossler via USRP-users wrote:
>>
>> I will change my sample rate to something small so that the chirp is over
>> a very narrow band and then turn off the spectrum analyzer sweeping as you
>> suggest. But, I'm pretty confident because I was measuring the power using
>> a marker function which integrates all power within a specified band. With
>> the very fast chirp compared to the very slow spectrum analyzer sweep, the
>> measurement should be ok.
>>
>> Rob
>>
>> On Fri, Sep 30, 2016 at 5:53 PM, Matt Ettus <[email protected]> wrote:
>>
>>>
>>> Yes, but if your signal is sweeping, then you can't just read the output
>>> power level, as the power is spread over a wider frequency range. Turn off
>>> the sweep and look at the power if you haven't already done that.
>>>
>>> Matt
>>>
>>> On Fri, Sep 30, 2016 at 2:51 PM, Rob Kossler <[email protected]> wrote:
>>>
>>>> Spectrum analyzer (Agilent EXA). They are reasonably good power meters
>>>> - their spec for overall amplitude accuracy is +/- 0.3 dB.
>>>>
>>>>
>>>> On Fri, Sep 30, 2016 at 5:48 PM, Matt Ettus <[email protected]> wrote:
>>>>
>>>>>
>>>>> You should be getting much more power out. But are you sure you are
>>>>> measuring correctly? Are you looking at a power meter or a spectrum
>>>>> analyzer?
>>>>>
>>>>>
>>>>> On Fri, Sep 30, 2016 at 2:47 PM, Rob Kossler <[email protected]> wrote:
>>>>>
>>>>>> 31.5
>>>>>>
>>>>>> On Fri, Sep 30, 2016 at 5:44 PM, Matt Ettus <[email protected]> wrote:
>>>>>>
>>>>>>>
>>>>>>> What did you set tx gain to?
>>>>>>>
>>>>>>> On Fri, Sep 30, 2016 at 2:31 PM, Rob Kossler via USRP-users <
>>>>>>> [email protected]> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> I am trying to see how much output power I can get from my
>>>>>>>> X310/UBX-160. Measuring on a spectrum analyzer (Agilent EXA), I am
>>>>>>>> getting
>>>>>>>> much lower levels than I expected after reviewing the UBX performance
>>>>>>>> data
>>>>>>>> on the Ettus website. In particular, I am only presently concerned
>>>>>>>> with
>>>>>>>> two center frequencies: 2440 & 5800 MHz.
>>>>>>>>
>>>>>>>> From the UBX performance data (page 263), I expect in the ballpark
>>>>>>>> of 20 dBm @ 2440 MHz and 9 dBm @ 5800 MHz. In my measurements, I am
>>>>>>>> seeing
>>>>>>>> 8.4 dBm @ 2440 MHz and 1 dBm @ 5800 MHz. Thus, @ 2440 MHz, it is
>>>>>>>> 11-12 dB
>>>>>>>> lower than expected. Similarly, @ 5800 MHz, it is 8 dB lower than
>>>>>>>> expected.
>>>>>>>>
>>>>>>>> My signal is a linear FM chirp with constant amplitude at 0.9 full
>>>>>>>> scale so that could account for 1 dB of loss. I'm wondering if it is
>>>>>>>> perhaps not possible to achieve the UBX output powers shown in the
>>>>>>>> document
>>>>>>>> when the UBX is installed in an X310. Was the performance data measured
>>>>>>>> with the UBX in an X310 or stand-alone?
>>>>>>>>
>>>>>>>> Rob
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> USRP-users mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/11d6ec66/attachment-0001.html>
------------------------------
Message: 25
Date: Fri, 30 Sep 2016 19:37:17 -0400
From: Sam Carey <[email protected]>
To: [email protected]
Subject: [USRP-users] TX/RX Fixed Signal Phase Synchronization
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Howdy,
I?ve been trying to solve a problem and thought of a new approach for which I?d
like some feedback.
I have an X310 with two UBX daughterboards. The TX of daughterboard A is
connected via coaxial cable to the RX of daughterboard B.
I need to send a tone from A to B, and measure the phase offset accumulated
during the transit (via a conjugate multiply).
The measurement result needs to be consistent and repeatable across power
cycles and under/overflows.
So far, I?ve been told that aligning the TX and RX channels of a GR flow graph
is difficult because of the GR scheduler, OS buffers, and other somewhat random
factors. In my own experiments, the phase offset will always ?jump? randomly if
there is an under/overflow or power cycle. I can see that there?s no clear way
to keep TX and RX packets aligned in an absolute sense.
So my idea is to generate a fixed signal that makes an integer number of cycles
per packet, and use the beginning of the packet as the reference for alignment.
This way, if a packet gets dropped or something, it?s okay because the next
packet carries the same information (exactly for the TX packets, approximately
for the RX packets).
I imagine this would require that:
1) The packets created on the host always contain exactly the same vector of
samples.
2) The packets are never altered or recombined as they pass between the host
and the radio front-ends.
3) The TX and RX radios always start transmitting or generating a packet at the
same time or at a consistent sample-offset. I cannot have a situation where the
two radios are working on samples ?p? and ?k" of their respective packets, and
then later they?re working on samples ?p? and ?q != k?.
Can anyone tell me whether the above is feasible?
Thank you,
Sam Carey
------------------------------
Message: 26
Date: Fri, 30 Sep 2016 20:04:31 -0700
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TX/RX Fixed Signal Phase Synchronization
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Sam!
Nice hearing from you again :)
> The TX of daughterboard A is connected via coaxial cable to the RX of
> daughterboard B.
Well, the usual "please don't fry the RX LNA, use an attenuator" applies :)
> So far, I?ve been told that aligning the TX and RX channels of a GR flow
> graph is difficult because of the GR scheduler, OS buffers, and other
> somewhat random factors.
Ha, yes. GR is a very buffer-driven architecture, designed to maximize
throughput, not minimize latency or latency variance.
> In my own experiments, the phase offset will always ?jump? randomly if there
> is an under/overflow or power cycle.
Overflows will mean you lost an unknown number of samples, so yes, that
feels true.
Anyway, if you get under or overruns, your application is basically
broken. We should cooperate on fixing that, first! It shouldn't happen.
Usually, it means you're tasking your PC with too much processing and it
can't keep up, but there might be more to it and things that can be done
to avoid it.
> I can see that there?s no clear way to keep TX and RX packets aligned in an
> absolute sense.
That's not 100% true ? in fact, with the X310, you get a motherboard
that has its own notion of time, so you can do things with
hardware-exact timing, and with the UBXes, you get tuners that can
restore a phase at such a "timed command".
In essence, you'd go ahead and tell the USRP to tune both your RX and TX
at the same time. That way, UHD will make sure that the phase offset
between these LOs is constant (even after power cycle, if you tune to
the same frequency again, simultaneously, using timed commands.
Then, you get an RX stream, by issuing a stream command with a time spec
set ? and you do the same for the TX stream, where you set the time of
the first sample to be transmitted.
Doing so, you can have a deterministic RX-to-TX phase offset.
That's the theory behind doing phase-deterministic loopback.
However, I think what you're after is more in the terms of a real-world
modem, right? In that case, again, underruns or overruns must not
happen. You'll break your signal.
Best regards,
Marcus
On 09/30/2016 04:37 PM, Sam Carey via USRP-users wrote:
> Howdy,
>
> I?ve been trying to solve a problem and thought of a new approach for which
> I?d like some feedback.
>
> I have an X310 with two UBX daughterboards. The TX of daughterboard A is
> connected via coaxial cable to the RX of daughterboard B.
> I need to send a tone from A to B, and measure the phase offset accumulated
> during the transit (via a conjugate multiply).
> The measurement result needs to be consistent and repeatable across power
> cycles and under/overflows.
>
> So far, I?ve been told that aligning the TX and RX channels of a GR flow
> graph is difficult because of the GR scheduler, OS buffers, and other
> somewhat random factors. In my own experiments, the phase offset will always
> ?jump? randomly if there is an under/overflow or power cycle. I can see that
> there?s no clear way to keep TX and RX packets aligned in an absolute sense.
>
> So my idea is to generate a fixed signal that makes an integer number of
> cycles per packet, and use the beginning of the packet as the reference for
> alignment.
> This way, if a packet gets dropped or something, it?s okay because the next
> packet carries the same information (exactly for the TX packets,
> approximately for the RX packets).
> I imagine this would require that:
>
> 1) The packets created on the host always contain exactly the same vector of
> samples.
> 2) The packets are never altered or recombined as they pass between the host
> and the radio front-ends.
> 3) The TX and RX radios always start transmitting or generating a packet at
> the same time or at a consistent sample-offset. I cannot have a situation
> where the two radios are working on samples ?p? and ?k" of their respective
> packets, and then later they?re working on samples ?p? and ?q != k?.
>
> Can anyone tell me whether the above is feasible?
>
> Thank you,
> Sam Carey
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 27
Date: Fri, 30 Sep 2016 22:57:49 -0700
From: Dario Fertonani <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] API that clears recv buffer?
Message-ID:
<cajgedajga3ws2fvkmwgdkq4pfcd8ndt3gackad+4vvgq7vo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Is it possible to clear the recv buffer in the "some code" part of the
example below? I was assuming that stopping the rxStreamPtr stream and
starting a new one would clear the buffer, but the time stamps of the RX
meta data say otherwise.
Thanks,
Dario
{
uhd::stream_cmd_t rxStreamCmd(
uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS );
rxStreamCmd.stream_now = true;
rxStreamPtr->issue_stream_cmd( rxStreamCmd );
}
{
//some code
}
{
uhd::stream_cmd_t rxStreamCmd(
uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS );
rxStreamCmd.stream_now = false;
rxStreamCmd.time_spec = newStreamStartTime;
rxStreamPtr->issue_stream_cmd( rxStreamCmd );
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160930/b7b701f9/attachment-0001.html>
------------------------------
Message: 28
Date: Sat, 1 Oct 2016 13:40:42 +0530
From: ayush gupta <[email protected]>
To: [email protected]
Subject: [USRP-users] Fwd: Help In installing Yate BTS with B200
Message-ID:
<cagf-_vpcgk_is3jmyae_ng-jf-cv-_ngxtuvdacancqg-nv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello everyone
I want to use yatebts with USRP B200
Upto now I have successfully installed
YateBTS and USRP B200 UHD driver with correct FPGA image but since recent
update I am unable change "transceiver
Path value" to ./transceiver-uhd
As new configuration file doesn't have that option now (ybts.conf)
Can anyone help me how can I make USRP B200 work with yateBTS?!?
I am using Ubuntu 16.04 lts
Thanks In advance
Ayush Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/9fcaac00/attachment-0001.html>
------------------------------
Message: 29
Date: Sat, 1 Oct 2016 10:29:37 +0100
From: David Miller <[email protected]>
To: Paul David <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Thank-you for replying...
Using Vivado hardware manager, program FPGA with...
uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
From what I remember uhd_usrp_probe states the loaded version is now
003.009.004... and not 003.008.002
then do:
uhd_image_loader --args addr=192.168.10.2,type=x300 --fpga-path
uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
which returns the error.
Thanks,
Dave
On 30/09/2016 19:12, Paul David wrote:
> Also, could you provide the arguments you're supplying to
> uhd_image_loader?
>
> On Fri, Sep 30, 2016 at 11:10 AM, Paul David <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi David,
>
> Are you certain you're on the same version of UHD as the FPGA image?
>
> On Fri, Sep 30, 2016 at 3:42 AM, David Miller
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Hi Paul and usrp-users,
>
> So, I used Vivado hardware manager to program the FPGA with
> 3.9.4 bitfile (I'm stuck with 3.9.4 for the moment) and
> confirmed with uhd_usrp_probe that all appears OK.
> I did not power cycle the X310.
> But then trying to use uhd_image_loader with the 3.9.4 bitfile
> fails with the same "Error: RunTimeError: Device reported an
> error during initialization".
>
> Maybe I should re-program the 3.8.2 image back first?
>
> Any ideas?
>
> Thanks,
> Dave
>
>
> On 20/09/2016 19:07, Paul David wrote:
>> Hi David,
>>
>> To answer your question: you do need Vivado in order to
>> configure the FPGA over JTAG using the command:
>> viv_jtag_program <bitfile path> .
>>
>> Or you can use the hardware manager in Vivado. After you do
>> that, you'll need to use uhd_image_loader to burn the same
>> FPGA image so that it persists after a power cycle.
>>
>> I would recommend upgrading UHD to a more recent tagged
>> release as well.
>>
>> -- Paul
>>
>> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>> I have acquired an X310 with an image based on the
>> original uhd 3.8.2 image, not sure what it does but doing
>> a uhd_usrp_probe with uhd 3.8.2 it works as expected,
>> however no samples are emitted with the utilities, it's
>> hosed!
>>
>> Anyways, I have tried the 3.8.2 burn program
>> (usrp_x3xx_fpga_burner) which fails, and currently tried
>> the 3.9.4 uhd_image_loader.
>>
>> uhd_image_loader fails (and similarly
>> usrp_x3xx_fpga_burner) with:
>>
>> Error: RunTimeError: Device reported an error during
>> initialization.
>>
>> I hacked the code in the x310_send_and_receive()
>> function, somewhere in the code, to see if there is any
>> kind of status message generated that might help, the
>> recv function returns a len of 4 (0 being a timeout),
>> which fails a subsequent check function that masks this
>> len value (with 0x04, or whatever the def is) to
>> determine that this is a failure. Sorry to be a bit
>> vague, I don't have the setup in front of me at the moment.
>>
>> So, the real question is: How do I recover the unit and
>> burn back a working image, is it now only possible using
>> Vivado/ISE/JTAG?
>>
>> Hope you can help?
>>
>> Thanks,
>> Dave
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> <mailto:[email protected]>
>>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>
>
>
>
> --
> #/Paul David/
> # /Staff Software Design Engineer/
> #/Ettus Research - A National Instruments Company/
>
>
>
>
> --
> #/Paul David/
> # /Staff Software Design Engineer/
> #/Ettus Research - A National Instruments Company/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/8702b6ae/attachment-0001.html>
------------------------------
Message: 30
Date: Sat, 01 Oct 2016 08:47:09 -0700
From: Marcus M?ller <[email protected]>
To: ayush gupta <[email protected]>, ayush gupta via USRP-users
<[email protected]>, [email protected]
Subject: Re: [USRP-users] Fwd: Help In installing Yate BTS with B200
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Ayush,
Have you re-compiled/linked yatebts after updating UHD?
Best regards,
Marcus
Am 1. Oktober 2016 01:10:42 GMT-07:00, schrieb ayush gupta via USRP-users
<[email protected]>:
>Hello everyone
>
>I want to use yatebts with USRP B200
>Upto now I have successfully installed
>YateBTS and USRP B200 UHD driver with correct FPGA image but since
>recent
>update I am unable change "transceiver
>Path value" to ./transceiver-uhd
>
>As new configuration file doesn't have that option now (ybts.conf)
>Can anyone help me how can I make USRP B200 work with yateBTS?!?
>I am using Ubuntu 16.04 lts
>
>Thanks In advance
>Ayush Gupta
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>USRP-users mailing list
>[email protected]
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/b5c581cc/attachment-0001.html>
------------------------------
Message: 31
Date: Sat, 01 Oct 2016 08:51:27 -0700
From: Marcus M?ller <[email protected]>
To: David Miller <[email protected]>, David Miller via
USRP-users <[email protected]>, Paul David
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi David,
003.009.004 is the host-side UHD library version, not the version of the FPGA
image (these do have to be compatible, but FPGA versioning follows a different
scheme). Loading a different FPGA image onto the USRP can't change that string.
Since you're using images from a path that indicates you want to use UHD 3.9.4,
you must make sure that at runtime, no different version of UHD is accidentally
loaded.
Best regards
Marcus
Am 1. Oktober 2016 02:29:37 GMT-07:00, schrieb David Miller via USRP-users
<[email protected]>:
>Thank-you for replying...
>
>Using Vivado hardware manager, program FPGA with...
>uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
> From what I remember uhd_usrp_probe states the loaded version is now
>003.009.004... and not 003.008.002
>then do:
>uhd_image_loader --args addr=192.168.10.2,type=x300 --fpga-path
>uhd-images_003.009.004-release/share/uhd/images/usrp_x310_fpga_HGS.bit
>which returns the error.
>
>Thanks,
>Dave
>
>
>
>On 30/09/2016 19:12, Paul David wrote:
>> Also, could you provide the arguments you're supplying to
>> uhd_image_loader?
>>
>> On Fri, Sep 30, 2016 at 11:10 AM, Paul David <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi David,
>>
>> Are you certain you're on the same version of UHD as the FPGA
>image?
>>
>> On Fri, Sep 30, 2016 at 3:42 AM, David Miller
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> Hi Paul and usrp-users,
>>
>> So, I used Vivado hardware manager to program the FPGA with
>> 3.9.4 bitfile (I'm stuck with 3.9.4 for the moment) and
>> confirmed with uhd_usrp_probe that all appears OK.
>> I did not power cycle the X310.
>> But then trying to use uhd_image_loader with the 3.9.4
>bitfile
>> fails with the same "Error: RunTimeError: Device reported an
>> error during initialization".
>>
>> Maybe I should re-program the 3.8.2 image back first?
>>
>> Any ideas?
>>
>> Thanks,
>> Dave
>>
>>
>> On 20/09/2016 19:07, Paul David wrote:
>>> Hi David,
>>>
>>> To answer your question: you do need Vivado in order to
>>> configure the FPGA over JTAG using the command:
>>> viv_jtag_program <bitfile path> .
>>>
>>> Or you can use the hardware manager in Vivado. After you do
>>> that, you'll need to use uhd_image_loader to burn the same
>>> FPGA image so that it persists after a power cycle.
>>>
>>> I would recommend upgrading UHD to a more recent tagged
>>> release as well.
>>>
>>> -- Paul
>>>
>>> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users
>>> <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hi,
>>>
>>> I have acquired an X310 with an image based on the
>>> original uhd 3.8.2 image, not sure what it does but
>doing
>>> a uhd_usrp_probe with uhd 3.8.2 it works as expected,
>>> however no samples are emitted with the utilities, it's
>>> hosed!
>>>
>>> Anyways, I have tried the 3.8.2 burn program
>>> (usrp_x3xx_fpga_burner) which fails, and currently tried
>>> the 3.9.4 uhd_image_loader.
>>>
>>> uhd_image_loader fails (and similarly
>>> usrp_x3xx_fpga_burner) with:
>>>
>>> Error: RunTimeError: Device reported an error during
>>> initialization.
>>>
>>> I hacked the code in the x310_send_and_receive()
>>> function, somewhere in the code, to see if there is any
>>> kind of status message generated that might help, the
>>> recv function returns a len of 4 (0 being a timeout),
>>> which fails a subsequent check function that masks this
>>> len value (with 0x04, or whatever the def is) to
>>> determine that this is a failure. Sorry to be a bit
>>> vague, I don't have the setup in front of me at the
>moment.
>>>
>>> So, the real question is: How do I recover the unit and
>>> burn back a working image, is it now only possible using
>>> Vivado/ISE/JTAG?
>>>
>>> Hope you can help?
>>>
>>> Thanks,
>>> Dave
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> <mailto:[email protected]>
>>>
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
><http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>>
>>>
>>
>>
>>
>>
>> --
>> #/Paul David/
>> # /Staff Software Design Engineer/
>> #/Ettus Research - A National Instruments Company/
>>
>>
>>
>>
>> --
>> #/Paul David/
>> # /Staff Software Design Engineer/
>> #/Ettus Research - A National Instruments Company/
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>USRP-users mailing list
>[email protected]
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20161001/e01221bc/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 74, Issue 1
*****************************************
