Re: [Discuss-gnuradio] trouble with gr_multiply_const_ff
Hi Marcus, Thanks for your attention. I have upload a bigger size image below. the x axis is sampling point which reflects time and the y axis is margin which reflects the power. I plot the image from the rx block of the gen2_reader project. The signal is transmitted by the tx block of gen2_reader. The to_complex block is use to trasfer the float data to complex data for transmitting by tx block. The input data of gr_multiply_const_ff block are the same, they come from the reader block. It's weird that the output data of gr_multiply_const_ff are the same in matlab image with different amplitude(bigger than 40 or not) but the signal tx block transmiting are not. I can't figure out how the amplitude in gr_multiply_const_ff block influence the signal in tx block without change the output data. By the way, we use a gen2_monitor with another usrp to get signal transmitted from the gen2_reader tx blcok, it has the same signal image to the rx block of gen2_reader. So, we can assume that there is no problem with our equipments Lee http://gnuradio.4.n7.nabble.com/file/n45025/amp5000.png -- View this message in context: http://gnuradio.4.n7.nabble.com/trouble-with-gr-multiply-const-ff-tp45018p45025.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] quadrature_demod losing weak signals
On Sat, Nov 30, 2013 at 2:50 AM, Kevin Reid kpr...@switchb.org wrote: This seems like a bug, but I want to check first that I'm not having unreasonable expectations. I'm using GNU Radio 3.7.2. If the amplitude of the input to quadrature_demod_cf is less than about 10^(-2.23), then the output samples are zero instead of the demodulated signal. Since such an exponent is well within the range for (complex) single-float samples, this seems like a problem with the arithmetic used by quadrature_demod. I noticed it because my analog FM receiver would produce complete silence instead of static, despite not having any squelch enabled; unfortunately, it also produces silence on weak signals that would otherwise be intelligible. I have a notion that this did not occur in older GNU Radio versions (e.g. 3.6) but I'm not in a good position to test exactly where the problem might have been introduced. I've attached a GRC flowgraph for experimenting with the behavior, and a screenshot of what the demodulated output looks like just at the threshold of failure (the signal is 200 samples per cycle). I tried your grc file and the scope sink shows a perfect sinewave here. So maybe it is a voilk issue or the gr::fast_atan2f on your parchitecture. Mine was using avx_64_mmx_orc Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Detecting internal GPSDO.... not found on first connection
Dear All, my device: USRP N200 System: Ubuntu 13.04 1. I always get this on first connections (the next ones are okay): $ uhd_usrp_probe linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.006.000-0-g7788c692 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- Detecting internal GPSDO not found 2. Besides that I usually lose the connection with the port I was connected. 3. If I wait for some time, I again lose the connection on next command and each time I have to type : sudo ifconfig eth0 192.168.10.1. Do you think these are normal? -- NE___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] trouble with gr_multiply_const_ff
On Sat, Nov 30, 2013 at 5:00 AM, atools_cook liwenpux...@gmail.com wrote: Hi Marcus, Thanks for your attention. I have upload a bigger size image below. the x axis is sampling point which reflects time and the y axis is margin which reflects the power. I plot the image from the rx block of the gen2_reader project. The signal is transmitted by the tx block of gen2_reader. The to_complex block is use to trasfer the float data to complex data for transmitting by tx block. The input data of gr_multiply_const_ff block are the same, they come from the reader block. It's weird that the output data of gr_multiply_const_ff are the same in matlab image with different amplitude(bigger than 40 or not) but the signal tx block transmiting are not. I can't figure out how the amplitude in gr_multiply_const_ff block influence the signal in tx block without change the output data. By the way, we use a gen2_monitor with another usrp to get signal transmitted from the gen2_reader tx blcok, it has the same signal image to the rx block of gen2_reader. So, we can assume that there is no problem with our equipments Lee Lee, You know that the UHD transmitter takes signal samples from 0 to 1? So after the multiply_const block, what's the value of the signal? If it's 1, you're not going to get any change in the transmit power. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] quadrature_demod losing weak signals
On Sat, Nov 30, 2013 at 5:09 AM, Alexandru Csete oz9...@gmail.com wrote: On Sat, Nov 30, 2013 at 2:50 AM, Kevin Reid kpr...@switchb.org wrote: This seems like a bug, but I want to check first that I'm not having unreasonable expectations. I'm using GNU Radio 3.7.2. If the amplitude of the input to quadrature_demod_cf is less than about 10^(-2.23), then the output samples are zero instead of the demodulated signal. Since such an exponent is well within the range for (complex) single-float samples, this seems like a problem with the arithmetic used by quadrature_demod. I noticed it because my analog FM receiver would produce complete silence instead of static, despite not having any squelch enabled; unfortunately, it also produces silence on weak signals that would otherwise be intelligible. I have a notion that this did not occur in older GNU Radio versions (e.g. 3.6) but I'm not in a good position to test exactly where the problem might have been introduced. I've attached a GRC flowgraph for experimenting with the behavior, and a screenshot of what the demodulated output looks like just at the threshold of failure (the signal is 200 samples per cycle). I tried your grc file and the scope sink shows a perfect sinewave here. So maybe it is a voilk issue or the gr::fast_atan2f on your parchitecture. Mine was using avx_64_mmx_orc Alex Works fine for me, too. Alex is probably right that there's something going on with the SIMD architecture of your processor. The quadrature_demod_cf block uses the volk_32fc_x2_multiply_conjugate_32fc kernel. On my machine, I'm using the SSE3 version of the kernel for both aligned and unaligned architectures (in ~/.volk/volk_config). That kernel only has SSE3 and generic kernels. You might try changing those to 'generic' to see if that makes a difference on your machine. For more details on VOLK and how the configure file is structured, see: http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] quadrature_demod losing weak signals
On Nov 30, 2013, at 2:09, Alexandru Csete oz9...@gmail.com wrote: On Sat, Nov 30, 2013 at 2:50 AM, Kevin Reid kpr...@switchb.org wrote: If the amplitude of the input to quadrature_demod_cf is less than about 10^(-2.23), then the output samples are zero instead of the demodulated signal. I tried your grc file and the scope sink shows a perfect sinewave here. Just checking, since I didn't mention it before: the default value of the slider is the level well above where it fails. Does it fail for you if you turn it down? So maybe it is a voilk issue or the gr::fast_atan2f on your parchitecture. Mine was using avx_64_mmx_orc Thank you, I should have mentioned my volk configuration. fast_atan2f doesn't appear to have any volk dependency... ...but I think I've spotted the problem. In fast_atan2f, we have this recently-introduced (Nov 6) code, where the epsilon used to be a comparison with zero: /* don't divide by zero! */ if((y_abs 1.5E-5) (x_abs 1.5E-5)) return 0.0; Since the preceding multiply_conjugate should square the magnitude, this choice of epsilon accounts for the threshold I found empirically. Given this, I'm going to file an issue requesting that this epsilon be reduced. (The only alternative that comes to mind is to place an AGC block before the demodulator, which seems unlikely to be better from a numerical perspective). -- Kevin Reid http://switchb.org/kpreid/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] quadrature_demod losing weak signals
On Sat, Nov 30, 2013 at 10:55 AM, Kevin Reid kpr...@switchb.org wrote: On Nov 30, 2013, at 2:09, Alexandru Csete oz9...@gmail.com wrote: On Sat, Nov 30, 2013 at 2:50 AM, Kevin Reid kpr...@switchb.org wrote: If the amplitude of the input to quadrature_demod_cf is less than about 10^(-2.23), then the output samples are zero instead of the demodulated signal. I tried your grc file and the scope sink shows a perfect sinewave here. Just checking, since I didn't mention it before: the default value of the slider is the level well above where it fails. Does it fail for you if you turn it down? Yes, same behavior if I turn it down; not unexpected giving what you found below. So maybe it is a voilk issue or the gr::fast_atan2f on your parchitecture. Mine was using avx_64_mmx_orc Thank you, I should have mentioned my volk configuration. fast_atan2f doesn't appear to have any volk dependency... ...but I think I've spotted the problem. In fast_atan2f, we have this recently-introduced (Nov 6) code, where the epsilon used to be a comparison with zero: /* don't divide by zero! */ if((y_abs 1.5E-5) (x_abs 1.5E-5)) return 0.0; Since the preceding multiply_conjugate should square the magnitude, this choice of epsilon accounts for the threshold I found empirically. Given this, I'm going to file an issue requesting that this epsilon be reduced. (The only alternative that comes to mind is to place an AGC block before the demodulator, which seems unlikely to be better from a numerical perspective). -- Kevin Reid http://switchb.org/kpreid/ Agreed. This threshold should be reduced. Can you experiment with that threshold to see if there's any lower limit that might be problematic (my default threshold, for some reason, is 1e-20; would want to make sure that doesn't cause something else in the math to blow up). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detecting internal GPSDO.... not found on first connection
Whenever I hear of anyone struggling with ethernet ports going up and down unexpectedly on Ubuntu it nearly always comes down to Ubuntu's Network Manager trying to be clever. Go google information on how to disable Ubuntu from automatically managing network interfaces for the version you are using, then ifconfig will likely do what you expect it to. As far as GPSDO not being found, it takes time for GPS's to achieve a lock after a power cycle event, easily on the order of seconds. The USRP is just parsing ASCII string output from the GPS on a UART. I doubt this is indicative of any type of real problem in your case. Note also that GPSDO's need to be powered up for many minutes before they have a stable clock that meets there specified performance. -Ian On Nov 30, 2013, at 5:56 AM, Nasi nesaz...@mail.ru wrote: Dear All, my device: USRP N200 System: Ubuntu 13.04 1. I always get this on first connections (the next ones are okay): $ uhd_usrp_probe linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.006.000-0-g7788c692 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes -- Detecting internal GPSDO not found 2. Besides that I usually lose the connection with the port I was connected. 3. If I wait for some time, I again lose the connection on next command and each time I have to type : sudo ifconfig eth0 192.168.10.1. Do you think these are normal? -- NE ___ 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
Re: [Discuss-gnuradio] quadrature_demod losing weak signals
On Nov 30, 2013, at 8:22, Tom Rondeau t...@trondeau.com wrote: On Sat, Nov 30, 2013 at 10:55 AM, Kevin Reid kpr...@switchb.org wrote: /* don't divide by zero! */ if((y_abs 1.5E-5) (x_abs 1.5E-5)) return 0.0; Since the preceding multiply_conjugate should square the magnitude, this choice of epsilon accounts for the threshold I found empirically. Given this, I'm going to file an issue requesting that this epsilon be reduced. (The only alternative that comes to mind is to place an AGC block before the demodulator, which seems unlikely to be better from a numerical perspective). Agreed. This threshold should be reduced. Can you experiment with that threshold to see if there's any lower limit that might be problematic (my default threshold, for some reason, is 1e-20; would want to make sure that doesn't cause something else in the math to blow up). I have modified a copy of fast_atan2f to have the test (y_abs == 0.0f) (x_abs == 0.0f) and plotted the results of fast_atan2f(k*sin(angle), k*cos(angle)) against both angle and atan2f(k*sin(angle), k*cos(angle)) at various exponents for k. At small magnitudes fast_atan2f is a _better_ approximation to regular atan2f than it is at magnitudes close to 1, and the error compared to the original angle (which should partly be attributed to representing sin and cos values) has the same patterning at all scales. At no point does fast_atan2f emit complete nonsense; it is consistent all the way down to the point at which both y and x are rounded to 0.0. My conclusion is that fast_atan2f is as good as it ever is all the way down to the minimum representable values (~ 1e-45), and that one might as well revert the code to an equality test with 0.0 (or perhaps y_abs = 0.0 if a linter needs to be satisfied). That said, I'm no expert on numerics and I might well have missed some particular undesirable behavior that should be avoided. Therefore, I will attach the tools I wrote to test the behavior. main.cc generates a table of error values (the parameters are hardcoded), and run.sh will build it and plot the values using the gnuplot script. (Note that there is a special case in main.cc to emit a constant nonzero value when x and y are exactly zero after being scaled down; that value is intended as an out-of-band marker and is not an actual error.) main.cc Description: Binary data plot.gnuplot Description: Binary data run.sh Description: Binary data -- Kevin Reid http://switchb.org/kpreid/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
