Hi Frederico, hi Ihab

to add a little background Vector to Stream / Stream to Vector advice:
That's a pretty good trick to add buffering between your hardware and
your decoder, because the/stream to vector/ has to accumulate as many
samples as fit in one vector, and the buffer between that and the
/vector to stream /will usually hold at least two items, which in this
case contain a huge amount of samples. The buffer downstream of /stream
to vector/ is going to be huge, too, because/stream to vector/ tells the
GNU Radio runtime his big output multiple. That's three large buffers at
once.

Another trick you can try is set a "min output buffer" in your hardware
source block's "advanced" tab.

Notice that both these tricks actually need large circular buffers,
which means they will consume shared memory, which on Linux doesn't grow
on trees -- If you get a ENOSPACE (Error, no space left on device), it's
not because some filesystem is full, but because you actually ran out of
shared memory buffers. You can increase the available shared memory,
though:

sysctl -w kernel.shmmax $(( 2**30 ))

Best regards,
Marcus

On 26.11.2015 18:22, Federico Larroca wrote:
> Hi Ihab,
> Those "restart aquisition" are generated by the ofdm_sym_acquisition
> block when it does not find a peak on the correlation function he uses
> to detect the beginning of the OFDM symbol. You should verify there is
> indeed a DVB signal precisely at 570 MHz. To do this you may use our
> "Sym Align OFDM" block (not a very nice name) available with gr-isdbt
> (https://github.com/git-artes/gr-isdbt) and check that you see a
> "triangle" (please refer to the readme, the examples, and even the
> issues on our git). The symbol alignment is totally equivalent between
> DVB-T and ISDB-T.
> Moreover, I see several "O"s, meaning that somewhere samples are being
> dropped. That does not help either. If you do not have a very fast
> machine, you may use at the beginning of the flowgraph a "Stream to
> Vector" followed by a "Vector to Stream" with a very big "Num Items"
> (some millions).
> best
> Federico
>
> 2015-11-26 12:59 GMT-03:00 Ihab Zine <ihab.zin...@gmail.com
> <mailto:ihab.zin...@gmail.com>>:
>
>     Hi,
>
>     I’m trying to receive a live signal from an antenna on the roof
>     through a cable connected to my SDR (hackrf one ).The bandwidth of
>     the DVB-T in ireland is 8 Mhz , and the parametetrs Here in
>     ireland as following:
>
>     Bandwidth: 8 MHz
>     Stream code rate (hi prio): FEC 2/3
>     Stream code rate (lo prio): FEC 2/3
>     Modulation: QAM 64
>     Transmission mode: 8k mode
>     Guard interval: 1/32
>     Hierarchy: none
>
>     net_data_rate = 24.128 Mbits/s
>
>     I used dvbt_rx_demo_8k_QAM64_rate78.grc flow graph with the
>     following changes :
>
>      *
>
>         frequency of hackrf one = 570 Mhz, sampling rate = ((8*8e6)/7).
>
>      *
>
>         Cyclic Prefix to (8192/32, is this right?)
>
>      *
>
>         Code Rate HP : 2/3
>
>      *
>
>         Code Rate LP : 2/3
>
>      *
>
>         Guard Interval : 1/32
>
>     The problem i have is that no output data coming out after the
>     demod_reference_signals BLOCK(no cancellation map), and got the
>     following:
>
>     restart aquisition
>
>     OOrestart aquisition
>
>     d_freq_offset: -5
>
>     Od_freq_offset: -5
>
>     d_freq_offset: -5
>
>     d_freq_offset: -5
>
>     d_freq_offset: -5
>
>     d_freq_offset: -5
>
>     d_freq_offset: -5
>
>     d_freq_offset: -5
>
>     restart aquisition
>
>     OOd_freq_offset: -5
>
>     d_freq_offset: -5
>
>
>
>     so I had to add a signal source to shift the signal. After shfting
>     the signal i got the following :
>
>     restart aquisition
>
>     restart aquisition
>
>     restart aquisition
>
>     restart aquisition
>
>     Orestart aquisition
>
>
>
>     I have read a lot about DVB , mapping ,ofdm and others, i have
>     spent weeks on this but still the same problem, if it is
>     synchronization problem what i should do?
>
>     So please i need a some help with this problem .
>
>
>
>     Thanks
>
>     Ihab
>
>
>
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     Discuss-gnuradio@gnu.org <mailto: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

Reply via email to