NXP Designs Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

NXP Designs Knowledge Base

Discussions

Sort by:
Description Application demo uses a model trained off the MNIST dataset to recognize individual handwritten digits written on the touch sensitive LCD screen. Thie model conversion can be found here: https://community.nxp.com/docs/DOC-344227. Software The RT1060 SDK should already be installed in MCUXpresso IDE. Drag-and-drop the .zip file into the Project Explorer view, and then compile and flash. NXP Products Link i.MX RT1060 Evaluation Kit i.MX RT1060 Evaluation Kit | NXP  4.3" LCD Panel 4.3" LCD Panel RK043FN02H-CT | NXP 
View full article
Description Application demo recognizes 10 keywords: "yes", "no", "up", "down", "left", "right", "on", "off", "stop", "go" spoken into the on-board microphone. Use terminal output - 115200 baud - to see results. This demo was created as part of hands-on lab demonstrating model conversion which can be found here: https://community.nxp.com/docs/DOC-344227. Software The RT1060 SDK should already be installed in MCUXpresso IDE. Drag-and-drop the .zip file into the Project Explorer view, and then compile and flash. NXP Product Link i.MX RT1060 Evaluation Kit i.MX RT1060 Evaluation Kit | NXP 
View full article
Overview Human Fall Detection using 3-axis Accelerometer provides an implementation of human activity/fall detection mainly targeted for medical and security applications.This reference design is based on the 3-Axis accelerometer MMA7260Q, RF transceiver MC13192 and the Digital Signal Controller56F8013. The idea is to provide information that helps determine if a person has suffered an accident (if the person has fallen and to provide information related to the fall to determine the magnitude and characteristics of the accident. This application could result extremely useful to the police, firemen, and elderly people. Human Fall Detection using 3-axis Accelerometer is a modular architecture. The user is able to use Digital Signal Processing capability, wireless/serial communication interfaces, 3-axis sensing, external memory for data storage, plus the ability to reprogram the board with different applications with a JTAG interface. Archived content is no longer updated and is made available for historical reference only. Features Three-axis low g accelerometer (MMA7260Q). 2.4 GHz RF transceiver data modem for 802.15.4 applications (MC13192). Digital Signal Controller (56F8013). 9V Battery Operation, Serial communication Interface (RS-232),2 LED’s, 1 Buzzer and 2 Push-Buttons. The Hardware for the Parallel Port to JTAG/EOnCE adapter can be found at: AXIOM MAN and the hardware for the Parallel to JTAG/OnCE Interface providing low cost migration path from the DSP56F800DEMO board to your target hardware  at SEG13LLC. Design Resources
View full article
This demo shows how to load the different demo codes for the kit FRDM-K64 with FRDM-FXS-MULT2B boards, to access the different sensors included in the card and use it to create your own applications. This demo runs on a K64 freedom board and uses the MCUXpresso IDE, the FRDM-K64 with MULT2B SDK and a serial terminal, in this case TeraTerm. Video: Software Links: Driver FRDM-K64: http://developer.mbed.org/media/downloads/drivers/mbedWinSerial_16466.exe MCUXpresso (requires NXP account): https://www.nxp.com/design/software/development-software/mcuxpresso-software-and-tools/mcuxpresso-integrated-development-environment-ide:MCUXpresso-IDE SDK Builder (requires NXP account): https://mcuxpresso.nxp.com/en/select_config_tools_data TeraTerm: https://osdn.net/projects/ttssh2/releases/ NXP Product Link Freedom Development Platform for Kinetis® K64, K63, and K24 MCUs FRDM-K64F Platform|Freedom Development Board|Kinetis MCUs | NXP  Freedom Development Platform for NXP® Sensors with Bluetooth®. Freedom Development Platform Bluetooth® | NXP 
View full article
uCP1020 - IoT Gateway System-On-Module Based on QorIQ P1020, dual-core, 800MHz, communications processor 80x 80mm module, with 120-pin board-to-board connector Module contains: power distribution, DDR-SDRAM with ECC, NOR flash, (optional eMMC), network and USB PHYs, -40 to +85C parts Peripheral connectivity using SPI, I2C, UART, USB, SDHC, PCIe, miniPCIe Complete development kit available with host-board reference design Optional software stacks including Arcturus Mbarx-IoT Gateway middleware, PBX/Communications software package Embedded Linux BSP from kernel mainline branch uCP1020 - Gateway Module (80x80mm)  |  uCP1020 - Development Kit  |  uCP1020 - Module and Host-board in optional anodized aluminum enclosure This Product Is Probably of Interest If You: Are evaluating or developing an IoT or multi-service gateway Looking for turn-key, deployment-ready, system-level IoT solutions Need versatility to deploy in various types of IoT environments Need a hardware platform capable of supporting various wired or wireless network interfaces Need flexible hardware as a back-bone for various derivative products Differentiation of This Product Module design increases flexibility and reduces time-to-market Core module reduces integration complexity Full host board reference design provided Turn-key compatibility with Mbarx IoT end-point (node) devices and Mbarx System Manager IoT tools Value-add software stacks, services, support and customization available Description What this Product is All About Video Link : 4537 uCP1020 IoT Gateway SoM - Product Introduction Video Product Diagram(s) IoT Physical Components Gateways SOC: QorIQ P1020 Dual-Core Communication Processor Boards/Modules: Arcturus - uCP1020 System-on-Module Software: Arcturus Mbarx IoT Gateway middleware Arcturus management middleware  Arcturus PBX/Communications software package Arcturus Mbarx-Operations Controller work-flow management middleware Open source Linux software (Kernel mainline branch) Edge Devices SOC: 2x 10/100/1000BaseT networking supported natively by the P1020 processor and on board network PHYs Software: Linux OS Modules: Various PCIe and miniPCIe based connectivity options (see wireless below) Wireless Connectivity Modules:Connectivity options for various PCIe and miniPCIe based wireless modules (modules not provided as part of development kit) Modules:GSM/LTE/HSPA/UMTS/EVDO data (depending on providers, regions and certifications).  As tested using Telit HE910 family (HEPCHGPS204T701) Modules:Wi-Fi (depending on regions and certifications).  As tested using Atheros AR9390 family. Sensors SOC: Peripheral connectivity supported by SPI, I2C, UART, USB, SDHC, PCIe, miniPCIe Cloud Infrastructure/Services Software/Services: Arcturus Mbarx IoT Gateway middleware is fully compatible with Mbarx IoT end-nodes such as uCMK60 based on K60, K64. Mbarx IoT protocol supports TCP/IP sockets with TLS security and simple character driven protocol Mbarx IoT Gateway middleware supports remote-site aggregation, secure connectivity and device management proxy. Optional plugs-ins for MQTT, CoAP and other popular IoT/M2M protocols. Smart Devices/Apps Software: Mbarx-Operations Controller supports cross-platform work-flow driven, operational control using a responsive HTML5 architecture. Mbarx-System Manager site-wide IoT device/node management tool is available for PCs. IoT System Capabilities Device Management Secure remote site connectivity Remote site IoT node/device aggregation Bulk device firmware updates, bulk configuration, site wide-provisioning Secure IoT node/device management and configuration Cloud/App Communications/Interworking Wi-Fi Access Point (Host AP mode), cellular data Security SSL/TLS 1.1,1.2 server and client with X.509 IoT Development Capabilities Embedded Platforms Kinetis MCUs, QorIQ 32-bit Power Architecture processors Embedded Tools Linux - kernel, driver, middleware and user space application development U-boot development and customization MQX - KSDK Services Customization and system solutions available through direct engagement - contact Arcturus Hardware and software services available - contact Arcturus
View full article
LS1021A IoT Gateway Reference Design Included in Kit Linux BSP and OpenWRT Reference Design (schematics, layout and BOM available) HW Quick Start Guide and User's Guide This Product Is Probably of Interest If You: Need a ready to use high capability IoT Gateway Reference Platform Need built-in WiFi and Arduino connectivity Want a ready to manufacture HW design Key HW Features: 1 Gb QSPI NOR Flash 1 GB DDR3L SDHC slot—up to 32 GB 4 GB populated 1x One Gb/s Ethernet (SGMII) 1x One Gb/s Ethernet (RGMII) 2x mini PCIe (x1) slots 1x mSATA slot 1x Terminal (USB to UART) x Four wire LP-UART to Arduino connector (Thread, ZigBee, Bluetooth, etc.) • Muxed LCD/QE interface 24-bit LVDS LCD interface QE UART to header for PROFIBUS or RS485 (external transceiver required) • USB 3.0 2x ports—USB-A 2x ports to mini PCIe slots • 13x GPIO or 8x FTM (PWM) • 6x Interrupts • 1x SPI • I2C1 bus Board EEPROM Boot EEPROM Arduino Connector Sensors/PHYs, etc., TBD • I2C2 GPIO expansion ADC Sensors/PHYs, etc., TBD Certification: FCC Class B and CE What this Product is All About Product Diagram(s) Click here to Buy the LS1021A IoT Gateway Reference Design IoT Physical Components Gateways SOC: QorIQ LS1021A Boards/Modules: QorIQ LS1021A IoT Gateway Reference Design FRDM-KW24D512 Software: Linux BSP OpenWRT
View full article
Cellular Freedom Quickly move sensor data to the cloud using the FRDM-K64F End-Device certified Skywire cellular modems provide a path to production Complete mbed code provided This Demo Is Probably of Interest If You: Need a quick proof of concept Have to demonstrate cellular connectivity to a customer or client Don’t want to build your own Thing for your IoT demo Differentiation - This Demo Highlights End-Device certified modems require no Carrier certifications to use on the cellular network XBee R footprint makes your design futureproof Global options for devices deployed or moved anywhere in the world Description The NXP FRDM-K64F is the development board for the NXP Kinetis series, providing an affordable, flexible way to build prototypes. For applications requiring cellular connectivity, the NimbeLink Sensor Shield plugs into the FRDM-K64F development board and, in turn, accepts a plug-in NimbeLink Skywire end-device certified cellular modem, providing quick cellular access. This first-in-the-industry plug-in cellular solution is easier and more compact than USB or other modem connection options, and the pre-certified Skywire embedded modem eliminates the cost and complexity of obtaining carrier certifications. The NimbeLink shield comes with four integrated MEMS sensors for easy proof-of-concept development. Sensors include an accelerometer, a temperature sensor, an atmospheric pressure sensor, light sensor, a humidity sensor, an accelerometer and two pushbutton switches. The shield also provides headers similar to those on an Arduino board. These accept any of hundreds of compatible expansion boards allowing the addition of capabilities like GPS, screens, motor controllers, and more. The NimbeLink Sensor Shield requires 5-12vdc power and accepts a variety of antennas. Full Listing of Products/Components Note: For full listing or additional information for Products/Components used in this demo see "This Demo's IoT Highlights" in Left Column. Note: If you aren't looking at this demo in the IoT Solutions Center, please use below link to access NXP IoT Solutions Center: https://community.freescale.com/community/iot-center/demos/skywire-m2mmanager-demo What this Demo is All About Video Link : 4994 IoT Physical Components Gateways Boards/Modules: FRDM-K64F Software: ARM mbed End User Products: NimbeLink Sensor Shield and Skywire Modem Wireless Connectivity End-Device certified Skywire cellular modem Sensors MEMS accelerometer, temperature, humidity and pressure sensors. Light sensor, potentiometer and pushbutton switches. Cloud Infrastructure/Services Verizon ThingSpace IoT System Capabilities Cloud/App Communications/Interworking See the data from your Sensor Shield in the cloud using the Verizon ThingSpace portal on any connected device. IoT Development Capabilities Embedded Platforms NimbeLink can help you customize your cellular product design to take advantage of the latest NXP advances in technology. IoT Product Type Product/Component Vendor Research or Procure This Product/Component End User Hardware Skywire Sensor Shield Commercial Skywire Sensor Shield End User Hardware Skywire end-device certified cellular modem Commercial Skywire Modem
View full article
NXP Thread Commissioning Demo with Arrayent’s Cloud Control Thread devices can be monitored and controlled from anywhere in the world using Arrayent Connect Cloud Devices are easily commissioned onto a Thread network using NXP Thread App & QR code Devices are secure using Arrayent Unique ID (whitelisting) and AES-128 bit encryption. This Demo Is Probably of Interest If You: Want to monitor and control Thread devices that sit behind a consumer grade firewall from anywhere in the world. Want to commission Thread devices in a easy way. Differentiation This Demo Highlights Control and monitor Thread devices that sit behind a consumer grade firewall from anywhere in the world. Commission Thread devices using QR code Description The Thread network is managed by a LS1021A  IT Gateway with FRDM-KW24 Thread Border border reference design. The board supports Thread, Wi-Fi, BlueTooth and NFC too. NXP’s Thread commissioning android App discovers the Thread border router. NXP powered Thread “device” is a card with a NXP Kinetis® KW2xD 802.15.4 Wireless chip with an ARM Cortex M4 MCU board running the Thread protocol and the lightweight Arrayent Connect Agent. The Thread device boards are commissioned (or “paired”) on to the Thread network by using the NXP Thread commissioning Android App takes the device’s unique ID from the  QR code on the  device and pushes Thread network credentials into the device. This is shown again with a second card. Arrayent’s Connect Agent has been pre-loaded into the device boards.  And once the board is connected to the Thread network, the device board starts communicates directly to the Arrayent Cloud. Essentially key attributes on the board are presented up to the Arrayent Connect Cloud web services APIs. The final step is to use the Arrayent devkit app to monitor and control the device board from anywhere in the world.  In this case the we can demonstrate three monitor/control use cases: 1.     Turn on and off the device LED from the mobile app. 2.     Press a button three times to update the Apps button press counter (in this case three times.) 3.     Push the board temperature to the mobile app. What this Demo is All About Video Link : 5310 Find more information Press release: Read on The Business Journals Blog posts to read: NXP and Arrayent Collaborate to Connect Thread Devices at Embedded World, Nuremberg, Germany Thread-Enabled Smart Home Powered by Arrayent Demo Diagram IoT Physical Components Gateways SOC: NXP i.MX6 Applications Processor, NXP Kinetis®KW24D SoC Software: Embedded Linux, NXP Thread Stack for border router End User Products: LS1021A IT Gateway with FRDM-KW24 Thread Border border reference design Edge Devices SOC: NXP Kinetis®KW24D (802.15.4 Wireless chip with an ARM Cortex M4 MCU) Boards/Modules: NXP FRDM-KW24D  Development Board Software: Arrayent Connect Agent ported to the KW2xD, NXP Thread Stack for router end devices Wireless Connectivity SOC: NXP Kinetis®KW24D (802.15.4 Wireless chip with an ARM Cortex M4 MCU) Sensors SOC: KW24D On-chip Temperature, MMA8451Q 3-axis accelerometer Cloud Infrastructure/Services Software/Services: Arrayent Connect Cloud Smart Devices/Apps Software: Arrayent Android DevKit sample app and SDK Software: NXP Android Thread provisioning app IoT System Capabilities Device Management Each device is flashed at time of manufacturing a unique Arrayent Device ID and AES key.  The device ID is bound to a specific customer account at time of device commissioning. Cloud/App Communications/Interworking Arrayent devkit app talks to the Arrayent Connect Cloud’s device services interface through the Arrayent Connect Agent embedded software to connect to the device boards. The App is used to monitor and control the device board from anywhere in the world.  In this case the we can demonstrate three monitor/control use cases: Turn on and off the device LED from the mobile app. Press a button three times to update the Apps button press counter (in this case three times.) Push the board temperature to the mobile app. Security Arrayent uses device ID Whitelisting, that is Arrayent issued device ID is flashed into endpoint MCU memory at time of manufacturing.  The per device unique ID is reserved in the cloud. Arrayent ACA embedded agent and ACC cloud services support AES-128 bit end-to-end encryption with dynamic temporal key refresh. Analytics/Data The Arrayent Connect Cloud support IoT Product Type Product/Component Vendor Research or Procure This Product/Component End User Hardware USB Wireless Keyboard and Touchpad Commercial Logitech Wireless Touch Keyboard K400 with Built-in Multi-Touch Touchpad, Black End User Hardware Dell 22" HDMI Monitor Commercial Dell 22" Monitor End User Smart Device Motorola XT1032 Moto G Android Smart Phone Commercial Motorola Android Smart Phone End User Edge Device Xfinity XR2 Remote Control Unit Commercial Comcast Remote Control End User Edge Device Philips HUE Bulb ZigBee Lightlink (HA 1.2) Commercial Hue, Professional Wireless LED Lighting | Philips Lighting End User Edge Device CentraLite 3-Series Appliance Module (4257050-RZHAC) (Zigbee HA 1.2) Commercial SmartPlug End User Edge Device Axis 0301004 M1011-W camera (WiFi g) Commercial AXIS M1011-W Network Camera, a small wireless IP camera | Axis Communications End User Edge Device Maxxima Style Night Light w/ sensor Commercial Night Light End User Edge Device TP-LINK TL-MR3020 3G/4G Wireless N 150 Portable Router Commercial WiFi Router
View full article
uCP1020 IoT Gateway Module and Mbarx IoT Middleware uCP1020 IoT Gateway Module hardware Mbarx IoT Gateway Middleware TLS secure remote site connectivity Data aggregation and proxy of remote IoT devices Seamless switching between local and remote IoT sites   Mbarx System Manager GUI IoT site management tool uCP1020 IoT Gateway System-On-Module Hardware This Demo Is Probably of Interest If You: Have various remote site locations that need to be centrally connected Require remote site data aggregation and secure connectivity, across public networks Need to implement a private cloud service architecture (e.g. develop your own device interactions/workflow) Require a versatile Linux platform to deploy various gateway services Are evaluating options for RYO or commercial IoT gateway hardware Differentiation This Demo Highlights Modular, off-the-shelf IoT gateway hardware Eco-system of Mbarx IoT solutions and tools Simple, GUI driven management of remote sites Complete system-level solution for private or public cloud IoT deployments   What this Demo is All About Video Link : 4542 uCP1020 IoT Gateway Demo - Using Mbarx IoT Gateway Middleware, End-points and System Manager Tool. Demo Diagram(s) IoT Physical Components Gateways SOC: QorIQ P1020 Dual-Core Communication Processor Boards/Modules: uCP1020 IoT Gateway Module hardware Software: Arcturus Mbarx IoT Gateway middleware Arcturus management middleware  Arcturus PBX/Communications software package Arcturus Mbarx-Operations Controller work-flow management middleware Open source Linux software (Kernel mainline branch) Edge Devices SOC:2x 10/100/1000BaseT networking supported natively by the P1020 processor and on board network PHYs Modules:Various PCIe and miniPCIe based connectivity options (see wireless below) Software:Linux Wireless Connectivity Modules:GSM/LTE/HSPA/UMTS/EVDO data (depending on providers, regions and certifications).  As tested using Telit HE910 family (HEPCHGPS204T701) Modules:Wi-Fi (depending on regions and certifications).  As tested using Atheros AR9390 family. Software:Linux Sensors SOC: Peripheral connectivity supported by SPI, I2C, UART, USB, SDHC, PCIe, miniPCIe Cloud Infrastructure/Services Software/Services: Arcturus Mbarx IoT Gateway middleware is fully compatible with Mbarx IoT end-nodes such as uCMK60 based on K60, K64. Mbarx IoT protocol supports TCP/IP sockets with TLS security and simple character driven protocol Mbarx IoT Gateway middleware supports remote-site aggregation, secure connectivity and device management proxy. Optional plugs-ins for MQTT, CoAP and other popular IoT/M2M protocols. Smart Devices/Apps Software: Mbarx-Operations Controller supports cross-platform work-flow driven, operational control using a responsive HTML5 architecture. Mbarx-System Manager site-wide IoT device/node management tool is available for PCs. IoT System Capabilities Device Management Secure remote site connectivity Remote site IoT node/device aggregation Bulk device firmware updates, bulk configuration, site wide-provisioning Secure IoT node/device management and configuration Cloud/App Communications/Interworking Wi-Fi Access Point (Host AP mode), cellular data Security SSL/TLS 1.1,1.2 server and client with X.509 IoT Development Capabilities Embedded Platforms Kinetis MCUs, QorIQ 32-bit Power Architecture processors Embedded Tools Linux - kernel, driver, middleware and user space application development U-boot development and customization MQX - KSDK Services Customization and system solutions available through direct engagement - contact Arcturus Hardware and software services available - contact Arcturus IoT Product Type Product/Component Vendor Research or Procure This Product/Component End User Hardware Laptop PC Win7, Win8, Win10 or Mac Commercial Laptop PC End User Software Arcturus Mbarx System Manager Tool Commercial Arcturus Mbarx IoT and M2M Solutions End User Smart Device Arcturus uCMK60 - VoIP / IoT Board/Modules Arcturus uCMK64 - IoT Board/Modules Commercial Arcturus uCMK60 - VoIP / IoT Boards/Modules End User Edge Device TP-Link TL-SF1008P 802.3af PoE Switch Commercial TP Link TL-SF1008P End User Edge Device Linksys EA6100 Dual Band Smart Wi-Fi Router Commercial Linksys EA6100 Dual Band Smart Wi-Fi Router
View full article
Vital signs patient monitoring module using K60 Family MCU. Medical grade device, meets stringent safety / regulatory requirements Multi channel, real time data collection and processing:  Electrocardiogram, blood pressure, blood oxygenation etc. Usable as bed-side unit or part of distributed patient monitoring system This Project of Interest If You: Are interested in industrial medical products Are interested in real time analysis of live sensor data Description The module was developed as main functional part of portable patient monitor. It has a compact design, and unified serial interface to the host unit.  We developed it as a single board PC designed for main patient monitor application hosting and system purposes. The module provides comprehensive solution for patient vital signs monitoring. It has simplified connections, requiring only a power connection and a single data connection to the host or the distributed monitoring system. The design also meets the safety requirements for galvanic isolation of the patient. Kinetis K60 Family MCU was used as a core of this module, for data acquisition, signal preprocessing (digital filtration), data analysis and system tasks including extended supervisor functionality (with additional NIBP reserve/alarm system). The module has the following features: Module can be used in a bed-side unit, or part of a distributed monitoring system 7-lead electrocardiogram (ECG) (3-lead capable mode without RLD); Respiration rate (transimpedance on ECG lead I or lead II); SpO2 (oxygen saturation) using Nellcor OxiMax™ technology NIBP (noninvasive blood pressure) with patient adaptive fast measure mode for continuous monitoring, STAT mode; Body temperature, 2 channels Optional IBP (invasive blood pressure) up to 4 channels. This module meets all IEC safety requirements and is CE certified (as a part of patient monitor). Full Listing of Products/Components Protected by NDA IoT Physical Modules Sensors ECG / Respiration Blood oxygenation Blood pressure: invasive, non-invasive Body temperature Kinetis K60 MCU used for: Data acquisition Signal preprocessing and filtering Analysis, result output Supervisory functions Alarm generation IoT System Capabilities Under NDA
View full article
Smart Sensor Demo Kit Highlighted Features Multi-protocol bi-directional data stream support from/to any IP-enabled remote system Data parsing and abstraction mapping layer for normalizing data from heterogeneous devices Drag-and-drop business and analytics processing logic (akin to using Visio and Excel fused together) Report and web page builder that assembles Table reports (including data for exposure to the secure API) Time-series graphs Pie, line, spark and other chart types Uploaded visuals such as photos, CAD/CAM drawings, diagrams, schematics, etc. Full location-based services incorporating Google Maps, NOKIA here, CloudMade and Open Street Maps Business Forms assembly system so you can deploy workflow for Firmware push Remote command and control (on/off, settings, reboot, etc.) Device inventory tracking and control Asset management Financial transactions from machines Many other possibilities   Description The SeeControl Cloud Service allows embedded systems engineers to quickly assemble scalable 3-tier web applications that collect, analyze and display systems data. The service is drag and drop so you don't have to script or code to create a web app. The Service natively supports the following IoT/M2M communication protocols: UDP TCP MQTT HTTP MODBUS CoAP There is additional support for vendor-specific communication stacks such as GE, CalAmp, Sierra Wireless, etc. Customers can also create their own device adapter using protocol and language of choice. You can stream data to these data adapters at http://com2.seecontrol.com. We will give you a specific port range for each protocol/device type. You can also send your data through a device API. Guidance is here. Once the data has been received by our system. You will use a data abstraction tool to define fields that are in the packets you are sending. For example, if you send a variable field called tmp_123 from a temperature sensor you will tell the SeeControl service that tmp_123 is a a number and specifically a unit of measure called "Temperature" and then select whether Celsius or Fahrenheit. Once that is done, you can use the rest of the system to build a scalable web app, typically in 1-2 days depending on how complex our solution needs to be. To see the full range of interfaces available for visualizaing IoT data and managing devices/process, you can log in to: http://cloudx.seecontrol.com user:                fslcommunity1 password:        fslcomms1 This account only shows the visualization output, not the tools used to collect and process data. To try out the whole toolset, please acquire a full demo kit. The demo kit includes a cloud account that you can connect to the sample connectivity and sensor items listed below (or any hardware/system you would like to try out). Full Bill of Materials See bottom of this page for BOM Table Basic Data (To be filled out by FSL) Demo Number: Current Version: Current Demo Reproducibility: Intended to be Modified By: Current Demo Operation: BOM: See bottom of this page Demo Video   Freescale IoT Cloud Demo Kit     System Block Diagram   Hardware Kit & Data Flow Diagram     IoT Physical Components Gateways SOC's: i.MX6 Dual Boards/Modules: Utilite Standard Box Software: https://community.nxp.com/docs/DOC-103268 Utilite Linux BSP Connectivity Software: USB Local TCP/IP over Ethernet HTTP to Cloud Sensors End User Products: Commercial Temperature and Electric Current Sensors (See below for list) Cloud Infrastructure/Services https://community.nxp.com/docs/DOC-103268 IoT System Capabilities Device Management Add Device Remove Device Device Inventory Management Check Online/Offline Status View real time and historical messages Communications/Interworking HTTP (other protocols such as CoAP, MQTT, etc. optional) Security HTTPs (secured HTTP) Middleware / Analytics / Data SeeControl Cloud Communications & Data Mapping Tool SeeControl No Coding Analytic Engine SeeControl No Coding Visualizer Note: For additional Products/Components used in this demo see bottom of this page. IoT Product Type Product/Component Vendor Research or Procure This Product/Component Gateway NXP Utilite Standard Box NXP Contact NXP IoT Center Temperature Sensor Lascar USB Temperature Logger MicroDAQ Visit MicroDAQ Website Electrical Meter eGauge eg3000 Electric Meter eGauge Visit eGauge Website In online or phone order, please ask for SeeControl Turnkey Part Number Current Transformer(s) eGauge Current Transformers eGauge Visit eGauge Website Connectivity / Messaging Middleware SeeControl No Coding IoT Cloud Service    SeeControl Get a live demo Analytics SeeControl No Coding IoT Cloud Service SeeControl Get a live demo Data Visualization SeeControl No Coding IoT Cloud Service SeeControl Get a live demo
View full article
LS1021A IoT Gateway/Thread Border Router Demo LS1021A Gateway Reference Design operating as Thread Border Router/Gateway Connects high density Thread 802.15.4 mesh network to cloud Sensor network detects parking spot usage in large parking structure This Demo Is Probably of Interest If You: Need high bandwidth to the cloud, other gateways, etc. w/OpenWRT Need to connect a large number of low power wireless edge devices Looking to use a Thread 802.15.4 mesh to connect sensors Differentiation This Demo Highlights Ability to quickly connect Thread network to high capability Gateway Use Linux on LS1021A to display data from sensors and also post to cloud Gateway can function as a multi-protocol gateway and Thread Border Router Description This illustrative demo leverages the LS1021A-IoT Gateway and features the KW24 Freedom board attached to the onboard Arduino headers. This FRDM-KW24 communicates with the KW24 sensor boards using the Thread protocol over 802.15.4. The embedded Linux on the LS1021A-IoT can be used to display information sent and received from the KW24 sensor boards and can also forward the information to a cloud application. The demo simulates an illustrative automated parking structure system that tracks and displays open parking spaces locally for drivers, as well as remotely to allow for managing parking availability across multiple lots for activities such as major sporting and entertainment events where tens of thousands of cars need to be directed to open parking in a short period of time. Full Listing of Products/Components Note: For full listing or additional information for Products/Components used in this demo see "This Demo's IoT Highlights" in Left Column and Additional Products/Components below that. Note: If you aren't looking at this demo in the IoT Solutions Center, please use below link to access IoT Center: LS1021A Thread IoT Gateway Demo  What this Demo is All About [Demo Video is Under Construction] Demo Diagram(s) IoT Physical Components Gateways SOC: QorIQ LS1021A Boards/Modules: QorIQ LS1021A IoT Gateway Reference Design FRDM-KW24D512 Software: Linux BSP OpenWRT Edge Devices SOC: Kinetis KW24D512 Sensor Boards/Modules: FRDM-KW24D512 Sensor Prototype Board Software: Thread Stack Prototype Sensor SW Wireless Connectivity SOC: Kinetis KW24D512 802.15.4 2.4G Transceiver Modules: FRDM-KW24D512 Software: Thread Stack w/ 802.15.4 PHY/MAC Sensors SOC: Sensor Modules: Sensor Prototype Board Software: Prototype Sensor SW IoT Development Capabilities Embedded Platforms Linux BSP w/OpenWRT Kinetis SDK Embedded Tools GNU Tools (Packaged with Linux BSP) IAR Embedded Workbench for ARM IoT Product Type Product/Component Vendor Research or Procure This Product/Component End User Hardware USB Wireless Keyboard and Touchpad Commercial Logitech Wireless Touch Keyboard K400 with Built-in Multi-Touch Touchpad, Black End User Hardware Dell 22" HDMI Monitor Commercial Dell 22" Monitor End User Smart Device Motorola XT1032 Moto G Android Smart Phone Commercial Motorola Android Smart Phone End User Edge Device Xfinity XR2 Remote Control Unit Commercial Comcast Remote Control End User Edge Device Philips HUE Bulb ZigBee Lightlink (HA 1.2) Commercial Hue, Professional Wireless LED Lighting | Philips Lighting End User Edge Device CentraLite 3-Series Appliance Module (4257050-RZHAC) (Zigbee HA 1.2) Commercial SmartPlug End User Edge Device Axis 0301004 M1011-W camera (WiFi g) Commercial AXIS M1011-W Network Camera, a small wireless IP camera | Axis Communications End User Edge Device Maxxima Style Night Light w/ sensor Commercial Night Light End User Edge Device TP-LINK TL-MR3020 3G/4G Wireless N 150 Portable Router Commercial WiFi Router
View full article
JN516x-EK004 ZigBee Smart Home Kit with NFC Commissioning All necessary hardware components to demonstrate, evaluate and develop ZigBee wireless network solutions with IoT connectivity and NFC commissioning Firmware pre-loaded with demonstration software for both ZigBee nodes and IoT Gateway Free support resources for developing ZigBee applications for the JN516x microcontrollers Expandable with the addition of extra ZigBee nodes, available separately             JN516x-EK004 Evaluation Kit                               NFC Controller on Raspberry Pi Board Physical Components The JN516x-EK004 ZigBee Smart Home Evaluation Kit includes the following hardware components: Gateway Component Raspberry Pi single-board computer to act as IoT Gateway Host JN5169 USB dongle (OM15020) to act as ZigBee Control Bridge Wi-Pi Raspberry Pi dongle for Wi-Fi connectivity NFC controller (PN7120) for NFC commissioning of ZigBee nodes ZigBee Node Components Carrier boards (OM15022) to accommodate expansion board and ZigBee JN5169 module, and incorporating NFC connected tag (NTAG I 2 C) including NFC antenna ZigBee modules (JN5169-001-T00/T01) providing processing platform and RF interface Generic expansion board (DR1199) with switch and level control functionality Lighting/Sensor expansion board (DR1175) with white light, colour light and sensor functionality Software Pre-loaded ZigBee Smart Home demonstration Flash programming utility for firmware re-programming Software Developer’s Kits (SDKs) for developing applications for JN516x microcontrollers Eclipse-based Integrated Development Environment (IDE) for easy application development Application Notes containing example applications and templates This Demo Is Probably of Interest If You: Work with Home Automation, Smart Energy or other similar IoT applications Need a state-of-the-art ZigBee solution Need a secure and convenient way to commission devices to your ZigBee network Key Benefits of Kit All-in-one kit to rapidly get started with your ZigBee application development Leverages NXP NFC solution to commission ‘smart nodes’ out of the box, securely and in just one tap Comprehensive support software and collateral for developing custom ZigBee solutions with IoT connectivity Video Link : 4980 JN516x-EK004 Evaluation Kit Leaflet JN516x-EK004 Evaluation Kit User Guide JN5169 ZigBee Wireless Microcontroller JN5169 USB Dongle for ZigBee (OM15020) ZigBee 3.0 Wireless Network Protocol ZigBee Generic Node Expansion Kit (JN5169XK010) ZigBee Lighting/Sensor Node Expansion Kit (JN5169XK020) NFC Controller (PN7120) NFC Connected Tags (NTAG I 2 C)
View full article
IoT Physical Components Gateways SoC i.MX 6UltraLite                                  Volansys Modular Gateway NXP Modules Supported PN7120 NFC, JN5169 ZigBee   Protocols Supported ZigBee, Thread, Bluetooth, Wi-Fi   User Compatibility MikroBus™ Compatible   Network Connectivity Ethernet, Wi-Fi   Form Factor 100mm x 150mm   Applications Smart Home Smart Building Smart Security Smart Healthcare Smart Energy     SOM MODULE SoC i.MX 6UltraLite                                                   Volansys i.MX6UL SOM for Modular Gateway Memory DRAM, DDR3, NAND Flash, EEPROM, eMMC I/O Interfaces CAN, I2C, SPI, UART, SDIO, PWM, JTAG, SAI, S/PDIF Form Factor 67.6mm x 45.0mm x 5.0mm Applications Energy management Systems IoT gateway Solutions Industrial HMI & Access Control Industrial control & automation Medical & Healthcare equipment Smart appliances Mobile POS & Secure e-commerce KW2XD Module SoC MKW24D512   Volansys KW24D Module (for use with Modular Gateway) or Edge Devices NXP Modules Supported Kinetis® KW2xD Applications Smart Energy M2M Automated meter reading Medical Network HVAC Control Lighting control Asset tracking Environment monitoring and control Protocols Supported Thread User Compatibility MikroBus Compatible Form Factor 24mm x 19mm   KW41Z Module SoC KW41Z512VHT4   Volansys KW41Z Module (for use with Modular Gateway) or Edge Devices     NXP Modules Supported Kinetis® KW41Z Protocols Supported Zigbee, Thread, Bluetooth User Compatibility MikroBus Compatible Form Factor     21mm x 16mm Applications Extremely low-power embedded systems Portable health care devices Wearable sports Fitness devices Computer keyboards and mice Gaming controllers Access control Security systems Smart energy Home area networks Automated meter reading Medical Network HVAC Control Lighting control Asset tracking Environment monitoring and control EDGE DEVICES NXP Modules Supported JN5169 , MKW2xD, MKW41Z   Volansys Modular Edge Node Platform (Supports Same Radio Modules as Modular Gateway) Protocols Supported Thread, ZigBee and BLE User Compatibility MikroBus Compatible Form Factor 74.98mm x 49.99mm Applications Smart Home Buildings Industries What this Demo is All About Video Link : 7307 Modular in design MikroBus Compatible Modules Supports ZigBee, Bluetooth, BLE, Thread, Wi-Fi (SigFox & Lora WAN coming soon) Seamless Integration of your module in our gateway Plug & use our modules to convert your products to solutions      Volansys' NXP Specific Capabilities Presentation. Volansys has created a KW2xD Thread ready module using NXPs' Kinetis KW22D512 Processor for adding thread support on Gateway. The Above Demo reflects controlling of NXPs' Thread End Devices through Volansys Gateway using a mobile application. The mobile application is developed on Android which can control the Thread End Devices sensors (LEDs, Accelerometer, Switch Press) Built using the IAR compiler Volansys IoT Gateway is a production ready modular design with effortless implementation and modification to manufacture your product and also provide a Connectivity solution to your product. KW2xD is a Thread ready module with MikroBus Compatibility for easy integration to convert your products to  Thread ready solutions. KW41Z is multi protocols supported module (Zigbee + Thread + BLE) with MikroBus Compatibility. NXPs' NFC Tap Commissioning helps faster connectivity to the Gateway. Volansys Gateway is also integrated with Amazon Alexa for controlling the IoT end devices using voice for effortless communication for the user. Volansys Overview Presentation Reach out to us If you have any questions or comments, don't see exactly what you need, etc. please feel free to follow up with one of our IoT product managers directly, the IoT Solutions Center Follow Up Team, or the IoT Solutions Center Community: NXPIOTCTR@nxp.com
View full article
This post entry aims at explaining the debugging process oriented to EMVCo Contactless certification of a device integrating NXP's PN5180. The structure is the following: PN5180 Antenna design considerations Before going into the debugging process for the EMVCo Contactless Analog tests we will see some important considerations for an antenna design and impedance tuning oriented for an EMVCo compliant device. Antenna tuning recommendations The first recommendation is that with the Dynamic Power Control feature the PN5180 allows us to perform symmetrical antenna tuning instead of the typical asymmetrical tuning. This symmetrical tuning provides us with a better transfer function, being able to drive more power to the antenna. The following figure shows the Smith Chart with the S11 parameter plot of a device using a symmetrical antenna tuning:   The only disadvantage of the symmetrical tuning is that we need a current limiter to avoid destroying the chip because of exceeding the chip’s limits. In the case we are documenting today, the PN5180 DPC feature is used to limit the supply voltage and therefore the transmitter current depending on the load detected by the chip. Regarding the EMC filter, the inductor should fit with the following condition to guarantee a good relation between the AGC and the ITVDD: Another consideration is about the resistor used in the reception branch. This resistor controls the receiver sensibility and as a starting point is recommended to use a value to obtain an AGC in free air of: Reader Mode only design: AGC value in free air around 600dec Full NFC design: AGC value in free air around 300dec Finally, EMV contactless transactions are performed at 106kbps which would allow us to work with a high Q factor of the overall system. This means that the power gain can be higher, but at the same time it might also lead to some issues because of the lower bandwidth. In light of this, we have to bear in mind, that if the Q factor is too high it may lead to problems in the waveform tests. PN5180 DPC calibration The Dynamic Power Control is a feature that uses the AGC value to establish different power configurations depending on the load applied to the antenna. As I mentioned before, the main goal is to protect the chip from a transmitter current level that might destroy it. The first step before calibrating the DPC is to check the correlation between the AGC value and the transmitter current or ITVDD when different loads are applied to the antenna. Basically, we will play with the distance between the load and the device to get several points with different AGC values. Based on those measurements, we can plot a graph like the following: Normally we would use a reference PICC and a metal plane or phone to check that the behavior is linear and with no big difference between those loads. Once we have checked the correlation we can proceed with the calibration process, which can be done very easily with the NFC Cockpit software. Here the important thing is to control the ITVDD and keep it always below the chip’s limit. As you can see in the figure below, without the DPC, this symmetrical tuning would lead to a voltage above the limit for positions close to the reader antenna. However, with DPC we can control that voltage at any moment. Another consideration is that we have to make sure that the DPC is calibrated to have maximum power when the reference PICC is far from the reader to avoid a lack of power in the tests at those positions. EMV L1 Analog Tests Debugging process We are going to divide this debugging process into 3 main phases which are the power tests in the first instance, followed by the waveform tests and the reception tests. The reason why we set this order is to first debug the tests that may require HW modifications which have a strong impact on the other tests. This way, for example, if you have passed all power and waveform tests, debugging the reception tests may not have an impact on the results obtained previously. Power tests Tests setup In order to debug the power tests, we will need just an oscilloscope and an EMVCo reference PICC. We will need to connect the outputs J9 and J1 of the EMVCo reference PICC to the oscilloscope and set the jumper J8 of the reference PICC in non-linear load mode. The J9 of the EMVCo reference PICC is the DC_OUT output that we will use to measure the power received by the antenna. The J1 is the LETI_COIL_OUT output and we will use it to capture the command in the oscilloscope. The overall setup is depicted in the figure below. Performing tests We have to use the trigger to capture the REQA command sent from the DTE when the reference PICC is in the position we want to test. This capture can be seen in the two figures below. The yellow channel is the LETI_COIL_OUT of the EMVCo reference PICC and the blue channel represents the DC_OUT obtained from the J1 connector. As said previously, we will use the DC_OUT to measure the voltage in the period of the signal where there is no modulation, like this part highlighted with the red squared. We have zoomed into the period to get the average value using the oscilloscope measurement features. We will use this same procedure to evaluate the power tests in all positions. Depending on the position tested, the specifications define and certain range where the voltage measured should be fitted. In this sense, the maximum voltage level is common for all planes, but the minimum voltage allowed will decrease for positions further from the terminal.  In order to identify the critical positions for the power tests, we have to identify two different scenarios, the first one with the positions that might not reach the minimum voltage established, and the positions that might exceed the maximum value. For the first scenario the critical positions are the outer positions of the plane z = 4cm and the plane z=3cm as the external positions for plane z= 3cm have a bigger radius. The other scenario is that where you can be exceeding the maximum level. This situation can happen in the central positions of the lower planes, like plane z=1 or z=0. Debugging hints In order to overcome possible issues, we will give some tips that can be used for your design. Regarding a case of lack of power, first, we have to make sure that the DPC is correctly calibrated, meaning that you are operating in gear 0 for the external positions of planes 3 and 4 and that gear 0 is operating with full power. If we have verified those two things and we still have issues, we would need to change the tuning of the antenna and reduce the target impedance. This is graphically represented in the following Smith Chart: By reducing the impedance we increase the current that the PN5180 is driving to the antenna so the voltage would increase. Is important to always verify that we are working within the recommended operating range of the chip and that we are not exceeding the transmitter current limit. In a worst-case scenario, if we cannot achieve the voltage with these HW changes we would need to evaluate changes in the hardware design, like adding a ferrite sheet or changing the antenna dimensions or position. On the other hand, if the problem comes because we are exceeding the maximum voltage allowed by the specifications we can easily solve it by reducing the power configuration of the gear used in that specific position. Waveform tests Test setup For the waveform group of tests, we will use a setup consisting of the EMVCo reference PICC along with an oscilloscope and a PC software to evaluate the signal obtained from the oscilloscope. In our case, we will use the Wave Checker software from CETECOM. We need to connect the output J9 of the EMVCo reference PICC to the oscilloscope and set the jumper J8 of the EMVCo reference PICC in the fixed load position. The oscilloscope needs to be connected to the PC or laptop, so the software is able to get the waveform and analyze the parameters needed. Type A tests The waveform group of tests for Type A consists of the following test cases: TA121: t1 TA122: Monotonic Decrease TA123: Ringing TA124: t2 TA125: t3 and t4 TA127: Monotonic Increase TA128: Overshoot Some of these test cases are directly related to the parameters defined for the specific modulation phase for Type A at 106 kbps. This modulation phase along with the respective parameters is depicted in the figure below. When the Wave Checker gets the oscilloscope capture, it automatically analyzes the signal, performing all the measurements and comparing them with the specifications limits. Debugging hints for Type A The PN5180 has a few registers and parameters to control the wave shape generated by the NFC chip and transmitted by the antenna. These are the most relevant ones: TX_CLK_MODE_RM (RF_CONTROL_TX_CLK register) Rise and Fall times (RF_CONTROL_TX register) TX_OVERSHOOT_CONFIG register From all the different test cases we will show how to debug the t3 and t4 test case as it is usually the most problematic. For this purpose, we will start from a certain configuration where the waveform tests show the following results, with a fail in the t3 and t4 test case. In order to tackle this problem, we will rely on the TAU_MOD_RISING parameter from the RF_CONTROL_TX register of the PN5180. In this case, as the timings are slightly above the maximum allowed in the specifications we will decrease the TAU_MOD_RISING 3 points and execute again the tests. The results after the modification show that all test are passing with a certain margin:   Another parameter that the PN5180 has and can be used for the waveform tests is the TX_CLK_MODE_RM parameter from the RF_CONTROL_TX_CLK register. Below you can see two graphs that clearly illustrate the effect of this parameter over the waveform.  As you can see from the two figures, by changing the default high impedance configuration of 001, to a low side pull configuration the waveform results in a smoother decay of the envelope. Type B tests For Type B waveform, the specifications define the following test cases:  TB121: Modulation Index TB122: Fall time TB123: Rise time TB124: Monotonic Increase TB125: Monotonic Decrease TB126: Overshoots TB127: Undershoots Again, these tests are based on the different parameters that can be identified for the modulation phase of the Type B commands: Debugging hints for Type B The register and parameters that the PN5180 includes to control the waveform for type B are: TX_RESIDUAL_CARRIER (RF_CONTROL_TX register) TX_CLK_MODE_RM (RF_CONTROL_TX_CLK register) TX_UNDERSHOOT_CONFIG register TX_OVERSHOOT_CONFIG register For Type B, we will study the modulation index test case, as it is the one that needs to be adjusted more often. In this case, we start from a situation where the device presents problems in the modulation index at 1 cm, with a value below the limit. In order to make corrections of the modulation index we will use the TX_RESIDUAL_CARRIER parameter from the RF_CONTROL_TX register. This parameter controls the amplitude of the residual carrier during the modulated phase. For the present problem, we will increase it by 4 points and rerun the test. As you can see in the picture below, the modulation index is within the specifications limits with margin.  Adaptative Waveform Control The PN5180 has another interesting feature called Adaptative Waveform Control that is used to set a different transmitter configuration depending on the gear and protocol used at any moment. This way we can easily debug by positions and use specific configurations for a certain group of positions without the need of rerunning all the tests for the rest of the positions. With the AWC feature we can control the: TAU_MOD_FALLING TAU_MOD_RISING TX_RESIDUAL CARRIER We can see in the table an example of an AWC configuration for Type B. Where we have changed the Residual Carrier from gear 2 onwards. As you can see, It is also configured with a change in the falling and rising times from Gear 1. As you can see this Adaptative Waveform Control feature along with the DPC represent a powerful tool to easily debug waveform tests without a change in the HW. Reception tests The reception tests purpose is to evaluate the ability of the device to identify and correctly demodulate the responses from the PICC when this response comes in the limits of the specifications for amplitude and polarity of the modulation.  Tests setup The tools and setup needed to debug the reception tests for EMVCo are depicted in the following figure: Oscilloscope to capture the signal received by the reference PICC. Arbitrary Waveform Generator to generate the response of the PICC. PC Software to control the AWG and load the EMVCo responses to the EMVCo reference PICC. For our case, we will use the Wave Player software from CETECOM. EMVCo reference PICC. This time, we will use the output J9 of the reference PICC to the oscilloscope to capture the command from the reader and trigger the injection of the response from the waveform generator to reference PICC, connected to J2. We should connect the waveform generator to the computer that has the Wave Player software installed to load the EMVCo responses. Performing tests As said previously, the reception tests aim at testing the ability of the device to correctly interpret the response when it is generated at the limit of the amplitude and polarity of the modulation. Considering the positive and negative polarity and the maximum and minimum amplitude of the modulation we have the following four test cases that are performed both for Type A and Type B: Tx131: Minimum positive modulation Tx133 - Maximum positive modulation Tx135 - Minimum negative modulation Tx137 - Maximum negative modulation To debug these tests with the PN5180 we will use: RX_GAIN (RF_CONTROL_RX register) RX_HPCF (RF_CONTROL_RX register) MIN_LEVEL (SIGPRO_RM_CONFIG register) MIN_LEVELP (SIGPRO_RM_CONFIG register) The procedure is basically to use the Waveplayer to set the amplitude and polarity of the response and check in the device is the response was correctly received and demodulated. Debugging hints To debug the reception we will test different configuration for the RX_GAIN and RX_HPCF parameters that control the reception filters, amplifier and ADC blocks from the receiver branch. These receiver blocks are pictured in the diagram below. Depending on the values used for the RX_GAIN and RX_HPCF parameters, the filter will be defined accordingly. The following table shows the filter characteristics in relation to those values: If we don’t find a correct value to pass the test at a certain position, we should modify the Rx resistor in order to increase or decrease the receiver sensibility. Adaptative Receiver Control In the same line as the Adaptative Waveform Control, the PN5180 includes the Adaptative Receiver Control that can be used to define different reception configurations depending on the gear and protocol used. With the ARC we can control all the registers involved in the reception and apply a correction to the preconfigured value depending on the gear used.  We can see an example of the Adaptative Receiver Control configuration in the following table, where we have defined a correction of -1 to the MIN_LEVEL and the HPCF parameters from gear 1. We can also see that the RX_GAIN parameter has a correction of +2 from gear 0. The ARC is very useful when we can't find a proper configuration for all positions and we need a different set of values depending on the positions tested. Rx Matrix tool Another interesting tool for debugging the reception tests is the Rx Matrix tool. This tool is used to launch and tests different receiver configuration in an automated way. The Rx Matrix tool is integrated into NXP's NFC Cockpit and you can control the Arbitrary Waveform Generator to set the amplitude of the modulation used for the tests. We can select which parameters we want to change and in which range we want them to be tested and the Rx Matrix will automatically run all the possible combinations in a sweep.   With the Rx Matrix tool, we can select the expected response and the number of iterations we want to try for every possible configuration. That way we can obtain a success ratio for the communication and easily identify the best configuration for the position tested. An example of the Rx Matrix is given in the figure below. We have fixed the RX_GAIN and RX_HPCF parameters and performed a sweep for the MinLevel, testing it from a value of 0 to 8. We have set the Rx Matrix to execute 50 iterations for every configuration, obtaining the success ratio results plotted below. As you can see the Rx Matrix along with a Waveform Generator is a powerful tool to find the optimum receiver configuration in a short time and in an effortless way. PN5180 Ecosystem The PN5180 comes with a complete and useful product support package including: The demokit, that can be used to get introduced to the product and check its features. The NFC Cockpit, that we have talked about during this article, and that represents a powerful tool to control the PN5180 with a very intuitive and useful interface. We srongly recommend that you integrate this tool in your final device as it may save you a lot of time during the debugging phase. A complete documentation including the updated product datasheet, or a set of application notes to guide you through all the designing process, from the antenna design guide to the DPC configuration or use of the Rx Matrix tool. Last but not least, the NFC Reader library which is the recommended software stack for NXP's NFC frontends and NFC controllers with customizable firmware. NFC Reader Library The NFC Reader Library comes with built-in MCU support, but it can also run on different MCU platforms, as well as non-NXP. The library has been built in such a way that you can adapt it and implement the required driver for your host platform. Other characteristics are: It is free of charge and you can download the latest release from NXP’s website. It is a complete API for developing NFC and MIFARE-based applications. Includes an HTML-based API documentation for all the components, which is generated from source-code annotations.  Finally, the release includes several examples and applications. Among the examples and applications included in the NFC Reader Library we can highlight two applications that are very useful for the preparation of the Device Test Environment required for the EMVCo certification:  The SimplifiedAPI_EMVCo for the digital testing The SimplifiedAPI_EMVCo_Analog for the Analog testing. You can control all the parameters involved in both applications using the phNxpNfcRdLib_Config.h configuration file. The identification and modification of these parameters should be very easy as the code is well documented, like you can see in the code chunk in the image: Further information You can find more information about NFC in: Our NFC everywhere portal: https://www.nxp.com/nfc You can ask your question in our technical community: https://community.nxp.com/community/identification-security/nfc You can look for design partners: https://nxp.surl.ms/NFC_AEC And you can check our recorded training: http://www.nxp.com/support/online-academy/nfc-webinars:NFC-WEBINARS Video recorded session
View full article
This post entry provides a guide to designing antennas for the NTAG I2C plus. This article has been structured as follows: How the NTAG I2C plus works The NTAG I2C plus is what we call a connected NFC tag. It combines a memory, a passive NFC interface and a contact I2C interface. Additionally, it has more features such as: A field detection pin, to send a wake-up signal to a connected MCU The Energy harvesting, able to power external devices The SRAM, a memory without writing cycles limitation The pass-through mode, for fast data exchange between interfaces Memory access control options, available from both NFC and I2C interfaces And the originality signature, to protect your brand against clones As such, it supports bidirectional communication between an NFC-enabled device and the host MCU and it is an ideal solution for Industrial applications, IoT nodes, meters, consumer electronics and accessories among others.  To enable the NFC interface, the chip needs to be connected to an antenna coil using the two dedicated antenna pins. How to design this coil is the main goal for today. NTAG I2C plus antenna design files The NTAG I2C plus support package includes development kits, demo apps, sample code, application notes, and, the design files of the Class 4 PCB antenna, and the Class 6 Flex antenna, which are available for direct and free download from the website.   These design files include: The schematics  The Gerbers The BoM Therefore, if you do not have any antenna size or shape constrains in your application, the easiest is to just copy & paste these reference antennas. On the other hand, if you need to design your custom antenna, NXP also offers a coil design Excel sheet to help you. I will talk more about it along the article. Basic antenna theory for NTAG I2C plus tags The NTAG I2C plus is an 8-pin package, with: The field detection pin The Vout pin The I2C serial clock and data Iines to the MCU The ground The VCC wo antenna pins NTAG I2C plus electrical input capacitance The NTAG I2C plus equivalent circuit can be represented with: A resistor, representing its current consumption And a parallel capacitor, representing the chip internal capacitance For the NTAG I2C plus, this capacitance is 50pF for both the 1k and 2k memory versions. Precisely, the chip capacitance is the most important factor for the antenna tuning. Antenna coil electrical equivalent circuit The antenna coil itself is a resonant circuit with an input impedance. The electrical equivalent model of the antenna coil consists of: An inductance A capacitance And some resistive losses of the loop antenna itself. The actual impedance value depends on:  The antenna material The thickness of the turns, mainly affecting the resistance  The distance between the windings, mainly affecting the capacitance The number of turns, mainly affecting the inductance  And the nearby environment Tag with an NTAG I2C plus electrical equivalent circuit When the NTAG I2C chip and the antenna coil are assembled, we can consider a parasitic resistance and capacitance generated by the connections between the chip and the antenna. This parasitic impedance depends on the assembly process used and the antenna material.  As a result, what we can observe in the schematic of the figure is that the NTAG I2C plus capacitance together with the parasitic connection capacitance and the antenna capacitance forms a resonance circuit with the inductance of the antenna coil.   The self-resonance frequency of a system is given when the imaginary part of the circuit equivalent impedance is null, and the system is only purely resistive. Considering the antenna loop inductance, the parallel equivalent capacitance and the parallel equivalent resistance of the tag, the resonance frequency and the quality factor of the tag can be calculated by these formulas. Antenna design procedure for NTAG I2C plus tags The antenna design procedure for the NTAG I2C plus tags is:  Design the antenna coil. This is about the antenna specs in terms of number of turns, track width, spacing, shape, etc according to your application requirements. Characterize the antenna coil and find its R, L, and C parameters. Calculate the parallel capacitor value required to adjust the tag resonant frequency Assemble the calculated capacitor and measure the results. If the results are not accurate enough, fine-tune the capacitor value, assemble and measure again as needed. Design the antenna coil  As part of the ISO14443 standard, six PICC antenna classes are defined. Per each of the antenna class, the physical characteristics and dimensions are defined. For instance, Class 1 is the largest, with a size comparable to the size of a regular credit card, and Class 6, which is the smaller one. In addition, Class 3 to Class 6 define two antenna shapes: a rectangular and a circular one. However, tag manufacturers are not constrained to conform to any of these dimensions. Therefore, its use is optional and rather intended to improve interoperability. As such, you may consider using these antenna sizes as a reference for your designs. The major parameter of the antenna coil is the inductance. This inductance can be estimated based on geometrical parameters and the material properties such as: The diameter for a round antenna or the overall length and width for a rectangular shape. The track width The gap between track The thickness And the number of turns To avoid cumbersome formulas, NXP offers you an Excel-based coil calculation tool to estimate the inductance of rectangular and circular antennas. This tool uses some parameters related to the material used and the antenna dimensions. And with it, it estimates the antenna inductance for you. Typically, the coil design steps include: An estimation of the electrical parameters, like the operating frequency and the chip capacitance The definition of the target inductance, we define the dimensions, the track width, the gap between track, the thickness, etc that achieves our target inductance. The production of prototypes. Based on the matrix run, with different inductance values deviated between 10-20% plus and minus the original value. Characterization of the coil prototypes. Based on this characterization, select the one with the best parameters for your application.  If needed, you can execute a second matrix run, with new prototypes, based on the first results. Measure the antenna coil parameters The antenna characterization can be done using a network analyzer connected to the antenna pads, isolated from the rest of the circuit. For our case, a low-end solution, such as the miniVNA PRO is sufficient. This device is cheap compared with the high-end devices like Agilent but still, accurate enough for our needs.  As a remark, it is fundamental that this characterization is done with the antenna placed at its final mounting position, so that all environment effects, like metal plates or others, are considered. Calculate the resonant capacitor value We use a network analyzer to measure the system resonant frequency after connecting the NTAG I2C plus to the antenna coil. As I explained before, the self-resonant frequency of the tag is given when the system is purely resistive. Most likely, the actual resonant frequency will not be 13.56MHz as we would like, but some other value. If that is your case, calculate the system capacitance at the current resonant frequency based on the equation derived from the NFC tag equivalent circuit shown previously. At this point: We know the current resonant frequency We know the antenna inductance, because we measured it before with the network analyzer And, as design parameter, we define the target resonant frequency With this data, we can use once again, this formula to calculate which is the resulting capacitance that would make our tag resonate to our target resonant frequency. Knowing the required total capacitance and the actual capacitance, we can calculate the extra capacitance missing. This is given by this formula: Regarding the target resonant frequency, for single tag operation, a tuning slightly above 13.56 MHz would lead to maximum read-/write distance. However, due to manufacturing tolerances, a nominal frequency up to 14.5 MHz would still operate well. Assemble and measure resonant frequency Therefore, the last steps are: Solder the capacitor in parallel Connect the network analyzer And measure the new resonant frequency  If the resonant frequency measured is not the target one, repeat the process by fine tuning the capacitor value.  If the frequency is higher than expected, you can increase the capacitor value. On the other hand, if the frequency is lower than expected, you can decrease it. Example: Tuning for a 54x27mm PCB antenna Based on a real lab exercise, this section illustrates the steps to adjust the tuning of an antenna for the NTAG I2C plus. As described before, we need to start by characterizing our antenna coil. In this lab exercise, we have used a PCB antenna of 54 by 27 mm and, we have connected our miniVNA PRO to the antenna pads. The results that we have obtained from this measurement are that our PCB antenna has an inductance around 895 nH. After characterizing the antenna coil: We have soldered the NTAG I2C plus chip to this PCB antenna. Right after, we connect again the miniVNA PRO to measure the actual resonant frequency.  In this case, it returns a resonant frequency near 24 MHz. Using the formula, we calculate that the tag capacitance at 24 MHz is almost 50 pF. Note that, the actual capacitance is basically the chip capacitance as the antenna and connection capacitance is usually not impacting significantly. Obviously, a resonant frequency of 24MHz is way too high for a ISO14443 NFC tag like our NTAG I2C plus. Therefore, we need to add some capacitance to the system so that we can bring this resonant frequency down. As an example, for this lab exercise, we are adjusting the tag to around 13.6 MHz, intentionally a bit higher than the NFC operating frequency. With a target resonant frequency to 13.6MHz and an antenna inductance is around 895nH,  the result is that the tag needs a total capacitance of around 153 pF. This means that we need to solder an extra capacitance of 100pF to bring down the resonant frequency.  So we go to our component box, and select the closer commercial value (100pF). As a last step, it is worth to measure how well adjusted is our system after adding the 100pF. We connect the miniVNA to the system including the IC, the antenna and the 100pF. Now, the results obtained are that the resonant frequency is 13.8 MHz. In our case, we consider this as good enough. However, you are always free to repeat this process as many times as needed until you obtain the accuracy that you need. Summary The antenna tuning steps for the NTAG I2C plus that we followed are: Design the antenna coil. You can use the NXP reference antennas or design your own antenna coil using the NXP Excel-based calculation tool. Measure the antenna coil. Use a network analyzer connected to the antenna pads, without any other circuitry Calculate the extra capacitance. Measure the current resonant frequency, and we calculate the extra capacitance needed to achieve the desired operating frequency. Solder and measure. If the results are sufficient, you are done. Otherwise, repeat the process with a new capacitance value As you can see, the antenna tuning process is quite straight forward. Basically, it is a matter of adjusting the capacitance of the tag until the operating frequency is the right one. Further information You can find more information about NFC in: NTAG I2C plus website http://www.nxp.com/products/:NT3H2111_2211 NTAG antenna design guide support package https://www.nxp.com/docs/en/application-note/AN11276.zip NXP technical community: https://community.nxp.com/community/identification-security/nfc NXP design partners: https://nxp.surl.ms/NFC_AEC Video recorded session On 25 July 2018, a live session explaining this topic was delivered. You can watch the recording here:
View full article
This post entry provides a detailed description of the OM29263ADK kit, a new antenna tuning development kit specially designed to facilitate the NFC antenna prototyping process. This document has been structured as follows: OM29263ADK kit contents This kit consists of a single PCB board that includes:  A pre-matched antenna of 2 turns and a size of 77 by 113 mm.  A second pre-matched antenna of 4 turns and a smaller size of 20 by 20 mm.  And, 8 extra boards to prepare the matching for custom antennas. As a result, this kit is a perfect resource for different purposes such as evaluating the RF performance of different antenna sizes and, for prototyping your custom antenna quickly. In addition, this NFC antenna development kit is compatible with our existing product support package. You can directly connect it to CLRC663 demoboards, as well as to PN5180 and PN7462 demoboards after a minor tuning. Using OM29263ADK kit with CLEV6630A or CLEV6630B The process is really straightforward… First, take one CLRC663 demoboard and separate the main PCB from the antenna & matching circuit. The board includes cut lines, so you can divide both sections easily by only using your hands. Second, break the kit OM29263ADK PCB so that you separate the pre-matched antenna from the other PCB parts. Then, it is just a matter of connecting the two parts together. The kit antenna includes pin male connectors while the CLRC663 board includes the corresponding female connectors. Therefore, hook up the antenna with the main board, solder the connectors and that’s all. We can observe that when we connect the kit large antenna to the reader PCB, the  impedance measured with our network analyzer shows that the tuning is adjusted to approximately, 19 Ohms. This is the result obtained without any hardware modification The same process applies for the smaller antenna: Similarly, we can observe that when we connect the kit small antenna to the reader PCB, the  impedance measured with our network analyzer shows that the tuning is adjusted to approximately, 36 Ohms. This is the result obtained without any hardware modification: Using OM29263ADK kit with PNEV5180B or PNEV7462C In case you are interested to connect the OM29263ADK kit antennas to the PNEV5180B or PNEV7462C boards, the preparation process is the following: First, separate the antenna and the matching section from the PN5180 or PN7462 demoboards, as before, using the cut lines. Then, take one kit sample, and separate the pre-matched antennas for the other PCB parts. And finally, adjust the EMC filter. The EMC filter adaptation is required because the kit antenna is prepared for asymmetric tuning while the PN5180 and PN7462 original antenna use a symmetrical tuning. The main difference between both types of tuning is the cut off frequency. The symmetric tuning uses a cutoff frequency around 15MHz, while the asymmetric can go up to 22 MHz. In practice, for this adaptation, we only need to change the value of the capacitor C0 in the main board. For instance, the existing 220 pF capacitor can be replaced for another one of 68 pF. Using OM29263ADK kit to connect your own antenna coil This section describes how to use the kit PCB boards for our custom antenna tuning. For this task, the list of material that we need is: A reader PCB board, in the example, we picked CLRC663 One of the PCBs for antenna matching included in the kit And, the any antenna to be matched  In our case, we have selected one sample antenna available in our lab. The following explanation will be guided using this antenna as a reference, but any antenna can be tune using the same process. The usual list of steps to tune a custom antenna are: First, we need to define target impedance and Q factor, as design parameters for our reader Then, we will characterize the antenna coil and find its parameters After that, we will design the EMC filter With this, we will calculate the matching components using an Excel sheet Afterwards, we will assemble the calculated components and measure the first results. We will take field measurements, which probably will show that it is not perfect, so we may need to adapt the matching values With these fine-tuned vales, we will re-assemble again And finally, we will design the receiver circuit. Define target impedance and Q-factor First, we start defining the target impedance and Q-factor. The target impedance is a design parameter, which needs to be chosen according to our needs whether we want to go for maximum field strength or minimum battery consumption or a trade-off in between. Typically, reasonable values are between 20 Ohms and 80. Another important design parameter is the Q factor. The Q factor is a dimensionless parameter indicating the performance of a resonant circuit. The higher the Q factor, the higher the read range. On the other hand, increasing the Q factor also reduces the bandwidth of the circuit. As a result, in practical implementation, Q-factor values below 30 are demonstrated to fit well for the ISO14443 wave form timing requirements and corresponding spectrum.  For our tuning exercise, the design parameters chosen are an impedance of 20 ohms and a Q factor of 25 Measure antenna coil Next step is to characterize the antenna coil. Any antenna coil has an input impedance. This input impedance is complex and consists of an inductance, capacitance as well as some losses represented by a resistance (R). The actual values depend, among others, on antenna material, thickness of conductor, distance between the windings, number of turns, etc.  The coil characterization needs to be done with a network analyzer. It could be a high end, such as Agilent or Rohde & Schwarz, which is powerful, accurate, easy to use, but expensive. Or we can also go for low end solutions, such as the miniVNA PRO, which is cheap compared with the previous ones, and accurate enough for our needs. In our case, the characterization of our lab antenna shows:  An inductance around 1.3 uH And a resistance of 2.5 Ohms Design EMC filter The next step is to design the EMC filter. As we are using CLRC663, we will go for an asymmetric antenna tuning. Good inductor values are between 330nH and 560nH. and 21MHz cutoff frequency is ideal for asymmetric tuning. Fixing this two parameters, we can easily calculate the required capacitor component for our EMC filter with the formula below. In our example, we need to use a capacitor of C= 122 pF. With this, we just pick up the closer commercial value from our components box Calculate matching circuit components We have characterized the antenna coil and completed the EMC filter. Now, we can calculate the matching network components. The matching components need to be calculated so that the maximum power from the reader is transmitted to the antenna. This happens when the equivalent impedance seen from the reader IC only has the real part, without the complex part. There are some complex calculation involved in the process. In order to avoid these cumbersome formulas, NXP provides a useful Antenna Tuning excel sheet that calculate the appropriate components for you. Below, you can see a screenshot of the Excel sheet in the slide. This sheet calculates C1 and C2 matching values according to the inputs expected from the user. These are The measured antenna coil parameters The EMC filter parameters. The target impedance and Q-factor of our design With these values, The Excel sheet calculates and outputs the value of the matching components: C0, C1, C2 and Rs. In our exercise, the output values calculated for the matching network by the Excel sheet are C1 around 43 pF and C2 around 144 pF Assemble and measure Typically, the calculated values do not match with commercial components. The easiest way is to add components in parallel to get as close as possible to the calculated values. If we take a closer look to the kit antenna matching PCB board, the pad location is the following: We have two slots for C0 – so we can have two capacitors in parallel to achieve a better accuracy on the capacitance value we need to achieve We also have two slots for C1, for the same purpose We have two more slots for C2 soldering We also have two slots for the dampening resistor, in case we need to reduce the Q-factor of our antenna. And finally, one slot for the receiver resistor circuit. After the first component assembly, it is worth performing a field measurement to find out how accurate our matching is in reality. Typically, the measured impedance is different than the impedance calculated in the simulation. Therefore, the calculated matching components were not 100% accurate. But we knew that in advance. We were aware that we were just getting a rough approximation to the antenna parameters. As a result, a good matching is achieved after a number of iterations according to the field measurements that we obtain. As a general rule,  C1 changes the magnitude of the matching impedance and C2 changes its imaginary part. In our exercise, after soldering the first components, the equivalent impedance is around 19 Ohms but it also has a significant imaginary part. As a result, it can be fine-tuned towards better performance. We modified C1 and C2 a couple of times until we found out the final values that work better. obtaining a impedance with only real part at 22 Ohms (C1= 36pF and C2=154 pF). Adjust receiver circuit The last step of tuning our antenna is to design the receiver circuit. The Rx circuit that consists of a voltage divider and a coupling capacitor connected from the output of the EMC filter to the RX pins of the NFC reader. The objective is to set the voltage level at the reception pins to achieve the compromise between a good sensitivity. For CLRC663 plus, the serial resistor is in the range of 7 and 15 kΩ. You can start with a 11 KOhm value, then, the resistor can be adjusted depending on the voltage measured in the Rx pins. If the voltage at Rx pin is higher than 1.7 V, it is recommended to increase the resistor value and if the voltage at Rx pin is below than 1.2 V, it is recommended to decrease the resistor value. Using OM29263ADK kit to evaluate the performance of different antenna shapes The section covers how you can use the antennas included in the kit for performance comparison. Please note that this lab exercise is shown only for illustrative purposes on how the kit can be used to evaluate the performance of different antenna shapes. As an example, we defined a sample scenario where we want to characterize how the field strength decreases with distance when using antennas of different size. For that, we used the following setup: A class 1 ISO14443 Reference PICC A scope A CLRC663 board connected to the small antenna A CLRC663 board connected to the large antenna A ruler to measure the distance The measurements were taken in this way: We tuned the large and small antennas to 20 Ohms We connected the board to the laptop, and we executed the NFC Cockpit tool to control the RF field. We measured with the scope the voltage level obtained by the ISO14443 Class 1 Reference PICC while we increased the distance. Background information Before actually showing you the results, it is worth it to review a couple of antenna design principles to properly understand the results. Coupling coefficient Before actually showing you the results, it is worth it to review a couple of antenna design principles to properly understand the results. The coupling coefficient is a parameter that indicates how much of the magnetic field generated by the reader is picked up by the card. The coupling coefficient takes a value between 0 and 1 If the coupling equals 1, it means we have a perfect coupling, all magnetic field lines are picked by the card If the coupling equals 0, it means we have no coupling at all, no magnetic field lines are picked by the card The key message is that the coupling coefficient is just a geometric quantity. It depends on: The reader and card antenna dimensions (both antenna radius) Their relative position (whether in parallel or perpendicular, they will pick a different amount of magnetic field lines) The distance between them And the magnetic properties of the medium Mutual inductance Very related to the coupling coefficient, we have the mutual inductance. The mutual inductance allows us to determine the voltage induced in the card antenna, that depends on: Coupling coefficient  Better coupling, higher the voltage Driver current  The higher the current we drive in the reader antenna, the stronger the magnetic field Antenna inductance Precisely, in this setup, we are going to measure the voltage perceived by the reference PICC when using two different antennas. Antenna tuning components used for the large antenna First, we prepared a tuning of 20 Ohms in the large antenna. This task was done using the process described above. As an example, we selected a low Q-factor of 10, which helped us to accommodate high bit rates for ISO14443. In the figure below, you can see the components we assembled to tune the large antenna near to 20 Ohms. Antenna tuning components used for the small antenna Second, we prepared a tuning of 20 Ohms in the small antenna so that the results are comparable. The same Q-factor and EMC filter values were used, but obviously, as the antenna size is different, we used different C1, C2 and Rs values to achieve the same equivalent impedance OM29263ADK large antenna vs small antenna The following graph shows the results we obtained: The blue line, represents the DC output voltage obtained from the Class 1 Reference PICC as we increase the distance from the reader using the large antenna… The green line, represents the DC output voltage obtained from the Class 1 Reference PICC but using the reader with the small antenna connected. As a result, what we see is that at close distance, both antennas are able to deliver the same field strength. However, as distance increases, the RF field of the small antenna starts to attenuate quickly from 2 cm distance of the reader while the RF field of the large antenna is more or less stable until 5 cm, after that, it starts to attenuate quickly as well. Potentially, what we can conclude is that for this setup, we might be able to get more reading distance with the large antenna. ISO/IEC14443 vs ISO/IEC15693 reader - Quality factor We need to bear in mind that our antenna is not only for energy transfer, but also it should match with the waveform requirements. Therefore, from the practical point of view, the Q factor of the system is limited by the bandwidth as if we increase the Q, we increase the field strength but we decrease the bandwidth. Our reader can be optimized whether we are designing a reader for ISO14443 or ISO15693 as the signals modulation and timing requirements of the rise and fall times for both RF protocols are different. Actually, in practice, ISO15693 allows us a higher Q factor because there is a lower bandwidth requirement as the waveform timings are more relaxed and, the power transfer requirement is lower than ISO14443. For such optimization, you can refer again to NXP antenna tuning excel sheet. If you recall, one of the input fields of the excel sheet is the Q-factor. Therefore, you can introduce here a value below 30 for ISO14443 readers or below 100 for ISO15693 readers. The excel will output reasonable matching values for the first components adjustment. After that, you can do a fine tuning according to the process I explained before. Further information You can find more information about NFC in: Our NFC everywhere portal: https://www.nxp.com/nfc You can ask your question in our technical community: https://community.nxp.com/community/identification-security/nfc You can look for design partners: https://nxp.surl.ms/NFC_AEC And you can check our recorded training: http://www.nxp.com/support/online-academy/nfc-webinars:NFC-WEBINARS Video recorded session On 21 June 2018, a live session explaining this topic. You can watch the recording here:
View full article
QGroundControl mission planner optimized by Qt Company to run on a Technexion TEP-15 industrial panel computer. QGroundControl is part of the Dronecode Platform. ======= Please see www.hovergames.com and www.nxp.com/hovergamesdrones for more drone hardware. ======= Features: A low power, rugged, fa n-less, cost effective reference solution NXP i.MX6 Quad core processor QGroundControl is an intuitive and powerful ground control station, is part of the Dronecode Platform and supports MAVLink enabled UAVs such as those based on the PX4 Pro Autopilot and ArduPilot. Technexion TEP-15 industrial panel computer running Ubuntu or Yocto Linux  The Qt Company optimized HMI & app Communicates with the NXP RDDRONE-FMUK66 Drone Flight management unit and KIT-HGDRONEK66 www.HoverGames.com drone kit Partner Information: Technexion offers both SBCs SOMs and Panel computers using NXP i.MX family processors Qt Company provides optimized solutions and consulting services for Qt framework    See NXP UAV landing page for solutions for Rovers and Drones and the HoverGames Drone reference design, and software coding challenge. ##
View full article
Combining NXP's wireless MCU with NFC controller allows to build a BLE-NFC bridge. It allows demonstrating transmission of NFC data over BLE, acting then as a king of Magic NFC remote. This demonstrator is built assembling the OM5578: Development Kits for PN7150 Plug’n Play NFC Controller (OM5578/PN7150ARD version including Arduino compatible connectors). on top of the FRDM-KW41Z: Freedom Development Kit for Kinetis ® KW41Z/31Z/21Z MCUs (minimum version B1 since previous versions have a pin conflict on the Arduino connector) Alternatively the Rigado R41Z Eval Board can be used as replacement to the FRDM-KW41Z To complete the demonstration, an android phone is used as BLE counterpart. It shall run the modified version of Kinetis BLE Toolbox android application including the NFC demo part. This dedicated version of the Kinetis BLE Toolbox android application is available for download from the files attached to this document. Below is a video of the demo. As shown, it demonstrate capabilities to control the NFC discovery remotely (via BLE) from the phone. Then, if tapping a card on the bridge, the related information including the content is conveyed through BLE to the phone and get displayed by the app. Additionally, the app can configure a message to be shared whenever an NFC reader (e.g. NFC phone) tap the bridge. The K41Z firmware of this demo is built based on the wireless UART example from MCUXpresso Software Development Kit (SDK), and updated with the porting of the NXP-NCI MCUXpresso example. The complete MCUXpresso project is given in source code in the attached files. To replicate the demo, just import it in an MCUXpresso workspace by selecting "Existing Projects into Workspace", then browsing to the BLE-NFC_bridge_MCUXpressoProject.zip file. Select the frdmkw41z_BLE-NFC_bridge from the "Project Explorer" view, and click on the blue bug icon to build, flash and debug the program.
View full article
This post entry provides a detailed description of how NFC can be used for authentication and identification of consumables and accessories. This document has been structured as follows: NFC for product authentication and identification NFC is a useful addition to verify product authenticity and identification. There are plenty of examples where NFC fits nicely, for instance: For anti-counterfeit protection and safe brand reputation. For identifying users and provide personalized interactions For sending notifications when accessories need to be replaced And to automatically adjust settings of the main unit based on the accessory attached. These are just a few examples so you grasp the potential of NFC in such scenarios. How NFC works in product authentication and identification Into the scope of a consumable or accessories authentication via NFC, there are always two components involved.  On the one hand, there is one main unit. This is the device where you can plug the part or the accessory. Typically, this main unit would include an active NFC reader. On the other hand, the consumable or replacement would include and NFC tag. The NFC reader in the main unit can detect when the removable part is connected. As soon as the replacement is connected, it reads the information stored in the tag and uses it to verify the accessory originality. Precisely, the information and security features implemented in the tag is what allows the main unit to: First, authenticate that is a genuine accessory And optionally, configure related settings depending on the accessory. Success stories The NFC authentication is not a proof-of-concept but rather a consolidated solution. There are already some success stories in the market. For example: A high-end blender that uses NFC to verifies the authenticity of the containers and cups used. In addition, the blender adjusts the speed parameters automatically per each different container. As mentioned, the NFC reader is part of the base unit while the tag is part of each container. Another example, a face brush that make sure that the brush head is genuine. As before, the reader in on the base while the tag is on each head brush. When a new head brush is connected it check its validity and adjust the settings. The third example is a fridge that discards non-original water filters and check if the fridge and filter models are compatible. How to implement the use case From a simplified block diagram perspective, the base unit embed an NFC reader, this NFC reader is made of an NFC frontend, generating the RF field and a Host MCU, loaded with the application firmware. On the other hand, the accessory, beds an NFC tag. The MFRC630 or our SLRC610 are recommended options from the reader side, while the NTAG and ICODE families are recommended from the tag side. The final product selection depends on your specific application requirements There are a few questions that you can ask yourself to know which product fits you best. First, what is your application about? Are you looking for brand protection? Or counterfeit detection? Or settings customization? Second, what kind of security you need? You need device identification, or you also would like encrypted data exchange? Third, what reading distance is required in your system? Are we talking about a centimeters or tenths of centimiters? And, in relation implementation details, are there any specific size constrains? Is there metal in the surrounding? Etc. NFC portfolio for authentication and identification applications I organized the security features for consumable authentication in three groups: There is a basic level security level where the tag UID is used for proof-of-origin. In this case, there is no crypto protocols applied and the verification consists on checking whether the UID is in our database or not. There is a second level, where the authentication is proven using an originality signature. Depending on the solution, this can be an NXP- signature or a customer-specific signature. There is a third level, that uses a cryptographic three pass mutual authentication as a verification mechanism. NXP originality signature The originality signature implemented in NTAG and ICODE families is based on standard Elliptic Curve Cryptography. NXP generates a ECC key pair (a public and a private key) that are stored in a secure server. In asymmetric crypto, a signature is generated by a signing algorithm given a message and a private key. During production, NXP takes care of provisioning a die-individual signature in each IC. This signature is generated using the tag’s UID and the NXP private key. Since each tag has a different UID, a unique signature is stored in each tag. Therefore, the tags leave the NXP factory already with this unique signature pre-programmed in the IC memory. These pre-provisioned tags are integrated by OEM into their final devices & accessories. On the field, the originality signature verification process is as follows: First, the reader unit reads the tag UID. Second, the reader retrieves the tag signature with the READ_SIGNATURE command. Third, the reader can verify this tag originality signature using the corresponding ECC public key and the tag’s UID. With this feature, it is possible to verify with confidence that the tag is using an IC manufactured by NXP and not a cloned IC. In case that the public key is stored in the reader, the entire process can be performed offline. The products supporting this functionality are: NTAG21x, NTAG413 DNA, NTAG I2C plus, NTAG21x F and ICODE SLIX2. OEM customizable orignality signature The NFC tags come pre-programmed with an NXP originality signature. However, some NTAG and ICODE family members also offer the possibility to customize the originality signature per OEM. The process is similar to the one described above, but in this case, the OEM provisions each tag with a die-individual signature, and lock it to avoid unauthorized overwriting. On the field, the tag originality signature verification is done in the same way: The reader retrieves the tag UID and tag signature The reader uses the corresponding OEM public key and tag UID to verify the signature. The main benefit of customizing the originality signature is that, in addition, it allows to verify that the product belongs to the OEM and not from another manufacturer. The products supporting customer originality signature are NTAG210u, NTAG 213 TT and ICODE DNA. Secure unique NFC message (SUN) One security level up, we find solutions like our NTAG 413 DNA which enable a new Secure Unique NFC message (SUN) feature. This SUN feature generates a unique, secure authentication code each time the tag is tapped. This tap-unique data consists of an NDEF formatted packet that includes: A URL The tag UID The tap counter And a AES-based CMAC calculated over the UID, the counter and the URL. This CMAC is dynamic and changes over each tap since the counter is increased every time. The cloud service verifies the authenticity of the message with the appropriate symmetric keys. With this tag, any NFC enabled device (including Android and the recent iOS 11 devices) can automatically connect to a web based service and based on the information contained in URL, the device can check the tags authenticity and verify the information validity. AES three-pass mutual authentication The last tag security feature is the AES mutual authentication, which is supported by our NTAG 413 DNA as well as the ICODE DNA. The mutual authentication: It is based on a shared secret key known by both endpoints It allows us to verify both ends of the communication (not just the accessory). . The AES 3 pass mutual authentication consist of probing to the other end the knowledge of a secret, in this case, the knowledge of a secret AES key. As we do not want to share in plain this secret over an unsecure channel, the mechanism is based on the encryption of random challenges using this secret key. If both ends are capable of verifying this random-challenge scheme, they demonstrate that the other end knows the secret, and therefore, they prove their authenticity. NFC tag security feature comparison The following table consolidates the different NFC tag security options:  The NTAG21x support NXP originality signature The NTAG210u is a cost optimized version with customizable originality signature The NTAG413 DNA offers the SUN feature as well as AES authentication and encryption Finally, the ICODE DNA comes with customizable originality signature and AES authentication. Therefore, the NTAG413 DNA and ICODE DNA are the strongest authentication options that we have right now in the tag portfolio. The reading distance will influence on the decision between NTAG or ICODE: NTAG is an ISO14443 compliant tag with a operating distance of a few centimiters. ICODE is an ISO15693 compliant tag with an operating distance of tens of centimers. NFC frontends comparison Regarding the NFC readers for the base unit side, we most ideal solutions are: The SLRC610 plus if your application needs a reading distance of tens of centimiters. The SLRC610 supports ISO15693 and is fully operational with our ICODE family. The MFRC630 if your applications needs a reading distance of a few centimiters. The MFRC630 supports ISO14443-A and is fully operational with our NTAG family. NFC Nutshell kit This section leverages on the NFC Nutshell kit to explain how to develop your own NFC authentication solution. This kit was developeb by GMMC an approved engineering consultant of NXP. The NFC Nutshell kit is a set of hardware modules that can be used for: NFC integration into new designs or retrofitting into existing products thanks to its small size. It can be used to build NFC demonstrators Or, it can be used for evaluation, development and testing of NFC applications The main benefits offered by the NFC Nutshell kit are that: It is made to provide designers with Nano sized hardware modules which can be configured and combined in a variety of ways. It was developed with flexibility in mind so that designers can easily combined different MCUs with different NFC frontends and multiple development environment easily. And, it is constructed and prepared to be compatible with NXP software tools. NFC Nutshell kit components The kit includes a good bunch of modules that be divided in 4 different groups: Host interface modules A USB plug that bridges the USB communication to the Host MCU A USB converter that is used to communicate over UART, I2C or SPI with the host MCU A host interface signal debug extender MCU modules: LPC1769 LPC11U68. NFC reader modules: CLRC663 plus PN5180 And soon, PN7462 and PN7150 Antenna PCBs of different sizes to test the performance over different antenna sizes (20x10mm, 20x20mm, 40x40mm, 72x48mm). All the modules are connected with flexible flat cables, and the hardware components are designed for minimal PCB area to demonstrate integration into space constrained products. Modes of operation for the USB protocol converter module In our case, out of the different host interface modules, we select the USB to I²C, UART and SPI converter. This single module itself has several configuration options. As part of the kit, a USB Protocol Converter Configure Tool is provided to easily configure the different operation modes of this component. The user can open this tool and check the different options: The first one is used when the converter is connected to an MCU. It configures the module for an in-system-programming, which means we can use NXP Flash Magic Tool to program the MCU flash memory.  The second option, the development PC communicates directly to the connected NFC frontend via UART.  Last, we have 3 bridge modes for single protocol conversion. The Host system can send the any command over the USB interface and it will be converted to the chosen protocol, either I²C, SPI or UART.  NXP development tools supported Another nice feature of this NFC Nutshell kit is its native support of NXP development tools. Using this kit, you can seamlessly run: The NFC Cockpit, an intuitive graphic user interface that lets you configure and adapt IC settings without writing a single line of software code. The RFIDDiscover PC tool, a user-friendly GUI for evaluation of NTAGs, ICODEs or MIFARE Cards. It is the software that is commonly used with NXP Pegoda reader. The NFC reader library, a complete SW support library for RF frontend ICs. The faster and more straightforward way to develop NFC applications. Consumable authentication using the NFC Nutshell kit This last section is meant to give insight on how to develop your own NFC authentication solution. For that, we will make use of the NFC Nutshell kit and existing software examples as a way to illustrate a possible development process.  The five steps that we followed to run a tag signature verification software example in the NFC Nutshell kit are: First, we select and connect the right modules together Second, we configure the host system interface according to our SW development environment. After that, we develop the application logic of our use case. When the code is ready, we build the project, and create the binary file. And last, we use the Flash Magic tool to install the binary file. Hardware preparation About the hardware preparation… the modules selected are: The USB protocol converter module, as an interface converter between the development PC and the reader host MCU. The LPC1769 as the reader host MCU The CLRC663 as NFC frontend And, the 40x400 mm PCB antenna. USB converter module configuration Before going to the software development itself, we need to configure the USB protocol converter. The USB protocol converter mode of operation configuration is a straight forward process. We just need to execute the Configure Tool provided in the kit, and select the mode compatible for Flash Magic.  In this case, this setting corresponds to the first choice as shown in the screenshot. Software development with the NFC Reader Library For the application software development, we leverage on our well know NFC Reader Library. The NFC Reader Libary is a complete API for developing NFC and MIFARE-based applications, it is free of charge and the latest release can be downloaded from www.nxp.com/pages/:NFC-READER-LIBRARY. Great news is that the NFC Reader Library has: Native support for the modules we selected out the NFC Nutshell kit (the CLRC663 plus and LPC1769) Supports the proximity and vicinity RF protocols. And also, the commandset of Type 2, Type 4 and Type 5 tags. Therefore, we can focus on developing the application logic rather than spending time on implementing drivers or the RF protocols. For that, we do not even need to start from scratch, because we can take as reference any of the eleven software examples. Each of these examples do not make use of the entire library, but just use the NFC Reader library components required for the use case demonstrate, allowing to reduce the overall memory footprint. NXP Originality signature verification We take the Basic Discovery loop example as a starting point for developing an piece of code for tag originality signature verification. If we have a look at the source code, this example: Initialize the library, this is initializing the SW components that will be used It configures the discovery loop for tag detection Keeps iterating until a tag is detected Once the tag is detected, we mentioned that the signature verification process consisted of: Retrieving the UID Retrieving the signature Use a signing verification algorithm to check the signature There are several libraries implementing ECC signature validation. As an example, we added an open source C library called nano-ECC into our project. The function call ecdsa_verify() can process the originality signature read from the tags. It is just as simple as passing as arguments, the UID the signature and the public key. In addition, the NTAG Originality signature validation application note provides code snipets and instructions for this process as well. Three-pass mutual authentication Another example for the implementation of a AES three-pass mutual authentication. Once again, we can take as a starting point the Basic Discovery loop example, which: Initializes the library, configures the discovery and iterates until a tag is detected. In addition, we need to add the crypto component in the NFC Reader Library handling the crypto calculation and key storage (in orange) Once the tag is detected, we can make a direct API function call of the corresponding tag type, whether it is a Type 5 (ICODE) or a Type 4 tag (NTAG 413 DNA) there is the right function call in the lib for that. All the crypto complexity of the three pass mutual authentication is just hidden behing a single function call. Build project with MCUXpresso The MCUXpresso tools is used to build and compile the solution by clicking in the hammer button down in the quick start panel. Create .hex file with MCUXpresso After that, we can also generate the .hex file. For that, we just need to right click on the binary file, go to binary utilities and click on create hex file option. Flash the MCU image with Flash Magic tool With the .hex file generated., the last step is to flash our MCU with this .hex file. In the Flash Magic tool menu, select: The MCU used, in this case LPc1769 The COM port, which can be found in the Windows device manager, in our case COM72 Select the path to the .hex file Click start Once the flashing is completed, the USB converter setting should be changed to I2C or SPI configuration. At this moment, the solution is running and the application will try to authenticate any tag presented in front of the reader. Debugging mode Optionally, the NFC Nutshell kit also incorporates a code debugging mode. For that, there is an extra HW module compatible with LC1769 and LPC11U68 that can be used to interface with an LPC-Link2 debug probe. Video recorded session On 22 February 2018, a live session explaining the NFC for consumable and accessories solution was recorded. You can watch the recording here: Available resources The available resources referred to this post explanation are:  Tags: NTAG 413 DNA NTAG 210μ NTAG 213 TT ICODE DNA Readers: MFRC630 plus SLRC610 plus Application notes: AN11350 NTAG Originality Signature Validation NFC Nutshell kit: GMMC
View full article