Hvordan programmere NFC-tagger med forskjellige brikketyper (NTAG, MIFARE og mer)

 

Å skrive en tag er tre separate operasjoner, ikke én

 

Når folk sier at de vil programmere NFC-tagger, beskriver de vanligvis tre forskjellige ting som tilfeldigvis utløses av den samme knappen i en telefonapp.

 

Den første erformatering. En NFC-brikkes minne må fortelles at brukerområdet inneholder en NDEF-melding i stedet for vilkårlige byte. Dette gjøres ved å skrive en liten datastruktur kjent som evnebeholderen. På NTAG21x-deler gjøres dette allerede på wafernivå, så brikken ankommer NDEF-formatert og kan bare holde NDEF. På MIFARE Classic og noen andre brikker er formatering noe du utfører, og strukturen lander i en-gang-programmerbar region. Formatering er derfor permanent. Det er ingen unformat kommando, og ingen leverandørverktøy som vil gi deg en.

 

Det andre erskrive nyttelasten: en NDEF-melding som inneholder en eller flere poster, oftest en URI-post som peker på en URL. Dette er delen alle bilder. Nyttelastskrivninger er normalt repeterbare, og det er grunnen til at et markedsføringsteam kan omdirigere en kampanjetag seks måneder senere uten å ombestille maskinvare.

 

Den tredje erkonfigurasjon: passordbytes, låsebiter, speilinnstillinger, tilgangsbetingelser, autentiseringsnøkler. Dette laget er der de irreversible beslutningene bor, og det er laget som ingen forbrukerveiledning berører i det hele tatt. Hvis du planlegger å programmere NFC-tagger for noe med en sikkerhetsgrense rundt seg, er konfigurasjonslaget prosjektet.

 

Å holde disse tre adskilt i hodet ditt er det som stopper en batch fra å bli skrotet. De fleste skrivefeil vi diagnostiserer er ikke nyttelastfeil. De er en formateringstilstand eller en konfigurasjonstilstand som noen ikke visste eksisterte.

 

NFC-brikketyper sammenlignet før du programmerer dem

 

Hver seriøs avgjørelse om hvordan du skal programmere NFC-tagger starter med denne tabellen, fordi minnetak og plattformstøtte er satt i øyeblikket av brikkevalg og kan ikke lappes senere i programvare.

 

Chip	Brukerminne	NFC-forumtype	Fabrikk NDEF tilstand	Passord-/nøkkelbeskyttelse	iPhone NDEF lese + skrive
NTAG 213	144 byte	Type 2	Forhånds-formatert	32-bit PWD / 16-bit PACK	Ja
NTAG 215	504 byte	Type 2	Forhånds-formatert	32-bit PWD / 16-bit PACK	Ja
NTAG 216	888 byte	Type 2	Forhånds-formatert	32-bit PWD / 16-bit PACK	Ja
MIFARE Ultralight EV1	48 eller 128 byte	Type 2	Formattable	32-bit PWD / 16-bit PACK	Ja
MIFARE Classic 1K	1 024 byte totalt, omtrent 716 tilgjengelig for NDEF når produsentblokken og 16 sektortilhengere er trukket fra	Ikke en NFC-forumtype	Formaterbar, sektor-basert	CRYPTO-1 sektornøkler A/B	Ingen
MIFARE DESFire EV3	2 KB til 8 KB, fil-basert	Type 4	Søknad må opprettes	AES-128 / 3DES, tilgangsrettigheter per fil	Ja
NTAG 424 DNA	416 byte totalt, delt inn i en 32-byte-kapasitetsbeholder, en 256-byte NDEF-fil og en 128-byte beskyttet datafil	Type 4	Forhånds-klargjorte filer	Fem AES-128-nøkler, 3-pass gjensidig autentisering	Ja

 

NTAG21x-tall, lås-bit-oppførsel og Type 2/ISO/IEC 14443 Type A-samsvar iht.NXP NTAG213/215/216 produktdatablad. MIFARE Classic 1K-struktur per NXP-datablad MF1S50yyX (16 sektorer × 4 blokker × 16 byte). DESFire EV3 per MF3D(H)x3. NTAG 424 DNA-minneoppsett prNXP.

 

To kolonner bestemmer de fleste prosjekter før noen programvare velges: minnetaket og iPhone-søylen. Det tabellen ikke kan fortelle deg er avkastning. En korrekt spesifisert brikke produserer fortsatt avvisninger hvis kodingstrinnet ikke har noen bekreftelsespass bak seg, som er temaet i andre halvdel av denne artikkelen.

 

NTAG 213, 215 og 216: Standardvalget og dets virkelige tak

 

For omtrent fire av fem innkommende prosjekter er denne familien det rette svaret, og å lære hvordan du programmerer NTAG 215 NFC-tagger tar omtrent nitti sekunder med en telefonapp. Brikken sendes NDEF-formatert, posttypen som oppfører seg konsekvent på tvers av alle håndsett er en vanlig URI-post, og både Android og iOS skriver den uten at SDK fungerer.

 

 

Det er også familien bak nesten alle digitale visittkortprogram, der et enkelt vCard- eller URL-oppføring er hele nyttelasten, og hvor det fysiske formatet vanligvis betyr mer enn brikken. De fleste av disse bestillingene ender opp påtomme hvite PVC NFC-kortheller enn klistremerker, fordi kortet må overleve en lommebok og ta en utskrift.

 

Taket kommer raskere enn folk forventer. NTAG213 gir deg 144 byte med brukerminne, og en NDEF-melding er ikke bare URL-en din. Det er en TLV-innpakning, en postoverskrift, et typefelt og et lengdefelt før et enkelt tegn i adressen din lagres. En URI-post komprimerer vanlige prefikser som f.ekshttps://www.til en enkelt byte, som gjenoppretter ti til tjue byte, og på en 144-bytedel er denne forskjellen grensen mellom tilpasning og feil. Der team blir fanget, er ikke URL-en i seg selv, men ekstrautstyret: legg til en tekstpost for en menneskelig lesbar etikett, legg til en Android Application Record slik at taggen åpner en app i stedet for en nettleser, og en komfortabel nyttelast blir en overløpsfeil.

 

Vår egen tommelfingerregel, og dette er den typen ting du bare lærer ved å kode noen få millioner av disse: hvis den tiltenkte nettadressen inkludert søkeparametere overstiger ca. 90 tegn, slutt å spesifisere NTAG213 og gå opp. Enhetskostnadsforskjellen mellom 213 og 215 er liten nok til at det nesten aldri er verdt risikoen med et redesign-midtprogram. En kampanje som senere ønsker å legge til UTM-parametere eller et serienummer til hver tag-URL, vil treffe veggen på 213 og vil ikke treffe den på 215.

 

Passordbeskyttelse på denne familien er verdt å forstå nøyaktig, fordi den er svakere enn ordet "passord" antyder. En 32-biters PWD-verdi overføres i klarteksten og sjekkes av brikken, som gir skrivetilgang og eventuelt lesetilgang fra en valgt side og fremover. Det stopper et nysgjerrig medlem av offentligheten fra å skrive om taggen din med en telefon. Det er ikke en kryptografisk kontroll og bør aldri beskrives for en klient som en. Merk også at ikke alle generasjoner støtter det i det hele tatt: den eldre NTAG203 har ingen passordmekanisme overhodet, og bibliotekdokumentasjonen er eksplisitt at beskyttelsesoppfordringer mot den rett og slett mislykkes (nfcpy dokumentasjon).

 

MIFARE Classic: Skrivbar på Android, fraværende på iPhone

 

Her er kompatibilitetsfellen som har avsluttet flere NFC-prosjekter enn noen annen enkeltfaktor. Alle som spør hvordan man skriver NDEF til MIFARE Classic, jobber allerede mot strukturen i formatet: MIFARE Classic er ikke en NFC Forum-tagtype, det er et ISO/IEC 14443-3A-kort med en proprietær sektor og nøkkelstruktur som går før NDEF-økosystemet, og NDEF-støtte på det eksisterer bare gjennom en kartleggingskonvensjon lagt på toppen.

 

 

Android håndterer denne konvensjonen. iOS gjør det ikke. Apples Core NFC har aldri støttet MIFARE Classic, med plattformens støttede MIFARE-familier begrenset til Ultralight, Plus og DESFire, en posisjon utviklere har bekreftet gjentatte ganger på Apples egne fora (Apple utviklerforum). Fordi iOS ikke kan adressere kortets minne direkte, kan ikke en iPhone skrive NDEF til det og ikke vise NDEF som er lagret på det.

 

Det som gjør dette så farlig under evaluering er at MIFARE Classic-tagger ikke vises døde på en iPhone. Kortet presenterer en ISO 14443-A UID, så snarveier-appen vil gjerne godta det som en automatiseringsutløser, og bakgrunnsskanning kan fortsatt starte en tidligere lagret NDEF-post av en støttet type. En innkjøpsleder som tester en prøve på sin iPhone, ser et svar og kvitterer. Atferden de så hadde ingenting å gjøre med taggens minneinnhold, og hele tilnærmingen kollapser i det øyeblikket prosjektet trenger nettadresser per enhet som iPhones faktisk kan lese.

 

Den praktiske regelen som faller ut av dette: alle som sammenligner hvordan man programmerer NFC-tagger for iPhone vs Android bør kjøre aksepttesting på begge plattformene med produksjonsbrikken, aldri på Android alene, og aldri på en prøve av en annen brikke enn den på innkjøpsordren.

 

La meg være rett ut om anbefalingen, for "det avhenger av din brukstilfelle" er ikke et nyttig svar her. Hvis NFC-taggene dine vil bli avlyttet av publikum, spesifiser alt unntatt MIFARE Classic.

 

For team som allerede er inne i et klassisk-basert tilgangssystem, reduseres beslutningen til én variabel, og det er ikke kodene. Det er den gjenværende levetiden til din lesereiendom. Hvis disse leserne har to eller tre år igjen og ingen smarttelefon noen gang vil røre legitimasjonen, er det en forsvarlig samtale å fortsette med Classic i en lukket sløyfe, og de praktiske spørsmålene blir IC-kilde og UID-format i stedet for kodingsmetode, som er det vi dekker i notatene våre ombestille MIFARE 1K-brikker til et installert system. Hvis leserne selv skal byttes i det vinduet, ikke bruk penger på en overgangslegitimasjon. Flytt hele eiendommen til en AES-basert del i ett trinn og absorber kostnadene én gang.

 

Det er en annen felle i samme familie, subtil nok til at den overlever hele QA-sykluser. Ved å legge til en Smart Poster-omslag til en post, som de vanlige kodingsverktøyene tilbyr som en vennlig måte å legge ved en tittel til en URL, endres posttypen. Poster pakket inn på den måten blir ikke fanget opp av iOS-bakgrunnsskanning i det hele tatt, uavhengig av hva som er nestet inni. Android-testing passerer på alle enheter, iPhones gjør ingenting, og det er ingen feilmelding noe sted å diagnostisere.

 

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

 

MIFARE Ultralight EV1 sitter nær NTAG21x i oppførsel og du programmerer NFC-tagger på den på samme måte, med et mindre minnebudsjett på 48 eller 128 byte og samme klasse passordport. Ingenting konseptuelt nytt skjer.

 

DESFire og NTAG 424 DNA er en annen disiplin. På disse Type 4-delene skriver du ikke byte til et flatt minnekart, du opererer på et filsystem med per-filtilgangsrettigheter, og hver meningsfull operasjon krever autentisering med en AES-128-nøkkel først. NTAG 424 DNA har fem kundedefinerte AES-nøkler, bruker 3-pass gjensidig autentisering for den beskyttede datafilen, og har Common Criteria EAL4-sertifisering på både maskinvare og programvare. Lag som programmerer NFC-tagger for produktautentisering i stedet for enkel omdirigering, leter vanligvis etter denne delen spesifikt på grunn av én funksjon.

 

Denne funksjonen er Secure Dynamic Messaging, ofte skrevet som SUN. Når den er aktivert, endres NDEF-URL-en brikken presenterer ved hvert enkelt trykk: brikken speiler UID-en og en monotont økende leseteller inn i URL-en, eventuelt kryptert, og legger til en CMAC beregnet med en nøkkel bare du og brikken har. Din backend kan da fortelle en ekte tag fra en fotografert URL, og kan fortelle trykk nummer 4 fra trykk nummer 4000.

 

Å konfigurere den riktig er der spesifikasjonen biter. Speilreglene er ikke gratis-: når PICC-dataene er kryptert, blir speiling av UID og lesetelleren obligatorisk i stedet for valgfri, de to reiser alltid sammen, og CMAC-en må sitte på slutten av NDEF-meldingen. Design URL-strukturen din rundt disse begrensningene, ikke omvendt, ellers vil forskyvningene ikke løses, og backend vil avvise hver lesing.

 

Feilen vi ser oftest på SUN-utplasseringer har ingenting med det å gjøre. Alle offentlige referanseimplementeringer og demoservere leveres konfigurert med fabrikk-standard alle-nullnøkler, fordi det er det som får en demo til å fungere rett fra esken. Prosjekterer prototypen mot det, prototypen fungerer, og nøkkelrotasjonstrinnet kommer aldri inn på lanseringssjekklisten. Taggene går ut kryptografisk nakne mens alle involverte tror distribusjonen er kryptert, og det er grunnen til at vår egen prøveutgivelsesprosedyre sjekker nøkkeldiversifisering på produksjonsenhetene i stedet for på det som ble brukt til demoen.

 

Seks operasjoner du ikke kan reversere når du først har programmert NFC-tagger

 

Nyttelastomskrivinger er billige. Disse er ikke det. Hver av dem nedenfor er en avgjørelse som konverterer et parti med tagger til et anleggsmiddel, og hver enkelt har vært årsaken til utrangert beholdning vi personlig har måttet erstatte.

 

Operasjon	Hva den gjør	Hvorfor det ikke kan angres	Når det skal planlegges
NDEF-formatering	Skriver evnebeholderen	Lander i én-gang-programmerbart minne	På fabrikken, etter at brikketypen er bekreftet
Statiske låsbits	Låser de første 16 sidene på Type 2-brikker	Låsebiter angis bare-og kan ikke tilbakestilles	Først etter at endelig innhold er avskrevet
Dynamiske låsebiter	Dekk 96 databyte på NTAG213, 456 på NTAG215 og 840 på NTAG216, med en granularitet på 2 sider på NTAG213 og 16 sider på NTAG215 og NTAG216, i henhold til NXP-dataarket sitert ovenfor	Samme sett-bare mekanisme, samme varighet	Samme port som statiske låser
-skrivebeskyttet bryter	Setter NDEF skriveflagget permanent	Det finnes ingen invers kommando	Aldri før fullført feltprøve
LRP-modus på NTAG 424 DNA	Bytter AES til lekkasje-fjærende drift	Aktivert av SetConfiguration, uten vei tilbake til AES-modus	Bare hvis en dokumentert trusselmodell krever det
Nøkkelbytte uten deponering	Erstatter fabrikkens AES-nøkler	Brikken har ingen gjenopprettingsbane hvis den nye nøkkelen går tapt	Bare én gang nøkkelforvaring er formelt tildelt

 

Denne sidegranulariteten er den praktiske detaljen de fleste savner når de spør hvordan man låser en NFC-tag etter programmering. Låsing er ikke en enkelt alt-eller-ingenting-bryter. På NTAG215 og NTAG216 kan du låse blokker på 16 sider, noe som gjør en blandet layout levedyktig: en serienummerregion låst på fabrikken, en kampanje-URL-region som er skrivbar for markedsføringsteamet. På NTAG213 er granulariteten to sider, finere, men over et mye mindre kart. Å bestemme grensen er en designoppgave, og det må skje før kodingskjøringen, ikke etter.

 

Vanen som er verdt å bygge er å skille kodeporten fra låseporten. Vi fraråder kundene å låse ved bestilling, og årsaken er utelukkende kommersiell enn teknisk.

 

I bestillingsloggen vår er den hyppigste post{0}}leveringsforespørselen ikke et defektkrav, det er en destinasjonsendring, og den samles i det første tjenesteåret. De vanlige triggerne er en destinasjonssidemigrering eller en byråoverlevering, ingen av disse er synlige når bestillingen legges inn. Du trenger ikke noens feilstatistikk for å handle på dette, fordi asymmetrien avgjør det på egen hånd: en ulåst brikke som aldri trenger å endres koster deg ingenting, mens en låst brikke som må endres koster en full erstatningsordre pluss reinstallasjonsarbeidet. Programmer NFC-tagger først, kjør feltprøven, lås etterpå.

 

Å bekrefte at brikken er det fakturaen sier

 

 

Autentisitet for brikke er ikke en paranoid bekymring i denne kategorien, det er et rutinemessig innkommende-inspeksjonselement, og det hører hjemme i samme QC-trinn som alle andre kontroller du kjører før du programmerer NFC-tagger i produksjonsmengder. NXPs NTAG-, MIFARE-, Ultralight- og ICODE-familier har hver en ECC-basert originalitetssignatur skrevet ved brikkeproduksjon, 32 byte på NTAG21x-deler, som kan leses tilbake og verifiseres mot produsentens offentlige nøkkel. En merkelapp som oppfører seg perfekt kan fortsatt mislykkes i den kontrollen.

 

Dette skjer mer enn markedet innrømmer. Ingeniører som kjøper NTAG21x-tagger gjennom generelle detaljhandelskanaler har rapportert til produsentens eget fellesskap at prøver fungerer nøyaktig som spesifisert, tellerspeiling inkludert, men rapporterer som klonet silisium under originalitetsverifisering, og NXPs publiserte svar er at slike deler ikke støttes og er uegnet for sikker bruk fordi selve IC-en kan være sårbar (NXP-fellesskap).

 

Den operative konsekvensen er snevrere enn folk antar, og verdt å angi presist. Hvis applikasjonen din er en markedsføringsomdirigering, vil en klonebrikke tjene deg tilstrekkelig, og du bryr deg kanskje ikke. Hvis søknaden din involverer autentisering, manipulasjonsbevis eller ethvert krav om anti-forfalskning overfor din egen kunde, vil en ukontrollerbar brikke ugyldiggjøre hele premisset, og ingen mengde korrekt koding kompenserer for det. Bekreftelsen tar sekunder per prøve med en leserapp, og den hører hjemme i den innkommende QC-prosedyren din i stedet for i et post{4}}mortem. Relatert lesing for alle hvis skriving er fullført, men hvis leser tier:hvorfor et klonet klistremerke leser fint og fortsatt feiler ved døren.

 

Det klassiske MIFARE-sikkerhetsspørsmålet, gjengitt ærlig

 

Alle som spesifiserer MIFARE Classic i dag bør jobbe fra den nåværende forskningsposisjonen i stedet for ryktet plattformen hadde for et tiår siden.

 

I 2024 beseiret en studie av FM11RF08S, en MIFARE Classic-kompatibel brikke utgitt i 2020 med mottiltak spesielt utviklet for å motstå alle kjente-kortangrep, disse mottiltakene og avdekket en maskinvarebakdør i prosessen. Bakdøren lar enhver part som er klar over det kompromittere hver bruker-definert nøkkel på kortet i løpet av minutter etter fysisk tilgang, og dette gjelder selv der nøklene har blitt fullstendig diversifisert per kort (Kryptologi ePrint-arkiv). Relaterte bakdørsnøkler ble identifisert på tvers av et bredere sett med deler, inkludert tidligere Fudan-generasjoner og spesifikke NXP- og Infineon-enheter.

 

Les det nøye før du trekker feil konklusjon av det. Dette er ikke et argument for at alle som bruker MIFARE Classic blir eksponert i morgen, og vi presenterer det ikke som ett. Millioner av klassiske legitimasjoner opererer i miljøer med lav-konsekvens der kloning av et kort gir en angriper tilgang til et treningsskap. Det er et argument at uttrykket "sikker" ikke skal vises noe sted i et spesifikasjonsdokument ved siden av denne brikkefamilien, og at alle som skal programmere NFC-tagger for hotellrom, kontortilgang eller kontantløs betaling på klassisk silisium bør prise en migrering til en AES-basert del inn i samme budsjettsyklus.

 

Programmere NFC-tagger i bulk: Hva endres over tusen enheter

 

Alt beskrevet så langt skalerer dårlig. En telefonapp skriver én tagg om gangen uten batch-oppføring, ingen bekreftelsespass, og ingen måte å bevise etterpå hvilken URL som gikk til hvilken fysisk enhet. Det er tre nivåer for hvordan man programmerer NFC-tagger i bulk, og hoppet mellom dem er operasjonelt snarere enn teknisk.

 

Det første nivået er en telefon og en app, levedyktig til omtrent hundre enheter, egnet for prototyper og interne piloter.

 

Det andre nivået er der de fleste-husteam lander: du programmerer NFC-tagger med en leserskriver på et skrivebord, drevet av en batchfil, vanligvis gjennom en USB-koder i ACR12xx- eller uTrust-klassen. Det fungerer bra helt til brikken endres. Det mye brukte batchverktøyet med åpen-kildekode i dette området, for eksempel, retter seg spesifikt mot ACR122 og koder bare MIFARE Ultralight og Ultralight C, som er Type 2-deler, så å flytte prosjektet til en Type 4-brikke betyr å gjenoppbygge verktøyet i stedet for å redigere en konfigurasjonsfil. Hvis du fortsatt velger maskinvare for dette nivået, vårUSB- og stasjonær NFC-leser-skriverseriedekker lesermodellene disse verktøykjedene forventer.

 

Bransjepraksis for det tredje nivået er forhånds-koding under produksjon, og dette er nivået de fleste kjøpere ikke vet eksisterer. På våre linjer i et 3600 m² stort anlegg, sitter koding mellom chip bonding og sluttmontering, på utstyr som indekserer hver tag på plass, skriver posten og leser den tilbake før taggen går videre. Bekreftelsespasset er hele poenget. En tag som ikke kan leses-tilbake, avvises på-linjen i stedet for å oppdages av en kunde i felten, og partiet forlater med en kartleggingsfil som kobler hver UID eller TID til det nøyaktige innholdet som er skrevet til den, som er det CMS- eller analyseplattformen din trenger på dag én. Automatisert bindingskapasitet på tvers av fem produksjonslinjer går over 100 000 brikker per dag, så koding blir ikke begrensningen på ledetid.

 

Det den beskrivelsen utelater, bevisst, er akseptterskelen. Tilbakelesing-bekreftelse er en bestått/feil-port, men feilfrekvensen du kontraktmessig bør akseptere varierer etter brikkefamilie, formfaktor og om taggen blir laminert etterpå; et anti-metall-klistremerke og et PVC-kort oppfører seg ikke på samme måte på samme linje. Dette tallet hører hjemme i et sitat mot din spesifikke konstruksjon, ikke i en artikkel, og det er det første vi setter når et nytt program starter.

 

Hvor vi trekker vår egen kapasitetsgrense er verdt å si tydelig, fordi det er delen leverandørene vanligvis uskarpe. Vi vil forhånds-programmere NFC-tagger med URL-malen din, serialisere per enhet, verifisere hver tagg og levere kartfilen. Vi vil levere AES-nøkler du leverer. Vi beholder ikke produksjonsnøklene dine, vi vil ikke betjene valideringsstøtten din, og vi vil ikke fortelle deg at en fabrikk kan gjøre en applikasjons-sikkerhetsdesign korrekt. Den delen er din, og enhver leverandør som hevder noe annet, selger deg en risikooverføring som ikke eksisterer.

 

Ni spørsmål å løse før kodingskjøringen

 

Kjør dette før innkjøpsordren, ikke etter at prøvene kommer. Hver gjenstand har avsluttet minst ett prosjekt vi har blitt bedt om å redde.

 

#	Spørsmål	Hvorfor det bestemmer brikken
1	Vil iPhones trykke på disse taggene?	Fjerner MIFARE Classic helt fra vurderingen
2	Hva er hele URL-lengden, inkludert fremtidige parametere?	Setter gulvet på NTAG213, 215 eller 216
3	Er én post nok, eller trenger du også en tekstpost eller app-post?	Ytterligere poster bruker samme minnebudsjett
4	Vil destinasjonen endres i løpet av taggens levetid?	Avgjør om låsing noen gang er akseptabel
5	Gir applikasjonen et autentisitetskrav til sluttbrukere?	Skyver deg til NTAG 424 DNA eller DESFire
6	Hvem holder og roterer AES-nøklene?	Må tildeles før noen tast endres
7	Hva er akseptkriteriet for en levert batch?	Definerer om tilbakelesning-er kontraktfestet
8	Trenger du en UID-til-innholdskartleggingsfil?	Må spesifiseres før kjøring, ikke forespurt etter
9	Er originalitetssignaturverifisering en del av innkommende kvalitetskontroll?	Bestemmer om chip sourcing er reviderbar

 

Lag som kan svare på alle ni får vanligvis en ren produksjon på første forsøk. Lag som kan svare seks av ni, oppdager vanligvis de resterende tre på den dyre måten.

 

De ni spørsmålene er den generiske versjonen. Den vi faktisk jobber fra legger til en tiende kolonne, svaret som er riktig for din konstruksjon i stedet for generelt, og den kolonnen avhenger av ting denne artikkelen ikke kan se: håndsettmiksen din, lesergodset, lamineringsprosessen din og om serialisering må være sekvensiell eller tilfeldig. Send oss ​​de første ni svarene, og vi vil returnere den kommenterte versjonen mot spesifikasjonen din.

 

Hvor dette etterlater en kjøper

 

Det er ingen generell prosedyre for hvordan du programmerer NFC-tagger, kun en prosedyre per brikke, per plattform, per volum. Velg brikken mot minnetaket og iPhone-spørsmålet først. Behandle formatering, nyttelast og konfigurasjon som tre separate porter. Lås aldri før en feltprøve. Bekreft originalitet på innkommende prøver. Over tusen enheter, slutt å tenke på apper og begynn å tenke på verifisering og sporbarhet.

 

Hvis en spesifikasjon allerede er utarbeidet, vurderer vi den gjerne mot brikkebegrensningene ovenfor og flagger alt som ikke vil overleve produksjonen, og gratis prøver er tilgjengelige for testing på dine faktiske lesere og telefoner. Du kan også starte fraNFC-tag-formater vi forhånds-programmerer og bekrefter-hjemmehvis chip-avgjørelsen fortsatt er åpen, ellersend URL-strukturen og målvolumet for en kodingsgjennomganghvis det allerede er fikset.

 

FAQ