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. No x310 XGS image for UHD 3.9.6? (Stephen Larew)
2. Re: RFNOC + GPIO (Michael West)
3. B205mini Frequency Accuracy (carry chen)
4. Re: B205mini Frequency Accuracy ([email protected])
5. problem with RFNoC settings register (Jason Matusiak)
6. Re: GRC + RFNoC + Radio Loopback (Nick Foster)
7. Re: problem with RFNoC settings register (Jason Matusiak)
8. Re: No x310 XGS image for UHD 3.9.6? (Nate Temple)
9. Re: No x310 XGS image for UHD 3.9.6? (Stephen Larew)
10. Re: rfnoc-modtool cores (EJ Kreinar)
11. About Self calibration (liu Jong)
12. B200mini GPIO input (Xingjian Chen)
13. Fw: B205mini Frequency Accuracy (carry chen)
14. Re: Trigger Signal ([email protected])
15. Shifting frequencies ([email protected])
16. Re: Fw: B205mini Frequency Accuracy (Marcus D. Leech)
17. Re: Fw: B205mini Frequency Accuracy (Jason Matusiak)
18. Re: GRC + RFNoC + Radio Loopback (Christophe ALEXANDRE)
19. Re: Fw: B205mini Frequency Accuracy ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Tue, 23 May 2017 14:21:05 -0400
From: Stephen Larew <[email protected]>
To: USRP-users <[email protected]>
Subject: [USRP-users] No x310 XGS image for UHD 3.9.6?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
I?m trying to use dual 10g ethernet on an x310. I?m using UHD 3.9.6. The
images downloaded by uhd_images_downloader do not appear to contain the XGS
(dual 10G) image. Am I missing something?
> $ ls ./current/share/uhd/images/
> 003.009.006.tag usrp_e110_fpga.bin
> bit usrp_e310_fpga.bit
> LICENSE usrp_e310_fpga_idle.bit
> octoclock_bootloader.hex usrp_e310_fpga_sg3.bit
> octoclock_r4_fw.hex usrp_e3xx_fpga_idle.bit
> usrp1_fpga_4rx.rbf usrp_e3xx_fpga_idle_sg3.bit
> usrp1_fpga.rbf usrp_n200_fw.bin
> usrp1_fw.ihx usrp_n200_r2_fpga.bin
> usrp2_fpga.bin usrp_n200_r3_fpga.bin
> usrp2_fw.bin usrp_n200_r4_fpga.bin
> usrp_b100_fpga_2rx.bin usrp_n210_fw.bin
> usrp_b100_fpga.bin usrp_n210_r2_fpga.bin
> usrp_b100_fw.ihx usrp_n210_r3_fpga.bin
> usrp_b200_fpga.bin usrp_n210_r4_fpga.bin
> usrp_b200_fw.hex usrp_x300_fpga_HGS.bit
> usrp_b200mini_fpga.bin usrp_x300_fpga_HGS.lvbitx
> usrp_b205mini_fpga.bin usrp_x310_fpga_HGS.bit
> usrp_b210_fpga.bin usrp_x310_fpga_HGS.lvbitx
> usrp_e100_fpga_v2.bin winusb_driver
-Stephen
------------------------------
Message: 2
Date: Tue, 23 May 2017 11:23:11 -0700
From: Michael West <[email protected]>
To: Christophe ALEXANDRE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC + GPIO
Message-ID:
<CAM4xKrq+CAJi1PyUZfofbpfgt=boeevo_dnbjeyorkifolw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Christophe,
There is no real deterministic way of figuring out the latency since it
takes time to send a packet from one block to another, but I would expect
it to be <10us since the packet is small and the bus clock is 167 MHz.
Unfortunately, there are no examples or documentation on how to do it yet.
You will have to spend some time reading the code and figuring it out.
The packet header format can be found here:
https://github.com/EttusResearch/fpga/blob/maint/usrp3/chdr.txt
Wiring the signals directly into the block is just basic FPGA design.
Disconnect the fp_gpio lines from the radio block and connect them to your
custom block.
Perhaps an easier approach is to use the ATR feature of the GPIO. You can
set up the GPIO to automatically switch values when it is idle,
transmitting, receiving, or in full duplex (transmitting and receiving).
You simply set desired values for each state.
Regards,
Michael
On Mon, May 22, 2017 at 11:38 PM, Christophe ALEXANDRE <
[email protected]> wrote:
> thank you for your quick answer.
>
> do you have any figure about the random latency ?
>
> is there any documentation/example somewhere about :
>
> 1) generating the appropriate control packet
>
> 2) rewiring the GPIO signals directly to the custom block
>
>
> regards.
>
>
> Christophe ALEXANDRE
>
>
> Le 23/05/2017 ? 03:06, Michael West a ?crit :
>
> Hi Christophe,
>
> Yes. The external GPIO is controlled by the radio block, so the custom
> RFNoC block would just have to generate the appropriate control packet to
> the radio and handle the ACK packet coming back. There will be some random
> amount of latency with that approach. If you need deterministic timing of
> the GPIO signals, you can supply a timestamp in the packet from your custom
> block, use timed commands from the host, or simply rewire the GPIO signals
> directly to the custom block.
>
> Regards,
> Michael
>
> On Mon, May 22, 2017 at 10:53 AM, Christophe ALEXANDRE via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>>
>> i'm using an X310. Is there any way to use
>> the external GPIOs inside an RFNOC block ?
>>
>> regards.
>>
>> Christophe ALEXANDRE
>>
>>
>>
>> _______________________________________________
>> 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/20170523/ee2303b1/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 23 May 2017 18:58:35 +0000
From: carry chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B205mini Frequency Accuracy
Message-ID:
<sixpr06mb09052d31cf8027e030400030dd...@sixpr06mb0905.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,list
I check the b205mini datasheet and see the frequency accuracy is ?2.0 ppm,
Can I change the clock to get better frequency accuracy?
Thank you very much!
Carry
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/be0d6f7e/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 23 May 2017 15:04:55 -0400
From: [email protected]
To: carry chen <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The usual way to do that is to use an external reference oscillator that
is better than the clock that is on-board.
For example a GPSDO, or an external 10MHz OCXO source, etc.
On 2017-05-23 14:58, carry chen via USRP-users wrote:
> Hi,list
>
> I check the b205mini datasheet and see the frequency accuracy is ?2.0 ppm,
>
> Can I change the clock to get better frequency accuracy?
>
> Thank you very much!
>
> Carry
> _______________________________________________
> 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/20170523/06692ef4/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 23 May 2017 15:05:53 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] problem with RFNoC settings register
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I attempted to add a new RFNoC block to my OOT project and I am having
problems setting the sample rate in my block. I mimiced what I did in
my previously working block, but this new one keeps erroring out. The
error looks like:
[ERROR] [RFNOC] [NocScript] Error while executing SR_WRITE(VECTOR_SIZE,
0x200):
LookupError: KeyError: Unknown settings register name: VECTOR_SIZE
Error: RuntimeError: [NocScript] Code returned false:
SR_WRITE("VECTOR_SIZE", $spp)
My freqShift,xml has:
<registers>
<setreg>
<name>VECTOR_SIZE</name>
<address>130</address>
</setreg>
</registers>
and
<arg>
<name>spp</name>
<type>int</type>
<value>512</value>
<check>GE($spp, 8) AND LE($spp, 2048) AND IS_PWR_OF_2($spp)</check>
<check_message>Window size must be in [8, 2048] and a power of
two.</check_message>
<action>SR_WRITE("VECTOR_SIZE", $spp)</action>
</arg>
And my ma_freqShift has:
args="spp={}".format($vector_size), (in the make section)
and
<param>
<name>Vector Size</name>
<key>vector_size</key>
<value>512</value>
<type>int</type>
<option>
<name>16</name>
<key>16</key>
</option>
<option>
<name>32</name>
<key>32</key>
</option>
<option>
<name>64</name>
<key>64</key>
</option>
<option>
<name>128</name>
<key>128</key>
</option>
<option>
<name>256</name>
<key>256</key>
</option>
<option>
<name>512</name>
<key>512</key>
</option>
<option>
<name>1024</name>
<key>1024</key>
</option>
<option>
<name>2048</name>
<key>2048</key>
</option>
</param>
and
<check>$vector_size in [2**n for n in xrange(4, 11)]</check>
So what am I missing? It seems to be a disconnect between the FPGA
image and the XML for GR.
Oh yea, in my noc_block_freqShift, I have:
localparam [7:0] AXI_WRAPPER_BASE = 128;
localparam [7:0] SR_VECTOR_SIZE = AXI_WRAPPER_BASE + 8'd2;
wire [15:0] vector_size;
setting_reg #(
.my_addr(SR_VECTOR_SIZE), .awidth(8), .width(16))
sr_vector_size (
.clk(ce_clk), .rst(ce_rst | clear_tx_seqnum),
.strobe(set_stb), .addr(set_addr), .in(set_data), .out(vector_size));
Can anyone see what I am missing or messing up?
------------------------------
Message: 6
Date: Tue, 23 May 2017 19:08:33 +0000
From: Nick Foster <[email protected]>
To: Jonathon Pendlum <[email protected]>, Christophe
ALEXANDRE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GRC + RFNoC + Radio Loopback
Message-ID:
<CA+JMMq9erniy+pOv5y3=wbdgh2mwreqy-twghfjac5_s+2c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Christophe,
This might be a dumb question, but If you followed Step 2 in the guide I
wrote, did you also follow steps 1 & 3?
--n
On Tue, May 23, 2017 at 7:43 AM Jonathon Pendlum via USRP-users <
[email protected]> wrote:
> Hi Christophe,
>
> Out of the box, all RFNoC flowgraphs require at least one connection back
> to the host. This is a limitation of UHD that we plan on fixing. That is
> also why your second flowgraph worked. We are having some discussions on
> making a block to allow loopback, but I can't give you any dates when that
> will be done. If you want to give it a try yourself, one possibility would
> be to make a custom rfnoc block with 2 inputs / 1 output. One of the inputs
> would be from the rx radio, the other a "dummy" connection from the host.
> The output would connect to the tx radio. The block would also need to
> adjust vita time or just strip it off the header.
>
>
>
> Jonathon
>
> On Tue, May 23, 2017 at 5:40 AM, Christophe ALEXANDRE via USRP-users <
> [email protected]> wrote:
>
>> Hi,
>>
>> i'm using an X310 with 2 BasicRx and 2 BasicTx and a fresh install of
>> RFNoC.
>>
>> i'm trying to understand how i can use RFNoC with gnuradio companion
>> and how i can mix gnuradio software blocks and RFNoC blocks.
>>
>> With the help of Ettus documentations, i think i understand the idea
>> except in one case, when i try to use both Rx and Tx radio blocks (and i
>> can't
>> see any examples in ~rfnoc/src/gr-ettus/examples/rfnoc).
>>
>> My first test is a simple loopback :
>>
>>
>>
>>
>> when i run this flowgraph, there is no errors, but nothing happens
>> and the rf0 and rf1 leds are off. There is no signal copy
>> from rf1:Rx2 to rf0:Tx.
>>
>> if i understand clearly the problem explained here :
>>
>> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>>
>> this is a timestamp problem on the Tx side. I've tried to follow the
>> proposed solution
>> (Step 2: Enable Streamer), but without success.
>>
>> But if the flowgraph go back to the host doing nothing (add a 0
>> constant), it works
>> (i suppose that gnuradio creates the necessary timestamps for the Tx
>> side) :
>>
>>
>>
>>
>> Leds are on and the input signal is going from rf1:Rx2 to rf0:Tx.
>>
>>
>> Is there any better way to solve this problem ?
>>
>>
>> regards.
>>
>>
>> Christophe ALEXANDRE
>>
>>
>>
>>
>> _______________________________________________
>> 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/20170523/901a4a12/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mhchgkcieefppgkn.png
Type: image/png
Size: 48211 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/901a4a12/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oblcnkeooilafnfm.png
Type: image/png
Size: 51473 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170523/901a4a12/attachment-0003.png>
------------------------------
Message: 7
Date: Tue, 23 May 2017 15:13:59 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] problem with RFNoC settings register
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I should have sent this email out earlier, I figured it out as soon as I
sent it.... The problem was that I had 3 settings in my freqShift.xml,
and I inadvertidly wrapped all three in the registers tag individually
instead of one set of tags around all three. Sorry for the SPAM.
On 05/23/2017 03:05 PM, Jason Matusiak wrote:
> I attempted to add a new RFNoC block to my OOT project and I am having
> problems setting the sample rate in my block. I mimiced what I did in
> my previously working block, but this new one keeps erroring out. The
> error looks like:
> [ERROR] [RFNOC] [NocScript] Error while executing
> SR_WRITE(VECTOR_SIZE, 0x200):
> LookupError: KeyError: Unknown settings register name: VECTOR_SIZE
> Error: RuntimeError: [NocScript] Code returned false:
> SR_WRITE("VECTOR_SIZE", $spp)
>
>
> My freqShift,xml has:
> <registers>
> <setreg>
> <name>VECTOR_SIZE</name>
> <address>130</address>
> </setreg>
> </registers>
>
> and
>
> <arg>
> <name>spp</name>
> <type>int</type>
> <value>512</value>
> <check>GE($spp, 8) AND LE($spp, 2048) AND IS_PWR_OF_2($spp)</check>
> <check_message>Window size must be in [8, 2048] and a power of
> two.</check_message>
> <action>SR_WRITE("VECTOR_SIZE", $spp)</action>
> </arg>
>
>
> And my ma_freqShift has:
> args="spp={}".format($vector_size), (in the make section)
>
> and
>
> <param>
> <name>Vector Size</name>
> <key>vector_size</key>
> <value>512</value>
> <type>int</type>
> <option>
> <name>16</name>
> <key>16</key>
> </option>
> <option>
> <name>32</name>
> <key>32</key>
> </option>
> <option>
> <name>64</name>
> <key>64</key>
> </option>
> <option>
> <name>128</name>
> <key>128</key>
> </option>
> <option>
> <name>256</name>
> <key>256</key>
> </option>
> <option>
> <name>512</name>
> <key>512</key>
> </option>
> <option>
> <name>1024</name>
> <key>1024</key>
> </option>
> <option>
> <name>2048</name>
> <key>2048</key>
> </option>
> </param>
>
> and
>
> <check>$vector_size in [2**n for n in xrange(4, 11)]</check>
>
>
> So what am I missing? It seems to be a disconnect between the FPGA
> image and the XML for GR.
>
> Oh yea, in my noc_block_freqShift, I have:
> localparam [7:0] AXI_WRAPPER_BASE = 128;
> localparam [7:0] SR_VECTOR_SIZE = AXI_WRAPPER_BASE + 8'd2;
>
> wire [15:0] vector_size;
>
> setting_reg #(
> .my_addr(SR_VECTOR_SIZE), .awidth(8), .width(16))
> sr_vector_size (
> .clk(ce_clk), .rst(ce_rst | clear_tx_seqnum),
> .strobe(set_stb), .addr(set_addr), .in(set_data), .out(vector_size));
>
> Can anyone see what I am missing or messing up?
------------------------------
Message: 8
Date: Tue, 23 May 2017 12:26:34 -0700
From: Nate Temple <[email protected]>
To: Stephen Larew <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] No x310 XGS image for UHD 3.9.6?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hi Stephen,
Dual 10Gb support on the X3xx was officially added with UHD 3.10.0.0. [1]
[1] - https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L60
Regards,
Nate Temple
> On May 23, 2017, at 11:21 AM, Stephen Larew via USRP-users
> <[email protected]> wrote:
>
> I?m trying to use dual 10g ethernet on an x310. I?m using UHD 3.9.6. The
> images downloaded by uhd_images_downloader do not appear to contain the XGS
> (dual 10G) image. Am I missing something?
>
>> $ ls ./current/share/uhd/images/
>> 003.009.006.tag usrp_e110_fpga.bin
>> bit usrp_e310_fpga.bit
>> LICENSE usrp_e310_fpga_idle.bit
>> octoclock_bootloader.hex usrp_e310_fpga_sg3.bit
>> octoclock_r4_fw.hex usrp_e3xx_fpga_idle.bit
>> usrp1_fpga_4rx.rbf usrp_e3xx_fpga_idle_sg3.bit
>> usrp1_fpga.rbf usrp_n200_fw.bin
>> usrp1_fw.ihx usrp_n200_r2_fpga.bin
>> usrp2_fpga.bin usrp_n200_r3_fpga.bin
>> usrp2_fw.bin usrp_n200_r4_fpga.bin
>> usrp_b100_fpga_2rx.bin usrp_n210_fw.bin
>> usrp_b100_fpga.bin usrp_n210_r2_fpga.bin
>> usrp_b100_fw.ihx usrp_n210_r3_fpga.bin
>> usrp_b200_fpga.bin usrp_n210_r4_fpga.bin
>> usrp_b200_fw.hex usrp_x300_fpga_HGS.bit
>> usrp_b200mini_fpga.bin usrp_x300_fpga_HGS.lvbitx
>> usrp_b205mini_fpga.bin usrp_x310_fpga_HGS.bit
>> usrp_b210_fpga.bin usrp_x310_fpga_HGS.lvbitx
>> usrp_e100_fpga_v2.bin winusb_driver
>
> -Stephen
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 9
Date: Tue, 23 May 2017 15:32:50 -0400
From: Stephen Larew <[email protected]>
To: Nate Temple <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] No x310 XGS image for UHD 3.9.6?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
That would explain it thanks Nate.
FYI, we used to use 3.10.1.1 but have found it to be too unstable for us right
now. We?re back on 3.9 without issue but would like to use RFNoC soon. Add dual
10g to the RFNoC requirement as reasons to switch back to maint/rfnoc-devel
branches. Hopefully the issues we were seeing will be resolved soon.
> On May 23, 2017, at 15:26, Nate Temple <[email protected]> wrote:
>
> Hi Stephen,
>
> Dual 10Gb support on the X3xx was officially added with UHD 3.10.0.0. [1]
>
> [1] - https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L60
>
> Regards,
> Nate Temple
>
>
>
>> On May 23, 2017, at 11:21 AM, Stephen Larew via USRP-users
>> <[email protected]> wrote:
>>
>> I?m trying to use dual 10g ethernet on an x310. I?m using UHD 3.9.6. The
>> images downloaded by uhd_images_downloader do not appear to contain the XGS
>> (dual 10G) image. Am I missing something?
>>
>>> $ ls ./current/share/uhd/images/
>>> 003.009.006.tag usrp_e110_fpga.bin
>>> bit usrp_e310_fpga.bit
>>> LICENSE usrp_e310_fpga_idle.bit
>>> octoclock_bootloader.hex usrp_e310_fpga_sg3.bit
>>> octoclock_r4_fw.hex usrp_e3xx_fpga_idle.bit
>>> usrp1_fpga_4rx.rbf usrp_e3xx_fpga_idle_sg3.bit
>>> usrp1_fpga.rbf usrp_n200_fw.bin
>>> usrp1_fw.ihx usrp_n200_r2_fpga.bin
>>> usrp2_fpga.bin usrp_n200_r3_fpga.bin
>>> usrp2_fw.bin usrp_n200_r4_fpga.bin
>>> usrp_b100_fpga_2rx.bin usrp_n210_fw.bin
>>> usrp_b100_fpga.bin usrp_n210_r2_fpga.bin
>>> usrp_b100_fw.ihx usrp_n210_r3_fpga.bin
>>> usrp_b200_fpga.bin usrp_n210_r4_fpga.bin
>>> usrp_b200_fw.hex usrp_x300_fpga_HGS.bit
>>> usrp_b200mini_fpga.bin usrp_x300_fpga_HGS.lvbitx
>>> usrp_b205mini_fpga.bin usrp_x310_fpga_HGS.bit
>>> usrp_b210_fpga.bin usrp_x310_fpga_HGS.lvbitx
>>> usrp_e100_fpga_v2.bin winusb_driver
>>
>> -Stephen
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 10
Date: Tue, 23 May 2017 22:04:27 -0400
From: EJ Kreinar <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnoc-modtool cores
Message-ID:
<cadrnh22w0jjelsrnovnktxef4-nhi5pzrdmnrm4_a-qp-38...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jason and others,
As a follow up, I put together an rfnoc OOT repo that uses Makefiles to
build Vivado IP and HLS IP: https://github.com/ejk43/rfnoc-ootexample
The simulations should run successfully when uhd-fpga is set up correctly
(see readme), and also should build the OOT noc_blocks into an FPGA image
using "make E310_RFNOC" etc etc.
Hope this helps,
EJ
On Fri, May 19, 2017 at 12:08 PM, EJ Kreinar <[email protected]> wrote:
> Jason,
>
> Sure, I'd say just clone my fpga repo and apply the patch for now. Quick
> instructions:
>
> 1. In your uhd-fpga repo: `git remote add ejk
> https://github.com/ejk43/fpga.git` <https://github.com/ejk43/fpga.git>
> a. This now sets up a remote named "ejk" which points to my fork
> 2. Then: `git fetch ejk new_oot_includes`
> 3. Then you can either checkout this branch (if you have no other changes
> on your uhd-fpga repo), or cherry-pick the commits from the
> new_oot_includes branch.
>
>
> In lieu of an example OOT repo, here's how I set up my "rfnoc" folder
> structure in the OOT repo:
>
> rfnoc:
> + Makefile.inc
> + blocks
> + testbenches
> + fpga-src
> + Makefile.inc
>
> + noc_block_testblock.v
>
> + ip
> + Makefile.inc
> + my_ip
> + my_ip.xci
> + Makefile.inc
>
>
>
> Here's an example top-level Makefile.inc:
>
> RFNOC_MYTEST_DIR := $(OOT_DIR)
> include $(abspath $(RFNOC_MYTEST_DIR)/fpga-src/Makefile.inc)
> include $(abspath $(RFNOC_MYTEST_DIR)/ip/Makefile.inc)
>
>
>
> Then the fpga-src Makefile.inc:
>
> RFNOC_OOT_SRCS += $(addprefix $(RFNOC_MYTEST_DIR)/fpga-src/, \
> noc_block_testblock.v \
> )
>
>
>
> Then the IP Makefile.inc (modeled after the Makefile.inc in the
> uhd-fpga/usrp3/lib/ip:
>
> include $(RFNOC_MYTEST_DIR)/ip/my_ip/Makefile.inc
>
> LIB_MYTEST_IP_XCI_SRCS = \
> $(LIB_IP_MY_IP_SRCS)
>
> LIB_MYTEST_IP_SYNTH_OUTPUTS = \
> $(LIB_IP_MY_IP_OUTS)
>
> LIB_IP_XCI_SRCS += $(LIB_MYTEST_IP_XCI_SRCS)
>
>
>
> And finally, the Makefile.inc inside the my_ip directory (modeled after
> the lib/ip/xxx Makefile.inc):
>
> include $(TOOLS_DIR)/make/viv_ip_builder.mak
>
> LIB_IP_MY_IP_SRCS = $(IP_BUILD_DIR)/my_ip/my_ip.xci
>
> LIB_IP_MY_IP_OUTS = $(addprefix $(IP_BUILD_DIR)/my_ip/, \
> my_ip.xci.out \
> synth/my_ip.vhd \
> )
>
> $(LIB_IP_MY_IP_SRCS) $(LIB_IP_MY_IP_OUTS) : $(LIB_IP_DIR)/my_ip/my_ip.xci
> $(call BUILD_VIVADO_IP,my_ip,$(ARCH),$(PART_ID),$(LIB_IP_DIR),$(IP_
> BUILD_DIR),0)
>
>
>
> It's also possible to rejigger the testbench makefiles to build the OOT IP
> for your testbench.
>
> Again, I should pull this into an example OOT repo sometime soon, which
> would make it a bit easier to have an example. Let me know if you hit any
> problems.
>
> EJ
>
> On Fri, May 19, 2017 at 8:38 AM, Jason Matusiak <
> [email protected]> wrote:
>
>> EJ, that looks exactly like what I need to do. Is there a way for me to
>> patch in your changes so I can try to use them while we wait for Ettus to
>> (dis)approve your PR?
>>
>> Thanks!
>> ~Jason
>>
>>
>>
>> On 05/18/2017 04:11 PM, EJ Kreinar wrote:
>>
>> Hi Jason,
>>
>> I currently have a PR in to the fpga repo (https://github.com/EttusResea
>> rch/fpga/pull/12) that adds support for linking Makefile.inc files in
>> OOT repos. Your OOT Makefile can then build the Xilinx IP and append it to
>> your build as needed. I've been using this approach for some time now with
>> success for both Xilinx IP and HLS designs.
>>
>> I have an action to provide a sample "dummy" OOT repo with the correct
>> Makefiles-- but I havent gotten to it yet, unfortunately-- Was waiting for
>> confirmation if this approach will be supported in-tree in the future. I
>> could put something together soon though if this would help.
>>
>> I'd also be interested in other good solutions, if anyone has an
>> alternate approach :)
>>
>> EJ
>>
>> On Thu, May 18, 2017 at 2:22 PM, Jason Matusiak via USRP-users <
>> [email protected]> wrote:
>>
>>> I wanted to create an RFNoC block that utilized some Xilinx cores. Where
>>> do I need to put these cores in the rfnoc-modtool project created directory
>>> structure, and how do I go about tying that into the Vivado GUI so I can
>>> build them up (just use the GUI=1 CL argument and do the save-as project
>>> approach?)?
>>>
>>> _______________________________________________
>>> 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/20170523/f51cc3ec/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 24 May 2017 10:51:08 +0800
From: liu Jong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] About Self calibration
Message-ID:
<CAEui2n0DC048B=jnjepsyrfsf2vehuomkjsgthyfzmlezwf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We used usrp X310 and run command uhd_usrp_probe,errors as below:
uhd_usrp_probe
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.001.HEAD-0-g945fd653
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1186.3MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1173.8MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
Error: RuntimeError: self_cal_adc_capture_delay: Self calibration failed.
Convergence error.
command with uhd_usrp_probe --init--only:
uhd_usrp_probe --init-only
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.001.HEAD-0-g945fd653
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1189.6MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1184.8MB/s)
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- Performing timer loopback test... pass
Error: RuntimeError: self_cal_adc_capture_delay: Self calibration failed.
Convergence error.
Then we changed uhd version to uhd3.9.5,but the errors keep same.
We tried to find a solution on user list,but not found.
Do you have any advice?
thank you.
best regards
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/9713a226/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 24 May 2017 03:46:30 +0000
From: Xingjian Chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B200mini GPIO input
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Do you know how to configure some of GPIO ports as inputs and some as outputs
for b200mini?
Thank you very much.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/4967cc58/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 24 May 2017 05:08:02 +0000
From: carry chen <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Fw: B205mini Frequency Accuracy
Message-ID:
<sixpr06mb0905a541d933a08405e3ac47dd...@sixpr06mb0905.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks, mleech,
But I check the ettus website, only B210/B200/E3xx have GPSDO interface,
Can B205mini do that?
Can some body recommend some GPSD or OCXO Product use for B205mini ?
Thank you very much!
Carry
________________________________
From: [email protected] <[email protected]>
Sent: Tuesday, May 23, 2017 12:04 PM
To: carry chen
Cc: [email protected]
Subject: Re: [USRP-users] B205mini Frequency Accuracy
The usual way to do that is to use an external reference oscillator that is
better than the clock that is on-board.
For example a GPSDO, or an external 10MHz OCXO source, etc.
On 2017-05-23 14:58, carry chen via USRP-users wrote:
Hi,list
I check the b205mini datasheet and see the frequency accuracy is ?2.0 ppm,
Can I change the clock to get better frequency accuracy?
Thank you very much!
Carry
_______________________________________________
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/20170524/21b77281/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 24 May 2017 10:22:22 +0200
From: [email protected]
To: Julian Arnold <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Trigger Signal
Message-ID:
<20170524102222.horde.behymzt26onywreztodh...@webmail.rrzn.uni-hannover.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
No, I did not but it sounds as if it would work much better! I will try this!
Thank you!
Mareike
Zitat von Julian Arnold <[email protected]>:
> Hey Mareike,
>
> have you considered using the GPIO API for this task [1]?
> I think using the GPIOs as a trigger source is more adequate than using
> the PPS input as the PPS should be used for time synchronization between
> multiple devices. (However, one could probably abuse it as a trigger)
>
> Cheers,
>
> [1] https://files.ettus.com/manual/page_gpio_api.html
>
> On 05/22/2017 04:50 PM, hetzel--- via USRP-users wrote:
>> Hi!
>>
>> I want to build a trigger signal for my USRP X310 using UHD version
>> 3.10.1.1. I want to send a pulse to the USRP and after receiving this
>> pulse my device should start/stop streaming or something similar.
>>
>> I found that I can use the PPS TRIG IN port and send a trigger signal.
>> Therefore I have to set the PPS to external:
>> pps = "external" (Is this the right way to do so?)
>> Afterwards the idea is to use timed commands and to start a long time
>> from now. But with the next received PPS pulse, I set the clock to the
>> same time. I started with a slightly changed tx_waveforms C++ file. I
>> would use these additions to the code:
>>
>> usrp->set_time_now(0.0); //somewhere in the beginning
>> usrp->set_command_time(uhd::time_spec_t(1e6));
>>
>> md.has_time_spec = true;
>> md.time_spec = uhd::time_spec_t(1e6); // I am not sure if this is needed
>>
>> usrp->set_time_next_pps(uhd::time_spec_t(1e6)); // and this directly
>> before I want to start streaming
>>
>> usrp->clear_command_time(); // in the end
>>
>>
>>
>> If I run this program my USRP seems to wait for a PPS signal but it
>> does not react to those I send using a Function Generator. So how does
>> a PPS input pulse has to look like? It says that it should have max 5V
>> but how long should it be?
>>
>> So I have to stop the program. But if I want to re-run it there occurs
>> a problem and I cannot run any other program until I power cycle the
>> device. I get the following output to the console:
>>
>>
>> Win32; Microsoft Visual C++ version 14.0; Boost_105900;
>> UHD_003.010.001.001-rele
>> ase
>>
>>
>> Creating the usrp device with: ...
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 8000 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Creating WSA UDP transport for 192.168.40.2:49153
>> -- Creating WSA UDP transport for 192.168.40.2:49153
>> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1304.3MB/s)
>> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1304.9MB/s)
>> -- Creating WSA UDP transport for 192.168.40.2:49153
>> Error: EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no
>> response packet
>> - AssertionError: bool(buff)
>> in unsigned __int64 __cdecl ctrl_iface_impl::wait_for_ack(const bool)
>> at
>> C:\cygwin64\home\jenkins\worker\Package_Windows_x64_14\work\uhd\host\lib\rf
>> noc\ctrl_iface.cpp:205
>>
>>
>> Do you have any idea why this happens?
>>
>> I use Visual Studio 2015 on Windows 7.
>>
>> Best regards,
>> Mareike Hetzel
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Julian Arnold, M.Sc.
>
> Institute for Networked Systems
> RWTH Aachen University
>
> Kackertstrasse 9
> 52072 Aachen
> Germany
------------------------------
Message: 15
Date: Wed, 24 May 2017 11:18:29 +0200
From: [email protected]
To: [email protected]
Subject: [USRP-users] Shifting frequencies
Message-ID:
<20170524111829.horde.c033zkyahi5nmr7vkruk...@webmail.rrzn.uni-hannover.de>
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Hi!
I want to shift my output frequency. For example I set my center
frequency at 100MHz and I want to send a varying frequency between 100
and 105 MHz. I changed the tx_waveforms C++ code where I changed the
frequency inside the while-loop:
int i = 0;
while (true) {
i++;
double count = static_cast<double>(i);
if (stop_signal_called) break;
if (total_num_samps > 0 and num_acc_samps >= total_num_samps) break;
for (size_t n = 0; n < buff.size(); n++) {
double convertn = static_cast<double>(n);
shift[n] = (1.0 / buff.size() * convertn);
buff[n] = 0.15 * exp(2.0 *im* M_PI* shift[n] * count);
}
num_acc_samps += tx_stream->send(
buffs, buff.size(), md
);
}
This was working fine and I could define the frequency range by
adjusting the counter. But with higher sample rates or generating more
frequencies I got a lot of underflows which I could solve for static
frequencies by pre-calculating the buffer (outside the while-loop).
Now I want to pre-calculate the varying frequencies. I tried to write
them into an array like this:
std::complex<float> buffer[spb][columns];
...
for (size_t k = 0; k < columns; k++) {
double convertn = static_cast<double>(k);
shift[k] = (1.0 / columns* convertn);
for (size_t n = 0; n < spb; n++) {
double count = static_cast<double>(n);
buffer[n][k] = 0.15 * exp(2.0 *im* M_PI* shift[k] * count);
}
}
int m=0;
while(true) {
m++;
std::vector<std::complex<float> *> buffers(channel_nums.size(),
&buffer[0][m]);
...
send(...);
...
}
But this is generating very strange output. Instead of sweeping the
frequency it generates a lot of frequencies at the same time. I tried
to find out what is happening and started with only one column which
worked. But already with two columns there appeared additional peaks
at +/- 10 MHz with a sampling rate of 20MHz although I calculated and
send only one column. I did this for a couple of numbers and it
generated frequencies at +/-sample_rate/columns and multiples of that.
Do you have any solution or idea how to pre-calculate the buffers? Is
it possible to send parts of an array?
Or is there a completely different way to sweep the frequencies?
Best regards,
Mareike
------------------------------
Message: 16
Date: Wed, 24 May 2017 10:09:15 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 05/24/2017 01:08 AM, carry chen via USRP-users wrote:
>
>
> Thanks, mleech,
>
>
> But I check the ettus website, only B210/B200/E3xx have GPSDO interface,
>
> Can B205mini do that?
>
> Can some body recommend some GPSD or OCXO Product use for B205mini ?
>
>
> Thank you very much!
>
>
> Carry
>
The "mini" series have a synchronization input that can either be 1PPS
or 10MHz, which is used to steer the on-board oscillator.
Ettus have the Octoclock-G product, but unless you have a number of
devices which require synchronization, this may not be economical.
Jackson Labs make many of the internal GPSDOs used inside Ettus devices,
and they have a number that can be used externally as well.
One can also search eBay.
What is your application that you need better than +/- 2PPM?
>
>
> ------------------------------------------------------------------------
> *From:* [email protected] <[email protected]>
> *Sent:* Tuesday, May 23, 2017 12:04 PM
> *To:* carry chen
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] B205mini Frequency Accuracy
>
> The usual way to do that is to use an external reference oscillator
> that is better than the clock that is on-board.
>
> For example a GPSDO, or an external 10MHz OCXO source, etc.
>
> On 2017-05-23 14:58, carry chen via USRP-users wrote:
>
>> Hi,list
>>
>> I check the b205mini datasheet and see the frequency accuracy is ?2.0
>> ppm,
>>
>> Can I change the clock to get better frequency accuracy?
>>
>> Thank you very much!
>>
>> Carry
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[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/20170524/5ca53654/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 24 May 2017 10:45:38 -0400
From: Jason Matusiak <[email protected]>
To: carry chen <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Carry, What I think Marcus means, is that you could use the sync/clock
port on the mini to get better accuracy. There is no way to add on a
GPSDO directly.
On 05/24/2017 01:08 AM, carry chen via USRP-users wrote:
>
>
> Thanks, mleech,
>
>
> But I check the ettus website, only B210/B200/E3xx have GPSDO interface,
>
> Can B205mini do that?
>
> Can some body recommend some GPSD or OCXO Product use for B205mini ?
>
>
> Thank you very much!
>
>
> Carry
>
>
> ------------------------------------------------------------------------
> *From:* [email protected] <[email protected]>
> *Sent:* Tuesday, May 23, 2017 12:04 PM
> *To:* carry chen
> *Cc:* [email protected]
> *Subject:* Re: [USRP-users] B205mini Frequency Accuracy
>
> The usual way to do that is to use an external reference oscillator
> that is better than the clock that is on-board.
>
> For example a GPSDO, or an external 10MHz OCXO source, etc.
>
> On 2017-05-23 14:58, carry chen via USRP-users wrote:
>
>> Hi,list
>>
>> I check the b205mini datasheet and see the frequency accuracy is ?2.0
>> ppm,
>>
>> Can I change the clock to get better frequency accuracy?
>>
>> Thank you very much!
>>
>> Carry
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[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/20170524/1ab411f1/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 24 May 2017 16:46:56 +0200
From: Christophe ALEXANDRE <[email protected]>
To: Nick Foster <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GRC + RFNoC + Radio Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Nick,
not so dumb. I think my step 1 is not correct.
your post is very clear and i can't see why it doesn't work.
I will try again next week.
regards.
Christophe ALEXANDRE
Le 23/05/2017 ? 21:08, Nick Foster a ?crit :
> Christophe,
>
> This might be a dumb question, but If you followed Step 2 in the guide
> I wrote, did you also follow steps 1 & 3?
>
> --n
>
> On Tue, May 23, 2017 at 7:43 AM Jonathon Pendlum via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Christophe,
>
> Out of the box, all RFNoC flowgraphs require at least one
> connection back to the host. This is a limitation of UHD that we
> plan on fixing. That is also why your second flowgraph worked. We
> are having some discussions on making a block to allow loopback,
> but I can't give you any dates when that will be done. If you want
> to give it a try yourself, one possibility would be to make a
> custom rfnoc block with 2 inputs / 1 output. One of the inputs
> would be from the rx radio, the other a "dummy" connection from
> the host. The output would connect to the tx radio. The block
> would also need to adjust vita time or just strip it off the header.
>
>
>
> Jonathon
>
> On Tue, May 23, 2017 at 5:40 AM, Christophe ALEXANDRE via
> USRP-users <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi,
>
> i'm using an X310 with 2 BasicRx and 2 BasicTx and a fresh
> install of RFNoC.
>
> i'm trying to understand how i can use RFNoC with gnuradio
> companion
> and how i can mix gnuradio software blocks and RFNoC blocks.
>
> With the help of Ettus documentations, i think i understand
> the idea
> except in one case, when i try to use both Rx and Tx radio
> blocks (and i can't
> see any examples in ~rfnoc/src/gr-ettus/examples/rfnoc).
>
> My first test is a simple loopback :
>
>
>
>
> when i run this flowgraph, there is no errors, but nothing happens
> and the rf0 and rf1 leds are off. There is no signal copy
> from rf1:Rx2 to rf0:Tx.
>
> if i understand clearly the problem explained here :
>
> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>
> this is a timestamp problem on the Tx side. I've tried to
> follow the proposed solution
> (Step 2: Enable Streamer), but without success.
>
> But if the flowgraph go back to the host doing nothing (add a
> 0 constant), it works
> (i suppose that gnuradio creates the necessary timestamps for
> the Tx side) :
>
>
>
>
> Leds are on and the input signal is going from rf1:Rx2 to rf0:Tx.
>
>
> Is there any better way to solve this problem ?
>
>
> regards.
>
>
> Christophe ALEXANDRE
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> _______________________________________________
> 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/20170524/d5abb2c2/attachment-0001.html>
------------------------------
Message: 19
Date: Wed, 24 May 2017 11:33:18 -0400
From: [email protected]
To: Jason Matusiak <[email protected]>
Cc: carry chen <[email protected]>, [email protected]
Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Yes, sorry if I created any confusion.
The 'mini' series have no provision for an on-board GPSDO, like their
big brothers do. You'd need to use an external clock source, and use
the sync input on the 'mini' series.
On 2017-05-24 10:45, Jason Matusiak via USRP-users wrote:
> Carry, What I think Marcus means, is that you could use the sync/clock port
> on the mini to get better accuracy. There is no way to add on a GPSDO
> directly.
>
> On 05/24/2017 01:08 AM, carry chen via USRP-users wrote:
>
> Thanks, mleech,
>
> But I check the ettus website, only B210/B200/E3xx have GPSDO interface,
>
> Can B205mini do that?
>
> Can some body recommend some GPSD or OCXO Product use for B205mini ?
>
> Thank you very much!
>
> Carry
>
> -------------------------
>
> FROM: [email protected] <[email protected]>
> SENT: Tuesday, May 23, 2017 12:04 PM
> TO: carry chen
> CC: [email protected]
> SUBJECT: Re: [USRP-users] B205mini Frequency Accuracy
>
> The usual way to do that is to use an external reference oscillator that is
> better than the clock that is on-board.
>
> For example a GPSDO, or an external 10MHz OCXO source, etc.
>
> On 2017-05-23 14:58, carry chen via USRP-users wrote:
>
> Hi,list
>
> I check the b205mini datasheet and see the frequency accuracy is ?2.0 ppm,
>
> Can I change the clock to get better frequency accuracy?
>
> Thank you very much!
>
> Carry
> _______________________________________________
> 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
_______________________________________________
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/20170524/275935a1/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 81, Issue 24
******************************************
