Re: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
On Tue, Apr 13, 2010 at 1:11 AM, Ian Holland ian.holl...@rlmgroup.com.au wrote: Hi All I have been studying up on the Costas loop, and have a couple of queries as to the benchmark_tx.py and benchmark_rx.py as a result. Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when using a Costas loop. Why does this not seem to occur with the benchmark_rx.py example? Is this related somehow to the PN code introduced by the scrambler. Another point of clarification for the way benchmark_rx works. We use differential modulation to account for the phase ambiguity. For BPSK, there would indeed be a 180 degree ambiguity, but we use DBPSK, which is insensitive to that. For anyone wanting to use non-differential BPSK, you would have to use information in the preamble to account for that. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
On Wed, Apr 14, 2010 at 06:48, Tom Rondeau trondeau1...@gmail.com wrote: Another point of clarification for the way benchmark_rx works. We use differential modulation to account for the phase ambiguity. For BPSK, there would indeed be a 180 degree ambiguity, but we use DBPSK, which is insensitive to that. For anyone wanting to use non-differential BPSK, you would have to use information in the preamble to account for that. There seems to be confusion about which script the original poster is referring to. Both the digital packet modem (digital) and the digital bit error rate tester (digital-bert) have scripts called benchmark_rx.py. The original question was how the digital-bert example was avoiding phase ambiguity while using straight BPSK and not differential BPSK. This is due to the use of a self-synchronizing digital scrambler prior to modulation. As you point out above, the receive chain in the digital packet modem is indeed using DBPSK to avoid the phase lock ambiguity, but that's not what the OP was referring to, unless I am mistaken. Either way it's important to distinguish between these two applications, as they work differently. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
On Mon, Apr 12, 2010 at 22:11, Ian Holland ian.holl...@rlmgroup.com.au wrote: I have been studying up on the Costas loop, and have a couple of queries as to the benchmark_tx.py and benchmark_rx.py as a result. Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when using a Costas loop. Why does this not seem to occur with the benchmark_rx.py example? Is this related somehow to the PN code introduced by the scrambler. The digital-bert example uses a self-synchronizing scrambler to generate a bit sequence that occupies the full baseband bandwidth of the channel. The scrambler/descrambler pair is insensitive to the phase ambiguity; however, this comes at the price of generating extra bit errors on the descrambled sequence for every bit error in the channel. Secondly, I came across another post in which it was mentioned the Costas loop should only operate on a single sample per symbol. However, as I read the source code, it seems as though it is actually passed sps samples per symbol, where sps 1. Have I misread something here? Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
Thanks Jonathon This clears things up a bit. By the way, the post I was referring to can be found at http://osdir.com/ml/discuss-gnuradio-gnu/2010-02/msg00098.html Maybe I misread the reply from Jason, but said reply seemed to suggest to me that a single sample per symbol should be used. Anyway, your response has cleared things up for me. Best Regards Ian. -Original Message- From: Johnathan Corgan [mailto:jcor...@corganenterprises.com] Sent: Tuesday, 13 April 2010 4:36 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Why no phase ambiguity in digital-bert... On Mon, Apr 12, 2010 at 22:11, Ian Holland ian.holl...@rlmgroup.com.au wrote: I have been studying up on the Costas loop, and have a couple of queries as to the benchmark_tx.py and benchmark_rx.py as a result. Firstly, for BPSK, there should in theory be a 180 deg. phase ambiguity when using a Costas loop. Why does this not seem to occur with the benchmark_rx.py example? Is this related somehow to the PN code introduced by the scrambler. The digital-bert example uses a self-synchronizing scrambler to generate a bit sequence that occupies the full baseband bandwidth of the channel. The scrambler/descrambler pair is insensitive to the phase ambiguity; however, this comes at the price of generating extra bit errors on the descrambled sequence for every bit error in the channel. Secondly, I came across another post in which it was mentioned the Costas loop should only operate on a single sample per symbol. However, as I read the source code, it seems as though it is actually passed sps samples per symbol, where sps 1. Have I misread something here? Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Why no phase ambiguity in digital-bert...
Thanks, I wasn't 100% clear if there were some conditions for interchangability after Jonathon's reply, but it sounds like not. Cheers Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Jason Uher Sent: Wednesday, 14 April 2010 12:19 PM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Why no phase ambiguity in digital-bert... I notice in the digital-bert example (benchmark_rx.py and receive_path.py), the Costas loop actually occurs prior to the MM sampler, without being wrapped inside the mpsk_receiver: (lines 104-105 of http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-examples/python/digi tal-bert/receive_path.py) self.connect(self, self._agc, self._rrc, self._costas, self._mm, self._c2r, self._slicer, self._descrambler, self._ber) Are these operations generally interchangeable? Thanks Ian. My explanation pertained to the benchmark_rx; but Johnathan already said it doesnt matter in his first reply ;) Not sure what post you are referring to. While a Costas loop can indeed operate on a single sample per symbol, it can also operate on more than that. Different strategies in a receiver chain places the frequency/phase synchronization at different places. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
