Response wait time t1 gets too high, when reading more than 8 blocks on emulated transponder

[mschmitt-pf]

Normally the response wait time t1 (ISO15693-3 VICC waiting time before transmitting its response after reception of an EOF from the VCD) shall be in range of 318,6µs to 323,3µs .

But response wait time t1 (reader TX EOF to transponder TX SOF) increases significant, when reading multiple blocks with more than 8 blocks.

Parameter to reproduce:

• emulating EM4233 transponder with uploaded tag data
• use external ISO15693 reader
• read multiple blocks (e.g. 16 blocks) of data in addressed mode
• observe response wait time t1 with scope

Note: The markers in scope plots below are not on correct position of EOF and SOF, but for relative observation I have put the markers on last reader TX pulse and first transponder modulation. The deltaT is the relevant measure.

The response wait time t1 is correct, when reading a low block count, e.g. 4 blocks. (Reader data TX = .22.23.FF.FF.AA.AA.EE.24.16.E0.00.03 + CRC)

Requesting 16 blocks the time t1 increases by additional ~204µs which is out of allowed window for t1 (Reader data TX = .22.23.FF.FF.AA.AA.EE.24.16.E0.00.0F + CRC)

Many thanks in advance for your support.

[ceres-c]

Hi, being me and @MrMoDDoM the authors of that application, I'd like to say we were aware of the issue. We had not done proper tests, but were pretty sure it was a timing issue, now your comment confirms our speculations.

It was first noticed somewhere in the comments on #182 and I tried to compensate optimizing code in be729b7. It was not resolutive, but improved the situation: before it was even worse. It'd be interesting to investigate on which part of the code is slowing down data encoding and optimize it, maybe even resorting to hand written assembly. It could as well be a fixed delay due to FRAM read times. In that case I don't know whether it could be fixed.

PS I'd like to point out this was an issue only with my ST reader, not with readers in the field

[david-oswald]

This should be resolved by PR #274 (once merged), correct @ceres-c ?

[ceres-c]

Sadly not solved. We have been analyzing the situation and found out that both FRAM and CRC calculation are slow. No investigation went on about possible ways to improve the former, as we believed we were hitting FRAM limits (not sure about that, tough). On the other side, CRC calculation is ridiculously slow. Here you can see a capture I've just taken with my scope

• first pulse: time it took to read the data - 25,3 us
• second pulse: CRC calculation - 170 us

I'm pretty sure this delay is unjustified, so the CRC function must be improved. We have not taken the time to do so.

274 solves other minor issues with the codec and remove useless fram reads in applications, but as stated above, this issue won't be solved like that. This is a challenge for experienced AVR asm devs

Now that I think about it, a quick solution/hack would be to move CRC calculation inside the codec. It might help since the application would return earlier and modulation would start while CRC calculation is still ongoing, but it should (?) terminate before modulation is done

--Update-- Well, this late night epiphany was too tempting for me to go to sleep without testing it and, surprisingly, it works. It looks like we have found our solution to this issue. Tomorrow I'll add this fix to the other PR :)

[iceman1001]

@ceres-c , make PR to the RRG repo as well? you moved the crc calcs. interesting solution.

[david-oswald]

nice, well done!