Re: USRP B200mini Does Not Work in Gnu Radio With Latest Version of Linux Mint (21.2)
> 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)
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
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)
> > 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
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
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
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
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
Quick note that gr-gsm has a viterbi enabled GMSK demod block. Cheers, Sylvain
Re: gr-fosphor display freeze issues
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"
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
> 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
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?
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 ?
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
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
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 ?
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
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
> 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
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()
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()
> 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)
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)
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
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
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
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
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
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
> -- 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
> 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
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
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
> 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...
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...
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
> 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
> 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
> 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?
> 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
It's using an outdated version of fosphor ... so much for a fast-paced OS. Cheers, Sylvain
Re: Execute python code when tag detected
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
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)
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.
> 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
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
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
> 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
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
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++
> 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++
> 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
> 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?
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
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
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?
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
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
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?
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?
> 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
> 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
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
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
> 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
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]?
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
> 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
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
> 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
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
>> > 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
> 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!)
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)
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
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)
> 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)
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
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
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
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
> 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
> > 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
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
> 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&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
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
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
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
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?
> 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
> 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
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?
Hi, > It's a little bit off-topic but if someone will change the gr-osmosdr, > it would be great to have other stream tags that we are used to see at > the output UHD source. For example if the source prints on the output > that there is some problem with transmission it would be great to add a > stream tag at that moment. In Multi-RTL > (https://github.com/ptrkrysik/multi-rtl/) currently any such event means > that synchronization of channels is lost until user manually calls > resynchronization. Because there is no way to detect samples loss > resynchronization can't be called automatically. rtl-sdr can't detect sample loss ... With USRP, the hw reports overflows to the host, but the rtl-sdr has no such thing, it will drop sample silently if its internal buffers overflow. Cheers, Sylvain ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scheduler enhancement?
> 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
> 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
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
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
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
> 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