• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

Die geteilte Stage

thomas_st

Geowizard
Hallo zusammen,

ich hätte da mal wieder eine "kleine" Schaltung vorzustellen. Um das Ganze aber nicht zu sehr mit Details zu überfrachten (wird auch so schon lang genug), erläutere ich dieses Mal eher die grobe Struktur und beantworte dann lieber die Detailfragen, wenn sie auftauchen und gestellt werden.

Die geteilte (Kletter-)Stage

Das Ganze begann recht unspektakulär mit einem Telefonat mit -jha-. Dieser fragte, ob man nicht eine Stage bauen könnte, die man nur zu zweit mit zwei Kletterausrüstungen finden könnte. Klar geht das: da gibt es ja das geteilte Reaktivlicht. Wenn man diesem die RL-Funktionen klauen würde und stattdessen einen einfachen Taster vorsehen würde hätte man alles, was so eine geteilte Stage braucht. Ok, so einfach ist es auch nicht: 1.) will Thomas mit diesem Projekt auch was Neues realisieren und 2.) will er den auf den Baum gekletterten Cachern nicht zumuten, einen LED-Blinkcode zu entschlüsseln :igitt:. Daher schwebte mir vor, die Ausgabe mit Hilfe einer LED-Matrix zu realisieren.

Last but not least fand ich auch eine Fernsteuerung des Ganzen sinnvoll: so könnte man von unten abfragen, ob die Batterien noch ok sind, oder gewechselt werden müssen und kann die Funkparameter an die konkreten Gegebenheiten anpassen ohne dazu auf den Baum zu müssen.

Damit besteht das Projekt aus folgenden 4 Komponenten:
1.) Steuerung der geteilten Stage
- Erkennt die Aktivierung der Stage (Überwachung des Taster)
- gibt die notwendigen Infos auf dem Display aus
- stellt die Kommunikation mit der zweiten Stage sicher
- ermöglicht die Fernabfrage und -konfiguration
2.) LED-Matrix Display
- Stellt die Informationen der Steuerung dar
3.) Modul zur Fernabfrage
- Umsetzung der vom Rechner via serieller Schnittstelle kommenden Befehle in die entsprechenden Funkbefehle
4.) Programm zur Fernabfrage für den Rechner


Prinzip

Die Komponenten 1 und 2 werden zweimal benötigt und zusammen in einem Vogelhaus ähnlichen (oder Briefkasten ähnlichem) Gebilde auf den Baum gehängt - das sind dann die beiden Stationshälften. Komponente 3 und 4 sind nur einmal nötig und dienen nur der Fernabfrage. Das folgende Bild zeigt alle Komponenten zusammen: die beiden Stages in ihren "Vogelhäusern", das Fernsteuerprogramm auf dem Rechner sowie im Vordergrund die Fernsteuerung selbst.


Gesamtsystem

Soweit ist alles fertig und läuft seit ca. 3 Monaten in meiner Wohnung ... und nun weiß ich nicht ob ich das Ganze auch im Wald installieren kann - abhalten tut mich dieser Thread. Na schauen wir mal.

Soweit das Ganze im Groben, nun wenden wir uns den einzelnen Komponenten zu.
 
OP
T

thomas_st

Geowizard
Komponente 1: Steuerung

Die Schaltung der Steuerung ist kein Hexenwerk, sondern basiert prinzipiell auf dem geteilten Reaktivlicht. Auch hier gibt es wieder das RFM12, welches via SPI an den µC angekoppelt ist. Das RFM12 hat auch bei dieser Schaltung die Möglichkeit den µC via IRQ aus seiner "normalen" Tätigkeit zu reißen (z.B. wenn Daten empfangen wurden, oder die zu sendenden Daten auf Reisen sind und das Modul neue Daten benötigt). Einen Unterschied gibt es im verwendeten µC - hier werkelt ein ATMEGA 88 - einerseits um das etwas größere Programm unter zu bekommen und hauptsächlich aufgrund der Hardware-Unterstützung des TWI (I²C): per Software habe ich bisher nur den TWI-Slave realisiert.


Schaltplan der Steuerung

Auf zwei Punkte möchte ich aber hinweisen.
1.) Auf den Spannungsteiler R5/R6. Dieser teilt die Betriebsspannung (bereitgestellt über PC0) in den Bereich der internen Referenzspannung des Mega (1,1V). Unter der Voraussetzung, dass die Referenz unabhängig von der Versorgungsspannung ist (ist sie in gewissen Grenzen) kann man darüber die Betriebsspannung selbst messen (ADC3).

2.) Der MOSFET T1. Ich versuche bei meinen Schaltungen alle Peripheriekomponenten programmgesteuert den Saft abdrehen zu können. So wird das Funkmodul über PB0 aus dem µC versorgt und der Spannungsteiler R5/R6 wie schon geschrieben aus PC0. Ein recht starker Verbraucher ist das Display, welches im Extremfall bis zu 1,5A ziehen kann. Das versorgt man nicht mehr direkt aus einem µC-Pin ;) Auch unsere "normalen" Kleinsignaltransistoren (BCxxx) währen hier überfordert. Um jetzt nicht mit Leistungstransistoren anzufangen, habe ich mich für den "einfachen" Weg entschieden: MOSFET - IRF7220. Wenn man hier einen Typ mit entsprechend kleinen Einschaltwiderstand nimmt, ist die im Transistor frei werdende Leistung so gering, dass auch "kleine" Typen ordentliche Ströme schalten kann. Der verwendete Typ im SO8-Gehäuse verkraftet laut Datenblatt bis zu 11A Dauerstrom. Aufpassen muss man mit der Schaltspannung: viele MOSFET schalten erst bei Gatespannungen von 10V und mehr komplett durch: nach Logic-Level FETs suchen.
Da ich die Versorgung abklemmen will und nicht die Masse, muss der Transistor ein P-Kanal MOSFET sein (analog dem PNP-Bipolartransistor).

Auf den folgenden Bildern könnt ihr die Steuerung sehen. Alles ist soweit klassisch aufgebaut, wobei die beiden SMD Bauteile (RFM12 und IRF7220) auf die Rückseite verband wurden ;).


Platine der Steuerung
 
OP
T

thomas_st

Geowizard
Komponente 2: Display

Ich hatte ja schon geschrieben, dass die Ausgabe der Stage über ein LED-Matrix Display erfolgen soll. In solchen Displays steuert man die einzelnen LEDs nicht mehr separat an, da dies bei der Vielzahl an LEDs nicht mehr praktikabel ist. Vielmehr werden die LEDs gemultiplext, d.h. die Leuchtmuster wird in schneller Folge nacheinander auf den LEDs ausgegeben - und zwar so schnell, dass das Auge dem nicht mehr folgen kann. So sieht das Auge das komplette Leuchtmuster, obwohl jeweils nur ein Bruchteil aller LEDs leuchtet (Beispiel für eine 7x5 LED-Matrix).
So, wie gestaltet man die Ansteuerung? Die erste Möglichkeit wäre, dem µC auf der Steuerplatine auch die Ansteuerung des Displays incl. Multiplex-Betrieb durchführen zu lassen. Ein paar IO-Pins sind noch frei und auch der Programmspeicher ist noch nicht ausgenutzt: über einen Port-Expander (wie z.B. der im mikrocontroller.net-Beispiel genutzte 74x595) könnt dieser µC diese Aufgabe sicherlich noch mit übernehmen. Nur ob das auch wirklich funktioniert: :???: Irgendwie glaube ich nicht, dass das mit der Serial-zu-Parallel-Umwandlung in den Portexpander noch hinreichend flott funktioniert. Für mich ist dies ein Paradebeispiel für die Nutzung eines weiteren µC. Dieser kann A) das gesamte Display steuern oder sich B) die Aufgabe mit weiteren µC teilen und nur einen Teil des Displays ansteuern.
Ich habe mich für letzteres entschieden. Ein eigenständiger ATTINY2313, der ein Teil des Displays - nämlich 8x8 LEDs - ansteuert. Damit komme ich ohne 74x595 aus (der BTW auch nicht so viel preiswerte als ein ATTINY 2313 ist) da der Tiny genug (siehe unten) IO-Pins besitzt um die Zeilen und Spalten des Displays direkt anzusteuern und ich kann das Displays flexibel auf die notwendige Länge erweitern: einfach so viele 8x8-Module hintereinander hängen, bis es hinreichend lang ist.


Schaltplan des Displays

Die Ansteuerung der Displayzeilen erfolgt direkt aus dem Tiny, während die Spalten über den ULN2803 als Spaltentreiber angesteuert werden. Damit wird schnell ersichtlich, dass ich die Spalten multiplexe: eine Spalte wird aktiviert und über die IO-Pins der Zeilen wird das entsprechende Muster ausgegeben - es wird einige Zeit gewartet - es wird die nächste Spalte aktiviert und deren Muster wird über die Zeilen ausgegeben - ... Während über die Zeilen immer nur maximal der Strom einer LEDs fließt, kann über die Spalten maximal der Strom von 8 LEDs fließen - das ist zu viel für einen armen IO-Pin des Tinys -> daher der ULN als Treiber. Noch ein Wort, warum die Ausgänge des ULN und die Spaltenanschlüsse der Matrix so etwas durcheinander gewürfelt verschaltet sind: sie sind so verschaltet, dass ich die wenigsten Leitungskreuzungen auf der Leiterplatte bekomme. Die Zuordnung der Spalten zu den IO-Pins kann dann ja im Programm erfolgen.

Die Daten erhält das Display-Modul via TWI von der Steuerung. ... und damit bekomme ich dann doch Probleme mit der Anzahl der IO-Pins des Tiny: dieser hat ohne umgefuseten Resetpin 17 IO-Pins: 2 brauche ich fürs TWI, bleiben nur noch 15 für das Display - eines zu wenig für ein 8x8 Display. Aus diesem Grund wird über Jumper J1 die unterste Zeile des Displays deaktivieren, wenn der zugehörige IO-Pin fürs TWI benötigt wird.


Platine Einzeldisplay

Um die Module zu einem Display zusammenzuführen, werden diese einfach aneinandergereiht, mit einer individuellen TWI-Slave-ID im EEPROM versehe und zusammen an den Bus gehängt. Der steuernde µC kann über den Bus die Daten an jedes Displaymodul übermitteln und anschließend über einen Befehl an alle Module (Slave-ID 0) gleichzeitig die Übernehme der Daten in die Anzeige initiieren. Damit erreicht man eine sehr flüssige Displayausgabe.


Gesamt-Display

Aufs Programm gehe ich auch erstmal nicht weiter ein, sondern warte auf Eure Fragen. Ein paar Punkte sind - sagen wir mal - suboptimal gelöst, dienen aber einem flotten Multiplexing.
 

Anhänge

  • LED-Matrix.zip
    359,2 KB · Aufrufe: 83
OP
T

thomas_st

Geowizard
Komponente 3: Fernsteuerung

Die Fernsteuerung ist in erster Linie meiner Faulheit geschuldet: die Stages sollen ja in T5-Höhe auf einen Baum gehängt werden. Irgendwie will ich nicht auf den Baum klettern, weil ich leer Batterien vermute nur um festzustellen: die sind ja noch ok. Auch das ganze Prozedere, um optimale Sende- und Empfangsparameter einzustellen, würde ich gerne auf dem Boden erledigen. … und da ja sowieso schon das RFM12 verbaut ist, kann dieses ja für diese Zwecke mit verwenden werden.

Alle ca. 8s wird hierfür die Steuerung vom Watchdog geweckt und das RFM12 als Empfänger aktiviert. Sobald dabei ein an die Stage gerichteter Fernsteuerbefehl empfangen wird, wird die Steuerung in den Sendebetrieb gehen und ein ACK senden. Nach dem ACK werden dann die angeforderten Daten ermittelt und gesendet.

Die Fernsteuerung auf der anderen Seite wird, sobald sie etwas von einer Stage will, einen kontinuierlichen Sende- und Empfangszyklus fahren: erst den Fernsteuerbefehl senden und dann hören ob jemand sich angesprochen fühlt und ein ACK sendet. Sobald ein ACK empfangen wurde, bleibt die Fernsteuerung im Empfangsmodus und empfängt die noch fehlenden Daten.

Diese werden dann aufbereitet und über die serielle Schnittstelle ausgegeben, über die auch der ursprüngliche Befehl entgegengenommen wurde.

Folgende Fernsteuerbefehle sind implementiert:
- Aktuelle Betriebsspannung ermitteln
Übermittelt wird die Vcc im unbelasteten Zustand, nach einer Sekunde Belastung mit einem komplett leuchtenden Display und nach 4s Belastung mit den Display
- Aktueller Zustand der Stage
Wie häufig wurde sie ausgelöst? Wie häufig wurde sie gelöst (also wie häufig wurden beide Stages gleichzeitig aktiviert)?
- Aktivieren der Stage
"Simulieren" des Tastendrucks von unten
- RESET
Rücksetzen der Stage
- Sende- und Empfangsparameter festlegen
Es können alle Sende- und Empfangsparameter für die Kommunikation zwischen den beiden Stages festgelegt werden, mit Ausnahme der Frequenz. Die Sende- und Empfangsparameter für die Fernsteuerung können NICHT beeinflusst werden.
- Sende- und Empfangsparameter abfragen

Der Aufbau der Fernsteuerung ist recht einfach und im folgenden Bild zu sehen.


Schaltplan der Fernsteuerung

Sie besteht eigentlich nur aus einem ATTMEGA88 der das RFM12 anspricht und ein MAX232 der die Pegelwandlung der seriellen Schnittstelle durchführt. Drumherum noch ein paar LEDs über die der aktuelle Zustand visualisiert wird. Neben der eigentlichen seriellen Schnittstelle ist noch eine "pseudo"-serielle Schnittstelle eingebaut, die zwar das serielle Protokoll spricht aber auf Logic-Pegel: 1 = 3,3V / 0 = 0V. Hier schließe ich direkt einen "USB zu Seriell"-Wandler an.

Aufgebaut habe ich das Ganze auf einer Lochrasterplatine, so bin ich flexibel für mögliche Erweiterungen (z.B. könnte man das A-RSSI Signal des Moduls an einen ADC führen und das Ganze als einfachen Frequenzscanner im 433MHz-Band einsetzen).


Fernsteuerung
 
OP
T

thomas_st

Geowizard
Komponente 4: Fernsteuerprogramm

Bleibt nur noch das Programm vorzustellen, mit welchem auf dem Rechner die Fernabfrage der Stages gesteuert werden kann. Allerdings werde ich diesen Part recht kurz halten, da es sich hierbei eigentlich nur um eine grafische Oberfläche um die eigentliche Kommunikation auf der seriellen Schnittstelle handelt. Der Vorteil des Programms gegenüber einer direkten Nutzung des COM-Ports ist allerdings die Übersetzung und Umrechnung der übergebenen Werte: Eine Textzeile wie
BAT B 750 650 651 503 849
ist halt doch etwas schwerer zu verstehen, als die Ausgabe
Stage B hat unbelastet eine Spannung von 4,43V sowie belastet von 3,86V.


Spannungsabfrage


Sende- und Empfangsparameter

Das Programm ist mit Visual C++ geschrieben und nutzt das .NET-Framework.
 
OP
T

thomas_st

Geowizard
Zusammenfassung und "Wo sind denn die Programme?"

Das Ganze läuft seit ca. 3 Monaten kontinuierlich auf meinem Balkon ohne das größere Probleme aufgetreten sind. Ok, eine LED-Spalte einer Stage ist aufgrund einer unsauberen Lötstelle ausgefallen, sonst funktioniert aber alles problemlos.

"Befeuert" werden die Stages mit drei in Reihe geschalteten Baby-Zellen (C-Zelle). In diesen 3 Monaten ist die Spannung der Batterien von 4,55V auf 4,43V (unbelastet) bzw. 4,08V auf 3,86V (belastet) abgesunken (Bsp. für die eine Stage, die Werte der anderen sind ähnlich). In diesem Zeitrahmen wurde die Stage ungefähr 60x ausgelöst.
Über den Daumen gepeilt sollte jedes Auslösen der Stage mit ca. 10mAh zu Buche schlagen - so das diese 60 Auslösungen schon mal 600mAh bedeuten. Der Ruhestromverbrauch der Stage (incl. Aktivierung des Empfängers alle 8s) liegt bei ca. 65µA, so dass da pro Jahr auch nochmal 600mAh zusammenkommen.
Für Baby-Zellen gehe ich mal von einer Kapazität von 8000mAh aus, so dass das Ganze schon ein paar Jahre halten sollte. Andererseits ist die Spannung in den 3 Monaten doch schon merklich abgesunken ... :???: Mal schauen wie es sich entwickelt.

Soweit die Vorstellung des Projektes und nun noch die Frage "Wo sind denn die Programme?". Das Programm für das Display habe ich ja schon oben angeführt. Dass ich die anderen Programme nicht angehängt habe, soll nicht bedeuten, dass ich sie unter Verschluss halten will. Allerdings ist das vorgestellte Projekt recht speziell und wenn jetzt nicht jemand das Teil genauso aufbauen will, wird er den Programmcode kaum verwenden können. Der Teil, der vielleicht für eine breitere Interessengruppe interessant ist (Display) habe ich deshalb angegeben, der Rest gebe ich heraus, wenn es konkrete Fragen und/oder Wünsche dazu gibt.

Viele Grüße und hoffentlich habe ich Euch nicht mal wieder gelangweilt,
Thomas(_st)
 

qByter

Geocacher
:megaeek:
Hammer. Darf ich fragen wie lange Du daran gebastelt hast?

Bevor Detailfragen kommen muss ich mir das erst mal ganz in Ruhe anschauen ;)
 

schnasemann

Geocacher
Seeeeeeeeeeeeeeeeeeeehr schön. Das mit den Funkmodulen könnte man, wenn man etwas Zeit voraussetzt, noch ein wenig stromsparender hinbekommen. Man muss sicherlich nicht im 8s-Rhythmus gucken, ob was da gesendet wird. Da tuts auch alle Minute. Aber ob das die bahnbrechende Stromersparnis darstellt, sei auch mal dahin gestellt.
Warum verwendest Du zur Anzeige kein grafisches Display? Oder, aber nur, weil ich mich gerade damit befasse - ein POV? Ein kleiner Motor (umgebauter Lüfter) und 8 LEDs, die meinetwegen auch stark übersteuert werden dürfen, sind immer noch stromsparender als Dein Display - aber jetzt hast Du's ja eh gebaut :D Allerdings sind meine Erfahrungen mit LED-Matrixen bei Temperatur - Frost, z.B. (Spannungsrisse, kalte Lötstellen) nicht die besten.

Grüße,
schnasemann
 

maierkurt

Geowizard
Super Ding! Hut ab!

Ist das RFM12 von Pollin? Welche Software benutzt Du zum Ansteuern auf dem Atmel? Den von mikrocontroller.net?


Gruß, maierkurt
 
OP
T

thomas_st

Geowizard
qByter schrieb:
Darf ich fragen wie lange Du daran gebastelt hast?
Gerade mal nachgeschaut: die ersten Bauteile habe ich im Mai besorgt und fertig ist es jetzt seit Mitte August - macht also ungefähr 4 Monate (+3 Monate, die ich brauchte, alles zusammenzuschreiben :eek:pa: )

schnasemann schrieb:
Das mit den Funkmodulen könnte man, wenn man etwas Zeit voraussetzt, noch ein wenig stromsparender hinbekommen. Man muss sicherlich nicht im 8s-Rhythmus gucken, ob was da gesendet wird. Da tuts auch alle Minute.
Die Zeit müsste man dann halt warten, wenn man per Fernsteuerung auf die Stage zugreifen will - geht aber natürlich ;)

schnasemann schrieb:
Warum verwendest Du zur Anzeige kein grafisches Display?
LCD? Das Problem ist etwas die Größe - die Stage soll ja auf einen Baum. ... und wenn ich jetzt mal von mir ausgehe: wenn ich da oben bin, bin ich doch etwas geschafft und kann mich nicht auf das doch recht kleine LCD-Display konzentrieren. -> alles schön groß und benutzerfreundlich.

schnasemann schrieb:
Oder, aber nur, weil ich mich gerade damit befasse - ein POV? Ein kleiner Motor (umgebauter Lüfter) und 8 LEDs, die meinetwegen auch stark übersteuert werden dürfen, sind immer noch stromsparender als Dein Display
Ich befürchte da eher, dass das nicht hält. Bei mechanischen Konstruktionen im Wald bin ich sehr skeptisch. ... und (ist jetzt eigentlich kein Grund): ich wollte mal was mit LED-Displays bauen (so habe ich von den Displays auch nicht nur die 14 gebaut, die ich für die zwei Stages brauche, sondern 30 Stück. So wird es wohl irgendwann noch ein Display für was anderes geben ;) :p

schnasemann schrieb:
Allerdings sind meine Erfahrungen mit LED-Matrixen bei Temperatur - Frost, z.B. (Spannungsrisse, kalte Lötstellen) nicht die besten.
Da hatte ich jetzt mit wenig Problemen gerechnet (habe aber keine Erfahrungen in dieser Richtung) - sind ja eigentlich nur x LEDs. Ehrlich gesagt, hätte ich da mehr Sorgen mit LCD-Displays (Trägheit bei niedrigen Temperaturen) und mechanischen Aufbauten wie der POV mit Motor.

maierkurt schrieb:
Ist das RFM12 von Pollin?
Jep.
maierkurt schrieb:
Welche Software benutzt Du zum Ansteuern auf dem Atmel?
Die ist selbst entwickelt - schaue mal in den Thread zum geteilten Reaktivlicht, die dort für die Ansteuerung des RFM12 verwendete Software rfm12.c / rfm12.h nutze ich im Wesentlichen auch hier. Ich bin ein Fan von Interrupt gesteuerter Software und genau diesen nutzt die Software von mikrocontroller.net nicht.

Viele Grüße,
Thomas(_st)
 

schnasemann

Geocacher
thomas_st schrieb:
schnasemann schrieb:
Warum verwendest Du zur Anzeige kein grafisches Display?
LCD? Das Problem ist etwas die Größe - die Stage soll ja auf einen Baum. ... und wenn ich jetzt mal von mir ausgehe: wenn ich da oben bin, bin ich doch etwas geschafft und kann mich nicht auf das doch recht kleine LCD-Display konzentrieren. -> alles schön groß und benutzerfreundlich.
Naja, es gibt z.B. bei Pollin immer wieder günstig gute grafische Displays. Da kann man schon auch große Zahlen drauf darstellen, zur Not eben auch mit einer Laufschrift. Wäre halt Energiesparender, aber jetzt hast Du sowieso Vorrat an LED-Matrixen (jetzt verstehe ich auch Deinen Beitrag nach meinen 50 gelöteten RLs).
ELV verkauft gerade ein Retro-Ping-Pong. Da sind auch 120 LEDs drin. Mit einem Atmega8, den könnte man auch für sowas verwenden. Und hätte Matrix und Platine schon mit dabei.
Grüße,
schnasemann
 

chrysophylax

Geomaster
schnasemann schrieb:
thomas_st schrieb:
schnasemann schrieb:
Warum verwendest Du zur Anzeige kein grafisches Display?
LCD? Das Problem ist etwas die Größe - die Stage soll ja auf einen Baum. ... und wenn ich jetzt mal von mir ausgehe: wenn ich da oben bin, bin ich doch etwas geschafft und kann mich nicht auf das doch recht kleine LCD-Display konzentrieren. -> alles schön groß und benutzerfreundlich.
Naja, es gibt z.B. bei Pollin immer wieder günstig gute grafische Displays. Da kann man schon auch große Zahlen drauf darstellen, zur Not eben auch mit einer Laufschrift.

Selbst wenn man mal die temperaturadaptive Kontrastregelung ausläßt, die bei LCD-Außeneinsätzen absolute Pflicht ist um auf den Dingern überhaupt was erkennen zu können möchte ich lieber nicht wissen, wie das LCD aussieht, nachdem es 1-2 Nächte bei -15°C bis -20°C im Winter draußen verbracht hat und so auskristallisiert ist, daß es vor lauter schwarzen Flecken gar nix mehr anzeigt.... Sämtliche "Kaufprodukte für Outdooreinsatz" (Parkscheinautomaten etc.) schummeln sich um dieses Problem drumherum, indem sie bei zu kleinen Temperaturen dauerhaft die Hintergrundbeleuchtung zum Heizen anwerfen, damit die Flüssigkeit nicht unter -10°C kommt, aber das dürfte bei einem batteriebetriebenen Gerät im Baum etwas schwieriger werden. Und Spezial-LCDs in temperaturfest bis -40°C, wie sie in Autos verbaut werden, bekommt man wahrlich nicht an jeder Ecke.

Von daher find ich die Lösung mit der LED-Matrix auch deutlich praxistauglicher und eleganter....

chrysophylax.
 

qByter

Geocacher
Etwas offtopic, aber:

möchte ich lieber nicht wissen, wie das LCD aussieht, nachdem es 1-2 Nächte bei -15°C bis -20°C im Winter draußen verbracht hat
Ich hab vor kurzem mal testweise ein 08/15-LCD (spezifiert nur bis 0°) für 2 Tage in die Tiefkühltruhe gelegt (-19°)... Das Ding war danach zwar extrem träge (ca. 2 Sekunden Verzögerung beim Anzeigen), funktionierte ansonsten aber einwandfrei.
Mal schauen wie das die nächsten Monate im "Praxistest" aussieht :roll:
 
OP
T

thomas_st

Geowizard
schnasemann schrieb:
[...]jetzt hast Du sowieso Vorrat an LED-Matrixen (jetzt verstehe ich auch Deinen Beitrag nach meinen 50 gelöteten RLs).
:D :eek:ps:
schnasemann schrieb:
ELV verkauft gerade ein Retro-Ping-Pong. Da sind auch 120 LEDs drin. Mit einem Atmega8, den könnte man auch für sowas verwenden. Und hätte Matrix und Platine schon mit dabei.
Na, etwas größer ist mein Display schon. Es hat jetzt 56x7 (einsetzbare) LEDs = 392 (wirklich sind es 56x8, aber die unterste Reihe ist ja komplett abgeschaltet). Ich denke mal, das Teil von ELV ist zwar schön, aber die Platine hätte ich sowieso neu machen müssen.

Viele Grüße,
Thomas(_st)
 

radioscout

Geoking
Warum nicht einfacher? Die Koordinate wird auf Folie gedruckt und hinter einer matten Folie angebracht. Licht von hinten macht die Schrift sichtbar.
 

schnasemann

Geocacher
radioscout schrieb:
Warum nicht einfacher?
:sign2_S: :sign2_P: :sign2_I: :sign2_E: :sign2_L: :sign2_V: :sign2_E: :sign2_R: :sign2_D: :sign2_E: :sign2_R: :sign2_B: :sign2_E: :sign2_R: :sign2_!: ;)

SCNR!
Das mit dem Kontrast bei einer LCD stimmt, ich habe noch eine kleine Entgegnung, VFL. Wäre auch was.

Thomas, verstehe mich nicht falsch, das Ding ist schön, aber 1.5A peak lässt mich schon mal schaudern. Leider werde ich eh nicht in den Genuss der Vogelhäuschen kommen, da ich kein Kletterzeug habe.
 

chrysophylax

Geomaster
schnasemann schrieb:
Das mit dem Kontrast bei einer LCD stimmt, ich habe noch eine kleine Entgegnung, VFL. Wäre auch was.

Hochgradigst edel - steh ich ja total drauf. Ist aber auch alles Andere als stromsparend und richtigrichtig teuer in der Anschaffung. Aber unschlagbar in Kontrast & Ablesewinkel :). Nur baut außer Noritake sowas Feines heute niemand mehr, und die lassen sich ihren Hintern dafür RICHTIG vergolden....

chrysophylax.
 
OP
T

thomas_st

Geowizard
radioscout schrieb:
Warum nicht einfacher? Die Koordinate wird auf Folie gedruckt und hinter einer matten Folie angebracht. Licht von hinten macht die Schrift sichtbar.
Weil ich so, im Fall, dass die Stage noch nicht gelöst wurde und nur eines der beiden "Vogelhäuser" ausgelöst wurde, gleich noch dem Cacher mitteilen kann, wo die andere Stage / Vogelhaus ist.

schnasemann schrieb:
Thomas, verstehe mich nicht falsch, das Ding ist schön, aber 1.5A peak lässt mich schon mal schaudern.
Warum? Bzgl. Laufzeit? Das ist eine Frage der Batterien - momentan habe ich C-Zellen drin, Platz habe ich aber auch gut für D-Zellen. Ehrlich gesagt ist das "Vogelhaus" relativ leer:
.

Viele Grüße,
Thomas(_st)
 

schnasemann

Geocacher
thomas_st schrieb:
schnasemann schrieb:
Thomas, verstehe mich nicht falsch, das Ding ist schön, aber 1.5A peak lässt mich schon mal schaudern.
Warum? Bzgl. Laufzeit? Das ist eine Frage der Batterien - momentan habe ich C-Zellen drin

Peakstrom heißt immer: Das kann mal kommen und muss von der Spannungsversorgung leistbar sein. Wenn Dir dabei der Mikrocontroller abschmiert, ist das ein selbstverstärkender Zustand, der die Batterien bald platt gemacht hat. Das Problem der Batterien ist auch, dass der Innenwiderstand steigt, eine einfache Spannungsmessung sagt also über die Peakstromfähigheit nicht wirklich was aus. Wäre doof, wenn man gerade erst gecheckt hat, dass die Spannungen noch in Ordnung sind und der nächste knipst dem Ding das Licht aus - nachdem er hochgeklettert ist.
 
Oben