Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Sylvain Munaut]

> If that's the case, then Mint are now packaging a version of UHD that is NOT
>from NI/Ettus.

Doesn't UHD have like a plugin system that can dynamically load .so
files ? The UHD_MODULE_PATH thing ?

So it could be a perfectly legit UHD just with some soapy plugin
loaded dynamically.

Cheers,

Sylvain

Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)

[Sylvain Munaut]

Hi,

The " type: soapy" probably means there is some weird plugin installed
making soapy device appear as UHD device or something. (and so it's
using any audio device as IQ source ...)

And uhd_usrp_probe only probes the first device which is not the
B200mini so you need to give it some address argument to select the
b200 mini.

Cheers,

   Sylvain

Re: Galileo E5a and E5b bands simultaneously receiver with GRC

[Sylvain Munaut]

Hi,


> - Number of channels: 1 ( Since USRP 2190 model has only 1 local oscillator, 
> it will not be possible to use 2 simultaneously channels for receiving)

Well, you could still tune the RF between the two freq and then use
the DDC to shift and decimate each channel separately so that you can
have a sample rate much much lower than bringing the full 50 MHz to
the PC.
It saves on USB traffic, making it more reliable and on host side processing.

Just my 2 ct.

Cheers,

   Sylvain

Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)

[Sylvain Munaut]

> > I used to have a working flowgraph developed with GR 3.10.2, but after
> > update to GR 3.10.4 it just ends with a segmentation fault.

The 'master' branch should work for 3.9 and 3.10
The 'gr-3.7' and 'gr-3.8' branches are historical branch for those
specific versions of

But I haven't personally tested with 3.10.4 ...

Doing CL / GL in multithread application always requires quite a bit
of care and it's possible a recent version of GR broke one of the
assumption made ...

Cheers,

   Sylvain

Re: fosphor sink block error

[Sylvain Munaut]

Hi,

TBH, the way you had it installed in your original post was fine and you
might want to revert to that.
Sure it might have been 3.8 but if it's been packaged, the maintainer must
have ensured it was fine and a known working stable version and it should
work provided the right drivers.

So if you have the opportunity to go back to that, it's probably easier
than trying to mix a packaged and source install ... especially if you're
not very familiar with all the details of how this works.


Cheers,
Sylvain

Re: fosphor sink block error

[Sylvain Munaut]

Hi,


If you're using Ubuntu, you can try the intel-opencl-icd package which
is the binary package for https://github.com/intel/compute-runtime
which is the OpenCL driver for Intel GPUs.
However, I'm not sure anyone has ever run fosphor with it ... not sure
if it supports the features required, I only tried on AMD and NVidia
GPUs as I don't have any Intel GPU supporting that driver.

Cheers,

  Sylvain

Re: fosphor sink block error

[Sylvain Munaut]

Hi Gwendoline,


> I tried various versions of Gnuradio but fosphor sink block doesn't work 
> under 3.8 or 3.9.

Definitely go for 3.9
I only maintain it for the latest version of gnuradio ( so it might be
3.10 only soon ... ).


> [!] CL Error (-1001, 
> /build/gr-fosphor-1DVbtt/gr-fosphor-3.8~2.2d4fe78/lib/fosphor/cl.c:299): 
> Unable to fetch platform IDs
> [!] No suitable OpenCL device found
> gr::log :ERROR: qt_sink_c0 - Failed to initialize fosphor

So that's a sign that it found no valid OpenCL device.
Most distribution don't install proper OpenCL drivers by default.

The OpenCL stack is composed of two elements :
 - The "Dispatcher" : which is just a shim to dispatch OpenCL requests
to multiple "platforms" (i..e vendors basically) in case you have
several OpenCL devices in your system.
 - The actual driver that talks to the hardware.

Obviously you have the dispatcher installed (called "ICD Loader"), but
there was no driver (caled "ICD") found (or if there was drivers,
those drivers reported no valid/available devices).

What GPU do you have in your machine ?
Also, list the files in `/etc/OpenCL/vendors/` which gives the
installed drivers.

Cheers,

   Sylvain

Re: USRP N210 growing latencies

[Sylvain Munaut]

Hi,


> OK I understand that. But is there any solution which permits to reset that 
> growing propagation delay ? How to reset the flowgraph buffers without 
> killing the application and restart it ? Is there any method that permits to 
> purge and resync buffers of the flowgraph ?

The USRP supports timestamps for RX and TX.
So you get tags for when data was received / is supposed to be transmitted.
Using a custom block to modify the RX tags into TX tags ( to change
the RX timestamps to TX timestamps a bit into the future ), you should
be able to achieve a constant controlled latency.

Cheers,

Sylvain

Re: Proper GMSK Decoding with the Viterbi Algorithm

[Sylvain Munaut]

Quick note that gr-gsm has a viterbi enabled GMSK demod block.

Cheers,

Sylvain

Re: gr-fosphor display freeze issues

[Sylvain Munaut]

Hi Paul,

Mmm that's strange. What NVidia driver version are you running ? And
any chance they got updated (or other part of the OS) between the last
time it worked and now ?
I'm not sure what timeout you're talking about, but in any case, the
batch size (CL job) in gr-fosphor is constant, there is just more of
them sent one after the other for high sample rates.

Cheers,

   Sylvain

Re: GR-3.9 Windows BETA "Installer"

[Sylvain Munaut]

Hi Geof,

I had a quick look, seems you included fosphor, thank you. However it
seems the python/grc binding weren't built ? I only see the c++ block
in there.

Cheers,

Sylvain

Re: hwo to convert 3.8 GRC to 3.7

[Sylvain Munaut]

> It's usually not that hard to get a modern GNU Radio, so honestly, let's
> rather work on installing GNU Radio 3.8.

I'd suggest 3.9 directly.

Cheers,

   Sylvain

Re: Vector Source and QT GUI Time Sink causes performance drop

[Sylvain Munaut]

Hi,

> I also tried to add a separate path Null Source -> Throttle -> Null Sink (as 
> seen somewhere in the Wiki), but this also didn't help. Changing sample rate 
> of the throttle also doesn't seem to change anything.

Well this obviously wouldn't do anything ...
The throttle block needs to be in the path that processes samples ...

If you have disjoints subgraphs, they all need to be constrained.

Cheers,

Sylvain

Re: Which guarantees, if any, do messages provide?

[Sylvain Munaut]

Hi,

> For example, I use "Message Strobe" to create a message every 10ms. A custom 
> blocks creates a pulse when the message is received (it does so by putting 
> the message into a std::queue in the message handler and retrieving it in the 
> work function).
> When I trigger on one pulse and zoom out, I ideally would see one pulse 
> exactly every 100ms. However, the pulses jump around (i.e., the period always 
> changes).

Yeah, that's why they're called asynchronous messages.


> 1.) What is the typical latency of messages?

Too dependent on too many factors to provide any meaningful answer.
They're not artificially delayed ... so "as fast as possible" is the
only thing I can say.


> 2.) Related, what is typically the maximum speed for sending messages? Is 
> sending messages at >1kHz (i.e., "Message Strobe" with interval <1ms) 
> meaningful?

As fast as you can process them.
I've had bursts decoder use message for decoded bursts and that was
for sure reaching 1k packet per second.

I thought there was a back pressure mechanism to block senders if the
queue was too long, but I can't find it in the code :/  So if there
really isn't any, be careful of your memory footprint could grow
without bounds.


> 3.) Are there any "guarantees" on maximum/minimum delay? (for example, I read 
> that the message handler is guaranteed to be executed when work() is not. Is 
> an upper bound of delay (in samples) given by the worst case execution of the 
> work function, i.e. the size of the output buffer?)

None whatsoever.


> 4.) Can I be sure that all messages are received or does gnuradio silently 
> drop messages under certain conditions?

It won't drop messages.


> 5.) Are messages always received in correct order?

Yes


Cheers,

 Sylvain

Re: Sound card input & output synchronization ?

[Sylvain Munaut]

What audio backend are you using ?

I know Pulse Audio / Alsa  can just drop / duplicate samples. They try
to reduce latency by adjusting some buffer size dynamically but those
adjustments will cause discontinuities.
You can for instance run pulse audio in debug mode and you'll see if /
when it does those and if it matches with what you see.

Cheers,

Sylvain

Re: [USRP-users] disabling ddc duc blocks in rfnoc usrp e310

[Sylvain Munaut]

Hi,

MMm, I thought there was an "all in one" mode where fosphor had built
in optimized windows / fft / re-order blocks to greatly reduce
resource usage, but looking back at the logs it seems this was never
merged into mainline :/

Cheers,

Sylvain

Re: Switching Chat Services: From Slack to Matrix

[Sylvain Munaut]

Couple of questions / suggestions about the current irc bridge :
 - Could the name be shorted: I mean "ungleich-bridge_" is wasted
space at every line ...
 - Could the nick name be highlighted using irc colors, not bright
yellow, but maybe italic or bold just to highlight it. Since it's part
of the message it's not aligned with the native IRC nicks and makes it
hard to read especially since with the server specifier they tend to
be rather long like 

Cheers,

Sylvain

Re: USRP LO stabilization time ?

[Sylvain Munaut]

I played with fast hopping a while ago and it works very well and you
get lock times of less than 1 msec easily.

This is a B210 just quickly switching between  100M (FM), 816M (LTE),
940M (GSM), 1817M (LTE), 2115M (3G), 2450M (Wifi/Bluetooth)

http://i.imgur.com/FwzVgMx.jpg

You can get an idea of the switch time by looking at the duration of
the GSM FCCH signal ( which is ~ 4.6 ms long )

The hardware can only store 8 profiles internally but you can upload /
download profiles via SPI while another profile is running and so my
plan was to use the FPGA to upload next profile and switch to it at
times interval.

The client for that project disappeared and so I never continued to
actually implement it ...

Cheers,

 Sylvain

Re: Multithreading in GR blocks

[Sylvain Munaut]

The m_finished thing only works if you're not using any blocking calls.

But you're using `accept` and `recv` etc ... all calls that can block
forever until they get something.
You need to use `select` on the file descriptors while waiting for
events / data and set a timeout on that select so your code has a
periodic opportunity to check the m_finished flag.

Cheers,

Sylvain

Re: Question on OOT- Modules installation path

[Sylvain Munaut]

> gr-osmosdr (and other modules of the same authors) have historically
> deviated from that (well, or, they were around before anyone even
> thought of having a common style), and want to be installed *into* the
> GNU Radio installation.

gr-osmosdr follows the modtool model AFAIK:
  import osmosdr
  $prefix/include/osmosdr
  ... etc ...

In 3.8 it generates a gnuradio-osmosdrConfig.cmake  but AFAIK that's
what modtool does too ( and it's in lib/cmake/osmosdr/ and not
lib/cmake/gnuradio for instance ).

That was Dimitri's choice when he originally wrote the module and I
tried to stick to it when porting over to 3.8. If I deviated from it,
that was not intentional.

Cheers,

 Sylvain

Re: linking with GNU Radio FFT library

[Sylvain Munaut]

Hi JM,

In CMakeList.txt:
find_package(Gnuradio "3.8" REQUIRED COMPONENTS fft)

In lib/CMakeList.txt :
target_link_libraries(your-oot-name gnuradio::gnuradio-fft)

Cheers,

Sylvain

Re: Failed to XInitThreads()

[Sylvain Munaut]

Hi,

> Yes. Here it is. Regardless of its effects, I am very interested in removing 
> this warning.
>
> https://a.uguu.se/rgc6Iiu3v37w_test.py

Can you edit it and below the "print("Warning: failed to
XInitThreads()")" , add a "raise" so we get to see the actual
exception details that prevent it ?

Also, try to move the "from distutils.version import StrictVersion"
below that code block that tries to run it.
That should should really be the _very_ first thing run since anything
that could remotely touch 'X' before it does will screw with it. (and
python through inter-dependent imports can sometime be surprising ...)

Cheers,

   Sylvain

Re: Failed to XInitThreads()

[Sylvain Munaut]

> Generating: '/home/mgusr/Flowgraphs/Test.py'
>
> Executing: /usr/bin/python3 -u /home/mgusr/Flowgraphs/Test.py
>
> Warning: failed to XInitThreads()

Could you put up the .py file generated somewhere ?

Cheers,

    Sylvain Munaut

Re: Weird behaviour of the analog signal source (was: Re: How ensure consistency with timing signals)

[Sylvain Munaut]

Hi,

> I am by no means an expert on this but just for my understanding I would be 
> curious:
>
> 1.) I still do not understand why for 1 Hz at 5MSps I can get a period that's 
> "500578.5" on average. The frequency error is a whopping 0.1158%! 
> ((5005789.5-500)/500*100). Huge.

That's because you're a rather extreme case. The ratio between your
frequency and the sample rate is pretty large.
The precision of the block would be somewhere around 0.25 ppb of the
_sample_rate_ which is not that bad, but in case of huge oversampling
obviously that can become significant ...
It's just a use case this block was not really designed for.


> 2.) Why is it implemented that way? Why does Simulink, ADS, Cadence Spectre 
> et.al. provide correct and accurate results?

Phase increment is a pretty common way to implement digital
oscillator. The advantage is that it's pretty fast, the state variable
is limited (you just have the phase) and whatever error you have is
constant and time-invariant.


> 3.) What would you do if you would want to create precise timing signals? Is 
> a custom block really the only way? And then, how would you implement it?

Yes, custom block is the only way. And really for _anything_ where you
depend on precision, you _must_ be 100% in control of the arithmetic
and how you deal with precision. And GR never guarantees
implementation so using any default block that does math and the error
might change from one version to the next. So IMHO any "metrology"
type thing must re-implement every math operation and control how they
deal with errors.

For the cases where you have huge oversampling handling it the other
way around would probably make more sense. You just keep "how many
samples per cycle". Then you keep both an integer counter of how many
sample you are in this cycle and a fractional offset and generate the
sin/cos values based on that. This would probably perform worse for
low oversampling signals (like if you generated a 1 MHz sine sampled
at 5 Msps), but for your case, it will be better (actually given
you're an exact divider, it would be perfect with no frequency error
and as little phase noise as permissible with double precision).


> I know that it is impossible to give a solution to this remotely but this is 
> so weird that don't even know where to start looking.
>
> If it were you, how would you approach debugging this?

Look at the code ... at no point did you state which git commit you're
working of so can't help there, but that's the only source of truth.
Randomly adding block is useless. The only thing is points toward is
that depending on how the block gets scheduled (i.e. how many samples
it generates at each call to work()) changes the result, which should
not happen.


Cheers,

 Sylvain

Re: Weird behaviour of the analog signal source (was: Re: How ensure consistency with timing signals)

[Sylvain Munaut]

Hi,

> How can (or better: *should*) a fully digital signal source have phase noise?

Limited precision arithmetic


> Also, for 1Hz at 5MSps I always get either 5005789 or 5005790 samples 
> (instead of 500) ... this is fairly deterministic.

That's because the signal source works with phase increments per step.
So it computes how much the phase changes per sample. The precision
limit of that numbers will then create precision errors.


> Example 1: I pipe the output of the signal source into a file:
>
> https://snipboard.io/xY1JvE.jpg
>
> Now, I would not care too much about a constant phase shift or similar, but 
> it can be seen that the frequency slowly drifts (this is also seen if I just 
> plot them on top of each other).

Frequency doesn't drift.
Frequency is stable but is not exactly 1 Hz which means the phase slowly drifts.


> Example 2: I extend the block diagram with blocks that should never alter the 
> behaviour as they are only reading samples:
> [...]
> However, now the saved data is distorted:
>
> https://snipboard.io/amyn3X.jpg

Yeah, that's weird, not sure where that would come from.
I looked at the code and can't see anything wrong with it, but then
again I might not be looking at the code from the version you're
running.

Cheers,

Sylvain

Re: gr-fosphor on AMD RX 550

[Sylvain Munaut]

Hi Johannes,


> I really hoped I could install AMD OpenCL on top of the open driver.
> How do you do that? I guess, if I install the correct OpenCL + amdgpu 
> version, this should actually work.

Yeah, that's what I did ... I use the AMD binary OpenCL stuff, but I
continued using the amdgpu driver.


> It works and look fine. This is part of the output.

Oh, so that's interesting. That means the issue is somewhere in the
way the OpenGL context is setup by Qt, that's really strange.
Can you try the GLFW version of the fosphor GR block ?


> If I do `./main` without an argument, a window is opened and unresponsive.

Yeah, that's expected, it's reading  sample data from stdin in that mode.


Cheers,

Sylvain


PS: I re-cc'd the mailing list since taking it off seemed like an error ...

Re: gr-fosphor on AMD RX 550

[Sylvain Munaut]

Hi,


> I attached the output of glxinfo and ran glmark2. The output is attached
> in this mail.

So from the GL info it looks like the OpenGL drivers you have are the
one from AMD and not the one from Mesa. I never used those.

Unfortunately, since they don't actually _report_ any error, I don't
have any clue what to do or how to debug that remotely ...
(and I checked the code by putting an error in the shader on my
machine, here I do correctly get the error message printed out, so
it's relly the AMD driver screwing up here)

You can try the standalone 'main' test (you can build by going to the
lib/fosphor subdir of the source tree and type make) and then run it
by giving it a .cfile as argument. This might give some clue (because
it's not tangled in the whole thread mess of Qt and gnuradio) as to
what's going on.


> Currently, I'm stuck with a 5.0 kernel because the system won't boot
> with newer kernels due to some MCS checks.

Is that the issue with Ryzen 7 ?  I know I had to use a kernel from a
PPA for my machine because the one from the official 19.10 wouldn't
boot either.


Cheers,

   Sylvain

Re: gr-fosphor on AMD RX 550

[Sylvain Munaut]

Hi Johannes,

First off the RX550 should work just fine. I have a RX570 and run
fosphor on it with no issues.
I am using Ubuntu 19.10 though which is much newer kernel and newer Mesa.

The OpenCL procedure looks fine and if it gets to that point, that
also worked fine. For some reason the shader fail ... but it's
supposed to print the error message which it's obviously not doing :/

Can you provide the full output of glxinfo and also try some open gl
application / benchmark (like glmark) see if they run fine ?

Cheers,

 Sylvain

Re: clear buffers of stuck chain

[Sylvain Munaut]

My best guess at this point is you're spamming it with as much message
as possible (way too many for the actual radio part to send) and then
at some point the buffers are filled up and it's only accepting new
messages at the rate it's actually sending them.

Cheers,

   Sylvain

Re: Finding GNU Radio 3.8 Compatible Versions Of OOT Modules

[Sylvain Munaut]

Hi,

> Regarding that column, how does it work? I've seen that only gr-fosphor
> and gr-iqbal have that column filled out currently, but I don't know how
> tnt has accomplished that. I don't see anything special in the
> MANIFEST.md nor in the .lwr recipe.

I accomplished that by not being on github ... and so CGRAN doesn't
actually even look at my manifest file and the data for fosphor and
iqbal is literally hard-coded inside of CGRAN's codebase.

Cheers,

   Sylvain

Re: gr-iqbal->gr-osmosdr->gqrx missing pkgconfig files break gr-3.8 builds

[Sylvain Munaut]

> -- Checking for module 'gmp'
> --   Found gmp, version 6.2.0
> -- Could NOT find GMP (missing: GMPXX_LIBRARY GMP_INCLUDE_DIR)

Looks like mageia has split the c++ gmp bindings into libgmpxx-devel
make sure you have that installed.

> We do have these installed in the build chroot:
> BuildRequires:  gmp-devel
> BuildRequires:  gmpxx-devel
> BuildRequires:  mpir-devel
> BuildRequires:  mpirxx-devel
>
> But I don't understand:
> --   Found gmp, version 6.2.0
> -- Could NOT find GMP

Shouldn't that be libgmp-devel & libgmpxx-devel ?

The "Found gmp, version 6.2.0" means he found a pkg-config file.

Then after, using the data from the .pc file it tries to find gmpxx.h
and libgmpxx.so and libgmp.so.  It can find the last one, but not the
two first ( see the "missing GMPXX_LIBRARY GMP_INCLUDE_DIR" ).

Cheers,

Sylvain

Re: gr-iqbal->gr-osmosdr->gqrx missing pkgconfig files break gr-3.8 builds

[Sylvain Munaut]

> 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)

Are you sure you're using the latest gqrx code ?!?

Here I have :
find_package(Gnuradio REQUIRED COMPONENTS analog audio blocks digital
filter fft)

With upper case 'G'.

and my gnuradio 3.8 install has GnuradioConfig.cmake installed.

Cheers,

 Sylvain

Re: Slack alternatives

[Sylvain Munaut]

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: Using other blocks inside OOT

[Sylvain Munaut]

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

Re: gr-iqbal->gr-osmosdr->gqrx missing pkgconfig files break gr-3.8 builds

[Sylvain Munaut]

> 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: gr version hell gets bigger and bigger...

[Sylvain Munaut]

Hi,

> > > I know, this is mainly a matter of the people who maintain such
> > > projects...and I have no idea how the awareness for this could be 
> > > sharpened.
> >
> > Paying the maintainer usually helps.
>
> Sure, in a commercial world things work this way. In a hobbyists world 
> however the projects just die :)

In the real world things work that way.
If nobody cares about those project to either pay someone to update
them or to update them themselves, they die. And that's the way it
should be. If nobody cares about those project, there is no need for
them to build or be up to date ...

Anything relying on < 3.7 is a dead project and has been for a long time.
Anything relying on 3.7 is still in the transition period (I'd say 6
month is reasonable). Either it will be updated if any body cares
enough or it will die. That's just the way life works for software.


Regards,

 Sylvain

Re: gr version hell gets bigger and bigger...

[Sylvain Munaut]

Hi,

> As I am not a coder, no, I can't contribute and update the projects - I am
> only a user. And also I was not yet motivated enough modifying the cmake
> file to fool the procedure, in the hope, it may work somehow if I simply
> extend the accepted version range.
>
> I know, this is mainly a matter of the people who maintain such
> projects...and I have no idea how the awareness for this could be sharpened.

Paying the maintainer usually helps.

Cheers,

 Sylvain

Re: GNU Radio ABI guarantees

[Sylvain Munaut]

> we guarantee API
> compatibility (i.e. recompiling will never fail) for all releases that
> have the same A.B.

Huh really ?

I thought it was more like within the same A.B, if it builds with C0,
it will build for any C1 >= C0.

Cheers,

Sylvain

Re: pybombs install gr-osmosdr ........ bunch of errors

[Sylvain Munaut]

> Why such an old version of gnuradio - 3.7.3? I'm on 3.7.13.5 and I'm
> behind on building updates.

3.7.3 is the Python version, not the Gnuradio version.

Cheers,

 Sylvain

Re: gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8

[Sylvain Munaut]

> We use pkgconfig(gr-iqbal) style BuildRequires in our rpm spec files for
> installation during package builds where we can and are somewhat
> confused as to why you did this.

Because GR 3.8 doesn't use .pc files to determine which path to
include and which libs are needed to build and I don't like have two
independent "source of truth". New modules created by gr-modtool also
don't include pc files.

It uses some new CMake magic which I'm not entirely sure how it works
really but it seems it does. My understanding is it's automatically
generated from the scoping of the target_link_libraries /
target_include_directories (i.e. PUBLIC ones will be passed on to
children) using the whole autogenerated FindGnuradioIqbalance.cmake
thing that cmakes creates and installs automatically.

That should be enough for building or do you get link / include issues ?

> I have only looked at gr-iqbal so far, so if any of the others have had
> the same treatment then ... :)
>
> Oh yes and I could not find any path to a release tarball for
> gr-iqbal-0.38.1.
> If there is a spec. friendly one I would love to know where it is.
> I can normally find them in github or SF but cgit is another story.

There isn't, we disabled it in cgit.  Lots of crawlers wouldn't obey
the robots.txt and kept crawling the link and since that archive is
dynamically generated, it would overload the server with crawlers
trying to download every archive of every branch and every tag for
every projects ...

You either need to make and host your own, or download from the github
mirror ( https://github.com/osmocom/gr-iqbal/releases )

Cheers,

Sylvain

Re: [3.8] Best OOT-Modules?

[Sylvain Munaut]

> Ya I've seen the mainline gr-fosphor has had some 3.8 changes lately, but 
> it's still not integrated with pybombs. We submitted a PR for him and I think 
> he's still working on it.

Huh no ...

http://git.osmocom.org/gr-fosphor/  has the latest code which should
be completely working with Qt5 and GR 3.8.

If it doesn't work in pybombs, then that should be reported to the
pybomb maintainer, I don't maintain pybomb ...

Cheers,

   Sylvain






> From: Nate Temple 
> Sent: Tuesday, December 31, 2019 10:53
> To: Kyle A Logue 
> Cc: Discuss Gnuradio 
> Subject: Re: [3.8] Best OOT-Modules?
>
> Hi Kyle,
>
> Just as a heads up, Sylvain has the mainline branch of gr-fosphor working 
> with Qt5/GR 3.8 here https://github.com/osmocom/gr-fosphor
>
> Instead of on the wiki, one solution we have discussed is to add a column to 
> https://www.cgran.org/ that would show compatibility with GR 3.7 and GR 3.8.
>
> Regards,
> Nate Temple
>
> On Tue, Dec 31, 2019 at 10:43 AM Kyle A Logue  wrote:
>
> Since the pythonclock.org is ticking away the last seconds of python2 today I 
> decided to refresh my 3.8 installation.
>
> After my `pybombs install gnuradio` version of 3.8 I have:
>
> gr-fosphor
>
> https://github.com/the-aerospace-corporation/gr-fosphor
> branch gr38-qt5-aero
>
> gr-pdu-utils
>
> https://github.com/convolutional/gr-pdu_utils
> branch master
> PR is open for sandia labs
>
>  gr-inspector
>
> https://github.com/gnuradio/gr-inspector.git
> branch dev_3.8
>
> Should there be a page on the GNU Radio wiki with 3.8 compatible modules?
>
> Does anyone else have good out-of-tree modules that I should install?
>
> Kyle Logue
> Engineering Manager ⚝ Comm Software Implementation Dept
> The Aerospace Corporation

Re: Docksphor: gr-fosphor inside docker for times of despair

[Sylvain Munaut]

It's using an outdated version of fosphor ...  so much for a fast-paced OS.

Cheers,

   Sylvain

Re: Execute python code when tag detected

[Sylvain Munaut]

Hi,


> Two days ago I have asked about the best way to implement frequency hopping. 
> In absence of advice I am unfortunately still heavily struggling with this.

That's because you're trying to coerce GRC for something it's really
not meant for.

Really anything that's not purely flow based and that has some
"behavior" associated to it pretty much requires at the very least
custom blocks and/or coding a GR application and not simply wiring
stuff in GRC.


Cheers,

   Sylvain

gr-iqbal, gr-fosphor, gr-osmosdr updated to Gnuradio 3.8

[Sylvain Munaut]

Hi,

I have just pushed updates to various osmocom repositories, updating
them to run on gnuradio 3.8.

Here's the status per project :

* gr-iqbal :
   - Old gnuradio 3.7 version been forked into a 'gr3.7' branch and
will remain there. It won't be maintained and will most likely never
receive any further updates.
   - 'master' now contains the gnuradio 3.8 compatible code and the
latest version has also been tagged.

* gr-fopshor :
   - The gnuradio 3.7 version actually got updated a bit with some new
functionality, then moved over to also a 'gr3.7'. Again, I won't
backport future features to it so I don't really expect any further
updates.
   - Because I know some distribution still maintain a gnuradio 3.7
package but removed Qt4 (and so ported gnuradio to Qt5), I also
created a 'gr3.7-qt5' branch that's designed to work with gnuradio 3.7
but using Qt5 instead of Qt4.
   - Finally, 'master' contains the gnuradio 3.8 compatible code. ATM
there is no functional (as in 'fosphor features') differences with the
two others, it's just Qt5 support and Makefile changes.
   - A couple of the interesting new features that have been added :
 . Fixes the long standing bug of NVidia CL/GL sharing not working
(thanks Aaron Giles for figuring out root cause)
 . Memory leak fix (thanks Emil Berg for reporting)
 . Improved CL device compatibility check before trying to use
them (thanks to Ethan Trewhitt)
 . Allow explicit selection of the CL device via FOSPHOR_CL_DEV
env var if you have several CL platform/devices.

* gr-osmosdr :
- 'master' is still 3.7 version, same code as before but has been
tagged and a 'gr3.7' branch has been created in anticipation that
master will become 3.8
- An experimental 'gr3.8' branch has been added that contains an
upgrade to Gnuradio 3.8 (based off the work from Mickey Vänskä and
Maitland Bottoms).
  . I tested it with UHD / Blade RF / Hack RF which are all the
devices I have available.
  . It also adds support for the Airspy HF courtesy of Alexandru Csete
  . Still feel free to use it as base for packaging and report any
additional patch you have to apply for the build.
  . Once I have enough success report, this will land in master.
  . Currently the utilities in apps _have_not_ been ported to 3.8
(especially GUI changed to Qt5) ... if anyone wants to do that and
send me a diff, that would be _very_ welcome and I'll include that in
this branch.


Cheers,

 Sylvain Munaut

PS: bcc'd package maintainer I thought of.

Re: How to efficiently implement dechannelization (combine multiple narrowband signals into a single broadband spectrum)

[Sylvain Munaut]

Hi,

> I'm working on an SDR project where I need to transmit a narrow
> baseband signal on multiple different carriers simultaneously, over a
> relatively wide bandwidth (1Mhz).

Is this the same baseband signals copied at several place ?

What you can do is :

 * First modulate the signal to a narrow sample-rate (just enough for
the modulation)

 * Upsample that signal to 1 Msps.
   - Depending on the ration between the narrow rate and wide rate, it might be
 beneficial to do that in several steps.
   - So for instance you would go from 10 kHz to 100 kHz first with a
filter that's relatively sharp
   - Then you would go from 100 kHz to 1 MHz with a second filter than
can be much more relaxed (i.e. larger transition bandwidth and so much
less CPU usage)

 * Then use several rotators to position it at the various places you
need it in the 1MHz bandwidth

 * And finally add the output of all the rotators.


There is also the so called Polyphase Filter Banks, but that only
works if you need carriers that are all equally spaced. And is also
only a benefic if you really fill a significant number of them.

Cheers,

 Sylvain

Re: [Discuss-gnuradio] Request for Wiki update.

[Sylvain Munaut]

> I know I'm going to ruffle some feathers, but my intentions are noble,
> so here it is: GNUradio is by far the worst project I've seen in my 20
> years are a Linux user when it comes to documentation.

You've used linux for 20 years and it took you half a day to figure
out you need to call ldconfig ...

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

[Sylvain Munaut]

Hi,

> I'm very certain that flatbuffers does handle this correctly, yes.
> Haven't tried it, though. But "serialization library that doesn't deal
> with cross-platform" sounds bad, doesn't it?

You would think so yes, but it's not like it's un-heard of, especially
if the primary goal was performance and games where "All our relevant
targets are little endian" is probably a valid trade-off.

But in any case, after digging in a little, they explicitly state that
the on-the-wire representation is little endian for performance of the
most common CPU today, but it works on big endian at the cost of the
accessor needing to do the byte swapping.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [RFC] PMT succession: experts' opinions on serialization libs

[Sylvain Munaut]

Hi,

>> Tbh, I'd just assume that in all these formats, being tight-packing by
>> default, std::complex can just be represented by the equivalent
>> of struct {float re; float im;} complex;.

I haven't delved into the code, but do you know if it handles properly
architecture differences between sender and receiver ?
Things like 32b long vs 64b long and little endian vs big endian ?

Because the message end up send across network, this matters, there
historically has been at least one instance of a bug because PMT was
not resilient to that when exchanging data between a x86_64 PC and an
E310 for instance.

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Distance Measurement by Correlation

[Sylvain Munaut]

> Any ideas about how we can troubleshoot this more effectively? Or better 
> model the channel?

Make sure both your radios are locked to the same clock source.
Any fsignificant requency offset between the two is going to ruin your
correlation peaks very quickly.

Frequency offset is going to end up as a progressive phase shift along
your PN sequence. If that phase shift is a non-negligibe part of the
unit circle during the time of your PN sequence, they won't 'add up'
to a peak anymore.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Looking for other users of the XTRX SDR

[Sylvain Munaut]

I think there aren't many users yet ...

I have a pcie one I have been using  (but not with GR, just natively).
I'm still waiting for the usb3 one.

And more relevant is that the gr-osmosdr author is also still waiting
for his I think :p (and is unavailable atm anyway ...)

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OsmoGMR

[Sylvain Munaut]

Use the 'sylvain/live' branch and in there there is a utils directory
with modern python script that work with gnuradio 3.7

Cheers,

  Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT blocks not imported when using extern variables in C++

[Sylvain Munaut]

> Then, it let's say you have this system uhd_source -> block1 -> block2 -> 
> block3 -> uhd_sink,
> how would you trigger different actions on block1 based on the result of one 
> function of block3?

https://www.gnuradio.org/doc/doxygen/page_msg_passing.html

 Cheers,

 Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT blocks not imported when using extern variables in C++

[Sylvain Munaut]

> How/where should I declare the global variables that can be read and modified 
> from the general blocks?

You shouldn't.

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Sylvain Munaut]

> Why do we have a normalized error instead of a absolute error threshold
> at all?

Welll because this is float ... only relative errors matter.

If you have a signal between -1e6 and 1e6  , then an error or 0.1 is
really not all that important.  OTOH if your signal is -1 .. +1, then
an error or 0.1 is kind of important.
Basically like EVM, it only make sense as a ratio.

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] no uhd/osmocom blocks with 3.8?

[Sylvain Munaut]

Yes, 3.8 is not exactly all that usable at the moment.

UHD block are not properly/entirely built and won't work in GRC.
Osmocom source simply hasn't been ported to 3.8 yet AFAIK.

We're in the 3.8 early days (no 3.8 release yet AFAIK) and now that
it's in master, people need to test, report issues, submit patches,
port their OOT to 3.8, 

Cheers,

 Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Sylvain Munaut]

I'm starting to wonder if having different precision version of the
kernels wouldn't make sense ...

TBH most of the time I don't care that much about precision because my
input data is noisy and  the 0.1 dB difference doesn't matter, I much
prefer to be _fast_.
Especially for something like log2 that would be used to plot an FFT
for instance. My display windows is only 1000 px high, so as long as
the error is < 1e-3 in the end, I wouldn't even see the difference.

And I recognize that for some other applications, it might matter, but
I always found that when dealing with real time, real world signals, I
often prefer fast over precise. (within reason obviously).

Cheers,

 Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Non-deterministic behavior in GNU Radio

[Sylvain Munaut]

Hi,

> Unfortunately, there were no further replies to that thread but I did see 
> that my same question "pops up every once in a while". Anyway, my specific 
> problem is I'm trying to QPSK demodulate + RS decode a 2MS/s, 1Mbps bit rate, 
> 10GB IQ file. This works fine, but I'm getting a different number of 
> successfully decoded packets every run. I am using a throttle block, and in 
> fact tried to reduce the throttling rate to 200KHz (samplingrate/10), but it 
> still doesn't seem to work. As for how much CPU my flowgraph is utilizing, it 
> takes up around 80% of all 8 of my CPU cores at the regular sampling rate, 
> while taking around 30% of my cores at samplingrate/10. Do you guys have any 
> idea on what might be going on? The thread I'm referencing is from 2013, but 
> is it still relevant? Any technical reasons for the non-deterministic 
> behavior? I'm using 3.7.13.2.

Depends on your flow graph obviously, but in general, no.

Unless for the obviously "random" blocks (like noise generators and
such), AFAIK most other blocks should have a deterministic behavior
(at least when running on the same exact GR version). Usually
undeterministic behavior points to a bug in one of the blocks that
doesn't properly deal with the boundaries in the work() call.

cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UDP sink that respects PDU? SOCK_SEQPACKET?

[Sylvain Munaut]

Hi,

> IIRC, the SOCK_SEQPACKET packet type paradigm never had a IP-based
> protocol that could be used across commodity networks (unlike
> SOCK_DGRAM, which pretty much defaults to UDP and SOCK_STREAM, which
> pretty much defaults to TCP).

Err ... what about SCTP ?

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] LDPC in GNURadio

[Sylvain Munaut]

Hi all,


I've spent the last day trying to understand the state of LDPC
encoding / decoding in GNURadio, to see how it could be improved. I
limit myself here to gr-fec and not the application specific ldpc that
can be found in gr-dtv for instance.
Here's what I think is the current state (please, anyone that knows
better, feel free to comment):

There are two distinct implementations that have nothing to do with each other :

* ldpc_encoder_impl.cc / ldpc_decoder.cc : This implementation uses
self written matrix / vector operations that can be found in
gf2{mat,vec}.cc in the gr-fec/lib directory. The decoder
implementation is a belief propagation system AFAICT.
* ldpc_gen_mtrx_encoder_impl.cc / ldpc_par_mtrx_encoder_impl.cc /
ldpc_bit_flip_decoder_impl.cc : This implementation uses GSL for its
matrix operations and the deocder is a bit flipping decoder.

I did some very quick benchmark encoding a bunch of data. Absolute
number are meaning less, they only make sense relative to each other :

 * GSL encoder : ~ 50 s
 * GF2Mat encoder : ~ 10 s
 * GSL decoder : ~ 15 s
 * GF2Mat decoder : ~ 10 s

Keep in mind the decoder were operating on perfect input data so it's
pretty much only checking the syndrome ...

Now when looking at the actual code, both these implementation are, to
say the least, sub-optimal from a performance point of view.

I also did some quick test, trying to compare the speed of using an
optimized matrix library operating on GF(2)  (M4RI
https://bitbucket.org/malb/m4ri )  rather than the naive
re-implementation found in GNURadio.
This shows an improvement up to 10x faster when encoding a codeword
(although I can't be sure how much is due to using an optimized
library vs just doing things better in general).

My first idea was to just replace both GSL and the custom GF2{Mat,Vec}
operations by calls to M4RI. I was hoping to remove the dependency to
GSL and replacing it by M4RI. However turns out GSL is used by
gr-filter and gr-wavelet as well, so this would effectively add a new
dependency to GNURadio.

However after reading the code, I don't think this would be enough.

(1) There is no reason to have 3 different encoder blocks ...
especially since 2 of them take the same input (parity check matrix).
The third one takes the generator matrix as input, but even then, it
doesn't make sense to have a separate block with different work
function and a re-implementation of the encoding and converting the
input matrices to the matrix needed for encoding at every iteration.
(2) Using GSL is just a bad idea. Either go with M4RI, or a naive
in-tree implementation, but using a library operating on 'double' to
do binary math and then applying a mod 2 operation on every cell is
just ... weird. To be honest I'm not sure what's the best option here.
I really don't fancy re-implenting some of the matrix operations
needed to convert from parity check to generator matrices for
instance. M4RI is not optimized for sparse matrices, but it is (1)
_way_ better than GSL. (2) better, both time and memory wise than any
in-tree implementation we can make. Cost is an added dependency.
(3) Having two decoders can make sense given they operate using
different algorithm. But they should still "look similar" rather than
being clearly completely different implementation that don't even take
the same parameters to specify the LDPC code.


So my questions would be :

(1) Is cleaning up the mess worth it ?
(2) Is completely breaking the API of those blocks acceptable ?
(There is no way I'm going to bother trying to maintain API
compatibility with the previous blocks)
(3) Is adding a dependency to M4RI library to gnuradio acceptable ?
(possibly optional one, disabling LDPC if not present).

I don't want to loose my time and make work that cannot be merged, so
if the answer to any of the above is "no", then I'll just move along.
It might see "harsh", but to be honest, I can't imagine that there are
any users of the code given the state it is in ATM ...


Cheers,

 Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Template Error

[Sylvain Munaut]

Hi all,


It's due to commit b5396df5547a5c29218a18a469454f5db03e6ab5 in GNURadio.

Now my question to the author / commiter of this : How is one supposed
to write a OOT that works with both 3.7.12 and previous versions ?!?


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to use IQ Bal Optimize/Fix?

[Sylvain Munaut]

Hi,

* You can just use 0.0 / 0.0 as the default. Those value are only
really used if you don't use the message system and just want a fixed
/ known manually set correction. Once the first message is received,
those value are overwritten

* As stated the time constant is in samples.

* The 'optimize' block only really works when you have some narrow
band signals distributed around the spectrums. It will fail
_miserably_ if you have a single wideband signal centered around DC
...

Cheers,

 Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFT size constraints?

[Sylvain Munaut]

> By convention, FFT sizes seem to be powers of 2.  And Gnu Radio Companion
> throws an error if you try to set a size of 16384 -- but will accept 16383.

Probably related to the size of the buffers or something like that.


> Is using a non-power-of-2 FFT simply less efficient, or are there other
> concerns?

Power of 2 FFTs are faster (potentially _much_ faster), but you can do
FFT of any sizes.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] build from source fails - Kubuntu 16.04 / master

[Sylvain Munaut]

> Any ideas would be highly welcome :)

Most likely you have an old uhd or uhd devel headers installed somewhere.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Sylvain Munaut]

On Wed, Aug 16, 2017 at 5:11 PM,   wrote:
> What type of hardware? I thought from hardware point of view only precise 
> clock is required and all the other things in
> firmware. I've naively thought i could modify hackrf firmware to get this 
> feature.

Mostly a FPGA and a PPS input from a GPS receiver.

Each individual sample has a timestamp of when it has been received.
And you can also reset the timestamp on the next  PPS edge.

Technically it would be possible to modify the hackrf firmware and
repurpose some GPIOs and have all samples transmitted to the host be
in timestamped packets and implements timestamping in the on-board
ARM.
For additional hardware you'd only need an external GPS receiver (or
some other way to have both a single freq reference + single sync
pulse).

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Time syncing between SDRs on different computers

[Sylvain Munaut]

The USRP have dedicated hardware to support that kind of stuff, the
rtl-sdr and hackrf do not.
That's the kind of advanced features that are cut to reduce the price ...

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT Block with output size of not power of 2

[Sylvain Munaut]

> How can I set output buffer size of my OOT block for example 346 and
> gnuradio don't change it automatically to 512?

You can't.

Buffer size in bytes must be an integer number of memory pages (4096
bytes) because of the way the circular buffer system is implement
using MMU and multiple memory map of the same physical memory and that
only works for full pages.


Cheers,

  Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Tagged Stream Blocks with HackRF

[Sylvain Munaut]

The hackrf driver has no support for burst transmissions.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: What value is in in[noutput_items+1]?

[Sylvain Munaut]

First, set_history(2) means there will be 1 old sample, not two. (yeah
go figure ... but the default value is '1' and means "no history").

So, if noutput_items = 8192

in[0] = history[0]
in[1] = new_sample[0]
...
in[8192] = new_sample[8191]


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

[Sylvain Munaut]

> If we see from the user perspective, why would someone need two displays ?

You're assuming it would be the same people ... or at the same time.

* I could use QT locally but still expose a web UI for people to
remotely see what I'm describing. The local Qt UI could be more
complete and just have a basic read-only version exposed to others.
* I could use Qt locally with advanced visualization (fosphor for
instance) but still want a basic spectrum available on my phone so I
can go outside, tweak the antenna and see improvements live then come
back to my local station.

That's just off the top of my mind.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [GSOC] A HTML-based GUI for GNU Radio: Draft of proposal

[Sylvain Munaut]

Hi,


One thing that I find a bit weird in the proposal is to use a new "generate
option" webui.

For the qt/wx/... that makes more sense because :

 (1) they're exclusive, you can't be both WX and QT, trying to link
multiple graphics framework in the same app is just not practical
(possible).
 (2) because of some fundamental ways the app is going to be run when links
to a local gui toolkit, it's hard to do otherwise.

However, I don't see why having both a local QT GUI _and_ exposing a Web UI
would have to be exclusive.

The "global" options for a Web UI could be in a block without port (much
like there is a xmlrpc server block, or also the Device3 block in RFNoC).
That block instance would take care of setting up all the global stuff that
can be used by the actual UI blocks sending data to clients.


Just my 2ct.


Cheers,

Sylvain
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] bins osmocom_spectrum_sense

[Sylvain Munaut]

> Does anyone know why the first and last 25% of FFT bins are discarded? I am
> talking about the following lines of code:
>
> line 267: bin_start = int(tb.fft_size * ((1 - 0.75) / 2))
> line 277: bin_stop = int(tb.fft_size - bin_start)

Read that code again ... it discards the first and last 12.5% ... so
that it discards 25% in total.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GNUradio not working with SDRplay in Windows10

[Sylvain Munaut]

Hi,

> That is not good news. I'm not a software developper and 'API' and 'DLL'
> sound like  'magic' words to me.
> So as long as there's not a proper library for SDRPlay,  gnuradio will not
> work with this device.

Feel free to write to the hardware vendor and request open-source API
library / documentation so that this device can be supported in a
fully FOSS driver and distributed pre-built.

It's only if actual customers write and insist that this is important
to them that hardware vendors might do it ...


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Continuously Write FFT Samples to a File

[Sylvain Munaut]

>> > I have a flowgraph that reads a signal and writes its FFT samples to a
>> > file. I need to run this continuously (for a long time), without running
>> > out of memory.

What I'm understanding: You write FFT results into a file so you can
always read at the end of it to get the "latest" one by reading at the
end of it ...
My advice: Don't do that ! Using files is really dumb for this
usecase. Depending on what's reading you can either use a FIFO or even
better write to a ZMQ pub sink and modify your reader to use a ZMQ
sub.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] set_max_output_buffer_size

[Sylvain Munaut]

> I tested it a little and it appears to work just fine.  Perhaps runtime
> experts want to comment?  For performance reasons, we may want to warn the
> user if the buffer is very small.  Anyone see other issues?

I'm pretty sure the whole "dual mapped pages" circular buffer thing
only works for buffer that are multiple of the page size ...


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Request for volunteers: FOSDEM Videos (even if you're not going to FOSDEM!)

[Sylvain Munaut]

Hi,

>
> Jan Krämer (cc'd) is in charge of our A/V setup, so if you're
> interested, please let him know.

I can help cut the video. And I can help looking after the feeds on the day.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Sylvain Munaut]

On Tue, Nov 22, 2016 at 9:30 PM, Garver, Paul W  wrote:
> If it is a link order problem, why isn’t this problem a more common
> occurrence for other modules? It appears the dynamic libs generated by the
> various gnuradio components do have cyclic dependencies. For example ldd on
> the following libraries yields:
>
> libgnuradio-runtime: pmt
> libgnuradio-digital: analog,filter,fft,blocks,runtime,pmt
> libgnuradio-treliis: digital,analog,filter,fft,blocks,runtime,pmt

There is nothing cyclic here ...

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Questions regarding hierarchical polyphase channelizer

[Sylvain Munaut]

Hi,


> For example for 13e6 GSM band I can extract all channels by setting
> Channels parameter of the channelizer to 65 (13e6/0.2e6).
> Then I can get output signal that is sampled with 4*gsm_symbol_rate by
> setting oversampling to 65/12.
>
> It would be great to have something like this in your block because it
> is more efficient than the regular one. I can look into this if I will
> find some time.

Unfortunately that's not so simple.

If you want to have channel width that's wider that the channel
spacing, that means that in the hierarchy, your first layer will need
to have oversampling as well. (else the channels at the 'border'
between two first layer band would be cut).

So that means the input of the second layer will be oversampled,
meaning that at the output of the second layer, some channels will be
useless (because they'll correspond to the 'sideband' of the
oversampled first layer output) and you'll need to drop them. Also
means your second layer will run at a higher rate, using more CPU. So
your computational overhead becomes much higher and the benefits of
the hierarchical version decreases.


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Sylvain Munaut]

> ImportError: /usr/local/lib/libgnuradio-pwg-1.0.0git.so.0.0.0: undefined
> symbol:
> _ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_
>


If you check with objdump, is that symbol indeed in that lib ?


objdump -t /usr/local/lib/libgnuradio-trellis-3.7.11git.so.0.0.0  |
grep 
_ZN2gr7trellis26viterbi_algorithm_combinedIfhEEviiiRKSt6vectorIiSaIiEES6_RKS2_IS4_SaIS4_EESA_RKS2_IT_SaISB_EENS_7digital21trellis_metric_type_tEPKSB_PT0_


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Sylvain Munaut]

Little tip in general:

in the python/  directory, look at the __init__.py file and remove the
try / except around the "from xxx_swig import *".

This will then actually _print_ the error preventing the SWIG import ...

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] out-of-tree module without root privileges

[Sylvain Munaut]

Hi,


>> Once you authorize someone to use sudo, he _is_root for all intents
>> and purposes, you realize that right ?
>
> In general that's not true, you can just allow some specific
> commands via sudo.

True, but "allow specific commands" is _really_ hard if you don't
understand _everything_ about those commands and what they can do.


> Assuming the install operation requires a fixed set of commands,
> you could
> - make a script 'install_oot' doing exactly what is required,

Unless you want to target _one_ specific OOT, that's going to be hard
... unless you authorize the 'install' binary used in the 'make
install' step, but at that point you've essentially allowed root
access since the user can now replace arbitrary file on the system
with arbitrary permission, giving them root. And some OOT install
things like udev rules ... which are run as root, at which point
you've again given root to all users. The ways to get this wrong are
nearly endless here ...

Even if you somehow managed to avoid all those traps, the users would
still be able to install executable code in shared / system wide
directories of GR. At this point other users could me made to execute
arbitrary code by just running any GR app and if the admin normal user
is one of those users actually using GR, you've again given root ...
(or at the very least, given each user the ability to do anything as
any other user).


All in all, it's a terrible idea and it's better to have users be able
to install OOT in a private dir and instruct GR to go look there.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] out-of-tree module without root privileges

[Sylvain Munaut]

Hi,

>> I am having a problem with out of tree modules in gnuradio. I have a pc
>> on which multiple users can log on to it. I have installed gnuradio on
>> the administration account and all users can use it. The users who are
>> using the machine can't install out of tree modules in gnuradio because
>> they don't have root privileges.
>
> Presuming it's a Linux system, yes, they can use
>
>   sudo make install

That's not so much a way to use OOT without root privileges but a way
to give someone root privileges.

Once you authorize someone to use sudo, he _is_root for all intents
and purposes, you realize that right ?


As for the original question, you can try to play with environment
variables. Won't always work though.

BASE=/home/whoever/gnuradio-prefix
export PATH=${PATH}:${BASE}/bin
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${BASE}/lib64
export PKG_CONFIG_PATH=${PKG_CONFIG_PATH}:${BASE}/lib64/pkgconfig
export PYTHONPATH=${PYTHONPATH}:${BASE}/lib64/python2.7/site-packages/
export GRC_BLOCKS_PATH=${GRC_BLOCKS_PATH}:${BASE}/share/gnuradio/grc/blocks


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Question about GNURADIO File sink

[Sylvain Munaut]

Hi,

> You could write a python block that takes input which is a vector
> of 100*1024*1024B/(8B/sample) = 13107200 complex numbers, and directly
> writes each input to an own file using numpy. You can convert a stream
> of (single) samples to a stream of vectors of that size using a
> stream_to_vector block.

I would _highly_ advise against that ...

That would use an insane amount of memory since each buffer will try
to store several of those vectors ...

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] simple mod-demod combinations doesn't work

[Sylvain Munaut]

> If i start an audio flow graph without [throttle] and increase some additive
> noise or change the volume with a multiplier in the stream the audible
> signal gets effected way too slow (action-to-effect-time approximately 10 s
> or more). If I use a [throttle] after the [wav file source] i can effect the
> stream directly - maybe i can call it "in real time", but then sometimes aU
> occurs.
>
> The issue remains also if i use real hardware (redpitaya with osmocom
> blocks) an resampler blocks in the stream.

That's because of buffering. Each block has a buffer after it and if
your "hardware" is at the end of the chain, then all the elements
before it are free to generate data in advance until they fill all
those buffers (the more blocks the more buffers). And so any change to
those source will only be applied after all the pre-generated data
that's sitting in the buffers has been flushed.

The default size of those buffer might not be appropriate for low rate
audio because they can easily represent seconds ...

> So is the solution for such problems a tagged stream with control through
> tags or the usage of PDUs?

No.
The easiest solution is to manually control the max size of the
buffers for the "low rate" blocks in your chains to prevent too much
buffering there.


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] WXGui behaving badly on some systems

[Sylvain Munaut]

>
> Thanks for this, but, I can't get the patch to apply.  I'm on:
>
> ce354379fee28872ea103eafa9164e6fc1ea54a1

That file hasn't changed in years ... just try to edit the file by
hand and apply the mods by hand. email probably screwed the patch
format.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] simple mod-demod combinations doesn't work

[Sylvain Munaut]

Hi,

> Maybe I am wrong, but i expect an
> lossless connection in GRC if I directly connect an modulator to its
> appropriate demodulator - particularly when i use the default values.

Yes you are wrong.

Demodulation is not an exact process and the various loops in there
will take some time to lock and so the beginning will be corrupted and
your output won't be synced on the bytes boundaries of your input.

Before modulation you need some kind of pre-processing to add
synchronization patterns and stuff like that and eventually some
padding data both at the beginning and the end to let the loop lock
and let stuff flush at the end if you want the full data to be
recovered, then you need to detect, align and remove all of that at
the output.

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Polyphase Clock Sync for Bursts

[Sylvain Munaut]

> Does anyone have insight into how to do burst timing recovery
> with PF clock sync block? I’ll also note it appears that the M clock sync
> block experiences a similar problem.

Both blocks are meant for continuous signal and will take a "while" to lock.

Usually for bursts, you have a sync sequence to correlate to to get an
initial valid alignement.

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] WXGui behaving badly on some systems

[Sylvain Munaut]

Hi Marcus,

> GL.glCallList(self._grid_compiled_list_id)
>   File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in
> glCheckError
> baseOperation = baseOperation,
> OpenGL.error.GLError: GLError(
> err = 1285,
> description = 'out of memory',
> baseOperation = glCallList,
> cArguments = (3L,)
>
>
> They have an older system, with 2G of memory, but with 12G of swap.

RAM doesn't matter.

This is merely a reflection of buggy OpenGL drivers.
Display Lists are an outdated OpenGL feature that's most likely never
ever tested in any modern driver and so my guess is that they leak
resources when regenerating it and at somepoint they run out of
something ...

Try the patch below. It effectively disables the use of display list
and just issues all the commands every draw ... which for any kind of
modern GPU should really not be a problem.


diff --git a/gr-wxgui/python/wxgui/plotter/plotter_base.py
b/gr-wxgui/python/wxgui/plotter/plotter_base.py
index ca90490..c4dbd26 100644
--- a/gr-wxgui/python/wxgui/plotter/plotter_base.py
+++ b/gr-wxgui/python/wxgui/plotter/plotter_base.py
@@ -49,20 +49,14 @@ class gl_cache(object):
To be called when gl initializes.
Create a new compiled list.
"""
-   self._grid_compiled_list_id = GL.glGenLists(1)
+   pass

def draw(self):
"""
Draw the gl stuff using a compiled list.
If changed, reload the compiled list.
"""
-   if self.changed():
-   GL.glNewList(self._grid_compiled_list_id, GL.GL_COMPILE)
-   self._draw()
-   GL.glEndList()
-   self.changed(False)
-   #draw the grid
-   GL.glCallList(self._grid_compiled_list_id)
+   self._draw()

def changed(self, state=None):
"""


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Poly phase channelizing in Blade Or USRP

[Sylvain Munaut]

Hi,


> It seems like a perfect fit for a poly phase filter - however this is
> something that I believe needs to be done in hardware (128 channels *
> 200khz = about 60mhz sample rate this will not go over a USB cable, and
> I doubt I can get this bandwidth into a laptop PC.

!?!?

128 channels of 200 kHz = 25.6 MHz of bandwidth. You can totally get
that to a laptop.
B2xx or BladeRF will do that without issues given a sufficiently good laptop.
Even a hackRF with USB2 only can nearly do it ( 20 MHz ).

If the transmission are "infrequent" you can even use the same trick
that researchers used a while back to listen to all of bluetooth and
deliberately alias the signal to fold the spectrum over itself.


> Am I going to have to do FPGA work on my own?

Very likely.


> Or - is there some existing cook book solution with the FPGA
> configuration pre-cooked?

Very unlikely to find something "all done".
Especially that if you don't want to ship the samples, a PFB is not
all you need. You'd need demod for each channel in the hardware as
well.


> What I am looking for is the FPGA channelizer solution... hopefully an
> existing one I could start with?

There is an embryon of one in the ettus rfnoc repo and AFAIK they
might also replace it with another version soon.

But it's written for RFNoC and Series-7 Xilinx fpga. It'll need quite
some adaptation to run on anything else.
Also, AFAIU, it's incomplete and non-tested currently so ... YMMV.


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Errors using PyBombs recipe for RFNoC setup

[Sylvain Munaut]

Hi,


> That last error completely errors out and I don't have GNU Radio installed.
> How do I resolve this?

Did you even bother to _read_ the error ?


> E: Unable to fetch some archives, maybe run apt-get update or try with
> --fix-missing?

Did you do that ?


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Upgrading Gnuradio/GRC

[Sylvain Munaut]

Hi,

> what's the quickest way to remove an older Gnuradio build prior to
> installing a later version?

If it's a package, then purge the package and also make sure you purge
related packages that were installed as dependencies. (for instance,
it's quite common to see people that remove the 'gnuradio' package but
leave the 'volk' package installed and that can ruin your day ...)

If it was built from source and you still have the exact build repo
you used for the make install, then make unsintall should work. If you
don't have it anymore, you're stuck with manually looking for files
...

The best option IMHO is to never install gnuradio in /usr or
/usr/local and _always_ install in a separate prefix ( like
/opt/gnuradio or ~/gnuradio or something ), which pybombs can do
pretty easily but it's also not hard to do by hand.
This way you can just nuke the entire prefix, or even maintain several
prefix in parallel to have several version (like keep a stable version
and a bleeding edge version)

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ZMQ REQ / REP naming Swap?

[Sylvain Munaut]

> But this model doesn't work for the REP / REQ in Figure 2
> "Request-Reply". I would expect the ZMQ REQ to be a GR sink but instead
> if is a source; likewise, I'd expect the ZMQ REP to be a GR source & it
> is instead a sink.
>
> The internal coding is consistent with the external naming; I just
> question whether the naming was swapped. Am I missing something? - MLD

Basically it's coded so that you REQuest some samples from a server.

So the REQ is the source (it sends a request for data and gets back
some samples that are fed to GR).
And REP obviously then has to be a sink since it waits for a REQuest
and when it gets one, sends some data out of GR in the REPlies.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Hierarchial block as an input source

[Sylvain Munaut]

> I’m trying to find a way to create a *COMMON* - decoder that will work with a 
> number of front ends
> It seems I have to do “surgery” on my flow graph every time… Yuck.

That's exactly what the gr-osmosdr block does ...

Of course that assumes that all your frontend actually support what
you ask of them. If you ask for 10M sample rate and you plug-in a
rtl-sdr that just won't do ...

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] About closing flowgraph automatically

[Sylvain Munaut]

Hi,

>  52 int pdu_to_tagged_stream_impl::calculate_output_stream_length(const 
> gr_vector_int &)
>  53 {
>  54   if (d_curr_len == 0) {
>  55   /* FIXME: This blocking call is far from ideal but is the best 
> we
>  56*can do at the moment
>  57*/
>  58 pmt::pmt_t msg(delete_head_blocking(PDU_PORT_ID, 100));
>  59 if (msg.get() == NULL) {
>  60   return 0;
>  61 }

[snip]

> Problem is that if we use the non-blocking call here, the scheduler would 
> have a chance to process the shutdown signal, but it would be constantly 
> asking (spinning) for the output stream length.
>
> You could try out what would happen if we'd added a timeout to the blocking 
> cal; that way, you could reduce the spinning, and hopefully get the scheduler 
> to check for "done" messages.

There _is_ a timeout ... that "100" in there is the # of millisec to
wait at most.


Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Scheduler enhancement?

[Sylvain Munaut]

> Something that would make this easier--in that it would establish a
> starting-point for cross correlation, and thus reduce the window size
>   over which one needs to estimate, would be if the scheduler could insert a
> time tag of some sort the FIRST time it calls a work function
>   either initially or after a start() stop() start() sequence.  This would
> be crude, since it would be based on an OS-based timer, so it could
>   only act as a starting point.

I don't see why this has to be done by the scheduler, I'd do that in
the source, or even as a separate OOT that just inserts that tag.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Sylvain Munaut]

> If GLFW is disabled it will still successfully install but you wont have
> OpenGL support.

Well that's just not true ...

GLFW is one of 3 ways fosphor can get a GL context. But it can get a
context from Qt or from WX as alternatives.

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Sylvain Munaut]

On Sat, Jul 9, 2016 at 8:26 AM, cam Gmail  wrote:
> I think even when you get opencl working you will run into issues with 16.04 
> not supporting freetype 2

That's been fixed.

freetype keeps changing the location of their headers and the CMake
module in fosphor didn't support their latest version used in 16.04
but it has been updated now.
So as long as you have the freetype2-dev package installed it should
find it just fine by itself.


Cheers,

  Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Sylvain Munaut]

Hi,

> It looks like libfreetype6-dev,  ocl-icd-opencl-dev, and libqt4-opengl-dev 
> are already installed.  I can't find libghc-glfw-dev in my package manager.
>
> Pybombs says the install of gr-fosphor was successful however I can't find an 
> executable on my system.  Where would it be located.  It does not seem to be 
> anywhere in my pybombs prefix directory or anywhere else on the system that I 
> can find.   I see the gr-fosphor folder in my src directory but I don't see 
> any executables.

fosphor itself is just a GNURadio block, it doesn't have any executables.

If you have gr-osmosdr installed, there is an osmocom_fft utility that
implements a basic spectrum browser and it has a -F option that will
use fosphor for the display

Cheers,

   Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installation of gr-fosphor via PyBombs

[Sylvain Munaut]

Hi,

> Your suggestion helped.  I got past the x11 error.
> Now it fails with this line:
> -- Could NOT find OpenCL (missing: OpenCL_LIBRARY OpenCL_INCLUDE_DIR)
> I don't see either one of those entries explicitly in the Ubuntu package
> manager so I'm not sure what I should load next.

Try installing ocl-icd-opencl-dev package


Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] License for libs linked in OOT

[Sylvain Munaut]

> I think the GNURadio OOT block glue has to be GPLv3 in any case and that is
> fine.

Why ?

As long as the license is GPLv3 compatible you can publish it under
what you like.
Now of course when re-distributed as binary/complete system, the
effective license will be GPLv3 because the gplv3 compatibility often
uses the "sub-licence" clause to be compatible ...

But if someone wants to extract parts of your code he can do that and
use it as whatever license you used. Same thing if they somehow
re-implement an API compatble runtime that doesn't rely on gpl code
for instance.

And that obviously applies to whatever lib you use as well. (Actually
if that lib is "standalone" and not tied to GR in anyway, it's
probably not considered a "derivative work" and so it can be any
license you like, doesn't even need to be GPL compatible, but that may
prevent binary distributions though depending on details)

(Of course IANAL ... but I'm pretty sure of what I'm saying at least in the EU).

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] SWIG Errors

[Sylvain Munaut]

See the thread :

"The AttributeError problem now that I have modified a working OOT"

My guess is that you encountered something similar.

So the SWIG process went fine and without any error, but if the .so
that was generated from your C++ code can't be loaded because of
undefined symbols, then the ImportError will be silently caught
(because in OOT that are pure python, that error is expected and there
isn't really any easy way to know in advance) and so you end up with a
empty module.

There isn't much that can be done at build time unfortunately because
some of the conditions that can prevent the .so from loading are
runtime issues.

Now what can you do :
 * You can remove that try catch in the __init__.py if you know your
module is not python only. Then you'll get an ImportError with some
detailled error
 * You can make sure that when building your C++ code you don't have
_any_ "Warning" from the compiler. This will catch a lot of the
missing symbols errors that are typo and things like that. But it
won't catch all of them (like if you include the header but forget to
actually link to the library).

Cheers,

Sylvain

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio