so würde meine adxrs-träger-kompatibele platine wohl aussehen



.

JUERGEN_ meinte

und so würde die schaltung meines sensoren-trägers aussehen.

lt. datenblatt des MLX sollten die NC pins (wie der name schon sagt) nicht angeschlossen werden - also auch nicht auf masse gelegt werden.

lg, hans.

ufo-hans meinte

lt. datenblatt des MLX sollten die NC pins (wie der name schon sagt)
nicht angeschlossen werden - also auch nicht auf masse gelegt werden.

damit das mit zukünftigen mlx-versionen kompatibel ist, habe ich verstanden ?
z.z. sind die aber nicht intern in den gyros belegt.

.

auszug von melexis selbst, referenzschaltung.


und ich liebe überflüssiges auf GND

.

JUERGEN_ meinte

auszug von melexis selbst, referenzschaltung.

und im datenblatt schreiben sie extra "do not connect"...

da soll sich noch wer auskennen...

ufo-hans meinte

da soll sich noch wer auskennen ...

wie so immer in den grossen firmen.

es weiss wieder nicht der linke fuss,
was die rechte hand tut.


in irgend son entwicklungs-board waren auch alle nc auf gnd.

.

Hi,

ich habe sie auch alle auf GND

Specky

wenn ich das sehen . . .
http://forum.mikrokopter.de/topic-4836.html

scheint ja doch noch eine adxrs-träger-kompatibele platine zu fehlen ???


oder, sind das alles anwärter auf den . . .

.

Hi Juergen,

ein paar Breakoutborads vom ADXRS300 sind noch zu haben...

@detlefxx bitte lese einmal Deine eMails, seit Dienstag versuche ich Deine Adresse zu bekommen!

Specky

ich war eigentlich nur zu faul !

die module nach MLX90609 umzubenennen.

und das ist eh nur etwas für leute,


die sich damit auskennen

.

Hi!

Der MLX scheint im Moment wohl große Wellen zu schlagen...
...und zwar nicht nur hier:
Ich habe mich heute noch mal nach Quellen für den MLX umgesehen, und siehe da, auf einmal (will sagen bis vor ca. 10 Tagen noch nicht)
finde ich den auch da, wo man ihn erwarten sollte, bei Sparkfun und Co.:
http://www.sparkfun.com/commerce/product_info.php?products_id=8372#
http://www.sparkfun.com/commerce/product_info.php?products_id=8337
http://www.coolcomponents.co.uk/catalog/product_info.php?cPath=36&products_id=127
http://www.componentsuperstore.com/store/ProductDetails.aspx?ProductIdentifier=MLX90609EEAR2MELEXIS6524805&MSCSProfile=3C79F0C7EA3162B289A6F3317CC124D86EF53FA25F2509A091747320010AA213F01335AF97945F8D05276BEACCAA3CD582360D6C65B65A7361C6298B10B8B61EC3281E56561BBA94DFE72E60F9C2001F77E4D4F89A2B762AD34DBA99AAB41DEBF14C77EEA4E8CB04828BEC07FC3C7786038C909B6758D8BA4BA199AE04993E292AC27FDE83E569EC
Vor drei Tagen gabs bei denen "nur" die 150°/s- Version.

Spricht (außer der Programmier- Arbeit, von der ich KEINE Ahnung habe) eigendlich irgendetwas gegen die Idee, den Sensor via SPI auszulesen?
Der MM3 wird ja wohl kaum die gesamte Bandbreite des Busses beanspruchen, und man spart sich den potentiellen Ärger mit der Analog- Auswertung...

@Specky: Ich hoffe, Du bleibst jetzt nicht auf den MLXern und den Breakout- Boards hängen. Bist aber in sofern auf der sicheren Seite, dass die Breakout- Boards von Sparkfun nicht Pin- kompatibel zu Deinen sind und damit auch nicht wirklich auf die FC passen.

MfG

Rage

Hi ragedavis,

bei Sparkfun und Future-Electronic gibts die MLXer schon ne ganze Weile....

LG Specky

Hi!

@Specky:
Bei den MLXern selber kannst Du recht haben, da habe ich mangels Reflow- Ofen nicht wirklich nachgesehen,
aber bein den Breakout- Boards bin ich mir ziemlich sicher, dass die neu sind, weil ich mich vor wenigen Tagen noch geärgert habe,
dass nur die 150er- Version bei Sparkfun als Breakout zu bekommen war.


MfG

Rage

Hi

Die gibt es dort schon recht lange. Ich hatte die bereits im Auge als hier noch niemand von den Melexis zu träumen gewagt hat
Was das Auslesen über SPI angeht: Wenn man den Angaben im Datenblatt trauen kann, dann lassen sich die Gyros häufig genug abfragen. Vermutlich würde es sogar für einen 1kHz Regeltakt gut reichen. Allerdings möchtest du den SPI Bus bestimmt nicht mit dem MM3 teilen. Der MM3 ist nämlich sowas wie ein Fahrrad auf der Datenautobahn, weil er den Bus durch Wartezeiten komplett blockiert. Dann kannst du eine Flugregelung mit Sicherheit vergessen. Das ist übrigens auch der Grund, warum wir beim NG gerade Versuche mit einem "SPI- Geschwindigkeitsumsetzer" für den MM3 starten. Ein kleiner AVR arbeitet als Puffer, der schnell mit der NG- FC kommunzieren kann und so den Bus wenig belastet. Zudem kann er ja auch gleich einen Teil der Rechenarbeit erledigen.

Gruss
Patrick

Crossfire meinte

Was das Auslesen über SPI angeht...

meine ganz persönliche meinung zu dem thema:

über A/D-wandlung der analogen signale kann ich mit dem ARM7 8 kanäle innerhalb von wenigen µs einlesen - zu einem definierten zeitpunkt. da ich mir bei SPI-übertragung der "in der ferne" eingelesenen werte nicht so ganz im klaren sein kann, wann der wert nun gültigkeit hatte, präferiere ich für diese zeitkritische geschichte weiterhin die direktere variante.

just my 2 cents...


lg, hans.

Hi Hans

Das ist natürlich eine Frage der persönlichen Vorlieben und auch ein Abwägen zwischen Vor- und Nachteilen der zwei unterschiedlichen Methoden.
Ich möchte der Vollständigkeit halber noch ergänzen, dass du über SPI die AD- Wandlung mit dem internen ADC des MLX startest und somit genau weisst, in welchem Zeitraum diese stattgefunden hat. Abgesehen davon hat man ja auch gewisse Verzögerungen durch die Berechnungen im Regler und somit ist es schlussendlich vor allem wichtig, dass die drei Messungen in möglichst kurzen Abständen und innerhalb der Regelfrequenz durchgeführt werden können.

Gruss
Patrick

hi patrick!

vollkommen richtig, was du schreibst.

mir gefällt halt einfach der geringe aufwand: starten aller 8 a/d wandlungen - interrupt, wenn letzte fertig. und das innerhalb weniger µs...

lg, hans.

Hi!

Erstmal vielen Dank für die Antworten!
Ich muß leider feststellen, dass ich etwas zu blauäugig an die Sache herangegangen bin.
Um die Bandbreite des Busses und die Häufigkeit der Abfragen habe ich mir Gedanken gemacht,
die Verzögerungen durch Buszyklen und die in beiden Fällen notwendigen A/D- Wandlungen
(aka Totzeiten) hatte ich total verdrängt.
Und ich hab zumindest eine ungefähre Vorstellung davon, wie ekelig Totzeiten im Zusammenhang mit
(zeitdiskreten) Regelungssystemen sind bzw. werden können.

Auf der anderen Seite sind die Totzeiten für den Bus im Datenblatt zu finden, also zumindest recht genau dokumentiert,
die Totzeiten für die A/D- Wandlung kommt bei beiden System zum Tragen.

Bei den (theoretisch möglichen) Regeltakt von 1 KHz sollte man sich allerdings fragen, ob die zusätzliche Totzeit
im Verhältnis zur Massenträgheit, bzw. zum Flächenträgheitsmoment der MK´s wirklich eine nicht zu vernachlässigende Größe darstellt, oder zumindest rechentechnisch in der Griff zu bekommen ist.

OT on
Stichwort "Verzögerung durch die Berechnung im Regler":
Beim Stöbern hier im Forum habe ich an einigen Stellen den Hinweis gefunden, dass der Prozessor mit den vorhandenen
Aufgaben doch schon ziemlich an seine Grenzen gebracht wird. (Artikel Coderedesign von killagreg)
An einer anderen Stelle habe ich gelesen, dass beispielsweise Winkelfunktionen über eine Werte- Tabelle angenähert werden, weil der µC "nur" 3 der 4 Grundrechenarten beherrscht, von einer FPU ganz zu schweigen.
Divisionen, Winkelfunktionen oder gar Matrix- Operationen (Stichwort Kalman- Filter, der in diesem Projekt meines Wissens nicht genutzt wird) müß(t)en also in Software durchgeführt werden. Und das kostet wiederum reichlich Rechenzeit.

Lange Rede, kurzer Sinn: Bei Stöbern bei den einschlägigen Hardware- Bezugsquellen bin ich zufällig auf folgendes gestoßen:
Ein Floating-Point- Coporzessor, der speziell für Anwendungen wie diese entwickelt und gebaut wurde.
http://www.micromegacorp.com/umfpu-v3.html

Die Vorteile:
- Hardwaremäßige, also schnellere Berechnung im Floating- Point- Bereich
- Exakte Werte statt Näherungen (wobei ich keine Ahnung habe, wie genau die Näherungen sind, zum "in der Luft bleiben" reicht es ganz offensichtlich)
- geringere Auslastung des µC, oder anders gesagt, mehr freie Rescourcen für andere Aufgaben
- weniger Speicherbedarf (die "Wertetabelle" fällt weg)

Die Nachteile:
- Software zur Ansteuerung erforderlich
- Mehrkosten (~10 Euro für den IC, ~5 Euro für "Kleinkram")

Eigendlich käme jetzt ein OT off, aber so lang, wie das Ganze jetzt geworden ist,
mache ich zu dem Thema lieber einen neuen Thread auf. Kommentare zum Thema FPU also bitte dort hinterlegen.

http://forum.mikrokopter.de/topic-4933.html

MfG

Rage

Besonders schlimm wird es, wenn die Totzeiten auch noch zeitlich variieren und das unvorhersehbar und in deutlichen Prozentzahlen der Zykluszeit.
Nicht umsonst gibt es nur wenige Echtzeitbetriebssysteme.

Hi!

Die Totzeit für die Übertragung eines Datenpaketes über den SPI beträgt laut Datenblatt des MLX 24 Clockcycles, ist als fest definiert.
Die höchste per Definition zulässige Taktrate für den SPI beträgt 4MHz.
Damit dauert die Abfrage eines Datenpaketes 0,000006 s bzw. 6 µs.

Die Zeit, bis der MLX einen Datensatz berechnet hat, beträgt laut Datenblatt durchschnittlich 90µs, maximal 125 µs.
Im schlimmsten Fall hat man also eine Totzeit von insgesamt 131µs.
Sicher mehr als bei der analogen Beschaltung zum µC, aber immer noch sehr klein im Verhältnis zur Trägheit der QC.

MfG

Rage

ragedavis meinte

Im schlimmsten Fall hat man also eine Totzeit von insgesamt 131µs.
Sicher mehr als bei der analogen Beschaltung zum µC, aber immer noch sehr klein im Verhältnis zur Trägheit der QC.

aber doch schon beachtlich groß, wenn man den vergleich zu 1000µs regeltakt anstellt - man ist einfach immer um diesen tick später dran.

lg, hans.

Ja, aber eben "immer", also jedes mal... und somit ist das Delta dazwischen immer noch 1ms...
... wenn man's richtig macht... im Interrupt.

Gruss
- Amir

Hi,

hier mal zwei Bilder



Specky

Sind die nun früher im Shop zu beziehen, weil fertig? Ich suche im Niershop aber finde nichts.

schön aufgeräumt schaut das aus! freue mich auf die tarnfarbenen teile!

mfg
Rob - hofft dass genug bestellt wurden.