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: GPSDO on usrp2 (Josh Blum)
2. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Josh Blum)
3. Re: GPSDO on usrp2 (Dario Lombardo)
4. Sampling frequency offset between 2 USRP2 devices ?
(Sanat Gulvadi)
5. Re: Sampling frequency offset between 2 USRP2 devices ?
(Marcus D. Leech)
6. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
7. Re: Sampling frequency offset between 2 USRP2 devices ?
(Sanat Gulvadi)
8. Re: Sampling frequency offset between 2 USRP2 devices ?
([email protected])
9. Re: high packet loss tunnel.py (vegihat vegihat)
10. Re: Sampling frequency offset between 2 USRP2 devices ?
(Sanat Gulvadi)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 May 2012 21:02:49 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO on usrp2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/28/2012 01:00 AM, Dario Lombardo wrote:
> Hello everybody
> I'm trying to use my gpsdo, but I'm not sure to have set it up correctly.
>
> $ /usr/local/share/uhd/utils/usrp_burn_mb_eeprom --key gpsdo
> linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
> UHD_003.004.000-1fab7e9
>
> Creating USRP device from address:
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Found a Jackson Labs GPS
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
>
> Fetching current settings from EEPROM...
> EEPROM ["gpsdo"] is "internal"
>
> Done
>
> Is it right? Or should I set it to NONE?
>
> Then, the jumper in J510 is set to 2-3... should be fine. The E led on the
> front panel is turnen on.
>
> With this config if I run kalibrate, I have a high error rate
>
> $ ./kal -c 37 -x
> linux; GNU C++ version 4.5.1 20100924 (Red Hat 4.5.1-4); Boost_104400;
> UHD_003.004.000-1fab7e9
>
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> -- Found a Jackson Labs GPS
> -- Setting references to the internal GPSDO
> -- Initializing time to the internal GPSDO
>
> UHD Warning:
> The hardware does not support the requested RX sample rate:
> Target sample rate: 0.270833 MSps
> Actual sample rate: 0.271739 MSps
> kal: Calculating clock frequency offset.
> Using GSM-900 channel 37 (942.4MHz)
> average [min, max] (range, stddev)
> - 19.021kHz [-19063, -18975] (88, 25.709314)
> overruns: 0
> not found: 6
>
> That can be ok if the satellite signal is bad.
>
> Now the question is: how can I be sure that the problem is related to the
> GPS signal and not to some wrong configuration? Are there any other tools
> that can be used to check the GPSDO?
>
The printout from UHD tells me that it is correctly communicating with
the gpsdo unit.
You can use the available sensors for the GPSDO to query for locked
status among other things:
http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application
-josh
------------------------------
Message: 2
Date: Mon, 28 May 2012 23:17:01 -0700
From: Josh Blum <[email protected]>
To: Isaac Gerg <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> Here is what I'm running:
> \UHD\share\uhd\examples>tx_bursts --rep-delay 3 --repeat --freq 10000
>
Looks like the DAC is continuing to modulate. Even though the
application stopped feeding it zeros, the modulator in the DAC is still
spinning. Apparently flushing out zeros isnt doing the trick.
It looks like the best thing ever is to just shutoff the digital part of
the ADC when the USRP tx state machine is shutoff. The output of that
tx_bursts app then looks quiet in between the bursts:
> void enable_tx(bool enb){
> _tx_enabled = enb;
> _fx2_ctrl->usrp_tx_enable(enb);
> + BOOST_FOREACH(const std::string &key, _dbc.keys())
> + {
> + _dbc[key].codec->enable_tx_digital(enb);
> + }
> }
I cant think of a downside to this yet, so this diff should get in there.
As far as older UHDs working, I dont even. The tx state machine was
actually not disabled, and this somehow led to underflow condition and
the output shutting off, possibly due to zeros being flushed out.
-josh
------------------------------
Message: 3
Date: Tue, 29 May 2012 11:15:45 +0200
From: Dario Lombardo <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] GPSDO on usrp2
Message-ID:
<CAOYJJfuAdpJAgf7bc=x5odduwp5tzybyzxkpdrzys2si0pc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Tue, May 29, 2012 at 6:02 AM, Josh Blum <[email protected]> wrote:
>
> The printout from UHD tells me that it is correctly communicating with
> the gpsdo unit.
>
>
So, your point is that I have a bad gps signal?
> You can use the available sensors for the GPSDO to query for locked
> status among other things:
>
> http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application
Are there apps ready-to-use to query it? I don't have programmed usrp ever
:(.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/29eb7727/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 29 May 2012 13:33:05 +0200
From: Sanat Gulvadi <[email protected]>
To: [email protected]
Subject: [USRP-users] Sampling frequency offset between 2 USRP2
devices ?
Message-ID:
<CAH12yLsGiL-ieoNYg=wwon5vm4w4h5m+lvq5ae17wfl8w0m...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Greetings,
I apologize in advance if this question has already been asked or has
already been addressed in the manual. I was unsuccessful in finding the
answer. Should I expect an offset in the sampling frequencies between the 2
devices ? Just to add a little background :
I am implementing an OFDM based communication system using 2 USRP2-REV4s
each with an RFX2400 board. My algorithm is supposed to estimate and
correct the different effects that an OFDM symbol might experience. With
simulated transmission within MATLAB alone, the whole algorithm works fine
with the following simulated channel effects
* unknown arrival time by placing a random number of noise samples before
and after the sample stream.
* frequency offset simulated by multiplying the time domain digital samples
by an exponential term
* additive noise using function like like awgn()
* multipath by summing with say *cyclicprefixlength*/4 number of multipath
components each multiplied with a small amplitude with the original stream
* purposely placing the FFT window incorrectly and correcting the resulting
constellation for each symbol after demodulation etc.
* also found a linear phase error that was causing the whole constellation
to rotate proportionally with each subsequent OFDM symbol which I corrected
for.
I am no OFDM expert but from my reading, I thought I had accounted for the
different effects that can cause the signal to degrade.
So to bring me back to my actual question for the list is that the only
thing that occured to me is whether there is possible chance for there to
be a sampling frequency offset between the 2 devices when I attempt a real
transmission. Is there any to be expected ?
Best Regards,
Sanat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/f506ee59/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 29 May 2012 08:07:50 -0400
From: "Marcus D. Leech" <[email protected]>
To: Sanat Gulvadi <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sampling frequency offset between 2 USRP2
devices ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 05/29/2012 07:33 AM, Sanat Gulvadi wrote:
> Greetings,
>
> I apologize in advance if this question has already been asked or has
> already been addressed in the manual. I was unsuccessful in finding
> the answer. Should I expect an offset in the sampling frequencies
> between the 2 devices ? Just to add a little background :
> I am implementing an OFDM based communication system using 2
> USRP2-REV4s each with an RFX2400 board. My algorithm is supposed to
> estimate and correct the different effects that an OFDM symbol might
> experience. With simulated transmission within MATLAB alone, the whole
> algorithm works fine with the following simulated channel effects
> * unknown arrival time by placing a random number of noise samples
> before and after the sample stream.
> * frequency offset simulated by multiplying the time domain digital
> samples by an exponential term
> * additive noise using function like like awgn()
> * multipath by summing with say /cyclicprefixlength//4 number of
> multipath components each multiplied with a small amplitude with the
> original stream
> * purposely placing the FFT window incorrectly and correcting the
> resulting constellation for each symbol after demodulation etc.
> * also found a linear phase error that was causing the whole
> constellation to rotate proportionally with each subsequent OFDM
> symbol which I corrected for.
> I am no OFDM expert but from my reading, I thought I had accounted for
> the different effects that can cause the signal to degrade.
> So to bring me back to my actual question for the list is that the
> only thing that occured to me is whether there is possible chance for
> there to be a sampling frequency offset between the 2 devices when I
> attempt a real transmission. Is there any to be expected ?
>
> Best Regards,
> Sanat
Unless your devices are synchronized to an external reference, there is
a near-certainty that there will be an offset in the sampling
frequencies between the two devices -- the master clocks on the two
devices won't be synchronized, which leads both to sample-rate
differences, and actual tuned-frequency differences.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/2316a7e5/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 29 May 2012 09:11:30 -0400
From: Isaac Gerg <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<cadnn3yw6hx-ksgemjkuy1kzod3bxhwtwss5gbu1hexyfe+9...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh,
Is the diff you suggest in one of the releases of the UHD that I can
download and use today?
Isaac
On Tue, May 29, 2012 at 2:17 AM, Josh Blum <[email protected]> wrote:
>
> > Here is what I'm running:
> > \UHD\share\uhd\examples>tx_bursts --rep-delay 3 --repeat --freq 10000
> >
>
> Looks like the DAC is continuing to modulate. Even though the
> application stopped feeding it zeros, the modulator in the DAC is still
> spinning. Apparently flushing out zeros isnt doing the trick.
>
> It looks like the best thing ever is to just shutoff the digital part of
> the ADC when the USRP tx state machine is shutoff. The output of that
> tx_bursts app then looks quiet in between the bursts:
>
> > void enable_tx(bool enb){
> > _tx_enabled = enb;
> > _fx2_ctrl->usrp_tx_enable(enb);
> > + BOOST_FOREACH(const std::string &key, _dbc.keys())
> > + {
> > + _dbc[key].codec->enable_tx_digital(enb);
> > + }
> > }
>
> I cant think of a downside to this yet, so this diff should get in there.
>
> As far as older UHDs working, I dont even. The tx state machine was
> actually not disabled, and this somehow led to underflow condition and
> the output shutting off, possibly due to zeros being flushed out.
>
> -josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/bdc91e69/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 29 May 2012 16:50:37 +0200
From: Sanat Gulvadi <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Sampling frequency offset between 2 USRP2
devices ?
Message-ID:
<CAH12yLtYEvyk_Pux5tLX8Rojn1Wy=am74awnotn8ifovimw...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for the quick response. Could you help me understand this better
please? The different in the physical constraints that affect the clocks on
board the devices that cause the the carrier frequency offset also causes
differences in sampling rates ? So if I am using same
decimation/interpolation factors, setting the sampling frequency on Tx to
100e6/16 and on the Rx side also to 100e6/16 will still result in them
being sampled at different rates ? What would typically such numbers ? I
have the RFX2400 on both devices and carrier frequency set to 2.44GHz.
On Tue, May 29, 2012 at 2:07 PM, Marcus D. Leech <[email protected]> wrote:
> **
> On 05/29/2012 07:33 AM, Sanat Gulvadi wrote:
>
> Greetings,
>
> I apologize in advance if this question has already been asked or has
> already been addressed in the manual. I was unsuccessful in finding the
> answer. Should I expect an offset in the sampling frequencies between the 2
> devices ? Just to add a little background :
> I am implementing an OFDM based communication system using 2 USRP2-REV4s
> each with an RFX2400 board. My algorithm is supposed to estimate and
> correct the different effects that an OFDM symbol might experience. With
> simulated transmission within MATLAB alone, the whole algorithm works fine
> with the following simulated channel effects
> * unknown arrival time by placing a random number of noise samples before
> and after the sample stream.
> * frequency offset simulated by multiplying the time domain digital
> samples by an exponential term
> * additive noise using function like like awgn()
> * multipath by summing with say *cyclicprefixlength*/4 number of
> multipath components each multiplied with a small amplitude with the
> original stream
> * purposely placing the FFT window incorrectly and correcting the
> resulting constellation for each symbol after demodulation etc.
> * also found a linear phase error that was causing the whole constellation
> to rotate proportionally with each subsequent OFDM symbol which I corrected
> for.
> I am no OFDM expert but from my reading, I thought I had accounted for the
> different effects that can cause the signal to degrade.
> So to bring me back to my actual question for the list is that the only
> thing that occured to me is whether there is possible chance for there to
> be a sampling frequency offset between the 2 devices when I attempt a real
> transmission. Is there any to be expected ?
>
> Best Regards,
> Sanat
>
> Unless your devices are synchronized to an external reference, there is a
> near-certainty that there will be an offset in the sampling
> frequencies between the two devices -- the master clocks on the two
> devices won't be synchronized, which leads both to sample-rate
> differences, and actual tuned-frequency differences.
>
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>
>
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/1f51fdf7/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 29 May 2012 11:00:02 -0400
From: [email protected]
To: Sanat Gulvadi <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Sampling frequency offset between 2 USRP2
devices ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
The master oscillator on the USRP2 is a +/- 5PPM TCXO oscillator.
Crystal oscillators are imperfect, and they get closer to perfect the
more you spend on them. Which is why one generally uses an external
reference to move from 5PPM to 50PPB, using a GPSDO or similar.
So,
you can take the 5PPM estimate and plug it into your calculations.
-Marcus
On 29 May 2012 10:50, Sanat Gulvadi wrote:
> Thanks for
the quick response. Could you help me understand this better please? The
different in the physical constraints that affect the clocks on board
the devices that cause the the carrier frequency offset also causes
differences in sampling rates ? So if I am using same
decimation/interpolation factors, setting the sampling frequency on Tx
to 100e6/16 and on the Rx side also to 100e6/16 will still result in
them being sampled at different rates ? What would typically such
numbers ? I have the RFX2400 on both devices and carrier frequency set
to 2.44GHz.
>
> On Tue, May 29, 2012 at 2:07 PM, Marcus D. Leech
<[email protected] [1]> wrote:
>
>> On 05/29/2012 07:33 AM, Sanat
Gulvadi wrote:
>>
>>> Greetings,
>>>
>>> I apologize in advance if
this question has already been asked or has already been addressed in
the manual. I was unsuccessful in finding the answer. Should I expect an
offset in the sampling frequencies between the 2 devices ? Just to add a
little background :
>>> I am implementing an OFDM based communication
system using 2 USRP2-REV4s each with an RFX2400 board. My algorithm is
supposed to estimate and correct the different effects that an OFDM
symbol might experience. With simulated transmission within MATLAB
alone, the whole algorithm works fine with the following simulated
channel effects
>>> * unknown arrival time by placing a random number
of noise samples before and after the sample stream.
>>> * frequency
offset simulated by multiplying the time domain digital samples by an
exponential term
>>> * additive noise using function like like awgn()
>>> * multipath by summing with say _cyclicprefixlength_/4 number of
multipath components each multiplied with a small amplitude with the
original stream
>>> * purposely placing the FFT window incorrectly and
correcting the resulting constellation for each symbol after
demodulation etc.
>>> * also found a linear phase error that was causing
the whole constellation to rotate proportionally with each subsequent
OFDM symbol which I corrected for.
>>> I am no OFDM expert but from my
reading, I thought I had accounted for the different effects that can
cause the signal to degrade.
>>> So to bring me back to my actual
question for the list is that the only thing that occured to me is
whether there is possible chance for there to be a sampling frequency
offset between the 2 devices when I attempt a real transmission. Is
there any to be expected ?
>>>
>>> Best Regards,
>>> Sanat
>> Unless
your devices are synchronized to an external reference, there is a
near-certainty that there will be an offset in the sampling
>>
frequencies between the two devices -- the master clocks on the two
devices won't be synchronized, which leads both to sample-rate
>>
differences, and actual tuned-frequency differences.
>>
>> --
>>
Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy
Consortium
>> http://www.sbrac.org
>
> --
Links:
------
[1]
mailto:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/e2e531e2/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 29 May 2012 11:42:30 -0400
From: vegihat vegihat <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] high packet loss tunnel.py
Message-ID:
<CAAa8Va1eRoB=9OJHaGYRnA3T8cgw7CWTeSWBaQ2aOtY=fij...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello again :)
Well,after many experiments i have achieved a ping of 12% packet loss from
machine A to machine B but 100% packet loss from machine B to machine A
what i give on both machines is
$ sudo su
# ./tunnel.py -f 2.41G --bitrate 250k -m gmsk --tx-amplitude=0.2
--tx-gain=50 --rx-gain=50 -c 50
how could i archieve a full duplex communication?
2012/5/15 Josh Blum <[email protected]>
>
>
> On 05/15/2012 05:36 AM, vegihat vegihat wrote:
> > hello folks,
> >
> >
> > I have tried to set TCP/IP over GNU Radio between 2 USRP1 with RFX2400
> > daughterboards using the example
> > gnuradio/examples/digital/narrowband/tunnel.py
> >
> > i give
> > ./tunnel.py -f 2500e6 --bitrate 500k -v --tx-amplitude=1 --tx-gain=20000
> > --rx-gain=20000 -c 50
> >
>
> watch out for --tx-amplitude=1, the float values are +/-1.0. To avoid
> clipping, I would half this value while you are debugging.
>
> > and i take a ~80% packet loss.
> >
> >
> > How to reduce the high packet loss?
> >
> > if you want additional info , tell me.
> >
> > ps: i have attached the output of uhd_usrp_probe
> >
> >
>
> I recommend to observe the transmit spectrum. Is it at acceptable output
> power level and RF frequency.
>
> Same for the RX signal. Is the power level good, and the signal at the
> expected baseband frequency?
>
> -josh
>
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/5ec23613/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 29 May 2012 17:58:35 +0200
From: Sanat Gulvadi <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Sampling frequency offset between 2 USRP2
devices ?
Message-ID:
<CAH12yLtQCLBA_MXZ3hcB2ttW_WuBPCM_SLVP21VH=gpgzua...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I want to design the system without any external synchronization. All my
corrections I plan to do within the receiver. I apologize if I seem to be
asking the same question again. But in my case, with no synchronization
with an external reference clock, should I be assuming that 100e6/16 Hz
sampling rate on one USRP2 will not be the same as 100e6/16 Hz sampling
rate on the other ? If this is the case, am I also right in assuming that
this is because 100MHz doesn't really mean the same resulting real-world
clock frequency on different devices, because of these imperfections in the
crystals ?
Regards,
Sanat
On Tue, May 29, 2012 at 5:00 PM, <[email protected]> wrote:
> **
>
> The master oscillator on the USRP2 is a +/- 5PPM TCXO oscillator. Crystal
> oscillators are imperfect, and they get closer to perfect the more you
> spend on them. Which is why one generally uses an external reference to
> move from 5PPM to 50PPB, using a GPSDO or similar.
>
> So, you can take the 5PPM estimate and plug it into your calculations.
>
> -Marcus
>
>
>
> On 29 May 2012 10:50, Sanat Gulvadi wrote:
>
> Thanks for the quick response. Could you help me understand this better
> please? The different in the physical constraints that affect the clocks on
> board the devices that cause the the carrier frequency offset also causes
> differences in sampling rates ? So if I am using same
> decimation/interpolation factors, setting the sampling frequency on Tx to
> 100e6/16 and on the Rx side also to 100e6/16 will still result in them
> being sampled at different rates ? What would typically such numbers ? I
> have the RFX2400 on both devices and carrier frequency set to 2.44GHz.
>
> On Tue, May 29, 2012 at 2:07 PM, Marcus D. Leech <[email protected]>wrote:
>
>> On 05/29/2012 07:33 AM, Sanat Gulvadi wrote:
>>
>> Greetings,
>>
>> I apologize in advance if this question has already been asked or has
>> already been addressed in the manual. I was unsuccessful in finding the
>> answer. Should I expect an offset in the sampling frequencies between the 2
>> devices ? Just to add a little background :
>> I am implementing an OFDM based communication system using 2 USRP2-REV4s
>> each with an RFX2400 board. My algorithm is supposed to estimate and
>> correct the different effects that an OFDM symbol might experience. With
>> simulated transmission within MATLAB alone, the whole algorithm works fine
>> with the following simulated channel effects
>> * unknown arrival time by placing a random number of noise samples before
>> and after the sample stream.
>> * frequency offset simulated by multiplying the time domain digital
>> samples by an exponential term
>> * additive noise using function like like awgn()
>> * multipath by summing with say *cyclicprefixlength*/4 number of
>> multipath components each multiplied with a small amplitude with the
>> original stream
>> * purposely placing the FFT window incorrectly and correcting the
>> resulting constellation for each symbol after demodulation etc.
>> * also found a linear phase error that was causing the whole
>> constellation to rotate proportionally with each subsequent OFDM symbol
>> which I corrected for.
>> I am no OFDM expert but from my reading, I thought I had accounted for
>> the different effects that can cause the signal to degrade.
>> So to bring me back to my actual question for the list is that the only
>> thing that occured to me is whether there is possible chance for there to
>> be a sampling frequency offset between the 2 devices when I attempt a real
>> transmission. Is there any to be expected ?
>>
>> Best Regards,
>> Sanat
>>
>>
>>
>> Unless your devices are synchronized to an external reference, there
>> is a near-certainty that there will be an offset in the sampling
>> frequencies between the two devices -- the master clocks on the two
>> devices won't be synchronized, which leads both to sample-rate
>> differences, and actual tuned-frequency differences.
>>
>>
>>
>>
>> --
>> Marcus Leech
>> Principal Investigator
>> Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org
>>
>>
>
>
> --
>
>
>
>
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120529/ef4eafce/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 21, Issue 28
******************************************
