my chip model: efr32fg12p431. I use OQPSK modulationtype + DSSS symbol coding. When I configure radio at 434MHz, everything is fine in transmit and receive. But when I modify the Base Channel Frequency to 350MHz (no other configuration item is modified), wireless transfer fails. The receiver does not even trigger any RAIL event like RAIL_EVENTS_RX_XXX, RAIL_EVENT_RX_PREAMBLE_DETECT or RAIL_EVENT_RX_PREAMBLE_LOST.
So I use specturm analyzer to examine the transmitting signal. I found that when I configure frenqency is at 350MHz, the RF signal is likely be filtered by a narrow band filter, meanwhile is OK at 434MHz with no other configuration changed.
Here is the two spectrum(434MHz above and 350MHz below)
My PHY configuration:
Did I miss or make mistakes with some configurations?
1) Disable all the advanced configuration options. Let the configurator calculate those fields.
2) Don't use a Gaussian filter with OQPSK, use no filter or custom OQPSK.
Give these two changes a try and let me know how it's gone.
Thanks for your reply.
I disable all advanced configuration, and tried NONE and custom OQPSK filter respectively. It does not work. The spectrum is still likely to be filtered by a super narrow band pass filter.
I tried to modify configuration item 'PLL Bandwidth in TX mode' / 'PLL Bandwidth in RX mode', changle them from BW_2520KHz to BW_250KHz at 434MHz, the TX signal does differ from each other. When it set to BW_250KHz, tx signal has a quicker amplitude falling along with frequency offset away from the center frequency 434MHz compared to BW_2520KHz setting.
Still, the spectrum in BW_250KHz is more like a Fujiyama mountain (in Japan) which has a flat top. So I feel so strange that why the spectrum of tx signal is 350MHz has the shape of a sharp blade? I think it's harder to implement such a super narrow band pass filter even if it is intend to.
I had a closer look and this is indeed a bug. MSK/OQPSK modulation is not correct in this frequency band. I am pushing for a Q2 fix on this. This means a June/July schedule.
It is a SW bug.
Did the OQPSK modulation get corrected in Q2 after all?
No, sorry. The cogwheels are turning slower than i thought.
However, here is a workaround for MSK:
1) At the Tx side use FSK with a modulation index of 0.5 (deviation is 1/2 th of the DR).
2) At the Rx side configure MSK for best sensitivity.
These will be two different PHYs for Tx and Rx so do use the multi PHY configurator.
I cannot give you a workaround for OQPSK but as far as performance is concerned it is the same as MSK so you may use MSK unless your hands are tied for OQPSK.
All above said I'll keep pushing the fix.