Hallo Leute, ich plane einen Teil meiner "Hauselektronik" zu erneuern und brauche einen Ratschlag. Ist-Zustand: Beck SC13 der über DS2482-800 momentan 20 DS18B20 ausliest sowie von zwei Quellen (Gas, Strom) zwei S0-Signale empfängt. Der SC13 bzw. die Beck-Libraries erlauben die problemlose Verarbeitung von externen Interrupts via ISRs, die ich für die Auswertung der S0-Signale verwende. Der Rest via I2C ist eher Kinderkram. Das ganze wird via Socket (TCP) an einen Host geschickt der dies wiederum in eine Oracle-DB schreibt. Die Verwendung der Daten (Heitungssteuerung und Auswertung) lasse ich an dieser Stelle einfach außen vor da diese ja bleiben soll. Das Ganze läuft seit ca. 5 Jahren 24/7 mit relativ wenig Problemen. Warum dann umstellen? Den SC13 gibt es nicht mehr. Relativ hoher Stromverbrauch (und Wärmeentwicklung). Grottenschlechte Entwicklungsumgebung. Ich möchte in Zukunft mehr als 2 S0-Signale verarbeiten (neu: Wasser sowie eine weitere Strom-Messung). Avisierter Zustand: Ein Raspi, der die o.g. Aufgaben übernimmt aber die Daten nicht mehr via (proprietärem) Socket-Protokoll abliefert sondern sie gleich in eine remote (auf dem Host laufende) MySQL-DB schreibt (leider kein Oracle-Client für ARM verfügbar). Sollte der Kontakt zum Host abbrechen (Stromausfall, der Pi wird Batterie-gepuffert) wird solange in eine "lokale" SQLite-DB geschrieben, bis der Host wieder da ist um dann alle Daten von der lokalen zur remoten DB zu transportieren. Soweit so gut. Software dafür sowie I2C ist kein Problem. Der alles entscheidende Punkt sind die S0-Signale. Hier komme ich nicht weiter. Ich weiß dass es prinzipiell die Möglichkeit gibt, so etwas wie ISR auf dem Pi zu verwenden. Es wird aber von überall gewarnt dass es hier keine Priorisierung gibt und u.U. Signale (Flanken) verloren gehen können. Das aber will ich unbedingt vermeiden. Meine momentane Idee ist es, einen ATmega328 (Arduino, wegen der Einfachheit der Tool-Chain) zu verwenden, der die S0-Signale empfängt, die Zeiten (zwischen zwei Flanken == Verbrauchs-Momentanwert) misst und diese dann vi UART oder I2C (Slave) an den Raspi schickt. Softwaremäßig würde ich mir das auch zutrauen und sehe da auch keine großen Probleme. Aber: ich möchte die Anzahl der S0-Kanäle auf 4 erweitern und der ATmega328 besitzt nur 2 ext. Interruptus. Ich könnte auf einen Mega2560 ausweichen, der 8 ext. Interruptus besitzt, scheue mich aber vor der Idee so ein "Monster" selbst zu verbauen (PCB-Design, löten). Der ATmega328 (DIL, Fassung, extern programmieren) wäre mir da deutlich lieber. Vielleicht wäre es auch möglich ein Eingangsbyte zu pollen (es gibt doch da so eine Fast-IO-Lib). Wie gestalte ich dann meine Timebase? Eine Möglichkeit wäre es, Timer1 im Hintergrund (mit Auto-Reload) laufen zu lassen (Überlauf mitzählen) und dann im 'main' einfach eine Schleife mit max. Speed laufen lassen, dabei die Eingänge (als Byte) pollen und bei Veränderung L->H (vorherigen Zustand sowie Timer1-Wert - getrennt für jeden Kanal bzw. Eingang gemerkt) die abgelaufene Zeit berechnen. Wird ein bisschen tricky (Überlauf berücksichtigen) aber sollte gehen. Dann aber noch die Kommunikation mit dem Host. Verwende ich I2C muss ich dem Host signalisieren, dass Daten zur Verfügung stehen (oder der muss ständig I2C-pollen, besser nicht). UART wäre hier besser, einfach Daten senden. Während ich das schreibe, frage ich mich gerade, ob ich nicht auch mit dem Raspi seine PIOs pollen kann. Ich würde mal sagen, 1k/s reichen. Wie hoch ist dabei die CPU-Belastung. Muss ich testen. Hat jemand Ideen oder Anmerkungen dazu? Was ist Eurer Meinung nach der beste Weg?
Danke für den sehr "freundlichen" Hinweis. Aber um des Friedens Willen, ich habe mir mehr als die ersten 4 Seiten durchgelesen - und verstehe immer noch nicht was das mit dem Problem "Interfacing S0 into the Raspberry.Pi" zu tun hat. Speziell, nachdem ich meine Zielkomponenten (sowie die Erklärung zur Entscheidung für dieselben) ja relativ deutlich dargelegt habe. Der CGMMSTICK ist sicherlich kein schlechtes Teil, ich (ich persönlich also) bleibe aber lieber bei einer überschaubaren Anzahl von zu verwendenden Controllern. Da ich derer schon einige "im Programm" habe möchte ich mein Repertoire nur ungern erweitern - und sehe auch keine Notwendigkeit dazu.
na weil das Teil, basierend auf dem modernsten PIC, das alles kann was Du benötigst und beispielsweise 20 ext. Interrupts besitzt und auch all Deine Peripherieanforderungen erfüllt. Und so ein rasend schneller Interpreter ist für Test und Entwicklung eine extrem angenehme Umgebung, nebst Eignung als Zielplattform..... Die Beck Entwicklungsumgebung beschreibst Du ja selbst als sehr schlecht. Der Stick kostet übrigens keine 20 Euronen.
Enrico F. schrieb: ..schnipp.. > Aber: ich möchte die Anzahl der > S0-Kanäle auf 4 erweitern und der ATmega328 besitzt nur 2 ext. > Interruptus. wieso? Jeder PIN ist als Interruptquelle nutzbar >siehe PCINTx Sascha
@Sascha Gut recherchiert. Aber wie der Name es vermuten lässt handelt es sich um "Pin-Change-Ints" die noch dazu alle in einem einzigen Interrupt-Vector landen. D.h. dass ich in diesem dann als erstes einen Poll machen muss, um herauszufinden welcher Pin es war. Da kann ich auch gleich (Loop-)pollen ... Wenn der Chip sonst keine weiteren Tätigkeiten ausführen soll fände ich das (in diesem speziellen Fall) auch gar nicht so schlimm ... und ich freunde mich auch immer mehr mit dem Gedanken an :) In einer solchen (sehr schnellen) Loop könnte man auch problemlos einen Tiefpass einbauen und spart sich so eine externe Entprellung.
@6502oldpapa Bitte, bitte nicht falsch verstehen und bitte auch nicht persönlich nehmen: ich entwickle seit 16J. beruflich in C/C++, auf beinahe jeder bekannten Plattform (OS) inkl. einiger Exoten, "rasend schnell" ist für mich Assembler, schnell ist C, evtl. noch C++, aber einen Interpreter als "rasend schnell" zu bezeichnen ... "Die Beck Entwicklungsumgebung beschreibst Du ja selbst als sehr schlecht." Deswegen will ich ja auch weg davon. Für den Rasp.Pi verwende ich Eclipse, für den Arduino die gleichnamige "IDE". Vielleicht nicht "top notch", speziell die letzt genannte, aber OK. Was mich ebenfalls davon abhalten würde den CGMMSTICK zu verwenden, ist die Verfügbarkeit. Wer weiß wie lange das "Projekt" noch lebt. Einen Atmega328 wird es sicherlich noch einige Jahre geben ... und dem Rasp.Pi traue ich auch einen langen live-cycle zu.
das ist doch kein Problem, du schließt alle Eingänge an einen Port an. In der ISR liest du den ganzen Port ein und machst ein XOR mit einem gespeicherten Wert vom letzten Durchlauf - und schon hast du den/die Pins die sich geändert haben. ODER: du nimmst INT0, INT1 und die zwei restlichen von zwei verschiedenen Ports - schon hast du 4 INTs mit eigener ISR. Sascha
....für einen Interpreter ist der mmbasic Interpreter definitiv rasend schnell. Abhängigkeiten bezüglich Verfügbarkeit sehe ich hier nicht, oder ist die Aversion gegen einen PIC in diesem Forum so groß ? Komplette ERP Lösungen des damaligen Marktführers Nixdorf ( 80 er Jahre) liefen in einem Interpreter. Das war schon bemerkenswert wie ein Bekannter damals in laufenden ERP Umgebungen großer Automobilhersteller on The fly Kundenwünsche in der Software umsetzte. Etwas komfortableres ist mir bis heute nicht mehr begegnet. Ich muss heute zwar keine Eproms mehr unter die Höhensonne legen, dennoch besteht der Zyklus immer aus programmieren, compilieren, flashen, testen und wieder von vorn beginnen..... Es hängt halt immer von den Anforderungen ab, wer heilt hat recht ;-)...
Interpreter schrieb: > Abhängigkeiten bezüglich Verfügbarkeit sehe ich hier nicht, oder ist die > Aversion gegen einen PIC in diesem Forum so groß ? Nein, zumindest von meiner Seite keine Aversion. Und ich glaube auch, dass der Interpreter für viele Dinge (die Meisten?) schnell genug ist (vlt. auch für mein Ziel). Aber das ist nicht so sehr die Frage, sondern vielmehr wieviel Aufand es mich kostet vs. eine mir (und das nicht nur oberflächlich) bekannte Plattform (Arduino) zu verwenden, für die ich sowieso schon "eingerichtet" bin. Bei der Verfügbarkeit meinte ich mehr das kpl. Board (CGMMSTICK) als den PIC.
Hallo Enrico, ein interessantes Projekt mit einigen Fragestellungen die mir auch schon untergekommen sind. Zum Stromverbrauch: Der Beck SC13 zieht laut Datenblatt 1,3W. "Ein Raspberry Pi Modell A verbraucht 2,5W (5V, 500 mA), ein Modell B 3,5W (5V, 700mA)." Falls Atmega: Der Arduino Ethernet Shield basiert auf dem Wiznet W5100, der benötigt 150-180mA. Die 3.3V stammen aus Linearreglern, also 5V*180ma -> 0.9W. Dann besser Wiz820IO, basierend auf W5200 -> 0.5W im Betrieb, und dann entweder den Power Down Modus benutzen oder die Spannungsversorgung nur für jede Übertragung aktivieren. Für den Wiz820IO kann die Arduino Ethernet-Lib mit einer kleinen Änderung weiter verwendet werden. Wenn der Stromverbrauch wirklich minimal werden soll, solltest du den uC immer wieder in den Stromsparmodus schicken. Dann kann die Software aber nicht pollen sondern muss Timer- und Interruptgesteuert gebaut werden. Zur S0-Messung: Ein S0-Impuls hat eine minimale Dauer von 30ms. Das ist eine Ewigkeit. Es werden dir also keine Impulse verlorengehen. Ich denke, dir geht es um die Messung der Zeit zwischen zwei Impulsen, um jederzeit den aktuellen Verbrauch zu ermitteln? Aber wie genau muss es denn sein? Bei einem S0-Impuls pro Wh bewirkt ein Stromverbrauch von 3600W einen Impuls pro Sekunde, und eine Änderung auf 3610W bewirkt einen Impulsverkürzung um 2770uS. Solch "lange" Zeiten zu messen wird weder für den Raspi noch für einen uC irgend ein Problem sein. Der Raspi-Prozessor kalibriert zwei Mal pro Sekunde den SDRAM-Refresh und hält dabei für einige uS an, aber erstens lässt sich das mit disable_pvt=1 ausschalten (siehe http://www.raspberrypi.org/phpBB3/viewtopic.php?f=37&t=7696) und zweitens wird der Messfehler (bei obigen Annahmen) unter 1/10W liegen. Beim Ansatz mit Atmega ist die gemeinsame ISR für alle Pin Change Interrupts nicht wirklich ein Problem, und auch nicht die auch hier fehlende Priotisierung. Zur Datenübertragung: Bei meiner Hausüberwachung überträgt ein Arduino Ethernet minütlich Sensor- und Heizkesseldaten über HTTP an ein CGI-Script bei meinem Webhosting-Provider (DF). Als minimale Sicherheit überprüft das CGI-Script einen ebenfalls übermittelten Hashcode, der aus dem Datenpaket und einem Passwort gebildet wird. Das CGI-Script fügt die Daten dann in eine MySQL-Datenbank ein. LG, Sebastian
Hallo Sebastian,
Danke für Deine ausführliche Antwort.
>> Der Beck SC13 zieht laut Datenblatt 1,3W.
Ich gebe zu, ich habe die Stromaufnahme noch nicht gemessen, hole ich
morgen Früh nach. Was aber auffällt ist, dass das Teil so heiß wird,
dass man es nur kurz berühren kann. Daher meine Einschätzung.
Mit der Stromaufnahme des B-Modells kann ich leben.
Einen Atmega hatte ich zusätzlich zum R.Pi in Erwägung gezogen, um die
Zeitmessung der S0-Impulse damit zu realisieren und den R.Pi damit zu
entlasten. Irgendwie gefällt mir die Idee immer mehr, vor allem in
Verbindung mit I2C als Kommunikation (Atmega als Slave). Diese
Teilkomponente kann man dann auch recht einfach testen und in Betrieb
nehmen.
Das mit der Länge der S0-Impulse ist klar - und ja, es geht um eine
möglichst hohe (Betonung auf "möglichst" - aber eben nicht mehr als das)
Genauigkeit. Ich habe bei der Berechnung mal max. 10kW zu Grunde gelegt.
Ein Wert, der sicherlich nur selten zustande kommt (Weihnachten,
Backofen, Herd, Waschmaschine und Trockner im Keller sowie Spülmaschine
in der Küche läuft, Licht überall an, so kommen ganz schnell 10kW
zusammen). Bei 1000Imp/kWh kommt man bei 10kW auf eine Zeit zw. zwei
Impulsen von 360ms. Bei einer Ungenauigkeit von 1ms, also einem
gemessenem Wert von (in diesem Beispiel) von 361ms würde ein Wert von
9972W, also 28W zu wenig angezeigt. Bei einem Wert von bspw. 300W wäre
der resultierende Fehler (bei 1ms Messungenauigkeit) deutlich kleiner
(angezeigt: 299,975W). Ich denke, das wäre so in etwa die Genauigkeit
die ich mind. anstrebe.
Man lernt nie aus, das Projekt "Panalyzer - a RaspberryPi based Logic
Analyzer" (Dein Link) ist wirklich bemerkenswert und eine tolle Quelle
für neue Ideen (Softwaretechnisch).
Mit dem Arduino Mega2560 + Ethernet Board habe ich auch ganz gute
Erfahrung gemacht. Es gab auch eine Zeit, in der ich darüber nachdachte,
die aktuelle Konstellation damit zu ersetzten. Ich hätte aber wie
bereits beschrieben ganz gern eine möglichst lückenlose Aufzeichnung
(vor allem der Temperatur sowie zukünftig auch einiger Wetter-Daten).
Hin und wieder muss der Host mal angehalten werden (oder tut es vlt.
auch mal von selbst). Kommt selten vor aber eine "Lücke" in der
Datenbank ärgert mich immer. Vielleicht ist man ja auch mal ein paar
Tage nicht da und kann nicht sofort reagieren. Dafür dann die SQLite
"on-board", das bekommt man mit dem Atmega so nicht hin (natürlich kann
man sich etwas einfallen lassen und auf eine SD-Karte schreiben, die
SQLite ist in dem Moment einfach die "Luxusvariante").
Hallo Enrico, bei Raspi und Atmega über I2C solltest du beachten: "There is a bug in the [Raspi] I2C master that it does not support clock stretching ..." (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=13771). Bei meiner Kommunikation zwischen Raspi und Attiny (http://tilda.googlecode.com) habe ich die I2C-Clockrate auf dem Raspi ich glaube auf 94kHz reduziert um den Fehler zu umgehen. LG, Sebastian
Hallo Sebastian, komme erst jetzt dazu zu Antworten, Sorry. Also, bitte streiche aus meinem ersten Posting die Bemerkung mit der Stromaufnahme, erst messen, dann beschweren :) Die kpl. Platine zieht gerade einmal 150mA, also knapp 3,5W. Der Raspi ist da keine Verbesserung. Aber, die anderen Punkte (hauptsächlich die Seite der Entwicklungsumgebung sowie der Entwicklung selbst - Compiler etc.) stehen eher im Vordergrund. Vielen Dank für den wertvollen Tipp bezüglich des Clock-Stretching. Ohne diesen hätte ich sicherlich Stundenlang versucht, den Fehler zu finden. Und obwohl ich prinzipiell I2C-"Sattelfest" :) bin, weiß ich wie ein solcher Fehler einen zur Verzweiflung bringen kann. Ich habe ein paar C++ Klassen geschrieben die nahtlos "ineinander" greifen (bzw. aufeinander aufbauen) - von der Möglichkeit eigene I2C Hardware zu verwenden (Bit-Bang oder am PC via RS232), über das Versenden/Empfangen (inkl. Timing) bis hin zu einzelnen Klassen (die auf die darunter liegenden aufbauen) für alle von mir verwendeten I2C-Devices. Je nach Verfügbarkeit von Hardware- bzw. Software-Support im Host setzten meine Klassen weiter oben oder unten an. So kann ich erst einmal die Kommunikation mit dem Slave am PC codieren und testen und wenn diese Lösung dann tut was sie soll auf den Ziel-Host portieren. Mit dem o.g. Problem hätte ich dann wohl einige Fragezeichen über meinem Kopf gehabt ... und u.U. zu einem Bit-Bang-Mode übergegangen. Speed ist in meinem Fall glaube ich nicht so sehr das Thema, die 4 S0-Kanäle á 16Bit und einer geschätzten Impulsfrequenz von max. 2Hz würden mir auch die 50kHz I2C-Frequenz reichen.
Enrico F. schrieb: > Ist-Zustand: Beck SC13 ... > Das Ganze läuft seit ca. 5 Jahren 24/7 mit relativ wenig Problemen. > Avisierter Zustand: Ein Raspi Ich hätte da so meine Bedenken, ob ein Raspberry Pi so lange problemlos läuft. Als Schwachstellen hätte ich die SD-Karte und das Netzteil im Visier.
Schau Dir mal www.udoo.org an. Da hast Du Linux/Android und Arduino auf einem Board. Der Pi ist zwarganz nett, aber auf billig designt, z.B unterdimensionierte Treiber und Spannungsregler. Für die Lehre oder als Spielerei ist das egal, für den Dauerbetrieb nicht. Und Ethernet über USB wäre mir auch nicht zuverlässig genug. Alternative: BeagleBoneBlack. Die Hardware macht mir auch einen zuverlässigeren Eindruck, und Du hast viel mehrIOs als beim Pi. fchk
... schrieb: > http://wiki.volkszaehler.org/hardware/controllers/... Danke :) ... hatte ich weiter oben schon zitiert :)
Frank K. schrieb: > Schau Dir mal www.udoo.org an. Da hast Du Linux/Android und > Arduino auf > einem Board. > > Der Pi ist zwarganz nett, aber auf billig designt, z.B > unterdimensionierte Treiber und Spannungsregler. Für die Lehre oder als > Spielerei ist das egal, für den Dauerbetrieb nicht. Und Ethernet über > USB wäre mir auch nicht zuverlässig genug. > > Alternative: BeagleBoneBlack. Die Hardware macht mir auch einen > zuverlässigeren Eindruck, und Du hast viel mehrIOs als beim Pi. > > fchk Vielen Dank für den Tip! Das Board auf www.udoo.org sieht vielversprechend aus. Preislich auch völlig ok bzw. im Rahmen. Die von Dir angesprochenen Punkte bzgl. Spannungsregler und USB2Eth. gefallen mir auch nicht sonderlich. Ich würde dem Rasp dennoch (bis auf Wiederruf, das muss dann einfach die Zeit zeigen) den Vorzug geben. Warum? Ganz großer Punkt für den Rasp ist die Verfügbarkeit und die Verkaufszahlen. Hohe Verkaufszahlen sind (mein Empfinden/Meinung) ein Motor für Weiterentwicklung und Verbesserungen (hoffentlich kompatibel). Sehr gut gefällt mir BeagleBoneBlack. Ich bekomme seit einiger Zeit immer wieder Werbemails von TI (hatte mal beruflich mit denen zu tun), eine Dieser bewarb den BeagleBoneBlack. Cooles Teil. Ich denke ich werde mir einen besorgen und mal "unter die Lupe" nehmen :) Das wäre für mich tatsächlich eine Alternative zum Raspi, weil ich hier bzgl. der o.g. Punkte mind. das gleich Potential sehe (scheinbar auch noch gepusht von TI). Mit der gleichen CPU habe ich auch ein "AM335x Starter Kit" von TI hier "rum-liegen" ... allerdings ist mir dieses Teil schon zu "bulky". Beste Grüße!
Alexander Schmidt schrieb: > Enrico F. schrieb: >> Ist-Zustand: Beck SC13 ... >> Das Ganze läuft seit ca. 5 Jahren 24/7 mit relativ wenig Problemen. >> Avisierter Zustand: Ein Raspi > Ich hätte da so meine Bedenken, ob ein Raspberry Pi so lange problemlos > läuft. Als Schwachstellen hätte ich die SD-Karte und das Netzteil im > Visier. Hallo Alex, das mit der SD-Karte macht mir auch "zu schaffen". Allerdings "leiden" alle solchen "Einplatinen-Computerchen" :) unter diesem Problem. Wie ich oben schon schrieb, soll der Rasp ja (auch wegen der Bedenken in Hinblick auf die SD-Card) seine Daten an eine remote MySQL-DB abliefern und nur im Notfall die Daten lokal speichern. Swapping etc. ausschalten, alle unnötigen Schreibzugriffe auf die SD unterbinden, evtl SSD via USB (durch die Größe des SSD und dem ausgefeilten wear-leveling hat diese dann schon ein beachtliches Leben - in hinblick auf die zu erwartenden Datenmengen), das sind so meine Ideen um dem Problem zu begegnen. Beim Netzteil, hmm, wie könnte man es besser machen? Gibt es besser Komponenten als die drei Spannungsregler auf dem Board? Wenn ja welche? Und, wie hoch sind die Drei tatsächlich ausgelastet? Wie schon in einem meiner vorherigen Postings, die Zeit wird zeigen wie gut oder schlecht das alles für Langzeitanwendungen bemessen ist. Beste Grüße.
Enrico F. schrieb: > und dem Rasp.Pi > traue ich auch einen langen live-cycle zu. Ich nicht. Der Broadcom-SOC ist ein Consumerprodukt, und ich glaube nicht, dass der mehr als 5 Jahre verfügbar ist (und er hat ja schon einige Jahre rum). Er wurde gewählt, weil er billig ist, und das ist typisch für den Comsumermarkt: Billig, in kurzer Zeit hohe Stückzahlen verkaufen, und in einem Jahr kommt wieder was neues. Das siehst Du ja auch an der PC-Welt. Versuch mal ein, für ein zwei Jahre altes Mainboard einen exakten Ersatz in der gleichen Revision nachzubestellen. Du wirst Dich wundern, wie kurz die Produktzyklen hier sind. Wenn Du Langzeitverfügbarkeit willst, bist Du hier komplett falsch. Automotive verlangt 15 Jahre Verfügbarkeit, die Industrie 10 Jahre. Freescale garantiert z.B., dass der iMX.53 bis 2026 verfügbar ist. DAS sind doch ganz andere Dimensionen, oder? Weiterer Grund: Der Broadcom-Chip ist nur ein ARM11, also eigentlich schon veraltet. Aktuell sind die ARM Cortex Architekturen, also hier A8/A9. fchk
Ich habe mir den AVR-NetIO http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html auf die Hutschiene in meinen Zählerkasten eingebaut. Der hat 4 A/D Wandler auf seine Schraubleiste herausgeführt, mit denen polle ich die S0 Ausgänge meiner Stromzähler. Der netio hat ne Ethernet Schnittstelle, die geht in ein PLC modem im Schaltschrank. Ganze Setup kost nix, braucht wenig Strom, kann aber nichts speichern. Deswegen lasse ich den ATMega auf dem netio alle drei Minuten ne email mit den Daten schreiben, dann brauche ich keinen 'Server' ständig laufen haben und Google zahlt den Strom für die Speicherung der Daten. Mit nem script hole ich die Daten gesammelt ab und pflücke sie für die Datenbank auseinander. Läuft seit Jahren super. Cheers Detlef
Detlef _a schrieb: > Ich habe mir den AVR-NetIO > > http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetz... > > auf die Hutschiene in meinen Zählerkasten eingebaut. Der hat 4 A/D > Wandler auf seine Schraubleiste herausgeführt, mit denen polle ich die > S0 Ausgänge meiner Stromzähler. Der netio hat ne Ethernet Schnittstelle, > die geht in ein PLC modem im Schaltschrank. Ganze Setup kost nix, > braucht wenig Strom, kann aber nichts speichern. Deswegen lasse ich den > ATMega auf dem netio alle drei Minuten ne email mit den Daten schreiben, > dann brauche ich keinen 'Server' ständig laufen haben und Google zahlt > den Strom für die Speicherung der Daten. Mit nem script hole ich die > Daten gesammelt ab und pflücke sie für die Datenbank auseinander. > > Läuft seit Jahren super. > Cheers > Detlef Das Teil kenne ich auch :) Beinahe hätte ich gesagt "warum einfach wenn's auch umständlich geht" (alle drei Minuten ne email, pflücke sie für die Datenbank auseinander) ... aber ich sag's nicht :) Auf die Art und Weise ist aber leider keine Momentanverbrauchsanzeige möglich ... und auf die möchte ich nicht verzichten :) Beste Grüße.
Frank K. schrieb: > Enrico F. schrieb: >> und dem Rasp.Pi >> traue ich auch einen langen live-cycle zu. > > Ich nicht. Der Broadcom-SOC ist ein Consumerprodukt, und ich glaube > nicht, dass der mehr als 5 Jahre verfügbar ist (und er hat ja schon > einige Jahre rum). Deine Argument klingen plausibel und "erschlagend" - es ist aber weniger der Chip (CPU) selbst auf den ich setzte, sondern vielmehr das Format (Größe, Pinheader usw.). Falls Rasp irgendwann die CPU gegen eine andere austauscht aber die Sourcen von meiner Software 1:1 portierbar sind, bin ich zufrieden.
Enrico F. schrieb: > Deine Argument klingen plausibel und "erschlagend" - es ist aber weniger > der Chip (CPU) selbst auf den ich setzte, sondern vielmehr das Format > (Größe, Pinheader usw.). Das wird dann Dein geringstes Problem sein, denn das lässt sich per Adapterkabel innerhalb weniger Minuten anpassen. fchk
Ein Rasperry wäre mir für den Kleckerkram schon zu viel. Nimm ein Board mit einem Cortex M3 was Ethernet und SD-Karte an Bord hat. So was oder was ähnliches: http://www.embeddedartists.com/products/app/aoa_kit.php Die Messdaten werden erst mal auf SD geschrieben und parallel versucht eine weitere Task die Daten an den Server los zu werden. Da kann auch mal länger die Verbindung fehlen. Das ganze braucht dann deutlich weniger Strom und ist zuverlässiger. Mir wird immer warm ums Herz wenn man liest wieviele Zeilen Quellcode (Linux + Treiber + ...) verballert werden um so eine relativ triviale Aufgabe zu lösen. Nicht das man die selber schreiben müßte, aber in 10Mil. Zeilen Quellcoden stecken garantiert mehr Fehler als in 10000.
Hallo Enrico, ich komme vermutlich etwas spät, aber ich bin einen ähnlichen Weg gegangen wie Du das willst (oder wolltest). Ich verarbeite die S0-Impulse auf einem Arduino und sende sie per USB an einen Logger (bei mir eine Fritz!Box mit der Software FHEM). Mir war es auch wichtig, keine Signale durch Polling zu verlieren. Als ich die Implementierung dann fertig hatte, habe ich aber gesehen, dass die Signaldauer meiner Zähler ca. 70ms beträgt - das ist eine Menge Zeit. Heute sehe ich deshalb keine Vorteile mehr für die Interrupt-getriebene Verarbeitung - die Software dafür habe ich trotzdem geschrieben. Die ganze Geschichte und den Arduino-Code findest Du bei Bedarf unter http://forum.fhem.de/index.php?t=msg&th=13155
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.