ST25R3916 / Discovery Board +GUI and supported bit rates for NFCA

[ec.1]

Hi all,

I have a few questions regard the topic above.

1. Is it an NFCA ISO standard that the PICCs will use BPSK (instead of OOK) to transmit data to the PCD for rates higher than 106?
2. Does the ST25R3916 chipset and/or DISCO board supports speeds up to 848 officially for NFCA?
3. Is this a the correct way to make a bitrate change? I am setting up the speed change is through the 14443A tab. After a successful RATS, I issue a PPS to the PICC to request it switch the DRI/DSI (the GUI implementation has a bug, it swaps the values when calling into the firmware) and then go to the Debug tab/ModeandSpeed and select NFCA and change the TX/RX speed reader bitrates locally.
4. I also looked into the ST25R3916 datasheet to see about demodulating BPSK incoming RX (>106). Can I assume when I set the RX speed higher than 106 the GUI will send appropriate commands to switch the demodulation type from OOK to BPSK?
5. Are there any analog front end settings that we can tweak via the GUI to try to make comms work better at the higher bitrates?

Thanks in advance.

[Ulysses HERNIOSUS]

Hi,

ad 1) yes.

ad 2) yes, RTM

ad 3) yes. I tried setting asymmetric 212/424 and set it in debug tab the same, and it worked. Can you please elaborate with which exact versions and which exact sequence you observe an issue?

ad 4) yes, it is even the chip which automatically switches to BPSK when changing the bitrate register - depending on mode.

ad 5) the RFAL is coming with Analog configs (compare to Analog Config tab) which should make it work well for HBR. Are you experiencing here issues? Which ones?

Regards, Ulysses

[ec.1]

Thanks for the quick reply.

2) Will go though the datasheet as suggested and come back if I have more questions. I did see the official support up to 848 in the datasheet.

3) My MB firmware version is 1.1.0. This was observed at our PICC end when the PPS frame is sent over. I traced this into the GUI source code and cross checked with the actual call in dispatcher.c. What I found out the GUI sends this in

void Iso14443aTab::on_pps_pb_clicked()
{
	ST25R391xComError err;
	QByteArray answer;
 
	err = this->com->iso14443aPPS(this->cid_cb->currentText().toInt(),
						this->dr_cb->currentText().toInt(),
						this->ds_cb->currentText().toInt(),
						change_send_and_receive_data_rate_cb->isChecked(),
						answer);
 
	// send answer to main window
	emit mainWindowDisplayMessage(QString("PPS[%1]->").arg(com->decodeFWError(err)) + answer.toHex());
	if ( ST25R391xComError::NoError == err )
	{
	}
	else
	{
	}
	pps_dc_gb ->setEnabled(false); // disable after first time
}

But the dispatcher.c expects this

case ISODEP_CMD_PPS:
 OutSize = sizeof(rfalIsoDepPpsRes);
 if ( (BuffInSize == 3) && ( OutSizeMax == OutSize) )
 {
 err = rfalIsoDepPPS ( buf[0] /* DID*/, (rfalBitRate) buf[1] /*DSI*/, (rfalBitRate) buf[2] /* DRI */, (rfalIsoDepPpsRes *) (txData));
 }
 break;

Note that the DSI/DRI parameters have been swapped when calling into the firmware. As mentioned then I changed the reader bitrate to match that in debug/modeandspeed.

4) Noted, I traced the bit settings through the Register Map via the Debug tab and noted that the demodulators are changed when bitrate is changed.

5) At the moment we are unable to transmit higher than 212 to our PICC. The reader is able to receive at all speeds (106,212,424,848) so I'm assuming the demodulation config is working ok. We are also trying to tweak our antenna and coil design on the PICC end to see if that is the limiting factor.

What I noticed is that the ST25R3916 switches from OOK to AM (with default modulation depth of 12%) for bitrates higher than 106. Some of the quick tweaks I have done on the reader transmit parameter side but did not improve things. I did this through the Register Map.

a. I manually switched it to OOK (Mode definition register, 0x03H) , while keeping other default settings.

b. Increased modulation depth (TX driver register, 0x28H) -- AM modulation mode.

c. Increased modulation pulse width (ISO14443A and NFC 106kb/s settings register, 0x05H) , while keeping other default settings.

Thank you.

[Ulysses HERNIOSUS]

Hi,

ad 3)

DSI/DRI are not naturally defined for ISO14443A, it is from PICC perspective whereas ST25R3916-DISCO GUI has a PCD/3916 perspective historically. The ISO14443A tab uses a different function: iso14443aPPS which does then swap DSI and DRI to match the spec.

The mentioned ISODEP_CMD_PPS is a different path for the same thing anyhow.

ad 5)

Is the PICC communication working with the stock ST25R3916-DISCO demo? I verified that it is indeed working properly for 424 PCD->PICC / 848 PICC->PCD communication.

Regards, Ulysses

[ec.1]

3) Agreed, the convention of which is the sender / receiver can differ.

5) As a summary, on the stock ST25R3916-DISCO demo, PCD (disco board) -> PICC (our custom board)-- only up to 212k achievable for now. PICC -> PCD -- all rates are ok. All reader rates are changed through debug/ModeandSpeed.

[Ulysses HERNIOSUS]

Hi,

ad 5)

For me this means that the issue is on your PICC side. I tested various combinations on ST25R3916-DISCO vs. a Mifare DESFIRE card: ISO14443A tab up to PPS and then on Debug tab (directly going to TxRxNBytes as the PPS button already changes the bitrate).

Regards, Ulysses

[ec.1]

5) Noted, just wanted to get a confirm that the ST25R3916-DISCO board and its PCB has been validated for all TX/RX rates so that I know the limitation is not coming from the PCD side.

Just one thing to point out, I believe sending PPS in the ISO14443A GUI tab doesn't change the PCD (ST25R3916) bit rate it just broadcasts a PPS frame to the PICC on the rate change. I still need to manually set the PCD desired bitrate through Debug/ModeandSpeed.

Thanks.