Hi Federico, I think I have sent my previous email a bit too fast.
After having looked at the code of the OFDM Synchronization block it seems to me that this block is specific to ISDB-T. This would mean that I cannot use it for DVB-T because of incompatibilities between ISDB-T and DVB-T (e.g. carrier positions). Kind regards, Ralf Am 03.03.2020 um 13:05 schrieb Federico 'Larroca' La Rocca:
Hi Ralf, It should be right after the channel. It performs symbol acquisition, FFT and channel equalization (as well as sampling corrections and coarse and fine frequency corrections). Please see the examples folder in gr-isdbt (for instance rx_demo.grc which also includes the gr-dtv blocks disabled, which should help you understand where to put the block). best El mar., 3 mar. 2020 a las 4:16, Ralf Gorholt (<ralf.gorh...@gmx.de <mailto:ralf.gorh...@gmx.de>>) escribió: Dear Federico, unfortunately I have not been able to figure out how this block has to be used and where it has to be positioned in the flow graph. Although I know more about DVB-T today than three months ago I am still a beginner :-) Perhaps it would help me if you could give me some hints. Thank you very much and kind regards, Ralf, DL5EU *Gesendet:* Montag, 02. März 2020 um 13:47 Uhr *Von:* "Federico 'Larroca' La Rocca" <flarr...@gmail.com <mailto:flarr...@gmail.com>> *An:* "Ron Economos" <w...@comcast.net <mailto:w...@comcast.net>> *Cc:* "GNURadio Discussion List" <discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>> *Betreff:* Re: DVB-T receiver problem (OFDM symbol acquisition) Hi, Although I don't have an answer to Ralf's question, if the sampling rate seems to be a problem, gr-isdbt's OFDM Synchronization block (with "Interpolate" set to "yes") corrects the sampling rate; see https://iie.fing.edu.uy/publicaciones/2016/LFGGB16/ for an explanation of the algorithm (although it expects different tags and parameters, so that's probably why it won't work out of the box with the rest of the gr-dtv blocks or a DVB-T transmission). As Ron wrote, the rest of the block is mostly the same as in gr-dtv. best Federico El lun., 2 mar. 2020 a las 9:44, Ron Economos (<w...@comcast.net <mailto:w...@comcast.net>>) escribió: Did you read the README.md of gr-dvbt? It says: /Late note: As of 2015, I donated the gr-dvbt project to gnuradio. It is now integrated in the mainline of gnuradio/gr-dtv./ The OFDM symbol acquisition block in gr-dtv has been upgraded with the fixes from the ISDBT team. See this commit: https://github.com/gnuradio/gnuradio/commit/761b62d4660a121c78b6a7ad17fd7b08badcbb88#diff-aa5858d955a31c6be8746db56ea13c6a However, there is still an issue with the block. It can't tolerate a sample rate difference between the transmitter and receiver. If the difference is large, the block will fail fairly quickly (minutes). I have a test OFDM acquisition block that prints out the drift. It can be found here: https://github.com/drmpeg/gr-dvbtx You may have to go back one commit to make it compile with the latest version of GNU Radio 3.7. Ron On 3/2/20 03:58, Ralf Gorholt wrote: Dear all, please apologize my long email but I cannot explain my problem and what I have done so far in three words. I am currently working on a DVB-T receiver project to receive transmissions on 434 MHz with 2 MHz bandwidth or less using GNU Radio and an RTL-SDR stick. The flow graph is based on the examples in gr-dvbt. The transmitter is a HiDes model HV320E. Reception works, but the video stops after one minute or so while the constellation diagram is still active (dots are moving). I am no expert and have only few knowledge of DSP and DVB yet, but to me the problem seems to be in the OFDM symbol acquisition block. Conditions: Linux Mint 19.3 in a virtual machine (VMware) GNU Radio 3.7.11 if I am right (I would need to check at home) What I have done so far: I have created a flow graph for a DVB-T receiver based on the examples in gr-dvbt. The signal source is an RTL-SDR stick and the sample rate is 16/7 MHz (= 2.285714 MHz) to get 2 MHz bandwidth. The signal sink is a TCP server sink to which I connect with VLC media player to display the received video transport stream. This works, but after one minute or so the video stops while the constellation diagram is still active (dots are moving). I am currently using QPSK, code rate 3/4 and guard interval 1/8 but I have also tried 16QAM, code rate 1/2 and guard interval 1/8 and have the same problem. To track down the source of the problem, I have created a file outside of GNU Radio that I can use in a file source instead of the RTL-SDR source of my flow graph. This allows me to make tests with an input signal that does not change between different tests. The data of this file are sent to the OFDM symbol acquisition block and the output of this block is stored in a second file. When the input signal, the algorithm and the parameters do not change between different tests I expect the generated file to be always the same. However, this is not the case. The files that are generated with the output of the OFDM symbol acquisition block differ from each other. But when I send the content of one of those generated files to the rest of the receiver and do this several times, I always get the same transport stream at the output. I have verified this by using a file sink and comparing the files. That’s why I suspect the OFDM symbol acquisition block to be the culprit. When I was searching the internet for information concerning my problem, I found an email from 2015 in the archive of this mailing list where someone wrote that the OFDM symbol acquisition block of gr-isdbt should be used because it worked better than the one in gr-dvbt. I have done so and installed gr-isdbt from git and replaced the block. However, there are two such blocks in gr-isdbt and none of them solves my problem. They perform even worse than the original block in gr-dvbt and after some time the program terminates without a message. I hope that my explanations are clear enough. Is there anybody who can tell me what might be wrong here or what I am doing wrong? Why is the output of the OFDM symbol acquisition block not always the same when the start condition of every run is the same? Am I missing something here? Thank you very much for your help. Kind regards, Ralf
