• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 18 subscribers
  • Views 2887 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DLP-7970ABP / ISO 14443-B Proprietary Tag

forum_user
Expert 1090 points

Other Parts Discussed in Thread: RF430FRL152H, DLP-7970ABP, MSP-EXP430F5529LP

Slight deviation from the original reason we obtained the DLP-7970ABP (To work with the RF430FRL152H). We were testing some additional tags, in particular the Maxim MAX66040K ISO 14443-B secure memory tags and found that when using the DLP-7970ABP Example Code (Rev. A) with the MSP-EXP430G2, the tag is only recognized when placed in a very particular spot, laying down on the PCB. ISO 14443-A and ISO 15693 tags have no issues. 

When running the DLP-7970ABP on an MSP-EXP430F5529LP running the NFCLink firmware and nfcplayer, the tag is recognized from about 3cm away. 

Is there something fundamentally different in the way the platforms are interacting with the tag that comes immediately to mind, or something that should be tweaked with the example code? 

Thanks, Karl

  • 0
    TI__Guru*** 135355 points

    Hi Karl,

    Based on your description it seems like that it may an issue where the guard time needed for the ISO14443B tag from Maxim is longer than what the example software is using currently. That example software is setup to follow the specifications when it comes to permitted guard time, but certain tags which are passively powered such as the RF430FRL15xH require a longer guard time in order to harvest energy from the RF field. This may be the case for the MAX66040K tag as well.

    I am working on updating the DLP-7970ABP Example Code which you are referencing to handle situations like that. It already has an extended guard time for ISO14443B. In our other E2E thread, I provided an updated example project for the G2 LaunchPad. I recommend trying that and seeing if the tag will perform better with that firmware.

    The link for that project is: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/667/TRF7970ABP_5F00_G2_5F00_FRL_5F00_Reader.zip

  • 0 in reply to Ralph Jacobi
    Expert 1090 points

    That project seems to only have the iso15693 interface files. Is there a different link? 

    Thanks, Karl

  • 0 in reply to forum_user
    TI__Guru*** 135355 points

    Hi Karl

    Ahhhh right, sorry - forgot that particular one was just for our FRL tag.

    Here is the link which contains ISO14443A, ISO14443B, ISO15693, and FeliCa: EDIT (My copy/paste failed me...): http://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/667/TRF7970ABP_5F00_RFID_5F00_Reader_5F00_Demo.zip


    Sorry about that!!

  • 0 in reply to Ralph Jacobi
    Expert 1090 points
    Thanks, unfortunately no difference in behavior. Verified this version had the additional delay and even increased it. I believe I had done the same in the original project. Data sheet indicates the tag only needs ~1ms to startup.
  • 0 in reply to forum_user
    TI__Guru*** 135355 points
    Hi Karl,

    Okay. The exact tag you have seems to be obsoleted on distributor stores, but we are getting the next gen version of it which is available to test with and figure out what it is going on. I'll also look over what NFCLink might be doing that is different from the code I provided.
  • 0 in reply to Ralph Jacobi
    Expert 1090 points
    Unfortunately the next gen versions are the 66240/66242, both of which are iso15693 (and for the record work just fine), I have them both here.

    Would appreciate any insight you can get from NFClink.

    Thanks again, Karl
  • 0 in reply to forum_user
    TI__Guru*** 135355 points
    The one we found is the MAX66140K which is a Type B/ISO14443 B version still.
  • 0 in reply to Ralph Jacobi
    Expert 1090 points

    Great, hopefully they should behave about the same.

    Karl

  • 0 in reply to forum_user
    TI__Mastermind 47315 points

    Karl,

    We received the MAX66140K-000AA+ tags, but unfortunately these are not type B.  The Digikey description had them labeled as type B, but they are in fact ISO 15693 only per the datasheet.  I checked on the Maxim website and it seems the only active RFID products they have are ISO 15693 and the ISO14443B tags have been obsoleted(see link below).  Where did you obtain the type B tags from?  Are you planning to use them for a new application?  It may be difficult to source them as I cannot find any place to order from.  Please let me know if you have a source of these tags where I can order some from, otherwise you may want to consider a different tag for your application. 

    https://para.maximintegrated.com/results.mvp?fam=ibutton_rfid&sel=no&295=Tag%7CReader 

  • 0 in reply to Eddie LaCost
    Expert 1090 points

    They were sourced some time back directly from Maxim (at least the ones I have). The work we did with the tags in the past is with another customer. We're working on finding a new platform to replace the legacy NXP one in use now and were hoping the 7970A could cover all use cases. 

    Is there anything in the type B initialization between the sample code provided and the NFCLink firmware that could explain the behavior difference? It would seem it is not an issue with the 7970A / Booster Pack from a hardware perspective...

    Karl

  • 0 in reply to forum_user
    TI__Guru*** 135355 points

    Hi Karl,

    I have been looking into this on the software end and I think I may have found something that could explain the performance issue. It seems there was a small error in the Modulator Control settings where the modulation depth is being set to 7% rather than the 10% defined in the ISO14443B standards.

    Please find Line 903 in trf7970.c (within the Hardware folder): pui8Write[1] = 0x02; // Sys Clock Output = 13.56MHz, ASK 7%
    And change it to: pui8Write[1] = 0x00; // Sys Clock Output = 13.56MHz, ASK 10%

    This may explain why the read range was reduced as with a lower modulation depth the tag may need to be placed closer to the antenna to properly receive the data packets. This would be especially true for the BoosterPacks which operate at 3.3V.

    Try this fix and see if that improves the performance of the tag reads with the Maxim tag.

  • 0 in reply to Ralph Jacobi
    Expert 1090 points

    That did it! Has the same range and response now as the NFClink version.

    However,  it seems very erratic in the time it takes (and success) of detecting an type 2A tag (mifare ultralight). The original demo program from the official page detects it fine / with same original range. 

    ISO 15693 is fine for the RF430FRL152H and memory dump, but slow to react to other tags like a MAX66242, unless the Iso15693_Anticollision call is swapped out for Iso15693_SingleSlotInventory in iso15693.c:80

    Hope this is helpful feedback, wondering what's causing the behavior on the 2A tag. 

    Thanks, Karl

  • 0 in reply to forum_user
    TI__Guru*** 135355 points
    Hi Karl,

    Glad to hear that fix worked out, and thanks for reporting the issue to begin with!

    Thanks for the feedback on the ISO15693 time, I made that observation as well. It is just a matter of how the firmware is setup in flow, and I have recently addressed it on my internal version by modifying flow to do a single slot inventory first, and only use Anticollision if needed to resolve a tag collision.

    I am a bit surprised to hear about the inconsistent success with the Type 2 Mifare Ultralight tag. I do expect it to be slower than the demo code as the demo code did not have a proper implementation of the ISO14443A anticollision process. The updated version handles ISO14443A Anticollision entirely, but as a result it is a little slower because additional commands are issued. However, there shouldn't be inconsistency in the actual success of detecting those tags. I've tested extensively with Mifare ultralight, and tested a few Ultralights I have at my desk again just now and see no issues with detecting the tags.

    Is it just one Ultralight tag, or many? I have occasionally seen Mifare tags with poor antenna tuning (+/- 100 MHz) show up and those tend to be much more finicky about passing through anticollision for Type A in general.
  • 0 in reply to Ralph Jacobi
    Expert 1090 points
    It was all the UL's I have. Apologies, turns out that in moving the booster pack from the G2 to the F5529LP I finally forgot to flip the IRQ jumper. Seems to be working consistently now.

    I'll keep that change I made in for the single slot inventory and look forward to any updates you might provide of this firmware going forward.

    Thanks again,
    Karl