Our customer, who is considering MKW40, is asking NXP regarding max input voltage of PSWITCH and DCDC_CFG pins. Especially they plan to use buck mode with input voltage 4.2[v] as shown below. Would you comment if max voltage of PSWITCH and DCDC_CFG pins is 4.2[v] as well as DCDC_IN pin? Regards, Koichi

Our customer is evaluating RF characteristics using FRDM-MKW24. Regarding Tx max power, they have one question. The spec of max tx power is +8dBm and I could verify the power using TWR-KW24d512 before. They observed tx power with tx un-modulated cnt transmission and informed that the power was about +2dBm. That is to say, "Power 31" in Connectivity_Test means to +2dBm. I feel that it is small... Would you comment regarding the spec of the max tx power on FRDM-MKW24? Regards, Koichi

Hello community, This time I bring to you a document which explains how easy is to add a new endpoint and a new cluster to a ZigBee device in the BeeStack in BeeKit. This document is based in the MC1323x MCUs but the procedure applies to the Kinetis devices. Before to start you need to install the BeeKit Wireless Connectivity Toolkit​. If you are interested about what an endpoint is, the document ZigBee Endpoints Reserved could be useful for you. I hope you find this guide useful. Enjoy this guide, enjoy ZigBee! Any feedback is welcome. Best regards, Earl Orlando Ramírez-Sánchez Technical Support Engineer NXP Semiconductors

Bluetooth Low Energy is a standard for Low Power Wireless Networks introduced in the Bluetooth specification 4.0. Its target application domains include medical, sports & fitness, home automation and others. The adoption and development rates of this technology are growing fast helped by the wide availability of hardware support in most modern mobile phones and mobile operating systems. The purpose of this application note is to show how the Freescale FRDM-KW40Z can board with BLE Controller software can be used with the hcitool from the Linux Bluetooth stack over the HCI interface. 1. Introduction The Bluetooth specification has a very well defined interface between the Controller and the Host called the HCI (Host Controller Interface). This interface is defined for and can be used with various transport layers including an asynchronous serial transport layer. A typical scenario of Bluetooth Low Energy hardware use is a development board which has a BLE Controller accessible via serial transport HCI connected to a device on which the BLE Host runs. The device which runs the BLE Host can be any type of embedded device or a PC. PCs running a Linux type OS can use the hcitool from the Linux Bluetooth Stack to interact with a BLE Controller via the HCI interface. The particular use case of  FRDM-KW40Z board with a serial transport HCI interface running over USB CDC and connected to a PC running the Linux Bluetooth stack is shown in the diagram below and will be detailed din the following sections. Figure 1FRDM-KW40Z (BLE Controller) connected to Linux PC (Bluetooth Host Stack) via HCI Serial Transport 2. Loading the HCI Application onto the FRDM-KW40Z First load the hci_app on the FRDM-KW40Z board. The hci_app aplication can be found in the <ConnectivitySwInstallationPath>\ConnSw\examples\bluetooth\hci_app folder. 3. Connecting the FRDM-KW40Z to the Computer via a Serial Port After the app is downloaded to the board plug the board into a free USB port of your Linux computer. The following instructions, commands and their output is typical to a Debian based Linux OS. After the board is plugged in run the following command to list the serial ports available. >> dmesg | grep tty [ 0.000000] console [tty0] enabled [ 2374.118201] cdc_acm 1-2:1.1: ttyACM0: USB ACM device In our example the FRDM-KW40Z board serial port is ttyACM0. To test the connection some HCI commands can be sent in hex format from any terminal application to the serial HCI on the FRDM-KW40Z board. In the figure below an HCI_Read_BD_ADDR command and its corresponding Command Complete Event are shown as they were sent and received in hexadecimal format from the moserial serial terminal GUI application. Figure 2: HCI command and response event in hexadecimal format (HCI UART Transport) 4. Connecting the HCI Serial Interface to the Bluetooth Stack To connect the Linux Bluetooth stack to a serial HCI interface the hciattach command must be run as shown below. >> hciattach /dev/ttyACM0 any 115200 noflow nosleep Device setup complete If the the HCI serial interface is successfully attached to the Bluetooth stack then the "Device setup complete" message is shown. The any parameter specifies a generic Bluetooth device. The 115200 parameter is the UART baudrate. The noflow parameter diasables serial flow control. The nosleep parameter disables hardware specific power managment. Run the hciconfig command with no parameters to check the HCI interface id of the newly attached HCI serial device. >> hciconfig hci1:    Type: BR/EDR  Bus: UART     BD Address: 00:04:9F:00:00:15  ACL MTU: 27:4 SCO MTU: 0:0     UP RUNNING     RX bytes:205 acl:0 sco:0 events:14 errors:0     TX bytes:112 acl:0 sco:0 commands:14 errors:0 hci0:    Type: BR/EDR  Bus: USB     BD Address: 90:00:4E:A4:70:97  ACL MTU: 310:10  SCO MTU: 64:8     UP RUNNING     RX bytes:595 acl:0 sco:0 events:37 errors:0     TX bytes:2564 acl:0 sco:0 commands:36 errors:0 In this example the FRDM-KW40Z is assigned the hci1 interface as can be seen from the bus type (Type: BR/EDR  Bus: UART). The hci0 interface is the example shown corresponds to the on-board Bluetooth module from the machine. On some systems the interface might need to be manually started by using the hciconfig interfaceId up command. hciconfig hci1 up 5. Configuring the Bluetooth Device and Listing its Capabilities The hciconfig command offers the possibility of configuring the device and listing the device capabilities. To find all commands supported by the hciconfig tool type the following command. >> hciconfig –h ...display supported commands... Each individual hciconfig command must be addressed to the correct HCI interface as reported above. In our example we use the hci1 interface. Some hciconfig commands require root privileges and must be run with sudo (the "Operation not permitted(1)" error will be returned if a command needs to be run with root privileges). Some useful hci config commands: >> hciconfig hci1 version    -> lists hci device verison information >> hciconfig hci1 revision    -> lists hci device revision information >> hciconfig hci1 features    -> lists the features supported by the device >> hciconfig hci1 commands    -> lists the hci commands supported by the device >> sudo hciconfig hci1 lestates    -> lists the BLE states supported by the device >> sudo hciconfig hci1 lerandaddr 11:22:33:44:55:66    -> set a random address on the device >> sudo hciconfig hci1 leadv 3    -> enable LE advertising of the specified type >> sudo hciconfig hci1 noleadv    -> disable LE advertising Now the newly connected board with a serial HCI is attached to a HCI interface of the Bluetooth stack and is ready to use. 6.    Controlling the Bluetooth Device using the hcitool The hcitool can be used to send HCI commands to the Bluetooth device. A command is available which lists all available hcitool actions. >> hcitool -h ...display supported commands... To target a specific HCI interface use the -i hciX option for an hcitool command. We will use -i hci1 in our examples. The hcitool supports commands for common BLE HCI operations some of which are shown below and also supports sending generic HCI commands using a dedicated option which uses hexadecimal numbers for the OGF (Command Group), OCF (Command Code) and the parameters. The 6 bit OGF and the 10 bit OCF compose the 16 bit HCI Command Opcode. The command parameters are specific to each command. 6.1.  Listing Devices Available to the hcitool An hcitool command can list all available device interfaces. >> hcitool dev Devices: hci1    00:04:9F:00:00:15 hci0    90:00:4E:A4:70:97 The device we are working with is connected to the hci1 interface as seen from the output of the hciconfig command used above. 6.2.  Scanning for Advertising LE Devices The hcitool can be used to perform a LE Device scan. This command requires root privileges. Press Ctrl+C to stop the scan at any time. >> sudo hcitool -i hci1 lescan LE Scan ... 00:04:9F:00:00:13 (FSL_OTAC) ^C A list of addresses and device names will be shown if advertised (<<Shortened Local Name>> or <<Complete Local Name>> as define din the specification). 6.3.  Obtaining Remote LE Device Information Using the hcitool To obtain information about a remote LE device a special hcitool command can be used. The hcitool leinfo command creates a connection, extracts information from the remote device and then disconnects. The remote device information is shown at the command prompt. >> sudo hcitool -i hci1 leinfo 00:04:9F:00:00:13 Requesting information ...        Handle: 32 (0x0020)        LMP Version: 4.1 (0x7) LMP Subversion: 0x113        Manufacturer: Freescale Semiconductor, Inc. (511)        Features: 0x1f 0x00 0x00 0x00 0x00 0x00 0x00 0x00 In this example information about a device previously discovered using the hcitool lescan command is shown. 6.4.  Connecting and Disconnecting from a Remote LE Device Connecting to a remote LE device is done using the hcitool lecc command. >> sudo hcitool -i hci1 lecc 00:04:9F:00:00:13 Connection handle 32 As before a previously discovered device address is used. If the connection is successful then the Connection Handle is returned and in our case the Connection Handle is 32. The hcitool con command shows active connections information: address, connection handle, role, etc. >> hcitool con Connections: < LE 00:04:9F:00:00:13 handle 32 state 1 lm MASTER To end a LE connection the hcitool ledc command can be used. It must be provided with the Connection Handle to be terminated, and optionally the reason. The device handle obtained after the connection and shown in the connected devices list is used. >> hcitool –I hci1 ledc 32 >> Listing the connections after all connections are terminated will show an empty connection list. >> hcitool con Connections: >> 6.5.  Sending Arbitrary HCI Commands To send arbitrary HCI commands to a device using the Command CopCode (OGF and OCF) the hcitool cmd command can be used. As an example the HCI_Read_BD_ADDR command is used which has the 0x1009 OpCode (OGF=0x04, OCF=0x009) and no parameters. It is the same command shown in the direct serial port to HCI communication example above. hcitool -i hci0 cmd 0x04 0x0009 < HCI Command: ogf 0x04, ocf 0x0009, plen 0 > HCI Event: 0x0e plen 10   01 09 10 00 15 00 00 9F 04 00 The OpCode OGF (0x04) and OCF (0x009) and no parameters are passed to the hcitool cmd command all in hexadecimal format. The parameters length (plen) is 0 for the command. The response is a Command Complete event (0x03) with the parameters length (plen) 10. The parameters are 01 09 10 00 15 00 00 9F 04 00: 01 is the Num_HCI_Command_Packets parameter 09 10 is the Command OpCode for which this Command Complete Event is returned (in little endian format) 00 is the status – Success in this case 15 00 00 9F 04 00 is the BD_ADDR of the device as listed by the hcitool dev command

This is some information of Bluetooth Low Energy about the White List. I hope this information help you to understand the White List. The device to connect is saved on the white list located in the LL block of the controller. This enumerates the remote devices that are allowed to communicate with the local device. Since device filtering occurs in the LL it can have a significant impact on power consumption by filtering (or ignoring) advertising packets, scan requests or connection requests from being sent to the higher layers for handling. The Withe List can restrict which device are allowed to connect to other device. If is not, is not going to connect.      Once the address was saved, the connection with that device is going to be an auto connection establishment procedure.This means that the Controller autonomously establishes a connection with the device address that matches the address stored in the While List. Figure 1. White List Procedure NOTE: For more details download the Specification of the Ble​

What is a BLE Beacon? A BLE Beacon is a hardware including a MCU, a BLE radio, an antenna and a power source. Things like Freescale Beacon, iBeacon, AltBeacon or Eddystone are software protocols with their own characteristics. How it works? A BLE Beacon is a non-connectable device that uses Bluetooth Low Energy (BLE or Bluetooth Smart) to broadcast packets that include identifying information and each packet receives the name of Advertising Packet. The packet structure and the information broadcasted by a Beacon depend on the protocol, but, the basic structure is conformed by: UUID. This is a unique identifier that allows identifying a beacon or a group of beacons from other ones. Major number. Used to identify a group of beacons that share a UUID. Minor number. Used to identify a specific beacon that share UUID and Major number. Example UUID Major Minor AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 1 1 These Beacons share the same UUID and Major number, and are differentiated by Minor number. AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 1 2 AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA 2 1 This Beacon shares the same UUID as the previous ones, but has a different Major number, so it belongs to a different group. BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB 1 1 This Beacon is completely different from the previous ones, since it doesn’t share the same UUID. These packets need to be translated or interpreted in order to provide the beacon a utility. There are applications that can interact with beacons, usually developed to be used with smartphones and/or tablets. These applications require being compliant with the protocol used by the beacon in order to be able to perform an action when a beacon is found. Use Cases Beacons can be used on different places to display different content or perform different actions, like: Restaurants, Coffee Shops, Bars Virtual Menu Detailed information Food source Suggested wine pairings Museums Contextual information. Analytics Venue check-in (entry tickets) Self-guided tours. Educational excursions Event Management and Trade Shows Frictionless Registration Improved Networking Sponsorship Navigation and Heat Mapping Content Delivery Auto Check-in Stadiums Seat finding and seat upgrading Knowing the crowded locations Promotions, offers and loyalty programs Sell Merchandise Future implementations Retail and Malls Shopping with digital treasure hunts Gather digital up-votes and down-votes from visitors Allow retailers to join forces when it comes to geo-targeted offers Use time-sensitive deal to entice new shoppers to walk in Help in navigation Engage your customers with a unified mall experience.

Commissioner Authentication server for new Thread devices and the authorizer for providing the network credentials they require to join the network. A device capable of being elected as a Commissioner is called a Commissioner Candidate. Devices without Thread interfaces may perform this role, but those that have them may combine this role with all other roles except the Joiner. This device may be, for example, a cell phone or a server in the cloud, and typically provides the interface by which a human administrator manages joining a new device to the Thread Network. Commissioner Candidate A device that is capable of becoming the Commissioner, and either intends or is currently petitioning the Leader to become the Commissioner, but has not yet been formally assigned the role of Commissioner. Commissioner Credential A human-scaled passphrase for use in authenticating that a device may petition to become the commissioner of the network. This credential can be thought of as the network administrator password for a Thread Network. The first device in a network, typically the initial Leader, MUST be out-of-band commissioned to inject the correct user generated Commissioning Credential into the Thread Network, or provide a known default Commissioning Credential to be changed later. Joiner A device to be added by a human administrator to a commissioned Thread Network. This role requires a Thread interface to perform and cannot be combined with another role in one device. The Joiner does not have network credentials. Joiner Router An existing Thread router or REED (Router-Eligible End Device) on the secure Thread Network that is one radio hop away from the Joiner. The Joiner Router requires a Thread interface to operate, and may be combined in any device with other roles except the Joiner role. Information extracted from the Thread Whitepapers available at threadgroup.org

The SMAC & IEEE 802.15.4 protocol stacks are a KSDK add-on, therefore you need the installation of the KSDK 1.2 before installing these connectivity stacks. Install the Kinetis SDK 1.2: Software Development Kit for Kinetis MCUs|Freescale After installing the KSDK 1.2, download the desired protocol stack. The connectivity software for this platform can be found in the board webpage, in the downloads tab: Modular Reference Boards for Kinetis KW0x|Freescale The installation window will guide you through an easy way to install the software. Best regards, Luis Burgos.

The connectivity software is an add-on of the Kinetis SDK, therefore the demos are referenced to a KSDK path variable named "KSDK_PATH" in IAR. The KSDK_PATH variable contains the path of the installation folder for the KSDK version in your PC. Taking as an example the MRB-KW01 SMAC Connectivity Software, we can realize that this variable is used to reference for libraries. In particular, this SMAC software for the MRB-KW01 works with KSDK 1.2, that is why you could have troubles if the variable is referenced to another KSDK version (for example KSDK 1.1). Follow the next steps to modify the KSDK_PATH variable in your computer: 1. Right click on "computer", then click "properties" 2. A Control Panel window will be opened. Click on "Advanced system settings" 3. A system Properties windows will be opened. Select the "Advanced" tab, then click "Environment Variables". 4. Select the KSDK_PATH variable and assure that it stores the correct path needed for your project. In case that you need to modify the variable, then click "Edit" 5. Finally click "Ok" to close all tabs and you will be able to run your connectivity software without problems. Best regards, Luis Burgos.

Certification is the process of testing radio hardware to demonstrate that it meets the stated regulations in the country that it will operate in. A certification is needed generally when electronic hardware will be sold in a country, the certification requirements of that country must be met. If you require changes in your certificated hardware that will affects your RF performance, then you need to re-certificate the device. Most common regions and certification's institutes are (it applies for 2.4GHz & SubGHz): FCC for USA IC for Canada ETSI (CE) for Europe ARIB for Japan Other countries generally follow FCC or ETSI standars. The institute in charge of certifications depends on the region. It's the same institute to certificate your device in 2.4GHz or SubGHz in a certain region, the only difference are the articles of each institute to operate in the different frequencies. For operating in the 2.4GHZ band (worldwide): - In the U.S, CFR 47 FCC Part 15 203, 15.209 and 15.247 - In Canada, IC RSS-210 which closely follows FCC Part 15 - In EU, ETSI EN 300, 301 - In Japan, ARIB STD-T66 For SubGHz depends on the frequency you want to operate in. Taking Japan as an example: In Japan you can operate in the 920MHz band or in the 400MHz band for SubGHz. For both frequencies, ARIB is the institute in charge of the certifications but to operate in the 400MHz band the article that you will need is the ARIB STD-T67, and to operate in the 920MHz you will need to certificate your hardware with ARIB STD-T108 article. Freescale's MRB-KW019032 is certificated to operate in the following SubGHz ISM bands: The firmware used to certificate our KW products is the Radio Utility or the Connectivity Test, it allows the user in changing some RF parameters needed to pass the certification process. If you are thinking in certificate a product, contact an expert! There are Telecommunication Certification Body (TCB) companies which can give you guidance in the processes you need to follow to achieve a certification. To know more about FCC certification requirements and processes, refer to the reference manual “Freescale IEEE 802.15.4 / ZigBee Node RF Evaluation and Test Guidelines” in the Freescale's website. Best regards, Burgos. This document was generated from the following discussion: Certifications

Thread is a secure, wireless, simplified IPv6-based mesh networking protocol developed by industry leading technology companies, including Freescale, for connecting devices to each other, to the internet and to the cloud. Before starting a Thread Network implementation, users should be familiar with some concepts and how they are related to Thread protocol. IPv6 Addressing Devices in the Thread stack support IPv6 addressing IPv6 addresses are 128-bit identifiers (IPv4 is only 32-bit) for interfaces and sets of interfaces.  Thread supports the following types of addresses: Unicast:  An identifier for a single interface.  A packet sent to a unicast address is delivered to the interface identified by that address. Multicast: An identifier for a set of interfaces (typically belonging to different nodes).  A packet sent to a multicast address is delivered to all interfaces identified by that address. NOTES There are no broadcast addresses in IPv6, their function being superseded by multicast addresses. Each device joining the Thread Network is also assigned a 16-bit short address as specified in IEEE 802.15.4. 6LoWPAN All Thread devices use 6LoWPAN 6LoWPAN stands for “IPv6 over Low Power Wireless Personal Networks”. 6LoWPAN is a set of standards defined by the Internet Engineering Task Force (IETF), which enables the efficient use of IPv6 over low-power, low-rate wireless networks on simple embedded devices through an adaptation layer and the optimization of related protocols. Its main goal is to send/receive IPv6 packets over 802.15.4 links. Next figure compares IP and 6LoWPAN protocol stacks: The following concepts would explain the transport layer. ICMP Thread devices support the ICMPv6 (Internet Control Message Protocol version 6) protocol and ICMPv6 error messages, as well as the echo request and echo reply messages. The Internet Control Message Protocol (ICMP) is an error reporting and diagnostic utility and is considered a required part of any IP implementation. ICMPs are used by routers, intermediary devices, or hosts to communicate updates or error information to other routers, intermediary devices, or hosts. For instance, ICMPv6 is used by IPv6 nodes to report errors encountered in processing packets, and to perform other internet-layer functions, such as diagnostics. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.  The ICMPv6 messages have the following general format: The type field indicates the type of the message.  Its value determines the format of the remaining data. The code field depends on the message type.  It is used to create an additional level of message granularity. The checksum field is used to detect data corruption in the ICMPv6 message and parts of the IPv6 header. ICMPv6 messages are grouped into two classes: error messages and informational messages.  Error messages are identified as such by a zero in the high-order bit of their message Type field values.  Thus,   error messages have message types from 0 to 127; informational messages have message types from 128 to 255. UDP The Thread stack supports UDP for messaging between devices. This User Datagram Protocol  (UDP)  is defined  to  make available  a datagram   mode of  packet-switched   computer communication  in  the environment  of an  interconnected  set  of  computer  networks, assuming that the Internet  Protocol (IP) is used as the underlying protocol. With UDP, applications can send data messages to other hosts on an IP network without prior communications to set up special transmission channels or data paths. UDP is suitable for purposes where error checking and correction is either not necessary or is performed in the application, avoiding the overhead of such processing at the network interface level. The UDP format is as follows: Source Port is an optional field, when meaningful, it indicates the port of the sending  process,  and may be assumed  to be the port  to which a reply should be addressed  in the absence of any other information.  If not used, a value of zero is inserted. Destination Port has a meaning within the context of a particular internet destination address. Length is the length in octets of this user datagram including this header and the data.   (This means the minimum value of the length is eight.) Checksum is the 16-bit one's complement of the one's complement sum of a pseudo header of information from the IP header, the UDP header, and the data, padded  with zero octets at the end (if  necessary)  to  make  a multiple of two octets. References White papers available at http://threadgroup.org/ “6LoWPAN: The Wireless Embedded Internet” by Zach Shelby and Carsten Bromann RFC 4291, RFC 4944, RFC 4443 and RFC 768 from https://www.ietf.org

The image below shows the different types of devices in a Thread Network. Router Routers provide routing services to network devices. Routers also provide joining and security services for devices trying to join the network. Routers are not designed to sleep. Routers can downgrade their functionality and become REEDs (Router-eligible End Devices). A Router can become a Leader and start a Thread network. Border Router A Border Router is a type of Router that provides connectivity from the 802.15.4 network to adjacent networks on other physical layers (for example, Wi-Fi and Ethernet). Border Routers provide services for devices within the 802.15.4 network, including routing services for off-network operations. There may be one or more Border Routers in a Thread Network. The Border Router also serves as an interface point for the Commissioner when the Commissioner is on a non-Thread Network; it requires a Thread interface and may be combined in any device with other Thread roles except the Joiner. Leader A Router or Border Router can assume a Leader role for certain functions in the Thread Network. This Leader is required to make decisions within the network. For example, the Leader assigns Router addresses and allows new Router requests. The Leader role is elected and if the Leader fails, another Router or Border Router assumes the Leader role. It is this autonomous operation that ensures there is no single point of failure. Router-eligible End Device REEDs have the capability to become Routers but due to the network topology or conditions these devices are not acting as Routers. These devices do not generally forward messages or provide joining or security services for other devices in the Thread Network. The Thread Network manages REEDs becoming Routers if necessary without user interaction. Sleepy End Device Sleepy end devices are host devices. They communicate only through their Parent Router and cannot forward messages for other devices References: Thread Whitepapers available at http://threadgroup.org 

KW01 demo code for 315/434MHz application is ready. The demo code located in the "software Development Tools" FXTH87|Tire Pressure Monitor Sensor|Freescale

BeeStack solutions included in BeeKit contain several low level drivers that definitely ease customer’s development phase.  Ranging from UART, SPI, NVM, I2C, among many others, these drivers could be used to interface the MW2x devices with different devices or sensors. It is also true these drivers will not support all custom applications by default, but they are conveniently provided in source code so anyone can modify them to the application’s needs. One example would be the need to use an accelerometer such as FXOS8700 or MMA8451. In this case, the default functionality of the I2C drivers might not be well-suited to work with these devices out-of-the-box. Nevertheless, this could be achieved with simple modifications to the source code. This project implements the basic I2C functionality to interface a TWR-KW24D512 board with a FXOS8700 sensor using the drivers included in Kinetis BeeStack Codebase 4.0.x solutions. The demo uses a ZigBee Home Automation GenericApp template to initialize and periodically read the accelerometer data X, Y and Z. A change in the registers read and written would be enough to use MMA8451 instead.  Following images illustrate the I2C frames obtained from the analyzer: FXOS8700 Initialization: Accelerometer X-Axis Data: Accelerometer Y-Axis Data: Accelerometer Z-Axis Data: IMPORTANT NOTE: Support of the attached project is limited. Please use this project as reference only. If it does not fulfill your requirements, you could always modify its source code to meet you application’s needs.

The TWR-KW2x board's OpenSDA is programmed with PE Micro's OpenSDA firmware which enables MSD, debugging and CDC Serial port. This firmware can be easily modified by putting the K20 part in bootloader mode and load another firmware to it with a simple drag and drop. Follow these steps to modify the OpenSDA firmware on the TWR-KW2x board. Segger's OpenSDA v2.1 will be used as an example of the new OpenSDA firmware (Instead of the default PE Micro's) 1. Unplug the board 2. Insert a Jumper in J30 to put the device in Bootloader mode 3. Plug in the board (Mini-USB) 4. Device will be enumerated as a "Drive Disk" But now with a "Bootloader" label 5. Drag and Drop the Segger's JLink_OpenSDA_V2_1.bin firmware (https://segger.com/opensda.html) into the Bootloader unit 6. Unplug the board 7. Remove Jumper 8. Plug in the board (Mini-USB) Now you should see the board being enumerated as "JLink CDC UART Port", allowing serial port communication. You should also be able to debug your application using J-Link debugging interface through the OpenSDA interface, no need of external hardware. Note1: Drivers can be found at Segger's website (https://segger.com/opensda.html) Note2: Jumper has to be in place in J29 for debugging Note3: IDE options must be set to use J-Link Driver

This document describes the implementation of the Connected Home Gateway for the Internet of Things (IoT) and its controller implemented in a Smart device (tablet) running Android OS. The gateway is intended to serve as a communication bridge between WiFi/Ethernet and ZigBee Protocol, making every ZigBee-enabled device accessible and controllable from any smart device with Wi-Fi capabilities such as a smart phone or tablet. This will remove the need of having a ZigBee transceiver in every mobile device attempting to control the house appliances. In general, users will be able to: Remote control of Home Appliances using ZigBee protocol Any WiFi-enabled device could control the appliances without a ZigBee transceiver Achieve bi-directional communication between users and appliances Real system implementation would require a powerful MCU to manage all WiFi/Ethernet communication and a second MCU to manage all ZigBee communications. The Kinetis K60 and KW24 were selected among the different options available.

Sniffing is the process of capturing any information from the surrounding environment. In this process, addressing or any other information is ignored, and no interpretation is given to the received data. Freescale provides both means and hardware to create devices capable of performing this kind of operation. For example, a KW01 board can be easily turned into a Sub-GHz sniffer using Test Tool 12.2.0 which can be found at https://www.freescale.com/webapp/sps/download/license.jsp?colCode=TESTTOOL_SETUP&appType=file2&location=null&DOWNLOAD_ID=null After downloading and installing Test Tool 12.2.0 there are several easy steps to create your own sniffer for Sub-GHz bands. 1) How to download the sniffer image file onto KW01.      a) Connect KW01 to PC using the mini-usb cable      b) Connect the J-Link to the PC      c) Open Test Tool 12.2 and go to the Firmware Loaders tab      d) Select Kinetis Firmware Loader. A new tab will pop-up.      e) J-Link will appear under the J-Link devices tab.      f) Select the KW01Z128_Sniffer.srec file and press the upload button.     g) From the Development Board Option menu select KW01Z128.      h) Follow the on-screen instruction and unplug the board. Then plug it back in.      i) Close the Kinetis Firmware Loader tab and open the Protocol Analyzer Tab 2) How to use the Protocol Analyzer feature. Basics.     a) The Protocol Analyzer should automatically detect the KW01 sniffer. If not, close the tab, unplug the board, plug it back and re-open the tab. If this doesn’t work, try restarting Test Tool.     b) To start “sniffing” the desired channel, click the arrow down button from Devices: KW01 (COMx) Off and select the desired mode and channel.     c) The tab will change to ON meaning that KW01 will "sniff" on the specified channel. To select another channel, click the tab again and it will switch back to Off. Then select a new channel.      d) Regarding other configurations, please note that you can specify what decoding will be applied to the received data. Additional information: The sniffer image found in Test Tool is compiled for the 920-928MHz frequency band. Because of this, the present document will have attached to it two sniffer images, for the 863-870MHz and the 902-928MHz frequency bands. To upload a custom image perform the steps described at the beginning of this document, but instead of selecting a *.srec file from the list in Kinetis Firmware Loader click the Browse button and locate the file on disk. After selecting it, redo the steps for uploading an image file. A potential outcome: sometimes, if you load a different frequency band sniffer image, the Protocol Analyzer will display the previously used frequency band. To fix this, close Test Tool, re-open it and go to the Protocol Analyzer tab again. The new frequency band should be displayed. More information on this topic can be found in Test Tool User Guide (..\Freescale\Test Tool 12\Documentation\TTUG.pdf), under Chapter 5 (Protocol Analyzer, page 87).

This document describes how to sniff ZigBee packets to identify messages and layers from the ZigBee stack using the MC1322x USB dongle and Wireshark protocol analyzer. --------------------------------------------------------------------------------------------------------- Pre-Requisites If not done yet, download & Install Wireshark protocol analyzer http://www.wireshark.org/download.html Download the Wireshark ZigBee Utility Zip file from Sourceforge http://sourceforge.net/projects/wiresharkzigbee/ Unzip the file in a known location -------------------------------------------------------------------------------------------------------- 1. Install MC1322x dongle Plug-in MC1322xUSB dongle and wait for Windows to install the driver. If the driver was not found, steer Windows manually to the directory         C:\Program Files\Freescale\Drivers If BeeKit is not installed, be aware of the following: The 1322x USB Dongle uses the FTDI serial to USB converter, Virtual COM Port (VCP) driver for Windows, available at www.ftdichip.com/ftdrivers.htm. The FTDI web site offers drivers for other platforms including Windows® (98 through Vista x64 and CE), MAC OS (8 through X) and Linux. Download the appropriate driver and follow the instructions to complete driver installation. 2. Check COM port Once installed, the MC1322xUSB dongle should be listed in the available COM ports in Widows device manager. Verify the board’s drivers were successfully installed and take note of the COM port assigned      3. Run the ZigBee Utility Open a command console and navigate to the directory where Wireshark Zigbee utility files were unzipped. c:\<path> Then start the .exe utility and set the serial port and ZigBee channel to monitor, for instance:     4. Setting Wireshark Start Wireshark and open Capture>Options Dialog Click on “Manage Interfaces” and add a new pipe with ‘\\.\pipe\wireshark’. Save it and start capture. 5. Start sniffing

When having several ZigBee Networks in the same area, and therefore several potential parents, it may become necessary to join one of them and discard the rest. While having a mechanism to only accept joining devices when desired is the best method (like using a button to trigger the joining), it might not always be possible since the parent nodes could be commercial devices or another vendor’s product without this feature. Below are some mechanisms that could be used for this purpose. In general, when searching for suitable parents, the process is as follows: ZDO of device to join sends a MAC scan request. The MAC layer starts scan. For every beacon it receives, it sends a beacon notify indication that is processed in ParseBeaconNotifincaiton() function from AppStackImpl.c The ParseBeaconNotifincaiton() function will add the relevant information in the discovery table and for this it needs a free entry, so it calls GetFreeEntryInDiscoveryTable() function with reuse parameter as FALSE. If the table is full, it will call GetFreeEntryInDiscoveryTable() with reuse set to TRUE to literally re-use low priority entries. When the MAC scan has finished, it will send a MAC scan confirm. When this reaches ZDO, the SearchForSuitableParent() function is called. At this point, there are several approaches that could be used: Use a specific Extended PAN ID to search only for a specific parent node Use a specific PAN ID to prioritize the network’s ID Search in a specific Channel where network is supposed to be operating in All these parameters are configurable in ApplicationConf.h file of the project’s Configure Folder and used in SearchForSuitableParent() function to filter Discovery table entries. Nevertheless, those solutions are not always the best for all applications since it may require hard-coding the network’s parameters. Fortunately, BeeStack leaves all this open for any modification in case it is necessary. In brief, if the discovery table gets full with suitable parents that you DO NOT want to use, you should update the "if(reuse)" statement of the GetFreeEntryInDiscoveryTable() function to replace an entry. In other words, if you think that the desired parent is not present in the discovery table (due to its size limitation or other reason), you should update the GetFreeEntryInDiscoveryTable() function to make sure discovery table contains only devices that are of interest to your node. Please note that the criteria used to select the desired parents is totally application specific. As mentioned, it is always best having a way to trigger the joining such as a button so the rest of parents have permit join set to FALSE and therefore join only to the desired parent without having to implement custom code. Anyway, you may select the solution that meets your application’s requirements the most.