This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

P2P or Card Emulation?

Other Parts Discussed in Thread: TRF7970A, RF430CL330H, DLP-RF430BP, MSP430G2553, TIDM-DYNAMICNFCTAG, TIDA-00217, CC3200, MSP-EXP430FR5739

Dear all, 

I have a project t to implement NFC in a ventilation device, so that we can receive data from ventilation device, but also can modify data (like setting information such as fan speed) with the mobile phone to the ventilation device  (two-way communication). 

I earlier think this is rather a card emulation mode, however, i begin to think since the smartphone should be able to transfer new data to the ventilation device, it sounded as a P2P mode too.
Now i confused, in this case does it's more to P2P mode or Card Emulation mode?Can we still modify the data and send it from the NFC-enabled-device to the reader in a card emulation mode?

My question is very, I hope someone can enlighten me with a more detail about the difference capability between P2P mode and Card Emulation more?

Thank you in advance.

Best Regards, 


  • Stella - 

    P2P mode is mainly for when you need to send information between two devices, with either device being able to send data to the other without being "asked", once the connection is established. One of them starts the connection, but as i stated, once the connection is made, either side can send data. (it even uses LLCP, which makes sense)

    Card emulation on the other hand is a situation where the reader/writer device is always in charge - the card is activated, selected and read out or written to based on what the reader/writer side is wanting to do. The card cannot send back anything to the reader on its own accord. (this is analogous to an I2C master and slave relationship - hope that makes sense - if you are familiar)   

    so - it sounds to me like either one will work for you in this application - the choice now is cost and performance. the use of a dynamic tag (like the RF430CL330H) on the ventilator side might be less expensive solution, but if they want the choice to use either CE or P2P, then a system using the TRF7970A would be more appropriate.

     can send over more if needed - but to start I hope that simple explanation helps you out. 

  • Hey Josh, 

    Thanks for explaining.

    I would like to make something clear, 
    regarding you said: "The card cannot send back anything to the reader on its own accord. (this is analogous to an I2C master and slave relationship - hope that makes sense - if you are familiar)" which i conclude that if in a Card Emulation, the smartphone or tablet which is acting as a card won't be able to transmit data to the reader, will it?

    and i am little bit confused if that the case, you earlier said that "either one will work for you in this application".
    it sounds that you suggested in the card emulation can be used to send new data from mobile phone to the ventilation system too. 

    Sorry that I made myself too much confusion...

    I give this link to illustrate what is my expectation for the NFC operation in a ventilation systems (in case i fail to make myself clear) :

    Thank you in advance :)


  • the emulated card or dynamic transponder will send new data back as requested by the reader. 

    to be clear the process/scenario here would be: 

    reader could read activate and select the tag, then read out data. then reader would leave (handset removed)...then the emulated card or dynamic transponder could update its own contents because of new data being collected on that side of the application and some time later the reader would be presented again to activate and select the tag, then read out data (new or otherwise)

    so the system can be continuously datalogging on its own and provide data back upon request (if an emulated card or dynamic transponder) - but only when commanded to do so by the reader.

    if a P2P system, the ventilation system could continuously send back new data as long as the connection was there, without being commanded to do so by the other peer. 

    any clearer?


  • Josh,

    Thank you for your answer, I seems to understand what you mean. If you do not mind, I have another question for you,

    So, I am currently developing a new ventilation with NFC where it is used for home automation. Thus we can collect information from the ventilation devices (such as mode or fan  speed) and probably, we can adjust the setting of the mode through the smartphone application. At this moment, we already have a microcontroller (atmel Atmega) in our device. Additionally, we want to connect the NFC through I2C communication.

    The first goal is to be able to read the status of our product by a NFC enabled mobile phone, and also change settings in our product by this mobile phone.
    We are thinking that a card emulation mode in our product will be suitable for this use case.
    Is that correct?
    Can you tell us more about the limitations of this mode (antenna requirements, maximum datasize / datarate etc)?

    We are also thinking about the ability to use NFC tags to control our product, e.g. by swiping an NFC card in front of our product a setting would be changed.
    For this we are thinking that our product must act as a reader/writer.
    Is that correct?
    Can both modes (card emulation and reader/writer) be combined in one product?
    Is additional SW/HW or another NFC controller needed to support both?
    Is for example a larger antenna needed to support both?

    As an alternative of the card emulation mode, peer-to-peer mode might be useable as well, since both the mobile phone and our product are powered, and have a processor.
    Is there any disadvantage (in HW/SW etc) in using peer-to-peer mode instead of card emulation mode?

    Thanks in advance. 

  • Oh, and I have another question,

    Is there any difference use of this board:

    With this one?

    I thought the major difference is on the antenna design, but it looks like if i compare the datasheet, both of them are almost similar. Is that right?

    Please let me know if there is any difference aspect that I've missed...

  • Stella - 

    for connecting TRF7970A + MSP430G2553 MCU via I2C, we have prepared this example:, the accompanying code example currently is as reader, but we have done other examples on this platform to show dedicated CE and P2P modes, too. This is a good example to answer the questions about small module size including antenna, etc.  The antenna requirement is that is matched to 50 ohms @ 13.56MHz, with a Q of ~8 (this means BW (-3dB points) = ~1.7MHz) - we also placed U.FL connector on the module example to allow for other antennas to be connected (with onboard one then disconnnected, of course)

    the reader mode will allow you to present a card and collect the configuration data that you like, in either NFC NDEF format or just in straight RFID mode, where the block data would not be preceded by the capability container information. Either way, this device will get the info in and pass it back for use in the system. Currently, the project on the web in the TI designs is just showing basic function, but since release we have expanded the scope of the code so that we can read out (in addition to the UID or PUPI) all data from: ISO14443A/B (this covers NFC Type 2, Type 4A and Type 4B), FeliCa (this is NFC Type 3), and ISO15693 (Type 5) - in the TI E2E Forum i have been giving that example out and we continue to work on it as time permits (nights, weekends, sparetime :)

    the RF430CL330H (the dynamic NFC Type 4B Tag Platform) will talk directly to an MCU via I2C. See examples here: and here :


    regarding the question about P2P vs. CE mode - in this case either one will most likely work equally well - data rate limitation on the CE mode with the TRF7970A is 106kbps in Type A or B mode, 212 or 424 in Type F mode. in P2P same three data rates apply (this is to spec, too). The RF430CL330H is capable of operating over the air at 106kbps, 212kbps, 424kbps or 848kbps, but almost all handsets never ask to change the data rate above 106kbps, where the communication starts.


  • the difference between the BoosterPack and the EM header board are just the connectivity options really - meaning, the EM header board was intended for the MCU platforms with EM headers (like the MSP-EXP430FR5739, MSP-EXP430F5529, etc.) and the BoosterPack fits on any TI MCU LaunchPad (G2xx, F5529, Tiva based, CC3200, etc.)