Smart Meter auslesen

Knickohr

BASCOM-Experte
29. Feb. 2008
465
0
16
Sprachen
Ihr habe ja lange nichts mehr von mir gehört, aber ich war immer da und habe mitgelesen. Hier meine neueste Frickelidee : Wie lese ich den elektronischen Stromzähler von meiner Bude aus ?

Na, man baut sich eine kleine Schaltung die das infrarote Geblinke des Zählers umsetzt und über USB an einen PC weiter gibt :dance3:

Sooo einfach isses nu auch nicht, es hab mehrere Monate gebraucht, bis ich die nötigen Informationen zusammen gesammelt und eine passende kleine Platine dazu gemacht habe. Doch von Anfang an. Vor etwas über 2 Jahren, als meine Eltern gestorben sind, mußte ich die Wohnung komplett neu renovieren. Die beiden waren demenzkrank und haben quasi die Bude von innen raus zerstört. Also kam gleich der Gedanke auf, die komplette Elektroinstallation ebenfalls auf den neuesten Stand zu bekommen. Und so habe ich auch gleich diese neumodischen modernen elektronischen Zähler installieren lassen :

P1020044.jpg


Die Zähler waren noch nicht lange drin, da fiel mir schon auf, das sie eine Infrarotschnittstelle zur Außenwelt hatten. Das Auge rechts oben an den Zählern muß eine Art Schnittstelle sein :

P1020051.jpg


Beim Fotografieren bemerkte ich auch, das dieses "Auge" mit mir "redet". Man erkennt im Kameradisplay immer wieder violette Lichtimpulse. Diese Impulse sind mit dem Auge nicht wahr zu nehmen, da es Infrarotlicht ist, die Kamera sieht es aber :

P1020052.jpg


Nun ging das große Suchen im Internet los. Wie funktioniert der Zähler, welches Protokoll sendet er, wie kann man die Signale abgreifen und umwandeln, gibt es bereits Software dafür, ist vielleicht sogar schon eine Auswerte- und Interfaceelektronik vorhanden ? Bei diversen Studien im Internet, in gewissen Foren, wurden auch Schaltungen vorgeschlagen. Die entsprechen aber nicht meinen "Anforderungen", waren zu primitiv und zu sehr Möchtegerngebastel, so das ich mir doch eine eigene Schaltung entwickelt habe :

Schaltplan.gif


Die Schaltung ist universell und kann wohl für die meisten Zähler verwendet werden. Außerdem ist die komplette USB-Schnittstelle bereits mit integriert. Das Platinenlayout sieht dann so aus :

Platine.gif


Meine bisher am dichtesten bepackte Miniplatine. Die Leiterbahnen sind gerade mal 0,5mm stark, aber es soll ja alles in ein passendes Gehäuse direkt auf dem Zähler passen. Die Platine habe ich schon seit ein paar Monaten bei irgendeinem Auftrag mitmachen lassen :

P1020035.jpg


Gerade mal 23mm Durchmesser hat diese Winzplatine, aber ihr seid ja nichts anderes von mir gewöhnt :yes4: Bestückt sieht das dann so aus :

P1020036.jpg


Nun nehmen wir ein altes USB-Kabel und zwicken den Stecker von der Geräteseite ab. Die 4 Adern werden mit der Platine verbunden :

P1020037.jpg


Und schon haben wir einen Schreib-/Lesekopf für das Infrarotauge der elektronischen Zähler. Da ich die Schreibfunktion nicht benötige, fehlt auch die Sendediode. Einige Zähler müssen aber aufgefordert werden, etwas zu senden, deshalb ist das auf der Platine auch gleich mit vorgesehen. Das Kabel mit der Schnittstelle sieht dann so aus :

P1020038.jpg


Fehlt noch ein passendes Gehäuse für das Teil. Bei Shapeways (3d-Printing) habe ich mit ein Gehäuse aus Kunststoff drucken lassen. Dazu kommt noch ein Neodym-Magnet, der das Ganze magnetisch auf dem Zähler befestigt :

P1020039.jpg


Der Ringmagnet wird in das Gehäuse eingelegt, darauf kommt ein ausgeschnittener Papierring zur Isolation :

P1020040.jpg


Dann die kleine bestückte Platine einlegen und das Gehäuse verschrauben :

P1020041.jpg
 
(suppi, man kann hier nur 15 Grafiken in einem Beitrag einfügen :fie: Deshalb gleich einen Doppelpost dazu :sarcastic: )


Na, sieht doch ganz brauchbar aus. Wie gekauft :dirol: Vorderseite :

P1020042.jpg


Rückseite :

P1020043.jpg


Also "kleben" wir das Ding mal an einen Zähler dran uns schauen, was passiert :

P1020045.jpg


Hier noch etwas größer, damit man es auch besser erkennen kann :

P1020046.jpg


Jepp, da fliegen die Daten. Der Zähler liefert mir alle 1 bis 2 Sekunden ein komplettes "Telegramm" über alle gespeicherten Verbrauchsdaten. Aus dieser Zahlenwurst muß ich die Werte noch raus fischen :

Protokoll.jpg


Diese 324 Bytes enthalten alles, was der Zähler speichert. Es ist ein sogenanntes SML-Protokoll (Smart Messaging Language). Jetzt muß ich "nur" noch ein entsprechendes Stück Software schreiben, das mir diese Daten da leserlich darstellt.

.... to be continued ...

Thomas
 
Hi Thomas,

sieht ja richtig professionell aus :cool: (Aber mit Lochraster bekommt man das noch kleiner :p)

Das geht ja schon beinahe wieder an Reverse-Engineering dran ;) Ich laß mich echt mal überraschen wie das Protokoll nun aussieht und was alles drinsteckt. Bei nem Industriebetrieb wo ich mal vor nem Zählerkasten stand war da alles mögliche drauf zu sehen. CosPhi, Blindleistung, Wirkleistung und was weiß ich noch alles.

Gruß
Dino
 
Ein paar Beispiele :

SML.jpg


Das rosane ist die Startsqeuenz für SML :

1B 1B 1B 1B - Start Escape Zeichenfolge
01 01 01 01 - Start Übertragung Version 1
76 - jetzt kommt eine SML-Message

Das rote ist die Wirkarbeit Bezug (+) Zählerstand Total, das grüne die Wirkleistung Total.

So kann man sich die ganzen Werte da raus fummeln. Muß nur noch wissen, wie die Werte zu lesen sind, denn im Hexcode kann ich so noch nix anfangen.

Thomas
 
Sooo,

ich hab mal das SML-Protokoll ein bißchen auseinander geflöht :

Code:
1B1B1B1B - Start Escape Zeichenfolge
01010101 - Start Übertragung Version 1

7605 - SML-Message + transactionId
06C64A2C - transactionId

6200 - groupNo 00
6200 - abortOnError Ausführung fortsetzen

72630101 - messageBody

7601 - SML_GetList_Res + clientId (not set)
0105024218BA
0B0649534B01027A231797 - ServerID
0101 - refTime + smlVersion
638E3B - crc16 (Checksumme nach CCITT-CRC16)
00 - SMLEndOfMessage

7605
06C64A2D
62006200726307
01

7701
0B0649534B01027A231797

0701
00620AFFFF

72620165 - actSensorTime -> Aktuelles Datum und Zeit der Real Time Clock
031D63F877 - 13377992823 Sekunden => 11.08.2013 13:17:12 MEZ -> 11.08.2013 12:17:12 MESZ

7707 - valListEntry (sequence) + objName
8181C78203FF - Herstelleridentifikation
0101010104 - status, valTime, unit, scaler -> not set + value
49534B - I S K -> ISKRA - Hersteller
01 - valueSignature = not set

7707 - valListEntry (sequence) + objName
0100000009FF
010101010B0649534B01027A231797
01 - valueSignature = not set

7707 - valListEntry (sequence) + objName
0100010800FF - Wirk- Energie Total Bezug
6500000182
01621E - valTime = not set + unit Wh
52FF59 - scaler ??? müßte /10 sein
0000000003DE95A1 - 6491.894,5Wh
01 - valueSignature = not set

7707 - valListEntry (sequence) + objName
0100010801FF - Wirk- Energie Tarif 1 Bezug
0101621E - status = not set + valTime = not set + unit Wh
52FF59 - scaler ??? müßte /10 sein
0000000003DE95A1 - 6491.894,5Wh
01 - valueSignature = not set

7707 - valListEntry (sequence) + objName
0100010802FF - Wirk- Energie Tarif 2 Bezug
0101621E - status = not set + valTime = not set + unit Wh
52FF59 - scaler ??? müßte /10 sein
0000000000000000 - 0,0Wh
01 - valueSignature = not set

7707 - valListEntry (sequence) + objName
01000F0700FF - Wirk- Leistung Total
0101621B - status = not set + valTime = not set + unit W
520065 - scaler = 1
00000183 - 387W
01 - valueSignature = not set

7707 - valListEntry (sequence) + objName
8181C78205FF - Public Key des Zählers
01010101 - status = not set + valTime = not set + unit = not set
8302BD191EE9B4816EB2990D6EFD69DB80673ECE2FC385B3D5B7EBD5DE6460E2E0EA58DEDF8E151A841034435AB7BF77E5A901010163C80E00760506C64A2E62006200726302
01 - valueSignature = not set

7101 - listSignature (not set) + actGatewayTime (not set)
630B5A - crc16 (Checksumme nach CCITT-CRC16)
00 - SMLEndOfMessage
-- Erweiterungsbyte (bis Anzahl Byte modulo 4 = 0)
1B1B1B1B - Ende Escape Zeichenfolge
1A - Ende der Nachricht
00 - Anzahl Erweiterungsbyte
8F28 - Checksumme gesamte Nachricht (CCITT-CRC16)

Na, sehr viel kommt da nicht raus, aber immerhin. Ich kann die Energie und die Leistung ablesen. Werde das nun in einen kleinen Linix-PC schieben und dort zerpflücken. Dann kommt noch eine grafische Aufbereitung dazu, die mir das Ganze auf meiner Webpage darstellt.

Thomas
 
Das Projekt ist (fast) beendet :cool:

Mein Zähler loggt jetzt sauber auf einen kleinen Miniserver :

slugwithaudio.jpg
unslung.png


... und stellt die Informationen grafisch dar :

leistung-p.gif


Jetzt muß ich nur nur die anderen 3 Zähler über einen USB-Hub anschließen und auswerten. Im Prinzip einfach nur den Code duplizieren und das wars dann schon.

Thomas
 
Wow, werde erst jetzt auf dein Projekt aufmerksam. Ganz klasse!

Das kannst du ja quasi vermarkten ... :flute:
 
Hi,

könnte man heute auch nen RasPi für einsetzen. Ließe sich sogar noch besser an den Atmel koppeln.

Gruß
Dino

Prinzipiell schon. Ich persönlich würde dafür aber eher sowas hier nehmen:

CubieBoard: klick mich

CubieBoard 2: klick mich

Vorteile gegenüber RPi:
-> SATA
-> vernünftig angebundener USB
-> mehr Speicher
-> mehr Leistung
-> mehr GPIOs

Okay, zugegeben, das Ding kostet auch "etwas" mehr.
 
Hallo Knickohr,
hab man deine Markierte Stelle, dass rote sool ja die Wirkarbeit Bezug sein eingebeben.

Irgendwie bekomme ich bei deinen Hex „Zahlen“ nichts brauchbares geboten, siehe Foto.


Hab ich da wo einen „Systemfehler“ gemacht ?

Gruß
 

Anhänge

  • Hex auslessen .png
    Hex auslessen .png
    455,3 KB · Aufrufe: 22
Rot markiert ist (HEX):
Code:
77 07 01 00 01 08 00 FF 65 00 00 01 82 01 62 1E 52 FF 59 00 00 00 00 03 DD 7D 69 01
Knickohr schrieb dazu:
7707 - valListEntry (sequence) + objName
0100010800FF - Wirk- Energie Total Bezug
6500000182
01621E - valTime = not set + unit Wh
52FF59 - scaler ??? müßte /10 sein
0000000003DE95A1 - 6491.894,5Wh
01 - valueSignature = not set
Wäre also hier:

7707 - valListEntry (sequence) + objName
0100010800FF - Wirk- Energie Total Bezug
6500000182
01621E - valTime = not set + unit Wh
52FF59 - scaler ??? müßte /10 sein
0000000003DD7D69 - ??? Wh
01 - valueSignature = not set

Also 0x03DD7D69 dWh (deziWh, wegen dem Scaler)
0x03DD7D69 dWh = 64847209 dWh = 6.484.720,9 Wh
 
Sehr interessant ;)
 
Leider scheinen auch hier wesentliche, extern eingebundene Inhalte verloren gegangen zu sein.
Immerhin steht in #5 noch was zur Interpretation der Daten, und in #14 wurde eines der Bilder in den Forenspeicher gerettet...

Ok, ich bin das jetzt mal mit der, bei mir installierten "modernen Messeinrichtung" (DVS7420.1H) angegangen...
Die Test-Schaltung ist so simpel gewesen, daß sie den Namen nicht verdient - einen "SFH 309 FA-4"-Fototransistor und ein 10k-Widerstand direkt an einen USB-TTL-Wandler gesteckt (also VUSB<--Widerstand-->RxD<--Fototransistor-->Gnd).
hTerm auf 8N1@9600baud und den Transistor vor die Sendediode gehalten - dann purzeln im Sekundentakt Telegramme wie dieses ein:

1B 1B 1B 1B 01 01 01 01 76 05 66 01 77 03 62 00 62 00 72 63 01 01 76 01 01 02 31 0B 0A 01 44 5A 47 00 03 65 E2 A6 72 62 01 65 05 99 2E EC 62 02 63 26 F1 00 76 05 67 01 77 03 62 00 62 00 72 63 07 01 77 01 0B 0A 01 44 5A 47 00 03 65 E2 A6 07 01 00 62 0A FF FF 72 62 01 65 05 99 2E EC 73 77 07 01 00 60 32 01 01 01 72 62 01 62 00 62 00 52 00 04 44 5A 47 01 77 07 01 00 60 01 00 FF 01 72 62 01 62 00 62 00 52 00 0B 0A 01 44 5A 47 00 03 65 E2 A6 01 77 07 01 00 01 08 00 FF 64 1C 01 04 72 62 01 62 00 62 1E 52 03 63 30 11 01 01 01 63 3A 4E 00 76 05 68 01 77 03 62 00 62 00 72 63 02 01 71 01 63 26 01 00 00 1B 1B 1B 1B 1A 01 6D 9D

Also erstmal auch hier
77 07 - valListEntry
01 00 - Elektrizität und Kanal 0
01 08 00 - Obis-Kennzahl "1.8.0*FF", also salopp der Gesamt-Zählerstand

Danach wird's im Reverse-Engineering etwas komplizierter der Zähler hatte 12??? kWh auf der Uhr, und sollte erst bei 999999 kWh überlaufen. Irgendwo hätte ich wie auch oben ein paar mehr Nullen erwartet. Also über Nacht das Auto etwas "betankt", und dann die Telegramme mit neuem Zählerstand (+12kWh) verglichen - hat mich einige Tassen Kaffee gekostet, aber irgendwann war folgendes klar:
Nur die lila Bytes sind in diesem Falle mein Zählerstand, und zwar in vollen kWh. 12307.
Aber mit zwei Bytes käme man so nur bis 65535 - das paßt nicht zum sechsstelligen Display des Zählers... -> später

Nach Anforderung habe ich irgendwann den Zähler-PIN vom Versorger bekommen und eingemorst, und dann erstmal die Pineingabe aus-, und den erweiterten Datensatz eingeschaltet.
Jetzt sehen die Telegramme so aus:

1B 1B 1B 1B 01 01 01 01 76 05 81 02 9D 03 62 00 62 00 72 63 01 01 76 01 01 02 31 0B 0A 01 44 5A 47 00 03 65 E2 A6 72 62 01 65 05 A6 06 7C 62 02 63 62 1E 00 76 05 82 02 9D 03 62 00 62 00 72 63 07 01 77 01 0B 0A 01 44 5A 47 00 03 65 E2 A6 07 01 00 62 0A FF FF 72 62 01 65 05 A6 06 7C 74 77 07 01 00 60 32 01 01 01 72 62 01 62 00 62 00 52 00 04 44 5A 47 01 77 07 01 00 60 01 00 FF 01 72 62 01 62 00 62 00 52 00 0B 0A 01 44 5A 47 00 03 65 E2 A6 01 77 07 01 00 01 08 00 FF 64 1C 01 04 72 62 01 62 00 62 1E 52 FF 65 07 63 B4 F5 01 77 07 01 00 10 07 00 FF 01 72 62 01 62 00 62 1B 52 FE 53 0B 02 01 01 01 63 8A 26 00 76 05 83 02 9D 03 62 00 62 00 72 63 02 01 71 01 63 C5 D9 00 00 1B 1B 1B 1B 1A 01 7E 21

Aus der 03 ist jetzt ein FF geworden, das Scheint das Unterscheidungskriterium zwischen vereinfachtem und erweitertem Datensatz zu sein. Diesmal passen vier Bytes zum Zählerstand: 07 63 B4 F5 entsprechen 123974901. Denkt man sich das Komma vier Stellen nach links, werden 12397,4901kWh draus - paßt. Aber auch hier wäre bei FF FF FF FF = 429496,7295kWh Schluß - nicht mal die Hälfte für das Display... -> später

Außerdem findet sich hier auch Obis-Kennzahl "16.7.0xFF" für den Gesamtstrom (leider keine einzelnen Phasen, die scheint er nicht über die optische Schnittstelle, sondern nur über die elektrische auszugeben (für das Smartmeter-Gateway - käme man aber wegen Verplombung eh nicht ran)).
Hier hat 0B 02 zum Verbrauch gepaßt - 28,18W. Würde auch hier nur bis 655,35W reichen, also mal das nächste Telegramm mit höherer Stromaufnahme eingesehen:

1B 1B 1B 1B 01 01 01 01 76 05 84 02 9D 03 62 00 62 00 72 63 01 01 76 01 01 02 31 0B 0A 01 44 5A 47 00 03 65 E2 A6 72 62 01 65 05 A6 06 7D 62 02 63 74 55 00 76 05 85 02 9D 03 62 00 62 00 72 63 07 01 77 01 0B 0A 01 44 5A 47 00 03 65 E2 A6 07 01 00 62 0A FF FF 72 62 01 65 05 A6 06 7D 74 77 07 01 00 60 32 01 01 01 72 62 01 62 00 62 00 52 00 04 44 5A 47 01 77 07 01 00 60 01 00 FF 01 72 62 01 62 00 62 00 52 00 0B 0A 01 44 5A 47 00 03 65 E2 A6 01 77 07 01 00 01 08 00 FF 64 1C 01 04 72 62 01 62 00 62 1E 52 FF 65 07 63 B4 F8 01 77 07 01 00 10 07 00 FF 01 72 62 01 62 00 62 1B 52 FE 54 02 34 3B 01 01 01 63 5D 5A 00 76 05 86 02 9D 03 62 00 62 00 72 63 02 01 71 01 63 96 54 00 00 00 00 00 1B 1B 1B 1B 1A 04 20 C1

Der Zählerstand entspräche jetzt also mit 07 63 B4 F8 12397,4904 kWh (also 0,3Wh/s).
Auffälligerweise sind es jetzt vier Bytes mehr. Drei Nuller-Füllbytes direkt vor der Endsequenz, und das vermutete Byte beim Strom.
Stromaufnahme also hier 02 34 3B = 1444,43W.

Das Byte davor scheint also (auch) die Anzahl der auszuwertenden Bytes festzulegen. Beim Strom stehen die 53 für zwei Bytes und 54 für drei (die würden bis knapp 168kW reichen, also 3x243A - das gibt der Hausanschluß eh nicht her. Bis 2,55W würde auch ein Byte reichen - dann könnte aus der 53 'ne 52 werden, aber ich wollte jetzt nicht deswegen alle Leitungsschutzschalter oder FIs ausschalten/auslösen.

Ob das mit den Zählerständen ebenso paßt , werd ich auch frühestens in gut 50000kWh (reduzierter Datensatz) in Erfahrung bringen können - also über den Daumen mindestens 10 Jahre. Wenn der Zähler bis dahin nicht getauscht werden muß...
 
ok, experimentell hab ich bereits 'n Raspberry Pi 4B auf dem 'ne InfluxDB läuft, die durch Grafana visualisiert wird.

Derzeit werden die Daten zweier DS18B20 direkt am Raspi in die Datenbank geloggt (via cronjob) sowie ein paar Daten vom KFZ via Web Request ausgelesen (und auch geloggt).
Des weiteren hab ich noch 'nen ESP8266 mit 'nem BME280 dran, der via WLAN Temperatur und Luftfeuchte in die Datenbank einspeist. (Außerdem kann man die Onboard-Led über einen (nicht näher genannten Sprachassistenten) ansteuern...)
Erstmal nur Spielkram...

wie erfasse ich jetzt sinnig die Stromzählerdaten in die Datenbank?
Zuerst hatte ich an 'ne direkte Anbindung meines "Hightech-Messkopfes" an den RxD des Raspi gedacht - aber auf dem RasPi kann ich höchstens rudimentäres Python, und da finde ich irgendwie nichts, was sich halbwegs sinnig umsetzen läßt. Also sowas wie'n ReceiveCompleteIRQ oder so.
Im Moment schwebt mir ein kleiner Tiny direkt im Messkopf vor, der die relevanten Daten filtert, die Stromaufnahme über 256 Sekunden mittelt (dabei aber Extrema erfaßt), und das ganze als String weiterleitet.
Also kürzere Telegramme und etwa alle 5min statt im Sekundentakt.
Bleibt immer noch das Problem, das auf dem Raspi entgegenzunehmen. Statt das zu pollen habe ich testweise einfach mal dessen UART aktiviert (und auf die Konsole geschaltet gelassen), und'n toten ESP8266 als USB-UART-Wandler mißbraucht (der geht nämlich da noch).
Wenn der Raspi startet erscheint irgendwann der übliche Login-Prompt via hterm, nach einloggen mit Passwort kann man den Raspi dann wie gewohnt über dessen Kommandozeile mit hterm bedienen.

Grundsätzlich könnte ich also 'nen AVR 'n Telegramm senden lassen, welches auf dem Raspi 'n Python-Script starten, welches seinerseits die via Parameter übergebenen Daten in die InfluxDB einbaut und Und ein Ok oder so zurückgibt.

Entsprechend wären also anderthalb laufende UARTs auf dem AVR nötig.
Mal vorsichtig 'ne Frage an die BASCOM-Profis hier: ist das ganze mit'nem ATtiny25 zu machen (davon hab ich (auch in Anbetracht der Chipkriese) genug hier...)? Quick'n'dirty mit BASCOM??
@Cassio ?
Oder wer auch immer sich angesprochen fühlt???


Also quasi gleichzeitig zweimal Software-UART-Receiver und einen Transmitter (der sich allerdings mit dem Empfänger vom Zähler abwechselt)?
Der UART des Stromzählers läuft mit 9600Baud, der des Raspi bisher mit 115200, aber der läßt sich möglicherweise noch drosseln. Der Tiny könnte mit internem RC-Oszillator mit 8 oder 16MHz (über die PLL) getaktet werden, und bei Soft-RxD könnte man auf jede erkannte Flanke Synchronisieren...
2kB Program-Flash und 128 Bytes SRAM wären natürlich 'ne Herausforderung.

Die Aktion von damals mit dem Tiny10 würde ich jetzt nicht unbedingt wiederholen/weiterentwickeln wollen...
( Soft-RxD mit 8fach Oversampling und Auswertung der mittleren drei Samples wie das auch die Hardware macht (bei gesetztem U2X-Bit und mit Majority Rules). Mit Paritätsbit-Kontrolle.
Der verwendete einzige Timer hat nebenbei PWM ausgegeben, das empfangene Byte die Pulsbreite gesteuert.
Clever fand ich damals den Trick mit dem Bit-Toggeln für die Parität: verwendet hatte ich das PIN-Register-Bit des Reset-Beins. Dessen PORT und PIN Register Bits sind zwar vom Bein wegen Overrides abgekoppelt, aber der konventionelle Zugriff auf die Bits geht trotzdem, und die sind direct bit accessible. Ein setzen des PIN-Bits (mit SBI) toggelt das PORT-Bit (welches man mit SBIS/SBIC auswerten kann).
Insgesamt hatte ich das ganze in 134 Bytes Code gepreßt (13,1% des einen(!) kB Flash), und bin mit Fünf der sechzehn(!) Rechenregistern ausgekommen (von den 32 Bytes SRAM hab ich gar keins verwendet). Und dabei waren da noch ein paar Debugging-Ausgaben über Bein B2 drin).
 
Thomas scheint seit etwa sieben Jahren hier nicht mehr aktiv zu sein - ich übernehme den Topic jetzt einfach mal frech...

Die Konsole des RasPi kann wie gesagt auf den UART geschaltet werden, beim Start erscheint dann folgendes am TxD (mit 115200bd):
Time [ s]Analyzer NameDecoded Protocol Result
0.000000000000000Async Serial'0' (framing error)
24.803992562500000Async Serial\r
24.804080687500001Async Serial\r
24.804168812499999Async Serial\n
24.804257000000000Async SerialD
24.804345125000001Async Seriale
24.804433249999999Async Serialb
24.804521375000000Async Seriali
24.804609500000002Async Seriala
24.804697624999999Async Serialn
24.804785750000001Async Serial' '
24.804873874999998Async SerialG
24.804962000000000Async SerialN
24.805050125000001Async SerialU
24.805138249999999Async Serial/
24.805226375000000Async SerialL
24.805314500000001Async Seriali
24.805402687499999Async Serialn
24.805490812500000Async Serialu
24.805578937500002Async Serialx
24.805667062500000Async Serial' '
24.805755187500001Async Serial1
24.805843312499999Async Serial1
24.805931437500000Async Serial' '
24.806019562500001Async Serialr
24.806107687499999Async Seriala
24.806195812500000Async Serials
24.806283937500002Async Serialp
24.806372062499999Async Serialb
24.806460187500001Async Seriale
24.806548312499999Async Serialr
24.806636500000000Async Serialr
24.806724625000001Async Serialy
24.806812749999999Async Serialp
24.806900875000000Async Seriali
24.806989000000002Async Serial' '
24.807077124999999Async Serialt
24.807165250000001Async Serialt
24.807253374999998Async Serialy
24.807341500000000Async SerialS
24.807429625000001Async Serial0
24.807517749999999Async Serial\r
24.807605875000000Async Serial\n
24.807694000000001Async Serial\r
24.807782187499999Async Serial\n
24.807870312500000Async Serialr
24.807958437500002Async Seriala
24.808046562500000Async Serials
24.808134687500001Async Serialp
24.808222812499999Async Serialb
24.808310937500000Async Seriale
24.808399062500001Async Serialr
24.808487187499999Async Serialr
24.808575312500000Async Serialy
24.808663437500002Async Serialp
24.808751562499999Async Seriali
24.808839687500001Async Serial' '
24.808927874999998Async Seriall
24.809016000000000Async Serialo
24.809104125000001Async Serialg
24.809192249999999Async Seriali
24.809280375000000Async Serialn
24.809368500000001Async Serial:
24.809456624999999Async Serial' '

Am Anfang also fast 25s bevor's losgeht - ich kann also den Tiny25 problemlos an den Spannungsausgang des RasPi hängen.

115200bd sind natürlich 'n ordentliches Tempo für den Tn25. Als erstes hatte ich bei 'nem neuen Tiny also die CKOUT-Fuse aktiviert -> 1MHz an CLKO (PB4)
CKDIV8 deaktiviert -> jetzt warens 8MHz, paßt.

Als Clocksource die PLL ausgewählt -> immer noch 8Mz???
CKDIV8 wieder aktiviert -> 2MHz - das würde passen
???
Der Logic8 sollte die 16MHz eigentlich können, oder?

Also mal andersrum getestet: CKOUT deaktiviert, Timer0 (kann selbst nicht direkt über die PLL getaktet werden) auf Prescaler=1 gesetzt, B4 als Ausgang, und dann in einer Endlosloop TOV0 gepollt, und bei Überlauf B4 getoggelt (SBI PinB.4), undnatürlich das TOV-Flag zurückgesetzt...
Etwa 31,8kHz am Bein...
16MHz/256=62,5kHz, und da jedesmal nur getoggelt wird, nochmal durch zwei: sollten also 31,250kHz sein. Etwas zu schnell, aber paßt etwa...

Als nächstes hatte ich etwa folgendes geplant:
ein Soft-UART-Rx für den Stromzähler und ein ein Soft-UART-Rx/Tx für den RasPi.
Für jeden steht ein eigener 8-Bit-Timer bereit, und ein eigener PinChangeIRQ (PCINT0 und INT0)
Bei jeder Flanke synchronisiert der entsprechende Timer auf die halbe Bit-Zeit, bei ganzer Bit-Zeit läuft der Timer dann über, dann...

...wird der Pegel des entsprechenden Beines in ein Register (nennen wir es einfach mal UDR) gerollt.

So'n UART-Transfer sieht ja so aus:
Code:
_______       _____ _____ _____ _____ _____ _____ _____ __________________
...Idle\Start/ LSB X B1  X B2  X B3  X B4  X B5  X B6  X MSB / Stop...Idle
        ¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯¯
Also initialisiere ich "mein" UDR mit 0xFF, und takte bei jedem Timerüberlauf den Pegel rein. Im Idle werden dann immer "Einsen" durchgeschoben, sobald Daten kommen, wird als erstes das Startbit durchgeschoben. Wenn dieses rausgeschoben wird - also im Carry landet - enthält das UDR ein komplettes empfangenes Byte.
Das Startbit ist immer "0", also kann man mit BRCC/BRCS wunderbar drauf reagieren, das UDR auslesen und mit 0xFF reinitialisieren.

Ich hatte also schon 'nen Schaltplan und weitgehend 'n Layout für den Lesekopf, als mir einfiel, daß der Tiny eine USI besitzt...
index.php

Im 3WireMode kann statt SCK-Flanken oder Soft-Strobes auch ein Compare-Event von Timer0 genutzt werden - das würde natürlich das eintakten erheblich vereinfachen, das Timing entlasten...
aber:
  • gesendete/empfangene Bytes müssen "umgedreht" werden (UART ist LSB-first, USI MSB-first)
  • Beim Empfang landet das Startbit (normalerweise) irgendwann als MSB im USIDR, und setzt den DO-Pin auf "0" - um das zu umgehen müßte am einfachsten beim Empfang DO als Eingang mit aktiviertem Pullup geschaltet werden (bei 3WireUsi bestimmt USIDR.MSB den DO via Override, wenn DO Ausgang ist. Ist DO Eingang, legt das PORT-Bit wie immer den Pullup fest)
  • Wann wird beim 3wire ins USIBR gepuffert??
  • beim Senden muß zwischendurch "nachgeladen" werden, da zusätzlich ja Start und Stop ausgegeben werden müssen
  • Mit dem USI bin ich natürlich auf (ganz andere) Beine festgelegt - Schaltplan usw nochmal von vorn...

P.S. @Dirk : Tabellenkopf ist auch im dunklen Modus weiß - mit weißer Standard-Schriftfarbe ist der nicht mehr lesbar...
Und die ASCII-Grafik mit den UART-Bits hatte ich auch irgndwie besser in Erinnerung - keine Ahnung, wie das damals ging...
 
Durch die Festlegung auf das USI als Kommunikationskanal und den zweiten Pin-Interrupt für den anderen Kanal, steht der Schaltplan eigentlich weitgehend fest.
Da USI auf den ISP-Pins liegt, verwende ich einfach den konventionellen ISP-Header um die Platine zu kontaktieren.
Da INT0 auf SCK liegt, muß der Lesekopf außerdem während des flashens vom Zähler entfernt werden...
B3 und B4 sind quasi ungenutzt, also hab ich LEDs für die Statusausgabe dranngehängt, B4 kann sogar eingeschränkt PWM-Ausgabe.
B5 bleibt Reset...
Schaltplan:

Lesekopf_sch.png

Layout:
Lesekopf_brd.png
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)