TRF7960: Data framing errors

Ian Pratt

Intellectual 880 points

Part Number: TRF7960

I have an ISO15693 reader built with the TI 7960 chip.

The system is reading TI Tag-it HF RFID tags without much problem. As an example I can Inventory and get:

E007C1A254422623
E00700001B461036
E007C1A25442252C
E007C1A25442253C
E00700001B46103B

Here there is a collision in the bottom nibble "C" but all the tags in the field are read.

When I try this with NXP silicon (04), say

E00401001850013B
E004010015CBE53E
E004015020922C6E
E004010015CC2A07
E004010015CC29D7
E00401004618644F (Not read)

There are 2 collisions here. However the last tag is missing in the response.

When I try at low data rate (same 6 tags in the field) I get:

E00401001850013B (Not read)
E004010015CBE53E (Not read)
E004015020922C6E (Not read)
E004010015CC2A07
E004010015CC29D7
E00401004618644F (Not read)

What seems to be happening is that tags that have a higher order than when the collision occurred tend to go missing in the response. Here there is a collision "7" and tags with "B", "E" & "F" are missing. This is using the TI firmware for the anticollision. I note that "Byte Framing" error is raised *Register BIT2 when this problem occurs.

I suspect this is something to do with subtle differences in timings between the tags. Like I say TI silicon tends not to have this problem but their again it is a TI reader chip and it would be expected to interact with TI silicon. However, it is supposed to be an ISO15693 standard and I would also expect NXP silicon ISO15693 to read without problems.

The question is basically: Is there some way to ease the timing tolerances in order to use the framing capabilities of the 7960 but accommodate the supposedly standardised timing variability of the ISO15693 silicon on the market ? The problem for me is that other readers on the market can do this so I need to solve this problem.

Regards,

Ian

over 8 years ago

0 Ralph Jacobi over 8 years ago

TI__Guru*** 135355 points

Hello Ian,

Yes you ease the timings. I recall exactly what you are talking about. There is a difference in how long each tag takes to reply. The NXP tags can take longer, so the TRF79xx will think it is a no reply situation instead and skip over them.

If I am remembering right, the setting to change is the No Response Time setting which is Register 0x07. In the firmware which supports anticollision, we set this manually to 0x15 instead of allowing the TRF79xx to set it.

I am fairly certain that is the only change needed and then you should have no issue with the NXP tags.

0 Ian Pratt over 8 years ago in reply to Ralph Jacobi

Intellectual 880 points

Ralph,

Thanks for your reply. Setting RXNoResponseWaitTime to 0x15 with NXP silicon is certainly better but the problem still persists to some extent. It always follows a collision, if you have tags with distinct lower nibbles then these are read perfectly. If you have these 3 tags then they will be read:

E00401003D85561A
E004010015CC29FA
E004010046187BF4

Then putting this tag into the field E00401001850013B and it will not be seen in the Inventory. However if you put a tag with lower nibble less than A into the field then it will be seen. It is something to do with the collision and the recursive function call. If I mask off the recursive function call //Inventory(&NewMask[0],NewLenght) then of course I don't see the 2 tags that are in collision, I also don't see E00401001850013B. Is it something to do with the timing following the collision ? From the TI code it is done this way:

if (i_reg == 0xFF)

{

// We have a valid tag response - great

}

else if (i_reg == 0x02)

{

// We have a collision

PslotNo++;

*PslotNo = i;

}

else if (i_reg== 0x00)

{

// Timer interrupt to move to next slot

}

// Implement next slot transmission

It seems to me that the case when the timer interrupt occurs gives good slot timing but when you hit the case i_reg = 0x02 then the timing of your next slot

transmission is not precisely timed, it is at the mercy of when the MCU finishes the "else if (i_reg == 0x02) case.

Was there something else that needed to be changed ?

Regards,

Ian

0 Ian Pratt over 8 years ago in reply to Ralph Jacobi

Intellectual 880 points

Ralph,

I made progress, I think it works if you add a slight delay like this:

if (i_reg == 0xFF)
{

// We have a valid tag response - great

for (k = 0; k < 5000; k++)
asm("nop");

}
else if (i_reg == 0x02)
{

for (k = 0; k < 5000; k++)
asm("nop");

}
.......

This works for the high data rate, perhaps the delay is too long k < 5000, I will try to reduce it and get it faster but also reading, fundamentally the principle works. The claimed setting for low data rate is RxNoResponseWaitTime = 0x2F
This is problematic for low data rate NXP silicon. Is there a different value for low data rate ?

Regards,
Ian

0 Ralph Jacobi over 8 years ago in reply to Ian Pratt

TI__Guru*** 135355 points

Hello Ian,

I would imagine the Low Data rate has a different value. I've never had to deal with Low Data rate, no one ever uses it. So the settings I provided are for high data rate.

It looks like you are using really old anticollision code, I think there may be a bug in the routine. Are you using a TI EVM? I might have a newer project for it.

Also in general this is recommended firmware for the TRF7960A: http://www.ti.com/lit/zip/sloc297

It supports for the 70A and 60A, and you can enable the 60A firmware by going into the trf79xxa.h file and toggling the #define for TRF79xxA_VERSION to 60.

0 Ian Pratt over 8 years ago in reply to Ralph Jacobi

Intellectual 880 points

Ralph,

I have the TI 7960EVM.

Thanks for the firmware. I note that these are driver functions which I can update. Is there an updated ISO 15693 anticollision algorithm with a recursive call in firmware that draws upon these driver functions ?

Regards,

Ian

0 Ralph Jacobi over 8 years ago in reply to Ian Pratt

TI__Guru*** 135355 points

Hello Ian,

The latest version of the ISO15693 anticollision firmware is included in firmware I shared.

I thought I had an already working project for the TRF7960AEVM but it isn't working yet. I need to figure out whats wrong with it. I should be able to do that on Monday and then provide you that (It's something we plan to release formally in the future).

0 Ian Pratt over 8 years ago in reply to Ralph Jacobi

Intellectual 880 points

Ralph,

Yes, I found that function:

uint8_t ISO15693_runAnticollision(uint8_t ui8ReqFlags, uint8_t ui8MaskLength, uint8_t ui8Afi)

I'll update to the new firmware and see how it goes.

Regards,

Ian

0 Ralph Jacobi over 8 years ago in reply to Ian Pratt

TI__Guru*** 135355 points

Hello Ian,

Here is the project for the TRF7960AEVM: 7608.TRF7960AEVM_RFID_Reader_Demo.zip

To use this, you will need to convert the EVM to SPI mode which is done by moving the 0 ohm resistors between HDR_4 and HDR_5 to be between HDR_5 and HDR_6. You don't have to move the resistors for P4_5 and P4_3, but the others all must be moved.

0 Ian Pratt over 8 years ago in reply to Ralph Jacobi

Intellectual 880 points

Ralph,

Thanks, I'll download and take a look.

Regards,
Ian

0 Ian Pratt over 8 years ago in reply to Ralph Jacobi

Intellectual 880 points

Ralph,

Thanks for your help ironing out the difficulties here. I have a combination of settings including your RxNoResponseWaitTime = 0x15 setting that now work for my setup. It was important for us to be thorough with the testing and test all modes (1 out of 4, 1 out of 256, hi & lo data rates and different subcarrier settings. The timing spacings following collisions and successful tag reads was needed in order to interact with both TI & NXP ISO 15693 silicon.

Regards,
Ian

Other wireless

Other wireless technologies forum

TRF7960: Data framing errors