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
