Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for higher data rates #45

Open
dev-zzo opened this issue Oct 19, 2016 · 2 comments
Open

Support for higher data rates #45

dev-zzo opened this issue Oct 19, 2016 · 2 comments
Assignees

Comments

@dev-zzo
Copy link
Contributor

dev-zzo commented Oct 19, 2016

Currently, only 106k is supported. Unfortunately, to properly emulate newer cards it would be required to support 212k and 424k at the very least; this would allow for proper emulation of DESFire (the first model). Until we have that, we would either have a different ATS stating we only support 106k OR the ATS would lie a bit in order to mimic the original card and risk the reader setting comm rate higher than 106k.

How much work would it take to implement the higher data rates? From my very limited experience with codecs in Chameleon, I would writing a new one for each speed setting?

@geo-rg geo-rg self-assigned this Oct 24, 2016
@geo-rg
Copy link
Collaborator

geo-rg commented Oct 24, 2016

First of all: I would suggest to get the DESFire emulation (and other things) stable first and then think about adding new features more specifically. But we have this on our agenda.

Technically this brings us to a dilemma: We could either implement a new codec, but then we would have the problem that we would have to alter the codec functions during a configuration which is used. This could cause big problems.
Or: we could change the existing codec so we can alter the data rate during emulation. But this also could cause big problems.

To me, the latter option makes more sense, since the codec is basically the same but only the data rate is higher.

@skuep
Copy link
Collaborator

skuep commented Oct 28, 2016

Actually I am rather skeptical whether the processing power of the ATxmega can handle data rates higher than 106kbit/s. From what I remember developing the ISO14443A codec, the way its implemented is already using a lot of CPU grunt to do what it is supposed to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants