AutoMower von Elektrolux und Husqvarna

Weiter zum Thema "Regensensor und externe Steuerung": Eine AVR-Lösung halte ich für grundsätzlich machbar, scheitere aber momentan an der notwendigen Echtzeituhr.

Ich habe bisher nur das RN-Mega2560 Board gefunden, das eine Echtzeituhr bietet - aber eine stabilisierte 5 Volt Spannung benötigt. Diese Spannungsversorgung bekomme ich (als Anfänger in Hardware) nicht hin -- mein Thema ist nun mal die Software.

Das RN Mega8Plus wäre sonst geeignet. Man könnte auch ein kleines LCD-Display ansteueren, Taster sind bereits vorhanden. Das Funkmodul ist unbrauchbar, da 433 MHz -- auf diesen Kanälen habe ich jede Menge Probleme hier in der Umgebung, daher bin ich auf 868 MHz fixiert. Da könnte man das RN-Funk per RS232 ansteuern.

Bleibt wie gesagt nur die Echzeituhr. Hat da jemand eine Idee wie man diese Echtzeituhr realisieren könnte? Ich habe da einen IC PCF8583 gefunden, aber den jetzt Batterie-gepuffert einzubauen ... das muß doch irgendwie einfacher gehen?

Gruß, Klaus

Hallo Klaus,

der PCF8583 ist ja nun auch schon (ca.) 100 Jahre alt, der hat ja noch nicht einmal einen eingebauten Quarz. Ich würde eher bei Dallas Semiconductor schauen (gehört jetzt zu www.maxim-ic.com) und dort unter Real Time Clocks einen passenden Baustein mit integriertem Quarz und mit passender Schnittstelle (SPI?) auswählen. Die bekommt man dort im Musterservice völlig unproblematisch. Mit einer kleinen Lithium-Zelle zum Einlöten ist die Batteriepufferung auch sehr einfach zu realisieren.
Was ich aber an deiner Stelle viel eher ins Auge fassen würde:
Einen DCF-Empfänger von http://www.hkw-elektronik.de mit RS232-Ausgang. Das sind eben nicht die Standard-DCF Empfänger mit Pulsausgang sondern ein richtiger Baustein mit komplett decodierten und vor allem verifizierten Daten. Man hat damit auch Datum und Wochentag ohne weiteren Programmieraufwand. Der Baustein geht nur einmal nachts auf Empfang, der Rest des Tages wird aus der integrierten Uhr bestritten (das ist auch gut so, da tagsüber eher schlechter AM-Empfang möglich ist). Schau Dir mal diesen Baustein an:
http://www.hkw-elektronik.de/pdfdeutsch/FUM-dcf.pdf
Kostenpunkt 20 Euro. Hinzu kommt noch eine Antenne aus dem Shop ( http://www.hkw-elektronik.de/shop/index.php )
Ich hatte diesen Baustein bereits in (Test-)Betrieb, er funktioniert sehr gut. Einziges Problem ist die Montage in unmittelbarer Nachbarschaft von Mikroprozessor-Schaltungen, evt. muss man die Einheit ein kleines Stück per Kabel absetzen. Man sollte sich vor den einfachen Empfängern mit Pulsausgang hüten, denn der Aufwand für die Software ist nicht unerheblich. Das Signal zu dekodieren erscheint zunächst einmal sehr einfach, die Probleme fangen an mit der Überbrückung von Empfangsproblemen und mit der Verifikation der empfangengen Daten. Die meisten Beispiele im Netz können nämlich nur dekodieren und das wars dann. Genau dort fängt aber das Know-How bzgl. DCF-Dekodierung erst richtig an.

Gruß, Harald

Ein DCF-Empfänger scheidet aus ... da hatte ich katastrophale Ergebnisse mit einer DCF-Lösung für unser Netzwerk: Die Empfangsprobleme waren grausam. Die AM-Steuerung wäre in der Garage, und die Stahlbetonkonstruktion könnte das Signal abschirmen ...

Ich muß eine Lösung finden, die auch die Spannungsversorgung diverser Baugruppen regelt. RN Mega8Plus läuft mit 7 bis 18 Volt, ein Regensensor z.B. mit 12 Volt, und das RN-Funk (per RS232) mit 5 bis 20 Volt. Ein 12 Volt Netzteil wäre also für alles geeignet und hält den Aufwand in Grenzen.

Für eine Echtzeituhr habe ich etwas auf www.myavr.com gefunden. Das Interface sollte ein I2C Bus sein. Ob das mit einem RN Mega8Plus lauffähig wäre?

Gruß, Klaus

Hallo,
apropos katastrophale Ergebnisse mit DCF: genau das meinte ich ja mit dem Punkt, wo das Know-How anfängt. Es geht eben nicht, die DCF als ständige Hauptzeitbasis zu benutzen. Da bekommt man immer nur Empfangsprobleme, das Ergebnis ist Ärger und Frust. Die Lösung, die ich meinte, ist eben eine NORMALE Echtzeituhr mit herkömmlichen Quarz, die sich einmal in 24h (oder sooft notwendig) mit der DCF abgleicht. DAS ist der entscheidende Unterschied. Stahlbeton wäre auch kein Problem für Langwelle....

Aber egal, die angestrebte Lösung von MYAVR sollte auch funktionieren. Wie sieht es denn aus mit fertigen Software-Libraries?

Hallo Klaus,
die Minimallösung mit dem AVR-Butterfly kann ich mir ganz gut vorstellen. Der Butterfly braucht nur 3 Volt. Laut Datenblatt http://www.atmel.com/dyn/resources/p...ts/doc4271.pdf kommt der Buttefly mit 3 Volt und ein paar mA aus. Einen Regensensor kann man mit 3 Volt auch realisieren. http://www.uoguelph.ca/%7Eantoon/circ/sensor3.htm
So lässt sich erst mal da Problem Regensensor am AM lösen ohne sich über den zusätzliche Stromversorgung gedanken machen zu müssen.

Des weitern kann der Butterfly auch stationär über eine Funkverbindung arbeiten. Da gibt es zwar keine Probleme beim Stromverbrauch, aber wenn keine aufwendige Software in dem AVR laufen soll, reicht er auch.

Momentan bin ich mit der Planung bei folgenden Komponenten:

RN-Control 1.4 Mega32
dazu ein 4x20 LCD Display

RN-Funk mit Modul für 868 MHz (433 MHz halte ich für abenteuerlich)
(läuft bereits)

Regensensor (von Conrad Electronic)

Auf www.futurlec.com gibt es (in der Kategorie Mini-Boards) eine batteriegepufferte Echtzeituhr (DS1307) für den I2C-Bus. Das Board kostet komplett mit Versandkosten gerade mal ca. 7,50 Euro. Da selbst basteln ist mir zu nervig, ich spiele lieber mit der Software.

In dieser Richtung forsche ich weiter. Mehr demnächst.

Gruß, Klaus

Halleluja, ich habs nun doch hinbekommen, das Ding zum Funken zu bewegen =D> Problem war wohl der Pin 16 (Power Down) an dem Funkmodul, den ich noch auf Masse gelegt habe, oder eine kalte Lötstelle oder einfach das Wetter .... egal, jetzt geht's. Vielen Dank an Vogon und Klaus für die Tips auch per PM!

Hier ein Bild des Einbaus:

Bild hier  

Einfach eine Aufputz-Dose, die ist wasserdicht, und zwei winkel zwischen die Schrauben und mit ein wenig Draht festmachen, so hat man eine solide Verbindung ohne irgendwo ein Loch bohren zu müssen.

Jetzt geht´s erstmal dadrum, den AM per Timer an/aus Flag rein- und rauszuschicken, ich habe eine komplette Haussteuerung (Heizung, Licht, Rolläden, Witterung, ...) die eigentlich alle Daten hat, somit hab ich nicht das Problem der Echtzeituhr. Bericht folgt.

Hallo Andiadm,
Glückwunsch zum erfolgreichen Funker.

Ich habe, der Anregung von harald_nds folgend, den mechanischen Regensensor RSD-BEx getestet:

http://www.rainbird.com/landscape/pr...ollers/rsd.htm

Vorteil:
Er benötigt keine Versorgungsspannung und schaltet nur durch die Quellkörper einen Wechsler um.

Nachteil:
Es ist schwierig, eine geeignete Einstellung zu finden. Man kann die Regenmenge (Ansprechschwelle) und den Lüftungsschlitz (Verweilzeit) einstellen. Das Gerät ist aber sehr träge. Wenn es beim ersten Regen ansprechen soll, dauert es recht lange, bis der Kontakt wieder freigegeben wird.

Zitat:

---

Zitat von Andiadm

...Problem war wohl der Pin 16 (Power Down) an dem Funkmodul, den ich noch auf Masse gelegt habe...

---

Jetzt wo du es sagst - den Pin hab ich beim ersten mal auch übersehen.
Egal, jetzt geht es ja. Willkommen im Club.
Nach dem mir zwei mal die Antenne abgebrochen, das Funkmodul einmal abgesoffen und zu guter letzt das Kabel vom Mähwerk gehächselt wurde habe ich jetzt eine ähnliche Lösung gefunden. Letzte Schwachstelle ist die Diagsteckdose. Momentan habe ich einen breiten Steifen Klebstreifen darüber gebappt.

So, der AM hängt jetzt bei mir erfolgreich in der Haussteuerung. Die hat einen Timer und einen Regensensor. Damit fährt er brav nach Hause, wenn es tröpfelt. Ein Schritt nach vorne.
Hat jemand schon erfolgreich eine gute Antenne in den AM verbaut, und wenn ja welche und wo? Mir scheint es, dass doch einiges an Funklöchern bei mir ums Haus ist, und eine gute Antenne - das jedenfalls die Erfahrungen mit anderen Funksystemen - ist immernoch die beste Lösung.
Andreas

Die Funklöcher habe ich auch.
Gibt es eine Möglichkeit, das Antennensignal z.B. kapazitiv auf den Schleifendraht zu legen?

Werden bei dem von euch eingesetzten Funkmodul die Pakete von der Gegenseite bestätigt und ggf. wiederholt? Beim ZigBee Modul sind Acknowledges und Retries (max. 3) bereits in der Default-Einstellung eingestellt.

Natürlich spricht das Einkoppeln des Funksignals in die Schleife gegen jegliche Theorie bzgl. Fehlanpassung aber einen Versuch wäre es wert. Auf jeden Fall einen keramischen Kondensator mit vieleicht 10nF zur Entkopplung verwenden. Bleibt zu hoffen, dass das Schleifensignal des Automowers die Sendeendstufe nicht schwindelig macht oder gar beschädigt.
Ein Problem mit der Reichweite ergibt sich aus der (zwangsweise) erdnahen Montage der Antenne. Da kommt die Fresnel-Zone ins Spiel, eine Erläuterung dazu gibt es hier: http://www.maxstream.net/support/knowledgebase/files/XST-AN010a-Maximizing%20Range.pdf%20(712.29KB).pdf?
Eine deutliche Verbesserung dürftet ihr schon erzielen wenn die Antenne einfach oben auf dem Automower sitzt. Sieht vielleicht bescheiden aus aber einen Versuch wäre es wert, oder?
Gruß, Harald

Ich habe den Vorschlag von Andiadm aufgegriffen und das Funkmodul in eine halbe Verteilerdose gesetzt. Die Dose ist auf dem Gehäuse mit Treibschrauben befestigt. Darunter liegt der Akku. Es sind mehrere cm Platz, so dass die Schauben nichts zerstören können.
Die Antenne bleibt hinter der Verkleidung und reicht bis knapp unter die Klappe.
Bei der Testversion lag das Funkmodul noch unter der oberen Abdeckhaube. Die Antenne ragte über den AM hinaus. Da war die Verbindung stabiler. Vielleicht muss die Antenne doch nach außen und etwas höher vom Boden weg.

Die programmtechnischen Feinheiten zur Datensicherung muss Vogon darstellen.

Bei meinem Aufbau ist das Funkmodul AM-seitig in einer kleinen verschraubten (dichten) Kunsttoff-Box untergebracht. Es ist mit doppelseitigem Klebeband unter der großen Haube (unter der die Schnitthöhe des Mähers eingestellt wird) angebracht. Die Antenne - momentan noch ein ein einfaches Stück Draht liegt waagerecht, aber - da direkt unter der Haube - offensichtlich hoch genug für eine akzeptable Funkverbindung.

Verkabelung zum Diag-Port ist mit relativ starren Kabeln ausgeführt. Diese sind mit Schrumpfschlauch gebündelt. Die Kabelführung läuft oben, unter dem grünen Gehäuse entlang, nach hinten zum Diag-Port. Eine Beschädigung durch das Mähwerk ist damit ausgeschlossen.

Funklöcher gibt es, aber die sind im Moment landschaftsbedingt nicht zu umgehen. Das wird besser wenn ich die Steuerung in der Garage aufgebaut habe.

Die ZigBee Module wären eine echte Alternative. Ein gesichertes Protokoll bzw. Retries sind mit dem RT868F4 auf der AM-Seite nicht ohne weiteres machbar: Es fehlt die Möglichkeit ein eigenes Protokoll zu laden. ZigBee/Xbee haben mehr "Logik" auf dem Chip (soweit ich das aus den Beschreibungen und Data Sheets interpretieren kann). Außerdem soll mit ZigBee/XBee ein Point-to-MultiPoint Netz möglich sein: Man könnte dann eine autarke Station mit dem AM kommunizieren lassen und sich immer noch mit der sonst autarken Station wireless "unterhalten", z.B. um gesammelte Statistikdaten abzurufen. Wenn ich mir dann die "größeren" XBee's ansehe ... mit RS323 oder USB und Antenne, ideal für die autarke Station, während im AM ein XBee-Pro läuft ... sehr interessant!

Gruß, Klaus

Hallo,
kann mir einer der Beteiligten mal grob erklären, wie eure derzeitigen Konzepte aussehen? Konkret habe ich folgende Fragen:
- Was läuft in der Haussteuerung (ein PC?)
- Was für ein Programm läuft dort?
- Wo soll der Regensensor sitzen? Zentral oder auf dem Automower?
- Der Automower hat nur das Funkmodem oder noch eine weitere Hardware, z.B. um die Tastendrücke zu simulieren?

Zum ZigBee Modul kann ich noch beisteuern, dass die Reichweite mit der PRO-Variante aufgrund der 63mW besser sein dürfte. Weiterhin sind Point-to-Multipoint Netze in der Tat recht einfach umsetzbar, da bin ich gerade dran (momentan aber nicht für den Automower). Es gibt zu diesem Zweck ein Framing, in dem neben den Nutzdaten die Zieladressen und weitere Parameter ansprechbar sind. In diesem braucht man aber einen Microcontroller, welcher das Framing erzeugt. Transparente Datenverbindungen sind nur mit zwei Teilnehmern möglich, ansonsten wäre ja gar kein gezielter Datenverkehr möglich. Man kann natürlich alle Teilnehmer auf die gleiche Adresse setzen, dann gehen alle Daten immer zu allen übrigen Teilnehmern. Aber auch in diesem Fall müsste man sich ein eigenes Framing ausdenken.

Okay, dann fange ich einmal mit meinem Konzept an - das bisher teilweise (Funkverbindung, "manuelle" Softwaresteuerung) realisiert ist, aber in der Konzeptionsphase Fortschritte macht:

Steuerung:
Es ist eine autarke Station mit AVR geplant, die in der Garage untergebracht wird (dort stehe auch der Trafo für die AM-Ladestation). Als Controller-Board habe ich geplant:

RN-Control 1.4 Mega32
dazu ein 4x20 LCD Display
Dazu eine batteriegepufferte Echtzeithur von futurlec, (DS1307), für den I2C-Bus.

Programmierung:
entweder in BASCOM oder C.

Funkverbindung:
Zurzeit RN-Funk mit Modul für 868 MHz (433 MHz halte ich für abenteuerlich). Sehr wahrscheinlich werde ich auf die ZigBee/XBee Module umstellen. Gründe:

- Gesicherte Datenübertragung *)
- Variabler
- ggf. Point-to-Multipoint Netz möglich

Regensensor:
von Conrad Electronic, an die autarke Station angeschlossen.

Zusätzliche Kommentare:

Ein Regensensor am AM macht für mich keinen Sinn:
Die notwendige Stromversorgung/Spannung ist am AM nicht vorhanden und eine Wandlung zieht zuviel Strom vom AM-Akku
Ich habe für meinen AM einen "Car-Port" (Dach) gebaut. Da merkt er zunächst nicht ob es regnet ... Er soll ja nicht erst rausfahren um festzustellen dass er in der Garage bleiben soll.

*) Mit den bisherigen Funkmodulen können Übertragungsfehler auftreten, die auf der AM-Seite nicht erkennbar sind (bzw. einen zusätzlichen AVR erfordern, der wieder Strom zieht ...). Ungewollt modifizierte Daten beim Schreiben des Timer-Flags bzw. Abfragen bestimmter Speicherzellen können für den AM tödlich sein - wie Vogon bereits früher ermittelt hat, gibt es Bereiche in die keinesfalls geschrieben werden darf, sonst verabschiedet sich der AM (neue Firmware-Programmierung notwendig).

ZigBee ist da deutlich weiter. Die PRO-Version macht Sinn, insbesondere wenn die Funkverbindung durch (Stahlbeton-) Mauern hindurch laufen muß. ZigBee arbeitet im 2.4 GHz Band wie WLAN - da habe ich hier im Haus schon 30% Verlust bei einer Wand gemessen.

Unschön ist bei ZigBee der 2mm Pinabstand. Da bin ich noch auf der Suche nach geeigeneten Bauteilen um das steckbar zu machen (Platinen bauen kann ich nicht, machte wegen einem Teil auch keinen Sinn.)

Der AM kann keine Tastendrücke simulieren. Es gibt keine brauchbare Schnittstelle dazu. Die einzige Kommunikationsmöglichkeit ist der Speicherbereich, in dem sich der AM Zustände/Zähler speichert bzw. von dort liest.

Im AM sollte nur das Funkmodul sitzen, und dieses kommuniziert über den Diag-Port. Ich verfolge die von "seibot" beschriebene Strategie, die gesamte Timer-Steuerung extern (in der autarken Station/AVR) zu programmieren und im AM praktisch nur das Timer-Flag zu setzen. Eine weitere Ausbaustufe ist dann das Sammeln von Statistikdaten zur Optimierung der Mähzeiten. Auch dies wird komplett extern laufen und der AM nur per Timerflag als Start/Stop gesteuert.

Point-To-MultiPoint wäre eine weitere Ausbaustufe - wie schon erwähnt, mit den Teilnehmern:

- AM
- autarke Station (mit AVR) zur zentralen Steuerung
- PC zur Abfrage und ggf. Einstellung der Station (via USB - ZigBee)

Für das Framing hätte die Station einen AVR, die Steuerung und Kommunikation muß ohnehin programmiert werden (ich sehe schon, der AVR wird ein Mega32 ... ein AVR-Butterfly reicht da längst nicht mehr).

Gruß, Klaus

Hallo Klaus,
vielen Dank für deine ausführliche Darstellung des Projektes!

Ein paar Anmerkungen habe ich noch:
- Mit einem Adapterboard auf Lochraster-freundliche 2.54mm kann ich weiterhelfen. Natürlich habe ich im Platinenservice so einige mehr machen lassen, der Stückpreis bei dieser kleinen Platine ist nicht sehr hoch (dafür die Grundkosten). Schick mir mal eine PN wenn Du Interesse hast. Das Adapterboard enthält noch die Pegelanpassung von 3.3V <--> 5V und ein 3.3V Linearregler (5V-->3.3V). Auf der Automower-Seite kann man Regler und Pegelanpassung überbrücken, die braucht man da nicht.

- Stahlbeton ist bei 2.4GHz natürlich ein Problem. Aber Du hast doch sicherlich irgendwo Dein Automower-Kabel durch die Wand geführt. Dort hindurch passt doch sicherlich auch noch ein RG58-Kabel, oder?

- Mit analogen Schaltern wie dem 4066 oder ähnlichen könnte man sehr wohl Tastendrücke simulieren. Das läßt sich auch in das Tastaturkabel einschleifen, rückbaubar. Aber wenn alles über die DIAG geht umso besser.

- Das Framing würde im Automower in jedem Fall einen Microcontroller erfordern. Der Frame muss erstellt und ausgewertet werden. Ich kenne mich hauptsächlich mit PICs aus aber im Bereich AVR gibt es da sicherlich auch etwas sehr stromsparendes.

- Bei allen bisherigen Varianten habe ich die Verwendung des Diagnosesteckers auf der Unterseite gesehen. Wenn man den Automower öffnet kommt man sehr leicht an die eingerastete Buchse, welche man dann nach oben führen kann. Als Ausgang böte sich die Öffnung für das STOP-Schalter-Kabel an. Ich meine das ist nicht so schmutzbelastend - auf die Dauer ist die Kabelführung unten doch sehr störanfällig, oder? Oder ist die Öffnung des Automowers ein Hinderniss? Das ist wirklich kein Problem, beim ersten Mal brauchte ich fast 1h, mittlerweile mache ich das in ca. 5 Minuten :-) Und da gibt es auch keine Garantiesiegel oder ähnliches.

Hallo Klaus,
Hallo Harald,
bin ich wirklich hoch erfreut. Endlich kommt mal Bewegung in die Sache.
Wie ihr ja schon fest gestellt habt, die Funkverbindung ohne absicherte Daten ist ein Problem. Ohne intelligentere Funkmodule oder einen zusätzlichen Prozessor auf der AM Seite wird man das nicht weg bekommen.
Ein PIC oder AVR am AM hätte schon einige zusätzliche Vorteile.
1. Den zusätzliche Leistungverbrauch kann er durch abschalten des Funkmodules bzw Reduzierung des Funkverkehrs in Arbeitspausen sicherlich ausgleichen.
2. Protokoll zum sicheren Datenaustausch.
3. Er kann mit dem AM bei 115200 Baud schneller Daten austauschen und intern Puffern.
4. Daten sammeln und auf Anforderung dem Leitrechner am anderen Ende der Funkverbindung zur Verfügung stellen.
5. Einfache Aufgaben kann er auch selbst abarbeiten.
6. Mit Analogschaltern dem AM Kommandos übergeben.

Nachteil: Da steckt erst mal jede Menge Arbeit drin. Aber wenn sich da in Zukunft auch noch andere daran beteiligen? "Na, dann schauen wir mal ...."

@Harald:

Die Garage ist aus Stahlbeton und liegt so ungünstig, dass der AM eine außen angebrachte Antenne nicht ständig "sieht" (er fährt um eine Ecke herum und hat dort seine Ladestation). Ich gehe aber davon aus, dass ein ZigBee PRO Modul genügend Power hat um durch die Wand zu funken.

Tastendrücke simulieren - den Bedarf sehe ich momentan noch nicht, dafür ergeben sich diverse Komplikationen wie z.B. Prüfung ob der Befehl wirklich ausgeführt wurde (geht wieder über den Diag-Port "zuletzt gedrückte Taste"). "Nice to have", das ist ggf. eine spätere Ausbaustufe.

Framing: Richtig, der AM braucht dann einen AVR, das hatte ich übersehen. Da tut's ein AVR-"Butterfly". Auch eine spätere Ausbaustufe. Alternativ könnte man an die Basisstation zwei ZigBee's nutzen, die auf unterschiedlichen Kanälen arbeiten. Dann unterhält sich die Basisstation mit dem AM und mit dem PC. Nur so eine Idee, da ist noch mehr konzeptionelle Arbeit notwendig.

Diag-Port: Da hatte ich ursprünglich auch Bedenken - Schmutz, Stecker könnte sich lösen, Kabel schleifen etc. Nicht dergleichen ist bisher passiert. Den AM öffnen wäre kein Problem, nur ist die Verschraubung (Gewinde) miserabel (zu oft geschraubt leiert die Gewinde aus!) und die beiden Fahrwerksteile dicht bekommen ... das wäre besser zu lösen gewesen. Wenn in 2-3 Jahren der Akku auszutauschen ist könnte ich mir eine andere Leitungsführung vorstellen.

@Harald, @seibot, @Vogon (in alphabetischer Reihenfolge):

Das Projekt kommt jetzt doch gut voran, nimmt allerdings eine Dimension an die ich in einem einzigen Schritt nicht als realisierbar halte. Was wir sicher haben müssen ist die Zielprojektion, dann aber eine Umsetzung in mehreren Stufen. Denkbar halte ich folgendes:

1. Gesicherte Funkverbindung

Das erscheint mir als dringende Aktion. Austausch der bisherigen Funkmodule durch 2 x ZigBee PRO. Auf der AM-Seite problemlos, auf der PC-Seite ist die Spannungsversorgung zu beachten. Evtl. könnte man hier eine der fertigen Stationen verwenden - die gibt es mit USB oder RS232 Anschluß (oder selbst bauen, wer Zeit hat ...).

Gibt es hier Erfahrungswerte für die Antennen? Das kurze Stück Draht an einer der ZigBee Modulvarianten sieht etwas abenteuerlich aus. Eine "richtige" Antenne bringt sicher bessere Ergebnisse. Diese müßte dann aber federnd befestigt sein, sodass die Antenne bei Hindernissen (Sträucher etc.) wegklappen kann.

2. Basis-Station (Conrollerboard mit AVR) und Regensensor

Hier gibt es hardwareseitig fertige Boards. Die Programmierung ist nicht trivial, halte ich aber für machbar. BASCOM erscheint mir geeigneter als C (leichter lesbar, weniger Programmieraufwand).

Board (z.B. 7 - 14 Volt) und Regensensor (12 Volt) könnten an einer gemeinsamen Stromversorgung (Steckernetzteil) hängen (oder gibt es Komplikationen wenn beide Verbraucher einfach parallel dranhängen? ... Frage nur zur Sicherheit).

4. AVR im AM

Für die ersten Schritte nicht notwendig, da wir nur das Timer-Flag setzen müssen und ggf. die AM-Uhr abfragen. Die Basisstation stellt dann die batteriegepufferte Echtzeituhr soweit notwendig. Übrigens: Die AM-Uhr kennt keine Sommer-/Winterzeit, man ging vermutlich davon aus dass der AM nur während der Sommerzeit fährt. Das war einmal, letztes Jahr ist der Rasen noch Anfang Dezember kräftig gewachsen.

In welchem Umfang der AM eine eigene Logik benötigt muß noch festgelegt werden. Für Point-to-Multipoint mit ZigBee's brauchen wir das Framing. Sonst fällt mir ein:

- Daten sammeln und im Batch an die Basisstation übertragen
- Autarke Funktionen, z.B. Betriebsfehler an die Basisstation melden
- Sleep-Modus des Funkmoduls in Pausen

5. Diverse Zusatzfunktionen

- Statistikwerte sammeln und übertragen
- Mähzeiten optimieren
- Point-To-Multipoint Netz (Framing ímplementieren)
- Tastenfolgen erzeugen, damit den AM steuern

Soweit meine Gedanken zu diesem Projekt.

Gruß, Klaus[/list]

Update zum Stand der Dinge:

Die Hardware ist fast vollständig eingetroffen (Controller-Board. LCD, XBee's, Adapter-Platinen [Danke an Harald!], Regensensor, diverse Kleinteile. Die RTC fehlt noch (www.futurlec.com sitzt in Australien, angeblich ist die Sendung unterwegs, es gibt allerdings sehr unterschiedliche Erfahrungsberichte über diesen Versender. Wie auch immer, die Einzelteile für eine RTC habe ich für den Notfall jetzt auch - wäre also auf einer Standard-Leiterplatte machbar.)

Die XBee Pro Module gefallen mir immer besser - wenn sie jetzt noch die erwartete Übertragungsleistung bringen ... warum nicht. Mit dem "XBee Development Board" mit USB-Anschluß und der zugehörigen PC-Software lassen sich die Teile problemlos konfigurieren. Die Stromversorgung erfolgt über USB, ein virtueller COM-Port macht die Ansteuerung mit jeder RS232-kompatiblen Software einfach.

Nächster Schritt: Austausch der bisherigen Funkmodule durch 2 XBee Pro, Austausch des PC-seitigen Boards durch das XBee USB-Board.

Danach gibt's einen kurzen Update.

Dann: Aufbau der Basisstation und AVR-Programmierung. Das dauert ein paar Tage länger 8-[

Anmerkungen:

XBee Pro: Aus der Doku ist ersichtlich, dass ein Multi-Point Netz nicht mehr mit gesicherten Übertragungen laufen würde, weil der Sender nicht mehr feststellen kann von wem ein ACK kommt. Ich hatte gemeint, per Sender ID und Framing wäre das zu regeln. Falls nicht, gibt es einen konzeptionellen Ausweg: Die Basisstation spielt Koordinator und hält - mit 2 angeschlossenen XBee Pro Modulen - Verbindung 1 x zum AM und 1 x zum PC. Vom PC muß der AM nicht direkt gesteuert werden. Mein Plan ist mehr, vom PC die Basisstation zu steuern bzw. gesammelte Daten abzurufen, während die Basisstation mit dem AM kommuniziert (Timer, Stopp bei Regen, Statistikdaten sammeln, etc.).

Das ist dann aber schon eine weitere Ausbaustufe - jetzt muß erst mal die Basis laufen. Mit einigen AVR-Details geht es gut voran, auch Dank der Hilfe in anderen Diskussionen hier im Forum.

Mehr demnächst.

Gruß, Klaus

Hallo Klaus,

das mit der Datensicherung im Point-to-Multipoint kann das Device auch ja nicht mehr so einfach regeln - das muss ja schon detailliert aus der Anwendung hervorgehen wie das laufen soll.
Auf jeden Fall solltest Du mal unter dem Kapitel "API" (Stichwort Framing) nachsehen. Jedes Package, das man in diesem Modus versendet, kann verfolgt werden ob es denn tatsächlich angekommen ist. Nur nicht bei Broadcast-Nachrichten, das funktioniert naturgemäß natürlich nicht. Die Nachrichten bekommen eine Frame-ID, damit man nachher die Zuordnung noch hat. Das Modul antwortet nach erfolgreicher/-loser Zustellung mit dieser Frame-ID. Das Modul macht dabei selbständig Retries anhand der im Parameterspeicher hinterlegten Anzahl.
Eigentlich bietet der API-Modus wirklich alle Eigenschaften, die man für ein Netzwerk braucht. Die Sache mit dem ZigBee-Koordinator würde ich nicht machen, das ist dann schon sehr in Richtung voller ZigBee Norm und somit arg kompliziert. Oder meinst Du "Koordinator" nur im allgemeinen Sinne?


Kapitel 4.3 API
==========
ZigBee Transmit Request : API Identifier Value: 0x10
A TX Request message will cause the module to send RF Data as an RF Packet.

und

ZigBee Transmit Status : API Identifier Value: 0x8B
When a TX Request is completed, the module sends a TX Status message. This message will indicate if the packet was transmitted successfully or if there was a failure.

Hallo Leute,

ab heute ist unser Wohngebiet mit Automower-Daten versorgt, ich habe gerade mal einen Reichweitentest mit dem Auto durchgeführt :-)
Das XBee-Pro Modul habe ich in eine Tic-Tac-Dose verbaut. Zunächst einmal provisorisch - versteht sich. Auf Dauer möchte ich den Stecker unten aus der Diagnosedose herausholen und unter das Display führen. Da kommt man durch die extra Verschraubung des Displays schnell heran.....
Zum Test habe ich das Programm von Vogon genommen, das ist ja wirklich genial!!! (@Vogon: könntest Du auf Dauer verschiedene COM-Ports unterstützen, mein XBee-USB Interface kann ich nicht auf COM1 verschieben?)

Bild hier  

Ich streue hier nur mal ein "ist ja toll was iher hier auf die Beine stellt" rein.
Da euer Vorhaben Kommunikationsfragen aufwirft und löst finde ich das für mich natürlich besonders spannend.


Netter Gruß
http://www.marvins-lab.roboterbastler.de/

Ps. Und nicht nachlassen ;-)

Zitat:

---

Zitat von harald_nds

(@Vogon: könntest Du auf Dauer verschiedene COM-Ports unterstützen, mein XBee-USB Interface kann ich nicht auf COM1 verschieben?)

---

Das Programm von Vogon besitzt eine Setup-Funktion. Vor dem Start des Programmes können die COM-Einstellungen gewechselt werden. Diese sind dann in einer optionen.ini gespeichert.

Upate und Erfolgsmeldungen:

XBeePro

Die Funkverbindung ist von den bisherigen 868 MHz-Modulen auf die XBeePro Module umgestellt. Im AM sitzt ein XBee Pro vorne unter der Haube in einer kleinen Kunststoff-Box. Die Antenne ist oben auf der Haube montiert (und kann wegklappen, sollte es ein Hindernis geben).

An dieser Stelle Danke an alle Entwickler im Roboternetz-Forum, die mir bei grundlegenden Verständnisfragen zum AVR geholfen haben, und die mit dem Einbringen eigener Forschungsergebnisse den aktuellen Stand überhaupt möglich gemacht haben. =D>

Die Verbindung zum AM regelt im Moment eine Station am PC. Diese Station ist ein MaxStream XBee Development Board mit USB-Anschluß. Ich habe das Board in ein Gehäuse eingebaut (da mußte allerdings kräftig "nachgearbeitet" werden 8-[ ):

Bild hier  

Vorne rechts ist der USB-Anschluß, links LEDs für Betriebsbereitschaft, zur Rückmeldung der Funksignal-Qualität (1-3 LEDs), und optische Meldung der Sende/Empfangsvorgänge. An der Rückwand ist die Antenne für das 2.4 GHz Band angebracht.

Die PC-seitige Station dient mir als Konfigurationsmöglichkeit für die XBee Module sowie für erste Tests mit vorhandenen AM Diagnose- und Steuerprogrammen. Wichtig ist eine XBee Erstkonfiguration um die Sendeleistung auf das in Europe zugelassene Maximum zu begrenzen. Gleichzeitig hatte ich etwas zu optimistisch die Baudrate auf 38.400 eingestellt - was sich als nicht machbar erwiesen hat: Bereits bei der Konfigurationseinstellung gab es mehrmals Übertragungsprobleme. Eine Kommunikation mit dem AM war überhaupt nicht machbar. ](*,)

Zurück zu 9.600 Baud war erfolgreich. Der Grund für die Limitierung dürften die (alten) PC Device Driver für den virtuellen COM Port sein - diese sind in der Software für die XBee's enthalten, es gibt aber vom eigentlichen Treiberhersteller inzwischen Updates.

Die Ergebnisse sind für mich durchaus beeindruckend: Mit 9.600 Baud ist der Datendurchsatz erheblich (!) besser als mit den 868-MHz-Funkmodulen - und das bei gesicherter Übertragung! Zu einem späteren Zeitpunkt werde ich noch weiter testen, wo die maximale Datenrate liegt (was aber aufwendig ist, das beide XBee-Pro Module dann umkonfiguriert werden müssen - d.h. auch Ausbau aus dem AM -- daher die Befestigung unter der Haube, leicht errecihbar.)

Die Funklöcher sind weg, die vorherigen Datenfehler sind weg - letzteres aufgrund der gesicherten Übertragung. \:D/

Jetzt habe ich weniger Bedenken, auch Daten im AM zu verändern (was bei ungesicherter Übertragung ein Abenteuer ist.)

Basis-Station (AVR)

Zur autarken Station auf AVR-Basis bin ich auch ein Stück weiter. Hier der Hardware-Testaufbau:

Bild hier  

Links im Bild der Regensensor, hier mit etwas Wasser "Regen" simuliert (grüne LED meldet "Feuchtigkeit"). Rechts das RN-Control mit ATmega32. oben das LCD (RS232 wird für die XBee Steuerung benötigt, also mußte eine Alternative zur Infoanzeige her), unten ein Verteilerboard (Wannenstecker auf Klemmleiste für einen Port) mit LED-Portstatuskontrolle. Das XBee und die RTC fehlen im Aufbau noch - ich überlege wie ich das auf Platinen aufbaue oder per Stecker zusammenhänge ... zu viele Einzelplatinen sind nicht gut (wie befestigen!?), evtl. wird's eine Huckpack-Konstruktion.

Ein erstes Programm (BASCOM) erkennt "Regen" oder "kein-Regen": Wenn der Sensor Regen erkennt, schließt ein eingebautes Relais einen Stromkreislauf. Die Spannungsänderung an einem AVR-Port löst den Interrupt 0 aus, worauf im Programm ein Flag für die "Wetterlage" gesetzt wird. Es werden beide Zustände gemeldet und gespeichert (Regen / kein Regen). Man müßte das nicht per Interrupt machen, hier könnte auch ein Polling erfolgen - die Int0 Implementierung hilft mir als AVR-Einsteiger die Zusammenhänge besser zu verstehen, außerdem ist es m.E. logischer wenn ein "Ereignis" einen Interrupt auslöst und dieser im Programm einen Status setzt.

Die autarke Station weiß also jetzt zu jeder Zeit ob es momentan regnet oder nicht. Zur Kontrolle werden diese Zustände am LCD angezeigt. In einer späteren Programmlogik wird hier eine Latenzzeit für die AM-Steuerung einzuplanen sein - der AM soll ja nicht ständig rein und rausfahren wenn ein paar Regentropfen fallen. Das fällt aber schon in den Bereich "Optimierung".

Das Board hat fünf Taster, mit denen momentan Port-Zustände am LCD angezeigt werden, die LCD-Beleuchtung an/aus zu schalten ist (das Teil zieht mächtig Strom, da kommt der Spannungsregler am RN-Control ins Schwitzen ...).

Der nächste Schritt wird die Kommuniklation mit dem AM, und danach folgt die Timer-Programmierung. Das muß dann auch irgendwie einstellbar sein - mit einem 4-zeiligen LCD und ein paar Tastern (oder eine kleine Tastatur?).

Wie dann alle 3 Systeme (PC, Basisstation, AM) miteinander reden weiß ich noch nicht. "Framing" erfordert mehr Einarbeitung in das XBee API und einen AVR im AM. Eine Alternative wären 2 Funkstrecken: AM - Basis und Basis - PC. Das setzt 2 serielle Schnittstellen am RN-Control voraus und die Basisstation müßte eine Art Vermittler spielen. Die beiden seriellen Schnittstellen könnte man mit 1 x HW und 1 x SW realisieren. Wie weit das mit 32 KB Programmspeicher überhaupt zu realisieren wäre ist fraglich.

Nächster Schritt: Die Basisstation (AVR) soll mit dem AM reden.

Kommentar, Anregungen, Fragen sind willkommen. Und wenn ich zu lange Beiträge schreibe, dann sagt es mir bitte 8-[

Gruß, Klaus

Hallo Klaus,

klasse, das schaut ja schon richtig gut aus! Freut mich, das XBee nun doch das richtige zu sein scheint! Ein paar Fragen/Bemerkungen habe ich:

* Du sagst 38400 Baud haben nicht funktioniert. Hast Du die denn auf beiden Seiten eingestellt, ich meine der AM kann mit 38400 doch eh nichts anfangen, oder?
* Verwendest Du für die Konfiguration das Program X-CTU von Maxstream? Bei mir war bei den XBee Pro erst mal ein Firmware-Upgrade erforderlich, damit X-CTU die ansprechen konnte.
* Das Diagnoseprogramm kann ja 9600 und 115200 Baud. Wie stellt der AM diese Baudrate um, oder kann er anhand des ersten 0x0F Byte das automatisch erkennen? Mein Experimentiertrieb war in diesem Punkt noch etwas zurückhaltend. Das Problem ist nämlich das ich ein FW-Upgrade des AM nicht über USB-Seriell-Adapter am Notebook hinbekomme. Also schleppe ich bei Absturz den AM ins Büro auf den Schreibtisch und nutze den Legacy-COM Port des PCs. Da liegt der WAF natürlich nicht sehr hoch...
* Die Begrenzung auf Europa-taugliche 10mW gilt sicherlich für Serienprodukte - klar. Aber für experimentelle Zwecke hätte ich da keine Skrupel. Aber wenn es bereits mit 10mW auch schon perfekt geht - warum mehr? Als ich mir die Motorströme so angeschaut habe kam mir die Stromaufnahme des XBee in den Sinn. Mit ca. 200mA beim Senden liegt die Aufnahme in der Größenordnung des Hauptmotors wenn dieser nicht viel zu tun hat. Aber großartige negative Einflüsse auf die Mähzeit habe ich selbst bei dauernder Übertragung nicht feststellen können. Wahrscheinlich sind die 200mA nur Peaks und fallen deshalb nicht ins Gewicht.
* Hat jemand schon Erfahrung (vielleicht auch ungeplante) mit der Strombelastbarkeit der AM-Debug-Schnittstelle? Ich meine, ist das intern abgesichert oder schmort da mal gleich eine Leiterbahn durch? Bei 200mA kommt man ja schon in's Grübeln.
* Nach Benutzung der Vogon-SW haben sich bei mir Datum und Uhrzeit komplett auf Null gesetzt. Hat das jemand schon mal gehabt? Vielleicht sind noch weitere Parameter betroffen, muss ich noch prüfen. Was könnte da passiert sein? Ich habe jedenfalls nichts geschrieben, nur das Variablenfenster nur einmal geöffnet und gleich wieder geschlossen.
* Sind die Speicherzellen der neuen Generation noch identisch mit denen der 2006 AM's.
* 32kB Hauptspeicer sollten doch allemal reichen. Ich meine, ich kenne BASCOM nicht, aber in C kann man da schon so einiges regieren.
* Ich könnte mir vorstellen nachher alles schön auf eine Platine zu bringen. Da würde ich mich anbieten. Wenn es kein Großserien-Produkt werden muß ist das kein großes Problem. Evt auch gleich die Regensensor-Elektronik.
* Spannungsregler zu warm: Handelt es sich auf dem Board um einen normalen 7805? Falls ja, könnte das hier eine Alternative sein, die du direkt umlöten kannst: Conrad Best.Nr. 154496 Die habe ich mal getestet, funktionieren ganz gut und werden bei >90% Wirkungsgrad auch kaum warm.

@seibot: Vielen Dank für den Tip mit der INI-Datei!
@Vogon: Könnte man vielleicht die Update-Rate einstellbar machen? Momentan funkt das Modul bei Kontakt ja unentwegt und zieht dadurch zusätzlichen Strom. Vielleicht müsste man wirklich einen kleinen Microcontroller dazwischenschalten, der lokal auf dem AM Daten anfragt und die dann erst bei "Notwendigkeit" aktiv über Funk weitergibt. Müssen wir noch einen µC mit zwei richtigen UARTs finden.
Gruß, Harald

@Harald

- 38400 waren auf beiden Seiten eingestellt, ebenso für den COM-Port am PC. ABER, es ist richtig, der AM kann damit nichts anfangen - das hatte ich in der Eurphorie völlig übersehen!
- Ja, ich verwendet X-CTU. Läuft problemlos, nur die Umstellung der Baud-Rate hat nicht immer so funktioniert. Jetzt bin ich wieder auf 9600, da macht X-CTU alles problemlos. Meine XBee Pro melden sich mit XPB24, XBEE PRO 802.15.4, Version 1083, Hardware-Version 1808. Es sind neuere Versionen verfügbar ... aber "never change a running system"!
- Wie der AM die Baudrate umstellt weiß ich (noch) nicht. 115200 gehen sicher rein seriell, aber mit einem virtuellen COM-Port habe ich da Bedenken: Da ist "zuviel Software" dazwischen. Eine direkte Kabelverbindung mit USB-nach-Seriell Adapterkabel funktioniert bei mir. Das ist dann allerdings wieder ein virtueller COM-Port und wird mit 9600 Baud betrieben (auch bei mir am Notebook).

- XBee Stromaufnahme: Bei 10 dBm sollen es "nur" 137 mA sein, bei maximaler Sendeleistung (18 dBm) gibt das Handbuch 215 mA an. Idle sind es 55 mA. Das ist immer noch mehr als die 868 MHz Module, scheint aber keine Probleme zu verursachen.
In ein paar Tagen, wenn das XBee Pro an meinem AVR-Testaufbau hängt, wird's interessant: Das LCD am RN-Control zieht bei eingeschalteter Beleuchtung 200 mA - dann kommt der Spannungsregler (ein 7905) ins Schwitzen. Wenn jetzt nochmal 137 mA für das XBee Pro dazukommen ... Als Netzteil für RN-Control habe ich 12 V/2A stabilisierte Ausgangsspannung. Das Board selbst braucht 60 - 100 mA. Macht zusammen ca. 500 mA. (Einen Kühlkörper für den 7805 habe ich jetzt angebaut.)
Dazu noch folgende Überlegungen:
* Mein Ziel ist eine Reduzierung der Datenübertragung. Die Zeitsteuerung, Regensensor-Überwachung etc. läuft in der Basisstation. Diese muß jetzt nuir noch das Timer-Flag im AM auf On oder Off setzen. Alles Weitere ist nice-to-have und sicher wünschenswert, aber selbst dann könnte man Statistikdaten (die der AM sowieso sammelt) in der Nacht bzw. in Pausen abrufen.
* XBee Pro hatt einen Sleep-Modus und einen zyklischen Datencheck zum "Aufwachen". Vielleicht ist das eine weitere Möglichkeit, die Stromaufnahme zumindest auf der AM-Seite zu reduzieren. Dazu wäre mehr Doku zu lesen - soweit es die Zeit erlaubt.
* Strombelastbarkeit der Diag-Schnittstelle: Könnte ggf. jemand beantworten, der den AM schon einmal geöffnet hat.

- Die Vogon-SW hat bei mir funktioniert. Über Speicherzellen 2006 und 2007 ist mir nichts bekantnt, nur beim 220AC hat sich genau genommen nichts geändert. Der 230 dürfte zusätzliche Daten und Logik haben, weil er intern zwischen 2 Akkus umschaltet.
- Hauptspeicher: BASCOM macht das schon recht ordentlich, und ist für Prototyping gut geeignet, da sprachlich höher angesiedelt als C. Vielleicht schreibe ich das dann irgendwann auf C um. Das Problem ist ja nicht nur der Programmspeicher, sondern die 2 K RAM und etwas EEPROM (weniger kritisch). In 2 K RAM müssen die Stacks rein, alle Variablen ... das wird eng wenn wir einigen Komfort wollen. Warten wir ab was passiert.

So, jetzt hänge ich das XBee Pro an den Testaufbau und fange diese Woche mit der Kommunikationslogik an.

Grüße aus München, Klaus

Hallo Klaus und Harald,
Glückwunsch zu diesen Ergebnissen. Ich muss noch auf Bestellungen warten.
Die XBee-Module wurden leider mit 43€ Zoll belegt - ist das üblich?

Noch ein Tipp zum Regensensor.
Wenn die Sensoroberfläche waagerecht oder nur leicht geneigt liegt, ist die Latenzzeit bei Regen ausreichend, damit der AM nicht ständig ein- und ausfährt.

@Jürgen

Zoll oder Einfuhrumsatzsteuer oder beides? 19% EUSt sind normal, Zoll weiß ich noch nicht - die Abrechnung habe ich noch nicht.

Regensensor: Der sollte eine "Heizung" eingebaut haben, damit nicht jede Feuchtigkeit gleich als Regen erkannt wird. Ich habe den Eindruck, mein Sensor "heizt" nicht. Mir ist schon klar, dass man da keine Spiegeleier braten kann ...

Gruß, Klaus

@DigitalKlaus,
auf den Nettobetrag von 179,23 € von Digi-Key wurden 43,82 € Einfuhrumsatzsteuer berechnet. Das sind 24,4 %.


Regensensor (CONRAD)
Ich habe die Heizung abgeschaltet, da diese zu einem sehr zeitigen Abtrocknen führt. Die Ansprechschwelle des Sensors lässt sich ja einstellen, so dass das Relais erst bei Regen schaltet.

@seibot: Bei Privatbestellungen kenne ich mich da nicht so aus, es gibt da so einen Modus das die Zollgebühren schon in den Warenpreis eingerechnet sind. Ich habe schon mal bei Digikey unter der deutschen Nummer angerufen, die waren sehr freundlich und hilfsbereit. Bestimmt erklären Sie dir den Sachverhalt genau.

@DigitalKlaus: 5V/500mA aus 12V würde ich nicht mehr mit einem Linearregler machen. Kühlkörper sind aus meiner privaten und beruflichen Enwicklungspraxis fast ganz verschwunden, irgendwie gibt es immer einen schöneren Weg die Leistung nicht zu verbraten. Neben dem weiter oben empfohlenen DC/DC Wandler könnte ich dir noch ein Netzteil von einem USB-HUB empfehlen, das ist meiner Meinung fast die günstigste Methode an 5V/2A zu kommen. Oder das Netzteil von www.pollin.de Best.Nr. 350377 für 0,95 Euro. Das ist ein Ericcson-Restposten, sehr edel verarbeitet mit 7,6V/600mA. Das passt genau für einen 7805, wobei nur wenig Verlustwärme entsteht. Ich habe davon noch einige herumliegen, bei Bedarf kann ich dir welche zusenden (hatte ich mir mal für ein anderes Projekt gekauft und nicht alle gebraucht)

Gruß, Harald

@seibot:

Den einzigen halbwegs brauchbaren Regensensor hatte ich bei CONRAD gefunden - aber da gibt's nur noch einen Regensensor ohne abschaltbare Heizung und ohne einstellbare Ansprechschwelle. Nennt sich "Kemo M152". Die Heizung hat 1W. Ist das ein anderes Teil?

@Harald

So einfach ist die Stromversorgung nicht: Der Regensensor braucht 12V, das Rn-Control läuft mit 7 - 18V, wobei 12-14V optimal sein sollen. Für einen relativ einfachen Testaufbau habe ich deshalb ein 12V Netzteil genommen. Ein anderes Netzteil ... dann habe ich gleich 2 Stromversorgungen rumstehen, für den Regensensor und das RN-Control - auch nicht ideal. Lassen wir es im Moment bei einem Testaufbau und überlegen die endgültige Lösung wenn alles läuft - es gibt noch viel zu tun.

@Alle

So, wieder einen großen Schritt weiter: Das XBee läuft mit der Adapterplatine (inkl. Spannungsapnassungen) und kommuniziert mit dem AVR! Aufbau als Huckepack auf einer Streifenraster-Platine. Vom RN-Control den MAX232 raus und RX, TX an den Port D1 und D2 angeschlossen.

Bisher gehen nur triviale Dinge wie Firmware-Details auslesen - wobei das problematischer ist als reine transparente Datenübertragung: Das XBee ist etwas "empfindlich" bei der Umschaltung in den AT-Commandmodus (Timing!). Es bockt dann gerne und braucht einen Reset.

Im Programm ist jetzt eine zweite Interrupt-Serviceroutine enthalten, die auf Rx reagiert und die empfangenen Zeichen in einen Buffer schreibt. Die Bytes werden direkt aus dem UART-Register gelesen, damit die Performance stimmt. Sieht gut aus, benötigt noch etwas Anpassung wenn es dann um reine Binärdaten vom AM geht sowie die AM-spezifische Logik einen vollständigen Datensatz zu erkennen. Das ist machbar.

Vieles ist noch experimentell, die Gesamtarchitektur der Software muß später überarbeitet werden - wenn die Basis läuft.

Bevor ich den AM steuere werde ich zunächst ein paar Daten auslesen, danach kommt das Setzen des Timer-Flag an die Reihe. Das dauert jetzt ein paar Tage - ich muß zwischendurch an meinen anderen Projekten arbeiten.

Bis die Tage - Gruß, Klaus

@Klaus

Regensensor

Ich habe von CONRAD diesen Sensor. Das lassen sich die Ansprechschwellen einstellen und die Heizung mittels Jumper still legen.

REGENSENSOR FS 20 SR
Artikel-Nr.: 623018 - LN

Da scheint es einen Verlinkungsfehler zu geben. Unter der Bestell-Nr.: 187621 kannst Du das gerät finden.

Eingangsspannung
Ich habe das gleiche Problem, wegen des Regensensors und der Relaissteuerung zwei Netzteile zu benötigen. Ich will als Spannungsregler den vom RN-Funk übrig gebliebenen LF 33 CV einsetzen. Das sieht zwar nicht so schön aus, ist aber im Gehäuse kein Problem. So kann ich alles mit einem 12V Netzteil speisen.

@Alle:
Klaus möchte ja ganz gerne den Framing (API-) Mode des XBee Moduls verwenden, damit aus den verschiedenen Teilnehmern ein Netzwerk entstehen kann. Die Schwierigkeit liegt ja darin, im Automower diesen Frame an der seriellen Schnittstelle des XBee-Moduls zu en- und dekodieren, damit der Automower letztendlich mit den erforderlichen Rohdaten gefüttert wird. Wir brauchen also eine schmale Protokoll-Engine mit zwei seriellen Schnittstellen. Wie wäre es denn hiermit:
http://www.elektor.de/extra/r8c---di...te.83229.lynkx

Dieses R8C13 Board wurde durch Kooperation des Distributors Glyn und der Zeitschrift Elektor stark verbreitet, es gibt tonnenweise Software für das Teil. Und hier die Vorteile für das AM-Projekt:
* Bestehendes DIP-Modul bei Reichelt u.a. für ca. 11-12 Euro.
* Kann mit 3.3V leben, I=11..15mA
* Keine Programmiertools erforderlich, SW über serielle Schnittstelle
* Hat zwei echte UARTS
* Kann auf Lochraster einfach verarbeitet werden
* Programmierbar in C, alle Tools frei. Ein Kollege hat das Ding schon benutzt, funktioniert angeblich tadellos. Auch für die UART-Implementierung gibt es anscheinend viele bestehende Sachen

Ich würde mir das Teil näher ansehen, allerdings sollte es in dieser Runde einen gewissen Konsens geben damit nicht alles doppelt entwickelt wird. Die CPU könnte ich auf dem nächsten XBee Adapterboard auch gleich mit aufbringen, für solche Protokollwandlungen scheint sie ideal zu sein.

Die andere Idee ist ein PIC mit zwei UARTs, da habe ich alle Tools verfügbar, allerdings sind dann Weiterentwicklungen durch andere Leute ohne (kostenpflichtigen) Compiler wieder aussen vor.

Gruß, Harald

@seibot

CONRAD hat ein schönes Durcheinander ... ich habe mit "Regensensor" nur diese einfacher Version (die ich habe) gefunden. Die "bessere" version mit Artikelnummer 187621 findet man nur als "Regenmelder". Daher hatte ich keinen Treffer! Einstellbare Ansprechschwelle, schaltbare Heizung - genau an so etwas hatte ich gedacht. Danke für die Info - das bessere Teil wird bestellt.

@Harald und Alle

Ich schreibe hier mal meine Gedanken zusammen - bitte um Korrektur, wenn es andere Meinungen gibt:

Das Netzwerk (3 Stationen: AM, Basis, PC) ist meine Zielprojektion. Selbstverständlich könnte ein AVR oder PIC im AM noch für weitere Dinge nützlich sein. So gesehen - selbst wenn das Netzwerk aus welchen Gründen auch immer nicht zum Laufen kommt - macht das Board Sinn.

Ganz klar, Doppelentwicklungen sollten wir vermeiden.

Sobald die AM-Kommunikation per AVR fehlefrei und stabil läuft, wäre eine Evaluierung des R8C13 Boards hilfreich. Ich plädiere für dieses Board, weil da offensichtlich Software und Tools frei verfügbar sind. Ich kann mir vorstellen, dass wir im AM-Projekt eine gemeinsame Basisversion entwickeln, auf die später jeder eigene Ideen aufsetzen möchte. Dann sind wir mit dem R8C13 flexibler als mit einem PIC.

Als den Hauptakteur für das R8C13 sehe ich Harald - oder, sagen wir's so, ich habe keine Zeit dazu die AVR-Steuerung beschäftigt mich in der wenigen Freizeit zu 100%.

Das Netzwerk mit mehreren XBee Stationen ist eine weitere Ausbaustufe. Ich kann noch nicht so ganz absehen welchen Aufwand das verursacht und ob da evtl. Komplikationen entstehen. Da ist dann sicher Teamwork hilfreich, auch zum Testen des Systems.

Platinen mit mehreren Baugruppen sind eine schöne Sache. Das sollten wir überlegen, wenn wir über den experimentellen Status raus sind und genauer wissen über welche Bausteine und Gruppen wir reden.

Gruß, Klaus

Zitat:

---

Selbstverständlich könnte ein AVR oder PIC im AM noch für weitere Dinge nützlich sein.

---

Kleine Anekdote am Rand, wo doch unser AM heute am 17.07. seinen ersten Geburtstag feiert:
Meinten meine Arbeitskollegen, nachdem ich ihnen von der Funkanbindung des AM erzählt habe, doch tatsächlich:
Hey, wieso baust Du da nicht gleich mit weißen und roten LEDs Arbeits-, Rück- und Bremslicht ein?

Hmmm, die Idee gefällt mir immer besser - wo doch der Status bereits Kollisionen meldet... :roll:

Aber keine Angst, ich konzentriere mich natürlich erstmal auf die "nützlichen" Dinge.

@Alle
Die Idee, R8C13 Boards einzusetzen, möchte ich gern unterstützen. Ich glaube auch, dass sich viele Komponenten aus Vogons Programm leichter in C portieren lassen, da keine zusätzliche Entwicklungsumgebung nötig ist. Mit dem AVM scheint mir das aufwändiger.
Ich stelle mir die Lösung so vor, dass die Basis mit dem AM absolut autark arbeiten kann, so wie es zurzeit mit PC und AM läuft. Die Verbindung der Basis zum PC könnte der Konfuguration und dem Datensammeln dienen.

Nachtrag

Die Schnittstelle Basis - PC muss nicht unbedingt Funk sein. Es bietet sich an, das 220 V -Netz mittels z.B. Devolo-Kit zu nutzen. Entweder man verbindet die Basis über USB zu einem PC oder es wird die Ethernet-Schnittstelle genutzt.
Ich habe meine gegenwärtige "Basis" (RN- Funkmodul und Relaisschaltung für die Sperrschleife) an einen Ethernet - RS232- Converter EXSYS 6022 mit zwei COM-Schnittstellen angeschlosen. Das Gerät bekommt eine IP-Adresse und ist von jedem beliebigen PC im Netzwerk erreichbar. Ich kann nun im Arbeitszimmer mit Vogons Programm den AM steuern. Das funktioniert auch mit der Händlersoftware Autocheck (aktuell 5.2.1), wenn man die Kommunikation auf 9600 Bit/s umstellt.
Natürlich ist diese Variante nicht die preiswerteste, aber relativ schnell betriebsbereit. An der LS wird ohnehin eine Steckdose benötigt. Ggf. ist noch ein Phasenkoppler zu installieren.

@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

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?

Zitat:

---

Zitat von 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

---

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