Re: [USRP-users] Fwd: Varying delay in signal reception

[Michael Dickens via USRP-users]

Let's take this discussion off list. If there's something useful to report back 
to the list we will. - MLD

On Fri, Aug 9, 2019, at 3:41 AM, Sneha vasan wrote:
> I want to know the time it takes to transmit and receive the signal,(which is 
> in the sense delay). I calculate this based on the time instant I receive the 
> signal. Since I was receiving the signal at different time instants. And 
> currently I am receiving the delay of 1.9e-4sec, 2.3e-4, 2.1e-4s...so on.
> So I was just wondering is it common to receive this. And also with the cable 
> length of 20cm I expect the delay to be in µs. Isn't it higher delay?.
> And I am transmitting a signal of 300µs continuously with 20MHz sampling rate.
> I dont know if I clear enough with my explanation. Can you be specific, if 
> more details required.
> 
> Regards,
> Sneha
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] How to get code phase from the output of GNSS-SDR?

[Xu, Zhao via USRP-users]

Thank you very much!

Zhao Xu

Michael Dickens  于2019年8月9日周五 下午1:33写道：

> Hi Zhao Xu - Your query is really about GNSS-SDR, not about USRP (or GNU
> Radio). Hence it is better suited for their email list <
> https://sourceforge.net/p/gnss-sdr/mailman/gnss-sdr-developers/ >, or
> directly to one of their development team < https://gnss-sdr.org/team/ >,
> or maybe on their GitHub < https://github.com/gnss-sdr/gnss-sdr >. I've
> always had good success in contacting the GNSS-SDR team via various of
> these methods; hopefully you will too! - MLD
>
> On Fri, Aug 9, 2019, at 1:19 PM, Xu, Zhao via USRP-users wrote:
>
> Hello, I am trying to use USRP N210 to get the code phase of the received
> satellite signal. And I have the output of Acquisition and Tracking Blocks
> after running gnss-sdr command according to the instructions (
> https://gnss-sdr.org/conf/ ).
>
> However, I cannot understand the usage of these data and I also cannot
> find some detailed explanation of the output file. I have the following
> data and could you please tell me how I can calculate the code phase?
>
>
>

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

Re: [USRP-users] How to get code phase from the output of GNSS-SDR?

[Michael Dickens via USRP-users]

Hi Zhao Xu - Your query is really about GNSS-SDR, not about USRP (or GNU 
Radio). Hence it is better suited for their email list < 
https://sourceforge.net/p/gnss-sdr/mailman/gnss-sdr-developers/ >, or directly 
to one of their development team < https://gnss-sdr.org/team/ >, or maybe on 
their GitHub < https://github.com/gnss-sdr/gnss-sdr >. I've always had good 
success in contacting the GNSS-SDR team via various of these methods; hopefully 
you will too! - MLD

On Fri, Aug 9, 2019, at 1:19 PM, Xu, Zhao via USRP-users wrote:
> Hello, I am trying to use USRP N210 to get the code phase of the received 
> satellite signal. And I have the output of Acquisition and Tracking Blocks 
> after running gnss-sdr command according to the instructions ( 
> https://gnss-sdr.org/conf/ ).
> 
> However, I cannot understand the usage of these data and I also cannot find 
> some detailed explanation of the output file. I have the following data and 
> could you please tell me how I can calculate the code phase?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Delayed samples receiving, X310

[Cherif Diouf via USRP-users]

I will take a look at it.

Thanks for all
Cherif



From: Nick Foster 
Sent: woensdag 7 augustus 2019 18:52
To: Cherif Diouf 
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Delayed samples receiving, X310

This is exactly what the "timed commands" feature is used for. See the 
documentation here:

https://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html

On Wed, Aug 7, 2019 at 7:15 AM Cherif Diouf via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello guys,

I have developed a custom RFNoC CE connected to one radio core of the X310.
The core will act as receiver and provide samples to my CE for further 
processing (Antennas-> RX frontend + noc_radio_core -> custom CE).
However, I would like the radio core to start sampling and providing data only 
after a deterministic and fixed duration t0 consistent with the 5ns time 
counter and likely synchronized to an external PPS used as time reference.

From python, I know I can use the "set_time_next_pps" call to initialize the 
USRP X310 time. But how to tell the radio core to stay in a idle state until 
the time keeper matches my duration t0?
Can it be done by  software? Or the only option is to use CHDR packets and VITA 
timing?

Best Regards
Cherif

___
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] USRP-users Digest, Vol 108, Issue 8

[Nico Pfeffer via USRP-users]

Dear Marcus,

I fixed it. I was purge/remove all the uhd and gnuradio stuff from my  
system and then apply the pre-requirements for ubuntu18.04LTS and  
using the latest uhd version 003.014.001.000 (added by the ppa) then  
I've done the following,


$ uhd_images_downloader

Then I've looked my usrp with

$ uhd_find_devices

Then I retried the benchmark test dn it failed  BUT  I didn't  
changed the image of the FPGA, so I've used


$ uhd_image_loader

This failed by firmware verification ... DON'T WORRY ... I did the  
image safe-mode and then retried the procedure  voila   
everything fine with image upload . power cycle the usrp  did  
the benchmark again with 200kHz  SUCCESS  then with 10MHz   
SUCCESS


Thank you very much ... savior of the day, nothing more to say :)


Best regards, Nico
Zitat von usrp-users-requ...@lists.ettus.com:


Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com

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
usrp-users-requ...@lists.ettus.com

You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."


Today's Topics:

   1. Re: Delayed samples receiving, X310 (Nick Foster)
   2. USRP B210 FPGA Amplify-forward (Razvan-Andrei Stoica)
   3. Re: 214 MHz ce_clk vs 200 MHz radio_clk, USRP X310 (Cherif Diouf)
   4. USRP N200 has sequence error only on transmission (Nico Pfeffer)
   5. Re: RFNoC Polyphase Channelizer updates (Royce Connerley)
   6. RFX-2400 - Band Pass Filter (Iain Young)
   7. Re: RFNoC Polyphase Channelizer updates (EJ Kreinar)
   8. Fwd: Varying delay in signal reception (Sneha vasan)
   9. Re: Fwd: Varying delay in signal reception (Michael Dickens)
  10. Re: RFX-2400 - Band Pass Filter (Marcus D. Leech)
  11. Re: USRP N200 has sequence error only on transmission
  (Marcus D. Leech)


--

Message: 1
Date: Wed, 7 Aug 2019 09:51:44 -0700
From: Nick Foster 
To: Cherif Diouf 
Cc: "usrp-users@lists.ettus.com" 
Subject: Re: [USRP-users] Delayed samples receiving, X310
Message-ID:

Content-Type: text/plain; charset="utf-8"

This is exactly what the "timed commands" feature is used for. See the
documentation here:

https://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html

On Wed, Aug 7, 2019 at 7:15 AM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:


Hello guys,

I have developed a custom RFNoC CE connected to one radio core of the
X310.
The core will act as receiver and provide samples to my CE for further
processing (Antennas-> RX frontend + noc_radio_core -> custom CE).
However, I would like the radio core to start sampling and  
providing data only

after a deterministic and fixed duration t0 consistent with the 5ns time
counter and likely synchronized to an external PPS used as time reference.

From python, I know I can use the "set_time_next_pps" call to initialize
the USRP X310 time. But how to tell the radio core to stay in a idle state
until the time keeper matches my duration t0?
Can it be done by  software? Or the only option is to use CHDR packets and
VITA timing?

Best Regards
Cherif

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


-- next part --
An HTML attachment was scrubbed...
URL:  



--

Message: 2
Date: Wed, 07 Aug 2019 21:41:49 +0200
From: Razvan-Andrei Stoica 
To: "usrp-users" 
Subject: [USRP-users] USRP B210 FPGA Amplify-forward
Message-ID:
<16c6d9a140f.b4d0b90640043.7921529196409486...@wiosense.de>
Content-Type: text/plain; charset="utf-8"

Hello,



I am working with 2 B210 units trying to realize an out-of-band  
amplify-forward wideband relay.




The signal flow is simple and was already implemented using the  
GNURadio blocks and associated UHD USRP drivers.




The input signal is DCed to BB by one of the RF ends and  
additionally amplified if need be in SW. The output is then rerouted  
to the second RF end on a higher frequency then that of the output.




The second device performs the same operations but reconverts the  
relayed signal to the initial frequency band.




This works quite okay with the host processing and control over a BW  
of 22 Msps, with the occasional bursts of lost samples.




However, due to latency reasons and easier deployment I would like  
to understand if it is possible to implement this simple signal  
processing logic on the FPGA and flash this module such 

Re: [USRP-users] RFNoC Polyphase Channelizer updates

[Royce Connerley via USRP-users]

Nick:

That was my first approach, but I can’t even fit two DDCs in the E310 FPGA.

Royce

> On Aug 8, 2019, at 1:36 PM, Nick Foster  wrote:
> 
> Nevermind, I just saw you're doing it in an E310. Reading is fundamental.
> 
> You might consider splitting the problem into a pair of DDCs instead.
> 
> Nick
> 
> On Thu, Aug 8, 2019 at 11:35 AM Nick Foster  > wrote:
> Royce,
> 
> Is there a reason you absolutely need it to be done in RFNoC? This is only 
> 5MHz of bandwidth, and any commodity PC should be able to handle channelizing 
> it in software.
> 
> Nick
> 
> On Thu, Aug 8, 2019 at 11:19 AM Royce Connerley via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> EJ:
> 
> I’m currently wanting to receive a total of four channels that are 12.5 kHz 
> wide.  The channels are not equally spaced.
> 
> F2 = F1 + 1 MHz
> F3 = F1 + 3.99375 MHz
> F4 = F3 + 1 MHz
> 
> For this type of system, I typically have a number of channel pairs (repeater 
> output and input separated by 1 MHz) that I need to monitor.
> 
> Royce
> 
>> On Aug 8, 2019, at 8:51 AM, EJ Kreinar > > wrote:
>> 
>> Hi Royce,
>> 
>> Can you walk me through your use case real quick?
>> 
>> - How many channels?
>> - How wide is each channel?
>> - Are the channels equally spaced?
>> 
>> The polyphase channelizer in theseus-cores currently has a static number of 
>> "max channels" that get instantiated which is not insignificant. We've 
>> discussed exposing a build-time parameter that could scale down the max 
>> number of channels to save some resources, but 1) that hasn't been 
>> implemented yet and 2) I'm not totally confident it would fit in the e310 
>> anyway. 
>> 
>> But lets think through your scenario and we can discuss where we'd need the 
>> channelizer to go for it to work... for example, you probably also need the 
>> FPGA-based channel downselection in the channelizer -- the E310 wont be able 
>> to return all channels in real time! Or, we could consider other approaches 
>> -- the DDC channelizer in theseus-cores might be workable if you have just 
>> small number of channels and you need arbitrary spacing/channel widths.
>> 
>> EJ
>> 
>> On Thu, Aug 8, 2019, 8:52 AM Royce Connerley > > wrote:
>> EJ:
>> 
>> I want to pick a few narrowband channels scattered over about 5 MHz.  I 
>> would like to be able to use your channelizer in an E310.  Do you think it 
>> could fit in the E310’s FPGA?  When I run uhd_image_builder with just the 
>> channelizer and a FIFO, I’m seeing the following errors:
>> 
>> ERROR: [Place 30-640] Place Check : This design requires more RAMB36/FIFO 
>> cells than are available in the target device. This design requires 324 of 
>> such cell types but only 140 compatible sites are available in the target 
>> device. Please analyze your synthesis results and constraints to ensure the 
>> design is mapped to Xilinx primitives as expected. If so, please consider 
>> targeting a larger device.
>> ERROR: [Place 30-640] Place Check : This design requires more RAMB18 and 
>> RAMB36/FIFO cells than are available in the target device. This design 
>> requires 703 of such cell types but only 280 compatible sites are available 
>> in the target device. Please analyze your synthesis results and constraints 
>> to ensure the design is mapped to Xilinx primitives as expected. If so, 
>> please consider targeting a larger device.
>> ERROR: [Place 30-640] Place Check : This design requires more RAMB36E1 cells 
>> than are available in the target device. This design requires 324 of such 
>> cell types but only 140 compatible sites are available in the target device. 
>> Please analyze your synthesis results and constraints to ensure the design 
>> is mapped to Xilinx primitives as expected. If so, please consider targeting 
>> a larger device.
>> 
>> Royce Connerley
>> 
>>> On Jul 24, 2019, at 6:34 PM, EJ Kreinar >> > wrote:
>>> 
>>> Hi Royce,
>>> 
>>> Phil and I have been working on the channelizer in the theseus-cores repo 
>>> here: gitlab.com/theseus-cores/theseus-cores 
>>> 
>>> 
>>> The master branch has a (potentially) working channelizer, at least 
>>> according to my recent tests on the x310, as long as the network interface 
>>> supports the desired output rate.
>>> 
>>> There's also an fpga solution for channel downselection in a branch that 
>>> Phil put together. The ball is in my court to turn the crank and merge to 
>>> master with supporting software, but I haven't gotten much of a chance 
>>> recently. 
>>> 
>>> If you're interested in testing we could definitely use some more people to 
>>> give it a shot :D Let me know if you need a sample bitstream or if you can 
>>> build one yourself.
>>> 
>>> EJ
>>> 
>>> On Wed, Jul 24, 2019, 4:39 PM Royce Connerley via USRP-users 
>>> mailto:usrp-users@lists.ettus.com>> wrote:
>>> At the 2018 GRCon, EJ 

[USRP-users] Source Codes and SDK for N310 (Embedded Mode)

[retina999--- via USRP-users]

Hi,

We are currently using N310 to design a prototype MIMO OFDM communications 
system. We plan to implemented the baseband in a custom RFNOC block. For the 
MAC and network layers’ functionalities, we hope to implement them on the ARM 
within Zynq FPGA. So ARM should communicate with the custom RFNOC block and 
config the RF chips. The baseband will get samples from the RF radio and send 
TX samples to it. N310 should operate in the embedded mode like an e-series 
usrp equipment. (N310 supports both host and embedded modes).

But we could not find enough info on N310’s embedded mode operations.
1)  Where can we get the SDK for N310 similar to that for E310?
2)  If we want to develop the AXI and SPI drivers for the ARM, where can we get 
source codes of the Linux running on ARM (uboot, kernel, petalinux bsp 
packages, etc. )

Many thanks in advance!
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fwd: Varying delay in signal reception

[Sneha vasan via USRP-users]

I want to know the time it takes to transmit and receive the signal,(which
is in the sense delay). I calculate this based on the time instant I
receive the signal. Since I was receiving the signal at different time
instants. And currently I am receiving the delay of 1.9e-4sec, 2.3e-4,
2.1e-4s...so on.
So I was just wondering is it common to receive this. And also with the
cable length of 20cm I expect the delay to be in µs. Isn't it higher delay?.
And I am transmitting a signal of 300µs continuously with 20MHz sampling
rate.
I dont know if I clear enough with my explanation. Can you be specific, if
more details required.

Regards,
Sneha

On Thu, Aug 8, 2019 at 9:51 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 08/08/2019 01:32 PM, Michael Dickens via USRP-users wrote:
>
> Hi Sneha - Please "reply all" to keep the discussion on the USRP users
> email list. More eyes reading these means a greater chance that folks will
> jump in to help!
>
> The startup time for UHD / USRP / GR will be very similar between
> different runs of the exact same flowgraph, but not exactly the same. If
> you were to somehow measure these and plot them, I'd bet you'd get a curve
> that looks Gaussian except with limits (a "truncated normal distribution").
> The exact same file being Tx'd over and again will have a slightly
> different delay on Tx each time.
>
> Not sure this is what you're experiencing. If you don't think it is, then
> please provide more information; what we have right now is pretty thin.
>
> Hope this is useful! - MLD
>
> I was going to make the same general comment--we don't have enough
> information about exactly *what* you mean by "delay", and exactly
>   how you're measuring it.
>
> It's nearly impossible to get predictable-and-repeatable fine-scale
> latency on a software-based system running on a general-purpose
>   operating-system like Linux or Windows.  If your system-design requires
> this to be so, then you have a problem with your system design.
>
>
> On Thu, Aug 8, 2019, at 11:38 AM, Sneha vasan wrote:
>
> Hi Michael,
>
> I sent a email before I confirmed the subscription for the usrp users. So
> I was wondering if I could receive the email back if replied in usrp lists.
> So just forwarded once again just to be sure. Probably I would have put a
> note there.
>
> I am generating the signal using Matlab and store it in a file and then
> send it to the USRP using gnu-radio. So now when I make multiple recordings
> of the signal at different time , I am receiving the signal at varying
> intial delay . I except the delay to be constant as I am send same signal
> and with same parameters.
>
> Regards,
> Sneha
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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