AN451
TRÅDLØS M-BUS PROGRAMVARE IMPLEMENTERING

Introduksjon

Dette applikasjonsnotatet beskriver Silicon Labs-implementeringen av Wireless M-Bus ved bruk av en Silicon Labs C8051 MCU og EZRadioPRO®. Wireless M-bus er en europeisk standard for måleravlesningsapplikasjoner som bruker 868 MHz frekvensbåndet.

Stable lag

Wireless M-Bus bruker 3-lags IEC-modellen, som er en undergruppe av 7-lags OSI-modellen (se figur 1).

Det fysiske (PHY) laget er definert i EN 13757-4. Det fysiske laget definerer hvordan bitene kodes og overføres, RF-modemets egenskaper (brikkehastighet, preambel og synkroniseringsord) og RF-parametere (modulasjon, senterfrekvens og frekvensavvik).
PHY-laget er implementert ved hjelp av en kombinasjon av maskinvare og fastvare. EZRadioPRO utfører alle RF- og modemfunksjonene. EZRadioPRO brukes i FIFO-modus med pakkebehandleren. MbusPhy.c-modulen gir SPI-grensesnitt, koding/dekoding, blokklesing/skriving og pakkehåndtering og administrerer transceivertilstandene.
M-Bus Datalink-laget er implementert i MbusLink.c-modulen. M-Bus Application Programming-grensesnittet består av offentlige funksjoner som kan kalles opp fra applikasjonslaget i hovedtråden. MbusLink-modulen implementerer også Data Link Layer. Datalinklaget vil formatere og kopiere data fra applikasjonens TX-buffer til MbusPhy TX-bufferen, og legge til de nødvendige overskriftene og CRC-ene.
Selve applikasjonslaget er ikke en del av M-bus-fastvaren. Applikasjonslaget definerer hvordan et bredt utvalg av data skal formateres for overføring. De fleste målere trenger bare å overføre én eller to typer data. Å legge til en stor mengde kode for å imøtekomme alle typer data til måleren vil legge til unødvendig kode og kostnader til måleren. Det kan være mulig å implementere et bibliotek eller en header file med en uttømmende liste over datatyper. Imidlertid vet de fleste målerkunder nøyaktig hva slags data de trenger å overføre og kan referere til standarden for formateringsdetaljer. En universell leser eller sniffer kan implementere et komplett sett med applikasjonsdatatyper på PC GUI. Av disse grunner implementeres applikasjonslaget ved å bruke example applikasjoner for en måler og leser.

Påkrevde standarder

1. EN 13757-4
   EN 13757-4
   Kommunikasjonssystem for målere og fjernavlesning av målere
   Del 4: Trådløs måleravlesning
   Radiometeravlesning for drift i 868 MHz til 870 MHz SRD-båndet
2. EN 13757-3
   Kommunikasjonssystem for målere og fjernavlesning av målere
   Del 3: Dedikert påføringslag
3. IEC 60870-2-1:1992
   Fjernkontroll utstyr og systemer
   Del 5: Overføringsprotokoller
   Seksjon 1: Linkoverføringsprosedyre
4. IEC 60870-1-1:1990
   Fjernkontroll utstyr og systemer
   Del 5: Overføringsprotokoller
   Seksjon 1: Overføringsrammeformater

Definisjoner

• M-buss—M-Bus er en kablet standard for måleravlesning i Europa.
• Trådløs M-buss—Trådløs M-Bus for måleravlesningsapplikasjoner i Europa.
• PHY— Physical Layer definerer hvordan databiter og byte kodes og overføres.
• API—Application Programmer grensesnitt.
• LINK—Data Link Layer definerer hvordan blokker og rammer overføres.
• CRC—Syklisk redundanssjekk.
• FSK—Frekvensskifttasting.
• Chip—Minste enhet av overførte data. Én databit er kodet som flere brikker.
• Modul—AC-kodekilde .c file.

M-Bus PHY funksjonsbeskrivelse

Innledningssekvens

Innledningssekvensen spesifisert av M-bus-spesifikasjonen er et heltall som veksler mellom nuller og enere. En ener er definert som den høyere frekvensen, og en null er definert som den lavere frekvensen.
nx (01)
Innledningsalternativene for Si443x er et heltall av nibbles som består av alternerende enere og nuller.
nx (1010)
En ingress med en ekstra ledende ville ikke være noe problem, men da vil synkroniseringsordet og nyttelasten være feiljustert med én bit.
Løsningen er å invertere hele pakken ved å sette motorbiten i Modulation Control 2-registeret (0x71). Dette vil invertere preambelen, synkroniseringsordet og TX/RX-data. Som en konsekvens bør dataene inverteres når du skriver TX-data eller leser RX-data. Synkroniseringsordet inverteres også før skriving til Si443x Synchronization Word-registre.

Synkroniseringsord

Synkroniseringsordet som kreves av EN-13757-4 er enten 18 brikker for Mode S og Mode R eller 10 brikker for Model T. Synkroniseringsordet for Si443x er 1 til 4 byte. Imidlertid, siden synkroniseringsordet alltid innledes med preambelen, kan de siste seks bitene av preambelen betraktes som en del av synkroniseringsordet; så det første synkroniseringsordet er polstret med tre repetisjoner av en null etterfulgt av en ener. Synkroniseringsordet kompletteres før skriving til Si443x-registrene.
Tabell 1. Synkroniseringsord for modus S og modus R

EN 13757-4	00	01110110	10010110	binær
	00	76	96	hex
pute med (01) x 3	01010100	01110110	10010110	binær
	54	76	96	hex
komplement	10101011	10001001	01101001	binær
	AB	89	69	hex

Tabell 2. Synkroniseringsord for Mode T Meter til Annet

SYNK	SYNK	SYNK
ORD	ORD	ORD
3	2	1

Sende innledningslengde

Minimumsinnledningen er spesifisert for fire forskjellige driftsmoduser. Det er akseptabelt å ha en ingress som er lengre enn spesifisert. Å trekke fra seks sjetonger for innledningen gir minimum antall sjetonger for Si443x-innledningen. Implementeringen legger til to ekstra biter av innledning i alle korte innledningsmoduser for å forbedre innledningsdeteksjon og interoperabilitet. Innledningen på Mode S med lang ingress er veldig lang; så minsteinnledningen brukes. Innledningslengden i nibbles skrives til registeret Preambellengde (0x34). Innledningslengderegisteret bestemmer innledningen kun ved overføring. Innstillingene for minimumsspesifikasjon og innledningslengde er oppsummert i tabell 3.
Tabell 3. Sendeinnledningslengde

	EN-13757-4 minimum		Si443x Preamble Sett ing		Synkroniser Ord	Total	ekstra
	nx (01)	sjetonger	napper	sjetonger	sjetonger	sjetonger	sjetonger
Mode S kort ingress	15	30	8	32	6	38	8
Mode S lang ingress	279	558	138	552	6	558	0
Modus T (meter-annet)	19	38	10	40	6	46	8
Modus R	39	78	20	80	6	86	8

Minimum preamble for mottak bestemmes av Preamble Detection Control register (0x35). Ved mottak må antallet biter i synkroniseringsordet trekkes fra den spesifiserte minimumsinnledningen for å bestemme den brukbare innledningen. Minimum innstillingstid for mottakeren er 16 brikker hvis AFC er aktivert eller 8 brikker hvis AFC er deaktivert. Mottakerinnstillingstiden trekkes også fra den brukbare preamblen for å bestemme minimumsinnstillingen for preambledeteksjonskontrollregisteret.

Sannsynligheten for en falsk innledning avhenger av innstillingen til registeret for registrering av innledningsregistrering. En kort innstilling på 8-brikker kan føre til at en falsk preamble oppdages med noen sekunders mellomrom. Den anbefalte innstillingen på 20chips gjør deteksjon av falsk innledning til en usannsynlig hendelse. Innledningslengdene for Mode R og Mode SL er tilstrekkelig lange til at den anbefalte innstillingen kan brukes.
Det er svært liten fordel å få innledningen til å oppdage lengre enn 20 sjetonger.
AFC er deaktivert for Model S med en kort preambel og Model T. Dette reduserer mottakerinnstillingstiden og tillater en lengre innledningsdeteksjonsinnstilling. Med AFC deaktivert kan Mode T bruke den anbefalte innstillingen på 20 brikker. En innstilling på 4 nibbles eller 20 chips brukes for Model S med en kort ingress. Dette gjør sannsynligheten for en falsk innledningsdeteksjon litt høyere for denne modellen.
Tabell 4. Innledningsdeteksjon

	EN-13757-4 minimum		Synkroniser Ord	brukbar ingress	RX-oppgjør	Oppdag min	Si443x Preamble Deteksjonsinnstilling
	nx (01)	sjetonger	sjetonger	sjetonger	sjetonger	sjetonger	napper	sjetonger
Mode S kort ingress	15	30	6	24	8*	16	4	16
Model S lang ingress	279	558	6	552	16	536	5	20
Modell T (meter-annet)	19	38	6	32	8*	24	5	20
Modus R	39	78	6	72	16	56	5	20
*Note: AFC deaktivert

Mottakeren er konfigurert til å fungere sammen med en sender ved å bruke minimum spesifisert innledning. Dette sikrer at mottakeren vil fungere sammen med enhver M-bus-kompatibel sender.
Wireless M-Bus-spesifikasjonen krever en veldig lang preamble for Mode S1 på minst 558 brikker. Dette vil ta ca. 17 ms bare å sende innledningen. Si443x krever ikke en så lang ingress og har ikke nytte av den lange ingressen. Mens den lange ingressen er bemerket som valgfri for Mode S2, er det ingen grunn til å bruke en lang preambel med Si443x. Hvis enveiskommunikasjon er ønskelig, vil Mode T1 gi en kortere preamble, høyere datahastighet og lengre batterilevetid. Hvis toveiskommunikasjon ved bruk av Mode S2 er nødvendig, anbefales en kort ingress.
Legg merke til at deteksjonsterskelen for Model S med en lang preambel er lengre enn antallet innledningsnibbles som sendes for Model S med en kort preambel. Dette betyr at den lange innledningen Mode S-mottakeren ikke vil oppdage en preambel fra en kort innledningsmodus S-sender. Dette er nødvendig hvis den lange innledningen Mode S-mottakeren skal få noen fordel av den lange innledningen.
Merk at den korte innledningen Mode S-mottakeren vil oppdage innledningen og motta pakker fra både en kort innledning Mode S
sender og en lang innledning Mode S-sender; så generelt bør målerleseren bruke den korte innledningen Mode S-mottakerkonfigurasjonen.

Koding/Dekoding

Wireless M-bus-spesifikasjonen krever to forskjellige kodingsmetoder. Manchester-koding brukes for Mode S og Mode R. Manchester-koding brukes også for annen-til-meter-lenken i Model T. Model T meter-til-andre-lenken bruker 3 av 6 kodinger.
1. Manchester-kodet/dekoding
Manchester-koding er vanlig historisk i RF-systemer for å gi robust klokkegjenoppretting og sporing ved hjelp av et enkelt og rimelig modem. En moderne høyytelsesradio som Si443x trenger imidlertid ikke Manchester-koding. Manchester-koding støttes først og fremst for kompatibilitet med eksisterende standarder, men datahastigheten for Si443x dobles effektivt når man ikke bruker Manchester-koding.
Si443x støtter Manchester-koding og dekoding av hele pakken i maskinvare. Synkroniseringsordet er dessverre ikke Manchester-kodet. En ugyldig Manchester-sekvens ble med vilje valgt for synkroniseringsordet. Dette gjør Manchester-koding inkompatibel med de fleste eksisterende radioer, inkludert Si443x. Som en konsekvens må Manchester-kodingen og dekodingen utføres av MCU. Hver byte på ukodede data består av åtte databiter. Ved å bruke Manchester-koding blir hver databit kodet til et to-brikke symbol. Siden de kodede dataene må skrives til radio-FIFO-en åtte brikker om gangen, blir en bit data kodet og skrevet til FIFO-en om gangen.
Tabell 5. Manchester-koding

data	Ox12		0x34		bytes
	Ox1	0x2	0x3	0x4	napper
	1	10	11	100	binær
chip	10101001	10100110	10100101	10011010	binær
FIFO	OxA9	OxA6	OxA5	OxlA	hex

Hver byte som skal overføres sendes en byte om gangen til kodebytefunksjonen. Encode byte-funksjonen vil kalle encode nibble-funksjonen to ganger, først for den mest signifikante nibble og deretter for den minst signifikante nibble.
Manchester-koding i programvare er ikke vanskelig. Med utgangspunkt i den mest signifikante biten, er en kodet som en "01" brikkesekvens. En null er kodet som en "10" brikkesekvens. Dette kan enkelt oppnås ved å bruke en løkke og skifte to-bits for hvert symbol. Det er imidlertid raskere å bare bruke en enkel oppslagstabell med 16 oppføringer for hver bit. Encode Manchester nibble-funksjonen koder en nibble av data og skriver den til FIFO. Brikkene inverteres før de skrives til FIFO for å ta hensyn til kravene til invertert innledning.
Ved mottak består hver byte i FIFO-en av åtte brikker og dekodes til én bit data. Leseblokkfunksjonen leser én byte om gangen fra FIFO-en og kaller dekode-bytefunksjonen. Brikkene inverteres etter lesing fra FIFO for å ta hensyn til kravene til invertert innledning. Hver byte med Manchester-kodede brikker dekodes til en bit av data. Den dekodede nibble skrives til RX-bufferen ved å bruke skrive nibble RX-bufferfunksjonen.
Legg merke til at både kodet og dekoding utføres én databit om gangen i farten. Koding til en buffer vil kreve en ekstra buffer som er dobbelt så stor som de ukodede dataene. Koding og dekoding er mye raskere enn den raskeste støttede datahastigheten (100 k brikker per sekund). Siden Si443x støtter multiple-byte lesing og skriving til FIFO, er det en liten overhead ved å kun bruke enkelt-byte lesing og skriving. Overhead er omtrent 10 µs for 100 kodede brikker. Fordelen er en RAM-besparelse på 512 byte.
2. Tre av seks kodingsdekoding
Tre-av-seks-kodingsmetoden spesifisert i EN-13757-4 er også implementert i fastvare på MCU. Denne kodingen brukes for høyhastighets (100 k brikker per sekund) Mode T fra meter til annen. Model T gir kortest sendetid og lengst batterilevetid for en trådløs måler.
Hver byte med data som skal overføres er delt inn i to nibbles. Den viktigste biten kodes og overføres først. Igjen implementeres dette ved å bruke en kodebyte-funksjon som kaller opp encode nibble-funksjonen to ganger.
Hver bit av data er kodet inn i et symbol med seks brikker. Sekvensen av symboler med seks brikker må skrives til FIFO med 8 brikker.
Under koding blir to byte med data kodet som fire nibbles. Hver nibble er et 6-brikke symbol. Fire 6chip-symboler er samlet som tre byte.
Tabell 6. Tre av seks koding

data	0x12			0x34			bytes
	Ox1	0x2		0x3		0x4	napper
chip	15	16		13		34	oktal
	1101	1110		1011		11100	binær
FIFO	110100		11100010		11011100		binær
	0x34		OxE2		OxDC		hex

I programvare er tre-av-seks-kodingen implementert ved hjelp av tre nestede funksjoner. Encode byte-funksjonen kaller encode nibble-funksjonen to ganger. Encode nibble-funksjonen bruker en oppslagstabell for seks-chip-symbolet og skriver symbolet til Shift Three of Six-funksjonene. Denne funksjonen implementerer et 16-brikkes skiftregister i programvare. Symbolet skrives til den minst signifikante byten i skiftregisteret. Registeret flyttes til venstre to ganger. Dette gjentas tre ganger. Når en komplett byte er tilstede i den øvre byte i skiftregisteret, inverteres den og skrives til FIFO.
Siden hver byte med data er kodet som halvannen kodet byte, er det viktig å tømme skiftregisteret innledningsvis slik at den første kodede byten er riktig. Hvis pakkelengden er et oddetall, etter å ha kodet alle byte, vil det fortsatt være en nibble igjen i skiftregisteret. Dette håndteres med postamblet som forklart i neste avsnitt.
Dekoding av de tre av seks kodede er omvendt prosedyre. Ved dekoding dekodes tre kodede byte til to databyte. Programvarens skiftregister brukes igjen til å aggregere byte med dekodede data. En 64-oppførings invers oppslagstabell brukes for dekoding. Dette bruker færre sykluser, men mer kodeminne. Å søke i en oppslagstabell med 16 oppføringer etter det tilsvarende symbolet tar betydelig lengre tid.
Postamble
Wireless M-bus-spesifikasjonen har spesifikke krav for postamble eller tilhenger. For alle moduser er minimum to sjetonger, og maksimum er åtte sjetonger. Siden minste atomenhet for FIFO er én byte, brukes en 8-brikke trailer for Mode S og Mode R. Mode T postamble er åtte brikker hvis pakkelengden er partall eller fire brikker hvis pakkelengden er oddetall. Fire-chip postamble for en odde pakkelengde oppfyller kravene til å ha minst to vekslende brikker.
Tabell 7. Postamble Lengde

	Postamble Lengde (chips)
	min	maks	Implementering		brikkesekvens
Modus S	2	8	8		1010101
Modus T	2	8	4	(merkelig)	101
			8	(til og med)	1010101
Modus R	2	8	8		1010101

Pakkebehandler

Pakkebehandleren på Si443x kan brukes i en modus med variabel pakkebredde eller en modus med fast pakkebredde. Modusen for variabel pakkebredde krever en pakkelengdebyte etter synkroniseringsordet og valgfrie topptekstbyte. Ved mottak vil radioen bruke lengdebyten for å bestemme slutten på en gyldig pakke. Ved overføring vil radioen sette inn lengdefeltet etter header-bytene.
L-feltet for den trådløse M-buss-protokollen kan ikke brukes for lengdefeltet Si443x. For det første er ikke L-feltet den faktiske pakkelengden. Det er antallet koblingslags nyttelastbyte, ikke inkludert CRC-byte eller koding. For det andre er selve L-feltet kodet ved å bruke enten Manchester-koding eller Tre av seks-koding for Mode T-meter til andre.
Implementeringen bruker pakkebehandleren i fast pakkebreddemodus for både overføring og mottak. Ved overføring vil PHY-laget lese L-feltet i overføringsbufferen og beregne antall kodede byte, inkludert postamble. Det totale antallet kodede bytes som skal overføres skrives til pakkelengderegisteret (0x3E).
Ved mottak dekodes de to første kodede bytene, og L-feltet skrives til mottaksbufferen. L-feltet brukes til å beregne antall kodede byte som skal mottas. Antallet kodede byte som skal mottas blir så skrevet til pakkelengderegisteret (0x3E). Postemblemet er forkastet.
MCU'en må dekode L-feltet, beregne antall kodede byte og skrive verdien til pakkelengderegisteret før kortest mulig pakkelengde er mottatt. Det korteste tillatte L-feltet for PHY-laget er 9, noe som gir 12 ukodede byte. Dette gir 18 kodede byte for Model T. De to første bytene er allerede dekodet. Dermed må pakkelengderegisteret oppdateres i 16-byte ganger med 100 kbps eller 1.28 millisekunder. Dette er ikke noe problem for en 8051 som kjører på 20 MIPS.
Antall byte som skal mottas inkluderer ikke postamble, bortsett fra fire-chip postamble som brukes for Mode T-pakker med en odde pakkelengde. Mottakeren krever derfor ikke en postamble, bortsett fra Model T-pakkene med odde lengde. Denne postamble er bare nødvendig for å gi et heltall av kodede byte. Innholdet i postamblet ignoreres; så hvis postamble ikke sendes, vil fire brikker med støy bli mottatt og ignorert. Siden det totale antallet kodede byte er begrenset til 255 (0xFF), begrenser implementeringen det maksimale L-feltet for de forskjellige modusene.
Tabell 8. Pakkestørrelsesgrenser

	kodet		dekodet		M-buss
	bytes		bytes		L-felt
	des	hex	des	hex	des	hex
Modus S	255	FF	127	7 F	110	6E
Modus T (meter-annet)	255	FF	169	A9	148	94
Modus R	255	FF	127	7 F	110	6E

Disse grensene er normalt godt over det typiske brukstilfellet for en trådløs måler. Pakkelengden bør holdes liten for å få best mulig batterilevetid.
I tillegg kan brukeren spesifisere det maksimale L-feltet som skal mottas (USER_RX_MAX_L_FIELD). Dette bestemmer den nødvendige størrelsen for mottaksbufferen (USER_RX_BUFFER_SIZE).
Å støtte et maksimalt L-felt på 255 vil kreve en mottaksbuffer på 290 byte og maksimalt 581 Manchester-kodede byte. Pakkebehandleren må deaktiveres og pakkelengderegisteret kunne ikke brukes i så fall. Dette er gjennomførbart, men det er mer praktisk å bruke pakkebehandleren, hvis mulig.

FIFO-bruk

Si4431 gir en 64 byte FIFO for sending og mottak. Siden antallet kodede byte er 255, kan det hende at en hel kodet pakke ikke får plass i bufferen på 64 byte.
Overføring
Ved overføring beregnes det totale antallet kodede byte. Hvis det totale antallet kodede byte, inkludert postamble, er mindre enn 64 byte, skrives hele pakken til FIFO og bare pakken sendt avbrudd er aktivert. De fleste korte pakker vil bli sendt i én FIFO-overføring.
Hvis antallet kodede byte er større enn 64, vil flere FIFO-overføringer være nødvendig for å sende pakken. De første 64 bytene skrives til FIFO. Pakke sendt og TX FIFO Nesten tom avbrudd er aktivert. Terskelen for TX FIFO Nesten tom er satt til 16 byte (25%). Ved hver IRQ-hendelse leses status 2-registeret. Pakke sendt-biten kontrolleres først, og hvis pakken ikke er fullstendig sendt, skrives de neste 48 byte med kodede data til FIFO. Dette fortsetter til alle kodede byte er skrevet og Pakkesendt-avbruddet oppstår.
1. Resepsjon
Ved mottak er det først bare Sync Word-avbruddet som er aktivert. Etter å ha mottatt synkroniseringsordet, er synkroniseringsordavbruddet deaktivert og FIFO Nesten Full avbrudd er aktivert. FIFO nesten full terskel er i utgangspunktet satt til 2 byte. Det første FIFO Nesten Full-avbruddet brukes til å vite når de to lengdebytene er mottatt. Når lengden er mottatt, dekodes lengden og antall kodede byte beregnes. RX FIFO nesten full terskel settes deretter til 48 byte. RX FIFO er nesten full og gyldige pakkeavbrudd er aktivert. Ved neste IRQ-hendelse leses status 1-registeret. Først sjekkes den gyldige pakkebiten, og deretter blir FIFO Nesten full-biten sjekket. Hvis bare RX FIFO Nesten Full-biten er satt, leses de neste 48 byte fra FIFO. Hvis den gyldige pakkebiten er satt, leses resten av pakken fra FIFO. MCU holder styr på hvor mange byte som er lest og slutter å lese etter siste byte.

Datalinklag

Datalinklagmodulen implementerer et 13757-4:2005-kompatibelt linklag. Datalinklaget (LINK) gir et grensesnitt mellom det fysiske laget (PHY) og applikasjonslaget (AL).
Datalink-laget utfører følgende funksjoner:

• Gir funksjoner som overfører data mellom PHY og AL
• Genererer CRC-er for utgående meldinger
• Oppdager CRC-feil i innkommende meldinger
• Gir fysisk adressering
• Godkjenner overføringer for toveis kommunikasjonsmoduser
• Rammer databiter
• Oppdager innrammingsfeil i innkommende meldinger

Link Layer Frame Format

Det trådløse M-Bus-rammeformatet som brukes i EN 13757-4:2005 er avledet fra rammeformatet FT3 (Frame Type 3) fra IEC60870-5-2. Rammen består av en eller flere blokker med data. Hver blokk inkluderer et 16-biters CRC-felt. Den første blokken er en blokk med fast lengde på 12 byte som inkluderer L-feltet, C-feltet, M-feltet og A-feltet.

1. L-felt
   L-feltet er lengden på koblingslagets datanyttelast. Dette inkluderer ikke selve L-feltet eller noen av CRC-bytene. Det inkluderer L-feltet, C-feltet, M-feltet og A-feltet. Disse er en del av PHY-nyttelasten.
   Fordi antallet kodede byte er begrenset til 255 byte, er den maksimale støttede verdien for M-feltet 110 byte for Manchester-kodede data og 148 byte for Mode T tre-av-seks kodede data.
   Link-laget er ansvarlig for å beregne L-feltet ved overføring. Link-laget vil bruke L-feltet ved mottak.
   Merk at L-feltet ikke indikerer PHY-nyttelastlengden eller antall kodede byte. Ved overføring vil PHY beregne PHY nyttelastlengden og antall kodede byte. Ved mottak vil PHY dekode L-feltet og beregne antall byte som skal dekodes.
2. C-felt
   C-feltet er rammekontrollfeltet. Dette feltet identifiserer rammetypen og brukes for koblingsdatautvekslingstjenestens primitiver. C-feltet angir rammetypen – SEND, BEKREFT, FORESPØRSEL eller SVAR. Når det gjelder SEND- og REQUEST-rammer, indikerer C-feltet om det forventes en CONFIRM eller RESPOND.
   Når du bruker den grunnleggende Link TX-funksjonen, kan en hvilken som helst verdi av C brukes. Når du bruker Link Service Primitives, fylles C-feltet ut automatisk i henhold til EN 13757-4:2005.
3. M-felt
   M-feltet er produsentens kode. Produsenter kan be om en trebokstavskode fra følgende web adresse: http://www.dlms.com/flag/INDEX.HTM Hvert tegn i trebokstavskoden er kodet som fem biter. 5-bits koden kan oppnås ved å ta ASCII-koden og trekke fra 0x40 ("A"). De tre 5-bits kodene er sammenkoblet for å lage 15-biter. Den mest signifikante biten er null.
4. Et jorde
   Adressefeltet er en unik 6-byte adresse for hver enhet. Den unike adressen bør tildeles av produsenten. Det er hver produsents ansvar å sørge for at hver enhet har en unik 6-byte adresse. Adressen for send- og forespørselsrammer er selvadressen til måleren eller annen enhet. Bekreftelsesvarsdatarammer sendes ved å bruke adressen til den opprinnelige enheten.
5. CI-felt
   CI-feltet er applikasjonsoverskriften og spesifiserer typen data i applikasjonsdatanyttelasten. Mens EN13757-4:2005 spesifiserer et begrenset antall verdier, vil Link Service Primitives tillate bruk av enhver verdi.
6. CRC
   CRC er spesifisert i EN13757-4:2005.
   CRC-polynomet er:
   X16 + x13 + x12 + x11 + x10 + x8 +x6 + x5 +x2 + 1
   Merk at M-Bus CRC beregnes over hver 16-byte blokk. Resultatet er at hver 16 byte med data krever at 18 byte skal overføres,

Tilleggsinformasjon

For ytterligere informasjon om Link Layer-implementering, se "AN452: Wireless M-Bus Stack Programmers Guide".

Strømstyring

Figur 2 viser strømstyringstidslinjen for en måler f.eksample ved å bruke Mode T1.

MCU-en bør være i hvilemodus når det er mulig for å spare energi. I dette eksample, MCU-en sover når RTC kjører, når den venter på oppstart av radiokrystall og når den sender fra FIFO. MCU-en vil våkne fra EZRadioPRO IRQ-signalet koblet til en Port Match-vekker.
Når du sender meldinger som er lengre enn én blokk, må MCU-en våkne for å fylle FIFO-en (basert på FIFO-en nesten tomme avbrudd) og deretter gå tilbake til dvale.
MCU-en skal være i hvilemodus og kjøre fra laveffektoscillatoren eller burst-modusoscillatoren når den leser fra ADC. ADC krever en SAR-klokke.
Når den ikke er i bruk, bør EZRadioPRO være i Shutdown-modus med SDN-pinnen høyt drevet. Dette krever en fast tilkobling til MCU. EZ Radio Pro-registrene er ikke bevart i avstengningsmodus; så EZRadioPro initialiseres på hvert RTC-intervall. Initialisering av radioen tar mindre enn 100 µs og sparer 400 nA. Dette resulterer i en energibesparelse på 10 µJ, basert på et 10-sekunders intervall.
EZRadioPRO-krystallen tar omtrent 16 ms for en POR. Denne er lang nok til å beregne CRC for omtrent åtte blokker. MCU-en vil gå tilbake til dvale hvis den fullfører alle CRC-er før krystallen har stabilisert seg. Hvis kryptering er nødvendig, kan den også startes mens du venter på krystalloscillatoren.
MCU-en skal kjøre på 20 MHz ved å bruke laveffektoscillatoren for de fleste oppgaver. Oppgaver som krever en presis tidsavbrudd må bruke presisjonsoscillator og hvilemodus i stedet for hvilemodus. RTC gir nok oppløsning for de fleste oppgaver. Tidslinjen for strømstyring for T2-måleren eksampapplikasjonen er vist i figur 3.

Transceiver-implementeringen bør optimaliseres for det normale tilfellet når måleren våkner og det ikke er noen leser til stede. Minimum/maksimum ACK-tidsavbrudd er tilstrekkelig lange til at det er mulig å bruke C8051F930 RTC og sette MCU i hvilemodus.
Byggealternativer er gitt for nett- eller USB-drevne lesere som ikke trenger å bruke hvilemodus. Inaktiv modus vil bli brukt i stedet for hvilemodus, slik at USB og UART kan avbryte MCU.

Simplicity Studio
Ett-klikks tilgang til MCU og trådløse verktøy, dokumentasjon, programvare, kildekodebiblioteker og mer. Tilgjengelig for Windows,
Mac og Linux!

IoT-portefølje www.silabs.com/IoT	SV/HW www.silabs.com/simplicity	Kvalitet www.silabs.com/quality	Støtte og fellesskap community.silabs.com

Ansvarsfraskrivelse
Silicon Labs har til hensikt å gi kundene den nyeste, nøyaktige og dyptgående dokumentasjonen av alle periferiutstyr og moduler tilgjengelig for system- og programvareimplementere som bruker eller har til hensikt å bruke Silicon Labs-produktene. Karakteriseringsdata, tilgjengelige moduler og periferiutstyr, minnestørrelser og minneadresser refererer til hver spesifikk enhet, og "Typiske" parametere kan variere i forskjellige applikasjoner. Søknad eksampLes beskrevet her er kun for illustrasjonsformål. Silicon Labs forbeholder seg retten til å gjøre endringer uten ytterligere varsel og begrensning på produktinformasjon, spesifikasjoner og beskrivelser heri, og gir ingen garantier for nøyaktigheten eller fullstendigheten til den inkluderte informasjonen. Silicon Labs skal ikke ha noe ansvar for konsekvensene av bruken av informasjonen som er gitt her. Dette dokumentet antyder eller uttrykker ikke opphavsrettslisenser gitt under for å designe eller produsere integrerte kretser. Produktene er ikke designet eller autorisert for bruk i noe livsstøttesystem uten spesifikt skriftlig samtykke fra Silicon Labs. Et "Livsstøttesystem" er ethvert produkt eller system beregnet på å støtte eller opprettholde liv og/eller helse, som, hvis det mislykkes, med rimelighet kan forventes å resultere i betydelig personskade eller død. Silicon Labs-produkter er ikke designet eller autorisert for militære applikasjoner. Silicon Labs-produkter skal under ingen omstendigheter brukes i masseødeleggelsesvåpen, inkludert (men ikke begrenset til) atomvåpen, biologiske eller kjemiske våpen, eller missiler som er i stand til å levere slike våpen.
Varemerkeinformasjon
Silicon Laboratories Inc.®, Silicon Laboratories®, Silicon Labs®, SiLabs® og Silicon Labs-logoen®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember® , Energy Micro, Energy Micro-logoen og kombinasjoner av disse, «verdens mest energivennlige mikrokontrollere», Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY® , Telegesis, Telegesis Logo®, USBXpress® og andre er varemerker eller registrerte varemerker for Silicon Labs. ARM, CORTEX, Cortex-M3 og thumbs er varemerker eller registrerte varemerker for ARM Holdings. Keil er et registrert varemerke for ARM Limited. Alle andre produkter eller merkenavn nevnt her er varemerker for deres respektive eiere.

Silicon Laboratories Inc.
400 West Cesar Chavez
Austin, TX 78701
USA
http://www.silabs.com

Dokumenter / Ressurser

SILICON LABS Trådløs M-BUS-programvareimplementering AN451 [pdfBrukerhåndbok SILICON LABS, C8051, MCU, og, EZRadioPRO, Wireless M-bus, Wireless, M-BUS, Software, Implementation, AN451

Referanser

• Brukerhåndbok