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.

PeerToPeer connection between TRF7970A evm and Android Smartphone (Nexus s) doesn´t work.

Other Parts Discussed in Thread: TRF7970A, MSP430F5529, MSP430F2370, MSP430G2553, TIDM-NFC-P2P, TIDM-NFC-TRANSCEIVER, UNIFLASH

Hi,

I am working on a NFC application project for a Android Smartphone (Nexus s). I tried to connect the Nexus with the TRF7970A evm over PeerToPeer, but it doesn´t work.

Android use for the P2P connection the NDEF Push Protocol (com.android.npp library). My question now is, does the TRF7970A supports this protocol (has this library included)?

Or, is it even possible to establish a connection between the TRF7970A evm and a Android Smartphone over P2P?

Has anyone some experience about this? Hope someone can help me.

 

Greetings

Bernd

 

 

  • Bernd -

    please see start of presentation here which should assist you here. we will be releasing some more formal collateral on this topic quite soon.

     

    6366.Connecting to Android.pdf

  • Hi,

    how to configure the register of trf7970 when connect to android smart phone? I'm working on connect samsung galaxy nexus (4.0.4) to trf7970a. Please tell me how to initialize the register such as ISO_CONTROL, etc.

    Thank you.

  • Victor -

    Are you trying to do P2P with the phone, be read by the phone in card emulation or be a reader to read the phones tag? or are you trying to connect the TRF7970A to the OMAP4 inside the phone and replace the PN65n/PN544 inside?

     

  • Hi Josh,

    I am also working on P2P communication between an Android smartphone (Galaxy Nexus) and the TRF7970A (on the TRF7970A EVM). I want to establish reader to reader communication, but I haven't got a clue on how to do this. I have looked at the "Connecting to Android NFC P2P" document, but that really didn't clarify much for me. For instance, the Android phone will send a polling message containing "06 00 FF FF 01 01". Is this automatically received by the TRF7970A EVM with the standard firmware or do I have to change certain registers? Also, where in the reference firmware will this data be received to be acted upon? So many lines of code are nothing more than a maze to me...

    I hope my question was clear and that you can shed some more light on this.

    Regards,

    Matthijs.

  • Dear all,

    Does anybody becoming successful, communicating the TRF7970A with Samsung phones?.

    I’ll try to follow the procedure explained in the document (6366.Connecting to Android.pdf), posted by Mr. Josh. But I can’t  reach the connection!!

    First thing was:

    - The first command recived from the Samsun are (0x06_0x00_0xFF_0xFF_0x00_0x01), instead of the values (0x06_0x00_0xFF_0xFF_0x00_0x01) as its explained in the document!

     - Second thing was that after sending the SENS_RES to the phone (0x14_0x01,…..), I never receive any answer (ATR_REQ) from the phone!

     

    Does anybody have more information regarding to it?

    I’m using the  TRF7970A_EVM and a Samdung Nexus S!

    Thanks in advance!

    Lluis O.

  • Lluis -

    As the EVM firmware and GUI was created before the DEP and SNEP docs were ratified/finalized/completed...you are right that the setup you have is not exactly working with the phone the way you want it to.

    however -  if you want to modify the MSP430F2370 firmware by using the attached MSP430G2553 and MSP430F5529 examples, this would be the way to go here. and if you want to repost that (in the spirit of the forum) that would be good, too...we just have not had the time yet, sorry - this is using NFC-F @ 424kbps and supports GB NDEF push (what ships on Nexus S, we have found that there is a nice app on the market from KDDI which works well for this) and SNEP (functionally = Android Beam on ICS) although we found that this implementation does not exactly comply with the NFC specs, it does work.

    6457.NFC_P2P_eZ430G2553.zip

    8562.NFC_P2P_02_29_12_v2.zip

    i have also attached here a doc (excerpt from a forthcoming app note) regarding the steps you will see occurring.

    3531.NFC Peer to Peer Communicaiton with Android Nexus S using MSP430 and TRF7970A.pdf

  • Dear Josh,

     

                Thank you very much for your support!

                The information that you provide is really helpful!!

                I saw my mistake, and it was in the register 0x00. I suppose that setting the bit 5 of the control register, it puts the radio ON, and it can cause an RF collision.

                The setting this bit (ISO_CONTROL_REGISTER(0x00).bit5), I receive the answer from the phone!

                Regarding to the firmware, I using the TRF7970AEVM, but we interface the SPI directly from the computer, and we don’t use the MSP430F23 in the board. I’m so sorry for that!

                However I can help in the forum by posting the code we use!

                Regards,

    Lluis.O.   

  • I am working with Nexus S with android 4.0.4 and a board design myself.

    I don’t receive SENSF_REQ but directly ATR_REQ. Is it normal?

    And When I send the frame below I received  new ATR_REQ like I send nothing.    
        response[0] = 31; // lg
        response[1] = 0xD5; // ATR_RES    
        response[2] = 0x01; // ATR_RES
        for(i=0;i<10;i++)
            response[3+i] = TargetCID[i];     
        response[13] = 0x00;                 
            response[14] = 0x00;                
            response[15] = 0x00;               
            response[16] = 0x0E;
            response[17] = 0x32;   
            response[18] = 0x46;     
        response[19] = 0x66;     
        response[20] = 0x6D;              
        response[21] = 0x01;    
        response[22] = 0x01;    
        response[23] = 0x10;
        response[24] = 0x03;              
        response[25] = 0x02;    
        response[26] = 0xFF;    
        response[27] = 0xFF;
        response[28] = 0x04;
        response[29] = 0x01;
        response[30] = 0x96;

    thank you for your help,

    Remi

  • Remi -

    i think your length might be off and i am not sure what your bytes 28, 29 and 30 are doing there...the TRF7970A will generate the CRC for you, if that is what you were trying to do there.

    See the table here as example of what the ATR_RES portion of the string coming from your MCU to the TRF7970A should look like.

     

    Format
    BYTE #
    Name
    Value (in hex)
    SoD
    0
    Length
    0x1C (27 byte payload +1)
    Payload (NFC-DEP Portion)
    1:2
    Command (ATR_RES)
    0xD5, 0x01 (Required Values)
    Payload (NFC-DEP Portion)
    3:12
    NFCID3T
    NFCID (bytes 3:10 are NFCID2 of target)
    Payload (NFC-DEP Portion)
    13
    DIDT
    0x00 (Must be same as ATR_REQ value)
    Payload (NFC-DEP Portion)
    14
    BST
    0x00 (Required Value)
    Payload (NFC-DEP Portion)
    15
    BRT
    0x00 (Required Value)
    Payload (NFC-DEP Portion)
    16
    TO
    0x0E (max waiting time)
    Payload (NFC-DEP Portion)
    17
    PPT
    0x32 (matches ATR_REQ value)
    Payload (NFC-LLCP Portion)
    18:20
    LLCP Magic #
    0x46, 0x66, 0x6D
    Payload (NFC-LLCP Portion)
    21:23
    TLV Version #
    0x01, 0x01, 0x10 (version 1.0 spec)
    Payload (NFC-LLCP Portion)
    24:27
    TLV Services
    0x03, 0x02, 0xFF, 0xFF (all services)
    EoD
    28:29
    CRC_F1, CRC_F2
    Generated by TRF7970A, not seen in the digital domain
  • Josh,

    Thanks you for your response.

    I correct my mistake and now I send the message below but I receive only 1 byte after (0x26). Do you know what does it mean ?

    0 1C
    1 D5
    2 01
    3 01
    4 FE
    5 03
    6 04
    7 05
    8 06
    9 07
    10 08
    11 09
    12 0A
    13 00
    14 00
    15 00
    16 0E
    17 32
    18 46
    19 66
    20 6D
    21 01
    22 01
    23 10
    24 03
    25 02
    26 FF
    27 FF

    Best Regards,

    Remi

  • Remi,

                One thing if it can help you:

                I can experiment the same behaviour, as you explained. Using the Nexus S.

                What I find is that the Nexus its sends alternatively the SENS_REQF command at the ATRIB_REQ command alternatively.

                What I do to saw that is to attend the TRF7970AEVM_IRQ quickly and thus I saw that the Nexus send both commands.

                I hope that can help you.

    Regards,

    Ll.O.  

  • Lluis,

    Android (Nexus S Android 4.0.4) do an attempt of 100ms every second.

    During this attempt I saw 3 ATR_REQ and 2 SENSF_REQ:
    @10ms : first ATR_REQ
    @20ms : second ATR_REQ
    @30ms : third ATR_REQ                
    @45ms : first SENSF_REQ
    @70ms : second SENSF_REQ

    I don't understand why I received  ATR_REQ before SENSF_REQ ?

    SENSF_REQ is needed to have ATR_REQ ?

    Is there a specific timing to send the SENSF_RES response after SENSF_REQ ?

    Have you made ​​your software on TRF7970AEVM. Does the peer to peer works with android on TRF7970AEVM board?

    Thanks,

    Rémi

  • Hello together,

    I have the same problem as described above. I am using the Samsung Galaxy S3 and the TRF7970A_EVM in my application. I receive a SENSF_REQ from the Handset. After sending the SENS_RESP from the TRF7970A to the Handset I never receive any answer (ATR_REQ).  

    I am using following documents as recommended from Mr. Wyatt:

    http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/667/6366.Connecting-to-Android.pdf

    http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/667/3531.NFC-Peer-to-Peer-Communicaiton-with-Android-Nexus-S-using-MSP430-and-TRF7970A.pdf

    I basicly use the following software for my application:

    6237.MSP_430_NFC_P2P_4_2_2012.zip

    2451.NFC_P2P_02_29_12_v2.zip

    Does anybody have an idea whats the problem with the Samsung Galaxy S3 and the TRF7970A?

    Thank you for your help.

    Mike R.

  • Sorry to all,

    here are the right software files I use.

    No password is needed.

    Firmware for the MSP430F2370 developed with IAR embeeded workbench for MSP430

    5852.NFC.zip

    App for the Smartphone

    2311.APP_NFC_P2P.zip

    Best regards

     

  • I am working on an NFC project for school and I tried updating the firmware to the MSP430F2370 on the TRF-7970A board. The problem I am having is the the NFC code is producing compiler errors. It does not recognized U08_t. In the original firmware for the MSP430, the U08_t datatype was defined in types.h, but it is not defined in the new code. Should I include this in the types header file so the project will compile. Please help.

    Thank you

  • Is there a way to access the msp430 on the development board so that I can send hex commands or replace the host with a microcontroller?

  • Hi Mike R.

    Now we can unzip your files, but the source files and drawables in the Android project are missing.

    Maybe in your NFC_Connect project are files missing too?

    Please zip them again.

  • Hi, Mike 

    I meet the same problem. I am use the HTC/SONY android phone.

    After receive a SENSF_REQ ,And I reply the SENSF_RESP to the Handset.
    I never receive any command(link ATR_REQ, ... etc) .

    Does you or anybody solve that problem or idea? I had been stop here several days. 

    Thank for your help

    J.K Pan 

  • Hi, I have exactly the same problem that I have seen in this forum before, I am working with an Xperia phone and I can obtain the sensf_req (polling request in the I.S.O.), and inmediattly I answer with a 0x140101feffffc2c3c4c5c6c70fab (sometimes without the 0x0fab but with the length:0x12, as the stanrdard recommends), but nothing. I saw that someone before configure the 0x00 register with 0x01 (with b5=0;) instead of 0x21, but I can't prove it now, but, Was that the correction that would help me with this issue?. Is there any solution after all this time.

  • Daniel - 

    see if this enlightens the issue for you somewhat. 

    8360.Initiator P2P Operations with the TRF7970A+MSP430 Training.pptx

  • Dear Josh,

    can Android phone send to and  then receive data from trf7970 in one connection? After 7970a received data, sent back data to phone before DEP disconnect.  Does it work?

    Best regards,

    thanks.

  • Victor - 

    pls. use attached to demostrate P2P using the EVM with the NFC enabled handsets or between two EVMs

    Docklight can be downloaded from here ==> http://www.docklight.de/download_en.htm 

    3125.TRF7970AEVM_P2P_Tools.7z

  • Dear Josh,

    Thank you for your kindly help. I'm still working on receive and transmit data in one DEP loop. I will let you know if I have any further information.

    I have a question about TRF7970 P2P connection with Nexus 4 and Galaxy S4. The code work well with Nexus S using P2P connection, but does not work with N4 or S4 which using Broadcom BCM2079x NFC chip.

    ========= TRF7970 main register setting as follwing ==========
     ISO_CONTROL(0x01)  = 0x23; // NFC passive target @ 424
     NFC_TARGET_LEVEL(0x18) = 0x86;  // NFCID 10byte, AutoSDD disable
     NFC_LOW_DETECTION(0x16) = 0x07;   // Maxium RF field level
     FIFO_IRQ_LEVEL(0x14) = 0x0F;  // RX high = 96, TX low = 32
     RX_SPECIAL_SETTINGS = 0x1C;  // 100k~1.5M,Gain 15dB, AGC 5x, 8 subcarrier
    =====================================================

    ===== Register value when P2P communication =====
    1) Regsiter : NFC_TARGET_PROTOCOL(0x19)
    N4 (BCM) phone: the value of this register is 0x9B; compared with Nexus S(NXP) phone , this value is 0x93.
    There is no detail information about BIT3 (pas_106) descripion.

    2) Register: IRQ_STATUS(0x0C)
    When N4(BCM) phone, BIT4 is set idicate any protocol error.

    3) SENSF_REQ
    TRF7970 can recevive SENSF_REQ from N4(BCM) phone, RC=0x00, TSN=0x03. After reply with SENSF_REQ, there is no data received.
    ============================
    void TargetSenseResponse(TSN) {
      slots = TSN;
      response[0] = 18; // Length
     response[1] = 0x01;
     for(i = 0; i < 8; i++){
      response[2 + i] = targetid.array[i]; // Array length is 8 bytes
     }
     response[10] = 0xFF;
     response[11] = 0xFF;
     response[12] = 0xc2;
     response[13] = 0xc3;
     response[14] = 0xc4;
     response[15] = 0xc5;
     response[16] = 0xc6;
     response[17] = 0xc7;
     Delay(T_2400US); //  Delay for 2.4ms

      for(i = 0; i < (slots + 1); i++){
            if(i == 0){   //send the reply in the calculated timeslot
                NfcSend(&response[0]);
                break;
            }
       Delay(T_1200US);   // Delay for 1.2ms
       }
    }
    ============================

    Please give me any suggestion.

    Thank you!

    Victor

  • Hello,

    I am also stuck and having the same problem with TRF7970A EVM and Nexus 7. I also send SENSF_RES response after SENSF_REQ. But, I don't get any command like ATR_REQ in return.

    Do you think that it has to do something with timings? Perhaps we are not reading the FIFO status and FIFO content at the right moment. ?

    Best regards.

  • Hi! mhr456,

    NEXUS 7 should be good. It is as same as NEXUS S. Please check your code and read the following reference:

    3531.NFC Peer to Peer Communicaiton with Android Nexus S using MSP430 and TRF7970A.pdf

    Best regards.

  • Hi Victor,

    Do you solve these issues? I faced exactly the same problem with you with my Nexus4 . Hope your helps. Many thanks.

  • Hi Victor,

    Like SeaFesse above, I'm interested in finding out if you solved your problem with the Nexus 4 and S4 but I have one more question.

    Can you tell us the Android version of your phones ? Because I have problems with the Nexus 4 as well but I assumed it was because of the latest Android 4.3 version. 

    But the S4 doesn't have the 4.3 and apparently it doesn't work for you as well so I'm concerned that getting the TRF7970A to work with most if not all Android phones is pretty difficult.

  • the problem is more that none of the phones out there are certified, which means that there are varying interpretations implemented in the various devices. Erick on my team has been doing extensive work on the subject and the NFCLink package that we released in June is first finished product of the work we have been doing. We did also notice that the S4 was doing NFC-F a bit differently and have implemented support for that. We are also interfacing with the technical team from the NFC IC vendor in that device to make sure they are on the same page as we are. Furthermore, one of our customers has just submitted their product for testing against 30-40 NFC devices and we have not heard anything negative back from them, plus we test against all the devices we have, and with test equipment as well.

    So...the TRF7970A will do the job, its more a matter of the firmware support to handle all these slightly different implementations. As time progresses on and the handsets are actually NFC compliant, these kinds of issues will diminish. 

  • Hi,

    Was this issue finally resolved. 

    I am stuck at the same point where I recieve the SENS_REQ from an Experia, but after sending a SENS_RES from the TRF7970 I do not recieve an ATR_REQ from the phone.

    Any help would be highly appreciated, really stuck bad here.

    Regards

    Royston

  • Hi, 

    I am new to NFC and trf 7970A. I would like to know the 8562.NFC_P2P_02_29_12_v2.zip is an example of peer to peer mode communication? Is it working fine? I have tried to run the code.I think the data processing is having some issues. Please let me know the status,

    thanks,

    Shiju

  • Shiju - 

    best example for P2P (which is highly interoperable) is posted here: 

    http://www.ti.com/tool/TIDM-NFC-P2P

    (please see the associated app note which includes a table showing which devices are capable of what, this code does all P2P protocols and data rates)

    next best example is here, and will be updated on the web in a week or so, to be at same level for P2P as the first example, but also includes R/W card support and CE mode. 

    http://www.ti.com/tool/TIDM-NFC-TRANSCEIVER 

    both examples can run on MSP-EXP430F5529 LaunchPad, with the DLP-7970A BoosterPack. 

  • Hi ,

    Thank you for the valuable reply. How can i download the CCS project for TIDM-NFC-P2P? Is it the demo code "MSP430F5529_P2P_Demo" in the folder TRF7970A_P2P_1.00.35 after installing the TRF7970A-1.00.35-windows-installer.

    Thanks and regards

    Shiju

  • the hex files are located in folders which are arranged by board in this folder location

    C:\ti\msp430\TRF7970A_P2P_1.00.35\MSP430F5529_P2P_Demo

    there is a folder for the -F5529 EXP board and one for the -F5529 LaunchPad

    whichever hardware you have, open the relevant folder and the hex file to download is in there.

    Uniflash or Elprotronic tool can be used to update your MCU, if you are not using CCS at the moment. 

  • Hi Josh,

    Thank you for the valuable reply.

    I have imported the MSP430F5529_P2P_Demo code in to CCS and i could build and load the code successfully.

    The data sending is working perfect and verified. Now i have to check the data reception and to verify the received data.Is the processing of received data is handled in the MSP430F5529_P2P_Demo code?

     

    Thanks and regards,

    Shiju

  • yes it is. it you use the GUI with the LP, its easier to look at what is going on and if you use standalone mode with the EXP board, the LCD display will show you the # of bytes rx'ed, etc. bottom line though, is that this is not a host based system like what we have in the NFCLink example, this is a self contained, standalone implementation which is the point i think you are looking for, correct?

  • Hi Josh,

    Thank you for the reply. Yes exactly i am looking for the standalone mode. I did not get time to analyze the received data.I will check it and inform you as soon as possible. As per your explanation i think i could display the received message on LCD easily and verify the result. I will try it as soon as possible. I could not find the verify button.How could i use the verify answer?

    Thanks and regards,

    Shiju 

  • not the message itself on the LCD, but the # of bytes, as the message itself will always be too long/large to display on such a small screen, with the other things on there already. 

    if you want to see the message itself, it a format which is arranged so its human readable, the PC GUI can show you that.

    See page 29 in the user guide ==> http://www.ti.com/lit/an/sloa192/sloa192.pdf , this is screen shot of GUI and is representing what will also show up as RX'ed # of bytes. 

    then on page 31 of the same document, you can see the tab of the GUI which will show you human readable formatted NDEF data. 

  • Hi Josh,

    I have read the document. I am looking for standalone mode. I want to process the received data in standalone mode.

    I have tried to view the received data by using the code in debug mode and using break point in the following location.

    // Check if the last packet was received completely
    if((uint16_t) sP2PRxStatus.ui32PacketSize == ui16BytesReceived)
    {
    // Reset Bytes received
    ui16BytesReceived = 0;
    }

    I could find that the url in the memory location of sP2PRxStatus.pui8RxDataPtr. But when i send the url (for eg www.google.com) the data in the memory location will contain only google.com (www is missing). There will be few bytes (5 bytes ) before the received data. What is that data?Is it the expected result? 

    Thanks in advance,

    Shiju.

  • Shiju -

    NFC uses Record Type Definitons (RTD) which are well known already - in this case the well known type being used is a Uniform Resource Identifier (URI), so the NDEF content in what you describe above is a URI Record, which will be labeled with a Type (in this case you will find a 0x55, this is hex for ASCII letter U, for URI), then there will be the URI Identifier Code of 0x01 (this is coded byte which abbreviates http:www. or and there are of course other codes for https:www. , tel:, ftps:, mailto:, etc.) 

    so then for example you will find in the string similar to this in the NDEF response...

    should be 0xD1 0x01, 0x0C, 0x55, 0x01, 0x67,0x6F, 0x6F, 0x67, 0x6C, 0x65, 0x2E, 0x63, 0x6F, 0x6D, 0x0D, 0x0A

    where...

    0xD1 is TLV

    0x01 is length of record type (1 byte in this case)

    0x0C is length of payload

    0x55 is URI record type "U"

    0x01 is URI Identifier "http://www."

    0x67,0x6F, 0x6F, 0x67, 0x6C, 0x65, 0x2E, 0x63, 0x6F, 0x6D, 0x0D, 0x0A is the string which spells: google.com

  • Hi Josh,

    Thank you for the valuable information.

    Thanks and regards,

    Shiju

  • no problem - by the way - if you want to read/learn more about the RTD structure and any other NFC topic details, the NFC Forum has made public most of their specs, so you can access them, too. 

    all it requires is to register with them, then you can login as a guest ==> http://nfc-forum.org/our-work/specifications-and-application-documents/specification-application-license/

  • Hi,

    In our demo code the transferred string is "NFC - powered by Texas Instruments Inc.", which is 39 in length.

    static
    const uint8_t pui8NfcPoweredByTexasInstruments[46] =
    {0xD1, 0x01, 0x2A, 0x54, 0x02, 0x65, 0x6E, 0x4E, 0x46, 0x43,
    0x20, 0x2D, 0x20, 0x50, 0x6F, 0x77, 0x65, 0x72, 0x65, 0x64,
    0x20, 0x62, 0x79, 0x20, 0x54, 0x65, 0x78, 0x61, 0x73, 0x20,
    0x49, 0x6E, 0x73, 0x74, 0x72, 0x75, 0x6D, 0x65, 0x6E, 0x74,
    0x73, 0x20, 0x49, 0x6E, 0x63, 0x2E};

    this is the string array.

    0xD1 is TLV

    0x01 is length of record type (1 byte in this case)

    0x2A is length of payload

    0x54 is record type 

    02 is the Identifier .

    1) What are the 0x65 and 0x6E.

    2)The payload length is 2A (42). Our pay load is 39 bytes string +0x65 and 0x6E. Which is equal to 41 bytes.Plus the header gives 46 bytes.

    Is payload length given is correct?

    Did i misunderstood anything?

    Thanks and regards,

    Shiju

  • 1) 0x65, 0x6E is the language type, as 0x65 = ASCII value for e, 0x6E = n

    payload length looks correct = 42 bytes 

  • further - i was in a hurry before - sorry

    you have 39 bytes of message

    you have two bytes language field

    you have one byte saying you have two byte language field

    =42 bytes

    so NDEF record header is, like you say:

    TLV = 0xD1, 

    0x01 = length of record type (in this case it is Text)

    0x2A = length of payload (42 bytes)

    0x54 = T (binary encoding of the name, length defined in two bytes prior)

    The payload is: 

    0x02 = status byte: UTF-8, with two byte language code

    0x65 = e (ASCII)

    0x6E = n (ASCII)

    then the 39 bytes of your message: NFC - Powered by Texas Instruments Inc.

    0x4E:0x46:0x43:0x20:0x2D:0x20:0x50:0x6F:0x77:0x65:0x72:0x65:0x64:0x20:0x62:0x79:0x20:0x54:0x65:0x78:0x61:0x73:0x20:0x49:0x6E:0x73:0x74:0x72:0x75:0x6D:0x65:0x6E:0x74:0x73:0x20:0x49:0x6E:0x63:0x2E

  • Hi Josh,

    Thank you very much..

    Regards,

    Shiju 

     

  • Hi Josh,

    Now everything is working fine. Thanks you for giving valuable support. The NFC can be work in 3 modes 

    1.Card emulator

    2.Peer to peer mode

    3.Reader/writer mode

    Is the peer to peer mode is a combination of both card emulator and reader/writer mode ?

    Is it a mode in which the device can be a card emulator and a reader/writer?

    Is there any technical difference?

     

    Thanks in advance,

    Shiju

     

  • From air interface perspective, passive peer to peer operations are more or less identical to reader/writer and passive tag relationship. Active peer to peer operations are more akin to two readers talking in a half duplex fashion. 

    from a protocol perspective, P2P and the other modes are different - this is how the systems know which mode they are in and what to do...its all well defined

    http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-340.pdf (this is origin of P2P) and led to ISO18092 ==> http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_detail_ics.htm?csnumber=56692

    also, the NFC Forum Activity Spec is a great place to see the whole picture of the systems

    here is a link which will take you to the download area ==> http://members.nfc-forum.org/specs/spec_list/ 

     

  • Hi Josh,

     

    Thank you very much. It was very helpful.

     

    Regards,

    Shiju