On Thursday, July 30, 2020, 12:58:30 PM EDT, Tim Huggins <huggins.timothy@yahoo.com> wrote:
If I understand the underlying python for the OFDM Transmitter block and the OFDM Receiver block, they booth make calls to the OFDM Carrier Allocator block so it doesn't appear if the issue is there. The final difference seems to be that the tx_ofdm.grc uses a Protocol Formatter block and calls digital.header_format_ofdm while the other three blocks use digital.packet_header_ofdm and at least the OFDM Transmitter block looks like it uses digital.packet_headergenerator_bb instead of the Protocol Formatter but I haven't had any luck modifying the tx_ofm.grc to use the packet header generator instead yet.
On Wednesday, July 29, 2020, 3:28:04 PM EDT, Tim Huggins <huggins.timothy@yahoo.com> wrote:
I'm not certain if this data point helps at all, but I can make the above changes (also turning on the QT GUI and adding the QT GUI Time sync) to the rx_ofdm.grc example and still decode the data correctly. My intuition has me looking at the OFDM Carrier Allocator block to see if there is any reason that the Occupied Carrier seems to work best with multiples of 8 carriers. Thank you for all the help so far.
On Wednesday, July 29, 2020, 6:26:45 AM EDT, Jeff Long <willcode4@gmail.com> wrote:
Martin says the allocator has no alignment requirement, so this is likely due to alignment requirements in the example itself.
On Tue, Jul 28, 2020 at 4:42 PM Jeff Long <willcode4@gmail.com> wrote:
Looks like an alignment issue. If you take 4 subcarriers off each end:(list(range(-22, -21)) + list(range(-20, -7)) + list(range(-6, 0)) + list(range(1, 7)) + list(range(8, 21)) + list(range(22, 23)),)or the same number out in a different way:(list(range(-26, -25)) + list(range(-20, -7)) + list(range(-6, 0)) + list(range(1, 7)) + list(range(8, 21)) + list(range(26, 27)),)then it works. Someone else might know whether the allocator is supposed to handle arbitrary numbers of occupied subcarriers, or whether it has to be a multiple of 8 or something like that.On Tue, Jul 28, 2020 at 4:26 PM Jeff Long <willcode4@gmail.com> wrote:Ok, I see the same thing and haven't figured it out either.On Tue, Jul 28, 2020 at 3:53 PM Tim Huggins <huggins.timothy@yahoo.com> wrote:The signal looks correct, but the plots change from this:to this:Maybe the issue is not with the actual chain, but potentially how I am displaying the results?On Tuesday, July 28, 2020, 3:44:52 PM EDT, Jeff Long <willcode4@gmail.com> wrote:I plugged the shorter list into the occupied_carriers variable in tx_ofdm.grc on 3.8.1.0 and saw what looked like a reasonable signal.On Tue, Jul 28, 2020 at 3:27 PM Tim Huggins <huggins.timothy@yahoo.com> wrote:I am trying to understand the OFDM examples and I'm quickly running into an issue. I was successfully able to modify the occupied carriers in the ofdm_loopback.grc example, however when I copy these changes to the tx_ofdm.grc or rx_ofdm.grc I do not see data on coming out of either the OFDM Receiver (tx_ofdm.grc) or the Stream CRC32 block (rx_ofdm.grc). I have attached a UChar To Float which is connected to a QT GUI Time Sink to view the data (mimicking the loopback example).For example tx_ofdm.grc sets occupied_carriers to:(list(range(-26, -21)) + list(range(-20, -7)) + list(range(-6, 0)) + list(range(1, 7)) + list(range(8, 21)) + list(range(22, 27)),)or([-26, -25, -24, -23, -22, -20, -19, -18, -17, -16, -15, -14, -13, -12, -11, -10, -9, -8, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26],)Modifying this to(list(range(-25, -21)) + list(range(-20, -7)) + list(range(-6, 0)) + list(range(1, 7)) + list(range(8, 21)) + list(range(22, 26)),)or([-25, -24, -23, -22, -20, -19, -18, -17, -16, -15, -14, -13, -12, -11, -10, -9, -8, -6, -5, -4, -3, -2, -1, 1, 2, 3, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 24, 25],)results in only zero being displayed. What am I overlooking that results in the data not making through the examples?Thank you,Tim
