Save the output of Tag Debug to CVS file
Dears, I am working on GNURadio flowgraph where I use a Tag Debug block (https://wiki.gnuradio.org/index.php/Tag_Debug). In my grc-graph, the output of Tag debug is displayed on the command window as (I,Q) tuples. Can I save the output of the Tag debug displayed on the command into a cvs file? Thanks, HZ
Channel State Information of OFDM in gnuradio
Dears, I am doing some analysis on channel state information of OFDM signals. I used GNURadion rx_ofdm.grc (gnuradio/gr-digital/examples/ofdm at main · gnuradio/gnuradio) for signal transmission and reception through a channel model block. Then, the CSI has been extracted using Tag debug block. After that, I used matlab to plot the phase of pilot signals from csi. When I set the noise voltage on the channel block to zero, the phase of each pilot signal is constant. However, when I set the noise voltage to 100m, the phases of the pilot signals vary over time as shown in Fig. (phase_pilot). I used a moving average filter to mitigate the noise impact on the pilot phase. The results were better, but still there is a phase drop as shown in Fig. (phase_pilot_filter). As I read, the phase should be constant as long as the environment is static. So, why there is a phase drop? how that can be fixed? Thanks,HZ | | | | | | | | | | | gnuradio/gr-digital/examples/ofdm at main · gnuradio/gnuradio GNU Radio – the Free and Open Software Radio Ecosystem - gnuradio/gr-digital/examples/ofdm at main · gnuradio/gn... | | |
Detected an invalid packet at item
Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. packet_headerparser_b :info: Detected an invalid packet at item 167472header_payload_demux :info: Parser returned #f I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use.2- Multipath --> absorption boards were used to minimize the impact of multipath.3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ
Re: Detected an invalid packet at item
Hi Marcus, I am using GPSDO as a reference clock. I also increased the UHD gain of both TX and RX. The number of invalid packets was reduced, but still there is some invalid packets. Thanks, HZOn Saturday, May 13, 2023 at 04:36:10 AM CDT, Marcus Müller wrote: Hi Hamed, consider noise. Any real-world communication is subject to it. Another thing would be sample clock offset, which you could reduce if you clock both X300 from the same reference clock, or the Clock ref out on the back of the first X300 and connect it to the Clock ref in of the second, and set the clock source to "external". Also, good idea to isolate multipath effects, but don't forget that if your system can't deal with the multipath environment you're in, you've incorrectly designed your OFDM system. Best, Marcus On 13.05.23 02:09, Hamed Al-Zubi wrote: Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. packet_headerparser_b :info: Detected an invalid packet at item 167472 header_payload_demux :info: Parser returned #f I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use. 2- Multipath --> absorption boards were used to minimize the impact of multipath. 3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ
Re: Detected an invalid packet at item
Ed, I tried the NLOS scenario to avoid distortion, but still the same error occurs. Thanks!HZ On Saturday, May 13, 2023 at 11:07:22 AM CDT, Ed Criscuolo wrote: 2 meters seems like an incredibly short distance unless you have an attenuator in series with the Tx antenna. You may be overdriving the receiver and causing distortion errors. @(^.^)@ EdSent from my iPhone On May 12, 2023, at 8:10 PM, Hamed Al-Zubi wrote: Hello, I am utilizing two USRPs, specifically the X300 models, along with GNURadio for the purpose of transmitting and receiving OFDM signals. I have implemented the OFDM flowgraphs available on Github for this purpose. The transmission and reception setup involves LOS (Line-of-Sight) configuration, where the transmit and receive antennas are positioned with a separation distance of 2 meters. To minimize the impact of multipath interference, the antennas are surrounded by absorption boards. Although the transmission and reception process itself is functioning without issues, I have encountered a problem when displaying the channel state information. In particular, there are instances where invalid packets are detected, as evidenced by the following occurrences. packet_headerparser_b :info: Detected an invalid packet at item 167472header_payload_demux :info: Parser returned #f I have searched the possible causes of the error I'm encountering, and there are a few factors that have been suggested: 1- Interference--> I used different frequencies and ensured they are not in use.2- Multipath --> absorption boards were used to minimize the impact of multipath.3- Some people suggested to change the FFT length and CRC length as a potential solution, however, modifying these papermeters did not resolve the issue. When I used a channel model instead of USRPs, the error did not occur. I am still uncertain about the exact cause of the error I am experiencing. Thanks, HZ
Re: Detected an invalid packet at item
Johannes, Thanks for your reply! Occasionally, I encounter difficulties in retrieving the data when I send a text file and attempt to read it using the message debug feature on the receiving end. Regards,HZ On Monday, May 15, 2023 at 05:30:59 AM CDT, Johannes Demel wrote: Hi Hamed, you mentioned that increasing the TX and RX gain reduced the number of invalid packets. Still, as long as you transmit over an imperfect channel, there will be reception errors. The reports you receive stem from the logging system. They are tagged ":info:" because this might be an interesting information in some cases. However, this is not a software system error. This is a reception error and should be treated as such. You already mentioned a few channel effects that influence your reception: - multipath - interference I'd like to stress that: - noise - hardware imperfections - any unfortunate condition in your receiver chain may also affect your reception. The questions that arise are: - What do you want to fix here? - Did you observe anything that you didn't expect? Cheers Johannes On 14.05.23 05:33, Hamed Al-Zubi wrote: > > Ed, > > I tried the NLOS scenario to avoid distortion, but still the same error > occurs. > > Thanks! > HZ > On Saturday, May 13, 2023 at 11:07:22 AM CDT, Ed Criscuolo > wrote: > > > 2 meters seems like an incredibly short distance unless you have an > attenuator in series with the Tx antenna. You may be overdriving the > receiver and causing distortion errors. > > @(^.^)@ Ed > Sent from my iPhone > >> On May 12, 2023, at 8:10 PM, Hamed Al-Zubi >> wrote: >> >> >> Hello, >> >> I am utilizing two USRPs, specifically the X300 models, along with >> GNURadio for the purpose of transmitting and receiving OFDM signals. I >> have implemented the OFDM flowgraphs available on Github for this >> purpose. The transmission and reception setup involves LOS >> (Line-of-Sight) configuration, where the transmit and receive antennas >> are positioned with a separation distance of 2 meters. To minimize the >> impact of multipath interference, the antennas are surrounded by >> absorption boards. Although the transmission and reception process >> itself is functioning without issues, I have encountered a problem >> when displaying the channel state information. In particular, there >> are instances where invalid packets are detected, as evidenced by the >> following occurrences. >> >> *packet_headerparser_b :info: Detected an invalid packet at item 167472* >> *header_payload_demux :info: Parser returned #f* >> >> I have searched the possible causes of the error I'm encountering, and >> there are a few factors that have been suggested: >> >> 1- Interference--> I used different frequencies and ensured they are >> not in use. >> 2- Multipath --> absorption boards were used to minimize the impact of >> multipath. >> 3- Some people suggested to change the FFT length and CRC length as a >> potential solution, however, modifying these papermeters did not >> resolve the issue. >> >> When I used a channel model instead of USRPs, the error did not occur. >> I am still uncertain about the exact cause of the error I am experiencing. >> >> >> Thanks, >> HZ
USRP X300 Synchronization
Hello Dears, I would like to inquire about the synchronization of two USRPs X300, one acting as a transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the same laptop, I'm wondering if the accuracy provided by PC clock synchronization is similar (or close) to that achieved through GPSDO synchronization? Regards, HZ
Re: USRP X300 Synchronization
Thanks for your response, Marcus! I have observed a constellation rotation for OFDM subcarriers when I use the PC clock for synchronization. However, by using the channel model, I am able to see the QPSK constellation. Thanks!HZ On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller wrote: No, it's several orders of magnitude worse and generally insufficient for anything where you need synchronization. Best, Marcus On 18.05.23 17:12, Hamed Al-Zubi wrote: Hello Dears, I would like to inquire about the synchronization of two USRPs X300, one acting as a transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the same laptop, I'm wondering if the accuracy provided by PC clock synchronization is similar (or close) to that achieved through GPSDO synchronization? Regards, HZ
Re: USRP X300 Synchronization
Actually, I don't know. I thought that by using PC clock in UHD sink and source block in gnuradio allows synchronization. Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM receivers. On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller wrote: Any OFDM receiver needs a timing recovery method anyways, so that has nothing to do with how well your PC is suitable for synchronizing two devices. On 18.05.23 17:43, Hamed Al-Zubi wrote: > Thanks for your response, Marcus! > I have observed a constellation rotation for OFDM subcarriers when I use the > PC clock for > synchronization. However, by using the channel model, I am able to see the > QPSK > constellation. > > Thanks! > HZ > > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller > wrote: > > > No, it's several orders of magnitude worse and generally insufficient for > anything where > you need synchronization. > > Best, > Marcus > > On 18.05.23 17:12, Hamed Al-Zubi wrote: > Hello Dears, > > I would like to inquire about the synchronization of two USRPs X300, one > acting as a > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are > connected to the same > laptop, I'm wondering if the accuracy provided by PC clock synchronization is > similar (or > close) to that achieved through GPSDO synchronization? > > Regards, > HZ
Re: USRP X300 Synchronization
So, I have to get GPS modules and use GPSDO synchronization. On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller wrote: On 18.05.23 18:10, Hamed Al-Zubi wrote: Actually, I don't know. I thought that by using PC clock in UHD sink and source block in gnuradio allows synchronization. Not in a way meaningful for synchronizing transceivers, no. Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM receivers. Exactly, that's why your PC clock synchronization would contribute nothing, even if it was more accurate. You just don't benefit from synchronization. On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller wrote: Any OFDM receiver needs a timing recovery method anyways, so that has nothing to do with how well your PC is suitable for synchronizing two devices. On 18.05.23 17:43, Hamed Al-Zubi wrote: > Thanks for your response, Marcus! > I have observed a constellation rotation for OFDM subcarriers when I use the PC clock for > synchronization. However, by using the channel model, I am able to see the QPSK > constellation. > > Thanks! > HZ > > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller wrote: > > > No, it's several orders of magnitude worse and generally insufficient for anything where > you need synchronization. > > Best, > Marcus > > On 18.05.23 17:12, Hamed Al-Zubi wrote: > Hello Dears, > > I would like to inquire about the synchronization of two USRPs X300, one acting as a > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the same > laptop, I'm wondering if the accuracy provided by PC clock synchronization is similar (or > close) to that achieved through GPSDO synchronization? > > Regards, > HZ
Re: USRP X300 Synchronization
Okay. I need to figure out how can I do that. Thanks! HZ On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller wrote: No, that's the opposite of what I said. (also, why would you need a GPSDO when these USRPs are colocated?) You *always* have time offset at a receiver – due to the finiteness of the speed of light. So, *any* working receiver you have has to have timing recovery, there's no way around it. So, getting better hardware-level synchronization *does not help you at all*. Not if you do it badly, not if you do it really really well. Best, Marcus On 18.05.23 18:21, Hamed Al-Zubi wrote: So, I have to get GPS modules and use GPSDO synchronization. On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller wrote: On 18.05.23 18:10, Hamed Al-Zubi wrote: Actually, I don't know. I thought that by using PC clock in UHD sink and source block in gnuradio allows synchronization. Not in a way meaningful for synchronizing transceivers, no. Also, I thought that Schmidl and Cox algorithm used for timing recovery in OFDM receivers. Exactly, that's why your PC clock synchronization would contribute nothing, even if it was more accurate. You just don't benefit from synchronization. On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller wrote: Any OFDM receiver needs a timing recovery method anyways, so that has nothing to do with how well your PC is suitable for synchronizing two devices. On 18.05.23 17:43, Hamed Al-Zubi wrote: > Thanks for your response, Marcus! > I have observed a constellation rotation for OFDM subcarriers when I use the PC clock for > synchronization. However, by using the channel model, I am able to see the QPSK > constellation. > > Thanks! > HZ > > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller wrote: > > > No, it's several orders of magnitude worse and generally insufficient for anything where > you need synchronization. > > Best, > Marcus > > On 18.05.23 17:12, Hamed Al-Zubi wrote: > Hello Dears, > > I would like to inquire about the synchronization of two USRPs X300, one acting as a > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are connected to the same > laptop, I'm wondering if the accuracy provided by PC clock synchronization is similar (or > close) to that achieved through GPSDO synchronization? > > Regards, > HZ
Re: USRP X300 Synchronization
I use the Shmdil and Cox gnuradio block and it does time recovery based on what I have read. I also can retrieve the transmitted data. But what I am confused about the presence of constellation rotation when I used the USRP. On Thursday, May 18, 2023 at 12:32:22 PM CDT, Marcus Müller wrote: Your OFDM receiver already does Schmidl&Cox, I thought? So, if you correctly designed the length of your OFDM symbols and the subcarrier spacing, that should be sufficient. What you described, a "constellation rotation for OFDM subcarriers" is unproblematic; you're doing subcarrier-wise multiplication with the inverse of your channel estimate, anyways, and that cancels that. Best regards, Marcus On 18.05.23 19:08, Hamed Al-Zubi wrote: > Okay. I need to figure out how can I do that. > > Thanks! > HZ > > On Thursday, May 18, 2023 at 11:54:42 AM CDT, Marcus Müller > wrote: > > > No, that's the opposite of what I said. (also, why would you need a GPSDO > when these USRPs > are colocated?) > > You *always* have time offset at a receiver – due to the finiteness of the > speed of light. > > So, *any* working receiver you have has to have timing recovery, there's no > way around it. > So, getting better hardware-level synchronization *does not help you at all*. > Not if you > do it badly, not if you do it really really well. > > Best, > > Marcus > > On 18.05.23 18:21, Hamed Al-Zubi wrote: > > So, I have to get GPS modules and use GPSDO synchronization. > > > > On Thursday, May 18, 2023 at 11:20:02 AM CDT, Marcus Müller > > <mailto:marcus.muel...@ettus.com> wrote: > > > > On 18.05.23 18:10, Hamed Al-Zubi wrote: >> Actually, I don't know. I thought that by using PC clock in UHD sink and >> source block in >> gnuradio allows synchronization. > Not in a way meaningful for synchronizing transceivers, no. >> Also, I thought that Schmidl and Cox algorithm used for timing recovery in >> OFDM receivers. > Exactly, that's why your PC clock synchronization would contribute nothing, > even if it was > more accurate. You just don't benefit from synchronization. >> >> On Thursday, May 18, 2023 at 10:46:38 AM CDT, Marcus Müller >> >> <mailto:mmuel...@gnuradio.org> wrote: >> >> >> Any OFDM receiver needs a timing recovery method anyways, so that has >> nothing to do with >> how well your PC is suitable for synchronizing two devices. >> >> >> On 18.05.23 17:43, Hamed Al-Zubi wrote: >> > Thanks for your response, Marcus! >> > I have observed a constellation rotation for OFDM subcarriers when I use >> > the PC clock for >> > synchronization. However, by using the channel model, I am able to see the >> > QPSK >> > constellation. >> > >> > Thanks! >> > HZ >> > >> > On Thursday, May 18, 2023 at 10:35:01 AM CDT, Marcus Müller >> > > <mailto:marcus.muel...@ettus.com>> wrote: >> > >> > >> > No, it's several orders of magnitude worse and generally insufficient for >> > anything where >> > you need synchronization. >> > >> > Best, >> > Marcus >> > >> > On 18.05.23 17:12, Hamed Al-Zubi wrote: >> > Hello Dears, >> > >> > I would like to inquire about the synchronization of two USRPs X300, one >> > acting as a >> > transmitter (Tx) and the other as a receiver (Rx). If both USRPs are >> > connected to the >> same >> > laptop, I'm wondering if the accuracy provided by PC clock synchronization >> > is similar (or >> > close) to that achieved through GPSDO synchronization? >> > >> > Regards, >> > HZ >>
