Feature: Amiibo NFC reading support

[Poohl]

This mainly implements enough of the NFC functionality to simulate amiibos for reading. The implementations core is in mcu.py, but this is not some rewrite of the old copyrighted code.

There are still some hacks in detecting and storing the tag but it seems stable om my end.

This is currently only tested using Splatoon2 and Pro-Controller on my laptop (Acer spin 5) using PopOS based on Ubuntu 20.04 running bluez 5.53-0ubuntu3

my command to test this:

python3 run_controller_cli.py -d hci0 -r --nfc PRO_CONTROLLER

And it successfully transmits the amiibos data and wants me to register a user.

TODO:

• more MCU-functionallity
• NFC-Write
• validate right Joycon working
• validate registered Amiibo working

Other changes in the merge:

• removed this reader injection into transport
• added "click" command
• partially fixed the input-speed-change improving latency
• some documentation on how it works

[mart1nro]

Thanks, I'm going to test this as soon as I have the time.

Btw, besides the first google search result, MCU stands for microcontroller unit (https://en.wikipedia.org/wiki/Microcontroller) :)

[Poohl]

Sorry for the delay, but thanks I'll change the name.

I checked BOTW myself and since this for some reason doesn't require you to register a owner it seems to just work.

I also noticed that #90 also includes a fix for the flow control problem that seems to work better than mine, I can try to integrate that one or would you want to?

[DarkPro1337]

Not worked on my Switch Lite, putted in nfc command a regular amiibo for BoTW and nothing happens on the amiibo adding to mii screen, and these two lines spam in the terminal.
JoyControl was hosted on the Raspberry Pi 4B with latest Raspbian OS.

[Poohl]

@DarkPro1337 Two things: First I assume you are on the 'register owner and name' screen in the settings, that sadly isn't working yet but you don't even need it, as botw works with unregistered amiibos.

Second the 'not implemented length' means just that, the nfc tag you passed is not of the expected size. This might be an issue in the code (I'll check, I have a few commits only local but they should be unrelated), but please check that the file you use is exactly 540 bytes, anything else is not an amiibo. If you have another size you might have the decrypted version exported by tagmo or some format with the image embedded or UID stripped. This implementation needs the raw binary image that would be stored on the NFC tag.

The 'set NFC tag data' is just telling you it picked up on the tag you set.

[DarkPro1337]

@Poohl oh, thanks, I'll try to check these amiibo dumps later. Maybe they are just corrupted due the archivation.

But just sending amiibos on the botw screen also does nothing (amiibos was enabled).

[Poohl]

I assume you have the Amiibo rune active. Does the terminal view that the Switch requested 0x31 Input mode? The Expected sequence of events is
0. open the rune

1. switch requests 0x31 mode
2. switch configures NFC (0x21 command)
3. switch starts and stopps polling a few times
4. switch requests the tag be read
5. tag is send back

[thxomas]

@Poohl thanks for your work.
I tried to use an amiibo in Botw and got the same length errors. I hacked a little further and noticed that the zelda game sends a 572 bytes payload instead of 540.
I just changed the code to let it continue and the game worked as expected ! I dumped the data payload ( botw_nfc_data.bin.log )
Keep up !

[Poohl]

@thxomas are you on the amiibo_edits branch? Did you use multiple amiibos in a single run of joycontrol? And regardless, what was your fix?

I know of a few length issues on the amiibo_writing branch, but i thought the other one was fixed...

[thxomas]

Oh, I notice now, I used your fork, not a branch from this project. (I'm not really confident with git yet)
The fix was quick and dirty : I just commented out the "return" instruction after length check in mcu.py
And yes, multiple amiibos in the same session worked the same way.

I will try again with the amiibo_writing branch and report.

EDIT: Yes, I was previously on amiibo_edits branch. and I'm having more lowlevel issues with the amiibo_writing branch ATM (connection from switch doesn't work, I have to use the reconnect option, and as soon as I leave the Grip screen I get No data received/Connection Lost). I'd be happy to help in DM if you want/need.

[Poohl]

The amiibo_edits branch i would consider more stable than amiibo_writing, the second still has a bunch of dirty hacks that make the register owner work, but nohing else yet. (Both of them are only in my fork, this is the thread to merge them into mart1nro's project)

Regarding low level issues: look at the reset and restart Bluetooth scrips in amiibo_writing/scrips most notably the folder in /var/<bluetooth_or_so_not_sure> mentioned likes to corrupt.

Ps: are there dms on GitHub or are you talking of another platform? Help is always appreciated.

[choss]

@Poohl thanks for your work.
I tried to use an amiibo in Botw and got the same length errors. I hacked a little further and noticed that the zelda game sends a 572 bytes payload instead of 540.
I just changed the code to let it continue and the game worked as expected ! I dumped the data payload ( botw_nfc_data.bin.log )
Keep up !

The Mismatch in payload size is easily explainable:

• An amiibo is 540 bytes long as "user" payload
• The other bytes are additional non writable information from factory (signature of the manufactorer)
• BotW sends the whole tag, the last 32 byte can be safely ignored

https://gbatemp.net/threads/making-amiibo-ntag215s.413050/page-37
https://www.nxp.com/docs/en/data-sheet/NTAG213_215_216.pdf (section 8.9)

[Poohl]

@choss So what you're saying is there is additional data at the NFC-tags end?
I couldn't find it (my nfc-dump app produces 540 bytes when dumping a Link-Archer amiibo) or anywhere that it's used. I can however assure you that BOTW does not send the entire tag (or at least not care if you don't), since the line responsible cuts off at 540:

self.nfc_tag_data[245:540]

I'll update the NFC-tag loader to accept these longer tags. Are they always 572 bytes long?

[choss]

Yes as far as I can tell from the spec it is always 572 bytes long. So it should be fine :) The last bytes are anyway only the vendor signature and "static"

[Poohl]

I will create a new Pull request with updated info for everything. Will edit the comment to contain a link.
It's Pull request #110 .