NFC-IP disconnection with Nokia 6131

[hrdonka]

Hi all,

I made simple example of NFC-IP communication between Arygon NFC Reader and Nokia 6131. The communication breaks after 2 seconds. (Nokia reads empty data and consequent trial to read or write gives NFCException). When the same is made with Samsung X700 (also with NFC) it works without any problem.

Is there some timeout defined in Nokia? Can this be changed?

[super_beda]

Hi hrdonka,
please could you tell how did you get Samsung NFC phone?I heard about it but i can't find it anywhere..

[super_beda]

Hi again,
I have to buy a NFCIP reader.Plòease could you tell if Arygon supplies good reader SDK? Where did you buy your reader?
Thanx in advance

[venidici]

Hi,Hrdonka.
I intend to develop an application to exchange data between the PN531 Arygon reader and Nokia 6131 NFC. Could you please help me out?

Thank you

[geri-m]

Hi,

the Samsung x700n is a prototype phone, that (as far as I know) can not be bought "somewhere". You could turn to NXP in order to get such a phone. Although the phone is already 2 years old and thus Nokia 6131 is more appropriated.

I actually epxerience the same: the problem with the p2p connection between the Nokia and an external p2p device. (eg. also WDI SD-Cards). Looks like there is some problem with the implementation in the proctoll. But I didn't investigate to much time on that.

cheers, geri-m

[fkooman]

Hi,

the Samsung x700n is a prototype phone, that (as far as I know) can not be bought "somewhere". You could turn to NXP in order to get such a phone. Although the phone is already 2 years old and thus Nokia 6131 is more appropriated.

I actually epxerience the same: the problem with the p2p connection between the Nokia and an external p2p device. (eg. also WDI SD-Cards). Looks like there is some problem with the implementation in the proctoll. But I didn't investigate to much time on that.

cheers, geri-m

I'm running into this problem with the Nokia 6131 NFC and a ACS ACR122 reader (NXP PN532 chip). I'm trying to write a NFCIP library in Java (see http://nfcip-java.googlecode.com) which works perfectly between two ACS readers but fails after some random amount of time with the phone. It seems like a bug in the Nokia phone as also repeatedly using send() / receive() between two phones within the "same" connection gives problems...

My tests consist of sending some byte arrays of data back and forth between phone and terminal (or two phones) which fails after some time. Sometimes it succeeds though, it's really strange!

Was P2P support improved/fixed with the new Nokia NFC phone (6212 classic)? Is there a firmware update available for the 6131 NFC?

[RicardoPortela]

Regarding Arygon's SDK, in terms of NFC-IP, it is non-existent...
In terms of Mifare, the reader implements a high level ASCII protocol that helps performing tasks related to Mifare cards. The documentation for this protocol is available on the SDK. The SDK includes a tool for Mifare card reading and writing.

Another issue, is that the documentation for NXP's PN-531 chip that is used in Arygon's reader, is in the SDK but password protected, and you need to sign a NDA with Arygon and NXP to get the password. Signing the NDA with Arygon was fast, but with NXP... oh well...

After I got the documentation, I was able to create a working prototype that allows communication between a Nokia 6131NFC and the Arygon reader using NFC-IP1.
My library was built using Visual Studio 2008 in C#, and uses a serial port to "talk" to the reader.

I am not experiencing any problems.

I did note that while sending large amounts of data, the phone fails to send/Receive all the data. However, the information that is transferred is correct (despite being incomplete).

I solved this issue with a simple protocol that takes advantage of the fact that in NFC-IP1 data transfer occurs in send/receive pairs, to send information about the amount of information that arrived the destination. The source then uses this information to re-send part of the previous message, if needed.

However, because while tranferring large amounts of information the user can take the phone far from the reader, you will always need some kind of error control mechanism for handling this special cases, so this was a normal requirement, even before I noticed the problems I mentioned.

I can provide more details about this, if needed.

[RicardoPortela]

To support my previous statements about the amount of information that isn't always what it should, here goes the logs of a transfer using my library and a 6131NFC phone.

The numbers you see here, are the result of a relatively large transfer (189140 bytes) from the reader to the phone that gets split into small buffers. This numbers represent the size of the data buffers that the phone received (result of a call to receive()). I am sending buffers of 252 bytes each (you can check NFC-IP1 spec and PN-531 Manual for the reason of this).

121, 235, 121, 110, 121, 132, 211, 119, 126, 120, 114, 122, 121, 117, 125, 119, 125, 121, 121, 120, 121, 119, 118, 116, 128, 125, 123, 121, 120, 128, 127, 119, 116, 116, 118, 129, 122, 119, 122, 128, 124, 122, 123, 124, 117, 130, 125, 129, 124, 124, 124, 117, 118, 122, 117, 126, 116, 118, 135, 121, 125, 122, 116, 117, 123, 120, 127, 123, 127, 124, 127, 120, 119, 108, 123, 113, 127, 119, 129, 130, 121, 122, 120, 116, 121, 122, 127, 124, 114, 129, 122, 124, 123, 119, 130, 119, 116, 127, 121, 115, 120, 122, 127, 120, 124, 119, 118, 136, 121, 122, 114, 116, 122, 120, 133, 122, 122, 119, 125, 123, 123, 120, 120, 125, 122, 117, 129, 124, 123, 122, 114, 120, 122, 130, 127, 116, 121, 117, 109, 121, 127, 129, 117, 123, 122, 130, 123, 119, 107, 122, 126, 133, 129, 122, 126, 124, 123, 121, 117, 114, 121, 125, 121, 117, 107, 119, 120, 129, 111, 111, 121, 120, 115, 127, 118, 123, 123, 116, 123, 131, 114, 117, 115, 122, 120, 128, 123, 117, 117, 114, 123, 131, 125, 125, 118, 123, 124, 121, 124, 127, 124, 129, 127, 130, 122, 130, 120, 129, 116, 124, 123, 114, 118, 127, 120, 130, 124, 129, 121, 125, 125, 118, 121, 130, 125, 130, 120, 126, 237, 145, 117, 115, 115, 121, 127, 126, 115, 218, 131, 119, 108, 127, 121, 116, 121, 124, 196, 121, 127, 119, 114, 117, 122, 116, 125, 203, 122, 133, 119, 118, 115, 127, 123, 117, 193, 120, 127, 128, 125, 117, 135, 159, 122, 120, 134, 128, 123, 120, 121, 122, 120, 133, 124, 121, 124, 120, 131, 118, 129, 121, 124, 123, 128, 114, 122, 126, 125, 123, 117, 120, 120, 127, 125, 109, 130, 124, 123, 128, 117, 122, 125, 124, 118, 124, 122, 129, 121, 125, 167, 122, 127, 113, 126, 123, 121, 123, 112, 122, 125, 125, 124, 110, 116, 134, 123, 120, 121, 132, 129, 128, 118, 122, 129, 120, 125, 113, 125, 123, 129, 123, 127, 115, 120, 136, 125, 117, 121, 125, 124, 122, 129, 118, 115, 118, 124, 118, 150, 195, 153, 116, 122, 126, 123, 124, 146, 121, 124, 121, 115, 120, 119, 158, 125, 124, 126, 126, 118, 123, 123, 131, 121, 117, 116, 118, 128, 121, 121, 119, 125, 131, 130, 112, 117, 109, 119, 119, 124, 123, 122, 125, 121, 125, 118, 109, 133, 132, 126, 118, 111, 122, 122, 125, 126, 121, 127, 122, 123, 120, 124, 121, 121, 128, 131, 113, 122, 120, 130, 126, 121, 128, 123, 117, 124, 119, 120, 117, 134, 125, 118, 126, 118, 121, 123, 118, 144, 131, 126, 130, 124, 119, 123, 122, 132, 162, 119, 127, 121, 118, 126, 127, 127, 131, 128, 136, 112, 126, 122, 119, 126, 124, 122, 129, 118, 127, 122, 122, 125, 118, 129, 122, 116, 132, 118, 132, 124, 120, 124, 118, 127, 124, 127, 125, 85, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 252, 155

As you can see, even though I always tried to send 252 bytes, sometimes the phone did not get all the information. In this cases, I re-send the information that is missing.

I cannot justify this. I just live with it

[fkooman]

However, because while tranferring large amounts of information the user can take the phone far from the reader, you will always need some kind of error control mechanism for handling this special cases, so this was a normal requirement, even before I noticed the problems I mentioned.

I can provide more details about this, if needed.

Yes, but this will be a problem as the target is lost then (or target released by initiator) so you would have to re-establish the connection I guess by using InJumpForDEP command at the initiator side and on the phone set it to target mode again. Is that the way to go?

It's strange that it sometimes magically works without seemingly changing anything. It seems to be related to some kind of timing issues on the phone. One thing I found out so far is that the send/receive methods don't seem to be blocking (when using the PN53x meta chaining). I now wrote a custom wrapper that just sends block of 250 bytes each time but that also doesn't help.

Added problem is that the emulator in the Nokia SDK (the new one for the Nokia 6212 classic) doesn't seem to work (it crashes) when running P2P apps. I used that one to see if that would work without problems.

[RicardoPortela]

Exactly.
I am handling target lost in the Nokia 6131 NFC and a similar class of exception in my C# library. I then try to reconnect and proceed sending the data from the last acknowledged packet.

I never used the emulators for this task because the Arygon reader was not supported by the 6131NFC SDK.

[RicardoPortela]

I got some questions on my email regarding the Arygon SDK, and I realized that maybe I wasn't clear enough. I think I can use this topic to clear things up. Maybe this is usefull to someone who had the same questions.

The questions were (adapted):
"(...)
1-I read in one of your posts about an Arygon SDK for reading and writing mifare commands.
2-If you can share the link to that SDK it would greatly help.
3-Is there any other tool that needs to be installed.
4-If a detailed procedure to implement (...) applications on the phone using the Arygon plug and play module is given it will help greatly."

Answers:

1-I said that "The SDK includes a tool for Mifare card reading and writing." This is different from an SDK for reading and writing commands. This tool allows reading and writing of Mifare cards, and shows a terminal-like window that displays the commands that are being sent to the reader via Serial Port (COM). This tool doesn't have any support for NFC-IP1 and I see it as a testing tool that one can use during development, but no more than that.

2-I could share the link but even though I think that this information is not covered by the NDA, Arygon should have sent you a login for their site, where you can download this information. This login is sent after you buy the reader. If you don't have a login, please contact Arygon. Their team answers to emails quickly.

3-You need to install the USB-Serial Driver, that is also included in the SDK.

4-The way I'm doing it is not trivial and is way too complex to show it here, but the main concept is quite simple:
For Mifare commands (and because there is an ASCII high level protocol), you just write strings to the serial port, the reader does the operation requested and replies with status information or other kinds of info (such as Firmware version or sector data, for example). Information about these commands is on the Application Note that is part of the SDK.


Best regards,
Ricardo Portela

[jlanza]

Hi,


I have been able to send data from Initiator to Target using the meta-chaining capability of the PN53x (bit 6). However I'm not able to do so from the Target to the initiator.

As a target initially I'm using a Nokia 6131 using the implemented SDK functions. The reception of long block from the initator seems to work well. However when sending for instance 400 bytes from the target to initiator, I'm able to get the first chunk (D5 41 40 XXX) but I don't know what I have to send at the initator to get the rest.

Any help??

TA

[fkooman]

You can use the inDataExchange command again, without any data
d4 40 01 (assuming 01 is the target number)

See:
http://code.google.com/p/nfcip-java/ for a Java library implementing this, and see:
http://code.google.com/p/nfcip-java/...R122_PN53x.txt for the PN53x commands.

[jlanza]

You can use the inDataExchange command again, without any data
d4 40 01 (assuming 01 is the target number)

See:
http://code.google.com/p/nfcip-java/ for a Java library implementing this, and see:
http://code.google.com/p/nfcip-java/...R122_PN53x.txt for the PN53x commands.

Hi,

The nfcip-java library uses a custom chaining format, if I haven't understood wrongly. I wanna use the one implemented in the PN53x.

I have done what you suggest by sending again a null InDataExchange command from the initiator, but it seems it is not working, or at least I get an error from the Windows library (using it in C++). Anyway I will test it again.

Just sumarizing, you mean that the answer to get more data when chunks are sent by the Target using the PN53x chaining is using the standard InDataExchange. Am I right?

TA

[fkooman]

Hi,

The nfcip-java library uses a custom chaining format, if I haven't understood wrongly. I wanna use the one implemented in the PN53x.

I started out with that, but there were serious problems with the phone and my ACS ACR122 in that the connection is very unreliable and the phone's send/receive methods don't seem to be blocking... Also the ACS ACR122 seems to break when using PN53x chaining when the last block is of size between 11 and 23 bytes. Also wanted to create a connection that resumes after connection tear which seems easier, especially from the point of view of the phone when there is just one "block" you may have to resend.

But I guess PN53x would be a preferable solution if you get that to work...

I have done what you suggest by sending again a null InDataExchange command from the initiator, but it seems it is not working, or at least I get an error from the Windows library (using it in C++). Anyway I will test it again.

what is the error you get? It is from the reader, or from the PN53x?

Just sumarizing, you mean that the answer to get more data when chunks are sent by the Target using the PN53x chaining is using the standard InDataExchange. Am I right?

TA

Yes, exactly. As long as the status byte of the response to InDataExchange has bit 6 set you can send an empty InDataExchange to request more data from the target...