AuronX

Mich würde übrigens sehr interessieren, wie das ganze am Ende aussieht wenn es verbaut wurde ^^ Viele Grüße Jan P.S.: @TF: Habt ihr schonmal überlegt eure Dual-Relays in einer kommenden Hardware-Version durch Solid State Relays zu schalten? Diese scheinen ja für das Baukasten-Prinzip die überlegene Technologie zu sein, weil sie Fehlertoleranter sind. Oder gibt es dort andere Nachteile?

Glaube zum Thema UART gab es schonmal nen Thread, ich erinnere mich aber nicht mehr an die Lösung. Such einfach mal nach UART ^^

Du solltest bei den Dual-relays soweit ich das sehe zwei Dinge beachten: - nicht viele auf einmal schalten (ich glaube im standby verbrauchen sie nichts, aber bin mir unsicher) - mit den Relays kannst du nicht ohne weiteres Dinge schalten die magnetische Rückkopplungen erzeugen (Paradebeispiel: Leuchtstoffröhre) - Es gibt viele Berichte, dass die Dual-Relays sich schlecht mit LCD vertragen, deswegen würde ich dir empfehlen deine zwei Master-Bricks einzeln (nicht gestacked) anzuschließen

Wenn ich die Strömungsgeschwindigkeit abhängig vom Anstellwinkel meines Messinstrumentes bestimmen möchte Ich denke was sich durchaus noch entwickeln könnte wäre eine Sammlung von Mods/Addons/Custom-Firmwares (nennt es wie ihr wollt). Damit wäre sowas dann von TF weg, sofort in die "Profi-Ecke" verschoben und trotzdem könnte man es vielen zugänglich machen die es wollen. LG Jan

Das passt aber nicht wirklich zum Konzept von TF. Da sind ja quasi alle Bricks gleich, aber jeder hat eine "Superkraft" die ihn von den anderen bricks unterscheidet. Wenn jetzt plötzlich ein Bricklet nur an manchen Bricks vollen Leistungsumfang aht wäre das doof.

Also ich gehe davon aus, dass du "zwischen" den Umdrehungen die Zeit genau genug bestimmen können solltest, dass das klappt. Die mehreren Messungen würde ich deswegen machen, weil du so toleranter gegenüber ungünstigem Scheduling durch dein Betriebssystem bist (ein hoch-priorer Task der dafür sorgt, dass du die Zeit erst eine Millisekunde später messen kannst usw.). Wenn ich da so drüber nachdenke macht ein arithmetisches Mittel gar keinen Sinn, weil es diese Ausreißer halt nur dämpfen würde. Ich vermute ein Median über n Messungen sollte besser geeignet sein (für die Ermittlung der Momentangeschwindigkeit). Wenn du dir dann die Momentanwerte eine Minute lang notierst, dann kannst du zusätzlich auch noch eine Durchschnittsgeschwindigkeit berechnen. OT: Wenn ich irgendwann über eigenen Grund und Boden verfüge werde ich sowas wohl auch bauen und dann hoffentlich die Erfahrung von euch anderen nutzen können

Die Zeit zwischen zweien wird dir sehr wackelige Werte geben und hin und wieder nen Ausreißer wenn mal der Prozess nciht sofort drankommt. Ich würde es erstmal mit der Zeit dazwischen probieren und das über ein paar Umdrehungen mitteln, das sollte dann ganz ordentlich sein und nciht zu verzögert. Kommt auch auf den Anwendungsfall an, wenn du Böhen messen willst musst du innerhalb von einigen Umdrehungen ne zahl haben, wenn du nur den typischen Wind brauchst, dann mittlere ruhig über ne Minute oder so...

Bisher nur Servo-Brick und Distance IR Bricklet. Das Servo-Brick steuert Motor, Lenkung und ggf. einen weiteren Servo für ein "Rundum-Sicht"-Distanz-Bricklet. Das Distance IR schaut im Moment nur nach vorn. Was den Code angeht habe ich damals vergessen zu erwähnen, dass der auf den von mir veränderten TF-Bindings beruht. Dort sind Callbacks mit .NET-Events umgesetzt und ich kann mir den Position-Callback des Servo an verschiedenen Stellen besorgen. Allerdings ist das Projekt bei mir gerade eingeschlafen weil mein Fahrtenregler an Altersschwäche gestorben ist. Werde da aber weitermachen, habe auf der SOftwareseite auch noch einige Sachen vor die den Code hübscher machen ^^

Das war auch mehr an den Threadersteller gerichtet Ich möchte bitte kein Bricklet mit 4x7 Eingängen und passendem Textparser im Shop sehen

Habe das heute auf heise gelesen und mich auch direkt gefragt in welcher weise das mit TF gepaart werden kann. Vermutlich kann man das TF-Protokoll irgendwie in die Plattform einbinden oder so, habe ich mir aber noch nicht genau angeschaut ^^ @mikrolinux: Klingt ja wahnsinnig spannend ^^ Täusche ich mich oder steht das noch gar nciht im Projektbereich?

Zum Thema: Möglicherweise kriegt man die originalen Empfänger angezapft... Ich habe leider keine ELektronik-erfahrung, deswegen könnte das auch unsinn sein... Aber das wäre eine Chance. Was auf jeden Fall gehen sollte (aber nicht erstrebenswert ist) ist das folgende: Der originale Empfänger wird ja die Temperatur über ein Display ausgeben, vermutlich so eine 7-Segment-Anzeige. Spätestens dort könnte man natürlich das Signal für die Anzeige abgreifen und "parsen". Wie gesagt, nciht erstrebenswert aber ein Notnagel.

Danke für die Erläuterung ^^

Ist ja interessant... Aber es unterscheidet sich schon von einer Messung der relativen Luftfeuchte oder? (Weil er schreibt, dass damit der Wassergehalt der Luft gemessen wird) Hmmm... ziemlich cool, auch wenn ich es noch nicht ganz verstehe

Bin gespannt wie die Software-Seite dessen aussieht ^^ Kann mir gerade noch nciht vorstellen, wie man mit einem Distance IR Bricklet Wolken erkennt

dito... bei mir ist auch keine externe befestigung nötig...

Und damit nennst du ja nichtmal die Probleme durch ARM und Co ^^ Ich bin auch mittelmäßig skeptisch was den Gain durch die neue Implementierung angeht. Immerhin ist TCP (darauf basiert ja der brickd) schon von sich aus eher fett (selbst wenn es nur übers loopback-interface geht). Auf jeden Fall solltet ihr da vorher ausloten was ihr erwartet und mit nem kleinen Prototyp testen ob das jemals erreicht werden kann. Alternative: Ich habe mir sagen lassen, dass PyPy schneller sein soll als Python (ist aber source-kompatibel). Aber das ist mehr so hören sagen (keine Erfahrungen meinerseits), wäre aber villt eine interessante Richtung in die man die Nase mal halten könnte ^^

@borg: Ich denke alle die die hohe auflösung wollen kommen aus der Ecke "Quadrokopter". Eine Frage die ich für mcih noch nicht klären konnte ist, ob TF überhaupt geeignet ist Quadrokopter zu steuern. Also mit eigener Firmware natürlich, aber mit Bordmitteln wird das eng. Da ist dann schon die Frage, ob der Wunsch nach der höheren Auflösung nicht eher auf "Träumen" beruht. Der einzig andere Anwendungsfall für ein Altimeter der mir einfällt wäre das HUD fürs Flugzeug, da wird Metergenauigkeit wohl reichen ^^ Will sagen: ich bin mir inzwischen uneins... Haltet ihr (TF) den Einsatz eurer Hardware für quadrokopter für realistisch?

Da ich denke, dass er von vielen Nutzern eben auch als Altimeter für Quadrokopter u.ä. eingesetzt werden soll (bzw. als solcher mal gewünscht wurde) wäre ich auch definitiv für den hoch-aufgelösten. Der andere scheint nur für die Wetterstationen u.ä. interessant zu sein.

Also erstmal steht auch noch die Frage im Raum ob der Code den du gezeigt hast ausführbar ist, es sieht nämlich nach einem kleinen Fehler aus (Vermutung: Funktion InsertRow mal außerhalb der Main-methode definieren und nur innerhalb der main rufen, dann klappts). Ansonsten ist wohl keine Sprache dafür von sich aus besser geeignet. C# ist schon ziemlich gut, weil du mit Visual Studio ein ziemlich gutes Entwicklungs-Werkzeug zur Verfügung hast (meine Meinung). Gut erlernbar wäre denke ich Python. Aus dem Bauch heraus würde ich sagen bleib einfach bei C#, wenn jede andere Sprache (außer PHP) ebenso Einarbeitung für dich bedeutet (Ansonsten nimm eine Sprache die dir vertraut ist). PHP würde ich tatsächlich nur im Webserver-Umfeld nutzen.

Definierst du die Funktion InsertRow mitten IN der main-funktion? Das sieht komisch aus und ich wäre erstaunt, wenn das kompiliert... aber gut. Auf jeden Fall scheinst du diese methode niemals aufzurufen, liegt es daran? Ansonsten: Kommen Fehler? Oder läuft alles stumm durch?

Was zum nicht-erkennen deines Bricks bei angeschlossenem Bricklet führt ist mir nicht erklärbar. SPielt es dabei eine Rolle an welchem Eingang des Bricks du das Bricklet anschließt oder spielt das Kabel eine Rolle? Wenn es mit der alten Firmware gefunzt hat, dann würde ich versuchen diese wieder aufzuspielen. Wenn es dann wieder funktioniert ist natürlich trotzdem die Frage warum Wegen dem Grundproblem: Also ich meine mich zu erinnern, dass ein Kabel das "in der Luft" hängt, also weder an Masse noch an VCC angeschlossen ist auch nichts anderes macht als zu rauschen. Das heißt es kann je nach "Gemütszustand" mal 1 oder mal 0 geben. Zumindest glaube ich nicht, dass es in jedem Fall 0 Volt gibt. Aber mein Wissen dazu ist eher angestaubt...

Kann man solchen Problemen irgendwie kostengünstig entgegenwirken? (zumindest die Eintrittswahrscheinlichkeit senken) Ich denke dabei an Kondensatoren oder andere Komponenten die entweder die empfindlichen Komponenten resistenter gegen Stromschwankungen machen oder aber die Schwankungsverursachenden Komponenten weniger gefährlich. Keine Ahnung ob das so einfach möglich wäre...

Also wenn dein getState das vom Dual Relay ist, dann sollte der Aufruf in etwa so aussehen: $current_state = $myDualRelayBricklet->getState(); Du musst die Funktion ja auf einem bestimmten Bricklet aufrufen...

Ich möchte doch sehr bitten

Er würde ncihts anzeigen, richtig. Aber zumindest sollte die Fehlermeldung "Please check host, check port und check if brickd is running." nur dann kommen, wenn kein service läuft oder er nciht erreichbar ist. Es sollte keinen Zusammenhang zu angeschlossenen Geräten geben. P.S.: gerade getestet, nix angeschlossen und erfolgreich connected