Re: [Discuss-gnuradio] [GREP] GNU Radio Coding Guidelines
Hi, On Mon, 14 Jan 2019 23:03:40 -0800 Ron Economos wrote: > I realize that I'm late to the game, but I was recently reminded of > this GREP (and it's associated GREP 0011). I'm all for cleaning the > code, but the current .clang-format rules create a problem (that's > addressed in GREP 0011). Yeah, a bit late, but with valid arguments nonetheless. > > Specifically, the current .clang-format would change the files so > much, that the repository history would become useless. In GREP 0011, > this is referred to as a "history reset". Reformatting everything in one commit will make it easy to jump this single commit if going back in git blame or in git log. Still all functional (relevant) changes are visible to the observer. Mitigating "large" code changes by crafting a .clang-format comapatible to the old, non-enforced, coding guideline will result in "medium" code changes. At that point it's not really clear if one would have a benefit of changing only half of the code (since it's very likely to be the "important" half). And thus the .clang-format was crafted to have the most pleasant coding experience. Also while editing old files the formatting was all over the place in relevant places (where the functional code lives). Usually header & footer is formatted uniformly. > > I'd like to suggest a middle ground. A .clang-format can easily be > crafted that uses the old GNU Radio guidelines. This would provide > minimal changes to the files, and a "history reset" would be avoided > (or at least mitigated). Personally I'm not really keen to touch the formatting again, but I'd like to hear other opinions. But to be honest, I don't really care, as long as the formatting is enforced automatically. Otherwise formatting is futile. Thanks for chiming in! Cheers Andrej ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [GREP] GNU Radio Coding Guidelines
I realize that I'm late to the game, but I was recently reminded of this GREP (and it's associated GREP 0011). I'm all for cleaning the code, but the current .clang-format rules create a problem (that's addressed in GREP 0011). Specifically, the current .clang-format would change the files so much, that the repository history would become useless. In GREP 0011, this is referred to as a "history reset". I'd like to suggest a middle ground. A .clang-format can easily be crafted that uses the old GNU Radio guidelines. This would provide minimal changes to the files, and a "history reset" would be avoided (or at least mitigated). Comments, questions or concerns? Ron GREPs: https://github.com/gnuradio/greps/blob/master/grep-0001-coding-guidelines.md https://github.com/gnuradio/greps/blob/master/grep-0011-code-reformatting.md Old guidelines: https://wiki.gnuradio.org/index.php/Coding_guide_impl https://wiki.gnuradio.org/index.php/BlocksCodingGuide On 2/15/18 12:20, Martin Braun wrote: Hi all, recently, we announced the GREP process (see also here: https://www.gnuradio.org/blog/gnu-radio-enhancement-proposal-process/). The first actual GNU Radio Enhancement Proposal is about *coding guidelines*, you can find the associated PR here: https://github.com/gnuradio/greps/pull/4 To recap the process, this PR will be up for discussion for a little longer until there's no objections to merging it. Merging it does not however finalize it, it just means it's deemed good enough to become an official GREP, in "Draft" status. Eventually, we'll flag it as "Active", and even then, it's open for discussion (but once that happens, it'll also become the official coding guidelines for the project!). If you're interested in the GREP process in general, in the coding guidelines specifically, or both, I would recommend checking out the repository, and commenting. The guidelines themselves are currently 100% up for debate. I copied them from another project and renamed the project name to "GNU Radio" as a place to get started. Cheers, Martin ___ 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
Re: [Discuss-gnuradio] Regarding correlate access code-tag block
Actually, with the Default Header Format file, and the Protocol Formatter, use correlation-access tagged block was a piece of cake. Also, here's an example of bspk using constellations - if you haven't found already. -- Cinaed On 1/14/19 12:39 PM, Cinaed Simson wrote: > As you may have already discovered, I was wrong about unpacking bits for > fec. > > Actually, I have no idea on how I'm getting the results I'm getting > using my modifications of your flowgraph - those depreciated blocks > definitely have strange problems. If I insert the unpack k=8 block as > required for fec the flowgraph doesn't work. > > I ran into a problem testing fec - I modified your sources and I didn't > have enough frame bits. So I set the frame bits to exactly what I need. > > And I can't get a simple correlation access tagged test working - even > with a tag gate. The only way it works is if remove the access code - > which defeats the purpose. > > So I'm go to have to evolve and get the protocol formatter working. > > Also, you don't have to use the rx and tx packet blocks - you can use > the replacements for the PSK mod/demod blocks - the constellation > mod/demod blocks - you probably shouldn't use any depreciated blocks. > > -- Cinaed > > > On 1/10/19 10:01 PM, Maitry Raval wrote: >> Hello, >> >> Ok, One more query, what is the purpose of the block unpack k=1 bit at >> output of PSK demod block, because the meaning of unpack k=1 means byte to >> byte conversion, right? >> >> With Best Regards, >> Maitry Raval, >> >> - Original Message - >> From: "Cinaed Simson" >> To: "Maitry Raval" >> Cc: "discuss-gnuradio" >> Sent: Friday, January 11, 2019 2:11:54 AM >> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block >> >> On 1/10/19 2:47 AM, Maitry Raval wrote: >>> Hello, >>> >>> Thanks for your time! >>> >>> It works completely fine, now I understand that we have to give tagged >>> stream at the input of encoder. >> >> Sorry, I didn't mean to imply you needed the stream to tagged stream >> block to make it work. >> >> I just put in at the beginning so I could use the tag debug as a brute >> force search to find out what was blocking the flow. >> >> There are two sequential tag blocks - the correlate correlate access >> code-tag from gnuradio and a block from gr-satellites - I would guess >> that is all you need. >> >> Select "pass thru" on the stream to tagged stream block - it should >> still work. >> >> -- Cinaed >> >> >>> >>> >>> With Best Regards, >>> Maitry Raval, >>> R& D engineer|Azista Industries Pvt Ltd| >>> 079-40605800|www.azistaaerospace.com >>> >>> - Original Message - >>> From: "Cinaed Simson" >>> To: "discuss-gnuradio" >>> Cc: "Maitry Raval" >>> Sent: Thursday, January 10, 2019 1:21:34 PM >>> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block >>> >>> Hi Mailry - I was able to get it run. >>> >>> I used the "correlate access" block from gnuradio - my installation of >>> gnuradio didn't like the block in your flowgraph. >>> >>> And then I had to install the python module "construct" in order to get >>> the flowgraph to run. >>> >>> In order to get the flowchart to work - at least in the sense of filling >>> up the output.txt file - I added a "Stream to Tagged Stream" block and >>> define a consist tag to get the Tag Debug block to work. >>> >>> Also, I had to remove the "unpack" block before the PSK modulation, >>> added a "Unpack K=1" block just after the PSK demodulation - and I set >>> "Generate Options" to "No Gui" in the Options block. >>> >>> -- Cinaed >>> >>> >>> >>> On 1/8/19 12:40 AM, Maitry Raval wrote: Hello, thanks for your guidance. I have also attached the grc file, input/output files and python file for your reference. after adding tag debug, still didn't get any output. I have also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version. actually because these psk blocks are deprecated, I have tried it with dpsk mod, demod block. But as I wanted to do continuous transmission, I didn't find replaced block for correlate access code-tag block, and the cusom block from gr-satellites are for extracting syncbits. I have also tried with simple flow graph by just sream muxing 2 files one with sync bits and other one is payload file and give that output to correlate access code-tag block, but that also didn't work. It would be grateful, If you guide me on this. I just want to make that sync bits searching and extracting from payload and receive only payload at the output. With Best Regards, Maitry Raval, - Original Message - From: "Cinaed Simson" To: "discuss-gnuradio" Sent: Tuesday, January 8, 2019 1:47:56 PM Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block I broke down and looked at the image. Note, PSK Demod, Correlate
Re: [Discuss-gnuradio] Regarding correlate access code-tag block
As you may have already discovered, I was wrong about unpacking bits for fec. Actually, I have no idea on how I'm getting the results I'm getting using my modifications of your flowgraph - those depreciated blocks definitely have strange problems. If I insert the unpack k=8 block as required for fec the flowgraph doesn't work. I ran into a problem testing fec - I modified your sources and I didn't have enough frame bits. So I set the frame bits to exactly what I need. And I can't get a simple correlation access tagged test working - even with a tag gate. The only way it works is if remove the access code - which defeats the purpose. So I'm go to have to evolve and get the protocol formatter working. Also, you don't have to use the rx and tx packet blocks - you can use the replacements for the PSK mod/demod blocks - the constellation mod/demod blocks - you probably shouldn't use any depreciated blocks. -- Cinaed On 1/10/19 10:01 PM, Maitry Raval wrote: > Hello, > > Ok, One more query, what is the purpose of the block unpack k=1 bit at output > of PSK demod block, because the meaning of unpack k=1 means byte to byte > conversion, right? > > With Best Regards, > Maitry Raval, > > - Original Message - > From: "Cinaed Simson" > To: "Maitry Raval" > Cc: "discuss-gnuradio" > Sent: Friday, January 11, 2019 2:11:54 AM > Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block > > On 1/10/19 2:47 AM, Maitry Raval wrote: >> Hello, >> >> Thanks for your time! >> >> It works completely fine, now I understand that we have to give tagged >> stream at the input of encoder. > > Sorry, I didn't mean to imply you needed the stream to tagged stream > block to make it work. > > I just put in at the beginning so I could use the tag debug as a brute > force search to find out what was blocking the flow. > > There are two sequential tag blocks - the correlate correlate access > code-tag from gnuradio and a block from gr-satellites - I would guess > that is all you need. > > Select "pass thru" on the stream to tagged stream block - it should > still work. > > -- Cinaed > > >> >> >> With Best Regards, >> Maitry Raval, >> R& D engineer|Azista Industries Pvt Ltd| 079-40605800|www.azistaaerospace.com >> >> - Original Message - >> From: "Cinaed Simson" >> To: "discuss-gnuradio" >> Cc: "Maitry Raval" >> Sent: Thursday, January 10, 2019 1:21:34 PM >> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block >> >> Hi Mailry - I was able to get it run. >> >> I used the "correlate access" block from gnuradio - my installation of >> gnuradio didn't like the block in your flowgraph. >> >> And then I had to install the python module "construct" in order to get >> the flowgraph to run. >> >> In order to get the flowchart to work - at least in the sense of filling >> up the output.txt file - I added a "Stream to Tagged Stream" block and >> define a consist tag to get the Tag Debug block to work. >> >> Also, I had to remove the "unpack" block before the PSK modulation, >> added a "Unpack K=1" block just after the PSK demodulation - and I set >> "Generate Options" to "No Gui" in the Options block. >> >> -- Cinaed >> >> >> >> On 1/8/19 12:40 AM, Maitry Raval wrote: >>> Hello, >>> thanks for your guidance. >>> I have also attached the grc file, input/output files and python file for >>> your reference. after adding tag debug, still didn't get any output. I have >>> also tried this same in ubuntu 18.04 with GNU radio 3.7.11 version. >>> actually because these psk blocks are deprecated, I have tried it with dpsk >>> mod, demod block. But as I wanted to do continuous transmission, I didn't >>> find replaced block for correlate access code-tag block, and the cusom >>> block from gr-satellites are for extracting syncbits. >>> I have also tried with simple flow graph by just sream muxing 2 files one >>> with sync bits and other one is payload file and give that output to >>> correlate access code-tag block, but that also didn't work. >>> >>> It would be grateful, If you guide me on this. I just want to make that >>> sync bits searching and extracting from payload and receive only payload at >>> the output. >>> >>> >>> With Best Regards, >>> Maitry Raval, >>> >>> >>> - Original Message - >>> From: "Cinaed Simson" >>> To: "discuss-gnuradio" >>> Sent: Tuesday, January 8, 2019 1:47:56 PM >>> Subject: Re: [Discuss-gnuradio] Regarding correlate access code-tag block >>> >>> I broke down and looked at the image. >>> >>> Note, PSK Demod, Correlate Access Code - Tag, Packet Encoder, and Packet >>> Decoder have been depreciated. >>> >>> And they're usually depreciated because they have problems - and they >>> are usually replaced with different blocks which work better and are >>> typically more general. >>> >>> The tutorials are good place to start looking for the replacements. >>> >>> -- Cinaed >>> >>> >>> On 1/7/19 11:22 PM, Thomas Lavarenne wrote: Oh, it is
[Discuss-gnuradio] Gnuradio ring buffer code
Hi, I'm implementing an application that has similarities with gnuradio in as much as it stores ethernet packets containing radar pulse descriptor words in a ring buffer. Its the same producer/consumer idea, i.e. a producer (Rx) pushing packets into the ring buffer and a consumer (processing algorithm) pulling packets out. I'm really struggling with the consumer keeping up with the producer though, whether this is due to thread mutex contention, thread scheduling, thread priority or just code bottlenecks I haven't been able to pin down I was hoping to take a look at the gnuradio src to see how the problem is tackled there. Could anyone help point me to the right part of the src, I've had an initial go but have been unable to find the specific parts of the code that handle the adding/taking of samples into the gnuradio ring buffer. I'm particularly interested to know what phtread scheduling is used if its different from the defaults and how mutexes are handled regards, bph ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
