Füllstandsanzeige für Zisterne

Hallo Dino,

danke für Deine Bemühungen!

Zunächst habe ich auch mein aktuell verwendetes Kabel vermessen. Die einzelnen Adern im Kabel haben gegeneinander eine Kapazität von 0,83 nF!!!!
Die einzelnen Adern gegen den offenen Schirm bringen es schon auf 1,12 nF und wenn ich den Schirm noch auf Masse lege dann haben z.B. die Signalleitungen SCL und SDA gegen Masse eine Kapazität von 1,23 nF.
Unter Berücksichtigung, dass der gesamte Bus nur 400 pF haben darf schon stattlich.

Also, wie werde ich weiter vorgehen?

1.
Die Filiale vom Computer Arlt hat in Ulm das Cat 5e Kabel in einer Länge von 15m vorrätig. Das werde ich mir zunächst organisieren. Kostet nur 16 Steine. Damit werde ich die Kapazitätsmessung fortsetzen und den Versuchsaufbau nochmals ausprobieren.

2.
Sollte das immer noch nicht funktionieren versuche ich den I2C nur mit 50 kBaud zu fahren und einen Recovery-Mechanismus einzubauen der so aussehen soll, dass wenn Messwerte 0 und 255 gelesen werden de Messung nochmals durchgeführt werden muss.
En schönes Indiz für den Erfolg und Misserfolg ist das Auslesen der Messwerte aus der Tabelle. Wenn die Kommunikation zum SRF sauber funktioniert hat dann bekomme ich in der Tabelle nur die Abstände der erkannten Objekte (Mehrfachechos) in Zentimeter und die restlichen Tabelenplätze sind NULL. Ist die Kommunikation gestört so sehe ich die Werte 255 und 65535. Schrott also.
Dann messe ich halt nochmals.

3.
Sollte Punkt 2. auch scheitern dann muss ich in der Tat über einen Tiny oder ähnliches nachdenken. Dann wirds aber ecklig da ich ja sowohl das I2C-Interface als auch 1Wire und RS232 abdecken muss. Mit einem Tiny44 komme ich damit nicht mehr hin und bei einem Tiny84 z.B. beißen sich auch RS232 und I2C Funktionalität so dass ich eines von beiden "von Hand" auf einem beliebigen Port implementieren muss.
Ich drücke fest die Daumen das die Signalqualität mit einem CAT5e reicht und ich nicht noch zusätzliche HW benötige.

Wir werden sehen.... to be continued .....

Grüße,
Markus
 
Hi Markus ,
1.
Die Filiale vom Computer Arlt hat in Ulm das Cat 5e Kabel in einer Länge von 15m vorrätig. Das werde ich mir zunächst organisieren. Kostet nur 16 Steine. Damit werde ich die Kapazitätsmessung fortsetzen und den Versuchsaufbau nochmals ausprobieren.
Wenn Du etwas Zeit hast dann kann ich heute abend bei mir zuhause mal ein 15m-Ende
CAT5e von Reichelt durchmessen. Die Zeit spart dir dann deine 16 "Steine" :D

3.
Sollte Punkt 2. auch scheitern dann muss ich in der Tat über einen Tiny oder ähnliches nachdenken. Dann wirds aber ecklig da ich ja sowohl das I2C-Interface als auch 1Wire und RS232 abdecken muss.
Ich befürchte, das dir die 1-Wire-Schnittstelle über das Kabel nen Strich durch
die Rechnung machen wird. Ich habe bei meinen Experimenten zuhause
(weil es nicht auf Anhieb funktionierte) nen Oszi drangehängt. Da sind selbst
bei dem 1,5m RG174 von den Klemmen zum BNC ins Scope schon die
Kanten mächtig gerundet (Kabel ohne Tastkopf). Das war bei dem 2us-Puls für
das Senden des 1-Bits zum DS18S20 gerade noch annehmbar. :(

Alternativ kannst Du ja über ne Glasfaser nachdenken :D :p :D

- - - - - - - - - - Ein Einfall - - - - - - - - - - - - - - - -
Mir kam gerade mal eine Idee :)
Warum kein 5 x 1,5qmm Erdkabel nehmen ?
Die Adern sollten wegen der dickeren Isolierung und
dem fehlenden Schirm eigentlich ne kleinere
Kapazität haben. Ich hab da wegen Renovierung
zuhause noch 50m-Ringe NYM-Kabel liegen. Kann
ich ja auch mal durchmessen :) Und dann könnte man
ja nen LM35 (oder wie heißen die I2C-Temp-Sensoren)
statt dem 1-Wire verwenden. Einfach den I2C mit dem
NYM weiterführen, ne PG-Verschraubung ans Ende vom
Kabel, den Sensor in der PG-Verschraubung unterbringen
und das Teil mit Silikon einkitten. Das spart dann den 1-Wire.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Gruß
Dino
 
Hallo zusammen,

nun, ich weiß, das es jetzt etwas Offtopic wird, aber es paßt gerade so schön zu den Leitungskapazitäten.

Ich verwende am SHT71 ein 3m langes Flachbandkabel. Funktioniert auch, hin und wieder kommen aber Fehler rüber. Ich bin dem entgangen, indem ich einfach den PullUp-Widerstand von 10k auf 4,7k verringert habe.

Leider kann ich im Datenblatt nichts finden, was sich über die Leitungslänge ausläßt. Da steht nur was von Anstiegs- und Abfallzeiten der Flanken bei Data out. Offensichtlich spielt es fast keine Rolle, würde aber schon gerne wissen, wie lang die Leitung ungefähr sein darf.

Ist eigentlich ein Flachbandkabel oder ein geschirmtes Kabel die bessere Lösung ?

Thomas
 
Hi Thomas,
Ist eigentlich ein Flachbandkabel oder ein geschirmtes Kabel die bessere Lösung ?
Kommt darauf an, was man machen will. Für Digitalkram würde ich wohl das Flachband
bevorzugen wegen kleineren Kapazitäten zu den Nachbaradern. Bei analogen Sachen
würde ich dann allerdings abgeschirmte Kabel bevorzugen. Jede Aufgabe benötigt ein
entsprechendes Kabel.

Ich hab auch schon überlegt ob man die PullUps bei Markus seinem Problem verkleinert.
Für den PCF8583 RTC an meinem Board hab ich die Datenblätter mal durchgeschaut
und bin bei 5V-Versorgung auf minimal 1,8kOhm gekommen. Wenn man jetzt für SCL
und SDA auf jeder Seite jeweils einen 4,7kOhm dranpappt sind das ca. 2,3kOhm pro
Ader und man verringert die Reflexionen an den Leitungsenden. Das könnte ja auch
schon ein wenig nützen. Scheint aber ein ziemliches rumexperimentieren zu werden :rolleyes:

Mal sehen, heute abend sind einige Kabelkapazitäten mehr bekannt. Evtl ergibt sich
daraus ja schon ein Lösungsweg. :)

Gruß
Dino
 
Füllstandsanzeige

Hallo zusammen,
bereits seit Jahren nutze ich I2C als Bussystem in meinem Garten, immerhin sind es derzeit schon mehr als 1.000 m. Ich fahre mit ca. 15 kHz Bus-Frequenz, I2C wird mit den Wandlern von CCTOOLS hardwareseitig auf CAN umgesetzt. als Kabel verwende ich CAT5.
2 Brunnen (Oberflächenwasser) für die automatische Gartenbewässerung werden von 2 I2C-Slaves (M8 mit US-Sensor und 8 x I/O) alle 5 Sekunden gemessen. Mittelwert über 12 Messungen holt I2C-Master 1x/min ab, der dann den einen oder den anderen oder auch beide Brunnen freigeben oder sperren kann. Funktioniert problemlos.
Meine Brunnen sind rotationsrund (d= 1,6 m), so dass eine einfache Formel ausreicht, um aus dem Abstand des Sensors zur Wasseroberfläche die Füllhöhe und das Füllvolumen auszurechnen. Auch die Sensoren arbeiten bisher einwandfrei.
radebeul
 
Hi radebeul,

Der CAN-Bus scheint auch besser für größere Längen ausgelegt zu sein.
Wenn ich das richtig mitbekommen habe, arbeitet er mit symetrischen
Datensignalen (Daten+ / Daten-) und mit höreren Signalspannungen (+/-12V ??)
Oder irre ich mich da?
Und die 15kHz Busfrequenz erledigen auch schon viele Probleme (gegenüber
50kHz oder sogar 100kHz).
Die Bausteine für CAN sind ja anscheinend auch schon für CAT-Leitungen mit
100Ohm Wellenwiderstand (oder so in der Nähe) ausgelegt.
Und gegenüber z.B. 1-Wire arbeitet man mit einer anderen Bitcodierung. 1-Wire
codiert die Bits ja mit der Länge des negativen Impulses. Da hauen natürlich
kapazitive Einflüsse voll rein und verfälschen oder vernichten einem die Signale.
Ich bin auch noch auf der Suche nach einem einfachen Bus für Steuerdaten im
Haus. Möglichst nur 2 Adern + Schirm (also z.B. Daten, +12V, GND) da ich teilweise
solche Kabel drin habe. Mal sehen was ich da noch finde :rolleyes:
Ich möchte die Übertragung auch möglichst ohne zusätzliche Hardware mit
dem uC hinbekommen.

Gruß
Dino
 
CAN, RS232, I2C, 1Wire gegen Cat und Flachband

Hi all,

ja, der CAN.... Er arbeitet mit 12V und differentiellen Signalen. Bei CAN kommt man auch mit zwei Leitungen für CAN-HI und CAN-LO aus. Den BUS kenne ich auswenig da ich für diesen einst Netzwerkemanagement, Treiber und Transportkanäle für einen digitalen Signalprozessor implementiert habe.

Nur bedeuten diese Ansätze alle zusätzliche Hardware und da könnte ich für meine Anwendung gleich einen Tiny oder Mega spendieren, die Messungen direkt an Ort und Stelle machen und die Ergebnisse via RS232 oder RS485 zur Main-Unit übertragen. Ist vielleicht unumgänglich wenn ich mit der reinen Kabellösung nicht weiter komme.

Fakt ist, ich habe zwei Sensoren. Den Ultraschallsensor SRF08 mit I2C Interface und den temperatursensor DS18S20 mit 1-Wire und mit beiden Sensoren die in meine Zisterne rein sollen muss ich ca. 7 Meter weit in einen Raum kommen in dem die Anzeige eingebaut werden soll.

OK. Nun gehe ich mal Step by Step vorwärts. Ein 15 Meter Cat 5e Kabel liegt neben mir. Allerdings zeigt mir hier mein Messgerät auch eine Kapazität von 0,72 nF von Ader zu Ader bei 15 Meter. Damit wäre das Cat genauso gut oder eher schlecht wie die Steuerleitung welche ich schon in Betrieb hatte
Weiter habe ich vorhin 10 Meter Flachbandkabel erstanden für das der Hersteller eine Kapazität von 45 pF pro Meter garantiert. Mit meinen benötigten 7 Metern wäre ich damit noch unterhalb der 400 pF die für den Bus zulässig sind. Wenn es halt nur mit Flachbandkabel funktioniert dann lege ich in Gottes Namen Flachbandkabel in ein Hohlrohr und gut.
Bei 10 Meter Flachbandkabellänge zeigt mein Messgerät 0,12 nF. Das hört sich doch gegenüber dem Cat-Kabel schon mal richtig gut an. Ich glaube ich mache den Funktionstest gleich mit dem Flachbandkabel und lasse Cat Cat sein.

Und wenns dann immer noch nicht funktioniert dann werde ich mir mal den Mega8 im TQFT Gehäuse naher anschauen. In meinem Gehäuse welches in die Zisterne eingebaut werden soll habe ich nämlich nur 5x4 cm Platz und das bei einer Höhe von 2 cm wobei der Ultraschallsensor ja auch noch Platz haben muss.
Vermutlich werde ich dann diesen Adapter in SMD ausführen müssen damit ich den in die kleine Kiste rein bekomme.

Grüße,
Markus
 
bus

Hallo
Im Garten I2C/CAN, dabei bleibe ich auch, weil's gut funktioniert und die Performance bei 15 kHz ausreicht. Das kleine I2C/CAN-Platinchen von D. Harlos kostet quasi nichts und passt wegen der geringen Größe überall hin.

Im Haus verwende ich Funk mit RFM12, bin da allerdings noch in der Experimentierphase. Aktuell arbeiten 4 Atmegas (M8, M16 und M32- alle auf Pollin-Boards) testweise im Haus, ich verwende das SNAP-Protokoll (derzeit noch mit fester Bytelänge = 14 Nutzbyte + 2 crc-Bytes+1 verlorenes Byte).

Leider habe ich mit ledsee-Displays schlechte Erfahrungen gemacht, zumindest wollen zwei 128x64-Touchdisplays nach kleinen Modifikationen nicht mehr trotz Rückbau auf alten Stand. Kann das evtl. auch an der neuen Bascom-Version liegen?

radebeul
 
Versuch gescheitert!

Soooo, nun habe ich sowohl mit Flachbandkabel als auch mit Cat5e versucht wenigstens den Ultraschallsensor zum Laufen zu bekommen. Das was da auf der Leitung ist sieht alles andere aus als digital und der Sensor macht in beiden Fällen nix bzw. sonst-irgendwas.

@Radebeul: Kannst Du mir bitte den Link zu den CAN-I2C Modulen zusenden und wenn möglich ne kurze Skizze wie Du vom Mega weg die Beschaltung vorgesehen hast. Ich schaue mir die Lösung auf jeden Fall mal an bevor ich mit SMD anfange irgendwas zu basteln und mir ne eigene Lösung zu striken.

Auf jeden Fall kann ich hiermit die Versuche mit Flachbandkabel, Steuerleitung und Cat 5e mit einer Länge von 10 Meter für gescheitert erklären. Ich habe auch versucht die Abschlusswiderstände auf 4k7 zu verkleinern. Bringt nix!

Grüße,
markus
 
Kabelkapazitäten für die, die es noch interessiert

Hallo auch,

ich hab mal ein wenig gemessen und wenn es noch jemanden interessiert ...

UTP-Kabel CAT5e 4x2xAWG24 (also nur 4 Paare ohne jeglichen Schirm)
Ader 4 zu 5 => 45,8pF/m
Aderpaar 1/2 zu 7/8 => 41,6pF/m

SSTP-Kabel CAT6 4x2xAWG27/7 PiMF
Ader 4 zu 5 => 46,4pF/m
Ader 5 zum Schirm => 84,6pF/m
Aderpaar 4/5 zum Schirm => 152,3pF/m

NYM-J 3x1,5qmm
nicht zu empfehlen für Digitalkram - irgendwie mochte mein Meßgerät
das Kabel nicht so richtig. Was auch immer da schief liegt.
Ich habe zwei verschiedene Rollen getestet. Evtl mag die Isolierung
keine Hochfrequenz vom RLC-Meter.

Also das waren erst mal die Werte für zukünftige Experimente ;)

@Markus : Wenn der I2C-Bus bereits so viele Probleme macht wird
der 1-Wire wohl total am Boden liegen (meine Einschätzung) :(

@radebeul : gibt es von den Konvertern Schaltbilder und IC-Bezeichnungen
oder irgendwas ähnliches (Datenblätter). Würde mich technikmäßig
interessieren :)
Im Internet war leider nichts zu finden. Google hat mich im Stich gelassen.
Auch auf den Seiten von Dietmar Harlos war außer der C-Control nichts.

Na denn

Gruß
Dino
 
I2c/can

Hallo
Das ist der Link betr. I2C-Transceiver, Artikelnummer #1823: http://cctools.hs-control.de. Ich habe auch eine ganz kurze Doku, die ich erst morgen nachsenden kann.

Ich habe ein I2C-Bus-System aufgebaut, in dem ein Master (Multimaster kommt vielleicht später nach) mit verschiedenen Slaves kommuniziert. Die einfachen Slaves sind PCF 8574 (A) mit I2C-Transceiver, die im Feld 8 x I/O bereitstellen. Über Relais werden dann Magnetventile 24 V AC und auch Gartenlampen 230 V AC geschaltet. Aktuell sind 11 PCF 8574-Slaves im Einsatz, einige weitere liegen schon bestückt bereit.

Die intelligenten Slaves sind M8, M16 und M32, an deren SDA und SCL einfach die I2C-Transceiver angeschlossen werden. Anfang und Ende des I2C/CAN-Busses müssen definiert mit Widerständen abgeschlossen werden. Noch einmal: CAN wird nur als Transportschicht benutzt, es gibt keine Auswirkungen auf das I2C(TWI)-Programm.

An zwei der intelligenten Slaves (M8) sind lokal US-Sensoren SRF02 angeschlossen. Wegen der Vermeidung von Konflikten mit dem I2C-Bus arbeiten diese Sensoren auf RS232, es werden nur drei Leitungen benötigt. Länge, Impedanz, Kapazität sind bis zu etwa 20 m völlig unkritisch. Die Slaves machen noch andere Sachen wie Temperaturen messen oder...
Der dcf-Master sammelt alle Daten, macht diverse Auswertungen, schaut 1x/min in diversen Tabellen nach und schickt Befehle.

radebeul
 
Hi radebeul,

besten Dank. Recht interessant. Ein IC trennt den I2C in Rx- und Tx-Richtung
für den SCL und SDA auf und zwei CAN-Bus-ICs treiben dann die TP-Paare
für SDA und SCL.
Die Datenblätter und der ApplNote ganz unten auf der Seite sind nicht schlecht.
Ich glaube, die ICs habe ich auch schon mal bei Reichelt gesehen.
Ich hab mich da mal über I2C-Puffer informiert.

Das macht dann also zwei Doppeladern (2 Adernpaare) im CAT-Kabel.
Man könnte also über ein normales LAN-Kabel 2 Busse laufen lassen.

Gruß
Dino
 
Zisterne

Hallo Markus

Ich hoffe nur, dass Du mit Deiner Zisterne besser klar kommst als ich/wir mit dem Teil eines Kollegen. Ich hatte es mit einigen Vereinfachungen mit MathCAD berechnet und wollte dann nachmessen. Das Ergebnis war niederschmetternd.
Letztendlich haben wir die gesamte Zisterne (2000 l) aufgefüllt und kontrolliert wieder entleert. Mit Wasseruhr die Menge und gleichzeitig mit US den Pegelstand gemessen und daraus Tabellenwerte generiert. Funktioniert.

Wenn Du nur 7 m zu überbrücken hast, würde ich Dir vorschlagen, einen M8 zu nehmen, an dem ein US-Sensor über i2c und ein Dallas-DS über 1-wire hängt.Der M8 sitzt direkt vor Ort im Gehäuse des US-Sensors (z.B. Bopla 5x5x3,5 cm³). Du musst dem M8 wahrscheinlich nicht mal einen MAX spendieren, um 7 m weit zu kommen. Die 5 V-Ebene sollte reichen.
Du hättest damit auch den Vorteil, dass der vor-Ort-M8 von Pegel und Temperatur gleitende Mittelwerte bilden kann, die dann zur Anzeige geschickt werden. Das gibt eine ruhige Darstellung der Messwerte.

radebeul
 
Danke für Eure Unterstützung!

Guten Morgen zusammen,

ein herzliches Dankeschön geht an alle die sich in diesem Thread so stark beteiligt haben, Radebeul, Dino, Thomas, .... Danke!

Ich war gestern zu Basteleien bei Thomas (Knickohr) und wir haben nochmals über die gesamte Problematik Datenübertragung gesprochen. Nachdem die ganzen Versuche mit Leitungen usw. gescheitert sind und ich wegen dem zusätzlichen 1-Wire den I2C-CAN-Transceiver nicht verwenden kann erkläre ich das bisherige Konzept und meinen Denkansatz für gescheitert!

Ich kam heute Nach tnoch zu der Erkenntnis den Lösungsvorschlag von Radebeul umzusetzen und wirklich in der wasserdichten Dose einen eigenen Mega8 zu spendieren.

Vorteile:
- 1Wire und I2C können direkt mit kurzen Leitungslängen betrieben werden.
- Datenübertragung vom Slave zum Master via RS232 ist über viele Meter möglich, stabil und sauber!

Ich bin sogar bereit mein altes geplantes und schon gefrästes Gehäuse in die Tonne zu treten und eine größere Variante zu kaufen die es mir ermöglicht die PCB inkl. Mega8 und Ultraschallsensor sauber aufzusetzen und zu planen.

Somit könnt Ihr in den nächsten Stunden / Tagen mit einem neuen Satz Schaltpläne rechnen die das Master/Slave-Knzept abdecken.

Übrigens, der Schaltplan in seiner ursprünglichen Form funktioniert ohne Probleme unter der Berücksichtigung, dass die 1-Wire Leitung zum Temperatursensor (Original) nur 2 Meter lang ist und der I2C mit Flachbandkabel nur einen Meter lang ist. Da funzt das Ding sogar bei 400 kBaud!

Also liebe Leute, es bleibt spannend. Euch allen einen schönen Tag.

.... to be continued ....

Markus
 
Hilfäääää

Hallo zusammen,

habe in der Zwischenzeit meinen "Zisternen-Slave" als Prototyp entwickelt und in Betrieb genommen. Auch der Temperatursensor mit dem Dallas Sensor DS1820 bzw. 18S20 arbeitet bereits (fast) komplett und (fast) richtig.

Der Sensor scheint ohne Probleme zu arbeiten und mir die richtige Temperatur auszugeben. Das Scratchpad kann ohne Probleme gelesen werden, die CRC stimmt und auch die 64Bit ROM-Code werden korrekt gelesen. Ich habe nur eine Ungereimtheit die ich mir nicht erklären kann, die auch im Datenblatt nicht beschrieben ist. Der Sensor liefert mir nach PowerUp beim ersten Auslesen der Temperatur nach Aufschalten der Betriebsspannung den Wert 170 und damit +85°C. Alle danach folgenden Messungen innerhalb eines PowerZyklus sind OK. Nur die aller erste Messung liefert immer 85°C.
Können Ihr Euch das erklären? Ist der Sensor defekt oder habe ich etwas übersehen?

Zuerst dache ich, ich hätte Mist zusammenprogrammiert. Also habe ich mir diverse Implementierungen im Internet besorgt und ausprobiert. Diese liefern aber aber gleiche Ergebnis.
Auch den Code von HB9NMT aus dem Thread
http://www.avr-praxis.de/forum/showthread.php?t=280
habe ich probiert. Liefert als ersten Messwert auch 85°C?

Was tun? Hat jemand ne Ahnung? Ich steht wieder mal echt auf dem Schlauch und bald auf Kriegsfuß mit dem Ding!

Grüße,
Markus
 
Hmmmmmm

Vergesst den letzen Beitrag einfach! Mir viel es gerade wie Schuppen von den Augen. Ich habe im Datenblatt übersehen, dass die Konvertierungszeit bis max. 750 ms beträgt. Kaum macht man's richtig schon geht es. Ich betreibe den Sensor nicht im "parasite power mode" sondern über alle drei Leitungen und da scheint der Zwerg ne ganze Menge Zeit zu benötigen.
Der Wert 170 = 85°C ist der Fehlercode des Sensors und zeigt wohl, dass noch keine Messwerte vorgelegen haben.

Also, mit 750 ms Wartezeit zwischen "Convert T" und dem Auslesen des Scratchpad scheint das Problem zu lösen.

.... man ist das Ding langsam


Grüße,
Markus
 
Hi Markus,

Ich betreibe den Sensor nicht im "parasite power mode" sondern über alle drei Leitungen und da scheint der Zwerg ne ganze Menge Zeit zu benötigen
Eine kleine Verwechslung ?
Bei mir läuft das Teil nämlich mit Parasite-Power (nur 2 Leitungen) und benötigt dann
die 750ms. Bei 3 Leitungen (also mit extra Versorgung) liegt er glaube ich so um
die 200-500ms (glaube ich irgendwo gelesen zu haben). Den genauen Wert habe ich
nicht mehr im Kopf und wo das stand weiß ich im Moment auch nicht mehr.
Oder er benötigt in beiden Modi 750ms.
Ich hab mir schon überlegt, wenn ich im 1 sec Abstand abfrage, die Sache umzudrehen.
Also erst Abfragen und dann die Conversion anstoßen danach warten. Dann hat man
bei der nächsten Abfragen nach 1 sec bestimmt den nächsten Wert :)

Gruß
Dino
 
Hallo dino,

Eine kleine Verwechslung ?

Nein, eigentlich nicht. Ich war anfänglich schon auch davon ausgegangen, dass die "längere" Zeit schon für den parasite power mode gilt und nicht für die konventionelle Spannungsversorgung. Allerdings habe ich dazu keine präzisen Informationen im Datenblatt gefunden. Es steht nur etwas von max. 750 ms und da war ich schon sehr verwundert, als ich die anwenden musste um den Sensor sauber zum Laufen zu bekommen.

Interessanter Weise hatte ich gestern Abend um 22:00 Uhr noch Kontakt mit dem Geschäftsführer der Firma, die den Temperaturmessfühler bauen den ich über Konrad gekauft habe. Du kannst Dich daran erinnern, dass ich ein fertiges Stück Kabel mit Edelstahlrohr vergossen gekauft habe in dem sich der DS18S20 von Dallas befindet. Ja, lange Rede kurzer Sinn, den Herrn der den gesamten Fühler baut habe ich erreicht und der sagte mir zu meiner Frage warum der Sensor 85°C liefert folgendes:

Dieses Phänomen haben wir auch schon festgestellt, auch bei extrem langen Leitungen oder Unterspannung wird 85° gemessen. Eine Erklärung habe ich dafür allerdings auch nicht.

Meine Erklärung dazu ist zunächst einfach die benötigte Zeit. 85°C sind dezimal 170 und das ist genau der Bitcode 10101010 und damit der Fehlercode des Sensors.
Das habe ich dem Hersteller mitgeteilt und folgendes Antwort bekommen:

ja Sie haben vermutlich recht mit den 750 ms. Das ist natürlich ein Handicap bei batteriebetriebenen Systemen oder Datenloggern.

So, ich für meinen Teil bleibe bei den 750 ms da ich nicht zyklisch messen möchte sondern nur bei Bedarf und da kann ich die Zeit auch warten bis ein gültiges Ergebnis angezeigt wird.

Grüße,
Markus
 
ZFA-Slave is running

Guten Abend allerseits,

in den letzten Tagen / Stunden habe ich nun den Ansatz eines externen Slaves für die Messungen verfolgt, welcher seine Messwerte (Rohdaten) via RS232 zum Master überträgt und dieser dann die restliche Berechnung und Anzeige übernimmt.

Heute stelle ich Euch also nun den Slave vor, der als Prototyp bereits arbeitet und für den die PCB auch schon fertig groutet ist. Ihr findet im Anhang folgendes:
- Die EAGLE-Daten (BRD und SCH) als ZIP-File
- Den Schaltplan und das Board als Bild in PDF-Form
- Den BASCOM-Source-Code für den Slave
- zwei Bilder vom Prototyp

Einige Worte zur Umsetzung:
- Die PCB wurde für das Polyamidgehäuse PK 105 75x80x57 designed welches bei Conrad unter der Bestellnummer 524170 zu haben ist.
- Die Wasseroberfläche messe ich mit dem Ultraschallmodul SRF08 aus der Robotertechnik.
-Die Temperatur messe ich mit einem Messfühler der den Sensor Dallas DS18S20 enthält.
- Auf der PCB arbeitet ein kleiner Mega8 mit 16 externen Hertzen und ein wenig Pheripherie.
- Die Versorgungsspannung kommt vom Master.
- Für Entwicklungszwecke habe ich eine Low-Current-LED und ein Reset-Taster eingebaut.
- Zur Programmierung habe ich die 6-polige ISP integriert damit ich auch mit meinem AVRISP mkII direkt auf das Target kann.

So liebe Leute, damit bin ich einen Schritt weiter und im nächsten Schritt werde ich mich an das Redesign des Masters machen welcher hoffentlich bald möglichst schnell die Daten auswerten, verrechnen und anzeigen wird :)

Grüße,
Markus
 

Anhänge

  • ZFA_Slave.bas
    25,5 KB · Aufrufe: 110
  • Fuellstandsanzeige_Slave.zip
    69,5 KB · Aufrufe: 170
  • Fuellstandsanzeige_Slave.pdf
    100,3 KB · Aufrufe: 177
  • slave_ls.jpg
    slave_ls.jpg
    22,7 KB · Aufrufe: 101
  • slave_bs.jpg
    slave_bs.jpg
    22,1 KB · Aufrufe: 97

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)