Re: gr-iqbal->gr-osmosdr->gqrx missing pkgconfig files break gr-3.8 builds
On 04/02/2020 07:45, Sylvain Munaut wrote:
Without a .pc in gr-iqbal, gr-osmosdr (3.8 branch) will not build as it
can't find gr-iqbal.
I just had a look at gr-osmosdr-0.1.4.127-3.mga7.src.rpm and this is
not using the official code from the gr3.8 branch of
git.osmocom.org/gr-osmosdr
True, that is from Mageia 7, the current stable release which has not
and will never have anything related to gnuradio-3.8.
I am working on Mageia 8 which is under develpoment (A.K.A. Cauldron).
I have already updated to gnuradio-3.8 in Cauldron and also updated to
gr-iqbal-0.38.1
The version of gr-osmosdr that I am currently working on is from the
gr-3.8 branch which was taken from git as gr-osmosdr-gr3.8.zip.
The code in that repo at absolutely no point will ever look for a pkg
config file.
OK, I have re-tested the gr-osmosdr build again with the gr-iqbal.pc
missing and it does now build, so that appears to be correct.
In 3.8 the modules install 3 cmake specific files :
gnuradio-osmosdrConfig.cmake
gnuradio-osmosdrTargets.cmake
gnuradio-osmosdrTargets-release.cmake
Yes they are there:
gnuradio-osmosdrConfig.cmake
gnuradio-osmosdrTargets.cmake
gnuradio-osmosdrTargets-relwithdebinfo.cmake
and I found a patch which was causing the wrong name to be searched, so
that now builds.
and these contain all the informations needed by cmake to know which
libraries to link and which include directory the add to the include
path and any dependency on other cmake modules.
OK
Theses are also automatically generated by cmake, without the need to
duplicate the information in another file.
If you look at CMakeList for iqbal for instance :
target_include_directories(gnuradio-iqbalance
PRIVATE ${LIBOSMODSP_SEL_INCLUDE_DIRS}
PUBLIC ${Boost_INCLUDE_DIRS}
PUBLIC $
PUBLIC $
)
the PRIVATE / PUBLIC / INTERFACE / ... are all specifiers for cmake to
generate those files properly and include everything needed
automatically.
If this doesn't work for you, either :
- You're not using the right source as pointed out above ...
- Something is broken in the gr-iqbal / gr-osmosdr CMake that makes
it not work properly ( wronge PRIVATE / PUBLIC specifier or something
omitted or something like this )
- Something else in your setup is broken that breaks cmake's module system
In gqrx build I am now hitting a fail to find gnuradio from this line in
CMakeLists.txt:
find_package(gnuradio REQUIRED COMPONENTS analog audio blocks digital
filter fft)
//
CMake Error at CMakeLists.txt:120 (find_package):
By not providing "Findgnuradio.cmake" in CMAKE_MODULE_PATH this
project has
asked CMake to find a package configuration file provided by "gnuradio",
but CMake did not find one.
Could not find a package configuration file provided by "gnuradio"
with any
of the following names:
gnuradioConfig.cmake
gnuradio-config.cmake
Add the installation prefix of "gnuradio" to CMAKE_PREFIX_PATH or set
"gnuradio_DIR" to a directory containing one of the above files. If
"gnuradio" provides a separate development package or SDK, be sure it has
been installed.
//--
All gnuradio is libified so we generate rpm packages for each library,
each of which in turn produces it's own -devel rpm package containing
the cmake files for that package.
There is no gnuradio.cmake or Findgnuradio-*.cmake files - no idea why.
The *Config.cmake files for example for gnuradio that I have currently
installed locally are:
./gnuradio-digitalConfig.cmake
./gnuradio-vocoderConfig.cmake
./gnuradio-audioConfig.cmake
./gnuradio-qtguiConfig.cmake
./gnuradio-pmtConfig.cmake
./gnuradio-channelsConfig.cmake
./gnuradio-blocksConfig.cmake
./gnuradio-iqbalanceConfig.cmake
./gnuradio-uhdConfig.cmake
./gnuradio-dtvConfig.cmake
./gnuradio-fecConfig.cmake
./gnuradio-waveletConfig.cmake
./gnuradio-video-sdlConfig.cmake
./gnuradio-analogConfig.cmake
./gnuradio-fftConfig.cmake
./gnuradio-trellisConfig.cmake
./gnuradio-runtimeConfig.cmake
./gnuradio-zeromqConfig.cmake
./gnuradio-filterConfig.cmake
each of the above from different rpm packages.
In anycase, none of this requires pkg-config files.
OK I believe you now and thank you for your explanations :)
How can we work around the above gqrx issue?
This does not get any easier!
Cheers,
Sylvain
Cheers,
Barry
Re: Slack alternatives
+1 On Tue, Feb 4, 2020 at 10:26 AM Sylvain Munaut <246...@gmail.com> wrote: > Hi > > > as you might know, Slack has become a very frequently used tool for > communication in the project. > > Tbh, I never understood the hype around Slack (not the form of > communication but the specific software). It deletes our old messages and > takes up a ridiculous amount of RAM. > > +1 > > > Are there any people interested on switching to an alternative, like > Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s > like Slack, but self-hosted, open-source and free. > > I think Andre was working on an alternative. > > Cheers, > >Sylvain > > -- Gerry Creager NSSL/CIMMS 405.325.6371 ++ *The way to get started is to quit talking and begin doing.* * Walt Disney*
RE: Slack alternatives
I vote we follow Sebastian's suggestion. Best regards, Jeff Wallace Original message From: Sebastian Müller Date: 2/4/20 1:21 PM (GMT-03:00) To: discuss-gnuradio@gnu.org Subject: Slack alternatives Hi all,as you might know, Slack has become a very frequently used tool for communication in the project.Tbh, I never understood the hype around Slack (not the form of communication but the specific software). It deletes our old messages and takes up a ridiculous amount of RAM. Are there any people interested on switching to an alternative, like Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s like Slack, but self-hosted, open-source and free.[1] https://mattermost.com/Sebastian Müllergse...@gmail.com PGP ID DC2AA3EE
Re: Slack alternatives
Hi Everyone, we're on this already :) But we do take your emails as "this needs to be bumped up in priority". Thanks! Marcus On Tue, 2020-02-04 at 17:32 +0100, Albin Stigö wrote: > +1 > > On Tue, Feb 4, 2020, 17:26 Sylvain Munaut <246...@gmail.com> wrote: > > Hi > > > > > as you might know, Slack has become a very frequently used tool for > > > communication in the project. > > > Tbh, I never understood the hype around Slack (not the form of > > > communication but the specific software). It deletes our old messages and > > > takes up a ridiculous amount of RAM. > > > > +1 > > > > > Are there any people interested on switching to an alternative, like > > > Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s > > > like Slack, but self-hosted, open-source and free. > > > > I think Andre was working on an alternative. > > > > Cheers, > > > >Sylvain > > smime.p7s Description: S/MIME cryptographic signature
Re: Slack alternatives
+1 On Tue, Feb 4, 2020, 17:26 Sylvain Munaut <246...@gmail.com> wrote: > Hi > > > as you might know, Slack has become a very frequently used tool for > communication in the project. > > Tbh, I never understood the hype around Slack (not the form of > communication but the specific software). It deletes our old messages and > takes up a ridiculous amount of RAM. > > +1 > > > Are there any people interested on switching to an alternative, like > Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s > like Slack, but self-hosted, open-source and free. > > I think Andre was working on an alternative. > > Cheers, > >Sylvain > >
Re: Slack alternatives
Hi > as you might know, Slack has become a very frequently used tool for > communication in the project. > Tbh, I never understood the hype around Slack (not the form of communication > but the specific software). It deletes our old messages and takes up a > ridiculous amount of RAM. +1 > Are there any people interested on switching to an alternative, like > Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s like > Slack, but self-hosted, open-source and free. I think Andre was working on an alternative. Cheers, Sylvain
Slack alternatives
Hi all, as you might know, Slack has become a very frequently used tool for communication in the project. Tbh, I never understood the hype around Slack (not the form of communication but the specific software). It deletes our old messages and takes up a ridiculous amount of RAM. Are there any people interested on switching to an alternative, like Mattermost [1]? I’m not deep in the topic, but from what I’ve heard it’s like Slack, but self-hosted, open-source and free. [1] https://mattermost.com/ Sebastian Müller gse...@gmail.com PGP ID DC2AA3EE signature.asc Description: Message signed with OpenPGP using AMPGpg
Re: [EXT] Re: Recommendation for high sample rate receiver?
Oh you're of course right :) My rule of thumb was "7 to 9 times the fundamental frequency in bandwidth for reliable edges". Cheers, Marcus On Mon, 2020-02-03 at 14:05 +, Chesir, Aaron M. wrote: > Your statement " A signal with 0.1 microsecond rise time definitely > has definitely more than 6 MHz bandwidth" is not necessarily true. > > Simple proof: > > The first 3 components of a 1 Mcycle/sec square wave are: > sin(2*pi*1e6*t) + (1/3) sin(2*pi*3*1e6*t) + (1/5) sin(2*pi*5*1e6*t). > > If you add just the above 3 components, the highest component of the > resultant signal is obviously 5 MHz. > > Its rise time is 0.1 microseconds. > > Aaron > > -Original Message- > From: Discuss-gnuradio < > discuss-gnuradio-bounces+achesir=mitre@gnu.org> On Behalf Of > Müller, Marcus (CEL) > Sent: Monday, February 3, 2020 6:18 AM > To: mike.nel...@rdss.com; discuss-gnuradio@gnu.org > Subject: [EXT] Re: Recommendation for high sample rate receiver? > > Hi Mike, > thanks for following up on this: > A signal with 0.1 microsecond rise time definitely has definitely > more than 6 MHz bandwidth :) so that's where my confusion stems from. > > It will have something upwards of 20 MHz, rule of thumb should be > around 100 MHz bandwidths, and that fits nicely with the bare > necessary > 40 MHz bandwidth for do anything at a 25ns timescale. > As said, if you can capture that amount of bandwidth, you can infer > the timing – you really do not need 500 MS/s, as far as I can tell > from your description of the signal. > Then again, there might be complicating factors – extreme dynamic > range, for example. > > Could you tell us more details about your signal? And also, "as > accurately as possible" is not a spec; could you say "I need a timing > accuracy of X ns, given an SNR of Y dB", so that we could help you > there? > > Best regards, > Marcus > > On Sat, 2020-02-01 at 02:58 -0500, Mike wrote: > > Thank you to all who commented. > > > > The target signal of interest uses pulse modulation where each > > pulse > > is 1 microsecond in duration, with a rise time of less than 0.1 > > microsecond and a decay time of less than 0.2 microseconds. The > > goal > > is to identify the start (arrival) of a transmission at each > > receiver > > site as accurately as possible (better than 25 ns). > > > > Interpolation adds no useful information regarding start time, of > > course. Lower sampling rates lose arrival time resolution. > > > > No affordable SDR supports 500 MS/sec; I'm looking at A/D > > evaluation > > boards with an RF front end. > > > > > > Thanks! > > > > > > > > On 1/29/2020 10:34 PM, Kyeong Su Shin wrote: > > > To whom it may concern: > > > > > > Forgot to mention: There is a Wikipedia article, listing SDR > > > receivers with various capabilities ( > > > https://en.wikipedia.org/wiki/List_of_software-defined_radios ). > > > There's also something called OneRadio ( > > > http://www.oneradiocorp.com/ ). I saw an actual build of > > > OneRadio, > > > and it was pretty impressive (but expensive, of course). > > > > > > Do not expect these receivers to be well-supported by GNU Radio, > > > however. However (I think it is not necessary, but), if you > > > still > > > want to get a fast receiver and do not want to roll out your own > > > receiver using oscilloscopes or FPGAs, then I guess these > > > are possible alternatives. > > > > > > Regards, > > > Kyeong Su Shin > > > 보낸 사람: Kyeong Su Shin 대신 Discuss-gnuradio > > > < > > > discuss-gnuradio-bounces+ksshin=postech.ac...@gnu.org> > > > 보낸 날짜: 2020년 1월 30일 목요일 오후 12:10 > > > 받는 사람: discuss-gnuradio@gnu.org ; > > > mike.nel...@rdss.com > > > 제목: Re: Recommendation for high sample rate receiver? > > > > > > To whom it may concern: > > > > > > It is already well-discussed, but I would like to add a few > > > points: > > > > > > -If you absolutely want to have a such receiver (it's pretty > > > meaningless, as discussed already, but if you still want to), > > > then > > > you can grab a digital oscilloscope or a similar hardware and > > > attach > > > a RF frontend to it. You will end up losing some (actually, most > > > of) > > > samples, but you cannot run non-trivial data processing chains > > > at > > > 500MS/s in real-time with a generic desktop CPU anyway. > > > > > > -Regarding on why this is pretty meaningless (not using the > > > Nyquist > > > criterion or maths, but using intuitions): consider two > > > consecutive > > > samples, sampled by your receiver. Since the sampling rate is > > > way > > > higher than the bandwidth of the signal, these values are going > > > to > > > be nearly identical. There could be a bit of differences in the > > > amplitude and the phase, but the differences will be pretty > > > small > > > and will be easily washed out by the noise. You cannot expect to > > > get reliable TDOA results from that. You will have to > > > use > > > more samples to get more reliable
Re: gr-iqbal->gr-osmosdr->gqrx missing pkgconfig files break gr-3.8 builds
If that can help those interested in GQRX under GNURadio 3.8
(this worked for me under an Ubuntu 1.04 fresh install):
installs from source gr3.8 branch of
git.osmocom.org/gr-osmosdr (not yet available as debian package)
install some GQRX dependancies
sudo apt-get install qtbase5-dev qtdeclarative5-dev
libqt5svg5 libqt5svg5-dev libasound2 libasound2-dev libjack-dev
libportaudio2 portaudio19-dev libpulse-dev
installs from source branch master
from https://github.com/csete/gqrx (not yet available as debian
package)
regards
On 04/02/2020 08:45, Sylvain Munaut
wrote:
Without a .pc in gr-iqbal, gr-osmosdr (3.8 branch) will not build as it
can't find gr-iqbal.
I just had a look at gr-osmosdr-0.1.4.127-3.mga7.src.rpm and this is
not using the official code from the gr3.8 branch of
git.osmocom.org/gr-osmosdr
The code in that repo at absolutely no point will ever look for a pkg
config file.
In 3.8 the modules install 3 cmake specific files :
gnuradio-osmosdrConfig.cmake
gnuradio-osmosdrTargets.cmake
gnuradio-osmosdrTargets-release.cmake
and these contain all the informations needed by cmake to know which
libraries to link and which include directory the add to the include
path and any dependency on other cmake modules.
Theses are also automatically generated by cmake, without the need to
duplicate the information in another file.
If you look at CMakeList for iqbal for instance :
target_include_directories(gnuradio-iqbalance
PRIVATE ${LIBOSMODSP_SEL_INCLUDE_DIRS}
PUBLIC ${Boost_INCLUDE_DIRS}
PUBLIC $
PUBLIC $
)
the PRIVATE / PUBLIC / INTERFACE / ... are all specifiers for cmake to
generate those files properly and include everything needed
automatically.
If this doesn't work for you, either :
- You're not using the right source as pointed out above ...
- Something is broken in the gr-iqbal / gr-osmosdr CMake that makes
it not work properly ( wronge PRIVATE / PUBLIC specifier or something
omitted or something like this )
- Something else in your setup is broken that breaks cmake's module system
In anycase, none of this requires pkg-config files.
Cheers,
Sylvain
Re: Using other blocks inside OOT
Thanks for your reply On Tue, Feb 4, 2020 at 10:28 AM Sylvain Munaut <246...@gmail.com> wrote: > > Hi, > > > Now I'd like to take each message, demod it using the GFSK block which I've > > tested that it work successfully on stream, run sanity on the bits > > (preamble, trailer, FEC) and if the packet is good, send a new message with > > the bits and the original I/Q signal to the next block for further > > processing. > > > > 1. What will be the best way to do it in a flow-graph? > > 2. Is it possible to reuse code from other blocks directly/imperatively > > without connecting the block into a flow-graph? > > You can't "call" another block yourself really, unless you want to > re-implement enough of gnuradio runtime for it to run ... > > What you can do to make it transparent is make a hierarchical block > (hier_block2) that actually contains your custom block and the gfsk > block internally. Can I examine the output of the GFSK bits at this point, or should I create an additional block that drops the packets that doesn't pass sanity? > > Now for your particular application, I would have two custom blocks : > - One that detects the bursts and adds tags on the stream. I'm actually implementing this in 2 blocks, one that tags the stream with "start", "end" and "cancel" and another block that aggregates the samples between "start" and "end" that don't have "cancel" in between. Is there a better way to do it? > - You take the output of that and feed it to the GFSK demod > - Then another block that takes as input both the GFSK demod and the > output of the first block directly looks at the tags and recreates > messages by resyncing both streams. > > And then you can encapsulate all of this in a hier_block. > > Cheers, > > Sylvain
Re: Using other blocks inside OOT
Hi, > Now I'd like to take each message, demod it using the GFSK block which I've > tested that it work successfully on stream, run sanity on the bits (preamble, > trailer, FEC) and if the packet is good, send a new message with the bits and > the original I/Q signal to the next block for further processing. > > 1. What will be the best way to do it in a flow-graph? > 2. Is it possible to reuse code from other blocks directly/imperatively > without connecting the block into a flow-graph? You can't "call" another block yourself really, unless you want to re-implement enough of gnuradio runtime for it to run ... What you can do to make it transparent is make a hierarchical block (hier_block2) that actually contains your custom block and the gfsk block internally. This way your "users" only instantiate one block, but internally it contains several. Now for your particular application, I would have two custom blocks : - One that detects the bursts and adds tags on the stream. - You take the output of that and feed it to the GFSK demod - Then another block that takes as input both the GFSK demod and the output of the first block directly looks at the tags and recreates messages by resyncing both streams. And then you can encapsulate all of this in a hier_block. Cheers, Sylvain
Using other blocks inside OOT
Hi all, I'm trying to demodulate a GFSK signal in a very noisy environment, I'd like to extract packets and pack their bits together with the corresponding original I/Q signal items in a single message. I wrote a module that detect bursts that has no significant power variation (clean packets) and sends them as messages. Now I'd like to take each message, demod it using the GFSK block which I've tested that it work successfully on stream, run sanity on the bits (preamble, trailer, FEC) and if the packet is good, send a new message with the bits and the original I/Q signal to the next block for further processing. 1. What will be the best way to do it in a flow-graph? 2. Is it possible to reuse code from other blocks directly/imperatively without connecting the block into a flow-graph? Thanks, Desmond
