Member | Action | Date |
---|---|---|
![]() |
Replied
to
WT32i charger - battery and/or power source and operation when battery is disconnected
Nothing will happen, The charger will charge the 470uF capacitor which is in the VBAT line, that’s all. |
Oct 28 2017, 2:42 PM |
![]() |
Replied
to
WT32i power control - change to development board schematic
This circuit will work provided VREG_ENA is properly configured. |
Oct 28 2017, 2:38 PM |
![]() |
Posted
EM3xx – Designing for radio network coexistence on Knowledge Base
There are several new products being introduced into the emerging IoT market space which include multiple radios on the same printed circuit board operating on different wireless protocols, often at the same time. In order for these radio networks to operate efficiently and coexist, they need to have some higher level network management and control. This article provides information about EM3xx features which are currently available and can be used by network management software and hardware to help facilitate the coexistence of the ZigBee and Thread based radios with other radio networks such as Bluetooth and Wi-Fi. For those designs where network management is not possible, there is also a discussion of best practices to utilize in order to maximize the robustness of an un-managed co-existence network.
Currently, the available functions which can be utilized for EM3xx network coexistence are Radio Hold-off (RHO), which is a feature in the software stack and PTI_FRAME (PA4) and TX_ACTIVE (PC5)/nTX_ACTIVE (PC6), which are hardware functions within the IC.
RHO is a feature of the ZigBee software stack code. It is an input function normally residing on pins PA6 or PA7. The network arbiter, which can be another radio’s MCU, asserts RHO when the non-ZigBee/Thread network radio is active. This causes the ZigBee/Thread software stack to hold off the transmission of packets, until after RHO is de-asserted. Management of the RHO pin by the ZigBee / Thread software stack is done by forcing a return of channel busy for the CCA (clear channel assessment) algorithm, which then triggers a random back-off period for packet retry with a default of up to 3 total retries.
PTI_FRAME (PA4) is hardware function that must be enabled in software and the GPIO alternate function selected in order to be utilized. The primary function of PTI_FRAME is a debug port frame signal for network level debugging. It is asserted when TX preamble begins or when RX sync is detected. Thus PTI_FRAME can be used as an input to the network arbiter to indicate the ZigBee/Thread radio is active.
TX_ACTIVE (PC5) is a hardware function which must have the GPIO alternated function selected in order to be utilized. The primary function of TX_ACTIVE is to operate an external switch within a FEM or discrete PA / LNA solution to select either the transmit path or the receive path. When asserted it marks the start of TX operation and when de-asserted it marks the end of TX operation. As an input to the network arbiter, TX_ACTIVE can be used as a flag to indicate when the ZigBee/Thread radio is transmitting. Used in conjunction with PTI_FRAME, TX_ACTIVE can also be used to identify if the ZigBee/Thread radio is in TX mode or RX mode, adding another layer of feedback to the network arbiter. The reason for this signal combination is the ZigBee/Thread radio is not always active in RX mode when TX_ACTIVE is low. For example, when PTI_FRAME is asserted and TX_ACTIVE is high, the radio is in TX mode. When PTI_FRAME is asserted and TX_ACTIVE is low, the radio is in RX mode. If PTI_FRAME is not asserted and TX_ACTIVE is low, the ZigBee/Thread radio is either not enabled or is simply not receiving packets.
nTX_ACTIVE (PC6) is a hardware function which must have the GPIO alternated function selected in order to be utilized. The nTX_ACTIVE function is the inverse of the TX_ACTIVE function which is primarily the same except that nTX_ACTIVE de-asserts at the start of TX operation and asserts at the end of TX operation and is meant for separate LNA mode switching. nTX_ACTIVE can be used in the same manner as TX_ACTIVE as an input to the network arbiter to indicate when the ZigBee/Thread radio is active and in conjunction with PTI_FRAME to indicate when the ZigBee/Thread radio is transmitting or receiving.
In summary, connecting the non-ZigBee/Thread network radio’s transmit active and /or receive active output to the ZigBee/Thread RHO pin allows the ZigBee/Thread radio stack to hold-off on transmitting. Connecting PTI_FRAME and TX_ACTIVE or nTX_ACTIVE to the non-ZigBee/Thread network radio’s inputs allows the other network radio to know when the ZigBee/Thread radio is active and whether it is in transmit or receive operation. For the functionality described in this article to be fully utilized, the customer will need to develop the appropriate level of network arbiter / management functionality into the non-ZigBee/Thread network radio’s software application.
There are some design strategies that do not involve active network management and should be utilized in all cases where the ZigBee/Thread radio cannot be controlled at the same time as the non-ZigBee/Thread radios included in the design. The following strategies are also useful for designers who are looking for a more simplistic approach in applications where co-existence is not a priority or for managed network designs as supplemental and best practice design strategies. Note that these strategies are not a replacement for the above network management functions for which the designer should always implement whenever possible for robust network operation.
Further references: For enabling the hardware functions, refer to the EM3xx datasheets for more details. http://www.silabs.com/support/pages/document-library.aspx?p=Wireless%20-%20ZigBee%20and%20Thread
For more details about CCA, refer to the IEEE 805.15.4 technical specification. |
Oct 28 2017, 1:27 PM |
![]() |
Posted
EM3xx – Prevent Damage to ISA3 When Connecting to Line Powered Targets on Knowledge Base
When an ISA3 is connected to a line powered EM3xx target, there is potential for causing damage to the ISA3 or the EM3xx target, due to a difference in potential between the ISA3 reference ground and the reference ground of the EM3xx target. The reason is due to lack of isolation between the AC component of the AC Mains reference and the reference ground used for the EM35xx target, for example such as found in custom EM3xx designs using bridge rectifiers. The ISA3 design assumes the EM35xx target reference ground is floating. When the EM35xx target reference ground is not floating, i.e., when it is referenced directly to an earth ground, AC mains neutral wire or AC mains hot wire, care should be taken to verify the isolation of the ground connections between the ISA3 and the EM3xx target in order to prevent damage. The ISA3 ground is normally connected to the custom EM3xx target via the Packet Trace Port connector and in some rare cases via the DEI connector. The difference in ground reference potential often happens when the ISA3 USB cable connection from the PC or the Ethernet port POE (power over Ethernet) connection provides an alternate ground reference to the ISA3. To solve this problem, we recommend breaking the ground conductors within the Packet Trace Port cable and the DEI cable. A continuity check between the ISA3 reference ground and the EM3xx target should then be made to prove the two device grounds are isolated. |
Oct 28 2017, 1:27 PM |
![]() |
Posted
EM3xx RF Tuning on Knowledge Base
Due to tolerances of on board components and PCB materials, impedances found within the RF circuit path of a given design will vary from board to board. Additionally, the tolerances of the impedance matching components themselves allows a range of impedances between parts for a given component value, with wide tolerance parts being more likely to have inconsistent tuning results. For this reason, the procedures below should be applied to a minimal sample set of at least three to five boards of the same design in order to determine the most consistent component value to use in production. Note that component type and tolerance are factors that will need to be considered for higher end designs that require more precise RF performance targets.
The RF tuning of an EM3xx design consists of two steps: transmit power output and receive sensitivity. Transmit frequency offset (crystal) tuning is recommended prior to the RF tuning.
Transmit Frequency Offset / Crystal Tuning: For proper operation between the radios in a network, it is very important to have transmit frequency offset as small as possible. For more details refer to following KBA article: http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24MHz-Crystal-Tuning/ta-p/157154
Transmit Power Output Tuning (Ceramic Balun): In an EM3xx ceramic balun design, the main objective is to minimize the RF circuit path losses by presenting the best impedance match between the EM3xx differential port pins and the antenna. This is facilitated by adjusting the value of the tuning inductor which is placed between the differential port traces which connect the EM3xx to the ceramic balun. To accomplish this, the DUT is first configured for maximum transmit power level by issuing nodetest command ‘settxpower 8’ and for channel 0x13 (2445MHz, middle of the spectrum) by issuing nodetest command ‘setchannel 13’. The DUT is then placed into continuous unmodulated transmit mode with nodetest command ‘txtone’. The power output is measured at the output of the harmonic filter by connecting a spectrum analyzer through a RF connector interface placed for this purpose, such as a U.FL, SMA or any other preferred RF connector. The power output is then measured for a range of inductor values. The inductor value that provides the best impedance match will result in the highest power output. The goal of the tuning is to determine this value. Note that this value will differ from design to design as it is dependent on PCB layout which is generally not the same for each design. Once the tuning inductor value is determined, we recommend to check TX output power on the low and high channel of the IEEE 802.15.4 band to be sure that TX output power does not vary much more than 1 dB across the band.
Transmit Power Output Tuning (Front End Module): In an EM3xx front end module (FEM) design, the transmit power output tuning is performed by finding an inductor value that provides the best impedance match between the EM3xx and the FEM. The procedure is similar to that of the ceramic balun design except that care should be taken to keep the FEM’s power amplifier (PA) in its linear output range and avoid putting the PA into a state of compression. In order to avoid this, the transmit power setting of the EM3xx needs to be set much lower than normal. For example, if the typical transmit power setting for a FEM design with a gain of 25 dB is -5dBm for a desired output of +20 dBm, then -9dBm or lower power level should be used for tuning efforts. Refer to the ceramic balun section above for nodetest commands for configuring power level, channel, and transmit tone mode. The TOKEN_MFG_PHY_CONFIG need to be properly configured to route transmit signal onto the bidirectional port for single port FEMs or onto alternate TX port for dual port FEMs. Also, the FEM control signals need to be properly configured as per the FEM control logic table. Finally, it should be noted that the VDD_PADS supply should be set to 3.6V for maximum FEM output power, or to the maximum expected VDD_PADS supply voltage for the design being tuned. The power output is measured for a range of inductor values. Similar to the ceramic balun tuning, the inductor value that provides the best impedance match will result in the highest power output. The goal of the tuning is to determine this value. Note that this value will differ from design to design as it is dependent on PCB layout which is generally not the same for each design. We recommend to check the TX power output in the lower and upper channels to make sure that the power level across the band is not varying much more than 1 dB. Once the inductor value is determined, the lowest EM3xx transmit power level that gives the highest FEM power output (depending on the desired power output and regional regulatory restrictions) can be determined. This power level should then be used in the customer application for proper configuration of the PA as the most efficient power level setting resulting in lower spurious emissions and current consumption. Once the appropriate EM35xx TX power setting is determined, we recommend to measure EVM of the DUT to make sure that there is no distortion resulting from compression.
Receive Sensitivity Tuning (Ceramic Balun or FEM with 1 RF Port): Since there is only a single tuning inductor in these designs, the receive sensitivity is not tuned. The internal PA and LNA pads of the EM3xx have similar impedances. Due to it is more practical to measure the TX power output than it is to measure RX sensitivity during an impedance matching exercise, the inductor value is determined for the optimized TX power output. In this way, receiver sensitivity is optimized by default and therefore does not require further tuning.
Receive Sensitivity Tuning (FEM with 2 RF Ports): For FEM designs with 2 RF ports, the receive port is able to be tuned separately from the transmit port. Differences in the PCB layout between the TX differential port and the RX differential port will generally require different tuning component values for each differential port due to impedance differences in the layout. The receive port tuning determines the value of tuning inductor which maximizes receive sensitivity (the minimum signal level which still achieves less than 1% packet error rate) by providing an optimized impedance match. In order to tune the receive side, the receive sensitivity should be measured with a range of inductor values in order to determine the value that maintains less than 1% packet error rate at the lowest signal level from the signal generator. The DUT is placed in receive mode (nodetest command ‘rx’) with 1,000 or 10,000 valid packets sent from the signal generator. Normally the channel used for tuning is in the middle of the spectrum (2445MHz, in the case of ZigBee). We recommend to check the lower and upper channels before the tuning task is completed to be sure that the difference in RX sensitivity is less than 1 dB across the band. For more details on receive sensitivity testing, refer to section 2.10 Receive Sensitivity Test section in AN700: http://www.silabs.com/Support%20Documents/TechnicalDocs/AN700.pdf For more information on EM3xx reference designs, refer to: http://www.silabs.com/products/wireless/zigbee/Pages/zigbee-reference-designs.aspx. For information on setting the TOKEN_MFG_PHY_CONFIG, refer to: http://www.silabs.com/Support%20Documents/TechnicalDocs/AN710.pdf
|
Oct 28 2017, 1:27 PM |
![]() |
Posted
EM3xx 24MHz Crystal Tuning on Knowledge Base
For proper operation of the EM3xx RF block, it is very important to minimize transmit frequency offset, as well as comply with the 802.15.4 specification of +/-40ppm. The frequency offset is adjusted through the txtone (carrier tone) transmit function, as the 24MHz main clock offset directly relates to the transmitter frequency offset.
Use a spectrum analyzer to measure the frequency offset of the carrier. Set the amplitude reference level higher than the expected output power of the device in order to avoid possible damage to test equipment. For ceramic balun designs, this would be +10dBm, while for PA designs +30dBm should work fine as an initial setting and can be adjusted according to the actual PA TX power maximum capability. Configure the radio to transmit a continuous unmodulated tone at 2445MHz by issuing the commands ‘setchannel 13’ and ‘txtone’ with the nodetest application installed on the device. Measure the frequency offset by selecting the frequency counter setting on the spectrum analyzer followed by a marker peak search. To determine the PPM of the frequency offset, use the following equation: Channel offset PPM = (expected / (measured – expected)) * 1E6 The frequency offset needs to be improved by adjusting the crystal loading caps only if it appears it will not comply with the +/- 40 PPM 802.15.4 specification. The intent is to tune the frequency to be as close to the desired frequency as possible. Refer to AN700 section 2.6, Transmit Frequency test http://www.silabs.com/Support%20Documents/TechnicalDocs/AN700.pdf and KBA article EM35xx-24MHz Crystal Selection http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24-MHz-Crystal-Selection/ta-p/144602 for additional information. |
Oct 28 2017, 1:27 PM |
![]() |
Posted
Testing EM3xx Transmit Over Temperature on Knowledge Base
Some customers testing EM3xx device transmit functionality over temperature observe transmit issues such as signal degradation and varying frequency offsets during large changes in temperature. This happens when the customer places the device in a continuous transmit mode, for example with standalone tx, txtone or txstream test modes using the nodetest application or manufacturing library based test commands in the customer's application, and then change the temperature without exiting the continuous transmit mode. This test method, where the device resides in a continuous transmit mode, does not reflect the device’s normal transmit behavior as it would function in a real application. The reason for the customer seeing these performance issues is the device is not able to recalibrate the channel when left in this continuous transmit mode and recalibration is not triggered when the temperature changes. When a device is powered up for the first time after programming and it selects a channel, a calibration is run automatically for proper configuration of the device. This calibration occurs the first time each channel is selected (since default channel calibration token data exists for that channel in simulated EEPROM), as well as any time there is a change in temperature (when compared with the temperature at the time of the previous calibration event) which is large enough to trigger recalibration. Silicon Labs recommends not to remain in a continuous transmit mode while changing temperature. We recommend instead to bring the unit to the desired temperature, start the continuous transmit mode, take the desired test measurement, exit / stop the transmit mode, move on to the next temperature set point, and repeat. This allows all channel calibration checks and events to occur normally, thus allowing transmit operation to function normally at all test temperatures.
Related articles: http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24MHz-Crystal-Tuning/ta-p/157154
http://community.silabs.com/t5/Wireless-Knowledge-Base/EM3xx-24-MHz-Crystal-Selection/ta-p/144602
Related application note: http://www.silabs.com/Support%20Documents/TechnicalDocs/AN700.pdf
|
Oct 28 2017, 1:27 PM |
![]() |
Posted
EM35x - Most Common Design Review Feedback on Knowledge Base
Below is a list of the most common design review feedback items for EM35x customer design reviews. Before you complete your EM35x-based design and submit design files for review by our support team, please review this list and refer to the documentation links below.
Please refer to the EM35x Reference Designs (http://www.silabs.com/products/wireless/zigbee/Pages/zigbee-reference-designs.aspx) for recommended design implementations. Also, please refer to AN698 PCB Design with EM35x (http://www.silabs.com/Support%20Documents/TechnicalDocs/AN698.pdf) for detailed design recommendations. |
Oct 28 2017, 1:27 PM |
![]() |
Posted
Debugging EM3xx programming issues on Knowledge Base
QuestionHow do I debug EM3xx programming issues? AnswerThere are several possible causes of EM3xx programming issues. Some examples are described below.
One possible cause for not being able to program EM3xx flash is having enabled read and write protection inadvertently. This is easy to identify, as em3xx_load will display a message stating that read protection is enabled. To recover the device, simply disable read protection with the following command:
em3xx_load --disablerdprot
This operation will also erase the main flash block.
Another possible cause could be data corruption in the main flash block. This could be caused by programming a corrupt image into flash, where the application is in a tight reset loop that prevents the debugger from interfacing with the target device. In such a case, the EM3xx can be forced to enter FIB monitor mode, which will bypass the application, allowing the debugger to access the target and erase the corrupt image. This is achieved by shorting pin PA5 to ground on a power-up/boot-up event. You can verify that you know have a serial wire access to the device by issuing the following command, which reads the EUI-64 from the flash:
em3xx_load --reui64
This should display valid EUI-64 without any errors. Then, continuing to hold PA5 low, run either of the following commands:
em3xx_load --masserase or em3xx_load --erase
The command ‘masserase’ will perform a global erase operation and the entire flash block is erased at once, while the command ‘erase’ does a page by page erase operation. Once erased, PA5 can be removed from ground. Once the above action is done, programming operations on the EM3xx chip should now return to normal. |
Oct 28 2017, 1:28 PM |