Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Turning off the digital down converter(DDC) in USRP2
(Jason Abele)
2. Frequency Offset Question (Brian Gardiner)
3. Re: Timing and Frequency Synchronisation in MATLAB
(Ryan van den Bergh)
4. Re: Timing and Frequency Synchronisation in MATLAB (Nick Foster)
5. Re: Timing and Frequency Synchronisation in MATLAB
(Ryan van den Bergh)
----------------------------------------------------------------------
Message: 1
Date: Tue, 8 Mar 2011 15:54:23 -0800
From: Jason Abele <[email protected]>
To: "Song, Mujun CAPT KR USAF AETC AFIT/ENG" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Turning off the digital down converter(DDC)
in USRP2
Message-ID: <20110308235423.GI2526@manzanita>
Content-Type: text/plain; charset=us-ascii
> I'm working with USRP2 and Simulink to analyze the Spectral Correlation
> Function of transmitter signal. I have some problem which comes from
> Digital Down Converter(DDC) of USRP2. Because the SCF analysis is based
> on RF signal or at least IF signal which show positive and negative
> frequency peaks, the digital down conversion made by USRP2 makes the SCF
> analysis impossible. As I know, the DDC is implemented in FPGA. Is there
> any way to bypass the DDC process in USRP2 to get a IF or RF signal? Or
> is there anybody who know how to get IF or RF signal using different
> way? And I have to keep the link between USRP2 and Simulink.
Eventually, with UHD + Simulink, you could use a uhd::tune_request_t
with a policy setting to force the DDC to 0 Hz, effectively disabling
it.
You can simulate this effect by cleverly choosing your requested center
frequency. If you tell me what daughterboard you are using, I can help
you understand the tuning resolution of the daughterboard, and therefore
which frequencies will have 0 Hz DDC settings.
You can also make guesses at it by first trying multiples of 100MHz or
even integer divisors of 100MHz. So try the multiple of 25MHz closest
to your desired frequency, try the multiples of 5MHz, 1MHz
Jason
------------------------------
Message: 2
Date: Tue, 8 Mar 2011 19:03:25 -0500
From: Brian Gardiner <[email protected]>
To: [email protected]
Subject: [USRP-users] Frequency Offset Question
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I'm trying to do some 802.11 channel measurements by sending raw I/Q samples
from one USRPN210 and receiving on another. I'm using the RFX2400
daughterboard to operate in the 2.4GHz domain.
1) Will synchronizing both radios with a 10 MHz clock get rid of carrier
frequency and sampling frequency offset between the two? Besides 0 to 15dBm
of available power, is there any other important specs for the clock?
2) What is the LO and what does it mean for it to be locked. (i.e.
here<http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#a5bae478b5bed298138ca39a4fce253c5>
).
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110308/d34263d6/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 09 Mar 2011 08:08:19 +0200
From: Ryan van den Bergh <[email protected]>
To: Nick Foster <[email protected]>, Mike McLernon
<[email protected]>
Cc: Christoph Georgi <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timing and Frequency Synchronisation in
MATLAB
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Nick and Mike,
Wow that was a fast response! Thanks to the both of you.
Okay I think I'm starting to understand things a bit better.
Nick I don't need it to be a completely realistic simulation of a
digital radio - I'm using the USRP2s as an example of how SDR technology
is fundamentally changing the way telecommunications systems are being
developed and standardised.
So to essentially summarise what you guys have said:
1. Placing a 10MHz at +10dBm signal from the same function generator on
two USRP2s' Ref Clock ports will synchronise their frequencies (I assume
that I therefore ignore the pps port)
2. The USRP2 needs to be told to use the Ref Clock
3. The current SIMULINK USRP2 Blockset does not have the functionality
to tell the USRP2 to use the Ref Clock as this requires the UHD drivers,
which SIMULINK doesn't support at the moment
So that leaves me with a few options. I'd really appreciate any advice
on which one to choose:
1. Ignore the Ref Clock and simply try use the MATLAB/SIMULINK functions
to correct frequency offset
2. Try and recompile the USRP2 firmware used by Simulink to force it to
use the Ref Clock as default (I have absolutely no idea how to do this,
but if provided it's not too time consuming, I'm willing to give it a shot)
3. Create a wrapper using GNURadio and the UHD driver, which would
expose the functionality of the USRP2 to a Java application (all the
code for my project is written in Java, and I need certain functions in
MATLAB - so I already have an interface between MATLAB and Java) . I
don't know how time consuming this last option would be as I'm not 100%
familiar with the GNURadio's functions, and I only know C++, not Python.
The wrapper would also need to be compiled in Windows due to some of the
libraries I'm using in my Java code - and I know that GNURadio was
originally intended to be used in Linux, which also means that I may
have to recompile all the GNURadio dependencies in Windows or find
alternatives.
4. I read something a while back about the UHD drivers working on
National Instrument's LabView. So perhaps I could try and implement the
USRP2 code in there, and then find a way to get Java or MATLAB to
communicate with LabView. We don't have a license though, and I've never
used the product, so I have no idea what this would involve.
I am under fairly heavy time constraints, so I'm leaning towards option
1, but if anyone can shed some light on the other options, or even
suggest an alternative, I'd be extremely grateful.
Kind regards,
Ryan
On 2011/03/08 08:54 PM, Nick Foster wrote:
> On Tue, 2011-03-08 at 18:48 +0000, Mike McLernon wrote:
>> Hi Ryan,
>>
>> The UDP-based Simulink I/O blocks should not be sensitive to the source of
>> the clock, whether it is internally generated or externally input. We have
>> not tested this capability, however, so I cannot guarantee that it will
>> work. So, a hardware question to the group -- if an external clock is
>> connected to the board, does the UDP firmware automatically lock to it?
>>
> No. The default is free-running unless commanded to sync to the external
> reference.
>
> --n
>
>> Mike
>>
>>
>> -----Original Message-----
>> From: Nick Foster [mailto:[email protected]]
>> Sent: Tuesday, March 08, 2011 1:19 PM
>> To: [email protected]
>> Cc: [email protected]; Mike McLernon
>> Subject: Re: [USRP-users] Timing and Frequency Synchronisation in MATLAB
>>
>> On Tue, 2011-03-08 at 12:23 +0200, Ryan van den Bergh wrote:
>>> Hi Everyone,
>>>
>>> Firstly thanks for everyone who has helped me in the past with my USRP2
>>> and Simulink issues - I really appreciate it!!
>>>
>>> At the moment I need to create a full transceiver system in Simulink
>>> with the USRP2s and I need timing and frequency synchronisation for my
>>> frames.
>>>
>>> Now before I go any further, I have read the responses from Mike
>>> McLernon at Mathworks regarding Barker codes, cross-correlation and
>>> pulse shaping (Many thanks for those e-mails Mike - they helped
>>> immensely!!!), but what I'm actually wondering is whether the reference
>>> clock and pps could be used to provide a sort of preliminary
>>> synchronisation between the transmitting and receiving USRP2s. All the
>>> literature I have found thus far relates only seems to apply to GNURadio
>>> systems.
>>>
>>> My thought process (and please feel free to correct me if I'm completely
>>> wrong) is that by attaching two function generators to the USRP2s (one
>>> to both reference clock ports, and one to both pps ports) I will be able
>>> to largely eliminate frequency drift and timing offset. I believe this
>>> would make the barker code preambles and cross-correlation far more
>>> accurate when determining the start of the frame and greatly assist in
>>> the case of frames that contain OFDM symbols.
>>>
>>> So to summarise, I'll list my questions:
>>>
>>> 1. Would the addition of signals on the ref clock and pps ports assist
>>> in frame synchronisation?
>> Sure. It's not a very realistic simulation of a real digital radio, but
>> if you don't need that, then it'll save you some grief. That said, it
>> won't do anything for your frame synchronization, just for your
>> frequency synchronization. Both are necessary in a real digital radio
>> system. You will still have to do some sort of framing on the transmit
>> side, and preamble detection on the receive side, to detect the start of
>> your frames. This is pretty straightforward, and I'm pretty sure
>> Simulink blocks exist to just "make it work".
>>
>>> 2. Would the use of a standard function generator be
>>> appropriate/applicable or would I need more specialised hardware?
>> That's fine. Give it 10MHz at +10dBm and it'll sync.
>>
>>> 3. Depending on the answer above, can I use two separate function
>>> generators with the appropriate signal characteristics?
>> Not necessary.
>>
>>> 4. Bearing in mind that I am using MATLAB/Simulink which requires old
>>> versions of the USRP2 firmware, do I have to do anything to the USRP2s
>>> to get them to use these signals?
>> Here's the problem. I don't think that the current Simulink driver
>> supports locking to the ref clock input. I'm happy to be corrected, but
>> you might have to 1) use Gnuradio and either gr-uhd or the older raw
>> Ethernet driver, or 2) wait for Mathworks to release a UHD-compatible
>> Simulink driver (any day now?).
>>
>> --n
>>
>>> Kind regards,
>>>
>>> Ryan
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
------------------------------
Message: 4
Date: Tue, 08 Mar 2011 22:25:22 -0800
From: Nick Foster <[email protected]>
To: [email protected]
Cc: Christoph Georgi <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timing and Frequency Synchronisation in
MATLAB
Message-ID: <1299651922.24655.13.camel@crapshoot>
Content-Type: text/plain; charset="UTF-8"
On Wed, 2011-03-09 at 08:08 +0200, Ryan van den Bergh wrote:
> Hi Nick and Mike,
>
> Wow that was a fast response! Thanks to the both of you.
>
> Okay I think I'm starting to understand things a bit better.
>
> Nick I don't need it to be a completely realistic simulation of a
> digital radio - I'm using the USRP2s as an example of how SDR technology
> is fundamentally changing the way telecommunications systems are being
> developed and standardised.
>
> So to essentially summarise what you guys have said:
> 1. Placing a 10MHz at +10dBm signal from the same function generator on
> two USRP2s' Ref Clock ports will synchronise their frequencies (I assume
> that I therefore ignore the pps port)
> 2. The USRP2 needs to be told to use the Ref Clock
> 3. The current SIMULINK USRP2 Blockset does not have the functionality
> to tell the USRP2 to use the Ref Clock as this requires the UHD drivers,
> which SIMULINK doesn't support at the moment
You got it.
>
> So that leaves me with a few options. I'd really appreciate any advice
> on which one to choose:
> 1. Ignore the Ref Clock and simply try use the MATLAB/SIMULINK functions
> to correct frequency offset
> 2. Try and recompile the USRP2 firmware used by Simulink to force it to
> use the Ref Clock as default (I have absolutely no idea how to do this,
> but if provided it's not too time consuming, I'm willing to give it a shot)
> 3. Create a wrapper using GNURadio and the UHD driver, which would
> expose the functionality of the USRP2 to a Java application (all the
> code for my project is written in Java, and I need certain functions in
> MATLAB - so I already have an interface between MATLAB and Java) . I
> don't know how time consuming this last option would be as I'm not 100%
> familiar with the GNURadio's functions, and I only know C++, not Python.
> The wrapper would also need to be compiled in Windows due to some of the
> libraries I'm using in my Java code - and I know that GNURadio was
> originally intended to be used in Linux, which also means that I may
> have to recompile all the GNURadio dependencies in Windows or find
> alternatives.
> 4. I read something a while back about the UHD drivers working on
> National Instrument's LabView. So perhaps I could try and implement the
> USRP2 code in there, and then find a way to get Java or MATLAB to
> communicate with LabView. We don't have a license though, and I've never
> used the product, so I have no idea what this would involve.
>
> I am under fairly heavy time constraints, so I'm leaning towards option
> 1, but if anyone can shed some light on the other options, or even
> suggest an alternative, I'd be extremely grateful.
Since much of your functionality is in Java code external to MATLAB
already, you might seriously consider option #2. If you tell us what
specific functionality you depend on MATLAB for, we might be able to
suggest equivalent Gnuradio blocks.
That said, the MATLAB comms blockset should have everything you need to
do frequency and frame synchronization, but I'm not familiar enough with
it (or with your application) to say if it's easy or not.
--n
>
> Kind regards,
>
> Ryan
>
> On 2011/03/08 08:54 PM, Nick Foster wrote:
> > On Tue, 2011-03-08 at 18:48 +0000, Mike McLernon wrote:
> >> Hi Ryan,
> >>
> >> The UDP-based Simulink I/O blocks should not be sensitive to the source of
> >> the clock, whether it is internally generated or externally input. We
> >> have not tested this capability, however, so I cannot guarantee that it
> >> will work. So, a hardware question to the group -- if an external clock
> >> is connected to the board, does the UDP firmware automatically lock to it?
> >>
> > No. The default is free-running unless commanded to sync to the external
> > reference.
> >
> > --n
> >
> >> Mike
> >>
> >>
> >> -----Original Message-----
> >> From: Nick Foster [mailto:[email protected]]
> >> Sent: Tuesday, March 08, 2011 1:19 PM
> >> To: [email protected]
> >> Cc: [email protected]; Mike McLernon
> >> Subject: Re: [USRP-users] Timing and Frequency Synchronisation in MATLAB
> >>
> >> On Tue, 2011-03-08 at 12:23 +0200, Ryan van den Bergh wrote:
> >>> Hi Everyone,
> >>>
> >>> Firstly thanks for everyone who has helped me in the past with my USRP2
> >>> and Simulink issues - I really appreciate it!!
> >>>
> >>> At the moment I need to create a full transceiver system in Simulink
> >>> with the USRP2s and I need timing and frequency synchronisation for my
> >>> frames.
> >>>
> >>> Now before I go any further, I have read the responses from Mike
> >>> McLernon at Mathworks regarding Barker codes, cross-correlation and
> >>> pulse shaping (Many thanks for those e-mails Mike - they helped
> >>> immensely!!!), but what I'm actually wondering is whether the reference
> >>> clock and pps could be used to provide a sort of preliminary
> >>> synchronisation between the transmitting and receiving USRP2s. All the
> >>> literature I have found thus far relates only seems to apply to GNURadio
> >>> systems.
> >>>
> >>> My thought process (and please feel free to correct me if I'm completely
> >>> wrong) is that by attaching two function generators to the USRP2s (one
> >>> to both reference clock ports, and one to both pps ports) I will be able
> >>> to largely eliminate frequency drift and timing offset. I believe this
> >>> would make the barker code preambles and cross-correlation far more
> >>> accurate when determining the start of the frame and greatly assist in
> >>> the case of frames that contain OFDM symbols.
> >>>
> >>> So to summarise, I'll list my questions:
> >>>
> >>> 1. Would the addition of signals on the ref clock and pps ports assist
> >>> in frame synchronisation?
> >> Sure. It's not a very realistic simulation of a real digital radio, but
> >> if you don't need that, then it'll save you some grief. That said, it
> >> won't do anything for your frame synchronization, just for your
> >> frequency synchronization. Both are necessary in a real digital radio
> >> system. You will still have to do some sort of framing on the transmit
> >> side, and preamble detection on the receive side, to detect the start of
> >> your frames. This is pretty straightforward, and I'm pretty sure
> >> Simulink blocks exist to just "make it work".
> >>
> >>> 2. Would the use of a standard function generator be
> >>> appropriate/applicable or would I need more specialised hardware?
> >> That's fine. Give it 10MHz at +10dBm and it'll sync.
> >>
> >>> 3. Depending on the answer above, can I use two separate function
> >>> generators with the appropriate signal characteristics?
> >> Not necessary.
> >>
> >>> 4. Bearing in mind that I am using MATLAB/Simulink which requires old
> >>> versions of the USRP2 firmware, do I have to do anything to the USRP2s
> >>> to get them to use these signals?
> >> Here's the problem. I don't think that the current Simulink driver
> >> supports locking to the ref clock input. I'm happy to be corrected, but
> >> you might have to 1) use Gnuradio and either gr-uhd or the older raw
> >> Ethernet driver, or 2) wait for Mathworks to release a UHD-compatible
> >> Simulink driver (any day now?).
> >>
> >> --n
> >>
> >>> Kind regards,
> >>>
> >>> Ryan
> >>>
> >>> _______________________________________________
> >>> USRP-users mailing list
> >>> [email protected]
> >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >>
> >
> >
>
------------------------------
Message: 5
Date: Wed, 09 Mar 2011 10:01:13 +0200
From: Ryan van den Bergh <[email protected]>
To: Nick Foster <[email protected]>
Cc: Christoph Georgi <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Timing and Frequency Synchronisation in
MATLAB
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Nick,
Did you mean option 3? In other words the GNURadio/UHD wrapper?
From what I remember when I looked at GNURadio last year, the
interfaces to the USRP2 were written as C++ classes. If all I need to do
is use the Tx and Rx classes, then I think it'll be fairly simple.
Obviously there may be specific external libraries required to execute
those two classes, but am I correct in this assumption?
I'll try to compile a list of functions that I need, I may not be able
to do it for a week or two because I'm still in the process of modelling
and there are a lot of them - the primary reason I'm fairly certain
MATLAB has the functions I need, is that I've seen other researchers'
implement the protocol stacks that I'm looking at, viz. WiMAX and LTE.
In addition, the research I'm doing requires that I implement each
individual function independently, and that the flow of data between
functions must be controlled by my Java application - so I'd need a
wrapper to expose each of the C++ functions to Java (and I'm assuming
that those functions can be executed without the need to use Python?).
I'll look at the GNURadio C++ Blocks and get back to you if I have any
difficulties. As I said, I'll probably need a week or two before I get
to that stage. I've been trying to work on the USRP2s in parallel so
that they'll be ready when I'm finished modelling the protocol stacks.
Thanks for all your help!
Kind regards,
Ryan
On 2011/03/09 08:25 AM, Nick Foster wrote:
> On Wed, 2011-03-09 at 08:08 +0200, Ryan van den Bergh wrote:
>> Hi Nick and Mike,
>>
>> Wow that was a fast response! Thanks to the both of you.
>>
>> Okay I think I'm starting to understand things a bit better.
>>
>> Nick I don't need it to be a completely realistic simulation of a
>> digital radio - I'm using the USRP2s as an example of how SDR technology
>> is fundamentally changing the way telecommunications systems are being
>> developed and standardised.
>>
>> So to essentially summarise what you guys have said:
>> 1. Placing a 10MHz at +10dBm signal from the same function generator on
>> two USRP2s' Ref Clock ports will synchronise their frequencies (I assume
>> that I therefore ignore the pps port)
>> 2. The USRP2 needs to be told to use the Ref Clock
>> 3. The current SIMULINK USRP2 Blockset does not have the functionality
>> to tell the USRP2 to use the Ref Clock as this requires the UHD drivers,
>> which SIMULINK doesn't support at the moment
> You got it.
>
>> So that leaves me with a few options. I'd really appreciate any advice
>> on which one to choose:
>> 1. Ignore the Ref Clock and simply try use the MATLAB/SIMULINK functions
>> to correct frequency offset
>> 2. Try and recompile the USRP2 firmware used by Simulink to force it to
>> use the Ref Clock as default (I have absolutely no idea how to do this,
>> but if provided it's not too time consuming, I'm willing to give it a shot)
>> 3. Create a wrapper using GNURadio and the UHD driver, which would
>> expose the functionality of the USRP2 to a Java application (all the
>> code for my project is written in Java, and I need certain functions in
>> MATLAB - so I already have an interface between MATLAB and Java) . I
>> don't know how time consuming this last option would be as I'm not 100%
>> familiar with the GNURadio's functions, and I only know C++, not Python.
>> The wrapper would also need to be compiled in Windows due to some of the
>> libraries I'm using in my Java code - and I know that GNURadio was
>> originally intended to be used in Linux, which also means that I may
>> have to recompile all the GNURadio dependencies in Windows or find
>> alternatives.
>> 4. I read something a while back about the UHD drivers working on
>> National Instrument's LabView. So perhaps I could try and implement the
>> USRP2 code in there, and then find a way to get Java or MATLAB to
>> communicate with LabView. We don't have a license though, and I've never
>> used the product, so I have no idea what this would involve.
>>
>> I am under fairly heavy time constraints, so I'm leaning towards option
>> 1, but if anyone can shed some light on the other options, or even
>> suggest an alternative, I'd be extremely grateful.
> Since much of your functionality is in Java code external to MATLAB
> already, you might seriously consider option #2. If you tell us what
> specific functionality you depend on MATLAB for, we might be able to
> suggest equivalent Gnuradio blocks.
>
> That said, the MATLAB comms blockset should have everything you need to
> do frequency and frame synchronization, but I'm not familiar enough with
> it (or with your application) to say if it's easy or not.
>
> --n
>
>> Kind regards,
>>
>> Ryan
>>
>> On 2011/03/08 08:54 PM, Nick Foster wrote:
>>> On Tue, 2011-03-08 at 18:48 +0000, Mike McLernon wrote:
>>>> Hi Ryan,
>>>>
>>>> The UDP-based Simulink I/O blocks should not be sensitive to the source of
>>>> the clock, whether it is internally generated or externally input. We
>>>> have not tested this capability, however, so I cannot guarantee that it
>>>> will work. So, a hardware question to the group -- if an external clock
>>>> is connected to the board, does the UDP firmware automatically lock to it?
>>>>
>>> No. The default is free-running unless commanded to sync to the external
>>> reference.
>>>
>>> --n
>>>
>>>> Mike
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Nick Foster [mailto:[email protected]]
>>>> Sent: Tuesday, March 08, 2011 1:19 PM
>>>> To: [email protected]
>>>> Cc: [email protected]; Mike McLernon
>>>> Subject: Re: [USRP-users] Timing and Frequency Synchronisation in MATLAB
>>>>
>>>> On Tue, 2011-03-08 at 12:23 +0200, Ryan van den Bergh wrote:
>>>>> Hi Everyone,
>>>>>
>>>>> Firstly thanks for everyone who has helped me in the past with my USRP2
>>>>> and Simulink issues - I really appreciate it!!
>>>>>
>>>>> At the moment I need to create a full transceiver system in Simulink
>>>>> with the USRP2s and I need timing and frequency synchronisation for my
>>>>> frames.
>>>>>
>>>>> Now before I go any further, I have read the responses from Mike
>>>>> McLernon at Mathworks regarding Barker codes, cross-correlation and
>>>>> pulse shaping (Many thanks for those e-mails Mike - they helped
>>>>> immensely!!!), but what I'm actually wondering is whether the reference
>>>>> clock and pps could be used to provide a sort of preliminary
>>>>> synchronisation between the transmitting and receiving USRP2s. All the
>>>>> literature I have found thus far relates only seems to apply to GNURadio
>>>>> systems.
>>>>>
>>>>> My thought process (and please feel free to correct me if I'm completely
>>>>> wrong) is that by attaching two function generators to the USRP2s (one
>>>>> to both reference clock ports, and one to both pps ports) I will be able
>>>>> to largely eliminate frequency drift and timing offset. I believe this
>>>>> would make the barker code preambles and cross-correlation far more
>>>>> accurate when determining the start of the frame and greatly assist in
>>>>> the case of frames that contain OFDM symbols.
>>>>>
>>>>> So to summarise, I'll list my questions:
>>>>>
>>>>> 1. Would the addition of signals on the ref clock and pps ports assist
>>>>> in frame synchronisation?
>>>> Sure. It's not a very realistic simulation of a real digital radio, but
>>>> if you don't need that, then it'll save you some grief. That said, it
>>>> won't do anything for your frame synchronization, just for your
>>>> frequency synchronization. Both are necessary in a real digital radio
>>>> system. You will still have to do some sort of framing on the transmit
>>>> side, and preamble detection on the receive side, to detect the start of
>>>> your frames. This is pretty straightforward, and I'm pretty sure
>>>> Simulink blocks exist to just "make it work".
>>>>
>>>>> 2. Would the use of a standard function generator be
>>>>> appropriate/applicable or would I need more specialised hardware?
>>>> That's fine. Give it 10MHz at +10dBm and it'll sync.
>>>>
>>>>> 3. Depending on the answer above, can I use two separate function
>>>>> generators with the appropriate signal characteristics?
>>>> Not necessary.
>>>>
>>>>> 4. Bearing in mind that I am using MATLAB/Simulink which requires old
>>>>> versions of the USRP2 firmware, do I have to do anything to the USRP2s
>>>>> to get them to use these signals?
>>>> Here's the problem. I don't think that the current Simulink driver
>>>> supports locking to the ref clock input. I'm happy to be corrected, but
>>>> you might have to 1) use Gnuradio and either gr-uhd or the older raw
>>>> Ethernet driver, or 2) wait for Mathworks to release a UHD-compatible
>>>> Simulink driver (any day now?).
>>>>
>>>> --n
>>>>
>>>>> Kind regards,
>>>>>
>>>>> Ryan
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 7, Issue 15
*****************************************
