Re: [Discuss-gnuradio] synchronization questions
Lin, Thanks for the reply I am a newbie in the practical implementation world On the daughterboards, there is no synchonization processing. Everything is made in gnuradio software. You may use 'soft PLL' or 'soft baseband SYNC'. The daughterboard(FLEX 2400) has a PLL with frequency synthesizer. I think this is used for frequency synchronization and although I am not sure,but, there should be some way to change its frequency/phase on the fly. May be Marc or Eric can tell us more about this. With the development of full-digital receiver, now the baseband frequency synchronization is already used in products. Can you please give one example of such a commercial product. I'm not familiar with RF/IF. In my opinion, two stages are better. But only one stage is also acceptable. It depends on the signal characters. can you please explain why two stages are better and where are they implemented- in RF front end or both in Baseband only. More over, if only one stage is acceptable, where is it implemented- in RF front end or baseband. My questions are targetted towards typical receiver architectures as used in commercial products so that I can qualify the benefits involved in purely software implementations. Thanks once again SQ On 1/14/07, Lin HUANG On the daughterboards, there is no synchonization processing. Everything is made in gnuradio software. You may use 'soft PLL' or 'soft baseband SYNC'.l<[EMAIL PROTECTED]> wrote: 2007/1/15, science quest <[EMAIL PROTECTED]>: > > Hi > My appologies if the question is too vague or sounds naive- > I have read a number of papers(specially IEEE communication society > journals) on synchronization issues in communication- frequency, time and > phase sync. All these papers address the issue of synchronization in > baseband and no reference is made to the AFC present in transciever chips > (which in all probablity is controlled by baseband processor according to > some algorithm) . On the other hand literature from receiver circuit > perspective present approaches for synchronization in hardware by using > AFC/PLL etc and this is performed on RF signal. Considering this, I have > the following questions- > 1) Is the baseband approach of frequency synchronization only of > theroretical interest or are they actually used in products With the development of full-digital receiver, now the baseband frequency synchronization is already used in products. 2) Is the synchronization task perfomed in two stages? eg- first at RF/IF > level and then remaining offset in baseband software I'm not familiar with RF/IF. In my opinion, two stages are better. But only one stage is also acceptable. It depends on the signal characters. 3) How is synchronization achieved in USRP- at daughterboard hardware or > gnuradio software On the daughterboards, there is no synchonization processing. Everything is made in gnuradio software. You may use 'soft PLL' or 'soft baseband SYNC'. Thanks > SQ > > > > ___ > 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
Re: [Discuss-gnuradio] synchronization questions
2007/1/15, science quest <[EMAIL PROTECTED]>: Hi My appologies if the question is too vague or sounds naive- I have read a number of papers(specially IEEE communication society journals) on synchronization issues in communication- frequency, time and phase sync. All these papers address the issue of synchronization in baseband and no reference is made to the AFC present in transciever chips (which in all probablity is controlled by baseband processor according to some algorithm) . On the other hand literature from receiver circuit perspective present approaches for synchronization in hardware by using AFC/PLL etc and this is performed on RF signal. Considering this, I have the following questions- 1) Is the baseband approach of frequency synchronization only of theroretical interest or are they actually used in products With the development of full-digital receiver, now the baseband frequency synchronization is already used in products. 2) Is the synchronization task perfomed in two stages? eg- first at RF/IF level and then remaining offset in baseband software I'm not familiar with RF/IF. In my opinion, two stages are better. But only one stage is also acceptable. It depends on the signal characters. 3) How is synchronization achieved in USRP- at daughterboard hardware or gnuradio software On the daughterboards, there is no synchonization processing. Everything is made in gnuradio software. You may use 'soft PLL' or 'soft baseband SYNC'. Thanks SQ ___ 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
[Discuss-gnuradio] synchronization questions
Hi My appologies if the question is too vague or sounds naive- I have read a number of papers(specially IEEE communication society journals) on synchronization issues in communication- frequency, time and phase sync. All these papers address the issue of synchronization in baseband and no reference is made to the AFC present in transciever chips (which in all probablity is controlled by baseband processor according to some algorithm) . On the other hand literature from receiver circuit perspective present approaches for synchronization in hardware by using AFC/PLL etc and this is performed on RF signal. Considering this, I have the following questions- 1) Is the baseband approach of frequency synchronization only of theroretical interest or are they actually used in products 2) Is the synchronization task perfomed in two stages? eg- first at RF/IF level and then remaining offset in baseband software 3) How is synchronization achieved in USRP- at daughterboard hardware or gnuradio software Thanks SQ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Capturing data from various stages of modulationand demodulation
> -Original Message- > From: [EMAIL PROTECTED] [mailto:discuss- > [EMAIL PROTECTED] On Behalf Of Naveen Manicka > Sent: Sunday, January 14, 2007 8:01 PM > To: discuss-gnuradio@gnu.org > Subject: [Discuss-gnuradio] Capturing data from various stages of > modulationand demodulation > > Hi, > > What would be the best way to capture the raw data as it is passed from > each > block within GNURadio and represent in a GUI form? > Basically, if I send a "Hello World" from one machine to another, I can > see > it at the other end, but I am interested in somehow capturing and viewing > the data as it passes through each stage in GNURadio, after I generate in > the tunnel.py example. > > Any views on how I could do this? > I was exploring into representing the captured data as constellations, but > didn't know if I was proceeding in the right path. > > Thanks in advance, > Naveen Naveen, All of the digital modulators have a 'log' flag you can enable, which will drive every part of the modulator and demodulator to its own data file. If you want to see the constellation, you can look at "rx_mpsk_receiver.dat" (I think that's what it's called) using MATLAB/Octave and the read_complex_binary function provided in the gnuradio-core/src/utils. This returns a complex number, so plot(real(dat), imag(dat)). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Capturing data from various stages of modulation and demodulation
Hi, What would be the best way to capture the raw data as it is passed from each block within GNURadio and represent in a GUI form? Basically, if I send a "Hello World" from one machine to another, I can see it at the other end, but I am interested in somehow capturing and viewing the data as it passes through each stage in GNURadio, after I generate in the tunnel.py example. Any views on how I could do this? I was exploring into representing the captured data as constellations, but didn't know if I was proceeding in the right path. Thanks in advance, Naveen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error using SetLabel
Thank you so much Johnatan for the hint - that was the problem indeed!!! I followed the approach used in scopesink.py, encapsulating a gr message in a wx DATA EVENT, letting the panel manage the data extraction and presentation. It works fine now! thank you very much Matteo iz2eeq On Sun, 2007-01-14 at 08:30 -0800, Johnathan Corgan wrote: > On Sun, 2007-01-14 at 08:50 +0100, Matteo Campanella wrote: > > > Pango-ERROR **: file pango-layout.c: line 3230 > > (pango_layout_check_lines): assertion failed: (!layout->log_attrs) > > aborting... > > I have had a very similar problem in the past. > > I'd give it a high probability you are running into a threading issue. > wxWidgets is *not* reentrant, and updating controls from a thread > different from the one that is running the wxWidgets event loop will > create all sorts of problems eventually. > > The solution is to create a custom wxWidgets event, then use wxPostEvent > in your GR call back function. You then use a normal wxWidgets callback > function to handle that event to update the control. > > This link has some slightly outdated notes on doing this from C++; > you'll have to translate them mentally to the wxPython domain: > > http://www.wxwidgets.org/wiki/index.php/Custom_Events > > It's a major pain, especially if you have to do it for several different > event types. But the key difference is that wxWidgets main thread is > the one that is running and calling your wxWidgets event handler, so > there are no reentrancy issues. > > I beat my head against the wall for a couple days on this once :-( > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_empty in fpga
On Sun, Jan 14, 2007 at 12:45:48PM -0800, Matt Ettus wrote: > Eric Blossom wrote: > > > > > > This could work, with two caveats: > > > > (1) you're stuffing 0's into the input of the signal processing > > chain, instead of handing the underrun at the output of the > > signal processing chain. With the existing code, you're > > probably OK, but in general, if the idea is to zero the output > > when there's no input, I'd prefer to do it closer to the DACs. > > [ Don't let this comment stop you from trying this ;) ] > > > > Have to disagree with you here. The best place to do this is before the > signal processing chain, for exactly the reasons you state below... > > > (2) You're going to get the equivalent of a "key click". That is, > > wide band harmonics in the freq domain from the discontinuity in the > > time domain (step function). It would be better to ramp the last > > value down, say be doing the equivalent of an arithmetic shift right > > by 2. This really ought to be done by the code that feeds the DACs. > > > > The key clicks will get filtered if you do this before the upconverter. > They'll still be there, but they'll only be as wide as the baseband > bandwidth instead of the full 32 MHz. > > > I think a better place to fix this would be to filter the output of > > tx_a_a, tx_b_a, tx_a_b and tx_b_b in usrp_std.v based on their > > previous values and the delayed value of tx_empty. > > You don't need this filter if you do it before the interpolators. > > > I believe that a > > delay on the order of 12 clocks is about right. You'll need to count > > pipeline stages through the tx path to get it right. > > > > The delay through the interpolators is variable -- it depends on the > intepolation ratio. Again, this is why this should be done before the > interpolators. Agreed as long as the input being pushed into the signal processing pipeline is interpreted as samples. I think we're going to need to visit this problem again when somebody put a modulator into the FPGA. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_empty in fpga
Eric Blossom wrote: > > > This could work, with two caveats: > > (1) you're stuffing 0's into the input of the signal processing > chain, instead of handing the underrun at the output of the > signal processing chain. With the existing code, you're > probably OK, but in general, if the idea is to zero the output > when there's no input, I'd prefer to do it closer to the DACs. > [ Don't let this comment stop you from trying this ;) ] > Have to disagree with you here. The best place to do this is before the signal processing chain, for exactly the reasons you state below... > (2) You're going to get the equivalent of a "key click". That is, > wide band harmonics in the freq domain from the discontinuity in the > time domain (step function). It would be better to ramp the last > value down, say be doing the equivalent of an arithmetic shift right > by 2. This really ought to be done by the code that feeds the DACs. > The key clicks will get filtered if you do this before the upconverter. They'll still be there, but they'll only be as wide as the baseband bandwidth instead of the full 32 MHz. > I think a better place to fix this would be to filter the output of > tx_a_a, tx_b_a, tx_a_b and tx_b_b in usrp_std.v based on their > previous values and the delayed value of tx_empty. You don't need this filter if you do it before the interpolators. > I believe that a > delay on the order of 12 clocks is about right. You'll need to count > pipeline stages through the tx path to get it right. > The delay through the interpolators is variable -- it depends on the intepolation ratio. Again, this is why this should be done before the interpolators. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tx_empty in fpga
On Sat, Jan 13, 2007 at 06:54:20PM -0800, Loconut wrote: > > (originally posted on nabble without subscribing- previously was subscribed > as [EMAIL PROTECTED]) > > Trying to fix the problem of the transmitter repeating the last sample when > the fifo empties for doing gmsk on BasicTX/RX and/or LFRX/TX. > > bus_interface.v line 116 has: > assign txdata = tx_empty ? 32'b0 : txd; > > which says to me, load 32 bits of 0 when tx_empty, otherwise load the data.. > so why doesn't this work? Did I miss something (probably!) bus_interface.v is not used ;) > As an alternative, what about in tx_buffer around line 69: >if((load_next != channels) & !tx_empty) >begin > load_next <= #1 load_next + 4'd1; > case(load_next) > 4'd0 : tx_i_0 <= #1 fifodata; > 4'd1 : tx_q_0 <= #1 fifodata; > 4'd2 : tx_i_1 <= #1 fifodata; > 4'd3 : tx_q_1 <= #1 fifodata; > 4'd4 : tx_i_2 <= #1 fifodata; > 4'd5 : tx_q_2 <= #1 fifodata; > 4'd6 : tx_i_3 <= #1 fifodata; > 4'd7 : tx_q_3 <= #1 fifodata; > endcase // case(load_next) >end // if ((load_next != channels) & !tx_empty) > > what if instead of checking for tx_empty and loading fifodata we do this: >if(load_next != channels) > begin > load_next <= #1 load_next + 4'd1; > case(load_next) > 4'd0 : tx_i_0 <= #1 tx_empty ? 16'd0 : fifodata; > 4'd1 : tx_q_0 <= #1 tx_empty ? 16'd0 : fifodata; > 4'd2 : tx_i_1 <= #1 tx_empty ? 16'd0 : fifodata; > 4'd3 : tx_q_1 <= #1 tx_empty ? 16'd0 : fifodata; > 4'd4 : tx_i_2 <= #1 tx_empty ? 16'd0 : fifodata; > 4'd5 : tx_q_2 <= #1 tx_empty ? 16'd0 : fifodata; > 4'd6 : tx_i_3 <= #1 tx_empty ? 16'd0 : fifodata; > 4'd7 : tx_q_3 <= #1 tx_empty ? 16'd0 : fifodata; > endcase // case(load_next) > end // if ((load_next != channels) & !tx_empty) This could work, with two caveats: (1) you're stuffing 0's into the input of the signal processing chain, instead of handing the underrun at the output of the signal processing chain. With the existing code, you're probably OK, but in general, if the idea is to zero the output when there's no input, I'd prefer to do it closer to the DACs. [ Don't let this comment stop you from trying this ;) ] (2) You're going to get the equivalent of a "key click". That is, wide band harmonics in the freq domain from the discontinuity in the time domain (step function). It would be better to ramp the last value down, say be doing the equivalent of an arithmetic shift right by 2. This really ought to be done by the code that feeds the DACs. I think a better place to fix this would be to filter the output of tx_a_a, tx_b_a, tx_a_b and tx_b_b in usrp_std.v based on their previous values and the delayed value of tx_empty. I believe that a delay on the order of 12 clocks is about right. You'll need to count pipeline stages through the tx path to get it right. create a module, say module ramp_down_dac_when_empty ( input clock, input reset, input tx_empty, input [15:0] in, output reg [15:0] out ); // your code here... endmodule // ramp_down_dac_when_empty Then instantiate 4 of them to handle the filtering. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] alternate fpga image
On Sat, Jan 13, 2007 at 10:11:54PM -0800, Eric Blossom wrote: > On Sat, Jan 13, 2007 at 08:37:18PM -0800, Loconut wrote: > > > > I've tried placing my usrp_std.rbf in /usr/local/share/usrp/rev2 (I have a > > rev3 board) as well as in rev4, but that fails to load my firmware.. I also > > tried eiding transmit_path.py (testing gmsk) to be: > >self.u = usrp.sink_c(fusb_block_size=self._fusb_block_size, > > fusb_nblocks=self._fusb_nblocks, > > fpga_filename="/usr/local/share/usrp/rev2/usrp_std.rbf") > > > > at line 109 and that causes: > > [EMAIL PROTECTED] digital]# ./benchmark_tx.py -f 10e6 -r 100k -M .01 > > Can't find fpga bitstream: /usr/local/share/usrp/rev2/usrp_std.rbf > > > > yet: > > [EMAIL PROTECTED] digital]# ls -la /usr/local/share/usrp/rev2/ > > total 748 > > drwxr-xr-x 2 root root 4096 Jan 13 22:27 . > > drwxr-xr-x 4 root root 4096 Jan 13 10:08 .. > > -rw-r--r-- 1 root root 180809 Jan 13 10:08 multi_2rxhb_2tx.rbf > > -rw-r--r-- 1 root root 176948 Jan 13 10:08 std_2rxhb_2tx.rbf > > -rw-r--r-- 1 root root 173865 Jan 13 10:08 std_4rx_0tx.rbf > > -rw-r--r-- 1 root root 17622 Jan 13 10:08 std.ihx > > -rw-rw-r-- 1 root root 177037 Jan 13 22:05 usrp_std.rbf > > > > did I miss something? > > You can specify the fpga image to load using the fpga_filename keyword > argument. E.g., > > u = usrp.sink_c(fpga_filename = 'myfile.rbf') > > Eric Sorry, I must have been asleep when I sent this ;) FWIW, the reason we tack on the "path to the standard place" (which includes the rev) is to avoid accidentally loading an rbf for the wrong board rev into the USRP and killing it. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] error using SetLabel
On Sun, 2007-01-14 at 08:50 +0100, Matteo Campanella wrote: > Pango-ERROR **: file pango-layout.c: line 3230 > (pango_layout_check_lines): assertion failed: (!layout->log_attrs) > aborting... I have had a very similar problem in the past. I'd give it a high probability you are running into a threading issue. wxWidgets is *not* reentrant, and updating controls from a thread different from the one that is running the wxWidgets event loop will create all sorts of problems eventually. The solution is to create a custom wxWidgets event, then use wxPostEvent in your GR call back function. You then use a normal wxWidgets callback function to handle that event to update the control. This link has some slightly outdated notes on doing this from C++; you'll have to translate them mentally to the wxPython domain: http://www.wxwidgets.org/wiki/index.php/Custom_Events It's a major pain, especially if you have to do it for several different event types. But the key difference is that wxWidgets main thread is the one that is running and calling your wxWidgets event handler, so there are no reentrancy issues. I beat my head against the wall for a couple days on this once :-( -- Johnathan Corgan, AE6HO Corgan Enterprises LLC [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
