Re: [Discuss-gnuradio] anyone know what is the theory of the implementation of pll_freqdet_cf
Not sure. Just lock to one of them and another as interference. If interference after loop filtering is small (out of loop bandwidth) it can keep locking. 在 2019年1月11日星期五，wu jo 写道： > Hi, > thanks. i think i have figured out it from the source. i think this block > only works for a clean single frequency. if there are 2 or more frequency > in the input signal it will not detect any of them, right? > -- > *发件人:* WarMonkey > *发送时间:* 2019年1月11日 3:24 > *收件人:* wu jo > *抄送:* discuss-gnuradio@gnu.org > *主题:* Re: [Discuss-gnuradio] anyone know what is the theory of the > implementation of pll_freqdet_cf > > http://ricesimulink.groups.et.byu.net/pll.phtml > > > 在 2019年1月8日星期二，wu jo 写道： > > Hi ALL, > I am reading a block that using pll_freqdet_cf. it said pll_freqdet_cf > detect a frequency then lock to it. but what is the theory of the > impletation of that? anyone can share the knowledge? > > Best Regards > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Single step a stream
Keep in mind, with the multi-threaded scheduler you wouldn't end up in a deterministic state. Unless of course you only want to debug the state of your own block -- then you can do what WarMonkey suggested. -- M On Mon, Jan 7, 2019 at 11:43 AM Rudolf Wigblurr wrote: > Hi, > > Is it possible to single step a flow graph? > > I have a recorded stream of FSK modulated data with about 25 bursts of > messages. > When this is later decoded I do not get 100% detection, about 4 of 25 > bursts fails. > > Now my thinking is can I play this burst by burst and see what is wrong. > So my plan was to stop the scheduler after each burst. > Can I control (stop) the scheduler when a 'tag' is detected and restart it > with a GUI button. > > Block,Python,C++ dosen't matter... > > /Rudolf > ___ > 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] problems with installation on ubuntu 18.04.1
Is there more info in the build output further up? On Thu, Jan 10, 2019 at 4:48 PM Achilleas Anastasopoulos wrote: > Hi all, > > I needed to install gnuradio from source on an ubuntu 18.04.1 machine. > I followed the directions in > > https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux > > I installed the dependencies and then cloned gnuradio > > I checked out v3.7.10 > > git checkout 3.7.10git > > and performed the standard > > cmake > > make > > Unfortunately make stops around 50% with an error when linking > libgnuradio-blocks-3.7.10git.so > > --- > [ 53%] Linking CXX shared library libgnuradio-blocks-3.7.10git.so > [ 53%] Built target gnuradio-blocks > Makefile:162: recipe for target 'all' failed > make: *** [all] Error 2 > > I am also attaching the output of cmake > > Any clues as to what maybe wrong? > > thanks > > Achilleas > > > > > > ___ > 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] [announcement] 3.8 Feature Freeze in effect
Hello bug-crushiest SDR community known to sentient beings across the universe, as of yesterday, the freeze on features to still make it into the GNU Radio 3.8.0.0 release is in effect. This means that the list of missing features is now closed; this by no means means that these are all implemented right now! I'd like to highlight things to be implemented by 3.8.0.0 (list is not exhaustive): * Bug fixes. We need to get rid of all open bugs within the 3.8 release project. That means fixing them, not closing them ;) * gr-newmod: What would be the worth of an API-changing release that developers can't use to write OOTs for, due to a lack of template for gr_modtool? * modern CMake: There's ongoing work to un-historify our CMake codebase. This will lead to better usability, rarer breakage, better detection of dependencies, better test writing, cleaner API for OOTs. It's sadly not done yet. * Replacing our log4cpp backend with something better: log4cpp is a bad dependency, and we need to get rid of it. Also, multiple parties mentioned they need better logging, so I'm currently implementing a multi-producer, single-consumer queue with arbitrary numbers of logging backends. As usual, discuss away here, contact me in private, or ping us on IRC. Best regards, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [announcement] 3.8 Feature Freeze in effect
On Fri, Jan 11, 2019 at 11:10 AM Marcus Mueller wrote: > * Replacing our log4cpp backend with something better: log4cpp is a > bad dependency, and we need to get rid of it. Also, multiple parties > mentioned they need better logging, so I'm currently implementing a > multi-producer, single-consumer queue with arbitrary numbers of > logging backends. > Note this is the same discussion as we have captured in GREP13: https://github.com/gnuradio/greps/blob/master/grep-0013-remove-log4cpp.md -- M ___ 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
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? It means unpack 1 bit from the byte. Since it was PSK - or 1 bit per symbol - I used k=1. I put it in there because at the time I didn't know if the packet decoder was working because nothing was coming out of it. It won't create any problems but it's probably not be necessary. In hindsight, the error in the flow graph was the unpack k=8 in front of the packet coder near beginning. In fact, if you had chosen unpack k=1 instead of unpack k=8, everything would have worked perfectly! -- Cinaed > > 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 "File Sink" not "Tagged file sink", didn't see sorry. Le mar. 8 janv. 2019 à 08:20, Thomas Lavarenne mailto:thomas.lavare...@gmail.com>> a écrit : Hi, But, the issue is that correlate access code-tag block is not working and producing tags, so that my output file will come blank. as I am certain that at the output of FEC extended
Re: [Discuss-gnuradio] Single step a stream
Actually you can “freeze” execution and spying every thread with gdb, or just let sereval of them continue as your wish . Use data breakpoint can trap the exact point where abnormal happens. 在 2019年1月12日星期六，Martin Braun 写道： > Keep in mind, with the multi-threaded scheduler you wouldn't end up in a > deterministic state. Unless of course you only want to debug the state of > your own block -- then you can do what WarMonkey suggested. > > -- M > > On Mon, Jan 7, 2019 at 11:43 AM Rudolf Wigblurr > wrote: > >> Hi, >> >> Is it possible to single step a flow graph? >> >> I have a recorded stream of FSK modulated data with about 25 bursts of >> messages. >> When this is later decoded I do not get 100% detection, about 4 of 25 >> bursts fails. >> >> Now my thinking is can I play this burst by burst and see what is wrong. >> So my plan was to stop the scheduler after each burst. >> Can I control (stop) the scheduler when a 'tag' is detected and restart >> it with a GUI button. >> >> Block,Python,C++ dosen't matter... >> >> /Rudolf >> ___ >> 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] symbol_sync_cc stuck when error too large (resulting d_avg_period goes negative)
Yes I have already did all above. AGC and matched filter give little help, simply they just can’t **guarantee** TED output not out of range. I can reproduce this with usrp b210 and a 50R terminator at input. Some pulse will be produced when b210 starts or gain is changed. Recorded samples and flowgraph will be available later. 在 2019年1月9日星期三，Andy Walls 写道： > Hello: > > > Date: Mon, 7 Jan 2019 20:24:57 +0800 > > Bug > > > > When input amplitude is too large, symbol_sync_cc get stuck. > > Screenshot > > > > frame1 > > frame2 > > Tracing > > > > in file symbol_sync_cc_impl.cc line 537: > > error = -488.4; > > advance_loop(error); > > in file clock_tracking_loop.cc line 128 function advance_loop(float > error) : > > before: d_avg_period=10.771521, d_beta=0.0090558, error=-488.4; > > d_avg_period = d_avg_period + d_beta * error; > > after: d_avg_period = -0.417 > > out of range [d_min_avg_period, d_max_avg_period] > > back to file symbol_sync_cc_impl.cc line 540: > > d_clock->phase_wrap(); > > in file clock_tracking_loop.cc line 145 function phase_wrap() > > > > phase = -87.227, limit=-0.417/2=-0.20895, now we stuck in these while > > loops; > > Thank you! for the detailed tracing of the problem you encountered. > > Please report the bug on the github.com/gnuradio Issue tracker: > > https://github.com/gnuradio/gnuradio/issues > > So this is certainly a problem with the block: it should never hang > even if used improperly. > > However, given the large error sample value of -488.4, it looks like > you are not properly conditioning your input sample stream to the > block. > > For best results with the symbol_sync_cc block, please ensure: > > 1. You have a filter block acting as a channel filter or IF filter, > filtering noise from the input signal > > 2. You use an Automatic Gain Control block to control the amplitude of > the input signal to a consistent value. Your input amplitude should be > what the derivation of the particular Timing Error Detector (TED) in > use is expecting. For Decision Directed TEDs, the input amplitudes > should match what the slicer constellation is expecting. For the > signal*slope ML approximation TED, the input amplitude should be > significantly less than 1.0. For the signum*slope TED, the amplitude > should be greater than 1.0. > > 3. Use a level shifter/DC removal block. Almost all of the TED's > expect the amplitude excursions to be centered about 0. > > 4. You have a matched filter conditioning the input stream, either out > in front of the block, or done by the block's internal PFB > interpolation filter, to peak the symbol centers and reduce noise. If > you have rectangular pulses and use a TED that requires a derivative, > you must use an external filter block for the matched filter. > > 5. That you have set the TED gain based of the slope of the TED S-Curve > at timing offset = 0. The TED S-Curve for you situation must be > determined from modeling and simulation of the TED with various timing > offsets in your specific Signal/Noise/ISI situation in MatLab, Octave, > Python, R, or some other mathematical simulation tool. > > > If you are doing all of the above and the problem is induced by AGC > amplifying up noise in between received bursts, I would like to know. > > > > ps: i think period should be d_avg_period, because avg period is > > estimated symbol period. when loop bandwidth relatively larger ( > > 0.05~0.25 ), limiting d_inst_period can make tracking error larger, > > even loop unlock. i'll benchmark both later. > > Workaround > > > > apply limit to d_avg_period immediately after d_avg_period changed > > It is a potential change to make when fixing the block. > > I pondered this choice when I initially wrote the block. Back then I > decided to let the out of limits d_avg_period be applied to the > feedback, thinking that the excursion could never be so large as to > cause a problem, and that it might speed lock-in. I never imagined the > error signal being so large with proper conditioning of the input and > setting of the TED gain. > > Regards, > Andy > > > in file clock_tracking_loop.cc line 127 > > > > Ultimate solution > > > > check every input, state and output in range when calculate > > control loop > > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problems with installation on ubuntu 18.04.1
I resolved all the issues with 3.7.13.4 Achilleas On Fri, Jan 11, 2019 at 3:37 PM Achilleas Anastasopoulos wrote: > Hi Martin, > > I resolved all the issues with 3.7.13.4 > > Achilleas > > On Fri, Jan 11, 2019 at 2:07 PM Martin Braun > wrote: > >> Is there more info in the build output further up? >> >> On Thu, Jan 10, 2019 at 4:48 PM Achilleas Anastasopoulos < >> anas...@umich.edu> wrote: >> >>> Hi all, >>> >>> I needed to install gnuradio from source on an ubuntu 18.04.1 machine. >>> I followed the directions in >>> >>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux >>> >>> I installed the dependencies and then cloned gnuradio >>> >>> I checked out v3.7.10 >>> >>> git checkout 3.7.10git >>> >>> and performed the standard >>> >>> cmake >>> >>> make >>> >>> Unfortunately make stops around 50% with an error when linking >>> libgnuradio-blocks-3.7.10git.so >>> >>> --- >>> [ 53%] Linking CXX shared library libgnuradio-blocks-3.7.10git.so >>> [ 53%] Built target gnuradio-blocks >>> Makefile:162: recipe for target 'all' failed >>> make: *** [all] Error 2 >>> >>> I am also attaching the output of cmake >>> >>> Any clues as to what maybe wrong? >>> >>> thanks >>> >>> Achilleas >>> >>> >>> >>> >>> >>> ___ >>> 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
