Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
On Sat, Sep 14, 2013 at 9:13 AM, Sylvain Munaut 246...@gmail.com wrote: Hi, Do you know if it makes any difference whether I set the bandwidth or sample rate first? Looking at the code, yes it does. You should set sample rate, then bandwidth. But honestly I think it shouldn't make a difference and the code should be fixed. Thanks for the info. I have reversed the order so that the sample rate is set before the bandwidth. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
Hi, Hi Brian, I didn't think of these cases - they make sense. I have added an option to set the bandwidth in the I/O configuration dialog. It is Great! available in the git repository. I could test it with hackrf anbd I hope somebody else can test it with the bladerf. Currently it does no checking - just passes the value directly to gr-osmosdr. Just as an example, we have here three LTE carriers, and even with a few cm of wire as antenna it is almost impossible to determine the three signals here. It all mixes to a mush of signals. They are located as neighbor channels, 10 MHz spacing (796/806/816 MHz), 9 MHz bandwidth each. Also the GSM bands are full of real and fake carriers what becomes visible when you have a look at the band ends and see signals off limits that simply are not there. With the USRP1 / WBX I only can see a part of this spectrum at a time, but almost without such aliasing artifacts. Otherwise, I like the little thing, seems reasonably sensitive even at high frequencies (checked this with watching LTE2600 signals), just the lower limit of 300 MHz is a bit ugly, down to 50 would be great :) Frequency is off 2ppm, not good enough for hopefully (soon?) coming openbts support, but I guess some recalibration can fix it. While writing this, I downloaded and compiled it. The filter itself works great, I can see it from the noise floor, just the images are not gone, seems that the RX simply is not as good as other SDRs. Anyway this is only a quick shot, I will test it more thoroughly these days, with different combinations of sampling rate and filter limits. Alex Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
And as an addition, when trying to adjust the gain, I get these messages on the console output: Invalid LNA gain requested: 3.48, setting to LNA_MAX (6dB) Invalid LNA gain requested: 3.66, setting to LNA_MAX (6dB) Invalid LNA gain requested: 3.96, setting to LNA_MAX (6dB) Invalid LNA gain requested: 4.14, setting to LNA_MAX (6dB) Invalid LNA gain requested: 4.2, setting to LNA_MAX (6dB) Invalid LNA gain requested: 4.26, setting to LNA_MAX (6dB) Invalid LNA gain requested: 4.32, setting to LNA_MAX (6dB) Invalid LNA gain requested: 4.38, setting to LNA_MAX (6dB) Invalid LNA gain requested: 4.44, setting to LNA_MAX (6dB) Invalid LNA gain requested: 4.5, setting to LNA_MAX (6dB) -Original Message- From: discuss-gnuradio-bounces+ralph=schmid@gnu.org [mailto:discuss- gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Ralph A. Schmid, dk5ras Sent: Saturday, 14 September, 2013 08:14 To: 'Alexandru Csete'; 'Brian Padalino' Cc: 'GNURadio Discussion List' Subject: Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth? Hi, Hi Brian, I didn't think of these cases - they make sense. I have added an option to set the bandwidth in the I/O configuration dialog. It is Great! available in the git repository. I could test it with hackrf anbd I hope somebody else can test it with the bladerf. Currently it does no checking - just passes the value directly to gr-osmosdr. Just as an example, we have here three LTE carriers, and even with a few cm of wire as antenna it is almost impossible to determine the three signals here. It all mixes to a mush of signals. They are located as neighbor channels, 10 MHz spacing (796/806/816 MHz), 9 MHz bandwidth each. Also the GSM bands are full of real and fake carriers what becomes visible when you have a look at the band ends and see signals off limits that simply are not there. With the USRP1 / WBX I only can see a part of this spectrum at a time, but almost without such aliasing artifacts. Otherwise, I like the little thing, seems reasonably sensitive even at high frequencies (checked this with watching LTE2600 signals), just the lower limit of 300 MHz is a bit ugly, down to 50 would be great :) Frequency is off 2ppm, not good enough for hopefully (soon?) coming openbts support, but I guess some recalibration can fix it. While writing this, I downloaded and compiled it. The filter itself works great, I can see it from the noise floor, just the images are not gone, seems that the RX simply is not as good as other SDRs. Anyway this is only a quick shot, I will test it more thoroughly these days, with different combinations of sampling rate and filter limits. Alex Ralph. ___ 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] bladeRF - gr-osmosdr - gqrx - bandwidth?
Hi, Do you know if it makes any difference whether I set the bandwidth or sample rate first? Looking at the code, yes it does. You should set sample rate, then bandwidth. But honestly I think it shouldn't make a difference and the code should be fixed. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
Hi, And as an addition, when trying to adjust the gain, I get these messages on the console output: Invalid LNA gain requested: 3.48, setting to LNA_MAX (6dB) Probably gqrx or gr-osmosdr treats the gain as a continuous value even though on the LMS it's not, there is only a few discrete value. They should be harmless warnings. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
Hi, I played a bit more, and I found that checking the iq balance option makes things worse, not better. Maybe the real huge center DC peak is too much? The blind IQ estimation doesn't always works, there is no magic solution. One of the case where it fails is if you're tuned to the center of a wideband signal ... It's really more meant if you have narrow band signals to the left or right of center (or both), but not with one big signal in the center. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
Probably gqrx or gr-osmosdr treats the gain as a continuous value even though on the LMS it's not, there is only a few discrete value. They should be harmless warnings. Yep, just wanted to mention it I played a bit more, and I found that checking the iq balance option makes things worse, not better. Maybe the real huge center DC peak is too much? Without iq balance checked it looks so far OK, much better than without the adjustable filter, and the previously mentioned situation around 800 MHz is a bit unfair - I found that right below the LTE band there is a strong 785 MHz DVB-T transmitter that mixes things up a bit. Outside the GSM 900 and 1800 bands the spurs (spurs? Signals almost as fat as the original ones!) seem gone with properly adjusted filter. Here some screenshots, taken with 10cm of wire directly plugged into the bladeRF; sitting on my table :) http://dk5ras.dyndns.org/screenshots/ Cheers, Sylvain Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
On Fri, Sep 13, 2013 at 8:19 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: Hi, I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, so I use a sampling rate of 8 Ms/s, and in this mode I have big problems with images from the neighbour frequencies that are still within the 26 MHz bandwidth, or whatever the maximum BW is. Is there some command to set this bandwidth to a smaller value? I assume that this would improve my RX experience a lot :) A quick look at osmocom showed me nothing, but maybe I missed smth. Ralph, I think the hardware supports down to 1 MHz analog bandwidth and gr-osmosdr also has support for that parameter, though I don't know whether the driver actually provides it. I can tell you for sure that gqrx does not support it yet, but you can try it in the gnuradio-companion. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
On Fri, Sep 13, 2013 at 2:19 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: Hi, I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, so I use a sampling rate of 8 Ms/s, and in this mode I have big problems with images from the neighbour frequencies that are still within the 26 MHz bandwidth, or whatever the maximum BW is. Is there some command to set this bandwidth to a smaller value? I assume that this would improve my RX experience a lot :) A quick look at osmocom showed me nothing, but maybe I missed smth. The gr-osmosdr interface allows for a bandwidth setting to be changed here: http://cgit.osmocom.org/gr-osmosdr/tree/lib/bladerf/bladerf_source_c.cc#n581 The driver will figure out which bandwidth is closest to what you want with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass filters. It will definitely make a world of difference by actually applying the LPF and removing the aliasing. As for official support for gqrx, it's next on our list. We need to get on the gqrx mailing list and figure out what code we need to write. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
On Fri, Sep 13, 2013 at 3:53 PM, Brian Padalino bpadal...@gmail.com wrote: On Fri, Sep 13, 2013 at 2:19 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: Hi, I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, so I use a sampling rate of 8 Ms/s, and in this mode I have big problems with images from the neighbour frequencies that are still within the 26 MHz bandwidth, or whatever the maximum BW is. Is there some command to set this bandwidth to a smaller value? I assume that this would improve my RX experience a lot :) A quick look at osmocom showed me nothing, but maybe I missed smth. The gr-osmosdr interface allows for a bandwidth setting to be changed here: http://cgit.osmocom.org/gr-osmosdr/tree/lib/bladerf/bladerf_source_c.cc#n581 The driver will figure out which bandwidth is closest to what you want with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass filters. It will definitely make a world of difference by actually applying the LPF and removing the aliasing. As for official support for gqrx, it's next on our list. We need to get on the gqrx mailing list and figure out what code we need to write. Actually, it was a deliberate choice not to have explicit support for that API call since it seemed unnecessary. Wouldn't one always want to use the narrowest analog bandwidth corresponding to a given sample rate? If yes, the setting may as well happen as part of the sample rate configuration and best handled at a layer that knows about the specific device. Am I wrong? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
On Fri, Sep 13, 2013 at 3:58 PM, Alexandru Csete oz9...@gmail.com wrote: On Fri, Sep 13, 2013 at 3:53 PM, Brian Padalino bpadal...@gmail.com wrote: On Fri, Sep 13, 2013 at 2:19 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: Hi, I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, so I use a sampling rate of 8 Ms/s, and in this mode I have big problems with images from the neighbour frequencies that are still within the 26 MHz bandwidth, or whatever the maximum BW is. Is there some command to set this bandwidth to a smaller value? I assume that this would improve my RX experience a lot :) A quick look at osmocom showed me nothing, but maybe I missed smth. The gr-osmosdr interface allows for a bandwidth setting to be changed here: http://cgit.osmocom.org/gr-osmosdr/tree/lib/bladerf/bladerf_source_c.cc#n581 The driver will figure out which bandwidth is closest to what you want with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass filters. It will definitely make a world of difference by actually applying the LPF and removing the aliasing. As for official support for gqrx, it's next on our list. We need to get on the gqrx mailing list and figure out what code we need to write. Actually, it was a deliberate choice not to have explicit support for that API call since it seemed unnecessary. Wouldn't one always want to use the narrowest analog bandwidth corresponding to a given sample rate? If yes, the setting may as well happen as part of the sample rate configuration and best handled at a layer that knows about the specific device. Am I wrong? One may want to listen to an LTE signal that is 5MHz wide, but sample at the standard 30.72MHz sample rate. In this case, I would think the LPF might want to be set smaller than 28MHz (maybe 8MHz?) but still sample at 30.72MHz? Maybe another case is wanting to see 5MHz worth of bandwidth, seeing a weak signal, move the weak signal into the LPF region, and tighten the filter such that you could increase the gain without clipping the ADC in case there is a near-by blocker? I agree you can shoot yourself in the foot very easily by separating the two of them and have lots of noise alias in, but keeping them separate, in my mind, is still a very reasonable thing to do. Maybe, for the case of gqrx, an option for gr-osmosdr at device opening (and passed to the constructor) is to have a bandwidth setting (auto or manual) that when put into auto mode will do as you suggest, and set the appropriate low pass filter bandwidth as well as warn if the sample rate is too low, and there will be aliasing due to the LPF not being tight enough? What are your thoughts? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
The hackrf module for example has a special value of 0.0 for the set_bandwidth call that basically mean auto-set. When you change the sample_rate it goes to automatic unless you manually set a specific bandwidth. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
On Fri, Sep 13, 2013 at 10:53 PM, Brian Padalino bpadal...@gmail.com wrote: On Fri, Sep 13, 2013 at 3:58 PM, Alexandru Csete oz9...@gmail.com wrote: On Fri, Sep 13, 2013 at 3:53 PM, Brian Padalino bpadal...@gmail.com wrote: On Fri, Sep 13, 2013 at 2:19 AM, Ralph A. Schmid, dk5ras ra...@schmid.xxx wrote: Hi, I am using bladeRF with gr-osmosdr, gnuradio 3.7 and gqrx, so far a fine radio. One thing, when using gqrx...I am limited to USB2.0 at the moment, so I use a sampling rate of 8 Ms/s, and in this mode I have big problems with images from the neighbour frequencies that are still within the 26 MHz bandwidth, or whatever the maximum BW is. Is there some command to set this bandwidth to a smaller value? I assume that this would improve my RX experience a lot :) A quick look at osmocom showed me nothing, but maybe I missed smth. The gr-osmosdr interface allows for a bandwidth setting to be changed here: http://cgit.osmocom.org/gr-osmosdr/tree/lib/bladerf/bladerf_source_c.cc#n581 The driver will figure out which bandwidth is closest to what you want with a minimum of 1.5MHz and a maximum of 28MHz for the low-pass filters. It will definitely make a world of difference by actually applying the LPF and removing the aliasing. As for official support for gqrx, it's next on our list. We need to get on the gqrx mailing list and figure out what code we need to write. Actually, it was a deliberate choice not to have explicit support for that API call since it seemed unnecessary. Wouldn't one always want to use the narrowest analog bandwidth corresponding to a given sample rate? If yes, the setting may as well happen as part of the sample rate configuration and best handled at a layer that knows about the specific device. Am I wrong? One may want to listen to an LTE signal that is 5MHz wide, but sample at the standard 30.72MHz sample rate. In this case, I would think the LPF might want to be set smaller than 28MHz (maybe 8MHz?) but still sample at 30.72MHz? Maybe another case is wanting to see 5MHz worth of bandwidth, seeing a weak signal, move the weak signal into the LPF region, and tighten the filter such that you could increase the gain without clipping the ADC in case there is a near-by blocker? I agree you can shoot yourself in the foot very easily by separating the two of them and have lots of noise alias in, but keeping them separate, in my mind, is still a very reasonable thing to do. Maybe, for the case of gqrx, an option for gr-osmosdr at device opening (and passed to the constructor) is to have a bandwidth setting (auto or manual) that when put into auto mode will do as you suggest, and set the appropriate low pass filter bandwidth as well as warn if the sample rate is too low, and there will be aliasing due to the LPF not being tight enough? What are your thoughts? Hi Brian, I didn't think of these cases - they make sense. I have added an option to set the bandwidth in the I/O configuration dialog. It is available in the git repository. I could test it with hackrf anbd I hope somebody else can test it with the bladerf. Currently it does no checking - just passes the value directly to gr-osmosdr. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] bladeRF - gr-osmosdr - gqrx - bandwidth?
On Fri, Sep 13, 2013 at 11:25 PM, Sylvain Munaut 246...@gmail.com wrote: The hackrf module for example has a special value of 0.0 for the set_bandwidth call that basically mean auto-set. When you change the sample_rate it goes to automatic unless you manually set a specific bandwidth. Sylvain, Do you know if it makes any difference whether I set the bandwidth or sample rate first? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
