Re: [USRP-users] [Discuss-gnuradio] continous Tx voice transmission

[Ian Buckley via USRP-users]

Brian, I think your idea does work. I think the tricky bit to doing this really 
well is having a control loop that reacts quickly enough that we don’t have to 
be stuck with a giant buffer that adds undesirable latency, but then conversely 
a control loop that adapts at a slow enough rate and with small enough steps 
that we don’t introduce human perceptible audio artifacts. 

> On Mar 7, 2019, at 7:46 AM, Brian Padalino via USRP-users 
>  wrote:
> 
> On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller  > wrote:
> I've had rather longish discussions on how to solve this; essentially:
> for something that actually *solves* the issue (instead of postponing
> it), as Ian said, you'd need to have clock domain crossing ability.
> 
> Could message passing from the real-time blocks solve this issue in a 
> flexible way?
> 
> Imagine the following: blocks connected to actual hardware use the computer 
> wall clock to try to determine an average sample clock as it relates to the 
> CPU clock.  The USRP source block would be able to determine how many 
> samples/(sec of CPU clock) were coming in and Audio sink blocks would be able 
> to determine how many samples/(sec of CPU clock) were being consumed.  The 
> same idea for Audio sources and USRP sinks.  Since the blocking calls for 
> USRP or Audio blocks could be wrapped in a high precision timer, once any 
> initial buffering had been filled up, the rate should settle out.
> 
> The modified blocks could then send a message of actual sample rate to 
> whoever needed to listen, and the appropriate sample rate could be figured 
> out in the "resampling FIFO".
> 
> What am I missing?  Why won't this work?
> 
> Brian
> ___
> 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] link led colour

[Joe Martin via USRP-users]

Interestingly, my X310 front panel LED occasionally, very briefly shows red 
too.  Maybe the schematic isn’t current with what is actually used in the unit 
these days(?).  

Regards, 

Joe

> On Mar 7, 2019, at 3:36 PM, Marcus Müller via USRP-users 
>  wrote:
> 
> So that's built on an X3x0 platform. As said, no, the link leds really
> just display link status, nothing about the data.
> Also, when you look at the schematic of the X300, PDF [1] page 13,
> you'll find no red LED – only green and yellow, so I must admit I'm a
> bit confused about what you witnessed?
> 
> Best regards,
> Marcus
> 
> [1] http://files.ettus.com/schematics/x300/x3xx.pdf
> On Thu, 2019-03-07 at 09:56 +, Koyel Das (Vehere) wrote:
>> I am using USRP 2955 R
>> 
>> Koyel Das 
>> Senior – Product Engineer
>> Vehere | Proactive Communications Intelligence & Cyber Defence
>> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
>> www.vehere.com
>> 
>> 
>> 
>> Vehere is the proud recipient of the Fastest Growing Technology
>> Company Awards in India & Asia since 2012!
>> 
>> The content of this e-mail is confidential and intended solely for
>> the use of the addressee. The text of this email (including any
>> attachments) may contain information, which is proprietary and/or
>> confidential or privileged in nature belonging to Vehere Interactive
>> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you
>> are not the addressee, or the person responsible for delivering it to
>> the addressee, any disclosure, copying, distribution or any action
>> taken or omitted to be taken in reliance on it is prohibited and may
>> be unlawful. If you have received this e-mail in error, please notify
>> the sender and remove this communication entirely from your system.
>> The recipient acknowledges that no guarantee or any warranty is given
>> as to completeness and accuracy of the content of the email. The
>> recipient further acknowledges that the views contained in the email
>> message are those of the sender and may not necessarily reflect those
>> of Vehere Interactive Pvt Ltd. Before opening and accessing the
>> attachment please check and scan for virus. WARNING: Computer viruses
>> can be transmitted via email. The recipient should check this email
>> and any attachments for the presence of viruses. The company accepts
>> no liability for any damage caused by any virus transmitted by this
>> email.
>> From: Marcus Müller 
>> Sent: Thursday, March 7, 2019 3:21:40 PM
>> To: Koyel Das (Vehere); 'USRP-users@lists.ettus.com'
>> Subject: Re: [USRP-users] link led colour
>> 
>> The link LEDs on our USRPs don't indicate validness of data. It's
>> highly likely this is normal. What USRP are you using?
>> 
>> Best regards,
>> Marcus
>> 
>> On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users
>> wrote:
>>> Hi,
>>> 
>>> When I am receiving data using ethernet my link LED is orange most
>> of
>>> the times and blinking to red for momentarily, which is not so
>>> noticeable. Am I receiving wrong data? It is not turning green.
>>> 
>>> Regards,
>>> Koyel
>>> 
>>> Koyel Das 
>>> Senior – Product Engineer
>>> Vehere | Proactive Communications Intelligence & Cyber Defence
>>> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
>>> www.vehere.com


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

Re: [USRP-users] link led colour

[Marcus Müller via USRP-users]

So that's built on an X3x0 platform. As said, no, the link leds really
just display link status, nothing about the data.
Also, when you look at the schematic of the X300, PDF [1] page 13,
you'll find no red LED – only green and yellow, so I must admit I'm a
bit confused about what you witnessed?

Best regards,
Marcus

[1] http://files.ettus.com/schematics/x300/x3xx.pdf
On Thu, 2019-03-07 at 09:56 +, Koyel Das (Vehere) wrote:
> I am using USRP 2955 R
> 
> Koyel Das 
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> www.vehere.com
> 
> 
> 
> Vehere is the proud recipient of the Fastest Growing Technology
> Company Awards in India & Asia since 2012!
> 
> The content of this e-mail is confidential and intended solely for
> the use of the addressee. The text of this email (including any
> attachments) may contain information, which is proprietary and/or
> confidential or privileged in nature belonging to Vehere Interactive
> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you
> are not the addressee, or the person responsible for delivering it to
> the addressee, any disclosure, copying, distribution or any action
> taken or omitted to be taken in reliance on it is prohibited and may
> be unlawful. If you have received this e-mail in error, please notify
> the sender and remove this communication entirely from your system.
> The recipient acknowledges that no guarantee or any warranty is given
> as to completeness and accuracy of the content of the email. The
> recipient further acknowledges that the views contained in the email
> message are those of the sender and may not necessarily reflect those
> of Vehere Interactive Pvt Ltd. Before opening and accessing the
> attachment please check and scan for virus. WARNING: Computer viruses
> can be transmitted via email. The recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
> From: Marcus Müller 
> Sent: Thursday, March 7, 2019 3:21:40 PM
> To: Koyel Das (Vehere); 'USRP-users@lists.ettus.com'
> Subject: Re: [USRP-users] link led colour
>  
> The link LEDs on our USRPs don't indicate validness of data. It's
> highly likely this is normal. What USRP are you using?
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users
> wrote:
> > Hi,
> > 
> > When I am receiving data using ethernet my link LED is orange most
> of
> > the times and blinking to red for momentarily, which is not so
> > noticeable. Am I receiving wrong data? It is not turning green.
> > 
> > Regards,
> > Koyel
> > 
> > Koyel Das 
> > Senior – Product Engineer
> > Vehere | Proactive Communications Intelligence & Cyber Defence
> > M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> > www.vehere.com
> > 
> > 
> > 
> > Vehere is the proud recipient of the Fastest Growing Technology
> > Company Awards in India & Asia since 2012!
> > 
> > The content of this e-mail is confidential and intended solely for
> > the use of the addressee. The text of this email (including any
> > attachments) may contain information, which is proprietary and/or
> > confidential or privileged in nature belonging to Vehere
> Interactive
> > Pvt Ltd and/or its associates/ group companies/ subsidiaries. If
> you
> > are not the addressee, or the person responsible for delivering it
> to
> > the addressee, any disclosure, copying, distribution or any action
> > taken or omitted to be taken in reliance on it is prohibited and
> may
> > be unlawful. If you have received this e-mail in error, please
> notify
> > the sender and remove this communication entirely from your system.
> > The recipient acknowledges that no guarantee or any warranty is
> given
> > as to completeness and accuracy of the content of the email. The
> > recipient further acknowledges that the views contained in the
> email
> > message are those of the sender and may not necessarily reflect
> those
> > of Vehere Interactive Pvt Ltd. Before opening and accessing the
> > attachment please check and scan for virus. WARNING: Computer
> viruses
> > can be transmitted via email. The recipient should check this email
> > and any attachments for the presence of viruses. The company
> accepts
> > no liability for any damage caused by any virus transmitted by this
> > email.
> > ___
> > 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] [Discuss-gnuradio] continous Tx voice transmission

[Brian Padalino via USRP-users]

On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller 
wrote:

> I've had rather longish discussions on how to solve this; essentially:
> for something that actually *solves* the issue (instead of postponing
> it), as Ian said, you'd need to have clock domain crossing ability.
>

Could message passing from the real-time blocks solve this issue in a
flexible way?

Imagine the following: blocks connected to actual hardware use the computer
wall clock to try to determine an average sample clock as it relates to the
CPU clock.  The USRP source block would be able to determine how many
samples/(sec of CPU clock) were coming in and Audio sink blocks would be
able to determine how many samples/(sec of CPU clock) were being consumed.
The same idea for Audio sources and USRP sinks.  Since the blocking calls
for USRP or Audio blocks could be wrapped in a high precision timer, once
any initial buffering had been filled up, the rate should settle out.

The modified blocks could then send a message of actual sample rate to
whoever needed to listen, and the appropriate sample rate could be figured
out in the "resampling FIFO".

What am I missing?  Why won't this work?

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

Re: [USRP-users] link led colour

[Koyel Das (Vehere) via USRP-users]

I am using USRP 2955 R


Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.


From: Marcus Müller 
Sent: Thursday, March 7, 2019 3:21:40 PM
To: Koyel Das (Vehere); 'USRP-users@lists.ettus.com'
Subject: Re: [USRP-users] link led colour

The link LEDs on our USRPs don't indicate validness of data. It's
highly likely this is normal. What USRP are you using?

Best regards,
Marcus

On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users
wrote:
> Hi,
>
> When I am receiving data using ethernet my link LED is orange most of
> the times and blinking to red for momentarily, which is not so
> noticeable. Am I receiving wrong data? It is not turning green.
>
> Regards,
> Koyel
>
> Koyel Das
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W:
> www.vehere.com
>
>
>
> Vehere is the proud recipient of the Fastest Growing Technology
> Company Awards in India & Asia since 2012!
>
> The content of this e-mail is confidential and intended solely for
> the use of the addressee. The text of this email (including any
> attachments) may contain information, which is proprietary and/or
> confidential or privileged in nature belonging to Vehere Interactive
> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you
> are not the addressee, or the person responsible for delivering it to
> the addressee, any disclosure, copying, distribution or any action
> taken or omitted to be taken in reliance on it is prohibited and may
> be unlawful. If you have received this e-mail in error, please notify
> the sender and remove this communication entirely from your system.
> The recipient acknowledges that no guarantee or any warranty is given
> as to completeness and accuracy of the content of the email. The
> recipient further acknowledges that the views contained in the email
> message are those of the sender and may not necessarily reflect those
> of Vehere Interactive Pvt Ltd. Before opening and accessing the
> attachment please check and scan for virus. WARNING: Computer viruses
> can be transmitted via email. The recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
> ___
> 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] link led colour

[Marcus Müller via USRP-users]

The link LEDs on our USRPs don't indicate validness of data. It's
highly likely this is normal. What USRP are you using?

Best regards,
Marcus

On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users
wrote:
> Hi,
> 
> When I am receiving data using ethernet my link LED is orange most of
> the times and blinking to red for momentarily, which is not so
> noticeable. Am I receiving wrong data? It is not turning green.
> 
> Regards,
> Koyel
> 
> Koyel Das 
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> www.vehere.com
> 
> 
> 
> Vehere is the proud recipient of the Fastest Growing Technology
> Company Awards in India & Asia since 2012!
> 
> The content of this e-mail is confidential and intended solely for
> the use of the addressee. The text of this email (including any
> attachments) may contain information, which is proprietary and/or
> confidential or privileged in nature belonging to Vehere Interactive
> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you
> are not the addressee, or the person responsible for delivering it to
> the addressee, any disclosure, copying, distribution or any action
> taken or omitted to be taken in reliance on it is prohibited and may
> be unlawful. If you have received this e-mail in error, please notify
> the sender and remove this communication entirely from your system.
> The recipient acknowledges that no guarantee or any warranty is given
> as to completeness and accuracy of the content of the email. The
> recipient further acknowledges that the views contained in the email
> message are those of the sender and may not necessarily reflect those
> of Vehere Interactive Pvt Ltd. Before opening and accessing the
> attachment please check and scan for virus. WARNING: Computer viruses
> can be transmitted via email. The recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
> ___
> 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] Frequency resolution of UBX-160 with integer N mode

[Marcus Müller via USRP-users]

Good description!
If you look into uhd/host/lib/usrp/dboard/dboard_ubx.cpp (I think), you
should find that the constructor looks through all the rates the
motherboard (X310 in your case) has to offer and picks the highest one
that works with your UBX. That'd be 25 MHz for the 0. revision of the
UBX, and 50 MHz for any after that (which you extremely likely have).

Best regards,
Marcus
On Thu, 2019-03-07 at 10:14 +0100, Andreas Leuenberger via USRP-users
wrote:
> Hi Fabian
> 
> Thank you for your answer.
> I have check the schematics of the X310. The reference clocks to the 
> daughter boards and the 200 MHz sampling clocks are both generated 
> by the "clock jitter clean" chip (LMK0481). I did not have time yet
> to
> check the configuration of this chip, but probably you are right and
> the reference clock to the daughter boards is not 10 MHz (as I
> assumed).
> It could be 200 MHz or directly 50 MHz.
> 
> Best regards,
> andreas
> 
> 
> > Hi,
> >
> > please double check on that, as I am not 100% sure.
> > As far as I was able to figure out, the LO is generated from the 
> > Daughterboard internal 200 MHz reference (which is dirived from the
> 10 
> > MHz), but is divided by 4 for some reason, so you get multiples of
> 50 
> > MHz. This will also induce a random 90° phase shift between the
> signals, 
> > which is a big problem for MIMO stuff.
> > At least the TwinRX boards we used were able to share the LO
> between 
> > multiple channels, which fixed the problem for us.
> >
> > Best regards,
> > Fabian
> >
> > Am 04.03.2019 um 17:23 schrieb Andreas Leuenberger via USRP-users:
> > > Hello all,
> > > 
> > > I am using a USRP X310 with two daughter boards UBX-160 v2. To
> get a 
> > > stable phase difference of the two daughter boards, I use the RX
> LOs in 
> > > integer N mode ("mode_n=integer"). - I have noticed that the
> frequency 
> > > step of the LO is 50 MHz. As the frequency of the reference
> signal is 10 
> > > MHz, I would expect a step of 10 MHz.
> > > 
> > > Is there a way to reduce this frequency step?
> > > 
> > > Thanks for your help,
> > > andreas
> > > 
> > > 
> > > ___
> > > USRP-users mailing list
> > > USRP-users at lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] [B210] ERROR_CODE_TIMEOUT when recv_frame_size > 8184

[Krzysztof Wisniewski via USRP-users]

Thank you Ron,



Your suggestion did solve my problem, I moved back to v3.13.0.3-rc1 and now I 
can use larger frame sizes. With increased frame size and a RAM disk I can now 
achieve a full capture rate of 61.44MSps on Odroid XU4.



Regards,

Kris



On 2/8/19 12:45:47, Krzysztof Wisniewski via USRP-users wrote:



> The recv_frame_size behavior has been changed in UHD after

> v3.13.0.3-rc1. If you want to experiment with large frame sizes, you

> have to go back to v3.13.0.3-rc1 or before.

>

> Ron

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

Re: [USRP-users] Frequency resolution of UBX-160 with integer N mode

[Andreas Leuenberger via USRP-users]

Hi Fabian

Thank you for your answer.
I have check the schematics of the X310. The reference clocks to the
daughter boards and the 200 MHz sampling clocks are both generated
by the "clock jitter clean" chip (LMK0481). I did not have time yet to
check the configuration of this chip, but probably you are right and
the reference clock to the daughter boards is not 10 MHz (as I assumed).
It could be 200 MHz or directly 50 MHz.

Best regards,
andreas



Hi,

please double check on that, as I am not 100% sure.
As far as I was able to figure out, the LO is generated from the 
Daughterboard internal 200 MHz reference (which is dirived from the 10 
MHz), but is divided by 4 for some reason, so you get multiples of 50 
MHz. This will also induce a random 90° phase shift between the signals, 
which is a big problem for MIMO stuff.
At least the TwinRX boards we used were able to share the LO between 
multiple channels, which fixed the problem for us.


Best regards,
Fabian

Am 04.03.2019 um 17:23 schrieb Andreas Leuenberger via USRP-users:
>/Hello all, /> >//> >/I am using a USRP X310 with two daughter boards UBX-160 v2. To get a /> >/stable phase difference of the two daughter boards, I use the RX LOs in /> >/integer N mode ("mode_n=integer"). - I have noticed that the frequency /> >/step of the LO is 50 MHz. As the frequency of the reference signal is 10 /> >/MHz, I would expect a step of 10 MHz. /> >//> >/Is there a way to reduce this frequency step? /> >//> >/Thanks for your help, /> >/andreas /> >//> >//> >/___ /> >/USRP-users mailing list /> >/USRP-users at lists.ettus.com 

 
/>>/http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com /

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

[USRP-users] How To Reset a Previously JTAG-Programmed Image For Use Over PCI-e Interface for USRP X310

[akin soysal via USRP-users]

Hello all,

I have a USRP X310 and I previously programmed it through JTAG with its
latest image for 10GbE.

Now I got a PCIe x4 cable and as far as I know, the image through this
interface is programmed for each session. I have read in a few places that
the JTAG programmed image could cause a problem.

If this is a problem, how can I reset it to default?

Thanks and regards,
Akın
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com