Bralph

Gibt es für das Bricklet schon einen Veröffentlichungstermin bzw. eine grobe Abschätzung wann es rauskommt?

Ich habe in einem der letzten Blogeinträge gelesen, dass der I2C Bus Leitungslängen bis 8 m zulässt. Heißt das im Umkehrschluss, dass man am Masterbrick 2.1, durch die Einführung des Hub, knapp 8 m lange Brickletkabel anschließen könnte?

Mir würden noch ein kapazitiver Näherungssensor und ein Radioaktivitätsmessgerät (z.B. für Radon) einfallen. Auch ein Bluetooth bricklet speziell für iBeacon wäre interessant.

Ich finde es super, dass ihr dieses Projekt jetzt so richtig angeht. Habt ihr schon eine ungefähre Vorstellung wie lange es noch dauert bzw. ist der RED Brick die nächste geplante Veröffentlichung?

Ich sehe wie auch einige Kommentatoren zuvor, einen geringen Stromverbrauch als wichtig an, um einen Batteriebetrieb zu ermöglichen.  Darüber hinaus würde ich über einen Akkumanagementbrick nachdenken, der eine gute Ergänzung dazu wäre.

Viel Glück bei der Entwicklung mit hoffentlich keinen größeren Problemen.

Ich finde das "Li-ion battery management module" cool. Wäre sicherlich auch ein cooler Brick. Vor allem wenn irgendwann einmal die Standalone API kommt  .

d.h. ihr plant zusätzlich ein Tasterbricklet sowie Neigungs-, Regen- u. Feuchtigkeitssensor. Wird dann wohl auch eine Wetterstation 2.0 geben!? Nicht schlecht, ist ja einiges in der Pipeline…

Ok ich habe das Bricklet mal in unser Gerät eingebaut, d.h. aus einer Platine (von der ich leider keine Schaltpläne habe) kommen zwei Kabel an denen ein analoges Amperemeter hängt. Ich wollte das Bricklet in Reihe noch dazu schalten. Neben dem hohen Innerwiderstand der wahrscheinlich auch ein Problem für ein Amperemeter ist, floss nur durch das Einbringen in dem Stromkreis plötzlich und unerwartet Strom. Galvanisch getrennt sind die Eingänge von der Versorgung wahrscheinlich nicht?! Für meinen Aufbau ist es dadurch leider nicht zu gebrauchen.

Könntet ihr in den Bindings für die Variable „sensor“ noch eine Erklärung hinterlegen. Ich musste mir das aus euren Beispielcode erschließen.

Trotzdem vielen Dank für eure immer super schnelle Hilfe.

Bralph

Sinnvolle Stromwerte bekam ich nur, wenn ich M/- beschalte (beispielhaft für einen Sensor -siehe Abbildung). Dabei lag der Innenwiderstand des Bricklets bei etwa 90 Ω. Mein Testaufbau war ein Ohmeter (als Spannungsquelle), ein externes Amperemeter als Referenz und dann noch das Bricklet.

Wenn ich das Industrial Dual 0-20mA Bricklet als reines Amperemeter nutzen will, wie beschalte ich das Gerät? Brücke beim Sensor (+/M) und Supply in den Stromkreis?

Danke

Bralph

Für mich wäre ein erweiterter Masterbrick als Datenlogger interessant. Zum einem um festzustellen was vor einem Absturz schief gelaufen ist, aber vor allem als Messdatenerfasser (am besten mit nicht flüchtigen, austauschbaren Speicher). Den Pi finde ich dafür überqualifiziert.

Ich würde auch zur C-API tendieren. Auch in Hinblick auf eure Zielgruppe Industrie.

Was mir etwas an der Homepage fehlt ist eine Beschreibung zur Lizenzierung. So direkt habe ich dazu nichts gefunden. Ihr sprecht zwar von „open source hardware“, aber das sagt nichts über die Lizenzierung aus. Klar in den Tiefen der Schaltpläne findet man die CERN OHL 1.1 Lizenz (auf der Homepage wird das bis auf zwei Pressemittelungen nicht erwähnt). Die Frage bleibt ob ihr auch andere Lizenzmodelle anbietet: z.B. was würde es kosten, das Design weiterzuentwickeln und kommerziell zu vertreiben? Für die Industrie mit dem ganzen Prototypenbau sicherlich ein interessanter Punkt.

Danke für die Überarbeitung. Ein kleines Leerzeichen ist noch zu viel in Unit LEConverter:

function LEConv ertBooleanFrom(const offset: longint; const data: TByteArray): boolean;

Danke für den Hinweis mit dem Offset. Ich hätte nicht gedacht dass der so groß ist.

Leider passt auch die Steigung nicht ganz. Die Linearität ist OK, wie man an der Messreihe sieht (Vergleich interner / externen angelegter Temperatursensor). Die Steigung ist nicht 1 sondern liegt bei etwa 0.5. Scheint irgendwo noch ein Faktor 2 zu fehlen.

Und noch ein kurzer Hinweis zur der einen Move Zeile (erster Post):

Move(pendingData[len], pendingData[0], Length(pendingData) - len);

Das Problem ist glaub ich nicht die Verschiebung um Null sondern das Array pendingData hat Indices von 0..9. len hat in diesem Fall den Wert 10 versucht auf die entsprechende nicht vorhandene Position zuzugreifen.

Ich habe noch einige Probleme mit den Delphi Bindings.

Mein Beispielcode sieht derzeit so aus:

ipcon := TIPConnection.Create;
stepper := TBrickStepper.Create(UID, ipcon);
ipcon.Connect(HOST, PORT);
label1.caption:= inttostr(stepper.GetChipTemperature); 

Zum einem lassen sich die Bereichsüberprüfung und Überlaufprüfung in den Compileranweisungen nicht aktivieren ohne dementsprechende Fehler zu provozieren.

Z..B. hier (TIPConnection.ReceiveLoop):

Move(pendingData[len], pendingData[0], Length(pendingData) - len);

Ok kann man abschalten und akzeptieren, aber besonders schön ist das nicht.

Die Chip Temperatur die ausgelesen wird liegt bei ca. -28°C. Nicht wirklich realistisch! Wenn man etwas genauer hinsieht gibt es hier Probleme:

function LEConvertUInt16From(const offset: longint; const data: TByteArray): word;
begin
  result := word(data[offset + 0]) shl 0 or word(data[offset + 1]) shl 8;
end;

OK ein Beispiel: data[8] hat den Wert 225 (225/10= 22.5°C was passen würde). Der Rückgabewert ist mit den Ganzen shl Verschiebungen leider 65508. Diesen Wert kann die endgültige Rückgabefunktion LEConvertInt16From nicht mehr verarbeiten (Überlauf da smallint was nur bis grob 32000 geht). Macht dann – 28°C. mmmh schlecht.

Die Typdefinition

TArray0To2OfUInt8 = array [0..2]of byte

müsste in der Unit BrickStepper.pas gelöscht werden da diese bereits in der Unit Device.pas definiert ist. Der Compiler (Delphi XE2) stellt sonst in der Prozedur GetIdentity eine Unterscheidung fest. Das Problem besteht wahrscheinlich noch vielen weiteren Units.

@Luxor: Die reinen Materialkosten für die ausgedruckten Teile lagen bei ca. 10.- (das Mittelteil davon etwa 5.80).

Lieber BorgelMorgel könntest du die Gehäusedateien in einem anderen Format ins Forum stellen damit wir die Formen noch etwas bearbeiten können (z.B: *.stp, *.dwg oder *.dxt). Unser Programm ist Solid edge. Wir würden das Gehäuse soweit anpassen dass die Platine gut reinpasst.

Die Gehäusefotos (leider etwas schlecht belichtet)…

@luxor: Kosten muss ich noch nachfragen

Upps, die Stecker passen mit etwas Gewaltanwendung doch. Das Problem ist, dass auf der Platine die Buchsen nicht ganz exakt positioniert sind (wahrscheinlich Fertigungstoleranzen des Bestückers).

@ luxor

Unsere Hochschule hat einen Objet30 Pro (Genauigkeit so 0.1 mm)

Ich hab die *.stl Dateien der Bodenplatte, des Deckels und es Stepperbricksgehäuse auf einem professionellen 3D-Druckers ausgedruckt. Die Gehäuseteile passen bei mir perfekt aufeinander. Der Stepperbrick ließ sich jedoch nur mit leichter Gewaltanwendung in das Gehäuse drücken.

Das zweite Problem sind die Aussparungen für die Brickletanschlüsse. Mein Brickletstecker ist leider etwas breiter als die Aussparung und lässt sich somit nicht anstecken (außer man feilt die zwei Ohren weg).

Ansonsten passte alles perfekt und sieht auch toll aus. DANKE

Liebes Tinkerforge-Team

Ich wollte fragen ob die Industrial Bricklets mit Schraubsteckern betrieben werden können (ich wüsste zwar nicht was dagegen spricht) und ob ihr diese in eurem Shop anbieten werdet?

Danke

Bralph

P.S.: Die Diskussion über die Probleme bei den Bricks habe ich gelesen (http://www.tinkerunity.org/forum/index.php/topic,1178.msg7158.html#msg7158).

Der "Arduino Due" wurde ja inzwischen offiziell veröffentlicht. Arbeitet Ihr schon an der "On Device API"? Gibt es einen angepeilten Releasetermin? In der Timeline hab ich noch nichts gefunden.

Vielen Dank.

In dem Projekt geht um die Digitalisierung einer kalibrierten analogen Anzeige. Der Sensor liefert Ströme zwischen 2 und 7 mA. Deshalb wäre eine Auflösung unter 0.5 mA absolut nötig, besser wären 0.1 mA oder weniger um ein paar mehr Stützstellen zu haben. Technisch sicherlich kein Problem. (bezüglich der zu erreichenden Auflösung bezog ich mich auf einen anderen Post http://www.tinkerunity.org/forum/index.php/topic,246.msg1120.html#msg1120- hab leider nicht nachgerechnet  ).

Vielen Dank für die Info.

Bralph

Liebes Tinkerforge Team,

könnt ihr mir sagen ob das geplante neue Current Bricklet eine bessere Auflösung als die bisherigen 3 mA bietet? Ich bräuchte was im Bereich von unter 0.5 mA.

Vielen Dank

Bralph