Beleuchtung für Lomo MBS-9 Stereo Mikroskop

Bei meinem Lomo Mikroskop war die Originallampe nicht dabei. Ich habe daher eine passende Lampe gebaut, die mit 10 superhellen LEDs ausgerüstet ist und mit 6-9 Volt betrieben werden kann.


Beleuchtung am Mikroskop befestigt

 


Ätzvorlage

 


Bestückung

Schaltplan. Je nach verwendeter LED müssen die Widerstände evtl. verändert werden, so dass bei einer gegebenen Betriebsspannung der Maximalstrom für eine LED nicht überschritten wird

Wie macht man eine Platine in der Form einer Kreisscheibe?

Z.B. mit einer feinen Stichsäge oder so wie ich es gemacht habe.
Da ich eine Fräse und einen Drehtisch mein Eigen nenne, kann man die Platine am Mittelpunkt in ein Drehfutter einspannen, das auf dem Drehtisch befestigt ist. Dann kann man einfach durch Kurbeln mit einem Fräser auf den beiden Umkreisen die Platine ausschneiden.


Die Platine wurde im Kreismittelpunkt durchbohrt und ins Drehfutter eingespannt.

Das Drehfutter ist auf dem Drehtisch montiert.

 


Ausfräsen des äußeren Kreises

Nach dem Bestücken wurde experimentiert, wie die Lampe befestigt werden kann. Das Lomo Mikroskop hat einen drehbaren Ring mit einer Öse. Daran habe ich zunächst die Lampe mittels eines Stahlwinkels befestigt.


Erster Befestigungsversuch – die Lampe ragt etwas weit in den freien Raum unter dem Objektiv hinein.

Die LEDs sind in diesem Foto nicht stark genug nach innen gebogen eingesetzt, so dass sie nicht in der Mitte des Objektivbildes fokussieren.

Die LEDs wurden in einem zweiten Durchgang stärker nach innen gebogen, so dass sie ausreichend Licht in der Objektivmitte fokussieren.

Außerdem wurde der Winkel nun auf der anderen Seite der Platine befestigt, so dass die Lampe insgesamt deutlich höher sitzt und nicht mehr in den freien Raum unter dem Objektiv hineinragt.

 

Unten die endgültige Version der Befestigung.

 

Weiterführende Infos

Ein Datenlogger mit AVR – Nutzung von Sensoren

Hinweis: Diese Aktivität ist nicht abgeschlossen. Das Dokument beschreibt also den momentanen Stand.

Am AVR können zahlreiche (um nicht zu sagen: zahllose) Sensoren angeschlossen werden. Bei stromsparender Bauweise und Verwendung eines nichtflüchtigen Speichers (großes EEPROM, SD-Karte) können diese Werte über einen langen Zeitraum vom AVR autark gesammelt werden („Data Logger“). Ein bisschen habe ich da auch herumexperimentiert.

Luftdruck und Temperatursensor HopeRF HP03S

Dieser Sensor erfasst Luftdruck und Temperatur als 16-Bit Werte. Er kann mit dem I2C Protokoll  (auch „TWI“, Two Wire Interface genannt) angesprochen werden. Zum Sensor gibt es ein Datenblatt, dass auch die Programmierung darstellt. Allerdings ist das bei HopeRF abgedruckte Programm für 8051-CPUs.


Der Sensor (9,5x9x4,6mm) aus der Nähe. Das Innere ist mit einer gelartigen Masse gefüllt.

Um den Sensor nutzen zu können, muss man ihn elektrisch mit dem AVR verbinden. Ich habe ein Kabel angelötet. Evtl. kann man den Sensor auch direkt auf eine Platine auflöten.


An die sechs Kontakte kann man noch per Hand und ohne Lupe ein Kabel anlöten

Der Sensor wird mit maximal 3,6V betrieben. Man muss also evtl. aus einer 5V-Spannung noch eine geeignete Spannung (also z.B. 3,0 oder 3,3V) ableiten. Er hat einen XCLR-Eingang, der nur während der Messung High sein soll. Außerdem noch einen Masterclock-Eingang MCLK, an den eine Frequenz um 32768Hz anzulegen ist (auch nur während der Messung).  Schließlich noch SDA (Daten) und SCL (Clock) des  I2C-Interfaces um das EEPROM auszulesen.


Die sechs Anschlüsse des Sensors

Ich habe zum Experimentieren 3,0 Volt aus 5 in Serie geschalteten Dioden und einem Vorwiderstand gewonnen, die an +5V anliegen. MCLK, XCLR und SCL sind Leitungen, die nur der AVR beschreibt, daher kann man da die Pegelanpassung mittels zweier Widerstände machen. Der I2C-Bus erfordert, dass die beiden Leitungen mit einem Pullup-Widerstand gegen VCC gelegt sind.

Die SDA-Leitung wird in beide Richtungen genutzt, hier langt ein einfacher Spannungsteiler nicht aus. Man kann sich aber aus zwei Transistoren und drei Widerständen einen schönen Pegelwandler bauen (Erläuterungen dazu hier). Insgesamt ergibt sich das folgende Schaltbild.


Verkabelung zum AVR. Nicht eingezeichnet die beiden Pullup-Widerstände zu 4K7 gegen 3V an den Leitungen SDA und SCL.

Die vier Pins werden an den AVR angeschlossen, ich habe zum Experimentieren folgende Belegung gewählt:

AVR Sensor
PD7 MCLK
PD2 XCLR
PD3 SDA
PD6 SCL

Den Masterclock für den Sensor erzeugt der AVR mit einem Timer, der als PWM-Generator geschaltet ist. Mit einem 16Mhz- bzw. 8Mhz-Quarz bekomme ich nicht genau die Soll-Frequenz, sondern 31372 Hz. Erlaubt laut Datenblatt sind 30..35Khz, also ist meine Frequenz im erlaubten Rahmen.

Es dauerte einige Zeit, bis meine Hardware soweit war, die Calibration Werte auszulesen (hatte erst SDA auch nur mit einfachem Spannungsteiler versucht, was zu Lesefehlern führte). Bei mir kamen im Erfolgsfall folgenden Werte (mehrfache Auslesung):

Environmental Data Logger $Revision: 363 $ 
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11
Environmental Data Logger $Revision: 363 $
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11
Environmental Data Logger $Revision: 363 $
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11
Environmental Data Logger $Revision: 363 $
C1=17837, C2=3189, C3=358, C4=1474, C5=30695, C6=6333, C7=2500. A=7, B=29, C=6, D=11

Aus den Calibration Werten und den eigentlichen Messwerten, die als „raw“ 16-Bit-Werte vorliegen, muss nach einer (ohne Float-Arithmetik) nicht ganz simplem Formel die echten Werte für Temperatur und Luftdruck berechnet werden. Die Formeln sind im Datenblatt angegeben.
(Da der normale Luftdruck auf Meereshöhe eine Art Konstante ist und der Luftdruck mit der Höhe linear abnimmt, kann aus dem Luftdruck und einer passenden Tabelle/Formel übrigens  auch die Höhe des Messorts berechnet werden.)

Bei mir ergaben sich an einem schwülen Tag mit angekündigtem Gewitter (D1 und D2 sind die Raw-Werte, die anderen Werte Zwischenschritte der Umrechnung):

dUT=165
OFF=12774
SENS=17894
D1=41101, D2=30860
Temp=26.5 °Celsius, Pressure=1008.90 hPa (Height ~ 3.0m).
dUT=163
OFF=12773
SENS=17893
D1=41101, D2=30858
Temp=26.5 °Celsius, Pressure=1008.87 hPa (Height ~ 3.0m).

Die Höhe stimmt irgendwie nicht, zugegeben, es müssten um die 120 Meter sein 🙂

Zwei weitere digitale Thermometer, die ich direkt neben den Sensor stelle weichen nur minimal (0.1-0.3 Grad) von dem Messwert des Sensors ab. Die Temperatur stimmt also so in etwa. Genauer kann ich es nicht testen.

Weiterführende Infos

Luftfeuchtigkeitssensor HopeRF HH10D

Von Hope gibt es auch einen Luftfeuchtigkeitssensor, den HH10D. Dieser ist ein kleines Modul bestehend aus einem EEPROM sowie einem Sensor zuzüglich Beschaltung. Die Beschaltung macht aus einem Feuchtigkeitswert einen Frequenzwert. Im EEPROM stehen zwei Kalibrierwerte vom Hersteller.


Ansicht des Sensors HH10D von oben

Der EEPROM-Teil kann via I2C ausgelesen werden, für den Sensor-Teil muss man die entstehende Frequenz messen und mit den Kalibrierwerten in einen echten Messwert umrechnen. Eigentlich wäre es schöner, wenn der Sensor via I2C den Messwert bereitstellen würde, so wie das der HP03s macht. Ist aber nicht so. Die zu messende Frequenz liegt um 7Khz (5-10Khz).


Ansicht des Sensors HH10D von unten. Erkennbar sind das EEPROM und der Spannungs-Frequenz-Konverter. Die Unterseite des Moduls ist vergossen. Die Schnittkante der Platine (oben, unten) ist erstaunlich schlampig ausgeführt (es sieht wie mit der Hand an der Tischkante abgebrochen aus 🙂

Die Nutzung dieses Sensors besteht also darin dass man

  • Zunächst die Kalibrierkonstanten ausliest und dann
  • die Frequenz am Pin FOUT misst.

Mittels eines „Pin Changed“-Interrupts können Signalflankenwechsel an den Eingängen des AVRs erkannt und gezählt werden. Mit einem Timer-Interrupt, der z.B. alle Sekunde eintritt, kann nun der erreichte Zählwert als Frequenzwert des Sensors hergenommen werden.

Bei Experimenten mit einem 8Mhz-getakteten ATmega644, der nebenbei noch diverse Berechnungen machte und via RS232 kommunizierte (aber keine weiteren zeitkritische Interrupts ausführte), konnte ich Frequenzen bis etwa 70Khz sauber vom einem Eingangspin des AVRs lesen. Dies liegt weit über den geforderten maximalen 10Khz des Sensors.

Der HH10D wurde nach erfolgreichem Anschluss in das Logging des Datenloggers integriert. Es muss nur ein zusätzliches Byte mit abgespeichert werden.

Weiterführende Infos

Datenlogger

Nach dem prinzipiellen Anschluss des Sensors HP03s sollte ein Datenlogger entstehen. Designziele waren:

  • Loggen von Temperatur und Luftdruck, später kam noch Luftfeuchte hinzu
  • Speicherplatz für geloggte Daten („Samples“) für einen Zeitraum von mindestens 60 Tagen
  • Stromversorgung durch Akku o.ä. (nicht durch ein Netzteil!) autark für mindestens 60 Tage
  • Auslesen der Daten via RS232 oder USB
  • Nutzung einer Realtime-Clock für das Loggen der Uhrzeit
  • Die Möglichkeit, evtl. weitere Samples zu nehmen, insbesondere Nutzung der ADC-Eingänge des AVRs (Port A)

Aus den Designzielen habe ich abgeleitet:

  • Möglichst geringer Stromverbrauch des Datenloggers
  • Abspeicherung der Samples (Uhrzeit+Temperatur+Luftdruck+…) in einem EEPROM ausreichender Größe

Ein erster Grobentwurf des Dataloggers ist im Bild unten zu sehen. Ein AVR in einem möglichst stromsparenden Betrieb steuert Sensor, RTC (Real Time Clock) und EEPROM an.


Grobschaltbild des Datenloggers mit Sensor, Echtzeituhr und EEPROM (1. Enwurf, später durch ein Design mit 2 I2C-Bussen ersetzt. Das für die Realisierung gewählte EEPROM ist ein 24FC1025 und nicht wie hier im Bild noch beschrieben, ein 24LC1024).

Basierend auf den Designzielen wurde folgendes festgelegt:

  • Ablage der Daten in einem großen EEPROM. Das EEPROM ist ein 128KByte-Typ 24FC1025. Größere EEPROMs, die am I2C-Bus arbeiten, sind mir nicht bekannt.
  • Nutzung eines Realtime Chips (RTC). Die Wahl fiel auf den PCF8583. Vorab wurde bereits die Nutzung des PCF8583 und des EEPROMs am AVR ausprobiert.

Die Anzahl der pro Tag erzeugten Samples ist variabel.

Da ein „Environmental“ Datalogger entworfen wird, sind Temperatur und Luftdruck den natürlichen Gegebenheiten unterworfen. Ein Datalogger für einen Hochofen oder eine Druckkammer hätte mit anderen Wertebereichen zu arbeiten.

Datenplatzbedarf

Annahme: Der Datenlogger nimmt alle 30 Minuten ein Sample vom Sensor. D.h. es werden 48 Samples pro Tag erzeugt.

Abzubildender Temperaturbereich:

Die höchste jemals gemessene natürlich entstandene Temperatur ist +70,7 Grad Celsius (im Iran, 2007), der höchste europäische Wert ist höchstens +50,0 Grad (in Sevilla, Spanien, 1881).
Die niedrigste jemals gemessene natürlich entstandene Temperatur ist höchstens -91,5 Grad Celsius (Antaktis, Wostok-Station, 1997). in Europa höchstens -59,0 Grad Celsius (in Schweden unbestätigt gemessen).
Zu den erwähnten Extremtemperaturen siehe hier.
Mit einem Wertebereich -100…+100 Grad Celsius sind wir also auf der sicheren Seite.

Abzubildender Luftdruckbereich:

Der höchste jemals gemessene Luftdruck beträgt 1085,7hPa (Mongolei, 2001), der niedrigste jemals publizierte Wert beträgt 856hPa (Taifun bei Okinawa, Japan, 1958). Zu diesen Werten siehe hier und hier.
Mit einem Wertebereich 750..1250 käme man also ziemlich gut hin.

Pro Sample müssen folgende Informationen gespeichert werden:

  • Temperatur: Bereich -100 .. +100 Grad Celsius, zwei Nachkommastellen: Ganzzahlanteil 1 Byte, Nachkommaanteil 00..99: 1 Byte, also in Summe 2 Bytes.
  • Luftdruck: Bereich etwa 750..1250, zwei Nachkommastellen.
    Wenn man vom echten Luftdruckwert vor dem Speichern konstant 750 abzieht, kann man mit 9 Bit einen Ganzzahlanteil mit 512 Werten abbilden, also den Bereich 750 .. 1262. Für den Maximalwert 512 benötigt man 2 Bytes, eventuell kann man das 9.te Bit irgendwo anders unterbringen, dann nur 1 Byte. Nachkommaanteil 00..99: 1 Byte, also in Summe 3 Bytes. Evtl. oberstes Bit des 9-Bit Werts des Ganzzahlanteils in oberstem Bit des Nachkommateils mitcodieren, dann wären es in Summe nur 2 Bytes.
  • Zeitstempel: Hier wird z.B. alle 24 Stunden (immer um 0 Uhr) das Datum gespeichert: Jahr, Monat, Tag. Dann werden für die 47 weiteren Samples nur noch gespeichert: Samplenummer ab 1 gezählt.
    Für das Jahr braucht man (beim PCF8583)  2 Bit (0..3), Monat 4 Bit (1..12) und Tag 5 Bit (1..31). In Summe 11 Bit. Dies kann in 2 Bytes abgelegt werden. Für die Folgesamples wird jeweils 1 Byte benötigt, wenn man maximal 256 Samples pro Tag erlaubt oder halt 2 Bytes, dann kann man bis zu 65536 Samples / Tag abbilden.

Damit ergibt sich pro Tag folgender Bedarf (48 Samples / Tag):

1) Annahme: Luftdruck Wert braucht 2 Bytes: (2 Bytes Zeitstempel + 2 Bytes Temperatur + 2 Bytes Luftdruck) + 47 * (1 Byte Samplenummer + 2 Bytes Temperatur + 2 Bytes Luftdruck) = 6+47*5=241 Bytes

2) Annahme: Luftdruck Wert braucht 3 Bytes: (2 Bytes Zeitstempel + 2 Bytes Temperatur + 3 Bytes Luftdruck) + 47 * (1 Byte Samplenummer + 2 Bytes Temperatur + 3 Bytes Luftdruck) = 7+47*6=289 Bytes

Bei 128KByte EEPROM ergibt das in Tagen: 131.072 Bytes/241 = 543 Tage bzw. 453 Tage. Beide Werte sind mehr als ausreichend (Designziel waren 60 Tage).

Abzubildender Feuchte-Bereich

Dies ist mal einfach, es handelt sich um einen Prozentwert 0..100. Evtl. will man noch zwei Nachkommastellen haben, dann kommt ein weiterer Wert 00..99 hinzu. Also ein oder zwei Bytes Speicherbedarf.

Spannungsversorgung

Alle Bausteine hängen am I2C Bus.

Der Sensor wird mit 3,3V betrieben. Das EEPROM und die RTC kann ebenfalls mit 3,3V betrieben werden, ebenso der gewählte AVR ATMega644 (aber nur bis -offiziell- 10MHz Taktfrequenz). Somit wurde entschieden, alles mit 3,3V Versorgungsspannung aufzubauen.

Das Controllerboard ist das bewährte DD Megaboard mit einem 3,3V Spannungsregler LT1117 (statt dem „üblichen“ 7805; der LT1117 wurde gewählt, weil im Fundus vorhanden; der LT1117 ist jedoch eine schlechte Wahl, wenn es um geringen Stromverbrauch geht, siehe weiter unten). Die Schutzdiode vor dem Spannungsregler wurde diesmal durch eine Drahtbrücke ersetzt, um den Spannungsabfall an der Diode zu vermeiden.

Der MAX232CPE kann (inoffiziell) gerade so noch mit 3,3V betrieben werden, dies ist in diversen Foreneinträgen belegt.

Auch ISP funktioniert an 3,3V.

Die extern anliegende Versorgungspannung besteht im Zielbild aus 3-4 Batterien zu je 1,5V, also 4,5V -6,0V.

Stromverbrauch der gewählten Plattform

Nachmessen ergab, dass das DD Megaboard „ohne alles“ (also nur die Stromversorgung mit dem LT1117 3.3 alleine) schon 5,3mA braucht. Bei Betrieb mit Netzteil ist das lächerlich wenig, aber bei Batteriebetrieb schon zu viel.
Ohne das Sensorboard, ohne eingestecktes MAX232 und ohne eingesteckten RS232-Stecker und ohne eingestecktes ISP-Kabel werden 10,7mA verbraucht, d.h. der ATMega 644 verbraucht etwa 5mA bei 8Mhz.
Ein eingesteckter ISP-Stecker erhöht den Stromverbrauch um 0,4mA. Der MAX232CPE erhöht den Verbrauch um weitere satte 5,6mA. Alles zusammen verbraucht 16,7mA (ohne Sensorboard). Eine weitere Reduktion kann nur durch Programmierung des ATMega (Sleep-Modes, Aufwachen nur alle z.B. 10 Sekunden oder auch paar Minuten) erreicht werden.

Der Regler LT1117 3.3 ist nach Datenblatt für eine Anwendung bei minimalem Stromverbrauch definitiv nicht geeignet mit bis zu 5mA Eigenverbrauch. Laut Internet gibt es sparsamere Regler, z.B. den LP2950 in 3,3V Version, mit 75µA Eigenverbrauch, siehe hier: LINK. Ein LP2985 IM5 3,3 (SMD) ist ideal mit unglaublich niedrigen 1µA Ruhestrom.

Wenn der AVR mit set_sleep_mode(SLEEP_MODE_IDLE) und sleep_mode() schlafen geschickt wird, reduzieren sich die oben erwähnten 10,7mA auf 7,4mA. Mein Board braucht selbst wie erwähnt 5,3mA, so dass der AVR also in diesem Zustand nur 2,1mA bei 8Mhz braucht. Laut Quelle (http://www.mikrocontroller.net/articles/Sleep_Mode) soll der AVR bei nur 1Mhz sogar nur 0,3mA brauchen.

Mit einer optimierten Stromversorgung wie dem LP2950 denke ich, dass ohne Änderung der Hardware bei 8Mhz Gesamtverbrauchswerte um 3mA möglich sind. Bei einer Stromquelle, die nutzbare 1000mA liefert können so 333 Stunden überbrückt werden. Dies sind leider nur 333/24 ~ 13 Tage mit dem SLEEP_MODE_IDLE. Das langt aber nicht aus, um die Designziele zu erreichen (60 Tage Betrieb ohne Unterbrechung)

Momentan vorstellbarer Bestfall, wenn die Hardware verändert wird:

  • Die Stromversorgung benötigt 1µA (LP2985)
  • Statt des MAX232CP muß ein Typ verwendet werden, denn man in einen Sleep Zustand versetzten kann. Annahme: Auch dieser Chip verbraucht im Sleepmode nur 1µA
  • Der AVR ist während einer Stunde pro Minute nur 2 Sekunden aktiv, also nur 120 Sekunden in den 3600 Sekunden. Dabei verbraucht er die oben gemessenen 5mA. Pro Stunde sind dies 5000µA*120/3600=167µAh

Im Ergebnis sind dies 169µAh Gesamtverbrauch bei optimalen Annahmen.

Mit 2000mAh NiMh-Zellen, bei denen 1000mAh nutzbar sind (Annahme), kommt man so auf theoretisch 246 Tage (5917 Stunden). Bei solch großen Werten spielt schließlich die Selbstentladung der Akkus eine wesentliche Rolle. Die 60 Tage des Designziels sind aber unter diesen Annahmen sicher erreichbar.

Da mir momentan die entsprechenden Bauteile fehlen (kein passender Spannungsreger, kein abschaltbarer MAX232) mache ich erst mal mit dem weiter was ich habe. Ich kann den Datenlogger auch an eine vorhandene Solarzelle anschließen, die eine weit höhere Leistung liefert als der Datalogger braucht.

Interferenzen des Sensors HP03s mit anderen I2C Geräten

Ich habe ein EEPROM, eine RTC (Realtimeclock, PCF8583) sowie den genannten Sensor an einem I2C Bus betrieben. Dabei traten öfter Störungen auf. Das Auslesen der RTC war, wenn der Sensor gleichzeitig am Bus angeschlossen war, nicht zuverlässig. Variation der Bus-Pullup-Widerstände (an 3,3V Bus von 2K2 auf 1K gesenkt) brachte keine Verbesserung. Analysen mit dem Oszilloskop zeigen, dass das Acknowledge der RTC einen zu geringen Hi-Pegel hat, wenn der Sensor angeschlossen ist. Konkret waren es ohne Sensor ~2,4V, mit Sensor nur noch 1,78V. Dies langt zur Erkennung als HI nicht aus (Daumenregel: LO=weniger als 0,3*VCC, HI=mehr als 0,7*VCC). Herumsuchen in Foren brachte keine weiteren Erkenntnisse. Selbst wenn der Sensor softwaremäßig nicht angesprochen wird, funktioniert das Auslesen der RTC nicht immer (!). Nach drei Tagen Herumprobieren entschied ich mich dazu, das Design des Sensorboards zu ändern: Es gibt nun zwei getrennte I2C-Busse:

  • Einen für den/die Sensoren (Software Implementierung)
  • Einen für RTC und das EEPROM (Hardware-Implementierung)

Nach Änderung der Hardware können nun die drei Geräte (RTC, Sensor HP03S, EEPROM) sauber verwendet werden. Das Hardware-Design ist bereits vorbereitet, um den Luftfeuchtesensor HH10D aufzunehmen.


Schaltbild Sensorboard. Der Wannenstecker oben links dient der Verbindung mit dem AVR, die beiden Wannenstecker in der Mitte dem Anschluss der Sensoren HP03s und HH10D.

Verbindung AVR<->Sensorboard

AVR Pin AVR Pin Bedeutung Sensorboard Wannenstecker Pin Sensorboard Pin Bedeutung
PB3 OC0A PWM Generator Output 4 MCLK von HP03s
PC0 1 SCL (Hardware I2C)
PC1 2 SDA (Hardware I2C)
PC2 3 XCLR von HP03s
PC4 5 SCL2 (Software I2C)
PC5 6 SDA2 (Software I2C)
PC6 7 FOUT von HH10D
9 GND
10 VCC (3,3V)

 


Bild: DD Megaboard rechts, in der Mitte das Sensorboard und ganz links der Sensor HP03s.

 


Das Sensorboard aus der Nähe. Auf dem Sensorboard ist die RTC und das EEPROM sowie die Sicherungsbatterie zu sehen.

I2C Adressen

Die I2C Adressen der einzelnen Bausteine müssen eindeutig sein.

Baustein I2C Adresse Bus Kommentar
Hope HP03s 0xA0 SW Adresse nicht änderbar
Hope HH10 0xA2 SW Adresse nicht änderbar
EEPROM 24FC1025 0xAx11x HW Alternativen möglich (A0,A1,A2)
PCF8583 0xA2 HW Alternativen möglich (A0)

Hier kollidieren die Adressen von RTC und dem Luftdrucksensor. Da beide Bausteine an verschiedenen Bussen liegen, macht dies aber nichts. Über meist vorhandene Adressleitungen A0,A1,A2,… kann die Basisadresse eines I2C Bausteins variiert werden. Dies ist bei den beiden Sensoren nicht möglich, deren Adressen sind fix.

RTC PCF8583 geht viel zu schnell (läuft viel zu schnell)

Bei den ersten Tests zeigte es sich, dass die RTC PCF8583 viel zu schnell lief. Und zwar etwa eine Stunde in 4 Stunden, also satte ~20% zu schnell.

Nachforschen im Datenblatt und in Foren brachte die Erkenntnis, dass direkt an den Pins VCC und GND ein Kondensator zum Abblocken der hochfrequenten Störsignale aus der Versorgungsspannung benötigt wird. Ich hatte im Design einen 100n-Kondensator vorgesehen, diesen aber leider nicht direkt am PCF8583 platziert. Ich habe dann zur Nachbesserung einen 10uF-Kondenstator direkt an die Pins des Chips gelötet (Platinenunterseite). Danach war die Uhr sehr genau (in einem Tag ca. 12 Sekunden Abweichung). Ein weiteres Feintuning muss mit einem 20pF-Trimmer erfolgen (im Datenblatt beschrieben). Diesen Trimmer habe ich zur Zeit noch nicht an der Uhr. Die Datenlogger-Software erlaubt es aber, die Zeit direkt neu einzugeben, somit kann ich mit dem momentanen Zustand und einer leichten Gangabweichung nach einigen Wochen vorübergehend leben.

Weiter

– Einbau in Gehäuse

Betriebssoftware

Für den Datenlogger wurde eine kleine Software geschrieben. Diese ist mittels doxygen in den Sourcen dokumentiert. Die mit doxygen generierte Dokumentation ist unter folgendem Link als Kopie vorhanden:

Dokumentation, erzeugt mit doxygen (Englisch)

Format der Datenausgabe

Im folgenden ein Auszug eines Datendumps:

<dump> 
<header>
 Environmental Data Logger $Revision: 625 $
 number of samples per day: 144
 oldest sample with complete timestamp: 12.01. 16:10
 newest sample with complete timestamp: 11.02. 12:40
 samples in total: 4180
 eeprom start byte: 0x000006
 eeprom end byte: 0x00b3a1
 total bytes in eeprom: 45980
 <date>11.02.</date>
 <time>12:44:15</time>
</header> 
<logdata>
 <log type="long">12.1. 16:10 18.5 1006.40 56.0</log>
 <log type="long">12.1. 16:20 19.2 1006.37 56.9</log>
 <log type="long">12.1. 16:30 19.7 1006.40 56.3</log>
 <log type="long">12.1. 16:40 12.4 1006.9 59.1</log>
 <log type="long">12.1. 16:50 9.1 1005.62 63.6</log>
 <log type="long">12.1. 17:00 7.8 1005.56 65.5</log>
 <log type="long">12.1. 17:10 7.4 1005.56 65.8</log>
 <log type="long">12.1. 17:20 7.1 1005.43 65.7</log>
 <log type="long">12.1. 17:30 7.0 1005.46 65.5</log>
 <log type="long">12.1. 17:40 7.0 1005.43 65.2</log>
 ...
 <log type="long">10.2. 22:50 -9.5 1018.21 34.8</log>
 <log type="long">10.2. 23:00 -9.5 1018.18 34.7</log>
 <log type="long">11.2. 12:40 21.6 1018.9 48.8</log>
<statistics> 
 <temp-min>-14.0</temp-min>
 <temp-max>21.6</temp-max>
 <pressure-min>987.53</pressure-min>
 <pressure-max>1020.87</pressure-max>
 <moisture-min>19.4</moisture-min>
 <moisture-max>78.0</moisture-max>
</statistics>
</logdata>
</dump>

I2C Debugging

Da der I2C Bus nur aus zwei Leitungen besteht, kann man die Aktivitäten auf dem Bus noch gut mit einem Speicher-Oszilloskop mit zwei Eingängen ansehen.

Viele Oszilloskope haben einen externen Triggereingang, den man irgendwo in der Schaltung anklemmt, wo ein Signal zur Verfügung steht, dass als Start-Trigger geeignet ist. Die beiden Eingänge werden dann an SDL und SDA gelegt. Wenn das Oszilloskop eine große Speichertiefe hat, kann man nun das Oszilloskop auf „Single“ Trigger eingestellt und das Trigger-Event herbeigeführt. Danach steht die Geschichte um das Trigger-Event herum im Oszilloskop-Speicher. Man kann nun hineinzoomen, bis man die einzelnen Bits auf den beiden Leitungen sieht. Durch sorgfältiges Abzählen kommt man so auf die Bits und die Bytes.

Ein Datenbit wird in I2C immer bei einer steigenden SCL-Flanke übernommen.

Verwendung des Mikroskops Bresser Biolux AL

Das Mikroskop wird regelmäßig von Lidl angeboten. Laut Internet-Foren hat es eine gute Qualität für den Preis von ca. 60 Euro. Es wird mit einer Videokamera geliefert, die man via USB an den Computer anschließen kann. Mein OpenSuse Desktop hat die Kamera nicht eingebunden, aber mein Acer Netbook mit Linux4One hat die Kamera sofort erkannt. Die folgenden Bilder habe ich mit den mitgelieferten Mustern sowie ein paar Tropfen Aquarienwasser gemacht. Die Kamera liefert für Standbilder 640×480 und für Video 320×240.

Zu den untigen Bildern gibts auch einen Film, in dem man die Tierchen im Aquarienwasser schön sehen kann.
Film: Was quirlt und krabbelt da im (Aquarien-)wassertropfen?


Fliegenbein 1


Fliegenbein 2 – Der Fuß


Fliegenbein 3 – Detail des Fußes


Fliegenbein 4 – Details der Behaarung


Ein unbekanntes Objekt im Aquarienwasser


Das unbekannte Objekt in groß


Ein Fragment von etwas, vielleicht einer Alge


Ein Tierchen (siehe Video)


Eine winzige Pflanze, auf der kleine Tierchen leben (siehe Video)


Ein merkwürdiges Gebilde, das auch bewohnt ist (siehe Video)


Ein weiteres Tierchen, das sich mit einem Fuß an Gegenstände anhaften kann und sich damit auch fortbewegt (siehe Video)

Hier Aufnahmen von einem weiteren der dem Mikroskop beiliegenden Beispiele, ein Querschnitt durch einen kleinen Zweig einer Pflanze.


10x Vergrösserung, Übergang vom Inneren zur „Rinde“


40x Vergrösserung, Teil der „Rinde“


40x Vergrösserung, Der äussere Rand der Rinde

Infos zur Kamera unter Linux

Hier ein paar Ausgaben, die Infos zur Kamera des Mikroskops liefern. Soweit ich aus den Internet Foren erkennen kann, gibt es verschiedene Karema-Typen, die verschiedene Treiber brauchen. Mein Kikroskop wurde im Dezember 2009 bei Lidl gekauft. Die Infos wurden mit OpenSuse 11.1 gewonnen.

Nach Einstecken bringt dmesg:

usb 8-2: new high speed USB device using ehci_hcd and address 2
usb 8-2: configuration #1 chosen from 1 choice                
usb 8-2: New USB device found, idVendor=093a, idProduct=2800 
usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 8-2: Product: USB2.0_Camera                                 
usb 8-2: Manufacturer: PixArt Imaging Inc.                      
uvcvideo: Found UVC 1.00 device USB2.0_Camera (093a:2800)       
input: USB2.0_Camera as /devices/pci0000:00/0000:00:1d.7/usb8/8-2/8-2:1.0/input/input5
usbcore: registered new interface driver uvcvideo                                    
USB Video Class driver (v0.1.0)

          
Ausgabe von xawtv im hardware scan Modus:

dennis@socraggio:~> xawtv -hwscan
This is xawtv-3.95, running on Linux/x86_64 (2.6.27.29-0.1-default)
looking for available devices                                     
port 275-306                                                      
    type : Xvideo, image scaler                                   
    name : NV17 Video Texture                                     
port 307-338
    type : Xvideo, image scaler
    name : NV05 Video Blitter 
/dev/video0: OK                 [ -device /dev/video0 ]
    type : v4l2
    name : Hauppauge WinTV PVR-150
    flags:  capture tuner
/dev/video1: OK                 [ -device /dev/video1 ]
    type : v4l2
    name : USB2.0_Camera
    flags:  capture

Aha, die Mikroskop-Kamera ist video1. Unter Video0 ist eine TV-Karte (Haupage WinTV PVR-150) im Rechner.

Als Treiber lädt OpenSuse:

dennis@socraggio:~> lsmod|grep vid
uvcvideo               56512  0
hwmon_vid               3080  1 it87
compat_ioctl32          8520  2 uvcvideo,ivtv
videodev               35328  4 uvcvideo,tuner,ivtv,compat_ioctl32
v4l1_compat            14220  2 uvcvideo,videodev
nvidia               8148328  26
i2c_core               35296  12 tuner_simple,tda9887,tda8290,wm8775,cx25840,tuner,ivtv,i2c_algo_bit,v4l2_common,tveeprom,nvidia,i2c_i801
usbcore               195712  4 uvcvideo,ehci_hcd,uhci_hcd

–> der ucvideo Treiber ist der richtige, wie ein Check in der Kompatibilitätsliste von http://linux-uvc.berlios.de/#devices zeigt:
Mit der Geräte-Id (aus dmesg ablesbar) von 093a:2800 erhält man folgende Aussage:

93a:2800        DealExtreme USB 2.0 Camera      
Pixart Imaging          SUPPORTED

Hm.  Sollte also gehen. Start von  xawtv -nodga -device /dev/video1 (-nodga da die NVidia-Module keinen DGA beherrschen) bringt leider nur:


dennis@socraggio:~> xawtv -nodga -device /dev/video1
This is xawtv-3.95, running on Linux/x86_64 (2.6.27.29-0.1-default)
xinerama 0: 1600x1200+1600+0
xinerama 1: 1600x1200+0+0
X Error of failed request:  XF86DGANoDirectVideoMode
  Major opcode of failed request:  137 (XFree86-DGA)
  Minor opcode of failed request:  1 (XF86DGAGetVideoLL)
  Serial number of failed request:  13
  Current serial number in output stream:  13
v4l-conf had some trouble, trying to continue anyway
ioctl: VIDIOC_G_STD(std=0x7fffe602d234 [PAL_G,PAL_I,PAL_D,PAL_N,NTSC_M,?,?,SECAM_D,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)]): Das Argument ist ungültig
ioctl: VIDIOC_S_STD(std=0x0 []): Das Argument ist ungültig
ioctl: VIDIOC_DQBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0 [];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=unknown): DasArgument ist ungültig
ioctl: VIDIOC_DQBUF(index=0;type=VIDEO_CAPTURE;bytesused=0;flags=0x0 [];field=ANY;;timecode.type=0;timecode.flags=0;timecode.frames=0;timecode.seconds=0;timecode.minutes=0;timecode.hours=0;timecode.userbits="";sequence=0;memory=unknown): Das Argument ist ungültig

Und dann kommt ein schwarzes Bild, dass ich auch nicht mittels xawtv Controls aufhellen kann.

dennis@socraggio:~> lsusb -d 093a:2800
Bus 008 Device 002: ID 093a:2800 Pixart Imaging, Inc.

Und jetzt? Mit OpenSuse komme ich erst mal nicht weiter.

Mein Netbook erkennt die Kamera allerdings sofort, und das Capture-Program „cheese“ von Linux3One erlaubt es, Fotos und Filme von der Kamera zu holen.
Damit wurden alle Bilder und der Film auf dieser Seite erzeugt.