Re: [Discuss-gnuradio] frequent phase slip with the new digital.costas_loop_cc
On 21/09/2012, at 12:45 AM, Tom Rondeau wrote: > On Thu, Sep 20, 2012 at 9:56 AM, Kyle Zhou wrote: >> I adapted my codes from gnuradio-3.3 to the new 3.6 version. >> One of the changes is the new digital.costas_loop_cc is now implemented >> based on control_loop. >> The costas loop is used for phase recovery of a QPSK signal. >> But I noticed that with the new version, the output experiences a lot of >> phase slips. >> To be exact, the phase at the output rotate 90 degree from time to time. >> I changed it back to the old gr.costas_loop_cc and this did not happen. >> The setting for the old loop is alpha=0.01, beta=alpha*alpha/4, >> max_freq=2*pi*0.1, min_freq=-max_freq. >> The setting for the new loop is loop bandwidth = 2*pi/100 >> >> The new version is only good when SNR is very high, say 13dB+ >> >> Any has encountered the same problem? or am I doing something wrong? >> KZ > > Hi Kyle, > > I was using this just last week in a demonstration and hadn't noticed > any problems. If you can pin-point what's going wrong, though, I'll be > sure to fix it. > > Tom 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multiple USRP's on Switch
Hi all i have 2 USRP N210 connected via switch i want to make cognitive network on USRP's, for this i need multiple USRP's connection, i implemented 2X MIMO connection but there is allot of delay on slave USRP. software specs : GNU Radio 3.6.2 linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.004.002-34-stable -- -- UHD Device 0 -- Device Address: type: usrp2 addr: 192.168.10.3 name: serial: E1R12VBNW -- -- UHD Device 1 -- Device Address: type: usrp2 addr: 192.168.10.2 name: serial: E1R12VCNW Dose any one know how to configure UHD sink block for multiple USRP's connection; i have got fallowing error... Error : Using Volk machine: sse4_2_32 Registered event listener change listener: true LSSLSSLSSLSSLSSLSSLSSLSSLSSLSSLSSLSSLSSL Thanks Regards Muhammad Junaid m_junaid0...@yahoo.com http://junaidmuhammad.webs.com/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] frequent phase slip with the new digital.costas_loop_cc
On Fri, Sep 21, 2012 at 8:15 AM, Kyle Zhou wrote: > > On 21/09/2012, at 12:45 AM, Tom Rondeau wrote: > >> On Thu, Sep 20, 2012 at 9:56 AM, Kyle Zhou wrote: >>> I adapted my codes from gnuradio-3.3 to the new 3.6 version. >>> One of the changes is the new digital.costas_loop_cc is now implemented >>> based on control_loop. >>> The costas loop is used for phase recovery of a QPSK signal. >>> But I noticed that with the new version, the output experiences a lot of >>> phase slips. >>> To be exact, the phase at the output rotate 90 degree from time to time. >>> I changed it back to the old gr.costas_loop_cc and this did not happen. >>> The setting for the old loop is alpha=0.01, beta=alpha*alpha/4, >>> max_freq=2*pi*0.1, min_freq=-max_freq. >>> The setting for the new loop is loop bandwidth = 2*pi/100 >>> >>> The new version is only good when SNR is very high, say 13dB+ >>> >>> Any has encountered the same problem? or am I doing something wrong? >>> KZ >> >> Hi Kyle, >> >> I was using this just last week in a demonstration and hadn't noticed >> any problems. If you can pin-point what's going wrong, though, I'll be >> sure to fix it. >> >> Tom > > 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building blocks of gnuradio-companion - GR file sink
On Thu, Sep 20, 2012 at 11:05 PM, Hussain, Mushabbar wrote: > Hi, > > We are trying to build a simulated model using the building blocks of > gnuradio-companion tool. In the GRC model one of the blocks is the GR file > sink block which is intended for storage of the data. Now the issue is that > if the program is run for a longer period of time(say 40-60m mins) the data > file size would grow huge(may be in GB), somehow we want to > prevent/restrict the data file size to a few MB’s – like a fixed size > circular buffer. Is there any way GRC API which would allows us to set the > filesize? Another harder way is to write code to check file size and if that > exceeds certain limit, we can backup the data and flush the file to restart > storing again. > > Please comment what would be an easier way to achieve this? > > Regards, > > Hussain Hussain, Just to be clear, do you want to run the program indefinitely but only save the last N samples into a file? Or do you want to just run the program long enough to generate a file of N samples? The the latter, you can easily use the gr.head (just look for Head in the 'Misc' section in GRC). If you want the former, there's nothing in GNU Radio that will do this out of the box, so you'll have to write your own block (unless someone has one already that does this). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] a question to make sure Tx and Rx start times w.r.t. each other
Hi everybody, I have been trying to design a ionosonde with USRPs in my final year project. I am responsible for the signal processing part of the project. I will have been using USRP1 untill hardware part, that is amplifier and antennas, is set up. I have been using another USRP1 & a PC to model an HF channel, and processing the delayed signal in my own PC. As far as I see in web site of Ettus Research, http://files.ettus.com/uhd_docs/manual/html/usrp1.html , and several similar projects completed USRP2s are better to use for such a purpose. In processing of the received signal, the peak of the result of the x-correlation must not even be different from the its actual instant as three micro seconds. That is why, I need to make sure if Tx and Rx starts working at the same instant and perfectly synchronized, in other words , if they perform parallelly at all? Thanks in advance, Abdullah___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Messaging Blocks
Hello, In my current flow-graph I need to break data out ofgnuradio then feed it back once processed. I'm trying to use messaging blocks to do this but with no luck, actually my code is seg faulting. Would using message blocks, causing different flow rates, cause instability and segmentation faults? If I have a complex NumPy array say of 1000 elements, what is the best way to cast it back into a gnuradio message queue? Regards, -Travis ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_block::set_history()
On Thu, Sep 20, 2012 at 8:15 PM, Kyle Zhou wrote: > > > I have a general work function for which I will use GNU Radio's history > > functionality. In the block's constructor, I call set_history( m ). I cast > the input buffer in the standard way: > > const float *in = (const float *) input_items[0]; > > My question is wheere in[0] refers to in the buffer. It would make sense to > me that noutput_items is the number of new items for the block to consume > and ninput_items[0] refers to the total number of data in the buffer. So, > in[noutput_items-1] is the last element of the array, in[0] is the start of > the new items, and the in[-m] refers to the beginning of the history block. > Thus, ninput_items[0] is greater than or equal to m + noutput_items. > > I don't know if this assumption is true and would be pleased if someone knew > how this works. The GNU Radio API is somewhat vague in this respect. Thanks > in advance! > > > * > > > From you description you should use sync block. > Anyway, my knowledge on history is: (assuming 1:1 in-out ratio) > in[0] to in[noutput_items+m-2] are what you can use to produce noutput_items > outputs. > in[0] is the oldest and in[noutput_items+m-2] is the newest sample. > ninput_items[0]==noutput_items+m-1 > > Any one can correct me? > KZ Kyle, Yes, that's how the set_history works. Basically, when told you have noutput_items, you know that you have noutput_items+(history()-1). The default for set_history(m) is m=1, so that's where the -1 comes from. It allows you to look beyond the number of items you've been given. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_block::set_history()
Tom and Kyle, Thanks for your replies. Suppose I want in[0] to refer to the beginning of the new data. Then I could do this: const float *in = (const float *) input_items[history()-1]; So in[noutput_items-1] is the last? Thanks! Chris -- View this message in context: http://gnuradio.4.n7.nabble.com/gr-block-set-history-tp37687p37705.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
Re: [Discuss-gnuradio] gr_block::set_history()
On Fri, Sep 21, 2012 at 1:18 PM, cjpatton wrote: > Tom and Kyle, > > Thanks for your replies. Suppose I want in[0] to refer to the beginning of > the new data. Then I could do this: > >const float *in = (const float *) input_items[history()-1]; > > So in[noutput_items-1] is the last? Thanks! > > Chris Chris, Close. Remember that input_buffers is a vector of buffers. So you want the first buffer and then offset it. I think this should work: >const float *in = (const float *)(&input_items[0][history()-1]); A good one to look at is the gr_quadrature_demod_cf block where the history is set to 2 and the work function has: const float *in = (const float *) input_items[0]; in++; So the 'in++' sets the pointer forward that one sample so that in[i-1] is valid. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_block::set_history()
Hello Tom, Of course, how could I forget? I had to modify your code a bit to get to work, however: const float *in = (const float *) &((const float*)input_items[0])[history()-1]; It just needed a type cast in there. My code works now. The suggestion about gr_quadrature_demod_cf is very helpful; this will be a good reference moving forward on this project. Many thanks Chris Patton -- View this message in context: http://gnuradio.4.n7.nabble.com/gr-block-set-history-tp37687p37707.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
Re: [Discuss-gnuradio] gr_block::set_history()
On Fri, Sep 21, 2012 at 1:47 PM, cjpatton wrote: > Hello Tom, > > Of course, how could I forget? I had to modify your code a bit to get to > work, however: > >const float *in = (const float *) &((const > float*)input_items[0])[history()-1]; > > It just needed a type cast in there. My code works now. The suggestion about > gr_quadrature_demod_cf is very helpful; this will be a good reference moving > forward on this project. Many thanks > > Chris Patton Yeah, I figured I had gotten something like that wrong. You got the point, though. tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] not able to play fm receiver application
Hi, I have a USRP N210 with basicRX daughterboard. I ran uhd_wbfm_receive.grc application. But I cannot tune to any FM radio station. I get warning like -- UHD Warning: The hardware does not support the requested RX frequency: Target frequency: 88.50 MHz Actual frequency: -11.50 MHz >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE audio_alsa_sink[hw:0,0]: unable to support sampling rate 4 card requested 44100 instead. -- There was a similar post in the archive, but the reply said, it is ok to get this warning. If the card supports 88.5 MHz, then why is it not able to receive the station? I read somewhere that basicRX daughterboard needs an external RF component. Is the problem arising because I do not have an external RF component? If so, what kind of external RF component I should buy (from Ettus?)? Here is the usrp_probe output linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4); Boost_104100; UHD_003.004.003-221-g9d6f9492 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The recv buffer could not be resized sufficiently. Target sock buff size: 5000 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.rmem_max=5000 UHD Warning: The send buffer could not be resized sufficiently. Target sock buff size: 1048576 bytes. Actual sock buff size: 131071 bytes. See the transport application notes on buffer resizing. Please run: sudo sysctl -w net.core.wmem_max=1048576 -- Detecting internal GPSDO not found UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam _ / | Device: USRP2 / N-Series Device | _ |/ | | Mboard: N210r4 | | hardware: 2577 | | mac-addr: a0:36:fa:25:40:2f | | ip-addr: 192.168.10.2 | | subnet: 255.255.255.255 | | gateway: 255.255.255.255 | | gpsdo: none | | serial: E2R20PFUP | | FW Version: 12.3 | | FPGA Version: 10.0 | | | | Time sources: none, external, _external_, mimo | | Clock sources: internal, external, mimo | | Sensors: mimo_locked, ref_locked | | _ | |/ | | | RX DSP: 0 | | | Freq range: -50.000 to 50.000 Mhz | | _ | |/ | | | RX DSP: 1 | | | Freq range: -50.000 to 50.000 Mhz | | _ | |/ | | | RX Dboard: A | | | ID: Basic RX (0x0001) | | | Serial: EAR00ZFRB | | | _ | | |/ | | | | RX Frontend: AB | | | | Name: BasicRX (AB) | | | | Antennas: | | | | Sensors: | | | | Freq range: -250.000 to 250.000 Mhz | | | | Gain Elements: None | | | | Connection Type: IQ | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Frontend: BA | | | | Name: BasicRX (BA) | | | | Antennas: | | | | Sensors: | | | | Freq range: -250.000 to 250.000 Mhz | | | | Gain Elements: None | | | | Connection Type: QI | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Frontend: A | | | | Name: BasicRX (A) | | | | Antennas: | | | | Sensors: | | | | Freq range: -250.000 to 250.000 Mhz | | | | Gain Elements: None | | | | Connection Type: I | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Frontend: B | | | | Name: BasicRX (B) | | | | Antennas: | | | | Sensors: | | | | Freq range: -250.000 to 250.000 Mhz | | | | Gain Elements: None | | | | Connection Type: Q | | | | Uses LO offset: No | | | _ | | |/ | | | | RX Codec: A | | | | Name: ads62p44 | | | | Gain range digital: 0.0 to 6.0 step 0.5 dB | | | | Gain range fine: 0.0 to 0.5 step 0
Re: [Discuss-gnuradio] no fft or scope sink
sorted listed under gui -- View this message in context: http://gnuradio.4.n7.nabble.com/no-fft-or-scope-sink-tp37686p37710.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] Reg : WCDMA data
Does anyone have recorded WCDMA downlink data . I am trying to work on echo canceller for WCDMA repeaters using gnuradio. I tried getting data from WCDMA model of Simulink but the received power level has wide variance. Normally it shall be from -50 to -80 dB but the Simulink model is giving data with power level +8 to -70 dB. If anybody having the same and willing to share it will be of great help. -- View this message in context: http://gnuradio.4.n7.nabble.com/Reg-WCDMA-data-tp37711.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
