AutoMower von Elektrolux und Husqvarna

Zitat:

---

Zitat von DigitalKlaus

So, jetzt zu unserer Basisstation mit AVR: Wenn wir diese direkt in ein Ethernet einklinken brauchen wir eine TCP/IP-Schnittstelle.

---

@Harald und Klaus

Die Aufnahme einer TCP/IP-Schnittstelle an der Basis begrüße ich sehr.

Ich möchte gern auch zwei RS 232-Ports an der Basis. Die eine bedient die Schnittstelle zum XBee-Modul, die andere übergibt das Fernsignal für Start/Stop des AM.
Bei unserer gegenwärtigen Lösung mit RN-Funk hat es sich bewährt, dass das Programm sowohl direkt (z.B. Autostart am PC oder Fernsteuerung mit VNC ) aber auch durch eine externe Beschaltung am zweiten COM-Port (virtuell über Ethernet) mittels Scheduler gestartet und gestoppt werden kann.
Die zweite COM ist somit die Übergabestelle des Start/Stop-Signals aus einer unabhängigen Quelle an den ersten COM-Port für das Steuerprogramms, um den AM arbeiten zu lassen.

Zurzeit übe ich das , indem das Steuerprogramm auf einem Laptop läuft und über das LAN die erste COM für das Funkmodul bedient. Das Zeitsteuerprogramm kann auf einem anderen PC im Haus laufen. Die zweite COM ist für den Fernzugriff wichtig, kann aber auch mit physischen Direktsignalen anderer Quellen (Relais der TK-Anlage, Schalter, Schaltuhr usw.) beschaltet werden.

@Harald

Danke für das Test-Angebot - stellen wir das bitte zurück, es ist ein Zeitproblem, außerdem bin ich nicht sicher ob der XPort Sinn macht: Er ist - wie die meisten anderen TCP/IP-Schnittstellen für AVR - für den Anschluß an einen seriellen Port vorgesehen. Der ATmega32 auf dem RN-Control hat nur einen UART, d.h. jede weitere serielle Schnittstelle müßte per Software emuliert werden. Da habe ich Bedenken hinsichtlich Datendurchsatz.

BASCOM bringt das komplette TCP/IP Handling bereits mit, Voraussetzung ist ein W3100A Chip.

BASCOM hat noch weitere interessante Routinen dabei, z.B. ein komplettes RC5 Code Handling für Infrarot (Senden und Empfang) ... mich nerven die paar Taster, vielleicht baue ich zwischendurch einen IR-Empfänger (ggf. TOSP1736) dran und steuere die Test-Basis mit der Philps ProntoPro (programmierbare IR-Universal-FB).

Ja, die Frage mit dem Regler hat sich erledigt - alles läuft sauber und 100% stabil.

@seibot

Danke für die Devolo Infos. Das könnte funktionieren. Vom erfolgreichen Testbetrieb hängt die Entscheidung für eine TCP/IP oder eine Funkstrecke ab. Eine TCP/IP macht nur Sinn wenn die Devolo-Module störungsfrei funktionieren.

Zu den zwei RS232-Ports: Der ATmega32 (und damit das RN-Control) hat nur eine Hard-wre-RS232. Wie gesagt, weitere müßten softwareseitig emuliert werden. Einen Fernzugriff benötigen wir in jedem Fall (ich will nicht immer in die Garage laufen um Änderungen an der Basisstation-Einstellung vorzunehmen oder Statistikdaten vom AM abzuholen).

Die Basisstation sollte grundsätzlich autark sein, deren Zeitsteuerung aber von außen temporär zu überschreiben sein. Das kann natürlich ein Start bzw. Stop Signal sein - die Frage ist, wie das Signal generiert wird.

Wenn ein externes System per Relais einen Stromkreis schließt dann ist das an einem AVR Port erkennbar - ohne RS232. Auf diesem Weg meldet sich im Testaufbau der Regensensor.

Ich stelle mir das so vor: Die Kommunikation mit dem XBee und die externe Steuerung sind hardwareseitig völlig unabhängig werden und durch die (AVR) Programmlogik zentral gesteuert. Das Programm muß auf verschiedene (unabhängige) Ereignisse reagieren, diese interpretieren und entsprchende Aktionen auslösen.

Ich konzentriere mich jetzt auf das Schreiben von Speichervariablen im AM (z.B. Timerflag), Uhr und Routinen für die Zeitsteuerung, wobei die Werte im EEPROM abgelegt werden müssen - später wollen wir die Einstellungen verändern, aber nicht jedesmal neu flashen.

Mehr demnächst - Grüße aus München, Klaus

Zitat:

---

Zitat von DigitalKlaus

@Harald
Zu den zwei RS232-Ports: Der ATmega32 (und damit das RN-Control) hat nur eine Hard-wre-RS232. Wie gesagt, weitere müßten softwareseitig emuliert werden. Einen Fernzugriff benötigen wir in jedem Fall (ich will nicht immer in die Garage laufen um Änderungen an der Basisstation-Einstellung vorzunehmen oder Statistikdaten vom AM abzuholen).

Die Basisstation sollte grundsätzlich autark sein, deren Zeitsteuerung aber von außen temporär zu überschreiben sein. Das kann natürlich ein Start bzw. Stop Signal sein - die Frage ist, wie das Signal generiert wird.

Wenn ein externes System per Relais einen Stromkreis schließt dann ist das an einem AVR Port erkennbar - ohne RS232. Auf diesem Weg meldet sich im Testaufbau der Regensensor.

Ich stelle mir das so vor: Die Kommunikation mit dem XBee und die externe Steuerung sind hardwareseitig völlig unabhängig werden und durch die (AVR) Programmlogik zentral gesteuert. Das Programm muß auf verschiedene (unabhängige) Ereignisse reagieren, diese interpretieren und entsprchende Aktionen auslösen.

---

Ich hatte mich da wohl zur zweiten COM unklar ausgedrückt.

Die LAN-Schnittstelle soll ein zweites COM-Port liefern, damit der Basis über einen anderen Computer oder auch das Internet ein Steuersignal übergeben werden kann. Dieses wird an die AVR-Schnittstelle analog dem Regensensor geschaltet. Die zweite COM ist somit nicht mit dem AVR verbunden, sondern liefert nur das Fernsignal über das Netz.

Hallo Freunde der computergesteuerten Grashalmschnittmaschinen ...

Die erste AVR-Version eines autarken AutoMower Steuersystems läuft momentan im Testbetrieb. Detailinformationen folgen an Vogon, seibot und Harald_nds. Hier in der Kürze die Highlights:

Das System läuft in dem hier vorgestellten Hardware-Testaufbau (mit neuem Regensensor - Danke an seibot für die Information, der Sensor ist deutlich besser!)

Die aktuelle Version bietet folgenden Funktionsumfang:

• - Zeitsteuerung für die AutoMower-Fahrten/Mähzeiten. Es sind mehrere Pläne möglich:
  - 2 Fahrtzeiten für die Wochentage (Mo-Fr, für alle Tage gleich)
  - 2 Fahrtzeiten für die Wochenend-Tage (Sa-So, für beide Tage gleich)
  - Auswahl der einzelnen Tage (Mo-So)
  - Heimfahrt bei Regen (wenn der Regensensor Feuchtigkeit meldet) bzw. erneute Ausfahrt wenn der Regen vorbei ist
  - Wechsel (per Tastendruck, Start und Stop separat) in einen manuellen Modus, unabhängig von der Zeitsteuerung und unabhängig vom Regensensor. Der manuelle Modus bleibt aktiv bis per Tastendruck eine Rückkehr zum Auto-Modus gewählt wird
  - Menuesteuerung (4 x 20 Zeichen LCD)
  - Komplette Steuerung über die 5 Taster auf dem RN-Control Board. Es ist keine alphanumerische Eingabe erforderlich, alle Änderungen werden mit Tasten für +/- Funktionen vorgenommen. Entsprechende Bereiche für komfortable Einstellungen sind definiert.

Konzeptionelle Details

• - Optimierte Funk-Kommunikation mit dem AM: Es werden nur Befehle gesendet, wenn dies wirklich notwendig ist (Status-Management). EEPROM verträgt nur eine begrenzte Zahl Schreibzyklen (100.000?), und wenn wir ständig alle paar Sekunden blind Flags setzen ... nein, sowas macht das Programm nicht.
  - Prüfung ob ein gesendeter Befehl vom AM quittiert wird
  - Optimierter Programmablauf, Prüfungen in sinnvollen Intervallen
  - Quellcode funktional strukturiert für Anpassungen (z.B. zentrale Fuktion für die Tastenerkennung) und Erweiterungen
  - Bedingungsabhängige Kompilierung, sodass Versionen mit oder ohne externe Real Time Clock (DS1307 Chip) erstellt werden können.

Die Timer-Einstellung entspricht grundsätzlich dem AutoMower-Timer. Natürlich ist noch mehr denkbar - bis zur Grenze des verfügbaren Speichers. Momentan belegt das kompilierte Programm 55% Flash RAM.

Noch nicht implementiert
Die folgenden Funktionen erfordern weitere Analysen, Tests und Diskussionen

• - Latenzzeit (möglichst konfigurierbar) für eine "Pause" nach dem Regen. Der AM soll nicht sofort wieder rausfahen, wenn der Regen vorbei ist.
  - LAN-Schnittstelle für Einstellungen und Abfragen von einem PC-Netzwerk aus
  - (AVR) Stromsparmodus während der Nacht
  - Evtl. Ergänzung um einen Temperatursensor
  - Optimierung der Mähzeiten durch Berücksichtigung von Wetterbedingungen (Regen, Temperatur, Jahreszeit und vom AM gesammelte Werte)
  - Datensammlung, d.h. Abfrage des AM, z.B. in der Nacht bei Ruhepause
  - Steuerung durch ein weiteres externes Ereignis (wie von seibot beschrieben
  -

Da wäre sicher noch viel machbar - theoretisch zumindest. Alles wird nicht möglich sein, da ist die Grenze des verfügbaren Speichers zu eng. Evtl. müßte man einen anderen AVR einsetzen, z.B. den 2560 (256 KB Flash, 8 KB RAM, 4 KB EEPROM, 4 TTL UARTS !), wobei dann eine gute Basisplatine, möglichst für die anderen Bauteile, notwendig wird. Das ist ein Thema für später, vielleicht nächstes Jahr.

Alleine ca. 20% des Flash-Speichers beansprucht die Bedienerführung. Wenn - zu einem späteren Zeitpunkt - eine PC-LAN Anbindung realisiert ist, könnte man die Bedienerführung wieder reduzieren und Einstellungen über einen PC vornehmen.

Zur LAN-Anbindung gibt es noch keine endgültigen Pläne. Dazu in ein paar Tagen noch einige Gedanken für die weitere Diskussion. Ich war am Wochenende auf der Suche und muß die Ergebnisse noch ordnen.

Programmiersprache ist AVR-BASCOM. Der Compiler generiert kompakten Code, der Quellcode ist fast wie Pseudo-Code zu lesen. Es gibt unschöne Einschränkungen, z.B. wandelt der Editor den ersten Buchstaben einer Definition, Variablen etc. in einen Großbuchstaben, alles andere ist klein geschrieben (wer hat diesen Unfug erfunden!!!???). Einschränkungen habe ich auch in der Programmstruktur: Was ich als geschachtelte Funktionen gewohnt bin, muss hier oft in Einzelschritte aufgelöst werden.

Irgendwann sehe ich mir "C" für AVR Systeme an, dann könnte sicher noch einiges optimiert werden.

Grüße aus München, Klaus

@Klaus:
Vielen Dank für dein ausführliches Update. Das Projekt macht ja wirklich Riesenfortschritte!

@Alle:
Ich habe noch einmal über das "Problem" mit dem Regen nachgedacht - ich meine ob der paar Tropfen der AM nun reinfahren sollte und wie lange er nach dem Regen drinne bleiben sollte...
Ist es nicht eigentlich so dass wir die RegenMENGE erfassen müssten? Das wäre doch DER Faktor für eine zuverlässige Steuerung des AM! Dafür gibt es doch diese Funkdosen für die Wetterstationen, z.B. eine wie diese:
http://heavyweather.de/product_info....id=256&ref=251
Den Funksender kann man einfach abklemmen, übrig bleibt in der Regel eine Wasserwippe mit einem Dauermagneten und ein Reedkontakt. Das wäre dann sogar wieder ohne Fremdenergie bzw. Heizung. Diese Dinger sollte es bei einem bekannten Auktionshaus oder im Bekanntenkreis recht günstig geben, denn die bekannten runden Ausführungen hatten allesamt ein Problem mit der Haltbarkeit. Meistens war hier der Reedkontakt durch die Temperaturschwankungen aufgeknackt oder aber die Funkelektronik hat eine Macke.
Man müsste halt nur die Flanke vom Reedsensor auswerten, alle paar Tropfen wippt die Wippe einmal kurz über und schliesst den Reedkontakt für den Bruchteil einer Sekunde. Man muß das also an einem Interrupt-Eingang einlesen. Allerdings muss man das Signal über ein RC-Glied bzw. per Software entprellen.

Das nur mal zur Gedankenaustausch!

Gruß, Harald

@harald_nds

Die Methode, die Regenmenge zu ermitteln und danach über die erneute Ausfahrt zu entscheiden, finde ich interessant. So ließe sich vermeiden, dass der AM bei noch zu nassem Gras ausfährt und die Halme nieder legt.
Natürlich ist der Auswerteaufwand höher als beim Ein-/Aus- Kontakt des Regensensors.
Mit einerr Mengenerfassung könnte man die Wartezeit im Programm individuell regeln.

Ich habe nochmals den passiven Keramikmelder getestet. Ich hatte mir erhofft, genau diese Zeitüberbrückung zu ereichen. Das Ding ist auch bei Regenbeginn zu träge, die Trockenzeit zu lang - nicht geeignet.

Update:

Mit ein paar Verbesserungen absolviert das ACP ("AutoMower Control Program") in der Alpha-Version mit meinem System den Testbetrieb. Die Ergebnisse sind OK, besonders die XBee-Module waren ein wichtiger Schritt in die richtige Richtung.

Momentan bin ich an Konzeption für eine (konfigurierbare) Latenzzeit um den AutoMower nach Regen nicht sofort wieder auf die Piste zu jagen. Dazu möchte ich eine minimale Wartezeit vorgeben können, die endgültige Wartezeit ist dann abhängig von der Regendauer. Wenn es z.B. nur 5 Minuten geergnet hat, ist das weniger kritisch als 10 Stunden Regen.

Ich stimme zu, dass eine genauere Messung der Regenmenge bzw. Intensität hilfreich wäre. Das ist dann eine weitere Verbesserung. Die Ergebnisse würden als zusätzlicher Parameter in die Berechnung der Latenzzeit einfließen.

Wichtiger erscheint mir im Moment die LAN-Anbindung. Eine direkte TCP/IP-Schnittstelle kann mit AVR-BASCOM relativ einfach realisiert werden, aber es gibt einen Haken: Dies setzt den W3100A Chip voraus. Den gibt es auf einem IIM/000A Board, das aber 3,3V Betriebsspannung benötigt (wir habne 5V, also wieder Bastelei), außerdem ist ein "Transformer" für den Ethernet-Signalpegel notwendig. Ein komplettes Kit ist wieder zu groß dimensioniert - es kommt gleich mit AVR daher, den wir nicht brauchen, die Platine ist mir außerdem zu groß.

Generell stellt sich die Frage nach der Art der LAN-Anbindung. Ich greife die von Harald bereits eingeworfene Idee eines seriell-to-Ethernet Adapteres wieder auf. Das scheint mir doch der ganbarere Weg zu sein.

Das könnte man dann in unserer Steuersoftware wieder modular gestalten - wie bereits die verschiedenen Varianten der Zeitsteuerung (intern programmierte AVR-Uhr, RTC, oder Zeit vom AM holen). Bzgl. LAN wäre das dann intern ein serielles Interface auf eine Ethernet-Kabelschnittstelle (10/100) oder ein WLAN-Modul.

Gefunden habe ich im Bereich WLAN ein paar Dinge (allerdings relativ teuer ...):

WiPort von Lantronix:

http://www.lantronix.com/device-netw...rs/wiport.html

oder z.B. das EZL-80C von Sollae Systems:

http://elmicro.com/de/eztcp.html

Letzteres benötigt eine CF-WLAN-Karte, von denen es nicht so viele Alternativen gibt. Stromsparend bei guter Reichweite soll die SOCKET
WLAN CF-Card P 500 Low Power (Hersteller-Artikelnr. 754623B ) sein.

Alle diese WLAN-Adapterboards benötigen 3,3 V Betriebsspannung. Da kommen wir um eine Wandelung nicht herum (wie auch immer).

So, jetzt bin ich auf Kommentare und Alternativen gespannt 8-[

Gruß, Klaus

Ein paar Gedanken/Anregungen:

3.3V:
Kann eigentlich nicht das ganze AVR-Board auf 3.3V laufen? Leider kenne ich mich mit der AVR-Linie nicht so aus, bei PIC-Controllern funktioniert alles zwischen 2...6Volt. Ich nehme an, dass das grundsätzlich bei AVR-Controllern genau so ist. Höchtens das andere Peripherie-Komponenten nicht mit 3.3V klarkommen! Welche wären das?

Regensensor:
Natürlich sollte man erstmal mit dem Standard-Regensensor weitermachen bevor man alles wild durcheinander testet! Die Erfassung der Regenmenge bedingt ja auch nur eine andere SW, die HW bleibt ja identisch! Ich mag es ja fast nicht mehr erzählen, aber ich bin schon wieder auf einen neuen Typ Regensensor gestossen:
http://www.gardena.com/servlet/Produ...egory_rn=12862
Das scheint, wenn ich die Bedienungsanleitung richtig interpretiere, eine Art Mischmasch aus Regensensor und Regenmengensensor zu sein. Leider steht dort wenig zum Ausgangssignal, wahrscheinlich ist es ein Open-Collector-Ausgang der im Takt der Lichtschrankenunterbrechnungen geschaltet wird. Das ist aber reine Spekulation. Auf jeden Fall könnte dieser Sensortyp rein theoretisch sowohl kleine Regenmengen erfassen (kann die Funkmessdose nicht da die Wippe nicht kippt) als über die Zählung der Lichtschranken-Unterbrechungen auch Aufschluss über die Menge geben (kann der ursprüngliche Regensensor nur eingeschränkt).

--- UPDATE: Da das Gerät mit nur einer 9V-Batterie über min. 1 Jahr versorgt wird, werden wahrscheinlich keine einzelnen Impulse pro Lichtstrahl-Unterbrechung ausgegeben. Dazu müsste die Lichtschranke daueraktiv sein und das geht von der Energie her nicht. Wahrscheinlich so eine Art elektronisch verbesserte Variante des Rainbird-Sensors (siehe weiter oben). Aber vielleicht funktioniert das ja besser. Mal sehen, vielleicht kann ich so ein Ding zur Ansicht organisieren.


RS232-Interface:
Wir haben es also mit nur einer RS232-Schnittstelle am AVR-Controller zu tun. OK. Könnten wir diese nicht umschaltbar machen? Wir kommunizieren doch nur zu einem von uns bestimmten Zeitpunkt mit dem AM, der hält doch von sich aus die Klappe. Mit einem einfachen Analogschalter á la CD4051/4052/4053 oder einer einfachen Digitallogik aus NAND-Gattern wäre das einfach realisierbar. Einem eingehenden Datenstrom seitens des Ethernet-RS232 könnte man mittels Hardware-Handshake mit RTS/CTS begegnen. Das heisst, in dem Moment wo wir mit dem AM kommunizieren, setzen wir die RTS/CTS auf "nicht empfangsbereit". Sobald die Kommunikation mit dem AM abgeschlossen ist schalten wir RTS/CTS auf aktiv und sehen dann ob Daten eingehen. Auf jeden Fall geht nichts verloren.

WLAN:
hmmm, da habe ich so meine Bedenken. Klaus, Du sprachst doch über deine Bedenken mit der Stahlbeton-Garage. Sollte da WLAN eine gute Alternative sein?

Gruß, Harald

3.3V ist die neuere "stromsparende" Konzeption der AVRs - allerdings bisher nicht so hoch zu takten wie die 5V Versionen. Ich habe den Eindruck, dass da einiges im Umbruch ist, und der Trend zu 3.3V. geht (meine persönliche Meinung). Controllerboards wie das RN-Control habe ich bisher nicht für 3.3V gesehen. Die Eingangsspannung ist variabel und wird auf 5V runter geregelt. 3.3V sind nicht berücksichtigt. Wir hatten das Dilemma schon mit dem XBee(Pro), jetzt kommt sehr wahrscheinlich die nächste Komponente mit 3.3V daher. Ob diese 5 V vertragen ist ungewiß.

Zum Regensensor: Ich wollte keinesfalls die weitere Suche ignorieren, da war mein Beitrag evtl. nicht gut formuliert. Wenn ein guter (und bezahlbarer) Regenmengenmesser gefunden wird, sollten wir uns das Teil ansehen und prüfen wie das softwareseitig zu integrieren ist.

Ethernet: Mit der Stahlbeton-Garage hatte ich Bedenken wegen DCF-77. Das würde sehr wahrscheinlich nicht funktionieren. (Kurioses am Rande: Meine Küchenuhr, umgebaut mit einem DCF-77 Uhrwerk von Conrad, läuft einwandfrei, während ein DCF-77 Modul für PC am Server unbrauchbar war ... sehr wahrscheilich ist die PC-Software kompletter Müll, die Daten werden nicht richtig ausgewertet).

WLAN sollte gehen (werde ich demnächst mit dem Laptop testen). Mit Kabel-Ethernet hätte ich ein Problem, da ich kein neues Kabel legen kann bzw. will (Aufwand!). Daher die WLAN-Idee. Vielleicht geht es auch anders, mit regulären Ethernet-Anschluß und einer Ethernet WLAN-Bridge. Ein USB-WLAN-Adapter scheidet aus, da diese Teile einen Windows 2000/XP/Vista Treiber erfordern und USB am RN-Control wäre wieder ein Seriell-to-USB ...

Es geht auch ohne serielle Schnittstelle: MCS (von denen der AVR-BASCOM kommt) hat im Shop Ethernet-Module die über den I2C Bus gesteuert werden:

http://www.mcselec.com/

dort: Shop, Hardware, Embedded Ethernet. Das "Easy TCP/IP TWI Adapter Board" (5,95 Euro) ist alleine lauffähig (Motherboard nicht erforderlich) und kann per AVR-BASCOM über den I2C Bus gesteuert werden - die Library ist im BASCOM enthalten. Läuft mit 3.3V, I/O Signale bis 5 Volt. Also wieder 3.3V Betriebsspannung (von 12V 5V auf 3.3v mit einem Spannungsregler).

Eine zweite RS232 könnte man per Software emulieren (komplett inkl. DTR/DSR). Das bring Overhead, aber was macht das Controllerboard denn sonst? Es läuft programmtechnisch im Kreis, prüft in jeder Runde den Kalender und wartet auf Ereignisse. Da ist noch viel Luft für Aktionen. Die Kommunikation mit dem AM ist mit 9600 Baud und 5 Bytes hin und zurück in längeren Intervallen auch nicht gerade "heavy load". Es wäre interessant, die AM-Kommunikation testweise auf auf eine Software-RS232 zu legen und zu sehen was passiert.

Bleibt mir noch das Problem vom Haus zur Garage zu verbinden. "Devolo" ist schon fast rausgefallen: Es sind zwei strikt getrennte Stromkreise (Außenanlagen erfordern nicht nur einen separaten Stromkreis, sondern eine zusätzliche Absicherung, da müßte ein Phasenkoppler rein und das ist mir zuviel Aufwand - und zu teuer, denn da muß der Elektriker ran, selbst basten ist nicht bei 220V).

Gruß, Klaus

Zitat:

---

Ich wollte keinesfalls die weitere Suche ignorieren, da war mein Beitrag evtl. nicht gut formuliert.

---

Das habe ich auch nicht so aufgefasst, ich kam mir selber schon etwas komisch vor mit den ganzen Regensensor-Vorschlägen :-)

Software-UART ist beim Senden kein Problem - das funktioniert bei niedrigen Baudraten auch beim PIC hervorragend. Das Problem ist der Empfang, weil die SW aufgrund des Timings ziemlich genau auf die fallende Flanke des Startbits pollen muss. Also muss die Software an der entsprechenden Stelle ausharren und kann nichts anderes machen. Würde mich wundern wenn das bei BASCOM anders ist. Die einzige Chance aus dem Dilemma wäre ein Interrupt-Eingang, der die fallende Flanke auswertet - aber ist das so realisiert?

DCF77 vs. WLAN: Wenn WLAN geht funktioniert DCF-77 schon lange. Längstwelle breitet sich im Erdboden(!) aus, je höher die Frequenz wird umso mehr kommt es auf (Quasi-)Sichtverbindung an. Das mit deiner PC-Applikation kann ich mir schon vorstellen dass das nicht gut funktioniert hat. Der Langwellen-Empfang funktioniert nämlich nur nachts richtig gut und kann sich wie deine Küchenuhr am besten um 3..4 Uhr nachts synchronisieren (bzw. nch Batteriewechsel). Die PC-Dinger haben meist keine eigene Echtzeituhr und keine Batterieversorgung, insofern erfolgt die Synchronisierung mehr oder weniger erfolglos im PC-verseuchten Umfeld tagsüber. Und wenn dann die SW keine sehr gute Fehlererkennung hat (reine Paritätsauswertung reicht hier keinesfalls) gehts halt nicht vernünftig. Die meisten Wanduhr-Module bzw. die Chipsätze kommen aus dem Umfeld von HKW-Elektronik/Thüringen, den Link hatte ich schon weiter oben gepostet. Und die haben ein Riesen-Know-How auf diesem Sektor.

Aber wenn die AM-Uhr verwendet werden kann gefällt mir persönlich das immer noch am besten!

Ethernet: Die Module sind ja richtig preisgünstig! Wenn das so einfach funktioniert - warum nicht?! Das einzige "Problem" ist wahrscheinlich die starke Anbindung an BASCOM und desssen Treiber. Eine Umsetzung auf C ist dann eher schwierig.

Gruß, Harald