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.

RF430CL331H: Transmitting 80 kB with RF430CL331H

Part Number: RF430CL331H
Other Parts Discussed in Thread: MSP430FR5962,

Hi,

my customer wants to transfer a set of data that if about 80 kB. We proposed RF430CL331H as it supports data streams from the MCU (MSP430FR5962 in this case). Looking at the different threads, it seems that this device supports a maximum file length of 64 kB ().

If I understand the NDEF format correctly, there might be a possibility to support even 500 MB of data by using MB and ME fields in the header.

What is the easiest way to transfer about 80 kB data using RF430CL331H?

Best regards,
Phil

  • Hello Phil,

    The NDEF specification sets the broad use case, which is then divided into sub cases.

    For the RF430CL331H, the sub case in question is the Type 4 Tag Specifications, which for NDEF formatted tags indicates the following:

    MLe (bytes); Maximum R-APDU data size

    • Defines the maximum data size that can be read from the Type 4 Tag using a single ReadBinary command.
    • The valid values are MLe = 000Fh-FFFFh.
    • The values between 0000h-0000Eh are RFU.

    MLc (bytes); Maximum C-APDU data size

    • Defines the maximum data size that can be sent to the Type 4 Tag using a single UpdateBinary command.
    • The valid range is MLc = 0001h-FFFFh bytes.
    • The value 0000h is RFU.

    Based on these, 2^16 or 65,536 bytes is the max size supported in a single NDEF message that follows the specifications.

    This limit comes from the NFC Forum specifications, and it is not a device based limitation. The RF430CL331H can handle larger transfers, but it would violate NFC Forum specification.

    If they want to follow NFC forum specifications, they will need to store the 80kB of data into two separate NDEF messages, and read each of them individually.

    As a potential alternative - if the customer is functioning in a closed loop system where they have full control of the NFC Reader/Writer devices, do not need to interface with NFC-enabled smartphones/tablets/etc, and will not test their devices against NFC specification - they could just ignore that aspect of the specification. But that would make them non-compliant with NFC and no NFC-enabled device would be able to operate with their system, so it really depends on how they define their system and what risks they are willing to take in terms of not having such capability for future revisions without a notable firmware update.