• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 16 subscribers
  • Views 1402 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.

TRF7970A: High Speed, low latency packet rates for sensor interface

Philip Ouellette
Prodigy 50 points
Part Number: TRF7970A

I am researching using NFC for a non-contact sensor communication link.  In this case, power is not necessarily being supplied through NFC (our current design uses a low frequency inductive power scheme which we may keep).

The requirements for this sensor are pretty extreme. 5000 Hz measurement rate with a 0.2 mS latency.  I have looked at the TRF7970A which comes closest to meeting this (best case would be using 424Kpbs in a passive (peer to peer mode).  in this mode I can only get the 5000 Hz measurement rate by packing 10 measurements per packet which results in a 0.4 mS latency (this with a payload of 4 bytes per measurement).

Questions:

  1. Is peer to peer the best way to do this?  Tag emulation can support 848 Kbps, but I am having a hard time getting my head around how this works with a fast packet rate. The eval system I use seems to take a very long time to read a tag.
  2. Is it possible to run the Peer to Peer mode at 848 Kbps? I realize this is not supported in the P2P standard, but this is not a general purpose P2P system. It is for a captive non-contact sensor that is only used with our equipment.
  3. Our sensor must operate with large pieces of metal in close proximity. I plan on using ferrite shielding, but is the passive mode more effected by this than active?  From my limited understanding, it feels like active mode should be able to operate better in the presence of interfering metal, but I confess to limited understanding (this is my first NFC project).
  4. The TRF7970A documentation claims that a 1 mS delay must be inserted between collision detection and sending a packet in active mode. Is this a recommendation or is it built into the hardware?  If I am doing one way traffic (transmit only) can I bypass the 1 mS delay?

Any suggestions or help would be very appreciated

  • 0
    TI__Guru*** 135355 points
    Hello Philip,

    1) Peer to Peer is the best way to do this. Card Emulation wouldn't work well because the Reader has to the prompt the tag for information, so it would have to be very tightly synchronized and I don't know if that would even improve anything.

    2) I mean, theoretically, I suppose? But I wouldn't have a clue on how to implement that. That said, I think the Type F modulation is better for high data rates, and you can't use that modulation at 848kbps on the TRF7970A. I don't know if Type A would be able to handle the P2P side... anyways, nothing I can help you with on this.

    3) Metal is a problem yes, but ferrite shielding will help a lot. If you keep the initiator and target antennas close together you should be fine. Active mode is much worse for this, I would avoid that. Also Active mode will likely destroy your throughput, it is not robust and connection drops occur far more regularly even in robust systems. In our ideal setup, we still have 5-10% packet fail rates with Active P2P vs Passive P2P being 0.1%. That was with excellent antenna coupling and no metal anywhere around the system.

    4) For Active mode, that is part of the spec I believe. I recommend Passive mode as once you establish the connection, you can send data very quickly and there is no latency of turning on and off RF fields. You will find Passive mode is MUCH quicker to use for this application. For Active mode, you need to turn off an RF field, re-configure both devices, and turn on an RF field each time you want to send data which adds a ton of overhead. Active is the worst mode you can choose form really.
  • 0 in reply to Ralph Jacobi
    Prodigy 50 points

    Thanks for your reply. Details about our application:

    This is for a device streaming measurement data across a very short gap to a powered base station. Our goal is to be able to send measurement data at a 5000 samples per second rate with minimal latency. Ideally we would send one measurement per packet (0.2 mS latency). The payload data per sample is small (4 bytes).

    The data will be 99.9999% be sent only one way. Very occasionally the base station might need to send a command to the measurement device, but latency in that case is irrelevant (seconds are OK). I could even cycle power off/on to the measurement device so it will know the base station wants to talk back.

    We have absolutely no need for any kind of standardized NFC compatibility (readers/tags/Cell Phone etc). This is a high value, low volume product so BOM cost is not important.

    This is a refresh of an existing system that uses a Zigby radio link. The Zigby link does not meet our data throughput requirements and adds unnecessary complexity (pairing, interference from nearby equipment etc). The existing system uses a low frequency inductive link for power transmission. We could continue to use our existing inductive power system if required.

    More questions:

    Is the TRF7970A the best choice for this application or is there a different solution I should be looking at?

    Is NFC data symmetrical between the active and passive device or is the passive device able to send data at a faster rate then it's active partner can?

  • 0 in reply to Philip Ouellette
    TI__Guru*** 135355 points

    Hello Philip,

    That you don't need interoperability is excellent for your use case. You can basically use a proprietary communication method based loosely on the Peer-to-Peer standards to push up your throughput

    However, I am not sure you can hit the speed you are referencing, NFC is not designed to be a very high data communication. For example, I timed out the transfer of a 6 byte packet including IRQ for TX Complete with SPI @ 4MHz at 424kbps at 0.37 ms, and a 30 byte packet with the same specs at 0.89ms. I don't think you can get close to the 0.2ms per 4 bytes requirement...

    Depending how long the measurements are done for, you could buffer them and send them out in chunks while acknowledging there is a delay in the system - but if its continuous, you will eventually fall behind too far to make such a thing viable. I'd say that option would only work if the measurements are done in bursts short enough to let the NFC communication catch up to 'present' time.

    In any event, the TRF7970A is the best device in the TI NFC portfolio for this application - if that doesn't work timing wise, there isn't anything else we have that is a NFC which would help.

    Ultimately, I would recommend trying this by using Passive P2P at 424kbps.

    Passive P2P will definitely be faster. You won't need to reconfigure the device between communication cycles or wait for RF field turn on and RF field collision guard times. This will save you a lot of time.

    Our full P2P app note can be found here: http://www.ti.com/lit/pdf/sloa192