Frequently Asked Questions


Q & A

Q: What NFC reader can I use this Emulator with?

A: As of 2014, the most popular NFC reader devices happen to be Android phones with NFC interface, but the choice of reader is not limited to them.

Q: Why even bother making an emulator if Android might release the hidden API soon?

A: Even if Android releases the hidden API allowing MIFARE Ultralight tag emulation, full emulation will still not be possible because of two hardware restrictions of PN53x NFC interface chips found in most Android devices:
  1. UID size will be limited to 4 bytes, thus level 2 anticollision (0x95 command) will not be supported;
  2. First UID byte (UID0) will be hardwired to value 0x08, which is different from 0x04 used in standard tags.

Q: Does the Emulator come with extra software?

A: No, everything it needs in order to function is programmed into the microcontroller. It is up to the user or developer to use or make software for the reader (PCD) device. Normally, if someone has already used standard MIFARE Ultralight NFC tags, it is assumed that he/she already has all the reader software installed on the PCD device. Yes, now the user can implement own code directly on the Emulator using the provided SDK.

Q: How long do the batteries last?

A: Because of the automatic power-saving feature, the battery current consumption when no reader field is present is more than 1000 times smaller than when the field is present. Because of that, the battery life strongly depends on the frequency of use and duration of interaction with PCD. Typical capacity of AG8 batteries is 45 mAh, while the active current consumption of the reader with full batteries is around 6 mA, resulting in at least 8 hours of continuous work in reader field. However, batteries may always run out of power unexpectedly and this can lead to firmware corruption. If this has occured to you, you most likely need to reflash Emutag in addition to getting new batteries. If the reader field is never applied, it would *theoretically* take more than 20 years to drain full batteries.

Q: Is there a casing for the PCB?

A: The project is very new and there has not been much development in terms of mechanical design. However, depending on project success, there is a possibility of making a casing. The PCB dimensions have been chosen to leave 1 mm on each side for the casing in order to fit into length and width of a CR-80 card.

Q: Why can't my reader (PCD) read 2 or more PICC devices, even though all of them support anticollision?

A: All passive tags and the Emulator consume power from the electromagnetic field generated by the reader. The Emulator is designed to consume almost exactly the same amount of power from the antenna as a standard MIFARE Ultralight NFC tag. Increasing the number of tags reduces the field strength, which in turn renders one or more tags unreadable due to lack of power.

Q: Is it possible to design a completely passive version of the Emulator with no batteries?

A: Yes and no. Two key factors that determine the answer to this question are (1) the choice of microcontroller and (2) the reader delay timeout from PCD to PICC. It is known for a fact that in order to satisfy the standard write delay of 3.83 ms on a passive tag, it needs to use a hardware architecture allowing simultaneous write of 32 bits (4 bytes) of EEPROM. The answer would be positive if anyone found either a 32-bit microcontroller or an FPGA with such capability that also satisfies power consumption constraints. If the write delay is not critical, even a 8-bit ATMEGA family microcontroller can be used. Tests have shown that 9 ms delay works on most Android phones with NFC, and such a delay can be obtained by writing a block of FLASH memory of ATMEGA in bootloader mode.

Q: Does the Emulator support NDEF?

A: Yes. NDEF is a purely software concept, it's a data structure similar to a file system on a hard disk or Flash memory device. However, NDEF format implies having non-zero data in page 3 (OTP), meaning that standard tags can be formatted to NDEF only once. The Emulator can be formatted to NDEF multiple times using its distinctive lock/unlock switch.

Q: Does the Emulator support the software UID change command used in UID-changeable MIFARE Ultralight clones from China?

A: No. The idea of not supporting the backdoor command "HALT, 0x40, 0x43" is to prevent a reader from identifying the Emulator as a Chinese clone. Manually setting the hardware switch to Unlocked position is the only way to make the UID writable by standard WRITE or COMPATIBILITY_WRITE commands.

Q: What chip is the Emulator based on?

A: ATtiny4313. Yes, the software has been written and optimized in a way to make it possible to use such a basic microcontroller.

Q: Can I have the source code of the microcontroller firmware?

A: This is a commercial project for now, so the source code is neither disclosed, nor the firmware can be read back from the microcontroller. UPDATE: Some source code has been made available. Please visit the SDK page for more information.

Q: Can I apply external power to the board?

A: Yes, a voltage between 3.3V and 5.5V can be applied to the programming slot in a way shown in the picture below.

Programming Slot

WARNING! The power terminals on the programming slot connect directly in parallel with the batteries. The batteries must be removed before applying external power. Powering the Emulator with batteries inserted will cause a high current flow through the batteries, which can make them explode or catch fire.

Q: What's the pinout of the ICSP connector?

A: SCK MISO MOSI VCC RST (BLANK) GND. Please refer to Flashing firmware section for complete instructions.



Near Field Communication - technology that uses electromagnetic field to transfer information in a contactless way.


Proximity Coupling Device - reader device that supplies electromagnetic field to its antenna and uses it to communicate.


Proximity Integrated Circuit Card - tag device that captures electromagnetic field and uses it to power itself and to communicate.


Unique IDentification number - sequence of bytes which is fixed and unique in original NFC tags.


Block Check Character - redundant byte in UID area used for error detection while reading UID.


One-Time Programmable - bits that can be changed only in one direction (0 to 1) in original NFC tags.


REQuest protocol A command - repeatedly issued by PCD to discover PICC devices.


Answer To reQuest protocol A - values returned from PICC to PCD after receiving a REQA command. Fixed to 0x00 0x44 for MIFARE Ultralight.


Select AcKnowledge - value returned from PICC to PCD after completion of the anticollision procedure. Fixed to 0x00 for MIFARE Ultralight.


ACKnowledge - character returned from PICC to PCD usually upon successful write. Unlike other responses, this value is 4 bits long and equals 0xA.


Negative AcKnowledge - character returned from PICC to PCD usually upon a failed write due to permission restrictions set by lock bits. Unlike other responses, this value is 4 bits long and equals 0x0.


Cyclic Redundancy Check - mathematical algorithm used for error detection during data transfer, which appends 2 extra bytes at the end of a data message.


NFC Data Exchange Format - format defined on NFC Forum to standartize data exchange in form of objects (text string, URL, WiFi connection credentials, application launch, etc.) rather than simply binary data.


Application Protocol Data Unit - logical request or response sequence between PCD and PICC communicating according to part 4 of ISO 14443 standard. MIFARE Ultralight technology is not APDU-based. APDU are used with processor-based smartcards, contactless and with contacts.


Printed Circuit Board - material holding electronic components connected in a designed way.