Hi Nurullah,

Latching RSSI on preamble detect only makes sense in packet mode operation. Don’t use them in direct mode applications. Or are you using FIFO Direct Mode? (It is described in section 4.2.2.2 of https://www.silabs.com/documents/public/data-sheets/Si4463-61-60-C.pdf ) Then see the introduction section of https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2014/08/08/rssi_accuarcy_onsi4-qmkw

Regards,

Tamás

I see that he PHY 868 2GFSK 38.4 Kbps 20 kHz has an OBW (99.9%) of 89 kHZ. This is more strict than the ETSI definition (99%). Checked on a dev board BRD4163A. So from our side the PHY is good as the carson's rule (99% OBW) says 2x dev + DR = 79 kHz.

The only overlapping range is 235-239 MHz for Si4464. If you check in WDS a single frequency in the middle e.g. 237 MHz, you can see that OUTDIV16 is used in this range. All the other bands are defined explicitly in the OUTDIV table referenced previously. 

Yes, including the POR values is the safe solution.

Tamás

See https://www.silabs.com/community/wireless/proprietary/forum.topic.html/use_si4432_and_si4463together-p6UG

See https://www.silabs.com/community/wireless/proprietary/forum.topic.html/use_si4432_and_si4463together-p6UG

Andrew,

You have to re-run ircal at the frequency where you (WDS) switches to a different outdiv.

What you write about the sections of the config data array is true, but note that the initial state of the properties are the POR default values. So if you want to reconfigure the radio later for a different band without POR, first you have to take into account that the initial state is not the POR state anymore. You can set in WDS if the POR default values should be part of the generated config or not.

An example of possible optimization is, that if you are using the same CRC config in each band, you don't have to rewrite it when switching bands without POR.

Tamás

Hi Hamza,

The documentation of RAIL_AutoAckConfig_t structure's documentation can be found here. 
Did you enable RAIL_EVENT_RX_ACK_TIMEOUT event by the RAIL_ConfigEvents() API?

Best Regards,
Bence

Hi,

The API documentation available in HTML form only.

BR,

/sza2

Hi Saeid,

The Si4432 compatible whitening settings of the Si4463 are

Polynom: PN9: PKT_WHT_POLY = 0x0108

Seed: 0x010F

Output: 0x07

In Si4463 there is no dedicated header. To handle portions of the packet differently, you can define fields. See https://www.silabs.com/documents/public/application-notes/AN626.pdf for details.

Regards,

Tamás 

Hi,

I suppose this issue is permanent and not intermittent.

Are you aware that replay stream of most API commands can be read via a separate command called  READ_CMD_BUFF?

See also timing requirements at https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2017/04/06/si4x6x-c2a_si4x55-c-8Lg0 and startup sequence on page 25. of https://www.silabs.com/documents/public/application-notes/AN633.pdf

Make sure also that your crystal works properly. It is recommended to test your startup code on a known good eval board first,to be shure the issue is SW related.

Regards,

Tamás