If HW reset was not initiated when powering up the device, proper operation is not guaranteed.

It depends on the PHY used in your design. There is a big overlap of RF capabilities of the two device. 

On higher level, there is no communication stack provided by Silicon labs for the Si1064.

Can you please add some comments to your dump?

Hi Stephan,

I agree with you, the root cause of this issue was the incorrect crystal frequency configuration.

However I would like to exclude that the data rate error tolerance depends on the SPI timing, that we could not reproduce.

I do not expect from you to review your measurements, but it seems to me that your two sets of data were taken with different configuration. In longpacketrx-ok.logicdata the RX_DATA_CLK frequency seems to be 1.2kHz while in longpacketrx-fail.logicdata it seems to be 1.24kHz. This corresponds about the ratio of the two crystal frequencies you were testing. The jitter of RX_DATA_CLK and surplus data bits are caused by the clock recovery circuit that tries to align the clock edges with the edges of the demodulated RX raw data. RX_RAW_DATA is also available for observation on a GPIO.

Regards,

Tamás

Hi Bence,

I have to apologize: I made a mistake with the chip configuration.

We were evaluating the use of a slightly different crystal frequency (29.1MHz instead of 30MHz). In the course of this, the MODEM_* properties got mixed up. That is, we were using the settings meant for the 29.1MHz oscillator with the 30MHz oscillator on the evaluation board.

The effect would be similar to what you are saying about a wrong TX data rate.

Still, there is an influence from the SPI timing:

With the wrong MODEM settings and a short NSEL low time, the bits are still read correctly (11110000...)

With the wrong MODEM settings and a long NSEL low time, there are additional 1 or 0 bits.

I'm not sure I understand your description of the two scenarios you did - maybe you're saying the exact same thing?

In any case our transmitters are expected to be accurate within 100ppm. So with the correct settings, this strange behaviour of the chip should not cause any issues.

Thank you for your help

--Stephan W.

Hi Stephan,

I'd made a reproducer project, but I wasn't able to reproduce the issue. However, it helped me to find out, what's the case with your application: I had a very inaccurate clock signal to feed my TX radio to send out the 11110000 stream. On the RX side I've used the configuration you gave, and I varied the NSEL pin's low duration up to 2 ms (and read 8 byte from the RX FIFO on the middle of this period), as I saw in your logic capture. It worked as expected, but the 8 bytes weren't the same, it shifted due to inaccurate signal. I saw that the data was correct setting up a new SPI analyzer on the RX_DATA as MISO or MOSI, RX_DATA_CLOCK as SPI clock and SCLK as SPI enable signal (I've used here your labels coming from the logic captures). 

Then I set up the same SPI analyzer on your captures, and I got the same result: the demodulated signal is read from your RX FIFO correctly. Can you check it, whether the issue caused by the imperfection of the transmitted signal?

Best Regards,
Bence 

As a summary, it is highly recommended to implement a way for the host MCU to initiate HW reset of the radio.

Hi Sinsan,

Since this chip has no software reset from SPI, you may need SDN pin to initiate HW reset.

You can do it with power cycle on VDD as well, but you have to meet the VDD voltage power up timing requirements of the datasheet. See page 16 of https://www.silabs.com/documents/public/data-sheets/Si4362-C.pdf

Regards,

Tamás

We recommend you to recalibrate the VCO after a relative 15 degree Celsius temperature change in the radio. It can be done by exiting and reentering RX state.
Regardless of the temperature it is generally a good practice to check regularly if the radio is able to receive and/or to reset/reinitialize it. 

Regards,

Tamás

The content of the array is the radio configuration. You can access separately and change on the fly only the properties that are documented in the API description,

see at  https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2019/09/18/si4x5x_ezradio_apiguide-4upO

The array is generated by WDS from your GUI inputs, no other way to change it's content. If it is a limitation in your use case, you can switch to the Si446x family.