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. X300 with only one d/b (Serge Malo)
2. Netgear 10GB switch XS728T (Kevin Krieger)
3. Re: X300 with only one d/b ([email protected])
4. Re: B205i transient behavior (Michael West)
5. Re: Netgear 10GB switch XS728T (ROBIN TORTORA)
6. Re: Fw: B205mini Frequency Accuracy (carry chen)
7. Using on-board DRAM on x310 (Leandro Echevarr?a)
8. Re: B205mini Frequency Accuracy (Steven Knudsen)
9. Re: B205mini Frequency Accuracy (carry chen)
10. Re: X300 with only one d/b (Serge Malo)
11. Re: Netgear 10GB switch XS728T (Marcus M?ller)
12. Re: B205mini Frequency Accuracy (Marcus M?ller)
13. Re: About Self calibration (Marcus M?ller)
14. Re: B200mini GPIO input (Marcus M?ller)
15. Re: B200mini GPIO input (Michael West)
16. Re: In URSP B210, how to deal with the signal in real time?
(Michael West)
17. Re: UBX160 and TrinRx on one X310 (liu Jong)
18. Re: About Self calibration (liu Jong)
19. Re: X300 with only one d/b (Serge Malo)
20. Re: X300 with only one d/b (Marcus D. Leech)
----------------------------------------------------------------------
Message: 1
Date: Wed, 24 May 2017 13:35:16 -0400
From: Serge Malo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X300 with only one d/b
Message-ID:
<CAOhu+FNtGepK2MgH=am-2upvalikip+gaopsb8t2msh6fz-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We are using X300's with UHD coming from the maint branch, version of April
20th 2017. We wanted to use the latest version in order to support UBX-160
v2 d/b with all possible fixes in UHD.
However, we have felt into a serious issue in TX when only one UBX d/b is
present inside the X300:
The IQ samples don't seem to be consumed at the correct pace. Also, the
spectrum shape is incorrect and it is not consistent from one transmission
to another.
I would like to know if this is a known issue and if someone can confirm
this problem.
If so, is there a known workaround?
Regards,
Serge
__________________
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol <https://twitter.com/skydelsol>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/9a3e078f/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 24 May 2017 16:12:35 +0000
From: Kevin Krieger <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Netgear 10GB switch XS728T
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all,
I've got a predicament. Here's some *background* before I describe my
problem:
We purchased a Netgear xs728T 10GB switch in order to network 16 N200
devices, as well as a processing computer (which has a 10G ethernet
card). Our 16 N200 devices are going to be used in a radar configuration
where they are all simultaneously either transmitting or receiving. They
are all receiving coincident 10MHz and 1PPS signals from 2 octoclocks,
which are both fed from a third clock to ensure coincident clocks. They
are connected to the switch via cat6 cables ~7feet in length (this item:
https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136)
*The problem:*
During testing we've found that the example program tx_bursts, when run
on one USRP at a time with a modest bandwidth, the "Waiting for async
burst ack....failed" message appears about 75% of the time. If I try to
use two or more USRPs at a time, then it appears every time.
The line used for tx_bursts was typically something like
this:./tx_bursts --args="addr0=192.168.10.104" --freq 10e6 --rate=1e6
--channels="0"
for a one usrp test. For a multiple usrp test, I used lines like
this:./tx_bursts
--args="addr0=192.168.10.101,addr1=192.168.10.102,addr2=192.168.10.103,addr3=192.168.10.100,addr4=192.168.10.112,addr5=192.168.10.113,addr6=192.168.10.114"
--freq 10e6 --rate=1e6 --channels="0,1,2,3,4,5,6"
*Some evidence & information:
*We also have a 5 port 1G DLink DGS-1005G. We've tested 4 N200s with
tx_bursts on this switch (same cabling) and it works flawlessly.
We also have tested a second 10G switch, the 8 port XS708E with 7 N200s
with tx_bursts and it works flawlessly.
I have wireshark dumps taken via a third machine that is connected to
mirrored ports on the xs728T switch. I have attached them in case anyone
can tell me if they see something wrong besides the missing acks.
The wireshark filter to use is : ip.src == 192.168.10.104 and ip.dst ==
192.168.10.104 or ip.src == 192.168.10.104 and ip.dst == 192.168.10.99
The xs728t switch information is: Boot version is 1.0.0.0, SW version is
6.5.1.26 (latest as of testing).
I contacted Netgear support, and they sent us a brand new switch, which
exhibited the same problem.
I'm wondering if there's anyone out there who has had similar issues? Is
there anything I can do to get more information or get around this problem?
Can anyone see what the root cause might be in the wireshark captures?
Any help or pointers are appreciated. Thank you,
Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/d4787147/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1_device_succeed.pcapng
Type: application/x-pcapng
Size: 402236 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/d4787147/attachment-0002.pcapng>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1_device_fail.pcapng
Type: application/x-pcapng
Size: 194904 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/d4787147/attachment-0003.pcapng>
------------------------------
Message: 3
Date: Wed, 24 May 2017 14:04:03 -0400
From: [email protected]
To: Serge Malo <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] X300 with only one d/b
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Not sure what you mean by "consumed at the correct pace". The
daughterboards are entirely analog, so "sample consumption" is much
earlier in the chain.
Perhaps you could share some code that demonstrates the issue? Maybe
some spectral plots?
What sample rate are you trying to use?
On 2017-05-24 13:35, Serge Malo via USRP-users wrote:
> Hi all,
>
> We are using X300's with UHD coming from the maint branch, version of April
> 20th 2017. We wanted to use the latest version in order to support UBX-160 v2
> d/b with all possible fixes in UHD.
>
> However, we have felt into a serious issue in TX when only one UBX d/b is
> present inside the X300:
> The IQ samples don't seem to be consumed at the correct pace. Also, the
> spectrum shape is incorrect and it is not consistent from one transmission to
> another.
>
> I would like to know if this is a known issue and if someone can confirm this
> problem.
> If so, is there a known workaround?
>
> Regards,
> Serge
>
> __________________
> SERGE MALO
> CDO & Co-founder, Skydel Solutions
> Cell: 1-514-294-4017
>
> www.skydelsolutions.com [1]
> Twitter: @skydelsol [2]
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Links:
------
[1] http://www.skydelsolutions.com/
[2] https://twitter.com/skydelsol
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/6e97990a/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 24 May 2017 11:07:06 -0700
From: Michael West <[email protected]>
To: Dominik Eyerly <[email protected]>
Cc: "Marcus D. Leech" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] B205i transient behavior
Message-ID:
<cam4xkrqs9idkir_fwmz2snoyca+dfosanunbforbr20qvvw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To update anyone following this thread, the issue of the slow ramp on the
TX has been root caused to a simple hardware issue. The capacitors around
the RF switches (C15, C17, C23, C25, and C26) were too large. Reducing
them from 100 uF to 470 pF resolved the issue. To be clear, the issues is
only seen when operating in full duplex on a B200mini/B205mini/B205mini-I.
For anyone affected by the issue, please contact [email protected] to
arrange an RMA for the rework.
Many thanks to Dominik for staying on top of this issue!
Regards,
Michael
On Mon, May 1, 2017 at 4:41 PM, Michael West <[email protected]> wrote:
> Hi Dominik,
>
> My apologies for the delayed response. I have not had the opportunity to
> look into this any further. We can certainly test it out and let you know
> if we see the same results. I think the best way to proceed is for you to
> contact [email protected] and provide a code sample to reproduce the
> issue along with a link to this thread.
>
> Regards,
> Michael
>
> On Wed, Apr 26, 2017 at 6:16 AM, Dominik Eyerly <
> [email protected]> wrote:
>
>> Hi Michael,
>>
>> Unfortunately, this did not resolve the issue. It seemed to have no
>> effect on the waveform. What else could be causing this behavior? Would you
>> be able to test this on a board you have available to rule out the
>> possibility that I have a bad batch?
>>
>> cheers,
>> Dominik
>>
>> On 04/25/2017 08:25 PM, Michael West wrote:
>>
>> Hi Dominik,
>>
>> To keep the PA on all the time on the B205mini, change STATE_OFF to
>> TX_ENABLE1 on this line: https://github.com/EttusResear
>> ch/uhd/blob/maint/host/lib/usrp/b200/b200_impl.cpp#L1178
>>
>> I am still not convinced that is the main source of long ramp up in
>> power. Some transient due to PA warm up is expected, but it is usually on
>> the order of microseconds and not milliseconds.
>>
>> Regards,
>> Michael
>>
>> On Mon, Apr 24, 2017 at 12:44 AM, Dominik Eyerly <
>> [email protected]> wrote:
>>
>>> Hi Michael,
>>>
>>> Would you be able to point out where in the code I need to make this
>>> modification to keep the PA on at all times? Padding with zeros is a very
>>> undesirable workaround for my application. I will set the tx gain down to
>>> minimize the switch isolation issue.
>>> Thanks,
>>> dominik
>>>
>>>
>>> On 04/15/2017 12:37 AM, Michael West wrote:
>>>
>>> Hi Dominik,
>>>
>>> Creating the streamer connects the blocks in the FPGA, creates the
>>> transports, and does some initialization for the stream. It shouldn't (and
>>> probably doesn't) matter whether you create the streamer or do the other
>>> operations first. I just recommend creating the streamers first as a best
>>> practice to be on the safe side.
>>>
>>> As for the PA, 100ms is longer than I would expect for the warm up
>>> time. I suspect the slow rise is partially due to PA warm up, but there
>>> may be other factors involved as well. I recommend trying varying amounts
>>> of leading zeros to see what the minimum amount is to see a clear signal.
>>> Keeping the PA on all the time should be possible, but it will take UHD
>>> code changes and could have side effects like higher noise on the RX side
>>> due to leakage across the RF switch.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Wed, Apr 12, 2017 at 6:29 AM, Dominik Eyerly <
>>> [email protected]> wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> Thank you for your response. Padding the end with zeros clears some of
>>>> the garbage that is played at the beginning of the waveform.
>>>>
>>>> Creating the streams at the beginning should be no problem for me. One
>>>> follow up question, you mentioned explicitly to create the streamer prior
>>>> to tuning, setting bandwidth etc, do these operations have a specific
>>>> effect on the streamer? Or in other words, what adverse effects, if any,
>>>> exist if I perform these operations before creating the streamer?
>>>>
>>>> As per the PA behavior, this is an issue that is extremely undesirable
>>>> for my application. I understand all PAs will have some rise time, however,
>>>> 100ms seems excessive. Is it perhaps possible to power up the PA earlier
>>>> via some modification to the host / fpga code? Simply pre-pending 100ms of
>>>> zeros to my waveform won't work because I need the waveform to play with
>>>> minimal delay. I don't have any low power constraints so it would not be a
>>>> problem to keep the PA permanently enabled, if that is possible.
>>>>
>>>> cheers,
>>>> dominik
>>>> On 04/11/2017 08:40 PM, Michael West wrote:
>>>>
>>>> Hi Dominik,
>>>>
>>>> I can confirm that the creation of the streamers is very intrusive. It
>>>> changes the active chains in the AD9364 and reconfigures the interface
>>>> between the AD9364 and FPGA as Marcus has pointed out. For that reason, it
>>>> is recommended to create all streamers before starting any streaming.
>>>>
>>>> Looking at the images you posted, the gap and first spur correlate to
>>>> the creation of the TX streamer, so that should be eliminated if the
>>>> streamers are created first. The next significant spur seems to align with
>>>> the start of the TX streaming. My suspicion is that it is from garbage
>>>> samples left in the DUC from initialization, but some testing is needed to
>>>> prove that. Finally, the ramp and elevated power level during the
>>>> transmission of the zeros is due to the TX PA being enabled when the stream
>>>> starts.
>>>>
>>>> My suggestions:
>>>>
>>>> 1) Create the streamers right after creating the multi_usrp object
>>>> (before any tuning, setting bandwidth, setting sample rate, etc...).
>>>> 2) Pad the end of the TX burst with zeros. The first few samples
>>>> transmitted are always the residual samples in the DUC. This means the
>>>> last few samples of the burst will not actually make it to the AD9364
>>>> unless you pad with zeros to flush them. Zero padding the end of every
>>>> burst will make sure all desired samples are transmitted and that the next
>>>> burst will start by transmitting the residual zeros. The amount of the
>>>> group delay will vary depending on master clock rate and sample rate, but
>>>> it is usually on the order of a few to a couple hundred microseconds.
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Tue, Apr 11, 2017 at 1:11 AM, Dominik Eyerly via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> A couple of days has gone by so I wanted to follow up on my questions..
>>>>>
>>>>> *"OK, so, with the zeros, I think I understand what's going on. When
>>>>> you create a new streamer, the hardware has to be configured to the new
>>>>> state.*
>>>>> * In the case of the AD9361, this means the data path between the
>>>>> AD9361 and the FPGA, which unavoidably means that the RX samples are
>>>>> interrupted*
>>>>> * while the interface is reconfigured. I believe this is the
>>>>> reason for a lump of zeros when you configure for TX--someone in
>>>>> engineering can correct*
>>>>> * my understanding if it's wrong."*
>>>>>
>>>>> So this is confirmed behavior then? It is inherently due to the AD
>>>>> chip and not a bug in the code somewhere (host / fpga)?
>>>>>
>>>>> *"In terms of the rather-long transient time--is this only immediately
>>>>> after configuring the TX streamer, or for any TX burst? If it's just
>>>>> immediately*
>>>>> * after configuring a TX streamer, then this may be expected. If
>>>>> it's at the start of every burst, then something is very wrong. Again,
>>>>> I'm
>>>>> awaiting*
>>>>> * comment from someone in Ettus R&D."*
>>>>>
>>>>> This is at the start of *every* burst that is initiated when rx is
>>>>> running. Even when the tx_streamer is kept alive. Have you had a chance to
>>>>> run my example program, or modify the existing loopback example in the way
>>>>> I described in my previous email to reproduce the issue? I don't believe I
>>>>> am doing something that is incorrect, however, if I am, I would be happy
>>>>> to
>>>>> have someone point out my mistake.
>>>>>
>>>>> Best regards,
>>>>> Dominik
>>>>>
>>>>> On 04/06/2017 05:51 PM, Marcus D. Leech wrote:
>>>>>
>>>>> On 04/06/2017 05:07 AM, Dominik Eyerly wrote:
>>>>>
>>>>> I'm using 1M for both rx and tx. I've seen that example but it does
>>>>> not have the correct setup to display this behavior. As I mentioned
>>>>> before,
>>>>> the acquisition has to be running BEFORE transmit begins. In the example
>>>>> code there is no synchronization between rx start and tx start so you
>>>>> don't
>>>>> get to see the beginning of the transmit in the capture. I added a simple
>>>>> atomic bool to the example to ensure rx is running before tx starts. This
>>>>> is sufficient to display the issue. Also, the issue of having zeros in rx
>>>>> when creating a streamer will also not be displayed in this example code
>>>>> because the tx_streamer is created before the acquisition starts.
>>>>>
>>>>> Here is a plot of the txrx loopback example with my minor
>>>>> synchronization addition.
>>>>>
>>>>> http://imgur.com/a/0FjeI
>>>>>
>>>>> Would you be able to run the code that I posted in my previous email
>>>>> to see if you have the same issues on your end?
>>>>>
>>>>>
>>>>> cheers,
>>>>> dominik
>>>>>
>>>>> OK, so, with the zeros, I think I understand what's going on. When
>>>>> you create a new streamer, the hardware has to be configured to the new
>>>>> state.
>>>>> In the case of the AD9361, this means the data path between the
>>>>> AD9361 and the FPGA, which unavoidably means that the RX samples are
>>>>> interrupted
>>>>> while the interface is reconfigured. I believe this is the reason
>>>>> for a lump of zeros when you configure for TX--someone in engineering can
>>>>> correct
>>>>> my understanding if it's wrong.
>>>>>
>>>>>
>>>>> In terms of the rather-long transient time--is this only immediately
>>>>> after configuring the TX streamer, or for any TX burst? If it's just
>>>>> immediately
>>>>> after configuring a TX streamer, then this may be expected. If it's
>>>>> at the start of every burst, then something is very wrong. Again, I'm
>>>>> awaiting
>>>>> comment from someone in Ettus R&D.
>>>>>
>>>>>
>>>>>
>>>>> On 04/06/2017 04:10 AM, Marcus D. Leech wrote:
>>>>>
>>>>> On 04/05/2017 10:18 AM, Dominik Eyerly wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> UHD: linux; GNU C++ version 5.2.1 20151005; Boost_106100;
>>>>> UHD_3.11.0.git-release, compiled for ARM
>>>>> B205 running on USB3.
>>>>>
>>>>> Doesn't matter if the port is terminated or if it has a signal, recv
>>>>> returns hard 0s, (not 1e-10 or the like) when a tx streamer is created.
>>>>> I've uploaded a simple bit of code that illustrates the behavior quite
>>>>> clearly.
>>>>>
>>>>> https://pastebin.com/ZAccunUe
>>>>>
>>>>> Please note that this code assumes you have 20dB of attenuation
>>>>> between rx and tx. However you can adjust the gain values appropriately
>>>>> if
>>>>> you do not.
>>>>>
>>>>> I compiled with: g++ streamissue.cpp -o streamtest -lboost_thread
>>>>> -lboost_system -luhd
>>>>>
>>>>> But honestly, this issue is not my primary concern. My primary concern
>>>>> is the ramp behavior. Note that the code I posted also illustrates the
>>>>> ramping behavior. For this it needs to be in loopback with 20dB
>>>>> attenuation
>>>>> (or more). I included a little helper function which performs a quick
>>>>> dump
>>>>> to a python file. If you have matplotlib for python you can uncomment the
>>>>> "dump_to_py" line in the rx thread and then simply run the generated file
>>>>> with python to see a quick plot of the iq data.
>>>>>
>>>>> What else could I do to further troubleshoot this?
>>>>>
>>>>> cheers,
>>>>> Dominik
>>>>>
>>>>> There is an example program, called txrx_loopback_to_file that does
>>>>> something similar to your test.
>>>>>
>>>>> I wonder if it would be possible to do your tests with that, and see
>>>>> if there is any change in behavior.
>>>>>
>>>>> Also, what sample rates are you using?
>>>>>
>>>>>
>>>>>
>>>>> On 04/05/2017 02:25 PM, Marcus D. Leech wrote:
>>>>>
>>>>> On 04/05/2017 05:57 AM, Dominik Eyerly wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Thanks for the reply. I should add I am doing this test at 3.8G.
>>>>>
>>>>> Response to (A)
>>>>>
>>>>> Are you saying that regardless of my tx gain setting, I need 40dB of
>>>>> attenuation? I believe at max tx gain the board outputs around 10-15dBm
>>>>> @3.8G. I currently have a 6dB pad on tx port, cabled to a splitter which
>>>>> is
>>>>> cabled to the rx port with an inline 10dB pad. The other splitter port is
>>>>> going directly into my VSA. Also, my tx gain is around 50dB. My
>>>>> understanding was that the max input power of the rx port is -15dBm. With
>>>>> this configuration I should be well under that, as shown on my VSA capture
>>>>> (~-35dBm).
>>>>>
>>>>> Response to (B)
>>>>>
>>>>> According to the rough specifications posted here:
>>>>> https://kb.ettus.com/B200/B210/B200mini/B205mini#RF_Specifications
>>>>>
>>>>> The IIP3 is -15dBm. As you can see on my VSA capture, it received
>>>>> -35dBm and that doesn't even include the extra 10dB pad on the ettus rx
>>>>> port. I should be good on linearity, should I not? The reason the power
>>>>> capture looks so wavy is probably because I have the LO's tuned to the
>>>>> same
>>>>> spot. When I move tx off by 100kHz the capture looks "nicer" but the ramp
>>>>> up behavior is still there. Also, on the link I posted above, the max
>>>>> input
>>>>> power is called out as 0 dBm... is that correct?
>>>>>
>>>>> Could you provide some input on the questions I brought up in my
>>>>> previous email? Namely:
>>>>>
>>>>> (1) recv returning 0s when a tx_streamer is created while receiving
>>>>> continuously.
>>>>>
>>>>> Could you try a simple experiment here? Place a terminator on the
>>>>> input to the RX side, and see if you get 0s in the recv buffer. I want to
>>>>> distinguish
>>>>> between an analog situation and a digital one.
>>>>>
>>>>> (2) The ramp up behavior that is only present when transmitting during
>>>>> an active acquisition.
>>>>>
>>>>> That's odd. What version of UHD are you using?
>>>>>
>>>>>
>>>>> I also want to mention that the first burst of power in my captures
>>>>> coincides with changing the frequency of the tx LO. This triggers an
>>>>> internal calibration of the AD chip which in turn outputs this brief
>>>>> burst.
>>>>> So at least this mystery is solved. I am curious, however, is it possible
>>>>> to allow the chip to perform its cal without actually seeing this signal
>>>>> at
>>>>> the tx port?
>>>>>
>>>>> I'm not certain of exactly how it performs its calibration, but likely
>>>>> there will always be some leakage when it is doing so.
>>>>>
>>>>>
>>>>> cheers,
>>>>> Dominik
>>>>>
>>>>> On 04/04/2017 04:54 PM, [email protected] wrote:
>>>>>
>>>>> How are you doing the physical loop-back? If directly-cabled, you'll
>>>>> need about 40dB of attenuation in-line, to keep the receiver from:
>>>>>
>>>>> (A) Being damaged
>>>>>
>>>>> (B) Remaining linear
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2017-04-04 09:14, Dominik Eyerly via USRP-users wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>>
>>>>>
>>>>> My questions concern the B205i. I've uploaded some pictures to
>>>>> simplify the explaining process.
>>>>>
>>>>> http://imgur.com/a/XMAv6
>>>>>
>>>>> Basically, I want to transmit and receive a FSK waveform on one board
>>>>> (loopback). This means I've tuned both LOs to the same frequency. I've
>>>>> also
>>>>> inserted a splitter to be able to look at the signal on my VSA. This has
>>>>> allowed me to identify several problems.
>>>>>
>>>>>
>>>>>
>>>>> Let's start on the left:
>>>>> (B205i Receive - no zeros)
>>>>> Here you see the received power drop from the noise floor to -infinity
>>>>> because the rx_streamer was returning 0's. I've tracked this problem to
>>>>> the
>>>>> creation of a tx_streamer while an acquisition is running. This seems
>>>>> completely unacceptable; that calling a command on a chain (tx) that has
>>>>> nothing to do with rx, has an effect on rx. I could understand that the
>>>>> sample rate performance of rx is affected because they share a
>>>>> communication link, but not to actually alter the data that is returned by
>>>>> the recv call. Is this a known bug? Is there a workaround other than
>>>>> "don't
>>>>> do that"? Is this bug slated for a fix next release?
>>>>>
>>>>>
>>>>>
>>>>> Next:
>>>>> Right after all of the 0's, a strong but brief tone is blasted into
>>>>> the tx path. The power of this tone is not affected by the tx gain
>>>>> setting.
>>>>> This is quite a significant problem because we may use this module to test
>>>>> sensitive devices that may not be able to withstand such a transient. Any
>>>>> idea what is causing this? Again, any workarounds or fixes known?
>>>>>
>>>>>
>>>>>
>>>>> I don't care much for the spur at -83dBm. But it would be interesting
>>>>> to understand it.
>>>>>
>>>>>
>>>>>
>>>>> Lastly:
>>>>> The actual waveform is transmitted. Since this is an FSK waveform, I
>>>>> would expect a constant power envelope. Unfortunately, what I capture with
>>>>> the B205i is not even close. I performed the test again, but this time
>>>>> transmitting 200ms of 0s before my actual FSK waveform. You can still see
>>>>> the "warm up" looking behavior, however, by the time the actual waveform
>>>>> hits, the output seems settled. Is that what is happening (warm up)?
>>>>> Preloading every waveform with 200ms of zeroes is extremely undesirable.
>>>>> Is
>>>>> there a way to keep the chip always ready to go from both a Rx and Tx
>>>>> perspective?
>>>>>
>>>>>
>>>>>
>>>>> Tx only with no zeros:
>>>>> I performed the no zeros test again, this time without doing an
>>>>> acquisition with the B205i. Now the warm up behavior is completely gone.
>>>>> Why is Rx influencing the Tx RF performance?
>>>>>
>>>>>
>>>>>
>>>>> Any insight into these issues I am experiencing would be very
>>>>> appreciated.
>>>>>
>>>>> Best regards,
>>>>> Dominik
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>>> Email: [email protected]
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>>> use of the individual or entity to which it is addressed, and which may
>>>>> contain information that is privileged, confidential, and/or otherwise
>>>>> exempt from disclosure under applicable law. If the reader of this
>>>>> message is not the intended recipient, any disclosure, dissemination,
>>>>> distribution, copying or other use of this communication or its substance
>>>>> is prohibited. If you have received this communication in error, please
>>>>> contact us immediately. Thank you.
>>>>>
>>>>> _______________________________________________ USRP-users mailing
>>>>> list [email protected] http://lists.ettus.com/mailman
>>>>> /listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>> --
>>>>>
>>>>> --
>>>>>
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>>> Email: [email protected]
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>>> use of the individual or entity to which it is addressed, and which may
>>>>> contain information that is privileged, confidential, and/or otherwise
>>>>> exempt from disclosure under applicable law. If the reader of this
>>>>> message is not the intended recipient, any disclosure, dissemination,
>>>>> distribution, copying or other use of this communication or its substance
>>>>> is prohibited. If you have received this communication in error, please
>>>>> contact us immediately. Thank you.
>>>>>
>>>>> --
>>>>>
>>>>> --
>>>>>
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>>> Email: [email protected]
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>>> use of the individual or entity to which it is addressed, and which may
>>>>> contain information that is privileged, confidential, and/or otherwise
>>>>> exempt from disclosure under applicable law. If the reader of this
>>>>> message is not the intended recipient, any disclosure, dissemination,
>>>>> distribution, copying or other use of this communication or its substance
>>>>> is prohibited. If you have received this communication in error, please
>>>>> contact us immediately. Thank you.
>>>>>
>>>>> --
>>>>>
>>>>> --
>>>>>
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>>> Email: [email protected]
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>>> use of the individual or entity to which it is addressed, and which may
>>>>> contain information that is privileged, confidential, and/or otherwise
>>>>> exempt from disclosure under applicable law. If the reader of this
>>>>> message is not the intended recipient, any disclosure, dissemination,
>>>>> distribution, copying or other use of this communication or its substance
>>>>> is prohibited. If you have received this communication in error, please
>>>>> contact us immediately. Thank you.
>>>>>
>>>>> --
>>>>>
>>>>> --
>>>>>
>>>>> i.A. Dominik Eyerly
>>>>> Software
>>>>>
>>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>>> Email: [email protected]
>>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>>> Gesch?ftsleitung: Michael Konrad
>>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>>> Ust-Id-Nr. DE 206693267
>>>>>
>>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>>
>>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>>> use of the individual or entity to which it is addressed, and which may
>>>>> contain information that is privileged, confidential, and/or otherwise
>>>>> exempt from disclosure under applicable law. If the reader of this
>>>>> message is not the intended recipient, any disclosure, dissemination,
>>>>> distribution, copying or other use of this communication or its substance
>>>>> is prohibited. If you have received this communication in error, please
>>>>> contact us immediately. Thank you.
>>>>>
>>>>> _______________________________________________ USRP-users mailing
>>>>> list [email protected] http://lists.ettus.com/mailman
>>>>> /listinfo/usrp-users_lists.ettus.com
>>>>
>>>> --
>>>>
>>>> --
>>>>
>>>> i.A. Dominik Eyerly
>>>> Software
>>>>
>>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>>> Email: [email protected]
>>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>>> *Support Telefon: +49 (0) 7732 9815 100
>>>> <+49%207732%209815100>*[email protected][image: sig]
>>>> Gesch?ftsleitung: Michael Konrad
>>>> Handelsregisternr: HRB 550593 in Freiburg
>>>> Ust-Id-Nr. DE 206693267
>>>>
>>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden
>>>> Dokumente, enthalten Informationen der Konrad GmbH und sind nur f?r die
>>>> adressierte Person bestimmt. Diese k?nnen vertraulich und/oder von
>>>> Ver?ffentlichungen ausgenommen sein. Das Kopieren und die Weitergabe an
>>>> nicht autorisierte Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie
>>>> haftbar gemacht werden. Falls Sie nicht der Empf?nger sind,
>>>> benachrichtigen Sie den Absender bitte umgehend. Danke
>>>>
>>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>>> it, contains information from Konrad GmbH, which is intended only for the
>>>> use of the individual or entity to which it is addressed, and which may
>>>> contain information that is privileged, confidential, and/or otherwise
>>>> exempt from disclosure under applicable law. If the reader of this message
>>>> is not the intended recipient, any disclosure, dissemination,
>>>> distribution, copying or other use of this communication or its substance
>>>> is prohibited. If you have received this communication in error, please
>>>> contact us immediately. Thank you.
>>>>
>>>> --
>>>
>>> --
>>>
>>> i.A. Dominik Eyerly
>>> Software
>>>
>>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>>> Email: [email protected]
>>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>>> *Support Telefon: +49 (0) 7732 9815 100
>>> <+49%207732%209815100>*[email protected][image: sig]
>>> Gesch?ftsleitung: Michael Konrad
>>> Handelsregisternr: HRB 550593 in Freiburg
>>> Ust-Id-Nr. DE 206693267
>>>
>>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den
>>> Absender bitte umgehend. Danke
>>>
>>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>>> it, contains information from Konrad GmbH, which is intended only for the
>>> use of the individual or entity to which it is addressed, and which may
>>> contain information that is privileged, confidential, and/or otherwise
>>> exempt from disclosure under applicable law. If the reader of this message
>>> is not the intended recipient, any disclosure, dissemination, distribution,
>>> copying or other use of this communication or its substance is prohibited.
>>> If you have received this communication in error, please contact us
>>> immediately. Thank you.
>>>
>>>
>>
>> --
>>
>>
>>
>> --
>>
>> i.A. Dominik Eyerly
>> Software
>>
>> Tel: +49 (0) 351 7958019 233 <+49%20351%207958019233>
>> Fax: +49 (0) 351 7958019 232 <+49%20351%207958019232>
>> Email: [email protected]
>> *Konrad GmbH ? Fritz-Reichle-Ring 12 ? D-78315
>> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
>> *Support Telefon: +49 (0) 7732 9815 100
>> <+49%207732%209815100>*[email protected][image: sig]
>> Gesch?ftsleitung: Michael Konrad
>> Handelsregisternr: HRB 550593 in Freiburg
>> Ust-Id-Nr. DE 206693267
>>
>> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anh?ngenden Dokumente,
>> enthalten Informationen der Konrad GmbH und sind nur f?r die adressierte
>> Person bestimmt. Diese k?nnen vertraulich und/oder von Ver?ffentlichungen
>> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte
>> Dritte sind verboten. F?r Zuwiderhandlungen k?nnen Sie haftbar gemacht
>> werden. Falls Sie nicht der Empf?nger sind, benachrichtigen Sie den Absender
>> bitte umgehend. Danke
>>
>> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany
>> it, contains information from Konrad GmbH, which is intended only for the
>> use of the individual or entity to which it is addressed, and which may
>> contain information that is privileged, confidential, and/or otherwise
>> exempt from disclosure under applicable law. If the reader of this message
>> is not the intended recipient, any disclosure, dissemination, distribution,
>> copying or other use of this communication or its substance is prohibited.
>> If you have received this communication in error, please contact us
>> immediately. Thank you.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/bcad427c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddojlpbmdhnigbcj.png
Type: image/png
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/bcad427c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 25204 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/bcad427c/attachment-0001.jpg>
------------------------------
Message: 5
Date: Wed, 24 May 2017 14:15:12 -0400 (EDT)
From: ROBIN TORTORA <[email protected]>
To: Kevin Krieger via USRP-users <[email protected]>, Kevin
Krieger <[email protected]>
Subject: Re: [USRP-users] Netgear 10GB switch XS728T
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The only thing that jumps out to me is they are all on the same subnet...
That is something I have typically avoided, but if you say it works in another
configuration, that may not be the issue...
> On May 24, 2017 at 12:12 PM Kevin Krieger via USRP-users
> <[email protected]> wrote:
>
> Hi all,
>
> I've got a predicament. Here's some background before I describe my
> problem:
> We purchased a Netgear xs728T 10GB switch in order to network 16 N200
> devices, as well as a processing computer (which has a 10G ethernet card).
> Our 16 N200 devices are going to be used in a radar configuration where they
> are all simultaneously either transmitting or receiving. They are all
> receiving coincident 10MHz and 1PPS signals from 2 octoclocks, which are both
> fed from a third clock to ensure coincident clocks. They are connected to the
> switch via cat6 cables ~7feet in length (this item:
> https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136
>
> https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136
> )
>
> The problem:
> During testing we've found that the example program tx_bursts, when run
> on one USRP at a time with a modest bandwidth, the "Waiting for async burst
> ack....failed" message appears about 75% of the time. If I try to use two or
> more USRPs at a time, then it appears every time.
> The line used for tx_bursts was typically something like this:
> ./tx_bursts --args="addr0=192.168.10.104" --freq 10e6 --rate=1e6
> --channels="0"
> for a one usrp test. For a multiple usrp test, I used lines like this:
> ./tx_bursts
> --args="addr0=192.168.10.101,addr1=192.168.10.102,addr2=192.168.10.103,addr3=192.168.10.100,addr4=192.168.10.112,addr5=192.168.10.113,addr6=192.168.10.114"
> --freq 10e6 --rate=1e6 --channels="0,1,2,3,4,5,6"
>
>
> Some evidence & information:
> We also have a 5 port 1G DLink DGS-1005G. We've tested 4 N200s with
> tx_bursts on this switch (same cabling) and it works flawlessly.
> We also have tested a second 10G switch, the 8 port XS708E with 7 N200s
> with tx_bursts and it works flawlessly.
>
> I have wireshark dumps taken via a third machine that is connected to
> mirrored ports on the xs728T switch. I have attached them in case anyone can
> tell me if they see something wrong besides the missing acks.
> The wireshark filter to use is : ip.src == 192.168.10.104 and ip.dst ==
> 192.168.10.104 or ip.src == 192.168.10.104 and ip.dst == 192.168.10.99
>
> The xs728t switch information is: Boot version is 1.0.0.0, SW version is
> 6.5.1.26 (latest as of testing).
> I contacted Netgear support, and they sent us a brand new switch, which
> exhibited the same problem.
>
> I'm wondering if there's anyone out there who has had similar issues? Is
> there anything I can do to get more information or get around this problem?
> Can anyone see what the root cause might be in the wireshark captures?
>
> Any help or pointers are appreciated. Thank you,
> Kevin
>
> _______________________________________________
> 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/38dbb37e/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 24 May 2017 18:25:43 +0000
From: carry chen <[email protected]>
To: "[email protected]" <[email protected]>, Jason Matusiak
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
Message-ID:
<sixpr06mb09058d4ebf5a6b7ab5e1d482dd...@sixpr06mb0905.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="iso-2022-jp"
Thanks!
I see b205mini have three sma port, one ??X/RX , one RX2, and one REF, does
external clock source connect to REF sma port?
Can you give me some tips where to buy the external clock source ?
Does external clock source connect to port direct and the uhd is support direct?
Have some body do that ?
Thank you very much again!
________________________________
From: [email protected] <[email protected]>
Sent: Wednesday, May 24, 2017 8:33:18 AM
To: Jason Matusiak
Cc: carry chen; [email protected]
Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
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]<mailto:[email protected]>
<[email protected]><mailto:[email protected]>
Sent: Tuesday, May 23, 2017 12:04 PM
To: carry chen
Cc: [email protected]<mailto:[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]<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/191e46d3/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 24 May 2017 18:14:04 +0000
From: Leandro Echevarr?a <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Using on-board DRAM on x310
Message-ID:
<CALEOA2gt1LmtPsX7+MhPa6yZtqo2pRT9RnuZ4p_mvc=cgfy...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey everyone,
As far as I'm concerned, the DMA FIFO included in the latest releases makes
use of the external DRAM module to act as a rather large I/O buffer. Is
there a way to also access the DRAM as temporary storage to write and read
signals at specified times? I'm using an x310, by the way.
Thanks in advance,
Leo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/e44d9a2c/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 24 May 2017 12:46:05 -0600
From: Steven Knudsen <[email protected]>
To: carry chen <[email protected]>
Cc: "[email protected]" <[email protected]>, Jason Matusiak
<[email protected]>, USRP-users
<[email protected]>
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
There are many options for 1 PPS or 10 MHz clock sources, it all depends on
where you live and how you want to get one.
You can, for example, get a GPS module from ublox, AdaFruit, SparkFun, or
Amazon and make your own SMA terminated cable to connect to the REF input on
the mini. You need to be sure that the signal levels are within spec as show on
the B200mini schematic, for example. It may mean making a level translating
circuit. Normally you want to match the 50 Ohm impedance, but it?s not critical
it?s exact as long as the thresholds are met.
https://files.ettus.com/schematics/b200mini/
<https://files.ettus.com/schematics/b200mini/>
Personally, I love my Octoclock G :-)
There is support for external sources in the UHD and there are example programs
in the source to show you how..
Good luck,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist zu
erreichen. - Franz Kafka
> On May 24, 2017, at 12:25, carry chen via USRP-users
> <[email protected]> wrote:
>
> Thanks!
>
> I see b205mini have three sma port, one ??X/RX , one RX2, and one REF, does
> external clock source connect to REF sma port?
> Can you give me some tips where to buy the external clock source ?
> Does external clock source connect to port direct and the uhd is support
> direct?
> Have some body do that ?
>
> Thank you very much again!
> From: [email protected] <mailto:[email protected]> <[email protected]
> <mailto:[email protected]>>
> Sent: Wednesday, May 24, 2017 8:33:18 AM
> To: Jason Matusiak
> Cc: carry chen; [email protected] <mailto:[email protected]>
> Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
>
> 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] <mailto:[email protected]> <[email protected]>
>>> <mailto:[email protected]>
>>> Sent: Tuesday, May 23, 2017 12:04 PM
>>> To: carry chen
>>> Cc: [email protected] <mailto:[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
>>> <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
>>> <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
>> <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
> <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/2bec8304/attachment-0001.html>
------------------------------
Message: 9
Date: Wed, 24 May 2017 19:25:25 +0000
From: carry chen <[email protected]>
To: Steven Knudsen <[email protected]>
Cc: "[email protected]" <[email protected]>, Jason Matusiak
<[email protected]>, USRP-users
<[email protected]>
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Message-ID:
<sixpr06mb0905e7f524eeb6a17891f2f1dd...@sixpr06mb0905.apcprd06.prod.outlook.com>
Content-Type: text/plain; charset="gb2312"
Steven,
Very?appreciate?for you message!
I will try it!
???nks all!
Carry
________________________________
From: Steven Knudsen <[email protected]>
Sent: Wednesday, May 24, 2017 11:46:05 AM
To: carry chen
Cc: [email protected]; Jason Matusiak; USRP-users
Subject: Re: [USRP-users] B205mini Frequency Accuracy
There are many options for 1 PPS or 10 MHz clock sources, it all depends on
where you live and how you want to get one.
You can, for example, get a GPS module from ublox, AdaFruit, SparkFun, or
Amazon and make your own SMA terminated cable to connect to the REF input on
the mini. You need to be sure that the signal levels are within spec as show on
the B200mini schematic, for example. It may mean making a level translating
circuit. Normally you want to match the 50 Ohm impedance, but it?s not critical
it?s exact as long as the thresholds are met.
https://files.ettus.com/schematics/b200mini/
Personally, I love my Octoclock G :-)
There is support for external sources in the UHD and there are example programs
in the source to show you how..
Good luck,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca<http://techconficio.ca>
www.linkedin.com/in/knudstevenknudsen<http://www.linkedin.com/in/knudstevenknudsen>
Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt ist zu
erreichen. - Franz Kafka
On May 24, 2017, at 12:25, carry chen via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Thanks!
I see b205mini have three sma port, one ??X/RX , one RX2, and one REF, does
external clock source connect to REF sma port?
Can you give me some tips where to buy the external clock source ?
Does external clock source connect to port direct and the uhd is support direct?
Have some body do that ?
Thank you very much again!
________________________________
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, May 24, 2017 8:33:18 AM
To: Jason Matusiak
Cc: carry chen; [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] Fw: B205mini Frequency Accuracy
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]<mailto:[email protected]>
<[email protected]><mailto:[email protected]>
Sent: Tuesday, May 23, 2017 12:04 PM
To: carry chen
Cc: [email protected]<mailto:[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]<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
_______________________________________________
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/be11e457/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 24 May 2017 16:00:25 -0400
From: Serge Malo <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300 with only one d/b
Message-ID:
<CAOhu+FMZ7CwwsgBtXzfauoCs1rdCZRMYm=_syfxzeq8kesk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hum, I was unable to reproduce the problem with a simple example.
I'll get back as soon as I understand the difference between my app and the
example.
__________________
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol <https://twitter.com/skydelsol>
On 24 May 2017 at 14:04, <[email protected]> wrote:
> Not sure what you mean by "consumed at the correct pace". The
> daughterboards are entirely analog, so "sample consumption" is much earlier
> in the chain.
>
> Perhaps you could share some code that demonstrates the issue? Maybe some
> spectral plots?
>
> What sample rate are you trying to use?
>
>
>
>
>
>
>
>
> On 2017-05-24 13:35, Serge Malo via USRP-users wrote:
>
> Hi all,
>
> We are using X300's with UHD coming from the maint branch, version of
> April 20th 2017. We wanted to use the latest version in order to support
> UBX-160 v2 d/b with all possible fixes in UHD.
>
> However, we have felt into a serious issue in TX when only one UBX d/b is
> present inside the X300:
> The IQ samples don't seem to be consumed at the correct pace. Also, the
> spectrum shape is incorrect and it is not consistent from one transmission
> to another.
>
> I would like to know if this is a known issue and if someone can confirm
> this problem.
> If so, is there a known workaround?
>
> Regards,
> Serge
>
>
> __________________
> *Serge Malo *
> CDO & Co-founder, Skydel Solutions
> Cell: 1-514-294-4017 <(514)%20294-4017>
> www.skydelsolutions.com
> Twitter: @skydelsol <https://twitter.com/skydelsol>
>
> _______________________________________________
> 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/514798b3/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 24 May 2017 22:07:08 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Netgear 10GB switch XS728T
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Kevin, Hi Robin,
the same-subnet configuration is the right one, here. There's no routing
ambiguity if you have one card that serves the whole switch.
Kevin, this might be much to ask, but: I'd ask you to both install
wireshark and its development headers (typically, wireshark-dev or
wireshark-devel) from your operating system's package manager.
Then, get the UHD source code, and
cd /path/to/uhd/tools/dissectors
mkdir build
cd build
cmake -DETTUS_DISSECTOR_NAME=zpu ..
make -j4 && make install
Ideally, add your user to the group that has access to the raw network
hardware (in case of my OS, that was the "wireshark" group), log out and
back in.
If that doesn't work, you have to record as root and analyze as your
user (the USRP protocol dissectors got installed to your home directory).
Then, record the traffic on your 10G interface, and analyze the packets
in question as UHD (some/many will be sample packets, i.e. CVITA).
Best regards,
Marcus
On 24.05.2017 20:15, ROBIN TORTORA via USRP-users wrote:
>
> The only thing that jumps out to me is they are all on the same subnet...
>
>
> That is something I have typically avoided, but if you say it works in
> another configuration, that may not be the issue...
>
>> On May 24, 2017 at 12:12 PM Kevin Krieger via USRP-users
>> <[email protected]> wrote:
>>
>> Hi all,
>>
>> I've got a predicament. Here's some *background* before I describe my
>> problem:
>> We purchased a Netgear xs728T 10GB switch in order to network 16 N200
>> devices, as well as a processing computer (which has a 10G ethernet
>> card). Our 16 N200 devices are going to be used in a radar
>> configuration where they are all simultaneously either transmitting
>> or receiving. They are all receiving coincident 10MHz and 1PPS
>> signals from 2 octoclocks, which are both fed from a third clock to
>> ensure coincident clocks. They are connected to the switch via cat6
>> cables ~7feet in length (this item:
>> https://www.newegg.ca/Product/Product.aspx?Item=N82E16812119168&_ga=2.227605844.817843194.1495640587-1295759170.1493911136)
>>
>> *The problem:*
>> During testing we've found that the example program tx_bursts, when
>> run on one USRP at a time with a modest bandwidth, the "Waiting for
>> async burst ack....failed" message appears about 75% of the time. If
>> I try to use two or more USRPs at a time, then it appears every time.
>> The line used for tx_bursts was typically something like
>> this:./tx_bursts --args="addr0=192.168.10.104" --freq 10e6 --rate=1e6
>> --channels="0"
>> for a one usrp test. For a multiple usrp test, I used lines like
>> this:./tx_bursts
>> --args="addr0=192.168.10.101,addr1=192.168.10.102,addr2=192.168.10.103,addr3=192.168.10.100,addr4=192.168.10.112,addr5=192.168.10.113,addr6=192.168.10.114"
>> --freq 10e6 --rate=1e6 --channels="0,1,2,3,4,5,6"
>>
>>
>> *Some evidence & information:
>> *We also have a 5 port 1G DLink DGS-1005G. We've tested 4 N200s with
>> tx_bursts on this switch (same cabling) and it works flawlessly.
>> We also have tested a second 10G switch, the 8 port XS708E with 7
>> N200s with tx_bursts and it works flawlessly.
>>
>> I have wireshark dumps taken via a third machine that is connected to
>> mirrored ports on the xs728T switch. I have attached them in case
>> anyone can tell me if they see something wrong besides the missing acks.
>> The wireshark filter to use is : ip.src == 192.168.10.104 and ip.dst
>> == 192.168.10.104 or ip.src == 192.168.10.104 and ip.dst == 192.168.10.99
>>
>> The xs728t switch information is: Boot version is 1.0.0.0, SW version
>> is 6.5.1.26 (latest as of testing).
>> I contacted Netgear support, and they sent us a brand new switch,
>> which exhibited the same problem.
>>
>> I'm wondering if there's anyone out there who has had similar issues?
>> Is there anything I can do to get more information or get around this
>> problem?
>> Can anyone see what the root cause might be in the wireshark captures?
>>
>> Any help or pointers are appreciated. Thank you,
>> Kevin
>
>
>
>
>> _______________________________________________
>> 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/4da4e82b/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 24 May 2017 22:10:51 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B205mini Frequency Accuracy
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Carry,
I'd still light to highlight the question the other Marcus asked:
It's not very usual that an application needs such a high-quality clock
source. Since no two oscillators in this universe are exactly the same,
all practical receivers have some way to account (and often: correct) a
clock offset! So, before you spend money, ask yourself if your
application wouldn't need to implement something like that, anyways!
So: what is the reason the on-board oscillator isn't good enough for you?
Best regards,
Marcus
On 24.05.2017 21:25, carry chen via USRP-users wrote:
>
> Steven,
>
>
> Very?appreciate?for you message!
>
> I will try it!
>
>
> ???nks all!
>
>
> Carry
>
> ------------------------------------------------------------------------
> *From:* Steven Knudsen <[email protected]>
> *Sent:* Wednesday, May 24, 2017 11:46:05 AM
> *To:* carry chen
> *Cc:* [email protected]; Jason Matusiak; USRP-users
> *Subject:* Re: [USRP-users] B205mini Frequency Accuracy
>
> There are many options for 1 PPS or 10 MHz clock sources, it all
> depends on where you live and how you want to get one.
>
> You can, for example, get a GPS module from ublox, AdaFruit, SparkFun,
> or Amazon and make your own SMA terminated cable to connect to the REF
> input on the mini. You need to be sure that the signal levels are
> within spec as show on the B200mini schematic, for example. It may
> mean making a level translating circuit. Normally you want to match
> the 50 Ohm impedance, but it?s not critical it?s exact as long as the
> thresholds are met.
>
> https://files.ettus.com/schematics/b200mini/
>
> Personally, I love my Octoclock G :-)
>
> There is support for external sources in the UHD and there are example
> programs in the source to show you how..
>
> Good luck,
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
> /Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt
> ist zu erreichen. - Franz Kafka/
>
>> On May 24, 2017, at 12:25, carry chen via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Thanks!
>>
>> I see b205mini have three sma port, one ??X/RX , one RX2, and one
>> REF, does external clock source connect to REF sma port?
>> Can you give me some tips where to buy the external clock source ?
>> Does external clock source connect to port direct and the uhd is
>> support direct?
>> Have some body do that ?
>>
>> Thank you very much again!
>> ------------------------------------------------------------------------
>> *From:* [email protected]
>> <mailto:[email protected]> <[email protected] <mailto:[email protected]>>
>> *Sent:* Wednesday, May 24, 2017 8:33:18 AM
>> *To:* Jason Matusiak
>> *Cc:* carry chen; [email protected]
>> <mailto:[email protected]>
>> *Subject:* Re: [USRP-users] Fw: B205mini Frequency Accuracy
>>
>> 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] <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
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> 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/b5d8eabb/attachment-0001.html>
------------------------------
Message: 13
Date: Wed, 24 May 2017 23:44:19 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] About Self calibration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Jon!
um,
On 24.05.2017 04:51, liu Jong via USRP-users wrote:
> Error: RuntimeError: self_cal_adc_capture_delay: Self calibration
> failed. Convergence error.
isn't very good. but: The only time I've seen that was when someone had
overwritten the hardware revision number in EEPROM with a value that
doesn't apply to the hardware.
Can you share what the sticker at the highlighted position says? We
should be able to figure out the right revision of the hardware!
Revision Sticker Placement
Then, find usrp_burn_mb_eeprom, and run it "/path/to/usrp_burn_mb_eeprom
--args addr=192.168.40.2 --read-all" (replace the addr=x.x.x.x with the
IP address of your USRP). What does the revision eeprom content say?
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/85c08bf7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RevisionStickerPlacementSmall.jpg
Type: image/jpeg
Size: 22621 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/85c08bf7/attachment-0001.jpg>
------------------------------
Message: 14
Date: Thu, 25 May 2017 00:00:33 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B200mini GPIO input
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi,
http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a57f25d118d20311aca261e6dd252625e
Best regards,
Marcus
On 24.05.2017 05:46, Xingjian Chen via USRP-users wrote:
> Hi,
> Do you know how to configure some of GPIO ports as inputs and some as
> outputs for b200mini?
> Thank you very much.
>
>
> _______________________________________________
> 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/20170525/798548af/attachment-0001.html>
------------------------------
Message: 15
Date: Wed, 24 May 2017 17:28:13 -0700
From: Michael West <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B200mini GPIO input
Message-ID:
<CAM4xKrrG5zt=BwaKmMcucfzkv+26-MLeJZJcVLP=saq-d+q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Also, see the GPIO example:
https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
Regards,
Michael
On Wed, May 24, 2017 at 3:00 PM, Marcus M?ller via USRP-users <
[email protected]> wrote:
> Hi,
>
>
> http://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#
> a57f25d118d20311aca261e6dd252625e
>
> Best regards,
> Marcus
>
>
>
> On 24.05.2017 05:46, Xingjian Chen via USRP-users wrote:
>
> Hi,
> Do you know how to configure some of GPIO ports as inputs and some as
> outputs for b200mini?
> Thank you very much.
>
>
> _______________________________________________
> 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/20170524/0828e5a2/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 24 May 2017 17:38:45 -0700
From: Michael West <[email protected]>
To: Bob <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] In URSP B210, how to deal with the signal in
real time?
Message-ID:
<CAM4xKroHvUz2tGw-8xafR=okmpb551e5l2vxte1d8dd20wd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Bob,
Clearly something in Fig. 2 is back pressuring to the point data is
overflowing in the device. My suggestion is to disable all components in
Fig.2 that are not in Fig. 1 and then enable them one at a time (using a
Null Sink where necessary) to see which block may be causing the back
pressure.
Regards,
Michael
On Mon, May 22, 2017 at 5:05 AM, Bob via USRP-users <
[email protected]> wrote:
>
>
> Hello,
> Fig.1
> fig.2
> Under the same experimental conditions, Figure 1 can get a complete
> signal, but Figure 2 can only get a part. For example, the signal sent by
> the 200 MB, Figure 1 obtained data is 200 MB, and Figure 2 only 10 MB or
> so, why is this?
> In fig.2, "t and v esti cc", "viterbi ci" and "test crc ii" are the main
> signal processing modules for our system. The USRP is B210. The "O" appear
> in the console output. But we want to deal with the signal in real time,
> what should we do? And how can we fully receive the signal, and does not
> appear the "O"?
> IF we receive the signal use fig.1, and replace "USRP Source" with "file
> source" in fig.2, we can get the result for our signals. How do I get the
> same result with "USRP Source"?
> Figure 2 has more modules than the fig.1, whether the processing speed of
> these modules affect the speed of the received signal of "file sink", if we
> want to receive as many signals, how to do it?
> In GNU Radio, we build a system, firstly, we save the signal in a file, at
> the same time, read the data from the same file to process, you can do so?
> If it can, which block can be achieved?
>
> Thank you very much for your answers. I am looking forward to your reply
> as soon as possible and as detailed as possible.
> Thanks!
>
> Bob
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/930d7264/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??2.png
Type: image/png
Size: 122404 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/930d7264/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??1.png
Type: image/png
Size: 69949 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170524/930d7264/attachment-0003.png>
------------------------------
Message: 17
Date: Thu, 25 May 2017 09:11:44 +0800
From: liu Jong <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UBX160 and TrinRx on one X310
Message-ID:
<caeui2n3+fi5tri4bwlab_kycj9pd4hbqpty0zb_yvzr8opb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI,Derek,
If we need't receive three time aligned sample streams,and just receive in
3 RX?is it possible?
best regards
Jon
2017-05-23 16:04 GMT+08:00 liu Jong <[email protected]>:
> Derek,
> thank you.
>
> 2017-05-23 15:39 GMT+08:00 Derek Kozel <[email protected]>:
>
>> Hello Jon,
>>
>> Currently it is not possible to receive three time aligned sample streams
>> in that configuration. You can use the TwinRX or the UBX separately. We
>> hope to change that in the future but do not have a time estimate for
>> adding that feature.
>>
>> Regards,
>> Derek
>>
>> On Tue, May 23, 2017 at 2:39 AM, liu Jong via USRP-users <
>> [email protected]> wrote:
>>
>>> Dear all,
>>> Can we use UBX160 and TrinRx on one X310 and achieve 3 RX and 1 TX?
>>>
>>> thank you.
>>>
>>> best regards
>>> Jon
>>>
>>> _______________________________________________
>>> 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/20170525/d6a75b68/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 25 May 2017 09:55:10 +0800
From: liu Jong <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] About Self calibration
Message-ID:
<CAEui2n37hoZPzfM_f8-ZnY_gpjLZ=qhbsbk_vjcukz1amjj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI,Marcus,
information as below:
a sticker near the AUX I/O:
*154573H-02L*
then run usrp_burn_mb_eeprom:
/usr/local/lib/uhd/utils$ ./usrp_burn_mb_eeprom --args="addr=192.168.10.2,
type=x300" --read-all
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.001.HEAD-0-g945fd653
Creating USRP device from address: addr=192.168.10.2, type=x300
-- 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: 1185.4MB/s)
-- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1171.2MB/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.
will be some hardware broken?Can we start RMA?
thank you.
best regards
Jon
2017-05-25 5:44 GMT+08:00 Marcus M?ller via USRP-users <
[email protected]>:
> Hi Jon!
> um,
> On 24.05.2017 04:51, liu Jong via USRP-users wrote:
>
> Error: RuntimeError: self_cal_adc_capture_delay: Self calibration failed.
> Convergence error.
>
> isn't very good. but: The only time I've seen that was when someone had
> overwritten the hardware revision number in EEPROM with a value that
> doesn't apply to the hardware.
>
> Can you share what the sticker at the highlighted position says? We should
> be able to figure out the right revision of the hardware!
>
> [image: Revision Sticker Placement]
>
> Then, find usrp_burn_mb_eeprom, and run it "/path/to/usrp_burn_mb_eeprom
> --args addr=192.168.40.2 --read-all" (replace the addr=x.x.x.x with the IP
> address of your USRP). What does the revision eeprom content say?
>
> Best regards,
> Marcus
>
> _______________________________________________
> 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/20170525/7247342f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RevisionStickerPlacementSmall.jpg
Type: image/jpeg
Size: 22621 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170525/7247342f/attachment-0001.jpg>
------------------------------
Message: 19
Date: Thu, 25 May 2017 06:05:26 -0400
From: Serge Malo <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300 with only one d/b
Message-ID:
<CAOhu+FNOyxXX5zbQUro4TCH+3nMM3dPd5ab2xd=6fd3bgwb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ok, I have found the source of the problem, it was on my side this time,
sorry for this.
Regards,
Serge
__________________
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol <https://twitter.com/skydelsol>
On 24 May 2017 at 16:00, Serge Malo <[email protected]> wrote:
> Hum, I was unable to reproduce the problem with a simple example.
> I'll get back as soon as I understand the difference between my app and
> the example.
>
> __________________
> *Serge Malo *
> CDO & Co-founder, Skydel Solutions
> Cell: 1-514-294-4017 <(514)%20294-4017>
> www.skydelsolutions.com
> Twitter: @skydelsol <https://twitter.com/skydelsol>
>
> On 24 May 2017 at 14:04, <[email protected]> wrote:
>
>> Not sure what you mean by "consumed at the correct pace". The
>> daughterboards are entirely analog, so "sample consumption" is much earlier
>> in the chain.
>>
>> Perhaps you could share some code that demonstrates the issue? Maybe
>> some spectral plots?
>>
>> What sample rate are you trying to use?
>>
>>
>>
>>
>>
>>
>>
>>
>> On 2017-05-24 13:35, Serge Malo via USRP-users wrote:
>>
>> Hi all,
>>
>> We are using X300's with UHD coming from the maint branch, version of
>> April 20th 2017. We wanted to use the latest version in order to support
>> UBX-160 v2 d/b with all possible fixes in UHD.
>>
>> However, we have felt into a serious issue in TX when only one UBX d/b is
>> present inside the X300:
>> The IQ samples don't seem to be consumed at the correct pace. Also, the
>> spectrum shape is incorrect and it is not consistent from one transmission
>> to another.
>>
>> I would like to know if this is a known issue and if someone can confirm
>> this problem.
>> If so, is there a known workaround?
>>
>> Regards,
>> Serge
>>
>>
>> __________________
>> *Serge Malo *
>> CDO & Co-founder, Skydel Solutions
>> Cell: 1-514-294-4017 <(514)%20294-4017>
>> www.skydelsolutions.com
>> Twitter: @skydelsol <https://twitter.com/skydelsol>
>>
>> _______________________________________________
>> 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/20170525/3af362d8/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 25 May 2017 07:43:57 -0400
From: "Marcus D. Leech" <[email protected]>
To: Serge Malo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300 with only one d/b
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 05/25/2017 06:05 AM, Serge Malo wrote:
> Ok, I have found the source of the problem, it was on my side this
> time, sorry for this.
>
> Regards,
> Serge
>
>
Happy that you were able to resolve it.
> __________________
> *Serge Malo *
> CDO & Co-founder, Skydel Solutions
> Cell: 1-514-294-4017
> www.skydelsolutions.com <http://www.skydelsolutions.com/>
> Twitter: @skydelsol <https://twitter.com/skydelsol>
>
> On 24 May 2017 at 16:00, Serge Malo <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hum, I was unable to reproduce the problem with a simple example.
> I'll get back as soon as I understand the difference between my
> app and the example.
>
> __________________
> *Serge Malo *
> CDO & Co-founder, Skydel Solutions
> Cell: 1-514-294-4017 <tel:%28514%29%20294-4017>
> www.skydelsolutions.com <http://www.skydelsolutions.com/>
> Twitter: @skydelsol <https://twitter.com/skydelsol>
>
> On 24 May 2017 at 14:04, <[email protected]
> <mailto:[email protected]>> wrote:
>
> Not sure what you mean by "consumed at the correct pace". The
> daughterboards are entirely analog, so "sample consumption" is
> much earlier in the chain.
>
> Perhaps you could share some code that demonstrates the
> issue? Maybe some spectral plots?
>
> What sample rate are you trying to use?
>
> On 2017-05-24 13:35, Serge Malo via USRP-users wrote:
>
>> Hi all,
>> We are using X300's with UHD coming from the maint branch,
>> version of April 20th 2017. We wanted to use the latest
>> version in order to support UBX-160 v2 d/b with all possible
>> fixes in UHD.
>> However, we have felt into a serious issue in TX when only
>> one UBX d/b is present inside the X300:
>> The IQ samples don't seem to be consumed at the correct pace.
>> Also, the spectrum shape is incorrect and it is not
>> consistent from one transmission to another.
>> I would like to know if this is a known issue and if someone
>> can confirm this problem.
>> If so, is there a known workaround?
>> Regards,
>> Serge
>> __________________
>> *Serge Malo *
>> CDO & Co-founder, Skydel Solutions
>> Cell: 1-514-294-4017 <tel:%28514%29%20294-4017>
>> www.skydelsolutions.com <http://www.skydelsolutions.com/>
>> Twitter: @skydelsol <https://twitter.com/skydelsol>
>>
>> _______________________________________________
>> 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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170525/573acc8e/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 25
******************************************
