nfcpy

Does Sony RCS380 support to sense TTA in 212 or 424 kbps?

Asked by fengzhiquan

In nfc/dev/rcs380.py, the function "_sense_tta" sets the rf type to the fixed "106A". Seeing the codes below:

....
    def _sense_tta(self):
        log.debug("polling for NFC-A technology")
        self.chipset.switch_rf("off")

        self.chipset.in_set_rf("106A")
....

And also I find that setting the value to "212A" or "424A" results to a PARAMETER_ERROR.

Does this mean Sony RCS380 does not support typeA in 212kbps or 424kbps, or something is wrong with the parameters to set "212A" or "424A" to the device?

Question information

Language:
English Edit question
Status:
Solved
For:
nfcpy Edit question
Assignee:
No assignee Edit question
Solved by:
Stephen Tiedemann
Solved:
Last query:
Last reply:
Revision history for this message
Stephen Tiedemann (stephen-tiedemann) said : 		#1

The RC-S380 should support 212A and 424A but the parameter settings are probably (better: certainly) wrong. For 106A I originally sniffed the settings from USB communication between reader and Sony's Windows driver. For other than 106A this was not possible due to missing targets (and no real demand). The PARAMETER_ERROR is actually forced by the settings tuple for 212A and 424A (first value zero is invalid). A setting of "212A": (4, 4, 15, 4) in in_set_rf() will make the error go away but it will still yield invalid communication (just checked with an RF sniffer). I may be able to get it working as part of the current device driver modifications that will once become part of nfcpy v0.10 but it's no yet there and I can not promise.

Revision history for this message
fengzhiquan (fengzhiquan) said : 		#2

Hi Stephen,

To find the correct setting of "212A", may I try the whole possibilities of the setting tuple? It's 15*15*15*15 possibilities.

Revision history for this message
Stephen Tiedemann (stephen-tiedemann) said : 		#3

The four values in the tuple are RF settings table index and communication type for send and receive (index-send, type-send, index-recv, type-recv). I'm quite sure about the communication type values, 3/4/5 for 106/212/424A. I'm not sure about the table index values; the range is 1-15 and it might be worth to toggle them if you have something to test against.

Revision history for this message
fengzhiquan (fengzhiquan) said : 		#4

Hi Stephen

I tried all the possible index values and checked the RF log. It just didn't work.

Maybe I need an USB sniffer and use the same way you did for 106A.

Revision history for this message
Stephen Tiedemann (stephen-tiedemann) said : 		#5

Just to make sure: That would be about running the original Sony driver on a Windows machine and some application that makes the driver poll in 212A or 424A, then sniff the USB traffic to find what settings are used. By default, the driver will most likely just poll for 106A because that makes all cards (that I know of) and P2P targets respond.

Btw, I used a virtual Windows 8 machine on Ubuntu host to sniff the USB traffic.

Revision history for this message
Best Stephen Tiedemann (stephen-tiedemann) said : 		#6

After a bit more investigation I've come to the conclusion that higher speed 212A or 424A can only be achieved with a parameter change request (ISO 14443-4 PPS command) after initial discovery at 106 kbps. This needs to be part of the (Type 4) tag activation logic after inspecting the RATS response to check if higher bitrates are supported.

Revision history for this message
fengzhiquan (fengzhiquan) said : 		#7

Thanks Stephen Tiedemann, that solved my question.