Info on WaveShare Passive NFC-Powered E-Paper Modules

  • infoFull Post Details
    info_outlineClick for Full Post Details
    Date Posted:
    May. 20, 2021
    Last Updated:
    May. 20, 2021
  • classTags
    classClick for Tags

This post comprises my assorted notes related to WaveShare Passive NFC-Powered E-Paper Displays. I recently bought a 2.9″ module and ended up learning a good deal about it while building an Android app to interface with it.

Resources

Show Resources

What is Powering the Waveshare NFC EPaper Module?

Hard to tell – probably depends on model.

It looks like many use the ST25* (ST Microelectronics) based hardware for the NFC detection and reading. For example, the ST25R3911B board.. But, even more likely, they are specifically using the ST25 Dynamic chips, since those can support fast transfer mode, I2c, and energy harvesting.

Some models might also be using the ST M24LR for energy harvesting.

My Teardown

I was really curious on how these worked, so I took my 2.9″ module apart and took some pictures of the circuit board. Disassembly actually made things more confusing, not less.

To begin with, the main integrated circuit that obviously handles the bulk of the operations has had its label etched out – so you cannot discern model number, or even the manufacturer. It also is a 40-pin chip, which strikes me as odd, as 40-pin chips appear far more rarely than 44-pin chips. However, there is a package type that might match – the HVQFN-40 (or for NPX, SOT618-1). Using this package type to narrow down options makes it seem likely that this is actually a NXP chip, because as far as I can tell, they are the only ones with NFC chips that comes in 40-pin packages – for example, the PN512 or PN532.

WaveShare 2.9 Inch NFC EPaper Module - Left Side

WaveShare Passive NFC Powered EInk Epaper 2.9inch Module - Circuit Board Closeup

WaveShare Passive NFC Powered EInk Epaper 2.9inch Module - Circuit Board Closeup (Angled)

WaveShare Passive NFC Powered EInk Epaper 2.9inch Module - Circuit and Display

WaveShare NFC EPaper Module - Open Case

WaveShare 2.9 Inch Passive NFC EInk Module - Teardown (Back)

WaveShare 2.9 Inch Passive NFC EInk Module - Teardown (Front)

What NFC standards does it use?

These are based on my observations, with a 2.9″ passive display

The answer is complicated.

It’s a Type-2 Tag (aka NFC Tag Type 2, aka NFC Forum Type 2), which is covered specficially by ISO/IEC 14443-3A (aka ISO14443A). Falls under NFC-A spec.

However, the way to talk to this tag type is also covered by the NFC Forum Digital Protocol Technical Specifications, which further details things like command sets (such as WRITE and READ), error checking, etc.

Although the data set maximum message size is reported at 46 bytes, the Capability Container (CC) reports a maximum NDEF data size of 2016 bytes, which would match the maximum allowed by the type-2 spec. ST25 app, which is probably more accurate, reports 2032 bytes.

Although the AAR uses NDEF, the actual image memory stuff appears to use lower-level NFC stuff, so you can’t use Web-NFC or anything else that only speaks NDEF. (see this, and this).

Capability Container

AFAIK, the Capability Container (CC) is basically a very specific area of memory for NFC chips that contains metadata about the capabilities of the chip itself. Thus, I believe it is usually programmed / written / burned in at the factory, and written as “read-only” memory.

Data Format

Stored Data

Reading the raw data off the chip, via NFC Tools, TagInfo, or the ST25 app – all of them say the same thing: that the only data on the NFC chip is some meta information, and the single NDEF AAR entry. The hex is as follows:

57:53:44:5A:31:30:6D:FF
FF:FF:00:00:E1:10:FC:00
03:27:D4:0F:15:61:6E:64
72:6F:69:64:2E:63:6F:6D
3A:70:6B:67:77:61:76:65
73:68:61:72:65:2E:66:65
6E:67:2E:6E:66:63:74:61
67:FE:00:00

The first 7 bytes (57:53:44:5A:31:30:6D) are WSDZ10m in ASCII, which is not random; this is the UID (Unique ID), which belongs the specific manufacturer and/or product (I’m sure the WS in the string is for WaveShare). In this case, the UID is a “double size UID”, which is 7 bytes.

Keep in mind: Not all NFC tags use UIDs (some use NUIDs), and not all are the same byte length – it can differ, but some are well-known or can be determined. For Type 1, 2, and 4 tags, this is governed by ISO/IEC 14443-3.

Troubleshooting

Flashing Issues

I ran into this with both the official WaveShare Android App and the one that I built with their library – flashing new content to the module tends to be really touch-and-go, and it often takes multiple tries of holding your phone against the module just right.

I came to these conclusions with my specific phone (a Pixel 4a), so your experience my differ, but here is what seems to work best for me:

  • Not holding the phone flush against the display, but with a tiny gap (about 0.25 – 0.5 inches) away.
  • The less data you are pushing, the more likely the flash is to succeed
  • Try to align the NFC transceiver in your phone with the circuit board behind the display of the module.

One issue I ran into very quickly is that the very first NDEF Record is an AAR (Android Application Record), which Android treats as a high priority signal to open the corresponding app.

type: "android.com:pkg"
data: "waveshare.feng.nfctag"

As constructed with JS (Web-NFC), it would look like this:

const encoder = new TextEncoder();
/** @type {NDEFRecordInit} */
const waveshareAAR = {
    recordType: 'android.com:pkg',
    data: {
        records: [
            {
                recordType: 'text',
                data: encoder.encode('waveshare.feng.nfctag')
            }
        ]
    }
};

With an AAR, the only way to prevent the default app from taking over (or opening the Play Store to locate it, if not installed) is:


Leave a Reply

Your email address will not be published. Required fields are marked *