From 246tnt at gmail.com Fri Feb 3 19:06:19 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Fri, 3 Feb 2017 20:06:19 +0100 Subject: gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call In-Reply-To: References: Message-ID: Hi Raj, > I'm using the latest fosphor from git > (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird (and I > believe related) issues. Firstly, I see the following error: > > [+] Selected device: TITAN X (Pascal) > [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable to > queue clear of spectrum buffer That's really weird indeed. Although I've seen it before. Can't remember exactly what it was though ... > This is CL_INVALID_VALUE returning from clEnqueueFillBuffer, so I added some > debug fprints to cl.c to see what parameters were being passed into > clEnqueueFillBuffer: Watchout that CL 1.2 might not be supported by NVidia's driver and so it might use the fallback path defined in cl_compat.c > But there is this one condition that might be met, which is that somehow > size (16384) is larger than the underlying buffer (cl->mem_spectrum). The > underlying OpenGL buffer being too small brings me to my next (I believe > related) issue. The spectrum plot in fosphor is weirdly pixelated, please > see the attachment, which shows a screencap from "osmocom_fft -F -f 100e6 -g > 20 -s 10e6". > > Where is the cl->mem_spectrum buffer ultimately declared / initialized? My > OpenCL / OpenGL sharing knowledge is nonexistent, any pointers for how I can > help debug this issue? So, there is two way that mem_spectrum can be initialized depending on wether CL/GL sharing is active or not. Look into cl_init_buffers_gl and cl_init_buffers_nogl basically. But I've seen drivers do things that are not spec compliant unfortunately ... and other than trying random stuff to see exactly what they don't like, I'm not sure what to do. Cheers, Sylvain From 246tnt at gmail.com Sat Feb 4 09:44:09 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 4 Feb 2017 10:44:09 +0100 Subject: gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call In-Reply-To: References: Message-ID: Hi, >> I'm using the latest fosphor from git >> (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird (and I >> believe related) issues. Firstly, I see the following error: >> >> [+] Selected device: TITAN X (Pascal) >> [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable to >> queue clear of spectrum buffer > > That's really weird indeed. Although I've seen it before. Can't > remember exactly what it was though ... Actually the reason I'm not seeing it anymore on my setup is because I don't have any machine with CL/GL sharing working any more ... I changed laptop since and I can't get CL/GL sharing working with optirun and recent nvidia drivers ... One thing I would point out though is that if you have CL/GL sharing working, you can pretty much comment the entire call to cl_queue_clear_buffers because the GL side of things will clear the buffers already and they are the same. The independent clearing of the CL buffers only matter if they're different. Cheers, Sylvain From spam at rocketri.de Sun Feb 5 17:54:08 2017 From: spam at rocketri.de (Ricardo Romanowski) Date: Sun, 5 Feb 2017 18:54:08 +0100 Subject: RTL-SDR Power Consumption Message-ID: Hi, has anyone yet tried to optimize the rtl drivers towards using less energy on the chipset (cpu doesn't matter for my purpose). I just noticed that the r820 tuner gets awful hot when used normally or even when the device is just inserted into the usb port thus supplied with power. I also have multiple E4000 Tuner based dongles, but these do seem to heat up pretty well also. My hackrf stays quite cold compared to that. Are there chipsets known for less power consumption (thus less heat)? I doubt software could really do much about the chip design, but i'm not deep enough into the rtl chipset to judge whether it's more of a software- or hardware-issue. Any ideas on that topic? Thanks!! Best regards, Ricardo From raj.b at gatech.edu Sun Feb 5 19:36:46 2017 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Sun, 5 Feb 2017 14:36:46 -0500 Subject: gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call In-Reply-To: References: Message-ID: On Sat, Feb 4, 2017 at 4:44 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > Hi, > > >> I'm using the latest fosphor from git > >> (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird > (and I > >> believe related) issues. Firstly, I see the following error: > >> > >> [+] Selected device: TITAN X (Pascal) > >> [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable > to > >> queue clear of spectrum buffer > > > > That's really weird indeed. Although I've seen it before. Can't > > remember exactly what it was though ... > > Actually the reason I'm not seeing it anymore on my setup is because I > don't have any machine with CL/GL sharing working any more ... I > changed laptop since and I can't get CL/GL sharing working with > optirun and recent nvidia drivers ... > > One thing I would point out though is that if you have CL/GL sharing > working, you can pretty much comment the entire call to > cl_queue_clear_buffers because the GL side of things will clear the > buffers already and they are the same. The independent clearing of the > CL buffers only matter if they're different. > I'll comment out that call for my purposes and let you know how that goes. My guess is that resolves the -30 error but not the blocky/pixelated spectrum histogram. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.mueller at ettus.com Mon Feb 6 17:55:24 2017 From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=) Date: Mon, 6 Feb 2017 18:55:24 +0100 Subject: RTL-SDR Power Consumption In-Reply-To: References: Message-ID: Hi Ricardo, I don't think so. Anyway, I'd doubt you can do much but tweaking gains when it comes to the tuner ? and really, the power consumption of that would be in the milliwatts (datasheet [1] says 118mW typ); and seriously, in a device that's typically supplied 1.5 V generated using linear regulators from USB's 5V, I'd say your tweaking will have little to barely measurable effect. However, you seem to be more worried about heat than power, actually ? so what's your problem with the heat? At least the datasheet claims a Noise Figure of about 4.5 dB worst-band, presumably at room temperature. Going up from 20 ?C to 85 ?C (max rec. operating temp, assuming your device doesn't get higher) will increase your noise floor by the temperature-weighted Boltzmann constant, i.e. k??T, so something like -180 dBm/Hz; I'd have my doubts that this becomes a relevant problem, even assuming a full noise-equivalent filter bandwidth of 8 MHz (= 66 dBHz -> a noise floor increase by -114 dBm), since we're in a 8-bit sampling regime (which means the Signal-to-Quantization-Noise-Ratio is about 50dB (=1.76 dB + 6.02 dB ? bits)). Of course reducing temperature *does* increase SNR, especially in low-signal-power scenarious; however, the thing you'd probably want the least in that situation is to reduce the gain of the LNA. As usual, it's usually easier to help people when you know what exactly they want to do ? I can only guess your heat concern is noise-related. Maybe it isn't. In any case, your wording indicates you might want to ask general RF operation questions, and I'm not 100% sure this mailing list is the perfect place to do so. Best regards, Marcus [1] https://www.nooelec.com/files/e4000datasheet.pdf On 02/05/2017 06:54 PM, Ricardo Romanowski wrote: > Hi, > > has anyone yet tried to optimize the rtl drivers towards using less > energy on the chipset (cpu doesn't matter for my purpose). I just > noticed that the r820 tuner gets awful hot when used normally or even > when the device is just inserted into the usb port thus supplied with > power. I also have multiple E4000 Tuner based dongles, but these do > seem to heat up pretty well also. My hackrf stays quite cold compared > to that. > > Are there chipsets known for less power consumption (thus less heat)? > I doubt software could really do much about the chip design, but i'm > not deep enough into the rtl chipset to judge whether it's more of a > software- or hardware-issue. > > Any ideas on that topic? > > Thanks!! > > > Best regards, Ricardo > > From raj.b at gatech.edu Mon Feb 6 21:38:51 2017 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Mon, 6 Feb 2017 16:38:51 -0500 Subject: gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call In-Reply-To: References: Message-ID: Based on your comment about how your setup doesn't support GL/CL sharing, I tried defining FLG_FOSPHOR_USE_CLGL_SHARING as 0 in private.h. Not sharing GL objects fixes the pixelated spectrum issue! No more cl_clear_queue_clear_buffers errors either, because the code never goes down that path anymore. It seems to me there is a bug in the way the histogram buffer or texture is allocated when it is allocated through the GL code path. I'm not sure if this is quirk of my setup/GPU/driver, or if this is a general bug; I do have an older NVIDIA GPU and another machine on which I can try to reproduce what I'm seeing. Final question, what are the main downsides to NOT using CL/GL sharing? Is there some extra copy/performance overhead? On Sun, Feb 5, 2017 at 2:36 PM, Raj Bhattacharjea wrote: > On Sat, Feb 4, 2017 at 4:44 AM, Sylvain Munaut <246tnt at gmail.com> wrote: > >> Hi, >> >> >> I'm using the latest fosphor from git >> >> (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird >> (and I >> >> believe related) issues. Firstly, I see the following error: >> >> >> >> [+] Selected device: TITAN X (Pascal) >> >> [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): >> Unable to >> >> queue clear of spectrum buffer >> > >> > That's really weird indeed. Although I've seen it before. Can't >> > remember exactly what it was though ... >> >> Actually the reason I'm not seeing it anymore on my setup is because I >> don't have any machine with CL/GL sharing working any more ... I >> changed laptop since and I can't get CL/GL sharing working with >> optirun and recent nvidia drivers ... >> >> One thing I would point out though is that if you have CL/GL sharing >> working, you can pretty much comment the entire call to >> cl_queue_clear_buffers because the GL side of things will clear the >> buffers already and they are the same. The independent clearing of the >> CL buffers only matter if they're different. >> > > I'll comment out that call for my purposes and let you know how that goes. > My guess is that resolves the -30 error but not the blocky/pixelated > spectrum histogram. > > > -- > Raj Bhattacharjea, PhD > Georgia Tech Research Institute > Information and Communications Laboratory > http://www.prism.gatech.edu/~rb288/ > 404.407.6622 <(404)%20407-6622> > -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at rocketri.de Mon Feb 6 21:39:16 2017 From: spam at rocketri.de (Ricardo Romanowski) Date: Mon, 6 Feb 2017 22:39:16 +0100 Subject: RTL-SDR Power Consumption In-Reply-To: References: Message-ID: <3074d692-807d-8080-1fdb-fb73b0b58df8@rocketri.de> Hi Marcus, thanks for the Information! Though it might seem (and the temperature rise of ~40 degrees (i measured) between no power supply and a active chipset propably has *some* impact on the signal recieved) heat is not my main concern. My application is a raspberry zero with a oled screen and a battery attached that's a portable and slim sdr scanner. The raspberry performs superb battery-lifetime-wise (7 hours of idle/4 hours under 100% cpu load on a 1Ah single cell lipo) and i'm looking for the longest battery life that i can possibly archieve (as well as smallest size). I've continued searching for info on that topic after i sent the mail and found that there are indeed big differences between chipsets: https://www.reddit.com/r/RTLSDR/comments/2e9u7v/power_consuption/ which means that the E4000 uses (very) roughly 1/3rd of the energy of a R820T chipset. To bring that into some relation: for the raspberry to last 4 hours under full load on a 1000mAh battery (voltage regulator losses included) it propably draws ~250mA. Attaching a 300mA usb dongle would propably mean that i would get 1.8 hours of lifetime, while IF the E4000 only uses 110mA i'd get 2.7 hours of lifetime. Thats a significant difference (for me). So much for describing my application and concerns a little further. All the numbers are unproven so far (except for the 7h /4h lifetime of the zero, i did measure that), meaning that i need to experiment a little further and examine some chipsets power-consumption-vise myself.. As a sidenote, the battery has nominal 1Ah on 3.2V (lipo) meaning that after upconverting the voltage to 5V though a regulator (+loss) for that lifetime the pi zero propably draws even less current than 250mAh, thus increasing the impact of the power consumption of the rtl-sdr device for my battery life even further. Thank you so much for the description of temp-increase vs. signal quality - in order to understand it completely i propably have to dive a little deeper into general RF as you suggested. Maybe somebody is able to confirm the numbers for current draw, or even point me towards more energy-efficient rtl-sdr hardware (with a small form factor) Best regards, Ricardo On 06.02.2017 18:55, Marcus M?ller wrote: > Hi Ricardo, > > I don't think so. Anyway, I'd doubt you can do much but tweaking gains > when it comes to the tuner ? and really, the power consumption of that > would be in the milliwatts (datasheet [1] says 118mW typ); and > seriously, in a device that's typically supplied 1.5 V generated using > linear regulators from USB's 5V, I'd say your tweaking will have little > to barely measurable effect. > > However, you seem to be more worried about heat than power, actually ? > so what's your problem with the heat? At least the datasheet claims a > Noise Figure of about 4.5 dB worst-band, presumably at room temperature. > Going up from 20 ?C to 85 ?C (max rec. operating temp, assuming your > device doesn't get higher) will increase your noise floor by the > temperature-weighted Boltzmann constant, i.e. k??T, so something like > -180 dBm/Hz; I'd have my doubts that this becomes a relevant problem, > even assuming a full noise-equivalent filter bandwidth of 8 MHz (= 66 > dBHz -> a noise floor increase by -114 dBm), since we're in a 8-bit > sampling regime (which means the Signal-to-Quantization-Noise-Ratio is > about 50dB (=1.76 dB + 6.02 dB ? bits)). Of course reducing temperature > *does* increase SNR, especially in low-signal-power scenarious; however, > the thing you'd probably want the least in that situation is to reduce > the gain of the LNA. > > As usual, it's usually easier to help people when you know what exactly > they want to do ? I can only guess your heat concern is noise-related. > Maybe it isn't. > > In any case, your wording indicates you might want to ask general RF > operation questions, and I'm not 100% sure this mailing list is the > perfect place to do so. > > Best regards, > > Marcus > > [1] https://www.nooelec.com/files/e4000datasheet.pdf > > On 02/05/2017 06:54 PM, Ricardo Romanowski wrote: > >> Hi, >> >> has anyone yet tried to optimize the rtl drivers towards using less >> energy on the chipset (cpu doesn't matter for my purpose). I just >> noticed that the r820 tuner gets awful hot when used normally or even >> when the device is just inserted into the usb port thus supplied with >> power. I also have multiple E4000 Tuner based dongles, but these do >> seem to heat up pretty well also. My hackrf stays quite cold compared >> to that. >> >> Are there chipsets known for less power consumption (thus less heat)? >> I doubt software could really do much about the chip design, but i'm >> not deep enough into the rtl chipset to judge whether it's more of a >> software- or hardware-issue. >> >> Any ideas on that topic? >> >> Thanks!! >> >> >> Best regards, Ricardo >> >> From ky1k at myfairpoint.net Mon Feb 6 22:25:47 2017 From: ky1k at myfairpoint.net (Art) Date: Mon, 6 Feb 2017 17:25:47 -0500 Subject: RTL-SDR Power Consumption In-Reply-To: References: Message-ID: <08af5917-c4b8-2855-dad5-4e8f69aae04d@myfairpoint.net> Hi Ricardo, My guess is that it's power supply is a linear type, necessary due to the radio frequency hash that would appear as noise if a higher efficiency switching supply is used. So, the dongle has to dissipate 3.3 times 118 milliwatts (389.4milliwatts) instead of 118 milliwatts. The point is that 66.6 percent of the 'heat' you feel is not coming from the chip itself! As far as a practical solution, you can build a switching supply and build it in the cable run between the punchbox and the unit. You can't locate them extremely close to each other if a switching supply is used. Or, you can locate the linear power supply very close to (but not inside of) the enclosure for the chip. Today, linear power supplies can almost fit on the head of a pin, provided that the amount of power they dissipate is low. With radio questions related to SDR, check out the softrock mailing list on yahoo where you will find many hams, who have extensive exposure to radio communication and with SDR. GL, I hope to get one of these little beauties someday soon, and I hope that someone is working on the companion SDR based transmitter, that generates an rf output from an audio input....basically doing the reverse of what the SDR receiver does. Regards. Art A switching supply could be made outboard from the On 02/06/2017 12:55 PM, Marcus M?ller wrote: > Hi Ricardo, > > I don't think so. Anyway, I'd doubt you can do much but tweaking gains > when it comes to the tuner ? and really, the power consumption of that > would be in the milliwatts (datasheet [1] says 118mW typ); and > seriously, in a device that's typically supplied 1.5 V generated using > linear regulators from USB's 5V, I'd say your tweaking will have little > to barely measurable effect. > > However, you seem to be more worried about heat than power, actually ? > so what's your problem with the heat? At least the datasheet claims a > Noise Figure of about 4.5 dB worst-band, presumably at room temperature. > Going up from 20 ?C to 85 ?C (max rec. operating temp, assuming your > device doesn't get higher) will increase your noise floor by the > temperature-weighted Boltzmann constant, i.e. k??T, so something like > -180 dBm/Hz; I'd have my doubts that this becomes a relevant problem, > even assuming a full noise-equivalent filter bandwidth of 8 MHz (= 66 > dBHz -> a noise floor increase by -114 dBm), since we're in a 8-bit > sampling regime (which means the Signal-to-Quantization-Noise-Ratio is > about 50dB (=1.76 dB + 6.02 dB ? bits)). Of course reducing temperature > *does* increase SNR, especially in low-signal-power scenarious; however, > the thing you'd probably want the least in that situation is to reduce > the gain of the LNA. > > As usual, it's usually easier to help people when you know what exactly > they want to do ? I can only guess your heat concern is noise-related. > Maybe it isn't. > > In any case, your wording indicates you might want to ask general RF > operation questions, and I'm not 100% sure this mailing list is the > perfect place to do so. > > Best regards, > > Marcus > > [1] https://www.nooelec.com/files/e4000datasheet.pdf > > On 02/05/2017 06:54 PM, Ricardo Romanowski wrote: > >> Hi, >> >> has anyone yet tried to optimize the rtl drivers towards using less >> energy on the chipset (cpu doesn't matter for my purpose). I just >> noticed that the r820 tuner gets awful hot when used normally or even >> when the device is just inserted into the usb port thus supplied with >> power. I also have multiple E4000 Tuner based dongles, but these do >> seem to heat up pretty well also. My hackrf stays quite cold compared >> to that. >> >> Are there chipsets known for less power consumption (thus less heat)? >> I doubt software could really do much about the chip design, but i'm >> not deep enough into the rtl chipset to judge whether it's more of a >> software- or hardware-issue. >> >> Any ideas on that topic? >> >> Thanks!! >> >> >> Best regards, Ricardo >> >> > From 246tnt at gmail.com Tue Feb 7 09:01:27 2017 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 7 Feb 2017 10:01:27 +0100 Subject: gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call In-Reply-To: References: Message-ID: Hi, > Based on your comment about how your setup doesn't support GL/CL sharing, I > tried defining FLG_FOSPHOR_USE_CLGL_SHARING as 0 in private.h. Not sharing > GL objects fixes the pixelated spectrum issue! No more > cl_clear_queue_clear_buffers errors either, because the code never goes down > that path anymore. Ok, good to know. I need to come up with a good way to pass "options" to fosphor to be able to configure theses things at runtime. > It seems to me there is a bug in the way the histogram buffer or texture is > allocated when it is allocated through the GL code path. I'm not sure if > this is quirk of my setup/GPU/driver, or if this is a general bug; I do have > an older NVIDIA GPU and another machine on which I can try to reproduce what > I'm seeing. I can't get CL/GL sharing to work at all on my optimus laptop so unfortunately I can't even test that code path anymore. I really need to build myself a desktop machine .... > Final question, what are the main downsides to NOT using CL/GL sharing? Is > there some extra copy/performance overhead? Yes. Basically the result of the CL computation is downloaded to CPU memory, then re-uploaded as a texture. Not only does that impose extra data copy but also more synchronization points between CPU and GPU. Cheers, Sylvain From raj.b at gatech.edu Tue Feb 7 20:52:18 2017 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Tue, 7 Feb 2017 15:52:18 -0500 Subject: gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call In-Reply-To: References: Message-ID: Sylvain, > Ok, good to know. > > I need to come up with a good way to pass "options" to fosphor to be > able to configure theses things at runtime. > > That would be useful! Given how much I use your tool for real work, I'm willing to contribute; do you look at pull requests on the github mirror? Here are some other things I have often considered plumbing through as options: 1. FFT length. It looks like you have a length 512 FFT kernel in fft.cl already, but I think its unused. A few other FFT sizes might be useful too for adjusting resolution bandwidth. With what you have, several other powers of two should be implementable simply. 2. Waterfall time length. Requires some GL tricks to change the texture size, or internally render at some fixed size and always crop and/or downsample the texture to show the amount of time the user requested. Thanks for the tips that resolved the issue! -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.m at suddenlink.net Fri Feb 10 21:22:21 2017 From: martin.m at suddenlink.net (Martin McCormick) Date: Fri, 10 Feb 2017 15:22:21 -0600 Subject: rtl_fm Squelch Questions Message-ID: I have been playing with the rtl_fm program and most of it works amazingly well but I can not seem to get the squelch to stay open when receiving signals. I have not tried to analyze the source yet so I am asking what principle drives this squelch? In the analog world, the best squelches for FM receivers tend to be noise-driven and use a high-pass filter to filter out normal audio. When the noise drops below a preset threshold, the squelch opens. For AM receivers, a cheap and easy solution is to monitor the AGC and open the squelch when there is AGC voltage above a preset level. What I am noticing is that if I set the l value to a point just above where the noise stops, signals do open the squelch but even strong signals will not keep it from flickering on and off constantly. If I set the l value any lower, the squelch is always open so that is not the issue. I have tried signals that are absolutely full-quieting, with and without CTCSS and the squelch opens briefly, closes for a fraction of a second, opens for another fraction of a second and randomly flickers on and off for the whole transmission. On rare occasions, the squelch opens when the signal starts, stays open and then closes properly after the carrier leaves. Some of these signals are even ever so slightly noisy and I have heard this situation with and without PL tones or CTCSS so that doesn't seem to matter. Finally, I thought it might have something to do with too narrow a bandwidth so I increased the sampling rate to 24 K which made no difference at all. If the signal has voice on it, the flickering doesn't seem to be effected by the words. Basically, what is this squelch responding to to keep flapping? Martin McCormick WB5AGZ From marcus.mueller at ettus.com Fri Feb 10 23:17:18 2017 From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=) Date: Sat, 11 Feb 2017 00:17:18 +0100 Subject: rtl_fm Squelch Questions In-Reply-To: References: Message-ID: Hi Martin, I'll just address the question /what does the rtl_fm squelch do?/ very shortly: from rtl_fm.c /* power squelch */ if (d->squelch_level) { sr = rms(d->lowpassed, d->lp_len, 1); if (sr < d->squelch_level) { d->squelch_hits++; for (i=0; ilp_len; i++) { d->lowpassed[i] = 0; } } else { d->squelch_hits = 0;} } The signal enters the squelch after being low-pass filtered, then the RMS (basically, the power) is calculated and saved in ?sr?; if that is below the squelch threshold, the signal is zeroed out. If it's above, the signal passes to the next state. The squelch_hits just implement kind of a hysteresis. So, yeah, a couple lines below: /* todo, fm noise squelch */ :) Soooo, maybe you'd want todo that? CTCSS might be so low in frequency that their instantaneous amplitude might be sensed as energy or not, depending on how close they are to the LO (might get killed by the DC block). So, basically, the squelch is only sensitive to power. Best regards, Marcus On 10.02.2017 22:22, Martin McCormick wrote: > I have been playing with the rtl_fm program and most of > it works amazingly well but I can not seem to get the squelch to > stay open when receiving signals. > > I have not tried to analyze the source yet so I am asking > what principle drives this squelch? > > In the analog world, the best squelches for FM receivers > tend to be noise-driven and use a high-pass filter to filter out > normal audio. When the noise drops below a preset threshold, the > squelch opens. > > For AM receivers, a cheap and easy solution is to monitor > the AGC and open the squelch when there is AGC voltage above a > preset level. > > What I am noticing is that if I set the l value to a > point just above where the noise stops, signals do open the > squelch but even strong signals will not keep it from flickering > on and off constantly. > > If I set the l value any lower, the squelch is always > open so that is not the issue. > > I have tried signals that are absolutely full-quieting, > with and without CTCSS and the squelch opens briefly, closes for > a fraction of a second, opens for another fraction of a second > and randomly flickers on and off for the whole transmission. > > On rare occasions, the squelch opens when the signal > starts, stays open and then closes properly after the carrier > leaves. > Some of these signals are even ever so slightly noisy and I have > heard this situation with and without PL tones or CTCSS so that > doesn't seem to matter. > > Finally, I thought it might have something to do with too > narrow a bandwidth so I increased the sampling rate to 24 K which > made no difference at all. > > If the signal has voice on it, the flickering doesn't > seem to be effected by the words. > > Basically, what is this squelch responding to to keep flapping? > > Martin McCormick WB5AGZ From martin.m at suddenlink.net Sat Feb 11 13:58:34 2017 From: martin.m at suddenlink.net (Martin McCormick) Date: Sat, 11 Feb 2017 07:58:34 -0600 Subject: rtl_fm Squelch Questions In-Reply-To: References: Message-ID: =?UTF-8?Q?Marcus_M=c3=bcller?= writes: > Hi Martin, > > I'll just address the question /what does the rtl_fm squelch do?/ very > shortly: from rtl_fm.c > > /* power squelch */ > if (d->squelch_level) { > sr = rms(d->lowpassed, d->lp_len, 1); > if (sr < d->squelch_level) { > d->squelch_hits++; > for (i=0; ilp_len; i++) { > d->lowpassed[i] = 0; > } > } else { > d->squelch_hits = 0;} > } > > The signal enters the squelch after being low-pass filtered, then the > RMS (basically, the power) is calculated and saved in ?sr?; if that is > below the squelch threshold, the signal is zeroed out. If it's above, > the signal passes to the next state. The squelch_hits just implement > kind of a hysteresis. > > So, yeah, a couple lines below: > > /* todo, fm noise squelch */ > > :) Soooo, maybe you'd want todo that? Thank you very much. I feel a bit red-faced in that I could have stumbled on this as it is right there as you describe, about 700 lines in. and the source is good old C. I used gcc C for about 20 years at work so this looks like old times for me.:-) That doesn't mean I understand it all, but I will surely give it a try. I tend to try ridiculously simple ideas first in hopes that one will work. In FM reception, the loudest noise occurs when there is no signal or on occasion if there is a nearby signal just outside the passband in which case the noise squelch is closed more tightly. When one has the loudest noise, there should be the largest variations in individual samples compared to anything one will see when receiving a valid voice or data signal that is within the passband. More reply to follow: > CTCSS might be so low in frequency that their instantaneous amplitude > might be sensed as energy or not, depending on how close they are to the > LO (might get killed by the DC block). I did try receiving some signals which have no CTCSS or DCS and sometimes, the transmission was clear but usually it flickered. I will first save some rtl_fm output to raw files and then experiment with perl to see which ideas may have merit. When something good happens, I will code the same logic in C. Am I correct in that the 16-bit samples are signed integers so silence will look like 0x7fff or 0x8000 and extremes will be 0 or 0xffff? I would imagine that the noise squelch might also fall short when receiving wide-band FM broadcasts as they contain numerous sub carriers for stereo, RDS and auxiliary services. We will probably need both the noise and power squelches as the noise squelch will probably be useless for AM and SSB. The samples will probably not have enough of the right kind of noise in them to do any good on anything but FM. Martin WB5AGZ From marcus.mueller at ettus.com Sat Feb 11 14:35:57 2017 From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=) Date: Sat, 11 Feb 2017 15:35:57 +0100 Subject: rtl_fm Squelch Questions In-Reply-To: References: Message-ID: <3553eef6-c9b1-d111-ce6c-7e1e863eb2be@ettus.com> Hi Martin, never feel ashamed for asking questions. I've learned (support stuff) that the more at ease you are at potentially missing something, the easier others feel at answering questions, and the more pleasant the process is for both sides. And yeah, I've got no doubts you /could/ have spotted this ? but not spotting this in a couple hundred lines of code is really not a fauxpass nor a sign of anything negative. Instead, investigating what makes a piece of technology tick or misbehave (in this very case, more the latter) and writing an extensive email explaining your question and giving a bit of background ? what more could FOSS projects ask for?! > I tend to try ridiculously simple ideas first > in hopes that one will work. In FM reception, the loudest noise > occurs when there is no signal or on occasion if there is a > nearby signal just outside the passband in which case the noise > squelch is closed more tightly. Yep! Classical noise-squelch! Direct baseband mixing receiver problem: You might have a stable pseudo-carrier through LO leakage. Direct baseband mixer solution: DC block the heck out of your baseband :) I'll let the others answer your further audio-signal questions; I must admit that I'm on a train, which isn't necessarily the easiest environment to diligently write emails :) Best regards, Marcus From mmcg29440 at frontier.com Mon Feb 13 00:13:35 2017 From: mmcg29440 at frontier.com (Martin McGlensey) Date: Sun, 12 Feb 2017 19:13:35 -0500 Subject: RTLSDR_Set_tuner_Bandwith error Message-ID: I have a Panadapter program, written in python, that throws an error "undefined symbol Set_Tuner_Bandwith in librtlsdr0" Searching the net I've found that set_tuner_Baandwith may have been dropped from the library. I'm using version 5.3. One web site said that it had been added back in the latest revision v0.7.0. Tried loading the new library and now find that RTL-SDR requires dependencies found in librtlsdr0 version 5.3. Is there a work around to eliminate this error. I did download the latest rtl-sdr but it will not compile because of the dependency problem I did not write the program so I hesitate to take it apart and I have not received much help from the author. BITW I'm not the greatest linux person so I need clear answers. Having said that all responses will be appreciated. 73 Marty, N3MOW -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas at teske.net.br Mon Feb 13 00:40:13 2017 From: lucas at teske.net.br (Lucas Teske) Date: Sun, 12 Feb 2017 22:40:13 -0200 Subject: RTLSDR_Set_tuner_Bandwith error In-Reply-To: References: Message-ID: <11b94771-fcb8-a40a-52a2-66a985d1bfd7@teske.net.br> Hi Marty, the v0.7.0 is available at: https://github.com/librtlsdr/librtlsdr We are working to get the code better and be approved by osmocom community to get upstream. Lucas Em 12/02/2017 22:13, Martin McGlensey escreveu: > > I have a Panadapter program, written in python, that throws an error > ?undefined symbol Set_Tuner_Bandwith in librtlsdr0? Searching the net > I?ve found that set_tuner_Baandwith may have been dropped from the > library. I?m using version 5.3. One web site said that it had been > added back in the latest revision v0.7.0. Tried loading the new > library and now find that RTL-SDR requires dependencies found in > librtlsdr0 version 5.3. Is there a work around to eliminate this > error. I did download the latest rtl-sdr but it will not compile > because of the dependency problem > > > > I did not write the program so I hesitate to take it apart and I have > not received much help from the author. BITW I?m not the greatest > linux person so I need clear answers. Having said that all responses > will be appreciated. > > > > 73 > > Marty, N3MOW > -- Lucas Teske Teske Virtual System GPG: 4A90 974B ACE0 A9A6 AF09 B3B1 6C39 C1C1 6A9D A7BE -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3823 bytes Desc: Assinatura criptogr??fica S/MIME URL: From luigi.tarenga at gmail.com Mon Feb 13 08:22:26 2017 From: luigi.tarenga at gmail.com (Luigi Tarenga) Date: Mon, 13 Feb 2017 09:22:26 +0100 Subject: RTLSDR_Set_tuner_Bandwith error In-Reply-To: References: Message-ID: Hi Martin, the official rtl-sdr driver has been forked many times on github. Still I can say that the tuned bandwith is tunable with the official driver. The exported API is: On Mon, Feb 13, 2017 at 1:13 AM, Martin McGlensey wrote: > I have a Panadapter program, written in python, that throws an error > ?undefined symbol Set_Tuner_Bandwith in librtlsdr0? Searching the net I?ve > found that set_tuner_Baandwith may have been dropped from the library. I?m > using version 5.3. One web site said that it had been added back in the > latest revision v0.7.0. Tried loading the new library and now find that > RTL-SDR requires dependencies found in librtlsdr0 version 5.3. Is there a > work around to eliminate this error. I did download the latest rtl-sdr but > it will not compile because of the dependency problem > > > > I did not write the program so I hesitate to take it apart and I have not > received much help from the author. BITW I?m not the greatest linux person > so I need clear answers. Having said that all responses will be appreciated. > > > > 73 > > Marty, N3MOW > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luigi.tarenga at gmail.com Mon Feb 13 08:27:12 2017 From: luigi.tarenga at gmail.com (Luigi Tarenga) Date: Mon, 13 Feb 2017 09:27:12 +0100 Subject: RTLSDR_Set_tuner_Bandwith error In-Reply-To: References: Message-ID: Hi Martin, the official rtl-sdr driver has been forked many times on github. Still I can say that the tuned bandwith is tunable with the official driver. The exported API is: RTLSDR_API int rtlsdr_set_tuner_bandwidth(rtlsdr_dev_t *dev, uint32_t bw); see the git: http://git.osmocom.org/rtl-sdr the function has been added on 2015-05-15 I can make a guess, does you python program rely on another software layer like gr-osmosdr? (gnuradio osmosdr) because I had the same problem where I wanted to tune the bandwidth with gqrx but the function was not implemented in gr-osmosdr, only in the underlying rtl-sdr driver. If this is the case I already prepared a simple patch for myself and I will the more than happy to share it with you and the list. Can you send some more details on your python program? Maybe I have some time to check it out how it works. Luigi On Mon, Feb 13, 2017 at 9:22 AM, Luigi Tarenga wrote: > Hi Martin, > the official rtl-sdr driver has been forked many times on github. > Still I can say that the tuned bandwith is tunable with the official > driver. > The exported API is: > > On Mon, Feb 13, 2017 at 1:13 AM, Martin McGlensey > wrote: > >> I have a Panadapter program, written in python, that throws an error >> ?undefined symbol Set_Tuner_Bandwith in librtlsdr0? Searching the net I?ve >> found that set_tuner_Baandwith may have been dropped from the library. I?m >> using version 5.3. One web site said that it had been added back in the >> latest revision v0.7.0. Tried loading the new library and now find that >> RTL-SDR requires dependencies found in librtlsdr0 version 5.3. Is there a >> work around to eliminate this error. I did download the latest rtl-sdr but >> it will not compile because of the dependency problem >> >> >> >> I did not write the program so I hesitate to take it apart and I have not >> received much help from the author. BITW I?m not the greatest linux person >> so I need clear answers. Having said that all responses will be appreciated. >> >> >> >> 73 >> >> Marty, N3MOW >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lucas at teske.net.br Mon Feb 20 22:05:37 2017 From: lucas at teske.net.br (Lucas Teske) Date: Mon, 20 Feb 2017 19:05:37 -0300 Subject: Added Bias T set / get to API Message-ID: <30836fa6-cb4f-44cc-667d-588d31ec2620@teske.net.br> So since there are now three radios (that I know) that has a hardware Bias T support (HackRF, RTLSDR, Airspy) I added a set_biast and get_biast methods to the default Source API. I also added Airspy and HackRF bindings to enable / disable Bias T. The RTLSDR isn't merged into mainstream, so I didn't added anything. There is also the default implementations (doing nothing for set, and returning false for get), so no breaks on the current source or current applications. -- Lucas Teske Teske Virtual System GPG: 4A90 974B ACE0 A9A6 AF09 B3B1 6C39 C1C1 6A9D A7BE -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-BiasT-support-for-default-API.patch Type: text/x-patch Size: 5973 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3823 bytes Desc: Assinatura criptogr??fica S/MIME URL: From raj.b at gatech.edu Fri Feb 3 17:04:42 2017 From: raj.b at gatech.edu (Raj Bhattacharjea) Date: Fri, 03 Feb 2017 17:04:42 -0000 Subject: gr-fosphor CL_INVALID_VALUE in clEnqueueFillBuffer call Message-ID: I'm using the latest fosphor from git (7b6b9961bc2d9b84daeb42a5c8f8aeba293d207c) and am seeing two weird (and I believe related) issues. Firstly, I see the following error: [+] Selected device: TITAN X (Pascal) [!] CL Error (-30, /home/user/gr-fosphor/lib/fosphor/cl.c:409): Unable to queue clear of spectrum buffer This is CL_INVALID_VALUE returning from clEnqueueFillBuffer, so I added some debug fprints to cl.c to see what parameters were being passed into clEnqueueFillBuffer: Edits: fprintf(stderr, "size = %d\n", 2 * 2 * sizeof(cl_float) * FOSPHOR_FFT_LEN); fprintf(stderr, "pattern_size = %d\n", sizeof(float)); fprintf(stderr, "pattern = %p\n", &noise_floor); fprintf(stderr, "offset = %d\n", 0); Output: size = 16384 pattern_size = 4 pattern = 0x7fb66b7fdd2c offset = 0 These parameters look like they shouldn't cause CL_INVALID_VALUE: https://www.khronos.org/registry/OpenCL/sdk/2.0/docs/man/xhtml/clEnqueueFillBuffer.html But there is this one condition that might be met, which is that somehow size (16384) is larger than the underlying buffer (cl->mem_spectrum). The underlying OpenGL buffer being too small brings me to my next (I believe related) issue. The spectrum plot in fosphor is weirdly pixelated, please see the attachment, which shows a screencap from "osmocom_fft -F -f 100e6 -g 20 -s 10e6". Where is the cl->mem_spectrum buffer ultimately declared / initialized? My OpenCL / OpenGL sharing knowledge is nonexistent, any pointers for how I can help debug this issue? Output of clinfo is attached as well, and I'm on Ubuntu 16.04 on x86_64. -- Raj Bhattacharjea, PhD Georgia Tech Research Institute Information and Communications Laboratory http://www.prism.gatech.edu/~rb288/ 404.407.6622 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Number of platforms 1 Platform Name NVIDIA CUDA Platform Vendor NVIDIA Corporation Platform Version OpenCL 1.2 CUDA 8.0.46 Platform Profile FULL_PROFILE Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts Platform Extensions function suffix NV Platform Name NVIDIA CUDA Number of devices 1 Device Name TITAN X (Pascal) Device Vendor NVIDIA Corporation Device Vendor ID 0x10de Device Version OpenCL 1.2 CUDA Driver Version 367.57 Device OpenCL C Version OpenCL C 1.2 Device Type GPU Device Profile FULL_PROFILE Device Topology (NV) PCI-E, 05:00.0 Max compute units 28 Max clock frequency 1531MHz Compute Capability (NV) 6.1 Device Partition (core) Max number of sub-devices 1 Supported partition types None Max work item dimensions 3 Max work item sizes 1024x1024x64 Max work group size 1024 Preferred work group size multiple 32 Warp size (NV) 32 Preferred / native vector sizes char 1 / 1 short 1 / 1 int 1 / 1 long 1 / 1 half 0 / 0 (n/a) float 1 / 1 double 1 / 1 (cl_khr_fp64) Half-precision Floating-point support (n/a) Single-precision Floating-point support (core) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations Yes Double-precision Floating-point support (cl_khr_fp64) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Address bits 64, Little-Endian Global memory size 12779454464 (11.9GiB) Error Correction support No Max memory allocation 3194863616 (2.975GiB) Unified memory for Host and Device No Integrated memory (NV) No Minimum alignment for any data type 128 bytes Alignment of base address 4096 bits (512 bytes) Global Memory cache type Read/Write Global Memory cache size 458752 Global Memory cache line 128 bytes Image support Yes Max number of samplers per kernel 32 Max size for 1D images from buffer 134217728 pixels Max 1D or 2D image array size 2048 images Max 2D image size 16384x32768 pixels Max 3D image size 16384x16384x16384 pixels Max number of read image args 256 Max number of write image args 16 Local memory type Local Local memory size 49152 (48KiB) Registers per block (NV) 65536 Max constant buffer size 65536 (64KiB) Max number of constant args 9 Max size of kernel argument 4352 (4.25KiB) Queue properties Out-of-order execution Yes Profiling Yes Prefer user sync for interop No Profiling timer resolution 1000ns Execution capabilities Run OpenCL kernels Yes Run native kernels No Kernel execution timeout (NV) Yes Concurrent copy and kernel execution (NV) Yes Number of async copy engines 2 printf() buffer size 1048576 (1024KiB) Built-in kernels Device Available Yes Compiler Available Yes Linker Available Yes Device Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) NVIDIA CUDA clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [NV] clCreateContext(NULL, ...) [default] Success [NV] clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No platform ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.8 ICD loader Profile OpenCL 1.2 NOTE: your OpenCL library declares to support OpenCL 1.2, but it seems to support up to OpenCL 2.1 too. -------------- next part -------------- A non-text attachment was scrubbed... Name: pixelatedSpectrum.png Type: image/png Size: 642052 bytes Desc: not available URL: From mmcg29440 at frontier.com Tue Feb 7 21:05:03 2017 From: mmcg29440 at frontier.com (Martin McGlensey) Date: Tue, 07 Feb 2017 21:05:03 -0000 Subject: Error "No E4000 tuner found" on rtl_test -t Message-ID: Hello, I recently purchased a NooElec nesdr mini dongle. I want to install it on Linux Mint 17.1. I have rtl-sdr installed. I have blacklisted the dvb_usb_rtl28xxu driver. When I run rtl_test it reports that the dongle is present and sending. When I run rtl_sdr -t to check the tuning range it reports no E4000 tuner found. Called NooElec for tech support. Got link for linux install but got error "page not found". Tried to get on their mailing list from their IE page. Bad gateway error 502. Looks like support may be difficult to get through NooElec. Does this error indicate a defective rtl dongle? Where can I find the install procedure for the NooElec R820T NESDR mini. All responses are appreciated. Thank you, Marty, N3MOW N3mow at arrl.net mmcg29440 at frontier.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhjeragh at icloud.com Sat Feb 11 16:00:02 2017 From: zhjeragh at icloud.com (zainab jeragh) Date: Sat, 11 Feb 2017 16:00:02 -0000 Subject: Request Message-ID: Hello We are doing a ADS-B reciever senior project, Can we have the building blocks in the gnu radio for that? Please help us We are using the hackrf one hardware Which is the osmocom source in the gnu radio Thanks Sent from my iPhone From oe6pse at wirklich.priv.at Sun Feb 26 20:47:23 2017 From: oe6pse at wirklich.priv.at (Patrick Strasser-Mikhail) Date: Sun, 26 Feb 2017 21:47:23 +0100 Subject: Fwd: How to get out the maximum from cheap sdrs In-Reply-To: References: Message-ID: <03b0e62d-139c-52a0-90ee-8f93107d046f@wirklich.priv.at> Stefan Groi?meier 2017-01-10 17:37: > That is why I'm searching a way to correlate the signals of the sdrs > without hardware modification. Just my 2 cents: Intriguing idea, BUT (sorry...): For corrleation you need a common time base, that is a common clock source. That is not the case for multiple RTL-SDR dongles. Moreover you need a stable and known phase relation (runtimes of the clock signal) for your dongles. The USB bus does not provide the clock for the dongles, so this is no way to synchronize them The key word here would be MIMO - Multiple In Multiple Out. That is what WLAN 801.11n does, in one device. I do not know if any of the currently availabe dongles have a clock input (for a common source) or a clock output (to act as clock master) 73 de Patrick OE6PSE -- Engineers motto: cheap, good, fast - choose any two Amateur Radio Operator / Ham / Funkamateur / QTH: JN77rb http://oevsv.at/ One of the lucky 10.000: http://xkcd.com/1053 Use Mail Encryption Today! PGP Key ID: 0xDF8A127E5A120903 Patrick Strasser-Mikhail OE6PSE From marcus.mueller at ettus.com Sun Feb 26 21:30:51 2017 From: marcus.mueller at ettus.com (=?UTF-8?Q?Marcus_M=c3=bcller?=) Date: Sun, 26 Feb 2017 22:30:51 +0100 Subject: Fwd: How to get out the maximum from cheap sdrs In-Reply-To: <03b0e62d-139c-52a0-90ee-8f93107d046f@wirklich.priv.at> References: <03b0e62d-139c-52a0-90ee-8f93107d046f@wirklich.priv.at> Message-ID: <918193fd-9cb5-7f66-144a-a7d7d3d65fc3@ettus.com> I've only heard of the possibility to solder out the reference oscillator of all but one dongle and distribute the oscillator of that to the others. That's a modification, and also, only eliminates frequency offset - the random absolute phase (which you can remove by correlation, assuming your antennas /mainly/ see the same signal) stays, and what's more, the phase noise of the synthesizer inside the tuner chip. Point is that these devices are *exactly for reasons of integration* this cheap: there's one chip that does all the LO synthesizing and mixing. You can't get the LO out or into that. But, since Phase noise really is usually uncorellated to the signal we're interested in, Patrick's right ? with that modification, you can build Multiple-input receivers. You'll get diversity gain. How much gain (measured in reception quality improvement equivalent to an SNR improvement, hence the name) that is depends on the method you're using ? but the fact is: The first SDR you use gives you the most gain (namely, being able to observe the signal at all); the second still a bit, regardless of diversity method, the third always a bit less and so on. So whilst your complexity tends to grow worse than linearly, the increase with every additional receiver dwindles. What's making this worse: All these methods depend on your ability to know the phase of every receiver path. With RTL-SDRs you can't know that (there's no phase synchronization at all, and even worse, no time synchronity to even start with); you have to estimate it from your received signal, every single tune, and continously, since the LOs *will* drift against each other in any normal PLL'ed device. Now, estimating the phase of a reception is a pretty hard problem and usually requires intricate knowledge of what signal you're looking at ? that's why all wireless standards have things like preambles, pilot tones, sync words etc. With a pure cross-correlation, your phase estimate's variance is pretty much proportional to your sum(SNR^-1); not a good thing :( So, in general, this is hard, and a receiver that allows you to circumvent at least parts of these problems will be a lot more modular and complex than an RTL-SDR dongle :( Greetings, Marcus On 26.02.2017 21:47, Patrick Strasser-Mikhail wrote: > Stefan Groi?meier 2017-01-10 17:37: >> That is why I'm searching a way to correlate the signals of the sdrs >> without hardware modification. > Just my 2 cents: > > Intriguing idea, BUT (sorry...): > > For corrleation you need a common time base, that is a common clock > source. That is not the case for multiple RTL-SDR dongles. Moreover you > need a stable and known phase relation (runtimes of the clock signal) > for your dongles. > > > The USB bus does not provide the clock for the dongles, so this is no > way to synchronize them > > The key word here would be MIMO - Multiple In Multiple Out. That is what > WLAN 801.11n does, in one device. > > I do not know if any of the currently availabe dongles have a clock > input (for a common source) or a clock output (to act as clock master) > > > 73 de Patrick OE6PSE From cinaed.simson at gmail.com Sun Feb 26 22:54:38 2017 From: cinaed.simson at gmail.com (Cinaed Simson) Date: Sun, 26 Feb 2017 14:54:38 -0800 Subject: Error "No E4000 tuner found" on rtl_test -t In-Reply-To: References: Message-ID: <378a06c1-04f3-d80e-5b50-b40fd85187a2@GMail.COM> On 02/07/2017 12:58 PM, Martin McGlensey wrote: > Hello, > > > > I recently purchased a NooElec nesdr mini dongle. I want to install it > on Linux Mint 17.1. I have rtl-sdr installed. I have blacklisted the > dvb_usb_rtl28xxu driver. When I run rtl_test it reports that the dongle > is present and sending. When I run rtl_sdr -t to check the tuning range > it reports no E4000 tuner found. This is the correct behavior. See rtl_test --help It means don't have an E4000. If you did have an E4000, then the first test your ran would have failed. -- Cinaed > > > > Called NooElec for tech support. Got link for linux install but got > error ?page not found?. Tried to get on their mailing list from their IE > page. Bad gateway error 502. Looks like support may be difficult to get > through NooElec. > > > > Does this error indicate a defective rtl dongle? Where can I find the > install procedure for the NooElec R820T NESDR mini. All responses are > appreciated. > > > > Thank you, > > Marty, N3MOW > > N3mow at arrl.net mmcg29440 at frontier.net > > > > From cinaed.simson at gmail.com Sun Feb 26 22:56:27 2017 From: cinaed.simson at gmail.com (Cinaed Simson) Date: Sun, 26 Feb 2017 14:56:27 -0800 Subject: Request In-Reply-To: References: Message-ID: On 02/11/2017 06:59 AM, zainab jeragh wrote: > Hello > We are doing a ADS-B reciever senior project, > Can we have the building blocks in the gnu radio for that? > Please help us > > We are using the hackrf one hardware > Which is the osmocom source in the gnu radio > Thanks > Sent from my iPhone > Try https://github.com/bistromath/gr-air-modes gnuradio questions should go to discuss-gnuradio at gnu.org -- Cinaed From leif at sm5bsz.com Mon Feb 27 00:38:52 2017 From: leif at sm5bsz.com (Leif Asbrink) Date: Mon, 27 Feb 2017 01:38:52 +0100 Subject: Fwd: How to get out the maximum from cheap sdrs In-Reply-To: References: Message-ID: <20170227013852.97fb83ebfc0ee2b92e8fc71a@sm5bsz.com> Hi Stefan, > Rtl-sdrs are quite cheap, but for now a user has no benefit of having > multiple sdrs in its system. Hmmm, with several rtlsdr units one can monitor several different frequency bands. I am sure there are users who find that beneficial:-) > That is why I'm searching a way to correlate the signals of the sdrs > without hardware modification. I think everyone of you has seen the noise from > the power source. Has anyone tried to build a filter to use that noise > to calculate the delay between multiple dongles? Surely it is possible to synchronize two or more dongles in software. They just have to receive the same signals to a sufficient amount. One would have to apply a fractional resampler to all but one rtlsdr to compensate for different sampling clocks. Those resamplers have to be adaptive to accomodate different frequency drifts. This means one has to find the time shift for best correlation, and establish how that time drifts to update the resampling ratio for the time shift to stay constant. There will be many interesting complications if one just uses the normal antenna signals. It would however be fairly easy to inject pulses at perhaps 30 Hz and use them for the synchronization. Those pulses would be known accurately so they can be subtracted from the data stream to not have any adverse effect on the desired signals. > I mean, they get the same noise. I don't know if it is sufficient, > but it is also a good spot, to put some artificial noise in, as it can be easily > accessed and does not interfere with rf circuitry when it is switched off. Synchronization can not be switched off, stability is not good enough for that - but the artificial noise is known so we can subtract it:-) > Is that an useful approach? > Do you think this could work? Did I miss something? Surely it can work. I do not think it will be trivial to get it running however, but you should be able to make a multi-channel receiver that could combine phase-coherent signals from several antennas for drastically improved S/N. 73 Leif > > > regards, > > Steve > From cinaed.simson at gmail.com Mon Feb 27 05:46:56 2017 From: cinaed.simson at gmail.com (Cinaed Simson) Date: Sun, 26 Feb 2017 21:46:56 -0800 Subject: Floating point error in tuner_r82xx.c In-Reply-To: <3c1fc3dc-9303-504f-ca54-c36ae60379ba@yahoo.com> References: <3c1fc3dc-9303-504f-ca54-c36ae60379ba@yahoo.com> Message-ID: <610d2f6a-b055-7248-57eb-45615b20f1ee@GMail.COM> On 01/10/2017 11:06 PM, Steve Knoeck wrote: > Hi, > > I get a floating point exception when I run rtl_tcp. I traced the error > with GDB to line 515 of tuner_r82xx.c > if (vco_fra > (2 * pll_ref_khz / n_sdm)) > I found that n_sdm was 0. > > I don't understand how this code work and I'm very new to this software > but it sure looks like a programming bug. > > | 513 /* sdm calculator */|| > || 514 while (vco_fra > 1) {|| > || 515 if (vco_fra > (2 * pll_ref_khz / n_sdm)) {|| > || 516 sdm = sdm + 32768 / (n_sdm / 2);|| > || 517 vco_fra = vco_fra - 2 * pll_ref_khz / > n_sdm;|| > || 518 if (n_sdm >= 0x8000)|| > || 519 break;|| > || 520 }|| > || 521 n_sdm <<= 1;|| > || 522 }| > > If the condition on line 515 ever evaluates to false then vco_fra > doesn't get updated. The loop will keep repeating with the same value > of vco_fra until n_sdm becomes 0. > > Steve I'm using rtl_tcp from http://git.osmocom.org/rtl-sdr/rtl-sdr-0.5.3.tar.xz with gnuradio-3.7.10.1 and it works perfectly. Which version are you using? -- Cinaed From f6gnj78 at gmail.com Mon Feb 27 13:30:57 2017 From: f6gnj78 at gmail.com (a c) Date: Mon, 27 Feb 2017 14:30:57 +0100 Subject: RTLSDR IQ imbalance ??? Message-ID: Hello, I use RTL-FM on a raspberry pi3. I notice practically always the presence of a weak carrier accompanying the emission received in AM mode and interferences in NFM mode. When i use rtl-tcp and sdr# or sdrconsole the demodulation is perfect. I assume that IQ amplitude phase correction is involved. I saw in the source of rtlsdr: IQ estimation / compensation (en_iq_comp, en_iq_est) * / Rtlsdr_demod_write_reg (dev, 1, 0xb1, 0x1b, 1); I suppose we use an internal chipset function? Is this function good enough? I did not find anything about it in RTL-FM but I'm not a specialist. Is an improvement possible? Regards, Arnaud From lucas at teske.net.br Mon Feb 27 14:38:28 2017 From: lucas at teske.net.br (Lucas Teske) Date: Mon, 27 Feb 2017 11:38:28 -0300 Subject: RTLSDR IQ imbalance ??? In-Reply-To: References: Message-ID: That doesn't look an IQ Imbalance but a DC Offset. But that depends a lot of the tuner you use. I develop some softwares using rtlsdr, and the newest dongles with R820T2 dongle doesn't have IQ Imbalance or DC Spike issues by default. Em 27/02/2017 10:30, a c escreveu: > Hello, > I use RTL-FM on a raspberry pi3. I notice practically always the > presence of a weak carrier accompanying the emission received in AM > mode and interferences in NFM mode. When i use rtl-tcp and sdr# or > sdrconsole the demodulation is perfect. I assume that IQ amplitude > phase correction is involved. I saw in the source of rtlsdr: > IQ estimation / compensation (en_iq_comp, en_iq_est) * / > Rtlsdr_demod_write_reg (dev, 1, 0xb1, 0x1b, 1); > I suppose we use an internal chipset function? Is this function good > enough? I did not find anything about it in RTL-FM but I'm not a > specialist. Is an improvement possible? > Regards, > Arnaud