[GRCon'23] Call for Participation for the GNU Radio Conference 2023

2023-05-12 Thread Marcus Müller

Dear Community,

GRCon'23 is happening in early September this year – so our submission deadlines are a bit 
tighter than usual.


Submission for talks, papers, workshops, and other contributions are accepted through the 
GRCon'23 website:


https://events.gnuradio.org/event/21/abstracts/

This call for participation closes on 5 June 2022!

A tiny bit about the GNU Radio conference:

GRCon is GNU Radio's annual conference, being held in changing cities in the U.S., and 
also live-streamed and chat-interacted online. Watching the main track online and 
interacting with the audience and speakers via chat are free. Registration for the 
in-person event started in March.


GRCon'23 happens 5 – 9 September in Tempe, Arizona at ASU.

What GRCon offers is a main track of presentations with topics on GNU Radio, applications 
of SDR / high-rate signal processing, computational radio science, scientific and industry 
developments, policy and technological breakthroughs.


Next to that, there's tutorials on specific topics, a poster session, Special Interest 
Groups and the developer's summit, which is the get-together for the project developers.

Oh, and of course, there's social events, happening at local highlight 
locations.

If you have *any* question (and I mean that – we're trying to make GRCon as accommodating 
as possible) about GRCon, be it about attendance, online participation, content submission 
or other problems related to the conference, we want you to reach out: Here on the mailing 
list, on the chat (https://chat.gnuradio.org), or in a private email to the GRCon 
organizers (gr...@gnuradio.org).


Now, clearly, this all requires significant funds to set up – with a history of more than 
300 in-person attendees prior to COVID (last year's in-person attendance was around 200 
attendees), and the live video streams achieving 3900 views last year, there's a large 
responsibility to organize a smooth conference and offer an excellent in-person and remote 
experience.


As in previous years, we do not intend to push all these costs onto the attendees alone 
(this year's tickets are cheaper than last year!); instead, it has proven mutually 
advantageous to have sponsors contribute to the conference, and be present in various 
forms to the audience. If your company is interested in reaching a high-profile, technical 
and social audience, please do see
https://events.gnuradio.org/event/21/page/106-sponsorship-opportunities and reach out to 
spon...@gnuradio.org .


Best regards, and: see you in person in Arizona or online in September,
Marcus



Detected an invalid packet at item

2023-05-12 Thread Hamed Al-Zubi
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