Hur man programmerar NFC-taggar med olika chiptyper (NTAG, MIFARE och mer)

 

Att skriva en tagg är tre separata operationer, inte en

 

När människor säger att de vill programmera NFC-taggar beskriver de vanligtvis tre olika saker som råkar utlösas av samma knapp i en telefonapp.

 

Den första ärformatering. Ett NFC-chips minne måste få veta att dess användarområde innehåller ett NDEF-meddelande snarare än godtyckliga bytes. Detta görs genom att skriva en liten datastruktur som kallas för kapacitetsbehållaren. På NTAG21x-delar görs detta redan på wafernivå, så chipet anländer NDEF-formaterat och kan bara hålla NDEF. På MIFARE Classic och några andra marker är formatering något du utför, och strukturen landar i en-gångs-programmerbar region. Formateringen är därför permanent. Det finns inget unformat-kommando och inget leverantörsverktyg som ger dig ett.

 

Den andra ärskriva nyttolasten: ett NDEF-meddelande som innehåller en eller flera poster, oftast en URI-post som pekar på en URL. Det här är delen som alla bilder. Nyttolastskrivningar är normalt repeterbara, vilket är anledningen till att ett marknadsföringsteam kan omdirigera en kampanjtagg sex månader senare utan att beställa om hårdvaran.

 

Den tredje ärkonfiguration: lösenordsbytes, låsbitar, spegelinställningar, åtkomstvillkor, autentiseringsnycklar. Det här lagret är där de oåterkalleliga besluten lever, och det är lagret som ingen konsumenthandledning berör alls. Om du planerar att programmera NFC-taggar för något med en säkerhetsgräns runt sig, är konfigurationslagret projektet.

 

Att hålla dessa tre åtskilda i ditt huvud är det som hindrar en batch från att skrotas. De flesta skrivfel vi diagnostiserar är inte nyttolastfel. De är ett formateringstillstånd eller ett konfigurationstillstånd som någon inte visste fanns.

 

NFC-taggchiptyper jämförda innan du programmerar dem

 

Varje seriöst beslut om hur man programmerar NFC-taggar i stor skala börjar med denna tabell, eftersom minnestak och plattformsstöd ställs in i ögonblicket för chipval och kan inte patchas senare i programvaran.

 

Chips	Användarminne	NFC-forumtyp	Fabriks NDEF-tillstånd	Lösenord / nyckelskydd	iPhone NDEF läs + skriv
NTAG 213	144 byte	Typ 2	För-formaterad	32-bitars PWD / 16-bitars PACK	Ja
NTAG 215	504 byte	Typ 2	För-formaterad	32-bitars PWD / 16-bitars PACK	Ja
NTAG 216	888 byte	Typ 2	För-formaterad	32-bitars PWD / 16-bitars PACK	Ja
MIFARE Ultralight EV1	48 eller 128 byte	Typ 2	Formattable	32-bitars PWD / 16-bitars PACK	Ja
MIFARE Classic 1K	1 024 byte totalt, ungefär 716 tillgängliga för NDEF när tillverkaren blockerar och 16 sektorssläpvagnar dras av	Inte en NFC-forumtyp	Formattabel, sektor-baserad	CRYPTO-1 sektornycklar A/B	Inga
MIFARE DESFire EV3	2 KB till 8 KB, fil-baserat	Typ 4	Ansökan måste skapas	AES-128 / 3DES, åtkomsträttigheter per fil	Ja
NTAG 424 DNA	416 byte totalt, uppdelat i en 32-byte kapacitetsbehållare, en 256-byte NDEF-fil och en 128-byte skyddad datafil	Typ 4	Förhand-förberedda filer	Fem AES-128-nycklar, 3-pass ömsesidig autentisering	Ja

 

NTAG21x-siffror, lås-bitbeteende och typ 2/ISO/IEC 14443 typ A-kompatibilitet enligtNXP NTAG213/215/216 produktdatablad. MIFARE Classic 1K-struktur per NXP-datablad MF1S50yyX (16 sektorer × 4 block × 16 byte). DESFire EV3 per MF3D(H)x3. NTAG 424 DNA-minneslayout prNXP.

 

Två kolumner avgör de flesta projekt innan någon programvara väljs: minnestaket och iPhone-kolumnen. Vad tabellen inte kan berätta är avkastningen. Ett korrekt specificerat chip ger fortfarande avslag om kodningssteget inte har något verifieringspass bakom sig, vilket är ämnet för den andra hälften av denna artikel.

 

NTAG 213, 215 och 216: standardvalet och dess riktiga tak

 

För ungefär fyra av fem inkommande projekt är den här familjen det rätta svaret, och att lära sig hur man programmerar NTAG 215 NFC-taggar tar ungefär nittio sekunder med en telefonapp. Chipet levereras NDEF-formaterat, posttypen som fungerar konsekvent över alla handenheter är en vanlig URI-post, och både Android och iOS skriver den utan att SDK fungerar.

 

 

Det är också familjen bakom nästan alla digitala visitkortsprogram, där ett enda vCard- eller URL-register är hela nyttolasten, och där det fysiska formatet vanligtvis spelar större roll än chippet. De flesta av dessa beställningar hamnar påtomma vita PVC NFC-kortsnarare än klistermärken, eftersom kortet måste överleva en plånbok och ta ett tryck.

 

Taket kommer snabbare än vad folk förväntar sig. NTAG213 ger dig 144 byte användarminne, och ett NDEF-meddelande är inte bara din URL. Det finns ett TLV-omslag, ett posthuvud, ett typfält och ett längdfält innan ett enda tecken i din adress lagras. En URI-post komprimerar vanliga prefix som t.exhttps://www.till en enda byte, som återställer tio till tjugo byte, och på en 144-bytedel är den skillnaden gränsen mellan att passa och misslyckas. Där team fastnar är inte webbadressen i sig utan extrafunktionerna: lägg till en textpost för en läsbar etikett, lägg till en Android Application Record så att taggen öppnar en app istället för en webbläsare, och en bekväm nyttolast blir ett överflödesfel.

 

Vår egen tumregel, och det här är sådant du bara lär dig genom att koda några miljoner av dessa: om den avsedda webbadressen inklusive frågeparametrar överstiger cirka 90 tecken, sluta specificera NTAG213 och gå uppåt. Enhetskostnadsskillnaden mellan 213 och 215 är tillräckligt liten för att det nästan aldrig är värt risken med en omdesign av mitt-program. En kampanj som senare vill lägga till UTM-parametrar eller ett serienummer till varje tagg-URL kommer att träffa väggen på 213 och inte träffa den på 215.

 

Lösenordsskydd på denna familj är värt att förstå precis, eftersom det är svagare än ordet "lösenord" antyder. Ett 32-bitars PWD-värde sänds i klartexten och kontrolleras av chipet, som grindar skrivåtkomst, och valfritt läsåtkomst, från en vald sida och framåt. Det hindrar en nyfiken medlem av allmänheten att skriva om din tagg med en telefon. Det är inte en kryptografisk kontroll och bör aldrig beskrivas för en klient som en. Observera också att inte alla generationer stöder det alls: den äldre NTAG203 har ingen som helst lösenordsmekanism, och biblioteksdokumentationen är tydlig att skyddsanrop mot den helt enkelt misslyckas (nfcpy dokumentation).

 

MIFARE Classic: Skrivbar på Android, frånvarande på iPhone

 

Här är kompatibilitetsfällan som har avslutat fler NFC-projekt än någon annan enskild faktor. Alla som frågar hur man skriver NDEF till MIFARE Classic arbetar redan mot formatet: MIFARE Classic är inte en NFC Forum-taggtyp, det är ett ISO/IEC 14443-3A-kort med en proprietär sektor och nyckelstruktur som föregår NDEF-ekosystemet, och NDEF-stöd på det existerar endast genom en kartläggningskonvention som är skiktad ovanpå.

 

 

Android hanterar den konventionen. iOS gör det inte. Apples Core NFC har aldrig stött MIFARE Classic, med plattformens stödda MIFARE-familjer begränsade till Ultralight, Plus och DESFire, en position som utvecklare har bekräftat upprepade gånger på Apples egna forum (Apples utvecklarforum). Eftersom iOS inte kan adressera kortets minne direkt, kan en iPhone inte skriva NDEF till det och inte visa NDEF lagrat på det.

 

Det som gör detta så farligt under utvärdering är att MIFARE Classic-taggar inte visas döda på en iPhone. Kortet presenterar ett ISO 14443-UID, så genvägsappen accepterar det gärna som en automatiseringsutlösare, och bakgrundsskanning kan fortfarande starta en tidigare lagrad NDEF-post av en typ som stöds. En inköpsledare som testar ett prov på sin iPhone ser ett svar och kvitterar. Beteendet de såg hade ingenting att göra med taggens minnesinnehåll, och hela tillvägagångssättet kollapsar i samma ögonblick som projektet behöver webbadresser per enhet som iPhones faktiskt kan läsa.

 

Den praktiska regeln som faller ur detta: alla som jämför hur man programmerar NFC-taggar för iPhone vs Android bör köra acceptanstestning på båda plattformarna med produktionschippet, aldrig enbart på Android och aldrig på ett prov av ett annat chip än det på inköpsordern.

 

Låt mig vara rakt på sak om rekommendationen, för "det beror på ditt användningsfall" är inte ett användbart svar här. Om dina NFC-taggar kommer att avlyssnas av allmänheten, ange allt utom MIFARE Classic.

 

För team som redan finns i ett klassiskt-baserat åtkomstsystem reduceras beslutet till en variabel, och det är inte taggarna. Det är den återstående livslängden för ditt läsarbo. Om dessa läsare har två eller tre år kvar på sig och ingen smartphone någonsin kommer att röra referensen, är det ett försvarbart samtal att fortsätta med Classic i en sluten slinga, och de praktiska frågorna blir IC-källa och UID-format snarare än kodningsmetod, vilket är vad vi tar upp i våra anteckningar ombeställa MIFARE 1K-taggar till ett installerat system. Om läsarna själva ska bytas ut i det fönstret, spendera inte pengar på en övergångsreferens. Flytta hela fastigheten till en AES-baserad del i ett steg och absorbera kostnaden en gång.

 

Det finns en andra fälla i samma familj, subtil nog att den överlever hela QA-cykler. Genom att lägga till en Smart Poster-omslag till en post, som de vanliga kodningsverktygen erbjuder som ett vänligt sätt att bifoga en titel till en URL, ändras posttypen. Poster som är inslagna på det sättet plockas inte upp av iOS-bakgrundsskanning alls, oavsett vad som är kapslat inuti. Android-testning passerar på alla enheter, iPhones gör ingenting och det finns inget felmeddelande någonstans att diagnostisera.

 

Ultralight, DESFire och NTAG 424 DNA: Where Programming Becomes Key Management

 

MIFARE Ultralight EV1 sitter nära NTAG21x i beteende och du programmerar NFC-taggar på den på samma sätt, med en mindre minnesbudget på 48 eller 128 byte och samma klass av lösenordsgrind. Inget konceptuellt nytt händer.

 

DESFire och NTAG 424 DNA är en annan disciplin. På dessa Typ 4-delar skriver du inte byte till en platt minneskarta, du använder ett filsystem med per-filåtkomsträttigheter, och varje meningsfull operation kräver autentisering med en AES-128-nyckel först. NTAG 424 DNA bär fem kunddefinierade AES-nycklar, använder 3-pass ömsesidig autentisering för den skyddade datafilen och bär Common Criteria EAL4-certifiering på både hårdvara och mjukvara. Lag som programmerar NFC-taggar för produktautentisering snarare än enkel omdirigering letar vanligtvis efter denna del specifikt på grund av en funktion.

 

Den funktionen är Secure Dynamic Messaging, ofta skriven som SUN. Med den aktiverad ändras NDEF-URL:n som chippet presenterar vid varje tryck: chippet speglar dess UID och en monotont ökande läsräknare i URL:en, valfritt krypterad, och lägger till en CMAC beräknad med en nyckel som bara du och chippet har. Din backend kan sedan skilja en riktig tagg från en fotograferad webbadress, och kan skilja tryck nummer 4 från tryck nummer 4 000.

 

Att konfigurera det korrekt är där specifikationen biter. Speglingsreglerna är inte fria-: när PICC-data är krypterad, spegling av UID och läsräknaren blir obligatorisk snarare än valfri, de två reser alltid tillsammans och CMAC måste sitta i slutet av NDEF-meddelandet. Designa din URL-struktur runt dessa begränsningar, inte tvärtom, annars kommer förskjutningarna inte att lösas och backend kommer att avvisa varje läsning.

 

Det misslyckande vi ser oftast på SUN-utbyggnader har ingenting att göra med något av det. Varje offentlig referensimplementering och demoserver levereras konfigurerad med fabriks-standardnycklar-noll, eftersom det är det som får en demo att fungera direkt. Projekterar prototyp mot det, prototypen fungerar, och nyckelrotationssteget kommer aldrig in på startchecklistan. Taggarna slocknar kryptografiskt nakna medan alla inblandade tror att distributionen är krypterad, vilket är anledningen till att vår egen procedur för provsläpp kontrollerar nyckeldiversifiering på produktionsenheterna snarare än på vad som än användes för demon.

 

Sex operationer som du inte kan ångra när du väl har programmerat NFC-taggar

 

Nyttolastomskrivningar är billiga. Dessa är inte. Var och en nedan är ett beslut som omvandlar ett parti taggar till en anläggningstillgång, och var och en har varit orsaken till skrotat lager som vi personligen har behövt ersätta.

 

Drift	Vad den gör	Varför det inte går att ångra	När det ska schemaläggas
NDEF-formatering	Skriver kapacitetsbehållaren	Landar i ett-gångs-programmerbart minne	På fabriken, efter att chiptypen har bekräftats
Statiska låsbitar	Låser de första 16 sidorna på typ 2-chips	Låsbitar är endast inställda-och kan inte återställas	Först efter att det slutliga innehållet är avstängt
Dynamiska låsbitar	Täck 96 databyte på NTAG213, 456 på NTAG215 och 840 på NTAG216, med en granularitet på 2 sidor på NTAG213 och 16 sidor på NTAG215 och NTAG216, enligt NXP-databladet som citeras ovan	Samma uppsättning-endast mekanism, samma beständighet	Samma grind som statiska lås
-Endast läsväxel	Ställer in NDEF-skrivflaggan permanent	Det finns inget omvänt kommando	Aldrig innan fältförsöket slutförts
LRP-läge på NTAG 424 DNA	Växlar AES till läckage-fjädrande drift	Aktiverad av SetConfiguration, utan väg tillbaka till AES-läge	Endast om en dokumenterad hotmodell kräver det
Nyckelbyte utan deposition	Ersätter fabriks AES-nycklar	Chipet har ingen återställningsväg om den nya nyckeln tappas bort	Endast en gång nyckelförvar är formellt tilldelat

 

Den sidans granularitet är den praktiska detalj som de flesta missar när de frågar hur man låser en NFC-tagg efter programmering. Låsning är inte en enda allt-eller-inget-växel. På NTAG215 och NTAG216 kan du låsa in block om 16 sidor, vilket gör en blandad layout genomförbar: en serienummerregion låst på fabriken, en kampanj-URL-region som lämnas skrivbar för marknadsföringsteamet. På NTAG213 är granulariteten två sidor, finare men över en mycket mindre karta. Att bestämma gränsen är en designuppgift, och det måste ske före kodningskörningen, inte efter.

 

Vanan som är värd att bygga upp är att separera kodningsgrinden från låsgrinden. Vi avråder kunder från att låsa vid beställningstillfället och anledningen är helt och hållet kommersiell snarare än teknisk.

 

I hela vår beställningshistorik är den vanligaste begäran efter-leverans inte ett defektanspråk, det är en destinationsändring och den samlas under det första tjänsteåret. De vanliga triggerna är en migrering av målsidan eller en överlämning av byråer, vilka inte är synliga när beställningen görs. Du behöver inte någons misslyckandestatistik för att agera på detta, eftersom asymmetrin avgör det på egen hand: en olåst tagg som aldrig behöver ändras kostar dig ingenting, medan en låst tagg som behöver ändras kostar en hel ersättningsorder plus ominstallationsarbetet. Programmera NFC-taggar först, kör fältförsöket, lås efteråt.

 

Att verifiera chipet är vad fakturan säger

 

 

Chipets äkthet är inte ett paranoid problem i den här kategorin, det är ett rutinmässigt inkommande-inspektionsobjekt och det hör till samma kvalitetskontrollsteg som alla andra kontroller du kör innan du programmerar NFC-taggar i produktionskvantiteter. NXP:s NTAG-, MIFARE-, Ultralight- och ICODE-familjer har var och en en ECC--baserad originalitetssignatur skriven vid chiptillverkning, 32 byte på NTAG21x-delar, som kan läsas tillbaka och verifieras mot tillverkarens publika nyckel. En tagg som fungerar perfekt kan fortfarande misslyckas med den kontrollen.

 

Detta händer mer än vad marknaden medger. Ingenjörer som köper NTAG21x-taggar genom allmänna återförsäljarkanaler har rapporterat till tillverkarens egen community att prover fungerar exakt som specificerat, motspegling ingår, men rapporterar som klonkisel under originalitetsverifiering, och NXP:s publicerade svar är att sådana delar inte stöds och är olämpliga för säker användning eftersom själva IC:en kan vara sårbar (NXP-gemenskap).

 

Den operativa konsekvensen är snävare än folk antar, och värd att ange exakt. Om din applikation är en marknadsföringsomdirigering kommer ett klonchip att tjäna dig på ett adekvat sätt och du kanske inte bryr dig. Om din ansökan omfattar autentisering, manipuleringsbevis eller något påstående om anti-förfalskning till din egen kund, ogiltigförklarar ett icke verifierbart chip hela premissen och ingen korrekt kodning kompenserar för det. Verifieringen tar sekunder per prov med en läsarapp, och den hör hemma i din inkommande QC-procedur snarare än i en-post mortem. Relaterad läsning för alla vars skrivande slutförs men vars läsare är tyst:varför en klonad klistermärke läser bra och fortfarande misslyckas vid dörren.

 

Den klassiska MIFARE-säkerhetsfrågan, omformulerad ärligt

 

Alla som specificerar MIFARE Classic idag borde arbeta utifrån den nuvarande forskningspositionen snarare än det rykte som plattformen hade för ett decennium sedan.

 

År 2024 besegrade en studie av FM11RF08S, ett MIFARE Classic-kompatibelt chip som släpptes 2020 med motåtgärder speciellt utformade för att motstå alla kända-kort attacker, dessa motåtgärder och avslöjade en hårdvarubakdörr i processen. Bakdörren gör det möjligt för alla parter som är medvetna om det att äventyra varje användardefinierad-nyckel på kortet inom några minuter efter fysisk åtkomst, och detta gäller även där nycklar har diversifierats helt per kort (Kryptologi ePrint-arkiv). Relaterade bakdörrsnycklar identifierades över en bredare uppsättning delar, inklusive tidigare Fudan-generationer och specifika NXP- och Infineon-enheter.

 

Läs det noga innan du drar fel slutsatser av det. Detta är inte ett argument för att alla som använder MIFARE Classic är exponerade imorgon, och vi presenterar det inte som ett. Miljontals klassiska referenser fungerar i miljöer med låg-konsekvens där kloning av ett kort ger en angripare tillgång till ett gymskåp. Det är ett argument att frasen "säker" inte ska förekomma någonstans i ett specifikationsdokument vid sidan av denna chipfamilj, och att alla som ska programmera NFC-taggar för hotellrum, kontorsåtkomst eller kontantlös betalning på Classic silicon bör prissätta en migrering till en AES-baserad del i samma budgetcykel.

 

Programmera NFC-taggar i bulk: vad som förändras över tusen enheter

 

Allt som beskrivits hittills skalar dåligt. En telefonapp skriver en tagg i taget utan batchpost, inget verifieringspass och inget sätt att bevisa efteråt vilken URL som gick till vilken fysisk enhet. Det finns tre nivåer för hur man programmerar NFC-taggar i bulk, och hoppet mellan dem är operativt snarare än tekniskt.

 

Den första nivån är en telefon och en app, genomförbar för ungefär hundra enheter, lämpliga för prototyper och interna piloter.

 

Den andra nivån är där de flesta inom-husteam landar: du programmerar NFC-taggar med en läsarskrivare på ett skrivbord, driven av en batchfil, vanligtvis genom en USB-kodare i klassen ACR12xx eller uTrust. Det fungerar bra tills chippet ändras. Det flitigt använda batchverktyget med öppen-källkod i det här utrymmet, till exempel, riktar sig specifikt mot ACR122 och kodar bara MIFARE Ultralight och Ultralight C, som är typ 2-delar, så att flytta projektet till ett typ 4-chip innebär att man bygger om verktyget istället för att redigera en konfigurationsfil. Om du fortfarande väljer hårdvara för denna nivå, vårUSB- och stationär NFC-läsare-skrivaretäcker läsarmodellerna som dessa verktygskedjor förväntar sig.

 

Branschpraxis för den tredje nivån är för-förkodning under tillverkningen, och detta är den nivå som de flesta köpare inte vet finns. På våra linjer i en 3 600 m² stor anläggning sitter kodning mellan chipbondning och slutmontering, på utrustning som indexerar varje tagg på plats, skriver posten och läser tillbaka den innan taggen går vidare. Verifieringspasset är hela poängen. En tagg som misslyckas med att läsa-tillbaka avvisas i-rad snarare än att en kund upptäcker den på fältet, och partiet lämnas med en mappningsfil som länkar varje UID eller TID till det exakta innehållet som skrivits till den, vilket är vad din CMS eller analysplattform behöver dag ett. Automatiserad bindningskapacitet över fem produktionslinjer går över 100 000 chips per dag, så kodning blir inte begränsningen för ledtiden.

 

Vad den beskrivningen utelämnar, medvetet, är acceptanströskeln. Återläsnings-bekräftelse är en godkänd/misslyckad gate, men felfrekvensen du bör acceptera enligt avtalet skiljer sig åt beroende på chipfamilj, formfaktor och om taggen lamineras efteråt; en anti-dekal och ett PVC-kort beter sig inte på samma sätt på samma linje. Det numret hör hemma i ett citat mot ditt specifika bygge, inte i en artikel, och det är det första vi ställer in när ett nytt program startar.

 

Var vi drar vår egen kapacitetsgräns är värt att uttrycka tydligt, eftersom det är den del som leverantörer vanligtvis suddar ut. Vi kommer att för-programmera NFC-taggar med din webbadressmall, serialisera per enhet, verifiera varje tagg och leverera mappningsfilen. Vi tillhandahåller AES-nycklar som du tillhandahåller. Vi kommer inte att hålla dina produktionsnycklar, vi kommer inte att använda din valideringsbackend och vi kommer inte att berätta för dig att en fabrik kan göra en applikations-säkerhetsdesign korrekt. Den delen är din, och varje leverantör som påstår något annat säljer dig en risköverföring som inte existerar.

 

Nio frågor att lösa innan kodningskörningen

 

Kör detta före inköpsordern, inte efter att proverna anländer. Varje föremål har avslutat minst ett projekt som vi har blivit ombedda att rädda.

 

#	Fråga	Varför det avgör chipet
1	Kommer iPhones att trycka på dessa taggar?	Tar bort MIFARE Classic helt och hållet
2	Vad är den fullständiga webbadressens längd, inklusive framtida parametrar?	Ställer golvet på NTAG213, 215 eller 216
3	Räcker det med en post, eller behöver du också en textpost eller apppost?	Ytterligare poster förbrukar samma minnesbudget
4	Kommer destinationen att ändras under taggens livslängd?	Avgör om låsning någonsin är acceptabel
5	Gör applikationen ett autenticitetsanspråk till slutanvändare?	Skickar dig till NTAG 424 DNA eller DESFire
6	Vem håller och roterar AES-nycklarna?	Måste tilldelas innan någon knapp ändras
7	Vilket är acceptanskriteriet för en levererad batch?	Definierar om läs-tillbaka verifiering är avtalsenlig
8	Behöver du en UID-till-innehållsmappningsfil?	Måste specificeras före körningen, inte efterfrågas
9	Är originalitetssignaturverifiering en del av inkommande kvalitetskontroll?	Bestämmer om chipsourcing är granskningsbar

 

Lag som kan svara på alla nio får vanligtvis en ren produktionskörning vid första försöket. Lag som kan svara sex av nio upptäcker vanligtvis de återstående tre på ett dyrt sätt.

 

De nio frågorna är den generiska versionen. Den vi faktiskt arbetar utifrån lägger till en tionde kolumn, svaret som är rätt för din konstruktion snarare än i allmänhet, och den kolumnen beror på saker som den här artikeln inte kan se: din telefonmix, din läsare, din lamineringsprocess och om serialisering måste vara sekventiell eller slumpmässig. Skicka oss de första nio svaren så returnerar vi den kommenterade versionen mot din specifikation.

 

Var detta lämnar en köpare

 

Det finns ingen generell procedur för hur man programmerar NFC-taggar, bara en procedur per chip, per plattform, per volym. Välj chippet mot minnestaket och iPhone-frågan först. Behandla formatering, nyttolast och konfiguration som tre separata grindar. Lås aldrig före ett fältförsök. Verifiera originalitet på inkommande prover. Över tusen enheter, sluta tänka på appar och börja tänka på verifiering och spårbarhet.

 

Om en specifikation redan är utarbetad, granskar vi gärna den mot chipbegränsningarna ovan och flaggar allt som inte kommer att överleva produktionen, och gratisprover finns tillgängliga för testning på dina faktiska läsare och telefoner. Du kan också börja frånNFC-taggformat vi för-programmerar och verifierar internt.-om chipbeslutet fortfarande är öppet, ellerskicka URL-strukturen och målvolymen för en kodningsgranskningom det redan är fixat.

 

FAQ