In our application we need to demodulate proprietary constellation. It consist a different slicing than ordinary QPSK with differential coding.
We are using the EFR32 Mighty Gecko MG12
We saw there are two special data sources.
1. RX_DEMOD_DATA - in some references it states that this data is 1B each sample "Before Slicing". Does it means it is the quadrature coordinate after AGC,AFC and phase correction? if yes how does the coordinate represented ?
2. RX_IQDATA_FILTLSB - This allow us to do our proprietary slicing , but does in this mode the IQ samples are after the AGC,AFC, and matched filter? What is the maximal samples per second we can get ?
Is there other option we have'nt mentioned to do a custom slicer application?
1. The RX_DEMOD_DATA in case of OQPSK holds the zero-IF signal's phase in degrees, and as it is represented in 8 bits, it can over- and underflow on the extrema. You are right, it is the signal after AFC and AGC operation takes place.
2. The RX_IQDATA_FILTxSB signal sources tap the IQ signal stream before the signal is being converted into polar coordinates, but after the AGC and AFC. The sample-frequency depends on the actual PHY, and the actual rate can be seen in the efr32_radio_configurator_log.txt log file as Actual sample frequency. I don't know the maximum sample rate, but I believe this will be limited by the slicer algorithm you will have not the radio's capability.
I don't know any other possibility to get one kind of "pre-demodulated" signal to do the custom slicing.
We have troubles with RX_DEMOD_DATA -
Does the data is filled in the data rate or it is oversampled?
If it oversampled what is the Over sampling factor? in addition the eight bits - in what representation is it? 2's complement? unsignd integer?
We would appreciate your fast response,
It is oversampled, but as far as I know it is not indicated in the log file nor can be precisely calculated by the radio configuration GUI's inputs. Therefore the oversampling ratio should be measured. I use to calculate it by measuring the time between two consecutive RAIL_EVENT_RX_FIFO_ALMOST_FULL events; the measured time should be divided by the number of bytes read out from the RX FIFO (use RAIL_ReadRxFifo instead of clearing the FIFO by the RAIL_ResetFifo). For more accurate result you can either increase the RX FIFO's length or calculate it over multiple radio events.
The representation of the RX_DEMOD_DATA is 2's complement, so it might be negative.