Are Si443x and Si446x families of chips both capable of operation in Raw Data mode?
Yes, but the two families of chips handle Raw Mode in a different manner.
The Si443x family of chips was optimized for reception of a conventional packet structure that contains a standard Preamble '101010...' pattern, followed by a Sync Word and Payload. The RX Modem within the chip attempts to lock a locally-created RX bit clock against the received data stream, such that there is a 1-to-1 one relationship between the frequency of the RX bit clock and the incoming data rate. Acquisition of the bit timing is performed during the Preamble and thus depends heavily upon the presence of a standard Preamble pattern.
However, not all "legacy" packet structures contain a standard Preamble, making it difficult for Si443x chips to acquire proper RX bit clock timing. As a result, Si443x chips may be configured for an alternate configuration of the RX Modem known as "Raw Mode". In this mode of operation, the chip no longer attempts to maintain a 1-to-1 relationship between the frequency of the local RX bit clock and the received data rate; instead, the local RX bit clock is operated at a highly oversampled rate. As a result, the chip cannot use FIFO mode but instead must use Direct mode, where the RXDATA stream is output in real time on a physical GPIO pin for subsequent processing by a host MCU. Additionally, that real-time RXDATA stream may contain "glitches" at the transitions of the data bits, as each received data bit is now output as multiple data samples. It is usually necessary for the host MCU to apply a de-glitching algorithm on the RXDATA stream to recover the actual data stream.
The Si446x family of chips can receive the same legacy packet structures as the Si443x family of chips (and usually with better performance!), but accomplishes the reception in an entirely different fashion. As the Si446x chips can continue to receive the same packet structures that were handled by Raw Mode in Si443x chips, this mode of operation is often referred to as Raw mode in Si446x chips as well. Technically speaking, the meaning of Raw Mode is quite different between the two chip families; however, the intent of retaining the term "Raw Mode" is to ensure customers that Si446x chips can also receive the legacy packet structures.
Si446x chips contain an additional type of demodulator (not present in Si443x chips) that Silicon Labs refers to as the Asynchronous Demodulator. This Async Demod circuit block is capable of properly acquiring bit timing on packet structures that do NOT contain a standard Preamble pattern. Si446x chips can receive the same legacy packet structures but without needing to configure the RX Modem for highly over-sampled operation. As a result, Si446x chips can continue to provide a local RX bit clock that is locked to the data rate of the incoming data stream in a 1-to-1 frequency relationship. This is a significant advantage of the Si446x family of chips.
Configuration of Si443x chips for Raw Mode operation is a rather complex process and specific to the selected data rate; a discussion of Raw Mode for Si443x chips may be found within app note AN463. Configuration of Si446x chips to receive "Raw Mode" legacy packets is handled automatically within WDS as a result of properly describing the packet structure.
Can I configure Si446x chips to identify both a unique Node Address as well as a Broadcast Address?
Yes, but with certain limits on the number of bytes in the address.
The Si446x family of chips provides for matching up to 4 address or header byte locations, with (potentially) four different matching values. The configuration of these matching bytes is performed within the MATCH property group. The important thing to understand is that matching one header byte location against multiple matching values requires configuration of multiple MATCH properties.
As an example, the user could potentially configure the chip to look at only one header byte, but to compare it against four different match values. This would require use of all four MATCH byte properties. Or alternatively, matching two header byte locations against two different match values (each) also requires use of all four MATCH byte properties. Or matching four different header byte locations against one match value (each) again requires use of all four MATCH byte properties.
Thus configuration of the chip to respond to both a unique Node Address as well as a Broadcast address will require two MATCH byte properties for *each* byte of the address; that is, the maximum possible length of the Node Address and Broadcast Address would be 2-bytes in length. The Boolean logic capability of the MATCH property group may be used to configure the chip to respond to either the unique Node Address or the Broadcast Address (i.e., by use of the logical-OR function within the MATCH property group).
Can I drive the 32 kHz clock signal externally on Si446x?
The short answer is yes you can. However, before we described how, let’s clarify why you would want to do that in the 1st place!
The 32 kHz clock source is primarily used for the Wake Up Timer (WUT) to count the predefined number of clock cycles and beacon if the target has been reached. This will in-turn switch on the receiver if the Rx Low Duty Cycle (LDC) operation is enabled.
There are two possible sources of the 32 kHz clock signal. It is either an internal RC oscillator, or an internal XO oscillator complemented with a 32 kHz XO between GPIO0 and GPIO1. The 1st option is less accurate but does not take up any GPIO pins and takes less current. However, if superior accuracy is important and you don’t want to take up two GPIO pins all the time for the XO, you may opt for “overdriving” the XO oscillator by an externally fed 32k clock signal (i.e coming form an MCU). You can do this while the WUT is enabled (typically in Rx LDC operations) and then reprogram the GPIO functionalities while not in this mode. Hence, you can save 2 GPIO pins while the WUT is not needed and still keep the superior accuracy.
The only “trick” with the external drive is that *you need to connect the external clock signal to GPIO1*. It will not work if it is connected to GPIO0. Current consumption in this mode of operation will match the current consumption with an XO at ~ 1.8 uA in SLEEP state.
Another subtlety that is worth mentioning is that GPIO0 and GPIO1 *must be configured to TRI STATE mode* when an external XO is connected across them for the 32k XO oscillator operation. It follows than if the overdrive method is used GPIO1 must also be configured to TRI STATE mode. (See GPIO_PIN_CFG API command for details.)
Find here a WDS RSP (Register Settings Panel) script for easily testing the operation. This script sets up RX LDC operation with 1 s sleep time and 25 ms wake time with the WUT using the 32k XO oscillator. On GPIO2 you can observe the buffered 32k clock signal while on GPIO3 you can observe the RX_STATE signal.
# Si446x batch file for testing Rx LDC operation with the WUT using the 32k XO oscillator
# POWER UP with 30 MHz XO
'POWER_UP' 01 00 01 C9 C3 80
# GPIO0 and GPIO1:TRI STATE; GPIO2: buffered 32k; GPIO3: RX_STATE
'GPIO_PIN_CFG' 04 04 05 21 00 00 00
# 30MHZ XO cap bank calibration
'SET_PROPERTY' 'GLOBAL_XO_TUNE' 52
# 32k source: XO oscillator
'SET_PROPERTY' 'GLOBAL_CLK_CFG' 02
##### WUT for 1s sleep an 25 ms wake time ###########
'SET_PROPERTY' 'GLOBAL_CONFIG' 20
#WUT enable, LDC Rx enable, Cal timer disabled
'SET_PROPERTY' 'GLOBAL_WUT_CONFIG' 42
#sleep time configuration 1s
'SET_PROPERTY' 'GLOBAL_WUT_M_15_8' 20
'SET_PROPERTY' 'GLOBAL_WUT_M_7_0' 00
'SET_PROPERTY' 'GLOBAL_WUT_R' 20
#active state time configuration
'SET_PROPERTY' 'GLOBAL_WUT_LDC' CD
'START_RX' 00 00 00 00 00 08 08