bambu-research-group / rfid-tag-guide

Instructions on how to read out the bambulab nfc tags

Bambulab RFID Tag Guide

This guide gives you a basic overview how you can decrypt and read your tags. Since we don't know how Bambulab will react on this guide and the general reverse engineering of the tags: Please don't share you tag's UID and the related keys for now.

We are currently working on a way to submit the tag data in a secure way so analysis on the data could be done.

Table of contents

• Project Summary
  • FAQs
  • How do RFID tags work?
  • How to contribute
• Todos/Timeline/Next steps
• Required Equipment
  • Proxmark3 compatible readers
    • Proxmark3 Easy
• Hacking a Bambulab Tag and readout of its data
  • Bambulab AMS RFID reader location
  • Bambulab AMS Lite RFID reader location
  • Proxmark3 placement for sniffing
  • Dump RFID Contents (.bin)
• Tag Documentation
  • Block Overview
  • MIFARE Encryption Keys
  • Block 0
  • Block 1
  • Block 2
  • Block 4
  • Block 5
  • Block 6
  • Block 8
  • Block 9
  • Block 10
  • Block 12
  • Block 13
  • Block 14
• Compatible RFID tags - By generation

Project Summary

This is a research group dedicated to documenting the data structures used by Bambulab 3D printers to identify filament data.

FAQs

• Can I clone tags?
  • Yes, you can read and clone tags using a tool such as a Proxmark3
• Can I create custom tags?
  • No, tags are digitally signed. Even if you modify the contents, the printer will reject any tags without a valid RSA signature
  • An Open Source RFID Tag has been proposed to allow anyone to create / modify their own tags. This must be adopted by printer manufacturers, or you can mod your own printer for support
• What are the next steps for this project?
  • Decyphering the rest of the unknwn tag content
  • Custom AMS firmware that allows custom tags to be read while ignoring the signature
  • See Todos/Timeline/Next steps for more info

How do RFID tags work?

Here's a high-level summary of how everything works:

• BambuLab printers use MiFare 13.56MHZ RFID tags
  • These tags contain a unique ID that is not encrypted (called the UID)
  • In most cases UID is fixed (not-changable). Some "hackable" rfid tags allow you to set the UID to anything you want
• Blocks (Encrypted)
  • MiFare tags also contain "Blocks" of data. Each block contains info about the spool, such as Material, Color, Manufacturing Date, etc. See Tag stucture section for details
  • The blocks are encrypted, meaning that you need to have a KEY to decipher them
  • Each block is encrypted with a different key
• Encryption Keys
  • Keys are unique to each RFID tag. Even if you discover the key for one tag, that doesn't mean you can use that same key to unlock a different tag.
  • Keys are likely derived from the UID. The UID goes through an algorithm (known only by Bambu) to reveal a set of keys for each block
  • Keys can be sniffed by using a device (such as a ProxMark 3) to listen in on the communication between the AMS and the rfid tag.
  • Once the keys have been sniffed, they can be saved and used to read the contents of the tag directly (without an AMS). (Reminder, the saved keys will ONLY work for the tag they were sniffed from)
• RSA Signature
  • One of the blocks contains a 2048-bit RSA Signature
  • RSA signatures are a way to digitally sign / certify authenticity of content, and they are effectively un-breakable (this is how things like cryptocurrency remain secure)
  • RSA signatures encompass all of the data of the RFID tag. Changing a single byte somewhere else in the tag would require a completely different signature to be considered genuine
  • Bambu printers check the content of the tag and then check if the signature is valid. If the signature is invalid, it rejects the tag
• Cloning Tags
  • Even though there is a signature, a tag can be cloned
  • To clone a tag, it must have the same UID, identical content from the data blocks, and the identical RSA signature
  • Changing even one byte will cause the signature to be invalid, and the tag will be rejected
• Custom Tags
  • This is very unlikely to happen, mostly due to the RSA signature. Only Bambu has their "Private Key" which is used to digitally sign these tags.
  • To create a custom key, you need to know the following info:
    • UUID -> Encryption Key algorithm (or just use known UID + Key pairs)
    • RSA Signature Private Key. You'd have to get this from bambu, good luck
  • Since Bambulab will likely not remove the signature requirement, you would need custom AMS firmware to read tags and ignore the signature

How to contribute

If you have a Proxmark3 (or other RFID debugging tool), you can sniff and decrypt the contents of your tags and submit them for review. The more data we have, the easier it is to compare differences to learn what each byte represents. A lot of the contents have been deciphered (see Tag stucture), but there is still more unknown data still left.

Todos/Timeline/Next steps

• Tool for automatic trace analysis
• Web service for tag submisson with automatic anonymized data publishing to github
• Tag content analysis
• Generate keys based on an arbitrary UID

Required Equipment

• Bambulab 3D Printer with AMS or AMS Lite
• Bambulab Filament spool or the related tags
• A Proxmark3-compatible RFID reader
• The proxmark3 software

Proxmark3 compatible readers

Proxmark3 Easy

A Proxmark3 Easy is sufficient for all the tasks that need to be done. You can buy a clone from Alixepress, Amazon or Dangerous Things.

Hacking a Bambulab Tag and readout of its data

The easiest way to obtain the We document here the most simple approach to get all required A-Keys and the data of the tag. The easiest way is to sniff the data.

Bambulab AMS RFID reader location

The Bambulab AMS RFID readers are located between slots 1&2 and slots 3&4.

Bambulab AMS Lite RFID reader location

The Bambulab AMS Lite RFID readers are located at the base of each spool holder.

For sniffing, you will need to place the Proxmark in between the RFID tag and the reader on the AMS. As there is not much clearance, it is recommended to temporarily remove the low frequency radio (the topmost piece) if you can, as it will not be used in this process.

Proxmark3 placement for sniffing

For sniffing, you will need to place the Proxmark3 against the reader. On the AMS, you may place it on the other side (for example, load the spool into slot one and place the Proxmark3 against the reader in slot 2). On the AMS lite, you will need to place it in between the reader and the spool.

As there is not much clearance, it is recommended to temporarily remove the low frequency radio (the topmost piece) if you can, as it will not be used in this process.

If you place the Proxmark in between the AMS reader and the spool, make sure that spool rotates so that the RFID tag moves away from the reader, otherwise the AMS will assume that it is reading the tag from its neighboring slot and attempt to rewind it until it cannot see the RFID tag.

Dump RFID Contents (.bin)

1. Run ProxMark3 Software

   In a terminal, run pm3 to start the Proxmark3 Software

2. Sniff Communication

   • Start sniffing with: hf 14a sniff -c -r
     (hf=High Frequency, 14a=Tag Type, Sniff=command, -c and -r mean "capture on triggers instead of continuously)

   • Place your Proxmark3 between the tag and the AMS. Recommended: Use tape to hold it in place.

   • Load a strand of filament into the AMS. This is what triggers the AMS to attempt to read the RFID tag.

   • Press the button on the ProxMark to end capture after the filament has completed loading

3. Create a Key Dictionary

   • We will discover keys one at a time and save them to a dictionary file.

   • Navigate to your Proxmark3 software installation directory. This will be specific to your Operating System and Installation.

     • macOS (Intel) Example: /usr/local/Cellar/proxmark3/4.17768/share/proxmark3/
     • macOS (ARM) Eample: /opt/homebrew/Cellar/proxmark3/4.17768/share/proxmark3/
     • Windows Example: TBD
     • Linux Example: TBD

   • Open a text editor and save a blank file called myDictionary.dic into the dictionaries/ folder of your Proxmark3 software installation directory.

     (You can call this file anything you want, but for the rest of this example, we will refer to it as "myDictionary")

   • Leave this file open, we will continue to add keys to it in the next step

4. Extract Keys From Trace

   • Run trace list -t mf -f myDictionary to view the trace that was recorded from sniffing in the previous step.

     This uses the key dictionary myDictionary.dic that we created in step 3.

   • Read the output and look for anything that mentions a key.

     • Three Possible Formats:

       • key E0B50731BE27 prng WEAK - Follow Step 5
       • nested probable key: 50B0318A4FE7 - Follow Step 6
       • Nested authentication detected. - Follow Step 7

     • Each of these 3 entries can provide us with a valid key. Follow step 5, 6, or 7 depending on which type of key you encounter.

5. First Key - Plain Text

   • Example: key E0B50731BE27 prng WEAK
   • This is the first key that was discovered by sniffing AMS traffic.
   • Copy/paste this key into the myDictionary.dic file that you created in step 3, then save the file.

6. Nested Probable Key

   • Example: nested probable key: 50B0318A4FE7
   • Copy/paste this key into the myDictionary.dic file that you created in step 3, then save the file.

7. Nested Authentication Key

   • Example:

     Nested authentication detected.
     tools/mf_nonce_brute/mf_nonce_brute 75066b1d 4db2f2ac 0101 70fcdd3d 328eb1e6 1101 28b75cfd 0010 5196401C
     

   • Open a second terminal window, and change directories into your Proxmark3 software installation directory. This is specific to your OS and PM3 installation.
     • macOS/Linux: cd $(brew --prefix proxmark3)/share/proxmark3/
     • Windows: TBD
   • CD into the tools folder cd tools/
   • Copy the command from ProxMark starting at mf_nonce_brute, including all the arguments (random letters/numbers) after it, and run the program from the tools/ directory.
     • Example (macOS/Linux): ./mf_nonce_brute 75066b1d 4db2f2ac 0101 70fcdd3d 328eb1e6 1101 28b75cfd 0010 5196401C
     • Example (Windows): mf_nonce_brute.exe 75066b1d 4db2f2ac 0101 70fcdd3d 328eb1e6 1101 28b75cfd 0010 5196401C
   • The program will discover a key. Copy/paste this key into your myDictionary.dic file, and SAVE IT.
     • Example Output:

       Valid Key found [ 202efd3dcdfd ]
       

8. Check Keys (Optional)

   • If you want to check how many valid keys you've discovered, you can do this test

   • This is optional, and you can choose to wait until you have discovered all of the keys

   • WARNING: Performing a key check will erase the trace that you recorded during step 2, and will require you to re-sniff data (repeat step 2)

     • If you want to save your trace to avoid re-sniffing, use trace save -f <trace-name> and trace load -f <trace-name>

   • Run hf mf fchk --1k -f myDictionary to test your keys

     • Example Output (showing 11/16 keys discovered):

       [+] found keys:
       
       [+] -----+-----+--------------+---+--------------+----
       [+]  Sec | Blk | key A        |res| key B        |res
       [+] -----+-----+--------------+---+--------------+----
       [+]  000 | 003 | E0B50731BE27 | 1 | ------------ | 0
       [+]  001 | 007 | 63654DB94D97 | 1 | ------------ | 0
       [+]  002 | 011 | 387C06EFFDC8 | 1 | ------------ | 0
       [+]  003 | 015 | 38963E577E43 | 1 | ------------ | 0
       [+]  004 | 019 | 8A3EA2564692 | 1 | ------------ | 0
       [+]  005 | 023 | 935E0F11857A | 1 | ------------ | 0
       [+]  006 | 027 | EBC8F7D23A06 | 1 | ------------ | 0
       [+]  007 | 031 | DD6128F13D4C | 1 | ------------ | 0
       [+]  008 | 035 | ------------ | 0 | ------------ | 0
       [+]  009 | 039 | 4E470B09521F | 1 | ------------ | 0
       [+]  010 | 043 | 50EB8811A69C | 1 | ------------ | 0
       [+]  011 | 047 | 4BDD25091824 | 1 | ------------ | 0
       [+]  012 | 051 | ------------ | 0 | ------------ | 0
       [+]  013 | 055 | ------------ | 0 | ------------ | 0
       [+]  014 | 059 | ------------ | 0 | ------------ | 0
       [+]  015 | 063 | ------------ | 0 | ------------ | 0
       [+] -----+-----+--------------+---+--------------+----
       [+] ( 0:Failed / 1:Success )
       

9. Find Remaining Keys

   • Repeat step 4 until all 16 keys are discovered
   • Your dictionary may be larger than 16 entries if you accidentally copied a duplicate key or an invalid key. These invalid entries are fine, and you can ignore them
   • Recommended: When you think you have discovered all 16 keys, perform step 8 to verify that your keys are correct.

10. Convert Dictionary to Key File

• Run hf mf fchk --1k -f myDictionary --dump to create a key file
• The program will report the destination of the key file that it saved. Copy this filepath to your clipboard
  • Example:

    [+] Found keys have been dumped to /Users/mitch/hf-mf-75066B1D-key.bin
    

11. Dump RFID Contents

• Run hf mf dump -k [path-to-keyfile] to dump the contents of the tag using the 16 keys we discovered
• There should be no errors
• The output should tell you where your .bin file is saved
  • Example:

    [+] saved 1024 bytes to binary file /Users/mitch/hf-mf-75066B1D-dump.bin
    

Tag Documentation

This contains documentation for the known and unknown data that is contained in each block on the RFID tag.

Block Overview

Summary of what kind of data is stored in each block. Detailed info for each block is documented below.

sec	blk	Data
0	0	Block 0 UID and Tag Manufacturer Data
0	1	Block 1 Tray Info Index
0	2	Block 2 Filament Type
0	3	Block 3 MIFARE encryption keys, Unrelated to BambuLab
1	0	Block 4 Detailed Filament Type
1	1	Block 5 Spool Weight, Color Code
1	2	Block 6 Min/Max Hotend, Bed Temp, Bed Temp Type, Drying Time, Drying Temp
1	3	Block 7 MIFARE encryption keys, Unrelated to BambuLab
2	0	Block 8 X Cam Info
2	1	Block 9 Tray UID
2	2	Block 10 Unknown
2	3	Block 11 MIFARE encryption keys, Unrelated to BambuLab
3	0	Block 12 Production Date/Time
3	1	Block 13 Unknown
3	2	Block 14 Unknown
3	3	Block 15 MIFARE encryption keys, Unrelated to BambuLab
4	0	Empty
4	1	Empty
4	2	Empty
4	3	Block 19 MIFARE encryption keys, Unrelated to BambuLab
5	0	Empty
5	1	Empty
5	2	Empty
5	3	Block 23 MIFARE encryption keys, Unrelated to BambuLab
6	0	Empty
6	1	Empty
6	2	Empty
6	3	Block 27 MIFARE encryption keys, Unrelated to BambuLab
7	0	Empty
7	1	Empty
7	2	Empty
7	3	Block 31 MIFARE encryption keys, Unrelated to BambuLab
8	0	Empty
8	1	Empty
8	2	Empty
8	3	Block 35 MIFARE encryption keys, Unrelated to BambuLab
9	0	Empty
9	1	Empty
9	2	Empty
9	3	Block 39 MIFARE encryption keys, Unrelated to BambuLab
10-15	*	RSA-2048 Signature

The first part of the filament serial number seems to be the Tag UID.

Note

All numbers are encoded as Little Endian (LE).

MIFARE Encryption Keys

Every 4th block (eg Sector X, Block 3) contains encryption keys that are part of the MIFARE RFID standard. This has nothing to do with BambuLab's memory format. All BambuLab tags use the same Permission Bits (Access Control)

Example Data: AA AA AA AA AA AA PP PP PP PP BB BB BB BB BB BB

position	length	type	Description
0 (AA)	6	RAW Bin	A-Key
6 (PP)	4	RAW Bin	Permission Bits (Access Control) ALWAYS 87 87 87 69 (hex) for Bambu Tags
10 (BB)	6	RAW Bin	B-Key (always 00 00 00 00 00 00 for Bambu tags)

Block 0

Note: Block 0 is Read-only. The contents are set by the tag manufacturer.

Example Data: AA AA AA AA BB BB BB BB BB BB BB BB BB BB BB BB

position	length	type	Description
0 (AA)	4	string	Tag UID
4 (BB)	12	RAW Bin	Tag Manufacturer Data

Block 1

Example Data: AA AA AA AA AA AA AA AA BB BB BB BB BB BB BB BB

position	length	type	Description
0 (AA)	8	string	Tray Info Index - Material Variant Identifier
8 (BB)	16	string	Tray Info Index - Unique Material Identifier

Block 2

Example Data: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA

position	length	type	Description
0 (AA)	16	string	Filament Type

Block 4

Example Data: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA

position	length	type	description
0 (AA)	16	string	Detailed Filament Type

Known Values:

• PLA Basic
• PLA Tough
• Support for PLA
• PLA-CF
• PETG Basic

Block 5

Example Data: AA AA AA AA BB BB __ __ CC CC CC CC __ __ __ __

position	length	type	Description
0 (AA)	4	RGBA	Color in hex RBGA
4 (BB)	2	uint16 (LE)	Spool Weight in grams (E8 03 --> 1000 g)
8 (CC)	8	float (LE)	Filament Diameter in milimeters

Block 6

Example Data: AA AA BB BB CC CC DD DD EE EE FF FF __ __ __ __

position	length	type	Description
0 (AA)	2	uint16 (LE)	Drying Temperature in °C
2 (BB)	2	uint16 (LE)	Drying time in hours
4 (CC)	4	uint16 (LE)	Bed Temerature Type (types unknown)
6 (DD)	2	uint16 (LE)	Bed Temperature in °C
8 (EE)	2	uint16 (LE)	Min Temperature for Hotend in °C
10 (FF)	2	uint16 (LE)	Max Temperature for Hotend in °C

Block 8

Example Data: AA AA AA AA AA AA AA AA AA AA AA AA BB BB BB BB

position	length	type	description
0 (AA)	12	RAW Bin	X Cam info
12 (BB)	4	float (LE)	Nozzle Diameter...?

Block 9

Example Data: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA

position	length	type	Description
0 (AA)	16	string	Tray UID

Block 10

Example Data: __ __ __ __ AA AA __ __ __ __ __ __ __ __ __ __

position	length	type	Description
4 (AA)	2	uint16 (LE)	Spool Width in µm (E1 19 --> 6625µm --> 66.25mm )

Block 12

Example Data: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA

position	length	type	Description
0 (AA)	16	string	Production Date and Time in ASCII (<year>_<month>_<day>_<hour>_<minute>)

Block 13

Example Data: AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA

position	length	type	Description
0 (AA)	16	string	Short Production Date/Time...?

Block 14

Example Data: __ __ __ __ AA AA __ __ __ __ __ __ __ __ __ __

position	length	type	Description
4 (AA)	2	uint16 (LE)	Filament length in meters...?

Compatible RFID tags - By generation

Gen 1 --> Not compatible(due to AMS checking if tag is unlockable with command 0x40)

Gen 2 --> Works

Gen 2 OTW --> Not tested

Gen 3 --> Not tested

Gen 4 --> Not tested(The best option but pricey and hard to source in small chip formfactor)

rfid-tag-guide's Issues

DoD on Update process of firmware on AMS

A other way is check via network analysed the communication printer/AMS to BambooLab, but i'm things see must a options to appended new tags to AMS and a simples way is, add new keys on customized materials and configurations.

Is there any progrss ?

Hi,

Is there any progress please ? I would love to get it workig...

Regards

What are the smallest RFID Readers do you guys recommend for reading Bambu spools?

I'm working on a modular draw system that scans filaments as I'm closing the drawer. This partially involves the open source RFID for filaments and Bambu labs, which sounds readable. All of the readers I know of are pretty large though. I'm hoping to find something that I can stick to the side of a plastic wall or around a PVC pipe (although it would be parallel going the PVC route, so not sure how well it would scan). Just started playing with the idea, but I would love to hear some recommended components from people more experienced.

mf_nonce_brute finds incorrect keys, leading to incomplete key retrieval

Sometimes, when you include a key found by mf_nonce_brute in the dictionary, trace list will suggest the same mf_nonce_brute command line. It's because the key is not the good one.

In our case, when the decoding is successful, the decoded command always starts with '30'. For example :

enc:  5315320D
dec:  30200089

However, when the decoding is incorrect, the decoded command differs in Phase 2, even though it was correct in Phase 1 :

CMD enc( 8f090159 )
    dec( 300426ee )    <-- valid cmd
...
enc:  8F090159
dec:  60D1F1BC

So, I edited mf_nonce_brute.c and commented out all commands except for the one starting with 0x30, as specified in protocol.h, before recompiling it :

uint8_t cmds[8][2] = {
    {ISO14443A_CMD_READBLOCK, 18}
/*
    {ISO14443A_CMD_WRITEBLOCK, 18},
    {MIFARE_AUTH_KEYA, 0},
    {MIFARE_AUTH_KEYB, 0},
    {MIFARE_CMD_INC, 6},
    {MIFARE_CMD_DEC, 6},
    {MIFARE_CMD_RESTORE, 6},
    {MIFARE_CMD_TRANSFER, 0}
*/
};

Now it decodes with the correct key :

CMD enc( 8f090159 )
    dec( 300426ee )    <-- valid cmd
...
enc:  8F090159
dec:  300426EE

Also, don't forget to include in the dictionary the keys that are listed as 'WEAK' or as 'nested probable keys' in the trace.

Can only recover 10 keys

Hi,
I was wondering if someone would be able to help me. I can only recover 10 of the 16 keys. After the 10 keys I found the trace list command doesnt return a new hf_nonce command altough the trace doesnt show any crc erros.

Filament info through MQTT

When connecting to your printer with mqtt (port 8883) and sending this:
{
"pushing": {
"sequence_id": "1",
"command": "pushall"
},
"user_id": "1234567890"
}
to device/{SERIAL_NO}/request, the response will contain most (if not all) data of the AMS and the Filaments inside.
I don't really know if this helps for this research but might be interesting, as it is a easier and cheaper method to retrieve the UIDs of the rolls.

Question: Whats neccessary to get further with this Project ?

As metioned in the description - what do you need to get further ?
I´m really looking for a solution to use my own filament with own tags.

At the moment i own a Bambu Printer with AMS and 4 Spools with Tags - Already tried to sniff with the Chamelon Mini (but i guess sniffing works different here) and with the Chameon Ultra (but at the moment it has no sniffing implemented)

But im more then ready to order a proxmark 3 to play with the ams ;)

So back to the question, my guess is that your approach is to gather as many (partialy)decrypted tags as possible to generate those keys.
And with that keys we can hopefully decrypt the complete tag, modify the data and write it to our own tags ?

Abrasiveness

There is interest in knowing the abrasiveness of a material in order to check and use the right nozzle for the material.

I could not find an existing standard to describe the abrasiveness of a manufacturing material. Based on a few data points I found here and there, I've drafted an initial table of what it could look like:

Index	Filament Abrasiveness	Nozzle Material Recommendation
0 - 5	Non-abrasive	Brass
6 - 10	Slightly abrasive	Hardened steel or stainless steel
11 - 20	Moderately abrasive	Hardened steel or stainless steel
21 - 40	Highly abrasive	Tungsten carbide
41+	Very abrasive	Silicon carbide or ruby

Man in the Middel

Hi, I would like to propose a solution that may be easier then to create counter fit NFC tags. Maby its a bad Idea but i just wanted to proposed anyway.

What if we used a mcu as man in the middle from the AMS main board to the rfid reader the man in the middle spoofs all the checks like is it writable ( i thought i heard that this is a problem ).

In my mind you have the advantage that you can use all compatible RFID tags that work with the chip they use ( FM17580-QNA-T-G lcsc),
but off cores you would need to create the board and hardware so please let me know what you think off this. At the moment I don't have the time to look into it but after my exams at the start off next year I have plant off time for it.

Compatible RFID tags. (Post your tested tags here)

Sourcing right rfid tags can be hard so to make it easier for everyone please share your working/non working tags here.

Add following information:

LINK: https://lab401.com/products/mifare-compatible-1k-uid-modifiable-pack-of-5
STATUS: Not working

(Optional):
GENERATION: Gen 1
INFORMATION: Tag can be unlocked with command 0x40, therefore doesnt work with AMS

Bambulab Firmware for AMS

I don't believe it, but is the firmware for the X1 or the AMS available for download?
You could check whether the public key is included in the firmware. If the key is contained in the firmware, you could perhaps inject your own key? Unfortunately I have not found a download option for the firmware.

More fields identified

Now that I have a couple of tags decoded, I've checked through their data and can assert the following:

Block 5: 4 bytes after the spool weight is filament diameter as a single precision float (1.75)
Block 8: 4x uint16 and 2x float. The floats vary between 0.8 to 0.2, but not restricted to nozzle sizes.
Block 10: Second uint32 is the width of the spool in hundredths of mm. (6625 for all my tags, 66.25mm)
Block 12: Long manufacturing timestamp, "YYYY_MM_DD_HH_mm"
Block 13: Short manufacturing timestamp, "YY_MM_DD_HH"
Block 14: Second uint32 is the total length of filament in metres. (330 for my 1kg spools, 82 for my "90m" 250g spool)

And unfortunately the block of random data right at the end of the tag is almost certainly a 2048-bit RSA signature. The public key will be in the firmware, but we won't be able to derive the private key.

More data (optional)

Part of what I'm trying to achieve is to be able to send a manufacturing job to a printer in a fleet of printers that has the right material currently loaded for the job.

In order to achieve this, I need to know as much as possible of the mechanical properties of the currently loaded material, given the fact that there are thousands of commercial names for materials and it will be near-impossible, if even desirable, to classify them in a centralized reference database.

My proposition is not to change the required fields, but add many more optional fields. Using a serialization format to store the data should allow still using 1K NFC chips, but if at some point optional data become too powerful, 2K/4K support should be possible while still supporting 1K for required and some optional data.

In this proposition I've also included a section to track the usage of the spool dynamically, and an abrasiveness level that will be discussed in another issue. This is only an initial draft, but it could look something like this:

filament_data = {
  # meta
  'tag_version':           '2',                         # required

  # product
  'manufacturer':          'Francofil',                 # required
  'name':                  'Blue PLA Filament A 110',   # required
  'sku':                   'PLA-110',
  'color_name':            'Blue A 110 Metalized',      # required
  'color_hex':             0x0000FF,
  'manufacturing_method':  'fused_filament_fabrication',
  'certifications':        'rohs,ue:10/2011,reach,fda',
  'additional_data':       None,

  # characteristics
  'diameter_nominal':        1750,                        # required
  'diameter_tolerance':      20,
  'weight_nominal':          1000,                        # required
  'min_extrusion_diameter':  10, # 0.10mm

  # manufacturing data
  'batch':                 '2021-01-01-1234',
  'id':                    '3abe4ae4',
  'manufacture_time':      1612147, # unix timestamp
  'manufacture_location':  '4C5P+JR', # open location code
  'weight_measured':       1003,
  'length_measured':       336,
  'standard_deviation':    3677, # x/1000 um
  'ovality':               180, # x/100 %

  # properties
  'type':                    'polylactic_acid',           # required
  'additional_components':   'thermoplastic_polyurethane:3',
  'properties':              'food_contact_materials,biodegradation',
  'abrasiveness':            1,
  'density':                 1240,                        # required
  'shore':                   75,
  'water_absorption':        5,    # x/10 %
  'surface_resistance':      6,    # 10^x ohm
  'tensile_modulus':         2612, # MPa
  'tensile_stress_yield':    53,   # MPa
  'tensile_stress_break':    51,   # MPa
  'elongation_yield':        21,   # x/10 %
  'elongation_break':        25,   # x/10 %
  'flexural_strength':       100,  # MPa
  'flexural_modulus':        4960, # MPa
  'compressive_strength':    60,   # MPa
  'compressive_modulus':     5000, # MPa
  'compressive_break':       60,   # x/10 %
  'charpy_impact_strength':  26,   # kJ/m^2
  'melt_flow_rate':          720,  # g/10min
  'glass_transition':        575,  # x/10 °C
  'melting_point':           1390, # x/10 °C

  # spool
  'spool_diameter_core':   52,
  'spool_diameter_flange': 200,
  'spool_width':           55,
  'spool_empty_weight':    246,

  # print settings
  'extrusion_temp_min':    190,                         # required
  'extrusion_temp_max':    230,
  'bed_temp_min':          40,                          # required
  'bed_temp_max':          60,

  # properties
  'transmission_distance': 2540,
  'max_dry_temp':          55,
  'humidity_storage':      25,
  'humidity_print':        20,
  'temperature_print':     45,

  # usage
  'remaining_weight':      -1, # grams
  'seen_first':            -1, # unix timestamp
  'seen_last':             -1, # unix timestamp
  'max_humidity':          -1,
  'max_temperature':       -1,
  'computed_density':      -1,
}

Flipper Zero RFID files

I used the Flipper Zero to read my Bambu filaments. Perhaps helpful?
just delete .txt

PLA_Basic_Bambu Green #16C344.nfc .txt
PLA_Matte_Ice Blue #A3D8E1.nfc .txt

Storage format

One of the challenges working with NFC tags is to future-proof the organization of data in its memory.

While NFC chips are capable of addressing values by block for fast reading, the memory can also be used as a whole where very fast reading may not be a requirement.

Looking at the tradeoff between speed and the furure-proofing of data organization, I think that for a NFC on a spool, reading speed is not a priority. Whether the spool is read in 0.2s or 2s in my opinion does not make a huge difference in usage, if that allows for future compatibility.

There are many ways to look at the organisation of data in a constrained memory. On my side I'm looking at 2 standards: Protobuf and IPLD. Both take a data format spec and data in any kind of format or language, and output a space-optimized representation of this data.

Protobuf advantages:

• widely supported and common
• probably more compact

Protobuf disadvantages:

• data slots for legacy data must be kept reserved to preserve readability of legacy content
• explicit data slot numbering
• maintained mostly by google, known to kill projects on their own agenda

IPLD advantages:

• most modern view on data interoperability
• inherent mechanisms to link to other data through IPFS (e.g. printing processes or datasheets)
• spec versioning and upgrades supported by the tooling
• maintained by many decentralized organizations

IPLD disadvantages:

• still early, small community and basic tools
• mostly oriented to golang for now

My proposition is to use the NFC's memory as a whole, storing data as per a data spec, instead of allocating specific block numbers for specific data, which is both inefficient and hard to evolve.

RFID Testing

I imagine this behaviour is pretty obvious - but thought I would document it anyway as it might be of interest.

Test1 - Empty BL PLA White Basic -> Generic White.

• Respooled about half of some generic white PLA onto an Empty BL PLA Basic white spool inner.
• Printer detected it ok as white PLA and also seem to get the approximately amount respooled about right too - so probably handy for auto colour selection of non Bambu filament - as long as you have a previously used Bambu inner, and don't mind the generic filament being picked up as Bambu.
  NB. I marked an arrow on the cardboard of the inner to make sure I wound the filament on in the correct direction

Test2 - Removed RFID from left hand side.

• As expected the respooled generic white filament on a BL spool wasn't detected as white in Slot 4 of the AMS.
• But in slot 3 of the AMS it was detected ok as white.

Test 3 - Removed RFID from left hand side of BL Generic Blue

• As expected same behaviour as above - the spool was detected ok when it was replaced in slot3

Test 4 - probably the most useful one to me.

Took a half of the BL Generic Blue filament (which I was already using in another AMS on another printer), - but having to manually configure it on that printer.

Added the left RFID removed from the main BL Blue PLA spool into the Half respooled spool - on the outside, with the edge of the RFID about 3.7mm from the edge of the spool. Stuck it on with sticky tape on the outside.

• Result as expected - in slot 4 of the second AMS (on a different printer) - filament was detected ok as half empty BL PLA blue.

So I will probably do the same for the other 4 or 5 BL filaments that I have half respooled onto 2nd spools - so that I can use the same colour on 2 printers at the same time. Just need to mark the 2 spools carefully to make sure that it is obvious which ones will be detected in the odd and even slots respectively.

The only slight change I might make is that I think it would probably be better to slice off the right hand side RFID - as it won't interfere with the notch - where as the left hand side is the one right on the notch in the spool holder.

Haven't actually tried doing any printing on long term tests - but thought I would document results anyway in case they might be of use.

RFID snooper

Rather than try and break the firmware on the AMS, would it be possible to use an ESP32 to passively monitor the bus signals from the AMS RFID boards and motherboard? It could then send this data to the slicer, and override the values from the bambu network plugin. This would hopefully allow any RFID to be recognised and assigned to an arbitrary filament profile, without having to crack the bambu keys or firmware.

Lookup table vs plain text

Hi,

I would like to give my opinion on the debate of using a lookup table or plain text as mentioned in the Open Spec document, also as to stir the debate so other people can give their opinions.

We have been active contributors of a few other related standards, including Open Know How which describes how to build something and Open Know Where which describes manufacturing capabilities.

When elaborating these standards, the decision was made to use wikipedia's article slugs to refer to existing tool types, manufacturing processes, materials and the such. That was convenient so that no specific actor has to maintain a database for others to access, which would increase centralization of the standard. The wikipedia slugs also have the advantage of being human readable, so if a slug is not present in a local database of slugs on a machine that is not connected to the internet, it will still be more readable than a sequential ID.

Materials in 3D printing have been known to have many names for similar stuff, as outlined in the Open Spec doc for PLA. However similar materials are often interchangeable in terms of printing process : PLA+, Tough PLA, PLA Silk will still be a PLA base offering different properties but will be printed with similar settings, being PLA base.

I propose the following:

The spec should include a plain text commercial name of the material identifying how the manufacturer sells it, and wikipedia slugs for the main component (>=51% of the composition) and for other components with optional percentages.

example:

name: Tough PLA-GF # required
type: polylactic_acid # optional wikipedia slug for PLA
components: fiber_glass:5,thermoplastic_polyurethane:3 # optional component that makes PLA tough with optional percentage in composition

Transmissivity

It may be useful to have the tag provide transmissivity information for the filament for use with software such as Hueforge.