Hi, To complement Ron's answer, when working with a recording, there is no need to use the stream to vector -> vector to stream "trick" (at least in my experience). It should be used when making the recording instead. Regarding your recording in particular, how did you obtain it? Are you sure no samples were dropped by the USRP (i.e. no "O"s were displayed on the console) when it was obtained? That could explain the "restart!" messages you're getting. best Federico
2015-12-17 10:59 GMT-03:00 Ron Economos <w...@comcast.net>: > It looks like it's doing a little better. I would try deleting (or > bypassing) that Multiply Const block. It may actually be causing trouble > for the gr-isdbt OFDM acquisition block. > > If you do get things running, the viterbi_decoder block needs to be set to > Code rate 2/3. > > Ron > > > On 12/17/2015 05:44 AM, ahsan....@studium.fau.de wrote: > >> Thank you all for reply. Ron I have now used cyclic prefix length of 2048 >> and still no progress. For you I have attached a complete picture of my >> flowgraph. I only have a dual core processor and 4GB of ram so I used >> vector to stream in my flowgraph. The samples were recorded using a usrp >> b210 so I do not need a rational resampler. There is still no >> synchronization with any of the synchronization blocks.Can you see now >> where the problem is? Or may be if you can upload somewhere a sample dvb-t >> signal file from which I can check my receiver. Thanks alot >> >> Regards >> Ahsan >> > > > _______________________________________________ > 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
