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 ):

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. \/

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

Gruß, Klaus