date:20140617


On 17.06.2014 04:24, Michael Rahaim wrote:

I have a relatively high level question regarding gnuradio and software
radio in general. Is it a fair generalization to say that gnuradio is
operating at the application layer and is essentially emulating a
physical layer implementation (or the implementation of other lower
layer protocols)? For example, if I have a link between two USRPs (more
specifically, N series USRPs), the digitally sampled received data comes
in on the ethernet NIC and moves up the stack to the software radio
application. The signal processing that would typically be done in
lower layers is then handled by the application.


In most cases, GNU Radio handles pretty much what comes out of the A/D 
converter (well, not quite, there's some decimation and filtering in 
there. But for the sake of this argument, this is irrelevant).


So, we have this:

ADC - GNU Radio - DAC

To say GNU Radio operates at application layer would therefore be not 
good description of what it does; it doesn't emulate a PHY, it *is* 
the PHY for all intents and purposes.
This is the software radio principle: Using A/D converters, we bring the 
software very close to the antenna.


This is not an academic view on things. While most wireless devices (and 
I guess that means mobile phones) are what you could call hardware 
radio, i.e. they have dedicated circuits to do the PHY, many other 
applications such as base stations are actually driven by software.


So when you say data moves up the stack, it's not going up the stack 
in terms of ISO/OSI layers. The means of getting the sample data (which 
is the raw signal, even before the PHY layer) to the software are just 
slightly more elaborate than having the PHY chip connected directly to 
the ADC.


GNU Radio was specifically designed to implement PHYs, it can also 
implement MACs. Above that, you would probably use something else.




The second part of my question is, given a flow graph in gnuradio, what
sort of steps would be necessary to push it back down the stack or
implement in a chipset such that it can be used as an interface in a
typical network stack? Is this something that anyone using gnuradio has
considered or should I assume the next step would involve re-implementation?


I'm not sure what you're trying to do here. Maybe what you're trying to 
do is what Balint and John have done with their gr-mac module, which 
allows you to create a TCP/IP connection over your own user-defined PHY?



NOTE: This is by no means for a commercial product, but rather for
demonstration. My research has led me to use gnuradio for some proof of
concept implementations and I'm curious how much additional effort would
be required to port the work to a practical device - for example,
implementation on a smart phone. (you can read this as will it cause me
to postpone graduation a few weeks? months? years?)


GNU Radio works on some embedded devices, which might be what you're 
interested in. If you have no experience in embedded development, it can 
take you months to years to figure out, but if you're a smart guy you 
might be able to get some results sooner than that. Note that I'm not 
talking about smartphones here, but rather commercially available 
embedded SDR devices, such as the Ettus E100.


Martin




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block


On 16.06.2014 19:02, David Halls wrote:

Hey Martin,

My calls using

self.set_min_output_buffer(4096*2)

and

self.set_min_noutput_items(4096)

fail at runtime. Perhaps I am missing some import statements?

AttributeError: 'bsld_dec_butterfly_cfb' object has no attribute
'set_min_output_buffer'


Ah, I misunderstood. You want to use this on Python blocks, I thought 
you just wanted to call it from Python (on C++ blocks). It it's not in 
the gateway blocks, then it won't work in Python.


Cheers,
Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block

2014-06-17 Thread David Halls

From: Activecat [active...@gmail.com]
Sent: 17 June 2014 08:39
To: discuss-gnuradio@gnu.org
Cc: David Halls
Subject: Re: [Discuss-gnuradio] Using set_min_output_buffer() in Python block

On Tue, Jun 17, 2014 at 1:02 AM, David Halls
david.ha...@toshiba-trel.commailto:david.ha...@toshiba-trel.com wrote:
Hey Martin,

My calls using

self.set_min_output_buffer(4096*2)

and

self.set_min_noutput_items(4096)

fail at runtime. Perhaps I am missing some import statements?

AttributeError: 'bsld_dec_butterfly_cfb' object has no attribute
'set_min_output_buffer'

Regards,

David

The set_min_noutput_items() is not yet a supported python statement [1] as
per March 06, 2014.
Also, I believe this statement should be placed in the member functions
(constructor, work function, callback function etc) of your custom block,
don't put it at the wrong place.
In alternative, you may want to replace it with set_output_multiple() if
this is more appropriate.

1.
http://gnuradio.4.n7.nabble.com/self-set-min-noutput-items-is-not-a-valid-python-command-in-gnuradio-td46731.html

Thanks Activecat!! I had the problem that

out_rc[0:len(rcABm)] = rcABm
ValueError: operands could not be broadcast together with shapes (4096) (5376)

where out_rc = output_items[3]

using set_output_multiple(4096*2) has resolved my problem by increasing the
length of the output buffer vector to 4096*2. I wonder if there is a fixed
limit as to how far I can stretch this? In the future I may want my decoder to
output even more than blocks in one go.

Regards,

David

NOTE: The information in this email and any attachments may be confidential
and/or legally privileged. This message may be read, copied and used only by
the intended recipient. If you are not the intended recipient, please destroy
this message, delete any copies held on your system and notify the sender
immediately.

Toshiba Research Europe Limited, registered in England and Wales (2519556).
Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ,
England. Web: www.toshiba.eu/research/trl
---
This email has been scanned for email related threats and delivered safely by
Mimecast.
For more information please visit http://www.mimecast.com
---

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] [GSoC] gr-radar: Echotimer (USRP interface) and FSK Radar Demonstration

2014-06-17 Thread Stefan Wunsch

Hi!

The GNU Radio Radar Toolbox has some nice new features!

First the USRP interface for synchronized TX/RX streams is finished. It
ensures that any waveform given by a tagged stream is received with only
a constant delay due to hardware delays. Therefore a MIMO connection
between two USRPs is needed. This delay can be evaluated with a simple
calibration setup and is fix for a specific hardware setup for all time.
Then the TX/RX streams of the radar system are in sync and you can start
with velocity and range estimations! Check out the post on my blog for
more information and an example video [0].

Second a FSK radar demonstrator is set up! It provides a single target
detection every 210ms with 0.25m/s velocity resolution and a maximum
range of 120m. Two USRP N210 and simple 2.4GHz wifi beam antennas are
used. Check out my blog again [1]! You will find there more information,
e.g. a second demonstration video of the FSK radar and the GRC flowgraph.

Greetings,
Stefan

[0]
https://grradar.wordpress.com/2014/06/17/synchronisation-echotimer-usrp-interface/
[1] https://grradar.wordpress.com/2014/06/17/fsk-radar-demonstration/

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio / Software Radio conceptual question

2014-06-17 Thread Michael Rahaim

Thanks for the quick replies. I can see how putting the SDR in a block
directly before the DAC or after the ADC is a PHY implementation, and how
this is the case when using embedded devices such as the E series USRPs and
the embedded SDR components in a base station.



My confusion is when gnuradio is operating in an OS where the sole purpose
isn’t the comms link (i.e., running on my PC rather than on an embedded
linux micro). In the case of the N series USRPs, my understanding is that
the signal chain wraps whatever is implemented in gnuradio (PHY, MAC, etc)
within network and Ethernet packets to send to the USRP, the USRP unwraps
this and places the samples on the physical channel and vice versa at the
receiver. To me, the wrapping and passing of digital samples seems to put a
stack within the stack. The ends of the chain are unaware of the internal
message passing and act as if the samples were directly passed to the DAC
and ADC, which is why I see it as an emulation of the PHY. Perhaps this is
strictly a case of my definitions being incorrect (and I definitely realize
that network layer models are models rather than standards), but please
confirm if my sense of what is occurring in the signal chain is correct.


Thanks again,


-Mike


On Tue, Jun 17, 2014 at 5:31 AM, Martin Braun martin.br...@ettus.com
wrote:

 On 17.06.2014 04:24, Michael Rahaim wrote:

 I have a relatively high level question regarding gnuradio and software
 radio in general. Is it a fair generalization to say that gnuradio is
 operating at the application layer and is essentially emulating a
 physical layer implementation (or the implementation of other lower
 layer protocols)? For example, if I have a link between two USRPs (more
 specifically, N series USRPs), the digitally sampled received data comes
 in on the ethernet NIC and moves up the stack to the software radio
 application. The signal processing that would typically be done in
 lower layers is then handled by the application.


 In most cases, GNU Radio handles pretty much what comes out of the A/D
 converter (well, not quite, there's some decimation and filtering in there.
 But for the sake of this argument, this is irrelevant).

 So, we have this:

 ADC - GNU Radio - DAC

 To say GNU Radio operates at application layer would therefore be not
 good description of what it does; it doesn't emulate a PHY, it *is* the
 PHY for all intents and purposes.
 This is the software radio principle: Using A/D converters, we bring the
 software very close to the antenna.

 This is not an academic view on things. While most wireless devices (and I
 guess that means mobile phones) are what you could call hardware radio,
 i.e. they have dedicated circuits to do the PHY, many other applications
 such as base stations are actually driven by software.

 So when you say data moves up the stack, it's not going up the stack in
 terms of ISO/OSI layers. The means of getting the sample data (which is the
 raw signal, even before the PHY layer) to the software are just slightly
 more elaborate than having the PHY chip connected directly to the ADC.

 GNU Radio was specifically designed to implement PHYs, it can also
 implement MACs. Above that, you would probably use something else.



  The second part of my question is, given a flow graph in gnuradio, what
 sort of steps would be necessary to push it back down the stack or
 implement in a chipset such that it can be used as an interface in a
 typical network stack? Is this something that anyone using gnuradio has
 considered or should I assume the next step would involve
 re-implementation?


 I'm not sure what you're trying to do here. Maybe what you're trying to do
 is what Balint and John have done with their gr-mac module, which allows
 you to create a TCP/IP connection over your own user-defined PHY?


  NOTE: This is by no means for a commercial product, but rather for
 demonstration. My research has led me to use gnuradio for some proof of
 concept implementations and I'm curious how much additional effort would
 be required to port the work to a practical device - for example,
 implementation on a smart phone. (you can read this as will it cause me
 to postpone graduation a few weeks? months? years?)


 GNU Radio works on some embedded devices, which might be what you're
 interested in. If you have no experience in embedded development, it can
 take you months to years to figure out, but if you're a smart guy you might
 be able to get some results sooner than that. Note that I'm not talking
 about smartphones here, but rather commercially available embedded SDR
 devices, such as the Ettus E100.

 Martin





 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio / Software Radio conceptual question

2014-06-17 Thread Sylvain Munaut

 To me, the wrapping and passing of digital samples seems to put a
 stack within the stack. The ends of the chain are unaware of the internal
 message passing and act as if the samples were directly passed to the DAC
 and ADC, ...

Yes, and ? These are un-related stacks.

Some highend DAC/ADC have high speed serial interfaces and
encode/packetize the data before sensing them to the CPU/FPGA/ASIC
that will deal with the samples, would you consider that a PHY
emulation as well ? The way the samples are transported from one
endpoint to the other is largely irrelevant here ...

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNU Radio / Software Radio conceptual question


On 17.06.2014 13:52, Sylvain Munaut wrote:

To me, the wrapping and passing of digital samples seems to put a
stack within the stack. The ends of the chain are unaware of the internal
message passing and act as if the samples were directly passed to the DAC
and ADC, ...


Yes, and ? These are un-related stacks.

Some highend DAC/ADC have high speed serial interfaces and
encode/packetize the data before sensing them to the CPU/FPGA/ASIC
that will deal with the samples, would you consider that a PHY
emulation as well ? The way the samples are transported from one
endpoint to the other is largely irrelevant here ...


I agree, this is the point I was trying to make. Somehow, the samples 
have to get from the ADC to the PHY. In the case of a networked device, 
it's by Ethernet. On an embedded device, there might be an AXI connection.


The PHY is where the physical signal is handled (or samples in case of 
digital systems), hence the name, regardless of where the samples are 
from. Of course Ethernet has its own PHY and MAC, but our comms system 
doesn't care about this.


M


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] sample time alignment in GRC

2014-06-17 Thread Lapointe, Benjamin - 1008 - MITLL

Hi All,

 

I am still having trouble time aligning sample streams from two USRP X310 
devices.  In GRC I noticed a random time offset from run to run in the two data 
streams using a WX GUI Scope Sink.  Looking at recorded data in MATLAB I also 
see a random time offset from run to run in the two data streams (8, 18, and 24 
sample offset).  I verified that the two data streams that I am inputting into 
the X310 devices are time aligned using a physical scope.  

 

My GRC setup:

 

USRP Source 1 (with internal GPSDO-MINI)

-  Sync = unknown PPS

-  Mb0: Clock Source = Default

-  Mb0: Time Source = Default

USRP Source 2

-  Sync = unknown PPS

-  Mb0: Clock Source = External

-  Mb0: Time Source = External

 

For looking at the data streams I have USRP Source - Complex to Mag - WX GUI 
Scope Sink.

For recording the data streams I have USRP Source - Head (5K) - File Sink 
(Unbuffered: OFF)

 

Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable.

PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” 
SMA cable.

RF input to USRP devices is a pulsed RF signal, to make it easier to look at 
time offset.

GPS on USRP 1 is locked; however, I work with tall buildings completely 
surrounding me and so I don’t know the strength of the GPS lock.

I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but 
until then..

 

Does anyone have any other ideas for getting time-aligned samples from run to 
run in GRC, or what I am doing wrong? I would expect at most a minimal constant 
time offset between data streams if the 10 MHz Ref and 1 PPS signals are 
locked. 

 

Thanks!

-ben

 

From: Marcus Leech [mailto:mle...@ripnet.com] 
Sent: Friday, June 13, 2014 2:04 PM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] sample time alignment in GRC

 

Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and 
all of them should use time synch of

  unknown PPS.

 

Also, there has been a bug in the scope sink (dunno if fixed) where samples are 
*not* time-aligned in the scope sink.  The except

  is that a complex-pair will be time-aligned internally, but not necessarily 
to other streams being displayed.

 

 

 

on Jun 13, 2014, Lapointe, Benjamin - 1008 - MITLL blapoi...@ll.mit.edu wrote:

Hi,

 

I have two USRP X310 devices that I am trying to time align in GNU Radio 
Companion.  One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS 
signals to the other one. The GPS is locked.  Ideally I would have matched 
length cables for 10 MHz reference and 1 PPS, but I think my setup is close 
enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with 
matched length cables, USRP output sampling rate = 5M, USRP center frequency = 
10M.) 

 

I am using WX GUI Scope Sink to look at the magnitudes of each stream from the 
USRP devices.  I expect to see no/minimal delay between the two signal streams, 
but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run 
between the two signal streams.  The period of the signal is 50 samples, so the 
maximum delay difference is 25 samples.  Am I missing something in my 
configuration?  Since I am using a 10 MHz reference and 1 PPS signals, I expect 
time alignment between the two sample streams.  Is there a GRC block for 
forcing time alignment? 

 

Thanks!

-Ben

 

  _  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] sample time alignment in GRC

2014-06-17 Thread Marcus D. Leech


On 06/17/2014 09:58 AM, Lapointe, Benjamin - 1008 - MITLL wrote:


Hi All,

I am still having trouble time aligning sample streams from two USRP 
X310 devices.  In GRC I noticed a random time offset from run to run 
in the two data streams using a WX GUI Scope Sink.  Looking at 
recorded data in MATLAB I also see a random time offset from run to 
run in the two data streams (8, 18, and 24 sample offset).  I verified 
that the two data streams that I am inputting into the X310 devices 
are time aligned using a physical scope.


My GRC setup:

USRP Source 1 (with internal GPSDO-MINI)

-Sync = unknown PPS

-Mb0: Clock Source = Default

-Mb0: Time Source = Default

USRP Source 2

-Sync = unknown PPS

-Mb0: Clock Source = External

-Mb0: Time Source = External

For looking at the data streams I have USRP Source - Complex to Mag 
- WX GUI Scope Sink.


For recording the data streams I have USRP Source - Head (5K) - File 
Sink (Unbuffered: OFF)


Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” 
SMA cable.


PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 
with a 6” SMA cable.


RF input to USRP devices is a pulsed RF signal, to make it easier to 
look at time offset.


GPS on USRP 1 is locked; however, I work with tall buildings 
completely surrounding me and so I don’t know the strength of the GPS 
lock.


I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS 
signals, but until then..


Does anyone have any other ideas for getting time-aligned samples from 
run to run in GRC, or what I am doing wrong? I would expect at most a 
minimal constant time offset between data streams if the 10 MHz Ref 
and 1 PPS signals are locked.


Thanks!

-ben

*From:*Marcus Leech [mailto:mle...@ripnet.com]
*Sent:* Friday, June 13, 2014 2:04 PM
*To:* Lapointe, Benjamin - 1008 - MITLL
*Cc:* discuss-gnuradio@gnu.org
*Subject:* Re: [Discuss-gnuradio] sample time alignment in GRC

Make sure that you specify that the 2nd X310 uses external clock and 
1PPS, and all of them should use time synch of


  unknown PPS.

Also, there has been a bug in the scope sink (dunno if fixed) where 
samples are *not* time-aligned in the scope sink.  The except


  is that a complex-pair will be time-aligned internally, but not 
necessarily to other streams being displayed.


on Jun 13, 2014, *Lapointe, Benjamin - 1008 - MITLL* 
blapoi...@ll.mit.edu mailto:blapoi...@ll.mit.edu wrote:


Hi,

I have two USRP X310 devices that I am trying to time align in GNU
Radio Companion.  One X310 has a GPSDO that is sending 10 MHz
reference and 1 PPS signals to the other one. The GPS is locked.
 Ideally I would have matched length cables for 10 MHz reference
and 1 PPS, but I think my setup is close enough. (Input signal
from sig gen = pulsed 10.005 MHz, input is split with matched
length cables, USRP output sampling rate = 5M, USRP center
frequency = 10M.)

I am using WX GUI Scope Sink to look at the magnitudes of each
stream from the USRP devices.  I expect to see no/minimal delay
between the two signal streams, but I am seeing delays of 24, 13,
9, 0, 3, 6, 25, 24 samples from run to run between the two signal
streams.  The period of the signal is 50 samples, so the maximum
delay difference is 25 samples.  Am I missing something in my
configuration?  Since I am using a 10 MHz reference and 1 PPS
signals, I expect time alignment between the two sample streams. 
Is there a GRC block for forcing time alignment?


Thanks!

-Ben




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

What daughtercards are you using again?

There *will* be a random phase offset between the two sides here, 
because GRC flow-graphs can't take advantage of timed-commands to 
phase-align

  the LOs on WBX and SBX cards.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] sample time alignment in GRC

2014-06-17 Thread Lapointe, Benjamin - 1008 - MITLL

I am using BasicRX daughterboards, each sampling a single real-mode signal.

-ben

 

From: discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org 
[mailto:discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org] On Behalf Of 
Marcus D. Leech
Sent: Tuesday, June 17, 2014 10:06 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] sample time alignment in GRC

 

On 06/17/2014 09:58 AM, Lapointe, Benjamin - 1008 - MITLL wrote: 

Hi All,

 

I am still having trouble time aligning sample streams from two USRP X310 
devices.  In GRC I noticed a random time offset from run to run in the two data 
streams using a WX GUI Scope Sink.  Looking at recorded data in MATLAB I also 
see a random time offset from run to run in the two data streams (8, 18, and 24 
sample offset).  I verified that the two data streams that I am inputting into 
the X310 devices are time aligned using a physical scope.  

 

My GRC setup:

 

USRP Source 1 (with internal GPSDO-MINI)

Sync = unknown PPS

Mb0: Clock Source = Default

Mb0: Time Source = Default

USRP Source 2

Sync = unknown PPS

Mb0: Clock Source = External

Mb0: Time Source = External

 

For looking at the data streams I have USRP Source - Complex to Mag - WX GUI 
Scope Sink.

For recording the data streams I have USRP Source - Head (5K) - File Sink 
(Unbuffered: OFF)

 

Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable.

PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” 
SMA cable.

RF input to USRP devices is a pulsed RF signal, to make it easier to look at 
time offset.

GPS on USRP 1 is locked; however, I work with tall buildings completely 
surrounding me and so I don’t know the strength of the GPS lock.

I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but 
until then..

 

Does anyone have any other ideas for getting time-aligned samples from run to 
run in GRC, or what I am doing wrong? I would expect at most a minimal constant 
time offset between data streams if the 10 MHz Ref and 1 PPS signals are 
locked. 

 

Thanks!

-ben

 

From: Marcus Leech [mailto:mle...@ripnet.com] 
Sent: Friday, June 13, 2014 2:04 PM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] sample time alignment in GRC

 

Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and 
all of them should use time synch of

  unknown PPS.

 

Also, there has been a bug in the scope sink (dunno if fixed) where samples are 
*not* time-aligned in the scope sink.  The except

  is that a complex-pair will be time-aligned internally, but not necessarily 
to other streams being displayed.

 

 

 

on Jun 13, 2014, Lapointe, Benjamin - 1008 - MITLL blapoi...@ll.mit.edu wrote:

Hi,

 

I have two USRP X310 devices that I am trying to time align in GNU Radio 
Companion.  One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS 
signals to the other one. The GPS is locked.  Ideally I would have matched 
length cables for 10 MHz reference and 1 PPS, but I think my setup is close 
enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with 
matched length cables, USRP output sampling rate = 5M, USRP center frequency = 
10M.) 

 

I am using WX GUI Scope Sink to look at the magnitudes of each stream from the 
USRP devices.  I expect to see no/minimal delay between the two signal streams, 
but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run 
between the two signal streams.  The period of the signal is 50 samples, so the 
maximum delay difference is 25 samples.  Am I missing something in my 
configuration?  Since I am using a 10 MHz reference and 1 PPS signals, I expect 
time alignment between the two sample streams.  Is there a GRC block for 
forcing time alignment? 

 

Thanks!

-Ben

 

  _  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 
 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

What daughtercards are you using again?

There *will* be a random phase offset between the two sides here, because GRC 
flow-graphs can't take advantage of timed-commands to phase-align
  the LOs on WBX and SBX cards.






-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Driver Not Working

2014-06-17 Thread fnguyen


Hey Carl,
I'm having the same issue on my Fedora boxes. I have two Fedora 20 
boxes. On the first one I removed everything related to UHD and GNU 
Radio and then ran pybombs as uhd first and then GNU Radio. That worked 
fine for that box so maybe give that a try; however, I replicated the 
same steps on my 2nd Fedora box, but it's still missing the UHD 
components(source and sink blocks in GRC and unable to do 
uhd_find_devices, etc.). On occasion when I remove everything and 
reinstall uhd and Gnuradio, it'll have the uhd drivers, but not GRC and 
its related components.


I'm not really sure what's up, but I've set up the environments and 
verified the paths. Anyone else have any ideas?


Any advice is much appreciated.

Thanks,
Francis


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSoC] Co-Processors Update #3

On Tue, Jun 17, 2014 at 12:37 AM, Alfredo Muniz mun...@seas.upenn.edu
wrote:

 Hello all,

 Logistical:
 - 1/3 of the summer is gone!
 - Midterm evaluations are due at the end of next week (June 27). They are
 short so shouldn't affect progress at all.
 - Coproc dev call next week to get more ideas on GNU Radio integration.
 Time TBD: http://whenisgood.net/rhep54r

 Progress:
 - We finally got GNU Radio running on the board and a successful
 connection to a usrp
 - Figured out some of TI's software tools. Built and ran a successful self
 test for the network coprocessor. Will hopefully get data in and out of the
 FFTC this week.

 I have updated the wiki with my steps for those interested. I still need
 to add some stuff on the MCSDK and programming the board but that's when I
 make a little more progress. Stay tuned:
 http://gnuradio.org/redmine/projects/gnuradio/wiki/Keystone2



Thanks for the update, Alfredo, sounds like good progress. And great job
keeping the wiki page updated. That's an important outcome of this project!

Looking forward to seeing the results of the FFTC work.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD Driver Not Working

On Tue, Jun 17, 2014 at 11:41 AM, fnguyen fngu...@vt.edu wrote:

 Hey Carl,
 I'm having the same issue on my Fedora boxes. I have two Fedora 20 boxes.
 On the first one I removed everything related to UHD and GNU Radio and then
 ran pybombs as uhd first and then GNU Radio. That worked fine for that box
 so maybe give that a try; however, I replicated the same steps on my 2nd
 Fedora box, but it's still missing the UHD components(source and sink
 blocks in GRC and unable to do uhd_find_devices, etc.). On occasion when I
 remove everything and reinstall uhd and Gnuradio, it'll have the uhd
 drivers, but not GRC and its related components.

 I'm not really sure what's up, but I've set up the environments and
 verified the paths. Anyone else have any ideas?

 Any advice is much appreciated.

 Thanks,
 Francis



yum install gnuradio

I believe they are keeping GNU Radio up to date pretty well on Fedora these
days.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Updated NBFM Recorder

On Sun, Jun 15, 2014 at 12:28 PM, madengr rfe...@everestkc.net wrote:

 I actually started with that, but the US 2 meter suggested channels are
 either 15 kHz or 20 kHz spacing depending on location.  It's interesting to
 dump all the 2 meter repeater traffic in my city to disk for several days.
 Even the busy ones are only active about 2 hours/day.  Unfortunately the
 800
 MHz public saftey band is so wide it's difficult to capture many channels,
 and they are P25 anyway.  I patched in the DSD P25 decoder, but it can only
 handle two channels simultaneously.  The public safety channel spacing may
 work well with the pfb_channelizer.

 Thanks,
 Lou
 KD4SHO


Gotcha. That makes sense. Thanks for the explanation.

There are ways to handle this situation of non-equal bandwidths, but I'd
wonder if it's more complicated for this project than it's worth (using the
concept of the reconstruction filters). Could be a good testing ground,
though, to build a system that channelizes the entire band, does some
signal detection for those channels that are active, figures out their
channel bandwidth, and pulls them out or reconstructs them as necessary.
It's a pretty advanced use of the PFB channelizers, though, so it's not a
trivial experiment to just run.

Nice work!

Tom



 Tom Rondeau-2 wrote
  Nice work.
 
  I recommend seeing if you can replace the bank for xlating_fir_filters
  with
  a pfb_channelizer_ccf block. This should be more computationally
 efficient
  than all of the xlating filters, so I'd really like to see if that's true
  for you app.
 
  Tom
 
  ___
  Discuss-gnuradio mailing list

  Discuss-gnuradio@

  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





 --
 View this message in context:
 http://gnuradio.4.n7.nabble.com/Updated-NBFM-Recorder-tp48925p48929.html
 Sent from the GnuRadio mailing list archive at Nabble.com.

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] wxPython 3.0 breaks wxGUI

On Sun, Jun 15, 2014 at 4:36 PM, Iain Young, G7III g7...@g7iii.net wrote:

 Hi Folks,

 Sorry to be late with my two penneth, but I am still in catch up mode
 from vacation.


 On 13/06/14 03:52, Marcus D. Leech wrote:

 On 06/12/2014 10:43 PM, Tom Rondeau wrote:



 In one sense, this is a low priority because we are moving away from
 using the wx sinks in favor of the qt sinks. Still, for now, most of
 our examples are base on wx, so we will need this to work for a little
 bit longer.

 Tom

  Tom, it's not just the examples.  It's a significant base of 3rd party
 applications.   If you make WX go away without having some kind of
uber-smooth transition plan, then the bad taste left by the 3.6 to
 3.7 transition will be remembered, and it won't be pretty.


 I have some concerns of my own here. I'll admit that most of the QT GUI
 sinks look cuter, (and in some cases work better). I do use both,
 depending on what I need.

 The one where the WX GUI wins for my use is the (Non GL) version of the
 WX Waterfall vs the QT Waterfall. It's raw simplicity to show me what I
 need (often did I get the filters right...)

 Even playing with the QT Waterfall's settings, autoscale, bin size etc,
 it never quite seems as easy to spot signals in it, esp weaker ones.
 It's probably just levels that I'm feeding it, but the WX Waterfall works
 better in this regard for me.

 If there would be a way (within GRC) to turn off all the decoration
 (Time, Intensity, Frequency Axis labels etc), so we just have the raw
 waterfall, I'd love that, as things like the QT Time Sink work way
 better than the WX equivalent.

 Also, the QT version seems limited to auto scaling or not. On the WX
 version I can set my own Dynamic Range, Reference Level, and Reference
 Scales should I decide to.

 BTW I think I found a bug. When you first fire the QT Waterfall GUI up,
 and select Multi-Colour colour map, it doesn't work. Select another
 colour map, and then select the multi-colour map, and it's fine.


 Iain


Thanks for the feedback.

I can see a use for turning off the decorations in the waterfall plot. I'd
hope that it'd be a simple function call to just alter the QwtPlot
attributes for these things. Then, it'd simply be another menu item to
toggle it on/off like the other menu features (like turning the grid
on/off).

And I agree about the dynamic range settings. The qtsink itself allows you
to set the min/max values. We really should make those settings available
to the user in the waterfall sink, too. I believe the accessor to do that
is available in the class and needs to be exposed in GRC and in the
drop-down menu settings.

As for the multi-color map, that's the default map. So clicking it won't
change anything since you're just selecting the current setting. If you go
to the 'config' tab of the properties box, you should be able to set
different color maps as the defaults.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Measuring phase between channels

2014-06-17 Thread David Miller


Hello,
I want to measure the phase difference between three synchronised USRP 
channels (Common Ref  PPS), does software exist to do this, and to what 
accuracy, please?

Sorry, this is a bit of a newbie question, and probably already covered!
Dave

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Measuring phase between channels

2014-06-17 Thread Marcus Müller

Hi David,

for starters, you could just divide one channel by the other and
calculate the result's argument. There are blocks for both operations :)

Short explanation:
Just consider the complex signals $s_1, s_2$ in polar coordinates
(instead of the usual real/imag representation)
$s_1(t) = a_1(t) * e^{j \phi_1(t)}$.
Dividing that by $s_2(t) = a_2(t) * e^{j \phi_2(t)}$ gives you
$p(t) = a_1(t)/a_2(t) * e^{j \phi_1 - \phi_2(t)}$, of which you can take
the argument to get the phase difference.

Greetings,
Marcus

On 17.06.2014 19:06, David Miller wrote:
 Hello,
 I want to measure the phase difference between three synchronised USRP
 channels (Common Ref  PPS), does software exist to do this, and to
 what accuracy, please?
 Sorry, this is a bit of a newbie question, and probably already covered!
 Dave

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Phase measurement with Ettus Research N210

2014-06-17 Thread Daniele Nicolodi

Hello,

I'm using an Ettus Research N210 with a LFRX daughter-board to do data
measure the phase of a signals referred to a 10 MHz clock.

To start I want to characterize the phase noise of the device, therefore
I send to both the RX channel and to the frequency reference input the
same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
carrier frequency of 10 MHz.

When I look at the data I obtain, I see a constant phase drift
corresponding to a 9.32 mHz frequency different between the signal I
send to the RX channel and the frequency at which the N210 does the
demodulation.

Given that the signal and the clock are derived from the same oscillator
(in this simple case are the exact same signal), where does this
difference come from? How can I get rid of it?

I imagine it comes from the fact that the ADC sampling frequency is not
an exact multiple of the signal frequency, but I haven't found details
on how the ADC sampling frequency is generated, thus I have no idea
about how to make it an exact multiple of the signal frequency.

Thanks. Cheers,
Daniele

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Measuring phase between channels


On 17.06.2014 19:06, David Miller wrote:

Hello,
I want to measure the phase difference between three synchronised USRP
channels (Common Ref  PPS), does software exist to do this, and to what
accuracy, please?
Sorry, this is a bit of a newbie question, and probably already covered!


Sure, the easiest way would simply be to put in a scope, and check by 
looking -- of course, that's not very accurate.


There's enough math operators in GNU Radio to see the actual phase 
difference, such as conjugate and multiply, then convert to phase.


Cheers,
Martin


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

2014-06-17 Thread Marcus Müller

Hello Daniele,

I've included the USRP users mailing list [1], since this is not related
to GNU Radio but to the USRP.

The N210 has a fixed master clock rate of 100MHz, generated from the
10MHz reference by using PLL controlled clock multipliers.
The ADC always samples at 100MHz complex, then passes this 100MS/s
signal to the FPGA, which then shifts it (if you use an RF frequency
that cannot be synthesized by the daughterboard in use exactly)
digitally by multiplying it with a complex sine, lowpasses it to fulfill
nyquist for your desired sampling rate, and then decimates it. The
sample stream at your desired rate is then passed on via gigabit ethernet.

First of all, let's get a relative error estimate: 9.32e-3/10e6 is about
1ppb error, which is fantastically low from my point of view; this might
as well be caused by numerical accuracy in the FPGA, e.g. when shifting
the signal or decimating it; this is all fixed point arithmetic!

Then, your 200kHz sampling rate is an odd fraction of 100MHz; try
250kHz, to get nicer low pass filtering (I always thought 250kHz was the
minimum usable sampling rate).
Also, how long did you observe your phase drift? To estimate a relative
error of 1e-9 reliably, you'll need a lot of samples (remember: you
always have quantization noise in digital systems, so even given perfect
analog signals and analog components at 0K temperature, you don't get
infinite SNR).

Hope that was a little helpful!

Greetings,
Marcus Müller

[1] subscribe via
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

On 17.06.2014 21:37, Daniele Nicolodi wrote:
 Hello,

 I'm using an Ettus Research N210 with a LFRX daughter-board to do data
 measure the phase of a signals referred to a 10 MHz clock.

 To start I want to characterize the phase noise of the device, therefore
 I send to both the RX channel and to the frequency reference input the
 same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
 carrier frequency of 10 MHz.

 When I look at the data I obtain, I see a constant phase drift
 corresponding to a 9.32 mHz frequency different between the signal I
 send to the RX channel and the frequency at which the N210 does the
 demodulation.

 Given that the signal and the clock are derived from the same oscillator
 (in this simple case are the exact same signal), where does this
 difference come from? How can I get rid of it?

 I imagine it comes from the fact that the ADC sampling frequency is not
 an exact multiple of the signal frequency, but I haven't found details
 on how the ADC sampling frequency is generated, thus I have no idea
 about how to make it an exact multiple of the signal frequency.

 Thanks. Cheers,
 Daniele

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

2014-06-17 Thread Daniele Nicolodi

Hello Marcus,

thank for your detailed response. Some comments and further questions:

On 17/06/2014 22:04, Marcus Müller wrote:
 The N210 has a fixed master clock rate of 100MHz, generated from the
 10MHz reference by using PLL controlled clock multipliers.
 The ADC always samples at 100MHz complex,

What do you mean by complex in this context? ADCs saple voltages, which
are a real quantity...

 then passes this 100MS/s
 signal to the FPGA, which then shifts it (if you use an RF frequency
 that cannot be synthesized by the daughterboard in use exactly)
 digitally by multiplying it with a complex sine, lowpasses it to fulfill
 nyquist for your desired sampling rate, and then decimates it. The
 sample stream at your desired rate is then passed on via gigabit ethernet.

Ok, I think that in the case of the LFRX daughter board the signal is
acquired as-it-is and the demodulation is done completely in the FPGA.

 First of all, let's get a relative error estimate: 9.32e-3/10e6 is about
 1ppb error, which is fantastically low from my point of view; this might
 as well be caused by numerical accuracy in the FPGA, e.g. when shifting
 the signal or decimating it; this is all fixed point arithmetic!

Uhm, this is not a phase accuracy error (which I could maybe agree can
be explained by numerical issues) but a frequency accuracy error: the
phase error adds systematically.

 Then, your 200kHz sampling rate is an odd fraction of 100MHz; try
 250kHz, to get nicer low pass filtering (I always thought 250kHz was the
 minimum usable sampling rate).

I'll try to see if this makes a difference. The minimum sampling rate I
can program is ~193 kHz (it is a strange fraction that I cannot check
right now).

 Also, how long did you observe your phase drift? To estimate a relative
 error of 1e-9 reliably, you'll need a lot of samples (remember: you
 always have quantization noise in digital systems, so even given perfect
 analog signals and analog components at 0K temperature, you don't get
 infinite SNR).

1e-9 is the relative frequency error: the phase drift is ~58 mrad/s
which is 0.58 rad in 10 seconds and this is very easily accessible.

 Hope that was a little helpful!

It is helpful, thanks. However, I believe that the source of the problem
cannot be finite numerical accuracy.

Given your explanation I believe that the issue may come from finite
accuracy in the generation of the 100 MHz sampling rate: how is the 100
MHz clock generated exactly?  If the 100 MHz clock is divided with a DDS
to be compared to the 10 MHz clock to derive the error signal for the
PLL, the finite precision of the DDS control register may explain the
small frequency error (a 32 bit DDS would introduce the right order of
magnitude effect, but I haven't check the exact number).

Cheers,
Daniele


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

2014-06-17 Thread Marcus D. Leech


On 06/17/2014 04:56 PM, Daniele Nicolodi wrote:


I'll try to see if this makes a difference. The minimum sampling rate I
can program is ~193 kHz (it is a strange fraction that I cannot check
right now).


Minimum sample rate = 100e6/512

The USRP devices do strictly-integer decimation in the FPGA.



Given your explanation I believe that the issue may come from finite
accuracy in the generation of the 100 MHz sampling rate: how is the 100
MHz clock generated exactly?  If the 100 MHz clock is divided with a DDS
to be compared to the 10 MHz clock to derive the error signal for the
PLL, the finite precision of the DDS control register may explain the
small frequency error (a 32 bit DDS would introduce the right order of
magnitude effect, but I haven't check the exact number).

Cheers,
Daniele


The master clock on the N2xx series is derived from a 10MHz source 
(on-board 10MHz VCTCXO, or external, or internal GPSDO), feeding an
  AD9510 PLL clock generator, which in turn controls a 100MHz VFO, 
implemented with a 100MHz VCTCXO--both clocks are in the 2.5PPM category.


http://files.ettus.com/schematics/n200/n2xx.pdf




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

I did this exact experiment about a year ago. It's caused by the resolution
of the phase accumulator in the DDC.


On Tue, Jun 17, 2014 at 2:09 PM, Marcus D. Leech mle...@ripnet.com wrote:

 On 06/17/2014 04:56 PM, Daniele Nicolodi wrote:


 I'll try to see if this makes a difference. The minimum sampling rate I
 can program is ~193 kHz (it is a strange fraction that I cannot check
 right now).

  Minimum sample rate = 100e6/512

 The USRP devices do strictly-integer decimation in the FPGA.



  Given your explanation I believe that the issue may come from finite
 accuracy in the generation of the 100 MHz sampling rate: how is the 100
 MHz clock generated exactly?  If the 100 MHz clock is divided with a DDS
 to be compared to the 10 MHz clock to derive the error signal for the
 PLL, the finite precision of the DDS control register may explain the
 small frequency error (a 32 bit DDS would introduce the right order of
 magnitude effect, but I haven't check the exact number).

 Cheers,
 Daniele


  The master clock on the N2xx series is derived from a 10MHz source
 (on-board 10MHz VCTCXO, or external, or internal GPSDO), feeding an
   AD9510 PLL clock generator, which in turn controls a 100MHz VFO,
 implemented with a 100MHz VCTCXO--both clocks are in the 2.5PPM category.

 http://files.ettus.com/schematics/n200/n2xx.pdf




 --
 Marcus Leech
 Principal Investigator
 Shirleys Bay Radio Astronomy Consortium
 http://www.sbrac.org



 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

2014-06-17 Thread Sylvain Munaut

Hi,

 To start I want to characterize the phase noise of the device, therefore
 I send to both the RX channel and to the frequency reference input the
 same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
 carrier frequency of 10 MHz.

The LFTRX doesn't have a tuner so if you set a carrier freq of 10 MHz
the frequency shift is done by the FPGA via CORDIC and  you'll have
numerical errors in there. You just can't get rid of them.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

Just some quick calculations in python:

exact phase increment for 10 MHz:

 (10e6/100e6)*2**32
429496729.6

Closest phase increment:

 np.round((10e6/100e6)*2**32)
429496730.0

Resulting frequency:

 (np.round(10e6/100e6*2**32)/2**32)*100e6
1000.009313226

We are out by 9.3mHz!


On Tue, Jun 17, 2014 at 3:36 PM, Sylvain Munaut 246...@gmail.com wrote:

 Hi,

  To start I want to characterize the phase noise of the device, therefore
  I send to both the RX channel and to the frequency reference input the
  same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
  carrier frequency of 10 MHz.

 The LFTRX doesn't have a tuner so if you set a carrier freq of 10 MHz
 the frequency shift is done by the FPGA via CORDIC and  you'll have
 numerical errors in there. You just can't get rid of them.


 Cheers,

Sylvain

 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

2014-06-17 Thread Daniele Nicolodi

Thanks for the answers.

I didn't think that the sine wave in the FPGA were generated with an
integer phase accumulator (I don't know much about how signal processing
is done in FPGAs).  If this is the case, as I understand from Stephen
email, now I know where the frequency error comes from.

On the other hand, I think that the fact that the sine is computed via
the CORDIC method may introduce numerical errors in the amplitude only,
which would not result in a frequency systematic error.

Cheers,
Daniele

On 18/06/2014 00:43, Stephen Harrison wrote:
 Just some quick calculations in python:
 
 exact phase increment for 10 MHz:
 
 (10e6/100e6)*2**32
 429496729.6
 
 Closest phase increment:
 
 np.round((10e6/100e6)*2**32)
 429496730.0
 
 Resulting frequency:
 
 (np.round(10e6/100e6*2**32)/2**32)*100e6
 1000.009313226
 
 We are out by 9.3mHz!
 
 
 On Tue, Jun 17, 2014 at 3:36 PM, Sylvain Munaut 246...@gmail.com
 mailto:246...@gmail.com wrote:
 
 Hi,
 
  To start I want to characterize the phase noise of the device,
 therefore
  I send to both the RX channel and to the frequency reference input the
  same 10 MHz signal. I configured the N210 for 200 kHz sampling and a
  carrier frequency of 10 MHz.
 
 The LFTRX doesn't have a tuner so if you set a carrier freq of 10 MHz
 the frequency shift is done by the FPGA via CORDIC and  you'll have
 numerical errors in there. You just can't get rid of them.
 
 
 Cheers,
 
Sylvain
 
 ___
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

The Verilog source for the USRP N210 is available online. You can see this
in ddc_chain.v:

  wire [31:0] phase_inc;
   reg [31:0]  phase;
...

   setting_reg #(.my_addr(BASE+0)) sr_0
 (.clk(clk),.rst(rst),.strobe(set_stb),.addr(set_addr),
  .in(set_data),.out(phase_inc),.changed());
...

   // NCO
   always @(posedge clk)
 if(rst)
   phase = 0;
 else if(~ddc_enb)
   phase = 0;
 else
   phase = phase + phase_inc;
...

   // CORDIC  24-bit I/O
   cordic_z24 #(.bitwidth(cwidth))
 cordic(.clock(clk), .reset(rst), .enable(ddc_enb),
.xi(to_cordic_i),. yi(to_cordic_q), .zi(phase[31:32-zwidth]),
.xo(i_cordic),.yo(q_cordic),.zo() );




On Tue, Jun 17, 2014 at 4:02 PM, Daniele Nicolodi dani...@grinta.net
wrote:

 Thanks for the answers.

 I didn't think that the sine wave in the FPGA were generated with an
 integer phase accumulator (I don't know much about how signal processing
 is done in FPGAs).  If this is the case, as I understand from Stephen
 email, now I know where the frequency error comes from.

 On the other hand, I think that the fact that the sine is computed via
 the CORDIC method may introduce numerical errors in the amplitude only,
 which would not result in a frequency systematic error.

 Cheers,
 Daniele

 On 18/06/2014 00:43, Stephen Harrison wrote:
  Just some quick calculations in python:
 
  exact phase increment for 10 MHz:
 
  (10e6/100e6)*2**32
  429496729.6
 
  Closest phase increment:
 
  np.round((10e6/100e6)*2**32)
  429496730.0
 
  Resulting frequency:
 
  (np.round(10e6/100e6*2**32)/2**32)*100e6
  1000.009313226
 
  We are out by 9.3mHz!
 
 
  On Tue, Jun 17, 2014 at 3:36 PM, Sylvain Munaut 246...@gmail.com
  mailto:246...@gmail.com wrote:
 
  Hi,
 
   To start I want to characterize the phase noise of the device,
  therefore
   I send to both the RX channel and to the frequency reference input
 the
   same 10 MHz signal. I configured the N210 for 200 kHz sampling and
 a
   carrier frequency of 10 MHz.
 
  The LFTRX doesn't have a tuner so if you set a carrier freq of 10 MHz
  the frequency shift is done by the FPGA via CORDIC and  you'll have
  numerical errors in there. You just can't get rid of them.
 
 
  Cheers,
 
 Sylvain
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Phase measurement with Ettus Research N210

There is a good treatment of errors in the CORDIC algorithm due to finite
word length in this paper from IEEE transactions: The Quantization Effects
of the CORDIC Algorithm (Yu Hen Hu, Senior Member, IEEE). I reproduced the
results of section IV fairly easily a while ago. There are numerical errors
in both amplitude and phase but you are right, this is not the cause of the
frequency offset you observe.


On Tue, Jun 17, 2014 at 4:09 PM, Stephen Harrison msteveharri...@gmail.com
wrote:

 The Verilog source for the USRP N210 is available online. You can see this
 in ddc_chain.v:

   wire [31:0] phase_inc;
reg [31:0]  phase;
 ...

setting_reg #(.my_addr(BASE+0)) sr_0
  (.clk(clk),.rst(rst),.strobe(set_stb),.addr(set_addr),
   .in(set_data),.out(phase_inc),.changed());
 ...

// NCO
always @(posedge clk)
  if(rst)
phase = 0;
  else if(~ddc_enb)
phase = 0;
  else
phase = phase + phase_inc;
 ...

// CORDIC  24-bit I/O
cordic_z24 #(.bitwidth(cwidth))
  cordic(.clock(clk), .reset(rst), .enable(ddc_enb),
 .xi(to_cordic_i),. yi(to_cordic_q), .zi(phase[31:32-zwidth]),
 .xo(i_cordic),.yo(q_cordic),.zo() );




 On Tue, Jun 17, 2014 at 4:02 PM, Daniele Nicolodi dani...@grinta.net
 wrote:

 Thanks for the answers.

 I didn't think that the sine wave in the FPGA were generated with an
 integer phase accumulator (I don't know much about how signal processing
 is done in FPGAs).  If this is the case, as I understand from Stephen
 email, now I know where the frequency error comes from.

 On the other hand, I think that the fact that the sine is computed via
 the CORDIC method may introduce numerical errors in the amplitude only,
 which would not result in a frequency systematic error.

 Cheers,
 Daniele

 On 18/06/2014 00:43, Stephen Harrison wrote:
  Just some quick calculations in python:
 
  exact phase increment for 10 MHz:
 
  (10e6/100e6)*2**32
  429496729.6
 
  Closest phase increment:
 
  np.round((10e6/100e6)*2**32)
  429496730.0
 
  Resulting frequency:
 
  (np.round(10e6/100e6*2**32)/2**32)*100e6
  1000.009313226
 
  We are out by 9.3mHz!
 
 
  On Tue, Jun 17, 2014 at 3:36 PM, Sylvain Munaut 246...@gmail.com
  mailto:246...@gmail.com wrote:
 
  Hi,
 
   To start I want to characterize the phase noise of the device,
  therefore
   I send to both the RX channel and to the frequency reference
 input the
   same 10 MHz signal. I configured the N210 for 200 kHz sampling
 and a
   carrier frequency of 10 MHz.
 
  The LFTRX doesn't have a tuner so if you set a carrier freq of 10
 MHz
  the frequency shift is done by the FPGA via CORDIC and  you'll have
  numerical errors in there. You just can't get rid of them.
 
 
  Cheers,
 
 Sylvain
 
  ___
  Discuss-gnuradio mailing list
  Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org
  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
 



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Measuring phase between channels