Hope pictures below give more context. Has anyone seen this happen before?
To reword the part of our question about constellation plots a little, does anyone know when the constellation block would output just four single points?
The problem we’re currently facing is that the constellation plot does not even really show up - there’s not even a giant blob to indicate noise. Instead, we get only 4 points, one in each of the four locations you’d expect for a QPSK signal - but only those 4 points. It almost feels like the constellation plot stops triggering after these first four points, and that’s why we don’t receive anymore data. We’re using a free trigger on the positive slope, centered at 0, which I feel should trigger at least something even if it’s just noise. We have also tried other trigger methods, which output either 4 points, 5 points (1 additional point in the center), or just 1 center point.
On Mon, Apr 18, 2016 at 5:01 PM, Jingyi Sun <address@hidden> wrote:
We are not compensating for any lost packets, although we would be aware of them thanks to the packet number. Could you tell us if there’s a block to do this, or would we need a custom block?
Also, could you tell us why the constellation diagram is not displaying properly?
Thanks,
Jenny
On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun <address@hidden> wrote:Are you comparing the correct packets? E.g., if packets get lost, do you
take that into account?
M
On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> Hi everyone,
>
> We are working on an experiment for a conference paper deadline in two
> weeks, and need to transmit and receive OFDM packets and want to study
> the constellation diagram and BER.
>
> I put together a flow graph consisting of an *OFDM transmitter block*
> and an *unpacked OFDM receiver* based on the online example rx_ofdm.grc.
> Here's how I'm trying to measure constellation diagram and BER:
>
> * I inserted a QT constellation sink right before the constellation
> decoder on the payload IQ stream, but it does not seem to output
> anything meaningful. The plot just shows single, clean points, which
> I am pretty sure does not correspond to real data. I suspect that
> the plots are not triggering properly, but am not sure.
>
> * For BER, we tried several different configurations, and they mostly
> give BER = 0.5 (i.e. random). Our leading theory is that we're not
> comparing the data at the correct points in the flow graph. Any
> suggestions as to what the BER inputs should be would be helpful.
>
> We've been running some diagnostics that seem to eliminate our
> communication channel as the problem:
>
> * We are transmitting the data over-the-air at 915 MHz using
> two omnidirectional antennas, placed roughly 1 meter apart. The
> output spectra at the transmitter output and receiver input are
> attached - all signals are comfortably above the noise floor.
> * From the tag debug output, we see that the OFDM packet headers are
> being received. For example, we can see when the packets are
> received, the packet numbers, as well as the channel estimation tap
> values. We take this to mean that we are receiving data
> successfully, and that our difficulties regarding BER and
> constellation diagram are something we're executing incorrectly in
> the software.
>
>
> The relevant annotated GRC block diagrams are attached.
>
> Thanks so much,
> Jenny
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio