Android SDK: readMailboxMessage() questions

[Andreas Angermayr]

Posted on April 23, 2018 at 23:04

Hi, I have a few questions about the use of the Android SDK for the ST24DV tags.

1) readMailboxMessage(0,0) allways returns a first byte which is zero. This zero-first byte seems to come from the tag itself, but I did not find any reference in the datasheet.

2) readMailboxMessage(0,1) where argument one is the mailbox adress, and argument two is the amount of bytes to read, never returns anything and the asyncrounous thread in which the function is calles terminates. Why is this?

3) fastReadMailboxMessage() and fastWriteMailboxMessage sho the same behavoir as the function call in 2). Is it possible, that these fast operation modes are not supported by my hardware (Huawei Mate 7)?

Any help would be very appreciated.

Yours, Andreas

#fastwritemailboxmessage #readmailboxmessage #first-byte #zero #st25dv #fastreadmailboxmessage

[Damien G.]

Posted on April 30, 2018 at 17:25

Hello Andreas,

First, for all the fast transfer commands , you must enable the mailbox with the ST25DVTag.enableMailbox() command.

For question 1:

myST25DVTag.readMailboxMessage(0,0) will read the full content of the mailbox as written by the I2C interface. The following statements are equivalent.

      

      response = myST25DVTag.readMailboxMessage(0, 0);

accomplishes the same result as:

      int len = myST25DVTag.readMailboxMessageLength();

      response = myST25DVTag.readMailboxMessage(0, len);

For question 2:

myST25DVTag.readMailboxMessage(0,1) will throw a BAD_PARAMETER STException.

This arises from the fact that

ST25DVTag.

readMailboxMessage(int address, int size) takes the actual number of bytes that you want to read from the mailbox. The RF command understood by the tag returns (size + 1) bytes.

To read a byte with the RF command, you would need to send a (size + 1) value of 0. When doing so for address 0, the command will actually return the whole content of the mailbox, as seen in question 1.

Because of the tag's behavior, it was decided to throw a BAD_PARAMETER exception for the parameter tuple (0, 1).

If you want to read the first byte, it is recommended to read the full content of the mailbox then select the first byte.

Regarding your question 3:

The ST25 SDK can be used for Android or any Java applications.

Libraries in the readers\ directory provide support for USB readers from ST and FEIG ELECTRONIC.

Fast commands are supported by ST type 5 readers but do not apply to Android phones.

More information on the fast transfer mode flow can be found in this application note:

http://www.st.com/resource/en/application_note/dm00328899.pdf

 

Best regards

[Andreas Angermayr]

Posted on May 04, 2018 at 16:46

Hello Damien,

thank you very much for the very detailed answer! However what I still dont understand is, why

byte[] sendByte = {0xAA};

mST25DV.writeMailboxMessage(sendByte);

byte[] recByte = mSt25DV.readMailboxMessage(0,0);

returns

{0x00, 0xAA}

  for

recByte

. Why is that first zero-byte added?

Plus I  have a new question: While testing how much time it takes to fill the whole 256 bytes of the mailbox, I came to the point where a

java.io.IOException: Transceive length exceeds supported maximum

exception occured when trying to send more than 241 bytes. I think this is a Android/Java problem, can you confirm this?

Looking forward to hear from you,

Andreas

[Damien G.]

Posted on May 04, 2018 at 18:53

Hi Andreas,

The first byte returned by

byte[] recByte 

mSt25DV.readMailboxMessage(0,0);

is actually the Iso command's status byte. A value of 0x00 means a successful operation.

Error values start with byte 0x01 followed by the error byte described in the Iso15693 specification document.

To retrieve the actual mailbox message, copy the byte array without the first byte:

byte[] message = Arrays.copyOfRange(

recByte

, 1,

recByte

.length);

However, I think you just pointed out an inconsistency in the API as the status byte is NOT returned in the case of a read size = 1... It's a bit of a mess. The correct fix would be to remove the status byte for all read sizes but would require a major release of the st25sdk library (and break existing apps). Thanks for bringing up this point to our attention.

For the Android Transceive length error, this may come from the IsoDep implementation on your smartphone. While the ST25DV tag can send responses up to 256 bytes of data + 7 bytes of protocol = 263 bytes, not all NFC  readers and controllers can accommodate this length.

This is why we have added getMaxTransmitLengthInBytes() and getMaxReceiveLengthInBytes() methods in the RFReaderInterface API. Call those to get the max value supported by your device then set your max read command accordingly (taking into account those 7 bytes of overhead detailed in the ST25DV's datasheet for the readMessage command).

Best regards,

Damien