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
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
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.
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--
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
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
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
Hello Vasil,
The problem was with gr-fcdproplus package only! After removing it was installing fine and I got it under GRC Menu!
But there is a new error while executing the flowgraph!
Console:
Generating: '/home/thangz/Desktop/gnuradio/rtlsdr_fm_spectrum_simple.py'
Executing: /usr/bin/python3 -u /home/thangz/Desktop/gnuradio/rtlsdr_fm_spectrum_simple.py
Traceback (most recent call last):
File "/usr/local/lib/python3/dist-packages/osmosdr/__init__.py", line 17, in <module>
from .osmosdr_python import *
ImportError: generic_type: type "sink" referenced unknown base type "gr::hier_block2"
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/thangz/Desktop/gnuradio/rtlsdr_fm_spectrum_simple.py", line 37, in <module>
import osmosdr
File "/usr/local/lib/python3/dist-packages/osmosdr/__init__.py", line 21, in <module>
from .osmosdr_python import *
ImportError: generic_type: type "sink" referenced unknown base type "gr::hier_block2"
What is the problem here?
Regards,
Thangaraj
-----Ursprüngliche Nachricht-----
Von: Vasil Velichkov <vvvelichkov(a)gmail.com>
Gesendet: Mittwoch, 27. Oktober 2021 13:27
An: Thangaraj Mukara Dhakshinamoorthy <thangaraj(a)komro.net>; osmocom-sdr(a)lists.osmocom.org
Betreff: Re: AW: AW: Make fails while installing gr-osmosdr
Hi Thangaraj,
On 27/10/2021 13.51, Thangaraj Mukara Dhakshinamoorthy wrote:
> Sorry! I was wrong, I installed main-3.9 only!
OK.
> I guess the problem would be something to do with the cmake prefix path I have passed:
I doubt that it is related to the prefix. Have you tried deleting gr-osmosdr's build directory and starting from scratch (after remvoing gr-fcdproplus package)? Alternatively you can delete only the CMakeCache file.
What is the exact problem that you have right now? Provide the full cmake and make output.
Hello,
My system config:
Host OS: Windows 10
Guest OS: VirtualBox Ubuntu 20.04.3 LTS
UHD version: 3.15.0.0
GNU Radio version: 3.9
SDR Device : RTL-SDR Dongle
I got the below error while executing the make command:
>thangz@thangz-VirtualBox:~/Desktop/gr-osmosdr/build$ cmake -DCMAKE_PREFIX_PATH=/usr ../
.
.
-- Configuring done
-- Generating done
-- Build files have been written to: /home/thangz/Desktop/gr-osmosdr/build
>thangz@thangz-VirtualBox:~/Desktop/gr-osmosdr/build$ make
.
.
/usr/local/include/gnuradio/hier_block2.h:93:35: note: no known conversion for argument 1 from 'gr::fcdproplus::fcdproplus::sptr' {aka 'boost::shared_ptr<gr::fcdproplus::fcdproplus>'} to 'gr::basic_block_sptr' {aka 'std::shared_ptr<gr::basic_block>'}
93 | void connect(basic_block_sptr src, int src_port, basic_block_sptr dst, int dst_port);
make[2]: *** [lib/CMakeFiles/gnuradio-osmosdr.dir/build.make:128: lib/CMakeFiles/gnuradio-osmosdr.dir/fcd/fcd_source_c.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:417: lib/CMakeFiles/gnuradio-osmosdr.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
What may I do to fix this error? What am I missing here? Please help!
PS: I just need the RTL-SDR component, so I installed the dependency for that alone (see complete log file).
PFA complete log file
Best regards
Thangaraj