Re: [Discuss-gnuradio] frequent phase slip with the new digital.costas_loop_cc
On 21/09/2012, at 11:37 PM, Tom Rondeau wrote: > On Fri, Sep 21, 2012 at 8:15 AM, Kyle Zhou wrote: >> >> >> Hi Tom, >> I spent some time on reading the code in gri_control_loop. However, the >> calculation from loop bandwidth to alpha and beta is quite complicated and >> from digital_costas_loop_cc I do not see how loop bandwidth is related to >> the loop behavior etc. >> Is the implementation based on some paper or text? I am really interested to >> read the theory. >> BTW, the phase detector is a decision-directed method. In a costas loop the >> phase error should be detected in a non-data aided way. so the block is not >> a costas loop strictly speaking. >> KZ > > Kyle, > > Correct, this is not really a 'Costas Loop', but that algorithm > doesn't really translate into the digital signal world all that well. > It's also not a great algorithm, frankly. What we call the > 'costas_loop_cc' block started off as a Costas loop but morphed into > something that's more applicable to software radio. > > One question, are you sending critically sampled symbols to the block? > This block is really meant to operate on 1 sps, preferably where that > one sample is at the optimal sampling point. So it's really meant to > come after a timing recovery loop and/or equalizer. This is the > scenario that I've used in the past with low SNRs. I can't tell you > the actual SNR, but visually it would have been down to 5 - 8 dB (just > looking at the constellation) for QPSK signals. > > So 2pi/1000 seems very small, but then again, that's why this value is > an adjustable parameter so you can tweak it for your purposes. > > If you're looking for more information on the control loop, I have a post > here: > http://www.trondeau.com/blog/2011/8/13/control-loop-gain-values.html > > Tom Hi Tom, Spent some time during the weekend on reading your post and now understand most of the bandwidth stuff. Thanks for the great work. Yes, in my system the phase recovery follows the timing recovery at one sample per symbol. I constructed a test in grc in baseband 1sps as attached. The frequency output from costas loop is connected to scope. When loop bandwidth is set to 2pi/100, the frequency varies a lot. I think this might explain the phase slip problem. Although the constellation seems OK, but the phase slip is not tolerable. A smaller loop bandwidth will improve the frequency variation as well as the phase slip. However, that leads to longer initial catch up time, which is proportional to inverse of bandwidth. For my case, this is fine since it is a continuous transmission system. But for a packet-wise transmission with short packet length, this could be of no use. KZ costas_qpsk_test.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Error: timed out waiting for TX and/or RX LO to lock
I had a similar problem a while back. Re-seating the daughter are was the fix. On Jul 3, 2012, at 6:27 PM, Julio Hector Aguilar Renteria wrote: > > Hi, all > > help error uhd_cal_tx_iq_balance --verbose > > root@usrp2:/usr/local/bin# uhd_cal_tx_iq_balance --verbose > linux; GNU C++ version 4.5.2; Boost_104200; UHD_003.004.002-177-unstable > > > Creating the usrp device with: ... > -- Opening a USRP2/N-Series device... > -- Current recv frame size: 1472 bytes > -- Current send frame size: 1472 bytes > Error: timed out waiting for TX and/or RX LO to lock > > ___ > 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] USRP / Laptop Road case?
im searching for a heavy duty road case to house my laptop and B100 for portable use. Optionally would like to stick some gel cells in there while away from AC power. I am thinking putting the laptop and usrp side be side on the top with batterys underneath, or laptop on top, usrp / battery under. Laptop pulls 20V, USRP 6V. Probably need to create a custom power supply / charging circuit? I checked the pelican line. the 1600 series looks like it might work.. Has anyone ventured into a project like this? If so i would like to see case / construction pics. thanks dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dr Dobbs Article about GNU Radio
FWIW http://www.drdobbs.com/embedded-systems/soft-radio/240007489 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Block missing GNU Radio Companion
Hi, I made a new block called "my_block", copying the example "blob_to_stream" provided in grcextras. I changed the files .cc, .h and .xml. Also, I added some lines in the CMakeList.txt files in the path: /grc /include/gnuradio/extras /lib Then, I compiled using: build/ sudo cmake ../ build/ sudo make check build/ sudo make install The problem is that I cannot see the block under "Extras" in GNU Radio Companion, however when I search (ie. when I type the name in GRC) "my block" in GNU Radio Companion the block is there. Anyone has faced something like this before? Do I need to change any other file for the compiling? Many thanks, Jose. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Waiting too much time for the GPS to be synchronized
Hi, I have two USRPs with GPS equipped. I found it always took too much for the two GPS to be sychronized to the same time (diff < 0.1s). Previously, I wait about 1 or 2 hours, but today 10 hours later, they still have time difference of 5s. I am using GPS indoor environment. -- Alex, *Dreams can come true – just believe.* ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Waiting too much time for the GPS to be synchronized
I think you need to put the antenna outside. In my situation, I put the antenna on the balcony. It usually takes me only several minutes to get an accurate time (diff<0.01). Wu From: discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.org [mailto:discuss-gnuradio-bounces+wu.ting=comf5.comm.eng.osaka-u.ac...@gnu.or g] On Behalf Of Alex Zhang Sent: Monday, September 24, 2012 2:51 PM To: gnuradio mailing list; usrp-users Cc: Tom Rondeau; j...@ettus.com Subject: [Discuss-gnuradio] Waiting too much time for the GPS to be synchronized Hi, I have two USRPs with GPS equipped. I found it always took too much for the two GPS to be sychronized to the same time (diff < 0.1s). Previously, I wait about 1 or 2 hours, but today 10 hours later, they still have time difference of 5s. I am using GPS indoor environment. -- Alex, Dreams can come true - just believe. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
