Thank you Ben, and others for capturing the true essence of what makes gnuradio and its community so great. Although it spans a great range of disciplines and requires tremendous work (for some) to use and extend, the community is normally quite friendly and willing to help. Of course each individual should spend time doing the legwork to solve their own issues, not over-relying on the community. The project has on occasion been referred to as "Grad-ware" because so commonly it is used by students in grad-school, and requires an equivalent level of sophistication to use and extend. I know my journey with Gnuradio started 10-15 years ago and it has taken me as many years to finally get to the point where I can build some of the logic that I had been contemplating for so many years. Some of my greater ambitions will take another 5-10 years yet.
By the way the C++ suggestions that were so kindly provided were quite useful in helping me get on the right foot, and with a bit of refactoring my block is up and running - and is thread-safe now. I studied C++ in college many years ago, and haven't had to use it since then, except for my hobby projects in Gnuradio, so I am immensely appreciative of those who have the patience to not only read the mailing list inquiries, but to also offer their insights, without which some of us would never be able to use and extend Gnuradio for useful purposes. The more people that use the platform, the more the platform grows both in community and in extensions and add-ons (custom blocks). On Thu, May 9, 2019 at 5:04 PM Ben Hilburn <bhilb...@gnuradio.org> wrote: > The topic of "what kinds of questions go on gnuradio-discuss" has come up > a couple of times over the last few weeks, and we've had a lot of fresh > subscriptions over the same period (I get all the subscribe / unsub > notices), so I'll take this opportunity to quickly answer the question. > What Marcus and Albin have said are both correct, but I want to clarify > things for anyone new =) > > It is our intention that users feel welcome and free to post any question > related to GNU Radio usage to this list. SDR is a tremendously complex > technology, and involves everything from electronics manufacturing to web > development. There is no such thing as a person that is an expert in all of > these things, and we can't and don't expect users to necessarily have the > expertise to know exactly where a problem lies. > > At the same time, we do expect people asking for help to be willing to > spend the necessary time to debug their issue, and respect guidance given > on-list when referrals are made to non-GNU Radio tutorials (e.g., a > programming language or communications theory). > > It really is quite common for, say, a signal processing engineer who is an > expert algorithm developer to try to build something in GNU Radio, only to > discover that they need to use Linux and they have no idea what that means. > They might very well ask a basic question on this list, as from their > perspective, they just want to use GNU Radio. That's fine. It's also fine > for someone to respond to them and point them to a Linux tutorial (kindly). > And if someone feels especially generous and wants to tutor them through > the process, that's great! It's better done off-list, though. > > When referring someone to non-GNU Radio material, please do it in a way > that is actually useful. If someone is trying to figure out how to build > something from source, saying, "Here's a book on computer science." is not > terribly useful. Sending them to a tutorial on compiling software in Linux > would be, though. > > I keep meaning to add this to the wiki and just haven't gotten to it. We > actually had a page on the old Redmine site about the sorts of advice you > can get on-list, etc., but it got lost in the move. That said, even the old > page wasn't as complete as it ought to be. We answer enough of these > questions that it's probably worthwhile having a list of useful tutorials > for various topics that we can recommend. > > As always, everyone on this list should be treated with respect and > kindness. If you get frustrated by a question or discussion, simply don't > respond, and if you think something steps over the line, please refer it to > me or Martin. > > Cheers, > Ben > > On Thu, May 9, 2019 at 4:33 PM Marcus D. Leech <patchvonbr...@gmail.com> > wrote: > >> On 05/09/2019 04:18 PM, Albin Stigö wrote: >> >> I absolutely agree with you. There are also other completely unrelated >> issues that keep coming up like Linux, python and x11. But I don't think >> there's any great harm in ending a topic by ever-so-gently pointing people >> in the right direction. >> >> Oh, indeed, and I don't want to discourage people from "diving right in", >> but that needs to be balanced with keeping the "support envelope" >> for this forum manageable. >> >> It is the case that being really successful with a framework like Gnu >> Radio requires non-trivial facility in a number of different disciplines, >> and >> there really is no substitute for developing that facility. I'm fairly >> sure that other specialized programming frameworks go through the same >> thing, and I wonder how they cope as a community... >> >> >> >> On Thu, May 9, 2019, 22:05 Marcus D. Leech <patchvonbr...@gmail.com> >> wrote: >> >>> On 05/09/2019 02:54 PM, Albin Stigö wrote: >>> >>> Every instance of a block is an instance of the c++ class but like Nick >>> says all your variables are static and not member variables. Those need to >>> be declared in the header. Your two block instances are referring to the >>> same variables and that's why things get messed up. >>> >>> "A tour of C++" by Bjarne Stroustrup is a good refresher on C++. >>> >>> --Albin >>> >>> I'm going to suggest, ever-so-gently, that discuss-gnuradio, and Gnu >>> Radio in general aren't the places for learning C++. There are forums >>> already for that. >>> >>> I'm saying this only because in the 15 years (!!!!) I've been involved >>> with Gnu Radio, I see an alarming number of cases where the >>> intrepid Gnu Radio developer actually doesn't have much in the way of >>> programming experience in the underlying languages used, >>> and arrives here, nearly-certain that their problem is GR related, >>> rather than an improper use of the underlying programming language. >>> >>> My guess is that other specialized-framework environments have the same >>> issue. Fortunately, most people here are helpful regardless. >>> But it shouldn't be a growing *expectation*, IMHO. >>> >>> >>> >>> On Thu, May 9, 2019, 20:46 Nick Foster <bistrom...@gmail.com> wrote: >>> >>>> It looks like you've declared a bunch of static variables within your >>>> block's namespace. Those variables (including pointers!) will be shared >>>> with every instance of your block. This is Bad News. Those variables should >>>> probably all be declared in the header as class member variables. >>>> >>>> On Thu, May 9, 2019 at 11:43 AM Brad Hein <linuxb...@gmail.com> wrote: >>>> >>>>> I'm running into a strange issue with a new flow graph [1] I'm working >>>>> on that uses a custom C++ block [2] that I built. The block takes input >>>>> samples, performs some DSP, and outputs modified samples at the same >>>>> sample >>>>> rate. >>>>> >>>>> When the flowgraph has a single instance of my custom block enabled, >>>>> it works fine. But when I enable a second instance of the block in a >>>>> separate second usage, (think stereo sound, one per sink channel) it acts >>>>> very unexpectedly - output samples are wildly inaccurate and distorted. >>>>> >>>>> My perception is that the two instances of the same block seem to be >>>>> sharing some part of their memory namespace and as they modify/store >>>>> variables they are doing so in some sort of shared namespace or memory >>>>> segment. >>>>> >>>>> Is it possible for two blocks to corrupt each other's memory? I can't >>>>> think of any other explanation for the two streams working fine >>>>> individually, but when both are enabled at the same time the output is >>>>> garbled. I've tried all sorts of things like tying them to the same source >>>>> block, removing the upsampling/downsampling, adding a delay to one, etc. >>>>> with no luck. >>>>> >>>>> >>>>> [1] "Flowgraph with two parallel streams both using the custom block >>>>> pq_rails": >>>>> https://github.com/regulatre/gr-powerquality/blob/master/examples/streamer.grc >>>>> >>>>> [2] "pq_rails (Custom block) source code": >>>>> https://github.com/regulatre/gr-powerquality/blob/master/lib/pq_rails_impl.cc >>>>> >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> Discuss-gnuradio@gnu.org >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing >>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
