osmocom-sdr

osmocom-sdr@lists.osmocom.org

2 participants
906 discussions

None
by None 03 Jan '22

03 Jan '22

direct sampling mode, only from signal processing view): If you already have analog signal as separated I&Q in baseband (so called zero-IF), and do I&Q two channel A/D converter, you can processing signal, highest frequency of which is less than sampling rate, without aliasing. That means, for example, you can processing signal, frequency of which is up to 28.8MHz, when sampling rate is 28.8MHz. (There is an implicit assumption that your zero-IF analog channel is ideal) If you have to do sampling on a single channel analog signal( not zero-IF, I&Q not separated by analog circuit, I&Q are still mixed together by an IF carrier/frequency), you have to ensure the highest frequency of signal less than half of sampling rate to ensure no aliasing. On Wed, Jan 29, 2014 at 7:50 AM, Richard Koch <n1gp(a)hotmail.com> wrote: > Can someone clarify what the frequency range is in Direct sampling mode. > > The rtl2832u dongle has a 28.8Mhz osc. > > So can the dongle in "direct sampling mode" (with appropriate antenna > connection) > receive > 14.4 Mhz (Nyquist) ? > > Googling I find conflicting advice. > > I've been able to receive > 14.4 Mhz in direct mode, but I'm not sure if > that's due to some non-optimal method...? > > I'm guessing it can because the tuner chip provides both I & Q data > therefore > allowing the double rate...? > > > > --047d7bf15fc8eed8c404f1137e92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>From the point of view of signal processing (not= very clear about your direct sampling mode, only from signal processing vi= ew):<br></div>If you already have analog signal as separated I&Q in bas= eband (so called zero-IF), and do I&Q two channel A/D converter, you ca= n processing signal, highest frequency of which is less than sampling rate,= without aliasing.<br> </div><div>That means, for example, you can processing signal, frequency of= which is up to 28.8MHz, when sampling rate is 28.8MHz. (There is an implic= it assumption that your zero-IF analog channel is ideal)<br><br></div>If yo= u have to do sampling on a single channel analog signal( not zero-IF, I&amp= ;Q not separated by analog circuit, I&Q are still mixed together by an = IF carrier/frequency), you have to ensure the highest frequency of signal l= ess than half of sampling rate to ensure no aliasing.<br> <br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On = Wed, Jan 29, 2014 at 7:50 AM, Richard Koch <span dir=3D"ltr"><<a href=3D= "mailto:n1gp@hotmail.com" target=3D"_blank">n1gp(a)hotmail.com</a>></span>= wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <div><div dir=3D"ltr">Can someone clarify what the frequency range is in Di= rect sampling mode.<br><br>The rtl2832u dongle has a 28.8Mhz osc. <br><br>S= o can the dongle in "direct sampling mode" (with appropriate ante= nna connection)<br> receive > 14.4 Mhz (Nyquist) ?<br><br>Googling I find conflicting advice= .<br><br>I've been able to receive > 14.4 Mhz in direct mode, but I&= #39;m not sure if<br>that's due to some non-optimal method...?<br><br> I'm guessing it can because the tuner chip provides both I & Q data= therefore<br>allowing the double rate...?<br><br><br><br> </div= ></div> </blockquote></div><br></div> --047d7bf15fc8eed8c404f1137e92--

1 0

None
by None 03 Jan '22

03 Jan '22

VOR from the Oakland airport. And I have now discovered a ridge near my home with a scenic overlook from which I can receive two. I've tested the software enough to know that the initial scan function seems to work, and the morse decoding kind of works, but I am not confident I'll get it to work very well. (One transmitter's dit looks a lot like another's dah.) The nav signal decoding is simple. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modulated at 9960 Hz. The phase obtained is the azimuth to the station.) If I ever get this working, I looking forward to sharing it with the community. In the process of building this, I created a simple SDR toolkit of DSP functions. It's like Gnuradio in concept, but 16b fixed-point, and has no external dependencies, and C89, so is easier to build on weird and limited platforms. It also has perl bindings. Compared to GR, it looks like the work of a rank amateur just learning DSP, but I do like the concept of there being a GR-like library out there, lightweight and embedded-friendly. Regards, Dave J On Tue, Oct 22, 2013 at 3:06 AM, jdow <jdow(a)earthlink.net> wrote: > He sent me two frequencies in private email. These were in the FM > broadcast band (in the US). He probably needs to notch them out > in order to get adequate response. > > As for wanting narrow bandwidth - I am not quite sure why he thinks > that is a benefit. I use a large FFT (about 10 Hz per bin) and use > the zoom control to see fine detail. (Different FFT settings suite > different uses. This one seems to be a good compromise with my two > needs. I'm too lazy to change it.) > > {^_^} > > > > On 2013/10/22 02:08, Sylvain Munaut wrote: > >> Effective filtering must occur between antenna and receiver. All the >>> problems that a saturated preamp and ADC cause can=92t be repaired by >>> software. Never. >>> >> >> But his original problem is not with saturated preamps or ADC ... it's >> aliasing ... and that can be solved in the digital domain provided >> fast enough ADC. >> >> Cheers, >> >> Sylvain >> >> >> --089e01184768dfc65f04e955c0d5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I originally posted about 115.8 and 116.8 MHz, both square= in the VOR band of 108 to 117.95. I might have sent something else in a PM= , but if so it was a typo. :-) I am definitely only interested in the VOR b= and right now -- though, as you say, it is adjacent to commercial FM with i= ts high power.<div> <br></div><div>My application is simple in concept: A fully auomatic VOR-ba= sed positioning system, a fallback from GPS. I want to scan the entire VOR = band, looking for signals in the standard VOR format that can be demodulate= d. I do the initial scan with a fast sample rate and FFT, just looking for = peaks. From those, I examine the signals to see if it looks like a VOR sign= al. From that list, I will "park" on each signal long enough (~30= s) to decode the VOR's morse code station ID. From that, I will have a = short list of VORs that I can currently receive. From those, if the geometr= y is appropriate (I know the VORs positions from a database) I can calculat= e a position.</div> <div><br></div><div>The software then just round-robin tunes the VORs in ra= nge and continually tries to calculate positions. If too many drop out, it = returns to the initial scan mode.</div><div><br></div><div>Not being able t= o receive this VOR or that VOR is not generally a problem, but obviously, t= he more the better. With extra VORs I have better options for choosing the = closest ones or the ones with the best geometry.</div> <div><br></div><div><br></div><div>This is actually quite difficult to test= , because VORs can generally only be received line-of-sight -- which means = in the air. I'm a private pilot but I found that flying and noodling wi= th a laptop is too much trouble. From my office window, on a high floor in = Oakland, CA, I can receive one VOR from the Oakland airport. And I have now= discovered a ridge near my home with a scenic overlook from which I can re= ceive two.</div> <div><br></div><div>I've tested the software enough to know that the in= itial scan function seems to work, and the morse decoding kind of works, bu= t I am not confident I'll get it to work very well. (One transmitter&#3= 9;s dit looks a lot like another's dah.) The nav signal decoding is sim= ple. (A 30 Hz AM modulated tone is phase compared with a 30 Hz tone FM modu= lated at 9960 Hz. The phase obtained is the azimuth to the station.)</div> <div><br></div><div><br></div><div class=3D"gmail_extra">If I ever get this= working, I looking forward to sharing it with the community. In the proces= s of building this, I created a simple SDR toolkit of DSP functions. It&#39= ;s like Gnuradio in concept, but 16b fixed-point, and has no external depen= dencies, and C89, so is easier to build on weird and limited platforms. It = also has perl bindings. Compared to GR, it looks like the work of a rank am= ateur just learning DSP, but I do like the concept of there being a GR-like= library out there, lightweight and embedded-friendly.</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><= div class=3D"gmail_extra">Regards,</div><div class=3D"gmail_extra">Dave J</= div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, O= ct 22, 2013 at 3:06 AM, jdow <span dir=3D"ltr"><<a href=3D"mailto:jdow@e= arthlink.net" target=3D"_blank">jdow(a)earthlink.net</a>></span> wrote:<br= > <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">He sent me two frequencies in private email.= These were in the FM<br> broadcast band (in the US). He probably needs to notch them out<br> in order to get adequate response.<br> <br> As for wanting narrow bandwidth - I am not quite sure why he thinks<br> that is a benefit. I use a large FFT (about 10 Hz per bin) and use<br> the zoom control to see fine detail. (Different FFT settings suite<br> different uses. This one seems to be a good compromise with my two<br> needs. I'm too lazy to change it.)<br> <br> {^_^}<div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <br> On 2013/10/22 02:08, Sylvain Munaut wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Effective filtering must occur between antenna and receiver. All the<br> problems that a saturated preamp and ADC cause can=92t be repaired by<br> software. Never.<br> </blockquote> <br> But his original problem is not with saturated preamps or ADC ... it's<= br> aliasing ... and that can be solved in the digital domain provided<br> fast enough ADC.<br> <br> Cheers,<br> <br> =A0 =A0 Sylvain<br> <br> <br> </blockquote> </div></div></blockquote></div><br></div></div> --089e01184768dfc65f04e955c0d5--

1 0

None
by None 03 Jan '22

03 Jan '22

it was a saturation issue in RF, it would show up no matter what the sample rate is. Also : - RF filter are often only band specific and not channel specific (because tunable RF filters to do channel selection would be prohibitively expensive) - IF filter (or BB filters for zero-if) are then used for channel selection. So in his case being two channel in the same band (and given the architecture of the dongles), the only saturation that IF filters would provide would be against ADC saturation and it's easy to check if this happens or not just looking at the time domain signal. Cheers, Sylvain

1 0

None
by None 03 Jan '22

03 Jan '22

developer doesn't really know or care about corner cases and as a result it's possible for the GUI to show "green" when in fact there is actually a problem that could be detected. That said, if you've used zadig to install the driver then it should indeed work. > but I can confidently say, I've followed every instruction quite > precisely... I've tried installing the winusb stub for both > instance 0 and 1 What do you mean by instance here again? Sorry if you already mentioned that. If the device has multiple interfaces (a so-called composite device) it is important to install WinUSB for the actual device, and not for either of the two interfaces. > trying everything in both cases in the event that installing it on > the second instance is itself a problem. there's something quite > subtle wrong, given that sdrsharp works perfectly... I don't know how your .exe files were built and if they are using libusb or the hostile fork libusbx which clobbers the soname and uses the same API namespace, the latter driven by that same zadig/libwdi developer. I know the actual libusb very well and it would be interesting to see output from a debug build of my current working directory with libusb source. I've built a binary using the MS C compiler here: http://stuge.se/libusb-1.0.dll Try putting this in the same directory as the program and see if you still have the same problem. Even if the program was built using MinGW that DLL should work well. If yes, the output from the program would be interesting. Thanks //Peter

1 0

None
by None 03 Jan '22

03 Jan '22

ioctl(5, USBDEVFS_CLAIMINTERFACE, 0x7fd063c4) = -1 ENOENT (No such file or directory) The kernel is saying that the interface doesn't exist. lsusb -v for this device run on the fritzbox would be interesting. //Peter

1 0

None
by None 03 Jan '22

03 Jan '22

3.54 GHz. The actual mixer frequency sent to the IF stage is the VCO frequency divided by a number between 2 and 63 -- so the possible center frequency tuning range ends up being in the range of ~24 MHz to 1.77 GHz. However, I was wondering if it would be possible to use a MixDiv of 1 -- to run the mixer frequency directly on the VCO? Has anyone tried that, or would it fry the device somehow? Just wondering if the range could be extended (disregarding any sensitivity issues, of course). -- Per.

1 0

None
by None 03 Jan '22

03 Jan '22

r feature of the device won't be of much use to me, but as for the FM, = I'm on the Ubuntu/Linux GNU platform, so I'm awaiting on the kindne= ss of strangers to perfect the kernel drivers enough to match the Windows k= it performance. But that's okay, because I'm learning a lot in the = process :)<br> <br><div class=3D"gmail_quote">On Mon, Aug 13, 2012 at 11:44 PM, Adam Niels= en <span dir=3D"ltr"><<a href=3D"mailto:a.nielsen@shikadi.net" target=3D= "_blank">a.nielsen(a)shikadi.net</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> so it is /designed/ for FM? =A0That's encouraging because mostly that i= s all I<div class=3D"im"><br> really need from it, only all my experiments so far have yielded only<br></= div> AM-quality sound, but it's good to hear because it means there's /h= ope/ and so<div class=3D"im"><br> I'll just keep hanging in there until an FM recipe surfaces :)<br> </div></blockquote> <br> Yes, because the dongles provide digital TV (via hardware) and as an extra = selling point, analogue FM radio (provided via the SDR.)<br> <br> I don't know what platform you're on or what your goals are, but I = hear the SDR# program for Windows offers excellent stereo FM support, as it= 's one of the few programs that can deal with the ~120kHz bandwidth nee= ded for a WBFM signal.<br> <br> Cheers,<br> Adam.<br> <br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div style= =3D"text-align:right"><i><span style=3D"font-size:x-small">Have Blog, Will = Travel: </span><span style=3D"font-size:x-small"><a href=3D"http://blog.tel= edyn.com" target=3D"_blank">blog.teledyn.com</a></span></i></div> <div style=3D"text-align:right"><i><span style=3D"font-size:x-small">A Serv= iceable Substitute: <a href=3D"http://post.teledyn.com" target=3D"_blank">p= ost.teledyn.com</a></span></i></div><br> --f46d042fd93a1d197104c738bd48--

1 0

None
by None 03 Jan '22

03 Jan '22

from DVB-T (I am a complete neophyte at all of this) and so that particular feature of the device won't be of much use to me, but as for the FM, I'm on the Ubuntu/Linux GNU platform, so I'm awaiting on the kindness of strangers to perfect the kernel drivers enough to match the Windows kit performance. But that's okay, because I'm learning a lot in the process :) On Mon, Aug 13, 2012 at 11:44 PM, Adam Nielsen <a.nielsen(a)shikadi.net>wrote: > so it is /designed/ for FM? That's encouraging because mostly that is all >> I >> >> really need from it, only all my experiments so far have yielded only >> AM-quality sound, but it's good to hear because it means there's /hope/ >> and so >> >> I'll just keep hanging in there until an FM recipe surfaces :) >> > > Yes, because the dongles provide digital TV (via hardware) and as an extra > selling point, analogue FM radio (provided via the SDR.) > > I don't know what platform you're on or what your goals are, but I hear > the SDR# program for Windows offers excellent stereo FM support, as it's > one of the few programs that can deal with the ~120kHz bandwidth needed for > a WBFM signal. > > Cheers, > Adam. > > > -- *Have Blog, Will Travel: blog.teledyn.com* *A Serviceable Substitute: post.teledyn.com* --f46d042fd93a1d197104c738bd48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

1 0

[CFP] Free Software Radio DevRoom 2022
by Andrej Rode 23 Dec '21

23 Dec '21

Dear friends and fans of software-defined radio and free/open-source radio topics in general, FOSDEM 2022 (the free and open-source developer's meeting usually in Brussels, Europe but **repeatedly virtual**) will again feature a track on Software Defined Radio and any other radio-related topics in the **Free Software Radio** devroom. Therefore, we invite developers and users from the free software radio community to join us for this track and present your work, ideas and/or demos. Given the current circumstances and the virtual nature of this event in 2022, we are asking the presenters to pre-record the talks, which will then be gathered by us and streamed during the event. Presenters are also asked to be present online during their timeslot for live Q&A. Software Radio is an important tool for educators, tinkerers and industry to implement signal processing and communication algorithms in software while still allowing for easy access to real signals. This allow anyone to access the EM spectrum out of curiosity, for research or for profit. At FOSDEM we want to foster collaboration and exchange of ideas between different projects in the field of SDR. We hope to network all these projects, and improve collaboration, bring new ideas forward and get more people involved. The track's website resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website. Notice that the reference time will be Brussels local time (CET). https://fosdem.org/2022/schedule/track/free_software_radio/ Additional Information will be also available at: https://wiki.gnuradio.org/index.php/FOSDEM_2022 ** Submit your presentations To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM22 and follow the instructions (you need an account, but can use your account from last year if you have one. Please do NOT create a new account if you already have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Your submission should have the following information: * Your contact Email * A descriptive title and subtitle of your talk * A short abstract * Links related to the project * [Optional] A longer description of the content of your talk. Lengths aren't fixed, but give a realistic estimate, and please don't exceed 30 minutes unless you have something special planned (in that case, contact one of us). We will typically go for 30-minute slots -- shorter talks, unless they're really short, usually tend to screw up the schedule too much. Please take into account some live Q&A at the end of your presentation, going for 25 minutes presentation plus 5 minutes for Q&A will provide a more lively conference experience for everyone. You aren't limited to slide presentations, of course. Be creative. However, FOSDEM is an free software conference, therefore we ask you to stay clear of marketing presentations and present something relevant to free/open software. We like nitty-gritty technical stuff. Topics discussed in this devroom include (but are not limited to): * SDR Frameworks + Tools * Cellular/telecoms software * Free/Open SDR hardware * Wireless security * Random fun wireless hacks * SDR in education * Satellite/spacecraft communication * Ham radio related topics ** Important Dates * Submission deadline: 26 December 2021 * Announcement of selected talks: 31 December 2021 * (preliminary) Pre-recorded presentation submission deadline: 23 January 2022 * Conference dates 5 & 6 February 2022 online * Free software radio devroom date: Sunday 6 February 2022 online In the last years we were always full to the brim with presentations, so if you want to present, please make sure to submit your abstracts soon! (It might be possible to get our allotted time extended to Saturday - given enough volunteers and high quality presentations to cover two days, but that's only an option as last resort) ** Following steps for accepted talks When your talk is accepted, you will be contacted by a deputy who will help you with the pre-recording of your talk. Together you will make sure that the content has the required quality and is stream-ready. When complete, the recording will be located into the streaming system, and Bob's your uncle. Don't forget that you **must** be available during the allocated timeslot of your talk for live Q&A. ** Steering Committee The track committee consists of: * Phil Balister - "Crofton" * Derek Kozel - "dkozel" * Andrej Rode - "noc0lour" * Martin Braun - "mbr0wn" Hope to hear from you soon! And please forward this announcement. Cheers Andrej

1 1

Cmake fails during osmocom grc block installation
by Thangaraj Mukara Dhakshinamoorthy 11 Nov '21

11 Nov '21

Hello, My system config: OS: Ubuntu 20.04.3 LTS OS Type: 64-bit RAM: 3.8 GB Processor: Intel Core i5-2450M CPU @2.50GHz x4 UHD version: 3.15.0.0 GNU Radio version: 3.8.1.0 SDR Device: Ettus USRP N320 Antenna Freq: 868 MHz I tried to build osmocom block in my existing gnuradio environment, but I got the following error during cmake command. The console logs are shown below. Console logs: komro@komro-HP-ProBook-6560b:~/gnuradio/gr-osmosdr/build$ cmake ../ -- The CXX compiler identification is GNU 9.3.0 -- The C compiler identification is GNU 9.3.0 -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Build type not specified: defaulting to release. -- Found Git: /usr/bin/git (found version "2.25.1") -- Extracting version information from git describe... -- Configuring Boost C++ Libraries... -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components: thread system -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") -- Checking for module 'gruel' -- No package 'gruel' found -- Could NOT find GRUEL (missing: GRUEL_LIBRARIES GRUEL_INCLUDE_DIRS) -- Checking for module 'gnuradio-core' -- No package 'gnuradio-core' found -- Could NOT find GNURADIO_CORE (missing: GNURADIO_CORE_LIBRARIES GNURADIO_CORE_INCLUDE_DIRS) -- Checking for module 'gnuradio-iqbalance' -- No package 'gnuradio-iqbalance' found -- Could NOT find GNURADIO_IQBALANCE (missing: GNURADIO_IQBALANCE_LIBRARIES GNURADIO_IQBALANCE_INCLUDE_DIRS) -- Checking for module 'uhd' -- No package 'uhd' found -- Could NOT find UHD (missing: UHD_LIBRARIES UHD_INCLUDE_DIRS) -- Checking for module 'gnuradio-uhd' -- Found gnuradio-uhd, version 3.8.1 -- gnuradio-uhd not found. -- Could NOT find GNURADIO_UHD (missing: GNURADIO_UHD_INCLUDE_DIRS) -- Checking for module 'gnuradio-fcd' -- No package 'gnuradio-fcd' found -- gnuradio-fcd not found. -- Could NOT find GNURADIO_FCD (missing: GNURADIO_FCD_LIBRARIES GNURADIO_FCD_INCLUDE_DIRS) -- Checking for module 'gnuradio-fcdproplus' -- No package 'gnuradio-fcdproplus' found -- gnuradio-fcdproplus not found. -- Could NOT find GNURADIO_FCDPP (missing: GNURADIO_FCDPP_LIBRARIES GNURADIO_FCDPP_INCLUDE_DIRS) -- Checking for module 'libosmosdr' -- No package 'libosmosdr' found -- libosmosdr not found. -- Checking for module 'librtlsdr' -- Found librtlsdr, version 0.6.0-32-gd770 -- Found librtlsdr: /usr/local/include, /usr/local/lib/librtlsdr.so -- Checking for module 'libmirisdr' -- No package 'libmirisdr' found -- libmirisdr not found. -- Checking for module 'libhackrf' -- No package 'libhackrf' found -- Could NOT find LIBHACKRF (missing: LIBHACKRF_LIBRARIES LIBHACKRF_INCLUDE_DIRS) -- Checking for module 'libairspy' -- No package 'libairspy' found -- Could NOT find LIBAIRSPY (missing: LIBAIRSPY_LIBRARIES LIBAIRSPY_INCLUDE_DIRS) -- Checking for module 'libbladeRF' -- No package 'libbladeRF' found -- libbladeRF not found. -- Found Doxygen: /usr/bin/doxygen (found version "1.8.17") found components: doxygen missing components: dot CMake Error at CMakeLists.txt:166 (message): Gruel required to build gr-osmosdr -- Configuring incomplete, errors occurred! See also "/home/komro/gnuradio/gr-osmosdr/build/CMakeFiles/CMakeOutput.log". See also "/home/komro/gnuradio/gr-osmosdr/build/CmakeFiles/CmakeError.log". What am I missing here? I installed the required RTL-SDR packages too! PFA CMake files Best regards, Thangaraj

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
91
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

osmocom-sdr