[USRP-users] Fwd: Please add me to the mail list

2019-03-21 Thread Armin Schmidt via USRP-users
Hallo Diogo,
I had the same Problem. You get no sending-confirmation from the
mailing-list and you don't get your own message from the mailing list.
Unfortunately even the support of Ettus didn't know that an couldn't
helped me. I've had to use a second Mail, to find this out :/

@Ettus: would be great to change this behaviour!

So everything is fine, even when a normal forum would be much more
structured and helpful than a mailing-list.

Am 21.03.19 um 11:05 schrieb Piotr Krysik via USRP-users:
> W dniu 21.03.2019 o 10:58, Diogo Botelho Ribeiro Marinho via USRP-users
> pisze:
>> I am using N310 and i would like to send my questions to the forum.
>>
>>  
>>
>> So far i am not able to do it.
>>
>>  
>>
>>
> Hi Diogo,
>
> I beg to disagree. From my perspective it looks that you are able to
> send posts to the mailing-list.
>
> I can even see your post from two days ago (without its subject however).
>
> --
> Best Regards,
> Piotr Krysik
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com



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


Re: [USRP-users] Phase drift issue of N310

2019-03-21 Thread Marcus D. Leech via USRP-users

On 03/21/2019 07:08 AM, Damon wrote:

Hi Marcus,

Thank you for your reply.

I compared the USRP configuration of your grc file with that of mine. 
I found that the key to solve this issue is set_time_next_pps or 
set_time_unknow_pps should be called.


I don't know why   those two functions have an effect on phase error. 
I haven't found any special description of these two functions in the 
N310 manual.


Best regards,

Damon
They'll have an effect on initial phase error, because each half of the 
N310 has its own timekeeper.  If those aren't brought into alignment, then
  the sample streams will be unaligned.  But that should have no effect 
on ongoing phase drift--ONLY on initial phase error.





On 2019/3/21 上午1:07, Marcus D. Leech wrote:

On 03/20/2019 12:55 PM, Damon wrote:

Hi Marcus,

Thanks for your reply.

Yes, it happen with any other frequency changes, not only 460.01M 
and 469.03Mhz.


I'm building a 4-channel coherent receiving system with n310. It 
needs to compensate the phase errors of multiple receiving channels. 
So I need to measure the phase errors first and then compensate 
them. But in the range of 100MHz bandwidth (from center_freq-50MHz 
to  center_freq+50MHz), the phase difference of two receiving 
channels of different dboards varies too much with frequency, so 
it's very difficult to compensate the phase errors. As a contrast, 
the phase errors of the two receiving channels of X310 with ubx vary 
very samll with frequency, so it is easy to compensate the phase 
difference.


Looking forward to your test results

Best regards,

Damon

I used the attached script.

Now, I'm only looking at +/- 2MHz, rather than your 100Mhz bandwidth.

I found that the phase noise and offset did not change noticably 
tuning across the entire 4Mhz band.  I don't have a machine fast 
enough here to
  sweep my TX across 100Mhz, but with the N310 RX at a fixed tuning, 
and sweeping the TX (in this case, a Marconi transceiver test set), I 
did not see
  any significant phase shift or change in mutual phase noise as the 
TX swept across the 4MHz band.





On 2019/3/20 上午10:40, Marcus D. Leech wrote:

On 03/19/2019 09:12 PM, Damon wrote:

Hi Marcus,

The phase  responses of two channels of different dboards 
(ubx-160) in  a X310  are very consistent. When the frequency of 
transmitting signal changes from 460.01MHz to 460.03Mhz, the phase 
difference between two RX channels of different dboards in X310 
remains unchanged. But for the phase difference between two RX 
channels of different dboards of N310,  there are dozens or 
hundreds degree of changes.


Can you try to reproduce the test and help me to figure out how to 
solve it?
I'm not sure if it's a hardware bug, a driver bug or USRP setup 
problem.
I cannot imagine a hardware or driver bug that could produce this 
behavior.  It would mean that the receiver was somehow changing LO

  frequency when the TX frequency changed.

Does this happen with *other* frequency changes, or just 
460.01<--->460.03.  I wonder if you have an interfering signal that 
is being
  "uncovered" by TX frequency change, and you're simply measuring 
that interfering signal?


The only other thing that occurs to me is filtering that is 
extremely non-linear phase.  But that would create such a mess that 
most applications

  would likely not work--clearly they do.

I can try to reproduce in my lab tomorrow, but, like the last tests 
I did, I very much expect to not be able to reproduce.





Best regards,
Damon
On 2019/3/19 上午6:10, Marcus D. Leech wrote:

On 03/18/2019 01:26 PM, Damon wrote:

Hi Marcus,

Sorry, I can't reproduce the first observation in this 
discussion thread. A new problem about phase response has arisen.
I am testing the phase coherence performance of four receiving 
channels of N310. A B200 is transmitting single tone continuous 
wave to a one to four splitter. The 4 outputs of the splitter 
are connected to 4 RX channels of N310. Attached please find the 
GRC file of this test.


The RX frequency of 4 channels of  N310 is set to 460MHz, and 
keep running in the test.


The TX frequency of B200 is set to 460.02MHz first, and then to 
460.03MHz. I thought the phase difference between different 
dboards would change very little when the signal frequency 
difference is very small, similar to the performance of X310. 
However, the fact is that the phase difference between the two 
dboards of N310 varies considerably with the signal frequency 
transmission. For example, in the attached picture, when the 
signal frequency is 460.01MHz, the phase difference between 
channel 2 and channel 0 is -118 degrees, the phase difference 
between channel 1 and channel 0 is 0 degrees; when the 
transmission frequency is adjusted to 460.03MHz, the phase 
difference between channel 2 and channel 0 is 117 degrees, and 
the phase difference between channel 1 and channel 0 is 0 
degrees. It is very difficult to understand that the phase 
difference of two receiving channels 

Re: [USRP-users] Phase drift issue of N310

2019-03-21 Thread Damon via USRP-users

Hi Marcus,

Thank you for your reply.

I compared the USRP configuration of your grc file with that of mine. I 
found that the key to solve this issue is set_time_next_pps or 
set_time_unknow_pps should be called.


I don't know why   those two functions have an effect on phase error. I 
haven't found any special description of these two functions in the N310 
manual.


Best regards,

Damon

On 2019/3/21 上午1:07, Marcus D. Leech wrote:

On 03/20/2019 12:55 PM, Damon wrote:

Hi Marcus,

Thanks for your reply.

Yes, it happen with any other frequency changes, not only 460.01M and 
469.03Mhz.


I'm building a 4-channel coherent receiving system with n310. It 
needs to compensate the phase errors of multiple receiving channels. 
So I need to measure the phase errors first and then compensate them. 
But in the range of 100MHz bandwidth (from center_freq-50MHz to  
center_freq+50MHz), the phase difference of two receiving channels of 
different dboards varies too much with frequency, so it's very 
difficult to compensate the phase errors. As a contrast, the phase 
errors of the two receiving channels of X310 with ubx vary very samll 
with frequency, so it is easy to compensate the phase difference.


Looking forward to your test results

Best regards,

Damon

I used the attached script.

Now, I'm only looking at +/- 2MHz, rather than your 100Mhz bandwidth.

I found that the phase noise and offset did not change noticably 
tuning across the entire 4Mhz band.  I don't have a machine fast 
enough here to
  sweep my TX across 100Mhz, but with the N310 RX at a fixed tuning, 
and sweeping the TX (in this case, a Marconi transceiver test set), I 
did not see
  any significant phase shift or change in mutual phase noise as the 
TX swept across the 4MHz band.





On 2019/3/20 上午10:40, Marcus D. Leech wrote:

On 03/19/2019 09:12 PM, Damon wrote:

Hi Marcus,

The phase  responses of two channels of different dboards (ubx-160) 
in  a X310  are very consistent. When the frequency of transmitting 
signal changes from 460.01MHz to 460.03Mhz, the phase difference 
between two RX channels of different dboards in X310 remains 
unchanged. But for the phase difference between two RX channels of 
different dboards of N310,  there are dozens or hundreds degree of 
changes.


Can you try to reproduce the test and help me to figure out how to 
solve it?
I'm not sure if it's a hardware bug, a driver bug or USRP setup 
problem.
I cannot imagine a hardware or driver bug that could produce this 
behavior.  It would mean that the receiver was somehow changing LO

  frequency when the TX frequency changed.

Does this happen with *other* frequency changes, or just 
460.01<--->460.03.  I wonder if you have an interfering signal that 
is being
  "uncovered" by TX frequency change, and you're simply measuring 
that interfering signal?


The only other thing that occurs to me is filtering that is 
extremely non-linear phase.  But that would create such a mess that 
most applications

  would likely not work--clearly they do.

I can try to reproduce in my lab tomorrow, but, like the last tests 
I did, I very much expect to not be able to reproduce.





Best regards,
Damon
On 2019/3/19 上午6:10, Marcus D. Leech wrote:

On 03/18/2019 01:26 PM, Damon wrote:

Hi Marcus,

Sorry, I can't reproduce the first observation in this discussion 
thread. A new problem about phase response has arisen.
I am testing the phase coherence performance of four receiving 
channels of N310. A B200 is transmitting single tone continuous 
wave to a one to four splitter. The 4 outputs of the splitter are 
connected to 4 RX channels of N310. Attached please find the GRC 
file of this test.


The RX frequency of 4 channels of  N310 is set to 460MHz, and 
keep running in the test.


The TX frequency of B200 is set to 460.02MHz first, and then to 
460.03MHz. I thought the phase difference between different 
dboards would change very little when the signal frequency 
difference is very small, similar to the performance of X310. 
However, the fact is that the phase difference between the two 
dboards of N310 varies considerably with the signal frequency 
transmission. For example, in the attached picture, when the 
signal frequency is 460.01MHz, the phase difference between 
channel 2 and channel 0 is -118 degrees, the phase difference 
between channel 1 and channel 0 is 0 degrees; when the 
transmission frequency is adjusted to 460.03MHz, the phase 
difference between channel 2 and channel 0 is 117 degrees, and 
the phase difference between channel 1 and channel 0 is 0 
degrees. It is very difficult to understand that the phase 
difference of two receiving channels of two different dboards has 
changed by 235 degrees with the signal frequency change of 20 
KHz. The phase difference of two receiving channels of the same 
dboard is basically unchanged.


Best regards,

Damon

Since the LO on the daughterboards has no idea that you've changed 
input frequency, this is clearly a 

Re: [USRP-users] Please add me to the mail list

2019-03-21 Thread Piotr Krysik via USRP-users
W dniu 21.03.2019 o 10:58, Diogo Botelho Ribeiro Marinho via USRP-users
pisze:
>
> I am using N310 and i would like to send my questions to the forum.
>
>  
>
> So far i am not able to do it.
>
>  
>
>
Hi Diogo,

I beg to disagree. From my perspective it looks that you are able to
send posts to the mailing-list.

I can even see your post from two days ago (without its subject however).

--
Best Regards,
Piotr Krysik



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


[USRP-users] Please add me to the mail list

2019-03-21 Thread Diogo Botelho Ribeiro Marinho via USRP-users
I am using N310 and i would like to send my questions to the forum.

So far i am not able to do it.

Thanks
Diogo Marinho

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


Re: [USRP-users] Are timed-configuration blocking calls?

2019-03-21 Thread Felipe Augusto Pereira de Figueiredo via USRP-users
Dear All,

Does anyone could give me some hint, suggestion, etc. on this issue?
Anything would be very helpful.

Thanks and Kind Regards,

Felipe Augusto

On Wed, Mar 13, 2019 at 10:39 PM Felipe Augusto Pereira de Figueiredo
 wrote:
>
> Dear all,
>
> I've got an application that uses timed commands to change Tx
> frequency and gain and sent at to schedule the transmission of my
> data, however, I noticed that the time it takes for my app to generate
> and transfer the data to the USRP increased after the introduction of
> the timed configuration. My app works like this
>
> 1) Generate data at upper layer with timestamp t0+2ms (i.e., send at t0+2ms)
> 2) Execute timed configuration (Tx freq. and/or gain) at t0+2ms-300us
> (i.e., the 300 us before the actual transmission time)
> 3) Encode the data and transfer to USRP.
>
> Before the introduction of timed configuration the step 3) would take
> around 300/400 us but after I started using timed configuration it
> went to more than 1 ms.
>
> Based on what I have explained, my questions are:
>
> 1) Are timed-configuration blocking calls?
> 2) Is there a non-blocking way of doing this?
> 3) Is there a way of scheduling data transmission at t0+2ms and timed
> config at t0+2ms-300us in the same timed configuration?
>
> I'm looking for a way to avoid this blockage. I have tried to create a
> thread that would only apply the timed config and another one that
> would encode data and transmit at the specified time, however, the UHD
> seems not to like being played with in separate threads (I have
> mutexes in my calls, but is doesn't help). My app crashes with a
> message saying UHD was waiting for message 1234 but received
> acknowledgement for message 2000. I use jumbo frames (MTU 9000) with
> 10 Gb ethernet card and probably the crash is related to aggregation
> and or reordering. BTW, I would like to change the MTU size right now.
> I would like to find a better solution to the blocking call, if
> possible.
>
> Many thanks in advance,
>
> Felipe

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