Vittja data från trådlös elmätare

[kng]

Tackar (:

Angående pris, jag köpte conrads för 250:- per packe tidigare (2 uttag, 1 mottagare), antar att det var nån kampanj eller så har dom bara tokhöjt priset till 389:-.
Om jag kollar på plugwise sida så säljer dom en likvärdig packe för 125€, så i grova drag är dom väl 4-5 ggr dyrare ?


Jag har suttit och glott på mätvärden nu några timmar och försökt läsa på om binära flyttal, utan riktigt genombrott.... kanske var för trött igår eller nått
Hur som helst, dessa är exempel på värden jag får fram tillsammans med vad som kan utläsas på displayen.
Aktuell teori är att några av bittarna är exponent och resten är fraktion, sen är talet ett heltal men som presenteras med en punkt innan lägsta siffran (textmässig division med 10).

0x0AD0 är 17.3W i display:
0x0AD0 = 2768, 2768/16 = 173, 173/10 = 17.3W (tur?)

Men när man går upp till lite större tal så spårar det ur direkt, försök lösa dessa:
0x5FE0 = 153.4W
0x8B71 = 632.7W
0xB1C2 = 1103.6W
0x24E5 = 2107W

Det finns ett format som kallas half precision float som borde passa, så när som på att det inte finns nån sign-bit, samt att bitfördelningen kanske inte stämmer.

[danielr112]

Ja fick du de för de priset så.
Men menar du att man får 2 enheter + mottagare för 389 nu? Jag uppfattade det som 389 per enhet. (har nog läst fel då)

Just nu kostar plugwise 324 kr st

[Borre]

I leveransen ingår:
* Bas- och manöverenhet
* 2 vägguttagsgivare

Från länken till Conrad ovan.

[danielr112]

jag som läste helt galet

[Borre]

Enbart "mätenheten" kostar löst 149kr/st: http://www.conrad.se/?article=125353

[kng]

Mystiken tätnar.. jag började undersöka talen binärt istället och då uppebarade sig en del, men det är fortfarande inte hundra utrett.

0xB1C2B1C0 betyder 1103.6W + 1103.6MaxW (11036 utan decimalpunkten).
tar man de 32 bitarna binärt så får vi:

Kod: Markera allt

0xB1C2B1C0 =    10110001110000101011000111000000
11036 =     0010101100011100
11036 =                     0010101100011100

Eller ett till exempel för 632.7W:

Kod: Markera allt

0x8B718B70 =     10001011011100011000101101110000
6327 =       0001100010110111
6327 =                       0001100010110111

Som synes så passar bittarna in, men dom är förskjutna 4 bit åt vänster.
Det innebär samtidigt att dom högsta 4 bittarna återfinns i nästa (eller ännu värre) byte som vi inte tagit med i detta exempel.
Har ett till exempel på 2000W+ som är vansinnigare än dessa två exempel...

*suck*

[LasseT]

Jag begriper inte mycket av vad du gör, men det är precis vad jag efterfrågar!

Jag har ett gäng mätare ifrån dem som jag vill logga till PC, så säg till när du är färdig.

Kan denna länk vara till nytta http://www.produktinfo.conrad.com/daten ... atv1_2.pdf, de har tydligen en annan produkt som kan logga 1 mätare till ett inbyggt SD-kort.

[kng]

Jag har haft häcken full på jobbet den senaste tiden, så jag har inte kunnat lägga all den tid jag velat på detta.
Dock har det inte stått stilla. Jag har loggat varierande effekter och stabila effekter över tid osv och kommit fram till lite småsaker.
Det enda jag kan konstatera än så länge är att man med flit har skiftat runt delar av eeprom-datan så att den inte ska bli enkel att tyda.
Det är inte klart, men det är på gång att få en användbar karta över de intressanta värdena, dock är det inte hundra klart vart vissa nollor hör hemma osv.

Snacket med radiomodulen har jag glott på ett par ggr men gett upp med att få ordning på den, har även kikat i datablad för ISM-kretsar med spi-interface för att se upplägget på de olika (samt kanske ha tur att hitta protokollet).

Den där pdf'en verkar helt klart intressant, det är alltid bra med facit hur andra har tänkt med deras produkter, ska läsa igenom den mer detaljerat någon dag framöver.

[cah]

Upptäckte att om minst signifikanta nibble:n flyttas till början så stämmer det med dina tidigare exempel. Det kan kanske vara till hjälp för att fortsätta att lista ut formatet.


0x0AD0 -> 0x00AD = 173 = 17.3*10
0x5FE0 -> 0x05FE = 1534 = 153.4*10
0x8B71 -> 0x18B7 = 6327 = 632.7*10
0xB1C2 -> 0x2B1C = 11036 = 1103.6*10
0x24E5 -> 0x524E = 21070 = 2107*10

[LasseT]

@kng
Jag har kollat med Conrad idag och de har ingen konkurrerande produkt som kan logga dessa mätare till PC, så gör du en så köper jag den!

[kng]

Det är riktigt att låga nibblen är uppflyttad, men det är inte hundra utrett exakt hur alla beter sig och om det är konsekvent. Det var väl det jag försökte förmedla tidigare, tror jag

Projektet har sakta gått framåt, har suttit och pulat med en avr som ska skicka datan över seriesnöre just nu, men det har strulat lite pga alla konstigheter/störningar i i2c-trafiken. Har valt en atmega88 nu eftersom den har uart som avlastar seriesnacket en hel del och sen använda ren pin-pollning för i2c datan.. Har även en reservplan där en tiny26 får lösa i2c-delen med sin USI (som går att härrja mer med) men då måste man lösa uart i mjukvara och timers.
Som det verkar kan man inte använda TWI från en atmega då den oundvikligen är och fipplar med utgångarna och förändrar trafiken.

Hur som helst, tanken är att den i ett första skede ska rent skicka över en dump av i2c-trafiken, i nästa steg ska den få tolka datan och "fixa till" den sen skicka över de intressanta delarna. Det andra steget är såklart intressant i en mer färdig produkt då man inte ska behöva behandla datan mer utan ska kunna lagra den direkt i en log eller databas.

[kng]

Vet inte om det är fel eller rätt ände att börja i, hade lust att få fram data snabbare istället för att skriva av från Logic... försöker knåpa ihop en i2c sniffer som ska passa denna hårdvara men det är nog mer än ett fel jag gör i min kod.

Aktuell rigg med en Mega88 i centrum och fifflande med debugwire:


I2C är ju ett relativt enkelt protokoll.. förutsatt att man inte hamnar i otakt eller bryr sig om oegentligheter på bussen. Än så länge har jag inte lyckats få någon riktig ordning på det. Bland annat så är det en irrelevant puls på dataledningen då clock går låg (jättetight timing) efter sista bitten och innan nästa byte ska påbörjas som jag tror ställer till det för mig. Det gör ju inte saken bättre av att jag är mest van avr-assembler och försöker göra allt i avr-gcc nu istället...

Det finns lite mer kul data att kika på i http://www.kng.se/voltcraft/bracket/ om någon känner för att kika lite

[cah]

Det går att exportera data från Logic:s analysatorer, åtminstone i senaste versionen 1.1.5.

[kng]

Jo, jag har tidigare provat Logic's exportfunktion för analysatorerna. Det är dock fortfarande problem med att deras analysator nästan alltid tappar bort sista byten innan stop-condition (vilket fordrar manuell analys). Dessutom exporterar den i ett format som är rörigt och blir mestadels manuellt kopierande ändå.
Även deras senaste beta (1.1.5.1) har strul med sista byten.

Får nog köra den tidigare versionen 1.0.33 som generellt är mycket segare än dom nya, den verkar dock inte ha problem med analysen.. sen får man väl skriva ihop något program som stuvar om data från loggarna till rätt ordning. Käns lite onödigt då det inte kommer att behövas senare.

Kod: Markera allt

"6,0408483",Start
"6,0410970",Setup write to 0xA0. +ACK
"6,0422995",Wrote 0x00 to 0xA0. +ACK
"6,0433220",Start
"6,0435819",Setup read from 0xA0. +ACK
"6,0445910",Read 0x00 from 0xA0. +ACK
"6,0457269",Read 0x00 from 0xA0. +ACK
"6,0468589",Read 0x00 from 0xA0. +ACK
"6,0479909",Read 0x00 from 0xA0. +ACK
"6,0491229",Read 0x50 from 0xA0. +ACK
"6,0502418",Read 0xD9 from 0xA0. +ACK
"6,0513409",Read 0x13 from 0xA0. +ACK
...

[kng]

Nu äntligen har jag fått igång en I2C avlyssnare som jag gillar.
Nämligen denna: http://www.mikrocontroller.net/topic/103600

Jag kör den på en tiny25 med 11.0592MHz kristall, det som fanns hemma alltså (:
Var inga större problem att justera koden att funka med 25'an och den frekvensen.
Sen tog jag bort onödiga tecken såsom s/p/a osv, ny rad genererar en linefeed är väl det som är kvar..

Exempel på utdata (CH/+ tryckt):

Kod: Markera allt

A0 00 A1 50 2C 00 00 D0 AB 00 03 00 00 00 50 90 04 00 90 2B 29 2E 94
A0 14 A1 00 08
A4 10 A5 01 00 00 00 00 00 0E 00
A0 16 A1 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Enda dryga är att det är slut på ben på den kretsen, hade först tänkt köra intern oscillator på 8MHz men det visade sig att 5% fel i baudrate var mer än min dator tyckte om.. så de ben som tidigare var tänkta att starta en skanning är numera upptagna av kristallen.
Lösningen är ju så klart att använda en större krets, t.ex tiny261 eller så överlåter man mer jobb åt datorn..
Kom på att man kan använda DTR eller någon annan statusledning att styra scan-knappen med, men det käns inte helt optimalt egentligen.
Originalidén var ju att man i princip skulle kunna logga data direkt till en fil eller databas med godtyckligt program som kan lyssna på serieporten. Nog för att man inte har någon kontroll över när data ska samlas in så är fördelen att det ställer låga krav på programmet i datorn.

Detta blir ju ett öppet projekt med kod/design osv, så det är ju inte så svårt att göra modifieringar och anpassningar man själv behöver.
Jag kommer först och främst att skriva ihop ett program i perl eller liknande, men det hindrar ju ingen att skriva ihop ett i VB eller något för windowslirarna.

Nu ska jag skifta fokus till själva tolkningen av datan istället, hoppas jag får ordning på allt (:

Har lagt upp exempel och kod på: http://www.kng.se/voltcraft/i2csniff/