Re: Channel estimation OFDM saving taps
Thank you so much for your answer, Marcus. I understood everything. I'm going to try to build my own block. Have a nice day. On Tue, Mar 3, 2020 at 9:48 PM Müller, Marcus (CEL) wrote: > Hi Vinicius, > > you can directly feed the output of the OFDM channel estimation block > into a simple general block that you write yourself[1] – even in Python > – and make that block > > * either save the contents of the relevant tags to a file or > * output a vector of (inverse) channel coefficients taken from the >`ofdm_sync_eq_taps` tag. > > Generally, however, never forget that OFDM channel estimations are > *not* a property of the _channel_, but of the _receiver_: > If you recall the effects of having a cyclic prefix in OFDM, you'll > remember that it's not critical that your receiver is in perfect time > synchronity with the beginning of the actual payload part of the symbol > (after the CP). > > Instead, as long as your FFT starts *somewhere* in the cyclic prefix, > you're fine synchronization-wise, since a (simulatedly) circular time > shift (due to starting the FFT in the CP instead of exactly at the > start of symbol after the CP) is just a point-wise multiplication with > a complex sinusoid after the FFT – and that means your timing offset > will just manifest as rotation of the channel coefficients. > > And you're correcting these, anyway. So, as long as a CP-OFDM receiver > is consistent in the amount of time it starts doing the FFT before the > end of CP, the rotation each subcarrier coefficient experiences is > always the same and will thus be corrected (e.g. through pilot > estimation). > > But: That means that your channel estimate is not the same you'd get > when you're even a fraction of a sample off in timing compared to > someone else. It's still the same, ignoring complex rotation, so the > power delay profile will be right, and when you agree on e.g. an > average phase of symbols, you can compare different channel estimates, > but don't directly compare the channel estimates from different > receivers, or the same receiver over more than a frame, or after > tuning. > > Best regards, > Marcus > > [1] https://tutorials.gnuradio.org > > PS: long-term observers will know that I fought very hard to not embed > loads of LaTeX in this reply. > > On Tue, 2020-03-03 at 16:39 +0100, Vinicius Mesquita wrote: > > Hello. > > Thank you in advance for the help... > > > > I already searched the mailing list and could not find it how to > properly see/save the channel taps from the OFDM Channel Estimation block. > I saw that is in a tag, but how can I save it? > > > > What I'd love to find is a way to see the channel estimation with the 52 > taps in a QT GUI plot. Is that possible? If it's not, saving it it's > already awesome. > > > > Thank you!! >
Re: Wire shark output question
Dear Ranganathan, the two connections to the Wireshark block are for (1) the packets that are generated locally and (2) the packets that are received. It is the same kind of data, i.e., the bytes that are about to be send out/the bytes that were demodulated. If you disconnect "rxout" from the PHY, you won't see the packets that were received. If you disconnect "pdu out" from the MAC, you won't see the packets that are generated locally. So what you describe sounds like you don't receive packets. Do you do this over the air? Best, Bastian On 3/3/20 11:05 PM, sampath ranga wrote: > Dear all, > > I am currently working on IEEE802.15.4 protocol with GNU Radio and > different SDR. I am using Dr. Basti's code for testing. Its successful. > But i am having few questions to ask. I see two connections to Wireshark > from PHY layer "rxout" pin and also from pdu out of MAC layer. When i > disable PHY Layer wire that goes to wireshark, i am still receiving the > packets in wireshark like usual. But if i disable pdu out to wireshark > wire , i am not receiving the packets. pdu output pin is from app in > from Rime. So the output going from the pdu out to wireshark is before > modulation ?isn't it? or is the packet from pdu out to wireshark is > after modulation and demodulation from pdu in? why is the packets still > receiving on wireshark if i disable the wire that runs from rxout of PHY > Layer to wireshark. Please let me know if i need to ask the question in > more clear way. Looking forward for someone's help to clear this doubt > > Thanks and regards, > Ranganathan Sampathkumar -- Dr. Bastian Bloessl Secure Mobile Networking Lab (SEEMOO) TU Darmstadt, Germany www.bastibl.net GitHub/Twitter: @bastibl
Installing an old version of gnuradio
Hello, Thank you in advance for the help... I am trying to transmit a video wirelessly by using Gnuradio. However, some of the blocks that I want to use in my study are undefined. But, these blocks can be reached at older versions of Gnuradio. I followed the instructions given below web-site. But, I get some errors. I also give the error screenshot in below figure. Can you help me how to install gnuradio 3.7 version instead of 3.8 version? Thank you. Web-site: https://wiki.gnuradio.org/index.php/InstallingGR#To_install_system_wide [image: Screenshot from 2020-03-04 16-25-04.png]
Re: Installing an old version of gnuradio
Depends on the operating system you're running on. However, if the blocks have been removed in GNU Radio 3.8, they've been removed because they didn't work anymore, so you'll need to replace them either way. Best regards, Marcus PS: If you include as much info as possible in your original emails, it's easier to help you right away. On Wed, 2020-03-04 at 16:26 +0300, Ahmet DEMIR wrote: > Hello, > Thank you in advance for the help... > I am trying to transmit a video wirelessly by using Gnuradio. However, some > of the blocks that I want to use in my study are undefined. But, these blocks > can be reached at older versions of Gnuradio. I followed the instructions > given below web-site. But, I get some errors. I also give the error > screenshot in below figure. Can you help me how to install gnuradio 3.7 > version instead of 3.8 version? > Thank you. > Web-site: > https://wiki.gnuradio.org/index.php/InstallingGR#To_install_system_wide > smime.p7s Description: S/MIME cryptographic signature
Re: How to control span of the frequency sink?
Hello, The span of the frequency sink is determined by the sample rate of the signal that is input to it. In order to zoom in add a Resampler block in front and decimate by the zoom factor. Regards, Derek On 04/03/2020 16:42, Md. Atiqur Rahman wrote: Hello everyone, I have a question to ask. While using the QT GUI Frequency Sink, the y-axis means signal gain/power can be change with respect minimum and maximum. However, I need to change the span size of the x-axis, but I did not find the option. Can I change the span size manually? Would you like to give me a hint here? -- Sincerely, Md Atiqur Rahman Hochschule Bremen
Re: How to control span of the frequency sink?
Thank you so much for your response. This helped me. On Wed, Mar 4, 2020 at 5:52 PM Derek Kozel wrote: > Hello, > > The span of the frequency sink is determined by the sample rate of the > signal that is input to it. In order to zoom in add a Resampler block in > front and decimate by the zoom factor. > > Regards, > Derek > > On 04/03/2020 16:42, Md. Atiqur Rahman wrote: > > Hello everyone, > I have a question to ask. While using the QT GUI Frequency Sink, the > y-axis means signal gain/power can be change with respect minimum and > maximum. > However, I need to change the span size of the x-axis, but I did not find > the option. Can I change the span size manually? > Would you like to give me a hint here? > > -- > Sincerely, > Md Atiqur Rahman > Hochschule Bremen > > > -- Sincerely, Md Atiqur Rahman Hochschule Bremen
Re: DVB-T receiver problem (OFDM symbol acquisition)
Hello Ron, do you think it would be possible to use your block that detects the drift to adapt the sample rate of the source block automatically and if yes, how would I have to do that? When the position of the CP increases, the sample rate must be decreased and vice versa. Could it be done by a kind of feedback? This way it would not be necessary to implement the algorithm for DVB-T. Even if I would like to do this, due to my lack of knowledge I don't think that I would be able to. Sample rate correction solves my problem but in order to be useful, it would have to be done automatically. Thank you very much and kind regards, Ralf Am 02.03.2020 um 13:42 schrieb Ron Economos: 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
