Re: Detected an invalid packet at item
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 smime.p7s Description: S/MIME Cryptographic Signature
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
NEWSDR 2023 on Friday June 2 at WPI in Worcester, MA (in less than 3 weeks!)
The New England Workshop on Software Defined Radio (NEWSDR) will be hosted in-person at Worcester Polytechnic Institute (WPI) in Unity Hall on Friday June 2, in Worcester, Massachusetts. There will be great sponsorship from MathWorks, NI (National Instruments), TMY Technology, and Red Wire Technologies, awesome invited speakers Muriel Medard (Massachusetts Institute of Technology (MIT)) and Tommaso Melodia (Northeastern University (NEU), Institute for the Wireless Internet of Things (WIoT)), a great line-up of afternoon breakout sessions on ChatGPT for software radio development, and prototyping with latest software tools, and spectrum discussions from a science perspective, and exciting tutorials sessions scheduled the evening before on Thursday June 1. Please note that NEWSDR will not be recorded or live-streamed this year. The event is free, but advance registration is required. We are still looking for poster presentations for the networking sessions. Please visit our website at the link below to see the full event agenda as well as to register for free. http://newsdr.org/workshops/newsdr2023/
Re: Resource issues when trying to record 2 FM broadcast stations
Hi Martin, On 13.05.23 17:40, Martin Lefkowitz wrote: I haven't spent a whole lot of time working with gnuradio. Well, then: Welcome to the GNU Radio community! 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. Let's rephrase this: Welcome to the GNU Radio community, the newly-found extension of your 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 Looks fine :) You could have also absorbed the 1/4-resampler into the freq xlating FIR filter (by setting the decimation to 4), but the only benefit of that would have been slightly reduced computational load. For a bit of documentation on the Frequency XLating FIR Filter: https://wiki.gnuradio.org/index.php?title=Frequency_Xlating_FIR_Filter (the top right spectrum diagram I think explains quite nicely what I mean with "let the Xlating FIR filter also do the decimation" :) ) 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. Well, WX GUI was indeed removed a couple of years ago, as we had nobody that knew how to fix its bugs anymore. But for your purposes, Qt GUI should offer a drop-in replacement. The rest of the blocks should be the same as in the GNU Radio 3.7 era, no? 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. Could you really share your flow graph with us? This is a bit strange to understand by reading about modifications on a 3.7-era (so, obsolete) blog post of someone else - I'd much rather analyze your flow graph than someone else's :) 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. These sound likely to be caused by switching to that other flow graph and using inelegantly related sampling rates or filter bandwidths, but I can really only speculate without seeing your flow graph :) 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. Don't think so. All that might have happened is that Marcus (Leech, aka. the Marcus the Wiser) didn't have the time (or energy, or attention …) to port that. Matter of fact, we have a – hopefully sensibly working – example in our wiki of a single-station stereo FM receiver. Should work out of the box, no need to recreate Marcus L's hier block to get stereo: https://wiki.gnuradio.org/index.php?title=WBFM_Receive_PLL Combine that with your original Freq' Xlating FIR approach, and it *should* work :) 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. This should technically work on a slightly overprovisioned toaster microcontroller, so I don't think that'll be necessary :) Let's have a look at your flow graph together :) Best regards, Marcus
