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
- WaveShare Store
- WaveShare Wiki
- Developer tools:
- Official
- Android / Java SDK
- Note: This is a bytecode / compiled JAR file, not raw source code
- Android App (APK)
- *ST25R3911B-NFC-Demo (C code)
- Related to this WaveShare board
- Android / Java SDK
- Unofficial
- Proxymark3
- Examples using the JAR file:
- Official
- Blog posts
- The Digital Reader – *Hands on With Waveshare’s NFC-Powered E-Ink Screens
- General WaveShare E-Ink Projects and Libraries
- Other
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
.
Teardown – Image Gallery
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.
Problem: NFC tag contains “deeplink”
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:
- Web-NFC: Start an active scan, and handle the
read
event - Android: By intercepting the intent with the foreground dispatch system
- Removing the AAR