Re: Detected an invalid packet at item
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
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
Resource issues when trying to record 2 FM broadcast stations
I haven't spent a whole lot of time working with gnuradio. I'm not a DSP engineer. I am however a software engineer that has dealt with signals so not completely a laymen, but I am out of my comfort zone. I had successfully created this project about 4 years ago using Marcus Leech's Stereo FM Radio implementation and grafting it into the front design of this the multiple station receiver design. Described here https://forums.radioreference.com/threads/multiple-fm-station-receiver.341340/#lg=_xfUid-2-1556650274&slide=0 I recorded 2 pirate radio stations at a 4 day music festival. Started the recording on Thursday. Stopped it on Sunday. The sample rate was 2.4M. I created an Heir block that had the appropriate parts of Marcus Leech's Stereo FM radio in it. and replaced everything from the xlating FIR to the multiply const in the second block figure above with the heir block, and added some WXQT blocks to handle the gui for 2 stations like wav sinks, file names, etc. It was successful, but one thing that did happen was I needed to go from a Acer 720 (celeron) with Gallium installation to an (older) I5 laptop. I let that project sit for a couple of years. The first thing I did when I got back to it was upgrade everything. Big mistake... Nothing worked after that. I got grc 3.10 running with radioconda. I swapped Marcus's implementation out for Zan's fm_stereo_demod_clean https://forums.radioreference.com/threads/multiple-fm-station-receiver.341340/#lg=_xfUid-2-1556650274&slide=0 http://zansprojects.blogspot.com/2019/05/stereo-fm-receiving-with-rtl-sdr-and.html In this new implementation I needed to create a series of variables to handle the design issue of having the signal be a multiple of 48k for the audio sink to be the correct speed. In particular the decimations in the rational resampler.This worked, but when I changed the sample rate to widen the bandwidth to receive 2 stations further apart on the FM band than 1Mhz I ran into performance issues. Basically with my setup the CPU load is about 90% with a sample rate of 1.24 Mhz. I was able to do this because of the great work done by the people mentioned above, but figuring out how to deal with the performance issues is kind of beyond the disciplines I am familiar with. I am wondering if anybody has any suggestions on how to get fm_stereo_demod_clean to have better performance. I did not see an updated version of the Marcus Leech design so I figured there was something blocking that update, but maybe that is incorrect. I am also wondering if I could get a more powerful laptop/NUC and make it work with brute force by throwing money at the project. I would love to hear any suggestions from people with more grc and dsp experience, or which path I should take now. Thanks in advance Marty
Re: Detected an invalid packet at item
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
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
