Datenlogger mit uC basteln

[Florian Rist]

Hallo,
ich denk grad über ein Projekt nach und um nicht gleich am Anfang arge
konzeptionelle Fehler zu machen würde mich Eure Meinung interessieren.

Ich möchte einen Datenlogger bauen, an den verschiedene digitale
Sensoren angeschlossen werden können sollen. Die Messwerte sollen
gespeichert und später mit einem PC ausgelesen und weiterverarbeitet
werden. Soweit mal nicht allzu Spannend, aber auch nicht ganz einfach.

Es sollen digitale Sensoren, etwa der Maxim Chip DS1621, verwendet
werden. Oft wird zur Übertragung der Messwerte ein I˛C Bus verwendet.
Leider setzen etliche interessante Sensoren eigene ein- oder
zweidrahtige Bussysteme ein, das ist je nur eine frage der Software.

Die Sensoren werden an einen ľController angeschlossen. Fragt sich nur
welcher sich eignet. Ich dachte an einen der AVR Typen von Atmel. Der
ľController muss die Messwerte einsammeln, so vielleicht all 60
Sekunden, und in einen nichtflüchtigen schreiben.

Als Speicher bietet sich ein serieller Flash-RAMs mit I˛C Bus an. Oder
ist der Aufwand für I˛C zu groß und unnötig und man setzt besser was
paralleles ein?

Das ganze soll am besten mit einem Akku als Energiequelle auskommen,
auch über Monate hinweg. Wenn das nicht geht, dann eben Netzteil und
Akkupuffer für den Fall eines kurzen Stromausfalles.

Mir scheint die Hardware einigermaßen überblickbar zu sein. Im Moment
macht mir die Software mehr Sorgen, die muss immerhin die Daten von
etlichen (verschiedenen) Sensoren sammeln und speichern, außerdem muss
sie die Daten auch wieder über eine geigende Schnittstelle (RS-232?)
an einen PC übermitteln können und das am besten ohne die Messungen zu
unterbrechen. Ich hab bisher noch keine Erfahrung in der
Programmierung von ľControllern, war aber mal in Pascal, C/C++ und x86
Assember recht fitt, mit nur etwas aus der Übung.

Was meint Ihr klingt das einigermaßen sinnvoll so? Irgendeine
Empfehlung für ľController, Flash, Bustreiber, etc.?

Ich hoffe das ist nicht noch alles viel zu allgemein. Naja und
vielleicht sind meine Überlegungen ja schon sinnvoll zu kommentieren.

Grüße
Flo

 

[Michael Roth]

Florian Rist wrote:

Ich hab bisher noch keine Erfahrung in der
Programmierung von ľControllern, war aber mal in Pascal, C/C++ und x86
Assember recht fitt, mit nur etwas aus der Übung.

Klein anfangen, iterativ vorgehen. Eierlegenden Wollmilchkühe werden
selten etwas.

Entscheide Dich erstmal für einen Messwert, z.B. Temperatur, und
verwende einen nicht zu komplizierten Controller. Die Teile hast Du für
ein paar Euro zusammen, die ICs könntest Du sogar sockeln, so dass sie
wiederverwendet werden können.

Einen Übungs-Prototyp zum anschließenden Wegwerfen solltest Du Dir schon
gönnen, wenn Du noch keine Erfahrung hast. Danach hast Du davon etwas
mehr...

 

[Florian Rist]

Hallo Michael

Klein anfangen, iterativ vorgehen. Eierlegenden Wollmilchkühe werden
selten etwas.

Ja, klar.

Entscheide Dich erstmal für einen Messwert, z.B. Temperatur,

Ja, genau, mit Temperatur und einem billigen I˛C Sensor wollt ich
anfangen. Später sollen aber andere Sachen dazu, min. andere
(genauere) Temperatursensoren und digitale Feuchtesensoren und wenn's
klappt noch Strömungssensoren.

und verwende einen nicht zu komplizierten Controller.

Ja, das mit der Auswahl eines passenden Controllers ist ohne Erfahrung
nicht so einfach. Mir scheint mir einem kleinen Atmel Controller kann
man nicht viel falsch machen, oder?

Die Teile hast Du für ein paar Euro zusammen, die ICs könntest Du
sogar sockeln, so dass sie wiederverwendet werden können.

Oh ja, ich hab irgendwo noch so ein Steckbrettchen... Vielleicht mal
raussuchen.

Einen Übungs-Prototyp zum anschließenden Wegwerfen solltest Du Dir schon
gönnen, wenn Du noch keine Erfahrung hast. Danach hast Du davon etwas
mehr...

Ja, das denk ich auch und mit den vielen Problemen, die da lauern bin
ich dann wieder hier.

Noch mal kurz zu den Temperatursensoren. Von Maxim gibt's ja nette I˛C
Sensoren, aber alle nicht genau genug. Nun hab ich von IST [1]
genauere gefunden, aber leider nicht mit I˛C sondern mit einem anderen
2draht Interface. Kennt noch jemand genaue Temperatursensoren mit I˛C
Interface? An digitalen Feuchtesensoren wär' ich auch interessiert.


Grüße
Flo

[1] http://www.ist-ag.ch

 

[Dirk Ruth]

Florian Ristschrieb:
"

Hallo,
ich denk grad über ein Projekt nach und um nicht gleich am Anfang arge
konzeptionelle Fehler zu machen würde mich Eure Meinung interessieren.

[...]

Gute Entscheidung. Vielen fragen hier in der Art:
Ich will... Deshalb habe ich jetzt schon mal alles bei Reichelt
gekauft, aber was muss ich jetzt machen ...?

Meine Meinung ist, am Anfang nicht den kleinsten und billigsten
Controller zu kaufen. Die Größeren sind einfach flexibler, haben mehr
RAM, mehr Flash, mehr Portpins und mehr fertig eingebaute
Schnittstellen. Da muss man sich dann nicht mit 'dirty tricks'
'rumärgern und der schnelle Erfolg ist garantiert.

Als nächstes sollte man sich nach einer guten und auch etwas
komfortablen Arbeitsumgebung umsehen. Wenn Du schon mal in C
programmiert hast, dann würde sich hier der kostenlose gcc für den
Atmel empfehlen. Mit Assembler würde ich nicht gleich im ersten
Projekt anfangen, aber das ist hier eher ein Glaubenskrieg.
Also einen guten Editor mit syntax-highlight, ein gutes make-file und
am besten ein fertiges Beispielprojekt, das man für sich umbauen kann.
Es soll ja keine Arbeit, sondern Hobby sein.

Falls Du jetzt schon weißt, das Du mehrere Projekte machen willst,
dann kann sich auch der Kauf eines ICD lohnen. Ansonsten ist halt
debuggen über die UART angesagt.

Das Erste, was auf einem Controller laufen muß, sind die UART (zum
debuggen)
http://www.atmel.com/dyn/resources/prod_documents/doc1451.pdf
http://www.atmel.com/dyn/resources/prod_documents/avr306.zip

und ein timer system.
http://www.avrfreaks.net/modules/FreaksFiles/files/418/DN_031.pdf

Diese beiden Dinge kann man grundsätzlich als erstes auf jeden
Controller aufsetzen.

Was Deine Sonsoren betrifft, so mußt Du hier nach Genauigkeit,
Beschaffbarkeit und Preis ausschau halten. I2C ist kein Problem und
von beinahe jedem Controller zu schaffen, der mind. 8 Beine hat.

Abspeichern in einem EEPROM oder Flash ist auch kein Problem.
Inzwischen gibt es ja auch fertige Routinen zum Lesen und Schreiben
von MMC/SD-Karten, da kann man den Sensor lassen, wo er ist, bzw. muss
den Computer nicht zum Sensor schleppen.

Dirk

 

[Joerg]

Hallo Florian,

ich denk grad über ein Projekt nach und um nicht gleich am Anfang arge
konzeptionelle Fehler zu machen würde mich Eure Meinung interessieren.

Ich möchte einen Datenlogger bauen, an den verschiedene digitale
Sensoren angeschlossen werden können sollen. Die Messwerte sollen
gespeichert und später mit einem PC ausgelesen und weiterverarbeitet
werden. Soweit mal nicht allzu Spannend, aber auch nicht ganz einfach.

Wenn das nicht zum Lerneffekt oder Spass sein soll, dann kann man so
etwas fuer einen moderaten Obulus fertig von der Stange kaufen, bei Euch
wohl in England:
http://www.lascarelectronics.com/promo.cfm?CFID=13128307&CFTOKEN=29465149
Nette Leute, mit astreinem Oxford Akzent.

Wenn ich jetzt den ganzen Spass daran verdorben habe, bitte ich um
Verzeihung.

Gruesse, Joerg

http://www.analogconsultants.com

 

[Florian Rist]

Hallo Joerg

Wenn das nicht zum Lerneffekt oder Spass sein soll, dann kann man so
etwas fuer einen moderaten Obulus fertig von der Stange kaufen, bei Euch
wohl in England:
http://www.lascarelectronics.com/promo.cfm?CFID=13128307&CFTOKEN=29465149
Nette Leute, mit astreinem Oxford Akzent.

Ah, danke, werd ich mir genauer anschauen. Auf den ersten Blick
scheint's mir nicht so geeignet, mal sehen.

Wenn ich jetzt den ganzen Spass daran verdorben habe, bitte ich um
Verzeihung.

Oh nein. Wenn's was passendes günstig gibt ist mir das sogar lieber.
Im Moment stehe ich aber nu vor der Wahl für ein paar hundert EUR
Equipment zu leihen oder mir was passendes zu basteln/kaufen. Jetzt
wird sich das für ein Projekt mir dem Selbstbau nie lohnen, aber
hinterher wäre die Hardware da, der zweite Einsatz sehr günstig und
ich hätte was gelernt, allerdings etwas, das ich wohl nie wieder
brauche.

Grüße
Flo

 

[Florian Rist]

Hallo Dirk

ich denk grad über ein Projekt nach und um nicht gleich am Anfang arge
konzeptionelle Fehler zu machen würde mich Eure Meinung interessieren.

[...]
Gute Entscheidung. Vielen fragen hier in der Art:
Ich will... Deshalb habe ich jetzt schon mal alles bei Reichelt
gekauft, aber was muss ich jetzt machen ...?

Ja, das wollt ich vermeiden, aber dafür gibt's jetzt noch keine ganz
konkreten Fragen.

Meine Meinung ist, am Anfang nicht den kleinsten und billigsten
Controller zu kaufen. Die Größeren sind einfach flexibler, haben mehr
RAM, mehr Flash, mehr Portpins und mehr fertig eingebaute
Schnittstellen. Da muss man sich dann nicht mit 'dirty tricks'
'rumärgern und der schnelle Erfolg ist garantiert.

Ja, das denk ich auch, einfache Sachen werden auch auf größeren
Controller einfach sein, man nutzt nur die Möglichkeiten des
Controllers nicht aus.

Als nächstes sollte man sich nach einer guten und auch etwas
komfortablen Arbeitsumgebung umsehen. Wenn Du schon mal in C
programmiert hast, dann würde sich hier der kostenlose gcc für den
Atmel empfehlen. Mit Assembler würde ich nicht gleich im ersten
Projekt anfangen, aber das ist hier eher ein Glaubenskrieg.

Hab früher mal auch ganz gern Assembler programmiert, aber das hat
sich damals (TM) auch geschwindigkeitsmässig mehr gelohnt als heute
und das bisschen Messdatensammeln wird einen Controller nicht wirklich
überfordern, also wohl her C oder Pascal.

Also einen guten Editor mit syntax-highlight, ein gutes make-file und
am besten ein fertiges Beispielprojekt, das man für sich umbauen kann.
Es soll ja keine Arbeit, sondern Hobby sein.

Ja, ich schau mich mal um, da gibt's ja auch viele Links in der FAQ.

Falls Du jetzt schon weißt, das Du mehrere Projekte machen willst,
dann kann sich auch der Kauf eines ICD lohnen. Ansonsten ist halt
debuggen über die UART angesagt.

Ja, ich glaub das reicht erst mal, sonst wird's doch gleich teuer.
Bequem wär's wahrscheinlich schon und Zeit spart man vielleicht auch…
hmm.

Das Erste, was auf einem Controller laufen muß, sind die UART (zum
debuggen)
http://www.atmel.com/dyn/resources/prod_documents/doc1451.pdf
http://www.atmel.com/dyn/resources/prod_documents/avr306.zip

und ein timer system.
http://www.avrfreaks.net/modules/FreaksFiles/files/418/DN_031.pdf

Diese beiden Dinge kann man grundsätzlich als erstes auf jeden
Controller aufsetzen.

Ah. Danke für die Links.

Vielleicht kann ich so was gleich mal auf dem Simulator, den's von
Atmel gibt laufen lassen? Ist das sinnvoll?

Was Deine Sonsoren betrifft, so mußt Du hier nach Genauigkeit,
Beschaffbarkeit und Preis ausschau halten.

Geschwindigkeit ist wohl kein Problem, wenn sind sie zu schnell, oder?
Aber die Sache mit der Beschaffbarkeit ist nicht so einfach, das hab
ich schon gemerkt. Mal sehen, von IST (und vielen anderen auch)
bekomme ich vielleicht ein Muster, aber wenn funktioniert bräuchte ich
immer mal wieder ein paar und das ist schwierig.

Abspeichern in einem EEPROM oder Flash ist auch kein Problem.
Inzwischen gibt es ja auch fertige Routinen zum Lesen und Schreiben
von MMC/SD-Karten, da kann man den Sensor lassen, wo er ist, bzw. muss
den Computer nicht zum Sensor schleppen.

Oh, das wär natürlich edel. Gibt's die Routinen von Atmel?

Grüße
Flo

 

[Frank-Christian Kruegel]

On Tue, 16 Aug 2005 19:28:10 +0200, Florian Rist <frist@fs.tum.de> wrote:

Die Sensoren werden an einen ľController angeschlossen. Fragt sich nur
welcher sich eignet. Ich dachte an einen der AVR Typen von Atmel. Der
ľController muss die Messwerte einsammeln, so vielleicht all 60
Sekunden, und in einen nichtflüchtigen schreiben.

AVR ist relativ einsteigerfreundlich. Nimm einen etwas größeren, dann hast
Du JTAG, was beim Debuggen extrem angenehm ist, und mehr internes RAM. Die
kleineren und älteren haben nur eine ISP-Schnittstelle, über die Du
programmieren, aber nicht debuggen kannst.

Als Speicher bietet sich ein serieller Flash-RAMs mit I˛C Bus an. Oder
ist der Aufwand für I˛C zu groß und unnötig und man setzt besser was
paralleles ein?

Oder SPI statt i2c. Ist Geschmackssache.

Das ganze soll am besten mit einem Akku als Energiequelle auskommen,
auch über Monate hinweg. Wenn das nicht geht, dann eben Netzteil und
Akkupuffer für den Fall eines kurzen Stromausfalles.

Mir scheint die Hardware einigermaßen überblickbar zu sein. Im Moment
macht mir die Software mehr Sorgen, die muss immerhin die Daten von
etlichen (verschiedenen) Sensoren sammeln und speichern, außerdem muss
sie die Daten auch wieder über eine geigende Schnittstelle (RS-232?)
an einen PC übermitteln können und das am besten ohne die Messungen zu
unterbrechen. Ich hab bisher noch keine Erfahrung in der
Programmierung von ľControllern, war aber mal in Pascal, C/C++ und x86
Assember recht fitt, mit nur etwas aus der Übung.

Die AVRs sind in C ganz gut zu programmieren. Assembler würde ich nur für
die wirklich zeitkritischen Sachen nehmen.

Was meint Ihr klingt das einigermaßen sinnvoll so? Irgendeine
Empfehlung für ľController, Flash, Bustreiber, etc.?

Populäre Alternative sind die PIC 18Fxxx. Hier wirst Du um das ICD2 und den
C18 C-Compiler nicht herumkommen - richtig brauchbare freie Standard ANSI C
Compiler gibts da nicht. RAM ist bei der 18'er Architektur auf 4k begrenzt
(mehr geht nicht, bei AVR kannst DU externes RAM anklemmen), aber die
Peripheriemodule sind manchmal etwas besser. Die PIC Assemblerprogrammierung
finde ich persönlich aber ätzend, aber mit dem C18 läßt es sich aushalten.
Mit freundlichen Grüßen

Frank-Christian Krügel

 

[Joerg]

Hallo Florian,

http://www.lascarelectronics.com/promo.cfm?CFID=13128307&CFTOKEN=29465149
Nette Leute, mit astreinem Oxford Akzent.

Ah, danke, werd ich mir genauer anschauen. Auf den ersten Blick
scheint's mir nicht so geeignet, mal sehen.

Die Speichertiefe erschien mir bei vielen Modellen etwas duenn.

... und
ich hätte was gelernt, allerdings etwas, das ich wohl nie wieder
brauche.

Das kann man nie wissen. Im Studium dachte ich immer, Medizintechnik sei
fuer mich nicht so wichtig. Nun entwickle ich seit fast 20 Jahren meist
genau diese.

Gruesse, Joerg

http://www.analogconsultants.com

 

[Florian Rist]

Hallo Joerg

http://www.lascarelectronics.com/promo.cfm?CFID=13128307&CFTOKEN=29465149
Nette Leute, mit astreinem Oxford Akzent.

Ah, danke, werd ich mir genauer anschauen. Auf den ersten Blick
scheint's mir nicht so geeignet, mal sehen.

Die Speichertiefe erschien mir bei vielen Modellen etwas duenn.

Na ja, 8000 Messwerte, ja viel ist's nicht, stimmt. Ich möchte Luft-,
Bauteil und Oberflächentemperaturen in und an Gebäuden messen, da
brauch ich mindestens für die Oberflächentemperaturen kleine externe
Sensoren mit geringer (thermischer) Masse, die ich z.B. an die
Wandkleben kann. So was geht nur mit den teuren Modellen von Lascar,
wenn ich recht gesehen habe.

... und ich hätte was gelernt, allerdings etwas, das ich wohl
nie wieder brauche.

Das kann man nie wissen.

Stimmt, aber ich bin eigentlich Architekt, also Jedenfalls Dipl. Ing.
Arch., und da sind wohl auch in Zukunft ľController eher ein
Randgebiet.

Im Studium dachte ich immer, Medizintechnik sei fuer mich nicht so
wichtig. Nun entwickle ich seit fast 20 Jahren meist genau diese.

Tja, man kann nie wissen wie' kommt.

Grüße
Flo

 

[Michael Eggert]

Florian Rist <frist@fs.tum.de> wrote:

Hi!

Das Erste, was auf einem Controller laufen muß, sind die UART (zum
debuggen)
http://www.atmel.com/dyn/resources/prod_documents/doc1451.pdf
http://www.atmel.com/dyn/resources/prod_documents/avr306.zip

Empfehlenswert sind außerdem die librarys von Peter Fleury, da zum
Beispiel seine uart-library bereits die Registernamen von vielen AVRs
kennt, während man die von Atmel evtl erst noch umbauen muss - nicht
unbedingt das, was man gleich zu Anfang machen möchte.

http://homepage.sunrise.ch/mysunrise/peterfleury/avr-software.html#libs

Vielleicht kann ich so was gleich mal auf dem Simulator, den's von
Atmel gibt laufen lassen? Ist das sinnvoll?

Wenn Du das AVR-Studio als Entwicklungsumgebung nimmst, geht das - ich
weiß allerdings nicht, ob nur in C oder nur in ASM oder beides. Mir
liegt der gcc mehr.

http://sourceforge.net/projects/winavr

Abspeichern in einem EEPROM oder Flash ist auch kein Problem.
Inzwischen gibt es ja auch fertige Routinen zum Lesen und Schreiben
von MMC/SD-Karten, da kann man den Sensor lassen, wo er ist, bzw. muss
den Computer nicht zum Sensor schleppen.

Oh, das wär natürlich edel. Gibt's die Routinen von Atmel?

http://www.ulrichradig.de/ -> AVR-Projekte -> MMC/SD

Ansonsten gibts viele ANs bei Atmel:

http://www.atmel.com/dyn/products/app_notes.asp?family_id=607

Und viele Links gibts hier:

http://www.mikrocontroller.net/articles/Linksammlung

Gruß,
Michael.

 

[Joerg]

Hallo Florian,

Na ja, 8000 Messwerte, ja viel ist's nicht, stimmt. Ich möchte Luft-,
Bauteil und Oberflächentemperaturen in und an Gebäuden messen, da
brauch ich mindestens für die Oberflächentemperaturen kleine externe
Sensoren mit geringer (thermischer) Masse, die ich z.B. an die
Wandkleben kann. So was geht nur mit den teuren Modellen von Lascar,
wenn ich recht gesehen habe.

Du koenntest natuerlich den USB Pod mit ADC ankleben und den Sensor
daneben. Doch so etwas faellt hier in Kalifornien einige Stunden nach
Sonnenaufgang von der Wand herunter. Kleber haelt meist nicht.

Falls das alles nicht so toll ist, suche mal per Google nach "mote" oder
"motes". Einige Unis hier haben so etwas entwickelt, um z.B. Nistplaetze
ueber ein Jahr klimatisch zu erfassen. Die Dinger sind klein und senden
die Daten ueber Funk. Von einem Mote zum naechsten, bis sie am Server
angekommen sind. Das spart Batterieverbrauch.

Stimmt, aber ich bin eigentlich Architekt, also Jedenfalls Dipl. Ing.
Arch., und da sind wohl auch in Zukunft ľController eher ein
Randgebiet.

Das ist wahr. Allerdings hat ein Architekt mit E-Technik Hintergrund den
Vorteil, dass Bauten nicht mehr durch Nicht-Vorsehen von Comm Kanaelen
vermurkst werden. Ich brauchte zwei Tage und mehrere Mullbinden, bis ich
das Gebaeude hier vernetzt hatte.

Gruesse, Joerg

http://www.analogconsultants.com

 

[Florian Rist]

Hallo Joerg

Na ja, 8000 Messwerte, ja viel ist's nicht, stimmt. Ich möchte Luft-,
Bauteil und Oberflächentemperaturen in und an Gebäuden messen, da
brauch ich mindestens für die Oberflächentemperaturen kleine externe
Sensoren mit geringer (thermischer) Masse, die ich z.B. an die
Wandkleben kann. So was geht nur mit den teuren Modellen von Lascar,
wenn ich recht gesehen habe.

Du koenntest natuerlich den USB Pod mit ADC ankleben und den Sensor
daneben. Doch so etwas faellt hier in Kalifornien einige Stunden nach
Sonnenaufgang von der Wand herunter. Kleber haelt meist nicht.

Und bei 10 Sensoren wird's dann auch gleich doch wieder teuer.

Falls das alles nicht so toll ist, suche mal per Google nach "mote" oder
"motes". Einige Unis hier haben so etwas entwickelt, um z.B. Nistplaetze
ueber ein Jahr klimatisch zu erfassen. Die Dinger sind klein und senden
die Daten ueber Funk. Von einem Mote zum naechsten, bis sie am Server
angekommen sind. Das spart Batterieverbrauch.

Schick, mal schauen, ob ich was finde.

Ein netter Zufallstreffer von eben: Es gibt's nette kleine mini Logger
(leider nur 8kB Speicher und mit 0.5 K etwas ungenau) von Maxim:

http://www.maxim-ic.com/products/ibutton/ibuttons/thermochron.cfm

Stimmt, aber ich bin eigentlich Architekt, also Jedenfalls Dipl. Ing.
Arch., und da sind wohl auch in Zukunft ľController eher ein
Randgebiet.

Das ist wahr. Allerdings hat ein Architekt mit E-Technik Hintergrund den
Vorteil, dass Bauten nicht mehr durch Nicht-Vorsehen von Comm Kanaelen
vermurkst werden.

Ich werde mich bemühen .

Ich brauchte zwei Tage und mehrere Mullbinden, bis ich das Gebaeude hier
vernetzt hatte.

Oh je, den Spaß hatte ich auch schon mal.

Grüße
Flo

 

[Joerg]

Hallo Florian,

Ein netter Zufallstreffer von eben: Es gibt's nette kleine mini Logger
(leider nur 8kB Speicher und mit 0.5 K etwas ungenau) von Maxim:

http://www.maxim-ic.com/products/ibutton/ibuttons/thermochron.cfm

Das passt doch wie die Faust aufs Auge. IIRC hatte Maxim die Firma
Dallas aufgekauft, daher kommt diese 1-wire Technologie wohl. Nun
muesste es die Dinger nur noch mit Bluetooth geben.

Ich brauchte zwei Tage und mehrere Mullbinden, bis ich das Gebaeude hier
vernetzt hatte.

Oh je, den Spaß hatte ich auch schon mal.

Hier muss man unter das Gebauede kriechen (raised foundation). Ich habe
keine Klaustrophobie, aber man weiss nie, wer sich da unten sonst noch
aufhaelt. Der Albtraum waere eine grosse Klapperschlange. Ist hier in
einem Warenlagerhaus passiert, aber zum Glueck war es eine zahme
Schlange. "Miss Hiss" hatte Freiheitsdrang und war mal wieder
ausgebuechst, aber bei einem leckeren Futterangebot ueberlegte sie es
sich doch noch mal.

Gruesse, Joerg

http://www.analogconsultants.com

 

[Rainer Zocholl]

(Joerg) 16.08.05 in /de/sci/electronics:

Hier muss man unter das Gebauede kriechen (raised foundation). Ich
habe keine Klaustrophobie, aber man weiss nie, wer sich da unten sonst
noch aufhaelt. Der Albtraum waere eine grosse Klapperschlange. Ist
hier in einem Warenlagerhaus passiert, aber zum Glueck war es eine
zahme Schlange. "Miss Hiss" hatte Freiheitsdrang und war mal wieder
ausgebuechst, aber bei einem leckeren Futterangebot ueberlegte sie es
sich doch noch mal.

Und das warst Du?

Rainer

 

[Johannes Bauer]

Joerg wrote:

"Miss Hiss" hatte Freiheitsdrang und war mal wieder
ausgebuechst, aber bei einem leckeren Futterangebot ueberlegte sie es
sich doch noch mal.

"Miss Hiss" ist aber auch wieder so ein origineller Name für eine
Schlange. Wie "Hoppel" für Hasen oder "Bello" für Hunde. Muss ich mir
merken ;-)

Gruß,
Johannes

 

[Joerg]

Hallo Rainer,

Hier muss man unter das Gebauede kriechen (raised foundation). Ich
habe keine Klaustrophobie, aber man weiss nie, wer sich da unten sonst
noch aufhaelt. Der Albtraum waere eine grosse Klapperschlange. Ist
hier in einem Warenlagerhaus passiert, aber zum Glueck war es eine
zahme Schlange. "Miss Hiss" hatte Freiheitsdrang und war mal wieder
ausgebuechst, aber bei einem leckeren Futterangebot ueberlegte sie es
sich doch noch mal.

Und das warst Du?

Nein, jemand anders ist ihr begegnet und das war sogar im lokalen
Fernsehen, weil es ein sehr grosses Exemplar war. Hinterher durfte sie
von allen gestreichelt werden.

Gruesse, Joerg

http://www.analogconsultants.com

 

[Joerg]

Hallo Rainer,

Bei uns sind es alles wilde Schlangen, keine "Miss Hiss". Zumeist
Klapperschlangen (rattle snakes), deren Biss sehr giftig ist. Ich hatte
mal aus Versehen beim Sprengen eine voll getroffen. Hinterher sagte mir
jemand, dass haette ich auf keinen Fall tun durfen, weil die ein langes
Gedaechtnis wie Elefanten haben.

Dann haben wir noch sehr schoene Garter Snakes, die bis zu
Besenstiellaenge werden koennen. Sie sind gutartig. Leider etwas zu viel
und deswegen werden sie oft ueberfahren.

Hier kann man sehen, was bei uns so kreucht:
http://www.montereybay.com/creagrus/CAsnakes.html

Gruesse, Joerg

http://www.analogconsultants.com

 

[Joerg Wunsch]

Florian Rist <frist@fs.tum.de> schrieb:

Ich möchte einen Datenlogger bauen, an den verschiedene digitale
Sensoren angeschlossen werden können sollen. Die Messwerte sollen
gespeichert und später mit einem PC ausgelesen und weiterverarbeitet
werden. Soweit mal nicht allzu Spannend, aber auch nicht ganz
einfach.

Guck dir doch mal den AVR Butterfly an.

--
Jörg Wunsch

"Verwende Perl. Shell will man können, dann aber nicht verwenden."
Kristian Köhntopp, de.comp.os.unix.misc

 

[Peter Blancke]

Florian Rist <frist@fs.tum.de> dixit:

Auf den ersten Blick scheint's mir nicht so geeignet, mal sehen.

Die Speichertiefe erschien mir bei vielen Modellen etwas duenn.

Na ja, 8000 Messwerte, ja viel ist's nicht, stimmt.

Ich habe zwar selber noch keinen praktischen Einsatz dafuer gehabt,
aber wenn Du Programmierkenntnisse hast, ist eventuell das
Ethernut-Projekt fuer Dich interessant. Guck mal rein:

http://www.ethernut.de/

Die Platine ist AFAIK komplett fertig beziehbar, auf der Platine
werkelt ein AVR-Controller. Fuer Din Vorhaben ist sicherlich die
On-Board-Ethernet-Schnittstelle von Bedeutung.

Grusz,

Peter Blancke

--
Hoc est enim verbum meum!