Last time I made the Si4432 communicate with the SX1231. This time I’ll take a look at its successor Si4463. While Si4432 implements a traditional register-style access, the Si4463 provides an “API”, which commands. There is a command to access properties, which are akin to registers, as-in you can set and get their values.

At first, I will attempt to communicate at the default bitrate (100 kbps) and frequency deviation (50 kHz). But first, we need to tune to a frequency. To tine to a frequency, we set the FREQ_CONTROL property. This contains an integer and a fractional part, which is multiplied to a prescaler (Npresc) and divided by a divisor (outdiv). The prescaler and divisor are found in the MODEM_CLKGEN_BAND property. The outdiv mentioned at the FREQ_CONTROL documentation is called band in the MODEL_CLKGEN_BAND property. The limitation of the fractional part of the FREQ_CONTROL register is that the MSB should be set. Otherwise the documentation does not mention any restrictions. So, why even bother with changing the outdiv if following the formula, we could tune the desired frequency by adjusting the FREQ_CONTROL alone? Well… it turns there are some unmentioned limitation. As per trial-and-error, I found the integer part to be within 53 and 74 to work.

The next thing of note is the SYNC word. As it turned out, the bytes of the sync word are transmitted in reversed order as compared to what is in the registers. The next thing to look at is the configuration of the fields of the packet. Here, I want “field 1”, the field transmitted right after the sync word, to be the size, as-in, the number of bytes of the payload that follows in field 2. It seems this is applied to the reception. For the transmission, unlike on the Si4432 where the size is written to a register, on the Si4463, one writes it to the FIFO like one does on the RX1231.

Once this works, looking at the data rate and the frequency deviation. The formulas from the documentation are straight to fill out, no surprised there. The last bit to tackle in this phase is the bandwidth filter. The documentation says “Silicon Labs has pre-calculated 15 different sets of filter tap coefficients. The WDS Calculator will recommend one of these filter sets, based upon the RX filter bandwidth required to receive the desired signal.” I guess that means I’ll have to request various values and analyse the generated code.

Initial tests show output like

	 // # WB filter 1 (BW =   9.54 kHz);  NB-filter 1 (BW = 9.54 kHz)
	 // # WB filter 2 (BW =  25.77 kHz);  NB-filter 2 (BW = 25.77 kHz)
	 // # WB filter 2 (BW = 137.42 kHz);  NB-filter 2 (BW = 137.42 kHz)

suggesting there are filters and multiplication factors for them similar to the filset and ndec_exp parameters seen on the Si4x3x. However, 137.42 / 25.77 does not give a power of 2. So it won’t be as simple as find a set of filter values, and doubling them.

I will have to take a closer look at the actual values to see what is actually going on here.

One other thing. I have noticed the auto-selected bandwidth is rather wide eg. selecting a 103.06 kHz bandwidth for a frequency deviation of 12.5 kHz. Where I would expect something like 25 kHz. It seems this is due the selected crystal accuracy, set to 20 ppm. When selecting a more accurate signal the selected bandwidth goes down. I did notice some frequency offset of the transmission frequency. I initially attributed this to an incorrect load capacitance, but it might as well be the accuracy itself.

Anyhow, this is for a later time to generate various bandwidth selections and analyse the generated code.