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 <a...@silverblocksystems.net> 写道： > 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
