2020-04-16 12:30 AM
Hi all,
I have a few questions regard the topic above.
Thanks in advance.
Solved! Go to Solution.
2020-04-16 06:42 AM
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
2020-04-16 06:42 AM
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
2020-04-20 09:47 PM
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.
2020-04-22 07:47 AM
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
2020-04-22 09:12 PM
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.
2020-04-23 03:08 AM
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
2020-04-23 04:29 AM
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.