OSTC erste Eindrücke
Volker Holthaus
ich hatte ja schon ein angedroht meine ersten Eindrücke über den OSTC
(Open Source Tauchcomputer) hier zu posten. Wer sich über den Aufbau,
Aussehen und Preis informieren möchte, kann das unter
http://www.heinrichsweikamp.net/ostc/de/index.htm machen.
Das Gehäuse:
Der Computer ist kompakt gebaut und macht einen robusten Eindruck.
Das Armband erinnert einen sehr stark an die alten Aladin Armbänder. ;-)
Zu dem kleinen Display gibt es noch Anzeigen für den USB Zugriff,
Flugverbot, Warnungen, sowie Batterieladestand.
Mein erster Eindruck war, dass das Display ein wenig klein geraten ist,
das hat sich aber beim Tauchen dann relativiert.
Es gibt zwei Knöpfe an der Gehäuseseite, die ebenfalls einen sehr
robusten und gut bedienbaren Eindruck (auch mit dicken 3 Finger
Handschuhen) hinterlassen haben.
Die Menüführung ist extrem intuitiv gestaltet und sollte wirklich keinen
überfordern.
Es gibt an der Gehäuseseite noch einen Anschluss für den USB Zugriff,
der durch einen kleinen eingesteckten Deckel abgedichtet ist (zwei
kleine O-Ringe). Auf diesen Deckel muss man gut aufpassen, da er sich
gerne versteckt, wenn man die Tauchgänge in JDivelog importiert und ihn
achtlos irgendwo ablegt. :-) Da er aber auch über ein kleine Bohrung
verfügt, könnte man ihn mit einem Band am Gehäuse festmachen.
Die Batterie kann auch über das USB Interface geladen werden. Dazu kann
man entweder einen Laptop oder ein Ladegerät mit USB Anschluß benutzen.
Den aktuellen Akkustand kann man auch in der Oberflächenanzeige in Volt
ablesen.
Die Oberflächen Anzeige:
Das Display ist mit schwarzen Hintergrund und leuchtend gelber Schrift
ausgestattet. Im Oberflächen Modus werden zur Zeit die folgenden Daten
angezeigt:
Firmwareversion
Sättigung der 16 Gewebe (jeweils für N2 und He getrennt)
Gesamtsättigung der 16 Gewebe
Batteriespannung
Druck
Uhrzeit
Datum
Temperatur
Die Tauchanzeige:
Ich habe bisher nur einen flachen Tauchgang gemacht, kann deswegen
leider noch nichts über die Anzeige der Dekostopps sagen (oder
schreiben). Grundsätzlich gefällt mir der Aufbau der Anzeige sehr gut.
Da Sie, wie man im Internet auch schön sieht, selbstleuchtend ist, lässt
sie sich auch sehr gut in dunklen oder trüben Umgebungen ablesen (ohne
Sekundärlicht).
Der Aufbau ist denkbar einfach, es werden die folgenden Daten angezeigt:
Aktuelle Tiefe (groß)
Max Tiefe (groß)
Tauchzeit in Minuten (groß)
Nullzeit in Minuten (groß)
Auf- und Abstiegsgeschwindigkeit (sehr klein, könnte ein wenig größer
sein) in m/min
Aktuelle Temperatur in Grad Celsius (klein)
Über die beiden Tasten lassen sich noch die Gaswechsel oder die
Dekoanzeige aufrufen (konnte ich wie gesagt noch nicht testen).
Bedienung ist sehr einfach und auch (wie schon geschrieben) mit
Handschuhen sehr gut möglich.
Das Menü:
In dem Menü kann ich die Logbucheinträge anschauen, die Parameter für
die Dekoberechnung (ZHL-16), Datum und Zeit, sowie die 5 verschiedenen
Gase (auch mit He Anteil) einstellen.
Im Logbuch bekomme ich die wichtigsten Daten und ein kleines Profil mit
angezeigt (siehe auch die Webseite, dort gibt es Bilder).
Mit den folgenden Parameter kann ich das Verhalten des OSTC verändern
(von der obengenannten Webseite):
Tauchtiefe in cm für Tauchmodus Begin
Tauchtiefe in cm für Tauchmodus Ende
Delay in s für Tauchmodus Ende
Zeit in s für Menüs und Surfacemode
Haltezeit in s für Menüvorstufe
Schwelle in m/min für Anzeige der Vertikalgeschwindigkeit
Absolutdruck in mbar zum Einschalten aus Sleepmode
Max. "erlaubter" Luftdruck in mbar für Luftdruckkompensation im
Schwelle in % für Anzeige des Gradienten Faktors für
Schwelle in % (O2-Gehalt) für Anzeige des aktuellen Gases im Tauchmodus
Delay in s für Menüs im Tauchmodus
Faktor in % für Sättigungsvorgänge *
Faktor in % für Entsättigungsvorgänge *
Verhältnis in % für Flugverbotszeit in Abhängigkeit der Entsättigungszeit
Schwelle in % für optischen Alarm des Gradienten Faktors
Schwelle in % für akustischen Alarm des Gradienten Faktors
Voraussichtlicher Abstand zum Dekostop in 10cm
untere Schwelle in 0,01Bar für ppO2 Warnung *
obere Schwelle in 0,01Bar für ppO2 Warnung *
obere Schwelle in 0,01Bar für Anzeige des ppO2 *
Resümee:
Weil mir das Display (sehr leuchtstark), die Aufteilung der Anzeige, die
Bedienung der Menüs, die Möglichkeit für mehr als 3 Gase (inkl. Trimix),
das kompakte Gehäuse, die Möglichkeit selber in das Geschehen der
Dekoberechnung einzugreifen (bzw. eigene Funktionen für den Computer zu
entwickeln) und der Preis (ist absolut in Ordnung) so sehr gefällt, habe
ich mir einen OSTC bestellt.
Die Daten verarbeite ich auf dem Notebook mit JDivelog (Danke Pascal für
die schnelle Umsetzung :-) )
Was ich zur Zeit noch vermisse, auch wenn es hier sehr kontrovers
diskutiert wird, ist eine integrierte Druckmessung des PTG (dafür ist
der Computer zwar schon vorbereitet, allerdings ist diese Funktionalität
noch nicht umgesetzt), auch wenn ich als Redundanz mit einem
zusätzlichen mechanischen Fini tauche.
Meiner Meinung nach könnte die Anzeige der Aufstiegsgeschwindigkeit auch
ein wenig größer sein, ich denke aber, dass sich dieses Manko sehr
schnell beheben lässt.
Einer der Hauptgründe für meine Entscheidung ist allerdings die
quelloffene Dekompressionsberechnung, sowie die Möglichkeit hier eigene
Funktionen zu implementieren (siehe auch mein Posting zu einem
Tabellencomputer).
Für weitere Fragen könnt ihr euch auch an die Hersteller wenden. Auf der
Internetseite gibt es auch ein Forum, in dem es schon einige Antworten
zu häufig gestellten Fragen gibt.
Um es auch gleich vorne weg zu nehmen, ich werde nicht an dem Verkauf
beteiligt und will euch durch meine subjektiven Eindrücke hier nur ein
paar Entscheidungskriterien liefern, sofern ihr euch mit der
Neuanschaffung eine TC beschäftigt.
Viele Grüße und auf diesem Weg noch ein gutes neues Jahr (wir haben ja
erst den 03. :-) )
Volker
Christian R.
vielen Dank für den, zumindest von mir, mit Spanung erwarteten Bericht :-)
Ich glaube es wird auch bei mir ein verspätetes Weihnachtsgeschenk für
mich geben.
Gruß
Christian
Volker Holthaus
Christian R. schrieb:
> Hallo Volker,
>
> vielen Dank für den, zumindest von mir, mit Spanung erwarteten Bericht :-)
Kein Problem. Pascal hat heute auch seinen ersten Tauchgang mit diesem
Computer gemacht und konnte auch die Dekoanzeige testen. Er ist vollens
begeistert.
>
> Ich glaube es wird auch bei mir ein verspätetes Weihnachtsgeschenk für
> mich geben.
Viel Spass damit.
>
> Gruß
> Christian
>
Gruß
Volker
Peter Rachow
"Volker Holthaus" <v.hol...@procar.de> schrieb im Newsbeitrag
news:5u49n8F...@mid.individual.net...
> Mit den folgenden Parameter kann ich das Verhalten des OSTC verändern
> (von der obengenannten Webseite):
>
> Tauchtiefe in cm für Tauchmodus Begin
....
> obere Schwelle in 0,01Bar für Anzeige des ppO2 *
Sehe ich das richtig: Das Teil kann man nur durch Veränderung der Parameter
in Grenzen neu definieren, man kann aber keine neue Software selbst
schreiben?
vg
Peter
Thomas Fragstein
> Hi Volker,
>
> "Volker Holthaus" <v.hol...@procar.de> schrieb im Newsbeitrag
> news:5u49n8F...@mid.individual.net...
>
>> Mit den folgenden Parameter kann ich das Verhalten des OSTC verändern
>> (von der obengenannten Webseite):
>>
>> Tauchtiefe in cm für Tauchmodus Begin
>> obere Schwelle in 0,01Bar für Anzeige des ppO2 *
>
> Sehe ich das richtig: Das Teil kann man nur durch Veränderung der Parameter
> in Grenzen neu definieren, man kann aber keine neue Software selbst
> schreiben?
>
> vg
>
> Peter
>
>
ich glaube das siehst du falsch.
Hier handelt es sich ja nur um die Einstellungsmöglichkeiten innerhalb
des existierenden Programms.
sobald der Quellcode veröffentlicht ist, kannst du munter darin umschreiben.
Gruß
Thomas
Peter Rachow
> Hier handelt es sich ja nur um die Einstellungsmöglichkeiten
>innerhalb des existierenden Programms.
Aha, OK...
> sobald der Quellcode veröffentlicht ist, kannst du munter darin
>umschreiben.
Auf welchem Controller basiert denn der TC und welche Programmierumgebung
wird benutzt? Und wo findet man den Code?
vg
Peter
Peter Rachow
habe gerade die Webseite gesehen => alle Fragen beantwortet. ;-)
Der Code ist noch nicht veröffentlicht. Schau'n mer mal, was die Jungz da
reinprogrammiert haben... ;-)
vg
Peter
Thomas Fragstein
>
> Auf welchem Controller basiert denn der TC und welche Programmierumgebung
> wird benutzt? Und wo findet man den Code?
>
> vg
>
> Peter
>
>
hier findest Du alle Infos
http://www.heinrichsweikamp.net/ostc/de/
Der Code ist allerdings noch nicht veröffentlicht.
Wird aber noch.
Gruß
Thomas
Peter Rachow
> http://www.heinrichsweikamp.net/ostc/de/
danke, hatte die Seite auch gerade gefunden. Bin mal gespannt, wenn der Code
da ist.
vg
Peter
Volker Holthaus
Peter Rachow schrieb:
Ich auch. Die Datenblätter des Controllers habe ich mir schon aus dem
Web geholt (als kleine Hausaufgabe. :-) )
>
> vg
>
> Peter
>
>
>
Gruß
Volker
Peter Rachow
"Volker Holthaus" <v.hol...@procar.de> schrieb
> Ich auch. Die Datenblätter des Controllers habe ich mir schon aus dem
> Web geholt (als kleine Hausaufgabe. :-) )
Gibt es für den PIC einen C-Compiler frei verfügbar?
vg
Peter
Volker Holthaus
Peter Rachow schrieb:
Da ich unter nur Linux arbeite, kann ich dir für Windows keinen Tipp
geben. Ich werde das voraussichtlich mit gcc machen.
>
> vg
>
> Peter
>
>
Gruß
Volker
Volker Holthaus
Hab noch was vergessen, frag doch mal bei Matthias (Mail Adresse auf der
Webseite oder in dem Forum) nach, der kann dir bestimmt bessere Tipps
geben. ;-)
>
> vg
>
> Peter
>
>
Gruß
Volker
Robert Hammann
> Gibt es für den PIC einen C-Compiler frei verfügbar?
Ich habe mit diesem
sehr gute Erfahrungen gemacht. Fügt sich nahtlos in MPLAP
(Microchip-IDE) ein.
Die Free-Licence ist auf 4k Code beschränkt.
Gruss Robert
Volker Holthaus
Peter Rachow schrieb:
Es gibt von Microchip eine IDE MPLAB (Download:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en019469&part=SW007002
), die für den nicht kommerziellen Bereich auch ein C-Compiler enthält
(C18 für den PIC18FXXXX). Des weiteren habe ich noch ein schöne Seite
gefunden, die auch den Aufbau des Controllers, sowie Programmierung in
den Grundzügen sehr gut beschreibt:
http://www.sprut.de/electronic/pic/index.htm
>
> vg
>
> Peter
>
>
Viele Grüße
Volker
Volker Holthaus
die Firmware in der Version 1.0 und der Sourcecode ist jetzt zum
Download freigegeben. Für alle die sich auch für die Umsetzung des
Dekoalgorithmus interessieren.
Gruß
Volker
Vincent Kessler
Moin,
hab gerade mal einen Blick auf den Sourcecode geworfen.
Ich finds ja klasse, was die Jungs da machen, aber puh, der Code ist
extrem sagen wir mal "ungünstig" konzipiert.
Sinnvoll wäre ein übersichtlich strukturierter Ansatz mit abgegrenzen
Interfaces, so dass einzelne Subsysteme einfach gegen eigene auch
versionsübergreifend ausgetauscht werden können.
Leider ist mit dem PIC Controller meines erachtens eine ungünstige Wahl
getroffen worden. Für so ein Projekt wäre der msp430 von TI meiner
Meinung nach sinnvoller gewesen, der ist extrem stromsparend, 16bit, von
Neumann Architektur und es gibt ein sehr einfaches und billiges JTAG
Interface sowie einen sehr guten GCC Port.
Leider gibts wohl keinen Schaltplan und so habe ich etwas Sorge, dass
auch die Hardwareseite evtl. nicht optimal konzipiert ist.
Ich bin schon nicht abgeneigt einen TC komplett selbst zu programmieren,
doch scheint mir hier das Konzept noch nicht reif zu sein.
Mal sehen, wie es mit dem Projekt weiter geht.
Gruß,
Vinz
Volker Holthaus
Vincent Kessler schrieb:
> Volker Holthaus schrieb, Am 05.01.2008 19:38:
>> Hallo Leute,
> Leider ist mit dem PIC Controller meines erachtens eine ungünstige Wahl
> getroffen worden. Für so ein Projekt wäre der msp430 von TI meiner
> Meinung nach sinnvoller gewesen, der ist extrem stromsparend, 16bit, von
> Neumann Architektur und es gibt ein sehr einfaches und billiges JTAG
> Interface sowie einen sehr guten GCC Port.
Ich habe mich zwar im meinem Studium mit Chipdesign beschäftigt, aber
das ist schon ziemlich lange her und arbeite mich gerade wieder ein
wenig in der Materie ein. Allerdings finde ich überhaupt die Möglichkeit
an der Programmierung was zu ändern schon sehr faszinierend und werde
mich auf jeden Fall dort auch austoben.
Es gibt immer bessere Lösungsmöglichkeiten, allerdings gibt es nur
dieses Projekt und ich glaube wir sollten aus diesen Möglichkeiten das
Beste herausholen. ;-)
> Leider gibts wohl keinen Schaltplan und so habe ich etwas Sorge, dass
> auch die Hardwareseite evtl. nicht optimal konzipiert ist.
> Ich bin schon nicht abgeneigt einen TC komplett selbst zu programmieren,
> doch scheint mir hier das Konzept noch nicht reif zu sein.
Das was ich in der Hand hatte fand sich schon ziemlich reif. ;-) Ich
freue mich über ein solches Projekt und es gibt viele, die sich immer
darüber beschwert hatten, dass die Algorithmen nie offen gelegt werden.
Jetzt werden sie es und müssen sich dadurch natürlich auch der Kritik
stellen. Aber wie schon geschrieben, mir gefällt der Computer sehr gut
und ich werde auf jeden Fall auch eigene Module schreiben, auch wenn der
Code vielleicht nicht optimal aufgebaut ist.
> Mal sehen, wie es mit dem Projekt weiter geht.
Ich bin guter Hoffnung.
>
> Gruß,
>
> Vinz
Gruß
Volker
Peter Rachow
"Volker Holthaus" <v.hol...@procar.de> schrieb
> Es gibt immer bessere Lösungsmöglichkeiten, allerdings gibt es nur
> dieses Projekt und ich glaube wir sollten aus diesen Möglichkeiten das
> Beste herausholen. ;-)
Ich denke, was die Anbieter dieses Gerätes tun müssen, ist ihre
Schittstellen genau zu definieren so dass man diese selbst auslesen und
ansteuern kann. Wenn man weiß, wie der Drucksensor zu lesen ist, der
Temp.-sensor und das Display anzusteuern ist, dann kann man die ganze
Software selber stricken. So würde ich es jedenfalls tun: Die Hardware als
Basis für eine komplett selbst geschriebene Software zu verwenden. Und dann
nicht in ASM sondern in C, denn der Cotroller hat ja schließlich laut
Datenblatt eine für C optimierte Architektur.
Da bleibe ch doch lieber beim SBTC mit seinem AVR, auch wenn der was die
Energieeffizienz bertrifft noch lange nicht das Optimum darstelt. Und die
Hardware des SBTC kostet nicht mal die die Hälfte der Hardware des OSTC. ;-)
vg
Peter
Volker Holthaus
Peter Rachow schrieb:
> Ich denke, was die Anbieter dieses Gerätes tun müssen, ist ihre
> Schittstellen genau zu definieren so dass man diese selbst auslesen und
> ansteuern kann. Wenn man weiß, wie der Drucksensor zu lesen ist, der
> Temp.-sensor und das Display anzusteuern ist, dann kann man die ganze
> Software selber stricken. So würde ich es jedenfalls tun: Die Hardware als
> Basis für eine komplett selbst geschriebene Software zu verwenden. Und dann
> nicht in ASM sondern in C, denn der Cotroller hat ja schließlich laut
> Datenblatt eine für C optimierte Architektur.
Ich denke diese Informationen lassen sich auch aus dem Source lesen und
dann für die eigene Software verwenden.
>
> Da bleibe ch doch lieber beim SBTC mit seinem AVR, auch wenn der was die
> Energieeffizienz bertrifft noch lange nicht das Optimum darstelt. Und die
> Hardware des SBTC kostet nicht mal die die Hälfte der Hardware des OSTC. ;-)
Wenn ich den Computer laden kann, dann interessiert mich die
Energieeffizienz eigentlich nicht besonders. Ich schliesse ihn einfach
an die gleiche Steckdose, wie ich auch meine Lampe, an. ;-)
>
> vg
>
> Peter
>
>
Gruß
Volker
Matthias Heinrichs
Ich freue mich, das wir hier für etwas Diskussion sorgen konnten.
> Temp.-sensor und das Display anzusteuern ist, dann kann man die ganze
> Software selber stricken. So würde ich es jedenfalls tun: Die Hardware als
> Basis für eine komplett selbst geschriebene Software zu verwenden. Und dann
> nicht in ASM sondern in C, denn der Cotroller hat ja schließlich laut
> Datenblatt eine für C optimierte Architektur.
Hier wirst Du ziemlich fündig:
http://www.heinrichsweikamp.net/ostc/de/hardware.htm
Im Schaltplan sind auch die ganzen Stecker- und Portbelegungen drin. Die
Ansteuerung der div. Peripherie sind in den entsprechenden Datenblättern
zu finden.
> Energieeffizienz bertrifft noch lange nicht das Optimum darstelt. Und die
> Hardware des SBTC kostet nicht mal die die Hälfte der Hardware des OSTC. ;-)
"Low-Budget" war nicht unsere gesuchte Marktnische und ja, seit dem C-64
bin ich _hoffnungslos_ Assembler-geschädigt (Im positiven Sinne....)
Gruss,
Matthias
Peter Rachow
> Ich denke diese Informationen lassen sich auch aus dem Source lesen und
> dann für die eigene Software verwenden.
Stimmt. Aber ich habe gerne genau definierte Arbeitsunterlagen. ;-)
> > Da bleibe ch doch lieber beim SBTC mit seinem AVR, auch wenn der was die
> > Energieeffizienz bertrifft noch lange nicht das Optimum darstelt. Und
die
> > Hardware des SBTC kostet nicht mal die die Hälfte der Hardware des OSTC.
;-)
>
> Wenn ich den Computer laden kann, dann interessiert mich die
> Energieeffizienz eigentlich nicht besonders. Ich schliesse ihn einfach
> an die gleiche Steckdose, wie ich auch meine Lampe, an. ;-)
Genau. Habe gerade die 3. Generation des SBTC in der Mache und habe ihm
einen größeren Akku spendiert, weil ich die Schaltung stark vereinfacht habe
und nun auf einmal viel ungenutzten Platz über hatte. Jetzt sind 10 Tage
Dauerbetrieb kein Problem mehr. Außerdem experiementiere ich gerade mit
einem Ladeverfahren über Induktion, so dass das Gehäuse nicht geöffnet
werden muss, wenn der Akku schwächelt.
vg
Peter
Vincent Kessler
> Hi zusammen,
>
Moin,
>
> Ich denke, was die Anbieter dieses Gerätes tun müssen, ist ihre
> Schittstellen genau zu definieren so dass man diese selbst auslesen und
> ansteuern kann. Wenn man weiß, wie der Drucksensor zu lesen ist, der
> Temp.-sensor und das Display anzusteuern ist, dann kann man die ganze
> Software selber stricken. So würde ich es jedenfalls tun: Die Hardware als
> Basis für eine komplett selbst geschriebene Software zu verwenden. Und dann
> nicht in ASM sondern in C, denn der Cotroller hat ja schließlich laut
> Datenblatt eine für C optimierte Architektur.
genau das sehe ich als suboptimal an.
Es wäre doch sinnlos, wenn jeder, der seine eigene Deko, Menüführung
oder Kontrolleursveraschung programmieren will, sich von vorne mit den
hardwarenahen Schnittstellen auseinandersetzen muss.
Gerade das ist ein Teil, der meiner Meinung nach sauber implementiert
und dokumentiert gehört mit Softwareschnittstellen, die auch einen
Versionssprung überleben.
>
> Da bleibe ch doch lieber beim SBTC mit seinem AVR, auch wenn der was die
> Energieeffizienz bertrifft noch lange nicht das Optimum darstelt. Und die
> Hardware des SBTC kostet nicht mal die die Hälfte der Hardware des OSTC. ;-)
>
Einen AVR würde ich auch einem PIC vorziehen. Gerade für ein OpenSource
Projekt überwiegen die Vorteile des AVR bei weitem.
> vg
>
> Peter
>
>
Gruß,
Vinz
Vincent Kessler
>
> Genau. Habe gerade die 3. Generation des SBTC in der Mache und habe ihm
> einen größeren Akku spendiert, weil ich die Schaltung stark vereinfacht habe
> und nun auf einmal viel ungenutzten Platz über hatte. Jetzt sind 10 Tage
> Dauerbetrieb kein Problem mehr. Außerdem experiementiere ich gerade mit
> einem Ladeverfahren über Induktion, so dass das Gehäuse nicht geöffnet
> werden muss, wenn der Akku schwächelt.
>
Benutzt du noch den selben Drucksensor, oder hast du da auch was anderes
verwendet? Mir schien das etwas aufwendig, wie es auf deiner Homepage
dokumentiert ist.
Erzähl mal, wenn du das mit der Induktion ausprobiert hast. Das finde
ich eine prima Idee.
> vg
>
> Peter
>
>
Gruß, Vinz
Vincent Kessler
> Leider gibts wohl keinen Schaltplan und so habe ich etwas Sorge, dass
> auch die Hardwareseite evtl. nicht optimal konzipiert ist.
Erfreulicher weise ist gerade der Schaltplan veröffentlicht worden!
Das ist ein sehr vernünftiger Schritt für das Projekt. Erhöht die
Glaubwürdigkeit enorm. Ich werde den mal durchschauen und mich dazu äußern.
Gruß, Vinz
Vincent Kessler
schön, dass du hier auch schreibst.
Wie kam es, dass eure Wahl auf den MS5541B gefallen ist?
Allgemein wäre es schön, wenn ihr bei Gelegenheit mal erläutert, wie ihr
die Komponenten ausgewählt habt, die in eurem TC verbaut sind.
Eine prima Erläuterung findet man z.B. auf der Hompage von Peter, wo er
die Konstruktion seines SBTC dokumentiert hat.
Gruß,
Vinz
Volker Holthaus
Peter Rachow schrieb:
> Dauerbetrieb kein Problem mehr. Außerdem experiementiere ich gerade mit
> einem Ladeverfahren über Induktion, so dass das Gehäuse nicht geöffnet
> werden muss, wenn der Akku schwächelt.
Die Idee finde ich wirklich klasse. Wenns klappt ist wieder eine Öffnung
im Gehäuse weniger, die als Schwachstelle dienen kann. :-)
>
> vg
>
> Peter
>
>
Gruß
Volker
Peter Rachow
"Vincent Kessler" <kessler...@nscit.com> schrieb
> Benutzt du noch den selben Drucksensor, oder hast du da auch was anderes
> verwendet? Mir schien das etwas aufwendig, wie es auf deiner Homepage
> dokumentiert ist.
Yep. Ich habe allerdings die Verstärkerschaltung stark vereinfacht. Sieht
jetzt in etwa so aus:
http://www.ece.uvic.ca/~ece499/2004b/group17/pressure_cct1.jpg
Vout führt direkt zum Eingang des AD-Wandlers im Controller ohne weitere
Spannungsteiler ertc. V+ des Sensors liegt über 2.7k an +5V, hinzu kommt
noch ein Glättungs-C. Das war's.
> Erzähl mal, wenn du das mit der Induktion ausprobiert hast. Das finde
> ich eine prima Idee.
Die Feldspule hat 500 Wdg. 0,5 mm CuL-Draht mit einem quadratischen Fe-Kern
und liegt an 15 V~. Die Induktionsspule hat ebenfalls 500 Wdg. aus 0,1 mm
CuL-Draht auf Fe-Kern und wird ungefähr 10mm von der Feldspule abgelegt.
Dazwischen ist ein Al-Blech mit 8 mm Stärke um das Gehäuse des SBTC zu
simulieren. Mit der Anordnung erziele ich einen Ladestrom von ungefähr 25
mA. Ziel sind aber 60 mA.
vg
Peter
Vincent Kessler
Man kann auch die Kommunikation über eine optische Schnittstelle
realisieren. Das wäre dann noch eine weniger.
Ich meine sogar, dass das bei einigen TC so gemacht wird.
Wie wärs dann noch mit Reedschaltern, oder spricht da was gegen?
Dann ist man alle Öffnungen los.
Gruß, Vinz
Volker Holthaus
Vincent Kessler schrieb:
> Wie wärs dann noch mit Reedschaltern, oder spricht da was gegen?
> Dann ist man alle Öffnungen los.
Nur der Drucksensor braucht doch ein wenig Wasserkontakt. ;-)
>
>
> Gruß, Vinz
Gruß
Volker
Peter Rachow
"Vincent Kessler" <kessler...@nscit.com> schrieb
> Einen AVR würde ich auch einem PIC vorziehen. Gerade für ein OpenSource
> Projekt überwiegen die Vorteile des AVR bei weitem.
Zumal mit dem GNU CC ein uneingeschränkt kostenfrei zu nutzender C-Compiler
vorhanden ist, der überdies ständig weiter entwickelt wird. Für den von
Microchip angebotenen Compiler muss ich dagegen löhnen, wenn ich mehr Code
als ein paar wenige kB schreiben will. Und mit wenigen kB ist meiner
Erfahrung nach kein TC zu programmieren.
vg
Peter
Vincent Kessler
Exakt. Genau das ist der Punkt.
Es gibt hier eine gute Übersicht über verfügbare Compiler für den PIC.
http://www.informel.de/pic/ccompiler.htm
Da ist nicht viel zu wollen, ohne ordentlich Geld auszugeben.
Für ein OpenSource Projekt denkbar ungünstig.
Das einzige, was da OpenSource wäre ist SDCC, und bei denen heisst es:
"Work is in progress on supporting the Microchip PIC16 and PIC18 series"
Nicht gerade das, was man für einen Tauchcomputer gerne verwenden möchte.
Für den AVR hingegen gibt es sogar fertige Pakete wie WinAVR und
AvrStudio und günstige JTAG Interfaces für ICE z.B. von Olimex.
Das gleiche gilt für den MSP430 oder wenns etwas heftiger sein soll ARM
Prozessoren.
Nun kann man natürlich sagen, wozu C, nimmste halt Assembler.
Theoretisch kann man das natürlich machen, ich habe selbst zig Projekte
- auch sehr umfangreiche - auf diversen Plattformen in Assembler
geschrieben, jedoch musste ich irgendwann auch einsehen, dass aktuelle
Compiler in vielerlei Hinsicht handgeschriebenem Assembler Code
überlegen sind.
Und wenn man dann noch einzelne Teile in Assembler machen muss oder
will, dann ist das ja auch kein Thema.
Aber das Grundkonstrukt würde ich heutzutage nicht mehr in Assembler
schreiben.
Letztendlich kommt noch dazu, dass Assembler nicht portabel ist und
gerade wenn man möchte, dass andere sich beteiligen oder an dem Code
rumwerkeln ist C einfach das Mittel der Wahl.
Gruß, Vinz