AutoMower von Elektrolux und Husqvarna

[DigitalKlaus]

@seibot

Das Devolo-Netz hatte ich glatt übersehen - es könnte eine echte Alternative sein. Dann brauchen wir das "Framing" mit den XBees nciht. Einfacher ist besser. Dazu ein paar Fragen (bei Devolo habe ich nur wenige Informationen gefunden):

- Funktioniert die Übertragung auch wenn es sich um getrennte Stromkreise handelt? D.h. die Verbindung der Stromkreise besteht nur im Sicherungskasten.
- Gibt es hinsichtlich der Entfernung eine Beschränkung? Bei mir liegen zwischen Stromkreisen im Haus und der Garage ca. 40 Meter.
- Wie ich das verstehe, stellen die beiden Devolo Adapter dann eine Standard-Ethernet-Leitung dar. Ein Adapter kann am Router bzw. Switch hängen, der andere ist der Endpunkt für ein Ethernet-fähiges Gerät

@Alle

So, jetzt zu unserer Basisstation mit AVR: Wenn wir diese direkt in ein Ethernet einklinken brauchen wir eine TCP/IP-Schnittstelle. So etwas gibt es als fertiges Modul, z.B. so etwas:

http://olimex.com/dev/enc28j60-h.html

(auf die Schnelle gefunden, es gibt sicher noch andere Module).

Der AVR-BASCOM hat bereits Funktionen für TCP/IP, die Ansteuerung geht z.B. über SPI. Damit benötigen wir keine zweite RS232.

Das R8C13 würde ich trotzdem nicht ignorieren. Eine "Intelligenz" im AM könnte bei diversen Aktionen helfen.

Die RTC ist eingetroffen - von Futurlec (Australien), abgeschickt aus Thailand, ging per Luftpost relativ schnell. So sieht das Teil jetzt aus:

So, jetzt zu unserer Basisstation mit AVR: Wir brauchen dann eine TCP/IP-Schnittstelle. So etwas gibt es als fertiges Modul, z.B. so etwas:

http://img183.imageshack.us/img183/705/rtcminiof2.jpg

(auf die Schnelle gefunden, es gibt sicher noch andere Module).

Der AVR-BASCOM hat bereits Funktionen für TCP/IP, die Ansteuerung geht z.B. über SPI. Damit benötigen wir keine zweite RS232.

Bild hier  

Ansteuerung über den I2C Bus. Für ca. 5 Euro (ohne Porto) macht es keinen Sinn so etwas selbst zu bauen - da kostet mich die Zeit kalkulatorisch mehr ...

Stand der Software-Forschung (ich konnte es nicht lassen und habe gestern zu später Stunde weiter entwickelt): Das AVR-Board kann sich jetzt per XBee mit dem AM unterhalten. Dabei hat Vogon's Grundlagenforschung geholfen. Bevor ich die Software weitergebe wird es noch etwas dauern: Es gibt noch Ungereimtheiten und die Architektur (Struktur) muß überarbeitet werden. Es ist momentan alles "sehr experimentell" - mit einem AVR sieht die serielle Kommunikations teilweise doch anders aus als am PC, zudem hat der AVR-BASCOM ein paar Eigenheiten (erfordert oft Einzelschritte in Konstrukten bei denen ich eine andere Technik gewohnt bin).

Ich habe bisher einfache Datenabfragen getestet, z.B. Akkuspanning, Temperatur etc. Dabei fällt mir auf, dass der Header in der Antwort immer korrekt ist, aber von den beiden Daten-Bytes manchmal das erste fehlt (?) und dafür eine binäre Null angehängt wird. Die Gesamtlänge des Telegramms stimmt immer, nur mit den beiden Datenbytes ist das etwas seltsam. Das Problem muß auf der Empfängerseite liegen - evtl. die XBee Konfiguration oder ein Timing-Problem in der Software - obwohl die Interrupt-gesteuert jedes Byte liest und - im experimentellen Aufbau - stur wartet bis 5 Bytes angekommen sind. (Da muß später per Timer ein Timeout eingebaut werden.)

@Harald: Könnte da evtl. die Adapterplatine mit dem Spannungswandler mitspielen? Aber warum sind es nur die Daten-Bytes (4 und 5), das nicht immer, während Bytes 1-3 immer 100% korrekt ankommen.

Update: Die AVR-AM Kommunikation läuft jetzt fehlerfrei!

Das Problem war, wie ich schon vermutet hatte, eine Timing-Schwäche. Vermutlich generiert AVR-Bascom teilweise zu schwerfälligen Code, sodass sogar eine Interrupt-Service-Routine, die ein Register liest und den Wert an einen Buffer anhängt, zu langsam ist. Ich habe das geändert und verwende jetzt "Serial Buffered Input" - da wird Zeichen lesen und Buffer Management intern abgehandelt, offensichtlich mit optimiertem Code.

Ergebnis: Konsistente Ergebnisse.

Es fehlt noch das Timeout-Handling und die interne Uhr bzw. Abfrage der RTC, und natürlich die gesamte Timer-Programmierung um den AM zu steuern.

Mehr demnächst.

Gruß, Klaus

[harald_nds]

Das Teil von Olimex habe ich schon mal gesehen, allerdings ist das ja ein reiner SPI-to-Ethernet-Chip. Das bedeutet, man muss den gesamten Stack selber nachbilden. Zwar liegen da die Sourcen von Microchip für den PIC bei, aber den Aufwand würde ich nicht unterschätzen.
Eine Alternative wäre evt. diese Teil hier:
http://www.lantronix.com/device-netw...ers/xport.html
Das Ding habe ich bereits getestet, ich habe davon 2 Stück zu Hause.

Das ist ein kompletter Webserver incl. RS232-to-Ethernet Bridge im Stecker. 3.3V drauf und fertig. Der Webserver ist nur eingeschränkt zu gebrauchen, da er fürchterlich lahm ist. Was allerdings sehr gut funktioniert ist der virtuelle entfernte COM-Port. Auf dem lokalen PC wird also ein COM-Port eingerichtet, welcher sich auf dem beliebig entfernten XPORT abbildet. Man müsste sogar ohne weitere Elektronik ein XBee Modul mit dem Teil zusammenschalten können und hätte dann von überall auf der Welt Zugriff auf den AM. Eine Idee, die ich wahrscheinlich bei meinen Eltern realisieren werde, die planen demnächst auch einen AM. Da kann ich dann aus der Ferne zumindest ein wenig Online-Service geben falls es Probleme gibt...

@Klaus: Falls Du das testen möchtest würde ich Dir einen zur Verfügung stellen (leihen). Ich müsste mich nur mal kurz auf die Suche begeben, wo die Dinger vergraben sind (Er sollte damals mehr als Webserver dienen aber dafür sind die halt nicht so dolle).
Deine Frage mit dem Regler hat sich erledigt - sehe ich das richtig?

[seibot]

@seibot

Das Devolo-Netz hatte ich glatt übersehen - es könnte eine echte Alternative sein. Dann brauchen wir das "Framing" mit den XBees nciht. Einfacher ist besser. Dazu ein paar Fragen (bei Devolo habe ich nur wenige Informationen gefunden):

- Funktioniert die Übertragung auch wenn es sich um getrennte Stromkreise handelt? D.h. die Verbindung der Stromkreise besteht nur im Sicherungskasten.
- Gibt es hinsichtlich der Entfernung eine Beschränkung? Bei mir liegen zwischen Stromkreisen im Haus und der Garage ca. 40 Meter.
- Wie ich das verstehe, stellen die beiden Devolo Adapter dann eine Standard-Ethernet-Leitung dar. Ein Adapter kann am Router bzw. Switch hängen, der andere ist der Endpunkt für ein Ethernet-fähiges Gerät

@DigitalKlaus

Die Devolo-Adapter haben lt. Hersteller eine Reichweite von 200m. Theoretisch funktionieren sie nur an der gleichen Phase. Es gibt Installationen, bei denen wegen der Parllelführung der Starkstromkabel ein Überkoppeln erfolgt.
Ansonsten muss man im Hausanschlusskasten einen Phasenkoppler installieren (lassen). Der koppelt HF-seitig die Phasen für das LAN.

Die Devolo-Adapter können auf zwei Arten eingesetzt werden.

1. USB- Anschuss
Damit ist eine Punkt- zu- Punkt- Verbindung möglich.

2. RJ45-Anschluss
Ein Adapter wird mit dm Router/Switch verbunden und koppelt so das "Netz ins Netz". Weitere Adapter im Haus wirken wie ein LAN, so dass auch das Internet an mehreren Steckdosen des Hauses verfügbar ist.

Beide Varianten schließen sich aus, es gibt nur ent-oder weder.
Die Adapter müssen in einer separaten Steckdose stecken, nicht im Verlängerungsbrett, das gibt Probleme.

Ich muss mein Starterkit (zwei Adapter) noch testen. Zurzeit konnte ich darauf verzichten, de bei mir in der Garage an der LS ein LAN-Anschluss existiert.

[seibot]

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.

[DigitalKlaus]

@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

[seibot]

@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.

[DigitalKlaus]

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

[harald_nds]

@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

[seibot]

@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.

[DigitalKlaus]

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

Gruß, Klaus