roarfred

Da har jeg fått komplette filer for schematics, part list og PCB, inklusive gerber filer fra vår venn i India. Det hele er lagt ut her: https://github.com/roarfred/AmsToMqttBridge/tree/master/Electrical

Jeg har også laget et lite sammendrag i readme.md her (den som kommer opp når en åpner linken)

Edit: fikset url

26 minutes ago, Tubez said:

Ja jeg ser den, men jeg får det fortsatt ikke til å stemme. Hvis du ser på Kamstrup så starter denne med 0C07. Den tar heller ikke med FF800000 i samme streng.

 

Det som jeg også har sett, er at i de tilfellene en sekvens starter med 09 (An orderes sequence of octets (8 bit bytes)), så tar han for seg byte for byte. Det vil si at 07D0 skal sees på som 07 = 7 og D0 = 320... Eller hvis man ser hele samlet så blir dette "07E1090C02171232FF800000" = "1760411030010270444000000000000". Dette ser du stemmer med følgende:

0907 4B464D5F303031 = KFM_001

0908 4D41333034483345 = MA304H3E

Jeg tror det er slik at den første byte forklarer dataformatet. Dvs 07=dato, 09=string, 06=int (32 bit)

Hver av disse har så sin egen definisjon av de påfølgende bytes. Eks trenger ikke 06 si hvor mange bytes som følger. 07 er nok et definert datoformat der det settes av 2 bytes (16 bit) til årstall. 07 D0 må dermed sees i sammenheng og gir 2000. Se mine data, så stemmer det godt

On ‎30‎.‎09‎.‎2017 at 10:17, Tubez said:

 

Tenker du på 0A i rad 5 og 6? Det er måler ID og type måler. 

 

Det som jeg lurer på i A0 i rad 1 kan være en tekststreng med E2 bytes? Edit: nei,  tviler på at der skal være 226 bytes i den strengen xD... 

 

Det jeg ikke klarer å finne ut av er hva som foregår på rad 2... 

Sorry, ser nå at jeg må ha ment rad to jeg også...

A0 i rad 1 er egentlig delt i to "halve" bytes. A angir en frame type eller noe slik, mens 0 settes sammen med E2 (som MSB) for å angi størrelsen på rammen. (muliggjør da rammestørrelser på opp til 4096 bytes i stedet for 256)

Forresten, lurer på om ikke det er en timestamp i rad 2:

0C = 12 bytes

07 D0 = 2000 (årstall)

01 = 1 (januar)

01 = 1 (1. januar)

06 = ??? (skilletegn)

16 = 22 (timer)

21 = 33 (minutter)

00 = 0 (sekunder)

FF800001 = usikker på denne, mener FF anga at hundredeler ikke er oppgitt, og at det lå noe om sommertid etc. i dette

9 minutes ago, Tubez said:

Ja, hvis netteieren her hadde aktivert utgangen så kunne jeg fått målt. 

 

Jeg har prøvd å se om jeg finner ut om de kodene i det eksempelet til Kamstrup, men har bare klart å komme så langt til nå:  

 

Det jeg vet er at alle de blanke tekstene i midten, er som du sier, henviser til OBIS koden. 

 

Det jeg også har sett er at "7E" (antar start flag), "2B", "21", "13", "E6E700" i første rekke er like i alle 3 eksemplene, samme gjelder for "0F" og "00000000" i rekke 2. 

De siste "5BE5" må være frame check og "E7" er da end flag eller noe i den duren.

 

Fant du ut noe mer angående Class 40?

Etter hver av 09 blokkene har du en 06. Det betyr også 6 påfølgende bytes, og her er det obis koden kommer. Det som er litt utfordrende er at min måler har omtrent tilsvarende data ut, men uten alle disse 09 06 verdiene. En kan tenke at en vha. OBIS identifier må slå opp i et register for å vite h a som kommer, og i hvilken rekkefølge. Hadde likevel vært kjekkere om de lignet litt mer på hverandre.

Jeg er usikker på hva som ligger i 0A dataene. Mulig interessant.

Det stemmer at 5BE5 er en checksum for hele framen. Det finnes også en egen checksum for header, ganske smart. Kalkulert på samme måte, men inkluderer da bare header data. Tror den er 239A i denne pakken.

Har ikke fått sjekket mer på class 40. Er på #rccodeathon2017 denne helgen...

6 hours ago, Tubez said:

Ikke verst

 

Vet du om dette kortet vil fungere på Aidon sine målere? For jeg har ikke sett veldig mye dokumentasjon på utgangen på den måleren annet enn OBIS listen du har på Github.

Umulig å si for meg... Håper noen får målt litt etterhvert, så kan jeg evt. justere om nødvendig

10 minutes ago, Tubez said:

hvem produserer PCBen? Og hvor er minimumsbestilling av brettet?

Har brukt noe som heter gogopcb tidligere. Minstaantall på 5 kort, for ca. $20.

Fikk nettopp forslag til PCB (i 3D PDF). Tok en snap av det her:

1 hour ago, Tubez said:

Jeg har lest litt mer i det dokumentet med eksempelkodene fra Kamstrup, og der nevner de DLMS klassen de benytter seg av, class 40. PPP er class 44 så det kan vell være en av årsakene til at ting ikke stemmer?

 

Har prøvd å finne ut litt mer om Class 40 men fant kun dette: https://www.kalkitech.com/news_releases/January15_Newsletter/page5.html

 

Fant også denne siden her: http://www.gurux.fi/gurux.dlms Her ser det ut som at de har laget koder i Java for å avlese målere, men usikker på hvordan DLMS klasse de har skrevet den til.

 

Edit:

Fant også Github siden deres: https://github.com/Gurux/Gurux.DLMS.Net

Søkte litt på dlms push og kom over en tråd her:

https://www.gurux.fi/node/4821

Sjekk innlegg nr. 11. Her er flere detaljer om hva hver byte betyr. Ser også ut som om dlms kan kjøres i flere modes, der den ene gir en slik 7E pakke. HDLC nevnes som et begrep. Er det slik at det er en stack på dette viset:

Mbus for elektrisk

Hdlc for pakke-protokoll

Dlms/cosem for data-protokoll

1 hour ago, Tubez said:

Har du lest de tabellene over variabel data strukturen for M-bus? http://www.m-bus.com/files/MBDOC48.PDF Side 76, side 75 inneholder informasjon om SI enhetene. 

Så bare at de definerer tre ulike typer pakker, hver med egen start byte som skal identifisere. Ingen av den er 7E. Men, så du skrev noe etterpå om at støtte for push har kommet etterpå. Skal se mer på det...

11 minutes ago, Tubez said:

Jeg har lest litt i det dokumentet på m-bus.com, og de sier at "data link layer" er basert på ICE870-5. Ikke at jeg klarte å finne ut hva standarden sier, men jeg fant denne fra abb: https://library.e.abb.com/public/b4ee801d21d685b5c1257b1300569705/rec523_IECprotENd.pdf

 

Og jeg fant denne også: http://www.geocities.jp/ps_dictionary/standard/cpaper/IEC-R20_1.pdf

 

Er det noe du kan bruke der?

Litt rart dette for det sies at det er mbus, men jeg får ikke protokollen til å stemme. Eks er det ulike start og stopp for pakkene. MBus dokumentasjonen stemmer med kommunikasjon jeg har gjort mot måleren på varmepumpen min, men ikke på AMS måleren. 2400baud, 8E1 og elektriske nivåer matcher. Kan det være at de har brukt deler av mbus bare?

5 minutes ago, Tubez said:

Ah ja det stemmer, ja det blir nok litt fordyrende på dette nivået man er på nå

 

Men for å snakke litt om kodingen, hvordan kom du fram til at det er RFC1662 standarden på dataoverføringen som er brukt?  

 

 

I seksjon 8.5.1/8.5.2 i Green Book finnes noen detaljer som satte meg på rett spor. Brant av en god lørdag for å komme derfra til ferdig implementert kode da  

https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/Excerpt_GB8.pdf 

Følger deg ikke helt på dette med RX og TX direkte på micro usb. En ville her måtte ha en FTDI krets direkte på kortet (for å oversette USB til seriell) om en ønsket å koble eks en PC direkte til. Veldig mange protoboards for ESP8266 har nettopp dette, og det er kjekt når en skal komme fram til et design. Derimot litt fordyrende og unødvendig i denne sammenheng. Det en derimot kunne gjort var å ta ut VCC (5V) fra den eksterne FDTIen, da hadde en slippet å ha en ekstern strømforsyning koblet til under programmering og testing.

Stemmer helt at du kunne koblet deg på ved jumper (RXTTL3V3) og rett i PI'en. Om det heter TX eller RX kommer vel bare an på siden en ser det fra. Kanskje bedre navn kunne være HAN_TTL3V3.

Har mer enn nok med å kommunisere de elektriske endringene tilbake til ingeniøren, om jeg ikke også skulle henge meg opp i navngiving

2 minutes ago, Tubez said:

Hvis VDD har ca. 27 V, så blir det litt feil på ESP8266 da der 3,3 V og VDD er tilkoblet sammen  

 

Jumper, så du ønsker å kunne frakoblet signalet under programmering? Men er det da ikke bare å koble ut kabelen fra selve måleren? Litt lettere å håndtere kabelen derfra enn en liten jumper på et kretskort, Evt så setter du en RJ45 kontakt på kortet for å kunne koble fra kabelen der? 

La oss krysse fingrene for at VDD på ESP bare er et navn på denne pinnen og at det ikke har noe med signal-navnet VDD å gjøre  

Poenget med å koble fra er at det kan være ukjent signal inn, så både transistoren og motstanden kan påvirke serie-signalet for programmering, noe som 115k baud signalet er litt ømfintlig for. Plass til en jumper koster ingen ting, og den kan evt. bare loddes over om en ser at det fungerer uten.

Header som en setter FTDIen oppå er også direkte på kretskortet, så en kan argumentere for at det er like enkelt å nappe ut en jumper som å koble ut RJ45 kabelen. Jeg bruker noe slik som dette: https://www.amazon.co.uk/XCSOURCE®-FT232RL-Adapter-Arduino-TE203/dp/B00HSX3CXE/ref=pd_lpo_sbs_147_img_1/257-9514725-8254220?_encoding=UTF8&psc=1&refRID=GTTP8PAVPYSN2E76DDR5

34 minutes ago, Tubez said:

 

Ikke verst dette. Eneste jeg lurte litt på om hvorfor det blir skilt på VDD og 3,3 V på tegningen når dette ser ut til å være akkurat det samme.

 

Hvor skal "JUMPER" være plassert inn mot ESP8266? 

 

Er det noe poeng med å ha en 470  ohms resistor mellom RST og GND hvis du setter switchen etter motstanden på 10k ohm? 

 

Jeg ser også at GPIO2 har en 10k ohm resistor, men den er tilsynelatende ikke koblet opp mot noe? 

 

Kunne man ikke erstattet "ProgramHeader" med å benytte RX og TX i "MicroUSB Connectoren"? Eller er det et poeng at du skal ha den for seg selv? For den "ProgramHeader" kan i praksis likså greit være USB?

VDD holder ca. 27V. Ref tidligere post må opamp ha så høy driftspenning for å takle input direkte fra MBus

JUMPER er for å kunne frikoble opamp signal under programmering

470 ohms motstander kunne sikkert vært fjernet, ja.

Good catch med R på GPIO2, den skal selvfølgelig være koblet!

Headeren er tilpasset en ekstern FTDI. En kunne brukt USB til dette, men da med egen FTDI krets på kortet. Ser for meg at vi hovedsakelig oppdaterer over WiFi, så det er bare under initiell programmering dette er behov for.

Da er neste revisjon av schematics klar. Neste steg er komplett parts list

28 minutes ago, Tubez said:

En ting jeg ikke klarer å legge fra meg, er hvorfor man ikke kan bruke TSS721A for dette? I følge http://www.m-bus.com/mbusdoc/md4.php så ser det ut som at man kan bruke denne brikken direkte mot måleren og koble denne mot en microcontroller/RPi? Ser ut som at man må inn med noen kondensatorer for å glatte signalet og noen motstander for aktivering eneste? Det er nok som du sier, at denne er mer ment for selve målerenheten, men hvis man hadde kunne brukt denne så hadde man sluppet noen av de komponentene dere har over (som igjen tar bort litt av gleden)?

 

Her er også noen som har lagt ferdige board, men det jeg tenkte var å kun bestille selve brikken fra e-bay (kostet 20 kr) og dermed har man vell det man trenger?: https://www.aliexpress.com/store/product/TSS721-Module-Board-M-BUS-To-TTL-with-RX-TX-Indicator-STM32-Development-Board-Free-Shipping/722716_32751482255.html 

Godt mulig du har rett i dette. Hadde vært spennende å prøvd! Den breakouten fra aliexpress kan en jo sikkert bruke for å koble direkte til både PC og RPi.

Tror jeg kjøpte noen løse chipper fra digikey til 40 kr stk. Utfordringen var nok at jeg den gangen trengte å lage en master, og ikke en slave. Samtidig fikk jeg den bare i SMD (16-SOIC) som er litt krevende å hånd-lodde. Dette er nok (om det fungerer) et mer solid design. Min tilnærming er nok en rimeligere løsning som kan lages med komponenter en gjerne likevel har liggende.

2 hours ago, Tubez said:

Må si at dette ser spennende ut

 

Men i ditt originale schematics, inverterer du signalet? Kan det være en årsak til at mengdene ikke stemmer helt? For de kodene du mottar, er ikke identisk med det eksempelet som kamstrup har her: https://github.com/roarfred/AmsToMqttBridge/blob/master/Documentation/Kamstrup HAN-NVE interface description_rev_3_0.pdf

 

Jeg spør sikkert dumt, men det er en stund siden jeg hadde elektroteknikk og digitalteknikk  

Har nok på et tidspunk hatt ute en skisse av en inverterende krets, men det vil ikke fungere. I dataene som mottas er det en checksum for header og en til for hele pakken. Disse bekrefter at det er samme data en mottar som de som ble sendt, og skal forhindre en enkel verdi å bli forandret av et dårlig signal.

Edit: Det stemmer at kodene ikke er like som de som Kamstrup sier skal komme. Forskjellen er egentlig at på Kamstrup sine data så kommer det annen hver record med en OBIS kode ut. Start på 09 06 skulle bety noe slik som "tekst følger de neste 6 bytes". Deretter kommer en 06, som betyr "de neste fire bytes representerer et heltall". Hos meg kommer bare 06-variantene fortløpende, mens Kamstrup sier det skal komme en 09-variant i forkant av hver verdi. Betydningen av 09 og 06 er bare noe jeg selv har tenkt meg til. Ser også at Kamstrup har et par 0A varianter, der også byte 2 har antall bytes i record. Alle detaljer omkring dette mottas med takk, foreløbig er alt basert på (u)kvalifisert gjetting

1 hour ago, Einar said:

Der sier du noe RoarFred. Input differentialet kan jo bli høyere enn Vcc. Differetialspenning inn kan ikke være høyere enn Vcc.

Legg inn en spenningsdeler før pin 2 og juster motstandsverdier deretter.

 

Og så retter jeg meg selv: Tilbakekobling for å få hysterese skal være mellom pin 1 og 3!

 

 

Trenger jeg mer inndeling? Slik det er nå så får opamp en nokså stabil vcc på 27V. Positiv inngang legges på en deling av denne, ca 20V, som igjen blir triggernivået til inngangen på negativ inngang. Rippel skjer vel stort sett i øvre og nedre områder, men som sagt kjøper jeg lett løsning for hysterese

29 minutes ago, Einar said:

LM358 vil bytte tilstand ved ca. 19-20V, men ikke nødvendigvis skifte pent over som du ønsker.

Lag en schmitt trigger ved å tilføye en motstand ca. 100K mellom pin 1 og 2. Da får du en hysterese på ca. 2V.

Verdiene gifter du deg ikke med, så de kan endres ved testing.

 

Legg også inn en keramisk kondensator i parallell med 10u på utgangen av spenningsregulatoren og en 47u ellytt på inngangssiden.

De keramiske er for å unngå selvsving. Ellytt på inngang fordi signalet der svinger mellom 24 og 15V. Og det trengs ingen likeretter, bare en diode.

 

LM1117 specs sier max 20V input og er allerede der diskvalifisert. Jeg forstår det slik at du tenker ta Vcc fra meteret? Da har du over 20V spenningsfall gjennom regulatoren. Det blir fort varmt! Jeg foreslår en switch regulator og kan komme tilbake med en jeg har god erfaring med. Må bare fyre opp KiCad og klippe-lime litt.

 

Er de to header2 kontaktene en og samme kontakt? Isåfall får du 2 stk i netlist og feil når du kjører sjekk på kretskortutlegget.

Og gi komponentene en reference, eller la KiCad gi dem det. Om du bruker KiCad så vil den insistere nær du genererer netlist.

 

Det var vel det jeg ser sånn i farta.

 

Her er regulatoren jeg foreslår. Med LM2575 bare med komponenter for å regulere rett ned til 3.3V. En slik switch regulator vil ikke brenne av mye, og dermed vil strømtrekket fra 24V bare bli 1/7 av det som går ut på 3,3V siden. Altså 24V/100mA vil gi ca 3,3V/700mA.

Mye god input! Takker!

Selv om input ser veldig bratt ut hos meg kjøper jeg gjerne en 2V hysterese!

Spec på Kaifa måleren sier 21mA/500mW, så jeg har kjørt med en separat 5V strømforsyning til dette. Ser det ble litt forvirring med bruk av VCC uten at jeg forklarte det  Viste seg å være helt nødvendig å likevel tilføre opamp en driftspenning som var høyere enn input, så her var det enklest å likerette (med en helt enkel 1n4148) og glatte spenningen fra MBus. Tror ikke vi trenger noe mer avansert til dette, her er i prinsippet kun tapping av 220uF gjennom 50K.

Med 5V in som skal reguleres til 3.3V, skulle vel utvalget av regulatorer være bra, og med mindre sjans for varme. (Kjører med den jeg nevnte tidligere, tatt fra et Adafruit design, 3-4 døgn med WiFi på uten problemer. Men, så er også strømtrekket sannsynligvis avhengig av signalstyrke som må til for å snakke med aksesspunkt, så best å dimensjonere riktig)

Jeg har fortsatt en kar fra India engasjert, så vi får se hvordan det blir  Resultatet legges uansett ut med schematics, PCB etc.

Mottok denne. Ser selv følgende, noen som har flere innspill?

• VCC må være en likerettet variant av MBus, og ikke direkte koblet til pin2 på Header 2
• Må sjekke om spenningsregulator holder til ESP
• Trenger 6-pin header for programmering (tilpasset standard USB/FTDI)
• Trenger to små push buttons for Prog/Reset

14 minutes ago, Einar said:

 

Hadde kanskje blitt billigere å legge det ut her?   Og har du sett hva du har av kontroller i skjemategning og utlegg? KiCad har slike sjekker. Du må selvfølgelig selv definere reglene.

Det er ganske vanlig at GND og power pins ikke kommer frem på skjema. Det er for at det ikke skal brukes plass på det opplagte. Jeg pleier legge bypass kondensatorer i en "klyse" i et ledig hjørne av skjema.

Sjekk netlist, der skal GND og power være for å komme med i kortutlegg.

hm, github prosjektet er åpent for å gjøre en pull-request mot, hvis du føler deg kallet... Har satset 14 euro på en kar i India som hadde mange års erfaring med skjema- og PCB design, så det er jo verdt pengene bare å se hva en får utav noe slik.

Har bedt om oppdatert skjema i første runde. Kan gjerne poste det her for kjapp review, om det er interesse...

3 hours ago, roarfred said:

Litt vrient å gi en garanti for dette...

Er obs på følgende feil:

• GND/VCC på LM358 viser ikke på skjema. Her skal Pin 8 til VCC og Pin 4 til GND
• På ESP skal GPIO 0 til +3V3 via en 10k motstand
• På ESP skal GPIO 2 til +3V3 via en 10k motstand

Jeg kan prøve å fikse dette i eagle skjema og evt. lage et forslag til en enkel PCB i løpet av kvelden

Vær obs på at denne fungerer på min Kaifa måler, men er ikke testet på hverken Kamstrup eller Aidon. Jeg har dog ikke sett noe som beviser at dette ikke skal fungere ennå

Jeg la ut et oppdrag på sjekk av krets og design av PCB og BOP, klart for produksjon på freelancer.com. Litt ille når en betaler for å få gjort hobbyen sin, men er kanskje verdt det

16 minutes ago, Tubez said:

Tja, det kan hende. I dokumentasjonen for Aidon måleren så står det at formatet skal være 4.3 (xxxx.xxx kW) og har en oppløsning på 1 W. Da tviler jeg på at verdien du får oppgitt i effekt er i mW.

 

Formatet på de ulike skal være: 

Spenning: format 3.1 (xxx.x V)

Strøm: format 3.2 (xxx.xx A)

Effekt: format 4.3 (xxxx.xxx kW). Legg merke til at her er den oppgitt i kW, men oppløsningen er i 1 W. 

 

Så ut fra hva jeg kan se, så får man oppgitt effekt i W med oppløsning på 1 W, strøm i mA med en oppløsning på 10 mA og spenning V med oppløsning 100 mV. 

Dette stemmer jo bra med effekten og spenninge, men for strømmen så skulle man fått 1,75 A og ikke 1,755 A ettersom oppløsningen er på 10 mA. 

Effekt: 06 00 00 02 5C = 000604 W, 

Strøm: 06 00 00 06 BD = 1755 mA = 1,755 A

Spenning: 06 00 00 09 60 = 2400 = 240 V

 

Men jeg stusser litt på at avlesningen din bare var på 0,6 kW ved dette tidspunktet, for hvis man ser på hvordan verdi strømmen skulle hatt (altså 17,5 A ettersom oppløsningen er 10 mA), så skulle effekten også vært høyere. Vet du med sikkerhet at lasten din på dette punktet var kun 604 W? eller var den 6,04 kW? 

Sorry, min feil, jeg mente effekt i W, ikke i mW

Er 99% sikker på at det er 600W på den aktuelle målingen. Det høyeste jeg har målt har vært ca 7500W og det laveste ca 300W. Stemmer bra med en fryktelig liten enebolig, uten en eneste panelovn, en beboer og luft til vann varmeanlegg.

Har du en referanse til hvor det sies hvordan formatet skal være xx.xxx eller x.xxx etc? Er dette data fra produsenten, krav fra NVE eller noe du har lest ut fra de aktuelle oppgitte OBIS kodene?

15 minutes ago, Tubez said:

Jeg ser at spenningen er oppgitt med en oppløsning på 0,1 V med format xxx.x V på Aidon sine målere og nesten det samme for Kaifa, bare der oppgir de ikke oppløsningen, men ettersom de består av akkurat samme OBIS kode så antar jeg at det er en oppløsning på 0,1 V og at den gir ut heltall. Det samme gjelder for strømmen (0,1 A) forutenom Kamstrup som oppgir oppløsning på 0,01 A. Her skal det nevnes at Kamstrup har objektkode 1.1.31/51/71.7.0.255, mens Aidon og Kaifa har objektkode: 1.0.31/51/71.7.0.255.

 

Når det kommer til inndelingen av OBIS kodene, så har jeg klart å finne fram til dette: 

"Value group B identifies the measuring channels. Value group C identifies the physical quantity measured, while value group D identifies the processing methods and country specific codes. Value group E is used for identifying rates or can be used for further classification. Value group F is used for identifying historical values or can be used for further classification. "

 

Gruppe A=1 angir om det er elektriske komponenter som skal måles.

 

Dermed ser det ut til at Aidon og Kaifa gir ut strømverdien på en annen kanal enn Kamstrup, og det er sikkert det som angir oppløsningen på 0,1 A og 0,01 A.

 

Edit: Ser på de dataene du har så stemmer det ikke helt med hva som er oppgitt på de skjemaene fra NVE. For tviler for at du har en belastning på over 200 A.

Jeg forstod det også slik at B i prinsippet ikke burde bety noe, og at den er mer aktuell i målere hvor en kanskje har flere kilder med tilført og avgitt energi.

Med øyeblikkseffekt på ca. 600W må en vel si at strømforbruk kan stemme sånn ca. med 604W / 240 V / 1,41 = 1.78A per linje (i snitt 1.79A i følge utleste data). Så dermed kan en vel si at det er mA som faktisk kommer ut. (Da også mW for effekt)

10 hours ago, Tubez said:

Jeg tittet litt på disse verdiene nå, og det er nok som du sier en feil med at verdien er 1000x for høy ja, men så lenge nettselskapet korrigerer det så er det nok ikke så farlig... 

 

Videre så ser jeg, hvis disse tallene stemmer, at du,  eller noen på samme trafokrets,  har jordfeil på fase 2

Hvis du refererte til spenning 0V på L2, så har det plutselig blitt i orden nå... Men det var disse dataene jeg fikk ut da jeg tok ut en sample.

Ser spec sier at det er SI enheter som skal brukes, men det ser ut som en på spenning opererer med decivolt, og på strøm med milliamper. Sikkert bare et triks for å få noenlunde oppløsning på verdiene, men hadde vært kjekt om dette var dokumentert på litt bedre vis.