Description NXP's leadership position in the security, contact and contactless identification space makes us the experts in access control solutions that are safe, secure, robust and reliable. NXP has devices for driving user interfaces as well as lock mechanisms. NXP also has different solutions for addressing designs using both contact and contactless identification systems. Putting these NXP devices together makes for compelling access control solutions. Use your phone or smart card for Access control to open doors or give access to machine configurations.  Use cases Corporate/campus access control system Lock manufacturers (mechanical and electronic) Industrial equipment with safety conditions or control restriction Components for multi-user appliances like printers Professional tools Smart lock manufacturer for smart home applications Block Diagram Products Category Name MCU Product URL Arm® Cortex®-M4|Kinetis® K64 120 MHz 32-bit MCUs | NXP  Product Description The Kinetis® K series MCU portfolio offers the broadest selection of pin, peripheral- and software-compatible MCU families based on the Arm® Cortex®-M4 core. Category Name Secure Product URL A71CH | Plug and Trust for IoT | NXP  Product Description  A71CH is a ready-to-use secure element for IoT devices providing a root of trust at the IC level and delivers, chip-to-cloud security right out of the box. Category Name NFC Product URL PN5180 | Full NFC Forum-compliant frontend IC | NXP  Product Description  The PN5180 is a high-performance full NFC Forum-compliant frontend IC for various contactless communication methods and protocols. Tools Product Link Freedom Development Platform for Kinetis® K64, K63, and K24 MCUs FRDM-K64F Platform|Freedom Development Board|Kinetis MCUs | NXP  A71CH Arduino® compatible development kit OM3710/A71CHARD | A71CH Arduino® compatible development kit | NXP  PN5180 NFC Frontend Development Kit for POS Terminal Applications OM25180 |PN5180 NFC Development Kit for POS Readers | NXP 

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:

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

Overview   RFID enhances theft protection by giving each animal a unique, encrypted identification. Meat industry stakeholders can improve disease control by storing and updating vaccination and movement data directly into each animal’s chip, or by correlating the identification number with this information in the backend system. Such traceability ensures consumers healthy and tasty meat, with clear proof of origin. The ability to track livestock and their movements allows governments to trace what occurs in the supply chain, and to tax each player appropriately. In the case of disease outbreaks, the technology makes it possible to identify which flocks have been affected, which helps to avoid unnecessary waste. Application Benefits of RFID Livestock Management   Provides proof of origin Verifies age and supports disease control Automates handling at farm and auction house Provides theft protection Supports storage and updating of vaccination and movement data   RFID Features Beneficial to Application Permanent identification No line-of-sight requirement Simultaneous multiple identification Robust and suitable for harsh environments Compliance with government mandates   Recommended Products   RFID Link HITAG 2 transponder IC HT2x | NXP  HITAG µ / Advanced / Advanced+ HTMS1x01 HTMS8x01 | NXP 

Demo DPDK provides a platform independent and vendor-neutral standard APIs for optimized packet processing and traditional networking services. This demo showcases DPDK based networking applications working over NXP QorIQ ARM Processors in host and virtual environment. Come discuss with us how NXP is providing support for these common API while leveraging specific acceleration advantages of the NXP data plane architectures   Features: NXP supports DPDK APIs for developing high performance networking applications in host and virtual environment NXP DPDK implementation leverages the underlying DPAA infrastructure and accelerators to offload the component of packet processing Existing DPDK based applications can seamlessly work over NXP QorIQ platforms.   _______________________________________________________________________________________________________   Featured NXP Products: QorIQ Processors Bades on ARM Technology|NXP QorIQ LS2045A and LS2085A Communication processors _______________________________________________________________________________________________________     N25

Demo Owner: Matt Hoover Embedded Planet's CEO Matt Hoover demonstrates the Wireless Sensor Gateway featuring i.MX6 applications processor at the FTF Americas 2014.       Features Bringing wireless sensor data tied to sensors that is brought into the i.MX6 based gateway via Verizon Cellular and  taken up to the cloud, then shown in a web portal Take the data from the field into the gateway via wire or wireless medium and take that data up to their server based system or a cloud based portal Featured NXP Products ARM® Cortex®-A9 Cores: i.MX 6 Series Multicore Processors Links NXP Connect - Embedded Planet  

Overview This reference design shows the simplicity of a soft modem design, how few resources of the processor it takes, and how well it performs on USA average lines. This design omits the standard telecommunications Codec, instead of using PWM for output and ADC for input. Since both peripherals are readily available on one 56F8300/100 series device, along with more processing power than required from the single core, the design is a true one-chip, one-core system that includes telecommunications ability with room for even more system functionality. Ideal for advanced motion control, home appliances, medical monitoring, fire and security systems, power management, smart relays, and POS terminals. Features Hybrid architecture facilitates implementation of V.21 and V.22bis modem, control, and signal processing functions in one chip Consumes only 7.5 MIPS for the modem function - Only 15K words of Flash for the complete modem application and test harness High-performance, secured Flash memory eliminates the need for external storage devices Extended temperature range allows for operation of non-volatile memory in harsh environments Flash memory emulation of EEPROM eliminates the need for external non-volatile memory 32-bit performance with 16-bit code density On-chip voltage regulator and power management reduces overall system cost Off-chip memory expansion capabilities allow for glueless interfacing with the additional memory of external devices, without sacrificing performance Boots directly from Flash, providing additional application flexibility High-performance PWM with programmable fault capability simplifies design and promotes compliance with safety regulations PWM and ADC modules are tightly coupled to reduce processing overhead; only one of each is used by the modem General purpose input/output (GPIO) pins support application-specific needs Simple in-application Flash memory programming via Enhanced OnCE or serial communication Block Diagram Board Design Resources

Demo This demonstration from Boundary Devices showcases one of the newest additions to the Single Chip System Module portfolio – the SCM-i.MX 6SoloX module with V-Link bus       The SCM-i.MX 6SoloX module with V-Link bus is a new type of single chip system module. It consists of: A base SCM-i.MX 6SoloX module that integrates NXP’s i.MX 6SoloX applications processor, NXP’s PF0100 power management IC, 512 MB LPDDR2, and system passive components (de-coupling capacitors and resistors) A custom signal interface on the top of the package that enables customers to design their own PCB or substrate that can vertically attach to the top of the base SCM-i.MX 6SoloX. This custom signal interface, or V-Link bus, brings out common I/O such as UART, GPIO, SPI, I2C, SDIO etc. Customers can design top boards that add connectivity, security or sensing functions The overall footprint of the solution is 15.5mm x 15.5mm SCM V-Link technology is ideal for handheld/space-constrained applications allowing customers to integrate vertically   Features Reduce overall hardware design time and bring products to market faster Shrink PCB area over current discrete solutions. Customers can add connectivity, sensing, security in a vertical integration fashion to further save on PCB area Reduces design complexity of integrating DDR memory and power management Get started with an evaluation board and Linux OS, early access program now available   NXP Recommends NXP Single Chip Modules – www.nxp.com/scm

Demo This demo shows how the FRDM-K82F board along with an OV7670 Camera module can be utilized to create a USB web camera application. The demo application software is delivered as part of the KSDK software enablement. The FS USB video class demonstration can deliver images to PCs or tablets. Features: USB Video device class demonstration application included in Kinetis SDK Easy connection to PC or tablet  display and process video captured from the device FlexIO camera driver utilized to interface to OV7670 camera module _______________________________________________________________________________________________________ Featured NXP Products: ARM Cortex-M4 Cores|Kinetis K8x MCUs|NXP AN5275: Using FlexiO for Parallel Camera Interface AN5280: Using Kinetis FlexIO to drive a Graphical LCD _______________________________________________________________________________________________________

This post entry provides a detailed description of how the Device-to-device communication demo was developed so that you can leverage this knowledge to integrate NFC into your own system. This document has been structured as follows:   Introduction Device-to-device communication demo functionality NFC for communication with a batteryless unit NFC for communication between two devices mounted in close proximity NFC for communication with a rotating part as a cable replacement solution Hardware details Base board based on CLRC663 plus Rotating disk based on NTAG I2C plus Application logic Reader module to rotating disk communication Rotating disk to reader module communication MCU code details NTAG I2C plus pass-through mode data exchange synchronization considerations Reader module MCU code NTAG_Device2DeviceDemo  application workflow Rotating disk MCU code NTAG_I2C _Explorer_01_LEDs_ButtonXample application workflow Video recorded session Available resources Introduction The Device-to-device communication demo shows how NFC can be used as a cable replacement between two units or devices. It is based on the CLRC663 plus NFC Frontend and the NTAG I 2 C plus connected tag solutions. It demonstrates how NFC is used for: Wireless communication with a batteryless unit. Wireless communication between two devices mounted in close vicinity that need to be completely isolated (e.g. dust or water proof). Wireless communication with a rotating part and as a cable replacement solution.   Device-to-device communication demo functionality The purpose of the demo is to illustrate how to enable device-to-device communication via NFC. It consist of: A base board of 14x12 cm, which embeds the CLRC663 plus NFC reader IC for the RF field generation. A sensor embedded on a separate, rotating sensor disk of 8 cm diameter, which embeds the NTAG I 2 C plus connected tag.   The base board and the rotating sensor disk communicate via NFC and optionally, a tablet display can be connected via a Bluetooth Low Energy (BLE) connection (the BLE connection is beyond the scope of this post entry).     NFC for communication with a batteryless unit The first scenario demonstrates the use of NFC for communication with a batteryless unit or sensor. Energy from the RF field generated by an NFC reader can be harvested to power up small devices so that a battery or other power supply no longer needs to be included.   In this demo, only the base board is powered using a 5V supply input (e.g. USB battery bank) while the rotating disk electronics are powered using only the harvested energy from the RF field generated by the base board. To maximize energy transfer and avoid possible interference caused by the electronics, both the rotating disk and base board antennas are placed on the edges. In the following video, you can observe how as soon as the base board is supplied, it starts generating an RF field and automatically. Then,  all the electronics on the rotating disk are powered and its LED turns GREEN.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/f54/f54337d597118_12181097.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387b9f NFC for communication between two devices mounted in close proximity The second scenario demonstrates the use of NFC for communication between two devices mounted in close proximity. For instance, any machine or device where sensors are inside or in close vicinity and the sensor needs to be completely sealed (e.g. waterproof, dustproof, etc).   In this demo, the bidirectional communication between the two units is demonstrated using push buttons, which light up LEDs on the opposite unit. For the base board to rotating disk communication direction: While action button 1 is pressed, the LED on the rotating disk turns BLUE. While action button 2 is pressed, the LED on the rotating disk turns RED. While action button 1 and button 2 are pressed, the LED on the rotating disk turns WHITE.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/912/912db3bd13b06_12160248.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387c99 With the other way around, for the rotating disk to base board communication direction: While action button 3 is pressed, a pattern on the LED circle will appear.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/d0b/d0b0072da0120_12160391.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb54387e98   NFC for communication with a rotating part as a cable replacement solution The third and last scenario demonstrates the use of NFC to communicate wirelessly with two moving parts where cables may break. For instance, any solution consisting of a main unit and a sensing part recording mechanical-stress readings on moving parts.   In this demo, the accelerometer on the rotating disk continuously sends its coordinates to the base board, which lights up a specific LED according to the calculated angle between the two units. In the following video, you can see that the LED circle "follows" the movement of the rotating disk.   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/c0e/c0e3daf347aed_12160349.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5438709a   Hardware details This section shows the architecture and main components of the base board and rotating disk.  The PCB schematics are attached at the end of this post entry.   Base board based on CLRC663 plus The disk has been dismounted so you can better appreciate the different components of the base board. The base board is driven by an LPC11U68 MCU, which is a low-cost Cortex-M0 USB solution, with 256 kB of flash memory, up to 80 GPIOs and several host interfaces (more details on the LPC11U68 product website).   From the LPC11U68 MCU, some of the GPIOs are used to connect the action buttons and the 12 LEDs of the circle, an SPI port is used to connect the CLRC663 plus NFC Frontend and, a USART port is used for connecting a BLE chip based on NXP's QN9021 chip.     The NFC functionality is provided by our CLRC663 plus reader IC, an NXP high performance multi-protocol reader. It is the evolution of CLRC663, with a larger LPCD detection range, more output power (2x times higher transmitter current), larger temperature operating range and pin-to-pin compatibility with the former version.   Rotating disk based on NTAG I 2 C plus The rotating disk is based on NXP solutions as well. This PCB board is driven by an LPC11U24 MCU, which is a low-cost Cortex M0 32 bit MCU, with 32 kB of flash memory, up to 40 GPIOs and several host interfaces (more details on the LPC11U24 product website).   From the LPC11U24 MCU, some of the GPIOs are used to connect the action button 3 and the RGB LED. In addition, an I 2 C interface port is shared to connect a temperature sensor, the accelerometer and the NTAG I 2 C plus.     The NTAG I 2 C plus is a family of connected NFC tags that combines a memory, a passive NFC interface with a contact I 2 C interface.  Functionally, the NTAG I 2 C plus behaves as a dual port memory. Therefore, the data can pass from an external NFC device to the embedded system. In addition, to this dual interface solution, it has more features: A field detection pin, to send a wake up signal The Energy harvesting, to power external devices The SRAM, a memory without writing cycles limitation The pass-through mode, for fast data exchange between interfaces Several memory access management settings from both NFC and I2C interfaces And an originality signature, to protect against clones.   Application logic This section describes how data is exchanged between the reader module (base board) and the rotating disk using NTAG I 2 C plus as a bridge (pass-through mode) between the two embedded systems.   Reader module to rotating disk communication In this demo, the reader module sends data to the rotating disk when any of its two action buttons are pressed. The NTAG I 2 C plus is configured in pass-through mode and the SRAM memory is used as conduit between the twto units.  The figure below illustrates a simplified representation of NTAG I 2 C plus memory seen from the NFC perspective (organized in pages of 4 bytes each). The red area represents the EEPROM memory while the yellow one represents the SRAM memory location. While the button 1 is pressed: The GPIO 4 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x01). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 18 status to high level. The RGB LED turns blue.   The operation that takes place while button 2 is pressed is pretty similar. Basically, it changes: the data written by the CLRC663 plus in the SRAM and the GPIO activated by the LPC11U24 on the rotating disk. More precisely, the steps are: The GPIO 5 of the LPC11U68 is in high level. The CLRC663 plus writes one byte into the SRAM memory (last page, value = 0x02). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 changes the GPIO 16 status to high level and sets GPIO 18 to low level. The RGB LED turns red.     In the same way, while the two buttons are pressed at the same time: The LPC11U68 detects that GPIO 4 and 5 are in high level The CLRC663 plus programs a different value on the last SRAM byte (0x03). The LPC11U24 on the rotating disk reads the SRAM. The LPC11U24 sets to high the three GPIOs (16,17,18) controlling the RGB LED. The RGB LED turns white The key message is that: what it is written in the SRAM controls the behavior of the rotating disk LED, demonstrating wireless data exchange between the two embedded systems.   Rotating disk to reader module communication In this demo, the rotating disk keeps sending data to the reader module for as long as it is powered by the RF field. Precisely, it continuously sends the disk position (via the accelerometer axis coordinates) and the measured temperature value. Additionally, an extra byte is sent while the button 3 is pressed. The actual steps are: First, the LPC11U24 MCU triggers a read operation to the temperature sensor and accelerometer. The temperaturre reading occupies 2 bytes while the accelerometer axis coordinates occupy 6 bytes. This data is transfered the LPC11U24 via the I 2 C shared bus. The LPC11U24 writes these 8 bytes into the SRAM in page addresses 0xFD, 0xFE and 0xFF (see the figure below). The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With the read information, the LPC11U68 base board MCU calculates the angle and sets the appropriate GPIO to high level. Since the LED circle contains 12 LEDs, the base board is able to represent position changes of 30 degrees (360º / 12 LEDs).   As mentioned, this data transfer keeps going for as long as the disk is powered. The key concept here is that the LED circle operation is directly controlled by the disk position and the axis coordinates which are exchanged via the NTAG I 2 C plus SRAM at any given moment. To illustrate this, the disk is rotated 90 º clockwise. The steps that take place are: The LPC11U24 MCU triggers the next reading command, the accelerometer axis coordinates have changed to different ones representing the new disk position (in red in the memory map figure below). The LPC11U24 writes into the SRAM again these 8 bytes (now with the updated accelerometer axis coordinates) The CLRC663 plus reads the SRAM when the LPC11U24 has finished writing it. With this new reading, the LPC11U68 MCU recalculates the angle and applies a different GPIO configuration (which leads to a different LED turned on in the circle).     Last, while button 3 is pressed: The LPC11U24 GPIO 12 is set to high value. The LPC11U24 checks GPIO 12 pin status before writing into the SRAM. While it is high level, it adds an additional byte into the SRAM (third byte on page 0xFF- value=0x01). The CLRC663 plus reads the SRAM, getting the latest data from the moving part. With the current firmware, while the third byte on page address 0xFF is set to 0x01, the LPC11U68 performs a LED pattern activating all the GPIOs simultaneously (all the LEDs are ON).     MCU code details This section explains the firmware implementation details for both the base board (CLRC663 plus) and the rotating disk (NTAG I 2 C plus). Before going into the firmware implementation details, a few considerations for data exchange synchronization when using the NTAG I 2 C plus pass-through mode are explained.   NTAG I 2 C plus pass-through mode data exchange synchronization considerations In the demo, the pass-through mode is used to exchange data between the base board and the rotating disk. The pass-through mode provides the SRAM for data communication and the mechanisms for the synchronization of the data transfer. This signalling can be done through the field detection pin or by polling the equivalent registers over the I 2 C interface. For the NFC to I 2 C direction, the synchronization can be done: By checking the SRAM_I2C_READY register to learn if new data has been written by the RF interface. By checking the filed detection pin changing from HIGH to LOW voltage.   For I 2 C interface to NFC direction, the synchronization can be done: By checking the SRAM_RF_READY register to learn if new data has been written by the I 2 C interface. By checking the filed detection pin changing from LOW to HIGH voltage.   The following table includes register bits which can be used for communication synchronization. In addition, there is a dedicated application note providing more details on how NTAG I 2 C plus can be used for bidirectional data communication.   Register bit Use PTHRU_ON_OFF Detects if the pass-through mode is still enabled (gets reset in case of RF or I2C power down). TRANSFER_DIR Defines the data flow direction for the data transfer. I2C_LOCKED Detects if memory access is currently locked to I2C. RF_LOCKED Detects if Memory access is currently locked to RF. SRAM_I2C_READY Detects if there is data available in the SRAM buffer to be fetched by the I²C side. SRAM_RF_READY Detects if there is data available in the SRAM buffer to be fetched by the RF interface. RF_FIELD_PRESENT Shows if a RF field strong enough to read the tag is there.   Reader module MCU code The MCU firmware was developed using our LPCXpresso platform, which provides a complete development environment for LPC MCU and LPC boards. In the source code, there are five project folders: The FreeRTOS project folder, which is an open source real-time operating system (RTOS) for embedded systems supporting many different architectures and compiler toolchains The Lpc_chip_11u6x_lib and nxp_lpcxpresso_11u68b project folders, which belong to the LPCOpen libraries supporting the LPC11U68 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_Device2DeviceDemo  project folder, which implements the logic supporting the device-to-device communication demo for the reader module. The NxpNfcRdLib project folder, which is the NXP's NFC Reader Library software stack supporting the implementation of the demo, the contactless protocols, the LPC MCU host interfaces and the CLRC663 drivers.   The reader module MCU code leverages on the NFC Reader Library. The NFC Reader Library is a software stack for creating and developing contactless applications for NXP's NFC readers. This API facilitates the most common operations required in NFC applications such as: reading or writing data into contactless cards, exchanging data with other NFC-enabled devices and emulating cards.   In order to use the NFC Reader Library, a stack of components has to be built up from the bottom to the top layer. Precisely, the application requirements define which modules need to be enabled and which do not. For the reader module firmware: The FreeRTOS is used. The SPI is used as host interface. A CLRC663 plus reader IC is used. And, communication with NTAG I 2 C plus is needed ( ISO14443 Type A card and NFC Forum Type 2 Tag compliant)   As a result, the software components that need to be enabled within the NFC Reader Library are depicted in the following picture: NTAG_Device2DeviceDemo  application workflow The reader module firmware starts its execution as soon as it is connected to the power bank. The firmware initializes the GPIOs, the UART for the tablet connection and the NFC Reader Library for the contactless operation. After all these initializations, the firmware code generates a new thread in charge of dealing with the disk operation. In this separate thread, the discovery loop for detection of Type A and Type V cards is configured and started. After that, the firmware keeps listening until the NTAG I 2 C plus is detected (i.e. the disk is mounted). On detection, the operation with the rotating disk starts: The reader module waits until the SRAM is available for the RF interface. The SRAM is available for the RF interface while the pass-through mode is enabled (PTHROUGH_ON_OFF register is set) and the RF to I 2 C direction is set (TRANSFER_DIR register bit). The board buttons are checked and the SRAM is written with the corresponding information.   At this point, the program awaits to receive data from the rotating disk. For that, it keeps polling if new data was written in the SRAM by the I 2 C interface (SRAM_RF_READY register bit is set). If new data is available, the SRAM is read and the data is processed: The accelerometer axis coordinates are read, the angle is calculated and the appropriate LED on the circle is activated. While the button 3 is pressed, the MCU triggers the LED pattern on the circle. Optionally, if the tablet connection is established, data is also sent using the BLE channel.   The following figure depicts the reader module application workflow in detail:   Rotating disk MCU code The MCU firmware was also developed using the LPCXpresso platform.  In the source code, there are four project folders: The Lpc_chip_11uxx_lib and nxp_lpcxpresso_11u24h_board_lib project folders belong to the LPCOpen libraries supporting the LPC11U24 MCU and PCB board, the MCU chip integrated in the Explorer board. If you use another MCU, you should replace them by the specific LPCOpen libraries. The NTAG_I 2 C _API project folder is a library providing a set of functions and procedures that allow you to communicate with the NTAG I 2 C from the I 2 C interface. Among others, functions to perform memory operations on EEPROM, SRAM, registers and for enabling the pass through mode The NTAG_I 2 C _Explorer_01_LEDs_ButtonXample project folder implements the logic for the rotating disk of this demo.   NTAG_I 2 C _Explorer_01_LEDs_ButtonXample application workflow The rotating disk firmware starts its execution as soon as it harvests enough energy from the reader's module RF field. The first operation taken is to enable the pass-through mode. Then, the firmware stays on a loop for as long as it is energized.   In this loop, it sets the SRAM into RF to I 2 C direction (TRANSFER_DIR register bit) and waits until the base board has written data. After data has been written from the RF side, it reads the SRAM and checks the last byte: While the last byte value is 0x01, it means the button 1 is pressed and the firmware sets the RGB LED to blue While the last byte value is 0x02, it means the button 2 is pressed and the firmware sets the RGB LED to red While the last byte value is 0x03, it means the button 1 and 2 are pressed and the firmware sets the RGB LED to white.   After receiving data from the base board, it prepares to send data back. For that: it checks the button status, it reads the temperature value and the accelerometer position. Once all the data has been collected: It changes the SRAM to I 2 C to RF direction (TRANSFER_DIR register bit). It writes into the SRAM and waits until the RF has read the data (SRAM_RF_READY register is cleared).   This loop is repeated for as long as the disk is powered. The following figure depicts the rotating disk application workflow in detail:     Video recorded session On 9 March 2017, a live session explaining the device-to-device communication demo was recorded. You can watch the recording here:   http://wpc.08c9.edgecastcdn.net/0008C9/twistage-production/149/149fee5f5e282_12181079.mp4?d273d3b84ae78c6b0b40b4df7e407772944048591ee44914b69449116aeb5439ff51 Available resources   Schematics Please see attached in the separate attachment section below. Device-to-device demo source code Please see attached in the separate attachment section below. Quick-start guide for showing the demo Please see attached in the separate attachment section below Android app The android app can be used on a tablet or smart phone connected via BLE to this demo to show additional parameters, and to have a bigger screen for demonstrations. You find it in Google play ("device2devicedemo") and attached below.  

Demo FXTH87 tire pressure monitor sensor solution for heavy trucks integrates a pressure sensor, 8-bit MCU, RF transmitter and a dual axis accelerometer into a single package. This demo will show the highest pressure range of 100–1500 kPa with tightest pressure offset.   1500 kPa Range Tire Pressure Monitoring Sensor Smallest footprint,  Low-power consumption, large customer memory size Pressure sensor, 8-bit microcontroller, RF transmitter, Accelerometer     Featured NXP Product FXTH8715|TPMS|Pressure Sensor|NXP   Other Tire Pressure Monitoring System (TPMS)|NXP

This demo will provide three modes to show the CAPWAP offloading capability of QorIQ platform. mode Iis the core-through mode which can be implemented by the CAPWAP stack to send the CAPWAP stack packets; Mode II is the offloading-mode which demonstrates the CAPWAP Encapsulation/De-capsulation capability of the SoC, and can be used in the AC case; Mode III is the net-bridge mode which is the basic usage for EAP which bridge the packets from PCIE to SEC and FM for offloading CAPWAP manipulation, the bridge is zero-memory copy in order to get high performance data. Together with the throughput data, this demo will help the customer to evaluate the EAP design with QorIQ platform.   Features QorIQ T1 processors handle secure WLAN tunnels with offload engines instead of CPU cycles CAPWAP tunneling firmware performs extra tasks (frag/ reassembly) and interfaces to the Linux user Highly efficient bridging to WLAN radios ensures maximum WLAN performance CAPWAP fragmentation and reassembly Featured NXP  Products T1040 Block Diagram

Demo NXP has a full range of high power LDMOS drivers and finals for cellular base stations. Our cellular LDMOS portfolio delivers industry leading performance with powerful and efficient products targeting rapidly growing frequencies and regions in the world. This demo wall features new devices that cover all cellular bands from 575 to 2400 MHz Products A2V09H300-04N 48 V LDMOS Solution • Frequency 720-960 MHz • Final Doherty performance at 8 dB OBO • Gain 19.5 dB • Efficiency 53% • Peak power 56 dBm • OM-780-4 package A2V07/09H400-04N 48 V LDMOS Solution • Frequency 575–960 MHz • Final Doherty performance at 8 dB OBO o Gain 18 dB o Efficiency 53% • Peak power 57.5 dBm • OM-780-4 package A2V07/08/09H525-04N 48 V LDMOS Solution • Frequency 575–960 MHz • Final Doherty performance at 8 dB OBO o Gain 18.7 dB o Efficiency 53% • Peak power 58.5 dBm • OM-1230-4L package A2T23H200W23S 28 V LDMOS Solution • Frequency 2300–2400 MHz • Final Doherty performance at 8 dB OBO o Gain 15.5 dB o Efficiency 50% • Peak power 55 dBm • ACP-1230-4L2S package A3T18H360W23S 28 V LDMOS Solution • Frequency 1805–1880 MHz • Final Doherty performance at 8 dB OBO o Gain 17.5 dB o Efficiency 53% • Peak power 55.5 dBm • ACP-1230-4L2S package A3T21H450W23S 28 V LDMOS Solution • Frequency 2110-2200 MHz • Final Doherty performance at 8 dB OBO o Gain 15.5 dB o Efficiency 49.5% • Peak power 57.4 dBm • ACP-1230-4L2S package

  Overview The TRIAX demo board was built to combine many of the demos available for accelerometer applications. The TRIAX demo board will enable you to see how Our accelerometers can add additional functionality to applications in many different industries. By thinking of accelerometer applications in terms of the measurements that are performed, they can be grouped into 5 sensing functions – Tilt, Motion, Positioning, Shock and Vibration. The RD1986MMA6260Q reference design is a two accelerometer solution which is achieved by using the MMA6260Q (x and y-axis device) and the MMA1260D z-axis accelerometer. Archived content is no longer updated and is made available for historical reference only.   Features Accelerometers:  MMA6260Q, MMA1260D Packages:  Quad Flat No-Lead (QFN) 6x6x1.98m and SOIC 16 G Range:  +/- 1.5 G Sensitivity:  1200 mV / G Microprocessor:  MC68HC908KX8 Demonstrates Consumer Accelerometer Applications High-performance M68HC08 architecture Option to allow use of external clock source or external crystal/ceramic resonator SCI Interface User Inputs:  1 Pushbutton Outputs:  Piezohom, Serial Port Connection Design Resources

The attached document describes how to optimize LCD display performance on RT10xx platform. The content include RT10xx configuration and Emwin setting with LCD parameters. Products Product Category NXP Part Number URL MCU i.MX RT1060 i.MX RT1060 MCU/Applications Crossover MCU | Arm® Cortex®-M7, 1MB SRAM | NXP  MCU i.MX RT1050 i.MX RT1050 MCU/Applications Crossover MCU| Arm® Cortex-M7, 512KB SRAM | NXP  SDK Software Software Development Kit https://mcuxpresso.nxp.com/en/select    Tools NXP Development Board URL MIMXRT1060-EVK i.MX RT1060 Evaluation Kit | NXP  MIMXRT1050-EVK i.MX RT1050 Evaluation Kit | NXP  Was this helpful to you?

Description This is a very simple dodge the objects game. You are going to control a spaceship nave with the pushbuttons, one is use for up and the other to down, using the GPIO capabilities of the MCU. The on-board capacitive touch pad acts as start button and the game will prints in a terminal application as Tera term or also you can use an SSD1306 OLED display via SPI, the next picture show a block diagram of the project. Video Requirements LPC845 Breakout Board MCUXpresso IDE SDK_2.6.0_LPC845BREAKOUT LPC845_Spaceship.zip Micro USB cable Terminal Emulator (Tera Term, Putty) OLED Display from Adafruit (optional) Block Diagram NXP Product Link LPC84X LPC84x 30MHz|Arm® Cortex®-M0+|32-bit Microcontrollers (MCUs) | NXP  LPC845-BRK LPC845 Breakout Board for LPC84x family MCUs | NXP 

Overview The 56F8300 (56800E core) family of Digital Signal Controllers (DSCs) is well suited for UPS design, combining the DSP's calculation capability with MCU controller features on a single chip. Offers many dedicated peripherals, including Pulse Width Modulation (PWM) units, Analog-to-Digital Converters (ADC), timers, communication peripherals (SCI, SPI, CAN), on-board Flash and RAM Online Uninterruptible Power Supplies (OUPS) provides continuous power to the load during power outage or glitches caused by power source switching Ideal for computers, office equipment, communication systems and medical life support Features Single-device solution: Combines MCU functionality and DSP processing power TCP/IP network communication for remote control and monitoring Bidirectional AC/DC conversion High input power factor with Direct PFC and lower power pollution to the power grid Battery management to extend battery life and lower maintenance costs Power source and load conditioning can be monitored in real time TCP/IP network communication for remote control and monitoring Bypass operation during overload or service maintenance Expedites time-to-market using out-of-the-box software components Block Diagram Board Design Resources

Demo NXP has released the 1500 W MRF1K50H and MRF1K50N. The industry’s highest power transistors for ISM, FM broadcast and sub-GHz aerospace applications. These are pin-compatible so can be situated on the same PCB as existing solutions on the market Demo / product features MRF1K50H 1.5 kW LDMOS Transistor 1–500 MHz, 1500 W CW 74% efficiency 23.5 dB gain Extremely rugged  (65:1 VSWR) MRF1K50N 1.5 kW LDMOS Transistor 1–500 MHz, 1500 W CW 73% efficiency 23 dB gain 30% lower thermal resistance compared to ceramic package Extremely rugged  (> 65:1 VSWR) NXP Recommends MRF1K50H MRF1K50N

Demo NXP has developed a whole vehicle multi-layered approach to vehicle security.  This demo will demonstrate the NXP security products in action, and show the 4 steps to securing an automotive electrical architecture, and how these 4 steps provide a barrier to the recent public vehicle hacks.   Features: Try to hack a typical automotive network. Enable and disable NXPs security layers to see how they work to protect the vehicle. Demonstrates various NXP security IP, including: A700x family secured MCUs, MPC5748G connected gateway and HSM/CSE security engines. ___________________________________________________________________________________________________________________________   NXP Recommends MPC5748G|NXP A700x|NXP   ___________________________________________________________________________________________________________________________      

Demo         This was a super fun project to work on and is popular around the office and on the road.  Now I have two of these for a truly amazing barrage of Nerf darts!  It's also always a lot of fun to tear things down and the Nerf gun had some cool plastic work and the shooting mechanism is more simple than what I originally guess.  But I digress, this post is about how you can build one of these yourself.  Please leave any questions or comments in the section below and I will try to answer and make refinements to this guide as we go.   The shopping list (aka Bill of Materials or BOM)   If you shop around you might be able to find better prices or substitute parts.   Type Part Qty Price URL UBEC HKU5 1 $             5.33 http://www.hobbyking.com/hobbyking/store/__16663__HobbyKing_HKU5_5V_5A_UBEC.html LiPo TURNIGY 2200mAh 3S 20C 1 $             7.89 http://www.hobbyking.com/hobbyking/store/__8932__Turnigy_2200mAh_3S_20C_Lipo_Pack.html Servo S5030DX 1 $           28.63 http://www.hobbyking.com/hobbyking/store/__18862__Hobbyking_S5030DX_Digital_MG_Servo_X_Large_HV_164g_0_20s_30kg.html Servo HK15138 1 $             3.12 http://www.hobbyking.com/hobbyking/store/__16269__HK15138_Standard_Analog_Servo_38g_4_3kg_0_17s.html Relay PCB COM-11041 1 $             3.95 https://www.sparkfun.com/products/11041 Relay Components Various 1 $             3.00 https://www.sparkfun.com/wish_lists/36307 Nerf Gun Nerf Dart Tag Swarmfire Blaster 1 $           44.99 http://www.toysrus.com/product/index.jsp?productId=11267568 Controller FRDM-K64F 1 $           29.00 FRDM-K64F | mbed Servo Arm Double Servo Arm X-Long 1 $             3.20 http://www.hobbyking.com/hobbyking/store/__19468__CNC_Alloy_Double_Servo_Arm_X_Long_Futaba_.html Servo Arm Heavy Duty Alloy Arm 1 $             5.63 http://www.hobbyking.com/hobbyking/store/__18350__Heavy_Duty_Alloy_1in_Servo_Arm_Futaba_Red_.html Servo Linkage Alloy Pushrod with Ball-Link 65mm 1 $             2.10 http://www.hobbyking.com/hobbyking/store/__25834__Alloy_Pushrod_with_Ball_Link_65mm.html Lazy Susan Shepherd 6 in. Lazy-Susan Turntable 1 $             4.49 http://www.homedepot.com/p/Shepherd-6-in-Lazy-Susan-Turntable-9548/100180572#.UYk5UqLql8E Metal Rod 3/8 in. x 36 in. Zinc Threaded Rod 1 $             2.87 http://www.homedepot.com/p/3-8-in-x-36-in-Zinc-Threaded-Rod-17340/202183465#.UYk5pqLql8E Frame 1/2 MDF 2ftx4ft 1 $           10.45 http://www.homedepot.com/p/1-2-in-x-2-ft-x-4-ft-Medium-Density-Fiberboard-Handy-Panel-1508108/202089097?N=btn1#.UYk6CqLql8E   The build   Two main pieces to construct in this phase.  The base turret and the actual hacking of the Nerf gun.   All your base.. The base of the turret is pretty rudimentary, lot's of room for improvement here.  I used 1/2 MDF and some carpentry skills.  Here is some instruction on how to build a MDF box.  Atop the box is a lazy Susan (ball bearing ring) so that the top-plate can rotate smoothly.  We considered leaving this element out, but worried that it would put to much strain on the servo.   On the subject of servos, a few tidbits of wisdom for you as you build this thing.  First, the left/right servo needs to be dead center of the lazy susan, if your off too much things will start to bind which is not good for your servo.  Second, I used large higher torque servos which cost a bit more, they might be overkill, but it certainly performs well.   I did a quick dimensionally accurate rendering of the design in Sketchup. Files are here.   Hacking the Nerf   Now for the fun stuff.   There is no shortage of screws with this Nerf Gun.  So get out your Phillips screwdriver and go to town. There are two electrical systems in the Nerf that we are going to tap into.  One is the power switch and the other is the electrical trigger. This is the electrical trigger.  The trigger goes to our relay, which is either on or off.  We did try at first to use a 7.2V R/C car battery, but the Nerf draws too much power and didn't fire.  Going up to a 11.1V LiPo fixed that right up. This is the power switch. In Nerfinator 1.0 everything was hardwired together, which prevented us from completely pulling the Nerf from the base and made repairs difficult to say the least.  Nerfinator 2.0 we put this handy connector which allowed us to completely and easily remove the Nerf from the base.  Shipping this thing around the country will take a toll on it!  On that subject, Nerf 1.0, stopped cycling to the next position for us at the Austin Mini Maker Faire.  After a through inspection of the operational mechanics inside the Nerf (really cool BTW) it was a little bitty spring that was causing the piston not to fully retract.  We replaced the spring with 1/2 a ballpoint pin spring and to our surprise it all worked again. Electrical Connection Diagram   Added High-Level Block Diagram.  Need to add pinouts.  You'll have to read the code for now to figure it out.     Code   Mbed was the programming tool of choice for this build.   Receive Side (RX) - The receiver is the base side.  This one takes input from the remote and controls the servo movement. NerfGun_nRF24L01P_RX - a mercurial repository | mbed Transmit Side (TX) - The transmitter is the remote side.  This one senses the users movement (accelerometer) and sends that data to the base station. NerfGun_nRF24L01P_TX - a mercurial repository | mbed   Finishing Touches   In the first passes of this build we just used a bare development board as the remote control.  We found that when given the remote they would not orientate it properly, so 3D Printed Controller STL files   Development Team John McLellan - Amplification/Motivation Clark Jarvis - Software/Hardware Iain Galloway and Angus Galloway - Design and print of controller FRDM_case_sunday_PART_REV_001.STL.zip